Kubernetes v1.35 bắt buộc di chuyển sang cgroup v2 cho các node Linux

Dự án Kubernetes đã đưa hỗ trợ cgroup v1 vào chế độ bảo trì, báo hiệu sự chuyển đổi dứt khoát sang giao diện quản lý tài nguyên hợp nhất của cgroup v2. Bắt đầu từ Kubernetes v1.35, kubelet sẽ từ chối khởi động trên các node vẫn đang sử dụng cgroup v1 trừ khi quản trị viên ghi đè rõ ràng hành vi này. Thay đổi này ảnh hưởng đến tất cả các cụm dựa trên Linux, đòi hỏi các nhà vận hành phải kiểm tra phiên bản kernel, runtime container và cấu hình node trước khi nâng cấp.

Chuyện gì đã xảy ra

Control groups, hay cgroups, là một tính năng của kernel Linux cho phép hệ điều hành phân bổ các tài nguyên như CPU và bộ nhớ cho các tiến trình cụ thể. Kubernetes dựa vào cơ chế này để đảm bảo các container không can thiệp lẫn nhau. Mặc dù cgroup v2 đã ổn định trong Kubernetes kể từ phiên bản 1.25, nhưng hỗ trợ cho giao diện v1 cũ hiện đang bị loại bỏ dần. Trong Kubernetes v1.35, tham số cấu hình failCgroupV1 được đặt mặc định là true. Điều này có nghĩa là nếu một node đang chạy cgroup v1, quá trình kubelet sẽ thất bại khi khởi động, khiến node đó bị ngoại tuyến.

Các quản trị viên chưa sẵn sàng di chuyển có thể tạm thời đặt failCgroupV1: false trong tệp cấu hình kubelet của họ. Tuy nhiên, đây chỉ là giải pháp tình thế. Chính sách ngừng hỗ trợ (deprecation policy) của Kubernetes cho biết việc loại bỏ hoàn toàn hỗ trợ cgroup v1 sắp tới, được theo dõi dưới KEP-5573. Đối với các cụm được quản lý bởi kubeadm, việc thực thi còn nghiêm ngặt hơn. Kiểm tra trước SystemVerification, một phần của công cụ k8s.io/system-validators, hiện trả về lỗi trong quá trình khởi tạo, tham gia hoặc nâng cấp nếu nó phát hiện cgroup v1 trên một node chạy kubelet v1.35 trở lên. Trước đây, đây chỉ là một cảnh báo.

Sự chuyển đổi này không chỉ liên quan đến tuân thủ quy chuẩn; nó mở khóa các khả năng quản lý tài nguyên hiện đại. Cgroup v2 cung cấp một hệ thống phân cấp hợp nhất duy nhất, giúp đơn giản hóa giao diện so với nhiều hệ thống phân cấp của v1. Nó cung cấp sự cô lập mạnh mẽ hơn và hỗ trợ các tính năng mới như Pressure Stall Information (PSI) và cải thiện chất lượng dịch vụ (QoS) bộ nhớ. Các cụm vẫn ở v1 sẽ bỏ lỡ những tối ưu hóa này và đối mặt với ngày càng nhiều vấn đề tương thích với các runtime container và công cụ giám sát mới hơn.

Cách hoạt động

Cgroup v2 thay thế cấu trúc đa hệ thống phân cấp phức tạp của v1 bằng một cây duy nhất nơi tất cả các bộ điều khiển (CPU, bộ nhớ, I/O) được gắn kết. Sự hợp nhất này cho phép kế toán tài nguyên nhất quán hơn và ngăn ngừa các kịch bản mà một tiến trình bị giới hạn bởi một bộ điều khiển nhưng không bị giới hạn bởi bộ điều khiển khác do sự không khớp giữa các hệ thống phân cấp. Trong Kubernetes, kubelet tương tác với các bộ điều khiển này để thực thi các giới hạn được xác định trong đặc tả Pod. Với v2, kubelet có thể sử dụng các tính năng như memory.high để throttling (giới hạn tốc độ) và memory.min để bảo vệ cứng, những điều không thể hoặc không đáng tin cậy trong v1.

Việc di chuyển cũng thay đổi cách xử lý các sự kiện out-of-memory (OOM). Trong cgroup v2, kubelet thiết lập memory.oom.group cho mỗi cgroup container. Khi xảy ra sự kiện OOM, kernel sẽ giết tất cả các tiến trình trong container đó đồng thời, thay vì chọn từng cái một. Điều này ngăn chặn các container hoạt động một phần bị mắc kẹt trong trạng thái hỏng hóc. Ngoài ra, cgroup v2 cho phép ủy quyền (delegation), cho phép các container rootless tự quản lý cgroup của chúng một cách an toàn thông qua systemd, một khả năng vốn rủi ro hoặc không thể thực hiện được trong v1.

