Hindi makakuha ang AKS ng image mula sa pribadong registry sa likod ng VPN
Kinukuha ng kubelet sa network ng node, hindi sa VPN ng pod. Magpasya batay sa mga ruta ng node, DNS ng node, bawat endpoint na hinahawakan ng pagkuha, at pagkatapos ay TLS at pagkakakilanlan.
Nakakakuha ang laptop mo ng image nang walang problema, pero nakabitin ang pod sa ImagePullBackOff at may nagmumungkahi na patakbuhin ang corporate VPN client bilang sidecar. Hindi ito makakatulong, dahil nangyayari ang pagkuha bago pa umiral ang container mo: hinihiling ng kubelet sa container runtime sa node na kunin ang image, at ginagamit ng runtime ang network namespace ng node.
Ang pagkakasunod-sunod ng operasyon ang nagtatakda ng layer
Una ang resolusyon ng pangalan, pagkatapos ang koneksyon, pagpapatunay, pag-download ng mga layer, at saka pa lamang nagsisimula ang container. Lahat ng ginagawa ng pod sa VPN ay pagkatapos nito, kaya ang gumaganang tunnel sa cluster ay hindi patunay tungkol sa pagkuha.
Kaya ang naka-cache na image ay napakapaniwalang kasinungalingan: ang node na kumuha nito ilang linggo na ang nakalipas ay patuloy na nagbibigay, mukhang malusog ang deployment, at lumalabas lang ang problema kapag naglagay ang scheduler ng replica sa mas bagong node. Ang scale-up o pagpapalit ng node ay ang gatilyo, hindi ang sanhi.
Tatlong kondisyon ang nagtatakda ng pag-aayos
Nakasalalay ang pag-access sa routing, resolusyon ng pangalan at set ng endpoint. Kung hindi makakapag-route ang subnet ng node patungo sa network ng registry, walang credential ang makakatulong. Kung hindi malutas ang pangalan sa pamamagitan ng DNS ng node, hindi magsisimula ang koneksyon. Kung manifest lang ang maabot at hindi ang blob, mabibigo ang pagkuha sa kalagitnaan.
| 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 |
Ang VNet peering lamang ay hindi nagbibigay ng lahat ng gateway transit setup, at ang rutang isang direksyon ay hindi gumaganang ruta. Kailangan ng node ng suportadong landas sa loob ng VPN gateway, at kailangan ng panig ng registry ng pabalik na ruta sa subnet ng node.
Basahin ang problema bago pumili ng pag-aayos
Magsimula sa mga event ng pod at sa node kung saan ito lumapag, gamit ang totoong pangalan: kubectl describe pod app-example -n team-example at kubectl get pod app-example -n team-example -o wide. Hinihiwalay ng teksto ng event ang hindi nalutas na hostname mula sa timeout, ang pagtanggi ng certificate mula sa kulang na image, at ang kabiguan ng awtorisasyon mula sa lahat ng iyon.
Ang pagpapatunay ang pinakalabis na tinatasa na sandata. Binibigyan ng imagePullSecret ang runtime ng credential para sa registry; hindi ito naglalagay ng ruta, hindi nagbabago ng resolver ng node at hindi ginagawang wasto ang hindi pinagkakatiwalaang certificate. Kung sinasabi ng event na hindi awtorisado ang pagkuha, tingnan ang saklaw ng pagkakakilanlan; kung sinasabi nitong nag-timeout ang koneksyon, walang kinalaman ang credential.
Ang dokumentasyon ng image ng Kubernetes ang sanggunian sa pag-uugali ng pagkuha at credential ng pribadong registry, at sulit itong basahin nang isang beses bago baguhin ang network, dahil nilinaw nito ang hangganan ng pagpapatunay at transportasyon.
Buuin ang landas sa ilalim ng pod
Magtrabaho sa ganitong pagkakasunod-sunod. I-route muna ang network ng node: tiyakin na may suportadong landas ang subnet patungo sa network ng registry, suriin ang epektibong ruta sa node, ang mga tuntunin ng seguridad sa dalawang dulo at ang pabalik na ruta sa panig ng registry.
Pagkatapos ay lutasin ang pangalan mula sa konteksto ng node. Ang resolver ng node ay hindi ang DNS configuration ng pod, at ang tagumpay sa loob ng pod ay hindi patunay para sa host runtime. Gumamit ng pinamamahalaang pribadong DNS kaysa permanenteng entry sa hosts; nabubuhay ang entry hanggang mapalitan ang node at pagkatapos ay tahimik na nawawala.
Pagkatapos ay patunayan ang bawat endpoint. Maaaring magbigay ang registry ng hiwalay na serbisyo ng pagpapatunay at hiwalay na imbakan ng blob. Ang maabot ang manifest ay halos walang pinatutunayan tungkol sa mga layer. Sa huli, tapusin ang TLS at awtorisasyon: certificate na wasto para sa pangalan ng registry at pinagkakatiwalaan sa pamamagitan ng suportadong node configuration, kasama ang pagkakakilanlan ng pagkuha na limitado sa pagbasa ng repository na iyon.
I-verify sa node na hindi mo inayos nang manwal
Ang makabuluhang pagsubok ay bagong pagkuha at kumpletong pag-download ng lahat ng layer sa angkop na node, mas mabuti kung ginawa sa pamamagitan ng scale o pagpapalit. Sakop nito ang lahat ng pool na maaaring maglagay ng workload, kabilang ang nakalimutan. Ang manwal na pag-aayos sa isang node ay hindi modelo ng deployment, at mahahanap ng susunod na autoscale event ang puwang.
Ang muling paggawa ng cluster sa ibang VNet ay maaaring magbago ng landas, ngunit iyon ang huling paraan at hindi ang unang hakbang sa diagnosis. Ihambing ang umiiral na network ng node sa kinakailangang pribadong ruta at sa mga suportadong kontrol ng network ng AKS bago magmungkahi ng migrasyon, at panatilihing hiwalay na verification ang koneksyon ng application pagkatapos magsimula: ang pod na nakikipag-usap sa backend nito ay ibang pagsusuri kaysa sa node na nagda-download ng image.