Docker的Cgroup Driver设置为Cgroupfs 和 Systemd 的区别

原创已于 2025-11-25 09:27:27 修改 · 750 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-11-25 09:23:02 首次发布

在 Docker 容器化部署中，资源限制是保障容器集群稳定的核心能力，无论是限制容器的 CPU 使用率、内存上限，还是块设备 I/O 吞吐量，本质上都依赖 Linux 内核的 Cgroups（Control Groups）机制。而 Docker 与 Cgroups 的交互，需要通过 “Cgroup Driver（Cgroup 驱动）” 作为中间接口：目前 Docker 支持两种主流驱动 ——cgroupfs和systemd。

两者的核心差异，本质是 Docker 与 Linux 系统 Cgroups 管理逻辑的 “交互方式不同”：cgroupfs是 Docker 独立操作 Cgroups 的原生接口，systemd则是 Docker 融入系统 init 进程（Systemd）Cgroups 层级的整合方案。本文将从 Docker 的应用场景出发，详解两种驱动的实现逻辑、核心差异及选择建议。

一、Docker 为何需要 Cgroup Driver？

在深入区别前，需先明确 Cgroup Driver 在 Docker 中的核心作用：Docker 的核心功能之一是 “容器资源隔离”，而这一功能完全依赖 Linux 内核的 Cgroups 机制。但 Docker 无法直接与内核 Cgroups 交互，必须通过Cgroup Driver作为 “翻译”，它定义了 Docker 如何创建、管理容器对应的 Cgroups 规则，以及如何将容器进程绑定到 Cgroups 层级中。

简单来说：Cgroup Driver 是 Docker 与 Cgroups 之间的 “交互协议”，不同协议对应不同的资源管理逻辑，直接影响容器与系统服务的资源隔离效果。

二、Docker 如何与 Cgroups 交互？

要理解两者的区别，首先需拆解它们在 Docker 环境中的具体实现方式，这背后关联了cgroupfs的 “独立性” 与systemd的 “整合性”。

Cgroupfs 驱动：Docker 独立管理 Cgroups

cgroupfs是 Docker 早期默认的 Cgroup 驱动，其核心逻辑是Docker 绕过系统 init 进程，直接通过 Cgroups 原生虚拟文件系统（/sys/fs/cgroup）管理容器资源。

cgroup有两个版本，核心区别见：cgroup v1 和 cgroup v2 的核心区别 - WuJing’s Blog
（1）实现流程

当 Docker 使用cgroupfs驱动时，创建容器的资源管理流程如下：

1.Docker 启动时，自动检测/sys/fs/cgroup下的 Cgroups 子系统（如cpu、memory、blkio）；
2.当创建一个带资源限制的容器（如docker run --memory=512M nginx）时，Docker 会：
    在/sys/fs/cgroup/[子系统]/docker/[容器ID]/目录下创建专属 Cgroups 目录（如/sys/fs/cgroup/memory/docker/abc123/）；
    通过echo命令将资源限制写入该目录下的配置文件（如echo 536870912 > memory.limit_in_bytes，限制内存 512M）；
    将容器内的所有进程 PID 写入tasks文件，完成容器与 Cgroups 的绑定。
3.容器运行期间，Docker 通过读取/sys/fs/cgroup/[子系统]/docker/[容器ID]/下的统计文件（如memory.usage_in_bytes），获取容器资源消耗情况。

（2）核心特点

独立性：Docker 的 Cgroups 管理完全独立于系统 init 进程（如 Systemd），不依赖系统级的 Cgroups 层级；
原生性：直接操作 Cgroups 原生文件系统，逻辑简单直观，无额外封装；
隔离性局限：若系统使用 Systemd 作为 init 进程，Systemd 自身也会管理/sys/fs/cgroup/systemd/层级的 Cgroups，可能与 Docker 的cgroupfs管理产生 “资源争夺”（例如同一进程被两个 Cgroups 层级管控）。

