آشنایی با Gateway API در کوبرنتیز؛ بررسی معماری و مقایسه با Ingress

Gateway API در کوبرنتیز به‌عنوان نسل جدید مدیریت ترافیک شبکه معرفی شد تا محدودیت‌های مدل Ingress را در محیط‌های cloud-native برطرف کند؛ مدلی که سال‌ها برای مدیریت ترافیک در کوبرنتیز استفاده می‌شد. Gateway API در کوبرنتیز فقط یک ارتقاء در قابلیت‌ها نیست، بلکه تغییری در مدل طراحی، تفکیک مسئولیت‌ها و نحوه مدیریت ترافیک در سطح کلاستر محسوب می‌شود. در این مطلب بررسی می‌کنیم که Gateway API چیست، چه تفاوتی با Ingress دارد و با چه مزایایی و چالش‌هایی همراه است.

Gateway API چیست؟

Gateway API در کوبرنتیز مجموعه‌ای از resourceها و APIهای استاندارد برای مدیریت ترافیک شبکه در کوبرنتیز است. این API با هدف رفع محدودیت‌های Ingress طراحی شد و امکان مدیریت پیشرفته‌تر ترافیک HTTP ،HTTPS ،TCP ،TLS و gRPC را فراهم می‌کند.

Gateway API در کوبرنتیز از چند مؤلفه اصلی تشکیل شده است که هرکدام نقش مشخصی در مدیریت ترافیک دارند:

• GatewayClass مشخص می‌کند که کدام کنترلر مسئول پیاده‌سازی Gateway است.
• Gateway نقطه ورود ترافیک به کلاستر را تعریف می‌کند.
• Routeها مانند HTTPRoute قوانین مسیریابی درخواست‌ها را مشخص می‌کنند.

یکی از ویژگی‌های اصلی Gateway API در کوبرنتیز مدل نقش‌محور آن است. در این مدل، مسئولیت‌ها بین نقش‌های مختلف مانند تیم زیرساخت، امنیت و توسعه تفکیک می‌شود تا هر تیم بتواند بخش مربوط به خود را مستقل مدیریت کند.

در Gateway API کوبرنتیز، Resorceهای مختلف از یکدیگر جدا شده‌اند و هر بخش مسئولیت مشخصی دارد. این ساختار باعث می‌شود مدیریت networking در کوبرنتیز انعطاف‌پذیرتر و قابل کنترل‌تر باشد.

امروزه پروژه‌هایی مانند Envoy Gateway ،Istio ،Kong و NGINX Gateway Fabric از Gateway API پشتیبانی می‌کنند و این API به یکی از بخش‌های مهم اکوسیستم networking در کوبرنتیز تبدیل شده است.

چرا Ingress دیگر کافی نیست؟

Ingress سال‌ها روش استاندارد مدیریت ترافیک HTTP و HTTPS در کوبرنتیز بود، اما با پیچیده‌تر شدن معماری‌های cloud-native دیگر پاسخگوی نیازهای جدید نبود.

Ingress در ابتدا برای سناریوهای ساده routing طراحی شده بود و بسیاری از قابلیت‌های پیشرفته networking را به‌صورت استاندارد ارائه نمی‌داد. به همین دلیل، Ingress Controllerها برای افزودن قابلیت‌های بیشتر به annotationهای اختصاصی وابسته شدند. annotationها نوعی متادیتا هستند که به منابع کوبرنتیز اضافه می‌شوند تا تنظیمات یا رفتارهای اضافی را برای کنترلرها تعریف کنند.

یکی دیگر از محدودیت‌های Ingress، مدل مدیریت و مالکیت آن بود. در بسیاری از سازمان‌ها، تیم‌های مختلف مسئول بخش‌های متفاوت شبکه هستند، اما Ingress جداسازی مشخصی برای این مسئولیت‌ها ارائه نمی‌کرد و مدیریت سطح دسترسی‌ها در محیط‌هایی که چند تیم روی یک کلاستر کار می‌کردند دشوارتر می‌شد.

