گره‌های خصوصی GKE تعیین نمی‌کنند kubectl از کدام API استفاده می‌کند

گره‌ها خصوصی‌اند، VPN به آن‌ها می‌رسد، و با این حال kubectl نمی‌تواند با خوشه گفتگو کند. این دو واقعیت به هم مربوط نیستند. نشانی‌ای که kubectl استفاده می‌کند از URL سروری می‌آید که هنگام دریافت اعتبارنامه‌ها در kubeconfig ذخیره شده است، و هیچ مسیری که اضافه کنید آن را تغییر نمی‌دهد. در این میان، گره‌ها اصلاً چیزی نیستند که 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 است، نه مسیری به زیرشبکهٔ کارگرها. پیش از سرزنش kubectl، نقطهٔ پایانی را با یک اتصال TCP ساده بیازمایید.

وقفهٔ زمانی یک مشکل مسیر است. 403 یک مشکل سیاست است. این دو راه‌حل مشترکی ندارند.

بررسی 4: گزارش‌ها و exec را از فراخوانی‌های API جدا کنید

اگر درخواست‌های معمولی API موفق می‌شوند و kubectl logs یا kubectl exec شکست می‌خورد، شما از انتخاب نقطهٔ پایانی گذشته‌اید. آن عملیات به مجوزهای مربوط Kubernetes نیاز دارند و به ارتباط صفحهٔ کنترل با گره‌ها وابسته‌اند، و شکست می‌تواند پاسخ Forbidden باشد نه وقفهٔ زمانی. دسترسی SSH به یک گره سرویس کاملاً دیگری را می‌آزماید و آن‌ها را برقرار نمی‌کند.

پیش از بازکردن دوبارهٔ بلیت VPN، ردهٔ خطا را بخوانید، زیرا این دو رده در جاهای مختلف زندگی می‌کنند.

بررسی 5: سه مشاهده برای نفر بعدی نگه دارید

URL انتخاب‌شدهٔ API، اینکه یک درخواست مجاز API کار می‌کند یا نه، و اینکه دقیقاً کدام عملیات بعدی شکست می‌خورد را همراه با متن خطا ثبت کنید. آن سه خط انتخاب نقطهٔ پایانی را از دسترسی به گره جدا می‌کند، و نمی‌گذارد مسیر VPN کاملاً سالمی به خاطر درخواستی که هرگز آن را حمل نکرده سرزنش شود.

مهندس بعدی خواهد پرسید آیا تونل خراب است. یادداشت شما باید از پیش به آن پاسخ داده باشد.