Kubernetes भण्डारणको लागि भोल्युम प्लगइनहरू: Flexvolume देखि CSI सम्म

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

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

फ्लेक्सभोल्युम प्लगइन: न्यूनतम माछा मार्ने रड

Kubernetes विकासकर्ताहरूले FlexVolume प्लगइन सिर्जना गरे, जुन तेस्रो-पक्ष विकासकर्ताहरूद्वारा लागू गरिएको Flexvolume ड्राइभरहरूसँग काम गर्ने चर र विधिहरूको तार्किक ढाँचा थियो।

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

OpenShift मा CIFS शेयरहरूको लागि जडान रेखाचित्र। 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

त्यसोभए, वास्तविक कार्यान्वयनयोग्य फाइल तयार गरिसकेपछि, तपाइँलाई आवश्यक छ Kubernetes क्लस्टरमा चालक अपलोड गर्नुहोस्। चालक पूर्वनिर्धारित मार्ग अनुसार प्रत्येक क्लस्टर नोडमा अवस्थित हुनुपर्छ। पूर्वनिर्धारित रूपमा यो चयन गरिएको थियो:

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

तर विभिन्न Kubernetes वितरण (OpenShift, Rancher...) प्रयोग गर्दा बाटो फरक हुन सक्छ।

फ्लेक्सभोल्युम समस्याहरू: कसरी माछा मार्ने रड सही रूपमा कास्ट गर्ने?

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

यो समस्या को समाधान Kubernetes आदिम मध्ये एक थियो - 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

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

रुक अपरेटरमा Ceph सँग काम गर्ने रेखाचित्र: रेखाचित्रमा फ्लेक्सभोल्युम चालक रुक एजेन्ट भित्र अवस्थित छ

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

यस समस्याको मूल समाधान रुक अपरेटरको फ्लेक्सभोल्युम ड्राइभर कार्यान्वयनमा देख्न सकिन्छ:

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

अलविदा, हाम्रो मायालु... इन-ट्री प्लगइनहरू!

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

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

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

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

कन्टेनर भण्डारण इन्टरफेस, वा CSI 3000 स्पिनिङ रड!

सबैभन्दा पहिले, म नोट गर्न चाहन्छु कि CSI भोल्युम प्लगइन मात्र होइन, तर वास्तविक हो मानक डाटा गोदामहरूसँग काम गर्नको लागि अनुकूलन कम्पोनेन्टहरू सिर्जना गर्न। Kubernetes र Mesos जस्ता कन्टेनर अर्केस्ट्रेसन प्रणालीहरूले यो मानक अनुसार कार्यान्वयन गरिएका घटकहरूसँग कसरी काम गर्ने भनेर "सिक्नु" भनिएको थियो। र अहिले मैले Kubernetes सिकेको छु।

Kubernetes मा CSI प्लगइन को संरचना के हो? CSI प्लगइनले विशेष चालकहरूसँग काम गर्दछ (CSI चालकहरू) तेस्रो पक्ष विकासकर्ताहरू द्वारा लिखित। Kubernetes मा एक CSI ड्राइभर कम्तिमा दुई कम्पोनेन्टहरू (पोडहरू) समावेश हुनुपर्छ:

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

CSI प्लगइनले Kubernetes मा कसरी काम गर्छ

तपाईंले CSI को कामका केही अन्य विवरणहरू बारे जान्न सक्नुहुन्छ, उदाहरणका लागि, लेखबाट "C.S.I. बुझ्दै», जसको अनुवाद हामीले एक वर्ष अघि प्रकाशित गर्यौं।

यस्तो कार्यान्वयन को लाभ

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

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

निष्कर्ष

CSI लाई डेटा गोदामहरूसँग अन्तरक्रिया गर्न अनुकूलन प्लगइनहरू लागू गर्नको लागि मानकको रूपमा समुदायले धेरै न्यानो स्वागत गरेको थियो। यसबाहेक, तिनीहरूका फाइदाहरू र बहुमुखी प्रतिभाको कारणले, CSI ड्राइभरहरू भण्डारण प्रणालीहरू जस्तै Ceph वा AWS EBS, काम गर्नका लागि प्लगइनहरूका लागि पनि सिर्जना गरिएका छन् जसको साथ Kubernetes को पहिलो संस्करणमा थपिएको थियो।

2019 को सुरुमा, इन-ट्री प्लगइनहरू अप्रचलित घोषित भएका छन्। हामी Flexvolume प्लगइनलाई समर्थन गर्न जारी राख्ने योजना गर्छौं, तर यसको लागि नयाँ कार्यक्षमता विकास गर्दैनौं।

हामीसँग पहिले नै ceph-csi, vsphere-csi प्रयोग गर्ने अनुभव छ र यो सूचीमा थप्न तयार छौं! अहिले सम्म, CSI ले यसलाई तोकिएको कार्यहरू धमाका साथ सामना गरिरहेको छ, तर हामी पर्खने र हेर्नेछौं।

नबिर्सनुहोस् कि सबै नयाँ पुरानो एक राम्रो पुनर्विचार हो!

PS

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

• «हामी कन्टेनर भण्डारण इन्टरफेस बुझ्छौं (कुबर्नेट्समा मात्र होइन)»;
• «रुकलाई कि रुकलाई होइन - त्यो प्रश्न हो»;
• «Kubernetes मा भोल्युम स्न्यापशटहरूको अल्फा संस्करण प्रस्तुत गर्दै"।

स्रोत: www.habr.com