容器化应用的健康检查：Liveness Probe 与 Readiness Probe

各位观众老爷们，大家好！我是你们的“码农诗人”——代码界的李白，Bug界的杜甫！（掌声在哪里？👏）

今天，咱们不聊风花雪月，不谈人生理想，就来聊聊咱们容器化应用的小日子，哦不，是“健康状况”。容器化应用就像咱们养的宠物，你得知道它吃得好不好，睡得香不香，有没有生病，不然哪天它突然“挂”了，你哭都来不及。

所以，为了避免这种悲剧发生，Kubernetes（K8s）给我们准备了两员大将，专门负责给容器化应用做体检，它们就是：Liveness Probe（存活探针）和 Readiness Probe（就绪探针）。

这哥俩名字听起来高大上，其实干的活儿挺接地气。就像咱们每天早上起来，先看看自己是不是还喘气（Liveness Probe），然后看看自己能不能正常工作（Readiness Probe）。

接下来，我就用幽默风趣（希望如此🤣）的方式，给大家详细讲解一下这两位“健康卫士”。

一、Liveness Probe：证明你还活着！

Liveness Probe，顾名思义，就是用来检查你的容器是不是还“活着”。如果Liveness Probe检测失败，K8s就会毫不留情地重启你的容器。这就像医生发现病人已经脑死亡，直接拔掉呼吸机一样，干脆利落！

那么，Liveness Probe是怎么判断一个容器“死没死”呢？它主要有三种方式：

HTTP GET Probe: 这就像给你的容器发一个“喂，有人吗？”的HTTP请求，如果容器返回200-399的状态码，那就说明它还活着。就像你给朋友发微信，他秒回，那肯定还活着嘛！🎉
TCP Socket Probe: 这种方式更直接，就像直接拨打你的容器的电话号码，如果能建立TCP连接，那就说明它还活着。就像你打电话给客服，电话通了，那说明客服还在上班嘛！📞
Exec Probe: 这种方式最粗暴，就像直接跑到你的容器里面，执行一条命令，如果命令执行成功，返回0，那就说明它还活着。就像警察叔叔直接破门而入，看看你是不是在干坏事！👮

举个栗子：

假设咱们有一个Web应用，端口是8080，咱们可以用HTTP GET Probe来检查它的存活状态。

apiVersion: v1
kind: Pod
metadata:
  name: my-web-app
spec:
  containers:
  - name: my-web-app-container
    image: my-web-app-image
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3   # 容器启动后3秒开始检测
      periodSeconds: 10        # 每隔10秒检测一次

这段YAML配置的意思是：

容器启动后3秒，开始对/healthz路径发起HTTP GET请求，端口是8080。
如果请求返回200-399的状态码，就认为容器还活着。
如果请求失败，或者返回其他状态码，就认为容器已经“挂了”，K8s会重启这个容器。
每隔10秒进行一次检测。

划重点：

initialDelaySeconds: 这个参数很重要，一定要设置一个合适的值，给你的应用足够的启动时间，不然刚启动就被Liveness Probe判定为“死亡”，那就太冤了！
periodSeconds: 这个参数决定了Liveness Probe的检测频率，一般来说，10-30秒比较合适。
/healthz：这个路径需要你的应用提供，用来表示应用的健康状态。如果你的应用没有提供这个路径，那就只能自己实现了。

什么情况下需要使用Liveness Probe？

一般来说，如果你的应用可能会进入一种“假死”状态，比如死锁、内存泄漏等，就需要使用Liveness Probe。这样，K8s才能及时发现并重启你的应用，保证服务的可用性。

二、Readiness Probe：准备好了吗？

Readiness Probe，顾名思义，就是用来检查你的容器是不是“准备好了”，可以接受流量了。如果Readiness Probe检测失败，K8s会将你的容器从Service的Endpoint列表中移除，这意味着你的容器将不会接收到任何新的流量。

这就像餐厅的服务员，如果他还没穿好制服，或者还没熟悉菜单，那肯定不能让他去服务客人，不然会搞砸的！🤦‍♀️

Readiness Probe的检测方式和Liveness Probe一样，也是三种：HTTP GET Probe、TCP Socket Probe、Exec Probe。

举个栗子：

还是以咱们的Web应用为例，假设我们的Web应用需要连接数据库才能正常工作，那么我们可以用Readiness Probe来检查数据库连接是否正常。

apiVersion: v1
kind: Pod
metadata:
  name: my-web-app
spec:
  containers:
  - name: my-web-app-container
    image: my-web-app-image
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 3306 # 假设数据库端口是3306
      initialDelaySeconds: 5
      periodSeconds: 15

这段YAML配置的意思是：

容器启动后5秒，尝试建立与数据库的TCP连接，端口是3306。
如果连接建立成功，就认为容器已经“准备好了”，可以接受流量了。
如果连接建立失败，就认为容器还没有“准备好”，K8s会将它从Service的Endpoint列表中移除。
每隔15秒进行一次检测。

划重点：

