Yandex.Cloud को लागि Kubernetes मा CSI ड्राइभर विकास गर्ने हाम्रो अनुभव

हामी यो घोषणा गर्न पाउँदा खुसी छौं कि Flant ले Kubernetes को लागि खुला स्रोत उपकरणहरू जारी गरेर आफ्नो योगदान विस्तार गर्दैछ। CSI चालकको अल्फा संस्करण Yandex.Cloud को लागि (कन्टेनर भण्डारण इन्टरफेस)।

तर कार्यान्वयन विवरणहरूमा जानु अघि, Yandex सँग पहिले नै सेवा भएको बेला यो किन आवश्यक छ भन्ने प्रश्नको जवाफ दिनुहोस्। Kubernetes को लागि व्यवस्थित सेवा.

परिचय

यो किन हो?

हाम्रो कम्पनी भित्र, उत्पादनमा Kubernetes प्रयोग गरेको सुरुदेखि नै (अर्थात धेरै वर्षदेखि), हामीले हाम्रो आफ्नै उपकरण (डेकहाउस) विकास गर्दै आएका छौं, जसलाई, हामी चाँडै नै खुला स्रोत परियोजनाको रूपमा उपलब्ध गराउने योजनामा ​​छौं। । यसको मद्दतले, हामीले हाम्रा सबै क्लस्टरहरूलाई समान रूपमा कन्फिगर र कन्फिगर गर्छौं, र हाल तिनीहरूमध्ये 100 भन्दा बढी छन्, विभिन्न प्रकारका हार्डवेयर कन्फिगरेसनहरूमा र सबै उपलब्ध क्लाउड सेवाहरूमा।

डेकहाउस प्रयोग गर्ने क्लस्टरहरूमा सञ्चालनको लागि आवश्यक सबै घटकहरू छन्: ब्यालेन्सरहरू, सुविधाजनक चार्टहरू, मेट्रिक्स र अलर्टहरू, सबै ड्यासबोर्डहरूमा पहुँचको लागि बाह्य प्रदायकहरू मार्फत प्रयोगकर्ता प्रमाणीकरण, र यस्तै अन्य। व्यवस्थित समाधानमा यस्तो "पम्प अप" क्लस्टर स्थापना गर्नुको कुनै मतलब छैन, किनकि यो प्रायः असम्भव हुन्छ वा कम्पोनेन्टहरूको आधा असक्षम गर्न आवश्यक हुन्छ।

NB: यो हाम्रो अनुभव हो, र यो एकदम विशिष्ट छ। हामी कुनै पनि हालतमा तयार समाधानहरू प्रयोग गर्नुको सट्टा सबैले कुबेरनेट क्लस्टरहरू आफ्नै रूपमा प्रयोग गर्नुपर्छ भनेर सुझाव दिइरहेका छैनौं। वैसे, हामीसँग Yandex बाट Kubernetes सञ्चालन गर्ने कुनै वास्तविक अनुभव छैन र हामी यस लेखमा यस सेवाको कुनै मूल्याङ्कन दिने छैनौं।

यो के हो र कसको लागि?

त्यसोभए, हामीले Kubernetes मा भण्डारणको लागि आधुनिक दृष्टिकोणको बारेमा कुरा गरिसकेका छौं: CSI कसरी काम गर्छ? и समुदाय कसरी आयो यस दृष्टिकोण को लागी।

हाल, धेरै ठूला क्लाउड सेवा प्रदायकहरूले आफ्नो क्लाउड डिस्कहरू Kubernetes मा Persistent Volume को रूपमा प्रयोग गर्नका लागि ड्राइभरहरू विकास गरेका छन्। यदि आपूर्तिकर्तासँग त्यस्तो ड्राइभर छैन, तर सबै आवश्यक कार्यहरू API मार्फत प्रदान गरिएको छ, त्यसपछि तपाईलाई ड्राइभर आफैं लागू गर्नबाट केहि पनि रोक्दैन। यो Yandex.Cloud को साथ भयो।

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

