minikube nedosiahne na privátne API? Najprv skontroluj ovládač

Privátne API odpovedá z tvojho notebooku a Pod v minikube sa k nemu nedostane. Skôr než na hoste čokoľvek zmeníš, pomenuj ovládač za aktívnym profilom, pretože tento jediný fakt rozhoduje, z ktorej siete požiadavka skutočne vychádza. Potom otestuj ten istý endpoint z hosta, z uzla a z Podu. Len jeden z tých troch zlyhal a nesprávny predpoklad stojí popoludnie.

Krok 0: pomenuj ovládač a pôvod

Opýtaj sa minikube, ktorý profil je aktívny a ako beží. Ovládač kontajnera umiestni uzol do kontajnera na tvojom počítači, ovládač VM ho umiestni do virtuálneho počítača a vzdialený ovládač ho umiestni úplne inam.

minikube profile list
minikube status
kubectl config current-context

Z toho si zapíš, odkiaľ požiadavka pochádza. Odpoveď určuje, čí resolver a ktoré trasy sú dôležité, a nie vždy je to ten hostový. Dva profily na tom istom notebooku sa môžu pre rovnakú URL správať úplne odlišne.

Krok 1: otestuj ten istý endpoint trikrát

Použi jeden neškodný endpoint a udrž hostname, port a rodinu adries rovnaké vo všetkých troch testoch. Ak medzi behmi niektorý z nich zmeníš, výsledky nebudú porovnateľné.

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

Úspešný pull image uzlom nič nedokazuje o preklade názvov pre privátny host. Úspešná verejná požiadavka dokazuje ešte menej. Drž výsledky oddelené podľa kontextu, pretože vzorec v troch riadkoch je diagnóza a jediné zlyhanie je stopa.

Ak zlyhá aj riadok hosta, zastav. Máš problém so sieťou hosta a cluster je rozptýlenie.

Krok 2: zachovaj cestu hosta ku clusteru

Existuje druhý smer, na ktorý ľudia zabúdajú: host musí naďalej dosiahnuť na vlastné API a služby clusteru. Klient VPN môže nainštalovať trasy, ktoré súťažia s prefixmi, ktoré minikube používa pre svoju sieť uzlov, rozsah služieb a rozsah podov.

Keď sa to stane, príznak je mätúci, pretože tunel funguje a kubectl prestane odpovedať alebo NodePort odmieta spojenia. Vyzerá to ako porucha clusteru a je to porucha smerovania notebooku.

Skontroluj smerovaciu tabuľku hosta proti rozsahom minikube, skôr než tunel obviníš z čohokoľvek iného. Prekryv je zvyčajne vidieť ako konkrétnejšiu trasu ukazujúcu na rozhranie tunela pre prefix, ktorý cluster považuje za svoj.

Krok 3: vyrieš prekryv bez vypnutia VPN

Vlastná príručka minikube pre VPN a proxy sa týmito konfliktmi zaoberá a svoje príkladové rozsahy berie ako veci na preskúmanie, nie ako univerzálny zoznam. Prečítaj si ju spolu s profilom, ktorý skutočne máš.

Tam, kde existuje skutočný prekryv, je podporovanou odpoveďou neprekrývajúci sa rozsah alebo zámerná zásada miestneho prístupu schválená vlastníkom VPN. Zmena rozsahu služieb nie je to isté ako zmena rozsahu podov a ani jedno nie je to isté ako zmena siete uzlov.

Vypnutie firemného tunela, aby lokálny cluster fungoval, nie je obchádzka; je to rozhodnutie o zásadách, ktoré musí urobiť niekto iný. Prines to tej osobe, namiesto toho, aby si to urobil potichu po tom, čo všetci ostatní išli domov. Ak si to už urobil, vráť to späť, kým sa spýtaš.

Krok 4: oddeľ proxy, DNS a štyri podoby zlyhania

Ak sa vyžaduje proxy, urči, ktorý kontext ju potrebuje. Nastavenie prehliadača na hoste nenakonfiguruje proces vnútri uzla a Pod potrebuje premenné prostredia alebo konfiguráciu proxy na úrovni clusteru.

Potom zlyhanie klasifikuj namiesto opisovania. Názov, ktorý sa nepreloží, je DNS. Názov, ktorý sa preloží a odmietne spojenie, je smerovanie alebo listener. Spojenie, ktoré sa nadviaže a zlyhá na identite, je TLS. Úspešné spojenie s chybovým telom je aplikácia.

Každé z tých štyroch patrí k inej oprave a len jedno z nich sa týka VPN. Zapíš, ktoré si v každom kontexte pozoroval, a ďalší človek zdedí dôkazy namiesto príbehu.