Workload API

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.35 [alpha](стандартно вимкнено)

Ресурс Workload API визначає вимоги до планування та структуру багатоподового застосунку. У той час як контролери робочого навантаження, такі як Job, керують станом виконання застосунку, Workload визначає, як слід планувати групи Pods. Контролер Job є єдиним вбудованим контролером, який створює обʼєкти PodGroup з PodGroupTemplates ресурсу Workload під час виконання.

Що таке робоче навантаження?

Ресурс Workload API є частиною групи API scheduling.k8s.io/v1alpha2 (і ваш кластер повинен мати цю групу API увімкнену, а також функціональну можливість GenericWorkload, перш ніж ви зможете скористатися цим API).

Workload є статичним, довгоживучим шаблоном політики. Він визначає, які політики планування слід застосовувати до груп Podʼів, але самостійно не відстежує стан виконання. Стан виконання планування підтримується обʼєктами PodGroup, які контролери створюють з PodGroupTemplates ресурсу Workload.

Структура API

Workload складається з двох полів: списку PodGroupTemplates та необовʼязкового посилання на контролер. Вся специфікація Workload є незмінною після створення: ви не можете змінювати наявні шаблони, додавати нові шаблони або видаляти шаблони з podGroupTemplates.

PodGroupTemplates

Список spec.podGroupTemplates визначає окремі компоненти вашого робочого навантаження. Наприклад, завдання машинного навчання може мати шаблон driver та шаблон worker.

Кожен елемент у podGroupTemplates повинен мати:

  1. Унікальне поле name, яке буде використовуватися для посилання на шаблон у spec.podGroupTemplateRef обʼєкта PodGroup.
  2. Політику планування (basic або gang).

Якщо увімкнено функціональну можливість WorkloadAwarePreemption, кожен елемент у podGroups також може мати пріоритет та режим розладу.

Максимальна кількість PodGroupTemplates в одному Workload становить 8.

apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  controllerRef:
    apiGroup: batch
    kind: Job
    name: training-job
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        # gang може бути запланована тільки в тому випадку, якщо одночасно можуть працювати 4 пода.
        minCount: 4
    priorityClassName: high-priority # Застосовується лише з функціональною можливістю WorkloadAwarePreemption
    disruptionMode: PodGroup # Застосовується лише з функціональною можливістю WorkloadAwarePreemption

Коли контролер робочого навантаження створює PodGroup з одного з цих шаблонів, він копіює schedulingPolicy у власну специфікацію PodGroup. Зміни в Workload впливають лише на новостворені PodGroups, а не на наявні.

Посилання на обʼєкт керування робочим навантаженням

Поле controllerRef звʼязує Workload з конкретним обʼєктом вищого рівня, що визначає застосунок, наприклад Job або власний CRD. Це корисно для спостереження та інструментів. Ці дані не використовуються для планування або управління Workload.

Gang scheduling with Jobs

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.36 [alpha](стандартно вимкнено)

Коли функціональна можливість WorkloadWithJob увімкнена, контролер Job автоматично створює обʼєкти Workload та PodGroup для паралельних індексованих Job, де .spec.parallelism дорівнює .spec.completions. Політика gang встановлює minCount рівним паралелізму Job, тому всі Podʼи повинні бути заплановані одночасно, перш ніж будь-який з них буде привʼязаний до вузлів.

Це вбудований шлях для використання групового планування з використанням завдань (Jobs). Вам не потрібно самостійно створювати об’єкти Workload або PodGroup, оскільки контролер завдань (Job controller) робить це автоматично. Інші контролери робочих навантажень (наприклад, JobSet) можуть самостійно керувати своїми об’єктами Workload та PodGroup.

Що далі


Востаннє змінено May 15, 2026 at 6:30 PM PST: [uk] Ukrainian translation (all-in-one) (3f52b3b106)