🙎 🐛 👨🏽‍🔧 ट्यूबर को कुबेरनेट पर स्विच करें 👨🏽‍🏭 🤛 👽

लगभग। ट्रांस। : टिंडर के कर्मचारियों ने हाल ही में कुबेरनेट्स में अपने बुनियादी ढांचे को स्थानांतरित करने के कुछ तकनीकी विवरण साझा किए। इस प्रक्रिया में लगभग दो साल लगे और 488 कंटेनरों में होस्ट की गई 200 सेवाओं से युक्त एक बहुत बड़े पैमाने के प्लेटफॉर्म के K8 पर लॉन्च किया गया। टिंडर इंजीनियरों को किन दिलचस्प कठिनाइयों का सामना करना पड़ा और उनके क्या परिणाम आए - इस अनुवाद में पढ़ें।

क्यों?

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

हमने स्केलेबिलिटी और स्थिरता की समस्या के समाधान की भी तलाश की। जब स्केलिंग क्रिटिकल हो गई, तो हमें अक्सर नए EC2 इंस्टेंस लॉन्च करने के लिए कई मिनट इंतजार करना पड़ता था। इसलिए, कंटेनरों को लॉन्च करने और मिनटों के बजाय सेकंड में ट्रैफ़िक सेवा शुरू करने का विचार हमारे लिए बहुत आकर्षक हो गया।

प्रक्रिया आसान नहीं थी। माइग्रेशन के दौरान, 2019 की शुरुआत में, कुबेरनेट्स क्लस्टर एक महत्वपूर्ण द्रव्यमान तक पहुंच गया और हम यातायात, क्लस्टर आकार और डीएनएस की मात्रा के कारण विभिन्न समस्याओं का सामना करने लगे। इस यात्रा में, हमने 200 सेवाओं के हस्तांतरण और कुबेरनेट्स क्लस्टर के रखरखाव से संबंधित कई दिलचस्प समस्याओं को हल किया, जिसमें 1000 नोड्स, 15,000 पॉड और 48,000 वर्किंग कंटेनर शामिल हैं।

कैसे?

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

कुबेरनेट्स के लिए छवियां बनाएं

हमारे पास Kubernetes क्लस्टर में चलने वाले microservices के लिए 30 से अधिक स्रोत कोड रिपॉजिटरी हैं। इन रिपॉजिटरी में कोड अलग-अलग भाषाओं में लिखा जाता है (उदाहरण के लिए, Node.js, Java, Scala, Go) एक ही भाषा के लिए कई रनटाइम वातावरण के साथ।

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

चित्र 1-1। कंटेनर-बिल्डर (बिल्डर) के माध्यम से मानकीकृत निर्माण प्रक्रिया

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

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

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

कुबेरनेट्स क्लस्टर वास्तुकला और प्रवासन

क्लस्टर आकार प्रबंधन

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

नतीजतन, हम पर बसे:

m5.4xlarge - निगरानी (प्रोमेथियस) के लिए;
c5.4xlarge - Node.js वर्कलोड (एकल-थ्रेडेड वर्कलोड) के लिए;
c5.2xlarge - जावा और गो (बहु-थ्रेडेड वर्कलोड) के लिए;
c5.4xlarge - नियंत्रण कक्ष (3 नोड्स) के लिए।

प्रवास

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

ये एंडपॉइंट प्रत्येक नए ईएलबी की ओर इशारा CNAMEs के साथ DNS रिकॉर्ड के भारित सेट का उपयोग करके बनाए गए थे। स्विच करने के लिए, हमने 0. के वजन के साथ नई कुबेरनेट सेवा ईएलबी की ओर इशारा करते हुए एक नया रिकॉर्ड जोड़ा। फिर हमने रिकॉर्डसेट के टाइम टू लाइव (टीटीएल) को 0. पर सेट किया। इसके बाद, पुराने और नए वजन धीरे-धीरे समायोजित किए गए, और अंततः 100% लोड हो गया। नए सर्वर के लिए। स्विच पूरा होने के बाद, TTL मान अधिक पर्याप्त स्तर पर लौट आया।

हमारे मौजूदा जावा मॉड्यूल ने कम टीटीएल डीएनएस को संभाला, लेकिन नोड अनुप्रयोगों ने नहीं किया। इंजीनियरों में से एक ने कनेक्शन पूल कोड का हिस्सा फिर से लिखा, इसे एक प्रबंधक में लपेटकर जिसने हर 60 सेकंड में पूल को अपडेट किया। चुने गए दृष्टिकोण ने बहुत अच्छा काम किया और प्रदर्शन में ध्यान देने योग्य कमी के बिना।

