Hvordan bygge en hybridsky ved hjelp av Kubernetes som kan erstatte DBaaS

Mitt navn er Petr Zaitsev, jeg er administrerende direktør, grunnlegger percona og jeg vil fortelle deg:

  • hvordan vi kom fra åpen kildekode-løsninger til Database as a Service;
  • hvilke tilnærminger finnes for å distribuere databaser i skyen;
  • hvordan Kubernetes kan erstatte DBaaS, eliminere leverandøravhengighet og opprettholde enkelheten til DBMS som en tjeneste.

Artikkelen ble utarbeidet basert på en rapport på @Databases Meetup av Mail.ru Cloud Solutions & Tarantool. Hvis du ikke vil lese, kan du se:


Hvordan vi kom fra åpen kildekode til Database as a Service i skyen

Jeg har jobbet i åpen kildekode siden slutten av 90-tallet. For XNUMX år siden var det ikke så lett å bruke åpen kildekode, som databaser. Det var nødvendig å laste ned kildekoden, lappe den, kompilere den og først deretter bruke den.

Åpen kildekode gikk deretter gjennom en rekke forenklinger:

  • Tar.gz og INSTALL kilder som måtte kompileres;
  • pakker med avhengigheter som .deb og .rpm, hvor du bare trenger å installere et sett med pakker;
  • pakkelager som APT og YUM, med hvilke installasjonen er automatisk;
  • løsninger som Docker og Snap, som lar deg motta pakker ved installasjon uten eksterne avhengigheter.

Som et resultat blir det enklere å bruke åpen kildekode-programvare og senker også adgangsbarrieren for å utvikle slike applikasjoner.

Samtidig, i motsetning til situasjonen for 20 år siden, da alle var monteringseksperter, kan ikke de fleste utviklere bygge verktøyene de bruker fra kilden.

Faktisk er dette ikke dårlig, fordi:

  1. Vi kan bruke mer kompleks, men mer brukervennlig programvare. For eksempel er en nettleser praktisk å bruke, men den inkluderer mange åpen kildekode-komponenter og er upraktisk å bygge fra bunnen av.
  2. Flere kan bli utviklere av åpen kildekode og annen programvare, mer programvare brukes av bedrifter, og behovet for det er større.

Ulempen er at neste steg i forenkling er knyttet til bruk av skyløsninger, og dette fører til en viss leverandørlåsing, det vil si binding til én leverandør. Vi bruker enkle løsninger og leverandører bruker åpen kildekode-komponenter, men faktisk er de spikret til en av de store skyene. Det vil si at den enkleste og raskeste måten å distribuere åpen kildekode (og programvare som er kompatibel med den) er i skyene, ved å bruke et proprietært API.

Når det gjelder databaser i skyen, er det to tilnærminger:

  1. Sett sammen databaseinfrastrukturen, som i et vanlig datasenter. Det vil si, ta standard byggeklosser: data, lagring og så videre, installer Linux og en database på dem, og konfigurer dem.
  2. Bruk Database as a Service, hvor leverandøren tilbyr en ferdig database inne i skyen.

DBaaS er et raskt voksende marked akkurat nå fordi det lar utviklere jobbe direkte med databaser og minimerer rutinearbeid. Leverandøren forplikter seg til å sikre høy tilgjengelighet og enkel skalering, databasepatching, sikkerhetskopiering og ytelsesjustering.

To typer Database as a Service basert på åpen kildekode og et alternativ i form av Kubernetes

Det finnes to typer Database as a Service for åpne databaser:

  1. Et standard åpen kildekode-produkt pakket i en administrasjonsstøtte for enkel distribusjon og administrasjon.
  2. En avansert kommersiell løsning med ulike tillegg, kompatibel med åpen kildekode.

Begge alternativene reduserer muligheten for migrering mellom skyer og reduserer portabiliteten av data og applikasjoner. For eksempel, til tross for at forskjellige typer skyer støtter i hovedsak samme standard MySQL, er det betydelige forskjeller mellom dem: i drift, ytelse, sikkerhetskopiering og så videre. Migrering fra en sky til en annen kan være utfordrende, spesielt for komplekse applikasjoner.

