Přehled Percona XtraDB Cluster Operátor Kubernetes

Pokud jste se pohybovali ve světě kontejnerů, věděli byste, že je docela náročné přijmout plnou automatizaci Kubernetes pro klastrovaný databázový systém, který běžně přidává úroveň složitosti do kontejnerového systému architektura pro tyto stavové aplikace. Právě tam nám může operátor Kubernetes pomoci tento problém vyřešit. Operátor Kubernetes je speciální typ řadiče zavedený pro zjednodušení komplexních nasazení, který v podstatě rozšiřuje rozhraní Kubernetes API o vlastní zdroje. Staví na základních konceptech zdrojů a ovladačů Kubernetes, ale zahrnuje znalosti specifické pro doménu nebo aplikaci pro automatizaci celého životního cyklu softwaru, který spravuje.

Percona XtraDB Cluster Operator je elegantní způsob, jak automatizovat specifické úkoly Percona XtraDB Cluster, jako je nasazení, škálování, zálohování a upgrady v rámci Kubernetes, vytvořeného a spravovaného Perconou. Nasazuje cluster do StatefulSet s trvalým svazkem, což nám umožňuje udržovat konzistentní identitu pro každý modul v clusteru a udržovat naše data.

V tomto blogovém příspěvku otestujeme nasazení Percona XtraDB Cluster 8.0 v kontejnerovém prostředí, které řídí Percona XtraDB Cluster Kubernetes Operator na Google Cloud Platform.

Vytvoření clusteru Kubernetes ve službě Google Cloud

V tomto návodu použijeme cluster Kubernetes na Google Cloud, protože je relativně jednoduché a snadné spustit Kubernetes. Přihlaste se do svého hlavního panelu Google Cloud Platform -> Compute -> Kubernetes Engine -> Create Cluster a zobrazí se vám následující dialog:

Stačí zadat název clusteru Kubernetes, vybrat preferovanou zónu a kliknout na „VYTVOŘIT “ (v dolní části stránky). Za 5 minut bude 3uzlový cluster Kubernetes připraven. Nyní na své pracovní stanici nainstalujte sadu gcloud SDK, jak je znázorněno v této příručce, a poté stáhněte konfiguraci Kubernetes do své pracovní stanice:

$ gcloud container clusters get-credentials my-k8s-cluster --zone asia-northeast1-a --project s9s-qa
Fetching cluster endpoint and auth data.
kubeconfig entry generated for my-k8s-cluster.

Výše uvedený výstup znamená, že se můžeme připojit k hlavnímu serveru Kubernetes a načíst uzly clusteru Kubernetes. Nyní jsme připraveni spustit úlohy Kubernetes.

Nasazení klastru Percona XtraDB na Kubernetes

Při nasazení pracovní zátěže se budeme řídit pokyny uvedenými v dokumentaci Percona XtraDB Cluster Operator. V podstatě na naší pracovní stanici spustíme následující příkaz k vytvoření vlastních zdrojů, jmenného prostoru, řízení přístupu na základě rolí a také samotného operátora Kubernetes:

$ git clone -b v1.6.0 https://github.com/percona/percona-xtradb-cluster-operator
$ cd percona-xtradb-cluster-operator/
$ kubectl apply -f deploy/crd.yaml
$ kubectl create namespace pxc
$ kubectl config set-context $(kubectl config current-context) --namespace=pxc
$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value core/account)
$ kubectl apply -f deploy/rbac.yaml
$ kubectl apply -f deploy/operator.yaml

Dále musíme připravit naše hesla (v Kubernetes termínu se tomu říká Secrets) aktualizací hodnot v deploy/secrets.yaml ve formátu zakódovaném base64. K vytvoření můžete použít online nástroje, jako je https://www.base64encode.org/, nebo použít nástroj příkazového řádku, jako je tento:

$ echo -n 'mypassword' | base64
bXlwYXNzd29yZA==

Potom aktualizujte soubor deploy/secrets.yaml, jak je uvedeno níže:

apiVersion: v1
kind: Secret
metadata:
  name: my-cluster-secrets
type: Opaque
data:
  root: bXlwYXNzd29yZA==
  xtrabackup: bXlwYXNzd29yZA==
  monitor: bXlwYXNzd29yZA==
  clustercheck: bXlwYXNzd29yZA==
  proxyadmin: bXlwYXNzd29yZA==
  pmmserver: bXlwYXNzd29yZA==
  operator: bXlwYXNzd29yZA==

Výše uvedené představuje super zjednodušení správy tajných informací, kde nastavujeme všechna hesla, aby byla pro všechny uživatele stejná. Při výrobě používejte prosím složitější heslo a pro každého uživatele zadejte jiné heslo.

