सघन Google Kubernetes Engine (GKE) क्लस्टर पैकिंग के माध्यम से लागत कैसे कम करें

हर किसी को अभिवादन! आज हम अपने कुबेरनेट क्लस्टर को प्रबंधित करने के लिए Google Kubernetes Engine का उपयोग करने के अपने अनुभव को साझा करना चाहते हैं। उत्पादन में हम पिछले तीन वर्षों से इसका उपयोग कर रहे हैं और हमें प्रसन्नता है कि अब हमें स्वयं इन समूहों के प्रबंधन के बारे में चिंता करने की आवश्यकता नहीं है।

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

हमें अपनी समस्या को पूरी तरह से समझने के लिए अपने परीक्षण के बुनियादी ढांचे के बारे में जानकारी प्रदान करनी चाहिए। हमारे पास पांच से अधिक स्थायी परीक्षण वातावरण हैं और अनुरोध पर डेवलपर्स के लिए वातावरण तैनात कर रहे हैं। सप्ताह के दिनों में मॉड्यूल की संख्या दिन के दौरान 6000 तक पहुंच जाती है और बढ़ती रहती है। चूंकि लोड अस्थिर है, हम लागत बचाने के लिए मॉड्यूल को बहुत कसकर पैक करते हैं, और संसाधनों को पुनर्विक्रय करना हमारी सबसे अच्छी रणनीति है।

यह कॉन्फ़िगरेशन हमारे लिए एक दिन पहले तक ठीक से काम करता था जब हमें एक अलर्ट प्राप्त हुआ और हम नाम स्थान को हटा नहीं सके। नाम स्थान हटाने के संबंध में हमें प्राप्त त्रुटि संदेश यह था:

 $ kubectl delete namespace arslanbekov Error from server (Conflict): Operation cannot be fulfilled on namespaces "arslanbekov": The system is ensuring all content is removed from this namespace. Upon completion, this namespace will automatically be purged by the system.

बलपूर्वक विलोपन विकल्प का उपयोग करने से भी समस्या का समाधान नहीं हुआ:

 $ kubectl get namespace arslanbekov -o yaml apiVersion: v1 kind: Namespace metadata: ... spec: finalizers: - kubernetes status: phase: Terminating

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

एक बेहतर समाधान खोजने के लिए दृढ़ संकल्पित, हमने आगे की जांच करने का निर्णय लिया। अलर्ट ने मेट्रिक्स समस्या का संकेत दिया, जिसकी पुष्टि हमने कमांड चलाकर की:

 $ kubectl api-resources --verbs=list --namespaced -o name error: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

हमने पाया कि मेट्रिक्स-सर्वर पॉड एक आउट-ऑफ-मेमोरी (OOM) त्रुटि और लॉग में पैनिक त्रुटि का अनुभव कर रहा था:

 apiserver panic'd on GET /apis/metrics.k8s.io/v1beta1/nodes: killing connection/stream because serving request timed out and response had been started goroutine 1430 [running]:

फली के संसाधनों की सीमा में कारण था:

कंटेनर अपनी परिभाषा के कारण इन मुद्दों का सामना कर रहा था, जो इस प्रकार था (सीमा ब्लॉक):

 resources: limits: cpu: 51m memory: 123Mi requests: cpu: 51m memory: 123Mi

मुद्दा यह था कि कंटेनर को केवल 51m CPU आवंटित किया गया था, जो मोटे तौर पर एक कोर CPU के 0.05 के बराबर है, और यह इतनी बड़ी संख्या में पॉड्स के लिए मेट्रिक्स को संभालने के लिए पर्याप्त नहीं था। मुख्य रूप से CFS अनुसूचक का उपयोग किया जाता है।

आमतौर पर, ऐसे मुद्दों को ठीक करना सीधा होता है और इसमें पॉड को अधिक संसाधन आवंटित करना शामिल होता है। हालाँकि, GKE में, यह विकल्प UI या gcloud CLI के माध्यम से उपलब्ध नहीं है। ऐसा इसलिए है क्योंकि Google सिस्टम संसाधनों को संशोधित होने से बचाता है, जो समझ में आता है क्योंकि सभी प्रबंधन उनकी ओर से किए जाते हैं।

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

हमें एक और उपाय खोजने की जरूरत थी।

हमारा पहला कदम यह समझना था कि संसाधनों की सीमा इन मूल्यों पर क्यों निर्धारित की गई थी। पॉड में दो कंटेनर होते हैं: metrics-server और addon-resizer । उत्तरार्द्ध संसाधनों को समायोजित करने के लिए जिम्मेदार था क्योंकि क्लस्टर के ऊर्ध्वाधर ऑटोस्केल के लिए एक कार्यवाहक के रूप में कार्य करने वाले नोड्स को क्लस्टर से जोड़ा या हटा दिया गया था।

इसकी कमांड लाइन परिभाषा इस प्रकार थी:

 command: - /pod_nanny - --config-dir=/etc/config - --cpu=40m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi ...

इस परिभाषा में, सीपीयू और मेमोरी आधारभूत संसाधनों का प्रतिनिधित्व करते हैं, जबकि extra-cpu और extra-memory प्रति नोड अतिरिक्त संसाधनों का प्रतिनिधित्व करते हैं। 180 नोड्स के लिए गणना इस प्रकार होगी:

 0.5m * 180 + 40m=~130m

स्मृति संसाधनों पर भी यही तर्क लागू होता है।

दुर्भाग्य से, संसाधनों को बढ़ाने का एकमात्र तरीका अधिक नोड जोड़ना था, जो हम नहीं करना चाहते थे। इसलिए, हमने अन्य विकल्पों का पता लगाने का फैसला किया।

इस मुद्दे को पूरी तरह से हल करने में सक्षम नहीं होने के बावजूद, हम जितनी जल्दी हो सके तैनाती को स्थिर करना चाहते थे। हमने सीखा है कि YAML परिभाषा में कुछ गुणों को GKE द्वारा रोलबैक किए बिना बदला जा सकता है। इसे संबोधित करने के लिए, हमने प्रतिकृतियों की संख्या 1 से बढ़ाकर 5 कर दी , एक स्वास्थ्य जांच जोड़ी और इस लेख के अनुसार रोलआउट रणनीति को समायोजित किया ।

इन कार्रवाइयों ने मेट्रिक्स-सर्वर इंस्टेंस पर लोड को कम करने में मदद की और यह सुनिश्चित किया कि हमारे पास हमेशा कम से कम एक काम करने वाला पॉड हो जो मेट्रिक्स प्रदान कर सके। हमने समस्या पर पुनर्विचार करने और अपने विचारों को ताज़ा करने के लिए कुछ समय लिया। पूर्व-निरीक्षण में समाधान सरल और स्पष्ट हो गया।

हमने ऐड-ऑन-रिसाइज़र के आंतरिक भाग में गहराई से खोज की और पाया कि इसे एक कॉन्फ़िग फ़ाइल और कमांड लाइन पैरामीटर के माध्यम से कॉन्फ़िगर किया जा सकता है। पहली नज़र में, ऐसा लग रहा था कि कमांड लाइन पैरामीटर को कॉन्फ़िगरेशन मानों को ओवरराइड करना चाहिए, लेकिन ऐसा नहीं था।

जांच करने पर, हमने पाया कि कॉन्फ़िग फ़ाइल ऐडऑन-रीज़र कंटेनर के कमांड लाइन मापदंडों के माध्यम से पॉड से जुड़ी थी:

 --config-dir=/etc/config

कॉन्फ़िगरेशन फ़ाइल को सिस्टम नेमस्पेस में metrics-server-config नाम के साथ एक कॉन्फ़िगरेशन मैप के रूप में मैप किया गया था, और GKE इस कॉन्फ़िगरेशन को वापस नहीं करता है!

हमने इस कॉन्फ़िगरेशन के माध्यम से संसाधनों को निम्नानुसार जोड़ा है:

 apiVersion: v1 data: NannyConfiguration: |- apiVersion: nannyconfig/v1alpha1 kind: NannyConfiguration baseCPU: 100m cpuPerNode: 5m baseMemory: 100Mi memoryPerNode: 5Mi kind: ConfigMap metadata:

और यह काम कर गया! यह हमारे लिए एक जीत थी।

जब क्लस्टर का आकार बदल रहा था, तब हमने स्वास्थ्य जांच और शून्य-डाउनटाइम रणनीति के साथ दो पॉड छोड़े थे, और इन परिवर्तनों के बाद हमें कोई और अलर्ट प्राप्त नहीं हुआ।

निष्कर्ष

1. यदि आपके पास सघन रूप से भरा हुआ GKE क्लस्टर है, तो आपको मेट्रिक्स-सर्वर पॉड के साथ समस्याएँ आ सकती हैं। यदि प्रति नोड पॉड्स की संख्या सीमा (110 प्रति नोड) के करीब है, तो पॉड को आवंटित डिफ़ॉल्ट संसाधन पर्याप्त नहीं हो सकते हैं।
2. GKE सिस्टम पॉड्स सहित अपने सिस्टम संसाधनों की सुरक्षा करता है, और उन पर सीधा नियंत्रण असंभव है। हालांकि, कभी-कभी वर्कअराउंड ढूंढना संभव होता है।
3. यह नोट करना महत्वपूर्ण है कि इस बात की कोई गारंटी नहीं है कि भविष्य के अपडेट के बाद भी समाधान काम करेगा। हमने केवल अपने परीक्षण वातावरण में इन मुद्दों का सामना किया है, जहां हमारे पास संसाधनों के लिए अत्यधिक बिक्री की रणनीति है, इसलिए जब यह निराशाजनक है, तब भी हम इसे प्रबंधित कर सकते हैं।