GitLab.com को Kubernetes पर स्थानांतरित करने के एक वर्ष के दौरान हमारे निष्कर्ष

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

अब लगभग एक साल से, हमारा इन्फ्रास्ट्रक्चर डिवीजन GitLab.com पर चल रही सभी सेवाओं को कुबेरनेट्स पर स्थानांतरित कर रहा है। इस दौरान, हमें न केवल कुबेरनेट्स में सेवाओं को स्थानांतरित करने से संबंधित चुनौतियों का सामना करना पड़ा, बल्कि संक्रमण के दौरान हाइब्रिड तैनाती के प्रबंधन से भी संबंधित चुनौतियों का सामना करना पड़ा। हमने जो मूल्यवान सबक सीखे, उनकी चर्चा इस लेख में की जाएगी।

GitLab.com की शुरुआत से ही, इसके सर्वर वर्चुअल मशीनों पर क्लाउड में चलते थे। इन वर्चुअल मशीनों को शेफ द्वारा प्रबंधित किया जाता है और हमारे द्वारा स्थापित किया जाता है आधिकारिक लिनक्स पैकेज. परिनियोजन रणनीति यदि एप्लिकेशन को अपडेट करने की आवश्यकता है, तो इसमें सीआई पाइपलाइन का उपयोग करके समन्वित, अनुक्रमिक तरीके से सर्वर बेड़े को अपडेट करना शामिल है। यह विधि-यद्यपि धीमी और थोड़ी है उबाऊ - यह सुनिश्चित करता है कि GitLab.com ऑफ़लाइन उपयोगकर्ताओं के समान इंस्टॉलेशन और कॉन्फ़िगरेशन प्रथाओं का उपयोग करता है (स्व-प्रबंधित) इसके लिए हमारे लिनक्स पैकेज का उपयोग करके GitLab इंस्टॉलेशन।

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

कुबेरनेट्स और क्लाउड-नेटिव गिटलैब के लिए पहला कदम

यह प्रोजेक्ट 2017 में बनाया गया था गिटलैब चार्ट क्लाउड परिनियोजन के लिए GitLab तैयार करना, और उपयोगकर्ताओं को Kubernetes क्लस्टर पर GitLab स्थापित करने में सक्षम बनाना। हम तब जानते थे कि GitLab को Kubernetes में ले जाने से SaaS प्लेटफ़ॉर्म की स्केलेबिलिटी बढ़ जाएगी, तैनाती सरल हो जाएगी और कंप्यूटिंग संसाधनों की दक्षता में सुधार होगा। साथ ही, हमारे एप्लिकेशन के कई कार्य माउंटेड एनएफएस विभाजन पर निर्भर थे, जो वर्चुअल मशीनों से संक्रमण को धीमा कर देता था।

क्लाउड नेटिव और कुबेरनेट्स की ओर दबाव ने हमारे इंजीनियरों को क्रमिक परिवर्तन की योजना बनाने की अनुमति दी, जिसके दौरान हमने नई सुविधाओं को विकसित करना जारी रखते हुए नेटवर्क स्टोरेज पर एप्लिकेशन की कुछ निर्भरता को छोड़ दिया। चूंकि हमने 2019 की गर्मियों में माइग्रेशन की योजना बनाना शुरू किया था, इसलिए इनमें से कई सीमाएं हल हो गई हैं, और GitLab.com को कुबेरनेट्स में माइग्रेट करने की प्रक्रिया अब अच्छी तरह से चल रही है!

कुबेरनेट्स में GitLab.com की विशेषताएं

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

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

ये सभी GitLab.com सेवाएँ एक असंशोधित GitLab हेल्म चार्ट का उपयोग करके कॉन्फ़िगर की गई हैं। कॉन्फ़िगरेशन उपचार्ट में किया जाता है, जिसे चुनिंदा रूप से सक्षम किया जा सकता है क्योंकि हम धीरे-धीरे सेवाओं को क्लस्टर में स्थानांतरित करते हैं। भले ही हमने माइग्रेशन में अपनी कुछ स्टेटफुल सेवाओं, जैसे रेडिस, पोस्टग्रेज, गिटलैब पेज और गीताली को शामिल नहीं करने का फैसला किया है, कुबेरनेट्स का उपयोग हमें शेफ द्वारा वर्तमान में प्रबंधित किए जाने वाले वीएम की संख्या को मौलिक रूप से कम करने की अनुमति देता है।

कुबेरनेट्स कॉन्फ़िगरेशन दृश्यता और प्रबंधन

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

हालाँकि कुबेरनेट्स क्लस्टर के लिए हमारी पाइपलाइन एक अलग GitLab इंस्टॉलेशन पर चलती हैं, कोड रिपॉजिटरी के दर्पण हैं जो निम्नलिखित पते पर सार्वजनिक रूप से उपलब्ध हैं:

• k8s-वर्कलोड/gitlab-com - GitLab हेल्म चार्ट के लिए GitLab.com कॉन्फ़िगरेशन ढांचा;
• k8s-वर्कलोड्स/जीटलैब-हेल्मफाइल्स - इसमें उन सेवाओं के लिए कॉन्फ़िगरेशन शामिल हैं जो सीधे GitLab एप्लिकेशन से संबद्ध नहीं हैं। इनमें लॉगिंग और क्लस्टर मॉनिटरिंग के लिए कॉन्फ़िगरेशन, साथ ही प्लांटयूएमएल जैसे एकीकृत उपकरण शामिल हैं;
• Gitlab-com-बुनियादी ढांचा - कुबेरनेट्स और लीगेसी वीएम इंफ्रास्ट्रक्चर के लिए टेराफॉर्म कॉन्फ़िगरेशन। यहां आप क्लस्टर को चलाने के लिए आवश्यक सभी संसाधनों को कॉन्फ़िगर करते हैं, जिसमें क्लस्टर, नोड पूल, सेवा खाते और आईपी एड्रेस आरक्षण शामिल हैं।

