minikube nedosáhne na privátní API? Nejdřív zkontroluj ovladač

Privátní API odpovídá z tvého notebooku a Pod v minikube na něj nedosáhne. Než na hostu cokoli změníš, pojmenuj ovladač za aktivním profilem, protože tento jediný fakt rozhoduje, ze které sítě požadavek skutečně vychází. Potom otestuj stejný endpoint z hostu, z uzlu a z Podu. Jen jeden z těch tří selhal a špatný odhad stojí odpoledne.

Krok 0: pojmenuj ovladač a původ

Zeptej se minikube, který profil je aktivní a jak běží. Ovladač kontejneru umístí uzel do kontejneru na tvém počítači, ovladač VM ho umístí do virtuálního počítače a vzdálený ovladač ho umístí někam úplně jinam.

minikube profile list
minikube status
kubectl config current-context

Z toho si zapiš, odkud požadavek pochází. Odpověď určuje, čí resolver a které trasy jsou důležité, a ne vždy je to ten hostův. Dva profily na stejném notebooku se mohou pro stejnou URL chovat zcela odlišně.

Krok 1: otestuj stejný endpoint třikrát

Použij jeden neškodný endpoint a udrž hostname, port a rodinu adres stejné ve všech třech testech. Pokud mezi běhy některý z nich změníš, výsledky nebudou srovnatelné.

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

Úspěšný pull image uzlem nic nedokazuje o překladu názvů pro privátní host. Úspěšný veřejný požadavek dokazuje ještě méně. Drž výsledky oddělené podle kontextu, protože vzorec ve třech řádcích je diagnóza a jediné selhání je stopa.

Pokud selže i řádek hostu, zastav. Máš problém se sítí hostu a cluster je rozptýlení.

Krok 2: zachovej cestu hostu ke clusteru

Existuje druhý směr, na který lidé zapomínají: host musí nadále dosáhnout na vlastní API a služby clusteru. Klient VPN může nainstalovat trasy, které soutěží s prefixy, jež minikube používá pro svou síť uzlů, rozsah služeb a rozsah podů.

Když se to stane, příznak je matoucí, protože tunel funguje a kubectl přestane odpovídat nebo NodePort odmítá spojení. Vypadá to jako porucha clusteru a je to porucha směrování notebooku.

Zkontroluj směrovací tabulku hostu proti rozsahům minikube, než tunel obviníš z čehokoli jiného. Překryv je obvykle vidět jako konkrétnější trasa ukazující na rozhraní tunelu pro prefix, který cluster považuje za svůj.

Krok 3: vyřeš překryv bez vypnutí VPN

Vlastní příručka minikube pro VPN a proxy se těmito konflikty zabývá a své příkladové rozsahy bere jako věci k prozkoumání, ne jako univerzální seznam. Přečti si ji spolu s profilem, který skutečně máš.

Tam, kde existuje skutečný překryv, je podporovanou odpovědí nepřekrývající se rozsah nebo záměrná zásada místního přístupu schválená vlastníkem VPN. Změna rozsahu služeb není totéž jako změna rozsahu podů a ani jedno není totéž jako změna sítě uzlů.

Vypnutí firemního tunelu, aby lokální cluster fungoval, není obejití; je to rozhodnutí o zásadách, které musí udělat někdo jiný. Přines to té osobě, místo abys to udělal potichu poté, co všichni ostatní šli domů. Pokud jsi to už udělal, vrať to zpět, než se zeptáš.

Krok 4: odděl proxy, DNS a čtyři podoby selhání

Pokud je vyžadována proxy, urči, který kontext ji potřebuje. Nastavení prohlížeče na hostu nenakonfiguruje proces uvnitř uzlu a Pod potřebuje proměnné prostředí nebo konfiguraci proxy na úrovni clusteru.

Pak selhání klasifikuj místo popisování. Název, který se nepřeloží, je DNS. Název, který se přeloží a odmítne spojení, je směrování nebo listener. Spojení, které se naváže a selže na identitě, je TLS. Úspěšné spojení s chybovým tělem je aplikace.

Každá z těch čtyř patří k jiné opravě a jen jedna z nich se týká VPN. Zapiš, kterou jsi v každém kontextu pozoroval, a další člověk zdědí důkazy místo příběhu.