Знакомство с Percona Everest [Beta] — инструментом для управления кластерами баз данных

Осенью 2023 года вышла Alpha-версия Percona Everest — нового продукта от компании Percona. Это cloud-native database platform — инструмент с графическим интерфейсом для управления кластерами баз данных, развёрнутыми в Kubernetes.

22 февраля 2024 года Percona Everest перешла в состояние Beta. Обновлённый продукт сильно отличается от первой версии — разработчики проделали большой объем работы. В сегодняшней статье разберём, как выглядит Beta-версия Percona Everest и как её установить. Также рассмотрим, чего не хватает инструменту, на наш взгляд, на текущий момент.

О продукте

Percona Everest позволяет с помощью веб-интерфейса в несколько кликов развернуть в Kubernetes-кластере кластер БД с требуемыми характеристиками. Инструмент не зависит от вендора Kubernetes-кластера и сам является Open Source-решением. Это позволяет реализовать собственный вендоронезависимый Database-as-a-Service.

Репозиторий: https://github.com/percona/everest

Лицензия: Apache 2.0

Поддерживаемые СУБД: MySQL 8.0, PostgreSQL v12 .. v16, MongoDB v4.4 .. v6.0

На сегодняшний день, если взглянуть высокоуровнево, Percona Everest — это совокупность следующих компонентов:

Frontend для пользовательского UI.
Операторы Percona для управления кластерами БД:

OLM, служащий для управления перечисленными операторами, а также для развёртывания БД нужного типа.
Встроенное средство мониторинга и отправки телеметрии Everest на серверы Percona.

Возможности

Сейчас в инструменте реализованы следующие функции:

Создание и удаление кластера БД.
Автоматическое переключение ролей Leader/Follower.
Резервное копирование. Доступно создание резервных копий БД в AWS S3-совместимое хранилище. Выполнение резервного копирования возможно как по расписанию, так и по кнопке:

Восстановление из резервной копии в существующий кластер БД. Также возможно создание нового кластера из резервной копии:

Восстановление на момент времени (Point-in-time recovery, PITR):

Поддержка объектных хранилищ для бэкапов не только Virtual-hosted-style, но и Path-style.
Поддержка выбора StorageClass при развёртывании БД.
Поддержка кастомных конфигураций. Конфигурирование возможно как при развёртывании кластера БД, так и во время его работы:

Поддержка ручного горизонтального и вертикального скейлинга кластера БД. Особенно приятно при этом видеть предполагаемые доступные ресурсы в Kubernetes-кластере (estimated available):

Автоматическое развёртывание Haproxy для MySQL.
Автоматическое развёртывание PgBouncer для PostgreSQL.
Поддержка подключения к произвольному PMM-сервису с отправкой данных мониторинга по push-модели:

Inventory в PMM:

Установка

Для установки Everest требуются заранее развёрнутый Kubernetes-кластер и kube config для него.

Установка производится с помощью cli-утилиты everestctl:

everestctl install --kubeconfig "/my/path/to/kube/config" --namespaces dev,prod --operator.mongodb=true --operator.postgresql=true --operator.xtradb-cluster=true --skip-wizard

Здесь dev и prod — пространства имён, в каждое из которых будет установлен набор из перечисленных операторов БД. Если раньше пространств имён не было, они будут созданы.

Если в дальнейшем потребуется передать под контроль Everest дополнительное пространство имён, необходимо вызвать команду everestctl install несколько раз.
Например:

everestctl install --namespaces dev --operator.postgresql=true --skip-wizard everestctl install --namespaces prod --operator.postgresql=true --skip-wizard

Установить разные наборы операторов БД в разные пространства имён на сегодняшний день невозможно.

Для удаления пространства имён из-под управления Everest пока также нет средств. Можно только удалить пространство имён вручную, так как everestctl uninstall попытается удалить все инсталляции целиком.

Установка нескольких копий операторов БД в разные пространства имён выглядит избыточным, но это позволяет выборочно обновлять версии операторов с помощью everestctl upgrade --namespaces.

Наконец, для доступа к веб-интерфейсу Everest потребуется проброс порта, или публикация сервиса everest на внешнем IP тем или иным образом, или просто деплой Ingress. Например:

apiVersion: networking.k8s.io/v1 kind: Ingress metadata:   name: everest   namespace: everest-system spec:   ingressClassName: nginx   rules:   - host: everest.mydomain.com     http:       paths:       - backend:           service:             name: everest             port:               number: 8080         path: /         pathType: Prefix   tls:   - hosts:     - everest.mydomain.com     secretName: everest-tls

