Ingress-NGINX सेवानिवृत्त हो गया: कुबरनेट्स टीमों को आगे क्या करना चाहिए

आपका Ingress कंट्रोलर अब भी सामान्य रूप से ट्रैफ़िक रूट कर रहा हो सकता है, लेकिन उसे सुरक्षित रखने वाला प्रोजेक्ट रुक चुका है। माइग्रेशन के लिए सिर्फ़ YAML बदलने से ज़्यादा कुछ चाहिए।

यह अब भी काम करता है—इसीलिए इसे टालना आसान है

आपके Kubernetes ऐप्लिकेशन सामान्य रूप से जवाब दे रहे हैं। TLS सर्टिफ़िकेट रिन्यू हो रहे हैं। रूट्स अब भी सही Services तक ट्रैफ़िक भेज रहे हैं। डैशबोर्ड पर कहीं यह नहीं दिखता कि आपकी ingress परत की मियाद ख़त्म हो चुकी है।

लेकिन अगर वे रूट्स Kubernetes समुदाय के Ingress-NGINX कंट्रोलर पर निर्भर हैं, तो यह सॉफ़्टवेयर अब रिटायर हो चुका है। प्रोजेक्ट रिपॉज़िटरी को 24 मार्च 2026 को आर्काइव कर दिया गया। अब कोई नई रिलीज़, बग-फ़िक्स या सुरक्षा पैच नहीं आएँगे।

मौजूदा इंस्टॉलेशन को रिमोट से बंद नहीं किया गया। इमेजेज़ और Helm चार्ट अब भी उपलब्ध हैं। यह परिचालन निरंतरता के लिए उपयोगी है, लेकिन यह एक ख़तरनाक धारणा भी बनाता है: क्योंकि कंट्रोलर अब भी चल रहा है, इसलिए माइग्रेशन का इंतज़ार किया जा सकता है।

जोखिम तुरंत बंद हो जाने का नहीं है। जोखिम यह है कि इंटरनेट ट्रैफ़िक को लगातार ऐसे कॉम्पोनेंट से गुज़ारा जा रहा है जिसके मेंटेनर अब अगली कमज़ोरी को ठीक नहीं करेंगे।

पहले, तीन मिलती-जुलती लगने वाली चीज़ों को अलग करें

रिटायरमेंट की घोषणा को ग़लत समझना आसान है क्योंकि Kubernetes नेटवर्किंग में कई मिलते-जुलते नाम इस्तेमाल होते हैं।

नाम	यह क्या है	मौजूदा स्थिति
Ingress API	बुनियादी HTTP और HTTPS रूटिंग बताने के लिए एक स्थिर Kubernetes रिसोर्स	रिटायर या डिप्रीकेटेड नहीं
Ingress-NGINX	Kubernetes-समुदाय का कंट्रोलर जो Ingress रिसोर्स और NGINX-विशिष्ट एनोटेशन को चलते हुए प्रॉक्सी कॉन्फ़िगरेशन में बदलता है	24 मार्च 2026 को रिटायर
NGINX Ingress Controller	F5 द्वारा बनाए रखा जाने वाला एक अलग कंट्रोलर	एक अलग उत्पाद; Kubernetes रिटायरमेंट में शामिल नहीं
Gateway API	Kubernetes नेटवर्किंग रिसोर्स और कन्फ़ॉर्मेंस नियमों का एक नया सेट	नई डिज़ाइनों और कई माइग्रेशन के लिए अनुशंसित दिशा

एक Ingress रिसोर्स सिर्फ़ एक घोषणा है। एक कंट्रोलर उस घोषणा को पढ़ता है और असली ट्रैफ़िक-हैंडलिंग सॉफ़्टवेयर को कॉन्फ़िगर करता है। एक कंट्रोलर को रिटायर करने से Kubernetes से Ingress API नहीं हट जाता।

Gateway API भी अपने-आप में कोई कंट्रोलर नहीं देता। यह GatewayClass, Gateway और HTTPRoute जैसे रिसोर्स परिभाषित करता है। आपको अब भी ऐसा इम्प्लीमेंटेशन चुनना होगा जो आपकी ज़रूरत की सुविधाओं और परिचालन मॉडल का समर्थन करे।

सिर्फ़ YAML बदलना पर्याप्त क्यों नहीं है

Ingress-NGINX अपेक्षाकृत छोटे Ingress API के साथ शुरू हुआ, फिर एनोटेशन, ConfigMap और कस्टम रिसोर्स के ज़रिए वर्षों में कंट्रोलर-विशिष्ट व्यवहार जोड़ता गया।

