AKS no pot baixar la imatge d@APOS@un registre privat darrere la VPN
El kubelet baixa a través de la xarxa del node, no de la VPN del pod. Decidiu per rutes del node, DNS del node, cada endpoint que toca la baixada, i després TLS i identitat.
El vostre portàtil baixa la imatge sense problema, però el pod es queda a ImagePullBackOff i algú proposa executar el client VPN corporatiu com a sidecar. Això no ajudarà, perquè la baixada passa abans que existeixi el vostre contenidor: el kubelet demana al container runtime del node que obtingui la imatge, i el runtime fa servir l’espai de noms de xarxa del node. Una VPN dins del workload no té cap ruta per a aquest camí, i la seva pròpia imatge auxiliar encara s’ha de baixar abans.
L’ordre de les operacions decideix la capa
Primer ve la resolució del nom. El kubelet, a través del runtime, resol el nom del registre, s’hi connecta, s’autentica, baixa les capes i només després inicia el contenidor. Tot el que el pod fa amb la VPN passa després d’aquesta seqüència, i per això un túnel que funciona dins del clúster no és cap prova sobre la baixada.
Per això una imatge en memòria cau és una mentida tan convincent. Un node que va baixar la imatge fa setmanes continua servint-la, el desplegament sembla sa, i la fallada només apareix quan el planificador col·loca una rèplica en un node més nou. Si la línia de temps d’esdeveniments inclou un escalat, una substitució de node o una actualització del pool, tracteu-ho com el desencadenant, no com la causa.
Tres condicions decideixen la reparació
L’abast del registre privat des d’un pool de nodes gestionat es redueix a encaminament, resolució de noms i conjunt d’endpoints. Si la subxarxa del node no pot encaminar cap a la xarxa del registre, cap credencial no ajudarà. Si encamina però no resol el nom del registre pel camí DNS del node, la connexió no comença mai. Si tots dos funcionen per a l’endpoint de manifest però no per a l’endpoint de blob on el registre redirigeix, la baixada falla a mitges.
| 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 |
Només el peering de VNet no us dona automàticament totes les combinacions de gateway transit, i una ruta que existeix en un sentit no és una ruta que funcioni. El node necessita un camí admès pel gateway VPN previst o per un aparell aprovat, i el costat del registre necessita una ruta de retorn a la subxarxa del node.
Llegiu la fallada abans de triar la solució
Comenceu pels esdeveniments del pod i pel node on ha caigut, amb els vostres noms reals: kubectl describe pod app-example -n team-example i kubectl get pod app-example -n team-example -o wide. El text de l’esdeveniment separa un nom d’amfitrió no resolt d’un temps d’espera, un rebuig de certificat d’una imatge absent, i una fallada d’autorització de tots ells. Aquests quatre tenen quatre propietaris diferents.
L’autenticació és la palanca més sobrevalorada. imagePullSecret dona credencials del registre al runtime; no instal·la cap ruta, no canvia el resolutor del node ni fa vàlid un certificat no confiable. Si l’esdeveniment diu que la baixada no estava autoritzada, mireu l’abast de la identitat. Si diu que la connexió s’ha esgotat, les credencials són irrellevants.
La documentació d’imatges de Kubernetes és la referència sobre el comportament de baixada i les credencials de registres privats, i val la pena llegir-la un cop abans de canviar la xarxa, perquè fa explícita la frontera entre autenticació i transport.
Construïu el camí per sota del pod
Treballou en aquest ordre, perquè cada pas no té sentit fins que es compleix l’anterior. Encamineu primer la xarxa del node: confirmeu que la subxarxa té un camí admès cap a la xarxa del registre, reviseu les rutes efectives al node, les regles de seguretat als dos extrems i la ruta de retorn al costat del registre.
Després resoleu el nom des del context del node. El resolutor del node no és la configuració DNS del pod, i l’èxit dins d’un pod no és cap prova sobre el runtime de l’amfitrió. Feu servir DNS privat gestionat en lloc d’una entrada permanent a hosts; l’entrada sobreviu fins que el node es substitueix i llavors desapareix en silenci.
Després demostreu cada endpoint. Un registre pot donar al client un servei d’autenticació separat i una ubicació d’emmagatzematge blob separada. Arribar a l’endpoint de manifest no demostra gairebé res sobre les capes. Finalment, completeu TLS i autorització: un certificat vàlid per al nom del registre i confiat mitjançant una configuració de node admesa, més una identitat de baixada limitada a llegir aquest repositori.
Verifiqueu-ho en un node que no hàgiu reparat a mà
La prova que compta és una baixada nova i una descàrrega completa de totes les capes en un node apte, idealment un creat per escalat o substitució. Això cobreix tots els pools que podrien programar el workload, inclosos els que heu oblidat. Una reparació manual en un node no és un model de desplegament, i el proper esdeveniment d’autoscalat trobarà el forat.
Recrear el clúster en una altra VNet pot canviar el camí, però és l’últim recurs i no el primer pas de diagnòstic. Compareu la xarxa de nodes existent amb la ruta privada necessària i amb els controls de xarxa d’AKS admesos abans de proposar una migració, i manteniu la connectivitat de l’aplicació després de l’arrencada com una verificació separada: el pod que parla amb el seu backend és una comprovació diferent de la del node que baixa la imatge.