Programu jalizi za kiasi kwa hifadhi ya Kubernetes: kutoka Flexvolume hadi CSI

Huko nyuma wakati Kubernetes ilikuwa v1.0.0, kulikuwa na programu jalizi za sauti. Zilihitajika kuunganisha mifumo kwa Kubernetes kwa kuhifadhi data ya kontena endelevu (ya kudumu). Idadi yao ilikuwa ndogo, na kati ya kwanza walikuwa watoa huduma kama vile GCE PD, Ceph, AWS EBS na wengine.

Programu-jalizi ziliwasilishwa pamoja na Kubernetes, ndiyo sababu walipata jina lao - ndani ya mti. Walakini, kwa wengi, seti iliyopo ya programu-jalizi kama hizo iligeuka kuwa haitoshi. Mafundi waliongeza programu-jalizi rahisi kwenye msingi wa Kubernetes kwa kutumia viraka, baada ya hapo walikusanya Kubernetes zao na kusakinisha kwenye seva zao. Lakini baada ya muda, watengenezaji wa Kubernetes waligundua hilo samaki tatizo haliwezi kutatuliwa. Watu wanahitaji fimbo ya uvuvi. Na katika kutolewa kwa Kubernetes v1.2.0 ilionekana...

Programu-jalizi ya Flexvolume: fimbo ndogo ya uvuvi

Watengenezaji wa Kubernetes waliunda programu-jalizi ya FlexVolume, ambayo ilikuwa mfumo wa kimantiki wa vigezo na mbinu za kufanya kazi na viendeshaji vya Flexvolume vilivyotekelezwa na watengenezaji wa watu wengine.

Wacha tusimame na tuangalie kwa karibu ni nini kiendesha FlexVolume. Hii ni fulani faili inayoweza kutekelezwa (faili ya jozi, hati ya Python, hati ya Bash, n.k.), ambayo, inapotekelezwa, huchukua hoja za safu ya amri kama ingizo na kurudisha ujumbe wenye sehemu zinazojulikana awali katika umbizo la JSON. Kwa makubaliano, hoja ya mstari wa amri ya kwanza daima ni njia, na hoja zilizobaki ni vigezo vyake.

Mchoro wa muunganisho wa Hisa za CIFS katika OpenShift. Dereva ya Flexvolume - Katikati

Seti ya chini ya mbinu inaonekana kama hii:

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

Kutumia Mbinu attach и detach itafafanua hali ambayo kubelet itachukua hatua katika siku zijazo wakati wa kumpigia simu dereva. Pia kuna mbinu maalum expandvolume и expandfs, ambayo inawajibika kwa kubadilisha ukubwa wa sauti kwa nguvu.

Kama mfano wa mabadiliko ambayo njia inaongeza expandvolume, na kwa hiyo uwezo wa kurekebisha ukubwa kwa wakati halisi, unaweza kujijulisha nayo ombi letu la kuvuta katika Rook Ceph Operator.

Na hapa kuna mfano wa utekelezaji wa dereva wa Flexvolume kwa kufanya kazi na 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

Kwa hiyo, baada ya kuandaa faili halisi inayoweza kutekelezwa, unahitaji pakia kiendeshaji kwenye nguzo ya Kubernetes. Dereva lazima awe kwenye kila nodi ya nguzo kulingana na njia iliyotanguliwa. Kwa chaguo-msingi, ilichaguliwa:

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

... lakini unapotumia usambazaji tofauti wa Kubernetes (OpenShift, Rancher...) njia inaweza kuwa tofauti.

Matatizo ya Flexvolume: jinsi ya kutupa fimbo ya uvuvi kwa usahihi?

Kupakia kiendesha Flexvolume kwenye nodi za nguzo kuligeuka kuwa kazi isiyo ya kawaida. Baada ya kufanya operesheni kwa mikono mara moja, ni rahisi kukutana na hali ambapo nodi mpya zinaonekana kwenye nguzo: kwa sababu ya kuongezwa kwa nodi mpya, kuongeza usawa wa moja kwa moja, au - ni mbaya zaidi - uingizwaji wa nodi kwa sababu ya malfunction. Katika kesi hii, kazi na hifadhi kwenye nodes hizi inapaswa kufanyika haiwezekani, hadi bado uongeze mwenyewe kiendesha Flexvolume kwao.

Suluhisho la shida hii lilikuwa moja ya primitives ya Kubernetes - DaemonSet. Wakati nodi mpya inaonekana kwenye nguzo, huwa na kiotomatiki ganda kutoka kwa DaemonSet yetu, ambayo kiasi cha ndani huambatishwa kwenye njia ili kupata viendeshaji vya Flexvolume. Baada ya uundaji wa mafanikio, pod inakili faili muhimu kwa dereva kufanya kazi kwenye diski.

