🥇 په کبرنیټس کې د ذخیره کولو لپاره حجم پلگ ان: له Flexvolume څخه CSI ته

بیرته کله چې Kubernetes لاهم v1.0.0 و، د حجم پلگ ان شتون درلود. دوی د دوامداره (دایمي) کانټینر ډیټا ذخیره کولو لپاره سیسټمونه کوبرنیټس سره وصل کولو ته اړتیا درلوده. د دوی شمیر لږ و، او د لومړي په منځ کې دا ډول ذخیره چمتو کونکي وو لکه GCE PD، Ceph، AWS EBS او نور.

پلگ ان د کبرنیټس سره لیږدول شوي ، له همدې امله دوی خپل نوم ترلاسه کړ - په ونې کې. په هرصورت، د ډیری لپاره، د داسې پلگ انونو موجوده سیټ کافي نه و. هنرمندانو د پیچونو په کارولو سره د Kubernetes کور ته ساده پلگ انونه اضافه کړل، وروسته له هغه چې دوی خپل Kubernetes راټول کړل او په خپلو سرورونو کې یې نصب کړل. مګر د وخت په تیریدو سره ، د کبرنیټس پراختیا کونکي پدې پوه شول کب ستونزه نشي حل کیدی. خلک اړتیا لري کب نیولو. او د Kubernetes v1.2.0 په خوشې کولو کې دا ښکاره شوه ...

د فلیکس حجم پلگ ان: لږترلږه کب نیولو راډ

د کوبرنیټس پراختیا کونکو د 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، او د دې سره په ریښتیني وخت کې د حجمونو اندازه کولو وړتیا ، تاسو کولی شئ خپل ځان وپیژنئ زموږ د وتلو غوښتنه په Rook Ceph Operator کې.

او دلته د 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 ډرایور اپلوډ کول یو غیر معمولي کار وګرځید. په لاسي ډول یوځل عملیات ترسره کولو سره ، د داسې وضعیت سره مخ کیدل اسانه دي چیرې چې نوي نوډونه په کلستر کې څرګندیږي: د نوي نوډ اضافه کولو له امله ، اتوماتیک افقی اندازه کول ، یا - څه بد دي - د خرابۍ له امله د نوډ بدلول. په دې حالت کې، د دې نوډونو ذخیره کولو سره کار باید ترسره شي ناممکن دی، تر هغه چې تاسو لاهم په لاسي ډول دوی ته د Flexvolume ډرایور اضافه کړئ.

د دې ستونزې د حل لاره د Kubernetes primitives څخه یوه وه - DaemonSet. کله چې یو نوی نوډ په کلستر کې ښکاره شي، دا په اتوماتيک ډول زموږ د ډیمون سیټ څخه پوډ لري، کوم چې د Flexvolume ډرایورانو موندلو لپاره د لارې په اوږدو کې ځایی حجم تړل کیږي. د بریالۍ رامینځته کولو سره ، پوډ د ډریور لپاره اړین فایلونه کاپي کوي ترڅو ډیسک ته کار وکړي.

دلته د 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>

... او د 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 ډرایور کارول کیږي دا په کلستر نوډ کې د ډیری ذخیره کولو لپاره د دې لپاره اړین سافټویر باید نصب شي (د مثال په توګه، د سیف لپاره د سیف عام کڅوړه). په پیل کې، د Flexvolume پلگ ان د داسې پیچلي سیسټمونو پلي کولو لپاره ډیزاین شوی نه و.

د دې ستونزې اصلي حل د Rook آپریټر د Flexvolume ډرایور پلي کولو کې لیدل کیدی شي:

ډرایور پخپله د RPC پیرودونکي په توګه ډیزاین شوی. د مخابراتو لپاره IPC ساکټ په ورته لارښود کې موقعیت لري چې پخپله ډرایور دی. موږ په یاد لرو چې د ډرایور فایلونو کاپي کولو لپاره دا به ښه وي چې ډیمون سیټ وکاروئ ، کوم چې لارښود د ډرایور سره د حجم په توګه وصلوي. د اړین روک ډرایور فایلونو کاپي کولو وروسته، دا پوډ نه مړ کیږي، مګر د بشپړ شوي RPC سرور په توګه د ضمیمه حجم له لارې د IPC ساکټ سره وصل کیږي. د سیف عام کڅوړه دمخه د پوډ کانټینر دننه نصب شوې. د آی.پی.سی ساکټ ډاډ ورکوي چې کوبیلټ به په سمه توګه د هغه پوډ سره اړیکه ونیسي چې په ورته نوډ کې موقعیت لري. هر څه په زړه پوري ساده دي! ..

الوداع، زموږ په زړه پورې ... د ونې پلگ ان!

د Kubernetes پراختیا کونکو وموندله چې په کور کې د ذخیره کولو لپاره د پلگ انونو شمیر شل دی. او په دوی کې هر یو کې بدلون، یوه یا بله لاره، د بشپړ کبرنیټ خوشې کولو دورې څخه تیریږي.

دا معلومه شوه چې د ذخیره کولو پلگ ان نوې نسخه کارولو لپاره، تاسو اړتیا لرئ ټول کلستر تازه کړئ. د دې سربیره، تاسو شاید حیران شئ چې د کبرنیټس نوې نسخه به ناڅاپه د هغه لینکس کرنل سره مطابقت ونه لري چې تاسو یې کاروئ ... نو تاسو خپلې اوښکې پاکې کړئ او خپل غاښونه پاک کړئ، د خپل مدیریت او کاروونکو سره همغږي وکړئ. د لینکس کرنل او کبرنیټس کلستر تازه کړئ. د خدماتو په چمتو کولو کې د ممکنه ځنډ سره.

وضعیت له طنز څخه ډیر دی، ایا تاسو فکر نه کوئ؟ دا ټولې ټولنې ته څرګنده شوه چې چلند کار نه کوي. د ارادې پریکړې سره ، د کوبرنیټس پراختیا کونکي اعلان کوي چې د ذخیره کولو سره کار کولو لپاره نوي پلگ انونه به نور په کرنل کې ونه منل شي. سربیره پردې ، لکه څنګه چې موږ دمخه پوهیږو ، د Flexvolume پلگ ان پلي کولو کې یو شمیر نیمګړتیاوې پیژندل شوي ...

په Kubernetes، CSI کې د حجمونو لپاره وروستي اضافه شوي پلگ ان ته وغوښتل شول چې مسله د دوامداره معلوماتو ذخیره کولو سره یو ځل او د ټولو لپاره وتړي. د دې الفا نسخه، په بشپړ ډول د ونې څخه بهر د CSI حجم پلگ انونو ته راجع کیږي، په خپرونه کې اعلان شوی. کوبرنیټ 1.9.

د کانټینر ذخیره کولو انٹرفیس ، یا CSI 3000 سپننګ راډ!

له هرڅه دمخه ، زه غواړم یادونه وکړم چې CSI نه یوازې د حجم پلگ ان دی ، مګر یو ریښتینی معیاري د ډیټا ګودامونو سره کار کولو لپاره د دودیز اجزاوو رامینځته کولو باندې. د کانټینر آرکیسټریشن سیسټمونه لکه کبرنیټس او میسوس باید "زده کړي" چې څنګه د دې معیار سره سم پلي شوي اجزاو سره کار وکړي. او اوس ما دمخه Kubernetes زده کړل.

په Kubernetes کې د CSI پلگ ان جوړښت څه دی؟ د CSI پلگ ان د ځانګړو چلوونکو سره کار کوي (د CSI چلوونکي) د دریمې ډلې پراختیا کونکو لخوا لیکل شوی. په کبرنیټس کې د CSI ډرایور باید لږترلږه دوه برخې ولري (پوډونه):

کنټرولر - بهرنۍ دوامداره ذخیره اداره کوي. دا د gRPC سرور په توګه پلي کیږي، د کوم لپاره چې ابتدايي کارول کیږي StatefulSet.
نوډ - د کلستر نوډونو ته د دوامداره ذخیره کولو لپاره مسؤل دی. دا د gRPC سرور په توګه هم پلي کیږي، مګر دا ابتدايي کاروي DaemonSet.

څنګه د CSI پلگ ان په Kubernetes کې کار کوي

تاسو کولی شئ د CSI د کار ځینې نور توضیحات زده کړئ، د بیلګې په توګه، د مقالې څخه "د C.S.I درک کول»، چې ژباړه موږ یو کال دمخه خپور کړ.

د دې ډول پلي کولو ګټې

د لومړني شیانو لپاره لکه د نوډ لپاره د ډرایور راجستر کول، د کوبرنیټس پراختیا کونکو د کانټینرونو سیټ پلي کړ. تاسو نور اړتیا نلرئ د JSON ځواب پخپله د وړتیاو سره رامینځته کړئ ، لکه څنګه چې د Flexvolume پلگ ان لپاره ترسره شوی و.
په نوډونو کې د اجرا وړ فایلونو "سلپ کولو" پرځای، موږ اوس کلستر ته پوډونه اپلوډ کوو. دا هغه څه دي چې موږ یې په پیل کې د کوبرنیټس څخه تمه کوو: ټولې پروسې د کانټینرونو دننه واقع کیږي چې د کوبرنیټس پریمیټیو په کارولو سره ځای په ځای شوي.
تاسو نور اړتیا نلرئ د پیچلي چلوونکو پلي کولو لپاره د RPC سرور او RPC پیرودونکي رامینځته کړئ. پیرودونکي زموږ لپاره د Kubernetes پراختیا کونکو لخوا پلي شوي.
د gRPC پروتوکول کې د کار کولو لپاره د دلیلونو لیږدول د کمانډ لاین دلیلونو له لارې تیرولو په پرتله خورا اسانه ، انعطاف وړ او د باور وړ دي. د دې پوهیدو لپاره چې څنګه د معیاري gRPC میتود اضافه کولو سره CSI ته د حجم کارولو میټریکونو لپاره ملاتړ اضافه کړئ ، تاسو لوستلی شئ: زموږ د وتلو غوښتنه د vsphere-csi ډرایور لپاره.
اړیکه د آی.پی.سی ساکټونو له لارې ترسره کیږي، ترڅو دا مغشوش نه شي چې آیا کوبیلټ سم پوډ ته غوښتنه لیږلې که نه.

ایا دا لیست تاسو ته کوم شی یادوي؟ د CSI ګټې دا دي د ورته ستونزو حل کول، کوم چې د Flexvolume پلگ ان رامینځته کولو پرمهال په پام کې نه و نیول شوي.

موندنو

CSI د ډیټا ګودامونو سره د متقابل عمل لپاره د دودیز پلگ انونو پلي کولو لپاره د معیار په توګه د ټولنې لخوا خورا تود هرکلی شوی. سربیره پردې ، د دوی د ګټو او استقامت له امله ، د CSI ډرایورونه حتی د ذخیره کولو سیسټمونو لپاره رامینځته شوي لکه Ceph یا AWS EBS ، د کار کولو لپاره پلگ ان چې د کوبرنیټس په لومړۍ نسخه کې اضافه شوي.

د 2019 په پیل کې، د ونې دننه پلگ ان متروک اعلان شوي دي. موږ پلان لرو چې د Flexvolume پلگ ان ملاتړ ته دوام ورکړو، مګر د دې لپاره به نوي فعالیت ته وده ورنکړو.

موږ پخپله د ceph-csi، vsphere-csi کارولو تجربه لرو او چمتو یو چې دې لیست کې اضافه کړو! تر دې دمه ، CSI دې ته ګمارل شوي دندو سره مبارزه کوي ، مګر موږ به انتظار وکړو او وګورو.

دا مه هېروئ چې هر څه نوي د زاړه په اړه ښه فکر کول دي!

PS

زموږ په بلاګ کې هم ولولئ:

سرچینه: www.habr.com

د کوبرنیټس ذخیره کولو لپاره حجم پلگ ان: له Flexvolume څخه CSI ته