10 कारण [नहीं] k8 का उपयोग करें

आज हम कुबेरनेट्स के बारे में बात करेंगे, उस रैक के बारे में जो इसके व्यावहारिक उपयोग में एकत्र किया जा सकता है, और उन घटनाक्रमों के बारे में जो लेखक की मदद करते हैं और जिनसे आपको भी मदद मिलनी चाहिए। हम यह साबित करने की कोशिश करेंगे कि आधुनिक दुनिया में कहीं भी k8 के बिना। K8s के विरोधियों के लिए, हम उत्कृष्ट कारण भी प्रदान करते हैं कि आपको इसे क्यों स्विच नहीं करना चाहिए। यही है, कहानी में हम न केवल कुबेरनेट का बचाव करेंगे, बल्कि उसे डांटेंगे भी। यहाँ से नाम में यह आया [नहीं] ।

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





सबसे पहले, मैं संक्षेप में इस क्षेत्र पर जाऊंगा कि यह उपयोगी क्यों है और कई लोगों के लिए महत्वपूर्ण है, यह प्रचार क्यों होता है। फिर मैं आपको प्रौद्योगिकी का उपयोग करने के हमारे अनुभव के बारे में बताऊंगा। खैर, फिर निष्कर्ष।

इस लेख में, सभी स्लाइड्स को चित्रों के रूप में डाला गया है, लेकिन कभी-कभी आप कुछ कॉपी करना चाहते हैं। उदाहरण के लिए, कॉन्फ़िगर के साथ उदाहरण होंगे। पीडीएफ स्लाइड यहां से डाउनलोड की जा सकती हैं ।

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



तो, यह प्रचार आखिर क्यों हुआ, वाई। क्यूबर्नेट्स की तुलना में एक्स तकनीक बेहतर क्यों है, बिल्कुल यही प्रणाली है, और एक से अधिक कई हैं। पपेट, शेफ, अन्सिबल, बैश + एसएसएच, टेराफॉर्म हैं। मेरा पसंदीदा एसएसएच अब मेरी मदद कर रहा है, मुझे क्यों कहीं जाना चाहिए। मेरा मानना ​​है कि कई मापदंड हैं, लेकिन मैंने सबसे महत्वपूर्ण पर प्रकाश डाला।

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



मैं आपको कुबेरनेट्स का संक्षिप्त परिचय नहीं बताऊंगा, आप जानते हैं कि यह क्या है। मैं इन क्षेत्रों को थोड़ा और आगे बढ़ाऊंगा।

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

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



रिलीज डेवलपर्स के लिए, कई और अधिक फायदे हैं। सबसे पहले, यह एक अपरिवर्तनीय बुनियादी ढांचा है।

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

कुबेरनेट्स क्या नहीं है, और यह क्या करने की अनुमति नहीं देता है? इस संबंध में कई गलत धारणाएं हैं। कंटेनर से शुरू करते हैं। उनके ऊपर कुबेरनेत्स चलता है। कंटेनर हल्के आभासी मशीन नहीं हैं, लेकिन एक पूरी तरह से अलग इकाई है। इस अवधारणा की मदद से उन्हें समझाना आसान है, लेकिन वास्तव में यह गलत है। अवधारणा पूरी तरह से अलग है, इसे समझना और स्वीकार करना होगा।
दूसरे, Kubernetes एप्लिकेशन को अधिक सुरक्षित नहीं बनाता है। यह स्वचालित रूप से स्केलेबल नहीं बनाता है।

कुबेरनेट्स को शुरू करने के लिए आपको कड़ी मेहनत करने की आवश्यकता है, यह ऐसा नहीं होगा कि "एक बटन दबाया, और यह सभी स्वचालित रूप से काम करता है।" दुख होगा।


हमारा अनुभव। हम चाहते हैं कि आप और सभी लोग कुछ भी न तोड़ें। ऐसा करने के लिए, आपको और अधिक देखने की आवश्यकता है - और यहां हमारा पक्ष है।



