Init containers: sequential setup до main

Init container — это специальный контейнер, который должен завершиться успешно (exit 0) до старта main containers Pod-а. Несколько init containers выполняются последовательно в порядке, в котором они объявлены в манифесте. Каждый следующий стартует только после успешного завершения предыдущего. Это идеальный механизм для setup-задач: дождаться зависимости, сгенерировать конфиг, накатить миграцию.

Базовый пример

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
  - name: wait-for-db
    image: busybox:1.36
    command: ['sh', '-c', 'until nc -z postgres 5432; do echo waiting for db; sleep 2; done']
  - name: run-migrations
    image: myapp/migrations:v1
    command: ['flyway', 'migrate']
  containers:
  - name: app
    image: myapp:v1

Что происходит при старте Pod:

1. kubelet стартует wait-for-db. Контейнер крутится в цикле, пингуя postgres:5432 через netcat. Когда соединение установлено — nc -z exits 0, цикл until завершается, контейнер exits 0.
2. kubelet стартует run-migrations. flyway применяет SQL миграции к базе. После успешного завершения exit 0.
3. kubelet стартует main контейнер app. Только теперь app получает CPU.

Если на любом шаге exit code не 0 — kubelet перезапускает init container согласно restartPolicy Pod (по умолчанию Always). Pod висит в фазе Init:N/M или Init:Error.

5 use cases для init containers

Sequential execution: ordering и failures

Init containers выполняются строго последовательно в порядке объявления. Это критически важно:

spec:
  initContainers:
  - name: step-1            # стартует первым
    image: busybox
    command: ['echo', 'one']
  - name: step-2            # стартует только после step-1 exit 0
    image: busybox
    command: ['echo', 'two']
  - name: step-3            # стартует только после step-2 exit 0
    image: busybox
    command: ['echo', 'three']

Если step-2 падает с ошибкой:

• step-3 не стартует;
• Pod в фазе Init:Error или Init:CrashLoopBackOff;
• kubelet перезапускает только step-2, не весь Pod;
• step-1 повторно не выполняется (он уже Completed).

Killer момент: resource calculation для Pod

Init containers и main containers имеют разные модели расчёта эффективных ресурсов для scheduling. Поскольку init containers выполняются по очереди, в каждый момент времени запущен только один из них. Поэтому scheduler берёт максимум по init containers, а не сумму.

Effective Pod request для каждого resource (CPU, memory) считается как:

effective = max(
  max(initContainer_i.request),    // максимум по init containers
  sum(container_j.request)         // сумма по main containers (они работают параллельно)
)

Probes: init containers их НЕ имеют

Init containers не могут использовать probes (livenessProbe, readinessProbe, startupProbe). Это by design:

• init container — это короткоживущий процесс, который должен просто завершиться с exit 0;
• если init упадёт — kubelet рестартанёт его по restartPolicy;
• нет понятия «init container Ready», есть только «exited 0 или нет».

Если ваш init container — это long-running процесс, который не завершается (например, веб-сервер), вы делаете что-то не то. Это либо main container, либо native sidecar (init container с restartPolicy: Always, GA v1.33).

Логи init containers

Логи init containers видны через специальный флаг -c:

# Логи всех контейнеров Pod (только main по умолчанию)
kubectl logs my-pod

# Логи конкретного контейнера, включая init
kubectl logs my-pod -c wait-for-db
kubectl logs my-pod -c run-migrations

# Список контейнеров в Pod (с типом)
kubectl get pod my-pod -o jsonpath='{.spec.initContainers[*].name}'
kubectl describe pod my-pod | grep -A2 'Init Containers'

После того как init container завершился, его логи доступны до удаления Pod через kubectl logs -c <name>. Это критично для отладки: если миграция failed — вы хотите видеть её output до того, как Pod пересоздан.

Init containers vs sidecar

Один и тот же манифест initContainers может содержать оба типа — обычные init без restartPolicy и sidecars с restartPolicy: Always. kubelet разруливает по полю restartPolicy.