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 форматында алдын ала белгилүү талаалары бар билдирүүнү кайтарат. Шарт боюнча, биринчи буйрук сабынын аргументи ар дайым метод болуп саналат, ал эми калган аргументтер анын параметрлери болуп саналат.

OpenShift ичиндеги CIFS үлүштөрү үчүн туташуу диаграммасы. Flexvolume Driver - туура борбордо

Методдордун минималдуу топтому Ал мындай болот:

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 операторунда.

Бул жерде NFS менен иштөө үчүн Flexvolume драйверин ишке ашыруунун мисалы:

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 драйверин кол менен кошконго чейин.

Бул маселени чечүү Kubernetes примитивдердин бири болгон - DaemonSet. Кластерде жаңы түйүн пайда болгондо, ал автоматтык түрдө Flexvolume драйверлерин табуу үчүн жол боюндагы жергиликтүү көлөм тиркелип турган DaemonSet'ибиздин капчыгын камтыйт. Ийгиликтүү түзүлгөндөн кийин, поддон драйвердин дискке иштеши үчүн керектүү файлдарды көчүрөт.

Flexvolume плагинин түзүү үчүн мындай DaemonSetтин мисалы:

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>

... жана Flexvolume драйверин жайгаштыруу үчүн Bash скриптинин мисалы:

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

Бул көчүрүү операция экенин унутпашыбыз керек атомдук эмес. Кубелет драйверди камсыздоо процесси аяктаганга чейин колдоно башташы ыктымал, бул системанын бузулушуна алып келет. Туура ыкма - адегенде драйвер файлдарын башка ат менен көчүрүү, андан кийин атомдук атын өзгөртүү операциясын колдонуу.

Rook операторундагы Ceph менен иштөө диаграммасы: диаграммадагы Flexvolume драйвери Rook агентинин ичинде жайгашкан

Flexvolume драйверлерин колдонуудагы кийинки көйгөй кластердик түйүндөрдөгү көпчүлүк сактоо үчүн бул үчүн керектүү программа орнотулушу керек (мисалы, Ceph үчүн ceph-жалпы пакет). Башында, Flexvolume плагини мындай татаал системаларды ишке ашыруу үчүн иштелип чыккан эмес.

Бул маселенин оригиналдуу чечилишин Rook операторунун Flexvolume драйверин ишке ашыруудан көрүүгө болот:

Айдоочу өзү RPC кардары катары иштелип чыккан. Байланыш үчүн IPC розетка драйвердин өзү сыяктуу каталогдо жайгашкан. Драйвер файлдарын көчүрүү үчүн каталогду драйвер менен том катары байланыштырган DaemonSet колдонуу жакшы болорун эсибизде. Керектүү Rook драйвер файлдарын көчүргөндөн кийин, бул подколь өлбөйт, бирок толук кандуу RPC сервери катары тиркелген том аркылуу IPC розеткасына туташат. Ceph-жалпы топтому мурунтан эле поддон контейнеринин ичине орнотулган. IPC розеткасы кубелеттин ошол эле түйүндө жайгашкан так менен байланышышын камсыздайт. Бардык гениалдуу жөнөкөй!..

Кош бол, биздин мээримдүү... дарак ичиндеги плагиндер!

Kubernetes иштеп чыгуучулары өзөктө сактоо үчүн плагиндердин саны жыйырма экенин аныкташкан. Жана алардын ар бириндеги өзгөрүү, тигил же бул жол менен, Kubernetes релизинин толук циклинен өтөт.

Сактагыч плагиндин жаңы версиясын колдонуу үчүн, бүт кластерди жаңыртышыңыз керек. Мындан тышкары, сиз күтүлбөгөн жерден Kubernetesтин жаңы версиясы сиз колдонуп жаткан Linux ядросу менен шайкеш келбей калганына таң калышыңыз мүмкүн... Ошентип, көз жашыңызды аарчып, тишиңизди кычыратып, жетекчилик жана колдонуучулар менен макулдашып, Linux ядросун жана Kubernetes кластерин жаңыртыңыз. Кызмат көрсөтүүдө мүмкүн болгон токтоп калуу менен.

Кырдаал күлкүлүү эмес, сиз ойлобойсузбу? Бул ыкма иштебей жаткандыгы буткул коомчулукка ачык-айкын болду. Атайылап чечим менен, Kubernetes иштеп чыгуучулары сактагыч менен иштөө үчүн жаңы плагиндер мындан ары ядродо кабыл алынбай турганын жарыялашат. Мындан тышкары, биз билгендей, Flexvolume плагинин ишке ашырууда бир катар кемчиликтер аныкталган...

Kubernetes, CSI көлөмдөрү үчүн эң акыркы кошулган плагин, маалыматты туруктуу сактоо менен маселени биротоло жабууга чакырылган. Анын альфа версиясы, толугураак Out-of-tree CSI Volume Plugins деп аталат, релизде жарыяланды Кубернеттер 1.9.