सबसे पहले, कुबेरनेट्स अकेले नहीं जाते हैं। जब आप एक संरचना का निर्माण कर रहे हैं जो पूरी तरह से रिलीज और तैनाती का प्रबंधन करेगा, तो आपको यह समझना चाहिए कि कुबेरनेट्स एक पासा है, और 100 ऐसे पासे होने चाहिए। यह सब बनाने के लिए, आपको इसे पूरी मेहनत से अध्ययन करने की आवश्यकता है। शुरुआती जो आपके सिस्टम में आएंगे वे इस स्टैक का भी अध्ययन करेंगे, जानकारी का एक बड़ा हिस्सा।

कुबेरनेट्स एकमात्र महत्वपूर्ण ब्लॉक नहीं है, आसपास कई अन्य महत्वपूर्ण ब्लॉक हैं, जिसके बिना सिस्टम काम नहीं करेगा। यही है, आपको गलती सहिष्णुता के बारे में बहुत चिंता करने की आवश्यकता है।



इस वजह से, कुबेरनेट्स एक शून्य है। प्रणाली जटिल है, आपको बहुत ध्यान रखने की आवश्यकता है।



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





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



वास्तव में, प्रणाली बहुत जटिल है। एक प्रणाली, जो एक उच्च स्तर का अमूर्त होना चाहिए और सरल और अधिक समझने योग्य है, वास्तव में इसे समझना आसान नहीं है। इस माइनस के लिए।



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



आइए देखें कि यह कैसे काम करता है। यहां एक वास्तविक कॉन्फ़िगरेशन का एक उदाहरण है जो वर्तमान में उत्पादन में काम कर रहा है। हम यहाँ क्या देखते हैं?

सबसे पहले, हम देखते हैं कि एप्लिकेशन कहां लॉन्च किया जाए, दूसरा, लॉन्च करने की क्या जरूरत है, और तीसरा, इसे लॉन्च के लिए कैसे तैयार किया जाना चाहिए। एक बोतल में अवधारणाएं पहले से मिश्रित हैं।



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

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



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



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



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

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

एक प्रणाली जिसे वास्तव में सरल बनाना चाहिए वह जटिल है। मेरे लिए, यह एक स्पष्ट माइनस है। या तो कुछ और जोड़ने की जरूरत है, या उपयोग करने की नहीं



चलिए गहराई में जाते हैं, हम काफी गहरे नहीं हैं।



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

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

बहुत सारे परीक्षण हैं: प्रतिबद्ध रूप से, मर्ज करके, हर कोई एक समूह बनाता है, इसलिए क्लस्टर बस विशाल होते हैं।



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



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



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

दूसरे, यदि टीमों का द्रव्यमान, प्रत्येक की अपनी छवि है, तो वे बहुत और बहुत जल्दी जमा करते हैं। आप अपने डॉकर वितरण को मार सकते हैं। सफाई करना, छवियों को हटाना, उपयोगकर्ताओं के लिए जानकारी बनाना, कब और क्या आप साफ करेंगे, यह आवश्यक है।

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



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



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





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



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

मुझे उम्मीद नहीं थी कि जब यह चालू हो जाएगा, तो कैलिको राज्य में पहुंच जाएगा, और सब कुछ समस्याओं के बिना काम करता है।



उच्च उपलब्धता, जैसा कि मैंने कहा, हम kops के माध्यम से करते हैं, आप 5-7-9 नोड्स का उपयोग कर सकते हैं, हम तीन का उपयोग करते हैं। हम etcd v2 पर बैठे हैं, बग के कारण वे v3 पर अपडेट नहीं किए गए थे। सैद्धांतिक रूप से, यह कुछ प्रक्रियाओं को गति देगा। मुझे नहीं पता, मुझे संदेह है।



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





