Kubernetes v1.36: Як легко змінювати ресурси у призупинених Job і підвищити ефективність кластеру
У світі Kubernetes постійно з’являються нові функції, які роблять роботу з кластерами більш ефективною та зручною. Однією з таких інновацій у версії v1.36 стала можливість змінювати ресурси контейнерів у Job, які перебувають у стані призупинення. Ця функція відкриває нові горизонти для адміністраторів і розробників, які працюють із пакетними задачами та машинним навчанням.
Що таке призупинені Job і чому це важливо
Job у Kubernetes — це об’єкт, який відповідає за запуск одноразових задач. Іноді виникає потреба призупинити виконання Job, наприклад, щоб відкласти запуск або змінити параметри. Раніше, щоб змінити ресурси, доводилося видаляти Job і створювати його заново, що призводило до втрати статусу та історії.
З появою можливості змінювати ресурси у призупинених Job це стало набагато простіше і безпечніше. Тепер можна призупинити Job, відкоригувати ресурси, а потім відновити його виконання без втрати важливої інформації.
Основні можливості Kubernetes v1.36 у цій сфері
- Зміна ресурсів (CPU, пам’ять, GPU та інші) у Job зі статусом
suspend: true. - Підтримка зміни ресурсів у призупинених CronJob.
- Збереження історії виконання та метаданих при зміні ресурсів.
Як це працює на практиці
Зміни ресурсів дозволені лише для Job, які мають прапорець suspend: true і не мають активних подів (status.active == 0). Це гарантує, що зміни не вплинуть на поточне виконання.
Важливо дотримуватися стандартних правил Kubernetes щодо ресурсів: ліміти не можуть бути меншими за запити, а розширені ресурси мають задаватися цілими числами.
Приклад Job з призупиненням і зміною ресурсів
apiVersion: batch/v1 kind: Job metadata: name: example-training-job spec: suspend: true template: spec: containers: - name: trainer image: example-registry/training:latest resources: requests: cpu: "4" memory: "16Gi" example-hardware-vendor.com/gpu: "2" limits: cpu: "4" memory: "16Gi" example-hardware-vendor.com/gpu: "2" restartPolicy: Never
Після внесення змін у ресурси потрібно зняти прапорець suspend, щоб Job почав виконуватися з оновленими параметрами.
Важливі нюанси
- Якщо Job вже запускався, слід дочекатися завершення всіх активних подів (
status.active == 0), інакше зміни не будуть застосовані. - Для Job, де можливі падіння подів, рекомендується використовувати
podReplacementPolicy: Failed, щоб уникнути одночасного запуску кількох подів. - Dynamic Resource Allocation (DRA) наразі не підтримує зміну
resourceClaimTemplatesу призупинених Job, тому їх потрібно пересоздавати окремо.
Підтримка CronJob
У Kubernetes v1.36 також додано можливість змінювати ресурси у призупинених CronJob. Для цього потрібно встановити suspend: true перед внесенням змін.
Приклад CronJob
apiVersion: batch/v1 kind: CronJob metadata: name: example-periodic-training spec: suspend: true jobTemplate: spec: template: spec: containers: - name: trainer image: example-registry/training:latest resources: requests: cpu: "2" memory: "8Gi" limits: cpu: "2" memory: "8Gi" restartPolicy: Never
Висновки
Нова функція Kubernetes v1.36 значно спрощує керування пакетними задачами та
1 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарівТема цікава але є неточності щодо CronJob:
Не вистачає розкладу, тому воно не створюється
По друге, ліміти/реквести редагуються для крон джоби незалежно від саспенд статусу.kubernetes.io/...urces-for-suspended-jobs
P.S. В v1.36.0-gke.1379000 вже увімкнено