जियाकाओबाओडियन ने APISIX Ingress Controller को क्यों चुना

Qiang Zeng

September 29, 2022

Case Study

Kubernetes (संक्षिप्त में K8s) की प्रचलितता के साथ, हमारे पास आधिकारिक डिफ़ॉल्ट NGINX Ingress Controller के अलावा और भी विकल्प हैं, और Apache APISIX Ingress Controller भी कई कंपनियों के लिए एक लोकप्रिय विकल्प बन गया है। अधिक से अधिक कंपनियां धीरे-धीरे अपने Ingress Controller को APISIX Ingress Controller से बदल रही हैं।

पृष्ठभूमि

वुहान मुकांग टेक्नोलॉजी कंपनी लिमिटेड की स्थापना 2011 में हुई थी, और इसके मुख्य उत्पाद जियाकाओबाओडियन जैसे दर्जनों कार एप्लिकेशन हैं। 10 साल से अधिक समय से स्थापित होने के बाद, कंपनी ने प्रौद्योगिकी के रुझान का अनुसरण किया और 2019 में क्लाउड-नेटिव को अपनाना शुरू किया, और कंपनी में विभिन्न परियोजनाएं Kubernetes पर शुरू हुईं।

लेकिन उस समय, जैसे ही K8s उभरा था, ट्रैफ़िक प्रवेश पोर्टल्स के लिए कम विकल्प थे। इसलिए, हमने लगभग 4 साल तक डिफ़ॉल्ट Ingress Controller – NGINX Ingress Controller – का उपयोग किया। हालांकि, उस अवधि के दौरान, यह स्पष्ट हो गया कि NGINX Ingress Controller अब हमारी आवश्यकताओं को पूरा नहीं कर सकता था, जिससे हमें एक नया चयन करने के लिए मजबूर होना पड़ा। मुख्यधारा के Ingress Controllers की तुलना करने के बाद, हमने कंपनी के प्रवेश गेटवे के रूप में Apache APISIX का उपयोग करने का निर्णय लिया।

NGINX Ingress Controller की समस्या

कंपनी में सेवाएं HTTP प्रोटोकॉल और TCP प्रोटोकॉल का उपयोग करती हैं, और केवल ऑपरेशन और रखरखाव इंजीनियर ही जानते हैं कि NGINX Ingress Controller के माध्यम से TCP प्रॉक्सी को कैसे कॉन्फ़िगर किया जाए। हालांकि, ऑपरेशन और रखरखाव की मानवशक्ति सीमित है। यह सबसे अच्छा होगा कि हम कुछ बुनियादी NGINX ऑपरेशन और कॉन्फ़िगरेशन को डेवलपमेंट टीम को सौंप दें, ताकि ऑपरेशन और रखरखाव की लागत बचाई जा सके।

इसके अलावा, हमें निम्नलिखित समस्याओं का सामना करना पड़ा:

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

इन कारणों से, हमने अपने पूर्व Ingress Controller को एक नए से बदलने का निर्णय लिया।

APISIX Ingress Controller क्यों

हमने Apache APISIX और अन्य Ingress Controllers की जांच की, उनकी प्रदर्शन, उपयोग में आसानी, विस्तारणीयता और प्लेटफ़ॉर्म एकीकरण के संदर्भ में तुलना की, और अंत में APISIX Ingress Controller को K8s ट्रैफ़िक प्रवेश गेटवे के रूप में चुना, निम्नलिखित कारणों से।

  • अच्छी विस्तारणीयता;
  • कॉन्फ़िगरेशन हॉट-लोडिंग का समर्थन;
  • उच्च प्रदर्शन;
  • बहुत सारे प्लगइन्स;
  • स्व-विकसित कंटेनर प्लेटफ़ॉर्म के साथ एकीकरण के लिए CRD का समर्थन।

समग्र आर्किटेक्चर

