AKS ne peut pas tirer l@APOS@image d@APOS@un registre privé derrière votre VPN
Le kubelet tire via le réseau du node, pas via le VPN du pod. Décidez d@APOS@après les routes du node, le DNS du node, chaque endpoint touché par le tirage, puis TLS et identité.
Votre portable tire l’image sans problème, mais le pod reste en ImagePullBackOff et quelqu’un propose de lancer le client VPN d’entreprise en sidecar. Cela n’aidera pas, car le tirage a lieu avant que votre conteneur existe : le kubelet demande au runtime du node de récupérer l’image, et le runtime utilise l’espace de noms réseau du node. Un VPN dans le workload n’a aucune route à offrir à ce chemin, et sa propre image auxiliaire doit d’abord être tirée.
L’ordre des opérations décide de la couche
La résolution du nom vient d’abord. Le kubelet, via le runtime, résout le nom du registre, se connecte, s’authentifie, télécharge les couches et ne démarre le conteneur qu’ensuite. Tout ce que votre pod fait avec un VPN arrive après cette séquence, donc un tunnel qui fonctionne dans le cluster ne prouve rien sur le tirage.
C’est pourquoi une image en cache est un mensonge si convaincant. Un node qui a tiré l’image il y a des semaines continue de la servir, le déploiement semble sain, et la panne n’apparaît que lorsque le planificateur place une réplique sur un node plus récent. Si la chronologie contient un scale-up, un remplacement de node ou une mise à niveau de pool, traitez-les comme le déclencheur, pas la cause.
Trois conditions décident de la réparation
L’accessibilité d’un registre privé depuis un pool géré se résume au routage, à la résolution de noms et à l’ensemble des endpoints. Si le sous-réseau du node ne peut pas router vers le réseau du registre, aucun identifiant n’aidera. S’il route mais ne résout pas le nom via le chemin DNS du node, la connexion ne démarre jamais. Si les deux marchent pour l’endpoint manifest mais pas pour l’endpoint blob vers lequel le registre redirige, le tirage échoue à mi-chemin.
| 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 |
Le peering VNet seul ne donne pas automatiquement toutes les combinaisons de gateway transit, et une route qui existe dans un sens n’est pas une route qui fonctionne. Le node a besoin d’un chemin pris en charge via la passerelle VPN prévue ou un équipement approuvé, et le côté registre a besoin d’une route de retour vers le sous-réseau du node.
Lisez la panne avant de choisir un correctif
Commencez par les événements du pod et le node où il a atterri, avec vos vrais noms : kubectl describe pod app-example -n team-example et kubectl get pod app-example -n team-example -o wide. Le texte de l’événement distingue un nom d’hôte non résolu d’un timeout, un rejet de certificat d’une image absente, et un échec d’autorisation de tout cela. Ces quatre ont quatre propriétaires différents.
L’authentification est le levier le plus surestimé. imagePullSecret fournit au runtime les identifiants du registre ; il n’installe pas de route, ne change pas le résolveur du node et ne rend pas valide un certificat non fiable. Si l’événement dit que le tirage n’était pas autorisé, regardez la portée de l’identité. S’il dit que la connexion a expiré, les identifiants sont sans objet.
La documentation Kubernetes sur les images est la référence pour le comportement de tirage et les identifiants de registres privés, et elle vaut une lecture avant de changer le réseau, car elle rend explicite la frontière entre authentification et transport.
Construisez le chemin sous le pod
Travaillez dans cet ordre, car chaque étape n’a pas de sens tant que la précédente ne tient pas. Routez d’abord le réseau du node : confirmez que le sous-réseau a un chemin pris en charge vers le réseau du registre, vérifiez les routes effectives sur le node, les règles de sécurité aux deux extrémités et la route de retour côté registre.
Résolvez ensuite le nom depuis le contexte du node. Le résolveur du node n’est pas la configuration DNS du pod, et un succès dans un pod ne prouve rien sur le runtime hôte. Utilisez un DNS privé géré plutôt qu’une entrée hosts permanente ; l’entrée survit jusqu’au remplacement du node puis disparaît en silence.
Prouvez ensuite chaque endpoint. Un registre peut fournir au client un service d’authentification distinct et un stockage blob distinct. Atteindre l’endpoint manifest ne prouve presque rien sur les couches. Enfin, terminez TLS et autorisation : un certificat valide pour le nom du registre et approuvé via une configuration de node prise en charge, plus une identité de tirage limitée à la lecture de ce dépôt.
Vérifiez sur un node que vous n’avez pas réparé à la main
Le test qui compte est un tirage neuf et un téléchargement complet de toutes les couches sur un node éligible, idéalement créé par scale-up ou remplacement. Cela couvre tous les pools qui pourraient placer le workload, y compris ceux oubliés. Une réparation manuelle sur un seul node n’est pas un modèle de déploiement, et le prochain événement d’autoscaling trouvera la faille.
Recréer le cluster dans un autre VNet peut changer le chemin, mais c’est le dernier recours et non le premier pas de diagnostic. Comparez le réseau de nodes existant avec la route privée requise et les contrôles réseau AKS pris en charge avant de proposer une migration, et gardez la connectivité de l’application après le démarrage comme vérification distincte : le pod qui parle à son backend est un autre contrôle que le node qui télécharge l’image.