Kubernetes वर पहिला अनुप्रयोग तैनात करताना पाच चुकले

Aris-Dreamer द्वारे अयशस्वी

बर्‍याच लोकांचा असा विश्वास आहे की कुबर्नेट्समध्ये अनुप्रयोग स्थलांतरित करणे पुरेसे आहे (एकतर हेल्म किंवा व्यक्तिचलितपणे) आणि ते आनंदी होतील. पण ते इतके सोपे नाही.

संघ Mail.ru क्लाउड सोल्यूशन्स DevOps अभियंता ज्युलियन गिंडी यांच्या लेखाचे भाषांतर केले. स्थलांतर प्रक्रियेदरम्यान त्याच्या कंपनीला काय अडचणी आल्या हे तो शेअर करतो जेणेकरून तुम्ही त्याच रेकवर पाऊल ठेवू नये.

पहिली पायरी: पॉड विनंत्या आणि मर्यादा सेट करणे

चला स्वच्छ वातावरण तयार करून सुरुवात करूया ज्यामध्ये आपल्या शेंगा चालतील. कुबर्नेट्स शेड्यूल शेड्यूल करणे आणि अयशस्वी परिस्थिती हाताळण्याचे उत्तम काम करते. परंतु असे दिसून आले की शेड्युलर कधीकधी पॉड ठेवू शकत नाही जर त्याला यशस्वीरित्या कार्य करण्यासाठी किती संसाधने आवश्यक आहेत याचा अंदाज लावणे कठीण असेल. येथे संसाधने आणि मर्यादांसाठी विनंत्या येतात. विनंत्या आणि मर्यादा सेट करण्याच्या सर्वोत्तम पद्धतीबद्दल बरेच वादविवाद आहेत. कधीकधी असे वाटते की ती विज्ञानापेक्षा अधिक कला आहे. हा आमचा दृष्टिकोन आहे.

पॉड विनंत्या - शेड्युलरद्वारे पॉड चांगल्या प्रकारे ठेवण्यासाठी हे मुख्य मूल्य वापरले जाते.

इझ Kubernetes दस्तऐवजीकरण: फिल्टरिंग पायरी नोड्सचा संच निर्धारित करते जेथे पॉड शेड्यूल केले जाऊ शकते. उदाहरणार्थ, PodFitsResources फिल्टर पॉडच्या विशिष्ट संसाधनाच्या विनंत्या पूर्ण करण्यासाठी नोडकडे पुरेसे संसाधने आहेत की नाही हे तपासते.

आम्ही अर्ज विनंत्या वापरतो जेणेकरुन किती संसाधनांचा अंदाज लावता येईल खरं तर अनुप्रयोगास ते योग्यरित्या कार्य करण्याची आवश्यकता आहे. अशा प्रकारे शेड्युलर नोड्स वास्तववादी ठेवू शकतो. प्रत्येक पॉडमध्ये पुरेशा प्रमाणात संसाधने आहेत याची खात्री करण्यासाठी आम्हाला सुरुवातीला मार्जिनसह विनंत्या सेट करायच्या होत्या, परंतु आमच्या लक्षात आले की शेड्यूलिंग वेळा लक्षणीयरीत्या वाढल्या आहेत आणि काही पॉड्स कधीही पूर्णपणे शेड्यूल केलेले नाहीत, जणू काही त्यांच्यासाठी संसाधन विनंत्या प्राप्त झाल्या नाहीत.

या प्रकरणात, शेड्युलर अनेकदा शेड्यूल बाहेर ढकलतो आणि त्यांना पुन्हा शेड्यूल करू शकत नाही कारण कंट्रोल प्लेनला शेड्यूलिंग अल्गोरिदमचा एक महत्त्वाचा घटक, ऍप्लिकेशनला किती संसाधनांची आवश्यकता असेल याची कल्पना नसते.

पॉड मर्यादा - ही पॉडसाठी एक स्पष्ट मर्यादा आहे. हे क्लस्टर कंटेनरला वाटप करणारी जास्तीत जास्त संसाधने दर्शवते.

