minikube nie dociera do prywatnego API? Najpierw sprawdź sterownik

Host, węzeł i Pod mają własne trasy i własny resolver. Nazwij sterownik, przetestuj ten sam endpoint z wszystkich trzech, a potem napraw kontekst, który zawiódł.

Prywatne API odpowiada z twojego laptopa, a Pod w minikube nie może go osiągnąć. Zanim cokolwiek zmienisz na hoście, nazwij sterownik stojący za aktywnym profilem, bo ten jeden fakt decyduje, z której sieci żądanie faktycznie wychodzi. Potem przetestuj ten sam endpoint z hosta, z węzła i z Poda. Tylko jeden z tych trzech zawiódł, a błędne przypuszczenie kosztuje popołudnie.

Krok 0: nazwij sterownik i źródło

Zapytaj minikube, który profil jest aktywny i jak działa. Sterownik kontenerowy umieszcza węzeł w kontenerze na twojej maszynie, sterownik VM umieszcza go w maszynie wirtualnej, a sterownik zdalny umieszcza go zupełnie gdzie indziej.

minikube profile list
minikube status
kubectl config current-context

Zapisz na tej podstawie, skąd pochodzi żądanie. Odpowiedź decyduje, czyj resolver i które trasy mają znaczenie, a to nie zawsze host. Dwa profile na tym samym laptopie mogą zachowywać się zupełnie różnie dla tego samego 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

Krok 1: przetestuj ten sam endpoint trzy razy

Użyj jednego nieszkodliwego endpointu i zachowaj ten sam hostname, port i rodzinę adresów we wszystkich trzech testach. Zmiana któregokolwiek z nich między uruchomieniami sprawia, że wyniki nie są porównywalne.

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

Udany pull obrazu przez węzeł nic nie dowodzi w kwestii rozwiązywania nazw dla prywatnego hosta. Udane żądanie publiczne dowodzi jeszcze mniej. Trzymaj wyniki osobno dla każdego kontekstu, bo wzorzec w trzech wierszach to diagnoza, a pojedyncza porażka to wskazówka.

Jeśli wiersz hosta też zawodzi, zatrzymaj się. Masz problem z siecią hosta, a klaster to rozproszenie uwagi.

Krok 2: zachowaj ścieżkę hosta do klastra

Jest drugi kierunek, o którym ludzie zapominają: host musi nadal docierać do własnego API i usług klastra. Klient VPN może zainstalować trasy, które konkurują z prefiksami, których minikube używa dla swojej sieci węzłów, zakresu usług i zakresu podów.

Gdy tak się dzieje, objaw jest mylący, bo tunel działa, a kubectl przestaje odpowiadać albo NodePort odmawia połączeń. Wygląda to na awarię klastra, a jest awarią routingu laptopa.

Sprawdź tablicę routingu hosta wobec zakresów minikube, zanim obwiniisz tunel o cokolwiek innego. Nakładanie się zwykle widać jako bardziej szczegółową trasę wskazującą na interfejs tunelu dla prefiksu, który klaster uważa za własny.

Krok 3: rozwiąż nakładanie się bez wyłączania VPN

Własny podręcznik VPN i proxy minikube omawia te konflikty i traktuje swoje przykładowe zakresy jako rzeczy do sprawdzenia, a nie uniwersalną listę. Przeczytaj go razem z profilem, który faktycznie masz.

Tam, gdzie istnieje prawdziwe nakładanie się, wspieraną odpowiedzią jest niepokrywający się zakres lub świadoma lokalna polityka dostępu zatwierdzona przez właściciela VPN. Zmiana zakresu usług to nie to samo co zmiana zakresu podów, a żadna z nich nie jest tym samym co zmiana sieci węzłów.

Wyłączenie firmowego tunelu, żeby lokalny klaster działał, nie jest obejściem; to decyzja polityczna, którą musi podjąć ktoś inny. Zanieś ją tej osobie, zamiast robić to po cichu, gdy wszyscy inni poszli do domu. Jeśli już to zrobiłeś, przywróć to, zanim zapytasz.

Krok 4: rozdziel proxy, DNS i cztery kształty awarii

Jeśli wymagany jest proxy, ustal, który kontekst go potrzebuje. Ustawienie przeglądarki na hoście nie konfiguruje procesu wewnątrz węzła, a Pod potrzebuje zmiennych środowiskowych albo konfiguracji proxy na poziomie klastra.

Potem sklasyfikuj awarię zamiast ją opisywać. Nazwa, która się nie rozwiązuje, to DNS. Nazwa, która się rozwiązuje i odmawia połączenia, to routing albo listener. Połączenie, które się nawiązuje i zawodzi na tożsamości, to TLS. Udane połączenie z treścią błędu to aplikacja.

Każda z tych czterech należy do innej naprawy, a tylko jedna dotyczy VPN. Zapisz, którą zaobserwowałeś w każdym kontekście, a następna osoba odziedziczy dowody zamiast opowieści.

Powiązane artykuły