👩‍🔬 👍🏽 🚢 कुबेरनेट्स टिप्स एंड ट्रिक्स: नोड आवंटन और वेब एप्लिकेशन लोड ⌛️ 🏔️ 🌮

कुबेरनेट्स के साथ रोजमर्रा के काम में जीवन को आसान बनाने के बारे में हमारे व्यावहारिक लेखों की निरंतरता में, हम ऑपरेशन की दुनिया से दो कहानियों के बारे में बात करते हैं: विशिष्ट कार्यों के लिए व्यक्तिगत नोड्स का आवंटन और भारी भार के लिए php-fpm (या किसी अन्य एप्लिकेशन सर्वर) के कॉन्फ़िगरेशन। पहले की तरह, यहां वर्णित समाधान आदर्श होने का दावा नहीं करते हैं, लेकिन आपके विशिष्ट मामलों के लिए शुरुआती बिंदु और प्रतिबिंब के लिए एक आधार के रूप में पेश किए जाते हैं। टिप्पणियों में प्रश्न और सुधार का स्वागत है!

1. विशिष्ट कार्यों के लिए अलग-अलग नोड्स का आवंटन

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

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

* अन्य बातों के अलावा, यह इनग्रेड के पुराने संस्करणों के लिए प्रासंगिक था, जब बड़ी संख्या में वेबसोकेट कनेक्शन और नग्नेक्स के लगातार लोड होने के कारण, "त्रिशंकु नग्नेक्स प्रक्रियाएं" दिखाई दीं, जो हजारों की संख्या में थीं और बड़ी मात्रा में संसाधनों का उपभोग करती थीं।

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

समाधान ने जल्दी से खुद को प्रेरित किया: विभिन्न कार्यों के लिए अलग-अलग मशीनों को आवंटित करना आवश्यक था। हमने 3 मुख्य प्रकार के कार्य समूहों की पहचान की है:

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

निर्णय

हम इसे कैसे लागू करेंगे? बहुत सरल: दो देशी कुबेरनेट तंत्र। पहला नोड है जहां वांछित नोड का चयन करना है जहां आवेदन जाना चाहिए, जो प्रत्येक नोड पर स्थापित लेबल पर आधारित है।

कहें कि हमारे पास एक kube-system-1 नोड है। हम इसमें एक अतिरिक्त लेबल जोड़ते हैं:

 $ kubectl label node kube-system-1 node-role/monitoring=

... और Deployment , जिसे इस नोड में रोल आउट किया जाना चाहिए, हम लिखते हैं:

 nodeSelector: node-role/monitoring: ""

दूसरा तंत्र तप और सहनशीलता है । इसकी मदद से, हम स्पष्ट रूप से इंगित करते हैं कि इन मशीनों पर केवल उन कंटेनरों को लॉन्च किया जा सकता है जिनके पास इस दाग में झुकाव है।

उदाहरण के लिए, एक kube-frontend-1 मशीन है जिस पर हम केवल kube-frontend-1 रोल करेंगे। इस नोड में टेंट जोड़ें:

 $ kubectl taint node kube-frontend-1 node-role/frontend="":NoExecute

... और Deployment हम बनाते हैं:

 tolerations: - effect: NoExecute key: node-role/frontend

कोप्स के मामले में, समान जरूरतों के लिए व्यक्तिगत उदाहरण समूह बनाए जा सकते हैं:

 $ kops create ig --name cluster_name IG_NAME

... और आपको इस तरह का कुछ मिलता है जैसे kops में ग्रुप कॉन्फिग कॉन्फ़िगर करना:

 apiVersion: kops/v1alpha2 kind: InstanceGroup metadata: creationTimestamp: 2017-12-07T09:24:49Z labels: dedicated: monitoring kops.k8s.io/cluster: k-dev.k8s name: monitoring spec: image: kope.io/k8s-1.8-debian-jessie-amd64-hvm-ebs-2018-01-14 machineType: m4.4xlarge maxSize: 2 minSize: 2 nodeLabels: dedicated: monitoring role: Node subnets: - eu-central-1c taints: - dedicated=monitoring:NoSchedule

इस प्रकार, इस उदाहरण समूह से नोड्स स्वचालित रूप से एक अतिरिक्त लेबल और टेंट जोड़ देगा।

2. भारी भार के लिए php-fpm को कॉन्फ़िगर करना

वेब एप्लिकेशन चलाने के लिए उपयोग किए जाने वाले सर्वर की एक विस्तृत विविधता है: php-fpm, gunicorn और इसी तरह। कुबेरनेट्स में उनके उपयोग का मतलब है कि कई चीजें हैं जिनके बारे में आपको हमेशा सोचना चाहिए:

