GKE xususiy tugunlari kubectl qaysi API ishlatishini hal qilmaydi

Tugunlar xususiy, VPN ularga yetib boradi, ammo kubectl klaster bilan gaplasha olmaydi. Bu ikki fakt bir-biri bilan bog‘liq emas. kubectl ishlatadigan manzil hisob ma’lumotlari olinganda kubeconfig’da saqlangan server URL manzilidan keladi va siz qo‘shgan hech qanday yo‘nalish uni o‘zgartirmaydi. Ayni paytda, tugunlar kubectl yetib bormoqchi bo‘lgan narsa umuman emas.

Beshta tekshiruv, muhim bo‘lgan yagona qiymatdan boshlab.

Tekshiruv 1: kubeconfig’dagi server URL manzilini o‘qing

Hisob ma’lumotlarini to‘kmasdan oxirgi nuqtani chop eting: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Shu bitta satr mijoz IP manzilga, DNS nomiga yoki siz nazarda tutmagan tashqi manzilga ishora qilyaptimi-yo‘qmi, shuni aytadi. Bu tekshiruvdagi qolgan hamma narsa shundan kelib chiqadi.

Agar URL siz sozlagan deb o‘ylagan oxirgi nuqta bo‘lmasa, diagnozning qolgan qismi faqat chalg‘itishdir.

Tekshiruv 2: URLni oxirgi nuqta turiga moslang

Hozirgi GKE boshqaruv tekisligiga IP asosidagi ham, DNS asosidagi ham kirishni qo‘llab-quvvatlaydi, siz olgan hisob ma’lumotlari ulardan birini tanlaydi. gcloud container clusters get-credentials NAME --location REGION --internal-ip ichki IP oxirgi nuqtasini yozadi, --dns-endpoint esa DNS asosidagi kirishni tanlaydi. Hech bir bayroq tarmoq yo‘lini ta’minlamaydi, bu esa hisob ma’lumotlarini olish aloqani tuzatadi deb kutganlarni hayratga soladi. Olishni ataylab takrorlang va keyin URLni yana o‘qing.

URLni qayta o‘qimasdan bayroqlarni o‘zgartirish — noutbuk ikkita klasterning hisob ma’lumotlari va bitta chalkash xato bilan qolishining yo‘li.

Ruxsat etilgan tarmoq yozuvi tashqi oxirgi nuqtaga kim yetib borishi mumkinligini belgilaydi va ichkisiga qo‘llanilmaydi. Xususiy yo‘lni sinash uchun uni kengaytirish diagnozingizni emas, ta’sirlanish darajangizni o‘zgartiradi.

Tekshiruv 3: o‘sha oxirgi nuqtagacha bo‘lgan yo‘lni isbotlang

Agar URL ichki IP bo‘lsa, yo‘nalishni mijoz haqiqatan o‘tirgan tarmoqdan, ruxsat etilgan manba diapazonidan va klasterning mintaqaviy yoki global kirish sozlamasidan tekshiring. Boshqaruv tekisligi diapazoni va tugunlar quyi tarmog‘i bir xil manzil emas, shuning uchun tugunlargacha ishlaydigan yo‘nalish oxirgi nuqta haqida hech narsani isbotlamaydi. DNS asosidagi kirish uchun yo‘l hujjatlashtirilgan Private Google Access tartibi bilan Google API aloqasi, ishchilar quyi tarmog‘iga yo‘nalish emas. kubectlni ayblashdan oldin oxirgi nuqtani oddiy TCP ulanishi bilan sinab ko‘ring.

Taym-aut — yo‘l muammosi. 403 — siyosat muammosi. Ularning umumiy yechimi yo‘q.

Tekshiruv 4: jurnallar va execni API chaqiruvlaridan ajrating

Agar oddiy API so‘rovlari muvaffaqiyatli bo‘lib, kubectl logs yoki kubectl exec muvaffaqiyatsiz bo‘lsa, siz oxirgi nuqta tanlovidan o‘tib bo‘lgansiz. Bu amallar tegishli Kubernetes ruxsatlarini talab qiladi va boshqaruv tekisligidan tugunlarga aloqaga bog‘liq, muvaffaqiyatsizlik esa taym-aut emas, Forbidden javobi bo‘lishi mumkin. Tugunga SSH kirish butunlay boshqa xizmatni sinaydi va ularni o‘rnatmaydi.

VPN chiptasini qayta ochishdan oldin xato sinfini o‘qing, chunki bu ikki sinf turli joylarda yashaydi.

Tekshiruv 5: keyingi odam uchun uchta kuzatuv saqlang

Tanlangan API URLni, bitta ruxsat etilgan API so‘rovi ishlayaptimi-yo‘qmi va qaysi keyingi amal muvaffaqiyatsiz bo‘lishini xato matni bilan birga yozib qo‘ying. O‘sha uch satr oxirgi nuqta tanlovini tugunlarga kirishdan ajratadi va butunlay yaxshi VPN yo‘nalishini u hech qachon tashimagan so‘rovda ayblashning oldini oladi.

Keyingi muhandis tunnel buzilganmi-yo‘qmi deb so‘raydi. Yozuvingiz bunga allaqachon javob bergan bo‘lishi kerak.