Kubernetes 自 1.35 版本起不再支持 cgroup v1。若集群节点仍使用 cgroup v1，升级到 Kubernetes 1.35 及以上版本后，节点上的 kubelet 可能无法正常启动，进而影响节点注册、Pod 调度和业务运行。

cgroup v2 采用统一的层级结构和改进的资源管理机制，是 Kubernetes 后续版本持续演进的基础能力。建议您在升级集群版本前，将节点迁移至支持 cgroup v2 的操作系统镜像，并提前验证业务容器、监控采集组件和运维脚本对 cgroup v2 的兼容性。

适用场景

本文适用于以下场景：

• 准备将 CCE 集群升级到 Kubernetes 1.35 或更高版本。
• 集群中存在使用 cgroup v1 的节点或节点组。
• 创建、编辑、复制节点组时，需要选择符合后续 Kubernetes 版本要求的操作系统镜像。
• 更换节点组操作系统时，需要确认目标镜像的 cgroup 版本。

背景信息

Linux 内核通过 cgroup 限制、记录和隔离进程组使用的 CPU、内存、I/O 等资源。cgroup 包含 v1 和 v2 两个版本：

如果应用、Agent 或运维脚本直接读取 /sys/fs/cgroup 下的文件，迁移到 cgroup v2 后可能需要适配路径、文件名或指标含义。迁移前请优先在测试集群或灰度节点组中验证。

注意事项

• Kubernetes 1.35 及以上版本要求节点操作系统支持 cgroup v2。使用 cgroup v1 的节点不建议继续用于 1.35 及以上版本集群。
• 集群升级前，CCE 会对节点 cgroup 版本进行兼容性检查。若检测到不兼容的 cgroup v1 节点，升级可能被阻断。请先完成节点迁移后再发起升级。
• 创建 Kubernetes 1.35 及以上版本集群或节点组时，请选择支持 cgroup v2 的操作系统镜像。控制台中不再推荐选择 cgroup v1 镜像。
• 迁移节点通常涉及节点替换、Pod 驱逐和业务重新调度。请提前评估容量水位、PodDisruptionBudget、亲和性、Local PV、DaemonSet、静态 Pod 和业务高可用策略。
• 若节点上运行自建组件、监控采集器、安全 Agent 或资源隔离相关脚本，请确认这些组件已支持 cgroup v2。

迁移流程

建议按以下顺序完成迁移：

1. 检查集群中节点的 cgroup 版本。
2. 评估业务和节点组件对 cgroup v2 的兼容性。
3. 创建或准备使用 cgroup v2 的新节点组。
4. 将业务从 cgroup v1 节点迁移到 cgroup v2 节点。
5. 删除或下线 cgroup v1 节点。
6. 重新执行集群升级前置检查，并升级集群。

步骤一：检查节点 cgroup 版本

您可以登录节点后执行以下命令，检查当前节点使用的 cgroup 版本：

1stat -fc %T /sys/fs/cgroup/

根据命令输出判断 cgroup 版本：

如需批量检查多个节点，可结合运维工具或登录各节点执行上述命令。若 CCE 控制台或 API 已展示节点组镜像的 cgroup 版本标识，也可以直接在节点组相关页面确认。

步骤二：评估业务兼容性

迁移前，请重点检查以下内容：

• 应用是否直接读取 /sys/fs/cgroup 下的资源文件。
• 监控、日志、安全、弹性伸缩等节点组件是否依赖 cgroup v1 文件路径。
• 业务容器运行时、基础镜像、Sidecar、DaemonSet 是否支持 cgroup v2。
• 是否存在强依赖本地磁盘数据、Local PV 或节点固定调度的工作负载。
• 是否已配置合理的副本数、PodDisruptionBudget 和健康检查，避免迁移期间业务不可用。

建议先在测试环境或灰度节点组中创建 cgroup v2 节点，将少量业务迁移到新节点上观察运行状态。确认业务、监控和告警正常后，再逐步扩大迁移范围。

