🙌🏻 👼🏿 🗓️ कुबेरनेट की उच्च उपलब्धता कैसे सुनिश्चित की जाती है 🍪 👨🏽‍🎤 👩‍👦

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

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

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

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

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

यह प्रकाशन कुबेरनेट की विश्वसनीयता पर केंद्रित है। वह इस बारे में बात करती है कि असफलताओं की उपस्थिति में कुबेरनेट कैसे जवाबदेही बनाए रखता है।

कुबेरनेट्स आर्किटेक्चर

योजना 1. मास्टर और कार्यकर्ता

एक वैचारिक स्तर पर, कुबेरनेट्स घटकों को दो अलग-अलग वर्गों में बांटा गया है: मास्टर घटक और कार्यकर्ता घटक।

चूल्हा के निष्पादन को छोड़कर सब कुछ के प्रबंधन के लिए मास्टर्स जिम्मेदार हैं। विज़ार्ड के घटकों में शामिल हैं:

श्रमिक चूल्हा के निष्पादन के प्रबंधन के लिए जिम्मेदार हैं। उनके पास एक घटक है:

kubelet

श्रमिक तुच्छ रूप से विश्वसनीय हैं: क्लस्टर में किसी भी श्रमिक की अस्थायी या स्थायी विफलता मास्टर या अन्य क्लस्टर श्रमिकों को प्रभावित नहीं करती है। यदि एप्लिकेशन उचित रूप से तैनात किया गया है, तो कुबेरनेट्स (पुनः) योजनाएं और (पुनः) कार्यकर्ता की विफलता से प्रभावित किसी एक को लॉन्च करती हैं।

एकल विज़ार्ड कॉन्फ़िगरेशन

योजना 2. एकल मास्टर के साथ विन्यास

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

इस विन्यास में, कुबेरनेट की जवाबदेही इस पर निर्भर करती है:

एकमात्र मास्टर
श्रमिकों को एक ही मास्टर से जोड़ना।

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

मल्टी-विज़ार्ड कॉन्फ़िगरेशन

योजना 3. कई मास्टर्स के साथ कॉन्फ़िगरेशन

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

इस विन्यास में, कुबेरनेट्स स्वतंत्र हैं:

एकमात्र मास्टर
श्रमिकों को एक ही मास्टर से जोड़ना।

चूंकि इस कॉन्फ़िगरेशन में विफलता का कोई एकल बिंदु नहीं है, इसलिए इसे अत्यधिक सुलभ माना जाता है।

कुबेरनेट्स में नेता और अनुयायी

बहु-विज़ार्ड कॉन्फ़िगरेशन में, कई क्यूब-कंट्रोलर-मैनेजर और क्यूब-शेड्यूलर शामिल होते हैं। यदि दो घटक समान वस्तुओं को संशोधित करते हैं, तो टकराव उत्पन्न हो सकता है।

क्यूब-कंट्रोलर-मैनेजर और क्यूब-शेड्यूलर कुबेरनेट के लिए संभावित संघर्षों से बचने के लिए, " मास्टर-स्लेव " (नेता / अनुयायी) पैटर्न लागू करता है। प्रत्येक समूह एक नेता (या नेता) चुनता है, और समूह के शेष सदस्य अनुयायियों की भूमिका निभाते हैं। किसी भी समय, केवल एक ही नेता सक्रिय है, और अनुयायी निष्क्रिय हैं।

चित्रा 4. विस्तार में निरर्थक तैनाती घटक जादूगर

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

लीड चयन

एक नए नेता को समूह के सदस्यों द्वारा लॉन्च के समय या नेता गिरने की स्थिति में चुना जाता है। लीड - तथाकथित नेता पट्टे के साथ एक सदस्य (वर्तमान में "पट्टे पर" नेता का दर्जा)।

आरेख 5. विज़ार्ड के मास्टर घटक का चयन करने की प्रक्रिया

यह चित्रण क्यूब-कंट्रोलर-मैनेजर और क्यूब-शेड्यूलर के लिए मास्टर चयन प्रक्रिया को दर्शाता है। इस प्रक्रिया का तर्क इस प्रकार है:

' ' , :
-
-

' ' , :
- leader lease
-
- holderIdentity 'self'

अग्रणी ट्रैकिंग

क्यूब-कंट्रोलर-मैनेजर और क्यूब-शेड्यूलर के लिए वर्तमान लीडर स्टेटस स्थायी रूप से कुबेरनेट्स ऑब्जेक्ट स्टोरेज में kube-system नेमस्पेस में एंडपॉइंट ऑब्जेक्ट्स के रूप में संग्रहीत किए जाते हैं। चूंकि दो कुबेरनेट वस्तुओं में एक ही नाम, प्रकार (प्रकार) और एक ही समय में नामस्थान नहीं हो सकते हैं, क्यूब-अनुसूचक के लिए और क्यूब-नियंत्रक-प्रबंधक के लिए केवल एक समापन बिंदु हो सकता है।

kubectl कंसोल उपयोगिता का उपयोग कर डेमो:

 $ kubectl get endpoints -n kube-system NAME ENDPOINTS AGE kube-scheduler <none> 30m kube-controller-manager <none> 30m

समापन बिंदु के क्यूब-शेड्यूलर और क्यूब-कंट्रोलर-मैनेजर स्टोर लीडर की जानकारी एनोटेशन control-plane.alpha.kubernetes.io/leader में- plane.alpha.kubernetes.io/leader:

 $ kubectl describe endpoints kube-scheduler -n kube-system Name: kube-scheduler Annotations: control-plane.alpha.kubernetes.io/leader= { "holderIdentity": "scheduler-2", "leaseDurationSeconds": 15, "acquireTime": "2018-01-01T08:00:00Z" "renewTime": "2018-01-01T08:00:30Z" }

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

स्प्लिट ब्रेन टॉपिक और संभावित समाधानों की एक शिक्षाप्रद चर्चा मार्टिन क्लेपमैन की हाउ टू डिस्ट्रीब्यूटेड लॉकिंग आर्टिकल में मिल सकती है।

कुबेरनेट्स किसी भी विभाजित मस्तिष्क काउंटरमेशर्स का उपयोग नहीं करते हैं। इसके बजाय, वह समय के साथ वांछित स्थिति के लिए प्रयास करने की अपनी क्षमता पर निर्भर करता है, जो संघर्ष के निर्णयों के परिणामों को कम करता है।

निष्कर्ष

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

ऑपरेशन के लिए कुबेरनेट्स उच्च उपलब्धता क्लस्टर कैसे तैयार करें, इसकी जानकारी के लिए, आधिकारिक दस्तावेज देखें ।

प्रकाशन के बारे में

यह पोस्ट कुबेरनेट्स और इसके अंतर्निहित अवधारणाओं की समझ में सुधार के लिए सीएनसीएफ, Google और एसएपी द्वारा एक संयुक्त पहल का हिस्सा है।

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

" कुबेरनेट्स में क्यूब-प्रॉक्सी और होस्ट की अयोग्यता के साथ प्रयोग ";
" कुबेरनेट की विश्वसनीयता में सुधार: कैसे जल्दी से नोटिस करने के लिए कि एक नोड गिर गया है ";
"हम कंटेनर भंडारण इंटरफ़ेस (कुबेरनेट्स में और न केवल) को समझते हैं ";
" कुबेरनेट्स पर आरबीएसी को समझना ";
“ कुबेरनेट्स में क्या होता है जब कुबलेटल रन शुरू होता है? भाग 1 ”;
" कुबेरनेट्स अनुसूचक वास्तव में कैसे काम करता है?" ";
" कुबेरनेट्स पर नेटवर्क के दृश्यों के पीछे ";
" छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (वीडियो रिपोर्ट, जिसमें कुबेरनेट्स तकनीकी उपकरण का परिचय शामिल है) ।

कुबेरनेट की उच्च उपलब्धता कैसे सुनिश्चित की जाती है