🥇Съхранение на данни в Kubernetes клъстер

Конфигурирането на съхранението на данни на приложения, работещи в кластер Kubernetes, може да бъде направено по няколко начина. Някои от тях вече са остаряли, а други са се появили съвсем наскоро. В тази статия ще разгледаме концепцията на трите опции за свързване на СХД, включително най-новата — свързване чрез Container Storage Interface.

Метод 1. Посочване на PV в манифеста на пода

Типичен манифест, описващ под в кластер Kubernetes:

С цветове са подчертавани частите на манифеста, където е описано кой том се свързва и къде.

В секцията volumeMounts посочва точките на монтиране (mountPath) — в коя папка вътре в контейнера ще бъде монтиран постоянния том, както и името на тома.

В секцията x изброява всичките томове, които се използват в пода. Посочва името на всеки том, както и типа (в нашия случай: awsElasticBlockStore) и параметрите за свързване. Какви конкретно параметри се изброяват в манифеста, зависи от типа тома.

Един и същ том може да бъде монтиран едновременно в няколко контейнера на пода. По този начин различни процеси на приложението могат да имат достъп до едни и същи данни.

Този метод на свързване беше създаден в самото начало, когато Kubernetes тъкмо започваше, и до днешен ден методът е остарял.

При неговото използване възникват няколко проблема:

всички томове трябва да се създават ръчно, Kubernetes не може да създаде нищо вместо нас;
параметрите за достъп до всеки от томовете са уникални и трябва да бъдат посочени в манифестите на всички подове, които използват тома;
за да смените системата за съхранение (например, да преминете от AWS в Google Cloud), трябва да промените настройки и тип на свързаните томове във всички манифести.

Всичко това е много неудобно, затова в реалността подобен начин се използва за свързване само на някои специални типове томове: configMap, secret, emptyDir, hostPath:

configMap и secret — служебни томове, които позволяват да се създаде в контейнера том с файлове от манифестите на Kubernetes.
emptyDir — временен том, който се създава само за времето на съществуването на пода. Удобно е да се използва за тестване или съхранение на временни данни. Когато подът бъде изтрит, томът тип emptyDir също се изтрива и всички данни изчезват.
hostPath — позволява да монтирате всяка директория от локалния диск на сървъра, на който работи приложението, в контейнера с приложението, включително /etc/kubernetes. Това е небезопасна функция, затова обикновено политиките за сигурност забраняват използването на томове от този тип. В противен случай приложението на злонамерен потребител може да монтира директорията на HTC Kubernetes в своя контейнер и да открадне всички сертификати на клъстера. Обикновено, томове hostPath са разрешени само за системни приложения, които се стартират в името на kube-system.

Системи за съхранение на данни, с които Kubernetes работи по подразбиране са описани в документацията.

Метод 2. Свързване с подовете SC/PVC/PV

Алтернативният метод за свързване е концепцията за Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class съхранява параметрите за свързване със системата за съхранение на данни.

PersistentVolumeClaim описва изискванията за тома, необходим за приложението.
PersistentVolume съхранява параметрите за достъп и статус на тома.

Същността на идеята: в манифеста на пода се указва volume от тип PersistentVolumeClaim и се посочва името на тази структура в параметъра claimName.

В манифеста PersistentVolumeClaim се описват изискванията за данния том, необходим за приложението. Включително:

размер на диска;
метод на достъп: ReadWriteOnce или ReadWriteMany;
връзка към Storage class — в коя система за съхранение на данни искаме да създадем том.

В манифестите на Storage class се съхраняват типът и параметрите за свързване с системата за съхранение на данни. Те са нужни на кублета, за да монтира тома на своя узел.

В манифестите на PersistentVolume се указва Storage class и параметрите за достъп до конкретен том (ID на тома, път и т.н.).

При създаване на PVC, Kubernetes проверява какъв размер и от коя Storage class е необходимият том и избира свободен PersistentVolume.

Ако няма налични PV, Kubernetes може да стартира специална програма — Provisioner (нейното име се указва в Storage class). Тази програма се свързва с СХД, създава необходимия по размер том, получава идентификатор и създава в клъстера Kubernetes манифест PersistentVolume, който се свързва с PersistentVolumeClaim.

Цялото това множество абстракции позволява да се премахне информацията за това, с коя СХД работи приложението, от нивото на манифеста на приложенията до нивото на администриране.

