कुबेरनेट्स आरक्षण: यह मौजूद है

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



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

हमने पहले बैकअप प्रक्रिया कैसे की थी? हमारे पास प्लेसमेंट के लिए समान प्लेटफ़ॉर्म थे - या तो वे वर्चुअल मशीन थे, या वे लोहे के सर्वर थे, जिसमें हमने तीन बुनियादी प्रथाओं को लागू किया था:

1. कोड सिंक्रनाइज़ेशन और स्टैटिक्स
2. कॉन्फ़िगरेशन सिंक्रनाइज़ेशन
3. डेटाबेस प्रतिकृति

और वसीला: किसी भी समय हम रिजर्व साइट पर स्विच करते हैं, हर कोई खुश है, हम उठते हैं, हम असहमत हैं।



और वे हमारे कुबेरनेट्स अनुप्रयोग की निरंतर उपलब्धता बढ़ाने के लिए हमें क्या प्रदान करते हैं? पहली बात यह है कि अनौपचारिक दस्तावेज़ीकरण कहता है कि बहुत सारी मशीनें लगाई जाएं, बहुत सारे स्वामी बनाएं - उनकी संख्या को क्लस्टर के भीतर एक कोरम प्राप्त करने के लिए शर्तों को पूरा करना होगा, और इसलिए कि स्वामी के प्रत्येक के लिए etcd, api, MC, अनुसूचक उठाए जाते हैं ... और, ऐसा लगता है, सब कुछ ठीक है : जब कई कामकाजी नोड्स या स्वामी विफल हो जाते हैं, तो हमारे क्लस्टर को फिर से चालू किया जाएगा और आवेदन काम करना जारी रखेगा। फिर से जादू सा लगता है! लेकिन अक्सर हमारा क्लस्टर एक ही डेटा सेंटर के भीतर स्थित होता है और इससे कुछ प्रश्न उत्पन्न हो सकते हैं। क्या होगा अगर एक खुदाई करने वाला आया और एक केबल को खोद दिया, बिजली गिरी, एक सार्वभौमिक बाढ़ थी? सब कुछ कवर किया गया है, हमारा क्लस्टर नहीं है। समस्या के इस पक्ष को ध्यान में रखते हुए आरक्षण कैसे प्राप्त करें?

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

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

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



लेकिन इंटरनेट से लोग हमें बैकअप क्लस्टर व्यवस्थित करने की पेशकश कैसे करते हैं? "क्यों?" के बाद दूसरा सबसे लोकप्रिय जवाब - कुबेरनेट्स फेडरेशन का उपयोग।

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

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

क्या किसी भी तरह एक क्यूबेर की बुकिंग की प्रक्रिया को सरल बनाना संभव है? हमारे पास कौन से उपकरण हैं?

सबसे पहले, हमारे पास हमेशा कुछ प्रकार की ci / cd प्रणाली होती है, अर्थात, हम मैन्युअल रूप से नहीं घूमते हैं, सर्वर पर क्रिएट / आवेदन नहीं लिखते हैं। सिस्टम हमारे कंटेनरों के लिए याम्लिक्स उत्पन्न करता है।

दूसरे, कई क्लस्टर हैं, हमारे पास या तो एक है, या कई (यदि हम स्मार्ट हैं) रजिस्ट्री, जिसे हमने लिया और आरक्षित किया। और एक अद्भुत कुबेकलेट उपयोगिता है जो एक साथ कई समूहों के साथ काम कर सकती है।



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

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

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

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

खैर, वास्तव में, इस सब से क्या निष्कर्ष निकाला जा सकता है?



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

या कल्पना कीजिए कि अमेज़ॅन को रूस में प्रतिबंधित किया गया था (और वह था)। और सभी: इस तथ्य की भावना कि एक और अमेज़ॅन हमारे रिजर्व में है? यह भी अनुपलब्ध है। इसलिए मैं दोहराता हूं: हम रिजर्व को कम से कम एक और डीसी में रखते हैं, और अधिमानतः दूसरे होस्ट के साथ।

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

और अंत में: मैं "घन" से प्यार करता हूं, साथ ही साथ इसके साथ प्रयोग भी करता हूं। मैं इन प्रयोगों के परिणामों को साझा करना पसंद करता हूं और सामान्य तौर पर, मेरा व्यक्तिगत अनुभव। इसलिए, मैंने विवरणों के लिए हमारे YouTube चैनल में K8 के बारे में वेबिनार की एक श्रृंखला दर्ज की।