Kubernetes သိုလှောင်မှုအတွက် အသံအတိုးအကျယ် ပလပ်အင်များ- Flexvolume မှ CSI အထိ

Kubernetes သည် v1.0.0 ဖြစ်နေဆဲကာလတွင်၊ အသံအတိုးအကျယ် ပလပ်အင်များ ရှိခဲ့သည်။ ဆက်တိုက် (အမြဲတမ်း) ကွန်တိန်နာဒေတာကို သိမ်းဆည်းရန်အတွက် Kubernetes နှင့် စနစ်များကို ချိတ်ဆက်ရန် ၎င်းတို့ကို လိုအပ်ပါသည်။ ၎င်းတို့၏ အရေအတွက်မှာ အနည်းငယ်သာရှိပြီး ပထမဦးစွာ GCE PD၊ Ceph၊ AWS EBS နှင့် အခြား သိုလှောင်မှုဝန်ဆောင်မှုပေးသူများထဲတွင် ပါဝင်ပါသည်။

ပလပ်အင်များကို Kubernetes နှင့်အတူ ပေးပို့ထားသောကြောင့် ၎င်းတို့သည် ၎င်းတို့၏အမည်ကို - in-tree ဖြင့် ရရှိခဲ့သည်။ သို့သော်၊ များစွာသောများအတွက်၊ ထိုကဲ့သို့သော plugins အစုံသည် မလုံလောက်တော့ပါ။ လက်မှုပညာသည်များသည် ဖာထေးမှုများကို အသုံးပြု၍ Kubernetes core သို့ ရိုးရှင်းသော ပလပ်အင်များကို ထည့်သွင်းပြီးနောက် ၎င်းတို့၏ကိုယ်ပိုင် Kubernetes များကို စုစည်းကာ ၎င်းတို့၏ဆာဗာများတွင် ထည့်သွင်းခဲ့သည်။ သို့သော် အချိန်ကြာလာသည်နှင့်အမျှ Kubernetes developer များသည် ယင်းကို သဘောပေါက်လာသည်။ ငါး ပြဿနာကို မဖြေရှင်းနိုင်ဘူး။ လူတွေလိုတယ်။ တံငါသည်. Kubernetes v1.2.0 ထုတ်ဝေမှုတွင် ၎င်းသည်...

Flexvolume ပလပ်အင်- အနည်းဆုံး ငါးမျှားတံ

Kubernetes ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် ပြင်ပမှဆော့ဖ်ဝဲရေးသားသူများမှအကောင်အထည်ဖော်ဆောင်ရွက်သည့် Flexvolume drivers များနှင့် လုပ်ဆောင်ရန်အတွက် ကိန်းရှင်များနှင့် နည်းလမ်းများ၏ ယုတ္တိမူဘောင်ဖြစ်သည့် FlexVolume ပလပ်အင်ကို ဖန်တီးခဲ့သည်။

ရပ်ပြီး FlexVolume driver က ဘာလဲဆိုတာကို အနီးကပ်လေ့လာကြည့်ရအောင်။ ဒါက သေချာပါတယ်။ executable ဖိုင် (binary ဖိုင်၊ Python script၊ Bash script စသည်ဖြင့်)၊ ၎င်းသည် လုပ်ဆောင်သောအခါတွင် command line arguments များကို ထည့်သွင်းပြီး JSON ဖော်မတ်ရှိ ကြိုတင်သိထားသော အကွက်များဖြင့် မက်ဆေ့ခ်ျကို ပြန်ပေးသည်။ ကွန်ဗင်းရှင်းအရ၊ ပထမ command line argument သည် အမြဲတမ်း method တစ်ခုဖြစ်ပြီး ကျန်သော arguments များသည် ၎င်း၏ parameters များဖြစ်သည်။

OpenShift တွင် CIFS မျှဝေမှုများအတွက် ချိတ်ဆက်မှုပုံစံ။ Flexvolume Driver - စင်တာတွင် ညာဘက်

