K8S मल्टीक्लस्टर प्रवास

अहो हाब्र!

आम्ही Exness प्लॅटफॉर्म संघाचे प्रतिनिधित्व करतो. पूर्वी, आमच्या सहकार्यांनी आधीच याबद्दल एक लेख लिहिला आहे k8s साठी उत्पादनासाठी तयार प्रतिमा. आज आम्‍हाला Kubernetes वर सेवा स्थलांतरित करण्‍याचा आमचा अनुभव शेअर करायचा आहे.

सुरूवातीस, आम्ही तुम्हाला काही संख्या देऊ करतो ज्याची चर्चा केली जाईल हे चांगल्या प्रकारे समजून घेण्यासाठी:

• आमच्या विकास विभागात 100+ लोकांचा समावेश आहे, ज्यात स्वयंपूर्ण QA, DevOps आणि स्क्रम प्रक्रियांसह 10 पेक्षा जास्त संघांचा समावेश आहे. डेव्हलपमेंट स्टॅक - Python, PHP, C++, Java आणि Golang. 
• चाचणी आणि उत्पादन वातावरणाचा आकार प्रत्येकी सुमारे 2000 कंटेनर आहे. ते त्यांच्या स्वत: च्या व्हर्च्युअलायझेशनवर आणि VMware अंतर्गत Rancher v1.6 चालवत आहेत. 

प्रेरणा

जसे ते म्हणतात, काहीही कायमचे टिकत नाही आणि रँचरने बर्‍याच काळापूर्वी आवृत्ती 1.6 साठी समर्थन समाप्त करण्याची घोषणा केली. होय, तीन वर्षांहून अधिक काळ आपण ते कसे तयार करावे आणि उद्भवलेल्या समस्यांचे निराकरण कसे करावे हे शिकलो आहोत, परंतु अधिकाधिक वेळा आपल्याला अशा समस्यांचा सामना करावा लागतो ज्या कधीही दुरुस्त होणार नाहीत. Rancher 1.6 मध्ये अधिकार जारी करण्यासाठी ossified प्रणाली देखील आहे, जिथे आपण एकतर जवळजवळ सर्व काही करू शकता किंवा काहीही करू शकता.

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

आम्ही IaC मानकांचे पालन करू इच्छितो आणि आवश्यक असल्यास, कोणत्याही भौगोलिक स्थानावर आणि विक्रेत्याच्या लॉकशिवाय त्वरीत क्षमता प्राप्त करू इच्छितो आणि ते त्वरीत सोडून देऊ इच्छितो.

प्रथम चरण

सर्वप्रथम, आम्हाला आधुनिक तंत्रज्ञान आणि उपायांवर विसंबून राहायचे आहे जे संघांना वेगवान विकास चक्र आणि शक्ती प्रदान करणार्‍या प्लॅटफॉर्मशी संवाद साधण्यासाठी ऑपरेशनल खर्च कमी करू देतील. 
 
अर्थात, आमच्या मनात आलेली पहिली गोष्ट म्हणजे Kubernetes, परंतु आम्ही उत्साहित झालो नाही आणि ती योग्य निवड आहे की नाही हे पाहण्यासाठी थोडे संशोधन केले. आम्ही फक्त ओपनसोर्स सोल्यूशन्सचे मूल्यमापन केले आणि एका अयोग्य लढाईत, कुबर्नेट्स बिनशर्त जिंकले.  

पुढे क्लस्टर तयार करण्यासाठी साधन निवडण्याचा प्रश्न आला. आम्ही सर्वात लोकप्रिय उपायांची तुलना केली: kops, kubespray, kubeadm.

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

आणि विजेता होता:

