Affinity và Anti-Affinity trong Kubernetes: Cách kiểm soát vị trí Pod

Kubernetes có thể tự động phân bổ Pod, nhưng vị trí được chọn chưa chắc phù hợp với mọi workload. Cùng Viettel IDC tìm hiểu cách Affinity và Anti-Affinity trong Kubernetes giúp tối ưu hiệu suất, phân tán Pod và tăng tính sẵn sàng.

Tìm hiểu tổng quan về Affinity và Anti-Affinity trong Kubernetes

Affinity và Anti-Affinity là các quy tắc giúp kube-scheduler kiểm soát vị trí triển khai Pod dựa trên label, selector và topology của cluster. Cơ chế này thường được dùng để tối ưu hiệu suất, tăng tính sẵn sàng hoặc phân tách workload.

Affinity là gì?

Affinity trong Kubernetes là cơ chế giúp kube-scheduler xác định Pod nên được triển khai trên node nào hoặc nên nằm gần nhóm Pod nào. Thay vì chỉ dựa vào CPU và RAM còn khả dụng, Scheduler có thể xét thêm nhãn của node, nhãn của Pod và mối quan hệ giữa các workload trước khi đưa ra quyết định.

Affinity được chia thành hai loại chính dựa trên đối tượng mà kube-scheduler sử dụng để xác định vị trí triển khai Pod:

- Node Affinity: Chọn node theo label, phù hợp với workload cần GPU, SSD, kiến trúc CPU hoặc zone cụ thể.

- Pod Affinity: Đặt các Pod liên quan gần nhau trong cùng node hoặc zone nhằm giảm độ trễ mạng.

Cả hai loại đều hỗ trợ hai mức độ ràng buộc:

- requiredDuringSchedulingIgnoredDuringExecution: Điều kiện bắt buộc; Pod có thể Pending nếu không tìm được vị trí phù hợp.

- preferredDuringSchedulingIgnoredDuringExecution: Điều kiện ưu tiên; Scheduler vẫn có thể chọn vị trí khác khi cần.

Anti-Affinity là gì?

Anti-Affinity trong Kubernetes là cơ chế giúp giữ các Pod phù hợp với một selector không nằm quá gần nhau trong cùng topology domain. Mục tiêu chính là giảm nguy cơ nhiều replica cùng bị ảnh hưởng khi một node, rack hoặc Availability Zone gặp sự cố.

Pod Anti-Affinity hỗ trợ hai mức độ ràng buộc:

- Hard anti-affinity: Điều kiện bắt buộc; Pod chỉ được triển khai khi có topology domain phù hợp.

- Soft anti-affinity: Điều kiện ưu tiên; Scheduler cố gắng phân tán Pod nhưng vẫn có thể đặt chúng gần nhau khi thiếu tài nguyên.

Kubernetes không có trường nodeAntiAffinity riêng. Khi cần tránh một nhóm node, có thể:

- Dùng toán tử NotIn hoặc DoesNotExist trong Node Affinity.

- Kết hợp Taints and Tolerations để kiểm soát Pod trên các node cụ thể.

Cách hoạt động của Affinity và Anti-Affinity

Khi một Pod mới được tạo, kube-scheduler đọc các quy tắc Affinity và Anti-Affinity trong cấu hình để xác định những node phù hợp. Scheduler đối chiếu label của node, label của các Pod đang chạy và topologyKey trước khi đưa ra quyết định.

Với Affinity, Scheduler ưu tiên hoặc yêu cầu Pod được đặt trên node phù hợp hay gần nhóm Pod có liên quan. Ngược lại, Anti-Affinity hướng Pod sang node hoặc topology domain khác nhằm tránh tập trung nhiều workload cùng vị trí.

Các quy tắc bắt buộc được dùng để loại bỏ node không đáp ứng điều kiện, còn quy tắc ưu tiên giúp chấm điểm những node còn lại. Pod sau đó được triển khai trên node có mức độ phù hợp cao nhất và đủ tài nguyên.

