GitLab.com ला Kubernetes मध्ये स्थलांतरित केल्याच्या एका वर्षातील आमचे निष्कर्ष

नोंद. अनुवाद: GitLab मध्ये Kubernetes दत्तक घेणे हे कंपनीच्या वाढीस हातभार लावणाऱ्या दोन मुख्य घटकांपैकी एक मानले जाते. तथापि, अलीकडे पर्यंत, GitLab.com ऑनलाइन सेवेची पायाभूत सुविधा व्हर्च्युअल मशीनवर तयार केली गेली होती, आणि फक्त एक वर्षापूर्वी त्याचे K8s मध्ये स्थलांतर सुरू झाले, जे अद्याप पूर्ण झाले नाही. हे कसे घडते आणि प्रकल्पात भाग घेणारे अभियंते काय निष्कर्ष काढतात याबद्दल GitLab SRE अभियंत्याच्या अलीकडील लेखाचा अनुवाद सादर करताना आम्हाला आनंद होत आहे.

आता सुमारे एक वर्षापासून, आमचा पायाभूत सुविधा विभाग GitLab.com वर चालणाऱ्या सर्व सेवा Kubernetes वर स्थलांतरित करत आहे. या वेळी, आम्हाला केवळ कुबर्नेट्समध्ये सेवा हलवण्याशी संबंधित आव्हाने आली नाहीत तर संक्रमणादरम्यान संकरित तैनाती व्यवस्थापित करण्यासाठी देखील. आपण शिकलेल्या मौल्यवान धड्यांबद्दल या लेखात चर्चा केली जाईल.

GitLab.com च्या अगदी सुरुवातीपासूनच, त्याचे सर्व्हर व्हर्च्युअल मशीनवर क्लाउडमध्ये चालू होते. या आभासी मशीन्स शेफद्वारे व्यवस्थापित केल्या जातात आणि आमच्या वापरून स्थापित केल्या जातात अधिकृत लिनक्स पॅकेज. उपयोजन धोरण अनुप्रयोग अद्यतनित करणे आवश्यक असल्यास, CI पाइपलाइन वापरून समन्वित, अनुक्रमिक पद्धतीने सर्व्हर फ्लीट अद्यतनित करणे समाविष्ट आहे. ही पद्धत - मंद आणि थोडे जरी कंटाळवाणा - GitLab.com ऑफलाइन वापरकर्त्यांप्रमाणेच स्थापना आणि कॉन्फिगरेशन पद्धती वापरते याची खात्री करते (स्वयं-व्यवस्थापित) यासाठी आमचे लिनक्स पॅकेजेस वापरून GitLab इंस्टॉलेशन.

आम्ही ही पद्धत वापरतो कारण GitLab च्या त्यांच्या प्रती स्थापित आणि कॉन्फिगर करताना समाजातील सामान्य सदस्यांनी अनुभवलेल्या सर्व दुःखांचा आणि आनंदांचा अनुभव घेणे अत्यंत महत्वाचे आहे. या दृष्टिकोनाने काही काळ चांगले काम केले, परंतु जेव्हा GitLab वरील प्रकल्पांची संख्या 10 दशलक्ष ओलांडली, तेव्हा आम्हाला समजले की ते यापुढे स्केलिंग आणि उपयोजनासाठी आमच्या गरजा पूर्ण करत नाहीत.

Kubernetes आणि क्लाउड-नेटिव्ह GitLab ची पहिली पायरी

हा प्रकल्प 2017 मध्ये तयार करण्यात आला होता GitLab चार्ट क्लाउड डिप्लॉयमेंटसाठी GitLab तयार करण्यासाठी आणि वापरकर्त्यांना Kubernetes क्लस्टरवर GitLab इंस्टॉल करण्यास सक्षम करण्यासाठी. तेव्हा आम्हाला माहित होते की GitLab ला Kubernetes वर हलवल्याने SaaS प्लॅटफॉर्मची स्केलेबिलिटी वाढेल, उपयोजन सुलभ होतील आणि संगणकीय संसाधनांची कार्यक्षमता सुधारेल. त्याच वेळी, आमच्या ऍप्लिकेशनची अनेक फंक्शन्स माउंट केलेल्या NFS विभाजनांवर अवलंबून होती, ज्यामुळे व्हर्च्युअल मशीनमधून संक्रमण कमी होते.

