Kubernetes Gateway API

 (romaglushko.com)
4 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • नवंबर 2025 में Kubernetes ने घोषणा की कि पूरे क्लस्टरों के 40% से अधिक में इस्तेमाल होने वाले NGINX Ingress Controller को मार्च 2026 में deprecated किया जाएगा; यह फैसला Gateway API को Ingress API के उत्तराधिकारी के रूप में स्थापित करने वाला एक अहम मोड़ बना
  • Gateway API inbound ट्रैफ़िक मैनेजमेंट के लिए जरूरी व्यापक क्षमताओं को कवर करता है, Ingress API की तुलना में अधिक expressive है और टीमों के बीच separation of concerns को अधिक स्पष्ट बनाता है
  • Ingress API की सीमाओं में संकीर्ण API दायरा, कठोर extensibility, policy enforcement की कमी, अस्पष्ट ownership boundaries, और सुरक्षित cross-namespace सपोर्ट का अभाव शामिल है
  • Gateway API GatewayClass, Gateway, Listener, Route जैसे अलग-अलग resource model के साथ-साथ ReferenceGrant और Policy attachment जैसे security और extensibility mechanisms प्रदान करता है
  • NGINX Ingress Controller में बार-बार सामने आए CVE इसकी संरचनात्मक खामियों से उत्पन्न होते हैं, और लंबी अवधि में Gateway API की ओर migration ही इसका एकमात्र मूलभूत समाधान है

Ingress का विकास क्रम

  • 2014 के शुरुआती Kubernetes में Service resource ही applications को expose करने का मूल तरीका था
    • ClusterIP केवल क्लस्टर के अंदर का DNS नाम देता था, बाहरी access संभव नहीं था
    • NodePort सभी nodes पर एक specific port खोलकर बाहरी ट्रैफ़िक स्वीकार करता था; node IP सार्वजनिक होने पर बाहरी exposure संभव होता था
    • LoadBalancer public IP वाले बाहरी load balancer को provision करके ट्रैफ़िक अग्रेषित करता था
    • ExternalName CNAME record के जरिए बाहरी service के लिए क्लस्टर के भीतर alias उपलब्ध कराता था
  • इन चारों में से सीधे बाहरी exposure केवल NodePort और LoadBalancer से संभव था
    • NodePort एक बुनियादी primitive था, लेकिन बहुत low-level; nodes के बीच बाहरी load balancing और path-based routing को सीधे implement करना पड़ता था
  • LoadBalancer, NodePort के ऊपर L4 load balancer (TCP/UDP) जोड़कर automatic provisioning देता था, जिसे Cloud Controller Manager संभालता था
    • लेकिन कई public IP और load balancer मैनेज करने पड़ते थे, जिससे लागत बढ़ती थी और ट्रैफ़िक के लिए कोई central management point नहीं होता था
  • हर Service के लिए अलग load balancer रखने के बजाय, एक single LoadBalancer Service सभी ट्रैफ़िक प्राप्त करे, उसे NGINX जैसे reverse proxy Deployment तक भेजे, और फिर path व hostname के आधार पर routing करे—यही संरचना Ingress API और Ingress Controller की शुरुआत बनी

Ingress Controller

  • 2015 में Kubernetes टीम ने बाहरी HTTP(S) ट्रैफ़िक को अंदरूनी Service तक route करने के नियम परिभाषित करने के तरीके के रूप में Ingress API पेश किया

  • Ingress API में IngressClass और Ingress दो resources होते हैं; यह केवल common interface परिभाषित करता है, जबकि वास्तविक व्यवहार के लिए Ingress Controller की स्थापना आवश्यक होती है

  • IngressClass

    • यह एक cluster-wide resource है जो तय करता है कि कौन-सा controller किसी विशेष Ingress resource set को प्रोसेस करेगा
    • इससे एक ही क्लस्टर में कई Ingress Controller को समानांतर रूप से चलाना संभव होता है; हर controller केवल अपनी IngressClass द्वारा चुने गए resources को ही watch करता है
    • controller को IngressClass पढ़ने और उपयोग करने के लिए ClusterRole permissions चाहिए होती हैं

  • Ingress resource

    • Ingress, Ingress API का मुख्य resource है जो कई तत्वों को जोड़ता है
      • path-based (exact/prefix) और host-based matching rules के जरिए अंदरूनी Service routing परिभाषित करता है
      • inbound ट्रैफ़िक के लिए TLS settings परिभाषित करता है
    • resource बनते ही Ingress Controller इसे detect करके अपनी configuration अपडेट करता है और routing rules लागू करता है

  • Ingress API की समस्याएँ

    • वास्तविक production environment में ये समस्याएँ सामने आईं: बहुत सीमित API scope, कठोर extensibility, policy enforcement का अभाव, अस्पष्ट ownership boundaries, और सुरक्षित cross-namespace सपोर्ट की कमी

  • बहुत सीमित API scope

    • Ingress API साधारण (simple) कम और अत्यधिक सरलीकृत (simplistic) ज्यादा है; यह ingress ट्रैफ़िक configuration के लिए केवल न्यूनतम चीज़ों को संभालता है
    • NGINX में आमतौर पर चाही जाने वाली ये क्षमताएँ सीधे समर्थित नहीं हैं
      • request timeout, CORS, max body size limit, sticky cookie session, canary traffic splitting, rate limiting, header·query·cookie आधारित routing, header modification
    • इसके कारण अतिरिक्त configuration देने का मानक तरीका custom annotation बन गया; Traefik जैसे कुछ controllers अपने खुद के CRD इस्तेमाल करते हैं
    • जब कई Ingress Controller एक साथ उपयोग किए जाते हैं, तो unified configuration method न होने के कारण हर controller के annotation अलग होते हैं, जिससे portability घटती है
    • Ingress केवल HTTP(S) routing को संभालता है, जबकि gRPC (L7)·TCP·UDP (L4) को implementation के अनुसार custom annotation से संभाला जाता है

  • कठोर extensibility

    • custom annotation केवल string key-value pair होते हैं, इसलिए complex configuration को string के रूप में serialize करना पड़ता है और expressiveness की कमी होती है

  • policy enforcement का अभाव

    • application teams Ingress resource में मनचाहे annotation जोड़ सकती हैं; उदाहरण के लिए platform team जिस rate limiting को सभी routes पर अपेक्षित मानती है, उसे भी disable किया जा सकता है
    • Ingress API में global behavior enforce करने का कोई built-in mechanism नहीं है, इसलिए Kyverno या OPA Gatekeeper जैसे बाहरी policy engine पर निर्भर रहना पड़ता है

  • अस्पष्ट ownership boundaries

    • Ingress resource कई तरह की settings को एक साथ मिला देता है
      • routing rules आमतौर पर application team की ownership में होते हैं
      • hostname और port settings, DNS, load balancer और networking संभालने वाली platform team की ownership में होते हैं
      • TLS settings, certificate provisioning संभालने वाली platform team की ownership में होते हैं
      • custom annotation दोनों में से किसी भी team की ownership में हो सकते हैं
    • umbrella Helm chart से deploy की गई complex systems में Ingress आमतौर पर application subchart में होता है, लेकिन platform team को भी उसके कुछ हिस्से update और enforce करने पड़ते हैं
    • single responsibility principle के दृष्टिकोण से Ingress में बदलाव के एक से अधिक कारण होते हैं, इसलिए इसे अधिक केंद्रित resources में विभाजित करना बेहतर है
    विज्ञापन

  • सुरक्षित cross-namespace सपोर्ट का अभाव

    • Ingress resource अपने namespace के बाहर की Service या TLS secret को refer नहीं कर सकता; rules[].backend.service में namespace specify करने के लिए field तक नहीं है
    • workaround के रूप में उसी namespace में ExternalName Service बनाकर target Service के क्लस्टर-आधारित DNS नाम की ओर point किया जा सकता है
    • लेकिन यह तरीका सीधे confused deputy attack जैसी समस्या समाहित करता है

