GKE nodo pribatuek ez dute erabakitzen kubectlek zein API erabiltzen duen

Nodoak pribatuak dira, VPNak haietara iristen da, eta hala ere kubectlek ezin du klusterrarekin hitz egin. Bi gertaera horiek ez dute zerikusirik. kubectlek erabiltzen duen helbidea kredentzialak eskuratzean kubeconfig-en gordetako zerbitzariaren URLtik dator, eta gehitzen duzun edozein bidek ez du aldatzen. Bitartean, nodoak ez dira kubectlek lehenik eta behin lortu nahi duena.

Bost egiaztapen, axola duen balio bakarraretik hasita.

1. egiaztapena: irakurri zerbitzariaren URLa kubeconfig-en

Inprimatu amaierako puntua kredentzialak bota gabe: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Kate bakar horrek esaten dizu bezeroak IP helbide batera, DNS izen batera edo nahi ez zenuen kanpoko helbide batera seinalatzen duen. Ikerketa honetako gainerako guztia hortik dator.

URLa konfiguratu uste zenuen amaierako puntua ez bada, diagnostikoaren gainerakoa distrazioa da.

2. egiaztapena: parekatu URLa amaierako puntu motarekin

Egungo GKEk IP bidezko eta DNS bidezko kontrol-planoaren sarbidea onartzen ditu, eta eskuratzen dituzun kredentzialek bat aukeratzen dute. gcloud container clusters get-credentials NAME --location REGION --internal-ip barne IParen amaierako puntua idazten du, eta --dns-endpoint DNS bidezko sarbidea hautatzen du. Inongo banderak ez du sare-biderik ematen, eta horrek harritu egiten ditu konektibitatea konponduko duela espero dutenak. Errepikatu eskuraketa nahita eta irakurri berriro URLa ondoren.

Banderak URLa berriro irakurri gabe aldatzea da ordenagailu eramangarri bat bi klusterren kredentzialekin eta errore nahasi batekin geratzeko modua.

Baimendutako sarearen sarrerak zehazten du nor irits daitekeen kanpoko amaierako puntu batera, eta ez da barnekoari aplikatzen. Bide pribatu bat probatzeko zabaltzeak zure esposizioa aldatzen du, ez zure diagnostikoa.

3. egiaztapena: frogatu amaierako puntu horretarako bidea

URLa barne IPa bada, egiaztatu bidea bezeroa benetan dagoen saretik, baimendutako jatorri-tartea eta klusterraren eskualdeko edo globaleko sarbide-ezarpena. Kontrol-planoaren tartea eta nodoen azpisarea ez dira helmuga bera, beraz nodoetaraino funtzionatzen duen bide batek ez du ezer frogatzen amaierako puntuaz. DNS bidezko sarbiderako bidea Google APIarekiko konektibitatea da, dokumentatutako Private Google Access antolamenduarekin, ez langileen azpisarrerako bidea. Probatu amaierako puntua TCP konexio arrunt batekin kubectl erruztatu aurretik.

Denbora-muga bide-arazoa da. 403 politika-arazoa da. Ez dute konponbide bera partekatzen.

4. egiaztapena: bereizi erregistroak eta exec API deietatik

API eskaera arruntek arrakasta badute eta kubectl logs edo kubectl exec huts egiten badu, amaierako puntuaren hautaketa gainditu duzu dagoeneko. Eragiketa horiek dagozkien Kubernetes baimenak behar dituzte eta kontrol-planoaren eta nodoen arteko komunikazioaren mende daude, eta hutsegitea Forbidden erantzuna izan daiteke, denbora-muga izan beharrean. Nodo baterako SSH sarbideak erabat beste zerbitzu bat probatzen du eta ez ditu haiek ezartzen.

Irakurri errore-klasea VPN txartela berriro ireki aurretik, bi klaseak leku desberdinetan bizi baitira.

5. egiaztapena: gorde hiru ohar hurrengo pertsonarentzat

Idatzi hautatutako API URLa, API eskaera baimendu batek funtzionatzen duen ala ez, eta zehazki zein geroko eragiketak huts egiten duen, errore-testuarekin batera. Hiru lerro horiek amaierako puntuaren hautaketa nodoen sarbidetik bereizten dute, eta bide VPN bikain bat inoiz eraman ez zuen eskaera baten errua ez leporatzeko eragozten dute.

Hurrengo ingeniariak galdetuko du tunela hondatuta dagoen. Zure oharrak jadanik erantzun beharko luke.