company_banner

Как собрать гибридное облако с помощью Kubernetes, которое может заменить DBaaS

    Меня зовут Петр Зайцев, я генеральный директор, основатель Percona и хочу рассказать:

    • как мы от open source-решений пришли к Database as a Service;
    • какие существуют подходы к развертыванию баз данных в облаке;
    • как Kubernetes может заменить DBaaS, устранив зависимость от вендора и сохранив простоту СУБД как сервиса.

    Статья подготовлена на основе доклада на @Databases Meetup by Mail.ru Cloud Solutions & Tarantool. Если не хотите читать, можно посмотреть:



    Как от open source пришли к Database as a Service в облаке


    Я занимаюсь open source с конца 90-х годов. Двадцать лет назад пользоваться open source, например базами данных, было не так просто. Надо было скачать исходники, пропатчить, скомпилировать и только потом использовать.

    Затем open source пережил серию упрощений:

    • исходники Tar.gz и INSTALL, которые нужно было компилировать;
    • пакеты с зависимостями типа .deb и.rpm, где нужно только установить набор пакетов;
    • репозитории пакетов вроде APT и YUM, с помощью которых установка происходит автоматически;
    • такие решения как Docker и Snap, позволяющие получать пакеты по инсталляции без внешних зависимостей.

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

    При этом, в отличие от ситуации 20 лет назад, когда все были экспертами по сборке, сейчас большинство разработчиков не могут собрать из исходников используемые инструменты.

    На самом деле, это неплохо, так как:

    1. Мы можем использовать более сложное, но более удобное программное обеспечение. Например, браузер — удобно использовать, но в него входит много open source-компонентов, его неудобно собирать с нуля.
    2. Больше людей могут стать разработчиками open source и другого программного обеспечения, больше ПО использует бизнес, выше потребность в нем.

    Обратная сторона — следующий шаг в упрощении связан с использованием облачных решений, а это приводит к определенному vendor lock-in, то есть привязке к одному поставщику. Мы используем простые решения и провайдеры используют open source-компоненты, но фактически они прибиты гвоздями к одному из крупных облаков. То есть самый простой и быстрый способ разворачивать open source (и совместимое с ним ПО) — в облаках, используя проприетарный API.

    Если говорить о базах данных в облаке, есть два подхода:

    1. Собрать инфраструктуру базы данных, как в обычном дата-центре. То есть взять стандартные компоновочные блоки: compute, storage и так далее, поставить на них Linux, базу данных, настроить.
    2. Использовать Database as a Service, где провайдер предлагает уже готовую базу данных внутри облака.

    Сейчас DBaaS — это быстро растущий рынок, потому что такой сервис позволяет разработчикам работать с базами данных напрямую и минимизирует рутинную работу. Провайдер берет на себя обеспечение High Availability (высокой доступности) и легкого масштабирования, патчинг базы данных, бэкапы, настройку производительности.

    Два типа Database as a Service на основе open source и альтернатива в виде Kubernetes


    Есть два типа Database as a Service для открытых баз данных:

    1. Стандартный open source-продукт, упакованный в бэкенд для администрирования, что упрощает развертывание и управление.
    2. Продвинутое коммерческое решение с разными дополнениями, совместимое с open source.

    Оба варианта снижают возможность миграции между облаками, уменьшают портативность данных и приложений. Например, несмотря на то, что разные виды облаков поддерживают, по сути, тот же стандартный MySQL, между ними есть существенные отличия: в работе, производительности, бэкапировании и так далее. Мигрировать с одного облака на другое может быть непросто, особенно для сложных приложений.

    И тут возникает вопрос — можно ли получить удобство Database as a Service, но как простое open source-решение?

    Плохая новость в том, что, к сожалению, пока таких решений на рынке нет. Хорошая новость — есть Kubernetes, который позволяет такие решения реализовать.

    Kubernetes — это операционная система для облака или дата-центра, которая позволяет деплоить приложение и управлять им на множестве серверов кластера, а не на одном хосте.

    Сейчас Kubernetes — лидер в категории подобного ПО. Для таких задач было много разных решений, но именно он стал стандартом. Многие компании, которые раньше занимались альтернативными решениями, сейчас фокусируются на адаптации своих продуктов для поддержки Kubernetes.

    Кроме того, Kubernetes — универсальное решение, которое поддерживается в частных, общедоступных и гибридных облаках многих вендоров, например: AWS, Google Cloud, Microsoft Azure, Mail.ru Cloud Solutions.

    Как Kubernetes работает с базами данных


    Kubernetes изначально разработали для stateless-приложений, которые обрабатывают данные, но ничего не хранят, например, микросервисы или веб-приложения. Базы данных находятся на другом конце спектра, то есть это — stateful-приложения. И Kubernetes для таких приложений изначально был не предназначен.

    Однако есть фичи, которые появились в Kubernetes в последнее время и позволяют использовать базы данных и другие stateful-приложения:

    1. Концепт StatefulSet — целая серия примитивов для обработки событий об остановке работы подов и осуществления Graceful Shutdown (предсказуемого завершения работы приложения).
    2. Persistent Volumes — хранилища данных, которые связаны с подами, объектами управления Kubernetes.
    3. Operator Framework — то есть возможность создавать компоненты для управления базами данных и другими stateful-приложениями, распределенными на многих узлах.

    Уже сейчас в публичных облаках есть крупные Database as a Service, в бэкенде которых Kubernetes, например: CockroachCloud, InfluxDB, PlanetScale. То есть база данных на Kubernetes — это не только то, что теоретически возможно, но и то, что работает на практике.

    У Percona есть два open source решения для Kubernetes:

    1. Kubernetes Operator for Percona Server for MongoDB.
    2. Kubernetes Operator for XtraDB CLUSTER — сервис, который совместим с MySQL, обеспечивает высокую доступность и консистентность. Также можно использовать single node, если высокая доступность не нужна, например для dev database.

    Пользователей Kubernetes можно разделить на две группы. Одни используют Kubernetes Operators напрямую — это, в основном, продвинутые пользователи, которые хорошо понимают, как работает технология. Другие запускают его на бэкенде — таким пользователям интересно что-то вроде Database as a Service, они не хотят вникать в нюансы работы Kubernetes. Для второй группы пользователей у нас есть еще одно open source решение — Percona DBaaS CLI Tool. Это экспериментальное решение для тех, кто хочет получить open source DBaaS на основе Kubernetes без глубокого понимания технологии.

    Как запустить DBaaS от Percona на Google Kubernetes Engine


    Google Kubernetes Engine, на мой взгляд, одна из самых функциональных реализаций технологии Kubernetes. Она доступно во многих регионах мира и обладает простым и удобным Command Line Tool (SDK), позволяющим создавать скрипты, а не управлять платформой вручную.

    Для того чтобы наш DBaaS заработал, нужны следующие компоненты:

    1. Kubectl.
    2. Google Cloud SDK.
    3. Percona DBaaS CLI.

    Устанавливаем kubectl


    Устанавливаем пакет для вашей операционной системы, мы рассмотрим на примере Ubuntu. Подробнее тут.

    sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
    curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
    echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
    sudo apt-get update
    sudo apt-get install -y kubectl
    

    Устанавливаем Google Cloud SDK


    Аналогично устанавливаем пакет ПО. Подробнее тут.

    # Add the Cloud SDK distribution URI as a package source
    echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] 
    http://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
    
    # Import the Google Cloud Platform public key
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
    
    # Update the package list and install the Cloud SDK
    sudo apt-get update && sudo apt-get install google-cloud-sdk
    

    Устанавливаем Percona DBaaS CLI


    Устанавливаем из репозиториев Percona. Percona DBaaS CLI Tool — продукт пока экспериментальный, поэтому находится в экспериментальном репозитории, который нужно включить отдельно, даже если у вас уже установлены репозитории Percona.

    Подробнее тут.

    Алгоритм установки:

    1. Настройте репозитории Percona с помощью инструмента percona-release. Сначала вам нужно скачать и установить официальный пакет percona-release от Percona:

      wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
      sudo dpkg -i percona-release_latest.generic_all.deb
    2. Включите экспериментальный компонент репозитория инструментов следующим образом:

      sudo percona-release enable tools experimental
      
    3. Установите percona-dbaas-cli пакет:

      sudo apt-get update
      sudo apt-get install percona-dbaas-cli

    Настраиваем работу компонентов


    Подробнее о настройках тут.

    Сначала нужно залогиниться в аккаунт Google. Дальше Google Cloud позволяет одному пользователю иметь много независимых проектов, поэтому требуется указать рабочий проект, используя код этого проекта:

    gcloud auth login
    gcloud config set project hidden-brace-236921
    

    Далее создаем кластер. Для демо я создал Kubernetes-кластер всего из трех нодов — это минимум, который требуется для высокой доступности:

    gcloud container clusters create --zone us-central1-a your-cluster-name --cluster-version 1.15 --num-nodes=3
    

    Следующая команда kubectl дает нужные привилегии нашему текущему пользователю:

    kubectl create clusterrolebinding cluster-admin-binding-$USER 
    --clusterrole=cluster-admin --user=$(gcloud config get-value core/account)

    Затем мы создаем namespace и делаем его активным. Namespace — это, грубо говоря, тоже как проект или environment, но уже внутри Kubernetes-кластера. Он независим от проектов Google Cloud:

    kubectl create namespace my-namespace
    kubectl config set-context --current --namespace=my-namespace
    

    Запускаем кластер


    После того, как мы прошли через эти несколько шагов, можем запустить кластер из трех узлов вот такой простой командой:

    # percona-dbaas mysql create-db example
    Starting ......................................... [done]
    Database started successfully, connection details are below:
    Provider:          k8s
    Engine:            pxc
    Resource Name:     example
    Resource Endpoint: example-proxysql.my-namespace.pxc.svc.local
    Port:              3306
    User:              root
    Pass:              Nt9YZquajW7nfVXTTrP
    Status:            ready
    

    Как подключиться к кластеру


    По умолчанию он доступен только внутри Kubernetes. То есть с этого сервера, с которого вы запустили команду «Создать», он не доступен. Чтобы он стал доступен, например для тестов с клиентом, нужно прокинуть порт через Port Mapping:

    kubectl port-forward svc/example-proxysql 3306:3306 $

    Потом подключаем ваш MySQL-клиент:

    mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP
    

    Продвинутые команды управления кластером


    База данных на публичном IP


    Если хочется более постоянного решения для доступности кластера, можно получить внешний IP-адрес. В этом случае база данных будет доступна откуда угодно. Это менее безопасно, но часто более удобно. Для внешнего IP используем следующую команду:

    # percona-dbaas mysql create-db exposed 
    --options="proxysql.serviceType=LoadBalancer"
    Starting ......................................... [done]
    Database started successfully, connection details are below:
    Provider:          k8s
    Engine:            pxc
    Resource Name:     exposed
    Resource Endpoint: 104.154.133.197
    Port:              3306
    User:              root
    Pass:              k0QVxTr8EVfgyCLYse
    Status:            ready
    
    To access database please run the following command:
    mysql -h 104.154.133.197 -P 3306 -uroot -pk0QVxTr8EVfgyCLYse
    

    Явно задаем пароль


    Вместо того, чтобы система генерировала пароль случайным образом, вы можете задать пароль явно:

    # percona-dbaas mysql create-db withpw --password=mypassword
    Starting ......................................... [done]
    Database started successfully, connection details are below:
    Provider:          k8s
    Engine:            pxc
    Resource Name:     withpw
    Resource Endpoint: withpw-proxysql.my-namespace.pxc.svc.local
    Port:              3306
    User:              root
    Pass:              mypassword
    Status:            ready
    

    Я показываю вывод скриптов в читабельном формате, но также поддерживается формат JSON.

    Выключаем высокую доступность


    Следующей командой можно выключить высокую доступность, чтобы развернуть single node:

    # percona-dbaas mysql create-db singlenode 
    --options="proxysql.enabled=false, allowUnsafeConfigurations=true,pxc.size=1"
    Starting ......................................... [done]
    Database started successfully, connection details are below:
    Provider:          k8s
    Engine:            pxc
    Resource Name:     singlenode
    Resource Endpoint: singlenode-pxc.my-namespace.pxc.svc.local
    Port:              3306
    User:              root
    Pass:              22VqFD96mvRnmPMGg
    Status:            ready
    

    Это решение для тестовых задач, чтобы максимально быстро и просто поднять MySQL, протестировать, а потом свернуть или использовать для разработки.

    Инструмент Percona DBaaS CLI помогает получить решение на Kubernetes, подобное DBaaS. При этом мы продолжаем работать над его функционалом и юзабилити.

    Этот доклад впервые прозвучал на @Databases Meetup by Mail.ru Cloud Solutions&Tarantool. Смотрите видео других выступлений и подписывайтесь на анонсы мероприятий в Telegram Вокруг Kubernetes в Mail.ru Group.

    Что еще почитать по теме:

    1. Базы данных в современной IIoT-платформе.
    2. Как выбрать базу данных для проекта, чтобы не выбирать снова.
    Mail.ru Group
    Строим Интернет

    Комментарии 3

      0
      бинарники Tar.gz и INSTALL, которые нужно было компилировать;

      репозитории пакетов вроде APT и YAM, с помощью которых установка происходит автоматически;

      Вы серьёзно?

      1. Бинарники компилировать? Может всё же компилировать из исходников (*.tar.gz) или ставить уже скомпилированные (INSTALL с правами 755 и первой строкой #!/bin/sh)?

      2. YAM? Может yum?

      3. И когда это apt (хотя на самом деле dpkg) и yum стали репозиториями?

        0
        1. Бинарники компилировать? Может всё же компилировать из исходников (*.tar.gz) или ставить уже скомпилированные (INSTALL с правами 755 и первой строкой #!/bin/sh)?

        Чё к словам придираетесь.
        Это очевидно опечатка. Слово «бинарники» просто должно идти после слова «компилировать».
        0
        Ну не бинарники а исходники. Ну не Yam a Yum все верно — есть мелкие недочеты в расшифровке. Суть главное в том что мир стремится к упрощению :)

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

        Самое читаемое