Els nodes privats de GKE no decideixen quin API fa servir kubectl

Els nodes són privats, la VPN els arriba i, tot i així, kubectl no pot parlar amb el clúster. Aquests dos fets no tenen res a veure. L'adreça que fa servir kubectl prové de l'URL del servidor desada al kubeconfig quan es van obtenir les credencials, i cap ruta que afegeixis la canvia. Mentrestant, els nodes no són el que kubectl intenta assolir en primer lloc.

Cinc comprovacions, començant per l'únic valor que importa.

Comprovació 1: llegeix l'URL del servidor al kubeconfig

Imprimeix el punt final sense abocar les credencials: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Aquesta única cadena et diu si el client apunta a una adreça IP, a un nom DNS o a una adreça externa que no volies. Tota la resta d'aquesta investigació en deriva.

Si l'URL no és el punt final que pensaves que havies configurat, la resta del diagnòstic és una distracció.

Comprovació 2: fes coincidir l'URL amb el tipus de punt final

El GKE actual admet tant l'accés al pla de control basat en IP com el basat en DNS, i les credencials que obtens n'escullen un. gcloud container clusters get-credentials NAME --location REGION --internal-ip escriu el punt final d'IP interna, mentre que --dns-endpoint selecciona l'accés basat en DNS. Cap dels dos indicadors no proporciona un camí de xarxa, cosa que sorprèn qui espera que l'obtenció arregli la connectivitat. Torna a obtenir les credencials deliberadament i torna a llegir l'URL després.

Canviar indicadors sense tornar a llegir l'URL és com un portàtil acaba amb credencials de dos clústers i un error confús.

Una entrada de xarxa autoritzada determina qui pot arribar a un punt final extern i no s'aplica a l'intern. Eixamplar-la per provar un camí privat canvia la teva exposició, no el teu diagnòstic.

Comprovació 3: demostra el camí fins a aquest punt final

Si l'URL és una IP interna, verifica la ruta des de la xarxa on és realment el client, el rang d'origen permès i el paràmetre d'accés regional o global del clúster. El rang del pla de control i la subxarxa dels nodes no són la mateixa destinació, així que una ruta que funciona fins als nodes no demostra res sobre el punt final. Per a l'accés basat en DNS, el camí és la connectivitat amb l'API de Google amb el seu mecanisme documentat Private Google Access, no una ruta cap a la subxarxa dels treballadors. Prova el punt final amb una connexió TCP simple abans de culpar kubectl.

Un temps d'espera és un problema de camí. Un 403 és un problema de política. No comparteixen solució.

Comprovació 4: separa els registres i l'exec de les crides a l'API

Si les peticions normals a l'API funcionen i kubectl logs o kubectl exec fallen, ja has superat la selecció del punt final. Aquestes operacions necessiten els permisos de Kubernetes corresponents i depenen de la comunicació del pla de control amb els nodes, i la fallada pot ser una resposta Forbidden en lloc d'un temps d'espera. L'accés SSH a un node prova un servei completament diferent i no els estableix.

Llegeix la classe d'error abans de reobrir el tiquet de la VPN, perquè les dues classes viuen en llocs diferents.

Comprovació 5: desa tres observacions per a la propera persona

Anota l'URL de l'API seleccionat, si una petició autoritzada a l'API funciona i exactament quina operació posterior falla, amb el text de l'error. Aquestes tres línies separen la selecció del punt final de l'accés als nodes, i eviten que una ruta VPN perfectament bona sigui culpada d'una petició que mai va transportar.

El proper enginyer preguntarà si el túnel està trencat. La teva nota ja hauria de respondre-ho.