အနည်းဆုံးနည်းလမ်းများ ဒါဟာတူ:

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 ယာဉ်မောင်းကို ခေါ်သောအခါ kubelet သည် အနာဂတ်တွင် လုပ်ဆောင်မည့် မြင်ကွင်းကို သတ်မှတ်ပေးမည်ဖြစ်သည်။ အထူးနည်းလမ်းများလည်းရှိပါသည်။ expandvolume и expandfsအသံအတိုးအကျယ်ကို အင်တိုက်အားတိုက် အရွယ်အစားပြောင်းရန် တာဝန်ရှိသော၊

နည်းလမ်းက ထပ်လောင်းတဲ့ အပြောင်းအလဲတွေရဲ့ ဥပမာတစ်ခုအနေနဲ့ expandvolume၊ ၎င်းသည် အချိန်နှင့်တပြေးညီ volumes များကို အရွယ်အစားပြောင်းလဲနိုင်သည့် စွမ်းရည်နှင့်အတူ၊ သင်ကိုယ်တိုင် ရင်းနှီးနိုင်သည်။ ကျွန်ုပ်တို့၏တောင်းဆိုချက် Rook Ceph အော်ပရေတာတွင်။

ဤသည်မှာ NFS နှင့်အလုပ်လုပ်ရန်အတွက် Flexvolume driver ကိုအကောင်အထည်ဖော်ခြင်း၏ဥပမာတစ်ခုဖြစ်သည်။

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

ဒါကြောင့် တကယ့် executable file ကို ပြင်ဆင်ပြီးရင်၊ ယာဉ်မောင်းကို Kubernetes အစုအဝေးသို့ အပ်လုဒ်လုပ်ပါ။. ယာဉ်မောင်းသည် ကြိုတင်သတ်မှတ်ထားသောလမ်းကြောင်းအတိုင်း အစုအဝေးတစ်ခုစီတွင် တည်ရှိနေရပါမည်။ မူရင်းအားဖြင့် ၎င်းကို ရွေးချယ်ခဲ့သည်-

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

... သို့သော် မတူညီသော Kubernetes ဖြန့်ဝေမှုများ (OpenShift၊ Rancher...) ကို အသုံးပြုသည့်အခါ လမ်းကြောင်းသည် ကွဲပြားနိုင်သည်။

Flexvolume ပြဿနာများ- ငါးမျှားတံကို မှန်ကန်စွာ ဘယ်လိုချရမလဲ။

Flexvolume driver ကို cluster node များသို့ အပ်လုဒ်တင်ခြင်းသည် အသေးအဖွဲမဟုတ်သော အလုပ်တစ်ခုဖြစ်သည်။ လုပ်ဆောင်ချက်ကို တစ်ကြိမ် ကိုယ်တိုင်လုပ်ဆောင်ပြီးပါက၊ node အသစ်များ အစုအဝေးတွင် ပေါ်လာသည့် အခြေအနေတစ်ခုကို အလွယ်တကူ ကြုံတွေ့ရနိုင်သည်- node အသစ်တစ်ခု ထပ်တိုးခြင်း၊ အလိုအလျောက် အလျားလိုက် အတိုင်းအတာ သို့မဟုတ် - ပိုဆိုးသည်မှာ ချွတ်ယွင်းမှုကြောင့် node အစားထိုးခြင်း ဖြစ်သည်။ ဤကိစ္စတွင်၊ ဤ node များပေါ်ရှိသိုလှောင်မှုနှင့်အတူအလုပ်လုပ်ရန်လုပ်ဆောင်သင့်သည်။ မဖြစ်နိုင်သောFlexvolume ဒရိုက်ဘာကို ၎င်းတို့ထံ သင်ကိုယ်တိုင်ထည့်မထည့်မချင်း၊

ဤပြဿနာအတွက် ဖြေရှင်းချက်မှာ Kubernetes ၏ မူလအစတစ်ခုဖြစ်သည်။ DaemonSet. node အသစ်တစ်ခု အစုအဝေးတွင်ပေါ်လာသောအခါ၊ ၎င်းတွင် Flexvolume drivers များကိုရှာဖွေရန် လမ်းကြောင်းတစ်လျှောက်တွင် local volume ကို ပူးတွဲပါရှိသည့် ကျွန်ုပ်တို့၏ DaemonSet မှ pod တစ်ခုပါရှိသည်။ ဖန်တီးမှုအောင်မြင်သောအခါတွင်၊ pod သည် ဒရိုက်ဘာအတွက် လိုအပ်သောဖိုင်များကို ကူးယူသည်။

