K8s Pod 重启策略与回滚方案

Kubernetes作为容器编排领域的标杆，其Pod重启策略与回滚方案直接影响应用稳定性与故障恢复效率。当业务容器异常退出或版本更新出现问题时，合理的重启机制和快速回滚能力成为保障服务连续性的关键。本文将深入解析Pod重启策略的核心逻辑，并梳理多种场景下的回滚实践，帮助开发者构建更健壮的云原生应用。
Pod重启策略深度解析
K8s提供三种重启策略：Always（默认策略）确保容器退出必重启，适用于无状态服务；OnFailure仅在非0退出码时重启，适合批处理任务；Never则完全依赖外部监控。关键在于理解策略与控制器（如Deployment）的协同机制——例如Job控制器会主动覆盖Pod的restartPolicy为OnFailure，而DaemonSet则强制要求Always策略。
版本回滚核心机制
通过Deployment的滚动更新历史记录，kubectl rollout undo可快速回退到上一版本。底层依赖ReplicaSet的版本快照功能，每次更新都会保留旧版ReplicaSet模板。关键参数revisionHistoryLimit需合理设置（建议3-5），过小会导致无法追溯历史版本，过大则浪费存储资源。
健康检查与重启联动
Readiness Probe失败会触发Endpoint摘除，但不会重启Pod；Liveness Probe连续失败则强制重启容器。两者配合可区分临时故障与死锁场景。典型实践是将业务关键接口设为Liveness检查，依赖服务接口设为Readiness检查，避免级联重启。
多版本并行回滚方案
对于金丝雀发布等复杂场景，可通过流量切分实现渐进式回滚。Ingress配合Service的selector标签，将部分流量导回旧版本Pod。结合Prometheus监控指标，实现基于错误率的自动回滚决策，这种方案在电商大促期间尤为有效。
状态服务特殊处理
StatefulSet管理的Pod需要特殊考虑——默认策略可能导致数据不一致。建议搭配持久卷使用Never策略，通过operator自定义恢复逻辑。例如Cassandra集群节点故障时，应先人工诊断再执行定向重建，避免脑裂问题。