So sánh Affinity và Anti-Affinity trong Kubernetes

Affinity và Anti-Affinity đều giúp kube-scheduler kiểm soát vị trí triển khai Pod, nhưng khác nhau về mục tiêu sử dụng. Affinity hướng Pod đến gần node hoặc workload phù hợp, còn Anti-Affinity tạo khoảng cách giữa các Pod để hạn chế rủi ro tập trung.

Ví dụ thực tế về Affinity và Anti-Affinity trong Kubernetes

Affinity và Anti-Affinity thường được áp dụng để tối ưu vị trí triển khai Pod theo yêu cầu về hiệu suất, khả năng chịu lỗi và tính sẵn sàng. Hai ví dụ dưới đây minh họa cách sử dụng phổ biến trong môi trường thực tế.

Đảm bảo tính sẵn sàng cho Redis Cluster

Với Redis Cluster, các replica nên được phân tán trên nhiều node để tránh nhiều thành phần cùng ngừng hoạt động khi một node gặp lỗi.

Cấu hình trên sử dụng Pod Anti-Affinity để ngăn các Pod mang label app: redis chạy trên cùng một node. Nếu một node gặp sự cố, các replica còn lại vẫn có thể tiếp tục duy trì hoạt động của cluster.

Giảm độ trễ giữa frontend và backend

Với ứng dụng có frontend thường xuyên giao tiếp với backend, đặt hai thành phần gần nhau có thể rút ngắn đường truyền dữ liệu và cải thiện tốc độ phản hồi.

Cấu hình sử dụng Pod Affinity ở mức ưu tiên để hướng Pod frontend đến node đang chạy backend. Khi không tìm được vị trí phù hợp, Scheduler vẫn có thể triển khai frontend trên node khác, nhờ đó tránh làm gián đoạn quá trình lập lịch.

Các lỗi thường gặp khi cấu hình Affinity và Anti-Affinity

Affinity và Anti-Affinity trong Kubernetes có thể khiến Pod không được lập lịch đúng như mong muốn nếu điều kiện đặt ra quá chặt hoặc topology chưa được xác định chính xác. Bảng dưới đây tổng hợp những lỗi phổ biến, nguyên nhân và hướng xử lý phù hợp.

Thách thức thường gặp khi triển khai Affinity và Anti-Affinity

Affinity và Anti-Affinity mang lại khả năng kiểm soát vị trí triển khai Pod linh hoạt hơn. Tuy nhiên, quy tắc thiếu hợp lý có thể làm giảm hiệu suất lập lịch, gây mất cân bằng tài nguyên hoặc khiến chi phí vận hành tăng cao.

Khó cân bằng hiệu suất và tính sẵn sàng

Pod Affinity đặt các workload liên quan gần nhau, qua đó rút ngắn đường truyền dữ liệu và giảm độ trễ mạng. Cách phân bổ tập trung lại làm tăng nguy cơ nhiều thành phần cùng ngừng hoạt động khi node hoặc zone gặp lỗi. Trong khi đó, Pod Anti-Affinity cải thiện khả năng chịu lỗi bằng cách phân tán các replica, nhưng khoảng cách giữa các workload có thể làm tăng độ trễ và chi phí truyền dữ liệu.

Để cân bằng hai mục tiêu, quản trị viên nên ưu tiên preferredDuringSchedulingIgnoredDuringExecution khi yêu cầu không mang tính bắt buộc. Topology Spread Constraints cũng có thể được kết hợp để phân phối Pod đồng đều hơn giữa các node hoặc zone.

Hiệu suất Scheduler bị ảnh hưởng

Khi cluster có nhiều quy tắc Affinity và Anti-Affinity phức tạp, kube-scheduler phải đánh giá thêm label, selector, Pod và topology domain trước khi lựa chọn node. Khối lượng xử lý tăng lên có thể kéo dài thời gian lập lịch, đặc biệt trong cluster chứa số lượng lớn node và Pod.

