Kubernetes - Использование существующего кластера Ceph для постоянного хранения

Thank you for reading this post, don't forget to subscribe!

Рас­смот­рим неко­то­рые вари­ан­ты хра­не­ния контейнеров

Хотя Kubernetes очень поле­зен в таких аспек­тах, как мас­шта­би­ру­е­мость, пере­но­си­мость и управ­ле­ние, ему не хва­та­ет под­держ­ки для сохра­не­ния состо­я­ния. Это озна­ча­ет, что когда про­ис­хо­дит сбой Кон­тей­не­ра, kubelet (агент узла, рабо­та­ю­щий на каж­дом узле) пере­за­пу­стит его, но фай­лы будут поте­ря­ны – Кон­тей­нер запус­ка­ет­ся с чистым состоянием.

Во-вто­рых, при сов­мест­ном запус­ке кон­тей­не­ров в моду­ле часто необ­хо­ди­мо обме­ни­вать­ся фай­ла­ми меж­ду эти­ми контейнерами.

Что­бы дан­ные мог­ли суще­ство­вать, когда кон­тей­нер пере­за­пус­ка­ет­ся или завер­ша­ет­ся, необ­хо­ди­мо исполь­зо­вать меха­низм хра­не­ния, кото­рый управ­ля­ет дан­ны­ми вне контейнера.

В этой ста­тье пред­став­ле­ны неко­то­рые инстру­мен­ты, помо­га­ю­щие решить такие про­бле­мы с хра­ни­ли­щем, кото­рые при­су­щи Kubernetes и Docker.

1. OpenEBS

OpenEBS – это веду­щий про­ект с откры­тым исход­ным кодом для хра­не­ния в кон­тей­не­рах и хра­не­ния в кон­тей­не­рах в Kubernetes.

В этом инстру­мен­те исполь­зу­ет­ся под­ход «Кон­тей­нер­ное хра­ни­ли­ще» (CAS), где каж­дая рабо­чая нагруз­ка снаб­жа­ет­ся выде­лен­ным кон­трол­ле­ром хранилища.

Он реа­ли­зу­ет дета­ли­зи­ро­ван­ные поли­ти­ки хра­не­ния и изо­ля­цию, кото­рые поз­во­ля­ют поль­зо­ва­те­лям опти­ми­зи­ро­вать хра­не­ние для каж­дой кон­крет­ной рабо­чей нагрузки.

OpenEBS рабо­та­ет в поль­зо­ва­тель­ском про­стран­стве и не име­ет зави­си­мо­стей от моду­лей ядра Linux (docs.openebs.io, 2019).

OpenEBS поз­во­ля­ет вам обра­ба­ты­вать ваши посто­ян­ные кон­тей­не­ры рабо­чей нагруз­ки, такие как БД в кон­тей­не­рах, так же, как и дру­гие контейнеры.

Сам OpenEBS раз­вер­ты­ва­ет­ся как еще один кон­тей­нер на вашем хосте и вклю­ча­ет служ­бы хра­не­ния, кото­рые могут быть назна­че­ны на уровне моду­ля, при­ло­же­ния, кла­сте­ра или контейнера.

Особенности OpenEBS

Хранилище для контейнеров

Как упо­ми­на­лось выше, OpenEBS сле­ду­ет архи­тек­ту­ре хра­ни­ли­ща с под­клю­чен­ным контейнером.

Поэто­му Тома, предо­став­ля­е­мые через OpenEBS, все­гда заклю­че­ны в контейнеры.

В резуль­та­те каж­дый том име­ет отдель­ный кон­трол­лер хра­ни­ли­ща, кото­рый повы­ша­ет гиб­кость и сте­пень дета­ли­за­ции опе­ра­ций посто­ян­но­го хра­не­ния при­ло­же­ний с сохра­не­ни­ем состояния.

Резервное копирование и восстановление

Резерв­ное копи­ро­ва­ние и вос­ста­нов­ле­ние томов OpenEBS рабо­та­ют с недав­ним реше­ни­ем для резерв­но­го копи­ро­ва­ния и вос­ста­нов­ле­ния Kubernetes, таким как HeptIO Ark.

