Kubernetes rời bỏ cgroup v1: từ v1.35 kubelet mặc định không khởi động trên node cũ
Từ Kubernetes v1.35, kubelet mặc định không khởi động trên node dùng cgroup v1. Blog Kubernetes tóm tắt lý do chuyển đổi, điều kiện để chạy cgroup v2 và những thay đổi về bộ nhớ, OOM mà đội vận hành cần nắm trước khi nâng cấp.
Vibe DevOps biên soạn ngày · khoảng 595 từ
Điểm chính từ bài gốc
- Hỗ trợ cgroup v2 ổn định từ Kubernetes v1.25; cgroup v1 vào chế độ bảo trì từ v1.31 và nay đã bị đánh dấu deprecated.
- Từ v1.35, failCgroupV1 mặc định là true nên kubelet dừng khởi động trên node cgroup v1. Có thể tạm đặt failCgroupV1: false, nhưng bài gốc cho biết phương án dự phòng này dự kiến bị gỡ ở v1.38.
- Với cụm kubeadm, bước kiểm tra SystemVerification báo lỗi ngay khi init, join hoặc upgrade nếu gặp cgroup v1 đi cùng kubelet v1.35 trở lên.
- Điều kiện tối thiểu: node Linux bật cgroup v2, kernel 5.8 trở lên (khuyến nghị 5.9 nếu dùng Memory QoS), runtime hỗ trợ cgroup v2 như containerd hoặc CRI-O, và cgroup driver của kubelet khớp với runtime.
- Trên node cgroup v2, khi xảy ra OOM, kubelet mặc định cho dừng toàn bộ tiến trình trong cùng container; muốn giữ hành vi kiểu cũ phải bật singleProcessOOMKill.
Theo bài gốc
Vì sao cgroup v2 trở thành bắt buộc trên thực tế
Theo bài viết, cgroup v2 có cây phân cấp thống nhất, giao diện nhất quán hơn và là nền móng cho các tính năng quản lý tài nguyên mới. Memory QoS (vẫn ở mức alpha), số liệu Pressure Stall Information mà kubelet nay bật sẵn, và việc thay đổi tài nguyên cấp Pod tại chỗ đều cần cgroup v2.
Bài gốc cũng lưu ý: chuyển sang cgroup v2 không tự sửa việc kubelet coi page cache loại active_file là bộ nhớ không thu hồi được. Workload nặng I/O vẫn có thể bị evict; cách xử lý được ghi nhận là đặt memory request bằng limit sau khi đo đạc.
Theo bài gốc
Những thay đổi hành vi cần kiểm tra
cgroup v1 dùng cpu.shares, cgroup v2 dùng cpu.weight. Công thức quy đổi mới nằm ở OCI runtime như crun và runc, nên công cụ giám sát hoặc policy dự đoán chính xác cpu.weight có thể phải cập nhật sau khi nâng runtime. Phần mềm đọc trực tiếp hệ thống file cgroup như cAdvisor cũng cần phiên bản tương thích. Về driver, bài viết khuyến nghị systemd cho cụm kubeadm; từ v1.34 kubelet có thể tự phát hiện driver qua CRI với containerd v2.0 hoặc CRI-O v1.28 trở lên.
Bình luận của Vibe DevOps — không phải nội dung bài gốc
Góc nhìn Vibe DevOps: kiểm tra trước khi nâng cấp
Góc nhìn Vibe DevOps: đừng để lần nâng cấp phiên bản trở thành lúc phát hiện node còn chạy cgroup v1. Hãy đưa việc kiểm kê cgroup vào checklist nâng cấp và làm theo từng nhóm node, vì chỉ cần sót một image hệ điều hành cũ là kubelet trên cả nhóm node đó không lên.
Nên chạy thử trên một node pool phụ, theo dõi Pod bị OOM và cảnh báo CPU một thời gian rồi mới cuốn chiếu sang production. Override failCgroupV1 chỉ nên là phao cứu sinh có hạn chót và ticket theo dõi việc gỡ bỏ.
- Kiểm kê image hệ điều hành và kernel của từng node pool.
- Xác nhận phiên bản runtime và cgroup driver đang dùng.
- Rà soát alert còn dựa trên cpu.shares hoặc đường dẫn cgroup cũ.
Lệnh và khoá cấu hình xuất hiện trong bài gốc
Trích nguyên văn từ nguồn để tra cứu; hãy đọc ngữ cảnh tại bài gốc trước khi áp dụng.
stat -fc %T /sys/fs/cgroup/Kiểm tra node đã bật cgroup v2 hay chưa; kết quả mong đợi là cgroup2fs.
systemd-cgtopXem các control group đang dùng nhiều tài nguyên nhất trên node.
Lưu ý và giới hạn
- Memory QoS vẫn là tính năng alpha; bài gốc khuyến nghị chưa bật trên production khi chưa thử nghiệm kỹ.
- Bài viết không hướng dẫn cách bật cgroup v2 trên từng bản phân phối Linux.