07/10/2026 · VietTechies · Biên tập
Với việc hỗ trợ node swap chính thức đạt mức Khả dụng Chung (GA) từ phiên bản Kubernetes v1.34, các đội ngũ hạ tầng hiện có thể kết hợp swap với ổ cứng thể rắn local NVMe tốc độ cao nhằm gia tăng mật độ container. Kết quả từ các bài đo hiệu năng trên những môi trường thực thi cô lập cho thấy việc chuyển bộ nhớ vô danh không hoạt động ra đĩa cứng giúp node chứa được số lượng pod đồng thời cao gấp ba lần mà không bị dừng tiến trình do thiếu bộ nhớ (Out-Of-Memory).
Khắc phục giới hạn bộ nhớ lịch sử bằng cgroup v2
Trước đây, các hệ thống Kubernetes thường tránh sử dụng swap do các rào cản về kiến trúc và phần cứng. Với cgroup v1, hệ thống quản lý bộ nhớ RAM và swap thành một giới hạn chung duy nhất, khiến mức tiêu thụ bộ nhớ của container trở nên khó dự đoán và khó cô lập. Bên cạnh đó, các ổ đĩa cơ truyền thống cũng gây ra độ trễ rất cao mỗi khi xảy ra quá trình phân trang.
Tính năng node swap trong Kubernetes giải quyết triệt để vấn đề này nhờ bắt buộc sử dụng cgroup v2, vốn hỗ trợ cơ chế hạch toán swap độc lập. Khi kết hợp cùng ổ SSD NVMe cục bộ, node có thể xử lý các đợt tăng đột biến dung lượng RAM bằng cách đẩy bộ nhớ nhàn rỗi xuống đĩa cứng, từ đó tránh tình trạng pod bị dừng sớm mà vẫn đảm bảo hiệu năng ổn định.
Kết quả đo hiệu năng mật độ trên các môi trường Sandbox
Các thử nghiệm thực tế chứng minh swap đã tối ưu hóa việc sử dụng tài nguyên ra sao qua ba mô hình phát triển và thực thi phổ biến. Trong bài kiểm tra biên dịch kernel Linux 6.1.1 đại diện cho các chuỗi quy trình CI/CD doanh nghiệp, việc bật swap trên SSD NVMe cho phép giảm một nửa giới hạn bộ nhớ của container từ 600 MB xuống 300 MB mà không làm giảm hiệu năng, thậm chí hoàn thành trong 374 giây so với 433 giây khi không dùng swap. Tuy nhiên, nếu thắt chặt giới hạn quá mức xuống 200 MB, bộ nhớ đang hoạt động buộc phải ghi xuống đĩa, làm giảm tốc độ I/O hơn 40%.
Đối với các AI Agent và môi trường thực thi sandbox, swap giúp hấp thụ lượng bộ nhớ tiêu hao do các rào cản bảo mật tạo ra. Trên một node 32 vCPU, container runc không dùng sandbox đã tăng mật độ tối đa từ 512 lên 768 pod. Khi dùng gVisor để cô lập, dung lượng tăng gấp đôi từ 80 lên 160 pod, trong khi các microVM Kata Containers tăng từ 40 lên 50 pod trước khi chạm giới hạn CPU. Trong môi trường sandbox Python cô lập xử lý các tập dữ liệu yêu cầu khoảng 375 MiB bộ nhớ thường trú mỗi phiên, node swap đã giải phóng các trạng thái chờ để tăng khả năng phục vụ từ 80 lên 240 sandbox đồng thời, tức gấp 3 lần.
Cấu hình Node Swap trong Kubelet
Để triển khai node swap từ phiên bản Kubernetes v1.34 trở đi, quản trị viên cần cập nhật cấu hình kubelet bằng cách đặt failSwapOn thành false và thiết lập thuộc tính memorySwap ở chế độ LimitedSwap. Cấu hình này nên được kết hợp với mức Chất lượng Dịch vụ (QoS) dạng Burstable, trong đó giới hạn bộ nhớ của container được đặt cao hơn mức yêu cầu. Theo cơ chế này, node sẽ tự động chuyển phần bộ nhớ ứng dụng nhàn rỗi ra ổ đĩa swap, đồng thời ưu tiên dành RAM vật lý cho các luồng xử lý tích cực.
Ảnh minh họa do AI tạo, không phải ảnh tư liệu.