В этом материале
После deny-all egress init container может не скачать артефакт и не дать Pod перейти к основному процессу. Проверьте DNS и сетевые зависимости самой подготовки. Загрузка image kubelet происходит в другой области и не доказывает доступность сети внутри Pod.
После deny-all egress init container может не скачать артефакт и не дать Pod перейти к основному процессу. Проверьте DNS и сетевые зависимости самой подготовки. Загрузка image kubelet происходит в другой области и не доказывает доступность сети внутри Pod.
Нарисуйте bootstrap dependencies
Для каждого init шага сохраните endpoint, протокол, порт и назначение: resolver, artifact storage, configuration service или другой подтверждённый ресурс. Не включайте в отчёт signed URLs и credentials. Уточните редиректы и proxy path, поскольку исходное имя может приводить к другому адресу. Общий список «разрешить интернет» не объясняет, какая зависимость нужна и где она используется. Отдельно запишите image registry как node-side dependency kubelet, чтобы не включить её ошибочно в Pod allowlist без необходимости.
Проверьте применение NetworkPolicy
Сохраните labels Pod, namespace selectors и все применимые egress policies. Их разрешения складываются по модели Kubernetes, а не выполняются как упорядоченный firewall first-match. Убедитесь, что CNI поддерживает нужную семантику. Обычная NetworkPolicy работает с IP/портами/selectors, а не предоставляет универсальный hostname allowlist для внешнего storage. Если платформа предлагает расширения, изучайте их отдельно. Смена IP у внешней зависимости может сделать статическое разрешение неустойчивым даже при корректном DNS lookup.
Разберите успешный pull и зависший init
В учебном Pod image уже загружен узлом, контейнер запущен, но init ждёт соединения с artifact.example.org. Это совместимо с запретом Pod egress и не опровергается успешным image pull. Проверьте DNS отдельно, затем TCP и TLS к требуемому адресу. Используйте диагностическую среду с той же policy identity, а не произвольный debug Pod без labels. Иначе тест случайно обойдёт правило и создаст ложное подтверждение доступности.
| Стадия | Где проверять |
|---|---|
| Image pull | Узел и kubelet/runtime |
| DNS lookup | Сеть и resolver Pod |
| Artifact connection | Egress выбранного workload |
| Init completion | Проверка результата загрузки |
Разрешите минимальный путь
Добавьте нужные DNS TCP/UDP rules и подтверждённые направления подготовки в подходящем для платформы виде. Не снимайте deny-all полностью ради одного endpoint. Сохраните возможность повторной идемпотентной загрузки после исправления: незавершённый файл может пережить повтор init. Credentials должны предоставляться отдельно от network policy. Успешный TCP connect не подтверждает ни доверие TLS, ни разрешение storage на чтение файла. Каждая граница должна иметь собственное диагностическое подтверждение.
Проверьте сохранение изоляции
После изменения запустите новый тестовый Pod с теми же labels и повторите bootstrap. Одновременно убедитесь, что посторонний адрес остаётся недоступным согласно policy. Артефакт содержит dependency graph, selectors, CNI version и результат разрешённого/запрещённого теста. Успех включает корректный проверенный артефакт и завершение init, а не только открытый порт. Повторяйте проверку после смены storage endpoint или redirect behavior: прежняя allowlist может больше не описывать реальный bootstrap path.
Связанные разборы: hardware security; autoscaling gpu cold start.