Private GKE-noder afgør ikke, hvilken API kubectl bruger

Noderne er private, VPN'et når dem, og alligevel kan kubectl ikke tale med klyngen. De to kendsgerninger har intet med hinanden at gøre. Den adresse, kubectl bruger, kommer fra serverens URL, der blev gemt i kubeconfig, da legitimationsoplysningerne blev hentet, og ingen rute, du tilføjer, ændrer den. Samtidig er noderne ikke det, kubectl overhovedet forsøger at nå.

Fem kontroller, startende med den eneste værdi, der betyder noget.

Kontrol 1: læs serverens URL i kubeconfig

Udskriv endepunktet uden at dumpe legitimationsoplysningerne: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Den ene streng fortæller dig, om klienten peger på en IP-adresse, et DNS-navn eller en ekstern adresse, du ikke havde til hensigt. Alt andet i denne undersøgelse følger af den.

Hvis URL'en ikke er det endepunkt, du troede, du havde konfigureret, er resten af diagnosen en afledning.

Kontrol 2: match URL'en med endepunktstypen

Nuværende GKE understøtter både IP-baseret og DNS-baseret adgang til kontrolplanet, og de legitimationsoplysninger, du henter, vælger en af dem. gcloud container clusters get-credentials NAME --location REGION --internal-ip skriver det interne IP-endepunkt, mens --dns-endpoint vælger DNS-baseret adgang. Ingen af flagene etablerer en netværksrute, hvilket overrasker folk, der forventer, at hentningen retter forbindelsen. Gentag hentningen bevidst, og læs URL'en igen bagefter.

At ændre flag uden at læse URL'en igen er måden, hvorpå en laptop ender med legitimationsoplysninger til to klynger og én forvirrende fejl.

En post i det autoriserede netværk bestemmer, hvem der må nå et eksternt endepunkt, og gælder ikke for det interne. At udvide den for at teste en privat rute ændrer din eksponering, ikke din diagnose.

Kontrol 3: bevis ruten til det endepunkt

Hvis URL'en er en intern IP, skal du kontrollere ruten fra det netværk, klienten faktisk står på, det tilladte kildeområde og klyngens regionale eller globale adgangsindstilling. Kontrolplanets område og nodes undernet er ikke samme destination, så en fungerende rute til noderne beviser intet om endepunktet. For DNS-baseret adgang er ruten Google API-forbindelse med dens dokumenterede Private Google Access-ordning, ikke en rute til arbejdernes undernet. Test endepunktet med en almindelig TCP-forbindelse, før du bebrejder kubectl.

En timeout er et ruteproblem. En 403 er et politikproblem. De deler ikke en løsning.

Kontrol 4: adskil logfiler og exec fra API-kald

Hvis almindelige API-anmodninger lykkes, og kubectl logs eller kubectl exec fejler, er du allerede forbi valget af endepunkt. De operationer kræver de tilsvarende Kubernetes-tilladelser og afhænger af kommunikation mellem kontrolplanet og noderne, og fejlen kan være et Forbidden-svar i stedet for en timeout. SSH-adgang til en node tester en helt anden tjeneste og etablerer dem ikke.

Læs fejlklassen, før du genåbner VPN-billetten, fordi de to klasser bor forskellige steder.

Kontrol 5: gem tre observationer til den næste person

Notér den valgte API-URL, om én autoriseret API-anmodning virker, og præcis hvilken senere operation der fejler, sammen med fejlteksten. De tre linjer adskiller valg af endepunkt fra nodeadgang og forhindrer, at en fuldstændig god VPN-rute bliver bebrejdet for en anmodning, den aldrig har båret.

Den næste ingeniør vil spørge, om tunnelen er brudt. Dit notat bør allerede svare på det.