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

Хотя 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 любой из поддерживаемых типов надежности.

 

Please follow and like us:

Добавить комментарий