Kubernetes 的 livenessProbe
是有一定危险性的。建议在用例清晰,并且理解足够深刻的情况下才使用这个功能。本文会涉及到存活检测以及就绪检测,并做出一些应该或者不该的建议。
我的同事 Sandor 最近说了一下他看到的问题,其中包括了错误的存活检测和就绪检测的内容:
错误的存活检测过程可能加重负载问题(雪崩式故障加上延长容器应用启动时间的风险),会引发其他负面问题,例如破坏依赖(参见我另一篇关于 K3s 和 ACME 速率限制的文章)。存活检测和外部数据健康检查的依赖是最差的情况:数据库的一点小问题会重启你的所有应用。
在喊出“不要使用存活检测”口号之前,还是先看看存活检测和就绪检测的用途。
注意下文很多来自 Zalando 的内部文档。
Kubernetes 提供了两个很棒的功能,分别是就绪检测和存活检测。这两个功能会周期性的执行一个动作(比如说发出 HTTP 请求,打开一个 TCP 连接或者在容器中运行一个命令),从而确认你的应用正在如常运行。
Kubernetes 使用就绪检测来探测容器是否准备好开始接收流量。如果 Pod 中所有的容器都准备就绪,这个 Pod 就被当做是就绪状态。这种信号的一个用途就是来控制 Kubernetes 服务的后端 Pod(尤其是 Ingress)。
Kubernetes 使用存活检测来确定是否需要重启容器。例如存活检测能够检查到运行中应用的死锁,这种应用正在运行,但是不会有任何进展。重启这种容器能够在有 Bug 的情况下提高应用的可用性,然而也可能会引起级联故障(见后)。
如果一个应用的存活或者就绪检测失败了,在尝试对其进行更新时,滚动更新的过程可能会挂死——K8s 会想要等待你的 Pod 进入就绪状态。
就绪检测会使用 HTTP 协议,检查 /health
路径(缺省行为:10 秒钟间隔、1 秒钟超时、成功阈值 1,失败阈值:3):
...
podTemplate:
spec:
containers:
- name: my-container
# ...
readinessProbe:
httpGet:
path: /health
port: 8080
...
/health
)来完成就绪检测。stateupProbe
failureThreshold
(例如 3 次失败之后设置为未就绪,10 次失败后才让存活检测失败)exec
检测:这是一个已知问题,会导致僵尸进程。