Воз­мож­ность инкре­мент­но­го сним­ка OpenEBS эко­но­мит боль­шую про­пуск­ную спо­соб­ность и про­стран­ство для хра­не­ния, посколь­ку толь­ко резерв­ные дан­ные исполь­зу­ют­ся для резерв­но­го копи­ро­ва­ния в объ­ек­ты хра­ни­ли­ща объ­ек­тов, такие как S3.

Это дела­ет OpenEBS таким мощ­ным инструментом.

Метрики Prometheus для настройки рабочей нагрузки

Мони­то­ринг мет­рик хра­ни­ли­ща с под­клю­чен­ным кон­тей­не­ром воз­мо­жен, пото­му что тома OpenEBS осна­ще­ны дета­ли­зи­ро­ван­ны­ми мет­ри­ка­ми дан­ных, таки­ми как IOPS тома, про­пуск­ная спо­соб­ность, задерж­ка и шаб­ло­ны данных.

Бла­го­да­ря таким воз­мож­но­стям мони­то­рин­га при­ло­же­ния Stateful мож­но настра­и­вать для повы­ше­ния про­из­во­ди­тель­но­сти, наблю­дая шаб­ло­ны дан­ных тра­фи­ка на Prometheus и кор­рек­ти­руя пара­мет­ры поли­ти­ки хра­не­ния, не бес­по­ко­ясь о сосед­них рабо­чих нагруз­ках, исполь­зу­ю­щих OpenEBS.

Снимки и клоны

Сним­ки копи­ро­ва­ния при запи­си явля­ют­ся клю­че­вой осо­бен­но­стью OpenEBS.

Что еще сла­ще, так это то, что опе­ра­ции со сним­ка­ми и кло­на­ми выпол­ня­ют­ся пол­но­стью натив­ным мето­дом Kubernetes с исполь­зо­ва­ни­ем стан­дарт­ной коман­ды kubectl.

Боль­ше не нуж­но ника­ких команд при исполь­зо­ва­нии OpenEBS.

Более того, момен­таль­ные сним­ки созда­ют­ся мгно­вен­но, а коли­че­ство созда­ва­е­мых сним­ков неограниченно.

Синхронная Репликация

Это функ­ция, кото­рая реа­ли­зу­ет высо­кую доступ­ность, посколь­ку OpenEBS син­хрон­но реп­ли­ци­ру­ет репли­ки тома данных.

Эта функ­ция ста­но­вит­ся осо­бен­но полез­ной для созда­ния высо­ко­до­ступ­ных при­ло­же­ний с отсле­жи­ва­ни­ем состо­я­ния с исполь­зо­ва­ни­ем локаль­ных дис­ков в служ­бах облач­ных про­вай­де­ров, таких как Google Kubernetes Engine и другие.

Избегайте облачной блокировки

При рабо­те с при­ло­же­ни­я­ми с сохра­не­ни­ем состо­я­ния дан­ные запи­сы­ва­ют­ся в инфра­струк­ту­ру хра­не­ния облач­но­го провайдера.

Посколь­ку каж­дый облач­ный про­вай­дер име­ет раз­ную реа­ли­за­цию сво­их инфра­струк­тур хра­не­ния, это при­во­дит к облач­ной бло­ки­ров­ке при­ло­же­ний с сохра­не­ни­ем состояния.

Что дела­ет OpenEBS, так это то, что дан­ные запи­сы­ва­ют­ся на уро­вень OpenEBS, и он дей­ству­ет как уро­вень абстрак­ции данных.

Таким обра­зом, нали­чие это­го уров­ня абстрак­ции озна­ча­ет, что дан­ные мож­но пере­ме­щать по сло­ям Kubernetes, что устра­ня­ет про­бле­му бло­ки­ров­ки облака.

Высокая доступность

В отли­чие от тра­ди­ци­он­ных систем хра­не­ния, мета­дан­ные тома не цен­тра­ли­зо­ва­ны и хра­нят­ся локаль­но для тома.

Дан­ные тома син­хрон­но реп­ли­ци­ру­ют­ся как мини­мум на двух дру­гих узлах.

