🥇Kiel konstrui hibridan nubon uzante Kubernetes, kiu povas anstataŭigi DBaaS

Mi nomiĝas Petr Zaitsev, mi estas la ĉefoficisto, fondinto percona kaj mi volas diri al vi:

kiel ni venis de malfermfontaj solvoj al Database as a Service;
kiaj aliroj ekzistas por deploji datumbazojn en la nubo;
kiel Kubernetes povas anstataŭigi DBaaS, forigante vendistan dependecon kaj konservante la simplecon de DBMS kiel servo.

La artikolo estis preparita surbaze de raporto ĉe @Databases Meetup de Mail.ru Cloud Solutions & Tarantool. Se vi ne volas legi, vi povas spekti:

Kiel ni venis de malferma fonto al Datumaro kiel Servo en la nubo

Mi laboras en malferma fonto ekde la fino de la 90-aj jaroj. Antaŭ dudek jaroj, uzi malferman fonton, kiel datumbazojn, ne estis tiel facila. Necesis elŝuti la fontkodon, fliki ĝin, kompili ĝin kaj nur tiam uzi ĝin.

Malferma fonto tiam ekzamenis serion de simpligoj:

Tar.gz kaj INSTALL fontoj kiuj bezonis esti kompilitaj;
pakaĵoj kun dependecoj kiel .deb kaj .rpm, kie vi nur bezonas instali aron da pakaĵoj;
pakaĵdeponejoj kiel APT kaj YUM, kun kiuj instalado estas aŭtomata;
solvoj kiel Docker kaj Snap, kiuj ebligas al vi ricevi pakaĵojn per instalado sen eksteraj dependecoj.

Kiel rezulto, iĝas pli facile uzi malfermfontecan programaron kaj ankaŭ malaltigas la baron al eniro en evoluigado de tiaj aplikoj.

Samtempe, male al la situacio antaŭ 20 jaroj, kiam ĉiuj estis asemblea fakulo, nun plej multaj programistoj ne povas konstrui la ilojn, kiujn ili uzas de la fonto.

Fakte, ĉi tio ne estas malbona, ĉar:

Ni povas uzi pli kompleksajn sed pli uzeblajn programojn. Ekzemple, retumilo estas oportuna por uzi, sed ĝi inkluzivas multajn malfermfontajn komponantojn kaj estas maloportuna konstrui de nulo.
Pli da homoj povas fariĝi programistoj de malferma fonto kaj alia programaro, pli da programaro estas uzata de entreprenoj, kaj la bezono de ĝi estas pli granda.

La malavantaĝo estas, ke la sekva paŝo en simpligo estas asociita kun la uzo de nubaj solvoj, kaj ĉi tio kondukas al certa vendisto-ŝlosado, tio estas, ligado al unu provizanto. Ni uzas simplajn solvojn kaj provizantoj uzas malfermfontajn komponantojn, sed fakte ili estas najlitaj al unu el la grandaj nuboj. Tio estas, la plej facila kaj rapida maniero deploji malferman fonton (kaj programaron kongruan kun ĝi) estas en la nuboj, uzante proprietan API.

Kiam temas pri datumbazoj en la nubo, ekzistas du aliroj:

Kunvenu la datumbazan infrastrukturon, kiel en regula datuma centro. Tio estas, prenu normajn konstrubriketojn: komputi, stokadon, ktp, instalu Linukson kaj datumbazon sur ili, kaj agordu ilin.
Uzu Datumbazon kiel Servon, kie la provizanto ofertas pretan datumbazon ene de la nubo.

DBaaS estas rapide kreskanta merkato nun ĉar ĝi permesas al programistoj labori rekte kun datumbazoj kaj minimumigas rutinan laboron. La provizanto entreprenas certigi Alta Haveblecon kaj facilan skaladon, datumbazajn flikaĵojn, sekurkopiojn kaj agordon de rendimento.

Du specoj de Datumaro kiel Servo bazita sur malferma fonto kaj alternativo en la formo de Kubernetes

Estas du specoj de Datumbazo kiel Servo por malfermaj datumbazoj:

Norma malfermfonta produkto enpakita en administra backend por facila deplojo kaj administrado.
Altnivela komerca solvo kun diversaj aldonaĵoj, kongrua kun malferma fonto.

