APISIX Ingress Controller, Emissary-ingress से बेहतर विकल्प क्यों है?

पृष्ठभूमि जानकारी

Kubernetes Ingress एक API ऑब्जेक्ट है जिसका उपयोग क्लस्टर में बाहरी ट्रैफ़िक को आंतरिक सेवाओं तक रूट करने के लिए नियमों को परिभाषित करने के लिए किया जाता है। एक Ingress Controller का उपयोग आमतौर पर Ingress संसाधन के तर्क को लागू करने और इन ट्रैफ़िक नियमों को केंद्रीय रूप से प्रबंधित करने के लिए किया जाता है।

व्यवहार में, उद्यम उपयोगकर्ताओं को आमतौर पर mTLS, रिट्राइज़, दर सीमित करना, और प्रमाणीकरण जैसे ट्रैफ़िक प्रबंधन कार्यों की आवश्यकता होती है, जिन्हें Ingress संसाधन के शब्दार्थ पूरा नहीं कर सकते। इसलिए, Ingress Controller कार्यान्वयन आमतौर पर अतिरिक्त CRDs जोड़कर कार्यों को विस्तारित करते हैं। निम्नलिखित में APISIX Ingress Controller और Emissary-Ingress कार्यान्वयन के बीच के अंतरों की विस्तृत तुलना प्रदान की जाएगी।

Apache APISIX Ingress Controller क्या है

Apache APISIX Ingress Controller ASF (Apache Software Foundation) के तहत एक ओपन-सोर्स प्रोजेक्ट है। इसका कंट्रोल प्लेन Kubernetes में संसाधनों को कॉन्फ़िगर और डिलीवर करता है, जबकि APISIX वास्तविक व्यावसायिक ट्रैफ़िक को संभालता है। सुरक्षा में सुधार के लिए, पूरी तैनाती प्रक्रिया में डेटा प्लेन और कंट्रोल प्लेन आर्किटेक्चर का उपयोग किया जाता है, जो डेटा प्लेन पर हमले के कारण Kubernetes क्लस्टर अनुमति लीक के जोखिम को प्रभावी ढंग से रोकता है।

Emissary-Ingress क्या है

Emissary-Ingress CNCF (Cloud Native Computing Foundation) का एक इन्क्यूबेटिंग प्रोजेक्ट है। Envoy प्रॉक्सी के कंट्रोल प्लेन के रूप में, यह Kubernetes संसाधनों को पार्स करने के लिए जिम्मेदार है, और सभी ट्रैफ़िक को डेटा प्लेन पर Envoy द्वारा सीधे संसाधित किया जाता है। कंट्रोल प्लेन और डेटा प्लेन को एक कंटेनर में पैकेज करके, पूरी प्रक्रिया को एक्सेस और तैनात करना आसान हो जाता है।

APISIX Ingress Controller और Emissary-Ingress के बीच अंतर

Ingress संसाधनों का समर्थन करने के अलावा, APISIX Ingress Controller और Emissary-Ingress दोनों CRDs और Gateway API के माध्यम से कॉन्फ़िगरेशन का समर्थन कर सकते हैं, जो Ingress शब्दार्थ की सीमाओं को पूरा करते हैं।

निम्नलिखित अनुभाग बुनियादी कार्यक्षमताओं, सेवा खोज, और विस्तारणीयता के दृष्टिकोण से दोनों के बीच के अंतर और लाभों का विश्लेषण करेंगे।

बुनियादी कार्यक्षमताएं

फ़ीचर		APISIX Ingress	Emissary-ingress
प्रोटोकॉल	HTTP/HTTPS	✓	✓
	gRPC	✓	✓
	TCP	✓	✓
	UDP	✓	✕
	Websockets	✓	✓
लोड बैलेंस	Round Robin	✓	✓
	Ring Hash	✓	✓
	Least Connections	✓	✓
	Maglev	✕	✓
प्रमाणीकरण	External Auth	✓	✓
	Basic	✓	✓
	JWT	✓	✕
	OAuth	✓	✕
	OpenID	✓	✕
ट्रैफ़िक प्रबंधन	Circuit Breaker	✓	✓
	Rate Limiting	✓	✓
	Canary	✓	✓
	Fault Injection	✓	✕
	Health Checks	✓	✓

सामान्य गेटवे फ़ंक्शन में ट्रैफ़िक प्रबंधन, लोड बैलेंसिंग, और प्रमाणीकरण शामिल हैं। हालांकि, यह ध्यान दिया जाना चाहिए कि Emissary-Ingress का प्रमाणीकरण के लिए समर्थन अपेक्षाकृत सीमित है, जिसमें केवल Basic Auth और External Auth क्षमताएं शामिल हैं।

