DomClick येथे Kubernetes: 1000 microservices च्या क्लस्टरचे व्यवस्थापन करून शांतपणे कसे झोपायचे

माझे नाव व्हिक्टर यागोफारोव्ह आहे, आणि मी Ops (ऑपरेशन) टीममध्ये तांत्रिक विकास व्यवस्थापक म्हणून DomClick येथे Kubernetes प्लॅटफॉर्म विकसित करत आहे. मला आमच्या Dev Ops प्रक्रियेची रचना, रशियामधील सर्वात मोठ्या k8s क्लस्टर्सपैकी एक चालवण्याची वैशिष्ट्ये, तसेच आमचा कार्यसंघ लागू असलेल्या DevOps/SRE पद्धतींबद्दल बोलू इच्छितो.

ऑप्स टीम

ऑप्स टीममध्ये सध्या 15 लोक आहेत. त्यापैकी तीन कार्यालयासाठी जबाबदार आहेत, दोन वेगळ्या टाइम झोनमध्ये काम करतात आणि रात्रीसह उपलब्ध आहेत. अशा प्रकारे, Ops मधील कोणीतरी नेहमी मॉनिटरवर असतो आणि कोणत्याही जटिलतेच्या घटनेला प्रतिसाद देण्यासाठी तयार असतो. आमच्याकडे नाईट शिफ्ट नाहीत, जे आमचे मानस टिकवून ठेवते आणि प्रत्येकाला पुरेशी झोप घेण्याची आणि त्यांचा फुरसतीचा वेळ केवळ संगणकावरच घालवण्याची संधी देते.

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

तसे, आम्ही शिकार करतो. उमेदवारांसाठी आवश्यकता अगदी मानक आहेत. माझ्यासाठी वैयक्तिकरित्या, एखादी व्यक्ती संघात बसते, संघर्ष नसलेली असते, परंतु त्याच्या दृष्टिकोनाचे रक्षण कसे करावे हे देखील माहित असते, विकसित करायचे असते आणि काहीतरी नवीन करण्यास घाबरत नाही, त्याच्या कल्पना देतात. तसेच, स्क्रिप्टिंग भाषांमधील प्रोग्रामिंग कौशल्ये, लिनक्स आणि इंग्रजीच्या मूलभूत गोष्टींचे ज्ञान आवश्यक आहे. इंग्रजीची फक्त गरज आहे जेणेकरुन एखादी व्यक्ती फकॅप झाल्यास 10 मिनिटांत नाही तर 10 सेकंदात समस्येचे निराकरण गूगल करू शकेल. लिनक्सचे सखोल ज्ञान असलेले तज्ञ शोधणे आता खूप अवघड आहे: हे मजेदार आहे, परंतु तीनपैकी दोन उमेदवार या प्रश्नाचे उत्तर देऊ शकत नाहीत “लोड सरासरी काय आहे? ते कशापासून बनलेले आहे?", आणि "सी प्रोग्राममधून कोर डंप कसा एकत्र करायचा" हा प्रश्न सुपरमेन... किंवा डायनासोरच्या जगातून काहीतरी मानला जातो. आम्हाला हे सहन करावे लागेल, कारण सामान्यतः लोकांमध्ये इतर कौशल्ये खूप विकसित असतात, परंतु आम्ही लिनक्स शिकवू. “आधुनिक ढगांच्या जगात देवऑप्स अभियंत्याला हे सर्व का माहित असणे आवश्यक आहे” या प्रश्नाचे उत्तर लेखाच्या व्याप्तीच्या बाहेर सोडावे लागेल, परंतु तीन शब्दांत: हे सर्व आवश्यक आहे.

संघ साधने

टूल्स टीम ऑटोमेशनमध्ये महत्त्वपूर्ण भूमिका बजावते. विकासकांसाठी सोयीस्कर ग्राफिकल आणि CLI साधने तयार करणे हे त्यांचे मुख्य कार्य आहे. उदाहरणार्थ, आमची अंतर्गत विकास परिषद तुम्हाला काही माऊस क्लिक्ससह कुबर्नेट्सवर अक्षरशः अनुप्रयोग रोल आउट करण्याची, त्याची संसाधने कॉन्फिगर करण्याची, व्हॉल्टमधील की इ. पूर्वी, जेनकिन्स + हेल्म 2 होते, परंतु मला कॉपी-पेस्ट काढून टाकण्यासाठी आणि सॉफ्टवेअर लाइफसायकलमध्ये एकसमानता आणण्यासाठी माझे स्वतःचे साधन विकसित करावे लागले.

