Kubernetes Liveness Probe存活探针 / Readiness Probe就绪探针介绍（Startup Probe启动探针）重启容器

文章目录Kubernetes 中的 Liveness / Readiness 探针详解一、为什么需要探针二、Liveness Probe存活探针作用典型场景工作机制示例配置常见检查方式示例Exec三、Readiness Probe就绪探针作用典型场景工作机制示例配置四、核心区别五、Startup Probe补充Startup Probe启动探针使用场景示例关键点六、最佳实践1️⃣ 区分两个探针的职责2️⃣ 健康检查接口设计3️⃣ Readiness 要检查依赖4️⃣ Liveness 不要过于严格5️⃣ 合理设置参数七、常见踩坑❌ 1. 没有 Readiness Probe❌ 2. Liveness 检查依赖服务❌ 3. 探针过于频繁❌ 4. 健康接口太重八、总结Kubernetes 中的 Liveness / Readiness 探针详解在使用 Kubernetes 进行容器编排时如何判断一个 Pod 是否健康、是否可以对外提供服务是运维中非常关键的问题。Kubernetes 提供了三种健康检查机制其中最常用的是Liveness Probe存活探针Readiness Probe就绪探针另外还有一个较新的 Startup Probe这里会顺带提一下本文将从原理、区别、配置与实战角度深入讲解它们的使用方法。一、为什么需要探针容器“运行中Running”并不代表“可用”。常见问题包括应用线程死锁进程还在但无法响应服务启动未完成比如还在加载模型、连接数据库依赖服务异常数据库、缓存不可用内部错误导致服务不可用 如果没有探针流量可能被发送到“假活”的 PodKubernetes 无法自动修复异常实例二、Liveness Probe存活探针作用判断容器是否“还活着”如果失败 Kubernetes 会重启容器典型场景应用发生死锁内存泄漏导致不可用线程卡死但进程未退出工作机制Kubernetes 定期执行检查成功 → 正常运行失败达到阈值 → 重启容器示例配置livenessProbe:httpGet:path:/healthzport:8080initialDelaySeconds:10periodSeconds:10timeoutSeconds:2failureThreshold:3常见检查方式类型说明HTTP请求接口TCP检查端口Exec执行命令示例ExeclivenessProbe:exec:command:-cat-/tmp/healthy三、Readiness Probe就绪探针作用判断容器是否“可以接收流量”如果失败 Pod 会被从 Service 的负载均衡中移除典型场景应用刚启动还没 ready依赖服务不可用数据库挂了服务负载过高需要暂时摘流工作机制成功 → Pod 加入 Service失败 → Pod 从 Service 移除不会重启示例配置readinessProbe:httpGet:path:/readyport:8080initialDelaySeconds:5periodSeconds:5四、核心区别特性Liveness ProbeReadiness Probe作用是否存活是否可接流量失败结果重启容器从 Service 移除是否影响流量❌✅是否触发重启✅❌五、Startup Probe补充Kubernetes 还提供Startup Probe启动探针 解决慢启动问题使用场景Java 应用Spring BootAI 模型加载大型初始化流程示例startupProbe:httpGet:path:/startupport:8080failureThreshold:30periodSeconds:10关键点Startup Probe 成功前不执行 liveness / readiness防止应用“还没启动就被杀掉”六、最佳实践1️⃣ 区分两个探针的职责Liveness判断是否需要重启Readiness判断是否接流量 不要混用同一个接口2️⃣ 健康检查接口设计推荐设计三个接口/healthz - liveness /ready - readiness /startup - startup3️⃣ Readiness 要检查依赖例如数据库连接Redis外部 API否则 服务“看起来正常”但实际不可用4️⃣ Liveness 不要过于严格错误示例把数据库依赖放到 liveness 会导致数据库短暂异常 → 容器疯狂重启雪崩5️⃣ 合理设置参数关键参数initialDelaySeconds periodSeconds timeoutSeconds failureThreshold建议高延迟系统 → 增大 timeout慢启动 → 增大 initialDelay防止抖动 → 提高 failureThreshold七、常见踩坑❌ 1. 没有 Readiness Probe结果流量打到未初始化服务❌ 2. Liveness 检查依赖服务结果外部依赖异常 → 容器被重启错误行为❌ 3. 探针过于频繁结果增加系统负担触发误判❌ 4. 健康接口太重结果健康检查本身变慢甚至失败 建议健康接口要轻量、快速、无副作用八、总结Kubernetes 探针是实现高可用、自愈能力的核心机制之一Liveness Probe→ 解决“死而不僵”Readiness Probe→ 解决“未 ready 就接流量”Startup Probe→ 解决“慢启动误杀” 三者配合才能构建真正稳定的生产系统