მოცულობის დანამატები Kubernetes შენახვისთვის: Flexvolume-დან CSI-მდე

როდესაც Kubernetes ჯერ კიდევ v1.0.0 იყო, იყო მოცულობის დანამატები. ისინი საჭირო იყო სისტემების დასაკავშირებლად Kubernetes-თან მუდმივი (მუდმივი) კონტეინერის მონაცემების შესანახად. მათი რაოდენობა მცირე იყო და პირველთა შორის იყო შენახვის ისეთი პროვაიდერები, როგორებიცაა GCE PD, Ceph, AWS EBS და სხვები.

დანამატები მიიტანეს Kubernetes-თან ერთად, რის გამოც მათ მიიღეს სახელი - in-tree. თუმცა, ბევრისთვის ასეთი დანამატების არსებული ნაკრები არასაკმარისი აღმოჩნდა. ხელოსნებმა დაამატეს Kubernetes-ის ბირთვს მარტივი დანამატები პატჩების გამოყენებით, რის შემდეგაც შეკრიბეს საკუთარი Kubernetes და დააინსტალირეს სერვერებზე. მაგრამ დროთა განმავლობაში, Kubernetes-ის დეველოპერებმა გააცნობიერეს ეს თევზი პრობლემის გადაჭრა შეუძლებელია. ხალხს სჭირდება როდ. და Kubernetes v1.2.0 გამოშვებაში გამოჩნდა...

Flexvolume მოდული: მინიმალური სათევზაო ჯოხი

Kubernetes-ის დეველოპერებმა შექმნეს FlexVolume მოდული, რომელიც იყო მესამე მხარის დეველოპერების მიერ დანერგილი ცვლადების და მეთოდების ლოგიკური ჩარჩო Flexvolume დრაივერებთან მუშაობისთვის.

მოდით შევჩერდეთ და უფრო ახლოს გადავხედოთ რა არის FlexVolume დრაივერი. ეს გარკვეულია შესრულებადი ფაილი (ორობითი ფაილი, პითონის სკრიპტი, Bash სკრიპტი და ა.შ.), რომელიც შესრულებისას იღებს ბრძანების ხაზის არგუმენტებს შეყვანად და აბრუნებს შეტყობინებას წინასწარ ცნობილი ველებით JSON ფორმატში. პირობითად, პირველი ბრძანების ხაზის არგუმენტი ყოველთვის მეთოდია, ხოლო დარჩენილი არგუმენტები მისი პარამეტრებია.

კავშირის დიაგრამა CIFS აქციებისთვის OpenShift-ში. 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 Operator-ში.

და აქ არის 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. როდესაც ახალი კვანძი გამოჩნდება კლასტერში, ის ავტომატურად შეიცავს პოდს ჩვენი 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

მნიშვნელოვანია არ დაგვავიწყდეს, რომ ასლის ოპერაცია არ არის ატომური. დიდია შანსი, რომ კუბელეტმა დაიწყოს დრაივერის გამოყენება მისი უზრუნველყოფის პროცესის დასრულებამდე, რაც გამოიწვევს სისტემაში შეცდომას. სწორი მიდგომაა ჯერ დრაივერის ფაილების სხვა სახელით კოპირება და შემდეგ ატომური სახელის გადარქმევის ოპერაციის გამოყენება.

Ceph-თან მუშაობის დიაგრამა Rook ოპერატორში: დიაგრამაში Flexvolume დრაივერი მდებარეობს Rook აგენტის შიგნით.

შემდეგი პრობლემა Flexvolume დრაივერების გამოყენებისას არის კლასტერულ კვანძზე შენახვის უმეტესი ნაწილი ამისათვის საჭირო პროგრამული უზრუნველყოფა უნდა იყოს დაინსტალირებული (მაგალითად, ceph-common პაკეტი Ceph-ისთვის). თავდაპირველად, Flexvolume მოდული არ იყო შექმნილი ასეთი რთული სისტემების დასანერგად.

ამ პრობლემის ორიგინალური გადაწყვეტა შეგიძლიათ ნახოთ Rook ოპერატორის Flexvolume დრაივერის განხორციელებაში:

თავად დრაივერი შექმნილია როგორც RPC კლიენტი. კომუნიკაციისთვის IPC სოკეტი მდებარეობს იმავე დირექტორიაში, როგორც თავად დრაივერი. ჩვენ გვახსოვს, რომ დრაივერის ფაილების კოპირებისთვის კარგი იქნება გამოვიყენოთ DaemonSet, რომელიც აკავშირებს დირექტორიას დრაივერთან, როგორც მოცულობა. საჭირო rook დრაივერის ფაილების კოპირების შემდეგ, ეს pod არ კვდება, მაგრამ უკავშირდება IPC სოკეტს თანდართული ტომის მეშვეობით, როგორც სრულფასოვანი RPC სერვერი. ceph-common პაკეტი უკვე დამონტაჟებულია პოდის კონტეინერში. IPC სოკეტი უზრუნველყოფს, რომ კუბელეტი დაუკავშირდეს ზუსტად იმ პოდს, რომელიც მდებარეობს იმავე კვანძზე. ყველაფერი გენიალური მარტივია!..

ნახვამდის, ჩვენო მოსიყვარულე... ხის დანამატები!

Kubernetes-ის დეველოპერებმა აღმოაჩინეს, რომ ბირთვში შესანახი დანამატების რაოდენობა არის ოცი. და თითოეული მათგანის ცვლილება, ამა თუ იმ გზით, გადის Kubernetes-ის გამოშვების სრულ ციკლს.

გამოდის, რომ შენახვის მოდულის ახალი ვერსიის გამოსაყენებლად, თქვენ უნდა განაახლოთ მთელი კლასტერი. ამას გარდა, შეიძლება გაგიკვირდეთ, რომ Kubernetes-ის ახალი ვერსია მოულოდნელად შეუთავსებელი გახდება Linux-ის ბირთვთან, რომელსაც თქვენ იყენებთ... ასე მოიწმინდეთ ცრემლები და კბილების ღრჭიალით, კოორდინაციას უწევთ თქვენს მენეჯმენტსა და მომხმარებლებს დრო, რომ განაახლეთ Linux ბირთვი და Kubernetes კლასტერი. მომსახურების მიწოდების შესაძლო შეფერხებით.

სიტუაცია უფრო მეტია ვიდრე კომიკური, არ ფიქრობთ? მთელი საზოგადოებისთვის ნათელი გახდა, რომ მიდგომა არ მუშაობდა. მიზანმიმართული გადაწყვეტილებით, Kubernetes-ის დეველოპერები აცხადებენ, რომ საცავთან მუშაობის ახალი დანამატები აღარ მიიღება ბირთვში. გარდა ამისა, როგორც უკვე ვიცით, Flexvolume მოდულის დანერგვისას გამოიკვეთა მთელი რიგი ხარვეზები...

უახლეს დამატებულ დანამატს ტომებისთვის Kubernetes-ში, CSI, მოწოდებული იქნა, ერთხელ და სამუდამოდ დაეხურა საკითხი მუდმივი მონაცემთა შენახვის შესახებ. მისი ალფა ვერსია, უფრო სრულად მოხსენიებული, როგორც Out-of-Tree CSI Volume Plugins, გამოქვეყნდა გამოშვებაში. კუბერნეტი 1.9.

კონტეინერის შენახვის ინტერფეისი, ან CSI 3000 დაწნული ჯოხი!

პირველ რიგში, მინდა აღვნიშნო, რომ CSI არ არის მხოლოდ მოცულობის მოდული, არამედ რეალური Стандарт მონაცემთა საწყობებთან მუშაობისთვის მორგებული კომპონენტების შექმნის შესახებ. კონტეინერების ორკესტრირების სისტემები, როგორიცაა Kubernetes და Mesos, უნდა „ისწავლონ“ ამ სტანდარტის მიხედვით განხორციელებულ კომპონენტებთან მუშაობა. ახლა კი უკვე ვისწავლე კუბერნეტები.

როგორია CSI მოდულის სტრუქტურა Kubernetes-ში? CSI მოდული მუშაობს სპეციალურ დრაივერებთან (CSI დრაივერები) დაწერილია მესამე მხარის დეველოპერების მიერ. CSI დრაივერი Kubernetes-ში მინიმალურად უნდა შედგებოდეს ორი კომპონენტისგან (pods):

• Controller — მართავს გარე მუდმივ საცავებს. ის დანერგილია როგორც gRPC სერვერი, რისთვისაც გამოიყენება პრიმიტიული StatefulSet.
• Node - პასუხისმგებელია მუდმივი შენახვის მონტაჟზე კლასტერულ კვანძებზე. ის ასევე დანერგილია როგორც gRPC სერვერი, მაგრამ ის იყენებს პრიმიტიულს DaemonSet.

როგორ მუშაობს CSI მოდული Kubernetes-ში

შეგიძლიათ შეიტყოთ CSI-ს მუშაობის სხვა დეტალების შესახებ, მაგალითად, სტატიიდან ”C.S.I-ს გაგება.' რომლის თარგმანიც ერთი წლის წინ გამოვაქვეყნეთ.

ასეთი განხორციელების უპირატესობები

• ძირითადი საკითხებისთვის, როგორიცაა დრაივერის რეგისტრაცია კვანძისთვის, Kubernetes-ის დეველოპერებმა განახორციელეს კონტეინერების ნაკრები. თქვენ აღარ გჭირდებათ JSON პასუხის გენერირება შესაძლებლობებით, როგორც ეს გაკეთდა Flexvolume მოდულისთვის.
• ნაცვლად შესრულებადი ფაილების კვანძებზე „გადატანის“ ნაცვლად, ჩვენ ახლა ავტვირთავთ პოდებს კლასტერში. ეს არის ის, რასაც თავდაპირველად ველით Kubernetes-ისგან: ყველა პროცესი ხდება კონტეინერებში, რომლებიც განლაგებულია 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

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «ჩვენ გვესმის კონტეინერის შენახვის ინტერფეისი (კუბერნეტში და არა მხოლოდ)";
• «რუკს თუ არა რუკს - ეს არის კითხვა";
• «წარმოგიდგენთ მოცულობის სნეპშოტების ალფა ვერსიას Kubernetes-ში".

წყარო: www.habr.com