Хранение Данных В Кластере Kubernetes

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

В этой статье мы рассмотрим концепцию трёх вариантов подключения СХД, в том числе самый последний — подключение через Container Storage Interface.

Хранение данных в кластере Kubernetes



Способ 1. Укажите PV в манифесте модуля.

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

Хранение данных в кластере Kubernetes

Цветом выделены части манифеста, описывающие, какой том и куда подключен.

В главе томМаунты указать точки монтирования (mountPath) — в какой каталог внутри контейнера будет смонтирован постоянный том, а также имя тома.

В главе объемы перечисляет все тома, которые используются в модуле.

Укажите имя каждого тома, а также тип (в нашем случае: awsElasticBlockStore) и параметры подключения.

Какие параметры указаны в манифесте, зависит от типа тома.

Один и тот же том можно смонтировать одновременно в нескольких контейнерах модулей.

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

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

При использовании возникает ряд проблем:

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

Все это очень неудобно, поэтому на самом деле этот метод используется для подключения только некоторых специальных типов томов: configMap, secret,emptyDir,hostPath:
  • configMap и secret — это служебные тома, которые позволяют создавать том с файлами из манифестов Kubernetes в контейнере.

  • пустойDir — это временный том, создаваемый только на время существования модуля.

    Удобно использовать для тестирования или хранения временных данных.

    При удалении модуля том пустойDir также удаляется, и все данные теряются.

  • HostPath — позволяет монтировать любую директорию на локальном диске сервера, на котором работает приложение, внутри контейнера с приложением, включая /etc/kubernetes. Это небезопасная функция, поэтому политики безопасности обычно запрещают использование тома такого типа.

    В противном случае приложение злоумышленника сможет смонтировать каталог /etc/kubernetes внутри своего контейнера и украсть все сертификаты кластера.

    Обычно тома HostPath разрешено использовать только системным приложениям, работающим в пространстве имен kube-system.

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



Способ 2. Подключение к подам SC/PVC/PV.

Альтернативным методом подключения является концепция класса Storage, PersistentVolumeClaim, PersistentVolume. Класс Storage хранит параметры подключения к системе хранения данных.

PersistentVolumeClaim описывает требования к тому, который нужен приложению.

PersistentVolume хранит параметры доступа и состояние тома.

Суть идеи: в манифесте пода указывают том типа PersistentVolumeClaim и указывают имя этой сущности в параметреclaimName.

Хранение данных в кластере Kubernetes

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

Включая:

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

Манифест класса Storage хранит тип и параметры подключения к системе хранения.

Они нужны кублету для монтирования тома на своем узле.

В манифестах PersistentVolume указывается класс хранилища и параметры доступа для конкретного тома (идентификатор тома, путь и т. д.).

При создании PVC Kubernetes смотрит, какой размер тома и какой класс хранилища требуется, и выбирает свободный PersistentVolume. Если таких PV нет, Kubernetes может запустить специальную программу — Provisioner (ее название указано в классе Storage).

Эта программа подключается к системе хранения, создает том необходимого размера, получает идентификатор и создает манифест PersistentVolume в кластере Kubernetes, который связан с PersistentVolumeClaim. Все это множество абстракций позволяет вынести информацию о том, с какой системой хранения работает приложение, с уровня манифеста приложения на уровень администрирования.

Все параметры подключения к системе хранения данных находятся в классе Storage, за который отвечают администраторы кластера.

Все, что вам нужно сделать при переходе с AWS на Google Cloud, — это изменить имя класса Storage на PVC в манифестах приложений.

Persistance Volume для хранения данных будет создан в кластере автоматически с помощью программы Provisioner.

Способ 3: Интерфейс хранилища контейнеров

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

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

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

Документация по интерфейсу хранилища контейнеров .

Обычно драйвер CSI состоит из двух компонентов: плагина узла и плагина контроллера.

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

Плагин Controller взаимодействует с системой хранения: создает или удаляет тома, назначает права доступа и т. д. Пока старые драйвера остаются в ядре Kubernetes, но их больше не рекомендуется использовать и всем рекомендуется устанавливать CSI Driver специально для той системы, с которой они будут работать.

Нововведение может напугать тех, кто уже привык настраивать хранение данных через класс Storage, но на самом деле ничего страшного не произошло.

Для программистов особо ничего не меняется — они работали только с именем Storage class, и будут продолжать это делать.

Для администраторов добавлена установка рулевой диаграммы и изменена структура настроек.

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

Давайте на примере рассмотрим преимущества, которые вы можете получить, переключившись на подключение систем хранения 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, см.

в практической части лекции вечерней школы Слёрма .

Вы также можете подписаться на Видеокурс по Ceph , который выйдет 15 октября.

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

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



Хранение данных в кластере Kubernetes

Теги: #Системное администрирование #Администрирование сервера #Kubernetes #DevOps #k8s #ceph #google cloud #secret #volumeMounts #volumes #Container Storage Interface #awsElasticBlockStore #EmptyDir #configMap #hostPath #Storage class #PersistentVolumeClaim #PersistentVolume #Node Plugin #Controller Plugin

Вместе с данным постом часто просматривают: