AKS kan nie van @APOS@n private registry agter jou VPN trek nie
Die kubelet trek deur die nodenetwerk, nie deur @APOS@n pod se VPN nie. Besluit op node-roetes, node-DNS, elke eindpunt wat die trek raak, en dan TLS en identiteit.
Jou skootrekenaar trek die beeld foutloos, die pod sit in ImagePullBackOff, en iemand stel voor om die korporatiewe VPN-kliënt as sidecar te laat loop. Dit sal nie help nie, want die trek gebeur voordat jou container bestaan. Die kubelet vra die container-runtime op die node om die beeld te haal, en die runtime gebruik die node se netwerk-naamruimte. ’n VPN binne die workload het geen roete om daardie pad te bied nie, en sy eie hulpbeeld moet steeds eers getrek word.
Die volgorde van bewerkings bepaal die laag
Beeldoplossing kom eerste. Die kubelet, via die runtime, los die registry-naam op, maak verbinding, verifieer, laai lae af, en eers daarna begin die container. Alles wat jou pod met ’n VPN doen, gebeur nadat daardie reeks voltooi is, en daarom is ’n werkende tonnel in die cluster nie bewys oor die trek nie.
Daarom is ’n gekaste beeld so ’n oortuigende leuenaar. Een node wat die beeld weke gelede getrek het, bly dit lewer, die deployment lyk gesond, en die fout verskyn eers wanneer die skeduleerder ’n replica op ’n nuwer node plaas. As die gebeurtydlyn ’n skaal-op, ’n node-vervanging of ’n pool-opgradering bevat, hanteer dit as die sneller, nie die oorsaak nie.
Drie voorwaardes bepaal die herstel
Bereikbaarheid van ’n private registry vanaf ’n bestuurde node-pool kom neer op roetering, naamoplossing en die stel eindpunte. As die node-subnet nie na die registry-netwerk kan roeteer nie, help geen geloofsbriewe nie. As dit roeteer maar nie die registry-naam via die node se DNS-pad kan oplos nie, begin die verbinding nooit. As albei werk vir die manifest-eindpunt maar nie vir die blob-eindpunt waarna die registry herlei nie, misluk die trek halfpad.
| 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 |
VNet-peering alleen gee jou nie outomaties elke gateway-transit-reëling nie, en ’n roete wat in een rigting bestaan, is nie ’n roete wat werk nie. Die node het ’n ondersteunde pad nodig deur die beoogde VPN-gateway of goedgekeurde toestel, en die registry-kant het ’n terugroete na die node-subnet nodig.
Lees die fout voordat jy ’n oplossing kies
Begin met die pod-gebeurtenisse en die node waarop dit beland het, met jou regte name: kubectl describe pod app-example -n team-example en kubectl get pod app-example -n team-example -o wide. Die gebeurteks skei ’n onopgeloste hostnaam van ’n timeout, ’n sertifikaatverwerping van ’n ontbrekende beeld, en ’n magtigingsfout van almal. Daardie vier het vier verskillende eienaars.
Verifikasie is die mees oorskatte hefboom. ’n imagePullSecret gee die runtime geloofsbriewe vir die registry; dit installeer nie ’n roete nie, verander nie die node se resolver nie en maak nie ’n onvertroude sertifikaat geldig nie. As die gebeur sê die trek was ongemagtig, kyk na die omvang van die identiteit. As dit sê die verbinding het uitgetree, is geloofsbriewe irrelevant.
Die Kubernetes-beelddokumentasie is die verwysing vir trekgedrag en geloofsbriewe vir private registries, en dit is die moeite werd om dit een keer te lees voordat jy netwerk verander, want dit maak die grens tussen verifikasie en transport eksplisiet.
Bou die pad onder die pod
Werk in hierdie volgorde, want elke stap is betekenisloos tot die vorige een geld. Roeteer eers die node-netwerk: bevestig dat die node-subnet ’n ondersteunde pad na die registry-netwerk het, kontroleer effektiewe roetes op die node, die sekuriteitsreëls aan beide kante en die terugroete aan die registry-kant.
Los dan die naam op vanuit die node se konteks. Die node se resolver is nie dieselfde as ’n pod se DNS-konfigurasie nie, en sukses binne ’n pod is nie bewys oor die gasheer-runtime nie. Gebruik bestuurde private DNS eerder as ’n permanente hosts-inskrywing; die inskrywing oorleef tot die node vervang word en verdwyn dan stilweg.
Bewys dan elke eindpunt. ’n Registry kan die kliënt na ’n aparte verifikasiediens en ’n aparte blob-bergingsplek stuur. Om die manifest-eindpunt te bereik bewys byna niks oor die lae nie. Voltooi laastens TLS en magtiging: ’n sertifikaat wat geldig is vir die registry-naam en deur ondersteunde node-konfigurasie vertrou word, plus ’n trek-identiteit met leestoegang tot daardie repository.
Verifieer dit op ’n node wat jy nie met die hand herstel het nie
Die toets wat tel, is ’n vars trek en ’n volledige aflaai van alle lae op ’n geskikte node, ideaal een wat deur skaal of vervanging geskep is. Dit dek elke pool wat die workload kan skeduleer, insluitend dié wat jy vergeet het. ’n Handmatige regstelling op een node is nie ’n ontplooiingsmodel nie, en die volgende outoskaal-gebeurtenis sal die gaping vind.
Om die cluster in ’n ander VNet te herskep kan die pad verander, maar dit is die laaste uitweg eerder as die eerste diagnostiese stap. Vergelyk die bestaande node-netwerk met die vereiste private roete en die ondersteunde AKS-netwerkbeheermaatreëls voordat jy ’n migrasie voorstel, en hou toepassingskonnektiwiteit na die opstart as ’n aparte verifikasie: die pod wat met sy backend praat, is ’n ander kontrole as die node wat die beeld aflaai.