Os nodos privados de GKE non deciden que API usa kubectl

Os nodos son privados, a VPN chega ata eles e, aínda así, kubectl non pode falar co clúster. Esas dúas realidades non teñen relación. A dirección que usa kubectl provén da URL do servidor gardada no kubeconfig cando se obtiveron as credenciais, e ningunha ruta que engadas a cambia. Mentres tanto, os nodos non son o que kubectl intenta alcanzar en primeiro lugar.

Cinco comprobacións, empezando polo único valor que importa.

Comprobación 1: le a URL do servidor no kubeconfig

Imprime o punto de conexión sen verter as credenciais: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Esa única cadea dinte se o cliente apunta a unha dirección IP, a un nome DNS ou a unha dirección externa que non pretendías. Todo o demais nesta investigación deriva dela.

Se a URL non é o punto de conexión que pensabas que tiñas configurado, o resto do diagnóstico é unha distracción.

Comprobación 2: fai coincidir a URL co tipo de punto de conexión

O GKE actual admite tanto o acceso ao plano de control baseado en IP como o baseado en DNS, e as credenciais que obtés elixen un. gcloud container clusters get-credentials NAME --location REGION --internal-ip escribe o punto de conexión de IP interna, mentres que --dns-endpoint selecciona o acceso baseado en DNS. Ningunha das dúas opcións proporciona unha ruta de rede, o que sorprende a quen espera que a obtención arranxe a conectividade. Volve obter as credenciais a propósito e le a URL outra vez despois.

Cambiar as opcións sen volver ler a URL é como un portátil acaba con credenciais de dous clústers e un erro confuso.

Unha entrada de rede autorizada determina quen pode alcanzar un punto de conexión externo e non se aplica ao interno. Ampliala para probar unha ruta privada cambia a túa exposición, non o teu diagnóstico.

Comprobación 3: demostra a ruta ata ese punto de conexión

Se a URL é unha IP interna, verifica a ruta desde a rede na que está realmente o cliente, o rango de orixe permitido e o axuste de acceso rexional ou global do clúster. O rango do plano de control e a subrede dos nodos non son o mesmo destino, así que unha ruta que funciona ata os nodos non demostra nada sobre o punto de conexión. Para o acceso baseado en DNS, a ruta é a conectividade coa API de Google co seu mecanismo documentado Private Google Access, non unha ruta cara á subrede dos traballadores. Proba o punto de conexión cunha conexión TCP simple antes de culpar a kubectl.

Un tempo de espera é un problema de ruta. Un 403 é un problema de política. Non comparten solución.

Comprobación 4: separa os rexistros e exec das chamadas á API

Se as peticións normais á API funcionan e kubectl logs ou kubectl exec fallan, xa pasaches a selección do punto de conexión. Esas operacións necesitan os permisos de Kubernetes correspondentes e dependen da comunicación do plano de control cos nodos, e o fallo pode ser unha resposta Forbidden en lugar dun tempo de espera. O acceso SSH a un nodo proba un servizo completamente distinto e non os establece.

Le a clase de erro antes de reabrir o tícket da VPN, porque as dúas clases viven en lugares diferentes.

Comprobación 5: garda tres observacións para a próxima persoa

Anota a URL da API seleccionada, se unha petición autorizada á API funciona e exactamente que operación posterior falla, co texto do erro. Esas tres liñas separan a selección do punto de conexión do acceso aos nodos, e evitan que unha ruta VPN perfectamente boa sexa culpada dunha petición que nunca transportou.

O seguinte enxeñeiro preguntará se o túnel está roto. A túa nota xa debería responder a iso.