En oversigt over Percona XtraDB Cluster Kubernetes-operatøren

Hvis du har været rundt i containerverdenen, ville du vide, at det er ret udfordrende at indføre en fuld Kubernetes-automatisering til et klynget databasesystem, som almindeligvis tilføjer et kompleksitetsniveau til det containerbaserede arkitektur til disse stateful applikationer. Det er her, en Kubernetes-operatør kan hjælpe os med at løse dette problem. En Kubernetes Operator er en speciel type controller introduceret for at forenkle komplekse implementeringer, som grundlæggende udvider Kubernetes API med brugerdefinerede ressourcer. Den bygger på de grundlæggende Kubernetes-ressource- og controllerkoncepter, men inkluderer domæne- eller applikationsspecifik viden for at automatisere hele livscyklussen af den software, den administrerer.

Percona XtraDB Cluster Operator er en smart måde at automatisere de specifikke opgaver i Percona XtraDB Cluster som implementering, skalering, sikkerhedskopier og opgraderinger i Kubernetes, bygget og vedligeholdt af Percona. Den implementerer klyngen i et StatefulSet med en persistent volumen, som giver os mulighed for at opretholde en ensartet identitet for hver Pod i klyngen og vores data, der skal vedligeholdes.

I dette blogindlæg skal vi teste implementeringen af Percona XtraDB Cluster 8.0 i et containeriseret miljø, orkestreret af Percona XtraDB Cluster Kubernetes Operator på Google Cloud Platform.

Oprettelse af en Kubernetes-klynge på Google Cloud

I denne gennemgang skal vi bruge Kubernetes-klyngen på Google Cloud, fordi det er relativt enkelt og nemt at få Kubernetes op at køre. Log ind på dit Google Cloud Platform-dashboard -> Compute -> Kubernetes Engine -> Create Cluster, og du vil blive præsenteret for følgende dialog:

Indtast blot Kubernetes Cluster-navnet, vælg din foretrukne zone og klik på "OPRET" " (nederst på siden). Om 5 minutter vil en 3-node Kubernetes-klynge være klar. Nu, på din arbejdsstation, skal du installere gcloud SDK'et som vist i denne vejledning og derefter trække Kubernetes-konfigurationen ind i din arbejdsstation:

