在Kubernetes中，Pod是Kubernetes创建及管理的最小的可部署的计算单元，一个Pod由一个或者多个容器（Docker，rocket等等）组成，这些容器共享内存，网络以及运行容器的方式。
在Kubernetes上下文中存活探针和就绪探针被称作健康检查。这些容器探针是一些周期性运行的小进程，这些探针返回的结果（成功，失败或者未知）反映了容器在Kubernetes的状态。基于这些结果，Kubernetes会判断如何处理每个容器，以保证弹性，高可用性和更长的正常运行时间。
健康检查是每个分布式系统所必需的！

Kubernetes的健康检查

Kubernetes提供了两种类型的健康检查：就绪探针和存活探针，它们有各自的用途。在这篇文章中我们将会选择：

• /.well-known/live——用于探测HTTP是否存活

• /.well-known/ready——用于探测HTTP是否就绪

简而言之，HTTP探测意味着Kubernetes在特定时间间隔执行HTTP请求/.well-known/live和/.well-known/ready。响应的状态码用于决定需要对Pod执行的操作。如果状态代码在区间[200,300)中，则一切正常。除此以外：

• 如果存活探测器的状态代码是4xx或5xx，则代表Pod已被重启。

• 如果就绪探测器的状态代码是4xx或5xx，那么Pod会被标记为不健康，并且Kubernetes为了提高可靠性和正常运行时间将不会再将HTTP请求转发给它。

如果您的容器独立于任何支持服务，则容器可以具有在同一处理程序上进行存活和就绪检查，并且后面的实践不适用于这种情况。
我们与来自Metro Systems Romania - Site Reliability Team的团队成员一起确定了健康检查的最佳实践列表，并建议应用程序开发人员遵循这些实践。这些最佳实践如下：
1. 存活和就绪的结果处理程序需要是互相独立的程序
如前所述，对于在Kubernetes上下文中部署的每个产品，应该实现2个分别处理HTTP请求“存活”和“就绪”的处理程序。这些探测器的处理程序需要独立实现自己的功能。
2. 不要把“存活/就绪”探针的逻辑与你的程序解耦
这适用于作业处理应用程序。对于Kubernetes，了解应用程序是否正在运行非常重要。如果存活/就绪逻辑被解耦了在新进程中运行，则结果不准确。
3. 不要在“存活”处理程序里实现任何逻辑。如果主线程正在运行，它需要返回状态200，如果不是，则返回5xx
这个探针让Kubernetes知道应用程序是正在运行还是停止运行。通过检查/.well-known/live的状态代码来做出决定，如果应用程序被检测为停止运行，Kubernetes会重新启动Pod。从可靠性的角度来看，如果应用程序的主线程已启动并正在运行，则存活探针的探测的结果为true，否则为false。
在这个上下文中，“逻辑”意味着对互相连接的服务实施某种检查。
4. 在“就绪”探针的处理程序中实现逻辑，以便提供有关应用程序准备情况的详情
就绪探针让Kubernetes知道Pod是否已准备好接收HTTP请求。作为开发人员，在此处实现一些逻辑来检查应用程序的所有后端依赖的可用性非常重要。当实现就绪处理程序时，需要清楚的知道您的应用程序依赖于哪些功能。换句话说，在就绪处理程序里，需要运行所有步骤以保证应用程序已准备好接收和处理https请求，这非常重要。例如，如果应用程序需要建立与数据库的连接以准备处理HTTP请求，那么在“就绪”的处理程序中就必须检查是否已建立与数据库连接并能正常使用。
5. 不要尝试在就绪处理程序上重新建立应用程序的就绪状态。这个探针只是为了检查应用程序是否准备就绪，而不是让应用程序就绪。
我并不建议实现任何让程序重新就绪的逻辑。这些逻辑可能会为系统中的某些组件带来危险。

结论

存活和就绪探针是部署在Kubernetes中的应用程序的核心和灵魂。它们是与虚拟机管理程序通信的标准方式，通过这种方式可以了解虚拟机的状态和问题。存活和就绪探针是开发人员和应用程序必备的强大武器，它确保应用程序的可靠性和弹性。
特别感谢Ionut Ilie。部分内容是他的研究成果以及智慧结晶。
原文链接：https://medium.com/metrosystemsro/kubernetes-readiness-liveliness-probes-best-practices-86c3cd9f0b4a