डोमक्लिक पर कुबेरनेट्स: 1000 माइक्रोसर्विसेज के क्लस्टर को प्रबंधित करते हुए शांति से कैसे सोएं

मेरा नाम विक्टर यागोफ़ारोव है, और मैं ऑप्स (ऑपरेशन) टीम में तकनीकी विकास प्रबंधक के रूप में डोमक्लिक में कुबेरनेट्स प्लेटफ़ॉर्म विकसित कर रहा हूं। मैं हमारी डेव <-> ऑप्स प्रक्रियाओं की संरचना, रूस में सबसे बड़े k8s क्लस्टरों में से एक के संचालन की विशेषताओं के साथ-साथ हमारी टीम द्वारा लागू की जाने वाली DevOps/SRE प्रथाओं के बारे में बात करना चाहूंगा।

ऑप्स टीम

ऑप्स टीम में फिलहाल 15 लोग हैं। उनमें से तीन कार्यालय के लिए जिम्मेदार हैं, दो अलग-अलग समय क्षेत्र में काम करते हैं और रात में भी उपलब्ध रहते हैं। इस प्रकार, ऑप्स से कोई व्यक्ति हमेशा मॉनिटर पर रहता है और किसी भी जटिलता की घटना पर प्रतिक्रिया देने के लिए तैयार रहता है। हमारे पास रात की पाली नहीं है, जो हमारे मानस को सुरक्षित रखती है और हर किसी को पर्याप्त नींद लेने और न केवल कंप्यूटर पर ख़ाली समय बिताने का अवसर देती है।

हर किसी की अलग-अलग योग्यताएँ होती हैं: नेटवर्कर्स, डीबीए, ईएलके स्टैक विशेषज्ञ, कुबेरनेट्स एडमिन/डेवलपर्स, मॉनिटरिंग, वर्चुअलाइजेशन, हार्डवेयर विशेषज्ञ, आदि। एक चीज सभी को एकजुट करती है - हर कोई कुछ हद तक हममें से किसी को भी बदल सकता है: उदाहरण के लिए, k8s क्लस्टर में नए नोड्स पेश करें, PostgreSQL को अपडेट करें, CI/CD + Ansible पाइपलाइन लिखें, Python/Bash/Go में कुछ स्वचालित करें, हार्डवेयर को कनेक्ट करें डेटा सेंटर। किसी भी क्षेत्र में मजबूत योग्यताएं आपको अपनी गतिविधि की दिशा बदलने और किसी अन्य क्षेत्र में सुधार शुरू करने से नहीं रोकती हैं। उदाहरण के लिए, मैं PostgreSQL विशेषज्ञ के रूप में एक कंपनी में शामिल हुआ, और अब मेरी ज़िम्मेदारी का मुख्य क्षेत्र Kubernetes क्लस्टर है। टीम में किसी भी ऊंचाई का स्वागत है और उत्तोलन की भावना बहुत विकसित है।

वैसे, हम शिकार कर रहे हैं. उम्मीदवारों के लिए आवश्यकताएँ काफी मानक हैं। मेरे लिए व्यक्तिगत रूप से, यह महत्वपूर्ण है कि एक व्यक्ति टीम में फिट बैठता है, गैर-संघर्ष करता है, लेकिन यह भी जानता है कि अपनी बात का बचाव कैसे करना है, विकास करना चाहता है और कुछ नया करने से डरता नहीं है, अपने विचार प्रस्तुत करता है। इसके अलावा, स्क्रिप्टिंग भाषाओं में प्रोग्रामिंग कौशल, लिनक्स और अंग्रेजी की मूल बातें का ज्ञान आवश्यक है। अंग्रेजी की जरूरत सिर्फ इसलिए है ताकि फेकअप की स्थिति में कोई व्यक्ति 10 मिनट में नहीं बल्कि 10 सेकंड में समस्या का समाधान गूगल पर ढूंढ सके। अब लिनक्स के गहन ज्ञान वाले विशेषज्ञों को ढूंढना बहुत मुश्किल है: यह हास्यास्पद है, लेकिन तीन में से दो उम्मीदवार इस सवाल का जवाब नहीं दे सकते हैं कि "लोड औसत क्या है?" यह किस चीज से बना है?", और सवाल "सी प्रोग्राम से कोर डंप कैसे इकट्ठा करें" को सुपरमैन या डायनासोर की दुनिया से कुछ माना जाता है। हमें इसे स्वीकार करना होगा, क्योंकि आमतौर पर लोगों में अन्य योग्यताएं अत्यधिक विकसित होती हैं, लेकिन हम लिनक्स सिखाएंगे। प्रश्न का उत्तर "एक DevOps इंजीनियर को बादलों की आधुनिक दुनिया में यह सब जानने की आवश्यकता क्यों है" को लेख के दायरे से बाहर छोड़ना होगा, लेकिन तीन शब्दों में: यह सब आवश्यक है।

