minikube bereikt een privé-API niet? Controleer eerst de driver

Een privé-API antwoordt vanaf je laptop en een Pod in minikube kan hem niet bereiken. Voordat je iets op de host verandert, benoem je de driver achter het actieve profiel, want dat ene feit bepaalt uit welk netwerk het verzoek echt vertrekt. Test daarna hetzelfde endpoint vanaf de host, vanaf de node en vanaf de Pod. Slechts één van die drie is wat faalde, en verkeerd gokken kost een middag.

Stap 0: benoem de driver en de oorsprong

Vraag minikube welk profiel actief is en hoe het draait. Een container-driver zet de node in een container op je machine, een VM-driver zet hem in een virtuele machine, en een remote-driver zet hem ergens heel anders.

minikube profile list
minikube status
kubectl config current-context

Noteer daaruit waar het verzoek vandaan komt. Het antwoord bepaalt welke resolver en welke routes ertoe doen, en dat is niet altijd die van de host. Twee profielen op dezelfde laptop kunnen zich voor dezelfde URL volledig anders gedragen.

Stap 1: test hetzelfde endpoint drie keer

Gebruik één onschadelijk endpoint en houd de hostnaam, de poort en de adresfamilie in alle drie de tests gelijk. Als je daarvan iets tussen runs verandert, zijn de resultaten niet vergelijkbaar.

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

Een geslaagde image-pull door de node bewijst niets over naamresolutie voor een privé-host. Een geslaagd openbaar verzoek bewijst nog minder. Houd de resultaten per context gescheiden, want een patroon over drie rijen is een diagnose en één enkele fout is een aanwijzing.

Als de hostrij ook faalt, stop dan. Je hebt een netwerkprobleem op de host en het cluster is een afleiding.

Stap 2: houd het pad van de host naar het cluster intact

Er is een tweede richting die mensen vergeten: de host moet de eigen API en diensten van het cluster blijven bereiken. Een VPN-client kan routes installeren die concurreren met de prefixen die minikube gebruikt voor zijn nodenetwerk, zijn servicebereik en zijn podbereik.

Als dat gebeurt, is het symptoom verwarrend, want de tunnel werkt en kubectl reageert niet meer of een NodePort weigert verbindingen. Het lijkt op een clusterfout en het is een routingfout van de laptop.

Controleer de routingtabel van de host tegen de bereiken van minikube voordat je de tunnel ergens anders de schuld van geeft. De overlap is meestal zichtbaar als een specifiekere route die naar de tunnelinterface wijst voor een prefix die het cluster als het zijne beschouwt.

Stap 3: los overlap op zonder de VPN uit te schakelen

De eigen VPN- en proxyhandleiding van minikube bespreekt deze conflicten en behandelt zijn voorbeeldbereiken als dingen om te inspecteren, niet als een universele lijst. Lees die naast het profiel dat je echt hebt.

Waar een echte overlap bestaat, is het ondersteunde antwoord een niet-overlappend bereik of een bewust lokaal toegangsbeleid dat is goedgekeurd door wie de VPN bezit. Het servicebereik wijzigen is niet hetzelfde als het podbereik wijzigen, en geen van beide is hetzelfde als het nodenetwerk wijzigen.

De bedrijfstunnel uitschakelen om een lokaal cluster te laten werken is geen workaround; het is een beleidsbeslissing die iemand anders moet nemen. Leg die bij die persoon neer in plaats van het stilletjes te doen nadat iedereen naar huis is. Als je het al hebt gedaan, zet het terug voordat je het vraagt.

Stap 4: scheid proxy, DNS en vier faalvormen

Als een proxy vereist is, bepaal dan welke context die nodig heeft. Een browserinstelling op de host configureert geen proces in de node, en een Pod heeft de omgevingsvariabelen of een proxyconfiguratie op clusterniveau nodig.

Classificeer de fout dan in plaats van hem te beschrijven. Een naam die niet oplost is DNS. Een naam die oplost en een verbinding weigert is routing of een listener. Een verbinding die tot stand komt en op identiteit faalt is TLS. Een geslaagde verbinding met een foutbody is de applicatie.

Elk van die vier hoort bij een andere oplossing, en slechts één ervan gaat over de VPN. Noteer welke je in elke context hebt waargenomen, en de volgende persoon erft bewijs in plaats van een verhaal.