Os nós privados do GKE não decidem qual API o kubectl usa

Os nós são privados, a VPN chega até eles e, mesmo assim, o kubectl não consegue falar com o cluster. Esses dois factos não têm relação. O endereço que o kubectl usa vem do URL do servidor guardado no kubeconfig quando as credenciais foram obtidas, e nenhuma rota que acrescente o altera. Entretanto, os nós não são aquilo que o kubectl está a tentar alcançar em primeiro lugar.

Cinco verificações, começando pelo único valor que importa.

Verificação 1: leia o URL do servidor no kubeconfig

Imprima o endpoint sem despejar as credenciais: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Essa única cadeia diz-lhe se o cliente aponta para um endereço IP, um nome DNS ou um endereço externo que não pretendia. Tudo o resto nesta investigação decorre dela.

Se o URL não for o endpoint que pensava ter configurado, o resto do diagnóstico é uma distração.

Verificação 2: faça corresponder o URL ao tipo de endpoint

O GKE atual suporta acesso ao plano de controlo baseado em IP e em DNS, e as credenciais que obtém escolhem um deles. gcloud container clusters get-credentials NAME --location REGION --internal-ip escreve o endpoint de IP interno, enquanto --dns-endpoint seleciona o acesso baseado em DNS. Nenhuma das opções fornece um caminho de rede, o que surpreende quem espera que a obtenção corrija a conectividade. Repita a obtenção deliberadamente e leia o URL outra vez depois.

Alterar opções sem reler o URL é como um portátil acaba com credenciais de dois clusters e um erro confuso.

Uma entrada de rede autorizada determina quem pode alcançar um endpoint externo e não se aplica ao interno. Alargá-la para testar um caminho privado altera a sua exposição, não o seu diagnóstico.

Verificação 3: prove o caminho até esse endpoint

Se o URL for um IP interno, verifique a rota a partir da rede onde o cliente está realmente, o intervalo de origem permitido e a definição de acesso regional ou global do cluster. O intervalo do plano de controlo e a sub-rede dos nós não são o mesmo destino, por isso uma rota funcional até aos nós não prova nada sobre o endpoint. Para acesso baseado em DNS, o caminho é a conectividade com a API Google com o seu mecanismo documentado Private Google Access, não uma rota para a sub-rede dos trabalhadores. Teste o endpoint com uma ligação TCP simples antes de culpar o kubectl.

Um tempo limite é um problema de caminho. Um 403 é um problema de política. Não partilham a mesma solução.

Verificação 4: separe os registos e o exec das chamadas de API

Se os pedidos de API normais funcionam e o kubectl logs ou o kubectl exec falha, já passou da seleção do endpoint. Essas operações precisam das permissões Kubernetes correspondentes e dependem da comunicação do plano de controlo com os nós, e a falha pode ser uma resposta Forbidden em vez de um tempo limite. O acesso SSH a um nó testa um serviço completamente diferente e não os estabelece.

Leia a classe de erro antes de reabrir o ticket da VPN, porque as duas classes vivem em locais diferentes.

Verificação 5: guarde três observações para a próxima pessoa

Registe o URL da API selecionado, se um pedido de API autorizado funciona e exatamente que operação posterior falha, com o texto do erro. Essas três linhas separam a seleção do endpoint do acesso aos nós, e impedem que uma rota VPN perfeitamente boa seja culpada por um pedido que nunca transportou.

O próximo engenheiro perguntará se o túnel está partido. A sua nota já devia responder a isso.