ڪبرنيٽس اسٽوريج لاءِ حجم پلگ ان: Flexvolume کان CSI تائين

واپس جڏهن ڪبرنيٽس اڃا تائين 1.0.0 هو، اتي حجم پلگ ان هئا. انهن کي مسلسل (مستقل) ڪنٽينر ڊيٽا کي محفوظ ڪرڻ لاءِ سسٽم کي ڪبرنيٽس سان ڳنڍڻ جي ضرورت هئي. انهن جو تعداد ننڍڙو هو، ۽ پهرين ۾ اهڙيون اسٽوريج فراهم ڪندڙ هئا جيئن GCE PD، Ceph، AWS EBS ۽ ٻيا.

پلگ ان کي ڪبرنيٽس سان گڏ پهچايو ويو، ڇو ته انهن کي پنهنجو نالو مليو - وڻ ۾. جڏهن ته، ڪيترن ئي لاء، اهڙي پلگ ان جو موجوده سيٽ ناگزير ٿي ويو. ڪاريگرن پيچس استعمال ڪندي ڪبرنيٽس ڪور ۾ سادو پلگ ان شامل ڪيو، جنهن کان پوءِ انهن پنهنجن ڪبرنيٽس کي گڏ ڪيو ۽ ان کي پنهنجي سرور تي انسٽال ڪيو. پر وقت سان گڏ، Kubernetes ڊولپرز اهو محسوس ڪيو مڇي مسئلو حل نه ٿو ڪري سگھجي. ماڻهن جي ضرورت آهي مڇي مارڻ وارو رستو. ۽ Kubernetes v1.2.0 جي ڇڏڻ ۾ اهو ظاهر ٿيو ...

Flexvolume پلگ ان: گھٽ ۾ گھٽ مڇي مارڻ واري راڊ

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/имя_поставщика_хранилища~имя_драйвера/

... پر جڏهن مختلف ڪبرنيٽس ڊسٽريبيوشن استعمال ڪندي (OpenShift، Rancher...) رستو مختلف ٿي سگهي ٿو.

Flexvolume مسئلا: مڇي مارڻ واري راڊ کي صحيح طريقي سان ڪيئن اڇلائي؟

Flexvolume ڊرائيور کي ڪلستر نوڊس تي اپ لوڊ ڪرڻ هڪ غير معمولي ڪم ٿي ويو. دستي طور تي هڪ ڀيرو آپريشن ڪرڻ سان، اهڙي صورتحال کي منهن ڏيڻ آسان آهي جتي ڪلستر ۾ نوان نوڊ ظاهر ٿين ٿا: نئين نوڊ جي اضافي جي ڪري، خودڪار افقي اسڪيلنگ، يا - ڇا خراب آهي - خرابي جي ڪري نوڊ جي متبادل. انهي حالت ۾، انهن نوڊس تي اسٽوريج سان ڪم ڪرڻ گهرجي ناممڪن آهي، جيستائين توھان اڃا تائين دستي طور تي شامل ڪريو Flexvolume ڊرائيور انھن کي.

هن مسئلي جو حل Kubernetes primitives مان هڪ هو. DaemonSet. جڏهن هڪ نئون نوڊ ڪلستر ۾ ظاهر ٿئي ٿو، اهو خودڪار طور تي اسان جي 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 ڊرائيورز اهو آهي ته ڪلستر نوڊ تي اڪثر اسٽوريج لاءِ ان لاءِ ضروري سافٽ ويئر انسٽال ڪيو وڃي (مثال طور، سيف-عام پيڪيج Ceph لاءِ). شروعات ۾، Flexvolume پلگ ان اهڙي پيچيده سسٽم کي لاڳو ڪرڻ لاء ٺهيل نه هئي.

هن مسئلي جو هڪ اصل حل ڏسي سگهجي ٿو Flexvolume ڊرائيور تي عملدرآمد روڪ آپريٽر:

ڊرائيور پاڻ کي آر پي سي ڪلائنٽ طور ٺهيل آهي. رابطي لاءِ IPC ساکٽ ساڳئي ڊاريڪٽري ۾ واقع آهي جيئن ڊرائيور پاڻ. اسان کي ياد آهي ته ڊرائيور فائلن کي نقل ڪرڻ لاءِ اهو استعمال ڪرڻ سٺو هوندو DaemonSet، جيڪو ڊاريڪٽري کي حجم جي طور تي ڊرائيور سان ڳنڍيندو آهي. ضروري روڪ ڊرائيور فائلن کي نقل ڪرڻ کان پوء، هي پوڊ مري نه ٿو، پر هڪ مڪمل RPC سرور جي طور تي منسلڪ حجم ذريعي IPC ساکٽ سان ڳنڍيندو آهي. سيف-عام پيڪيج اڳ ۾ ئي پوڊ ڪنٽينر اندر نصب ٿيل آهي. IPC ساکٽ انهي ڳالهه کي يقيني بڻائي ٿو ته ڪوبلٽ بلڪل انهي پوڊ سان رابطو ڪندو جيڪو ساڳئي نوڊ تي واقع آهي. هر شئي سادي آهي! ..

