🥇K8S मल्टीक्लस्टर जर्नी

अहो हाब्र!

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

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

आमच्या विकास विभागात १०० हून अधिक लोक आहेत, ज्यात स्वयंपूर्ण QA, DevOps आणि Scrum प्रक्रिया असलेल्या १० हून अधिक वेगवेगळ्या टीम आहेत. आमच्या विकास स्टॅकमध्ये Python, PHP, C++, Java आणि Golang यांचा समावेश आहे.
चाचणी आणि उत्पादन वातावरणात प्रत्येकी अंदाजे २००० कंटेनर असतात. ते रँचर v1.6 द्वारे त्यांच्या स्वतःच्या व्हर्च्युअलायझेशन प्लॅटफॉर्मवर आणि VMware अंतर्गत व्यवस्थापित केले जातात.

प्रेरणा

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

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

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

प्रथम चरण

सर्वप्रथम, आम्हाला आधुनिक तंत्रज्ञान आणि उपायांवर अवलंबून राहायचे होते जे संघांना जलद विकास चक्र करण्यास सक्षम करतील आणि क्षमता प्रदान करणाऱ्या प्लॅटफॉर्मशी संवाद साधण्याशी संबंधित ऑपरेशनल खर्च कमी करतील.

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

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

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

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

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

पहिल्या समस्या

क्यूबेसप्रेचा पाया असलेले अँसिबल हे आयएसीसाठी योग्य साधन नाही: नोड्स ऑनलाइन आणि ऑफलाइन आणताना सतत काहीतरी चूक होत असे, ज्यासाठी काही प्रकारच्या हस्तक्षेपाची आवश्यकता असते आणि प्लेबुक वेगवेगळ्या ऑपरेटिंग सिस्टममध्ये वेगवेगळ्या पद्धतीने वागते. क्लस्टरमधील टीम्स आणि नोड्सची संख्या वाढत असताना, आम्हाला लक्षात आले की प्लेबुक चालण्यासाठी जास्त वेळ लागत आहे. आमचा सर्वोत्तम वेळ आता ३.५ तास आहे. तुमचा काय आहे? 🙂

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

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

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

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

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

कसे असावे

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

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

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

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

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

त्याच वेळी, आपल्या सर्वांना हे सर्व क्लस्टर्स कसे तरी सांभाळावे लागतील, त्यांच्यापर्यंत सहज प्रवेश मिळवता येईल, तसेच नवीन तयार करावे लागतील आणि जुने मॅन्युअल हस्तक्षेपाशिवाय काढून टाकावे लागतील.

कुबर्नेट्सच्या जगात आमचा प्रवास सुरू करून काही काळ लोटला आहे, म्हणून आम्ही उपलब्ध उपायांची पुनर्तपासणी करण्याचा निर्णय घेतला. असे दिसून आले की बाजारात आधीच एक आहे: रँचर २.२.

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

रँचर २.२ आधीच अधिक कार्यक्षम होते आणि मागील आवृत्त्यांसोबतच, त्यात अनेक मनोरंजक आउट-ऑफ-द-बॉक्स वैशिष्ट्ये होती, जसे की अनेक बाह्य प्रदात्यांसह एकत्रीकरण, परवानग्या आणि kubeconfig फायली वितरित करण्यासाठी एकच बिंदू, UI मध्ये तुमच्या परवानग्यांसह kubectl प्रतिमा चालवणे आणि नेस्टेड नेमस्पेसेस (उर्फ प्रोजेक्ट्स).

रँचर २ च्या आसपास आधीच एक समुदाय तयार होत होता आणि त्याचे व्यवस्थापन करण्यासाठी एक हाशीकॉर्प टेराफॉर्म प्रदाता तयार करण्यात आला होता, ज्यामुळे आम्हाला सर्वकाही एकत्र आणण्यास मदत झाली.

काय झालं

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

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

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