---

tags:
– Kubernetes
– K8s系列
– DevOps
– Deployment
– ReplicaSet
– 滚动更新
– 蓝绿部署
– 金丝雀发布
– 容器编排

---

K8s 系列 | 第 4 天（重访）：Deployment 进阶：生产级部署策略、滚动更新调优与故障排查实战

第 4/30 天（重访）

一、引言

在 K8s 系列第 4 天的原始文章中，我们学习了 Deployment 和 ReplicaSet 的基础概念：什么是声明式管理、如何创建 Deployment、以及基本的滚动更新与回滚操作。但生产环境中的部署场景远比入门教程复杂——当你的集群承载着数十个微服务、每天多次发布、需要保证零停机、还要应对突发的发布失败时，仅仅知道 kubectl apply 和 kubectl rollout undo 远远不够。

本文将从生产运维的视角重新审视 Deployment，深入探讨以下高级主题：

• 滚动更新策略的精细调优：maxSurge / maxUnavailable 的数学原理与最佳配置
• 高级部署模式：蓝绿部署、金丝雀发布、A/B 测试的实现方法
• Progressive Delivery（渐进式交付）：Argo Rollouts 实现自动化的金丝雀分析与自动回滚
• PodDisruptionBudget：节点维护时保障部署可用性
• Deployment 故障排查实战：卡住、回滚失败、流量异常等常见问题

无论你是刚开始接触 K8s 的运维工程师，还是已经在生产环境中使用 Deployment 的开发者，本文都能帮你将部署能力提升到一个新的层次。

---

二、核心概念

2.1 滚动更新策略的深度调优：maxSurge / maxUnavailable 的数学原理

Deployment 的滚动更新策略由 strategy.rollingUpdate 下的两个参数控制，它们的组合直接决定了更新的速度、安全性和资源消耗。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: production-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 可超出期望副本数的最大数量（绝对值或百分比）
      maxUnavailable: 0    # 更新过程中允许不可用的最大 Pod 数量
  minReadySeconds: 30      # Pod 就绪后等待多少秒才视为可用
  progressDeadlineSeconds: 600  # 滚动更新超时时间（秒）

参数详解：

参数	类型	默认值	含义
maxSurge	整数或百分比	25%	滚动更新期间，允许超出 replicas 的最大 Pod 数量
maxUnavailable	整数或百分比	25%	滚动更新期间，允许不可用的最大 Pod 数量
minReadySeconds	整数	0	Pod 进入 Ready 状态后，等待多少秒才视为可用
progressDeadlineSeconds	整数	600	滚动更新未完成时的超时时间，超时后标记为 Progressing=False

常见的参数组合场景：

场景一：零停机更新（最严格）

rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0

• 旧 Pod 完全停止前，先启动新 Pod，确保始终有 10 个 Pod 在服务
• 需要额外 1 个 Pod 的资源（maxSurge=1）
• 适合对可用性要求极高的生产服务

场景二：快速更新（节省资源）

rollingUpdate:
  maxSurge: 0
  maxUnavailable: 1

• 先停掉 1 个旧 Pod，再启动 1 个新 Pod，不额外占用资源
• 更新过程中会短暂出现 N-1 个 Pod 提供服务
• 适合资源紧张但可接受短暂降级的场景

场景三：快速批量更新

rollingUpdate:
  maxSurge: 3
  maxUnavailable: 2

• 同时允许最多 13 个 Pod 运行（10+3），最多 2 个不可用
• 更新速度最快，但对资源消耗最大
• 适合非高峰期的大规模更新

关键公式：更新过程中，集群中 Pod 总数的范围为：
replicas - maxUnavailable 到 replicas + maxSurge

2.2 ReplicaSet 的版本管理与垃圾回收机制

Deployment 的每次 Pod 模板变更都会创建一个新的 ReplicaSet，旧的 ReplicaSet 保留一定数量（由 revisionHistoryLimit 控制）用于回滚。但这里有一个容易被忽略的细节：

spec:
  revisionHistoryLimit: 10   # 保留最近 10 个版本的 ReplicaSet

当 revisionHistoryLimit 被超过时，Kubernetes 会从最旧的版本开始删除对应的 ReplicaSet。这意味着：

• 如果回滚到 revision=1，但该 ReplicaSet 已被回收，回滚实际上会创建一个新的 ReplicaSet（模板与 revision=1 相同，但 Pod 标签哈希不同）
• 旧 ReplicaSet 的 Pod 会被更新为新 ReplicaSet 的 Pod，因此服务不会中断
• 但 kubectl rollout history 中记录的 revision 信息仍然保留

2.3 高级部署模式：蓝绿部署与金丝雀发布

