Til baka þegar Kubernetes var enn v1.0.0, voru til bindiviðbætur. Þeir voru nauðsynlegir til að tengja kerfi við Kubernetes til að geyma viðvarandi (varanleg) gámagögn. Fjöldi þeirra var lítill og meðal þeirra fyrstu voru geymsluveitendur eins og GCE PD, Ceph, AWS EBS og fleiri.
Viðbæturnar voru afhentar ásamt Kubernetes, þess vegna fengu þau nafnið sitt - í tré. Hins vegar, fyrir marga, reyndist núverandi sett af slíkum viðbótum ófullnægjandi. Iðnaðarmenn bættu einföldum viðbótum við Kubernetes kjarnann með því að nota plástra, eftir það settu þeir saman sína eigin Kubernetes og settu upp á netþjóna sína. En með tímanum áttuðu verktaki Kubernetes sig á því fiskur vandamálið er ekki hægt að leysa. Fólk þarf veiðistöng. Og í útgáfu Kubernetes v1.2.0 virtist...
Flexvolume viðbót: lágmarks veiðistöng
Kubernetes forritarar bjuggu til FlexVolume viðbótina, sem var rökrétt rammi af breytum og aðferðum til að vinna með Flexvolume rekla útfærð af þriðja aðila verktaki.
Stoppum og skoðum nánar hvað FlexVolume driverinn er. Þetta er víst keyranleg skrá (tvíundarskrá, Python script, Bash script, osfrv.), sem, þegar það er keyrt, tekur skipanalínubreytur sem inntak og skilar skilaboðum með fyrirfram þekktum reitum á JSON sniði. Samkvæmt venju eru fyrstu skipanalínurökin alltaf aðferð og þau rök sem eftir eru eru færibreytur hennar.
Tengimynd fyrir CIFS hlutabréf í OpenShift. Flexvolume bílstjóri - beint í miðjunni
Lágmarkssett af aðferðum lítur svona út:
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}
}
Að nota aðferðir attach и detach mun skilgreina atburðarásina þar sem kubelet mun starfa í framtíðinni þegar hringt er í ökumanninn. Það eru líka sérstakar aðferðir expandvolume и expandfs, sem bera ábyrgð á því að breyta stærð hljóðstyrksins á virkan hátt.
Sem dæmi um þær breytingar sem aðferðin bætir við expandvolume, og þar með getu til að breyta stærð bindi í rauntíma, þú getur kynnt þér í Rook Ceph Operator.
Og hér er dæmi um útfærslu Flexvolume bílstjórans til að vinna með 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 1Svo, eftir að hafa undirbúið raunverulegu keyrsluskrána, þarftu að hladdu upp bílstjóranum í Kubernetes þyrpinguna. Ökumaðurinn verður að vera staðsettur á hverjum klasahnút samkvæmt fyrirfram ákveðinni slóð. Sjálfgefið var valið:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/
... en þegar mismunandi Kubernetes dreifingar eru notaðar (OpenShift, Rancher...) getur slóðin verið önnur.
Flexvolume vandamál: hvernig á að kasta veiðistöng rétt?
Upphleðsla Flexvolume rekilsins á klasahnúta reyndist vera ekki léttvægt verkefni. Eftir að hafa gert aðgerðina handvirkt einu sinni er auðvelt að lenda í aðstæðum þar sem nýir hnútar birtast í þyrpingunni: vegna þess að nýjum hnút er bætt við, sjálfvirkri láréttri stærðargráðu eða - það sem verra er - skipt um hnút vegna bilunar. Í þessu tilviki ætti að vinna með geymsluna á þessum hnútum er ómögulegt, þar til þú bætir samt handvirkt Flexvolume reklum við þá.
Lausnin á þessu vandamáli var ein af frumstæðum Kubernetes - DaemonSet. Þegar nýr hnút birtist í þyrpingunni inniheldur hann sjálfkrafa belg úr DaemonSet okkar, sem staðbundið bindi er tengt við meðfram leiðinni til að finna Flexvolume rekla. Þegar búið er til vel afritar hólfið nauðsynlegar skrár til að ökumaðurinn virki á diskinn.
Hér er dæmi um slíkt DaemonSet til að setja upp Flexvolume viðbót:
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>... og dæmi um Bash handrit til að setja upp Flexvolume rekla:
#!/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Það er mikilvægt að gleyma því að afritunaraðgerðin er ekki atómbundið. Það eru miklar líkur á því að kubelet byrji að nota ökumanninn áður en úthlutunarferli þess er lokið, sem veldur því að kerfið hrynur. Rétta aðferðin er að afrita fyrst ökumannsskrárnar undir öðru nafni og nota síðan atómendurnefnaaðgerð.
Skýringarmynd um að vinna með Ceph í Rook rekstraraðilanum: Flexvolume driverinn á skýringarmyndinni er staðsettur inni í Rook umboðsmanninum
Næsta vandamál þegar þú notar Flexvolume rekla er það fyrir flestar geymslur á klasahnút þarf að setja upp nauðsynlegan hugbúnað fyrir þetta (td ceph-common pakkann fyrir Ceph). Upphaflega var Flexvolume viðbótin ekki hönnuð til að innleiða svo flókin kerfi.
Upprunalega lausn á þessu vandamáli má sjá í Flexvolume rekla útfærslu Rook rekstraraðilans:
Ökumaðurinn sjálfur er hannaður sem RPC viðskiptavinur. IPC-innstungan fyrir samskipti er staðsett í sömu möppu og bílstjórinn sjálfur. Við munum að til að afrita ökumannsskrár væri gott að nota DaemonSet, sem tengir möppuna við ökumanninn sem bindi. Eftir að hafa afritað nauðsynlegar ökumannsskrár fyrir hrók, deyr þessi belg ekki, heldur tengist IPC-innstungunni í gegnum meðfylgjandi bindi sem fullgildur RPC-þjónn. Ceph-common pakkinn er þegar uppsettur inni í belgílátinu. IPC innstungan tryggir að kubelet muni hafa samskipti við nákvæmlega fræbelginn sem er staðsettur á sama hnút. Allt sniðugt er einfalt! ..
Bless, ástúðleg...in-tree viðbætur okkar!
Hönnuðir Kubernetes komust að því að fjöldi viðbóta fyrir geymslu innan kjarnans er tuttugu. Og breyting á hverri þeirra, á einn eða annan hátt, fer í gegnum alla Kubernetes útgáfuferilinn.
Það kemur í ljós að til að nota nýju útgáfuna af geymsluviðbótinni, þú þarft að uppfæra allan klasann. Auk þessa gætirðu verið hissa á því að nýja útgáfan af Kubernetes verði skyndilega ósamrýmanleg Linux kjarnanum sem þú ert að nota... Þannig að þú þurrkar tárin þín og gnístir tönnum, samhæfir stjórnendum þínum og notendum tíma til að uppfærðu Linux kjarnann og Kubernetes þyrpinguna. Með mögulegum niðritíma í veitingu þjónustu.
Ástandið er meira en kómískt, finnst þér ekki? Samfélaginu öllu varð ljóst að aðferðin virkaði ekki. Með vísvitandi ákvörðun tilkynna verktaki Kubernetes að ný viðbætur til að vinna með geymslu verði ekki lengur samþykktar í kjarnanum. Að auki, eins og við vitum nú þegar, komu fram nokkrir annmarkar við innleiðingu Flexvolume viðbótarinnar...
Nýjasta viðbótin sem bætt var við fyrir bindi í Kubernetes, CSI, var kölluð til að loka málinu með viðvarandi gagnageymslu í eitt skipti fyrir öll. Alfa útgáfa hennar, nánar nefnd Out-of-Tree CSI Volume Plugins, var tilkynnt í útgáfunni .
Container Storage Interface, eða CSI 3000 snúningsstöng!
Fyrst af öllu vil ég taka fram að CSI er ekki bara hljóðstyrkstapp heldur raunverulegt um að búa til sérsniðna íhluti til að vinna með gagnavöruhús. Gámaskipunarkerfi eins og Kubernetes og Mesos áttu að „læra“ hvernig á að vinna með íhluti sem eru útfærðir samkvæmt þessum staðli. Og nú hef ég þegar lært Kubernetes.
Hver er uppbygging CSI viðbótarinnar í Kubernetes? CSI viðbótin virkar með sérstökum reklum (CSI bílstjóri) skrifað af þriðja aðila verktaki. CSI bílstjóri í Kubernetes ætti að lágmarki að samanstanda af tveimur hlutum (belg):
- Controller - stjórnar ytri viðvarandi geymslum. Það er útfært sem gRPC þjónn, sem frumefnið er notað fyrir
StatefulSet. - Hnút — er ábyrgur fyrir því að festa viðvarandi geymslu á klasahnúta. Það er einnig útfært sem gRPC þjónn, en það notar frumstæðuna
DaemonSet.
Hvernig CSI viðbótin virkar í Kubernetes
Þú getur lært um nokkrar aðrar upplýsingar um starf CSI, til dæmis í greininni "' við birtum fyrir ári síðan.
Kostir slíkrar framkvæmdar
- Fyrir grunnatriði eins og að skrá bílstjóri fyrir hnút, innleiddu Kubernetes verktaki sett af ílátum. Þú þarft ekki lengur að búa til JSON svar með getu sjálfur, eins og gert var fyrir Flexvolume viðbótina.
- Í stað þess að „renna“ keyrsluskrám inn á hnúta, hleðum við nú upp belg í þyrpinguna. Þetta er það sem við upphaflega búumst við frá Kubernetes: öll ferli eiga sér stað inni í gámum sem notuð eru með Kubernetes frumstæðum.
- Þú þarft ekki lengur að þróa RPC netþjón og RPC viðskiptavin til að innleiða flókna rekla. Viðskiptavinurinn var útfærður fyrir okkur af Kubernetes verktaki.
- Það er miklu þægilegra, sveigjanlegra og áreiðanlegra að senda rök til að vinna yfir gRPC samskiptareglur en að koma þeim í gegnum skipanalínurök. Til að skilja hvernig á að bæta við stuðningi við magnnotkunarmælingar við CSI með því að bæta við staðlaðri gRPC aðferð geturðu lesið: fyrir vsphere-csi bílstjóri.
- Samskipti eiga sér stað í gegnum IPC-innstungur, svo að ekki verði ruglað saman hvort kubelet hafi sent beiðnina á réttan pod.
Minnir þessi listi þig á eitthvað? Kostir CSI eru að leysa sömu vandamálin, sem ekki var tekið tillit til við þróun Flexvolume viðbótarinnar.
Niðurstöður
CSI sem staðall til að innleiða sérsniðnar viðbætur til að hafa samskipti við gagnageymslur var mjög vel tekið af samfélaginu. Þar að auki, vegna kosta þeirra og fjölhæfni, eru CSI reklar búnir til jafnvel fyrir geymslukerfi eins og Ceph eða AWS EBS, viðbætur til að vinna með sem var bætt við í fyrstu útgáfu Kubernetes.
Í byrjun árs 2019, viðbætur í tré . Við ætlum að halda áfram að styðja við Flexvolume viðbótina, en munum ekki þróa nýja virkni fyrir það.
Við höfum sjálf þegar reynslu af því að nota ceph-csi, vsphere-csi og erum tilbúin að bæta við þennan lista! Hingað til er CSI að takast á við verkefnin sem henni eru úthlutað með hvelli, en við munum bíða og sjá.
Ekki gleyma því að allt nýtt er góð endurhugsun á því gamla!
PS
Lestu líka á blogginu okkar:
- «»;
- «»;
- «'.
Heimild: www.habr.com