Ang mga pribadong node ng GKE ay hindi nagtatakda kung aling API ang ginagamit ng kubectl
Ang SSH sa mga node, mga tawag sa API at streaming ng log ay gumagamit ng magkakaibang landas. Basahin ang URL ng server sa kubeconfig bago maghinuha ng anuman mula sa mga address ng pribadong node.
Pribado ang mga node, naaabot sila ng VPN, at gayon pa man ay hindi makausap ng kubectl ang cluster. Walang kaugnayan ang dalawang katotohanang ito. Ang address na ginagamit ng kubectl ay nagmumula sa URL ng server na inimbak sa kubeconfig noong kinuha ang mga kredensyal, at walang rutang idinagdag mo ang nagbabago nito. Samantala, ang mga node ay hindi talaga ang sinusubukang abutin ng kubectl.
Limang pagsusuri, simula sa nag-iisang halagang mahalaga.
Pagsusuri 1: basahin ang URL ng server sa kubeconfig
I-print ang endpoint nang hindi ibinubuhos ang mga kredensyal: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Ang nag-iisang string na iyon ay nagsasabi kung ang kliyente ay tumuturo sa isang address ng IP, isang pangalang DNS, o isang panlabas na address na hindi mo sinadya. Lahat ng iba pa sa pagsisiyasat na ito ay nagmumula roon.
Kung ang URL ay hindi ang endpoint na inaakala mong na-configure mo, ang natitirang diagnosis ay isang abala lamang.
Pagsusuri 2: itugma ang URL sa uri ng endpoint
Sinusuportahan ng kasalukuyang GKE ang pag-access sa control plane batay sa IP at batay sa DNS, at ang mga kredensyal na kinukuha mo ay pumipili ng isa. Isinusulat ng gcloud container clusters get-credentials NAME --location REGION --internal-ip ang endpoint ng panloob na IP, samantalang pinipili ng --dns-endpoint ang pag-access na batay sa DNS. Wala sa mga flag ang nagbibigay ng landas ng network, na ikinagulat ng mga umaasang aayusin ng pagkuha ang koneksyon. Sadyang ulitin ang pagkuha at pagkatapos ay basahin muli ang URL.
Ang pagbabago ng mga flag nang hindi binabasa muli ang URL ay ang paraan ng pagtatapos ng isang laptop na may mga kredensyal ng dalawang cluster at isang nakakalitong error.
Ang entry sa awtorisadong network ay nagtatakda kung sino ang makakaabot sa panlabas na endpoint at hindi nalalapat sa panloob. Ang pagpapalawak nito upang subukan ang isang pribadong landas ay nagbabago ng iyong pagkakalantad, hindi ng iyong diagnosis.
Pagsusuri 3: patunayan ang landas patungo sa endpoint na iyon
Kung ang URL ay isang panloob na IP, i-verify ang ruta mula sa network kung saan talagang nakaupo ang kliyente, ang pinapayagang hanay ng pinagmulan at ang panrehiyon o pandaigdigang setting ng pag-access ng cluster. Ang hanay ng control plane at ang subnet ng node ay hindi magkaparehong destinasyon, kaya ang gumaganang ruta patungo sa mga node ay walang pinapatunayan tungkol sa endpoint. Para sa pag-access na batay sa DNS, ang landas ay ang koneksyon sa Google API kasama ang dokumentadong kaayusan ng Private Google Access, hindi isang ruta patungo sa subnet ng mga manggagawa. Subukan ang endpoint gamit ang payak na koneksyon ng TCP bago sisihin ang kubectl.
Ang timeout ay problema sa landas. Ang 403 ay problema sa patakaran. Wala silang iisang solusyon.
Pagsusuri 4: paghiwalayin ang mga log at exec mula sa mga tawag sa API
Kung nagtagumpay ang mga ordinaryong kahilingan sa API at nabigo ang kubectl logs o kubectl exec, nalampasan mo na ang pagpili ng endpoint. Ang mga operasyong iyon ay nangangailangan ng kaukulang mga pahintulot sa Kubernetes at nakadepende sa komunikasyon mula sa control plane patungo sa mga node, at ang pagpalya ay maaaring isang tugon na Forbidden sa halip na timeout. Ang pag-access ng SSH sa isang node ay sumusubok ng ganap na ibang serbisyo at hindi nagtatatag ng mga iyon.
Basahin ang klase ng error bago muling buksan ang tiket ng VPN, dahil ang dalawang klase ay nakatira sa magkaibang lugar.
Pagsusuri 5: mag-imbak ng tatlong obserbasyon para sa susunod na tao
Itala ang piniling URL ng API, kung gumagana ang isang awtorisadong kahilingan sa API, at eksakto kung aling kasunod na operasyon ang nabigo, kasama ang teksto ng error. Ang tatlong linyang iyon ay naghihiwalay ng pagpili ng endpoint mula sa pag-access sa node, at pinipigilan ang isang ganap na magandang rutang VPN na masisi sa isang kahilingang hindi nito kailanman dinala.
Tatanungin ng susunod na inhinyero kung sira ang tunnel. Dapat ay nasagot na iyon ng iyong tala.