MicroK8s中cgroups-per-qos配置异常导致服务启动失败问题分析

问题现象

在MicroK8s环境中，当主机遭遇意外断电后重启时，kubelite服务无法正常启动。系统日志显示关键错误信息："Failed to start ContainerManager"并提示"root container [kubepods] doesn't exist"。该问题表现为在非正常关机后，Kubernetes的QoS(服务质量)容器组(cgroups)初始化失败。

技术背景

cgroups是Linux内核提供的资源隔离机制，Kubernetes利用它来实现Pod的资源管理和QoS保障。在Kubernetes中，cgroups层级结构通常以"kubepods"为根节点，下面分为三个QoS级别：

• BestEffort
• Burstable
• Guaranteed

当启用cgroups-per-qos功能时(默认开启)，kubelet会尝试创建和维护这些cgroups层级结构。如果根容器不存在，整个资源管理系统将无法初始化。

问题原因分析

根据技术分析，该问题可能由以下因素导致：

1. 非正常关机导致cgroups状态不一致：突然断电可能导致cgroups的层级结构未正确持久化或损坏。

2. MicroK8s版本升级遗留问题：用户环境经历了从1.26到1.29的连续升级过程，可能存在版本间cgroups管理机制的差异。

3. cgroups子系统未正确挂载：在某些系统配置下，cgroups文件系统可能未按预期挂载。

4. 资源控制器未启用：必要的cgroups控制器(如cpu、memory等)可能未被激活。

临时解决方案

目前可行的临时解决方案是在kubelet配置中添加：

--cgroups-per-qos=false

该参数会禁用基于QoS的cgroups隔离，但会牺牲部分资源管理能力。

根本解决方案建议

1. 检查cgroups挂载情况：确认/sys/fs/cgroup目录结构完整，各子系统正确挂载。

2. 验证cgroups控制器：确保所需控制器(cpu、memory等)在系统中可用且启用。

3. 清理残留cgroups：手动检查并清理可能存在的残留cgroups结构。

4. 重建cgroups层级：通过系统工具或重启相关服务重建正确的cgroups结构。

5. 考虑系统配置：检查系统是否使用了非标准的cgroups驱动或配置。

长期预防措施

1. 实施正常的关机流程，避免强制断电。

2. 在MicroK8s升级后安排系统重启，确保各组件完全同步。

3. 监控cgroups相关指标，提前发现潜在问题。

4. 考虑在关键环境中部署不间断电源(UPS)保护。

技术影响评估

禁用cgroups-per-qos虽然可以解决启动问题，但会带来以下影响：

1. 资源隔离能力下降，可能引发Pod间资源干扰。

2. QoS保障机制失效，关键业务可能无法获得承诺的资源。

3. 资源监控数据可能不准确。

建议在解决问题后尽快恢复该功能，以确保集群的稳定性和可靠性。