تقاعد Ingress NGINX: لماذا تنكسر هجرتك إلى Gateway API عند الـAnnotations؟

في 24 مارس 2026 تحوّل مستودع Ingress NGINX إلى وضع «القراءة فقط». لا إصدارات جديدة، لا إصلاحات أخطاء، والأهم: لا ترقيعات أمنية بعد اليوم. المكوّن الذي كان يقف على حافة الشبكة في نحو نصف بيئات الحوسبة السحابية الأصلية أُغلق رسميًا، بعد سنوات من تحذيرات علنية بأن المشروع يعتمد على عدد ضئيل من المشرفين المتطوّعين في أوقات فراغهم.

اللافت أن قيادة Kubernetes لم تُجمّل الرسالة: البقاء على Ingress NGINX بعد التقاعد يترك نظامك ومستخدميك عرضة للهجوم، ولا يوجد بديل واحد يمكن استبداله مباشرة (drop-in). ومع ذلك، ما زال جزء كبير من الفرق يؤجّل. هذه المقالة عن السبب الحقيقي وراء التأجيل — وهو ليس الكسل — وعن الشكل الذي يجب أن تأخذه خطة الهجرة حتى لا تنكسر في الإنتاج.

ما الذي تقاعد بالضبط؟ (تصحيح التباس شائع)

هناك خلط يتكرّر في النقاشات، ويستحق التوضيح قبل أي شيء:

• واجهة Ingress نفسها لم تُهجَر. ما زال بإمكانك إنشاء موارد من نوع Ingress في أي عنقود، والواجهة قائمة.
• المتقاعد هو المتحكّم (controller) المبني على NGINX الذي يُنفّذ تلك الواجهة، أي البرنامج الذي يقرأ موارد Ingress ويحوّلها إلى إعدادات فعلية.

الفرق عملي لا لغوي: يمكنك نظريًا البقاء على واجهة Ingress والانتقال إلى متحكّم آخر يدعمها. لكن الاتجاه الذي يدفع إليه المجتمع هو Gateway API بوصفها الخليفة المعياري.

لماذا تقاعد أصلًا؟

سببان متشابكان:

1. نقص المشرفين. بنية تحتية حرجة لنصف السوق كانت تُصان في وقت الفراغ. هذا ليس نموذجًا قابلًا للاستمرار، وقد قيل ذلك علنًا لسنوات قبل القرار.
2. دين تقني أمني. خاصية «الـsnippets» التي تسمح بحقن إعدادات NGINX عشوائية تحوّلت إلى مسؤولية أمنية ثقيلة: مرونة هائلة للمستخدم، وسطح هجوم هائل للمشروع.

الخطر الحقيقي ليس تقنيًا فقط

كثيرون يقرأون الخبر باعتباره «تحديثًا مؤجَّلًا». التقييم الأدق أن التكلفة تتراكم في ثلاثة مسارات متوازية:

المسار	ما الذي يحدث بمرور الوقت
الأمني	أي ثغرة تُكتشف من اليوم فصاعدًا تبقى مفتوحة بلا إصلاح رسمي، في مكوّن يقف على حافة الشبكة مباشرة
الامتثال	برمجية منتهية الدعم في مسار البيانات تُنتج ملاحظات تلقائية في تدقيقات مثل SOC 2 وPCI-DSS وISO 27001
التشغيلي	كل يوم تأخير يعني إعدادات إضافية تُبنى فوق أساس لن ينتقل معك

الخلاصة أن التأجيل تحوّل من دين تقني إلى مخاطرة عمل لها ملف في تقرير التدقيق.

أين تنكسر الهجرة فعليًا؟

هنا الجزء الذي تُجمع عليه أدلّة الهجرة المختلفة، وهو ليس ما يتوقّعه معظم الناس.

تحويل ملفات YAML من Ingress إلى Gateway API ليس المشكلة؛ هذا جزء ميكانيكي، وله أداة رسمية. المشكلة في الـannotations: تلك السطور الصغيرة التي كتبها شخص ما قبل ثلاث سنوات لحل مشكلة محدّدة، ثم غادر الفريق.

الـannotations في عنقود قديم هي «فولكلور قابل للتنفيذ»: تعليقات جانبية كانت تُشغّل حافة الشبكة فعلًا. العمل الحقيقي في الهجرة ليس ترجمة الصيغة، بل إعادة اكتشاف ما كان كل سطر منها يفعله بالضبط.

مثال واقعي: annotation لإعادة كتابة المسار، وآخر لضبط مهلة اتصال أطول لخدمة بطيئة، وثالث يعطّل التحقّق من شهادة خلفية داخلية. الثلاثة مكتوبة بلا توثيق. الأداة ستترجم ما تعرفه، وستتجاهل الباقي بصمت — والنتيجة عطل يظهر في الإنتاج تحت حمل حقيقي، لا في بيئة الاختبار.

حدّ مهم في الأدوات