टीम उपकरण

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

ऑप्स टीम डेवलपर्स के लिए पाइपलाइन नहीं लिखती है, लेकिन अपने लेखन में किसी भी मुद्दे पर सलाह दे सकती है (कुछ लोगों के पास अभी भी हेल्म 3 है)।

DevOps

जहां तक ​​DevOps का सवाल है, हम इसे इस तरह देखते हैं:

देव टीमें कोड लिखती हैं, उसे कॉन्फर के माध्यम से डेव -> क्यूए/स्टेज -> प्रोड पर रोल आउट करती हैं। यह सुनिश्चित करने की ज़िम्मेदारी कि कोड धीमा न हो और इसमें त्रुटियाँ न हों, डेव और ऑप्स टीमों की है। दिन के समय, ऑप्स टीम के ड्यूटी पर मौजूद व्यक्ति को सबसे पहले अपने आवेदन के साथ किसी घटना का जवाब देना चाहिए, और शाम और रात में, ड्यूटी पर मौजूद प्रशासक (ऑप्स) को ड्यूटी पर मौजूद डेवलपर को जगाना चाहिए, यदि उसे इसके बारे में पता हो सुनिश्चित करें कि समस्या बुनियादी ढांचे में नहीं है। मॉनिटरिंग में सभी मेट्रिक्स और अलर्ट स्वचालित या अर्ध-स्वचालित रूप से दिखाई देते हैं।

ऑप्स की जिम्मेदारी का क्षेत्र उस क्षण से शुरू होता है जब एप्लिकेशन को उत्पादन में लाया जाता है, लेकिन देव की जिम्मेदारी यहीं खत्म नहीं होती है - हम वही काम करते हैं और एक ही नाव में हैं।

यदि डेवलपर्स को एडमिन माइक्रोसर्विस (उदाहरण के लिए, गो बैकएंड + HTML5) लिखने में सहायता की आवश्यकता होती है, तो वे एडमिन को सलाह देते हैं, और एडमिन किसी भी बुनियादी ढांचे के मुद्दों या k8s से संबंधित मुद्दों पर डेवलपर्स को सलाह देते हैं।

वैसे, हमारे पास कोई मोनोलिथ नहीं है, केवल माइक्रोसर्विसेज हैं। यदि संख्या द्वारा मापा जाता है, तो उनकी संख्या अब तक उत्पाद k900s क्लस्टर में 1000 और 8 के बीच उतार-चढ़ाव करती है तैनाती. पॉड्स की संख्या 1700 और 2000 के बीच घटती-बढ़ती रहती है। वर्तमान में प्रोड क्लस्टर में लगभग 2000 पॉड्स हैं।

मैं सटीक संख्या नहीं दे सकता, क्योंकि हम अनावश्यक माइक्रोसर्विसेज की निगरानी करते हैं और उन्हें अर्ध-स्वचालित रूप से काट देते हैं। K8s हमें अनावश्यक संस्थाओं पर नज़र रखने में मदद करता है बेकार-ऑपरेटर, जिससे बहुत सारे संसाधन और पैसे की बचत होती है।

संसाधन प्रबंधन

निगरानी

एक बड़े क्लस्टर के संचालन में अच्छी तरह से संरचित और सूचनात्मक निगरानी आधारशिला बन जाती है। हमें अभी तक एक सार्वभौमिक समाधान नहीं मिला है जो सभी निगरानी आवश्यकताओं को 100% कवर करेगा, इसलिए हम समय-समय पर इस वातावरण में विभिन्न कस्टम समाधान बनाते हैं।

