Kubernetes स्टोरेजसाठी व्हॉल्यूम प्लगइन: Flexvolume ते CSI पर्यंत

मागे जेव्हा Kubernetes अजूनही v1.0.0 होते, तेव्हा व्हॉल्यूम प्लगइन होते. पर्सिस्टंट (कायमस्वरूपी) कंटेनर डेटा संग्रहित करण्यासाठी कुबर्नेट्सशी सिस्टम कनेक्ट करण्यासाठी त्यांना आवश्यक होते. त्यांची संख्या कमी होती आणि GCE PD, Ceph, AWS EBS आणि इतर यांसारखे स्टोरेज प्रदाते प्रथम होते.

प्लगइन्स कुबर्नेट्ससह वितरित केल्या गेल्या, म्हणूनच त्यांना त्यांचे नाव मिळाले - इन-ट्री. तथापि, अनेकांसाठी, अशा प्लगइनचा विद्यमान संच अपुरा असल्याचे दिसून आले. कारागीरांनी पॅचेस वापरून कुबर्नेट्स कोरमध्ये साधे प्लगइन जोडले, त्यानंतर त्यांनी त्यांचे स्वतःचे कुबर्नेट्स एकत्र केले आणि ते त्यांच्या सर्व्हरवर स्थापित केले. परंतु कालांतराने, कुबर्नेट्सच्या विकसकांना हे समजले मासे समस्या सोडवता येत नाही. लोकांना गरज आहे मासेमारी रॉड. आणि Kubernetes v1.2.0 च्या रिलीझमध्ये ते दिसले...

फ्लेक्सव्हॉल्यूम प्लगइन: किमान फिशिंग रॉड

Kubernetes विकासकांनी FlexVolume प्लगइन तयार केले, जे थर्ड-पार्टी डेव्हलपर्सद्वारे लागू केलेल्या फ्लेक्सव्हॉल्यूम ड्रायव्हर्ससह कार्य करण्यासाठी व्हेरिएबल्स आणि पद्धतींचे तार्किक फ्रेमवर्क होते.

चला थांबू आणि FlexVolume ड्राइव्हर काय आहे ते जवळून पाहू. हे निश्चित आहे एक्झिक्युटेबल फाइल (बायनरी फाइल, पायथन स्क्रिप्ट, बॅश स्क्रिप्ट, इ.), जे कार्यान्वित केल्यावर, कमांड लाइन आर्ग्युमेंट्स इनपुट म्हणून घेते आणि JSON फॉरमॅटमध्ये पूर्व-ज्ञात फील्डसह संदेश परत करते. नियमानुसार, प्रथम कमांड लाइन वितर्क नेहमीच एक पद्धत असते आणि उर्वरित युक्तिवाद हे त्याचे मापदंड असतात.

OpenShift मध्ये CIFS शेअर्ससाठी कनेक्शन आकृती. फ्लेक्सव्हॉल्यूम ड्रायव्हर - उजवीकडे मध्यभागी

पद्धतींचा किमान संच असे दिसते:

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 सह कार्य करण्यासाठी फ्लेक्सव्हॉल्यूम ड्रायव्हरच्या अंमलबजावणीचे उदाहरण आहे:

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. जेव्हा क्लस्टरमध्ये नवीन नोड दिसतो, तेव्हा त्यात आपोआप आमच्या डेमनसेटचा पॉड असतो, ज्याला फ्लेक्सव्हॉल्यूम ड्रायव्हर्स शोधण्यासाठी मार्गावर स्थानिक व्हॉल्यूम जोडलेला असतो. यशस्वी निर्मितीनंतर, पॉड ड्रायव्हरला डिस्कवर काम करण्यासाठी आवश्यक फाइल्स कॉपी करते.

फ्लेक्सव्हॉल्यूम प्लगइन घालण्यासाठी अशा डेमनसेटचे उदाहरण येथे आहे:

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

हे कॉपी ऑपरेशन विसरू नका महत्वाचे आहे अणू नाही. कुबेलेटची प्रोव्हिजनिंग प्रक्रिया पूर्ण होण्याआधीच ड्रायव्हरचा वापर सुरू होण्याची दाट शक्यता आहे, ज्यामुळे सिस्टममध्ये त्रुटी निर्माण होईल. प्रथम ड्रायव्हर फायली वेगळ्या नावाखाली कॉपी करणे आणि नंतर अणू पुनर्नामित ऑपरेशन वापरणे हा योग्य दृष्टीकोन आहे.

रुक ऑपरेटरमध्ये सेफसोबत काम करण्याचा आकृती: आकृतीमधील फ्लेक्सव्हॉल्यूम ड्रायव्हर रुक एजंटमध्ये स्थित आहे

