在 Kubernetes 中，Pod 的 restartPolicy（重启策略）决定了当 Pod 中的容器退出（终止）时，Kubelet 应该如何处理。

该策略定义在 Pod 的 spec 中（spec.restartPolicy），适用于 Pod 内的所有容器。

共有以下 3 种 策略：

1. Always (默认策略)

• 行为：无论容器是因为正常退出（退出码为 0）还是非正常退出（退出码非 0），Kubelet 都会自动重启该容器。
• 适用场景：
  • 长期运行的服务：如 Web 服务器（Nginx）、数据库（MySQL）、API 服务等。这些服务设计为一直运行，如果停止了，通常意味着出错了，需要恢复。
• 注意：这是 Deployment、StatefulSet 和 DaemonSet 的默认且通常唯一的选择。

2. OnFailure

• 行为：只有当容器异常退出（退出码非 0）时，Kubelet 才会重启该容器。如果容器正常结束（退出码为 0），则不会重启。
• 适用场景：
  • 一次性任务或批处理任务：任务执行完应该停止，但如果执行过程中崩溃了，需要重试。
• 常见搭配：通常与 Job 控制器一起使用。

3. Never

• 行为：无论容器是正常退出还是异常退出，Kubelet 都不会重启该容器。
• 适用场景：
  • 一次性任务：如果你希望任务失败后不要在当前 Pod 原地重试，而是希望控制器（如 Job）创建一个全新的 Pod 来重试，或者你希望保留失败现场（日志、文件系统状态）以便调试。
  • 调试：运行一个脚本查看结果，不希望它自动重来。

策略对比总结

两个重要的补充机制

1. 指数退避延迟 (Exponential Back-off)：
   Kubernetes 不会无脑地疯狂重启容器。如果容器反复崩溃，Kubelet 会通过指数级延迟来重启它（例如：10s, 20s, 40s, 80s ... 最长 5 分钟）。这可以防止节点资源被死循环的重启耗尽。你会看到 Pod 状态变为 CrashLoopBackOff。

2. 控制器对策略的限制：
   虽然 Pod 规范支持这三种，但上层控制器有默认要求：

   • Deployment / StatefulSet / DaemonSet：必须设置为 Always（因为它们的目的是保证服务一直在线）。
   • Job：只能设置为 OnFailure 或 Never（因为 Job 的目的是任务完成后就结束，不能一直重启）。

YAML 配置示例

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
  # 在这里定义重启策略
  restartPolicy: Always  # 可选: Always, OnFailure, Never