Kubernetes әлі v1.0.0 болғанда, көлемді плагиндер болған. Олар тұрақты (тұрақты) контейнер деректерін сақтау үшін жүйелерді Kubernetes-ке қосу үшін қажет болды. Олардың саны аз болды, ал біріншілердің қатарында GCE PD, Ceph, AWS EBS және басқалары сияқты сақтау провайдерлері болды.
Плагиндер Kubernetes-пен бірге жеткізілді, сондықтан олар өз атауын алды - ағаш ішінде. Алайда, көпшілігі үшін мұндай плагиндердің бар жиынтығы жеткіліксіз болып шықты. Шеберлер патчтарды пайдаланып Kubernetes өзегіне қарапайым плагиндерді қосты, содан кейін олар өздерінің Кубернеттерін жинап, оны серверлеріне орнатты. Бірақ уақыт өте келе Kubernetes әзірлеушілері мұны түсінді балық мәселені шешу мүмкін емес. Адамдар керек шыбық. Ал Kubernetes v1.2.0 шығарылымында ол пайда болды...
Flexvolume плагині: ең аз қармақ
Kubernetes әзірлеушілері FlexVolume плагинін жасады, ол үшінші тарап әзірлеушілері жүзеге асыратын Flexvolume драйверлерімен жұмыс істеуге арналған айнымалылар мен әдістердің логикалық құрылымы болды.
Тоқтап, FlexVolume драйверінің не екенін мұқият қарастырайық. Бұл белгілі орындалатын файл (екілік файл, Python сценарийі, Bash сценарийі және т.б.), ол орындалған кезде пәрмен жолы аргументтерін кіріс ретінде қабылдайды және JSON пішімінде алдын ала белгілі өрістері бар хабарламаны қайтарады. Шарт бойынша бірінші пәрмен жолы аргументі әрқашан әдіс болып табылады, ал қалған аргументтер оның параметрлері болып табылады.
OpenShift ішіндегі CIFS Shares үшін қосылым диаграммасы. 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 операторында.
Мұнда 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. Кластерде жаңа түйін пайда болған кезде, ол автоматты түрде Flexvolume драйверлерін табу үшін жол бойымен жергілікті том тіркелген DaemonSet-тен подкастты қамтиды. Сәтті жасалғаннан кейін подвод драйвердің дискіге жұмыс істеуі үшін қажетті файлдарды көшіреді.
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 драйвер файлдарын көшіргеннен кейін бұл подколь өлмейді, бірақ толыққанды RPC сервері ретінде қосылған том арқылы IPC ұясына қосылады. Ceph-Common пакеті подколь контейнерінің ішіне орнатылған. IPC ұясы кубелеттің дәл сол түйінде орналасқан қосқышпен байланысуын қамтамасыз етеді. Тапқырдың бәрі қарапайым!..
Қош бол, біздің сүйікті... ағаш ішіндегі плагиндер!
Kubernetes әзірлеушілері ядродағы сақтауға арналған плагиндердің саны жиырма екенін анықтады. Және олардың әрқайсысының өзгеруі, кез келген жағдайда, Кубернетестің толық шығарылым циклінен өтеді.
Сақтау плагинінің жаңа нұсқасын пайдалану үшін, бүкіл кластерді жаңарту қажет. Бұған қоса, Kubernetes-тің жаңа нұсқасы сіз пайдаланып жатқан Linux ядросымен кенеттен үйлесімсіз болып қалатынына таң қалуыңыз мүмкін... Осылайша сіз көз жасыңызды сүртіп, тістеріңізді қайрап, басшылықпен және пайдаланушылармен келісесіз. Linux ядросы мен Kubernetes кластерін жаңартыңыз. Қызмет көрсету кезінде мүмкін болатын тоқтап қалумен.
Жағдай күлкілі емес, сіз ойлайсыз ба? Бүкіл қоғамдастыққа бұл тәсілдің нәтиже бермейтіні белгілі болды. Күрделі шешім бойынша Kubernetes әзірлеушілері жадпен жұмыс істеуге арналған жаңа плагиндер ядроға енді қабылданбайтынын хабарлайды. Сонымен қатар, біз білетіндей, Flexvolume плагинін енгізуде бірқатар кемшіліктер анықталды...
Kubernetes, CSI көлемдеріне арналған соңғы қосылған плагин деректерді тұрақты сақтау мәселесін біржола жабу үшін шақырылды. Оның альфа нұсқасы, толығымен ағаштан тыс CSI көлемді плагиндер деп аталады, шығарылымда жарияланды. .
Контейнерді сақтау интерфейсі немесе CSI 3000 айналдыру таяқшасы!
Ең алдымен, CSI тек көлемдік плагин емес, нақты екенін атап өткім келеді деректер қоймаларымен жұмыс істеу үшін теңшелетін құрамдастарды жасау бойынша. Kubernetes және Mesos сияқты контейнерлік оркестрлік жүйелер осы стандартқа сәйкес енгізілген компоненттермен жұмыс істеуді «үйренуі» керек еді. Ал қазір мен Кубернетесті үйрендім.
Kubernetes-тегі CSI плагинінің құрылымы қандай? CSI плагині арнайы драйверлермен жұмыс істейді (CSI драйверлері) үшінші тарап әзірлеушілерімен жазылған. Kubernetes-тегі CSI драйвері ең аз екі компоненттен (подтар) тұруы керек:
- Controller — сыртқы тұрақты қоймаларды басқарады. Ол gRPC сервері ретінде іске асырылады, ол үшін примитив пайдаланылады
StatefulSet. - Node — кластерлік түйіндерге тұрақты сақтауды орнатуға жауапты. Ол сондай-ақ gRPC сервері ретінде жүзеге асырылады, бірақ ол қарапайымды пайдаланады
DaemonSet.
CSI плагині Kubernetes жүйесінде қалай жұмыс істейді
Сіз CSI жұмысының басқа да мәліметтері туралы біле аласыз, мысалы, мақаладан ««, бір жыл бұрын шығардық.
Мұндай іске асырудың артықшылықтары
- Түйінге драйверді тіркеу сияқты негізгі нәрселер үшін Kubernetes әзірлеушілері контейнерлер жинағын енгізді. Енді Flexvolume плагині үшін жасалғандай, мүмкіндіктері бар JSON жауабын өзіңіз жасаудың қажеті жоқ.
- Орындалатын файлдарды түйіндерге «сыртқылаудың» орнына, біз енді блоктарды кластерге жүктейміз. Бастапқыда біз Кубернетестен күтетін нәрсе: барлық процестер Kubernetes примитивтері арқылы орналастырылған контейнерлерде орын алады.
- Күрделі драйверлерді енгізу үшін RPC сервері мен RPC клиентін әзірлеу қажет емес. Клиентті біз үшін Kubernetes әзірлеушілері енгізді.
- gRPC протоколы арқылы жұмыс істеу үшін аргументтерді жіберу оларды пәрмен жолы аргументтері арқылы өткізуге қарағанда әлдеқайда ыңғайлы, икемді және сенімді. Стандартталған gRPC әдісін қосу арқылы CSI жүйесіне көлемді пайдалану көрсеткіштеріне қолдауды қалай қосу керектігін түсіну үшін мынаны оқуға болады: vsphere-csi драйверіне арналған.
- Байланыс IPC розеткалары арқылы жүзеге асырылады, сондықтан кубелет сұрауды дұрыс подкетке жіберді ме, жоқ па, шатастырмау үшін.
Бұл тізім сізге бір нәрсені еске түсіре ме? CSI артықшылықтары сол мәселелерді шешу, олар Flexvolume плагинін жасау кезінде ескерілмеді.
қорытындылар
Деректер қоймаларымен әрекеттесу үшін пайдаланушы плагиндерін енгізу стандарты ретінде CSI қауымдастық өте жылы қабылдады. Сонымен қатар, олардың артықшылықтары мен әмбебаптығына байланысты, CSI драйверлері тіпті Ceph немесе AWS EBS сияқты сақтау жүйелері үшін жасалған, олармен жұмыс істеуге арналған плагиндер Kubernetes-тің ең бірінші нұсқасында қосылған.
2019 жылдың басында ағаш ішіндегі плагиндер . Біз Flexvolume плагинін қолдауды жалғастыруды жоспарлап отырмыз, бірақ ол үшін жаңа функционалдылықты дамытпаймыз.
Бізде ceph-csi, vsphere-csi пайдалану тәжірибесі бар және осы тізімге қосуға дайынбыз! Әзірге, CSI өзіне жүктелген тапсырмаларды жылдам орындауда, бірақ біз күтеміз және көреміз.
Жаңаның бәрі ескіні қайта қарау екенін ұмытпаңыз!
PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com