कसरी Kubernetes मा pod priorities ले Grafana Labs मा डाउनटाइम निम्त्यायो

नोट। अनुवाद।: हामी Grafana का सिर्जनाकर्ताहरू द्वारा राखिएको क्लाउड सेवामा हालैको डाउनटाइमको कारणहरूको बारेमा तपाइँको ध्यानाकर्षणमा प्राविधिक विवरणहरू प्रस्तुत गर्दछौं। यो एक उत्कृष्ट उदाहरण हो कि कसरी पूर्वाधारको गुणस्तर सुधार गर्न डिजाइन गरिएको नयाँ र एकदमै उपयोगी सुविधाले हानि पुऱ्याउन सक्छ यदि तपाईंले उत्पादनको वास्तविकताहरूमा यसको प्रयोगको असंख्य सूक्ष्मताहरू प्रदान गर्नुभएन भने। यो राम्रो छ जब यस्ता सामग्रीहरू देखा पर्छन् जसले तपाईंलाई आफ्ना गल्तीहरूबाट मात्र सिक्न अनुमति दिन्छ। विवरणहरू यस पाठको अनुवादमा Grafana Labs बाट उत्पादनका उपाध्यक्षबाट छन्।

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

प्रागितिहास

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

सिमलेस अपडेटहरूको लागि, Ingester Cortex सेवालाई अद्यावधिक प्रक्रियाको क्रममा अतिरिक्त Ingester प्रतिकृति चाहिन्छ। (नोट। अनुवाद।: इन्जेस्टर - Cortex को आधारभूत घटक। यसको काम नमूनाहरूको निरन्तर स्ट्रिम सङ्कलन गर्नु हो, तिनीहरूलाई प्रोमेथियस खण्डहरूमा समूहबद्ध गर्नु र DynamoDB, BigTable वा Cassandra जस्ता डाटाबेसमा भण्डारण गर्नु हो।) यसले पुराना इन्जेस्टरहरूलाई हालको डाटालाई नयाँ इन्जेस्टरहरूमा फर्वार्ड गर्न अनुमति दिन्छ। यो ध्यान दिन लायक छ कि Ingesters संसाधन-माग गर्दै छन्। तिनीहरूलाई काम गर्नको लागि, तपाईंसँग 4 कोर र 15 GB मेमोरी प्रति पोड हुन आवश्यक छ, अर्थात्। हाम्रो Kubernetes क्लस्टरहरूको मामलामा आधार मेसिनको प्रशोधन शक्ति र मेमोरीको 25%। सामान्यतया, हामीसँग क्लस्टरमा 4 कोर र 15 GB मेमोरी भन्दा धेरै धेरै अप्रयुक्त स्रोतहरू हुन्छन्, त्यसैले हामी अपग्रेडको क्रममा यी अतिरिक्त इन्जेस्टरहरूलाई सजिलैसँग स्पिन गर्न सक्छौं।

यद्यपि, यो प्रायः हुन्छ कि सामान्य सञ्चालनको समयमा कुनै पनि मेसिनमा यो 25% अप्रयुक्त स्रोतहरू छैनन्। हो, हामी प्रयास पनि गर्दैनौं: CPU र मेमोरी सधैं अन्य प्रक्रियाहरूको लागि उपयोगी हुनेछ। यो समस्या समाधान गर्न, हामीले प्रयोग गर्ने निर्णय गर्यौं Kubernetes Pod प्राथमिकताहरू। अन्य (स्टेटलेस) माइक्रोसर्भिसेसहरू भन्दा इन्जेस्टरहरूलाई उच्च प्राथमिकता दिने विचार हो। जब हामीलाई अतिरिक्त (N+1) इन्जेस्टर चलाउन आवश्यक हुन्छ, हामी अस्थायी रूपमा अन्य, साना पोडहरू विस्थापित गर्छौं। यी पोडहरूलाई अन्य मेसिनहरूमा नि:शुल्क स्रोतहरूमा स्थानान्तरण गरिन्छ, थप इन्जेस्टर चलाउन पर्याप्त ठूलो "प्वाल" छोडेर।

बिहीबार, जुलाई 18 मा, हामीले हाम्रा क्लस्टरहरूमा चार नयाँ प्राथमिकता स्तरहरू रोल आउट गर्यौं: आलोचनात्मक, высокий, औसत и low। तिनीहरू एक हप्ताको लागि कुनै ग्राहक ट्राफिक बिना आन्तरिक क्लस्टरमा परीक्षण गरियो। पूर्वनिर्धारित रूपमा, निर्दिष्ट प्राथमिकता बिना पोडहरू प्राप्त भयो औसत प्राथमिकता, कक्षा Ingesters को लागि सेट गरिएको थियो उच्च प्राथमिकता। क्रिटिकल अनुगमनका लागि आरक्षित गरिएको थियो (प्रोमेथियस, चेतावनी व्यवस्थापक, नोड-निर्यातकर्ता, क्युबे-स्टेट-मेट्रिक्स, आदि)। हाम्रो कन्फिगरेसन खुला छ, र तपाइँ PR हेर्न सक्नुहुन्छ यहाँ.

दुर्घटना

शुक्रबार, जुलाई 19 मा, एक इन्जिनियरले ठूलो ग्राहकको लागि नयाँ समर्पित कोर्टेक्स क्लस्टर सुरु गरे। यस क्लस्टरको कन्फिगरेसनले नयाँ पोड प्राथमिकताहरू समावेश गर्दैन, त्यसैले सबै नयाँ पोडहरूलाई पूर्वनिर्धारित प्राथमिकता तोकियो - औसत.

Kubernetes क्लस्टरसँग नयाँ कोर्टेक्स क्लस्टरको लागि पर्याप्त स्रोतहरू थिएनन्, र अवस्थित उत्पादन कोर्टेक्स क्लस्टर अद्यावधिक गरिएको थिएन (इन्जेस्टरहरू बिना नै छोडियो। उच्च प्राथमिकता)। किनकि पूर्वनिर्धारित रूपमा नयाँ क्लस्टरको इन्जेस्टरहरू थिए औसत प्राथमिकता, र उत्पादनमा अवस्थित पोडहरूले कुनै पनि प्राथमिकता बिना काम गरे, नयाँ क्लस्टरका इन्जेस्टरहरूले अवस्थित कोर्टेक्स उत्पादन क्लस्टरबाट इन्जेस्टरहरूलाई प्रतिस्थापन गरे।

उत्पादन क्लस्टरमा बेदखल गरिएको इन्जेस्टरको लागि ReplicaSet ले बेदखल गरिएको पोड पत्ता लगायो र प्रतिलिपिहरूको निर्दिष्ट संख्या कायम राख्न नयाँ सिर्जना गर्यो। नयाँ पोड पूर्वनिर्धारित रूपमा तोकिएको थियो औसत प्राथमिकता, र उत्पादनमा अर्को "पुरानो" इन्जेस्टरले यसको स्रोतहरू गुमायो। नतिजा आयो हिमस्खलन प्रक्रिया, जसले Cortex उत्पादन क्लस्टरहरूको लागि Ingester बाट सबै पोडहरूको विस्थापनको नेतृत्व गर्‍यो।

इन्जेस्टरहरू स्टेटफुल हुन्छन् र पछिल्लो १२ घण्टाको लागि डाटा भण्डारण गर्छन्। यसले हामीलाई तिनीहरूलाई लामो-समय भण्डारणमा लेख्नु अघि तिनीहरूलाई अझ प्रभावकारी रूपमा कम्प्रेस गर्न अनुमति दिन्छ। यो प्राप्त गर्नको लागि, Cortex ले डिस्ट्रिब्युटेड ह्यास टेबल (DHT) को प्रयोग गरी शृङ्खलाहरूमा डेटालाई जोड्छ र Dynamo-शैली कोरम स्थिरता प्रयोग गरी तीनवटा इन्जेस्टरहरूमा प्रत्येक शृङ्खलालाई दोहोर्याउँछ। Cortex ले अक्षम भएका Ingesters लाई डेटा लेख्दैन। यसरी, जब ठूलो संख्यामा इन्जेस्टरहरूले DHT छोड्छन्, कोर्टेक्सले प्रविष्टिहरूको पर्याप्त प्रतिकृति प्रदान गर्न सक्दैन, र तिनीहरू क्र्यास हुन्छन्।

पत्ता लगाउने र उपचार

"त्रुटि बजेट" मा आधारित नयाँ Prometheus सूचनाहरू (त्रुटि-बजेट-आधारित — विवरणहरू भविष्यको लेखमा देखा पर्नेछ) बन्द सुरु भएको 4 मिनेट पछि अलार्म बज्न थाले। अर्को पाँच मिनेट वा सो भन्दा बढीमा, हामीले केही निदानहरू चलायौं र नयाँ र अवस्थित उत्पादन क्लस्टरहरू होस्ट गर्न अन्तर्निहित Kubernetes क्लस्टरलाई मापन गर्यौं।

अर्को पाँच मिनेट पछि, पुराना इन्जेस्टरहरूले सफलतापूर्वक आफ्नो डेटा लेखे, नयाँहरू सुरु भयो, र कोर्टेक्स क्लस्टरहरू फेरि उपलब्ध भए।

Cortex को अगाडि अवस्थित प्रमाणीकरण रिभर्स प्रोक्सीहरूबाट आउट-अफ-मेमोरी (OOM) त्रुटिहरूको निदान र सुधार गर्न थप 10 मिनेट खर्च गरियो। OOM त्रुटिहरू QPS मा दस गुणा वृद्धिको कारणले भएको थियो (हामी ग्राहकको प्रोमेथियस सर्भरहरूबाट अत्यधिक आक्रामक अनुरोधहरूको कारणले विश्वास गर्छौं)।

परिणामहरू

कुल डाउनटाइम 26 मिनेट थियो। कुनै डाटा हराएको छैन। इन्जेस्टरहरूले सफलतापूर्वक सबै इन-मेमोरी डाटा लामो-समय भण्डारणमा लोड गरेका छन्। बन्दको समयमा, ग्राहक प्रोमेथियस सर्भरहरू बफर मेटाइयो (रिमोट) रेकर्डिङ प्रयोग गरेर नयाँ API remote_write WAL मा आधारित (द्वारा लेखक Callum Styan Grafana Labs बाट) र दुर्घटना पछि असफल लेखहरू दोहोर्याउनुहोस्।

उत्पादन क्लस्टर लेखन कार्यहरू

निष्कर्ष

यो घटनाबाट पाठ सिक्न र यसको पुनरावृत्तिबाट बच्न आवश्यक कदम चाल्न महत्त्वपूर्ण छ।

पछाडी मा, हामीले पूर्वनिर्धारित सेट गर्नुपर्दैन औसत उत्पादनमा सबै इन्जेस्टरहरूले प्राप्त नगरेसम्म प्राथमिकता высокий एक प्राथमिकता। साथै, यो अग्रिम हेरचाह गर्न आवश्यक थियो उच्च प्राथमिकता। अब सबै ठीक छ। हामी आशा गर्छौं कि हाम्रो अनुभवले अन्य संस्थाहरूलाई कुबेरनेटमा पोड प्राथमिकताहरू प्रयोग गर्ने विचारमा मद्दत गर्नेछ।

हामी कुनै पनि अतिरिक्त वस्तुहरूको परिनियोजनमा नियन्त्रणको अतिरिक्त स्तर थप्नेछौं जसको कन्फिगरेसनहरू क्लस्टरमा विश्वव्यापी छन्। अब देखि, त्यस्ता परिवर्तनहरू मूल्याङ्कन गरिनेछ खоधेरै मानिसहरू। थप रूपमा, दुर्घटनाको कारण परिमार्जन एक अलग परियोजना कागजात को लागी धेरै माइनर मानिएको थियो - यो केवल एक GitHub मुद्दा मा छलफल गरिएको थियो। अब देखि, कन्फिगमा त्यस्ता सबै परिवर्तनहरू उपयुक्त परियोजना कागजातहरूसँगै हुनेछन्।

अन्तमा, हामीले देखेका ओओएमलाई रोक्न प्रमाणीकरण रिभर्स प्रोक्सीको रिसाइजिङ स्वचालित गर्नेछौं, र भविष्यमा यस्तै समस्याहरू रोक्नको लागि फलब्याक र स्केलिङसँग सम्बन्धित प्रोमेथियस पूर्वनिर्धारित सेटिङहरूको समीक्षा गर्नेछौं।

असफलताले केही सकारात्मक नतिजाहरू पनि पाए: आवश्यक स्रोतहरू प्राप्त गरिसकेपछि, कोर्टेक्सले अतिरिक्त हस्तक्षेप बिना स्वचालित रूपमा पुनःप्राप्त गर्यो। हामीले काम गर्दाको बहुमूल्य अनुभव पनि प्राप्त गरेका छौं ग्राफाना लोकी - हाम्रो नयाँ लग एग्रीगेसन प्रणाली - जसले असफलताको समयमा र पछि सबै इन्जेस्टरहरूले ठीकसँग व्यवहार गरेको सुनिश्चित गर्न मद्दत गर्‍यो।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes मा स्वत: स्केलिंग र संसाधन व्यवस्थापन (अवलोकन र भिडियो रिपोर्ट)»;
• «Kubernetes साहसिक डेलीमोशन: क्लाउडहरू + अन-प्रिमाइसेसमा पूर्वाधार सिर्जना गर्दै»;
• «कुबेरनेटमा टिन्डर संक्रमण»;
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग १०: Reddit"।

स्रोत: www.habr.com