Gateway API

  • Gateway API, Ingress API का अगला-gen version है, जो इन तरीकों से इसकी सीमाएँ दूर करता है
    • यह inbound ट्रैफ़िक मैनेजमेंट के लिए कहीं अधिक व्यापक capabilities को कवर करता है और expressiveness बढ़ाता है
    • यह सामान्य resource ownership patterns को दर्शाते हुए टीमों के बीच separation of concerns को स्पष्ट करता है
    • इसमें policies नाम का defined extensibility mechanism और flexible cross-namespace object references शामिल हैं

GatewayClass

  • IngressClass की तरह यह भी किसी विशेष Gateway controller deployment के स्वामित्व वाले Gateway के set को परिभाषित करता है; अर्थ और संरचना में यह लगभग IngressClass जैसा ही है
  • यह implementation-specific अतिरिक्त Gateway configuration रखने वाले custom resource को refer कर सकता है
    • इसमें Gateway proxy को expose करने का तरीका, bootstrap और runtime defaults, deployment rollout और scaling method, तथा अन्य controller-specific options शामिल हो सकते हैं

Gateway

  • Gateway resource dynamically provision किए गए edge gateway को दर्शाता है, जो inbound ट्रैफ़िक प्राप्त कर उसे उपयुक्त backend service तक route करने वाला infrastructure abstraction है

    • Ingress डिजाइन में यह भूमिका Ingress Controller निभाता था, इसलिए इसे statically provision किए गए Gateway instance के रूप में देखा जा सकता है

  • हर Gateway, GatewayClass को refer करके तय करता है कि कौन-सा controller इसे provision और manage करेगा; इसका सबसे महत्वपूर्ण component listener की सूची है

  • Listeners

    • Gateway इनबाउंड ट्रैफ़िक को कैसे स्वीकार करता है, इसे परिभाषित करता है; हर listener एक अलग entry point होता है जिसे port·protocol·hostname के संयोजन से वर्णित किया जाता है
    • TLS termination कॉन्फ़िगर किया जा सकता है; Ingress दुनिया में यह जानकारी Ingress resource के भीतर मौजूद होती थी
    • यह सबसे सूक्ष्म इकाई है जिस पर कोई Route Gateway से attach हो सकता है

  • ListenerSet

    • listener entry point configuration को केंद्रीकृत करने के लिए अच्छा है, लेकिन जब सैकड़ों की आवश्यकता हो तो यह उपयुक्त नहीं रहता
    • मुख्य उदाहरण: एक single wildcard TLS certificate के बजाय service-विशिष्ट hostname·TLS settings वाले HTTPS listener, जिससे microservices की संख्या के बराबर listener बन सकते हैं
    • इसे एक single Gateway के रूप में मॉडल करने पर दो समस्याएँ पैदा होती हैं
      • Gateway अधिकतम 64 listeners ही support करता है
      • अगर कई टीमें listener·TLS को मैनेज करें, तो Gateway coordination का bottleneck बन जाता है
    • इसे distributed और multi-tenant बनाने के लिए ListenerSet resource का उपयोग किया जाता है

  • अनुमत Listener और Route

    • Gateway और Route की अवधारणाओं को अलग करने के बाद, यह नियंत्रित करने की नई समस्या पैदा हुई कि कौन-सा tenant किस listener पर Route attach कर सकता है
    • listener shared infra होते हैं और उनके उपयोग अलग-अलग हो सकते हैं; उदाहरण के लिए, database तक passthrough channel वाले tls-passthrough-db listener पर HTTPRoute attach करना उचित नहीं है, और db के अलावा किसी अन्य namespace से Route attach करना भी उचित नहीं है
    • क्योंकि Route को self-service तरीके से जोड़ा जाता है, misconfiguration रोकने के लिए allowedRoutes mechanism का उपयोग किया जाता है
    • allowedRoutes, Gateway·ListenerSet और किसी विशेष namespace·route type के Route के बीच trust relationship स्थापित करता है