ဤသည်မှာ 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 driver ကိုဖော်ပြရန်အတွက် Bash script ၏ဥပမာတစ်ခု။

#!/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

မိတ္တူလုပ်ဆောင်မှုကို မမေ့ရန် အရေးကြီးသည်။ atomic မဟုတ်ပါ။. စီမံဆောင်ရွက်ပေးခြင်းလုပ်ငန်းစဉ်မပြီးမီတွင် Kubelet သည် ယာဉ်မောင်းကို စတင်အသုံးပြုရန် အခွင့်အလမ်းမြင့်မားပြီး စနစ်ပျက်ဆီးသွားစေသည်။ မှန်ကန်သောနည်းလမ်းမှာ မတူညီသောအမည်တစ်ခုအောက်တွင် driver ဖိုင်များကို ဦးစွာကူးယူပြီး atomic rename operation ကိုအသုံးပြုရန်ဖြစ်သည်။

Rook အော်ပရေတာတွင် Ceph နှင့်အလုပ်လုပ်ပုံပုံ- ပုံကြမ်းရှိ Flexvolume ဒရိုက်ဘာသည် Rook အေးဂျင့်အတွင်းတွင်တည်ရှိသည်

Flexvolume drivers များကိုအသုံးပြုသောအခါနောက်ပြဿနာမှာ cluster node တစ်ခုရှိသိုလှောင်မှုအများစုအတွက်ဖြစ်သည်။ ၎င်းအတွက် လိုအပ်သော software ကို ထည့်သွင်းရပါမည်။ (ဥပမာ၊ Ceph အတွက် ဘုံအထုပ်)။ အစပိုင်းတွင်၊ Flexvolume ပလပ်အင်သည် ထိုကဲ့သို့သော ရှုပ်ထွေးသော စနစ်များကို အကောင်အထည်ဖော်ရန် ဒီဇိုင်းထုတ်ထားခြင်း မရှိပါ။

ဤပြဿနာအတွက် မူရင်းဖြေရှင်းချက်ကို Rook အော်ပရေတာ၏ Flexvolume ဒရိုက်ဘာအကောင်အထည်ဖော်မှုတွင် တွေ့မြင်နိုင်သည်-

Driver ကိုယ်တိုင်က RPC client တစ်ခုအနေနဲ့ ဒီဇိုင်းထုတ်ထားပါတယ်။ ဆက်သွယ်ရေးအတွက် IPC socket သည် driver ကိုယ်တိုင်နှင့်တူညီသောလမ်းညွှန်တွင်တည်ရှိသည်။ Driver ဖိုင်များကို ကူးယူရန် လမ်းကြောင်းကို volume အဖြစ် driver နှင့် ချိတ်ဆက်ပေးသော DaemonSet ကို အသုံးပြုခြင်းသည် ကောင်းမွန်ကြောင်း ကျွန်ုပ်တို့ သတိရပါသည်။ လိုအပ်သော rook driver ဖိုင်များကို ကူးယူပြီးနောက်၊ ဤ pod သည် မသေဘဲ၊ ပြည့်စုံသော RPC ဆာဗာအဖြစ် ပူးတွဲပါရှိသော volume မှတဆင့် IPC socket သို့ ချိတ်ဆက်သည်။ ceph-common package ကို pod container အတွင်းတွင် ထည့်သွင်းပြီးဖြစ်သည်။ IPC socket သည် kubelet သည် တူညီသော node ပေါ်တွင်ရှိသော pod နှင့်အတိအကျဆက်သွယ်နိုင်စေရန်သေချာစေသည်။ ပညာသားပါပါ အားလုံးရိုးရှင်းပါတယ်..!

နှုတ်ဆက်ပါသည်၊ ကျွန်ုပ်တို့၏ချစ်ခင်ရပါသော... သစ်ပင်တွင်းရှိ ပလပ်အင်များ။

core အတွင်းသိုလှောင်မှုအတွက် plugins အရေအတွက်သည် နှစ်ဆယ်ဖြစ်ကြောင်း Kubernetes developer များက တွေ့ရှိခဲ့သည်။ ၎င်းတို့တစ်ခုစီတွင် အပြောင်းအလဲတစ်ခုသည် Kubernetes ဖြန့်ချိမှုသံသရာတစ်ခုလုံးကို တစ်နည်းနည်းနှင့် ဖြတ်သန်းသွားပါသည်။

