存活探针
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 本身运行在节点上，所以如果节点异常终止，它将无法执行任何操作。