跳到主要内容

Probe 配置速查

本篇汇总 Kubernetes 三种探针（Probe）的区别、四种探测方式和常用参数，以表格为主，写 Deployment 时随手翻查。探针与健康检查接口设计的完整讨论，见第 4 篇《Workload 工作负载》。

三种探针的区别​

探针失败后的动作典型用途常见误用
livenessProbekubelet 按 restartPolicy 重启容器检测死锁、进程假死等「只有重启才能恢复」的故障拿它当 readiness 用：依赖未就绪就失败，容器被反复重启，陷入 CrashLoopBackOff
readinessProbe把 Pod 从 Service 的 Endpoints 中摘掉，不再接流量；恢复后自动加回启动加载、依赖未就绪、过载时临时摘流量与 liveness 用同一个接口：依赖抖动时既摘流量又重启，故障被放大
startupProbe成功之前禁用另外两种探针；连续失败超限才重启容器保护慢启动应用（老 Java 服务、要预加载大量数据的应用）不配它却给 liveness 堆超长 initialDelaySeconds，运行期故障发现变慢
三个探针的生效顺序

配了 startupProbe 后它先跑，成功之前 livenessProbe 和 readinessProbe 一律不生效；startupProbe 成功一次即永久退场，之后整个容器生命周期由 liveness 和 readiness 接管。

liveness 当 readiness 用是最常见的坑

应用在依赖（数据库、下游服务）不可用时，如果让 liveness 接口也返回失败，kubelet 会直接重启容器；依赖没恢复，重启后依旧失败，于是陷入反复重启。判断标准只有一个：这个故障「重启容器能不能恢复」？能，才配进 liveness；不能，走 readiness 摘流量，等依赖恢复。

探测方式​

方式判定成功适用场景关键字段
httpGet返回的 HTTP 状态码在 200–399 之间有 HTTP 端口的应用，首选path、port、scheme、httpHeaders
tcpSocket能建立 TCP 连接数据库、MQ 等没有 HTTP 接口的服务port
exec容器内命令退出码为 0需要自定义判断逻辑（查文件、跑脚本）command
grpcgRPC 健康检查协议返回 SERVINGgRPC 服务，Kubernetes 1.24+ 原生支持port、service

httpGet​

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080        # 数字或容器端口名
    scheme: HTTP      # 默认 HTTP，可改 HTTPS
    httpHeaders:      # 可选，自定义请求头
      - name: X-Probe
        value: kubernetes

tcpSocket​

readinessProbe:
  tcpSocket:
    port: 3306

exec​

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

grpc​

livenessProbe:
  grpc:
    port: 50051
    service: ""    # 可选，留空表示检查整体服务
exec 探针的代价

exec 每次探测都要在容器里起一个新进程，频率高了开销不小；能用 httpGet 或 tcpSocket 解决的就别用 exec。另外 command 直接执行、不经过 shell，需要管道或重定向时自己包一层 sh -c。

参数速查​

参数默认值含义
initialDelaySeconds0容器启动后等多少秒才开始第一次探测；配了 startupProbe 基本就不再需要它
periodSeconds10每隔多少秒探测一次，最小值 1
timeoutSeconds1单次探测多少秒没响应算失败，最小值 1
successThreshold1从失败转成功需要连续成功几次；liveness 和 startup 只能是 1，只有 readiness 能配大于 1
failureThreshold3连续失败几次才判定探针失败（readiness 摘流量 / liveness 与 startup 重启容器），最小值 1
terminationGracePeriodSeconds沿用 Pod 级配置（默认 30）探针级宽限期，1.28 起稳定：liveness 判定失败后给容器多少秒优雅退出再强杀；不配则用 Pod 的同名字段
给慢启动应用算 startup 探针的时长

慢启动应用不要再给 liveness 堆 initialDelaySeconds，改用 startupProbe，按公式配：

failureThreshold × periodSeconds ≥ 最慢启动时间

例如应用最慢 3 分钟（180 秒）才能起来，可配 periodSeconds: 10、failureThreshold: 18，最多容忍 180 秒；启动成功后 startup 探针退场，运行期的假死检测交给参数正常的 liveness。

常见场景配置片段​

Java 慢启动应用（startup 护航）​

spec:
  containers:
    - name: java-app
      image: example/java-app:1.0
      ports:
        - containerPort: 8080
      startupProbe:            # 启动期护航，成功前禁用另两个探针
        httpGet:
          path: /actuator/health
          port: 8080
        periodSeconds: 10
        failureThreshold: 18   # 10 × 18 = 180 秒，覆盖最慢启动时间
      livenessProbe:           # 运行期检测假死，参数保持灵敏
        httpGet:
          path: /actuator/health/liveness
          port: 8080
        periodSeconds: 10
        failureThreshold: 3
      readinessProbe:          # 能接流量才算就绪
        httpGet:
          path: /actuator/health/readiness
          port: 8080
        periodSeconds: 5

滚动发布：只在就绪时摘流量（readiness 单用）​

新副本没就绪就不进 Service、旧副本继续服务，实现「就绪才切流量」；failureThreshold 适当放大，避免瞬时抖动导致流量反复切换。

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3    # 连续 3 次失败（约 15 秒）才摘流量

数据库类重依赖应用：谨慎使用 liveness​

数据库、有状态中间件的「假死」大多重启也救不回来，liveness 触发重启反而可能打断复制、丢数据。常见做法是只配 readiness 摘流量，liveness 不配或只检测真正的进程级死锁。

readinessProbe:
  tcpSocket:
    port: 5432
  periodSeconds: 10
  failureThreshold: 6
# 不配 liveness；要配也只探进程级死锁，并给极保守的 failureThreshold
数据库类服务宁可不探，也别乱探

对 PostgreSQL、MySQL 这类有状态服务，重启一个实例的代价远高于摘几分钟流量。liveness 要么不配，要么用极保守的参数（很长的 failureThreshold、很低的探测频率），并把探活接口与外部依赖完全解耦。