Приватні вузли 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 у запиті, який він ніколи не переносив.

Наступний інженер запитає, чи не зламаний тунель. Ваша нотатка вже має відповідати на це.