minikube nesasniedz privātu API? Vispirms pārbaudiet draiveri
Resursdatoram, mezglam un Pod ir savi maršruti un savs resolver. Nosauciet draiveri, pārbaudiet to pašu endpoint no visiem trim, pēc tam izlabojiet kontekstu, kas neizdevās.
Privāts API atbild no jūsu portatīvā datora, un Pod minikube tam nevar piekļūt. Pirms kaut ko mainīt resursdatorā, nosauciet draiveri aiz aktīvā profila, jo šis vienīgais fakts nosaka, no kura tīkla pieprasījums patiešām iziet. Pēc tam pārbaudiet to pašu endpoint no resursdatora, no mezgla un no Pod. Tikai viens no šiem trim ir tas, kas neizdevās, un nepareizs minējums maksā pēcpusdienu.
Solis 0: nosauciet draiveri un izcelsmi
Pajautājiet minikube, kurš profils ir aktīvs un kā tas darbojas. Konteineru draiveris ievieto mezglu konteinerā jūsu mašīnā, VM draiveris ievieto to virtuālajā mašīnā, un attālinātais draiveris ievieto to pavisam citur.
minikube profile list
minikube status
kubectl config current-contextNo tā pierakstiet, no kurienes nāk pieprasījums. Atbilde nosaka, kura resolver un kuri maršruti ir svarīgi, un tas ne vienmēr ir resursdatora. Divi profili vienā portatīvajā datorā var uzvesties pilnīgi atšķirīgi vienam un tam pašam 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 |
Solis 1: pārbaudiet to pašu endpoint trīs reizes
Izmantojiet vienu nekaitīgu endpoint un saglabājiet resursdatora nosaukumu, portu un adrešu saimi identiskus visos trijos testos. Ja kaut ko no tā mainīsiet starp palaidēm, rezultāti nebūs salīdzināmi.
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/healthVeiksmīga image lejupielāde no mezgla neko nepierāda par nosaukumu atrisināšanu privātam resursdatoram. Veiksmīgs publisks pieprasījums pierāda vēl mazāk. Turiet rezultātus atsevišķi pēc konteksta, jo shēma trijās rindās ir diagnoze un viens neveiksmīgs gadījums ir pavediens.
Ja arī resursdatora rinda neizdodas, apstājieties. Jums ir resursdatora tīkla problēma, un klasteris ir novēršana no uzmanības.
Solis 2: saglabājiet resursdatora ceļu uz klasteri
Ir otrs virziens, ko cilvēki aizmirst: resursdatoram jāturpina sasniegt paša klastera API un pakalpojumus. VPN klients var instalēt maršrutus, kas konkurē ar prefiksiem, ko minikube izmanto sava mezglu tīkla, pakalpojumu diapazona un podu diapazona vajadzībām.
Kad tas notiek, simptoms ir mulsinošs, jo tunelis darbojas un kubectl pārstāj atbildēt vai NodePort atsaka savienojumus. Tas izskatās pēc klastera kļūdas, bet patiesībā tā ir portatīvā datora maršrutēšanas kļūda.
Salīdziniet resursdatora maršrutēšanas tabulu ar minikube diapazoniem pirms vainot tuneli jebkurā citā lietā. Pārklāšanās parasti ir redzama kā konkrētāks maršruts, kas norāda uz tuneļa saskarni prefiksam, kuru klasteris uzskata par savu.
Solis 3: atrisiniet pārklāšanos, neizslēdzot VPN
Pašas minikube VPN un proxy rokasgrāmata apskata šos konfliktus un uzskata savus piemēru diapazonus par lietām, kas jāpārbauda, nevis universālu sarakstu. Lasiet to kopā ar profilu, kas jums patiešām ir.
Kur pastāv reāla pārklāšanās, atbalstītā atbilde ir diapazons bez pārklāšanās vai apzināta vietējās piekļuves politika, ko apstiprinājis VPN īpašnieks. Pakalpojumu diapazona maiņa nav tas pats, kas podu diapazona maiņa, un neviens no tiem nav tas pats, kas mezglu tīkla maiņa.
Uzņēmuma tuneļa izslēgšana, lai vietējais klasteris darbotos, nav apkārtceļš; tas ir politikas lēmums, kas jāpieņem kādam citam. Aiznesiet to tam cilvēkam, nevis dariet to klusām pēc tam, kad visi pārējie ir devušies mājās. Ja jūs to jau izdarījāt, atgrieziet to pirms jautāšanas.
Solis 4: atdaliet proxy, DNS un četras kļūdu formas
Ja nepieciešams proxy, nosakiet, kuram kontekstam tas nepieciešams. Pārlūka iestatījums resursdatorā nekonfigurē procesu mezgla iekšienē, un Pod nepieciešami vides mainīgie vai proxy konfigurācija klastera līmenī.
Pēc tam klasificējiet kļūdu, nevis aprakstiet to. Nosaukums, kas netiek atrisināts, ir DNS. Nosaukums, kas tiek atrisināts un atsaka savienojumu, ir maršrutēšana vai listener. Savienojums, kas tiek izveidots un neizdodas identitātē, ir TLS. Veiksmīgs savienojums ar kļūdas saturu ir lietojumprogramma.
Katrs no šiem četriem pieder pie cita labojuma, un tikai viens no tiem ir par VPN. Pierakstiet, kuru jūs novērojāt katrā kontekstā, un nākamā persona mantošanas kārtībā saņems pierādījumus, nevis stāstu.