🥇Jak zbudować hybrydową chmurę z Kubernetes, która może zastąpić DBaaS

Nazywam się Piotr Zajcew, jestem dyrektorem generalnym, założycielem Percona i chciałbym opowiedzieć:

jak przeszliśmy od rozwiązań open source do Database as a Service;
jakie są podejścia do wdrażania baz danych w chmurze;
jak Kubernetes może zastąpić DBaaS, eliminując zależność od dostawcy i zachowując prostotę DB jako usługi.

Artykuł oparty jest na wykładzie na @Databases Meetup w Mail.ru Cloud Solutions & Tarantool. Jeśli nie chcesz czytać, możesz zobaczyć:

Jak przeszliśmy od open source do Database as a Service w chmurze

Zajmuję się open source od końca lat 90-tych. Dwadzieścia lat temu korzystanie z open source, na przykład baz danych, nie było takie proste. Należało pobrać źródła, załatwić poprawki, skompilować i dopiero potem używać.

Potem open source przeszedł szereg uproszczeń:

źródła Tar.gz i INSTALL, które trzeba było kompilować;
pakiety z zależnościami typu .deb i .rpm, gdzie wystarczyło zainstalować zestaw pakietów;
repozytoria pakietów, takie jak APT i YUM, które automatyzują proces instalacji;
rozwiązania takie jak Docker i Snap, umożliwiające uzyskiwanie pakietów do instalacji bez zewnętrznych zależności.

W rezultacie korzystanie z oprogramowania open source staje się łatwiejsze, a także obniża się bariera wejścia w rozwój takich aplikacji.

Jednocześnie, w przeciwieństwie do sytuacji sprzed 20 lat, kiedy wszyscy byli ekspertami w kompilowaniu, obecnie większość programistów nie potrafi skompilować używanych narzędzi ze źródeł.

W rzeczywistości to nie jest złe, ponieważ:

Możemy korzystać z bardziej skomplikowanego, ale wygodnego oprogramowania. Na przykład przeglądarka — jest wygodna w użyciu, ale zawiera wiele komponentów open source, trudno jest ją zbudować od podstaw.
Więcej osób może zostać programistami oprogramowania open source i innych aplikacji, więcej oprogramowania wykorzystuje biznes, rośnie zapotrzebowanie na nie.

Drugą stroną medalu jest to, że kolejny krok w uproszczeniu wiąże się z wykorzystaniem rozwiązań chmurowych, co prowadzi do pewnego vendor lock-in, czyli związania z jednym dostawcą. Używamy prostych rozwiązań, a dostawcy korzystają z komponentów open source, ale faktycznie są przywiązani do jednego z dużych chmur. To znaczy, że najprostszy i najszybszy sposób wdrażania open source (i kompatybilnego z nim oprogramowania) to w chmurach, korzystając z zamkniętego API.

Jeśli chodzi o bazy danych w chmurze, istnieją dwa podejścia:

Zbudować infrastrukturę bazy danych, jak w tradycyjnym centrum danych. To znaczy wziąć standardowe elementy składowe: compute, storage i tak dalej, zainstalować na nich Linuxa, bazę danych, skonfigurować.
Skorzystać z Database as a Service, gdzie dostawca oferuje już gotową bazę danych w chmurze.

Obecnie DBaaS to szybko rosnący rynek, ponieważ taki serwis umożliwia deweloperom bezpośrednią pracę z bazami danych i minimalizuje rutynową pracę. Dostawca zajmuje się zapewnieniem wysokiej dostępności (High Availability) oraz łatwego skalowania, patchowaniem bazy danych, tworzeniem kopii zapasowych, optymalizacją wydajności.

Dwa typy Database as a Service na podstawie open source i alternatywa w postaci Kubernetes

Istnieją dwa typy Database as a Service dla otwartych baz danych:

Standardowy produkt open source, opakowany w backend do zarządzania, co ułatwia wdrażanie i zarządzanie.
Zaawansowane rozwiązanie komercyjne z różnymi dodatkami, zgodne z open source.

Obie opcje ograniczają możliwość migracji między chmurami, zmniejszają mobilność danych i aplikacji. Na przykład, mimo że różne typy chmur wspierają zasadniczo ten sam standard MySQL, istnieją między nimi istotne różnice: w działaniu, wydajności, tworzeniu kopii zapasowych i tak dalej. Migracja z jednej chmury do innej może być trudna, zwłaszcza dla skomplikowanych aplikacji.

