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 विभाजनहरूमा निर्भर थिए, जसले भर्चुअल मेसिनहरूबाट संक्रमणलाई सुस्त बनायो।

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

Kubernetes मा GitLab.com को सुविधाहरू

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

फ्रन्टएन्डको मामलामा, यी प्रकारहरूलाई वेब, API, Git SSH/HTTPS र रजिस्ट्रीमा अनुरोधहरूमा विभाजित गरिएको छ। ब्याकएन्डको मामलामा, हामी विभिन्न विशेषताहरू आधारमा लाममा कामहरू विभाजन गर्छौं। पूर्वनिर्धारित स्रोत सीमाहरू, जसले हामीलाई विभिन्न कार्यभारहरूको लागि सेवा-स्तर उद्देश्यहरू (SLOs) सेट गर्न अनुमति दिन्छ।

यी सबै 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 अनुप्रयोगसँग सम्बन्धित छैन। यसमा लगिङ र क्लस्टर निगरानीका लागि कन्फिगरेसनहरू, साथै PlantUML जस्ता एकीकृत उपकरणहरू समावेश छन्;
• Gitlab-com-पूर्वाधार — Kubernetes र लिगेसी VM पूर्वाधारका लागि टेराफर्म कन्फिगरेसन। यहाँ तपाईँले क्लस्टर चलाउन आवश्यक सबै स्रोतहरू कन्फिगर गर्नुहुन्छ, क्लस्टर आफै, नोड पूलहरू, सेवा खाताहरू, र IP ठेगाना आरक्षणहरू सहित।

परिवर्तनहरू गर्दा सार्वजनिक दृश्य देखाइन्छ। छोटो सारांश विस्तृत भिन्नताको लिङ्कको साथ जुन SRE ले क्लस्टरमा परिवर्तन गर्नु अघि विश्लेषण गर्दछ।

SRE को लागि, लिङ्कले GitLab स्थापनामा विस्तृत भिन्नता तर्फ लैजान्छ, जुन उत्पादनको लागि प्रयोग गरिन्छ र पहुँच प्रतिबन्धित छ। यसले कर्मचारी र समुदायलाई परिचालन परियोजनामा ​​पहुँच बिना (जसलाई SRE हरू मात्र खुला छ) प्रस्तावित कन्फिगरेसन परिवर्तनहरू हेर्न अनुमति दिन्छ। CI पाइपलाइनहरूको लागि एक निजी उदाहरणसँग कोडको लागि सार्वजनिक GitLab उदाहरण संयोजन गरेर, हामी कन्फिगरेसन अद्यावधिकहरूको लागि GitLab.com बाट स्वतन्त्रता सुनिश्चित गर्दै एकल कार्यप्रवाह कायम राख्छौं।

बसाइँसराइको क्रममा हामीले के थाहा पायौं

चालको क्रममा, अनुभव प्राप्त भयो कि हामीले कुबेरनेटमा नयाँ माइग्रेसन र डिप्लोइमेन्टहरूमा लागू गर्छौं।

1. उपलब्धता क्षेत्रहरू बीचको ट्राफिकको कारणले बढेको लागत

GitLab.com मा Git रिपोजिटरी फ्लीटको लागि दैनिक निकास तथ्याङ्कहरू (प्रति दिन बाइटहरू)

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

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

2. सीमा, स्रोत अनुरोध र मापन

registry.gitlab.com मा उत्पादन ट्राफिक प्रशोधन गर्ने प्रतिकृतिहरूको संख्या। ~15:00 UTC मा ट्राफिक शिखर।

हाम्रो माइग्रेसन कथा अगस्ट २०१९ मा सुरु भयो, जब हामीले हाम्रो पहिलो सेवा, GitLab कन्टेनर रजिस्ट्री, Kubernetes मा स्थानान्तरण गर्यौं। यो मिशन-महत्वपूर्ण, उच्च-ट्राफिक सेवा पहिलो माइग्रेसनको लागि राम्रो विकल्प थियो किनभने यो केही बाह्य निर्भरताहरू भएको राज्यविहीन अनुप्रयोग हो। हामीले सामना गरेको पहिलो समस्या नोडहरूमा मेमोरीको कमीको कारण धेरै संख्यामा बेदखल गरिएका पोडहरू थिए। यस कारणले, हामीले अनुरोध र सीमाहरू परिवर्तन गर्नुपर्‍यो।

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

३. मेट्रिक्स र लगहरू

पूर्वाधार विभाजन विलम्बता, त्रुटि दर र स्थापना संग संतृप्ति मा केन्द्रित छ सेवा स्तर लक्ष्यहरू (SLO) मा लिङ्क गरिएको छ हाम्रो प्रणाली को सामान्य उपलब्धता.

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

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

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

4. नयाँ क्लस्टरमा ट्राफिक स्विच गर्दै

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

