【从零造容器】Cgroups v2：让容器不能吃掉整台机器
内容提要
本文讨论了Linux中的控制组（Cgroups）v2，强调其统一层级结构的优势，解决了v1的设计缺陷。介绍了创建Cgroup、设置资源限制（CPU、内存、IO）及监控和调试的方法，特别指出内存的软限制（memory.high）和硬限制（memory.max）的重要性，以及有效管理OOM（内存溢出）事件。最后提到Cgroups与容器运行时的关系，强调合理配置资源在容器管理中的重要性。
关键要点
-
Cgroups v2 统一层级结构解决了 v1 的设计缺陷，简化了资源管理。
-
Cgroups v2 通过文件系统接口创建和管理控制组，使用 mkdir 和 echo 命令。
-
CPU 控制通过 cpu.max 和 cpu.weight 设置，前者为硬限制，后者为相对权重。
-
内存控制使用 memory.max（硬限制）和 memory.high（软限制），后者在达到限制时减缓内存分配。
-
IO 控制通过 io.max 和 io.weight 设置，解决了 v1 中对 buffered IO 的限制无效问题。
-
Cgroups v2 与容器运行时（如 Docker 和 Kubernetes）紧密集成，合理配置资源对容器管理至关重要。
-
内存溢出（OOM）事件管理通过 memory.oom.group 选项实现，确保整个 cgroup 一起被杀死。
-
Cgroups v2 的设计避免了竞争条件和复杂性，提升了系统稳定性和可预测性。
延伸解读
Cgroups v2 的优势
Cgroups v2 通过统一层级结构解决了 v1 的设计缺陷，简化了资源管理。所有控制器共享同一棵树，避免了竞争条件和复杂性，提升了系统的稳定性和可预测性。这一改进对于容器管理尤为重要，确保了资源限制的有效性。
内存管理的最佳实践
在内存控制中，设置 memory.high 作为软限制比 memory.max 的硬限制更为重要。合理配置这两个参数可以有效避免 OOM 事件，给系统提供缓冲时间以处理内存压力。建议将 memory.high 设置在 memory.max 的 85-90% 左右，以便在接近限制时减缓内存分配。
CPU 限制的潜在风险
使用 CFS 带宽控制时，设置过低的 CPU 限制可能导致频繁的节流，从而增加请求延迟。监控 cpu.stat 中的 nr_throttled 和 throttled_usec 指标，可以帮助识别 CPU 限制是否过紧。建议在生产环境中合理配置 cpu.max 和 cpu.weight，以确保系统性能。
延伸问答
Cgroups v2 的主要优势是什么？
Cgroups v2 通过统一层级结构解决了 v1 的设计缺陷，简化了资源管理，避免了竞争条件和复杂性，提升了系统稳定性和可预测性。
如何在 Cgroups v2 中设置 CPU 资源限制？
在 Cgroups v2 中，可以通过设置 cpu.max 和 cpu.weight 来限制 CPU 资源，cpu.max 设置硬限制，cpu.weight 设置相对权重。
Cgroups v2 中的内存软限制和硬限制有什么区别？
内存硬限制（memory.max）一旦超过会触发 OOM killer，而内存软限制（memory.high）则在达到限制时减缓内存分配，避免进程被杀。
如何监控 Cgroups v2 中的资源使用情况？
可以通过读取 cgroup 目录下的控制文件，如 memory.current 和 cpu.stat，来监控资源使用情况。
Cgroups v2 如何处理内存溢出事件？
Cgroups v2 通过 memory.oom.group 选项实现组杀，确保一旦触发 OOM，整个 cgroup 内的所有进程一起被杀。
Cgroups v2 与容器运行时的关系是什么？
Cgroups v2 与容器运行时（如 Docker 和 Kubernetes）紧密集成，合理配置资源对容器管理至关重要。