သိုလှောင်မှုပလပ်အင်၏ ဗားရှင်းအသစ်ကို အသုံးပြုရန်၊ သင်သည် အစုအဝေးတစ်ခုလုံးကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သည်။. ၎င်းအပြင် Kubernetes ဗားရှင်းအသစ်သည် သင်အသုံးပြုနေသည့် Linux kernel နှင့် ရုတ်တရက် တွဲသုံး၍မရသည့်အတွက် သင်အံ့သြသွားလိမ့်မည်... ထို့ကြောင့် သင့်မျက်ရည်များကို သုတ်ကာ သွားများကို အံကြိတ်ကာ သင့်စီမံခန့်ခွဲရေးနှင့် အသုံးပြုသူများနှင့် ပူးပေါင်းလုပ်ဆောင်ရမည့်အချိန်ဖြစ်သည်။ Linux kernel နှင့် Kubernetes အစုအဝေးကို အပ်ဒိတ်လုပ်ပါ။ ဝန်ဆောင်မှုများပေးဆောင်ရာတွင် ဖြစ်နိုင်ခြေရှိသော စက်ရပ်များ။

အ​ခြေအ​နေက ရယ်​စရာ​တွေထက်​ ပိုတယ်​လို့ ထင်​သလား။ ချဉ်းကပ်မှုဟာ အလုပ်မဖြစ်ဘူးဆိုတာ အသိုင်းအဝိုင်းတစ်ခုလုံးကို ရှင်းရှင်းလင်းလင်း သိလာခဲ့တယ်။ တမင်တကာ ဆုံးဖြတ်ချက်ဖြင့်၊ Kubernetes ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် သိုလှောင်မှုနှင့်အတူ လုပ်ဆောင်နိုင်သော ပလပ်အင်အသစ်များကို kernel တွင် လက်ခံတော့မည်မဟုတ်ကြောင်း ကြေညာသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သိထားပြီးဖြစ်သည့်အတိုင်း Flexvolume ပလပ်အင်ကို အကောင်အထည်ဖော်ရာတွင် ချို့ယွင်းချက်များစွာကို တွေ့ရှိခဲ့သည်။

Kubernetes၊ CSI ရှိ အတွဲများအတွက် နောက်ဆုံးထည့်သွင်းထားသော ပလပ်အင်သည် အမြဲမပြတ်ဒေတာသိုလှောင်မှုပြဿနာကို တစ်ကြိမ်တစ်ခါမျှ ပိတ်ရန် တောင်းဆိုထားသည်။ ၎င်း၏ alpha ဗားရှင်းကို Out-of-Tree CSI Volume Plugins အဖြစ် အပြည့်အဝ ရည်ညွှန်းပြီး ထုတ်ဝေမှုတွင် ကြေညာခဲ့သည်။ ကူဘာနက် 1.9.

Container Storage Interface သို့မဟုတ် CSI 3000 ချည်ငင်တံ။

ပထမဆုံးအနေနဲ့၊ CSI ဟာ အသံအတိုးအကျယ်ပလပ်အင်တစ်ခုသာမက တကယ့်အစစ်အမှန်ဖြစ်ကြောင်း သတိပြုစေချင်ပါတယ်။ စံ ဒေတာသိုလှောင်ရုံများနှင့် လုပ်ဆောင်ရန်အတွက် စိတ်ကြိုက်အစိတ်အပိုင်းများကို ဖန်တီးခြင်းအပေါ်. Kubernetes နှင့် Mesos ကဲ့သို့သော ကွန်တိန်နာ တီးမှုတ်စနစ်များသည် ဤစံနှုန်းအရ အကောင်အထည်ဖော်ထားသော အစိတ်အပိုင်းများနှင့် မည်သို့အလုပ်လုပ်ရမည်ကို “လေ့လာ” ရန် လိုအပ်ပါသည်။ ယခု ကျွန်ုပ်သည် Kubernetes ကို လေ့လာပြီးဖြစ်သည်။

