minikube не стигнува до приватен API? Прво проверете го драјверот
Хостот, јазолот и Pod имаат свои рути и свој resolver. Именувајте го драјверот, тестирајте ја истата крајна точка од сите три и потоа поправете го контекстот што не успеа.
Приватен API одговара од вашиот лаптоп, а Pod во minikube не може да го достигне. Пред да промените нешто на хостот, именувајте го драјверот зад активниот профил, бидејќи тој еден факт одлучува од која мрежа всушност излегува барањето. Потоа тестирајте ја истата крајна точка од хостот, од јазолот и од Pod. Само еден од тие три е тоа што не успеа, а погрешна претпоставка чини попладне.
Чекор 0: именувајте го драјверот и изворот
Прашајте го minikube кој профил е активен и како работи. Драјверот за контејнери го става јазолот во контејнер на вашата машина, VM драјверот го става во виртуелна машина, а далечинскиот драјвер го става сосема на друго место.
minikube profile list
minikube status
kubectl config current-context
Од тоа запишете од каде потекнува барањето. Одговорот одредува чиј resolver и кои рути се важни, и тоа не е секогаш оној на хостот. Два профила на истиот лаптоп можат целосно различно да се однесуваат за истиот URL.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod 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. Запишете кој сте го забележале во секој контекст, и следниот човек наследува докази наместо приказна.