APISIX Ingress Controller, NGINX Ingress Controller से बेहतर क्यों है?

Xin Rong

December 6, 2022

Products

Ingress Kubernetes में सेवाओं को एक्सपोज़ करता है, जहां ट्रैफ़िक रूटिंग Ingress संसाधन पर कॉन्फ़िगर किए गए नियमों द्वारा नियंत्रित होती है। एक ingress को संतुष्ट करने के लिए, आपके पास एक Ingress कंट्रोलर भी होना चाहिए।

इस लेख में, हम दो लोकप्रिय Ingress कंट्रोलरों की तुलना करेंगे ताकि पाठकों को ingress कंट्रोलर चुनने में मदद मिल सके।

  • Ingress-NGINX Kubernetes समुदाय द्वारा लागू किया गया एक Ingress कंट्रोलर है और समुदाय में व्यापक रूप से उपयोग किया जाता है।
  • APISIX Ingress कंट्रोलर Apache APISIX को अपने डेटा प्लेन के रूप में लेता है, जो ASF (Apache Software Foundation) के तहत एक ओपन-सोर्स प्रोजेक्ट है।

Ingress NGINX बनाम APISIX Ingress

फीचर तुलना

नीचे दी गई तालिका Ingress NGINX और APISIX Ingress के बुनियादी फीचर्स की तुलना करती है, जिसमें प्रोटोकॉल, अपस्ट्रीम प्रोब/रिज़िलिएंसी, लोड बैलेंसर स्ट्रैटेजी, प्रमाणीकरण, Kubernetes इंटीग्रेशन आदि शामिल हैं। यह तालिका learnk8s.io से ली गई है।

उत्पाद/प्रोजेक्टIngress NGINXApache APISIX Ingress
1. सामान्य जानकारी
आधारितnginxnginx
2. प्रोटोकॉल
HTTP/HTTPS✔️✔️
HTTP2✔️✔️
gRPC✔️✔️
TCPआंशिक✔️
TCP+TLS✖︎✔️
UDPआंशिक✔️
वेबसॉकेट✔️✔️
प्रॉक्सी प्रोटोकॉल✔️✔️
QUIC/HTTP3पूर्वावलोकनपूर्वावलोकन
3. क्लाइंट
दर सीमित करना (L7)✔️✔️
WAF✔️आंशिक
टाइमआउट✔️✔️
सुरक्षित सूची/ब्लॉक सूची✔️✔️
प्रमाणीकरण✔️✔️
प्राधिकरण✖︎✔️
4. ट्रैफ़िक रूटिंग
होस्ट✔️✔️
पथ✔️✔️
हेडर✔️✔️
क्वेरीस्ट्रिंग✔️✔️
विधि✔️✔️
क्लाइंटIP✔️✔️
5. अपस्ट्रीम प्रोब/रिज़िलिएंसी
स्वास्थ्य जांच✖︎✔️
पुनः प्रयास✔️✔️
सर्किट ब्रेकर✖︎✔️
6. लोड बैलेंसर स्ट्रैटेजी
राउंड रॉबिन✔️✔️
स्टिकी सत्र✔️✔️
कम से कम कनेक्शन✖︎✔️
रिंग हैश✔️✔️
कस्टम लोड बैलेंसिंग✖︎✔️
7. प्रमाणीकरण
बेसिक प्रमाणीकरण✔️✔️
बाहरी प्रमाणीकरण✔️✔️
क्लाइंट प्रमाणपत्र - mTLS✔️✔️
OAuth✔️✔️
OpenID✖︎✔️
JWT✖︎✔️
LDAP✖︎✔️
HMAC✖︎✔️
8. अवलोकन
लॉगिंग✔️✔️
मेट्रिक्स✔️✔️
ट्रेसिंग✔️✔️
9. Kubernetes इंटीग्रेशन
स्थितिKubernetesKubernetes
CRD✖︎✔️
स्कोपक्लस्टरवाइड
नेमस्पेस
नेमस्पेस
गेटवे API का समर्थन✖︎पूर्वावलोकन
सर्विस मेश के साथ इंटीग्रेशन✔️✔️
10. ट्रैफ़िक शेपिंग
कैनरी✔️✔️
सत्र आत्मीयता✔️✔️
ट्रैफ़िक मिररिंग✔️✔️
11. अन्य
हॉट रीलोडिंग✔️✔️
LetsEncrypt इंटीग्रेशन✔️✔️
वाइल्डकार्ड प्रमाणपत्र समर्थन✔️✔️
हॉट रीलोडिंग कॉन्फ़िगर करेंपूर्वावलोकन✔️
सर्विस डिस्कवरी✔️

अंतर

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

Ingress NGINX और APISIX Ingress के बीच फीचर अंतर

सर्विस डिस्कवरी

