3. Deployment 基础：ReplicaSet、Pod 模板、滚动更新策略、声明式配置
Deployment 是 Kubernetes 中最常用的工作负载控制器，它通过声明式配置管理 Pod 的副本数量、更新策略与回滚操作。理解 Deployment 的底层组件与运行机制，是进行节点扩容与资源调度的前提。本节将拆解 Deployment 的四个核心要素：ReplicaSet、Pod 模板、滚动更新策略与声明式配置。
3.1 核心组件：ReplicaSet 与 Pod 模板
Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接控制 Pod 的副本数量与生命周期。每个 Deployment 在创建或更新时，都会生成一个对应的 ReplicaSet，该 ReplicaSet 持有完整的 Pod 模板副本。
| 组件 | 职责 | 关键字段 |
|---|---|---|
| Deployment | 声明期望状态（副本数、更新策略、回滚配置） | replicas, strategy, revisionHistoryLimit |
| ReplicaSet | 确保指定数量的 Pod 副本始终运行 | replicas, selector, template |
| Pod 模板 | 定义 Pod 的容器、卷、标签、资源请求与限制 | spec.template.spec.containers, resources |
3.2 滚动更新策略
滚动更新是 Deployment 默认的更新方式，它通过逐步替换旧版本 Pod 来减少服务中断。更新策略由 spec.strategy.rollingUpdate 控制，核心参数包括 maxSurge 和 maxUnavailable。
- maxSurge：更新期间允许超出期望副本数的最大 Pod 数量（可以是数或百分比）。例如
maxSurge: 25%表示最多允许超出期望副本数的 25%。 - maxUnavailable：更新期间允许不可用的最大 Pod 数量。例如
maxUnavailable: 1表示最多允许 1 个 Pod 不可用。
maxSurge: 25% 和 maxUnavailable: 25%，在保证可用性的同时加快更新速度。对于有状态应用，建议使用 maxUnavailable: 0 确保零中断。
3.3 声明式配置与 YAML 清单
Deployment 采用声明式配置模型，用户只需在 YAML 文件中定义期望状态，控制器会自动将实际状态调整为期望状态。以下是一个完整的 Deployment 示例，包含副本数、Pod 模板、资源限制与滚动更新策略。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
readinessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10spec.selector 与 template.metadata.labels 不匹配，Deployment 将无法管理 Pod。另外，replicas 字段在 HPA（水平 Pod 自动扩缩）启用时会被覆盖，不要同时手动修改。
3.4 声明式配置的优势与操作对比
| 操作方式 | 示例命令 | 适用场景 | 风险 |
|---|---|---|---|
| 声明式（推荐） | kubectl apply -f deployment.yaml |
生产环境、CI/CD 流水线、版本管理 | 低，YAML 文件可审计、可回滚 |
| 命令式 | kubectl set image deployment/web-app nginx=nginx:1.26 |
快速调试、临时变更 | 中，变更不可追溯，容易覆盖 |
| 直接编辑 | kubectl edit deployment web-app |
紧急修复、单次调整 | 高，容易误操作，无版本记录 |
kubectl diff 预览变更后再执行 kubectl apply。对于扩容操作，直接修改 replicas 字段并重新 apply 即可触发 ReplicaSet 调整。
3.5 回滚机制与版本管理
Deployment 默认保留最近 10 个版本的 ReplicaSet 历史记录（由 revisionHistoryLimit 控制）。当滚动更新出现问题时，可以快速回滚到上一个稳定版本。
- 查看更新历史：
kubectl rollout history deployment/web-app - 回滚到上一版本：
kubectl rollout undo deployment/web-app - 回滚到指定版本：
kubectl rollout undo deployment/web-app --to-revision=2
回滚操作会创建一个新的 ReplicaSet，其 Pod 模板与目标版本一致，然后执行与滚动更新相同的逐步替换流程。这意味着回滚本身也是一次受控的滚动更新，不会中断服务。
3.6 扩容场景中的 Deployment 行为
当需要增加 Pod 副本数以应对流量增长时，只需修改 spec.replicas 字段。Deployment 会立即更新对应的 ReplicaSet，ReplicaSet 再创建新的 Pod。如果集群节点资源不足，新 Pod 会处于 Pending 状态，等待调度器分配可用节点。