सबक

नेटवर्क डिवाइस प्रतिबंध

8 जनवरी, 2019 की सुबह में, टिंडर प्लेटफॉर्म अचानक दुर्घटनाग्रस्त हो गया। सुबह प्लेटफॉर्म विलंबता में असंबंधित वृद्धि के जवाब में, क्लस्टर में फली और नोड की संख्या में वृद्धि हुई। इसके कारण हमारे सभी नोड्स पर ARP कैश समाप्त हो गया।

ARP कैश से जुड़े तीन लिनक्स विकल्प हैं:

( स्रोत )

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

हम कुबेरनेट्स में फलालैन को नेटवर्क फैब्रिक के रूप में उपयोग करते हैं। पैकेट VXLAN पर प्रसारित होते हैं। VXLAN एक L2 सुरंग है, जिसे L3 नेटवर्क पर उठाया गया है। तकनीक मैक-इन-यूडीपी (मैक एड्रेस-इन-यूज़र डाटाग्राम प्रोटोकॉल) एनकैप्सुलेशन का उपयोग करती है और आपको दूसरे स्तर के नेटवर्क सेगमेंट का विस्तार करने की अनुमति देती है। डेटा सेंटर के भौतिक नेटवर्क में परिवहन प्रोटोकॉल आईपी प्लस यूडीपी है।

चित्र 2-1। फलालैन चार्ट ( स्रोत )

चित्र 2-2। VXLAN पैकेट ( स्रोत )

प्रत्येक कुबेरनेट कार्य नोड बड़े ब्लॉक / 9 से मास्क / 24 के साथ एक वर्चुअल एड्रेस स्पेस आवंटित करता है। प्रत्येक नोड के लिए, इसका अर्थ है राउटिंग टेबल में एक प्रविष्टि, एआरपी तालिका में एक प्रविष्टि ( फ्लैनलाइन.1 इंटरफ़ेस पर) और स्विचिंग टेबल ( एफडीबी ) में एक प्रविष्टि। उन्हें तब जोड़ा जाता है जब काम नोड पहले शुरू होता है या जब प्रत्येक नए नोड का पता लगाया जाता है।

इसके अलावा, नोड-पॉड (या पॉड-पॉड) कनेक्शन अंततः eth0 इंटरफ़ेस के माध्यम से जाता है (जैसा कि फ़्लेनलाइन आरेख में दिखाया गया है)। यह नोड के प्रत्येक संबंधित स्रोत और गंतव्य के लिए एआरपी तालिका में एक अतिरिक्त प्रविष्टि का परिणाम है।

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

विफलता के समय, क्लस्टर में 605 नोड्स थे। ऊपर बताए गए कारणों के लिए, यह डिफ़ॉल्ट gc_thresh3 मान को दूर करने के लिए पर्याप्त था। जब ऐसा होता है, तो न केवल पैकेट को छोड़ दिया जाना शुरू हो जाता है, बल्कि एआरपी तालिका से / 24 मास्क के साथ पूरा फ्लैननेल वर्चुअल एड्रेस स्पेस गायब हो जाता है। नोड-पॉड संचार और डीएनएस प्रश्न बाधित होते हैं (डीएनएस को एक क्लस्टर में होस्ट किया जाता है; विवरण के लिए इस लेख के बाकी देखें)।

इस समस्या को हल करने के लिए, gc_thresh1 , gc_thresh2 और gc_thresh3 के मान बढ़ाएँ और फ़्लानलाइन को लापता नेटवर्क को फिर से पंजीकृत करने के लिए पुनः आरंभ करें।

अनपेक्षित DNS स्केलिंग

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

चूंकि सेवाओं को कुबेरनेट्स में स्थानांतरित कर दिया गया था, हमने पाया कि DNS प्रति सेकंड 250,000 प्रश्नों को संभालता है। परिणामस्वरूप, DNS क्वेरीज़ के लिए एप्लिकेशन निरंतर और गंभीर समयबाह्य अनुभव करने लगे। डीएनएस प्रदाता को कोरडएनएस (जो कि १२० कोर पर १००० डोंगों पर चल रहा है) तक पहुँचने और स्विच करने के अविश्वसनीय प्रयासों के बावजूद ऐसा हुआ।

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