• Zabbix. अच्छी पुरानी निगरानी, ​​जिसका उद्देश्य मुख्य रूप से बुनियादी ढांचे की समग्र स्थिति पर नज़र रखना है। यह हमें बताता है कि प्रोसेसिंग, मेमोरी, डिस्क, नेटवर्क इत्यादि के संदर्भ में कोई नोड कब मर जाता है। कुछ भी अलौकिक नहीं है, लेकिन हमारे पास एजेंटों का एक अलग डेमॉनसेट भी है, जिसकी मदद से, उदाहरण के लिए, हम क्लस्टर में डीएनएस की स्थिति की निगरानी करते हैं: हम बेवकूफ कोरेडन्स पॉड्स की तलाश करते हैं, हम बाहरी होस्ट की उपलब्धता की जांच करते हैं। ऐसा प्रतीत होता है कि इससे परेशान क्यों हों, लेकिन बड़ी मात्रा में ट्रैफ़िक के साथ यह घटक विफलता का एक गंभीर बिंदु है। मैं पहले से ही बताया गया है, मैंने क्लस्टर में DNS प्रदर्शन के साथ कैसे संघर्ष किया।
• प्रोमेथियस ऑपरेटर. विभिन्न निर्यातकों का एक समूह क्लस्टर के सभी घटकों का एक बड़ा अवलोकन देता है। इसके बाद, हम ग्राफाना में बड़े डैशबोर्ड पर यह सब देखते हैं, और अलर्ट के लिए अलर्टमैनेजर का उपयोग करते हैं।

हमारे लिए एक और उपयोगी उपकरण था सूची-प्रवेश. हमने इसे कई बार ऐसी स्थिति का सामना करने के बाद लिखा है जहां एक टीम ने दूसरी टीम के प्रवेश पथ को ओवरलैप कर दिया था, जिसके परिणामस्वरूप 50x त्रुटियां हुईं। अब उत्पादन में तैनात करने से पहले, डेवलपर्स यह जांचते हैं कि कोई भी प्रभावित नहीं होगा, और मेरी टीम के लिए इनग्रेसेस के साथ समस्याओं के प्रारंभिक निदान के लिए यह एक अच्छा उपकरण है। यह मजेदार है कि पहले तो यह एडमिन के लिए लिखा गया था और यह "अनाड़ी" लग रहा था, लेकिन डेव टीमों को टूल से प्यार होने के बाद, यह बहुत बदल गया और ऐसा नहीं लगने लगा कि "एक एडमिन ने एडमिन के लिए एक वेब फेस बनाया है।" ” जल्द ही हम इस उपकरण को छोड़ देंगे और ऐसी स्थितियों को पाइपलाइन शुरू होने से पहले ही मान्य कर दिया जाएगा।

क्यूब में टीम संसाधन

इससे पहले कि हम उदाहरणों पर गौर करें, यह समझाने लायक है कि हम संसाधनों का आवंटन कैसे करते हैं microservices.

यह समझने के लिए कि कौन सी टीमें और कितनी मात्रा में उनका उपयोग करती हैं ресурсы (प्रोसेसर, मेमोरी, स्थानीय एसएसडी), हम प्रत्येक कमांड को अपना आवंटित करते हैं नाम स्थान "क्यूब" में और प्रोसेसर, मेमोरी और डिस्क के संदर्भ में इसकी अधिकतम क्षमताओं को सीमित करें, पहले टीमों की जरूरतों पर चर्चा की थी। तदनुसार, एक कमांड, सामान्य तौर पर, हजारों कोर और टेराबाइट्स मेमोरी आवंटित करते हुए, तैनाती के लिए पूरे क्लस्टर को ब्लॉक नहीं करेगा। AD के माध्यम से नेमस्पेस तक पहुंच प्रदान की जाती है (हम RBAC का उपयोग करते हैं)। नेमस्पेस और उनकी सीमाएं जीआईटी रिपॉजिटरी में एक पुल अनुरोध के माध्यम से जोड़ी जाती हैं, और फिर सब कुछ स्वचालित रूप से एन्सिबल पाइपलाइन के माध्यम से रोल आउट हो जाता है।

किसी टीम को संसाधन आवंटित करने का एक उदाहरण:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

अनुरोध और सीमाएँ

घनाकार" निवेदन गारंटीशुदा आरक्षित संसाधनों की संख्या है फली (एक या अधिक डॉकटर कंटेनर) एक क्लस्टर में। सीमा एक गैर-गारंटी अधिकतम है. आप अक्सर ग्राफ़ पर देख सकते हैं कि कैसे कुछ टीम ने अपने सभी अनुप्रयोगों के लिए बहुत सारे अनुरोध निर्धारित किए हैं और एप्लिकेशन को "क्यूब" पर तैनात नहीं कर सकते हैं, क्योंकि उनके नामस्थान के तहत सभी अनुरोध पहले ही "खर्च" किए जा चुके हैं।

