From：Kubernetes in Action

存活探针（liveness probe）

k8s可以通过存活探针，检查容器是否还在运行。可以为pod中每个容器单独指定存活探针，如果探测失败，k8s将定期执行探针并重新启动容器。

Kubernetes 存活探针有以下三种探测容器的机制：

  • HTTP GET探针对容器的 IP 地址（你指定的端又和路径）执行 HTTP GET请求。如果探测器收到响应，并且响应状态码不代表错误 （换句话说，如果 HTTP响应状态码是2xx或3xx），则认为探测成功。 如果服务器返回错误响应状态码或者根本没有响应，那么探测就被认为是失败的，容器将被重新启动。

  • TCP套接字探针尝试与容器指定端又建立 TCP连接。如果连接成功建立，则探测成功。否则，容器重新启动。

  • Exec探针在容器内执行任意命令，并检查命令的退出状态码。如 果状态码是0，则探测成功。所有其他状态码都被认为失败。

该 pod 的描述文件定义了一个 httpGet 存活探针，该探针告诉 Kubernetes定期在端口8080路径上执行 HTTP GET请求，以确定该容器是否健康。这些请求在容器运行后立即开始。

当你想知道为什么前一个容器终止时，你想看到的是前一个容器的日志，而不是当前容器的。可以通过添加--previous选项来完成：

kubectl logs mypod --previous

可以通过查看kubectl describe的内容来了解为什么必须重启容器， 如下面的代码清单所示

在底部列出的事件显示了容器为什么终止 ——Kubernetes发现容器 不健康，所以终止并重新创建。

kubectl describe 还显示关于存活探针的附加信息：

除了明确指定的存活探针选项，还可以看到其他属性，例如 delay（延迟）、 timeout（超时）、 period（周期）等。delay=0s部分显示在容器启动后立即开始探测。 timeout仅设置为1秒，因此容器必须 1 秒内进行响应，不然这次探测记作失败。每 10 秒探测一次容器 （period=10s），并在探测连续三次失败（#failure=3）后重启容器。

定义探针时可以自定义这些附加参数。例如，要设置初始延迟， 将 initialDelaySeconds 属性添加到存活探针的配置中。

如果没有设置初始延迟，探针将在启动时立即开始探测容器，这 通常会导致探测失败，因为应用程序还没准备好开始接收请求。如果 失败次数超过阈值，在应用程序能正确响应请求之前，容器就会重启。

就绪探针（readiness probe）

像存活探针一样，就绪探针有三种类型：

  • Exec探针，执行进程的地方。容器的状态由进程的退出状态代码确定。

  • HTTP GET探针，向容器发送 HTTP GET请求，通过响应的 HTTP 状态代码判断容器是否准备好。

  • TCP socket探针，它打开一个 TCP 连接到容器的指定端口。如果连接已建立，则认为容器已准备就绪。

启动容器时，可以为 Kubernetes配置一个等待时间，经过等待时间后才可以执行第一次准备就绪检查。之后，它会周期性地调用探针， 并根据就绪探针的结果采取行动。如果某个 pod报告它尚未准备就绪， 则会从该服务中删除该pod。如果pod再次准备就绪，则重新添加pod。

与存活探针不同，如果容器未通过准备检查，则不会被终止或重新启动。这是存活探针与就绪探针之间的重要区别。存活探针通过杀死异常的容器并用新的正常容器替代它们来保持 pod 正常工作，而就绪探针确保只有准备好处理请求的 pod 才可以接收它们（请求）。这在容器启动时最为必要，当然在容器运行一段时间后也是有用的。

如果一个容器的就绪探测失败，则将该容器从 endpoint 对象中移除。连接到该服务的客户端不会被重定向到 pod。这和 pod 与 service 的标签选择器完全不匹配的效果相同。

可以通过 kubectl edit 命令来向已存在的 ReplicationController中的 pod 模板添加探针。

就绪探针将定期在容器内执行 ls/var/ready命令。如果文件存在，则 ls命令返回退出码 0，否则返回非零的退出码。如果文件存在，则就绪探针将成功；否则，它会失败。

观察并修改pod就绪状态

READY列显示出没有一个容器准备好。现在通过创建 /var/ready文 件使其中一个文件的就绪探针返回成功，该文件的存在可以模拟就绪探针成功：

使用kubectl exec命令在kubia-2r1qb的pod容器内执行touch命令。如果文件尚不存在， touch命令会创建该文件。就绪探针命令现在应该返回退出码 0，这意味着探测成功，并且现在应该显示 pod 已准备就绪。 现在去查看其状态：

准备就绪探针会定期检查——默认情况下每 10秒检查一次。由于尚未调用就绪探针，因此容器未准备好。但是最晚10秒钟内，该pod应该已经准备就绪，其 IP 应该列为 service 的 endpoint。