AKS kann kein Image aus einer privaten Registry hinter deinem VPN ziehen
Der kubelet zieht über das Node-Netzwerk, nicht über das VPN des Pods. Entscheide anhand der Routen des Nodes, des Node-DNS, jedes Endpunkts, den der Pull berührt, dann TLS und Identität.
Dein Laptop zieht das Image problemlos, der Pod hängt aber in ImagePullBackOff, und jemand schlägt vor, den Firmen-VPN-Client als Sidecar laufen zu lassen. Das hilft nicht, denn der Pull passiert, bevor dein Container existiert: Der kubelet bittet die Container-Runtime auf dem Node, das Image zu holen, und die Runtime nutzt den Netzwerk-Namespace des Nodes. Ein VPN im Workload hat für diesen Weg keine Route, und sein eigenes Hilfs-Image müsste zuerst gezogen werden.
Die Reihenfolge der Operationen entscheidet die Ebene
Zuerst kommt die Namensauflösung. Der kubelet löst über die Runtime den Registry-Namen auf, verbindet sich, authentifiziert, lädt Layer herunter und startet erst danach den Container. Alles, was dein Pod mit einem VPN tut, geschieht nach dieser Kette, deshalb ist ein funktionierender Tunnel im Cluster kein Beweis für den Pull.
Darum ist ein gecachtes Image ein so überzeugender Lügner. Ein Node, der das Image vor Wochen gezogen hat, liefert es weiter, das Deployment wirkt gesund, und der Fehler zeigt sich erst, wenn der Scheduler eine Replik auf einen neueren Node legt. Stehen im Ereignisverlauf ein Scale-up, ein Node-Austausch oder ein Pool-Upgrade, behandle sie als Auslöser, nicht als Ursache.
Drei Bedingungen entscheiden die Reparatur
Erreichbarkeit einer privaten Registry aus einem verwalteten Node-Pool läuft auf Routing, Namensauflösung und die Menge der Endpunkte hinaus. Kann das Node-Subnetz nicht ins Registry-Netz routen, hilft keine Anmeldung. Löst es den Namen nicht über den DNS-Pfad des Nodes auf, beginnt die Verbindung nie. Funktioniert beides für den Manifest-Endpunkt, aber nicht für den Blob-Endpunkt, auf den die Registry weiterleitet, bricht der Pull auf halbem Weg ab.
| 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 allein schenkt dir nicht jede Gateway-Transit-Konstellation, und eine Route in eine Richtung ist keine funktionierende Route. Der Node braucht einen unterstützten Pfad über das vorgesehene VPN-Gateway oder eine freigegebene Appliance, und die Registry-Seite braucht eine Rückroute zum Node-Subnetz.
Lies den Fehler, bevor du eine Lösung wählst
Beginne mit den Pod-Events und dem Node, auf dem er gelandet ist, mit deinen echten Namen: kubectl describe pod app-example -n team-example und kubectl get pod app-example -n team-example -o wide. Der Event-Text trennt einen unaufgelösten Hostnamen von einem Timeout, eine Zertifikatsablehnung von einem fehlenden Image und einen Autorisierungsfehler von allem anderen. Diese vier haben vier verschiedene Eigentümer.
Authentifizierung ist der am meisten überschätzte Hebel. imagePullSecret gibt der Runtime Zugangsdaten für die Registry; es installiert keine Route, ändert nicht den Resolver des Nodes und macht ein nicht vertrauenswürdiges Zertifikat nicht gültig. Sagt das Event, der Pull sei nicht autorisiert gewesen, prüfe den Umfang der Identität. Sagt es, die Verbindung sei abgelaufen, sind Zugangsdaten irrelevant.
Die Kubernetes-Dokumentation zu Images ist die Referenz für Pull-Verhalten und Zugangsdaten privater Registries, und es lohnt sich, sie einmal zu lesen, bevor du das Netzwerk änderst, weil sie die Grenze zwischen Authentifizierung und Transport klar macht.
Baue den Pfad unter dem Pod
Arbeite in dieser Reihenfolge, denn jeder Schritt ist sinnlos, bis der vorige hält. Route zuerst das Node-Netzwerk: bestätige, dass das Node-Subnetz einen unterstützten Pfad ins Registry-Netz hat, prüfe die effektiven Routen auf dem Node, die Sicherheitsregeln an beiden Enden und die Rückroute auf der Registry-Seite.
Dann löse den Namen aus dem Kontext des Nodes auf. Der Resolver des Nodes ist nicht die DNS-Konfiguration des Pods, und Erfolg in einem Pod ist kein Beweis für die Host-Runtime. Nutze verwaltetes privates DNS statt eines dauerhaften Eintrags in hosts; der Eintrag überlebt bis zum Node-Austausch und verschwindet dann still.
Dann beweise jeden Endpunkt. Eine Registry kann dem Client einen eigenen Authentifizierungsdienst und einen eigenen Blob-Speicher geben. Den Manifest-Endpunkt zu erreichen beweist fast nichts über die Layer. Zum Schluss TLS und Autorisierung: ein Zertifikat, gültig für den Registry-Namen und vertrauenswürdig über unterstützte Node-Konfiguration, plus eine Pull-Identität, die auf das Lesen dieses Repositorys beschränkt ist.
Prüfe es auf einem Node, den du nicht von Hand repariert hast
Der Test, der zählt, ist ein frischer Pull und ein vollständiger Download aller Layer auf einem geeigneten Node, am besten einem per Skalierung oder Austausch erzeugten. Das deckt alle Pools ab, die den Workload platzieren könnten, auch die vergessenen. Eine Handreparatur auf einem Node ist kein Deployment-Modell, und das nächste Autoscale-Ereignis findet die Lücke.
Den Cluster in einem anderen VNet neu zu bauen kann den Pfad ändern, ist aber der letzte Ausweg und nicht der erste Diagnoseschritt. Vergleiche das bestehende Node-Netzwerk mit der nötigen privaten Route und den unterstützten AKS-Netzwerksteuerungen, bevor du eine Migration vorschlägst, und halte die Anwendungskonnektivität nach dem Start als eigene Prüfung: Der Pod, der mit seinem Backend spricht, ist eine andere Kontrolle als der Node, der das Image herunterlädt.