Как правильно высвободить ресурсы kubernetes для работы kubernetes, которая не может получить изображение?

Question

Контекст

У нас давно выполняются задания kubernetes на основе докеров. Контейнерам требуются ресурсы (например, 15 ГБ памяти, 2 процессора), и мы используем autoscaler для масштабирования новых рабочих узлов по запросу.

Сценарий

Пользователи могут выбрать версиюобраз докера, который будет использоваться для задания, например, 1.0.0, 1.1.0, или даже хеш коммита кода, из которого изображение было построено в тестовой среде.

Когда мы оставляем тег докера каксвободный текст, пользователь может ввести несуществующий тег докера. Из-за этого модуль работы находится в состоянии ImagePullBackOff. Модуль находится в этом состоянии и сохраняет ресурсы заблокированными, чтобы их нельзя было использовать в других заданиях.

Вопрос

Какое правильное решение может бытьприменяется в самом kubernetes, для немедленного или хотя бы быстрого отказа модуля при сбое извлечения из-за несуществующего образа докера: tag?

Возможности

Я посмотрел наbackofflimit. Я установил его на 0, но это не сбой или удалить работу. Ресурсы, конечно, тоже сохраняются.

Может быть, они могут быть убиты заданием cron. Не уверен, как это сделать.

В идеале ресурсы не следует даже выделять для работы с несуществующим образом докера. Но я не уверен, есть ли возможность легко добиться этого.

Любой другой?

Answer 1

Когда задание завершается, больше не создается никаких модулей, но они также не удаляются.

По умолчанию задание будет работать непрерывно, пока не произойдет сбой модуля (restartPolicy = Never) или контейнер не выйдет вошибка (restartPolicy = OnFailure), после чего Задание откладывается до .spec.backoffLimit , описанного выше. По достижении .spec.backoffLimit задание будет помечено как сбойное, а все запущенные модули будут прерваны.

Другой способ завершить задание - установить активный крайний срок. Сделайте это, установив в поле .spec.activeDeadlineSeconds задания заданное количество секунд. activeDeadlineSeconds применяется к продолжительности работы независимо от того, сколько модулей создано. Как только задание достигает activeDeadlineSeconds, все его работающие блоки прекращают работу, и статус задания становится типом: Сбой по причине: DeadlineExceeded.

Обратите внимание, что .spec.activeDeadlineSeconds задания 1011 * имеет приоритет над заданием. его .spec.backoffLimit . Таким образом, задание, которое повторяет один или несколько отказавших модулей, не будет развертывать дополнительные модули, как только достигнет предела времени, указанного в activeDeadlineSeconds , даже если backoffLimit еще не достигнут.

Здесьдополнительная информация: заданий .

Вы также можете настроить concurrencyPolicy из cronjob на Заменить и заменить текущийвыполнение задания с новым заданием.

Вот пример:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/2 * * * *"
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster && sleep 420
          restartPolicy: Never

Настройка Замена значением для concurrencyPolicy Флаг означает, что пришло времядля нового запуска задания, а предыдущий запуск еще не завершен, задание cron заменяет запущенный в данный момент запуск задания новым.

Независимо от этого решения ваша проблема заключается в неправильных изображениях, поэтому автоматическое удалениестручки или рабочие места не решают проблему. Потому что, если вы ничего не измените в определении заданий и изображений, ваши модули будут по-прежнему не работать после повторного создания задания.

Вот пример устранения неполадок для Error: ImagePullBackOff Normal BackOff: ImagePullBackOff .

Answer 2

После просмотра вашего проекта я бы порекомендовал добавить InitContainer к спецификации задания, чтобы проверить наличие образов докера с данным тегом.

Если изображение с тегом не существует в реестре, InitContainer может сообщить об ошибке и завершить работу модуля задания, выйдя с ненулевым кодом выхода.

После этого модуль задания будет перезапущен . После определенного количества попыток Иов получит Failed состояние. При настройке параметра .spec.ttlSecondsAfterFinished сбойные задания можно удалить.

Если контейнер инициализации модуля не работает, Kubernetes многократно перезапускает модуль, пока контейнер инициализации не будет выполнен успешно. Тем не менее, если Pod имеет RestartPolicy of Never, Kubernetes не перезапускает Pod.

Если изображение существует, сценарий InitContainer завершается с нулевым кодом выхода, и основной образ контейнера задания будет извлечени контейнер запускается.

Answer 3

Вы можете использовать failedJobsHistoryLimit для невыполненных заданий и successfulJobsHistoryLimit для успешных заданий

С этими двумя параметрами вы можете сохранить историю ваших заданий в чистоте

.spec.backoffLimit, чтобы указать числоповторных попыток, прежде чем считать работу неудачной.