minikube не дістає до приватного API? Спершу перевірте драйвер

Хост, вузол і Pod мають власні маршрути й власний resolver. Назвіть драйвер, перевірте ту саму кінцеву точку з усіх трьох і виправте контекст, який не вдався.

Приватний API відповідає з вашого ноутбука, а Pod у minikube не може до нього дістатися. Перш ніж щось змінювати на хості, назвіть драйвер за активним профілем, бо цей єдиний факт вирішує, з якої мережі запит насправді виходить. Потім перевірте ту саму кінцеву точку з хоста, з вузла й з Pod. Лише один із цих трьох і є те, що не вдалося, і хибне припущення коштує пообіддя.

Крок 0: назвіть драйвер і джерело

Запитайте minikube, який профіль активний і як він працює. Драйвер контейнерів ставить вузол у контейнер на вашій машині, драйвер VM ставить його у віртуальну машину, а віддалений драйвер ставить його зовсім в інше місце.

minikube profile list
minikube status
kubectl config current-context

Із цього запишіть, звідки походить запит. Відповідь визначає, чий resolver і які маршрути мають значення, і це не завжди хостовий. Два профілі на одному ноутбуці можуть поводитися цілком по-різному для того самого 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

Крок 1: перевірте ту саму кінцеву точку тричі

Використайте одну нешкідливу кінцеву точку й збережіть ім’я хоста, порт і родину адрес однаковими в усіх трьох тестах. Якщо змінити щось із цього між запусками, результати стануть непорівнянними.

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

Успішне витягування образу вузлом нічого не доводить про розв’язання імен для приватного хоста. Успішний публічний запит доводить ще менше. Тримайте результати окремо за контекстом, бо закономірність у трьох рядках — це діагноз, а одиничний збій — це підказка.

Якщо рядок хоста теж не вдається, зупиніться. У вас проблема з мережею хоста, а кластер — це відволікання.

Крок 2: збережіть шлях хоста до кластера

Є другий напрямок, який люди забувають: хост має далі діставатися до власного API та сервісів кластера. Клієнт VPN може встановити маршрути, які конкурують із префіксами, що minikube використовує для своєї мережі вузлів, діапазону сервісів і діапазону подів.

Коли це стається, симптом заплутує, бо тунель працює, а kubectl перестає відповідати або NodePort відмовляє в з’єднаннях. Це виглядає як збій кластера, а насправді це збій маршрутизації ноутбука.

Перевірте таблицю маршрутизації хоста щодо діапазонів minikube, перш ніж звинувачувати тунель у будь-чому іншому. Перекриття зазвичай видно як конкретніший маршрут, що вказує на інтерфейс тунелю для префікса, який кластер вважає своїм.

Крок 3: розв’яжіть перекриття, не вимикаючи VPN

Власний посібник minikube з VPN і проксі розглядає ці конфлікти й трактує свої приклади діапазонів як те, що треба перевірити, а не як універсальний список. Прочитайте його разом із профілем, який у вас насправді є.

Там, де є реальне перекриття, підтримана відповідь — діапазон без перекриття або свідома політика локального доступу, схвалена власником VPN. Зміна діапазону сервісів — це не те саме, що зміна діапазону подів, і жодне з них не те саме, що зміна мережі вузлів.

Вимикання корпоративного тунелю, щоб локальний кластер працював, — це не обхідний шлях; це рішення про політику, яке має ухвалити хтось інший. Віднесіть його цій людині, замість того щоб робити це тихо після того, як усі інші пішли додому. Якщо ви вже це зробили, поверніть усе назад, перш ніж питати.

Крок 4: відокремте проксі, DNS і чотири форми збою

Якщо потрібен проксі, визначте, який контекст його потребує. Налаштування браузера на хості не конфігурує процес усередині вузла, а Pod потребує змінних середовища або конфігурації проксі на рівні кластера.

Потім класифікуйте збій, а не описуйте його. Ім’я, яке не розв’язується, — це DNS. Ім’я, яке розв’язується й відмовляє у з’єднанні, — це маршрутизація або listener. З’єднання, яке встановлюється й зривається на ідентичності, — це TLS. Успішне з’єднання з тілом помилки — це застосунок.

Кожен із цих чотирьох належить до іншого виправлення, і лише один із них про VPN. Запишіть, який ви спостерігали в кожному контексті, і наступна людина успадкує докази, а не історію.

Схожі статті