Група планування

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

Ви можете повʼязати 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 у групі одночасно; жоден з них не прив'язується до вузлів, якщо мінімум не досягнуто.

Відсутнє посилання на PodGroup

Якщо Pod посилається на PodGroup, що ще не існує, Pod залишається в стані очікування. Планувальник автоматично переглядає Pod, як тільки PodGroup створено.

Це застосовується незалежно від того, чи політика в кінцевому підсумку є basic або gang, оскільки планувальнику потрібен PodGroup, щоб визначити політику.

Що далі

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