1. 课程导论：Deployment 滚动更新机制概述、集群升级对业务的影响、节点池治理的重要性
1.1 Deployment 滚动更新机制概述
Deployment 是 Kubernetes 中最常用的工作负载控制器，其核心能力之一便是滚动更新（Rolling Update）。该机制允许以零停机或低停机的方式，逐步将 Pod 实例从旧版本替换为新版本。理解其底层运作原理，是诊断中断和规划集群升级的前提。
核心目标：在更新过程中，始终保持一定数量的 Pod 可用（Ready），同时控制不可用 Pod 的数量上限，从而保障业务连续性。
滚动更新的行为由两个关键参数控制：
| 参数 | 默认值 | 含义 |
|---|---|---|
maxSurge |
25% | 更新期间，允许超出期望副本数（Replicas）的最大 Pod 数量。可以是数值或百分比。 |
maxUnavailable |
25% | 更新期间，允许相对于期望副本数不可用的最大 Pod 数量。可以是数值或百分比。 |
下图展示了 Deployment 滚动更新的典型流程：
1.2 集群升级对业务的影响
Kubernetes 集群升级（如 kube-apiserver、kubelet、kube-scheduler 等组件版本更新）是一项高风险运维操作。升级过程中，控制平面组件和节点组件的重启、API 版本废弃、资源对象的兼容性变化，都可能直接或间接影响运行中的 Deployment。
主要影响维度如下：
- Pod 重建与驱逐：节点升级（如 kubelet 重启或操作系统更新）通常会导致节点上的 Pod 被重新调度，触发 Deployment 的滚动更新或重建。
- API 兼容性中断：升级后，旧的 API 版本可能被废弃（如
extensions/v1beta1的 Ingress），导致 Deployment 使用的资源定义无法被新集群识别。 - 控制平面抖动：升级期间，kube-apiserver 可能短暂不可用，影响 Deployment 控制器、HPA、Service 等组件的正常协调。
- 节点资源压力：大规模节点升级时，大量 Pod 同时被驱逐，可能造成集群资源碎片化或节点过载。
常见故障模式：集群升级后，Deployment 的
maxUnavailable 设置不当，导致升级过程中可用 Pod 数量低于业务容忍阈值，引发服务降级或中断。
1.3 节点池治理的重要性
节点池（Node Pool）是云原生环境中对节点进行分组管理的核心抽象。在集群升级场景下，节点池治理直接决定了升级的可控性、灰度策略和故障隔离能力。
良好的节点池治理能够带来以下收益：
| 治理维度 | 收益描述 |
|---|---|
| 灰度升级 | 按节点池分批升级，先升级测试池或金丝雀池，验证业务稳定性后再升级生产池。 |
| 故障隔离 | 将关键业务与非关键业务部署在不同节点池，升级非关键池时不影响核心服务。 |
| 资源预留 | 为系统组件（如 kube-system）预留独立节点池，避免业务 Pod 挤占系统资源导致升级失败。 |
| 快速回滚 | 升级失败时，可快速将节点池回滚至旧镜像或配置，而不影响其他池。 |
下图展示了基于节点池的分批升级策略：
最佳实践：建议至少划分 3 个节点池：系统池（运行集群关键组件）、金丝雀池（运行测试或低风险业务）、生产池（运行核心业务）。升级时严格遵循“金丝雀 → 生产”的顺序，并设置合理的 PodDisruptionBudget（PDB）保护关键 Deployment。