2. Deployment 基础回顾:创建、副本管理、滚动更新与回滚机制

Deployment 是 Kubernetes 中最常用的工作负载控制器,它提供了声明式更新、副本管理、滚动更新与回滚等核心能力。在灾备场景中,理解 Deployment 的基础机制是配置镜像拉取策略、资源限制与 QoS 的前提。本节将系统回顾 Deployment 的创建、副本管理、滚动更新与回滚机制。

2.1 Deployment 的创建与声明式管理

Deployment 通过 YAML 清单文件定义期望状态,由 Kubernetes 控制面持续协调实际状态与期望状态。以下是一个典型的 Deployment 定义:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

创建 Deployment 的常用命令:

  • kubectl apply -f deployment.yaml —— 声明式创建或更新
  • kubectl create deployment web-app --image=nginx:1.25 --replicas=3 —— 命令式快速创建
  • kubectl get deployments —— 查看 Deployment 列表
  • kubectl describe deployment web-app —— 查看详细状态
最佳实践: 生产环境始终使用 kubectl apply 声明式管理,确保 YAML 文件作为单一事实来源,便于版本控制和灾备恢复。

2.2 副本管理机制

Deployment 通过 ReplicaSet 管理 Pod 副本。每次更新都会创建新的 ReplicaSet,旧的 ReplicaSet 保留用于回滚。副本管理的关键参数:

参数 说明 默认值 灾备建议
replicas 期望运行的 Pod 副本数 1 生产环境至少 2-3 个副本
revisionHistoryLimit 保留的历史版本数 10 灾备场景建议保留 5-10 个版本
progressDeadlineSeconds 滚动更新超时时间 600 根据镜像拉取时间适当调整
minReadySeconds Pod 就绪后等待时间 0 建议设置 30-60 秒,避免瞬态故障

副本扩缩容操作:

  • kubectl scale deployment web-app --replicas=5 —— 手动扩缩
  • kubectl autoscale deployment web-app --min=3 --max=10 --cpu-percent=80 —— 自动扩缩(HPA)
灾备要点: 在灾备切换场景中,副本数应快速调整以应对流量突增。建议结合 HPA 和 PDB(PodDisruptionBudget)确保最小可用副本数。

2.3 滚动更新机制

滚动更新是 Deployment 的默认更新策略,通过逐步替换旧版本 Pod 实现零停机更新。核心参数在 spec.strategy.rollingUpdate 中定义:

参数 说明 默认值 示例
maxSurge 更新期间允许超出期望副本数的最大 Pod 数 25% maxSurge: 1 或 maxSurge: 30%
maxUnavailable 更新期间允许不可用的最大 Pod 数 25% maxUnavailable: 0 或 maxUnavailable: 20%

滚动更新流程:

  1. 用户更新 Deployment 的 Pod 模板(如镜像版本)
  2. Deployment 创建新的 ReplicaSet,期望副本数为 0
  3. 根据 maxSurge 和 maxUnavailable 逐步创建新 Pod,同时终止旧 Pod
  4. 新 Pod 通过就绪探针检测后开始接收流量
  5. 旧 ReplicaSet 副本数逐步缩减至 0
灾备风险: 如果镜像拉取失败或资源不足,滚动更新可能卡住。建议设置 progressDeadlineSeconds 并监控更新进度。
滚动更新流程示意图 用户更新镜像 创建新 ReplicaSet 逐步创建新 Pod 就绪探针检测 终止旧 Pod 旧 ReplicaSet 缩至 0 更新完成 关键参数: maxSurge=25% 允许超出期望副本数 25%;maxUnavailable=25% 允许最多 25% 的 Pod 不可用

2.4 回滚机制

当滚动更新出现故障(如镜像拉取失败、就绪探针失败、应用崩溃),Deployment 支持快速回滚到历史版本。回滚机制基于 ReplicaSet 的历史版本记录。

回滚相关命令:

  • kubectl rollout history deployment/web-app —— 查看更新历史
  • kubectl rollout history deployment/web-app --revision=3 —— 查看指定版本详情
  • kubectl rollout undo deployment/web-app —— 回滚到上一个版本
  • kubectl rollout undo deployment/web-app --to-revision=2 —— 回滚到指定版本
  • kubectl rollout status deployment/web-app —— 查看更新状态
灾备场景应用: 当新版本镜像拉取失败或应用启动异常时,自动回滚机制可快速恢复服务。建议在 CI/CD 流水线中集成 kubectl rollout status 监控更新状态,超时后自动触发回滚。

2.5 更新策略对比

策略 更新方式 停机时间 资源消耗 适用场景
滚动更新 逐步替换 Pod 零停机(配置合理时) 中等(需额外资源支持 maxSurge) 生产环境默认策略
重建 先删除所有旧 Pod,再创建新 Pod 有停机时间 低(无需额外资源) 开发环境或非关键应用
蓝绿部署 同时运行两套环境,切换流量 零停机 高(需双倍资源) 关键业务,需快速回滚
金丝雀发布 先更新少量 Pod,验证后再全量 零停机 低到中 灰度测试,逐步放量
Deployment 回滚机制 Deployment 控制器 ReplicaSet v3 ReplicaSet v2 ReplicaSet v1 回滚到 v2 v3 缩至 0 回滚原理: Deployment 保留历史 ReplicaSet,回滚时直接调整期望副本数,将旧版本 ReplicaSet 扩容,新版本缩容至 0

2.6 灾备场景下的 Deployment 最佳实践

  • 版本历史保留: 设置 revisionHistoryLimit: 10,确保有足够的回滚版本
  • 更新超时控制: 设置 progressDeadlineSeconds: 300,避免更新卡死
  • 就绪探针: 配置 readinessProbe,确保新 Pod 真正就绪后才接收流量
  • 资源预留: 滚动更新时 maxSurge 需要额外资源,确保集群有足够余量
  • 监控与告警: 监控 kubectl rollout status 状态,异常时自动触发回滚
常见陷阱: 如果 maxUnavailable: 0 且 maxSurge: 0,滚动更新将无法进行。至少保证一个参数大于 0。