minikube når inte ett privat API? Kontrollera drivrutinen först

Värden, noden och Poden har var sin rutter och resolver. Namnge drivrutinen, testa samma endpoint från alla tre och åtgärda sedan den kontext som misslyckades.

Ett privat API svarar från din laptop och en Pod i minikube kan inte nå det. Innan du ändrar något på värden ska du namnge drivrutinen bakom den aktiva profilen, för just det faktumet avgör vilket nätverk förfrågan faktiskt lämnar. Testa sedan samma endpoint från värden, från noden och från Poden. Bara en av de tre är det som misslyckades, och en felaktig gissning kostar en eftermiddag.

Steg 0: namnge drivrutinen och ursprunget

Fråga minikube vilken profil som är aktiv och hur den körs. En containerdrivrutin placerar noden i en container på din maskin, en VM-drivrutin placerar den i en virtuell maskin, och en fjärrdrivrutin placerar den någon helt annanstans.

minikube profile list
minikube status
kubectl config current-context

Skriv ned varifrån förfrågan kommer. Svaret avgör vilken resolver och vilka rutter som spelar roll, och det är inte alltid värdens. Två profiler på samma laptop kan bete sig helt olika för samma 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

Steg 1: testa samma endpoint tre gånger

Använd en ofarlig endpoint och håll värdnamnet, porten och adressfamiljen identiska i alla tre testerna. Ändrar du något av dem mellan körningarna blir resultaten inte jämförbara.

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

Ett lyckat image-pull från noden bevisar ingenting om namnmatchning för en privat värd. En lyckad offentlig förfrågan bevisar ännu mindre. Håll resultaten åtskilda per kontext, för ett mönster över tre rader är en diagnos och ett enda fel är en ledtråd.

Om värdraden också misslyckas, sluta. Du har ett nätverksproblem på värden och klustret är en distraktion.

Steg 2: behåll värdens väg till klustret

Det finns en andra riktning som folk glömmer: värden måste fortsätta nå klustrets eget API och dess tjänster. En VPN-klient kan installera rutter som konkurrerar med de prefix som minikube använder för sitt nodnät, sitt serviceområde och sitt podområde.

När det händer är symptomet förvirrande, för tunneln fungerar och kubectl slutar svara eller en NodePort vägrar anslutningar. Det ser ut som ett klusterfel och är ett routingfel på laptopen.

Kontrollera värdens routingtabell mot minikubes intervall innan du skyller tunneln för något annat. Överlappningen syns oftast som en mer specifik rutt som pekar mot tunnelgränssnittet för ett prefix som klustret förväntar sig att äga.

Steg 3: lös överlappning utan att stänga av VPN:en

minikubes egen VPN- och proxyhandbok diskuterar dessa konflikter och behandlar sina exempelintervall som saker att inspektera, inte som en universell lista. Läs den tillsammans med den profil du faktiskt har.

Där en verklig överlappning finns är det rekommenderade svaret ett icke överlappande intervall eller en medveten lokal åtkomstpolicy som godkänts av den som äger VPN:en. Att ändra serviceintervallet är inte samma sak som att ändra podintervallet, och inget av dem är samma sak som att ändra nodnätet.

Att stänga av företagstunneln för att få ett lokalt kluster att fungera är ingen workaround; det är ett policybeslut som någon annan måste fatta. Ta det till den personen i stället för att göra det i tysthet efter att alla andra har gått hem. Om du redan har gjort det, sätt tillbaka det innan du frågar.

Steg 4: separera proxy, DNS och fyra felformer

Om en proxy krävs, identifiera vilken kontext som behöver den. En webbläsarinställning på värden konfigurerar inte en process inuti noden, och en Pod behöver miljövariablerna eller en proxykonfiguration på klusternivå.

Klassificera sedan felet i stället för att beskriva det. Ett namn som inte löses ut är DNS. Ett namn som löses ut och nekar en anslutning är routing eller en lyssnare. En anslutning som upprättas och misslyckas på identitet är TLS. En lyckad anslutning med en felkropp är applikationen.

Var och en av de fyra hör till en annan åtgärd, och bara en av dem handlar om VPN:en. Skriv ned vilken du observerade i varje kontext, och nästa person ärver bevis i stället för en historia.

Relaterade artiklar