Kubernetes उत्पादन में सफलता की कहानियां। भाग 10: रेडिट

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



लिकबेज़ : आज तक, रेडिट एलेक्सा के अनुसार शीर्ष 20 वैश्विक साइटों (और अमेरिका में नंबर 6) पर है। अमेरिकी मूल के इस ऑनलाइन समुदाय में 400 मिलियन से अधिक सक्रिय (एक महीने के भीतर) उपयोगकर्ता, 12 मिलियन प्रकाशन और प्रति दिन 2 बिलियन वोट शामिल हैं।

Reddit इंजीनियर कुबेरनेट्स में क्यों और कैसे आए, इसके बारे में पिछले दिसंबर में KubeCon 2018 ( प्रेजेंटेशन + वीडियो ) ग्रेग टेलर, प्रोजेक्ट इंजीनियरिंग के रिलीज़ इंजीनियरिंग ग्रुप, इन्फ्रास्ट्रक्चर विभाग के प्रमुख थे।

आप कुबेरनेट्स में क्यों आए?

2016 की शुरुआत में, एक अखंड आवेदन के रूप में लागू की गई सेवा में केवल 20 इंजीनियर थे, जिन्होंने 3 टीमों का गठन किया, जिनमें से एक कहानी का एक प्रकार है - इंफ्रास्ट्रक्चर टीम। हालांकि, इस वर्ष में काफी बदलाव आए हैं: वर्ष के अंत तक, 60 से अधिक इंजीनियरों ने कंपनी में काम किया (और 2018 के अंत तक, उनकी संख्या बढ़कर 200 हो गई, यानी, केवल 3 वर्षों में, कर्मचारियों में 10 गुना वृद्धि हुई )।

इस तरह की तेजी से विकास दर ने एजेंडा को अखंड अनुप्रयोग वास्तुकला की अप्रासंगिकता (अक्षमता) पर रखा है, क्योंकि इसके विभिन्न घटकों (विभिन्न टीमों द्वारा) में कई बदलाव करना बहुत मुश्किल हो गया है। समस्या को हल करने और कई विकल्पों पर विचार करने के लिए एकत्रित होने के बाद, इंजीनियरों ने सेवा-उन्मुख वास्तुकला (SOA) का मार्ग चुना।

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

हालांकि, यह अभी भी एक अस्थायी समाधान था और अभ्यास से पता चला कि हर कोई अपनी सेवा के लिए पूरे स्टैक को संचालित नहीं करना चाहता था:



यह स्थिति कैसे हल हुई? संगठन ने सेवा मालिकों की अवधारणा पेश की, जो शुरू से अंत तक अपनी सेवा विकसित कर सकते थे, सेवा को जल्दी और अक्सर तैनात करते हैं, सेवा का संचालन करते हैं (इसकी उपलब्धता और प्रदर्शन के मुद्दों सहित)। लेकिन इसे कैसे प्राप्त किया जाए?

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

"इस विचार को व्यवहार में लाने के लिए, हमें अपने ज्ञान, प्रक्रिया, सर्वोत्तम प्रथाओं और बहुत कुछ और अधिक रूप में" पैक "करने की आवश्यकता है।"

InfreRedd - Reddit में कुबेरनेट्स

कुबेरनेट्स पर आधारित रेडिट के आंतरिक अवसंरचना उत्पाद InfreRedd के बारे में यह बताया गया।

उनकी परिभाषा में सेवा मालिकों की तीन जरूरतों को कैसे पूरा किया गया?

1. विकास

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

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

स्थानीय विकास में मदद करने के लिए, Reddit इंजीनियरों की पसंद Google उत्पाद पर गिर गई - स्केफोल्ड , जो डेवलपर्स को एक पढ़ने योग्य चक्र संपादित करता है → पुन: निर्माण → ताज़ा करें, जो:

