🥇Як сабраць гібрыднае воблака з дапамогай Kubernetes, якое можа замяніць DBaaS

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

як мы ад open source-рашэнняў дашлі да Database as a Service;
якія існуюць падыходы да разгортвання баз дадзеных у воблаку;
як Kubernetes можа замяніць DBaaS, устараніўшы залежнасць ад вендара і захаваўшы прастату СКБД як сэрвісу.

Артыкул падрыхтавана на аснове даклада на 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 гадоў таму, калі ўсе былі экспертамі па зборцы, зараз большасць распрацоўшчыкаў не могуць сабраць з зыходнікаў інструменты, якія выкарыстоўваюцца.

Насамрэч, гэта нядрэнна, бо:

Мы можам выкарыстоўваць больш складанае, але зручнейшае праграмнае забеспячэнне. Напрыклад, браўзэр - зручна выкарыстоўваць, але ў яго ўваходзіць шмат open source-кампанентаў, яго няёмка збіраць з нуля.
Больш людзей могуць стаць распрацоўшчыкамі open source і іншага праграмнага забеспячэння, больш ПА выкарыстоўвае бізнэс, вышэй запатрабаванне ў ім.

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

Калі казаць аб базах дадзеных у воблаку, ёсць два падыходу:

Сабраць інфраструктуру базы дадзеных, як у звычайным дата-цэнтры. Гэта значыць узяць стандартныя кампанавальныя блокі: compute, storage і гэтак далей, паставіць на іх Linux, базу дадзеных, наладзіць.
Выкарыстоўваць Database as a Service, дзе правайдэр прапануе ўжо гатовую базу дадзеных усярэдзіне аблокаў.

Цяпер DBaaS – гэта хутка які расце рынак, таму што такі сэрвіс дазваляе распрацоўнікам працаваць з базамі дадзеных напроста і мінімізуе руцінную працу. Правайдэр бярэ на сябе забеспячэнне High Availability (высокай даступнасці) і лёгкага маштабавання, патчынг базы дадзеных, бэкапы, наладу прадукцыйнасці.

Два тыпы Database as a Service на аснове open source і альтэрнатыва ў выглядзе Kubernetes

Ёсць два тыпу Database as a Service для адкрытых баз дадзеных:

Стандартны open source-прадукт, спакаваны ў бэкэнд для адміністравання, што спрашчае разгортванне і кіраванне.
Прасунутае камерцыйнае рашэнне з рознымі дадаткамі, сумяшчальнае з 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-прыкладанні:

Канцэпт StatefulSet - цэлая серыя прымітываў для апрацоўкі падзей аб спыненні працы подаў і ажыццяўлення Graceful Shutdown (прадказальнага завяршэння працы прыкладання).
Persistent Volumes - сховішчы дадзеных, якія звязаны з падамі, аб'ектамі кіравання Kubernetes.
Operator Framework - гэта значыць магчымасць ствараць кампаненты для кіравання базамі дадзеных і іншымі stateful-прыкладаннямі, размеркаванымі на шматлікіх вузлах.

Ужо зараз у публічных аблоках ёсць буйныя Database as a Service, у бэкендзе якіх Kubernetes, напрыклад: CockroachCloud, InfluxDB, PlanetScale. Гэта значыць база дадзеных на Kubernetes - гэта не толькі тое, што тэарэтычна магчыма, але і тое, што працуе на практыцы.

У Percona ёсць два open source рашэнні для Kubernetes:

Kubernetes Operator для Percona Server для MongoDB.
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 зарабіў, патрэбны наступныя кампаненты:

Kubectl.
Google Cloud SDK.
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.

Больш падрабязна тут.

Алгарытм усталёўкі:

Наладзьце рэпазітары 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
```
Уключыце эксперыментальны кампанент рэпазітара інструментаў наступным чынам:
```
sudo percona-release enable tools experimental
```

Усталюйце 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.

Што яшчэ пачытаць па тэме:

Крыніца: habr.com

Як сабраць гібрыднае воблака з дапамогай Kubernetes, якое можа замяніць DBaaS