Таким обра­зом, поте­ря любо­го узла при­во­дит к поте­ре реплик тома, при­сут­ству­ю­щих толь­ко на этом узле.

Поэто­му в слу­чае сбоя узла дан­ные на дру­гих узлах про­дол­жа­ют оста­вать­ся доступ­ны­ми с теми же уров­ня­ми производительности.

2. Portworx

С сай­та Portworx:

Portworx пред­став­ля­ет собой про­грамм­но-опре­де­ля­е­мый овер­лей хра­ни­ли­ща, кото­рый поз­во­ля­ет вам

  • Запу­сти­те кон­тей­не­ри­зо­ван­ные при­ло­же­ния с состо­я­ни­ем, кото­рые явля­ют­ся высо­ко­до­ступ­ны­ми (HA) для несколь­ких узлов, облач­ных экзем­пля­ров, реги­о­нов, цен­тров обра­бот­ки дан­ных или даже облаков
  • Мигра­ция рабо­чих про­цес­сов меж­ду несколь­ки­ми кла­сте­ра­ми, рабо­та­ю­щи­ми в оди­на­ко­вых или гибрид­ных облаках
  • Запуск гипер­кон­вер­гент­ных рабо­чих нагру­зок, в кото­рых дан­ные нахо­дят­ся на том же хосте, что и приложения.
  • Про­грамм­ный кон­троль над ресур­са­ми хранения

Portworx – это ком­па­ния, кото­рая спе­ци­а­ли­зи­ру­ет­ся на предо­став­ле­нии про­дук­тов на осно­ве кон­тей­не­ров, начи­ная от хра­не­ния, мони­то­рин­га, вос­ста­нов­ле­ния после ава­рий и безопасности.

Мы сосре­до­то­чим­ся на их реше­нии для хра­не­ния кон­тей­не­ров Enterprise, извест­ном как PX-Store.

Этот про­дукт предо­став­ля­ет облач­ное хра­ни­ли­ще для при­ло­же­ний, рабо­та­ю­щих в обла­ке, локаль­но и в гибрид­ных / муль­ти­об­лач­ных средах.

Он обес­пе­чи­ва­ет надеж­ность, про­из­во­ди­тель­ность и защи­ту дан­ных, кото­рые вы ожи­да­е­те от ком­па­нии, зани­ма­ю­щей­ся хра­не­ни­ем дан­ных на пред­при­я­тии, но постав­ля­ют­ся в виде кон­тей­не­ра и управ­ля­ют­ся на 100% через Kubernetes и дру­гие веду­щие кон­тей­нер­ные платформы.

Особенности Portworx / PX-Store

  • Это реше­ние не с откры­тым исход­ным кодом
  • Опти­ми­зи­ро­ван­ные для кон­тей­не­ров объ­е­мы с упру­гим мас­шта­би­ро­ва­ни­ем (без про­стоя приложения)
  • Настрой­ка клас­са обслу­жи­ва­ния (COS) и под­держ­ки вво­да-выво­да с уче­том хранения
  • Настрой­ка общих томов с несколь­ки­ми запи­сы­ва­ю­щи­ми устрой­ства­ми (в несколь­ких контейнерах)
  • Ава­рий­ное пере­клю­че­ние меж­ду узла­ми / стой­ка­ми / AZ
  • Агре­ги­ро­ван­ные тома для орга­ни­за­ции пула хра­ни­лищ на хостах
  • Локаль­ные сним­ки – по тре­бо­ва­нию и по расписанию
  • OpenStorage SDK – под­клю­ча­ет­ся к томам CSI, Kubernetes и Docker
  • Авто­ма­ти­че­ское масштабирование
  • Локаль­ный центр обра­бот­ки дан­ных с син­хрон­ной репли­ка­ци­ей для HA. Эта функ­ция доступ­на толь­ко для хостов сервера.
  • Ска­ни­ро­ва­ние дис­ков на нали­чие оши­бок носи­те­лей, опо­ве­ще­ние и восстановление
  • Под­держ­ка гипер­кон­вер­гент­ных и выде­лен­ных архи­тек­тур хранилищ
  • Груп­пы согла­со­ван­но­сти объема