माइक्रोसर्विसेज आर्किटेक्चर में, एप्लिकेशन को कई माइक्रोसर्विसेज में विभाजित किया जाता है। जब भी एक माइक्रोसर्विस विफल होता है, या एक सेवा को स्केल अप या डाउन किया जाता है, तो कॉलर को जल्द से जल्द सूचित करने की आवश्यकता होती है ताकि कॉल विफलताओं से बचा जा सके। इसलिए, सर्विस रजिस्ट्रेशन और सर्विस डिस्कवरी मैकेनिज्म माइक्रोसर्विस आर्किटेक्चर में महत्वपूर्ण हैं, जो आमतौर पर सर्विस रजिस्ट्री द्वारा बनाए रखा जाता है।

सर्विस डिस्कवरीIngress NGINXApache APISIX Ingress
Kubernetes✔️✔️
DNS✔️
nacos✔️
eureka✔️
consul_kv✔️

प्रोटोकॉल समर्थन

जबकि दोनों ingress HTTP/HTTPS प्रोटोकॉल का समर्थन करते हैं, APISIX अधिक प्रोटोकॉल का समर्थन करता है। यह TCP ट्रैफ़िक को एन्क्रिप्ट करने के लिए TLS का समर्थन करता है। यह MQTT, Dubbo, और kafka को प्रॉक्सी करने के लिए भी समर्थन करता है।

अपस्ट्रीम प्रोब/रिज़िलिएंसी

स्वास्थ्य जांच

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

Ingress NGINX में स्वास्थ्य जांच फंक्शनलिटी अभी तक समर्थित नहीं है, लेकिन APISIX Ingress इस फंक्शनलिटी प्रदान करता है:

  • सक्रिय जांच: बैकएंड में पॉड्स के स्वस्थ होने को सुनिश्चित करने के लिए प्रोब का उपयोग करें। जब एक नोड को भेजे गए N लगातार प्रोब विफल होते हैं, तो नोड को अस्वस्थ के रूप में चिह्नित किया जाएगा। लोड बैलेंसर अस्वस्थ नोड्स को अनदेखा करेगा ताकि वे अनुरोध प्राप्त न कर सकें। सक्रिय स्वास्थ्य जांच को सक्षम करने से अस्वस्थ पॉड्स को अक्षम करके ट्रैफ़िक हानि से बचा जा सकता है।
  • निष्क्रिय जांच: निष्क्रिय स्वास्थ्य जांच को अतिरिक्त प्रोब शुरू करने की आवश्यकता नहीं होती है। नोड को भेजे गए प्रत्येक अनुरोध एक प्रोब के रूप में कार्य करता है। यदि एक स्वस्थ नोड को भेजे गए N लगातार अनुरोध विफल होते हैं, तो नोड को अस्वस्थ के रूप में चिह्नित किया जाएगा। चूंकि यह नोड स्थिति को पहले से महसूस नहीं कर सकता है, इसलिए कुछ विफल अनुरोध हो सकते हैं। यह स्थिति रोलिंग अपडेट के दौरान अपेक्षाकृत आम है, और हम सेवा डाउनग्रेड का उपयोग करके विफल अनुरोधों की संख्या को कम कर सकते हैं।

httpbin सेवा के लिए APISIX Ingress में स्वास्थ्य जांच कॉन्फ़िगर करने का उदाहरण:

apiVersion: apisix.apache.org/v2 kind: ApisixUpstream metadata: name: httpbin spec: healthCheck: passive: unhealthy: httpCodes: - 500 httpFailures: 3 active: type: http httpPath: /healthz healthy: successes: 3 interval: 2s httpCodes: - 200

सर्किट ब्रेकर

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

स्वास्थ्य जांच फीचर के समान, सेवा सर्किट ब्रेकिंग का फीचर Ingress NGINX में समर्थित नहीं है। APISIX Ingress में, api-breaker प्लगइन इसको लागू करने में मदद करता है।

APISIX Ingress में सर्किट ब्रेकर का नमूना कॉन्फ़िगरेशन:

