Sējuma spraudņi Kubernetes krātuvei: no Flexvolume līdz CSI

Kad Kubernetes vēl bija 1.0.0 versijā, pastāvēja apjoma spraudņi. Tie bija nepieciešami, lai savienotu pastāvīgu konteineru datu glabāšanas sistēmas ar Kubernetes. To nebija daudz, un tādi glabāšanas pakalpojumu sniedzēji kā GCE PD, Ceph, AWS EBS un citi bija vieni no pirmajiem, kas tos ieviesa.

Kubernetes komplektā tika iekļauti spraudņi, tāpēc arī nosaukums "in-tree". Tomēr daudzi uzskatīja, ka esošais šādu spraudņu komplekts ir nepietiekams. Daži "dari pats" entuziasti pievienoja Kubernetes kodolam vienkāršus spraudņus, izmantojot ielāpus, pēc tam izveidoja savu Kubernetes un izvietoja to savos serveros. Taču laika gaitā Kubernetes izstrādātāji saprata, ka zivis problēmu nevar atrisināt. Cilvēkiem ir nepieciešams makšķereUn Kubernetes v1.2.0 laidienā tas parādījās…

Flexvolume spraudnis: makšķere ar minimāliem iestatījumiem

Kubernetes izstrādātāji izveidoja spraudni FlexVolume, kas bija loģisks mainīgo un metožu apvalks darbam ar Flexvolume draiveriem, ko ieviesa trešo pušu izstrādātāji.

Apstāsimies un tuvāk aplūkosim, kas ir FlexVolume draiveris. Tas ir sava veida izpildāmais fails (binārais fails, Python skripts, Bash skripts utt.), kas izpildot pieņem komandrindas argumentus un atgriež ziņojumu ar iepriekš definētiem laukiem JSON formātā. Pēc vienošanās pirmais komandrindas arguments vienmēr ir metode, bet pārējie argumenti ir tās parametri.

CIFS koplieto savienojuma shēmu programmā OpenShift. Flexvolume draiveris atrodas tieši centrā.

Minimālais metožu kopums izskatās šādi:

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

Izmantojot metodes attach и detach definēs scenāriju, kuru kubelet ievēros nākotnē, izsaucot draiveri. Ir arī īpašas metodes expandvolume и expandfs, kas ir atbildīgi par skaļuma lieluma dinamisko mainīšanu.

Kā piemēru izmaiņām, ko metode pievieno expandvolume, un līdz ar to iespēju veikt skaļuma maiņu reāllaikā, varat apskatīt mūsu pieprasījuma Krauķa Cefa operatorā.

Šeit ir Flexvolume draivera ieviešanas piemērs darbam ar 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

Tātad, pēc faktiskā izpildāmā faila sagatavošanas ir nepieciešams Izvietot draiveri Kubernetes klasterīDraiverim jāatrodas katrā klastera mezglā saskaņā ar iepriekš norādītu ceļu. Pēc noklusējuma tika atlasīts šāds ceļš:

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

...bet, izmantojot dažādus Kubernetes izplatījumus (OpenShift, Rancher…), ceļš var atšķirties.

Flexvolume problēmas: Kā pareizi mest makšķeri?

Flexvolume draivera izvietošana klastera mezglos izrādījās nebūt ne triviāls uzdevums. Pēc operācijas manuālas veikšanas vienu reizi var viegli nonākt situācijā, kad klasterim tiek pievienoti jauni mezgli: jauna mezgla pievienošanas, automātiskas horizontālas mērogošanas vai — vēl ļaunāk — mezgla aizstāšanas dēļ darbības traucējumu dēļ. Šādā gadījumā piekļuve krātuvei šajos mezglos tiks ierobežota. nav iespējams, līdz manuāli pievienojat tiem Flexvolume draiveri.

Šīs problēmas risinājums bija viens no Kubernetes primitīvajiem elementiem — DaemonSetKad klasterī parādās jauns mezgls, tajā automātiski tiek izveidots mūsu DaemonSet pods, pievienojot tam lokālu sējumu, izmantojot FlexVolume draiveru meklēšanas ceļu. Pēc veiksmīgas izveides pods kopē draiverim nepieciešamos failus diskā.

