Cách sử dụng Taints và Tolerations trong Kubernetes đầy đủ 2026

Bạn có một Node chứa GPU đắt tiền và không muốn các ứng dụng web thông thường vô tình được đưa vào đó? Hoặc bạn muốn dành riêng một cụm máy chủ cho một team cụ thể? Đó là lúc bạn cần đến sức mạnh của Taints và Tolerations trong Kubernetes.

Bài viết này sẽ giải phẫu chi tiết khái niệm, cú pháp, các hiệu ứng và cách ứng dụng Taints và Tolerations trong Kubernetes chuẩn xác nhất trong thực tế.

Taints và Tolerations trong Kubernetes là gì?

Taints và Tolerations trong Kubernetes là hai cơ chế hoạt động song hành nhằm kiểm soát chặt chẽ việc Pod nào được phép hoặc không được phép phân bổ lên một Node cụ thể.

Taint là một thuộc tính được gắn lên Node. Nó có tác dụng "đẩy" (repel) các Pod ra khỏi Node đó. Bất kỳ Pod nào không có khai báo phù hợp sẽ tuyệt đối không được Scheduler đưa vào Node này.

Toleration là một thuộc tính được gắn lên Pod. Nó cho phép (nhưng không bắt buộc) Pod "chịu đựng" được một Taint cụ thể. Nhờ có Toleration, Pod mới có cơ hội được lên lịch vào Node mang Taint tương ứng.

Hãy tưởng tượng Taint giống như một tấm biển báo "Khu vực độc hại: Cấm vào trừ khi có đồ bảo hộ" dán trước cổng một máy chủ Node. Các Pod bình thường khi thấy biển này sẽ tự động quay xe đi tìm Node khác. Trong khi đó, Toleration chính là "Bộ đồ bảo hộ" mà một số Pod đặc biệt được trang bị. Có bộ đồ này, Pod được cấp giấy phép để đi qua cổng và chạy trên Node đó.

Cú pháp khai báo Taint và Toleration trong Kubernetes

Thêm taint vào node bằng lệnh kubectl taint nodes <tên-node> key=value:effect

Để gắn một Taint lên Node, bạn sử dụng lệnh kubectl taint với cấu trúc key=value:effect. Ví dụ, để đánh dấu node worker-gpu-1 chỉ dành cho các tác vụ xử lý đồ họa:

(Mẹo: Để xóa Taint này đi, bạn chỉ cần thêm dấu trừ - vào cuối lệnh: kubectl taint nodes worker-gpu-1 gpu-type=nvidia:NoSchedule-)

Khai báo toleration trong phần tolerations của pod spec

Để Pod có thể chạy trên node worker-gpu-1 vừa bị taint ở trên, bạn cần khai báo Toleration tương ứng bên trong tệp YAML của Pod (pod.spec.tolerations):

Toán tử Equal và Exists

Thuộc tính operator trong Toleration quyết định cách Pod so khớp với Taint:

- Equal (Mặc định): Yêu cầu Pod phải khai báo khớp chính xác cả key lẫn value của Taint. (Như ví dụ YAML ở trên).

- Exists: Chỉ cần khớp key của Taint là đủ, không cần quan tâm đến value là gì. Nếu bạn dùng toán tử này, bạn phải bỏ trống trường value trong YAML.

Ba hiệu ứng effect của Taint trong Kubernetes

Thuộc tính effect xác định mức độ "đẩy" của Taint đối với Pod. Có 3 loại hiệu ứng:

1. NoSchedule (Chặn cứng)

Đây là hiệu ứng phổ biến nhất. Pod mới nếu không có Toleration phù hợp sẽ chắc chắn không được lên lịch vào Node. Tuy nhiên, nó là một lệnh cấm tương lai: các Pod đang chạy sẵn trên Node trước khi Taint được áp dụng sẽ không bị ảnh hưởng và vẫn tiếp tục hoạt động bình thường.

2. PreferNoSchedule (Chặn mềm)

Đây là phiên bản "mềm mỏng" hơn. Scheduler sẽ cố gắng hết sức (best-effort) để không đưa Pod vào Node mang Taint này. Nhưng nếu cụm đã hết sạch tài nguyên trên các Node khác và không còn lựa chọn nào tốt hơn, Scheduler vẫn có thể linh động xếp Pod vào Node này dù Pod không có Toleration.

3. NoExecute (Trục xuất)