I tu pojawia się pytanie — czy można uzyskać wygodę Database as a Service, ale jako proste rozwiązanie open source?

Zła wiadomość jest taka, że niestety w tej chwili na rynku nie ma takich rozwiązań. Dobra wiadomość — jest Kubernetes, który umożliwia realizację takich rozwiązań.

Kubernetes to system operacyjny dla chmury lub centrum danych, który pozwala na wdrażanie aplikacji i zarządzanie nimi na wielu serwerach klastra, a nie na jednym hoście.

Obecnie Kubernetes jest liderem w kategorii podobnego oprogramowania. Dla takich zadań było wiele różnych rozwiązań, ale to właśnie on stał się standardem. Wiele firm, które wcześniej zajmowały się alternatywnymi rozwiązaniami, obecnie koncentruje się na dostosowywaniu swoich produktów do wsparcia dla Kubernetes.

Ponadto, Kubernetes to uniwersalne rozwiązanie, które jest wspierane w prywatnych, publicznych i hybrydowych chmurach wielu dostawców, takich jak AWS, Google Cloud, Microsoft Azure, Mail.ru Cloud Solutions.

Jak Kubernetes współpracuje z bazami danych

Kubernetes został pierwotnie stworzony dla aplikacji stateless, które przetwarzają dane, ale ich nie przechowują, takich jak mikrousługi czy aplikacje webowe. Bazy danych znajdują się na przeciwległym końcu spektrum, czyli są to aplikacje stateful. Dlatego Kubernetes nie był pierwotnie przeznaczony do obsługi takich aplikacji.

Jednak istnieją funkcje, które pojawiły się w Kubernetesie w ostatnim czasie i umożliwiają użycie baz danych oraz innych aplikacji stateful:

Koncept StatefulSet — seria prymitywów do obsługi zdarzeń związanych z zatrzymywaniem podów oraz realizacji Graceful Shutdown (przewidywalnego zakończenia pracy aplikacji).
Persistent Volumes — magazyny danych, które są powiązane z podami oraz obiektami sterującymi Kubernetes.
Operator Framework — możliwość tworzenia komponentów do zarządzania bazami danych i innymi aplikacjami stateful rozproszonymi na wielu węzłach.

Już teraz w publicznych chmurach istnieją duże usługi Database as a Service, w których backendzie wykorzystywany jest Kubernetes, na przykład: CockroachCloud, InfluxDB, PlanetScale. Oznacza to, że baza danych na Kubernetesie to nie tylko teoretyczna możliwość, ale także rozwiązanie działające w praktyce.

Percona ma dwa rozwiązania open source dla Kubernetes:

Kubernetes Operator for Percona Server for MongoDB.
Kubernetes Operator for XtraDB CLUSTER — usługa zgodna z MySQL, zapewniająca wysoką dostępność i spójność. Można również używać pojedynczego węzła, jeśli wysoka dostępność nie jest potrzebna, na przykład do bazy danych deweloperskiej.

Użytkowników Kubernetes można podzielić na dwie grupy. Jedni korzystają z Kubernetes Operators bezpośrednio — są to głównie zaawansowani użytkownicy, którzy dobrze rozumieją, jak działa ta technologia. Inni uruchamiają go w tle — tym użytkownikom interesuje coś w rodzaju Database as a Service, nie chcą zagłębiać się w szczegóły działania Kubernetes. Dla drugiej grupy użytkowników mamy jeszcze jedno rozwiązanie open source — Percona DBaaS CLI Tool. To eksperymentalne rozwiązanie dla tych, którzy chcą uzyskać open source DBaaS na bazie Kubernetes bez głębokiej znajomości technologii.

Jak uruchomić DBaaS od Percona na Google Kubernetes Engine

Google Kubernetes Engine, moim zdaniem, to jedna z najbardziej funkcjonalnych implementacji technologii Kubernetes. Jest dostępna w wielu regionach świata i ma prosty oraz wygodny Command Line Tool (SDK), który umożliwia tworzenie skryptów, a nie ręczne zarządzanie platformą.

