Mga plugin ng volume para sa storage ng Kubernetes: mula Flexvolume hanggang CSI

Noong v1.0.0 pa ang Kubernetes, may mga volume plugin. Kinailangan ang mga ito upang ikonekta ang mga system sa Kubernetes para sa pag-iimbak ng patuloy na (permanenteng) data ng container. Ang kanilang bilang ay maliit, at kabilang sa mga una ay ang mga naturang storage provider gaya ng GCE PD, Ceph, AWS EBS at iba pa.

Ang mga plugin ay naihatid kasama ng Kubernetes, kaya naman nakuha nila ang kanilang pangalan - in-tree. Gayunpaman, para sa marami, ang umiiral na hanay ng mga naturang plugin ay naging hindi sapat. Nagdagdag ang mga craftsmen ng mga simpleng plugin sa core ng Kubernetes gamit ang mga patch, pagkatapos ay binuo nila ang sarili nilang mga Kubernetes at na-install ito sa kanilang mga server. Ngunit sa paglipas ng panahon, napagtanto iyon ng mga developer ng Kubernetes isda hindi malulutas ang problema. Kailangan ng mga tao pangingisda. At sa paglabas ng Kubernetes v1.2.0 ay lumitaw...

Flexvolume plugin: minimal na fishing rod

Ginawa ng mga developer ng Kubernetes ang FlexVolume plugin, na isang lohikal na balangkas ng mga variable at pamamaraan para sa pagtatrabaho sa mga driver ng Flexvolume na ipinatupad ng mga third-party na developer.

Huminto tayo at tingnang mabuti kung ano ang driver ng FlexVolume. Ito ay tiyak maipapatupad na file (binary file, Python script, Bash script, atbp.), na, kapag naisakatuparan, ay kumukuha ng mga argumento ng command line bilang input at nagbabalik ng mensahe na may mga pre-known field sa JSON na format. Sa pamamagitan ng convention, ang unang command line argument ay palaging isang paraan, at ang natitirang argumento ay ang mga parameter nito.

Diagram ng koneksyon para sa Mga Pagbabahagi ng CIFS sa OpenShift. Flexvolume Driver - Sa mismong Gitna

Minimum na hanay ng mga pamamaraan ganito ang hitsura nito:

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

Paggamit ng mga Paraan attach и detach ay tutukuyin ang senaryo kung saan kikilos ang kubelet sa hinaharap kapag tumatawag sa driver. Mayroon ding mga espesyal na pamamaraan expandvolume и expandfs, na responsable para sa dynamic na pagbabago ng laki ng volume.

Bilang isang halimbawa ng mga pagbabago na idinagdag ng pamamaraan expandvolume, at kasama nito ang kakayahang baguhin ang laki ng mga volume sa real time, maaari mong gawing pamilyar ang iyong sarili ang aming kahilingan sa paghila sa Rook Ceph Operator.

At narito ang isang halimbawa ng pagpapatupad ng driver ng Flexvolume para sa pagtatrabaho sa 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

Kaya, pagkatapos ihanda ang aktwal na maipapatupad na file, kailangan mong i-upload ang driver sa Kubernetes cluster. Ang driver ay dapat na matatagpuan sa bawat cluster node ayon sa isang paunang natukoy na landas. Bilang default, napili ito:

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

... ngunit kapag gumagamit ng iba't ibang mga distribusyon ng Kubernetes (OpenShift, Rancher...) maaaring iba ang landas.

Mga problema sa Flexvolume: kung paano mag-cast ng isang pamingwit nang tama?

Ang pag-upload ng Flexvolume driver sa mga cluster node ay naging isang hindi maliit na gawain. Ang pagkakaroon ng manu-manong operasyon nang isang beses, madaling makatagpo ng isang sitwasyon kung saan lumilitaw ang mga bagong node sa cluster: dahil sa pagdaragdag ng isang bagong node, awtomatikong horizontal scaling, o - kung ano ang mas masahol pa - pagpapalit ng isang node dahil sa isang malfunction. Sa kasong ito, dapat gawin ang pag-iimbak sa mga node na ito ay imposible, hanggang sa manu-mano mo pa ring idagdag ang Flexvolume driver sa kanila.

Ang solusyon sa problemang ito ay isa sa mga primitibo ng Kubernetes - DaemonSet. Kapag lumitaw ang isang bagong node sa cluster, awtomatiko itong naglalaman ng isang pod mula sa aming DaemonSet, kung saan ang isang lokal na volume ay nakakabit sa landas upang mahanap ang mga driver ng Flexvolume. Sa matagumpay na paggawa, kinokopya ng pod ang mga kinakailangang file para gumana ang driver sa disk.

