Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість GenericWorkload для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Ви можете повʼязати Pod з PodGroup, щоб вказати, що Pod належить до групи Pods, які плануються разом. Це дозволяє планувальнику застосовувати політики на рівні групи, такі як gang scheduling, замість того, щоб розглядати кожен Pod окремо.
Коли увімкнено функцію GenericWorkload, ви можете встановити поле spec.schedulingGroup у маніфесті Pod. Це поле встановлює звʼязок із конкретним обʼєктом PodGroup у тому самому просторі імен за назвою.
apiVersion: v1
kind: Pod
metadata:
name: worker-0
namespace: some-ns
spec:
schedulingGroup:
podGroupName: training-worker-0
containers:
- name: ml-worker
image: training:v1
Поле schedulingGroup є незмінним. Після встановлення Pod не можна перемістити до іншої PodGroup.
Коли ви встановлюєте spec.schedulingGroup, планувальник шукає посилання на PodGroup і застосовує визначену в ньому політику планування:
PodGroup використовує політику basic, кожен Pod планується незалежно, використовуючи стандартну поведінку Kubernetes. Групування використовується як мітка на рівні групи.PodGroup використовує політику gang, Pod входить у життєвий цикл планування "все або нічого". Планувальник намагається розмістити принаймні minCount Pods у групі одночасно; жоден з них не привʼязується до вузлів, якщо мінімум не досягнуто.Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість CompositePodGroup для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Коли функціональну можливість CompositePodGroup увімкнено, PodGroup також може вказувати батьківський CompositePodGroup. В ієрархічному робочому навантаженні планування регулюється політиками, визначеними для всього дерева груп (такими як багаторівневе групове планування або обмеження топології).
Якщо Pod посилається на PodGroup, що ще не існує, Pod залишається в стані очікування. Аналогічно, якщо згаданий PodGroup вказує батьківський CompositePodGroup (через spec.parentCompositePodGroupName), який ще не створено, планування не починається, і Pod залишається в стані очікування, доки вся ієрархія груп не існуватиме в кластері.
Планувальник автоматично переглядає Pod, як тільки всі необхідні ресурси PodGroup та CompositePodGroup існують.