Kubernetes ရှိ CSI ပလပ်အင်၏ဖွဲ့စည်းပုံမှာ အဘယ်နည်း။ CSI ပလပ်အင်သည် အထူးဒရိုင်ဘာများနှင့် အလုပ်လုပ်သည် (CSI ယာဉ်မောင်းများ) Third-party developer မှရေးသားသည်။ Kubernetes ရှိ CSI ဒရိုက်ဘာတစ်ခုတွင် အစိတ်အပိုင်းနှစ်ခု (pods) အနည်းဆုံးပါဝင်သင့်သည်-

• controller ကို — ပြင်ပအဆက်မပြတ်သိုလှောင်မှုများကို စီမံခန့်ခွဲသည်။ ၎င်းကို primitive ကိုအသုံးပြုထားသည့် gRPC ဆာဗာအဖြစ် အကောင်အထည်ဖော်ထားသည်။ StatefulSet.
• node — ဆက်တိုက်သိုလှောင်မှုအား အစုအဝေးများထံ တပ်ဆင်ရန် တာဝန်ရှိသည်။ ၎င်းကို gRPC ဆာဗာတစ်ခုအနေဖြင့်လည်း အကောင်အထည်ဖော်ထားသော်လည်း ၎င်းသည် primitive ကို အသုံးပြုထားသည်။ DaemonSet.

CSI ပလပ်အင်သည် Kubernetes တွင် အလုပ်လုပ်ပုံ

ဥပမာ၊ CSI ၏အလုပ်နှင့်ပတ်သက်သော အခြားအသေးစိတ်အချက်များအကြောင်း သင်လေ့လာနိုင်သည်၊ ဥပမာ၊ ဆောင်းပါး “C.S.I ကိုနားလည်ခြင်း။» မည်သည့်ဘာသာပြန်ဆိုချက် ကျွန်ုပ်တို့သည် လွန်ခဲ့သော တစ်နှစ်က ထုတ်ဝေခဲ့သည်။

ထိုကဲ့သို့ အကောင်အထည်ဖော်ခြင်း၏ အားသာချက်များ

• node တစ်ခုအတွက် ယာဉ်မောင်းတစ်ဦးကို မှတ်ပုံတင်ခြင်းကဲ့သို့ အခြေခံအရာများအတွက် Kubernetes developer များသည် containers အစုံကို အကောင်အထည်ဖော်ခဲ့သည်။ Flexvolume ပလပ်အင်အတွက် လုပ်ဆောင်ခဲ့သည့်အတိုင်း သင်ကိုယ်တိုင် လုပ်ဆောင်နိုင်စွမ်းရှိသည့် JSON တုံ့ပြန်မှုတစ်ခုကို သင်ထုတ်လုပ်ရန် မလိုအပ်တော့ပါ။
• စီစဥ်ရေးဖိုင်များကို node များပေါ်တွင် "ချော်လဲခြင်း" အစား၊ ယခုအခါ pods များကို အစုအဝေးသို့ အပ်လုဒ်လုပ်ပါသည်။ Kubernetes မှ ကျွန်ုပ်တို့ ကနဦးမျှော်လင့်ထားသည်မှာ ဤအရာဖြစ်သည်- Kubernetes primitives များကို အသုံးပြု၍ အသုံးပြုထားသော ကွန်တိန်နာအတွင်း လုပ်ငန်းစဉ်များအားလုံး ဖြစ်ပေါ်ပါသည်။
• ရှုပ်ထွေးသော ဒရိုက်ဘာများကို အကောင်အထည်ဖော်ရန် သင်သည် RPC ဆာဗာနှင့် RPC client ကို တီထွင်ရန် မလိုအပ်တော့ပါ။ ကလိုင်းယင့်ကို Kubernetes developer များက ကျွန်ုပ်တို့အတွက် အကောင်အထည်ဖော်ခဲ့သည်။
• gRPC ပရိုတိုကောကို လုပ်ဆောင်ရန် ငြင်းခုံမှုများကို ဖြတ်ကျော်ခြင်းသည် အမိန့်ပေးစာကြောင်း အကြောင်းပြချက်များမှတဆင့် ၎င်းတို့ကို ဖြတ်သန်းခြင်းထက် များစွာ ပိုမိုအဆင်ပြေ၊ ပြောင်းလွယ်ပြင်လွယ်နှင့် ယုံကြည်စိတ်ချရသည်။ စံသတ်မှတ်ထားသော gRPC နည်းလမ်းကို ထည့်သွင်းခြင်းဖြင့် CSI သို့ အသံအတိုးအကျယ်အသုံးပြုမှုမက်ထရစ်များအတွက် ပံ့ပိုးမှုထည့်နည်းကို နားလည်ရန်၊ သင်သည် ဖတ်နိုင်သည်- ကျွန်ုပ်တို့၏တောင်းဆိုချက် vsphere-csi driver အတွက်။
• ဆက်သွယ်ရေးသည် IPC socket များမှတဆင့်ဖြစ်ပေါ်သည်၊ kubelet မှတောင်းဆိုချက်ကိုမှန်ကန်သော pod သို့ပေးပို့ခြင်းရှိမရှိမရှုပ်ထွေးစေရန်ဖြစ်သည်။

