🥇Kubernetes-en biltegiratzeko bolumen-pluginak: Flexvolume-tik CSI |-ra ProHoster

Kubernetes oraindik v1.0.0 zenean, bolumen-pluginak zeuden. Sistemak Kubernetesera konektatzeko behar ziren edukiontzien datu iraunkorrak (iraunkorrak) gordetzeko. Haien kopurua txikia zen, eta lehenengoen artean GCE PD, Ceph, AWS EBS eta beste biltegiratze hornitzaileak zeuden.

Pluginak Kubernetesekin batera entregatu ziren, eta horregatik jaso zuten izena - in-tree. Hala ere, askorentzat lehendik zegoen pluginen multzoa nahikoa ez zen. Artisauek plugin sinpleak gehitu zizkioten Kubernetes nukleoari adabakiak erabiliz, eta ondoren, beren Kubernetes muntatu eta zerbitzarietan instalatu zuten. Baina denborarekin, Kuberneteseko garatzaileak konturatu ziren horretaz arraina arazoa ezin da konpondu. Jendeak behar du arrantza kanabera. Eta Kubernetes v1.2.0 bertsioan agertu zen...

Flexvolume plugina: gutxieneko arrantza-kanabera

Kuberneteseko garatzaileek FlexVolume plugina sortu zuten, hau da, hirugarrenen garatzaileek inplementatutako Flexvolume kontrolatzaileekin lan egiteko aldagaien eta metodoen esparru logikoa zen.

Gelditu gaitezen eta ikus gaitezen zer den FlexVolume kontrolatzailea. Hau jakina da fitxategi exekutagarria (fitxategi bitarra, Python scripta, Bash scripta, etab.), exekutatzen denean, komando-lerroko argumentuak sarrera gisa hartzen ditu eta aurretik ezagutzen diren eremuak dituen mezu bat itzultzen du JSON formatuan. Konbentzioz, lehen komando-lerroko argumentua metodo bat da beti, eta gainerako argumentuak bere parametroak dira.

OpenShift-en CIFS Shares-en konexio-diagrama. Flexvolume Driver - Erdian

Gutxieneko metodoen multzoa hau itxura du:

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

Metodoak erabiltzea attach и detach kubeletak etorkizunean gidariari deitzean zein eszenatokitan jardungo duen zehaztuko du. Metodo bereziak ere badaude expandvolume и expandfs, bolumenaren tamaina dinamikoki aldatzeaz arduratzen direnak.

Metodoak gehitzen dituen aldaketen adibide gisa expandvolume, eta, horrekin, bolumenak denbora errealean tamaina aldatzeko gaitasunarekin, ezagutu dezakezu gure tira eskaera Rook Ceph Operator-en.

Eta hona hemen NFSrekin lan egiteko Flexvolume kontrolatzailearen ezarpenaren adibide bat:

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

Beraz, benetako fitxategi exekutagarria prestatu ondoren, behar duzu kargatu kontrolatzailea Kubernetes klusterera. Gidaria kluster-nodo bakoitzean kokatu behar da aurrez zehaztutako bide baten arabera. Berez hautatu zen:

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

... baina Kubernetes banaketa desberdinak erabiltzean (OpenShift, Rancher...) bidea ezberdina izan daiteke.

Flexbolumen arazoak: nola bota behar bezala arrantza-kanabera?

Flexvolume kontrolatzailea kluster-nodoetara kargatzea zeregin ez-trivial bat izan da. Eragiketa eskuz behin egin ondoren, erraza da klusterrean nodo berriak agertzen diren egoera batekin topatzea: nodo berri bat gehitzearen ondorioz, eskalatze horizontal automatikoa edo -okerrena dena- matxura baten ondorioz nodo bat ordezkatzea. Kasu honetan, nodo horien biltegiratzearekin lan egin beharko litzateke ezinezkoa da, Flexvolume kontrolatzailea eskuz gehitzen diezun arte.

Arazo honen konponbidea Kubernetes primitiboetako bat izan zen - DaemonSet. Klusterrean nodo berri bat agertzen denean, automatikoki gure DaemonSet-eko pod bat dauka, eta hari tokiko bolumen bat eransten zaio Flexvolume kontrolatzaileak aurkitzeko. Sortu ondoren, gailuak beharrezko fitxategiak kopiatzen ditu kontrolatzaileak diskoan funtziona dezan.