مجموعه این محدودیت‌ها باعث شد Ingress به‌مرور برای بسیاری از سناریوهای جدید cloud-native کافی نباشد؛ مخصوصاً در معماری‌های بزرگ، محیط‌های چندتیمی و زیرساخت‌هایی که به مدیریت پیشرفته‌تر ترافیک نیاز داشتند. به همین دلیل جامعه توسعه‌دهندگان کوبرنتیز به‌سمت طراحی API جدیدی حرکت کرد که بتواند مدیریت ترافیک شبکه را انعطاف‌پذیرتر، استانداردتر و قابل گسترش‌تر کند. نتیجه این تلاش، Gateway API بود.

تفاوت Ingress و Gateway API

تفاوت اصلی Ingress و Gateway API در کوبرنتیز در مدل طراحی و سطح انتزاع (abstraction level) آن‌ها است. Ingress یک API ساده و متمرکز برای مدیریت ترافیک HTTP/HTTPS است، در حالی که Gateway API یک مدل نقش‌محور و چندلایه برای مدیریت پیشرفته‌تر ترافیک در کوبرنتیز ارائه می‌دهد.

در Ingress، تمام منطق مسیریابی در یک resource واحد تعریف می‌شود که باعث سادگی، اما محدودیت در سناریوهای پیچیده می‌شود. در مقابل، Gateway API این مسئولیت‌ها را بین چند resource مستقل تقسیم می‌کند تا مدیریت شبکه قابل توسعه‌تر و منعطف‌تر شود.

از نظر مدل مدیریت، تفاوت مهم دیگر در نحوه تقسیم مسئولیت‌ها بین تیم‌ها است. در Ingress معمولاً یک تیم باید هم زیرساخت و هم قوانین routing را مدیریت کند. اما در Gateway API این مسئولیت‌ها قابل تفکیک هستند و هر تیم می‌تواند بخش مشخصی از شبکه را مدیریت کند.

از نظر قابلیت‌ها نیز تفاوت قابل توجهی وجود دارد. Ingress عمدتاً برای HTTP و HTTPS طراحی شده است، در حالی که Gateway API از پروتکل‌های بیشتری از جمله موارد زیر پشتیبانی می‌کند:

• HTTP و HTTPS
• TCP
• TLS
• gRPC

همچنین Gateway API در کوبرنتیز امکان تعریف قابلیت‌های پیشرفته‌تری را به‌صورت استاندارد و قابل توسعه فراهم می‌کند؛ از جمله مسیریابی مبتنی بر هدر، تقسیم ترافیک بین سرویس‌ها و مسیریابی بین چند فضای نام کوبرنتیز مختلف (Namespaceها). در حالی که در Ingress این نوع قابلیت‌ها معمولاً وابسته به پیاده‌سازی هر کنترلر کوبرنتیز هستند و استاندارد واحدی برای آن‌ها وجود ندارد.

در نتیجه، تفاوت اصلی این دو مدل در این است که Ingress یک راهکار ساده و محدود برای سناریوهای پایه است، در حالی که Gateway API یک چارچوب استاندارد و قابل توسعه برای مدیریت پیچیده‌تر ترافیک در کوبرنتیز محسوب می‌شود.

معماری و اجزای اصلی Gateway API

Gateway API در کوبرنتیز بر پایه یک مدل معماری نقش‌محور طراحی شده است که در آن مسئولیت مدیریت ترافیک بین چند resource مستقل تقسیم می‌شود. این طراحی برای کاهش پیچیدگی Ingress و ایجاد ساختاری قابل توسعه در سناریوهای پیشرفته شبکه شکل گرفته است.

در این معماری، به‌جای اینکه تمام منطق routing و پیکربندی شبکه در یک resource واحد متمرکز شود، اجزای مختلفی تعریف شده‌اند که هرکدام نقش مشخصی دارند و در کنار هم سیستم مدیریت ترافیک را تشکیل می‌دهند. در معماری Gateway API، سه مؤلفه اصلی نقش کلیدی دارند.

GatewayClass

GatewayClass مشخص می‌کند که کدام کنترلر مسئول پیاده‌سازی و مدیریت Gatewayها در کلاستر است. این بخش در واقع نقش template یا کلاس رفتاری برای Gatewayها را دارد و تعیین می‌کند که کل سیستم از چه نوع پیاده‌سازی networking استفاده کند.

Gateway

Gateway نقطه ورود ترافیک به کلاستر است. این resource مشخص می‌کند که ترافیک از چه مسیرهایی وارد می‌شود و چه listenerهایی برای دریافت درخواست‌ها فعال هستند. به عبارت دیگر Gateway نقطه اتصال بین دنیای بیرونی و سرویس‌های داخل کوبرنتیز است.

