So sánh Node Affinity vs Node Selector trong Kubernetes chi tiết

Trong Kubernetes, Node Affinity vs Node Selector là hai cơ chế chính giúp kiểm soát việc lập lịch Pod, cho phép người dùng chỉ định Pod nên chạy trên những node nào dựa trên các nhãn của node. Trong bài viết này, mình sẽ giúp bạn hiểu rõ hơn điểm khác biệt giữa Node Affinity vs Node Selector, tìm hiểu nguyên lý hoạt động, ưu nhược điểm và các trường hợp sử dụng phù hợp cho từng cơ chế.

Những điểm chính

• Tổng quan về cơ chế lập lịch: Hiểu rõ cơ chế lập lịch Pod trong Kubernetes dựa trên việc lọc và xếp hạng node, giúp bạn nắm được nền tảng của việc kiểm soát vị trí triển khai ứng dụng.
• Khái niệm Node Selector: Hiểu rõ Node Selector là cơ chế ràng buộc node đơn giản nhất, giúp bạn dễ dàng gán Pod vào các node có nhãn (label) chính xác mà không cần cấu hình phức tạp.
• Khái niệm Node Affinity: Nắm vững Node Affinity là cơ chế lập lịch nâng cao, giúp bạn sử dụng các biểu thức điều kiện linh hoạt và các quy tắc ưu tiên để kiểm soát vị trí Pod một cách chi tiết hơn.
• So sánh Node Affinity vs Node Selector: Phân biệt rõ ràng sự khác biệt về cú pháp, độ linh hoạt và các loại ràng buộc, giúp bạn lựa chọn đúng công cụ cho từng kịch bản cụ thể.
• Khi nào chọn Node Affinity và Node Selector: Nắm vững các trường hợp sử dụng phù hợp, giúp bạn đưa ra quyết định chiến lược để áp dụng đúng cơ chế cho từng yêu cầu lập lịch.
• Pod Affinity và Pod Anti‑Affinity: Tìm hiểu thêm về các cơ chế này, giúp bạn mở rộng khả năng kiểm soát vị trí Pod không chỉ dựa vào node mà còn dựa trên mối quan hệ với các Pod khác.
• Các phương pháp thực hành tốt nhất: Nắm vững các chiến lược đặt label và thiết kế chính sách lập lịch cho từng môi trường, giúp bạn áp dụng các cơ chế này một cách hiệu quả, dễ quản lý và tránh các rủi ro về chi phí hay tính sẵn sàng.
• Giới thiệu Vietnix: Biết đến Vietnix là nhà cung cấp dịch vụ Enterprise Cloud, giúp bạn có một lựa chọn hạ tầng lý tưởng để triển khai mọi chiến lược lập lịch Kubernetes.
• Câu hỏi thường gặp: Được giải đáp các thắc mắc phổ biến liên quan đến Pod Affinity và Node Selector.

Cơ chế lập lịch Pod trong Kubernetes là gì?

Bộ lập lịch (Scheduler) trong Kubernetes gán Pod cho Node qua quy trình hai bước:

• Lọc (Filtering): Loại bỏ các Node không đáp ứng yêu cầu của Pod, chẳng hạn như không đủ tài nguyên hoặc không thỏa mãn các ràng buộc do người dùng định nghĩa (nodeSelector, nodeAffinity, tolerations).
• Xếp hạng (Scoring): Chấm điểm các Node đã qua bước lọc để chọn ra Node phù hợp nhất để chạy Pod.

Nền tảng cho các cơ chế ràng buộc này là Nhãn (Labels) – các cặp khóa-giá trị được gán cho Node. Pod định nghĩa các điều kiện để khớp với nhãn này, qua đó quyết định Node nào hợp lệ.

Việc kiểm soát này giúp tối ưu hóa tài nguyên, tăng tính sẵn sàng bằng cách phân tán Pod, gán các tác vụ đặc thù lên Node tương ứng, và đảm bảo an toàn, tuân thủ.

