AKS ei suuda VPN-i taga olevast privaatsest registry-st pilti tõmmata
kubelet tõmbab node@APOS@i võrgu kaudu, mitte podi VPN-i kaudu. Otsusta node@APOS@i marsruutide, node@APOS@i DNS-i, iga tõmbamise puudutatud endpointi, seejärel TLS-i ja identiteedi järgi.
Sinu sülearvuti tõmbab pildi probleemideta, kuid pod jääb ImagePullBackOff olekusse ja keegi pakub välja käivitada ettevõtte VPN-klient sidecarina. See ei aita, sest tõmbamine toimub enne, kui sinu konteiner on olemas: kubelet palub node’i container runtime’il pilt tuua ja runtime kasutab node’i võrgu nimeruumi. Töökoormuse sees olev VPN ei saa sellele teele marsruuti pakkuda ja selle enda abipilt tuleb esmalt tõmmata.
Toimingute järjekord määrab kihi
Kõigepealt tuleb pildi nime lahendamine. kubelet lahendab runtime’i kaudu registry nime, ühendub, autendib, laadib kihid alla ja alles siis käivitab konteineri. Kõik, mida pod VPN-iga teeb, toimub pärast seda järjestust, seega klastris töötav tunnel ei ole tõmbamise kohta tõestus.
Seetõttu on vahemällu salvestatud pilt nii veenev valetaja. Node, mis tõmbas pildi nädalaid tagasi, serveerib seda edasi, deployment näib terve ja rike ilmneb alles siis, kui planeerija paigutab replica uuemasse node’i. Kui sündmuste ajajoon sisaldab scale-up’i, node’i vahetust või pooli uuendust, käsitle neid päästikuna, mitte põhjusena.
Kolm tingimust määravad paranduse
Privaatse registry kättesaadavus hallatud node pool’ist taandub marsruutimisele, nimelahendusele ja endpointide hulgale. Kui node’i alamvõrk ei saa registry võrku marsruutida, ei aita ükski mandaat. Kui see marsruudib, kuid ei lahenda registry nime node’i DNS-tee kaudu, ei alga ühendus kunagi. Kui mõlemad töötavad manifest endpointi jaoks, kuid mitte blob endpointi jaoks, kuhu registry suunab, ebaõnnestub tõmbamine poole peal.
| 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 |
Ainuüksi VNet peering ei anna sulle automaatselt kõiki gateway transit’i lahendusi ja ühes suunas eksisteeriv marsruut ei ole töötav marsruut. Node vajab toetatud teed kavandatud VPN gateway või heakskiidetud seadme kaudu ning registry pool vajab tagasiteed node’i alamvõrku.
Loe riket enne paranduse valimist
Alusta podi sündmustest ja node’ist, kuhu see maandus, oma tegelike nimedega: kubectl describe pod app-example -n team-example ja kubectl get pod app-example -n team-example -o wide. Sündmuse tekst eristab lahendamata hostinime timeout’ist, sertifikaadi tagasilükkamist puuduvast pildist ja autoriseerimise ebaõnnestumist kõigist neist. Need neli on neli erinevat omanikku.
Autentimine on kõige ülehinnatum hoob. imagePullSecret annab runtime’ile registry mandaadid; see ei paigalda marsruuti, ei muuda node’i resolverit ega muuda ebausaldusväärset sertifikaati kehtivaks. Kui sündmus ütleb, et tõmbamine ei olnud autoriseeritud, vaata identiteedi ulatust. Kui ütleb, et ühendus aegus, on mandaadid asjakohatud.
Kubernetes’i piltide dokumentatsioon on viide tõmbamise käitumisele ja privaatsete registry’te mandaatidele ning seda tasub enne võrgu muutmist korra lugeda, sest see teeb autentimise ja transpordi vahelise piiri selgeks.
Ehita tee podi alla
Tööta selles järjekorras, sest iga samm on mõttetu, kuni eelmine ei kehti. Marsruudi kõigepealt node’i võrk: kinnita, et node’i alamvõrgul on toetatud tee registry võrku, kontrolli node’i tegelikke marsruute, mõlema otsa turvareegleid ja registry poolel tagasiteed.
Seejärel lahenda nimi node’i kontekstist. Node’i resolver ei ole sama mis podi DNS-i konfiguratsioon ja edu podi sees ei ole tõestus host runtime’i kohta. Kasuta hallatud privaatset DNS-i, mitte püsivat hosts-kirjet; kirje elab kuni node’i vahetamiseni ja kaob siis vaikselt.
Seejärel tõesta iga endpoint. Registry võib anda kliendile eraldi autentimisteenuse ja eraldi blob-salvestuse. Manifest endpointini jõudmine ei tõesta kihtide kohta peaaegu midagi. Lõpuks lõpeta TLS ja autoriseerimine: sertifikaat, mis kehtib registry nimele ja on usaldusväärne toetatud node’i konfiguratsiooni kaudu, pluss tõmbamise identiteet, mis on piiratud selle hoidla lugemisega.
Kontrolli seda node’il, mida sa käsitsi ei parandanud
Loeb test, mis on värske tõmbamine ja kõigi kihtide täielik allalaadimine sobival node’il, ideaalis skaleerimise või vahetuse teel loodud node’il. See katab kõik poolid, mis võiksid töökoormuse paigutada, ka unustatud. Käsitsi parandus ühel node’il ei ole juurutamismudel ja järgmine autoscale’i sündmus leiab lünka.
Klastri uuesti loomine teises VNet’is võib teed muuta, kuid see on viimane abinõu, mitte esimene diagnostiline samm. Võrdle olemasolevat node’i võrku vajaliku privaatse marsruudi ja toetatud AKS-i võrgukontrollidega enne migratsiooni pakkumist ning hoia rakenduse ühenduvust pärast käivitumist eraldi kontrollina: pod oma backendiga rääkimas on teine kontroll kui node pilti alla laadimas.