I nodi privati di GKE non decidono quale API usa kubectl

I nodi sono privati, la VPN li raggiunge e kubectl continua a non riuscire a parlare con il cluster. Questi due fatti non hanno rapporto. L’indirizzo usato da kubectl proviene dall’URL del server salvato nel kubeconfig al momento del recupero delle credenziali, e nessuna rotta che aggiungi lo cambia. Nel frattempo, i nodi non sono affatto ciò che kubectl sta cercando di raggiungere.

Cinque verifiche, iniziando dall’unico valore che conta.

Verifica 1: leggi l’URL del server nel kubeconfig

Stampa l’endpoint senza riversare le credenziali: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Quella singola stringa ti dice se il client punta a un indirizzo IP, a un nome DNS o a un indirizzo esterno che non intendevi. Tutto il resto di questa indagine deriva da lì.

Se l’URL non è l’endpoint che pensavi di aver configurato, il resto della diagnosi è una distrazione.

Verifica 2: abbina l’URL al tipo di endpoint

L’attuale GKE supporta l’accesso al piano di controllo sia basato su IP sia su DNS, e le credenziali che recuperi ne scelgono uno. gcloud container clusters get-credentials NAME --location REGION --internal-ip scrive l’endpoint con IP interno, mentre --dns-endpoint seleziona l’accesso basato su DNS. Nessuno dei due flag fornisce un percorso di rete, cosa che sorprende chi si aspetta che il recupero sistemi la connettività. Ripeti il recupero deliberatamente e poi rileggi l’URL.

Cambiare i flag senza rileggere l’URL è il modo in cui un portatile finisce con le credenziali di due cluster e un errore confuso.

Una voce di rete autorizzata stabilisce chi può raggiungere un endpoint esterno e non si applica a quello interno. Ampliarla per testare un percorso privato cambia la tua esposizione, non la tua diagnosi.

Verifica 3: dimostra il percorso verso quell’endpoint

Se l’URL è un IP interno, verifica la rotta dalla rete in cui il client si trova davvero, l’intervallo di origine consentito e l’impostazione di accesso regionale o globale del cluster. L’intervallo del piano di controllo e la sottorete dei nodi non sono la stessa destinazione, quindi una rotta funzionante verso i nodi non dimostra nulla sull’endpoint. Per l’accesso basato su DNS il percorso è la connettività alle API di Google con il suo meccanismo documentato Private Google Access, non una rotta verso la sottorete dei worker. Prova l’endpoint con una semplice connessione TCP prima di dare la colpa a kubectl.

Un timeout è un problema di percorso. Un 403 è un problema di criterio. Non condividono una soluzione.

Verifica 4: separa i log e exec dalle chiamate API

Se le normali richieste API riescono e kubectl logs o kubectl exec falliscono, hai già superato la scelta dell’endpoint. Quelle operazioni richiedono le autorizzazioni Kubernetes corrispondenti e dipendono dalla comunicazione tra piano di controllo e nodi, e l’errore può essere una risposta Forbidden invece di un timeout. L’accesso SSH a un nodo verifica un servizio completamente diverso e non le stabilisce.

Leggi la classe di errore prima di riaprire il ticket VPN, perché le due classi vivono in posti diversi.

Verifica 5: conserva tre osservazioni per la persona successiva

Annota l’URL API scelto, se una richiesta API autorizzata funziona e esattamente quale operazione successiva fallisce, con il testo dell’errore. Quelle tre righe separano la scelta dell’endpoint dall’accesso ai nodi, e impediscono che una rotta VPN perfettamente valida venga incolpata di una richiesta che non ha mai trasportato.

Il prossimo ingegnere chiederà se il tunnel è rotto. La tua nota dovrebbe già rispondere.