Amikor a Kubernetes még 1.0.0 volt, léteztek kötetbővítmények. Szükségesek voltak a rendszerek Kuberneteshez való csatlakoztatásához a perzisztens (állandó) konténeradatok tárolására. Számuk csekély volt, és az elsők között voltak olyan tárolószolgáltatók, mint a GCE PD, Ceph, AWS EBS és mások.
A bővítményeket a Kubernetes-szel együtt szállították, ezért kapták a nevüket - in-tree. Sokak számára azonban az ilyen bővítmények meglévő készlete nem bizonyult elegendőnek. A kézművesek patchek segítségével egyszerű bővítményeket adtak a Kubernetes maghoz, majd összeállították saját Kubernetes-üket és telepítették a szervereikre. De idővel a Kubernetes fejlesztői rájöttek erre hal a probléma nem oldható meg. Az embereknek szükségük van horgászbot. A Kubernetes v1.2.0 kiadásában pedig megjelent...
Flexvolume plugin: minimális horgászbot
A Kubernetes fejlesztői létrehozták a FlexVolume beépülő modult, amely változók és módszerek logikai kerete volt a külső fejlesztők által implementált Flexvolume illesztőprogramokkal való munkavégzéshez.
Álljunk meg, és nézzük meg közelebbről, mi is az a FlexVolume illesztőprogram. Ez egy bizonyos futtatható fájl (bináris fájl, Python-szkript, Bash-szkript stb.), amely végrehajtásakor parancssori argumentumokat vesz be bemenetként, és egy üzenetet ad vissza előre ismert mezőkkel JSON formátumban. Megállapodás szerint az első parancssori argumentum mindig metódus, a többi argumentum pedig annak paraméterei.
Csatlakozási diagram a CIFS-megosztásokhoz az OpenShiftben. Flexvolume Driver – közvetlenül a központban
Minimális módszerkészlet így néz ki:
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}
}
Módszerek használata attach и detach meghatározza azt a forgatókönyvet, amelyben a kubelet a jövőben az illesztőprogram hívásakor fog működni. Vannak speciális módszerek is expandvolume и expandfs, amelyek a hangerő dinamikus átméretezéséért felelősek.
Példaként a módszer által hozzáadott változásokra expandvolume, és ezzel a kötetek valós idejű átméretezésének lehetőségével megismerkedhet a Rook Ceph Operatorban.
És itt van egy példa a Flexvolume illesztőprogram megvalósítására az NFS-sel való együttműködéshez:
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 1Tehát a tényleges futtatható fájl elkészítése után meg kell tennie töltse fel az illesztőprogramot a Kubernetes-fürtbe. Az illesztőprogramnak minden fürtcsomóponton egy előre meghatározott útvonalon kell elhelyezkednie. Alapértelmezés szerint ez volt kiválasztva:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/
... de különböző Kubernetes disztribúciók használatakor (OpenShift, Rancher...) az elérési út eltérő lehet.
Flexvolume problémák: hogyan kell helyesen dobni egy horgászbotot?
A Flexvolume illesztőprogram feltöltése a fürt csomópontjaira nem triviális feladatnak bizonyult. A művelet egyszeri manuális elvégzése után könnyen találkozhatunk olyan helyzettel, amikor új csomópontok jelennek meg a klaszterben: új csomópont hozzáadása, automatikus vízszintes skálázás, vagy - ami még rosszabb - meghibásodás miatti csomópont cseréje miatt. Ebben az esetben a tárolóval ezeken a csomópontokon kell dolgozni lehetetlen, amíg manuálisan hozzá nem adja hozzájuk a Flexvolume illesztőprogramot.
A probléma megoldása a Kubernetes primitívek egyike volt - DaemonSet. Amikor egy új csomópont jelenik meg a fürtben, az automatikusan tartalmaz egy pod-ot a DaemonSet-ünkből, amelyhez egy helyi kötetet csatolunk a Flexvolume illesztőprogramok megtalálásához. Sikeres létrehozás után a pod a lemezre másolja az illesztőprogram működéséhez szükséges fájlokat.
Íme egy példa egy ilyen DaemonSet-re egy Flexvolume beépülő modul elrendezéséhez:
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>... és egy példa egy Bash-szkriptre a Flexvolume illesztőprogram elrendezéséhez:
#!/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
doneFontos, hogy ne felejtsük el, hogy a másolási művelet nem atomos. Nagy az esélye annak, hogy a kubelet még azelőtt elkezdi használni az illesztőprogramot, mielőtt a kiépítési folyamat befejeződik, ami a rendszer összeomlását okozza. A helyes megközelítés az, hogy először más néven másolja át az illesztőprogram-fájlokat, majd atomi átnevezési műveletet használ.
A Ceph-fel való munka diagramja a Rook operátorban: a diagram Flexvolume illesztőprogramja a Rook ügynökön belül található
A következő probléma a Flexvolume illesztőprogramok használatakor az, hogy a legtöbb fürtcsomóponton lévő tárhelyre vonatkozik az ehhez szükséges szoftvert telepíteni kell (például a Ceph-hez használt ceph-common csomag). Kezdetben a Flexvolume beépülő modult nem ilyen összetett rendszerek megvalósítására tervezték.
Ennek a problémának az eredeti megoldása a Rook operátor Flexvolume illesztőprogramjának megvalósításában látható:
Maga az illesztőprogram RPC-kliensnek készült. A kommunikációt szolgáló IPC-aljzat ugyanabban a könyvtárban található, mint maga a meghajtó. Emlékezzünk arra, hogy az illesztőprogram-fájlok másolásához jó lenne a DaemonSet használata, amely kötetként köti össze a könyvtárat a meghajtóval. A szükséges rook illesztőprogram fájlok másolása után ez a pod nem hal meg, hanem teljes értékű RPC szerverként csatlakozik az IPC aljzathoz a mellékelt köteten keresztül. A ceph-common csomag már telepítve van a pod-tárolóban. Az IPC foglalat biztosítja, hogy a kubelet pontosan azzal a podtal kommunikáljon, amely ugyanazon a csomóponton található. Minden ötletes egyszerű!...
Viszlát, kedves... in-tree pluginjeink!
A Kubernetes fejlesztői felfedezték, hogy a magon belüli tárolásra szolgáló bővítmények száma húsz. És mindegyikük változása így vagy úgy, a teljes Kubernetes kiadási cikluson megy keresztül.
Kiderült, hogy a tárolóbővítmény új verziójának használatához frissítenie kell a teljes klasztert. Ezen túlmenően meglepődhet, hogy a Kubernetes új verziója hirtelen inkompatibilis lesz az Ön által használt Linux kernellel... Szóval letörli a könnyeit, és fogcsikorgatva egyezteti a vezetőséggel és a felhasználókkal az időt, frissítse a Linux kernelt és a Kubernetes-fürtöt. A szolgáltatásnyújtás esetleges leállásával.
A helyzet több mint komikus, nem gondolod? Az egész közösség számára világossá vált, hogy a megközelítés nem működik. Szándékos döntéssel a Kubernetes fejlesztői bejelentették, hogy a tárhellyel dolgozó új bővítményeket a továbbiakban nem fogadják el a kernelbe. Ráadásul, mint már tudjuk, a Flexvolume bővítmény implementációjában számos hiányosságot azonosítottak...
A Kubernetes (CSI) kötetekhez legutóbb hozzáadott bővítményt arra kérték, hogy egyszer s mindenkorra lezárja a problémát az állandó adattárolással. A kiadásban bejelentették alfa verzióját, amelyet teljesebben Out-of-Tree CSI Volume Plugins néven emlegetnek. .
Container Storage Interface, vagy CSI 3000 pergetőbot!
Mindenekelőtt szeretném megjegyezni, hogy a CSI nem csak egy kötet bővítmény, hanem egy igazi egyéni komponensek létrehozásáról adattárházakkal való munkavégzéshez. Az olyan konténer-hangszerelési rendszereknek, mint a Kubernetes és a Mesos, azt kellett volna „megtanulniuk”, hogyan kell dolgozni a szabvány szerint megvalósított komponensekkel. És most már megtanultam a Kuberneteset.
Mi a Kubernetes CSI-bővítményének felépítése? A CSI plugin speciális illesztőprogramokkal működik (CSI illesztőprogramok) harmadik fél fejlesztői írták. A Kubernetes CSI-illesztőprogramjának minimálisan két összetevőből (podból) kell állnia:
- ellenőr — kezeli a külső állandó tárolókat. GRPC-kiszolgálóként van megvalósítva, amelyhez a primitívet használják
StatefulSet. - Csomópont — felelős a perzisztens tárolók fürtcsomópontokhoz való csatlakoztatásáért. GRPC-szerverként is implementálva van, de a primitívet használja
DaemonSet.
Hogyan működik a CSI beépülő modul a Kubernetesben
A CSI munkájának néhány további részletét megismerheti például a „" egy éve adtuk ki.
Az ilyen megvalósítás előnyei
- Az olyan alapvető dolgokhoz, mint például az illesztőprogram regisztrálása egy csomóponthoz, a Kubernetes fejlesztői konténerkészletet implementáltak. Többé nem kell saját maga generálnia a képességekkel rendelkező JSON-választ, ahogyan azt a Flexvolume beépülő modul esetében tette.
- A végrehajtható fájlok csomópontokra „csúsztatása” helyett mostantól podokat töltünk fel a fürtbe. Kezdetben ezt várjuk el a Kubernetestől: minden folyamat a Kubernetes primitívekkel telepített konténerekben történik.
- Többé nem kell RPC-kiszolgálót és RPC-klienst fejlesztenie az összetett illesztőprogramok megvalósításához. Az ügyfelet a Kubernetes fejlesztői valósították meg számunkra.
- Az argumentumok átadása a gRPC protokollon keresztül sokkal kényelmesebb, rugalmasabb és megbízhatóbb, mint parancssori argumentumokon keresztül. Ha szeretné megérteni, hogyan adható hozzá a mennyiséghasználati mutatók támogatása a CSI-hez szabványosított gRPC-módszer hozzáadásával, olvassa el a következőket: vsphere-csi driverhez.
- A kommunikáció IPC-aljzatokon keresztül történik, hogy ne legyen összetéveszthető, hogy a kubelet a megfelelő podra küldte-e a kérést.
Emlékeztet valamire ez a lista? A CSI előnyei a következők ugyanazokat a problémákat megoldani, amelyeket nem vettünk figyelembe a Flexvolume bővítmény fejlesztésekor.
Álláspontja
A CSI-t, mint szabványt az adattárházakkal való interakcióhoz szükséges egyéni bővítmények implementálására, a közösség nagyon meleg fogadtatásban részesítette. Sőt, előnyeik és sokoldalúságuk miatt a CSI illesztőprogramokat még az olyan tárolórendszerekhez is hozzák létre, mint a Ceph vagy az AWS EBS, amelyekhez a Kubernetes legelső verziójában adták hozzá a munkavégzéshez szükséges beépülő modulokat.
2019 elején a fán belüli bővítmények . Terveink szerint továbbra is támogatjuk a Flexvolume bővítményt, de nem fejlesztünk hozzá új funkciókat.
Mi magunk már rendelkezünk tapasztalattal a ceph-csi, vsphere-csi használatában, és készek vagyunk kiegészíteni ezt a listát! A CSI eddig nagy lendülettel birkózik meg a rábízott feladatokkal, de majd meglátjuk.
Ne felejtsd el, hogy minden új a régi jó újragondolása!
PS
Olvassa el blogunkon is:
- «";
- «";
- «".
Forrás: will.com