कुबेरनेट्स क्लस्टर संसाधनों की निगरानी करना

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

मैं आपको फायदों के बारे में बताऊंगा क्यूब ईगल, लेकिन पहले मैं समझाऊंगा कि उपद्रव का कारण क्या था और उच्च गुणवत्ता वाली निगरानी की आवश्यकता क्यों थी।

मैंने 4-50 नोड्स के कई क्लस्टर प्रबंधित किए। प्रत्येक क्लस्टर में 200 तक माइक्रोसर्विसेज और एप्लिकेशन शामिल हैं। मौजूदा हार्डवेयर का बेहतर उपयोग करने के लिए, अधिकांश परिनियोजन को बर्स्टेबल रैम और सीपीयू संसाधनों के साथ कॉन्फ़िगर किया गया था। इस तरह, यदि आवश्यक हो तो पॉड उपलब्ध संसाधन ले सकते हैं, और साथ ही इस नोड पर अन्य अनुप्रयोगों में हस्तक्षेप नहीं करते हैं। अच्छा, क्या यह बढ़िया नहीं है?

और यद्यपि क्लस्टर ने अपेक्षाकृत कम सीपीयू (8%) और रैम (40%) की खपत की, लेकिन जब वे नोड पर उपलब्ध मेमोरी से अधिक मेमोरी आवंटित करने का प्रयास करते थे, तो हमें लगातार पॉड्स के प्री-एम्प्ट होने की समस्या होती थी। उस समय कुबेरनेट्स संसाधनों की निगरानी के लिए हमारे पास केवल एक डैशबोर्ड था। इस कदर:

ग्राफाना डैशबोर्ड केवल cAdvisor मेट्रिक्स के साथ

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

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

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

मेरे पास लगभग सभी Kubernetes क्लस्टरों की केवल निगरानी है नोड निर्यातक и क्यूब स्टेट मेट्रिक्स. नोड एक्सपोर्टर I/O और डिस्क, सीपीयू और रैम उपयोग पर आंकड़े प्रदान करता है, जबकि क्यूब स्टेट मेट्रिक्स कुबेरनेट्स ऑब्जेक्ट मेट्रिक्स जैसे अनुरोध और सीपीयू और मेमोरी संसाधन सीमाएं दिखाता है।

हमें ग्राफाना में उपयोग मेट्रिक्स को अनुरोधों और सीमा मेट्रिक्स के साथ संयोजित करने की आवश्यकता है, और फिर हमें समस्या के बारे में सारी जानकारी मिल जाएगी। यह सरल लगता है, लेकिन दोनों उपकरण वास्तव में लेबल को अलग-अलग नाम देते हैं, और कुछ मेट्रिक्स में कोई मेटाडेटा लेबल नहीं होता है। क्यूब ईगल सब कुछ स्वयं करता है और पैनल इस तरह दिखता है:

क्यूब ईगल डैशबोर्ड

हम संसाधनों के साथ कई समस्याओं को हल करने और उपकरण बचाने में कामयाब रहे:

1. कुछ डेवलपर्स को यह नहीं पता था कि माइक्रोसर्विसेज को कितने संसाधनों की आवश्यकता है (या बस उन्होंने इसकी परवाह नहीं की)। हमारे पास संसाधनों के लिए गलत अनुरोध ढूंढने का कोई तरीका नहीं था - इसके लिए हमें उपभोग प्लस अनुरोध और सीमाएं जानने की जरूरत है। अब वे प्रोमेथियस मेट्रिक्स देखते हैं, वास्तविक उपयोग की निगरानी करते हैं और अनुरोधों और सीमाओं को समायोजित करते हैं।
2. जेवीएम एप्लिकेशन उतनी ही रैम लेते हैं जितनी वे संभाल सकते हैं। कचरा संग्रहकर्ता केवल तभी मेमोरी जारी करता है जब 75% से अधिक का उपयोग किया जाता है। और चूँकि अधिकांश सेवाओं में बर्स्टेबल मेमोरी होती है, इसलिए उस पर हमेशा JVM का कब्ज़ा रहता था। इसलिए, ये सभी जावा सेवाएँ अपेक्षा से कहीं अधिक रैम खा रही थीं।
3. कुछ अनुप्रयोगों ने बहुत अधिक मेमोरी का अनुरोध किया, और कुबेरनेट्स शेड्यूलर ने इन नोड्स को अन्य अनुप्रयोगों को नहीं दिया, भले ही वास्तव में वे अन्य नोड्स की तुलना में अधिक मुक्त थे। एक डेवलपर ने गलती से अनुरोध में एक अतिरिक्त अंक जोड़ दिया और रैम का एक बड़ा टुकड़ा पकड़ लिया: 20 के बजाय 2 जीबी। किसी ने ध्यान नहीं दिया। एप्लिकेशन में 3 प्रतिकृतियां थीं, इसलिए कम से कम 3 नोड प्रभावित हुए।
4. हमने संसाधन सीमाएं पेश कीं, सही अनुरोधों के साथ पॉड्स को पुनर्निर्धारित किया, और सभी नोड्स में हार्डवेयर उपयोग का एक आदर्श संतुलन प्राप्त किया। कुछ नोड्स को पूरी तरह से बंद किया जा सकता था। और फिर हमने देखा कि हमारे पास गलत मशीनें थीं (सीपीयू उन्मुख, मेमोरी उन्मुख नहीं)। हमने प्रकार बदल दिया और कई और नोड्स हटा दिए।

परिणाम

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

स्रोत: www.habr.com