Kubernetes v1.35: Розширені оператори толерантності для підтримки числових порівнянь (Alpha)

Багато робочих кластерів Kubernetes поєднують вузли на вимогу (вищий рівень SLA) та спот-вузли/вузли з правом витіснення (нижчий рівень SLA) для оптимізації витрат при збереженні надійності критичних робочих навантажень. Команди платформи потребують безпечного стандартного варіанту, який утримує більшість робочих навантажень подалі від ризикованих потужностей, одночасно дозволяючи певним робочим навантаженням підключатися з явними пороговими значеннями, такими як «Я можу толерувати вузли з імовірністю відмови до 5%».

Сьогодні Kubernetes taints і tolerations можуть відповідати точним значенням або перевіряти наявність, але вони не можуть порівнювати числові пороги. Вам потрібно буде створити дискретні категорії taint, використовувати зовнішні контролери допуску або приймати рішення про розміщення, що не є оптимальними.

У Kubernetes v1.35 ми впроваджуємо розширені оператори толерантності як альфа-функцію. Це вдосконалення додає оператори Gt (більше ніж) і Lt (менше ніж) до spec.tolerations, що дозволяє приймати рішення про планування на основі порогових значень, які відкривають нові можливості для розміщення на основі SLA, оптимізації витрат і розподілу робочих навантажень з урахуванням продуктивності.

Розвиток толерантностей

Історично Kubernetes підтримував два основні оператора толерантності:

• Equal: толерантність відповідає позначці taint, якщо ключ і значення є абсолютно однаковими
• Exists: толерантність відповідає позначці taint, якщо ключ присутній, незалежно від значення

Хоча ці функції добре працювали для категорійних сценаріїв, вони не підходили для числових порівнянь. Починаючи з версії 1.35, ми усуваємо цю прогалину.

Розглянемо такі реальні ситуації:

• Вимоги SLA: планувати робочі навантаження з високою доступністю тільки на вузлах із ймовірністю відмови нижче певного порогу
• Оптимізація витрат: Дозвольте виконувати чутливі до витрат пакетні завдання на дешевших вузлах, які перевищують певну вартість за годину
• Гарантії продуктивності: Забезпечте, щоб чутливі до затримок застосунки виконувалися тільки на вузлах з дисковим IOPS або пропускною здатністю мережі вище мінімальних порогів

Без операторів числового порівняння оператори кластерів мусили вдаватися до обхідних рішень, таких як створення декількох дискретних значень taint або використання зовнішніх контролерів допуску, жоден з яких не масштабується добре і не забезпечує гнучкості, необхідної для динамічного планування на основі порогових значень.

Для чого розширювати толерантності замість використання NodeAffinity?

Ви можете запитати: NodeAffinity вже підтримує числові оператори порівняння, тож навіщо розширювати толерантності? Хоча NodeAffinity є потужним інструментом для вираження налаштувань подів, taints і tolerations надають важливі операційні переваги:

• ** Орієнтованість на політику**: NodeAffinity працює для кожного окремого пода, вимагаючи, щоб кожне робоче навантаження явно відмовлялося від ризикованих вузлів. Taints інвертують контроль — вузли заявляють свій рівень ризику, і тільки поди з відповідними tolerations можуть там розміщуватися. Це забезпечує більш безпечні стандартні налаштування; більшість подів тримаються подалі від spot/preemptible вузлів, якщо вони явно не вибирають їх.
• Семантика виселення: NodeAffinity не має можливості виселення. Taints підтримують ефект NoExecute з tolerationSeconds, що дозволяє операторам виводити та виселяти поди, коли SLA вузла погіршується або спотові інстанції отримують повідомлення про припинення.
• Ергономіка експлуатації: централізована політика на стороні вузла узгоджується з іншими безпечними taints, такими як навантаження на диск і навантаження на памʼять, що робить управління кластером більш інтуїтивним.

Це вдосконалення зберігає добре зрозумілу модель безпеки позначок і толерантності, одночасно забезпечуючи розміщення на основі порогових значень для планування з урахуванням SLA.

Представляємо оператори Gt та Lt

Kubernetes v1.35 представляє два нових оператори для толерантності:

• Gt (більше ніж): толерантність застосовується, якщо числове значення taint більше за значення толерантності
• Lt (менше ніж): толерантність застосовується, якщо числове значення taint менше за значення толерантності

Коли под толерує taint з Lt, це означає: «Я можу толерувати вузли, де цей показник менший за мій поріг». Оскільки толерантності дозволяють планувати, под може працювати на вузлах, де значення taint більше за значення толерантності. Подумайте про це так: «Я можу працювати з вузлами, які перевищують мої мінімальні вимоги».

Ці оператори працюють з числовими значеннями taint і дозволяють планувальнику приймати складні рішення щодо розміщення на основі безперервних метрик, а не дискретних категорій.

Випадки використання та приклади

Давайте розглянемо, як розширені оператори толерантності вирішують реальні завдання планування.

Приклад 1: Захист спотових інстанцій із пороговими значеннями SLA

Багато кластерів поєднують вузли на вимогу та спотові/преемптивні вузли для оптимізації витрат. Спотові вузли забезпечують значну економію, але мають вищий рівень відмов. Ви хочете, щоб більшість робочих навантажень стандартно уникало спотових вузлів, дозволяючи при цьому певним робочим навантаженням підключатися з чіткими межами SLA.

Спочатку позначте спотові вузли з їхньою ймовірністю відмови (наприклад, 15% річний рівень відмов):

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"

Критичні робочі навантаження можуть вимагати суворих вимог до SLA:

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

