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

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

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

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

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

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

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

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

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

Има няколко проблема при използването му:

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

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

• configMap и secret са сервизни томове, които ви позволяват да създадете том с файлове от манифестите на Kubernetes в контейнера.

• emptyDir е временен том, създаден само за живота на групата. Удобен за използване за тестване или съхраняване на временни данни. Когато под се изтрие, томът празенДир също се изтрива и всички данни се губят.

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

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

Метод 2. Свързване към SC/PVC/PV огнища

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

Клас за съхранение съхранява параметрите на връзката към системата за съхранение на данни.

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

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

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

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

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

Манифестите на PersistentVolume показват класа Storage и параметрите за достъп за конкретен том (ИД на том, път и т.н.).

Когато създава PVC, Kubernetes разглежда обема с какъв размер и какъв клас на съхранение се изисква и избира безплатен PersistentVolume.

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

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

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

Метод 3: Интерфейс за съхранение на контейнери

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

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

Документация на интерфейса за съхранение на контейнери.

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

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

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

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

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

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

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

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

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

Малък Post Scriptum не за реклама, а за полза...

PS Сергей Бондарев води два интензивни курса: актуализиран База Kubernetes 28-30 септември и напреднали Kubernetes Mega 14–16 октомври.

Източник: www.habr.com