minikube kan ikke nå en privat API? Tjek driveren først

En privat API svarer fra din laptop, og en Pod i minikube kan ikke nå den. Før du ændrer noget på værten, skal du navngive driveren bag den aktive profil, fordi den ene kendsgerning afgør, hvilket netværk anmodningen faktisk forlader. Test derefter det samme endpoint fra værten, fra noden og fra Pod'en. Kun én af de tre er det, der fejlede, og et forkert gæt koster en eftermiddag.

Trin 0: navngiv driveren og oprindelsen

Spørg minikube, hvilken profil der er aktiv, og hvordan den kører. En containerdriver sætter noden i en container på din maskine, en VM-driver sætter den i en virtuel maskine, og en fjern-driver sætter den et helt andet sted.

minikube profile list
minikube status
kubectl config current-context

Skriv ud fra det ned, hvor anmodningen stammer fra. Svaret afgør, hvilken resolver og hvilke ruter der betyder noget, og det er ikke altid værtens. To profiler på samme laptop kan opføre sig helt forskelligt for den samme URL.

Trin 1: test det samme endpoint tre gange

Brug ét uskyldigt endpoint, og hold værtsnavnet, porten og adressefamilien identiske i alle tre tests. Ændrer du én af dem mellem kørsler, er resultaterne ikke sammenlignelige.

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

Et vellykket image-pull fra noden beviser intet om navneopløsning for en privat vært. En vellykket offentlig anmodning beviser endnu mindre. Hold resultaterne adskilt efter kontekst, fordi et mønster over tre rækker er en diagnose, og en enkelt fejl er et fingerpeg.

Hvis værtsrækken også fejler, så stop. Du har et netværksproblem på værten, og klyngen er en distraktion.

Trin 2: bevar værtens vej til klyngen

Der er en anden retning, som folk glemmer: værten skal fortsat nå klyngens egen API og egne tjenester. En VPN-klient kan installere ruter, der konkurrerer med de præfikser, som minikube bruger til sit nodenetværk, sit serviceområde og sit podområde.

Når det sker, er symptomet forvirrende, fordi tunnelen virker, og kubectl holder op med at svare, eller en NodePort afviser forbindelser. Det ligner en klyngefejl, og det er en routingfejl på laptoppen.

Tjek værtens routingtabel mod minikubes områder, før du giver tunnelen skylden for noget andet. Overlapningen ses normalt som en mere specifik rute, der peger på tunnelinterfacet for et præfiks, som klyngen forventer at eje.

Trin 3: løs overlapning uden at slå VPN'en fra

minikubes egen VPN- og proxyhåndbog diskuterer disse konflikter og behandler sine eksempelområder som noget, man skal undersøge, ikke som en universel liste. Læs den sammen med den profil, du faktisk har.

Hvor der findes en reel overlapning, er det understøttede svar et ikke-overlappende område eller en bevidst lokal adgangspolitik godkendt af den, der ejer VPN'en. At ændre serviceområdet er ikke det samme som at ændre podområdet, og ingen af delene er det samme som at ændre nodenetværket.

At slå virksomhedstunnelen fra for at få en lokal klynge til at virke er ikke en workaround; det er en politisk beslutning, som en anden skal træffe. Tag den til den person i stedet for at gøre det i stilhed, efter alle andre er gået hjem. Hvis du allerede har gjort det, så sæt det tilbage, før du spørger.

Trin 4: adskil proxy, DNS og fire fejlformer

Hvis en proxy er påkrævet, så find ud af, hvilken kontekst der har brug for den. En browserindstilling på værten konfigurerer ikke en proces inde i noden, og en Pod har brug for miljøvariablerne eller en proxykonfiguration på klyngeniveau.

Klassificér derefter fejlen i stedet for at beskrive den. Et navn, der ikke opløses, er DNS. Et navn, der opløses og afviser en forbindelse, er routing eller en listener. En forbindelse, der etableres og fejler på identitet, er TLS. En vellykket forbindelse med et fejllegeme er applikationen.

Hver af de fire hører til en forskellig rettelse, og kun én af dem handler om VPN'en. Skriv ned, hvilken du observerede i hver kontekst, og den næste person arver beviser i stedet for en historie.