Плагинҳои ҳаҷм барои нигаҳдории Kubernetes: аз Flexvolume то CSI

Плагинҳои ҳаҷм барои нигаҳдории Kubernetes: аз Flexvolume то CSI

Вақте ки Kubernetes ҳанӯз v1.0.0 буд, плагинҳои ҳаҷм вуҷуд доштанд. Онҳо барои пайваст кардани системаҳо ба Kubernetes барои нигоҳ доштани маълумоти доимии контейнер лозим буданд. Шумораи онҳо кам буд ва дар байни аввалинҳо провайдерҳои нигаҳдорӣ ба монанди GCE PD, Ceph, AWS EBS ва дигарон буданд.

Плагинҳо дар якҷоягӣ бо Kubernetes расонида шуданд, аз ин рӯ онҳо номи худро гирифтанд - дар дарахт. Аммо, барои бисёриҳо, маҷмӯи мавҷудаи чунин плагинҳо нокифоя баромад. Ҳунармандон бо истифода аз часпакҳо ба ядрои Kubernetes плагинҳои оддиро илова карданд ва пас аз он онҳо Kubernetes-и худро ҷамъ карда, дар серверҳои худ насб карданд. Аммо бо гузашти вақт, таҳиягарони Kubernetes инро дарк карданд моҳӣ масъаларо хал кардан мумкин нест. Одамон лозиманд пиёдагард. Ва дар барориши Kubernetes v1.2.0 он пайдо шуд...

Васлкунаки Flexvolume: ҳадди ақали асои моҳидорӣ

Таҳиягарони Kubernetes плагини FlexVolume-ро эҷод карданд, ки чаҳорчӯбаи мантиқии тағирёбандаҳо ва усулҳои кор бо драйверҳои Flexvolume буд, ки аз ҷониби таҳиягарони тарафи сеюм амалӣ карда мешавад.

Биёед таваққуф кунем ва бодиққат бубинем, ки драйвери FlexVolume чист. Ин як чизи муайян аст файли иҷрошаванда (файли дуӣ, скрипти Python, скрипти Bash ва ғ.), ки ҳангоми иҷро кардан далелҳои сатри фармонро ҳамчун вуруд қабул мекунад ва паёмро бо майдонҳои қаблан маълум дар формати JSON бармегардонад. Тибқи анъана, аргументи сатри фармони аввал ҳамеша усул аст ва далелҳои боқимонда параметрҳои он мебошанд.

Плагинҳои ҳаҷм барои нигаҳдории Kubernetes: аз Flexvolume то CSI
Диаграммаи пайвастшавӣ барои саҳмияҳои CIFS дар OpenShift. Ронандаи Flexvolume - рост дар марказ

Маҷмӯи ҳадди ақали усулҳо чунин мешуморам:

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

Истифодаи усулҳо attach и detach сенарияеро муайян мекунад, ки кубелет дар оянда ҳангоми занг задан ба ронанда амал мекунад. Усулҳои махсус низ мавҷуданд expandvolume и expandfs, ки барои ба таври динамикӣ тағир додани ҳаҷми ҳаҷм масъуланд.

Ҳамчун мисоли тағйироте, ки усул илова мекунад expandvolume, ва бо он қобилияти тағир додани андозаи ҳаҷмҳо дар вақти воқеӣ, шумо метавонед бо худ шинос шавед дархости ҷалби мо дар оператори Rook Ceph.

Ва ин аст мисоли татбиқи драйвери Flexvolume барои кор бо 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

Пас, пас аз омода кардани файли иҷрошавандаи воқеӣ, шумо бояд драйверро ба кластери Kubernetes бор кунед. Драйвер бояд дар ҳар як гиреҳи кластер мувофиқи роҳи пешакӣ муайяншуда ҷойгир бошад. Бо нобаёнӣ он интихоб карда шуд:

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

... аммо ҳангоми истифодаи тақсимоти гуногуни Kubernetes (OpenShift, Rancher...) роҳ метавонад гуногун бошад.

Мушкилоти Flexvolume: чӣ гуна асои моҳигириро дуруст партофтан мумкин аст?

Бор кардани драйвери Flexvolume ба гиреҳҳои кластерӣ як кори ғайриоддӣ буд. Пас аз анҷом додани амалиёт як маротиба, бо вазъияте дучор шудан осон аст, ки гиреҳҳои нав дар кластер пайдо мешаванд: аз ҳисоби илова кардани гиреҳи нав, миқёси уфуқии автоматӣ ё бадтараш - иваз кардани гиреҳ аз сабаби корношоямӣ. Дар ин ҳолат, кор бо анбор дар ин гиреҳҳо бояд анҷом дода шавад имконнопазир аст, то он даме, ки шумо ба таври дастӣ драйвери Flexvolume-ро ба онҳо илова кунед.

