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 маршрутун ал эч качан ташыбаган суроого күнөөлөөгө жол бербейт.

Кийинки инженер туннель бузулдубу деп сурайт. Сиздин жазууңуз мурун эле жооп бериши керек.