При запуске пода основной контейнер зависит от подготовительного шага. Как оркестратор гарантирует, что этот шаг завершится до запуска основного контейнера?
Для этого используются init-контейнеры: оркестратор запускает их последовательно и не запускает обычные контейнеры пода, пока каждый init-контейнер не завершится успешно. При ошибке init-контейнер перезапускается, поэтому под остаётся в состоянии ожидания, а не начинает обслуживать запросы в неподготовленном состоянии.
Контейнеры изолируют процессы, но сами по себе не задают порядок их запуска и не решают зависимости между компонентами. На практике приложению часто требуется подготовить файловую систему, получить динамическую конфигурацию, дождаться доступности определённого условия или выполнить проверку перед стартом.
Init-контейнеры отделяют одноразовую подготовку от долгоживущего процесса приложения. Это надёжнее, чем помещать подготовительные действия в основной контейнер и пытаться определить готовность приложения только проверками доступности.
Если основной контейнер запустится до подготовки, он может прочитать неполную конфигурацию, обратиться к ещё не созданному файлу или начать принимать запросы до выполнения обязательной проверки. Простое добавление задержки ненадёжно: длительность подготовки меняется, а фиксированное ожидание не подтверждает успешный результат.
Неверное решение также может привести к циклу перезапусков, частично выполненным миграциям или к тому, что балансировщик направит трафик на формально запущенный, но фактически неготовый экземпляр.
В спецификации пода init-контейнеры задаются отдельно от обычных контейнеров. Они выполняются в указанном порядке; следующий запускается только после успешного завершения предыдущего. Пока последовательность не завершена, обычные контейнеры не считаются запущенными для нормальной работы пода.
Init-контейнер обычно выполняет подготовку в общем томе, проверяет внешнее условие или генерирует локальные файлы конфигурации. После завершения его процесс не должен продолжать работу: длительный процесс для такой задачи следует размещать в обычном контейнере или, если нужна отдельная модель жизненного цикла, использовать другой механизм.
При ненулевом коде завершения оркестратор рассматривает шаг как неуспешный и пытается выполнить его снова. Поэтому операция должна быть идемпотентной: повторный запуск не должен повреждать состояние или давать другой неконтролируемый результат. Сетевой доступ и переменные окружения init-контейнера могут отличаться по содержанию от обычного контейнера, поэтому зависимость от конкретной сетевой готовности нужно проверять явно.
Init-контейнер не заменяет readiness-пробу. Он отвечает за завершённую подготовку до запуска приложения, а readiness определяет, можно ли направлять трафик уже работающему контейнеру. Liveness-проба также имеет другую цель: обнаруживать зависание работающего процесса, а не управлять первоначальным порядком запуска.
Есть важное ограничение для миграций базы данных. Если несколько реплик запускают один и тот же init-контейнер, они могут одновременно выполнять миграцию. Для сложных или конкурентно небезопасных изменений лучше использовать отдельный управляемый этап релиза, блокировки миграций и совместимый переходный формат схемы.
Сервис при старте должен получить сертификат из секретного хранилища и проверить наличие обязательной конфигурации. Рассматривались три варианта: встроить получение секрета в приложение, добавить фиксированную задержку перед запуском или вынести подготовку в init-контейнер.
Встроенная логика усложняла приложение и могла привести к частично инициализированному процессу. Задержка была простой, но зависела от случайной длительности ответа хранилища и не подтверждала результат. Init-контейнер выполнял проверку и записывал временные файлы в общий том, а основной контейнер запускался только после успешной подготовки.
Выбранный вариант обеспечил детерминированный порядок и понятные события отказа. Дополнительно проверили повторный запуск, ограничили время ожидания внешнего хранилища и не записывали секрет в образ контейнера или журналы.
Оркестратор не переходит к следующему init-контейнеру и не запускает обычные контейнеры пода как готовое приложение. Неуспешный контейнер обычно перезапускается в соответствии с правилами жизненного цикла пода; поэтому временная ошибка может быть устранена повтором, но постоянная ошибка оставит под в незавершённом состоянии.
Практический вывод: подготовительный шаг должен иметь понятные тайм-ауты, диагностичные логи и безопасное поведение при повторении. Бесконечные повторы без наблюдаемости превращают ошибку в скрытое зависание релиза.
Init-контейнер предназначен для конечного подготовительного действия и должен завершиться. Sidecar работает одновременно с основным контейнером и поддерживает его во время всей жизни пода, например обслуживает проксирование или обновление локального файла.
Подмена одного механизма другим меняет семантику готовности: долго работающий sidecar как init-контейнер заблокирует запуск приложения, а подготовка в sidecar может позволить приложению стартовать слишком рано.
Init-контейнер выполняется для каждого создаваемого пода, поэтому при масштабировании несколько экземпляров могут одновременно изменить одну базу. Даже идемпотентная миграция может создать блокировки, конкуренцию или несовместимость между версиями приложения.
Безопаснее отделить миграцию от запуска реплик: выполнять её как контролируемый этап доставки, использовать блокировку или специализированный миграционный процесс и применять стратегию совместимых изменений, например сначала добавить новые поля, затем перевести приложение, а удаление старой структуры отложить.