ປັ໊ກອິນປະລິມານສໍາລັບການເກັບຮັກສາ Kubernetes: ຈາກ Flexvolume ເຖິງ CSI

ກັບໄປໃນເວລາທີ່ Kubernetes ຍັງ v1.0.0, ມີ plugins ປະລິມານ. ພວກເຂົາຕ້ອງການເພື່ອເຊື່ອມຕໍ່ລະບົບກັບ Kubernetes ສໍາລັບການເກັບຮັກສາຂໍ້ມູນບັນຈຸ (ຖາວອນ) ຄົງທີ່. ຈໍານວນຂອງພວກເຂົາແມ່ນນ້ອຍ, ແລະໃນບັນດາຜູ້ທໍາອິດແມ່ນຜູ້ໃຫ້ບໍລິການເກັບຮັກສາເຊັ່ນ GCE PD, Ceph, AWS EBS ແລະອື່ນໆ.

ປັ໊ກອິນຖືກຈັດສົ່ງພ້ອມກັບ Kubernetes, ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຂົາໄດ້ຮັບຊື່ - in-tree. ຢ່າງໃດກໍຕາມ, ສໍາລັບຈໍານວນຫຼາຍ, ຊຸດທີ່ມີຢູ່ແລ້ວຂອງ plugins ດັ່ງກ່າວໄດ້ຫັນອອກບໍ່ພຽງພໍ. ຊ່າງຫັດຖະກໍາໄດ້ເພີ່ມ plugins ງ່າຍໆໃສ່ຫຼັກ Kubernetes ໂດຍໃຊ້ patches, ຫຼັງຈາກນັ້ນພວກເຂົາປະກອບ Kubernetes ຂອງຕົນເອງແລະຕິດຕັ້ງມັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງພວກເຂົາ. ແຕ່ເມື່ອເວລາຜ່ານໄປ, ຜູ້ພັດທະນາ Kubernetes ໄດ້ຮັບຮູ້ສິ່ງນັ້ນ ປາ ບັນຫາບໍ່ສາມາດແກ້ໄຂໄດ້. ປະຊາຊົນຕ້ອງການ ຄັນ​ເບັດ. ແລະໃນການປ່ອຍ Kubernetes v1.2.0 ມັນປາກົດວ່າ ...

ປັ໊ກອິນ Flexvolume: ທໍ່ຫາປາໜ້ອຍທີ່ສຸດ

ນັກພັດທະນາ Kubernetes ໄດ້ສ້າງປລັກອິນ FlexVolume, ເຊິ່ງເປັນກອບທີ່ມີເຫດຜົນຂອງຕົວແປ ແລະວິທີການເຮັດວຽກກັບໄດເວີ Flexvolume ທີ່ປະຕິບັດໂດຍຜູ້ພັດທະນາພາກສ່ວນທີສາມ.

ໃຫ້ຢຸດເຊົາແລະເບິ່ງຢ່າງໃກ້ຊິດກ່ຽວກັບສິ່ງທີ່ໄດເວີ FlexVolume ແມ່ນຫຍັງ. ນີ້ແມ່ນແນ່ນອນ ໄຟລ໌ທີ່ສາມາດປະຕິບັດໄດ້ (ໄຟລ໌ binary, Python script, Bash script, ແລະອື່ນໆ), ເຊິ່ງ, ເມື່ອປະຕິບັດ, ເອົາ arguments ເສັ້ນຄໍາສັ່ງເປັນການປ້ອນຂໍ້ມູນແລະສົ່ງຄືນຂໍ້ຄວາມທີ່ມີຊ່ອງຂໍ້ມູນເບື້ອງຕົ້ນໃນຮູບແບບ JSON. ໂດຍສົນທິສັນຍາ, ການໂຕ້ຖຽງແຖວຄໍາສັ່ງທໍາອິດແມ່ນວິທີການສະເຫມີ, ແລະການໂຕ້ຖຽງທີ່ຍັງເຫຼືອແມ່ນຕົວກໍານົດການຂອງມັນ.

