🥇कुबेरनेट्स पर पहला एप्लिकेशन तैनात करते समय पांच मिस

आरिस ड्रीमर द्वारा विफल

बहुत से लोग सोचते हैं कि एप्लिकेशन को कुबेरनेट्स (या तो हेल्म या मैन्युअल रूप से) में स्थानांतरित करना पर्याप्त है - और खुशी होगी। लेकिन सब कुछ इतना आसान नहीं है.

टीम Mail.ru क्लाउड सॉल्यूशंस DevOps इंजीनियर जूलियन गिंडी के एक लेख का अनुवाद किया। वह बताता है कि माइग्रेशन प्रक्रिया के दौरान उनकी कंपनी को किन नुकसानों का सामना करना पड़ा ताकि आप उसी रेक पर कदम न रखें।

चरण एक: पॉड अनुरोध और सीमाएँ सेट करें

आइए एक स्वच्छ वातावरण स्थापित करके शुरुआत करें जहां हमारे पॉड्स चलेंगे। कुबेरनेट्स पॉड शेड्यूलिंग और फेलओवर में बहुत अच्छा है। लेकिन यह पता चला कि अनुसूचक कभी-कभी पॉड नहीं लगा सकता है यदि यह अनुमान लगाना मुश्किल है कि इसे सफलतापूर्वक काम करने के लिए कितने संसाधनों की आवश्यकता है। यहीं पर संसाधनों और सीमाओं के लिए अनुरोध पॉप अप होते हैं। अनुरोधों और सीमाओं को निर्धारित करने के सर्वोत्तम तरीके के बारे में बहुत बहस हुई है। कभी-कभी ऐसा लगता है कि यह वास्तव में विज्ञान से अधिक एक कला है। यहाँ हमारा दृष्टिकोण है।

पॉड अनुरोध करता है शेड्यूलर द्वारा पॉड को इष्टतम रूप से रखने के लिए उपयोग किया जाने वाला मुख्य मूल्य है।

की कुबेरनेट्स प्रलेखन: फ़िल्टर चरण नोड्स के एक सेट को परिभाषित करता है जहां एक पॉड को शेड्यूल किया जा सकता है। उदाहरण के लिए, PodFitsResources फ़िल्टर यह देखने के लिए जाँच करता है कि क्या नोड के पास पॉड से विशिष्ट संसाधन अनुरोधों को पूरा करने के लिए पर्याप्त संसाधन हैं।

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

इस मामले में, शेड्यूलर अक्सर पॉड्स को "निचोड़" देगा और उन्हें पुनर्निर्धारित करने में सक्षम नहीं होगा क्योंकि नियंत्रण विमान को पता नहीं था कि एप्लिकेशन को कितने संसाधनों की आवश्यकता होगी, जो कि शेड्यूलिंग एल्गोरिदम का एक प्रमुख घटक है।

फली की सीमा एक फली के लिए एक स्पष्ट सीमा है। यह संसाधनों की अधिकतम मात्रा का प्रतिनिधित्व करता है जो क्लस्टर कंटेनर को आवंटित करेगा।

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

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

आदर्श रूप से, हम चाहते हैं कि सिस्टम में अन्य प्रक्रियाओं में हस्तक्षेप किए बिना प्रक्रिया के जीवन चक्र के दौरान पॉड की संसाधन आवश्यकताओं को बदल दिया जाए - यह सीमा निर्धारित करने का उद्देश्य है।

दुर्भाग्य से, मैं विशिष्ट निर्देश नहीं दे सकता कि कौन से मूल्य निर्धारित किए जाएं, लेकिन हम स्वयं निम्नलिखित नियमों का पालन करते हैं:

लोड परीक्षण उपकरण का उपयोग करके, हम ट्रैफ़िक के आधार स्तर का अनुकरण करते हैं और पॉड संसाधनों (मेमोरी और प्रोसेसर) के उपयोग का निरीक्षण करते हैं।
पॉड अनुरोधों को एक मनमाने ढंग से कम मूल्य पर सेट करें (अनुरोधों के मूल्य के लगभग 5 गुना की संसाधन सीमा के साथ) और निरीक्षण करें। जब अनुरोध बहुत कम स्तर पर होते हैं, तो प्रक्रिया शुरू नहीं हो सकती है, जिससे अक्सर क्रिप्टिक गो रनटाइम त्रुटियां होती हैं।

मैं ध्यान देता हूं कि उच्च संसाधन सीमाएं शेड्यूलिंग को और अधिक कठिन बना देती हैं क्योंकि पॉड को पर्याप्त संसाधनों के साथ लक्ष्य नोड की आवश्यकता होती है।

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