Routes

  • listener ट्रैफ़िक प्राप्त करता है, लेकिन उसके बाद उसे कैसे प्रोसेस करना है यह नहीं जानता; यह काम Route resource करता है, और यही Gateway API की flexibility का मूल है

  • अलग-अलग protocols को संभालने वाले पाँच प्रकार के Route resource मौजूद हैं

    • HTTPRoute: उन्नत और विस्तारित HTTP ट्रैफ़िक routing
    • GRPCRoute: gRPC-aware routing
    • TLSRoute: TLS SNI-आधारित routing
    • TCPRoute·UDPRoute: listener port के TCP/UDP ट्रैफ़िक को सीधे backend तक पहुँचाना
    विज्ञापन

  • सभी Route resources (सामूहिक रूप से xRoutes) की envelope structure मिलती-जुलती है

    • parentRefs उस parent resource का typed object reference है जो Route को स्वीकार करता है (आमतौर पर Gateway, ListenerSet, service mesh का Service आदि); विकल्प sectionName·port से किसी specific listener को निर्दिष्ट किया जा सकता है
    • rules में protocol-specific routing rules·filters·settings शामिल होती हैं; हर rule में matches, वैकल्पिक filters, और वैकल्पिक backendRefs होते हैं; अगर filter request को पूरी तरह संभाल ले, तो backendRefs छोड़ा जा सकता है
    • जहाँ protocol अनुमति देता है, वहाँ hostnames field से Route स्तर पर host-based routing की जा सकती है

  • HTTPRoute

    • L7 स्तर के HTTP(S) ट्रैफ़िक के लिए routing rules परिभाषित करता है

    • Traffic Matching

      • Ingress-जैसी path·host-आधारित routing, साथ ही header·query·method-आधारित matching rules का support
      • उदाहरण: केवल internal clients के लिए canary release को header-based matching के जरिए test deployment तक route किया जा सकता है
      • data plane सबसे specific rule लागू करता है, इसलिए rules किस क्रम में परिभाषित किए गए हैं इससे फर्क नहीं पड़ता

    • URL Rewrites

      • filter का उपयोग करके backend तक पहुँचने से पहले request URL के कुछ हिस्सों को rewrite किया जा सकता है

    • Header Modifications

      • request·response headers को add·remove·modify करने के लिए HeaderModifier filter उपलब्ध है
      • Cross-Origin Resource Sharing configuration के लिए समर्पित CORS filter भी उपलब्ध है; वैचारिक रूप से यह response header modification का एक special case है, लेकिन इसे अलग filter type के रूप में expose किया गया है

    • Redirects

      • backend पर भेजने के बजाय client को redirect response लौटाया जा सकता है; 3xx path-based redirects और HTTP→HTTPS redirect supported हैं

    • Traffic Control

      • weight के आधार पर backend services के बीच ट्रैफ़िक बाँटा जा सकता है, जो blue-green deployment और A/B testing जैसे use cases में उपयोगी है
      • traffic mirroring production ट्रैफ़िक की एक copy अतिरिक्त backend को भेजता है और इसे RequestMirror filter से configure किया जाता है; मूल request default backend की ओर ही जाती रहती है
      • mirroring, refactoring और migration के दौरान पुराने और नए version के परिणामों की तुलना करने वाले tap-and-compare testing का एक मुख्य घटक है

    • Sticky Sessions

      • session persistence का support है; cookie या header को session marker बनाकर एक ही client की requests को लगातार उसी backend instance तक route किया जा सकता है

    • External Authentication

      • gRPC या HTTP-आधारित experimental external authentication filter का support है; backend तक भेजने से पहले Gateway request headers को बाहरी authentication service तक भेजता है, जबकि request body केवल स्पष्ट रूप से enable करने पर भेजी जाती है
      • gRPC के मामले में external authentication service को Envoy के ext_authz protobuf API को implement करना होगा
      • HTTP के मामले में authentication सफल होने पर 200 लौटाया जाता है; अन्य कोई भी status authentication failure माना जाता है

    • Retries & Timeouts

      • किसी specific route पर retry configure किया जा सकता है, और BackendTrafficPolicy retry storm रोकने के लिए global retry budget प्रदान करता है

  • GRPCRoute

    • gRPC, HTTP/2 पर आधारित है इसलिए इसे HTTPRoute से भी संभाला जा सकता है, लेकिन इसे अलग resource के रूप में मॉडल करने के कारण हैं
      • URL rewrite जैसे वे विकल्प जो gRPC में अर्थहीन हैं, उन्हें अलग रखा जा सकता है ताकि हर resource अपने protocol के अनुसार स्वतंत्र रूप से विकसित हो
      • gRPC responses HTTP 200 लौटाते हुए भी grpc-status·grpc-message headers के जरिए application errors व्यक्त करते हैं, जो सही retry और metrics के लिए महत्वपूर्ण है
      • उच्च-स्तरीय gRPC terminology में rules परिभाषित करने से user experience बेहतर होता है
    • HTTPRoute का path matcher यहाँ method matcher से बदल दिया जाता है; अंदरूनी रूप से path ही match होता है, लेकिन इसे service·method के रूप में expose किया जाता है
    • request·response header handling संभव है, लेकिन gRPC payload को decode नहीं किया जाता, इसलिए किसी specific protobuf field के आधार पर routing संभव नहीं है
    • traffic mirroring·weighted load balancing और header modification जैसे कुछ HTTPRoute filters का support है

  • TCPRoute और UDPRoute

    • listener port तक पहुँचे ट्रैफ़िक को backend service तक साधारण रूप से forward करते हैं; वर्तमान में matcher·filter का support नहीं है
    • दोनों प्रकार कई backends के बीच weighted load balancing का support करते हैं

  • TLSRoute

    • TLS handshake के दौरान दिए गए SNI के आधार पर TLS-encrypted ट्रैफ़िक को backend तक route करता है
    • मुख्य रूप से TLS passthrough के लिए उपयोग किया जाता है; Gateway SNI देखकर backend चुनता है और TLS terminate किए बिना encrypted connection को आगे बढ़ाता है, जबकि TLS termination backend संभालता है
    • Envoy Gateway या kgateway जैसे कुछ implementations edge पर TLS termination भी support करते हैं, लेकिन यह एक extension capability है
    • Route में hostname स्पष्ट रूप से देना आवश्यक है; यह SNI value से match होना चाहिए और Gateway listener के hostname के साथ इसका intersection होना चाहिए; matcher·filter supported नहीं हैं, लेकिन weighted load balancing supported है

  • Route Filter Extensions

    • HTTPRoute और GRPCRoute में extensionRef filter के जरिए custom filters और request/response processing को extend करने का mechanism शामिल है, जो typed object reference के रूप में किसी अन्य resource की ओर संकेत करता है
    • उदाहरण: Envoy Gateway ऐसा HTTPRouteFilter CRD प्रदान करता है जो backend service के बिना सीधे response लौटाता है

  • Backend Targets

    • डिफ़ॉल्ट रूप से मानक Service (सबसे सामान्य) और multi-cluster के लिए ServiceImport को backend target के रूप में सपोर्ट करता है
    • typed object reference के रूप में निर्दिष्ट होने के कारण, implementation-specific custom resource के साथ विस्तार संभव है
    • उदाहरण: Envoy Gateway, FQDN·IP·UNIX socket जैसे external upstream को इंगित करने वाले custom Backend resource को सपोर्ट करता है
    विज्ञापन

  • ReferenceGrant

    • Gateway API, cross-namespace references को standard design के first-class concept के रूप में संभालता है, लेकिन इसमें security risk मौजूद है
    • confused deputy attack का उदाहरण: यदि कोई attacker एक namespace पर कब्ज़ा कर ले, तो Ingress·Service·EndpointSlice बनाने की permission के ज़रिए protected service तक पहुंच लीक हो सकती है
      • नया Ingress, compromised namespace के नए Service को इंगित करता है
      • वह Service selectorless होता है, इसलिए किसी deployment से match नहीं होता और EndpointSlice को मैन्युअली दिया जा सकता है
      • attacker, दूसरे namespace के protected backend pod IP शामिल करने के लिए EndpointSlice को forge करता है, और port alignment के ज़रिए protected API के लिए दूसरा entry point बनाता है
      • वही परिणाम ExternalName Service से भी हासिल किया जा सकता है
    • इसे कम करने के लिए ReferenceGrant resource लाया गया, जो एक bidirectional trust mechanism है, जिसमें एक namespace यह परिभाषित करता है कि कौन-से namespace उसके resources को refer कर सकते हैं
    • Gateway Controller, backend target और TLS secret के लिए cross-namespace reference करते समय ReferenceGrant को ध्यान में रखता है, जिससे confused deputy attack करना कठिन हो जाता है
    • हालांकि, ReferenceGrant केवल reference की वैधता सुनिश्चित करता है; ट्रैफ़िक फ़ॉरवर्ड होने के बाद उसके व्यवहार में दखल नहीं देता, इसलिए NetworkPolicies के साथ protected API port access को block करके अतिरिक्त सुरक्षा दी जा सकती है

