# Init container повторно скачивает артефакт: как сделать подготовку идемпотентной

Диагностика: Init container повторно скачивает артефакт: как сделать подготовку идемпотентной. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-init-artifact-download/
Language: ru

Подготовка артефакта в init container должна переживать повторный запуск. Наличие файла с нужным именем не подтверждает, что загрузка закончилась и содержимое корректно. Проектируйте явную проверку версии, целостности и завершённого состояния перед стартом основного процесса.

## Определите готовый артефакт

Запишите immutable reference, ожидаемый набор файлов и критерий целостности из доверенного источника. У каталога должны быть понятные владелец и права. Не используйте единственный флаг «файл существует», если незавершённая загрузка создаёт его заранее. Для нескольких файлов определите, какой marker означает успешную подготовку всего набора. Значение marker связывайте с конкретной ревизией, иначе остаток предыдущего запуска может ошибочно разрешить старт с другой конфигурацией.


[Официальный источник 1](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).

## Учтите повтор init container

Kubernetes может повторно запускать init container; его код должен быть идемпотентным. Файлы в общем emptyDir могут уже существовать после предыдущей попытки. Отличайте повтор контейнера внутри Pod от создания нового Pod с новым временным томом. Не считайте init container постоянным кешем между любыми пересозданиями. Сохраните, какой mount используется и кто отвечает за остатки временной загрузки. Успешное завершение init означает выполненное условие подготовки, но не готовность самого приложения.


[Официальный источник 2](https://docs.docker.com/build/building/best-practices/).

## Спроектируйте условную загрузку

В учебном процессе версия A скачивается во временный каталог A.partial. После проверки файлов публикуется законченный каталог или marker для A, затем запускается main container. При повторе загрузчик проверяет ревизию и целостность, а не дописывает данные в неизвестный остаток. Атомарное перемещение требует подходящей файловой системы и одного корректно выбранного пути; для удалённого object storage нельзя автоматически обещать ту же семантику операции, что для локального rename.

| Состояние | Предусмотренное действие |
| --- | --- |
| Нет артефакта | Начать подготовку нужной ревизии |
| Есть partial | Проверить или очистить незавершённую попытку |
| Есть проверенная A | Разрешить предусмотренное повторное использование |
| Требуется версия B | Не принимать marker версии A |

## Ограничьте зависимость от сети

Определите timeout загрузки, retry policy и способ передачи credentials без записи в артефакт. Проверьте DNS, egress и доверие TLS внутри init container. Загрузка образа kubelet и скачивание файлов процессом используют разные сетевые области. Избегайте общего activeDeadlineSeconds без понимания: deadline Pod может влиять и после успешного завершения init. Для длительных задач учитывайте документированные рекомендации Kubernetes и назначение workload, а не просто добавляйте бесконечное ожидание.

## Проверьте прерывание и восстановление

Остановите тестовую попытку посреди загрузки, повторите её и убедитесь, что main container не видит непроверенный набор. Затем измените ревизию и проверьте инвалидирование старого marker. Артефакт процедуры содержит reference, checksum policy, состояние partial и критерий публикации. Он позволяет восстановить подготовку без интерактивных ручных исправлений. Повторяемость загрузки не гарантирует одинаковые ответы LLM; она фиксирует только проверяемый набор файлов, переданный следующему этапу запуска.

Связанные разборы: [software stack reproducibility](/ru/journal/software-stack-reproducibility/); [autoscaling gpu cold start](/ru/journal/autoscaling-gpu-cold-start/).