minikube ne atingas privatan API? Unue kontrolu la pelilon

La gastiganto, la nodo kaj la Pod havas ĉiu siajn vojojn kaj sian propran resolver. Nomu la pelilon, testu la saman endpoint de ĉiuj tri, poste ripari la kuntekston, kiu malsukcesis.

Privata API respondas de via tekkomputilo kaj Pod en minikube ne povas atingi ĝin. Antaŭ ol vi ŝanĝos ion ajn en la gastiganto, nomu la pelilon malantaŭ la aktiva profilo, ĉar tiu sola fakto decidas, el kiu reto la peto efektive eliras. Poste testu la saman endpoint de la gastiganto, de la nodo kaj de la Pod. Nur unu el tiuj tri estas tio, kio malsukcesis, kaj malĝusta konjekto kostas posttagmezon.

Paŝo 0: nomu la pelilon kaj la originon

Demandu minikube, kiu profilo estas aktiva kaj kiel ĝi funkcias. Pelilo por ujoj metas la nodon en ujon sur via maŝino, pelilo por VM metas ĝin en virtualan maŝinon, kaj fora pelilo metas ĝin tute aliloken.

minikube profile list
minikube status
kubectl config current-context

El tio, notu, de kie la peto originas. La respondo decidas, kies resolver kaj kiuj vojoj gravas, kaj ĝi ne ĉiam estas tiu de la gastiganto. Du profiloj sur la sama tekkomputilo povas konduti tute malsame por la sama URL.

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

Paŝo 1: testu la saman endpoint tri fojojn

Uzu unu sendanĝeran endpoint kaj tenu la gastigantnomon, la pordon kaj la adresfamilion identaj en ĉiuj tri testoj. Se vi ŝanĝos iun el ili inter ruladoj, la rezultoj ne estos kompareblaj.

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

Sukcesa image-elŝuto fare de la nodo pruvas nenion pri nomrezolucio por privata gastiganto. Sukcesa publika peto pruvas eĉ malpli. Tenu la rezultojn aparte laŭ kunteksto, ĉar ŝablono en tri vicoj estas diagnozo kaj unuopa malsukceso estas indico.

Se ankaŭ la gastiganta vico malsukcesas, haltu. Vi havas retproblemon sur la gastiganto kaj la klastro estas distraĵo.

Paŝo 2: konservu la vojon de la gastiganto al la klastro

Ekzistas dua direkto, kiun homoj forgesas: la gastiganto devas daŭre atingi la propran API kaj servojn de la klastro. VPN-kliento povas instali vojojn, kiuj konkurencas kun la prefiksoj, kiujn minikube uzas por sia nodreto, sia servo-gamo kaj sia pod-gamo.

Kiam tio okazas, la simptomo konfuzas, ĉar la tunelo funkcias kaj kubectl ĉesas respondi aŭ NodePort rifuzas konektojn. Ĝi aspektas kiel klastra fiasko kaj estas enkursiga fiasko de la tekkomputilo.

Komparu la enkursigan tabelon de la gastiganto kun la gamoj de minikube antaŭ ol kulpigi la tunelon pri io ajn alia. La koincido kutime videblas kiel pli specifa vojo, kiu montras al la tunela interfaco por prefikso, kiun la klastro atendas posedi.

Paŝo 3: solvu la koincidon sen malŝalti la VPN

La propra VPN- kaj proxy-manlibro de minikube diskutas tiujn konfliktojn kaj traktas siajn ekzemplajn gamojn kiel aferojn por inspekti, ne kiel universalan liston. Legu ĝin kune kun la profilo, kiun vi efektive havas.

Kie ekzistas reala koincido, la subtenata respondo estas gamo sen koincido aŭ konscia loka alirpolitiko aprobita de la posedanto de la VPN. Ŝanĝi la servo-gamon ne samas kiel ŝanĝi la pod-gamon, kaj neniu el ili samas kiel ŝanĝi la nodreton.

Malŝalti la kompanian tunelon por ke loka klastro funkciu ne estas ĉirkaŭvojo; ĝi estas politika decido, kiun devas fari iu alia. Portu ĝin al tiu persono anstataŭ fari ĝin silente post kiam ĉiuj aliaj iris hejmen. Se vi jam faris tion, restarigu ĝin antaŭ ol demandi.

Paŝo 4: apartigu proxy, DNS kaj kvar formojn de fiasko

Se proxy estas bezonata, identigu, kiu kunteksto bezonas ĝin. Retumila agordo sur la gastiganto ne agordas procezon interne de la nodo, kaj Pod bezonas la medivariablojn aŭ proxy-agordon je klastra nivelo.

Poste klasifiku la fiaskon anstataŭ priskribi ĝin. Nomo, kiu ne solviĝas, estas DNS. Nomo, kiu solviĝas kaj rifuzas konekton, estas enkursigo aŭ listener. Konekto, kiu establiĝas kaj fiaskas ĉe identeco, estas TLS. Sukcesa konekto kun erarkorpo estas la aplikaĵo.

Ĉiu el tiuj kvar apartenas al alia riparo, kaj nur unu el ili temas pri la VPN. Notu, kiun vi observis en ĉiu kunteksto, kaj la sekva persono heredos pruvojn anstataŭ rakonton.

Rilataj artikoloj