Readiness Probe不会重启你的容器，只会将其从Service的Endpoint列表中移除。
initialDelaySeconds也要设置一个合适的值，给你的应用足够的时间去连接数据库。
Readiness Probe的检测频率可以比Liveness Probe低一些，因为“准备好”的状态一般不会频繁变化。

什么情况下需要使用Readiness Probe？

一般来说，如果你的应用需要依赖一些外部服务，比如数据库、缓存等，才能正常工作，就需要使用Readiness Probe。这样，K8s才能保证只有“准备好”的容器才能接收流量，避免用户访问到“半成品”的应用。

三、Liveness Probe vs Readiness Probe：傻傻分不清楚？

很多同学刚接触Liveness Probe和Readiness Probe的时候，很容易把它们搞混。别慌，我来给大家总结一下它们的区别：

特性	Liveness Probe	Readiness Probe
作用	检查容器是否“活着”	检查容器是否“准备好了”
检测失败后果	重启容器	从Service的Endpoint列表中移除
适用场景	应用可能进入“假死”状态	应用需要依赖外部服务才能正常工作
目的	保证服务的可用性	保证用户访问的是“完整”的应用
比喻	检查人是否还活着（呼吸心跳）	检查人是否穿戴整齐，可以接待客人
口头禅	“死了没？没死就再撑一会儿！”	“准备好了吗？没准备好就先歇着！”
影响范围	对容器自身影响（重启）	对整个Service的影响（流量路由）

简单来说，Liveness Probe是“生死判官”，决定你的容器是生是死；Readiness Probe是“门卫”，决定你的容器能不能接待客人。

四、Liveness Probe 和 Readiness Probe 的最佳实践

不要过度使用： 不要把Liveness Probe和Readiness Probe设置得过于严格，否则可能会导致你的应用频繁重启或者被从Service中移除，影响服务的稳定性。
根据实际情况选择检测方式： HTTP GET Probe适合Web应用，TCP Socket Probe适合需要建立TCP连接的应用，Exec Probe适合需要执行一些复杂命令的应用。
提供专门的健康检查接口： 为你的应用提供/healthz、/readyz等专门的健康检查接口，方便Liveness Probe和Readiness Probe进行检测。
监控Liveness Probe和Readiness Probe的状态： 通过监控Liveness Probe和Readiness Probe的状态，可以及时发现应用的问题，并进行处理。
不要让 LivenessProbe 依赖 ReadinessProbe: LivenessProbe 的目的在于当应用确实无法恢复时，重启应用。如果 LivenessProbe 依赖于 ReadinessProbe，那么当应用无法提供服务时，LivenessProbe 也不会触发，导致应用无法自动恢复。
测试！测试！再测试！: 在生产环境部署之前，一定要充分测试你的Liveness Probe和Readiness Probe的配置，确保它们能够正常工作。

五、高级玩法：Startup Probe

除了Liveness Probe和Readiness Probe，K8s还提供了一个“隐藏的大佬”——Startup Probe（启动探针）。

Startup Probe是用来解决应用启动时间过长的问题的。有些应用启动时间很长，如果在启动期间，Liveness Probe和Readiness Probe就开始检测，很可能会误判应用“死亡”或者“未准备好”，导致应用频繁重启或者被从Service中移除。

Startup Probe的作用就是在应用启动期间，禁用Liveness Probe和Readiness Probe，等到Startup Probe检测成功后，再启用Liveness Probe和Readiness Probe。

这就像给你的应用一个“新手保护期”，让它有足够的时间去启动，而不会被误判。👶

举个栗子：

apiVersion: v1
kind: Pod
metadata:
  name: my-web-app
spec:
  containers:
  - name: my-web-app-container
    image: my-web-app-image
    ports:
    - containerPort: 8080
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30  # 允许失败30次
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 60
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /readyz
        port: 8080
      initialDelaySeconds: 60
      periodSeconds: 15

这段YAML配置的意思是：

在应用启动期间，先执行Startup Probe，每隔5秒检测一次/healthz路径，允许失败30次。
如果Startup Probe检测成功，就启用Liveness Probe和Readiness Probe。
如果Startup Probe检测失败超过30次，就认为应用启动失败，K8s会重启这个容器。

划重点：

Startup Probe和Liveness Probe、Readiness Probe可以同时使用，但是Startup Probe会优先执行。
failureThreshold参数很重要，一定要设置一个合适的值，给你的应用足够的启动时间。

六、总结

Liveness Probe、Readiness Probe和Startup Probe是K8s中非常重要的健康检查机制，它们可以帮助我们保证容器化应用的可用性和稳定性。

希望通过今天的讲解，大家能够对这三位“健康卫士”有更深入的了解，并在实际应用中灵活运用它们，让你的容器化应用更加健康、稳定！💪

最后，祝大家：

代码无Bug！
应用永不宕机！
生活充满阳光！ ☀️

谢谢大家！鞠躬！🙇‍♂️

(希望这篇幽默风趣的技术文章能帮助到你！如果觉得不错，请点个赞，转发一下，让更多的人受益！ Thanks! 😊)

发表回复 取消回复

发表回复取消回复