Kui Kubernetes oli veel v1.0.0, olid olemas mahupluginad. Neid oli vaja süsteemide ühendamiseks Kubernetesiga püsivate (püsivate) konteineriandmete salvestamiseks. Nende arv oli väike ja esimeste seas olid sellised salvestusteenuste pakkujad nagu GCE PD, Ceph, AWS EBS jt.
Pluginad tarniti koos Kubernetesega, mistõttu nad said oma nime - puus. Paljude jaoks osutus aga olemasolev selliste pistikprogrammide komplekt ebapiisavaks. Käsitöölised lisasid Kubernetese tuumale plaastrite abil lihtsaid pistikprogramme, misjärel panid nad kokku oma Kubernetese ja installisid selle oma serveritesse. Kuid aja jooksul said Kubernetese arendajad sellest aru kala probleemi ei saa lahendada. Inimesed vajavad õngeritv. Kubernetes v1.2.0 väljalaskes ilmus...
Flexvolume plugin: minimaalne õngeritv
Kubernetese arendajad lõid FlexVolume'i pistikprogrammi, mis oli muutujate ja meetodite loogiline raamistik Flexvolume'i draiveritega töötamiseks, mille on rakendanud kolmandate osapoolte arendajad.
Peatume ja vaatame lähemalt, mis on FlexVolume'i draiver. See on kindel käivitatav fail (binaarfail, Pythoni skript, Bashi skript jne), mis käivitamisel võtab sisendiks käsurea argumendid ja tagastab eelnevalt teadaolevate väljadega sõnumi JSON-vormingus. Kokkuleppeliselt on esimene käsurea argument alati meetod ja ülejäänud argumendid on selle parameetrid.
Ühendusskeem CIFS-i aktsiate jaoks OpenShiftis. Flexvolume Driver – otse kesklinnas
Minimaalne meetodite komplekt näeb välja selline:
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}
}
Meetodite kasutamine attach и detach määrab stsenaariumi, mille kohaselt kubelet edaspidi draiverile helistades tegutseb. On ka spetsiaalseid meetodeid expandvolume и expandfs, mis vastutavad helitugevuse dünaamilise suuruse muutmise eest.
Näitena meetodi lisatavatest muudatustest expandvolume, ja sellega saate reaalajas mahtude suurust muuta, millega saate tutvuda aastal Rook Ceph Operator.
Ja siin on näide Flexvolume'i draiveri rakendamisest NFS-iga töötamiseks:
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 1Nii et pärast tegeliku käivitatava faili ettevalmistamist peate seda tegema laadige draiver Kubernetese klastrisse. Draiver peab asuma igas klastri sõlmes vastavalt etteantud teele. Vaikimisi valiti see:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/
... aga erinevate Kubernetese distributsioonide (OpenShift, Rancher...) kasutamisel võib tee olla erinev.
Flexvolume probleemid: kuidas õngeritva õigesti visata?
Flexvolume'i draiveri üleslaadimine klastri sõlmedesse osutus mittetriviaalseks ülesandeks. Olles toimingu ühe korra käsitsi teinud, on lihtne kokku puutuda olukorraga, kus klastrisse tekivad uued sõlmed: uue sõlme lisamise, automaatse horisontaalse skaleerimise või - mis veel hullem - sõlme väljavahetamise tõttu rikke tõttu. Sel juhul tuleks nende sõlmede salvestusega tööd teha on võimatu, kuni lisate neile ikkagi käsitsi Flexvolume'i draiveri.
Selle probleemi lahendus oli üks Kubernetese primitiividest - DaemonSet. Kui klastris ilmub uus sõlm, sisaldab see automaatselt meie DaemonSeti kausta, mille külge kinnitatakse Flexvolume'i draiverite leidmiseks kohalik köide. Eduka loomise korral kopeerib pod draiveri töötamiseks vajalikud failid kettale.
Siin on näide sellisest DaemonSetist Flexvolume'i pistikprogrammi loomiseks:
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>... ja Bashi skripti näide Flexvolume'i draiveri paigutamiseks:
#!/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
doneOluline on mitte unustada, et kopeerimisoperatsioon ei ole aatomiline. On suur tõenäosus, et kubelet hakkab draiverit kasutama enne, kui selle ettevalmistamise protsess on lõppenud, põhjustades süsteemi kokkujooksmise. Õige lähenemisviis on esmalt kopeerida draiverifailid teise nime all ja seejärel kasutada ümbernimetamistoimingut.
Cephiga töötamise skeem Rooki operaatoris: skeemil olev Flexvolume'i draiver asub Rooki agendi sees
Järgmine probleem Flexvolume'i draiverite kasutamisel on enamiku klastri sõlme salvestusruumi jaoks selleks tuleb installida vajalik tarkvara (näiteks Ceph-i ühine pakett). Esialgu polnud Flexvolume'i pistikprogramm mõeldud selliste keerukate süsteemide rakendamiseks.
Selle probleemi originaalset lahendust saab näha Rooki operaatori Flexvolume'i draiverirakenduses:
Draiver ise on loodud RPC kliendina. Side jaoks mõeldud IPC-pesa asub draiveri endaga samas kataloogis. Mäletame, et draiverifailide kopeerimiseks oleks hea kasutada DaemonSeti, mis ühendab kataloogi draiveriga köitena. Pärast vajalike vankridraiveri failide kopeerimist see pod ei sure, vaid ühendub täieõigusliku RPC-serverina läbi lisatud helitugevuse IPC pesaga. Ceph-common pakett on juba kauna konteinerisse paigaldatud. IPC-pesa tagab, et kubelet suhtleb täpselt samas sõlmes asuva podiga. Kõik geniaalne on lihtne!...
Hüvasti, meie südamlikud... puusisesed pistikprogrammid!
Kubernetese arendajad avastasid, et südamikus on talletamiseks mõeldud pistikprogramme kakskümmend. Ja muutus igaühes neist ühel või teisel viisil läbib kogu Kubernetese väljalasketsükli.
Selgub, et salvestusplugina uue versiooni kasutamiseks peate värskendama kogu klastrit. Lisaks võite olla üllatunud, et Kubernetese uus versioon muutub ootamatult teie kasutatava Linuxi tuumaga kokkusobimatuks... Nii et pühite pisarad käest ja kooskõlastate hambaid kiristades oma juhtkonna ja kasutajatega aega, värskendage Linuxi tuuma ja Kubernetese klastrit. Võimalike seisakutega teenuste osutamisel.
Olukord on enam kui koomiline, kas sa ei arva? Kogu kogukonnale sai selgeks, et lähenemine ei tööta. Tahtliku otsusega teatavad Kubernetese arendajad, et uusi salvestusruumiga töötamiseks mõeldud pluginaid enam kernelisse vastu ei võeta. Lisaks, nagu me juba teame, tuvastati Flexvolume'i pistikprogrammi rakendamisel mitmeid puudusi...
Kubernetese köidete uusim lisatud pistikprogramm CSI kutsuti üles probleemi püsiva andmesalvestusega lõplikult lõpetama. Väljaandes teatati selle alfaversioonist, mida täpsemalt nimetatakse puuvälisteks CSI helitugevuse pistikprogrammideks .
Container Storage Interface ehk CSI 3000 ketrusvarras!
Kõigepealt tahaksin märkida, et CSI pole lihtsalt helitugevuse pistikprogramm, vaid päris kohandatud komponentide loomise kohta andmeladudega töötamiseks. Konteinerite orkestreerimissüsteemid, nagu Kubernetes ja Mesos, pidid "õppima" selle standardi kohaselt rakendatud komponentidega töötama. Ja nüüd olen Kubernetes juba õppinud.
Milline on Kubernetese CSI-plugina struktuur? CSI plugin töötab spetsiaalsete draiveritega (CSI draiverid), mille on kirjutanud kolmandatest osapooltest arendajad. Kubernetese CSI-draiver peaks koosnema minimaalselt kahest komponendist (poodidest):
- kontroller — haldab väliseid püsivaid salvestusi. See on realiseeritud gRPC-serverina, mille jaoks kasutatakse primitiivi
StatefulSet. - sõlme — vastutab püsiva salvestusruumi paigaldamise eest klastri sõlmedesse. Seda rakendatakse ka gRPC-serverina, kuid see kasutab primitiivset
DaemonSet.
Kuidas CSI pistikprogramm Kubernetesis töötab
Mõne muu CSI töö üksikasja kohta saate teada näiteks artiklist "" avaldasime aasta tagasi.
Sellise teostuse eelised
- Põhiliste asjade jaoks, nagu sõlme draiveri registreerimine, rakendasid Kubernetese arendajad konteinerite komplekti. Te ei pea enam ise JSON-vastust koos võimalustega genereerima, nagu seda tehti Flexvolume'i pistikprogrammi puhul.
- Selle asemel, et käivitatavaid faile sõlmedesse libistada, laadime nüüd kaunad klastrisse üles. See on see, mida me Kuberneteselt algselt ootame: kõik protsessid toimuvad Kubernetese primitiivide abil juurutatud konteinerites.
- Keeruliste draiverite juurutamiseks ei pea te enam arendama RPC-serverit ja RPC-klienti. Kliendi juurutasid meie jaoks Kubernetese arendajad.
- Argumentide edastamine gRPC-protokolli töötamiseks on palju mugavam, paindlikum ja usaldusväärsem kui nende edastamine käsurea argumentide kaudu. Et mõista, kuidas lisada CSI-le mahukasutusmõõdikute tugi standardiseeritud gRPC-meetodi lisamise kaudu, lugege järgmist. vsphere-csi draiveri jaoks.
- Side toimub IPC-pesade kaudu, et mitte segadusse jääda, kas kubelet saatis päringu õigesse kausta.
Kas see nimekiri tuletab teile midagi meelde? CSI eelised on neid samu probleeme lahendada, mida Flexvolume'i pistikprogrammi väljatöötamisel arvesse ei võetud.
Järeldused
CSI kui andmeladudega suhtlemise kohandatud pistikprogrammide juurutamise standard võeti kogukonna poolt väga soojalt vastu. Lisaks luuakse nende eeliste ja mitmekülgsuse tõttu CSI-draiverid isegi selliste salvestussüsteemide jaoks nagu Ceph või AWS EBS, millega töötamiseks mõeldud pistikprogrammid lisati Kubernetese kõige esimeses versioonis.
2019. aasta alguses puusisesed pistikprogrammid . Plaanime jätkata Flexvolume'i pistikprogrammi toetamist, kuid ei arenda selle jaoks uusi funktsioone.
Meil endal on juba ceph-csi, vsphere-csi kasutamise kogemus ja oleme valmis seda nimekirja täiendama! Siiani saab CSI talle pandud ülesannetega hiilgavalt hakkama, kuid ootame ja vaatame.
Ära unusta, et kõik uus on hea vana ümbermõte!
PS
Loe ka meie blogist:
- «";
- «";
- «'.
Allikas: www.habr.com