जब परिवर्तन किए जाते हैं तो सार्वजनिक दृश्य दिखाया जाता है। संक्षिप्त सारांश विस्तृत अंतर के लिंक के साथ जिसका एसआरई क्लस्टर में परिवर्तन करने से पहले विश्लेषण करता है।

एसआरई के लिए, लिंक गिटलैब इंस्टॉलेशन में एक विस्तृत अंतर की ओर ले जाता है, जिसका उपयोग उत्पादन के लिए किया जाता है और जिस तक पहुंच सीमित है। यह कर्मचारियों और समुदाय को, परिचालन परियोजना (जो केवल एसआरई के लिए खुला है) तक पहुंच के बिना, प्रस्तावित कॉन्फ़िगरेशन परिवर्तनों को देखने की अनुमति देता है। कोड के लिए सार्वजनिक GitLab इंस्टेंस को CI पाइपलाइनों के लिए निजी इंस्टेंस के साथ जोड़कर, हम कॉन्फ़िगरेशन अपडेट के लिए GitLab.com से स्वतंत्रता सुनिश्चित करते हुए एकल वर्कफ़्लो बनाए रखते हैं।

प्रवास के दौरान हमें क्या पता चला

इस कदम के दौरान, अनुभव प्राप्त हुआ कि हम कुबेरनेट्स में नए माइग्रेशन और तैनाती पर लागू होते हैं।

1. उपलब्धता क्षेत्रों के बीच यातायात के कारण बढ़ी हुई लागत

GitLab.com पर Git रिपॉजिटरी बेड़े के लिए दैनिक निकास आँकड़े (प्रति दिन बाइट्स)।

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

क्षेत्रीय जीकेई क्लस्टर आपको अतिरेक के लिए कई उपलब्धता क्षेत्रों का विस्तार करने की अनुमति देते हैं। हम संभावना पर विचार कर रहे हैं क्षेत्रीय GKE क्लस्टर को एकल-क्षेत्र क्लस्टर में विभाजित करें उन सेवाओं के लिए जो बड़ी मात्रा में ट्रैफ़िक उत्पन्न करती हैं। इससे क्लस्टर-स्तरीय अतिरेक को बनाए रखते हुए निकास लागत में कमी आएगी।

2. सीमाएँ, संसाधन अनुरोध और स्केलिंग

रजिस्ट्री.gitlab.com पर उत्पादन ट्रैफ़िक संसाधित करने वाली प्रतिकृतियों की संख्या। ट्रैफ़िक ~15:00 यूटीसी पर चरम पर होता है।

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

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

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

बुनियादी ढांचा प्रभाग विलंबता, त्रुटि दर और स्थापित के साथ संतृप्ति पर ध्यान केंद्रित करता है सेवा स्तर के लक्ष्य (एसएलओ) से जुड़ा हुआ है हमारे सिस्टम की सामान्य उपलब्धता.

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

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

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

4. ट्रैफ़िक को नए क्लस्टर में स्विच करना

GitLab.com के लिए, सर्वर का एक हिस्सा समर्पित है कैनरी चरण. कैनरी पार्क हमारी आंतरिक परियोजनाओं को पूरा करता है और कर भी सकता है उपयोगकर्ताओं द्वारा सक्षम किया गया. लेकिन इसे मुख्य रूप से बुनियादी ढांचे और एप्लिकेशन में किए गए परिवर्तनों का परीक्षण करने के लिए डिज़ाइन किया गया है। पहली माइग्रेट सेवा सीमित मात्रा में आंतरिक ट्रैफ़िक स्वीकार करके शुरू हुई, और हम यह सुनिश्चित करने के लिए इस पद्धति का उपयोग करना जारी रखते हैं कि क्लस्टर में सभी ट्रैफ़िक भेजने से पहले एसएलओ की पूर्ति हो।

माइग्रेशन के मामले में, इसका मतलब है कि आंतरिक परियोजनाओं के अनुरोध पहले कुबेरनेट्स को भेजे जाते हैं, और फिर हम धीरे-धीरे HAProxy के माध्यम से बैकएंड के लिए वजन बदलकर शेष ट्रैफ़िक को क्लस्टर में स्विच करते हैं। वीएम से कुबेरनेट्स में माइग्रेशन के दौरान, यह स्पष्ट हो गया कि पुराने और नए बुनियादी ढांचे के बीच यातायात को पुनर्निर्देशित करने का एक आसान तरीका होना और तदनुसार, माइग्रेशन के बाद पहले कुछ दिनों में पुराने बुनियादी ढांचे को रोलबैक के लिए तैयार रखना बहुत फायदेमंद था।

5. पॉड्स की आरक्षित क्षमताएं और उनका उपयोग

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

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

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

निष्कर्ष

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

मुझे आशा है कि आपको हमारे कुबेरनेट्स प्रवासन रोमांच की कहानी पसंद आई होगी। हम सभी नई सेवाओं को क्लस्टर में स्थानांतरित करना जारी रखते हैं। अतिरिक्त जानकारी निम्नलिखित प्रकाशनों में पाई जा सकती है:

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

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «कुबेरनेट्स के साथ उत्पादन में 3 साल: हम यही समझते हैं";
• «10 सामान्य कुबेरनेट्स गलतियाँ";
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग 3: गिटहब";
• «टिंडर का कुबेरनेट्स में संक्रमण'.

स्रोत: www.habr.com