Topology Spread Constraints là gì? Cơ chế phân tán Pod trong Kubernetes

Khi ứng dụng được triển khai trên nhiều node hoặc Availability Zone, các Pod có thể tập trung vào cùng một miền lỗi và làm tăng nguy cơ gián đoạn. Kubernetes cần một cơ chế kiểm soát mức độ phân tán workload để duy trì tính sẵn sàng khi hạ tầng gặp lỗi hoặc số lượng replica thay đổi. Cùng Viettel IDC tìm hiểu Topology Spread Constraints là gì và cách cơ chế này phân bổ Pod trong Kubernetes.

Topology Spread Constraints là gì?

Topology Spread Constraints là cơ chế lập lịch trong Kubernetes, cho phép kiểm soát cách các Pod được phân bổ giữa nhiều miền topology như node, Availability Zone, region hoặc miền do người dùng tự định nghĩa. Cơ chế này giúp hạn chế tình trạng nhiều Pod cùng tập trung trong một miền lỗi, từ đó nâng cao tính sẵn sàng và khả năng chịu lỗi của workload.

Ví dụ, một cluster có ba node và Deployment gồm ba replica. Thay vì để cả ba Pod cùng chạy trên một node, Topology Spread Constraints trong Kubernetes có thể được thiết lập để mỗi Pod nằm trên một node khác nhau hoặc được phân chia tương đối đồng đều giữa các node.

Cách hoạt động của Topology Spread Constraints trong Kubernetes

Cơ chế của Topology Spread Constraints dựa trên nhãn của node, nhóm Pod cần theo dõi và mức chênh lệch được cho phép giữa các topology domain. Khi một Pod mới cần được triển khai, kube-scheduler sẽ đánh giá trạng thái hiện tại của cluster trước khi lựa chọn vị trí phù hợp.

Trước tiên, topologyKey xác định phạm vi cần phân tán. Những node có cùng giá trị nhãn được xem là thuộc một domain. Tiếp theo, labelSelector giúp Scheduler nhận diện các Pod thuộc cùng nhóm cần tính toán. Hệ thống sẽ đếm số lượng bản sao phù hợp trong từng domain, xác định nơi đang có ít nhất và so sánh độ lệch với maxSkew.

Ví dụ, ba zone đang có số replica lần lượt là 2–2–1. Với maxSkew: 1, Pod mới nên được đưa vào zone chỉ có một replica để tạo tỷ lệ 2–2–2. Nếu đặt vào zone đang có hai bản sao, độ lệch sẽ vượt giới hạn.

Cách xử lý tiếp theo phụ thuộc vào whenUnsatisfiable. DoNotSchedule giữ Pod ở trạng thái Pending khi không còn vị trí phù hợp, còn ScheduleAnyway vẫn cho phép lập lịch nhưng ưu tiên domain giúp giảm độ chênh lệch.

Quá trình diễn ra theo trình tự:

- Xác định node có nhãn phù hợp với topologyKey.

- Lọc nhóm Pod bằng labelSelector.

- Đếm số replica trong từng topology domain.

- Tính độ lệch và so sánh với maxSkew.

- Lựa chọn node theo whenUnsatisfiable.

Khi Pod khai báo nhiều ràng buộc, kube-scheduler kết hợp chúng theo logic AND. Node được chọn phải đồng thời đáp ứng toàn bộ điều kiện đã thiết lập.

Vì sao Kubernetes cần Topology Spread Constraints?

Số lượng replica lớn chưa chắc giúp ứng dụng chịu lỗi tốt hơn nếu các bản sao vẫn tập trung trong cùng một miền hạ tầng. Topology Spread Constraints cho phép Kubernetes kiểm soát vị trí triển khai, hạn chế điểm lỗi tập trung và duy trì trạng thái ổn định khi hệ thống mở rộng.

Hạn chế nhiều Pod tập trung trên một node

Kubernetes Scheduler thường chọn node dựa trên tài nguyên còn trống và các điều kiện lập lịch đã thiết lập. Khi không có ràng buộc về topology, nhiều replica của cùng một ứng dụng dễ được đưa lên một máy chủ nếu CPU và bộ nhớ vẫn đáp ứng.