При первом нашем знакомстве с Percona Everest были не вполне очевидны все сценарии использования этого инструмента. Например, было не ясно, возможен ли GitOps-подход для управления инфраструктурой при его использовании. Но сейчас мы выяснили, что это вполне возможно. Можно вручную задеплоить в пространство имён, находящееся под контролем Everest, секрет с паролями для БД и манифест Custom Resource databaseclusters.everest.percona.com, при этом Everest развернёт кластер БД и отобразит его в UI.

Пример для Percona XtraDB Cluster:

--- apiVersion: v1 kind: Secret metadata:   name: everest-secrets-mysql-dev-from-git   namespace: dev type: Opaque data:   clustercheck: JiFvLk9IdEEjTntpISYoQA==   monitor: IyslSmlJdHZVYiYxS2FMSS0=   operator: Rm55NSZAVERAI1hKJTx0dXs=   proxyadmin: bThRUX0oNHcjMEBvRWJBMg==   replication: cnAwejUmTkBfN1F2JTVSIw==   root: cyxENzxHcmduRmliWXh3ZFpjPQ==   xtrabackup: S0tyUz9RcEpMKT1MWS5VRz8= --- apiVersion: everest.percona.com/v1alpha1 kind: DatabaseCluster metadata:   labels:     backupStorage-golf-ya-cloud: used     clusterName: mysql-dev-from-git   name: mysql-dev-from-git   namespace: dev spec:   allowUnsafeConfiguration: true   backup:     enabled: true     pitr:       backupStorageName: golf-ya-cloud       enabled: true     schedules:     - backupStorageName: golf-ya-cloud       enabled: true       name: mysql-dev-from-git       retentionCopies: 10       schedule: 0 11 * * *   engine:     config: |-       [mysqld]       max_connections=100     replicas: 1     resources:       cpu: 600m       memory: 1G     storage:       class: ceph-ssd       size: 1G     type: pxc     userSecretsName: everest-secrets-mysql-dev-from-git     version: 8.0.23-14.1   monitoring:     resources: {}   proxy:     expose:       type: internal     replicas: 1     resources:       cpu: "0"       memory: "0"     type: haproxy

Возможности, которых не хватает

Что хотелось бы видеть среди возможностей Everest:

Управление временем жизни бэкапов БД PostgreSQL через GUI. Веб-интерфейс Everest, начиная с версии v0.10, поддерживает возможность указания retention для MySQL и MongoDB. Для управления этим параметром в кластерах PostgreSQL пока придётся вручную отредактировать CR databaseclusters.everest.percona.com, а именно значение поля retentionCopies.
Возможность скейлинга размера диска. На данный момент для скейлинга диска возможно только создание нового кластера БД с новыми параметрами из бэкапа старого кластера.
Возможность апгрейда версии БД.
Возможность задания параметров podAntiAffinity, nodeAffinity и tolerations.
Более удобную систему добавления и удаления пространств имён в Everest.
Возможность задания своего набора операторов БД для каждого пространства имён.
Поддержку RBAC для UI Everest (в планах с пометкой «Coming soon», пока же есть только административный доступ для единственного суперпользователя).
Отображение прогресса выполнения операции развёртывания и реконфигурации в веб-интерфейсе, а также отображение состояния реплик. Возникали ситуации, когда кластер замирал в UI в статусе Initializing из-за того, что поды с БД были в CrashLoopBackOff из-за постоянных ООМ kill, или ошибки в кастомной конфигурации.
Управление пользователями БД в UI.
DownScale до одной реплики. Хотя создание с нуля кластера из одной реплики возможно, DownScale пока работает лишь частично. UpScale кластеров БД с 1 до N реплик работает без нареканий.
Вариант развёртывания Everest в Kubernetes-кластере не только с помощью binary-утилиты everestctl, но и с помощью манифестов для обеспечения возможности управления деплоем через git. Пока же для реализации этого необходим определённый реверс-инжиниринг.

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

Выводы

В настоящий момент не у всех операторов СУБД для Kubernetes есть веб-интерфейс. Те же, у которых есть собственные GUI, как правило, позволяют управлять только СУБД определённого типа. Также существуют свои проприетарные реализации GUI для управления Managed-DB в различных облачных сервисах. Благодаря Everest появляется возможность управлять через единый интерфейс тройкой популярных СУБД в едином ключе, развернув собственный DBaaS.

Мы активно используем в повседневной работе различные разработки Percona и благодарны им за отличные инструменты. Будем в дальнейшем с интересом следить за развитием Everest.

P. S.

Читайте также в нашем блоге:

ссылка на оригинал статьи https://habr.com/ru/articles/817685/