📩 🖖🏿 🤶🏿 "चलो कुबेरनेट का उपयोग करें!" अब आपको 8 समस्याएं हैं ⌚️ 🧙🏾 👩🏾‍💼

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

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

हर कोई "चलती भागों" को पसंद करता है

कुबेरनेट्स बहुत आगे बढ़ रहा है और बदल रहा है: अवधारणाएं, सबसिस्टम, प्रक्रियाएं, मशीनें, कोड ... और यह सब बहुत कठिनाइयों का मतलब है।

कई कारें

कुबेरनेट्स एक वितरित प्रणाली है: इसमें एक मेजबान मशीन है जो बाकी श्रमिकों को नियंत्रित करती है। प्रत्येक मशीन कंटेनरों में काम करती है।
तो, हम पहले से ही कम से कम दो भौतिक या आभासी मशीनों के बारे में बात कर रहे हैं, जो केवल इसे काम करने के लिए आवश्यक हैं। लेकिन वास्तव में आपको मिलता है ... सिर्फ एक कार। यदि आप पैमाने पर जा रहे हैं (यह वह जगह है जहाँ कुत्ते को दफनाया गया है!), तो आपको तीन, चार, या शायद सत्तर आभासी मशीनों की आवश्यकता होगी।

बहुत, बहुत कोड

मार्च 2020 की शुरुआत में कुबेरनेट्स कोड बेस में गो पर 580,000 से अधिक कोड शामिल हैं। और यह केवल साफ कोड है, टिप्पणियों, रिक्त लाइनों और विक्रेता पैकेजों को छोड़कर। 2019 सुरक्षा समीक्षा में कोड आधार का वर्णन इस प्रकार है:
“कुबेरनेट्स कोड आधार में सुधार के लिए महत्वपूर्ण जगह है। यह बड़ा और जटिल है, इसमें न्यूनतम प्रलेखन के साथ कोड के बड़े हिस्से और बड़ी संख्या में निर्भरता शामिल हैं, जिसमें सिस्टम शामिल हैं जो कुबेरनेट्स का हिस्सा नहीं हैं। कोड आधार में भी तर्क के पुन: कार्यान्वयन के कई मामले हैं जो सहायक पुस्तकालयों में केंद्रीकृत हो सकते हैं, जो जटिलता को कम करेगा, सुधार को सरल करेगा और कोड आधार के विभिन्न क्षेत्रों में दस्तावेज़ भार को कम करेगा। ”
ईमानदार होने के लिए, कई अन्य बड़ी परियोजनाओं के बारे में भी यही कहा जा सकता है, लेकिन यदि आप अपने आवेदन को विफल नहीं करना चाहते हैं तो यह सभी कोड सही ढंग से काम करना चाहिए।

वास्तुकला, संचालन, विन्यास और वैचारिक जटिलता

कुबेरनेट्स एक व्यापक प्रणाली है जिसमें कई अलग-अलग सेवाओं, प्रणालियों और बहुत कुछ है।
इससे पहले कि आप अपने एकमात्र आवेदन को लॉन्च कर सकें, आपको निम्नलिखित, बहुत सरलीकृत वास्तुकला प्रदान करना होगा (मूल छवि को कुबेरनेट दस्तावेज़ीकरण से लिया गया है):

K8s अवधारणा प्रलेखन में कई विशुद्ध रूप से "शैक्षिक" चीजें शामिल हैं, जैसे कि निम्न स्निपेट:

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

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

और - हाँ, ज्यादातर समय आप इन सभी सुविधाओं का उपयोग नहीं करेंगे। इसलिए, अधिकांश समय आपको कुबेरनेट की आवश्यकता नहीं होगी।

यहाँ एक और यादृच्छिक स्निपेट है:

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

यहाँ सुरक्षा समीक्षा इस बारे में क्या कहती है:

Kubernetes — , . , Kubernetes — , , , .