Ambaŭ opcioj reduktas la eblecon de migrado inter nuboj kaj reduktas la porteblon de datumoj kaj aplikoj. Ekzemple, malgraŭ la fakto, ke malsamaj specoj de nuboj subtenas esence la saman norman MySQL, estas gravaj diferencoj inter ili: en funkciado, rendimento, sekurkopio, ktp. Migri de unu nubo al alia povas esti malfacila, precipe por kompleksaj aplikoj.

Kaj ĉi tie staras la demando - ĉu eblas akiri la oportunon de Database kiel Servo, sed kiel simpla malfermfonta solvo?

La malbona novaĵo estas, ke, bedaŭrinde, ankoraŭ ne ekzistas tiaj solvoj sur la merkato. La bona novaĵo estas, ke ekzistas Kubernetes, kiu ebligas al vi efektivigi tiajn solvojn.

Kubernetes estas operaciumo por la nubo aŭ datumcentro, kiu permesas vin disfaldi kaj administri aplikaĵon tra pluraj serviloj en areto prefere ol sur ununura gastiganto.

Nun Kubernetes estas la gvidanto en la kategorio de tia programaro. Estis multaj malsamaj solvoj por tiaj problemoj, sed ĝi fariĝis la normo. Multaj kompanioj, kiuj kutimis koncentriĝi pri alternativaj solvoj, nun koncentriĝas pri adapto de siaj produktoj por subteni Kubernetes.

Krome, Kubernetes estas universala solvo, kiu estas subtenata en privataj, publikaj kaj hibridaj nuboj de multaj vendistoj, ekzemple: AWS, Google Cloud, Microsoft Azure, Mail.ru Cloud Solutions.

Kiel Kubernetes funkcias kun datumbazoj

Kubernetes estis origine desegnita por sennaciaj aplikoj, kiuj prilaboras datumojn sed ne stokas ion ajn, kiel ekzemple mikroservoj aŭ retaj aplikoj. Datumbazoj estas ĉe la alia fino de la spektro, tio estas, ili estas ŝtataj aplikoj. Kaj Kubernetes ne estis origine destinita por tiaj aplikoj.

Tamen, ekzistas trajtoj kiuj aperis en Kubernetes lastatempe, kiuj permesas la uzon de datumbazoj kaj aliaj ŝtataj aplikoj:

La StatefulSet-koncepto estas tuta serio de primitivuloj por prilaborado de eventoj pri ĉesigo de la laboro de podoj kaj efektivigo de Graceful Shutdown (antaŭvidebla ĉesigo de la aplikaĵo).
Persistaj Volumoj estas datumbutikoj, kiuj estas asociitaj kun podoj, administraj objektoj de Kubernetes.
Operator Framework - tio estas, la kapablo krei komponentojn por administrado de datumbazoj kaj aliaj ŝtataj aplikoj distribuitaj tra multaj nodoj.

Jam nun en publikaj nuboj estas grandaj Datumbazoj kiel Servo, kies backend estas Kubernetes, ekzemple: CockroachCloud, InfluxDB, PlanetScale. Tio estas, datumbazo pri Kubernetes ne nur estas io teorie ebla, sed ankaŭ io, kio funkcias praktike.

Percona havas du malfermfontajn solvojn por Kubernetes:

Kubernetes Operatoro por Percona Server por MongoDB.
Kubernetes Operator por XtraDB CLUSTER estas servo kongrua kun MySQL kaj provizas altan haveblecon kaj konsistencon. Vi ankaŭ povas uzi ununuran nodon se alta havebleco ne estas necesa, ekzemple por dev-datumbazo.

Kubernetes-uzantoj povas esti dividitaj en du grupojn. Iuj homoj uzas Kubernetes Operatorojn rekte - ĉi tiuj estas ĉefe progresintaj uzantoj, kiuj bone komprenas kiel funkcias la teknologio. Aliaj funkciigas ĝin sur la backend - tiaj uzantoj interesiĝas pri io kiel Database as a Service, ili ne volas enprofundiĝi en la nuancojn de Kubernetes. Por la dua grupo de uzantoj, ni havas alian malfermfontan solvon - Percona DBaaS CLI Tool. Ĉi tio estas eksperimenta solvo por tiuj, kiuj volas akiri malfermfontan DBaaS bazitan sur Kubernetes sen profunda kompreno de la teknologio.

Kiel ruli DBaaS de Percona en Google Kubernetes Engine

Google Kubernetes Engine, laŭ mi, estas unu el la plej funkciaj realigoj de Kubernetes-teknologio. Ĝi haveblas en multaj regionoj de la mondo kaj havas simplan kaj oportunan Komandlinian Ilon (SDK), kiu permesas krei skriptojn anstataŭ mane administri la platformon.

