深入探索Kubernetes探针：构建健壯的容器化应用

近日见闻

Kubernetes v1.29 发布，这是 2023 年的最后一个版本。该版本包含 49 项增强功能。其中 11 项已升级到稳定版，19 项进入 Beta 版，19 项升级到 Alpha 版。发布速度太快了，还停留在1.1x的朋友应该不少吧，这已经2字头末尾了。马上奔3了，抓紧学起来！
CNCF 首个云原生多云容器编排项目 Karmada 正式晋级孵化。
最近和读者朋友聊天，聊起写文章无法带来收益的问题，确实，我这种小博主写文章基本没什么收益，所以开了文中广告，请大家见谅（虽然只有几毛收益）。目前写文章就是我的业余爱好，只是在不断努力提升文章内容质量。读者建议卖课程，IT 尽头是卖课（这是一个梗）。尽管我有当老师的经历，但讲课和讲好课不是一回事。所以大家可以和我交流下自己的看法，在运维开发领域那些知识是比较关注的呢，近期会努力准备出课程，提前预约的朋友可以得到最优惠的价格！大致就以下名片里的四部分。

k8s健康检查入门

先看看官网关于配置健康探针文档，在配置pods和容器这一栏里：

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Kubernetes（K8s）中的健康检查是用于监视运行在Pods中的容器是否健康并且按预期工作。这些检查能够确定何时应该重启一个容器（如果它不再工作），何时不应该向其发送流量（如果它未准备好或者处于非健康状态），以及何时一个容器已经成功启动。健康检查对于保持应用的高可用性和可靠性至关重要。

健康检查的方式

Kubernetes 提供三种类型的健康检查，官网说是探测类型：

存活探针（Liveness Probe）这种探针的目的是判断容器是否还在运行。如果存活探针检查失败，意味着容器无法继续运行，因此Kubernetes会采取措施重启该容器。官网解释：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器，并且容器将根据其重启策略决定未来。如果容器不提供存活探针，则默认状态为 Success。[1]
就绪探针（Readiness Probe）就绪探针用于判断容器是否准备好对外服务，即是否能够处理新的请求。如果就绪探针检查失败，Kubernetes会认为容器不应该接收任何流量。此时，负载均衡器会停止向该容器发送请求。官网解释：指示容器是否准备好为请求提供服务。如果就绪态探测失败，端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。初始延迟之前的就绪态的状态值默认为 Failure。如果容器不提供就绪态探针，则默认状态为 Success。
启动探针（Startup Probe）启动探针是用来检测应用程序是否已经启动完毕。如果设置了启动探针，直到它成功为止，否则存活和就绪探针的检查将不会进行。官方解释：指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。如果容器没有提供启动探测，则默认状态为 Success。

探针的检查方式

每种探针都可以通过以下四种方式之一来进行检查：

HTTP GET这种方式会向容器的IP地址的指定端口和路径发送HTTP GET请求。如果返回的状态码在200到399之间，则认为探针成功。
TCP Socket通过尝试对容器的IP地址上的指定端口打开TCP连接来完成。如果能够建立连接，则认为探针成功。
Exec这种方式会在容器内部执行指定的命令。如果命令执行返回状态码为0，则认为探针成功。

这三种方式是我们常用的三种探针方式，也是k8s-1.23版本之前使用的，然而Kubernetes 1.23版本中引入了对gRPC探针的支持，为gRPC应用程序提供了更原生的健康检查方式。

GRPCgRPC探针允许kubelet通过gRPC来执行健康检查。这是特别适用于提供gRPC接口的应用程序。gRPC探针利用GRPC的健康检查协议，通过gRPC调用来判断服务的健康状态。

官网解释：使用 gRPC 执行一个远程过程调用。目标应该实现 gRPC 健康检查。如果响应的状态是 "SERVING"，则认为诊断成功。

探测结果

每次探测都将获得以下三种结果之一：

Success（成功）容器通过了诊断。

Failure（失败）容器未通过诊断。

Unknown（未知）诊断失败，因此不会采取任何行动。

探针的配置

根据以上介绍，来看一下集合了三种健康检查类型的四种探针方式的配置，帮助大家一次性理清。

代码语言：javascript复制

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp:1.0
    ports:
    - containerPort: 8080
    # 存活探针配置
    livenessProbe:
      httpGet: # 使用HTTP GET请求进行存活检查
        path: /healthz # 检查的路径
        port: 8080 # 容器服的务端口
      initialDelaySeconds: 15 # 容器启动后延迟15秒开始首次探测
      periodSeconds: 20 # 每20秒探测一次
      
    # 就绪探针配置
    readinessProbe:
      tcpSocket: # 使用TCP Socket进行就绪检查
        port: 8080 # 容器的服务端口
      initialDelaySeconds: 5 # 容器启动后延迟5秒开始首次探测
      periodSeconds: 10 # 每10秒探测一次
      
    # 启动探针配置
    startupProbe:
      exec: # 使用容器内命令执行进行启动检查
        command: # 执行的命令
        - cat
        - /app/is_started
      initialDelaySeconds: 10 # 容器启动后延迟10秒开始首次探测
      periodSeconds: 5 # 每5秒探测一次
      failureThreshold: 10 # 在确定初始失败之前的最小连续失败次数
      
    # gRPC探针配置 (需要Kubernetes 1.23或以上版本)
    livenessProbe:
      grpc: # 使用gRPC进行存活检查
        port: 50051 # 容器的gRPC服务端口
      initialDelaySeconds: 15 # 容器启动后延迟15秒开始首次探测
      periodSeconds: 20 # 每20秒探测一次

每个探针配置的具体参数：

initialDelaySeconds 表示在容器启动后延迟多少秒开始首次探测。
periodSeconds 表示探测的频率，每隔多少秒探测一次。
failureThreshold 表示在认定探针失败之前，探针需要连续失败的最小次数。
httpGet, tcpSocket, exec 和 grpc 分别表示不同的探针检查方式。

注意：使用 gRPC 探针时，Kubernetes 集群版本至少需要是 1.23 或以上，而且你的应用程序需要实现 gRPC 健康检查协议。

总结

健康检查是Kubernetes自动故障恢复和负载均衡的重要组成部分。合理配置和使用存活探针、就绪探针和启动探针可以保证应用程序的稳定性和可靠性。每种探针都应该根据容器的具体行为和需求来配置，以确保它们能够正确地反映出容器的健康状况。

嗯，通过以上介绍，各位读者应该有所了解了吧，后期我也会不断实践总结，分享给大家，记得关注呀！

参考资料

[1]

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes: livenessprobe

容器 kubernetes 负载均衡服务配置

0 人点赞