समस्या स्रोत और गंतव्य नेटवर्क पता अनुवाद (SNAT और DNAT) चरण और बाद में कनवर्टर तालिका में प्रवेश पर उत्पन्न होती है। कंपनी के भीतर चर्चा की और कंपनी द्वारा प्रस्तावित वर्कअराउंड में से एक DNS को कार्य नोड में ही स्थानांतरित करना था। इस मामले में:

SNAT की आवश्यकता नहीं है क्योंकि यातायात नोड के अंदर रहता है। यह eth0 इंटरफ़ेस के माध्यम से रूट करने की आवश्यकता नहीं है।
DNAT की आवश्यकता नहीं है, क्योंकि गंतव्य IP होस्ट के लिए स्थानीय है, और iptables नियमों के अनुसार यादृच्छिक रूप से चयनित पॉड नहीं है।

हमने इस दृष्टिकोण से चिपके रहने का फैसला किया। CoreDNS को कुबेरनेट्स में डेमनसेट के रूप में तैनात किया गया था और हमने क्यूबलेट कमांड के --cluster-dns ध्वज को कॉन्फ़िगर करके प्रत्येक पॉड के resolv.conf में एक स्थानीय होस्ट DNS सर्वर लागू किया था। यह समाधान DNS टाइमआउट के लिए प्रभावी साबित हुआ है।

हालाँकि, हमने अभी भी पैकेट हानि और फ़्लेनेल इंटरफ़ेस में सम्मिलित_फेल काउंटर में वृद्धि देखी । यह स्थिति वर्कअराउंड की शुरुआत के बाद जारी रही, क्योंकि हम एसएनएटी और / या डीएनएटी को केवल डीएनएस ट्रैफिक से बाहर करने में सक्षम थे। अन्य प्रकार के ट्रैफ़िक के लिए रेस की स्थिति बनी रही। सौभाग्य से, हमारे अधिकांश पैकेज टीसीपी हैं, और जब कोई समस्या होती है, तो वे बस पीछे हट जाते हैं। हम अभी भी सभी प्रकार के यातायात के लिए एक उपयुक्त समाधान खोजने की कोशिश कर रहे हैं।

बेहतर लोड संतुलन के लिए दूत का उपयोग करना

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

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

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

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

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

परिनियोजन के लिए, हमने एप्लिकेशन पॉड्स और साइडकार पॉड्स, दोनों पर प्रीस्टॉप हुक का उपयोग किया। हुक ने सीकर-कंटेनर पर स्थित व्यवस्थापक एंडपॉइंट की स्थिति की जांच करने में त्रुटि शुरू की, और सक्रिय कनेक्शन को पूरा करने की अनुमति देने के लिए थोड़ी देर के लिए "सो गया"।

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

परिणाम तत्काल और स्पष्ट थे। हमने सबसे असंतुलित सेवाओं के साथ शुरुआत की, और फिलहाल यह क्लस्टर में 12 सबसे महत्वपूर्ण सेवाओं से पहले ही काम करता है। इस वर्ष हम अधिक उन्नत सेवा खोज, सर्किट ब्रेकिंग, आउटलाइर डिटेक्शन, स्पीड लिमिटिंग और ट्रेसिंग के साथ एक पूर्ण सेवा जाल में जाने की योजना बना रहे हैं।

चित्र 3-1। एनवॉय को संक्रमण के दौरान एक सेवा का सीपीयू अभिसरण

अंतिम परिणाम

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

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

प्रवास करने में लगभग दो साल लग गए, लेकिन हमने मार्च 2019 में इसे पूरा किया। वर्तमान में, Tinder प्लेटफ़ॉर्म Kubernetes क्लस्टर पर विशेष रूप से चलता है, जिसमें 200 सेवाएँ, 1000 नोड्स, 15,000 पॉड्स और 48,000 रनिंग कंटेनर होते हैं। इंफ्रास्ट्रक्चर अब ऑपरेटिंग टीमों की एकमात्र जिम्मेदारी नहीं है। हमारे सभी इंजीनियर इस जिम्मेदारी को साझा करते हैं और केवल कोड का उपयोग करके अपने अनुप्रयोगों के निर्माण और तैनाती की प्रक्रिया को नियंत्रित करते हैं।

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

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

ट्यूबर को कुबेरनेट पर स्विच करें