نظرة عامة على سلسلة K8S Envoy Gateway: بوابة دخول للمرور أكثر حداثة من Ingress

إذا سبق لك التعامل مع المرور الخارجي في Kubernetes، فالغالب أنك بدأت مع Ingress. هو يعمل، وبالنسبة لكثير من السيناريوهات فهو كافٍ فعلًا. لكن عندما تبدأ المتطلبات بالتعقّد أكثر، مثل وجود عدة listeners، وملكية مشتركة بين عدة فرق، و gRPC، و TCP، و TLS passthrough، وسياسات مرور دقيقة، فستجد نفسك حتمًا في وضع يصبح فيه "إبقاؤه حيًا عبر annotations" هو القاعدة. يبدأ الـ YAML وكأنه تعويذة، والناس الذين يصونونه يشعرون وكأنهم على وشك كسر ختم قديم.

وهنا يأتي دور Gateway API + Envoy Gateway، فهي العدة الجديدة. لا تجعل الأمور أعقد؛ بل تفصل المسؤوليات التي كانت متشابكة سابقًا بشكل نظيف، بحيث يصبح فهم مرور الدخول، وقواعد التوجيه، وإعدادات أمان TLS، وأنواع البروتوكولات، وملكية الفرق أسهل بكثير.

ما هذا بالضبط

لنقلها بوضوح في جملة واحدة:

• Envoy Proxy: مستوى البيانات الذي يستقبل المرور فعليًا ويحوّل الطلبات، ويُسمّى أيضًا Gateway Proxy
• Envoy Gateway: مستوى التحكم الذي يدير Envoy Proxy نيابةً عنك
• Gateway API: الواجهة المعيارية التي تستخدمها في Kubernetes للتصريح بقواعد المرور

فكّر فيها هكذا:

• Gateway API هو المكان الذي تكتب فيه المتطلبات
• Envoy Gateway هو المدير الذي يترجم ويفوّض
• Envoy Proxy هو الحارس الفعلي الواقف عند الباب

فائدة هذا الفصل أنك لا تحتاج إلى صياغة إعدادات Envoy منخفضة المستوى يدويًا، ولا إلى حفظ كل annotation خاص من مختلف الـ controllers. أنت تصرّح بموارد Kubernetes، و Envoy Gateway يترجمها إلى إعدادات يستطيع Envoy Proxy تنفيذها فعلًا.

Gateway مقابل Ingress: ما الفرق

الإجابة المختصرة: Ingress لم يصبح قديمًا، لكن Gateway API أنسب للأنظمة المتوسطة والكبيرة التي تحتاج إلى حوكمة أفضل.

إذا كانت متطلباتك ببساطة:

• موقع واحد أو API بسيط
• توجيه أساسي حسب path أو host
• فريق صغير

فلا يزال Ingress خيارًا مناسبًا. لكن إذا بدأت متطلباتك تشمل:

• مدخل دخول واحد يخدم عدة بروتوكولات
• عدة listeners أو domains أو certificates
• HTTP و gRPC معًا
• فصل صلاحيات ingress الخاصة بالمنصة عن صلاحيات routes الخاصة بالتطبيق
• إعدادات تُقرأ كأنها API حقيقي وليست قائمة أمنيات من annotations

فعندها ستبدو Gateway API جذابة جدًا.

لماذا لا نكتفي بـ Ingress

الهدف الرسمي لـ Gateway API هو معالجة عدة نقاط ألم شائعة عند توسّع استخدام Ingress:

• قدرة تعبيرية أفضل: التوجيه و TLS وسياسات المرور وأنواع البروتوكولات محددة بشكل أوضح
• قابلية نقل أفضل: اعتماد أقل على annotations خاصة بكل controller
• فصل أدوار أكثر طبيعية: فرق المنصة تملك ingress، وفرق التطبيقات تملك routes

على سبيل المثال، كثير من إعدادات Ingress تبدو هكذا:

metadata:
  annotations:
    some.ingress.controller/rewrite-target: /
    some.ingress.controller/auth-type: basic
    some.ingress.controller/ssl-redirect: "true"

ليس لأنها لا تعمل، لكن مع نمو المتطلبات تتحول annotations بسهولة إلى سحر أسود غامض داخل YAML. Gateway API تسحب هذه الاحتياجات إلى حقول واضحة. فتبدو كأنها "إعدادات" وليست "قائمة أمنيات".

البنية الطبقية

الصفحة الرسمية للمفاهيم تقسّم Envoy Gateway إلى ثلاث طبقات، ومن المفيد جدًا حفظها كخريطة ذهنية:

• User Configuration: موارد Gateway API و CRDs التوسعية الخاصة بـ Envoy Gateway التي تكتبها
• Envoy Gateway Controller: يقرأ هذه الموارد ويترجمها إلى إعدادات قابلة للتنفيذ
• Envoy Proxy: مستوى البيانات الذي يتعامل فعليًا مع المرور الحي

عمليًا، ستقضي معظم وقتك في تعديل "الطبقة التصريحية"، وليس في الدخول عبر SSH إلى instances البروكسي لتعديل إعدادات منخفضة المستوى. هذه هي أناقة العمل بطريقة Kubernetes-native.

ماذا ستتعلّم في هذه السلسلة

