Kubernetes Gateway API يصبح سائداً: حقبة Ingress تنتهي في 2026

Ingress-NGINX سُحب — إليك ما حدث فعلاً

وصل Ingress-NGINX، أكثر متحكم ingress انتشاراً في منظومة Kubernetes، إلى نهاية الصيانة الرسمية في 24 مارس 2026. ستستمر عمليات النشر الحالية في العمل وتبقى القطع الأثرية متاحة، لكن لن تكون هناك إصدارات أو إصلاحات أو تصحيحات أمان مستقبلية. وأشارت SIG-Network في Kubernetes وSecurity Response Committee إلى عدم كفاية الصيانة (1-2 قائمون على الصيانة بدوام جزئي لمشروع يُتبنى عالمياً) وديون تقنية متراكمة — بما في ذلك تعليق "snippets" الذي سمح بتكوين NGINX تعسفي وأصبح مصدراً متكرراً لمخاوف الأمان.

هذه ليست مجرد ملاحظة تنظيفية. فبالنسبة لآلاف المجموعات التي لا تزال تعتمد على ingress-nginx، فإن غياب تصحيحات الأمان المستقبلية يجعله مسؤولية امتثال بقدر ما هو تشغيلي. توصية SIG-Network لا لبس فيها: رحّل، وابدأ الآن.

Gateway API هو الخلف — وهو جاهز فعلاً

كان Gateway API مجموعة عمل SIG-Network لسنوات، لكن 2026 هو عام انتقاله من "واعد" إلى "خط أساس إنتاجي". تُسلّم المواصفة ما أراده كل فريق منصة Kubernetes جاد من Ingress وتحايل عليه بالتعليقات: بدائل توجيه تعبيرية، وCRD آمنة الأنواع مع تحقق مناسب، وفصل مناسب للأدوار بين فرق البنية التحتية والمنصة والتطبيقات، وتوجيه عبر مساحات الأسماء، ونموذج توسيع قياسي للميزات الخاصة بالموردين.

إشارات المنظومة لا تقل أهمية عن المواصفة. شحن AWS Load Balancer Controller دعم GA لـ Kubernetes Gateway API في مارس 2026، متعاملاً مع توجيه L4 (TCP/UDP عبر NLB) وL7 (HTTP/gRPC عبر ALB) من خلال مواصفة Gateway API. هذا التغيير الواحد يمنح عملاء AWS اكتشاف الشهادات التلقائي، والتوجيه عبر مساحات الأسماء، والنشر المنفصل الأدوار دون صلاحيات cluster-admin — بالضبط الميزات التي كانت فرق المنصة تبني لها صمغاً مخصصاً. وGoogle Cloud وAzure ومشاريع service mesh الرئيسية (Istio وLinkerd وCilium) كلها تشحن تطبيقات Gateway API بالتوازي.

قصة الترحيل أقل إيلاماً مما تبدو

أصدر مشروع Kubernetes Ingress2Gateway 1.0 في 20 مارس 2026 — أداة تحويل تُعيّن موارد Ingress الحالية إلى ما يعادلها من Gateway API. إنها ليست عصا سحرية؛ فالتكوينات المعقدة التي تعتمد على التعليقات لا تزال تحتاج إلى مراجعة. لكن بالنسبة للحالة الشائعة (حفنة من موارد Ingress تشير إلى خدمات عبر مسارات قائمة على المضيف والمسار)، يستغرق Ingress2Gateway دقائق بدلاً من أيام.

تشغيلياً، أكثر مسار ترحيل أماناً هو التشغيل المتوازي: انشر Gateway API جنباً إلى جنب مع Ingress الحالي، ووجّه مجموعة فرعية من حركة المرور عبر المسار الجديد، وتحقق من السلوك، وحوّل تدريجياً. دعم Kubernetes منذ فترة طويلة متحكمات متعددة على نفس المجموعة، لذلك لا يجب أن يكون التبديل حدث قطع. ستجد الفرق ذات خطوط أنابيب GitOps الناضجة أن الترحيل نظيف بشكل خاص — أنواع موارد Gateway API الصريحة (Gateway وHTTPRoute وGRPCRoute وTLSRoute) تُعيّن بشكل نظيف على ممارسات Helm وKustomize وArgoCD/Flux.

ما ينبغي لفرق المنصات فعله في 2026

ثلاث خطوات عملية. أولاً، تدقيق. قم بتشغيل الأمر الموصى به (`kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx`) عبر كل مجموعة للعثور على أماكن استخدام ingress-nginx. ستفاجأ على الأرجح؛ فـ ingress-nginx يهبط بهدوء عبر charts Helm، وافتراضات Kubernetes المُدارة، وخطوط CI/CD القديمة.

ثانياً، حدد الأولويات. ابدأ عمليات الترحيل بالمجموعات التي تتعامل مع حركة مرور خاضعة للتنظيم أو مواجهة للعملاء، حيث يخلق عدم وجود تصحيحات أمان على ingress-nginx تعرضاً حقيقياً. يمكن للمجموعات غير الإنتاجية والداخلية أن تتبع.

ثالثاً، وحّد على تطبيق Gateway API واحد لكل منصة. المواصفة قياسية لكن التطبيقات تختلف في السلوكيات المتقدمة (مرشحات التمديد، وبروتوكولات النقل، وتكامل قابلية الرصد). اختر واحداً — متحكم مزود السحابة، أو Envoy Gateway، أو تطبيق service-mesh-native — واجعله الافتراضي عبر مجموعاتك.

القوس الأوسع

يُغلق وصول Gateway API توتراً طويل الأمد في شبكات Kubernetes: كان Ingress محدوداً جداً، لذلك بنت كل منصة تعليقات وCRD مخصصة حوله، وعانت قابلية النقل. يجعل Gateway API هذا الحل الوسط غير ضروري. مع انتقال المجموعات خلال 2026 و2027، توقع أن تستعيد فرق المنصات ساعات في الأسبوع من صمغ التوجيه المخصص وتوقع أن تتراخى قفل المورد على سلوك ingress بشكل ملحوظ. هذا هو الانتقال النادر في Kubernetes الذي يترك المشغلين في وضع أفضل بعد العمل.

المصادر والقراءات الإضافية

• Ingress NGINX Retirement: What You Need to Know — Kubernetes Blog
• Announcing Ingress2Gateway 1.0 — Kubernetes Blog
• AWS Load Balancer Controller Reaches GA with Kubernetes Gateway API Support — InfoQ
• Kubernetes Ingress vs Gateway API: What to Use in 2026 — OneUptime
• The End of an Era: Transitioning Away from Ingress NGINX — Google Open Source Blog