AKS ei voi vetää imagea VPN:n takana olevasta yksityisestä registrystä
kubelet vetää noden verkon kautta, ei podin VPN:n kautta. Ratkaise noden reittien, noden DNS:n, jokaisen vedon koskettaman endpointin ja lopuksi TLS:n ja identiteetin perusteella.
Kannettavasi vetää imagen ongelmitta, mutta pod jää ImagePullBackOff-tilaan ja joku ehdottaa yrityksen VPN-asiakasohjelman ajamista sidecarina. Se ei auta, koska veto tapahtuu ennen kuin konttisi on olemassa: kubelet pyytää noden container runtimea hakemaan imagen, ja runtime käyttää noden verkkonimiavaruutta. Workloadin sisäinen VPN ei voi tarjota reittiä sille polulle, ja sen oma apuimage on vedettävä ensin.
Toimintojen järjestys ratkaisee kerroksen
Ensin tulee imagen nimen selvitys. kubelet selvittää runtimen kautta registryn nimen, yhdistää, todentaa, lataa kerrokset ja vasta sitten käynnistää kontin. Kaikki mitä pod tekee VPN:llä tapahtuu tämän sarjan jälkeen, joten klusterissa toimiva tunneli ei ole todiste vedosta.
Siksi välimuistiin tallennettu image on niin vakuuttava valehtelija. Node, joka veti imagen viikkoja sitten, tarjoilee sitä edelleen, deployment näyttää terveeltä ja vika ilmenee vasta kun ajoitin sijoittaa replikan uudemmalle nodelle. Jos tapahtumien aikajanalla on skaalaus, noden vaihto tai poolin päivitys, kohtele niitä laukaisijana, älä syynä.
Kolme ehtoa ratkaisee korjauksen
Yksityisen registryn saavutettavuus hallitusta node poolista tiivistyy reititykseen, nimien selvitykseen ja endpointien joukkoon. Jos noden aliverkko ei voi reitittää registryn verkkoon, mikään tunnus ei auta. Jos se reitittää mutta ei selvitä registryn nimeä noden DNS-polun kautta, yhteys ei koskaan ala. Jos molemmat toimivat manifest-endpointille mutta eivät blob-endpointille, johon registry ohjaa, veto epäonnistuu puolivälissä.
| 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 |
Pelkkä VNet-peering ei anna automaattisesti kaikkia gateway transit -järjestelyjä, eikä yhteen suuntaan oleva reitti ole toimiva reitti. Node tarvitsee tuetun polun aiottuun VPN-gatewayhin tai hyväksyttyyn laitteeseen, ja registryn puoli tarvitsee paluureitin noden aliverkkoon.
Lue vika ennen korjauksen valintaa
Aloita podin tapahtumista ja nodesta, jolle se laskeutui, oikeilla nimilläsi: kubectl describe pod app-example -n team-example ja kubectl get pod app-example -n team-example -o wide. Tapahtuman teksti erottaa selvittämättömän isäntänimen timeoutista, varmenteen hylkäämisen puuttuvasta imagesta ja valtuutusvirheen kaikista niistä. Näillä neljällä on neljä eri omistajaa.
Todennus on yliarvostetuin vipu. imagePullSecret antaa runtimelle registryn tunnukset; se ei asenna reittiä, ei muuta noden resolveria eikä tee epäluotettavasta varmenteesta kelvollista. Jos tapahtuma sanoo, ettei vetoa valtuutettu, katso identiteetin laajuutta. Jos se sanoo yhteyden aikakatkaistun, tunnukset ovat merkityksettömiä.
Kubernetesin image-dokumentaatio on lähde vedon käyttäytymiselle ja yksityisten registryjen tunnuksille, ja se kannattaa lukea kerran ennen verkon muuttamista, koska se tekee todennuksen ja siirron rajan selväksi.
Rakenna polku podin alle
Työskentele tässä järjestyksessä, koska jokainen askel on merkityksetön kunnes edellinen pitää. Reititä ensin noden verkko: varmista, että noden aliverkolla on tuettu polku registryn verkkoon, tarkista noden voimassa olevat reitit, molempien päiden turvasäännöt ja registryn puolen paluureitti.
Selvitä sitten nimi noden kontekstista. Noden resolver ei ole sama kuin podin DNS-kokoonpano, eikä menestys podin sisällä ole todiste isäntäruntimesta. Käytä hallittua yksityistä DNS:ää pysyvän hosts-merkinnän sijaan; merkintä elää noden vaihtoon asti ja katoaa sitten hiljaa.
Todista sitten jokainen endpoint. Registry voi antaa asiakkaalle erillisen todennuspalvelun ja erillisen blob-tallennuksen. Manifest-endpointiin pääseminen ei todista kerroksista juuri mitään. Lopuksi viimeistele TLS ja valtuutus: registryn nimelle kelvollinen ja tuetun node-kokoonpanon kautta luotettu varmenne sekä vetämiseen identiteetti, joka on rajattu lukemaan kyseistä repositoriota.
Varmenna se nodella, jota et korjannut käsin
Ratkaiseva testi on tuore veto ja kaikkien kerrosten täysi lataus sopivalla nodella, mieluiten skaalauksella tai vaihdolla luodulla. Se kattaa kaikki poolit, jotka voisivat sijoittaa workloadin, myös unohtamasi. Käsin tehty korjaus yhdellä nodella ei ole julkaisumalli, ja seuraava autoscale-tapahtuma löytää aukon.
Klusterin luominen uudelleen toisessa VNetissä voi muuttaa polkua, mutta se on viimeinen keino eikä ensimmäinen diagnoosivaihe. Vertaa nykyistä node-verkkoa vaadittuun yksityiseen reittiin ja tuettuihin AKS-verkon hallintoihin ennen migraation ehdottamista, ja pidä sovelluksen yhteys käynnistyksen jälkeen erillisenä varmennuksena: podin keskustelu backendinsä kanssa on eri tarkistus kuin noden imagen lataaminen.