ProHoster > Blog > Administrimi > Plugins për volumet e ruajtjes në Kubernetes: nga Flexvolume në CSI

Plugins për volumet e ruajtjes në Kubernetes: nga Flexvolume në CSI

Plugins për volumet e ruajtjes në Kubernetes: nga Flexvolume në CSI

Në kohët kur Kubernetes ishte ende v1.0.0, ekzistonin pluginë për volume (volume plugins). Ato ishin të nevojshme për të lidhur sistemet e ruajtjes për ruajtjen e të dhënave të qëndrueshme (persistente) të kontejnerëve. Numri i tyre ishte i vogël, dhe mes ofruesve të parë ishin GCE PD, Ceph, AWS EBS dhe të tjerë.

PluginĂ«t u shpĂ«rndanĂ« sĂ« bashku me Kubernetes, pĂ«r çka edhe morĂ«n emrin e tyre - in-tree. MegjithatĂ«, shumĂ« njerĂ«z e gjetĂ«n tĂ« pamjaftueshĂ«m ekzistuesin e tillĂ«. InovatorĂ«t shtonin pluginĂ« tĂ« thjeshta nĂ« bĂ«rthamĂ«n e Kubernetes pĂ«rmes patches, dhe pastaj ndalonin Kubernetes-in e tyre dhe e instalonin atĂ« nĂ« serverat e tyre. Por me kalimin e kohĂ«s, zhvilluesit e Kubernetes kuptuan qĂ« me qenĂ« problemi nuk mund tĂ« zgjidhet. NjerĂ«zit kanĂ« nevojĂ« pĂ«r njĂ« nga. Dhe nĂ« lĂ«shimin e Kubernetes v1.2.0 ajo u shfaq


Plugin Flexvolume: një nga në minimale

Zhvilluesit e Kubernetes krijuan pluginin FlexVolume, i cili ishte një lidhje logjike e variablëve dhe metodave për të punuar me operatorët Flexvolume të realizuar nga zhvillues të jashtëm.

Le të ndalojmë dhe të shqyrtojmë më në detaje se çfarë përfaqëson driveri FlexVolume. Ai është një skedar ekzekutiv (skedha binar, skript Python, skript Bash, etj.) që gjatë ekzekutimit merr si hyrje argumente të komandës dhe kthen një mesazh me fushat e njohura paraprakisht në formatin JSON. Argumenti i parë i komandës për konvensionin gjithmonë është metoda, ndërsa argumentet e tjera janë parametrat e saj.

Plugins për volumet e ruajtjes në Kubernetes: nga Flexvolume në CSI
Diagrami i lidhjes sĂ« CIFS Shares nĂ« OpenShift. PĂ«rdorimi i Drejtorit Flexvolume — pikĂ«risht nĂ« qendĂ«r

Grupi minimal i metodave duke dukur kështu:

flexvolume_driver mount # përgjegjës për bashkimin e volumit me pod-in
# Formati i mesazhit të kthyer:
{
  "status": "Sukses"/"Dështim"/"Nuk mbështetet",
  "message": "Përse është kthyer ky status",
}

flexvolume_driver unmount # përgjegjës për shkëputjen e volumit nga pod-i
# Formati i mesazhit të kthyer:
{
  "status": "Sukses"/"Dështim"/"Nuk mbështetet",
  "message": "Përse është kthyer ky status",
}

flexvolume_driver init # përgjegjës për inicializimin e plugin-it
# Formati i mesazhit të kthyer:
{
  "status": "Sukses"/"Dështim"/"Nuk mbështetet",
  "message": "Përse është kthyer ky status",
  // Përcakton nëse driver-i përdor metodat attach/detach
  "capabilities":{"attach": True/False}
}

Përdorimi i metodave attach dhe detach do të përcaktojë skenarin se si në të ardhmen kubelet do të veprojë kur thirret drejtuesi. Ekzistojnë gjithashtu metoda speciale expandvolume dhe expandfs, të cilat janë përgjegjëse për ndryshimin dinamik të madhësisë së volumit.

Si shembuj tĂ« ndryshimeve qĂ« shton metoda expandvolume, e sĂ« bashku me tĂ« — mundĂ«sinĂ« pĂ«r tĂ« realizuar ndryshimin e madhĂ«sisĂ« sĂ« volumit nĂ« kohĂ« reale, mund tĂ« shqyrtohet pull request-in tonĂ« nĂ« Rook Ceph Operator.

