minikube når ikke et privat API? Sjekk driveren først
Verten, noden og Poden har hver sine ruter og sin resolver. Navngi driveren, test det samme endepunktet fra alle tre, og fiks deretter konteksten som feilet.
Et privat API svarer fra laptopen din, og en Pod i minikube når det ikke. Før du endrer noe på verten, navngi driveren bak den aktive profilen, fordi det ene faktumet avgjør hvilket nettverk forespørselen faktisk forlater. Test deretter det samme endepunktet fra verten, fra noden og fra Poden. Bare én av de tre er det som feilet, og en feil gjetning koster en ettermiddag.
Trinn 0: navngi driveren og opprinnelsen
Spør minikube hvilken profil som er aktiv, og hvordan den kjører. En containerdriver setter noden i en container på maskinen din, en VM-driver setter den i en virtuell maskin, og en ekstern driver setter den et helt annet sted.
minikube profile list
minikube status
kubectl config current-contextSkriv ned hvor forespørselen kommer fra. Svaret avgjør hvilken resolver og hvilke ruter som betyr noe, og det er ikke alltid vertens. To profiler på samme laptop kan oppføre seg helt forskjellig for samme 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 |
Trinn 1: test det samme endepunktet tre ganger
Bruk ett ufarlig endepunkt og hold vertsnavnet, porten og adressefamilien identiske i alle tre testene. Endrer du noe av det mellom kjøringer, blir resultatene ikke sammenlignbare.
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/healthEn vellykket image-pull fra noden beviser ingenting om navneoppslag for en privat vert. En vellykket offentlig forespørsel beviser enda mindre. Hold resultatene atskilt per kontekst, fordi et mønster over tre rader er en diagnose, og én enkelt feil er et hint.
Hvis vertsraden også feiler, stopp. Du har et nettverksproblem på verten, og klyngen er en distraksjon.
Trinn 2: behold vertens vei til klyngen
Det finnes en andre retning folk glemmer: verten må fortsette å nå klyngens egen API og egne tjenester. En VPN-klient kan installere ruter som konkurrerer med prefiksene minikube bruker for nodenettet, tjenesteområdet og podområdet sitt.
Når det skjer, er symptomet forvirrende, fordi tunnelen virker og kubectl slutter å svare, eller en NodePort avviser tilkoblinger. Det ser ut som en klyngefeil, og det er en rutefeil på laptopen.
Sjekk vertens rutetabell mot minikubes områder før du gir tunnelen skylden for noe annet. Overlappingen vises vanligvis som en mer spesifikk rute som peker mot tunnelegrensesnittet for et prefiks klyngen forventer å eie.
Trinn 3: løs overlapping uten å slå av VPN-en
minikubes egen VPN- og proxyhåndbok diskuterer disse konfliktene og behandler eksempelområdene sine som noe man skal undersøke, ikke som en universell liste. Les den sammen med profilen du faktisk har.
Der en reell overlapping finnes, er det støttede svaret et ikke-overlappende område eller en bevisst lokal tilgangspolicy godkjent av den som eier VPN-en. Å endre tjenesteområdet er ikke det samme som å endre podområdet, og ingen av delene er det samme som å endre nodenettet.
Å slå av bedriftstunnelen for å få en lokal klynge til å virke er ingen workaround; det er en policybeslutning noen andre må ta. Ta den til den personen i stedet for å gjøre det i stillhet etter at alle andre har gått hjem. Hvis du allerede har gjort det, sett det tilbake før du spør.
Trinn 4: skill proxy, DNS og fire feilformer
Hvis en proxy kreves, identifiser hvilken kontekst som trenger den. En nettleserinnstilling på verten konfigurerer ikke en prosess inne i noden, og en Pod trenger miljøvariablene eller en proxykonfigurasjon på klyngenivå.
Klassifiser deretter feilen i stedet for å beskrive den. Et navn som ikke slås opp, er DNS. Et navn som slås opp og avviser en tilkobling, er ruting eller en lytter. En tilkobling som opprettes og feiler på identitet, er TLS. En vellykket tilkobling med en feilkropp er applikasjonen.
Hver av de fire hører til en annen rettelse, og bare én av dem handler om VPN-en. Skriv ned hvilken du observerte i hver kontekst, og neste person arver bevis i stedet for en historie.