कुबेरनेट्स में आपको जितना अधिक मिलता है, उतना ही सामान्य विकास प्रक्रिया कठिन हो जाती है: आपको इन सभी अवधारणाओं (पोड, परिनियोजन, सेवा, आदि) की आवश्यकता है बस अपने कोड को बनाने के लिए। इस प्रकार, आपको एक पूर्ण मशीन K8s को बढ़ावा देने की जरूरत है, यहां तक कि एक आभासी मशीन या नेस्टेड डॉकर कंटेनरों के माध्यम से परीक्षण के लिए भी।

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

आप कर सकते हैं कोई भी विकल्प चुनें, लेकिन उनमें से कोई भी सही नहीं होगा। कुबेरनेट्स का उपयोग न करने का सबसे आसान तरीका।

माइक्रोसर्विसेस (यह एक बुरा विचार है)

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

वितरित एप्लिकेशन डीबग करना कठिन हैं। आपको पूरी तरह से नए प्रकार के डिबगिंग और लॉगिंग टूल की आवश्यकता होगी, जो आपको अभी भी एक अखंड एप्लिकेशन के लॉग से कम देगा।

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

यदि आपकी पूरी टीम में 5 लोग शामिल हैं, तो आपके पास 20 माइक्रोसेर्विस हैं और राजसी परिस्थितियों को मजबूर करने के लिए आपको एक वितरित प्रणाली बनाने के लिए मजबूर नहीं किया जाता है, तो कहीं आप मिसकॉल करते हैं। 5 लोगों के बजाय प्रति 1 माइक्रोसेवा, बड़ी कंपनियों में, आपको 0.25 लोग मिलते हैं।

Kubernetes बिल्कुल उपयोगी नहीं है?

स्केलिंग

यदि आपको गंभीर स्केलेबिलिटी की आवश्यकता है तो कुबेरनेट काम में आ सकता है। हालाँकि, आइए देखें कि आपके पास क्या विकल्प हैं:

आप क्लाउड में VMs खरीद सकते हैं, और उनके पास 416 तक का वर्चुअल CPU और 8 TB RAM होगा, यानी पूरी तरह से अप्रभावी शक्ति। यह आपको एक बहुत पैसा खर्च करेगा, लेकिन ऐसा करना बेहद सरल होगा।
कई सरल वेब अनुप्रयोगों को हर्कोक जैसी सेवाओं के साथ काफी आसान तरीके से बढ़ाया जा सकता है।

यह माना जाता है कि, काम करने वाले वीएम की संख्या में वृद्धि भी आपके हाथों में खेली जाएगी:

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

विश्वसनीयता

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

यदि आप विशेष रूप से डाउनटाइम के बारे में चिंतित हैं, तो पहले सोचा था कि आपको यात्रा नहीं करनी चाहिए "मैं 1 सेकंड से 1 मिलीसेकंड तक तैनात करते समय डाउनटाइम कैसे कम करूं), लेकिन यह होना चाहिए" मैं कैसे सुनिश्चित करूं कि डेटाबेस स्कीमा में परिवर्तन रोलबैक की अनुमति देता है यदि मैं कहीं और? ”
और अगर आपको विफलता के बिंदु के रूप में एक मशीन के बिना विश्वसनीय वेब श्रमिकों की आवश्यकता है, तो कुबेरनेट्स के बिना इसे लागू करने के कई तरीके हैं।

सबसे अच्छा अभ्यास?

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

जब तक आप इन सभी जटिलताओं के लिए तत्काल आवश्यकता महसूस नहीं करते हैं, तो आपके पास ऐसे उपकरणों का एक विस्तृत चयन होता है जो आपकी समस्याओं को हल करेंगे: एक मशीन के लिए डॉकर कंपोज़, ऑर्केस्ट्रेशन के लिए हैशिकॉर्प की घुमक्कड़ , हेरोकू और स्केलिंग के लिए समान सिस्टम, और कंप्यूटिंग पाइपलाइनों के लिए शकेमेक जैसी चीज ।

बाद में संपादक से

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

"चलो कुबेरनेट का उपयोग करें!" अब आपको 8 समस्याएं हैं