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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 |
cat <<EOF | kubectl create -n kube-system -f - kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-provisioner rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["events"] verbs: ["create", "update", "patch"] - apiGroups: [""] resources: ["services"] resourceNames: ["kube-dns","coredns"] verbs: ["list", "get"] - apiGroups: [""] resources: ["endpoints"] verbs: ["get", "list", "watch", "create", "update", "patch"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rbd-provisioner subjects: - kind: ServiceAccount name: rbd-provisioner namespace: kube-system roleRef: kind: ClusterRole name: rbd-provisioner apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: rbd-provisioner rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rbd-provisioner roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: rbd-provisioner subjects: - kind: ServiceAccount name: rbd-provisioner namespace: kube-system --- apiVersion: v1 kind: ServiceAccount metadata: name: rbd-provisioner --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: rbd-provisioner spec: replicas: 1 strategy: type: Recreate template: metadata: labels: app: rbd-provisioner spec: containers: - name: rbd-provisioner image: "quay.io/external_storage/rbd-provisioner:latest" env: - name: PROVISIONER_NAME value: ceph.com/rbd serviceAccount: rbd-provisioner EOF |
1 2 3 |
docker pull quay.io/external_storage/rbd-provisioner:latest docker history quay.io/external_storage/rbd-provisioner:latest | grep CEPH_VERSION <missing> 15 hours ago /bin/sh -c #(nop) ENV CEPH_VERSION=luminous |
1 2 3 |
kubectl get pods -l app=rbd-provisioner -n kube-system NAME READY STATUS RESTARTS AGE rbd-provisioner-77d75fdc5b-mpbpn 1/1 Running 1 1m |
Менеджеру томов RBD необходим ключ администратора от Ceph для предоставления хранилища.
Чтобы получить ключ администратора из кластера Ceph, используйте эту команду:
sudo ceph --cluster ceph auth get-key client.admin
ПРИМЕЧАНИЕ. Запустите все команды, начиная sudo, на узле Ceph MON. Также я использую Jewel-версию Ceph, и rbd-Provider также основан на Jewel.
Затем добавьте этот ключ к секретам Kubernetes:
1 2 3 4 |
kubectl create secret generic ceph-secret \ --type="kubernetes.io/rbd" \ --from-literal=key='AQBwruNY/lEmCxAAKS7tzZHSforkUE85htnA/g==' \ --namespace=kube-system |
Я также создам отдельный пул 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:
1 2 3 4 |
kubectl create secret generic ceph-secret-kube \ --type="kubernetes.io/rbd" \ --from-literal=key='AQC/c+dYsXNUNBAAMTEW1/WnzXdmDZIBhcw6ug==' \ --namespace=kube-system |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
cat <<EOF | kubectl create -f - apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-rbd provisioner: ceph.com/rbd parameters: monitors: <monitor-1-ip>:6789, <monitor-2-ip>:6789, <monitor-3-ip>:6789 adminId: admin adminSecretName: ceph-secret adminSecretNamespace: kube-system pool: kube userId: kube userSecretName: ceph-secret-kube userSecretNamespace: kube-system imageFormat: "2" imageFeatures: layering EOF |
1 2 3 4 5 6 7 8 9 10 11 12 13 |
cat <<EOF | kubectl create -f - kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 8Gi storageClassName: fast-rbd EOF |
1 2 3 |
kubectl get pvc myclaim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE myclaim Bound pvc-11559e19-2541-11e8-94dc-525400474652 8Gi RWO |