Plugin volume pikeun neundeun Kubernetes: ti Flexvolume ka CSI

Balik nalika Kubernetes masih v1.0.0, aya volume plugins. Éta diperyogikeun pikeun nyambungkeun sistem ka Kubernetes pikeun nyimpen data wadahna (permanén). Jumlahna leutik, sareng diantara anu pangheulana nyaéta panyadia panyimpen sapertos GCE PD, Ceph, AWS EBS sareng anu sanésna.

Plugin dikirimkeun sareng Kubernetes, naha éta ngagaduhan namina - in-tree. Nanging, pikeun seueur, set plugins sapertos kitu tétéla henteu cekap. Pengrajin nambihan plugins saderhana kana inti Kubernetes nganggo patches, saatos aranjeunna ngumpul Kubernetes sorangan sareng dipasang dina server na. Tapi kana waktosna, pamekar Kubernetes sadar éta lauk masalah teu bisa direngsekeun. Jalma butuh pancing. Sareng dina sékrési Kubernetes v1.2.0 éta muncul ...

plugin Flexvolume: rod fishing minimal

Pangembang Kubernetes nyiptakeun plugin FlexVolume, anu mangrupikeun kerangka logis tina variabel sareng metode pikeun damel sareng supir Flexvolume anu dilaksanakeun ku pamekar pihak katilu.

Hayu urang lirén sareng ningal langkung caket kana naon supir FlexVolume. Ieu tangtu file laksana (file binér, Aksara Python, Aksara Bash, jeung sajabana), anu, nalika dieksekusi, nyandak argumen baris paréntah salaku input sarta mulih pesen kalawan widang pre-dipikawanoh dina format JSON. Numutkeun konvénsi, argumen baris paréntah anu munggaran sok mangrupikeun metode, sareng argumen sésana mangrupikeun parameterna.

Diagram sambungan pikeun Saham CIFS di OpenShift. Supir Flexvolume - Katuhu dina Pusat

Métode set minimum Sigana kieu:

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

Ngagunakeun Métode attach и detach bakal nangtukeun skenario nu kubelet bakal meta dina mangsa nu bakal datang nalika nelepon supir. Aya ogé métode husus expandvolume и expandfs, anu tanggung jawab pikeun ngarobah ukuran polumeu sacara dinamis.

Salaku conto tina parobahan nu metoda nambahkeun expandvolume, tur mibanda kamampuhan pikeun ngarobah ukuran volume sacara real waktos, Anjeun bisa familiarize diri kalawan pamundut tarik urang di Rook Ceph Operator.

Sareng ieu mangrupikeun conto palaksanaan supir Flexvolume pikeun damel sareng 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

Janten, saatos nyiapkeun file anu tiasa dieksekusi, anjeun kedah unggah supir ka klaster Kubernetes. Supir kedah aya dina unggal titik klaster dumasar kana jalur anu tos ditangtukeun. Sacara standar dipilih:

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

... tapi lamun ngagunakeun distribusi Kubernetes béda (OpenShift, Rancher ...) jalur bisa jadi béda.

Masalah Flexvolume: kumaha carana tuang rod fishing leres?

Ngunggah supir Flexvolume ka titik kluster tétéla janten tugas anu henteu sepele. Saatos operasi sacara manual sakali, gampang mendakan kaayaan dimana titik-titik anyar muncul dina kluster: kusabab tambahan titik énggal, skala horizontal otomatis, atanapi - anu langkung parah - ngagantian titik kusabab gangguan. Dina hal ieu, gawé bareng gudang on titik ieu kudu dipigawé teu mungkin, nepi ka anjeun masih sacara manual nambahkeun supir Flexvolume ka aranjeunna.

Solusi pikeun masalah ieu mangrupikeun salah sahiji primitif Kubernetes - DaemonSet. Nalika titik anyar muncul dina kluster, éta otomatis ngandung pod ti DaemonSet kami, dimana volume lokal napel sapanjang jalur pikeun milarian supir Flexvolume. Saatos kreasi suksés, pod nyalin file anu dipikabutuh pikeun supir tiasa dianggo kana disk.

