टिंडरचे कुबर्नेट्समध्ये संक्रमण

नोंद. अनुवाद: जगप्रसिद्ध टिंडर सेवेच्या कर्मचार्‍यांनी अलीकडेच त्यांच्या पायाभूत सुविधा कुबेरनेटमध्ये स्थलांतरित करण्याचे काही तांत्रिक तपशील शेअर केले आहेत. या प्रक्रियेला जवळजवळ दोन वर्षे लागली आणि परिणामी K8s वर 200 हजार कंटेनरवर होस्ट केलेल्या 48 सेवांचा समावेश असलेला एक अतिशय मोठ्या प्रमाणात प्लॅटफॉर्म लॉन्च झाला. टिंडर अभियंत्यांना कोणत्या मनोरंजक अडचणी आल्या आणि त्यांचे काय परिणाम झाले? हे भाषांतर वाचा.

का?

जवळजवळ दोन वर्षांपूर्वी, टिंडरने त्याचे प्लॅटफॉर्म कुबेरनेटमध्ये हलवण्याचा निर्णय घेतला. कुबर्नेट्स टिंडर टीमला अपरिवर्तनीय तैनातीद्वारे कमीतकमी प्रयत्नांसह कंटेनर बनविण्यास आणि उत्पादनाकडे जाण्याची परवानगी देईल (अपरिवर्तनीय तैनाती). या प्रकरणात, अनुप्रयोगांची असेंब्ली, त्यांची तैनाती आणि पायाभूत सुविधा स्वतःच कोडद्वारे विशिष्टपणे परिभाषित केल्या जातील.

आम्ही स्केलेबिलिटी आणि स्थिरतेच्या समस्येवर उपाय शोधत होतो. जेव्हा स्केलिंग गंभीर बनले, तेव्हा आम्हाला नवीन EC2 उदाहरणे फिरण्यासाठी अनेक मिनिटे प्रतीक्षा करावी लागली. कंटेनर लाँच करणे आणि मिनिटांऐवजी काही सेकंदात वाहतूक सुरू करणे ही कल्पना आम्हाला खूप आकर्षक वाटली.

प्रक्रिया कठीण असल्याचे दिसून आले. 2019 च्या सुरुवातीला आमच्या स्थलांतरादरम्यान, कुबर्नेट्स क्लस्टर गंभीर प्रमाणात पोहोचला आणि आम्हाला रहदारीचे प्रमाण, क्लस्टर आकार आणि DNS मुळे विविध समस्यांना सामोरे जावे लागले. वाटेत, आम्ही 200 सेवा स्थलांतरित करणे आणि 1000 नोड्स, 15000 पॉड्स आणि 48000 रनिंग कंटेनर्स असलेल्या कुबर्नेट्स क्लस्टरची देखभाल करण्याशी संबंधित अनेक मनोरंजक समस्यांचे निराकरण केले.

कसे?

जानेवारी 2018 पासून, आम्ही स्थलांतराच्या विविध टप्प्यांतून गेलो आहोत. आम्ही आमच्या सर्व सेवांचे कंटेनरीकरण करून आणि त्यांना Kubernetes चाचणी क्लाउड वातावरणात तैनात करून सुरुवात केली. ऑक्टोबरपासून, आम्ही सर्व विद्यमान सेवा Kubernetes मध्ये पद्धतशीरपणे स्थलांतरित करण्यास सुरुवात केली. पुढील वर्षाच्या मार्चपर्यंत, आम्ही स्थलांतर पूर्ण केले आणि आता टिंडर प्लॅटफॉर्म केवळ कुबर्नेट्सवर चालतो.

Kubernetes साठी प्रतिमा तयार करणे

आमच्याकडे कुबर्नेट्स क्लस्टरवर चालणार्‍या मायक्रो सर्व्हिसेससाठी 30 हून अधिक स्त्रोत कोड रेपॉजिटरीज आहेत. या रेपॉजिटरीजमधील कोड एकाच भाषेसाठी एकाधिक रनटाइम वातावरणासह वेगवेगळ्या भाषांमध्ये (उदाहरणार्थ, Node.js, Java, Scala, Go) लिहिलेला आहे.