ແຜນວາດການເຊື່ອມຕໍ່ສໍາລັບຮຸ້ນ CIFS ໃນ OpenShift. 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, ແລະດ້ວຍຄວາມສາມາດໃນການປັບຂະຫນາດປະລິມານໃນເວລາທີ່ແທ້ຈິງ, ທ່ານສາມາດຄຸ້ນເຄີຍກັບຕົວທ່ານເອງ ການ​ຮ້ອງ​ຂໍ​ດຶງ​ຂອງ​ພວກ​ເຮົາ​ ໃນ Rook Ceph Operator.

ແລະນີ້ແມ່ນຕົວຢ່າງຂອງການປະຕິບັດໄດເວີ Flexvolume ສໍາລັບການເຮັດວຽກກັບ NFS:

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. ໄດເວີຕ້ອງຕັ້ງຢູ່ໃນແຕ່ລະ node cluster ຕາມເສັ້ນທາງທີ່ກຳນົດໄວ້ລ່ວງໜ້າ. ໂດຍຄ່າເລີ່ມຕົ້ນມັນຖືກເລືອກ:

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

... ແຕ່ເມື່ອໃຊ້ການແຈກຢາຍ Kubernetes ທີ່ແຕກຕ່າງກັນ (OpenShift, Rancher...) ເສັ້ນທາງອາດຈະແຕກຕ່າງກັນ.

ບັນ​ຫາ Flexvolume​: ວິ​ທີ​ການ​ໂຍນ​ຕູ້​ປາ​ຢ່າງ​ຖືກ​ຕ້ອງ​?

ການອັບໂຫລດໄດເວີ Flexvolume ໄປໃສ່ກຸ່ມກຸ່ມໄດ້ກາຍມາເປັນໜ້າວຽກທີ່ບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ. ໄດ້ເຮັດການດໍາເນີນການດ້ວຍຕົນເອງຄັ້ງດຽວ, ມັນງ່າຍທີ່ຈະພົບກັບສະຖານະການທີ່ nodes ໃຫມ່ປາກົດຢູ່ໃນກຸ່ມ: ເນື່ອງຈາກການເພີ່ມຂອງ node ໃຫມ່, ປັບຕາມແນວນອນອັດຕະໂນມັດ, ຫຼື - ສິ່ງທີ່ຮ້າຍແຮງກວ່າເກົ່າ - ການທົດແທນຂອງ node ເນື່ອງຈາກ malfunction. ໃນກໍລະນີນີ້, ການເຮັດວຽກກັບການເກັບຮັກສາໃນ nodes ເຫຼົ່ານີ້ຄວນຈະເຮັດ ແມ່ນບໍ່ເປັນໄປໄດ້, ຈົນກ່ວາທ່ານຍັງເພີ່ມໄດເວີ Flexvolume ດ້ວຍຕົນເອງ.

ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ນີ້​ແມ່ນ​ຫນຶ່ງ​ໃນ​ຕົ້ນ​ຕໍ Kubernetes - DaemonSet. ເມື່ອ node ໃໝ່ປາກົດຢູ່ໃນກຸ່ມ, ມັນຈະມີຝັກຈາກ DaemonSet ຂອງພວກເຮົາໂດຍອັດຕະໂນມັດ, ເຊິ່ງມີປະລິມານທ້ອງຖິ່ນຕິດຢູ່ຕາມເສັ້ນທາງເພື່ອຊອກຫາໄດເວີ Flexvolume. ເມື່ອສ້າງສຳເລັດແລ້ວ, ຝັກຈະສຳເນົາໄຟລ໌ທີ່ຈຳເປັນເພື່ອໃຫ້ໄດເວີເຮັດວຽກໃສ່ແຜ່ນດິດ.

ນີ້ແມ່ນຕົວຢ່າງຂອງ DaemonSet ສໍາລັບການວາງ plugin 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>

