Pod 中的健康检查liveness,readiness,startupProbe_liveness 容器中是什么意思

在创建Pod时，可以通过liveness和readiness两种方式来探测Pod内容器的运行情况。
1. liveness 可以用来检查容器内应用的存活的情况，用来探测容器是否真的在“运行”，即“探活”。如果检查失败这个时候kubelet会杀掉容器进程，停掉该容器，是否重启容器则取决于Pod的重启策略。
2. readiness 检查容器内的应用是否能够正常对外提供服务，即“就绪”，比如 nginx 容器在 reload 配置的时候无法对外提供 HTTP 服务。如果探测失败，则Endpoint Controller会将这个Pod的IP从服务中删除。
3.startupProbe 则可以用于判断容器是否已经启动好，就比如上面提到的容器启动慢的例子。我们可以通过参数，保证有足够长的时间来应对“超长”的启动时间。 如果检测失败的话，同livenessProbe的操作。这个 Probe 是在 1.16 版本才加入进来的，到 1.18 版本变为 beta。也就是说如果你的 Kubernetes 版本小于 1.18 的话，你需要在 kube-apiserver 的启动参数中，显式地在 feature gate 中开启这个功能。可以参考这个文档查看如何配置该参数。

这三种探针均具有以下参数：
initialDelaySeconds： 启动 liveness、readiness 探针前要等待的秒数。
periodSeconds： 检查探针的频率。
timeoutSeconds： 将探针标记为超时（未通过运行状况检查）之前的秒数。
successThreshold： 探针需要通过的最小连续成功检查数量。
failureThreshold：将探针标记为失败之前的重试次数。对于 liveness 探针，这将导致 Pod 重新启动。对于 readiness 探针，将标记 Pod 为未就绪（unready）。

Readiness 探针

readiness 探针可以让 kubelet 知道应用程序何时准备接受新流量。如果应用程序在进程启动后需要一些时间来初始化状态，要配置 readiness 探针让 Kubernetes 在发送新流量之前进行等待。readiness 探针的主要作用是将流量引导至 service 后的 deployment。
关于 readiness 探针有一点很重要，它会在容器的整个生命周期中运行。这意味着 readiness 探针不仅会在启动时运行，而且还会在 Pod 运行期间反复运行。这是为了处理应用程序暂时不可用的情况（比如加载大量数据、等待外部连接时）。在这种情况下，我们不一定要杀死应用程序，可以等待它恢复。readiness 探针可用于检测这种情况，并在 Pod 再次通过 readiness 检查后，将流量发送到这些 Pod。

Liveness 探针

liveness 探针用于重新启动不健康的容器。Kubelet 会定期地 ping liveness 探针，以确定健康状况，并在 liveness 检查不通过的情况下杀死 Pod。liveness 检查可以帮助应用程序从死锁中恢复。如果不进行 liveness 检查，Kubernetes 会认为死锁中的 Pod 处于健康状态，因为从 Kubernetes 的角度来看，Pod 的子进程仍在运行，是健康的。通过配置 liveness 探针，kubelet 可以检测到应用程序处于不健康状态，并重新启动 Pod 以恢复可用性。

Startup 探针

startup 探针与 readiness 探针类似，但它仅在启动时执行，能针对启动缓慢的容器或在初始化过程中有不可预测行为的应用程序进行优化。借助 readiness 探针，我们可以配置 initialDelaySeconds 来确定 readiness 探测在准备就绪前要等待多长时间。
假设有一个偶尔需要下载大量数据的应用程序，由于 initialDelaySeconds 是一个静态数字，因此该应用程序即使不需要那么长的初始化等待时间，我们也必须设置最保守的等待时间。通过 startup 探针，我们可以配置 failureThreshold 和 periodSeconds 来解决该问题，例如设置 failureThreshold 为 15，periodSeconds 为 5，这意味着应用程序在失败之前会有 10x5=75s 的启动时间。

配置探针

现在我们了解了不同类型的探针，下面是配置每种探针的三种不同方式。
HTTP
kubelet 将 HTTP GET 请求发送到 endpoint，并检查 2xx 或 3xx 响应。我们可以重复使用现有的 HTTP endpoint 或设置轻量级 HTTP 服务器以进行探测（例如，具有 /healthz endpoint 的 Express server）。HTTP 探针包含其他额外参数：
host：要连接的主机名（默认值：pod 的 IP）。
scheme：HTTP（默认）或 HTTPS。
path：HTTP/S 服务器上的路径 。
httpHeaders：自定义标头（如果需要标头用于身份验证、CORS 设置等） 。
port：访问服务器的端口名称或端口号。

TCP

如果仅需要检查是否可以建立 TCP 连接，则可以指定 TCP 探针。如果建立 TCP 连接，则将 Pod 标记为运行状况良好。对于不适合使用 HTTP 探针的 gRPC 或 FTP 服务器，TCP 探针可能会有用。

Command

可以将探针配置为运行 shell 命令。如果命令返回的退出代码为 0，则检查通过，否则 Pod 将被标记为不健康。如果不希望公开 HTTP 服务器与端口，或者希望通过命令检查初始化步骤（例如，检查是否已创建配置文件、运行 CLI 命令），这种类型的探针会很有用。