В этом материале
Подготовка артефакта в init container должна переживать повторный запуск. Наличие файла с нужным именем не подтверждает, что загрузка закончилась и содержимое корректно. Проектируйте явную проверку версии, целостности и завершённого состояния перед стартом основного процесса.
Подготовка артефакта в init container должна переживать повторный запуск. Наличие файла с нужным именем не подтверждает, что загрузка закончилась и содержимое корректно. Проектируйте явную проверку версии, целостности и завершённого состояния перед стартом основного процесса.
Определите готовый артефакт
Запишите immutable reference, ожидаемый набор файлов и критерий целостности из доверенного источника. У каталога должны быть понятные владелец и права. Не используйте единственный флаг «файл существует», если незавершённая загрузка создаёт его заранее. Для нескольких файлов определите, какой marker означает успешную подготовку всего набора. Значение marker связывайте с конкретной ревизией, иначе остаток предыдущего запуска может ошибочно разрешить старт с другой конфигурацией.
Учтите повтор init container
Kubernetes может повторно запускать init container; его код должен быть идемпотентным. Файлы в общем emptyDir могут уже существовать после предыдущей попытки. Отличайте повтор контейнера внутри Pod от создания нового Pod с новым временным томом. Не считайте init container постоянным кешем между любыми пересозданиями. Сохраните, какой mount используется и кто отвечает за остатки временной загрузки. Успешное завершение init означает выполненное условие подготовки, но не готовность самого приложения.
Спроектируйте условную загрузку
В учебном процессе версия 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; autoscaling gpu cold start.