اپراتورهای با تحمل گسترده برای پشتیبانی از مقایسه‌های عددی

Kubernetes v1.35 اپراتورهای جدیدی تحت عنوان Operators Extended Toleration (ویژگی آلفا) معرفی می‌کند که به شما امکان می‌دهد تصمیم‌های زمان‌بندی را بر اساس مقایسه‌های عددی بین taint‌های گره و tolerationهای پاد بگیرید — دقیقاً همان چیزی که برای مدیریت هوشمندانه‌ی ترکیب گره‌های on‑demand و spot/ preemptible لازم است. 🚀

در بسیاری از خوشه‌های تولیدی، تیم‌های پلتفرم گره‌های با SLA بالا (on‑demand) و گره‌های ارزان ولی ناپایدار (spot) را با هم استفاده می‌کنند. نیاز رایج این است که به طور پیش‌فرض بیشتر پادها از گره‌های پرخطر دور بمانند، اما به بعضی بارها اجازه دهیم با آستانه‌های صریح مثل «می‌توانم گره‌هایی با احتمال خرابی تا 5٪ را تحمل کنم» روی آن گره‌ها بنشینند. Operators Extended Toleration این امکان را فراهم می‌کند تا به‌جای برچسب‌زنی گسسته، مقادیر عددی را مقایسه کنید و تصمیم‌گیری‌های زمان‌بندی مبتنی بر آستانه داشته باشید. ⚖️🔧

تا امروز، taint/toleration اکثر مواقع بر برابری کلید/مقدار تکیه داشت؛ یعنی یک toleration وقتی match می‌شد که مقدار دقیقاً برابر باشد. NodeAffinity از مدتی قبل از عملگرهای مقایسه‌ای برای مقادیر عددی پشتیبانی می‌کرد، اما taint/toleration نه — یعنی ما فرصت کنترل سیاست‌محور (node-driven policy) و مدل evict بر اساس تغییرات مقادیر گره را از دست می‌دادیم. با اضافه شدن عملگرهای Gt و Lt، این شکاف بسته می‌شود و مدل taint/toleration می‌تواند تصمیم‌های مبتنی بر آستانه را با پشتیبانی از اثرات NoSchedule، NoExecute و PreferNoSchedule انجام دهد. 🧭

عملگرها چگونه کار می‌کنند؟ خلاصه فنی و شفاف:

– operator: “Gt” — toleration با taint مطابقت دارد وقتی مقدار taint بزرگتر از مقدار toleration باشد (V_taint > V_tol).

– operator: “Lt” — toleration با taint مطابقت دارد وقتی مقدار taint کمتر از مقدار toleration باشد (V_taint < V_tol).

– مقادیر باید عدد صحیح 64‑بیتی باشند، نباید leading zeros داشته باشند و مقدار “0” مجاز نیست. 📏

این یعنی اگر node taint ای مثل failure-probability=2 داشته باشد و پاد toleration با operator: “Lt” و value: “5” تعریف شده باشد، آن پاد آن گره را تحمل می‌کند و می‌تواند روی آن برنامه‌ریزی شود — مناسب برای بیان «من فقط مایل به اجرای روی گره‌هایی هستم که احتمال خرابی کمتر از 5٪ دارند». همچنین، وقتی effect برابر NoExecute و tolerationSeconds مشخص شده باشد، می‌توانید رفتار تخلیه (eviction) را هم کنترل کنید. 🧠

مثال 1 — نشانه‌گذاری nodeها: گره‌های spot با احتمال خرابی 15% و گره‌های on‑demand با 2%:

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

مثال 2 — پاد بحرانی با SLA سختگیرانه که فقط روی گره‌هایی با failure-probability کمتر از 5٪ برنامه‌ریزی شود و در صورت بدتر شدن مقدار گره، تا 30 ثانیه فرصت پاک شدن داشته باشد:

apiVersion: v1
kind: Pod
metadata:
  name: payment
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "5"
    effect: "NoExecute"
    tolerationSeconds: 30
  containers:
  - name: app
    image: payment-app:v1

توضیح عملی: این Pod فقط روی گره‌هایی برنامه‌ریزی می‌شود که failure-probability < 5 باشند (مثل ondemand-node-1 بالا). اگر ارائه‌دهنده ابر مقدار taint را تغییر دهد و گره دیگر مطابق SLA نباشد، اثر NoExecute به همراه tolerationSeconds باعث می‌شود پاد تا آن زمان نرم‌خروج (graceful) تخلیه شود. ⏱️

