Laptopul tău trage imaginea fără probleme, dar podul rămâne în ImagePullBackOff și cineva propune rularea clientului VPN corporativ ca sidecar. Nu ajută, pentru că descărcarea are loc înainte să existe containerul: kubelet cere container runtime-ului de pe nod să aducă imaginea, iar runtime-ul folosește spațiul de nume de rețea al nodului.

Ordinea operațiunilor decide stratul

Mai întâi rezolvarea numelui, apoi conexiunea, autentificarea, descărcarea straturilor și abia apoi pornirea containerului. Tot ce face podul cu VPN se întâmplă după această secvență, deci un tunel care funcționează în cluster nu este dovadă despre descărcare.

De aceea o imagine din cache este o minciună atât de convingătoare: un nod care a tras imaginea acum câteva săptămâni o servește în continuare, deployment-ul pare sănătos, iar defecțiunea apare doar când planificatorul pune o replică pe un nod mai nou. scale-up sau înlocuirea nodului este declanșatorul, nu cauza.

Trei condiții decid remedierea

Accesibilitatea se reduce la rutare, rezolvarea numelor și setul de endpoint-uri. Dacă subnetul nodului nu poate ruta către rețeaua registry-ului, nicio credențială nu ajută. Dacă numele nu se rezolvă prin DNS-ul nodului, conexiunea nu începe. Dacă răspunde doar manifestul, iar blob-ul nu, descărcarea eșuează la jumătate.

ConditionTypical symptomWhere to look
Node subnet has no route to the registry networkTimeout, no connectionEffective routes on the node NIC, gateway transit, return path on-premises
Node resolver cannot see the private zoneName resolution failure in eventsVNet DNS settings and the resolver the node actually uses
Only the manifest endpoint is reachableAuth succeeds, layer download failsEvery hostname the registry hands out during the pull
TLS or identity is wrongCertificate error, 401 or 403Server certificate name and trust, scoped pull identity

Doar VNet peering nu oferă toate configurațiile gateway transit, iar o rută într-o singură direcție nu este o rută funcțională. Nodul are nevoie de o cale susținută prin VPN gateway-ul prevăzut, iar partea de registry de o rută de întoarcere către subnetul nodului.

Citește defecțiunea înainte de a alege remedierea

Începe cu evenimentele podului și cu nodul pe care a ajuns, cu numele reale: kubectl describe pod app-example -n team-example și kubectl get pod app-example -n team-example -o wide. Textul evenimentului separă un hostname nerezolvat de un timeout, un refuz de certificat de o imagine lipsă și o eroare de autorizare de toate acestea.

Autentificarea este pârghia cea mai supraevaluată. imagePullSecret oferă runtime-ului credențialele registry-ului; nu instalează o rută, nu schimbă resolver-ul nodului și nu face valid un certificat neîncrezut. Dacă evenimentul spune că descărcarea nu a fost autorizată, uită-te la aria identității; dacă spune că conexiunea a expirat, credențialele sunt irelevante.

Documentația Kubernetes despre imagini este referința pentru comportamentul descărcării și credențialele registry-urilor private, și merită citită o dată înainte de a schimba rețeaua, pentru că face explicită granița dintre autentificare și transport.

Construiește calea sub pod

Lucrează în această ordine. Mai întâi rutează rețeaua nodului: confirmă că subnetul are o cale susținută către rețeaua registry-ului, verifică rutele efective pe nod, regulile de securitate la ambele capete și ruta de întoarcere la registry.

Apoi rezolvă numele din contextul nodului. Resolver-ul nodului nu este configurația DNS a podului, iar succesul într-un pod nu este dovadă pentru runtime-ul gazdă. Folosește DNS privat administrat în locul unei intrări permanente în hosts; intrarea trăiește până la înlocuirea nodului și apoi dispare în tăcere.

Apoi dovedește fiecare endpoint. Un registry poate oferi clientului un serviciu de autentificare separat și un spațiu blob separat. A ajunge la manifest nu dovedește aproape nimic despre straturi. La final încheie TLS și autorizarea: un certificat valid pentru numele registry-ului și de încredere prin configurație de nod susținută, plus o identitate de tragere limitată la citirea acelui repository.

Verifică pe un nod pe care nu l-ai reparat manual

Testul care contează este o tragere nouă și descărcarea completă a tuturor straturilor pe un nod potrivit, ideal unul creat prin scalare sau înlocuire. Acoperă toate pool-urile care ar putea plasa workload-ul, inclusiv cele uitate. O reparație manuală pe un singur nod nu este model de implementare, iar următorul eveniment de autoscale va găsi golul.

Recrearea clusterului într-un alt VNet poate schimba calea, dar este ultima soluție și nu primul pas de diagnostic. Compară rețeaua de noduri existentă cu ruta privată necesară și cu controalele de rețea AKS susținute înainte de a propune o migrare, și păstrează conectivitatea aplicației după pornire ca verificare separată: podul care vorbește cu backend-ul este alt control decât nodul care descarcă imaginea.

Articole similare