🥇Plugin volume kanggo panyimpenan ing Kubernetes: saka Flexvolume menyang CSI

Mbalik nalika Kubernetes isih v1.0.0, ana plugin volume. Padha dibutuhake kanggo nyambungake sistem menyang Kubernetes kanggo nyimpen data wadhah sing terus-terusan (permanen). Jumlahe cilik, lan ing antarane sing pertama yaiku panyedhiya panyimpenan kayata GCE PD, Ceph, AWS EBS lan liya-liyane.

Plugin kasebut dikirim bebarengan karo Kubernetes, mula dheweke entuk jenenge - in-tree. Nanging, kanggo akeh, set plugin kasebut ora cukup. Pengrajin nambahake plugin prasaja menyang inti Kubernetes kanthi nggunakake tembelan, banjur ngrakit Kubernetes dhewe lan nginstal ing server. Nanging liwat wektu, pangembang Kubernetes nyadari iwak masalah ora bisa ditanggulangi. Wong butuh pancing. Lan ing release saka Kubernetes v1.2.0 katon ...

Flexvolume plugin: pancing minimal

Pangembang Kubernetes nggawe plugin FlexVolume, sing minangka kerangka logis saka variabel lan metode kanggo nggarap driver Flexvolume sing ditindakake dening pangembang pihak katelu.

Ayo mandheg lan deleng kanthi luwih rinci babagan driver FlexVolume. Iki tartamtu file eksekusi (file binar, skrip Python, skrip Bash, lsp), sing, nalika dieksekusi, njupuk argumen baris perintah minangka input lan ngasilake pesen kanthi kolom sing wis dikenal ing format JSON. Miturut konvensi, argumen baris perintah pisanan tansah dadi metode, lan argumen sing isih ana yaiku paramèter.

Diagram sambungan kanggo Saham CIFS ing OpenShift. Flexvolume Driver - Tengen ing tengah

Set metode minimal katon kaya iki:

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}
}

Nggunakake Metode attach и detach bakal nemtokake skenario kang kubelet bakal tumindak ing mangsa nalika nelpon driver. Ana uga cara khusus expandvolume и expandfs, sing tanggung jawab kanggo ngowahi ukuran volume kanthi dinamis.

Minangka conto owah-owahan sing cara nambah expandvolume, lan karo kemampuan kanggo ngowahi ukuran volume ing wektu nyata, sampeyan bisa familiarize dhewe karo panyuwunan tarik kita ing Rook Ceph Operator.

Lan ing ngisor iki minangka conto implementasi driver Flexvolume kanggo nggarap 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

Dadi, sawise nyiapake file eksekusi sing nyata, sampeyan kudu upload driver menyang kluster Kubernetes. Driver kudu dumunung ing saben simpul kluster miturut path sing wis ditemtokake. Secara default dipilih:

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

... nanging nalika nggunakake distribusi Kubernetes beda (OpenShift, Rancher ...) path bisa uga beda.

Masalah Flexvolume: carane matak rod fishing bener?

Ngunggah driver Flexvolume menyang simpul kluster dadi tugas sing ora pati penting. Sawise nindakake operasi kanthi manual sapisan, gampang nemoni kahanan ing ngendi simpul anyar katon ing kluster: amarga tambahan simpul anyar, skala horisontal otomatis, utawa - sing luwih elek - panggantos simpul amarga malfunction. Ing kasus iki, karya karo panyimpenan ing kelenjar iki kudu rampung punika mokal, nganti sampeyan isih nambahake driver Flexvolume kanthi manual.

Solusi kanggo masalah iki yaiku salah sawijining primitif Kubernetes - DaemonSet. Nalika simpul anyar katon ing kluster, kanthi otomatis ngemot pod saka DaemonSet kita, sing volume lokal ditempelake ing dalan kanggo nemokake driver Flexvolume. Sawise nggawe sukses, pod nyalin file sing dibutuhake supaya driver bisa digunakake menyang disk.

Iki minangka conto DaemonSet kanggo nggawe 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>

... lan conto skrip Bash kanggo nyetel driver 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

Penting ora lali yen operasi salinan ora atom. Ana kemungkinan gedhe yen kubelet bakal miwiti nggunakake driver sadurunge proses provisioning rampung, nyebabake sistem kacilakan. Pendekatan sing bener yaiku nyalin file driver kanthi jeneng sing beda, banjur gunakake operasi ganti jeneng atom.

Diagram nggarap Ceph ing operator Rook: driver Flexvolume ing diagram kasebut ana ing njero agen Rook

Masalah sabanjure nalika nggunakake driver Flexvolume yaiku kanggo panyimpenan paling akeh ing simpul kluster piranti lunak sing dibutuhake kanggo iki kudu diinstal (contone, paket ceph-umum kanggo Ceph). Kaping pisanan, plugin Flexvolume ora dirancang kanggo ngetrapake sistem rumit kasebut.

Solusi asli kanggo masalah iki bisa dideleng ing implementasi driver Flexvolume operator Rook:

Driver kasebut dhewe dirancang minangka klien RPC. Soket IPC kanggo komunikasi dumunung ing direktori sing padha karo driver kasebut. Kita elinga yen kanggo nyalin file driver luwih becik nggunakake DaemonSet, sing nyambungake direktori karo driver minangka volume. Sawise nyalin file driver rook perlu, pod iki ora mati, nanging nyambung menyang soket IPC liwat volume ditempelake minangka server RPC lengkap. Paket ceph-common wis dipasang ing wadhah pod. Soket IPC mesthekake yen kubelet bakal komunikasi karo persis polong sing dumunung ing simpul sing padha. Kabeh pinter iku prasaja! ..

Sugeng ndalu, plugins in-tree!

Pangembang Kubernetes nemokake manawa jumlah plugin kanggo panyimpenan ing inti yaiku rong puluh. Lan owah-owahan ing saben wong, siji cara utawa liyane, liwat siklus release Kubernetes lengkap.

Pranyata yen nggunakake versi anyar saka plugin panyimpenan, sampeyan kudu nganyari kabeh kluster. Saliyane iki, sampeyan bisa uga kaget yen versi anyar Kubernetes bakal tiba-tiba dadi ora kompatibel karo kernel Linux sing sampeyan gunakake ... Dadi sampeyan ngusapake luh lan, gritting untu, koordinasi karo manajemen lan pangguna wektu kanggo nganyari kernel Linux lan kluster Kubernetes. Kanthi downtime bisa ing panyedhiya layanan.

Kahanan luwih saka lucu, apa sampeyan mikir? Dadi jelas kanggo kabeh komunitas manawa pendekatan kasebut ora bisa digunakake. Kanthi keputusan sing disengaja, pangembang Kubernetes ngumumake manawa plugin anyar kanggo nggarap panyimpenan ora bakal ditampa maneh ing kernel. Kajaba iku, kaya sing wis dingerteni, sawetara kekurangan diidentifikasi ing implementasine plugin Flexvolume ...

Plugin sing ditambahake paling anyar kanggo volume ing Kubernetes, CSI, dijaluk kanggo nutup masalah kasebut kanthi panyimpenan data sing terus-terusan. Versi alfa, luwih lengkap diarani Out-of-Tree CSI Volume Plugins, diumumake ing release Kubernetes 1.9.

Interface Storage Container, utawa CSI 3000 rod spinning!

Kaping pisanan, aku pengin nyathet yen CSI ora mung plugin volume, nanging nyata standar babagan nggawe komponen khusus kanggo nggarap gudang data. Sistem orkestrasi kontainer kayata Kubernetes lan Mesos mesthine "sinau" cara nggarap komponen sing ditindakake miturut standar iki. Lan saiki aku wis sinau Kubernetes.

Apa struktur plugin CSI ing Kubernetes? Plugin CSI bisa digunakake karo driver khusus (driver CSI) ditulis dening pangembang pihak katelu. Pembalap CSI ing Kubernetes kudu minimal kalebu rong komponen (pod):

controller - ngatur panyimpenan ngengkel external. Iki dileksanakake minangka server gRPC, sing digunakake primitif StatefulSet.
Node - tanggung jawab kanggo nyimpen panyimpenan terus-terusan menyang kelenjar kluster. Iki uga dileksanakake minangka server gRPC, nanging nggunakake primitif DaemonSet.

Carane plugin CSI bisa digunakake ing Kubernetes

Sampeyan bisa sinau babagan sawetara rincian liyane babagan karya CSI, contone, saka artikel "Pangertosan C.S.I." terjemahan kang kita diterbitake setahun kepungkur.

Kaluwihan saka implementasine kuwi

Kanggo perkara dhasar kaya ndhaptar driver kanggo simpul, pangembang Kubernetes ngetrapake sakumpulan wadhah. Sampeyan ora perlu maneh nggawe respon JSON kanthi kemampuan dhewe, kaya sing ditindakake kanggo plugin Flexvolume.
Tinimbang "slipping" file eksekusi menyang simpul, saiki kita ngunggah pod menyang kluster. Iki sing wiwitane kita ngarepake saka Kubernetes: kabeh proses kedadeyan ing njero wadah sing digunakake nggunakake primitif Kubernetes.
Sampeyan ora perlu maneh ngembangake server RPC lan klien RPC kanggo ngetrapake driver sing kompleks. Klien dileksanakake kanggo kita dening pangembang Kubernetes.
Maringake argumen kanggo nggarap protokol gRPC luwih trep, fleksibel lan dipercaya tinimbang ngliwati argumen baris perintah. Kanggo mangerteni carane nambah dhukungan kanggo metrik panggunaan volume menyang CSI kanthi nambahake metode gRPC standar, sampeyan bisa maca: panyuwunan tarik kita kanggo driver vsphere-csi.
Komunikasi dumadi liwat soket IPC, supaya ora dadi bingung apa kubelet dikirim panjalukan kanggo polong bener.

Apa dhaptar iki ngelingake sampeyan babagan apa wae? Keuntungan saka CSI yaiku ngrampungake masalah sing padha, sing ora dianggep nalika ngembangake plugin Flexvolume.

temonan

CSI minangka standar kanggo ngetrapake plugin khusus kanggo sesambungan karo gudang data ditampa kanthi apik dening masyarakat. Kajaba iku, amarga kaluwihan lan fleksibilitas, pembalap CSI digawe sanajan kanggo sistem panyimpenan kayata Ceph utawa AWS EBS, plugin kanggo nggarap sing ditambahake ing versi pisanan Kubernetes.

Ing wiwitan taun 2019, plugin in-tree wis diumumake lungse. Kita rencana bakal terus ndhukung plugin Flexvolume, nanging ora bakal ngembangake fungsi anyar.

Awake dhewe wis duwe pengalaman nggunakake ceph-csi, vsphere-csi lan siap ditambahake ing dhaptar iki! Nganti saiki, CSI ngrampungake tugas sing ditugasake kanthi cepet, nanging kita bakal ngenteni lan ndeleng.

Aja lali yen kabeh sing anyar yaiku mikir maneh sing lawas!

PS

Waca uga ing blog kita:

Source: www.habr.com

Plugin volume kanggo panyimpenan Kubernetes: saka Flexvolume nganti CSI