K8S मल्टीक्लस्टर यात्रा

हे हबर!

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

आरंभ करने के लिए, हम आपको इस बात को बेहतर ढंग से समझने के लिए कुछ संख्याएँ प्रदान करते हैं कि क्या चर्चा की जाएगी:

• हमारे विकास विभाग में 100 से अधिक लोग शामिल हैं, जिनमें आत्मनिर्भर QA, DevOps और Scrum प्रक्रियाओं वाली 10 से अधिक विभिन्न टीमें शामिल हैं। विकास स्टैक - पायथन, पीएचपी, सी++, जावा और गोलांग। 
• परीक्षण और उत्पादन वातावरण का आकार लगभग 2000 कंटेनर है। वे अपने स्वयं के वर्चुअलाइजेशन पर और VMware के तहत Rancher v1.6 चला रहे हैं। 

अभिप्रेरण

जैसा कि वे कहते हैं, कुछ भी हमेशा के लिए नहीं रहता है, और रंचर ने काफी समय पहले संस्करण 1.6 के लिए समर्थन समाप्त करने की घोषणा की थी। हां, तीन साल से अधिक समय में हमने सीख लिया है कि इसे कैसे तैयार किया जाए और आने वाली समस्याओं को कैसे हल किया जाए, लेकिन अधिक से अधिक बार हमें ऐसी समस्याओं का सामना करना पड़ता है जिन्हें कभी ठीक नहीं किया जा सकता है। Rancher 1.6 में अधिकार जारी करने के लिए एक ossified प्रणाली भी है, जहां आप या तो लगभग सब कुछ कर सकते हैं या कुछ भी नहीं कर सकते हैं।

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

हम IaC मानकों का पालन करना चाहते थे और, यदि आवश्यक हो, किसी भी भौगोलिक स्थान पर और विक्रेता लॉक के बिना, जल्दी से क्षमता प्राप्त करना चाहते थे, और इसे जल्दी से छोड़ने में भी सक्षम होना चाहते थे।

पहला कदम

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

इसके बाद क्लस्टर बनाने के लिए एक उपकरण चुनने का सवाल आया। हमने सबसे लोकप्रिय समाधानों की तुलना की: kops, kubespray, kubeadm।

शुरू करने के लिए, कुबेदम हमें बहुत जटिल रास्ता लगा, बल्कि एक "साइकिल" के आविष्कारक की तरह, और कोप्स के पास पर्याप्त लचीलापन नहीं था।

और विजेता था:

हमने अपने स्वयं के वर्चुअलाइजेशन और AWS के साथ प्रयोग करना शुरू कर दिया, अपने पिछले संसाधन प्रबंधन पैटर्न के समान कुछ फिर से बनाने की कोशिश की, जहां सभी ने समान "क्लस्टर" साझा किया। और अब हमारे पास 10 छोटी वर्चुअल मशीनों का पहला क्लस्टर है, जिनमें से कुछ AWS में स्थित हैं। हमने वहां टीमों को स्थानांतरित करने की कोशिश शुरू की, सब कुछ "अच्छा" लग रहा था, और कहानी समाप्त हो सकती थी, लेकिन...

पहली समस्याएँ

Ansible वह है जिस पर क्यूबस्प्रे बनाया गया है, यह एक उपकरण नहीं है जो आपको IaC का पालन करने की अनुमति देता है: नोड्स को चालू/डीकमीशन करते समय, लगातार कुछ गलत हो रहा था और किसी प्रकार के हस्तक्षेप की आवश्यकता थी, और विभिन्न ओएस का उपयोग करते समय, प्लेबुक अलग-अलग व्यवहार करता था। . जैसे-जैसे क्लस्टर में टीमों और नोड्स की संख्या बढ़ती गई, हमने नोटिस करना शुरू कर दिया कि प्लेबुक को पूरा होने में अधिक समय लग रहा था, और परिणामस्वरूप, हमारा रिकॉर्ड 3,5 घंटे का था, आपके बारे में क्या? 🙂

और ऐसा लगता है जैसे क्यूबस्प्रे सिर्फ एन्सिबल है, और पहली नज़र में सब कुछ स्पष्ट है, लेकिन:

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


इसके प्रकाश में, यह स्पष्ट हो गया कि संसाधनों को एक ऑर्केस्ट्रेशन सिस्टम में संयोजित करने का हमारा पुराना पैटर्न उपयुक्त नहीं था - ऐसे मामले में जहां क्लस्टर बहुत दूरस्थ हैं और विभिन्न प्रदाताओं द्वारा प्रबंधित किए जाते हैं। 

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

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

क्या करना है?

उपरोक्त और टीमों की अधिक स्वतंत्र होने की इच्छाओं को ध्यान में रखते हुए, हमने एक सरल निष्कर्ष निकाला: एक टीम - एक क्लस्टर। 

तो हमें दूसरा मिला:

और फिर तीसरा क्लस्टर: 

फिर हमने सोचना शुरू किया: मान लीजिए कि एक साल में हमारी टीमों के पास एक से अधिक क्लस्टर होंगे? उदाहरण के लिए, विभिन्न भौगोलिक क्षेत्रों में, या विभिन्न प्रदाताओं के नियंत्रण में? और उनमें से कुछ लोग कुछ परीक्षणों के लिए एक अस्थायी क्लस्टर को शीघ्रता से तैनात करने में सक्षम होना चाहेंगे। 

पूर्ण कुबेरनेट्स आएंगे! यह किसी प्रकार का मल्टीकुबेरनेट्स है, ऐसा पता चला है। 

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

कुबेरनेट्स की दुनिया में हमारी यात्रा की शुरुआत के बाद से कुछ समय बीत चुका है, और हमने उपलब्ध समाधानों की फिर से जांच करने का फैसला किया है। यह पता चला कि यह पहले से ही बाजार में मौजूद है - रंचर 2.2।

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

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

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

क्या हुआ

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

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

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

लेख ए. एंटिपोव, ए. गनुश, प्लेटफ़ॉर्म इंजीनियर्स द्वारा लिखा गया था। 

स्रोत: www.habr.com