Prywatne węzły GKE nie decydują, którego API używa kubectl

Węzły są prywatne, VPN do nich dociera, a kubectl nadal nie potrafi rozmawiać z klastrem. Te dwa fakty nie mają ze sobą związku. Adres, którego używa kubectl, pochodzi z adresu URL serwera zapisanego w kubeconfig w chwili pobierania danych uwierzytelniających, i żadna dodana trasa go nie zmienia. Tymczasem węzły wcale nie są tym, do czego kubectl próbuje dotrzeć.

Pięć kontroli, zaczynając od jedynej wartości, która ma znaczenie.

Kontrola 1: odczytaj adres URL serwera w kubeconfig

Wypisz punkt końcowy bez wylewania danych uwierzytelniających: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Ten jeden ciąg mówi, czy klient wskazuje adres IP, nazwę DNS, czy adres zewnętrzny, którego nie zamierzałeś. Wszystko inne w tym dochodzeniu z tego wynika.

Jeśli adres URL nie jest punktem końcowym, który sądziłeś, że skonfigurowałeś, reszta diagnozy jest rozproszeniem uwagi.

Kontrola 2: dopasuj adres URL do typu punktu końcowego

Obecne GKE obsługuje dostęp do płaszczyzny sterowania zarówno przez IP, jak i przez DNS, a pobrane dane uwierzytelniające wybierają jeden z nich. gcloud container clusters get-credentials NAME --location REGION --internal-ip zapisuje punkt końcowy wewnętrznego IP, natomiast --dns-endpoint wybiera dostęp przez DNS. Żadna z flag nie zapewnia ścieżki sieciowej, co zaskakuje osoby oczekujące, że pobranie naprawi łączność. Celowo powtórz pobieranie, a potem ponownie odczytaj adres URL.

Zmiana flag bez ponownego odczytania adresu URL to sposób, w jaki laptop zostaje z danymi uwierzytelniającymi dwóch klastrów i jednym mylącym błędem.

Wpis w autoryzowanej sieci określa, kto może dotrzeć do zewnętrznego punktu końcowego, i nie dotyczy wewnętrznego. Rozszerzanie go, by przetestować prywatną ścieżkę, zmienia twoją ekspozycję, a nie diagnozę.

Kontrola 3: udowodnij ścieżkę do tego punktu końcowego

Jeśli adres URL to wewnętrzny adres IP, sprawdź trasę z sieci, w której klient faktycznie się znajduje, dozwolony zakres źródłowy i ustawienie dostępu regionalnego lub globalnego klastra. Zakres płaszczyzny sterowania i podsieć węzłów to nie ten sam cel, więc działająca trasa do węzłów niczego nie dowodzi w kwestii punktu końcowego. Dla dostępu przez DNS ścieżką jest łączność z Google API wraz z udokumentowanym mechanizmem Private Google Access, a nie trasa do podsieci workerów. Przetestuj punkt końcowy zwykłym połączeniem TCP, zanim obwinisz kubectl.

Przekroczenie limitu czasu to problem ścieżki. 403 to problem polityki. Nie mają wspólnego rozwiązania.

Kontrola 4: oddziel logi i exec od wywołań API

Jeśli zwykłe żądania API się udają, a kubectl logs lub kubectl exec zawodzi, masz już za sobą wybór punktu końcowego. Te operacje wymagają odpowiednich uprawnień Kubernetes i zależą od komunikacji płaszczyzny sterowania z węzłami, a niepowodzenie może być odpowiedzią Forbidden, a nie przekroczeniem limitu czasu. Dostęp SSH do węzła testuje zupełnie inną usługę i ich nie ustanawia.

Przeczytaj klasę błędu, zanim ponownie otworzysz zgłoszenie VPN, bo te dwie klasy żyją w różnych miejscach.

Kontrola 5: zostaw trzy obserwacje dla następnej osoby

Zapisz wybrany adres URL API, czy jedno autoryzowane żądanie API działa i dokładnie która późniejsza operacja zawodzi, wraz z treścią błędu. Te trzy linie oddzielają wybór punktu końcowego od dostępu do węzłów i nie pozwalają obwinić całkiem dobrej trasy VPN o żądanie, którego nigdy nie przeniosła.

Następny inżynier zapyta, czy tunel jest zepsuty. Twoja notatka powinna już na to odpowiedzieć.