गरेको कामको नतिजा GitHub मा प्रकाशित र तिनीहरूका लागि उपयोगी हुन सक्छ जो, कुनै कारणले, Yandex.Cloud भर्चुअल मेसिनहरूमा आफ्नै Kubernetes स्थापना प्रयोग गर्छन् (तर तयार-निर्मित व्यवस्थित क्लस्टर होइन) र CSI मार्फत डिस्कहरू (अर्डर) प्रयोग गर्न चाहन्छन्।

कार्यान्वयन

मुख्य विशेषताहरू

हाल चालकले निम्न कार्यहरूलाई समर्थन गर्दछ:

• क्लस्टरमा नोडहरूको टोपोलोजी अनुसार क्लस्टरको सबै क्षेत्रहरूमा डिस्कहरू क्रमबद्ध गर्दै;
• पहिले अर्डर गरिएका डिस्कहरू हटाउँदै;
• डिस्कहरूको लागि अफलाइन रिसाइज (Yandex.Cloud समर्थन नगर्नुहोस् भर्चुअल मेसिनमा माउन्ट गरिएका डिस्कहरू बढाउँदै)। रिसाइजिङलाई सकेसम्म पीडारहित बनाउनको लागि चालकलाई कसरी परिमार्जन गरिएको थियो भन्ने जानकारीको लागि, तल हेर्नुहोस्।

भविष्यमा, हामी डिस्क स्न्यापसटहरू सिर्जना गर्न र मेटाउनको लागि समर्थन लागू गर्ने योजना बनाउँछौं।

मुख्य कठिनाई र यसलाई कसरी पार गर्ने

Yandex.Cloud API मा वास्तविक समयमा डिस्क बढाउने क्षमताको अभाव एक सीमा हो जसले PV (निरन्तर भोल्युम) को लागि रिसाइज अपरेशनलाई जटिल बनाउँछ: यस अवस्थामा, यो आवश्यक छ कि डिस्क प्रयोग गर्ने अनुप्रयोग पोड रोकियो, र यसले डाउनटाइम अनुप्रयोगहरू निम्त्याउन सक्छ।

अनुसार CSI विशिष्टताहरू, यदि CSI नियन्त्रकले रिपोर्ट गर्छ कि यसले डिस्कलाई "अफलाइन" मात्र रिसाइज गर्न सक्छ (VolumeExpansion.OFFLINE), त्यसपछि डिस्क बढाउने प्रक्रिया यसरी जानुपर्छ:

यदि प्लगइनसँग मात्र छ VolumeExpansion.OFFLINE विस्तार क्षमता र भोल्युम हाल प्रकाशित छ वा नोडमा उपलब्ध छ ControllerExpandVolume कुनै एक पछि मात्र कल गर्नुपर्छ:

• प्लगइनमा नियन्त्रक छ PUBLISH_UNPUBLISH_VOLUME क्षमता र ControllerUnpublishVolume सफलतापूर्वक आह्वान गरिएको छ।

वा अरू

• प्लगइनसँग नियन्त्रक छैन PUBLISH_UNPUBLISH_VOLUME क्षमता, प्लगइनसँग नोड छ STAGE_UNSTAGE_VOLUME क्षमता, र NodeUnstageVolume सफलतापूर्वक सम्पन्न भएको छ।

वा अरू

• प्लगइनसँग नियन्त्रक छैन PUBLISH_UNPUBLISH_VOLUME क्षमता, न नोड STAGE_UNSTAGE_VOLUME क्षमता, र NodeUnpublishVolume सफलतापूर्वक सम्पन्न गरेको छ।

यसको अनिवार्य अर्थ हो कि तपाईंले यसलाई विस्तार गर्नु अघि भर्चुअल मेसिनबाट डिस्कलाई अलग गर्न आवश्यक छ।