सेवा खोज

माइक्रोसर्विसेज आर्किटेक्चर में, एप्लिकेशन आमतौर पर कई माइक्रोसर्विसेज में विभाजित होते हैं जो विशिष्ट व्यावसायिक तर्क को पूरा करने के लिए एक साथ काम करते हैं। चूंकि माइक्रोसर्विस इंस्टेंस की संख्या लगातार बदलती रहती है, इसलिए एक तंत्र की आवश्यकता होती है जो सेवाओं को एक दूसरे को खोजने और स्थान निर्धारित करने में मदद करे।

सेवा खोज से तात्पर्य है कि माइक्रोसर्विसेज को नेटवर्क पर कैसे खोजा जाता है, सेवा नाम के माध्यम से सेवा खोज की जानकारी प्राप्त करके यह निर्धारित किया जाता है कि अनुरोध किस इंस्टेंस पर रूट किया जाएगा।

पारंपरिक माइक्रोसर्विस फ्रेमवर्क के लिए, रजिस्ट्री का चयन अक्सर विशिष्ट व्यावसायिक आवश्यकताओं पर आधारित होता है। हालांकि, मौजूदा सेवा पंजीकरण और खोज घटक को Kubernetes-आधारित DNS सेवा खोज तंत्र में माइग्रेट करने में कुछ संशोधनों की लागत शामिल हो सकती है।

दूसरी ओर, यदि गेटवे वर्तमान सेवा पंजीकरण और खोज घटकों का समर्थन करता है, तो ऐसे संशोधनों की आवश्यकता नहीं होती है, जिससे माइक्रोसर्विस फ्रेमवर्क के लिए बेहतर समर्थन प्राप्त हो सकता है।

यहां दोनों के लिए सेवा खोज घटकों का समर्थन स्थिति है:

सेवा खोज	Apache APISIX Ingress Controller	Emissary-Ingress
Kubernetes	✓	✓
DNS	✓	✓
Nacos	✓	✕
Eureka	✓	✕
Consul	✓	✓

सेवा खोज इकोसिस्टम के संबंध में, APISIX Ingress Controller का समर्थन अधिक मजबूत है, और उपयोगकर्ता इसे अपने मौजूदा माइक्रोसर्विस फ्रेमवर्क में Ingress कंट्रोलर के माध्यम से आसानी से एकीकृत कर सकते हैं।

विस्तारणीयता

जब Kubernetes Ingress कंट्रोलर की कार्यक्षमता विशिष्ट आवश्यकताओं को पूरा नहीं करती है, तो उपयोगकर्ता कस्टम विकास के माध्यम से इसकी कार्यक्षमता को विस्तारित कर सकते हैं। अधिक व्यक्तिगत आवश्यकताओं को पूरा करने के लिए कस्टम प्लगइन्स विकसित करने या मौजूदा कोड को संशोधित करने की आवश्यकता हो सकती है। मजबूत विस्तारणीयता वाले Ingress कंट्रोलर विशिष्ट परिदृश्यों के लिए बेहतर समर्थन और समाधान प्रदान कर सकते हैं।

Emissary-Ingress

Emissary-Ingress की विस्तारणीयता अपेक्षाकृत कम है, क्योंकि यह कस्टम Envoy Filter के माध्यम से विस्तार का समर्थन नहीं करता है। चूंकि डेटा प्लेन और कंट्रोल प्लेन एकीकृत हैं, इसलिए इसे पूरे सिस्टम के कस्टम विकास की आवश्यकता होती है। डेटा प्लेन Envoy के लिए कस्टम विकास की जटिलता अधिक है और यह डेवलपर्स पर महत्वपूर्ण बोझ डालता है।

इसके अलावा, यदि उपयोगकर्ताओं को अधिक शक्तिशाली Emissary-Ingress की आवश्यकता होती है, तो उन्हें इसे Ambassador के वाणिज्यिक उत्पाद Edge Stack में अपग्रेड करना होगा। कुछ मालिकाना फ़ीचर्स के लिए समर्थन प्राप्त करने के लिए भुगतान की आवश्यकता होती है।

APISIX Ingress Controller

APISIX का डेटा प्लेन मुख्य रूप से प्लगइन्स के माध्यम से अपनी कार्यक्षमता को विस्तारित करता है, जो 80 से अधिक आउट-ऑफ-द-बॉक्स प्लगइन्स प्रदान करते हैं। APISIX Ingress Controller APISIX द्वारा प्रदान किए गए सभी प्लगइन्स का समर्थन करता है, जो अधिकांश दैनिक उपयोग के मामलों को पूरा कर सकते हैं।