Ops टीम डेव्हलपरसाठी पाइपलाइन लिहित नाही, परंतु त्यांच्या लिखाणातील कोणत्याही समस्येवर सल्ला देऊ शकते (काही लोकांकडे अजूनही हेल्म 3 आहे).

DevOps

DevOps साठी, आम्ही ते असे पाहतो:

डेव्ह टीम कोड लिहितात, कॉन्फर टू dev -> qa/stage -> prod द्वारे रोल आउट करतात. कोडचा वेग कमी होणार नाही आणि त्यात त्रुटी नाहीत याची खात्री करण्याची जबाबदारी Dev आणि Ops संघांची आहे. दिवसाच्या वेळी, ऑप्स टीममधील ड्युटीवर असलेल्या व्यक्तीने सर्वप्रथम त्याच्या अर्जासह एखाद्या घटनेला प्रतिसाद दिला पाहिजे आणि संध्याकाळी आणि रात्री, ड्युटीवर असलेल्या प्रशासकाने (ऑप्स) विकासकाला माहित असल्यास त्याला जागे केले पाहिजे. समस्या पायाभूत सुविधांमध्ये नाही याची खात्री आहे. मॉनिटरिंगमधील सर्व मेट्रिक्स आणि सूचना स्वयंचलितपणे किंवा अर्ध-स्वयंचलितपणे दिसतात.

ऑप्सच्या जबाबदारीचे क्षेत्र अनुप्रयोग उत्पादनात आणल्याच्या क्षणापासून सुरू होते, परंतु देवची जबाबदारी तिथेच संपत नाही - आम्ही तेच करतो आणि त्याच बोटीत आहोत.

विकासकांना प्रशासकांना मायक्रोसर्व्हिस लिहिण्यास मदत हवी असल्यास सल्ला देतात (उदाहरणार्थ, गो बॅकएंड + HTML5), आणि प्रशासक विकासकांना कोणत्याही पायाभूत सुविधा समस्या किंवा k8s शी संबंधित समस्यांवर सल्ला देतात.

तसे, आमच्याकडे अजिबात मोनोलिथ नाही, फक्त मायक्रोसर्व्हिसेस. त्यांची संख्या आत्तापर्यंत prod k900s क्लस्टरमध्ये 1000 आणि 8 च्या दरम्यान चढ-उतार होते, जर संख्येने मोजले तर तैनात. शेंगांची संख्या 1700 आणि 2000 च्या दरम्यान चढ-उतार होते. सध्या उत्पादन क्लस्टरमध्ये सुमारे 2000 शेंगा आहेत.

मी अचूक संख्या देऊ शकत नाही, कारण आम्ही अनावश्यक मायक्रो सर्व्हिसेसचे निरीक्षण करतो आणि त्या अर्ध-स्वयंचलितपणे कापतो. K8s आम्हाला अनावश्यक घटकांचा मागोवा ठेवण्यास मदत करते निरुपयोगी ऑपरेटर, जे भरपूर संसाधने आणि पैशांची बचत करते.

संसाधन व्यवस्थापन

देखरेख

सु-संरचित आणि माहितीपूर्ण देखरेख ही मोठ्या क्लस्टरच्या ऑपरेशनमध्ये आधारशिला बनते. आम्‍हाला अद्याप एक सार्वत्रिक उपाय सापडलेला नाही जो सर्व देखरेखीच्या गरजा पूर्ण करेल 100%, म्हणून आम्ही या वातावरणात वेळोवेळी विविध सानुकूल उपाय तयार करतो.

