minikube به یک API خصوصی نمی‌رسد؟ اول درایور را بررسی کنید
هاست، نود و Pod هر کدام مسیرها و resolver خود را دارند. درایور را نام ببرید، همان endpoint را از هر سه آزمایش کنید و سپس زمینه‌ای را که شکست خورد درست کنید.
یک API خصوصی از لپ‌تاپ شما پاسخ می‌دهد و یک Pod در minikube نمی‌تواند به آن برسد. پیش از تغییر هر چیزی روی هاست، درایور پشت پروفایل فعال را نام ببرید، زیرا همین یک واقعیت تعیین می‌کند که درخواست واقعاً از کدام شبکه خارج می‌شود. سپس همان endpoint را از هاست، از نود و از Pod آزمایش کنید. تنها یکی از آن سه همان چیزی است که شکست خورد، و حدس اشتباه یک بعدازظهر هزینه دارد.
گام 0: درایور و مبدأ را نام ببرید
از minikube بپرسید کدام پروفایل فعال است و چگونه اجرا می‌شود. درایور کانتینر نود را در یک کانتینر روی ماشین شما قرار می‌دهد، درایور VM آن را در یک ماشین مجازی قرار می‌دهد، و درایور راه دور آن را جای کاملاً دیگری قرار می‌دهد.
minikube profile list
minikube status
kubectl config current-contextاز این، بنویسید که درخواست از کجا سرچشمه می‌گیرد. پاسخ تعیین می‌کند کدام resolver و کدام مسیرها اهمیت دارند، و همیشه مال هاست نیست. دو پروفایل روی یک لپ‌تاپ می‌توانند برای همان URL کاملاً متفاوت رفتار کنند.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
گام 1: همان endpoint را سه بار آزمایش کنید
از یک endpoint بی‌خطر استفاده کنید و نام میزبان، پورت و خانواده آدرس را در هر سه آزمایش یکسان نگه دارید. اگر هر یک از آن‌ها را بین اجراها تغییر دهید، نتایج قابل مقایسه نیستند.
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthیک image pull موفق توسط نود هیچ چیزی دربارهٔ resolve شدن نام‌ها برای یک هاست خصوصی اثبات نمی‌کند. یک درخواست عمومی موفق حتی کمتر اثبات می‌کند. نتایج را بر اساس زمینه جدا نگه دارید، زیرا الگویی در سه ردیف تشخیص است و یک شکست منفرد یک سرنخ.
اگر ردیف هاست هم شکست بخورد، توقف کنید. شما یک مشکل شبکه در هاست دارید و کلاستر یک حواس‌پرتی است.
گام 2: مسیر هاست به کلاستر را حفظ کنید
جهت دومی هست که مردم فراموش می‌کنند: هاست باید همچنان به API و سرویس‌های خود کلاستر برسد. یک کلاینت VPN می‌تواند مسیرهایی نصب کند که با پیشوندهایی که minikube برای شبکه نودها، محدوده سرویس و محدوده Pod خود استفاده می‌کند رقابت کنند.
وقتی این اتفاق می‌افتد، نشانه گیج‌کننده است، زیرا تونل کار می‌کند و kubectl پاسخ دادن را متوقف می‌کند یا یک NodePort اتصال‌ها را رد می‌کند. شبیه خطای کلاستر به نظر می‌رسد و خطای مسیریابی لپ‌تاپ است.
جدول مسیریابی هاست را با محدوده‌های minikube مقایسه کنید پیش از آنکه تونل را برای هر چیز دیگری سرزنش کنید. هم‌پوشانی معمولاً به‌صورت مسیری خاص‌تر دیده می‌شود که برای پیشوندی که کلاستر آن را مال خود می‌داند به رابط تونل اشاره می‌کند.
گام 3: هم‌پوشانی را بدون غیرفعال کردن VPN حل کنید
راهنمای VPN و proxy خود minikube این تعارض‌ها را بررسی می‌کند و محدوده‌های نمونه‌اش را چیزهایی برای بازرسی می‌داند، نه فهرستی جهانی. آن را در کنار پروفایلی که واقعاً دارید بخوانید.
جایی که هم‌پوشانی واقعی وجود دارد، پاسخ پشتیبانی‌شده یک محدوده بدون هم‌پوشانی یا یک سیاست دسترسی محلی آگاهانه است که مالک VPN آن را تأیید کرده است. تغییر محدوده سرویس همان تغییر محدوده Pod نیست، و هیچ‌کدام همان تغییر شبکه نودها نیست.
غیرفعال کردن تونل شرکتی برای اینکه یک کلاستر محلی کار کند راه‌حل میان‌بر نیست؛ این تصمیمی سیاستی است که شخص دیگری باید بگیرد. آن را به همان شخص ببرید به‌جای اینکه پس از رفتن همه به خانه بی‌صدا انجامش دهید. اگر قبلاً انجام داده‌اید، پیش از پرسیدن برش گردانید.
گام 4: proxy، DNS و چهار شکل شکست را جدا کنید
اگر proxy لازم است، مشخص کنید کدام زمینه به آن نیاز دارد. یک تنظیم مرورگر روی هاست فرآیندی درون نود را پیکربندی نمی‌کند، و یک Pod به متغیرهای محیطی یا پیکربندی proxy در سطح کلاستر نیاز دارد.
سپس خطا را به‌جای توصیف کردن دسته‌بندی کنید. نامی که resolve نمی‌شود DNS است. نامی که resolve می‌شود و اتصال را رد می‌کند مسیریابی یا یک listener است. اتصالی که برقرار می‌شود و در هویت شکست می‌خورد TLS است. اتصال موفق با بدنه خطا خود برنامه است.
هر یک از آن چهار مورد به اصلاح متفاوتی تعلق دارد، و تنها یکی از آن‌ها دربارهٔ VPN است. بنویسید کدام را در هر زمینه مشاهده کردید، و نفر بعدی به‌جای یک داستان شواهد را به ارث می‌برد.