Aby nasz DBaaS działał, potrzebne są następujące komponenty:

Kubectl.
Google Cloud SDK.
Percona DBaaS CLI.

Instalujemy kubectl

Instalujemy pakiet dla twojego systemu operacyjnego, omówimy na przykładzie Ubuntu. Dowiedz się więcej tutaj.

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

Instalujemy Google Cloud SDK

Podobnie instalujemy pakiet oprogramowania. Dowiedz się więcej tutaj.

# 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

Instalujemy Percona DBaaS CLI

Instalujemy z repozytoriów Percona. Percona DBaaS CLI Tool to produkt w fazie eksperymentalnej, dlatego znajduje się w eksperymentalnym repozytorium, które należy włączyć osobno, nawet jeśli masz już zainstalowane repozytoria Percona.

Dowiedz się więcej tutaj.

Algorytm instalacji:

Skonfiguruj repozytoria Percona za pomocą narzędzia percona-release. Najpierw musisz pobrać i zainstalować oficjalny pakiet percona-release od Percona:
```
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
```
Włącz eksperymentalny komponent repozytoriów narzędzi w następujący sposób:
```
sudo percona-release enable tools experimental
```

Zainstaluj pakiet percona-dbaas-cli:

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

Konfigurujemy działanie komponentów

Dowiedz się więcej o ustawieniach tutaj.

Najpierw musisz zalogować się na swoje konto Google. Następnie Google Cloud pozwala jednemu użytkownikowi mieć wiele niezależnych projektów, dlatego trzeba wskazać roboczy projekt, używając kodu tego projektu:

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

Następnie tworzymy klaster. Dla demonstracji stworzyłem klaster Kubernetes składający się z trzech węzłów — to minimalna liczba wymagana dla wysokiej dostępności:

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

Następna komenda kubectl przyznaje odpowiednie uprawnienia naszemu bieżącemu użytkownikowi:

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

Następnie tworzymy namespace i ustalamy go jako aktywny. Namespace to, w przybliżeniu, coś w rodzaju projektu lub środowiska, ale już wewnątrz klastra Kubernetes. Jest niezależny od projektów Google Cloud:

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

Uruchamiamy klaster

Po przejściu przez te kilka kroków, możemy uruchomić klaster z trzech węzłów za pomocą tej prostej komendy:

# 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

Jak połączyć się z klastrem

Domyślnie jest dostępny tylko wewnątrz Kubernetes. To znaczy, że z tego serwera, z którego uruchomiłeś komendę „Utwórz”, nie jest dostępny. Aby stał się dostępny, na przykład do testów z klientem, należy przenieść port za pomocą mapowania portów:

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

Następnie łączymy się z klientem MySQL:

mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP

Zaawansowane polecenia zarządzania klastrem

Baza danych na publicznym adresie IP

Jeśli chcesz bardziej trwałego rozwiązania dla dostępności klastra, możesz uzyskać zewnętrzny adres IP. W takim przypadku baza danych będzie dostępna z dowolnego miejsca. Jest to mniej bezpieczne, ale często bardziej wygodne. Aby uzyskać zewnętrzny adres IP, użyj poniższego polecenia:

# 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

Jawnie ustawiamy hasło

Zamiast tego, aby system generował hasło losowo, możesz jawnie ustawić hasło:

# 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

Pokazuję wyjście skryptów w czytelnej formie, ale obsługiwany jest również format JSON.

Wyłączamy wysoką dostępność

Następnym poleceniem można wyłączyć wysoką dostępność, aby wdrożyć pojedynczy węzeł:

# 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

To rozwiązanie do zadań testowych, aby jak najszybciej i najprościej uruchomić MySQL, przetestować, a następnie zamknąć lub użyć do rozwoju.

Narzędzie Percona DBaaS CLI pomaga uzyskać rozwiązanie na Kubernetes, podobne do DBaaS. Kontynuujemy pracę nad jego funkcjonalnością i użytecznością.

Ta prezentacja pierwszy raz została zaprezentowana na @Databases Meetup by Mail.ru Cloud Solutions&Tarantool. Zobacz wideo inne prezentacje i subskrybuj zapowiedzi wydarzeń w Telegramie Wokół Kubernetes w Mail.ru Group.

Co jeszcze przeczytać na ten temat:

Źródło: habr.com