Что такое контейнеры инициализации Kubernetes и когда их следует использовать?

apiVersion: v1
kind: Pod
metadata:
  name: init-containers-pod
spec:
  containers:
    - name: app-container
      image: busybox:latest
      command: ["echo", "Started app"]
  initContainers:
    - name: first-init-container
      image: busybox:latest
      command: ["echo", "This is the first init container"]
    - name: second-init-container
      image: busybox:latest
      command: ["echo", "This is the second init container"]

Используйте Kubectl, чтобы добавить Pod в свой кластер:

$ kubectl apply -f pod.yaml
pod/init-containers-pod created

Теперь извлеките журналы, связанные с каждым из контейнеров инициализации, чтобы убедиться, что они были запущены:

$ kubectl logs init-containers-pod -c first-init-container
This is the first init container

$ kubectl logs init-containers-pod -c second-init-container
This is the second init container

Вы можете использовать большинство свойств, доступных для манифестов контейнеров Kubernetes, в поле initContainers. К ним относятся тома, порты, переменные среды и контексты безопасности.

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

Одним из ограничений контейнеров инициализации является отсутствие поддержки зондов. Вы не можете назначать поля livenessProbe, readinessProbe или startupProbe объектам-контейнерам в поле initContainers. Контейнеры инициализации — это отдельный механизм, который вы можете использовать вместо зондов, прикрепленных к контейнерам вашего основного приложения, или вместе с ними.

Общие ошибки

Есть несколько распространенных ошибок при использовании контейнеров инициализации. Вот некоторые детали, которые следует помнить:

• Init-контейнеры запускаются каждый раз при перезапуске их пода. Это означает, что ваши операции с инициализирующим контейнером должны быть идемпотентными, чтобы они могли выполняться дважды в одном и том же поде. Если модуль перезапустить, все его инициализирующие контейнеры будут выполнены снова.
• Изменения в поле initContainers модуля не поддерживаются, за одним исключением. Вы можете изменить поле image. Это приведет к перезапуску модуля и запуску новых контейнеров инициализации.
• Имена контейнеров инициализации должны быть уникальными для всех контейнеров в модуле. Сюда входят другие контейнеры инициализации и контейнеры вашего приложения. Вы увидите ошибку проверки YAML в консоли, если попытаетесь применить манифест, нарушающий это правило.
• Поды имеют условие Initialized: False при запуске контейнеров инициализации. Это видно под заголовком Условия при запуске kubectl описывает мой модуль.

Вы также можете проверить, завершились ли контейнеры инициализации пода, используя команду kubectl get:

$ kubectl get init-containers-pod
NAME                   READY     STATUS    RESTARTS    AGE
init-containers-pod    0/1       Init:1/2  0           1m

В этом случае столбец STATUS показывает, что у модуля есть два контейнера инициализации, один из которых успешно завершен. Как только все контейнеры инициализации будут завершены, Kubernetes запустит контейнеры приложений, и статус пода изменится на Running.

Когда использовать Init-контейнеры

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

Вот несколько ситуаций, когда вы можете использовать контейнеры инициализации:

• Создание файлов конфигурации из переменных среды.
• Предварительное заполнение кэшей, используемых вашим приложением.
• Миграция и заполнение экземпляра базы данных.
• Загрузка и установка подключаемых модулей приложений в том.
• Блокировка запуска приложения до тех пор, пока не будут доступны зависимости (например, базы данных или внешние API).

Еще один способ выполнить некоторые из этих задач — использовать пробу готовности или запуска. Однако есть разница в намерениях: зонды в первую очередь предназначены для передачи состояния контейнера в Kubernetes, тогда как контейнеры инициализации предназначены для выполнения действий во время инициализации пода.

Краткое содержание

Контейнеры инициализации — это способ выполнения процедур инициализации первого запуска в модуле Kubernetes. Их можно использовать для блокировки или задержки запуска контейнера приложения, пока вы ждете, пока станут доступны зависимости или завершатся сценарии начальной загрузки.

Функциональность контейнеров инициализации иногда пересекается с проверками запуска и готовности. Вы можете использовать зонд, когда действие, которое вы хотите выполнить, в основном связано с блокировкой запуска приложения до тех пор, пока не будет выполнено условие. Они полагаются на ваш скрипт, уже существующий в образе контейнера вашего приложения. Контейнер инициализации — лучший выбор, если вы хотите выполнять специальные действия, не перегружая основной образ одноразовыми утилитами.