apiVersion: apisix.apache.org/v2 kind: ApisixRoute metadata: name: httpbin-route spec: http: - name: rule1 match: hosts: - httpbin.org paths: - /status/* backends: - serviceName: httpbin servicePort: 80 plugins: - name: api-breaker enable: true config: break_response_code: 502 unhealthy: http_statuses: - 505 failures: 2 healthy: http_statuses: - 200 successes: 2

अधिक प्लगइन और प्रमाणीकरण विधियों का समर्थन

Ingress NGINX मुख्य रूप से Annotations और ConfigMap का उपयोग करता है, और समर्थित प्लगइन अपेक्षाकृत सीमित हैं। यदि आप JWT, HAMC, या अन्य प्रमाणीकरण विधियों का उपयोग करना चाहते हैं, तो आपको उन्हें स्वयं इंटीग्रेट करना होगा।

APISIX Ingress APISIX में 80+ प्लगइन का समर्थन करता है, जो JWT, HAMC, wolf-rbac जैसे कई प्रमाणीकरण विधियों का समर्थन करता है। ये प्लगइन अधिकांश उपयोग के परिदृश्यों को कवर करते हैं।

APISIX रूट पर HMAC प्रमाणीकरण का उदाहरण:

apiVersion: apisix.apache.org/v2 kind: ApisixConsumer metadata: name: hmac-value spec: authParameter: hmacAuth: value: access_key: papa secret_key: fatpa algorithm: "hmac-sha256" clock_skew: 0 --- apiVersion: apisix.apache.org/v2 kind: ApisixRoute metadata: name: httpbin-route spec: http: - name: rule1 match: hosts: - httpbin.org paths: - /ip backends: - serviceName: httpbin servicePort: 80 authentication: enable: true type: hmacAuth

Ingress NGINX और APISIX Ingress की एक्स्टेंसिबिलिटी

जब Ingress कंट्रोलर के बुनियादी फीचर्स उद्योग उपयोगकर्ताओं की आवश्यकताओं को पूरा नहीं करते हैं, तो इसे केवल एक्सटेंशन के माध्यम से कस्टमाइज़ किया जा सकता है। आगे, हम समझाएंगे कि Ingress NGINX और APISIX Ingress अपने फीचर्स को कैसे एक्सटेंड करते हैं।

Ingress NGINX अपने फीचर्स को कैसे एक्सटेंड करता है

Ingress NGINX केवल Lua प्रोग्राम को एम्बेड करके एक्सटेंड किया जा सकता है।

Ingress NGINX प्लगइन डेवलपमेंट उदाहरण:

  1. Lua प्रोग्राम example-plugin लिखें
  2. प्लगइन को ingress-nginx पॉड में /etc/nginx/lua/plugins/<your plugin name> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin में इंस्टॉल करें
  3. ConfigMap में example-plugin को सक्षम करें, और Ingress NGINX इंस्टॉल करते समय इस ConfigMap ऑब्जेक्ट को संदर्भित करें
apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller namespace: ingress-nginx data: plugins: "example-plugin"

APISIX Ingress अपने फीचर्स को कैसे एक्सटेंड करता है

APISIX Ingress फीचर्स को एक्सटेंड करने के लिए विभिन्न विधियां प्रदान करता है, और उद्योग उपयोगकर्ता अपनी आवश्यकताओं के अनुसार स्वतंत्र रूप से विधि चुन सकते हैं। APISIX समर्थन करता है:

  • Lua के माध्यम से प्लगइन डेवलपमेंट: सरल और लगभग कोई प्रदर्शन हानि नहीं
  • प्लगइन-रनर के माध्यम से डेवलपमेंट: JAVA/Python/Go जैसी प्रोग्रामिंग भाषाओं का समर्थन करता है, इसलिए उपयोगकर्ता नई भाषाएं सीखे बिना अपने प्लगइन कस्टमाइज़ कर सकते हैं
  • WASM के माध्यम से प्लगइन: WASM बिल्ड करने वाली किसी भी भाषा का उपयोग प्लगइन डेवलपमेंट के लिए किया जा सकता है

इसके अलावा, आप सर्वरलेस प्लगइन के माध्यम से सीधे Lua कोड लिखकर व्यावसायिक आवश्यकताओं को जल्दी से पूरा कर सकते हैं।

APISIX Ingress CustomResourceDefinition (CRD) का समर्थन क्यों करता है?

वर्तमान में, APISIX Ingress तीन डिक्लेरेटिव कॉन्फ़िगरेशन का समर्थन करता है: Ingress, CRD, और Gateway API। हम यहां मुख्य रूप से Ingress और CRD की तुलना करेंगे। और हम Gateway API के बारे में बाद में समझाएंगे।

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

  • उपयोग में आसान क्योंकि यह डेटा प्लेन के डिज़ाइन सिमेंटिक्स के अनुरूप है
  • कॉन्फ़िगरेशन की पुन: उपयोगिता को बढ़ाने के लिए
  • कार्यक्षमता और एक्स्टेंसिबिलिटी में सुधार
  • APISIX का डेटा प्लेन एक सक्रिय समुदाय है, जिसमें त्वरित अपडेट और रिलीज़ होते हैं, और CRD डेटा प्लेन की अधिक क्षमताओं को आसानी से समर्थन कर सकता है

Ingress NGINX का दर्द बिंदु: हॉट रीलोडिंग समर्थित नहीं

स्टैटिक कॉन्फ़िगरेशन के कारण समस्याएं

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

NGINX रीलोड को ट्रिगर करने वाली स्थितियां

  • एक नया Ingress संसाधन बनाना
  • मौजूदा Ingress में TLS सेक्शन जोड़ना
  • Ingress एनोटेशन बदलना जो अपस्ट्रीम कॉन्फ़िगरेशन को प्रभावित कर सकता है (उदाहरण के लिए, लोड-बैलेंस एनोटेशन को रीलोड करने की आवश्यकता नहीं है)
  • Ingress में पथ जोड़ना या हटाना
  • Ingress, सेवा, या सीक्रेट संसाधनों को हटाना
  • सीक्रेट को अपडेट करना

उपरोक्त स्थितियां Ingress कंट्रोलर के अधिकांश उपयोग के परिदृश्यों को कवर करती हैं। एप्लिकेशन के लगातार डिप्लॉय होने वाले क्लस्टर वातावरण में, Ingress और सीक्रेट जैसे संसाधनों के ऑपरेशन (निर्माण, अपडेट, हटाना, आदि) लगातार ट्रिगर होंगे। इससे NGINX रीलोड की संख्या में तेजी से वृद्धि होगी, जो उत्पादन वातावरण पर महत्वपूर्ण प्रभाव डालेगी।

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

Gateway API

Kubernetes Gateway API के लाभ

Kubernetes Gateway API Ingress की तुलना में अधिक कार्यक्षमता प्रदान करता है और इसे Kubernetes सर्विस नेटवर्किंग को एक्सप्रेसिव, एक्स्टेंसिबल, और रोल-ओरिएंटेड इंटरफ़ेस के माध्यम से विकसित करने के लिए डिज़ाइन किया गया है, जिसे कई वेंडर्स द्वारा लागू किया गया है और व्यापक उद्योग समर्थन प्राप्त है। Gateway API की निम्नलिखित विशेषताएं हैं:

  • रोल-ओरिएंटेड: गेटवे API संसाधनों से बना है। विभिन्न API संसाधन Kubernetes नेटवर्क संसाधनों का उपयोग और कॉन्फ़िगर करने के लिए विभिन्न भूमिकाओं का प्रतिनिधित्व करते हैं

  • मजबूत एक्सप्रेसिवनेस: Gateway API कोर कार्यक्षमता का समर्थन करता है, जिसमें हेडर-आधारित मिलान, ट्रैफ़िक वेटिंग, और अन्य क्षमताएं शामिल हैं जो केवल Ingress में कस्टमाइज़्ड गैर-मानक एनोटेशन के माध्यम से संभव थीं

  • एक्स्टेंसिबिलिटी: Gateway API विभिन्न API लेयर्स पर विभिन्न संसाधनों को लिंक करने की अनुमति देता है। यह API संरचना के भीतर ग्रैन्युलर कस्टमाइज़ेशन को सक्षम करता है

Gateway API का समर्थन स्थिति

Kubernetes Gateway API Kubernetes सर्विस मेश को एक्सटेंड करने के लिए एक मानक है। इसका Gateway संसाधन Kubernetes API के रूप में उपयोग किया जा सकता है जो गेटवे के जीवनचक्र को प्रबंधित करता है, जो बहुत शक्तिशाली है। कई Ingress कंट्रोलर इसे सक्रिय रूप से समर्थन करते हैं, जिसमें Istio, Kong, Traefik, आदि शामिल हैं। दुर्भाग्य से, Ingress NGXIN अभी तक Gateway API का समर्थन करने की योजना नहीं बना रहा है (Gateway API Implementation Status), जबकि APISIX Ingress पहले से ही Gateway API के अधिकांश फीचर्स का समर्थन करता है: जिसमें HTTPRoute, TCPRoute, TLSRoute, UDPRoute, आदि शामिल हैं।

सारांश

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

Ingress NGINX अपनी सरलता और उपयोग में आसानी के लिए जाना जाता है, लेकिन इसमें कुछ स्पष्ट कमियां हैं, जैसे फीचर्स को एक्सटेंड करने में कठिनाई। APISIX Ingress, जो बाद में शामिल हुआ, ने NGINX के हॉट रीलोडिंग दर्द बिंदु को हल किया और बेहतर एक्स्टेंसिबिलिटी और कार्यक्षमता प्रदान की। उदाहरण के लिए, Gateway API और CRD का समर्थन करने से Ingress कंट्रोलर की क्षमताओं को परियोजना विकास के संदर्भ में समृद्ध किया गया है।

संक्षेप में, यदि आप अधिक समृद्ध फीचर्स और बेहतर एक्स्टेंसिबिलिटी वाला Ingress कंट्रोलर चुनना चाहते हैं, तो APISIX Ingress की दृढ़ता से सिफारिश की जाती है। यदि आप Ingress कंट्रोलर के लिए नए हैं और आपके पास अधिक कार्यात्मक आवश्यकताएं नहीं हैं, तो Ingress NGINX भी अप

Tags: