Kubernetes v1.34 kích hoạt hoán đổi bộ nhớ trên node để tăng mật độ khối lượng công việc AI

Hỗ trợ của Kubernetes cho việc chạy các node với tính năng hoán đổi bộ nhớ (swap) đã đạt trạng thái General Availability trong phiên bản 1.34. Bản cập nhật này cho phép các nhà vận hành cụm sử dụng bộ nhớ cục bộ tốc độ cao để xử lý tình trạng tràn bộ nhớ, giải quyết một nút thắt quan trọng đối với các khối lượng công việc AI tác nhân (agentic AI) hiện đại vốn thường xuyên ở trạng thái nhàn rỗi nhưng lại tiêu tốn lượng lớn RAM.

Chuyện gì đã xảy ra

Dung lượng bộ nhớ thường là giới hạn cứng đầu tiên mà các cụm Kubernetes gặp phải. Các node thường cạn kiệt RAM vật lý trước khi tài nguyên CPU được sử dụng hết. Ràng buộc này trở nên cấp bách hơn với sự gia tăng của các khối lượng công việc AI tác nhân, vốn yêu cầu footprint bộ nhớ lớn để khởi tạo và thực thi mã không tin cậy. Sau đợt hoạt động ban đầu này, các tác nhân thường bước vào những khoảng thời gian dài nhàn rỗi trong khi chờ lệnh từ người dùng. Việc giữ trạng thái ngủ đông này trong RAM vật lý đắt đỏ làm hạn chế số lượng pod mà một node có thể lưu trữ, dẫn đến chi phí cơ sở hạ tầng tăng cao.

Việc phát hành Kubernetes v1.34 thay đổi động thái này bằng cách chính thức hỗ trợ hoán đổi bộ nhớ trên node. Bằng cách cho phép kernel Linux đưa các trang bộ nhớ ẩn danh (anonymous memory) ra đĩa, swap đóng vai trò như một bộ đệm trong các đợt tăng đột biến về lưu lượng truy cập hoặc khi bộ nhớ bị phân bổ quá mức. Khi được hỗ trợ bởi ổ cứng thể rắn (SSD) NVMe tốc độ cao, phương pháp này cho phép các node卸载 (offload) các trang bộ nhớ nhàn rỗi và gói gọn nhiều pod hơn đáng kể lên mỗi máy. Các bài kiểm tra chuẩn (benchmark) chỉ ra rằng phương pháp này có thể mang lại mức tăng mật độ lên tới ba lần, thường với tác động tối thiểu đến độ trễ.

Trước đây, swap bị khuyến nghị tránh sử dụng trong môi trường Kubernetes vì hai lý do chính. Thứ nhất, việc tính toán bộ nhớ dưới cgroup v1 coi bộ nhớ và swap là một giới hạn kết hợp, khiến việc cô lập và dự đoán mức sử dụng bộ nhớ thực tế của container trở nên khó khăn. Thứ hai, việc đưa trang ra các ổ đĩa quay truyền thống gây ra hình phạt độ trễ nghiêm trọng. Hỗ trợ mới dựa trên cgroup v2, cung cấp tính toán swap riêng biệt, và kết hợp với bộ nhớ NVMe nhanh để giảm thiểu các vấn đề về độ trễ, khiến tính năng này trở nên khả thi cho mục đích sản xuất.

Cách thức hoạt động

Hoán đổi bộ nhớ trên node hoạt động bằng cách cho phép hệ điều hành di chuyển các trang bộ nhớ không hoạt động từ RAM sang không gian swap được chỉ định trên đĩa. Trong Kubernetes v1.34, điều này được quản lý thông qua cấu hình kubelet. Các nhà vận hành đặt failSwapOn thành false và xác định swapBehavior là LimitedSwap. Cấu hình này yêu cầu node chỉ sử dụng swap khi cần thiết, thay vì phụ thuộc vào nó như bộ nhớ chính.

Hiệu quả của cơ chế này phụ thuộc rất nhiều vào tốc độ của bộ nhớ lưu trữ bên dưới. Bằng cách định tuyến swap sang các ổ Local SSD, thời gian chờ I/O liên quan đến việc đưa trang ra đĩa được giảm đáng kể. Thiết lập này hoạt động tốt nhất với các lớp Chất lượng Dịch vụ (QoS) Burstable, nơi giới hạn bộ nhớ của container được đặt cao hơn so với yêu cầu. Node sau đó tự động phân bổ không gian swap dựa trên mức sử dụng bộ nhớ ứng dụng nhàn rỗi, giữ các tiến trình đang hoạt động trong RAM vật lý nhanh và di chuyển dữ liệu ngủ đông ra đĩa.

Chi tiết chính

• Kubernetes v1.34 đánh dấu sự sẵn sàng chung (General Availability) của hỗ trợ hoán đổi bộ nhớ trên node.
• Tính năng này yêu cầu cgroup v2 để tính toán và cô lập swap độc lập.
• Các bài kiểm tra chuẩn cho thấy mức giảm 50% footprint RAM cho các bản build kernel Linux, giảm từ 600 MB xuống còn 300 MB.
• Các pod Chrome headless sử dụng gVisor ghi nhận mức tăng mật độ 100%, tăng từ 80 lên 160 pod đồng thời.
• Các sandbox Python cô lập đạt được mức cải thiện mật độ 200%, mở rộng quy mô từ 80 lên 240 phiên đồng thời.
• Sự gia tăng độ trễ ở mật độ đỉnh điểm chủ yếu do cạnh tranh CPU chứ không phải do I/O swap.

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

Đối với các kỹ sư xây dựng nền tảng cho các tác nhân AI hoặc pipeline CI/CD, sự phát triển này cung cấp một con đường trực tiếp để giảm chi phí cơ sở hạ tầng. Các khối lượng công việc tác nhân vốn dĩ có tính chất bùng nổ; chúng tăng vọt trong quá trình khởi tạo và thực thi mã, sau đó vẫn ở trạng thái nhàn rỗi. Nếu không có swap, các nhà vận hành phải cung cấp đủ RAM để xử lý mức đỉnh, khiến phần lớn bộ nhớ đó bị lãng phí trong các khoảng thời gian nhàn rỗi. Hoán đổi bộ nhớ trên node cho phép các đội ngũ điều chỉnh kích thước yêu cầu bộ nhớ cho mức sử dụng tích cực, đồng thời sử dụng không gian đĩa như một chính sách bảo hiểm cho các đợt bùng nổ.

Điều này cũng ảnh hưởng đến kiến trúc bảo mật. Các môi trường thực thi an toàn như gVisor hoặc Kata Containers thêm overhead bộ nhớ do các yêu cầu cô lập. Trước đây, overhead này hạn chế chặt chẽ mật độ pod. Với hoán đổi bộ nhớ trên node, chi phí bộ nhớ bổ sung của các runtime an toàn này có thể được đưa ra đĩa khi không hoạt động tích cực. Điều này có nghĩa là các đội ngũ có thể duy trì ranh giới bảo mật nghiêm ngặt cho mã không tin cậy mà không hy sinh lợi ích kinh tế của việc lập lịch mật độ cao.

Những gì bạn có thể làm

• Nâng cấp các cụm Kubernetes của bạn lên phiên bản 1.34 trở lên để truy cập các tính năng GA hoán đổi bộ nhớ trên node.
• Cấu hình kubelet với failSwapOn: false và memorySwap.swapBehavior: LimitedSwap.
• Đảm bảo các node của bạn được trang bị ổ Local SSD NVMe tốc độ cao để giảm thiểu độ trễ swap.
• Đặt giới hạn bộ nhớ container cao hơn yêu cầu để kích hoạt hành vi QoS Burstable.
• Chạy benchmark cho các khối lượng công việc cụ thể của bạn để xác định tỷ lệ tối ưu giữa RAM và không gian swap.
• Giám sát sự cạnh tranh CPU ở mật độ cao, vì đây sẽ trở thành nút thắt chính trước khi I/O swap gây ra vấn đề.