• झब्बीक्स. चांगले जुने निरीक्षण, जे प्रामुख्याने पायाभूत सुविधांच्या एकूण स्थितीचा मागोवा घेण्यासाठी आहे. प्रक्रिया, मेमरी, डिस्क्स, नेटवर्क इत्यादींच्या बाबतीत नोड कधी मरतो ते आम्हाला सांगते. अलौकिक काहीही नाही, परंतु आमच्याकडे एजंट्सचा एक वेगळा डेमनसेट देखील आहे, ज्याच्या मदतीने, उदाहरणार्थ, आम्ही क्लस्टरमधील DNS च्या स्थितीचे निरीक्षण करतो: आम्ही मूर्ख कॉरेडन्स पॉड्स शोधतो, आम्ही बाह्य होस्टची उपलब्धता तपासतो. असे दिसते की याचा त्रास का होतो, परंतु मोठ्या प्रमाणात रहदारीसह हा घटक अपयशाचा एक गंभीर मुद्दा आहे. मी आधीच वर्णन केले आहे, क्लस्टरमधील DNS कार्यप्रदर्शनाशी मी कसा संघर्ष केला.
• प्रोमिथियस ऑपरेटर. वेगवेगळ्या निर्यातदारांचा संच क्लस्टरच्या सर्व घटकांचा एक मोठा विहंगावलोकन देतो. पुढे, आम्ही हे सर्व ग्राफना मधील मोठ्या डॅशबोर्डवर दृश्यमान करतो आणि अलर्टसाठी अॅलर्ट मॅनेजर वापरतो.

आमच्यासाठी आणखी एक उपयुक्त साधन होते यादीत प्रवेश. एका संघाने दुसर्‍या संघाच्या प्रवेशाचे मार्ग ओव्हरलॅप केल्यावर 50x चुका झाल्या. आता उत्पादनासाठी तैनात करण्यापूर्वी, विकासक तपासतात की कोणावरही परिणाम होणार नाही आणि माझ्या कार्यसंघासाठी हे इंग्रेसेसच्या समस्यांचे प्रारंभिक निदान करण्यासाठी एक चांगले साधन आहे. हे मजेदार आहे की सुरुवातीला ते प्रशासकांसाठी लिहिले गेले होते आणि ते "अनाडी" दिसले, परंतु डेव्ह टीम्स टूलच्या प्रेमात पडल्यानंतर, ते बरेच बदलले आणि "एडमिनने प्रशासकांसाठी वेब चेहरा बनवला" असे दिसू लागले. " लवकरच आम्ही या साधनाचा त्याग करू आणि पाइपलाइन आणण्यापूर्वीच अशा परिस्थितीचे प्रमाणीकरण केले जाईल.

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

आम्ही उदाहरणांमध्ये जाण्यापूर्वी, आम्ही संसाधनांचे वाटप कसे करतो हे स्पष्ट करणे योग्य आहे सूक्ष्म सेवा.

कोणते संघ आणि कोणत्या प्रमाणात त्यांचा वापर करतात हे समजून घेण्यासाठी संसाधने (प्रोसेसर, मेमरी, स्थानिक SSD), आम्ही प्रत्येक कमांड स्वतःचे वाटप करतो नेमस्पेस "क्यूब" मध्ये आणि प्रोसेसर, मेमरी आणि डिस्कच्या बाबतीत त्याची कमाल क्षमता मर्यादित करा, यापूर्वी संघांच्या गरजा चर्चा केल्या होत्या. त्यानुसार, एक कमांड, सर्वसाधारणपणे, तैनातीसाठी संपूर्ण क्लस्टर अवरोधित करणार नाही, हजारो कोर आणि टेराबाइट मेमरी वाटप करेल. नेमस्पेसमध्ये प्रवेश AD द्वारे दिला जातो (आम्ही RBAC वापरतो). नेमस्पेसेस आणि त्यांची मर्यादा जीआयटी रेपॉजिटरीमध्ये पुल विनंतीद्वारे जोडली जाते आणि नंतर सर्व काही आपोआप उत्तरदायी पाइपलाइनद्वारे आणले जाते.

संघाला संसाधने वाटप करण्याचे उदाहरण:

namespaces:

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

विनंत्या आणि मर्यादा

घन" विनंती साठी हमी आरक्षित संसाधनांची संख्या आहे पॉड (एक किंवा अधिक डॉकर कंटेनर) क्लस्टरमध्ये. मर्यादा ही हमी नसलेली कमाल आहे. आपण अनेकदा आलेखांवर पाहू शकता की काही संघाने त्याच्या सर्व अनुप्रयोगांसाठी स्वतःला किती विनंत्या सेट केल्या आहेत आणि ते अनुप्रयोग “क्यूब” वर तैनात करू शकत नाहीत, कारण त्यांच्या नेमस्पेस अंतर्गत सर्व विनंत्या आधीच “खर्च” केल्या गेल्या आहेत.

या परिस्थितीतून बाहेर पडण्याचा योग्य मार्ग म्हणजे संसाधनाचा वास्तविक वापर पाहणे आणि विनंती केलेल्या रकमेशी (विनंती) तुलना करणे.

वरील स्क्रीनशॉटमध्ये तुम्ही पाहू शकता की "विनंती केलेले" CPU थ्रेडच्या वास्तविक संख्येशी जुळले आहेत आणि मर्यादा सीपीयू थ्रेडच्या वास्तविक संख्येपेक्षा जास्त असू शकतात =)

आता काही नेमस्पेस तपशीलवार पाहू या (मी नेमस्पेस क्यूब-सिस्टम निवडले - "क्यूब" च्या घटकांसाठी सिस्टम नेमस्पेस) आणि विनंती केलेल्या प्रोसेसरचा वेळ आणि मेमरी यांचा प्रत्यक्षात वापरलेल्या गुणोत्तर पाहू:

हे स्पष्ट आहे की प्रत्यक्षात वापरल्या गेलेल्यापेक्षा कितीतरी जास्त मेमरी आणि CPU सिस्टम सेवांसाठी आरक्षित आहे. कुबे-सिस्टमच्या बाबतीत, हे न्याय्य आहे: असे घडले की nginx एंग्रेस कंट्रोलर किंवा nodelocaldns त्यांच्या शिखरावर CPU ला धडकले आणि भरपूर RAM खाल्ली, म्हणून येथे असे राखीव न्याय्य आहे. याव्यतिरिक्त, आम्ही शेवटच्या 3 तासांसाठी चार्टवर अवलंबून राहू शकत नाही: मोठ्या कालावधीत ऐतिहासिक मेट्रिक्स पाहणे इष्ट आहे.

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

आणि येथे अशा शेंगा आहेत ज्यांनी त्यांची भूक कमी केली पाहिजे:

वर थ्रॉटलिंग + संसाधन निरीक्षण, आपण एकापेक्षा जास्त लेख लिहू शकता, म्हणून टिप्पण्यांमध्ये प्रश्न विचारा. काही शब्दांत, मी असे म्हणू शकतो की अशा मेट्रिक्सचे स्वयंचलित करण्याचे कार्य खूप कठीण आहे आणि "विंडो" फंक्शन्स आणि "सीटीई" प्रोमिथियस / व्हिक्टोरियामेट्रिक्ससह बराच वेळ आणि संतुलित कृती आवश्यक आहे (या अटी अवतरणात आहेत, कारण जवळजवळ PromQL मध्ये असे काहीही नाही आणि तुम्हाला भयानक प्रश्नांना मजकूराच्या अनेक स्क्रीनमध्ये विभाजित करावे लागेल आणि त्यांना ऑप्टिमाइझ करावे लागेल).

परिणामी, डेव्हलपर्सकडे क्यूबमध्ये त्यांच्या नेमस्पेसेसचे निरीक्षण करण्यासाठी साधने आहेत आणि ते स्वत:साठी कोठे आणि कोणत्या वेळी कोणते ऍप्लिकेशन त्यांचे संसाधन "कट" करू शकतात आणि कोणत्या सर्व्हरला संपूर्ण CPU रात्रभर देऊ शकतात हे निवडण्यास सक्षम आहेत.

पद्धती

कंपनीत जसे आता आहे फॅशनेबल, आम्ही DevOps- आणि एसआरई- अभ्यासक जेव्हा एखाद्या कंपनीकडे 1000 मायक्रो सर्व्हिसेस, सुमारे 350 डेव्हलपर आणि संपूर्ण पायाभूत सुविधांसाठी 15 प्रशासक असतात, तेव्हा तुम्हाला "फॅशनेबल" असणे आवश्यक आहे: या सर्व "बसवर्ड्स" च्या मागे सर्व काही आणि प्रत्येकाला स्वयंचलित करण्याची तातडीची आवश्यकता आहे आणि प्रशासकांनी अडथळे नसावेत. प्रक्रियांमध्ये.

Ops म्हणून, आम्ही सेवा प्रतिसाद दर आणि त्रुटींशी संबंधित विकासकांसाठी विविध मेट्रिक्स आणि डॅशबोर्ड प्रदान करतो.

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

मी महिनाभर आलेख काढले नाहीत. हे कदाचित एक चांगले चिन्ह आहे: याचा अर्थ बहुतेक "इच्छा" आधीच लक्षात आल्या आहेत. असे झाले की आठवड्यातून मी दिवसातून एकदा तरी नवीन आलेख काढेन.

परिणामी परिणाम मौल्यवान आहे कारण आता विकसक फारच क्वचितच प्रश्नांसह प्रशासकांकडे जातात "कोणत्या प्रकारचे मेट्रिक कुठे पहावे."

