#kubernetes#envoy-gateway#gateway-api#httproute#grpcroute#tcproute#tlsroute

ورقة غش لأنواع Route في Envoy Gateway: ‏HTTPRoute أم GRPCRoute أم TCPRoute أم TLSRoute؟

5 min read

إذا كنت قرأت المقالات السابقة، فالسؤال الأرجح أنه يوقفك الآن ليس "أنا لا أفهم Gateway API"، بل:

"حسنًا، لكن أي واحد أكتب فعليًا: HTTPRoute أم GRPCRoute أم TCPRoute أم TLSRoute؟"

هذه المقالة موجودة تحديدًا لفك هذا التشابك. احتفظ بها كمرجع جيب. عندما تظهر خدمة جديدة، ارجع إليها أولًا، فهي ستنقذك من كتابة YAML بشكل أعمى ثم تلقي درس قاسٍ من condition statuses.

الخلاصة أولًا: أربعة أنواع Route، وأربعة استخدامات

نوع Route طبقة المرور ما الذي يفحصه الأنسب له غير مناسب لـ
HTTPRoute ‏L7 HTTP/HTTPS host و path و header و query و method مواقع الويب و REST APIs والمرور العام للويب TCP الخام و TLS passthrough
GRPCRoute ‏L7 gRPC hostname و service و method و header توجيه gRPC حسب service/method REST APIs العامة و TCP الخام
TCPRoute ‏L4 TCP معلومات الـ listener ومستوى الاتصال قواعد البيانات وبروتوكولات TCP المخصصة والخدمات غير HTTP السيناريوهات التي تحتاج فحص path/header
TLSRoute ‏L4/L5 TLS ‏TLS SNI hostname ‏TLS passthrough والحفاظ على التشفير من الطرف إلى الطرف الحالات التي تحتاج فحص تفاصيل HTTP بعد فك التشفير

إذا كنت تريد نسخة فائقة الاختصار:

  • تحتاج إلى فحص path أو header → HTTPRoute
  • تحتاج إلى فحص gRPC service/method → GRPCRoute
  • تريد فقط تمرير اتصالات TCP → TCPRoute
  • لا تريد TLS termination، بل توجيه SNI فقط → TLSRoute

قرار من ثلاث خطوات: توقّف عن التخمين

استخدم هذا الترتيب:

  1. هل سيقوم الـ Gateway بتحليل دلالات HTTP في هذا المرور؟
  2. إذا كانت الإجابة نعم، فهل هو HTTP/REST عادي أم gRPC؟
  3. إذا كانت الإجابة لا، فهل هو TCP خام أم TLS passthrough؟

بشكل مباشر:

  • لديك HTTP path/header/method تريد فحصه → HTTPRoute
  • لديك gRPC service/method تريد فحصه → GRPCRoute
  • لا توجد قواعد L7، فقط TCP forwarding → TCPRoute
  • تريد الحفاظ على TLS حتى الـ backend → TLSRoute

هذا القرار مهم جدًا. كثير من الناس يبدؤون تلقائيًا بكتابة HTTPRoute، ثم يكتشفون في منتصف الطريق أنهم يتعاملون مع مرور قاعدة بيانات. وعندها يدخل الـ YAML كاملًا في وضعية "ماذا أفعل أنا هنا أصلًا؟"

أمثلة YAML مصغّرة: تعرّف على كل نوع بنظرة واحدة

هذه هي أقصر النسخ وأكثرها قابلية للتعرّف من كل نوع.

HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
spec:
  parentRefs:
    - name: eg
      sectionName: http
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080

إذا رأيت path و hostnames و backendRefs، فهو هذا النوع.

GRPCRoute

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: user-grpc
spec:
  parentRefs:
    - name: eg
      sectionName: grpc
  hostnames:
    - "grpc.example.com"
  rules:
    - matches:
        - method:
            service: com.example.User
            method: Login
      backendRefs:
        - name: user-grpc-service
          port: 50051

إذا رأيت method.service و method.method، فأنت تطابق دلالات gRPC وليس HTTP العادي.

TCPRoute

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: postgres-route
spec:
  parentRefs:
    - name: eg
      sectionName: postgres
  rules:
    - backendRefs:
        - name: postgres
          port: 5432

يكاد TCPRoute لا يحتوي على أي مفاهيم path/header، لأنه أصلًا لا ينظر إليها. وهو أقرب إلى: "أي اتصالات TCP تصل إلى هذا الـ listener ارسلها إلى هذا الـ backend."

TLSRoute

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name: passthrough-route
spec:
  parentRefs:
    - name: eg
      sectionName: tls
  hostnames:
    - "db.example.com"
  rules:
    - backendRefs:
        - name: db-service
          port: 5432

غالبًا ما يُستخدم مع listener يحمل protocol: TLS. والتركيز هنا ليس فك التشفير، بل التوجيه المبني على SNI.

💡 كثيرًا ما يوجد TCPRoute و TLSRoute في القناة التجريبية عبر إصدارات Gateway API المختلفة. تحقّق من نسخة CRD المثبتة في الـ cluster قبل التطبيق.

أربعة أخطاء شائعة

1. ‏gRPC لا يتطلب بالضرورة GRPCRoute

إذا كان كل ما تريده هو مرور gRPC فقط، فقد تدعم بعض الـ implementations ذلك عبر HTTPRoute لأن gRPC يعمل فوق HTTP/2. لكن إذا أردت المطابقة بحسب gRPC service/method semantics، فـ GRPCRoute هو الخيار الأصح والأوضح.

2. ‏TLSRoute ليس "HTTPS لكن بشكل متقدم"

هذا هو الالتباس الأكثر شيوعًا.

  • HTTPS listener + HTTPRoute: الـ Gateway ينهي TLS ثم يطبق قواعد HTTP
  • TLS listener + TLSRoute: الـ Gateway لا ينهي TLS، بل يوجّه اعتمادًا على SNI فقط

أحدهما يفك التشفير ويتعامل على L7، والآخر يُبقي المرور مشفرًا وينفذ passthrough. عالمان مختلفان تمامًا.

3. ‏TCPRoute لا يستطيع رؤية Path/Header

إذا كان مطلبك هو:

  • /api يذهب إلى A
  • /admin يذهب إلى B

فهذا ليس عمل TCPRoute. لأن TCPRoute لا يفهم تفاصيل HTTP. وإجبار هذه المتطلبات عليه مجرد وصفة جاهزة للإحباط.

4. ‏parentRefs.sectionName مهم جدًا

عندما يكون لدى Gateway عدة listeners، استخدم sectionName:

parentRefs:
  - name: eg
    sectionName: https

هذا يضمن أن يرتبط الـ route بدقة بالـ listener الذي تقصده. ومن دونه قد تعتقد أنك حجزت قاعة VIP ثم تجد نفسك في الصالة الخطأ بالكامل.

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

ابدأ أولًا بتحديد ما الذي تتعامل معه: HTTP أم gRPC أم TCP أم TLS passthrough، ثم اختر نوع Route المناسب. إذا اخترت النوع الصحيح، فسيتدفق 80% من YAML لديك بشكل طبيعي. وإذا أخطأت، فستجد نفسك عالقًا في معركة مع condition statuses.

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

بعد أن تفهم أنواع الـ routes، تكون العقدة التالية الشائعة هي: عندما يملك نفس الـ Gateway عدة listeners، كيف تنظّمها من دون أن تصنع فوضى؟

المقالة التالية تغطي تصميم multi-listener: 👉 دليل تصميم Listener