Yandex.Cloud के लिए कुबेरनेट्स में CSI ड्राइवर विकसित करने का हमारा अनुभव

हमें यह घोषणा करते हुए खुशी हो रही है कि फ़्लैंट कुबेरनेट्स के लिए ओपन सोर्स टूल जारी करके अपने योगदान का विस्तार कर रहा है सीएसआई ड्राइवर का अल्फा संस्करण (कंटेनर स्टोरेज इंटरफ़ेस) Yandex.Cloud के लिए।

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

परिचय

ऐसा क्यों है?

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

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

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

यह क्या है और किसके लिए है?

इसलिए, हम पहले ही कुबेरनेट्स में भंडारण के आधुनिक दृष्टिकोण के बारे में बात कर चुके हैं: सीएसआई कैसे काम करता है? и समुदाय कैसे आया इस दृष्टिकोण के लिए.

वर्तमान में, कई बड़े क्लाउड सेवा प्रदाताओं ने कुबेरनेट्स में अपने क्लाउड डिस्क को पर्सिस्टेंट वॉल्यूम के रूप में उपयोग करने के लिए ड्राइवर विकसित किए हैं। यदि आपूर्तिकर्ता के पास ऐसा कोई ड्राइवर नहीं है, लेकिन सभी आवश्यक कार्य एपीआई के माध्यम से प्रदान किए जाते हैं, तो आपको ड्राइवर को स्वयं लागू करने से कोई नहीं रोकता है। Yandex.Cloud के साथ यही हुआ है।

हमने इसे विकास का आधार माना DigitalOcean क्लाउड के लिए CSI ड्राइवर और कुछ विचार जीसीपी के लिए ड्राइवर, चूंकि इन क्लाउड्स (Google और Yandex) के एपीआई के साथ इंटरेक्शन में कई समानताएं हैं। विशेष रूप से, एपीआई और जीसीपी, और Yandex किसी वस्तु को वापस करना Operation लंबे समय से चल रहे संचालन की स्थिति को ट्रैक करने के लिए (उदाहरण के लिए, एक नई डिस्क बनाना)। Yandex.Cloud API के साथ इंटरैक्ट करने के लिए, उपयोग करें यांडेक्स.क्लाउड गो एसडीके.

किये गये कार्य का परिणाम गिटहब पर प्रकाशित और उन लोगों के लिए उपयोगी हो सकता है, जो किसी कारण से, Yandex.Cloud वर्चुअल मशीनों (लेकिन रेडी-मेड प्रबंधित क्लस्टर नहीं) पर अपने स्वयं के Kubernetes इंस्टॉलेशन का उपयोग करते हैं और CSI के माध्यम से डिस्क का उपयोग (ऑर्डर) करना चाहते हैं।

कार्यान्वयन

मुख्य विशेषताएं

वर्तमान में ड्राइवर निम्नलिखित कार्यों का समर्थन करता है:

• क्लस्टर में नोड्स की टोपोलॉजी के अनुसार क्लस्टर के सभी क्षेत्रों में डिस्क को ऑर्डर करना;
• पहले से ऑर्डर की गई डिस्क को हटाना;
• डिस्क के लिए ऑफ़लाइन आकार बदलें (Yandex.Cloud समर्थन नहीं करते वर्चुअल मशीन पर माउंट की गई डिस्क को बढ़ाना)। आकार को यथासंभव दर्द रहित बनाने के लिए ड्राइवर को किस प्रकार संशोधित करना पड़ा, इसकी जानकारी के लिए नीचे देखें।

भविष्य में, हम डिस्क स्नैपशॉट बनाने और हटाने के लिए समर्थन लागू करने की योजना बना रहे हैं।

मुख्य कठिनाई और इसे कैसे दूर किया जाए

Yandex.Cloud API में वास्तविक समय में डिस्क को बढ़ाने की क्षमता की कमी एक ऐसी सीमा है जो PV (पर्सिस्टेंट वॉल्यूम) के लिए आकार बदलने के ऑपरेशन को जटिल बनाती है: इस मामले में, यह आवश्यक है कि डिस्क का उपयोग करने वाले एप्लिकेशन पॉड को रोक दिया जाए, और इससे एप्लिकेशन डाउनटाइम हो सकते हैं.

के अनुसार सीएसआई विशिष्टताएँ, यदि सीएसआई नियंत्रक रिपोर्ट करता है कि वह डिस्क का आकार केवल "ऑफ़लाइन" ही बदल सकता है (VolumeExpansion.OFFLINE), तो डिस्क को बढ़ाने की प्रक्रिया इस प्रकार होनी चाहिए:

यदि प्लगइन केवल है VolumeExpansion.OFFLINE विस्तार क्षमता और मात्रा वर्तमान में प्रकाशित है या किसी नोड पर उपलब्ध है ControllerExpandVolume इनमें से किसी एक के बाद ही बुलाया जाना चाहिए:

• प्लगइन में नियंत्रक है PUBLISH_UNPUBLISH_VOLUME क्षमता और ControllerUnpublishVolume सफलतापूर्वक लागू किया गया है.

वरना

• प्लगइन में नियंत्रक नहीं है PUBLISH_UNPUBLISH_VOLUME क्षमता, प्लगइन में नोड है STAGE_UNSTAGE_VOLUME क्षमता, और NodeUnstageVolume सफलतापूर्वक पूरा कर लिया गया है।

वरना

• प्लगइन में नियंत्रक नहीं है PUBLISH_UNPUBLISH_VOLUME क्षमता, न ही नोड STAGE_UNSTAGE_VOLUME क्षमता, और NodeUnpublishVolume सफलतापूर्वक पूरा हो गया है.