أداة الهجرة الرسمية ingress2gateway وصلت إلى الإصدار 1.0 في مارس 2026 وتدعم أكثر من 30 annotation، وهي نقطة انطلاق جيدة. لكن انتبه إلى قيد جوهري: هي تحوّل YAML ثابتًا. إن كانت موارد Ingress عندك تُولَّد وقت التشغيل — بواسطة operator، أو كود منصّة يُنشئ مسارًا لكل عميل — فالأداة لن تساعدك؛ التحويل يجب أن يحدث في المولّد نفسه.

ما الذي صار جاهزًا في Gateway API؟

الخبر الجيد أن الواجهة البديلة نضجت بالتوازي مع الموعد النهائي، ولم تعد تجربة:

• حصص مرجّحة (canary) وتحويل تدريجي للحركة بصيغة معيارية بدل annotations خاصة بكل متحكّم.
• المهل (timeouts) وإعادة كتابة المسارات كحقول رسمية في المواصفة.
• TLS passthrough ومنذ الإصدارات الأحدث دعم TCP/UDP الخام.
• الإصدار 1.5 نقل ست خصائص إلى القناة المستقرّة، منها التحقّق من شهادة العميل على مستوى البوابة، وListenerSet، والمصادقة على مستوى البوابة والمسار.

الفارق الجوهري أن ما كان «وصفة خاصة بمتحكّم واحد» صار جزءًا من المواصفة، أي قابلًا للنقل بين المنفّذين — وهذا بالضبط الدرس الذي دفعنا ثمنه في هذه الحادثة.

البدائل المطروحة

لا يوجد خيار واحد صحيح، والاختيار يعتمد على فريقك:

• Envoy Gateway وkgateway: مسار Gateway API الأصلي، والأكثر ذكرًا في أدلّة الهجرة.
• متحكّمات Ingress من جهات أخرى: خيار انتقالي لمن يريد البقاء على واجهة Ingress مؤقتًا وتقليل التغيير دفعة واحدة.
• المسار الأنضج غالبًا: انتقال على مرحلتين — أولًا متحكّم مدعوم لوقف النزيف الأمني، ثم الانتقال إلى Gateway API على مهل.

خطة عملية مختصرة

1. جرد قبل أي شيء. استخرج كل موارد Ingress وكل annotation فيها، واحصر القيم الفريدة. القائمة هذه هي حجم مشروعك الحقيقي، لا عدد الخدمات.
2. صنّف كل annotation إلى: له مقابل معياري / يحتاج إعادة تصميم / لم يعد له داعٍ. الفئة الثالثة أكبر مما تتوقّع.
3. ابدأ بأقل مسار خطورة — خدمة داخلية، لا بوابة الدفع.
4. شغّل الاثنين بالتوازي ووزّع نسبة صغيرة من الحركة قبل التحويل الكامل.
5. اختبر تحت حمل حقيقي. أعطال المهل والاتصالات الطويلة لا تظهر في طلب واحد.

أسئلة شائعة

عنقودي يعمل بلا مشاكل، هل يجب أن أهاجر فورًا؟

«يعمل» ليس المعيار هنا. المكوّن سيظل يعمل كما هو؛ ما تغيّر أن أي ثغرة تُكتشف فيه من الآن فصاعدًا لن تُصلَح، وهو يقف في مسار كل طلب يدخل إلى خدماتك. أضف إلى ذلك أن تدقيقات الامتثال ترصد البرمجيات منتهية الدعم تلقائيًا. الاستعجال مبرّر، لكن التسرّع غير مبرّر: خطة مرحلية مدروسة أفضل من هجرة ليلة واحدة.

هل Gateway API أصعب من Ingress؟

أكثر تفصيلًا، نعم — فهي تفصل الأدوار: من يملك البوابة (فريق المنصّة) ومن يملك المسارات (فرق التطبيقات). هذا التقسيم يبدو عبئًا في عنقود صغير، لكنه بالضبط ما يجعلها قابلة للتوسّع في مؤسسة. والمقابل أن معظم ما كنت تحقّقه بـannotations غير موثّقة صار حقولًا رسمية.

هل يمكنني البقاء على واجهة Ingress بمتحكّم آخر؟

نعم، وهو خيار انتقالي مشروع يقلّل حجم التغيير دفعة واحدة. لكن اعتبره محطة لا وجهة: الاستثمار المعياري طويل الأمد يتّجه إلى Gateway API، والبقاء على الواجهة الأقدم يؤجّل الهجرة ولا يلغيها.

الخلاصة

تقاعد Ingress NGINX ليس مجرد إعلان نهاية دعم؛ إنه تذكير بأن «مجاني ومفتوح المصدر» لا يعني «مصان إلى الأبد»، وأن البنية التحتية الحرجة التي لا يموّلها أحد تصبح في النهاية مسؤولية مَن يعتمد عليها.

عمليًا: ابدأ بالجرد لا بالأدوات، وتعامل مع الـannotations بوصفها المشروع الحقيقي لا بوصفها تفصيلة، واختر مسارًا مرحليًا يوقف المخاطرة الأمنية أولًا ثم يكمل التحديث المعماري. الفرق بين هجرة هادئة وحادثة إنتاج هو غالبًا سطر إعداد واحد لم يقرأه أحد منذ سنوات.