Reen kiam Kubernetes ankoraŭ estis v1.0.0, ekzistis volumenaj kromaĵoj. Ili estis bezonataj por konekti sistemojn al Kubernetes por stoki konstantajn (konstantajn) ujajn datumojn. Ilia nombro estis malgranda, kaj inter la unuaj estis tiaj stokadprovizantoj kiel GCE PD, Ceph, AWS EBS kaj aliaj.
La kromaĵojn estis liveritaj kune kun Kubernetes, tial ili ricevis sian nomon - en-arbo. Tamen, por multaj, la ekzistanta aro de tiaj aldonaĵoj montriĝis nesufiĉa. Metiistoj aldonis simplajn kromaĵojn al la kerno de Kubernetes uzante diakilojn, post kio ili kunvenis sian propran Kubernetes kaj instalis ĝin sur siaj serviloj. Sed kun la tempo, la programistoj de Kubernetes rimarkis tion fiŝoj la problemo ne povas esti solvita. Homoj bezonas fiŝkaptilo. Kaj en la eldono de Kubernetes v1.2.0 ĝi aperis...
Flexvolume kromaĵo: minimuma fiŝkano
Kubernetes-programistoj kreis la FlexVolume-aldonaĵon, kio estis logika kadro de variabloj kaj metodoj por labori kun Flexvolume-ŝoforoj efektivigitaj de triapartaj programistoj.
Ni haltu kaj rigardu pli detale, kio estas la ŝoforo FlexVolume. Ĉi tio estas certa rulebla dosiero (binara dosiero, Python-skripto, Bash-skripto, ktp.), kiu, kiam ĝi estas efektivigita, prenas komandliniajn argumentojn kiel enigaĵon kaj resendas mesaĝon kun antaŭkonataj kampoj en JSON-formato. Laŭ konvencio, la unua komandlinia argumento ĉiam estas metodo, kaj la ceteraj argumentoj estas ĝiaj parametroj.
Konektdiagramo por CIFS-akcioj en OpenShift. Flexvolume Driver - Ĝuste en la Centro
Minimuma aro de metodoj similas ĉi tion:
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}
}
Uzante Metodojn attach и detach difinos la scenaron en kiu la kubelet agos estonte kiam vokos la ŝoforon. Estas ankaŭ specialaj metodoj expandvolume и expandfs, kiuj respondecas pri dinamike regrandigi la volumon.
Kiel ekzemplo de la ŝanĝoj kiujn la metodo aldonas expandvolume, kaj kun ĝi la kapablo regrandigi volumojn en reala tempo, vi povas konatiĝi kun en Rook Ceph Operator.
Kaj jen ekzemplo de la efektivigo de la ŝoforo Flexvolume por labori kun 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 1Do, post preparado de la efektiva rulebla dosiero, vi devas alŝutu la ŝoforon al la Kubernetes-grupo. La ŝoforo devas troviĝi sur ĉiu aretnodo laŭ antaŭdestinita vojo. Defaŭlte ĝi estis elektita:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/
... sed kiam oni uzas malsamajn distribuojn de Kubernetes (OpenShift, Rancher...) la vojo povas esti malsama.
Flexvolume-problemoj: kiel ĝuste gisi fiŝkanon?
Alŝuti la Flexvolume-ŝoforon al clusternodoj montriĝis ne-triviala tasko. Farinte la operacion permane unufoje, estas facile renkonti situacion kie novaj nodoj aperas en la areto: pro aldono de nova nodo, aŭtomata horizontala skalo, aŭ - kio estas pli malbona - anstataŭigo de nodo pro misfunkcio. En ĉi tiu kazo, laboro kun la stokado sur ĉi tiuj nodoj devus esti farita estas neebla, ĝis vi ankoraŭ permane aldonas la Flexvolume-ŝoforon al ili.
La solvo al ĉi tiu problemo estis unu el la primitivuloj de Kubernetes - DaemonSet. Kiam nova nodo aperas en la areto, ĝi aŭtomate enhavas pod el nia DaemonSet, al kiu loka volumo estas alfiksita laŭ la vojo por trovi Flexvolume-ŝoforojn. Post sukcesa kreado, la pod kopias la necesajn dosierojn por ke la ŝoforo funkciu al disko.
Jen ekzemplo de tia DaemonSet por aranĝi Flexvolume kromaĵon:
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>... kaj ekzemplo de Bash-skripto por aranĝi la Flexvolume-ŝoforon:
#!/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
doneGravas ne forgesi, ke la kopia operacio ne estas atoma. Estas alta ŝanco ke la kubelet komencos uzi la ŝoforon antaŭ ol ĝia provizoprocezo finiĝos, kaŭzante la sistemon kraŝi. La ĝusta aliro estas unue kopii la ŝofordosierojn sub malsama nomo, kaj poste uzi atoman renoman operacion.
Diagramo pri laborado kun Ceph en la Rook-funkciigisto: la Flexvolume-ŝoforo en la diagramo situas ene de la Rook-agento
La sekva problemo dum uzado de Flexvolume-ŝoforoj estas tio por plej multe de la stokado sur grapolnodo la necesa programaro por tio devas esti instalita (ekzemple, la ceph-komuna pakaĵo por Ceph). Komence, la aldonaĵo Flexvolume ne estis dizajnita por efektivigi tiajn kompleksajn sistemojn.
Originala solvo al ĉi tiu problemo videblas en la efektivigo de la ŝoforo Flexvolume de la telefonisto Rook:
La ŝoforo mem estas desegnita kiel RPC-kliento. La IPC-ingo por komunikado situas en la sama dosierujo kiel la ŝoforo mem. Ni memoras, ke por kopii ŝofordosierojn estus bone uzi DaemonSet, kiu ligas la dosierujon kun la ŝoforo kiel volumo. Post kopiado de la necesaj rook-ŝofordosieroj, ĉi tiu pod ne mortas, sed konektas al la IPC-ingo tra la kunsenda volumeno kiel plentaŭga RPC-servilo. La pako ceph-common jam estas instalita ene de la podujo. La IPC-ingo certigas, ke la kubelet komunikados kun ĝuste la pod, kiu situas sur la sama nodo. Ĉio sprita estas simpla!...
Adiaŭ, niaj amaj... en-arbaj kromprogramoj!
Kubernetes-programistoj malkovris, ke la nombro da kromprogramoj por stokado ene de la kerno estas dudek. Kaj ŝanĝo en ĉiu el ili, laŭ unu maniero aŭ alia, trairas la plenan eldonciklon de Kubernetes.
Rezultas, ke por uzi la novan version de la stokada kromaĵo, vi devas ĝisdatigi la tutan areton. Aldone al tio, vi eble surpriziĝos, ke la nova versio de Kubernetes subite fariĝos malkongrua kun la Linukso-kerno, kiun vi uzas... Do vi viŝas viajn larmojn kaj, kunpreminte viajn dentojn, kunordigas kun via administrado kaj uzantoj la tempon por ĝisdatigi la Linuksan kernon kaj Kubernetes-areton. Kun ebla malfunkcio en la liverado de servoj.
La situacio estas pli ol komika, ĉu vi ne pensas? Evidentiĝis al la tuta komunumo, ke la aliro ne funkciis. Per intenca decido, Kubernetes-programistoj anoncas, ke novaj kromprogramoj por labori kun stokado ne plu estos akceptitaj en la kernon. Krome, kiel ni jam scias, kelkaj mankoj estis identigitaj en la efektivigo de la kromaĵo Flexvolume...
La plej nova aldonita kromaĵo por volumoj en Kubernetes, CSI, estis vokita por fermi la aferon per konstanta datumstokado unufoje por ĉiam. Ĝia alfa-versio, pli plene referita kiel Out-of-Tree CSI Volume Plugins, estis sciigita en la eldono .
Container Storage Interface, aŭ CSI 3000 turniĝanta bastono!
Antaŭ ĉio, mi ŝatus rimarki, ke CSI ne estas nur voluma kromaĵo, sed reala pri kreado de kutimaj komponantoj por labori kun datumstokejoj. Uj-instrumentaj sistemoj kiel Kubernetes kaj Mesos supozis "lerni" kiel labori kun komponantoj efektivigitaj laŭ ĉi tiu normo. Kaj nun mi jam lernis Kubernetes.
Kio estas la strukturo de la CSI-kromaĵo en Kubernetes? La CSI-kromaĵo funkcias kun specialaj peliloj (CSI-ŝoforoj) verkita de triapartneraj programistoj. CSI-ŝoforo en Kubernetes devus minimume konsisti el du komponentoj (pods):
- regilo — administras eksterajn konstantajn stokaĵojn. Ĝi estas efektivigita kiel gRPC-servilo, por kiu la primitivo estas uzata
StatefulSet. - nodo — respondecas pri muntado de konstanta stokado al aretnodoj. Ĝi ankaŭ estas efektivigita kiel gRPC-servilo, sed ĝi uzas la primitivon
DaemonSet.
Kiel la CSI-kromaĵo funkcias en Kubernetes
Vi povas lerni pri iuj aliaj detaloj de la laboro de CSI, ekzemple, de la artikolo "" ni publikigis antaŭ unu jaro.
La avantaĝoj de tia efektivigo
- Por bazaj aferoj kiel registri ŝoforon por nodo, la programistoj de Kubernetes efektivigis aron da ujoj. Vi ne plu bezonas generi JSON-respondon kun kapabloj mem, kiel oni faris por la kromaĵo Flexvolume.
- Anstataŭ "gliti" ruleblajn dosierojn sur nodojn, ni nun alŝutas podojn al la areto. Jen kion ni komence atendas de Kubernetes: ĉiuj procezoj okazas ene de ujoj deplojitaj per Kubernetes-primitivoj.
- Vi ne plu bezonas evoluigi RPC-servilon kaj RPC-klienton por efektivigi kompleksajn ŝoforojn. La kliento estis efektivigita por ni de Kubernetes-programistoj.
- Pasi argumentojn por labori super la gRPC-protokolo estas multe pli oportuna, fleksebla kaj fidinda ol pasi ilin per komandliniaj argumentoj. Por kompreni kiel aldoni subtenon por volumaj uzadometrikoj al CSI aldonante normigitan gRPC-metodon, vi povas legi: por vsphere-csi-ŝoforo.
- Komunikado okazas per IPC-ingoj, por ne esti konfuzita ĉu la kubelet sendis la peton al la ĝusta podo.
Ĉu ĉi tiu listo memorigas vin pri io? La avantaĝoj de CSI estas solvante tiujn samajn problemojn, kiuj ne estis enkalkulitaj dum disvolvado de la kromaĵo Flexvolume.
trovoj
CSI kiel normo por efektivigado de kutimaj aldonaĵoj por interagado kun datumstokejoj estis tre varme ricevita de la komunumo. Krome, pro siaj avantaĝoj kaj ĉiuflankeco, CSI-ŝoforoj estas kreitaj eĉ por stokadsistemoj kiel Ceph aŭ AWS EBS, kromaĵojn por labori kun kiuj estis aldonitaj en la plej unua versio de Kubernetes.
Komence de 2019, en-arbaj kromaĵojn . Ni planas daŭre subteni la kromprogramon Flexvolume, sed ne disvolvos novajn funkciojn por ĝi.
Ni mem jam havas sperton uzante ceph-csi, vsphere-csi kaj estas pretaj aldoni al ĉi tiu listo! Ĝis nun, CSI traktas la taskojn atribuitajn al ĝi kun bruego, sed ni atendos kaj vidos.
Ne forgesu, ke ĉio nova estas bona repripenso de la malnova!
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «".
fonto: www.habr.com