Як зібрати гібридну хмару за допомогою Kubernetes, яка може замінити DBaaS

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

  • як ми від 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 для Percona Server для 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 використовуємо таку команду:

# 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. Як вибрати базу даних для проекту, щоби не вибирати знову.

Джерело: habr.com

Додати коментар або відгук