مثال 3 — کار دسته‌ای حساس به هزینه که می‌تواند گره‌هایی با احتمال خرابی تا 20٪ را تحمل کند (پس می‌تواند روی spot یا on‑demand اجرا شود):

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  template:
    spec:
      tolerations:
      - key: "failure-probability"
        operator: "Lt"
        value: "20"
        effect: "NoExecute"
      containers:
      - name: worker
        image: batch-worker:v1
      restartPolicy: OnFailure

مثال 4 — سطوح GPU: می‌توانید گره‌ها را بر اساس قدرت محاسباتی GPU با taint مقداردهی کنید و سپس بارهای یادگیری ماشین را تنها روی گره‌های با امتیاز کافی بنشانید.

apiVersion: v1
kind: Node
metadata:
  name: gpu-node-a100
spec:
  taints:
  - key: "gpu-type"
    value: "a100"
    effect: NoSchedule
---
apiVersion: v1
kind: Node
metadata:
  name: gpu-node-t4
spec:
  taints:
  - key: "gpu-compute-score"
    value: "500"
    effect: NoSchedule
---
apiVersion: v1
kind: Pod
metadata:
  name: ml-trainer
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "800"
    effect: NoSchedule
  containers:
  - name: trainer
    image: ml-trainer:v1
    resources:
      limits:
        nvidia.com/gpu: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: ml-inference
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "400"
    effect: NoSchedule
  containers:
  - name: inference
    image: ml-inference:v1
    resources:
      limits:
        nvidia.com/gpu: 1

توضیح: ml-trainer فقط روی گره‌هایی با gpu-compute-score > 800 برنامه می‌نشیند (برای آموزش سنگین)، در حالی که ml-inference با threshold پایین‌تر (مثلاً 400) می‌تواند روی گره‌های ضعیف‌تر اجرا شود. این الگو به شما امکان می‌دهد هزینه و عملکرد را با هم متعادل کنید. 🧩

مثال 5 — بهینه‌سازی هزینه: یک کار دسته‌ای حساس به هزینه که فقط روی گره‌هایی با هزینه کمتر از 100 (واحد دلاری/ساعتی) اجرا شود:

apiVersion: batch/v1
kind: Job
metadata:
  name: cost-sensitive-batch
spec:
  template:
    spec:
      tolerations:
      - key: "cost-per-hour"
        operator: "Lt"
        value: "100"
        effect: NoSchedule
      containers:
      - name: batch
        image: batch-worker:v1
      restartPolicy: OnFailure

مثال 6 — نیازمندی حداقل IOPS دیسک: اگر برنامه‌ای نیاز به تضمین I/O دارد:

apiVersion: v1
kind: Pod
metadata:
  name: io-intensive
spec:
  tolerations:
  - key: "disk-iops"
    operator: "Gt"
    value: "3000"
    effect: NoSchedule
  containers:
  - name: app
    image: io-app:v1

چگونه این ویژگی را امتحان کنیم (در محیط توسعه / staging):

# فعال‌سازی feature gate روی apiserver و scheduler
--feature-gates=TaintTolerationComparisonOperators=true

# نمونه taint روی یک node
kubectl taint nodes node-1 failure-probability=5:NoExecute
kubectl taint nodes node-1 disk-iops=5000:NoSchedule

# نمونه ساده toleration در Pod spec
tolerations:
- key: "failure-probability"
  operator: "Lt"
  value: "5"
  effect: "NoExecute"

نکته مهم: این قابلیت در این نسخه آلفا است — ممکن است رفتار/API در نسخه‌های بعدی تغییر کند. حتماً پیش از استفاده در محیط‌های production، کامل تست و بارگذاری (stress) کنید و سناریوهای evacuation/eviction و autoscaler را بررسی نمایید. 🧪

مسیر پیش رو: تیم توسعه قصد دارد با دریافت بازخورد از جامعه ویژگی‌هایی مثل پشتیبانی از عبارات CEL برای منطق پیچیده‌تر در toleration/taint، ادغام بهتر با autoscaler خوشه‌ای و ارتقا به حالت بتا را دنبال کند. اگر سناریو، نیاز یا ایده‌ای دارید که در آن زمان‌بندی مبتنی بر آستانه مشکل‌گشا باشد، خوشحال می‌شویم بشنویم — مشارکت توسط SIG Scheduling هدایت می‌شود. 📣

برای ارتباط و به اشتراک‌گذاری بازخورد می‌توانید به کانال‌های SIG Scheduling بپیوندید (مثلاً #sig-scheduling در Kubernetes Slack) یا در mailing list مربوط مشارکت کنید. مشتاق شنیدن سناریوهای شما و موارد استفاده‌تان هستیم! 🙌