കുബെർനെറ്റസ് സ്റ്റോറേജിനുള്ള വോളിയം പ്ലഗിനുകൾ: ഫ്ലെക്‌സ് വോള്യം മുതൽ സിഎസ്‌ഐ വരെ

കുബർനെറ്റസ് v1.0.0 ആയിരുന്നപ്പോൾ, വോളിയം പ്ലഗിനുകൾ ഉണ്ടായിരുന്നു. സ്ഥിരമായ (സ്ഥിരമായ) കണ്ടെയ്‌നർ ഡാറ്റ സംഭരിക്കുന്നതിന് സിസ്റ്റങ്ങളെ കുബർനെറ്റിലേക്ക് ബന്ധിപ്പിക്കുന്നതിന് അവ ആവശ്യമായിരുന്നു. അവരുടെ എണ്ണം ചെറുതായിരുന്നു, ആദ്യത്തേതിൽ GCE PD, Ceph, AWS EBS തുടങ്ങിയ സ്റ്റോറേജ് ദാതാക്കളും ഉണ്ടായിരുന്നു.

പ്ലഗിനുകൾ കുബർനെറ്റസിനൊപ്പം ഡെലിവർ ചെയ്തു, അതിനാലാണ് അവർക്ക് അവരുടെ പേര് ലഭിച്ചത് - ഇൻ-ട്രീ. എന്നിരുന്നാലും, പലർക്കും, അത്തരം പ്ലഗിനുകളുടെ നിലവിലുള്ള സെറ്റ് അപര്യാപ്തമായി മാറി. കരകൗശല വിദഗ്ധർ കുബർനെറ്റസ് കോറിലേക്ക് പാച്ചുകൾ ഉപയോഗിച്ച് ലളിതമായ പ്ലഗിനുകൾ ചേർത്തു, അതിനുശേഷം അവർ സ്വന്തം കുബർനെറ്റുകൾ കൂട്ടിച്ചേർക്കുകയും അവരുടെ സെർവറുകളിൽ ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്തു. എന്നാൽ കാലക്രമേണ, കുബർനെറ്റസ് ഡെവലപ്പർമാർ അത് മനസ്സിലാക്കി മത്സ്യം പ്രശ്നം പരിഹരിക്കാൻ കഴിയില്ല. ആളുകൾക്ക് ആവശ്യമാണ് ഫിഷിംഗ് വടി. കുബർനെറ്റസ് v1.2.0 ന്റെ റിലീസിൽ അത് പ്രത്യക്ഷപ്പെട്ടു...

Flexvolume പ്ലഗിൻ: മിനിമൽ ഫിഷിംഗ് വടി

കുബെർനെറ്റസ് ഡവലപ്പർമാർ 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-നൊപ്പം പ്രവർത്തിക്കുന്നതിനായി 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/имя_поставщика_хранилища~имя_драйвера/

... എന്നാൽ വ്യത്യസ്ത കുബർനെറ്റസ് വിതരണങ്ങൾ ഉപയോഗിക്കുമ്പോൾ (ഓപ്പൺഷിഫ്റ്റ്, റാഞ്ചർ...) പാത വ്യത്യസ്തമായിരിക്കാം.

ഫ്ലെക്സ് വോളിയം പ്രശ്നങ്ങൾ: ഒരു മത്സ്യബന്ധന വടി എങ്ങനെ ശരിയായി ഇടാം?

ഫ്ലെക്സ് വോളിയം ഡ്രൈവർ ക്ലസ്റ്റർ നോഡുകളിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നത് നിസ്സാരമല്ലാത്ത ഒരു ജോലിയായി മാറി. ഓപ്പറേഷൻ ഒരിക്കൽ സ്വമേധയാ ചെയ്തുകഴിഞ്ഞാൽ, ക്ലസ്റ്ററിൽ പുതിയ നോഡുകൾ പ്രത്യക്ഷപ്പെടുന്ന ഒരു സാഹചര്യം നേരിടാൻ എളുപ്പമാണ്: ഒരു പുതിയ നോഡ്, ഓട്ടോമാറ്റിക് ഹോറിസോണ്ടൽ സ്കെയിലിംഗ്, അല്ലെങ്കിൽ - ഒരു തകരാർ കാരണം ഒരു നോഡ് മാറ്റിസ്ഥാപിക്കൽ എന്നിവ കാരണം. ഈ സാഹചര്യത്തിൽ, ഈ നോഡുകളിലെ സ്റ്റോറേജുമായി പ്രവർത്തിക്കണം അസാധ്യമാണ്, നിങ്ങൾ അവയിലേക്ക് Flexvolume ഡ്രൈവർ സ്വമേധയാ ചേർക്കുന്നത് വരെ.