虽然 Deployment 原生支持滚动更新，但滚动更新本身存在一个固有缺陷：它逐步替换 Pod，新旧版本会在短时间内共存，如果新旧版本不兼容（如数据库 schema 变更），滚动更新会导致请求路由到错误版本。

蓝绿部署（Blue-Green Deployment） 通过创建全新的 Deployment 来规避这个问题：

# 创建蓝色版本（当前稳定版）
kubectl apply -f deployment-blue.yaml

# 创建绿色版本（新版本），使用不同的标签
kubectl apply -f deployment-green.yaml

# 验证绿色版本就绪后，切换 Service 的 selector
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'

# 出现问题立即切回蓝色版本
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"blue"}}}'

金丝雀发布（Canary Deployment） 则是让一小部分流量流向新版本，逐步验证：

# 主 Deployment（95% 流量）
kubectl scale deployment myapp-stable --replicas=19

# 金丝雀 Deployment（5% 流量）
kubectl scale deployment myapp-canary --replicas=1

然后在 Service 层面通过标签选择器让两个版本同时接收流量，或者使用 Service Mesh（如 Istio）进行更精细的流量分割。

---

三、实战步骤

3.1 生产级 Deployment 配置模板

以下是一个适用于生产环境的 Deployment 配置，包含了健康检查、资源限制、优雅关闭和调度策略：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: production-app
  namespace: production
  labels:
    app: production-app
    environment: production
    managed-by: argo
spec:
  replicas: 5
  selector:
    matchLabels:
      app: production-app
  template:
    metadata:
      labels:
        app: production-app
        version: v2.3.0
    spec:
      terminationGracePeriodSeconds: 60   # 优雅关闭等待时间
      containers:
      - name: app
        image: registry.example.com/app:v2.3.0
        ports:
        - containerPort: 8080
          protocol: TCP
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 1000m
            memory: 1Gi
        livenessProbe:           # 存活探针：容器挂了就重启
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:          # 就绪探针：流量只发给就绪的 Pod
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 2
        startupProbe:            # 启动探针：慢启动应用避免误杀
          httpGet:
            path: /startup
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 30
        lifecycle:
          preStop:               # 优雅关闭：先停止接收新请求，再等待处理中的请求完成
            exec:
              command: ["/bin/sh", "-c", "sleep 10 && /app/pre-stop.sh"]
      affinity:
        podAntiAffinity:           # Pod 反亲和：尽量分散到不同节点
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - production-app
              topologyKey: kubernetes.io/hostname
      topologySpreadConstraints:   # 拓扑分布约束：跨可用区均匀分布
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: production-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 30
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 600

3.2 使用 Argo Rollouts 实现渐进式交付

Argo Rollouts 是 Kubernetes 原生的渐进式交付控制器，为 Deployment 提供了蓝绿部署、金丝雀发布、自动分析回滚等高级功能。

# argo-rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: production-app
spec:
  replicas: 10
  selector:
    matchLabels:
      app: production-app
  template:
    metadata:
      labels:
        app: production-app
    spec:
      containers:
      - name: app
        image: registry.example.com/app:v2.3.0
        ports:
        - containerPort: 8080
  strategy:
    canary:
      steps:
      - setWeight: 10       # 第一步：10% 流量
      - pause: {duration: 5m}  # 暂停 5 分钟观察
      - setWeight: 30       # 第二步：30% 流量
      - pause: {duration: 5m}
      - setWeight: 60
      - pause: {duration: 5m}
      - setWeight: 100      # 最终：100% 流量
      analysis:
        templates:
        - templateName: success-rate  # 自动分析成功率
        startingStep: 1               # 从第一步开始分析
        args:
        - name: service-name
          value: production-app-svc

配合 Prometheus 监控指标自动分析发布质量，如果错误率飙升，Argo Rollouts 会自动中止并回滚：

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 30s
    successCondition: result[0] >= 0.95
    failureLimit: 3
    provider:
      prometheus:
        query: >
          sum(rate(
            http_requests_total{service="{{args.service-name}}",status=~"2..|3.."}[5m]
          )) / sum(rate(
            http_requests_total{service="{{args.service-name}}"}[5m]
          ))

3.3 PodDisruptionBudget：保障节点维护时的部署可用性

当集群节点需要维护（如内核升级、硬件维修）时，kubectl drain 会驱逐节点上的 Pod。如果没有 PodDisruptionBudget（PDB），所有 Pod 可能同时被驱逐，导致服务不可用。

# pdb-production-app.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: production-app-pdb
spec:
  minAvailable: 4          # 最少保持 4 个 Pod 可用（replicas=5）
  selector:
    matchLabels:
      app: production-app

PDB 的关键参数：

