Прыватныя вузлы GKE не вызначаюць, які API выкарыстоўвае kubectl

Вузлы прыватныя, VPN да іх дастае, а kubectl усё яшчэ не можа звязацца з кластарам. Гэтыя два факты не звязаныя паміж сабой. Адрас, які выкарыстоўвае kubectl, паходзіць з URL сервера, захаванага ў kubeconfig у момант атрымання ўліковых даных, і ні адзін дададзены вамі маршрут не змяняе яго. Тым часам вузлы — не тое, да чаго kubectl наогул імкнецца.

Пяць праверак, пачынаючы з адзінага значэння, якое мае сэнс.

Праверка 1: прачытайце URL сервера ў kubeconfig

Вывядзіце канчатковы пункт, не выліваючы ўліковыя даныя: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Гэты адзіны радок паведаміць, ці кліент накіраваны на IP-адрас, DNS-імя або знешні адрас, які вы не мелі на ўвазе. Усё астатняе ў гэтым расследаванні вынікае з яго.

Калі URL — не той канчатковы пункт, які вы, як вам здавалася, наладзілі, рэшта дыягностыкі — проста адцягненне ўвагі.

Праверка 2: суаднясіце URL з тыпам канчатковага пункта

Сучасны GKE падтрымлівае доступ да плоскасці кіравання як праз IP, так і праз DNS, і атрыманыя ўліковыя даныя выбіраюць адзін з іх. gcloud container clusters get-credentials NAME --location REGION --internal-ip запісвае канчатковы пункт унутранага IP, а --dns-endpoint выбірае доступ праз DNS. Ні адзін з сцягоў не стварае сеткавы маршрут, што здзіўляе тых, хто чакае, што атрыманне даных выправіць злучэнне. Атрымайце даныя свядома яшчэ раз і пасля гэтага зноў прачытайце URL.

Змена сцягоў без паўторнага чытання URL — гэта шлях, пры якім ноўтбук застаецца з уліковымі данымі двух кластараў і адной заблытанай памылкай.

Запіс у дазволенай сетцы вызначае, каму можна дасягаць знешняга канчатковага пункта, і не тычыцца ўнутранага. Пашырэнне яго для праверкі прыватнага шляху змяняе вашу экспазіцыю, а не вашу дыягностыку.

Праверка 3: дакажыце шлях да гэтага канчатковага пункта

Калі URL — унутраны IP, праверце маршрут з сеткі, дзе фактычна знаходзіцца кліент, дазволены дыяпазон крыніц і рэгіянальны або глабальны настройка доступу кластара. Дыяпазон плоскасці кіравання і падсетка вузлоў — не адна і тая ж мэта, таму працоўны маршрут да вузлоў нічога не даказвае пра канчатковы пункт. Для доступу праз DNS шлях — гэта злучэнне з Google API з яго дакументаваным парадкам Private Google Access, а не маршрут да падсеткі працоўных вузлоў. Праверце канчатковы пункт звычайным TCP-злучэннем, перш чым вінаваціць kubectl.

Тайм-аўт — гэта праблема шляху. 403 — гэта праблема палітыкі. Яны не маюць агульнага выпраўлення.

Праверка 4: аддзяліце логі і exec ад выклікаў API

Калі звычайныя запыты API праходзяць, а kubectl logs або kubectl exec не працуе, вы ўжо мінулі выбар канчатковага пункта. Гэтыя аперацыі патрабуюць адпаведных правоў Kubernetes і залежаць ад сувязі плоскасці кіравання з вузламі, а збой можа быць адказам Forbidden, а не тайм-аўтам. SSH-доступ да вузла правярае зусім іншую службу і не ўстанаўлівае іх.

Прачытайце клас памылкі, перш чым адкрываць зноў тыкет VPN, бо гэтыя два класы жывуць у розных месцах.

Праверка 5: пакіньце тры назіранні для наступнага чалавека

Запішыце выбраны URL API, ці працуе адзін дазволены запыт API, і якая менавіта наступная аперацыя не працуе, разам з тэкстам памылкі. Гэтыя тры радкі аддзяляюць выбар канчатковага пункта ад доступу да вузлоў і не даюць абвінаваціць цалкам добры маршрут VPN у запыце, які ён ніколі не перавозіў.

Наступны інжынер спытае, ці не зламаны тунель. Ваша нататка павінна ўжо адказваць на гэта.