ഈ പ്രശ്നത്തിനുള്ള പരിഹാരം കുബെർനെറ്റസ് പ്രിമിറ്റീവുകളിൽ ഒന്നായിരുന്നു - 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>

... കൂടാതെ Flexvolume ഡ്രൈവർ സ്ഥാപിക്കുന്നതിനുള്ള ഒരു ബാഷ് സ്ക്രിപ്റ്റിന്റെ ഒരു ഉദാഹരണം:

#!/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 ഡ്രൈവറുകൾ ഉപയോഗിക്കുമ്പോഴുള്ള അടുത്ത പ്രശ്നം ഒരു ക്ലസ്റ്റർ നോഡിലെ മിക്ക സംഭരണത്തിനും ആണ് ഇതിനാവശ്യമായ സോഫ്റ്റ്‌വെയർ ഇൻസ്റ്റാൾ ചെയ്യണം (ഉദാഹരണത്തിന്, Ceph-നുള്ള ceph-common പാക്കേജ്). തുടക്കത്തിൽ, Flexvolume പ്ലഗിൻ അത്തരം സങ്കീർണ്ണ സംവിധാനങ്ങൾ നടപ്പിലാക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടില്ല.

ഈ പ്രശ്നത്തിനുള്ള ഒരു യഥാർത്ഥ പരിഹാരം റൂക്ക് ഓപ്പറേറ്ററിന്റെ ഫ്ലെക്സ് വോളിയം ഡ്രൈവർ നടപ്പിലാക്കലിൽ കാണാൻ കഴിയും:

ഡ്രൈവർ തന്നെ ഒരു RPC ക്ലയന്റ് ആയി രൂപകൽപ്പന ചെയ്തിരിക്കുന്നു. ആശയവിനിമയത്തിനായുള്ള ഐപിസി സോക്കറ്റ് ഡ്രൈവറിന്റെ അതേ ഡയറക്ടറിയിലാണ് സ്ഥിതി ചെയ്യുന്നത്. ഡ്രൈവർ ഫയലുകൾ പകർത്തുന്നതിന്, ഡയറക്‌ടറിയെ ഒരു വോള്യമായി ബന്ധിപ്പിക്കുന്ന ഡെമോൺസെറ്റ് ഉപയോഗിക്കുന്നത് നല്ലതാണെന്ന് ഞങ്ങൾ ഓർക്കുന്നു. ആവശ്യമായ റൂക്ക് ഡ്രൈവർ ഫയലുകൾ പകർത്തിയ ശേഷം, ഈ പോഡ് മരിക്കില്ല, എന്നാൽ ഒരു പൂർണ്ണമായ RPC സെർവറായി അറ്റാച്ച് ചെയ്ത വോളിയം വഴി IPC സോക്കറ്റിലേക്ക് ബന്ധിപ്പിക്കുന്നു. പോഡ് കണ്ടെയ്‌നറിനുള്ളിൽ സെഫ്-കോമൺ പാക്കേജ് ഇതിനകം ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്. അതേ നോഡിൽ സ്ഥിതി ചെയ്യുന്ന പോഡുമായി കുബെലെറ്റ് ആശയവിനിമയം നടത്തുമെന്ന് IPC സോക്കറ്റ് ഉറപ്പാക്കുന്നു. സമർത്ഥമായ എല്ലാം ലളിതമാണ്! ..

വിട, ഞങ്ങളുടെ വാത്സല്യമുള്ള... ഇൻ-ട്രീ പ്ലഗിനുകൾ!

കേർണലിനുള്ളിൽ സംഭരണത്തിനുള്ള പ്ലഗിനുകളുടെ എണ്ണം ഇരുപതാണെന്ന് കുബർനെറ്റസ് ഡെവലപ്പർമാർ കണ്ടെത്തി. അവയിൽ ഓരോന്നിലും ഒരു മാറ്റം, ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്ന്, പൂർണ്ണമായ കുബർനെറ്റസ് റിലീസ് സൈക്കിളിലൂടെ കടന്നുപോകുന്നു.