यह कहने के बाद, आइए पूरे गेटवे आर्किटेक्चर पर एक नज़र डालें। एक वास्तविक व्यावसायिक परिदृश्य में, उपयोगकर्ता पहले ट्रैफ़िक को SLB (सर्वर लोड बैलेंसर) के माध्यम से फॉरवर्ड करेंगे, और जब ट्रैफ़िक K8s में प्रवेश करता है, तो प्रत्येक सेवा को APISIX क्लस्टर के माध्यम से आमंत्रित किया जाएगा। हम गेटवे साइड पर कई सामान्य कार्य (कैनरी रिलीज़, फ्लो कंट्रोल, API सर्किट ब्रेकिंग, ट्रैफ़िक सुरक्षा नियंत्रण, अनुरोध/प्रतिक्रिया ट्रैफ़िक नियंत्रण, आदि) को लागू करते हैं ताकि सेवाओं का एकीकृत प्रबंधन किया जा सके, व्यवसाय की जटिलता को कम किया जा सके और लागत बचाई जा सके।

आर्किटेक्चर डायग्राम

तैनाती विधि

हमारा व्यवसाय विभिन्न क्लाउड प्लेटफ़ॉर्म (हुआवेई क्लाउड, टेनसेंट क्लाउड, अलीबाबा क्लाउड) पर तैनात है, और हम APISIX Ingress Controller द्वारा समर्थित Helm Chart के माध्यम से अपने व्यवसाय को तेजी से ऑनलाइन ला सकते हैं। APISIX Ingress Controller का उपयोग करते समय, यदि हमें ऐसी सुविधाएं मिलती हैं जिन्हें सुधारा जा सकता है, तो हम समुदाय को सुविधाओं को अपडेट और पुनरावृत्त करने में मदद करने के लिए PRs भी जमा करते हैं। वास्तविक तैनाती प्रक्रिया में, हमने अपने व्यवसाय की विशेषताओं के अनुसार कुछ कॉन्फ़िगरेशन को अनुकूलित किया, जैसे:

  • K8s के माध्यम से NameSpace बनाएं, APISIX और APISIX Ingress Controller को अलग-अलग NameSpace में तैनात करें, और उत्पाद लाइनों और सेवा महत्व के अनुसार ट्रैफ़िक को अलग करें;
  • APISIX initContainer में Linux TCP कर्नेल पैरामीटर्स को अनुकूलित करें;
  • चूंकि हमें उत्पाद लाइनों और सेवा महत्व के संदर्भ में ट्रैफ़िक को अलग करने की आवश्यकता है, K8s का ClassName जानकारी कॉन्फ़िगर करने की आवश्यकता है।

विभिन्न उत्पाद लाइनों और महत्व के अनुसार ट्रैफ़िक को अलग करके, आप सॉफ़्टवेयर दोषों के कारण होने वाले नुकसान को कम कर सकते हैं।

CRD का उपयोग करके स्व-विकसित कंटेनर प्लेटफ़ॉर्म के साथ एकीकरण

APISIX Ingress Controller वर्तमान में कई CRD संसाधनों का समर्थन करता है, इसलिए हम CRD संसाधनों का उपयोग करके APISIX Ingress Controller को अपने स्वयं के कंटेनर प्लेटफ़ॉर्म के साथ एकीकृत कर सकते हैं। हालांकि, चूंकि APISIX Java Client प्रदान नहीं करता है, हमें K8s द्वारा प्रदान किए गए कोड जनरेशन टूल का उपयोग करके Model जनरेट करने और CustomObjectApi का उपयोग करके CRD को प्रबंधित करने की आवश्यकता है। ApisixRoute ऑब्जेक्ट्स को कंटेनर प्लेटफ़ॉर्म एप्लिकेशन्स के साथ जोड़ा जाता है और कोर ऑब्जेक्ट्स के साथ संरचित किया जाता है, जिससे ऑपरेशन स्टाफ और प्रोजेक्ट मैनेजर्स दोनों कंटेनर प्लेटफ़ॉर्म में ऑपरेशन कर सकते हैं।

अनुप्रयोग परिदृश्य

प्रमाणीकरण

Apache APISIX का उपयोग करने से पहले, हमने Istio गेटवे के आधार पर प्रमाणीकरण लागू किया था, और Apache APISIX पर माइग्रेट करने के बाद, हमने forward-auth प्लगइन का उपयोग करने का चयन किया, जो प्रमाणीकरण और प्राधिकरण लॉजिक को एक बाहरी auth सेवा में स्थानांतरित करता है। उपयोगकर्ता का अनुरोध गेटवे के माध्यम से auth सेवा को फॉरवर्ड किया जाता है, और जब auth सेवा 20x स्थिति के अलावा किसी अन्य स्थिति के साथ प्रतिक्रिया करती है, तो मूल अनुरोध को ब्लॉक कर दिया जाता है और परिणाम को प्रतिस्थापित किया जाता है। इस तरह, यदि प्रमाणीकरण विफल होता है, तो एक कस्टम त्रुटि रिपोर्ट वापस करना या उपयोगकर्ता को प्रमाणीकरण पृष्ठ पर रीडायरेक्ट करना संभव है।

जब एक क्लाइंट किसी एप्लिकेशन को अनुरोध भेजता है, तो यह पहले APISIX के forward-auth प्लगइन द्वारा संसाधित होता है, और अनुरोध forward-auth के माध्यम से एक बाहरी प्रमाणीकरण सेवा को फॉरवर्ड किया जाता है, और परिणाम अंत में APISIX गेटवे को वापस किया जाता है। यदि प्रमाणीकरण सफल होता है, तो क्लाइंट सेवा को सामान्य रूप से अनुरोध कर सकता है। यदि प्रमाणीकरण विफल होता है, तो एक त्रुटि कोड वापस किया जाता है।

फ्लो कंट्रोल

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

इसलिए, हम APISIX के limit-conn, limit-req, और limit-count प्लगइन्स का उपयोग करके अनुरोधों को सीमित करते हैं और एवलांच ब्रेकडाउन को रोकते हैं। प्लगइन्स को संशोधित करके फ्लो और गति को सीमित करना आसान है, और APISIX हॉट-लोडिंग मैकेनिज्म के कारण, प्लगइन्स को कॉन्फ़िगर करते समय उन्हें रीस्टार्ट करने की आवश्यकता नहीं होती है, इसलिए वे तुरंत प्रभावी हो जाते हैं। ट्रैफ़िक को नियंत्रित करके, यह कुछ दुर्भावनापूर्ण हमलों को रोक सकता है और सिस्टम सुरक्षा की रक्षा कर सकता है। हमने K8s प्लेटफ़ॉर्म में HPA (हॉरिजॉन्टल पॉड ऑटोस्केलर) भी लागू किया है, जो स्वचालित रूप से ऊपर और नीचे स्केल करता है जब ट्रैफ़िक की मात्रा बहुत अधिक या बहुत कम होती है, APISIX फ्लो और रेट लिमिटिंग प्लगइन्स के साथ बड़े पैमाने पर ब्रेकडाउन को रोकने के लिए।

अवलोकनीयता

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

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

निष्कर्ष

चूंकि APISIX Ingress Controller अभी लॉन्च हुआ है, इसलिए अभी इतने सारे अनुप्रयोग परिदृश्य नहीं हैं। हम अनुप्रयोग परिदृश्यों को गहराई से खोजते रहेंगे और समुदाय को और अधिक उपयोग उदाहरण प्रदान करेंगे।

अधिक से अधिक टीमें उत्पादन वातावरण में Apache APISIX Ingress Controller का उपयोग कर रही हैं। यदि आप भी APISIX Ingress Controller का उपयोग कर रहे हैं, तो हम आपको समुदाय में अपने उपयोग के मामलों को साझा करने के लिए प्रोत्साहित करते हैं।

Tags: