DEVOXX UK। उत्पादनमा Kubernetes: निलो/हरियो डिप्लोइमेन्ट, अटोस्केलि and र डिप्लोयमेन्ट स्वचालन। भाग 2

कुबर्नेट्स क्लस्टर उत्पादन वातावरणमा डकर कन्टेनरहरू चलाउनको लागि उत्कृष्ट उपकरण हो। यद्यपि, त्यहाँ समस्याहरू छन् जुन Kubernetes समाधान गर्न सक्दैनन्। बारम्बार उत्पादन डिप्लोइमेन्टहरूका लागि, हामीलाई प्रक्रियामा डाउनटाइमबाट बच्न पूर्ण रूपमा स्वचालित नीलो/हरियो डिप्लोइमेन्ट चाहिन्छ, जसले बाह्य HTTP अनुरोधहरू ह्यान्डल गर्न र SSL अफलोडहरू प्रदर्शन गर्न आवश्यक छ। यसका लागि ha-proxy जस्ता लोड ब्यालेन्सरसँग एकीकरण आवश्यक छ। अर्को चुनौती भनेको क्लाउड वातावरणमा चल्दा कुबेरनेट क्लस्टरको अर्ध-स्वचालित मापन हो, उदाहरणका लागि रातमा क्लस्टरलाई आंशिक रूपमा मापन गर्ने।

जबकि Kubernetes सँग यी सुविधाहरू बाकस बाहिर छैन, यसले एपीआई प्रदान गर्दछ जुन तपाइँ समान समस्याहरू समाधान गर्न प्रयोग गर्न सक्नुहुन्छ। स्वचालित नीलो/हरियो डिप्लोइमेन्ट र कुबर्नेट्स क्लस्टरको स्केलिङका लागि उपकरणहरू क्लाउड आरटीआई परियोजनाको भागको रूपमा विकसित गरिएको थियो, जुन खुला स्रोतमा आधारित बनाइएको थियो।

यो लेख, एक भिडियो ट्रान्सक्रिप्टले तपाइँलाई उत्पादनमा डाउनटाइम बिना git कमिटबाट कोड स्वीकार गर्ने उत्पादन-तयार वातावरण सिर्जना गर्न अन्य खुला स्रोत घटकहरूसँग Kubernetes कसरी सेटअप गर्ने भनेर देखाउँदछ।

DEVOXX UK। उत्पादनमा Kubernetes: निलो/हरियो डिप्लोइमेन्ट, अटोस्केलि and र डिप्लोयमेन्ट स्वचालन। भाग 1

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

Kubernetes एउटा उपकरण होइन जुन बक्स बाहिर उत्पादक रूपमा प्रयोग गर्न सकिन्छ। अवश्य पनि, तपाइँ त्यो गर्न सक्नुहुन्छ, kubectl प्रयोग गर्नुहोस् र यस्तै अन्य, तर अझै पनि API यस प्लेटफर्मको बारेमा सबैभन्दा रोचक र उपयोगी चीज हो। एपीआईलाई कार्यहरूको सेटको रूपमा प्रयोग गरेर, तपाईंले Kubernetes मा गर्न चाहनुभएको लगभग कुनै पनि कुरा पहुँच गर्न सक्नुहुन्छ। kubectl ले पनि REST API प्रयोग गर्दछ।

यो REST हो, त्यसैले तपाइँ यस API सँग काम गर्न कुनै पनि भाषा वा उपकरण प्रयोग गर्न सक्नुहुन्छ, तर तपाइँको जीवन अनुकूलन पुस्तकालयहरूले धेरै सजिलो बनाइनेछ। मेरो टोलीले त्यस्ता २ पुस्तकालयहरू लेखे: एउटा Java/OSGi को लागि र एउटा Go को लागि। दोस्रो प्रायः प्रयोग गरिएको छैन, तर कुनै पनि अवस्थामा तपाईंसँग यी उपयोगी चीजहरू छन्। तिनीहरू आंशिक रूपमा इजाजतपत्र प्राप्त खुला स्रोत परियोजना हुन्। त्यहाँ विभिन्न भाषाहरूको लागि त्यस्ता धेरै पुस्तकालयहरू छन्, त्यसैले तपाईंले आफूलाई उपयुक्त हुनेहरू छनौट गर्न सक्नुहुन्छ।

