Los nodos privados de GKE no deciden qué API usa kubectl

Los nodos son privados, la VPN llega hasta ellos y, aun así, kubectl no puede hablar con el clúster. Esos dos hechos no tienen relación. La dirección que usa kubectl proviene de la URL del servidor guardada en kubeconfig cuando se obtuvieron las credenciales, y ninguna ruta que añadas la cambia. Mientras tanto, los nodos no son lo que kubectl intenta alcanzar en primer lugar.

Cinco comprobaciones, empezando por el único valor que importa.

Comprobación 1: lee la URL del servidor en kubeconfig

Imprime el punto de conexión sin volcar las credenciales: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Esa única cadena te dice si el cliente apunta a una dirección IP, a un nombre DNS o a una dirección externa que no pretendías. Todo lo demás en esta investigación se deriva de ella.

Si la URL no es el punto de conexión que creías haber configurado, el resto del diagnóstico es una distracción.

Comprobación 2: haz coincidir la URL con el tipo de punto de conexión

El GKE actual admite tanto el acceso al plano de control basado en IP como el basado en DNS, y las credenciales que obtienes eligen uno. gcloud container clusters get-credentials NAME --location REGION --internal-ip escribe el punto de conexión de IP interna, mientras que --dns-endpoint selecciona el acceso basado en DNS. Ninguno de los dos indicadores proporciona una ruta de red, lo que sorprende a quien espera que la obtención arregle la conectividad. Vuelve a obtener las credenciales a propósito y lee la URL otra vez después.

Cambiar indicadores sin volver a leer la URL es como un portátil acaba con credenciales de dos clústeres y un error confuso.

Una entrada de red autorizada determina quién puede alcanzar un punto de conexión externo y no se aplica al interno. Ampliarla para probar una ruta privada cambia tu exposición, no tu diagnóstico.

Comprobación 3: demuestra la ruta hasta ese punto de conexión

Si la URL es una IP interna, verifica la ruta desde la red en la que está realmente el cliente, el rango de origen permitido y el ajuste de acceso regional o global del clúster. El rango del plano de control y la subred de los nodos no son el mismo destino, así que una ruta que funciona hasta los nodos no demuestra nada sobre el punto de conexión. Para el acceso basado en DNS, la ruta es la conectividad con la API de Google con su mecanismo documentado Private Google Access, no una ruta hacia la subred de los trabajadores. Prueba el punto de conexión con una conexión TCP simple antes de culpar a kubectl.

Un tiempo de espera es un problema de ruta. Un 403 es un problema de política. No comparten solución.

Comprobación 4: separa los registros y exec de las llamadas a la API

Si las peticiones normales a la API funcionan y kubectl logs o kubectl exec fallan, ya has superado la selección del punto de conexión. Esas operaciones necesitan los permisos de Kubernetes correspondientes y dependen de la comunicación del plano de control con los nodos, y el fallo puede ser una respuesta Forbidden en lugar de un tiempo de espera. El acceso SSH a un nodo prueba un servicio completamente distinto y no los establece.

Lee la clase de error antes de reabrir el tiquete de la VPN, porque las dos clases viven en lugares diferentes.

Comprobación 5: guarda tres observaciones para la próxima persona

Anota la URL de la API seleccionada, si una petición autorizada a la API funciona y exactamente qué operación posterior falla, con el texto del error. Esas tres líneas separan la selección del punto de conexión del acceso a los nodos, y evitan que una ruta VPN perfectamente buena sea culpada de una petición que nunca transportó.

El siguiente ingeniero preguntará si el túnel está roto. Tu nota ya debería responderlo.