Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard 😊

نسخه v1.6.0 که در 30 ژوئن منتشر شد، یک گام مهم برای Gateway API است. این API که حالا نقش استاندارد برای شبکه‌های مبتنی بر نقش در Kubernetes را بازی می‌کند، پیش‌تر روی ترافیک لایه 7 مثل HTTP و TLS تمرکز داشت؛ اما با v1.6 حالا پوشش بهتری برای ترافیک خام لایه 4 داریم و مرزبندی تمیزتری بین امکانات استاندارد و تجربی ایجاد شده است.

چند نکته کلیدی به صورت خلاصه:

• TCPRoute و UDPRoute به صورت رسمی به نسخه v1 ارتقا یافته‌اند (GEP-2644 و GEP-2645) و مدل قابل حملی برای پروتکل‌های لایه 4 فراهم می‌کنند. 🔌

• منابع تجربی حالا در یک گروه API جداگانه به نام gateway.networking.x-k8s.io با پیشوند X قرار می‌گیرند تا مرز تجربه/استاندارد واضح‌تر باشد. 🧭

تا پیش از این، Gateway API یک مدل پایدار برای HTTP/TLS ارائه می‌کرد، اما ترافیک‌هایی که از پروتکل‌های خام TCP یا UDP استفاده می‌کردند — مثل دیتابیس‌ها، DNS، VoIP، بازی‌ها یا تله‌متری IoT — راه قابل حمل و استانداردی برای وصل شدن به Gateway نداشتند. کاربران معمولاً مجبور به استفاده از Service ساده یا CRDهای اختصاصی پیاده‌سازی می‌شدند که قابل جابجایی بین کنترل‌کننده‌ها نبودند. TCPRoute و UDPRoute این شکاف را پر می‌کنند: این منابع ترافیک را بر اساس پروتکل و پورت مستقیم به backend هدایت می‌کنند، بدون نیاز به آگاهی لایه 7. 🎯

مثال ساده‌ای از تعریف یک Gateway با listener که اجازهٔ اتصال TCPRoute را می‌دهد:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: foo
      protocol: TCP
      port: 12345
      allowRoutes:
        kinds:
          - kind: TCPRoute

نمونه‌ای از TCPRoute که به آن listener متصل می‌شود و ترافیک را به باک‌اند my-foo-service روی پورت 6000 هدایت می‌کند:

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: tcp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

معادل UDP هم مشابه است؛ یک UDPRoute می‌تواند یک listener با protocol: UDP را target کند و ترافیک UDP را به backend مورد نظر بفرستد:

apiVersion: gateway.networking.k8s.io/v1
kind: UDPRoute
metadata:
  name: udp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

معرفی XBackend: در v1.6 یک منبع جدید تجربی به نام XBackend اضافه شده که نقش یک decorator عمومی برای Service (و دیگر انواع backends) را دارد. Service ابزاری قدرتمند و منعطف است، اما بعضی موارد لبه و پیچیدگی‌ها را به همراه می‌آورد که بهتر است Gateway API خودش بتواند به صورت بومی آن‌ها را هدف بگیرد. XBackend راهی برای هدف‌گیری برنامه پشتیبان با انعطاف بیشتر فراهم می‌کند — مثلاً پشتیبانی از ExternalHostname که برای سناریوهای egress یا وصل شدن به سرویس‌های خارجی مثل APIهای ابری مفید است. ⚙️

مثالی از استفاده از XBackend برای اشاره به یک سرویس خارجی و ارجاع به آن از یک HTTPRoute:

# نمونه XBackend از گروه تجربی
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackend
metadata:
  name: ai-provider-api
  namespace: ai-apps
spec:
  type: ExternalHostname
  externalHostname:
    hostname: hostname.ai.example
---
# یک HTTPRoute که از XBackend به عنوان backend استفاده می‌کند
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: use-ai-backend
spec:
  rules:
    - backendRefs:
        - name: ai-provider-api
          group: gateway.networking.x-k8s.io
          kind: XBackend

نکات مهم در مورد XBackend: این منبع فعلاً تجربی است و در گروه gateway.networking.x-k8s.io قرار دارد. وقتی منابع تجربی به Standard ارتقا یابند، نام گروه تغییر کرده و پیشوند X حذف می‌شود (مثلاً XMesh به Mesh تبدیل می‌شود). این جداسازی، مرز تجربه و استاندارد را در سطح گروه API مشخص می‌کند تا صرفاً به رشتهٔ نسخه تکی متکی نباشیم.

این تغییرات یک نقطه عطف در این است که Gateway API می‌تواند به عنوان یک API یکپارچه برای ورودی و شبکه مشبک (ingress & mesh) برای بارهای کاری Kubernetes عمل کند — در هر دو سطح لایه 4 و لایه 7. 🌐

آماده امتحان؟ می‌توانید از امروز با نصب کنترلر Gateway مورد علاقهٔ خود و فعال‌سازی CRDها شروع کنید. Gateway API یک مجموعهٔ تست انطباق (conformance) قوی دارد تا رفتارش بین پیاده‌سازی‌ها قابل حمل و سازگار باشد. چند پیاده‌سازی شناخته‌شده که با v1.6 هماهنگ شده‌اند شامل GKE Gateway، NGINX Gateway و Traefik Proxy هستند؛ البته فهرست پیاده‌سازی‌ها دائماً در حال رشد است.

اگر در نقش DevOps/SRE هستید، این به شما امکان می‌دهد تا مدیریت ترافیک لایه 4 را با همان رویکرد نقش‌محور که برای HTTP/TLS در Gateway API دارید، وارد جریان کار خود کنید — کنترلِ واضح‌تر بر listenerها، مسیرها و backends و قابلیت انتقال‌پذیری بین کنترل‌کننده‌ها. 🚀

برای مشارکت یا دنبال‌کردن پیشرفت‌ها می‌توانید در بحث‌های SIG Network مشارکت کنید، یا مشکلات و پیشنهادات را در مخزن مرتبط مطرح کنید. مشارکت جامعه نقش کلیدی در تکامل Gateway API داشته و دارد — از همه مشارکت‌ها استقبال می‌شود. 🙏