神刀安全网

使用Kubernetes健康检查

文章由才云科技翻译,如若转载,必须注明转载自“才云科技”。查看原文请点击“原文链接”。

这篇文章我们来聊Kubernetes的健康检查,以及不同健康检查是如何影响你的应用程序的。

Liveness Probes

Kubernetes健康检查被分成 liveness和readiness probes。liveness probes是用来检测你的应用程序是否正在运行。通常情况下,你的程序一崩溃,Kubernetes就会看到这个程序已经终止,然后重启这个程序。但是liveness probes的目的就是捕捉到当程序还没有终止,还没有崩溃或者还没陷入死锁的情况。所以一个简单的HTTP回应能够满足。

以下是一个我使用的为Go应用程序使用健康检查的例子。

使用Kubernetes健康检查

在配置中

使用Kubernetes健康检查

上图就是告诉Kubernetes,应用程序正在运行。initialDelaySeconds 告诉Kubernetes在看到pod启动之后要延迟开启健康检查,并说清楚延迟几秒。如果你的应用程序需要一些时间来启动,你可以用这个设置来帮助它。timeoutSeconds会告诉Kubernetes应该为健康检查等待多长时间。对于liveness probes,这个时间不能太长,但是万一有欠载的情况,你就真的需要给你的应用足够的时间来回应。

如果应用程序从未启动,或者回应过来一个HTTP错误代码,那么之后Kubernetes就会重新启动pod。你最好不要在liveness probes中进行太炫酷的什么动作,想都不要想,因为一旦liveness probes功能开始失效的话,这会引起你的应用程序错误。

Readiness Probes

Readiness Probes跟liveness probes十分相似,只有失效检测的结果是不一样的。Readiness Probes是用来检查你的应用程序是否可以为通信服务。这跟liveness有些微妙的不同。比如,你的应用程序取决于数据库与memcached。如果上面两个都在良好状态,为你的应用提供通信,然后你就可以说这两个都是你的应用的“readiness”。

如果你的应用的readness probe运行失败,那么pod就会从组成service的端点被删除。这样的话,没有准备好的pods就不会有流量通信通过Kubernetes服务发现机制来发送给他们。当遇到service的新pod启动时;拓展events时,滚动更新等状态的时候,这个状态十分有帮助。Readiness probes确认在pods开启的时候pods没有被发通信,还有他们处于待服务通信的时候也没有。

Readiness probe的定义跟liveness probes的定义一样。Readiness probes被定义为Deployment的一部分,比如像这样:

使用Kubernetes健康检查

你是不是想要检验一下是否可以在你的readiness probe中连接到你的应用程序的依赖。以我们依赖数据库为例,我们想要检查我们是否能够连接到两者。

情况看起来应该是这样的(下图所示)。我检查memcached和数据库,如果有一个不可得,那么我就会回复一个503回应状态。

使用Kubernetes健康检查

更稳定的应用程序

Liveness和Readiness probes对增加应用程序的稳定性很有帮助。他们帮助确认通信是否只流通到为它准备的实例上,当应用变得无反应的时候,自我治愈也是一样。他们就是我同事所说的叫做“12 Fractured Apps”的更好的解决方法。有了合适的健康检查,你就能够以任意顺序配置你的应用程序,不需要担心相关性或者复杂的进入点脚本。当应用程序准备好的时候,他们会开始服务通信,所以自动调度和滚动更新运行得十分顺利。

文章由才云科技翻译,如若转载,必须注明转载自“才云科技”。查看原文请点击“原文链接”。

使用Kubernetes健康检查

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 使用Kubernetes健康检查

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址