यदि विशिष्ट व्यावसायिक परिदृश्यों के आधार पर कस्टमाइज़ेशन की आवश्यकता होती है, तो APISIX उपयोगकर्ताओं को उनकी स्थिति के अनुसार स्वतंत्र रूप से चुनने और संयोजित करने के लिए कई विस्तार विकल्प प्रदान करता है। वर्तमान में समर्थित विस्तार विधियां निम्नलिखित हैं:

1. Lua भाषा का उपयोग करके प्लगइन्स विकसित करना अपेक्षाकृत सरल है और लगभग किसी भी प्रदर्शन हानि के बिना। इसके अलावा, आप सर्वरलेस प्लगइन का उपयोग करके Lua कोड सीधे लिख सकते हैं, जो व्यावसायिक आवश्यकताओं को तेजी से पूरा कर सकता है।
2. मूल Lua भाषा के अलावा, आप Plugin Runner या WASM प्लगइन्स का उपयोग करके विस्तार कर सकते हैं, जो Java, Python, और Go जैसी कोडिंग भाषाओं में कस्टम प्लगइन्स विकसित करने का समर्थन करते हैं। यह उपयोगकर्ताओं को अपने मौजूदा व्यावसायिक तर्क का उपयोग करने और अपनी कंपनी की तकनीकी स्टैक या विकास प्राथमिकताओं के आधार पर चयन करने की अनुमति देता है, बिना किसी नई भाषा की आवश्यकता के।

APISIX Ingress Controller उपरोक्त विस्तार विधियों का पूर्ण समर्थन करता है, बिना किसी अतिरिक्त विकास के।

प्रदर्शन

Kubernetes ingress ट्रैफ़िक प्रॉक्सी घटक के रूप में, यह प्लेटफ़ॉर्म के सभी आने वाले ट्रैफ़िक को प्रबंधित करता है और विभिन्न ट्रैफ़िक नियमों को एकीकृत रूप से प्रबंधित करता है, जो प्रॉक्सी के प्रदर्शन पर अधिक मांग रखता है।

इस लेख में, हम APISIX Ingress Controller (APISIX: 3.1.0) और Emissary-Ingress 3.4.0 का प्रदर्शन परीक्षण एक ही इंस्टेंस (4C 8G) में करेंगे।

QPS

QPS (Queries-per-second) एक सेवा द्वारा प्रति सेकंड संसाधित किए जा सकने वाले अनुरोधों की संख्या को दर्शाता है। संख्या जितनी अधिक होगी, प्रदर्शन उतना ही बेहतर होगा।

• 5000 Ingress संसाधन QPS

विलंबता

प्रतिक्रिया विलंबता: सर्वर द्वारा प्रतिक्रिया देने में लगने वाला समय। विलंबता जितनी कम होगी, प्रदर्शन उतना ही बेहतर होगा।

ग्राफ से पता चलता है कि APISIX Ingress Controller विभिन्न संसाधन स्केल पर सुसंगत प्रदर्शन बनाए रखता है, जो एक संतुलित प्रदर्शन दर्शाता है।

दूसरी ओर, Emissary-Ingress बड़े संसाधन स्केल और विभिन्न रूटिंग मैचों को संभालने में QPS और विलंबता पर महत्वपूर्ण प्रभाव डालता है, जिसमें प्रदर्शन संसाधन संख्या बढ़ने के साथ कम होता है। इसलिए, वास्तविक उत्पादन वातावरण में व्यावसायिक मात्रा बढ़ने के साथ, APISIX का उच्च प्रदर्शन अधिक प्रमुख हो जाता है।

निष्कर्ष

Emissary-Ingress सरलता और एकीकरण में आसानी की विशेषता रखता है, लेकिन कस्टम विकास के लिए अधिक कठिन है। इसके अलावा, अतिरिक्त फ़ीचर आवश्यकताओं के लिए प्लेटफ़ॉर्म के संबंधित घटकों पर निर्भरता होती है।

तुलना में, APISIX Ingress Controller विस्तारणीयता और सेवा खोज एकीकरण में लाभ रखता है, जिसमें मजबूत विस्तारणीयता और सरल विकास होता है। इसके अलावा, APISIX Ingress Controller का प्रदर्शन असाधारण रूप से अच्छा है, विशेष रूप से जब व्यावसायिक स्केल लगातार बढ़ता है, तो यह महत्वपूर्ण लाभ दिखाता है।