Ja një shembull i implementimit të drejtuesit Flexvolume për të punuar me NFS:

usage() {
    err "Përdorim i pahijshëm. Përdorimi: "
    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": "Sukses"}'
        exit 0
    fi

    mkdir -p ${MNTPATH} &> /dev/null

    mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Dështim", "message": "Dështoi të montojë ${NFS_SERVER}:${SHARE} në ${MNTPATH}"}"
        exit 1
    fi
    log '{"status": "Sukses"}'
    exit 0
}

unmount() {
    MNTPATH=$1
    if [ $(ismounted) -eq 0 ] ; then
        log '{"status": "Sukses"}'
        exit 0
    fi

    umount ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Dështim", "message": "Dështoi të çmontojë volum në ${MNTPATH}"}"
        exit 1
    fi

    log '{"status": "Sukses"}'
    exit 0
}

op=$1

if [ "$op" = "init" ]; then
    log '{"status": "Sukses", "kapacitetet": {"attach": false}}'
    exit 0
fi

if [ $# -lt 2 ]; then
    usage
fi

shift

case "$op" in
    mount)
        domount $*
        ;;
    unmount)
        unmount $*
        ;;
    *)
        log '{"status": "Jo e mbështetur"}'
        exit 0
esac

exit 1

Pra, pas përgatitjes së skedarit ekzekutues të vetë, duhet të ngarkohet drejtori në klasterin Kubernetes. Driveri duhet të ndodhet në çdo nyje të klashtër sipas rrugës së paracaktuar. Në mënyrë default, u zgjodh:

/usr/libexec/kubernetes/kubelet-plugins/volume/exec/ĐžĐŒŃ_ĐżĐŸŃŃ‚Đ°ĐČщоĐșĐ°_Ń…Ń€Đ°ĐœĐžĐ»ĐžŃ‰Đ°~ĐžĐŒŃ_ЮраĐčĐČДра/


 por kur përdoren distribuza të ndryshme Kubernetes (OpenShift, Rancher
) rruga mund të jetë e ndryshme.

Problemet e Flexvolume: si të hedhim përsëri?

Vendosja e driverit Flexvolume nĂ« nyjet e klashtĂ«r u tregua tĂ« ishte njĂ« detyrĂ« e ndĂ«rlikuar. Pasi tĂ« kryeni procedurĂ«n njĂ« herĂ« manualisht, Ă«shtĂ« e lehtĂ« tĂ« ballafaqoheni me njĂ« situatĂ« ku nĂ« klashtĂ«r shfaqen nyje tĂ« reja: pĂ«r shkak tĂ« shtimit tĂ« njĂ« nyje tĂ« re, shtimit automatik horizontal, ose — kjo Ă«shtĂ« mĂ« e frikshme — zĂ«vendĂ«simi i nyjĂ«s pĂ«r shkak tĂ« njĂ« defekti. NĂ« kĂ«tĂ« rast, puna me ruajtjen nĂ« kĂ«to nyje bĂ«het e pamundur, sa herĂ« qĂ« ju akoma nĂ« mĂ«nyrĂ« manuale nuk e shtoni driverin Flexvolume nĂ« to.

Zgjidhja e kĂ«tij problemi Ă«shtĂ« njĂ« nga primitive tĂ« Kubernetes — DaemonSet. Kur njĂ« nyje e re shfaqet nĂ« klashtĂ«r, automatikisht krijohet njĂ« pod nga DaemonSet’i ynĂ«, i cili lidhet me volumin lokal sipas rrugĂ«s pĂ«r gjetjen e driverĂ«ve Flexvolume. Me krijimin e suksesshĂ«m tĂ« pod, kopjon skedarĂ«t e nevojshĂ«m pĂ«r funksionimin e driverit nĂ« disk.

Ja një shembull i tillë DaemonSet për shpërndarjen e plugin Flexvolume:

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:


 dhe një shembull i skriptit Bash për shpërndarjen e driverit 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

ËshtĂ« e rĂ«ndĂ«sishme tĂ« mos harrohet se operacioni i kopjimit nuk Ă«shtĂ« atomar. Ka shumĂ« mundĂ«si qĂ« kubelet tĂ« fillojĂ« tĂ« pĂ«rdorĂ« driverin para se procesi i pĂ«rgatitjes sĂ« tij tĂ« pĂ«rfundojĂ«, duke shkaktuar njĂ« gabim nĂ« funksionimin e sistemit. Qasje e duhur do tĂ« ishte sĂ« pari tĂ« kopjoni skedarĂ«t e driverit me njĂ« emĂ«r tjetĂ«r, dhe pastaj tĂ« pĂ«rdorni njĂ« operacion atomar tĂ« riemĂ«rtimit.

Plugins për volumet e ruajtjes në Kubernetes: nga Flexvolume në CSI
Skema e punës me Ceph në operatorin Rook: driveri Flexvolume në skemë gjendet brenda agjentit Rook

Problemi tjetër gjatë përdorimit të driverëve Flexvolume është se për shumicën e ruajtjeve në nyjën e klasterit duhet të instalohet softi i nevojshëm për këtë (p.sh., paket ceph-common për Ceph). Fillimisht, plugu Flexvolume nuk ishte menduar për realizimin e sistemeve kaq të komplikuara.

Zgjidhja origjinale për këtë problem mund të shihet në realizimin e drejtuesit Flexvolume nga operatori Rook:

Drejtuesi vetë është realizuar si një klient RPC. IPC-soketi për komunikim ndodhet në të njëjtin katalog si drejtuesi vetë. Ne e mbajmë mend se për të kopjuar skedarët e drejtuesit do të ishte mirë të përdornim DaemonSet, që lidh një direktori me drejtuesin si volum. Pas kopjimit të skedarëve të nevojshëm të drejtuesit rook, ky pod nuk vdes, por lidhet me IPC-soketin përmes volumes së bashkangjitur si një server RPC të plotë. Paketa ceph-common tashmë është instaluar brenda konteinerit të pod-it. IPC-soketi ofron siguri që kubelet do të komunikojë pikërisht me atë pod që është në të njëjtin nod me të. E gjithë gjenialiteti është i thjeshtë!..

Mirupafshim, pluginat tanë të dashur... in-tree!

Zhvilluesit e Kubernetes zbuluan se numri i pluginave për magazinat brenda bërthamës është njëzet. Dhe cdo ndryshim në secilin prej tyre kalon përmes ciklit të plotë të lëshimit të Kubernetes.

Duket se pĂ«r tĂ« pĂ«rdorur njĂ« version tĂ« ri tĂ« pluginĂ«s pĂ«r magazinĂ«, Duhet tĂ« pĂ«rditĂ«soni tĂ« gjithĂ« klasterin. PĂ«rveç kĂ«saj, mund tĂ« habiteni se si versioni i ri i Kubernetes papritur mund tĂ« bĂ«het i papajtueshĂ«m me kernelin e pĂ«rdorur tĂ« Linux
 Prandaj, ju fshini lotĂ«t dhe duke gĂ«rryer dhĂ«mbĂ«t, rregulloni me drejtuesit dhe pĂ«rdoruesit kohĂ«n e pĂ«rditĂ«simit tĂ« kernelit tĂ« Linux dhe klasterit Kubernetes. Me mundĂ«sinĂ« e ndaljes sĂ« shĂ«rbimeve.

Situata është më se komike, a nuk e mendoni? Të gjithë komuniteti e kuptoi se qasja nuk funksionon. Me një vendim të fortë, zhvilluesit e Kubernetes shpallin se pluginat e rinj për të punuar me ruajtjet nuk do të pranohet më në kernel. Për më tepër, siç e dimë tashmë, në realizimin e plugin-it Flexvolume janë zbuluar disa mangësi...

Për të mbyllur një herë e mirë çështjen e ruajtjeve të qëndrueshme të dhënash, plugin-i i fundit i shtuar për volumin në Kubernetes - CSI. Alfa-versioni i tij, i quajtur më plotësisht si Out-of-Tree CSI Volume Plugins, u njoftua në lëshimin Kubernetes 1.9.

Container Storage Interface, ose spinning CSI 3000!

Së pari, do të doja të theksoj se CSI - është jo vetëm një plugin volumesh, por një të vërtetë standard për krijimin e komponenteve të përdoruesit për të punuar me ruajtjet e dhënave. Kishititet se sistemet e orkestrimit të kontejnerëve, si Kubernetes dhe Mesos, duhet të "mësojnë" të punojnë me komponentët që janë realizuar sipas këtij standardi. Dhe ja, Kubernetes tashmë e ka mësuar.