चरण दो: लाइवनेस और रेडीनेस टेस्ट सेट अप करें

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

जीवंतता दिखाता है कि क्या कंटेनर चल रहा है। यदि यह विफल रहता है, तो क्यूबलेट कंटेनर को मार देता है और इसके लिए पुनरारंभ नीति सक्षम हो जाती है। यदि कंटेनर लाइवनेस जांच से लैस नहीं है, तो डिफ़ॉल्ट स्थिति सफल होगी - जैसा कि में कहा गया है कुबेरनेट्स प्रलेखन.

लाइवनेस जांच सस्ती होनी चाहिए, यानी बहुत सारे संसाधनों का उपभोग नहीं करना चाहिए, क्योंकि वे अक्सर चलते हैं और कुबेरनेट्स को सूचित करना चाहिए कि एप्लिकेशन चल रहा है।

यदि आप विकल्प को हर सेकंड चलाने के लिए सेट करते हैं, तो यह प्रति सेकंड 1 अनुरोध जोड़ देगा, इसलिए ध्यान रखें कि इस ट्रैफ़िक को संसाधित करने के लिए अतिरिक्त संसाधनों की आवश्यकता होगी।

हमारी कंपनी में, लाइवनेस परीक्षण किसी एप्लिकेशन के मुख्य घटकों का परीक्षण करता है, भले ही डेटा (उदाहरण के लिए, किसी दूरस्थ डेटाबेस या कैश से) पूरी तरह से उपलब्ध न हो।

हमने अनुप्रयोगों में एक "स्वास्थ्य" समापन बिंदु स्थापित किया है जो केवल 200 प्रतिक्रिया कोड लौटाता है। यह एक संकेतक है कि प्रक्रिया चल रही है और अनुरोधों को संभालने में सक्षम है (लेकिन अभी तक यातायात नहीं)।

कसौटी तत्परता इंगित करता है कि कंटेनर अनुरोधों को पूरा करने के लिए तैयार है या नहीं। यदि तत्परता जांच विफल हो जाती है, तो समापन बिंदु नियंत्रक पॉड से मेल खाने वाली सभी सेवाओं के समापन बिंदु से पॉड के आईपी पते को हटा देता है। यह कुबेरनेट्स प्रलेखन में भी कहा गया है।

रेडीनेस जांच अधिक संसाधनों का उपभोग करती है, क्योंकि उन्हें बैकएंड को इस तरह से हिट करना चाहिए कि यह दिखा सके कि आवेदन अनुरोध स्वीकार करने के लिए तैयार है।

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

यदि आप अपने एप्लिकेशन की तत्परता का परीक्षण करने के लिए डेटाबेस को क्वेरी करने का निर्णय लेते हैं, तो सुनिश्चित करें कि यह यथासंभव सस्ता है। आइए इस प्रश्न को लें:

SELECT small_item FROM table LIMIT 1

यहाँ एक उदाहरण है कि हम कुबेरनेट्स में इन दो मूल्यों को कैसे कॉन्फ़िगर करते हैं:

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

आप कुछ अतिरिक्त कॉन्फ़िगरेशन विकल्प जोड़ सकते हैं:

initialDelaySeconds - कंटेनर के लॉन्च और प्रोब के लॉन्च के बीच कितने सेकंड का समय लगेगा।
periodSeconds - नमूना रन के बीच प्रतीक्षा अंतराल।
timeoutSeconds - सेकंड की संख्या जिसके बाद पॉड को आपातकालीन माना जाता है। सामान्य समय समाप्त।
failureThreshold पॉड को पुनरारंभ सिग्नल भेजे जाने से पहले परीक्षण विफलताओं की संख्या है।
successThreshold तैयार अवस्था में पॉड के संक्रमण से पहले सफल परीक्षणों की संख्या है (विफलता के बाद जब पॉड शुरू होता है या ठीक हो जाता है)।

चरण तीन: पॉड की डिफ़ॉल्ट नेटवर्क नीतियों को सेट करना

कुबेरनेट्स में एक "सपाट" नेटवर्क स्थलाकृति है, डिफ़ॉल्ट रूप से सभी पॉड्स एक दूसरे के साथ सीधे संवाद करते हैं। कुछ मामलों में यह वांछनीय नहीं है।

एक संभावित सुरक्षा समस्या यह है कि एक हमलावर नेटवर्क पर सभी पॉड्स पर ट्रैफ़िक भेजने के लिए एकल असुरक्षित एप्लिकेशन का उपयोग कर सकता है। जैसा कि सुरक्षा के कई क्षेत्रों में होता है, यहां कम से कम विशेषाधिकार का सिद्धांत लागू होता है। आदर्श रूप से, नेटवर्क नीतियों को स्पष्ट रूप से बताना चाहिए कि पॉड्स के बीच कौन से कनेक्शन की अनुमति है और कौन सी नहीं।

