Kubernetes saqlash uchun hajmli plaginlar: Flexvolume dan CSIgacha

Kubernetes hali v1.0.0 bo'lganida, ovoz balandligi plaginlari mavjud edi. Ular doimiy (doimiy) konteyner ma'lumotlarini saqlash uchun tizimlarni Kubernetesga ulash uchun kerak edi. Ularning soni kichik edi va birinchilar qatorida GCE PD, Ceph, AWS EBS va boshqalar kabi saqlash provayderlari bor edi.

Plaginlar Kubernetes bilan birga yetkazib berildi, shuning uchun ular o'z nomlarini oldilar - daraxt ichida. Biroq, ko'pchilik uchun bunday plaginlarning mavjud to'plami etarli emas edi. Hunarmandlar yamoqlar yordamida Kubernetes yadrosiga oddiy plaginlarni qo'shdilar, shundan so'ng ular o'zlarining Kuberneteslarini yig'dilar va uni serverlariga o'rnatdilar. Ammo vaqt o'tishi bilan Kubernetes ishlab chiquvchilari buni tushunishdi baliq muammoni hal qilib bo'lmaydi. Odamlarga kerak novda. Va Kubernetes v1.2.0 versiyasida u paydo bo'ldi ...

Flexvolume plagini: minimal qarmoq

Kubernetes ishlab chiquvchilari FlexVolume plaginini yaratdilar, bu o'zgaruvchilar va uchinchi tomon ishlab chiquvchilari tomonidan amalga oshirilgan Flexvolume drayverlari bilan ishlash usullarining mantiqiy asosi edi.

Keling, to'xtab, FlexVolume drayveri nima ekanligini batafsil ko'rib chiqaylik. Bu aniq bajariladigan fayl (ikkilik fayl, Python skripti, Bash skripti va boshqalar), ular bajarilganda buyruq qatori argumentlarini kirish sifatida qabul qiladi va JSON formatidagi oldindan ma'lum maydonlar bilan xabarni qaytaradi. An'anaga ko'ra, birinchi buyruq qatori argumenti har doim usul bo'lib, qolgan argumentlar uning parametrlari hisoblanadi.

OpenShift-dagi CIFS Shares uchun ulanish diagrammasi. Flexvolume drayveri - markazda

Minimal usullar to'plami quyidagicha ko'rinadi:

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

Usullaridan foydalanish attach и detach haydovchini chaqirganda kubelet kelajakda harakat qiladigan stsenariyni belgilaydi. Bundan tashqari, maxsus usullar mavjud expandvolume и expandfs, ular ovoz balandligini dinamik ravishda o'zgartirish uchun javobgardir.

Usul qo'shadigan o'zgarishlarga misol sifatida expandvolume, va u bilan real vaqtda hajmlarni o'zgartirish qobiliyati bilan siz tanishishingiz mumkin bizning tortishish talabimiz Rook Ceph operatorida.

Mana NFS bilan ishlash uchun Flexvolume drayverini amalga oshirishga misol:

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

Shunday qilib, haqiqiy bajariladigan faylni tayyorlaganingizdan so'ng, kerak drayverni Kubernetes klasteriga yuklang. Haydovchi oldindan belgilangan yo'lga muvofiq har bir klaster tugunida joylashgan bo'lishi kerak. Odatiy bo'lib, u tanlangan:

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

... lekin turli Kubernetes distributivlaridan foydalanganda (OpenShift, Rancher...) yo‘l boshqacha bo‘lishi mumkin.

Flexvolume muammolari: qarmoqni qanday qilib to'g'ri quyish kerak?

Flexvolume drayverini klaster tugunlariga yuklash ahamiyatsiz ish bo'lib chiqdi. Operatsiyani bir marta qo'lda bajarganingizdan so'ng, klasterda yangi tugunlar paydo bo'ladigan vaziyatga duch kelish oson: yangi tugun qo'shilishi, avtomatik gorizontal masshtablash yoki eng yomoni - nosozlik tufayli tugunni almashtirish. Bunday holda, ushbu tugunlarda saqlash bilan ishlash kerak mumkin emas, siz hali ham ularga Flexvolume drayverini qo'lda qo'shguningizcha.

Ushbu muammoni hal qilish Kubernetes ibtidoiylaridan biri edi - DaemonSet. Klasterda yangi tugun paydo bo'lganda, u avtomatik ravishda DaemonSet-dan podkastni o'z ichiga oladi, unga Flexvolume drayverlarini topish uchun yo'l bo'ylab mahalliy hajm biriktiriladi. Muvaffaqiyatli yaratilgandan so'ng, pod drayverning diskda ishlashi uchun kerakli fayllarni nusxalaydi.

Flexvolume plaginini joylashtirish uchun bunday DaemonSet misoli:

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>

... va Flexvolume drayverini joylashtirish uchun Bash skriptiga misol:

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

Nusxalash operatsiyasini unutmaslik kerak atom emas. Kubelet drayverni ta'minlash jarayoni tugaguniga qadar foydalanishni boshlash ehtimoli yuqori, bu tizimning ishdan chiqishiga olib keladi. To'g'ri yondashuv birinchi navbatda drayver fayllarini boshqa nom ostida nusxalash va keyin atom nomini o'zgartirish operatsiyasidan foydalanishdir.

Rook operatorida Ceph bilan ishlash diagrammasi: diagrammadagi Flexvolume drayveri Rook agenti ichida joylashgan.

Flexvolume drayverlarini ishlatishda keyingi muammo shundaki, klaster tugunidagi ko'p saqlash uchun Buning uchun kerakli dasturiy ta'minot o'rnatilgan bo'lishi kerak (masalan, Ceph uchun seph-umumiy paketi). Dastlab, Flexvolume plagini bunday murakkab tizimlarni amalga oshirish uchun mo'ljallanmagan.

Ushbu muammoning original yechimini Rook operatorining Flexvolume drayverini amalga oshirishda ko'rish mumkin:

Drayvning o'zi RPC mijozi sifatida yaratilgan. Aloqa uchun IPC rozetkasi haydovchining o'zi bilan bir xil katalogda joylashgan. Drayv fayllarini nusxalash uchun katalogni drayver bilan jild sifatida bog'laydigan DaemonSet-dan foydalanish yaxshi bo'lishini eslaymiz. Kerakli rook drayver fayllarini nusxalashdan so'ng, bu pod o'lmaydi, lekin to'liq huquqli RPC serveri sifatida biriktirilgan hajm orqali IPC rozetkasiga ulanadi. Ceph-umumiy to'plami allaqachon pod konteyneriga o'rnatilgan. IPC rozetkasi kubeletning aynan bir tugunda joylashgan podkast bilan bog'lanishini ta'minlaydi. Aqlli hamma narsa oddiy!..

Xayr, bizning mehribon... daraxt ichidagi plaginlarimiz!

Kubernetes ishlab chiquvchilari yadroda saqlash uchun plaginlar soni yigirmata ekanligini aniqladilar. Va ularning har biridagi o'zgarish, u yoki bu tarzda, Kubernetesning to'liq chiqarish tsiklidan o'tadi.

Ma'lum bo'lishicha, saqlash plaginining yangi versiyasidan foydalanish uchun, butun klasterni yangilashingiz kerak. Bunga qo'shimcha ravishda, Kubernetesning yangi versiyasi to'satdan siz foydalanayotgan Linux yadrosi bilan mos kelmaydigan bo'lib qolishi sizni hayratda qoldirishi mumkin... Shunday qilib, siz ko'z yoshlaringizni artib, tishlaringizni g'ijirlatib, rahbariyat va foydalanuvchilar bilan vaqtni muvofiqlashtirasiz. Linux yadrosi va Kubernetes klasterini yangilang. Xizmatlarni taqdim etishda mumkin bo'lgan uzilishlar bilan.

Vaziyat kulgili emas, shunday emasmi? Bu yondashuv ish bermayotgani butun jamoaga ayon bo‘ldi. Kubernetes ishlab chiquvchilari irodali qarorga ko'ra, xotira bilan ishlash uchun yangi plaginlar endi yadroga qabul qilinmasligini e'lon qiladilar. Bundan tashqari, biz allaqachon bilganimizdek, Flexvolume plaginini joriy etishda bir qator kamchiliklar aniqlangan...

Kubernetes-dagi hajmlar uchun so'nggi qo'shilgan plagin, CSI, doimiy ma'lumotlarni saqlash bilan bog'liq muammoni bir marta va butunlay yopish uchun chaqirildi. Uning alfa versiyasi, to'liqroq "Daraxtdan tashqari CSI Volume plaginlari" deb nomlanadi, relizda e'lon qilindi. Kubernetes 1.9.

Konteynerlarni saqlash interfeysi yoki CSI 3000 yigiruv novdasi!

Avvalo, shuni ta'kidlashni istardimki, CSI nafaqat ovoz balandligi plagini, balki haqiqiydir standart ma'lumotlar omborlari bilan ishlash uchun moslashtirilgan komponentlarni yaratish bo'yicha. Kubernetes va Mesos kabi konteyner orkestrlash tizimlari ushbu standartga muvofiq amalga oshirilgan komponentlar bilan ishlashni "o'rganishi" kerak edi. Va endi men allaqachon Kubernetesni o'rgandim.

Kubernetes-dagi CSI plaginining tuzilishi qanday? CSI plagini maxsus drayverlar bilan ishlaydi (CSI haydovchilar) uchinchi tomon ishlab chiquvchilari tomonidan yozilgan. Kubernetesdagi CSI drayveri kamida ikkita komponentdan (podlardan) iborat bo'lishi kerak:

• Controller — tashqi doimiy xotiralarni boshqaradi. U gRPC serveri sifatida amalga oshiriladi, buning uchun primitiv ishlatiladi StatefulSet.
• Node — klaster tugunlariga doimiy saqlashni o'rnatish uchun javobgardir. U gRPC serveri sifatida ham amalga oshiriladi, lekin u ibtidoiydan foydalanadi DaemonSet.

CSI plagini Kubernetesda qanday ishlaydi

Siz CSI ishining boshqa tafsilotlarini, masalan, maqoladan bilib olishingiz mumkin "C.S.I ni tushunish.», qaysi tarjimasi biz bir yil oldin nashr etgan edik.

Bunday amalga oshirishning afzalliklari

• Tugun uchun drayverni ro'yxatdan o'tkazish kabi asosiy narsalar uchun Kubernetes ishlab chiquvchilari konteynerlar to'plamini amalga oshirdilar. Flexvolume plagini uchun qilinganidek, endi o'zingiz imkoniyatlarga ega JSON javobini yaratishingiz shart emas.
• Bajariladigan fayllarni tugunlarga o'tkazish o'rniga, endi biz podlarni klasterga yuklaymiz. Biz dastlab Kubernetesdan kutgan narsamiz: barcha jarayonlar Kubernetes primitivlari yordamida joylashtirilgan konteynerlarda sodir bo'ladi.
• Murakkab drayverlarni amalga oshirish uchun endi RPC serveri va RPC mijozini ishlab chiqishingiz shart emas. Mijoz biz uchun Kubernetes dasturchilari tomonidan amalga oshirilgan.
• gRPC protokoli ustida ishlash uchun argumentlarni uzatish ularni buyruq qatori argumentlari orqali o'tkazishdan ko'ra ancha qulay, moslashuvchan va ishonchli. Standartlashtirilgan gRPC usulini qo'shish orqali CSI-ga hajmdan foydalanish ko'rsatkichlarini qanday qo'shishni tushunish uchun quyidagilarni o'qishingiz mumkin: bizning tortishish talabimiz vsphere-csi haydovchi uchun.
• Kubelet so'rovni to'g'ri podga yuborganmi yoki yo'qmi, chalkashmaslik uchun aloqa IPC rozetkalari orqali amalga oshiriladi.

Ushbu ro'yxat sizga nimanidir eslatadimi? CSI ning afzalliklari quyidagilardan iborat xuddi shu muammolarni hal qilish, Flexvolume plaginini ishlab chiqishda e'tiborga olinmagan.

topilmalar

Ma'lumotlar omborlari bilan o'zaro ishlash uchun maxsus plaginlarni joriy qilish uchun standart sifatida CSI hamjamiyat tomonidan juda iliq qabul qilindi. Bundan tashqari, afzalliklari va ko'p qirraliligi tufayli CSI drayverlari hatto Ceph yoki AWS EBS kabi saqlash tizimlari uchun ham yaratilgan, ular bilan ishlash uchun plaginlar Kubernetesning birinchi versiyasida qo'shilgan.

2019 yil boshida daraxt ichidagi plaginlar eskirgan deb e'lon qilindi. Biz Flexvolume plaginini qo‘llab-quvvatlashda davom etishni rejalashtirmoqdamiz, lekin u uchun yangi funksiyalarni ishlab chiqmaymiz.

Biz allaqachon ceph-csi, vsphere-csi-dan foydalanish tajribasiga egamiz va bu ro'yxatga qo'shishga tayyormiz! Hozircha, CSI o'ziga yuklangan vazifalarni portlash bilan hal qilmoqda, ammo biz kutamiz va ko'ramiz.

Shuni unutmangki, hamma yangi narsa eskisini yaxshi qayta ko'rib chiqishdir!

PS

Shuningdek, bizning blogimizda o'qing:

• «Biz konteynerni saqlash interfeysini tushunamiz (nafaqat Kubernetesda)";
• «Rookmi yoki yo'qmi - bu savol";
• «Kubernetes-da ovoz balandligidagi suratlarning alfa versiyasini taqdim etish".

Manba: www.habr.com