AKS не може да повлече слика од приватен registry зад VPN
kubelet повлекува преку мрежата на node, а не преку VPN на pod. Одлучете по маршрутите на node, DNS-от на node, секој endpoint што повлекувањето го допира, потоа TLS и идентитет.
Вашиот лаптоп ја повлекува сликата без проблем, но pod-от останува во ImagePullBackOff. Предлогот да го стартувате корпоративниот VPN клиент како sidecar нема да помогне, бидејќи повлекувањето се случува пред вашиот контејнер да постои: kubelet бара од container runtime на node да ја донесе сликата, а runtime го користи мрежниот namespace на node.
Редоследот на операции го одредува слојот
Прво се разрешува името, потоа врската, автентикацијата, преземањето слоеви и дури тогаш контејнерот се стартува. Сето она што pod-от го прави со 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.
Прочитајте го дефектот пред да изберете поправка
Започнете со настаните на 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 не докажува речиси ништо за слоевите. На крај завршете TLS и авторизација: сертификат важечки за името на registry и доверлив преку поддржана node конфигурација, плус идентитет за повлекување ограничен на читање на тоа repo.
Проверете на node што не сте го поправиле рачно
Вистинскиот тест е свежо повлекување и целосно преземање на сите слоеви на соодветен node, идеално создаден со скалирање или замена. Тоа ги покрива сите pool-ови што можат да го постават workload-от, вклучително заборавените. Рачна поправка на еден node не е модел на распоредување, а следниот autoscale настан ќе ја најде празнината.
Пресоздавањето на кластерот во друг VNet може да го промени патот, но тоа е последно средство, а не прв дијагностички чекор. Споредете ја постоечката мрежа на node со потребната приватна рута и поддржаните AKS мрежни контроли пред да предложите миграција, и задржете ја поврзаноста на апликацијата по стартување како одделна проверка: pod-от што зборува со backend-от е друга проверка од node-от што ја презема сликата.