Og her oppstår spørsmålet - er det mulig å få fordelen med Database as a Service, men som en enkel åpen kildekode-løsning?

Den dårlige nyheten er at det dessverre ikke finnes slike løsninger på markedet ennå. Den gode nyheten er at det er Kubernetes, som lar deg implementere slike løsninger.

Kubernetes er et operativsystem for skyen eller datasenteret som lar deg distribuere og administrere en applikasjon på tvers av flere servere i en klynge i stedet for på en enkelt vert.

Nå er Kubernetes ledende innen kategorien slik programvare. Det var mange forskjellige løsninger på slike problemer, men det ble standarden. Mange selskaper som pleide å fokusere på alternative løsninger, fokuserer nå på å tilpasse produktene sine for å støtte Kubernetes.

I tillegg er Kubernetes en universell løsning som støttes i private, offentlige og hybride skyer fra mange leverandører, for eksempel: AWS, Google Cloud, Microsoft Azure, Mail.ru skyløsninger.

Hvordan Kubernetes fungerer med databaser

Kubernetes ble opprinnelig designet for statsløse applikasjoner som behandler data, men som ikke lagrer noe, for eksempel mikrotjenester eller nettapplikasjoner. Databaser er i den andre enden av spekteret, det vil si at de er stateful applikasjoner. Og Kubernetes var opprinnelig ikke ment for slike applikasjoner.

Det er imidlertid funksjoner som nylig har dukket opp i Kubernetes som tillater bruk av databaser og andre stateful applikasjoner:

  1. StatefulSet-konseptet er en hel serie med primitiver for å behandle hendelser om å stoppe arbeidet til pods og implementere Graceful Shutdown (forutsigbar nedleggelse av applikasjonen).
  2. Vedvarende volumer er datalagre som er assosiert med pods, Kubernetes-administrasjonsobjekter.
  3. Operator Framework - det vil si muligheten til å lage komponenter for å administrere databaser og andre stateful applikasjoner fordelt på mange noder.

Allerede nå i offentlige skyer er det store Databaser as a Service, hvis backend er Kubernetes, for eksempel: CockroachCloud, InfluxDB, PlanetScale. Det vil si at en database på Kubernetes ikke bare er noe som er teoretisk mulig, men også noe som fungerer i praksis.

Percona har to åpen kildekode-løsninger for Kubernetes:

  1. Kubernetes Operator for Percona Server for MongoDB.
  2. Kubernetes Operator for XtraDB CLUSTER er en tjeneste som er kompatibel med MySQL og gir høy tilgjengelighet og konsistens. Du kan også bruke en enkelt node hvis høy tilgjengelighet ikke er nødvendig, for eksempel for en utviklingsdatabase.

Kubernetes-brukere kan deles inn i to grupper. Noen bruker Kubernetes Operators direkte – dette er hovedsakelig avanserte brukere som har god forståelse for hvordan teknologien fungerer. Andre kjører det på backend - slike brukere er interessert i noe som Database as a Service, de ønsker ikke å fordype seg i nyansene til Kubernetes. For den andre gruppen brukere har vi en annen åpen kildekode-løsning - Percona DBaaS CLI Tool. Dette er en eksperimentell løsning for de som ønsker å få en åpen kildekode DBaaS basert på Kubernetes uten dyp forståelse av teknologien.

Hvordan kjøre Perconas DBaaS på Google Kubernetes Engine

Google Kubernetes Engine, etter min mening, er en av de mest funksjonelle implementeringene av Kubernetes-teknologi. Den er tilgjengelig i mange regioner i verden og har et enkelt og praktisk kommandolinjeverktøy (SDK), som lar deg lage skript i stedet for manuelt å administrere plattformen.

For at DBaaS skal fungere, trenger vi følgende komponenter:

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

Installer kubectl

Vi installerer pakken for operativsystemet ditt, vi vil se på eksemplet med Ubuntu. Mer informasjon her.

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