Node Selector là gì?

Node Selector là cơ chế ràng buộc node đơn giản nhất trong Kubernetes, cho phép chỉ định Pod chỉ được lên lịch trên những node có nhãn phù hợp với cặp khóa-giá trị khai báo trong cấu hình. Cách hoạt động dựa trên nguyên tắc “khớp nhãn đơn giản”: Scheduler chỉ chọn các node có đầy đủ các nhãn trùng khớp, nếu không có node nào thỏa điều kiện thì Pod sẽ ở trạng thái Pending.​

Ở mức cấu hình, người quản trị gắn label cho node (ví dụ disktype=ssd, env=prod) rồi trong phần spec.nodeSelector của Pod hoặc Deployment khai báo các cặp khóa-giá trị tương ứng. Khi đó, Scheduler sẽ lọc toàn bộ node trong cụm và chỉ xem xét những node có nhãn trùng khớp hoàn toàn với các cặp được chỉ định trong nodeSelector, bỏ qua mọi node còn lại.​

Các bước gán nhãn node và cấu hình nodeSelector trong Pod

Đầu tiên, cần gán nhãn cho node bằng lệnh kubectl label nodes, ví dụ thêm nhãn env=prod hoặc disktype=ssd cho một hoặc nhiều node tùy theo mục đích phân nhóm tài nguyên. Sau khi gán, có thể kiểm tra lại nhãn bằng lệnh liệt kê node kèm label để bảo đảm node mục tiêu đã mang đúng cặp khóa–giá trị sẽ dùng cho ràng buộc nodeSelector.​

Tiếp theo, trong tệp cấu hình Pod hoặc Deployment, khai báo trường spec.nodeSelector với các cặp khóa–giá trị trùng với label đã gán trên node, ví dụ nodeSelector: env: prod hoặc nodeSelector: disktype: ssd. Khi áp dụng manifest, Kubernetes Scheduler sẽ chỉ xem xét và đặt Pod lên những node có đầy đủ các nhãn khớp với nodeSelector, nếu không có node nào thỏa điều kiện, Pod sẽ giữ trạng thái Pending cho đến khi tồn tại node phù hợp.

Ưu nhược điểm khi chỉ dùng nodeSelector

Node Affinity là gì?

Node Affinity là cơ chế cho phép khai báo các quy tắc để Scheduler đặt Pod lên những node có nhãn phù hợp, dựa trên điều kiện biểu thức thay vì chỉ khớp khóa-giá trị đơn giản như nodeSelector. Các quy tắc này dùng thông tin label gắn trên node (ví dụ loại phần cứng, môi trường, khu vực) để bảo đảm Pod chỉ được chạy trên nhóm node đáp ứng yêu cầu tài nguyên hoặc chính sách triển khai đã định.

Mục tiêu của Node Affinity là kiểm soát vị trí chạy của Pod một cách chi tiết hơn, phục vụ các kịch bản như buộc workload dùng GPU lên node có GPU, tách ứng dụng nhạy cảm sang node riêng hoặc gom nhóm workload theo zone, môi trường. Node Affinity được cấu hình trong trường .spec.affinity.nodeAffinity của Pod và hỗ trợ hai loại quy tắc chính, gồm:

• requiredDuringSchedulingIgnoredDuringExecution (Bắt buộc): Pod chỉ được Scheduler lên lịch trên các node có nhãn thỏa điều kiện đã khai báo, nếu không có node nào khớp thì Pod sẽ không được chạy.​
• preferredDuringSchedulingIgnoredDuringExecution (Ưu tiên): Scheduler ưu tiên đặt Pod lên các node đáp ứng điều kiện nhãn, nhưng nếu không đủ lựa chọn thì vẫn có thể chọn node khác để bảo đảm Pod được chạy.​

Cú pháp biểu thức trong nodeAffinity

