Kubernetes उत्कृष्ट अभ्यासहरू। साना कन्टेनरहरू सिर्जना गर्दै

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

यद्यपि यो प्रविधि सुरु गर्नको लागि उत्कृष्ट छ, पूर्वनिर्धारित आधार छविहरू प्रयोग गर्दा कमजोरीहरूले भरिएका ठूला छविहरूसँग असुरक्षित कार्य हुन सक्छ।

थप रूपमा, डकरमा धेरै छविहरूले आधार छविको लागि डेबियन वा उबुन्टु प्रयोग गर्दछ, र यसले उत्कृष्ट अनुकूलता र सजिलो अनुकूलन प्रदान गर्दछ (एक डकर फाइलले कोडको दुई लाइन मात्र लिन्छ), आधार छविहरूले तपाईंको कन्टेनरमा सयौं मेगाबाइट अतिरिक्त लोड थप्न सक्छ। उदाहरणका लागि, Go "hello-world" अनुप्रयोगको लागि एउटा साधारण node.js फाइल लगभग 700 मेगाबाइट हुन्छ, जबकि तपाईंको वास्तविक अनुप्रयोग आकारमा केही मेगाबाइट मात्र हुन्छ।

त्यसैले यो सबै अतिरिक्त कार्यभार भनेको डिजिटल स्पेसको बर्बादी र सुरक्षा कमजोरी र बगहरूका लागि ठूलो लुक्ने ठाउँ हो। त्यसोभए कन्टेनर छविको आकार घटाउने दुई तरिकाहरू हेरौं।

पहिलो सानो आधार छविहरूको प्रयोग हो, दोस्रो बिल्डर ढाँचाको प्रयोग हो। साना आधार तस्बिरहरू प्रयोग गरेर तपाईंको कन्टेनरको साइज घटाउने सबैभन्दा सजिलो तरिका हो। सम्भवतः, तपाईले प्रयोग गरिरहनु भएको भाषा वा स्ट्याकले मौलिक अनुप्रयोग छवि प्रदान गर्दछ जुन पूर्वनिर्धारित छवि भन्दा धेरै सानो छ। हाम्रो node.js कन्टेनरमा एक नजर राखौं।

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

सानो आधार छविमा सार्नको लागि, नयाँ आधार छविसँग काम सुरु गर्न केवल डकरफाइल अपडेट गर्नुहोस्:

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

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

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

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

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

तपाईंले यो डकर फाइलमा केहि अनौठो देख्न सक्नुहुन्छ: यसले दुई FROM लाइनहरू समावेश गर्दछ। पहिलो 4 रेखा खण्ड अघिल्लो डकरफाइल जस्तै ठ्याक्कै उस्तै देखिन्छ बाहेक यसले यस चरणको नाम दिन AS कुञ्जी शब्द प्रयोग गर्दछ। अर्को खण्डमा नयाँ छवि सुरु गर्नको लागि नयाँ FROM लाइन छ, जहाँ golang:alpine छविको सट्टा हामी आधार छविको रूपमा Raw alpine प्रयोग गर्नेछौं।

कच्चा अल्पाइन लिनक्समा कुनै पनि SSL प्रमाणपत्रहरू स्थापना गरिएको छैन, जसले HTTPS मार्फत धेरै API कलहरू असफल हुनेछ, त्यसैले केही रूट CA प्रमाणपत्रहरू स्थापना गरौं।

अब रमाइलो भाग आउँछ: कम्पाइल गरिएको कोडलाई पहिलो कन्टेनरबाट दोस्रोमा प्रतिलिपि गर्न, तपाइँ केवल दोस्रो खण्डको लाइन 5 मा अवस्थित COPY आदेश प्रयोग गर्न सक्नुहुन्छ। यसले एउटा अनुप्रयोग फाइल मात्र प्रतिलिपि गर्नेछ र Go उपयोगिता उपकरणहरूलाई असर गर्दैन। नयाँ बहु-चरण डकर फाइलले कन्टेनर छवि समावेश गर्दछ जुन आकारमा 12 मेगाबाइट मात्र छ, मूल कन्टेनर छवि 700 मेगाबाइटको तुलनामा, जुन ठूलो भिन्नता हो!
त्यसैले सानो आधार छविहरू र बिल्डर ढाँचा प्रयोग गरेर धेरै काम बिना धेरै साना कन्टेनरहरू सिर्जना गर्न उत्कृष्ट तरिकाहरू छन्।
यो सम्भव छ कि एप्लिकेसन स्ट्याकको आधारमा, छवि र कन्टेनरको आकार घटाउने अतिरिक्त तरिकाहरू छन्, तर के साना कन्टेनरहरूमा साँच्चै मापनयोग्य फाइदा छ? दुई क्षेत्रहरू हेरौं जहाँ साना कन्टेनरहरू अत्यन्त प्रभावकारी छन् - प्रदर्शन र सुरक्षा।

कार्यसम्पादन वृद्धिको मूल्याङ्कन गर्न, कन्टेनर सिर्जना गर्ने प्रक्रियाको अवधिलाई विचार गर्नुहोस्, यसलाई रजिस्ट्री (पुश) मा घुसाउनुहोस्, र त्यसपछि त्यहाँबाट पुन: प्राप्त गर्नुहोस् (तान्नुहोस्)। तपाईले देख्न सक्नुहुन्छ कि सानो कन्टेनरको ठूलो कन्टेनर भन्दा फरक फाइदा छ।

डकरले तहहरू क्यास गर्नेछ त्यसैले पछिल्लो निर्माणहरू धेरै छिटो हुनेछन्। यद्यपि, कन्टेनरहरू निर्माण र परीक्षण गर्न प्रयोग गरिएका धेरै सीआई प्रणालीहरूले तहहरू क्यास गर्दैनन्, त्यसैले त्यहाँ महत्त्वपूर्ण समय बचतहरू छन्। तपाईले देख्न सक्नुहुने रूपमा, तपाईको मेसिनको शक्तिमा निर्भर गर्दै ठूलो कन्टेनर निर्माण गर्ने समय 34 देखि 54 सेकेन्डसम्म छ, र कन्टेनर प्रयोग गर्दा बिल्डर ढाँचा प्रयोग गरेर घटाइन्छ - 23 देखि 28 सेकेन्डसम्म। यस प्रकारको सञ्चालनको लागि, उत्पादकता वृद्धि 40-50% हुनेछ। त्यसोभए सोच्नुहोस् कि तपाइँ कति पटक तपाइँको कोड निर्माण र परीक्षण गर्नुहोस्।

कन्टेनर बनिसकेपछि, तपाईंले यसको छवि (पुश कन्टेनर छवि) कन्टेनर रजिस्ट्रीमा पुश गर्न आवश्यक छ ताकि तपाईंले यसलाई आफ्नो Kubernetes क्लस्टरमा प्रयोग गर्न सक्नुहुन्छ। म गुगल कन्टेनर रजिस्ट्री प्रयोग गर्न सिफारिस गर्दछु।

Google कन्टेनर रजिस्ट्री (GCR) को साथ, तपाईंले कच्चा भण्डारण र नेटवर्किङका लागि मात्र भुक्तानी गर्नुहुन्छ, र त्यहाँ कुनै अतिरिक्त कन्टेनर व्यवस्थापन शुल्कहरू छैनन्। यो निजी, सुरक्षित र धेरै छिटो छ। GCR ले पुल अपरेशनलाई गति दिन धेरै चालहरू प्रयोग गर्दछ। तपाईंले देख्न सक्नुहुने रूपमा, go:onbuild प्रयोग गरेर डकर कन्टेनर छवि कन्टेनर घुसाउन 15 देखि 48 सेकेन्डसम्म लाग्नेछ, कम्प्युटरको कार्यसम्पादनमा निर्भर गर्दछ, र सानो कन्टेनरमा उही अपरेशनले 14 देखि 16 सेकेन्डसम्म लिन्छ, र कम उत्पादक मेसिनहरूको लागि। सञ्चालन गति मा लाभ 3 गुणा बढ्छ। ठूला मेसिनहरूको लागि, समय लगभग उस्तै छ, किनकि GCR ले छविहरूको साझा डाटाबेसको लागि विश्वव्यापी क्यास प्रयोग गर्दछ, यसको मतलब तपाईंले तिनीहरूलाई लोड गर्न आवश्यक छैन। कम पावर कम्प्युटरमा, CPU बाधा हो, त्यसैले साना कन्टेनरहरू प्रयोग गर्ने फाइदा यहाँ धेरै ठूलो छ।

यदि तपाइँ GCR प्रयोग गर्दै हुनुहुन्छ भने, म तपाइँको निर्माण प्रणालीको भागको रूपमा Google कन्टेनर बिल्डर (GCB) प्रयोग गर्न सिफारिस गर्दछु।

तपाईले देख्न सक्नुहुने रूपमा, यसको प्रयोगले तपाईलाई उत्पादनशील मेसिनको तुलनामा बिल्ड + पुश अपरेशनको अवधि घटाउन धेरै राम्रो नतिजाहरू प्राप्त गर्न अनुमति दिन्छ - यस अवस्थामा, होस्टमा कन्टेनरहरू निर्माण र पठाउने प्रक्रिया लगभग 2 गुणाले द्रुत हुन्छ। । साथै, तपाईले हरेक दिन 120 नि:शुल्क निर्माण मिनेट पाउनु हुन्छ, जसले तपाईको कन्टेनर बिल्डिंग आवश्यकताहरू प्राय जसो केसहरूमा समेट्छ।

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

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

यस तुलनामा एक नजर राख्नुहोस्: साना कन्टेनरहरूमा पुल अपरेशनले 4-9 गुणा कम समय लिन्छ, मेसिनको शक्तिमा निर्भर गर्दै, go:onbuild प्रयोग गरी उही सञ्चालन भन्दा। साझा गरिएको, साना कन्टेनर आधार छविहरू प्रयोग गरेर नयाँ Kubernetes नोडहरू तैनात गर्न र अनलाइन आउन सक्ने समय र गतिलाई उल्लेखनीय रूपमा गति दिन्छ।

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

नतिजा अचम्मको छ: सानो कन्टेनरमा केवल 3 मध्यम जोखिमहरू पत्ता लगाइयो, र 16 महत्वपूर्ण र 376 अन्य कमजोरीहरू ठूलो कन्टेनरमा फेला परे। यदि हामीले ठूलो कन्टेनरको सामग्री हेर्‍यौं भने, हामी देख्न सक्छौं कि धेरैजसो सुरक्षा समस्याहरूको हाम्रो अनुप्रयोगसँग कुनै सरोकार छैन, तर हामीले प्रयोग नगर्ने कार्यक्रमहरूसँग सम्बन्धित छ। त्यसोभए जब मानिसहरूले ठूलो आक्रमण सतहको बारेमा कुरा गर्छन्, तिनीहरूको मतलब यही हो।

टेकअवे स्पष्ट छ: साना कन्टेनरहरू बनाउनुहोस् किनभने तिनीहरूले तपाईंको प्रणालीमा वास्तविक प्रदर्शन र सुरक्षा लाभहरू प्रदान गर्छन्।

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