फ्लेक्सव्हॉल्यूम ड्रायव्हर्स वापरताना पुढील समस्या क्लस्टर नोडवरील बहुतेक स्टोरेजसाठी आहे यासाठी आवश्यक सॉफ्टवेअर स्थापित करणे आवश्यक आहे (उदाहरणार्थ, Ceph साठी ceph-सामान्य पॅकेज). सुरुवातीला, Flexvolume प्लगइन अशा जटिल प्रणाली लागू करण्यासाठी डिझाइन केलेले नव्हते.

या समस्येचे मूळ समाधान रुक ऑपरेटरच्या फ्लेक्सव्हॉल्यूम ड्रायव्हर अंमलबजावणीमध्ये पाहिले जाऊ शकते:

ड्रायव्हर स्वतः RPC क्लायंट म्हणून डिझाइन केलेले आहे. संप्रेषणासाठी IPC सॉकेट ड्रायव्हरच्याच निर्देशिकेत स्थित आहे. आम्ही लक्षात ठेवतो की ड्रायव्हर फायली कॉपी करण्यासाठी डेमनसेट वापरणे चांगले आहे, जे व्हॉल्यूम म्हणून ड्रायव्हरशी निर्देशिका जोडते. आवश्यक रूक ड्रायव्हर फाइल्स कॉपी केल्यानंतर, हा पॉड मरत नाही, परंतु पूर्ण RPC सर्व्हर म्हणून संलग्न व्हॉल्यूमद्वारे IPC सॉकेटशी कनेक्ट होतो. पॉड कंटेनरमध्ये सेफ-कॉमन पॅकेज आधीपासूनच स्थापित केले आहे. IPC सॉकेट हे सुनिश्चित करते की कुबेलेट त्याच नोडवर असलेल्या पॉडशी संवाद साधेल. कल्पक सर्वकाही सोपे आहे! ..

गुडबाय, आमचे स्नेही... इन-ट्री प्लगइन्स!

Kubernetes विकासकांनी शोधून काढले की कोरमध्ये स्टोरेजसाठी प्लगइनची संख्या वीस आहे. आणि त्या प्रत्येकामध्ये बदल, एक ना एक मार्ग, पूर्ण कुबर्नेट्स रिलीझ सायकलमधून जातो.

असे दिसून आले की स्टोरेज प्लगइनची नवीन आवृत्ती वापरण्यासाठी, तुम्हाला संपूर्ण क्लस्टर अपडेट करणे आवश्यक आहे. या व्यतिरिक्त, तुम्हाला आश्चर्य वाटेल की कुबर्नेट्सची नवीन आवृत्ती तुम्ही वापरत असलेल्या लिनक्स कर्नलशी अचानक विसंगत होईल... त्यामुळे तुम्ही तुमचे अश्रू पुसून, दात घासून, तुमच्या व्यवस्थापनाशी आणि वापरकर्त्यांशी समन्वय साधा. लिनक्स कर्नल आणि कुबर्नेट्स क्लस्टर अपडेट करा. सेवांच्या तरतूदीमध्ये संभाव्य डाउनटाइमसह.

परिस्थिती हास्यास्पद आहे, तुम्हाला वाटत नाही का? हा दृष्टिकोन काम करत नसल्याचे संपूर्ण समाजाला स्पष्ट झाले. जाणूनबुजून निर्णय घेऊन, Kubernetes विकासक घोषणा करतात की स्टोरेजसह कार्य करण्यासाठी नवीन प्लगइन यापुढे कर्नलमध्ये स्वीकारले जाणार नाहीत. याव्यतिरिक्त, आम्हाला आधीच माहित आहे की, फ्लेक्सव्हॉल्यूम प्लगइनच्या अंमलबजावणीमध्ये अनेक कमतरता ओळखल्या गेल्या आहेत...

Kubernetes, CSI मधील व्हॉल्यूमसाठी नवीनतम जोडलेले प्लगइन, कायमस्वरूपी डेटा स्टोरेजसह समस्या एकदा आणि सर्वांसाठी बंद करण्यास सांगितले होते. त्याची अल्फा आवृत्ती, ज्याला आउट-ऑफ-ट्री सीएसआय व्हॉल्यूम प्लगइन्स म्हणून पूर्णपणे संबोधले जाते, त्याची घोषणा प्रकाशनात करण्यात आली. कुबर्नेट्स 1.9.

कंटेनर स्टोरेज इंटरफेस, किंवा CSI 3000 स्पिनिंग रॉड!

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

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

• नियंत्रक - बाह्य पर्सिस्टंट स्टोरेज व्यवस्थापित करते. हे gRPC सर्व्हर म्हणून लागू केले आहे, ज्यासाठी आदिम वापरला जातो StatefulSet.
• नोड — क्लस्टर नोड्समध्ये पर्सिस्टंट स्टोरेज माउंट करण्यासाठी जबाबदार आहे. हे gRPC सर्व्हर म्हणून देखील लागू केले आहे, परंतु ते आदिम वापरते DaemonSet.