الوداع، اسان جا پيارا... وڻن ۾ پلگ ان!

Kubernetes ڊولپرز دريافت ڪيو ته ڪور اندر اسٽوريج لاء پلگ ان جو تعداد ويهه آهي. ۽ انهن مان هر هڪ ۾ هڪ تبديلي، هڪ طريقو يا ٻيو، مڪمل ڪبرنيٽس ڇڏڻ واري چڪر مان گذري ٿو.

اهو ظاهر ٿئي ٿو ته اسٽوريج پلگ ان جو نئون نسخو استعمال ڪرڻ لاء، توھان کي پوري ڪلستر کي اپڊيٽ ڪرڻ جي ضرورت آھي. ان کان علاوه، توهان کي حيرت ٿي سگھي ٿي ته ڪبرنيٽس جو نئون ورزن اوچتو ئي لينڪس ڪنيل سان مطابقت نه رکندو آھي جيڪو توھان استعمال ڪري رھيا آھيو... تنھنڪري توھان پنھنجا ڳوڙھا صاف ڪريو ۽، پنھنجي ڏندن کي پڪڙي، پنھنجي انتظاميا ۽ استعمال ڪندڙن سان وقت بوقت تعاون ڪريو. لينڪس ڪرنل ۽ ڪبرنيٽس ڪلستر کي اپڊيٽ ڪريو. خدمتن جي فراهمي ۾ ممڪن دير سان.

صورتحال مزاحيه کان وڌيڪ آهي، ڇا توهان نه سوچيو؟ اهو سڄي ڪميونٽي تي واضح ٿي ويو ته اهو طريقو ڪم نه ڪري رهيو هو. هڪ ارادي فيصلي سان، ڪبرنيٽس ڊولپرز اعلان ڪن ٿا ته اسٽوريج سان ڪم ڪرڻ لاء نئين پلگ ان کي وڌيڪ قبول نه ڪيو ويندو ڪرنل ۾. ان کان علاوه، جيئن اسان اڳ ۾ ئي ڄاڻون ٿا، Flexvolume پلگ ان جي عمل ۾ ڪيتريون ئي نقصن جي نشاندهي ڪئي وئي ...

Kubernetes، CSI ۾ حجمن لاءِ تازو شامل ڪيل پلگ ان، هڪ ڀيرو ۽ سڀني لاءِ مسلسل ڊيٽا اسٽوريج سان مسئلو بند ڪرڻ لاءِ چيو ويو. ان جو الفا ورزن، وڌيڪ مڪمل طور تي آئوٽ آف ٽري CSI حجم پلگ ان جو حوالو ڏنو ويو، رليز ۾ اعلان ڪيو ويو ڪبرنيٽز 1.9.

ڪنٽينر اسٽوريج انٽرفيس، يا CSI 3000 اسپننگ راڊ!

سڀ کان پهريان، مان اهو نوٽ ڪرڻ چاهيندس ته CSI صرف هڪ حجم پلگ ان ناهي، پر هڪ حقيقي معياري ڊيٽا گودامن سان ڪم ڪرڻ لاءِ ڪسٽم اجزاء ٺاهڻ تي. ڪنٽينر آرڪيسٽريشن سسٽم جهڙوڪ ڪبرنيٽس ۽ ميسوس کي "سکڻ" گهرجي ته هن معيار جي مطابق لاڳو ڪيل اجزاء سان ڪيئن ڪم ڪجي. ۽ هاڻي مون اڳ ۾ ئي Kubernetes سکيو آهي.

Kubernetes ۾ CSI پلگ ان جي جوڙجڪ ڇا آهي؟ CSI پلگ ان خاص ڊرائيورن سان ڪم ڪري ٿو (CSI ڊرائيور) ٽئين پارٽي ڊولپرز پاران لکيل آهي. ڪبرنيٽس ۾ هڪ سي ايس آئي ڊرائيور گهٽ ۾ گهٽ ٻن حصن تي مشتمل هجڻ گهرجي (پڊ):

• ڪنٽرولر - ٻاهرين مسلسل اسٽوريج کي منظم ڪري ٿو. اهو هڪ gRPC سرور جي طور تي لاڳو ڪيو ويو آهي، جنهن لاء پرائمري استعمال ڪيو ويندو آهي StatefulSet.
• نوڊ - ڪلستر نوڊس تي مسلسل اسٽوريج کي وڌائڻ لاء ذميوار آهي. اهو پڻ هڪ gRPC سرور جي طور تي لاڳو ڪيو ويو آهي، پر اهو استعمال ڪري ٿو پرائمري DaemonSet.

ڪبرنيٽس ۾ CSI پلگ ان ڪيئن ڪم ڪري ٿي

