🥇 Ategion cyfrol i'w storio yn Kubernetes: o Flexvolume i CSI

Yn ôl pan oedd Kubernetes yn dal i fod yn v1.0.0, roedd ategion cyfaint. Roedd eu hangen i gysylltu systemau â Kubernetes ar gyfer storio data cynhwysydd parhaus (parhaol). Roedd eu nifer yn fach, ac ymhlith y cyntaf roedd darparwyr storio o'r fath fel TAG PD, Ceph, AWS EBS ac eraill.

Cyflwynwyd yr ategion ynghyd â Kubernetes, a dyna pam y cawsant eu henw - yn y goeden. Fodd bynnag, i lawer, roedd y set bresennol o ategion o'r fath yn annigonol. Ychwanegodd crefftwyr ategion syml at graidd Kubernetes gan ddefnyddio clytiau, ac ar ôl hynny fe wnaethant ymgynnull eu Kubernetes eu hunain a'i osod ar eu gweinyddwyr. Ond dros amser, sylweddolodd datblygwyr Kubernetes hynny pysgod ni ellir datrys y broblem. Mae angen pobl gwialen bysgota. Ac wrth ryddhau Kubernetes v1.2.0 roedd yn ymddangos ...

Ategyn Flexvolume: gwialen bysgota lleiaf posibl

Creodd datblygwyr Kubernetes yr ategyn FlexVolume, a oedd yn fframwaith rhesymegol o newidynnau a dulliau ar gyfer gweithio gyda gyrwyr Flexvolume a weithredwyd gan ddatblygwyr trydydd parti.

Gadewch i ni stopio ac edrych yn agosach ar beth yw'r gyrrwr FlexVolume. Mae hyn yn sicr ffeil gweithredadwy (ffeil deuaidd, sgript Python, sgript Bash, ac ati), sydd, pan gaiff ei weithredu, yn cymryd dadleuon llinell orchymyn fel mewnbwn ac yn dychwelyd neges gyda meysydd hysbys ymlaen llaw mewn fformat JSON. Yn ôl confensiwn, mae dadl y llinell orchymyn gyntaf bob amser yn ddull, a'r dadleuon sy'n weddill yw ei baramedrau.

Diagram cysylltu ar gyfer CIFS Shares yn OpenShift. Gyrrwr Flexvolume - Reit yn y Ganolfan

Set leiaf o ddulliau yn edrych fel hyn:

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

Defnyddio Dulliau attach и detach yn diffinio'r senario y bydd y kubelet yn gweithredu ynddo yn y dyfodol wrth ffonio'r gyrrwr. Mae yna hefyd ddulliau arbennig expandvolume и expandfs, sy'n gyfrifol am newid maint y gyfrol yn ddeinamig.

Fel enghraifft o'r newidiadau y mae'r dull yn eu hychwanegu expandvolume, a chyda hynny y gallu i newid maint cyfeintiau mewn amser real, gallwch ymgyfarwyddo â ein cais tynnu yn Rook Ceph Operator.

A dyma enghraifft o weithrediad y gyrrwr Flexvolume ar gyfer gweithio gyda 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

Felly, ar ôl paratoi'r ffeil weithredadwy gwirioneddol, mae angen i chi wneud hynny uwchlwythwch y gyrrwr i glwstwr Kubernetes. Rhaid lleoli'r gyrrwr ar bob nod clwstwr yn ôl llwybr a bennwyd ymlaen llaw. Yn ddiofyn fe'i dewiswyd:

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

... ond wrth ddefnyddio gwahanol ddosbarthiadau Kubernetes (OpenShift, Rancher...) gall y llwybr fod yn wahanol.

Problemau cyfaint hyblyg: sut i gastio gwialen bysgota yn gywir?

Roedd uwchlwytho'r gyrrwr Flexvolume i nodau clwstwr yn dasg nad oedd yn ddibwys. Ar ôl gwneud y llawdriniaeth â llaw unwaith, mae'n hawdd dod ar draws sefyllfa lle mae nodau newydd yn ymddangos yn y clwstwr: oherwydd ychwanegu nod newydd, graddio llorweddol awtomatig, neu - yr hyn sy'n waeth - amnewid nod oherwydd camweithio. Yn yr achos hwn, dylid gweithio gyda storio ar y nodau hyn yn amhosib, nes eich bod yn dal i ychwanegu'r gyrrwr Flexvolume atynt â llaw.

Yr ateb i'r broblem hon oedd un o'r cyntefig Kubernetes - DaemonSet. Pan fydd nod newydd yn ymddangos yn y clwstwr, mae'n cynnwys pod yn awtomatig o'n DaemonSet, y mae cyfrol leol ynghlwm wrtho ar hyd y llwybr i ddod o hyd i yrwyr Flexvolume. Ar ôl ei greu'n llwyddiannus, mae'r pod yn copïo'r ffeiliau angenrheidiol i'r gyrrwr weithio i ddisg.

Dyma enghraifft o DaemonSet o'r fath ar gyfer gosod ategyn 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>

... ac enghraifft o sgript Bash ar gyfer gosod y gyrrwr Flexvolume allan:

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

Mae'n bwysig peidio ag anghofio bod y llawdriniaeth copi nid yw'n atomig. Mae siawns uchel y bydd y kubelet yn dechrau defnyddio'r gyrrwr cyn i'w broses ddarparu ddod i ben, gan achosi i'r system chwalu. Y dull cywir yw copïo'r ffeiliau gyrrwr o dan enw gwahanol yn gyntaf, ac yna defnyddio gweithrediad ailenwi atomig.

Diagram o weithio gyda Ceph yn y gweithredwr Rook: mae'r gyrrwr Flexvolume yn y diagram wedi'i leoli y tu mewn i'r asiant Rook

Y broblem nesaf wrth ddefnyddio gyrwyr Flexvolume yw bod ar gyfer y rhan fwyaf o storio ar nod clwstwr rhaid gosod y meddalwedd angenrheidiol ar gyfer hyn (er enghraifft, y pecyn ceph-common ar gyfer Ceph). I ddechrau, nid oedd yr ategyn Flexvolume wedi'i gynllunio i weithredu systemau mor gymhleth.

Gellir gweld ateb gwreiddiol i'r broblem hon yng ngweithrediad gyrrwr Flexvolume y gweithredwr Rook:

Mae'r gyrrwr ei hun wedi'i gynllunio fel cleient RPC. Mae'r soced IPC ar gyfer cyfathrebu wedi'i leoli yn yr un cyfeiriadur â'r gyrrwr ei hun. Cofiwn y byddai'n dda defnyddio DaemonSet, sy'n cysylltu'r cyfeiriadur â'r gyrrwr fel cyfrol, i gopïo ffeiliau gyrrwr. Ar ôl copïo'r ffeiliau gyrrwr rook angenrheidiol, nid yw'r pod hwn yn marw, ond mae'n cysylltu â'r soced IPC trwy'r gyfrol atodedig fel gweinydd RPC llawn. Mae'r pecyn ceph-common eisoes wedi'i osod y tu mewn i'r cynhwysydd pod. Mae'r soced IPC yn sicrhau y bydd y kubelet yn cyfathrebu â'r union god sydd wedi'i leoli ar yr un nod. Mae popeth dyfeisgar yn syml! ..

Hwyl fawr, ein cariadus... ategion yn y goeden!

Darganfu datblygwyr Kubernetes mai ugain yw nifer yr ategion i'w storio yn y craidd. Ac mae newid ym mhob un ohonynt, un ffordd neu'r llall, yn mynd trwy gylch rhyddhau llawn Kubernetes.

Mae'n troi allan, i ddefnyddio'r fersiwn newydd o'r ategyn storio, mae angen i chi ddiweddaru'r clwstwr cyfan. Yn ogystal â hyn, efallai y byddwch chi'n synnu y bydd y fersiwn newydd o Kubernetes yn sydyn yn dod yn anghydnaws â'r cnewyllyn Linux rydych chi'n ei ddefnyddio ... Felly rydych chi'n sychu'ch dagrau ac, yn graeanu'ch dannedd, yn cydlynu â'ch rheolwyr a'ch defnyddwyr yr amser i diweddaru cnewyllyn Linux a chlwstwr Kubernetes. Gydag amser segur posibl wrth ddarparu gwasanaethau.

Mae'r sefyllfa yn fwy na doniol, onid ydych chi'n meddwl? Daeth yn amlwg i'r gymuned gyfan nad oedd y dull yn gweithio. Trwy benderfyniad bwriadol, mae datblygwyr Kubernetes yn cyhoeddi na fydd ategion newydd ar gyfer gweithio gyda storfa yn cael eu derbyn i'r cnewyllyn mwyach. Yn ogystal, fel y gwyddom eisoes, nodwyd nifer o ddiffygion wrth weithredu'r ategyn Flexvolume ...

Galwyd ar yr ategyn ychwanegol diweddaraf ar gyfer cyfeintiau yn Kubernetes, CSI, i gau'r mater gyda storio data parhaus unwaith ac am byth. Cyhoeddwyd ei fersiwn alffa, y cyfeirir ato'n llawnach fel Ategion Cyfrol CSI Out-of-Tree, yn y datganiad Ciwbernetau 1.9.