3. Rook

Пуб­лич­но выпу­щен­ный в нояб­ре 2016 года, Rook – это облач­ный оркест­ра­тор хра­не­ния с откры­тым исход­ным кодом для Kubernetes, предо­став­ля­ю­щий плат­фор­му, инфра­струк­ту­ру и под­держ­ку раз­но­об­раз­но­го набо­ра реше­ний для хра­не­ния дан­ных, кото­рые изна­чаль­но инте­гри­ру­ют­ся с облач­ны­ми средами.

Это хра­ни­ли­ще гото­вых фай­лов, бло­ков и объектов.

Rook пре­вра­ща­ет про­грамм­ное обес­пе­че­ние для хра­не­ния в само­управ­ля­е­мые, мас­шта­би­ру­е­мые и само­вос­ста­нав­ли­ва­ю­щи­е­ся сер­ви­сы хранения.

По сути, Rook поз­во­ля­ет поме­щать Ceph в кон­тей­не­ры и обес­пе­чи­ва­ет логи­ку управ­ле­ния кла­сте­ром для надеж­ной рабо­ты Ceph в Kubernetes.

4. StorageOS

StorageOS – это посто­ян­ное облач­ное хра­ни­ли­ще для контейнеров.

Полу­чи­те выго­ду от ори­ен­ти­ро­ван­но­го на при­ло­же­ния кон­тей­нер­но­го хра­ни­ли­ща, кото­рое пере­ме­ща­ет­ся вме­сте с вашим приложением.

Эта плат­фор­ма предо­став­ля­ет вам облач­ное реше­ние для хра­не­ния дан­ных кор­по­ра­тив­но­го клас­са, кото­рое вы може­те раз­вер­нуть где угод­но с про­из­во­ди­тель­но­стью, услу­га­ми пере­да­чи дан­ных и управ­ле­ни­ем поли­ти­ка­ми, кото­рые вы ожи­да­е­те от любо­го реше­ния для хра­не­ния дан­ных предприятия.

С веб-сай­та Kubernetes StorageOS рабо­та­ет как Кон­тей­нер в вашей сре­де Kubernetes, делая локаль­ное или под­клю­чен­ное хра­ни­ли­ще доступ­ным из любо­го узла в кла­сте­ре Kubernetes.

Дан­ные могут быть реп­ли­ци­ро­ва­ны для защи­ты от сбоя узла.

Тон­кая под­го­тов­ка и сжа­тие могут улуч­шить исполь­зо­ва­ние и сни­зить стоимость.

По сво­ей сути StorageOS предо­став­ля­ет блоч­ное хра­ни­ли­ще для кон­тей­не­ров, доступ­ное через фай­ло­вую систему.

5. Rancher Longhorn

Longhorn – это про­ект на 100% с откры­тым исход­ным кодом и плат­фор­ма, обес­пе­чи­ва­ю­щая посто­ян­ную реа­ли­за­цию хра­ни­ли­ща для любо­го кла­сте­ра Kubernetes.

По сво­ей сути Longhorn пред­став­ля­ет собой рас­пре­де­лен­ную блоч­ную систе­му хра­не­ния для Kubernetes с исполь­зо­ва­ни­ем кон­тей­не­ров и микросервисов.

Его мож­но уста­но­вить в суще­ству­ю­щий кла­стер Kubernetes с помо­щью одной коман­ды kubectl apply или с помо­щью диа­грамм Хелма.

После запус­ка Longhorn добав­ля­ет посто­ян­ную под­держ­ку томов в кла­стер Kubernetes.

Что уди­ви­тель­но в Longhorn, так это то, что он созда­ет выде­лен­ный кон­трол­лер хра­ни­ли­ща для каж­до­го тома блоч­но­го устрой­ства и син­хрон­но реп­ли­ци­ру­ет том на несколь­ко реплик, хра­ня­щих­ся на несколь­ких узлах.

6. GlusterFS Heketi

