AKS haiwezi kuvuta image kutoka registry ya faragha iliyo nyuma ya VPN yako
kubelet huvuta kupitia mtandao wa node, si kupitia VPN ya pod. Amua kwa njia za node, DNS ya node, kila endpoint inayoguswa na uvutaji, kisha TLS na utambulisho.
Kompyuta yako inavuta image bila shida, lakini pod inabaki kwenye ImagePullBackOff na mtu anapendekeza kuendesha mteja wa VPN wa kampuni kama sidecar. Hiyo haitasaidia, kwa sababu uvutaji hufanyika kabla container yako haipo: kubelet inaomba container runtime kwenye node kuleta image, na runtime hutumia nafasi ya majina ya mtandao ya node.
Mpangilio wa shughuli huamua tabaka
Kwanza utatuzi wa jina, kisha muunganisho, uthibitishaji, upakuaji wa tabaka, na ndipo container huanza. Kila kitu pod hufanya na VPN hufanyika baada ya mpangilio huo, kwa hiyo tunnel inayofanya kazi kwenye cluster si ushahidi kuhusu uvutaji.
Ndiyo sababu image iliyo kwenye cache ni uongo wa kushawishi: node iliyovuta image wiki zilizopita inaendelea kuipatia, deployment inaonekana nzuri, na hitilafu huonekana tu scheduler inapoweka replica kwenye node mpya. scale-up au kubadilisha node ni kichocheo, si sababu.
Masharti matatu huamua urekebishaji
Ufikiaji hutegemea uelekezaji, utatuzi wa majina na seti ya endpoint. Ikiwa subnet ya node haiwezi kuelekeza kwenye mtandao wa registry, hakuna credential itakayosaidia. Ikiwa jina halitatuliwi kupitia DNS ya node, muunganisho hauanza. Ikiwa manifest pekee inapatikana na blob haipatikani, uvutaji unashindwa katikati.
| 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 pekee haitoi mipangilio yote ya gateway transit, na njia ya upande mmoja si njia inayofanya kazi. Node inahitaji njia inayoungwa mkono kupitia VPN gateway, na upande wa registry unahitaji njia ya kurudi kwenye subnet ya node.
Soma hitilafu kabla ya kuchagua urekebishaji
Anza na matukio ya pod na node iliyoangukia, kwa majina yako halisi: kubectl describe pod app-example -n team-example na kubectl get pod app-example -n team-example -o wide. Maandishi ya tukio hutofautisha hostname isiyotatuliwa na timeout, kukataliwa kwa certificate na image inayokosekana, na kushindwa kwa idhini na vyote.
Uthibitishaji ndio kipengele kinachokadiriwa kupita kiasi. imagePullSecret huipa runtime credentials za registry; haiweki njia, haibadilishi resolver ya node na haifanyi certificate isiyoaminika kuwa halali. Ikiwa tukio linasema uvutaji haukuidhinishwa, angalia wigo wa utambulisho; ikiwa linasema muunganisho uliisha muda, credentials hazina umuhimu.
Nyaraka za image za Kubernetes ni rejea ya tabia ya uvutaji na credentials za registry za faragha, na inafaa kusoma mara moja kabla ya kubadilisha mtandao, kwa sababu inafanya wazi mpaka kati ya uthibitishaji na usafirishaji.
Jenga njia chini ya pod
Fanya kazi kwa mpangilio huu. Kwanza elekeza mtandao wa node: hakikisha subnet ina njia inayoungwa mkono kuelekea mtandao wa registry, angalia njia zinazofanya kazi kwenye node, kanuni za usalama pande zote mbili na njia ya kurudi upande wa registry.
Kisha tatua jina kutoka muktadha wa node. Resolver ya node si mpangilio wa DNS wa pod, na mafanikio ndani ya pod si ushahidi kwa host runtime. Tumia DNS ya faragha inayosimamiwa badala ya ingizo la kudumu la hosts; ingizo huishi hadi node ibadilishwe kisha hutoweka kimya.
Kisha thibitisha kila endpoint. Registry inaweza kumpa mteja huduma tofauti ya uthibitishaji na hifadhi tofauti ya blob. Kufikia manifest huthibitisha karibu hakuna kuhusu tabaka. Mwisho kamilisha TLS na idhini: certificate halali kwa jina la registry na inayoaminika kupitia usanidi wa node unaoungwa mkono, pamoja na utambulisho wa uvutaji uliowekwa kwa kusoma hazina hiyo.
Thibitisha kwenye node usiyoirekebisha kwa mkono
Jaribio linalohesabiwa ni uvutaji mpya na upakuaji kamili wa tabaka zote kwenye node inayofaa, ikiwezekana iliyoundwa kwa scale au kubadilishwa. Hii inashughulikia pool zote zinazoweza kuweka workload, ikiwa ni pamoja na zilizosahaulika. Urekebishaji wa mkono kwenye node moja si model ya uwekaji, na tukio lijalo la autoscale litapata pengo.
Kuunda cluster upya kwenye VNet nyingine kunaweza kubadilisha njia, lakini hiyo ni njia ya mwisho na si hatua ya kwanza ya uchunguzi. Linganisha mtandao uliopo wa node na njia ya faragha inayohitajika na vidhibiti vya mtandao vya AKS vinavyoungwa mkono kabla ya kupendekeza uhamishaji, na uweke muunganisho wa application baada ya kuanza kama uthibitisho tofauti: pod inayozungumza na backend yake ni ukaguzi tofauti na node inayopakua image.