Số lượng quy tắc trong mỗi workload nên được giới hạn ở mức cần thiết. Label và selector cũng cần xác định cụ thể để thu hẹp phạm vi đánh giá, đồng thời hiệu suất Scheduler nên được theo dõi qua Prometheus và Grafana.

Các quy tắc có thể xung đột

Nhiều quy tắc được áp dụng đồng thời có thể tạo ra những yêu cầu trái ngược nhau. Chẳng hạn, Pod Affinity yêu cầu hai Pod chạy trong cùng một topology domain, trong khi Pod Anti-Affinity lại buộc chúng phải tách biệt. Khi không tồn tại node đáp ứng toàn bộ điều kiện, Pod có thể duy trì trạng thái Pending.

Trước khi đưa cấu hình vào môi trường vận hành, quản trị viên cần kiểm tra nguyên nhân lập lịch bằng kubectl describe và đối chiếu cấu trúc trường với kubectl explain. Các công cụ như Kube-linter cũng hỗ trợ phát hiện cấu hình chưa phù hợp trong tệp YAML.

Tài nguyên phân bổ không đồng đều

Node Affinity thường được sử dụng để hướng workload đến các node có GPU, SSD hoặc phần cứng chuyên dụng. Nếu nhiều Pod cùng phụ thuộc vào một nhóm label, các node phù hợp dễ rơi vào tình trạng quá tải, trong khi tài nguyên trên những node còn lại chưa được khai thác hiệu quả.

Affinity nên được kết hợp với resource requests và limits để Scheduler đánh giá chính xác nhu cầu của từng Pod. Horizontal Pod Autoscaler và Cluster Autoscaler có thể hỗ trợ điều chỉnh quy mô workload hoặc hạ tầng khi nhu cầu tài nguyên thay đổi.

Khả năng mở rộng và chi phí bị hạn chế

Pod Anti-Affinity nghiêm ngặt có thể yêu cầu cluster duy trì nhiều node hoặc nhiều Availability Zone hơn để đáp ứng điều kiện phân tán. Cấu hình này giúp tăng tính sẵn sàng, nhưng đồng thời làm phát sinh chi phí hạ tầng, truyền dữ liệu và vận hành. Với cluster nhỏ, số lượng topology domain hạn chế còn có thể khiến Scheduler không tìm được vị trí phù hợp.

Doanh nghiệp cần xác định mức độ phân tán dựa trên tầm quan trọng của workload và ngân sách thực tế. Soft anti-affinity nên được ưu tiên khi yêu cầu không tuyệt đối, còn Taints and Tolerations có thể được kết hợp để kiểm soát nhóm node chuyên dụng hiệu quả hơn.

Kết luận

Affinity và Anti-Affinity trong Kubernetes giúp kiểm soát cách Pod được sắp xếp trên node hoặc zone, từ đó cân bằng hiệu suất, khả năng chịu lỗi và mức độ sử dụng tài nguyên. Để các quy tắc phát huy hiệu quả, quản trị viên cần xây dựng hệ thống label rõ ràng, lựa chọn topology phù hợp và tránh đặt ràng buộc quá nghiêm ngặt.

Khi workload ngày càng phức tạp, yêu cầu kiểm soát vị trí Pod cũng cần đi kèm một nền tảng Kubernetes ổn định, linh hoạt và dễ mở rộng. Viettel Dedicated Kubernetes Service (vDKS) hỗ trợ khởi tạo, quản lý cluster tập trung trên hạ tầng Viettel IDC, thuận tiện áp dụng Affinity, Anti-Affinity cùng nhiều chính sách lập lịch khác trong quá trình vận hành ứng dụng container.

Tham khảo dịch vụ tại: https://viettelidc.com.vn/viettel-kubernetes-service