GKE-ի մասնավոր հանգույցները չեն որոշում, թե kubectl-ը որ API-ն է օգտագործում

Հանգույցները մասնավոր են, VPN-ը հասնում է նրանց, և այնուամենայնիվ kubectl-ը չի կարողանում խոսել կլաստերի հետ։ Այս երկու փաստերը կապված չեն իրար հետ։ Այն հասցեն, որն օգտագործում է kubectl-ը, գալիս է kubeconfig-ում պահված սերվերի URL-ից, որը գրանցվել է հավատարմագրերը ստանալու պահին, և ձեր ավելացրած ոչ մի ուղեգիծ այն չի փոխում։ Մինչդեռ հանգույցները բոլորովին էլ այն չեն, ինչին 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 ուղին մեղադրվի այնպիսի հարցման համար, որը երբեք չի տեղափոխել։

Հաջորդ ինժեները կհարցնի՝ արդյոք թունելը կոտրված է։ Ձեր գրառումը պետք է արդեն պատասխանի դրան։