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. Запишете кое сте наблюдавали във всеки контекст и следващият човек наследява доказателства вместо история.

Подобни статии