minikube bereik nie 'n private API nie? Kyk eers na die drywer
Die gasheer, node en Pod het elkeen sy eie roetes en resolver. Noem die drywer, toets dieselfde endpoint van al drie, en maak dan die konteks reg wat misluk het.
'n Private API antwoord vanaf jou skootrekenaar en 'n Pod in minikube kan dit nie bereik nie. Voordat jy enigiets op die gasheer verander, noem die drywer agter die aktiewe profiel, want daardie enkele feit bepaal uit watter netwerk die versoek werklik vertrek. Toets dan dieselfde endpoint vanaf die gasheer, vanaf die node en vanaf die Pod. Net een van daardie drie is die ding wat misluk het, en 'n verkeerde raaiskoot kos 'n middag.
Stap 0: noem die drywer en die oorsprong
Vra minikube watter profiel aktief is en hoe dit loop. 'n Houerdrywer plaas die node in 'n houer op jou masjien, 'n VM-drywer plaas dit in 'n virtuele masjien, en 'n afstanddrywer plaas dit heeltemal elders.
minikube profile list
minikube status
kubectl config current-contextSkryf van daar af neer waar die versoek ontstaan. Die antwoord bepaal wie se resolver en watter roetes saak maak, en dit is nie altyd die gasheer s'n nie. Twee profiele op dieselfde skootrekenaar kan heeltemal anders optree vir dieselfde 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 |
Stap 1: toets dieselfde endpoint drie keer
Gebruik een onskadelike endpoint en hou die gasheernaam, die poort en die adresfamilie identies in al drie toetse. As jy enigeen daarvan tussen lopies verander, is die resultate nie vergelykbaar nie.
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'n Suksesvolle image-trek deur die node bewys niks oor naamoplossing vir 'n private gasheer nie. 'n Suksesvolle openbare versoek bewys nog minder. Hou die resultate per konteks apart, want 'n patroon oor drie rye is 'n diagnose en 'n enkele mislukking is 'n leidraad.
As die gasheerry ook misluk, stop. Jy het 'n netwerkprobleem op die gasheer en die cluster is 'n afleiding.
Stap 2: behou die gasheer se pad na die cluster
Daar is 'n tweede rigting wat mense vergeet: die gasheer moet aanhou om die cluster se eie API en dienste te bereik. 'n VPN-kliënt kan roetes installeer wat meeding met die voorvoegsels wat minikube vir sy nodenetwerk, diensreeks en podreeks gebruik.
Wanneer dit gebeur, is die simptoom verwarrend, want die tonnel werk en kubectl hou op reageer of 'n NodePort weier verbindings. Dit lyk soos 'n clusterfout en dit is 'n routeringsfout van die skootrekenaar.
Vergelyk die gasheer se routeringstabel met minikube se reekse voordat jy die tonnel vir enigiets anders blameer. Die oorvleueling is gewoonlik sigbaar as 'n meer spesifieke roete wat na die tonnelkoppelvlak wys vir 'n voorvoegsel wat die cluster as syne beskou.
Stap 3: los oorvleueling op sonder om die VPN af te skakel
minikube se eie VPN- en proxy-handboek bespreek hierdie konflikte en beskou sy voorbeeldreekse as dinge om te ondersoek, nie as 'n universele lys nie. Lees dit saam met die profiel wat jy werklik het.
Waar 'n werklike oorvleueling bestaan, is die ondersteunde antwoord 'n nie-oorvleuelende reeks of 'n doelbewuste plaaslike toegangsbeleid wat deur die eienaar van die VPN goedgekeur is. Om die diensreeks te verander is nie dieselfde as om die podreeks te verander nie, en nie een daarvan is dieselfde as om die nodenetwerk te verander nie.
Om die korporatiewe tonnel af te skakel sodat 'n plaaslike cluster werk, is nie 'n kortpad nie; dit is 'n beleidsbesluit wat iemand anders moet neem. Neem dit na daardie persoon eerder as om dit stilweg te doen nadat almal anders huis toe is. As jy dit reeds gedoen het, sit dit terug voordat jy vra.
Stap 4: skei proxy, DNS en vier vorme van mislukking
As 'n proxy vereis word, identifiseer watter konteks dit nodig het. 'n Blaaierinstelling op die gasheer konfigureer nie 'n proses binne die node nie, en 'n Pod het die omgewingsveranderlikes of 'n proxy-konfigurasie op clustervlak nodig.
Klassifiseer dan die mislukking in plaas daarvan om dit te beskryf. 'n Naam wat nie oplos nie, is DNS. 'n Naam wat oplos en 'n verbinding weier, is routering of 'n luisteraar. 'n Verbinding wat tot stand kom en op identiteit misluk, is TLS. 'n Suksesvolle verbinding met 'n foutliggaam is die toepassing.
Elkeen van daardie vier hoort by 'n ander regstelling, en net een van hulle gaan oor die VPN. Skryf neer watter een jy in elke konteks waargeneem het, en die volgende persoon erf bewyse in plaas van 'n verhaal.