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% |
滚动更新流程:
- 用户更新 Deployment 的 Pod 模板(如镜像版本)
- Deployment 创建新的 ReplicaSet,期望副本数为 0
- 根据
maxSurge和maxUnavailable逐步创建新 Pod,同时终止旧 Pod - 新 Pod 通过就绪探针检测后开始接收流量
- 旧 ReplicaSet 副本数逐步缩减至 0
灾备风险: 如果镜像拉取失败或资源不足,滚动更新可能卡住。建议设置
progressDeadlineSeconds 并监控更新进度。
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,验证后再全量 | 零停机 | 低到中 | 灰度测试,逐步放量 |
2.6 灾备场景下的 Deployment 最佳实践
- 版本历史保留: 设置
revisionHistoryLimit: 10,确保有足够的回滚版本 - 更新超时控制: 设置
progressDeadlineSeconds: 300,避免更新卡死 - 就绪探针: 配置
readinessProbe,确保新 Pod 真正就绪后才接收流量 - 资源预留: 滚动更新时
maxSurge需要额外资源,确保集群有足够余量 - 监控与告警: 监控
kubectl rollout status状态,异常时自动触发回滚
常见陷阱: 如果
maxUnavailable: 0 且 maxSurge: 0,滚动更新将无法进行。至少保证一个参数大于 0。