文章目录一. 三种重启策略详解1.1. Always默认值1.2. OnFailure1.3. Never二. 重启策略与控制器的关系三. 重启背后的机制指数退避Back-off四. 常见误区澄清4.1. livenessProbe存活探针失败会导致重启吗4.2. readinessProbe就绪探针失败会导致重启吗4.3. 节点重启后Pod 会重启吗4.4. 如何查看容器的重启次数五. 最佳实践建议5.1. 长期服务用 Always5.2. 批处理任务用 OnFailure backoffLimit5.3. 避免在 Pod 中处理复杂重启逻辑5.4. 调试时使用 Never5.5. 总结在 Kubernetes (K8s) 中重启策略Restart Policy是决定当 Pod 中的容器终止退出时Kubelet 应该如何处理该 Pod 的核心机制。与 Docker 不同K8s 的重启策略是定义在Pod 级别.spec.restartPolicy而不是单个容器级别。这意味着 Pod 中的所有容器共享同一个重启策略。一. 三种重启策略详解Kubernetes 支持以下三种重启策略1.1.Always默认值行为无论容器因何种原因退出正常退出代码 0 或异常退出代码非 0Kubelet 都会自动重启该容器。适用控制器Deployment,StatefulSet,DaemonSet,ReplicaSet。场景长期运行的服务如 Web 服务器、数据库、API 网关。只要节点还在服务就应该一直在线。注意如果手动执行kubectl delete podPod 会被删除且不会重启因为控制器会创建一个新的 Pod 来替代它而不是重启旧的。1.2.OnFailure行为只有当容器以非零状态码即发生错误/崩溃退出时Kubelet 才会重启容器。如果容器正常退出状态码为 0则不会重启。适用控制器Job,CronJob。场景批处理任务、数据迁移脚本、一次性计算任务。如果任务成功完成exit 0就不需要再跑了如果失败了则需要重试。1.3.Never行为无论容器因何种原因退出Kubelet永远不会重启该容器。Pod 的状态将变为Completed正常退出或Failed异常退出。适用控制器Job某些特定场景。场景调试任务、只需要运行一次且不在乎结果的任务、或者由外部系统监控并手动重启的任务。二. 重启策略与控制器的关系并非所有控制器都支持所有重启策略。K8s 会根据控制器类型强制校验控制器类型支持的 RestartPolicy说明DeploymentAlways必须始终运行保证服务可用性。StatefulSetAlways同上有状态服务需持续运行。DaemonSetAlways每个节点上的守护进程需持续运行。JobOnFailure,Never任务完成后应结束失败时可重试。CronJobOnFailure,Never同 Job由定时触发。❌ 错误示例如果你在 Deployment 的 YAML 中设置restartPolicy: OnFailureK8s API Server 会直接拒绝创建报错Unsupported value: OnFailure: supported values: Always。三. 重启背后的机制指数退避Back-off为了防止容器因代码 Bug 导致“启动-崩溃-重启”的死循环CrashLoopBackOffKubelet 采用了指数退避算法第一次重启等待 10 秒。第二次重启等待 20 秒。第三次重启等待 40 秒。…最大等待时间上限通常为5 分钟300 秒。状态变化流程Running-Error/Crash-CrashLoopBackOff(等待中) -Running(重试)你可以在kubectl describe pod pod-name中看到Last State和Reason: CrashLoopBackOff。四. 常见误区澄清4.1.livenessProbe存活探针失败会导致重启吗是的。如果livenessProbe检查失败Kubelet 会杀死容器。然后根据restartPolicy如果是Always或OnFailure且退出码非0容器会被重启。如果是Never容器死后不再复活。4.2.readinessProbe就绪探针失败会导致重启吗不会。readinessProbe失败只会将 Pod 从 Service 的 Endpoint 列表中移除停止流量进入但不会杀死或重启容器。4.3. 节点重启后Pod 会重启吗如果 Pod 是由控制器如 Deployment管理的控制器会发现 Pod 缺失并调度一个新的 Pod 到可用节点上。这不属于“重启策略”的范畴而是控制器的**期望状态协调Reconciliation**机制。4.4. 如何查看容器的重启次数kubectl get pods# 输出示例# NAME READY STATUS RESTARTS AGE# my-app-7d9f6b8c5-x2z9a 1/1 Running 3 10mRESTARTS列显示的数字就是该 Pod 历史上被重启的次数。kubectl describe podpod-name# 在 Containers 部分查看# Last State: Terminated# Reason: Error# Exit Code: 1# Started: ...# Finished: ...# Ready: True# Restart Count: 3五. 最佳实践建议5.1. 长期服务用Always对于 Web 应用、微服务始终使用Always。配合livenessProbe可以自动恢复死锁或僵死的进程。5.2. 批处理任务用OnFailurebackoffLimit对于 Job设置restartPolicy: OnFailure并在 Job spec 中设置backoffLimit: 4默认6次防止无限重试浪费资源。5.3. 避免在 Pod 中处理复杂重启逻辑不要在应用代码里写while true来防止退出。让 K8s 管理生命周期应用应该设计为“无状态”或“可快速启动”。5.4. 调试时使用Never如果容器一启动就崩溃你可以临时将策略改为Never这样容器死后会保留现场你可以进入容器或通过日志排查问题而不会被不断重启打断。5.5. 总结策略何时重启典型用途控制器支持Always任何退出长期服务Deployment, StatefulSet, DaemonSetOnFailure仅异常退出批处理/任务Job, CronJobNever从不重启调试/一次性Job
