Kubernetes v1.35: Mở rộng Toleration Operators hỗ trợ so sánh số học (Alpha)

1. Thử thách từ những con số

Hãy tưởng tượng bạn đang quản lý một cluster lớn và nhận được yêu cầu: “Chỉ cho phép các dịch vụ quan trọng chạy trên những Node có xác suất xảy ra lỗi dưới 5%.”

Trong thực tế hiện nay, các Taints và Tolerations của Kubernetes chỉ có thể khớp các giá trị chính xác (exact values) hoặc kiểm tra sự tồn tại của Key. Chúng hoàn toàn bất lực trước việc so sánh các ngưỡng số (numeric thresholds). Để giải quyết, chúng ta thường phải chia nhỏ các Taint thành từng loại rời rạc, dùng Admission Controller bên ngoài, hoặc chấp nhận việc lập lịch (scheduling) không tối ưu.

Với phiên bản Kubernetes v1.35, cộng đồng đã giới thiệu Extended Toleration Operators dưới dạng tính năng Alpha. Cải tiến này bổ sung hai Operator là Gt (Greater Than – Lớn hơn) và Lt (Less Than – Nhỏ hơn) vào trường spec.tolerations. Điều này cho phép thực hiện các quyết định lập lịch dựa trên ngưỡng, mở ra khả năng quản lý placement theo SLA, tối ưu chi phí và phân phối workload dựa trên hiệu năng.

2. Sự nâng cấp của cơ chế Tolerations

Về mặt lịch sử, Kubernetes chỉ hỗ trợ hai Operator chính cho Toleration:

Equal: Khớp Taint nếu cả Key và Value đều giống hệt nhau.
Exists: Khớp Taint nếu Key tồn tại, không quan tâm đến Value.

Mặc dù hai toán tử này hoạt động tốt cho các kịch bản định danh (categorical), chúng lại thất bại khi đối mặt với so sánh số học. v1.35 đã lấp đầy khoảng trống này. Hãy xem xét các kịch bản thực tế:

Yêu cầu SLA: Lập lịch cho các workload HA chỉ trên các Node có xác suất lỗi thấp.
Tối ưu chi phí: Cho phép các Batch Job chạy trên các Node giá rẻ khi chi phí mỗi giờ (cost-per-hour) vượt quá một ngưỡng nhất định.
Đảm bảo hiệu năng: Đảm bảo ứng dụng nhạy cảm với độ trễ (latency-sensitive) chỉ chạy trên Node có chỉ số IOPS hoặc băng thông mạng trên mức tối thiểu.

3. Tại sao lại mở rộng Toleration mà không dùng NodeAffinity?

Có một thắc mắc phổ biến: NodeAffinity đã hỗ trợ so sánh số, vậy tại sao lại cần thêm vào Tolerations? Đội ngũ Kubernetes nhấn mạnh 3 lợi ích vận hành cốt yếu của Taints/Tolerations:

Tính định hướng chính sách (Policy Orientation): NodeAffinity nằm ở phía Pod, yêu cầu mọi workload phải chủ động né tránh các Node rủi ro. Taints thì ngược lại: Node tự tuyên bố mức rủi ro, và chỉ Pod nào có Toleration phù hợp mới được phép landing. Đây là cơ chế “Safe default” (mặc định an toàn).
Cơ chế trục xuất (Eviction Semantics): NodeAffinity không có khả năng trục xuất. Taints hỗ trợ hiệu ứng NoExecute kết hợp với tolerationSeconds. Điều này cho phép SRE “drain” và đuổi Pod khi SLA của Node bị giảm sút (ví dụ: khi Node Spot nhận thông báo sắp bị thu hồi).
Công thái học vận hành (Operational Ergonomics): Chính sách tập trung tại phía Node giúp việc quản lý cluster trực quan hơn, tương tự như cách chúng ta quản lý các lỗi hệ thống (disk-pressure, memory-pressure).

4. Giới thiệu toán tử Gt và Lt