क्लाउड नेटिव्ह आणि कुबर्नेट्सच्या दिशेने केलेल्या धक्क्याने आमच्या अभियंत्यांना हळूहळू संक्रमणाची योजना करण्याची अनुमती दिली, ज्या दरम्यान आम्ही नवीन वैशिष्ट्ये विकसित करणे सुरू ठेवत नेटवर्क स्टोरेजवरील काही अनुप्रयोगांचे अवलंबित्व सोडून दिले. आम्ही 2019 च्या उन्हाळ्यात स्थलांतराची योजना सुरू केल्यापासून, यापैकी बर्‍याच मर्यादांचे निराकरण केले गेले आहे आणि GitLab.com ला Kubernetes मध्ये स्थलांतरित करण्याची प्रक्रिया आता चांगली सुरू आहे!

Kubernetes मध्ये GitLab.com ची वैशिष्ट्ये

GitLab.com साठी, आम्ही एकल प्रादेशिक GKE क्लस्टर वापरतो जो सर्व अॅप्लिकेशन ट्रॅफिक हाताळतो. (आधीपासूनच अवघड) स्थलांतराची जटिलता कमी करण्यासाठी, आम्ही स्थानिक स्टोरेज किंवा NFS वर अवलंबून नसलेल्या सेवांवर लक्ष केंद्रित करतो. GitLab.com मुख्यत: मोनोलिथिक रेल कोडबेस वापरते आणि आम्ही वर्कलोड वैशिष्ट्यांवर आधारित रहदारीला त्यांच्या स्वतःच्या नोड पूलमध्ये विलग केलेल्या वेगवेगळ्या एंडपॉइंट्सकडे मार्गस्थ करतो.

फ्रंटएंडच्या बाबतीत, हे प्रकार वेब, API, Git SSH/HTTPS आणि रजिस्ट्रीच्या विनंतीमध्ये विभागले गेले आहेत. बॅकएंडच्या बाबतीत, आम्ही विविध वैशिष्ट्यांनुसार रांगेतील नोकर्या विभाजित करतो पूर्वनिर्धारित संसाधन सीमा, जे आम्हाला विविध वर्कलोड्ससाठी सेवा-स्तरीय उद्दिष्टे (SLO) सेट करण्याची परवानगी देतात.

या सर्व GitLab.com सेवा बदल न केलेला GitLab हेल्म चार्ट वापरून कॉन्फिगर केल्या आहेत. कॉन्फिगरेशन सबचार्टमध्ये केले जाते, जे आम्ही हळूहळू क्लस्टरमध्ये सेवा स्थलांतरित करत असताना निवडकपणे सक्षम केले जाऊ शकते. Redis, Postgres, GitLab Pages आणि Gitaly यांसारख्या स्थलांतरामध्ये आम्ही आमच्या काही स्टेटफुल सेवा समाविष्ट न करण्याचा निर्णय घेतला असला तरीही, Kubernetes वापरल्याने आम्हाला शेफ सध्या व्यवस्थापित करत असलेल्या VM ची संख्या आमूलाग्रपणे कमी करू देते.

Kubernetes कॉन्फिगरेशन दृश्यमानता आणि व्यवस्थापन

सर्व सेटिंग्ज GitLab द्वारेच व्यवस्थापित केल्या जातात. यासाठी टेराफॉर्म आणि हेल्मवर आधारित तीन कॉन्फिगरेशन प्रकल्प वापरले जातात. जेव्हा शक्य असेल तेव्हा GitLab चालवण्यासाठी आम्ही GitLab चा वापर करण्याचा प्रयत्न करतो, परंतु ऑपरेशनल कामांसाठी आमच्याकडे स्वतंत्र GitLab इंस्टॉलेशन आहे. GitLab.com उपयोजन आणि अद्यतने करत असताना तुम्ही GitLab.com च्या उपलब्धतेवर अवलंबून नसल्याची खात्री करण्यासाठी हे आवश्यक आहे.

Kubernetes क्लस्टरसाठी आमच्या पाइपलाइन वेगळ्या GitLab इंस्टॉलेशनवर चालत असल्या तरी, कोड रिपॉझिटरीजचे मिरर आहेत जे खालील पत्त्यांवर सार्वजनिकपणे उपलब्ध आहेत:

• k8s-workloads/gitlab-com — GitLab हेल्म चार्टसाठी GitLab.com कॉन्फिगरेशन फ्रेमवर्क;
• k8s-workloads/gitlab-helmfiles - GitLab अनुप्रयोगाशी थेट संबंधित नसलेल्या सेवांसाठी कॉन्फिगरेशन समाविष्ट आहे. यामध्ये लॉगिंग आणि क्लस्टर मॉनिटरिंगसाठी कॉन्फिगरेशन, तसेच प्लांटयूएमएल सारख्या एकात्मिक साधनांचा समावेश आहे;
• गिटलॅब-कॉम-इन्फ्रास्ट्रक्चर — Kubernetes आणि लेगसी VM पायाभूत सुविधांसाठी टेराफॉर्म कॉन्फिगरेशन. येथे तुम्ही क्लस्टर चालविण्यासाठी आवश्यक असलेली सर्व संसाधने कॉन्फिगर करता, ज्यामध्ये क्लस्टर स्वतः, नोड पूल, सेवा खाती आणि IP पत्ता आरक्षण समाविष्ट आहे.

बदल केल्यावर सार्वजनिक दृश्य दाखवले जाते. संक्षिप्त सारांश क्लस्टरमध्ये बदल करण्यापूर्वी SRE विश्लेषण केलेल्या तपशीलवार फरकाच्या लिंकसह.

SRE साठी, लिंक GitLab इंस्टॉलेशनमध्ये तपशीलवार फरक दर्शवते, जी उत्पादनासाठी वापरली जाते आणि ज्यावर प्रवेश प्रतिबंधित आहे. हे कर्मचारी आणि समुदायाला, ऑपरेशनल प्रोजेक्टमध्ये प्रवेश न करता (जे फक्त SREs साठी खुले आहे) प्रस्तावित कॉन्फिगरेशन बदल पाहण्याची परवानगी देते. CI पाइपलाइनसाठी खाजगी उदाहरणासह कोडसाठी सार्वजनिक GitLab उदाहरण एकत्र करून, कॉन्फिगरेशन अद्यतनांसाठी GitLab.com वरून स्वातंत्र्य सुनिश्चित करताना आम्ही एकच कार्यप्रवाह राखतो.

स्थलांतरादरम्यान आम्हाला काय कळले

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

1. उपलब्धता क्षेत्रांमधील रहदारीमुळे वाढलेला खर्च

GitLab.com वर Git रिपॉझिटरी फ्लीटसाठी दैनिक निर्गमन आकडेवारी (दररोज बाइट्स)

Google त्याचे नेटवर्क प्रदेशांमध्ये विभाजित करते. त्या बदल्यात, प्रवेशयोग्यता झोन (AZ) मध्ये विभागल्या जातात. Git होस्टिंग मोठ्या प्रमाणात डेटाशी संबंधित आहे, त्यामुळे नेटवर्क बाहेर पडणे नियंत्रित करणे आमच्यासाठी महत्त्वाचे आहे. अंतर्गत रहदारीसाठी, त्याच उपलब्धता झोनमध्ये राहिल्यासच बाहेर पडणे विनामूल्य आहे. या लेखनापर्यंत, आम्ही साधारण कामाच्या दिवसात अंदाजे 100 TB डेटा देत आहोत (आणि ते फक्त Git रिपॉझिटरीजसाठी आहे). आमच्या जुन्या VM-आधारित टोपोलॉजीमध्ये समान आभासी मशीनमध्ये राहणाऱ्या सेवा आता वेगवेगळ्या Kubernetes पॉडमध्ये चालतात. याचा अर्थ असा की काही रहदारी जी पूर्वी VM साठी स्थानिक होती ती संभाव्यत: उपलब्धता क्षेत्राबाहेर प्रवास करू शकते.

प्रादेशिक GKE क्लस्टर्स तुम्हाला रिडंडंसीसाठी अनेक उपलब्धता झोन वाढवण्याची परवानगी देतात. आम्ही शक्यता विचारात घेत आहोत प्रादेशिक GKE क्लस्टरला सिंगल-झोन क्लस्टरमध्ये विभाजित करा मोठ्या प्रमाणात रहदारी निर्माण करणाऱ्या सेवांसाठी. हे क्लस्टर-स्तरीय रिडंडन्सी कायम ठेवताना बाहेर पडण्याचा खर्च कमी करेल.

2. मर्यादा, संसाधन विनंत्या आणि स्केलिंग

registry.gitlab.com वर उत्पादन ट्रॅफिकवर प्रक्रिया करणाऱ्या प्रतिकृतींची संख्या. रहदारी ~15:00 UTC वर पोहोचते.

आमची स्थलांतर कथा ऑगस्ट 2019 मध्ये सुरू झाली, जेव्हा आम्ही आमची पहिली सेवा, GitLab कंटेनर रजिस्ट्री, Kubernetes मध्ये स्थलांतरित केली. ही मिशन-गंभीर, उच्च-वाहतूक सेवा ही पहिल्या स्थलांतरासाठी चांगली निवड होती कारण ती काही बाह्य अवलंबनांसह एक स्टेटलेस ऍप्लिकेशन आहे. नोड्सवर मेमरी नसल्यामुळे मोठ्या संख्येने बेदखल केलेल्या पॉड्सची आम्हाला पहिली समस्या आली. यामुळे, आम्हाला विनंत्या आणि मर्यादा बदलाव्या लागल्या.

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

3. मेट्रिक्स आणि लॉग

इन्फ्रास्ट्रक्चर डिव्हिजन लेटन्सी, एरर रेट आणि इन्स्टॉल केलेले संपृक्तता यावर लक्ष केंद्रित करते सेवा पातळी उद्दिष्टे (SLO) शी जोडलेले आहे आमच्या सिस्टमची सामान्य उपलब्धता.

गेल्या वर्षभरात, पायाभूत सुविधा विभागातील महत्त्वाच्या घटनांपैकी एक म्हणजे SLOs सोबत निरीक्षण आणि काम करण्यात सुधारणा. SLO ने आम्हाला वैयक्तिक सेवांसाठी लक्ष्य सेट करण्याची परवानगी दिली ज्यांचे आम्ही स्थलांतर दरम्यान बारकाईने निरीक्षण केले. परंतु या सुधारित निरीक्षणक्षमतेसह, मेट्रिक्स आणि अलर्ट वापरून समस्या त्वरित पाहणे नेहमीच शक्य नसते. उदाहरणार्थ, विलंबता आणि त्रुटी दरांवर लक्ष केंद्रित करून, आम्ही स्थलांतर करत असलेल्या सेवेसाठी सर्व वापर प्रकरणे पूर्णपणे कव्हर करत नाही.

काही वर्कलोड्स क्लस्टरमध्ये स्थलांतरित केल्यावर ही समस्या जवळजवळ लगेचच आढळली. हे विशेषतः तीव्र झाले जेव्हा आम्हाला अशी कार्ये तपासायची होती ज्यासाठी विनंत्यांची संख्या कमी होती, परंतु ज्यात विशिष्ट कॉन्फिगरेशन अवलंबित्व होते. स्थलांतरातील मुख्य धड्यांपैकी एक म्हणजे निरीक्षण करताना केवळ मेट्रिक्सच नव्हे तर लॉग आणि "लांब शेपटी" देखील विचारात घेण्याची गरज होती. (हे याबद्दल आहे असे त्यांचे वितरण चार्टवर - अंदाजे. अनुवाद.) चुका आता प्रत्येक स्थलांतरासाठी आम्ही लॉग क्वेरीची तपशीलवार यादी समाविष्ट करतो (लॉग क्वेरी) आणि स्पष्ट रोलबॅक प्रक्रियेची योजना करा ज्या समस्या उद्भवल्यास एका शिफ्टमधून दुसऱ्या शिफ्टमध्ये हस्तांतरित केल्या जाऊ शकतात.

जुन्या VM इन्फ्रास्ट्रक्चर आणि नवीन Kubernetes-आधारित पायाभूत सुविधांवर समांतरपणे समान विनंत्या पूर्ण करणे हे एक अद्वितीय आव्हान आहे. लिफ्ट-आणि-शिफ्ट स्थलांतराच्या विपरीत (नवीन पायाभूत सुविधांमध्ये "जसे आहे तसे" अनुप्रयोगांचे द्रुत हस्तांतरण; अधिक तपशील वाचले जाऊ शकतात, उदाहरणार्थ, येथे - अंदाजे अनुवाद.), "जुन्या" VMs आणि Kubernetes वरील समांतर कार्यासाठी निरीक्षण साधने दोन्ही वातावरणाशी सुसंगत असणे आवश्यक आहे आणि मेट्रिक्स एका दृश्यात एकत्र करण्यास सक्षम असणे आवश्यक आहे. संक्रमण कालावधी दरम्यान सातत्यपूर्ण निरीक्षणक्षमता प्राप्त करण्यासाठी आम्ही समान डॅशबोर्ड आणि लॉग क्वेरी वापरणे महत्वाचे आहे.

4. नवीन क्लस्टरवर रहदारी स्विच करणे

GitLab.com साठी, सर्व्हरचा भाग समर्पित आहे कॅनरी स्टेज. कॅनरी पार्क आमच्या अंतर्गत प्रकल्पांना सेवा देतो आणि करू शकतो वापरकर्त्यांनी सक्षम केले. परंतु हे प्रामुख्याने पायाभूत सुविधा आणि अनुप्रयोगामध्ये केलेले बदल तपासण्यासाठी डिझाइन केलेले आहे. प्रथम स्थलांतरित सेवा मर्यादित प्रमाणात अंतर्गत रहदारी स्वीकारून सुरू झाली आणि सर्व ट्रॅफिक क्लस्टरला पाठवण्यापूर्वी SLO पूर्ण झाल्याची खात्री करण्यासाठी आम्ही ही पद्धत वापरत आहोत.

स्थलांतराच्या बाबतीत, याचा अर्थ असा होतो की अंतर्गत प्रकल्पांच्या विनंत्या प्रथम कुबर्नेट्सला पाठवल्या जातात आणि नंतर आम्ही हळूहळू HAProxy द्वारे बॅकएंडसाठी वजन बदलून उर्वरित रहदारी क्लस्टरवर स्विच करतो. VM ते Kubernetes मधील स्थलांतरादरम्यान, हे स्पष्ट झाले की जुन्या आणि नवीन पायाभूत सुविधांमधील रहदारी पुनर्निर्देशित करण्याचा एक सोपा मार्ग असणे आणि त्यानुसार, स्थलांतरानंतर पहिल्या काही दिवसांत जुन्या पायाभूत सुविधा रोलबॅकसाठी तयार ठेवणे खूप फायदेशीर आहे.

