3. 滚动升级原理：Kubernetes Deployment 滚动更新策略、maxSurge 与 maxUnavailable 参数详解

滚动升级（Rolling Update）是 Kubernetes Deployment 默认的更新策略。它通过逐步替换旧 Pod 实例为新版本，实现零停机的应用发布。理解其底层机制与核心参数，是后续进行资源调优与瓶颈分析的基础。

3.1 滚动更新策略的核心机制

当修改 Deployment 的 Pod 模板（如镜像版本）并应用后，Kubernetes 会创建一个新的 ReplicaSet，并逐步扩容新 RS、缩容旧 RS。整个过程由 ReplicaSet Controller 和 Deployment Controller 协同完成。

下图展示了滚动更新的典型流程：

3.2 maxSurge 参数详解

maxSurge 定义了在滚动更新过程中，最多可以超出期望副本数（replicas）的 Pod 数量或百分比。它控制着新 Pod 的创建速度。

3.3 maxUnavailable 参数详解

maxUnavailable 定义了在滚动更新过程中，最多允许有多少个 Pod 处于不可用状态。它控制着旧 Pod 的销毁速度。

3.4 参数组合与行为分析

两个参数共同决定了滚动更新的速度和安全性。以下是常见的组合策略：

3.5 实际配置示例

以下是一个完整的 Deployment YAML 配置，展示了滚动更新策略的声明方式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

3.6 滚动更新过程中的状态观察

使用 kubectl rollout status 和 kubectl describe deployment 可以实时观察滚动更新的进度：

# 查看滚动更新状态
kubectl rollout status deployment/my-app

# 输出示例
Waiting for deployment "my-app" rollout to finish: 2 out of 5 new replicas have been updated...
Waiting for deployment "my-app" rollout to finish: 2 out of 5 new replicas have been updated...
Waiting for deployment "my-app" rollout to finish: 3 out of 5 new replicas have been updated...
deployment "my-app" successfully rolled out

# 查看详细事件
kubectl describe deployment my-app | grep -A 10 "Events:"

通过 kubectl get replicasets 可以同时看到新旧两个 ReplicaSet 的副本数变化：

NAME               DESIRED   CURRENT   READY   AGE
my-app-7d4f8b5c6   3         3         3       2m
my-app-9a2b3c4d5   2         2         2       10m

3.7 滚动更新与资源调优的关联

在后续章节中，我们将基于滚动更新的行为特征，分析资源瓶颈并优化 Argo CD 的同步策略。理解 maxSurge 和 maxUnavailable 的底层逻辑，是进行以下调优的前提：

• 资源预留：根据 maxSurge 计算峰值资源需求，避免节点资源不足导致 Pod 调度失败。
• 速度控制：通过调整参数，平衡更新速度与集群负载，防止突发流量压垮服务。
• 健康检查：确保 readinessProbe 配置合理，避免因探针延迟导致滚动更新卡死。
• 回滚策略：在更新失败时，利用 Deployment 的历史版本快速回滚，减少故障时间。