• कुबेरनेट्स के गहन ज्ञान की आवश्यकता नहीं है;
• उत्पादन के जितना करीब हो सके;
• आप मानक चार्ट / छवियों का उपयोग करने की अनुमति देता है;
• और - मिनिक्यूब के विपरीत जो पहले इस्तेमाल किया गया था - स्कैफोल्ड के साथ काम करने के लिए काम करने वाले लैपटॉप से ​​भारी संसाधनों की आवश्यकता नहीं है (क्योंकि रोलआउट दूरस्थ समूहों के लिए किया जाता है)।

2. तैनात

Reddit परीक्षण चलाने और कलाकृतियों (आमतौर पर Docker छवियाँ) के निर्माण के लिए निरंतर वितरण मंच ड्रोन का उपयोग करता है।

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

परिणामस्वरूप, स्पिनर्कर को कुबेरनेट्स में तैनाती को ऑर्केस्ट्रेट करने के लिए चुना गया था। उसके लिए, विशिष्ट पाइपलाइनों के लिए टेम्पलेट बनाए गए थे (Jsonnet पर)। इसके बाद, हेल्म चार्ट तैयार किए जाते हैं, जो पहले से ही स्पिनरनर द्वारा कुबेरनेट में लुढ़का हुआ है। उपयोगकर्ता तैनाती की प्रगति के बारे में जानकारी प्राप्त करते हैं और किसी भी समस्या के मामले में निदान के लिए मदद करते हैं। यहाँ बताया गया है कि मंचन / उत्पादन में एक सामान्य तैनाती की प्रक्रिया बहुत सामान्य तरीके से होती है:

3. ऑपरेशन

सबसे पहले, सेवा मालिकों और बुनियादी ढांचे की टीम के दायित्वों को कैसे साझा किया जाता है?

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

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

ऑपरेशन का एक अन्य महत्वपूर्ण बिंदु संभावित नुकसान का कम से कम होना है जो विभिन्न स्रोतों से आ सकता है। इसके लिए Reddit क्या करता है:



ऑपरेशन में शामिल इंजीनियरों के लिए जीवन को आसान बनाने के लिए, निम्नलिखित भी शामिल हैं:

• वेवफ्रंट - मेट्रिक्स के लिए;
• पेजरडूट - अलर्ट के लिए;
• जिपकिन - अनुरेखण के लिए;
• संतरी - अपवाद और त्रुटियों को ट्रैक करने के लिए;
• केंद्रीकृत प्रवेश प्रणाली।

रेडिट में कुबेरनेट्स की स्थिति

पिछले साल दिसंबर के समय कुबेरनेट्स के बुनियादी ढांचे पर सामान्य आंकड़े इस प्रकार थे:

• 7 क्लस्टर (3 से 6 नए लोगों को अगले कुछ महीनों में जोड़ा जाना था);
• सभी इंजीनियरिंग टीमों की एक तिहाई से लेकर कुबेरनेट्स के साथ बातचीत;
• लगभग 20 रेडिट सेवाएं K8 के उत्पादन में हैं;
• कार्यदिवस पर, K8s को इन सेवाओं की 10-20 तैनाती होती है।

पूरे संगठन के लिए कुबेरनेट्स के साथ इन्फ्रारेड की उपलब्धता की योजना 2019 की पहली तिमाही के लिए बनाई गई थी, जिसने कुबेरनेट्स द्वारा उत्पादित उत्पादन में किसी भी नई सेवा की तैनाती को निहित किया था। (उस समय, यह लगभग 3 4 नई सेवाओं के लिए हो रहा था।)

जैसा कि लेख की शुरुआत में बताया गया है, यह मील का पत्थर पिछले सप्ताह ही सफलतापूर्वक पहुँचा था:

चक्र से अन्य लेख

• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 1: 4,200 श्रवण और ईबे पर टेसमास्टर । ”
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 2: कॉन्सुर और एसएपी । "
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 3: गिटहब । "
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 4: साउंडक्लाउड (लेखक प्रोमेथियस) । "
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 5: मोन्जो डिजिटल बैंक
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 6: BlaBlaCar । "
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 7: ब्लैकरॉक । "
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 8: हुआवेई । "
• “ कुबेरनेत्स उत्पादन में सफलता की कहानियाँ। भाग 9: CERN और 210 K8s क्लस्टर