माइग्रेसनको अवस्थामा, यसको मतलब यो हो कि आन्तरिक परियोजनाहरूका लागि अनुरोधहरू पहिले Kubernetes मा पठाइन्छ, र त्यसपछि हामी HAProxy मार्फत ब्याकइन्डको लागि वजन परिवर्तन गरेर क्रमशः क्लस्टरमा बाँकी ट्राफिकहरू स्विच गर्छौं। VM बाट Kubernetes मा माइग्रेसनको क्रममा, यो स्पष्ट भयो कि पुरानो र नयाँ पूर्वाधारहरू बीच ट्राफिक रिडिरेक्ट गर्न सजिलो तरिका पाउनु धेरै लाभदायक थियो र, तदनुसार, माइग्रेसन पछिको केही दिनहरूमा पुरानो पूर्वाधारलाई रोलब्याकको लागि तयार राख्नुहोस्।

5. पोडहरू र तिनीहरूको प्रयोगको क्षमताहरू सुरक्षित गर्नुहोस्

लगभग तुरुन्तै निम्न समस्या पहिचान गरिएको थियो: रजिस्ट्री सेवाको लागि पोडहरू चाँडै सुरु भयो, तर Sidekiq को लागि पोडहरू सुरू गर्न समय लाग्यो। दुई मिनेट। Sidekiq pods को लागी लामो स्टार्टअप समय एक मुद्दा बन्यो जब हामीले कामदारहरु को लागी Kubernetes मा कार्यभार माइग्रेट गर्न थाल्यौं जसलाई छिटो र छिटो मापन गर्न आवश्यक छ।

यस अवस्थामा, पाठ यो थियो कि Kubernetes' Horizontal Pod Autoscaler (HPA) ले ट्राफिक बृद्धिलाई राम्रोसँग ह्यान्डल गर्छ, कार्यभारका विशेषताहरूलाई विचार गर्न र पोडहरूमा स्पेयर क्षमता आवंटित गर्न महत्त्वपूर्ण छ (विशेष गरी जब माग असमान रूपमा वितरित हुन्छ)। हाम्रो केसमा, त्यहाँ कामहरूमा अचानक वृद्धि भएको थियो, जसले द्रुत स्केलिंगको लागि नेतृत्व गर्‍यो, जसले हामीले नोड पूल मापन गर्ने समय हुनु अघि CPU स्रोतहरूको संतृप्ति निम्त्यायो।

त्यहाँ जहिले पनि क्लस्टरबाट सकेसम्म धेरै निचोड गर्ने प्रलोभन हुन्छ, तथापि, सुरुमा प्रदर्शन समस्याहरू सामना गरेपछि, हामी अब उदार पोड बजेटको साथ सुरू गर्दैछौं र पछि यसलाई घटाउँदैछौं, SLOs मा नजिकको नजर राख्दै। Sidekiq सेवाको लागि पोडहरू लन्च गर्ने क्रममा उल्लेखनीय रूपमा गति बढेको छ र अब औसतमा लगभग 40 सेकेन्ड लाग्छ। पोडको प्रक्षेपण समय घटाउने देखि GitLab.com र आधिकारिक GitLab हेल्म चार्टसँग काम गर्ने स्व-व्यवस्थित स्थापनाहरूको हाम्रा प्रयोगकर्ताहरू दुवै जित्यो।

निष्कर्षमा

प्रत्येक सेवा माइग्रेट गरेपछि, हामीले उत्पादनमा Kubernetes प्रयोग गर्ने फाइदाहरूमा रमाइलो गर्‍यौं: छिटो र सुरक्षित एप्लिकेसन डिप्लोइमेन्ट, स्केलिङ, र थप कुशल स्रोत आवंटन। यसबाहेक, माइग्रेसनका फाइदाहरू GitLab.com सेवाभन्दा बाहिर जान्छन्। आधिकारिक हेल्म चार्टमा हुने हरेक सुधारले यसको प्रयोगकर्ताहरूलाई फाइदा पुर्‍याउँछ।

मलाई आशा छ कि तपाईंले हाम्रो Kubernetes माइग्रेसन साहसिक कथाको मजा लिनुभयो। हामी सबै नयाँ सेवाहरू क्लस्टरमा स्थानान्तरण गर्न जारी राख्छौं। थप जानकारी निम्न प्रकाशनहरूमा फेला पार्न सकिन्छ:

• «हामी किन कुबेरनेटमा बसाइँ सर्दै छौं?»;
• «Kubernetes मा GitLab.com»;
• GitLab.com मा Kubernetes मा स्थानान्तरण मा महाकाव्य.

अनुवादकबाट PS

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

• «उत्पादनमा Kubernetes संग 3 वर्ष: हामी के बुझ्छौं यहाँ छ»;
• «Kubernetes प्रयोग गर्दा 10 सामान्य गल्तीहरू»;
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 3: GitHub»;
• «कुबेरनेटमा टिन्डर संक्रमण"।

स्रोत: www.habr.com