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

हे हाबर!

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

सुरुमा, के छलफल गरिनेछ भनेर राम्रोसँग बुझ्नको लागि हामी तपाईंलाई केही नम्बरहरू प्रस्ताव गर्छौं:

• हाम्रो विकास विभागमा 100 भन्दा बढी व्यक्तिहरू छन्, जसमा आत्म-पर्याप्त QA, DevOps र Scrum प्रक्रियाहरू सहित 10 भन्दा बढी विभिन्न टोलीहरू छन्। विकास स्ट्याक - Python, PHP, C++, Java र Golang। 
• परीक्षण र उत्पादन वातावरण को आकार लगभग 2000 कन्टेनर प्रत्येक छ। तिनीहरू आफ्नै भर्चुअलाइजेशन र VMware अन्तर्गत Rancher v1.6 चलाउँदै छन्। 

प्रेरणा

तिनीहरूले भनेझैं, केहि पनि सधैंभरि रहँदैन, र Rancher ले धेरै लामो समय पहिले संस्करण 1.6 को लागि समर्थनको अन्त्य घोषणा गर्‍यो। हो, तीन वर्ष भन्दा बढीमा हामीले यसलाई कसरी तयार गर्ने र उत्पन्न हुने समस्याहरू समाधान गर्ने भनेर सिकेका छौं, तर धेरै पटक हामी समस्याहरूको सामना गर्दैछौं जुन कहिल्यै सच्याइँदैन। Rancher 1.6 सँग अधिकार जारी गर्नको लागि एक ओसीफाइड प्रणाली पनि छ, जहाँ तपाइँ या त लगभग सबै गर्न सक्नुहुन्छ वा केहि पनि गर्न सक्नुहुन्छ।

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

हामी IaC मापदण्डहरू पछ्याउन चाहन्थ्यौं र, आवश्यक भएमा, कुनै पनि भौगोलिक स्थानमा र विक्रेता लक बिना नै छिटो क्षमता प्राप्त गर्न, र यसलाई तुरुन्तै त्याग्न सक्षम हुन चाहन्छौं।

पहिलो कदम

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

अर्को क्लस्टरहरू सिर्जना गर्न उपकरण छनौट गर्ने प्रश्न आयो। हामीले सबैभन्दा लोकप्रिय समाधानहरू तुलना गर्यौं: kops, kubespray, kubeadm।

सुरु गर्न को लागी, kubeadm हामीलाई "साइकल" को कुनै प्रकारको आविष्कारक जस्तै, धेरै जटिल बाटो जस्तो देखिन्थ्यो, र कोप्समा पर्याप्त लचिलोपन थिएन।

र विजेता थियो:

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

पहिलो समस्याहरू

kubespray मा बनाइएको हो, यो IaC लाई पछ्याउन अनुमति दिने उपकरण होइन: नोडहरू कमिसन/डिकममिशन गर्दा, केहि निरन्तर गल्ती भयो र केहि प्रकारको हस्तक्षेप आवश्यक थियो, र विभिन्न OS प्रयोग गर्दा, प्लेबुकले फरक व्यवहार गर्यो। । क्लस्टरमा टोली र नोडहरूको संख्या बढ्दै जाँदा, हामीले याद गर्न थाल्यौं कि प्लेबुक पूरा हुन लामो र लामो समय लिइरहेको थियो, र परिणाम स्वरूप, हाम्रो रेकर्ड 3,5 घण्टा थियो, तपाईंको के हो? 🙂

र यस्तो देखिन्छ कि kubespray मात्र उत्तरदायी छ, र सबै कुरा पहिलो नजरमा स्पष्ट छ, तर:

यात्राको सुरुमा, कार्य AWS र भर्चुअलाइजेशनमा मात्र क्षमताहरू सुरू गर्ने थियो, तर त्यसपछि, प्रायः हुन्छ, आवश्यकताहरू परिवर्तन भयो।
 


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

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

एउटा छुट्टै कथा भनेको कर्मचारीहरूलाई अधिकार जारी गर्ने थियो: प्रत्येक टोली क्लस्टरको "हेडमा" हुन चाहन्थे र यसलाई पूर्ण रूपमा व्यवस्थापन गर्न चाहन्थे, जसले पूर्ण रूपमा पतन हुन सक्छ, किनकि टोलीहरू मूल रूपमा एक अर्काबाट स्वतन्त्र छन्।

कसरी गर्ने?

माथिका कुराहरूलाई ध्यानमा राख्दै र टोलीहरूको इच्छालाई अझ बढी आत्मनिर्भर हुन, हामीले एउटा साधारण निष्कर्ष निकाल्यौं: एउटा टोली - एउटा समूह। 

त्यसैले हामीले दोस्रो पायौं:

र त्यसपछि तेस्रो क्लस्टर: 

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

पूरा कुबेरनेट आउँथ्यो! यो केहि प्रकारको MultiKubernetes हो, यो बाहिर जान्छ। 

एकै समयमा, हामी सबैले कुनै न कुनै रूपमा यी सबै क्लस्टरहरूलाई कायम राख्न, तिनीहरूमा सजिलैसँग पहुँच प्रबन्ध गर्न सक्षम हुन, साथै नयाँहरू सिर्जना गर्न र म्यानुअल हस्तक्षेप बिना पुरानाहरूलाई खारेज गर्न आवश्यक हुनेछ।

Kubernetes को संसारमा हाम्रो यात्रा सुरु भएको केही समय बितिसकेको छ, र हामीले उपलब्ध समाधानहरू पुन: जाँच गर्ने निर्णय गर्यौं। यो बाहिर भयो कि यो पहिले नै बजार मा अवस्थित छ - Rancher 2.2।

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

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

त्यहाँ पहिले नै Rancher 2 वरिपरि एउटा समुदाय बनाइएको थियो, र HashiCorp Terraform नामक प्रदायकलाई यसलाई व्यवस्थापन गर्न सिर्जना गरिएको थियो, जसले हामीलाई सबै कुरा एकसाथ राख्न मद्दत गर्‍यो।

के भयो

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

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

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

लेख ए. एन्टिपोभ, ए गानुस, प्लेटफर्म इन्जिनियर्स द्वारा लेखिएको थियो। 

स्रोत: www.habr.com