Rhyngwyneb Storio Cynhwysydd, neu wialen nyddu CSI 3000!

Yn gyntaf oll, hoffwn nodi nad ategyn cyfaint yn unig yw CSI, ond go iawn safonol ar greu cydrannau arfer ar gyfer gweithio gyda warysau data. Roedd systemau cerddorfa cynwysyddion fel Kubernetes a Mesos i fod i “ddysgu” sut i weithio gyda chydrannau a weithredwyd yn unol â'r safon hon. Ac yn awr yr wyf eisoes wedi dysgu Kubernetes.

Beth yw strwythur yr ategyn CSI yn Kubernetes? Mae'r ategyn CSI yn gweithio gyda gyrwyr arbennig (Gyrwyr CSI) a ysgrifennwyd gan ddatblygwyr trydydd parti. Ni ddylai gyrrwr CSI yn Kubernetes gynnwys dwy gydran (pods):

Rheolwr — yn rheoli storfeydd parhaus allanol. Fe'i gweithredir fel gweinydd gRPC, y defnyddir y cyntefig ar ei gyfer StatefulSet.
Nôd — yn gyfrifol am osod storfa barhaus ar nodau clwstwr. Fe'i gweithredir hefyd fel gweinydd gRPC, ond mae'n defnyddio'r cyntefig DaemonSet.

Sut mae'r ategyn CSI yn gweithio yn Kubernetes

Gallwch ddysgu am rai manylion eraill am waith CSI, er enghraifft, o'r erthygl “Deall y C.S.I.' cyfieithiad o ba un cyhoeddasom flwyddyn yn ôl.

Manteision gweithrediad o'r fath

Ar gyfer pethau sylfaenol fel cofrestru gyrrwr ar gyfer nod, gweithredodd datblygwyr Kubernetes set o gynwysyddion. Nid oes angen i chi gynhyrchu ymateb JSON gyda galluoedd eich hun mwyach, fel y gwnaed ar gyfer yr ategyn Flexvolume.
Yn lle “llithro” ffeiliau gweithredadwy ar nodau, rydyn ni nawr yn uwchlwytho codennau i'r clwstwr. Dyma'r hyn yr ydym yn ei ddisgwyl i ddechrau gan Kubernetes: mae'r holl brosesau'n digwydd y tu mewn i gynwysyddion a ddefnyddir gan ddefnyddio primitives Kubernetes.
Nid oes angen i chi bellach ddatblygu gweinydd RPC a chleient RPC i weithredu gyrwyr cymhleth. Gweithredwyd y cleient i ni gan ddatblygwyr Kubernetes.
Mae trosglwyddo dadleuon i weithio dros y protocol gRPC yn llawer mwy cyfleus, hyblyg a dibynadwy na'u pasio trwy ddadleuon llinell orchymyn. I ddeall sut i ychwanegu cefnogaeth ar gyfer metrigau defnydd cyfaint i CSI trwy ychwanegu dull gRPC safonol, gallwch ddarllen: ein cais tynnu ar gyfer gyrrwr vsphere-csi.
Mae cyfathrebu'n digwydd trwy socedi IPC, er mwyn peidio â drysu a anfonodd y kubelet y cais i'r pod cywir.

A yw'r rhestr hon yn eich atgoffa o unrhyw beth? Mae manteision CSI yn datrys yr un problemau hynny, na chawsant eu hystyried wrth ddatblygu'r ategyn Flexvolume.

Canfyddiadau

Cafodd CSI fel safon ar gyfer gweithredu ategion personol ar gyfer rhyngweithio â warysau data groeso cynnes iawn gan y gymuned. Ar ben hynny, oherwydd eu manteision a'u hyblygrwydd, mae gyrwyr CSI yn cael eu creu hyd yn oed ar gyfer systemau storio fel Ceph neu AWS EBS, ategion ar gyfer gweithio gyda nhw a ychwanegwyd yn fersiwn gyntaf Kubernetes.

Ar ddechrau 2019, ategion yn y goeden wedi eu datgan yn ddarfodedig. Rydym yn bwriadu parhau i gefnogi'r ategyn Flexvolume, ond ni fyddwn yn datblygu swyddogaethau newydd ar ei gyfer.

Mae gennym ni ein hunain eisoes brofiad o ddefnyddio ceph-csi, vsphere-csi ac yn barod i ychwanegu at y rhestr hon! Hyd yn hyn, mae CSI yn ymdopi â'r tasgau a neilltuwyd iddo gyda chlec, ond byddwn yn aros i weld.

Peidiwch ag anghofio bod popeth newydd yn ailfeddwl yn dda o'r hen!

PS

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Ategion cyfaint ar gyfer storio Kubernetes: o Flexvolume i CSI