प्राधिकरण एक शाश्वत प्रश्न है। हम कुबेरनेट्स में RBAC, भूमिका-आधारित पहुंच का उपयोग करते हैं। यह एबीएसी से बहुत बेहतर है, और यदि आपने इसे कॉन्फ़िगर किया है, तो आप समझते हैं कि मेरा क्या मतलब है। कॉन्फ़िगरेशन देखें - आश्चर्यचकित हो।
हम Dex का उपयोग करते हैं, एक OpenID प्रदाता जो कुछ डेटा स्रोत से सभी जानकारी को पंप करता है।
और कुबेरनेट्स में लॉग इन करने के लिए, दो तरीके हैं। किसी भी तरह .kube / config में पंजीकृत होना आवश्यक है कि कहाँ जाना है और यह क्या कर सकता है। किसी तरह यह कॉन्फिगर करना जरूरी है। या उपयोगकर्ता यूआई में जाता है, जहां वह लॉग इन करता है, कॉन्फ़िगरेशन प्राप्त करता है, उन्हें / कॉन्फिगर करता है और काम करता है। यह बहुत सुविधाजनक नहीं है। हम धीरे-धीरे इस तथ्य पर चले गए कि एक व्यक्ति कंसोल में जाता है, बटन पर क्लिक करता है, लॉग इन करता है, कॉन्फ़िगर स्वचालित रूप से उससे उत्पन्न होता है और सही जगह पर स्टैक्ड होता है। इतना अधिक सुविधाजनक, हमने इस तरह से कार्य करने का निर्णय लिया।



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



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

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







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

बड़ा और मोटा प्लस, आपको बहुत सारी मुश्किल चीजें करने की अनुमति देता है।





स्केलिंग। आप Kubernetes के अंदर और Kubernetes के बाहर स्केलिंग नहीं मिला सकते हैं। कुबेरनेट्स के अंदर स्केलिंग खुद करता है। बड़ा लोड होने पर यह अपने आप फली बढ़ा सकता है।

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





जब आपके पास बहुत सारे उपयोगकर्ता और उपयोगकर्ता अनुप्रयोग हैं, तो आपको किसी तरह उन्हें मॉनिटर करने की आवश्यकता है। आमतौर पर यह टेलीमेट्री, लॉग, कुछ सुंदर ग्राफिक्स हैं।



ऐतिहासिक कारणों से, हमारे पास सेंसु था, यह कुबेरनेट्स के लिए बहुत उपयुक्त नहीं था। एक अधिक मीट्रिक उन्मुख परियोजना की आवश्यकता थी। हमने पूरे TICK स्टैक, विशेष रूप से InfluxDB को देखा। अच्छी UI, SQL जैसी भाषा, लेकिन पर्याप्त सुविधाएँ नहीं। हमने प्रोमेथियस पर स्विच किया।

वह अच्छा है। अच्छी क्वेरी भाषा, अच्छे अलर्ट और बॉक्स से बाहर सब कुछ।



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



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


अभी, सभी लॉग्स को stdout / stderr पर भेजा जाता है। सभी एप्लिकेशन इसके लिए डिज़ाइन किए गए हैं, इसलिए महत्वपूर्ण आवश्यकताओं में से एक यह है कि हम इस प्रणाली को नहीं छोड़ते हैं। Cernan ElasticSearch को डेटा भेजता है, पूरे Kubernetes सिस्टम की घटनाओं को Heapster का उपयोग करके वहां भेजा जाता है। यह एक बहुत अच्छी प्रणाली है, मैं सलाह देता हूं।

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





राज। हम S3 और KMS का उपयोग करते हैं। हम कुबेरनेट्स में वॉल्ट या रहस्यों पर स्विच करने के बारे में सोच रहे हैं। वे अल्फा राज्य में 1.7 में थे, लेकिन इसके साथ कुछ करने की आवश्यकता है।



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