दो क्लस्टरों में मिलते-जुलते दिखने वाले Ingress रिसोर्स हो सकते हैं, फिर भी वे इन जैसी सेटिंग्स के कारण अलग व्यवहार कर सकते हैं:

• पथ पुनर्लेखन और रेगुलर एक्सप्रेशन;
• अनुरोध और कनेक्शन टाइमआउट;
• अधिकतम अनुरोध-बॉडी आकार;
• HTTP-से-HTTPS रीडायरेक्ट;
• सोर्स-IP हैंडलिंग;
• प्रमाणीकरण और रेट लिमिट;
• कस्टम NGINX कॉन्फ़िगरेशन स्निपेट;
• TLS पासथ्रू और सर्टिफ़िकेट प्लेसमेंट।

इनमें से कुछ के लिए मानक Gateway API समकक्ष मौजूद हैं। कुछ के लिए इम्प्लीमेंटेशन-विशिष्ट पॉलिसी रिसोर्स चाहिए। कुछ को कॉपी करने के बजाय दोबारा सोचा जाना चाहिए।

उदाहरण के लिए, Kubernetes माइग्रेशन मार्गदर्शन चेतावनी देता है कि Ingress-NGINX के रेगुलर-एक्सप्रेशन मैच केस-इनसेंसिटिव प्रीफ़िक्स मैच हो सकते हैं। इसलिए एक यांत्रिक रूप से अनुवादित रूट अलग पथ स्वीकार कर सकता है, जब तक टीम असली व्यवहार की जाँच न करे। बॉडी-साइज़ लिमिट, URL नॉर्मलाइज़ेशन और कस्टम कॉन्फ़िगरेशन स्निपेट में भी पोर्टेबल एक-से-एक मैपिंग नहीं हो सकती।

जो माइग्रेट किया जा रहा है वह मैनिफ़ेस्ट नहीं है। वह ट्रैफ़िक व्यवहार है।

Gateway API एक दिशा है, कोई उत्पाद चुनाव नहीं

Gateway API मूल Ingress मॉडल की कई सीमाओं को सुधारता है। यह इंफ्रास्ट्रक्चर स्वामित्व को ऐप्लिकेशन रूटिंग से अलग करता है, साझा क्लस्टरों के लिए स्पष्ट अनुमति मॉडल देता है, और हर एक्सटेंशन को एनोटेशन में डाले बिना समृद्ध रूटिंग का समर्थन करता है।

इससे हर Gateway API इम्प्लीमेंटेशन समान नहीं बन जाता। इम्प्लीमेंटेशन अलग-अलग रूट प्रकार, वैकल्पिक सुविधाएँ और पॉलिसी एक्सटेंशन का समर्थन कर सकते हैं। Gateway API प्रोजेक्ट कन्फ़ॉर्मेंस परिणाम प्रकाशित करता है, लेकिन कन्फ़ॉर्मेंस हर संभव सुविधा के बजाय किसी ख़ास प्रोफ़ाइल और रूट प्रकार पर लागू हो सकता है।

कोई कंट्रोलर चुनने से पहले, यह तुलना करें कि आपके वर्कलोड को क्या चाहिए:

ज़रूरत	जाँचने के लिए सवाल
HTTP रूटिंग	क्या इम्प्लीमेंटेशन मौजूदा Gateway + HTTPRoute कन्फ़ॉर्मेंस पास करता है?
TLS	सर्टिफ़िकेट कहाँ संग्रहीत हैं, और क्या TLS समाप्त होता है या पासथ्रू होता है?
प्रमाणीकरण	क्या यह मानक है, इम्प्लीमेंटेशन-विशिष्ट पॉलिसी है या कोई बाहरी सेवा?
ट्रैफ़िक पॉलिसी	टाइमआउट, रीट्राई, बॉडी लिमिट और रेट लिमिट कैसे व्यक्त किए जाते हैं?
मल्टी-टीम स्वामित्व	क्या प्लेटफ़ॉर्म और ऐप्लिकेशन टीमें अलग-अलग रिसोर्स सुरक्षित रूप से प्रबंधित कर सकती हैं?
ऑपरेशन	अपग्रेड, लॉग, मेट्रिक्स, ट्रेसिंग और रोलबैक कैसे संभाले जाते हैं?
पोर्टेबिलिटी	डिज़ाइन के कौन-से हिस्से किसी एक कंट्रोलर के एक्सटेंशन पर निर्भर हैं?