यद्यपि, दुर्भाग्यवश कार्यान्वयन साइडकारहरू मार्फत CSI विशिष्टताले यी आवश्यकताहरू पूरा गर्दैन:

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

हाम्रो केसमा (CSI प्लगइन), डिस्क बढाउने कार्य यस्तो देखिन्छ:

1. हामीले gRPC कल प्राप्त गर्छौं ControllerExpandVolume;
2. हामी API मा डिस्क बढाउने प्रयास गर्दैछौं, तर डिस्क माउन्ट भएकोले सञ्चालन गर्न असम्भवताको बारेमा हामीले त्रुटि प्राप्त गर्छौं;
3. हामी नक्सामा डिस्क पहिचानकर्ता भण्डार गर्छौं, जसमा डिस्कहरू समावेश हुन्छन् जसको लागि वृद्धि अपरेशन गर्न आवश्यक छ। तल, संक्षिप्तता को लागी, हामी यो नक्सा को रूपमा कल गर्नेछौं volumeResizeRequired;
4. म्यानुअल रूपमा डिस्क प्रयोग गरिरहेको पोड हटाउनुहोस्। Kubernetes यसलाई पुन: सुरु गर्नेछ। ताकि डिस्क माउन्ट गर्न समय छैन (ControllerPublishVolume) माउन्ट गर्ने प्रयास गर्दा वृद्धि अपरेशन पूरा गर्नु अघि, हामी जाँच गर्छौं कि दिइएको डिस्क अझै छ volumeResizeRequired र त्रुटि फिर्ता गर्नुहोस्;
5. CSI ड्राइभरले रिसाइज सञ्चालन पुन: कार्यान्वयन गर्ने प्रयास गर्छ। यदि अपरेशन सफल भयो भने, त्यसपछि डिस्कबाट हटाउनुहोस् volumeResizeRequired;
6. किनभने डिस्क ID बाट हराइरहेको छ 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 API सर्भर र kubelet को लागि;
• समावेश --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API सर्भर र kubelet को लागि;
• माउन्ट प्रसार (माउन्ट प्रसार) क्लस्टरमा सक्षम हुनुपर्छ। डकर प्रयोग गर्दा, साझा माउन्टहरूलाई अनुमति दिन डेमन कन्फिगर गरिनुपर्छ।

स्थापनाको लागि सबै आवश्यक चरणहरू README मा वर्णन गरिएको छ। स्थापनामा manifests बाट Kubernetes मा वस्तुहरू सिर्जना समावेश छ।

चालकले काम गर्नको लागि तपाईंलाई निम्न आवश्यक पर्दछ:

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

समग्रमा - प्रयास गर्नुहोस्, र हामी प्रतिक्रिया प्राप्त गर्न खुसी हुनेछौं र नयाँ मुद्दाहरूयदि तपाइँ कुनै समस्या सामना गर्नुहुन्छ भने!

थप समर्थन

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

थप रूपमा, Yandex सँग सम्भवतः यसको व्यवस्थित Kubernetes क्लस्टरमा CSI ड्राइभरको आफ्नै कार्यान्वयन छ, जुन खुला स्रोतमा जारी गर्न सकिन्छ। हामी यो विकास विकल्पलाई अनुकूलको रूपमा पनि देख्छौं - समुदायले सेवा प्रदायकबाट प्रमाणित चालक प्रयोग गर्न सक्षम हुनेछ, तेस्रो-पक्ष कम्पनीबाट होइन।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes भण्डारणको लागि भोल्युम प्लगइनहरू: Flexvolume देखि CSI सम्म»;
• «हामी कन्टेनर भण्डारण इन्टरफेस बुझ्छौं (कुबर्नेट्समा मात्र होइन)»;
• «के Kubernetes क्लस्टर तयार गर्न सजिलो र सुविधाजनक छ? एडअन-अपरेटर घोषणा गर्दै»;
• «Kubernetes को विस्तार र पूरक (अवलोकन र भिडियो रिपोर्ट)"।

स्रोत: www.habr.com