Yandex.Cloud साठी Kubernetes मध्ये CSI ड्राइव्हर विकसित करण्याचा आमचा अनुभव

आम्‍हाला हे जाहीर करताना आनंद होत आहे की फ्लॅंट कुबेर्नेट्ससाठी मुक्त स्रोत साधनांमध्‍ये आपले योगदान वाढवत आहे. CSI ड्राइव्हरची अल्फा आवृत्ती (कंटेनर स्टोरेज इंटरफेस) Yandex.Cloud साठी.

परंतु अंमलबजावणीच्या तपशीलांकडे जाण्यापूर्वी, यांडेक्समध्ये आधीपासूनच सेवा असताना याची आवश्यकता का आहे या प्रश्नाचे उत्तर द्या. Kubernetes साठी व्यवस्थापित सेवा.

परिचय

हे का?

आमच्या कंपनीमध्ये, उत्पादनामध्ये कुबर्नेट्स वापरण्याच्या अगदी सुरुवातीपासूनच (म्हणजेच आता अनेक वर्षांपासून), आम्ही आमचे स्वतःचे साधन (डेकहाऊस) विकसित करत आहोत, जे आम्ही लवकरच मुक्त स्रोत प्रकल्प म्हणून उपलब्ध करून देण्याची योजना आखत आहोत. . त्याच्या मदतीने, आम्ही आमचे सर्व क्लस्टर एकसमानपणे कॉन्फिगर आणि कॉन्फिगर करतो आणि सध्या त्यापैकी 100 हून अधिक हार्डवेअर कॉन्फिगरेशनच्या विविध प्रकारांवर आणि सर्व उपलब्ध क्लाउड सेवांमध्ये आधीपासूनच आहेत.

डेकहाऊस वापरणाऱ्या क्लस्टर्समध्ये ऑपरेशनसाठी आवश्यक असलेले सर्व घटक असतात: बॅलन्सर, सोयीस्कर चार्टसह मॉनिटरिंग, मेट्रिक्स आणि अॅलर्ट्स, सर्व डॅशबोर्ड्समध्ये प्रवेश करण्यासाठी बाह्य प्रदात्यांद्वारे वापरकर्ता प्रमाणीकरण इ. व्यवस्थापित सोल्यूशनमध्ये असे "पंप अप" क्लस्टर स्थापित करण्यात काही अर्थ नाही, कारण हे एकतर अशक्य आहे किंवा अर्धे घटक अक्षम करण्याची आवश्यकता निर्माण करेल.

NB: हा आमचा अनुभव आहे आणि तो अगदी विशिष्ट आहे. आम्ही कोणत्याही प्रकारे असे सुचवत नाही की प्रत्येकाने तयार-तयार उपाय वापरण्याऐवजी कुबर्नेट्स क्लस्टर्स स्वतःहून तैनात करावेत. तसे, आम्हाला Yandex वरून Kubernetes ऑपरेट करण्याचा कोणताही वास्तविक अनुभव नाही आणि आम्ही या लेखात या सेवेचे कोणतेही मूल्यांकन देणार नाही.

ते काय आणि कोणासाठी आहे?

तर, आम्ही कुबर्नेट्समधील स्टोरेजच्या आधुनिक दृष्टिकोनाबद्दल आधीच बोललो आहोत: CSI कसे काम करते? и समाज कसा आला या दृष्टिकोनाकडे.

सध्या, बर्‍याच मोठ्या क्लाउड सेवा प्रदात्यांनी त्यांच्या क्लाउड डिस्कचा वापर कुबर्नेट्समध्ये पर्सिस्टंट व्हॉल्यूम म्हणून करण्यासाठी ड्रायव्हर्स विकसित केले आहेत. जर पुरवठादाराकडे असा ड्रायव्हर नसेल, परंतु सर्व आवश्यक कार्ये API द्वारे प्रदान केली गेली असतील, तर ड्रायव्हर स्वतः लागू करण्यापासून काहीही प्रतिबंधित करत नाही. Yandex.Cloud सह असेच घडले.

आम्ही विकासाचा आधार घेतला DigitalOcean क्लाउडसाठी CSI ड्राइव्हर आणि कडून काही कल्पना GCP साठी ड्रायव्हर्स, या क्लाउड्सच्या API (Google आणि Yandex) सह परस्परसंवादात अनेक समानता आहेत. विशेषतः, API आणि जीसीपी, आणि y यांडेक्स ऑब्जेक्ट परत करा 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 कॉलला प्रतिसाद देते. नवीनतम विकसित केले जात आहेत कुबर्नेट्स समुदायाद्वारे.

