Kubernetes通过Liveness、Readiness和Startup三类探针协同实现Pod健康检查：LivenessProbe失败则重启容器，ReadinessProbe失败则从Service Endpoint摘除但不重启，StartupProbe专用于长启动应用，暂禁其他探针以避免误杀。
Kubernetes 通过声明式控制循环和多层健康保障机制，让 Pod 在故障后能自动恢复，而不是靠人工介入。核心不在于“出了问题再修”，而是在问题发生前就定义好“应该什么样”，系统持续比对、自动纠偏。
定义明确的健康探针
只靠进程是否存活远远不够。Kubernetes 提供三类探针协同判断：
- LivenessProbe：确认容器是否“活着”。失败即重启，比如 HTTP 接口返回 5xx 或超时。适合处理死锁、内存泄漏等僵死状态。
- ReadinessProbe：确认容器是否“ ready to serve”。失败则从 Service 的 Endpoint 中摘除，停止转发流量，但不重启。适用于依赖未就绪、数据库连接中断等临时不可用场景。
- StartupProbe：专为启动慢的应用（如 Java 应用）设计。它会暂停 liveness 和 readiness 探测，避免在初始化完成前被误杀。
例如，一个 Spring Boot 应用可配置 startupProbe 等待 120 秒，liveness 每 30 秒检查 /actuator/health/liveness，readiness 检查 /actuator/health/readiness —— 三层覆盖不同生命周期阶段。
维持期望副本数（ReplicaSet 控制器）
Deployment 背后由 ReplicaSet 管理。只要集群中有可用节点，控制器就会确保实际运行的 Pod 数始终等于你声明的 replicas 数量。
- 某个 Pod 因 OOM 被 kubelet 终止？控制器发现数量不足，立刻新建一个。
- 整个节点宕机？Controller Manager 检测到该节点失联，将原节点上的 Pod 标记为“缺失”，并在其他健康节点上调度新 Pod。
- 即使手动删除 Pod（
kubectl delete pod），也会被立即重建 —— 因为这违反了声明的期望状态。
结合调度策略与节点容错
自动恢复不只是“重启”，更是“智能重调度”：
- 使用
podAntiAffinity避免同 Deployment 的多个 Pod 落在同一节点，降低单点故障影响。 - 配置
taints & tolerations，让关键 Pod 只运行在专用节点；或反过来，把维护中的节点打上 taint，驱逐非容忍的 Pod。 - 节点进入
NotReady状态超过指定时间（默认 40 秒），其上 Pod 会被标记为Unknown，随后由控制器触发重建 —— 这个过程无需人工干预。
利用启动与重启策略兜底
当 kubelet 层面接管不了（比如容器运行时崩溃、节点重启），底层机制仍能起作用：
- Pod 的
restartPolicy设为Always（默认值），确保容器进程退出后立即重启（限于同一 Pod 内）。 - Docker 或 containerd 自身也支持 restart policy（如
--restart=always），作为最外层防线，应对 kubelet 异常或宿主机重启场景。 - 对于 initContainer 失败，整个 Pod 会终止并根据 restartPolicy 决定是否重试，防止主容器在错误前提下启动。
这些能力不是孤立的，而是层层嵌套：探针决定“要不要动”，控制器决定“动多少”，调度器决定“动到哪”，运行时决定“最后能不能拉起来”。整套逻辑围绕“期望状态”运转，不复杂但容易忽略细节。
