Для чего используются initContainers и чем они принципиально отличаются от обычных контейнеров приложения в Pod?

Короткий ответ

initContainers запускаются последовательно до старта основных контейнеров Pod и должны полностью и успешно завершиться (exit code 0), прежде чем Kubernetes начнёт запускать обычные контейнеры; их используют для подготовительных задач — ожидания готовности зависимости, миграции данных, загрузки конфигурации или секретов перед стартом приложения.

Как это работает подробнее

в отличие от обычных контейнеров (которые запускаются параллельно и работают постоянно), initContainers выполняются строго по очереди, один за другим; если какой-то initContainer завершается с ошибкой, Kubernetes перезапускает именно его (согласно restartPolicy Pod), не переходя к следующему и не запуская основные контейнеры, пока проблема не будет решена.

Пример кода

manifest.yamlКопировать

initContainers:
  - name: wait-for-db
    image: busybox:1.36
    command: ["sh", "-c", "until nc -z db 5432; do echo waiting; sleep 2; done"]
containers:
  - name: app
    image: myapp:1.0

Что использовать на практике

• Практика. типичные примеры — init-контейнер, который ждёт доступности базы данных перед стартом приложения (until pg_isready; do sleep 1; done), или который клонирует репозиторий конфигурации во временный volume, используемый затем основным контейнером. Это позволяет не усложнять образ основного приложения логикой ожидания и подготовки, вынося её в отдельный переиспользуемый шаг.

Подводные камни

• Риски. пытаться использовать initContainer для фоновой задачи, которая должна работать параллельно с приложением — для этого нужен sidecar (обычный дополнительный контейнер), а не init; не задавать разумный таймаут ожидания зависимости в init-контейнере, из-за чего под бесконечно висит в состоянии Init:0/1 без явной ошибки, если зависимость так и не становится доступной.