Kubernetes मा पहिलो अनुप्रयोग तैनात गर्दा पाँच छुटेको छ

Aris-Dreamer द्वारा असफल

धेरै मानिसहरू विश्वास गर्छन् कि यो अनुप्रयोगलाई कुबेरनेटमा स्थानान्तरण गर्न पर्याप्त छ (या त हेल्म वा म्यानुअल रूपमा) र तिनीहरू खुसी हुनेछन्। तर यो त्यति सरल छैन।

टोली Mail.ru क्लाउड समाधान DevOps इन्जिनियर जुलियन Gindi द्वारा एक लेख अनुवाद। उसले माइग्रेसन प्रक्रियाको क्रममा आफ्नो कम्पनीले सामना गरेको समस्याहरू साझा गर्दछ ताकि तपाईं एउटै रेकमा पाइला नपरोस्।

चरण एक: पोड अनुरोध र सीमाहरू सेट अप गर्दै

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

पोड अनुरोधहरू - यो पोडलाई इष्टतम रूपमा राख्नको लागि अनुसूचकले प्रयोग गरेको मुख्य मान हो।

Из Kubernetes दस्तावेज: फिल्टरिङ चरणले नोडहरूको सेट निर्धारण गर्दछ जहाँ पोड अनुसूचित गर्न सकिन्छ। उदाहरणका लागि, PodFitsResources फिल्टरले पोडको विशेष स्रोत अनुरोधहरू पूरा गर्न नोडसँग पर्याप्त स्रोतहरू छन् कि छैनन् भनी जाँच गर्दछ।

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

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

पोड सीमा - यो पोड को लागी एक स्पष्ट सीमा हो। यसले क्लस्टरले कन्टेनरमा आवंटित गर्ने स्रोतहरूको अधिकतम मात्रालाई प्रतिनिधित्व गर्दछ।

फेरि, बाट आधिकारिक दस्तावेज: यदि कन्टेनरमा 4 GiB मेमोरी सीमा सेट छ भने, कुबेलेट (र कन्टेनर रनटाइम) ले यसलाई लागू गर्नेछ। रनटाइमले कन्टेनरलाई निर्दिष्ट स्रोत सीमा भन्दा बढी प्रयोग गर्न अनुमति दिँदैन। उदाहरणका लागि, जब कन्टेनरमा भएको प्रक्रियाले अनुमति दिइएको मात्राभन्दा बढी मेमोरी प्रयोग गर्ने प्रयास गर्छ, प्रणाली कर्नेलले "मेमोरी बाहिर" (OOM) त्रुटिको साथ प्रक्रिया समाप्त गर्छ।

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

आदर्श रूपमा, हामी प्रणालीमा अन्य प्रक्रियाहरूमा हस्तक्षेप नगरी प्रक्रियाको जीवनचक्रमा पोडको स्रोत आवश्यकताहरू परिवर्तन गर्न चाहन्छौं — त्यो सीमाहरू सेट गर्ने लक्ष्य हो।

दुर्भाग्यवश, म कुन मानहरू सेट गर्ने भनेर विशेष निर्देशन दिन सक्दिन, तर हामी आफैंले निम्न नियमहरू पालना गर्छौं:

1. लोड परीक्षण उपकरण प्रयोग गरेर, हामी ट्राफिकको आधारभूत स्तर अनुकरण गर्छौं र पोड स्रोतहरू (मेमोरी र प्रोसेसर) को प्रयोग निगरानी गर्छौं।
2. हामीले पोड अनुरोधहरूलाई स्वेच्छाचारी रूपमा कम मूल्यमा सेट गर्छौं (अनुरोधहरूको मूल्यको लगभग 5 गुणाको स्रोत सीमाको साथ) र अवलोकन गर्छौं। जब अनुरोधहरू धेरै कम हुन्छन्, प्रक्रिया सुरु हुन सक्दैन, प्रायः रहस्यमय Go रनटाइम त्रुटिहरू निम्त्याउँछ।

