Privee GKE-knopen bepale net hokker API kubectl brûkt

De knopen binne privee, de VPN berikt se, en dochs kin kubectl net mei it cluster prate. Dy twa feiten hawwe neat mei elkoar te meitsjen. It adres dat kubectl brûkt, komt út de tsjinner-URL dy't yn 'e kubeconfig bewarre waard doe't de oanmeldinggegevens ophelle waarden, en gjin rûte dy't jo tafoegje feroaret dat. Underwilens binne de knopen hielendal net wat kubectl besiket te berikken.

Fiif kontrôles, begjinnend mei de iennichste wearde dy't ta docht.

Kontrôle 1: lês de tsjinner-URL yn 'e kubeconfig

Print it einpunt sûnder de oanmeldinggegevens út te jaan: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Dy iene string fertelt jo oft de klant nei in IP-adres, in DNS-namme of in ekstern adres wiist dat jo net bedoelden. Al it oare yn dit ûndersyk folget dêrút.

As de URL net it einpunt is dat jo tochten dat jo konfigurearre hiene, is de rest fan 'e diagnoaze in ôflieding.

Kontrôle 2: jou de URL by it type einpunt

It hjoeddeistige GKE stipet sawol IP-basearre as DNS-basearre tagong ta it kontrôleflak, en de oanmeldinggegevens dy't jo ophelje kieze ien. gcloud container clusters get-credentials NAME --location REGION --internal-ip skriuwt it einpunt fan it ynterne IP, wylst --dns-endpoint DNS-basearre tagong kiest. Gjin fan beide flaggen soarget foar in netwurkrûte, wat minsken ferrast dy't ferwachtsje dat it opheljen de ferbining reparearret. Werhelje it opheljen bewust en lês de URL dêrnei wer.

Flaggen feroarje sûnder de URL opnij te lêzen is hoe't in laptop mei de oanmeldinggegevens fan twa clusters en ien betiizjende flater einiget.

In ynskriuwing yn it autorisearre netwurk bepaalt wa't in ekstern einpunt berikke mei en jildt net foar it ynterne. It ferbreedzjen om in privee paad te testen feroaret jo bleatstelling, net jo diagnoaze.

Kontrôle 3: bewiis it paad nei dat einpunt

As de URL in yntern IP is, kontrolearje dan de rûte fan it netwurk dêr't de klant echt sit, it tastiene boarneberik en de regionale of globale tagongsynstelling fan it cluster. It berik fan it kontrôleflak en it subnet fan 'e knopen binne net deselde bestemming, dus in wurkjende rûte nei de knopen bewiist neat oer it einpunt. Foar DNS-basearre tagong is it paad Google API-ferbining mei syn dokumintearre Private Google Access-regeling, net in rûte nei it subnet fan 'e wurknimmers. Test it einpunt mei in gewoane TCP-ferbining foardat jo kubectl de skuld jouwe.

In time-out is in paadprobleem. In 403 is in beliedsprobleem. Se diele gjin oplossing.

Kontrôle 4: skied logs en exec fan API-oproppen

As gewoane API-fersiken slagje en kubectl logs of kubectl exec mislearret, binne jo al foarby de kar fan it einpunt. Dy bewurkingen hawwe de oerienkommende Kubernetes-rjochten nedich en hingje ôf fan kommunikaasje fan it kontrôleflak nei de knopen, en de mislearring kin in Forbidden-antwurd wêze ynstee fan in time-out. SSH-tagong ta in knoop test in hiel oare tsjinst en fêstiget se net.

Lês de flaterklasse foardat jo it VPN-ticket wer iepenje, want de twa klassen libje op ferskate plakken.

Kontrôle 5: bewarje trije waarnimmings foar de folgjende persoan

Skriuw de keazen API-URL op, oft ien autorisearre API-fersyk wurket, en krekt hokker lettere bewurking mislearret, mei de flatertekst. Dy trije rigels skiede de kar fan it einpunt fan knooptagong, en se foarkomme dat in folslein goede VPN-rûte de skuld kriget foar in fersyk dat se nea droech.

De folgjende yngenieur sil freegje oft de tunnel stikken is. Jo notysje soe dat al antwurdzje moatte.