कुबर्नेट्स क्लस्टर संसाधनांचे निरीक्षण करणे

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

मी तुम्हाला फायद्यांबद्दल सांगेन कुबे गरुड, परंतु प्रथम मी गडबड कशामुळे झाली आणि उच्च-गुणवत्तेचे निरीक्षण का आवश्यक आहे हे स्पष्ट करेन.

मी 4-50 नोड्सचे अनेक क्लस्टर व्यवस्थापित केले. प्रत्येक क्लस्टरमध्ये 200 पर्यंत मायक्रो सर्व्हिसेस आणि ऍप्लिकेशन्स असतात. विद्यमान हार्डवेअरचा अधिक चांगला वापर करण्यासाठी, बर्स्टेबल RAM आणि CPU संसाधनांसह बहुतेक उपयोजने कॉन्फिगर केली गेली. अशा प्रकारे, आवश्यक असल्यास पॉड्स उपलब्ध संसाधने घेऊ शकतात आणि त्याच वेळी या नोडवरील इतर अनुप्रयोगांमध्ये व्यत्यय आणू शकत नाहीत. बरं, छान आहे ना?

आणि जरी क्लस्टर तुलनेने कमी CPU (8%) आणि RAM (40%) वापरत असले तरी, जेव्हा त्यांनी नोडवर उपलब्ध असलेल्या मेमरीपेक्षा जास्त मेमरी वाटप करण्याचा प्रयत्न केला तेव्हा आम्हाला पॉड्स प्रीम्प्प्ट करण्यात समस्या येत होत्या. तेव्हा आमच्याकडे Kubernetes संसाधनांचे परीक्षण करण्यासाठी फक्त एक डॅशबोर्ड होता. याप्रमाणे:

केवळ cAdvisor मेट्रिक्ससह Grafana डॅशबोर्ड

अशा पॅनेलसह, भरपूर मेमरी आणि CPU खाणारे नोड्स पाहण्यात समस्या नाही. कारण काय आहे हे शोधण्यात अडचण आहे. शेंगा जागच्या जागी ठेवण्यासाठी, सर्व शेंगा (मर्यादेच्या समान संसाधनांची विनंती केलेली) वर निश्चितच हमी संसाधने सेट करू शकतात. पण हा हार्डवेअरचा सर्वात हुशार वापर नाही. क्लस्टरमध्ये अनेक शेकडो गीगाबाइट मेमरी होती, काही नोड्स भुकेले होते, तर इतरांकडे 4-10 GB राखीव शिल्लक होते.

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

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

माझ्याकडे जवळजवळ सर्व कुबर्नेट्स क्लस्टर्सचे निरीक्षण केले आहे नोड निर्यातक и कुबे स्टेट मेट्रिक्स. नोड एक्सपोर्टर I/O आणि डिस्क, CPU आणि RAM वापरावरील आकडेवारी प्रदान करतो, तर Kube State Metrics Kubernetes ऑब्जेक्ट मेट्रिक्स जसे की विनंत्या आणि CPU आणि मेमरी संसाधन मर्यादा दर्शविते.

आम्हाला Grafana मधील विनंत्या आणि मर्यादा मेट्रिक्ससह वापर मेट्रिक्स एकत्र करणे आवश्यक आहे आणि त्यानंतर आम्हाला समस्येबद्दल सर्व माहिती मिळेल. हे सोपे वाटते, परंतु दोन साधने प्रत्यक्षात लेबलांना वेगळी नावे देतात आणि काही मेट्रिक्समध्ये कोणतेही मेटाडेटा लेबल नसतात. कुबे ईगल सर्वकाही स्वतः करतो आणि पॅनेल असे दिसते:

कुबे ईगल डॅशबोर्ड

आम्ही संसाधनांसह अनेक समस्यांचे निराकरण करण्यात आणि उपकरणे जतन करण्यात व्यवस्थापित केले:

1. काही विकसकांना मायक्रोसर्व्हिसेसची किती संसाधने आवश्यक आहेत हे माहित नव्हते (किंवा फक्त त्रास दिला नाही). आमच्यासाठी संसाधनांसाठी चुकीच्या विनंत्या शोधण्याचा कोणताही मार्ग नव्हता - यासाठी आम्हाला उपभोग अधिक विनंत्या आणि मर्यादा माहित असणे आवश्यक आहे. आता ते प्रोमिथियस मेट्रिक्स पाहतात, वास्तविक वापराचे निरीक्षण करतात आणि विनंत्या आणि मर्यादा समायोजित करतात.
2. JVM ऍप्लिकेशन्स ते हाताळू शकतील तेवढी RAM घेतात. जेव्हा 75% पेक्षा जास्त वापरले जाते तेव्हाच कचरा गोळा करणारा मेमरी सोडतो. आणि बहुतेक सेवांमध्ये बर्स्टेबल मेमरी असल्याने, ती नेहमी JVM द्वारे व्यापलेली असते. त्यामुळे, या सर्व Java सेवा अपेक्षेपेक्षा जास्त RAM खात होत्या.
3. काही ऍप्लिकेशन्सने खूप जास्त मेमरीची विनंती केली, आणि कुबर्नेट्स शेड्युलरने हे नोड्स इतर ऍप्लिकेशन्सना दिले नाहीत, जरी ते इतर नोड्सपेक्षा मोकळे होते. एका विकसकाने चुकून विनंतीमध्ये अतिरिक्त अंक जोडला आणि RAM चा एक मोठा तुकडा पकडला: 20 ऐवजी 2 GB. कोणाच्याही लक्षात आले नाही. अर्जात 3 प्रतिकृती होत्या, त्यामुळे तब्बल 3 नोड प्रभावित झाले.
4. आम्ही संसाधन मर्यादा सादर केल्या, योग्य विनंत्यांसह पॉड्स पुन्हा शेड्यूल केले आणि सर्व नोड्समध्ये हार्डवेअर वापराचा एक आदर्श शिल्लक मिळाला. दोन नोड पूर्णपणे बंद केले जाऊ शकतात. आणि मग आम्ही पाहिले की आमच्याकडे चुकीची मशीन आहेत (CPU ओरिएंटेड, मेमरी ओरिएंटेड नाही). आम्ही प्रकार बदलला आणि आणखी अनेक नोड हटवले.

परिणाम

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

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