AKS نمی‌تواند تصویر را از registry خصوصی پشت VPN بکشد
kubelet از طریق شبکه node تصویر را می‌کشد، نه از طریق VPN پاد. بر اساس مسیرهای node، DNS node، هر endpoint که کشیدن لمس می‌کند و سپس TLS و هویت تصمیم بگیرید.
لپ‌تاپ شما تصویر را بی‌مشکل می‌کشد، اما پاد در ImagePullBackOff می‌ماند و کسی پیشنهاد می‌کند کلاینت VPN سازمانی را به‌عنوان sidecar اجرا کنید. این کمکی نمی‌کند، چون کشیدن پیش از وجود کانتینر شما رخ می‌دهد: kubelet از container runtime روی node می‌خواهد تصویر را بیاورد و runtime از فضای نام شبکه‌ی node استفاده می‌کند. VPN داخل workload مسیری برای این راه ندارد و تصویر کمکی خودش هم باید ابتدا کشیده شود.
ترتیب عملیات لایه را تعیین می‌کند
نخست حل نام تصویر می‌آید. kubelet از طریق runtime نام registry را حل می‌کند، متصل می‌شود، احراز هویت می‌کند، لایه‌ها را دانلود می‌کند و تنها پس از آن کانتینر را اجرا می‌کند. هر کاری که پاد با VPN انجام می‌دهد بعد از این توالی رخ می‌دهد، پس تونلی که در کلاستر کار می‌کند شاهدی بر کشیدن نیست.
به همین دلیل تصویر کش‌شده دروغی چنین باورپذیر است. nodeای که هفته‌ها پیش تصویر را کشیده همچنان آن را سرو می‌کند، deployment سالم به نظر می‌رسد و خطا تنها وقتی ظاهر می‌شود که زمان‌بند یک replica را روی node جدیدتر می‌گذارد. اگر خط زمانی رویدادها شامل scale-up، تعویض node یا ارتقای pool باشد، آن‌ها را محرک بدانید نه علت.
سه شرط تعیین‌کننده‌ی ترمیم هستند
دسترسی به registry خصوصی از یک node pool مدیریت‌شده به مسیریابی، حل نام و مجموعه‌ی endpointها خلاصه می‌شود. اگر زیرشبکه‌ی node نتواند به شبکه‌ی registry مسیریابی کند، هیچ اعتباری کمک نمی‌کند. اگر مسیریابی کند اما نام registry را از مسیر DNS نود حل نکند، اتصال هرگز آغاز نمی‌شود. اگر هر دو برای endpoint مانیفست کار کنند اما برای endpoint blob که registry به آن هدایت می‌کند نه، کشیدن نیمه‌کاره شکست می‌خورد.
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
تنها VNet peering همه‌ی آرایش‌های gateway transit را خودکار به شما نمی‌دهد و مسیری که فقط در یک جهت وجود دارد مسیر کارآمدی نیست. node به مسیری پشتیبانی‌شده از طریق VPN gateway موردنظر یا دستگاهی تأییدشده نیاز دارد و سمت registry به مسیر بازگشت به زیرشبکه‌ی node.
پیش از انتخاب راه‌حل، خطا را بخوانید
از رویدادهای پاد و nodeای که روی آن فرود آمده شروع کنید، با نام‌های واقعی خودتان: kubectl describe pod app-example -n team-example و kubectl get pod app-example -n team-example -o wide. متن رویداد نام میزبان حل‌نشده را از timeout، رد گواهی را از تصویر غایب و شکست احراز مجوز را از همه‌ی آن‌ها جدا می‌کند. این چهار، چهار صاحب متفاوت دارند.
احراز هویت بیش از همه دست‌بالا گرفته می‌شود. imagePullSecret اعتبارنامه‌ی registry را به runtime می‌دهد؛ مسیر نصب نمی‌کند، resolver نود را عوض نمی‌کند و گواهی نامعتبر را معتبر نمی‌سازد. اگر رویداد می‌گوید کشیدن مجاز نبوده، دامنه‌ی هویت را ببینید. اگر می‌گوید اتصال timeout شده، اعتبارنامه بی‌ربط است.
مستندات تصویر Kubernetes مرجع رفتار کشیدن و اعتبارنامه‌ی registryهای خصوصی است و ارزش دارد پیش از تغییر شبکه یک‌بار خوانده شود، چون مرز میان احراز هویت و انتقال را روشن می‌کند.
مسیر را زیر پاد بسازید
به این ترتیب کار کنید، چون هر گام تا وقتی گام قبلی برقرار نشود بی‌معناست. نخست شبکه‌ی node را مسیریابی کنید: تأیید کنید زیرشبکه‌ی node مسیر پشتیبانی‌شده به شبکه‌ی registry دارد، مسیرهای مؤثر روی node، قواعد امنیتی دو سر و مسیر بازگشت در سمت registry را بررسی کنید.
سپس نام را از بافت node حل کنید. resolver نود همان تنظیمات DNS پاد نیست و موفقیت داخل پاد شاهدی بر runtime میزبان نیست. از DNS خصوصی مدیریت‌شده به‌جای ورودی دائمی hosts استفاده کنید؛ ورودی تا تعویض node زنده می‌ماند و سپس بی‌صدا ناپدید می‌شود.
سپس هر endpoint را اثبات کنید. registry می‌تواند به کلاینت سرویس احراز هویت جداگانه و محل ذخیره‌سازی blob جداگانه بدهد. رسیدن به endpoint مانیفست تقریباً هیچ چیز درباره‌ی لایه‌ها اثبات نمی‌کند. در پایان TLS و مجوز را کامل کنید: گواهی معتبر برای نام registry و مورد اعتماد از طریق پیکربندی پشتیبانی‌شده‌ی node، به‌همراه هویتی برای کشیدن که به خواندن آن مخزن محدود است.
روی nodeای که دستی ترمیم نکرده‌اید بررسی کنید
آزمونی که اهمیت دارد کشیدن تازه و دانلود کامل همه‌ی لایه‌ها روی یک node مناسب است، ترجیحاً nodeای که با مقیاس‌دهی یا تعویض ساخته شده. این همه‌ی poolهایی را که می‌توانند workload را جای‌گذاری کنند پوشش می‌دهد، از جمله آن‌هایی که فراموش کرده‌اید. ترمیم دستی روی یک node مدل استقرار نیست و رویداد autoscale بعدی شکاف را پیدا می‌کند.
ساخت دوباره‌ی کلاستر در VNet دیگر می‌تواند مسیر را تغییر دهد، اما آخرین راه‌حل است نه نخستین گام تشخیصی. پیش از پیشنهاد مهاجرت، شبکه‌ی node موجود را با مسیر خصوصی لازم و کنترل‌های شبکه‌ی پشتیبانی‌شده‌ی AKS مقایسه کنید و اتصال برنامه پس از راه‌اندازی را به‌عنوان بررسی جداگانه نگه دارید: گفت‌وگوی پاد با backend خود بررسی متفاوتی از دانلود تصویر توسط node است.