Les nœuds GKE privés ne décident pas de l’API utilisée par kubectl

Les nœuds sont privés, le VPN les atteint, et kubectl ne peut toujours pas parler au cluster. Ces deux faits n’ont aucun rapport. L’adresse qu’utilise kubectl provient de l’URL du serveur enregistrée dans le kubeconfig lors de la récupération des identifiants, et aucune route que vous ajoutez ne la change. Pendant ce temps, les nœuds ne sont pas du tout ce que kubectl cherche à atteindre.

Cinq vérifications, en commençant par la seule valeur qui compte.

Vérification 1 : lisez l’URL du serveur dans le kubeconfig

Affichez le point de terminaison sans déverser les identifiants : kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Cette seule chaîne vous dit si le client pointe vers une adresse IP, un nom DNS ou une adresse externe que vous ne vouliez pas. Tout le reste de cette enquête en découle.

Si l’URL n’est pas le point de terminaison que vous pensiez avoir configuré, le reste du diagnostic est une distraction.

Vérification 2 : faites correspondre l’URL au type de point de terminaison

GKE prend actuellement en charge l’accès au plan de contrôle à la fois par IP et par DNS, et les identifiants que vous récupérez en choisissent un. gcloud container clusters get-credentials NAME --location REGION --internal-ip écrit le point de terminaison IP interne, tandis que --dns-endpoint sélectionne l’accès par DNS. Aucun des deux indicateurs ne fournit de chemin réseau, ce qui surprend ceux qui attendent de la récupération qu’elle corrige la connectivité. Relancez la récupération délibérément, puis relisez l’URL ensuite.

Changer les indicateurs sans relire l’URL, c’est ainsi qu’un ordinateur portable finit avec les identifiants de deux clusters et une erreur déroutante.

Une entrée de réseau autorisé détermine qui peut atteindre un point de terminaison externe et ne s’applique pas à l’interne. L’élargir pour tester un chemin privé change votre exposition, pas votre diagnostic.

Vérification 3 : prouvez le chemin vers ce point de terminaison

Si l’URL est une IP interne, vérifiez la route depuis le réseau où se trouve réellement le client, la plage source autorisée et le paramètre d’accès régional ou global du cluster. La plage du plan de contrôle et le sous-réseau des nœuds ne sont pas la même destination, donc une route qui fonctionne vers les nœuds ne prouve rien sur le point de terminaison. Pour l’accès par DNS, le chemin est la connectivité à l’API Google avec son dispositif documenté Private Google Access, et non une route vers le sous-réseau des workers. Testez le point de terminaison avec une simple connexion TCP avant d’accuser kubectl.

Un délai d’attente est un problème de chemin. Un 403 est un problème de stratégie. Ils ne partagent pas de correctif.

Vérification 4 : séparez les journaux et exec des appels API

Si les requêtes API ordinaires réussissent et que kubectl logs ou kubectl exec échoue, vous avez déjà dépassé la sélection du point de terminaison. Ces opérations nécessitent les autorisations Kubernetes correspondantes et dépendent de la communication entre le plan de contrôle et les nœuds, et l’échec peut être une réponse Forbidden plutôt qu’un délai d’attente. L’accès SSH à un nœud teste un tout autre service et ne les établit pas.

Lisez la classe d’erreur avant de rouvrir le ticket VPN, car les deux classes vivent à des endroits différents.

Vérification 5 : conservez trois observations pour la personne suivante

Notez l’URL d’API sélectionnée, si une requête API autorisée fonctionne et exactement quelle opération ultérieure échoue, avec le texte de l’erreur. Ces trois lignes séparent la sélection du point de terminaison de l’accès aux nœuds, et elles empêchent qu’une route VPN parfaitement valable soit blâmée pour une requête qu’elle n’a jamais transportée.

Le prochain ingénieur demandera si le tunnel est cassé. Votre note devrait déjà répondre à cela.