AKS kan geen image trekken uit een private registry achter je VPN
De kubelet trekt via het netwerk van de node, niet via de VPN van de pod. Beslis op basis van de routes van de node, de DNS van de node, elk endpoint dat de pull raakt, en dan TLS en identiteit.
Je laptop trekt de image zonder problemen, maar de pod blijft in ImagePullBackOff hangen en iemand stelt voor de zakelijke VPN-client als sidecar te draaien. Dat helpt niet, want de pull gebeurt voordat je container bestaat: de kubelet vraagt de container runtime op de node om de image te halen, en de runtime gebruikt de netwerknamespace van de node.
De volgorde van bewerkingen bepaalt de laag
Eerst naamresolutie, dan verbinden, authenticeren en lagen downloaden, en pas daarna start de container. Alles wat je pod met een VPN doet, gebeurt daarna, dus een tunnel die in het cluster werkt is geen bewijs over de pull.
Daarom is een gecachte image zo’n overtuigende leugen: een node die de image weken geleden trok blijft hem leveren, de deployment lijkt gezond, en de fout verschijnt pas als de scheduler een replica op een nieuwere node plaatst. scale-up of nodevervanging is de trigger, niet de oorzaak.
Drie voorwaarden bepalen de reparatie
Bereikbaarheid komt neer op routing, naamresolutie en de set endpoints. Kan het subnet van de node niet naar het registry-netwerk routeren, dan helpt geen enkele credential. Wordt de naam niet via het DNS-pad van de node opgelost, dan begint de verbinding nooit. Werkt alleen het manifest-endpoint en niet het blob-endpoint, dan faalt de pull halverwege.
| 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 |
Alleen VNet-peering geeft niet elke gateway-transit-opstelling, en een route in één richting is geen route die werkt. De node heeft een ondersteund pad nodig via de bedoelde VPN-gateway, en de registry-kant een retourroute naar het subnet van de node.
Lees de fout voordat je een oplossing kiest
Begin bij de events van de pod en de node waar hij landde, met je echte namen: kubectl describe pod app-example -n team-example en kubectl get pod app-example -n team-example -o wide. De eventtekst onderscheidt een onopgeloste hostnaam van een timeout, een certificaatweigering van een ontbrekende image, en een autorisatiefout van alle drie.
Authenticatie is de meest overschatte hefboom. imagePullSecret geeft de runtime credentials voor het registry; het installeert geen route, verandert de resolver van de node niet en maakt een niet-vertrouwd certificaat niet geldig. Zegt de event dat de pull niet geautoriseerd was, kijk dan naar de scope van de identiteit; zegt hij dat de verbinding verliep, dan doen credentials er niet toe.
De Kubernetes-documentatie over images is de referentie voor pullgedrag en credentials van private registry’s, en het loont die één keer te lezen voordat je het netwerk wijzigt, omdat ze de grens tussen authenticatie en transport expliciet maakt.
Bouw het pad onder de pod
Werk in deze volgorde. Route eerst het netwerk van de node: bevestig dat het subnet een ondersteund pad naar het registry-netwerk heeft, controleer de effectieve routes op de node, de beveiligingsregels aan beide kanten en de retourroute aan de registry-kant.
Los daarna de naam op vanuit de context van de node. De resolver van de node is niet de DNS-configuratie van de pod, en succes in een pod is geen bewijs voor de host-runtime. Gebruik beheerde private DNS in plaats van een permanente hosts-regel; die regel leeft tot de node vervangen wordt en verdwijnt dan stil.
Bewijs daarna elk endpoint. Een registry kan de client een aparte authenticatiedienst en een aparte blob-opslag geven. Het manifest-endpoint bereiken bewijst bijna niets over de lagen. Rond ten slotte TLS en autorisatie af: een certificaat geldig voor de registry-naam en vertrouwd via ondersteunde nodeconfiguratie, plus een pull-identiteit beperkt tot het lezen van dat repo.
Verifieer op een node die je niet met de hand hebt gerepareerd
De test die telt is een verse pull en een volledige download van alle lagen op een geschikte node, liefst een die door scaling of vervanging is gemaakt. Dat dekt alle pools die de workload kunnen plaatsen, ook de vergeten. Een handmatige reparatie op één node is geen uitrolmodel, en de volgende autoscale-gebeurtenis vindt het gat.
De cluster opnieuw bouwen in een ander VNet kan het pad veranderen, maar dat is het laatste redmiddel en niet de eerste diagnostische stap. Vergelijk het bestaande node-netwerk met de vereiste private route en de ondersteunde AKS-netwerkbesturingen voordat je een migratie voorstelt, en houd de applicatieconnectiviteit na de start als aparte verificatie: de pod die met zijn backend praat is een andere controle dan de node die de image downloadt.