यह लेख आधुनिक सॉफ़्टवेयर विकास में एप्लिकेशन कंटेनरीकरण पर केंद्रित है, जिसमें क्लाउड प्रदाता का कंटेनर ऑर्केस्ट्रेशन शामिल है। यह हमें अपनी एप्लिकेशन को किसी भी वर्कलोड माँग के अनुसार परिनियोजित करने और डायनेमिक रूप से स्केल करने देता है, वह भी दोहराने योग्य, बनाए रखने योग्य, प्रेक्षणीयता और उच्च उपलब्धता के साथ, लागत-प्रभावी रहते हुए और आपदा पुनर्प्राप्ति प्रदान करते हुए।
\n
संक्षेप में
\n
\n- कंटेनर हमें अपनी एप्लिकेशन को प्लेटफ़ॉर्म से स्वतंत्र, हल्के इमेज के रूप में पैकेज करने देते हैं, जिन्हें तेज़ी से स्पिन-अप और प्रतिलिपि बनाया जा सकता है।
\n- कंटेनर ऑर्केस्ट्रेशन इंजन हमें अप्रत्याशित और बड़े वितरित कंप्यूट वर्कलोड को डायनेमिक रूप से प्रबंधित करने देते हैं।
\n- AWS EKS सबसे लोकप्रिय कंटेनर ऑर्केस्ट्रेटरों में से एक है और अनेक AWS सेवाओं के साथ सघन एकीकरण प्रदान करता है।
\n- Helm चार्ट्स का उपयोग करके केवल एक कमांड में जटिल मशीन लर्निंग या डेटा साइंस Kubernetes एप्लिकेशन परिनियोजित करें।
\n
\n
कंटेनर क्यों?
\n
“क्यों” का उत्तर बिना “क्या” के लगभग असंभव है, इसलिए पहले यह समझते हैं कि कंटेनर किन समस्याओं को हल करने का लक्ष्य रखते हैं और कंटेनर है क्या, ताकि हम “क्यों” का उत्तर दे सकें।
\n
पुराने सॉफ़्टवेयर इंजीनियरिंग मॉडल में डेवलपर अपने स्थानीय मशीनों पर कोड लिखते थे, जिसे फिर टेस्ट वातावरण में परिनियोजित कर भेजा जाता था, और उसके बाद प्रोडक्शन में रिलीज़ किया जाता था। इस मॉडल की समस्या वातावरणों के बीच असंगतियाँ तथा विभिन्न सर्वरों पर चल रही निर्भरताएँ और लाइब्रेरीज़ थीं।
\n
तो, एक एप्लिकेशन जो “मेरी मशीन पर काम करता है” (एक क्लासिक डेवलपर कथन) लक्ष्य वातावरण की तुलना में बहुत अलग संस्करणों की रनटाइम लाइब्रेरीज़ पर निर्भर हो सकता है, जिससे परिनियोजन के बाद अप्रत्याशित व्यवहार हो सकता है।
\n
कंटेनर इसे इस तरह हल करते हैं कि वे कंपाइल्ड कोड, लाइब्रेरीज़, निर्भरताएँ और रनटाइम को एक “इमेज” में पैकेज करके एप्लिकेशन लेयर को पूरी तरह एब्स्ट्रैक्ट कर देते हैं।
\n
फिर कंटेनर इमेज को एक टेम्पलेट की तरह इस्तेमाल किया जा सकता है, जिसे Docker जैसे कंटेनर इंजन द्वारा किसी भी वातावरण में पूर्वानुमेय व्यवहार के साथ तेज़ी से परिनियोजित कर कंटेनर इंस्टेंस के रूप में चलाया जा सके।
\n
अगली समस्याएँ जिन्हें कंटेनर हल करते हैं, वे हैं स्केलेबिलिटी, मेंटेनबिलिटी और लागत-प्रभावशीलता। ऐतिहासिक रूप से, प्रोडक्शन वातावरणों में बहुत सारे (महंगे) हार्डवेयर संसाधन होते थे जिन्हें उच्च-वॉल्यूम या व्यवसाय-महत्वपूर्ण एप्लिकेशन के विशिष्ट उपयोग के लिए अलग-थलग और संरक्षित रखा जाता था। इन महंगे वातावरणों का लगातार प्रबंधन, रखरखाव और पैचिंग आवश्यक होता था।
\n
ऐसी एप्लिकेशन को आवंटित हार्डवेयर की मात्रा को चरम लोड को पूरा करने के लिए अधिकतम होना पड़ता था, पर एप्लिकेशन हमेशा सुसंगत, पूर्वानुमेय उपयोग पैटर्न नहीं दिखातीं। इस कारण ऑफ-पीक समय में बड़ी मात्रा में हार्डवेयर निष्क्रिय पड़ा रहता था।
\n
समाधान है कंटेनर ऑर्केस्ट्रेशन।
\n
चूँकि कंटेनर इमेज प्लेटफ़ॉर्म-स्वतंत्र होती है, इसलिए कंटेनर कंप्यूट संसाधनों को मांग के अनुसार ऊपर-नीचे स्केल किया जा सकता है, किसी भी उपलब्ध सर्वर का उपयोग करते हुए जिसमें कंटेनर इंजन चलाने की क्षमता हो, और इस प्रकार अंतर्निहित सर्वर ऑपरेटिंग सिस्टम का रखरखाव एप्लिकेशन से अलग हो जाता है।
\n
इसका लागत-प्रभावशीलता पर स्पष्ट प्रभाव पड़ता है, क्योंकि यदि हम अपने कंटेनरों का प्रबंधन इस प्रकार करें कि वे वर्तमान माँग को डायनेमिक रूप से पूरा करें, तो हम बेयर मेटल का अधिकतम उपयोग कर रहे होते हैं।
\n
यह व्याख्या एक “ऊँची उड़ान” दृष्टि है; हम अगले खंडों में गहराई में जाएँगे, पर उससे पहले कंटेनरों के कुछ व्यावहारिक उपयोगों पर बात करें।
\n
डेटा साइंस और मशीन लर्निंग के लिए कंटेनर
\n
डेटा साइंस और मशीन लर्निंग की एप्लिकेशन अक्सर अत्यधिक कंप्यूट-इंटेंसिव होती हैं
\n
जिनमें कभी-कभी अप्रत्याशित उपयोग पैटर्न होते हैं और वे विशाल मात्रा में डेटा से निपटती हैं।
\n
ऐसी एप्लिकेशन प्रायः पैरेललाइज़ेशन से लाभान्वित होती हैं, ताकि किसी समस्या को बाँटकर हल किया जा सके और फिर परिणामों को किसी डेटा स्टोर में सुरक्षित रखा जा सके। यह निश्चित रूप से बहुत सरलीकृत चित्रण है, पर तुरंत स्पष्ट है कि ऐसी एप्लिकेशन कंटेनर और कंटेनर ऑर्केस्ट्रेशन के लिए एकदम उपयुक्त हैं!
\n
तो, इन सब जानकारियों से सुसज्जित होकर, अब “कैसे” पर आते हैं। और लेख के अंत में, जब हम Helm पर चर्चा करेंगे, तब हम फिर से डेटा साइंस और मशीन लर्निंग एप्लिकेशन के बीच संबंध पर लौटेंगे और देखेंगे कि कंटेनर ऑर्केस्ट्रेशन इंजन के भीतर कंटेनर के रूप में परिनियोजित जटिल एप्लिकेशन को न्यूनतम प्रयास और कॉन्फ़िगरेशन के साथ कैसे चलाया जा सकता है।
\n
बाज़ार में कई कंटेनर इंजन हैं, लेकिन इस लेख में हम सबसे लोकप्रिय Docker का उपयोग करेंगे। आप हमारे Introduction to Docker ट्यूटोरियल में इस प्लेटफ़ॉर्म से परिचित हो सकते हैं।
\n
वर्चुअल मशीन (VM) बनाम कंटेनर
\n
वर्चुअल मशीनें भौतिक हार्डवेयर को एब्स्ट्रैक्ट करती हैं, हाइपरवाइज़र के माध्यम से एक सर्वर को कई में बाँटती हैं, जिससे कई VM एक ही होस्ट साझा कर सकें। प्रत्येक VM का अपना गेस्ट ऑपरेटिंग सिस्टम (OS) होता है।
\n
कंटेनर एप्लिकेशन लेयर पर एब्स्ट्रैक्शन हैं। एक सर्वर जिसमें कंटेनर इंजन इंस्टॉल है, एक साथ कई कंटेनर चला सकता है जो सभी अंतर्निहित OS को साझा करते हैं। आप हमारे कंटेनराइज़ेशन ट्यूटोरियल में कंटेनरों के बारे में और जान सकते हैं।
\n
यहाँ मुख्य अंतर यह है कि कंटेनर होस्ट OS का उपयोग करते हैं और अपने साथ OS पैकेज करके नहीं आते, जबकि VM में ऐसा होता है। इससे वे बहुत अधिक हल्के हो जाते हैं और तेज़ी से प्रतिलिपि, रन और नष्ट किए जा सकते हैं, जबकि कंटेनरों के बीच सुरक्षा आइसोलेशन और फॉल्ट टॉलरेंस के लाभ बने रहते हैं (यदि कोई कंटेनर क्रैश हो जाए तो अन्य कंटेनरों पर कोई प्रभाव नहीं पड़ता)।
\n
इसका अर्थ बेहतर संसाधन उपयोग भी है, इसलिए समान अंतर्निहित हार्डवेयर विनिर्देशों के साथ एक सिंगल Docker इंजन पर VMs की तुलना में अधिक कंटेनर चलाए जा सकते हैं।
\n
Docker इमेज बनाम कंटेनर
\n
Docker इमेज कॉन्फ़िगरेशन, कोड, निर्भरताएँ और रनटाइम इंजन को पैकेज करती है। इमेज Docker के भीतर कंटेनर इंस्टेंस को प्रतिलिपि बनाने और चलाने के लिए टेम्पलेट की तरह कार्य करती हैं। कोई भी कंटेनर किसी भी ऐसे प्लेटफ़ॉर्म पर चल सकता है जो Docker को सपोर्ट करता है।
\n
कंटेनर ऑर्केस्ट्रेशन
\n
अब जब हमें कंटेनरों के बारे में पता है, हमें उन्हें प्रबंधित करने का तरीका चाहिए। कई ऑर्केस्ट्रेटर उपलब्ध हैं, लेकिन इस लेख में हम AWS क्लाउड में Elastic Kubernetes Service (EKS) के अंतर्गत चल रहे Kubernetes पर ध्यान केंद्रित करेंगे।
\n
EKS द्वारा प्रबंधित कुछ प्रमुख कार्य हैं:
\n
\n- परिनियोजन
\n- स्केलिंग
\n- लोड बैलेंसिंग
\n- मॉनिटरिंग
\n- सर्विस डिस्कवरी
\n- स्वतः-रिकवरी (Self-healing)
\n
\n
AWS सेवाएँ
\n
EKS को समझाने से पहले, हमें कुछ AWS क्लाउड सेवाओं को समझना होगा जो EKS की नींव हैं।
\n
CloudWatch
\n
मॉनिटरिंग और प्रेक्षणीयता सेवा जो लॉग, मेट्रिक्स और इवेंट्स के रूप में डेटा एकत्र करती है।
\n
VPC
\n
Virtual Private Cloud एक तार्किक रूप से पृथक नेटवर्क है जो प्रत्येक AWS खाते के लिए सुरक्षित रूप से संरक्षित और प्रबंधित होता है।
\n
ELB
\n
एक इलास्टिक लोड बैलेंसर एक उच्च उपलब्धता वाला नेटवर्किंग घटक है जो ट्रैफ़िक को कई टार्गेट्स में वितरित कर सकता है।
\n
IAM
\n
Identity and Access Management AWS खातों के लिए सूक्ष्म-स्तरीय एक्सेस नियंत्रण प्रदान करता है।
\n
ECR
\n
Elastic Container Registry पूरी तरह प्रबंधित Docker इमेज कंटेनर रजिस्ट्री है।
\n
EC2
\n
Elastic Cloud Compute (दो C के कारण संक्षिप्त) एक कोर AWS सेवा है जो कई अन्य सेवाओं की नींव है। यह वर्चुअल सर्वर किराये पर लेने की सुविधा देती है जिन पर ग्राहक अपनी एप्लिकेशन चला सकते हैं।
\n
Region
\n
एक भौतिक स्थान जिसके इर्द-गिर्द डेटा सेंटर्स का क्लस्टर किया जा सकता है, उदाहरण के लिए, EU-WEST-1 (आयरलैंड) और EU-WEST-2 (लंदन)।
\n
AZ
\n
Availability Zone एक या अधिक पृथक डेटा सेंटर्स होते हैं जिनकी अपनी रेडंडेंट पावर, नेटवर्किंग और कनेक्टिविटी होती है। एक Region में कई AZ होते हैं।
\n
Route53
\n
एक उच्च उपलब्धता वाली DNS सेवा।
\n
WAF
\n
Web Application Firewall जो सामान्य एक्सप्लॉइट्स और बॉट्स से एप्लिकेशन की रक्षा करने में मदद करता है, जो उपलब्धता को प्रभावित कर सकते हैं, सुरक्षा से समझौता कर सकते हैं या अत्यधिक संसाधन खपा सकते हैं।
\n
Kubernetes की मूल बातें
\n
कभी-कभी Kubernetes को K8s कहा जाता है। ऐसा इसलिए क्योंकि Kubernetes में K और S के बीच आठ अक्षर होते हैं।
\n
क्लस्टर
\n
EKS एक प्रबंधित K8s क्लस्टर प्रोविज़न करेगा। यह सबसे उच्च-स्तरीय घटक है और सभी सेवाओं, नोड्स और पॉड्स के लिए कंटेनर की तरह कार्य करता है।
\n
EKS का CloudWatch, Elastic Container Repository (ECR), IAM, API Gateway, Elastic Load Balancer (ELB), CodePipeline, Secrets Manager, आदि के साथ सघन एकीकरण है।
\n
सबसे बुनियादी उदाहरण लेते हुए, हम ECR में कंटेनर इमेज स्टोर कर सकते हैं और अपनी एप्लिकेशन को EKS द्वारा प्रबंधित और चलाया जा सकता है, जिसे कई Availability Zones में VPC में परिनियोजित किया गया है, और सभी सिस्टम व एप्लिकेशन लॉग CloudWatch पर प्रकाशित होते हैं।
\n
![\"Container]()
\n
मास्टर/कंट्रोल प्लेन
\n
मास्टर नोड K8s का हृदय है और नोड्स का प्रबंधन, मॉनिटरिंग, शेड्यूलिंग और योजना बनाने में मदद करता है। इसके कई उप-घटक होते हैं।
\n
ETCD
\n
यह एक की-वैल्यू स्टोर है जो सभी महत्वपूर्ण क्लस्टर डेटा को टिकाऊ बनाकर रखता है।
\n
Kube scheduler
\n
शेड्यूलर कंटेनरों को नोड्स में परिनियोजित करता है।
\n
Kube controller manager
\n
यह क्लस्टर घटकों की उचित स्थिति सुनिश्चित करता है, यह देखकर कि इच्छित वर्कलोड वास्तविक वर्कलोड के बराबर हो।
\n
API
\n
क्लस्टर के बाहर से सभी इंटरैक्शन K8s API के माध्यम से होते हैं।
\n
![\"Kubernetes]()
\n
नोड्स (वर्कर नोड्स)
\n
एक EKS वर्कर नोड एक EC2 इंस्टेंस होता है। प्रत्येक नोड में कंटेनर चलाने के लिए Docker रनटाइम, मास्टर से और मास्टर को सभी संचार संभालने वाला Kubelet एजेंट, और इंटर-नोड संचार की अनुमति देने वाला K-proxy इंस्टॉल होता है।
\n
नोड्स को CloudWatch के साथ एकीकृत करने के लिए, नोड के IAM रोल में CloudWatchLogsFullAccess पॉलिसी शामिल होनी चाहिए।
\n
![\"Nodes]()
\n
पॉड
\n
पॉड सबसे छोटा परिनियोज्य यूनिट है। यह एक सिंगल एप्लिकेशन कंटेनर के साथ किसी भी आवश्यक साइडकार कंटेनरों को चलाता है। प्रत्येक पॉड क्षणिक होता है और उसका एक विशिष्ट IP पता होगा।
\n
![\"Pod]()
\n
डिप्लॉयमेंट्स और रेप्लिका सेट्स
\n
![\"Deployments]()
\n
एक रेप्लिका सेट लेबल के आधार पर पॉड्स के सेट का प्रबंधन करता है और यह सुनिश्चित करता है कि किसी निर्दिष्ट वर्कलोड के लिए हमेशा एक स्थिर सेट के रनिंग पॉड्स मौजूद हों। यदि कोई पॉड डाउन हो जाता है, तो उसे बहाल करना रेप्लिका सेट का काम है।
\n
डिप्लॉयमेंट्स रेप्लिका सेट्स का प्रबंधन करते हैं। यदि कोई रेप्लिका सेट डाउन हो जाता है, तो उसे बहाल करना डिप्लॉयमेंट का काम है। डिप्लॉयमेंट्स को रोलिंग, रैंप्ड, री-क्रिएट या केनरी के रूप में कॉन्फ़िगर किया जा सकता है (डिप्लॉयमेंट प्रकारों का विवरण इस लेख के दायरे से बाहर है)।
\n
सेवाएँ
\n
इस लेख के उद्देश्य से, हम किसी सेवा को AWS की Application Load Balancer (ALB) से प्रत्यक्ष रूप से मैप मान सकते हैं, जो ELB का एक प्रकार है। इसमें इससे थोड़ा अधिक होता है, लेकिन यह समझना महत्वपूर्ण है कि ALB कौन-कौन से लाभ दे सकता है:
\n
\n- DNS नाम संबद्ध करना
\n- हेल्थ चेक्स
\n- कई AZ में उच्च उपलब्धता
\n- WAF
\n- एक्सेस लॉग्स
\n
\n
किसी सेवा का प्राथमिक कार्य नोड्स/पॉड्स के बीच ट्रैफ़िक वितरित करना है।
\n
कंटेनर स्केलिंग
\n
ASG और EC2
\n
EC2 का एक मुख्य घटक Auto Scaling Group (ASG) है। यह AWS घटक सामान्यतः एक लोड बैलेंसर के पीछे, किसी Region के अंदर कई AZ में, इच्छित वर्कलोड पर EC2 इंस्टेंसों के फ़्लीट को बनाए रखेगा।
\n
CloudWatch मेट्रिक्स स्केल-आउट या स्केल-इन के ट्रिगर प्रदान करते हैं।
\n
इस प्रकार की स्केलिंग को क्षैतिज स्केलिंग कहा जाता है क्योंकि एप्लिकेशन सर्वरों का फ़्लीट ट्रैफ़िक माँगों को पूरा करने के लिए “क्षैतिज” रूप से फैल और सिमट सकता है। एक उदाहरण स्केलिंग नीति सभी इंस्टेंसों को 50% CPU उपयोग से नीचे बनाए रखना हो सकती है। इस स्तर पर, ASG सामान्यतः प्रति AZ समान संख्या में EC2 इंस्टेंस प्रबंधित करने के लिए कॉन्फ़िगर किया जाता है, लेकिन अन्य कॉन्फ़िगरेशन भी उपलब्ध हैं जिन पर चर्चा करना इस लेख के दायरे से बाहर है।
\n
HPA
\n
EC2 स्तर पर स्केलिंग और पॉड स्तर पर स्केलिंग के बीच अंतर करना बहुत महत्वपूर्ण है। Horizontal Pod Autoscaler प्रत्येक नोड के भीतर पॉड्स को स्केल करने के लिए ज़िम्मेदार है। HPA, Metrics Server के माध्यम से एकत्रित K8s मेट्रिक्स का उपयोग करता है (इसे क्लस्टर में इंस्टॉल करना पड़ता है और यह EKS के डिफ़ॉल्ट क्लस्टर डिप्लॉयमेंट का हिस्सा नहीं है) और नोड मेट्रिक्स के आधार पर पॉड्स को स्केल करता है। एक उदाहरण स्केलिंग नीति vCPU उपयोग को 50% पर लक्षित करना हो सकती है।
\n
EKS क्लस्टर ऑटोस्केलर
\n
क्लस्टर ऑटोस्केलिंग के लिए एक ओपन-सोर्स EKS क्लस्टर ऑटोस्केलर का इंस्टॉलेशन आवश्यक होता है, जो AWS ASG के साथ-साथ K8s सेवा को स्केल करने के लिए ज़िम्मेदार है, और ASG बदले में क्लस्टर के लिए प्रोविज़न किए गए भौतिक इंस्टेंसों की स्केलिंग का प्रबंधन करता है।
\n
जब कोई नोड HPA स्केल नीति के आधार पर अपनी अधिकतम क्षमता तक पहुँच जाता है, तो क्लस्टर ऑटोस्केलर एक और EC2 इंस्टेंस बनाएगा और उसे ASG में जोड़ देगा।
\n
पूरी तस्वीर
\n
![\"The]()
\n
स्केलिंग नीतियाँ अत्यधिक लचीली, अनुकूलनशील और कॉन्फ़िगरेबल होती हैं, लेकिन सामान्यतः स्केल-डाउन/इन होने से पहले एक कूल-डाउन अवधि के साथ आती हैं ताकि अनियमित, उतार-चढ़ाव वाले ट्रैफ़िक के कारण अनावश्यक स्केलिंग से बचा जा सके।
\n
यह नोट करना महत्वपूर्ण है कि यदि कोई पॉड अपनी vCPU सीमा से अधिक उपयोग करता है, तो Kubernetes उस पॉड में चल रही एप्लिकेशन को थ्रॉटल करेगा, पर यदि कोई पॉड अपनी मेमोरी सीमा से अधिक उपयोग करता है, तो Kubernetes कंटेनर को रीस्टार्ट करेगा।
\n
लागत अनुकूलन
\n
m5.large इंस्टेंस प्रकार का उपयोग करते हुए इंस्टेंसों के भीतर पॉड्स को प्रतिबंधित करने का एक उदाहरण:
\n
2 * vCPU = 2000m (मिलिकोर)
\n
8 GiB मेमोरी
\n
पॉड संसाधन प्रतिबंध:
\n
\n- आरक्षित vCPU मात्रा, जैसे 500m
\n- vCPU की सीमा, जैसे 1000m
\n- आरक्षित मेमोरी मात्रा, जैसे 256Mi
\n- मेमोरी की सीमा, जैसे 512Mi
\n
\n
प्रेक्षणीयता
\n
EKS रिसोर्स व्यू
\n
क्लस्टर पर चल रहे सभी संसाधन दिखाता है।
\n
![\"EKS]()
\n
CloudWatch Container Insights
\n
\n- मॉनिटर्स
\n- अलार्म्स
\n- Lambda फ़ंक्शंस को ट्रिगर करें
\n- पूर्व-निर्मित डैशबोर्ड और मेट्रिक्स
\n- वन-क्लिक इंस्टॉलेशन
\n
\n
![\"CloudWatch]()
\n
Helm
\n
Helm Kubernetes के लिए एक पैकेज मैनेजर है जो एप्लिकेशन के पैकेजिंग, कॉन्फ़िगरेशन और परिनियोजन को स्वचालित करता है। Helm चार्ट आपको जटिल Kubernetes एप्लिकेशन बनाने, साझा करने, संस्करणित करने और प्रकाशित करने देते हैं।
\n
डेटा साइंस और मशीन लर्निंग के क्षेत्र में कुछ रोचक चार्ट उदाहरण हैं:
\n
\n- Ml-workspace
\n- Mlflow
\n- Tensorflow
\n- Hive
\n- Spark
\n
\n
इन K8s एप्लिकेशनों को आपके EKS क्लस्टर पर Helm के माध्यम से एक ही कमांड से परिनियोजित किया जा सकता है!
\n
निष्कर्ष
\n
इस व्यापक मार्गदर्शिका में, हमने AWS Elastic Kubernetes Service (EKS) के साथ कंटेनर ऑर्केस्ट्रेशन के मूल सिद्धांतों की पड़ताल की है। कंटेनरों की मूल बातें और डेटा साइंस व मशीन लर्निंग में उनके वास्तविक-जीवन के उपयोग मामलों को समझने से लेकर AWS सेवाओं और Kubernetes घटकों की बारीकियों में गहराई तक जाने तक, हमने बहुत कुछ कवर किया है। कंटेनर ऑर्केस्ट्रेशन की दुनिया जटिल है, पर बेहद फलदायी है—जो स्केलेबिलिटी, मेंटेनबिलिटी और लागत-प्रभावशीलता प्रदान करती है।
\n
चाहे आप डेवलपर हों, डेटा साइंटिस्ट हों या आईटी प्रोफेशनल, कंटेनर ऑर्केस्ट्रेशन में महारत आपके टूलकिट में निस्संदेह एक मूल्यवान कौशल होगी। जैसे-जैसे व्यवसाय क्लाउड-आधारित समाधानों की ओर पलायन करते हैं और माइक्रोसर्विस आर्किटेक्चर अपनाते हैं, इन क्षेत्रों में विशेषज्ञता वाले पेशेवरों की माँग और बढ़ेगी।
\n
क्या आप अपने ज्ञान को व्यवहार में उतारने के लिए तैयार हैं? DataCamp ऐसे कई कोर्स प्रदान करता है जो Kubernetes, Docker और क्लाउड कंप्यूटिंग की आपकी समझ को और गहरा कर सकते हैं। शुरुआती से उन्नत स्तर तक, आपको इंटरैक्टिव पाठ, वास्तविक-जीवन की चुनौतियाँ और विशेषज्ञ-निर्देशित ट्यूटोरियल मिलेंगे जो आपके कौशल को निखारेंगे।
\n
\n
उपयोगी लिंक
\n
\n- Kubectl चीट शीट जिसमें सबसे अधिक उपयोग किए जाने वाले कमांड हैं
\n- HPA ट्यूटोरियल HPA समझाता है और आपको प्रबंधित स्केलिंग वाली एप्लिकेशन से होकर कराता है
\n- क्लस्टर ऑटोस्केलर ट्यूटोरियल एक सरल एप्लिकेशन को क्लस्टर ऑटोस्केलिंग के साथ सेटअप और रन करने के लिए
\n- Helm चार्ट्स
\n- AWS प्राइसिंग कैलकुलेटर
\n
यह लेख आधुनिक सॉफ़्टवेयर विकास में एप्लिकेशन कंटेनरीकरण पर केंद्रित है, जिसमें क्लाउड प्रदाता का कंटेनर ऑर्केस्ट्रेशन शामिल है। यह हमें अपनी एप्लिकेशन को किसी भी वर्कलोड माँग के अनुसार परिनियोजित करने और डायनेमिक रूप से स्केल करने देता है, वह भी दोहराने योग्य, बनाए रखने योग्य, प्रेक्षणीयता और उच्च उपलब्धता के साथ, लागत-प्रभावी रहते हुए और आपदा पुनर्प्राप्ति प्रदान करते हुए।
\nसंक्षेप में
\n\n- कंटेनर हमें अपनी एप्लिकेशन को प्लेटफ़ॉर्म से स्वतंत्र, हल्के इमेज के रूप में पैकेज करने देते हैं, जिन्हें तेज़ी से स्पिन-अप और प्रतिलिपि बनाया जा सकता है।
\n- कंटेनर ऑर्केस्ट्रेशन इंजन हमें अप्रत्याशित और बड़े वितरित कंप्यूट वर्कलोड को डायनेमिक रूप से प्रबंधित करने देते हैं।
\n- AWS EKS सबसे लोकप्रिय कंटेनर ऑर्केस्ट्रेटरों में से एक है और अनेक AWS सेवाओं के साथ सघन एकीकरण प्रदान करता है।
\n- Helm चार्ट्स का उपयोग करके केवल एक कमांड में जटिल मशीन लर्निंग या डेटा साइंस Kubernetes एप्लिकेशन परिनियोजित करें।
\n
\nकंटेनर क्यों?
\n“क्यों” का उत्तर बिना “क्या” के लगभग असंभव है, इसलिए पहले यह समझते हैं कि कंटेनर किन समस्याओं को हल करने का लक्ष्य रखते हैं और कंटेनर है क्या, ताकि हम “क्यों” का उत्तर दे सकें।
\nपुराने सॉफ़्टवेयर इंजीनियरिंग मॉडल में डेवलपर अपने स्थानीय मशीनों पर कोड लिखते थे, जिसे फिर टेस्ट वातावरण में परिनियोजित कर भेजा जाता था, और उसके बाद प्रोडक्शन में रिलीज़ किया जाता था। इस मॉडल की समस्या वातावरणों के बीच असंगतियाँ तथा विभिन्न सर्वरों पर चल रही निर्भरताएँ और लाइब्रेरीज़ थीं।
\nतो, एक एप्लिकेशन जो “मेरी मशीन पर काम करता है” (एक क्लासिक डेवलपर कथन) लक्ष्य वातावरण की तुलना में बहुत अलग संस्करणों की रनटाइम लाइब्रेरीज़ पर निर्भर हो सकता है, जिससे परिनियोजन के बाद अप्रत्याशित व्यवहार हो सकता है।
\nकंटेनर इसे इस तरह हल करते हैं कि वे कंपाइल्ड कोड, लाइब्रेरीज़, निर्भरताएँ और रनटाइम को एक “इमेज” में पैकेज करके एप्लिकेशन लेयर को पूरी तरह एब्स्ट्रैक्ट कर देते हैं।
\nफिर कंटेनर इमेज को एक टेम्पलेट की तरह इस्तेमाल किया जा सकता है, जिसे Docker जैसे कंटेनर इंजन द्वारा किसी भी वातावरण में पूर्वानुमेय व्यवहार के साथ तेज़ी से परिनियोजित कर कंटेनर इंस्टेंस के रूप में चलाया जा सके।
\nअगली समस्याएँ जिन्हें कंटेनर हल करते हैं, वे हैं स्केलेबिलिटी, मेंटेनबिलिटी और लागत-प्रभावशीलता। ऐतिहासिक रूप से, प्रोडक्शन वातावरणों में बहुत सारे (महंगे) हार्डवेयर संसाधन होते थे जिन्हें उच्च-वॉल्यूम या व्यवसाय-महत्वपूर्ण एप्लिकेशन के विशिष्ट उपयोग के लिए अलग-थलग और संरक्षित रखा जाता था। इन महंगे वातावरणों का लगातार प्रबंधन, रखरखाव और पैचिंग आवश्यक होता था।
\nऐसी एप्लिकेशन को आवंटित हार्डवेयर की मात्रा को चरम लोड को पूरा करने के लिए अधिकतम होना पड़ता था, पर एप्लिकेशन हमेशा सुसंगत, पूर्वानुमेय उपयोग पैटर्न नहीं दिखातीं। इस कारण ऑफ-पीक समय में बड़ी मात्रा में हार्डवेयर निष्क्रिय पड़ा रहता था।
\nसमाधान है कंटेनर ऑर्केस्ट्रेशन।
\nचूँकि कंटेनर इमेज प्लेटफ़ॉर्म-स्वतंत्र होती है, इसलिए कंटेनर कंप्यूट संसाधनों को मांग के अनुसार ऊपर-नीचे स्केल किया जा सकता है, किसी भी उपलब्ध सर्वर का उपयोग करते हुए जिसमें कंटेनर इंजन चलाने की क्षमता हो, और इस प्रकार अंतर्निहित सर्वर ऑपरेटिंग सिस्टम का रखरखाव एप्लिकेशन से अलग हो जाता है।
\nइसका लागत-प्रभावशीलता पर स्पष्ट प्रभाव पड़ता है, क्योंकि यदि हम अपने कंटेनरों का प्रबंधन इस प्रकार करें कि वे वर्तमान माँग को डायनेमिक रूप से पूरा करें, तो हम बेयर मेटल का अधिकतम उपयोग कर रहे होते हैं।
\nयह व्याख्या एक “ऊँची उड़ान” दृष्टि है; हम अगले खंडों में गहराई में जाएँगे, पर उससे पहले कंटेनरों के कुछ व्यावहारिक उपयोगों पर बात करें।
\nडेटा साइंस और मशीन लर्निंग के लिए कंटेनर
\nडेटा साइंस और मशीन लर्निंग की एप्लिकेशन अक्सर अत्यधिक कंप्यूट-इंटेंसिव होती हैं
\nजिनमें कभी-कभी अप्रत्याशित उपयोग पैटर्न होते हैं और वे विशाल मात्रा में डेटा से निपटती हैं।
\nऐसी एप्लिकेशन प्रायः पैरेललाइज़ेशन से लाभान्वित होती हैं, ताकि किसी समस्या को बाँटकर हल किया जा सके और फिर परिणामों को किसी डेटा स्टोर में सुरक्षित रखा जा सके। यह निश्चित रूप से बहुत सरलीकृत चित्रण है, पर तुरंत स्पष्ट है कि ऐसी एप्लिकेशन कंटेनर और कंटेनर ऑर्केस्ट्रेशन के लिए एकदम उपयुक्त हैं!
\nतो, इन सब जानकारियों से सुसज्जित होकर, अब “कैसे” पर आते हैं। और लेख के अंत में, जब हम Helm पर चर्चा करेंगे, तब हम फिर से डेटा साइंस और मशीन लर्निंग एप्लिकेशन के बीच संबंध पर लौटेंगे और देखेंगे कि कंटेनर ऑर्केस्ट्रेशन इंजन के भीतर कंटेनर के रूप में परिनियोजित जटिल एप्लिकेशन को न्यूनतम प्रयास और कॉन्फ़िगरेशन के साथ कैसे चलाया जा सकता है।
\nबाज़ार में कई कंटेनर इंजन हैं, लेकिन इस लेख में हम सबसे लोकप्रिय Docker का उपयोग करेंगे। आप हमारे Introduction to Docker ट्यूटोरियल में इस प्लेटफ़ॉर्म से परिचित हो सकते हैं।
\nवर्चुअल मशीन (VM) बनाम कंटेनर
\nवर्चुअल मशीनें भौतिक हार्डवेयर को एब्स्ट्रैक्ट करती हैं, हाइपरवाइज़र के माध्यम से एक सर्वर को कई में बाँटती हैं, जिससे कई VM एक ही होस्ट साझा कर सकें। प्रत्येक VM का अपना गेस्ट ऑपरेटिंग सिस्टम (OS) होता है।
\nकंटेनर एप्लिकेशन लेयर पर एब्स्ट्रैक्शन हैं। एक सर्वर जिसमें कंटेनर इंजन इंस्टॉल है, एक साथ कई कंटेनर चला सकता है जो सभी अंतर्निहित OS को साझा करते हैं। आप हमारे कंटेनराइज़ेशन ट्यूटोरियल में कंटेनरों के बारे में और जान सकते हैं।
\nयहाँ मुख्य अंतर यह है कि कंटेनर होस्ट OS का उपयोग करते हैं और अपने साथ OS पैकेज करके नहीं आते, जबकि VM में ऐसा होता है। इससे वे बहुत अधिक हल्के हो जाते हैं और तेज़ी से प्रतिलिपि, रन और नष्ट किए जा सकते हैं, जबकि कंटेनरों के बीच सुरक्षा आइसोलेशन और फॉल्ट टॉलरेंस के लाभ बने रहते हैं (यदि कोई कंटेनर क्रैश हो जाए तो अन्य कंटेनरों पर कोई प्रभाव नहीं पड़ता)।
\nइसका अर्थ बेहतर संसाधन उपयोग भी है, इसलिए समान अंतर्निहित हार्डवेयर विनिर्देशों के साथ एक सिंगल Docker इंजन पर VMs की तुलना में अधिक कंटेनर चलाए जा सकते हैं।
\nDocker इमेज बनाम कंटेनर
\nDocker इमेज कॉन्फ़िगरेशन, कोड, निर्भरताएँ और रनटाइम इंजन को पैकेज करती है। इमेज Docker के भीतर कंटेनर इंस्टेंस को प्रतिलिपि बनाने और चलाने के लिए टेम्पलेट की तरह कार्य करती हैं। कोई भी कंटेनर किसी भी ऐसे प्लेटफ़ॉर्म पर चल सकता है जो Docker को सपोर्ट करता है।
\nकंटेनर ऑर्केस्ट्रेशन
\nअब जब हमें कंटेनरों के बारे में पता है, हमें उन्हें प्रबंधित करने का तरीका चाहिए। कई ऑर्केस्ट्रेटर उपलब्ध हैं, लेकिन इस लेख में हम AWS क्लाउड में Elastic Kubernetes Service (EKS) के अंतर्गत चल रहे Kubernetes पर ध्यान केंद्रित करेंगे।
\nEKS द्वारा प्रबंधित कुछ प्रमुख कार्य हैं:
\n\n- परिनियोजन
\n- स्केलिंग
\n- लोड बैलेंसिंग
\n- मॉनिटरिंग
\n- सर्विस डिस्कवरी
\n- स्वतः-रिकवरी (Self-healing)
\n
\nAWS सेवाएँ
\nEKS को समझाने से पहले, हमें कुछ AWS क्लाउड सेवाओं को समझना होगा जो EKS की नींव हैं।
\nCloudWatch
\nमॉनिटरिंग और प्रेक्षणीयता सेवा जो लॉग, मेट्रिक्स और इवेंट्स के रूप में डेटा एकत्र करती है।
\nVPC
\nVirtual Private Cloud एक तार्किक रूप से पृथक नेटवर्क है जो प्रत्येक AWS खाते के लिए सुरक्षित रूप से संरक्षित और प्रबंधित होता है।
\nELB
\nएक इलास्टिक लोड बैलेंसर एक उच्च उपलब्धता वाला नेटवर्किंग घटक है जो ट्रैफ़िक को कई टार्गेट्स में वितरित कर सकता है।
\nIAM
\nIdentity and Access Management AWS खातों के लिए सूक्ष्म-स्तरीय एक्सेस नियंत्रण प्रदान करता है।
\nECR
\nElastic Container Registry पूरी तरह प्रबंधित Docker इमेज कंटेनर रजिस्ट्री है।
\nEC2
\nElastic Cloud Compute (दो C के कारण संक्षिप्त) एक कोर AWS सेवा है जो कई अन्य सेवाओं की नींव है। यह वर्चुअल सर्वर किराये पर लेने की सुविधा देती है जिन पर ग्राहक अपनी एप्लिकेशन चला सकते हैं।
\nRegion
\nएक भौतिक स्थान जिसके इर्द-गिर्द डेटा सेंटर्स का क्लस्टर किया जा सकता है, उदाहरण के लिए, EU-WEST-1 (आयरलैंड) और EU-WEST-2 (लंदन)।
\nAZ
\nAvailability Zone एक या अधिक पृथक डेटा सेंटर्स होते हैं जिनकी अपनी रेडंडेंट पावर, नेटवर्किंग और कनेक्टिविटी होती है। एक Region में कई AZ होते हैं।
\nRoute53
\nएक उच्च उपलब्धता वाली DNS सेवा।
\nWAF
\nWeb Application Firewall जो सामान्य एक्सप्लॉइट्स और बॉट्स से एप्लिकेशन की रक्षा करने में मदद करता है, जो उपलब्धता को प्रभावित कर सकते हैं, सुरक्षा से समझौता कर सकते हैं या अत्यधिक संसाधन खपा सकते हैं।
\nKubernetes की मूल बातें
\nकभी-कभी Kubernetes को K8s कहा जाता है। ऐसा इसलिए क्योंकि Kubernetes में K और S के बीच आठ अक्षर होते हैं।
\nक्लस्टर
\nEKS एक प्रबंधित K8s क्लस्टर प्रोविज़न करेगा। यह सबसे उच्च-स्तरीय घटक है और सभी सेवाओं, नोड्स और पॉड्स के लिए कंटेनर की तरह कार्य करता है।
\nEKS का CloudWatch, Elastic Container Repository (ECR), IAM, API Gateway, Elastic Load Balancer (ELB), CodePipeline, Secrets Manager, आदि के साथ सघन एकीकरण है।
\nसबसे बुनियादी उदाहरण लेते हुए, हम ECR में कंटेनर इमेज स्टोर कर सकते हैं और अपनी एप्लिकेशन को EKS द्वारा प्रबंधित और चलाया जा सकता है, जिसे कई Availability Zones में VPC में परिनियोजित किया गया है, और सभी सिस्टम व एप्लिकेशन लॉग CloudWatch पर प्रकाशित होते हैं।
\n![\"Container]()
\nमास्टर/कंट्रोल प्लेन
\nमास्टर नोड K8s का हृदय है और नोड्स का प्रबंधन, मॉनिटरिंग, शेड्यूलिंग और योजना बनाने में मदद करता है। इसके कई उप-घटक होते हैं।
\nETCD
\nयह एक की-वैल्यू स्टोर है जो सभी महत्वपूर्ण क्लस्टर डेटा को टिकाऊ बनाकर रखता है।
\nKube scheduler
\nशेड्यूलर कंटेनरों को नोड्स में परिनियोजित करता है।
\nKube controller manager
\nयह क्लस्टर घटकों की उचित स्थिति सुनिश्चित करता है, यह देखकर कि इच्छित वर्कलोड वास्तविक वर्कलोड के बराबर हो।
\nAPI
\nक्लस्टर के बाहर से सभी इंटरैक्शन K8s API के माध्यम से होते हैं।
\n![\"Kubernetes]()
\nनोड्स (वर्कर नोड्स)
\nएक EKS वर्कर नोड एक EC2 इंस्टेंस होता है। प्रत्येक नोड में कंटेनर चलाने के लिए Docker रनटाइम, मास्टर से और मास्टर को सभी संचार संभालने वाला Kubelet एजेंट, और इंटर-नोड संचार की अनुमति देने वाला K-proxy इंस्टॉल होता है।
\nनोड्स को CloudWatch के साथ एकीकृत करने के लिए, नोड के IAM रोल में CloudWatchLogsFullAccess पॉलिसी शामिल होनी चाहिए।
\n![\"Nodes]()
\nपॉड
\nपॉड सबसे छोटा परिनियोज्य यूनिट है। यह एक सिंगल एप्लिकेशन कंटेनर के साथ किसी भी आवश्यक साइडकार कंटेनरों को चलाता है। प्रत्येक पॉड क्षणिक होता है और उसका एक विशिष्ट IP पता होगा।
\n![\"Pod]()
\nडिप्लॉयमेंट्स और रेप्लिका सेट्स
\n![\"Deployments]()
\nएक रेप्लिका सेट लेबल के आधार पर पॉड्स के सेट का प्रबंधन करता है और यह सुनिश्चित करता है कि किसी निर्दिष्ट वर्कलोड के लिए हमेशा एक स्थिर सेट के रनिंग पॉड्स मौजूद हों। यदि कोई पॉड डाउन हो जाता है, तो उसे बहाल करना रेप्लिका सेट का काम है।
\nडिप्लॉयमेंट्स रेप्लिका सेट्स का प्रबंधन करते हैं। यदि कोई रेप्लिका सेट डाउन हो जाता है, तो उसे बहाल करना डिप्लॉयमेंट का काम है। डिप्लॉयमेंट्स को रोलिंग, रैंप्ड, री-क्रिएट या केनरी के रूप में कॉन्फ़िगर किया जा सकता है (डिप्लॉयमेंट प्रकारों का विवरण इस लेख के दायरे से बाहर है)।
\nसेवाएँ
\nइस लेख के उद्देश्य से, हम किसी सेवा को AWS की Application Load Balancer (ALB) से प्रत्यक्ष रूप से मैप मान सकते हैं, जो ELB का एक प्रकार है। इसमें इससे थोड़ा अधिक होता है, लेकिन यह समझना महत्वपूर्ण है कि ALB कौन-कौन से लाभ दे सकता है:
\n\n- DNS नाम संबद्ध करना
\n- हेल्थ चेक्स
\n- कई AZ में उच्च उपलब्धता
\n- WAF
\n- एक्सेस लॉग्स
\n
\nकिसी सेवा का प्राथमिक कार्य नोड्स/पॉड्स के बीच ट्रैफ़िक वितरित करना है।
\nकंटेनर स्केलिंग
\nASG और EC2
\nEC2 का एक मुख्य घटक Auto Scaling Group (ASG) है। यह AWS घटक सामान्यतः एक लोड बैलेंसर के पीछे, किसी Region के अंदर कई AZ में, इच्छित वर्कलोड पर EC2 इंस्टेंसों के फ़्लीट को बनाए रखेगा।
\nCloudWatch मेट्रिक्स स्केल-आउट या स्केल-इन के ट्रिगर प्रदान करते हैं।
\nइस प्रकार की स्केलिंग को क्षैतिज स्केलिंग कहा जाता है क्योंकि एप्लिकेशन सर्वरों का फ़्लीट ट्रैफ़िक माँगों को पूरा करने के लिए “क्षैतिज” रूप से फैल और सिमट सकता है। एक उदाहरण स्केलिंग नीति सभी इंस्टेंसों को 50% CPU उपयोग से नीचे बनाए रखना हो सकती है। इस स्तर पर, ASG सामान्यतः प्रति AZ समान संख्या में EC2 इंस्टेंस प्रबंधित करने के लिए कॉन्फ़िगर किया जाता है, लेकिन अन्य कॉन्फ़िगरेशन भी उपलब्ध हैं जिन पर चर्चा करना इस लेख के दायरे से बाहर है।
\nHPA
\nEC2 स्तर पर स्केलिंग और पॉड स्तर पर स्केलिंग के बीच अंतर करना बहुत महत्वपूर्ण है। Horizontal Pod Autoscaler प्रत्येक नोड के भीतर पॉड्स को स्केल करने के लिए ज़िम्मेदार है। HPA, Metrics Server के माध्यम से एकत्रित K8s मेट्रिक्स का उपयोग करता है (इसे क्लस्टर में इंस्टॉल करना पड़ता है और यह EKS के डिफ़ॉल्ट क्लस्टर डिप्लॉयमेंट का हिस्सा नहीं है) और नोड मेट्रिक्स के आधार पर पॉड्स को स्केल करता है। एक उदाहरण स्केलिंग नीति vCPU उपयोग को 50% पर लक्षित करना हो सकती है।
\nEKS क्लस्टर ऑटोस्केलर
\nक्लस्टर ऑटोस्केलिंग के लिए एक ओपन-सोर्स EKS क्लस्टर ऑटोस्केलर का इंस्टॉलेशन आवश्यक होता है, जो AWS ASG के साथ-साथ K8s सेवा को स्केल करने के लिए ज़िम्मेदार है, और ASG बदले में क्लस्टर के लिए प्रोविज़न किए गए भौतिक इंस्टेंसों की स्केलिंग का प्रबंधन करता है।
\nजब कोई नोड HPA स्केल नीति के आधार पर अपनी अधिकतम क्षमता तक पहुँच जाता है, तो क्लस्टर ऑटोस्केलर एक और EC2 इंस्टेंस बनाएगा और उसे ASG में जोड़ देगा।
\nपूरी तस्वीर
\n![\"The]()
\nस्केलिंग नीतियाँ अत्यधिक लचीली, अनुकूलनशील और कॉन्फ़िगरेबल होती हैं, लेकिन सामान्यतः स्केल-डाउन/इन होने से पहले एक कूल-डाउन अवधि के साथ आती हैं ताकि अनियमित, उतार-चढ़ाव वाले ट्रैफ़िक के कारण अनावश्यक स्केलिंग से बचा जा सके।
\nयह नोट करना महत्वपूर्ण है कि यदि कोई पॉड अपनी vCPU सीमा से अधिक उपयोग करता है, तो Kubernetes उस पॉड में चल रही एप्लिकेशन को थ्रॉटल करेगा, पर यदि कोई पॉड अपनी मेमोरी सीमा से अधिक उपयोग करता है, तो Kubernetes कंटेनर को रीस्टार्ट करेगा।
\nलागत अनुकूलन
\nm5.large इंस्टेंस प्रकार का उपयोग करते हुए इंस्टेंसों के भीतर पॉड्स को प्रतिबंधित करने का एक उदाहरण:
\n2 * vCPU = 2000m (मिलिकोर)
\n8 GiB मेमोरी
\nपॉड संसाधन प्रतिबंध:
\n\n- आरक्षित vCPU मात्रा, जैसे 500m
\n- vCPU की सीमा, जैसे 1000m
\n- आरक्षित मेमोरी मात्रा, जैसे 256Mi
\n- मेमोरी की सीमा, जैसे 512Mi
\n
\nप्रेक्षणीयता
\nEKS रिसोर्स व्यू
\nक्लस्टर पर चल रहे सभी संसाधन दिखाता है।
\n![\"EKS]()
\nCloudWatch Container Insights
\n\n- मॉनिटर्स
\n- अलार्म्स
\n- Lambda फ़ंक्शंस को ट्रिगर करें
\n- पूर्व-निर्मित डैशबोर्ड और मेट्रिक्स
\n- वन-क्लिक इंस्टॉलेशन
\n
\n![\"CloudWatch]()
\nHelm
\nHelm Kubernetes के लिए एक पैकेज मैनेजर है जो एप्लिकेशन के पैकेजिंग, कॉन्फ़िगरेशन और परिनियोजन को स्वचालित करता है। Helm चार्ट आपको जटिल Kubernetes एप्लिकेशन बनाने, साझा करने, संस्करणित करने और प्रकाशित करने देते हैं।
\nडेटा साइंस और मशीन लर्निंग के क्षेत्र में कुछ रोचक चार्ट उदाहरण हैं:
\n\n- Ml-workspace
\n- Mlflow
\n- Tensorflow
\n- Hive
\n- Spark
\n
\nइन K8s एप्लिकेशनों को आपके EKS क्लस्टर पर Helm के माध्यम से एक ही कमांड से परिनियोजित किया जा सकता है!
\nनिष्कर्ष
\nइस व्यापक मार्गदर्शिका में, हमने AWS Elastic Kubernetes Service (EKS) के साथ कंटेनर ऑर्केस्ट्रेशन के मूल सिद्धांतों की पड़ताल की है। कंटेनरों की मूल बातें और डेटा साइंस व मशीन लर्निंग में उनके वास्तविक-जीवन के उपयोग मामलों को समझने से लेकर AWS सेवाओं और Kubernetes घटकों की बारीकियों में गहराई तक जाने तक, हमने बहुत कुछ कवर किया है। कंटेनर ऑर्केस्ट्रेशन की दुनिया जटिल है, पर बेहद फलदायी है—जो स्केलेबिलिटी, मेंटेनबिलिटी और लागत-प्रभावशीलता प्रदान करती है।
\nचाहे आप डेवलपर हों, डेटा साइंटिस्ट हों या आईटी प्रोफेशनल, कंटेनर ऑर्केस्ट्रेशन में महारत आपके टूलकिट में निस्संदेह एक मूल्यवान कौशल होगी। जैसे-जैसे व्यवसाय क्लाउड-आधारित समाधानों की ओर पलायन करते हैं और माइक्रोसर्विस आर्किटेक्चर अपनाते हैं, इन क्षेत्रों में विशेषज्ञता वाले पेशेवरों की माँग और बढ़ेगी।
\nक्या आप अपने ज्ञान को व्यवहार में उतारने के लिए तैयार हैं? DataCamp ऐसे कई कोर्स प्रदान करता है जो Kubernetes, Docker और क्लाउड कंप्यूटिंग की आपकी समझ को और गहरा कर सकते हैं। शुरुआती से उन्नत स्तर तक, आपको इंटरैक्टिव पाठ, वास्तविक-जीवन की चुनौतियाँ और विशेषज्ञ-निर्देशित ट्यूटोरियल मिलेंगे जो आपके कौशल को निखारेंगे।
\n\n- Introduction to Docker
\n- Machine Learning, Pipelines, Deployment and MLOps Tutorial
\n- AWS Cloud Concepts Course
\n
\nउपयोगी लिंक
\n\n- Kubectl चीट शीट जिसमें सबसे अधिक उपयोग किए जाने वाले कमांड हैं
\n- HPA ट्यूटोरियल HPA समझाता है और आपको प्रबंधित स्केलिंग वाली एप्लिकेशन से होकर कराता है
\n- क्लस्टर ऑटोस्केलर ट्यूटोरियल एक सरल एप्लिकेशन को क्लस्टर ऑटोस्केलिंग के साथ सेटअप और रन करने के लिए
\n- Helm चार्ट्स
\n- AWS प्राइसिंग कैलकुलेटर
\n