Installerer Google Cloud SDK

Vi installerer programvarepakken på samme måte. Mer informasjon her.

# 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

Installerer Percona DBaaS CLI

Installer fra Percona-lagrene. Percona DBaaS CLI Tool er fortsatt et eksperimentelt produkt, så det ligger i det eksperimentelle depotet, som må aktiveres separat, selv om du allerede har installert Percona-lagre.

Mer her.

Installasjonsalgoritme:

  1. Sett opp Percona-depoter ved å bruke percona-release-verktøyet. Først må du laste ned og installere den offisielle percona-utgivelsespakken fra Percona:
    wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
    sudo dpkg -i percona-release_latest.generic_all.deb
  2. Aktiver den eksperimentelle verktøydepotkomponenten som følger:
    sudo percona-release enable tools experimental
    
  3. Installer percona-dbaas-cli-pakken:
    sudo apt-get update
    sudo apt-get install percona-dbaas-cli

Sette opp driften av komponenter

Mer om innstillinger her.

Først må du logge på Google-kontoen din. Videre lar Google Cloud én bruker ha mange uavhengige prosjekter, så du må spesifisere et fungerende prosjekt ved å bruke koden for dette prosjektet:

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

Deretter lager vi en klynge. For demoen opprettet jeg en Kubernetes-klynge med bare tre noder - dette er minimumskravet for høy tilgjengelighet:

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

Følgende kubectl-kommando gir de ønskede rettighetene til vår nåværende bruker:

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

Deretter oppretter vi et navneområde og gjør det aktivt. Namespace er, grovt sett, også som et prosjekt eller miljø, men allerede inne i en Kubernetes-klynge. Det er uavhengig av Google Cloud-prosjekter:

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

Starter klyngen

Når vi har gått gjennom disse få trinnene, kan vi starte en tre-node-klynge med denne enkle kommandoen:

# 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

Hvordan koble til en klynge

Som standard er den bare tilgjengelig i Kubernetes. Det vil si at den ikke er tilgjengelig fra denne serveren du kjørte kommandoen "Create" fra. For å gjøre den tilgjengelig, for eksempel for tester med en klient, må du videresende porten gjennom Port Mapping:

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

Deretter kobler vi til din MySQL-klient:

mysql -h 127.0.0.1 -P 3306 -uroot -pNt9YZquajW7nfVXTTrP

Avanserte klyngeadministrasjonskommandoer

Database over offentlig IP

Ønsker du en mer permanent løsning for klyngetilgjengelighet, kan du få en ekstern IP-adresse. I dette tilfellet vil databasen være tilgjengelig fra hvor som helst. Dette er mindre sikkert, men ofte mer praktisk. For ekstern IP bruker vi følgende kommando:

# 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

Angi passordet eksplisitt

I stedet for at systemet tilfeldig genererer et passord, kan du angi passordet eksplisitt:

# 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

Jeg viser utdataene til skriptene i lesbart format, men JSON-formatet støttes også.

Slå av høy tilgjengelighet

Med følgende kommando kan du deaktivere høy tilgjengelighet for å distribuere en enkelt 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

Dette er en løsning for å teste oppgaver for å få MySQL i gang så raskt og enkelt som mulig, teste det og deretter slå det av eller bruke det til utvikling.

Percona DBaaS CLI-verktøyet hjelper deg å oppnå en DBaaS-lignende løsning på Kubernetes. Samtidig fortsetter vi å jobbe med funksjonaliteten og brukervennligheten.

Denne rapporten ble først presentert kl @Databaser Meetup av Mail.ru Cloud Solutions&Tarantool. Se video andre forestillinger og abonner på begivenhetskunngjøringer på Telegram Rundt Kubernetes på Mail.ru Group.

Hva annet å lese om emnet:

  1. Databaser i en moderne IIoT-plattform.
  2. Hvordan velge en database for et prosjekt slik at du ikke trenger å velge på nytt.

Kilde: www.habr.com

Legg til en kommentar