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. Текст події відрізняє нерозв’язане ім’я хоста від timeout, відмову сертифіката від відсутнього образу й помилку авторизації від усього цього.
Автентифікація є найбільш переоціненим важелем. 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.