आम्ही आमच्या स्वतःच्या व्हर्च्युअलायझेशन आणि AWS सह प्रयोग सुरू केले, आमच्या मागील संसाधन व्यवस्थापन पॅटर्नसारखे काहीतरी पुन्हा तयार करण्याचा प्रयत्न केला, जिथे प्रत्येकाने समान "क्लस्टर" सामायिक केले. आणि आता आमच्याकडे 10 लहान व्हर्च्युअल मशीन्सचा पहिला क्लस्टर आहे, त्यापैकी काही AWS मध्ये आहेत. आम्ही तेथे संघ स्थलांतरित करण्याचा प्रयत्न सुरू केला, सर्व काही "चांगले" असल्याचे दिसत होते, आणि कथा पूर्ण होऊ शकते, परंतु...

प्रथम समस्या

kubespray कशावर बांधले आहे ते उत्तरदायी आहे, ते तुम्हाला IaC चे अनुसरण करण्यास अनुमती देणारे साधन नाही: नोड्स चालू/डिकमिशन करताना, सतत काहीतरी चूक होते आणि काही प्रकारचा हस्तक्षेप आवश्यक होता आणि भिन्न OS वापरताना, प्लेबुक वेगळ्या पद्धतीने वागले. वेगळ्या पद्धतीने . क्लस्टरमधील संघ आणि नोड्सची संख्या जसजशी वाढत गेली तसतसे प्लेबुक पूर्ण होण्यास जास्त वेळ लागत असल्याचे आमच्या लक्षात येऊ लागले आणि परिणामी आमचा रेकॉर्ड 3,5 तासांचा होता, तुमचे काय? 🙂

आणि असे दिसते की kubespray फक्त उत्तरदायी आहे, आणि सर्व काही पहिल्या दृष्टीक्षेपात स्पष्ट आहे, परंतु:

प्रवासाच्या सुरूवातीस, कार्य केवळ AWS मध्ये आणि आभासीकरणावर क्षमता लॉन्च करणे होते, परंतु नंतर, जसे अनेकदा होते, आवश्यकता बदलल्या.
 


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

पुढे आणखी. जेव्हा सर्व संघ एकाच क्लस्टरमध्ये काम करतात, तेव्हा चुकीच्या पद्धतीने स्थापित नोडसेलेक्टरसह विविध सेवा दुसर्‍या संघाच्या “परदेशी” होस्टकडे जाऊ शकतात आणि तेथील संसाधनांचा वापर करू शकतात आणि जर कलंक सेट केला गेला असेल, तर एक किंवा दुसरी सेवा कार्य करत नाही अशा सतत विनंत्या केल्या जात होत्या, मानवी घटकामुळे योग्यरित्या वितरित केले नाही. आणखी एक समस्या म्हणजे खर्चाची गणना करणे, विशेषत: नोड्समध्ये सेवा वितरीत करण्याच्या समस्यांचा विचार करणे.

कर्मचार्‍यांना अधिकार जारी करणे ही एक वेगळी कथा होती: प्रत्येक संघाला क्लस्टरच्या "मुख्यस्थानी" राहायचे होते आणि ते पूर्णपणे व्यवस्थापित करायचे होते, ज्यामुळे संपूर्ण संकुचित होऊ शकते, कारण संघ मुळात एकमेकांपासून स्वतंत्र आहेत.

कसे असावे

वरील गोष्टी आणि संघांच्या अधिक स्वतंत्र होण्याच्या इच्छा लक्षात घेऊन, आम्ही एक साधा निष्कर्ष काढला: एक संघ - एक क्लस्टर. 

तर आम्हाला दुसरा मिळाला:

आणि मग तिसरा क्लस्टर: 

मग आम्ही विचार करू लागलो: एका वर्षात आमच्या संघांमध्ये एकापेक्षा जास्त क्लस्टर असतील असे म्हणूया? वेगवेगळ्या भौगोलिक भागात, उदाहरणार्थ, किंवा वेगवेगळ्या प्रदात्यांच्या नियंत्रणाखाली? आणि त्यापैकी काहींना काही चाचण्यांसाठी तात्पुरते क्लस्टर त्वरित तैनात करण्यात सक्षम व्हायचे असेल. 

पूर्ण कुबर्नेट्स येतील! हे एक प्रकारचे मल्टीकुबर्नेट्स आहे, असे दिसून आले. 

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

कुबर्नेट्सच्या जगात आमचा प्रवास सुरू झाल्यापासून काही काळ निघून गेला आहे आणि आम्ही उपलब्ध उपायांचे पुन्हा परीक्षण करण्याचा निर्णय घेतला. असे दिसून आले की ते आधीपासूनच बाजारात अस्तित्वात आहे - रॅन्चर 2.2.

आमच्या संशोधनाच्या पहिल्या टप्प्यावर, Rancher Labs ने आवृत्ती 2 चे पहिले प्रकाशन आधीच केले होते, परंतु जरी काही पॅरामीटर्ससह बाह्य अवलंबनाशिवाय कंटेनर लाँच करून किंवा अधिकृत HELM चार्ट वापरून ते खूप लवकर वाढवले ​​जाऊ शकते, परंतु ते कच्चे वाटले. आमच्यासाठी, आणि आम्हाला माहित नव्हते की आम्ही या निर्णयावर अवलंबून राहू शकतो की ते विकसित केले जाईल किंवा त्वरीत सोडले जाईल. UI मधील क्लस्टर = क्लिक पॅराडाइम देखील आम्हाला शोभत नाही, आणि आम्ही RKE शी जोडले जाऊ इच्छित नाही, कारण ते एक संकुचितपणे केंद्रित साधन आहे. 

आवृत्ती Rancher 2.2 मध्ये आधीपासूनच अधिक कार्यक्षम स्वरूप होते आणि मागील आवृत्तीसह, अनेक मनोरंजक वैशिष्ट्यांचा समूह होता, जसे की अनेक बाह्य प्रदात्यांसह एकत्रीकरण, अधिकार वितरणाचा एक बिंदू आणि kubeconfig फाइल्स, kubectl लाँच करणे. UI, नेस्टेड नेमस्पेस उर्फ ​​​​प्रकल्पांमध्ये आपल्या अधिकारांसह प्रतिमा. 

Rancher 2 च्या आसपास आधीच एक समुदाय तयार झाला होता आणि ते व्यवस्थापित करण्यासाठी HashiCorp Terraform नावाचा एक प्रदाता तयार केला गेला होता, ज्याने आम्हाला सर्वकाही एकत्र ठेवण्यास मदत केली.

काय झालं

परिणामी, आम्ही एका लहान क्लस्टरसह रॅन्चर चालवत आहोत, इतर सर्व क्लस्टर्समध्ये प्रवेश करण्यायोग्य आहे, तसेच त्याच्याशी जोडलेले अनेक क्लस्टर, ज्यापैकी कोणत्याहीमध्ये प्रवेश ldap निर्देशिकेत वापरकर्ता जोडण्याइतकाच मंजूर केला जाऊ शकतो, पर्वा न करता. ते कुठे आहे आणि ते कोणत्या प्रदात्याचे संसाधने वापरते.

gitlab-ci आणि Terraform वापरून, एक प्रणाली तयार केली गेली जी तुम्हाला क्लाउड प्रदाते किंवा आमच्या स्वतःच्या पायाभूत सुविधांमध्ये कोणत्याही कॉन्फिगरेशनचे क्लस्टर तयार करण्यास आणि त्यांना Rancher शी कनेक्ट करण्यास अनुमती देते. हे सर्व IaC शैलीमध्ये केले जाते, जेथे प्रत्येक क्लस्टरचे वर्णन रेपॉजिटरीद्वारे केले जाते आणि त्याची स्थिती आवृत्ती केली जाते. त्याच वेळी, बहुतेक मॉड्यूल्स बाह्य रिपॉझिटरीजमधून जोडलेले असतात जेणेकरून जे काही उरते ते व्हेरिएबल्स पास करणे किंवा उदाहरणांसाठी आपल्या सानुकूल कॉन्फिगरेशनचे वर्णन करणे, जे कोड पुनरावृत्तीची टक्केवारी कमी करण्यात मदत करते.

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

लेख A. Antipov, A. Ganush, Platform Engineers यांनी लिहिला होता. 

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