Šeit ir šāda DaemonSet piemērs Flexvolume spraudņa izvietošanai:

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>

...un Bash skripta piemērs Flexvolume draivera izvietošanai:

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

Ir svarīgi neaizmirst par kopēšanas darbību nav atomisksPastāv liels risks, ka kubelets sāks izmantot draiveri pirms tā sagatavošanas procesa pabeigšanas, kas izraisīs sistēmas kļūdu. Pareizā pieeja ir vispirms kopēt draivera failus ar citu nosaukumu un pēc tam izmantot atomāro pārdēvēšanas darbību.

Ceph darbības diagramma Rook operatorā: diagrammā redzamais Flexvolume draiveris atrodas Rook aģenta iekšpusē.

Nākamā problēma, izmantojot Flexvolume draiverus, ir tā, ka lielākajai daļai krātuves klastera mezglā šim nolūkam ir jāinstalē nepieciešamā programmatūra (piemēram, Ceph pakotne ceph-common). Flexvolume spraudnis sākotnēji nebija paredzēts tik sarežģītu sistēmu ieviešanai.

Oriģināls risinājums šai problēmai ir redzams Rook operatora Flexvolume draivera ieviešanā:

Pats draiveris ir ieviests kā RPC klients. IPC ligzda saziņai atrodas tajā pašā direktorijā, kur pats draiveris. Atceramies, ka draivera failu kopēšanai vislabāk ir izmantot DaemonSet, kas pievieno draivera direktoriju kā sējumu. Pēc nepieciešamo draivera failu kopēšanas rook pods nemirst, bet gan izveido savienojumu ar IPC ligzdu caur pievienoto sējumu kā pilnvērtīgs RPC serveris. ceph-common pakotne jau ir instalēta poda konteinerā. IPC ligzda nodrošina, ka kubelets sazināsies ar podu, kas atrodas tajā pašā mezglā. Ģeniāli vienkārši!

Ardievu, mūsu jaukie… kokā iebūvētie spraudņi!

Kubernetes izstrādātāji atklāja, ka kodolā ir divdesmit krātuves spraudņi. Izmaiņas katrā no tiem, vienā vai otrā veidā, tiek veiktas visā Kubernetes izlaišanas ciklā.

Izrādās, ka, lai izmantotu jauno krātuves spraudņa versiju, viss klasteris ir jāatjauninaTurklāt jūs varētu pārsteigt, ka jauna Kubernetes versija pēkšņi kļūst nesaderīga ar jūsu izmantoto kodolu. Linux...Un tā jūs noslaucāt asaras un, sakodis zobus, saskaņojat ar priekšniecību un lietotājiem kodola atjaunināšanas laiku. Linux un Kubernetes klasteris. Tas var izraisīt pakalpojuma dīkstāvi.

Situācija ir vairāk nekā komiska, vai ne? Visai kopienai ir kļuvis skaidrs, ka šī pieeja nedarbojas. Kubernetes izstrādātāji izlēmīgi paziņoja, ka kodolā vairs netiks pieņemti jauni krātuves spraudņi. Turklāt, kā jau zināms, Flexvolume spraudņa ieviešanā ir konstatētas vairākas nepilnības…

Jaunākais Kubernetes papildinājums, CSI apjoma spraudnis, bija paredzēts, lai vienreiz un uz visiem laikiem atrisinātu pastāvīgo datu glabāšanas problēmu. Tā alfa versija, kas plašāk pazīstama kā Out-of-Tree CSI Volume Plugins, tika izziņota laidienā. Kubernetes 1.9.

Konteineru uzglabāšanas saskarne jeb CSI 3000 spininga kāts!

Pirmkārt, es vēlētos norādīt, ka CSI nav tikai apjoma spraudnis, bet gan īsts. standarta par pielāgotu komponentu izveidi darbam ar datu noliktavāmBija paredzēts, ka konteineru orķestrēšanas sistēmas, piemēram, Kubernetes un Mesos, "iemācīsies" strādāt ar komponentiem, kas ieviesti saskaņā ar šo standartu. Un tagad Kubernetes to ir izdarījusi.

Kā CSI spraudnis darbojas Kubernetes vidē? CSI spraudnis darbojas ar īpašiem draiveriem (CSI draiveri), ko izstrādājuši trešo pušu izstrādātāji. Kubernetes CSI draiverim jāsastāv no vismaz diviem komponentiem (podiem):

• kontrolieris — pārvalda ārējo pastāvīgo krātuvi. Tā ir ieviesta kā gRPC serveris, kas izmanto primitīvu StatefulSet.
• mezgls — ir atbildīgs par pastāvīgās krātuves pievienošanu klastera mezgliem. Tas ir ieviests arī kā gRPC serveris, taču tas izmanto primitīvu. DaemonSet.

Kā CSI spraudnis darbojas Kubernetes vidē

Par citām CSI darba detaļām varat uzzināt, piemēram, no raksta “CSI izpratne" kura tulkojums Mēs to publicējām pirms gada.

Šādas ieviešanas priekšrocības

• Pamatuzdevumu veikšanai, piemēram, draivera reģistrēšanai mezglam, Kubernetes izstrādātāji ieviesa konteineru kopu. Vairs nav manuāli jāģenerē JSON atbilde ar iespējām, kā tas tika darīts ar Flexvolume spraudni.
• Izpildāmo failu vietā mezglos mēs tagad izvietojam podus klasterī. To mēs vienmēr esam gaidījuši no Kubernetes: visi procesi notiek konteineros, kas izvietoti, izmantojot Kubernetes primitīvus.
• Sarežģītu draiveru ieviešanai vairs nav nepieciešams izstrādāt RPC serveri un RPC klientu. Kubernetes izstrādātāji ir ieviesuši klientu mūsu vietā.
• Argumentu nodošana darbam, izmantojot gRPC protokolu, ir daudz ērtāka, elastīgāka un uzticamāka nekā to nodošana, izmantojot komandrindas argumentus. Lai saprastu, kā pievienot apjoma lietojuma metrikas atbalstu CSI, pievienojot standartizētu gRPC metodi, lūdzu, skatiet sadaļu mūsu pieprasījuma vsphere-csi draiverim.
• Saziņa notiek, izmantojot IPC ligzdas, lai izvairītos no neskaidrībām par to, vai kubelets nosūtīja pieprasījumu uz pareizo podu.

Vai šis saraksts jums šķiet saistošs? CSI priekšrocības ir šādas: risinājumu tieši šīm problēmām, kas netika ņemti vērā, izstrādājot Flexvolume spraudni.

Atzinumi

CSI kā standarts pielāgotu spraudņu ieviešanai mijiedarbībai ar datu glabātuvi ir guvis sabiedrības atzinību. Turklāt, pateicoties tā priekšrocībām un daudzpusībai, CSI draiveri tiek veidoti pat tādām glabāšanas sistēmām kā Ceph vai AWS EBS, kuru spraudņi tika pievienoti jau pirmajā Kubernetes versijā.

2019. gada sākumā koka spraudņi tika pasludināti par novecojušiemMēs plānojam turpināt atbalstīt Flexvolume spraudni, bet neizstrādāsim tam jaunas funkcijas.

Mums jau ir pieredze, izmantojot ceph-csi un vsphere-csi, un esam gatavi paplašināt šo sarakstu! Līdz šim CSI ir lieliski ticis galā ar paredzētajiem uzdevumiem, taču laiks rādīs.

Neaizmirstiet, ka viss jaunais ir pārdomāta vecā pārvērtēšana!

PS

Lasi arī mūsu emuārā:

• «Mēs saprotam konteineru krātuves saskarni (Kubernetes un ne tikai)";
• «Rokam vai nē - tāds ir jautājums";
• «Iepazīstinām ar apjoma momentuzņēmumu alfa versiju pakalpojumā Kubernetes'.

Avots: www.habr.com