... ແລະຕົວຢ່າງຂອງ Bash script ສໍາລັບການຈັດວາງໄດເວີ 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

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະບໍ່ລືມວ່າການດໍາເນີນງານສໍາເນົາ ບໍ່ແມ່ນປະລໍາມະນູ. ມີໂອກາດສູງທີ່ kubelet ຈະເລີ່ມໃຊ້ໄດເວີກ່ອນທີ່ຂະບວນການຈັດຫາຈະສໍາເລັດ, ເຮັດໃຫ້ລະບົບຂັດຂ້ອງ. ວິທີການທີ່ຖືກຕ້ອງແມ່ນທໍາອິດຄັດລອກໄຟລ໌ໄດເວີພາຍໃຕ້ຊື່ອື່ນ, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ການປ່ຽນຊື່ປະລໍາມະນູ.

ແຜນວາດຂອງການເຮັດວຽກກັບ Ceph ໃນ Rook operator: ໄດເວີ Flexvolume ໃນແຜນວາດແມ່ນຕັ້ງຢູ່ພາຍໃນຕົວແທນ Rook

ບັນຫາຕໍ່ໄປໃນເວລາທີ່ໃຊ້ໄດເວີ Flexvolume ແມ່ນວ່າສໍາລັບການເກັບຮັກສາສ່ວນໃຫຍ່ໃນ node cluster ຊອບແວທີ່ຈໍາເປັນສໍາລັບການນີ້ຕ້ອງໄດ້ຮັບການຕິດຕັ້ງ (ຕົວຢ່າງ, ຊຸດ ceph-ທົ່ວໄປສໍາລັບ Ceph). ໃນເບື້ອງຕົ້ນ, plugin Flexvolume ບໍ່ໄດ້ຖືກອອກແບບມາເພື່ອປະຕິບັດລະບົບສະລັບສັບຊ້ອນດັ່ງກ່າວ.

ການແກ້ໄຂຕົ້ນສະບັບຂອງບັນຫານີ້ສາມາດເຫັນໄດ້ໃນການປະຕິບັດໄດເວີ Flexvolume ຂອງຜູ້ປະຕິບັດການ Rook:

ໄດເວີຕົວມັນເອງຖືກອອກແບບມາເປັນລູກຄ້າ RPC. ເຕົ້າຮັບ IPC ສໍາລັບການສື່ສານແມ່ນຕັ້ງຢູ່ໃນໄດເລກະທໍລີດຽວກັນກັບຕົວຂັບເອງ. ພວກເຮົາຈື່ໄວ້ວ່າເພື່ອຄັດລອກໄຟລ໌ໄດເວີມັນຈະເປັນການດີທີ່ຈະໃຊ້ DaemonSet, ເຊິ່ງເຊື່ອມຕໍ່ໄດເລກະທໍລີກັບໄດເວີເປັນປະລິມານ. ຫຼັງຈາກການຄັດລອກໄຟລ໌ໄດເວີ rook ທີ່ຈໍາເປັນ, ຝັກນີ້ບໍ່ຕາຍ, ແຕ່ເຊື່ອມຕໍ່ກັບເຕົ້າສຽບ IPC ຜ່ານປະລິມານທີ່ຕິດຄັດມາເປັນເຄື່ອງແມ່ຂ່າຍ RPC ເຕັມຮູບແບບ. ຊຸດ ceph-common ໄດ້ຖືກຕິດຕັ້ງຢູ່ແລ້ວພາຍໃນກ່ອງບັນຈຸຝັກ. ເຕົ້າຮັບ IPC ຮັບປະກັນວ່າ kubelet ຈະຕິດຕໍ່ສື່ສານກັບຝັກທີ່ຕັ້ງຢູ່ໃນ node ດຽວກັນ. ທຸກສິ່ງທຸກຢ່າງ ingenious ແມ່ນງ່າຍດາຍ!..

ສະບາຍດີ, ທີ່ຮັກແພງຂອງພວກເຮົາ... plugins in-tree!

