د GKE شخصي نوډونه نه ټاکي چې kubectl کوم API کاروي

نوډونه شخصي دي، VPN ورته رسېږي، او بیا هم kubectl نشي کولی له کلسټر سره خبرې وکړي۔ دا دوه حقایق یو له بل سره تړاو نه لري۔ هغه آدرس چې kubectl کاروي د سرور URL څخه راځي چې په kubeconfig کې هغه وخت خوندي شو چې اعتبارلیکونه واخیستل شول، او هغه لار چې تاسو اضافه کوئ هغه نه بدلوي۔ په دې منځ کې، نوډونه هغه څه نه دي چې 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 لارې لپاره د هغې غوښتنې تورنول بندوي چې هغې هیڅکله نه ده وړلې۔

بل انجینر به وپوښتي چې تونل مات دی که نه۔ ستاسو یادښت باید لا دمخه د هغې ځواب ورکړی وي۔