k8s之各类 Pod 控制器的更新策略

各类 Pod 控制器的更新策略

1. Deployment（无状态应用）

Deployment 是用于管理无状态应用的控制器，它提供了强大的更新策略来确保应用的平稳升级。

spec:
  strategy:
    type: RollingUpdate | Recreate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%

• RollingUpdate（默认）：
  • 采用滚动更新的方式，逐步替换旧的 Pod 实例。maxUnavailable 定义了在更新过程中不可用的 Pod 最大数量或百分比，maxSurge 则规定了超过期望 Pod 数量的最大 Pod 数量或百分比。
  • 例如，maxUnavailable: 25% 和 maxSurge: 25% 意味着在更新时，最多允许 25% 的 Pod 不可用，同时最多可以额外创建 25% 的 Pod 来进行更新操作。
• Recreate：
  • 先删除所有旧的 Pod 实例，然后再创建新的 Pod 实例。这种方式会导致应用有短暂的停机时间。

适用场景：Web 应用、API 服务等无状态服务。

2. StatefulSet（有状态应用）

类似 Deployment 的 strategy，但更复杂，因为要维护 Pod 的顺序和稳定性。

spec:
  updateStrategy:
    type: RollingUpdate | OnDelete
    rollingUpdate:
      partition: 2  # 控制分批更新（类似金丝雀发布）

• RollingUpdate（默认）：
  • 按 Pod 序号逆序（从最大序号开始）逐个更新。
  • 通过 partition 控制更新的范围（例如 partition: 3 表示只更新序号 ≥3 的 Pod）。
• OnDelete：
  • 手动删除 Pod 时才会触发更新（类似旧版 Deployment 行为）。

适用场景：数据库（MySQL、MongoDB）、有状态服务（如 Kafka Broker）。

3. DaemonSet（节点级守护进程）

无 strategy，但有类似的更新控制。

spec:
  updateStrategy:
    type: RollingUpdate | OnDelete
    rollingUpdate:
      maxUnavailable: 1  # 类似 Deployment 的滚动更新

• RollingUpdate（默认）：
  • 逐个节点更新 DaemonSet Pod，maxUnavailable 控制并发更新的节点数。
• OnDelete：
  • 需手动删除 Pod 才会触发更新。

适用场景：日志收集（Fluentd）、网络插件（Calico）。

4. Job / CronJob（批处理任务）

无滚动更新策略，因为任务是短期运行的。

Job

直接替换 Pod 模板，新 Job 会创建新 Pod。

CronJob

CronJob 依赖 concurrencyPolicy 字段来处理作业的并发执行情况，concurrencyPolicy 有以下几种取值：

spec:
  concurrencyPolicy: Allow | Forbid | Replace
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

• Allow（默认）：CronJob 允许并发执行作业。也就是说，如果一个 CronJob 触发的前一个作业还未完成，新的作业会同时启动执行。
• Forbid：CronJob 禁止并发执行作业。如果前一个作业还未完成，新的作业会被跳过，直到前一个作业完成。
• Replace：CronJob 会用新的作业替换正在运行的作业。如果前一个作业还未完成，新的作业启动时，正在运行的作业会被终止。

适用场景：一次性任务或定时任务。

5. ReplicaSet（Deployment 的底层控制器）

本身无 strategy，更新策略由 Deployment 控制。

• 直接修改 ReplicaSet 的 Pod 模板不会触发滚动更新，必须通过 Deployment 操作。

对比总结

控制器	类似 strategy 的字段	更新行为	适用场景
Deployment	spec.strategy	滚动更新（RollingUpdate）或重建（Recreate）	无状态服务（如 Web 应用）
StatefulSet	spec.updateStrategy	按序号分批更新，支持分区控制	有状态服务（如数据库）
DaemonSet	spec.updateStrategy	按节点滚动更新	节点级守护进程
Job/CronJob	无	直接替换 Pod，CronJob 依赖 concurrencyPolicy 控制并发	批处理任务
ReplicaSet	无	需通过 Deployment 控制	一般不直接使用

关键结论

1. Deployment 和 StatefulSet 提供了最接近 strategy 的精细控制。Deployment 适合无状态应用的滚动更新和重建操作，StatefulSet 则能保证有状态应用的有序更新。
2. DaemonSet 的更新策略较简单，仅支持滚动更新或手动触发，主要用于节点级守护进程的更新。
3. Job/CronJob 无滚动更新，因为任务本质是短期运行，直接替换 Pod 模板即可，CronJob 可通过 concurrencyPolicy 控制并发执行。

如果需要更灵活的更新策略（如蓝绿部署、金丝雀发布），通常需要结合 Ingress 流量控制 或 Argo Rollouts 等高级工具。