त्यसोभए, तपाईंले आफ्नो डिप्लोयमेन्ट स्वचालित गर्न सुरु गर्नु अघि, तपाईंले यो सुनिश्चित गर्न आवश्यक छ कि प्रक्रिया कुनै पनि डाउनटाइमको अधीनमा हुनेछैन। उदाहरणका लागि, हाम्रो टोलीले दिनको बीचमा उत्पादन डिप्लोइमेन्टहरू सञ्चालन गर्दछ जब मानिसहरूले उनीहरूको सबैभन्दा धेरै अनुप्रयोगहरू प्रयोग गरिरहेका हुन्छन्, त्यसैले यो प्रक्रियामा ढिलाइबाट बच्न महत्त्वपूर्ण छ। डाउनटाइमबाट बच्नको लागि, 2 विधिहरू प्रयोग गरिन्छ: नीलो/हरियो डिप्लोइमेन्ट वा रोलिङ अपडेट। पछिल्लो अवस्थामा, यदि तपाइँसँग चलिरहेको अनुप्रयोगको 5 प्रतिकृतिहरू छन् भने, तिनीहरू क्रमशः एक पछि अर्को अद्यावधिक हुन्छन्। यो विधिले राम्रो काम गर्छ, तर यो उपयुक्त छैन यदि तपाईंसँग डिप्लोइमेन्ट प्रक्रियाको क्रममा एप्लिकेसनको विभिन्न संस्करणहरू एकैसाथ चलिरहेको छ भने। यस अवस्थामा, ब्याकइन्ड पुरानो संस्करण चलिरहेको बेला तपाईले प्रयोगकर्ता इन्टरफेस अपडेट गर्न सक्नुहुन्छ, र अनुप्रयोगले काम गर्न छोड्नेछ। त्यसैले, दृष्टिकोण को एक प्रोग्रामिंग बिन्दु देखि, यस्तो अवस्थामा काम धेरै गाह्रो छ।

यो एउटा कारण हो कि हामीले हाम्रो एप्लिकेसनहरूको डिप्लोइमेन्टलाई स्वचालित गर्न नीलो/हरियो डिप्लोइमेन्ट प्रयोग गर्न रुचाउँछौं। यस विधिको साथ, तपाईंले एक पटकमा एप्लिकेसनको एउटा मात्र संस्करण सक्रिय छ भनी सुनिश्चित गर्नुपर्छ।

नीलो/हरियो डिप्लोइमेन्ट मेकानिजम यस्तो देखिन्छ। हामीले हा-प्रोक्सी मार्फत हाम्रा एप्लिकेसनहरूका लागि ट्राफिक प्राप्त गर्छौं, जसले यसलाई उही संस्करणको एप्लिकेसनको चलिरहेको प्रतिकृतिहरूमा फर्वार्ड गर्छ।

जब नयाँ परिनियोजन गरिन्छ, हामी डिप्लोयर प्रयोग गर्छौं, जसलाई नयाँ कम्पोनेन्टहरू दिइन्छ र नयाँ संस्करण प्रयोग गर्दछ। एप्लिकेसनको नयाँ संस्करण डिप्लोय गर्नु भनेको प्रतिकृतिहरूको नयाँ सेट "उठाइयो" हो, त्यसपछि नयाँ संस्करणका यी प्रतिकृतिहरू छुट्टै, नयाँ पोडमा लन्च हुन्छन्। यद्यपि, ha-proxy लाई तिनीहरूको बारेमा केही पनि थाहा छैन र उनीहरूलाई कुनै पनि कामको बोझ रुट गर्दैन।

