Kubernetes कार्यकर्ता नोडहरू: धेरै साना वा धेरै ठूलाहरू?

Kubernetes क्लस्टर सिर्जना गर्दा, प्रश्नहरू उठ्न सक्छन्: कति कार्यकर्ता नोडहरू कन्फिगर गर्न र कस्तो प्रकार? अन-प्रिमिस क्लस्टरको लागि के राम्रो छ: धेरै शक्तिशाली सर्भरहरू किन्नुहोस् वा तपाईंको डाटा केन्द्रमा एक दर्जन पुराना मेसिनहरू प्रयोग गर्नुहोस्? क्लाउडमा आठ एकल-कोर वा दुई क्वाड-कोर उदाहरणहरू लिनु राम्रो हो?

यी प्रश्नहरूको जवाफ लेखमा छन्। डेनियल Weibel, सफ्टवेयर इन्जिनियर र Learnk8s शैक्षिक परियोजना को शिक्षक आदेश को अनुवाद मा Kubernetes aaS Mail.ru बाट.

क्लस्टर क्षमता

सामान्यतया, एक Kubernetes क्लस्टर ठूलो "सुपरनोड" को रूपमा सोच्न सकिन्छ। यसको कुल कम्प्युटिङ पावर यसको सबै घटक नोडहरूको शक्तिहरूको योग हो।

तपाईंको इच्छित क्लस्टर क्षमता लक्ष्य हासिल गर्न धेरै तरिकाहरू छन्। उदाहरणका लागि, हामीलाई 8 प्रोसेसर कोर र 32 GB RAM को कुल क्षमता भएको क्लस्टर चाहिन्छ किनभने अनुप्रयोगहरूको सेटलाई धेरै स्रोतहरू चाहिन्छ। त्यसपछि तपाईंले १६ जीबी मेमोरी भएका दुई नोडहरू वा ८ जीबी मेमोरी भएका चार नोडहरू, दुई क्वाड-कोर प्रोसेसर वा चार डुअल-कोरहरू स्थापना गर्न सक्नुहुन्छ।

यहाँ क्लस्टर सिर्जना गर्न दुई सम्भावित तरिकाहरू छन्:

दुबै विकल्पहरूले समान क्षमताको साथ क्लस्टर उत्पादन गर्दछ, तर तलको कन्फिगरेसनमा चार साना नोडहरू छन् र शीर्ष कन्फिगरेसनमा दुई ठूला नोडहरू छन्।

कुन विकल्प राम्रो छ?

यस प्रश्नको जवाफ दिनको लागि, हामी दुवै विकल्पहरूको फाइदाहरू हेरौं। हामीले तिनीहरूलाई तालिकामा संक्षेप गरेका छौं।

धेरै ठूला नोडहरू

धेरै साना नोडहरू

सजिलो क्लस्टर व्यवस्थापन (यदि यो आधारमा छ)

चिकनी स्वत: स्केलिंग

सस्तो (यदि आधारमा)

मूल्य थोरै फरक छ (क्लाउडमा)

संसाधन-गहन अनुप्रयोगहरू चलाउन सक्छ

पूर्ण प्रतिकृति

संसाधनहरू अधिक कुशलतापूर्वक प्रयोग गरिन्छ (प्रणाली डेमनहरूमा कम ओभरहेड
उच्च क्लस्टर दोष सहिष्णुता

कृपया ध्यान दिनुहोस् कि हामी केवल कार्यकर्ता नोडहरूको बारेमा कुरा गर्दैछौं। मुख्य नोडहरूको संख्या र साइज छनोट गर्नु एकदम फरक विषय हो।

त्यसोभए, तालिकाबाट प्रत्येक बिन्दुलाई थप विस्तारमा छलफल गरौं।

पहिलो विकल्प: धेरै ठूला नोडहरू

सबैभन्दा चरम विकल्प सम्पूर्ण क्लस्टर क्षमताको लागि एक कार्यकर्ता नोड हो। माथिको उदाहरणमा, यो 16 CPU कोर र 16 GB RAM भएको एकल कार्यकर्ता नोड हुनेछ।

Плюсы

प्लस नम्बर १. सजिलो व्यवस्थापन
पूरै फ्लीट भन्दा केही मेसिनहरू व्यवस्थापन गर्न सजिलो छ। अपडेट र फिक्सहरू रोल आउट गर्न यो छिटो छ, र यसलाई सिङ्क्रोनाइज गर्न सजिलो छ। निरपेक्ष संख्यामा असफल हुने संख्या पनि कम छ।

कृपया ध्यान दिनुहोस् कि माथिका सबै तपाइँको हार्डवेयर, तपाइँको सर्भरहरूमा लागू हुन्छ, क्लाउड उदाहरणहरूमा होइन।

बादलको अवस्था फरक छ। त्यहाँ, क्लाउड सेवा प्रदायक द्वारा व्यवस्थापन गरिन्छ। यसरी, क्लाउडमा दस नोडहरू प्रबन्ध गर्नु एउटा नोड प्रबन्ध गर्नु भन्दा धेरै फरक छैन।

क्लाउडमा पोडहरू बीच ट्राफिक मार्ग र लोड वितरण स्वचालित रूपमा प्रदर्शन: इन्टरनेटबाट आउने ट्राफिकलाई मुख्य लोड ब्यालेन्सरमा पठाइन्छ, जसले ट्राफिकलाई एउटा नोडको पोर्टमा फर्वार्ड गर्छ (नोडपोर्ट सेवाले प्रत्येक क्लस्टर नोडमा 30000-32767 दायरामा पोर्ट सेट गर्दछ)। kube-proxy द्वारा सेट गरिएको नियमहरू नोडबाट पोडमा ट्राफिक रिडिरेक्ट गर्दछ। यहाँ दुई नोडहरूमा दस पोडहरूको लागि कस्तो देखिन्छ:

प्रो #2: प्रति नोड कम लागत
एक शक्तिशाली कार अधिक महँगो छ, तर मूल्य वृद्धि आवश्यक रैखिक छैन। अर्को शब्दमा, 10 GB मेमोरी भएको एक दस-कोर सर्भर सामान्यतया मेमोरीको समान मात्रा भएको दस एकल-कोर सर्भरहरू भन्दा सस्तो हुन्छ।

तर ध्यान दिनुहोस् कि यो नियम सामान्यतया क्लाउड सेवाहरूमा काम गर्दैन। सबै प्रमुख क्लाउड प्रदायकहरूको हालको मूल्य निर्धारण योजनाहरूमा, मूल्यहरू क्षमतासँगै रैखिक रूपमा बढ्छन्।

यसैले, क्लाउडमा तपाइँ सामान्यतया अधिक शक्तिशाली सर्भरहरूमा बचत गर्न सक्नुहुन्न।

प्रो #3: तपाईं संसाधन-गहन अनुप्रयोगहरू चलाउन सक्नुहुन्छ
केही अनुप्रयोगहरूलाई क्लस्टरमा शक्तिशाली सर्भरहरू चाहिन्छ। उदाहरणका लागि, यदि मेसिन लर्निङ प्रणालीलाई ८ GB मेमोरी चाहिन्छ भने, तपाईंले यसलाई १ GB नोडहरूमा चलाउन सक्नुहुने छैन, तर कम्तीमा एउटा ठूलो कार्यकर्ता नोडसँग मात्र।

Минусы

हानि नम्बर १. प्रति नोड धेरै पोडहरू
यदि एउटै कार्य कम नोडहरूमा प्रदर्शन गरिएको छ भने, तिनीहरूमध्ये प्रत्येकमा स्वाभाविक रूपमा धेरै पोडहरू हुनेछन्।

यो समस्या हुन सक्छ।

कारण यो हो कि प्रत्येक मोड्युलले कन्टेनर रनटाइम (जस्तै डकर), साथै कुबेलेट र सीएडभाइजरमा केही ओभरहेड परिचय गराउँछ।

उदाहरणका लागि, क्युबलेटले नियमित रूपमा नोडमा भएका सबै कन्टेनरहरू बाँच्नको लागि जाँच गर्छ—जति धेरै कन्टेनरहरू, क्युबलेटले त्यति धेरै काम गर्नुपर्छ।

CAdvisor ले नोडमा भएका सबै कन्टेनरहरूको लागि स्रोत उपयोग तथ्याङ्कहरू सङ्कलन गर्दछ, र कुबेलेटले नियमित रूपमा यो जानकारी सोध्छ र यसलाई API मार्फत प्रदान गर्दछ। फेरि, थप कन्टेनरहरूको अर्थ cAdvisor र kubelet दुवैका लागि थप काम हो।

यदि मोड्युलहरूको संख्या बढ्छ भने, यसले प्रणालीलाई ढिलो गर्न सक्छ र यसको विश्वसनीयतालाई कमजोर पार्न सक्छ।

Kubernetes भण्डारमा केहि गुनासो गरेत्यो नोडहरू रेडी/नोटरेडी स्थितिहरू बीच उफ्रिन्छ किनभने नोडमा भएका सबै कन्टेनरहरूको नियमित कुबेलेट जाँचले धेरै समय लिन्छ।
यस कारण कुबेरनेट प्रति नोड 110 पोडहरू भन्दा बढी राख्न सिफारिस गर्दछ। नोडको कार्यसम्पादनमा निर्भर गर्दै, तपाइँ प्रति नोडमा धेरै पोडहरू चलाउन सक्नुहुन्छ, तर त्यहाँ समस्याहरू हुनेछ वा सबै ठीक काम गर्नेछ भनेर भविष्यवाणी गर्न गाह्रो छ। यो अग्रिम काम परीक्षण लायक छ।

हानि नम्बर 2. प्रतिकृतिमा सीमितता
धेरै थोरै नोडहरूले अनुप्रयोग प्रतिकृतिको प्रभावकारी हदलाई सीमित गर्दछ। उदाहरणका लागि, यदि तपाईंसँग पाँच प्रतिकृतिहरू तर दुईवटा मात्र नोडहरू भएको उच्च उपलब्धता अनुप्रयोग छ भने, त्यसोभए अनुप्रयोगको प्रतिकृतिको प्रभावकारी डिग्री दुईमा घटाइन्छ।

पाँच प्रतिकृतिहरू मात्र दुई नोडहरूमा वितरण गर्न सकिन्छ, र यदि तिनीहरूमध्ये एउटा असफल भयो भने, यसले एकै पटक धेरै प्रतिकृतिहरू हटाउनेछ।

यदि तपाइँसँग पाँच नोडहरू वा बढी छन् भने, प्रत्येक प्रतिकृति छुट्टै नोडमा चल्नेछ, र एउटा नोडको विफलताले बढीमा एउटा प्रतिकृति हटाउनेछ।

यसैले, उच्च उपलब्धता आवश्यकताहरूलाई क्लस्टरमा नोडहरूको निश्चित न्यूनतम संख्या आवश्यक पर्दछ।

हानि नम्बर 3। असफलताको खराब नतिजा
नोड्स को एक सानो संख्या संग, प्रत्येक विफलता को अधिक गम्भीर परिणामहरु छन्। उदाहरणका लागि, यदि तपाईंसँग केवल दुई नोडहरू छन् र तिनीहरूमध्ये एउटा असफल भयो भने, तपाईंको मोड्युलहरूको आधा तुरुन्तै गायब हुन्छ।

निस्सन्देह, Kubernetes असफल नोडबाट अन्यमा कार्यभार स्थानान्तरण गर्नेछ। तर यदि तिनीहरूमध्ये थोरै छन् भने, त्यहाँ पर्याप्त मुक्त क्षमता नहुन सक्छ। नतिजाको रूपमा, तपाईंले असफल नोड ल्याउनुभएसम्म तपाईंका केही अनुप्रयोगहरू अनुपलब्ध हुनेछन्।

यसरी, जति धेरै नोडहरू, हार्डवेयर विफलताको प्रभाव कम हुन्छ।

हानि # 4: थप स्वत: स्केलिंग चरणहरू
Kubernetes क्लाउड पूर्वाधारको लागि क्लस्टर स्वत: स्केलिंग प्रणाली छ, जसले तपाइँलाई तपाइँको हालको आवश्यकताहरु मा निर्भर गर्दछ स्वचालित रूपमा नोडहरू थप्न वा हटाउन अनुमति दिन्छ। ठूला नोडहरूसँग, स्वत: स्केलिङ् थप अचानक र clunky हुन्छ। उदाहरणको लागि, दुई नोडहरूमा, थप नोड थप्दा तुरुन्तै क्लस्टर क्षमता 50% बढ्नेछ। र तपाईंले ती स्रोतहरूको लागि तिर्नुपर्नेछ, यदि तपाईंलाई तिनीहरूको आवश्यकता छैन भने पनि।

तसर्थ, यदि तपाइँ स्वचालित क्लस्टर स्केलिंग प्रयोग गर्ने योजना बनाउनुहुन्छ भने, नोडहरू जति साना हुन्छन्, त्यति नै लचिलो र लागत-प्रभावी स्केलिंग तपाईंले पाउनुहुनेछ।

अब ठूलो संख्यामा साना नोडहरूका फाइदाहरू र हानिहरू हेरौं।

दोस्रो विकल्प: धेरै साना नोडहरू

यस दृष्टिकोणका फाइदाहरू अनिवार्य रूपमा धेरै ठूला नोडहरूको साथ विपरीत विकल्पको हानिबाट उत्पन्न हुन्छन्।

Плюсы

प्रो #1: असफलताको कम प्रभाव
जति धेरै नोडहरू, प्रत्येक नोडमा कम पोडहरू। उदाहरणका लागि, यदि तपाइँसँग प्रति दस नोडहरू सय मोड्युलहरू छन् भने, त्यसपछि प्रत्येक नोडमा दस मोड्युलहरूको औसत हुनेछ।

यस तरिकाले, यदि कुनै नोडहरू असफल भएमा, तपाईंले कार्यभारको 10% मात्र गुमाउनुहुन्छ। सम्भावनाहरू छन् कि प्रतिकृतिहरूको सानो संख्या मात्र प्रभावित हुनेछ र समग्र अनुप्रयोग परिचालन रहनेछ।

थप रूपमा, बाँकी नोडहरूसँग असफल नोडको कार्यभार ह्यान्डल गर्न पर्याप्त नि:शुल्क स्रोतहरू हुने सम्भावना हुन्छ, त्यसैले Kubernetes ले पोडहरूलाई स्वतन्त्र रूपमा पुन: तालिका बनाउन सक्छ र तपाइँका अनुप्रयोगहरू तुलनात्मक रूपमा छिटो कार्यात्मक अवस्थामा फर्किनेछन्।

प्रो #2: राम्रो प्रतिकृति
यदि त्यहाँ पर्याप्त नोडहरू छन् भने, Kubernetes अनुसूचकले सबै प्रतिकृतिहरूमा विभिन्न नोडहरू तोक्न सक्छ। यस तरिकाले, यदि नोड असफल भयो भने, केवल एउटा प्रतिकृति प्रभावित हुनेछ र अनुप्रयोग उपलब्ध रहनेछ।

Минусы

बेफाइदा नम्बर १. नियन्त्रण गर्न गाह्रो
ठूलो संख्यामा नोडहरू व्यवस्थापन गर्न गाह्रो हुन्छ। उदाहरणका लागि, प्रत्येक Kubernetes नोडले अरू सबैसँग सञ्चार गर्नुपर्छ, अर्थात् जडानहरूको सङ्ख्या चौथो रूपमा बढ्छ, र यी सबै जडानहरू ट्र्याक गर्न आवश्यक छ।

Kubernetes कन्ट्रोलर प्रबन्धकमा नोड नियन्त्रक नियमित रूपमा स्वास्थ्य जाँच गर्न क्लस्टरमा सबै नोडहरू मार्फत हिंड्छ - धेरै नोडहरू, नियन्त्रकमा अधिक लोड।

etcd डाटाबेसमा लोड पनि बढ्दै छ - प्रत्येक kubelet र kube-proxy कलहरू दर्शक etcd को लागि (एपीआई मार्फत), जसमा etcd ले वस्तु अद्यावधिकहरू प्रसारण गर्नुपर्छ।

सामान्यतया, प्रत्येक कार्यकर्ता नोडले मास्टर नोडहरूको प्रणाली कम्पोनेन्टहरूमा अतिरिक्त भार लगाउँछ।

Kubernetes आधिकारिक रूपमा क्लस्टरहरूको साथ समर्थन गर्दछ 5000 सम्म नोडहरूको संख्या। यद्यपि, व्यवहारमा त्यहाँ पहिले नै 500 नोडहरू छन् मामूली समस्या निम्त्याउन सक्छ.

कार्यकर्ता नोडहरूको ठूलो संख्या व्यवस्थापन गर्न, तपाईंले थप शक्तिशाली मास्टर नोडहरू छनौट गर्नुपर्छ। उदाहरणका लागि, कुबे-अप स्वचालित रूपमा स्थापना हुन्छ कार्यकर्ता नोडहरूको संख्यामा आधारित मास्टर नोडको लागि सही VM आकार। अर्थात्, जति धेरै कार्यकर्ता नोडहरू, मास्टर नोडहरू बढी उत्पादक हुनुपर्छ।

यी विशेष समस्याहरू समाधान गर्न विशेष विकासहरू छन्, जस्तै भर्चुअल कुबलेट। यो प्रणालीले तपाईंलाई प्रतिबन्धहरू बाइपास गर्न र कार्यकर्ता नोडहरूको ठूलो संख्याको साथ क्लस्टरहरू निर्माण गर्न अनुमति दिन्छ।

हानि # 2: अधिक ओभरहेड लागत।
प्रत्येक कार्यकर्ता नोडमा, Kubernetes ले प्रणाली डेमनहरूको सेट चलाउँछ - यसमा कन्टेनर रनटाइम (जस्तै डकर), kube-proxy र kubelet, cAdvisor सहित। तिनीहरू सँगै एक निश्चित मात्रामा स्रोतहरू खपत गर्छन्।

यदि तपाईंसँग धेरै साना नोडहरू छन् भने, प्रत्येक नोडमा यो ओभरहेडको अनुपात ठूलो छ। उदाहरणको लागि, कल्पना गर्नुहोस् कि एकल नोडमा सबै प्रणाली डेमनहरूले 0,1 CPU कोर र 0,1 GB मेमोरी प्रयोग गर्दछ। यदि तपाईंसँग १० GB मेमोरी भएको दस कोर नोड छ भने, डेमनहरूले क्लस्टर क्षमताको १% उपभोग गर्छन्। अर्कोतर्फ, 10 GB मेमोरीको साथ दस एकल-कोर नोडहरूमा, डेमनहरूले क्लस्टर क्षमताको 1% लिनेछन्।

यसरी, कम नोडहरू, अधिक कुशलतापूर्वक पूर्वाधार प्रयोग गरिन्छ।

बेफाइदा नम्बर 3. स्रोतहरूको अकुशल प्रयोग
साना नोडहरूमा, यो हुन सक्छ कि बाँकी संसाधन भागहरू कुनै पनि कार्यभार तोक्न धेरै सानो छन्, त्यसैले तिनीहरू प्रयोग नगरिएका छन्।

उदाहरणका लागि, प्रत्येक पोडलाई 0,75 GB मेमोरी चाहिन्छ। यदि तपाइँसँग दस नोडहरू छन् भने, प्रत्येक 1 GB मेमोरीको साथ, तपाइँ दस पोडहरू चलाउन सक्नुहुन्छ, प्रत्येक नोडलाई 0,25 GB प्रयोग नगरिएको मेमोरीको साथ छोडेर।

यसको मतलब सम्पूर्ण क्लस्टरको मेमोरीको 25% बर्बाद भएको छ।

10 GB मेमोरी भएको ठूलो नोडमा, तपाइँ यी मोड्युलहरू मध्ये 13 चलाउन सक्नुहुन्छ - र त्यहाँ 0,25 GB को एक मात्र प्रयोग नगरिएको टुक्रा हुनेछ।

यस अवस्थामा, मेमोरीको 2,5% मात्र बर्बाद हुन्छ।

यसरी, स्रोतहरू ठूला नोडहरूमा अझ राम्रोसँग प्रयोग गरिन्छ।

धेरै ठूला नोडहरू वा धेरै सानाहरू?

त्यसोभए, कुन राम्रो छ: क्लस्टरमा केही ठूला नोडहरू वा धेरै सानाहरू? सधैं जस्तै, त्यहाँ कुनै स्पष्ट जवाफ छैन। धेरै आवेदन को प्रकार मा निर्भर गर्दछ।

उदाहरणका लागि, यदि एप्लिकेसनलाई १० GB मेमोरी चाहिन्छ भने, ठूला नोडहरू स्पष्ट विकल्प हुन्। र यदि एप्लिकेसनलाई उच्च उपलब्धताको लागि दश गुणा प्रतिकृति आवश्यक छ भने, यो केवल दुई नोडहरूमा प्रतिकृतिहरू राख्ने जोखिमको लायक छैन - त्यहाँ क्लस्टरमा न्यूनतम दस नोडहरू हुनुपर्दछ।

मध्यवर्ती परिस्थितिहरूमा, प्रत्येक विकल्पको फाइदा र बेफाइदाहरूमा आधारित छनोट गर्नुहोस्। सायद केही तर्कहरू अरूको तुलनामा तपाईंको अवस्थासँग बढी सान्दर्भिक छन्।

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

त्यहाँ कुनै एकल नुस्खा छैन, र प्रत्येक अवस्थाको आफ्नै नक्साहरू छन्, र केवल उत्पादनले सत्य देखाउनेछ।

क्लाउड प्लेटफर्म टोली द्वारा तयार अनुवाद Mail.ru क्लाउड समाधान.

Kubernetes को बारे मा अधिक: 25 क्लस्टरहरू प्रबन्ध गर्न र प्रयोग गर्नका लागि उपयोगी उपकरणहरू.

स्रोत: www.habr.com