Chi tiết chính

• Thực thi mặc định: Trong Kubernetes v1.35, failCgroupV1 mặc định là true, gây ra lỗi khởi động kubelet trên các node cgroup v1.
• Yêu cầu Kernel: Cần phiên bản kernel Linux 5.8 trở lên để hỗ trợ cgroup v2, khuyến nghị 5.9+ để ổn định Memory QoS.
• Hỗ trợ Runtime: Containerd v1.4+ và CRI-O v1.20+ hỗ trợ cgroup v2; việc khám phá driver tự động yêu cầu containerd v2.0+ hoặc CRI-O v1.28+.
• Memory QoS: Tính năng alpha Memory QoS, sử dụng memory.high và memory.low, chỉ khả dụng độc quyền trên các node cgroup v2.
• Cập nhật Công cụ: Các công cụ giám sát phải được cập nhật; khuyến nghị cAdvisor v0.43.0+, cùng với các phiên bản thư viện Java và Node.js tương thích.
• Chuyển đổi Trọng số CPU: Các runtime OCI mới hơn như crun v1.23 và runc v1.3.2 sử dụng chuyển đổi phi tuyến tính từ cpu.shares của v1 sang cpu.weight của v2, cải thiện độ hạt cho các yêu cầu CPU nhỏ.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và nhóm nền tảng, sự thay đổi này có nghĩa là các cấu hình hạ tầng cũ không còn khả thi nữa. Nếu bạn nâng cấp control plane lên v1.35 mà không di chuyển các worker node, cụm của bạn sẽ bị hỏng. Các node sẽ không thể tham gia, và các node hiện có có thể không khởi động lại được sau khi reboot. Điều này tạo ra phụ thuộc cứng nhắc vào các bản cập nhật hệ điều hành, vì nhiều bản phân phối Linux cũ mặc định sử dụng cgroup v1. Các nhóm hiện nay phải phối hợp nâng cấp kernel trên toàn bộ đội hình máy chủ của họ, điều này có thể là một rào cản vận hành đáng kể trong các môi trường lớn và không đồng nhất.

Ngoài nỗi đau di chuyển trước mắt, việc ở lại v2 mở khóa hiệu quả tài nguyên tốt hơn. Các tính năng như PSI cung cấp khả năng hiển thị thời gian thực vào sự cạnh tranh tài nguyên, cho phép đưa ra quyết định autoscaling chính xác hơn. Việc xử lý OOM được cải thiện đảm bảo rằng các lỗi ứng dụng sạch sẽ hơn và dễ gỡ lỗi hơn. Hơn nữa, khi scaling dọc tại chỗ (in-place vertical scaling) trở nên ổn định, cgroup v2 là bắt buộc để thực thi tổng hợp chính xác. Bỏ qua con đường di chuyển này cuối cùng sẽ khiến các cụm không thể áp dụng những cải tiến về hiệu suất và độ tin cậy này.

Bạn có thể làm gì

• Kiểm tra Trạng thái Hiện tại: Chạy stat -fc %T /sys/fs/cgroup/ trên các node của bạn. Nếu nó trả về cgroup2fs, bạn đã ở trên v2.
• Xác minh Phiên bản Kernel: Đảm bảo tất cả các node Linux đang chạy kernel 5.8 trở lên. Nâng cấp OS nếu cần thiết trước khi thử nâng cấp Kubernetes.
• Cập nhật Runtime Container: Xác nhận bạn đang sử dụng containerd v1.4+ hoặc CRI-O v1.20+. Lý tưởng nhất là chuyển sang containerd v2.0+ để tận dụng việc khám phá driver cgroup tự động.
• Cấu hình Kubelet: Nếu bạn không thể di chuyển ngay lập tức, hãy đặt failCgroupV1: false trong cấu hình kubelet, nhưng hãy lên kế hoạch xóa ghi đè này sớm. Khớp driver cgroup với runtime của bạn, tốt nhất là sử dụng systemd.
• Cập nhật Stack Giám sát: Nâng cấp cAdvisor lên v0.43.0 trở lên và xác minh rằng các scraper Prometheus và các công cụ giám sát khác của bạn hỗ trợ các số liệu cgroup v2.
• Thử nghiệm Memory QoS: Nếu bạn sử dụng quản lý tài nguyên nâng cao, hãy thử nghiệm các tính năng alpha Memory QoS trong môi trường staging để hiểu cách throttling memory.high ảnh hưởng đến workload của bạn.