तसर्थ, सबै भन्दा पहिले, प्रतिकृतिहरू लोड सेवा गर्न तयार छन् भनेर सुनिश्चित गर्न स्वास्थ्य जाँचको नयाँ संस्करणहरूको प्रदर्शन जाँच गर्न आवश्यक छ।

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

प्रणालीले प्रमाणित गरेपछि सबै अद्यावधिक गरिएका प्रतिकृतिहरू काम गरिरहेका छन्, डिप्लोयरले कन्फिगरेसन अपडेट गर्नेछ र सही कन्फिगरेसन पास गर्नेछ, जसले ha-proxy पुन: कन्फिगर गर्नेछ।

यस पछि मात्र ट्राफिकलाई नयाँ संस्करणको प्रतिकृतिहरू सहित पोडमा निर्देशित गरिनेछ, र पुरानो पोड गायब हुनेछ।

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

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

त्यसोभए, डिप्लोयरले गर्ने पहिलो कुरा Kubernetes API प्रयोग गरेर RC प्रतिकृति नियन्त्रक सिर्जना गर्नु हो। यस API ले थप तैनातीका लागि पोडहरू र सेवाहरू सिर्जना गर्दछ, त्यो हो, यसले हाम्रा अनुप्रयोगहरूको लागि पूर्ण रूपमा नयाँ क्लस्टर सिर्जना गर्दछ। RC ले प्रतिकृतिहरू सुरु भएको कुरामा विश्वस्त हुने बित्तिकै, यसले तिनीहरूको कार्यक्षमतामा स्वास्थ्य जाँच गर्नेछ। यो गर्नका लागि, डिप्लोयरले GET/health आदेश प्रयोग गर्दछ। यसले उपयुक्त स्क्यान कम्पोनेन्टहरू चलाउँछ र क्लस्टरको सञ्चालनलाई समर्थन गर्ने सबै तत्वहरू जाँच गर्दछ।

सबै पोडहरूले तिनीहरूको स्वास्थ्य रिपोर्ट गरिसकेपछि, डिप्लोयरले नयाँ कन्फिगरेसन तत्व सिर्जना गर्दछ - etcd वितरण गरिएको भण्डारण, जुन कुबर्नेट्स द्वारा आन्तरिक रूपमा प्रयोग गरिन्छ, लोड ब्यालेन्सर कन्फिगरेसन भण्डारण सहित। हामी etcd मा डाटा लेख्छौं, र नयाँ डाटाको लागि confd मोनिटर etcd भनिने सानो उपकरण।

यदि यसले प्रारम्भिक कन्फिगरेसनमा कुनै परिवर्तनहरू पत्ता लगायो भने, यसले नयाँ सेटिङ फाइल उत्पन्न गर्छ र यसलाई ha-proxy मा स्थानान्तरण गर्छ। यस अवस्थामा, ha-proxy कुनै पनि जडानहरू नगुमाई रिबुट गर्दछ र नयाँ सेवाहरूमा लोडलाई सम्बोधन गर्दछ जसले हाम्रो अनुप्रयोगहरूको नयाँ संस्करणलाई काम गर्न सक्षम बनाउँछ।

तपाईले देख्न सक्नुहुन्छ, कम्पोनेन्टहरूको प्रशस्तताको बावजुद, यहाँ केहि जटिल छैन। तपाईंले केवल API र etcd मा थप ध्यान दिन आवश्यक छ। म तपाईलाई खुला स्रोत डिप्लोयरको बारेमा बताउन चाहन्छु जुन हामी आफैले प्रयोग गर्छौं - Amdatu Kubernetes Deployer।

यो Kubernetes डिप्लोयमेन्टहरू अर्केस्ट्रेट गर्ने उपकरण हो र निम्न सुविधाहरू छन्:

• नीलो/हरियो तैनाती;
• बाह्य लोड ब्यालेन्सर स्थापना गर्दै;
• परिनियोजन वर्णनकर्ता व्यवस्थापन;
• वास्तविक तैनाती व्यवस्थापन;
• तैनाती समयमा स्वास्थ्य जाँच को कार्यक्षमता जाँच गर्दै;
• पोडहरूमा वातावरणीय चरहरूको कार्यान्वयन।

यो डिप्लोयर Kubernetes API को शीर्षमा बनाइएको छ र ह्यान्डलहरू र डिप्लोयमेन्टहरू प्रबन्ध गर्नको लागि REST API प्रदान गर्दछ, साथै तैनाती प्रक्रियाको क्रममा स्ट्रिमिङ लगहरूको लागि Websocket API प्रदान गर्दछ।

यसले लोड ब्यालेन्सर कन्फिगरेसन डाटालाई etcd मा राख्छ, त्यसैले तपाईले ha-proxy को आउट-अफ-द-बक्स समर्थनको साथ प्रयोग गर्नु पर्दैन, तर सजिलैसँग आफ्नै लोड ब्यालेन्सर कन्फिगरेसन फाइल प्रयोग गर्नुहोस्। Amdatu Deployer Go मा लेखिएको छ, Kubernetes आफैं जस्तै, र Apache द्वारा इजाजतपत्र दिइएको छ।

मैले डिप्लोयरको यो संस्करण प्रयोग गर्न सुरु गर्नु अघि, मैले निम्न डिप्लोयमेन्ट डिस्क्रिप्टर प्रयोग गरें, जसले मलाई चाहिने प्यारामिटरहरू निर्दिष्ट गर्दछ।

यस कोडको महत्त्वपूर्ण मापदण्डहरू मध्ये एक "useHealthCheck" फ्ल्याग सक्षम गर्नु हो। हामीले निर्दिष्ट गर्न आवश्यक छ कि डिप्लोइमेन्ट प्रक्रियाको बखत सेनिटी चेक गरिनु पर्छ। यो सेटिङ असक्षम गर्न सकिन्छ जब डिप्लोयमेन्टले तेस्रो-पक्ष कन्टेनरहरू प्रयोग गर्दछ जुन प्रमाणीकरण गर्न आवश्यक छैन। यो वर्णनकर्ताले प्रतिकृतिहरूको संख्या र ha-proxy को आवश्यकता पर्ने फ्रन्टएन्ड URL लाई पनि संकेत गर्दछ। अन्तमा पोड स्पेसिफिकेशन फ्ल्याग "पोडस्पेक" छ, जसले पोर्ट कन्फिगरेसन, छवि, इत्यादिमा जानकारीको लागि कुबेरनेटलाई कल गर्छ। यो एकदम सरल JSON वर्णनकर्ता हो।

अर्को उपकरण जुन खुला स्रोत Amdatu परियोजनाको भाग हो Deploymentctl हो। योसँग डिप्लोयमेन्टहरू कन्फिगर गर्न, डिप्लोइमेन्ट इतिहास भण्डारण गर्नको लागि UI छ, र तेस्रो-पक्ष प्रयोगकर्ताहरू र विकासकर्ताहरूबाट कलब्याकहरूको लागि वेबहुकहरू समावेश गर्दछ। तपाईले UI प्रयोग गर्न सक्नुहुन्न किनकि Amdatu Deployer आफैं एक REST API हो, तर यो इन्टरफेसले कुनै पनि API समावेश नगरिकन तपाईको लागि प्रयोगलाई धेरै सजिलो बनाउन सक्छ। Deploymentctl Angular 2 को प्रयोग गरेर OSGi/Vertx मा लेखिएको छ।

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