Контейнерди сактоо интерфейси же CSI 3000 айланма таякчасы!

Биринчиден, мен CSI жөн гана көлөмдүү плагин эмес, реалдуу экенин белгилегим келет -стандартты, маалымат кампалары менен иштөө үчүн ыңгайлаштырылган компоненттерди түзүү боюнча. Kubernetes жана Mesos сыяктуу контейнердик оркестрдик системалар ушул стандартка ылайык ишке ашырылган компоненттер менен иштөөнү "үйрөнүшү" керек болчу. Эми мен Kubernetes үйрөндүм.

Kubernetesтеги CSI плагининин структурасы кандай? CSI плагини атайын драйверлер менен иштейт (CSI айдоочулары) үчүнчү тарап иштеп чыгуучулар тарабынан жазылган. Kubernetesтеги CSI драйвери эң аз эки компоненттен (поддор) турушу керек:

• контролеру — тышкы туруктуу сактагычтарды башкарат. Ал gRPC сервери катары ишке ашырылат, ал үчүн примитив колдонулат StatefulSet.
• Node — кластердик түйүндөргө туруктуу сактагычты орнотуу үчүн жооптуу. Ал ошондой эле gRPC сервери катары ишке ашырылат, бирок ал примитивдүү колдонот DaemonSet.

CSI плагини Kubernetesте кантип иштейт

Сиз CSI ишинин башка деталдары тууралуу биле аласыз, мисалы, макаладан "C.S.I түшүнүү.«, анын котормосу бир жыл мурун жарыялаганбыз.

Мындай ишке ашыруунун артыкчылыктары

• Түйүн үчүн драйверди каттоо сыяктуу негизги нерселер үчүн Kubernetes иштеп чыгуучулары контейнерлердин топтомун ишке ашырышкан. Flexvolume плагини үчүн жасалгандай, мүмкүнчүлүктөрү бар JSON жообун өзүңүз жаратуунун кереги жок.
• Аткарылуучу файлдарды түйүндөргө "жылдыруунун" ордуна, биз азыр подкасттарды кластерге жүктөйбүз. Башында биз Кубернетестен күткөн нерсебиз: бардык процесстер Kubernetes примитивдери менен орнотулган контейнерлердин ичинде жүрөт.
• Мындан ары татаал драйверлерди ишке ашыруу үчүн RPC серверин жана RPC кардарын иштеп чыгуунун кереги жок. Кардар биз үчүн Kubernetes иштеп чыгуучулары тарабынан ишке ашырылган.
• gRPC протоколунун үстүнөн иштөө үчүн аргументтерди өткөрүү аларды буйрук сабынын аргументтери аркылуу өткөрүүгө караганда алда канча ыңгайлуу, ийкемдүү жана ишенимдүү. Стандартташтырылган gRPC ыкмасын кошуу менен CSIге көлөмдү колдонуу көрсөткүчтөрүн колдоону кантип кошууну түшүнүү үчүн төмөнкүнү окуй аласыз: биздин тартуу өтүнүчүбүз vsphere-csi драйвери үчүн.
• Байланыш IPC розеткалары аркылуу ишке ашат, ошондуктан kubelet суроо-талапты туура подкетке жөнөткөнбү деп чаташтырбоо үчүн.

Бул тизме сизге бир нерсени эске салабы? CSI артыкчылыктары болуп саналат ошол эле маселелерди чечүү, алар Flexvolume плагинин иштеп чыгууда эске алынган эмес.

табылгалары

Маалымат кампалары менен өз ара аракеттенүү үчүн ыңгайлаштырылган плагиндерди ишке ашыруу үчүн стандарт катары CSI коомчулук тарабынан абдан жылуу кабыл алынды. Мындан тышкары, алардын артыкчылыктары жана ар тараптуулугу үчүн, CSI драйверлери Ceph же AWS EBS сыяктуу сактоо тутумдары үчүн да түзүлгөн, алар менен иштөө үчүн плагиндер Kubernetesтин эң биринчи версиясында кошулган.

2019-жылдын башында дарак ичиндеги плагиндер эскирген деп жарыяланды. Биз Flexvolume плагинин колдоону улантууну пландап жатабыз, бирок ал үчүн жаңы функцияларды иштеп чыкпайбыз.

Бизде ceph-csi, vsphere-csi колдонуу тажрыйбасы бар жана бул тизмеге кошууга даярбыз! Азырынча, CSI ага жүктөлгөн милдеттерди бир жарылуу менен аткарып жатат, бирок биз күтө жана көрөбүз.

Бардык жаңы нерсе эскини жакшылап ойлонуу экенин унутпаңыз!

PS

Биздин блогдон дагы окуңуз:

• «Контейнерди сактоо интерфейсин түшүнөбүз (Кубернетеде гана эмес)";
• «Рукпу же жокпу - бул суроо";
• «Kubernetes'те көлөмдүү сүрөттөрдүн альфа версиясын киргизүү«.

Source: www.habr.com