• minAvailable：指定维护期间必须保持可用的最小 Pod 数量（绝对值或百分比）
• maxUnavailable：指定维护期间允许不可用的最大 Pod 数量（绝对值或百分比）

两者只能指定一个。例如 minAvailable: 4 等价于 maxUnavailable: 1（当 replicas=5 时）。

3.4 Deployment 故障排查实战

问题一：滚动更新卡住（Progressing 状态为 False）

# 查看 Deployment 状态
kubectl describe deployment production-app

# 查看滚动更新事件
kubectl get events --field-selector involvedObject.name=production-app --sort-by=.lastTimestamp

# 检查 ReplicaSet 状态
kubectl get replicaset -l app=production-app

# 检查 Pod 状态
kubectl get pods -l app=production-app

# 查看 Pod 日志
kubectl logs -l app=production-app --tail=50

# 常见原因：
# 1. 镜像拉取失败（镜像不存在、认证失败、拉取策略问题）
# 2. 资源不足（节点 CPU/内存不够新 Pod 调度）
# 3. 就绪探针失败（新版本应用启动慢或 /ready 端点返回非 200）
# 4. PDB 阻止了旧 Pod 的终止（minAvailable 限制）

问题二：回滚后流量异常

如果回滚后出现 502/503 错误，通常是以下原因：

# 1. 检查 Service 的 Endpoint 是否指向正确的 Pod
kubectl get endpoints production-app-svc

# 2. 检查回滚后的 ReplicaSet 是否就绪
kubectl rollout status deployment/production-app

# 3. 如果回滚后旧版本 Pod 的 readinessProbe 在新的环境中失败
#    （例如依赖的数据库 schema 已经变更无法回退）
#    解决方案：通过 kubectl set image 手动指定旧版本镜像
kubectl set image deployment/production-app app=registry.example.com/app:v2.2.0

问题三：maxSurge/maxUnavailable 配置不当导致资源争抢

# 症状：滚动更新时出现大量 Pending 状态的 Pod
kubectl get pods -o wide | grep Pending

# 排查：查看节点资源使用情况
kubectl describe nodes | grep -A 5 "Allocated resources"

# 解决方案：降低 maxSurge 或减少 replicas，确保集群有足够的资源余量

---

四、常见问题

Q1：Deployment 滚动更新时，如何处理数据库 schema 变更？

这是生产环境中最棘手的问题之一。滚动更新会导致新旧版本共存，如果新版本依赖新的数据库 schema 而旧版本不兼容，旧 Pod 可能会崩溃。

推荐方案： 采用向后兼容的 schema 变更策略：

1. 第一阶段：先执行新增字段/表的迁移，不删除旧字段
2. 第二阶段：滚动更新应用代码，新版本使用新字段，旧版本继续使用旧字段
3. 第三阶段：所有 Pod 更新完成后，再清理旧字段

如果需要彻底隔离新旧版本，考虑使用蓝绿部署 + 独立的数据库迁移流程。

Q2：Deployment 的 progressDeadlineSeconds 超时后会发生什么？

Deployment 会被标记为 Progressing=False 状态，但不会自动回滚。K8s 只会停止尝试推进更新，你需要手动介入：

# 手动回滚
kubectl rollout undo deployment/production-app

# 或者手动修复问题后继续
kubectl rollout resume deployment/production-app

Q3：多个 Deployment 更新时，如何控制更新顺序？

对于依赖链中的微服务（如 A → B → C），建议：

1. 使用 Init Containers 等待依赖服务就绪
2. 借助 ArgoCD 或 Flux 的 sync waves 功能控制部署顺序
3. 使用 Service Mesh（如 Istio）的流量管理实现平滑切换

---

五、总结

本文从生产运维的角度深入探讨了 Deployment 的高级用法：

1. 滚动更新调优：通过 maxSurge/maxUnavailable 的精细配置，在更新速度和资源消耗之间找到平衡
2. 高级部署模式：蓝绿部署和金丝雀发布规避了滚动更新中新旧版本共存的问题
3. 渐进式交付：Argo Rollouts 提供了自动化的金丝雀分析与自动回滚能力
4. PDB 保障：PodDisruptionBudget 确保节点维护时服务不中断
5. 故障排查：滚动更新卡住、回滚异常、资源争抢的实战排查方法

掌握这些技巧，你就能在生产环境中自信地管理 Deployment 的每一次发布。记住：好的部署策略不是让发布变快，而是让发布失败时的恢复变快。

---

下期预告： 第 5 天将深入 Service 与网络基础——从 ClusterIP 到 LoadBalancer，再到 DNS 解析与服务发现，全面解析 K8s 的网络模型。

系列目录： K8s 系列 30 天从入门到生产运维