यहाँ हामी एक HTTP सर्भर सिर्जना गर्दैछौं जसले /स्वास्थ्यमा मात्र प्रतिक्रिया दिन्छ, त्यसैले यो अनुप्रयोगले स्वास्थ्य जाँच मात्र परीक्षण गर्छ र अरू केही होइन। यदि चेक पास भयो भने, तल देखाइएको JSON संरचना प्रयोग गरिन्छ। यसले एपको संस्करण समावेश गर्दछ जुन डिप्लोयरद्वारा डिप्लोइड हुनेछ, तपाईंले फाइलको शीर्षमा देख्नुभएको सन्देश, र बुलियन डाटा प्रकार - हाम्रो एपले काम गरिरहेको छ वा छैन।

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

त्यसैले सुरु गरौं। पहिले, हामी कमाण्ड ~ kubectl get pods प्रयोग गरेर कुनै पनि चलिरहेको पोडहरूको उपस्थितिको लागि जाँच गर्छौं र, फ्रन्टएन्ड URL बाट प्रतिक्रियाको अनुपस्थितिको आधारमा, हामी निश्चित गर्छौं कि हाल कुनै पनि डिप्लोयमेन्टहरू भइरहेको छैन।

स्क्रिनमा अर्को तपाईंले मैले उल्लेख गरेको Deploymentctl इन्टरफेस देख्नुहुन्छ, जसमा डिप्लोयमेन्ट प्यारामिटरहरू सेट गरिएको छ: नेमस्पेस, एप्लिकेसन नाम, डिप्लोयमेन्ट संस्करण, प्रतिकृतिहरूको संख्या, फ्रन्ट-एन्ड URL, कन्टेनरको नाम, छवि, स्रोत सीमा, स्वास्थ्य जाँचको लागि पोर्ट नम्बर, आदि। संसाधन सीमाहरू धेरै महत्त्वपूर्ण छन्, किनकि तिनीहरूले तपाईंलाई हार्डवेयरको अधिकतम सम्भावित मात्रा प्रयोग गर्न अनुमति दिन्छ। यहाँ तपाइँ डिप्लोयमेन्ट लग पनि हेर्न सक्नुहुन्छ।

यदि तपाइँ अब आदेश दोहोर्याउनु भयो भने ~ kubectl get pods, तपाइँले देख्न सक्नुहुन्छ कि प्रणाली 20 सेकेन्डको लागि "फ्रिज" हुन्छ, जुन समयमा ha-proxy पुन: कन्फिगर हुन्छ। यस पछि, पोड सुरु हुन्छ, र हाम्रो प्रतिकृति डिप्लोयमेन्ट लगमा देख्न सकिन्छ।

मैले भिडियोबाट 20 सेकेन्ड पर्खाइ काटें, र अब तपाईंले स्क्रिनमा देख्न सक्नुहुन्छ कि अनुप्रयोगको पहिलो संस्करण तैनाथ गरिएको छ। यो सबै UI प्रयोग गरेर मात्र गरिएको थियो।

अब दोस्रो संस्करण प्रयास गरौं। यो गर्नको लागि, म "नमस्ते, Kubernetes!" बाट अनुप्रयोगको सन्देश परिवर्तन गर्छु। "Hello, Deployer!" मा, प्रणालीले यो छवि सिर्जना गर्छ र यसलाई डकर रजिस्ट्रीमा राख्छ, जस पछि हामी Deploymentctl विन्डोमा "Deploy" बटनमा क्लिक गर्छौं। यस अवस्थामा, डिप्लोइमेन्ट लग स्वचालित रूपमा सुरु हुन्छ जसरी अनुप्रयोगको पहिलो संस्करण प्रयोग गर्दा भएको थियो।

कमाण्ड ~ kubectl get pods ले देखाउँछ कि त्यहाँ अनुप्रयोगको 2 संस्करणहरू चलिरहेको छ, तर फ्रन्टएन्डले देखाउँछ कि हामी अझै पनि संस्करण 1 चलिरहेको छ।