Ví dụ, một Deployment gồm bốn replica chạy trên cluster có bốn node, nhưng ba bản sao cùng nằm tại node-1. Nếu máy chủ này ngừng hoạt động, phần lớn năng lực phục vụ của ứng dụng sẽ mất đi cùng lúc. Hệ thống dễ rơi vào trạng thái quá tải trong thời gian Kubernetes khởi tạo các replica thay thế.

Khi sử dụng kubernetes.io/hostname làm topologyKey, Scheduler ưu tiên những node đang chứa ít bản sao hơn. Cách bố trí này giúp ứng dụng tránh phụ thuộc quá nhiều vào một điểm hạ tầng duy nhất.

Phân tán workload giữa các Availability Zone

Tách các replica sang nhiều node vẫn chưa đủ nếu toàn bộ máy chủ cùng thuộc một Availability Zone. Lỗi mạng, mất điện hoặc gián đoạn tại khu vực đó vẫn ảnh hưởng đến toàn bộ dịch vụ.

Giả sử một ứng dụng có sáu replica chạy trên ba node nhưng tất cả đều nằm trong zone-a. Khi cluster mở rộng sang zone-b và zone-c, Pod Topology Spread Constraints cho phép chia các bản sao theo tỷ lệ hai replica tại mỗi khu vực thông qua nhãn topology.kubernetes.io/zone.

Mô hình đa zone còn phù hợp với hệ thống phục vụ người dùng tại nhiều khu vực. Lưu lượng được định tuyến đến instance gần nguồn truy cập hơn sẽ góp phần giảm độ trễ, đồng thời hạn chế chi phí truyền dữ liệu giữa các Availability Zone.

Duy trì phân bố cân bằng khi scale

Số lượng replica thường thay đổi theo lưu lượng thực tế, đặc biệt khi ứng dụng sử dụng Horizontal Pod Autoscaler. Nếu thiếu quy tắc kiểm soát, các bản sao mới dễ tiếp tục được đặt vào miền đang chứa nhiều instance, làm độ chênh lệch ngày càng lớn.

Ví dụ, một ứng dụng ban đầu có ba replica và được chia đều như sau:

Khi mở rộng lên sáu replica, trạng thái hợp lý là mỗi khu vực có hai bản sao. Với maxSkew: 1, Scheduler ưu tiên miền đang có số lượng thấp hơn để giữ độ lệch trong giới hạn cho phép.

Cần lưu ý rằng ràng buộc này chủ yếu tác động tại thời điểm lập lịch replica mới. Sau khi Deployment scale down, các bản sao còn lại dễ rơi vào trạng thái mất cân bằng. Khi đó, quản trị viên cần dùng Descheduler hoặc chủ động sắp xếp lại workload.

Cải thiện khả năng sử dụng tài nguyên

Topology Spread Constraints không trực tiếp chia đều CPU hoặc RAM, nhưng góp phần hạn chế tình trạng một nhóm node phải xử lý phần lớn tải trong khi các máy chủ còn lại chưa được khai thác hiệu quả.

Chẳng hạn, ba node có cấu hình tương đương nhưng bốn trong năm replica đều chạy trên node-1. Máy chủ này nhanh chóng tiến gần giới hạn tài nguyên, trong khi node-2 và node-3 vẫn còn nhiều năng lực trống. Cách bố trí theo tỷ lệ 2–2–1 tạo ra mức sử dụng hợp lý hơn và tăng dư địa tiếp nhận lưu lượng.

Các thành phần trong topologySpreadConstraints

Trường topologySpreadConstraints gồm nhiều tham số giúp kube-scheduler xác định phạm vi phân tán, nhóm Pod cần tính toán, mức chênh lệch cho phép và cách xử lý khi không thể đáp ứng ràng buộc. Trong đó, maxSkew, topologyKey, whenUnsatisfiable và labelSelector là các thành phần cốt lõi; những trường còn lại hỗ trợ kiểm soát sâu hơn trong các kịch bản phức tạp.