इस दृष्टिकोण से नहीं कि सब कुछ बुरा है, लेकिन इस तथ्य से कि आपको चीजों को थोड़ा अलग ढंग से देखने की जरूरत है। मैं कुबेरनेट्स में कार्यात्मक प्रोग्रामिंग के साथ विकास की तुलना करता हूं: जब तक आप इसे नहीं छूते हैं, आप अपनी अनिवार्य शैली में सोचते हैं, सब कुछ ठीक है। कार्यात्मकता में विकसित करने के लिए, आपको अपने सिर को दूसरी तरफ थोड़ा मोड़ने की आवश्यकता है - यहां एक ही बात।

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

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

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

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





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

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


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

मैं मैकओएस पर काम करता हूं, मेरे पास एक मैक है, क्रमशः, एक स्थानीय ऐप चलाने के लिए, मुझे स्थानीय रूप से डॉक चलाने की आवश्यकता है। यह नहीं किया जा सकता है। अंत में, आपको या तो वर्चुअलबॉक्स या xhyve चलाने की आवश्यकता है। दोनों चीजें, वास्तव में, मेरे ऑपरेटिंग सिस्टम के शीर्ष पर उत्सर्जन हैं। हम xhyve का उपयोग करते हैं, लेकिन हम VirtualBox का उपयोग करने की सलाह देते हैं, क्योंकि बहुत सारे कीड़े हैं, उन्हें दरकिनार करना होगा।

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





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

सभी CI में सामान्य रूप से बहुत कम दस्तावेज हैं, आपको कोड पढ़ना होगा, और सामान्य तौर पर, हमने कॉनकोर्स को छोड़ दिया। हमने Drone.io पर स्विच किया - यह छोटा है, बहुत हल्का है, फुर्तीला है, कार्यक्षमता बहुत कम है, लेकिन अधिक बार यह पर्याप्त है। हां, बड़े और वज़न पर निर्भरता वाले ग्राफ़ रखना सुविधाजनक होगा, लेकिन आप छोटे लोगों पर भी काम कर सकते हैं। थोड़ा दस्तावेज भी, हम कोड पढ़ते हैं, लेकिन यह ठीक है।

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



यह एक साधारण ड्रोन कॉन्फिग का उदाहरण है। तैयार कार्य प्रणाली से लिया गया, इस मामले में पाइपलाइन में पांच चरण हैं, प्रत्येक चरण कुछ करता है: एकत्र करता है, परीक्षण करता है, और इसी तरह। उस फीचर सेट के साथ जो ड्रोन में है, मुझे लगता है कि यह एक अच्छी बात है।





हमने इस बारे में बहुत तर्क दिया कि कितने क्लस्टर हैं: एक या अधिक। जब हम कई समूहों के विचार के साथ आए, तो हमने इस दिशा में आगे काम करना शुरू किया, कुछ लिपियों का निर्माण किया, हमारे कुबेरनेट्स के लिए अन्य क्यूब्स का एक समूह बनाया। इसके बाद, वे Google पर आए और सलाह मांगी, क्या सभी ने ऐसा किया है, शायद कुछ को ठीक करने की आवश्यकता है।

Google ने सहमति व्यक्त की कि कुबेरनेट्स में एक भी क्लस्टर का विचार लागू नहीं है। कई खामियां हैं, विशेष रूप से, जियोलोकेशन के साथ काम करते हैं। यह पता चला कि यह विचार सत्य है, लेकिन इसके बारे में बात करना जल्दबाजी होगी। शायद बाद में। जबकि सर्विस मेश मदद कर सकता है।



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



हां, कुबेरनेट्स के साथ काम करने के हमारे अभ्यास में भी समस्याएं हैं।

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



चलो सभी विपक्ष की तरह हो।

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

कुबेरनेट्स आपके सिस्टम का सिर्फ एक छोटा सा हिस्सा होगा। हर कोई सोचता है कि वे कुबेरनेट्स स्थापित करेंगे, और सब कुछ तुरंत काम करेगा। नहीं, यह एक छोटा क्यूब है, और ऐसे कई क्यूब्स होंगे।

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

ये सभी विपक्ष निश्चित रूप से घृणित हैं।



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



