AKS ezin du VPN atzean dagoen registry pribatu batetik irudia atera
kubelet-ek nodearen sarearen bidez egiten du tira, ez podaren VPNaren bidez. Erabaki nodearen ibilbideen, nodearen DNSaren, tirak ukitzen duen endpoint bakoitzaren arabera, eta gero TLS eta identitatea.
Zure ordenagailu eramangarriak irudia ondo jaisten du, baina poda ImagePullBackOff egoeran geratzen da, eta norbaitek VPN bezero korporatiboa sidecar gisa exekutatzea proposatzen du. Horrek ez du lagunduko, tira zure edukiontzia existitzen hasi aurretik gertatzen delako: kubelet-ek nodeko container runtime-ari esaten dio irudia ekartzeko, eta runtime-ak nodearen sare-namespacea erabiltzen du. Workload barruko VPNak ez du bide horretarako ibilbiderik, eta bere laguntza-irudia ere lehenago jaitsi behar da.
Eragiketen ordenak erabakitzen du geruza
Lehenik irudiaren izenaren ebazpena dator. kubelet-ek, runtimearen bidez, registryaren izena ebazten du, konektatu, autentifikatu, geruzak deskargatu eta gero bakarrik abiatzen du edukiontzia. Podak VPNarekin egiten duen guztia sekuentzia horren ondoren gertatzen da, beraz klusterrean funtzionatzen duen tunel bat ez da tiraren froga.
Horregatik cachean dagoen irudi bat gezur sinesgarria da. Duela asteak irudia atera zuen node batek ematen jarraitzen du, deploymentak osasuntsu dirudi, eta hutsegitea replica node berriago batean jartzen duenean agertzen da soilik. Denbora-lerroan scale-up, node ordezkatze edo pool eguneratze bat badago, horiek kitzikatzailetzat hartu, ez kausatzat.
Hiru baldintzak erabakitzen dute konponketa
Node pool kudeatu batetik registry pribatu baterako irisgarritasuna bideratzean, izen-ebazpenean eta endpoint multzoan laburbiltzen da. Nodoaren azpisareak registry sareara bideratzeko gai ez bada, kredentzialik ez du lagunduko. Bideratu baina nodoaren DNS bidearen bidez registry izena ebazten ez badu, konexioa ez da inoiz hasten. Biak manifest endpointarentzat funtzionatzen badute baina registryk birbideratzen duen blob endpointarentzat ez, tirak erdian huts egiten du.
| 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 hutsak ez dizu gateway transit konbinazio guztiak automatikoki ematen, eta noranzko bakarrean dagoen ibilbidea ez da funtzionatzen duen ibilbidea. Nodoak VPN gateway aurreikusiaren edo gailu onartu baten bidezko bide onartua behar du, eta registry aldeak nodoaren azpisarera itzultzeko ibilbidea.
Irakurri hutsegitea konponbidea aukeratu aurretik
Hasi podaren gertaerekin eta erori zen nodoarekin, zure benetako izenekin: kubectl describe pod app-example -n team-example eta kubectl get pod app-example -n team-example -o wide. Gertaeraren testuak bereizten ditu ebazpenik gabeko ostalari-izena eta timeouta, ziurtagiri ukatzea eta falta den irudia, eta autorizazio-hutsegitea eta gainerako guztiak. Lauek lau jabe desberdin dituzte.
Autentifikazioa da gehien gainbaloratzen den palanka. imagePullSecretk registryaren kredentzialak ematen dizkio runtimeari; ez du ibilbiderik instalatzen, ez du nodoaren resolverra aldatzen eta ez du ziurtagiri ez-fidagarri bat baliozko bihurtzen. Gertaerak tira ez zela baimendu esaten badu, begiratu identitatearen irismena. Konexioak denbora agortu zuela esaten badu, kredentzialak ez dira garrantzitsuak.
Kubernetes-en irudi dokumentazioa da tira-portaeraren eta registry pribatuen kredentzialen erreferentzia, eta merezi du sareak aldatu aurretik behin irakurtzea, autentifikazioaren eta garraioaren arteko muga argi uzten duelako.
Eraiki bidea podaren azpian
Lan egin ordena honetan, aurrekoa betetzen ez den bitartean urrats bakoitza zentzugabea delako. Bideratu lehenik nodoaren sarea: egiaztatu azpisareak registry sareara bide onartua duela, berrikusi nodoan indarrean dauden ibilbideak, bi muturretako segurtasun-arauak eta registry aldeko itzulera-ibilbidea.
Gero ebatzi izena nodoaren testuingurutik. Nodoaren resolverra ez da podaren DNS konfigurazioa, eta pod baten barruko arrakasta ez da ostalariaren runtimearen froga. Erabili kudeatutako DNS pribatua hosts fitxategiko sarrera iraunkorraren ordez; sarrera nodoa ordezkatu arte bizirik dago eta gero isilka desagertzen da.
Gero frogatu endpoint bakoitza. Registry batek autentifikazio-zerbitzu bereizia eta blob biltegiratze bereizia eman diezazkioke bezeroari. Manifest endpointera iristeak ez du geruzen inguruan ia ezer frogatzen. Azkenik osatu TLS eta autorizazioa: registry izenerako baliozkoa eta onartutako nodo konfigurazioaren bidez fidatua den ziurtagiria, gehi repo hori irakurtzera mugatutako tira-identitatea.
Egiaztatu eskuz konpondu ez duzun nodo batean
Kontuan hartzen den proba nodo egoki batean tira berri bat eta geruza guztien deskarga osoa da, hoberena eskalatze edo ordezkatze bidez sortutako nodo batean. Honek workloada kokatu lezakeen pool guztiak estaltzen ditu, ahaztu dituzunak barne. Nodo bakarrean eskuz egindako konponketa ez da hedapen-eredua, eta hurrengo autoscale gertaerak hutsunea aurkituko du.
Klusterra beste VNet batean birsortzeak bidea alda dezake, baina azken baliabidea da, ez lehen diagnostiko urratsa. Alderatu egungo nodo-sarea beharrezko ibilbide pribatuarekin eta onartutako AKS sare-kontrolekin migrazioa proposatu aurretik, eta mantendu aplikazioaren konektibitatea abiatu ondoren egiaztapen bereizi gisa: podak bere backendarekin hitz egitea nodoak irudia deskargatzearen beste egiaztapen bat da.