Планування великих робочих навантажень є набагато складнішою і делікатнішою операцією, ніж планування одного Podʼа, оскільки часто вимагає врахування всіх Podʼів разом, а не планування кожного окремо. Наприклад, при плануванні пакетної задачі машинного навчання часто потрібно стратегічно розмістити кожного виконавця, наприклад, на одній стійці, щоб зробити весь процес максимально ефективним. Водночас Podʼи, що входять до такого робочого навантаження, дуже часто є ідентичними з точки зору планування, що кардинально змінює вигляд цього процесу.
Існує багато спеціальних планувальників, пристосованих для ефективного планування робочих навантажень, але з огляду на те, наскільки поширеним і важливим є планування робочих навантажень для користувачів Kubernetes, особливо в епоху штучного інтелекту з дедалі більшою кількістю випадків використання, настав час зробити робочі навантаження першочерговим завданням для kube-scheduler і підтримувати їх нативно.
В останньому випуску Kubernetes 1.35 було представлено першу частину вдосконалень планування з урахуванням навантаження. Вони є частиною ширших зусиль, спрямованих на поліпшення планування та управління навантаженнями. Ці зусилля охоплюватимуть багато SIG та версій і мають поступово розширювати можливості системи для досягнення головної мети, якою є безперебійне планування та управління робочими навантаженнями в Kubernetes, включаючи, але не обмежуючись, випередженням та автоматичним масштабуванням.
Kubernetes v1.35 представляє Workload API, який можна використовувати для опису бажаного вигляду, а також вимог до планування робочого навантаження. Він постачається з початковою реалізацією планування груп, яка наказує kube-scheduler планувати групи Podʼів за принципом все або нічого. Нарешті, ми вдосконалили планування ідентичних Podʼів (які зазвичай утворюють групи) для прискорення процесу завдяки функції ситуативного пакетування.
Новий ресурс Workload API є частиною scheduling.k8s.io/v1alpha1 API group. Цей ресурс діє як структуроване, машиночитане визначення вимог до планування застосунку з декількома Podʼами. У той час як робочі навантаження, орієнтовані на користувача, такі як Jobs, визначають, що потрібно запустити, ресурс Workload визначає, як слід планувати групу Podʼів і як слід керувати її розміщенням протягом усього життєвого циклу.
Workload дозволяє визначити групу Podʼів і застосувати до них політику планування. Ось як виглядає конфігурація планування групи. Ви можете визначити podGroup з назвою workers і застосувати політику gang з minCount, що дорівнює 4.
apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
name: training-job-workload
namespace: some-ns
spec:
podGroups:
- name: workers
policy:
gang:
# Група планується лише якщо одночасно можуть працювати 4 Podʼи
minCount: 4
Коли ви створюєте свої Podʼи, ви повʼязуєте їх із цим робочим навантаженням за допомогою нового поля workloadRef:
apiVersion: v1
kind: Pod
metadata:
name: worker-0
namespace: some-ns
spec:
workloadRef:
name: training-job-workload
podGroup: workers
...
Політика gang забезпечує розміщення за принципом «все або нічого». Без групового планування завдання може бути заплановано частково, споживаючи ресурси без можливості виконання, що призводить до марнування ресурсів і потенційних тупикових ситуацій.
Коли ви створюєте Podʼи, які є частиною групи Podʼів із груповим плануванням, втулок GangScheduling планувальника управляє життєвим циклом незалежно для кожної групи Podʼів (або ключа репліки):
Коли ви створюєте свої Podʼи (або контролер створює їх для вас), планувальник блокує їх планування, доки:
minCount.Коли зʼявляється достатня кількість Podʼів, планувальник намагається їх розмістити. Однак замість того, щоб відразу привʼязувати їх до вузлів, Podʼи чекають на воротах Permit.
Планувальник перевіряє, чи знайшов він дійсні призначення для всієї групи (принаймні minCount).
Хочемо зазначити, що хоча це перша реалізація, проєкт Kubernetes має твердий намір вдосконалити та розширити алгоритм групового планування в майбутніх версіях. Серед переваг, які ми сподіваємося досягти, — фаза планування за один цикл для всієї групи, витіснення на рівні робочого навантаження та інше, що наближає нас до нашої головної мети.
На додачу до явного групового планування, у версії 1.35 запроваджено ситуативну пакетну обробку. Це бета-функція, яка покращує затримку планування для ідентичних Podʼів.
На відміну від групового планування, ця функція не вимагає Workload API або явного погодження з боку користувача. Вона працює ситуативно в рамках планувальника, ідентифікуючи Podʼи, які мають однакові вимоги до планування (образи контейнерів, запити на ресурси, спорідненість тощо). Коли планувальник обробляє Pod, він може повторно використовувати розрахунки здійсненності для наступних однакових Podʼів у черзі, що значно прискорює процес.
Більшість користувачів отримають переваги від цієї оптимізації автоматично, без будь-яких спеціальних дій, за умови, що їх Podʼи відповідають наступним критеріям.
Ситуативне пакетування працює за певних умов. Усі поля, які використовує kube-scheduler для пошуку розміщення, повинні бути ідентичними між Podʼами. Крім того, використання деяких функцій вимикає механізм пакетування для цих Podʼів, щоб забезпечити правильність.
Зверніть увагу, що вам може знадобитися переглянути конфігурацію kube-scheduler, щоб переконатися, що вона не вимикає пакетну обробку для ваших робочих навантажень.
Більш детальну інформацію про обмеження дивіться в документації.
Проєкт має амбітну мету — забезпечити планування з урахуванням навантаження. Ці нові API та вдосконалення планування — лише перші кроки. У найближчому майбутньому планується вирішити такі завдання:
І багато іншого. Пріоритетність і порядок реалізації цих пріоритетних напрямків можуть змінюватися. Слідкуйте за подальшими оновленнями.
Щоб випробувати вдосконалення планування з урахуванням навантаження:
GenericWorkload на kube-apiserver і kube-scheduler та переконайтеся, що scheduling.k8s.io/v1alpha1 API group увімкнено.GangScheduling на kube-scheduler (потрібно увімкнути Workload API).OpportunisticBatching на kube-scheduler, якщо потрібно.Ми рекомендуємо вам спробувати планування з урахуванням навантаження у ваших тестових кластерах і поділитися своїм досвідом, щоб допомогти сформувати майбутнє планування Kubernetes. Ви можете надіслати свої відгуки: