Kubernetes र स्वचालन को लागी दुई घण्टा मा क्लाउड मा कसरी माइग्रेट गर्ने

URUS कम्पनीले विभिन्न रूपहरूमा Kubernetes को प्रयास गर्‍यो: Google Cloud मा बेयर मेटलमा स्वतन्त्र तैनाती, र त्यसपछि यसको प्लेटफर्मलाई Mail.ru Cloud Solutions (MCS) क्लाउडमा स्थानान्तरण गर्‍यो। इगोर शिश्किनले उनीहरूले कसरी नयाँ क्लाउड प्रदायक छनौट गरे र कसरी उनीहरूले रेकर्ड दुई घण्टामा यसलाई माइग्रेट गर्न व्यवस्थित गरे बताउँछन्।t3ran), URUS मा वरिष्ठ प्रणाली प्रशासक।

URUS ले के गर्छ?

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

कसरी URUS भित्रबाट काम गर्दछ

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

H2S एकाग्रता निगरानी ग्राफले नजिकैको बिरुवाबाट नियमित रातको उत्सर्जन देखाउँछ

हामीले URUS मा प्रयोग गर्ने यन्त्रहरूमा धेरै सेन्सरहरू हुन्छन् जसले वातावरणीय अवस्थाको मूल्याङ्कन गर्न निश्चित ग्यासहरूको सामग्री, आवाजको स्तर र अन्य डेटाको बारेमा जानकारी सङ्कलन गर्दछ। सेन्सरहरूको सही संख्या सधैं विशिष्ट कार्य द्वारा निर्धारण गरिन्छ।

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

समानान्तरमा, हाम्रो प्लेटफर्ममा अन्य धेरै सेवाहरू सञ्चालन हुन्छन्, तर तिनीहरू मुख्य रूपमा सेवा प्रकृतिका हुन्छन्। उदाहरणका लागि, सूचना सेवाले क्लाइन्टहरूलाई सूचनाहरू पठाउँछ यदि कुनै पनि अनुगमन गरिएको प्यारामिटरहरू (उदाहरणका लागि, CO2 सामग्री) अनुमतियोग्य मान भन्दा बढी छ।

हामी कसरी डाटा भण्डारण गर्छौं। नग्न धातुमा कुबेरनेटको कथा

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

जब हामी धेरै वर्ष पहिले हाम्रो भण्डारण समस्या समाधान गर्न खोजिरहेका थियौं, हामीसँग दुईवटा प्लेटफर्म विकल्पहरू थिए: Kubernetes र OpenStack। तर पछिल्ला एकदम राक्षसी देखिन्छ (यसको विश्वस्त हुनको लागि यसको वास्तुकला हेर्नुहोस्), हामी कुबेरनेटमा बस्यौं। यसको पक्षमा अर्को तर्क अपेक्षाकृत सरल सफ्टवेयर नियन्त्रण थियो, संसाधनहरू अनुसार हार्डवेयर नोडहरू पनि लचिलो रूपमा काट्ने क्षमता।

Kubernetes मा निपुणता संग समानांतर मा, हामीले डाटा भण्डारण गर्ने तरिकाहरू पनि अध्ययन गर्यौं, जबकि हामीले हाम्रो सबै भण्डारण Kubernetes मा हाम्रो आफ्नै हार्डवेयरमा राख्यौं, हामीले उत्कृष्ट विशेषज्ञता प्राप्त गर्यौं। हामीले कुबेरनेटमा बसेका सबै कुरा: स्टेटफुल भण्डारण, निगरानी प्रणाली, CI/CD। Kubernetes हाम्रो लागि सबैमा एक प्लेटफर्म भएको छ।

तर हामी Kubernetes सँग एक सेवाको रूपमा काम गर्न चाहन्थ्यौं, र यसको समर्थन र विकासमा संलग्न हुन चाहँदैनौं। साथै, हामीलाई नग्न धातुमा यसलाई कायम राख्न कति खर्च लाग्छ, र हामीलाई निरन्तर विकास चाहिन्छ! उदाहरण को लागी, पहिलो कार्यहरु मध्ये एक Kubernetes Ingress नियन्त्रकहरु लाई हाम्रो संगठन को नेटवर्क पूर्वाधार मा एकीकृत गर्न को लागी थियो। यो एक बोझिलो कार्य हो, विशेष गरी त्यो समयमा DNS रेकर्ड वा IP ठेगानाहरूको आवंटन जस्ता प्रोग्रामेटिक स्रोत व्यवस्थापनको लागि केहि पनि तयार थिएन भन्ने कुरालाई ध्यानमा राख्दै। पछि हामीले बाह्य डाटा भण्डारण प्रयोग गर्न थाल्यौं। हामी PVC नियन्त्रक लागू गर्न वरपर कहिल्यै पुगेनौं, तर त्यसपछि पनि यो स्पष्ट भयो कि यो कामको ठूलो क्षेत्र हो जसलाई समर्पित विशेषज्ञहरू चाहिन्छ।

गुगल क्लाउड प्लेटफर्ममा स्विच गर्नु एक अस्थायी समाधान हो

हामीले यो जारी राख्न सक्दैन भन्ने महसुस गर्यौं, र हाम्रो डेटालाई बेयर मेटलबाट Google क्लाउड प्लेटफर्ममा सारियो। वास्तवमा, त्यस समयमा रूसी कम्पनीको लागि धेरै रोचक विकल्पहरू थिएनन्: गुगल क्लाउड प्लेटफर्मको अलावा, केवल अमेजनले समान सेवा प्रस्ताव गर्‍यो, तर हामी अझै गुगलबाट समाधानमा बसेका छौं। त्यसोभए यो हामीलाई अधिक आर्थिक रूपमा लाभदायक देखिन्थ्यो, अपस्ट्रीमको नजिक, गुगल आफैं उत्पादनमा एक प्रकारको PoC Kubernetes हो भन्ने तथ्यलाई उल्लेख नगर्न।

पहिलो प्रमुख समस्या क्षितिजमा देखा पर्यो जब हाम्रो ग्राहक आधार बढ्यो। जब हामीलाई व्यक्तिगत डेटा भण्डारण गर्न आवश्यक थियो, हामीले एक छनौटको सामना गर्‍यौं: या त हामी गुगलसँग काम गर्छौं र रूसी कानूनहरू उल्लङ्घन गर्छौं, वा हामी रूसी संघमा विकल्प खोजिरहेका छौं। छनोट, समग्रमा, अनुमानित थियो। 🙂

हामीले कसरी आदर्श क्लाउड सेवा देख्यौं

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

• छिटो र लचिलो। हामी चाँडै एउटा नयाँ नोड थप्न वा कुनै पनि समयमा केहि तैनात गर्न सक्छौं।
• सस्तो। हामीसँग स्रोतसाधन सीमित भएकाले आर्थिक समस्याको बारेमा धेरै चिन्तित थियौँ । हामीलाई पहिले नै थाहा थियो कि हामी Kubernetes सँग काम गर्न चाहन्छौं, र अब यो समाधान प्रयोग गर्ने दक्षता बढाउन वा कम्तिमा कायम राख्नको लागि यसको लागत कम गर्ने कार्य थियो।
• स्वचालित। हामीले एपीआई मार्फत सेवासँग काम गर्ने योजना बनायौं, प्रबन्धकहरू र फोन कलहरू वा परिस्थितिहरू बिना जहाँ हामीले आपतकालीन मोडमा धेरै दर्जन नोडहरू म्यानुअल रूपमा उठाउनु पर्छ। हाम्रा धेरैजसो प्रक्रियाहरू स्वचालित भएकाले हामीले क्लाउड सेवाबाट पनि त्यस्तै अपेक्षा गरेका थियौं।
• रूसी संघ मा सर्भर संग। अवश्य पनि, हामीले रूसी कानून र त्यही 152-FZ पालना गर्ने योजना बनायौं।

त्यसबेला, रूसमा कुबेरनेट्स एएएस प्रदायकहरू थोरै थिए, र प्रदायक छनोट गर्दा, हाम्रा प्राथमिकताहरूमा सम्झौता नगर्नु हाम्रो लागि महत्त्वपूर्ण थियो। Mail.ru Cloud Solutions टोली, जससँग हामीले काम गर्न थाल्यौं र अझै पनि सहकार्य गरिरहेका छौं, हामीलाई API समर्थन र Horizon समावेश गर्ने सुविधाजनक कन्ट्रोल प्यानल सहितको पूर्ण स्वचालित सेवा प्रदान गर्‍यो - यसका साथ हामीले चाँडै नोडहरूको स्वेच्छाचारी संख्या बढाउन सक्छौं।

हामीले कसरी दुई घण्टामा MCS मा माइग्रेट गर्न सफल भयौं

त्यस्ता चालहरूमा, धेरै कम्पनीहरूले कठिनाइ र अवरोधहरू सामना गर्छन्, तर हाम्रो अवस्थामा त्यहाँ कुनै थिएन। हामी भाग्यशाली थियौं: माइग्रेसन सुरु हुनुभन्दा पहिले नै हामीले कुबेरनेटमा काम गरिराखेका छौं, हामीले केवल तीन फाइलहरू सच्यायौं र नयाँ क्लाउड प्लेटफर्म, MCS मा हाम्रा सेवाहरू सुरू गर्यौं। म तपाईंलाई सम्झाउन चाहन्छु कि त्यो समय सम्म हामीले अन्ततः खाली धातु छोडेर Google क्लाउड प्लेटफर्ममा बसेका थियौं। तसर्थ, चाल आफैंमा दुई घण्टा भन्दा बढी लागेन, साथै अलि बढी समय (लगभग एक घण्टा) हाम्रो उपकरणहरूबाट डाटा प्रतिलिपि गर्न खर्च भयो। त्यसबेला हामीले स्पिननेकर (निरन्तर डेलिभरी प्रदान गर्नको लागि बहु-क्लाउड सीडी सेवा) प्रयोग गरिरहेका थियौं। हामीले यसलाई चाँडै नयाँ क्लस्टरमा थप्यौं र सामान्य रूपमा काम गर्न जारी राख्यौं।

विकास प्रक्रिया र CI/CD को स्वचालन को लागी धन्यवाद, URUS मा Kubernetes एक विशेषज्ञ द्वारा ह्यान्डल गरिएको छ (र त्यो म हुँ)। केहि चरणमा, अर्को प्रणाली प्रशासकले मसँग काम गर्यो, तर त्यसपछि यो पत्ता लाग्यो कि हामीले पहिले नै सबै मुख्य दिनचर्या स्वचालित गरिसकेका छौं र हाम्रो मुख्य उत्पादनको भागमा अधिक र अधिक कार्यहरू थिए र यसले यसका लागि स्रोतहरू निर्देशित गर्न अर्थपूर्ण बनायो।

हामीले क्लाउड प्रदायकबाट हामीले अपेक्षा गरेको कुरा प्राप्त गर्यौं, किनकि हामीले भ्रम बिना सहयोग सुरु गर्यौं। यदि त्यहाँ कुनै घटनाहरू थिए भने, तिनीहरू प्रायः प्राविधिक थिए र ती सेवाको सापेक्ष ताजापनद्वारा सजिलै व्याख्या गर्न सकिन्छ। मुख्य कुरा यो हो कि MCS टोलीले तुरुन्तै कमजोरीहरू हटाउँछ र द्रुत रूपमा सन्देशवाहकहरूमा प्रश्नहरूको जवाफ दिन्छ।

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

हामी कसरी भविष्यमा बादलहरूसँग काम गर्ने देख्छौं

