AKS не может получить образ из приватного registry за VPN
kubelet скачивает через сеть node, а не через VPN пода. Решайте по маршрутам node, DNS node, каждому endpoint, которого касается скачивание, затем по TLS и идентичности.
На ноутбуке образ скачивается без проблем, но под висит в ImagePullBackOff и кто-то предлагает запустить корпоративный VPN-клиент как sidecar. Это не поможет, потому что скачивание происходит до появления контейнера: kubelet просит container runtime на node принести образ, а runtime использует сетевое пространство имён node.
Порядок операций определяет слой
Сначала разрешается имя, затем соединение, аутентификация, загрузка слоёв, и только потом стартует контейнер. Всё, что под делает с VPN, происходит после этой последовательности, поэтому работающий туннель в кластере не доказывает успех скачивания.
Поэтому закэшированный образ — настолько убедительная ложь: node, скачавший образ недели назад, продолжает его отдавать, deployment выглядит здоровым, а сбой проявляется только когда планировщик ставит реплику на более новый node. scale-up или замена node — это триггер, а не причина.
Три условия определяют починку
Доступность сводится к маршрутизации, разрешению имён и набору endpoint. Если подсеть node не маршрутизирует в сеть registry, никакие учётные данные не помогут. Если имя не разрешается через DNS node, соединение не начнётся. Если доступен только manifest, а blob нет, скачивание сорвётся на середине.
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
Один только VNet peering не даёт всех схем gateway transit, а маршрут в одну сторону — не рабочий маршрут. Node нужен поддерживаемый путь через нужный VPN gateway, а стороне registry — обратный маршрут к подсети node.
Прочитайте сбой, прежде чем выбирать исправление
Начните с событий пода и node, на который он попал, со своими реальными именами: kubectl describe pod app-example -n team-example и kubectl get pod app-example -n team-example -o wide. Текст события отличает неразрешённое имя хоста от таймаута, отказ сертификата от отсутствующего образа, а ошибку авторизации от всего перечисленного.
Аутентификация — самый переоценённый рычаг. imagePullSecret даёт runtime учётные данные для registry; он не ставит маршрут, не меняет resolver node и не делает недоверенный сертификат действительным. Если событие говорит, что скачивание не было авторизовано, смотрите на область действия идентичности; если говорит, что соединение истекло, учётные данные ни при чём.
Документация Kubernetes об образах — источник о поведении при скачивании и учётных данных приватных registry, и её стоит прочитать один раз перед изменением сети, потому что она ясно показывает границу между аутентификацией и транспортом.
Постройте путь под подом
Работайте в этом порядке. Сначала маршрутизируйте сеть node: подтвердите, что подсеть имеет поддерживаемый путь в сеть registry, проверьте действующие маршруты на node, правила безопасности на обоих концах и обратный маршрут на стороне registry.
Затем разрешите имя из контекста node. Resolver node — не то же самое, что DNS-конфигурация пода, и успех внутри пода не доказывает работу host runtime. Используйте управляемый приватный DNS вместо постоянной записи в hosts; запись живёт до замены node, а затем тихо исчезает.
Затем докажите каждый endpoint. Registry может выдать клиенту отдельный сервис аутентификации и отдельное blob-хранилище. Достижение manifest почти ничего не доказывает о слоях. В конце завершите TLS и авторизацию: сертификат, действительный для имени registry и доверенный через поддерживаемую конфигурацию node, плюс идентичность скачивания с правом чтения этого репозитория.
Проверьте на node, который вы не чинили вручную
Настоящий тест — свежее скачивание и полная загрузка всех слоёв на подходящем node, лучше созданном масштабированием или заменой. Это охватывает все пулы, которые могут разместить workload, включая забытые. Ручная починка на одном node — не модель развёртывания, и следующее событие автомасштабирования найдёт пробел.
Пересоздание кластера в другом VNet может изменить путь, но это крайняя мера, а не первый шаг диагностики. Сравните существующую сеть node с требуемым приватным маршрутом и поддерживаемыми сетевыми механизмами AKS, прежде чем предлагать миграцию, и держите связность приложения после старта отдельной проверкой: разговор пода с backend — это другая проверка, чем загрузка образа node.