Routeها

Routeها مسئول تعریف قوانین مسیریابی در Gateway API هستند. این resourceها مشخص می‌کنند درخواست‌ها بر اساس چه معیارهایی به سرویس‌های داخلی هدایت شوند. این معیارها می‌توانند شامل مسیر URL، هدرها یا سایر ویژگی‌های درخواست باشند.

HTTPRoute یکی از مهم‌ترین انواع Route است که امکان مسیریابی بر اساس ویژگی‌های HTTP مانند مسیر درخواست، هدرها و سایر مشخصه‌ها را فراهم می‌کند. علاوه بر آن، Routeهای دیگری نیز برای پروتکل‌هایی مانند TCP ،TLS و gRPC وجود دارند.

یکی از نکات مهم در معماری Gateway API در کوبرنتیز این است که این سه بخش به‌صورت مستقل از هم طراحی شده‌اند. این جداسازی باعث می‌شود مدیریت شبکه در کوبرنتیز انعطاف‌پذیرتر شود و امکان تقسیم مسئولیت بین تیم‌های مختلف فراهم شود. در این مدل، تیم زیرساخت معمولاً GatewayClass و Gateway را مدیریت می‌کند، در حالی که تیم‌های توسعه می‌توانند Routeهای مربوط به سرویس‌های خود را به‌صورت مستقل تعریف و کنترل کنند.

یک مثال ساده

مثال زیر یک Gateway ساده را نشان می‌دهد که ترافیک HTTP را روی پورت ۸۰ دریافت می‌کند:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80

در این تعریف:

• Gateway به یک GatewayClass متصل است که تعیین می‌کند کدام کنترلر آن را مدیریت کند
• یک نقطه ورود ترافیک روی پورت ۸۰ ایجاد شده است
• پروتکل HTTP برای دریافت درخواست‌ها مشخص شده است

در مثال زیر برای تشریح HTTPRoute (تعریف قوانین مسیریابی)، مشخص شده که درخواست‌ها باید به کدام سرویس داخلی ارسال شوند:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - name: example-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: example-service
          port: 8080

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - name: example-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: example-service
          port: 8080

در اینجا:

• این Route به Gateway قبلی متصل شده است
• تمام درخواست‌های شروع شده با مسیر / تطبیق داده می‌شوند.
• ترافیک به سرویس example-service روی پورت ۸۰۸۰ هدایت می‌شود

مزایای Gateway API

Gateway API در کوبرنتیز در سناریوهای واقعی چند مزیت کلیدی نسبت به مدل Ingress دارد:

تفکیک مسئولیت‌ها در معماری شبکه

در Gateway API، وظایف مربوط به زیرساخت، نقطه ورود ترافیک و قوانین مسیریابی از هم جدا شده‌اند و هر بخش می‌تواند به‌صورت مستقل مدیریت شود.

کاهش وابستگی به annotationهای اختصاصی

بسیاری از قابلیت‌هایی که در Ingress وابسته به پیاده‌سازی کنترلر بودند، در Gateway API به‌صورت استاندارد و قابل پیش‌بینی تعریف می‌شوند.

مقیاس‌پذیری بهتر در معماری‌های بزرگ
در محیط‌های مبتنی بر مایکروسرویس، مدیریت تعداد زیاد مسیرها و سرویس‌ها ساده‌تر می‌شود و پیچیدگی پیکربندی‌ها کاهش پیدا می‌کند.

یکپارچگی بیشتر بین پیاده‌سازی‌های مختلف
رفتار سیستم در کنترلرهای مختلف قابل پیش‌بینی‌تر است و وابستگی به هر پیاده‌سازی خاص کاهش پیدا می‌کند.

پشتیبانی گسترده‌تر از پروتکل‌ها
Gateway API در کوبرنتیز علاوه بر HTTP و HTTPS، از پروتکل‌هایی مانند TCP ،TLS و gRPC به‌صورت استاندارد پشتیبانی می‌کند.

چالش‌ها و محدودیت‌های Gateway API

با وجود مزایای معماری Gateway API، این مدل هنوز بدون چالش نیست و در بسیاری از سناریوهای عملی محدودیت‌هایی دارد:

ناهمگونی در پیاده‌سازی کنترلرها
همه کنترلرها هنوز سطح یکسانی از پشتیبانی از Gateway API ندارند و برخی قابلیت‌ها ممکن است در همه پیاده‌سازی‌ها در دسترس نباشند.

پیچیدگی بیشتر نسبت به Ingress
مدل Gateway API در کوبرنتیز به‌جای یک resource واحد، از چند resource جدا استفاده می‌کند. این موضوع اگرچه از نظر معماری مزیت است، اما در عمل باعث افزایش پیچیدگی مفهومی و یادگیری می‌شود.

پیچیدگی مهاجرت از Ingress
بسیاری از تنظیمات Ingress به‌خصوص مواردی که با annotationهای اختصاصی تعریف شده‌اند، معادل مستقیم در Gateway API ندارند و باید مجدد طراحی شوند.

بلوغ ناقص در برخی سناریوها
با وجود استاندارد بودن API، هنوز برخی ویژگی‌ها در سطح اکوسیستم به‌صورت کامل و یکپارچه در همه پروژه‌ها پیاده‌سازی نشده‌اند.

هم‌زیستی با Ingress در بسیاری از محیط‌ها
در عمل، بسیاری از سازمان‌ها هنوز به‌طور کامل به Gateway API مهاجرت نکرده‌اند و استفاده هم‌زمان از Ingress و Gateway API در یک کلاستر رایج است.

مهاجرت از Ingress به Gateway API در کوبرنتیز

مهاجرت از Ingress به Gateway API یک تغییر تدریجی در معماری شبکه است، نه یک جایگزینی ساده. چون این دو مدل ساختار متفاوتی دارند، مهاجرت معمولاً نیازمند بازطراحی بخشی از منابع شبکه در کلاستر است.

در مدل Ingress، تمام تنظیمات routing در یک resource واحد تعریف می‌شود. اما در Gateway API این مسئولیت بین چند resource جدا مانند GatewayClass ،Gateway و Routeها تقسیم شده است. به همین دلیل، اولین گام در مهاجرت، درک و بازنویسی این تفکیک مسئولیت‌ها است.

در فرایند مهاجرت، معمولاً ابتدا یک Gateway جدید در کنار Ingressهای موجود ایجاد می‌شود. این Gateway به یک کنترلر سازگار متصل می‌شود و به‌صورت تدریجی بخشی از ترافیک را از Ingress به سمت Routeهای جدید هدایت می‌کند.

در این مرحله، یکی از چالش‌های اصلی، بازنویسی تنظیمات Ingress است. بسیاری از قابلیت‌هایی که قبلاً از طریق annotationها تعریف می‌شدند، باید در قالب resourceهای استاندارد Gateway API بازتعریف شوند. این موضوع نیازمند بررسی دقیق رفتار Ingressهای موجود و تبدیل آن‌ها به معادل‌های Gateway API است.

همچنین در مهاجرت باید توجه شود که همه قابلیت‌های Ingress ممکن است معادل مستقیم در Gateway API نداشته باشند یا پیاده‌سازی آن‌ها وابسته به کنترلر انتخاب‌شده باشد. بنابراین انتخاب کنترلر سازگار با نیازهای پروژه نقش مهمی در موفقیت مهاجرت دارد.

در نهایت، مهاجرت معمولاً به‌صورت مرحله‌ای انجام می‌شود؛ به‌طوری که Ingress و Gateway API برای مدتی در کنار هم در کلاستر وجود دارند تا انتقال ترافیک بدون اختلال انجام شود.

سخن پایانی

Gateway API یک مسیر جدید در تکامل networking در کوبرنتیز است که برای رفع محدودیت‌های مدل Ingress طراحی شده است. Ingress همچنان در بسیاری از محیط‌ها استفاده می‌شود، اما برای نیازهای جدید و سناریوهای پیچیده‌تر، تمرکز اصلی توسعه در اکوسیستم کوبرنتیز به سمت Gateway API حرکت کرده است. در نتیجه، Gateway API در کوبرنتیز بیشتر به‌عنوان مسیر پیشنهادی آینده برای طراحی شبکه در کوبرنتیز دیده می‌شود، در حالی که Ingress هنوز در بسیاری از سیستم‌های موجود نقش کاربردی خود را حفظ کرده است.