5. शेंगांची राखीव क्षमता आणि त्यांचा वापर

जवळजवळ लगेचच खालील समस्या ओळखल्या गेल्या: नोंदणी सेवेसाठी पॉड्स त्वरीत सुरू झाले, परंतु Sidekiq साठी पॉड्स लाँच करण्यास सुमारे दोन मिनिटे. Sidekiq पॉड्ससाठी प्रदीर्घ स्टार्टअप वेळ ही समस्या बनली जेव्हा आम्ही कामाचा भार त्वरीत आणि त्वरीत स्केल करण्यासाठी आवश्यक असलेल्या कामगारांसाठी कुबर्नेट्समध्ये स्थलांतरित करू लागलो.

या प्रकरणात, धडा असा होता की कुबर्नेट्सचा क्षैतिज पॉड ऑटोस्केलर (HPA) वाहतूक वाढ चांगल्या प्रकारे हाताळतो, परंतु वर्कलोडची वैशिष्ट्ये विचारात घेणे आणि पॉड्ससाठी अतिरिक्त क्षमता वाटप करणे महत्वाचे आहे (विशेषतः जेव्हा मागणी असमानपणे वितरित केली जाते). आमच्या बाबतीत, नोकऱ्यांमध्ये अचानक वाढ झाली होती, ज्यामुळे जलद स्केलिंग होते, ज्यामुळे आम्हाला नोड पूल मोजण्यासाठी वेळ मिळण्यापूर्वी CPU संसाधनांचे संपृक्तता होते.

क्लस्टरमधून शक्य तितके पिळून काढण्याचा मोह नेहमीच असतो, परंतु सुरुवातीला कार्यप्रदर्शन समस्या आल्याने, आम्ही आता उदार पॉड बजेटसह सुरुवात करत आहोत आणि नंतर ते कमी करत आहोत, SLO वर बारीक लक्ष ठेवून आहोत. Sidekiq सेवेसाठी पॉड्स लाँच करणे लक्षणीयरीत्या वेगवान झाले आहे आणि आता सरासरी 40 सेकंद लागतात. शेंगा लाँच वेळ कमी पासून GitLab.com आणि अधिकृत GitLab हेल्म चार्टसह काम करणार्‍या स्वयं-व्यवस्थापित इंस्टॉलेशनचे आमचे वापरकर्ते दोन्ही जिंकले.

निष्कर्ष

प्रत्येक सेवेचे स्थलांतर केल्यानंतर, उत्पादनामध्ये Kubernetes वापरण्याचे फायदे पाहून आम्हाला आनंद झाला: जलद आणि सुरक्षित अनुप्रयोग उपयोजन, स्केलिंग आणि अधिक कार्यक्षम संसाधन वाटप. शिवाय, स्थलांतराचे फायदे GitLab.com सेवेच्या पलीकडे जातात. अधिकृत हेल्म चार्टमधील प्रत्येक सुधारणा त्याच्या वापरकर्त्यांना फायदेशीर ठरते.

मला आशा आहे की तुम्ही आमच्या Kubernetes स्थलांतर साहसांच्या कथेचा आनंद घेतला असेल. आम्ही सर्व नवीन सेवा क्लस्टरमध्ये स्थलांतरित करणे सुरू ठेवतो. अतिरिक्त माहिती खालील प्रकाशनांमध्ये आढळू शकते:

• «आम्ही कुबर्नेट्समध्ये स्थलांतर का करत आहोत?";
• «Kubernetes वर GitLab.com";
• GitLab.com ला Kubernetes वर स्थलांतरित करण्यावरील महाकाव्य.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्ससह उत्पादनात 3 वर्षे: आम्हाला काय समजले ते येथे आहे";
• «Kubernetes वापरताना 10 सामान्य चुका";
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 3: GitHub";
• «टिंडरचे कुबर्नेट्समध्ये संक्रमण».

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