सही लक्ष्य कोई प्रबंधित क्लाउड Gateway कंट्रोलर, Envoy Gateway, Traefik, Istio या कोई अन्य कन्फ़ॉर्मेंट इम्प्लीमेंटेशन हो सकता है। यह कोई अन्य मेंटेन किया जा रहा Ingress कंट्रोलर भी हो सकता है, जब तुरंत Gateway API माइग्रेशन व्यावहारिक न हो। रिटायरमेंट आपको असमर्थित सॉफ़्टवेयर छोड़ने के लिए कहता है; यह हर क्लस्टर के लिए एक ही गंतव्य को सही नहीं बनाता।

एक सुरक्षित माइग्रेशन क्रम

1. पता करें कि Ingress-NGINX वास्तव में कहाँ इस्तेमाल हो रहा है

क्लस्टर, कंट्रोलर वर्ज़न, Helm रिलीज़, IngressClass ऑब्जेक्ट, Ingress रिसोर्स, एनोटेशन, ConfigMap, स्निपेट, TCP/UDP एक्सपोज़र और cert-manager या ExternalDNS जैसे इंटीग्रेशन की इन्वेंट्री बनाएँ। नॉन-प्रोडक्शन और डिज़ास्टर-रिकवरी क्लस्टर भी शामिल करें; भूले हुए क्लस्टर अक्सर सबसे आख़िर में माइग्रेट होते हैं।

2. रिप्लेसमेंट चुनने से पहले व्यवहार दर्ज करें

हर महत्वपूर्ण रूट के लिए, होस्ट, पथ, रीडायरेक्ट, हेडर, प्रमाणीकरण, टाइमआउट, बॉडी लिमिट, TLS व्यवहार और फ़ेलियर रिस्पॉन्स दर्ज करें। इस व्यवहार के लिए टेस्ट जोड़ें। सिर्फ़ कॉन्फ़िगरेशन देखकर कंट्रोलर द्वारा तय किए गए डिफ़ॉल्ट सामने नहीं आ सकते।

3. लक्ष्य इम्प्लीमेंटेशन चुनें

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

4. Ingress2Gateway को एक सहायक के रूप में इस्तेमाल करें

Kubernetes SIG Network का Ingress2Gateway 1.0 सामान्य Ingress-NGINX एनोटेशन का अनुवाद कर सकता है और उस कॉन्फ़िगरेशन के बारे में चेतावनी दे सकता है जिसे वह दर्शा नहीं सकता। यह 30 से ज़्यादा सामान्य एनोटेशन का समर्थन करता है और अनुवादों को असली कंट्रोलरों पर परखता है।

इसका अपना दस्तावेज़ीकरण स्पष्ट है: यह एक माइग्रेशन सहायक है, एक-झटके में होने वाला रिप्लेसमेंट नहीं। हर चेतावनी को अनसुलझा काम मानें। सिर्फ़ इसलिए चेतावनियाँ न छोड़ें क्योंकि वैध Gateway API YAML जनरेट हो गया।

5. दोनों रास्ते चलाएँ और नतीजे तुलना करें

नया कंट्रोलर और रूट मौजूदा रास्ते के साथ-साथ डिप्लॉय करें। सामान्य ट्रैफ़िक, फ़ेलियर केस, बड़े अनुरोध, रीडायरेक्ट, लंबे समय तक चलने वाले अनुरोध, क्लाइंट IP और सर्टिफ़िकेट व्यवहार टेस्ट करें। फिर वेटेड DNS, लोड-बैलेंसर नियंत्रण या समर्थित ट्रैफ़िक स्प्लिटिंग का उपयोग करके धीरे-धीरे ट्रैफ़िक शिफ़्ट करें।

जब तक नया रूट असली ट्रैफ़िक और उपयुक्त अवलोकन अवधि से गुज़र न जाए, तब तक एक परखा हुआ रोलबैक रास्ता बनाए रखें।

6. पुराने कंट्रोलर को पूरी तरह हटाएँ

कटओवर के बाद, पुराने Ingress रिसोर्स, एडमिशन कॉम्पोनेंट, कंट्रोलर वर्कलोड, सर्विस अकाउंट, क्लस्टर रोल, ConfigMap, Services और लोड बैलेंसर हटाएँ। एक बिना इस्तेमाल वाला इंटरनेट-फ़ेसिंग कंट्रोलर इंस्टॉल छोड़ देना अटैक सरफ़ेस और परिचालन भ्रम दोनों बनाए रखता है।

टीमों को इस हफ़्ते क्या करना चाहिए?

किसी फ़ैशनेबल रिप्लेसमेंट को इंस्टॉल करने से शुरुआत न करें। सबूत से शुरुआत करें।

हर क्लस्टर पर इन्वेंट्री चलाएँ और इनका जवाब दें:

