نسخه پایدار Gateway API v1.4.0 که در تاریخ 6 اکتبر 2025 منتشر شد، گام مهمی در جهت شبکه‌بندی سرویس‌های مدرن، قابل‌بیان و قابل‌گسترش در Kubernetes برداشته است. 🚀 این نسخه مجموعه‌ای از قابلیت‌های جدید را معرفی می‌کند که برای تیم‌های DevOps و SRE طراحی شده تا مدیریت ترافیک و امنیت ارتباطات ساده‌تر و قابل‌اعتمادتر شود. همچنین با معرفی named rules، امکان مدیریت روشن‌تر قوانین Route فراهم می‌شود.


named rules در مدیریت قوانین Route


کلیدواژه تأکیدی این مقاله، named rules است که به بهبود ارجاع و مدیریت دقیق قوانین برای انواع Routeها در Gateway می‌پردازد.

نسخه پایدار Gateway API v1.4.0 که در تاریخ 6 اکتبر 2025 منتشر شد، گام مهمی در جهت شبکه‌بندی سرویس‌های مدرن، قابل‌بیان و قابل‌گسترش در Kubernetes برداشته است. 🚀 این نسخه مجموعه‌ای از قابلیت‌های جدید را معرفی می‌کند که برای تیم‌های DevOps و SRE طراحی شده تا مدیریت ترافیک و امنیت ارتباطات ساده‌تر و قابل‌اعتمادتر شود.

در کانال Standard (GA) سه قابلیت جدید اضافه شده است: BackendTLSPolicy برای رمزگذاری ترافیک بین Gateway و backendها، فیلد supportedFeatures در وضعیت GatewayClass برای اعلام قابلیت‌های پیاده‌سازی، و امکان نام‌گذاری قوانین (named rules) برای انواع Route. علاوه بر این، سه قابلیت تجربی هم معرفی شده‌اند: منبع Mesh برای تنظیمات سطح مش، default gateways برای کاهش پیچیدگی پیکربندی، و فیلتر externalAuth برای HTTPRoute. 🔒⚙️

BackendTLSPolicy (GEP-1897) — مشکل و راه‌حل: پیش از این هیچ API مشخصی برای رمزگذاری hop بین Gateway و پادهای backend وجود نداشت. BackendTLSPolicy یک نوع جدید است که پیکربندی TLS این ارتباط را مشخص می‌کند. این نوع به شما اجازه می‌دهد SNI، اعتبارسنجی گواهی (بر اساس hostname یا subjectAltNames) و مرجع CA مورد اعتماد را تعریف کنید تا ارتباطات داخلی نیز رمزنگاری و معتبرسازی شوند. 🧩

نکات کلیدی BackendTLSPolicy:

– hostname برای SNI استفاده می‌شود و اگر subjectAltNames مشخص نشود، باید با گواهی ارائه‌شده توسط backend مطابقت داشته باشد. اگر SANs مشخص شده باشند، hostname فقط به‌عنوان SNI استفاده می‌شود؛ اگر نیاز دارید hostname هم در اعتبارسنجی لحاظ شود، باید آن را در subjectAltNames قرار دهید.

– برای اعتبارسنجی باید یا caCertificateRefs یا wellKnownCACertificates را تعیین کنید. caCertificateRefs می‌تواند تا ۸ bundle از گواهی‌های PEM را ارجاع دهد. اگر گواهی خاصی ندارید، می‌توانید wellKnownCACertificates را برابر “System” بگذارید تا از مجموعه CA‌های پیش‌فرض پیاده‌سازی استفاده شود.

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-auth
spec:
  targetRefs:
  - kind: Service
    name: auth
    group: ""
    sectionName: "https"
  validation:
    caCertificateRefs:
    - group: "" # core API group
      kind: ConfigMap
      name: auth-cert
    subjectAltNames:
    - type: "Hostname"
      hostname: "auth.example.com"



در این مثال بالا، BackendTLSPolicy به ConfigMap به‌نام auth-cert ارجاع می‌دهد و انتظار دارد پادهای سرویس auth برای auth.example.com یک گواهی معتبر ارائه کنند. می‌توان به‌جای Hostname از نوع URI هم استفاده کرد.


apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-dev
spec:
  targetRefs:
  - kind: Service
    name: dev
    group: ""
    sectionName: "btls"
  validation:
    wellKnownCACertificates: "System"
    hostname: dev.example.com



در مثال دوم، از گواهی‌های سیستمی استفاده شده و hostname برای SNI و (در صورت نیاز) اعتبارسنجی تعیین شده است. برای جزئیات بیشتر در مورد پیکربندی TLS در Gateway API، مستندات TLS Configuration مفید است. 🔎


SupportedFeatures در GatewayClass status (GEP-2162): این قابلیت به پیاده‌سازی‌ها اجازه می‌دهد در .status/GatewayClass لیستی از قابلیت‌های پشتیبانی‌شده را اعلام کنند. این کار ابزارها و کاربران را قادر می‌سازد تا به‌صورت روشن متوجه شوند چه ویژگی‌هایی در یک GatewayClass فعال است و آزمون‌های conformance دقیقاً براساس آن اجرا شوند. این فیلد باید در همان عملیاتی که GatewayClass پذیرفته می‌شود یا قبل از قبول شدن مقداردهی شود.


apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
...
status:
  conditions:
  - lastTransitionTime: "2022-11-16T10:33:06Z"
    message: Handled by Foo controller
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  supportedFeatures:
    - HTTPRoute
    - HTTPRouteHostRewrite
    - HTTPRoutePortRedirect
    - HTTPRouteQueryParamMatching



تأثیر عملی: با وجود supportedFeatures، تست‌های Conformance به‌صورت خودکار بر اساس ویژگی‌های اعلام‌شده اجرا می‌شوند؛ نیازی به فلگ‌های دستی مثل --supported-features یا --exempt نیست. تنها استثنا Mesh است که می‌تواند از طریق Conformance Profiles یا فلگ‌های ترکیبی تا زمان خروج از حالت تجربی تست شود. ✅


Named rules برای Routes (GEP-995): اکنون هر rule در انواع xRouteRule مانند HTTPRouteRule یا GRPCRouteRule می‌تواند یک فیلد نام داشته باشد. این امکان مزایایی مثل ارجاع مستقیم وضعیت به یک rule خاص، مشاهدپذیری بهتر (logs/traces/metrics)، هدف‌گیری قوانین توسط سیاست‌ها، و ساده‌سازی فیلتر و ارجاع در ابزارها (مثل gwctl، kubectl، jq/yq) را فراهم می‌کند. این فیلد اختیاری است اما استفاده از آن قویًا پیشنهاد می‌شود؛ قالب نام تحت اعتبارسنجی قرار می‌گیرد و ممکن است پیاده‌سازی‌ها محدودیت‌هایی مثل immutable بودن را اعمال کنند.


تغییرات Experimental — externalAuth برای HTTPRoute: یکی از خواسته‌های دیرینه، توانایی اجرای authentication/authorization در سطح Gateway یا HTTPRoute بود. این نسخه یک فیلتر تجربی ExternalAuth برای HTTPRoute اضافه کرده که از API ext_authz در Envoy الهام گرفته، و امکان فراخوانی یک سرویس خارجی Auth را از طریق gRPC یا HTTP فراهم می‌کند. پروتکل HTTP اجازه ارسال اطلاعات اضافی مانند prefix path را هم می‌دهد و در هر دو حالت می‌توانید هدرهای ارسالی را کنترل کنید. 🔐


apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: require-auth
  namespace: default
spec:
  parentRefs:
    - name: your-gateway-here
  rules:
    - matches:
      - path:
          type: Prefix
          value: /admin
      filters:
        - type: ExternalAuth
          externalAuth:
            protocol: HTTP
            backendRef:
              name: auth-service
            http:
              # These headers are always sent for the HTTP protocol,
              # but are included here for illustrative purposes
              allowedHeaders:
                - Host
                - Method
                - Path
                - Content-Length
                - Authorization
      backendRefs:
        - name: admin-backend
          port: 8080



رفتار runtime: سرویس Auth وقتی درخواست را قبول کند پاسخ 200 می‌دهد و می‌تواند هدرهای اضافی برای ارسال به backend برگرداند؛ در صورت عدم اجازه، معمولاً 403 بازگردانده می‌شود. از آنجایی که هدر Authorization در روش‌های مختلف احراز هویت استفاده می‌شود، این فیلتر می‌تواند برای Basic، OAuth، JWT و روش‌های مشابه کاربردی باشد.


Mesh resource (GEP-3949) — experimental: یک منبع جدید سطح‌کلاستر به‌نام XMesh در گروه API gateway.networking.x-k8s.io معرفی شده است که برای پیکربندی تنظیمات سراسری مش و کشف قابلیت‌های پیاده‌سازی مش استفاده می‌شود. این منبع مشابه Gateway است و در آغاز بیشتر برای اهداف Conformance مورد استفاده قرار می‌گیرد، اما برنامه‌ریزی برای توسعه آن به کاربردهایی مثل Gateways خارج از کلاستر نیز وجود دارد. یک فیلد مهم آن controllerName است که مشخص می‌کند کدام پیاده‌سازی مسئول XMesh است و وضعیت منبع نشان‌دهنده قابلیت‌های پشتیبانی‌شده خواهد بود. 🧭


جمع‌بندی برای تیم‌های DevOps/SRE: این نسخه تمرکز خاصی روی امنیت ارتباطات داخلی (BackendTLSPolicy)، شفافیت قابلیت‌ها (supportedFeatures)، و مدیریت قابل‌ارجاع قواعد (named rules) دارد؛ هر سه برای عملیات پایدار و قابل‌اعتماد در محیط‌های تولید حیاتی‌اند. قابلیت‌های تجربی مثل externalAuth و XMesh چشم‌اندازی برای یکپارچگی بهتر با سرویس‌های احراز هویت و پیکربندی مش ارائه می‌دهند — اما قبل از استفاده در production، حتماً پشتیبانی پیاده‌سازی خود را بررسی کنید و آزمون‌های لازم را اجرا نمایید. اگر دوست دارید، می‌توانم راهنمایی‌ عملی برای مهاجرت سرویس‌ها به استفاده از BackendTLSPolicy یا نمونه‌های تستی برای externalAuth آماده کنم. 🙂