Trong nodeAffinity, các điều kiện được khai báo chủ yếu dưới dạng matchExpressions với ba thành phần chính:

• key: Tên nhãn của node, ví dụ env, disktype, topology.kubernetes.io/zone.​
• operator: Toán tử mô tả kiểu so khớp giữa key và values.​
• values: Danh sách giá trị nhãn mà node cần đáp ứng theo operator tương ứng.

Các toán tử (operator) được nodeAffinity hỗ trợ gồm:

• In: Node phải có nhãn với giá trị thuộc một trong các phần tử trong values.​
• NotIn: Node có nhãn nhưng giá trị không được nằm trong danh sách values.
• Exists: Chỉ cần key nhãn tồn tại trên node, không yêu cầu danh sách giá trị.
• DoesNotExist: Node không được có nhãn với key được chỉ định.​
• Gt: Giá trị nhãn dạng số lớn hơn giá trị trong values.
• Lt: Giá trị nhãn dạng số nhỏ hơn giá trị trong values.

Khi khai báo nhiều matchExpressions trong cùng một nodeSelectorTerm, tất cả điều kiện trong danh sách đó đều phải thỏa mãn thì node mới được coi là phù hợp (tương đương quan hệ AND giữa các biểu thức). Ngược lại, khi có nhiều nodeSelectorTerms, chỉ cần một trong các term thỏa mãn toàn bộ các biểu thức của nó là node có thể được chọn (tương đương quan hệ OR giữa các term), giúp biểu diễn các tập điều kiện phức tạp cho nodeAffinity.​

Điểm giống nhau của Node Affinity vs Node Selector

Cả Node Affinity và Node Selector đều có những điểm chung cốt lõi sau:

• Cùng dựa trên Nhãn (Labels): Cả hai đều sử dụng nhãn được gán cho các Node làm cơ sở để quyết định Pod sẽ được chạy ở đâu.
• Cấu hình tại Pod: Chúng đều được định nghĩa bên trong file cấu hình (manifest) của Pod, cho phép người dùng chỉ thị cho Bộ lập lịch (Scheduler) mà không cần thay đổi cách hoạt động của chính Scheduler.
• Mục tiêu chung: Cả hai đều dùng để giới hạn Pod chỉ chạy trên một nhóm Node cụ thể, nhằm phục vụ các mục đích như:
  • Chạy tác vụ trên Node có phần cứng đặc biệt (ví dụ: GPU).
  • Tách biệt các môi trường (dev, staging, production).
  • Phân bổ Pod theo khu vực địa lý.
• Tương đương ở mức cơ bản: Quy tắc bắt buộc (required…) của Node Affinity có thể làm chính xác những gì Node Selector làm – đó là yêu cầu Pod phải khớp hoàn toàn với một nhãn nhất định.

Điểm khác biệt của Node Affinity và Node Selector

Khi lựa chọn giữa Node Selector và Node Affinity, có thể dựa trên mức độ phức tạp của yêu cầu lập lịch, quy mô cụm và nhu cầu kiểm soát chi tiết vị trí Pod để quyết định cơ chế phù hợp. Dưới đây là các trường hợp điển hình nên ưu tiên mỗi cơ chế:

Trường hợp nên chọn Node Selector

• Trường hợp đơn giản, khớp nhãn chính xác: Nên dùng khi chỉ cần ràng buộc Pod chạy trên những node có một hoặc một vài nhãn cố định theo dạng cặp khóa–giá trị và không có yêu cầu về biểu thức điều kiện phức tạp.​
• Cụm nhỏ, ít loại node và ít quy tắc: Phù hợp với các cụm Kubernetes có ít node, ít nhóm tài nguyên và số lượng quy tắc lập lịch đơn giản, nơi hệ thống nhãn ít thay đổi theo thời gian.​
• Ràng buộc cứng, không cần “ưu tiên mềm”: Thích hợp cho các kịch bản yêu cầu Pod chỉ được phép chạy trên đúng nhóm node mang nhãn xác định và chấp nhận để Pod ở trạng thái Pending nếu không có node nào đáp ứng điều kiện.​
• Cần cấu hình nhanh, dễ đọc: Nên áp dụng khi ưu tiên tệp cấu hình ngắn gọn, dễ hiểu cho nhóm vận hành, đặc biệt trong giai đoạn làm quen với cơ chế lập lịch trước khi triển khai các dạng ràng buộc nâng cao.​

