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.
Workload складається з двох полів: списку PodGroupTemplates та необовʼязкового посилання на контролер. Вся специфікація Workload є незмінною після створення: ви не можете змінювати наявні шаблони, додавати нові шаблони або видаляти шаблони з podGroupTemplates.
Список spec.podGroupTemplates визначає окремі компоненти вашого робочого навантаження. Наприклад, завдання машинного навчання може мати шаблон driver та шаблон worker.
Кожен елемент у podGroupTemplates повинен мати:
name, яке буде використовуватися для посилання на шаблон у spec.podGroupTemplateRef обʼєкта PodGroup.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.
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.