Топологічно-орієнтоване планування робочих навантажень

Топологічно-орієнтоване планування робочих навантажень (Topology-Aware Scheduling, TAS) є функцією Workload API, яка оптимізує розміщення Podʼів у межах кластера.

TAS забезпечує, щоб усі Podʼи в межах PodGroup були розміщені в одному топологічному домені, наприклад, на одному серверному стелажі або в одній зоні. Це мінімізує затримки між Podʼами та запобігає фрагментації робочого навантаження по інфраструктурі кластера.

Топологічно-орієнтоване планування з політикою gang

При застосуванні до PodGroup з політикою планування gang, TAS симулює потенційне розміщення (placement) всієї групи Pod одночасно. Це гарантує, що принаймні зазначена кількість minCount Podʼів може розміститися разом в одному топологічному домені перед виділенням ресурсів. Якщо не знайдено жодного можливого розміщення, вся PodGroup не може бути запланованою.

Цей підхід рекомендується для робочих навантажень, таких як розподілене навчання AI та ML, які строго потребують близькості для мінімізації затримок між Podʼами.

Якщо до PodGroup додаються нові Podʼи, де деякі Podʼи вже заплановані (наприклад, якщо Podʼи перестворюються), планувальник змусить всі нові Podʼи розміститися в тому ж топологічному домені, де наразі знаходяться поточні Podʼи. Якщо в цьому конкретному домені недостатньо ресурсів для нових Podʼів, вони залишаться в стані очікування — навіть якщо це означає, що на даний момент буде заплановано менше ніж minCount Podʼів.

Топологічно-орієнтоване планування з політикою basic

Використання TAS з політикою планування basic може призводити до непослідовної поведінки. Планувальник може спостерігати лише підмножину Podʼів під час входу в цикл планування PodGroup — тому можливість розміщення оцінюється лише для спостережуваних Podʼів, а не для всієї PodGroup. Щоб частково помʼякшити це обмеження, можна використовувати шлюзи планування, щоб затримати планування PodGroup до тих пір, поки всі Podʼи в PodGroup не будуть у черзі планування.

Якщо не знайдено жодного можливого розміщення для всієї PodGroup, може бути запланована лише підмножина Podʼів, і вони гарантовано відповідатимуть обмеженням планування.

Якщо до PodGroup додаються нові Podʼи, де деякі Podʼи вже заплановані, планувальник діятиме так само, як у випадку політики gang — змушуючи нові Podʼи розміститися в тому ж домені, якщо є достатньо ресурсів (у протилежному випадку нові Podʼи залишаться в стані очікування).

Налаштування API: обмеження планування

Кожна PodGroup (або PodGroupTemplate) може опціонально оголосити поле schedulingConstraints, яке інтерпретується алгоритмом планування PodGroup на основі розміщення. Якщо обмеження визначені в PodGroupTemplate, вони будуть скопійовані до вказаних PodGroup.

Починаючи з версії Kubernetes v1.36, API підтримує топологічні обмеження.

Топологічне обмеження

Щоб визначити топологічне обмеження для PodGroup, потрібно встановити key, який відповідає мітці вузла Kubernetes, що представляє цільовий топологічний домен (наприклад, стелаж або зону). Планувальник суворо забезпечує, щоб усі Podʼи в межах PodGroup були розміщені на вузлах, які мають однакове значення для цієї мітки.

Ось приклад PodGroup, налаштованої з топологічним обмеженням:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: example-podgroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

Що далі

• Дізнайтеся про політики груп Pod.
• Дізнайтеся про втулки, повʼязані з топологічно-орієнтованим плануванням
• Прочитайте про алгоритм групового планування.