تتبع هذه السلسلة ترتيب "ابنه أولًا ثم تعمّق" مع 10 مقالات بما في ذلك هذه النظرة العامة:

1. البداية السريعة: ثبّت Envoy Gateway وشغّل أول طلب HTTP من البداية إلى النهاية
2. المفاهيم الأساسية: افهم GatewayClass و Gateway و Listener و Envoy Proxy
3. التوجيه العملي لـ HTTP: تعمّق في HTTPRoute، من host و path إلى header و filter و timeout
4. TLS والأمان: اضبط HTTPS وافهم certificateRefs و TLS termination و TLSRoute
5. أفضل الممارسات: أهم العادات قبل الذهاب إلى الإنتاج
6. ورقة غش لأنواع Route: قرّر بسرعة بين HTTPRoute و GRPCRoute و TCPRoute و TLSRoute
7. دليل تصميم Listener: أنماط تصميم multi-port و multi-hostname و multi-ingress
8. تعدد الـ Namespace وملكية الفرق: أتقن allowedRoutes و ReferenceGrant وحوكمة ingress المشتركة
9. دليل الحالة واستكشاف الأخطاء: اقرأ Accepted و ResolvedRefs و Programmed واتبع أقصر طريق للتشخيص

إذا كنت فقط تريد أن تشعر بطبيعة Envoy Gateway، فاذهب مباشرة إلى المقالة التالية. تشغيله فعليًا أفضل من حفظ كل مصطلح قبل البدء، تمامًا مثل الذهاب إلى النادي الرياضي: الحضور الفعلي أفضل من مشاهدة 30 فيديو على YouTube أولًا.

الموارد الأساسية التي ستصادفها

المبتدئون غالبًا يتعثرون لأنهم يفترضون أن Gateway API لا يحتوي إلا على Gateway و HTTPRoute. لكنه في الحقيقة عائلة كاملة من الموارد.

GatewayClass

يعرّف "أي implementation من Gateway يجب استخدامه في هذا الـ cluster." وبالنسبة إلى Envoy Gateway، فالنقطة الأساسية هي أن يوجَّه controllerName إلى الـ controller الصحيح.

Gateway

يعرّف "كيف يبدو ingress." على سبيل المثال: ما المنافذ التي ستُفتح، وما البروتوكولات التي ستُستمع إليها، وكيفية إرفاق TLS، وأي routes يُسمح بها.

Listener

Listener هو إحدى أهم الوحدات داخل Gateway. فكّر فيه على أنه فتحة مواجهة للخارج في الـ Gateway، وكل فتحة تعرّف:

• port
• protocol
• hostname
• TLS config
• allowedRoutes

كثيرون ينظرون إلى Gateway كأنه صندوق أسود، لكن ما يحدد سلوك ingress فعليًا هو كل listener داخله على حدة.

عائلة Route

• HTTPRoute: مرور HTTP/HTTPS وهو الأكثر شيوعًا
• GRPCRoute: مرور gRPC ويمكنه المطابقة على service و method
• TCPRoute: مرور TCP خام، ولا يفسّر دلالات HTTP
• TLSRoute: يوجّه بناءً على TLS SNI، وهو شائع في TLS passthrough

ما تشترك فيه كل الـ routes: هي لا "تفتح الباب"، بل تقرر "كيف يُوجَّه المرور بعد دخوله".

نموذج ذهني مختصر

احتفظ بهذه الخريطة في رأسك:

GatewayClass  # Which Gateway implementation to use in this cluster
Gateway       # Which listeners this ingress opens
Listener      # A port / protocol / hostname / TLS slot
Route         # How to distribute traffic once it enters
Service       # The backend actually serving requests in the cluster
Envoy Proxy   # The data plane that ultimately handles the traffic

مثال أدنى يبدو هكذا:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo
spec:
  parentRefs:
    - name: eg
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: backend
          port: 3000

لا تحتاج إلى حفظ كل حقل الآن. فقط افهم ما الذي يفعله:

• parentRefs: إلى أي Gateway ترتبط هذه القاعدة
• hostnames: أي domain يجب أن يطابق هذه القاعدة
• backendRefs: إلى أي Service يجب إرسال المرور

لمحة سريعة: متى تستخدم كل Route

هذه المصفوفة عملية جدًا. قبل أن تكتب YAML، اسأل نفسك:

"هل أتعامل مع مرور HTTP أم gRPC أم TCP/TLS خام؟"

الخلاصة في سطر واحد

Envoy Gateway ليس مجرد مصطلح إضافي عليك حفظه، بل هو طريقة لرفع المرور الخارجي في Kubernetes من "يؤدي الغرض" إلى "شيء يشبه نظامًا هندسيًا حقيقيًا."

💡 إذا كانت هذه أول مرة لك مع هذه المجموعة، فلا تحاول تعلّم كل CRD دفعة واحدة. ثبّته، واجعل أول طلب يمر، ثم ارجع إلى المفاهيم لاحقًا، فمعدل الاستيعاب سيكون أسرع بكثير بهذه الطريقة.

الخطوة التالية

في المقالة التالية سننتقل إلى التطبيق العملي: تثبيت Envoy Gateway في الـ cluster وتشغيل أول Gateway + HTTPRoute: 👉 البداية السريعة