AKS ne povas tiri bildon el privata registro malantaŭ via VPN
La kubelet tiras tra la reto de la nodo, ne tra la VPN de la podo. Decidu laŭ la itineroj de la nodo, la DNS de la nodo, ĉiu finpunkto kiun la tirado tuŝas, poste TLS kaj identeco.
Via tekkomputilo tiras la bildon senprobleme, sed la podo restas en ImagePullBackOff, kaj iu proponas ruli la firmaan VPN-klienton kiel sidecar. Tio ne helpos, ĉar la tirado okazas antaŭ ol ekzistas via ujo: la kubelet petas la container runtime sur la nodo alporti la bildon, kaj la runtime uzas la retan namespacen de la nodo. VPN ene de la workload ne havas itineron por tiu vojo, kaj ĝia propra helpa bildo ankoraŭ devas esti tirita unue.
La ordo de operacioj decidas la tavolon
Unue venas la solvo de la bilda nomo. La kubelet, per la runtime, solvas la registran nomon, konektiĝas, aŭtentikigas, elŝutas la tavolojn kaj nur poste lanĉas la ujon. Ĉio, kion via podo faras kun VPN, okazas post tiu sinsekvo, do funkcianta tunelo en la klastro ne estas pruvo pri la tirado.
Tial kaŝmemorita bildo estas tiel konvinka mensoganto. Nodo, kiu tiris la bildon antaŭ semajnoj, daŭre servas ĝin, la deployment aspektas sana, kaj la paneo aperas nur kiam la planilo metas replikon sur pli novan nodon. Se la tempolinio de eventoj inkluzivas scale-up, anstataŭigon de nodo aŭ ĝisdatigon de pool, traktu ilin kiel ekigilon, ne kiel kaŭzon.
Tri kondiĉoj decidas la riparon
Atingebleco de privata registro el administrita node pool dependas de enkursigo, nomosolvo kaj la aro de finpunktoj. Se la subreto de la nodo ne povas enkursigi al la registra reto, neniu akreditaĵo helpos. Se ĝi enkursigas sed ne solvas la registran nomon per la DNS-vojo de la nodo, la konekto neniam komenciĝas. Se ambaŭ funkcias por la manifest-finfunkto sed ne por la blob-finfunkto al kiu la registro redirektas, la tirado paneas duonvoje.
| 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 |
Nur VNet-peering ne donas al vi aŭtomate ĉiujn gateway-transit-arangojn, kaj itinero en unu direkto ne estas funkcianta itinero. La nodo bezonas subtenatan vojon tra la celita VPN-gateway aŭ aprobita aparato, kaj la registra flanko bezonas revenan itineron al la subreto de la nodo.
Legu la paneon antaŭ ol elekti riparon
Komencu per la podaj eventoj kaj la nodo sur kiu ĝi alteriĝis, kun viaj veraj nomoj: kubectl describe pod app-example -n team-example kaj kubectl get pod app-example -n team-example -o wide. La eventa teksto distingas nesolvitan hostnomon de timeout, certifikatan rifuzon de mankanta bildo, kaj rajtigan paneon de ĉiuj aliaj. Tiuj kvar havas kvar malsamajn posedantojn.
Aŭtentikigo estas la plej trotaksata levilo. imagePullSecret donas al la runtime akreditaĵojn por la registro; ĝi ne instalas itineron, ne ŝanĝas la solvilon de la nodo kaj ne igas nefidindan certifikaton valida. Se la evento diras ke la tirado ne estis rajtigita, rigardu la amplekson de la identeco. Se ĝi diras ke la konekto tempolimis, akreditaĵoj estas nerelevantaj.
La Kubernetes-dokumentaro pri bildoj estas la referenco pri tirada konduto kaj akreditaĵoj de privataj registro, kaj indas legi ĝin unufoje antaŭ ol ŝanĝi la reton, ĉar ĝi klarigas la limon inter aŭtentikigo kaj transporto.
Konstruu la vojon sub la podo
Laboru en ĉi tiu ordo, ĉar ĉiu paŝo sensignifas ĝis la antaŭa validas. Unue enkursigu la reton de la nodo: konfirmu ke la subreto de la nodo havas subtenatan vojon al la registra reto, kontrolu la efektivajn itinerojn sur la nodo, la sekurecajn regulojn ĉe ambaŭ finoj kaj la revenan itineron ĉe la registra flanko.
Poste solvu la nomon el la kunteksto de la nodo. La solvilo de la nodo ne samas kiel la DNS-agordo de la podo, kaj sukceso ene de podo ne estas pruvo pri la gastiga runtime. Uzu administritan privatan DNS anstataŭ daŭra hosts-enskribo; la enskribo vivas ĝis la nodo anstataŭiĝos kaj tiam silente malaperas.
Poste pruvu ĉiun finpunkton. Registro povas doni al la kliento apartan aŭtentikigan servon kaj apartan blob-stokadon. Atingi la manifest-finfunkton pruvas preskaŭ nenion pri la tavoloj. Fine kompletigu TLS kaj rajtigon: certifikato valida por la registra nomo kaj fidita per subtenata noda agordo, plus tira identeco limigita al legado de tiu deponejo.
Kontrolu ĝin sur nodo kiun vi ne riparis permane
La testo kiu gravas estas freŝa tirado kaj plena elŝuto de ĉiuj tavoloj sur taŭga nodo, prefere kreita per skalado aŭ anstataŭigo. Tio kovras ĉiujn pool-ojn kiuj povus loki la workload, inkluzive tiujn kiujn vi forgesis. Permanenta riparo sur unu nodo ne estas laŭnorma modelo, kaj la sekva autoscale-evento trovos la breĉon.
Rekrei la klasteron en alia VNet povas ŝanĝi la vojon, sed tio estas la lasta rimedo, ne la unua diagnoza paŝo. Komparu la ekzistantan nodan reton kun la bezonata privata itinero kaj la subtenataj AKS-retaj kontroloj antaŭ ol proponi migradon, kaj tenu la aplikaĵan konektecon post lanĉo kiel apartan kontrolon: la podo parolanta kun sia backend estas alia kontrolo ol la nodo elŝutanta la bildon.