Постоянное хранилище для Kubernetes
Развертывание Portworx на контейнерной платформе Red Hat OpenShift
Обзор
В сегодняшнюю цифровую эпоху ценность контейнерных приложений неоспорима. Это смена парадигмы в разработке приложений и переход на DevOps и облачную архитектуру для успешной цифровой трансформации. Благодаря этому Kubernetes (K8) стал основным и де-факто стандартом оркестровки контейнеров. В Kubernetes много движущихся частей, однако в этой статье я расскажу о решении для хранения контейнеров.
Рабочие нагрузки, развернутые в контейнерах и управляемые через K8, не имеют состояния или имеют состояние. По умолчанию рабочие нагрузки K8 не имеют состояния. Приложение без сохранения состояния не сохраняется, что означает, что оно использует временное хранилище, предоставленное в K8, и уничтожается после завершения работы приложения или модуля. Вот почему мы называем контейнеры эфемерными по своей природе, данные, связанные с контейнерами, могут быть потеряны после завершения работы контейнера или случайного сбоя. Кроме того, данные также не могут использоваться другими контейнерами.
Для приложения с отслеживанием состояния постоянное хранилище является первым обязательным требованием. Kubernetes поддерживает различные решения для постоянного хранения, которые помогают решить эту проблему и поддерживают рабочие нагрузки с отслеживанием состояния в контейнерной среде. Kubernetes вводит концепцию постоянных томов, которые существуют независимо от контейнеров, выживают даже после закрытия контейнеров и могут запрашиваться и использоваться контейнерными рабочими нагрузками.
В этой статье я расскажу о Portworx, масштабируемой платформе постоянного хранения для Kubernetes. Portworx доступен практически на всех основных платформах Kubernetes, таких как Amazon EKS, Azure AKS, Google GKE и многих других. В этом документе я расскажу о том, как реализовать Portworx в Red Hat OpenShift Container Platform.
Логическая топология
На рисунке ниже показано, как рабочие узлы в платформе OpenShift настроены по отношению к диску, выделенному для использования при формировании кластера Portworx. Также важно отметить, что в этой настройке я буду использовать внутреннюю встроенную базу данных значений ключей (KVDB). Для формирования кластера хранилища ключей и значений (kvdb) требуется минимум три узла, а узлы должны быть помечены как px-metadata-node = true. При желании вы можете использовать метку px / enabled = false, если вы не хотите, чтобы какой-либо конкретный узел был частью кластера Portworx.
Если вы планируете использовать собственный кластер etcd, обратитесь к документации Portworx. В этом документе не рассматривается развертывание Portworx с использованием внешнего хранилища ключей.
Предпосылки
Ниже приведены предварительные условия для установки Portworx в OpenShift.
· В вашем кластере должен быть запущен OpenShift 4 или выше.
· Требуется минимум три узла
· Каждый узел должен соответствовать следующим минимальным требованиям для Portworx
Установите оператор Portworx в OpenShift
Оператор Portworx - это простой способ развернуть Portworx в OpenShift. Он управляет общим жизненным циклом кластера Portworx. Благодаря этому мы можем устанавливать, настраивать, обновлять и удалять Portworx.
На диаграмме ниже показаны компоненты, составляющие платформу Portworx.
Войдите в веб-консоль OpenShift и перейдите в OperatorHub. Найдите Portworx, как показано ниже.
В этой настройке я буду устанавливать Portworx Essentials. Это бесплатная версия с ограниченными возможностями, такими как до 5 узлов, емкость 5 ТБ и 500 томов. Это достаточно хорошо для целей PoC. Однако для настройки производственного уровня можно использовать Portworx Enterprise. Вы также можете попробовать корпоративную версию с 30-дневным ознакомительным периодом.
Теперь установите основные компоненты Portworx в пространство имен kube-system.
На этом шаге будет подготовлен операторский модуль и будет ждать, пока его состояние не изменится на «работает», а установленные операторы не покажут «InstallSucceeded», как показано на рисунке ниже.
Вы можете перейти к Pods в проекте kube-system, чтобы проверить, создан ли и запущен ли оператор Pod.
Настройка узлов хранения
Рекомендуется использовать чистый диск, без форматирования и без подключения. В случае, если вы столкнетесь с такими проблемами, как KVDB не создает. Попробуйте следующее.
Попробуйте обнулить и посмотрите, поможет ли это. Убедитесь, что вы удалили Portworx с опцией очистки в файле yaml для кластера хранения, упомянутого в разделе удаления Portworx в этой статье.
# dd if=/dev/zero of=/dev/sdc bs=512 count=1
Метки узлов
Обязательно маркируйте узлы, если вы используете внутреннюю базу данных KVDB (Key Value Data Base). Поскольку здесь мы используем встроенный внутренний KVDB в этой настройке.
Используйте следующую команду, чтобы пометить рабочие узлы OpenShift для запуска встроенного в KVDB.
# kubectl label nodes worker0.ocp4.sjc02.lab.cisco.com px/metadata-node=true # kubectl label nodes worker1.ocp4.sjc02.lab.cisco.com px/metadata-node=true # kubectl label nodes worker2.ocp4.sjc02.lab.cisco.com px/metadata-node=true
Создание спецификаций Portworx в PX-Central
Чтобы установить Portworx в OpenShift, мы должны сначала сгенерировать спецификацию StorageCluster, которая будет использоваться для развертывания кластера хранения.
Сгенерируйте спецификацию кластера хранилища с помощью инструмента генератора спецификаций Portworx. Он доступен по адресу https://docs.portworx.com/portworx-install-with-kubernetes/openshift/operator/2-deploy-px/#.
Поскольку мы развертываем Portworx Essentials, выберите то же самое на следующем экране, как показано ниже.
Мы будем развертывать с помощью оператора Portworx. Установите флажок «Использовать оператора Portworx».
На экране хранилища
Выберите «На территории».
Выберите вручную указать диск. В этом случае мы выделим один диск, например. / dev / sdc для Portworks. Вы можете указать больше дисков, нажав знак +. Для простоты мы используем «Устройство автоматического создания журнала» и пропускаем «Устройство KVDB». Вы можете указать выделенное устройство KVDB, такое как / dev / sdd или около того, чтобы разделить ввод-вывод KVDB с вводом-выводом хранилища.
На экране сети оставьте все значения по умолчанию.
На экране настройки выберите OpenShift 4+, как показано ниже.
Щелкните Готово. Загрузите файл спецификации, указав имя. это даст вам файл .yaml для подготовки кластера хранения.
Загрузите файл спецификации. Файл спецификации будет выглядеть, как показано ниже:
# SOURCE: https://install.portworx.com/?operator=true&mc=false&kbver=&oem=esse&user=&b=true&s=%2Fdev%2Fsdc&j=auto&c=px-cluster&osft=true&stork=true&lh=true&st=k8s kind: StorageCluster apiVersion: core.libopenstorage.org/v1 metadata: name: px-cluster namespace: kube-system annotations: portworx.io/install-source: "https://install.portworx.com/?operator=true&mc=false&kbver=&oem=esse&user=&b=true&s=%2Fdev%2Fsdc&j=auto&c=px-cluster&osft=true&stork=true&lh=true&st=k8s" portworx.io/is-openshift: "true" portworx.io/misc-args: "--oem esse" spec: image: portworx/oci-monitor:2.6.1.3 imagePullPolicy: Always kvdb: internal: true storage: devices: - /dev/sdc journalDevice: auto secretsProvider: k8s stork: enabled: true args: webhook-controller: "false" userInterface: enabled: true autopilot: enabled: true providers: - name: default type: prometheus params: url: http://prometheus:9090 --- apiVersion: v1 kind: Secret metadata: name: px-essential namespace: kube-system data: px-essen-user-id: px-osb-endpoint:
Примечание. Вышеупомянутый файл yaml предназначен только для справки. Скопировать и вставить этот файл спецификации yaml не получится.
Создайте секрет для Portworx Essentials
Если вы используете кластер Portworx Essentials, создайте следующий секрет со своим Essential Entitlement ID:
Вы можете получить идентификатор доступа из своей зарегистрированной учетной записи Portworx.
Он будет выглядеть примерно так: df12e1234–1234–12ab-a1c3-c124e123c1234 (это для примера)
kubectl -n kube-system create secret generic px-essential \ — from-literal=px-essen-user-id=YOUR_ESSENTIAL_ENTITLEMENT_ID \ — from-literal=px-osb-endpoint='https://pxessentials.portworx.com/osb/billing/v1/register'
Проверьте это с помощью консоли OCP, как показано ниже.
Создать кластер хранения
Примените спецификацию, используя следующую команду
# oc apply -f px-spec.yaml
Или его можно установить прямо с portworx.com. это сгенерировано для вас во время создания спецификации для кластера хранения
# kubectl apply -f ‘https://install.portworx.com/2.6?operator=true&mc=false&kbver=&oem=esse&user=d123e123-1234-12eb-a1c1-c12e123c1234&b=true&s=%2Fdev%2Fsdc&j=auto&c=px-cluster&osft=true&stork=true&lh=true&st=k8s'
После выполнения команды. Поды начнут подготавливаться в пространстве имен kube-system, как показано ниже. Убедитесь, что все модули в конечном итоге перешли в состояние «Выполняется», а для параметра «Готовность» должно быть указано «Готово».
Убедитесь, что Portworx успешно развернут, перейдя на вкладку Кластер хранения на странице Установленные операторы. После того, как Portworx будет полностью развернут, статус отобразится как В сети.
Подтвердить установку
Проверьте, выполнив следующее, чтобы убедиться, что он установлен правильно и успешно. Убедитесь, что все модули в пространстве имен kube-system запущены и работают.
[root@rhel1 ocp-install]# oc get pods -n kube-system
Проверьте статус кластерных модулей. Поскольку мы использовали 4 рабочих узла для участия в формировании кластера Portworx, у вас будет четыре модуля кластера. Вы можете проверить каждый из них, выполнив следующую команду.
oc exec px-cluster-35526b65–8e30–446d-af4f-be66f82e745d-25x4v -n kube-system — /opt/pwx/bin/pxctl status
Выполните следующую команду, чтобы проверить состояние диска, выделенного для Portworx.
[root@rhel1 ocp-install]# for i in {worker0,worker1,worker2,worker3}; do ssh core@$i.ocp4.sjc02.lab.cisco.com lsblk /dev/sdc; done;
Внутренний kvdb использует устройство хранения / dev / sdc2 для хранения своих данных. Помните, что в нашем поколении спецификаций мы не выбирали отдельное выделенное устройство для kvdb. Мы видим два раздела / dev / sdc1 и / dev / sdc2. Устройство ведения журнала: / dev / sdc1
Удалите Portworx
Во время установки вы можете столкнуться с проблемами, и в некоторых случаях вы можете захотеть удалить и начать заново. Удаление Portworx выполняется за несколько щелчков мышью, однако, если шаги, описанные ниже, не будут выполнены, вы можете не удалить его полностью и создадите больше проблем при новой установке.
Для удаления добавьте следующее в yaml-файл кластера хранилища. Перейдите в Установленный оператор, нажмите StorageCluster и отредактируйте YAML. Следующая строка должна быть в вашем YAML-файле. Если его там нет, добавьте его и сохраните файл YAML.
spec:
deleteStrategy:
type: UninstallAndWipe
У установленных операторов. Нажмите Storage Cluster.
Нажмите Удалить StorageCluster, как показано ниже.
Отключите кластер от своего профиля, иначе при установке нового кластера будет проблема с истечением срока действия лицензии. Зайдите в свой профиль на Portworx.com и нажмите «Отменить связь».
Объемы резервов
Создать классы хранения
В консоли RHOCP нажмите «Классы хранилища», затем нажмите кнопку «Создать класс хранилища».
Щелкните Изменить YAML.
Copy and paste the following kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: portworx-sc provisioner: kubernetes.io/portworx-volume parameters: repl: "1"
Нажмите "Создать".
Класс хранилища также можно создать, сохранив указанный выше файл yaml и запустив следующий
kubectl create -f portworx-sc.yaml
проверьте, был ли создан класс хранилища, выполнив следующие
[root@rhel1 ocp-install]# kubectl describe storageclass portworx-sc Name: portworx-sc IsDefaultClass: No Annotations: <none> Provisioner: kubernetes.io/portworx-volume Parameters: repl=1 AllowVolumeExpansion: <unset> MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: Immediate Events: <none> [root@rhel1 ocp-install]#
Создать заявку на постоянный том
Используйте следующий файл yaml и сохраните его как portworx-volume-pvcsc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvcsc001
annotations:
volume.beta.kubernetes.io/storage-class: portworx-sc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
Выполните следующую команду
kubectl create -f portworx-volume-pvcsc.yaml
Вы можете создать то же самое в графическом интерфейсе, щелкнув Persistent Volume Claim, скопировать и вставить приведенный выше YAML.
Выполните следующую команду для проверки
[root@rhel1 ocp-install]# kubectl describe pvc pvcsc001 -n kube-system
Name: pvcsc001
Namespace: kube-system
StorageClass: portworx-sc
Status: Bound
Volume: pvc-00fb7cd2-638d-4f3b-a8bd-226bdaeffa97
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-class: portworx-sc
volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/portworx-volume
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 2Gi
Access Modes: RWO
VolumeMode: Filesystem
Mounted By: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ProvisioningSucceeded 79s persistentvolume-controller Successfully provisioned volume pvc-00fb7cd2-638d-4f3b-a8bd-226bdaeffa97 using kubernetes.io/portworx-volume
[root@rhel1 ocp-install]#
[root@rhel1 ocp-install]#
Создать под, который использует постоянное утверждение тома с классом хранения
apiVersion: v1
kind: Pod
metadata:
name: pvpod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/test-webserver
volumeMounts:
- name: test-volume
mountPath: /test-portworx-volume
volumes:
- name: test-volume
persistentVolumeClaim:
claimName: pvcsc001
Создайте POD, выполнив следующую команду
kubectl create -f portworx-volume-pvcscpod.yaml
Мы можем создать такой же Pod в консоли RHOCP, как показано ниже.
Нажмите Workload → Pods → Create Pod, как показано ниже.
Скопируйте и вставьте вышеупомянутое содержимое файла yaml
нажмите "Создать". Это предоставит Pod возможность монтирования томов из постоянного хранилища.
Заключение
Постоянные тома Kubernetes - это предоставляемые пользователем тома хранения, назначенные кластеру Kubernetes. Жизненный цикл постоянных томов не зависит от используемого модуля. Таким образом, постоянные тома идеально подходят для случаев использования, когда вам необходимо хранить данные независимо от непредсказуемого жизненного процесса подов Kubernetes.
Без постоянных томов поддержка таких общих служб, как база данных, была бы невозможна. Всякий раз, когда модуль заменяется, данные, полученные в течение жизненного цикла этого модуля, теряются. Однако благодаря постоянным томам данные хранятся в согласованном состоянии.
