以下是 Kubernetes 中?cgroups（Control Groups）?的詳細解析，涵蓋其核心原理、在 Kubernetes 中的具體應用及實踐操作：

一、cgroups 基礎概念

1.?是什么？

• cgroups?是 Linux 內核提供的?資源隔離與控制機制，用于限制、統計和監控進程組（如容器）的資源使用。

• 可管理的資源類型：

  • CPU：分配核心數、時間片權重

  • 內存：限制最大使用量、Swap 控制

  • I/O：磁盤和網絡帶寬限制

  • 進程數：防止 fork bomb

  • 設備訪問：限制特定設備使用

2.?核心組件

組件	功能
Hierarchy	樹狀層級結構，每個層級綁定一個或多個子系統（如 CPU、Memory）
Subsystem	資源控制器（如?cpu、memory、blkio），負責具體資源管理
Cgroup	層級中的節點，包含一組進程及其資源限制規則
Task	進程（線程），屬于某個 cgroup，資源受其規則約束

3.?cgroup v1 vs v2

特性	cgroup v1	cgroup v2
層級結構	多層級，每個子系統獨立	單一層級，統一管理所有子系統
資源分配模型	分散控制	統一權重分配（如?cpu.weight）
內存控制	memory.limit_in_bytes	memory.max
兼容性	廣泛支持	需較新內核（≥4.15）

二、Kubernetes 中的 cgroups 實現

1.?資源模型

Kubernetes 通過?Resource Requests/Limits?定義容器的資源需求，底層由容器運行時（如 containerd、Docker）轉換為 cgroup 配置。

resources:requests:cpu: "500m"    # 0.5 CPU 核心memory: "1Gi"   # 1 GB 內存limits:cpu: "1"       # 1 CPU 核心memory: "2Gi"   # 內存硬限制

2.?核心子系統映射

Kubernetes 參數	cgroup 子系統	關鍵文件/參數
CPU Requests	cpu	cpu.shares（權重）
CPU Limits	cpu	cpu.cfs_period_us?+?cpu.cfs_quota_us
Memory Limits	memory	memory.limit_in_bytes（v1）或?memory.max（v2）
HugePages	hugetlb	hugetlb.<size>.limit_in_bytes
Ephemeral Storage	blkio（部分）	通過 XFS 配額或?blkio.throttle?控制

3.?cgroup 路徑結構

容器 cgroup 路徑示例（v1）：

# 查看容器進程的 cgroup
$ cat /proc/<PID>/cgroup# 示例輸出：
12:memory:/kubepods/burstable/pod<UID>/<容器ID>
3:cpu,cpuacct:/kubepods/burstable/pod<UID>/<容器ID>

Kubernetes 層級命名規則：

/kubepods/[QoS-Class]/pod<Pod-UID>/<Container-ID>

• QoS Class：burstable（彈性）、besteffort（盡力而為）、guaranteed（保證）

三、實戰操作：驗證 cgroup 配置

1.?查看容器的 cgroup 限制

進入容器所在節點的 cgroup 目錄（以內存為例）：

# 查找容器對應的 cgroup 路徑
$ CONTAINER_ID=$(docker ps | grep <容器名> | awk '{print $1}')
$ CGROUP_PATH=$(docker inspect $CONTAINER_ID | grep -i cgroup | grep memory | head -1 | cut -d'"' -f4)# 查看內存限制
$ cat /sys/fs/cgroup/memory/$CGROUP_PATH/memory.limit_in_bytes
2147483648  # 2Gi

2.?動態調整 cgroup 參數（調試用）

# 臨時修改 CPU 配額（慎用！）
echo 50000 > /sys/fs/cgroup/cpu/$CGROUP_PATH/cpu.cfs_quota_us  # 限制為 50ms/100ms 周期

四、Kubernetes 資源 QoS 與 cgroup

1.?QoS 等級

QoS 級別	條件	cgroup 表現
Guaranteed	所有容器設置?limits=requests	高優先級，cpu.shares?根據 requests 分配，內存不足時最后被 OOMKill
Burstable	至少一個容器設置?requests<limits?或未設置 limits	中等優先級，資源超用時可能被限制或終止
BestEffort	所有容器未設置?requests?和?limits	最低優先級，資源緊張時優先被終止

2.?OOM 處理機制

• 當節點內存不足時，OOM Killer?按優先級終止容器：

  • BestEffort?→ 2.?Burstable?→ 3.?Guaranteed

• 查看 OOM 事件：

  dmesg | grep -i "oom"
  journalctl -k | grep -i "oom"

五、高級配置

1.?自定義 cgroup 驅動

Kubernetes 支持兩種 cgroup 驅動：

• cgroupfs：直接寫入 cgroup 文件系統（默認）。

• systemd：通過 systemd 管理 cgroup（需節點使用 systemd）。

配置 kubelet 使用 systemd 驅動：

--cgroup-driver=systemd

2.?設置 cgroup 根目錄

調整 kubelet 參數：

--cgroup-root=/custom-cgroup

3.?Reserved Resources

為系統進程預留資源，避免容器占用全部資源：

# kubelet 配置
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
systemReserved:cpu: "500m"memory: "1Gi"

六、常見問題排查

1.?容器被 OOMKilled

• 檢查點：

  kubectl describe pod <pod-name> | grep -i "OOM"
  kubectl get events --field-selector=reason=OOMKilled

• 解決：調整?spec.containers[].resources.limits.memory

2.?CPU 節流（Throttling）

• 檢查點：

  kubectl top pod --containers
  cat /sys/fs/cgroup/cpu/$CGROUP_PATH/cpu.stat | grep nr_throttled

• 解決：優化應用 CPU 使用或增加?limits.cpu

總結

• 核心作用：Kubernetes 通過 cgroups 實現容器資源隔離，保障多租戶環境穩定性。

• 配置關鍵：合理設置?requests/limits，結合 QoS 策略優化資源分配。

• 調試工具：docker stats、kubectl top、直接查看 cgroup 文件系統。