पुन्हा, पासून अधिकृत दस्तऐवजीकरण: कंटेनरमध्ये 4 GiB मेमरी मर्यादा सेट असल्यास, कुबेलेट (आणि कंटेनर रनटाइम) त्याची अंमलबजावणी करेल. रनटाइम कंटेनरला निर्दिष्ट संसाधन मर्यादेपेक्षा जास्त वापरण्याची परवानगी देत ​​​​नाही. उदाहरणार्थ, जेव्हा कंटेनरमधील प्रक्रिया परवानगी दिलेल्या प्रमाणापेक्षा जास्त मेमरी वापरण्याचा प्रयत्न करते, तेव्हा सिस्टम कर्नल "मेमरीबाहेर" (OOM) त्रुटीसह प्रक्रिया समाप्त करते.

कंटेनर नेहमी संसाधन विनंतीमध्ये निर्दिष्ट केलेल्या पेक्षा अधिक संसाधने वापरू शकतो, परंतु मर्यादेमध्ये निर्दिष्ट केलेल्या पेक्षा जास्त कधीही वापरू शकत नाही. हे मूल्य योग्यरित्या सेट करणे कठीण आहे, परंतु ते खूप महत्वाचे आहे.

तद्वतच, सिस्टममधील इतर प्रक्रियांमध्ये हस्तक्षेप न करता पॉडच्या संसाधन आवश्यकता बदलल्या पाहिजेत - हेच उद्दिष्ट आहे.

दुर्दैवाने, मी कोणती मूल्ये सेट करावी याबद्दल विशिष्ट सूचना देऊ शकत नाही, परंतु आम्ही स्वतः खालील नियमांचे पालन करतो:

1. लोड टेस्टिंग टूल वापरून, आम्ही ट्रॅफिकच्या बेसलाइन लेव्हलचे अनुकरण करतो आणि पॉड रिसोर्सेसच्या (मेमरी आणि प्रोसेसर) वापराचे निरीक्षण करतो.
2. आम्ही पॉड विनंत्या अनियंत्रितपणे कमी मूल्यावर सेट करतो (विनंत्यांच्या मूल्याच्या सुमारे 5 पट संसाधन मर्यादेसह) आणि निरीक्षण करतो. जेव्हा विनंत्या खूप कमी असतात, तेव्हा प्रक्रिया सुरू होऊ शकत नाही, अनेकदा अनाकलनीय गो रनटाइम त्रुटी निर्माण करतात.

लक्षात घ्या की उच्च संसाधन मर्यादा शेड्यूलिंग अधिक कठीण करतात कारण पॉडला पुरेशी संसाधने उपलब्ध असलेल्या लक्ष्य नोडची आवश्यकता असते.

अशा परिस्थितीची कल्पना करा जिथे तुमच्याकडे खूप जास्त संसाधन मर्यादा असलेले हलके वेब सर्व्हर आहे, 4 GB मेमरी म्हणा. ही प्रक्रिया शक्यतो क्षैतिजरित्या मोजावी लागेल, आणि प्रत्येक नवीन मॉड्यूल किमान 4 GB उपलब्ध मेमरी असलेल्या नोडवर शेड्यूल केले जावे. असा कोणताही नोड अस्तित्वात नसल्यास, त्या पॉडवर प्रक्रिया करण्यासाठी क्लस्टरने नवीन नोड सादर करणे आवश्यक आहे, ज्यास काही वेळ लागू शकतो. जलद आणि गुळगुळीत स्केलिंग सुनिश्चित करण्यासाठी संसाधन विनंत्या आणि मर्यादा यांच्यातील फरक कमीतकमी ठेवणे महत्वाचे आहे.

पायरी दोन: लाइव्हनेस आणि रेडिनेस चाचण्या सेट करणे

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

चैतन्य कंटेनर चालू आहे की नाही ते दाखवते. ते अयशस्वी झाल्यास, कुबेलेट कंटेनरला मारून टाकते आणि त्यासाठी रीस्टार्ट धोरण सक्षम केले जाते. जर कंटेनर लाइव्हनेस प्रोबने सुसज्ज नसेल, तर डीफॉल्ट स्थिती यशस्वी होईल - हे त्यात म्हटले आहे Kubernetes दस्तऐवजीकरण.

लाइव्हनेस प्रोब्स स्वस्त असाव्यात, म्हणजे त्यांनी भरपूर संसाधने वापरू नयेत, कारण ते वारंवार चालतात आणि कुबेरनेटेसला ऍप्लिकेशन चालू असल्याची माहिती द्यावी लागते.