Trường hợp nên chọn Node Affinity

• Cần nhiều điều kiện nhãn và biểu thức phức tạp: Nên dùng khi phải ràng buộc node dựa trên nhiều điều kiện nhãn, cần sử dụng các toán tử như In, NotIn, Exists, DoesNotExist, Gt, Lt để mô tả chính xác tập node mục tiêu.​
• Cần phân biệt quy tắc bắt buộc và quy tắc ưu tiên: Phù hợp với trường hợp cần vừa có điều kiện bắt buộc (requiredDuringScheduling) quyết định node có hợp lệ hay không, vừa có điều kiện ưu tiên (preferredDuringScheduling) để hướng Scheduler chọn node tốt hơn khi có nhiều lựa chọn.​
• Hệ thống lớn, nhiều nhóm node, đa zone: Thích hợp cho môi trường sản xuất có nhiều loại node, nhiều vùng hoặc khu vực triển khai, nơi cần kiểm soát chi tiết vị trí Pod theo tài nguyên phần cứng, khu vực địa lý, môi trường vận hành hoặc mức độ quan trọng của ứng dụng.
• Muốn gom chính sách lập lịch vào một cấu trúc thống nhất: Hữu ích khi cần tập trung hóa các quy tắc ràng buộc node trong phần nodeAffinity, giúp quản lý, bảo trì và mở rộng chính sách lập lịch thuận lợi hơn so với việc sử dụng nhiều cấu hình nodeSelector rời rạc.​

Kết hợp nodeSelector và nodeAffinity trong cùng một Pod

Khi cần điều khiển vị trí chạy của Pod theo nhiều điều kiện khác nhau, có thể kết hợp cả nodeSelector và nodeAffinity trong cùng một manifest để tăng mức độ ràng buộc. Cách kết hợp này giúp tận dụng cú pháp đơn giản của nodeSelector cho các yêu cầu cố định, đồng thời dùng nodeAffinity để bổ sung các quy tắc linh hoạt hơn dựa trên biểu thức.​

Về nguyên tắc, khi một Pod khai báo đồng thời spec.nodeSelector và spec.affinity.nodeAffinity, một node chỉ được coi là phù hợp nếu thỏa mãn cả hai nhóm điều kiện. Nghĩa là node phải có đầy đủ các nhãn khớp với tất cả cặp khóa–giá trị trong nodeSelector, đồng thời đáp ứng các biểu thức trong nodeAffinity (bao gồm cả phần bắt buộc và nếu có, các ưu tiên được cấu hình).​

Trong thực tế, có thể dùng nodeSelector cho các ràng buộc mang tính “nhóm cứng” như môi trường (env=prod, env=dev), còn nodeAffinity được dùng để chi tiết hóa hơn theo loại tài nguyên, khu vực hay lớp hạ tầng (ví dụ zone, loại máy, có GPU). Cách tách lớp này giúp tệp cấu hình dễ đọc hơn: nodeSelector thể hiện điều kiện cơ bản, trong khi nodeAffinity gói các quy tắc nâng cao, bao gồm cả quy tắc bắt buộc và quy tắc ưu tiên để hướng Scheduler chọn node tối ưu.​

Pod Affinity và Pod Anti‑Affinity: Bổ sung cho Node Affinity