Hona hemen Flexvolume plugin bat ezartzeko DaemonSet baten adibide bat:

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>

... eta Flexvolume kontrolatzailea ezartzeko Bash script baten adibidea:

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

Garrantzitsua da ez ahaztu kopia eragiketa ez da atomikoa. Aukera handia dago kubelet-a kontrolatzailea erabiltzen hastea hornitze-prozesua amaitu baino lehen, sistema huts egitea eraginez. Planteamendu zuzena da lehenik gidariaren fitxategiak beste izen batekin kopiatzea, eta gero atomikoen izenaren eragiketa erabiltzea.

Ceph-ekin Rook operadorean lan egiteko diagrama: diagramako Flexvolume kontrolatzailea Rook agentearen barruan dago

Flexvolume kontrolatzaileak erabiltzean hurrengo arazoa kluster-nodo bateko biltegiratze gehiena da horretarako beharrezko softwarea instalatu behar da (adibidez, Ceph-erako ceph-common paketea). Hasieran, Flexvolume plugina ez zen sistema konplexuak ezartzeko diseinatu.

Arazo honen irtenbide original bat Rook operadorearen Flexvolume kontrolatzailearen inplementazioan ikus daiteke:

Gidaria bera RPC bezero gisa diseinatuta dago. Komunikaziorako IPC socketa kontrolatzailearen beraren direktorio berean dago. Gogoratzen dugu kontrolatzaile-fitxategiak kopiatzeko egokia litzatekeela DaemonSet erabiltzea, direktorioa kontrolatzailearekin bolumen gisa konektatzen duena. Beharrezko rook kontrolatzaile fitxategiak kopiatu ondoren, pod hau ez da hiltzen, baina erantsitako bolumenaren bidez IPC socketera konektatzen da RPC zerbitzari oso gisa. Ceph-common paketea dagoeneko instalatuta dago pod edukiontziaren barruan. IPC socketak kubelet nodo berean dagoen podarekin zehatz-mehatz komunikatuko dela ziurtatzen du. Asmagarria dena sinplea da!...

Agur, gure... zuhaitz barruko pluginak!

Kuberneteseko garatzaileek aurkitu zuten nukleoaren barruan biltegiratzeko pluginen kopurua hogei dela. Eta horietako bakoitzean aldaketa bat, modu batera edo bestera, Kubernetes kaleratze-ziklo osotik igarotzen da.

Biltegiratze pluginaren bertsio berria erabiltzeko, kluster osoa eguneratu behar duzu. Honetaz gain, harritu zaitezke Kubernetes-en bertsio berria bat-batean erabiltzen ari zaren Linux kernelarekin bateraezin bihurtuko delako... Beraz, malkoak garbitu eta, hortzak estutuz, zure zuzendaritzarekin eta erabiltzaileekin koordinatzen duzu denbora. eguneratu Linux nukleoa eta Kubernetes clusterra. Zerbitzuak ematean geldialdi posibleekin.

Egoera komikoa baino gehiago da, ez duzu uste? Komunitate osoarentzat argi geratu zen ikuspegia ez zela funtzionatzen. Nahita erabaki baten bidez, Kuberneteseko garatzaileek biltegiratzearekin lan egiteko plugin berriak ez direla onartuko kernelean iragarri dute. Horrez gain, dagoeneko dakigunez, Flexvolume pluginaren ezarpenean hainbat hutsune antzeman ziren...

Kubernetes-en bolumenetarako gehitutako azken pluginari, CSI, arazoa behin betiko biltegiratze iraunkorrarekin ixteko eskatu zitzaion. Bere alfa bertsioa, Out-of-Tree CSI Bolumen Pluginak bezala ezagutzen dena, oharra argitaratu zen. Kubernetes 1.9.

Edukiontzien biltegiratze interfazea edo CSI 3000 biraka egiteko hagatxoa!

