简介

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

• 启动探针（Startup Probe）
• 存活探针（Liveness Probe）
• 就绪探针（Readiness Probe）

探针功能

启动探针

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

• 延缓其他探针生效： 在容器启动初期，启动探针（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：容器启动（包括pod创建时第一次容器启动、容器oom异常重启、容器liveness探针失败重启等情况）后要等待多少秒后才启动启动、存活和就绪探针。 如果定义了启动探针，则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。 如果 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:   # 启动探针配置也相似

探针检查失败

1. startupProbe检查失败，Pod内的容器会重启且重启次数会加1，pod状态为Running，由于readinessProbe还未介入，Pod实例ip不会加入到service关联的Endpoints中。
   

2. livenessProbe检查失败，Pod内的容器会重启且重启次数会加1，pod状态为Running，service关联的Endpoints资源不会删除Pod实例ip
   

3. readinessProbe检查失败，Pod内的容器不会重启，pod状态为Running，service关联的Endpoints资源会删除不健康Pod实例ip
   

容器异常退出，pod状态才是CrashLoopBackOff，livenessProbe、readinessProbe探针失败，Pod状态仍然是Running

配置建议

1. 如果应用是慢启动类型，建议配置startupProbe，livenessProbe的initialDelaySeconds参数<=readinessProbe的initialDelaySeconds参数，避免livenessProbe过早介入导致容器频繁重启或者业务没有提供服务就开始readness探测。
2. 如果应用启动时间不固定建议使用startupProbe。
3. 可以将startupProbe的initialDelaySeconds、periodSeconds值调低，让startupProbe更快感知容器健康状态；由于startupProbe探测成功后就会退出不会影响容器后续运行，可以将failureThreshold的值调大，避免应用还未启动完成过早触发重启

startupProbe:
  httpGet:
    ...
  initialDelaySeconds: 5
  timeoutSeconds: 3
  periodSeconds: 5
  successThreshold: 1
  failureThreshold: 20

1. 由于livenessProbe探测失败会导致容器重启，建议将livenessProbe的failureThreshold设置比readinessProbe大，这样如果应用有问题应该先切断流量