സ്റ്റോറേജ് പ്ലഗിന്റെ പുതിയ പതിപ്പ് ഉപയോഗിക്കുന്നതിന് ഇത് മാറുന്നു, നിങ്ങൾ മുഴുവൻ ക്ലസ്റ്ററും അപ്ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട്. ഇതുകൂടാതെ, Kubernetes-ന്റെ പുതിയ പതിപ്പ് നിങ്ങൾ ഉപയോഗിക്കുന്ന Linux കേർണലുമായി പെട്ടെന്ന് പൊരുത്തപ്പെടാത്തതിൽ നിങ്ങൾ ആശ്ചര്യപ്പെട്ടേക്കാം... അതിനാൽ നിങ്ങൾ കണ്ണുനീർ തുടച്ചു, പല്ല് കടിച്ചുകൊണ്ട്, നിങ്ങളുടെ മാനേജ്മെന്റുമായും ഉപയോക്താക്കളുമായും സമയം ഏകോപിപ്പിക്കുക. Linux കേർണലും Kubernetes ക്ലസ്റ്ററും അപ്ഡേറ്റ് ചെയ്യുക. സേവനങ്ങൾ നൽകുന്നതിൽ തടസ്സം സാധ്യമായതോടെ.

സാഹചര്യം തമാശയേക്കാൾ കൂടുതലാണ്, നിങ്ങൾ കരുതുന്നില്ലേ? സമീപനം ഫലപ്രദമല്ലെന്ന് സമൂഹത്തിന് മുഴുവൻ വ്യക്തമായി. മനഃപൂർവമായ തീരുമാനത്തിലൂടെ, സംഭരണവുമായി പ്രവർത്തിക്കുന്നതിനുള്ള പുതിയ പ്ലഗിനുകൾ ഇനി കേർണലിലേക്ക് സ്വീകരിക്കില്ലെന്ന് കുബർനെറ്റസ് ഡെവലപ്പർമാർ പ്രഖ്യാപിക്കുന്നു. കൂടാതെ, നമുക്ക് ഇതിനകം അറിയാവുന്നതുപോലെ, Flexvolume പ്ലഗിൻ നടപ്പിലാക്കുന്നതിൽ നിരവധി പോരായ്മകൾ തിരിച്ചറിഞ്ഞു.

കുബെർനെറ്റസിലെ വോള്യങ്ങൾക്കായുള്ള ഏറ്റവും പുതിയ ചേർത്ത പ്ലഗിൻ, CSI, സ്ഥിരമായ ഡാറ്റ സ്റ്റോറേജ് ഉപയോഗിച്ച് പ്രശ്‌നം അവസാനിപ്പിക്കാൻ ആവശ്യപ്പെട്ടു. അതിന്റെ ആൽഫ പതിപ്പ്, പൂർണ്ണമായും ഔട്ട്-ഓഫ്-ട്രീ CSI വോളിയം പ്ലഗിനുകൾ എന്നറിയപ്പെടുന്നു, റിലീസിൽ പ്രഖ്യാപിച്ചു. കുബേർനെറ്റ്സ് 1.9.

കണ്ടെയ്നർ സ്റ്റോറേജ് ഇന്റർഫേസ്, അല്ലെങ്കിൽ CSI 3000 സ്പിന്നിംഗ് വടി!

ഒന്നാമതായി, സി‌എസ്‌ഐ ഒരു വോളിയം പ്ലഗിൻ മാത്രമല്ല, യഥാർത്ഥമാണെന്ന് ഞാൻ ശ്രദ്ധിക്കാൻ ആഗ്രഹിക്കുന്നു സ്റ്റാൻഡേർഡ് ഡാറ്റ വെയർഹൗസുകളിൽ പ്രവർത്തിക്കുന്നതിന് ഇഷ്ടാനുസൃത ഘടകങ്ങൾ സൃഷ്ടിക്കുന്നതിൽ. ഈ സ്റ്റാൻഡേർഡ് അനുസരിച്ച് നടപ്പിലാക്കിയ ഘടകങ്ങളുമായി എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് കുബെർനെറ്റസ്, മെസോസ് തുടങ്ങിയ കണ്ടെയ്നർ ഓർക്കസ്ട്രേഷൻ സംവിധാനങ്ങൾ "പഠിക്കണം". ഇപ്പോൾ ഞാൻ ഇതിനകം കുബർനെറ്റസ് പഠിച്ചു.

