Життєвий цикл PodGroup

PodGroup планується як єдине ціле і захищений від передчасного видалення, поки його Podʼи все ще працюють.

Володіння та життєвий цикл

PodGroups належать контролеру робочого навантаження, який їх створив (наприклад, Job), через стандартні ownerReferences. Коли обʼєкт-власник видаляється, PodGroups автоматично видаляються збирачем сміття.

Назви PodGroup повинні бути унікальними в межах простору імен і бути дійсними DNS-піддоменами.

Порядок створення

Контролери повинні створювати обʼєкти в такому порядку:

1. Workload — шаблон політики планування.
2. PodGroup — екземпляр під час виконання.
3. Pods — з spec.schedulingGroup.podGroupName, що вказує на PodGroup.

Якщо PodGroup включає podGroupTemplateRef, який вказує на Workload, що не існує (або видаляється), API-сервер відхиляє запит на створення PodGroup. Вказаний Workload повинен існувати перед створенням PodGroup.

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

Захист від видалення

PodGroup не може бути повністю видалено, поки будь-які його Podʼи все ще працюють. Спеціальний завершувач забезпечує блокування видалення, поки всі Pods, що посилаються на PodGroup, не досягнуть термінальної фази (Succeeded або Failed).

PodGroups, керовані контролером та користувачем

У більшості випадків контролери робочих навантажень (наприклад, Job) створюють PodGroups автоматично (керовані контролером). Контролер визначає podGroupName для кожного Podʼа під час створення, аналогічно тому, як DaemonSet встановлює спорідненість вузлів для кожного Podʼа.

Якщо вам потрібно більше контролю над іменуванням та життєвим циклом, ви можете безпосередньо створювати обʼєкти PodGroup та самостійно встановлювати spec.schedulingGroup.podGroupName у своїх шаблонах Podʼів (керовані користувачем). Це надає вам повний контроль над створенням та іменуванням PodGroup.

Обмеження

• Всі Podʼи в PodGroup повинні використовувати той самий .spec.schedulerName. Якщо виявлено невідповідність, планувальник відхиляє всі Podʼи в групі як такі, що не можуть бути заплановані.
• Всі Podʼи в PodGroup повинні використовувати той самий .spec.priority. Якщо виявлено невідповідність, планувальник відхиляє всі Podʼи в групі як такі, що не можуть бути заплановані.
• Всі Podʼи в PodGroup повинні використовувати той самий .spec.preemptionPolicy. Якщо виявлено невідповідність, планувальник відхиляє всі Podʼи в групі як такі, що не можуть бути заплановані.
• Поле spec.schedulingGroup у Podʼа є незмінним. Після встановлення Pod не може перейти до іншого PodGroup.
• Максимальна кількість PodGroupTemplates в одному Workload становить 8.
• Планувальник не оновлює інформацію про статус щодо поточного робочого стану PodGroup або подальших спроб планування після початкового розміщення. Отже, статус PodGroup не оновлюється, коли наявні Podʼи зазнають збою, виселяються або завершуються, або коли нововиявлені Podʼи не можуть бути заплановані.

Що далі

• Ознайомтеся з оглядом та структурою API PodGroup.
• Дізнайтеся про Workload API, який надає PodGroupTemplates.
• Дізнайтеся, як Podʼи посилаються на свій PodGroup через поле групи планування.
• Ознайомтеся з алгоритмом групового планування.
• Прочитайте політики планування PodGroup, щоб дізнатися більше про basic та gang.