1. 滚动升级概述
1.1 什么是滚动升级
滚动升级（Rolling Update）是一种渐进式、零停机的节点或应用更新策略。在 Kubernetes 集群治理中，滚动升级通过逐个替换旧版本节点/ Pod，用新版本实例逐步接管流量，确保在整个变更过程中集群始终对外提供服务。
与“蓝绿部署”或“一次性全部替换”不同，滚动升级的核心思想是：每次只更新一小部分，通过控制“不可用实例数”和“峰值超出实例数”两个关键水位，将变更风险控制在可接受范围内。
核心定义：滚动升级 = 分批 + 健康检查 + 流量切换 + 回滚能力。它不是简单的“逐个重启”，而是一套包含优雅排空、Pod 迁移、就绪探针、最大不可用预算的完整治理流程。
1.2 滚动升级在 Kubernetes 集群治理中的核心价值
在节点池升级、内核补丁、kubelet 版本更新等场景中，滚动升级是保障集群稳定性、可用性、安全性的基石。其核心价值体现在以下五个维度：
| 价值维度 | 说明 | 关键指标 |
|---|---|---|
| 零停机 | 升级过程中业务 Pod 持续运行，客户端无感知 | 服务可用性 ≥ 99.99% |
| 风险可控 | 通过 maxUnavailable / maxSurge 控制变更步长 | 单批次故障影响面 ≤ 1/N |
| 自动回滚 | 健康检查失败时自动暂停并回退到上一版本 | 回滚触发时间 ≤ 30s |
| 资源高效 | 无需额外预留 100% 资源，节省集群成本 | 资源冗余率降低 40%-60% |
| 可观测性 | 升级进度、Pod 迁移状态、节点健康度全程可追踪 | 升级进度可视化覆盖率 100% |
运维经验：在生产环境中，滚动升级的“最大不可用预算”通常设置为 25%（即一次只允许 1/4 的节点不可用），既能保证升级速度，又能保留足够的冗余容量应对突发流量。
1.3 滚动升级 vs 其他升级策略对比
为了更清晰地理解滚动升级的定位，下表对比了 Kubernetes 集群中常见的三种升级策略：
| 对比维度 | 滚动升级 | 蓝绿部署 | 一次性替换 |
|---|---|---|---|
| 停机时间 | 零停机 | 零停机（切换瞬间） | 有停机窗口 |
| 资源消耗 | 低（复用现有资源） | 高（需双倍资源） | 低 |
| 回滚速度 | 中等（逐批回滚） | 快（流量切回旧环境） | 慢（需重新部署） |
| 适用场景 | 节点池升级、应用小版本更新 | 重大版本发布、数据库迁移 | 测试环境、非关键节点 |
| 风险暴露面 | 逐步暴露，可随时暂停 | 一次性暴露，切换后风险集中 | 全量暴露，风险最高 |
1.4 滚动升级的核心流程
一个标准的节点池滚动升级流程包含以下 6 个步骤：
- 节点排空（Drain）：标记节点为不可调度，驱逐已有 Pod，等待 Pod 优雅终止。
- 节点下线/替换：销毁旧节点实例，创建新节点实例（或原地升级 kubelet 版本）。
- 节点就绪检查：等待新节点通过 NodeReady 条件、kubelet 健康检查、节点条件验证。
- Pod 重新调度：新节点加入集群后，调度器将待调度 Pod 分配到新节点。
- 应用健康验证：通过 ReadinessProbe / StartupProbe 确认 Pod 正常提供服务。
- 进入下一批次：当前批次全部健康后，自动或手动触发下一批节点升级。
常见陷阱：排空节点时如果 PodDisruptionBudget（PDB）设置过严，可能导致节点排空卡死。建议 PDB 的 maxUnavailable 与滚动升级的 maxUnavailable 保持协调，避免互相阻塞。
1.5 滚动升级架构图
下图展示了滚动升级过程中节点状态变化与 Pod 迁移的完整流程：
1.6 滚动升级的 Kubernetes 原生支持
Kubernetes 原生提供了两种滚动升级机制，分别面向工作负载和节点层面：
- Deployment 滚动更新：通过
strategy.type: RollingUpdate控制 Pod 的滚动替换，适用于无状态应用。 - 节点池滚动升级：通过云厂商的节点组/节点池管理 API 或
kubectl drain+ 节点替换脚本实现，适用于集群基础设施升级。
课程聚焦：本课程重点讲解节点池层面的滚动升级，包括节点排空策略、Pod 迁移优化、PDB 协调、升级速率控制等 SRE 核心技能。后续章节将深入每个环节的实战配置与故障排查。
1.7 滚动升级的典型触发场景
| 场景 | 触发原因 | 升级对象 | 风险等级 |
|---|---|---|---|
| Kubernetes 版本升级 | kubelet / kube-proxy 版本落后 | 节点 kubelet | 中 |
| 操作系统内核补丁 | 安全漏洞修复（如 CVE） | 节点 OS 内核 | 高 |
| 容器运行时升级 | containerd / Docker 版本更新 | 节点容器运行时 | 中 |
| 节点规格变更 | 实例类型调整（如 CPU/内存扩容） | 节点实例规格 | 低 |
| 节点池扩缩容 | 集群容量规划调整 | 节点数量 | 低 |
最佳实践：建议将滚动升级与集群的维护窗口对齐，在业务低峰期执行。同时开启
cluster-autoscaler 的扩容保护，避免升级过程中触发意外的节点扩缩容。