Systemd 驱动：Docker 融入系统 Cgroups 层级

随着 Systemd 成为主流 Linux 发行版（如 CentOS 7+、Ubuntu 16.04+）的默认 init 进程，Docker 推出了systemd驱动，其核心逻辑是Docker 不再独立管理 Cgroups，而是将容器作为 Systemd 的 “Scope/Slice”，融入系统原生的 Cgroups 层级。
（1）前置：Systemd 的 Cgroups 层级模型

Systemd 本身会将系统所有进程纳入 Cgroups 层级管理，核心依赖三种 Unit 类型：

Slice：纯层级容器，用于分类资源（如system.slice管理系统服务，machine.slice管理虚拟机 / 容器）；
Scope：封装外部创建的进程组（如 Docker 容器、用户会话）；
Service：封装 Systemd 启动的进程（如nginx.service）。

当 Docker 使用systemd驱动时，会自动遵循这一层级，每个 Docker 容器都会被封装为一个 Systemd Scope，归属到machine.slice下（如machine-docker-[容器ID].scope）。
（2）实现流程

以docker run --memory=512M nginx为例，systemd驱动的资源管理流程：

Docker 启动时，检测到系统使用 Systemd，自动对接/sys/fs/cgroup/systemd/层级；
创建容器时，Docker 会请求 Systemd 创建一个专属 Scope（如machine-docker-abc123.scope），并将容器进程绑定到该 Scope；
资源限制（如 512M 内存）通过 Systemd 的接口（而非直接写文件）传入，Systemd 自动将限制同步到/sys/fs/cgroup/[子系统]/machine.slice/machine-docker-abc123.scope/目录下；
容器运行期间，Docker 可通过 Systemd 命令（如systemctl status machine-docker-abc123.scope）或systemd-cgtop工具，查看容器资源消耗。

（3）核心特点

整合性：容器的 Cgroups 完全融入系统层级，与 Systemd 管理的系统服务（如cron.service、sshd.service）共享统一的资源管理逻辑；
无冲突：避免了cgroupfs与 Systemd 的资源争夺问题（因容器属于 Systemd 的 Scope，由 Systemd 统一管控）；
便捷性：可通过 Systemd 工具（如systemd-cgtop）统一监控容器与系统服务的资源，无需单独操作 Docker 命令。

三、Cgroupfs vs Systemd

基于上述实现逻辑，两种驱动在 Docker 场景下的差异可从 5 个关键维度展开，直接影响容器部署的稳定性与可维护性：

对比维度	Cgroupfs 驱动	Systemd 驱动
与系统 init 进程的关系	完全独立，不依赖 Systemd	深度整合，依赖 Systemd 的 Cgroups 层级
Cgroups 层级归属	容器 Cgroups 在`/sys/fs/cgroup/[子系统]/docker/`下	容器 Cgroups 在`/sys/fs/cgroup/[子系统]/machine.slice/`下
资源冲突风险	高：若系统用 Systemd，可能出现 “双管控” 冲突	低：由 Systemd 统一管控，无冲突
监控工具	依赖 Docker 命令（如`docker stats`）	支持 Docker 命令 + Systemd 工具（如`systemd-cgtop`）
配置复杂度	简单：Docker 自动管理，无需额外配置	较简单：需确保系统为 Systemd，Docker 自动适配
主流兼容性	兼容所有 Linux 系统，但逐渐被边缘化	主流推荐（Docker 官方、K8s 官方推荐），仅支持 Systemd 系统

四、为什么 Docker 官方推荐 Systemd 驱动？

在 Docker 1.12 + 版本后，官方明确建议在 Systemd 系统中使用systemd驱动，核心原因可归结为两点：

避免资源管理冲突，提升稳定性

若系统使用 Systemd 作为 init 进程（可通过cat /proc/1/comm命令查看），Systemd 会默认将所有进程（包括 Docker daemon）纳入自身的 Cgroups 层级（/sys/fs/cgroup/systemd/）。此时若 Docker 使用cgroupfs驱动，会出现 “双重管控”：