$ gcloud-beholderklynger get-legitimationsoplysninger my-k8s-cluster --zone asia-northeast1-a --project s9s-qaHenter cluster endpoint og auth data.kubeconfig-indgang genereret for my-k8s-cluster.

 Du burde være i stand til at oprette forbindelse til Kubernetes-klyngen på dette tidspunkt. Kør følgende kommando for at bekræfte:
 $ kubectl get nodesNAME STATUS ROLLER ALDER VERSIONgke-my-k8s-cluster-default-pool-b80902cd-gp09 Klar  139m v1.16.13-gke.401gke-my-k8s-cluster-default -b80902cd-jdc3 Klar  139m v1.16.13-gke.401gke-my-k8s-cluster-default-pool-b80902cd-rdv8 Klar  139m v1.16.13-gke.401 
 Ovenstående output betyder, at vi er i stand til at oprette forbindelse til Kubernetes-masteren og hente Kubernetes-klyndeknuderne. Nu er vi klar til at køre Kubernetes-arbejdsbelastningerne. 
 Installation af en Percona XtraDB-klynge på Kubernetes
 
 For implementering af arbejdsbelastning vil vi følge instruktionerne som angivet i Percona XtraDB Cluster Operator-dokumentationen. Grundlæggende kører vi følgende kommando på vores arbejdsstation for at skabe de tilpassede ressourcer, navneområde, rollebaseret adgangskontrol og også selve Kubernetes-operatøren:
 $ git clone -b v1.6.0 https://github.com/percona/percona-xtradb-cluster-operator$ cd percona-xtradb-cluster-operator/$ kubectl anvende -f deploy/crd. yaml$ kubectl oprette navneområde pxc$ kubectl config sæt-kontekst $(kubectl config nuværende-kontekst) --namespace=pxc$ kubectl oprette clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get -værdi kerne/konto)$ kubectl anvende -f deploy/rbac.yaml$ kubectl anvende -f deploy/operator.yaml 
 Dernæst skal vi forberede vores adgangskoder (det kaldes Secrets in Kubernetes term) ved at opdatere værdierne inde i deploy/secrets.yaml i et base64-kodet format. Du kan bruge onlineværktøjer som https://www.base64encode.org/ til at oprette et eller bruge et kommandolinjeværktøj som følgende:
 $ echo -n 'mypassword' | base64bXlwYXNzd29yZA== 
 Opdater derefter deploy/secrets.yaml, som vist nedenfor:
 apiVersion:v1kind:Secretmetadata:name:my-cluster-secretstype:Uigennemsigtige data:root:bXlwYXNzd29yZA==xtrabackup:bXlwYXNzd29yZA==skærm:bXlwYXNzd29yZA==cluster ==operator:bXlwYXNzd29yZA== 
 Ovenstående er en super forenkling af hemmelig håndtering, hvor vi indstiller alle adgangskoder til at være ens for alle brugere. I produktionen skal du bruge en mere kompleks adgangskode og angive en anden adgangskode for hver bruger. 
 
 Nu kan vi skubbe den hemmelige konfiguration til Kubernetes:
 $ kubectl apply -f deploy/secrets.yaml 
 
 Før vi går videre for at implementere en Percona XtraDB-klynge, skal vi gense standardimplementeringsdefinitionen inde i deploy/cr.yaml for klyngen. Der er mange Kubernetes-objekter, der er defineret her, men de fleste af dem er kommenteret ud. For vores arbejdsbyrde ville vi foretage ændringen som nedenfor:
 $ cat deploy/cr.yamlapiVersion:pxc.percona.com/v1-6-0kind:PerconaXtraDBClustermetadata:navn:cluster1 finalizers:- delete-pxc-pods-in-orderspec:crVersion:1.6.0 secretsName :my-cluster-secrets vaultSecretName:keyring-secret-vault sslSecretName:my-cluster-ssl sslInternalSecretName:my-cluster-ssl-internal allowUnsafeConfigurations:false updateStrategy:SmartUpdate upgradeOptions:https://Service. anbefalet tidsplan:"0 4 * * *" pxc:størrelse:3 billede:percona/percona-xtradb-cluster:8.0.20-11.1 konfiguration:| [client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] collation-server =utf8_unicode_ci character-set-server =utf8 default_authentication_plugin =mysql_native_password ressourcer:requests:memory:1G "affinity:antiKey:antiAffinityTopology kubernetes.io/hostname" podDisruptionBudget:maxUnavigable:1 volumeSpec:persistentVolumeClaim:ressourcer:requests:storage:6Gi gracePeriod:600 haproxy:enabled:true size:3 image:percona/percona-xtradb-cluster:ha.6 ressourcer:anmodninger:hukommelse:1G affinitet:antiAffinityTopologyNøgle:"kubernetes.io/hostname" podDisruptionBudget:maxUnavigable:1 gracePeriod:30 backup:image:percona/percona-xtradb-cluster-operator:1.6.0-pxc8 storages :fs-pvc:type:filsystem volumen:persistentVolumeClaim:accessModes:[ "ReadWriteOnce" ] ressourcer:requests:storage:6Gi-skema:- navn:"daily-backup" tidsplan:"0 0 * * *" keep:5 storageName:fs-pvc 
 Vi har foretaget nogle ændringer af den medfølgende cr.yaml for at få den til at fungere med vores applikation, som vist ovenfor. Først og fremmest skal vi kommentere (eller fjerne) alle CPU-relaterede linjer, for eksempel [*].resources.requests.cpu:600m, for at sikre, at Kubernetes er i stand til at planlægge pod-oprettelsen korrekt på noder med begrænset CPU. Så skal vi tilføje nogle kompatibilitetsmuligheder for Percona XtraDB Cluster 8.0, som er baseret på MySQL 8.0, for at fungere problemfrit med vores WordPress-applikation, som vi skal implementere senere, som vist i følgende uddrag:
 -konfiguration:| [client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] collation-server =utf8_unicode_ci character-set-server =utf8 default_authentication_plugin =mysql_native_password  Ovenstående vil matche MySQL-serverens standardtegnsæt med MySQLi PHP-driveren i vores WordPress-beholder. Det næste afsnit er HAProxy-implementeringen, hvor den er sat til "enabled:true". Der er også en ProxySQL-sektion med "enabled:false" - almindeligvis ville man vælge en af de omvendte proxyer for hver klynge. Det sidste afsnit er backup-konfigurationen, hvor vi gerne vil have en daglig backup planlagt kl. 12:00 hver dag og beholde de sidste 5 backups.
 
 Vi kan nu begynde at implementere vores 3-node Percona XtraDB Cluster:
 $ kubectl apply -f deploy/cr.yaml 
 
 Oprettelsesprocessen vil tage noget tid. Operatøren vil implementere Percona XtraDB Cluster pods som et Stateful Set, hvilket betyder, at én pod skabes ad gangen, og hver Pod i StatefulSet vil blive tildelt en heltalsordinal, fra 0 op gennem N-1, som er unik over sættet. Processen er slut, når både operatør og pods har nået deres kørestatus:
 $ kubectl get podsNAME KLAR STATUS GENSTARTER AGEcluster1-haproxy-0 2/2 Kører 0 71mcluster1-haproxy-1 2/2 Kører 0 70mcluster1-haproxy-2 2/2 Kører 0 70mcluster1-pxc-pxc 1 Kører 0 71mcluster1-pxc-1 1/1 Kører 0 70mcluster1-pxc-2 1/1 Kører 0 69mpercona-xtradb-cluster-operator-79d786dcfb-6clld 1/1 Kører 0 121m 
 Da denne operatør er en brugerdefineret ressource, kan vi manipulere perconaxtradbcluster-ressourcen til at kunne lide standard Kubernetes-ressourcen:
 $ kubectl få perconaxtradbclusterNAME ENDPOINT STATUS PXC PROXYSQL HAPROXY AGEcluster1 cluster1-haproxy.pxc klar 3 3 27h 
 Du kan også bruge det kortere ressourcenavn, "pxc", og prøve med følgende kommandoer:
 $ kubectl beskriv pxc$ kubectl rediger pxc 
 Når vi ser på arbejdsbelastningssættet, kan vi se, at operatøren har oprettet to StatefulSets:
 $ kubectl get statefulsets -o wideNAME READY AGE CONTAINERS IMAGEScluster1-haproxy 3/3 26h haproxy,pxc-monit percona/percona-xtradb-cluster-operator:1.6.0-haproxy,percona/percona-xtradb-xtradb- cluster-operator:1.6.0-haproxycluster1-pxc 3/3 26h pxc percona/percona-xtradb-cluster:8.0.20-11.2 
 Operatøren vil også oprette de tilsvarende tjenester, der vil belastningsbalancerede forbindelser til de respektive pods:
 $ kubectl get serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEcluster1-haproxy ClusterIP 10.40.9.177  3306/TCP,3309/TCP,33062/TCP 3h27mproxy-1ica Cluster-4pla. 0,236  3306/TCP 3h27mcluster1-pxc ClusterIP Ingen  3306/TCP,33062/TCP 3h27mcluster1-pxc-unready ClusterIP Ingen  3306/TCP,336> 3306/TCP,336> 
 Ovenstående output viser, at operatøren har oprettet 4 tjenester:
  cluster1-haproxy - Tjenesten til en belastningsbalanceret MySQL single-master (3306), Proxy protokol (3309) og MySQL Admin (33062) - En ny administrativ port introduceret i MySQL 8.0.14 og senere. Dette er tjenestenavnet eller klyngens IP-adresse, som applikationerne skal oprette forbindelse til for at have en enkelt-master-forbindelse til Galera-klyngen.
 cluster1-haproxy-replicas - Tjenesten for en belastningsbalanceret MySQL multi-master (3306). Dette er tjenestenavnet eller klynge-IP-adressen, som applikationerne skal forbinde for at have en multi-master-forbindelse til Galera-klyngen med round-robin-balanceringsalgoritme.
 cluster1-pxc - Tjenesten til belastningsbalancerede PXC-pods, der omgår HAProxy. Ved at oprette forbindelse direkte til denne tjeneste, vil Kubernetes rute forbindelsen på round-robin måde til alle PXC pods, svarende til hvad cluster-haproxy-replikase giver. Tjenesten har ingen offentlig IP-adresse tildelt og er ikke tilgængelig uden for klyngen.
 cluster1-pxc-unready - 'Uklar'-tjenesten er nødvendig for at finde pod-adresser under opstart af applikationen uanset Pod-tilstanden. Proxysql og pxc pods bør kende til hinanden, før databasen bliver fuldt operationel. Uklar-tjenesten har ingen offentlig IP-adresse tildelt og er ikke tilgængelig uden for klyngen.
 
 
 For at oprette forbindelse via en MySQL-klient skal du blot køre følgende kommando:
 $ kubectl run -i --rm --tty percona-client --image=percona:8.0 --restart=Aldrig -- bash -il 
 Dette vil oprette en forbigående Pod og straks gå ind i containermiljøet. Kør derefter standard mysql-klientkommandoen med en korrekt legitimationsoplysninger:
 bash-4.2$ mysql -uroot -pmypassword -h cluster1-haproxy -P3306 -e 'SELECT @@hostname'mysql:[Advarsel] Brug af en adgangskode på kommandolinjegrænsefladen kan være usikker.+-- --------------+| @@værtsnavn |+----------------+| cluster1-pxc-0 |+----------------+ 
 Når vi ser på Pod-placeringen, er alle Percona XtraDB Cluster-pods placeret på en anden Kubernetes-vært:
 $ kubectl get pods -o wide --selector=app.kubernetes.io/component=pxcNAME KLAR STATUS GENSTART ALDER IP NODE NOMINERET NODE KLAR KLAR GATEScluster1-pxc-0 1/1 Kører 0 67m 10.36.2.5 gke -my-k8s-cluster-default-pool-b80902cd-gp09  cluster1-pxc-1 1/1 Løb 0 66m 10.36.1.10 gke-my-k8s-cluster-default-pool-b80902cd-rdv8  cluster1-pxc-2 1/1 Løb 0 65m 10.36.0.11 gke-my-k8s-cluster-default-pool-b80902cd-jdc3   
 Dette vil helt sikkert forbedre tilgængeligheden af tjenesten, hvis en af Kubernetes-værterne går ned. 
 
 For at skalere op til 5 pods skal vi forberede yderligere 2 nye Kubernetes-noder på forhånd for at respektere pod-affinitetskonfigurationen (standard til affinity.antiAffinityTopologyKey.topologyKey="kubernetes.io/hostname"). Kør derefter følgende patch-kommando for at skalere Percona XtraDB Cluster til 5 noder:
 $ kubectl patch pxc cluster1 \--type='json' -p='[{"op":"erstat", "sti":"/spec/pxc/størrelse", "værdi":5 }]' 
 
 Overvåg pod'ens oprettelse ved at bruge kommandoen kubectl get pods:
 $ kubectl get pods -o wideNAME KLAR STATUS GENSTARTER ALDER IP NODE NOMINERET NODE KLAR KLAR GATEScluster1-pxc-0 1/1 Kører 0 27h 10.36.2.5 gke-my-k8s-cluster-default-pool-cd-80 gp09  cluster1-pxc-1 1/1 Kører 0 27t 10.36.1.10 gke-my-k8s-cluster-default-pool-b80902cd-rdv8  cluster1-pxc-2 1/1 Løb 0 27t 10.36.0.11 gke-my-k8s-cluster-default-pool-b80902cd-jdc3  cluster1-pxc-3 1/1 Løb 0 30m 10.36.7.2 gke-cluster-k8s-pool -1-ab14a45e-h1pf  cluster1-pxc-4 1/1 Løb 0 13m 10.36.5.3 gke-my-k8s-cluster-pool-1-ab14a45e-01qn   
 Yderligere 2 nye Pods (cluster1-pxc-3 og cluster1-pxc-4) er blevet oprettet på yderligere 2 nye Kubernetes-noder (gke-my-k8s-cluster-pool-1-ab14a45e-h1pf og gke-my-k8s-cluster-pool-1-ab14a45e-01qn). For at nedskalere skal du blot ændre værdien tilbage til 3 i ovenstående patch-kommando. Bemærk, at Percona XtraDB Cluster bør køre med et ulige antal noder for at forhindre split-brain.
 Deployering af en applikation (WordPress)
 
 I dette eksempel skal vi implementere en WordPress-applikation oven på vores Percona XtraDB Cluster og HAProxy. Lad os først forberede YAML-definitionsfilen som følgende:
 $ cat wordpress-deployment.yamlapiVersion:v1kind:Servicemetadata:navn:wordpress labels:app:wordpressspec:porte:- port:80 selector:app:wordpress tier:frontend type:LoadBalancer---apiVersion:v1kind :PersistentVolumeClaimmetadata:navn:wp-pv-claim labels:app:wordpressspec:accessModes:- ReadWriteOnce-ressourcer:requests:storage:2Gi---apiVersion:apps/v1 # for versioner før 1.9.0 brug apps/v1beta2kind:Deploymentmetadata:navn :wordpress labels:app:wordpressspec:selector:matchLabels:app:wordpress tier:frontend strategi:type:Genskab skabelon:metadata:labels:app:wordpress tier:frontend spec:containere:- billede:wordpress:4.8-apache navn:wordpress env:- navn:WORDPRESS_DB_HOST værdi:klynge1-haproxy - navn:WORDPRESS_DB_PASSWORD værdiFra:secretKeyRef:navn:min-klynge-hemmeligheder nøgle:rodporte:- containerPort:80 navn:wordpress volumeMounts:- navn:wordpress-persistent-storage mountPath:/var/www/html volumes:- navn:wordpress-persistent-storage persistentVolumeClaim:claimName:wp-pv-claim 
 Vær opmærksom på miljøvariablerne WORDPRESS_DB_HOST og WORDPRESS_DB_PASSWORD. Den førstnævnte variabel, hvor vi definerede "cluster1-haproxy" som databaseværten, i stedet for en individuel databaseknude, og for sidstnævnte specificerede vi root-adgangskoden ved at instruere Kubernetes om at læse den fra my-cluster-secrets-objektet under nøglen "root", hvilket svarer til "mypassword" (efter at base64-værdien blev afkodet). Vi springer over at definere WORDPRESS_DB_USER miljøvariablen, da standardværdien er "root".
 
 Nu kan vi oprette vores applikation:
 $ kubectl apply -f wordpress-deployment.yaml 
 Tjek tjenesten:
 $ kubectl get serviceNAME TYPE CLUSTER-IP EKSTERN-IP-PORT(E) AGEcluster1-haproxy ClusterIP 10.40.9.177  3306/TCP,3309/TCP,33062/TCP 4h42mproxy-1ica 4h42mproxy-1ica. 0,236  3306/TCP 4H42MCluster1-PXC CLUSTERIP Ingen  3306/TCP, 33062/TCP 4H42MCluster1-PXC-UNREADY CLUSTERIP None  3306/TCP, 33062/TCP 4H42MBRESSESSESSEBALANCER 10.40.13.205 35.25.25.20.20.2520.20.20.20.20.20.20. /TCP 4h39m 
 På dette tidspunkt kan vi oprette forbindelse til vores WordPress-applikation på http://35.200.78.195/ (den eksterne IP-adresse) og begynde at konfigurere WordPress-applikationen. På dette tidspunkt er vores WordPress-applikation forbundet til en af Percona XtraDB Cluster (single-master forbindelse) via en af HAProxy pods.
 Det var det for nu. For mere information, se dokumentationen til Percona Kubernetes Operator for Percona XtraDB Cluster. God fornøjelse med containerisering!