Lehenik eta behin, adierazi nahi nuke CSI ez dela bolumen-plugin bat soilik, benetakoa baizik estandarra datu biltegiekin lan egiteko osagai pertsonalizatuak sortzeari buruz. Kubernetes eta Mesos bezalako edukiontzien orkestrazio sistemek estandar honen arabera inplementatutako osagaiekin lan egiten "ikasi" behar zuten. Eta orain Kubernetes ikasi dut.

Zein da CSI pluginaren egitura Kubernetes-en? CSI pluginak kontrolatzaile bereziekin funtzionatzen du (CSI gidariak) hirugarrenen garatzaileek idatzia. Kubernetes-en CSI kontrolatzaile batek gutxienez bi osagai izan behar ditu (pod):

Controller — kanpoko biltegiratze iraunkorrak kudeatzen ditu. gRPC zerbitzari gisa inplementatzen da, eta horretarako primitiboa erabiltzen da StatefulSet.
Nodoa — Kluster-nodoetan biltegiratze iraunkorra muntatzeaz arduratzen da. GRPC zerbitzari gisa ere inplementatuta dago, baina primitiboa erabiltzen du DaemonSet.

CSI pluginak nola funtzionatzen duen Kubernetes-en

CSIren lanaren beste xehetasun batzuk ezagutu ditzakezu, adibidez, " artikuluan "C.S.I.' horren itzulpena duela urtebete argitaratu genuen.

Ezarpen horren abantailak

Nodo baterako kontrolatzaile bat erregistratzeko oinarrizko gauzetarako, Kuberneteseko garatzaileek edukiontzi multzo bat inplementatu zuten. Jada ez duzu zuk zeuk sortu behar gaitasunekin JSON erantzunik, Flexvolume pluginerako egin zen bezala.
Fitxategi exekutagarriak nodoetara "larritu" beharrean, orain lekak kargatzen ditugu klusterera. Hau da hasieran Kubernetesengandik espero duguna: prozesu guztiak Kubernetes primitiboak erabiliz zabaldutako edukiontzien barruan gertatzen dira.
Jada ez duzu RPC zerbitzari bat eta RPC bezero bat garatu behar kontrolatzaile konplexuak ezartzeko. Bezeroa Kuberneteseko garatzaileek inplementatu ziguten.
GRPC protokoloaren gainean lan egiteko argumentuak pasatzea askoz erosoagoa, malguagoa eta fidagarriagoa da komando-lerroko argumentuetatik pasatzea baino. GRPC metodo estandarizatu bat gehituta bolumenaren erabilera-neurrietarako euskarria nola gehitu CSIra ulertzeko, irakur dezakezu: gure tira eskaera vsphere-csi kontrolatzailerako.
Komunikazioa IPC socket bidez gertatzen da, kubelet-ek eskaera pod egokira bidali duen ala ez nahasteko.

Zerrenda honek zerbait gogorarazten al dizu? CSIren abantailak hauek dira problema horiek berdin konpontzea, Flexvolume plugina garatzerakoan kontuan hartu ez direnak.

Findings

CSI datu biltegiekin elkarreragiteko plugin pertsonalizatuak ezartzeko estandar gisa oso harrera ona izan zuen komunitateak. Gainera, abantailak eta aldakortasuna direla eta, CSI kontrolatzaileak Ceph edo AWS EBS bezalako biltegiratze sistemetarako ere sortzen dira, eta horiekin lan egiteko pluginak Kubernetes-en lehen bertsioan gehitu ziren.

2019aren hasieran, zuhaitz barruko pluginak zaharkituta geratu dira. Flexvolume plugina onartzen jarraitzeko asmoa dugu, baina ez dugu funtzionalitate berririk garatuko.

Guk dagoeneko badugu esperientzia ceph-csi, vsphere-csi erabiltzen eta prest gaude zerrenda honetara gehitzeko! Orain arte, CSI esleitutako zereginei kolpeka ari da aurre egiten, baina itxaron eta ikusiko dugu.

Ez ahaztu berria dena zaharraren berrazterketa ona dela!

PS

Irakurri ere gure blogean:

Iturria: www.habr.com

Kubernetes biltegiratzeko bolumen-pluginak: Flexvolume-tik CSIra