ນັກພັດທະນາ Kubernetes ຄົ້ນພົບວ່າຈໍານວນຂອງ plugins ສໍາລັບການເກັບຮັກສາພາຍໃນຫຼັກແມ່ນຊາວ. ແລະການປ່ຽນແປງໃນແຕ່ລະພວກມັນ, ບໍ່ທາງໃດທາງໜຶ່ງ, ຈະຜ່ານຮອບການປ່ອຍ Kubernetes ເຕັມຮູບແບບ.

ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ການ​ນໍາ​ໃຊ້​ສະ​ບັບ​ໃຫມ່​ຂອງ plugin ການ​ເກັບ​ຮັກ​ສາ​, ທ່ານຈໍາເປັນຕ້ອງປັບປຸງກຸ່ມທັງຫມົດ. ນອກເຫນືອໄປຈາກນີ້, ທ່ານອາດຈະຕົກຕະລຶງວ່າ Kubernetes ຮຸ່ນໃຫມ່ກໍ່ຈະກາຍເປັນທີ່ບໍ່ເຂົ້າກັນໄດ້ກັບ Linux kernel ທີ່ທ່ານກໍາລັງໃຊ້ ... ດັ່ງນັ້ນທ່ານເຊັດນ້ໍາຕາຂອງທ່ານແລະ, ກັດແຂ້ວ, ປະສານງານກັບການຄຸ້ມຄອງແລະຜູ້ໃຊ້ຂອງທ່ານ. ອັບເດດ kernel Linux ແລະກຸ່ມ Kubernetes. ດ້ວຍການຢຸດເວລາທີ່ເປັນໄປໄດ້ໃນການສະຫນອງການບໍລິການ.

ສະຖານະການແມ່ນຫຼາຍກວ່າຕະຫລົກ, ເຈົ້າຄິດບໍ? ມັນໄດ້ກາຍເປັນທີ່ຈະແຈ້ງຕໍ່ຊຸມຊົນທັງຫມົດວ່າວິທີການດັ່ງກ່າວບໍ່ໄດ້ຜົນ. ໂດຍການຕັດສິນໃຈທີ່ຕັ້ງໃຈ, ຜູ້ພັດທະນາ Kubernetes ປະກາດວ່າປລັກອິນໃຫມ່ສໍາລັບການເຮັດວຽກກັບບ່ອນເກັບມ້ຽນຈະບໍ່ຖືກຍອມຮັບເຂົ້າໃນ kernel ອີກຕໍ່ໄປ. ນອກຈາກນັ້ນ, ດັ່ງທີ່ພວກເຮົາຮູ້ແລ້ວ, ຂໍ້ບົກຜ່ອງຈໍານວນຫນຶ່ງໄດ້ຖືກກໍານົດໃນການປະຕິບັດຂອງ plugin Flexvolume ...

ປັ໊ກອິນທີ່ເພີ່ມຫຼ້າສຸດສໍາລັບປະລິມານໃນ Kubernetes, CSI, ໄດ້ຖືກຮຽກຮ້ອງໃຫ້ປິດບັນຫາດ້ວຍການເກັບຮັກສາຂໍ້ມູນຢ່າງຕໍ່ເນື່ອງຄັ້ງດຽວແລະສໍາລັບທັງຫມົດ. ຮຸ່ນ alpha ຂອງມັນ, ຖືກເອີ້ນວ່າ Out-of-Tree CSI Volume Plugins, ໄດ້ຖືກປະກາດໃນການປ່ອຍ ຄູໂບຕ້າ 1.9.

ການໂຕ້ຕອບການເກັບຮັກສາຕູ້ຄອນເທນເນີ, ຫຼື CSI 3000 spinning rod!

ກ່ອນອື່ນ ໝົດ, ຂ້າພະເຈົ້າຢາກສັງເກດວ່າ CSI ບໍ່ພຽງແຕ່ເປັນ plugin ປະລິມານ, ແຕ່ເປັນຈິງ ມາດຕະຖານ ກ່ຽວກັບການສ້າງອົງປະກອບທີ່ກໍາຫນົດເອງສໍາລັບການເຮັດວຽກກັບຄັງຂໍ້ມູນ. ລະບົບການປະສານສຽງຂອງຕູ້ຄອນເທນເນີເຊັ່ນ Kubernetes ແລະ Mesos ຄວນຈະ "ຮຽນຮູ້" ວິທີການເຮັດວຽກກັບອົງປະກອບທີ່ປະຕິບັດຕາມມາດຕະຖານນີ້. ແລະຕອນນີ້ຂ້ອຍໄດ້ຮຽນຮູ້ Kubernetes ແລ້ວ.