आमच्या बाबतीत (CSI प्लगइन), डिस्क वाढवण्याचे ऑपरेशन असे दिसते:

1. आम्हाला gRPC कॉल येतो ControllerExpandVolume;
2. आम्ही API मध्ये डिस्क वाढवण्याचा प्रयत्न करीत आहोत, परंतु आम्हाला ऑपरेशन करण्याच्या अशक्यतेबद्दल त्रुटी प्राप्त झाली कारण डिस्क माउंट केली आहे;
3. आम्ही डिस्क आयडेंटिफायर नकाशामध्ये संग्रहित करतो, ज्यामध्ये डिस्क असतात ज्यासाठी वाढ ऑपरेशन करणे आवश्यक आहे. खाली, संक्षिप्ततेसाठी, आम्ही या नकाशाला असे म्हणू volumeResizeRequired;
4. डिस्क वापरत असलेला पॉड मॅन्युअली काढा. Kubernetes ते रीस्टार्ट करेल. जेणेकरून डिस्कला माउंट करण्यासाठी वेळ नसेल (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 API सर्व्हर आणि कुबेलेटसाठी;
• समाविष्ट --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API सर्व्हर आणि कुबेलेटसाठी;
• माउंट प्रसार (माउंट प्रसार) क्लस्टरवर सक्षम करणे आवश्यक आहे. डॉकर वापरताना, सामायिक माउंट्सना परवानगी देण्यासाठी डिमन कॉन्फिगर केले पाहिजे.

स्थापनेसाठी सर्व आवश्यक पावले स्वतः README मध्ये वर्णन केले आहे. इन्स्टॉलेशनमध्ये मॅनिफेस्टमधून कुबर्नेट्समध्ये ऑब्जेक्ट्स तयार करणे समाविष्ट आहे.

ड्रायव्हरने काम करण्यासाठी आपल्याला पुढील गोष्टींची आवश्यकता असेल:

• मॅनिफेस्टमध्ये निर्देशिका अभिज्ञापक निर्दिष्ट करा (folder-id) Yandex.Cloud (दस्तऐवजीकरण पहा);
• Yandex.Cloud API शी संवाद साधण्यासाठी, CSI ड्रायव्हर सेवा खाते वापरतो. मॅनिफेस्टमध्ये, सिक्रेट पास करणे आवश्यक आहे अधिकृत कळा सेवा खात्यातून. दस्तऐवजीकरण मध्ये वर्णन केले आहे, सेवा खाते कसे तयार करावे आणि की मिळवा.

एकंदरीत - हे करून पहा, आणि आम्हाला अभिप्राय मिळाल्याने आनंद होईल आणि नवीन मुद्देतुम्हाला काही समस्या आल्यास!

पुढील समर्थन

परिणामी, आम्ही हे लक्षात घेऊ इच्छितो की आम्ही या CSI ड्रायव्हरची अंमलबजावणी Go मध्ये मजेदार अनुप्रयोग लिहिण्याच्या मोठ्या इच्छेने केली नाही, परंतु कंपनीमध्ये तातडीची गरज असल्याने. आमची स्वतःची अंमलबजावणी राखणे आम्हाला व्यावहारिक वाटत नाही, म्हणून जर Yandex ने स्वारस्य दाखवले आणि ड्रायव्हरला समर्थन देणे सुरू ठेवण्याचा निर्णय घेतला, तर आम्हाला त्यांच्याकडे भांडार हस्तांतरित करण्यात आनंद होईल.

याव्यतिरिक्त, यॅन्डेक्सकडे कदाचित त्याच्या व्यवस्थापित कुबर्नेट्स क्लस्टरमध्ये सीएसआय ड्रायव्हरची स्वतःची अंमलबजावणी आहे, जी मुक्त स्त्रोतामध्ये सोडली जाऊ शकते. आम्ही हा विकास पर्याय अनुकूल म्हणून देखील पाहतो - समुदाय तृतीय-पक्ष कंपनीकडून नव्हे तर सेवा प्रदात्याकडून सिद्ध ड्रायव्हर वापरण्यास सक्षम असेल.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «Kubernetes स्टोरेजसाठी व्हॉल्यूम प्लगइन: Flexvolume ते CSI पर्यंत";
• «आम्ही कंटेनर स्टोरेज इंटरफेस समजतो (केवळ कुबर्नेट्समध्ये नाही)";
• «कुबर्नेट्स क्लस्टर तयार करणे सोपे आणि सोयीचे आहे का? अॅडऑन-ऑपरेटरची घोषणा करत आहे";
• «कुबर्नेट्सचा विस्तार आणि पूरक (पुनरावलोकन आणि व्हिडिओ अहवाल)».

स्त्रोत: www.habr.com