AKS negali parsiųsti iš privataus registro už jūsų VPN
Kubelet traukia per mazgo tinklą, o ne per podo VPN. Spręskite pagal mazgo maršrutus, mazgo DNS, kiekvieną galinį tašką, kurį paliečia traukimas, o tada pagal TLS ir tapatybę.
Jūsų nešiojamasis kompiuteris atvaizdą atsisiunčia be problemų, podas įstringa būsenoje ImagePullBackOff, ir kažkas pasiūlo paleisti įmonės VPN klientą kaip sidecar. Tai nepadės, nes traukimas įvyksta dar prieš atsirandant jūsų konteineriui: kubelet paprašo mazgo konteinerių vykdymo aplinkos atsisiųsti atvaizdą, o ta aplinka naudoja mazgo tinklo vardų erdvę. VPN darbo krūvio viduje neturi ko pasiūlyti tam keliui, o jo paties pagalbinį atvaizdą vis tiek pirmiausia reikėtų atsisiųsti.
Operacijų tvarka nulemia sluoksnį
Pirmiausia vyksta atvaizdo išsprendimas. Kubelet per vykdymo aplinką išsprendžia registro vardą, prisijungia prie jo, autentifikuojasi, atsisiunčia sluoksnius ir tik tada paleidžia konteinerį. Viskas, ką jūsų podas daro su VPN, įvyksta po tos sekos, todėl veikiantis tunelis klasterio viduje nėra įrodymas apie traukimą.
Štai kodėl talpykloje esantis atvaizdas taip įtikinamai meluoja. Vienas mazgas, atsisiuntęs atvaizdą prieš kelias savaites, toliau jį naudoja, diegimas atrodo sveikas, o triktis pasirodo tik tada, kai planuotojas paskiria kopiją naujesniame mazge. Jei įvykių laiko juosta apima mastelio didinimą, mazgo pakeitimą ar baseino atnaujinimą, laikykite tai priežastimi, kuri suveikė, o ne pagrindine priežastimi.
Trys sąlygos nulemia taisymą
Privataus registro pasiekiamumas iš valdomo mazgų baseino priklauso nuo maršrutizavimo, vardų sprendimo ir galinių taškų rinkinio. Jei mazgo potinklis negali maršrutizuoti į registro tinklą, jokie kredencialai nepadės. Jei maršrutizuoja, bet negali išspręsti registro vardo per mazgo DNS kelią, ryšys net neprasideda. Jei abu veikia manifest'o galiniam taškui, bet ne blob'ų galiniam taškui, į kurį registras nukreipia, traukimas nutrūksta pusiaukelėje su klaidinančiu pranešimu.
| 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 |
Vien VNet savitarpio ryšys automatiškai nesuteikia visų šliuzo tranzito konfigūracijų, o maršrutas, egzistuojantis viena kryptimi, nėra veikiantis maršrutas. Mazgui reikia palaikomo kelio per numatytą VPN šliuzą ar patvirtintą įrenginį, o registro pusėje reikia grįžtamojo maršruto į mazgo potinklį.
Prieš rinkdamiesi taisymą perskaitykite triktį
Pradėkite nuo podo įvykių ir mazgo, kuriame jis atsidūrė, naudodami savo tikrus pavadinimus: kubectl describe pod app-example -n team-example ir kubectl get pod app-example -n team-example -o wide. Įvykio tekstas atskiria neišspręstą pagrindinio kompiuterio vardą nuo laiko limito, sertifikato atmetimą nuo trūkstamo atvaizdo, o autorizacijos triktį nuo visų jų. Tos keturios turi keturis skirtingus savininkus.
Autentifikavimas yra labiausiai pervertinama svirtis. imagePullSecret suteikia vykdymo aplinkai registro kredencialus; jis neįdiegia maršruto, nekeičia mazgo resolver'io ir nepadaro nepatikimo sertifikato galiojančiu. Jei įvykis sako, kad traukimas buvo neautorizuotas, žiūrėkite į tapatybės apimtį. Jei sakoma, kad ryšio laikas baigėsi, kredencialai nesvarbūs.
Kubernetes atvaizdų dokumentacija yra traukimo elgsenos ir privataus registro kredencialų šaltinis, ir verta ją perskaityti vieną kartą prieš keičiant tinklą, nes ji aiškiai parodo ribą tarp autentifikavimo ir transportavimo.
Nutieskite kelią žemiau podo
Dirbkite šia tvarka, nes kiekvienas žingsnis beprasmis, kol neįvykdytas ankstesnis. Pirmiausia suderinkite mazgo tinklą: patvirtinkite, kad mazgo potinklis turi palaikomą kelią į registro tinklą, patikrinkite veiksmingus maršrutus mazge, saugos taisykles abiejuose galuose ir grįžtamąjį maršrutą registro pusėje.
Tada išspręskite vardą mazgo kontekste. Mazgo resolver'is nėra tas pats, kas podo DNS konfigūracija, o sėkmė podo viduje nėra įrodymas apie pagrindinės sistemos vykdymo aplinką. Naudokite valdomą privatų DNS, o ne nuolatinį hosts failo įrašą; įrašas išlieka iki mazgo pakeitimo ir tada tyliai dingsta.
Tada įrodykite kiekvieną galinį tašką. Registras klientui gali pateikti atskirą autentifikavimo paslaugą ir atskirą blob'ų saugyklos vietą. Pasiekimas manifest'o galinio taško beveik nieko neįrodo apie sluoksnius. Galiausiai užbaikite TLS ir autorizaciją: sertifikatas, galiojantis registro vardui ir patikimas per palaikomą mazgo konfigūraciją, bei traukimo tapatybė, kurios apimtis leidžia skaityti tą saugyklą.
Patikrinkite tai mazge, kurio neremontavote rankomis
Svarbus testas yra naujas traukimas ir visas sluoksnių atsisiuntimas tinkamame mazge, idealiu atveju tokiame, kuris sukurtas mastelio keitimu ar pakeitimu. Tai apima kiekvieną baseiną, kuris galėtų paskirti darbo krūvį, įskaitant tuos, kuriuos pamiršote. Rankinis taisymas viename mazge nėra diegimo modelis, ir kitas automatinio mastelio įvykis ras spragą.
Klasterio atkūrimas kitame VNet gali pakeisti kelią, bet tai paskutinė priemonė, o ne pirmas diagnostikos žingsnis. Prieš siūlydami migraciją palyginkite esamą mazgo tinklą su reikiamu privačiu maršrutu ir palaikomomis AKS tinklo valdymo priemonėmis, o programos ryšį po paleidimo laikykite atskiru patikrinimu: podo pokalbis su savo užnugariu yra kitas patikrinimas nei mazgo atvaizdo atsisiuntimas.