Kubernetes v1.36: Як легко змінювати ресурси у призупинених Job і підвищити ефективність кластеру

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

У світі 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 значно спрощує керування пакетними задачами та ML-процесами, дозволяючи динамічно змінювати ресурси у призупинених Job і CronJob без втрати історії та метаданих. Це підвищує гнучкість і ефективність роботи з кластерами, що особливо важливо у сучасних динамічних середовищах.

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному1
LinkedIn
Ctrl + Enter
Ctrl + Enter

Тема цікава але є неточності щодо CronJob:

Не вистачає розкладу, тому воно не створюється

apiVersion: batch/v1
kind: CronJob
metadata:
  name: example-periodic-training
spec:
  # This was missing! Even if suspended, it must be defined.
  schedule: "0 0 * * *" 
  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.io/...​urces-for-suspended-jobs

P.S. В v1.36.0-gke.1379000 вже увімкнено

Підписатись на коментарі