Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість GenericWorkload для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
PodGroup — це обʼєкт середовища виконання, який представляє групу Podʼів, запланованих для роботи як єдине ціле. У той час як Workload API визначає шаблони політик планування, PodGroups є їхніми аналогами в середовищі виконання, які містять як саму політику, так і стан планування для конкретного екземпляра цієї групи.
Ресурс API PodGroup є частиною групи API scheduling.k8s.io/v1beta1 і ваш кластер повинен мати цю групу API увімкненою, а також функціональну можливість GenericWorkload, перш ніж ви зможете використовувати цей API.
PodGroup — це самостійна одиниця планування. Вона визначає групу Podʼів, які повинні бути заплановані разом, містить політику планування, що регулює розміщення, і фіксує стан виконання цього рішення про планування.
PodGroup складається з розділів spec, який визначає бажану поведінку планування, та status, який відображає поточний стан планування.
Кожна PodGroup має політику планування (basic або gang) у spec.schedulingPolicy. Коли контролер робочого навантаження створює PodGroup, ця політика копіюється з PodGroupTemplate робочого навантаження під час створення. Для автономних PodGroup ви встановлюєте політику безпосередньо.
spec:
schedulingPolicy:
gang:
minCount: 4
Необовʼязкове поле spec.podGroupTemplateRef повʼязує PodGroup з PodGroupTemplate у робочому навантаженні, з якого вона була створена. Це корисно для спостереження та інструментів.
spec:
podGroupTemplateRef:
workload:
workloadName: training-policy
podGroupTemplateName: worker
Кожна PodGroup також може визначати власні spec.priority, spec.preemptionPolicy та spec.disruptionMode. Пріоритет і політика витіснення встановлюються за допомогою поля spec.priorityClassName, яке вказує на ресурс PriorityClass. Див. Розлад та пріоритет Pod Group для детального опису цих полів.
Коли контролер робочого навантаження створює PodGroup, ці поля копіюються з PodGroupTemplate робочого навантаження під час створення. Для автономних PodGroup ви встановлюєте поля безпосередньо.
spec:
disruptionMode:
all: {}
priorityClassName: high-priority
Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість DRAWorkloadResourceClaims для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Пристрої доступні через Динамічне виділення ресурсів (DRA) можуть бути запитані PodGroup через поле spec.resourceClaims:
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
name: training-group
namespace: some-ns
spec:
...
resourceClaims:
- name: pg-claim
resourceClaimName: my-pg-claim
- name: pg-claim-template
resourceClaimTemplateName: my-pg-template
ResourceClaims повʼязані з PodGroups можуть бути спільно використані всіма Podʼами, що належать до групи. Замість того, щоб мати посилання на кожен окремий Pod у status.reservedFor ResourceClaim, достатньо посилання на PodGroup, і будь-яка кількість Podʼів у тій самій PodGroup може спільно використовувати ResourceClaim. ResourceClaims також можуть бути створені з ResourceClaimTemplates для кожної PodGroup, що дозволяє пристроям, виділеним для кожного створеного ResourceClaim, бути спільно використаними Podʼами в кожній PodGroup.
За докладною інформацією та більш повним прикладом звертайтесь до документації DRA.
Планувальник оновлює status.conditions, щоб повідомити, чи група була успішно запланована. Основною умовою є PodGroupInitiallyScheduled, яка є True, коли всі необхідні Podʼи були розміщені, і False, коли планування не вдається.
PodGroupInitiallyScheduled відображає лише початкове рішення планувальника. Планувальник не оновлює його, якщо Podʼи пізніше зазнають невдачі або будуть виселені. Детальніше див. у розділі Обмеження.Див. сторінку Життєвий цикл PodGroup для повного списку станів та причин.
Ресурс API PodGroup є частиною групи API scheduling.k8s.io/v1alpha2 (і ваш кластер повинен мати цю групу API увімкненою, а також функціональну можливість GenericWorkload, перш ніж ви зможете використовувати цей API).
Наступний маніфест створює PodGroup з політикою планування gang, яка вимагає, щоб щонайменше 4 Podʼа могли бути заплановані одночасно:
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
name: training-worker-0
namespace: default
spec:
schedulingPolicy:
gang:
minCount: 4
Ви можете переглянути PodGroups у вашому кластері:
kubectl get podgroups
Щоб побачити повний стан, включаючи стани планування:
kubectl describe podgroup training-worker-0
Взаємозвʼязок між контролерами, Workloads, PodGroups та Podʼами слідує такому шаблону:
spec.schedulingGroup.podGroupName.Контролер Job є єдиним вбудованим контролером Workload, який наразі слідує цьому шаблону. Власні контролери можуть реалізувати той самий потік для своїх власних типів Workload.
apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
name: training-policy
spec:
podGroupTemplates:
- name: worker
schedulingPolicy:
gang:
minCount: 4
---
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
name: training-worker-0
spec:
podGroupTemplateRef:
workload:
workloadName: training-policy
podGroupTemplateName: worker
schedulingPolicy:
gang:
minCount: 4
---
apiVersion: v1
kind: Pod
metadata:
name: worker-0
spec:
schedulingGroup:
podGroupName: training-worker-0
containers:
- name: ml-worker
image: training:v1
Workload виступає як довготривале визначення політики, тоді як PodGroups обробляють тимчасовий стан виконання для кожного екземпляра. Це розділення означає, що оновлення стану для окремих PodGroups не конфліктує з спільним обʼєктом Workload.
Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість CompositePodGroup для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Коли функціональну можливість CompositePodGroup увімкнено, PodGroup може діяти як кінцевий вузол у багаторівневій ієрархії груп, що складається з PodGroups та CompositePodGroups. PodGroup може вказати свою батьківську групу за допомогою поля spec.parentCompositePodGroupName. Організація робочого навантаження в ієрархію груп може використовуватися для вираження багаторівневих вимог групового планування, багаторівневих обмежень топології та спільного розподілу розладів між частинами робочого навантаження.
Для отримання додаткових відомостей про ієрархічні структури груп та багаторівневе групове планування див. огляд CompositePodGroup API.
PodGroup, який вказує spec.parentCompositePodGroupName, також повинен вказувати spec.workloadRef, повʼязуючи PodGroup з його шаблоном у Workload. Автономним обʼєктам PodGroup (створеним без spec.workloadRef) не дозволяється вказувати батьківський CompositePodGroup.