Ҳалли ин мушкилот яке аз ибтидоии Кубернетес буд - DaemonSet. Вақте ки гиреҳи нав дар кластер пайдо мешавад, он ба таври худкор як pod аз DaemonSet-и моро дар бар мегирад, ки ба он ҳаҷми маҳаллӣ дар роҳ барои дарёфти драйверҳои Flexvolume замима карда мешавад. Пас аз эҷоди бомуваффақият, pod файлҳои заруриро барои кор кардани драйвер ба диск нусхабардорӣ мекунад.

Ин аст мисоли чунин DaemonSet барои гузоштани плагини 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>

... ва намунаи скрипти Bash барои ҷойгиркунии драйвери 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

Муҳим аст, ки фаромӯш накунед, ки амалиёти нусхабардорӣ атом нест. Эҳтимоли зиёд вуҷуд дорад, ки kubelet пеш аз ба итмом расидани раванди таъминоти он драйверро истифода мебарад ва боиси садамаи система мегардад. Муносибати дуруст ин аст, ки аввал файлҳои драйверро бо номи дигар нусхабардорӣ кунед ва сипас амалиёти тағир додани номи атомиро истифода баред.

Плагинҳои ҳаҷм барои нигаҳдории Kubernetes: аз Flexvolume то CSI
Диаграммаи кор бо Ceph дар оператори Rook: драйвери Flexvolume дар диаграмма дар дохили агенти Rook ҷойгир аст

Мушкилоти навбатӣ ҳангоми истифодаи драйверҳои Flexvolume ин аст, ки барои аксари нигоҳдорӣ дар гиреҳи кластер барои ин программам зарурй гузошта шавад (масалан, бастаи ceph-умумӣ барои Ceph). Дар аввал, плагини Flexvolume барои татбиқи чунин системаҳои мураккаб тарҳрезӣ нашуда буд.

Ҳалли аслии ин мушкилотро дар татбиқи драйвери Flexvolume оператори Rook дидан мумкин аст:

Худи ронанда ҳамчун муштарии RPC тарҳрезӣ шудааст. Васлаки IPC барои иртибот дар ҳамон феҳристи худи драйвер ҷойгир аст. Мо дар хотир дорем, ки барои нусхабардории файлҳои драйвер истифода бурдани DaemonSet хуб мебуд, ки директорияро бо драйвер ҳамчун ҳаҷм мепайвандад. Пас аз нусхабардории файлҳои драйвери лозимии rook, ин подк мемирад, балки ба васлаки IPC тавассути ҳаҷми замимашуда ҳамчун сервери мукаммали RPC пайваст мешавад. Бастаи ceph-умум аллакай дар дохили контейнер насб карда шудааст. Васлаки IPC кафолат медиҳад, ки кубелет маҳз бо подкале, ки дар ҳамон гиреҳ ҷойгир аст, муошират мекунад. Ҳама чиз оддӣ аст!..

Дуруд, плагинҳои дӯстдоштаи мо... дар дарахт!

Таҳиягарони Kubernetes кашф карданд, ки шумораи плагинҳо барои нигоҳдорӣ дар ядро ​​​​бист аст. Ва тағирот дар ҳар яки онҳо, ин ё он роҳ, аз давраи пурраи барориши Kubernetes мегузарад.

Маълум мешавад, ки барои истифодаи версияи нави плагини нигаҳдорӣ, шумо бояд тамоми кластерро навсозӣ кунед. Илова бар ин, шумо шояд ҳайрон шавед, ки версияи нави Kubernetes ба таври ногаҳонӣ бо ядрои Linux, ки шумо истифода мебаред, номувофиқ мешавад... Ҳамин тавр, шумо ашкҳои худро пок мекунед ва дандонҳои худро ғиҷир зада, бо роҳбарият ва корбарони худ вақт ҷудо мекунед. ядрои Linux ва кластери Kubernetes -ро навсозӣ кунед. Бо бекористии имконпазир дар расонидани хидматҳо.

Вазъият беш аз хандаовар аст, оё шумо фикр намекунед? Ба тамоми ахли чамъият маълум шуд, ки ин усул самара намебахшад. Бо тасмими ирода, таҳиягарони Kubernetes эълон мекунанд, ки плагинҳои нав барои кор бо нигаҳдорӣ дигар ба ядро ​​​​қабул карда намешаванд. Илова бар ин, тавре ки мо аллакай медонем, дар татбиқи плагини Flexvolume як қатор камбудиҳо ошкор карда шуданд...

Васлкунаки охирини иловашуда барои ҳаҷмҳо дар Kubernetes, CSI, даъват карда шуд, ки масъаларо бо нигоҳдории доимии додаҳо як бор ва барои ҳама пӯшонад. Дар нашрия версияи алфа, ки пурратар ҳамчун плагинҳои берун аз дарахт номи CSI Volume эълон шудааст Кубернетҳо 1.9.

Интерфейси нигаҳдории контейнер ё асои ресандагии CSI 3000!

