存活探针
Kubemetes 可以通过存活探针 (liveness probe) 检查容器是否还在运行。可以为 pod 中的每个容器单独指定存活探针。如果探测失败,Kubemetes 将定期执行探针并重新启动容器。
Kubemetes 有以下三种探测容器的机制:
- HTTP GET 探针对容器的 IP 地址(用户指定的端口和路径)执行 HTTP GET 请求。
如果探测器收到响应,并且响应状态码不代表错误(如果 HTTP 响应状态码是2xx或3xx), 则认为探测成功。
如果服务器返回错误响应状态码或者根本没有响应,那么探测就被认为是失败的,容器将被重新启动。
- TCP 套接字探针尝试与容器指定端口建立TCP连接。如果连接成功建立,则探测成功。否则,容器重新启动。
- Exec 探针在容器内执行任意命令,并检查命令的退出状态码。如果状态码是 0, 则探测成功。所有其他状态码都被认为失败。
RESTARTS 列显示 pod 的容器已被重启一次,可以通过查看kubectl describe的内容来了解为什么必须重启容器。
可以看到容器现在正在运行,但之前由于错误而终止。
退出代码为137, 这有特殊的含义:表示该进程由外部信号终止。数字137是两个数字的总和:
128+x, 其中x是终止进程的信号编号。在这个例子中,x等于9, 这是 SIGKILL 的信号编号,意味着这个进程被强行终止。
在底部列出的事件显示了容器为什么终止:Kubemetes发现容器不健康,所以终止并重新创建。
当容器被强行终止时,会创建一个全新的容器,而不是重启原来的容器。
kubectl describe 还显示关于存活探针的附加信息:
- delay=0s 表示在容器启动后立即开始探测。
- timeout=1s 表示容器必须在1秒内进行响应,否则这次探测记作失败。
- period=10s 表示每10秒探测一次容器。
- failure=3 表示在探测连续三次失败后重启容器。
定义探针时可以自定义这些附加参数, 比如设置初始延迟。
如果没有设置初始延迟,探针将在启动时立即开始探测容器, 这通常会导致探测失败,因为应用程序还没准备好开始接收请求。如果失败次数超过阈值,在应用程序能正确响应请求之前, 容器就会重启。
总结
Kubernetes 会在容器崩溃或其存活探针失败时,通过重启容器来保持运行,由承载 pod 的节点上的 Kubelet 执行,在主服务器上运行的 Control Plane 组件不会参与此过程。
如果节点本身崩溃,那么 Control Plane 必须为所有随节点停止运行的 pod 创建新的 pod。它不会为你直接创建的 pod 执行此操作,这些 pod 只被 Kubelet 管理,但由于 Kubelet 本身运行在节点上,所以如果节点异常终止,它将无法执行任何操作。