4. Deployment 滚动更新：rollingUpdate 策略、maxSurge 与 maxUnavailable 参数、更新过程演示

滚动更新（Rolling Update）是 Kubernetes Deployment 默认的更新策略，它通过逐步替换旧 Pod 实例来保证服务在更新期间持续可用。本节将深入解析 rollingUpdate 策略的核心参数 maxSurge 与 maxUnavailable，并通过完整的更新过程演示帮助理解其工作原理。

4.1 rollingUpdate 策略概述

当 Deployment 的 spec.strategy.type 设置为 RollingUpdate 时，Kubernetes 会按照用户定义的参数逐步替换 Pod。该策略的核心目标是：在保证服务可用性的前提下，平滑地将所有 Pod 从旧版本迁移到新版本。

4.2 maxSurge 与 maxUnavailable 参数详解

这两个参数共同控制滚动更新的速率和资源占用，是精细化调优的关键。

4.2.1 maxUnavailable

定义： 更新过程中允许处于不可用状态的 Pod 最大数量或百分比（相对于期望副本数）。

• 作用： 保证更新期间至少有 replicas - maxUnavailable 个 Pod 处于可用状态。
• 取值： 整数（如 1）或百分比（如 25%），默认值为 25%。
• 示例： 若 replicas=10，maxUnavailable=25%，则更新期间最多允许 2 个 Pod 不可用，确保至少 8 个 Pod 持续提供服务。

4.2.2 maxSurge

定义： 更新过程中允许超出期望副本数的 Pod 最大数量或百分比。

• 作用： 控制可以提前创建的新 Pod 数量，加速更新过程。
• 取值： 整数（如 1）或百分比（如 25%），默认值为 25%。
• 示例： 若 replicas=10，maxSurge=25%，则更新期间最多允许 12 个 Pod 同时存在（10 + 2），新 Pod 创建后旧 Pod 才被删除。

4.3 滚动更新过程演示

以下通过一个实际案例演示滚动更新的完整流程。假设 Deployment 配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
        version: v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

执行更新命令：kubectl set image deployment/web-app nginx=nginx:1.25

4.3.1 更新步骤分解

1. 初始状态： 4 个 version=v1 的 Pod 全部运行，ReplicaSet web-app-xxx-v1 管理所有 Pod。
2. 创建新 ReplicaSet： Kubernetes 创建新的 ReplicaSet web-app-yyy-v2，期望副本数为 0。
3. 扩容新 RS： 根据 maxSurge=1，允许最多 5 个 Pod 同时存在。系统在旧 RS 保持 4 个 Pod 的基础上，为新 RS 创建 1 个新 Pod（version=v2）。
4. 缩容旧 RS： 新 Pod 通过 readinessProbe 检查变为 Ready 后，根据 maxUnavailable=1，系统从旧 RS 中删除 1 个旧 Pod（version=v1）。此时总 Pod 数回到 4。
5. 循环执行： 重复步骤 3-4，每次创建 1 个新 Pod，删除 1 个旧 Pod，直到所有旧 Pod 被替换。
6. 完成状态： 4 个 version=v2 的 Pod 全部运行，旧 ReplicaSet 副本数缩为 0。

4.3.2 滚动更新状态图

4.4 滚动更新参数配置建议

4.5 滚动更新回滚机制

当更新过程中出现故障（如新版本 CrashLoopBackOff），Kubernetes 会自动暂停更新。运维人员可以通过以下命令手动回滚：

# 回滚到上一个版本
kubectl rollout undo deployment/web-app

# 回滚到指定版本
kubectl rollout undo deployment/web-app --to-revision=2

# 查看更新历史
kubectl rollout history deployment/web-app

回滚时，Kubernetes 会复用相同的 rollingUpdate 策略参数，以同样的滚动方式将 Pod 恢复到旧版本，确保回滚过程同样平滑。

4.6 滚动更新与 CRI 资源调度的关系

滚动更新过程中，新 Pod 的创建会触发 CRI（Container Runtime Interface）接口的资源调度流程：

• kubelet 调用 CRI： 新 Pod 被调度到节点后，kubelet 通过 CRI 接口（如 containerd、CRI-O）创建容器。
• 资源预留与限制： CRI 根据 Pod 的 resources.requests 和 resources.limits 配置，向容器运行时申请 CPU、内存等资源。
• 节点资源压力： 若 maxSurge 设置过大，可能导致节点资源超分，触发 kubelet 的驱逐机制（Eviction）。