हर किसी को अभिवादन! आज हम अपने कुबेरनेट क्लस्टर को प्रबंधित करने के लिए 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 मुद्दा यह था कि कंटेनर को केवल आवंटित किया गया था, जो मोटे तौर पर के बराबर है, और यह इतनी बड़ी संख्या में पॉड्स के लिए मेट्रिक्स को संभालने के लिए पर्याप्त नहीं था। मुख्य रूप से CFS अनुसूचक का उपयोग किया जाता है। 51m CPU एक कोर CPU के 0.05 आमतौर पर, ऐसे मुद्दों को ठीक करना सीधा होता है और इसमें पॉड को अधिक संसाधन आवंटित करना शामिल होता है। हालाँकि, 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 ... इस परिभाषा में, सीपीयू और मेमोरी आधारभूत संसाधनों का प्रतिनिधित्व करते हैं, जबकि और प्रति नोड अतिरिक्त संसाधनों का प्रतिनिधित्व करते हैं। 180 नोड्स के लिए गणना इस प्रकार होगी: extra-cpu extra-memory 0.5m * 180 + 40m=~130m स्मृति संसाधनों पर भी यही तर्क लागू होता है। दुर्भाग्य से, संसाधनों को बढ़ाने का एकमात्र तरीका अधिक नोड जोड़ना था, जो हम नहीं करना चाहते थे। इसलिए, हमने अन्य विकल्पों का पता लगाने का फैसला किया। हमने सीखा है कि YAML परिभाषा में कुछ गुणों को GKE द्वारा रोलबैक किए बिना बदला जा सकता है। इसे संबोधित करने के लिए, , और के अनुसार । इस मुद्दे को पूरी तरह से हल करने में सक्षम नहीं होने के बावजूद, हम जितनी जल्दी हो सके तैनाती को स्थिर करना चाहते थे। हमने प्रतिकृतियों की संख्या 1 से बढ़ाकर 5 कर दी एक स्वास्थ्य जांच जोड़ी इस लेख रोलआउट रणनीति को समायोजित किया इन कार्रवाइयों ने मेट्रिक्स-सर्वर इंस्टेंस पर लोड को कम करने में मदद की और यह सुनिश्चित किया कि हमारे पास हमेशा कम से कम एक काम करने वाला पॉड हो जो मेट्रिक्स प्रदान कर सके। हमने समस्या पर पुनर्विचार करने और अपने विचारों को ताज़ा करने के लिए कुछ समय लिया। पूर्व-निरीक्षण में समाधान सरल और स्पष्ट हो गया। हमने ऐड-ऑन-रिसाइज़र के आंतरिक भाग में गहराई से खोज की और पाया कि इसे एक कॉन्फ़िग फ़ाइल और कमांड लाइन पैरामीटर के माध्यम से कॉन्फ़िगर किया जा सकता है। पहली नज़र में, ऐसा लग रहा था कि कमांड लाइन पैरामीटर को कॉन्फ़िगरेशन मानों को ओवरराइड करना चाहिए, लेकिन ऐसा नहीं था। जांच करने पर, हमने पाया कि कॉन्फ़िग फ़ाइल ऐडऑन-रीज़र कंटेनर के कमांड लाइन मापदंडों के माध्यम से पॉड से जुड़ी थी: --config-dir=/etc/config कॉन्फ़िगरेशन फ़ाइल को सिस्टम नेमस्पेस में नाम के साथ एक कॉन्फ़िगरेशन मैप के रूप में मैप किया गया था, और GKE इस कॉन्फ़िगरेशन को वापस नहीं करता है! metrics-server-config हमने इस कॉन्फ़िगरेशन के माध्यम से संसाधनों को निम्नानुसार जोड़ा है: apiVersion: v1 data: NannyConfiguration: |- apiVersion: nannyconfig/v1alpha1 kind: NannyConfiguration baseCPU: 100m cpuPerNode: 5m baseMemory: 100Mi memoryPerNode: 5Mi kind: ConfigMap metadata: और यह काम कर गया! यह हमारे लिए एक जीत थी। जब क्लस्टर का आकार बदल रहा था, तब हमने स्वास्थ्य जांच और शून्य-डाउनटाइम रणनीति के साथ दो पॉड छोड़े थे, और इन परिवर्तनों के बाद हमें कोई और अलर्ट प्राप्त नहीं हुआ। निष्कर्ष यदि आपके पास सघन रूप से भरा हुआ GKE क्लस्टर है, तो आपको मेट्रिक्स-सर्वर पॉड के साथ समस्याएँ आ सकती हैं। यदि प्रति नोड पॉड्स की संख्या सीमा (110 प्रति नोड) के करीब है, तो पॉड को आवंटित डिफ़ॉल्ट संसाधन पर्याप्त नहीं हो सकते हैं। GKE सिस्टम पॉड्स सहित अपने सिस्टम संसाधनों की सुरक्षा करता है, और उन पर सीधा नियंत्रण असंभव है। हालांकि, कभी-कभी वर्कअराउंड ढूंढना संभव होता है। यह नोट करना महत्वपूर्ण है कि इस बात की कोई गारंटी नहीं है कि भविष्य के अपडेट के बाद भी समाधान काम करेगा। हमने केवल अपने परीक्षण वातावरण में इन मुद्दों का सामना किया है, जहां हमारे पास संसाधनों के लिए अत्यधिक बिक्री की रणनीति है, इसलिए जब यह निराशाजनक है, तब भी हम इसे प्रबंधित कर सकते हैं।