बिल्ड सिस्टम प्रत्येक मायक्रो सर्व्हिससाठी पूर्णपणे सानुकूल करण्यायोग्य "बिल्ड संदर्भ" प्रदान करण्यासाठी डिझाइन केले आहे. यात सहसा डॉकरफाइल आणि शेल कमांडची सूची असते. त्यांची सामग्री पूर्णपणे सानुकूल करण्यायोग्य आहे आणि त्याच वेळी, हे सर्व बिल्ड संदर्भ प्रमाणित स्वरूपानुसार लिहिलेले आहेत. मानकीकरण बिल्ड संदर्भ सर्व मायक्रोसर्व्हिसेस हाताळण्यासाठी एक सिंगल बिल्ड सिस्टमला अनुमती देते.

आकृती 1-1. बिल्डर कंटेनरद्वारे प्रमाणित बिल्ड प्रक्रिया

रनटाइम दरम्यान जास्तीत जास्त सुसंगतता प्राप्त करण्यासाठी (रनटाइम वातावरण) विकास आणि चाचणी दरम्यान समान बिल्ड प्रक्रिया वापरली जाते. आम्हाला एक अतिशय मनोरंजक आव्हानाचा सामना करावा लागला: संपूर्ण प्लॅटफॉर्मवर बिल्ड वातावरणाची सुसंगतता सुनिश्चित करण्यासाठी आम्हाला एक मार्ग विकसित करावा लागला. हे साध्य करण्यासाठी, सर्व असेंब्ली प्रक्रिया एका विशेष कंटेनरमध्ये केल्या जातात. बिल्डर.

त्याच्या कंटेनर अंमलबजावणीसाठी प्रगत डॉकर तंत्र आवश्यक होते. बिल्डरला स्थानिक वापरकर्ता आयडी आणि गुप्तता (जसे की SSH की, AWS क्रेडेन्शियल्स इ.) खाजगी टिंडर रिपॉझिटरीजमध्ये प्रवेश करण्यासाठी आवश्यक आहे. हे नैसर्गिकरित्या बिल्ड आर्टिफॅक्ट्स संचयित करण्यासाठी स्त्रोत असलेल्या स्थानिक निर्देशिका माउंट करते. हा दृष्टीकोन कार्यप्रदर्शन सुधारतो कारण ते बिल्डर कंटेनर आणि होस्ट यांच्यातील बिल्ड आर्टिफॅक्ट्स कॉपी करण्याची आवश्यकता काढून टाकते. संग्रहित बिल्ड आर्टिफॅक्ट्स अतिरिक्त कॉन्फिगरेशनशिवाय पुन्हा वापरल्या जाऊ शकतात.

काही सेवांसाठी, रनटाइम वातावरणात संकलन वातावरण मॅप करण्यासाठी आम्हाला दुसरा कंटेनर तयार करावा लागला (उदाहरणार्थ, Node.js bcrypt लायब्ररी इंस्टॉलेशन दरम्यान प्लॅटफॉर्म-विशिष्ट बायनरी आर्टिफॅक्ट्स व्युत्पन्न करते). संकलन प्रक्रियेदरम्यान, सेवांमध्ये आवश्यकता भिन्न असू शकतात आणि अंतिम डॉकरफाइल फ्लायवर संकलित केली जाते.

कुबर्नेट्स क्लस्टर आर्किटेक्चर आणि स्थलांतर

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

आम्ही वापरण्याचे ठरविले kube-aws Amazon EC2 उदाहरणांवर स्वयंचलित क्लस्टर उपयोजनासाठी. अगदी सुरुवातीस, सर्व काही नोड्सच्या एका सामान्य पूलमध्ये कार्य करते. संसाधनांचा अधिक कार्यक्षम वापर करण्यासाठी आकार आणि उदाहरणाच्या प्रकारानुसार वर्कलोड वेगळे करण्याची गरज आम्हाला त्वरीत लक्षात आली. लॉजिक असे होते की अनेक लोडेड मल्टी-थ्रेडेड पॉड्स चालवणे हे त्यांच्या मोठ्या संख्येने सिंगल-थ्रेडेड पॉड्ससह सहअस्तित्वापेक्षा कार्यक्षमतेच्या दृष्टीने अधिक अंदाजे ठरले.

शेवटी आम्ही यावर सेटल झालो:

• m5.4x मोठा - देखरेखीसाठी (प्रोमेथियस);
• c5.4x मोठा - Node.js वर्कलोडसाठी (एकल-थ्रेडेड वर्कलोड);
• c5.2x मोठा - जावा आणि गो (मल्टीथ्रेडेड वर्कलोड) साठी;
• c5.4x मोठा - नियंत्रण पॅनेलसाठी (3 नोड्स).

स्थलांतर

जुन्या पायाभूत सुविधांमधून कुबर्नेट्समध्ये स्थलांतरित करण्याच्या तयारीच्या पायऱ्यांपैकी एक म्हणजे सेवांमधील विद्यमान थेट संप्रेषण नवीन लोड बॅलन्सर्स (इलॅस्टिक लोड बॅलन्सर्स (ELB) कडे पुनर्निर्देशित करणे. ते आभासी खाजगी क्लाउड (VPC) च्या विशिष्ट सबनेटवर तयार केले गेले. हे सबनेट Kubernetes VPC शी जोडलेले होते. यामुळे आम्हाला सेवा अवलंबनांच्या विशिष्ट क्रमाचा विचार न करता हळूहळू मॉड्यूल्स स्थलांतरित करण्याची परवानगी मिळाली.

प्रत्येक नवीन ELB कडे निर्देश करणारे CNAME असलेले DNS रेकॉर्डचे भारित संच वापरून हे एंडपॉइंट तयार केले गेले. स्विच ओव्हर करण्यासाठी, आम्ही कुबर्नेट्स सेवेच्या नवीन ELB कडे निर्देश करणारी एक नवीन एंट्री जोडली ज्याचे वजन 0 होते. त्यानंतर आम्ही सेट केलेल्या एंट्रीचा टाइम टू लाइव्ह (TTL) 0 वर सेट केला. त्यानंतर, जुने आणि नवीन वजन हळूहळू समायोजित केले, आणि अखेरीस 100% भार नवीन सर्व्हरवर पाठविला गेला. स्विचिंग पूर्ण झाल्यानंतर, TTL मूल्य अधिक पुरेशा स्तरावर परत आले.

आमच्याकडे असलेले Java मॉड्यूल कमी TTL DNS सह सामना करू शकत होते, परंतु नोड अनुप्रयोग करू शकत नाहीत. एका अभियंत्याने कनेक्शन पूल कोडचा काही भाग पुन्हा लिहिला आणि तो व्यवस्थापकामध्ये गुंडाळला जो दर 60 सेकंदांनी पूल अद्यतनित करतो. निवडलेला दृष्टीकोन खूप चांगले कार्य करतो आणि कोणत्याही लक्षात येण्याजोग्या कामगिरीत घट न होता.

धडे

नेटवर्क फॅब्रिकच्या मर्यादा

8 जानेवारी 2019 च्या पहाटे, टिंडर प्लॅटफॉर्म अनपेक्षितपणे क्रॅश झाला. त्या सकाळी प्लॅटफॉर्म लेटन्सीमध्ये असंबंधित वाढीच्या प्रतिसादात, क्लस्टरमधील पॉड्स आणि नोड्सची संख्या वाढली. यामुळे आमच्या सर्व नोड्सवर ARP कॅशे संपुष्टात आली.

एआरपी कॅशेशी संबंधित तीन लिनक्स पर्याय आहेत:

(स्त्रोत)

gc_thresh3 - ही एक कठोर मर्यादा आहे. लॉगमध्ये "शेजारी टेबल ओव्हरफ्लो" एंट्री दिसल्याचा अर्थ असा होतो की सिंक्रोनस कचरा संकलन (GC) नंतरही, शेजारच्या एंट्री संचयित करण्यासाठी एआरपी कॅशेमध्ये पुरेशी जागा नव्हती. या प्रकरणात, कर्नलने पॅकेट पूर्णपणे टाकून दिले.

आम्ही वापरतो फ्लॅनेल Kubernetes मध्ये नेटवर्क फॅब्रिक म्हणून. पॅकेट VXLAN वर प्रसारित केले जातात. VXLAN हा L2 नेटवर्कच्या वर उभा केलेला L3 बोगदा आहे. तंत्रज्ञान MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation वापरते आणि लेयर 2 नेटवर्क विभागांच्या विस्तारास अनुमती देते. भौतिक डेटा सेंटर नेटवर्कवरील वाहतूक प्रोटोकॉल आयपी प्लस यूडीपी आहे.

आकृती 2-1. फ्लॅनेल आकृती (स्त्रोत)

आकृती 2-2. VXLAN पॅकेज (स्त्रोत)

प्रत्येक Kubernetes वर्कर नोड मोठ्या /24 ब्लॉकमधून /9 मास्कसह व्हर्च्युअल अॅड्रेस स्पेसचे वाटप करतो. प्रत्येक नोडसाठी हे आहे म्हणजे राउटिंग टेबलमध्ये एक एंट्री, एआरपी टेबलमध्ये एक एंट्री (फ्लानेल.1 इंटरफेसवर), आणि स्विचिंग टेबल (FDB) मध्ये एक एंट्री. प्रथमच वर्कर नोड सुरू झाल्यावर किंवा प्रत्येक वेळी नवीन नोड शोधल्यावर ते जोडले जातात.

याव्यतिरिक्त, नोड-पॉड (किंवा पॉड-पॉड) संवाद अंततः इंटरफेसमधून जातो eth0 (वरील फ्लॅनेल आकृतीमध्ये दर्शविल्याप्रमाणे). यामुळे प्रत्येक संबंधित स्रोत आणि गंतव्य होस्टसाठी ARP टेबलमध्ये अतिरिक्त एंट्री होते.

आपल्या वातावरणात, या प्रकारचे संप्रेषण खूप सामान्य आहे. Kubernetes मधील सेवा वस्तूंसाठी, एक ELB तयार केला जातो आणि Kubernetes प्रत्येक नोडची ELB सोबत नोंदणी करतो. ELB ला पॉड्सबद्दल काहीही माहिती नाही आणि निवडलेला नोड कदाचित पॅकेटचे अंतिम गंतव्यस्थान असू शकत नाही. मुद्दा असा आहे की जेव्हा नोडला ELB कडून एक पॅकेट प्राप्त होते, तेव्हा ते नियम विचारात घेते. iptables विशिष्ट सेवेसाठी आणि यादृच्छिकपणे दुसर्या नोडवर पॉड निवडते.

अपयशाच्या वेळी, क्लस्टरमध्ये 605 नोड होते. वर नमूद केलेल्या कारणांमुळे, हे महत्त्व दूर करण्यासाठी पुरेसे होते gc_thresh3, जे डीफॉल्ट आहे. जेव्हा हे घडते, तेव्हा केवळ पॅकेट्स सोडणे सुरू होत नाही, तर /24 मास्क असलेली संपूर्ण फ्लॅनेल व्हर्च्युअल अॅड्रेस स्पेस ARP टेबलमधून अदृश्य होते. नोड-पॉड संप्रेषण आणि DNS प्रश्नांमध्ये व्यत्यय आला आहे (DNS क्लस्टरमध्ये होस्ट केला आहे; तपशीलांसाठी या लेखात नंतर वाचा).

या समस्येचे निराकरण करण्यासाठी, आपल्याला मूल्ये वाढवणे आवश्यक आहे gc_thresh1, gc_thresh2 и gc_thresh3 आणि गहाळ नेटवर्कची पुन्हा नोंदणी करण्यासाठी फ्लॅनेल रीस्टार्ट करा.

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

स्थलांतर प्रक्रियेदरम्यान, आम्‍ही रहदारी व्‍यवस्‍थापित करण्‍यासाठी सक्रियपणे DNS चा वापर केला आणि हळुहळू सेवा जुन्या पायाभूत सुविधांमधून Kubernetes वर हस्तांतरित केली. आम्ही रूट 53 मधील संबंधित रेकॉर्डसेटसाठी तुलनेने कमी 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 कुबर्नेट्समध्ये डेमनसेट म्हणून तैनात केले होते आणि आम्ही स्थानिक नोड DNS सर्व्हर लागू केले solve.conf प्रत्येक पॉड एक ध्वज सेट करून --cluster-dns आज्ञा कुबेलेट . हा उपाय DNS टाइमआउटसाठी प्रभावी ठरला.

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

उत्तम भार संतुलनासाठी दूत वापरणे

जसजसे आम्ही बॅकएंड सेवा कुबर्नेट्समध्ये स्थलांतरित केल्या, आम्हाला पॉड्समधील असंतुलित लोडचा त्रास होऊ लागला. आम्हाला आढळले की HTTP Keepalive मुळे ELB कनेक्शन रोल आउट केलेल्या प्रत्येक तैनातीच्या पहिल्या तयार पॉड्सवर हँग होतात. अशा प्रकारे, मोठ्या प्रमाणात वाहतूक उपलब्ध पॉड्सच्या थोड्या टक्केवारीतून गेली. आम्ही चाचणी केलेला पहिला उपाय म्हणजे सर्वात वाईट परिस्थितींसाठी नवीन उपयोजनांवर MaxSurge 100% वर सेट करणे. मोठ्या तैनातीच्या दृष्टीने परिणाम नगण्य आणि आशाहीन असल्याचे दिसून आले.

आम्ही वापरलेला दुसरा उपाय म्हणजे गंभीर सेवांसाठी संसाधन विनंत्या कृत्रिमरित्या वाढवणे. या प्रकरणात, शेजारी ठेवलेल्या शेंगा इतर जड शेंगांच्या तुलनेत युक्तीसाठी अधिक जागा असतील. ते दीर्घकाळात काम करणार नाही कारण ते संसाधनांचा अपव्यय होईल. याव्यतिरिक्त, आमचे नोड अनुप्रयोग सिंगल-थ्रेडेड होते आणि त्यानुसार, फक्त एक कोर वापरू शकतात. उत्तम लोड बॅलन्सिंग वापरणे हा एकमेव खरा उपाय होता.

आम्ही बर्याच काळापासून पूर्णपणे प्रशंसा करू इच्छित होतो दूत. सध्याच्या परिस्थितीमुळे आम्हाला ते अत्यंत मर्यादित पद्धतीने उपयोजित करण्याची आणि त्वरित परिणाम मिळण्याची परवानगी मिळाली. दूत हा उच्च-कार्यक्षमता, मुक्त-स्रोत, मोठ्या SOA अनुप्रयोगांसाठी डिझाइन केलेला स्तर-XNUMX प्रॉक्सी आहे. हे प्रगत लोड बॅलन्सिंग तंत्र लागू करू शकते, ज्यामध्ये स्वयंचलित पुन्हा प्रयत्न करणे, सर्किट ब्रेकर्स आणि जागतिक दर मर्यादित करणे समाविष्ट आहे. (नोंद. अनुवाद: आपण याबद्दल अधिक वाचू शकता हा लेख Istio बद्दल, जे दूतावर आधारित आहे.)

आम्ही खालील कॉन्फिगरेशन घेऊन आलो: प्रत्येक पॉड आणि एकल मार्गासाठी एक दूत साइडकार घ्या आणि क्लस्टरला पोर्टद्वारे स्थानिकरित्या कंटेनरशी कनेक्ट करा. संभाव्य कॅस्केडिंग कमी करण्यासाठी आणि लहान हिट त्रिज्या राखण्यासाठी, आम्ही प्रत्येक सेवेसाठी एंवॉय फ्रंट-प्रॉक्सी पॉड्सचा एक फ्लीट वापरला, प्रत्येक उपलब्धता झोन (AZ) साठी. ते आमच्या एका अभियंत्याने लिहिलेल्या साध्या सेवा शोध इंजिनवर अवलंबून होते ज्याने दिलेल्या सेवेसाठी प्रत्येक AZ मधील पॉड्सची यादी फक्त परत केली.

सर्व्हिस फ्रंट-एंवॉय्सनी नंतर एका अपस्ट्रीम क्लस्टर आणि मार्गासह ही सेवा शोध यंत्रणा वापरली. आम्ही पुरेसा कालबाह्य सेट केला, सर्व सर्किट ब्रेकर सेटिंग्ज वाढवल्या आणि एकल अपयशांना मदत करण्यासाठी आणि सुरळीत तैनाती सुनिश्चित करण्यासाठी किमान पुन्हा प्रयत्न कॉन्फिगरेशन जोडले. आम्ही या प्रत्येक सर्व्हिस फ्रंट-एंवॉयच्या समोर एक TCP ELB ठेवला आहे. जरी आमच्या मुख्य प्रॉक्सी लेयरमधील Keepalive काही एन्वॉय पॉड्सवर अडकले असले तरीही ते लोड अधिक चांगल्या प्रकारे हाताळण्यास सक्षम होते आणि बॅकएंडमध्ये कमीतकमी_request द्वारे समतोल राखण्यासाठी कॉन्फिगर केले होते.

उपयोजनासाठी, आम्ही ऍप्लिकेशन पॉड्स आणि साइडकार पॉड्स या दोन्हींवर प्रीस्टॉप हुक वापरला. साइडकार कंटेनरवर असलेल्या अॅडमिन एंडपॉईंटची स्थिती तपासण्यात हुकने एरर आणली आणि सक्रिय कनेक्शन संपुष्टात आणण्यासाठी थोडा वेळ झोपी गेला.

आम्ही इतक्या लवकर हलवू शकलो याचे एक कारण म्हणजे तपशीलवार मेट्रिक्स जे आम्ही सामान्य प्रोमिथियस इंस्टॉलेशनमध्ये सहजपणे समाकलित करू शकलो. यामुळे आम्हाला कॉन्फिगरेशन पॅरामीटर्स आणि ट्रॅफिक पुनर्वितरित करताना नेमके काय घडत आहे ते पाहण्याची परवानगी मिळाली.

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

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

अंतिम निकाल

या अनुभवाद्वारे आणि अतिरिक्त संशोधनाद्वारे, आम्ही मोठ्या कुबर्नेट्स क्लस्टर्सची रचना, तैनाती आणि कार्यान्वित करण्यासाठी मजबूत कौशल्यांसह एक मजबूत पायाभूत सुविधा संघ तयार केला आहे. सर्व टिंडर अभियंत्यांकडे आता कंटेनर पॅकेज करण्याचे आणि कुबर्नेट्सवर अनुप्रयोग तैनात करण्याचे ज्ञान आणि अनुभव आहे.

जेव्हा जुन्या पायाभूत सुविधांवर अतिरिक्त क्षमतेची गरज निर्माण झाली तेव्हा नवीन EC2 उदाहरणे सुरू होण्यासाठी आम्हाला काही मिनिटे प्रतीक्षा करावी लागली. आता कंटेनर धावू लागतात आणि मिनिटांऐवजी सेकंदात रहदारीवर प्रक्रिया करण्यास सुरवात करतात. एकाच EC2 उदाहरणावर अनेक कंटेनर शेड्यूल केल्याने सुधारित क्षैतिज एकाग्रता देखील मिळते. परिणामी, आम्ही गेल्या वर्षीच्या तुलनेत 2019 मध्ये EC2 खर्चात लक्षणीय घट होण्याचा अंदाज वर्तवला आहे.

स्थलांतराला जवळपास दोन वर्षे लागली, परंतु आम्ही ते मार्च 2019 मध्ये पूर्ण केले. सध्या, टिंडर प्लॅटफॉर्म केवळ कुबर्नेट्स क्लस्टरवर चालतो ज्यामध्ये 200 सेवा, 1000 नोड्स, 15 पॉड्स आणि 000 रनिंग कंटेनर असतात. पायाभूत सुविधा हे यापुढे ऑपरेशन टीमचे एकमेव डोमेन राहिलेले नाही. आमचे सर्व अभियंते ही जबाबदारी सामायिक करतात आणि केवळ कोड वापरून त्यांचे अनुप्रयोग तयार आणि तैनात करण्याच्या प्रक्रियेवर नियंत्रण ठेवतात.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर लेखांची मालिका देखील वाचा:

• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 1: eBay कडून 4200 चूल आणि TessMaster».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 2: सहमत आणि SAP».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 3: GitHub».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 4: साउंडक्लाउड (प्रोमेथियस द्वारे)».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 5: डिजिटल बँक मोंझो».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 6: BlaBlaCar».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 7: काळा दगड».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 8: उलाढाल».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 9: CERN आणि 210 K8s क्लस्टर्स».
• «कुबर्नेट्सच्या उत्पादनातील यशोगाथा. भाग 10: पंचकर्म».

स्त्रोत: www.habr.com