AISpeech ने k8s Ingress Controller के रूप में NGINX के बजाय Apache APISIX को क्यों चुना

प्रस्तावना

सभी को नमस्कार, मैं AISpeech से जिन वेई हूं, जो कंप्यूटर स्पीच रिकग्निशन और विश्लेषण में विशेषज्ञता वाली एक हाई-टेक कंपनी है, और मैं यहां Apache APISIX को K8s के साथ एकीकृत करने के बारे में बात करने आया हूं, न कि नेटिव इन्ग्रेस के साथ।

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

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

ऊपर दिए गए चित्र से, APISIX-ingress-controller नेटिव इन्ग्रेस के साथ दोहराव लगता है। इस लेख में, हम संक्षेप में समझाएंगे कि हमने नेटिव इन्ग्रेस को क्यों छोड़ दिया और Apache APISIX के आधार पर अपना खुद का इन्ग्रेस कंट्रोलर क्यों बनाया।

इन्ग्रेस क्या है

संक्षेप में, इन्ग्रेस Kubernetes के लिए बाहरी ट्रैफिक को संभालने का एक तरीका है।

इन्ग्रेस किस समस्या को हल करता है

चूंकि Kubernetes क्लस्टर के भीतर सेवाएं वर्चुअल नेटवर्क हैं, बाहरी ट्रैफिक को क्लस्टर के भीतर की सेवाओं तक पहुंचने के लिए कम से कम एक सार्वजनिक आईपी और एक उचित रूप से मैप किया गया पोर्ट की आवश्यकता होती है।

Kubernetes के पास Kubernetes आंतरिक सेवाओं तक पहुंचने के लिए इंटरफेस को एक्सपोज़ करने के कई तरीके (NodePort, LoadBalancer, Ingress, …) हैं। तुलना में, इन्ग्रेस निश्चित रूप से सीमित संख्या में सार्वजनिक आईपी को एक्सपोज़ करके रिवर्स प्रॉक्सी प्राप्त करने का एक अधिक आर्थिक तरीका है।

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

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

Kubernetes नेटिव इन्ग्रेस कंट्रोलर की समस्याएं

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

Kubernetes नेटिव इन्ग्रेस कंट्रोलर का उपयोग करने के बाद, हमने निम्नलिखित समस्याओं को प्रमुख पाया:

1. रीलोडिंग समस्या

   Kubernetes नेटिव इन्ग्रेस को YAML कॉन्फ़िगरेशन फाइलों को इन्ग्रेस कंट्रोलर को पास करने, उन्हें NGINX कॉन्फ़िगरेशन फाइलों में परिवर्तित करने, और फिर रीलोडिंग को ट्रिगर करने के लिए डिज़ाइन किया गया है ताकि कॉन्फ़िगरेशन प्रभावी हो सके।

   यह अस्वीकार्य है, खासकर जब ट्रैफिक लंबे कनेक्शन का उपयोग करता है, जिससे दुर्घटनाएं हो सकती हैं।

   इसके विपरीत, Apache APISIX कॉन्फ़िगरेशन हॉट रीलोडिंग का समर्थन करता है, इसलिए आप किसी भी समय रूट को परिभाषित और संशोधित कर सकते हैं बिना NGINX रीलोड को ट्रिगर किए।

2. एनोटेशन में स्क्रिप्ट लिखना और पैरामीटर भरना

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

   Apache APISIX में, हम प्लगइन कोड के माध्यम से लॉजिक लिख सकते हैं जो एक सरल कॉन्फ़िगरेशन इंटरफेस को एक्सपोज़ करता है जो कॉन्फ़िगरेशन रखरखाव को सुविधाजनक बनाता है और DevOps स्टाफ को स्क्रिप्टिंग के हस्तक्षेप से बचाता है।

3. स्टेटफुल लोड बैलेंसिंग के लिए समर्थन की कमी

   उन्नत लोड बैलेंसिंग पॉलिसीज़ का समर्थन नहीं है, जैसे "सत्र स्थिरता", आदि। Kubernetes एक ऑपरेशन-उन्मुख, कंटेनराइज्ड एप्लिकेशन प्रबंधन प्रणाली है, जो इस तथ्य से संबंधित हो सकता है कि Kubernetes एक स्टेटलेस डिप्लॉयमेंट दृष्टिकोण को बढ़ावा देता है, इसलिए Kubernetes निकट भविष्य में इन विरोधाभासी लोड बैलेंसिंग पॉलिसीज़ का आधिकारिक समर्थन नहीं करेगा। वास्तव में, Google ने पहले से ही इन मुद्दों को हल करने के लिए अपने सर्विस मेश समाधान (Istio) के साथ प्रयास किया है। Istio का आर्किटेक्चर परफेक्ट है, लेकिन प्रदर्शन की कीमत पर, जिसे mixer v2 के साथ हल किया जा सकता है।

   चूंकि Kubernetes स्केलिंग का समर्थन करता है, हम Apache APISIX को अपनी उन्नत लोड बैलेंसिंग आवश्यकताओं को पूरा करने के लिए विस्तारित कर सकते हैं, क्योंकि Apache APISIX न केवल "सत्र स्थिरता" और अन्य लोड बैलेंसिंग को नेटिव रूप से समर्थन करता है, बल्कि बैलेंसर चरण को स्केल करने की क्षमता भी रखता है।

4. डायनामिक वेट

   बिजनेस सेवाओं को अक्सर ट्रैफिक को प्रतिशत के आधार पर नियंत्रित करने की आवश्यकता होती है, जो Kubernetes में एक समस्या बन जाती है।

   हालांकि Kubernetes 1.8 के बाद IPVS (IP वर्चुअल सर्वर) का समर्थन करता है, न तो "kube-proxy" के स्टार्ट पैरामीटर्स और न ही "kube-route" के एनोटेशन Apache APISIX जितना उपयोग में आसान हैं, जो आंतरिक रूप से रूट, सेवा, कंज्यूमर, अपस्ट्रीम, प्लगइन, और अन्य प्रमुख ऑब्जेक्ट्स को एब्स्ट्रैक्ट करता है। ऐसे ऑपरेशन्स के वेट को समायोजित करना स्वाभाविक रूप से समर्थित है, बस "अपस्ट्रीम" के तहत "नोड वेट" को संशोधित करके।

5. लचीली विस्तार क्षमताओं की कमी

   हालांकि इन्ग्रेस को मूल रूप से बाहरी ट्रैफिक को संबोधित करने के लिए डिज़ाइन किया गया था, बाहरी ट्रैफिक के लिए आंतरिक ट्रैफिक से कम मांग नहीं है।

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

   Apache APISIX स्केलेबिलिटी के लिए प्लगइन समर्थन प्रदान करता है, और आधिकारिक प्लगइन्स के अलावा, आप अपनी खुद की विशेषताओं को पूरा करने के लिए कस्टम प्लगइन्स बना सकते हैं।

   ConfigMap और Namespaces के कारण कुछ कॉन्फ़िगरेशन समस्याएं भी हैं, जो हमारे उपयोग के तरीके से संबंधित हैं और सामान्य नहीं हैं, इसलिए मैं यहां उन पर विस्तार से नहीं जाऊंगा।

Apache APISIX इन्ग्रेस कंट्रोलर

Apache APISIX की शक्तिशाली रूटिंग और स्केलिंग क्षमताओं के कारण, इन्ग्रेस के एक कार्यान्वयन के रूप में Apache APISIX का उपयोग करने से उपरोक्त दर्द बिंदुओं को आसानी से हल किया जा सकता है और समुदाय को एक अतिरिक्त इन्ग्रेस कंट्रोलर विकल्प प्रदान किया जा सकता है। टाइमिंग डायग्राम निम्नलिखित है:

Apache APISIX इन्ग्रेस कंट्रोलर को लागू करने के लिए, हमें दो प्रकार की मूलभूत समस्याओं को हल करने की आवश्यकता है: एक है Kubernetes क्लस्टर और Apache APISIX स्थिति के बीच सिंक्रनाइज़ेशन को हल करना; दूसरा है Apache APISIX में ऑब्जेक्ट्स को Kubernetes में परिभाषित करना (CRD)।

Apache APISIX को तेजी से एकीकृत करने और इसका लाभ उठाने के लिए, हमने Apache APISIX इन्ग्रेस कंट्रोलर प्रोजेक्ट बनाया (सभी का स्वागत है), जिसने वर्तमान में पहली प्रकार की मूलभूत समस्या को हल किया है: Kubernetes पॉड जानकारी को Apache APISIX अपस्ट्रीम में सिंक्रनाइज़ करना, जबकि इसकी अपनी उच्च उपलब्धता समस्याओं को हल करने के लिए एक प्राथमिक बैकअप को लागू किया है।

चूंकि Kubernetes क्लस्टर स्थिति को डिक्लेरेटिव रूप से परिभाषित करने के लिए YAML का उपयोग करता है, हमें Apache APISIX में ऑब्जेक्ट्स (रूट/सेवा/अपस्ट्रीम/प्लगइन) के लिए CRD (कस्टम रिसोर्स डेफिनिशन्स) को परिभाषित करने की आवश्यकता है ताकि उन्हें Kubernetes में एकीकृत किया जा सके।

साथ ही, मौजूदा Kubernetes इन्ग्रेस उपयोगकर्ताओं के माइग्रेशन को सुविधाजनक बनाने के लिए, हम मौजूदा इन्ग्रेस कॉन्फ़िगरेशन आइटम्स के साथ संगत होने का प्रयास करेंगे।

ये सुविधाएं हमारे अगले प्रयासों का लक्ष्य होंगी, और हम आपकी भागीदारी का स्वागत करते हैं।