Pod Affinity và Pod Anti‑Affinity là hai cơ chế mở rộng cho Node Affinity, cho phép kiểm soát vị trí Pod dựa trên nhãn của các Pod khác thay vì chỉ dựa trên nhãn của node. Cả hai được khai báo trong trường spec.affinity.podAffinity và spec.affinity.podAntiAffinity, thường dùng kết hợp với Node Affinity để vừa ràng buộc theo loại node, vừa ràng buộc theo mối quan hệ giữa các Pod trong cụm.​

Với Pod Affinity, Pod có thể yêu cầu được đặt gần (trên cùng node, cùng zone hoặc cùng topology key) với các Pod khác có nhãn xác định, nhằm mục tiêu như tối ưu độ trễ hoặc gom các thành phần của cùng một ứng dụng vào cùng miền mạng. Ngược lại, Pod Anti‑Affinity cho phép định nghĩa quy tắc để Scheduler tránh đặt Pod mới lên cùng node hoặc cùng topology với các Pod có nhãn nhất định, thường dùng để trải bản sao của cùng một dịch vụ ra nhiều node hoặc nhiều vùng nhằm tăng khả dụng và giảm rủi ro khi một node gặp sự cố.​

Cũng giống Node Affinity, cả Pod Affinity và Pod Anti‑Affinity đều hỗ trợ hai chế độ chính là requiredDuringSchedulingIgnoredDuringExecution và preferredDuringSchedulingIgnoredDuringExecution, kết hợp với topologyKey để xác định phạm vi áp dụng (node, hostname, zone,…). Khi thiết kế chính sách lập lịch nâng cao, Node Affinity thường được dùng để ràng buộc Pod vào nhóm node có đặc tính hạ tầng phù hợp, sau đó Pod Affinity/Anti‑Affinity được bổ sung để kiểm soát mối quan hệ giữa các Pod (gom hoặc tách) trên những node đó, tạo thành bộ công cụ lập lịch nhiều lớp cho kiến trúc Kubernetes.​

Chiến lược đặt label cho node để dễ quản lý lâu dài

Chiến lược đặt label cho node nên dựa trên các nhóm thông tin ổn định như loại tài nguyên phần cứng (CPU cao, RAM cao, GPU, SSD), khu vực địa lý hoặc zone, môi trường (dev, staging, prod) và vai trò node (worker chung, worker cho batch, worker cho ML). Các label này cần được đặt theo quy ước thống nhất, có tài liệu nội bộ rõ ràng, và hạn chế thay đổi tùy hứng để tránh làm hỏng các ràng buộc nodeSelector/nodeAffinity đang sử dụng.​

Bên cạnh đó, nên ưu tiên gán label cho node ở mức “khả năng” (ví dụ hardware=gpu, storage=ssd, zone=us-east-1a) rồi dùng nodeAffinity để chọn tổ hợp phù hợp, thay vì tạo quá nhiều label chi tiết cho từng ứng dụng riêng lẻ. Việc này giúp tái sử dụng được label cho nhiều workload khác nhau và giảm chi phí bảo trì khi cụm mở rộng số lượng node.​

Thiết kế policy lập lịch cho môi trường dev, staging, production

Đối với môi trường dev hoặc test, có thể chỉ dùng nodeSelector cho một số phân tách cơ bản (như env=dev) và để Scheduler tự phân phối Pod trong nhóm node này, hạn chế dùng nhiều ràng buộc phức tạp để giữ cấu hình đơn giản và linh hoạt. Với môi trường staging, có thể bắt đầu áp dụng nodeAffinity dạng ưu tiên để mô phỏng gần hơn điều kiện sản xuất, ví dụ ưu tiên node theo zone, loại phần cứng nhưng vẫn cho phép Pod được chạy nếu không đủ node khớp hoàn toàn.​

Trong môi trường production, chính sách lập lịch thường kết hợp cả điều kiện bắt buộc (required) và ưu tiên (preferred) với nodeAffinity, đồng thời dùng nodeSelector cho các phân tách “cứng” như môi trường hoặc nhóm tuân thủ đặc biệt. Thiết kế này giúp kiểm soát chặt vị trí đặt Pod cho các dịch vụ quan trọng, trong khi vẫn cho phép Scheduler linh hoạt tối ưu tài nguyên giữa các node còn trống trong cùng nhóm.​

Lưu ý về chi phí, khả dụng và bảo trì khi lạm dụng ràng buộc node

Việc đặt quá nhiều ràng buộc nodeSelector/nodeAffinity có thể làm giảm số node đủ điều kiện, khiến Pod dễ bị Pending và tài nguyên trong cụm bị phân mảnh, từ đó ảnh hưởng đến hiệu quả sử dụng chi phí.

Đặc biệt trong môi trường autoscaling hoặc khi dùng nhiều loại máy khác nhau, ràng buộc quá chặt có thể khiến Scheduler không tận dụng được node rảnh, dẫn tới phải mở rộng thêm node mới không cần thiết.​

Ngoài chi phí, lạm dụng ràng buộc còn ảnh hưởng đến tính sẵn sàng và khả năng bảo trì: khi một nhóm node cố định gặp sự cố hoặc cần nâng cấp, các Pod gắn chặt với nhóm đó sẽ không có nhiều lựa chọn thay thế để chuyển sang.

Do đó, tài liệu và các bài hướng dẫn khuyến nghị chỉ sử dụng ràng buộc bắt buộc khi thực sự cần thiết, ưu tiên dùng quy tắc ưu tiên (preferred) cho các mong muốn mềm, và thường xuyên rà soát lại chính sách nodeAffinity/nodeSelector khi kiến trúc, chi phí hoặc mô hình triển khai thay đổi.​

Vietnix – Nền tảng Cloud Server cho mọi chiến lược lập lịch Kubernetes

Việc áp dụng Node Selector và Node Affinity một cách chiến lược giúp bạn làm chủ việc điều phối tài nguyên trong Kubernetes. Tuy nhiên, để các quy tắc này phát huy tối đa hiệu quả, bạn cần một nền tảng hạ tầng đủ mạnh mẽ và linh hoạt. Đó chính là lúc thuê máy chủ cloud server Vietnix trở thành lựa chọn lý tưởng.

Thay vì quản lý các Node riêng lẻ, Enterprise Cloud cung cấp cho bạn một cụm tài nguyên độc lập, trang bị phần cứng đỉnh cao với CPU AMD EPYC và 100% ổ cứng NVMe. Bạn có toàn quyền tự tạo và quản lý nhiều Cloud Server, hỗ trợ API mạnh mẽ để tự động hóa hạ tầng (IaC) và tích hợp liền mạch với Kubernetes. Với khả năng mở rộng linh hoạt, chi phí minh bạch và độ ổn định vượt trội, bạn có thể tự tin xây dựng các môi trường Dev/Test/Production phức tạp mà không lo về giới hạn phần cứng.

Hãy nâng tầm hạ tầng Kubernetes của bạn ngay hôm nay! Khám phá giải pháp Enterprise Cloud của Vietnix để biến chiến lược lập lịch của bạn thành hiện thực.

Thông tin liên hệ:

• Website: https://vietnix.vn/
• Hotline: 1800 1093
• Email: sales@vietnix.com.vn
• Địa chỉ: 265 Hồng Lạc, Phường Bảy Hiền, Thành Phố Hồ Chí Minh

Node Affinity vs Node Selector là hai công cụ lập lịch mạnh mẽ trong Kubernetes, giúp kiểm soát chính xác vị trí triển khai Pod. Việc hiểu rõ sự khác biệt, các trường hợp sử dụng phù hợp và cách kết hợp chúng với các cơ chế lập lịch khác như Pod Affinity/Anti-Affinity sẽ là chìa khóa để xây dựng một kiến trúc Kubernetes hiệu quả, tối ưu hóa tài nguyên, tăng cường tính sẵn sàng và đáp ứng mọi yêu cầu vận hành.