पहला प्लस यह है कि समय के साथ, शुरुआती लोगों को कम सीखना होगा। अक्सर ऐसा होता है कि जब एक नवागंतुक सिस्टम में आता है, तो वह अपने सभी बालों को फाड़ना शुरू कर देता है, क्योंकि पहले 1-2 महीनों के लिए वह यह पता लगाने की कोशिश करता है कि यह सब कैसे करें, यदि सिस्टम बड़ा है और लंबे समय तक रहता है, तो कई वार्षिक रिंग बढ़े हैं। Kubernetes चीजों को आसान बनाता है।

दूसरे, कुबेरनेट्स स्वयं ऐसा नहीं करते हैं, लेकिन आपको एक छोटी रिलीज चक्र करने की अनुमति देते हैं। एक प्रतिबद्ध सीआई ने, सीआई ने एक छवि बनाई, स्वचालित रूप से पंप किया गया, आपने एक बटन दबाया, और सब कुछ उत्पादन में चला गया। यह रिलीज के समय को बहुत कम कर देता है।

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

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



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

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

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

यह सिस्टम की स्थिरता, और टीम के अंदर के मूड के लिए एक सुविधाजनक चीज है। हम "मोरल पुलिस" बनना बंद कर देते हैं, जो हमें देर रात को रिहा करने से रोकती है। वह करें जो आप चाहते हैं जबकि आपके पास गलतियों का एक अच्छा बजट है। यह कंपनी के भीतर तनाव को कम करता है।

मुझसे संपर्क करने के लिए, आप उपयोग कर सकते हैं ई-मेल या ट्विटर पर हमें लिखें: @gliush ।

और अंत में आपके लिए बहुत सारे लिंक हैं, आप खुद ही सब कुछ डाउनलोड और देख सकते हैं:

1. कंटेनर-नेटिव नेटवर्किंग - तुलना
   
2. जेज विनम्र, डेविड फार्ले द्वारा निरंतर वितरण।
   
3. कंटेनर VMs नहीं हैं
   
4. डॉकर वितरण (छवि रजिस्ट्री)
   
5. Quay - सेवा के रूप में छवि रजिस्ट्री
   
6. वल्ड-ऑपरेटर - एबर्ड क्लस्टर के प्रबंधक कुबेरनेट्स के ऊपर
   
7. डेक्स - ओपेनआईडी कनेक्ट आइडेंटिटी (ओआईडीसी) और ओयूथ 2.0 प्रोवाइडर प्लगएबल कनेक्टर्स के साथ
   
8. AWS क्रेडेंशियल प्रबंधित करने के लिए awsudo - sudo जैसी उपयोगिता
   
9. Autoscaling-related components for Kubernetes
   
10. Simon's cat
    
11. Helm: Kubernetes package manager
    
12. Geodesic: framework to create your own cloud platform
    
13. Calico: Configuring IP-in-IP
    
14. Sensu: Open-core monitoring system
    
15. InfluxDB: Scalable datastore for metrics, events, and real-time analytics
    
16. Cernan: Telemetry and logging aggregation server
    
17. Prometheus: Open Source monitoring solution
    
18. Heapster: Compute Resource Usage Analysis and Monitoring of Container Clusters
    
19. Stern: Multi pod and container log tailing for Kubernetes
    
20. Minikube: tool to run Kubernetes locally
    
21. Docker machine driver fox xhyve native OS X Hypervisor
    
22. Drone: Continuous Delivery platform built on Docker, written in Go
    
23. Borg, Omega and Kubernetes
    
24. Container-Native Networking — Comparison
    
25. Bug in minikube when working with xhyve driver.
    

विज्ञापन का मिनट। यदि आपको देवओप्स सम्मेलन से यह रिपोर्ट पसंद आई - ध्यान दें कि 14 अक्टूबर को सेंट पीटर्सबर्ग में नया देवओप्स 2018 आयोजित किया जाएगा, इसके कार्यक्रम में बहुत सारी दिलचस्प चीजें होंगी। साइट में पहले से ही स्पीकर और रिपोर्ट हैं।