Docker 通过cgroupfs将容器绑定到/sys/fs/cgroup/[子系统]/docker/；
Systemd 同时将 Docker daemon 及容器进程绑定到/sys/fs/cgroup/systemd/下的层级。

这种冲突可能导致资源限制失效（如容器实际内存超过配置上限）、进程归属混乱，甚至触发系统级的资源泄漏。而systemd驱动通过将容器纳入 Systemd 的 Scope，完全规避了这一问题。
2. 统一系统与容器的资源管理，降低运维成本

使用systemd驱动后，运维人员可通过一套工具（Systemd 工具链）管理系统服务与容器：

用systemd-cgtop实时监控所有进程（包括 Nginx 服务、Docker 容器）的 CPU / 内存占用；
用systemctl查看容器的资源配置（如systemctl show machine-docker-abc123.scope -p MemoryLimit）；
若系统启用了资源配额（如 Systemd 的 Slice 资源限制），容器会自动遵循系统级的配额规则，无需单独为 Docker 配置。

五、Docker 如何配置 Cgroup Driver？

无论是新部署 Docker，还是从cgroupfs切换到systemd，只需修改 Docker 的 daemon 配置文件（daemon.json），步骤如下：

查看当前 Docker 的 Cgroup Driver

首先通过docker info命令查看当前驱动（关键看Cgroup Driver字段）：

docker info | grep “Cgroup Driver”

输出示例（cgroupfs驱动）：Cgroup Driver: cgroupfs

输出示例（systemd驱动）：Cgroup Driver: systemd

配置 Cgroup Driver

Docker 的核心配置文件为/etc/docker/daemon.json（若不存在则新建），添加"exec-opts": [“native.cgroupdriver=驱动类型”]：
（1）配置为 Systemd 驱动（推荐，Systemd 系统）

{
“exec-opts”: [“native.cgroupdriver=systemd”]
}

（2）配置为 Cgroupfs 驱动（非 Systemd 系统或特殊场景）

{
“exec-opts”: [“native.cgroupdriver=cgroupfs”]
}

重启 Docker 服务，生效配置

修改配置后，需重启 Docker 服务使配置生效：

重启Docker

systemctl daemon-reload
systemctl restart docker

验证配置（再次查看Cgroup Driver）

docker info | grep “Cgroup Driver”

六、两种驱动该如何选？

实际部署中，驱动的选择完全取决于Linux 系统的 init 进程，无需过度复杂的评估：

系统环境	推荐驱动	原因分析
系统 init 为 Systemd（如 CentOS 7+、Ubuntu 16.04+、RHEL 7+）	Systemd 驱动	避免资源冲突，支持统一监控，符合官方推荐
系统 init 为非 Systemd（如 CentOS 6、Debian 7）	Cgroupfs 驱动	无 Systemd，无法使用 Systemd 驱动，只能选 cgroupfs
特殊场景（如 Docker 独立部署，无其他系统服务）	Cgroupfs 驱动	无冲突风险，配置简单，满足基础资源限制需求

七、总结

Docker 的 Cgroup Driver 选择，本质是 “Docker 如何与 Linux 系统 Cgroups 管理逻辑协同” 的问题：cgroupfs是 Docker “独来独往” 的原生方案，适合非 Systemd 系统；systemd是 Docker “融入系统” 的整合方案，适合主流 Systemd 系统，也是官方与 K8s（Kubernetes）的推荐选择。

在当前 Linux 发行版普遍采用 Systemd 的背景下，优先选择 Systemd 驱动是规避资源冲突、降低运维成本的最佳实践。若需切换驱动，只需修改daemon.json并重启 Docker，无需复杂的迁移操作 —— 这也是 Docker 对系统整合性的优化，让容器资源管理更贴合现代 Linux 的运维逻辑。

你的点赞、收藏和关注这是对我最大的鼓励。