eikö minikube tavoita yksityistä APIa? Tarkista ensin ajuri
Isännällä, noodilla ja Podilla on kullakin omat reitit ja oma resolverinsa. Nimeä ajuri, testaa sama päätepiste kaikista kolmesta ja korjaa sitten se konteksti, joka epäonnistui.
Yksityinen API vastaa kannettavaltasi, eikä minikuben Pod tavoita sitä. Ennen kuin muutat isännällä mitään, nimeä aktiivisen profiilin takana oleva ajuri, sillä juuri tämä yksi seikka ratkaisee, mistä verkosta pyyntö todella lähtee. Testaa sitten sama päätepiste isännältä, noodilta ja Podilta. Vain yksi noista kolmesta on se, joka epäonnistui, ja väärä arvaus maksaa yhden iltapäivän.
Vaihe 0: nimeä ajuri ja lähde
Kysy minikubelta, mikä profiili on aktiivinen ja miten se toimii. Konttiajuri sijoittaa noodin koneesi konttiin, VM-ajuri sijoittaa sen virtuaalikoneeseen ja etäajuri sijoittaa sen jonnekin aivan muualle.
minikube profile list
minikube status
kubectl config current-contextKirjoita sen perusteella muistiin, mistä pyyntö on lähtöisin. Vastaus ratkaisee, kenen resolverilla ja millä reiteillä on merkitystä, eikä se ole aina isännän. Kaksi profiilia samalla kannettavalla voivat käyttäytyä täysin eri tavalla samalle URLille.
| 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 |
Vaihe 1: testaa sama päätepiste kolme kertaa
Käytä yhtä vaaratonta päätepistettä ja pidä isäntänimi, portti ja osoiteperhe samoina kaikissa kolmessa testissä. Jos muutat jotain niistä ajojen välillä, tulokset eivät ole vertailukelpoisia.
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/healthNoodin onnistunut imagen haku ei todista mitään nimien selvityksestä yksityiselle isännälle. Onnistunut julkinen pyyntö todistaa vielä vähemmän. Pidä tulokset erillään konteksteittain, sillä kolmen rivin kuvio on diagnoosi ja yksittäinen epäonnistuminen on vihje.
Jos isäntärivikin epäonnistuu, lopeta. Sinulla on isännän verkko-ongelma, ja klusteri on harhautus.
Vaihe 2: säilytä isännän polku klusteriin
On toinen suunta, jonka ihmiset unohtavat: isännän on edelleen tavoitettava klusterin oma API ja palvelut. VPN-asiakas voi asentaa reittejä, jotka kilpailevat niiden etuliitteiden kanssa, joita minikube käyttää noodiverkolleen, palvelualueelleen ja podialueelleen.
Kun niin tapahtuu, oire on hämmentävä, koska tunneli toimii ja kubectl lakkaa vastaamasta tai NodePort kieltäytyy yhteyksistä. Se näyttää klusterin vialta ja on kannettavan reititysvika.
Tarkista isännän reititystaulukko minikuben alueita vasten ennen kuin syytät tunnelia mistään muusta. Päällekkäisyys näkyy yleensä tarkempana reittinä, joka osoittaa tunnelin rajapintaan etuliitteelle, jonka klusteri odottaa omistavansa.
Vaihe 3: ratkaise päällekkäisyys poistamatta VPN:ää käytöstä
Minikuben oma VPN- ja välityspalvelinkäsikirja käsittelee näitä ristiriitoja ja pitää esimerkkialueitaan tarkistettavina asioina, ei yleisenä luettelona. Lue se sen profiilin rinnalla, joka sinulla todella on.
Kun todellinen päällekkäisyys on olemassa, tuettu vastaus on päällekkäisyydetön alue tai tarkoituksellinen paikallinen käyttöoikeuskäytäntö, jonka VPN:n omistaja on hyväksynyt. Palvelualueen muuttaminen ei ole sama asia kuin podialueen muuttaminen, eikä kumpikaan ole sama asia kuin noodiverkon muuttaminen.
Yritystunnelin poistaminen käytöstä paikallisen klusterin toimimiseksi ei ole kiertotie; se on käytäntöpäätös, jonka jonkun muun on tehtävä. Vie se hänelle sen sijaan, että tekisit sen hiljaa, kun kaikki muut ovat jo menneet kotiin. Jos olet jo tehnyt niin, palauta se ennen kuin kysyt.
Vaihe 4: erottele välityspalvelin, DNS ja neljä vikamuotoa
Jos välityspalvelin vaaditaan, selvitä, mikä konteksti sitä tarvitsee. Isännän selainasetus ei määritä noodin sisällä olevaa prosessia, ja Pod tarvitsee ympäristömuuttujat tai klusteritason välityspalvelinasetukset.
Luokittele sitten vika sen kuvaamisen sijaan. Nimi, joka ei selviä, on DNS. Nimi, joka selviää ja hylkää yhteyden, on reititys tai kuuntelija. Yhteys, joka muodostuu ja epäonnistuu identiteetissä, on TLS. Onnistunut yhteys, jossa on virheellinen runko, on sovellus.
Jokainen noista neljästä kuuluu eri korjaukseen, ja vain yksi niistä koskee VPN:ää. Kirjoita muistiin, minkä havaitsit kussakin kontekstissa, niin seuraava henkilö perii todisteita tarinan sijaan.