Ieu mangrupikeun conto DaemonSet sapertos pikeun nempatkeun 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>

... sareng conto skrip Bash pikeun nempatkeun supir 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

Kadé ulah poho yén operasi salinan henteu atom. Aya kamungkinan luhur yén kubelet bakal ngamimitian nganggo supir sateuacan prosés provisioning parantos réngsé, nyababkeun sistem nabrak. Pendekatan anu bener nyaéta nyalin heula file supir dina nami anu béda, teras nganggo operasi ngaganti ngaran atom.

Diagram gawé bareng Ceph dina operator Rook: supir Flexvolume dina diagram perenahna di jero agén Rook

Masalah salajengna nalika nganggo panggerak Flexvolume nyaéta pikeun kalolobaan panyimpen dina titik kluster software diperlukeun pikeun ieu kudu dipasang (Contona, pakét ceph-umum pikeun Ceph). Mimitina, plugin Flexvolume henteu dirancang pikeun nerapkeun sistem kompléks sapertos kitu.

Solusi asli pikeun masalah ieu tiasa ditingali dina palaksanaan supir Flexvolume operator Rook:

Supir sorangan dirancang salaku klien RPC. Stop kontak IPC pikeun komunikasi lokasina di diréktori sarua salaku supir sorangan. Kami émut yén pikeun nyalin file supir langkung saé ngagunakeun DaemonSet, anu nyambungkeun diréktori sareng supir salaku volume. Saatos nyalin file supir rook perlu, pod ieu teu maot, tapi nyambung ka stop kontak IPC ngaliwatan volume napel salaku server RPC full-fledged. Paket ceph-umum geus dipasang di jero wadah pod. Stop kontak IPC ensures yén kubelet bakal komunikasi sareng persis pod nu lokasina dina titik sarua. Sagalana cerdik basajan! ..

Wilujeng sumping, urang kaasih... in-tree plugins!

Pangembang Kubernetes mendakan yén jumlah plugins pikeun neundeun dina inti nyaéta dua puluh. Sarta parobahan dina unggal sahijina, salah sahiji atawa cara séjén, ngaliwatan siklus release Kubernetes pinuh.

Tétéla yén ngagunakeun versi anyar tina plugin gudang, anjeun kudu ngamutahirkeun sakabéh klaster. Sajaba ti ieu, Anjeun bisa jadi reuwas yen versi anyar tina Kubernetes bakal ujug-ujug jadi sauyunan jeung kernel Linux Ubuntu nu Anjeun pake... Jadi Anjeun ngusap cipanon Anjeun jeung, gritting huntu Anjeun, koordinasi jeung manajemén jeung pamaké Anjeun waktu pikeun update kernel Linux Ubuntu jeung klaster Kubernetes. Kalawan mungkin downtime dina penyediaan jasa.

Kaayaan éta langkung pikaseurieun, saur anjeun henteu? Janten jelas ka sakumna masarakat yén pendekatan éta henteu jalan. Ku kaputusan dihaja, pamekar Kubernetes ngumumkeun yén plugins anyar pikeun gawé bareng gudang moal deui ditarima kana kernel. Salaku tambahan, sakumaha anu parantos urang terang, sajumlah kakurangan anu diidentipikasi dina palaksanaan plugin Flexvolume ...

Plugin tambihan panganyarna pikeun volume dina Kubernetes, CSI, disebat pikeun nutup masalah sareng neundeun data anu pengkuh sakali sareng salamina. Versi alfa na, langkung seueur disebut Out-of-Tree CSI Volume Plugins, diumumkeun dina sékrési Kubernet 1.9.

Wadahna Panyimpenan Interface, atanapi CSI 3000 rod spinning!

Anu mimiti, abdi hoyong dicatet yén CSI henteu ngan hiji plugin volume, tapi nyata standar dina nyieun komponén custom pikeun gawé bareng gudang data. Sistem orkestrasi wadah sapertos Kubernetes sareng Mesos sakuduna "diajar" kumaha cara damel sareng komponén anu dilaksanakeun dumasar kana standar ieu. Sareng ayeuna kuring parantos diajar Kubernetes.