CSI प्लगइन Kubernetes मध्ये कसे कार्य करते

आपण CSI च्या कार्याच्या इतर काही तपशीलांबद्दल जाणून घेऊ शकता, उदाहरणार्थ, लेखातूनC.S.I समजून घेणे.» ज्याचे भाषांतर आम्ही एक वर्षापूर्वी प्रकाशित केले.

अशा अंमलबजावणीचे फायदे

• नोडसाठी ड्रायव्हरची नोंदणी करण्यासारख्या मूलभूत गोष्टींसाठी, कुबर्नेट्स डेव्हलपर्सनी कंटेनरचा एक संच लागू केला. Flexvolume प्लगइनसाठी केले होते त्याप्रमाणे, तुम्हाला यापुढे क्षमतांसह JSON प्रतिसाद निर्माण करण्याची आवश्यकता नाही.
• एक्झिक्युटेबल फाइल्स नोड्सवर “स्लिप” करण्याऐवजी, आम्ही आता क्लस्टरवर पॉड्स अपलोड करतो. कुबर्नेट्सकडून आम्ही सुरुवातीला हीच अपेक्षा करतो: सर्व प्रक्रिया कुबर्नेट्स प्रिमिटिव्स वापरून तैनात केलेल्या कंटेनरमध्ये होतात.
• जटिल ड्रायव्हर्स लागू करण्यासाठी तुम्हाला यापुढे RPC सर्व्हर आणि RPC क्लायंट विकसित करण्याची आवश्यकता नाही. क्लायंट आमच्यासाठी Kubernetes विकासकांनी लागू केला होता.
• कमांड लाइन वितर्कांमधून पास करण्यापेक्षा gRPC प्रोटोकॉलवर काम करण्यासाठी युक्तिवाद पास करणे अधिक सोयीस्कर, लवचिक आणि विश्वासार्ह आहे. प्रमाणित gRPC पद्धत जोडून CSI मध्ये व्हॉल्यूम वापर मेट्रिक्ससाठी समर्थन कसे जोडायचे हे समजून घेण्यासाठी, तुम्ही हे वाचू शकता: आमची पुल विनंती vsphere-csi ड्राइव्हरसाठी.
• संप्रेषण आयपीसी सॉकेट्सद्वारे होते, जेणेकरून कुबेलेटने योग्य पॉडला विनंती पाठवली की नाही याचा गोंधळ होऊ नये.

ही यादी तुम्हाला कशाची आठवण करून देते का? CSI चे फायदे आहेत त्याच समस्या सोडवणे, जे Flexvolume प्लगइन विकसित करताना विचारात घेतले गेले नाही.

निष्कर्ष

डेटा वेअरहाऊसशी संवाद साधण्यासाठी सानुकूल प्लगइन्सची अंमलबजावणी करण्यासाठी मानक म्हणून CSI ला समुदायाकडून अतिशय उत्साहाने स्वागत मिळाले. शिवाय, त्यांच्या फायद्यांमुळे आणि अष्टपैलुत्वामुळे, CSI ड्रायव्हर्स अगदी Ceph किंवा AWS EBS सारख्या स्टोरेज सिस्टीमसाठी तयार केले जातात, कुबर्नेट्सच्या पहिल्या आवृत्तीत जोडलेले कार्य करण्यासाठी प्लगइन.

2019 च्या सुरुवातीला, इन-ट्री प्लगइन अप्रचलित घोषित केले आहेत. आम्ही Flexvolume प्लगइनला समर्थन देणे सुरू ठेवण्याची योजना आखत आहोत, परंतु त्यासाठी नवीन कार्यक्षमता विकसित करणार नाही.

आम्हाला आधीच ceph-csi, vsphere-csi वापरण्याचा अनुभव आहे आणि आम्ही या सूचीमध्ये जोडण्यासाठी तयार आहोत! आतापर्यंत, CSI त्याला नेमून दिलेल्या कार्यांचा सामना करत आहे, परंतु आम्ही प्रतीक्षा करू आणि पाहू.

हे विसरू नका की नवीन सर्वकाही जुन्याचा चांगला पुनर्विचार आहे!

PS

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

• «आम्ही कंटेनर स्टोरेज इंटरफेस समजतो (केवळ कुबर्नेट्समध्ये नाही)";
• «रुककडे किंवा रुककडे नाही - हा प्रश्न आहे";
• «Kubernetes मध्ये व्हॉल्यूम स्नॅपशॉटची अल्फा आवृत्ती सादर करत आहे».

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