Nyní můžeme poslat tajnou konfiguraci do Kubernetes:

$ kubectl apply -f deploy/secrets.yaml

Než se pustíme do nasazení klastru Percona XtraDB, musíme se znovu podívat na výchozí definici nasazení v deploy/cr.yaml pro klastr. Existuje mnoho objektů Kubernetes, které jsou zde definovány, ale většina z nich je zakomentována. Pro naši pracovní zátěž bychom provedli úpravu následovně:

$ cat deploy/cr.yaml
apiVersion: pxc.percona.com/v1-6-0
kind: PerconaXtraDBCluster
metadata:
  name: cluster1
  finalizers:
    - delete-pxc-pods-in-order
spec:
  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:
    versionServiceEndpoint: https://check.percona.com
    apply: recommended
    schedule: "0 4 * * *"
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0.20-11.1
    configuration: |
      [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
    resources:
      requests:
        memory: 1G
    affinity:
      antiAffinityTopologyKey: "kubernetes.io/hostname"
    podDisruptionBudget:
      maxUnavailable: 1
    volumeSpec:
      persistentVolumeClaim:
        resources:
          requests:
            storage: 6Gi
    gracePeriod: 600
  haproxy:
    enabled: true
    size: 3
    image: percona/percona-xtradb-cluster-operator:1.6.0-haproxy
    resources:
      requests:
        memory: 1G
    affinity:
      antiAffinityTopologyKey: "kubernetes.io/hostname"
    podDisruptionBudget:
      maxUnavailable: 1
    gracePeriod: 30
  backup:
    image: percona/percona-xtradb-cluster-operator:1.6.0-pxc8.0-backup
    storages:
      fs-pvc:
        type: filesystem
        volume:
          persistentVolumeClaim:
            accessModes: [ "ReadWriteOnce" ]
            resources:
              requests:
                storage: 6Gi
    schedule:
      - name: "daily-backup"
        schedule: "0 0 * * *"
        keep: 5
        storageName: fs-pvc

Udělali jsme některé úpravy poskytnutého cr.yaml, aby fungoval s naší aplikací, jak je uvedeno výše. Nejprve musíme zakomentovat (nebo odstranit) všechny řádky související s CPU, například [*].resources.requests.cpu:600m, abychom se ujistili, že Kubernetes dokáže správně naplánovat vytvoření podu na uzlech s omezeným CPU. Poté musíme přidat některé možnosti kompatibility pro Percona XtraDB Cluster 8.0, který je založen na MySQL 8.0, abychom hladce fungovali s naší aplikací WordPress, kterou se chystáme nasadit později, jak je znázorněno v následujícím úryvku:

   configuration: |
      [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

Výše uvedené bude odpovídat výchozí znakové sadě serveru MySQL s ovladačem PHP MySQLi v našem kontejneru WordPress. Další částí je nasazení HAProxy, kde je nastaveno na "enabled:true". Existuje také sekce ProxySQL s "enabled:false" - obvykle by se pro každý cluster vybral jeden z reverzních proxy. Poslední částí je konfigurace zálohování, kde bychom chtěli mít naplánovanou denní zálohu každý den ve 00:00 a zachovat posledních 5 záloh.

Nyní můžeme začít nasazovat náš 3-uzlový Percona XtraDB Cluster:

$ kubectl apply -f deploy/cr.yaml

Proces vytváření bude nějakou dobu trvat. Operátor nasadí pody Percona XtraDB Cluster jako stavovou sadu, což znamená vytvoření jednoho modulu najednou a každému podu v sadě StatefulSet bude přiřazeno celé číslo řadové, od 0 až po N-1, které je v sadě jedinečné. Proces je u konce, když operátor i moduly dosáhnou svého provozního stavu:

$ kubectl get pods
NAME                                               READY   STATUS    RESTARTS   AGE
cluster1-haproxy-0                                 2/2     Running   0          71m
cluster1-haproxy-1                                 2/2     Running   0          70m
cluster1-haproxy-2                                 2/2     Running   0          70m
cluster1-pxc-0                                     1/1     Running   0          71m
cluster1-pxc-1                                     1/1     Running   0          70m
cluster1-pxc-2                                     1/1     Running   0          69m
percona-xtradb-cluster-operator-79d786dcfb-6clld   1/1     Running   0          121m

Protože tento operátor je vlastní zdroj, můžeme manipulovat se zdrojem perconaxtradbcluster tak, aby se líbil standardnímu zdroji Kubernetes:

$ kubectl get perconaxtradbcluster
NAME       ENDPOINT               STATUS   PXC   PROXYSQL   HAPROXY   AGE
cluster1   cluster1-haproxy.pxc   ready    3                3         27h

Můžete také použít kratší název zdroje, "pxc", a zkuste to pomocí následujících příkazů:

$ kubectl describe pxc
$ kubectl edit pxc

Když se podíváme na sadu zátěže, můžeme říci, že operátor vytvořil dvě sady StatefulSets:

$ kubectl get statefulsets -o wide
NAME               READY   AGE   CONTAINERS          IMAGES
cluster1-haproxy   3/3     26h   haproxy,pxc-monit   percona/percona-xtradb-cluster-operator:1.6.0-haproxy,percona/percona-xtradb-cluster-operator:1.6.0-haproxy
cluster1-pxc       3/3     26h   pxc                 percona/percona-xtradb-cluster:8.0.20-11.2

Operátor také vytvoří odpovídající služby, které budou zátěžově vyvážená připojení k příslušným modulům:

$ kubectl get service
NAME                        TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                       AGE
cluster1-haproxy            ClusterIP      10.40.9.177    <none>          3306/TCP,3309/TCP,33062/TCP   3h27m
cluster1-haproxy-replicas   ClusterIP      10.40.0.236    <none>          3306/TCP                      3h27m
cluster1-pxc                ClusterIP      None           <none>          3306/TCP,33062/TCP            3h27m
cluster1-pxc-unready        ClusterIP      None           <none>          3306/TCP,33062/TCP            3h27m

Výše uvedený výstup ukazuje, že operátor vytvořil 4 služby:

• cluster1-haproxy - Služba pro singlemaster MySQL s vyváženou zátěží (3306), Proxy protokol (3309) a MySQL Admin (33062) - Nový administrativní port představený v MySQL 8.0.14 a novějších. Jedná se o název služby nebo IP adresu clusteru, ke které se aplikace potřebují připojit, aby měly připojení jednoho hlavního serveru ke clusteru Galera.
• cluster1-haproxy-replicas - Služba pro multimaster MySQL s vyváženou zátěží (3306). Jedná se o název služby nebo IP adresu clusteru, ke které se aplikace potřebují připojit, aby měly vícemaster připojení ke clusteru Galera s algoritmem pro vyrovnávání mezi jednotlivými uživateli.
• cluster1-pxc - Služba pro zátěžově vyvážené PXC moduly, obcházení HAProxy. Přímým připojením k této službě bude Kubernetes směrovat připojení způsobem cyklicky do všech modulů PXC, podobně jako to poskytuje cluster-haproxy-replicase. Služba nemá přidělenou žádnou veřejnou IP adresu a není dostupná mimo cluster.
• cluster1-pxc-unready - Služba 'nepřipraveno' je potřebná pro zjišťování adresy modulu během spouštění aplikace bez ohledu na stav modulu. Proxysql a pxc pody by o sobě měly vědět, než bude databáze plně funkční. Nepřipravená služba nemá přiřazenou veřejnou IP adresu a není dostupná mimo cluster.

Chcete-li se připojit prostřednictvím klienta MySQL, jednoduše spusťte následující příkaz:

$ kubectl run -i --rm --tty percona-client --image=percona:8.0 --restart=Never -- bash -il

Tím se vytvoří přechodný modul a okamžitě vstoupí do prostředí kontejneru. Poté spusťte standardní příkaz klienta mysql se správným pověřením:

bash-4.2$ mysql -uroot -pmypassword -h cluster1-haproxy -P3306 -e 'SELECT @@hostname'
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------------+
| @@hostname     |
+----------------+
| cluster1-pxc-0 |
+----------------+

Když se podíváme na umístění podu, všechny pody Percona XtraDB Cluster jsou umístěny na jiném hostiteli Kubernetes:

$ kubectl get pods -o wide --selector=app.kubernetes.io/component=pxc
NAME             READY   STATUS    RESTARTS   AGE   IP           NODE                                            NOMINATED NODE   READINESS GATES
cluster1-pxc-0   1/1     Running   0          67m   10.36.2.5    gke-my-k8s-cluster-default-pool-b80902cd-gp09   <none>           <none>
cluster1-pxc-1   1/1     Running   0          66m   10.36.1.10   gke-my-k8s-cluster-default-pool-b80902cd-rdv8   <none>           <none>
cluster1-pxc-2   1/1     Running   0          65m   10.36.0.11   gke-my-k8s-cluster-default-pool-b80902cd-jdc3   <none>           <none>

To určitě zlepší dostupnost služby v případě, že jeden z hostitelů Kubernetes vypadne.

Abychom škálovali až na 5 podů, musíme předem připravit další 2 nové uzly Kubernetes, aby respektovaly konfiguraci afinity pod (výchozí je affinity.antiAffinityTopologyKey.topologyKey="kubernetes.io/hostname"). Poté spusťte následující příkaz patch pro škálování Percona XtraDB Cluster na 5 uzlů:

$ kubectl patch pxc cluster1 \
--type='json' -p='[{"op": "replace", "path": "/spec/pxc/size", "value": 5 }]'

Monitorujte vytváření podu pomocí příkazu kubectl get pods:

$ kubectl get pods -o wide
NAME               READY   STATUS      RESTARTS   AGE   IP           NODE                                            NOMINATED NODE   READINESS GATES
cluster1-pxc-0     1/1     Running     0          27h   10.36.2.5    gke-my-k8s-cluster-default-pool-b80902cd-gp09   <none>           <none>
cluster1-pxc-1     1/1     Running     0          27h   10.36.1.10   gke-my-k8s-cluster-default-pool-b80902cd-rdv8   <none>           <none>
cluster1-pxc-2     1/1     Running     0          27h   10.36.0.11   gke-my-k8s-cluster-default-pool-b80902cd-jdc3   <none>           <none>
cluster1-pxc-3     1/1     Running     0          30m   10.36.7.2    gke-my-k8s-cluster-pool-1-ab14a45e-h1pf         <none>           <none>
cluster1-pxc-4     1/1     Running     0          13m   10.36.5.3    gke-my-k8s-cluster-pool-1-ab14a45e-01qn         <none>           <none>

Další 2 nové pody (cluster1-pxc-3 a cluster1-pxc-4) byly vytvořeny na dalších 2 nových uzlech Kubernetes (gke-my-k8s-cluster-pool-1-ab14a45e-h1pf a gke-my-k8s-cluster-pool-1-ab14a45e-01qn). Pro zmenšení jednoduše změňte hodnotu zpět na 3 ve výše uvedeném příkazu patch. Všimněte si, že Percona XtraDB Cluster by měl běžet s lichým počtem uzlů, aby se zabránilo rozdělení mozku.

Nasazení aplikace (WordPress)

V tomto příkladu nasadíme aplikaci WordPress nad náš Percona XtraDB Cluster a HAProxy. Nejprve si připravíme definiční soubor YAML takto:

$ cat wordpress-deployment.yaml
apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: LoadBalancer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - image: wordpress:4.8-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: cluster1-haproxy
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-cluster-secrets
              key: root
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim

Věnujte pozornost proměnným prostředí WORDPRESS_DB_HOST a WORDPRESS_DB_PASSWORD. První proměnná, kde jsme definovali "cluster1-haproxy" jako hostitele databáze, místo jednotlivého databázového uzlu a pro druhý jmenovaný jsme specifikovali heslo uživatele root tak, že jsme dali pokyn Kubernetes, aby jej načetl z objektu my-cluster-secrets pod klíčem "root", což je ekvivalentní "moje heslo" (po dekódování hodnoty base64). Přeskočíme definování proměnné prostředí WORDPRESS_DB_USER, protože výchozí hodnota je "root".

Nyní můžeme vytvořit naši aplikaci:

$ kubectl apply -f wordpress-deployment.yaml

Zkontrolujte službu:

$ kubectl get service
NAME                        TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                       AGE
cluster1-haproxy            ClusterIP      10.40.9.177    <none>          3306/TCP,3309/TCP,33062/TCP   4h42m
cluster1-haproxy-replicas   ClusterIP      10.40.0.236    <none>          3306/TCP                      4h42m
cluster1-pxc                ClusterIP      None           <none>          3306/TCP,33062/TCP            4h42m
cluster1-pxc-unready        ClusterIP      None           <none>          3306/TCP,33062/TCP            4h42m
wordpress                   LoadBalancer   10.40.13.205   35.200.78.195   80:32087/TCP                  4h39m

V tuto chvíli se můžeme připojit k naší aplikaci WordPress na http://35.200.78.195/ (externí IP adresa) a začít konfigurovat aplikaci WordPress. V tuto chvíli je naše aplikace WordPress připojena k jednomu z Percona XtraDB Clusteru (jednohlavní připojení) prostřednictvím jednoho z HAProxy podů.

To je prozatím vše. Další informace najdete v dokumentaci Percona Kubernetes Operator pro Percona XtraDB Cluster. Šťastné balení kontejnerů!