3. Deployment 滚动更新机制：ReplicaSet、maxSurge、maxUnavailable 参数详解

Deployment 的滚动更新是 Kubernetes 中最核心的发布策略。理解其底层运作机制，尤其是 ReplicaSet 的交替过程以及 maxSurge、maxUnavailable 两个关键参数，是实现资源预留优化的前提。本章从资源画像视角，拆解滚动更新的每个阶段。

3.1 核心概念：ReplicaSet 的版本交替

Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接控制。每次更新都会创建一个新的 ReplicaSet，并逐步缩容旧 ReplicaSet、扩容新 ReplicaSet。整个滚动更新过程就是新旧两个 ReplicaSet 的“交接班”。

3.2 滚动更新流程：分步图解

以下 SVG 展示了从更新触发到完成的完整流程，包含 ReplicaSet 的交替与 Pod 的创建/销毁节奏。

3.3 maxSurge 与 maxUnavailable 参数详解

这两个参数共同控制滚动更新的“速度”和“资源占用”。它们可以设置为 数值（如 1、2）或 百分比（如 25%），Kubernetes 会向上取整。

3.4 参数组合与资源峰值计算

不同的参数组合会直接影响更新期间的资源占用峰值。以下表格展示了在期望副本数 replicas=10 的场景下，不同参数组合的资源表现。

3.5 参数配置示例

以下 YAML 展示了一个典型的滚动更新配置，其中显式设置了 maxSurge 和 maxUnavailable。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2          # 允许最多超出 2 个 Pod
      maxUnavailable: 1    # 允许最多 1 个 Pod 不可用
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          requests:
            cpu: "500m"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"

3.6 资源画像视角下的参数调优建议

基于资源画像数据，可以针对性地调整滚动更新参数，实现资源预留优化：

• 低负载、高冗余场景（如开发环境）：可适当增大 maxSurge（如 50%），加快更新速度，资源预留可适当放宽。
• 高负载、资源紧张场景（如生产环境核心服务）：建议 maxSurge=1、maxUnavailable=1，严格控制资源峰值，预留资源需覆盖“期望副本数 + maxSurge”。
• 无状态、快速迭代场景：可设置 maxUnavailable=25%，允许部分旧 Pod 快速下线，配合 maxSurge=25% 保持服务容量。
• 资源画像驱动决策：通过历史资源画像分析节点剩余容量，动态调整 maxSurge 上限，避免更新时触发节点过载。

3.7 滚动更新与资源预留的协同关系

以下 SVG 展示了滚动更新参数如何影响资源预留的决策模型，帮助你在实际集群中制定合理的预留策略。

3.8 常见误区与避坑指南

• 误区一： 认为 maxSurge 只影响更新速度，不影响资源。实际上 maxSurge 直接决定资源峰值。
• 误区二： 将 maxUnavailable 设置为 0 可以保证服务不降级，但会拖慢更新速度，且资源峰值可能更高。
• 误区三： 忽略百分比向上取整。例如 replicas=3、maxSurge=25% 时，实际 maxSurge=1，而非 0.75。
• 误区四： 资源预留只考虑期望副本数，未考虑更新期间的“共存峰值”，导致节点过载。