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

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

किन?

लगभग दुई वर्ष पहिले, Tinder ले आफ्नो प्लेटफर्म Kubernetes मा सार्न निर्णय गर्यो। Kubernetes ले Tinder टोलीलाई कन्टेनराइज गर्न र अपरिवर्तनीय तैनाती मार्फत न्यूनतम प्रयासको साथ उत्पादनमा सार्न अनुमति दिनेछ। (अपरिवर्तनीय परिनियोजन)। यस अवस्थामा, अनुप्रयोगहरूको संयोजन, तिनीहरूको तैनाती, र पूर्वाधार आफैंमा कोडद्वारा विशिष्ट रूपमा परिभाषित हुनेछ।

हामीले मापनीयता र स्थिरताको समस्याको समाधान पनि खोजिरहेका थियौं। जब स्केलिंग महत्वपूर्ण भयो, हामीले प्राय: नयाँ EC2 उदाहरणहरू स्पिन गर्न धेरै मिनेट पर्खनु पर्थ्यो। कन्टेनरहरू लन्च गर्ने र मिनेटको सट्टा सेकेन्डमा ट्राफिक सेवा सुरु गर्ने विचार हामीलाई धेरै आकर्षक लाग्यो।

प्रक्रिया झन्झटिलो सावित भयो । 2019 को सुरुमा हाम्रो माइग्रेसनको क्रममा, Kubernetes क्लस्टर महत्वपूर्ण मासमा पुग्यो र हामीले ट्राफिक भोल्युम, क्लस्टर साइज, र DNS का कारण विभिन्न समस्याहरूको सामना गर्न थाल्यौं। बाटोमा, हामीले 200 सेवाहरू माइग्रेट गर्ने र 1000 नोडहरू, 15000 पोडहरू र 48000 चलिरहेको कन्टेनरहरू मिलेर कुबेरनेट क्लस्टरलाई कायम राख्ने सम्बन्धमा धेरै रोचक समस्याहरू समाधान गर्यौं।

कसरी?

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

Kubernetes को लागि छविहरू निर्माण गर्दै

हामीसँग Kubernetes क्लस्टरमा चल्ने माइक्रो सेवाहरूको लागि 30 भन्दा बढी स्रोत कोड भण्डारहरू छन्। यी भण्डारहरूमा कोड फरक भाषाहरूमा लेखिएको छ (उदाहरणका लागि, Node.js, Java, Scala, Go) एउटै भाषाको लागि धेरै रनटाइम वातावरणहरूसँग।

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

चित्र १-१। बिल्डर कन्टेनर मार्फत मानकीकृत निर्माण प्रक्रिया

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

उसको कन्टेनर कार्यान्वयनको लागि उन्नत डकर प्रविधिहरू चाहिन्छ। बिल्डरले स्थानीय प्रयोगकर्ता ID र गोप्यहरू (जस्तै SSH कुञ्जी, AWS प्रमाणहरू, आदि) लाई निजी टिन्डर भण्डारहरू पहुँच गर्न आवश्यक पर्दछ। यसले प्राकृतिक रूपमा निर्माण कलाकृतिहरू भण्डारण गर्न स्रोतहरू समावेश गर्ने स्थानीय निर्देशिकाहरू माउन्ट गर्दछ। यस दृष्टिकोणले कार्यसम्पादन सुधार गर्छ किनभने यसले बिल्डर कन्टेनर र होस्ट बीचको निर्माण कलाकृतिहरू प्रतिलिपि गर्ने आवश्यकतालाई हटाउँछ। भण्डारण गरिएका निर्माण कलाकृतिहरू अतिरिक्त कन्फिगरेसन बिना पुन: प्रयोग गर्न सकिन्छ।

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

Kubernetes क्लस्टर वास्तुकला र माइग्रेसन

क्लस्टर साइज व्यवस्थापन

हामीले प्रयोग गर्ने निर्णय गर्यौं kube-aws Amazon EC2 उदाहरणहरूमा स्वचालित क्लस्टर डिप्लोइमेन्टको लागि। धेरै सुरुमा, सबै नोड्स को एक साझा पूल मा काम गरे। हामीले संसाधनहरूको थप प्रभावकारी प्रयोग गर्न आकार र उदाहरण प्रकारद्वारा कार्यभार छुट्याउनुपर्ने आवश्यकतालाई तुरुन्तै महसुस गर्यौं। तर्क यो थियो कि धेरै लोड गरिएका बहु-थ्रेडेड पोडहरू लन्च गर्दा एकल-थ्रेडेड पोडहरूको ठूलो संख्याको साथ तिनीहरूको सहअस्तित्वको तुलनामा कार्यसम्पादनको सर्तमा अधिक अनुमानित भयो।

