分布式系统很难管理. 一个重要原因是有许多动态部件都为系统运行起作用. 如果一个小部件损坏, 系统必须检测它, 绕过它并修复它. 这一切都需要自动完成!
健康检查 (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 响应, 它会将应用程序标记为健康. 否则它被标记为不健康.
您可以在 此处 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request 阅读有关 HTTP 探针的更多信息.
Command
对于 Command 探针, Kubernetes 则只是在容器内运行命令. 如果命令以退出代码 0 返回, 则容器标记为健康. 否则, 它被标记为不健康. 当您不能或不想运行 HTTP 服务时, 此类型的探针则很有用, 但是必须是运行可以检查您的应用程序是否健康的命令.
您可以在 此处 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command 阅读有关 Command 探针的更多信息.
TCP
最后一种类型的探针是 TCP 探针, Kubernetes 尝试在指定端口上建立 TCP 连接. 如果它可以建立连接, 则容器被认为是健康的; 否则被认为是不健康的.
如果您有 HTTP 探针或 Command 探针不能正常工作的情况, TCP 探测器会派上用场. 例如, gRPC 或 FTP 服务是此类探测的主要候选者.
您可以在 此处 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-tcp-liveness-probe 阅读有关 TCP 探针的更多信息.
配置探针的初始化延迟时间
可以通过多种方式配置探针. 您可以指定它们应该运行的频率, 成功和失败阈值是什么, 以及等待响应的时间. 有关 配置探针的文档 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes 非常清楚地介绍了其不同的选项及功能.
但是, 使用 liveness 探针时需要配置一个非常重要的设置, 就是 initialDelaySeconds 设置.
如上所述, liveness 探针失败会导致 pod 重新启动. 在应用程序准备好之前, 您需要确保探针不会启动. 否则, 应用程序将不断重启, 永远不会准备好!
我建议使用 p99 延迟 https://www.quora.com/What-is-p99-latency 启动时间作为 initialDelaySeconds, 或者只是取平均启动时间并添加一个缓冲区. 随着您应用的启动时间变得越来越快, 请确保更新这个数值.
结论
大多数人会告诉你健康检查是分布式系统的基本要求, Kubernetes 也不例外. 使用健康检查为您的 Kubernetes 服务奠定了坚实的基础, 更好的可靠性和更长的正常运行时间. 值得庆幸的是, Kubernetes 让您轻松做到这些!
来源: http://www.tuicool.com/articles/rUzIVjZ