Цей под буде плануватися тільки на вузлах з failure-probability менше 5 (тобто ondemand-node-1 з 2%, але не spot-node-1 з 15%). Ефект NoExecute з tolerationSeconds: 30 означає, що якщо SLA вузла погіршується (наприклад, хмарний провайдер змінює значення taint), под отримує 30 секунд для коректного завершення роботи перед примусовим виселенням.

Тим часом, відмовостійке пакетне завдання може явно вибрати спотові інстанси:

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

Це пакетне завдання допускає вузли з імовірністю відмови до 20%, тому воно може виконуватися як на вузлах на вимогу, так і на спотових вузлах, що дозволяє максимально заощадити кошти, приймаючи при цьому більш високий ризик.

Приклад 2: Розміщення робочих навантажень ШІ за рівнями GPU

Робочі навантаження ШІ та машинного навчання часто мають специфічні вимоги до апаратного забезпечення. За допомогою операторів розширеної толерантності ви можете створювати рівні вузлів GPU та забезпечувати розміщення робочих навантажень на апаратному забезпеченні з відповідною потужністю.

Позначте вузли GPU за їхнім показником обчислювальної потужності:

apiVersion: v1
kind: Node
metadata:
  name: gpu-node-a100
spec:
  taints:
  - key: "gpu-compute-score"
    value: "1000"
    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: model-training
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

Це гарантує, що под для тренування буде плануватися лише на вузлах з показником обчислювальної потужності більше 800 (наприклад, вузол A100), запобігаючи розміщенню на GPU нижчого рівня, які можуть уповільнити тренування.

Тим часом, робочі навантаження для інференсу з менш вимогливими характеристиками можуть використовувати будь-який доступний GPU:

apiVersion: v1
kind: Pod
metadata:
  name: model-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

Приклад 3: Розміщення робочого навантаження з оптимізацією витрат

Для пакетної обробки або некритичних робочих навантажень ви можете мінімізувати витрати, запускаючи їх на дешевших вузлах, навіть якщо вони мають нижчі характеристики продуктивності.

Вузли можуть бути позначені їхнім рейтингом вартості:

spec:
  taints:
  - key: "cost-per-hour"
    value: "50"
    effect: "NoSchedule"

Вразливе до вартості пакетне завдання може виражати свою толерантність до дорогих вузлів:

tolerations:
- key: "cost-per-hour"
  operator: "Lt"
  value: "100"
  effect: "NoSchedule"

Ця пакетна задача буде плануватися на вузлах, вартість яких становить менше 100 доларів за годину, але уникатиме більш дорогих вузлів. У поєднанні з пріоритетами планування Kubernetes це дозволяє реалізувати складні стратегії розподілу витрат, за якими критичні робочі навантаження отримують преміум-вузли, а пакетні робочі навантаження ефективно використовують бюджетні ресурси.

Приклад 4: Розміщення на основі продуктивності

Застосунки, що вимагають великого обсягу памʼяті, часто потребують мінімальних гарантій продуктивності диска. За допомогою операторів розширеної толерантності ви можете забезпечити дотримання цих вимог на рівні планування.

tolerations:
- key: "disk-iops"
  operator: "Gt"
  value: "3000"
  effect: "NoSchedule"

Ця толерантність гарантує, що под планується тільки на вузлах, де disk-iops перевищує 3000. Оператор Gt означає «Мені потрібні вузли, які перевищують цей мінімум».

Як використовувати цю функцію

Розширені оператори толерантності є альфа-функцією в Kubernetes v1.35. Щоб спробувати її:

1. Увімкніть функціональнe можливість у вашому API-сервері та планувальнику:

   --feature-gates=TaintTolerationComparisonOperators=true
   

2. Позначте ваші вузли числовими значеннями, що представляють метрики, релевантні для ваших потреб планування:

     kubectl taint nodes node-1 failure-probability=5:NoSchedule
     kubectl taint nodes node-2 disk-iops=5000:NoSchedule
   

3. Використовуйте нові оператори у специфікаціях ваших подів:

     spec:
       tolerations:
       - key: "failure-probability"
         operator: "Lt"
         value: "1"
         effect: "NoSchedule"
   

Що далі?

Ця альфа-версія — лише початок. Збираючи відгуки від спільноти, ми плануємо:

• Додати підтримку виразів CEL (Common Expression Language) у толерантності та спорідненості вузлів для ще більш гнучкої логіки планування, включаючи семантичні порівняння версій
• Поліпшити інтеграцію з автоматичним масштабуванням кластерів для планування потужностей з урахуванням порогових значень
• Перевести функцію в бета-версію і, зрештою, в загальну доступність із стабільністю, готовою до промислового використання

Нам особливо цікаво дізнатися про ваші випадки використання! Чи є у вас сценарії, в яких планування на основі порогових значень вирішило б проблеми? Чи є додаткові оператори або можливості, які ви хотіли б бачити?

Як долучитися

Ця функція підтримується спільнотою SIG Scheduling. Приєднуйтесь до нас, щоб долучитися до спільноти та поділитися своїми ідеями та відгуками щодо цієї функції та інших питань.

Ви можете звʼязатися з адміністраторами цієї функції за адресою:

• Slack: #sig-scheduling у Kubernetes Slack
• Список розсилки: kubernetes-sig-scheduling@googlegroups.com

З питаннями або конкретними запитаннями, повʼязаними з операторами розширеної толерантності, звертайтеся до спільноти SIG Scheduling. Чекаємо на ваші повідомлення!

Як дізнатися більше?

• Заплямованість та Толерантність для розуміння основних концепцій
• Оператори числового порівняння для деталей використання операторів Gt та Lt
• KEP-5471: Extended Toleration Operators for Threshold-Based Placement

• ←Попередня
• Наступна→