AKS kin gjin image helje út in privee registry efter jo VPN
De kubelet hellet fia it netwurk fan de node, net fia de VPN fan de pod. Beslis op grûn fan rûtes fan de node, node-DNS, elk endpoint dat de heling rekket, en dan TLS en identiteit.
Jo laptop hellet de image sûnder probleem, mar de pod bliuwt yn ImagePullBackOff en immen stelt foar de bedriuws-VPN-klant as sidecar te draaien. Dat helpt net, want de heling bart foardat jo container bestiet: de kubelet freget de container runtime op de node om de image te heljen, en de runtime brûkt de netwurk-namespace fan de node. In VPN yn de workload hat gjin rûte om dy wei te bieden, en syn eigen helpimage moat earst helle wurde.
De folchoarder fan operaasjes beslút de laach
Earst komt it oplossen fan de namme. De kubelet lost fia de runtime de registry-namme op, makket ferbining, autentisearret, hellet lagen en start pas dêrnei de container. Alles wat jo pod mei in VPN docht bart nei dy searje, dêrom is in tunnel dy’t yn it cluster wurket gjin bewiis oer de heling.
Dêrom is in cache-image sa’n oertsjûgjende liger. In node dy’t de image wiken lyn helle hat, bliuwt him tsjinjen, de deployment liket sûn, en de flater ferskynt pas as de scheduler in replika op in nijere node set. As de tiidline scale-up, in node-ferfanging of in pool-upgrade befettet, behannelje dy as de trigger, net as de oarsaak.
Trije betingsten beslute de reparaasje
Berikberens fan in privee registry út in beheard node pool komt del op routing, namme-oplossing en de set fan endpoints. As it subnet fan de node net nei it registry-netwurk routearje kin, helpt gjin inkelde oanmeldgegevens. As it routearret mar de registry-namme net fia it DNS-paad fan de node oplosse kin, begjint de ferbining nea. As beide wurkje foar it manifest-endpoint mar net foar it blob-endpoint dêr’t it registry nei ferwiist, mislearret de heling healwei.
| 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 |
Allinnich VNet-peering jout jo net automatysk alle gateway-transit-opstellings, en in rûte yn ien rjochting is gjin rûte dy’t wurket. De node hat in stipe paad nedich fia de bedoelde VPN-gateway of in goedkard apparaat, en de registry-kant hat in weromrûte nei it subnet fan de node nedich.
Lês de flater foardat jo in reparaasje kieze
Begjin mei de eveneminten fan de pod en de node dêr’t er op kaam, mei jo echte nammen: kubectl describe pod app-example -n team-example en kubectl get pod app-example -n team-example -o wide. De tekst fan it evenemint skift in net-oploste hostnamme fan in timeout, in sertifikaat-ôfwizing fan in ûntbrekkende image, en in autorisaasjeflater fan al dat. Dy fjouwer hawwe fjouwer ferskate eigners.
Autentikaasje is de meast oerskatte hendel. imagePullSecret jout de runtime oanmeldgegevens foar it registry; it ynstallearret gjin rûte, feroaret de resolver fan de node net en makket in net fertroud sertifikaat net jildich. As it evenemint seit dat de heling net autorisearre wie, sjoch dan nei de omfang fan de identiteit. As it seit dat de ferbining ferrûn, binne oanmeldgegevens net relevant.
De Kubernetes-dokumintaasje oer images is de referinsje foar helgedrach en oanmeldgegevens fan privee registry’s, en it is de muoite wurdich dy ien kear te lêzen foardat jo it netwurk feroarje, want it makket de grins tusken autentikaasje en ferfier dúdlik.
Bou it paad ûnder de pod
Wurkje yn dizze folchoarder, want elke stap is sinleas oant de foarige stiet. Routearje earst it netwurk fan de node: befêstigje dat it subnet in stipe paad nei it registry-netwurk hat, kontrolearje de effektive rûtes op de node, de feiligensregels oan beide kanten en de weromrûte oan de registry-kant.
Los dan de namme op út de kontekst fan de node. De resolver fan de node is net itselde as de DNS-konfiguraasje fan de pod, en sukses yn in pod is gjin bewiis oer de host-runtime. Brûk beheard privee DNS ynstee fan in permaninte hosts-ynfier; de ynfier libbet oant de node ferfongen wurdt en ferdwynt dan stil.
Bewiis dan elk endpoint. In registry kin de kliïnt in aparte autentikaasjetsjinst en in aparte blob-opslach jaan. It manifest-endpoint berikke bewist hast neat oer de lagen. Finish úteinlik TLS en autorisaasje: in sertifikaat jildich foar de registry-namme en fertroud fia stipe node-konfiguraasje, plus in helidentiteit beheind ta it lêzen fan dat repository.
Ferifiearje it op in node dy’t jo net mei de hân reparearre hawwe
De test dy’t telt is in nije heling en in folsleine download fan alle lagen op in geskikte node, leafst ien dy’t makke is troch scale of ferfanging. Dat dekt alle pools dy’t de workload pleatse kinne, ynklusyf dy’t jo fergetten. In hânreparaasje op ien node is gjin útrolmodel, en it folgjende autoscale-evenemint sil it gat fine.
It cluster opnij bouwe yn in oar VNet kin it paad feroarje, mar dat is it lêste middel en net de earste diagnostyske stap. Fergelykje it besteande node-netwurk mei de fereaske privee rûte en de stipe AKS-netwurkkontrôles foardat jo in migraasje foarstelle, en hâld de applikaasjefebining nei it opstarten as aparte ferifikaasje: de pod dy’t mei syn backend praat is in oare kontrôle as de node dy’t de image downloadt.