Đây là hiệu ứng mạnh nhất và cực kỳ "tàn nhẫn". Nó không chỉ chặn Pod mới (giống NoSchedule) mà còn trục xuất (evict) ngay lập tức tất cả các Pod đang chạy trên Node nếu chúng không có Toleration phù hợp. Điểm đặc biệt của NoExecute là nó có thể đi kèm với thuộc tính tolerationSeconds trong cấu hình Pod. Thuộc tính này cho phép Pod một khoảng "thời gian ân hạn" (grace period) trước khi bị đuổi khỏi Node. Ví dụ: tolerationSeconds: 3600 nghĩa là Pod được phép nán lại Node thêm 1 giờ đồng hồ sau khi Node bị dính Taint NoExecute.

Taints do hệ thống tự động gán

Không chỉ do quản trị viên tự gán, bản thân Kubernetes Node Controller cũng liên tục theo dõi sức khỏe của máy chủ và tự động gắn Taint khi có sự cố.

- Tự động gắn Taint sự cố: Khi phát hiện Node gặp vấn đề, hệ thống sẽ tự động gắn các taint như node.kubernetes.io/not-ready hoặc node.kubernetes.io/unreachable với effect là NoExecute.

- Toleration ngầm định (Default): Theo mặc định, Admission Controller của Kubernetes tự động tiêm (inject) sẵn một toleration ngầm định cho 2 taint trên vào mọi Pod, với tolerationSeconds là 300 giây. Điều này giải thích tại sao khi một Node đột ngột mất kết nối mạng chớp nhoáng, các Pod trên đó không bị trục xuất ngay lập tức mà hệ thống sẽ đợi 5 phút trước khi "khai tử" chúng để tạo Pod thay thế ở nơi khác.

- Bảo vệ Control Plane: Các Node đóng vai trò Master/Control-plane thường được tự động gán sẵn taint node-role.kubernetes.io/control-plane:NoSchedule. Điều này giúp đảm bảo các Pod ứng dụng thông thường không vô tình được lên lịch vào đây, dành trọn tài nguyên cho các tiến trình điều phối của Kubernetes.

Kết hợp Taints và Tolerations trong Kubernetes với Node Affinity

Để làm chủ hoàn toàn nghệ thuật xếp lịch trong Kubernetes, bạn phải hiểu sự khác biệt và cách kết hợp giữa hai khái niệm này:

- Taint và Toleration trong Kubernetes là cơ chế "Đẩy": Nó xua đuổi các Pod không mong muốn khỏi Node, nhưng không thu hút Pod mục tiêu. Một Pod có Toleration gpu=true hoàn toàn có thể bị Scheduler ném sang một Node bình thường không có GPU.

- Node Affinity là cơ chế "Kéo": Nó thu hút Pod về phía các Node có nhãn (label) nhất định. (Ví dụ: Pod yêu cầu chỉ chạy trên node có label disk=ssd).

Tuyệt chiêu Dedicated Nodes (Node dành riêng): Khi bạn muốn một nhóm Node chỉ chạy một loại ứng dụng cụ thể (VD: Database) và ứng dụng đó phải chạy trên nhóm Node này, bạn phải kết hợp cả hai:

1. Gắn Taint lên Node để cản bước các Pod rác lạc vào.

2. Cấu hình Toleration trên Pod Database để vượt qua Taint.

3. Cấu hình Node Affinity trên Pod Database để ép nó chủ động tìm đến đúng nhóm Node đó thay vì chạy rải rác ở các Node trống khác.

Ứng dụng thực tế của Taints và Tolerations trong Kubernetes

Dành riêng node cho phần cứng đặc biệt như GPU

Các máy chủ sở hữu card đồ họa (GPU) hoặc vi xử lý tensor (TPU) tốn rất nhiều chi phí. Bằng cách gán Taint hardware=gpu:NoSchedule, bạn cấm cửa mọi ứng dụng web, API thông thường chạy trên đó. Chỉ những workload Machine Learning/AI có cấu hình Toleration tương ứng mới được phép chạm vào nguồn tài nguyên quý giá này.

Cách ly node theo team hoặc tenant trong cụm dùng chung

Trong môi trường multi-tenant, bạn có thể thiết lập các Node Pool riêng cho từng team. Node của Team A sẽ có Taint tenant=team-a:NoSchedule. Chỉ các Pod do Team A deploy (được tự động gắn Toleration qua Mutating Webhook) mới có thể chạy trên máy chủ do họ trả tiền, đảm bảo tính cách ly vật lý và bảo mật.

