Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість CompositePodGroup для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
CompositePodGroup — це обʼєкт середовища виконання, який представляє некінцевий вузол у багаторівневій ієрархії робочого навантаження. У той час як Workload API визначає статичні шаблони політик планування, обʼєкти CompositePodGroup та PodGroup є їхніми аналогами в середовищі виконання, які несуть політики та посилання на ієрархію для конкретного екземпляра робочого навантаження.
Ресурс API CompositePodGroup є частиною групи API scheduling.k8s.io/v1alpha3. Ваш кластер повинен мати цю групу API увімкненою, а також функціональну можливість CompositePodGroup, перш ніж ви зможете використовувати цей API.
CompositePodGroup представляє групування дочірніх груп (які можуть бути обʼєктами CompositePodGroup або PodGroup). Він несе політики планування, режими розладу, налаштування пріоритету та необовʼязкові топологічні обмеження, які застосовуються колективно до його дочірніх груп.
CompositePodGroup складається з розділу spec, який визначає бажану поведінку планування для його дочірніх груп, та підресурсу status.
Кожен CompositePodGroup несе політику планування (basic або gang) у spec.schedulingPolicy. Коли контролер робочого навантаження створює CompositePodGroup, ця політика копіюється з CompositePodGroupTemplate робочого навантаження Workload під час створення.
Для політики gang на CompositePodGroup поле minGroupCount визначає мінімальну кількість дочірніх груп, які повинні бути заплановані одночасно:
spec:
schedulingPolicy:
gang:
minGroupCount: 2
Некореневі ресурси CompositePodGroup вказують свою батьківську групу за допомогою spec.parentCompositePodGroupName. Кореневі обʼєкти CompositePodGroup залишають це поле невстановленим.
spec:
parentCompositePodGroupName: root-group-0
Поле spec.workloadRef повʼязує CompositePodGroup з CompositePodGroupTemplate в обʼєкті Workload, з якого він був створений.
spec:
workloadRef:
workloadName: hierarchical-workload
templateName: replica-group
Схема API CompositePodGroup включає підресурс status. В альфа-версії поле status присутнє в типі API, але kube-scheduler не оновлює та не заповнює умови стану для обʼєктів CompositePodGroup. Відстеження стану для складових груп буде реалізовано в майбутніх випусках.
Контролери робочого навантаження створюють обʼєкти CompositePodGroup автоматично з шаблонів Workload під час виконання.
Наступний маніфест створює кореневий CompositePodGroup з політикою планування gang, яка вимагає, щоб щонайменше 2 дочірні групи могли бути заплановані одночасно:
apiVersion: scheduling.k8s.io/v1alpha3
kind: CompositePodGroup
metadata:
name: root-group-0
namespace: default
spec:
workloadRef:
workloadName: hierarchical-workload
templateName: root
schedulingPolicy:
gang:
minGroupCount: 2
Ви можете переглянути ресурси CompositePodGroup у вашому кластері:
kubectl get compositepodgroups
Щоб переглянути деталі конкретної складової групи:
kubectl describe compositepodgroup root-group-0
Взаємозвʼязок між контролерами, Workloads, CompositePodGroups, PodGroups та Podʼами слідує такому шаблону:
Workload, який визначає дерево CompositePodGroupTemplates та кінцевих PodGroupTemplates.CompositePodGroup, дочірні обʼєкти CompositePodGroup та кінцеві обʼєкти PodGroup у порядку зверху вниз.Pods, які посилаються на свій кінцевий PodGroup через spec.schedulingGroup.podGroupName.Наступний приклад ілюструє повну ієрархію маніфестів для дворівневого робочого навантаження:
apiVersion: scheduling.k8s.io/v1alpha3
kind: Workload
metadata:
name: hierarchical-workload
namespace: default
spec:
compositePodGroupTemplates:
- name: root
schedulingPolicy:
gang:
minGroupCount: 2
podGroupTemplates:
- name: workers-a
schedulingPolicy:
gang:
minCount: 4
- name: workers-b
schedulingPolicy:
gang:
minCount: 4
---
apiVersion: scheduling.k8s.io/v1alpha3
kind: CompositePodGroup
metadata:
name: root-group-0
namespace: default
spec:
workloadRef:
workloadName: hierarchical-workload
templateName: root
schedulingPolicy:
gang:
minGroupCount: 2
---
apiVersion: scheduling.k8s.io/v1alpha3
kind: PodGroup
metadata:
name: workers-a-0
namespace: default
spec:
parentCompositePodGroupName: root-group-0
workloadRef:
workloadName: hierarchical-workload
templateName: workers-a
schedulingPolicy:
gang:
minCount: 4
---
apiVersion: scheduling.k8s.io/v1alpha3
kind: PodGroup
metadata:
name: workers-b-0
namespace: default
spec:
parentCompositePodGroupName: root-group-0
workloadRef:
workloadName: hierarchical-workload
templateName: workers-b
schedulingPolicy:
gang:
minCount: 4
---
apiVersion: v1
kind: Pod
metadata:
name: worker-a-0
namespace: default
spec:
schedulingGroup:
podGroupName: workers-a-0
containers:
- name: worker
image: registry.k8s.io/pause:3.9
Workload виступає як довготривалий шаблон політики, тоді як ресурси CompositePodGroup та PodGroup обробляють стан планування під час виконання для кожного екземпляра.