Hindi maabot ng minikube ang pribadong API? Suriin muna ang driver
Ang host, node at Pod ay may kanya-kanyang ruta at resolver. Pangalanan ang driver, subukan ang parehong endpoint mula sa tatlo, pagkatapos ay ayusin ang context na nabigo.
May pribadong API na sumasagot mula sa iyong laptop at hindi ito maabot ng Pod sa minikube. Bago ka magbago ng anuman sa host, pangalanan ang driver sa likod ng aktibong profile, dahil ang nag-iisang katotohanang ito ang nagtatakda kung saang network talaga lumalabas ang kahilingan. Pagkatapos, subukan ang parehong endpoint mula sa host, mula sa node at mula sa Pod. Isa lang sa tatlong iyon ang nabigo, at ang maling hula ay nagkakahalaga ng isang hapon.
Hakbang 0: pangalanan ang driver at ang pinagmulan
Itanong sa minikube kung aling profile ang aktibo at paano ito tumatakbo. Inilalagay ng container driver ang node sa isang container sa iyong makina, inilalagay ng VM driver ito sa isang virtual machine, at inilalagay ng remote driver ito sa ibang lugar nang tuluyan.
minikube profile list
minikube status
kubectl config current-contextMula doon, isulat kung saan nagmumula ang kahilingan. Tinatakda ng sagot kung kaninong resolver at aling mga ruta ang mahalaga, at hindi laging sa host ito. Dalawang profile sa parehong laptop ay maaaring kumilos nang lubos na naiiba para sa parehong 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 |
Hakbang 1: subukan ang parehong endpoint nang tatlong beses
Gumamit ng isang hindi nakakapinsalang endpoint at panatilihing pareho ang hostname, port at address family sa lahat ng tatlong pagsubok. Kapag binago ang alinman sa mga ito sa pagitan ng mga run, hindi na maihahambing ang mga resulta.
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/healthAng matagumpay na image pull ng node ay walang pinapatunayan tungkol sa paglutas ng pangalan para sa isang pribadong host. Ang matagumpay na pampublikong kahilingan ay mas kaunti pa ang pinapatunayan. Ihiwalay ang mga resulta ayon sa context, dahil ang pattern sa tatlong hilera ay diagnosis at ang nag-iisang kabiguan ay pahiwatig.
Kung nabigo rin ang hilera ng host, tumigil. May problema ka sa network ng host at ang cluster ay distraction lamang.
Hakbang 2: panatilihin ang daan ng host patungo sa cluster
May pangalawang direksyon na nakakalimutan ng mga tao: kailangang patuloy na maabot ng host ang sariling API at mga serbisyo ng cluster. Maaaring maglagay ang isang VPN client ng mga rutang nakikipagkumpitensya sa mga prefix na ginagamit ng minikube para sa network ng node, saklaw ng serbisyo at saklaw ng pod nito.
Kapag nangyari iyon, nakakalito ang sintomas, dahil gumagana ang tunnel at tumitigil sa pagtugon ang kubectl o tumatanggi ang NodePort sa mga koneksyon. Mukha itong sira ng cluster at sira pala ng routing ng laptop.
Ihambing ang routing table ng host sa mga saklaw ng minikube bago sisihin ang tunnel sa anumang iba pa. Karaniwang nakikita ang overlap bilang mas espesipikong ruta na tumuturo sa tunnel interface para sa prefix na inaasahang pag-aari ng cluster.
Hakbang 3: lutasin ang overlap nang hindi pinapatay ang VPN
Tinatalakay ng sariling VPN at proxy handbook ng minikube ang mga conflict na ito at itinuturing ang mga halimbawang saklaw nito na bagay na dapat suriin, hindi unibersal na listahan. Basahin ito kasama ng profile na talagang mayroon ka.
Kung saan may tunay na overlap, ang sinusuportahang sagot ay isang saklaw na hindi nag-o-overlap o sinadyang lokal na patakaran sa access na inaprubahan ng may-ari ng VPN. Ang pagbabago ng saklaw ng serbisyo ay hindi katulad ng pagbabago ng saklaw ng pod, at wala sa dalawa ang katulad ng pagbabago ng network ng node.
Ang pagpatay sa corporate tunnel para gumana ang lokal na cluster ay hindi shortcut; ito ay desisyon sa patakaran na dapat gawin ng ibang tao. Dalhin ito sa taong iyon sa halip na gawin ito nang tahimik pagkatapos umuwi ng lahat. Kung nagawa mo na ito, ibalik ito bago ka magtanong.
Hakbang 4: ihiwalay ang proxy, DNS at apat na hugis ng kabiguan
Kung kailangan ang proxy, tukuyin kung aling context ang nangangailangan nito. Ang setting ng browser sa host ay hindi nag-configure ng proseso sa loob ng node, at kailangan ng Pod ang mga environment variable o cluster-level na proxy configuration.
Pagkatapos, uriin ang kabiguan sa halip na ilarawan ito. Ang pangalang hindi nalulutas ay DNS. Ang pangalang nalulutas at tumatanggi sa koneksyon ay routing o listener. Ang koneksyong nabubuo at nabigo sa pagkakakilanlan ay TLS. Ang matagumpay na koneksyon na may error body ay ang aplikasyon.
Bawat isa sa apat na iyon ay kabilang sa ibang pag-aayos, at isa lang ang tungkol sa VPN. Isulat kung alin ang naobserbahan mo sa bawat context, at ang susunod na tao ay magmamana ng ebidensya sa halip na kuwento.