Policies

  • Policy attachment एक शक्तिशाली extension pattern है, जो मूल resource को बदले बिना एक या अधिक Gateway API components पर hierarchical तरीके से behavior और effects लागू करता है
  • authentication इसका प्रमुख उदाहरण है
    • यदि authentication पूरे Gateway (या ListenerSet) पर लागू किया जाए, तो इसका hierarchical प्रभाव अभी और भविष्य में attach होने वाले सभी Route पर पड़ता है, साथ ही public route जैसे Route-level exceptions भी संभव हैं
    • authentication को Gateway·Route से असंबंधित टीम भी नियंत्रित कर सकती है, इसलिए इसे इस तरह डिज़ाइन किया गया है कि उन resources को सीधे modify न करना पड़े
    • OAuth 2·OIDC जैसे standards होने के बावजूद, authentication configuration implementation पर काफ़ी निर्भर होती है, इसलिए ऐसा abstraction बनाना कठिन है जो सभी implementations पर काम करे
  • उदाहरण: Envoy Gateway का SecurityPolicy resource JWT token validation configure करता है; Policy, Ingress युग की annotation-based configuration का आधुनिक और अधिक expressive विकल्प है
  • built-in Policy केवल दो हैं
    • BackendTLSPolicy: Gateway को upstream backend से TLS के माध्यम से कनेक्ट करने का निर्देश देता है
    • BackendTrafficPolicy: किसी specific backend के लिए retry budget निर्धारित करता है; यदि global retry allowance से अधिक हो जाए, तो 503 लौटाता है, circuit breaker की तरह काम करता है और retry storm को रोकता है