इस स्थिति से बाहर निकलने का सही तरीका वास्तविक संसाधन खपत को देखना और अनुरोधित राशि (अनुरोध) के साथ तुलना करना है।

ऊपर दिए गए स्क्रीनशॉट में आप देख सकते हैं कि "अनुरोधित" सीपीयू थ्रेड की वास्तविक संख्या से मेल खाते हैं, और सीमाएं सीपीयू थ्रेड की वास्तविक संख्या से अधिक हो सकती हैं =)

आइए अब कुछ नेमस्पेस को विस्तार से देखें (मैंने नेमस्पेस क्यूब-सिस्टम को चुना - "क्यूब" के घटकों के लिए सिस्टम नेमस्पेस) और अनुरोधित प्रोसेसर के लिए वास्तव में उपयोग किए गए प्रोसेसर समय और मेमोरी का अनुपात देखें:

यह स्पष्ट है कि वास्तव में उपयोग की जाने वाली मेमोरी और सीपीयू से कहीं अधिक मेमोरी और सीपीयू सिस्टम सेवाओं के लिए आरक्षित है। क्यूब-सिस्टम के मामले में, यह उचित है: ऐसा हुआ कि nginx इनग्रेस कंट्रोलर या nodelocaldns ने अपने चरम पर सीपीयू को हिट किया और बहुत अधिक रैम की खपत की, इसलिए यहां ऐसा रिजर्व उचित है। इसके अलावा, हम पिछले 3 घंटों के चार्ट पर भरोसा नहीं कर सकते: बड़ी अवधि में ऐतिहासिक मेट्रिक्स देखना वांछनीय है।

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

और यहां वे पॉड्स हैं जिनसे उनकी भूख पर अंकुश लगना चाहिए:

पर थ्रॉटलिंग + संसाधन निगरानी, ​​आप एक से अधिक लेख लिख सकते हैं, इसलिए टिप्पणियों में प्रश्न पूछें। कुछ शब्दों में, मैं कह सकता हूं कि ऐसे मेट्रिक्स को स्वचालित करने का कार्य बहुत कठिन है और इसके लिए बहुत समय और "विंडो" फ़ंक्शंस और "सीटीई" प्रोमेथियस / विक्टोरियामेट्रिक्स के साथ संतुलन की आवश्यकता होती है (ये शब्द उद्धरण चिह्नों में हैं, क्योंकि लगभग है) PromQL में ऐसा कुछ नहीं है, और आपको डरावने प्रश्नों को टेक्स्ट की कई स्क्रीनों में विभाजित करना होगा और उन्हें अनुकूलित करना होगा)।

नतीजतन, डेवलपर्स के पास क्यूब में अपने नेमस्पेस की निगरानी के लिए उपकरण हैं, और वे खुद के लिए चयन करने में सक्षम हैं कि कहां और किस समय कौन से एप्लिकेशन अपने संसाधनों को "कट" कर सकते हैं, और कौन से सर्वर को पूरी रात पूरी सीपीयू दी जा सकती है।

के तरीके

कंपनी में जैसा अभी है फैशनेबल, हम DevOps- और का पालन करते हैं एसआरई-अभ्यासकर्ता जब किसी कंपनी के पास पूरे बुनियादी ढांचे के लिए 1000 माइक्रोसर्विसेज, लगभग 350 डेवलपर्स और 15 एडमिन हों, तो आपको "फैशनेबल बनना" होगा: इन सभी "बेसवर्ड्स" के पीछे हर चीज और हर किसी को स्वचालित करने की तत्काल आवश्यकता है, और एडमिन को बाधा नहीं बनना चाहिए प्रक्रियाओं में.

ऑप्स के रूप में, हम डेवलपर्स के लिए सेवा प्रतिक्रिया दरों और त्रुटियों से संबंधित विभिन्न मैट्रिक्स और डैशबोर्ड प्रदान करते हैं।

हम निम्नलिखित पद्धतियों का उपयोग करते हैं: लाल, उपयोग и सुनहरे संकेतउन्हें एक साथ जोड़कर. हम डैशबोर्ड की संख्या को कम करने का प्रयास करते हैं ताकि एक नज़र में यह स्पष्ट हो कि कौन सी सेवा वर्तमान में खराब हो रही है (उदाहरण के लिए, प्रति सेकंड प्रतिक्रिया कोड, 99 वें प्रतिशत द्वारा प्रतिक्रिया समय), और इसी तरह। जैसे ही सामान्य डैशबोर्ड के लिए कुछ नए मेट्रिक्स आवश्यक हो जाते हैं, हम तुरंत उन्हें बनाते और जोड़ते हैं।

