AKS kan ikke hente image fra et privat registry bag din VPN
kubelet henter gennem nodens netværk, ikke gennem podens VPN. Afgør efter nodens ruter, nodens DNS, hvert endpoint hentningen rammer, og derefter TLS og identitet.
Din bærbare henter image uden problemer, men poden bliver stående i ImagePullBackOff, og nogen foreslår at køre virksomhedens VPN-klient som sidecar. Det hjælper ikke, for hentningen sker før din container findes: kubelet beder container runtime på noden om at hente image, og runtime bruger nodens netværksnamespace. En VPN inde i workloadet har ingen rute at tilbyde den vej, og dets eget hjælpe-image skal stadig hentes først.
Rækkefølgen af operationer afgør laget
Først kommer navneopløsningen. kubelet opløser registry-navnet gennem runtime, forbinder, autentificerer, henter lag og starter først derefter containeren. Alt poden gør med en VPN sker efter den sekvens, og derfor er en tunnel der virker i klyngen ikke bevis om hentningen.
Derfor er et cachet image så overbevisende en løgner. En node der hentede image for uger siden bliver ved med at levere det, deployment ser sundt ud, og fejlen viser sig først når scheduleren placerer en replika på en nyere node. Hvis hændelseslinjen indeholder scale-up, udskiftning af node eller pool-opgradering, så behandl dem som udløser, ikke årsag.
Tre betingelser afgør reparationen
Adgang til et privat registry fra en administreret node pool afhænger af routing, navneopløsning og sættet af endpoints. Kan nodens subnet ikke route til registry-netværket, hjælper ingen legitimationsoplysninger. Kan det route, men ikke opløse registry-navnet via nodens DNS-vej, starter forbindelsen aldrig. Virker begge for manifest-endpointet men ikke for blob-endpointet som registry videresender til, fejler hentningen halvvejs.
| 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 alene giver dig ikke automatisk alle gateway-transit-opstillinger, og en rute der findes i én retning er ikke en rute der virker. Noden har brug for en understøttet vej gennem den tilsigtede VPN-gateway eller en godkendt enhed, og registry-siden har brug for en returrute til nodens subnet.
Læs fejlen før du vælger en rettelse
Begynd med podens hændelser og den node den landede på, med dine rigtige navne: kubectl describe pod app-example -n team-example og kubectl get pod app-example -n team-example -o wide. Hændelsesteksten skelner et uopløst værtsnavn fra en timeout, en certifikatafvising fra et manglende image og en autorisationsfejl fra dem alle. De fire har fire forskellige ejere.
Autentificering er den mest overvurderede håndtag. imagePullSecret giver runtime legitimationsoplysninger til registryet; det installerer ikke en rute, ændrer ikke nodens resolver og gør ikke et ikke-betroet certifikat gyldigt. Siger hændelsen at hentningen var uautoriseret, se på identitetens omfang. Siger den at forbindelsen timede ud, er legitimationsoplysninger irrelevante.
Kubernetes-dokumentationen om images er reference for henteadfærd og legitimationsoplysninger til private registryer, og den er værd at læse én gang før du ændrer netværk, fordi den gør grænsen mellem autentificering og transport tydelig.
Byg vejen under poden
Arbejd i denne rækkefølge, fordi hvert skridt er meningsløst indtil det forrige holder. Route nodens netværk først: bekræft at nodens subnet har en understøttet vej til registry-netværket, kontroller de effektive ruter på noden, sikkerhedsreglerne i begge ender og returruten på registry-siden.
Opløs derefter navnet fra nodens kontekst. Nodens resolver er ikke det samme som podens DNS-konfiguration, og succes inde i en pod er ikke bevis om værts-runtime. Brug administreret privat DNS i stedet for en permanent hosts-post; posten overlever indtil noden udskiftes og forsvinder så lydløst.
Bevis derefter hvert endpoint. Et registry kan give klienten en separat autentificeringstjeneste og en separat blob-lagring. At nå manifest-endpointet beviser næsten intet om lagene. Til sidst, fuldfør TLS og autorisation: et certifikat gyldigt for registry-navnet og betroet gennem understøttet node-konfiguration, plus en henteidentitet begrænset til at læse det repository.
Verificer det på en node du ikke reparerede i hånden
Testen der tæller er en frisk hentning og fuld download af alle lag på en egnet node, helst en der blev oprettet ved skalering eller udskiftning. Det dækker alle pools der kan placere workloadet, inklusive dem du glemte. En manuel rettelse på én node er ikke en udrulningsmodel, og den næste autoscale-hændelse finder hullet.
At genskabe klyngen i et andet VNet kan ændre vejen, men det er den sidste udvej snarere end det første diagnostiske skridt. Sammenlign det eksisterende node-netværk med den krævede private rute og de understøttede AKS-netværkskontroller, før du foreslår en migrering, og hold applikationsforbindelsen efter opstart som en separat verifikation: poden der taler med sin backend er en anden kontrol end noden der downloader image.