Hapa kuna mfano wa DaemonSet kama hiyo ya kuweka programu-jalizi ya 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>

... na mfano wa hati ya Bash ya kuweka dereva wa 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

Ni muhimu usisahau kwamba operesheni ya nakala sio atomiki. Kuna uwezekano mkubwa kwamba kubelet itaanza kutumia dereva kabla ya mchakato wake wa utoaji kukamilika, na kusababisha mfumo kuanguka. Njia sahihi ni kunakili faili za kiendeshi kwanza chini ya jina tofauti, na kisha kutumia operesheni ya kubadilisha jina la atomiki.

Mchoro wa kufanya kazi na Ceph katika opereta wa Rook: dereva wa Flexvolume kwenye mchoro iko ndani ya wakala wa Rook.

Shida inayofuata wakati wa kutumia viendeshaji vya Flexvolume ni kwamba kwa uhifadhi mwingi kwenye nodi ya nguzo programu muhimu kwa hili lazima iwe imewekwa (kwa mfano, kifurushi cha ceph-kawaida cha Ceph). Hapo awali, programu-jalizi ya Flexvolume haikuundwa kutekeleza mifumo ngumu kama hii.

Suluhisho la asili la shida hii linaweza kuonekana katika utekelezaji wa dereva wa Flexvolume wa opereta wa Rook:

Dereva yenyewe imeundwa kama mteja wa RPC. Soketi ya IPC ya mawasiliano iko kwenye saraka sawa na dereva yenyewe. Tunakumbuka kwamba kunakili faili za kiendeshi itakuwa vizuri kutumia DaemonSet, ambayo inaunganisha saraka na dereva kama kiasi. Baada ya kunakili faili zinazohitajika za kiendesha rook, ganda hili halifi, lakini huunganishwa na tundu la IPC kupitia kiasi kilichoambatishwa kama seva kamili ya RPC. Kifurushi cha ceph-common tayari kimesakinishwa ndani ya chombo cha ganda. Soketi ya IPC inahakikisha kuwa kubelet itawasiliana na ganda ambalo liko kwenye nodi sawa. Kila kitu cha busara ni rahisi! ..

Kwaheri, mpendwa wetu... programu-jalizi za ndani ya mti!

Watengenezaji wa Kubernetes waligundua kuwa idadi ya programu-jalizi za kuhifadhi ndani ya msingi ni ishirini. Na mabadiliko katika kila mmoja wao, kwa njia moja au nyingine, hupitia mzunguko kamili wa kutolewa wa Kubernetes.

Inabadilika kuwa kutumia toleo jipya la programu-jalizi ya uhifadhi, unahitaji kusasisha nguzo nzima. Kwa kuongeza hii, unaweza kushangaa kwamba toleo jipya la Kubernetes litaachana ghafla na kernel ya Linux unayotumia ... Kwa hiyo unafuta machozi yako na, kusaga meno yako, kuratibu na usimamizi wako na watumiaji wakati wa sasisha kernel ya Linux na nguzo ya Kubernetes. Pamoja na downtime iwezekanavyo katika utoaji wa huduma.

Hali ni zaidi ya ucheshi, hufikirii? Ikadhihirika kwa jamii nzima kuwa mbinu hiyo haifanyi kazi. Kwa uamuzi wa makusudi, watengenezaji wa Kubernetes wanatangaza kuwa programu-jalizi mpya za kufanya kazi na uhifadhi hazitakubaliwa tena kwenye kernel. Kwa kuongezea, kama tunavyojua tayari, mapungufu kadhaa yalitambuliwa katika utekelezaji wa programu-jalizi ya Flexvolume...

Programu-jalizi ya hivi punde zaidi ya juzuu katika Kubernetes, CSI, iliitwa kufunga suala hilo kwa uhifadhi wa data unaoendelea mara moja na kwa wote. Toleo lake la alpha, linalojulikana zaidi kama Programu-jalizi za Kiasi cha Out-of-Tree CSI, lilitangazwa katika toleo hilo. Kubernetes 1.9.

Kiolesura cha Kuhifadhi Kontena, au fimbo ya kusokota ya CSI 3000!

