K8s Liveness与Readiness探针保障微服务滚动更新

在 Kubernetes 微服务滚动更新中，Liveness 和 Readiness 探针配置不当是导致流量中断、服务雪崩和更新失败的隐形元凶——Readiness 探针若未真实反映业务就绪（如忽略数据库/Redis 连通性、initialDelaySeconds 设置过短），会令流量过早涌入尚未初始化完成的新 Pod；Liveness 探针若复用重依赖路径或探测过于激进，则可能在 GC 或 IO 延迟时误杀健康实例；而 Startup Probe 则是应对 Java/.NET 等慢启动应用的关键补救机制，配合合理的 terminationGracePeriodSeconds、maxUnavailable 和 timeoutSeconds 调优，才能真正实现平滑、零感知的滚动更新。

滚动更新时 Pod 还没就绪，流量就打过去了？

这是最常见的滚动更新失败场景：新 Pod 启动后，readinessProbe 没配或配得太激进（比如 initialDelaySeconds 太小、failureThreshold 太低），导致 kubelet 误判容器已就绪，Service 立即把流量导过去——而此时 Spring Boot 还在加载上下文、Golang 的 gRPC server 还没 bind 完端口、数据库连接池也未初始化完毕。

关键不是“有没有探针”，而是 readiness 探针是否真实反映「能处理业务请求」这一状态。例如：

• /actuator/health 默认返回 UP 并不等于应用所有依赖（DB、Redis、下游服务）都连通了；建议用 /actuator/health/show-details=always 或自定义 HealthIndicator 加入关键依赖检查
• Golang HTTP 服务若只监听 /healthz 且只返回 200 OK，但没校验 DB ping，依然会过早就绪
• Java 应用启动慢，initialDelaySeconds: 10 常常不够，应结合 JVM 启动日志实测，设为 60–120 秒更稳妥

Liveness 探针把健康 Pod 频繁重启？

错误的 livenessProbe 是滚动更新中隐形的雪崩推手。它本该用于捕获死锁、线程卡死等不可恢复故障，但很多人直接复用 readiness 路径，还调高了探测频率——结果在 GC 峰值或短暂 IO 延迟时，HTTP 超时触发重启，新旧 Pod 同时抖动。

正确做法是让 liveness 和 readiness 在语义上分离：

• readiness 探针走完整业务健康检查（含依赖），路径如 /health/ready
• liveness 探针走轻量级存活信号，例如只检查进程文件句柄或内存映射，路径如 /health/live，且 periodSeconds 不低于 10 秒、failureThreshold 设为 3–5
• 绝对避免在 liveness 中调用外部服务或执行耗时 SQL；它必须是本地、快速、无副作用的判断

Startup Probe 能解决什么问题？

当你的 Java 微服务启动要 90 秒、.NET Core 初始化要 70 秒，而默认的 initialDelaySeconds 最大只撑到 60 秒时，startupProbe 就是唯一解。它让 kubelet 在应用真正“活过来”之前，完全禁用 liveness 和 readiness 探针，避免因超时误杀。

典型配置示例（Java + Spring Boot）：

startupProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  failureThreshold: 30
  periodSeconds: 2

这意味着：最多允许 60 秒（30 × 2）启动时间，期间即使探测失败也不重启；一旦成功一次，就交棒给 liveness/readiness 探针接管。注意：failureThreshold 必须足够大，否则 startupProbe 自身就会失败并 kill 容器。

滚动更新策略与探针参数必须协同

再好的探针，如果和 maxUnavailable、terminationGracePeriodSeconds 不匹配，也会导致流量中断或连接堆积。

几个硬性配合点：

• terminationGracePeriodSeconds 必须 ≥ Golang 的 Shutdown 超时时间（如 30 秒），否则 SIGTERM 发出后不到 30 秒就被 SIGKILL 强杀，正在处理的请求丢失
• maxUnavailable: 25% 意味着升级时最多 1/4 实例不可用；但如果 readiness 探针失败周期（periodSeconds × failureThreshold）短于滚动节奏，旧 Pod 可能被提前摘除，而新 Pod 还没 ready，造成真实不可用
• 对长连接服务（如 WebSocket、gRPC streaming），需在 preStop Hook 中加 sleep，确保 Envoy/Istio sidecar 有足够时间从 upstream cluster 中摘掉该实例

最易被忽略的是：探针的 timeoutSeconds 默认只有 1 秒，而某些健康端点在高负载下响应可能达 2–3 秒——这会导致探测频繁失败，却不报错，只默默重启。

以上就是《K8s Liveness与Readiness探针保障微服务滚动更新》的详细内容，更多关于的资料请关注golang学习网公众号！