Kubernetesi salvestusmahtude pluginad: Flexvolume'ist CSI-ni

Aegadel, mil Kubernetes oli veel v1.0.0, eksisteerisid mahtude pluginad (volume plugins). Need olid vajalikud Kubernetes'i süsteemide ühendamiseks, et salvestada konteinerite püsivaid (püsivaid) andmeid. Nende arv oli väike, esmaseks olid sellised salvestusteenuse pakkujad nagu GCE PD, Ceph, AWS EBS ja teised.

Pluginad tarniti koos Kubernetes'iga, mistõttu saadi nende nimeks in-tree. Siiski osutus olemasolev pluginate kogus paljudele ebapiisavaks. Kavalad arendajad lisasid lihtsaid pluginaid Kubernetes'i tuuma, kasutades patše, seejärel koondasid nad oma Kubernetes'i ja paigaldasid selle oma serveritesse. Kuid aja jooksul mõistsid Kubernetes'i arendajad, et selle probleemiga ei lahenda. Inimestele on vajane intellekt . Ja Kubernetes v1.2.0 versioonis see ilmus...Flexvolume plugin: lihtne intellekt

Kubernetes'i arendajad lõid FlexVolume plugina, mis oli loogiline kapseldus muutujaist ja meetoditest kolmandate osapoolte Flexvolume draiveritega töötamiseks.

Peatugem ja vaatame lähemalt, mida kujutab endast FlexVolume draiver. See on teatud

täidesaatav fail (binaarfail, Python'i skript, Bash'i skript jne), mis täitmise ajal võtab vastu käsklisi argumendi ja tagastab sõnumi juba määratud väljadega JSON-formaadis. Esimene käskluse argumendi poolt on alati meetod ning ülejäänud argumendid on selle parameetrid. CIFS Share'i ühendamise skeem OpenShiftis. Flexvolume draiver on täpselt keskel

Minimaalne meetodite kogum

flexvolume_driver mount # vastutab mahu ühendamise eest pod'iga # Tagastatava sõnumi formaat: { "status": "Success"/"Failure"/"Not supported", "message": "Miks tagastati just see staatus", }flexvolume_driver unmount # vastutab mahu eemaldamise eest pod'ist # Tagastatava sõnumi formaat: { "status": "Success"/"Failure"/"Not supported", "message": "Miks tagastati just see staatus", }flexvolume_driver init # vastutab plugina initsialiseerimise eest # Tagastatava sõnumi formaat: { "status": "Success"/"Failure"/"Not supported", "message": "Miks tagastati just see staatus", // Määrab, kas draiver kasutab meetodeid attach/detach "capabilities":{"attach": True/False} } näeb välja nagu:

Meetodite kasutamine

attach detach ja lahutamine määrab stsenaariumi, mille alusel tulevikus kubelet käitub draiverit kutsudes. On ka spetsiaalsed meetodid expandvolume ja expandfs, mis vastutavad mahu dünaamilise suuruse muutmise eest.

Muudatuste näiteks, mida meetod lisab expandvolume, koos sellega — ja võimalusega teha mahtude muutmine reaalajas, saab tutvuda meie pull requests Rook Ceph Operatoris.

Siin on Flexvolume-draiveri näide NFS-i jaoks:

