minikube no arriba a una API privada? Comprova primer el controlador
L'amfitrió, el node i el Pod tenen les seves pròpies rutes i el seu propi resolver. Anomena el controlador, prova el mateix endpoint des dels tres i després corregeix el context que ha fallat.
Una API privada respon des del teu portàtil i un Pod a minikube no pot arribar-hi. Abans de canviar res a l'amfitrió, anomena el controlador que hi ha darrere del perfil actiu, perquè aquest únic fet decideix de quina xarxa surt realment la petició. Després prova el mateix endpoint des de l'amfitrió, des del node i des del Pod. Només un d'aquests tres és el que ha fallat, i una suposició errònia costa una tarda.
Pas 0: anomena el controlador i l'origen
Pregunta a minikube quin perfil és actiu i com s'executa. Un controlador de contenidor posa el node en un contenidor a la teva màquina, un controlador de VM el posa en una màquina virtual, i un controlador remot el posa en un lloc completament diferent.
minikube profile list
minikube status
kubectl config current-contextA partir d'això, anota d'on neix la petició. La resposta determina quin resolver i quines rutes importen, i no sempre és el de l'amfitrió. Dos perfils al mateix portàtil poden comportar-se de manera completament diferent per al mateix URL.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
Pas 1: prova el mateix endpoint tres vegades
Utilitza un endpoint inofensiu i mantén el mateix nom d'amfitrió, el mateix port i la mateixa família d'adreces en les tres proves. Canviar-ne qualsevol entre execucions fa que els resultats no siguin comparables.
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/healthUna baixada d'imatge correcta per part del node no demostra res sobre la resolució de noms per a un amfitrió privat. Una petició pública correcta demostra encara menys. Separa els resultats per context, perquè un patró en tres files és un diagnòstic i un fracàs aïllat és una pista.
Si la fila de l'amfitrió també falla, atura't. Tens un problema de xarxa a l'amfitrió i el clúster és una distracció.
Pas 2: conserva el camí de l'amfitrió cap al clúster
Hi ha una segona direcció que la gent oblida: l'amfitrió ha de continuar arribant a l'API i als serveis del mateix clúster. Un client VPN pot instal·lar rutes que competeixen amb els prefixos que minikube utilitza per a la seva xarxa de nodes, el seu rang de serveis i el seu rang de pods.
Quan això passa, el símptoma és confús, perquè el túnel funciona i kubectl deixa de respondre o un NodePort rebutja connexions. Sembla una fallada del clúster i és una fallada d'encaminament del portàtil.
Comprova la taula d'encaminament de l'amfitrió contra els rangs de minikube abans de culpar el túnel de qualsevol altra cosa. El solapament normalment es veu com una ruta més específica que apunta a la interfície del túnel per a un prefix que el clúster espera posseir.
Pas 3: resol el solapament sense desactivar la VPN
El propi manual de VPN i proxy de minikube tracta aquests conflictes i considera els seus rangs d'exemple com a coses a inspeccionar, no com una llista universal. Llegeix-lo juntament amb el perfil que realment tens.
On existeix un solapament real, la resposta admesa és un rang que no se solapi o una política d'accés local deliberada aprovada per qui és propietari de la VPN. Canviar el rang de serveis no és el mateix que canviar el rang de pods, i cap de les dues coses equival a canviar la xarxa de nodes.
Desactivar el túnel corporatiu perquè funcioni un clúster local no és una solució improvisada; és una decisió de política que ha de prendre una altra persona. Porta-la a aquesta persona en lloc de fer-ho en silenci després que tothom hagi anat a casa. Si ja ho has fet, torna-ho a posar abans de preguntar.
Pas 4: separa proxy, DNS i quatre formes de fallada
Si es requereix un proxy, identifica quin context el necessita. Un paràmetre del navegador a l'amfitrió no configura un procés dins del node, i un Pod necessita les variables d'entorn o una configuració de proxy a nivell de clúster.
Després classifica la fallada en lloc de descriure-la. Un nom que no es resol és DNS. Un nom que es resol i rebutja una connexió és encaminament o un listener. Una connexió que s'estableix i falla en la identitat és TLS. Una connexió correcta amb un cos d'error és l'aplicació.
Cada una d'aquestes quatre pertany a una correcció diferent, i només una té a veure amb la VPN. Anota quina has observat en cada context, i la següent persona hereta proves en lloc d'una història.