AKS ne more potegniti slike iz zasebnega registryja za VPN
kubelet vleče prek omrežja node, ne prek VPN poda. Odločite se po poteh node, DNS node, vsakem endpointu, ki se ga dotakne vlečenje, nato TLS in identiteta.
Na prenosniku se slika potegne brez težav, a pod ostane v ImagePullBackOff in nekdo predlaga zagon korporativnega odjemalca VPN kot sidecar. To ne pomaga, ker se vlečenje zgodi preden obstaja vaš container: kubelet prosi container runtime na node, naj prinese sliko, runtime pa uporablja omrežni namespace node.
Vrstni red operacij določa plast
Najprej razrešitev imena, nato povezava, preverjanje pristnosti, prenos plasti in šele nato zagon containerja. Vse, kar pod počne z VPN, se zgodi po tem zaporedju, zato delujoč tunel v gruči ni dokaz o vlečenju.
Zato je predpomnjenja slika tako prepričljiva laž: node, ki je sliko potegnil pred tedni, jo še vedno streže, deployment je videti zdrav, napaka pa se pokaže šele, ko razporejevalnik postavi repliko na novejši node. scale-up ali zamenjava node je sprožilec, ne vzrok.
Trije pogoji določajo popravilo
Dostopnost se zvede na usmerjanje, razreševanje imen in množico endpointov. Če podomrežje node ne more usmerjati v omrežje registryja, nobene poverilnice ne pomagajo. Če se ime ne razreši prek DNS node, povezava se ne začne. Če deluje le manifest in ne blob, vlečenje odpove na pol poti.
| 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 |
Samo VNet peering ne da vseh postavitev gateway transit in pot v eno smer ni delujoča pot. Node potrebuje podprto pot skozi predvideni VPN gateway, stran registryja pa povratno pot v podomrežje node.
Preberite napako, preden izberete popravilo
Začnite z dogodki poda in node, na katerega je pristal, z resničnimi imeni: kubectl describe pod app-example -n team-example in kubectl get pod app-example -n team-example -o wide. Besedilo dogodka loči nerazrešeno ime gostitelja od timeouta, zavrnitev potrdila od manjkajoče slike in napako avtorizacije od vsega tega.
Preverjanje pristnosti je najbolj precenjena ročica. imagePullSecret daje runtimeu poverilnice za registry; ne namesti poti, ne spremeni resolverja node in ne naredi nezaupljivega potrdila veljavnega. Če dogodek pravi, da vlečenje ni bilo avtorizirano, poglejte obseg identitete; če pravi, da je povezava potekla, so poverilnice nepomembne.
Dokumentacija Kubernetes o slikah je referenca za vedenje pri vlečenju in poverilnice zasebnih registryjev, in vredno jo je enkrat prebrati pred spremembo omrežja, ker jasno pokaže mejo med preverjanjem pristnosti in prenosom.
Zgradite pot pod podom
Delajte v tem vrstnem redu. Najprej usmerite omrežje node: potrdite, da ima podomrežje podprto pot v omrežje registryja, preverite dejanske poti na node, varnostna pravila na obeh koncih in povratno pot na strani registryja.
Nato razrešite ime iz konteksta node. Resolver node ni DNS konfiguracija poda in uspeh v podu ni dokaz za host runtime. Uporabite upravljani zasebni DNS namesto trajnega vnosa v hosts; vnos živi do zamenjave node in nato tiho izgine.
Nato dokažite vsak endpoint. Registry lahko odjemalcu da ločeno storitev preverjanja pristnosti in ločeno shrambo blob. Doseganje manifesta skoraj ničesar ne dokaže o plasteh. Na koncu dokončajte TLS in avtorizacijo: potrdilo veljavno za ime registryja in zaupanja vredno prek podprte konfiguracije node, plus identiteta vlečenja omejena na branje tega repozitorija.
Preverite na node, ki ga niste popravili ročno
Test, ki šteje, je sveže vlečenje in popoln prenos vseh plasti na ustreznem node, idealno ustvarjenem s skaliranjem ali zamenjavo. To pokrije vse pool-e, ki bi lahko postavili workload, tudi pozabljene. Ročno popravilo na enem node ni model uvajanja in naslednji dogodek autoscale bo našel vrzel.
Ponovno ustvarjanje gruče v drugem VNet lahko spremeni pot, a to je zadnja možnost in ne prvi diagnostični korak. Primerjajte obstoječe omrežje node z zahtevano zasebno potjo in podprtimi omrežnimi kontrolami AKS, preden predlagate migracijo, in ohranite povezljivost aplikacije po zagonu kot ločeno preverjanje: pogovor poda z backendom je druga kontrola kot prenos slike na node.