Модуль 2.8: Теорія планувальника та життєвого циклу Подів

Складність: [MEDIUM] — Висока цінність на іспиті

Час на проходження: 25-35 хвилин

Передумови: Модуль 2.5 (Керування ресурсами), Модуль 2.6 (Планування)

Що ви зможете робити

Після завершення цього модуля ви зможете:

Простежити шлях Пода через фази планувальника: фільтрація, оцінювання та прив’язка
Створити PriorityClass та передбачити поведінку витіснення
Визначити клас QoS Пода за його специфікацією ресурсів
Пояснити сигнали витіснення kubelet та типи порогових значень
Налаштувати коректне завершення роботи за допомогою PreStop hooks та PDB
Діагностувати Поди у стані Pending та неочікувані витіснення на іспиті CKA

Зміст

Чому планувальник працює саме так (фільтрація → оцінювання → прив’язка)
Як QoS, requests/limits і пріоритет впливають на розміщення та витіснення
Сигнали життєвого циклу Пода: grace-періоди, бюджети порушень, витіснення
Рішення менеджера витіснень при навантаженні на ресурси

Потік рішень планувальника

Фільтрація (Predicates): Готовність вузлів, taints/tolerations, node selector/affinity, томи (attach/mount), requests ресурсів проти allocatable.
Оцінювання (Priorities): Розподіл між доменами топології, балансування використання CPU/пам’яті, врахування м’яких переваг (preferredDuringScheduling...) та PodTopologySpread.
Прив’язка (Bind): Записує об’єкт Binding до API-сервера; потім kubelet завантажує образи та запускає контейнери.

Порада до іспиту: Якщо Под у стані Pending — перевірте події на повідомлення «0/3 nodes are available» та конкретний фільтр, що не пройшов (taints, volume attach, insufficient CPU).

Пріоритет, витіснення та PDB

Пріоритет Подів: Поди з вищим пріоритетом можуть витіснити Поди з нижчим для звільнення ресурсів. Визначається через priorityClassName.
Витіснення (Preemption): Планувальник обирає Поди-жертви на вузлах-кандидатах, витісняє їх, а потім прив’язує Под з високим пріоритетом. PDB можуть блокувати витіснення — тоді Под залишається у стані Pending.
Тристороння взаємодія: priorityClass + PodDisruptionBudget + taints/tolerations визначають, чи витіснять критичні Поди інші, чи залишаться заблокованими.

QoS та гарантії ресурсів

Guaranteed: Requests == limits для всіх контейнерів — витісняються останніми при дефіциті пам’яті.
Burstable: Requests задано, limits — необов’язково; середній пріоритет при витісненні.
BestEffort: Без requests і limits — витісняються першими.
Вплив на планування: Requests визначають bin-packing; limits — ні. Перевищення limits не блокує планування, але може призвести до throttling під час роботи.

Витіснення та навантаження на вузол

Менеджер витіснень kubelet відстежує сигнали: memory.available, nodefs.available, imagefs.available, PID pressure.
М’які та жорсткі порогові значення: М’які включають grace-період; жорсткі — негайне витіснення.
Результат: Под завершується з причиною (Evicted), не перепланується на тому ж вузлі; контролер створює його на іншому.

Ключові моменти життєвого циклу Пода

Послідовність завершення: PreStop hook (якщо є) → SIGTERM → зворотний відлік grace-періоду → SIGKILL після таймауту → відключення томів.
Grace-періоди: За замовчуванням 30 с; налаштовується через terminationGracePeriodSeconds. Для критичних сервісів поєднуйте з readiness probes, щоб вчасно припинити прийом трафіку.
Порушення роботи: Добровільні (drain, оновлення, витіснення) поважають PDB; примусові (OOMKill, навантаження на вузол) — ні. Завжди вказуйте бажану політику порушень через PDB там, де важливі SLO.