AKS nuk mund të tërheqë imazhin nga një registry privat pas VPN-së
kubelet tërheq përmes rrjetit të node, jo përmes VPN-së së pod. Vendosni sipas rrugëve të node, DNS-së së node, çdo endpoint që prek tërheqja, pastaj TLS dhe identiteti.
Laptopi juaj e tërheq imazhin pa problem, por pod-i mbetet në ImagePullBackOff dhe dikush propozon të ekzekutoni klientin e VPN-së korporative si sidecar. Kjo nuk ndihmon, sepse tërheqja ndodh para se container-i juaj të ekzistojë: kubelet i kërkon container runtime në node ta sjellë imazhin, dhe runtime përdor hapësirën e emrave të rrjetit të node.
Rendi i operacioneve vendos shtresën
Së pari zgjidhja e emrit, pastaj lidhja, vërtetimi, shkarkimi i shtresave dhe vetëm pastaj nis container-i. Gjithçka që pod-i bën me VPN ndodh pas kësaj sekuence, prandaj një tunel që funksionon në cluster nuk është provë për tërheqjen.
Prandaj një imazh në cache është një gënjeshtër kaq bindëse: node që e tërhoqi imazhin javë më parë vazhdon ta shërbejë, deployment duket i shëndetshëm, dhe dështimi shfaqet vetëm kur planifikuesi vendos një replikë në node më të ri. scale-up ose zëvendësimi i node është nxitësi, jo shkaku.
Tre kushte vendosin riparimin
Arritshmëria zbret në rrugëtim, zgjidhje emrash dhe grupin e endpoint-eve. Nëse subnet-i i node nuk rrugëton dot drejt rrjetit të registry, asnjë kredencial nuk ndihmon. Nëse emri nuk zgjidhet përmes DNS-së së node, lidhja nuk fillon. Nëse funksionon vetëm manifest dhe jo blob, tërheqja dështon në mes.
| 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 |
Vetëm VNet peering nuk jep të gjitha konfigurimet e gateway transit, dhe një rrugë në një drejtim nuk është rrugë që funksionon. Node ka nevojë për një shteg të mbështetur përmes VPN gateway-it të synuar, dhe ana e registry për një rrugë kthimi drejt subnet-it të node.
Lexoni dështimin përpara se të zgjidhni riparimin
Filloni me ngjarjet e pod-it dhe node ku u ul, me emrat tuaj realë: kubectl describe pod app-example -n team-example dhe kubectl get pod app-example -n team-example -o wide. Teksti i ngjarjes dallon një hostname të pazgjidhur nga timeout, një refuzim certifikate nga një imazh që mungon, dhe një dështim autorizimi nga të gjitha.
Vërtetimi është levë më e mbivlerësuar. imagePullSecret i jep runtime-it kredencialet e registry; nuk instalon rrugë, nuk ndryshon resolver-in e node dhe nuk e bën të vlefshëm një certifikatë jo të besuar. Nëse ngjarja thotë se tërheqja nuk ishte e autorizuar, shihni shtrirjen e identitetit; nëse thotë se lidhja skadoi, kredencialet janë të parëndësishme.
Dokumentacioni i Kubernetes për imazhet është referenca për sjelljen e tërheqjes dhe kredencialet e registry-ve private, dhe ia vlen ta lexoni një herë përpara se të ndryshoni rrjetin, sepse e bën të qartë kufirin mes vërtetimit dhe transportit.
Ndërtoni shtegun nën pod
Punoni në këtë rend. Së pari rrugëtoni rrjetin e node: konfirmoni që subnet-i ka një shteg të mbështetur drejt rrjetit të registry, kontrolloni rrugët efektive në node, rregullat e sigurisë në të dy skajet dhe rrugën e kthimit në anën e registry.
Pastaj zgjidhni emrin nga konteksti i node. Resolver-i i node nuk është konfigurimi DNS i pod-it, dhe suksesi brenda pod-it nuk është provë për host runtime. Përdorni DNS privat të menaxhuar në vend të një hyrjeje të përhershme në hosts; hyrja jeton derisa node të zëvendësohet dhe pastaj zhduket në heshtje.
Pastaj provoni çdo endpoint. Një registry mund t’i japë klientit një shërbim vërtetimi të veçantë dhe një ruajtje blob të veçantë. Arritja e manifest nuk provon pothuajse asgjë për shtresat. Në fund përfundoni TLS dhe autorizimin: një certifikatë e vlefshme për emrin e registry dhe e besueshme përmes konfigurimit të mbështetur të node, plus një identitet tërheqjeje i kufizuar në leximin e atij repo.
Verifikoni në një node që nuk e riparuat me dorë
Testi që ka rëndësi është një tërheqje e re dhe shkarkim i plotë i të gjitha shtresave në një node të përshtatshëm, idealisht të krijuar nga shkallëzimi ose zëvendësimi. Kjo mbulon të gjitha pool-et që mund të vendosin workload, përfshirë ato të harruara. Riparimi me dorë në një node nuk është model vendosjeje, dhe ngjarja e radhës e autoscale do ta gjejë boshllëkun.
Rikrijimi i cluster në një VNet tjetër mund ta ndryshojë shtegun, por është mjeti i fundit dhe jo hapi i parë i diagnostikimit. Krahasoni rrjetin ekzistues të node me rrugën private të nevojshme dhe me kontrollet e rrjetit AKS të mbështetura përpara se të propozoni një migrim, dhe mbani lidhshmërinë e aplikacionit pas nisjes si verifikim të veçantë: pod-i që flet me backend-in e tij është kontroll tjetër nga node që shkarkon imazhin.