Narito ang isang halimbawa ng naturang DaemonSet para sa paglalagay ng isang Flexvolume plugin:

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>

... at isang halimbawa ng isang Bash script para sa paglalagay ng Flexvolume driver:

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

Mahalagang huwag kalimutan na ang operasyon ng kopya ay hindi atomic. Malaki ang posibilidad na ang kubelet ay magsisimulang gamitin ang driver bago makumpleto ang proseso ng pagbibigay nito, na nagiging sanhi ng pag-crash ng system. Ang tamang diskarte ay ang unang kopyahin ang mga file ng driver sa ilalim ng ibang pangalan, at pagkatapos ay gumamit ng atomic rename operation.

Diagram ng pakikipagtulungan kay Ceph sa Rook operator: ang Flexvolume driver sa diagram ay matatagpuan sa loob ng Rook agent

Ang susunod na problema kapag gumagamit ng mga driver ng Flexvolume ay para sa karamihan ng imbakan sa isang cluster node dapat na mai-install ang kinakailangang software para dito (halimbawa, ang ceph-common package para kay Ceph). Sa una, ang Flexvolume plugin ay hindi idinisenyo upang ipatupad ang mga kumplikadong sistema.

Ang isang orihinal na solusyon sa problemang ito ay makikita sa pagpapatupad ng driver ng Flexvolume ng Rook operator:

Ang driver mismo ay idinisenyo bilang isang RPC client. Ang IPC socket para sa komunikasyon ay matatagpuan sa parehong direktoryo ng driver mismo. Naaalala namin na upang kopyahin ang mga file ng driver, makabubuting gumamit ng DaemonSet, na nag-uugnay sa direktoryo sa driver bilang isang volume. Matapos kopyahin ang mga kinakailangang rook driver file, ang pod na ito ay hindi namamatay, ngunit kumokonekta sa IPC socket sa pamamagitan ng nakalakip na volume bilang isang ganap na RPC server. Ang ceph-common package ay naka-install na sa loob ng pod container. Tinitiyak ng IPC socket na ang kubelet ay makikipag-ugnayan sa eksaktong pod na matatagpuan sa parehong node. Lahat ng mapanlikha ay simple!..

Paalam, ang aming mapagmahal... in-tree na mga plugin!

Natuklasan ng mga developer ng Kubernetes na ang bilang ng mga plugin para sa imbakan sa loob ng core ay dalawampu. At ang pagbabago sa bawat isa sa kanila, sa isang paraan o iba pa, ay dumadaan sa buong ikot ng paglabas ng Kubernetes.

Lumalabas na para magamit ang bagong bersyon ng storage plugin, kailangan mong i-update ang buong cluster. Bilang karagdagan dito, maaari kang mabigla na ang bagong bersyon ng Kubernetes ay biglang magiging hindi tugma sa Linux kernel na iyong ginagamit... Kaya't pinupunasan mo ang iyong mga luha at, nagngangalit ang iyong mga ngipin, makipag-ugnayan sa iyong pamamahala at mga gumagamit ng oras upang i-update ang Linux kernel at Kubernetes cluster. Sa posibleng downtime sa pagkakaloob ng mga serbisyo.

Ang sitwasyon ay higit pa sa nakakatawa, sa palagay mo ba? Naging malinaw sa buong komunidad na hindi gumagana ang diskarte. Sa pamamagitan ng kusang desisyon, inanunsyo ng mga developer ng Kubernetes na ang mga bagong plugin para sa pagtatrabaho sa storage ay hindi na tatanggapin sa kernel. Bilang karagdagan, tulad ng alam na natin, ang isang bilang ng mga pagkukulang ay natukoy sa pagpapatupad ng Flexvolume plugin...

Ang pinakabagong idinagdag na plugin para sa mga volume sa Kubernetes, CSI, ay tinawag na isara ang isyu sa patuloy na pag-iimbak ng data nang minsan at para sa lahat. Ang alpha na bersyon nito, na mas ganap na tinutukoy bilang Out-of-Tree CSI Volume Plugin, ay inihayag sa release Kubernetes 1.9.

Container Storage Interface, o CSI 3000 spinning rod!

Una sa lahat, nais kong tandaan na ang CSI ay hindi lamang isang volume plugin, ngunit isang tunay pamantayan sa paglikha ng mga custom na bahagi para sa pagtatrabaho sa mga warehouse ng data. Ang mga sistema ng orkestrasyon ng container gaya ng Kubernetes at Mesos ay dapat na "matuto" kung paano gumana sa mga bahaging ipinatupad ayon sa pamantayang ito. At ngayon natutunan ko na ang Kubernetes.

Ano ang istraktura ng CSI plugin sa Kubernetes? Gumagana ang plugin ng CSI sa mga espesyal na driver (Mga driver ng CSI) na isinulat ng mga third party na developer. Ang isang driver ng CSI sa Kubernetes ay dapat na minimal na binubuo ng dalawang bahagi (mga pod):

• Magsusupil — namamahala sa mga panlabas na patuloy na imbakan. Ito ay ipinatupad bilang isang gRPC server, kung saan ginagamit ang primitive StatefulSet.
• Node — ay responsable para sa pag-mount ng patuloy na storage sa mga cluster node. Ipinapatupad din ito bilang isang gRPC server, ngunit ginagamit nito ang primitive DaemonSet.

Paano gumagana ang CSI plugin sa Kubernetes

Maaari mong malaman ang tungkol sa ilang iba pang mga detalye ng gawain ng CSI, halimbawa, mula sa artikulong "Pag-unawa sa C.S.I.' pagsasalin ng kung saan nai-publish namin isang taon na ang nakakaraan.

Ang mga pakinabang ng naturang pagpapatupad

• Para sa mga pangunahing bagay tulad ng pagpaparehistro ng driver para sa isang node, nagpatupad ang mga developer ng Kubernetes ng isang hanay ng mga container. Hindi mo na kailangang bumuo ng isang tugon ng JSON na may mga kakayahan sa iyong sarili, tulad ng ginawa para sa Flexvolume plugin.
• Sa halip na "i-slipping" ang mga executable na file papunta sa mga node, nag-a-upload na kami ngayon ng mga pod sa cluster. Ito ang una naming inaasahan mula sa Kubernetes: lahat ng proseso ay nangyayari sa loob ng mga container na naka-deploy gamit ang mga primitive ng Kubernetes.
• Hindi mo na kailangang bumuo ng isang RPC server at RPC client upang ipatupad ang mga kumplikadong driver. Ang kliyente ay ipinatupad para sa amin ng mga developer ng Kubernetes.
• Ang pagpasa ng mga argumento upang gumana sa gRPC protocol ay higit na maginhawa, nababaluktot at maaasahan kaysa sa pagpasa sa mga ito sa pamamagitan ng mga argumento ng command line. Upang maunawaan kung paano magdagdag ng suporta para sa mga sukatan ng paggamit ng dami sa CSI sa pamamagitan ng pagdaragdag ng standardized na paraan ng gRPC, maaari mong basahin ang: ang aming kahilingan sa paghila para sa vsphere-csi driver.
• Nagaganap ang komunikasyon sa pamamagitan ng mga socket ng IPC, upang hindi malito kung ipinadala ng kubelet ang kahilingan sa tamang pod.

Ang listahang ito ba ay nagpapaalala sa iyo ng anuman? Ang mga pakinabang ng CSI ay paglutas ng parehong mga problema, na hindi isinasaalang-alang sa pagbuo ng Flexvolume plugin.

Natuklasan

Ang CSI bilang isang pamantayan para sa pagpapatupad ng mga custom na plugin para sa pakikipag-ugnayan sa mga warehouse ng data ay mainit na tinanggap ng komunidad. Bukod dito, dahil sa kanilang mga pakinabang at kakayahang magamit, ang mga driver ng CSI ay nilikha kahit para sa mga sistema ng imbakan tulad ng Ceph o AWS EBS, mga plugin para sa pagtatrabaho kung saan idinagdag sa pinakaunang bersyon ng Kubernetes.

Sa simula ng 2019, mga in-tree na plugin ay idineklara nang hindi na ginagamit. Plano naming patuloy na suportahan ang Flexvolume plugin, ngunit hindi bubuo ng bagong functionality para dito.

Kami mismo ay may karanasan na sa paggamit ng ceph-csi, vsphere-csi at handa nang idagdag sa listahang ito! Sa ngayon, kinakaya ng CSI ang mga gawaing itinalaga dito, ngunit maghihintay kami at tingnan.

Huwag kalimutan na ang lahat ng bago ay isang magandang muling pag-iisip ng luma!

PS

Basahin din sa aming blog:

• «Naiintindihan namin ang Container Storage Interface (sa Kubernetes at hindi lamang)";
• «Sa Rook o hindi sa Rook - iyon ang tanong";
• «Ipinapakilala ang alpha na bersyon ng mga volume snapshot sa Kubernetes'.

Pinagmulan: www.habr.com