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. Запішыце, які вы назіралі ў кожным кантэксце, і наступны чалавек атрымае ў спадчыну доказы, а не гісторыю.

Падобныя артыкулы