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. Запишите, какой вы наблюдали в каждом контексте, и следующий человек унаследует доказательства, а не историю.

Похожие статьи