लोड ब्यालेन्सरले नयाँ संस्करणमा ट्राफिक रिडिरेक्ट गर्नु अघि स्वास्थ्य जाँच पूरा हुनको लागि पर्खन्छ। 20 सेकेन्ड पछि, हामी कर्लमा स्विच गर्छौं र देख्छौं कि हामीसँग एपको संस्करण 2 प्रयोग गरिएको छ, र पहिलो मेटाइएको छ।

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

तपाईले देख्न सक्नुहुन्छ, डिप्लोइमेन्ट माथिका सबै चरणहरू मार्फत जान्छ र ~ kubectl get pods ले दुबै पोडहरू चलिरहेको देखाउँदछ। तर अघिल्लो परिनियोजनको विपरीत, लगले टाइमआउट स्थिति देखाउँछ। त्यो हो, स्वास्थ्य जाँच असफल भएको तथ्यका कारण, अनुप्रयोगको नयाँ संस्करण प्रयोग गर्न सकिँदैन। नतिजाको रूपमा, तपाईंले देख्नुहुन्छ कि प्रणाली अनुप्रयोगको पुरानो संस्करण प्रयोग गर्न फर्किएको छ, र नयाँ संस्करण मात्र स्थापना रद्द गरिएको छ।

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

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

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

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

एकै समयमा, काम गर्ने घण्टाको समयमा तपाईले बढाउनु पर्ने हुन सक्छ, र रातमा, Amazon सेवाहरूको लागत घटाउनको लागि, तपाईले चलिरहेको अनुप्रयोग उदाहरणहरूको संख्या घटाउन आवश्यक पर्दछ। यसको मतलब यो होइन कि पोडहरूको संख्या मात्र मापन गर्न पर्याप्त हुनेछ, किनकि यदि नोडहरू मध्ये एउटा निष्क्रिय छ भने, तपाईंले अझै पनि यसको लागि Amazon तिर्नुपर्नेछ। त्यो हो, पोडहरू स्केलिङको साथमा, तपाईंले प्रयोग गरिएका मेसिनहरूको संख्या मापन गर्न आवश्यक छ।

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

त्यसैले हामीले नोड र पोड दुवैको ख्याल राख्नुपर्छ। हामी Kubernetes कार्यकर्ता नोडहरूको संख्या कन्फिगर गर्न AWS API र स्केलिंग समूह मिसिनहरू प्रयोग गरेर नयाँ नोडहरूको सुरुवात सजिलैसँग गर्न सक्छौं। कुबेरनेट क्लस्टरमा नोडहरू दर्ता गर्न तपाईंले क्लाउड-इनिट वा समान स्क्रिप्ट पनि प्रयोग गर्न सक्नुहुन्छ।

