क्लाउड नेटिव में तकनीकी विकास के अवसर और चुनौतियाँ

आजकल, क्लाउड नेटिव तेजी से लोकप्रिय हो रहा है, और CNCF क्लाउड नेटिव को इस प्रकार परिभाषित करता है:

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

CNCF 2021 सर्वेक्षण के अनुसार, Kubernetes समुदाय में बहुत ही महत्वपूर्ण संख्या (62,000 से अधिक) योगदानकर्ता हैं। वर्तमान तकनीकी प्रवृत्ति के साथ, अधिक से अधिक कंपनियां क्लाउड नेटिव में अधिक लागत निवेश कर रही हैं और सक्रिय क्लाउड तैनाती के लिए जल्दी ट्रैक में शामिल हो रही हैं। कंपनियां विकास के दौरान क्लाउड नेटिव को क्यों अपना रही हैं, और उनके लिए क्लाउड नेटिव का क्या अर्थ है?

क्लाउड नेटिव के तकनीकी लाभ

क्लाउड नेटिव की लोकप्रियता तकनीकी स्तर पर इसके लाभों से आती है। क्लाउड नेटिव तकनीक के दो मुख्य पहलू हैं, जिनमें Docker द्वारा नेतृत्व किया गया कंटेनरीकरण, और Kubernetes द्वारा नेतृत्व किया गया कंटेनर ऑर्केस्ट्रेशन शामिल है।

Docker ने तकनीकी दुनिया में कंटेनर इमेज को पेश किया, जिससे कंटेनर इमेज एक मानकीकृत डिलीवरी यूनिट बन गई। वास्तव में, Docker से पहले भी कंटेनरीकरण तकनीक मौजूद थी। आइए 2008 में एक और हालिया तकनीक, LXC (Linux Containers) के बारे में बात करते हैं। Docker की तुलना में, LXC कम लोकप्रिय है क्योंकि Docker कंटेनर इमेज प्रदान करता है, जो अधिक मानकीकृत और माइग्रेट करने में अधिक सुविधाजनक हो सकता है। इसके अलावा, Docker ने DockerHub पब्लिक सर्विस बनाई, जो दुनिया का सबसे बड़ा कंटेनर इमेज रिपॉजिटरी बन गया है। इसके अतिरिक्त, कंटेनरीकरण तकनीक कुछ हद तक संसाधन अलगाव भी प्राप्त कर सकती है, जिसमें न केवल CPU, मेमोरी, और अन्य संसाधन अलगाव शामिल है, बल्कि नेटवर्क स्टैक अलगाव भी शामिल है, जो एक ही मशीन पर एप्लिकेशन के कई कॉपी को तैनात करना आसान बनाता है।

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

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

कंटेनरीकरण के लाभ

1. मानकीकृत डिलीवरी

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

2. पोर्टेबल और हल्का, लागत बचत

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

सभी एप्लिकेशन कर्नेल को साझा कर सकते हैं, जिससे लागत बचती है। और एप्लिकेशन जितना बड़ा होगा, लागत बचत उतनी ही अधिक होगी।

3. संसाधन प्रबंधन की सुविधा

कंटेनर शुरू करते समय, आप CPU, मेमोरी, या डिस्क IO गुणों को सेट कर सकते हैं जो कंटेनर सेवा के लिए उपयोग किए जा सकते हैं, जिससे कंटेनर के माध्यम से एप्लिकेशन इंस्टेंस शुरू करते समय संसाधनों की बेहतर योजना और तैनाती की जा सकती है।

कंटेनर ऑर्केस्ट्रेशन के लाभ

1. वर्कफ्लो को सरल बनाएं

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

2. दक्षता बढ़ाएं और लागत बचाएं

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

Docker और Kubernetes के उदय के साथ, आप देखेंगे कि उनके उदय ने एप्लिकेशन डिलीवरी में बड़ी नवाचार और अवसर लाए हैं। कंटेनर इमेज, मानक डिलीवरी यूनिट के रूप में, डिलीवरी प्रक्रिया को छोटा करते हैं और CI/CD सिस्टम के साथ एकीकरण को आसान बनाते हैं।

यह देखते हुए कि एप्लिकेशन डिलीवरी तेज हो रही है, एप्लिकेशन आर्किटेक्चर क्लाउड नेटिव प्रवृत्ति का अनुसरण कैसे कर रहा है?

एप्लिकेशन आर्किटेक्चर का विकास: मोनोलिथ, माइक्रोसर्विस से सर्विस मेश तक

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

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

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

एक और API गेटवे पैटर्न है, जो क्लस्टर या पूरे माइक्रोसर्विस आर्किटेक्चर के प्रवेश ट्रैफ़िक को एक गेटवे के माध्यम से प्राप्त करता है और API के माध्यम से ट्रैफ़िक वितरण को पूरा करता है। यह सबसे अधिक उपयोग किए जाने वाले पैटर्न में से एक है, और Spring Cloud Gateway या Apache APISIX जैसे गेटवे उत्पाद लागू किए जा सकते हैं।

लोकप्रिय आर्किटेक्चर धीरे-धीरे क्लाउड नेटिव आर्किटेक्चर तक विस्तारित हो रहे हैं। क्या क्लाउड नेटिव के तहत एक माइक्रोसर्विस आर्किटेक्चर मूल माइक्रोसर्विस को एक कंटेनर इमेज के रूप में बना सकता है और इसे सीधे Kubernetes में माइग्रेट कर सकता है?

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

माइग्रेशन प्रक्रिया में व्यावसायिक स्तर पर परिवर्तन और अनुकूलन भी शामिल होता है, जिसमें प्रमाणीकरण, प्राधिकरण, और ऑब्जर्वेबिलिटी-संबंधी क्षमताओं (लॉगिंग, मॉनिटरिंग, आदि) को K8s में माइग्रेट करने की आवश्यकता होती है। इसलिए, मूल भौतिक मशीन तैनाती से K8s प्लेटफॉर्म पर माइग्रेशन इससे कहीं अधिक जटिल है।

इस स्थिति में, हम उपरोक्त परिदृश्य को सरल बनाने के लिए साइडकार मॉडल का उपयोग कर सकते हैं।

आमतौर पर, साइडकार मॉडल साइडकार प्रॉक्सी के रूप में आता है, जो नीचे दिए गए चित्र के बाएं से दाएं तक कुछ सामान्य क्षमताओं (जैसे प्रमाणीकरण, प्राधिकरण, सुरक्षा, आदि) को साइडकार में डूबाकर विकसित होता है। जैसा कि आप चित्र से देख सकते हैं, इस मॉडल को कई घटकों को बनाए रखने की आवश्यकता से केवल दो चीजों (एप्लिकेशन + साइडकार) को बनाए रखने के लिए अनुकूलित किया गया है। साथ ही, साइडकार मॉडल में कुछ सामान्य घटक शामिल होते हैं, इसलिए इसे व्यावसायिक पक्ष द्वारा बनाए रखने की आवश्यकता नहीं होती है, जिससे माइक्रोसर्विस संचार की समस्या आसानी से हल हो जाती है।

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

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

इस समाधान का लाभ यह है कि जब आप पिछले माइक्रोसर्विस आर्किटेक्चर से क्लाउड नेटिव आर्किटेक्चर में माइग्रेट करना चाहते हैं, तो आप सर्विस मेश समाधान का उपयोग करके व्यावसायिक पक्ष पर बड़े पैमाने पर परिवर्तन से बच सकते हैं।

क्लाउड नेटिव की तकनीकी चुनौतियां

पिछले लेख में वर्तमान क्लाउड नेटिव प्रवृत्ति के कुछ लाभों का उल्लेख किया गया था। हालांकि, हर सिक्के के दो पहलू होते हैं। हालांकि कुछ नए तत्व और अवसर लाए जा सकते हैं, लेकिन कुछ तकनीकों की भागीदारी के कारण चुनौतियां भी उत्पन्न होती हैं।

कंटेनरीकरण और K8s के कारण समस्याएं

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

इसके अलावा, हालांकि कंटेनर इमेज एक मानकीकृत डिलीवरी विधि प्रदान करते हैं, लेकिन वे आपूर्ति श्रृंखला हमलों के लिए प्रवण होते हैं।

इसी तरह, K8s का परिचय भी घटक सुरक्षा में चुनौतियां लाया है। घटकों में वृद्धि के कारण हमले की सतह में वृद्धि हुई है, साथ ही अंतर्निहित घटकों और निर्भरता स्तर से संबंधित अतिरिक्त कमजोरियां भी पैदा हुई हैं। इंफ्रास्ट्रक्चर स्तर पर, पारंपरिक भौतिक या वर्चुअल मशीन से K8s में माइग्रेट करने में इंफ्रास्ट्रक्चर परिवर्तन लागत और क्लस्टर डेटा बैकअप, आवधिक अपग्रेड, और प्रमाणपत्र नवीनीकरण करने के लिए अधिक श्रम लागत शामिल होती है।

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

सुरक्षा

नई तकनीकों के उपयोग के लिए सुरक्षा स्तर पर अतिरिक्त ध्यान देने की आवश्यकता होती है:

• नेटवर्क सुरक्षा स्तर पर, नेटवर्क पॉलिसी द्वारा ट्रैफ़िक का सूक्ष्म नियंत्रण लागू किया जा सकता है, या mTLS जैसे अन्य कनेक्शन एन्क्रिप्शन विधियों का उपयोग करके शून्य-विश्वास नेटवर्क बनाया जा सकता है।

• डेटा सुरक्षा स्तर पर, K8s गोपनीय डेटा को संभालने के लिए सीक्रेट संसाधन प्रदान करता है, लेकिन वास्तव में यह सुरक्षित नहीं है। सीक्रेट संसाधन की सामग्री Base64 में एन्कोडेड होती है, जिसका अर्थ है कि आप Base64 डिकोडिंग के माध्यम से सामग्री तक पहुंच सकते हैं, खासकर यदि वे etcd में रखे गए हैं, जिसे etcd तक पहुंच होने पर सीधे पढ़ा जा सकता है।

• अनुमति सुरक्षा स्तर पर, RBAC सेटिंग्स के अनुचित होने की स्थिति भी होती है, जिससे एक हमलावर संबंधित टोकन का उपयोग करके apiserver के साथ संचार करके हमले का उद्देश्य प्राप्त कर सकता है। इस तरह की अनुमति सेटिंग अक्सर कंट्रोलर और ऑपरेटर परिदृश्यों में देखी जाती है।

ऑब्जर्वेबिलिटी

अधिकांश क्लाउड नेटिव परिदृश्यों में कुछ ऑब्जर्वेबिलिटी-संबंधी ऑपरेशन शामिल होते हैं, जैसे लॉगिंग, मॉनिटरिंग, आदि।

K8s में, यदि आप विभिन्न तरीकों से लॉग एकत्र करना चाहते हैं, तो आपको प्रत्येक K8s नोड पर सीधे एकत्र करने की आवश्यकता होती है। यदि लॉग इस तरह से एकत्र किए जाते हैं, तो एप्लिकेशन को मानक आउटपुट या मानक त्रुटियों में निर्यात करने की आवश्यकता होती है।

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

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

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

इसके अलावा, K8s क्लस्टर में एक और स्थिति होती है जहां पूरे क्लस्टर या नोड के संसाधन समाप्त हो जाते हैं, जिससे संसाधन निष्कासन होता है, जिसका अर्थ है कि एक नोड पर चल रहे संसाधनों को अन्य नोड्स पर निष्कासित किया जाता है। यदि क्लस्टर के संसाधन तंग होते हैं, तो एक नोड तूफान आसानी से पूरे क्लस्टर को क्रैश कर सकता है।

एप्लिकेशन विकास और मल्टी-क्लस्टर पैटर्न

एप्लिकेशन आर्किटेक्चर विकास स्तर पर, मुख्य मुद्दा सेवा खोज है।

K8s डिफ़ॉल्ट रूप से एक DNS-आधारित सेवा खोज मैकेनिज्म प्रदान करता है, लेकिन यदि व्यवसाय में क्लाउड व्यवसाय और स्टॉक व्यवसाय का सह-अस्तित्व शामिल है, तो स्थिति से निपटने के लिए DNS सेवा खोज मैकेनिज्म का उपयोग करना अधिक जटिल होगा।

इसी समय, यदि उद्यम क्लाउड नेटिव तकनीक का चयन करते हैं, तो व्यवसाय के पैमाने के विस्तार के साथ, वे धीरे-धीरे मल्टी-नोड प्रसंस्करण की दिशा में विचार करेंगे, जिससे मल्टी-क्लस्टर मुद्दे शामिल होंगे।

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

APISIX डिजिटल परिवर्तन को कैसे सक्षम करता है

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