अंमलबजावणी सेवा जाळी अगदी कोपऱ्याच्या आसपास आहे आणि प्रत्येकासाठी जीवन खूप सोपे बनवायला हवे, टूल्सचे सहकारी आधीच “स्वस्थ व्यक्तीचे इष्टिओ” हे गोषवारा अंमलात आणण्याच्या जवळ आहेत: प्रत्येक HTTP(s) विनंतीचे जीवन चक्र निरीक्षणामध्ये दृश्यमान असेल, आणि आंतर-सेवा (आणि केवळ नाही) परस्परसंवाद दरम्यान "सर्व काही कोणत्या टप्प्यावर तुटले" हे समजून घेणे नेहमीच शक्य होईल. DomClick हबवरील बातम्यांची सदस्यता घ्या. =)

Kubernetes पायाभूत सुविधा समर्थन

ऐतिहासिकदृष्ट्या, आम्ही पॅच केलेली आवृत्ती वापरतो कुबेस्प्रे — Kubernetes तैनात करणे, विस्तारित करणे आणि अद्यतनित करणे यासाठी उत्तरदायी भूमिका. काही क्षणी, मुख्य शाखेतून नॉन-कुबीएडएम इंस्टॉलेशन्ससाठी समर्थन कापले गेले होते, आणि कुबीएडएमवर स्विच करण्याची प्रक्रिया प्रस्तावित नव्हती. परिणामी, साउथब्रिज कंपनीने स्वतःचा काटा तयार केला (कुबीएडएम समर्थनासह आणि गंभीर समस्यांसाठी त्वरित निराकरण).

सर्व k8s क्लस्टर्स अपडेट करण्याची प्रक्रिया अशी दिसते:

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

भविष्यात ते बदलण्याची योजना आहे कुबेस्प्रे काहीतरी जलद आणि जा kubeadm.

एकूण आमच्याकडे तीन “क्यूब्स” आहेत: ताण, देव आणि उत्पादन. आम्ही आणखी एक लॉन्च करण्याचा विचार करत आहोत (हॉट स्टँडबाय) दुसऱ्या डेटा सेंटरमध्ये उत्पादन-“क्यूब”. ताण и देव “व्हर्च्युअल मशीन” मध्ये राहतात (तणावांसाठी oVirt आणि Dev साठी VMWare क्लाउड). उत्पादन- "क्यूब" "बेअर मेटल" वर राहतात: हे 32 CPU थ्रेड्स, 64-128 GB मेमरी आणि 300 GB SSD RAID 10 असलेले एकसारखे नोड आहेत - त्यापैकी एकूण 50 आहेत. तीन "पातळ" नोड्स "मास्टर्स" ला समर्पित आहेत उत्पादन- “क्युबा”: 16 GB मेमरी, 12 CPU थ्रेड्स.

विक्रीसाठी, आम्ही "बेअर मेटल" वापरण्यास प्राधान्य देतो आणि अनावश्यक स्तर टाळतो ओपनस्टॅक: आम्हाला "गोंगाट करणारे शेजारी" आणि CPU ची गरज नाही वेळ चोरणे. आणि इन-हाऊस ओपनस्टॅकच्या बाबतीत प्रशासनाची जटिलता अंदाजे दुप्पट होते.

CI/CD “क्युबिक” आणि इतर पायाभूत सुविधा घटकांसाठी आम्ही स्वतंत्र GIT सर्व्हर, हेल्म 3 वापरतो (हेल्म 2 वरून हे एक अतिशय वेदनादायक संक्रमण होते, परंतु आम्ही पर्यायांसह खूप आनंदी आहोत. अणू), जेनकिन्स, उत्तरदायी आणि डॉकर. आम्हाला वैशिष्ट्य शाखा आणि एका भांडारातून वेगवेगळ्या वातावरणात तैनात करणे आवडते.

निष्कर्ष

ऑपरेशन अभियंत्याच्या दृष्टीकोनातून DomClick वर DevOps प्रक्रिया कशी दिसते हे सर्वसाधारण शब्दात आहे. लेख माझ्या अपेक्षेपेक्षा कमी तांत्रिक असल्याचे दिसून आले: म्हणून, Habré वरील DomClick बातम्यांचे अनुसरण करा: Kubernetes आणि बरेच काही बद्दल अधिक "हार्डकोर" लेख असतील.

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