这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
作者: David Porter (Google), Mrunal Patel (Red Hat)
Kubernetes 1.25 将 cgroup v2 正式发布（GA）， 让 kubelet 使用最新的容器资源管理能力。
有效的资源管理是 Kubernetes 的一个关键方面。 这涉及管理节点中的有限资源，例如 CPU、内存和存储。
cgroups 是一种可建立资源管理功能的 Linux 内核能力， 例如为正在运行的进程限制 CPU 使用率或设置内存限制。
当你使用 Kubernetes 中的资源管理能力时，例如配置 Pod 和容器的请求和限制， Kubernetes 会使用 cgroups 来强制执行你的资源请求和限制。
Linux 内核提供了两个版本的 cgroup：cgroup v1 和 cgroup v2。
cgroup v2 是 Linux cgroup API 的最新版本, 提供了一个具有增强的资源管理能力的统一控制系统。
自 2016 年以来，cgroup v2 一直在 Linux 内核中进行开发， 近年来在整个容器生态系统中已经成熟。在 Kubernetes 1.25 中， 对 cgroup v2 的支持已升级为正式发布。
默认情况下，许多最新版本的 Linux 发行版已切换到 cgroup v2， 因此 Kubernetes 继续在这些新更新的发行版上正常运行非常重要。
cgroup v2 对 cgroup v1 进行了多项改进，例如：
一些 Kubernetes 特性专门使用 cgroup v2 来增强资源管理和隔离。 例如，MemoryQoS 特性提高了内存利用率并依赖 cgroup v2 功能来启用它。kubelet 中的新资源管理特性也将利用新的 cgroup v2 特性向前发展。
许多 Linux 发行版默认切换到 cgroup v2； 你可能会在下次更新控制平面和节点的 Linux 版本时开始使用它！
推荐使用默认使用 cgroup v2 的 Linux 发行版。 一些使用 cgroup v2 的流行 Linux 发行版包括：
要检查你的发行版是否默认使用 cgroup v2， 请参阅你的发行版文档或遵循识别 Linux 节点上的 cgroup 版本。
如果你使用的是托管 Kubernetes 产品，请咨询你的提供商以确定他们如何采用 cgroup v2， 以及你是否需要采取行动。
要将 cgroup v2 与 Kubernetes 一起使用，必须满足以下要求：
kubelet 和容器运行时使用 cgroup 驱动 来设置 cgroup 参数。使用 cgroup v2 时，强烈建议 kubelet 和你的容器运行时都使用 systemd cgroup 驱动程序， 以便系统上只有一个 cgroup 管理员。要配置 kubelet 和容器运行时以使用该驱动程序， 请参阅 systemd cgroup 驱动程序文档。
当你使用启用 cgroup v2 的 Linux 发行版运行 Kubernetes 时，只要你满足要求， kubelet 应该会自动适应而无需任何额外的配置。
在大多数情况下，除非你的用户直接访问 cgroup 文件系统， 否则当你切换到使用 cgroup v2 时，不会感知到用户体验有什么不同。
如果你在节点上或从容器内直接访问 cgroup 文件系统的应用程序， 你必须更新应用程序以使用 cgroup v2 API 而不是 cgroup v1 API。
你可能需要更新到 cgroup v2 的场景包括：
随时欢迎你的反馈！SIG Node 定期开会，可在 Kubernetes Slack的
#sig-node 频道中获得，或使用 SIG 邮件列表。
cgroup v2 经历了漫长的旅程，是整个行业开源社区协作的一个很好的例子， 因为它需要跨堆栈的工作，从 Linux 内核到 systemd 到各种容器运行时，当然还有 Kubernetes。
我们要感谢 Giuseppe Scrivano 在 Kubernetes 中发起对 cgroup v2 的支持， 还要感谢 SIG Node 社区主席 Dawn Chen 和 Derek Carr 所作的审查和领导工作。
我们还要感谢 Docker、containerd 和 CRI-O 等容器运行时的维护者， 以及支持多种容器运行时的 cAdvisor 和 runc, libcontainer 等组件的维护者。 最后，如果没有 systemd 和上游 Linux 内核维护者的支持，这将是不可能的。