1. 课程导论：什么是滚动升级？为什么需要节点亲和性？节点池的概念与价值
在生产环境中，Kubernetes 集群的节点并非一成不变。操作系统补丁、kubelet 版本升级、内核参数调优、GPU 驱动更新等操作，都要求对节点进行变更。如何在不中断业务的前提下完成这些变更，是集群运维的核心挑战。本课程将围绕滚动升级、节点亲和性与节点池三个关键概念，构建一套完整的节点配置变更实战体系。
1.1 什么是滚动升级？
滚动升级（Rolling Update）是一种逐步替换实例的变更策略，在 Kubernetes 中广泛应用于 Deployment、DaemonSet 等工作负载的 Pod 更新，同样适用于节点池中节点的配置变更。其核心思想是：一次只更新一小部分实例，始终保持可用实例数不低于阈值，从而将变更风险控制在最小范围。
maxUnavailable（最大不可用数）和 maxSurge（最大额外数）两个参数控制变更速率。例如，maxUnavailable=25% 表示升级过程中最多允许 25% 的 Pod 不可用。
滚动升级相比蓝绿部署、金丝雀部署的优势在于：无需额外资源预留，变更过程自动回滚，且对集群资源利用率影响最小。在节点池场景中，滚动升级表现为：逐台替换节点，新节点使用新配置，旧节点排空后销毁。
1.2 为什么需要节点亲和性？
节点亲和性（Node Affinity）是 Kubernetes 调度系统提供的精细化调度规则，用于控制 Pod 可以部署到哪些节点上。在节点池升级场景中，亲和性承担着流量导流和配置隔离的双重角色。
| 场景 | 无节点亲和性 | 有节点亲和性 |
|---|---|---|
| 节点配置变更 | Pod 可能被调度到正在升级的节点，导致连接中断 | Pod 只调度到已就绪的新节点，业务无感 |
| GPU 驱动升级 | 旧驱动节点上的 Pod 无法利用新驱动特性 | 通过亲和性将 GPU 任务定向到新驱动节点 |
| 多规格节点池 | Pod 随机分布，无法利用高性能节点 | 关键业务 Pod 通过亲和性绑定高配节点 |
requiredDuringSchedulingIgnoredDuringExecution 强制新 Pod 调度到新节点，同时配合 preferredDuringSchedulingIgnoredDuringExecution 实现软偏好，确保升级过程中调度器的灵活性。
1.3 节点池的概念与价值
节点池（Node Pool）是云原生环境中对一组同配置节点的逻辑抽象。在托管 Kubernetes 服务（如 AKS、EKS、GKE）中，节点池通常对应一组使用相同虚拟机规格、操作系统、磁盘类型和初始化脚本的节点实例。
节点池的核心价值体现在以下三个方面：
- 配置统一管理：节点池内的所有节点共享相同的 kubelet 参数、内核参数、标签和污点，变更只需修改节点池模板，无需逐台操作。
- 滚动升级载体：节点池天然支持滚动升级操作——创建新节点池实例，逐步迁移 Pod，销毁旧节点池，整个过程由云平台或自动化工具编排。
- 资源隔离与混合部署：通过创建多个节点池（如 CPU 池、GPU 池、高内存池），结合节点亲和性，实现不同业务负载的物理隔离和资源保障。
1.4 三者协同：课程核心脉络
本课程将滚动升级作为变更手段，节点亲和性作为调度控制，节点池作为配置管理单元，三者形成完整的节点配置变更闭环：
- 定义节点池模板：包含节点规格、初始化脚本、kubelet 参数、标签和污点。
- 配置节点亲和性规则：确保关键业务 Pod 始终调度到符合要求的节点池。
- 执行滚动升级：创建新节点池实例，逐步排空旧节点，验证新节点运行状态。
- 验证与回滚：通过监控指标确认升级成功，异常时快速切回旧节点池。
接下来的课程中，我们将从节点池的创建与配置开始，逐步深入到滚动升级策略的调优、节点亲和性规则的编写，以及生产环境中的故障排查与自动化方案。通过 30 章的系统学习，你将具备独立设计和实施 Kubernetes 节点池滚动升级的能力。