Scheduler: affinity, taints, topology
Placement là một quyết định reliability, không chỉ tìm CPU còn trống.
Nắm bản chất
Scheduler xem xét resource requests, node labels, node affinity, taints/tolerations, pod affinity/anti-affinity và topology spread constraints. Affinity cho phép ưu tiên hoặc yêu cầu placement; taints ngăn Pods không có toleration tương ứng; topology spread giúp phân tán replicas qua failure domains.
Anti-affinity cứng có thể khiến Pod Pending khi không đủ nodes/AZ; lựa chọn soft constraints có thể tăng khả năng schedule nhưng giảm phân tán. Hãy định nghĩa rõ yêu cầu về availability trước khi chọn hard/soft.
Luồng hoạt động
Hãy tự giải thích mỗi mũi tên: dữ liệu, quyền hoặc tín hiệu nào được truyền qua bước này?
Lệnh & cấu hình mẫu
kubectl get nodes --show-labels
kubectl -n app describe pod API_POD
kubectl -n app get pods -o wide
kubectl get events -A --sort-by=.lastTimestamp | tail -30
Lệnh có placeholder hoặc phụ thuộc môi trường thì cần thay thông tin thực tế, kiểm tra quyền và chỉ thực hiện trên tài nguyên được phép.
Bài tập 10–20 phút
Dùng lab Buổi 11: tạo Deployment có podAntiAffinity rồi scale khi số nodes
có giới hạn. Quan sát FailedScheduling và giải thích nguyên
nhân.
Lỗi dễ mắc
Đừng thêm toleration cho mọi taint để “cho Pod chạy”. Taints có thể đánh dấu node dành riêng hoặc node không an toàn.
Tự kiểm tra
Taints và tolerations có tự ép Pod lên node đó không?Xem đáp án ↗
Không. Toleration cho phép vượt qua taint; node affinity/nodeSelector mới giúp ràng buộc placement.
Học thêm qua lab
Có project thực hành đúng với chương này, kèm README và những giới hạn môi trường cần lưu ý.
↓ Tải mã nguồn thực hành chương 11Đối chiếu tài liệu gốc
Cú pháp và khả năng hỗ trợ có thể thay đổi theo phiên bản. Trước khi dùng Production, hãy kiểm tra tài liệu tương ứng.
Mở tài liệu chính thức ↗