AKS kan ikke hente image fra et privat registry bak VPN-en din
kubelet henter gjennom nodens nettverk, ikke gjennom podens VPN. Avgjør etter nodens ruter, nodens DNS, hvert endepunkt hentingen berører, og deretter TLS og identitet.
Datamaskinen din henter image uten problemer, men poden blir stående i ImagePullBackOff. Forslaget om å kjøre selskapets VPN-klient som sidecar hjelper ikke, fordi hentingen skjer før containeren din finnes: kubelet ber container runtime på noden hente image, og runtime bruker nodens nettverksnavnerom.
Rekkefølgen av operasjoner avgjør laget
Først navneoppslag, deretter tilkobling, autentisering og nedlasting av lag, og først da starter containeren. Alt poden gjør med VPN skjer etter denne sekvensen, så en tunnel som virker i klyngen er ikke bevis om hentingen.
Derfor er et cachet image en så overbevisende løgn: en node som hentet image for uker siden leverer det fortsatt, deployment ser sunt ut, og feilen vises først når scheduler legger en replika på en nyere node. scale-up eller nodebytte er utløseren, ikke årsaken.
Tre betingelser avgjør reparasjonen
Tilgjengeligheten avhenger av ruting, navneoppslag og settet av endepunkter. Kan nodens subnett ikke rute til registry-nettverket, hjelper ingen legitimasjon. Løses ikke navnet via nodens DNS-vei, starter ikke forbindelsen. Virker bare manifest-endepunktet og ikke blob-endepunktet, feiler hentingen halvveis.
| 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 gir ikke alle gateway-transit-oppsett, og en rute i én retning er ikke en rute som virker. Noden trenger en støttet vei gjennom den tiltenkte VPN-gatewayen, og registry-siden trenger en returrute til nodens subnett.
Les feilen før du velger rettelse
Start med podens hendelser og noden den landet på, med dine ekte navn: kubectl describe pod app-example -n team-example og kubectl get pod app-example -n team-example -o wide. Hendelsesteksten skiller et uløst vertsnavn fra timeout, en sertifikatavvisning fra et manglende image, og en autorisasjonsfeil fra alt dette.
Autentisering er den mest overvurderte spaken. imagePullSecret gir runtime legitimasjon for registry; det installerer ingen rute, endrer ikke nodens resolver og gjør ikke et ikke-klarert sertifikat gyldig. Sier hendelsen at hentingen ikke var autorisert, se på identitetens omfang; sier den at forbindelsen timet ut, er legitimasjon irrelevant.
Kubernetes-dokumentasjonen om images er referansen for henteatferd og legitimasjon for private registry, og den er verdt å lese én gang før du endrer nettverket, fordi den gjør grensen mellom autentisering og transport tydelig.
Bygg veien under poden
Arbeid i denne rekkefølgen. Rut nodens nettverk først: bekreft at subnettet har en støttet vei til registry-nettverket, kontroller effektive ruter på noden, sikkerhetsreglene i begge ender og returruten på registry-siden.
Løs deretter navnet fra nodens kontekst. Nodens resolver er ikke podens DNS-oppsett, og suksess inne i en pod er ikke bevis for vertens runtime. Bruk administrert privat DNS i stedet for en permanent hosts-oppføring; oppføringen lever til noden byttes ut og forsvinner da stille.
Bevis deretter hvert endepunkt. Et registry kan gi klienten en egen autentiseringstjeneste og en egen blob-lagring. Å nå manifest-endepunktet beviser nesten ingenting om lagene. Til slutt, fullfør TLS og autorisasjon: et sertifikat gyldig for registry-navnet og klarert gjennom støttet nodekonfigurasjon, pluss en henteidentitet begrenset til å lese det repoet.
Verifiser på en node du ikke reparerte for hånd
Testen som teller er en fersk henting og full nedlasting av alle lag på en egnet node, helst en som ble laget ved skalering eller bytte. Det dekker alle pooler som kan plassere workloaden, også de glemte. En håndreparasjon på én node er ikke en utrullingsmodell, og neste autoscale-hendelse finner gapet.
Å gjenopprette klyngen i et annet VNet kan endre veien, men det er siste utvei og ikke det første diagnostiske trinnet. Sammenlign det eksisterende node-nettverket med den nødvendige private ruten og de støttede AKS-nettverkskontrollene før du foreslår migrering, og hold applikasjonsforbindelsen etter oppstart som en egen verifisering: poden som snakker med backenden er en annen kontroll enn noden som laster ned image.