So sánh Pod Topology Spread và Pod Anti-Affinity

Pod Topology Spread vs Pod Anti-Affinity đều hỗ trợ kiểm soát vị trí triển khai của các Pod trong cluster, nhưng mục tiêu và cách vận hành có nhiều khác biệt. Pod Topology Spread hướng đến duy trì mức phân bố hợp lý giữa các miền topology, còn Pod Anti-Affinity tập trung ngăn những Pod nhất định nằm trong cùng một domain.

Hướng dẫn cấu hình Topology Spread Constraints

Để minh họa rõ cách thiết lập ràng buộc phân tán, ví dụ dưới đây sử dụng một cluster gồm sáu node trải trên ba Availability Zone. Deployment có bảy replica và yêu cầu số Pod giữa các zone không chênh lệch quá một.

Bước 1: Xác định topology domain trong cluster

Giả sử hạ tầng được chia như sau:

Mỗi node cần có nhãn topology.kubernetes.io/zone tương ứng. Quản trị viên kiểm tra nhanh bằng lệnh:

Ví dụ kết quả:

Các node thiếu nhãn trên sẽ không được đưa vào phạm vi tính toán của constraint.

Bước 2: Khai báo topologySpreadConstraints trong Deployment

Giả sử bảy replica hiện được phân phối theo tỷ lệ 3–2–2 giữa ba zone. Manifest dưới đây giữ mức chênh lệch tối đa ở một Pod:

Trong cấu hình trên, topology.kubernetes.io/zone chia cluster thành ba miền độc lập. maxSkew: 1 cho phép số Pod giữa zone nhiều nhất và zone ít nhất lệch tối đa một, còn DoNotSchedule ngăn lập lịch nếu không tìm được vị trí phù hợp.

Khi Deployment tăng lên tám replica, Scheduler sẽ ưu tiên zone-b hoặc zone-c thay vì tiếp tục đưa Pod vào zone-a. Kết quả hợp lý là 3–3–2 hoặc 3–2–3, đều nằm trong giới hạn đã đặt.

Bước 3: Triển khai và kiểm tra kết quả

Lưu manifest thành web-deployment.yaml, sau đó áp dụng:

Kiểm tra vị trí của từng Pod:

Nếu cluster đã gắn nhãn chính xác và còn đủ tài nguyên, các replica sẽ được trải tương đối đồng đều giữa ba Availability Zone. Khi một Pod ở trạng thái Pending, dùng lệnh sau để xem nguyên nhân:

Các lỗi thường gặp gồm node thiếu topologyKey, labelSelector không khớp nhãn của Pod, tài nguyên không đủ hoặc nhiều constraint cùng áp dụng nhưng không có node nào thỏa toàn bộ điều kiện.

Muốn phân tán theo từng node thay vì theo zone, đổi giá trị:

Khi đó, mỗi node trở thành một topology domain riêng và kube-scheduler sẽ tính mức chênh lệch ở cấp máy chủ.

Kết luận

Topology Spread Constraints là gì có thể hiểu là cơ chế giúp Kubernetes kiểm soát mức độ phân tán Pod giữa các node, Availability Zone hoặc miền topology khác. Khi lựa chọn đúng, doanh nghiệp sẽ hạn chế điểm lỗi tập trung, duy trì tính sẵn sàng và mở rộng workload ổn định hơn.

Viettel Dedicated Kubernetes Service (vDKS) cung cấp nền tảng Kubernetes được triển khai trên hạ tầng Viettel IDC, hỗ trợ doanh nghiệp xây dựng, quản lý và mở rộng ứng dụng container theo nhu cầu thực tế. Dịch vụ giúp rút ngắn quá trình khởi tạo cluster, giảm áp lực vận hành hạ tầng và tạo nền tảng thuận lợi để áp dụng các cơ chế lập lịch như Topology Spread Constraints.

Tham khảo chi tiết tại: https://viettelidc.com.vn/viettel-kubernetes-service