Az AKS nem tud képet húzni a VPN mögötti privát registryből
A kubelet a node hálózatán keresztül húz, nem a pod VPN-jén. A node útvonalai, a node DNS-e, a húzás minden érintett endpointja, majd a TLS és az identitás dönt.
A laptopod gond nélkül húzza a képet, a pod viszont ImagePullBackOff állapotban marad, és valaki azt javasolja, hogy futtasd a céges VPN klienst sidecarként. Ez nem segít, mert a húzás még a konténer létrejötte előtt történik: a kubelet a node container runtime-jától kéri a képet, a runtime pedig a node hálózati névterét használja.
A műveletek sorrendje dönti el a réteget
Először a kép nevének feloldása jön, majd a kapcsolódás, a hitelesítés és a rétegek letöltése, és csak ezután indul a konténer. Minden, amit a pod VPN-nel tesz, e sorozat után történik, ezért egy működő alagút a klaszterben nem bizonyíték a húzásra.
Ezért olyan meggyőző hazugság a cache-elt kép: a hetekkel korábban húzó node továbbra is kiszolgálja, a deployment egészségesnek látszik, és a hiba csak akkor jelenik meg, amikor az ütemező egy újabb node-ra tesz replikát. A scale-up vagy a node-csere okozat, nem ok.
Három feltétel dönti el a javítást
Az elérés az útvonalakon, a névfeloldáson és az endpointok halmazán múlik. Ha a node alhálózata nem tud a registry hálózatára route-olni, semmilyen hitelesítő adat nem segít. Ha a név nem oldódik fel a node DNS-útján, a kapcsolat el sem indul. Ha csak a manifest endpoint érhető el, a blob nem, a húzás félúton elakad.
| 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 |
Az önmagában vett VNet peering nem ad minden gateway transit elrendezést, és az egyirányú útvonal nem működő útvonal. A node-nak támogatott útvonal kell a tervezett VPN gatewayen át, a registry oldalának pedig visszaút a node alhálózatába.
Olvasd el a hibát, mielőtt javítást választasz
Kezdd a pod eseményeivel és a node-dal, ahová került, a valódi neveiddel: kubectl describe pod app-example -n team-example és kubectl get pod app-example -n team-example -o wide. Az esemény szövege megkülönbözteti a fel nem oldott hostnevet a timeouttól, a tanúsítvány elutasítását a hiányzó képtől, és az engedélyezési hibát mindezektől.
A hitelesítés a leginkább túlértékelt eszköz. A imagePullSecret hitelesítő adatokat ad a runtime-nak a registryhez; nem telepít útvonalat, nem változtatja meg a node resolverét, és nem tesz érvényessé egy nem megbízható tanúsítványt. Ha az esemény szerint a húzás nem volt engedélyezett, az identitás hatókörét nézd; ha a kapcsolat lejárt, a hitelesítő adatok lényegtelenek.
A Kubernetes képekről szóló dokumentációja a húzási viselkedés és a privát registry hitelesítő adatok referenciája, és érdemes egyszer elolvasni a hálózat módosítása előtt, mert világossá teszi a hitelesítés és a szállítás határát.
Építsd fel az útvonalat a pod alatt
Ebben a sorrendben dolgozz. Először route-old a node hálózatát: igazold, hogy az alhálózatnak van támogatott útja a registry hálózatába, ellenőrizd a node tényleges útvonalait, a két vég biztonsági szabályait és a registry oldali visszautat.
Utána oldd fel a nevet a node kontextusából. A node resolver nem azonos a pod DNS-konfigurációjával, és a podon belüli siker nem bizonyíték a host runtime-ra. Használj menedzselt privát DNS-t tartós hosts-bejegyzés helyett; a bejegyzés a node cseréjéig él, majd csendben eltűnik.
Utána bizonyíts minden endpointot. A registry külön hitelesítési szolgáltatást és külön blob-tárolót adhat a kliensnek. A manifest endpoint elérése szinte semmit nem bizonyít a rétegekről. Végül fejezd be a TLS-t és az engedélyezést: a registry nevére érvényes, támogatott node-konfiguráción keresztül megbízható tanúsítvány, valamint az adott repó olvasására korlátozott húzási identitás.
Ellenőrizd egy olyan node-on, amelyet nem javítottál kézzel
Az igazi teszt egy friss húzás és az összes réteg teljes letöltése megfelelő node-on, lehetőleg skálázással vagy cserével létrehozotton. Ez lefedi az összes poolt, amely a workloadot elhelyezheti, a kihagyottakat is. Az egy node-on végzett kézi javítás nem telepítési modell, és a következő autoscale esemény megtalálja a rést.
A klaszter újbóli létrehozása másik VNetben megváltoztathatja az útvonalat, de ez az utolsó eszköz, nem az első diagnosztikai lépés. Hasonlítsd össze a meglévő node-hálózatot a szükséges privát útvonallal és a támogatott AKS hálózati vezérlőkkel, mielőtt migrációt javasolsz, és az alkalmazás kapcsolatát indítás után külön ellenőrzésként kezeld: a pod és a backendje beszélgetése más ellenőrzés, mint a node képletöltése.