minikube ne dolazi do privatnog API-ja? Prvo provjeri drajver

Privatni API odgovara s tvog laptopa, a Pod u minikubeu ne može ga dohvatiti. Prije nego što bilo šta promijeniš na hostu, imenuj drajver iza aktivnog profila, jer ta jedna činjenica odlučuje s koje mreže zahtjev zaista izlazi. Zatim testiraj isti endpoint s hosta, s čvora i s Poda. Samo jedan od ta tri je ono što je zakazalo, a pogrešna pretpostavka košta popodne.

Korak 0: imenuj drajver i porijeklo

Pitaj minikube koji je profil aktivan i kako se izvodi. Drajver za kontejnere stavlja čvor u kontejner na tvom računaru, VM drajver ga stavlja u virtualnu mašinu, a udaljeni drajver ga stavlja negdje sasvim drugdje.

minikube profile list
minikube status
kubectl config current-context

Iz toga zapiši odakle zahtjev potiče. Odgovor određuje čiji resolver i koje rute su važne, a to nije uvijek onaj s hosta. Dva profila na istom laptopu mogu se za isti URL ponašati potpuno različito.

Korak 1: testiraj isti endpoint tri puta

Koristi jedan bezopasan endpoint i drži ime hosta, port i adresnu familiju identičnim u sva tri testa. Ako bilo šta od toga promijeniš između pokretanja, rezultati nisu uporedivi.

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

Uspješan pull slike od strane čvora ništa ne dokazuje o razrješavanju imena za privatni host. Uspješan javni zahtjev dokazuje još manje. Drži rezultate odvojeno po kontekstu, jer obrazac u tri reda je dijagnoza, a pojedinačni neuspjeh je trag.

Ako i red hosta zakazuje, stani. Imaš problem s mrežom hosta, a klaster je odvraćanje pažnje.

Korak 2: zadrži put hosta do klastera

Postoji drugi smjer koji ljudi zaboravljaju: host mora nastaviti dolaziti do vlastitog API-ja i servisa klastera. VPN klijent može instalirati rute koje se takmiče s prefiksima koje minikube koristi za svoju mrežu čvorova, raspon servisa i raspon podova.

Kada se to dogodi, simptom je zbunjujuć, jer tunel radi, a kubectl prestane odgovarati ili NodePort odbija veze. Izgleda kao kvar klastera, a to je kvar rutiranja na laptopu.

Provjeri routing tabelu hosta prema rasponima minikubea prije nego za bilo šta drugo okriviš tunel. Preklapanje se obično vidi kao specifičnija ruta koja pokazuje na interfejs tunela za prefiks koji klaster očekuje kao svoj.

Korak 3: riješi preklapanje bez isključivanja VPN-a

Vlastiti minikube priručnik za VPN i proxy obrađuje te konflikte i svoje primjere raspona tretira kao stvari koje treba pregledati, a ne kao univerzalnu listu. Pročitaj ga uz profil koji zaista imaš.

Gdje postoji stvarno preklapanje, podržani odgovor je raspon bez preklapanja ili namjerna politika lokalnog pristupa koju odobri vlasnik VPN-a. Promjena raspona servisa nije isto što i promjena raspona podova, a ni jedno nije isto što i promjena mreže čvorova.

Isključivanje korporativnog tunela da bi lokalni klaster radio nije zaobilazno rješenje; to je odluka o politici koju mora donijeti neko drugi. Odnesi je toj osobi umjesto da to uradiš tiho nakon što su svi ostali otišli kući. Ako si to već uradio, vrati ga prije nego što pitaš.

Korak 4: razdvoji proxy, DNS i četiri oblika kvara

Ako je potreban proxy, identificiraj kojem kontekstu treba. Postavka preglednika na hostu ne konfiguriše proces unutar čvora, a Pod treba varijable okruženja ili konfiguraciju proxyja na nivou klastera.

Zatim klasifikuj kvar umjesto da ga opisuješ. Ime koje se ne razrješava je DNS. Ime koje se razrješava i odbija vezu je rutiranje ili listener. Veza koja se uspostavi i padne na identitetu je TLS. Uspješna veza s tijelom greške je aplikacija.

Svaki od ta četiri pripada drugoj popravci, a samo jedan od njih se odnosi na VPN. Zapiši koji si uočio u svakom kontekstu, i sljedeća osoba nasljeđuje dokaze umjesto priče.