1. क्या हम रिटायर हो चुका Kubernetes Ingress-NGINX कंट्रोलर चला रहे हैं?
2. कौन-सी इंटरनेट-फ़ेसिंग सेवाएँ इस पर निर्भर हैं?
3. कौन-से एनोटेशन या कस्टम कॉन्फ़िगरेशन ऐसा व्यवहार तय करते हैं जो बुनियादी Ingress रिसोर्स नहीं दिखाता?
4. माइग्रेशन का मालिक कौन है और लक्ष्य तारीख़ क्या है?
5. ट्रैफ़िक शिफ़्ट होने से पहले हम कैसे साबित करेंगे कि रिप्लेसमेंट सही व्यवहार करता है?

अगर जवाब अधूरे हैं, तो Ingress-NGINX को एक असमर्थित प्लेटफ़ॉर्म निर्भरता के रूप में दर्ज करें और माइग्रेशन को एक मालिक दें। काम करता हुआ कंट्रोलर, समर्थित कंट्रोलर के बराबर नहीं है।

जानें, इस्तेमाल करें या महारत हासिल करें?

जानें: डेवलपर्स को समझना चाहिए कि Ingress API, Ingress-NGINX और Gateway API अलग-अलग चीज़ें हैं। ऐप्लिकेशन टीमों को यह जानना ज़रूरी है कि उनकी सेवाएँ किन रूटिंग व्यवहारों पर निर्भर हैं।

इस्तेमाल करें: प्लेटफ़ॉर्म और DevOps इंजीनियरों को एनोटेशन की इन्वेंट्री बनानी चाहिए, इम्प्लीमेंटेशन का आकलन करना चाहिए, रूट का अनुवाद करना चाहिए और समानांतर वातावरण में व्यवहार टेस्ट करना चाहिए।

महारत हासिल करें: साझा क्लस्टरों के लिए ज़िम्मेदार प्लेटफ़ॉर्म आर्किटेक्ट को GatewayClass, Gateway, रूट स्वामित्व, पॉलिसी अटैचमेंट, कन्फ़ॉर्मेंस वैलिडेशन और कंट्रोलर लाइफ़साइकल गवर्नेंस डिज़ाइन करना चाहिए।

Ingress-NGINX का रिटायरमेंट किसी जल्दबाज़ी वाले कंट्रोलर बदलाव की वजह नहीं है। यह ingress परत को अदृश्य प्लंबिंग मानना बंद करने की वजह है। इसके व्यवहार को समझें, एक मेंटेन किया जा रहा गंतव्य चुनें, और सबूत के साथ ट्रैफ़िक माइग्रेट करें।

संदर्भ और आगे पढ़ने के लिए

• Ingress NGINX Retirement: What You Need to Know — Kubernetes, 11 नवंबर 2025. आधिकारिक रिटायरमेंट घोषणा और यह बताती है कि क्या उपलब्ध रहता है। सितंबर 2026 में समीक्षा की गई।
• Kubernetes v1.36 Sneak Peek: Ingress NGINX retirement — Kubernetes, 30 मार्च 2026. 24 मार्च 2026 को रिटायरमेंट और फ़िक्स तथा सुरक्षा अपडेट के बंद होने की पुष्टि करता है। सितंबर 2026 में समीक्षा की गई।
• Before You Migrate: Five Surprising Ingress-NGINX Behaviors — Kubernetes, 27 फ़रवरी 2026. वे कंट्रोलर व्यवहार दिखाता है जो सामान्य कॉन्फ़िगरेशन कन्वर्ज़न के दौरान खो सकते हैं। सितंबर 2026 में समीक्षा की गई।
• Announcing Ingress2Gateway 1.0 — Kubernetes SIG Network, 20 मार्च 2026. माइग्रेशन सहायक, उसके परखे गए एनोटेशन समर्थन और उसकी सीमाओं का वर्णन करता है। सितंबर 2026 में समीक्षा की गई।
• Migrating from Ingress — Kubernetes Gateway API प्रोजेक्ट. मुख्य Ingress अवधारणाओं को Gateway API से जोड़ता है और बताता है कि इम्प्लीमेंटेशन-विशिष्ट सुविधाएँ कहाँ बनी रहती हैं। सितंबर 2026 में समीक्षा की गई।
• Gateway API implementations and conformance — Kubernetes Gateway API प्रोजेक्ट. इम्प्लीमेंटेशन सूचीबद्ध करता है और कन्फ़ॉर्मेंस रिपोर्ट के दायरे को समझाता है। सितंबर 2026 में समीक्षा की गई।