minikube haifikii API ya kibinafsi? Kwanza angalia dereva
Mwenyeji, nodi na Pod kila mmoja ana njia zake na resolver yake. Taja dereva, jaribu endpoint hiyo hiyo kutoka kwa wote watatu, kisha rekebisha muktadha ulioshindwa.
API ya kibinafsi hujibu kutoka kwa kompyuta yako ndogo na Pod katika minikube haiwezi kuifikia. Kabla ya kubadilisha chochote kwenye mwenyeji, taja dereva aliye nyuma ya profaili inayotumika, kwa sababu ukweli huu mmoja huamua ombi linaondoka kutoka mtandao upi kwa kweli. Kisha jaribu endpoint hiyo hiyo kutoka kwa mwenyeji, kutoka kwa nodi na kutoka kwa Pod. Ni mmoja tu kati ya hao watatu ndio kitu kilichoshindwa, na ubashiri mbaya hugharimu mchana mzima.
Hatua 0: taja dereva na chanzo
Uliza minikube ni profaili gani inatumika na inaendeshwa vipi. Dereva wa kontena huweka nodi ndani ya kontena kwenye mashine yako, dereva wa VM huiweka ndani ya mashine pepe, na dereva wa mbali huiweka mahali pengine kabisa.
minikube profile list
minikube status
kubectl config current-context
Kutokana na hilo, andika ombi linatoka wapi. Jibu huamua resolver ya nani na njia zipi ni muhimu, na si mara zote ni ya mwenyeji. Profaili mbili kwenye kompyuta hiyo hiyo zinaweza kuwa na tabia tofauti kabisa kwa URL hiyo hiyo.
| 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 |
Hatua 1: jaribu endpoint hiyo hiyo mara tatu
Tumia endpoint moja isiyo na madhara na uweke jina la mwenyeji, bandari na familia ya anwani sawa katika majaribio yote matatu. Ukibadilisha lolote kati ya hayo kati ya uendeshaji, matokeo hayatakuwa ya kulinganishwa.
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
Kuvuta image kwa mafanikio na nodi hakuthibitishi chochote kuhusu utatuzi wa majina kwa mwenyeji wa kibinafsi. Ombi la umma lililofanikiwa huthibitisha kidogo zaidi. Tenganisha matokeo kwa muktadha, kwa sababu muundo katika mistari mitatu ni uchunguzi na kushindwa kwa pekee ni kidokezo.
Ikiwa mstari wa mwenyeji pia unashindwa, simama. Una tatizo la mtandao wa mwenyeji na nguzo ni kizuizi cha makini.
Hatua 2: hifadhi njia ya mwenyeji kuelekea nguzo
Kuna mwelekeo wa pili ambao watu huusahau: mwenyeji lazima aendelee kufikia API na huduma za nguzo yenyewe. Mteja wa VPN anaweza kusakinisha njia zinazoshindana na viambishi ambavyo minikube hutumia kwa mtandao wake wa nodi, anuwai ya huduma na anuwai ya pod.
Hilo linapotokea, dalili huchanganya, kwa sababu handaki inafanya kazi na kubectl huacha kujibu au NodePort hukataa miunganisho. Inaonekana kama hitilafu ya nguzo na kwa kweli ni hitilafu ya uelekezaji wa kompyuta ndogo.
Linganisha jedwali la uelekezaji la mwenyeji na anuwai za minikube kabla ya kulaumu handaki kwa kitu kingine chochote. Mwingiliano kwa kawaida huonekana kama njia mahususi zaidi inayoelekeza kwenye kiolesura cha handaki kwa kiambishi ambacho nguzo inatarajia kuwa chake.
Hatua 3: suluhisha mwingiliano bila kuzima VPN
Kitabu cha mwongozo cha VPN na proxy cha minikube chenyewe kinajadili migogoro hii na kinachukua anuwai zake za mfano kama vitu vya kukaguliwa, si orodha ya jumla. Kisome pamoja na profaili uliyo nayo kweli.
Mahali ambapo mwingiliano wa kweli upo, jibu linaloungwa mkono ni anuwai isiyoingiliana au sera ya upatikanaji wa ndani iliyokusudiwa iliyoidhinishwa na mmiliki wa VPN. Kubadilisha anuwai ya huduma si sawa na kubadilisha anuwai ya pod, na hakuna kati ya hizo mbili ni sawa na kubadilisha mtandao wa nodi.
Kuzima handaki ya kampuni ili nguzo ya ndani ifanye kazi si njia ya kukwepa; ni uamuzi wa sera ambao mtu mwingine anapaswa kufanya. Mpeleke kwa mtu huyo badala ya kuifanya kwa utulivu baada ya wengine wote kwenda nyumbani. Ikiwa tayari umefanya, irudishe kabla ya kuuliza.
Hatua 4: tenganisha proxy, DNS na aina nne za kushindwa
Ikiwa proxy inahitajika, tambua ni muktadha upi unaoihitaji. Mpangilio wa kivinjari kwenye mwenyeji hauweki mchakato ndani ya nodi, na Pod inahitaji vigeu vya mazingira au usanidi wa proxy wa kiwango cha nguzo.
Kisha ainisha kushindwa badala ya kukieleza. Jina lisilotatuliwa ni DNS. Jina linalotatuliwa na kukataa muunganisho ni uelekezaji au listener. Muunganisho unaoanzishwa na kushindwa kwenye utambulisho ni TLS. Muunganisho uliofanikiwa na mwili wa hitilafu ni programu.
Kila moja ya hizo nne ni ya marekebisho tofauti, na moja tu ndio kuhusu VPN. Andika ni lipi uliliona katika kila muktadha, na mtu anayefuata atarithi ushahidi badala ya hadithi.