Dema ku Kubernetes hîna jî v1.0.0 bû, pêvekên volumê hebûn. Ew hewce bûn ku pergalên bi Kubernetes ve girêdin ji bo hilanîna daneyên konteynerê domdar (daîmî). Hejmara wan hindik bû, û di nav yên yekem de pêşkêşkerên hilanînê yên wekî GCE PD, Ceph, AWS EBS û yên din bûn.
Pêvek bi Kubernetes re hatin radest kirin, ji ber vê yekê wan navê xwe girt - di nav darê de. Lêbelê, ji bo pir kesan, komek pêvekên weha yên heyî ne bes derket. Craftsmen pêvekên hêsan bi karanîna patches li bingeha Kubernetes zêde kirin, pişt re wan Kubernetesên xwe berhev kirin û li ser serverên xwe saz kirin. Lê bi demê re, pêşdebirên Kubernetes ew fêm kirin masî pirsgirêk çareser nabe. Mirov hewce dike darê masîvaniyê. Û di berdana Kubernetes v1.2.0 de xuya bû ...
Pêveka Flexvolume: çolê masîgiriyê ya hindiktirîn
Pêşdebirên Kubernetes pêveka FlexVolume afirandin, ku çarçoveyek mentiqî ya guhêrbar û awayên xebata bi ajokarên Flexvolume re bû ku ji hêla pêşdebirên partiya sêyemîn ve hatî bicîh kirin.
Ka em rawestin û ji nêz ve binihêrin ka ajokarê FlexVolume çi ye. Ev teqez e pelê îcrakar (pelê binary, skrîpta Python, skrîpta Bash, hwd.), ku dema ku were darve kirin, argumanên rêzika fermanê wekî têketinê digire û peyamek bi qadên berê-naskirî di formata JSON de vedigerîne. Li gorî peymanê, argumana rêza fermanê ya yekem her gav rêbazek e, û argumanên mayî pîvanên wê ne.
Diagrama girêdanê ya ji bo Parvekirinên CIFS di OpenShift de. Flexvolume Driver - Rast li Navendê
Rêbazên herî kêm vî rengî dibîne:
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}
}
Bikaranîna Rêbazan attach и detach dê senaryoya ku kubelet di pêşerojê de dema ku bang li ajokerê bike dê diyar bike. Rêbazên taybetî jî hene expandvolume и expandfs, yên ku ji bo dînamîk guheztina mezinahiyê berpirsiyar in.
Wek mînakek guhertinên ku rêbaz lê zêde dike expandvolume, û bi wê re şiyana ku hûn di wextê rast de mezinahiya cildan biguherînin, hûn dikarin xwe pê nas bikin li Rook Ceph Operator.
Va ye mînakek pêkanîna ajokera Flexvolume ji bo xebata bi NFS re:
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 1Ji ber vê yekê, piştî ku hûn pelê rastkirî yê rast amade bikin, hûn hewce ne ajokerê li koma Kubernetes barkirin. Pêdivî ye ku ajokar li ser her girêkek komê li gorî rêyek pêşwext were bicîh kirin. Ji hêla xwerû ve hatî hilbijartin:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/
... lê dema ku dabeşên cûda yên Kubernetes bikar tînin (OpenShift, Rancher...) dibe ku rê cûda be.
Pirsgirêkên Flexvolume: meriv çawa gopalê masîgiriyê rast bavêje?
Barkirina ajokera Flexvolume li girêkên komê wekî karekî ne-tawan derket. Piştî ku operasyon carekê bi destan hat kirin, hêsan e ku meriv rastî rewşek were ku girêkên nû di komê de xuya dibin: ji ber lêzêdekirina girêkek nû, pîvandina otomatîkî ya horizontî, an - ya xerabtir - veguheztina girêkek ji ber xeletiyekê. Di vê rewşê de, divê xebata bi hilanînê li ser van girêkan were kirin nabe, heta ku hûn hîn bi destan ajokera Flexvolume li wan zêde bikin.
Çareseriya vê pirsgirêkê yek ji primitives Kubernetes bû - DaemonSet. Dema ku girêkek nû di komê de xuya dibe, ew bixweber ji DaemonSet-a me podek vedihewîne, ku li ser rêyê cildek herêmî tê girêdan da ku ajokarên Flexvolume bibîne. Piştî afirandina serketî, pod pelên pêwîst ji bo ku ajoker li ser dîskê bixebite kopî dike.
Li vir mînakek DaemonSet-ek wusa ye ji bo danîna pêvekek Flexvolume:
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>... û mînakek nivîsarek Bash ji bo danîna ajokera Flexvolume:
#!/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
doneGirîng e ku meriv operasyona kopîkirinê ji bîr neke ne atomî ye. Derfetek mezin heye ku kubelet berî ku pêvajoya dabînkirina wê temam bibe dest bi karanîna ajokerê bike, ku bibe sedema têkçûna pergalê. Nêzîkatiya rast ev e ku meriv pêşî pelên ajokerê di bin navek cûda de kopî bike, û dûv re operasyonek nûvekirina atomî bikar bîne.
Diagrama xebata bi Ceph re di operatorê Rook de: ajokera Flexvolume di diagramê de di hundurê nûnerê Rook de ye.
Pirsgirêka din dema ku ajokarên Flexvolume bikar tînin ev e ku ji bo piraniya hilanînê li ser girêkek komê ye ji bo vê divê nermalava pêwîst bê sazkirin (mînak, pakêta ceph-hevbeş ji bo Ceph). Di destpêkê de, pêveka Flexvolume ji bo pêkanîna pergalên wusa tevlihev nehat sêwirandin.
Ji bo vê pirsgirêkê çareseriyek orîjînal dikare di pêkanîna ajokera Flexvolume ya operator Rook de were dîtin:
Ajokar bixwe wekî xerîdarek RPC-ê hatî sêwirandin. Soketa IPC ya ji bo ragihandinê di heman pelrêça ku ajokar bixwe ye de ye. Em bi bîr tînin ku ji bo kopîkirina pelên ajokerê baş e ku meriv DaemonSet bikar bîne, ku pelrêça bi ajokerê re wekî cildekê girêdide. Piştî kopîkirina pelên ajokera rookê ya pêwîst, ev pod namire, lê bi navgîniya pêvekirî ve wekî serverek RPC-ya bêkêmasî bi soketa IPC ve tê girêdan. Pakêta ceph-common jixwe di hundurê konteynera pod de hatî saz kirin. Soketa IPC piştrast dike ku kubelet dê tam bi podê ku li ser heman nodê ye re têkilî daynin. Her tişt aqilmend hêsan e!..
Bi xatirê te, pêvekên me yên delal... nav darê!
Pêşdebirên Kubernetes kifş kirin ku hejmara pêvekên ji bo hilanînê di hundurê bingehîn de bîst e. Û guhertinek di her yek ji wan de, bi awayek an yekî din, di çerxa serbestberdana tevahî ya Kubernetes re derbas dibe.
Derket holê ku ji bo karanîna guhertoya nû ya pêveka hilanînê, hûn hewce ne ku tevahiya komê nûve bikin. Ji bilî vê, dibe ku hûn şaş bimînin ku guhertoya nû ya Kubernetes dê ji nişka ve bi kernel Linux-ê ya ku hûn bikar tînin re nehevaheng bibe... Ji ber vê yekê hûn hêsirên xwe paqij dikin û, diranên xwe diqelişînin, bi rêvebir û bikarhênerên xwe re wextê koordîne bikin. kernel Linux û koma Kubernetes nûve bikin. Di peydakirina karûbaran de bi demdirêjiya gengaz re.
Rewş ji komîktir e, hûn nafikirin? Ji hemû civakê re eşkere bû ku ev nêzîkatî bi ser nakeve. Bi biryarek dilxwazî , pêşdebirên Kubernetes ragihand ku pêvekên nû yên ji bo xebitandina hilanînê dê êdî di kernelê de neyên pejirandin. Wekî din, wekî ku em jixwe dizanin, di pêkanîna pêveka Flexvolume de gelek kêmasî hatine tespît kirin…
Pêveka herî paşîn a lêzêdekirî ya ji bo cildên li Kubernetes, CSI, hate gazî kirin ku pirsgirêk bi hilanîna daneya domdar carekê û her dem bigire. Guhertoya wê ya alpha, ku bi tevahî wekî Pluginên Volume CSI-yê Derveyî Darê tê binav kirin, di berdanê de hate ragihandin. .
Navbera hilanînê ya konteyner, an çîpek zivirîna CSI 3000!
Berî her tiştî, ez dixwazim bibînim ku CSI ne tenê pêvekek volumê ye, lê rast e li ser afirandina pêkhateyên xwerû yên ji bo xebata bi depoyên daneyê re. Diviya bû ku pergalên orkestrasyona konteyner ên wekî Kubernetes û Mesos "fêr bibin" ka meriv çawa bi pêkhateyên ku li gorî vê standardê hatine bicîh kirin re bixebite. Û niha ez jixwe Kubernetes fêr bûm.
Struktura pêveka CSI li Kubernetes çi ye? Pêveka CSI bi ajokarên taybetî re dixebite (ajokarên CSI) ji hêla pêşdebirên partiya sêyemîn ve hatî nivîsandin. Ajokerek CSI li Kubernetes divê herî kêm ji du beşan (pods) pêk were:
- Rêveber: - depoyên domdar ên derveyî îdare dike. Ew wekî serverek gRPC tête bicîh kirin, ji bo ku primitive tê bikar anîn
StatefulSet. - Node - berpirsiyar e ku hilanîna domdar li girêkên komê bicîh bike. Ew wekî serverek gRPC jî tête bicîh kirin, lê ew primitive bikar tîne
DaemonSet.
Pêveka CSI-ê li Kubernetes çawa dixebite
Hûn dikarin li ser hin hûrguliyên din ên xebata CSI fêr bibin, mînakî, ji gotara "», me salek berê çap kir.
Awantajên pêkanîna wisa
- Ji bo tiştên bingehîn ên mîna qeydkirina ajokerek ji bo nodek, pêşdebirên Kubernetes komek konteyneran bicîh kirin. Naha hûn ne hewce ne ku hûn bi xwe bersivek JSON bi kapasîteyên çêbikin, wekî ku ji bo pêveka Flexvolume hate kirin.
- Li şûna ku em pelên îcrakar "bihejînin" li ser girêkan, em naha pelan li komê bar dikin. Ya ku em di destpêkê de ji Kubernetes hêvî dikin ev e: Hemî pêvajoyên di hundurê konteynerên ku bi karanîna primitivesên Kubernetes têne bicîh kirin de pêk tên.
- Hûn êdî ne hewce ne ku serverek RPC û xerîdarek RPC pêşve bibin da ku ajokarên tevlihev bicîh bikin. Xerîdar ji hêla pêşdebirên Kubernetes ve ji bo me hate bicîh kirin.
- Derbaskirina argumanan ji bo xebatê li ser protokola gRPC ji derbaskirina wan bi argumanên rêzika fermanê pir rehettir, maqûltir û pêbawertir e. Ji bo ku hûn fêm bikin ka meriv çawa bi lêzêdekirina rêbazek gRPC-ya standardkirî piştgirî ji bo metrîkên karanîna cildê li CSI zêde dike, hûn dikarin bixwînin: ji bo ajokera vsphere-csi.
- Ragihandin bi rêya soketên IPC-ê pêk tê, da ku tevlihev nebe ka kubelet daxwaz ji podê rast re şandiye an na.
Ma ev navnîş tiştek bîra we dike? Awantajên CSI hene çareserkirina heman pirsgirêkan, yên ku di dema pêşxistina pêveka Flexvolume de nehatin hesibandin.
vebiguherin
CSI wekî standardek ji bo pêkanîna pêvekên xwerû ji bo danûstendina bi wargehên daneyê re ji hêla civakê ve pir germ hate pêşwazî kirin. Digel vê yekê, ji ber avantaj û pirrengiya wan, ajokarên CSI-yê tewra ji bo pergalên hilanînê yên wekî Ceph an AWS EBS jî têne afirandin, pêvekên ji bo xebatê yên ku di guhertoya yekem a Kubernetes de hatine zêdekirin.
Di destpêka sala 2019-an de, pêvekên nav darê . Em plan dikin ku piştgiriya pêveka Flexvolume bidomînin, lê dê fonksiyonên nû ji bo wê pêşve nexin.
Em bixwe xwedan ezmûna karanîna ceph-csi, vsphere-csi heye û amade ne ku li vê navnîşê zêde bikin! Heya nuha, CSI bi peywirên ku jê re hatine peywirdarkirin bi dengek ve mijûl e, lê em ê li bendê bin û bibînin.
Ji bîr nekin ku her tiştê nû ji nû ve ramana berê ye!
PS
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «".
Source: www.habr.com