时间戳

首页 > 解决方案 > 一个 pod 中多个容器的活跃度和就绪度探测

kubernetes - 一个 pod 中多个容器的活跃度和就绪度探测

问题描述

我想知道是否有可能对 pod 中的多个容器或仅对 pod 中的一个容器应用活性和就绪探测检查。我确实尝试使用多个容器进行检查，但容器 A 的探测检查失败，并且容器 B 在 pod 中通过。

标签： kuberneteskubernetes-health-checkreadinessprobelivenessprobe

解决方案

欢迎来到社区。

回答

绝对可以对 pod 中的容器应用多个探针。接下来会发生什么取决于探测。

Containers 探针中列出了三个可以使用的探针liveness：readiness和startup。我将更多地描述livenessand readiness：

活力

livenessProbe：指示容器是否正在运行。如果 liveness探测失败，kubelet 会杀死容器，并且容器会受到其重启策略的约束。如果 Container 不提供liveness探测，则默认状态为 Success

kubelet 使用 liveness probes 来了解何时重新启动容器。例如，活跃度探针可以捕获死锁，即应用程序正在运行，但无法取得进展。尽管存在错误，但在这种状态下重新启动容器有助于使应用程序更可用。

如果livenessProbe失败，kubelet将在 POD 中重新启动容器，POD 将保持不变（它的年龄也是如此）。

也可以签入container events，此报价来自Kubernetes in Action - Marko Lukša

我在很多场合都看到过这种情况，用户很困惑为什么要重新启动他们的容器。但如果他们使用kubectl describe，他们会看到容器以退出代码 137 或 143 终止，告诉他们 pod 已在外部终止

准备就绪

readinessProbe：指示容器是否准备好响应请求。如果readiness探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认状态readiness是失败。如果 Container 不提供readiness探测，则默认状态为 Success

kubelet 使用就绪探针来了解容器何时准备好开始接受流量。当 Pod 的所有容器都准备好时，就认为 Pod 准备好了。此信号的一种用途是控制哪些 Pod 用作服务的后端。当 Pod 未准备好时，它会从服务负载均衡器中移除。

这里发生的是 kubernetes 检查容器中的 webserver 是否正在处理请求，如果没有，则readinessProbe失败，并且 POD 的 IP（通常是整个 POD）将从端点中删除，并且不会将流量定向到 POD。

有用的链接

推荐阅读