Ownership

  • क्लस्टर के भीतर Gateway API resources का स्वामित्व आमतौर पर दो टीमों के पास होता है
    • Platform team GatewayClass·Gateway·ListenerSet और LoadBalancer·TLS configuration को परिभाषित करती है, और कुछ या सभी Gateway पर लागू होने वाली global Policy भी मैनेज कर सकती है
    • Application/Service team मुख्य रूप से अपने Route resources पर ध्यान देती है और आवश्यकता पड़ने पर Route-level Policy लागू करती है
  • इसकी लचीलापन इतनी अधिक है कि Route को platform team द्वारा एक namespace में इकट्ठा करके own करने जैसे विभिन्न ownership models भी बनाए जा सकते हैं

Typical Architecture

  • Gateway API किसी विशेष implementation architecture को सख्ती से नहीं मानता, लेकिन एक सामान्य तरीका control plane और data plane का विभाजन है
  • Gateway Controller, control plane की भूमिका निभाने वाला Kubernetes operator है, जो Gateway API resources और CRD को observe करके वांछित data plane configuration तैयार करता है; इसके लिए resources को पढ़ने और संशोधित करने की विस्तारित permissions चाहिए
  • Gateway data plane, configuration के अनुसार traffic संभालने वाला proxy है; आमतौर पर Envoy Proxy·NGINX·Traefik आदि उपयोग होते हैं, और implementation के आधार पर हर Gateway के लिए अलग proxy provision किया जा सकता है या shared रखा जा सकता है
  • control/data plane का विभाजन, NGINX Ingress Controller में पाए गए मूलभूत security flaws से बचने के लिए लाभकारी design choice है

Ingress migration

  • NGINX Ingress Controller deprecation से निपटने के चार विकल्प हैं; इन्हें कम intrusive विकल्प से शुरू करके देखना चाहिए

  • Do Nothing

    • यह सर्वोत्तम नहीं है, लेकिन कुछ मामलों में संभव हो सकता है; homelab में इसके लिए प्रेरणा कम हो सकती है

    • enterprise वातावरण में इसे स्वीकार करना कठिन है, क्योंकि regulatory·security·compliance frameworks maintained और patched software चलाने की अपेक्षा करते हैं

      • ISO 27001: vulnerability management·patching·EOL tracking की अपेक्षा
      • SOC 2 Type II: vulnerability scanning·patch management·remediation SLA की अपेक्षा
      • HIPAA Security Rule: legacy और unpatched software को risk analysis में शामिल करना आवश्यक
      • PCI DSS v4.0.1: unsupported components की पहचान और remediation plan की मांग, साथ ही critical vulnerabilities के निपटान की समय-सीमा निर्धारित
      • FedRAMP: unsupported software को maintained alternatives से बदलने की अपेक्षा, और severity के अनुसार remediation deadlines मौजूद

    • अधिकांश frameworks में EOL software, नई vulnerabilities सामने आने पर व्यावहारिक समस्या बन जाता है

    • CVE analysis

      • पिछले 5 वर्षों में NGINX Ingress Controller के CVE की स्थिति
        • कुल 20 vulnerabilities
        • 2021 में secret leakage से संबंधित High 4
        • 2022 में controller credential leakage से संबंधित High 1
        • 2023~2024 में High 3
        • 2025 में 6, जिनमें Critical 1 (IngressNightmare) और NGINX configuration injection से संबंधित High 4 शामिल
        • 2026 में 6, जिनमें NGINX configuration injection से संबंधित High 3 शामिल
      • 2021~2022 के CVE मुख्य रूप से annotation में बिना sanitization के user-provided NGINX configuration की समस्या से जुड़े थे, जिससे configuration injection·information disclosure·secret leakage हुआ; Kubernetes ने validation जोड़ा
      • 2023~2024 के CVE मुख्यतः उसी annotation validation को bypass करने से संबंधित थे
      • IngressNightmare(CVE-2025-1974) ने स्थिति और खराब कर दी; पहले Ingress resource बनाने या modify करने की permission चाहिए होती थी, लेकिन admission controller तक network access भर होने पर configuration injection-जैसी bug के ज़रिए ingress-nginx controller context में remote code execution संभव हो गया, जिसके बाद controller जिन Secret तक पहुंच सकता है वे लीक हो सकते हैं
      • 2026 की बैच में भी annotation·path·comment के ज़रिए configuration injection का pattern जारी रहा
      • ये vulnerabilities बार-बार design की उसी कमजोरी को निशाना बनाती हैं
        • controller अत्यधिक flexible है और NGINX की व्यापक functionality expose करता है, इसलिए perfect validation कठिन है और configuration injection बार-बार होता है
        • controller, control plane और data plane को एक ही pod में चलाता है और filesystem साझा करता है, जिससे compromise की स्थिति में प्रभाव-क्षेत्र बढ़ जाता है
        • controller के पास अक्सर cluster-wide Secret तक पहुंच होती है, इसलिए configuration injection सफल होने पर cluster-wide secret leakage हो सकता है
      • इन संरचनात्मक समस्याओं के कारण भविष्य में अतिरिक्त CVE की संभावना है; migration plan के बिना मूल controller पर बने रहना जोखिम भरा विकल्प है
      विज्ञापन

  • NGINX Controller fork का उपयोग

    • सबसे सरल रास्ता maintained fork पर स्विच करना है
      • Chainguard का fork built image प्रदान नहीं करता दिखता, और यह संभवतः उसके paid offering का हिस्सा है
    • इससे नए CVE के exposure risk को कम किया जा सकता है और बड़े बदलाव के बिना सिस्टम चलाया जा सकता है, लेकिन यह अल्पकालिक समाधान है
    • Chainguard का लक्ष्य controller को लंबे समय तक विकसित करना नहीं, बल्कि users को migration के लिए समय देने हेतु best-effort CVE remediation उपलब्ध कराना है

  • दूसरे Ingress Controller का उपयोग

    • Ingress resource स्वयं deprecated नहीं है, इसलिए किसी दूसरे maintained Ingress Controller पर स्विच करना भी वैध विकल्प है, जैसे HAProxy·Istio·Traefik
    • पूरे सिस्टम में annotation migration की ज़रूरत होगी, और NGINX-विशिष्ट फीचर्स पर निर्भरता के अनुसार कठिनाई अलग-अलग होगी
    • आगे चलकर और प्रोजेक्ट Gateway API की ओर जाएंगे और Ingress का महत्व घटेगा, लेकिन फिलहाल Ingress भी पूरी तरह उपयुक्त है

  • Gateway API पर migration

    • लंबी अवधि के लिए एकमात्र विकल्प Ingress API से Gateway API पर जाना है
      • Gateway API CRD·implementation install करना
      • GatewayClass·Gateway·और आवश्यकता होने पर Policy resource configure करना
      • मौजूदा Ingress resources को Route में migrate करना
    • Kubernetes टीम द्वारा बनाया गया ingress2gateway CLI best-effort automatic conversion देता है, लेकिन custom annotation को बाद में manually फिर से जाँचना होगा
    • timeout, file upload limit, body size limit आदि को सटीक रूप से migrate करना होगा; छूटने या गलत mapping होने पर application की assumptions चुपचाप टूट सकती हैं
    • Ingress Controller के LoadBalancer से नए Gateway proxy के LoadBalancer तक traffic switchover को सावधानी से plan करना चाहिए, और इसे big-bang होना ज़रूरी नहीं है
      • Ingress Controller को अस्थायी public entry point के रूप में बनाए रखते हुए केवल कुछ traffic को Gateway API data plane पर भेजकर real traffic test के बाद धीरे-धीरे switch किया जा सकता है

