🐱 ⚠️ 💾 K8S मल्टीकलर यात्रा 🚵🏻 👉 📗

नमस्कार, हेब्र!

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

शुरू करने के लिए, हम आपको इस बात की बेहतर समझ के लिए कुछ नंबरों की पेशकश करते हैं:

100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang.
— 2000 . Rancher v1.6 VMware.

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

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

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

पहला चरण

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

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

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

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

और विजेता बाहर आया:

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

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

Ansible क्या kubespray पर बनाया गया है, यह ऐसा उपकरण नहीं है जो IaC का पालन करने की अनुमति देता है: नोड्स के इनपुट / आउटपुट के दौरान कुछ गलत हुआ, और कुछ हस्तक्षेप की आवश्यकता थी, और विभिन्न ओएस का उपयोग करते समय, प्लेबुक को बदला गया अलग तरीकों से। क्लस्टर में आदेशों और नोड्स की बढ़ती संख्या के साथ, हमने यह देखना शुरू कर दिया कि प्लेबुक को लंबा और लंबा समय लगा, अंत में हमारा रिकॉर्ड 3.5 घंटे का था, और आपका? :)

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

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

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

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

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

कैसे बनें

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

इसलिए हमें एक दूसरा मिला:

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

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

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

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

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

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

Rancher 2.2 संस्करण में पहले से ही अधिक कुशल रूप था, और पिछले वाले के साथ, बॉक्स से बाहर दिलचस्प सुविधाओं का एक गुच्छा था, जैसे कि कई बाहरी प्रदाताओं के साथ एकीकरण, अधिकारों के वितरण का एक बिंदु और kubeconfig फ़ाइलें, UI में अपने अधिकारों के साथ एक kubectl छवि लॉन्च करना, नेस्टस्पेस नाम aka प्रोजेक्ट्स।

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

क्या हुआ

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

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

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

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

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

पहला चरण

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

कैसे बनें

क्या हुआ

More articles: