1. Deployment 基础概念：Deployment 的作用、与 ReplicaSet 和 Pod 的关系、声明式更新机制
Deployment 是 Kubernetes 中用于管理无状态工作负载的核心 API 对象。它通过声明式配置驱动控制器循环，确保集群中的 Pod 副本数量、版本和运行状态始终与用户期望保持一致。理解 Deployment 是掌握集群容量规划与节点扩容的前提——因为所有资源分配最终都落脚于 Pod 的调度与副本管理。
1.1 Deployment 的核心作用
- 声明式副本管理：定义
replicas字段，控制器保证指定数量的 Pod 始终运行。 - 滚动更新与回滚：支持零停机更新应用版本，更新失败时可快速回退到历史版本。
- 自愈能力：当 Pod 因节点故障、资源不足或进程崩溃而终止时，Deployment 自动创建替换 Pod。
- 扩缩容：通过修改
replicas或结合 HPA（Horizontal Pod Autoscaler）动态调整副本数，是容量规划的直接入口。 - 版本追踪：每次更新都会生成新的 ReplicaSet，保留历史版本用于审计和回滚。
容量规划视角：Deployment 的
replicas 和 resources.requests/limits 直接决定了集群需要预留的 CPU 和内存总量。节点扩容方案通常以 Deployment 的副本数增长作为触发条件。
1.2 Deployment、ReplicaSet 与 Pod 的层级关系
三者构成 Kubernetes 工作负载管理的经典三层架构：Deployment → ReplicaSet → Pod。Deployment 不直接管理 Pod，而是通过 ReplicaSet 实现副本控制。
| 对象 | 职责 | 生命周期 | 与上层关系 |
|---|---|---|---|
| Deployment | 声明式版本管理、滚动策略、回滚 | 长期存在，随应用版本迭代更新 | 创建并管理 ReplicaSet |
| ReplicaSet | 确保指定数量的 Pod 副本运行 | 每次 Deployment 更新生成新 RS，旧 RS 保留用于回滚 | 被 Deployment 控制，直接管理 Pod |
| Pod | 运行容器化应用实例，拥有独立 IP 和存储 | 短暂易失，可能因调度、资源、健康检查而重建 | 由 ReplicaSet 创建和回收 |
关键区别：ReplicaSet 只保证副本数量，Deployment 在此基础上增加了版本控制、更新策略和回滚能力。在生产环境中，永远不要直接操作 ReplicaSet 或 Pod，所有变更都应通过 Deployment 的声明式配置进行。
1.3 声明式更新机制
声明式更新是 Deployment 区别于传统运维脚本的核心特征。用户只需提交期望状态（YAML/JSON），控制器持续调和当前状态直至匹配。
更新流程（滚动更新）
- 提交新版本：修改 Deployment 的
spec.template（如镜像版本），通过kubectl apply或 API 提交。 - 创建新 ReplicaSet：Deployment 控制器检测到模板变更，自动创建新 ReplicaSet，初始副本数为 0。
- 渐进式替换：按
spec.strategy.rollingUpdate.maxSurge和maxUnavailable参数，逐步扩容新 RS、缩容旧 RS。 - 健康检查：新 Pod 通过 readiness probe 后才继续下一批替换，确保服务不中断。
- 完成或回滚：新 RS 副本数达到
replicas，旧 RS 缩容至 0；若新版本异常，可执行kubectl rollout undo回退。
容量规划影响：滚动更新期间，集群需要同时运行新旧两个版本的 Pod（
maxSurge 决定额外副本数）。如果集群资源紧张，可能导致更新阻塞或 Pod 驱逐。规划节点容量时，必须将 maxSurge 和 maxUnavailable 纳入资源余量计算。
声明式 vs 命令式 对比
| 特性 | 声明式（Deployment） | 命令式（kubectl run / scale） |
|---|---|---|
| 操作方式 | 提交期望状态 YAML | 直接执行命令 |
| 可审计性 | YAML 可版本化管理（GitOps） | 命令无持久记录 |
| 回滚能力 | 内置历史版本回滚 | 需手动恢复 |
| 自动修复 | 控制器持续调和 | 无自动修复 |
| 扩缩容 | 修改 replicas 字段 | kubectl scale 命令 |
1.4 与容量规划的关联
Deployment 的副本数和资源请求直接决定了集群的资源水位。在节点扩容方案中，以下 Deployment 属性是核心输入：
spec.replicas：目标副本数，决定 Pod 总量。spec.template.spec.containers[].resources.requests：每个 Pod 预留的 CPU 和内存，用于计算集群总需求。spec.strategy.rollingUpdate.maxSurge：滚动更新期间的额外资源开销。spec.template.spec.nodeSelector / affinity：影响 Pod 在节点间的分布，间接决定扩容策略。
实践建议：在集群中为每个 Deployment 设置
resources.requests 和 limits，并开启 cluster-autoscaler。当 Deployment 副本数增加导致节点资源不足时，自动触发节点扩容。这是 Kubernetes 容量规划的标准模式。