步骤三：创建 cgroup v2 节点组

在 CCE 控制台创建节点组时，请选择支持 cgroup v2 的操作系统镜像。若当前集群版本低于 Kubernetes 1.35，但后续计划升级到 1.35 或更高版本，也建议提前选择 cgroup v2 镜像，避免后续再次迁移。

创建节点组时请关注以下配置：

• 节点规格和数量应满足迁移期间的业务容量需求。
• 网络、存储、标签、污点、容器运行时等配置应与原节点组保持业务所需的一致性。
• 若通过复制节点组创建新节点组，请确认复制后的操作系统镜像是否为 cgroup v2 镜像。
• 若编辑节点组或更换节点组操作系统，请关注控制台展示的 cgroup 版本提醒，避免从 cgroup v2 回退到 cgroup v1。

支持 cgroup v2 的操作系统

在创建或更换节点组操作系统时，请在 CCE 控制台的公共镜像列表中选择支持 cgroup v2 的操作系统镜像。

当前公共镜像列表中，以下操作系统版本不支持 cgroup v2，不建议用于 Kubernetes 1.35 及以上版本集群：

• CentOS 7.x、CentOS 8.x
• BaiduLinux 3.x
• Ubuntu 18.x、Ubuntu 20.x
• Rocky Linux 8.x
  除上述版本外，公共镜像列表中的其他操作系统镜像均按支持 cgroup v2 处理。实际可选镜像以 CCE 控制台公共镜像列表展示为准。

步骤四：迁移工作负载

创建 cgroup v2 节点组后，将业务逐步迁移到新节点。常见方式如下：

1. 为新节点组设置业务需要的节点标签或污点。
2. 调整工作负载的 nodeSelector、节点亲和性或容忍配置，使新 Pod 可以调度到 cgroup v2 节点。
3. 分批驱逐 cgroup v1 节点上的 Pod，观察业务运行状态。
4. 确认业务稳定后，继续迁移下一批节点。

如需手动驱逐节点上的 Pod，可参考以下命令：

1kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

命令执行前，请确认业务具备足够副本和可用容量。对于使用本地存储、不可中断任务或特殊调度策略的工作负载，请按业务运维规范单独处理。

迁移完成并确认节点不再承载业务后，可将 cgroup v1 节点从集群中移除或删除对应节点组。

步骤五：升级集群前重新检查

迁移完成后，请再次检查集群中是否仍存在 cgroup v1 节点。确认所有需要参与升级的节点均已迁移到 cgroup v2 后，再发起 Kubernetes 1.35 或更高版本升级。

若升级前置检查提示仍存在 cgroup v1 节点，请根据提示定位对应节点或节点组，完成迁移或下线后重新执行升级检查。

常见问题

为什么升级到 Kubernetes 1.35 前必须处理 cgroup v1 节点？

Kubernetes 1.35 起不再支持 cgroup v1。节点操作系统仍使用 cgroup v1 时，kubelet 可能无法正常启动，节点可能无法加入集群或维持正常运行。因此，升级前需要先将节点迁移到 cgroup v2。

cgroup v1 节点是否可以继续运行在低版本集群中？

低于 Kubernetes 1.35 的集群中，cgroup v1 节点可能仍可运行。但如果后续计划升级到 Kubernetes 1.35 或更高版本，建议提前迁移到 cgroup v2，降低升级窗口内的迁移风险。

是否支持一键将节点从 cgroup v1 转换为 cgroup v2？

不建议直接在原节点上修改 cgroup 模式。推荐创建使用 cgroup v2 操作系统镜像的新节点组，将业务迁移到新节点后，再下线原 cgroup v1 节点。该方式更便于灰度验证和故障回退。

迁移后业务指标发生变化怎么办？

cgroup v1 和 cgroup v2 的部分资源文件路径和指标含义不同。若迁移后监控指标、资源统计或告警规则异常，请检查采集组件和自定义脚本是否已适配 cgroup v2。