नयाँ मेसिन स्केलिंग समूहमा सुरु हुन्छ, नोडको रूपमा सुरु हुन्छ, मास्टरको रजिस्ट्रीमा दर्ता हुन्छ र काम गर्न थाल्छ। यस पछि, तपाईंले नतिजा नोडहरूमा प्रयोगको लागि प्रतिकृतिहरूको संख्या बढाउन सक्नुहुन्छ। स्केलिंग डाउन गर्न थप प्रयास चाहिन्छ, किनकि तपाईंले यो सुनिश्चित गर्न आवश्यक छ कि यस्तो कदमले "अनावश्यक" मेसिनहरू बन्द गरेपछि पहिले नै चलिरहेको अनुप्रयोगहरूको विनाशको नेतृत्व गर्दैन। यस्तो परिदृश्य रोक्नको लागि, तपाईंले नोडहरूलाई "अनशेड्युल" स्थितिमा सेट गर्न आवश्यक छ। यसको मतलब यो हो कि पूर्वनिर्धारित अनुसूचकले डेमनसेट पोडहरू अनुसूचित गर्दा यी नोडहरूलाई बेवास्ता गर्नेछ। अनुसूचकले यी सर्भरहरूबाट केही पनि मेटाउने छैन, तर त्यहाँ कुनै नयाँ कन्टेनरहरू पनि लन्च गर्नेछैन। अर्को चरण ड्रेन नोडलाई बाहिर निकाल्नु हो, त्यो हो, चलिरहेको पोडहरू यसबाट अर्को मेसिनमा स्थानान्तरण गर्न, वा यसका लागि पर्याप्त क्षमता भएका अन्य नोडहरू। एकचोटि तपाईंले यी नोडहरूमा अब कुनै कन्टेनरहरू छैनन् भनी सुनिश्चित गरिसकेपछि, तपाईंले तिनीहरूलाई Kubernetes बाट हटाउन सक्नुहुन्छ। यस पछि, तिनीहरू बस Kubernetes को लागि अस्तित्व बन्द हुनेछ। अर्को, तपाईंले अनावश्यक नोडहरू वा मेसिनहरू असक्षम गर्न AWS API प्रयोग गर्न आवश्यक छ।
तपाईले Amdatu Scalerd, AWS API जस्तै अर्को खुला स्रोत स्केलिंग उपकरण प्रयोग गर्न सक्नुहुन्छ। यसले क्लस्टरमा नोडहरू थप्न वा हटाउन CLI प्रदान गर्दछ। यसको चाखलाग्दो सुविधा निम्न json फाइल प्रयोग गरेर शेड्यूलर कन्फिगर गर्ने क्षमता हो।

देखाइएको कोडले रातको अवधिमा क्लस्टर क्षमता आधाले घटाउँछ। यसले उपलब्ध प्रतिकृतिहरूको संख्या र अमेजन क्लस्टरको इच्छित क्षमता दुवै कन्फिगर गर्दछ। यो शेड्युलर प्रयोग गर्नाले स्वचालित रूपमा रातमा नोडहरूको संख्या घटाउनेछ र बिहान बढ्दै जान्छ, अमेजन जस्ता क्लाउड सेवाबाट नोडहरू प्रयोग गर्दा लागत बचत हुन्छ। यो सुविधा Kubernetes मा निर्मित छैन, तर Scalerd प्रयोग गरेर तपाईंलाई यो प्लेटफर्म मापन गर्न अनुमति दिन्छ जुन तपाईं चाहनुहुन्छ।

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

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

विषय टुङ्ग्याउनको लागि, म तपाईंलाई मेरो टोलीले काम गरिरहेको Kubernetes मा आधारित Cloud RTI प्लेटफर्ममा परिचय गराउन चाहन्छु। यसले केन्द्रीकृत लगिङ, एप्लिकेसन र क्लस्टर निगरानी, ​​र काममा आउने अन्य धेरै उपयोगी सुविधाहरू प्रदान गर्दछ। यसले अनुगमन प्रदर्शन गर्न Grafana जस्ता विभिन्न खुला स्रोत उपकरणहरू प्रयोग गर्दछ।

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

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

केही विज्ञापनहरू 🙂

हामीसँग रहनु भएकोमा धन्यवाद। तपाईलाई हाम्रा लेखहरू मनपर्छ? थप रोचक सामग्री हेर्न चाहनुहुन्छ? हामीलाई अर्डर गरेर वा साथीहरूलाई सिफारिस गरेर समर्थन गर्नुहोस्, $4.99 बाट विकासकर्ताहरूको लागि क्लाउड VPS, प्रविष्टि-स्तर सर्भरहरूको एक अद्वितीय एनालग, जुन हामीले तपाईंको लागि आविष्कार गरेको हो: VPS (KVM) E5-2697 v3 (6 कोर) 10GB DDR4 480GB SSD 1Gbps $ 19 बाट वा कसरी सर्भर साझा गर्ने बारे सम्पूर्ण सत्य? (RAID1 र RAID10 सँग उपलब्ध, 24 कोर सम्म र 40GB DDR4 सम्म)।

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 बाट नेदरल्याण्ड मा! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com