Naon struktur plugin CSI di Kubernetes? Plugin CSI tiasa dianggo sareng supir khusus (supir CSI) ditulis ku pamekar pihak katilu. Supir CSI di Kubernetes kedah minimal diwangun ku dua komponén (pods):

• controller - ngatur panyimpenan pengkuh éksternal. Hal ieu dilaksanakeun salaku server gRPC, nu primitif dipaké StatefulSet.
• titik - tanggel waler pikeun neundeun gudang pengkuh kana titik klaster. Éta ogé dilaksanakeun salaku server gRPC, tapi nganggo primitif DaemonSet.

Kumaha plugin CSI dianggo dina Kubernetes

Anjeun tiasa ngalenyepan sababaraha rinci anu sanés ngeunaan padamelan CSI, contona, tina tulisan "Ngartos C.S.I.», tarjamahan nu urang diterbitkeun sataun katukang.

Kaunggulan tina palaksanaan misalna hiji

• Pikeun hal dasar sapertos ngadaptar supir pikeun node, pamekar Kubernetes ngalaksanakeun sakumpulan wadah. Anjeun henteu kedah deui ngahasilkeun réspon JSON kalayan kamampuan sorangan, sapertos anu dilakukeun pikeun plugin Flexvolume.
• Gantina "slipping" file laksana kana titik, urang ayeuna unggah pods ka kluster. Ieu anu mimitina urang ngarepkeun ti Kubernetes: sadaya prosés lumangsung di jero wadah anu dipasang nganggo primitif Kubernetes.
• Anjeun henteu kedah deui ngembangkeun server RPC sareng klien RPC pikeun ngalaksanakeun supir kompleks. Klién ieu dilaksanakeun pikeun urang ku pamekar Kubernetes.
• Ngalirkeun argumen pikeun ngerjakeun protokol gRPC langkung merenah, fleksibel sareng dipercaya tibatan ngalangkungan argumen baris paréntah. Pikeun ngartos kumaha carana nambihan dukungan pikeun métrik pamakean volume ka CSI ku cara nambihan metode gRPC standar, anjeun tiasa maca: pamundut tarik urang pikeun supir vsphere-csi.
• Komunikasi lumangsung via sockets IPC, ku kituna teu jadi bingung naha kubelet dikirim pamundut ka pod bener.

Naha daptar ieu ngingetkeun anjeun naon waé? Keunggulan CSI adalah ngarengsekeun masalah anu sami, anu henteu diperhatoskeun nalika ngembangkeun plugin Flexvolume.

papanggihan

CSI salaku standar pikeun nerapkeun plugins khusus pikeun berinteraksi sareng gudang data ditampi pisan ku masarakat. Sumawona, kusabab kaunggulan sareng fleksibilitasna, supir CSI didamel bahkan pikeun sistem panyimpen sapertos Ceph atanapi AWS EBS, plugins pikeun damel sareng anu parantos ditambah dina versi Kubernetes anu munggaran.

Dina awal 2019, in-tree plugins geus dinyatakeun luntur. Kami ngarencanakeun pikeun terus ngadukung plugin Flexvolume, tapi moal ngembangkeun fungsionalitas anyar pikeun éta.

Urang sorangan geus boga pangalaman ngagunakeun ceph-csi, vsphere-csi sarta siap pikeun nambahkeun kana daptar ieu! Sajauh ieu, CSI parantos ngatasi tugas-tugas anu ditugaskeun ka dinya, tapi urang antosan sareng ningali.

Tong hilap yén sadayana anu énggal mangrupikeun pamikiran ulang anu saé pikeun anu lami!

PS

Baca ogé dina blog urang:

• «Urang ngarti Antarmuka Panyimpen Wadahna (dina Kubernetes sanés ngan ukur)";
• «Ka Rook atanapi henteu ka Rook - éta patarosan";
• «Ngawanohkeun versi alfa tina jepretan volume di Kubernetes".

sumber: www.habr.com