Всички параметри за свързване с системата за съхранение на данни се намират в Storage class, за който отговарят администраторите на клъстера. Всичко, което трябва да направите при преместването от AWS в Google Cloud, е да промените името на Storage class в PVC в манифестите на приложението. Persistence Volume за съхранение на данни ще бъдат създадени в клъстера автоматично с помощта на програмата Provisioner.

Метод 3. Container Storage Interface

Целият код, който взаимодействува с различни системи за съхранение на данни, е част от ядрото на Kubernetes. Издаването на корекции на грешки или нови функционалности е обвързано с нови версии, кодът трябва да се променя за всички поддържани версии на Kubernetes. Всичко това е трудно за поддържане и добавяне на нови функционалности.

За да решат проблема, разработчиците от Cloud Foundry, Kubernetes, Mesos и Docker създадоха Container Storage Interface (CSI) — прост унифициран интерфейс, който описва взаимодействието между системата за управление на контейнери и специалния драйвер (CSI Driver), работещ с конкретната СХД. Целият код за взаимодействие с СХД е изнесен от ядрото на Kubernetes в отделна система.

Документация за Container Storage Interface.

Обикновено, CSI Driver се състои от два компонента: Node Plugin и Controller Plugin.

Node Plugin се стартира на всеки възел и отговаря за монтиране на томовете и за операции върху тях. Controller Plugin взаимодействува с СХД: създава или изтрива томове, задава права за достъп и т.н.

Докато в ядрото на Kubernetes все още съществуват стари драйвери, използването им вече не се препоръчва и всички съветват да се инсталира CSI Driver конкретно за системата, с която предстои работа.

Нововъведението може да изплаши тези, които вече са свикнали да настройват съхранение на данни чрез Storage class, но всъщност нищо страшно не се е случило. За програмистите определено нищо не се променя — те така и продължават да работят само с името Storage class. За администраторите се добави инсталирането на helm chart и се промени структурата на настройките. Докато преди настройките се въвеждаха директно в Storage class, сега те първо трябва да се зададат в helm chart, а след това в Storage class. Ако се разгледа, нищо страшно не е настъпило.

Нека, за примера, разгледаме какви предимства можем да получим, преминавайки на свързване със СХД Ceph с помощта на CSI драйвера.

При работа с Ceph, CSI плъгинът предоставя повече възможности за работа с СХД, отколкото вградените драйвери.

Динамично създаване на дискове. Обикновено RBD дисковете се използват само в RWO режим, а CSI за Ceph позволява тяхната употреба в RWX режим. Няколко pod-а на различни възли могат да монтират един и същ RDB диск и да работят с него паралелно. За справедливост, не всичко е толкова розово — този диск може да бъде свързан само като блочно устройство, т.е. ще се наложи адаптиране на приложението, за да работи с него в режим на множество потребители.
Създаване на снимки. В Kubernetes клъстер може да се създаде манифест с искане за създаване на снимка. CSI плъгинът ще го види и ще направи снимка на диска. На нейна база може да се направи или резервно копие, или копие на PersistentVolume.
Увеличаване на размера на диска в СХД и PersistentVolume в Kubernetes клъстера.
Квоти. Вградените в Kubernetes драйвери CephFS не поддържат квоти, а новите CSI плъгини с актуалния Ceph Nautilus умеят да включват квоти на CephFS дялове.
Метрики. CSI плъгинът може да предоставя в Prometheus множество метрики за това, кои томове са свързани, какви взаимодействия се извършват и т.н.
Зависимост от топология. Позволява да се укаже в манифестите как географски е разпределен клъстерът и да се избегне свързване с подове, разположени в Лондон, за системи за съхранение на данни, находящи се в Амстердам.

Как да свържете Ceph с Kubernetes клъстер чрез CSI, вижте в практическата част на лекцията на вечерното училище Слърм. Можете също да се запишете за видеокурс по Ceph, който ще започне на 15 октомври.

Автор на статията: Сергей Бондарев, практикуващ архитект в Southbridge, сертифициран Kubernetes администратор, един от разработчиците на kubespray.

Няколко думи Post Scriptum не за реклама, а за полза…

P.S. Сергей Бондарев води два интензива: обновен Kubernetes База 28-30 септември и напреднал Kubernetes Мега 14-16 октомври.