अब हाम्रो काम Kubernetes सँग नजिकबाट जोडिएको छ, र यो हामीलाई पूर्वाधार कार्यहरूको दृष्टिकोणबाट पूर्ण रूपमा उपयुक्त छ। तसर्थ, हामी यसबाट कतै माइग्रेट गर्ने योजना गर्दैनौं, यद्यपि हामीले नियमित कार्यहरू सरल बनाउन र नयाँहरूलाई स्वचालित बनाउन, सेवाहरूको स्थिरता र विश्वसनीयता बढाउन नयाँ अभ्यासहरू र सेवाहरू ल्याइरहेका छौं। , हामी chaoskube प्रयोग गर्छौं, तर यसले अवधारणालाई परिवर्तन गर्दैन: ), जुन मूल रूपमा Netflix द्वारा सिर्जना गरिएको थियो। Chaos Monkey ले एउटा साधारण कुरा गर्छ: यसले अनियमित समयमा एउटा यादृच्छिक Kubernetes पोड मेटाउँछ। यो हाम्रो सेवाको लागि आवश्यक छ उदाहरणहरूको संख्या n-1 संग सामान्य रूपमा बाँच्न, त्यसैले हामी आफैलाई कुनै पनि समस्याहरूको लागि तयार रहन तालिम दिन्छौं।

अब म तेस्रो-पक्ष समाधानहरूको प्रयोग देख्छु - उही क्लाउड प्लेटफर्महरू - युवा कम्पनीहरूको लागि मात्र सही चीजको रूपमा। सामान्यतया, तिनीहरूको यात्राको सुरुमा, तिनीहरू मानव र वित्तीय दुवै स्रोतहरूमा सीमित हुन्छन्, र तिनीहरूको आफ्नै क्लाउड वा डेटा केन्द्र निर्माण र मर्मत गर्न धेरै महँगो र श्रम-गहन हुन्छ। क्लाउड प्रदायकहरूले तपाईंलाई यी लागतहरू कम गर्न अनुमति दिन्छ; तपाईं तिनीहरूबाट यहाँ र अहिले सेवाहरूको सञ्चालनको लागि आवश्यक स्रोतहरू छिटो प्राप्त गर्न सक्नुहुन्छ, र तथ्य पछि यी स्रोतहरूको लागि भुक्तानी गर्नुहोस्। URUS कम्पनीको लागि, हामी अहिलेको लागि क्लाउडमा कुबर्नेट्सप्रति वफादार रहनेछौं। तर कसलाई थाहा छ, हामीले भौगोलिक रूपमा विस्तार गर्नुपर्ने हुन सक्छ, वा केही विशिष्ट उपकरणहरूमा आधारित समाधानहरू लागू गर्नुपर्ने हुन सक्छ। वा हुनसक्छ उपभोग गरिएको स्रोतको मात्राले राम्रो पुरानो दिनहरूमा जस्तै, बेयर-मेटलमा आफ्नै कुबर्नेट्सलाई औचित्य दिनेछ। 🙂

हामीले क्लाउड सेवाहरूसँग काम गरेर के सिक्यौं

हामीले नाङ्गो धातुमा Kubernetes प्रयोग गर्न थाल्यौं, र त्यहाँ पनि यो आफ्नै तरिकामा राम्रो थियो। तर यसको बल क्लाउडमा एएएस कम्पोनेन्टको रूपमा स्पष्ट रूपमा प्रकट गरिएको थियो। यदि तपाईंले लक्ष्य सेट गर्नुभयो र सकेसम्म सबै कुरा स्वचालित गर्नुभयो भने, तपाईं विक्रेता लक-इनबाट बच्न सक्षम हुनुहुनेछ र क्लाउड प्रदायकहरू बीच सार्न केही घण्टा लाग्नेछ, र तंत्रिका कोशिकाहरू हामीसँग रहनेछन्। हामी अन्य कम्पनीहरूलाई सल्लाह दिन सक्छौं: यदि तपाईं आफ्नो (क्लाउड) सेवा सुरु गर्न चाहनुहुन्छ भने, सीमित स्रोतहरू र विकासको लागि अधिकतम वेग, क्लाउड स्रोतहरू भाडामा लिएर अहिले नै सुरू गर्नुहोस्, र फोर्ब्सले तपाईंको बारेमा लेखेपछि तपाईंको डाटा केन्द्र निर्माण गर्नुहोस्।

स्रोत: www.habr.com