minikube жеке API-ға жетпей ме? Алдымен драйверді тексеріңіз
Хост, түйін және Pod әрқайсысының өз маршруттары мен өз resolver-і бар. Драйверді атаңыз, сол endpoint-ті үшеуінен де тексеріңіз, содан кейін сәтсіз болған контексті түзетіңіз.
Жеке API ноутбукіңізден жауап береді, ал minikube ішіндегі Pod оған жете алмайды. Хостта бірдеңе өзгертудің алдында белсенді профильдің артындағы драйверді атаңыз, өйткені осы бір факт сұраныстың іс жүзінде қай желіден шығатынын шешеді. Содан кейін сол endpoint-ті хосттан, түйіннен және 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-қадам: сол endpoint-ті үш рет тексеріңіз
Бір қауіпсіз endpoint пайдаланыңыз және хост атын, портты және мекенжай тобын үш тестіде де бірдей ұстаңыз. Олардың кез келгенін іске қосулар арасында өзгертсеңіз, нәтижелерді салыстыру мүмкін болмайды.
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
Түйіннің сәтті image тартуы жеке хост үшін атауларды шешу туралы ештеңе дәлелдемейді. Сәтті ашық сұраныс одан да азын дәлелдейді. Нәтижелерді контекст бойынша бөлек ұстаңыз, өйткені үш жолдағы заңдылық — диагностика, ал жалғыз сәтсіздік — белгі.
Егер хост жолы да сәтсіз болса, тоқтаңыз. Сізде хосттың желі мәселесі бар, ал кластер — назарды бұтатын нәрсе.
2-қадам: хосттың кластерге барар жолын сақтаңыз
Адамдар ұмытатын екінші бағыт бар: хост кластердің өз API-іне және қызметтеріне жете беруі керек. VPN клиенті minikube түйіндер желісі, қызмет ауқымы және pod ауқымы үшін пайдаланатын префикстермен бәсекелесетін маршруттар орнатуы мүмкін.
Бұл болғанда симптом шатастырады, өйткені туннель жұмыс істейді, ал kubectl жауап беруді тоқтатады немесе NodePort қосылымдарды қабылдамайды. Бұл кластер ақауына ұқсайды, ал шын мәнінде ноутбуктің маршруттау ақауы.
Туннельді басқа нәрсе үшін кінәламас бұрын хосттың маршруттау кестесін minikube ауқымдарымен салыстырыңыз. Қабаттасу әдетте кластер өзіне тиесілі деп күтетін префикс үшін туннель интерфейсіне сілтейтін нақтырақ маршрут ретінде көрінеді.
3-қадам: VPN-ді өшірмей қабаттасуды шешіңіз
minikube-тың өз VPN және прокси нұсқаулығы бұл қақтығыстарды қарастырады және мысал ауқымдарын әмбебап тізім емес, тексерілетін нәрселер ретінде қарайды. Оны шын мәнінде бар профиліңізбен бірге оқыңыз.
Нақты қабаттасу бар жерде қолдау көрсетілетін жауап — қабаттаспайтын ауқым немесе VPN иесі бекіткен әдейі жергілікті қатынау саясаты. Қызмет ауқымын өзгерту pod ауқымын өзгертумен бірдей емес, және екеуі де түйіндер желісін өзгертумен бірдей емес.
Жергілікті кластер жұмыс істеуі үшін корпоративтік туннельді өшіру — бұл айналма жол емес; бұл басқа біреу қабылдауға тиіс саяси шешім. Барлығы үйлеріне қайтқаннан кейін оны үнсіз жасаудың орнына сол адамға апарыңыз. Егер мұны бұрын жасаған болсаңыз, сұрамас бұрын қайтарыңыз.
4-қадам: прокси, DNS және төрт ақау түрін ажыратыңыз
Егер прокси қажет болса, қай контекстке қажет екенін анықтаңыз. Хосттағы браузер параметрі түйін ішіндегі процесті конфигурацияламайды, ал Pod қоршаған орта айнымалыларын немесе кластер деңгейіндегі прокси конфигурациясын қажет етеді.
Содан кейін ақауды сипаттаудың орнына жіктеңіз. Шешілмейтін атау — DNS. Шешілетін және қосылымнан бас тартатын атау — маршруттау немесе listener. Орнатылатын және сәйкестікте сәтсіз болатын қосылым — TLS. Қате денесімен сәтті қосылым — қолданба.
Осы төртеуінің әрқайсысы басқа түзетуге жатады, және тек біреуі VPN туралы. Әр контексте қайсысын байқағаныңызды жазыңыз, ал келесі адам әңгіме емес, дәлелдерді мұра етеді.