ဤစာရင်းသည် သင့်အား တစ်စုံတစ်ရာကို အမှတ်ရနေပါသလား။ CSI ၏အားသာချက်များ ဒီလိုပဲ ပြဿနာတွေကို ဖြေရှင်းတယ်။Flexvolume ပလပ်အင်ကို တီထွင်သည့်အခါ ထည့်သွင်းစဉ်းစားခြင်းမရှိပါ။

တွေ့ရှိချက်များ

CSI သည် ဒေတာသိုလှောင်ရုံများနှင့် အပြန်အလှန်တုံ့ပြန်ရန်အတွက် စိတ်ကြိုက်ပလပ်အင်များကို အကောင်အထည်ဖော်ရန်အတွက် စံအဖြစ် ရပ်ရွာမှ အလွန်နွေးထွေးစွာ လက်ခံရရှိခဲ့ပါသည်။ ထို့အပြင် ၎င်းတို့၏ အားသာချက်များနှင့် ဘက်စုံစွမ်းဆောင်နိုင်မှုတို့ကြောင့် Kubernetes ၏ ပထမဆုံးဗားရှင်းတွင် ထည့်သွင်းထားသည့် Ceph သို့မဟုတ် AWS EBS ကဲ့သို့သော သိုလှောင်မှုစနစ်များအတွက်ပင် CSI ဒရိုက်ဘာများကို ဖန်တီးထားသည်။

2019 ခုနှစ်အစတွင်၊ in-tree ပလပ်အင်များ အသုံးမပြုတော့ကြောင်း ကြေညာထားသည်။. ကျွန်ုပ်တို့သည် Flexvolume ပလပ်အင်ကို ဆက်လက်ပံ့ပိုးရန် စီစဉ်ထားသော်လည်း ၎င်းအတွက် လုပ်ဆောင်ချက်အသစ်များကို တီထွင်မည်မဟုတ်ပါ။

ကျွန်ုပ်တို့ကိုယ်တိုင်က ceph-csi၊ vsphere-csi ကိုအသုံးပြုပြီး အတွေ့အကြုံရှိပြီးသားဖြစ်ပြီး ဤစာရင်းထဲသို့ထည့်ရန် အဆင်သင့်ဖြစ်နေပါပြီ။ ယခုအချိန်အထိ၊ CSI သည် ၎င်းအား ပေးအပ်ထားသော တာဝန်များကို အပြင်းအထန် ကိုင်တွယ်ဖြေရှင်းနေသော်လည်း ကျွန်ုပ်တို့ စောင့်မျှော်ကြည့်ရှုပါမည်။

အသစ်သောအရာတိုင်းသည် အဟောင်းကို ပြန်လည်တွေးတောခြင်းဖြစ်သည်ကို မမေ့ပါနှင့်။

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «Container Storage Interface ကို ကျွန်ုပ်တို့ နားလည်သည် ( Kubernetes တွင်သာမက)";
• «Rook သို့မဟုတ် Rook သို့မဟုတျ - အဲဒါက မေးစရာပါ။";
• «Kubernetes တွင် volume snapshots ၏ အယ်လ်ဖာဗားရှင်းကို မိတ်ဆက်ခြင်း။"။

source: www.habr.com