AKS لا يستطيع سحب الصور من سجل خاص خلف VPN
الـ kubelet يسحب عبر شبكة العقدة لا عبر VPN الخاص بالـ pod. احسم الأمر بتوجيه العقدة وDNS العقدة وكل نقطة نهاية يلمسها السحب، ثم TLS والهوية.
حاسوبك المحمول يسحب الصورة بلا مشكلة, لكن الـ pod يبقى في ImagePullBackOff، فيقترح أحدهم تشغيل عميل VPN المؤسسي كـ sidecar. لن يفيد ذلك، لأن السحب يحدث قبل وجود الحاوية: الـ kubelet يطلب من وقت تشغيل الحاويات على العقدة جلب الصورة، ووقت التشغيل يستخدم فضاء شبكة العقدة. أي VPN داخل الـ workload لا يملك مسارًا يقدمه لذلك الطريق، كما أن صورة المساعد الخاصة به تحتاج إلى سحب أولًا.
ترتيب العمليات يحدد الطبقة
يأتي تحليل اسم الصورة أولًا. الـ kubelet، عبر وقت التشغيل، يحل اسم السجل ويتصل به ويتحقق من الهوية وينزّل الطبقات، وبعد ذلك فقط يبدأ الحاوية. كل ما يفعله الـ pod بالـ VPN يحدث بعد اكتمال هذا التسلسل، ولهذا فإن نفقًا يعمل داخل العنقود ليس دليلًا على السحب.
ولهذا أيضًا تكون الصورة المخزّنة مؤقتًا كاذبة مقنعة. العقدة التي سحبت الصورة قبل أسابيع تظل تقدّمها، ويبدو النشر سليمًا، ولا يظهر العطل إلا عندما يضع المجدول نسخة على عقدة أحدث. إذا تضمّن الخط الزمني للأحداث توسيعًا أو استبدال عقدة أو ترقية مجموعة عقد، فاعتبر ذلك محفّزًا لا سببًا.
ثلاثة شروط تحدد الإصلاح
قدرة مجموعة عقد مُدارة على الوصول إلى سجل خاص تتلخص في التوجيه وتحليل الأسماء ومجموعة نقاط النهاية. إذا لم تستطع الشبكة الفرعية للعقدة التوجيه إلى شبكة السجل فلن تساعد أي بيانات اعتماد. وإذا كانت توجّه لكنها لا تحل اسم السجل عبر مسار DNS للعقدة فلن يبدأ الاتصال أبدًا. وإذا نجح الأمران لنقطة manifest لا لنقطة blob التي يعيد السجل توجيه العميل إليها، فسيفشل السحب في منتصفه.
| 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 وحده لا يمنحك تلقائيًا كل ترتيبات عبور البوابة، والمسار الموجود في اتجاه واحد ليس مسارًا يعمل. تحتاج العقدة مسارًا مدعومًا عبر بوابة VPN المقصودة أو جهاز معتمد، ويحتاج جانب السجل مسار عودة إلى الشبكة الفرعية للعقدة.
اقرأ العطل قبل اختيار الإصلاح
ابدأ بأحداث الـ pod والعقدة التي هبط عليها، وبأسمائك الحقيقية: kubectl describe pod app-example -n team-example وkubectl get pod app-example -n team-example -o wide. نص الحدث يفرّق بين اسم مضيف لم يُحلّ ومهلة، وبين رفض شهادة وصورة مفقودة، وبين فشل تفويض وكل ما سبق. لهذه الأربع أربعة مالكين مختلفين.
المصادقة هي الرافعة الأكثر مبالغة في تقديرها. imagePullSecret يمنح وقت التشغيل بيانات اعتماد السجل؛ وهو لا يثبّت مسارًا ولا يغيّر محلل العقدة ولا يجعل شهادة غير موثوقة صالحة. إذا قال الحدث إن السحب غير مصرح به فانظر في نطاق الهوية. وإذا قال إن الاتصال انتهت مهلته فبيانات الاعتماد غير ذات صلة.
وثائق صور Kubernetes هي المرجع لسلوك السحب وبيانات اعتماد السجلات الخاصة، ويستحق قراءتها مرة قبل تغيير الشبكة، لأنها توضح الحد بين المصادقة والنقل.
ابنِ المسار تحت الـ pod
اعمل بهذا الترتيب، لأن كل خطوة بلا معنى حتى تثبت السابقة. وجّه شبكة العقدة أولًا: تأكد من وجود مسار مدعوم من الشبكة الفرعية للعقدة إلى شبكة السجل، وافحص المسارات الفعلية على العقدة وقواعد الأمان على الطرفين ومسار العودة في جانب السجل.
ثم حلّ الاسم من سياق العقدة. محلل العقدة ليس هو إعداد DNS للـ pod، والنجاح داخل pod ليس دليلًا على وقت تشغيل المضيف. استخدم DNS خاصًا مُدارًا بدلًا من إدخال دائم في ملف hosts؛ فالإدخال يبقى حتى تُستبدل العقدة ثم يختفي بصمت.
ثم أثبت كل نقطة نهاية. قد يمنح السجل العميل خدمة مصادقة منفصلة وموقع تخزين blob منفصلًا. الوصول إلى نقطة manifest لا يثبت شيئًا تقريبًا عن الطبقات. وأخيرًا أكمل TLS والتفويض: شهادة صالحة لاسم السجل وموثوقة عبر إعداد عقدة مدعوم، وهوية سحب مقصورة على قراءة ذلك المستودع.
تحقق على عقدة لم تصلحها يدويًا
الاختبار الذي يهم هو سحب جديد وتنزيل كامل للطبقات على عقدة مؤهلة، ويفضل عقدة أُنشئت بالتوسيع أو الاستبدال. يغطي ذلك كل مجموعة قد تسند الـ workload، بما فيها التي نسيتها. الإصلاح اليدوي على عقدة واحدة ليس نموذج نشر، وحدث التوسيع التلقائي القادم سيكشف الثغرة.
إعادة إنشاء العنقود في VNet آخر قد تغيّر المسار، لكنه الملاذ الأخير لا خطوة التشخيص الأولى. قارن شبكة العقد الحالية بالمسار الخاص المطلوب وبعناصر التحكم المدعومة في شبكة AKS قبل اقتراح الترحيل، وأبقِ اتصال التطبيق بعد الإقلاع تحققًا منفصلًا: تحدث الـ pod مع خلفيته فحص مختلف عن تنزيل العقدة للصورة.