ໂຄງສ້າງຂອງ plugin CSI ໃນ Kubernetes ແມ່ນຫຍັງ? plugin CSI ເຮັດວຽກກັບໄດເວີພິເສດ (ໄດເວີ CSI) ຂຽນໂດຍຜູ້ພັດທະນາພາກສ່ວນທີສາມ. ໄດເວີ CSI ໃນ Kubernetes ຄວນມີຢ່າງໜ້ອຍສອງອົງປະກອບ (ຝັກ):

• ການຄວບຄຸມ — ຄຸ້ມ​ຄອງ​ການ​ເກັບ​ຮັກ​ສາ​ທີ່​ຄົງ​ຄ້າງ​ພາຍ​ນອກ​. ມັນຖືກປະຕິບັດເປັນເຄື່ອງແມ່ຂ່າຍ gRPC, ເຊິ່ງພື້ນຖານຖືກນໍາໃຊ້ StatefulSet.
• node — ຮັບຜິດຊອບຕໍ່ການຕິດຕັ້ງບ່ອນເກັບຂໍ້ມູນຄົງທີ່ໃສ່ກັບ nodes cluster. ມັນຍັງຖືກປະຕິບັດເປັນເຄື່ອງແມ່ຂ່າຍ gRPC, ແຕ່ມັນໃຊ້ primitive DaemonSet.

Plugin CSI ເຮັດວຽກແນວໃດໃນ Kubernetes

ທ່ານສາມາດຮຽນຮູ້ກ່ຽວກັບລາຍລະອຽດອື່ນໆຂອງວຽກງານຂອງ CSI, ສໍາລັບການຍົກຕົວຢ່າງ, ຈາກບົດຄວາມ "ຄວາມເຂົ້າໃຈ C.S.I.», ການ​ແປ​ພາ​ສາ​ທີ່​ ພວກເຮົາຈັດພີມມາຫນຶ່ງປີກ່ອນຫນ້ານີ້.

ຂໍ້ດີຂອງການຈັດຕັ້ງປະຕິບັດດັ່ງກ່າວ

• ສໍາລັບສິ່ງພື້ນຖານເຊັ່ນການລົງທະບຽນໄດເວີສໍາລັບ node, ຜູ້ພັດທະນາ Kubernetes ໄດ້ປະຕິບັດຊຸດບັນຈຸ. ທ່ານບໍ່ຈໍາເປັນຕ້ອງສ້າງການຕອບສະຫນອງ JSON ດ້ວຍຄວາມສາມາດຂອງທ່ານເອງ, ດັ່ງທີ່ໄດ້ເຮັດສໍາລັບ plugin Flexvolume.
• ແທນທີ່ຈະ "ເລື່ອນ" ໄຟລ໌ທີ່ປະຕິບັດໄດ້ໃສ່ໂຫນດ, ຕອນນີ້ພວກເຮົາອັບໂຫລດ pods ໃສ່ກຸ່ມ. ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາຄາດຫວັງໃນເບື້ອງຕົ້ນຈາກ Kubernetes: ຂະບວນການທັງຫມົດເກີດຂື້ນພາຍໃນບັນຈຸທີ່ຖືກນໍາໃຊ້ໂດຍໃຊ້ Kubernetes primitives.
• ທ່ານບໍ່ຈໍາເປັນຕ້ອງພັດທະນາເຄື່ອງແມ່ຂ່າຍ RPC ແລະລູກຄ້າ RPC ເພື່ອປະຕິບັດໄດເວີທີ່ສັບສົນ. ລູກຄ້າໄດ້ຖືກປະຕິບັດໃຫ້ພວກເຮົາໂດຍຜູ້ພັດທະນາ Kubernetes.
• ການຖ່າຍທອດການໂຕ້ຖຽງເພື່ອເຮັດວຽກຜ່ານໂປໂຕຄອນ gRPC ແມ່ນສະດວກກວ່າ, ມີຄວາມຍືດຫຍຸ່ນແລະເຊື່ອຖືໄດ້ຫຼາຍກ່ວາການຖ່າຍທອດພວກມັນຜ່ານເສັ້ນຄໍາສັ່ງ. ເພື່ອເຂົ້າໃຈວິທີການເພີ່ມການສະຫນັບສະຫນູນສໍາລັບການວັດແທກປະລິມານການນໍາໃຊ້ກັບ CSI ໂດຍການເພີ່ມວິທີການ gRPC ມາດຕະຖານ, ທ່ານສາມາດອ່ານ: ການ​ຮ້ອງ​ຂໍ​ດຶງ​ຂອງ​ພວກ​ເຮົາ​ ສໍາລັບຄົນຂັບ vsphere-csi.
• ການສື່ສານເກີດຂຶ້ນຜ່ານຊັອກເກັດ IPC, ເພື່ອບໍ່ໃຫ້ສັບສົນວ່າ kubelet ສົ່ງຄໍາຮ້ອງຂໍໄປຫາຝັກທີ່ຖືກຕ້ອງ.

