A minikube nem ér el egy privát API-t? Először a drivert ellenőrizd

A hostnak, a node-nak és a Podnak külön útvonalai és külön feloldója van. Nevezd meg a drivert, teszteld ugyanazt a végpontot mindháromból, majd javítsd meg azt a kontextust, amelyik elbukott.

Egy privát API válaszol a laptopodról, és a minikube-ban futó Pod nem éri el. Mielőtt bármit módosítanál a hoston, nevezd meg az aktív profil mögötti drivert, mert ez az egyetlen tény dönti el, melyik hálózatból indul ki valójában a kérés. Utána teszteld ugyanazt a végpontot a hostról, a node-ról és a Podról. Csak egy bukott el a három közül, és egy rossz tipp egy délutánba kerül.

Lépés 0: a driver és az eredet megnevezése

Kérdezd meg a minikube-tól, melyik profil aktív, és hogyan fut. A konténeres driver a node-ot a gépeden lévő konténerbe teszi, a VM-es driver virtuális géppe, a távoli driver pedig teljesen máshová.

minikube profile list
minikube status
kubectl config current-context

Ebből írd le, honnan indul a kérés. A válasz határozza meg, melyik feloldó és mely útvonalak számítanak, és ez nem mindig a hosté. Két profil ugyanazon a laptopon teljesen másképp viselkedhet ugyanazon URL esetén.

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

Lépés 1: ugyanaz a végpont háromszori tesztelése

Használj egy ártalmatlan végpontot, és tartsd azonosnak a hosztnevet, a portot és a címcsaládot mindhárom tesztben. Ha bármelyiket megváltoztatod a futtatások között, az eredmények nem lesznek összehasonlíthatók.

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

A node sikeres image-letöltése semmit sem bizonyít a névfeloldásról egy privát host esetében. Egy sikeres nyilvános kérés még kevesebbet bizonyít. Tartsd külön az eredményeket kontextusonként, mert a három soron átívelő minta diagnózis, az egyszeri hiba pedig nyom.

Ha a host sora is elbukik, állj meg. Hálózati problémád van a hoston, és a klaszter csak elterelés.

Lépés 2: őrizd meg a host útját a klaszter felé

Van egy második irány, amit az emberek elfelejtenek: a hostnak továbbra is el kell érnie a klaszter saját API-ját és szolgáltatásait. Egy VPN-kliens olyan útvonalakat telepíthet, amelyek versengenek azokkal a prefixekkel, amelyeket a minikube a node-hálózatához, szolgáltatási tartományához és pod-tartományához használ.

Amikor ez megtörténik, a tünet zavaró, mert az alagút működik, a kubectl viszont nem válaszol, vagy egy NodePort visszautasítja a kapcsolatokat. Klaszterhibának tűnik, valójában laptop-útválasztási hiba.

Hasonlítsd össze a host útválasztási táblázatát a minikube tartományaival, mielőtt bármi másért az alagutat okolnád. Az átfedés általában egy konkrétabb útvonalként látszik, amely az alagút interfészére mutat egy olyan prefixnél, amelyet a klaszter a sajátjának vár.

Lépés 3: oldd fel az átfedést a VPN kikapcsolása nélkül

A minikube saját VPN- és proxy-kézikönyve tárgyalja ezeket az ütközéseket, és a példatartományait ellenőrizendő dolgoknak tekinti, nem univerzális listának. Olvasd el a ténylegesen meglévő profilod mellett.

Ahol valódi átfedés van, a támogatott válasz egy nem átfedő tartomány vagy egy szándékos helyi hozzáférési házirend, amelyet a VPN tulajdonosa hagyott jóvá. A szolgáltatási tartomány megváltoztatása nem ugyanaz, mint a pod-tartomány megváltoztatása, és egyik sem ugyanaz, mint a node-hálózat megváltoztatása.

A vállalati alagút kikapcsolása, hogy egy helyi klaszter működjön, nem kerülőmegoldás; ez olyan házirend-döntés, amelyet másnak kell meghoznia. Vidd annak a személynek, ahelyett hogy csendben megtennéd, miután mindenki más hazament. Ha már megtetted, tedd vissza, mielőtt kérdezel.

Lépés 4: válaszd szét a proxyt, a DNS-t és négy hibaformát

Ha proxy szükséges, azonosítsd, melyik kontextusnak kell. A hoston lévő böngészőbeállítás nem konfigurál egy folyamatot a node belsejében, és a Podnak környezeti változókra vagy klaszter szintű proxykonfigurációra van szüksége.

Ezután osztályozd a hibát a leírása helyett. Az a név, amely nem oldódik fel, DNS. Az a név, amely feloldódik és visszautasítja a kapcsolatot, útválasztás vagy egy figyelő. Az a kapcsolat, amely létrejön és az identitásnál elbukik, TLS. A sikeres kapcsolat hibás törzzsel az alkalmazás.

Mind a négy más-más javításhoz tartozik, és csak egyikük szól a VPN-ről. Írd le, melyiket figyelted meg az egyes kontextusokban, és a következő ember bizonyítékot örököl történet helyett.

Kapcsolódó cikkek