Kwanza kabisa, ningependa kutambua kwamba CSI sio tu programu-jalizi ya kiasi, lakini ni halisi kiwango juu ya kuunda vipengele maalum vya kufanya kazi na ghala za data. Mifumo ya ochestration ya kontena kama vile Kubernetes na Mesos ilipaswa "kujifunza" jinsi ya kufanya kazi na vipengele vilivyotekelezwa kulingana na kiwango hiki. Na sasa tayari nimejifunza Kubernetes.

Je, ni muundo gani wa programu-jalizi ya CSI katika Kubernetes? Programu-jalizi ya CSI inafanya kazi na viendeshi maalum (Madereva ya CSI) iliyoandikwa na watengenezaji wengine. Kiendeshi cha CSI huko Kubernetes kinapaswa kuwa na sehemu mbili (maganda):

• Mdhibiti - hudhibiti hifadhi za nje zinazoendelea. Inatekelezwa kama seva ya gRPC, ambayo ya kwanza hutumiwa StatefulSet.
• Node - inawajibika kwa kuweka hifadhi inayoendelea kwenye nodi za nguzo. Pia inatekelezwa kama seva ya gRPC, lakini hutumia ya primitive DaemonSet.

Jinsi programu-jalizi ya CSI inavyofanya kazi katika Kubernetes

Unaweza kujifunza juu ya maelezo mengine ya kazi ya CSI, kwa mfano, kutoka kwa kifungu "Kuelewa C.S.I.' tafsiri yake tulichapisha mwaka mmoja uliopita.

Faida za utekelezaji kama huo

• Kwa mambo ya msingi kama vile kusajili kiendeshi kwa nodi, watengenezaji wa Kubernetes walitekeleza seti ya vyombo. Huhitaji tena kutoa jibu la JSON lenye uwezo mwenyewe, kama ilivyofanywa kwa programu-jalizi ya Flexvolume.
• Badala ya "kuteleza" faili zinazoweza kutekelezwa kwenye nodi, sasa tunapakia maganda kwenye nguzo. Hili ndilo tunalotarajia mwanzoni kutoka kwa Kubernetes: michakato yote hutokea ndani ya makontena yaliyotumwa kwa kutumia matoleo ya awali ya Kubernetes.
• Huhitaji tena kutengeneza seva ya RPC na mteja wa RPC ili kutekeleza viendeshaji changamano. Mteja alitekelezwa kwa ajili yetu na watengenezaji wa Kubernetes.
• Kupitisha hoja ili kufanyia kazi itifaki ya gRPC ni rahisi zaidi, kunyumbulika na kutegemewa kuliko kuzipitisha kupitia hoja za mstari wa amri. Ili kuelewa jinsi ya kuongeza usaidizi wa vipimo vya matumizi ya kiasi kwa CSI kwa kuongeza mbinu sanifu ya gRPC, unaweza kusoma: ombi letu la kuvuta kwa dereva wa vsphere-csi.
• Mawasiliano hutokea kupitia soketi za IPC, ili usichanganyikiwe ikiwa kubelet ilituma ombi kwa ganda sahihi.

Je, orodha hii inakukumbusha chochote? Faida za CSI ni kutatua matatizo hayo hayo, ambazo hazikuzingatiwa wakati wa kutengeneza programu-jalizi ya Flexvolume.

Matokeo

CSI kama kiwango cha kutekeleza programu-jalizi maalum za kuingiliana na ghala za data ilipokelewa kwa uchangamfu sana na jumuiya. Kwa kuongezea, kwa sababu ya faida zao na matumizi mengi, viendeshi vya CSI huundwa hata kwa mifumo ya uhifadhi kama vile Ceph au AWS EBS, programu-jalizi za kufanya kazi nazo ambazo ziliongezwa katika toleo la kwanza la Kubernetes.

Mwanzoni mwa 2019, programu-jalizi za ndani ya mti yametangazwa kuwa ya kizamani. Tunapanga kuendelea kuauni programu-jalizi ya Flexvolume, lakini hatutatengeneza utendakazi mpya kwake.

Sisi wenyewe tayari tuna uzoefu wa kutumia ceph-csi, vsphere-csi na tuko tayari kuongeza kwenye orodha hii! Kufikia sasa, CSI inakabiliana na kazi iliyopewa kwa kishindo, lakini tutasubiri na kuona.

Usisahau kwamba kila kitu kipya ni kufikiria tena kwa zamani!

PS

Soma pia kwenye blogi yetu:

• «Tunaelewa Kiolesura cha Kuhifadhi Kontena (huko Kubernetes na sio tu)";
• «Kwa Rook au sio kwa Rook - hilo ndilo swali";
• «Tunakuletea toleo la alpha la vijipicha vya sauti katika Kubernetes'.

Chanzo: mapenzi.com