ລາຍຊື່ນີ້ເຕືອນເຈົ້າກ່ຽວກັບຫຍັງບໍ? ຂໍ້ດີຂອງ CSI ແມ່ນ ແກ້ໄຂບັນຫາດຽວກັນນັ້ນ, ເຊິ່ງບໍ່ໄດ້ຖືກພິຈາລະນາໃນເວລາທີ່ພັດທະນາ plugin Flexvolume.

ການຄົ້ນພົບ

CSI ເປັນມາດຕະຖານສໍາລັບການປະຕິບັດ plugins ແບບກໍານົດເອງສໍາລັບການພົວພັນກັບສາງຂໍ້ມູນໄດ້ຮັບການຕ້ອນຮັບຢ່າງອົບອຸ່ນຈາກຊຸມຊົນ. ຍິ່ງໄປກວ່ານັ້ນ, ເນື່ອງຈາກຂໍ້ໄດ້ປຽບແລະຄວາມຄ່ອງແຄ້ວຂອງພວກເຂົາ, ໄດເວີ CSI ໄດ້ຖືກສ້າງຂື້ນເຖິງແມ່ນວ່າສໍາລັບລະບົບການເກັບຮັກສາເຊັ່ນ Ceph ຫຼື AWS EBS, plugins ສໍາລັບການເຮັດວຽກທີ່ໄດ້ຖືກເພີ່ມເຂົ້າໃນ Kubernetes ຮຸ່ນທໍາອິດ.

ໃນຕົ້ນປີ 2019, ປລັກອິນໃນຕົ້ນໄມ້ ໄດ້ຖືກປະກາດວ່າລ້າສະໄໝແລ້ວ. ພວກເຮົາວາງແຜນທີ່ຈະສືບຕໍ່ສະຫນັບສະຫນູນ plugin Flexvolume, ແຕ່ຈະບໍ່ພັດທະນາຫນ້າທີ່ໃຫມ່ສໍາລັບມັນ.

ພວກເຮົາເອງມີປະສົບການໃຊ້ ceph-csi, vsphere-csi ແລະພ້ອມທີ່ຈະເພີ່ມເຂົ້າໃນບັນຊີລາຍຊື່ນີ້! ມາຮອດປະຈຸ, CSI ກໍາລັງຮັບມືກັບວຽກງານທີ່ຖືກມອບຫມາຍໃຫ້ມັນຢ່າງຫນັກແຫນ້ນ, ແຕ່ພວກເຮົາຈະລໍຖ້າແລະເບິ່ງ.

ຢ່າ​ລືມ​ວ່າ​ທຸກ​ສິ່ງ​ໃຫມ່​ແມ່ນ​ການ​ຄິດ​ຄືນ​ໃຫມ່​ຂອງ​ທີ່​ດີ​!

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ພວກເຮົາເຂົ້າໃຈການໂຕ້ຕອບການເກັບຮັກສາຕູ້ຄອນເທນເນີ (ໃນ Kubernetes ແລະບໍ່ພຽງແຕ່)"
• «ໄປ Rook ຫຼືບໍ່ Rook - ນັ້ນແມ່ນຄໍາຖາມ"
• «ຂໍແນະນຳເວີຊັນ alpha ຂອງການຖ່າຍຮູບລະດັບສຽງໃນ Kubernetes".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com