कुबेरनेट्स स्टोरेज वॉल्यूम प्लगइन्स: फ्लेक्सवोल्यूम टू सीएसआई

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

प्लग-इन को कुबेरनेट्स के साथ मिलकर वितरित किया गया था, जिसके लिए उन्हें अपना नाम मिला - इन-ट्री। हालांकि, ऐसे प्लग-इन के मौजूदा सेट में से कई पर्याप्त नहीं थे। शिल्पकारों ने पैच का उपयोग करके कुबेरनेट्स के मूल में सरल प्लगइन्स को जोड़ा, जिसके बाद उन्होंने अपने कुबेरनेट्स का निर्माण किया और इसे अपने सर्वर पर डाल दिया। लेकिन समय के साथ, कुबेरनेट्स डेवलपर्स ने महसूस किया कि मछली को हल नहीं किया जा सकता है। लोगों को मछली पकड़ने की छड़ी की जरूरत होती है। और Kubernetes v1.2.0 रिलीज में, यह दिखाई दिया ...

Flexvolume प्लगइन: न्यूनतम मछली पकड़ने वाली छड़ी

कुबेरनेट्स के डेवलपर्स ने FlexVolume प्लगइन बनाया, जो तृतीय-पक्ष Flexvolume ड्राइवरों के साथ काम करने के लिए चर और विधियों का एक तार्किक बंधन था।

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


CIFS OpenShift में कनेक्शन योजना साझा करता है। Flexvolume चालक - केंद्र में सही

तरीकों का न्यूनतम सेट इस तरह दिखता है:

flexvolume_driver mount #      pod' #   : { "status": "Success"/"Failure"/"Not supported", "message": "       ", } flexvolume_driver unmount #      pod' #   : { "status": "Success"/"Failure"/"Not supported", "message": "       ", } flexvolume_driver init #     #   : { "status": "Success"/"Failure"/"Not supported", "message": "       ", // ,     attach/deatach "capabilities":{"attach": True/False} } 

attach और detach विधियों का उपयोग करके उस परिदृश्य को निर्धारित किया जाएगा जिसके अनुसार भविष्य में क्यूबलेट चालक को बुलाए जाने पर कार्य करेगा। विशेष रूप से expandvolume और expandfs जो गतिशील रूप से वॉल्यूम को आकार देने के लिए जिम्मेदार हैं।

expandvolume विधि में परिवर्तन के एक उदाहरण के रूप में, और इसके साथ वास्तविक समय में वॉल्यूम आकार देने की क्षमता है, आप रूक सेफ ऑपरेटर में हमारे पुल अनुरोध की जांच कर सकते हैं।

