容器探针的三种类型介绍

简介

容器探针（Container Probes）是一种机制，由 kubelet 对容器执行定期的探查，从而获取容器的状态。探针的类型有三种：

启动探针（Startup Probe）

存活探针（Liveness Probe）

就绪探针（Readiness Probe）

探针功能

启动探针

启动探针（StartupProbe）主要用于检测容器内的应用是否已经成功启动并完成初始化任务。它的主要作用有以下几点：

延缓其他探针生效：在容器启动初期，启动探针先于存活探针（LivenessProbe）和就绪探针（ReadinessProbe）生效。当启动探针配置存在时，kubelet 不会执行存活和就绪探针，直到启动探针成功为止。这对于某些启动时间较长或者启动过程中有复杂初始化序列的应用程序来说非常重要，可以避免在应用还未完全启动时就被误判为不健康或就绪，进而被错误地重启或流量过早涌入。

防止频繁重启：若应用启动期间，存活探针或就绪探针就开始工作，而此时应用可能还没有完全启动成功，这两个探针可能会因为应用未能及时响应而触发容器重启，造成不必要的服务中断和循环重启。启动探针的存在可以有效地防止此类情况的发生。

存活探针

存活探针（Liveness Probe）主要作用是检测容器内主进程或服务是否仍然运行正常且响应健康检查。具体来说：

自动恢复：当存活探针检测失败时，kubelet 将认为该容器内的主进程已经不再健康或者已停止提供预期的服务。此时，kubelet 会根据 Pod 的重启策略来决定是否应该重新启动这个容器。通过这种方式，存活探针可以帮助实现故障自愈，及时恢复服务的可用性。

就绪探针

就绪探针（Readiness Probe）主要作用是检测容器是否已经准备好对外提供服务。具体来说：

流量路由控制：当就绪探针成功时，表示该容器内部的应用程序已处于可接受请求的状态，此时 kubelet 会将该容器标记为“就绪”状态，Service 将会将其 IP 地址添加到后端服务列表中，允许 Service 开始将网络流量转发至这个 Pod。

避免无效请求：如果就绪探针失败，则意味着容器可能还在启动过程中、正在重启服务、或者由于某种原因暂时无法正常响应请求。在这种情况下，kubelet 会将容器从 Service 的后端池中移除，确保不会向其发送任何用户请求，从而避免了因应用未准备完毕而引起的错误响应和用户体验下降。

平滑过渡：通过就绪探针，Kubernetes 可以实现滚动更新或部署过程中的平滑过渡，新版本的容器在通过就绪探针验证前，不会承担任何实际流量，直到它们完全启动并做好处理请求的准备。

探针方式

探针实现方式有三种：

HTTP GET请求：Kubernetes 通过向容器内应用发送一个HTTP GET请求来检查应用的状态。如果收到的 HTTP 响应码在 200-399 范围内，则认为该探测成功。

livenessProbe:   #可指定其他两种探针类型
  httpGet:     #指定探针方式
    path: /healthz   #http请求路径
    port: 8080      #请求端口
    httpHeaders: # 可选，用于设置自定义HTTP头部
    - name: Custom-Header
      value: huawei

TCP Socket检查：Kubernetes 尝试与容器上指定的端口建立 TCP 连接。如果能够成功建立连接，则说明探测成功。

livenessProbe:
  tcpSocket:
    port: 8080

exec执行命令：在容器内部执行一个命令，并根据命令退出时返回的状态码判断容器是否正常运行。通常情况下，如果命令返回 0，则表示成功。

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/health

启动探针、存活探针和就绪探针同时支持这三种方式。每种探针可以选择不同探测方式

探针配置参数

Kubernetes中的探针都支持一些通用的参数来定义它们的行为。以下是这些探针通常使用的配置参数：

initialDelaySeconds：容器启动后要等待多少秒后才启动启动、存活和就绪探针。如果定义了启动探针，则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。如果 periodSeconds 的值大于 initialDelaySeconds，则 initialDelaySeconds 将被忽略。默认是 0 秒，最小值是 0。

periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。

timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。

successThreshold：探针在失败后，被视为成功的最小连续成功数。默认值是 1。存活和启动探针的这个值必须是 1。

failureThreshold：探针连续失败了 failureThreshold 次之后， Kubernetes 认为总体上检查已失败：容器状态未就绪、不健康、不活跃。对于启动探针或存活探针而言，如果至少有 failureThreshold 个探针已失败， Kubernetes 会将容器视为不健康并为这个特定的容器触发重启操作。kubelet 遵循该容器的terminationGracePeriodSeconds 设置。

terminationGracePeriodSeconds：k8s1.25以上版本新增，为 kubelet 配置从为失败的容器触发终止操作到强制容器运行时停止该容器之前等待的宽限时长。默认值是继承 Pod 级别的 terminationGracePeriodSeconds 值（如果不设置则为 30 秒），最小值为 1。就绪探针不需要配置该参数

完整配置示例：

livenessProbe:
  #可以选择 httpGet、tcpSocket 或 exec 中的一种
  httpGet:
    path: /health
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: huawei
  #通用参数：
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3
  terminationGracePeriodSeconds: 30


readinessProbe: # 就绪探针配置类似
startupProbe:   # 启动探针配置也相似

配置建议

如果应用是慢启动类型，建议配置启动探针或者为存活探针配置initialDelaySeconds参数，避免存活探针过早介入导致容器频繁重启。如果应用启动时间不固定建议使用启动探针。

可以将启动探针initialDelaySeconds、periodSeconds的值调低，让启动探针更快感知容器健康状态；由于启动探针探测成功后就会退出不会影响容器后续运行，可以将failureThreshold的值调大，避免应用还未启动完成过早触发重启

由于存活探针探测失败会导致容器重启，因此将存活探针的failureThreshold设置比就绪探针大，这样如果应用有问题应该先切断流量

审核编辑：黄飞