升级 Kubernetes，不能只核对控制面和组件版本。这份写好标智库技术笔记聚焦一个容易遗漏的前置检查：Linux 节点的 cgroup 模式，以及围绕它的组件兼容性。
先查节点，再升级
cgroup 是 Linux 管理容器 CPU、内存等资源的基础。cgroup v2 采用统一层级和更一致的接口，但迁移不能只看 Kubernetes 版本：
- v1.25 起：cgroup v2 支持进入稳定阶段。
- v1.31 起：cgroup v1 支持进入维护模式。
- v1.35 起：
failCgroupV1默认为true，cgroup v1 节点上的 kubelet 默认无法启动。
因此，当前运行低于 v1.35 版本的集群，在升级到 v1.35 或更高版本前，应迁移全部 Linux 节点，或明确安排临时设置 failCgroupV1: false。已经运行 v1.35 及以上版本的集群，也需要逐节点确认，不能仅凭集群版本判断迁移是否完成。
failCgroupV1: false 不是长期方案。 这一覆盖配置后续的移除将遵循弃用政策，不应将其当作持续保留 cgroup v1 的保证。
别漏掉 kubeadm 预检
检测到 cgroup v1 时，kubeadm 的处理取决于 kubelet 版本：
| kubelet 版本 | 初始化、加入和升级时的预检行为 |
|---|---|
| v1.35 及以上 | 报错 |
| 更早版本 | 警告 |
升级计划需要同时考虑 kubelet 的启动条件和 kubeadm 的预检行为。
节点切换成功，不等于整体适配完成
盘点节点模式之后，还要检查容器运行时、资源采集组件和告警规则是否兼容 cgroup v2，重点核对它们对以下内容的依赖：
- cgroup 层级结构；
- 资源控制与读取接口；
- 指标含义及其在告警规则中的使用方式。
节点能够启动，只能说明部分检查已经通过，不能据此认定监控和告警也已完成适配。
内存驱逐问题需要单独评估
迁移到 cgroup v2 不会自动解决内存驱逐问题。kubelet 仍将 active_file 视为不可回收，I/O 密集型负载可能因页缓存触发内存压力。
对于这类负载，可以在测量实际内存行为后，考虑将内存 requests 与 limits 设置为相等值，而不是把 cgroup 模式切换当作直接修复手段。
不要把 Memory QoS 当作稳定能力
Memory QoS 仅适用于 Linux cgroup v2 节点：它自 v1.22 引入，在 v1.27 更新，到 v1.36 仍为 alpha。
评估升级收益时，需要把“可以使用的实验性能力”与“稳定功能承诺”区分开，不能因为迁移到 v2，就默认新增内存保护能力已经适合按稳定功能依赖。
升级前检查清单
- [ ] 逐一确认所有 Linux 节点的 cgroup 模式。
- [ ] 核对目标 kubelet 版本与
failCgroupV1配置。 - [ ] 检查 kubeadm 初始化、加入和升级的预检影响。
- [ ] 如需临时保留 cgroup v1，明确覆盖配置及后续迁移安排。
- [ ] 确认容器运行时、资源采集组件和告警规则对 v2 的兼容性。
- [ ] 对 I/O 密集型负载单独测量内存压力与驱逐行为。
- [ ] 将 Memory QoS 的 alpha 状态纳入功能评估。
核心原则是：把兼容性核查放在升级窗口之前，而不是等 kubelet 启动失败或监控异常后再补做。
