minikube não alcança uma API privada? Verifique o driver primeiro

O host, o nó e o Pod têm suas próprias rotas e seu próprio resolvedor. Nomeie o driver, teste o mesmo endpoint nos três e corrija o contexto que falhou.

Uma API privada responde do seu notebook e um Pod no minikube não consegue alcançá-la. Antes de mudar qualquer coisa no host, nomeie o driver por trás do perfil ativo, porque esse único fato decide de qual rede a requisição realmente sai. Depois teste o mesmo endpoint do host, do nó e do Pod. Apenas um desses três é o que falhou, e errar o palpite custa uma tarde.

Etapa 0: nomear o driver e a origem

Pergunte ao minikube qual perfil está ativo e como ele está rodando. Um driver de contêiner coloca o nó em um contêiner na sua máquina, um driver de VM o coloca em uma máquina virtual, e um driver remoto o coloca em outro lugar completamente.

minikube profile list
minikube status
kubectl config current-context

A partir disso, anote de onde a requisição se origina. A resposta determina qual resolvedor e quais rotas importam, e nem sempre é o do host. Dois perfis no mesmo notebook podem se comportar de forma totalmente diferente para a mesma URL.

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

Etapa 1: testar o mesmo endpoint três vezes

Use um endpoint inofensivo e mantenha o nome do host, a porta e a família de endereços idênticos nos três testes. Mudar qualquer um deles entre execuções torna os resultados incomparáveis.

curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health

Um pull de imagem bem-sucedido pelo nó não prova nada sobre a resolução de nomes para um host privado. Uma requisição pública bem-sucedida prova ainda menos. Mantenha os resultados separados por contexto, porque um padrão em três linhas é um diagnóstico e uma falha isolada é uma pista.

Se a linha do host também falhar, pare. Você tem um problema de rede no host e o cluster é uma distração.

Etapa 2: manter o caminho do host até o cluster

Há uma segunda direção que as pessoas esquecem: o host precisa continuar alcançando a API e os serviços do próprio cluster. Um cliente VPN pode instalar rotas que competem com os prefixos que o minikube usa para a rede de nós, a faixa de serviços e a faixa de pods.

Quando isso acontece, o sintoma é confuso, porque o túnel funciona e o kubectl para de responder ou um NodePort recusa conexões. Parece uma falha do cluster e é uma falha de roteamento do notebook.

Verifique a tabela de rotas do host contra as faixas do minikube antes de culpar o túnel por qualquer outra coisa. A sobreposição normalmente aparece como uma rota mais específica apontando para a interface do túnel para um prefixo que o cluster espera possuir.

Etapa 3: resolver a sobreposição sem desativar a VPN

O próprio manual de VPN e proxy do minikube discute esses conflitos e trata suas faixas de exemplo como coisas a inspecionar, não como uma lista universal. Leia-o junto com o perfil que você realmente tem.

Onde existe uma sobreposição real, a resposta suportada é uma faixa não sobreposta ou uma política deliberada de acesso local aprovada por quem é responsável pela VPN. Mudar a faixa de serviços não é o mesmo que mudar a faixa de pods, e nenhuma das duas é o mesmo que mudar a rede de nós.

Desativar o túnel corporativo para fazer um cluster local funcionar não é uma gambiarra; é uma decisão de política que outra pessoa precisa tomar. Leve-a a essa pessoa em vez de fazer isso em silêncio depois que todos os outros forem para casa. Se você já fez, coloque de volta antes de perguntar.

Etapa 4: separar proxy, DNS e quatro formas de falha

Se um proxy for necessário, identifique qual contexto precisa dele. Uma configuração de navegador no host não configura um processo dentro do nó, e um Pod precisa das variáveis de ambiente ou de uma configuração de proxy no nível do cluster.

Depois classifique a falha em vez de descrevê-la. Um nome que não resolve é DNS. Um nome que resolve e recusa uma conexão é roteamento ou um listener. Uma conexão que se estabelece e falha na identidade é TLS. Uma conexão bem-sucedida com um corpo de erro é a aplicação.

Cada uma dessas quatro pertence a uma correção diferente, e apenas uma delas é sobre a VPN. Anote qual você observou em cada contexto, e a próxima pessoa herda evidências em vez de uma história.

Artigos relacionados