यह मोटे तौर पर समझना आवश्यक है कि हम कितने श्रमिकों को प्रत्येक कंटेनर में php-fpm में आवंटित करने के लिए तैयार हैं। उदाहरण के लिए, हम आने वाले अनुरोधों को संसाधित करने के लिए 10 श्रमिकों को आवंटित कर सकते हैं, फली की संख्या का उपयोग करके फली और पैमाने के लिए कम संसाधन आवंटित कर सकते हैं - यह अच्छा अभ्यास है। एक और उदाहरण प्रत्येक फली के लिए 500 श्रमिकों को आवंटित करना है और उत्पादन में 2-3 ऐसे पॉड्स हैं ... लेकिन यह एक बहुत बुरा विचार है।
प्रत्येक फली के सही संचालन को सत्यापित करने के लिए लीवर / तत्परता परीक्षणों की आवश्यकता होती है और यदि नेटवर्क समस्याओं के कारण या डेटाबेस एक्सेस के कारण फली अटक जाती है (आपके कोई विकल्प और कारण हो सकते हैं)। ऐसी स्थितियों में, आपको समस्याग्रस्त फली को फिर से बनाने की आवश्यकता है।
प्रत्येक कंटेनर के लिए अनुरोधों को स्पष्ट रूप से पंजीकृत करना और संसाधनों को सीमित करना महत्वपूर्ण है ताकि एप्लिकेशन "प्रवाह" न करे और इस सर्वर पर सभी सेवाओं को नुकसान पहुंचाना शुरू न करे।

समाधान

दुर्भाग्य से, कोई चांदी की गोली नहीं है जो आपको तुरंत समझने में मदद करती है कि एक एप्लिकेशन को कितने संसाधनों (सीपीयू, रैम) की आवश्यकता हो सकती है। एक संभावित विकल्प संसाधनों की खपत को देखना है और हर बार इष्टतम मूल्यों का चयन करें। अनुचित OOM मार'ओव और थ्रॉटलिंग सीपीयू से बचने के लिए, जो सेवा को बहुत प्रभावित करता है, आप पेशकश कर सकते हैं:

सही लगन / तत्परता परीक्षण जोड़ें ताकि हम यह सुनिश्चित कर सकें कि यह कंटेनर सही तरीके से काम कर रहा है। सबसे अधिक संभावना है कि यह एक सेवा पृष्ठ होगा जो सभी बुनियादी ढांचे की उपलब्धता (फली में काम करने के लिए आवेदन के लिए आवश्यक) की उपलब्धता की जांच करता है और 200% प्रतिक्रिया कोड देता है;
सही ढंग से उन श्रमिकों की संख्या का चयन करें जो अनुरोधों को संसाधित करेंगे, और उन्हें सही ढंग से वितरित करेंगे।

उदाहरण के लिए, हमारे पास 10 पॉड्स हैं जिनमें दो कंटेनर शामिल हैं: नग्नेक्स (बैकेंड को स्टैटिक्स और प्रॉक्सिंग अनुरोध भेजना) और php-fpm (वास्तव में बैकेंड, जो डायनेमिक पेज प्रोसेस करता है)। Php-fpm पूल को श्रमिकों की स्थिर संख्या (10) के लिए कॉन्फ़िगर किया गया है। इस प्रकार, समय की एक इकाई में, हम बैकएंड पर 100 सक्रिय अनुरोधों को संसाधित कर सकते हैं। प्रत्येक अनुरोध को PHP द्वारा 1 सेकंड में संसाधित किया जाना चाहिए।

यदि 1 और अनुरोध एक विशिष्ट पॉड में आता है, तो 10 अनुरोधों को सक्रिय रूप से संसाधित किया जा रहा है? PHP इसे प्रोसेस करने में सक्षम नहीं होगा और यदि यह GET अनुरोध है तो Ingress इसे अगले पॉड में पुनः प्रयास के लिए भेज देगा। यदि कोई पोस्ट अनुरोध था, तो वह एक त्रुटि लौटाएगा।

और अगर हम इस बात को ध्यान में रखते हैं कि सभी 10 अनुरोधों के प्रसंस्करण के दौरान, हम क्यूबलेट (लीवर जांच) से एक चेक प्राप्त करेंगे, तो यह एक त्रुटि के साथ समाप्त हो जाएगा और कुबेरनेट्स यह सोचना शुरू कर देंगे कि इस कंटेनर में कुछ गड़बड़ है और इसे मार दें। इस मामले में, इस समय संसाधित किए गए सभी अनुरोध एक त्रुटि (!) के साथ समाप्त हो जाएंगे और कंटेनर के पुनरारंभ के समय यह शेष राशि से बाहर हो जाएगा, जो अन्य सभी बैकेंड के लिए अनुरोधों में वृद्धि दर्ज करेगा।

रेखांकन

मान लीजिए कि हमारे पास 2 पॉड्स हैं जिनमें से प्रत्येक में 10 php-fpm कार्यकर्ता कॉन्फ़िगर किए गए हैं। यहाँ एक ग्राफ है जो "डाउनटाइम" के दौरान सूचना प्रदर्शित करता है, अर्थात् जब केवल एक php-fpm का अनुरोध करने वाला php-fpm निर्यातक है (हमारे पास प्रत्येक सक्रिय कार्यकर्ता है):

