无状态容器健康检查需精准区分liveness（进程存活）与readiness（服务就绪）语义，为启动慢服务配置startupprobe，选对探测路径（如/health/liveness与/actuator/health/readiness），并按业务延迟调参。

无状态容器的健康检查不是“加个探针就完事”，关键在于让探针真正反映服务是否可服务，而不是进程是否在跑。配置低效往往导致误重启、流量错发或假死不自愈。下面从四个实操维度说清楚怎么做。

区分 liveness 和 readiness 的语义边界

很多故障源于把两个探针当同一个东西用。它们职责完全不同：

• livenessProbe只管“进程还活着吗”——比如 JVM 进程没卡死、主线程没退出、端口没被占满。它不该查数据库、Redis 或外部 API，否则一次网络抖动就触发重启，形成雪崩循环。
• readinessProbe管“现在能接请求吗”——可以包含依赖检查（如 DB 连通性、配置加载完成、缓存预热进度），失败时仅摘流量，不杀容器，给恢复留时间。

为启动慢的服务配 startupProbe

Spring Boot、.NET Core 等应用冷启动常需 30–90 秒。若只靠 liveness + initialDelaySeconds，容易因延迟设短而反复重启，设长又拖慢发布节奏。正确做法是启用 startupProbe：

• 设 initialDelaySeconds: 0，periodSeconds: 15，failureThreshold: 6 → 最多容忍 90 秒启动
• startupProbe 成功后，自动禁用，liveness/readiness 才开始工作
• K8s v1.24+ 支持 startupProbe，Docker Compose v2.20+ 也已支持类似 start_period 机制

选对探测方式和路径，避免副作用

HTTP 探针最常用，但路径设计很关键：

• /health（liveness）：轻量级，只检查进程存活、线程池未耗尽、GC 未长时间 STW。返回 200 即可，不连 DB
• /ready（readiness）：可查连接池状态、下游依赖连通性、本地缓存命中率等。返回 503 表示暂不接流
• 避免用 curl http://localhost:8080/actuator/health 这类默认端点——Spring Boot Actuator 的 /health 默认聚合所有组件，一环挂全挂
• 推荐用 Actuator 的 probes 模块，单独暴露 /actuator/health/liveness 和 /actuator/health/readiness

调参要匹配真实业务节奏

参数不是越严越好，而是要贴合服务响应特征和 SLO 要求：

• timeoutSeconds：设为接口 P95 延迟的 1.5 倍。例如 /health 平均耗时 120ms，设 200ms；别盲目设 1s
• periodSeconds：readiness 可设 3–5s（快速摘流），liveness 建议 10–30s（避免高频误判）
• failureThreshold：liveness 设 3，readiness 设 1 更稳妥——就绪失败应立即摘流，不必等三次
• start_period / initialDelaySeconds：必须大于最大冷启动时间 + 10 秒缓冲。上线前用 docker logs -f 观察真实启动耗时再定值