कौन-सा Gateway चुनें

  • migration का निर्णय लेने के बाद पहला बड़ा सवाल यह है कि कौन-सा Gateway API implementation इस्तेमाल किया जाए

  • इस लेख में generic API Gateway use case की परिभाषा: पूरी तरह नियंत्रित environment में deploy किया गया public North-South traffic के लिए scalable gateway, जो सामान्य authentication patterns और flexible rate limiting को built-in रूप में देता हो

  • API Gateway के अलावा LLM Gateway·Agent Gateway भी मौजूद हैं, लेकिन यह खंड पारंपरिक API Gateway पर केंद्रित है

  • Gateway API Conformance

    • Kubernetes टीम ने implementations के core protocol handling की शुद्धता जाँचने के लिए standard conformance tests तैयार किए हैं; इनका फोकस मुख्यतः functional behavior पर है, जबकि reliability·performance·scalability·operational complexity जैसे non-functional पहलू इसमें शामिल नहीं हैं
    • conformant implementations को प्राथमिकता देनी चाहिए, और यदि आधिकारिक साइट पर परिणाम न हों तो maintainer से conformance report माँगना उचित है

  • Public Benchmarks

    • आधिकारिक tests के अलावा reliability और performance पर आधारित public benchmarks भी मौजूद हैं; Istio contributor और Solo.io कर्मचारी John Howard ने प्रमुख implementations के benchmarks बनाए हैं, और Solo.io, kgateway की parent company है
    • इनमें Route attachment·propagation·scale·और सामान्य traffic handling performance जैसे उपयोगी test cases शामिल हैं; यह उनके अपने अनुभव पर आधारित हैं, इसलिए कुछ खास use cases की ओर झुकाव हो सकता है, लेकिन evaluation के एक दृष्टिकोण के रूप में उपयोगी हैं

  • OSS vs Proprietary

    • आज कई मजबूत production-grade OSS Gateway API implementations उपलब्ध हैं, इसलिए evaluation में उन्हें गंभीरता से शामिल करना चाहिए; बहुत-सी organizations के लिए OSS default starting point है
    • OAuth2·OIDC जैसे वे फीचर्स, जो पहले commercial purchase को उचित ठहराते थे, अब commodity बन चुके हैं, और OSS controllers भी इन्हें built-in देते हैं
    • OSS में commit करने से पहले उसकी quality को सीधे परखा जा सकता है, जबकि commercial विकल्पों में vendor पर जल्दी भरोसा करना पड़ता है

  • Recommendations

    • data plane के आधार पर grouping

      • Envoy Proxy आधारित: Envoy Gateway, Istio, Cilium, kgateway आदि
      • NGINX आधारित: NGINX Gateway Fabric, Kong
      • अन्य proxy: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Envoy Proxy टीम द्वारा विकसित Envoy Proxy-आधारित open source Gateway API controller, जो Envoy फीचर्स को Gateway API से अधिकतम सीधे map करता है; इसलिए Istio की तुलना में product-specific abstractions कम हैं और इसे समझना आसान है
      • Ingress API को support नहीं करता, लेकिन Envoy AI Gateway के ज़रिए LLM·MCP gateway·Inference Pools फीचर्स तक विस्तार किया जा सकता है
      • हल्का है और deploy·operate करना आसान है, तथा API Gateway (North-South) पर केंद्रित है; supported features
        • external authentication·JWT validation·JWT claim-आधारित authorization·OIDC·IP allowlisting·static API key authentication·credential injection जैसे security patterns
        • flexible global rate limit policy, जिसमें global·route-level settings, shadow mode, request cost settings आदि शामिल हैं
        • connection·bandwidth·file size limits, availability zone-aware routing, ServiceImport-आधारित basic multi-cluster, Brotli·gzip·zstd response compression, direct response·response override
        विज्ञापन
      • extensibility भी अच्छी है: request·response·xDS settings को modify करने के लिए gRPC services लिखी जा सकती हैं, और Lua या WASM-compiled languages (Go·Rust) में plugins लिखे जा सकते हैं
      • FQDN·IP external resources और sidecar के लिए UNIX socket को point करने वाला custom Backend resource भी शामिल है
      • फिलहाल कुछ skipped tests के कारण partially conformant के रूप में सूचीबद्ध है, लेकिन functional रूप से लगभग सभी items पूरे करता है, और KEDA·KNative जैसे CNCF projects के साथ integrate होता है
      • अगर आपको केवल feature-rich API Gateway चाहिए, तो यह एक अच्छा विकल्प है

    • Istio

      • Envoy Proxy-आधारित service mesh और CNCF Graduated project, जो Gateway API tests में conformant के रूप में सूचीबद्ध है
      • यह Ingress Controller·Gateway API controller·और service mesh को शामिल करने वाला package है, और agentgateway integration के माध्यम से LLM·MCP·A2A gateway फीचर्स भी दे सकता है
      • Admiral आदि के साथ advanced multi-cluster support, व्यापक deployment profiles, बड़ा community, O'Reilly किताबों सहित भरपूर resources, और mTLS-आधारित pod-to-pod encryption के कारण सरकारी·FedRAMP environments में उपयोगी
      • कमियों में sidecar mode में अधिक resource consumption और अपने कई अलग concepts होने के कारण तेज learning curve शामिल हैं
      • ambient mode हल्का setup देता है, लेकिन advanced L7 use cases में यह sidecar जितना feature-complete नहीं हो सकता; अगर अधिक मजबूत policy और L7 control चाहिए, तो Envoy Gateway को ingress gateway·waypoint proxy के रूप में साथ में इस्तेमाल करने पर विचार किया जा सकता है
      • जब service mesh प्राथमिक हो और Gateway API द्वितीयक, तब यह सबसे अच्छा है; अगर केवल API gateway चाहिए, तो यह थोड़ा कम उपयुक्त लग सकता है

    • kgateway

      • Gloo project पर आधारित open source CNCF Sandbox gateway, जो data plane के रूप में Envoy Proxy और agentgateway (AI gateway features) को support करता है, और externally managed अपने data plane instances भी इस्तेमाल कर सकता है
      • पूर्ण Gateway API conformance के साथ लगभग अकेला implementation है जो लगभग सभी items को पूरा करता है
      • Envoy data plane में JWT validation·OAuth2/OIDC·external authentication·IP access control, Envoy global rate limiting, ext_proc-आधारित request·response processing exposure उपलब्ध है, लेकिन Lua·WASM plugins या raw xDS की direct modification expose नहीं होती दिखती
      • MiniJinja template-आधारित शक्तिशाली transformation engine के साथ TrafficPolicy resource में header·response body·status transformations को declarative तरीके से define किया जा सकता है
      • Istio के साथ edge proxy के रूप में integrate हो सकता है, लेकिन खुद service mesh की भूमिका नहीं निभाता; यह hierarchical Route को support करता है, जिसमें एक Route traffic handling को दूसरे Route को delegate कर सकता है, और AWS Lambda को सीधे call करने वाला custom AwsLambda CRD भी देता है
      • vendor के व्यापक deployments के दावों के बावजूद स्वतंत्र feedback अभी अधिक नहीं है, इसलिए public community के नज़रिए से यह अभी भी बढ़ता हुआ project लगता है

  • Traefik

    • Go में लिखा गया लोकप्रिय open source reverse proxy, Ingress API और Gateway API दोनों को support करता है; बेहतरीन documentation, सुव्यवस्थित codebase, सरल configuration और आसान deployment की वजह से खासकर homelab community में लोकप्रिय है

    • core Gateway API features और कुछ अतिरिक्त features को support करता है, लेकिन ListenerSet और Gateway API के जरिए traffic mirroring अभी support नहीं हैं (custom TraefikService backend के साथ mirroring संभव है)

    • extension model middleware-आधारित है; ExtensionRef filter के जरिए Route को Middleware CRD से जोड़ा जाता है; built-in middleware में ForwardAuth (external authentication delegation, Envoy ext_authz जैसा), IP allowlisting और CORS, connection limits, retry और circuit breaker, compression, custom error page आदि मिलते हैं

    • Plugin middleware के जरिए custom YAEGI और WASM plugins जोड़े जा सकते हैं (मुख्यतः request और response modification के लिए), लेकिन JWT validation, OIDC और OAuth2 Client Credentials केवल paid plugins के रूप में उपलब्ध हैं

    • Middleware CRD के जरिए basic distributed rate limiting का support है (IP, host, header bucket), लेकिन configuration ज्यादा flexible नहीं है और यह policy attachment के बजाय ExtensionRef के रूप में जुड़ता है, इसलिए global apply करने के बाद route-level override जैसी layering कठिन हो जाती है

    • स्पष्ट control/data plane separation नहीं है, इसलिए architecture NGINX Ingress के ज्यादा करीब है; वही pod resource watch भी करता है और traffic handle भी; हर Gateway के लिए proxy को dynamically provision नहीं किया जाता, बल्कि एक single deployment watched namespace के सभी Gateway को manage करता है, जिससे large-scale पर single point of failure और कम isolation के कारण resiliency issues हो सकते हैं

    • चुनने से पहले expected traffic के साथ load test करने की सलाह दी जाती है; खासकर Traefik के performance को लेकर शिकायतें सुनी गई हैं, इसलिए अतिरिक्त सावधानी जरूरी है

    • NGINX Gateway Fabric

      • NGINX पर आधारित F5 का official Gateway API implementation (NGF), मजबूत conformance के साथ आता है, और हाल के versions में Gateway API 1.5 तथा standard HTTPRoute filters के जरिए CORS और request/response header modification support जोड़ा गया है
      • JWT और OIDC authentication, cookie-based session persistence, NGINX reload के बिना upstream updates जैसी कुछ features अब भी NGINX Plus पर निर्भर हैं, जबकि ये API Gateway की सामान्य जरूरतें हैं
      • custom SnippetsPolicy और SnippetsFilter के जरिए generated config के कई levels पर custom NGINX settings inject की जा सकती हैं, जिससे मौजूदा NGINX Ingress की बड़ी मात्रा में custom settings को दोबारा लिखे बिना migration आसान होता है
      • custom RateLimitPolicy के जरिए rate limiting support है, लेकिन यह local rate limiting है, इसलिए state NGINX data plane में रहती है; कई NGF replicas चलाने पर effective limit instances की संख्या के अनुसार बदल सकती है, जिससे strict per-user limits लागू करना कठिन होता है
      • NGINX के अपने extension escape hatch के रूप में lightweight JavaScript और Lua scripting, external authentication delegation के लिए auth_request (Envoy ext_authz और Traefik ForwardAuth जैसा), और custom C modules उपलब्ध हैं; हालांकि ext_proc शैली की external service-based request/response modification supported नहीं है
      • NGF 2.0 में architecture को फिर से डिजाइन कर control/data plane separation और multiple Gateway resources support जोड़ा गया; पहले architecture एक बड़ी चिंता थी

    • Cilium Service Mesh

      • कई clusters CNI के रूप में Cilium का उपयोग करते हैं; इसका eBPF-आधारित sidecar-less service mesh, Envoy Proxy-आधारित Gateway API implementation भी शामिल करता है, जिससे components कम किए जा सकते हैं और tech stack को slim बनाया जा सकता है
      • लेकिन इसका मुख्य फोकस Gateway API conformance पर है; Gateway API के बाहर काम आने वाली Envoy features first-class configuration के रूप में exposed नहीं हैं; उदाहरण के लिए Envoy extensions और plugins, IP allowlisting, JWT validation, claim-based authorization और OIDC के लिए first-class support नहीं है
      • जब तक आपको पूरा भरोसा न हो कि Cilium की मौजूदा Gateway API capabilities आपके लिए पर्याप्त हैं, तब तक इसे Envoy Gateway, kgateway या Istio जैसे ज्यादा feature-rich विकल्पों की तुलना में general-purpose API Gateway के रूप में recommend नहीं किया जाता

    • Kong

      • NGINX-आधारित लोकप्रिय API Gateway, Kong Operator Ingress और Gateway API दोनों को support करता है
      • मुख्य चिंता इसकी OSS strategy है; ऐसा लगता है कि नए open source Gateway versions के लिए prebuilt Docker images जारी करना बंद कर दिया गया है, और OSS images लगभग 3.10 release line पर रुक गई हैं, जिससे आपको खुद build, patch, harden और maintain करना पड़ सकता है
      • सार्वजनिक रूप से यह अटकल भी मौजूद है कि यह कदम enterprise customers के churn को कम करने से जुड़ा था; इसे पक्का तथ्य नहीं माना जा सकता, लेकिन OSS दिशा कम predictable लगती है
      • इसलिए जब तक आप enterprise license खरीदने या OSS packaging और maintenance की जिम्मेदारी खुद लेने के लिए तैयार न हों, इसकी सिफारिश नहीं की जाती

Summary

  • Kubernetes ingress patterns के evolution को शुरुआती दौर से Gateway API युग तक trace किया गया है, और Gateway API protocol को भी गहराई से समझाया गया है
  • GAMMA (Gateway API ideas को service mesh तक बढ़ाना) और Inference Extension (Kubernetes inference workloads की definition और optimization) को जानबूझकर scope से बाहर रखा गया है, क्योंकि ये अलग गहन चर्चा वाले विषय हैं
  • उपलब्ध Gateway API implementations और उन्हें चुनने के मानदंडों की भी साथ में समीक्षा की गई है

संबंधित पढ़ाई

2 टिप्पणियां

 
click 1 시간 전

पिछले साल मैंने NGF आज़माने की कोशिश की थी, लेकिन Authorization हेडर-आधारित authentication बनाने का कोई तरीका नहीं था, इसलिए envoy की ओर गया था — ऐसा याद है.
envoy की तुलना में मैं nginx को ज़्यादा पसंद करता हूँ, इसलिए जब Gateway API का पूरा support हो जाएगा तो अगली बार NGF इस्तेमाल करने का सोच रहा हूँ
 
hmmhmmhm 2 시간 전

लगता है Envoy अब और ज़्यादा लोकप्रिय होगा।