minikube nepasiekia privataus API? Pirmiausia patikrinkite tvarkyklę
Hostas, nodas ir Pod turi savo maršrutus ir savo resolver. Įvardykite tvarkyklę, išbandykite tą patį endpoint iš visų trijų, tada pataisykite kontekstą, kuris nepavyko.
Privatus API atsako iš jūsų nešiojamojo kompiuterio, o Pod minikube negali jo pasiekti. Prieš ką nors keisdami hoste, įvardykite tvarkyklę, esančią už aktyvaus profilio, nes šis vienintelis faktas nulemia, iš kurio tinklo užklausa iš tikrųjų išeina. Tada išbandykite tą patį endpoint iš hosto, iš nodo ir iš Pod. Tik vienas iš tų trijų yra tai, kas nepavyko, o klaidinga prielaida kainuoja popietę.
0 veiksmas: įvardykite tvarkyklę ir šaltinį
Paklauskite minikube, kuris profilis aktyvus ir kaip jis veikia. Konteinerio tvarkyklė įdeda nodą į konteinerį jūsų kompiuteryje, VM tvarkyklė įdeda jį į virtualią mašiną, o nuotolinė tvarkyklė įdeda jį visai kitur.
minikube profile list
minikube status
kubectl config current-contextIš to užsirašykite, iš kur kyla užklausa. Atsakymas nulemia, kurio resolver ir kurie maršrutai svarbūs, ir tai ne visada hosto. Du profiliai tame pačiame nešiojamajame kompiuteryje gali elgtis visiškai skirtingai tam pačiam 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 |
1 veiksmas: išbandykite tą patį endpoint tris kartus
Naudokite vieną nekenksmingą endpoint ir palikite tą patį hosto vardą, prievadą ir adresų šeimą visuose trijuose testuose. Jei ką nors iš jų pakeisite tarp paleidimų, rezultatai nebus palyginami.
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/healthSėkmingas image parsiuntimas node nė kiek neįrodo apie vardų sprendimą privačiam hostui. Sėkminga vieša užklausa įrodo dar mažiau. Laikykite rezultatus atskirai pagal kontekstą, nes trijų eilučių modelis yra diagnozė, o vienas nepavykimas yra užuomina.
Jei hosto eilutė irgi nepavyksta, sustokite. Turite hosto tinklo problemą, o klasteris yra dėmesio blaškymas.
2 veiksmas: išsaugokite hosto kelią į klasterį
Yra antra kryptis, kurią žmonės pamiršta: hostas turi ir toliau pasiekti paties klasterio API ir paslaugas. VPN klientas gali įdiegti maršrutus, kurie konkuruoja su prefiksais, kuriuos minikube naudoja savo nodų tinklui, paslaugų diapazonui ir podų diapazonui.
Kai taip nutinka, simptomas glumina, nes tunelis veikia, o kubectl nustoja atsakyti arba NodePort atmeta ryšius. Atrodo kaip klasterio gedimas, o iš tikrųjų tai nešiojamojo kompiuterio maršrutizavimo gedimas.
Palyginkite hosto maršrutizavimo lentelę su minikube diapazonais prieš kaltindami tunelį dėl ko nors kito. Persidengimas paprastai matomas kaip konkretesnis maršrutas, nukreiptas į tunelio sąsają prefiksui, kurį klasteris laiko savu.
3 veiksmas: išspręskite persidengimą neišjungdami VPN
Pačio minikube VPN ir proxy vadovas aptaria šiuos konfliktus ir savo pavyzdinius diapazonus laiko dalykais, kuriuos reikia patikrinti, o ne universaliu sąrašu. Skaitykite jį kartu su profiliu, kurį tikrai turite.
Kur yra tikras persidengimas, palaikomas atsakymas yra nesutampantis diapazonas arba sąmoninga vietinės prieigos politika, kurią patvirtino VPN savininkas. Paslaugų diapazono keitimas nėra tas pats, kas podų diapazono keitimas, ir nė vienas iš jų nėra tas pats, kas nodų tinklo keitimas.
Įmonės tunelio išjungimas, kad veiktų vietinis klasteris, nėra apeinamasis kelias; tai politikos sprendimas, kurį turi priimti kažkas kitas. Nuneškite jį tam žmogui, o ne darykite tyliai po to, kai visi kiti išėjo namo. Jei jau taip padarėte, grąžinkite prieš klausdami.
4 veiksmas: atskirkite proxy, DNS ir keturias gedimo formas
Jei reikalingas proxy, nustatykite, kuriam kontekstui jo reikia. Naršyklės nustatymas hoste nesukonfigūruoja proceso nodo viduje, o Podui reikia aplinkos kintamųjų arba proxy konfigūracijos klasterio lygmeniu.
Tada klasifikuokite gedimą, o ne aprašykite jį. Vardas, kuris neišsprendžiamas, yra DNS. Vardas, kuris išsprendžiamas ir atmeta ryšį, yra maršrutizavimas arba listener. Ryšys, kuris užmezgamas ir nepavyksta tapatybėje, yra TLS. Sėkmingas ryšys su klaidos turiniu yra programa.
Kiekvienas iš tų keturių priklauso skirtingam taisymui, ir tik vienas iš jų yra apie VPN. Užsirašykite, kurį pastebėjote kiekviename kontekste, ir kitas žmogus paveldės įrodymus, o ne istoriją.