Kai „Kubernetes“ dar buvo 1.0.0 versija, buvo apimties įskiepių. Jie buvo reikalingi sistemoms prijungti prie „Kubernetes“, kad būtų saugomi nuolatiniai (nuolatiniai) konteinerio duomenys. Jų buvo nedaug, o tarp pirmųjų buvo tokie saugyklos tiekėjai kaip GCE PD, Ceph, AWS EBS ir kt.
Papildiniai buvo pristatyti kartu su Kubernetes, todėl jie gavo savo pavadinimą - in-tree. Tačiau daugeliui esamas tokių įskiepių rinkinys pasirodė esąs nepakankamas. Amatininkai prie Kubernetes branduolio pridėjo paprastų įskiepių naudodami pataisas, po to jie surinko savo Kubernetes ir įdiegė jį savo serveriuose. Tačiau laikui bėgant „Kubernetes“ kūrėjai tai suprato žuvis problemos negalima išspręsti. Žmonėms reikia meškerė. O Kubernetes v1.2.0 leidime pasirodė...
„Flexvolume“ papildinys: minimali meškerė
„Kubernetes“ kūrėjai sukūrė „FlexVolume“ papildinį, kuris buvo logiška kintamųjų ir metodų sistema, skirta darbui su „Flexvolume“ tvarkyklėmis, įdiegtomis trečiųjų šalių kūrėjų.
Sustokime ir atidžiau pažiūrėkime, kas yra „FlexVolume“ tvarkyklė. Tai yra tam tikra vykdomąjį failą (dvejetainis failas, „Python“ scenarijus, „Bash“ scenarijus ir kt.), kuris, kai vykdomas, kaip įvestį priima komandų eilutės argumentus ir grąžina pranešimą su iš anksto žinomais laukais JSON formatu. Pagal susitarimą pirmasis komandos eilutės argumentas visada yra metodas, o likę argumentai yra jo parametrai.
Ryšio schema, skirta CIFS bendrinimui naudojant „OpenShift“. „Flexvolume“ tvarkyklė – pačiame centre
Minimalus metodų rinkinys atrodo taip:
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}
}
Metodų naudojimas attach и detach apibrėš scenarijų, pagal kurį kubeletas veiks ateityje, skambindamas vairuotojui. Taip pat yra specialių metodų expandvolume и expandfs, kurios yra atsakingos už dinaminį garsumo dydžio keitimą.
Kaip pakeitimų, kuriuos prideda metodas, pavyzdys expandvolume, o kartu su galimybe keisti tomų dydį realiuoju laiku galite susipažinti Rook Ceph Operator.
Ir čia yra „Flexvolume“ tvarkyklės, skirtos darbui su NFS, diegimo pavyzdys:
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 1Taigi, parengę tikrąjį vykdomąjį failą, turite įkelti tvarkyklę į Kubernetes klasterį. Vairuotojas turi būti kiekviename klasterio mazge pagal iš anksto nustatytą kelią. Pagal numatytuosius nustatymus jis buvo pasirinktas:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/
... bet naudojant skirtingus Kubernetes paskirstymus (OpenShift, Rancher...) kelias gali skirtis.
Flexvolume problemos: kaip teisingai užmesti meškerę?
„Flexvolume“ tvarkyklės įkėlimas į klasterio mazgus pasirodė esąs nebanalus uždavinys. Vieną kartą atlikus operaciją rankiniu būdu, nesunku susidurti su situacija, kai klasteryje atsiranda naujų mazgų: dėl naujo mazgo pridėjimo, automatinio horizontalaus mastelio keitimo arba – kas dar blogiau – mazgo pakeitimo dėl gedimo. Tokiu atveju reikėtų dirbti su šių mazgų saugykla neįmanoma, kol vis tiek rankiniu būdu prie jų pridėsite „Flexvolume“ tvarkyklę.
Šios problemos sprendimas buvo vienas iš Kubernetes primityvų - DaemonSet. Kai klasteryje atsiranda naujas mazgas, jame automatiškai yra mūsų „DaemonSet“ rinkinys, prie kurio pridedamas vietinis tomas, kad būtų galima rasti „Flexvolume“ tvarkykles. Sėkmingai sukūrus, blokas nukopijuoja reikalingus failus į diską, kad tvarkyklė veiktų.
Štai tokio „DaemonSet“, skirto „Flexvolume“ papildiniui išdėstyti, pavyzdys:
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>... ir Bash scenarijaus, skirto Flexvolume tvarkyklei išdėstyti, pavyzdys:
#!/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
doneSvarbu nepamiršti, kad kopijavimo operacija nėra atominis. Yra didelė tikimybė, kad kubeletas pradės naudoti tvarkyklę dar nepasibaigus jo aprūpinimo procesui, o tai sukels sistemos klaidą. Teisingas būdas yra pirmiausia nukopijuoti tvarkyklės failus kitu pavadinimu, o tada naudoti atominį pervadinimo operaciją.
Darbo su Ceph „Rook“ operatoriuje schema: „Flexvolume“ tvarkyklė diagramoje yra „Rook“ agento viduje
Kita problema naudojant „Flexvolume“ tvarkykles yra daugumos saugyklos klasterio mazge problema turi būti įdiegta tam reikalinga programinė įranga (pavyzdžiui, bendras Ceph paketas). Iš pradžių „Flexvolume“ papildinys nebuvo skirtas tokioms sudėtingoms sistemoms įdiegti.
Originalų šios problemos sprendimą galima pamatyti „Rook“ operatoriaus „Flexvolume“ tvarkyklės diegime:
Pati tvarkyklė sukurta kaip RPC klientas. Ryšio IPC lizdas yra tame pačiame kataloge kaip ir pati tvarkyklė. Prisimename, kad norint nukopijuoti tvarkyklės failus, būtų gerai naudoti DaemonSet, kuris sujungia katalogą su tvarkykle kaip tomą. Nukopijavus reikiamus rook tvarkyklės failus, šis pods nemiršta, o per pridedamą tomą jungiasi prie IPC lizdo kaip pilnavertis RPC serveris. Ceph-common paketas jau įdiegtas pod konteinerio viduje. IPC lizdas užtikrina, kad kubeletas susisieks tiksliai su tame pačiame mazge esančiu bloku. Viskas išradinga yra paprasta!..
Viso gero, mūsų meilūs... medyje esantys papildiniai!
„Kubernetes“ kūrėjai išsiaiškino, kad įskiepių, skirtų saugoti branduolyje, skaičius yra dvidešimt. Ir kiekvieno iš jų pasikeitimas vienaip ar kitaip praeina visą Kubernetes išleidimo ciklą.
Paaiškėjo, kad norint naudoti naują saugojimo papildinio versiją, reikia atnaujinti visą klasterį. Be to, galite nustebti, kad naujoji „Kubernetes“ versija staiga taps nesuderinama su jūsų naudojamu „Linux“ branduoliu... Taigi jūs nusišluostote ašaras ir, sukandę dantis, derinate su vadovybe ir vartotojais laiką atnaujinti Linux branduolį ir Kubernetes klasterį. Su galimomis prastovomis teikiant paslaugas.
Situacija daugiau nei komiška, ar nemanote? Visai bendruomenei tapo aišku, kad šis metodas neveikia. Sąmoningu sprendimu Kubernetes kūrėjai praneša, kad nauji papildiniai, skirti darbui su saugykla, nebebus priimami į branduolį. Be to, kaip jau žinome, įdiegiant Flexvolume įskiepį buvo nustatyta nemažai trūkumų...
Naujausias pridėtas tomų įskiepis Kubernetes, CSI, buvo paragintas kartą ir visiems laikams išspręsti problemą dėl nuolatinio duomenų saugojimo. Jo alfa versija, tiksliau vadinama Out-of-Tree CSI Volume Plugins, buvo paskelbta leidime .
Konteinerių laikymo sąsaja arba CSI 3000 verpimo meškerė!
Visų pirma, norėčiau pastebėti, kad CSI yra ne tik apimties įskiepis, bet ir tikras kaip sukurti pasirinktinius komponentus darbui su duomenų saugyklomis. Konteinerių orkestravimo sistemos, tokios kaip Kubernetes ir Mesos, turėjo „išmokti“ dirbti su komponentais, įdiegtais pagal šį standartą. O dabar jau išmokau Kubernetes.
Kokia yra Kubernetes CSI papildinio struktūra? CSI papildinys veikia su specialiomis tvarkyklėmis (CSI tvarkyklės) parašė trečiųjų šalių kūrėjai. „Kubernetes“ CSI tvarkyklę turėtų sudaryti mažiausiai du komponentai (dėklai):
- kontrolierius - tvarko išorines nuolatines saugyklas. Jis įdiegtas kaip gRPC serveris, kuriam naudojamas primityvus
StatefulSet. - mazgas - yra atsakingas už nuolatinės saugyklos diegimą klasterio mazguose. Jis taip pat įdiegtas kaip gRPC serveris, tačiau tam naudojamas primityvus
DaemonSet.
Kaip CSI papildinys veikia Kubernetes
Apie kai kurias kitas CSI darbo detales galite sužinoti, pavyzdžiui, iš straipsnio „" paskelbėme prieš metus.
Tokio įgyvendinimo pranašumai
- Pagrindiniams dalykams, pavyzdžiui, mazgo tvarkyklės registravimui, Kubernetes kūrėjai įdiegė konteinerių rinkinį. Jums nebereikia patiems generuoti JSON atsako su galimybėmis, kaip buvo daroma su „Flexvolume“ papildiniu.
- Užuot „slinkę“ vykdomuosius failus į mazgus, dabar įkeliame rinkinius į klasterį. To iš pradžių tikimės iš „Kubernetes“: visi procesai vyksta konteineriuose, įdiegtuose naudojant „Kubernetes“ primityvus.
- Jums nebereikia kurti RPC serverio ir RPC kliento, kad galėtumėte įdiegti sudėtingas tvarkykles. Klientą mums įdiegė Kubernetes kūrėjai.
- Argumentų perdavimas darbui naudojant gRPC protokolą yra daug patogesnis, lankstesnis ir patikimesnis nei perduoti juos per komandinės eilutės argumentus. Norėdami suprasti, kaip pridėti apimties naudojimo metrikos palaikymą prie CSI pridedant standartizuotą gRPC metodą, galite perskaityti: vsphere-csi tvarkyklei.
- Ryšys vyksta per IPC lizdus, kad nesusipainiotumėte, ar kubeletas išsiuntė užklausą į tinkamą lizdą.
Ar šis sąrašas jums ką nors primena? CSI pranašumai yra sprendžiant tas pačias problemas, į kuriuos nebuvo atsižvelgta kuriant „Flexvolume“ papildinį.
išvados
Bendruomenė labai šiltai priėmė CSI, kaip standartą, skirtą įdiegti pasirinktinius papildinius, skirtus sąveikai su duomenų saugyklomis. Be to, dėl savo pranašumų ir universalumo CSI tvarkyklės yra sukurtos net tokioms saugojimo sistemoms kaip Ceph ar AWS EBS, darbo įskiepiai, su kuriais buvo įtraukti į pačią pirmąją Kubernetes versiją.
2019 m. pradžioje įskiepiai medyje . Planuojame ir toliau palaikyti „Flexvolume“ papildinį, bet nekursime jam naujų funkcijų.
Mes patys jau turime patirties naudojant ceph-csi, vsphere-csi ir esame pasirengę papildyti šį sąrašą! Kol kas CSI su jai pavestomis užduotimis susidoroja su kaupu, bet palauksime ir pamatysime.
Nepamirškite, kad viskas, kas nauja, yra geras seno permąstymas!
PS
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «".
Šaltinis: www.habr.com