Приватни 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: оставите три запажања за следећу особу

Запишите изабрани API URL, да ли један овлашћени API захтев ради и тачно која каснија операција не успева, уз текст грешке. Та три реда раздвајају избор крајње тачке од приступа чворовима и спречавају да потпуно добра VPN рута буде окривљена за захтев који никада није носила.

Следећи инжењер ће питати је ли тунел покварен. Ваша белешка би то већ требало да одговори.