توهان CSI جي ڪم جي ڪجهه ٻين تفصيلن بابت سکي سگهو ٿا، مثال طور، آرٽيڪل مان "سمجھڻ C.S.I.»، جنهن جو ترجمو اسان هڪ سال اڳ شايع ڪيو.

اهڙي عمل جي فائدن

• بنيادي شين لاءِ جيئن هڪ نوڊ لاءِ ڊرائيور کي رجسٽر ڪرڻ، ڪبرنيٽس ڊولپرز ڪنٽينرز جو هڪ سيٽ لاڳو ڪيو. توھان کي ھاڻي ضرورت ناھي ته JSON جواب ٺاھيو پنھنجي صلاحيتن سان، جيئن Flexvolume پلگ ان لاءِ ڪيو ويو آھي.
• بجاءِ ”سلپ ڪرڻ“ قابل عمل فائلن کي نوڊس تي، اسان ھاڻي ڪلستر تي پوڊ اپلوڊ ڪندا آھيون. اھو اھو آھي جيڪو اسان شروعات ۾ ڪبرنيٽس کان توقع ڪريون ٿا: سڀ عمل ڪنٽينرز جي اندر ٿين ٿا جيڪي ڪبرنيٽس پرائمري استعمال ڪندي ترتيب ڏنل آھن.
• توهان کي وڌيڪ ضرورت نه آهي آر پي سي سرور ۽ آر پي سي ڪلائنٽ کي ترقي ڪرڻ لاء پيچيده ڊرائيور لاڳو ڪرڻ لاء. ڪلائنٽ اسان لاءِ Kubernetes ڊولپرز پاران لاڳو ڪيو ويو.
• gRPC پروٽوڪول تي ڪم ڪرڻ لاءِ دليلن کي پاس ڪرڻ ان کان وڌيڪ آسان، لچڪدار ۽ قابل اعتماد آھي انھن کي ڪمانڊ لائن دليلن ذريعي گذرڻ کان. سمجھڻ لاءِ ته ڪيئن مدد شامل ڪجي حجم جي استعمال جي ماپن لاءِ CSI ۾ معياري gRPC طريقو شامل ڪندي، توھان پڙھي سگھو ٿا: اسان جي ڇڪڻ جي درخواست vsphere-csi ڊرائيور لاءِ.
• ڪميونيڪيشن IPC ساکٽس ذريعي ٿئي ٿي، ته جيئن مونجهارو نه ٿئي ته ڪوبلٽ صحيح پوڊ ڏانهن درخواست موڪلي آهي.

ڇا هي فهرست توهان کي ڪجهه ياد ڏياريندو آهي؟ CSI جا فائدا آھن انهن ئي مسئلن کي حل ڪرڻ، جن کي Flexvolume پلگ ان کي ترقي ڪرڻ وقت حساب ۾ نه ورتو ويو.

پهچڻ

CSI ڊيٽا گودامن سان رابطي لاءِ ڪسٽم پلگ ان لاڳو ڪرڻ لاءِ هڪ معيار جي طور تي ڪميونٽي طرفان تمام گرمجوشي سان وصول ڪيو ويو. ان کان علاوه، انهن جي فائدن ۽ استحڪام جي ڪري، سي ايس آئي ڊرائيور پڻ ٺاهيا ويا آهن اسٽوريج سسٽم جهڙوڪ Ceph يا AWS EBS، ڪم ڪرڻ لاء پلگ ان جيڪي ڪبرنيٽس جي پهرين ورزن ۾ شامل ڪيا ويا آهن.

2019 جي شروعات ۾، وڻن ۾ پلگ ان ختم ٿيل قرار ڏنو ويو آهي. اسان Flexvolume پلگ ان جي حمايت جاري رکڻ جو ارادو رکون ٿا، پر ان لاءِ نئين ڪارڪردگي کي ترقي نه ڪنداسين.

اسان پاڻ اڳ ۾ ئي ceph-csi، vsphere-csi استعمال ڪرڻ جو تجربو ڪيو آهي ۽ هن لسٽ ۾ شامل ڪرڻ لاء تيار آهيون! هينئر تائين، سي ايس آئي ان کي تفويض ڪيل ڪمن سان مقابلو ڪري رهيو آهي، پر اسان انتظار ڪنداسين ۽ ڏسنداسين.

اهو نه وساريو ته هر شيء نئين آهي پراڻي جي ٻيهر سوچڻ!

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

• «اسان سمجھون ٿا ڪنٽينر اسٽوريج انٽرفيس (ڪيبرنيٽس ۾ ۽ نه رڳو)"؛
• «روڪ ڏانهن يا روڪ ڏانهن نه - اهو سوال آهي"؛
• «ڪبرنيٽس ۾ حجم سنيپ شاٽ جو الفا ورزن متعارف ڪرايو».

جو ذريعو: www.habr.com