अब बराबरी 19 के साथ बूट शुरू करें:

अब आइए हम (20) को संभालने की तुलना में अधिक संगामिति बनाने की कोशिश करें ... चलो 23 कहते हैं। तब सभी php-fpm कार्यकर्ता ग्राहक अनुरोधों को पूरा करने में व्यस्त हैं:

Vorkers अब एक लाईन सैंपल को संसाधित करने के लिए पर्याप्त नहीं हैं, इसलिए हम कुबेरनेट्स डैशबोर्ड में इस चित्र को देखते हैं (या describe pod ):

अब, जब पॉड्स में से एक रिबूट होता है, तो एक हिमस्खलन प्रभाव होता है : अनुरोध दूसरी पॉड पर गिरने लगते हैं, जो उन्हें संसाधित करने में भी सक्षम नहीं होता है, जिसके कारण हमें क्लाइंट से बड़ी संख्या में त्रुटियां प्राप्त होती हैं। सभी कंटेनरों के पूल भरे होने के बाद, सेवा को ऊपर उठाना समस्याग्रस्त है - यह केवल फली और श्रमिकों की संख्या में तेज वृद्धि से संभव है।

पहला विकल्प

PHP के साथ एक कंटेनर में, आप 2 fpm पूल को कॉन्फ़िगर कर सकते हैं: एक ग्राहक अनुरोधों को संसाधित करने के लिए, दूसरा कंटेनर की "उत्तरजीविता" की जाँच के लिए। फिर nginx कंटेनर पर आपको एक समान कॉन्फ़िगरेशन करने की आवश्यकता होगी:

  upstream backend { server 127.0.0.1:9000 max_fails=0; } upstream backend-status { server 127.0.0.1:9001 max_fails=0; }

सब कुछ है कि backend-status नामक अपस्ट्रीम में प्रोसेसिंग के लिए लीनिंग सैंपल भेजना है।

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

यह विकल्प, ज़ाहिर है, कुछ भी नहीं से बेहतर है, लेकिन यह भी खराब है क्योंकि मुख्य पूल में कुछ हो सकता है, जिसे हम लीन टेस्ट का उपयोग करने के बारे में नहीं जानते होंगे।

दूसरा विकल्प

तुम भी नहीं nginx- सीमा-अपस्ट्रीम नामक बहुत लोकप्रिय nginx मॉड्यूल का उपयोग कर सकते हैं। फिर PHP में हम 11 श्रमिकों को निर्दिष्ट करेंगे, और nginx के साथ कंटेनर में हम एक समान विन्यास बनाएंगे:

  limit_upstream_zone limit 32m; upstream backend { server 127.0.0.1:9000 max_fails=0; limit_upstream_conn limit=10 zone=limit backlog=10 timeout=5s; } upstream backend-status { server 127.0.0.1:9000 max_fails=0; }

सीमांत स्तर पर, nginx बैकेंड (10) को भेजे जाने वाले अनुरोधों की संख्या को सीमित करेगा। एक दिलचस्प बिंदु यह है कि एक विशेष बैकलॉग बनाया जाता है: यदि नाज़िनक्स के लिए 11 वां अनुरोध क्लाइंट से आता है, और नगीनेक्स देखता है कि php-fpm पूल व्यस्त है, तो यह अनुरोध 5 सेकंड के लिए बैकलॉग में रखा गया है। यदि, इस समय के दौरान, php-fpm को मुक्त नहीं किया गया है, तो ही Ingress कार्रवाई में आएगा, जो किसी अन्य पॉड के अनुरोध को पुनः प्रयास करेगा। यह तस्वीर को सुचारू करता है, क्योंकि हमारे पास हमेशा 1 नि: शुल्क पीएचपी कार्यकर्ता एक लीनिंग नमूना प्रसंस्करण के लिए होगा - हम हिमस्खलन प्रभाव से बच सकते हैं।

अन्य विचार

इस समस्या को हल करने के लिए अधिक बहुमुखी और सुंदर विकल्पों के लिए, यह दूत और उसके एनालॉग्स की दिशा में देखने लायक है।

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

पुनश्च

K8s टिप्स एंड ट्रिक्स चक्र से अन्य:

हमारे ब्लॉग में भी पढ़ें:

" कुबेरनेट्स में उच्च उपलब्धता कैसे प्रदान की जाती है ";
" निगरानी और कुबेरनेट्स " (समीक्षा और वीडियो रिपोर्ट) ;
" छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (वीडियो रिपोर्ट, जिसमें कुबेरनेट्स तकनीकी उपकरण का परिचय शामिल है) ।

कुबेरनेट्स टिप्स एंड ट्रिक्स: नोड आवंटन और वेब एप्लिकेशन लोड