Cơ chế tự động xử lý khi node gặp sự cố sức khỏe

Dựa vào cơ chế Taints tự động của Kubernetes, các hệ thống vận hành có thể thiết kế để tự động trục xuất (evict) Pod sang Node lành mạnh khác ngay khi Node cũ gặp lỗi phần cứng, báo đầy ổ đĩa (node.kubernetes.io/disk-pressure), hoặc cạn kiệt PID.

Sai lầm khi dùng Taints và Tolerations trong Kubernetes

Ảo tưởng về sức mạnh của Toleration

Rất nhiều người hiểu nhầm rằng việc cấu hình Toleration cho Pod đồng nghĩa với việc ép Pod đó chắc chắn được lên lịch vào Node mang Taint. Sai! Toleration chỉ là cái "thẻ thông hành" loại bỏ rào cản, scheduler vẫn có quyền xếp Pod vào một Node trống khác không có Taint. Để ép buộc, bạn phải dùng Node Affinity.

Trục xuất oan uổng vì quên tolerationSeconds

Khi sử dụng effect NoExecute lên Node, nếu quên cấu hình tolerationSeconds trên Pod, các Pod đang chạy sẽ bị "giết" ngay tắp lự. Điều này khiến ứng dụng không có thời gian gracefully shutdown (đóng kết nối an toàn), gây đứt gãy dịch vụ.

Nhầm lẫn vai trò đẩy hay kéo

Dùng Taint/Toleration để "kéo" Pod về Node là một thiết kế chiến lược lên lịch sai lầm hoàn toàn, dẫn đến việc Pod chạy rải rác không đúng mục đích thiết kế ban đầu.

Câu hỏi thường gặp về Taints và Tolerations trong Kubernetes 

Toleration có đảm bảo pod chắc chắn được lên lịch vào node có taint không? Không. Toleration chỉ cấp quyền để Pod được phép vào Node đó. Nếu một Node khác (không có Taint) có nhiều tài nguyên trống hơn, Scheduler hoàn toàn có thể xếp Pod sang Node bình thường đó.

Một node có thể có nhiều taint cùng lúc không? Có. Một Node có thể mang nhiều Taint, và một Pod cũng có thể mang nhiều Toleration. Kubelet sẽ rà soát từng Taint trên Node, loại trừ những Taint mà Pod có Toleration. Nếu sau khi đối chiếu mà Node vẫn còn sót lại Taint nào mang hiệu ứng NoSchedule, Pod sẽ bị từ chối.

Taints và Tolerations khác gì so với Node Affinity? Taint mang tính chất xua đuổi (Repulsion) - từ chối Pod. Node Affinity mang tính chất thu hút (Attraction) - kéo Pod về phía Node. Thường phải kết hợp cả hai để đạt hiệu quả "Cách ly hoàn toàn" (Dedicated Nodes).

Kết luận

Taints và Tolerations  trong Kubernetes  là bộ đôi công cụ không thể thiếu đối với bất kỳ Kubernetes Administrator nào muốn kiểm soát dòng chảy của các workload trong hệ thống. Việc nắm vững cách hoạt động của chúng không chỉ giúp bạn tối ưu hóa việc sử dụng các phần cứng đắt tiền (như GPU), cách ly môi trường bảo mật, mà còn thấu hiểu cơ chế tự bảo vệ sức khỏe của chính cụm Kubernetes khi có sự cố xảy ra.

Hãy nhớ quy tắc cốt lõi: Taint là biển cấm, Toleration là giấy thông hành, và hãy luôn kết hợp chúng với Node Affinity để có một chiến lược xếp lịch hoàn hảo.

Để giải quyết bài toán này, doanh nghiệp có thể tham khảo dịch vụ Viettel Dedicated Kubernetes Service (vDKS). Đây là giải pháp Kubernetes được quản lý toàn diện do Viettel IDC cung cấp, mang đến hạ tầng mạnh mẽ, ổn định cùng đội ngũ chuyên gia kỹ thuật đồng hành. Với vDKS, doanh nghiệp có thể rũ bỏ hoàn toàn gánh nặng quản trị nền tảng, các bản vá lỗi hay nâng cấp hệ thống, từ đó tập trung 100% nguồn lực vào việc phát triển ứng dụng và kiến tạo giá trị kinh doanh cốt lõi.

Tìm hiểu thêm về dịch vụ Viettel Dedicated Kubernetes Service (vDKS) tại đây: https://viettelidc.com.vn/viettel-kubernetes-service