मैंने एक महीने से ग्राफ़ नहीं बनाया है। यह शायद एक अच्छा संकेत है: इसका मतलब है कि अधिकांश "इच्छाएँ" पहले ही पूरी हो चुकी हैं। ऐसा हुआ कि सप्ताह के दौरान मैं दिन में कम से कम एक बार कोई नया ग्राफ़ खींचता।

परिणामी परिणाम मूल्यवान है क्योंकि अब डेवलपर्स शायद ही कभी "किसी प्रकार की मीट्रिक को कहां देखना है" प्रश्न लेकर व्यवस्थापकों के पास जाते हैं।

की शुरूआत सेवा मेश बस आने ही वाला है और इससे हर किसी के लिए जीवन बहुत आसान हो जाएगा, टूल्स के सहकर्मी पहले से ही "स्वस्थ व्यक्ति के इस्तियो" के सार को लागू करने के करीब हैं: प्रत्येक HTTP (एस) अनुरोध का जीवन चक्र निगरानी में दिखाई देगा, और यह अंतर-सेवा (और न केवल) बातचीत के दौरान यह समझना हमेशा संभव होगा कि "किस चरण में सब कुछ टूट गया"। डोमक्लिक हब से समाचार की सदस्यता लें। =)

कुबेरनेट्स बुनियादी ढांचे का समर्थन

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

सभी k8s क्लस्टरों को अद्यतन करने की प्रक्रिया इस प्रकार है:

• लेना क्यूबस्प्रे साउथब्रिज से, हमारे सूत्र, मेरजिम से जांचें।
• हम इसके लिए अपडेट जारी कर रहे हैं तनाव- "घन"।
• हम अपडेट को एक समय में एक नोड में रोल आउट करते हैं (एन्सिबल में यह "सीरियल: 1" है)। देव- "घन"।
• हम अद्यतन करते हैं ठेस शनिवार शाम को एक समय में एक नोड।

भविष्य में इसे बदलने की योजना है क्यूबस्प्रे किसी तेज़ चीज़ के लिए और जाएँ kubeadm.

कुल मिलाकर हमारे पास तीन "क्यूब्स" हैं: तनाव, विकास और उत्पादन। हम एक और लॉन्च करने की योजना बना रहे हैं (गर्म स्टैंडबाय) दूसरे डेटा सेंटर में उत्पाद-“क्यूब”। तनाव и देव "वर्चुअल मशीन" में रहें (तनाव के लिए oVirt और देव के लिए VMWare क्लाउड)। ठेस- "क्यूब" "नंगे धातु" पर रहता है: ये 32 सीपीयू थ्रेड, 64-128 जीबी मेमोरी और 300 जीबी एसएसडी RAID 10 के साथ समान नोड्स हैं - कुल मिलाकर उनमें से 50 हैं। तीन "पतले" नोड "मास्टर्स" को समर्पित हैं ठेस- "क्यूबा": 16 जीबी मेमोरी, 12 सीपीयू थ्रेड।

बिक्री के लिए, हम "नंगे धातु" का उपयोग करना पसंद करते हैं और अनावश्यक परतों से बचते हैं OpenStack: हमें "शोर करने वाले पड़ोसियों" और सीपीयू की आवश्यकता नहीं है समय चुराओ. और इन-हाउस ओपनस्टैक के मामले में प्रशासन की जटिलता लगभग दोगुनी हो जाती है।

सीआई/सीडी "क्यूबिक" और अन्य बुनियादी ढांचे के घटकों के लिए हम एक अलग जीआईटी सर्वर, हेल्म 3 का उपयोग करते हैं (यह हेल्म 2 से काफी दर्दनाक संक्रमण था, लेकिन हम विकल्पों से बहुत खुश हैं परमाणु), जेनकिंस, अन्सिबल और डॉकर। हम एक रिपॉजिटरी से विभिन्न वातावरणों में फीचर शाखाएं और तैनाती पसंद करते हैं।

निष्कर्ष

यह, सामान्य शब्दों में, एक ऑपरेशन इंजीनियर के दृष्टिकोण से डोमक्लिक पर DevOps प्रक्रिया जैसी दिखती है। लेख मेरी अपेक्षा से कम तकनीकी निकला: इसलिए, हैबे पर डोमक्लिक समाचार का अनुसरण करें: कुबेरनेट्स और अन्य के बारे में अधिक "कट्टर" लेख होंगे।

स्रोत: www.habr.com