Kubernetes-ലെ CSI പ്ലഗിന്റെ ഘടന എന്താണ്? CSI പ്ലഗിൻ പ്രത്യേക ഡ്രൈവറുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു (CSI ഡ്രൈവർമാർ) മൂന്നാം കക്ഷി ഡെവലപ്പർമാർ എഴുതിയത്. കുബെർനെറ്റസിലെ ഒരു സിഎസ്ഐ ഡ്രൈവറിൽ ചുരുങ്ങിയത് രണ്ട് ഘടകങ്ങൾ (പോഡുകൾ) അടങ്ങിയിരിക്കണം:

• കൺട്രോളർ - ബാഹ്യ പെർസിസ്റ്റന്റ് സ്റ്റോറേജുകൾ കൈകാര്യം ചെയ്യുന്നു. ഇത് ഒരു gRPC സെർവറായി നടപ്പിലാക്കുന്നു, അതിനായി പ്രാകൃതം ഉപയോഗിക്കുന്നു StatefulSet.
• നോഡ് — ക്ലസ്റ്റർ നോഡുകളിലേക്ക് പെർസിസ്റ്റന്റ് സ്റ്റോറേജ് മൌണ്ട് ചെയ്യുന്നതിനുള്ള ഉത്തരവാദിത്തം. ഇത് ഒരു gRPC സെർവറായും നടപ്പിലാക്കുന്നു, പക്ഷേ ഇത് പ്രാകൃതമാണ് ഉപയോഗിക്കുന്നത് DaemonSet.

കുബർനെറ്റസിൽ CSI പ്ലഗിൻ എങ്ങനെ പ്രവർത്തിക്കുന്നു

സിഎസ്‌ഐയുടെ പ്രവർത്തനത്തിന്റെ മറ്റ് ചില വിശദാംശങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് പഠിക്കാം, ഉദാഹരണത്തിന്, "" എന്ന ലേഖനത്തിൽ നിന്ന്സി.എസ്.ഐയെ മനസ്സിലാക്കുന്നു.", അതിന്റെ വിവർത്തനം ഞങ്ങൾ ഒരു വർഷം മുമ്പ് പ്രസിദ്ധീകരിച്ചു.

അത്തരമൊരു നടപ്പാക്കലിന്റെ ഗുണങ്ങൾ

• ഒരു നോഡിനായി ഒരു ഡ്രൈവർ രജിസ്റ്റർ ചെയ്യുന്നത് പോലുള്ള അടിസ്ഥാന കാര്യങ്ങൾക്കായി, കുബർനെറ്റസ് ഡെവലപ്പർമാർ ഒരു കൂട്ടം കണ്ടെയ്‌നറുകൾ നടപ്പിലാക്കി. Flexvolume പ്ലഗിൻ ചെയ്‌തതുപോലെ, കഴിവുകളുള്ള ഒരു JSON പ്രതികരണം നിങ്ങൾ ഇനി സൃഷ്‌ടിക്കേണ്ടതില്ല.
• എക്സിക്യൂട്ടബിൾ ഫയലുകൾ നോഡുകളിലേക്ക് "സ്ലിപ്പ്" ചെയ്യുന്നതിനുപകരം, ഞങ്ങൾ ഇപ്പോൾ ക്ലസ്റ്ററിലേക്ക് പോഡുകൾ അപ്‌ലോഡ് ചെയ്യുന്നു. Kubernetes ൽ നിന്ന് ഞങ്ങൾ ആദ്യം പ്രതീക്ഷിക്കുന്നത് ഇതാണ്: എല്ലാ പ്രക്രിയകളും Kubernetes പ്രിമിറ്റീവ് ഉപയോഗിച്ച് വിന്യസിച്ചിരിക്കുന്ന കണ്ടെയ്‌നറുകളിൽ സംഭവിക്കുന്നു.
• സങ്കീർണ്ണമായ ഡ്രൈവറുകൾ നടപ്പിലാക്കാൻ നിങ്ങൾ ഇനി ഒരു RPC സെർവറും RPC ക്ലയന്റും വികസിപ്പിക്കേണ്ടതില്ല. ക്യുബെർനെറ്റസ് ഡെവലപ്പർമാർ ഞങ്ങൾക്ക് വേണ്ടി ക്ലയന്റ് നടപ്പിലാക്കി.
• കമാൻഡ് ലൈൻ ആർഗ്യുമെന്റുകളിലൂടെ കടന്നുപോകുന്നതിനേക്കാൾ gRPC പ്രോട്ടോക്കോളിൽ പ്രവർത്തിക്കാൻ ആർഗ്യുമെന്റുകൾ കൈമാറുന്നത് കൂടുതൽ സൗകര്യപ്രദവും വഴക്കമുള്ളതും വിശ്വസനീയവുമാണ്. ഒരു സ്റ്റാൻഡേർഡ് gRPC രീതി ചേർത്ത് CSI-ലേക്ക് വോളിയം ഉപയോഗ മെട്രിക്‌സിനുള്ള പിന്തുണ എങ്ങനെ ചേർക്കാമെന്ന് മനസിലാക്കാൻ, നിങ്ങൾക്ക് വായിക്കാം: ഞങ്ങളുടെ പിൻവലിക്കൽ അഭ്യർത്ഥന vsphere-csi ഡ്രൈവറിനായി.
• ഐപിസി സോക്കറ്റുകൾ വഴിയാണ് ആശയവിനിമയം നടക്കുന്നത്, അതിനാൽ കുബെലെറ്റ് ശരിയായ പോഡിലേക്ക് അഭ്യർത്ഥന അയച്ചോ എന്ന് ആശയക്കുഴപ്പത്തിലാകരുത്.

ഈ ലിസ്റ്റ് നിങ്ങളെ എന്തെങ്കിലും ഓർമ്മപ്പെടുത്തുന്നുണ്ടോ? CSI യുടെ ഗുണങ്ങൾ ഇവയാണ് അതേ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു, Flexvolume പ്ലഗിൻ വികസിപ്പിക്കുമ്പോൾ കണക്കിലെടുക്കാത്തവ.

കണ്ടെത്തലുകൾ

ഡാറ്റാ വെയർഹൗസുകളുമായി സംവദിക്കുന്നതിനുള്ള ഇഷ്‌ടാനുസൃത പ്ലഗിനുകൾ നടപ്പിലാക്കുന്നതിനുള്ള ഒരു മാനദണ്ഡമെന്ന നിലയിൽ CSI സമൂഹം വളരെ ഊഷ്മളമായി സ്വീകരിച്ചു. മാത്രമല്ല, അവയുടെ ഗുണങ്ങളും വൈദഗ്ധ്യവും കാരണം, Ceph അല്ലെങ്കിൽ AWS EBS പോലുള്ള സ്റ്റോറേജ് സിസ്റ്റങ്ങൾക്കായി പോലും CSI ഡ്രൈവറുകൾ സൃഷ്ടിക്കപ്പെടുന്നു, അവയുമായി പ്രവർത്തിക്കാനുള്ള പ്ലഗിനുകൾ Kubernetes-ന്റെ ആദ്യ പതിപ്പിൽ ചേർത്തു.

2019-ന്റെ തുടക്കത്തിൽ, ഇൻ-ട്രീ പ്ലഗിനുകൾ കാലഹരണപ്പെട്ടതായി പ്രഖ്യാപിച്ചു. Flexvolume പ്ലഗിൻ പിന്തുണയ്ക്കുന്നത് തുടരാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു, പക്ഷേ അതിനായി പുതിയ പ്രവർത്തനം വികസിപ്പിക്കില്ല.

ഞങ്ങൾക്ക് ഇതിനകം തന്നെ ceph-csi, vsphere-csi ഉപയോഗിച്ച അനുഭവമുണ്ട്, ഈ ലിസ്റ്റിലേക്ക് ചേർക്കാൻ ഞങ്ങൾ തയ്യാറാണ്! ഇതുവരെ, CSI അതിന് നൽകിയിട്ടുള്ള ടാസ്‌ക്കുകളുമായി പൊരുതുന്നു, പക്ഷേ ഞങ്ങൾ കാത്തിരുന്ന് കാണാം.

പുതിയതെല്ലാം പഴയതിനെക്കുറിച്ചുള്ള നല്ല പുനർവിചിന്തനമാണെന്ന് മറക്കരുത്!

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «കണ്ടെയ്നർ സ്റ്റോറേജ് ഇന്റർഫേസ് ഞങ്ങൾ മനസ്സിലാക്കുന്നു (കുബർനെറ്റസിൽ മാത്രമല്ല)";
• «റൂക്ക് ചെയ്യണോ വേണ്ടയോ - അതാണ് ചോദ്യം";
• «വോളിയം സ്നാപ്പ്ഷോട്ടുകളുടെ ആൽഫ പതിപ്പ് കുബർനെറ്റസിൽ അവതരിപ്പിക്കുന്നു".

അവലംബം: www.habr.com