टिंडर का कुबेरनेट्स में संक्रमण

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

क्यों?

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

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

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

कैसे?

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

कुबेरनेट्स के लिए चित्र बनाना

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

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

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

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

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

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

कुबेरनेट्स क्लस्टर आर्किटेक्चर और माइग्रेशन

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

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

अंत में हम इस पर सहमत हुए:

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

प्रवास

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

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

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

पाठ

नेटवर्क फैब्रिक की सीमाएँ

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

ARP कैश से संबंधित तीन Linux विकल्प हैं:

(स्रोत)

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

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

चित्र 2-1. फलालैन आरेख (स्रोत)

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

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

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

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

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

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

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

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

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

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

समस्या सोर्स और डेस्टिनेशन नेटवर्क एड्रेस ट्रांसलेशन (एसएनएटी और डीएनएटी) और बाद में तालिका में प्रविष्टि के चरण में होती है conntrack. आंतरिक रूप से चर्चा किए गए और समुदाय द्वारा सुझाए गए समाधानों में से एक DNS को वर्कर नोड में ही स्थानांतरित करना था। इस मामले में:

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

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

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

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

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

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

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

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

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

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

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

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

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

अंतिम परिणाम

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

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

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

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

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

• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: ईबे से 4200 चूल्हे और टेसमास्टर'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: सहमति और एसएपी'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: GitHub'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: साउंडक्लाउड (प्रोमेथियस द्वारा)'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: डिजिटल बैंक मोन्जो'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: BlaBlaCar'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: ब्लैकरॉक'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: हुआवेई'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: CERN और 210 K8s क्लस्टर'.
• «उत्पादन में कुबेरनेट्स की सफलता की कहानियाँ। भाग ---- पहला: रेडिट'.

स्रोत: www.habr.com