3.2.3 健康检查
readiness
kubelet 使用就绪探测器可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。有时候，应用会暂时性地无法为请求提供服务。 例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 在这种情况下，应用是无法承载相关业务流量的。Kubernetes 提供了就绪探测器来发现并缓解这些情况。即设置合理的就绪探针policy，让业务应用在完全启动之后，才加入到service的后端中承载业务流量。 就绪探测器在容器的整个生命周期中保持运行状态 ，合理的就绪设置，对于应用的平滑部署和滚动更新至关重要：
a. 目前探针类型主要是EXEC， TCP和HTTP（1.24版本中会加入grpc）：如果业务是HTTP协议暴露的端口，建议探针类型选择HTTP，很多部署情况下会使用TCP探针，这种情况下存在四层监听就绪，但是七层业务还未启动的情况，可能会让业务状态未ok的pod被加到svc的后段，承载业务，进而引发业务超时或者5xx。
b.合理设置successThreshold、failureThreshold和timeoutSeconds对于pod能否平稳的提供业务应用非常重要。timeoutSeconds设置太小，比如 1ms等，这样的含义是探针1ms内没有得到回复，就认为探针失败，failure次数增加一次，这样很容易增加pod达到被判定失败的阈值，从而被从svc中移除后端，对于success来说，反之亦然。
liveness
kubelet 使用存活探测器来确定什么时候要重启容器。 例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。根据这个探针的行为，当探测失败达到阈值时候时候，会杀死重启容器。
a. liveness探针和readiness探针是同时启动的，所以不合理的liveness设置，可能会造成容器内应用还未完全启动时候，就被liveness探针探测失败而kill，就会引起pod一直处于不停的重启过程中，所以需要合理的设置initialDelaySeconds以实现pod内的应用完全read后，再执行liveness探针探测，或者可以设置startup探针。
b.合理设置successThreshold、failureThreshold和timeoutSeconds对于pod能否平稳的提供业务应用非常重要。timeoutSeconds设置太小，比如 1ms等，这样的含义是探针1ms内没有得到回复，就认为探针失败，failure次数增加一次，这样很容易增加pod达到被判定失败的阈值，从而被kill，对于success来说，反之亦然。
c.建议liveness探针和readiness 采用相同的探测方法和策略，否则liveness探测失败达到阈值，但是readiness 没有达到，这时候pod会马上收到SIGKILL 的信号，但是其实还是在SVC的后端中，这时候就需要考虑应用的滚动更新的情况了。
startupprobe
有时候，会有一些现有的应用在启动时需要较长的初始化时间。 这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间。一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 restartPolicy 来 执行进一步处置。