ध्यान दिनुहोस् कि उच्च स्रोत सीमाहरूले समय तालिकालाई अझ गाह्रो बनाउँछ किनभने पोडलाई पर्याप्त स्रोतहरू उपलब्ध भएको लक्ष्य नोड चाहिन्छ।

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

चरण दुई: जीवन्तता र तयारी परीक्षणहरू सेटअप गर्नुहोस्

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

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

लाइभनेस प्रोबहरू सस्तो हुनुपर्छ, यसको मतलब तिनीहरूले धेरै स्रोतहरू उपभोग गर्नु हुँदैन, किनभने तिनीहरू बारम्बार चल्छन् र कुबेरनेटलाई अनुप्रयोग चलिरहेको छ भनेर सूचित गर्न आवश्यक छ।

यदि तपाइँ प्रत्येक सेकेन्ड चलाउन विकल्प सेट गर्नुहुन्छ भने, यसले प्रति सेकेन्ड 1 अनुरोध थप्नेछ, त्यसैले यो ट्राफिक ह्यान्डल गर्न थप स्रोतहरू आवश्यक पर्नेछ भनेर सचेत रहनुहोस्।

हाम्रो कम्पनीमा, Liveness परीक्षणहरूले डाटा (उदाहरणका लागि, रिमोट डाटाबेस वा क्यासबाट) पूर्ण रूपमा पहुँचयोग्य नभए तापनि एप्लिकेसनको मुख्य भागहरू जाँच गर्दछ।

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

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

रेडिनेस प्रोबहरूले थप स्रोतहरू उपभोग गर्छन् किनभने तिनीहरू ब्याकइन्डमा पठाइनु पर्छ जसले अनुप्रयोग अनुरोधहरू स्वीकार गर्न तयार छ भन्ने संकेत गर्दछ।

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

यदि तपाइँ तपाइँको आवेदन को तत्परता परीक्षण गर्न डाटाबेस क्वेरी गर्ने निर्णय गर्नुहुन्छ भने, निश्चित गर्नुहोस् कि यो सकेसम्म सस्तो छ। यो अनुरोध गरौं:

SELECT small_item FROM table LIMIT 1

यहाँ हामीले यी दुई मानहरू Kubernetes मा कसरी कन्फिगर गर्छौं भन्ने एउटा उदाहरण हो:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

तपाइँ केहि अतिरिक्त कन्फिगरेसन विकल्पहरू थप्न सक्नुहुन्छ:

• initialDelaySeconds - कन्टेनरको प्रक्षेपण र नमूनाहरूको सुरुवात बीच कति सेकेन्डहरू बित्नेछ।
• periodSeconds - नमूना रन बीच प्रतीक्षा अन्तराल।
• timeoutSeconds - सेकेन्ड को संख्या जस पछि एकाइ आपतकालीन मानिन्छ। नियमित टाइमआउट।
• failureThreshold - पुन: सुरु संकेत पोडमा पठाइनु अघि परीक्षण विफलताहरूको संख्या।
• successThreshold - पोड तयार अवस्थामा जानु अघि सफल प्रोबहरूको संख्या (असफलता पछि, जब पोड सुरु हुन्छ वा पुन: प्राप्त हुन्छ)।

चरण तीन: पोडको लागि पूर्वनिर्धारित नेटवर्क नीतिहरू सेटअप गर्नुहोस्

Kubernetes सँग "फ्ल्याट" नेटवर्क टोपोग्राफी छ; पूर्वनिर्धारित रूपमा, सबै पोडहरू एक अर्कासँग सीधा सञ्चार गर्छन्। केही अवस्थामा यो वांछनीय छैन।

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

उदाहरणका लागि, तल एउटा साधारण नीति छ जसले विशिष्ट नेमस्पेसको लागि सबै आगमन ट्राफिकलाई अस्वीकार गर्छ:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

यस कन्फिगरेसनको दृश्यावलोकन:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
थप विवरणहरू यहाँ.

चरण चार: हुक र इनिट कन्टेनरहरू प्रयोग गरेर अनुकूलन व्यवहार

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

