存活探针决定是否重启容器，就绪探针决定是否接收流量；二者职责分离、触发动作不同，不可混用同一健康接口，否则会导致数据库故障时反复重启而非仅摘流。
存活探针和就绪探针是 Kubernetes 判断容器真实状态的两个核心机制，它们职责不同、触发动作不同，不能互相替代。
存活探针：决定是否重启容器
它回答“这个容器还在健康运行吗”。一旦失败，Kubelet 会直接终止当前容器并按 restartPolicy 重启。适用于检测进程僵死、死锁、内存泄漏等内部不可恢复的问题。
- 支持三种检查方式：HTTP GET（访问 /health 等路径）、TCP Socket（连通指定端口）、Exec（执行命令如 curl 或 test -f）
- 关键参数要合理设置：initialDelaySeconds（启动后多久开始检查）、periodSeconds（间隔）、failureThreshold（连续失败几次才判定失败）
- 不要把依赖外部服务的逻辑放进存活检查——比如检查数据库连通性，否则数据库抖动会导致整个 Pod 被反复重启
就绪探针：决定是否接收流量
它回答“这个容器准备好对外提供服务了吗”。失败时，Kubernetes 会将该 Pod 从 Service 的 Endpoint 列表中移除，但不会重启容器。适用于应用启动耗时长、需加载配置或预热缓存等场景。
- 同样支持 HTTP、TCP、Exec 三种方式，常对接 Spring Boot 的 /actuator/health 或自定义的 /ready 接口
- 建议检查依赖项是否就绪，例如数据库连接池是否建立完成、Redis 是否可写、本地模型文件是否加载完毕
- 如果没配就绪探针，Pod 一变成 Running 就立刻进入负载均衡，容易导致请求 502 或超时
两者协同工作的典型流程
容器启动后，Kubelet 按配置启动两个探针（若未配置启动探针）。就绪探针先通过，Service 才把 Pod 加入流量池；之后存活探针持续监控，一旦发现异常，就触发重启。二者独立运行，互不影响。
- 就绪成功 ≠ 存活一定成功；存活失败 ≠ 就绪一定失败
- 常见错误是用同一个接口同时做两种检查，但健康接口应区分语义：/health 只反映自身状态，/ready 还需校验下游依赖
- 对于启动慢的应用（如 Java 单体），建议叠加 startupProbe，避免因 initialDelaySeconds 设置不当导致误杀
配置要点提醒
探针不是加了就万事大吉，重点在于语义准确、检查轻量、参数匹配实际行为。
- 存活检查接口必须快速返回（通常
- 就绪检查可以稍重，但也不能阻塞太久（建议
- 避免在 readinessProbe 中做写操作（如清空队列），防止滚动更新时重复触发业务逻辑
