minikube ez da API pribatu batera iristen? Egiaztatu kontrolatzailea lehenik
Ostalariak, nodoak eta Pod-ak bakoitzak bere ibilbideak eta bere resolver-a ditu. Izendatu kontrolatzailea, probatu endpoint bera hiruretatik, eta gero zuzendu huts egin zuen testuingurua.
API pribatu batek zure ordenagailu eramangarritik erantzuten du eta minikube-ko Pod batek ezin du hara iritsi. Ostalarian ezer aldatu aurretik, izendatu profil aktiboaren atzean dagoen kontrolatzailea, gertaera hori bakarrik erabakitzen baitu eskaera benetan zein saretatik irteten den. Gero probatu endpoint bera ostalaritik, nodotik eta Pod-etik. Hiru horietatik bat bakarrik da huts egin zuena, eta okerreko susmoak arratsalde bat kostatzen du.
Urrats 0: izendatu kontrolatzailea eta jatorria
Galdetu minikube-ri zein profil den aktibo eta nola exekutatzen den. Kontrolagailu batek nodoa zure makinako edukiontzi batean jartzen du, VM kontrolagailu batek makina birtualean jartzen du, eta urruneko kontrolagailu batek erabat beste leku batean jartzen du.
minikube profile list
minikube status
kubectl config current-contextHortik, idatzi eskaera nondik sortzen den. Erantzunak erabakitzen du zein resolver eta zein ibilbide diren garrantzitsuak, eta ez da beti ostalariarena. Ordenagailu bereko bi profilek erabat desberdin joka dezakete URL bererako.
| 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 |
Urrats 1: probatu endpoint bera hiru aldiz
Erabili endpoint kaltegabe bat eta mantendu ostalari-izena, portua eta helbide-familia berdinak hiru probetan. Horietakoren bat exekuzioen artean aldatzen baduzu, emaitzak ez dira alderagarriak izango.
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/healthNodoak image bat ongi deskargatzeak ez du ezer frogatzen ostalari pribatu baterako izenen ebazpenari buruz. Eskaera publiko arrakastatsuak are gutxiago frogatzen du. Emaitzak testuinguruen arabera bereizita eduki, hiru errenkadako eredua diagnostikoa delako eta hutsegite bakarra arrastoa delako.
Ostalariaren errenkadak ere huts egiten badu, gelditu. Ostalariaren sare arazoa duzu eta klusterra arreta galarazteko zerbait da.
Urrats 2: mantendu ostalariaren bidea klusterraino
Jendeak ahazten duen bigarren norabide bat dago: ostalariak klusterraren beraren API-ra eta zerbitzuetara iristen jarraitu behar du. VPN bezero batek minikube-k bere nodo-sare, zerbitzu-barruti eta pod-barrutirako erabiltzen dituen aurrizkiekin lehiatzen diren ibilbideak instala ditzake.
Hori gertatzen denean, sintoma nahasia da, tunela funtzionatzen duelako eta kubectl erantzuteari uzten diolako edo NodePort batek konexioak ukatzen dituelako. Klusteraren hutsa dirudi eta ordenagailu eramangarriaren bideratze-hutsa da.
Konparatu ostalariaren bideratze-taula minikube-ren barrutiekin, tunelari beste edozergatik errua eman aurretik. Gainjartzea normalean klusterrak berezkotzat jotzen duen aurrizki baterako tunelaren interfazea seinalatzen duen ibilbide zehatzago gisa ikusten da.
Urrats 3: konpondu gainjartzea VPN-a itzali gabe
minikube-ren VPN eta proxy eskuliburuak berak gatazka hauek lantzen ditu eta bere adibide-barrutiak aztertu beharreko gauzatzat hartzen ditu, ez zerrenda unibertsaltzat. Irakurri ezazu benetan duzun profilarekin batera.
Benetako gainjartzea dagoen tokian, onartutako erantzuna gainjartzen ez den barruti bat edo VPN-aren jabeak onartutako tokiko sarbide-politika bat da. Zerbitzu-barrutia aldatzea ez da pod-barrutia aldatzearen berdina, eta bietako bat ere ez da nodo-sarea aldatzearen berdina.
Tokiko kluster bat funtziona dezan korporazio-tunela itzaltzea ez da saihesbidea; beste norbaitek hartu behar duen politika-erabakia da. Eraman pertsona horri, beste guztiak etxera joan ondoren isilka egin beharrean. Jada egin baduzu, jarri berriro galdetu aurretik.
Urrats 4: bereizi proxy-a, DNS-a eta hutsegitearen lau forma
Proxy-a beharrezkoa bada, identifikatu zein testuinguruk behar duen. Ostalarian nabigatzailearen ezarpenak ez du nodoaren barneko prozesurik konfiguratzen, eta Pod-ak ingurune-aldagaiak edo kluster mailako proxy konfigurazioa behar ditu.
Gero sailkatu hutsegitea deskribatu beharrean. Ebazten ez den izena DNS da. Ebazten den eta konexio bat ukatzen duen izena bideratzea edo listener bat da. Ezarritako eta identitatean huts egiten duen konexioa TLS da. Arrakastazko konexioa errore-gorputz batekin aplikazioa da.
Lau horietako bakoitza konponketa desberdin bati dagokio, eta horietako bat bakarrik da VPN-ari buruzkoa. Idatzi zein behatu zenuen testuinguru bakoitzean, eta hurrengo pertsonak istorio baten ordez frogak oinordetuko ditu.