Приватные узлы GKE не определяют, какой API использует kubectl

Узлы приватные, VPN до них доходит, а kubectl всё равно не может связаться с кластером. Эти два факта не связаны. Адрес, который использует kubectl, берётся из URL сервера, сохранённого в kubeconfig при получении учётных данных, и ни один добавленный вами маршрут его не меняет. При этом узлы — вовсе не то, к чему kubectl пытается обратиться.

Пять проверок, начиная с единственного значения, которое имеет смысл.

Проверка 1: прочитайте URL сервера в kubeconfig

Выведите конечную точку, не раскрывая учётные данные: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Эта одна строка скажет, направлен ли клиент на IP-адрес, DNS-имя или внешний адрес, который вы не планировали. Всё остальное в этом расследовании вытекает из неё.

Если URL — не та конечная точка, которую вы думали, что настроили, остальная диагностика только отвлекает.

Проверка 2: сопоставьте URL с типом конечной точки

Текущий GKE поддерживает доступ к плоскости управления как по IP, так и по DNS, и полученные учётные данные выбирают один из вариантов. gcloud container clusters get-credentials NAME --location REGION --internal-ip записывает конечную точку внутреннего IP, а --dns-endpoint выбирает доступ по DNS. Ни один из флагов не создаёт сетевой маршрут, что удивляет тех, кто ждёт, что получение учётных данных исправит связность. Повторите получение намеренно и после этого снова прочитайте URL.

Смена флагов без повторного чтения URL — это путь, при котором ноутбук остаётся с учётными данными двух кластеров и одной запутанной ошибкой.

Запись в разрешённой сети определяет, кто может достичь внешней конечной точки, и не применяется к внутренней. Расширение её для проверки приватного пути меняет вашу экспозицию, а не диагностику.

Проверка 3: докажите путь к этой конечной точке

Если URL — внутренний IP, проверьте маршрут из сети, в которой клиент действительно находится, разрешённый диапазон источников и региональную или глобальную настройку доступа кластера. Диапазон плоскости управления и подсеть узлов — не один и тот же адресат, поэтому работающий маршрут к узлам ничего не доказывает о конечной точке. Для доступа по DNS путь — это связность с Google API с документированным механизмом Private Google Access, а не маршрут к подсети рабочих узлов. Проверьте конечную точку обычным TCP-соединением, прежде чем винить kubectl.

Тайм-аут — это проблема пути. 403 — это проблема политики. У них нет общего исправления.

Проверка 4: отделите журналы и exec от вызовов API

Если обычные запросы API проходят, а kubectl logs или kubectl exec не работает, вы уже прошли выбор конечной точки. Эти операции требуют соответствующих прав Kubernetes и зависят от связи плоскости управления с узлами, а сбой может быть ответом Forbidden, а не тайм-аутом. SSH-доступ к узлу проверяет совсем другой сервис и их не устанавливает.

Прочитайте класс ошибки, прежде чем снова открывать тикет VPN, потому что эти два класса живут в разных местах.

Проверка 5: сохраните три наблюдения для следующего человека

Запишите выбранный URL API, работает ли один авторизованный запрос API и какая именно последующая операция не работает, вместе с текстом ошибки. Эти три строки отделяют выбор конечной точки от доступа к узлам и не дают обвинить вполне хороший маршрут VPN в запросе, который он никогда не переносил.

Следующий инженер спросит, не сломан ли туннель. В вашей заметке уже должен быть ответ.