usage() {
    err "Vale kasutus. Kasutamine: "
    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": "Kinnitamata ${NFS_SERVER}:${SHARE} ${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": "Volumes unmountimine ${MNTPATH} ebaas"}"
        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

Nii et pärast käideldava faili ettevalmistamist tuleb draiver Kubernetes'i klastri. Draiver peab olema igas klastri sõlmes vastavalt eelnevalt kokkulepitud teele. Vaikimisi on valitud:

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

… kuid erinevate Kubernetes’i jaotuste (OpenShift, Rancher…) puhul võib tee olla erinev.

Flexvolume probleemid: kuidas õigeid seoseid luua?

Flexvolume-draiveri paigaldamine klastri sõlmedele osutus keeruliseks ülesandeks. Pärast käsitsi ühe korra toimimist võib kergesti sattuda olukorda, kus klastrisse ilmuvad uued sõlmed: uue sõlme lisamine, automaatne horisontaalne skaleerimine või - mis on hullem - sõlme asendamine rikke tõttu. Sellisel juhul ei saa andmete talletamist nendel sõlmedel teostada, kuni te ise manuaalselt Flexvolume-draiveri nendesse lisate.

Probleemide lahendamiseks kasutatakse ühte Kubernetes'e primitiivi — DaemonSet. Uue sõlme ilmumisel klastri juurde lisatakse sellele automaatselt pod meie DaemonSet'ist, millele on ühendatud kohalik maht Flexvolume-juhiste leidmiseks. Kui pod on edukalt loodud, kopeerib see draiveri tööks vajalikud failid kettale.

Siin on näide sellisest DaemonSet'ist Flexvolume-pluginni paigaldamiseks:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: flex-set
spec:
  template:
    metadata:
      name: flex-deploy
      labels:
        app: flex-deploy
    spec:
      containers:
        - image: 
          name: flex-deploy
          securityContext:
              privileged: true
          volumeMounts:
            - mountPath: /flexmnt
              name: flexvolume-mount
      volumes:
        - name: flexvolume-mount
          hostPath:
            path:

… ja Bash-skripti näide Flexvolume-draiveri paigaldamiseks:

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

Oluline on mitte unustada, et kopeerimine ei ole aatomaarne. On suur tõenäosus, et kubelet hakkab kasutama draiverit enne, kui ettevalmistamise protsess on lõpetatud, mis toob kaasa süsteemi tõrke. Õige lähenemine oleks esmalt kopeerida draiveri failid teise nime alla ja seejärel kasutada aatomaarset ümbernimetamise operatsiooni.

Töövoog Cephiga Rook'i operaatoris: Flexvolume-draiver asub skeemis Rook'i agendi sees

Järgmine probleem Flexvolume-draiverite kasutamisel on see, et enamikul andmesalvestusseadmetest peab klastri sõlmes olema vajalik tarkvara (näiteks пакеt ceph-common Ceph'i jaoks). Algul ei olnud Flexvolume-plugin mõeldud nii keeruliste süsteemide rakendamiseks. Algne lahendus sellele probleemile on nähtav Rook'i operaatori Flexvolume-draiveri rakenduses:

Draiver ise on loodud RPC-klientina. IPC-soket suhtlemiseks asub samas kataloogis, kus on suur draiver. Me mäletame, et draiveri failide kopeerimiseks oleks hea kasutada DaemonSet'i, mis ühendab endale draiveri katalooge. Pärast draiveri vajalike failide kopeerimist ei sure rook see pod, vaid ühendub IPC-soketiga läbi ühendatud mahu nagu täieõiguslik RPC-server. Pakett ceph-common on juba paigaldatud pod'i konteinerisse. IPC-soket annab kindlustunde, et kubelet suhtleb endast ühe sõlmega asuva pod'iga. Kõik geniaalne on lihtne!..

Head aega, meie armsad… in-tree pluginid!

Kuna meie armsad… in-tree pluginid!

Kubernetesi arendajad on avastanud, et tuumapõhiseid pluginaid on kokku kakskümmend. Igas neist toimub muudatus läbides paratamatult kogu Kubernetes'e väljaandetsüklit.

Selgub, et uue versiooni plugina kasutamiseks on vajalik kogu klastrit uuendada. Lisaks võite märgata, et uus Kubernetes'i versioon võib äkitselt olla ühilduv kasutatava Linuxi tuumaga… Seetõttu pühite pisaraid ja hammaste kiristades lepite koos juhtkonna ja kasutajatega kokku Linuxi tuuma ja Kubernetes'e klastrite värskendamise aja. Mis võib põhjustada teenuste katkestusi.

Situatsioon on rohkem kui koomiline, kas pole? Kogu kogukond on aru saanud, et lähenemisviis ei toimi. Jõuliselt kuulutavad Kubernetes'e arendajad, et uusi pluginaid andmete salvestamiseks ei võeta enam tuuma. Lisaks oleme juba teadlikud, et Flexvolume-pluginis on ilmnenud mitmeid puudusi...

Viimase lisatud pluginana, mis pidi lõplikult lahendama püsivate andmesalvestuste küsimuse, tõstatus CSI. Selle alfa-versiooni, mida tuntakse täieliku nimega Out-of-Tree CSI Volume Plugins, kuulutati välja versioonis Kubernetes 1.9.

Container Storage Interface, ehk spinning CSI 3000!

Esimese asjana tahaksin märkida, et CSI ei ole lihtsalt volume plugin, vaid tõeline standard andmete salvestuskomponentide loomise jaoks. Eeldati, et konteinerite orkestreerimissüsteemid, nagu Kubernetes ja Mesos, peaksid õppima töötama komponentidega, mis on rakendatud selle standardi alusel. Ja nüüd on Kubernetes juba õppinud.

Kuidas on CSI-plugin Kubernetes'es üles ehitatud? CSI-plugin töötab spetsiaalsete draiveritega (CSI-draiveritega), mida on kirjutanud kolmandate poolte arendajad. CSI-draiver Kubernetes'es peab minimaalselt koosnema kahest komponendist (pod'idest):

• Kontroller — juhib väliseid püsivaid andmesalvestusi. Vabastatakse gRPC-serverina, mille jaoks kasutatakse primitivi StatefulSet.
• Node — vastutab püsivate andmesalvestuste ühendamise eest klastrite sõlmedesse. Samuti rakendatakse gRPC-serverina, kuid selle jaoks kasutatakse primitivi DaemonSet.

CSI-plugin tööpõhimõte Kubernetes'es

Mõningaid muid CSI tööpõhimõtete detaile saate teada, näiteks artiklist "Understanding the CSI», mille tõlget me avaldasime aastat tagasi.

Selle rakenduse eelised

• Põhiliste asjade jaoks – näiteks sõlme draiveri registreerimiseks – on Kubernetes'i arendajad rakendanud konteinerite komplekti. Nüüd ei ole vaja enam ise moodustada JSON- vastust capabilities, nagu see tehti Flexvolume pistikprogrammi puhul.
• Kohapeal käivitatavate failide „sissepanemise“ asemel laadime me nüüd klastrisse pod’id. Just seda me Kubernetes'ilt ootame: kõik protsessid toimuvad konteinerites, mis on käivitatud Kubernetes'e primitiivide abil.
• Komplekssete draiverite rakendamiseks ei ole enam vaja arendada RPC-serverit ja RPC-klienti. Klient on meie eest rakendanud Kubernetes'i arendajad.
• Argumentide edastamine gRPC protokolli kaudu on palju mugavam, paindlikum ja usaldusväärsem kui nende edastamine käskude rida argumentide kaudu. Et mõista, kuidas lisada CSI-le toetamist mahu mõõdikute jaoks standarditud gRPC-meetodi abil, saab tutvuda meie pull requests vsphere-csi draiveriga.
• Suhtlus toimub IPC-socketite kaudu, et mitte segi ajada, kuhu pod'ile kubelet päringu saatis.

Kas see nimekiri ei meenuta teile midagi? CSI eelised on lahendus nendele probleemidele, mis ei olnud arvesse võetud Flexvolume pistikprogrammi väljatöötamisel.

Järeldused

CSI kui standard kasutajate pistikprogrammide rakendamiseks andmesalvestuslahendustega suhtlemiseks on kogukonna poolt väga hästi vastu võetud. Veelgi enam, tänu oma eelistele ja universaalsusele luuakse CSI-draivereid isegi selliste salvestuslahenduste, nagu Ceph või AWS EBS jaoks, mille pistikprogrammide töötlus algas juba Kubernetes'i esimeses versioonis.

Aasta alguses 2019 kuulutati in-tree pistikprogrammid üksikasjalikult vana moodi. Plaanitakse jätkata Flexvolume pistikprogrammi toetamisega, kuid uusi funktsioone tema jaoks ei arenguta.

Meil on juba kogemus ceph-csi, vsphere-csi kasutamisel ja oleme valmis seda nimekirja täiendama! Praegu täidab CSI oma ülesandeid suurepäraselt, ja vaatame, mis edasi juhtub.

Ärge unustage, et kõik uus on hästi ümber mõeldud vana!

P.S.

Lugege ka meie blogist:

• «Mõistame Container Storage Interface'i (nii Kubernetes'es kui ka mujal)»;
• «Rook või mitte Rook — see on küsimus»;
• «Tutvume Kubernetes'e mahusnapshotide alfa-versiooniga».

Allikas: habr.com