इसका अनिवार्य रूप से मतलब है कि आपको डिस्क को विस्तारित करने से पहले वर्चुअल मशीन से अलग करना होगा।

हालाँकि, दुर्भाग्य से कार्यान्वयन साइडकार के माध्यम से सीएसआई विनिर्देश इन आवश्यकताओं को पूरा नहीं करता है:

• एक साइडकार कंटेनर में csi-attacher, जो माउंट के बीच आवश्यक अंतर की उपस्थिति के लिए जिम्मेदार होना चाहिए, यह कार्यक्षमता ऑफ़लाइन आकार में लागू नहीं की जाती है। इसको लेकर चर्चा शुरू की गयी यहां.
• इस संदर्भ में साइडकार कंटेनर वास्तव में क्या है? सीएसआई प्लगइन स्वयं कुबेरनेट्स एपीआई के साथ इंटरैक्ट नहीं करता है, बल्कि केवल साइडकार कंटेनरों द्वारा भेजे गए जीआरपीसी कॉल का जवाब देता है। नवीनतम विकसित हो रहे हैं कुबेरनेट्स समुदाय द्वारा।

हमारे मामले में (सीएसआई प्लगइन), डिस्क को बढ़ाने का ऑपरेशन इस तरह दिखता है:

1. हमें एक जीआरपीसी कॉल प्राप्त होती है ControllerExpandVolume;
2. हम एपीआई में डिस्क को बढ़ाने का प्रयास कर रहे हैं, लेकिन हमें डिस्क माउंट होने के कारण ऑपरेशन करने की असंभवता के बारे में एक त्रुटि प्राप्त होती है;
3. हम डिस्क पहचानकर्ता को मानचित्र में संग्रहीत करते हैं, जिसमें वे डिस्क होती हैं जिनके लिए वृद्धि ऑपरेशन करने की आवश्यकता होती है। नीचे, संक्षिप्तता के लिए, हम इस मानचित्र को इस प्रकार कहेंगे volumeResizeRequired;
4. डिस्क का उपयोग करने वाले पॉड को मैन्युअल रूप से हटा दें। कुबेरनेट्स इसे पुनः आरंभ करेगा। ताकि डिस्क को माउंट होने का समय न मिले (ControllerPublishVolume) माउंट करने का प्रयास करते समय वृद्धि ऑपरेशन को पूरा करने से पहले, हम जांचते हैं कि दी गई डिस्क अभी भी अंदर है volumeResizeRequired और एक त्रुटि लौटाएँ;
5. CSI ड्राइवर आकार बदलने की कार्रवाई को पुन: निष्पादित करने का प्रयास करता है। यदि ऑपरेशन सफल रहा, तो डिस्क को हटा दें volumeResizeRequired;
6. क्योंकि डिस्क आईडी गायब है volumeResizeRequired, ControllerPublishVolume सफलतापूर्वक गुजरता है, डिस्क माउंट हो जाती है, पॉड प्रारंभ हो जाता है।

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

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

इसके परिणामस्वरूप समय-समय पर डिस्क विस्तार ऑपरेशन को 15+ मिनट तक बढ़ाया जा सकता है और, इस प्रकार, संबंधित पॉड अनुपलब्ध हो सकता है।

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

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

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

इसका उपयोग कैसे शुरू करें?

ड्राइवर Kubernetes संस्करण 1.15 और उच्चतर पर समर्थित है। ड्राइवर को काम करने के लिए निम्नलिखित आवश्यकताओं को पूरा करना होगा:

• झंडा --allow-privileged मान पर सेट करें true एपीआई सर्वर और क्यूबलेट के लिए;
• शामिल --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true एपीआई सर्वर और क्यूबलेट के लिए;
• माउंट प्रसार (माउंट प्रसार) क्लस्टर पर सक्षम होना चाहिए। डॉकर का उपयोग करते समय, साझा माउंट की अनुमति देने के लिए डेमॉन को कॉन्फ़िगर किया जाना चाहिए।

स्थापना के लिए सभी आवश्यक कदम README में वर्णित है. इंस्टालेशन में मेनिफेस्टों से कुबेरनेट्स में ऑब्जेक्ट बनाना शामिल है।

ड्राइवर के काम करने के लिए आपको निम्नलिखित की आवश्यकता होगी:

• मेनिफेस्ट में निर्देशिका पहचानकर्ता निर्दिष्ट करें (folder-id) यांडेक्स.क्लाउड (दस्तावेज़ देखें);
• Yandex.Cloud API के साथ इंटरैक्ट करने के लिए, CSI ड्राइवर एक सेवा खाते का उपयोग करता है। प्रकट में, रहस्य को पारित किया जाना चाहिए अधिकृत कुंजी सेवा खाते से. दस्तावेज़ीकरण में वर्णित, सेवा खाता कैसे बनाएं और चाबियाँ कैसे प्राप्त करें।

सब मिलाकर - कोशिश, और हमें प्रतिक्रिया प्राप्त करने में खुशी होगी और नये मुद्देयदि आपको कोई समस्या आती है!

आगे की सहायता

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

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

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

• «कुबेरनेट्स स्टोरेज के लिए वॉल्यूम प्लगइन्स: फ्लेक्सवॉल्यूम से सीएसआई तक";
• «हम कंटेनर स्टोरेज इंटरफ़ेस को समझते हैं (कुबेरनेट्स में और न केवल)";
• «क्या कुबेरनेट्स क्लस्टर तैयार करना आसान और सुविधाजनक है? ऐडऑन-ऑपरेटर की घोषणा";
• «कुबेरनेट्स का विस्तार और पूरक (समीक्षा और वीडियो रिपोर्ट)'.

स्रोत: www.habr.com