gluster-kubernetes – это про­ект, предо­став­ля­ю­щий адми­ни­стра­то­рам Kubernetes меха­низм, поз­во­ля­ю­щий лег­ко раз­вер­ты­вать GlusterFS в каче­стве соб­ствен­ной служ­бы хра­не­ния в суще­ству­ю­щем кла­сте­ре Kubernetes.

Здесь GlusterFS управ­ля­ет­ся и управ­ля­ет­ся как любое дру­гое при­ло­же­ние в Kubernetes.

Это удоб­ный спо­соб раз­бло­ки­ро­вать мощь дина­ми­че­ски под­го­тов­лен­ных, посто­ян­ных томов GlusterFS в Kubernetes.

Heketi предо­став­ля­ет интер­фейс управ­ле­ния RESTful, кото­рый мож­но исполь­зо­вать для управ­ле­ния жиз­нен­ным цик­лом томов GlusterFS.

Бла­го­да­ря Heketi облач­ные сер­ви­сы, такие как Kubernetes, могут дина­ми­че­ски предо­став­лять томам GlusterFS любой из под­дер­жи­ва­е­мых типов надежности.

 

7. Ceph

Интеграция Kubernetes и Ceph

Кли­ент RBD исполь­зу­ет­ся для вза­и­мо­дей­ствия Kubernetes и Ceph.

К сожа­ле­нию, он не досту­пен в офи­ци­аль­ном кон­тей­не­ре kube-controller-manager.

Вы може­те изме­нить образ kube controller manager, что­бы вклю­чить RBD, но это не рекомендуется.

Вме­сто это­го я буду исполь­зо­вать внеш­ний пла­гин для Ceph.

Это создаст отдель­ный под rbd-provisioner, в кото­ром уста­нов­лен rbd.

Мой тесто­вый кла­стер Kubernetes вклю­ча­ет аутен­ти­фи­ка­цию RBAC.

Если у вас нет, вы може­те про­сто создать ресурс Deployment и про­пу­стить остальные.

В этом слу­чае не забудь­те уда­лить service account из Deploytment.

Давай­те созда­дим все ресур­сы для rbd-provisioner с RBAC в про­стран­стве имен kube-system:

 

Убе­ди­тесь, что в обра­зе quay.io/external_storage/rbd-provisioner:latest уста­нов­ле­на та же вер­сия Ceph, что и в вашем кла­сте­ре Ceph.
Вы може­те про­ве­рить это так на любой машине, на кото­рой запу­щен Docker:
Подо­жди­те несколь­ко минут, пока мене­джер томов RBD будет запу­щен и работает:

Мене­дже­ру томов RBD необ­хо­дим ключ адми­ни­стра­то­ра от Ceph для предо­став­ле­ния хранилища.
Что­бы полу­чить ключ адми­ни­стра­то­ра из кла­сте­ра Ceph, исполь­зуй­те эту команду:

sudo ceph --cluster ceph auth get-key client.admin

ПРИМЕЧАНИЕ. Запу­сти­те все коман­ды, начи­ная sudo, на узле Ceph MON. Так­же я исполь­зую Jewel-вер­сию Ceph, и rbd-Provider так­же осно­ван на Jewel.

Затем добавь­те этот ключ к сек­ре­там Kubernetes:

 

Я так­же создам отдель­ный пул Ceph для Kubernetes и новый кли­ент­ский ключ, так как в этом кла­сте­ре Ceph вклю­че­на аутен­ти­фи­ка­ция cephx:
sudo ceph --cluster ceph osd pool create kube 1024 1024
sudo ceph --cluster ceph auth get-or-create client.kube mon 'allow r' osd 'allow rwx pool=kube'
sudo ceph --cluster ceph auth get-key client.kube

Добавь­те новый сек­рет кли­ен­та для kube pool в сек­ре­ты Kubernetes:

Когда оба сек­ре­та при­сут­ству­ют, создай­те новый класс хранения.
Давай­те назо­вем его fast-rbd:
И послед­ний шаг – созда­ние про­сто­го PVC для тести­ро­ва­ния постав­щи­ка томов RBD:
Вот и все, новый том, создан­ный на кла­сте­ре Ceph: