कुबर्नेट्स वर्कर नोड्स: अनेक लहान किंवा अनेक मोठे?

कुबर्नेट्स क्लस्टर तयार करताना, प्रश्न उद्भवू शकतात: किती वर्कर नोड्स कॉन्फिगर करायचे आणि कोणत्या प्रकारचे? ऑन-प्रिमाइस क्लस्टरसाठी काय चांगले आहे: अनेक शक्तिशाली सर्व्हर खरेदी करा किंवा तुमच्या डेटा सेंटरमध्ये डझनभर जुनी मशीन वापरा? क्लाउडमध्ये आठ सिंगल-कोर किंवा दोन क्वाड-कोर उदाहरणे घेणे चांगले आहे का?

या प्रश्नांची उत्तरे लेखात आहेत. डॅनियल वीबेल, सॉफ्टवेअर अभियंता आणि Learnk8s शैक्षणिक प्रकल्पाचे शिक्षक आदेशाच्या भाषांतरात Mail.ru वरून Kubernetes aaS.

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

सर्वसाधारणपणे, कुबर्नेट्स क्लस्टरचा विचार मोठ्या "सुपरनोड" म्हणून केला जाऊ शकतो. त्याची एकूण संगणकीय शक्ती ही त्याच्या सर्व घटक नोड्सच्या शक्तींची बेरीज आहे.

तुमचे इच्छित क्लस्टर क्षमता लक्ष्य साध्य करण्याचे अनेक मार्ग आहेत. उदाहरणार्थ, आम्हाला 8 प्रोसेसर कोर आणि 32 GB RAM च्या एकूण क्षमतेसह क्लस्टरची आवश्यकता आहे कारण अनुप्रयोगांच्या संचासाठी खूप संसाधने आवश्यक आहेत. त्यानंतर तुम्ही 16 GB मेमरी असलेले दोन नोड्स किंवा 8 GB मेमरी असलेले चार नोड्स, दोन क्वाड-कोर प्रोसेसर किंवा चार ड्युअल-कोअर इन्स्टॉल करू शकता.

क्लस्टर तयार करण्यासाठी येथे फक्त दोन संभाव्य मार्ग आहेत:

दोन्ही पर्याय समान क्षमतेसह क्लस्टर तयार करतात, परंतु तळाच्या कॉन्फिगरेशनमध्ये चार लहान नोड्स असतात आणि वरच्या कॉन्फिगरेशनमध्ये दोन मोठे नोड असतात.

कोणता पर्याय चांगला आहे?

या प्रश्नाचे उत्तर देण्यासाठी, दोन्ही पर्यायांचे फायदे पाहूया. आम्ही त्यांचा सारणीत सारांश दिला आहे.

अनेक मोठे नोड्स

अनेक लहान नोड्स

सुलभ क्लस्टर व्यवस्थापन (जर ते ऑन-प्रिमाइस असेल)

गुळगुळीत ऑटोस्केलिंग

स्वस्त (जर ऑन-प्रिमाइस)

किंमत थोडी वेगळी आहे (क्लाउडमध्ये)

संसाधन-केंद्रित अनुप्रयोग चालवू शकतात

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

संसाधने अधिक कार्यक्षमतेने वापरली जातात (सिस्टम डिमनवर कमी ओव्हरहेड
उच्च क्लस्टर फॉल्ट सहिष्णुता

कृपया लक्षात घ्या की आम्ही फक्त वर्कर नोड्सबद्दल बोलत आहोत. मुख्य नोड्सची संख्या आणि आकार निवडणे हा पूर्णपणे वेगळा विषय आहे.

तर, सारणीतील प्रत्येक मुद्यावर अधिक तपशीलवार चर्चा करूया.

पहिला पर्याय: अनेक मोठे नोड्स

संपूर्ण क्लस्टर क्षमतेसाठी सर्वात टोकाचा पर्याय म्हणजे एक वर्कर नोड. वरील उदाहरणात, हे 16 CPU कोर आणि 16 GB RAM सह एकल वर्कर नोड असेल.

Плюсы

प्लस क्रमांक 1. सुलभ व्यवस्थापन
संपूर्ण ताफ्यापेक्षा काही मशीन व्यवस्थापित करणे सोपे आहे. अद्यतने आणि निराकरणे रोल आउट करणे अधिक जलद आहे आणि समक्रमित करणे सोपे आहे. निरपेक्ष संख्येत नापास होण्याचे प्रमाणही कमी आहे.

कृपया लक्षात घ्या की वरील सर्व गोष्टी तुमच्या हार्डवेअरवर, तुमच्या सर्व्हरला लागू होतात आणि क्लाउड उदाहरणांना लागू होत नाहीत.

ढगात परिस्थिती वेगळी आहे. तेथे, क्लाउड सेवा प्रदात्याद्वारे व्यवस्थापन हाताळले जाते. अशा प्रकारे, क्लाउडमध्ये दहा नोड्स व्यवस्थापित करणे हे एका नोडच्या व्यवस्थापनापेक्षा फारसे वेगळे नाही.

क्लाउडमधील पॉड्स दरम्यान वाहतूक मार्ग आणि लोड वितरण आपोआप केले जाते: इंटरनेटवरून येणारी रहदारी मुख्य लोड बॅलन्सरकडे पाठविली जाते, जी रहदारी एका नोडच्या पोर्टवर पाठवते (नोडपोर्ट सेवा प्रत्येक क्लस्टर नोडमध्ये पोर्ट 30000-32767 श्रेणीमध्ये सेट करते). kube-proxy द्वारे सेट केलेले नियम नोडपासून पॉडपर्यंत रहदारी पुनर्निर्देशित करतात. दोन नोड्सवर दहा पॉड्स कसे दिसतात ते येथे आहे:

प्रो #2: प्रति नोड कमी खर्च
एक शक्तिशाली कार अधिक महाग आहे, परंतु किंमत वाढ रेखीय असणे आवश्यक नाही. दुसऱ्या शब्दांत, 10 GB मेमरी असलेला एक दहा-कोर सर्व्हर सामान्यत: समान प्रमाणात मेमरी असलेल्या दहा सिंगल-कोर सर्व्हरपेक्षा स्वस्त असतो.

परंतु लक्षात घ्या की हा नियम सहसा क्लाउड सेवांमध्ये कार्य करत नाही. सर्व प्रमुख क्लाउड प्रदात्यांच्या सध्याच्या किंमती योजनांमध्ये, किमती क्षमतेनुसार एकरेषाने वाढतात.

अशा प्रकारे, क्लाउडमध्ये आपण सहसा अधिक शक्तिशाली सर्व्हरवर बचत करू शकत नाही.

प्रो #3: तुम्ही संसाधन-केंद्रित अनुप्रयोग चालवू शकता
काही अनुप्रयोगांना क्लस्टरमध्ये शक्तिशाली सर्व्हर आवश्यक असतात. उदाहरणार्थ, जर मशीन लर्निंग सिस्टमला 8 GB मेमरी आवश्यक असेल, तर तुम्ही ती 1 GB नोड्सवर चालवू शकणार नाही, परंतु कमीत कमी एका मोठ्या वर्कर नोडसह.

मिनिन्स

गैरसोय क्रमांक 1. प्रति नोड अनेक शेंगा
जर तेच कार्य कमी नोड्सवर केले गेले, तर त्या प्रत्येकामध्ये नैसर्गिकरित्या जास्त शेंगा असतील.

ही समस्या असू शकते.

याचे कारण असे आहे की प्रत्येक मॉड्यूल कंटेनर रनटाइम (उदा. डॉकर), तसेच कुबेलेट आणि सीएडव्हायझरमध्ये काही ओव्हरहेडचा परिचय देते.

उदाहरणार्थ, कुबेलेट टिकून राहण्यासाठी नोडवरील सर्व कंटेनरची नियमितपणे तपासणी करते—जेवढे कंटेनर जास्त तेवढे कुबेलेटला जास्त काम करावे लागेल.

CAdvisor नोडवरील सर्व कंटेनरसाठी संसाधन वापर आकडेवारी गोळा करतो आणि कुबेलेट नियमितपणे ही माहिती विचारतो आणि ती API द्वारे प्रदान करतो. पुन्हा, अधिक कंटेनर म्हणजे cAdvisor आणि kubelet दोघांसाठी अधिक काम.

जर मॉड्यूल्सची संख्या वाढली तर ते सिस्टमची गती कमी करू शकते आणि त्याची विश्वासार्हता देखील कमी करू शकते.

Kubernetes भांडारात काही तक्रार केलीते नोड्स रेडी/नॉटरेडी स्थितींमध्ये उडी मारतात कारण नोडवरील सर्व कंटेनरची नियमित कुबेलेट तपासणी खूप वेळ घेते.
या कारणास्तव कुबर्नेट्स प्रति नोड 110 पेक्षा जास्त शेंगा न ठेवण्याची शिफारस करते. नोडच्या कार्यक्षमतेनुसार, तुम्ही प्रति नोड अधिक पॉड्स चालवू शकता, परंतु समस्या असतील किंवा सर्व काही ठीक होईल की नाही हे सांगणे कठीण आहे. कामाची आगाऊ चाचणी करणे योग्य आहे.

गैरसोय क्रमांक 2. प्रतिकृतीवरील मर्यादा
खूप कमी नोड्स अनुप्रयोग प्रतिकृतीची प्रभावी मर्यादा मर्यादित करतात. उदाहरणार्थ, तुमच्याकडे पाच प्रतिकृती असलेला उच्च उपलब्धता अनुप्रयोग असल्यास परंतु केवळ दोन नोड्स असल्यास, अनुप्रयोगाची प्रतिकृतीची प्रभावी पदवी दोनपर्यंत कमी केली जाते.

पाच प्रतिकृती फक्त दोन नोड्समध्ये वितरीत केल्या जाऊ शकतात आणि त्यापैकी एक अयशस्वी झाल्यास, ते एकाच वेळी अनेक प्रतिकृती काढून टाकेल.

तुमच्याकडे पाच किंवा त्याहून अधिक नोड्स असल्यास, प्रत्येक प्रतिकृती वेगळ्या नोडवर चालेल आणि एका नोडचे अपयश जास्तीत जास्त एक प्रतिकृती काढून टाकेल.

अशाप्रकारे, उच्च उपलब्धता आवश्यकतांसाठी क्लस्टरमध्ये विशिष्ट किमान नोड्सची आवश्यकता असू शकते.

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

अर्थात, कुबर्नेट्स अयशस्वी नोडमधून वर्कलोड इतरांकडे स्थलांतरित करेल. परंतु जर त्यापैकी काही असतील तर पुरेशी मुक्त क्षमता असू शकत नाही. परिणामी, तुम्ही अयशस्वी नोड आणेपर्यंत तुमचे काही अनुप्रयोग अनुपलब्ध असतील.

अशा प्रकारे, जितके जास्त नोड्स, तितके हार्डवेअर अपयशाचा प्रभाव कमी.

गैरसोय #4: अधिक ऑटोस्केलिंग चरण
Kubernetes मध्ये क्लाउड इन्फ्रास्ट्रक्चरसाठी क्लस्टर ऑटो-स्केलिंग सिस्टम आहे, जी तुम्हाला तुमच्या सध्याच्या गरजांनुसार नोड्स आपोआप जोडू किंवा काढू देते. मोठ्या नोड्ससह, ऑटोस्केलिंग अधिक आकस्मिक आणि क्लंकी बनते. उदाहरणार्थ, दोन नोड्सवर, अतिरिक्त नोड जोडल्याने क्लस्टरची क्षमता ताबडतोब 50% वाढेल. आणि तुम्हाला त्यांची गरज नसली तरीही तुम्हाला त्या संसाधनांसाठी पैसे द्यावे लागतील.

अशा प्रकारे, आपण स्वयंचलित क्लस्टर स्केलिंग वापरण्याची योजना आखल्यास, नोड्स जितके लहान असतील तितके अधिक लवचिक आणि किफायतशीर स्केलिंग आपल्याला मिळेल.

आता मोठ्या संख्येने लहान नोड्सचे फायदे आणि तोटे पाहू.

दुसरा पर्याय: अनेक लहान नोड्स

या दृष्टिकोनाचे फायदे मूलत: अनेक मोठ्या नोड्ससह विरुद्ध पर्यायाच्या तोट्यांमधून उद्भवतात.

Плюсы

प्रो #1: अपयशाचा कमी प्रभाव
जितके जास्त नोड्स, प्रत्येक नोडवर कमी शेंगा. उदाहरणार्थ, जर तुमच्याकडे प्रति दहा नोड्स शंभर मॉड्यूल्स असतील, तर प्रत्येक नोडमध्ये सरासरी दहा मॉड्यूल्स असतील.

अशा प्रकारे, नोड्सपैकी एक अयशस्वी झाल्यास, आपण केवळ 10% कार्यभार गमावाल. फक्त काही प्रतिकृती प्रभावित होण्याची शक्यता आहे आणि एकूण अनुप्रयोग कार्यरत राहील.

याव्यतिरिक्त, उर्वरित नोड्समध्ये अयशस्वी नोडचा वर्कलोड हाताळण्यासाठी पुरेशी विनामूल्य संसाधने असण्याची शक्यता आहे, त्यामुळे कुबर्नेट्स मुक्तपणे पॉड्सचे शेड्यूल करू शकतात आणि तुमचे अॅप्लिकेशन तुलनेने लवकर कार्यक्षम स्थितीत परत येतील.

प्रो #2: चांगली प्रतिकृती
पुरेसे नोड्स असल्यास, Kubernetes शेड्युलर सर्व प्रतिकृतींना भिन्न नोड नियुक्त करू शकतो. अशा प्रकारे, नोड अयशस्वी झाल्यास, फक्त एक प्रतिकृती प्रभावित होईल आणि अनुप्रयोग उपलब्ध राहील.

मिनिन्स

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

कुबर्नेट्स कंट्रोलर मॅनेजरमधील नोड कंट्रोलर आरोग्य तपासण्यासाठी क्लस्टरमधील सर्व नोड्समधून नियमितपणे फिरतो - जितके जास्त नोड्स, कंट्रोलरवर अधिक भार.

etcd डेटाबेसवरील भार देखील वाढत आहे - प्रत्येक kubelet आणि kube-proxy कॉल निरीक्षक etcd साठी (API द्वारे), ज्यावर etcd ने ऑब्जेक्ट अपडेट्स प्रसारित केले पाहिजेत.

सर्वसाधारणपणे, प्रत्येक वर्कर नोड मास्टर नोड्सच्या सिस्टम घटकांवर अतिरिक्त भार लादतो.

Kubernetes अधिकृतपणे क्लस्टर्सचे समर्थन करते 5000 पर्यंत नोड्सची संख्या. तथापि, सराव मध्ये आधीच 500 नोड आहेत क्षुल्लक समस्या उद्भवू शकतात.

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

या विशिष्ट समस्यांचे निराकरण करण्यासाठी विशेष विकास आहेत, जसे की व्हर्च्युअल क्यूबलेट. ही प्रणाली तुम्हाला निर्बंधांना बायपास करण्यास आणि मोठ्या संख्येने कामगार नोड्ससह क्लस्टर तयार करण्यास अनुमती देते.

गैरसोय #2: अधिक ओव्हरहेड खर्च.
प्रत्येक वर्कर नोडवर, कुबर्नेट्स सिस्टम डिमनचा एक संच चालवतात - यामध्ये कंटेनर रनटाइम (जसे की डॉकर), क्यूबे-प्रॉक्सी आणि कुबेलेट, सीएडव्हायझरसह. एकत्रितपणे ते ठराविक प्रमाणात संसाधने वापरतात.

तुमच्याकडे अनेक लहान नोड्स असल्यास, प्रत्येक नोडवरील या ओव्हरहेडचे प्रमाण मोठे आहे. उदाहरणार्थ, कल्पना करा की एकाच नोडवरील सर्व सिस्टम डिमन एकत्रितपणे 0,1 CPU कोर आणि 0,1 GB मेमरी वापरतात. जर तुमच्याकडे 10 GB मेमरी असलेला एक दहा-कोर नोड असेल, तर डिमन क्लस्टर क्षमतेच्या 1% वापरतात. दुसरीकडे, 1 GB मेमरी असलेल्या दहा सिंगल-कोर नोड्सवर, डिमन क्लस्टर क्षमतेच्या 10% घेतील.

अशा प्रकारे, कमी नोड्स, पायाभूत सुविधांचा अधिक कार्यक्षमतेने वापर केला जातो.

गैरसोय क्रमांक 3. संसाधनांचा अकार्यक्षम वापर
लहान नोड्सवर, असे असू शकते की उर्वरित संसाधन भाग कोणत्याही वर्कलोडला नियुक्त करण्यासाठी खूप लहान आहेत, म्हणून ते न वापरलेले राहतात.

उदाहरणार्थ, प्रत्येक पॉडसाठी 0,75 GB मेमरी आवश्यक आहे. तुमच्याकडे दहा नोड्स असल्यास, प्रत्येक 1GB मेमरीसह, तुम्ही प्रत्येक नोडमध्ये 0,25GB न वापरलेली मेमरी सोडून दहा पॉड्स चालवू शकता.

याचा अर्थ संपूर्ण क्लस्टरची 25% मेमरी वाया गेली आहे.

10 GB मेमरी असलेल्या मोठ्या नोडवर, आपण यापैकी 13 मॉड्यूल चालवू शकता - आणि 0,25 GB चा फक्त एक न वापरलेला भाग असेल.

या प्रकरणात, केवळ 2,5% मेमरी वाया जाते.

अशा प्रकारे, मोठ्या नोड्सवर संसाधने अधिक चांगल्या प्रकारे वापरली जातात.

अनेक मोठे नोड्स किंवा अनेक लहान?

तर, कोणते चांगले आहे: क्लस्टरमधील काही मोठे नोड्स की अनेक लहान? नेहमीप्रमाणे, कोणतेही स्पष्ट उत्तर नाही. अर्जाच्या प्रकारावर बरेच काही अवलंबून असते.

उदाहरणार्थ, जर एखाद्या ऍप्लिकेशनला 10 GB मेमरी आवश्यक असेल, तर मोठ्या नोड्स ही एक स्पष्ट निवड आहे. आणि जर ऍप्लिकेशनला उच्च उपलब्धतेसाठी दहापट प्रतिकृती आवश्यक असेल, तर केवळ दोन नोड्सवर प्रतिकृती ठेवण्याची जोखीम कमीच आहे - क्लस्टरमध्ये किमान दहा नोड्स असणे आवश्यक आहे.

मध्यवर्ती परिस्थितींमध्ये, प्रत्येक पर्यायाचे फायदे आणि तोटे यावर आधारित निवड करा. कदाचित काही युक्तिवाद इतरांपेक्षा आपल्या परिस्थितीशी अधिक संबंधित असतील.

आणि सर्व नोड्स समान आकाराचे करणे अजिबात आवश्यक नाही. समान आकाराच्या नोड्ससह प्रथम प्रयोग करण्यापासून, नंतर त्यामध्ये भिन्न आकाराचे नोड्स जोडून, ​​त्यांना क्लस्टरमध्ये एकत्र करण्यापासून काहीही प्रतिबंधित करत नाही. कुबर्नेट्स क्लस्टरमधील वर्कर नोड्स पूर्णपणे भिन्न असू शकतात. म्हणून आपण दोन्ही दृष्टिकोनांचे फायदे एकत्र करण्याचा प्रयत्न करू शकता.

कोणतीही एकच कृती नाही आणि प्रत्येक परिस्थितीची स्वतःची बारकावे आहेत आणि केवळ उत्पादन सत्य दर्शवेल.

क्लाउड प्लॅटफॉर्म टीमने तयार केलेले भाषांतर Mail.ru क्लाउड सोल्यूशन्स.

कुबर्नेट्स बद्दल अधिक: 25 क्लस्टर्स व्यवस्थापित करण्यासाठी आणि तैनात करण्यासाठी उपयुक्त साधने.

स्त्रोत: www.habr.com