Batch-миграция init-контейнеров на Image Volumes в Kubernetes 1.35

Кластер с десятками подов, использующими init-контейнеры для копирования статичных данных, — типичная картина организации, ещё не перешедшей на Image Volumes, стабилизированные в Kubernetes 1.35. Проверка каждого манифеста вручную занимает время, которого обычно нет при плановом технологическом долге.

Характерный паттерн кандидата на замену

initContainers:
  - name: copy-config
    image: my-config-data:v3
    command: ["cp", "-r", "/data/.", "/shared/"]
    volumeMounts:
      - name: shared
        mountPath: /shared

Init-контейнер, единственная задача которого — скопировать статичные файлы из своего образа в общий volume, — прямой кандидат на замену Image Volume, потому что весь смысл такого контейнера сводится к копированию, а не к реальной логике выполнения.

Что НЕ подходит под замену

Практический подход к миграции парка манифестов

Массовая миграция редко бывает мгновенной — разумнее сначала найти всех кандидатов автоматически, оценить объём работы, а затем мигрировать постепенно, начиная с наименее критичных сервисов, проверяя каждую замену на реальном трафике перед переходом к следующей.

Как найти кандидатов сразу во всём парке манифестов

Просматривать каждый YAML-файл вручную в поисках паттерна копирования долго. Init Container to Image Volume Batch Migrator сканирует сразу несколько манифестов и находит совпадения по характерному паттерну команды копирования.

Итоговый чеклист

Init-контейнеры, единственная задача которых — копирование статичных данных, прямой кандидат на замену Image Volume, но не все init-контейнеры подходят под эту замену.

Массовую миграцию разумнее проводить постепенно, начиная с наименее критичных сервисов, а не одним рискованным переключением всего парка сразу.

Требуется совместимый container runtime — стоит проверить поддержку до начала массовой миграции.