AKS kan inte hämta image från ett privat registry bakom din VPN
kubelet hämtar via nodens nätverk, inte via poddens VPN. Avgör efter nodens rutter, nodens DNS, varje endpoint hämtningen rör, och sedan TLS och identitet.
Din laptop hämtar imagen utan problem, men podden blir kvar i ImagePullBackOff och någon föreslår att köra företagets VPN-klient som sidecar. Det hjälper inte, eftersom hämtningen sker innan din container finns: kubelet ber container runtime på noden hämta imagen, och runtime använder nodens nätverksnamnrymd.
Ordningen av operationer avgör lagret
Först namnmatchning, sedan anslutning, autentisering, nedladdning av lager och först därefter startar containern. Allt podden gör med VPN sker efter den sekvensen, så en tunnel som fungerar i klustret är inte bevis om hämtningen.
Därför är en cachad image en så övertygande lögn: en nod som hämtade imagen för veckor sedan fortsätter leverera den, deployment ser frisk ut, och felet syns först när schemaläggaren placerar en replik på en nyare nod. scale-up eller nodbyte är utlösaren, inte orsaken.
Tre villkor avgör åtgärden
Tillgängligheten kokar ner till routing, namnmatchning och uppsättningen endpoints. Kan nodens subnät inte routa till registryts nätverk hjälper inga uppgifter. Löses namnet inte via nodens DNS-väg börjar anslutningen aldrig. Fungerar bara manifest-endpointen och inte blob-endpointen misslyckas hämtningen halvvägs.
| 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 |
Enbart VNet-peering ger inte alla gateway-transit-uppsättningar, och en rutt i en riktning är inte en rutt som fungerar. Noden behöver en stödd väg genom den avsedda VPN-gatewayen, och registry-sidan en returrutt till nodens subnät.
Läs felet innan du väljer åtgärd
Börja med poddens händelser och noden den landade på, med dina riktiga namn: kubectl describe pod app-example -n team-example och kubectl get pod app-example -n team-example -o wide. Händelsetexten skiljer ett olöst värdnamn från timeout, en certifikatavvisning från en saknad image, och ett auktoriseringsfel från allt detta.
Autentisering är den mest överskattade spaken. imagePullSecret ger runtime uppgifter för registryt; det installerar ingen rutt, ändrar inte nodens resolver och gör inte ett ej betrott certifikat giltigt. Säger händelsen att hämtningen inte var auktoriserad, titta på identitetens omfattning; säger den att anslutningen tog timeout är uppgifterna irrelevanta.
Kubernetes dokumentation om images är referensen för hämtningsbeteende och uppgifter för privata registryn, och den är värd en läsning innan du ändrar nätverket, eftersom den tydliggör gränsen mellan autentisering och transport.
Bygg vägen under podden
Arbeta i den här ordningen. Rota först nodens nätverk: bekräfta att subnätet har en stödd väg till registryts nätverk, kontrollera effektiva rutter på noden, säkerhetsreglerna i båda ändar och returrutten på registry-sidan.
Lös sedan namnet från nodens kontext. Nodens resolver är inte poddens DNS-konfiguration, och framgång i en podd är inte bevis för värdens runtime. Använd hanterad privat DNS i stället för en permanent hosts-post; posten lever tills noden byts ut och försvinner sedan tyst.
Bevisa sedan varje endpoint. Ett registry kan ge klienten en egen autentiseringstjänst och en egen bloblagring. Att nå manifest-endpointen bevisar nästan inget om lagren. Avsluta med TLS och auktorisering: ett certifikat giltigt för registryts namn och betrott via stödd nodkonfiguration, plus en hämtidentitet begränsad till att läsa det repot.
Verifiera på en nod du inte reparerade för hand
Testet som räknas är en färsk hämtning och full nedladdning av alla lager på en lämplig nod, helst en som skapats genom skalning eller byte. Det täcker alla pooler som kan placera workloaden, även de glömda. En handreparation på en nod är inte en utrullningsmodell, och nästa autoscale-händelse hittar luckan.
Att återskapa klustret i ett annat VNet kan ändra vägen, men det är sista utvägen och inte första diagnostiska steget. Jämför det befintliga nodnätverket med den nödvändiga privata rutten och de stödda AKS-nätverkskontrollerna innan du föreslår en migrering, och håll applikationsanslutningen efter start som en separat verifiering: podden som talar med sin backend är en annan kontroll än noden som laddar ner imagen.