K8s中服务健康检查规范-多探针

K8s中的三种探针

策略参数含义

三种探针策略参数一致，只是作用方式不同：

• initialDelaySeconds（初始延迟时间）：探针启动前的等待时间。在容器启动后的指定时间内，探针将不会执行。默认值为0。
• timeoutSeconds（超时时间）：探测请求的超时时间。如果在指定时间内未收到响应，则认为探测失败。默认值为1。
• periodSeconds（探测间隔时间）：探测器执行的周期时间。即每隔多长时间进行一次探测。默认值为10。
• successThreshold（成功阈值）：连续成功的探测次数，达到该次数后探测器将被认为是成功的。默认值为1。
• failureThreshold（失败阈值）：连续失败的探测次数，达到该次数后探测器将被认为是失败的。默认值为3。

一、三种探针策略

1. 启动探针

用来给就绪、存活探针做缓冲，占用应用启动前期的时间。

启动探针最长允许时间15 + (10 * 30) = 315s，约5分钟，能覆盖大部分应用：

• 315秒内，一旦tcp端口监听，则启动探测终止，转用就绪、存活探针探测。
• 超过315秒，tcp端口还未监听，pod重启，触发报警。

# tcpSocket
startupProbe:
  tcpSocket:
    port: {{.Env.CMP_PORT}}
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 30

2. 就绪探针（仅HTTP应用）

i. HTTP应用

启动探针承载了启动开始的5分钟探测，因此就绪探针时间可以缩短。

就绪检查最长允许时间10 + (10 * 5) = 60s，约1分钟，加上启动探针共6分钟，可以满足大部分应用启动时间。

# httpGet
readinessProbe:
  httpGet:
    path: /statusCheck
    port: {{.Env.CMP_CHECK_PORT}}
    scheme: HTTP
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 5

ii. 非HTTP应用

不涉及Service层的流量控制，不配置就绪探针。

3. 存活探针

存活探针配置不合理会导致反复重启，业务高峰期风险较大，因此策略不应太敏感。

应尽量避免TCP端口探测，建议用HTTP或RPC接口探测。

i. HTTP探测

存活检查最长允许时间10 + (10 * 15) = 160s，约2.5分钟，加上启动探针共约8分钟，足够大部分应用启动完成。

# httpGet
livenessProbe:
  httpGet:
    path: /statusCheck
    port: {{.Env.CMP_CHECK_PORT}}
    scheme: HTTP
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 15

ii. RPC探测

从1.18版本开始支持，目前支持配置的功能不完善，建议从1.24版本开始使用，将提供更好用的grpc探测机制。

官方文档

二、健康检查配置规范

整改方式

• 探测方式按原有方式（tcp/http），多个探针的探测方式保持一致。
• 探针按如下配置（http三个探针，非http两个探针）。
• 探针时间参数严格按如下配置。

1. HTTP接口应用

启动探针、就绪探针、存活探针

startupProbe:
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 30
readinessProbe:
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 5
livenessProbe:
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 15

2. TCP/RPC应用

启动探针、存活探针

startupProbe:
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 30
livenessProbe:
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 15

三、启动检测时间过长的问题

1. Pod初始创建

• 慢启动应用：Pod用尽启动探针最大时间探测不通过，则HTTP/TCP/RPC应用最长使用5分钟的启动时间，超过5分钟后触发重启。
• 快启动应用：最快启动时间（启动延迟 + 就绪/存活延迟）15 + 30 = 45秒即可完成启动。

2. Pod运行过程中

HTTP应用：

• 异常达到40-50秒（间隔10秒连续5次），即阻断从Service流入的流量。
• 异常达到140-150秒（间隔10秒连续15次），即触发Pod重启。

TCP/RPC应用：

• 异常达到140-150秒（间隔10秒连续15次），即触发Pod重启。

四、容器探活策略现状

1. 现状

• 统一使用单个就绪探针做健康检查。

2. 解决了哪些问题

• 就绪更多是解决nginx流量截断的功能，对dubbo服务而言存活探针作用更大。
• 启动探针的加入，可以覆盖慢启动的时间，这样就绪、存活探针的失败次数就可以更小更合理。
• 存活探针的加入，实现真正的异常重启，对服务内部异常情况的处理更有效。

3. 需要注意

• 启动+存活探针确保覆盖所有应用的启动时间，避免发布即重启的情况发生。
• 存活探针时长 > 就绪探针时长。

五、推进计划

1. 各业务线服务按现有就绪探针配置，统一改成文档中的配置（http/非http应用有区别）

• 时间：1-2周时间完成配置。
• 操作：运维侧修改模板，等研发迭代生效。
• 三种探针策略配置相同即可。
• 探针时间参数按新的文档参数配置，探测接口按现有的配置。

2. 推进研发侧http接口、rpc服务接口的支持

• 操作：运维侧提供接口代码文档，等研发完成后运维侧协助上线。