Kubernetes v1.0.0 хэвээр байх үед эзлэхүүний залгаасууд байсан. Тэд байнгын (байнгын) контейнерийн өгөгдлийг хадгалахын тулд системийг Кубернетестэй холбоход хэрэгтэй байсан. Тэдний тоо цөөхөн байсан бөгөөд эхнийх нь GCE PD, Ceph, AWS EBS болон бусад хадгалах үйлчилгээ үзүүлэгчид байв.
Plugins-ийг Kubernetes-тэй хамт нийлүүлсэн тул тэд өөрсдийн нэрийг модоор авсан. Гэсэн хэдий ч олон хүмүүсийн хувьд ийм залгаасуудын одоо байгаа багц хангалтгүй байсан. Гар урчууд засваруудыг ашиглан Kubernetes-ийн цөмд энгийн залгаасуудыг нэмсэн бөгөөд үүний дараа тэд өөрсдийн Kubernetes-ийг угсарч, сервер дээрээ суулгасан. Гэвч цаг хугацаа өнгөрөхөд Kubernetes-ийн хөгжүүлэгчид үүнийг ойлгосон загас асуудлыг шийдэж чадахгүй. Хүмүүст хэрэгтэй загас барих саваа. Мөн Kubernetes v1.2.0 хувилбар дээр гарч ирэв ...
Flexvolume залгаас: хамгийн бага загас саваа
Kubernetes-ийн хөгжүүлэгчид FlexVolume залгаасыг бүтээсэн бөгөөд энэ нь гуравдагч талын хөгжүүлэгчдийн хэрэгжүүлсэн Flexvolume драйверуудтай ажиллах хувьсагч, аргуудын логик хүрээ байсан юм.
Одоо зогсоод FlexVolume драйвер гэж юу болохыг сайтар харцгаая. Энэ бол тодорхой юм гүйцэтгэх боломжтой файл (хоёртын файл, Python скрипт, Bash скрипт гэх мэт) бөгөөд үүнийг гүйцэтгэх үед командын мөрийн аргументуудыг оролт болгон авч, JSON форматаар урьдчилан мэддэг талбар бүхий мессежийг буцаадаг. Уламжлал ёсоор командын мөрийн эхний аргумент нь үргэлж арга бөгөөд үлдсэн аргументууд нь түүний параметрүүд юм.
OpenShift дээрх CIFS Share-ийн холболтын диаграм. Flexvolume драйвер - Яг төвд байна
Аргын хамгийн бага багц иймэрхүү харагдаж байна:
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}
}
Арга ашиглах attach и detach жолоочийг дуудах үед kubelet ирээдүйд ажиллах хувилбарыг тодорхойлох болно. Мөн тусгай аргууд байдаг expandvolume и expandfs, эзлэхүүнийг динамикаар өөрчлөх үүрэгтэй.
Аргын нэмсэн өөрчлөлтүүдийн жишээ болгон expandvolume, үүний тусламжтайгаар эзлэхүүний хэмжээг бодит цаг хугацаанд өөрчлөх чадвартай тул та өөрөө танилцаж болно Rook Ceph Operator-д.
NFS-тэй ажиллах Flexvolume драйверийг хэрэгжүүлэх жишээ энд байна.
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 1Тиймээс, гүйцэтгэх боломжтой файлыг бэлтгэсний дараа та хийх хэрэгтэй драйверийг Kubernetes кластерт байршуулна уу. Драйвер нь урьдчилан тодорхойлсон замын дагуу кластерын зангилаа бүр дээр байрлах ёстой. Анхдагчаар энэ нь сонгосон:
/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/
... гэхдээ өөр өөр Kubernetes түгээлтийг (OpenShift, Rancher...) ашиглах үед зам нь өөр байж болно.
Flexvolume-ийн асуудлууд: загас барих саваа хэрхэн зөв цутгах вэ?
Flexvolume драйверийг кластерийн зангилаа руу байршуулах нь тийм ч энгийн ажил биш болсон. Үйлдлийг гараар нэг удаа хийсний дараа кластерт шинэ зангилаа гарч ирэх нөхцөл байдалд амархан тулгардаг: шинэ зангилаа нэмэгдсэн, автомат хэвтээ масштабтай, эсвэл хамгийн муу нь эвдрэлийн улмаас зангилаа солигддог. Энэ тохиолдолд эдгээр зангилаанууд дээр агуулахтай ажиллах хэрэгтэй боломжгүй юм, та Flexvolume драйверийг гараар нэмэх хүртэл.
Энэ асуудлын шийдэл нь Кубернетес командуудын нэг байв. DaemonSet. Кластерт шинэ зангилаа гарч ирэхэд энэ нь манай DaemonSet-ийн pod-ыг автоматаар агуулж байдаг бөгөөд Flexvolume драйверуудыг олохын тулд зам дагуу локал эзлэхүүнийг хавсаргасан болно. Амжилттай бүтээсний дараа pod нь драйверийг диск рүү ажиллуулахад шаардлагатай файлуудыг хуулдаг.
Flexvolume залгаасыг байрлуулах ийм DaemonSet-ийн жишээ энд байна:
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>... мөн Flexvolume драйверийг байрлуулах Bash скриптийн жишээ:
#!/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Хуулбарлах ажиллагааг мартаж болохгүй атом биш. Кубелет нь хангамжийн процесс дуусахаас өмнө драйверийг ашиглаж эхлэх магадлал өндөр бөгөөд энэ нь системд алдаа гаргах болно. Зөв арга бол эхлээд драйверын файлуудыг өөр нэрээр хуулж, дараа нь атомын нэрийг өөрчлөх үйлдлийг ашиглах явдал юм.
Rook оператор дахь Ceph-тэй ажиллах диаграм: диаграм дахь Flexvolume драйвер нь Rook агент дотор байрладаг.
Flexvolume драйверуудыг ашиглах дараагийн асуудал бол кластерийн зангилаа дээрх ихэнх санах ойд зориулагдсан асуудал юм үүнд шаардлагатай програм хангамжийг суулгасан байх ёстой (жишээ нь, Ceph-д зориулсан ceph-нийтлэг багц). Эхэндээ Flexvolume залгаас нь ийм нарийн төвөгтэй системийг хэрэгжүүлэхэд зориулагдаагүй байв.
Энэ асуудлын анхны шийдлийг Rook операторын Flexvolume драйверын хэрэгжилтээс харж болно.
Драйвер нь өөрөө RPC клиент хэлбэрээр бүтээгдсэн. Харилцаа холбооны IPC залгуур нь драйвертай ижил директорт байрладаг. Драйверийн файлуудыг хуулбарлахын тулд лавлахыг драйвертай боть болгон холбодог DaemonSet-ийг ашиглах нь зүйтэй гэдгийг бид санаж байна. Шаардлагатай rook драйвер файлуудыг хуулж авсны дараа энэ pod нь үхэхгүй, харин IPC залгуурт бүрэн эрхт RPC сервер болгон холбогдсон ботьоор холбогддог. Ceph-common багцыг аль хэдийн pod савны дотор суулгасан байна. IPC залгуур нь kubelet нь нэг зангилаа дээр байрладаг подволтой яг холбогдохыг баталгаажуулдаг. Ухаантай бүхэн энгийн! ..
Баяртай, бидний хайрт ... мод доторх залгаасууд!
Kubernetes-ийн хөгжүүлэгчид цөм дотор хадгалах нэмэлт өргөтгөлүүдийн тоо хорин гэдгийг олж мэдсэн. Тэд тус бүрийн өөрчлөлт нь Кубернетес хувилбарын бүрэн мөчлөгийг дамждаг.
Хадгалах залгаасын шинэ хувилбарыг ашиглахын тулд, Та кластерийг бүхэлд нь шинэчлэх хэрэгтэй. Үүнээс гадна Kubernetes-ийн шинэ хувилбар гэнэт таны хэрэглэж буй Линукс цөмтэй таарахгүй байгаад гайхах байх... Тиймээс та нулимсаа арчиж, шүдээ зууж, удирдлага, хэрэглэгчидтэйгээ цагийг зохицуулаарай. Linux цөм болон Kubernetes кластерийг шинэчлэх. Үйлчилгээ үзүүлэх явцад сул зогсолт гарах боломжтой.
Нөхцөл байдал инээдэмээс ч илүү байна гэж бодож байна уу? Энэ арга нь үр дүнгүй байгаа нь нийт ард түмэнд тодорхой болсон. Санаатайгаар шийдвэрлэснээр Kubernetes-ийн хөгжүүлэгчид хадгалах сантай ажиллах шинэ залгаасуудыг цөмд хүлээн авахаа больсныг зарлаж байна. Үүнээс гадна, бидний мэдэж байгаагаар Flexvolume залгаасыг хэрэгжүүлэхэд хэд хэдэн дутагдал илэрсэн ...
Kubernetes-д хамгийн сүүлийн үеийн нэмэлт өргөтгөл болох CSI нь байнгын өгөгдөл хадгалах асуудлыг нэг удаа, бүрмөсөн хаахыг уриалав. Түүний альфа хувилбар буюу Out-of-Tree CSI Volume Plugins гэж нэрлэгдэх хувилбарыг хэвлэлд зарласан. .
Контейнер хадгалах интерфейс, эсвэл CSI 3000 ээрэх саваа!
Юуны өмнө би CSI нь зөвхөн эзлэхүүний залгаас биш, харин жинхэнэ гэдгийг тэмдэглэхийг хүсч байна өгөгдлийн агуулахтай ажиллах тусгай бүрэлдэхүүн хэсгүүдийг бий болгох талаар. Кубернетес, Месос зэрэг контейнер зохион байгуулах системүүд нь энэхүү стандартын дагуу хэрэгжсэн бүрэлдэхүүн хэсгүүдтэй хэрхэн ажиллах талаар "сурах" ёстой байв. Одоо би Кубернетесийг аль хэдийн сурсан.
Kubernetes дахь CSI залгаас ямар бүтэцтэй вэ? CSI залгаас нь тусгай драйверуудтай ажилладаг (CSI драйверууд) гуравдагч талын хөгжүүлэгчдийн бичсэн. Kubernetes дахь CSI драйвер нь хамгийн багадаа хоёр бүрэлдэхүүн хэсгээс (под) бүрдэх ёстой:
- хянагчийн — гадаад байнгын хадгалалтуудыг удирддаг. Энэ нь командыг ашигладаг gRPC сервер хэлбэрээр хэрэгждэг
StatefulSet. - Зангилаа — кластерын зангилаанд байнгын хадгалалт суурилуулах үүрэгтэй. Энэ нь мөн gRPC сервер хэлбэрээр хэрэгждэг боловч энэ нь командыг ашигладаг
DaemonSet.
CSI залгаас Kubernetes дээр хэрхэн ажилладаг
Та CSI-ийн ажлын бусад нарийн ширийн зүйлийн талаар, жишээлбэл "" нийтлэлээс мэдэж болно.» Бид жилийн өмнө нийтэлсэн.
Ийм хэрэгжилтийн давуу талууд
- Зангилааны драйвер бүртгэх гэх мэт үндсэн зүйлсийн хувьд Kubernetes-ийн хөгжүүлэгчид олон тооны контейнеруудыг хэрэгжүүлсэн. Та Flexvolume залгаастай адил боломж бүхий JSON хариу үүсгэх шаардлагагүй болсон.
- Гүйцэтгэх боломжтой файлуудыг зангилаанууд руу "гулсуулах" оронд бид pods-ийг кластерт байршуулж байна. Үүнийг бид эхлээд Кубернетесээс хүлээж байна: бүх процессууд Кубернетес командуудыг ашиглан байрлуулсан контейнер дотор явагддаг.
- Нарийн төвөгтэй драйверуудыг хэрэгжүүлэхийн тулд RPC сервер болон RPC клиентийг хөгжүүлэх шаардлагагүй болсон. Үйлчлүүлэгчийг бидэнд зориулж Kubernetes-ийн хөгжүүлэгчид хэрэгжүүлсэн.
- gRPC протокол дээр ажиллах аргументуудыг дамжуулах нь тэдгээрийг командын мөрийн аргументуудаар дамжуулахаас хамаагүй илүү тохиромжтой, уян хатан, найдвартай байдаг. Стандартчилсан gRPC аргыг нэмж CSI-д эзлэхүүний ашиглалтын хэмжүүрийг хэрхэн дэмжих талаар ойлгохын тулд та дараахийг уншиж болно: vsphere-csi драйверын хувьд.
- Харилцаа холбоо нь IPC залгуураар дамждаг бөгөөд ингэснээр kubelet хүсэлтийг зөв pod руу илгээсэн эсэх талаар эргэлзэхгүй байх болно.
Энэ жагсаалт танд ямар нэг зүйлийг сануулж байна уу? CSI-ийн давуу талууд нь ижил асуудлуудыг шийдвэрлэх, Flexvolume залгаасыг боловсруулахдаа үүнийг анхаарч үзээгүй.
үр дүн нь
Мэдээллийн агуулахтай харилцах тусгай залгаасуудыг хэрэгжүүлэх стандарт болох CSI нь олон нийтээс маш халуун дотноор хүлээн авсан. Нэмж дурдахад давуу тал, олон талт байдлаас шалтгаалан CSI драйверууд нь Kubernetes-ийн хамгийн анхны хувилбарт нэмэгдсэн Ceph эсвэл AWS EBS гэх мэт хадгалах системд зориулагдсан байдаг.
2019 оны эхээр мод доторх залгаасууд . Бид Flexvolume залгаасыг үргэлжлүүлэн дэмжихээр төлөвлөж байгаа ч түүнд зориулсан шинэ функцийг хөгжүүлэхгүй.
Бид өөрсдөө ceph-csi, vsphere-csi ашиглах туршлагатай бөгөөд энэ жагсаалтад нэмэхэд бэлэн байна! Одоогоор CSI өөрт өгөгдсөн даалгавруудыг амжилттай даван туулж байгаа ч бид хүлээж, харах болно.
Шинэ бүхэн хуучнаа сайн эргэцүүлэн бодох явдал гэдгийг битгий мартаарай!
PS
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «".
Эх сурвалж: www.habr.com