កម្មវិធីជំនួយកម្រិតសំឡេងសម្រាប់ការផ្ទុក Kubernetes៖ ពី Flexvolume ទៅ CSI

ត្រលប់មកវិញនៅពេលដែល Kubernetes នៅតែ v1.0.0 មានកម្មវិធីជំនួយកម្រិតសំឡេង។ ពួកគេត្រូវការដើម្បីភ្ជាប់ប្រព័ន្ធទៅ Kubernetes សម្រាប់រក្សាទុកទិន្នន័យកុងតឺន័រជាប់លាប់ (អចិន្ត្រៃយ៍)។ ចំនួនរបស់ពួកគេមានតិចតួច ហើយក្នុងចំណោមអ្នកផ្តល់សេវាផ្ទុកទិន្នន័យដំបូងគេដូចជា GCE PD, Ceph, AWS EBS និងផ្សេងទៀត។

កម្មវិធីជំនួយត្រូវបានចែកចាយជាមួយ Kubernetes ដែលនេះជាមូលហេតុដែលពួកគេទទួលបានឈ្មោះ - in-tree ។ ទោះយ៉ាងណាក៏ដោយ សម្រាប់មនុស្សជាច្រើន សំណុំកម្មវិធីជំនួយដែលមានស្រាប់បានប្រែទៅជាមិនគ្រប់គ្រាន់។ សិប្បករបានបន្ថែមកម្មវិធីជំនួយសាមញ្ញទៅស្នូល Kubernetes ដោយប្រើបំណះ បន្ទាប់ពីនោះពួកគេបានប្រមូលផ្តុំ Kubernetes ផ្ទាល់ខ្លួនរបស់ពួកគេ ហើយដំឡើងវានៅលើម៉ាស៊ីនមេរបស់ពួកគេ។ ប៉ុន្តែយូរ ៗ ទៅអ្នកអភិវឌ្ឍន៍ Kubernetes បានដឹងរឿងនោះ។ ត្រី បញ្ហាមិនអាចដោះស្រាយបានទេ។ មនុស្សត្រូវការ ដំបងនេសាទ. ហើយនៅក្នុងការចេញផ្សាយ Kubernetes v1.2.0 វាបានបង្ហាញខ្លួន ...

កម្មវិធីជំនួយ Flexvolume៖ ដំបងនេសាទតិចតួចបំផុត។

អ្នកអភិវឌ្ឍន៍ Kubernetes បានបង្កើតកម្មវិធីជំនួយ FlexVolume ដែលជាក្របខ័ណ្ឌឡូជីខលនៃអថេរ និងវិធីសាស្រ្តសម្រាប់ធ្វើការជាមួយកម្មវិធីបញ្ជា Flexvolume ដែលអនុវត្តដោយអ្នកអភិវឌ្ឍន៍ភាគីទីបី។

តោះឈប់ ហើយពិនិត្យមើលឲ្យកាន់តែច្បាស់ថា តើកម្មវិធីបញ្ជា FlexVolume ជាអ្វី។ នេះគឺជាក់លាក់មួយ។ ឯកសារដែលអាចប្រតិបត្តិបាន។ (ឯកសារគោលពីរ, ស្គ្រីប Python, ស្គ្រីប Bash ។ តាមអនុសញ្ញា អាគុយម៉ង់បន្ទាត់ពាក្យបញ្ជាទីមួយតែងតែជាវិធីសាស្ត្រ ហើយអាគុយម៉ង់ដែលនៅសល់គឺជាប៉ារ៉ាម៉ែត្ររបស់វា។

ដ្យាក្រាមតភ្ជាប់សម្រាប់ការចែករំលែក CIFS នៅក្នុង OpenShift ។ កម្មវិធីបញ្ជា 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 នឹងកំណត់សេណារីយ៉ូដែល 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. កម្មវិធីបញ្ជាត្រូវតែមានទីតាំងនៅលើថ្នាំងចង្កោមនីមួយៗ យោងទៅតាមផ្លូវដែលបានកំណត់ទុកជាមុន។ តាមលំនាំដើមវាត្រូវបានជ្រើសរើស៖

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

... ប៉ុន្តែនៅពេលប្រើការចែកចាយ Kubernetes ផ្សេងគ្នា (OpenShift, Rancher...) ផ្លូវអាចខុសគ្នា។

បញ្ហា Flexvolume: របៀបបោះដំបងនេសាទឱ្យបានត្រឹមត្រូវ?

ការអាប់ឡូតកម្មវិធីបញ្ជា Flexvolume ទៅកាន់ថ្នាំងចង្កោមបានប្រែទៅជាកិច្ចការដែលមិនសំខាន់។ ដោយបានធ្វើប្រតិបត្តិការដោយដៃម្តង វាងាយស្រួលក្នុងការជួបប្រទះនូវស្ថានភាពដែលថ្នាំងថ្មីលេចឡើងក្នុងចង្កោម៖ ដោយសារតែការបន្ថែមថ្នាំងថ្មី ការធ្វើមាត្រដ្ឋានផ្ដេកដោយស្វ័យប្រវត្តិ ឬ - អ្វីដែលកាន់តែអាក្រក់ - ការជំនួសថ្នាំងដោយសារតែដំណើរការខុសប្រក្រតី។ ក្នុងករណីនេះ ធ្វើការជាមួយការផ្ទុកនៅលើថ្នាំងទាំងនេះគួរតែត្រូវបានធ្វើ គឺមិនអាចទៅរួចទេរហូតដល់អ្នកនៅតែបន្ថែមកម្មវិធីបញ្ជា Flexvolume ដោយដៃទៅពួកគេ។

ដំណោះស្រាយចំពោះបញ្ហានេះគឺមួយនៃ Kubernetes primitives - DaemonSet. នៅពេលដែលថ្នាំងថ្មីលេចឡើងក្នុងចង្កោម វាមានផតដោយស្វ័យប្រវត្តិពី DaemonSet របស់យើង ដែលបរិមាណក្នុងតំបន់ត្រូវបានភ្ជាប់តាមផ្លូវដើម្បីស្វែងរកកម្មវិធីបញ្ជា Flexvolume ។ នៅពេលបង្កើតដោយជោគជ័យ ផតចម្លងឯកសារចាំបាច់សម្រាប់កម្មវិធីបញ្ជាដើម្បីដំណើរការទៅថាស។

នេះគឺជាឧទាហរណ៍នៃ DaemonSet សម្រាប់ដាក់ចេញកម្មវិធីជំនួយ 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 សម្រាប់ដាក់ចេញកម្មវិធីបញ្ជា 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: កម្មវិធីបញ្ជា Flexvolume នៅក្នុងដ្យាក្រាមមានទីតាំងនៅខាងក្នុងភ្នាក់ងារ Rook

បញ្ហាបន្ទាប់នៅពេលប្រើកម្មវិធីបញ្ជា Flexvolume គឺថាសម្រាប់ការផ្ទុកភាគច្រើននៅលើថ្នាំងចង្កោម កម្មវិធីចាំបាច់សម្រាប់ការនេះត្រូវតែត្រូវបានដំឡើង (ឧទាហរណ៍ កញ្ចប់ ceph-ទូទៅសម្រាប់ Ceph) ។ ដំបូង កម្មវិធីជំនួយ Flexvolume មិនត្រូវបានរចនាឡើងដើម្បីអនុវត្តប្រព័ន្ធស្មុគស្មាញបែបនេះទេ។

ដំណោះស្រាយដើមចំពោះបញ្ហានេះអាចមើលឃើញនៅក្នុងការអនុវត្តកម្មវិធីបញ្ជា Flexvolume របស់ប្រតិបត្តិករ Rook៖

កម្មវិធីបញ្ជាខ្លួនវាត្រូវបានរចនាឡើងជាម៉ាស៊ីនភ្ញៀវ RPC ។ រន្ធ IPC សម្រាប់ទំនាក់ទំនងមានទីតាំងនៅក្នុងថតដូចគ្នានឹងកម្មវិធីបញ្ជាផ្ទាល់។ យើងចងចាំថា ដើម្បីចម្លងឯកសារកម្មវិធីបញ្ជា វាជាការល្អក្នុងការប្រើ DaemonSet ដែលភ្ជាប់ថតឯកសារជាមួយកម្មវិធីបញ្ជាជាកម្រិតសំឡេង។ បន្ទាប់ពីចម្លងឯកសារកម្មវិធីបញ្ជា rook ចាំបាច់ ផតនេះមិនស្លាប់ទេ ប៉ុន្តែភ្ជាប់ទៅរន្ធ IPC តាមរយៈភាគដែលបានភ្ជាប់ជាម៉ាស៊ីនមេ RPC ពេញលេញ។ កញ្ចប់ ceph-common ត្រូវបានដំឡើងរួចហើយនៅក្នុងធុង pod ។ រន្ធ IPC ធានាថា kubelet នឹងទាក់ទងជាមួយ pod ដែលមានទីតាំងនៅលើថ្នាំងដូចគ្នា។ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញ!..

លាហើយ អ្នកជាទីស្រឡាញ់របស់យើង... កម្មវិធីជំនួយក្នុងដើមឈើ!

អ្នកអភិវឌ្ឍន៍ Kubernetes បានរកឃើញថាចំនួនកម្មវិធីជំនួយសម្រាប់ផ្ទុកនៅក្នុងស្នូលគឺម្ភៃ។ ហើយការផ្លាស់ប្តូរនៅក្នុងពួកវានីមួយៗ តាមមធ្យោបាយមួយ ឬមធ្យោបាយផ្សេងទៀត ឆ្លងកាត់វដ្តនៃការចេញផ្សាយ Kubernetes ពេញលេញ។

វាប្រែថាដើម្បីប្រើកំណែថ្មីនៃកម្មវិធីជំនួយការផ្ទុក, អ្នកត្រូវធ្វើបច្ចុប្បន្នភាពក្រុមទាំងមូល. បន្ថែមពីលើនេះ អ្នកប្រហែលជាភ្ញាក់ផ្អើលដែលកំណែថ្មីរបស់ Kubernetes នឹងក្លាយទៅជាមិនឆបគ្នាជាមួយខឺណែលលីនុចដែលអ្នកកំពុងប្រើ... ដូច្នេះអ្នកជូតទឹកភ្នែករបស់អ្នក ហើយគ្រវីធ្មេញរបស់អ្នក សម្របសម្រួលជាមួយអ្នកគ្រប់គ្រង និងអ្នកប្រើប្រាស់របស់អ្នក ដល់ពេលដែលត្រូវ ធ្វើបច្ចុប្បន្នភាពខឺណែលលីនុច និងចង្កោម Kubernetes ។ ជាមួយនឹងពេលវេលារងចាំដែលអាចកើតមានក្នុងការផ្តល់សេវាកម្ម។

ស្ថានការណ៍​គឺ​ហួស​ពី​រឿង​កំប្លែង​ទៅ​ទៀត​តើ​អ្នក​គិត​ទេ​? វាច្បាស់ណាស់ចំពោះសហគមន៍ទាំងមូលថាវិធីសាស្រ្តនេះមិនដំណើរការទេ។ តាមរយៈការសម្រេចចិត្តដោយចេតនា អ្នកអភិវឌ្ឍន៍ Kubernetes ប្រកាសថាកម្មវិធីជំនួយថ្មីសម្រាប់ធ្វើការជាមួយការផ្ទុកនឹងមិនត្រូវបានទទួលយកទៅក្នុងខឺណែលទៀតទេ។ លើសពីនេះ ដូចដែលយើងបានដឹងរួចមកហើយ ចំណុចខ្វះខាតមួយចំនួនត្រូវបានគេរកឃើញនៅក្នុងការអនុវត្តកម្មវិធីជំនួយ Flexvolume...

កម្មវិធីជំនួយដែលបានបន្ថែមចុងក្រោយបំផុតសម្រាប់បរិមាណនៅក្នុង Kubernetes, CSI, ត្រូវបានអំពាវនាវឱ្យបិទបញ្ហានេះជាមួយនឹងការផ្ទុកទិន្នន័យជាប់លាប់ម្តង និងសម្រាប់ទាំងអស់។ កំណែអាល់ហ្វារបស់វា ដែលសំដៅយ៉ាងពេញលេញថាជាកម្មវិធីជំនួយកម្រិតសំឡេង CSI ក្រៅដើមឈើ ត្រូវបានប្រកាសនៅក្នុងការចេញផ្សាយ Kubernetes ១.១៤.

Container Storage Interface ឬ CSI 3000 spinning rod!

ជាដំបូងខ្ញុំចង់កត់សម្គាល់ថា CSI មិនមែនគ្រាន់តែជាកម្មវិធីជំនួយកម្រិតសំឡេងប៉ុណ្ណោះទេ ប៉ុន្តែជាការពិត ស្តង់ដារ។ លើការបង្កើតសមាសធាតុផ្ទាល់ខ្លួនសម្រាប់ធ្វើការជាមួយឃ្លាំងទិន្នន័យ. ប្រព័ន្ធវង់ភ្លេងកុងតឺន័រដូចជា Kubernetes និង Mesos ត្រូវបានគេសន្មត់ថា "រៀន" របៀបធ្វើការជាមួយសមាសធាតុដែលបានអនុវត្តស្របតាមស្តង់ដារនេះ។ ហើយឥឡូវនេះខ្ញុំបានរៀន Kubernetes រួចហើយ។

តើអ្វីជារចនាសម្ព័ន្ធនៃកម្មវិធីជំនួយ CSI នៅក្នុង Kubernetes? កម្មវិធីជំនួយ CSI ដំណើរការជាមួយកម្មវិធីបញ្ជាពិសេស (អ្នកបើកបរ CSI) សរសេរដោយអ្នកអភិវឌ្ឍន៍ភាគីទីបី។ កម្មវិធីបញ្ជា CSI នៅក្នុង Kubernetes គួរតែមានយ៉ាងហោចណាស់សមាសភាគពីរ (pods)៖

• ឧបករណ៍បញ្ជា - គ្រប់គ្រងការផ្ទុកជាប់លាប់ខាងក្រៅ។ វាត្រូវបានអនុវត្តជាម៉ាស៊ីនមេ gRPC ដែលបុព្វបទត្រូវបានប្រើ StatefulSet.
• ថ្នាំង — ទទួលខុសត្រូវចំពោះការម៉ោនការផ្ទុកជាប់លាប់ទៅកាន់ថ្នាំងចង្កោម។ វាក៏ត្រូវបានអនុវត្តជាម៉ាស៊ីនមេ gRPC ប៉ុន្តែវាប្រើបុព្វកាល DaemonSet.

របៀបដែលកម្មវិធីជំនួយ CSI ដំណើរការនៅក្នុង Kubernetes

អ្នកអាចស្វែងយល់អំពីព័ត៌មានលម្អិតផ្សេងទៀតនៃការងាររបស់ CSI ជាឧទាហរណ៍ ពីអត្ថបទ “ការយល់ដឹងអំពី C.S.I.» ការបកប្រែដែល យើងបានបោះពុម្ពកាលពីមួយឆ្នាំមុន។

គុណសម្បត្តិនៃការអនុវត្តបែបនេះ

• សម្រាប់រឿងជាមូលដ្ឋានដូចជាការចុះឈ្មោះកម្មវិធីបញ្ជាសម្រាប់ថ្នាំង អ្នកអភិវឌ្ឍន៍ Kubernetes បានអនុវត្តសំណុំនៃកុងតឺន័រ។ អ្នកលែងត្រូវការបង្កើតការឆ្លើយតប JSON ជាមួយនឹងសមត្ថភាពដោយខ្លួនឯង ដូចដែលបានធ្វើរួចសម្រាប់កម្មវិធីជំនួយ Flexvolume ។
• ជំនួសឱ្យ "ការរអិល" ឯកសារដែលអាចប្រតិបត្តិបាននៅលើថ្នាំង ឥឡូវនេះយើងបង្ហោះ pods ទៅកាន់ cluster ។ នេះជាអ្វីដែលយើងរំពឹងទុកដំបូងពី Kubernetes៖ ដំណើរការទាំងអស់កើតឡើងនៅក្នុងកុងតឺន័រដែលដាក់ពង្រាយដោយប្រើ Kubernetes primitives។
• អ្នកមិនចាំបាច់បង្កើតម៉ាស៊ីនមេ RPC និងម៉ាស៊ីនភ្ញៀវ RPC ដើម្បីអនុវត្តកម្មវិធីបញ្ជាស្មុគស្មាញទៀតទេ។ ម៉ាស៊ីនភ្ញៀវត្រូវបានអនុវត្តសម្រាប់យើងដោយអ្នកអភិវឌ្ឍន៍ Kubernetes ។
• ការឆ្លងកាត់អាគុយម៉ង់ដើម្បីធ្វើការលើពិធីការ gRPC គឺកាន់តែងាយស្រួល បត់បែន និងអាចទុកចិត្តបានជាងការឆ្លងកាត់វាតាមរយៈអាគុយម៉ង់បន្ទាត់ពាក្យបញ្ជា។ ដើម្បីយល់ពីរបៀបបន្ថែមការគាំទ្រសម្រាប់រង្វាស់នៃការប្រើប្រាស់បរិមាណទៅ CSI ដោយបន្ថែមវិធីសាស្ត្រ gRPC ស្តង់ដារ អ្នកអាចអាន៖ សំណើទាញរបស់យើង។ សម្រាប់កម្មវិធីបញ្ជា vsphere-csi ។
• ការប្រាស្រ័យទាក់ទងគ្នាកើតឡើងតាមរយៈរន្ធ IPC ដើម្បីកុំឱ្យមានការភាន់ច្រឡំថាតើ kubelet បានផ្ញើសំណើទៅកាន់ pod ត្រឹមត្រូវ។

តើបញ្ជីនេះរំលឹកអ្នកអំពីអ្វីទេ? អត្ថប្រយោជន៍របស់ CSI គឺ ដោះស្រាយបញ្ហាដូចគ្នា។ដែលមិនត្រូវបានយកមកពិចារណានៅពេលបង្កើតកម្មវិធីជំនួយ Flexvolume ។

ការរកឃើញ

CSI ជាស្តង់ដារសម្រាប់អនុវត្តកម្មវិធីជំនួយផ្ទាល់ខ្លួនសម្រាប់អន្តរកម្មជាមួយឃ្លាំងទិន្នន័យត្រូវបានទទួលយ៉ាងកក់ក្តៅពីសហគមន៍។ លើសពីនេះទៅទៀត ដោយសារតែគុណសម្បត្តិ និងសមត្ថភាពរបស់វា កម្មវិធីបញ្ជា CSI ត្រូវបានបង្កើតឡើងសូម្បីតែសម្រាប់ប្រព័ន្ធផ្ទុកទិន្នន័យដូចជា Ceph ឬ AWS EBS កម្មវិធីជំនួយសម្រាប់ធ្វើការជាមួយដែលត្រូវបានបន្ថែមនៅក្នុងកំណែដំបូងនៃ Kubernetes ។

នៅដើមឆ្នាំ 2019 កម្មវិធីជំនួយក្នុងមែកធាង ត្រូវបានប្រកាសថាលែងប្រើហើយ។. យើងគ្រោងនឹងបន្តគាំទ្រកម្មវិធីជំនួយ Flexvolume ប៉ុន្តែនឹងមិនបង្កើតមុខងារថ្មីសម្រាប់វាទេ។

ខ្លួនយើងផ្ទាល់មានបទពិសោធន៍ប្រើប្រាស់ ceph-csi, vsphere-csi ហើយត្រៀមខ្លួនរួចជាស្រេចក្នុងការបន្ថែមទៅក្នុងបញ្ជីនេះ! រហូតមកដល់ពេលនេះ CSI កំពុងប្រឈមមុខនឹងភារកិច្ចដែលបានប្រគល់ឱ្យវាដោយសំឡេងខ្លាំង ប៉ុន្តែយើងនឹងរង់ចាំមើល។

កុំ​ភ្លេច​ថា​អ្វី​ដែល​ថ្មី​គឺ​ជា​ការ​គិត​ឡើង​វិញ​របស់​ចាស់!

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «យើងយល់ពីចំណុចប្រទាក់ផ្ទុកកុងតឺន័រ (នៅក្នុង Kubernetes និងមិនត្រឹមតែប៉ុណ្ណោះ)»
• «ទៅ Rook ឬមិន Rook - នោះជាសំណួរ»
• «ការណែនាំអំពីកំណែអាល់ហ្វានៃរូបថតកម្រិតសំឡេងនៅក្នុង Kubernetes"។

ប្រភព: www.habr.com