cgroup là gì?

cgroup (control group) là một tính năng của Linux kernel để giới hạn, ưu tiên và theo dõi tài nguyên (CPU, memory, I/O, số process...) của một nhóm process.

Điểm bất ngờ với newbie: cgroup không phải một câu lệnh hay một daemon. Nó là một virtual filesystem. Bạn điều khiển nó bằng cách read / write file trong thư mục /sys/fs/cgroup. Không có syscall riêng — chỉ là đọc ghi file thông thường.

Hai khái niệm cốt lõi cần phân biệt:

cgroups vs namespaces

cgroups gắn liền với namespaces — nhưng hai cơ chế này giải quyết hai bài toán hoàn toàn khác nhau. Chúng trực giao (orthogonal): độc lập với nhau, và chỉ khi gộp lại mới tạo thành một container đúng nghĩa.

Có thể dùng độc lập

cgroup không cần namespace: systemd-run -p MemoryMax=500M ... giới hạn một service nhưng nó vẫn chạy trên host bình thường, thấy mọi thứ.

namespace không cần cgroup: một process bị cô lập tầm nhìn nhưng không bị giới hạn tài nguyên — vẫn ngốn hết RAM host được. Container chỉ ra đời khi runtime gọi cả hai.

cgroups nằm ở đâu?

Hiểu lầm phổ biến: nghĩ cgroup tự nó "giới hạn" tài nguyên. Thực ra cgroup chỉ là lớp kế toán và policy — nó hook vào các cơ chế lõi của kernel, và chính những cơ chế đó mới thực thi việc giới hạn.

Cụ thể từng controller hook vào đâu:

Hai nhánh — cgroup (xanh lá) và namespace (tím) — chạy song song và độc lập trong kernel. Chúng chỉ gặp nhau ở chỗ runtime gọi cả hai để dựng container.

cgroup v1 vs v2

Có hai phiên bản cgroup tồn tại song song. Khác biệt lớn nhất nằm ở cách tổ chức cây thư mục. Hầu hết hệ thống mới (Ubuntu 22.04+, RHEL 9, systemd hiện đại, EKS AL2023) đã mặc định v2.

Hai quy tắc quan trọng của v2

1. "No internal process" rule: một cgroup không thể vừa chứa process vừa có controller bật cho cgroup con. Process chỉ được nằm ở leaf node (nút lá). Đây là lý do systemd tổ chức cây theo slice/scope.

2. Top-down enabling: controller phải được bật từ parent xuống thông qua file cgroup.subtree_control. Con không thể có controller mà cha chưa cấp.

Tự tay tạo một cgroup

Cách tốt nhất để hiểu là làm thủ công. Ví dụ dưới đây (cgroup v2) tạo một group giới hạn 100MB RAM và 50% một CPU core, không cần Docker hay K8s gì cả.

# Tạo một cgroup con (chỉ là mkdir một thư mục)
mkdir /sys/fs/cgroup/demo

# Bật controller cho cgroup con (ghi vào subtree_control của CHA)
echo "+cpu +memory" > /sys/fs/cgroup/cgroup.subtree_control

# Giới hạn memory 100MB
echo 104857600 > /sys/fs/cgroup/demo/memory.max

# Giới hạn CPU: 50% của 1 core → "quota period" (đơn vị micro giây)
# 50000 / 100000 = 50%
echo "50000 100000" > /sys/fs/cgroup/demo/cpu.max

# Đưa shell hiện tại vào cgroup
echo $$ > /sys/fs/cgroup/demo/cgroup.procs

# Giờ mọi process spawn từ shell này đều bị giới hạn
stress --vm 1 --vm-bytes 200M   # → bị OOMKilled vì vượt 100M

Các file điều khiển hay dùng (v2)

systemd quản lý cgroup thế nào

Trên hệ thống hiện đại, systemd là cgroup manager mặc định. Mọi process chạy đều nằm trong cây này, tổ chức theo 3 loại đơn vị:

# Tạo limit nhanh không cần đụng cgroupfs thủ công
systemd-run --scope -p MemoryMax=500M -p CPUQuota=50%   stress --vm 1 --vm-bytes 600M

# Xem cây cgroup realtime (như top nhưng cho cgroup)
systemd-cgtop

Docker flags map xuống cgroup

Docker chỉ là wrapper. Khi bạn chạy docker run --memory 100m, runc tạo một scope trong system.slice rồi ghi đúng các file cgroup bạn vừa thấy ở tầng Linux — giống hệt lúc bạn mkdir + echo thủ công.

Bảng quy đổi flag → file

requests vs limits

Đây là phần quan trọng nhất — và là nguồn gốc của hầu hết hiểu lầm. Mấu chốt: requests và limits KHÔNG map xuống cùng một loại file cgroup.

Hệ quả thực tế

CPU limit thấp → throttle dù node còn rảnh. Vì cpu.max là hard cap theo chu kỳ. Nhiều team bỏ CPU limit hẳn (chỉ giữ request) để tránh throttle oan với service nhạy độ trễ.

Memory không có "throttle". Chỉ có dùng được hoặc bị giết. Vượt memory.max = OOMKilled, không có vùng đệm như CPU.

QoS class quyết định thứ tự bị giết

K8s dựng cây 3 tầng dưới kubepods.slice. Khi node hết RAM (memory pressure), thứ tự eviction + OOM là: besteffort chết trước → burstable → guaranteed chết cuối.

# Trên node: xem cây cgroup của pods
systemd-cgls /kubepods.slice

# Đường cgroup thật của một container (v2)
# /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/
#   kubepods-burstable-pod<uid>.slice/cri-containerd-<id>.scope/

cat .../cpu.max         # 50000 100000  ← limit 500m
cat .../cpu.stat        # nr_throttled  ← bằng chứng throttling
cat .../memory.max      # 536870912     ← limit 512Mi
cat .../memory.current  # đang dùng bao nhiêu

Một cơ chế, ba tầng

Cùng một file cgroup xuyên suốt cả ba tầng — chỉ khác lớp abstraction phía trên. Hiểu tầng dưới cùng thì mọi hành vi lạ ở tầng trên đều giải thích được mà không cần đoán.

Checklist debug nhanh