minikube non raggiunge un’API privata? Controlla prima il driver

Un’API privata risponde dal tuo portatile e un Pod in minikube non riesce a raggiungerla. Prima di cambiare qualcosa sull’host, nomina il driver dietro il profilo attivo, perché quel singolo fatto decide da quale rete esce realmente la richiesta. Poi prova lo stesso endpoint dall’host, dal nodo e dal Pod. Solo uno di quei tre è ciò che ha fallito, e sbagliare la supposizione costa un pomeriggio.

Passo 0: nominare il driver e l’origine

Chiedi a minikube quale profilo è attivo e come è in esecuzione. Un driver per container mette il nodo in un container sulla tua macchina, un driver per VM lo mette in una macchina virtuale, e un driver remoto lo mette da un’altra parte del tutto.

minikube profile list
minikube status
kubectl config current-context

Da lì, annota da dove origina la richiesta. La risposta determina quale resolver e quali route contano, e non sempre è quello dell’host. Due profili sullo stesso portatile possono comportarsi in modo completamente diverso per lo stesso URL.

Passo 1: provare tre volte lo stesso endpoint

Usa un endpoint innocuo e mantieni identici il nome host, la porta e la famiglia di indirizzi in tutte e tre le prove. Cambiare uno di essi tra un’esecuzione e l’altra rende i risultati incomparabili.

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

Un pull di immagine riuscito da parte del nodo non dimostra nulla sulla risoluzione dei nomi per un host privato. Una richiesta pubblica riuscita dimostra ancora meno. Tieni separati i risultati per contesto, perché uno schema su tre righe è una diagnosi e un singolo fallimento è un indizio.

Se fallisce anche la riga dell’host, fermati. Hai un problema di rete sull’host e il cluster è una distrazione.

Passo 2: conservare il percorso dell’host verso il cluster

C’è una seconda direzione che le persone dimenticano: l’host deve continuare a raggiungere l’API e i servizi del cluster stesso. Un client VPN può installare route che competono con i prefissi che minikube usa per la rete dei nodi, l’intervallo dei servizi e l’intervallo dei pod.

Quando succede, il sintomo è confuso, perché il tunnel funziona e kubectl smette di rispondere oppure un NodePort rifiuta le connessioni. Sembra un guasto del cluster ed è un guasto di routing del portatile.

Controlla la tabella di routing dell’host rispetto agli intervalli di minikube prima di dare la colpa al tunnel per qualsiasi altra cosa. La sovrapposizione di solito si vede come una route più specifica che punta all’interfaccia del tunnel per un prefisso che il cluster si aspetta di possedere.

Passo 3: risolvere la sovrapposizione senza disattivare la VPN

Il manuale VPN e proxy di minikube stesso discute questi conflitti e tratta i suoi intervalli di esempio come cose da ispezionare, non come un elenco universale. Leggilo insieme al profilo che hai davvero.

Dove esiste una vera sovrapposizione, la risposta supportata è un intervallo non sovrapposto o una policy di accesso locale deliberata approvata da chi gestisce la VPN. Cambiare l’intervallo dei servizi non è la stessa cosa che cambiare l’intervallo dei pod, e nessuna delle due equivale a cambiare la rete dei nodi.

Disattivare il tunnel aziendale per far funzionare un cluster locale non è un espediente; è una decisione di policy che deve prendere qualcun altro. Portala a quella persona invece di farla in silenzio dopo che tutti gli altri sono andati a casa. Se l’hai già fatto, rimettilo a posto prima di chiedere.

Passo 4: separare proxy, DNS e quattro forme di guasto

Se è richiesto un proxy, individua quale contesto ne ha bisogno. Un’impostazione del browser sull’host non configura un processo dentro il nodo, e un Pod ha bisogno delle variabili d’ambiente o di una configurazione proxy a livello di cluster.

Poi classifica il guasto invece di descriverlo. Un nome che non si risolve è DNS. Un nome che si risolve e rifiuta una connessione è routing o un listener. Una connessione che si stabilisce e fallisce sull’identità è TLS. Una connessione riuscita con un corpo di errore è l’applicazione.

Ognuno di quei quattro appartiene a una correzione diversa, e solo uno riguarda la VPN. Annota quale hai osservato in ogni contesto, e la persona successiva eredita prove invece di un racconto.