Осенью 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 для управления кластерами БД:

  • Percona XtraDB Cluster Operator

  • Percona Operator for PostrgreSQL

  • Percona Operator for MongoDB

• 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.

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

• Как построить локальный self-managed Kubernetes-кластер

• Обзор UI-инструментов для мониторинга и управления кластерами Apache Kafka

• Наш опыт с графовой базой данных Dgraph в Kubernetes

• Разворачиваем Kubernetes-кластер на bare metal под управлением Deckhouse и создаем в нем виртуальные машины