ingress-nginx का विकल्प: Gateway API व्यवहार में

संक्षिप्त उत्तर: ingress-nginx प्रोजेक्ट अपने जीवन के अंत पर है — Kubernetes टीम ने घोषणा की है कि मार्च 2026 में मेंटेनेंस और सुरक्षा पैच बंद हो जाएंगे। इसका आधिकारिक उत्तराधिकारी कोई दूसरा Ingress कंट्रोलर नहीं, बल्कि एक API है: Gateway API, जो अक्टूबर 2023 में GA (v1) हो चुकी है। माइग्रेशन का मतलब है Gateway API के CRD इंस्टॉल करना, एक अनुरूप (conformant) कंट्रोलर तैनात करना (Kong, Traefik या NGINX Gateway Fabric), प्रत्येक Ingress को Gateway + HTTPRoute में बदलना, और फिर DNS स्विच करना। ट्रांज़िशन के दौरान दोनों को समानांतर चलाया जा सकता है।

किसी छोटे-मध्यम उद्यम के लिए क्लस्टर संभालने वाली कई टीमों को यह खबर किसी सुरक्षा बुलेटिन में पढ़कर मिलती है: «ingress-nginx retirement»। तीन साल पहले एक helm install से लगाया गया और उसके बाद कभी न छुआ गया कंट्रोलर, रातों-रात, इंटरनेट पर एक्सपोज़ किया गया एक गैर-मेंटेन्ड कंपोनेंट बन जाता है। यह ऐसी आपात स्थिति नहीं है जिसे एक रात में निपटाना पड़े, लेकिन यह एक ऐसा काम है जिसकी योजना अभी बनानी चाहिए, क्योंकि यह पूरे प्रोडक्शन HTTP ट्रैफ़िक के प्रवेश-बिंदु से जुड़ा है।

ingress-nginx क्यों बंद हो रहा है और इससे क्या बदलेगा

ingress-nginx Kubernetes प्रोजेक्ट का पारंपरिक Ingress कंट्रोलर है, जिसका रखरखाव SIG Network करता है। नवंबर 2025 में Kubernetes ब्लॉग पर प्रकाशित रिटायरमेंट की घोषणा दो कारण बताती है: एक अत्यंत महत्वपूर्ण कंपोनेंट, जिसका उपयोग अधिकांश क्लस्टर करते हैं, के लिए मेंटेनरों की टीम कुछ स्वयंसेवकों तक सिमट गई है; और तकनीकी कर्ज़ जिसे संभालना कठिन है — विशेष रूप से annotations के ज़रिए कॉन्फ़िगरेशन और configuration-snippet, जो कई उच्च-प्रभाव वाले CVE का स्रोत रहे हैं (जिनमें CVE-2025-1974, «IngressNightmare» भी शामिल है, जो कंट्रोलर में मनमाना कोड चलाने की अनुमति देता था)।

ठोस रूप में:

• बंद होने के बाद, कोई नया रिलीज़ नहीं, कोई सुरक्षा पैच नहीं, कोई अपडेटेड इमेज नहीं;
• आपका क्लस्टर चलता रहेगा — उस दिन कुछ भी टूटेगा नहीं;
• लेकिन NGINX, Lua या कंट्रोलर में आने वाला कोई भी नया CVE आधिकारिक पैच के बिना रह जाएगा।

एक Ingress कंट्रोलर सार्वजनिक रूप से एक्सपोज़ होता है और डिज़ाइन के अनुसार उसके पास एक ClusterRole होता है जो क्लस्टर के सभी Secrets पढ़ सकता है (TLS प्रमाणपत्रों के लिए)। यही बात IngressNightmare को विनाशकारी बनाती थी। सिस्टम के इस स्थान पर एक गैर-मेंटेन्ड कंपोनेंट पर कुछ महीनों से ज़्यादा बने रहना टिकाऊ विकल्प नहीं है।

भ्रमित न हों: ingress-nginx (Kubernetes का कम्युनिटी कंट्रोलर) और NGINX Ingress Controller, जो F5/NGINX द्वारा मेंटेन किया जाने वाला उत्पाद है। बाद वाला बना हुआ है। helm repo add ingress-nginx के ज़रिए इंस्टॉल किए गए अधिकांश क्लस्टर पहला वाला इस्तेमाल करते हैं।

Ingress भी अपने अंत की ओर है