तुम्ही प्रत्येक सेकंदाला चालवण्याचा पर्याय सेट केल्यास, हे प्रति सेकंद 1 विनंती जोडेल, म्हणून लक्षात ठेवा की ही रहदारी हाताळण्यासाठी अतिरिक्त संसाधनांची आवश्यकता असेल.

आमच्या कंपनीमध्ये, डेटा (उदाहरणार्थ, रिमोट डेटाबेस किंवा कॅशेमधून) पूर्णपणे प्रवेशयोग्य नसला तरीही, Liveness चाचण्या अनुप्रयोगाचे मुख्य घटक तपासतात.

आम्ही अॅप्सना "आरोग्य" एंडपॉइंटसह कॉन्फिगर केले आहे जे फक्त 200 चा प्रतिसाद कोड देते. हे एक संकेत आहे की प्रक्रिया चालू आहे आणि विनंत्यांवर प्रक्रिया करण्यास सक्षम आहे (परंतु अद्याप रहदारी नाही).

प्रयत्न तत्परता कंटेनर विनंत्या देण्यासाठी तयार आहे की नाही हे सूचित करते. रेडिनेस प्रोब अयशस्वी झाल्यास, एंडपॉइंट कंट्रोलर पॉडशी संबंधित सर्व सेवांच्या एंडपॉईंटमधून पॉडचा IP पत्ता काढून टाकतो. हे कुबर्नेट्स दस्तऐवजीकरणात देखील नमूद केले आहे.

रेडिनेस प्रोब्स अधिक संसाधने वापरतात कारण त्यांना बॅकएंडवर पाठवले जाणे आवश्यक आहे जे सूचित करते की अनुप्रयोग विनंती स्वीकारण्यास तयार आहे.

डेटाबेसमध्ये थेट प्रवेश करायचा की नाही याबद्दल समाजात बरीच चर्चा आहे. ओव्हरहेड (चेक वारंवार केले जातात, परंतु समायोजित केले जाऊ शकतात) लक्षात घेऊन, आम्ही ठरवले की काही अनुप्रयोगांसाठी, डेटाबेसमधून रेकॉर्ड परत केले जात असल्याची पडताळणी केल्यानंतरच रहदारी सेवा देण्याची तयारी मोजली जाते. चांगल्या प्रकारे डिझाइन केलेल्या तयारी चाचण्यांनी उच्च पातळीची उपलब्धता सुनिश्चित केली आणि तैनाती दरम्यान डाउनटाइम काढून टाकला.

तुम्ही तुमच्या अर्जाची तयारी तपासण्यासाठी डेटाबेसची चौकशी करण्याचे ठरविल्यास, ते शक्य तितके स्वस्त असल्याची खात्री करा. चला ही विनंती घेऊया:

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 कंटेनर सुरक्षितपणे सानुकूल कोड किंवा उपयुक्तता चालवतात जे अन्यथा अनुप्रयोग कंटेनर प्रतिमेची सुरक्षा कमी करतात. अनावश्यक साधने वेगळी ठेवून, तुम्ही अॅप्लिकेशन कंटेनर इमेजच्या अटॅक पृष्ठभागावर मर्यादा घालता.

पायरी पाच: कर्नल कॉन्फिगर करणे

शेवटी, अधिक प्रगत तंत्राबद्दल बोलूया.

Kubernetes हे एक अत्यंत लवचिक प्लॅटफॉर्म आहे जे तुम्हाला योग्य वाटेल तसे वर्कलोड चालवू देते. आमच्याकडे अनेक उच्च-कार्यक्षमता अनुप्रयोग आहेत जे अत्यंत संसाधन गहन आहेत. व्यापक लोड चाचणी आयोजित केल्यानंतर, आम्हाला आढळले की कुबर्नेट्सची डीफॉल्ट सेटिंग्ज प्रभावी असताना एक अनुप्रयोग अपेक्षित रहदारी लोड हाताळण्यासाठी संघर्ष करत होता.

तथापि, Kubernetes तुम्हाला एक विशेषाधिकार असलेला कंटेनर चालवण्याची परवानगी देतो जो केवळ विशिष्ट पॉडसाठी कर्नल पॅरामीटर्स बदलतो. उघडलेल्या कनेक्शनची कमाल संख्या बदलण्यासाठी आम्ही काय वापरले ते येथे आहे:

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

हे एक अधिक प्रगत तंत्र आहे जे सहसा आवश्यक नसते. परंतु जर तुमचा अॅप्लिकेशन जड भाराचा सामना करण्यासाठी संघर्ष करत असेल, तर तुम्ही यापैकी काही सेटिंग्ज बदलण्याचा प्रयत्न करू शकता. या प्रक्रियेबद्दल अधिक तपशील आणि भिन्न मूल्ये सेट करा - नेहमीप्रमाणे अधिकृत कागदपत्रांमध्ये.

शेवटी

कुबर्नेट्स हे बॉक्सच्या बाहेर तयार सोल्यूशनसारखे वाटत असले तरी, तुमचे अॅप्लिकेशन सुरळीत चालू ठेवण्यासाठी तुम्हाला काही प्रमुख पावले उचलावी लागतील.

तुमच्या कुबर्नेट्सच्या संपूर्ण स्थलांतरादरम्यान, "लोड टेस्टिंग सायकल" फॉलो करणे महत्त्वाचे आहे: अॅप्लिकेशन लाँच करा, त्याची चाचणी लोड करा, मेट्रिक्स आणि स्केलिंग वर्तनाचे निरीक्षण करा, त्या डेटावर आधारित कॉन्फिगरेशन समायोजित करा, नंतर सायकल पुन्हा करा.

तुमच्या अपेक्षित रहदारीबद्दल वास्तववादी व्हा आणि कोणते घटक प्रथम खंडित होतात हे पाहण्यासाठी त्यापलीकडे जाण्याचा प्रयत्न करा. या पुनरावृत्तीच्या दृष्टिकोनासह, सूचीबद्ध केलेल्या शिफारसींपैकी फक्त काही यश मिळविण्यासाठी पुरेसे असू शकतात. किंवा सखोल सानुकूलनाची आवश्यकता असू शकते.

नेहमी स्वतःला हे प्रश्न विचारा:

1. अनुप्रयोग किती संसाधने वापरतात आणि हे खंड कसे बदलतील?
2. वास्तविक स्केलिंग आवश्यकता काय आहेत? अॅप सरासरी किती रहदारी हाताळेल? पीक रहदारीचे काय?
3. सेवेला किती वेळा क्षैतिज प्रमाणात मोजावे लागेल? रहदारी प्राप्त करण्यासाठी नवीन पॉड्स किती लवकर ऑनलाइन आणणे आवश्यक आहे?
4. शेंगा किती योग्यरित्या बंद करतात? हे अजिबात आवश्यक आहे का? डाउनटाइमशिवाय तैनाती साध्य करणे शक्य आहे का?
5. तुम्ही सुरक्षिततेचे धोके कसे कमी करू शकता आणि कोणत्याही तडजोड केलेल्या पॉड्सचे नुकसान कसे मर्यादित करू शकता? कोणत्याही सेवांना आवश्यक नसलेल्या परवानग्या किंवा प्रवेश आहेत का?

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

सुदैवाने, Kubernetes सर्व तांत्रिक उद्दिष्टे साध्य करण्यासाठी आवश्यक कॉन्फिगरेशन प्रदान करते. संसाधन विनंत्या आणि मर्यादा, लाइव्हनेस आणि रेडिनेस प्रोब्स, इनिट कंटेनर्स, नेटवर्क पॉलिसी आणि कस्टम कर्नल ट्यूनिंग यांचे संयोजन वापरून, तुम्ही फॉल्ट टॉलरन्स आणि जलद स्केलेबिलिटीसह उच्च कार्यक्षमता प्राप्त करू शकता.

आणखी काय वाचायचे:

1. उत्पादन वातावरणात कंटेनर आणि कुबर्नेट्स चालवण्यासाठी सर्वोत्तम पद्धती आणि सर्वोत्तम पद्धती.
2. Kubernetes साठी 90+ उपयुक्त साधने: उपयोजन, व्यवस्थापन, देखरेख, सुरक्षा आणि बरेच काही.
3. आमचे चॅनेल अराउंड कुबरनेटेस टेलीग्राममध्ये.

स्त्रोत: www.habr.com