📚 课程目录第3章滚动升级原理

3. 滚动升级机制详解

滚动升级（Rolling Update）是 Kubernetes 中最常用的工作负载更新策略。它通过逐步替换旧版本 Pod 实例，确保服务在更新过程中持续可用。理解其核心参数与 Pod 生命周期，是实现资源配额精准校准的前提。

3.1 Deployment 滚动更新策略

Deployment 控制器默认采用 RollingUpdate 策略。该策略的核心思想是：在保证可用 Pod 数量不低于阈值的前提下，逐步创建新版本 Pod，并终止旧版本 Pod。整个过程由两个关键参数控制：maxSurge 和 maxUnavailable。

  关键概念： 滚动更新不是一次性替换所有 Pod，而是通过“渐进式”替换，将更新对业务的影响降到最低。资源配额的校准必须考虑更新过程中新旧 Pod 同时存在的峰值资源需求。

3.2 maxSurge 与 maxUnavailable 参数详解

这两个参数定义了滚动更新的“节奏”和“安全边界”。它们可以设置为数值（整数）或百分比（相对于期望副本数 replicas）。

参数	定义	默认值	作用
maxSurge	更新过程中，允许超出期望副本数的最大 Pod 数量	25%	控制更新速度，允许提前创建新 Pod
maxUnavailable	更新过程中，允许不可用 Pod 的最大数量	25%	保证服务可用性，控制旧 Pod 的下线速度

实践建议： 对于有状态服务或资源敏感型应用，建议将 maxSurge 设置为 0，maxUnavailable 设置为 1，以最小化资源峰值和风险。对于无状态 Web 服务，可以使用默认值以加快更新速度。

参数计算示例

假设 replicas=10，maxSurge=25%，maxUnavailable=25%：

maxSurge = 10 * 25% = 2.5 → 向上取整为 3。更新期间最多允许 10 + 3 = 13 个 Pod 同时运行。
maxUnavailable = 10 * 25% = 2.5 → 向上取整为 3。更新期间最多允许 3 个 Pod 处于不可用状态。
最小可用 Pod = 10 - 3 = 7。更新期间至少保证 7 个 Pod 正常运行。

资源配额陷阱： 当 maxSurge > 0 时，集群中会临时出现超出期望副本数的 Pod。如果 Namespace 的 ResourceQuota 设置过紧，可能导致新 Pod 因资源不足而创建失败，从而阻塞整个滚动更新流程。

3.3 Pod 生命周期与资源再分配

滚动更新过程中，每个 Pod 都会经历完整的生命周期阶段。理解这些阶段，有助于我们精确计算资源配额需求。

创建新 Pod（Pending → Running）：调度器为新 Pod 分配节点，kubelet 拉取镜像并启动容器。此阶段需要消耗 CPU 和内存资源。
就绪检查（Readiness Probe）：新 Pod 通过就绪探针后，Service 开始将流量转发给它。此时新 Pod 正式承担业务负载。
终止旧 Pod（Running → Terminating）：旧 Pod 收到 SIGTERM 信号，执行 preStop 钩子，然后优雅退出。此阶段旧 Pod 仍占用资源，但不再接收新流量。
资源释放：旧 Pod 完全终止后，其占用的资源被回收，可供新 Pod 或其他工作负载使用。

3.4 资源再分配的关键时刻

在滚动更新过程中，资源再分配发生在以下三个关键时刻，直接影响 ResourceQuota 的校验结果：

时刻	事件	资源状态	Quota 影响
T1	新 Pod 创建（Pending）	新 Pod 请求资源，旧 Pod 仍占用资源	资源使用量上升，可能触发 Quota 上限
T2	旧 Pod 进入 Terminating	新 Pod 已运行，旧 Pod 正在释放资源	资源使用量达到峰值，Quota 压力最大
T3	旧 Pod 完全删除	仅新 Pod 占用资源	资源使用量回落至期望水平

  校准公式： 滚动更新期间的最大资源需求 = (期望副本数 + maxSurge) × 单个 Pod 资源请求。在设置 Namespace ResourceQuota 时，必须确保 Quota 上限 ≥ 该峰值，否则更新将被阻塞。

3.5 实际配置示例

以下是一个 Deployment 配置片段，展示了如何显式设置滚动更新策略：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2
        resources:
          requests:
            cpu: "500m"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"

配置解读： 上述配置中 maxSurge: 1 表示最多允许 1 个额外 Pod，maxUnavailable: 0 表示必须保证所有 5 个 Pod 始终可用。这意味着更新过程会先创建一个新 Pod，待其就绪后，再终止一个旧 Pod，如此循环。这种配置对资源配额的要求是：必须能同时容纳 6 个 Pod 的资源请求。

3.6 滚动更新与资源配额的冲突场景

当 Namespace 的 ResourceQuota 设置不合理时，滚动更新可能遇到以下问题：

创建失败：新 Pod 因超出 Quota 而无法创建，更新流程卡住。
更新缓慢：由于资源紧张，新 Pod 调度缓慢，导致更新周期延长。
级联失败：旧 Pod 被终止后，新 Pod 仍无法创建，导致可用 Pod 数量低于 maxUnavailable 阈值，触发 Deployment 回滚。

避坑指南： 在设置 ResourceQuota 时，建议将 requests.cpu 和 requests.memory 的上限设置为：期望副本数 × 单 Pod 请求 × (1 + maxSurge百分比)。同时，为关键 Namespace 开启 LimitRange，确保每个 Pod 的资源请求在合理范围内。

3.7 本章小结

滚动更新机制通过 maxSurge 和 maxUnavailable 两个参数精细控制更新节奏。在资源配额校准场景下，必须关注以下要点：

峰值资源计算：以 期望副本数 + maxSurge 为基准计算最大资源需求。
生命周期理解：新 Pod 创建和旧 Pod 终止的重叠期是资源压力最大的时刻。
Quota 设置：ResourceQuota 的上限必须覆盖滚动更新期间的资源峰值，否则更新将失败。
策略选择：对于资源敏感型应用，优先考虑 maxSurge: 0 和 maxUnavailable: 1 的保守策略。