समस्या केवल एक कंट्रोलर तक सीमित नहीं है। networking.k8s.io/v1 Ingress API फ़्रीज़ हो चुका है: यह केवल होस्ट और पथ के आधार पर HTTP रूटिंग को कवर करता है। बाकी सब कुछ — रीराइट, टाइमआउट, mTLS, दो वर्ज़न के बीच ट्रैफ़िक विभाजन, हेडर, gRPC, TCP — मालिकाना annotations में व्यक्त होता है, जो हर विक्रेता के यहाँ अलग होती हैं। दस nginx.ingress.kubernetes.io/* annotations वाला एक Ingress कहीं भी पोर्टेबल नहीं है।

Gateway API इसका जवाब टाइप्ड रिसोर्सेज़ से देती है, जिन्हें API सर्वर वैलिडेट करता है, और प्लेटफ़ॉर्म टीम तथा एप्लिकेशन टीमों के बीच ज़िम्मेदारियों के साझा मॉडल के साथ।

तीन रिसोर्सेज़ में Gateway API का मॉडल

परिचालन लाभ तुरंत दिखता है: प्लेटफ़ॉर्म टीम के पास प्रवेश-बिंदु और प्रमाणपत्र रहते हैं, डेवलपर अपने नेमस्पेस में अपनी रूट घोषित करते हैं, बिना लिसनर 443 को छूने या किसी होस्टनेम को हड़पने की क्षमता के। अनुमति Gateway पर allowedRoutes के ज़रिए और नेमस्पेस-पार संदर्भों के लिए ReferenceGrant के ज़रिए मिलती है।

नवंबर 2026 में उपयोगी वर्ज़न: GATEWAY_API_VERSION=v1.3.0 में HTTPRoute, GRPCRoute और GatewayClass v1 (स्टेबल) में आते हैं, जबकि TCPRoute, UDPRoute और TLSRoute v1alpha2 में बने हुए हैं। ये CRD Kubernetes के साथ नहीं आते: इन्हें स्पष्ट रूप से इंस्टॉल करना पड़ता है।

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml
kubectl get crd | grep gateway.networking.k8s.io

सामान्य HTTP/HTTPS के लिए standard चैनल पर्याप्त है। TCPRoute, BackendTLSPolicy या इम्प्लीमेंटेशन के अनुसार उन्नत प्रतिशत-आधारित रूटिंग के लिए experimental चैनल ज़रूरी है।

अपना इम्प्लीमेंटेशन चुनना: Kong, Traefik या NGINX Gateway Fabric

एक SME क्लस्टर के लिए तीन गंभीर उम्मीदवार, यह इस पर निर्भर करता है कि आप अपनी annotations से पहले क्या कर रहे थे।

Kong Ingress Controller — अगर आपको एक सच्चे API गेटवे की ज़रूरत है

Kong तब उपयुक्त विकल्प है जब प्रवेश-बिंदु केवल रूटिंग से ज़्यादा करता है: की या OIDC के ज़रिए प्रमाणीकरण, प्रति उपभोक्ता रेट लिमिटिंग, रिक्वेस्ट ट्रांसफ़ॉर्मेशन, संरचित लॉगिंग। कंट्रोलर (KIC 3.x) Gateway API के अनुरूप है और अपने फ़ंक्शन HTTPRoute से जुड़े KongPlugin के ज़रिए उपलब्ध कराता है।

helm repo add kong https://charts.konghq.com
helm repo update
helm install kong kong/ingress -n kong --create-namespace \
  --set controller.ingressController.image.tag=3.5 \
  --set gateway.env.database=off

DB-less मोड (database=off) को प्राथमिकता देनी चाहिए: कॉन्फ़िगरेशन Kubernetes CRD में रहता है, बैकअप लेने योग्य किसी PostgreSQL डेटाबेस में नहीं। इसके बाद एक रेट-लिमिटिंग प्लगिन किसी निश्चित रूट से जोड़ा जाता है:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit-api
  namespace: production
plugin: rate-limiting
config:
  minute: 120
  policy: local
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
  namespace: production
  annotations:
    konghq.com/plugins: rate-limit-api
spec:
  parentRefs:
    - name: public-gateway
      namespace: infra
  hostnames:
    - api.exemple.fr
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-svc
          port: 8080

लागत: Kong Gateway OSS मुफ़्त है (Apache 2.0 लाइसेंस), लेकिन एंटरप्राइज़ प्लगिन (पूर्ण OIDC, RBAC, Konnect) सशुल्क हैं। मध्यम ट्रैफ़िक के लिए 256 Mi से 512 Mi RAM वाले दो पॉड का हिसाब रखें।

Traefik — लागू करने में सबसे आसान

Traefik v3 अपने पारंपरिक IngressRoute के साथ-साथ Gateway API को भी सपोर्ट करता है। अगर आप पहले से Traefik इस्तेमाल कर रहे थे या आपकी ज़रूरतें रूटिंग + TLS + कुछ मिडलवेयर तक सीमित हैं, तो यह सबसे कम खर्चीला माइग्रेशन है।

helm repo add traefik https://traefik.github.io/charts
helm install traefik traefik/traefik -n traefik --create-namespace \
  --set providers.kubernetesGateway.enabled=true \
  --set gateway.enabled=false

एक ऐसी बारीकी पर ध्यान दें जो आधा दिन बरबाद करा सकती है: डिफ़ॉल्ट रूप से Traefik चार्ट खुद एक Gateway बनाता है। अगर आप अपनी Gateway GitOps में संभालते हैं, तो इसे बंद कर दें (gateway.enabled=false), वरना दो ऑब्जेक्ट एक ही लिसनर के लिए झगड़ते रहेंगे।

NGINX Gateway Fabric — NGINX पर बने रहने के लिए

NGF, NGINX/F5 द्वारा मेंटेन किया जाने वाला Gateway API इम्प्लीमेंटेशन है, जिसमें डेटा प्लेन के रूप में NGINX है। अगर आपकी टीमें NGINX डायरेक्टिव धाराप्रवाह पढ़ती हैं और आप प्रॉक्सी का वही व्यवहार (बफ़रिंग, keepalive, टाइमआउट) बनाए रखना चाहते हैं, तो यह सबसे कम आश्चर्य वाला रास्ता है। बदले में, इसका पॉलिसी इकोसिस्टम Kong के मुकाबले नया है।

अपने Ingress को HTTPRoute में बदलना

यहाँ ठोस अभ्यास है। किसी प्रोडक्शन क्लस्टर से लिया गया एक सामान्य Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: site
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts: [www.exemple.fr]
      secretName: site-tls
  rules:
    - host: www.exemple.fr
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service: { name: api-svc, port: { number: 8080 } }
          - path: /
            pathType: Prefix
            backend:
              service: { name: web-svc, port: { number: 3000 } }

इसके समतुल्य Gateway, जिसका स्वामित्व प्लेटफ़ॉर्म टीम के पास है:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: infra
spec:
  gatewayClassName: kong
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.exemple.fr"
      tls:
        mode: Terminate
        certificateRefs:
          - name: site-tls
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"

और एप्लिकेशन की तरफ़ की रूट, जिसमें रीराइट एक annotation के बजाय टाइप्ड फ़िल्टर से व्यक्त है:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: site
  namespace: production
spec:
  parentRefs:
    - name: public-gateway
      namespace: infra
  hostnames:
    - www.exemple.fr
  rules:
    - matches:
        - path: { type: PathPrefix, value: /api }
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: api-svc
          port: 8080
    - matches:
        - path: { type: PathPrefix, value: / }
      backendRefs:
        - name: web-svc
          port: 3000

तीन बातें याद रखने योग्य:

1. रेगेक्स गायब हो जाता है। rewrite-target: /$2 अब ReplacePrefixMatch वाला URLRewrite फ़िल्टर बन जाता है। यह अधिक पठनीय है, लेकिन वास्तव में रेगुलर-एक्सप्रेशन आधारित रीराइट (कई कैप्चर वाले) का कोई मानक समतुल्य नहीं है: वे इम्प्लीमेंटेशन-विशिष्ट पॉलिसी से होकर जाते हैं।
2. ReferenceGrant अनिवार्य है अगर TLS Secret या कोई बैकएंड Service उस ऑब्जेक्ट से अलग नेमस्पेस में रहता है जो उसका संदर्भ देता है। इसके बिना रूट की स्थिति ResolvedRefs: False रहती है और ट्रैफ़िक 500 में गिर जाता है।
3. cert-manager किसी Gateway के लिए प्रमाणपत्र जारी कर सकता है: कंट्रोलर पर --enable-gateway-api सक्रिय करें और Gateway को cert-manager.io/cluster-issuer से annotate करें। यह cert-manager 1.15 से समर्थित है।

वह टूल जो 80 % काम कर देता है

Gateway API प्रोजेक्ट ingress2gateway देता है, जो आपके Ingress पढ़ता है (कुछ nginx और kong annotations सहित) और उनके अनुरूप मैनिफ़ेस्ट बनाता है:

go install github.com/kubernetes-sigs/ingress2gateway@latest
ingress2gateway print --providers ingress-nginx --all-namespaces > gateway-api.yaml

नतीजा एक शुरुआती बिंदु है, अंतिम डिलीवरी नहीं: उसे फिर से पढ़ें, Gateway को समेटें (टूल अक्सर प्रति Ingress एक बनाता है) और हर अनुवादित न हुई annotation जाँचें।

बिना डाउनटाइम स्विच करना

अच्छी खबर: दोनों दुनियाएँ साथ रह सकती हैं। एक Ingress कंट्रोलर और एक Gateway साथ-साथ चल सकते हैं, हर एक अपने LoadBalancer प्रकार के Service के पीछे, इसलिए अपने अलग IP के साथ।

1. इंस्टॉल करें CRD और नया कंट्रोलर एक समर्पित नेमस्पेस में। जाँचें कि IP असाइन हो गया है: kubectl get gateway -A -o wide।
2. DNS के बाहर परीक्षण करें, Host हेडर को नए IP की ओर ज़बरदस्ती भेजकर:

   curl -sk --resolve www.exemple.fr:443:203.0.113.42 https://www.exemple.fr/api/health -i
   

3. किसी भी स्विच से पहले रूट की स्थिति सत्यापित करें: kubectl describe httproute site -n production में Accepted: True और ResolvedRefs: True दिखना चाहिए।
4. एक दिन पहले DNS TTL घटाकर 60 सेकंड करें, फिर A/AAAA रिकॉर्ड स्विच करें। OVHcloud या Scaleway पर घोषित TTL से कुछ मिनट अधिक वास्तविक प्रसार समय का हिसाब रखें।
5. पुराने और नए IP पर 4xx/5xx कोड और p95 लेटेंसी 24 से 48 घंटे तक देखें। जब तक पुराना कंट्रोलर चल रहा है, रोलबैक सिर्फ़ DNS वापस बदलना है।
6. ingress-nginx को अनइंस्टॉल करें तभी, जब उसके Service पर एक हफ़्ते तक कोई अवशिष्ट ट्रैफ़िक न आए।

क्लासिक जाल है WebSocket और लंबी-अवधि के कनेक्शन: वे फिर से नहीं चलते, वे उस समय कट जाते हैं जब क्लाइंट दोबारा कनेक्शन खोलता है। स्विच व्यस्त घंटों के बाहर रखें, और नई Gateway पर timeouts जाँचें (Kong: KongIngress/KongUpstreamPolicy; Traefik: ServersTransport)।

लागत की दृष्टि से, देखने वाला मद लाइसेंस नहीं बल्कि लोड बैलेंसर है। एक्सपोज़्ड लिसनर वाली हर Gateway एक LoadBalancer सर्विस बनाती है, इसलिए प्रदाता द्वारा बिल किया गया एक IP — OVHcloud या Scaleway पर एक एंट्री-लेवल मैनेज्ड LB के लिए लगभग 10 से 15 €/माह। सहअस्तित्व के चरण में आप दोनों के पैसे देते हैं। इसके बाद साझा करें: हर एप्लिकेशन के लिए एक Gateway के बजाय, allowedRoutes की मदद से कई नेमस्पेस द्वारा साझा एक ही Gateway। यह बिल्कुल उसी तरह का निर्णय है जिसे हम अपने क्लाउड इंफ़्रास्ट्रक्चर और संचालन मिशनों में संभालते हैं।

अगर आपकी इमेज प्राइवेट हैं तो रजिस्ट्री सीक्रेट्स का भी ध्यान रखें: नए कंट्रोलर के पॉड, और विशेष रूप से नए नेमस्पेस में फिर से तैनात आपके एप्लिकेशन, को अपने imagePullSecret की ज़रूरत होती है — यह विषय Kubernetes पर प्राइवेट GitLab इमेज वाली हमारी गाइड में विस्तार से समझाया गया है।

अक्सर पूछे जाने वाले प्रश्न

क्या मार्च 2026 से पहले माइग्रेट करना अनिवार्य है?

नहीं: तकनीकी रूप से उस तारीख को कुछ बंद नहीं होता। जो बंद होता है, वह है पैच का प्रकाशन। असली मानदंड आपका एक्सपोज़र है: ग्राहक डेटा वाले सार्वजनिक क्लस्टर को इस तिमाही में माइग्रेट करना चाहिए; VPN के पीछे का आंतरिक क्लस्टर किसी अधिक आरामदायक विंडो का इंतज़ार कर सकता है। हर स्थिति में, निर्णय का दस्तावेज़ीकरण करें और NGINX पर CVE घोषणाओं की निगरानी रखें।

क्या ingress-nginx रखते हुए एक Gateway जोड़ी जा सकती है?

हाँ, और ट्रांज़िशन के लिए यही सुझाई गई रणनीति है। दोनों API एक ही क्लस्टर में साथ रह सकती हैं। बस ध्यान रखें कि एक ही होस्टनेम दोनों द्वारा एक साथ सर्व न हो: इससे व्यवहार DNS पर निर्भर हो जाएगा, और ऐसी घटनाएँ होंगी जिन्हें दोहराना असंभव है।

Kong, Traefik या NGINX Gateway Fabric: किसी SME के लिए कौन?

Traefik, अगर आप न्यूनतम झंझट चाहते हैं और रूटिंग + TLS पर्याप्त है। Kong, अगर प्रवेश-बिंदु को API गेटवे की भूमिका निभानी है (कीज़, कोटा, OIDC, लॉगिंग)। NGINX Gateway Fabric, अगर आपकी टीम डेटा प्लेन के रूप में NGINX बनाए रखना चाहती है। तीनों HTTPRoute v1 के अनुरूप हैं, इसलिए आपकी रूट पोर्टेबल रहती हैं: केवल विशिष्ट पॉलिसी (प्लगिन, मिडलवेयर) आपको किसी विक्रेता से बाँधती हैं।

जिन annotations का कोई समतुल्य नहीं है, उनका क्या होता है?

वे इम्प्लीमेंटेशन-विशिष्ट CRD से होकर जाती हैं: Kong में KongPlugin और KongUpstreamPolicy, Traefik में Middleware, NGF में ClientSettingsPolicy और ObservabilityPolicy। माइग्रेशन का फ़ायदा उठाकर पूरी सूची बनाएँ: व्यवहार में, वर्षों से जमा हुई annotations का एक-तिहाई हिस्सा अब किसी काम का नहीं होता।

क्या Gateway API TCP और gRPC संभालती है?

GRPCRoute स्टैंडर्ड चैनल के v1.1 से स्टेबल है। TCPRoute, UDPRoute और TLSRoute v1alpha2 में बने हुए हैं और experimental चैनल की माँग करते हैं, जिसका समर्थन इम्प्लीमेंटेशन के अनुसार बदलता है। PostgreSQL या Redis को क्लस्टर के बाहर एक्सपोज़ करने के लिए, पहले Gateway API प्रोजेक्ट का कंफ़र्मेंस मैट्रिक्स जाँचें।

सारांश

• मार्च 2026 के बाद ingress-nginx मेंटेन नहीं होगा: एक एक्सपोज़्ड कंपोनेंट, जो क्लस्टर के सभी Secrets पढ़ सकता है, उस पर कोई सुरक्षा पैच नहीं।
• उत्तराधिकारी है Gateway API (v1.3.0), जिसे उसके CRD के ज़रिए इंस्टॉल करना है, एक अनुरूप कंट्रोलर के साथ: Kong (API गेटवे), Traefik (सरलता), NGINX Gateway Fabric (NGINX की निरंतरता)।
• माइग्रेशन हर Ingress को Gateway + HTTPRoute में बदलता है: annotations टाइप्ड फ़िल्टर बन जाती हैं, और ingress2gateway पहला ड्राफ़्ट तैयार कर देता है।
• दोनों कंट्रोलर साथ रह सकते हैं: curl --resolve से परीक्षण करें, घटे हुए TTL के साथ DNS से स्विच करें, रोलबैक के लिए पुराने को एक हफ़्ता रखें।
• सहअस्तित्व के दौरान लोड बैलेंसर की लागत पर नज़र रखें और बाद में allowedRoutes के ज़रिए एक ही Gateway साझा करें।
• अपने प्रवेश-बिंदु या अपने क्लस्टर पर किसी बाहरी नज़र की ज़रूरत है? टीम से मिलें और अपने प्रोजेक्ट के बारे में बात करें।