Kubernetes क्लस्टर स्रोतहरू निगरानी गर्दै

मैले कुबे ईगल सिर्जना गरे - एक प्रोमेथियस निर्यातक। यो साना र मध्यम आकारको क्लस्टरहरूको स्रोतहरूलाई अझ राम्रोसँग बुझ्न मद्दत गर्ने एउटा राम्रो कुरा हो। अन्तमा, मैले सयौं डलर बचत गरें किनभने मैले सही मेसिन प्रकारहरू चयन गरेको छु र कार्यभारहरूको लागि अनुप्रयोग स्रोत सीमाहरू कन्फिगर गरेको छु।

म तपाईंलाई फाइदाहरूको बारेमा बताउनेछु कुबे ईगल, तर पहिले म के कारणले गडबड भयो र किन उच्च-गुणस्तर अनुगमन आवश्यक थियो भनेर व्याख्या गर्नेछु।

मैले 4-50 नोडहरूको धेरै क्लस्टरहरू व्यवस्थित गरें। प्रत्येक क्लस्टरमा 200 माइक्रो सेवाहरू र अनुप्रयोगहरू सम्मिलित छन्। अवस्थित हार्डवेयरको राम्रो प्रयोग गर्नका लागि, अधिकांश डिप्लोइमेन्टहरू burstable RAM र CPU स्रोतहरूसँग कन्फिगर गरिएको थियो। यस तरिकाले, आवश्यक भएमा पोडहरूले उपलब्ध स्रोतहरू लिन सक्छन्, र एकै समयमा यो नोडमा अन्य अनुप्रयोगहरूमा हस्तक्षेप गर्दैन। खैर, यो राम्रो छैन?

र यद्यपि क्लस्टरले अपेक्षाकृत थोरै CPU (8%) र RAM (40%) उपभोग गर्‍यो, हामीले नोडमा उपलब्ध भन्दा बढी मेमोरी आवंटित गर्ने प्रयास गर्दा पोडहरू प्रीम्पटेड हुने समस्याहरू थिए। त्यसबेला हामीसँग Kubernetes स्रोतहरू अनुगमनको लागि एउटा मात्र ड्यासबोर्ड थियो। यो जस्तो:

केवल cAdvisor मेट्रिक्स संग Grafana ड्यासबोर्ड

यस्तो प्यानलको साथ, धेरै मेमोरी र CPU खाने नोडहरू हेर्न समस्या छैन। समस्याको कारण के हो पत्ता लगाउनु हो। पोडहरू ठाउँमा राख्नको लागि, एक निश्चित रूपमा सबै पोडहरूमा ग्यारेन्टी स्रोतहरू सेट अप गर्न सक्छ (सीमा बराबर स्रोतहरू अनुरोध गरिएको)। तर यो हार्डवेयरको सबैभन्दा स्मार्ट प्रयोग होइन। क्लस्टरसँग धेरै सय गीगाबाइट मेमोरी थियो, जबकि केही नोडहरू भोकै थिए, जबकि अरूसँग 4-10 GB रिजर्भमा बाँकी थियो।

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

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

मसँग लगभग सबै Kubernetes क्लस्टरहरू मात्र अनुगमन गरिएको छ नोड निर्यातक и कुबे राज्य मेट्रिक्स। नोड एक्सपोर्टरले I/O र डिस्क, CPU, र RAM प्रयोगमा तथ्याङ्कहरू प्रदान गर्दछ, जबकि Kube State Metrics ले Kubernetes वस्तु मेट्रिकहरू जस्तै अनुरोधहरू र CPU र मेमोरी स्रोत सीमाहरू देखाउँछ।

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

कुबे ईगल ड्यासबोर्ड

हामीले धेरै समस्याहरू समाधान गर्न र उपकरणहरू बचत गर्न व्यवस्थित गर्यौं:

1. कतिपय विकासकर्ताहरूलाई कति स्रोतहरू माइक्रोसर्भिसेसहरू चाहिन्छ भनेर थाहा थिएन (वा केवल चिन्ता गरेन)। हामीले स्रोतहरूको लागि गलत अनुरोधहरू फेला पार्ने कुनै तरिका थिएन - यसका लागि हामीले खपत र अनुरोधहरू र सीमाहरू जान्न आवश्यक छ। अब तिनीहरूले प्रोमिथियस मेट्रिक्स देख्छन्, वास्तविक उपयोगको निगरानी गर्छन् र अनुरोध र सीमाहरू समायोजन गर्छन्।
2. JVM एप्लिकेसनहरूले आफूले ह्यान्डल गर्न सक्ने जति धेरै RAM लिन्छन्। फोहोर सङ्कलनकर्ताले ७५% भन्दा बढी प्रयोग हुँदा मात्र मेमोरी रिलिज गर्छ। र धेरैजसो सेवाहरूमा बर्स्टेबल मेमोरी भएको हुनाले, यो सधैं JVM द्वारा कब्जा गरिएको थियो। त्यसकारण, यी सबै जाभा सेवाहरूले अपेक्षा गरेभन्दा धेरै RAM खाइरहेका थिए।
3. केही अनुप्रयोगहरूले धेरै मेमोरी अनुरोध गरे, र Kubernetes अनुसूचकले यी नोडहरू अन्य अनुप्रयोगहरूलाई दिएनन्, यद्यपि तिनीहरू अन्य नोडहरू भन्दा स्वतन्त्र थिए। एक विकासकर्ताले संयोगवश अनुरोधमा अतिरिक्त अंक थप्यो र RAM को ठूलो टुक्रा: 20 को सट्टा 2 GB समात्यो। कसैले ध्यान दिएन। अनुप्रयोगमा 3 प्रतिकृतिहरू थिए, त्यसैले धेरै 3 नोडहरू प्रभावित थिए।
4. हामीले स्रोत सीमाहरू प्रस्तुत गर्‍यौं, सही अनुरोधहरूको साथ पोडहरू पुन: अनुसूचित गर्‍यौं, र सबै नोडहरूमा हार्डवेयर प्रयोगको एक आदर्श सन्तुलन पायौं। केही नोडहरू पूरै बन्द गर्न सकिन्थ्यो। र त्यसपछि हामीले देख्यौं कि हामीसँग गलत मेसिनहरू छन् (CPU उन्मुख, मेमोरी उन्मुख होइन)। हामीले प्रकार परिवर्तन गर्यौं र धेरै नोडहरू हटायौं।

परिणामहरू

क्लस्टरमा burstable स्रोतहरूको साथ, तपाइँ उपलब्ध हार्डवेयर अधिक कुशलतापूर्वक प्रयोग गर्नुहुन्छ, तर Kubernetes अनुसूचकले स्रोतहरूको लागि अनुरोधको आधारमा पोडहरू तालिकाबद्ध गर्दछ, र यो भरिएको छ। एउटै ढुङ्गामा दुई चराहरूलाई मार्न: समस्याहरूबाट बच्न र पूर्ण रूपमा स्रोतहरू प्रयोग गर्न, तपाईंलाई राम्रो निगरानी चाहिन्छ। यसैले यो उपयोगी हुनेछ कुबे ईगल (Prometheus निर्यातक र Grafana ड्यासबोर्ड)।

स्रोत: www.habr.com