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

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

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

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

कुबेरनेट्स डेवलपर्स ने फ्लेक्सवॉल्यूम प्लगइन बनाया, जो तीसरे पक्ष के डेवलपर्स द्वारा कार्यान्वित फ्लेक्सवॉल्यूम ड्राइवरों के साथ काम करने के लिए चर और तरीकों का एक तार्किक ढांचा था।

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

ओपनशिफ्ट में सीआईएफएस शेयरों के लिए कनेक्शन आरेख। फ्लेक्सवॉल्यूम ड्राइवर - ठीक मध्य में

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

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, और इसके साथ वास्तविक समय में वॉल्यूम का आकार बदलने की क्षमता से आप खुद को परिचित कर सकते हैं हमारा पुल अनुरोध रूक सेफ ऑपरेटर में।

और यहां एनएफएस के साथ काम करने के लिए फ्लेक्सवॉल्यूम ड्राइवर के कार्यान्वयन का एक उदाहरण दिया गया है:

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

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

/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/

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

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

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

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

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

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

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

रूक ऑपरेटर में सेफ के साथ काम करने का आरेख: आरेख में फ्लेक्सवॉल्यूम ड्राइवर रूक एजेंट के अंदर स्थित है

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

इस समस्या का मूल समाधान Rook ऑपरेटर के Flexvolume ड्राइवर कार्यान्वयन में देखा जा सकता है:

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

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

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

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

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

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

कंटेनर स्टोरेज इंटरफ़ेस, या सीएसआई 3000 स्पिनिंग रॉड!

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

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

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

कुबेरनेट्स में सीएसआई प्लगइन कैसे काम करता है

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

ऐसे कार्यान्वयन के लाभ

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

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

निष्कर्ष

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

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

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

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

पुनश्च

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

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

स्रोत: www.habr.com