Jika Anda mengelola klaster Kubernetes di server Linux, ada satu perubahan besar yang perlu segera masuk daftar rencana kerja: cgroup v1 sudah resmi dianggap usang dan akan dihapus. Kubernetes blog menulis bahwa sejak Kubernetes v1.35, opsi failCgroupV1 bernilai true secara bawaan, artinya kubelet tidak akan start di node yang masih memakai cgroup v1. Pada rilis Kubernetes 1.36 (versi yang berlaku saat artikel sumber ditulis), cgroup v1 masih bisa dipakai sebagai fallback, tetapi opsi fallback itu dijadwalkan dicabut pada Kubernetes v1.38. Praktisnya: upgrade klaster tanpa menyiapkan node ke cgroup v2 berpotensi membuat node gagal bergabung atau gagal naik saat kubeadm upgrade.

Apa itu cgroup dan kenapa Kubernetes pindah ke v2

cgroups (control groups) adalah fitur kernel Linux untuk mengatur sumber daya sistem. Kubernetes memakai cgroup untuk membagi CPU dan memori ke tiap container agar aplikasi tidak saling mengganggu. Dukungan manajemen cgroup v2 sudah stabil di Kubernetes sejak v1.25, sedangkan dukungan v1 masuk mode maintenance sejak v1.31. Alasan utama pindah: cgroup v2 punya satu hierarki terpadu, antarmuka yang lebih konsisten, dan fondasi isolasi sumber daya yang lebih kuat untuk fitur-fitur modern.

Tenggat yang perlu dicatat

• Kubernetes v1.35 ke atas: failCgroupV1 default true; kubelet menolak start di node cgroup v1 kecuali admin menuliskan override sementara failCgroupV1: false.
• kubeadm: pemeriksaan preflight SystemVerification dari k8s.io/system-validators mengembalikan error saat kubeadm init, join, dan upgrade bila mendeteksi cgroup v1 dengan kubelet v1.35+. Pada kubelet versi lama, pemeriksaan yang sama hanya memberi peringatan.
• Fallback dihapus di v1.38: pekerjaan penghapusan dijalankan lewat KEP-5573 (Remove cgroup v1 support).

Keuntungan nyata yang Anda dapat di cgroup v2

• Memory QoS dengan proteksi bertingkat. Fitur ini hanya bisa jalan di node Linux bercgroup v2 karena bergantung pada memory controller v2: memory.high untuk throttling, serta memory.min (hard protection) dan memory.low (soft protection) untuk reservasi. Saat memoryReservationPolicy: TieredReservation, request memori Pod Guaranteed dipetakan ke memory.min dan Pod Burstable ke memory.low; Pod BestEffort tidak mendapat proteksi. Perlu diingat, Memory QoS masih alpha di Kubernetes 1.36 — jangan aktifkan di produksi tanpa pengujian.
• Penanganan OOM per container. Di node cgroup v2, kubelet default singleProcessOOMKill: false sehingga menulis memory.oom.group pada cgroup container. Hasilnya, satu peristiwa OOM mematikan seluruh proses dalam container itu bersama-sama, bukan menyisakan container multiproses yang berjalan setengah hidup.
• Rootless container lebih aman. Berbeda dari cgroup v1, delegasi controller ke pengguna non-root didukung resmi di cgroup v2 dan umumnya memakai systemd.
• PSI dan eBPF. Pressure Stall Information (CPU, memori, I/O) tersedia otomatis dan dilaporkan kubelet lewat Summary API serta /metrics/cadvisor. Pengendali perangkat (device controller) di cgroup v2 diimplementasikan di atas cgroup BPF, yang dipakai antara lain oleh Cilium untuk socket-based load balancing.

Syarat teknis migrasi

1. Kubernetes dengan dukungan cgroup v2 (stabil sejak v1.25, tersedia di semua rilis yang masih didukung).
2. Sistem operasi node Linux yang boot dengan cgroup v2 aktif, kernel 5.8 atau lebih baru (5.9+ direkomendasikan bila memakai Memory QoS).
3. Container runtime yang mendukung cgroup v2: containerd v1.4+ (gunakan containerd v2.0+ agar cgroup driver terdeteksi otomatis) atau CRI-O v1.20+.
4. Kubelet dan runtime memakai cgroup driver yang sama. Bila dikelola kubeadm, gunakan driver systemd karena kubelet dijalankan sebagai service systemd. Deteksi otomatis driver runtime lewat RuntimeConfig CRI RPC (KEP-4033) sudah stabil sejak v1.34 dan butuh containerd v2.0+ atau CRI-O v1.28+.

# /var/lib/kubelet/config.yaml (contoh)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
# hanya untuk migrasi sementara, akan dihapus di rilis berikutnya
failCgroupV1: false

Cara memeriksa node Anda sekarang

• stat -fc %T /sys/fs/cgroup/ → bila hasilnya cgroup2fs, node sudah memakai cgroup v2.
• systemctl list-units 'kube*' --type=slice, systemd-cgls /sys/fs/cgroup/*, dan systemd-cgtop untuk melihat isi serta konsumsi control group.
• bpftool cgroup list /sys/fs/cgroup/* untuk melihat program BPF yang menempel.
• Untuk membuktikan limit benar-benar diterapkan, bandingkan resource di object Kubernetes dengan berkas kernel. Ambil ID container memakai crictl ps dengan label io.kubernetes.pod.namespace dan io.kubernetes.pod.name, lalu cek /sys/fs/cgroup milik PID container tersebut: cat $CGROUP/memory.max (nilai max berarti tanpa batas) atau cpu.max di cgroup slice induk untuk Pod-level resources.

Catatan penting: jangan memperlakukan info.runtimeSpec.linux.cgroupsPath sebagai path filesystem bila runtime memakai driver systemd — itu path unit systemd (slice:runtime:id), bukan direktori di /sys/fs/cgroup. Setelah upgrade crun ke v1.23 atau runc ke v1.3.2, rumus konversi cpu.shares (v1) ke cpu.weight (v2) ikut berubah, sehingga alat pemantauan yang memprediksi nilai cpu.weight secara pasti perlu disesuaikan. Perbarui juga perangkat lunak yang membaca langsung berkas cgroup — panduan migrasi menyarankan cAdvisor v0.43.0 atau lebih baru.

Sumber: Kubernetes Blog — The Shift to cgroup v2 in Kubernetes: What You Need to Know; Kubernetes Documentation — About cgroup v2.