Kubernetes v1.35 giới thiệu:

Gt (Greater Than): Khớp nếu giá trị số của Taint lớn hơn giá trị trong Toleration.
Lt (Less Than): Khớp nếu giá trị số của Taint nhỏ hơn giá trị trong Toleration.

Giải thích logic: Khi một Pod khai báo Lt, nó đang nói: “Tôi có thể chịu đựng được các Node có chỉ số này nhỏ hơn ngưỡng của tôi”. Điều này có nghĩa là Pod có thể chạy trên Node có giá trị Taint lớn hơn giá trị Toleration. Hãy coi đây là: “Tôi chấp nhận các Node vượt trên mức yêu cầu tối thiểu của tôi”.

Lưu ý kỹ thuật:

Giá trị phải là số nguyên 64-bit dương, không có số 0 ở đầu (VD: "100" là đúng, "0100" là sai).
Không được sử dụng giá trị "0".

5. Các ví dụ thực tế (Use Cases)

Ví dụ 1: Bảo vệ Spot Instance với ngưỡng SLA

Chúng ta trộn lẫn Node On-demand và Node Spot. Node Spot rẻ nhưng rủi ro lỗi cao.

Cấu hình Taint trên Node Spot (Xác suất lỗi 15%):

apiVersion: v1
kind: Node
metadata:
  name: spot-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "15"
    effect: "NoExecute"

Cấu hình Taint trên Node On-demand (Xác suất lỗi 2%):

apiVersion: v1
kind: Node
metadata:
  name: ondemand-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "2"
    effect: "NoExecute"

Ứng dụng xử lý thanh toán (Payment Processor) yêu cầu SLA khắt khe:

apiVersion: v1
kind: Pod
metadata:
  name: payment-processor
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "5"  # Chỉ chịu được Node có xác suất lỗi dưới 5
    effect: "NoExecute"
    tolerationSeconds: 30
  containers:
  - name: app
    image: payment-app:v1

Kết quả: Pod này sẽ chỉ chạy trên ondemand-node-1. Nếu Node bị tăng rủi ro lỗi lên quá 5, Pod sẽ có 30 giây để terminate trước khi bị trục xuất.

Batch Job chấp nhận rủi ro để tối ưu chi phí:

apiVersion: v1
kind: Pod
metadata:
  name: batch-job
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "20" # Chấp nhận rủi ro lên tới 20%
    effect: "NoExecute"
  containers:
  - name: worker
    image: batch-worker:v1

Kết quả: Job này có thể chạy trên cả hai loại Node, giúp tận dụng tối đa tài nguyên giá rẻ.

Ví dụ 2: Lập lịch cho AI Workload dựa trên phân tầng GPU

Các tác vụ AI thường có yêu cầu phần cứng cụ thể. Chúng ta có thể dùng Taint để đánh dấu “rank” hiệu năng của GPU. Các Pod yêu cầu hiệu năng cao sẽ đặt ngưỡng Lt thấp (chỉ chấp nhận Node xịn), trong khi các tác vụ inference nhẹ có thể chấp nhận các GPU đời cũ hơn bằng cách nâng ngưỡng Lt lên cao hơn.

6. Kết luận

Tính năng Extended Toleration Operators trong v1.35 là một bước tiến quan trọng giúp Kubernetes tiệm cận hơn với việc quản lý hạ tầng theo hướng dữ liệu (data-driven infrastructure). Bằng cách cho phép so sánh số học ngay trong cơ chế Taint/Toleration, chúng ta có thể xây dựng các hệ thống tự phục hồi và tự điều phối một cách thông minh hơn rất nhiều dựa trên các chỉ số SLA thực tế.

Vì đây là tính năng Alpha, bạn cần kích hoạt Feature Gate ExtendedTolerationOperators để sử dụng.

Thông tin chi tiết tại: https://kubernetes.io/blog/2026/01/05/kubernetes-v1-35-numeric-toleration-operators/