यहाँ NFS के साथ काम करने के लिए Flexvolume ड्राइवर का एक उदाहरण कार्यान्वयन है:

 usage() { err "Invalid usage. Usage: " err "\t$0 init" err "\t$0 mount <mount dir> <json params>" err "\t$0 unmount <mount dir>" exit 1 } err() { echo -ne $* 1>&2 } log() { echo -ne $* >&1 } ismounted() { MOUNT=`findmnt -n ${MNTPATH} 2>/dev/null | cut -d' ' -f1` if [ "${MOUNT}" == "${MNTPATH}" ]; then echo "1" else echo "0" fi } domount() { MNTPATH=$1 NFS_SERVER=$(echo $2 | jq -r '.server') SHARE=$(echo $2 | jq -r '.share') if [ $(ismounted) -eq 1 ] ; then log '{"status": "Success"}' exit 0 fi mkdir -p ${MNTPATH} &> /dev/null mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null if [ $? -ne 0 ]; then err "{ \"status\": \"Failure\", \"message\": \"Failed to mount ${NFS_SERVER}:${SHARE} at ${MNTPATH}\"}" exit 1 fi log '{"status": "Success"}' exit 0 } unmount() { MNTPATH=$1 if [ $(ismounted) -eq 0 ] ; then log '{"status": "Success"}' exit 0 fi umount ${MNTPATH} &> /dev/null if [ $? -ne 0 ]; then err "{ \"status\": \"Failed\", \"message\": \"Failed to unmount volume at ${MNTPATH}\"}" exit 1 fi log '{"status": "Success"}' exit 0 } op=$1 if [ "$op" = "init" ]; then log '{"status": "Success", "capabilities": {"attach": false}}' exit 0 fi if [ $# -lt 2 ]; then usage fi shift case "$op" in mount) domount $* ;; unmount) unmount $* ;; *) log '{"status": "Not supported"}' exit 0 esac exit 1 

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

/usr/libexec/kubernetes/kubelet-plugins/volume/exec/__~_/

... लेकिन कुबेरनेट के वितरण (ओपनशिफ्ट, रैंचर ...) के उपयोग से रास्ता अलग हो सकता है।

फ्लेक्सवोल्यूम समस्याएं: मछली पकड़ने वाली छड़ी कैसे डाली जाए?

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

इस समस्या का समाधान कुबेरनेट्स की प्रमुख प्राथमिकताओं में से एक था - DaemonSet । जब क्लस्टर में एक नया नोड दिखाई देता है, तो यह स्वचालित रूप से हमारे DaemonSet से एक फली प्राप्त करता है, जिसमें Flexvolume ड्राइवरों को खोजने के तरीके के साथ एक स्थानीय वॉल्यूम जुड़ा हुआ है। सफल निर्माण पर, पॉड डिस्क पर काम करने के लिए ड्राइवर के लिए आवश्यक फ़ाइलों की प्रतिलिपि बनाता है।

फ्लेक्सवोल्यूम प्लगइन को बाहर करने के लिए इस तरह के एक डेमोनसेट का एक उदाहरण है:

 apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: flex-set spec: template: metadata: name: flex-deploy labels: app: flex-deploy spec: containers: - image: <deployment_image> name: flex-deploy securityContext: privileged: true volumeMounts: - mountPath: /flexmnt name: flexvolume-mount volumes: - name: flexvolume-mount hostPath: path: <host_driver_directory> 

... और फ्लेक्सवोल्यूम चालक को बाहर निकालने के लिए बैश स्क्रिप्ट का एक उदाहरण:

 #!/bin/sh set -o errexit set -o pipefail VENDOR=k8s.io DRIVER=nfs driver_dir=$VENDOR${VENDOR:+"~"}${DRIVER} if [ ! -d "/flexmnt/$driver_dir" ]; then mkdir "/flexmnt/$driver_dir" fi cp "/$DRIVER" "/flexmnt/$driver_dir/.$DRIVER" mv -f "/flexmnt/$driver_dir/.$DRIVER" "/flexmnt/$driver_dir/$DRIVER" while : ; do sleep 3600 done 

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


रक बयान में सिफ के साथ काम करने की योजना: आरेख पर फ्लेक्सवोल्यूम चालक रूक एजेंट के अंदर है

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

इस समस्या का एक मूल समाधान रूक ऑपरेटर के फ्लेक्सवोल्यूम चालक के कार्यान्वयन में देखा जा सकता है:

ड्राइवर को स्वयं RPC क्लाइंट के रूप में डिज़ाइन किया गया है। संचार के लिए आईपीसी सॉकेट उसी निर्देशिका में निहित है जो चालक के रूप में है। हमें याद है कि ड्राइवर फ़ाइलों की प्रतिलिपि बनाने के लिए DaemonSet का उपयोग करना अच्छा होगा, जो ड्राइवर के साथ निर्देशिका को वॉल्यूम के रूप में जोड़ता है। आवश्यक रूक ड्राइवर फ़ाइलों की प्रतिलिपि बनाने के बाद, यह पॉड नहीं मरता है, लेकिन एक पूर्ण आरपीसी सर्वर के रूप में संलग्न वॉल्यूम के माध्यम से आईपीसी सॉकेट से जुड़ जाता है। पॉड कंटेनर के अंदर सेफ-कॉमन पैकेज पहले से स्थापित है। IPC सॉकेट आत्मविश्वास देता है कि क्यूबलेट उसी नोड पर स्थित विशेष पॉड के साथ संचार करेगा। सब कुछ सरल है!

अलविदा, हमारे स्नेही ... इन-ट्री प्लगइन्स!

कुबेरनेट डेवलपर्स ने पाया है कि कर्नेल के अंदर भंडारण प्लग की संख्या बीस है। और उनमें से प्रत्येक में परिवर्तन किसी तरह पूर्ण कुबेरनेट्स रिलीज चक्र से गुजरता है।

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

स्थिति हास्य से अधिक है, क्या आप नहीं हैं? यह पूरे समुदाय के लिए स्पष्ट हो गया कि दृष्टिकोण काम नहीं करता था। एक मजबूत इरादों वाले फैसले के साथ, कुबेरनेट्स डेवलपर्स घोषणा करते हैं कि नए स्टोरेज प्लगइन्स को अब कर्नेल में स्वीकार नहीं किया जाएगा। बाकी सब कुछ, जैसा कि हम पहले से ही जानते हैं, फ्लेक्सवोल्यूम प्लगइन के कार्यान्वयन में कई कमियों का पता चला था ...

एक बार और सभी के लिए, Kubernetes, CSI में वॉल्यूम के लिए अंतिम जोड़ा प्लगइन, लगातार डेटा वेयरहाउस के साथ समस्या को बंद करने के लिए कहा गया था। इसका अल्फा संस्करण, जिसे आमतौर पर आउट-ऑफ-ट्री सीएसआई वॉल्यूम प्लगइन्स के रूप में संदर्भित किया जाता है, कुबेरनेट्स 1.9 में घोषित किया गया था।

कंटेनर संग्रहण इंटरफ़ेस, या CSI 3000 कताई!

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

Kubernetes में CSI प्लगइन का उपकरण क्या है? CSI प्लगइन तीसरे पक्ष के डेवलपर्स द्वारा लिखे गए विशेष ड्राइवरों ( CSI ड्राइवरों ) के साथ काम करता है। Kubernetes में CSI ड्राइवर में कम से कम दो घटक (पॉड) शामिल होने चाहिए:

• नियंत्रक - बाहरी लगातार भंडारण का प्रबंधन करता है। यह एक gRPC सर्वर के रूप में कार्यान्वित किया जाता है जिसके लिए StatefulSet प्राइमेट का उपयोग किया जाता है।
• नोड - क्लस्टर नोड्स के लिए लगातार स्टोर बढ़ते के लिए जिम्मेदार है। इसे gRPC सर्वर के रूप में भी लागू किया गया है, लेकिन इसके लिए DaemonSet आदिम का उपयोग किया जाता है।

Kubernetes CSI प्लगइन वर्कफ़्लो

आप सीएसआई के कुछ अन्य विवरणों के बारे में जान सकते हैं, उदाहरण के लिए, " सीएसआई को समझना " लेख से, जिसका अनुवाद हमने एक साल पहले प्रकाशित किया था।

इस तरह के कार्यान्वयन के फायदे

• बुनियादी चीजों के लिए - उदाहरण के लिए, एक चालक को नोड के लिए पंजीकृत करने के लिए - कुबेरनेट डेवलपर्स ने कंटेनरों का एक सेट लागू किया है। अब आपको स्वयं क्षमताओं के साथ JSON प्रतिक्रिया बनाने की आवश्यकता नहीं है, जैसा कि फ्लेक्सवोल्यूम प्लगइन के लिए किया गया था।
• निष्पादन योग्य फ़ाइलों के नोड्स "फिसलने" के बजाय, हम अब क्लस्टर में पॉड्स बिछाते हैं। यह हम मूल रूप से कुबेरनेट्स से उम्मीद करते थे: कुबेरनेट्स प्राइमेटिव्स का उपयोग करके तैनात किए गए कंटेनरों के अंदर सभी प्रक्रियाएं होती हैं।
• जटिल ड्राइवरों को लागू करने के लिए, आपको अब RPC सर्वर और RPC क्लाइंट विकसित करने की आवश्यकता नहीं है। हमारे लिए क्लाइंट कुबेरनेट डेवलपर्स द्वारा लागू किया गया था।
• GRPC प्रोटोकॉल के साथ काम करने के लिए तर्क पारित करना कमांड लाइन तर्कों के माध्यम से पारित करने की तुलना में अधिक सुविधाजनक, लचीला और अधिक विश्वसनीय है। एक मानकीकृत gRPC विधि जोड़कर CSI में वॉल्यूम उपयोग मेट्रिक्स के लिए समर्थन कैसे जोड़ा जाए, यह समझने के लिए, आप vsphere-csi ड्राइवर के लिए हमारे पुल अनुरोध की जांच कर सकते हैं।
• संचार IPC सॉकेट्स के माध्यम से होता है ताकि भ्रमित न हों कि क्यूबलेट पॉड ने अनुरोध भेजा है या नहीं।

क्या यह सूची आपको कुछ याद दिलाती है? CSI के फायदे उन समस्याओं का समाधान हैं जिन्हें फ्लेक्सवोल्यूम प्लगइन विकसित करते समय ध्यान में नहीं रखा गया था।

निष्कर्ष

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

2019 की शुरुआत में, इन-ट्री प्लगइन्स को हटा दिया गया था । इसे Flexvolume प्लगइन का समर्थन जारी रखने की योजना है, लेकिन इसके लिए नई कार्यक्षमता का कोई विकास नहीं होगा।

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

मत भूलो कि सब कुछ नया एक अच्छी तरह से पुनर्विचार पुराना है!

पुनश्च

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

• "हम कंटेनर भंडारण इंटरफ़ेस (कुबेरनेट्स में और न केवल) को समझते हैं ";
• " Rook या नहीं - Rook - यह सवाल है ";
• " Kubernetes में वॉल्यूम स्नैपशॉट के अल्फ़ा संस्करण को जानना ।"