AKS не може да изтегли образ от частен registry зад VPN
kubelet изтегля през мрежата на node, а не през VPN на pod. Решавайте по маршрутите на node, DNS на node, всеки endpoint, който изтеглянето докосва, после TLS и идентичност.
На лаптопа ви образът се изтегля без проблем, а pod-ът стои в ImagePullBackOff и някой предлага да пуснете корпоративния VPN клиент като sidecar. Това няма да помогне, защото изтеглянето става преди контейнерът ви да съществува: kubelet иска от container runtime на node да донесе образа, а runtime използва мрежовото пространство на node. VPN вътре в workload не може да предложи маршрут за този път, а собственият му помощен образ също трябва да бъде изтеглен първо.
Редът на операциите определя слоя
Първо идва разрешаването на името. kubelet през runtime разрешава името на registry, свързва се, удостоверява се, изтегля слоевете и едва след това стартира контейнера. Всичко, което pod-ът прави с VPN, се случва след тази последователност, затова работещ тунел в клъстера не е доказателство за изтеглянето.
Затова кешираният образ е толкова убедителна лъжа. Node, който е изтеглил образа преди седмици, продължава да го сервира, deployment-ът изглежда здрав и отказът се появява само когато планировчикът постави реплика на по-нов node. Ако в хронологията има мащабиране, подмяна на node или upgrade на pool, третирайте ги като спусък, а не като причина.
Три условия определят ремонта
Достъпът до частен registry от управляван node pool се свежда до маршрутизация, разрешаване на имена и набор от endpoint-и. Ако подмрежата на node не може да маршрутизира към мрежата на registry, никакви идентификационни данни не помагат. Ако маршрутът е налице, но името не се разрешава през DNS пътя на node, връзката не започва. Ако и двете работят за manifest endpoint, но не за blob endpoint, към който registry пренасочва, изтеглянето се проваля по средата.
| 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.
Прочетете отказа, преди да изберете поправка
Започнете със събитията на pod-а и 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-та и си струва да се прочете веднъж преди промяна на мрежата, защото прави границата между удостоверяване и транспорт ясна.
Изградете пътя под pod-а
Работете в този ред, защото всяка стъпка е безсмислена, докато предишната не е изпълнена. Първо маршрутизирайте мрежата на node: потвърдете, че подмрежата има поддържан път до мрежата на registry, проверете ефективните маршрути на node, правилата за сигурност от двете страни и обратния маршрут при registry.
След това разрешете името от контекста на node. Resolver-ът на node не е същото като DNS конфигурацията на pod и успехът в pod не е доказателство за host runtime. Използвайте управляван частен DNS вместо постоянен запис в hosts; записът живее до подмяната на node и после тихо изчезва.
След това докажете всеки endpoint. Registry може да даде на клиента отделна услуга за удостоверяване и отделно място за blob съхранение. Достигането на manifest endpoint не доказва почти нищо за слоевете. Накрая завършете TLS и оторизацията: сертификат, валиден за името на registry и доверен чрез поддържана конфигурация на node, плюс идентичност за изтегляне с право да чете това repository.
Проверете на node, който не сте поправили на ръка
Тестът, който има значение, е ново изтегляне и пълно сваляне на всички слоеве на подходящ node, за предпочитане създаден чрез мащабиране или подмяна. Така се покриват всички pool-ове, които биха могли да поставят workload, включително забравените. Ръчна поправка на един node не е модел за внедряване и следващото автоматично мащабиране ще намери празнината.
Пресъздаването на клъстера в друг VNet може да промени пътя, но това е последна мярка, а не първа диагностична стъпка. Сравнете съществуващата мрежа на node с необходимия частен маршрут и поддържаните AKS мрежови контроли, преди да предложите миграция, и пазете свързаността на приложението след стартиране като отделна проверка: pod-ът, който говори с backend-а си, е различна проверка от node, който изтегля образа.