Kubernetes最佳实践S01E03:Kubernetes集群健康检查最佳实践

  1. 云栖社区>
  2. 博客>
  3. 正文

Kubernetes最佳实践S01E03:Kubernetes集群健康检查最佳实践

店家小二 2018-12-18 21:42:00 浏览997
展开阅读全文
今天是Google Developer Advocate Sandeep Dinesh关于如何充分利用Kubernetes环境的七部分视频和博客系列的第三部分。

分布式系统很难管理。 一个重要原因是有许多动态部件都为系统运行起作用。 如果一个小部件损坏,系统必须检测它,绕过它并修复它。 这一切都需要自动完成!

健康检查(Health Check)是让系统知道您的应用实例是否正常工作的简单方法。 如果您的应用实例不再工作,则其他服务不应访问该应用或向其发送请求。 相反,应该将请求发送到已准备好的应用程序实例,或稍后重试。 系统还应该能够使您的应用程序恢复健康状态。


默认情况下,当Pod中的所有容器启动时,Kubernetes开始向Pod发送流量,并在崩溃时重新启动容器。 虽然这在开始时可以“足够好”,但您还可以通过创建自定义运行状况检查来使部署更加健壮。 幸运的是,Kubernetes使这个相对简单,所以没有理由不去这么干!


在本期Kubernetes最佳实践中,让我们了解readinessliveness探针的细节,何时使用哪种探针,以及如何在Kubernetes集群中进行设置。

健康检查的类型

Kubernetes为您提供两种类型的健康检查,了解两者之间的差异及其用途非常重要。

Readiness

Readiness探针旨在让Kubernetes知道您的应用何时准备好其流量服务。 Kubernetes确保Readiness探针检测通过,然后允许服务将流量发送到Pod。 如果Readiness探针开始失败,Kubernetes将停止向该容器发送流量,直到它通过。

Liveness

Liveness探针让Kubernetes知道你的应用程序是活着还是死了。 如果你的应用程序还活着,那么Kubernetes就不管它了。 如果你的应用程序已经死了,Kubernetes将删除Pod并启动一个新的替换它。

健康检查是如何提供帮助的?

让我们看看两个场景,Readiness探针和Liveness探针可以帮助您构建鲁棒性更强的应用程序。

Readiness

让我们假设您的应用需要一分钟的时间来预热并开始。 即使该过程已启动,您的服务在启动并运行之前也无法运行。 如果要将此部署扩展为具有多个副本,也会出现问题。 新副本在完全就绪之前不应接收流量,但默认情况下,Kubernetes会在容器内的进程启动后立即开始发送流量。 通过使用Readiness探针,Kubernetes等待应用程序完全启动,然后才允许服务将流量发送到新副本。
1.gif

Liveness

让我们假设另一种情况,你的应用程序有一个令人讨厌的死锁情况,导致它无限期挂起并停止提供请求服务。 因为该服务还在运行,默认情况下Kubernetes认为一切正常并继续向已经broken的Pod发送请求。 通过使用Liveness探针,Kubernetes会检测到应用程序不再提供请求并重新启动有问题的Pod。
2.gif

探针类型

下一步是定义测试ReadinessLiveness的探针。 有三种类型的探测:HTTP、Command和TCP。 您可以使用它们中的任何一个进行LivenessReadiness检查。

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集群健康检查最佳实践

网友评论

登录后评论
0/500
评论
店家小二
+ 关注