Por ke nia DBaaS funkciu, ni bezonas la jenajn komponentojn:

Kubectl.
Google Cloud SDK.
Percona DBaaS CLI.

Instalu kubectl

Ni instalas la pakaĵon por via operaciumo, ni rigardos la ekzemplon de Ubuntu. Pli da detaloj tie.

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

Instalante Google Cloud SDK

Ni instalas la programaron en la sama maniero. Pli da detaloj tie.

# 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

Instalante Percona DBaaS CLI

Instalu el la deponejoj de Percona. Percona DBaaS CLI Tool estas ankoraŭ eksperimenta produkto, do ĝi situas en la eksperimenta deponejo, kiu devas esti ebligita aparte, eĉ se vi jam havas instalitajn deponejojn de Percona.

Legi pli tie.

Instala algoritmo:

Agordu Percona-deponejojn per la percona-liberiga ilo. Unue vi devas elŝuti kaj instali la oficialan percona-liberigan pakon de Percona:
```
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
```

Ebligu la eksperimentan ilan deponejon jene:

sudo percona-release enable tools experimental

Instalu percona-dbaas-cli pakaĵon:

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

Agordi la funkciadon de komponantoj

Pli pri agordoj tie.

Unue vi devas ensaluti en vian Google-konton. Plue, Google Cloud permesas al unu uzanto havi multajn sendependajn projektojn, do vi devas specifi funkciantan projekton uzante la kodon por ĉi tiu projekto:

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

Poste, ni kreas areton. Por la demo, mi kreis Kubernetes-grupon de nur tri nodoj - ĉi tio estas la minimumo postulata por alta havebleco:

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

La sekva komando kubectl donas la deziratajn privilegiojn al nia nuna uzanto:

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

Poste ni kreas nomspacon kaj aktivigas ĝin. Nomspaco estas, proksimume, ankaŭ kiel projekto aŭ medio, sed jam ene de Kubernetes-areo. Ĝi estas sendependa de Google Cloud-projektoj:

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

Komencante la areton

Post kiam ni trapasis ĉi tiujn kelkajn paŝojn, ni povas komenci tri-nodan areton per ĉi tiu simpla komando:

# 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

Kiel konekti al areto

Defaŭlte, ĝi disponeblas nur ene de Kubernetes. Tio estas, ĝi ne estas alirebla de ĉi tiu servilo de kiu vi kuris la komandon "Krei". Por disponigi ĝin, ekzemple, por testoj kun kliento, vi devas plusendi la havenon per Port Mapping:

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

Tiam ni konektas vian MySQL-klienton:

mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP

Altnivelaj komandoj pri administrado de clusteroj

Datumbazo pri publika IP

Se vi volas pli konstantan solvon por areto-havebleco, vi povas akiri eksteran IP-adreson. En ĉi tiu kazo, la datumbazo estos alirebla de ie ajn. Ĉi tio estas malpli sekura, sed ofte pli oportuna. Por ekstera IP ni uzas la jenan komandon:

# 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

Eksplicite agordu la pasvorton

Anstataŭ ke la sistemo hazarde generas pasvorton, vi povas agordi la pasvorton eksplicite:

# 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

Mi montras la eligon de la skriptoj en homlegebla formato, sed JSON-formato ankaŭ estas subtenata.

Malŝaltante altan haveblecon

Per la sekva komando vi povas malŝalti altan haveblecon por disfaldi ununuran nodon:

# 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

Ĉi tio estas solvo por provi taskojn por ekfunkciigi MySQL kiel eble plej rapide kaj facile, testi ĝin kaj poste malŝalti aŭ uzi ĝin por disvolviĝo.

La Percona DBaaS CLI-ilo helpas vin atingi DBaaS-similan solvon ĉe Kubernetes. Samtempe, ni daŭre laboras pri ĝia funkcieco kaj uzebleco.

Ĉi tiu raporto unue estis prezentita ĉe @Databases Meetup de Mail.ru Cloud Solutions&Tarantool. Rigardu видео aliajn prezentojn kaj abonu eventoncon sur Telegramo Ĉirkaŭ Kubernetes ĉe Mail.ru Group.

Kion alian legi pri la temo:

fonto: www.habr.com

Kiel konstrui hibridan nubon uzante Kubernetes, kiu povas anstataŭigi DBaaS