在 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的 “整合性”。

1. 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 層級管控）。

2. 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 個關鍵維度展開，直接影響容器部署的穩定性與可維護性：

四、為什麼 Docker 官方推薦 Systemd 驅動？

在 Docker 1.12 + 版本後，官方明確建議在 Systemd 系統中使用systemd驅動，核心原因可歸結為兩點：

1. 避免資源管理衝突，提升穩定性

若系統使用 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），步驟如下：

1. 查看當前 Docker 的 Cgroup Driver

首先通過docker info命令查看當前驅動（關鍵看Cgroup Driver字段）：

docker info | grep “Cgroup Driver”

輸出示例（cgroupfs驅動）：Cgroup Driver: cgroupfs

輸出示例（systemd驅動）：Cgroup Driver: systemd

2. 配置 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”]
}

3. 重啓 Docker 服務，生效配置

修改配置後，需重啓 Docker 服務使配置生效：

重啓Docker

systemctl daemon-reload
systemctl restart docker

驗證配置（再次查看Cgroup Driver）

docker info | grep “Cgroup Driver”

六、兩種驅動該如何選？

實際部署中，驅動的選擇完全取決於Linux 系統的 init 進程，無需過度複雜的評估：

七、總結

Docker 的 Cgroup Driver 選擇，本質是 “Docker 如何與 Linux 系統 Cgroups 管理邏輯協同” 的問題：cgroupfs是 Docker “獨來獨往” 的原生方案，適合非 Systemd 系統；systemd是 Docker “融入系統” 的整合方案，適合主流 Systemd 系統，也是官方與 K8s（Kubernetes）的推薦選擇。

在當前 Linux 發行版普遍採用 Systemd 的背景下，優先選擇 Systemd 驅動是規避資源衝突、降低運維成本的最佳實踐。若需切換驅動，只需修改daemon.json並重啓 Docker，無需複雜的遷移操作 —— 這也是 Docker 對系統整合性的優化，讓容器資源管理更貼合現代 Linux 的運維邏輯。