Si është struktura e plugin-it CSI në Kubernetes? Plugin-i CSI punon me shoferë të veçantë (shoferët CSI), të shkruar nga zhvillues të jashtëm. Shoferi CSI në Kubernetes minimalisht duhet të përbëhet nga dy komponentë (podë):

  • Controller — menaxhon depozitat e jashtme tĂ« qĂ«ndrueshme. Realizohet si njĂ« server gRPC, pĂ«r tĂ« cilin pĂ«rdoret objekti StatefulSet.
  • Node — pĂ«rgjigjet pĂ«r montimin e depozitave tĂ« qĂ«ndrueshme nĂ« nyjat e klasterit. Po ashtu realizohet si njĂ« server gRPC, por pĂ«r tĂ« pĂ«rdoret objekti DaemonSet.

Plugins për volumet e ruajtjes në Kubernetes: nga Flexvolume në CSI
Skema e punës së plugin-it CSI në Kubernetes

Për disa detaje të tjera sobre punën e CSI-së, mund të mësoni, për shembull, nga artikulli "Understanding the CSI», përkthimi i të cilit e publikova një vit më parë.

Përfitimet e këtij realizimi

  • PĂ«r gjĂ«rat bazike — pĂ«r shembull, pĂ«r regjistrimin e shoferit pĂ«r nyjĂ«n — zhvilluesit e Kubernetes realizuan njĂ« grup kontejnerĂ«sh. Nuk Ă«shtĂ« mĂ« e nevojshme tĂ« formoni vetĂ« pĂ«rgjigjen JSON me aftĂ«sitĂ«, siç bĂ«hej pĂ«r plugin-in Flexvolume.
  • NĂ« vend tĂ« "shkurtimit" tĂ« skedarĂ«ve ekzekutivĂ« nĂ« node, tani ne publikojmĂ« pod’ë nĂ« kluster. KĂ«tĂ« ne e presim fillimisht nga Kubernetes: tĂ« gjitha proceset ndodhin brenda kontejnerĂ«ve, tĂ« shpĂ«rndara me ndihmĂ«n e primitiveve tĂ« Kubernetes.
  • PĂ«r tĂ« realizuar shoferĂ«t e ndĂ«rlikuar, nuk Ă«shtĂ« mĂ« e nevojshme tĂ« zhvillohet njĂ« server RPC dhe njĂ« klient RPC. Klienti Ă«shtĂ« realizuar pĂ«r ne nga zhvilluesit e Kubernetes.
  • Kalim i argumenteve pĂ«r punĂ« sipas protokollit gRPC Ă«shtĂ« shumĂ« mĂ« i rehatshĂ«m, mĂ« fleksibĂ«l dhe mĂ« i sigurt se sa kalimi i tyre pĂ«rmes argumenteve tĂ« linjĂ«s sĂ« komandĂ«s. PĂ«r tĂ« kuptuar si tĂ« shtoni mbĂ«shtetje pĂ«r metrikat e pĂ«rdorimit tĂ« volumit nĂ« CSI duke shtuar njĂ« metodĂ« standardizuese gRPC, mund tĂ« referoheni nĂ« pull request-in tonĂ« pĂ«r shoferin vsphere-csi.
  • Komunikimi ndodh pĂ«rmes IPC-sockets, pĂ«r tĂ« mos u ngatĂ«rruar se nĂ« cilin pod kubelet dĂ«rgoi kĂ«rkesĂ«n.

A e shihni këtë listë si diçka njohur? Avantazhet e CSI janë zgjidhja e atyre problemeve, që nuk u morën parasysh gjatë zhvillimit të plugin-it Flexvolume.

PĂ«rfundimet

CSI si standardi i implementimit të shtojcave të përdoruesve për ndërveprimin me depozitat e të dhënave u pranuan shumë ngrohtas nga komuniteti. Për më tepër, falë avantazheve dhe universallitetit të tij, janë krijuar drivere CSI edhe për depozita si Ceph apo AWS EBS, shtojcat për të cilat u shtuan që në versionin më të parë të Kubernetes.

Në fillim të vitit 2019, shtojcat in-tree u shpallën të vjetra. Planifikohet të vazhdojë mbështetje për shtojcën Flexvolume, por nuk do të ketë zhvillim të funksionaliteteve të reja për të.

Ne kemi tashmë përvojë në përdorimin e ceph-csi, vsphere-csi dhe jemi të gatshëm të plotësojmë këtë listë! Deri tani, CSI po përballon detyrat e caktuara me sukses, dhe më pas do të shohim.

Mos harroni, gjithçka e re është një e vjetër e ri-të menduar mirë!

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster