今天是Google Developer Advocate Sandeep Dinesh关于如何充分利用Kubernetes环境的七部分视频和博客系列的第三部分。分布式系统很难管理。 一个重要原因是有许多动态部件都为系统运行起作用。 如果一个小部件损坏，系统必须检测它，绕过它并修复它。 这一切都需要自动完成！健康检查（Health Check）是让系统知道您的应用实例是否正常工作的简单方法。 如果您的应用实例不再工作，则其他服务不应访问该应用或向其发送请求。 相反，应该将请求发送到已准备好的应用程序实例，或稍后重试。 系统还应该能够使您的应用程序恢复健康状态。
默认情况下，当Pod中的所有容器启动时，Kubernetes开始向Pod发送流量，并在崩溃时重新启动容器。 虽然这在开始时可以“足够好”，但您还可以通过创建自定义运行状况检查来使部署更加健壮。 幸运的是，Kubernetes使这个相对简单，所以没有理由不去这么干！
在本期Kubernetes最佳实践中，让我们了解readiness和liveness探针的细节，何时使用哪种探针，以及如何在Kubernetes集群中进行设置。健康检查的类型
Kubernetes为您提供两种类型的健康检查，了解两者之间的差异及其用途非常重要。Readiness
Readiness探针旨在让Kubernetes知道您的应用何时准备好其流量服务。 Kubernetes确保Readiness探针检测通过，然后允许服务将流量发送到Pod。 如果Readiness探针开始失败，Kubernetes将停止向该容器发送流量，直到它通过。Liveness
Liveness探针让Kubernetes知道你的应用程序是活着还是死了。 如果你的应用程序还活着，那么Kubernetes就不管它了。 如果你的应用程序已经死了，Kubernetes将删除Pod并启动一个新的替换它。健康检查是如何提供帮助的？
让我们看看两个场景，Readiness探针和Liveness探针可以帮助您构建鲁棒性更强的应用程序。Readiness
让我们假设您的应用需要一分钟的时间来预热并开始。 即使该过程已启动，您的服务在启动并运行之前也无法运行。 如果要将此部署扩展为具有多个副本，也会出现问题。 新副本在完全就绪之前不应接收流量，但默认情况下，Kubernetes会在容器内的进程启动后立即开始发送流量。 通过使用Readiness探针，Kubernetes等待应用程序完全启动，然后才允许服务将流量发送到新副本。
Liveness
让我们假设另一种情况，你的应用程序有一个令人讨厌的死锁情况，导致它无限期挂起并停止提供请求服务。 因为该服务还在运行，默认情况下Kubernetes认为一切正常并继续向已经broken的Pod发送请求。 通过使用Liveness探针，Kubernetes会检测到应用程序不再提供请求并重新启动有问题的Pod。
探针类型
下一步是定义测试Readiness和Liveness的探针。 有三种类型的探测：HTTP、Command和TCP。 您可以使用它们中的任何一个进行Liveness和Readiness检查。HTTP
HTTP探针可能是最常见的自定义Liveness探针类型。 即使您的应用程序不是HTTP服务，您也可以在应用程序内创建轻量级HTTP服务以响应Liveness探针。 Kubernetes去ping一个路径，如果它得到的是200或300范围内的HTTP响应，它会将应用程序标记为健康。 否则它被标记为不健康。您可以在此处阅读有关HTTP探针的更多信息。Command
对于Command探针，Kubernetes则只是在容器内运行命令。 如果命令以退出代码0返回，则容器标记为健康。 否则，它被标记为不健康。 当您不能或不想运行HTTP服务时，此类型的探针则很有用，但是必须是运行可以检查您的应用程序是否健康的命令。您可以在此处阅读有关Command探针的更多信息。TCP
最后一种类型的探针是TCP探针，Kubernetes尝试在指定端口上建立TCP连接。 如果它可以建立连接，则容器被认为是健康的；否则被认为是不健康的。如果您有HTTP探针或Command探针不能正常工作的情况，TCP探测器会派上用场。 例如，gRPC或FTP服务是此类探测的主要候选者。您可以在此处阅读有关TCP探针的更多信息。配置探针的初始化延迟时间
可以通过多种方式配置探针。 您可以指定它们应该运行的频率，成功和失败阈值是什么，以及等待响应的时间。 有关配置探针的文档非常清楚地介绍了其不同的选项及功能。但是，使用Liveness探针时需要配置一个非常重要的设置，就是initialDelaySeconds设置。如上所述，Liveness探针失败会导致Pod重新启动。 在应用程序准备好之前，您需要确保探针不会启动。 否则，应用程序将不断重启，永远不会准备好！我建议使用p99延迟启动时间作为initialDelaySeconds，或者只是取平均启动时间并添加一个缓冲区。 随着您应用的启动时间变得越来越快，请确保更新这个数值。结论
大多数人会告诉你健康检查是分布式系统的基本要求，Kubernetes也不例外。 使用健康检查为您的Kubernetes服务奠定了坚实的基础，更好的可靠性和更长的正常运行时间。 值得庆幸的是，Kubernetes让您轻松做到这些！
本文转自DockOne-Kubernetes最佳实践S01E03：Kubernetes集群健康检查最佳实践