उदाहरण के लिए, निम्नलिखित एक साधारण नीति है जो किसी विशेष नाम स्थान के लिए आने वाले सभी ट्रैफ़िक को अस्वीकार करती है:

---
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)
अधिक जानकारी यहां.

चरण चार: हुक और इनिट कंटेनर के साथ कस्टम व्यवहार

हमारा एक मुख्य लक्ष्य डेवलपर्स के लिए डाउनटाइम के बिना कुबेरनेट्स में परिनियोजन प्रदान करना था। यह कठिन है क्योंकि अनुप्रयोगों को बंद करने और उनके उपयोग किए गए संसाधनों को जारी करने के कई विकल्प हैं।

के साथ विशेष कठिनाइयाँ उत्पन्न हुईं nginx. हमने देखा कि इन पॉड्स को क्रम से तैनात करते समय, सक्रिय कनेक्शन सफलतापूर्वक पूर्ण होने से पहले बाधित हो गए थे।

इंटरनेट पर व्यापक शोध के बाद, यह पता चला कि कुबेरनेट्स पॉड को बंद करने से पहले 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 कंटेनर में रहस्यों तक पहुँचने की है, जो इन क्रेडेंशियल्स को मुख्य मॉड्यूल को प्रदान करता है, जो मुख्य एप्लिकेशन मॉड्यूल से ही अनधिकृत पहुँच को रोकता है।

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

पाँचवाँ चरण: कर्नेल विन्यास

अंत में, चलिए एक और उन्नत तकनीक के बारे में बात करते हैं।

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

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

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

यह एक अधिक उन्नत तकनीक है जिसकी अक्सर आवश्यकता नहीं होती है। लेकिन अगर आपका एप्लिकेशन भारी लोड से निपटने के लिए संघर्ष कर रहा है, तो आप इनमें से कुछ सेटिंग्स को बदलने की कोशिश कर सकते हैं। इस प्रक्रिया के बारे में अधिक जानकारी और विभिन्न मान सेट करना - हमेशा की तरह आधिकारिक दस्तावेज में.

अंत में

जबकि कुबेरनेट्स एक आउट-ऑफ-द-बॉक्स समाधान की तरह लग सकता है, कुछ महत्वपूर्ण कदम हैं जो अनुप्रयोगों को सुचारू रूप से चलाने के लिए उठाए जाने चाहिए।

कुबेरनेट्स में प्रवास के दौरान, "लोड परीक्षण चक्र" का पालन करना महत्वपूर्ण है: एप्लिकेशन को चलाएं, लोड के तहत इसका परीक्षण करें, मेट्रिक्स और स्केलिंग व्यवहार का निरीक्षण करें, इस डेटा के आधार पर कॉन्फ़िगरेशन को समायोजित करें, फिर इस चक्र को दोबारा दोहराएं।

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

हमेशा खुद से ये सवाल पूछें:

एप्लिकेशन कितने संसाधनों का उपभोग करते हैं और यह राशि कैसे बदलेगी?
वास्तविक स्केलिंग आवश्यकताएँ क्या हैं? ऐप औसतन कितना ट्रैफिक हैंडल करेगा? पीक ट्रैफिक के बारे में क्या?
सेवा को कितनी बार स्केल आउट करने की आवश्यकता होगी? ट्रैफ़िक प्राप्त करने के लिए नए पॉड्स को कितनी जल्दी उठने और चलने की आवश्यकता होती है?
पॉड्स कितनी खूबसूरती से बंद हो जाते हैं? क्या यह बिल्कुल जरूरी है? क्या डाउनटाइम के बिना परिनियोजन प्राप्त करना संभव है?
सुरक्षा जोखिमों को कैसे कम करें और किसी भी समझौता किए गए पॉड से नुकसान को सीमित करें? क्या किन्हीं सेवाओं के पास ऐसी अनुमतियाँ या पहुँचें हैं जिनकी उन्हें आवश्यकता नहीं है?

कुबेरनेट्स एक अविश्वसनीय मंच प्रदान करता है जो आपको क्लस्टर में हजारों सेवाओं को तैनात करने के लिए सर्वोत्तम प्रथाओं का उपयोग करने की अनुमति देता है। हालाँकि, सभी एप्लिकेशन अलग-अलग हैं। कभी-कभी क्रियान्वयन के लिए थोड़ी अधिक मेहनत की आवश्यकता होती है।

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

और क्या पढ़ें:

स्रोत: www.habr.com

कुबेरनेट्स पर पहला एप्लिकेशन तैनात करते समय पांच मिस