Privaat GKE-nodusse bepaal nie watter API kubectl gebruik nie

Die nodusse is privaat, die VPN bereik hulle, en kubectl kan steeds nie met die cluster praat nie. Dié twee feite het niks met mekaar te doen nie. Die adres wat kubectl gebruik, kom uit die bediener-URL wat in die kubeconfig gestoor is toe die geloofsbriewe opgehaal is, en geen roete wat jy byvoeg verander dit nie. Intussen is die nodusse nie eers wat kubectl probeer bereik nie.

Vyf kontroles, beginnende met die enigste waarde wat saak maak.

Kontrole 1: lees die bediener-URL in die kubeconfig

Druk die eindpunt uit sonder om die geloofsbriewe te stort: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Daardie een string vertel jou of die kliënt na ’n IP-adres, ’n DNS-naam of ’n eksterne adres wys wat jy nie bedoel het nie. Alles anders in hierdie ondersoek volg daaruit.

As die URL nie die eindpunt is wat jy gedink het jy opgestel het nie, is die res van die diagnose ’n afleiding.

Kontrole 2: pas die URL by die tipe eindpunt

Huidige GKE ondersteun beide IP-gebaseerde en DNS-gebaseerde toegang tot die beheervlak, en die geloofsbriewe wat jy ophaal, kies een daarvan. gcloud container clusters get-credentials NAME --location REGION --internal-ip skryf die interne IP-eindpunt, terwyl --dns-endpoint DNS-gebaseerde toegang kies. Nie een van die vlae voorsien ’n netwerkroete nie, wat mense verras wat verwag dat die ophaal die verbinding sal regmaak nie. Herhaal die ophaal doelbewus en lees die URL daarna weer.

Om vlae te verander sonder om die URL weer te lees, is hoe ’n skootrekenaar met twee clusters se geloofsbriewe en een verwarrende fout beland.

’n Inskrywing in die toegestane netwerk bepaal wie ’n eksterne eindpunt mag bereik en geld nie vir die interne een nie. Om dit te verbreed om ’n private roete te toets, verander jou blootstelling eerder as jou diagnose.

Kontrole 3: bewys die roete na daardie eindpunt

As die URL ’n interne IP is, verifieer die roete vanaf die netwerk waarop die kliënt werklik sit, die toegelate bronreeks en die cluster se streeks- of globale toeganginstelling. Die beheervlakreeks en die nodus-subnet is nie dieselfde bestemming nie, so ’n werkende roete na die nodusse bewys niks oor die eindpunt nie. Vir DNS-gebaseerde toegang is die roete Google API-konnektiwiteit met sy gedokumenteerde Private Google Access-reëling, nie ’n roete na die werker-subnet nie. Toets die eindpunt met ’n gewone TCP-verbinding voordat jy kubectl blameer.

’n Tydverstryking is ’n roeteprobleem. ’n 403 is ’n beleidsprobleem. Hulle deel nie ’n oplossing nie.

Kontrole 4: skei logs en exec van API-oproepe

As gewone API-versoeke slaag en kubectl logs of kubectl exec misluk, is jy reeds verby die keuse van die eindpunt. Daardie bewerkings benodig die ooreenstemmende Kubernetes-regte en hang af van kommunikasie tussen die beheervlak en die nodus, en die mislukking kan ’n Forbidden-antwoord wees eerder as ’n tydverstryking. SSH-toegang tot ’n nodus toets heeltemal ’n ander diens en vestig hulle nie.

Lees die foutklas voordat jy die VPN-kaartjie heropen, want die twee klasse woon op verskillende plekke.

Kontrole 5: hou drie waarnemings vir die volgende persoon

Teken die gekose API-URL aan, of een gemagtigde API-versoek werk, en presies watter latere bewerking misluk, saam met die foutteks. Daardie drie reëls skei die keuse van die eindpunt van nodustoegang, en hulle keer dat ’n heeltemal goeie VPN-roete geblameer word vir ’n versoek wat dit nooit gedra het nie.

Die volgende ingenieur sal vra of die tonnel stukkend is. Jou nota behoort dit alreeds te antwoord.