يشرح George Sims في مادة منشورة على مدونة CNCF بتاريخ 3 سبتمبر 2026 تجربة ترحيل خدمة مصادقة أساسية في عنقود Kubernetes من default namespace إلى مساحة أسماء مخصصة، من دون إيقاف الخدمة. كانت الخدمة، التي أطلق عليها الكاتب اسم auth-svc، تُستخدم باستمرار من عشرات الخدمات، وكانت مسؤولة عن مصادقة المستخدمين في منطقة كاملة من العنقود؛ لذلك كان توقفها سيمنع تسجيل الدخول في تلك المنطقة.
لم تكن المشكلة مجرد نقل كائن Deployment إلى مساحة أخرى. فالمستهلكون داخل العنقود كانوا يصلون إلى الخدمة عبر الاسم auth-svc.default.svc.cluster.local، بينما كان المستخدمون خارج العنقود يصلون إليها عبر Ingress منفصل. كما أن الخدمات المستهلكة كانت مملوكة لفرق مختلفة وتعمل وفق جداول إصدار متباينة، ما جعل تعديل جميع المراجع في لحظة واحدة أمراً غير عملي.
لماذا لا يكفي نقل الخدمة وتحديث المراجع؟
يشير الكاتب إلى أن خط أنابيب النشر كان يدعم نشر الخدمة في مساحة أسماء واحدة فقط، ولم يكن مصمماً لتشغيل نسختين متزامنتين. وكان تعديل منطق الخط المشترك سيؤثر في فرق أخرى، وهو ما أراد الفريق تجنبه. كذلك كانت هناك سياسة مبنية على OPA تمنع وجود قواعد Ingress متطابقة في مساحتي أسماء في الوقت نفسه، لمنع التوجيه الملتبس الناتج عن عملية ترحيل غير مكتملة.
لهذا السبب لم يُبنَ الحل على إجبار كل مستهلك على معرفة العنوان الجديد، بل على إبقاء العنوان القديم صالحاً مؤقتاً وإعادة توجيهه إلى الخدمة المنقولة.
ExternalName كعنوان إعادة توجيه
بعد نشر النسخة الفعلية من الخدمة في مساحة الأسماء الجديدة authentication، حُوّل كائن Service القديم في default إلى خدمة من النوع ExternalName. وأصبح اسمها يشير إلى auth-svc.authentication.svc.cluster.local، بحيث تستمر الخدمات التي تستخدم العنوان القديم في الوصول إلى النسخة الجديدة من دون تغيير فوري في شيفرتها أو إعادة نشرها.
يشبه الكاتب هذه الآلية بخدمة إعادة توجيه البريد: لا حاجة إلى التواصل مع كل من يملك العنوان القديم، بل يجري توجيه الطلبات إلى الموقع الجديد إلى أن تُحدّث الجهات المستهلكة عناوينها تدريجياً. لكن هذا الأسلوب يعتمد على أن المستهلكين يستخدمون اسم DNS؛ فإذا كانت بعض الأنظمة تتصل بعنوان IP ثابت أو تتجاوز DNS، فلن تكون المشكلة مماثلة، وسيتطلب الانتقال معالجة مختلفة.
قبل إيقاف النسخة القديمة، راقب الفريق المقاييس للتأكد من أن الطلبات الواردة إلى العنوان القديم تصل فعلاً إلى Deployment الجديد ولا تفشل أو تدخل في حلقة إعادة توجيه. وبعد التحقق، جرى خفض عدد النسخ القديمة إلى الصفر بدلاً من حذفها مباشرة. أتاح ذلك مسار تراجع سريعاً عبر إعادة تشغيل النسخ القديمة إذا ظهرت مشكلة، مع تأجيل الحذف النهائي إلى وقت لاحق.
معالجة تعارض Ingress
كان مسار الوصول الخارجي يحتاج إلى Ingress في مساحة الأسماء الجديدة قبل إزالة Ingress القديم. غير أن سياسة OPA كانت تمنع إنشاء القاعدتين المتطابقتين معاً. لذلك استخدم الفريق استثناءً مؤقتاً ومحدداً بدلاً من تعطيل السياسة كلياً: أضيفت وسمية إلى مساحة authentication للسماح بتجاوز فحص تكرار Ingress أثناء الترحيل، باستخدام المفتاح policy.example.com/allow-duplicate-ingress: "true".
خلال نافذة التداخل القصيرة، شُغّل Ingress الجديد إلى جانب القديم، ثم جرى التحقق من وصول الحركة إلى Deployment الجديد. بعد ذلك حُذف Ingress القديم، وتُرك الاستثناء المؤقت لينتهي بدلاً من اعتباره إعداداً دائماً.
ما الذي يتغير عملياً؟
توضح التجربة أن ترحيل خدمة حساسة لا يتطلب بالضرورة تنسيقاً متزامناً مع كل المستهلكين، إذا كان هناك حد فاصل واضح يعتمد على DNS. لكن ذلك لا يلغي الحاجة إلى اختبار مرحلي ومراقبة دقيقة وخطة تراجع. نفذ الفريق العملية أولاً في بيئة التطوير، ثم في بيئة الاختبار، وانتظر أسبوعين بعد نجاح مرحلة الاختبار قبل تنفيذها في الإنتاج.
الدرس الأوسع هو أن تراكم الخدمات داخل default namespace قد يبقى بلا أثر حتى تحتاج الخدمة إلى سياسات أو موارد مقيدة بمساحة أسماء مخصصة. عندها يصبح الدين التشغيلي مشكلة فعلية. يوفر ExternalName مساراً عملياً للخدمات التي تعتمد على DNS، لكنه ليس حلاً عاماً للأنظمة التي تستخدم عناوين ثابتة، كما أن نافذة التداخل والاستثناء الأمني يجب أن تكونا مقصودتين ومؤقتتين ومصحوبتين بقياسات واضحة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.