AKS får ikkje henta image frå eit privat registry bak VPN-en din
kubelet hentar gjennom netverket til noden, ikkje gjennom VPN-en til poden. Avgjer etter rutene til noden, DNS-en til noden, kvar endpoint hentinga rører, og deretter TLS og identitet.
Maskinen din hentar image utan problem, men poden blir ståande i ImagePullBackOff. Framlegget om å køyre VPN-klienten til selskapet som sidecar hjelper ikkje, fordi hentinga skjer før containeren din finst: kubelet ber container runtime på noden hente image, og runtime brukar nettverksnamnerommet til noden.
Rekkjefølgja av operasjonar avgjer laget
Først namneoppslag, deretter tilkopling, autentisering og nedlasting av lag, og først då startar containeren. Alt poden gjer med VPN skjer etter denne sekvensen, så ein tunnel som verkar i klynga er ikkje prov om hentinga.
Difor er eit cacha image ei så overtydande løgn: ein node som henta image for veker sidan leverer det framleis, deployment ser sunt ut, og feilen viser seg først når scheduler legg ein replika på ein nyare node. scale-up eller nodebyte er utløysaren, ikkje årsaka.
Tre vilkår avgjer reparasjonen
Tilgjengelegheita kjem an på ruting, namneoppslag og settet av endpoint. Kan ikkje subnettet til noden rute til registry-nettverket, hjelper ingen legitimasjon. Blir ikkje namnet løyst via DNS-vegen til noden, startar ikkje sambandet. Verkar berre manifest-endepunktet og ikkje blob-endepunktet, feilar hentinga halvvegs.
| 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 åleine gjev ikkje alle gateway-transit-oppsett, og ei rute i éi retning er ikkje ei rute som verkar. Noden treng ein støtta veg gjennom den tiltenkte VPN-gatewayen, og registry-sida treng ei returrute til subnettet til noden.
Les feilen før du vel retting
Start med hendingane til poden og noden han landa på, med dine ekte namn: kubectl describe pod app-example -n team-example og kubectl get pod app-example -n team-example -o wide. Hendingsteksten skil eit uløyst vertsnamn frå timeout, ei sertifikatavvising frå eit manglande image, og ein autorisasjonsfeil frå alt dette.
Autentisering er den mest overvurderte spaken. imagePullSecret gjev runtime legitimasjon for registry; det installerer inga rute, endrar ikkje resolveren til noden og gjer ikkje eit ikkje-klart sertifikat gyldig. Seier hendinga at hentinga ikkje var autorisert, sjå på omfanget til identiteten; seier ho at sambandet tima ut, er legitimasjon irrelevant.
Kubernetes-dokumentasjonen om images er referansen for henteåtferd og legitimasjon for private registry, og han er verdt å lese éin gong før du endrar netverket, fordi han gjer grensa mellom autentisering og transport tydeleg.
Bygg vegen under poden
Arbeid i denne rekkjefølgja. Rut netverket til noden først: stadfest at subnettet har ein støtta veg til registry-nettverket, kontroller effektive ruter på noden, sikkerheitsreglane i begge endar og returruta på registry-sida.
Løys deretter namnet frå konteksten til noden. Resolveren til noden er ikkje DNS-oppsettet til poden, og suksess inne i ein pod er ikkje prov for runtime på verten. Bruk administrert privat DNS i staden for ei permanent hosts-oppføring; oppføringa lever til noden blir bytt ut og forsvinn då stille.
Prov deretter kvart endpoint. Eit registry kan gje klienten ein eigen autentiseringsteneste og ei eiga blob-lagring. Å nå manifest-endepunktet provar nesten ingenting om laga. Til slutt, fullfør TLS og autorisasjon: eit sertifikat gyldig for registry-namnet og klarert gjennom støtta nodekonfigurasjon, pluss ein henteidentitet avgrensa til å lese det repoet.
Verifiser på ein node du ikkje reparerte for hand
Testen som tel er ei fersk henting og full nedlasting av alle lag på ein eigna node, helst ein som vart laga ved skalering eller byte. Det dekkjer alle poolar som kan plassere workloaden, også dei gløymde. Ein handreparasjon på éin node er ikkje ein utrullingsmodell, og neste autoscale-hending finn gapet.
Å byggje klynga opp att i eit anna VNet kan endre vegen, men det er siste utveg og ikkje det første diagnostiske steget. Samanlikn det eksisterande node-nettverket med den nødvendige private ruta og dei støtta AKS-nettverkskontrollane før du føreslår migrering, og hald applikasjonssambandet etter oppstart som ei eiga verifisering: poden som snakkar med backenden sin er ein annan kontroll enn noden som lastar ned image.