Пеш аз ҳама, ман мехоҳам қайд кунам, ки CSI на танҳо як плагини ҳаҷмӣ, балки воқеӣ аст стандартӣ дар бораи сохтани ҷузъҳои фармоишӣ барои кор бо анборҳои додаҳо. Системаҳои оркестри контейнерӣ, ба монанди Кубернетес ва Месос бояд чӣ гуна кор карданро бо ҷузъҳои мувофиқи ин стандарт амалӣ карданро "омӯзанд". Ва ҳоло ман аллакай Кубернетесро омӯхтам.

Сохтори плагини CSI дар Kubernetes чист? Васлкунаки CSI бо драйверҳои махсус кор мекунад (Ронандагон CSI) аз ҷониби таҳиягарони тарафи сеюм навишта шудааст. Драйвери CSI дар Кубернетес бояд ҳадди аққал аз ду ҷузъ (подҳо) иборат бошад:

  • нозир — захирахои доимии беруниро идора мекунад. Он ҳамчун сервери gRPC амалӣ карда мешавад, ки барои он ибтидоӣ истифода мешавад StatefulSet.
  • Нод — барои насб кардани нигоҳдории доимӣ ба гиреҳҳои кластер масъул аст. Он инчунин ҳамчун сервери gRPC амалӣ карда мешавад, аммо он ибтидоиро истифода мебарад DaemonSet.

Плагинҳои ҳаҷм барои нигаҳдории Kubernetes: аз Flexvolume то CSI
Чӣ тавр плагини CSI дар Kubernetes кор мекунад

Шумо метавонед дар бораи баъзе ҷузъиёти дигари кори CSI маълумот гиред, масалан, аз мақолаи "Фаҳмидани C.S.I.», тарҷумаи он як сол пеш нашр карда будем.

Афзалиятҳои чунин татбиқ

  • Барои чизҳои асосӣ ба монанди сабти драйвер барои гиреҳ, таҳиягарони Kubernetes як қатор контейнерҳоро амалӣ карданд. Ба шумо дигар лозим нест, ки посухи JSON-ро бо қобилиятҳо худатон тавлид кунед, тавре ки барои плагини Flexvolume анҷом дода шудааст.
  • Ба ҷои он ки файлҳои иҷрошаванда ба гиреҳҳо "лағзиш" кунем, мо ҳоло подкҳоро ба кластер бор мекунем. Ин аст он чизе ки мо дар аввал аз Кубернетес интизорем: ҳама равандҳо дар дохили контейнерҳое рух медиҳанд, ки бо истифода аз ибтидоии Kubernetes ҷойгир карда шудаанд.
  • Барои татбиқи драйверҳои мураккаб ба шумо дигар лозим нест, ки сервери RPC ва муштарии RPC таҳия кунед. Муштариро барои мо таҳиягарони Kubernetes амалӣ кардаанд.
  • Гузаронидани аргументҳо барои кор дар протоколи gRPC назар ба интиқоли онҳо тавассути аргументҳои сатри фармон хеле қулай, чандир ва боэътимодтар аст. Барои фаҳмидани он ки чӣ гуна дастгирӣ барои метрикаи истифодаи ҳаҷм ба CSI тавассути илова кардани усули стандартишудаи gRPC, шумо метавонед хонед: дархости ҷалби мо барои ронандаи vsphere-csi.
  • Муошират тавассути розеткаҳои IPC сурат мегирад, то ошуфта нашавед, ки оё кубелет дархостро ба поди дуруст фиристодааст.

Оё ин рӯйхат ба шумо чизеро хотиррасон мекунад? Бартариҳои CSI инҳоянд ҳалли ҳамон мушкилот, ки ҳангоми таҳияи плагини Flexvolume ба назар гирифта нашудаанд.

натиҷаҳои

CSI ҳамчун стандарт барои татбиқи плагинҳои фармоишӣ барои ҳамкорӣ бо анборҳои додаҳо аз ҷониби ҷомеа хеле гарм қабул карда шуд. Гузашта аз ин, аз сабаби афзалиятҳо ва гуногунҷанбаи худ, драйверҳои CSI ҳатто барои системаҳои нигоҳдорӣ ба монанди Ceph ё AWS EBS сохта шудаанд, плагинҳо барои кор бо онҳо дар версияи аввалини Kubernetes илова карда шудаанд.

Дар аввали соли 2019, плагинҳои дохили дарахт кухнашуда эълон карда шудаанд. Мо нақша дорем дастгирии плагини Flexvolume-ро идома диҳем, аммо барои он функсияҳои нав таҳия нахоҳем кард.

Мо худамон аллакай таҷрибаи истифодаи ceph-csi, vsphere-csi дорем ва омодаем ба ин рӯйхат илова кунем! То ба ҳол, CSI вазифаҳои ба он гузошташударо бо як таркиш иҷро мекунад, аммо мо интизор мешавем ва мебинем.

Фаромӯш накунед, ки ҳама чизи нав аз нав дида баромадани хуби кӯҳна аст!

PS

Инчунин дар блоги мо хонед:

Манбаъ: will.com

Илова Эзоҳ