Privátní uzly GKE nerozhodují, které API kubectl používá

Uzly jsou privátní, VPN se k nim dostane, a přesto kubectl s clusterem nemluví. Tyto dvě skutečnosti spolu nesouvisejí. Adresa, kterou kubectl používá, pochází z URL serveru uložené v kubeconfig při načtení přihlašovacích údajů, a žádná přidaná trasa ji nemění. Uzly navíc vůbec nejsou to, na co se kubectl snaží dosáhnout.

Pět kontrol, počínaje jedinou hodnotou, na které záleží.

Kontrola 1: přečtěte URL serveru v kubeconfig

Vypište koncový bod, aniž byste vypsali přihlašovací údaje: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Tento jediný řetězec vám řekne, zda klient míří na IP adresu, název DNS, nebo na externí adresu, kterou jste nezamýšleli. Vše ostatní v tomto vyšetřování z toho vyplývá.

Pokud URL není koncový bod, který jste si mysleli, že jste nastavili, je zbytek diagnostiky jen rozptýlení.

Kontrola 2: přiřaďte URL k typu koncového bodu

Současné GKE podporuje přístup k řídicí rovině jak přes IP, tak přes DNS a načtené přihlašovací údaje vyberou jednu z možností. gcloud container clusters get-credentials NAME --location REGION --internal-ip zapíše koncový bod interní IP, zatímco --dns-endpoint vybere přístup přes DNS. Ani jeden přepínač nevytváří síťovou cestu, což překvapuje lidi, kteří čekají, že načtení opraví konektivitu. Načtení záměrně zopakujte a poté URL znovu přečtěte.

Měnit přepínače bez opětovného přečtení URL je způsob, jak notebook skončí s přihlašovacími údaji ke dvěma clusterům a jednou matoucí chybou.

Záznam v povolené síti určuje, kdo se může dostat k externímu koncovému bodu, a na interní se nevztahuje. Rozšíření kvůli testování privátní cesty mění vaši expozici, ne vaši diagnostiku.

Kontrola 3: dokažte cestu k tomuto koncovému bodu

Pokud je URL interní IP, ověřte trasu ze sítě, ve které klient skutečně sedí, povolený rozsah zdrojů a regionální nebo globální nastavení přístupu clusteru. Rozsah řídicí roviny a podsíť uzlů nejsou stejný cíl, takže funkční trasa k uzlům o koncovém bodu nic nedokazuje. Pro přístup přes DNS je cestou konektivita ke Google API s dokumentovaným uspořádáním Private Google Access, nikoli trasa do podsítě pracovních uzlů. Otestujte koncový bod běžným TCP připojením, než obviníte kubectl.

Časový limit je problém cesty. 403 je problém politiky. Nemají společné řešení.

Kontrola 4: oddělte logy a exec od volání API

Pokud běžné požadavky API uspějí a kubectl logs nebo kubectl exec selže, už jste za volbou koncového bodu. Tyto operace potřebují odpovídající oprávnění Kubernetes a závisí na komunikaci řídicí roviny s uzly, a selhání může být odpověď Forbidden místo časového limitu. SSH přístup k uzlu testuje úplně jinou službu a neprokazuje je.

Přečtěte si třídu chyby, než znovu otevřete tiket VPN, protože obě třídy žijí na různých místech.

Kontrola 5: nechte tři pozorování pro dalšího člověka

Zapište zvolenou URL API, zda jeden autorizovaný požadavek API funguje, a přesně která pozdější operace selhává, včetně textu chyby. Tyto tři řádky oddělují volbu koncového bodu od přístupu k uzlům a brání tomu, aby byla zcela dobrá trasa VPN obviňována z požadavku, který nikdy nepřenesla.

Další inženýr se zeptá, zda je tunel rozbitý. Vaše poznámka by na to už měla odpovídat.