minikube nuk arrin një API private? Kontrollo fillimisht drejtuesin
Hosti, nyja dhe Pod-i kanë secili rrugët dhe resolver-in e vet. Emërto drejtuesin, provo të njëjtin endpoint nga të tre, pastaj rregullo kontekstin që dështoi.
Një API private përgjigjet nga laptopi juaj dhe një Pod në minikube nuk mund ta arrijë. Përpara se të ndryshoni diçka në host, emërtoni drejtuesin prapa profilit aktiv, sepse ky fakt i vetëm vendos se nga cila rrjet del në të vërtetë kërkesa. Pastaj provoni të njëjtin endpoint nga hosti, nga nyja dhe nga Pod-i. Vetëm njëri prej atyre tre është ai që dështoi, dhe një supozim i gabuar kushton një pasdite.
Hapi 0: emërto drejtuesin dhe origjinën
Pyetni minikube se cili profil është aktiv dhe si funksionon. Një drejtues kontejnerësh e vendos nyjën në një kontejner në makinën tuaj, një drejtues VM e vendos në një makinë virtuale, dhe një drejtues i largët e vendos diku krejt tjetër.
minikube profile list
minikube status
kubectl config current-contextNga kjo, shkruani se nga vjen kërkesa. Përgjigja përcakton se resolver-i i kujt dhe cilat rrugë kanë rëndësi, dhe nuk është gjithmonë ai i hostit. Dy profile në të njëjtin laptop mund të sillen krejt ndryshe për të njëjtin URL.
| 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 |
Hapi 1: provoni të njëjtin endpoint tri herë
Përdorni një endpoint të padëmshëm dhe mbani emrin e hostit, portën dhe familjen e adresave identike në të tre provat. Nëse ndryshoni ndonjë prej tyre midis ekzekutimeve, rezultatet nuk janë të krahasueshme.
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/healthNjë image pull i suksesshëm nga nyja nuk provon asgjë për zgjidhjen e emrave për një host privat. Një kërkesë publike e suksesshme provon edhe më pak. Mbani rezultatet të ndara sipas kontekstit, sepse një model në tri rreshta është diagnozë dhe një dështim i vetëm është një indicie.
Nëse rreshti i hostit dështon gjithashtu, ndaloni. Keni një problem rrjeti në host dhe grupi është thjesht shpërqendrim.
Hapi 2: mbani rrugën e hostit drejt grupit
Ekziston një drejtim i dytë që njerëzit e harrojnë: hosti duhet të vazhdojë të arrijë API-n dhe shërbimet e vetë grupit. Një klient VPN mund të instalojë rrugë që konkurrojnë me prefikset që minikube përdor për rrjetin e nyjeve, gamën e shërbimeve dhe gamën e pod-eve.
Kur kjo ndodh, simptoma është konfuze, sepse tuneli funksionon dhe kubectl ndalon së përgjigjuri ose një NodePort refuzon lidhjet. Duket si një defekt i grupit dhe është një defekt i rrugëtimit të laptopit.
Krahasoni tabelën e rrugëtimit të hostit me gamat e minikube përpara se të fajësoni tunelin për çdo gjë tjetër. Mbivendosja zakonisht shihet si një rrugë më specifike që tregon ndërfaqen e tunelit për një prefiks që grupi pret ta ketë të vetin.
Hapi 3: zgjidhni mbivendosjen pa fikur VPN-në
Manuali i minikube për VPN dhe proxy trajton këto konflikte dhe i trajton gamat e tij shembullore si gjëra për t'u inspektuar, jo si një listë universale. Lexojeni së bashku me profilin që keni në të vërtetë.
Aty ku ekziston një mbivendosje e vërtetë, përgjigja e mbështetur është një gamë që nuk mbivendoset ose një politikë e qëllimshme e aksesit lokal e miratuar nga pronari i VPN-së. Ndryshimi i gamës së shërbimeve nuk është njësoj si ndryshimi i gamës së pod-eve, dhe asnjëra nuk është njësoj si ndryshimi i rrjetit të nyjeve.
Fikja e tunelit korporativ që një grup lokal të funksionojë nuk është një shmangie; është një vendim politike që duhet ta marrë dikush tjetër. Çojeni tek ai person në vend që ta bëni në heshtje pasi të gjithë të tjerët kanë shkuar në shtëpi. Nëse e keni bërë tashmë, kthejeni përpara se të pyesni.
Hapi 4: ndani proxy-n, DNS-në dhe katër forma dështimi
Nëse kërkohet një proxy, identifikoni cili kontekst ka nevojë për të. Një cilësim shfletuesi në host nuk konfiguron një proces brenda nyjes, dhe një Pod ka nevojë për variablat e mjedisit ose një konfigurim proxy në nivel grupi.
Pastaj klasifikoni dështimin në vend që ta përshkruani. Një emër që nuk zgjidhet është DNS. Një emër që zgjidhet dhe refuzon një lidhje është rrugëtim ose një listener. Një lidhje që krijohet dhe dështon në identitet është TLS. Një lidhje e suksesshme me një trup gabimi është aplikacioni.
Secila prej atyre katër i përket një rregullimi tjetër, dhe vetëm njëra prej tyre ka të bëjë me VPN-në. Shkruani cilën vëzhguat në secilin kontekst, dhe personi tjetër trashëgon prova në vend të një historie.