अन्तमा हामीले यो कुरा तय गर्यौं:

• m5.4x ठूलो - निगरानीको लागि (प्रोमेथियस);
• c5.4x ठूलो - Node.js कार्यभारको लागि (एकल-थ्रेडेड कार्यभार);
• c5.2x ठूलो - जाभा र गो (बहुथ्रेडेड कार्यभार) को लागी;
• c5.4x ठूलो - नियन्त्रण प्यानल (3 नोड्स) को लागी।

माइग्रेसन

पुरानो पूर्वाधारबाट Kubernetes मा स्थानान्तरणको लागि एक तयारी चरणहरू नयाँ लोड ब्यालेन्सरहरू (इलास्टिक लोड ब्यालेन्सरहरू (ELB) सेवाहरू बीचको विद्यमान प्रत्यक्ष सञ्चारलाई पुन: निर्देशित गर्नु थियो। तिनीहरू भर्चुअल निजी क्लाउड (VPC) को एक विशिष्ट सबनेटमा सिर्जना गरिएको थियो। यो सबनेट Kubernetes VPC मा जडान गरिएको थियो। यसले हामीलाई सेवा निर्भरताहरूको विशिष्ट क्रमलाई विचार नगरी बिस्तारै मोड्युलहरू माइग्रेट गर्न अनुमति दियो।

यी अन्तिम बिन्दुहरू DNS रेकर्डहरूको भारित सेटहरू प्रयोग गरेर सिर्जना गरिएका थिए जसमा CNAME हरू प्रत्येक नयाँ ELB तर्फ संकेत गर्दै थिए। स्विच गर्नको लागि, हामीले कुबर्नेट्स सेवाको नयाँ ELB तर्फ ० को तौल देखाउँदै नयाँ प्रविष्टि थप्यौं। त्यसपछि हामीले प्रविष्टिको टाइम टु लाइभ (TTL) लाई ० मा सेट गर्यौं। यसपछि, पुरानो र नयाँ तौलहरू थिए। बिस्तारै समायोजन गरियो, र अन्ततः 0% लोड नयाँ सर्भरमा पठाइयो। स्विचिङ पूरा भएपछि, TTL मान थप पर्याप्त स्तरमा फर्कियो।

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

पाठ

नेटवर्क कपडा को सीमा

जनवरी 8, 2019 को बिहान सबेरै, Tinder प्लेटफर्म अप्रत्याशित रूपमा क्र्यास भयो। त्यो बिहान पहिले प्लेटफर्म विलम्बतामा असंबद्ध वृद्धिको प्रतिक्रियामा, क्लस्टरमा पोडहरू र नोडहरूको संख्या बढ्यो। यसले हाम्रो सबै नोडहरूमा एआरपी क्यास समाप्त भएको कारणले गर्दा।

एआरपी क्याससँग सम्बन्धित तीन लिनक्स विकल्पहरू छन्:

(स्रोत)

gc_thresh3 - यो कडा सीमा हो। लगमा "छिमेकी तालिका ओभरफ्लो" प्रविष्टिहरूको उपस्थितिको अर्थ सिंक्रोनस गार्बेज सङ्कलन (GC) पछि पनि छिमेकी प्रविष्टिहरू भण्डारण गर्न ARP क्यासमा पर्याप्त ठाउँ थिएन। यस अवस्थामा, कर्नेलले प्याकेटलाई पूर्ण रूपमा खारेज गर्यो।

हामी प्रयोग गर्छौ फ्ल्यानल Kubernetes मा नेटवर्क कपडा को रूप मा। प्याकेटहरू VXLAN मार्फत प्रसारित हुन्छन्। VXLAN L2 नेटवर्कको माथि उठाइएको L3 सुरुङ हो। टेक्नोलोजीले MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation प्रयोग गर्दछ र लेयर 2 नेटवर्क खण्डहरूको विस्तारलाई अनुमति दिन्छ। भौतिक डाटा केन्द्र नेटवर्कमा यातायात प्रोटोकल आईपी प्लस UDP हो।

चित्र २-१। फ्लानेल रेखाचित्र (स्रोत)

चित्र २-२। VXLAN प्याकेज (स्रोत)

प्रत्येक Kubernetes कार्यकर्ता नोडले ठूलो /24 ब्लकबाट /9 मास्कको साथ भर्चुअल ठेगाना स्पेस आवंटित गर्दछ। प्रत्येक नोडको लागि यो हो यसको अर्थ रूटिङ तालिकामा एउटा प्रविष्टि, एआरपी तालिकामा एउटा प्रविष्टि (फ्लानेल।१ इन्टरफेसमा), र स्विचिङ तालिका (FDB) मा एउटा प्रविष्टि। तिनीहरू पहिलो पटक कार्यकर्ता नोड सुरु हुँदा वा प्रत्येक पटक नयाँ नोड पत्ता लगाउँदा थपिन्छन्।

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

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

विफलताको समयमा, क्लस्टरमा 605 नोडहरू थिए। माथि उल्लेखित कारणहरूका लागि, यो महत्वलाई पार गर्न पर्याप्त थियो gc_thresh3, जुन पूर्वनिर्धारित हो। जब यो हुन्छ, प्याकेटहरू मात्र छोड्न सुरु गर्दैन, तर ARP तालिकाबाट /24 मास्कको साथ सम्पूर्ण फ्ल्यानेल भर्चुअल ठेगाना ठाउँ गायब हुन्छ। नोड-पोड संचार र DNS प्रश्नहरू अवरुद्ध छन् (DNS क्लस्टरमा होस्ट गरिएको छ; विवरणहरूको लागि यस लेखमा पछि पढ्नुहोस्)।

यो समस्या समाधान गर्न, तपाईं मान वृद्धि गर्न आवश्यक छ gc_thresh1, gc_thresh2 и gc_thresh3 र छुटेको नेटवर्कहरू पुन: दर्ता गर्न फ्ल्यानेल पुन: सुरु गर्नुहोस्।

अनपेक्षित DNS मापन

माइग्रेसन प्रक्रियाको क्रममा, हामीले ट्राफिक व्यवस्थापन गर्न र विस्तारै पुरानो पूर्वाधारबाट Kubernetes मा सेवाहरू स्थानान्तरण गर्न सक्रिय रूपमा DNS प्रयोग गर्यौं। हामीले Route53 मा सम्बन्धित RecordSets को लागि अपेक्षाकृत कम TTL मानहरू सेट गर्यौं। जब पुरानो पूर्वाधार EC2 उदाहरणहरूमा चलिरहेको थियो, हाम्रो समाधानकर्ता कन्फिगरेसनले Amazon DNS लाई औंल्यायो। हामीले यसलाई सामान्य रूपमा लिएका छौं र हाम्रा सेवाहरू र Amazon सेवाहरू (जस्तै DynamoDB) मा कम TTL को प्रभाव धेरै हदसम्म बेवास्ता गरियो।

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

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

समस्या स्रोत र गन्तव्य नेटवर्क ठेगाना अनुवाद (SNAT र DNAT) र त्यसपछि तालिकामा प्रविष्टिको चरणमा हुन्छ। कन्ट्राक। आन्तरिक रूपमा छलफल गरिएको र समुदायले सुझाव दिएको एक समाधान भनेको DNS लाई कार्यकर्ता नोडमा सार्नु थियो। यस मामला मा:

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

हामीले यो दृष्टिकोणमा अडिग रहने निर्णय गर्‍यौं। CoreDNS लाई Kubernetes मा डेमनसेटको रूपमा तैनाथ गरिएको थियो र हामीले स्थानीय नोड DNS सर्भरमा लागू गर्यौं। solve.conf झण्डा सेट गरेर प्रत्येक पोड --cluster-dns टोलीहरू कुबलेट । यो समाधान DNS टाइमआउटको लागि प्रभावकारी हुन पुग्यो।

यद्यपि, हामीले अझै पनि प्याकेट हानि र काउन्टरमा वृद्धि देख्यौं insert_failed फ्ल्यानेल इन्टरफेसमा। यो वर्कअराउन्ड लागू भएपछि जारी रह्यो किनभने हामीले DNS ट्राफिकको लागि मात्र SNAT र/वा DNAT हटाउन सक्षम थियौं। अन्य प्रकारका ट्राफिकहरूको लागि दौड अवस्थाहरू सुरक्षित गरिएको थियो। सौभाग्यवश, हाम्रा धेरैजसो प्याकेटहरू TCP हुन्, र यदि कुनै समस्या भयो भने तिनीहरू पुन: प्रसारण हुन्छन्। हामी अझै पनि सबै प्रकारका ट्राफिकहरूको लागि उपयुक्त समाधान खोज्ने प्रयास गरिरहेका छौं।

राम्रो लोड सन्तुलनको लागि दूत प्रयोग गर्दै

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

हामीले प्रयोग गरेको अर्को समाधान महत्वपूर्ण सेवाहरूको लागि कृत्रिम रूपमा संसाधन अनुरोधहरू बढाउनु थियो। यस अवस्थामा, नजिकै राखिएको पोडहरू अन्य भारी पोडहरूको तुलनामा म्यानुअल गर्नको लागि धेरै ठाउँ हुनेछ। यसले लामो समयसम्म काम गर्दैन किनभने यो स्रोतको बर्बादी हुनेछ। थप रूपमा, हाम्रो नोड अनुप्रयोगहरू एकल-थ्रेडेड थिए र, तदनुसार, केवल एक कोर प्रयोग गर्न सक्थे। एकमात्र वास्तविक समाधान राम्रो लोड सन्तुलन प्रयोग गर्न थियो।

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

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

सेवा अगाडि-दूतहरूले त्यसपछि एक अपस्ट्रीम क्लस्टर र मार्गको साथ यो सेवा खोज संयन्त्र प्रयोग गरे। हामीले पर्याप्त टाइमआउटहरू सेट गर्यौं, सबै सर्किट ब्रेकर सेटिङहरू बढाएका छौं, र एकल विफलताहरूमा मद्दत गर्न र सहज परिनियोजन सुनिश्चित गर्न न्यूनतम पुन: प्रयास कन्फिगरेसन थप्यौं। हामीले यी प्रत्येक सेवा फ्रन्ट-एन्भोजहरूको अगाडि एउटा TCP ELB राख्यौं। हाम्रो मुख्य प्रोक्सी लेयरबाट Keepalive केही Envoy पोडहरूमा अड्किएको भए पनि, तिनीहरू अझै पनि धेरै राम्रोसँग लोड ह्यान्डल गर्न सक्षम थिए र ब्याकइन्डमा न्यूनतम_request मार्फत सन्तुलन गर्न कन्फिगर गरिएको थियो।

परिनियोजनको लागि, हामीले दुबै एप्लिकेसन पोड र साइडकार पोडहरूमा प्रिस्टप हुक प्रयोग गर्यौं। हुकले साइडकार कन्टेनरमा रहेको एडमिन एन्डपोइन्टको स्थिति जाँच गर्नमा त्रुटि उत्पन्न गर्‍यो र सक्रिय जडानहरू बन्द गर्न अनुमति दिन केही समयको लागि सुत्न गयो।

हामीले यति चाँडै सार्न सक्षम भएका कारणहरू मध्ये एक विस्तृत मेट्रिक्सको कारण हो जुन हामीले सजिलैसँग एक विशिष्ट प्रोमेथियस स्थापनामा एकीकृत गर्न सक्षम थियौं। यसले हामीलाई कन्फिगरेसन प्यारामिटरहरू समायोजन गर्दा र ट्राफिक पुन: वितरण गर्दा के भइरहेको थियो भनेर हेर्न अनुमति दियो।

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

चित्र ३–१। दूतमा संक्रमणको समयमा एउटा सेवाको CPU अभिसरण

अन्तिम परिणाम

यस अनुभव र थप अनुसन्धानको माध्यमबाट, हामीले ठूला Kubernetes क्लस्टरहरूको डिजाइन, डिप्लोइङ र सञ्चालनमा बलियो सीपसहितको बलियो पूर्वाधार टोली निर्माण गरेका छौं। सबै टिन्डर इन्जिनियरहरूसँग अब कन्टेनरहरू प्याकेज गर्ने र Kubernetes मा अनुप्रयोगहरू प्रयोग गर्ने ज्ञान र अनुभव छ।

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

माइग्रेसनमा लगभग दुई वर्ष लाग्यो, तर हामीले यसलाई मार्च २०१९ मा पूरा गर्‍यौं। हाल, टिन्डर प्लेटफर्म 2019 सेवाहरू, 200 नोडहरू, 1000 पोडहरू र 15 चलिरहेको कन्टेनरहरू मिलेर कुबर्नेट्स क्लस्टरमा विशेष रूपमा चल्छ। पूर्वाधार अब सञ्चालन टोलीहरूको एकमात्र डोमेन छैन। हाम्रा सबै इन्जिनियरहरूले यो जिम्मेवारी साझा गर्छन् र कोड प्रयोग गरेर मात्र तिनीहरूको अनुप्रयोगहरू निर्माण र प्रयोग गर्ने प्रक्रियालाई नियन्त्रण गर्छन्।

अनुवादकबाट PS

हाम्रो ब्लगमा लेखहरूको श्रृंखला पनि पढ्नुहोस्:

• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 1: eBay बाट 4200 चूल्हा र TessMaster"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 2: सहमति र SAP"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 3: GitHub"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 4: साउन्डक्लाउड (प्रोमेथियस द्वारा)"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 5: डिजिटल बैंक Monzo"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 6: BlaBlaCar"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 7: BlackRock"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 8: Huawei"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 9: CERN र 210 K8s क्लस्टरहरू"।
• «Kubernetes उत्पादन मा सफलता कथाहरू। भाग 10: Reddit"।

स्रोत: www.habr.com