GKE жеке түйіндері kubectl қай API қолданатынын шешпейді

Түйіндер жеке, VPN оларға жетеді, бірақ kubectl кластермен сөйлесе алмайды. Бұл екі факт бір-бірімен байланысты емес. kubectl қолданатын мекенжай тіркелгі деректері алынған кезде kubeconfig ішінде сақталған сервер URL мекенжайынан келеді, және сіз қосқан ешбір маршрут оны өзгертпейді. Бұл арада түйіндер kubectl жетуге тырысып жатқан нәрсе мүлде емес.

Бес тексеру, маңызды жалғыз мәннен бастап.

1-тексеру: kubeconfig ішіндегі сервер URL мекенжайын оқыңыз

Тіркелгі деректерін төгіп тастамай соңғы нүктені басып шығарыңыз: 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 негізіндегі қатынау үшін жол — құжатталған Private Google Access тәртібімен Google API байланысы, жұмысшылардың ішкі желісіне маршрут емес. kubectl-ті кінәламас бұрын соңғы нүктені қарапайым TCP байланысымен тексеріңіз.

Тайм-аут — жол мәселесі. 403 — саясат мәселесі. Олардың ортақ шешімі жоқ.

4-тексеру: журналдар мен exec-ті API шақыруларынан бөліңіз

Егер қарапайым API сұраулары сәтті болып, kubectl logs немесе kubectl exec сәтсіз болса, сіз соңғы нүктені таңдаудан өтіп кеткенсіз. Бұл операцияларға тиісті Kubernetes рұқсаттары қажет және олар басқару жазықтығының түйіндермен байланысына тәуелді, ал сәтсіздік тайм-аут емес, Forbidden жауабы болуы мүмкін. Түйінге SSH қатынау мүлде басқа қызметті тексереді және оларды орнатпайды.

VPN билетін қайта ашпас бұрын қате класын оқыңыз, өйткені екі класс әр жерде тұрады.

5-тексеру: келесі адам үшін үш бақылау сақтаңыз

Таңдалған API URL-ді, бір рұқсат етілген API сұрауының жұмыс істейтінін және кейінгі қай операцияның сәтсіз болатынын қате мәтінімен бірге жазып қойыңыз. Сол үш жол соңғы нүктені таңдауды түйінге қатынаудан ажыратады және мүлде жақсы VPN маршрутын ол ешқашан тасымаған сұрауға кінәлауға жол бермейді.

Келесі инженер туннель бүлінген бе деп сұрайды. Сіздің жазбаңыз бұған әлдеқашан жауап беруі керек.