Nodi za GKE za kibinafsi haziandiki API ipi ambayo kubectl inatumia

Nodi ni za kibinafsi, VPN inazifikia, na bado kubectl haiwezi kuzungumza na kundi. Mambo haya mawili hayahusiani. Anwani ambayo kubectl inatumia inatoka kwenye URL ya seva iliyohifadhiwa katika kubeconfig wakati vitambulisho vilipopatikana, na hakuna njia unayoongeza inayoibadilisha. Wakati huo huo, nodi si kitu ambacho kubectl inajaribu kufikia kwa mara ya kwanza.

Ukaguzi watano, kuanzia na thamani moja pekee iliyo muhimu.

Ukaguzi 1: soma URL ya seva katika kubeconfig

Chapisha sehemu ya mwisho bila kumwaga vitambulisho: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Mfuatano huo mmoja unakuambia kama mteja anaelekea kwenye anwani ya IP, jina la DNS au anwani ya nje ambayo hukukusudia. Kila kitu kingine katika uchunguzi huu kinatokana na hiyo.

Ikiwa URL si sehemu ya mwisho uliyodhani umeisanidi, uchunguzi uliobaki ni kuvuruga mawazo.

Ukaguzi 2: linganisha URL na aina ya sehemu ya mwisho

GKE ya sasa inaunga mkono ufikiaji wa tabaka la udhibiti kwa msingi wa IP na DNS, na vitambulisho unavyopata huchagua kimoja. gcloud container clusters get-credentials NAME --location REGION --internal-ip huandika sehemu ya mwisho ya IP ya ndani, wakati --dns-endpoint huchagua ufikiaji wa msingi wa DNS. Hakuna bendera yoyote inayotoa njia ya mtandao, jambo ambalo huwashangaza wale wanaotarajia upataji utarekebisha muunganisho. Rudia upataji kwa makusudi kisha usome URL tena baadaye.

Kubadilisha bendera bila kusoma URL tena ndiyo njia ambayo kompyuta ya mkononi huishia na vitambulisho vya makundi mawili na hitilafu moja ya kuchanganya.

Ingizo la mtandao lililoruhusiwa huamua nani anaweza kufikia sehemu ya mwisho ya nje na halitumiki kwa ile ya ndani. Kuipanua ili kujaribu njia ya kibinafsi hubadilisha mfiduo wako, si uchunguzi wako.

Ukaguzi 3: thibitisha njia ya kufikia sehemu hiyo ya mwisho

Ikiwa URL ni IP ya ndani, hakikisha njia kutoka kwenye mtandao ambao mteja amekaa kweli, safu ya chanzo inayoruhusiwa na mpangilio wa ufikiaji wa kanda au kimataifa wa kundi. Safu ya tabaka la udhibiti na subnet ya nodi si mwisho mmoja, kwa hiyo njia inayofanya kazi kufikia nodi haithibitishi chochote kuhusu sehemu ya mwisho. Kwa ufikiaji wa msingi wa DNS, njia ni muunganisho wa Google API pamoja na mpango wake ulioandikwa wa Private Google Access, si njia ya kufikia subnet ya wafanyakazi. Jaribu sehemu ya mwisho kwa muunganisho wa kawaida wa TCP kabla ya kulaumu kubectl.

Muda kuisha ni tatizo la njia. 403 ni tatizo la sera. Hazina suluhisho moja.

Ukaguzi 4: tenganisha kumbukumbu na exec kutoka kwa simu za API

Ikiwa maombi ya kawaida ya API yanafanikiwa na kubectl logs au kubectl exec inashindwa, tayari umevuka uchaguzi wa sehemu ya mwisho. Shughuli hizo zinahitaji ruhusa husika za Kubernetes na zinategemea mawasiliano kutoka tabaka la udhibiti hadi nodi, na kushindwa kunaweza kuwa jibu la Forbidden badala ya muda kuisha. Ufikiaji wa SSH kwa nodi hujaribu huduma tofauti kabisa na hautawazisha hizo.

Soma darasa la hitilafu kabla ya kufungua tena tikiti ya VPN, kwa sababu madarasa mawili yanaishi sehemu tofauti.

Ukaguzi 5: hifadhi maangalizi matatu kwa mtu anayefuata

Andika URL ya API iliyochaguliwa, ikiwa ombi moja la API lililoruhusiwa linafanya kazi, na hasa shughuli ipi ya baadaye inashindwa, pamoja na maandishi ya hitilafu. Mistari hiyo mitatu hutenganisha uchaguzi wa sehemu ya mwisho na ufikiaji wa nodi, na huzuia njia nzuri kabisa ya VPN kulaumiwa kwa ombi ambalo haikuwahi kubeba.

Mhandisi anayefuata atauliza kama handaki imevunjika. Maandishi yako yanapaswa kuwa tayari kujibu hilo.