Privataj GKE-nodoj ne decidas, kiun API kubectl uzas

La nodoj estas privataj, la VPN atingas ilin, kaj kubectl ankoraŭ ne povas paroli kun la klastero. Tiuj du faktoj ne rilatas unu la alian. La adreso, kiun kubectl uzas, venas de la servila URL konservita en kubeconfig kiam la akreditaĵoj estis akiritaj, kaj neniu vojo, kiun vi aldonas, ŝanĝas ĝin. Dume, la nodoj tute ne estas tio, kion kubectl provas atingi.

Kvin kontroloj, komencante per la sola valoro, kiu gravas.

Kontrolo 1: legu la servilan URL-on en kubeconfig

Presu la finpunkton sen elversi la akreditaĵojn: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Tiu unu ĉeno diras al vi, ĉu la kliento celas IP-adreson, DNS-nomon aŭ eksteran adreson, kiun vi ne intencis. Ĉio alia en ĉi tiu esploro sekvas el ĝi.

Se la URL ne estas la finpunkto, kiun vi pensis, ke vi agordis, la resto de la diagnozo estas distro.

Kontrolo 2: kongruigu la URL-on kun la finpunkta tipo

Nuna GKE subtenas kaj IP-bazan kaj DNS-bazan aliron al la rega ebeno, kaj la akreditaĵoj, kiujn vi akiras, elektas unu. gcloud container clusters get-credentials NAME --location REGION --internal-ip skribas la internan IP-finpunkton, dum --dns-endpoint elektas DNS-bazan aliron. Neniu el la flagoj provizas retan vojon, kio surprizas homojn, kiuj atendas, ke la akiro riparos la konekteblecon. Ripetu la akiron intence kaj poste denove legu la URL-on.

Ŝanĝi flagojn sen relegi la URL-on estas la maniero, kiel tekkomputilo finiĝas kun akreditaĵoj de du klasteroj kaj unu konfuza eraro.

Erikto en la rajtigita reto regas, kiu povas atingi eksteran finpunkton, kaj ne validas por la interna. Larĝigi ĝin por testi privatan vojon ŝanĝas vian ekspozicion, ne vian diagnozon.

Kontrolo 3: pruvu la vojon al tiu finpunkto

Se la URL estas interna IP, kontrolu la vojon el la reto, en kiu la kliento efektive sidas, la permesitan fontan intervalon kaj la regionan aŭ tutmondan alir-agordon de la klastero. La intervalo de la rega ebeno kaj la subreto de la nodoj ne estas la sama celo, do funkcianta vojo al la nodoj pruvas nenion pri la finpunkto. Por DNS-baza aliro la vojo estas konektebleco al Google API kun ĝia dokumentita Private Google Access-aranĝo, ne vojo al la subreto de la laboristoj. Testu la finpunkton per ordinara TCP-ligo antaŭ ol kulpi kubectl.

Tempo-limigo estas voja problemo. 403 estas politika problemo. Ili ne dividas riparon.

Kontrolo 4: apartigu protokolojn kaj exec de API-vokoj

Se ordinaraj API-petoj sukcesas kaj kubectl logs aŭ kubectl exec malsukcesas, vi jam preterpasis la elekton de finpunkto. Tiuj operacioj bezonas la respondajn Kubernetes-permesojn kaj dependas de komunikado de la rega ebeno al la nodoj, kaj la malsukceso povas esti Forbidden-respondo anstataŭ tempo-limigo. SSH-aliro al nodo testas tute alian servon kaj ne establas ilin.

Legu la erar-klason antaŭ ol remalfermi la VPN-bileton, ĉar la du klasoj loĝas en malsamaj lokoj.

Kontrolo 5: konservu tri observojn por la sekva persono

Notu la elektitan API-URL-on, ĉu unu rajtigita API-peto funkcias, kaj precize kiun postan operacion malsukcesas, kun la erar-teksto. Tiuj tri linioj apartigas la elekton de finpunkto disde noda aliro, kaj ili malhelpas, ke tute bona VPN-vojo estu kulpigita pro peto, kiun ĝi neniam portis.

La sekva inĝeniero demandos, ĉu la tunelo estas rompita. Via noto jam devus respondi tion.