विशेष कठिनाइहरू देखा पर्‍यो निजिनक्स। हामीले याद गर्यौं कि जब यी पोडहरू क्रमिक रूपमा तैनात गरियो, सक्रिय जडानहरू सफल समाप्ति अघि छोडियो।

व्यापक अनुसन्धान अनलाइन पछि, यो बाहिर निस्कन्छ कि कुबर्नेट्स पोड समाप्त गर्नु अघि Nginx जडानहरू आफैं समाप्त हुनको लागि पर्खदैन। प्रि-स्टप हुक प्रयोग गरेर, हामीले निम्न कार्यक्षमता लागू गर्यौं र डाउनटाइमबाट पूर्ण रूपमा छुटकारा पायौं:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

तर nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

अर्को अत्यन्त उपयोगी प्रतिमान विशेष अनुप्रयोगहरूको स्टार्टअप ह्यान्डल गर्न init कन्टेनरहरूको प्रयोग हो। यो विशेष गरी उपयोगी छ यदि तपाइँसँग संसाधन-गहन डाटाबेस माइग्रेसन प्रक्रिया छ जुन अनुप्रयोग सुरु हुनु अघि चलाउन आवश्यक छ। तपाईंले मुख्य अनुप्रयोगको लागि यस्तो सीमा सेट नगरी यस प्रक्रियाको लागि उच्च स्रोत सीमा पनि निर्दिष्ट गर्न सक्नुहुन्छ।

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

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

चरण पाँच: कर्नेल कन्फिगर गर्दै

अन्तमा, अझ उन्नत प्रविधिको बारेमा कुरा गरौं।

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

यद्यपि, Kubernetes ले तपाईंलाई विशेष पोडको लागि मात्र कर्नेल प्यारामिटरहरू परिवर्तन गर्ने विशेषाधिकार प्राप्त कन्टेनर चलाउन अनुमति दिन्छ। यहाँ हामीले खुला जडानहरूको अधिकतम संख्या परिवर्तन गर्न प्रयोग गरेको कुरा हो:

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

निष्कर्षमा

जबकि Kubernetes बाकस बाहिर एक तयार समाधान जस्तो लाग्न सक्छ, त्यहाँ केहि प्रमुख चरणहरू छन् जुन तपाईंले आफ्नो अनुप्रयोगहरू सुचारु रूपमा चलिरहेको राख्नको लागि लिन आवश्यक छ।

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

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

सधैं आफैलाई यी प्रश्नहरू सोध्नुहोस्:

1. अनुप्रयोगहरूले कति स्रोतहरू उपभोग गर्छन् र यो भोल्युम कसरी परिवर्तन हुनेछ?
2. वास्तविक स्केलिंग आवश्यकताहरू के हुन्? एपले औसतमा कति ट्राफिक ह्यान्डल गर्नेछ? शिखर ट्राफिकको बारेमा के हो?
3. कति पटक सेवा तेर्सो मापन गर्न आवश्यक हुनेछ? ट्राफिक प्राप्त गर्न कति चाँडो नयाँ पोडहरू अनलाइन ल्याउन आवश्यक छ?
4. पोडहरू कसरी सही रूपमा बन्द हुन्छन्? के यो सबै आवश्यक छ? के यो डाउनटाइम बिना तैनाती प्राप्त गर्न सम्भव छ?
5. तपाईं कसरी सुरक्षा जोखिमहरू कम गर्न सक्नुहुन्छ र कुनै पनि सम्झौता पोडहरूबाट हुने क्षतिलाई सीमित गर्न सक्नुहुन्छ? के कुनै सेवाहरूसँग अनुमति वा पहुँच छ जुन उनीहरूलाई आवश्यक छैन?

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

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

अरु के पढ्ने:

1. उत्पादन वातावरणमा कन्टेनर र Kubernetes चलाउनका लागि उत्तम अभ्यासहरू र उत्तम अभ्यासहरू.
2. Kubernetes को लागि 90+ उपयोगी उपकरणहरू: तैनाती, व्यवस्थापन, निगरानी, ​​सुरक्षा र थप.
3. Telegram मा Kubernetes को आसपास हाम्रो च्यानल.

स्रोत: www.habr.com