Privātie GKE mezgli nenosaka, kuru API izmanto kubectl

Mezgli ir privāti, VPN tiem piekļūst, un tomēr kubectl nevar sazināties ar klasteri. Šie divi fakti nav saistīti. Adrese, ko izmanto kubectl, nāk no servera URL, kas tika saglabāts kubeconfig, kad tika iegūti akreditācijas dati, un neviena pievienotā maršruta tabula to nemaina. Tikmēr mezgli nemaz nav tas, ko kubectl cenšas sasniegt.

Piecas pārbaudes, sākot ar vienīgo vērtību, kam ir nozīme.

1. pārbaude: izlasiet servera URL kubeconfig

Izdrukājiet galapunktu, neizgāžot akreditācijas datus: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Šī viena virkne pasaka, vai klients norāda uz IP adresi, DNS nosaukumu vai uz ārēju adresi, ko neesat domājis. Viss pārējais šajā izmeklēšanā izriet no tā.

Ja URL nav tas galapunkts, ko, jūsuprāt, konfigurējāt, pārējā diagnostika ir uzmanības novēršana.

2. pārbaude: saskaņojiet URL ar galapunkta veidu

Pašreizējais GKE atbalsta gan IP, gan DNS balstītu piekļuvi vadības plaknei, un iegūtie akreditācijas dati izvēlas vienu no tiem. gcloud container clusters get-credentials NAME --location REGION --internal-ip ieraksta iekšējā IP galapunktu, bet --dns-endpoint izvēlas DNS balstītu piekļuvi. Neviens karodziņš nenodrošina tīkla ceļu, kas pārsteidz tos, kuri gaida, ka datu iegūšana salabos savienojumu. Apzināti atkārtojiet iegūšanu un pēc tam vēlreiz izlasiet URL.

Karodziņu maiņa, atkārtoti neizlasot URL, ir veids, kā klēpjdators paliek ar divu klasteru akreditācijas datiem un vienu mulsinošu kļūdu.

Ieraksts atļautajā tīklā nosaka, kas drīkst sasniegt ārēju galapunktu, un neattiecas uz iekšējo. Tā paplašināšana, lai pārbaudītu privātu ceļu, maina jūsu pakļautību, nevis diagnostiku.

3. pārbaude: pierādiet ceļu uz šo galapunktu

Ja URL ir iekšējā IP, pārbaudiet maršrutu no tīkla, kurā klients faktiski atrodas, atļauto avota diapazonu un klastera reģionālo vai globālo piekļuves iestatījumu. Vadības plaknes diapazons un mezglu apakštīkls nav viens un tas pats galamērķis, tāpēc strādājošs maršruts uz mezgliem neko nepierāda par galapunktu. DNS balstītai piekļuvei ceļš ir Google API savienojamība ar dokumentēto Private Google Access kārtību, nevis maršruts uz darbinieku apakštīklu. Pārbaudiet galapunktu ar vienkāršu TCP savienojumu, pirms vainojat kubectl.

Taimauts ir ceļa problēma. 403 ir politikas problēma. Tiem nav kopīga risinājuma.

4. pārbaude: atdaliet žurnālus un exec no API izsaukumiem

Ja parastie API pieprasījumi izdodas un kubectl logs vai kubectl exec neizdodas, jūs jau esat pāri galapunkta izvēlei. Šīm darbībām nepieciešamas attiecīgās Kubernetes atļaujas, un tās ir atkarīgas no vadības plaknes saziņas ar mezgliem, un kļūme var būt Forbidden atbilde, nevis taimauts. SSH piekļuve mezglam pārbauda pavisam citu pakalpojumu un tos neizveido.

Izlasiet kļūdas klasi, pirms atkārtoti atverat VPN biļeti, jo abas klases dzīvo dažādās vietās.

5. pārbaude: saglabājiet trīs novērojumus nākamajai personai

Pierakstiet izvēlēto API URL, vai viens atļauts API pieprasījums darbojas, un tieši kura vēlākā darbība neizdodas, kopā ar kļūdas tekstu. Šīs trīs rindas atdala galapunkta izvēli no piekļuves mezgliem, un tās neļauj pilnīgi labu VPN maršrutu vainot pieprasījumā, ko tas nekad nav pārvadājis.

Nākamais inženieris jautās, vai tunelis ir salauzts. Jūsu piezīmei jau vajadzētu uz to atbildēt.