Общ преглед на клъстерния Kubernetes оператор Percona XtraDB

Ако сте били наоколо в света на контейнерите, щяхте да знаете, че е доста предизвикателно да се приеме пълна автоматизация на Kubernetes за клъстерирана система от бази данни, която обикновено добавя ниво на сложност към базираната на контейнери архитектура за тези приложения със състояние. Това е мястото, където Kubernetes Operator може да ни помогне да решим този проблем. Kubernetes Operator е специален тип контролер, въведен за опростяване на сложните внедрявания, който основно разширява Kubernetes API с персонализирани ресурси. Той се основава на основните концепции за ресурси и контролери на Kubernetes, но включва специфични за домейна или приложения познания за автоматизиране на целия жизнен цикъл на софтуера, който управлява.

Percona XtraDB Cluster Operator е чист начин за автоматизиране на специфичните задачи на Percona XtraDB Cluster като разгръщане, мащабиране, архивиране и надстройки в Kubernetes, изграден и поддържан от Percona. Той разгръща клъстера в StatefulSet с постоянен том, което ни позволява да поддържаме последователна идентичност за всеки Pod в клъстера и нашите данни да се поддържат.

В тази публикация в блога ще изпробваме внедряването на Percona XtraDB Cluster 8.0 в контейнерна среда, организирана от Percona XtraDB Cluster Kubernetes Operator на Google Cloud Platform.

Създаване на Kubernetes клъстер в Google Cloud

В това ръководство ще използваме клъстера Kubernetes в Google Cloud, защото е сравнително лесно и лесно да стартирате Kubernetes. Влезте във вашето табло за управление на Google Cloud Platform -> Compute -> Kubernetes Engine -> Създаване на клъстер и ще ви бъде представен следния диалогов прозорец:

Просто въведете името на Kubernetes Cluster, изберете предпочитаната от вас зона и щракнете върху „СЪЗДАВАНЕ “ (в долната част на страницата). След 5 минути Kubernetes клъстер с 3 възела ще бъде готов. Сега, на вашата работна станция, инсталирайте gcloud SDK, както е показано в това ръководство и след това изтеглете конфигурацията на Kubernetes във вашата работна станция:

$ 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.

В този момент трябва да можете да се свържете с клъстера Kubernetes. Изпълнете следната команда, за да проверите:

$ kubectl get nodes
NAME                                            STATUS   ROLES    AGE    VERSION
gke-my-k8s-cluster-default-pool-b80902cd-gp09   Ready    <none>   139m   v1.16.13-gke.401
gke-my-k8s-cluster-default-pool-b80902cd-jdc3   Ready    <none>   139m   v1.16.13-gke.401
gke-my-k8s-cluster-default-pool-b80902cd-rdv8   Ready    <none>   139m   v1.16.13-gke.401

Посоченият по-горе изход означава, че можем да се свържем с главната страница на Kubernetes и да извлечем възлите на клъстера на Kubernetes. Сега сме готови да стартираме работните натоварвания на Kubernetes.

Разгръщане на Percona XtraDB клъстер в Kubernetes

За разгръщане на работното натоварване ще следваме инструкциите, посочени в документацията на Percona XtraDB Cluster Operator. По принцип изпълняваме следната команда на нашата работна станция, за да създадем персонализираните ресурси, пространство от имена, контрол на достъпа, базиран на роли, а също и самия оператор 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

След това трябва да подготвим нашите пароли (нарича се Secrets в Kubernetes термин), като актуализираме стойностите в deploy/secrets.yaml в кодиран формат base64. Можете да използвате онлайн инструменти като https://www.base64encode.org/, за да създадете такъв или да използвате инструмент от командния ред като следния:

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

След това актуализирайте deploy/secrets.yaml, както е показано по-долу:

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==

Гореното е супер опростяване на тайното управление, при което настройваме всички пароли да бъдат еднакви за всички потребители. В производството, моля, използвайте по-сложна парола и посочете различна парола за всеки потребител.

Сега можем да изпратим тайната конфигурация в Kubernetes:

$ kubectl apply -f deploy/secrets.yaml

Преди да продължим напред, за да разположим Percona XtraDB клъстер, трябва да прегледаме отново дефиницията за разгръщане по подразбиране в deploy/cr.yaml за клъстера. Има много Kubernetes обекти, които са дефинирани тук, но повечето от тях са коментирани. За нашето работно натоварване бихме направили модификацията, както следва:

$ 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

Направихме някои модификации в предоставения cr.yaml, за да го накараме да работи с нашето приложение, както е показано по-горе. На първо място, трябва да коментираме (или да премахнем) всички линии, свързани с процесора, например [*].resources.requests.cpu:600m, за да сме сигурни, че Kubernetes може да планира правилно създаването на модула на възли с ограничен процесор. След това трябва да добавим някои опции за съвместимост за Percona XtraDB Cluster 8.0, който е базиран на MySQL 8.0, за да работи гладко с нашето WordPress приложение, което ще внедрим по-късно, както е показано в следния откъс:

   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

Посоченото по-горе ще съответства на набора от символи по подразбиране на MySQL сървъра с PHP драйвера MySQLi в нашия WordPress контейнер. Следващият раздел е внедряването на HAProxy, където е зададено на "enabled:true". Има и ProxySQL секция с "enabled:false" - обикновено човек би избрал някое от обратните прокси сървъри за всеки клъстер. Последният раздел е конфигурацията за архивиране, където бихме искали да имаме насрочено ежедневно архивиране в 12:00 ч. всеки ден и да запазим последните 5 резервни копия.

Вече можем да започнем да внедряваме нашия Percona XtraDB клъстер с 3 възли:

$ kubectl apply -f deploy/cr.yaml

Процесът на създаване ще отнеме известно време. Операторът ще разгърне модулите Percona XtraDB Cluster като Stateful Set, което означава създаване на един модул в даден момент и на всеки Pod в StatefulSet ще бъде присвоен целочислен порядък, от 0 нагоре до N-1, който е уникален за набора. Процесът приключва, когато и операторът, и модулите достигнат състоянието си на работа:

$ 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

Тъй като този оператор е персонализиран ресурс, можем да манипулираме ресурса perconaxtradbcluster, за да харесваме стандартния ресурс на Kubernetes:

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

Можете също да използвате по-краткото име на ресурс, "pxc", и да опитате със следните команди:

$ kubectl describe pxc
$ kubectl edit pxc

Когато разглеждаме набора от работно натоварване, можем да кажем, че операторът е създал два 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

Операторът също така ще създаде съответните услуги, които ще балансират връзките към съответните модули:

$ 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

Гореният изход показва, че операторът е създал 4 услуги:

• cluster1-haproxy - Услугата за балансиран по натоварване MySQL един главен (3306), Прокси протокол (3309) и MySQL Admin (33062) - Нов административен порт, въведен в MySQL 8.0.14 и по-нови. Това е името на услугата или IP адреса на клъстера, който приложенията трябва да се свържат, за да имат връзка с един главен към клъстера Galera.
• cluster1-haproxy-replicas - Услугата за балансиран по натоварване MySQL мулти-мастер (3306). Това е името на услугата или IP адреса на клъстера, който приложенията трябва да се свържат, за да имат връзка с множество главни към клъстера Galera с алгоритъм за кръгово балансиране.
• cluster1-pxc - Услугата за PXC модули с балансирано натоварване, заобикаляйки HAProxy. Свързвайки се директно с тази услуга, Kubernetes ще насочи връзката по кръгова система към всички PXC модули, подобно на това, което предоставя cluster-haproxy-replicase. Услугата няма присвоен публичен IP адрес и не е достъпна извън клъстера.
• cluster1-pxc-unready - Услугата „неготова“ е необходима за откриване на адрес на модула по време на стартиране на приложението, независимо от състоянието на Pod. Proxysql и pxc pods трябва да знаят един за друг, преди базата данни да започне да функционира напълно. Неготовата услуга няма присвоен публичен IP адрес и не е достъпна извън клъстера.

За да се свържете чрез MySQL клиент, просто изпълнете следната команда:

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

Това ще създаде преходен Pod и незабавно ще влезе в средата на контейнера. След това изпълнете стандартната клиентска команда на mysql с подходящи идентификационни данни:

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 |
+----------------+

Когато разгледаме разположението на Pod, всички модули на Percona XtraDB Cluster се намират на различен хост на 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>

Това определено ще подобри наличността на услугата, в случай че някой от хостовете на Kubernetes не работи.

За да мащабираме до 5 модула, трябва предварително да подготвим още 2 нови възела на Kubernetes, за да спазваме конфигурацията на афинитета на модула (по подразбиране е affinity.antiAffinityTopologyKey.topologyKey="kubernetes.io/hostname"). След това изпълнете следната команда за корекция, за да мащабирате Percona XtraDB Cluster до 5 възела:

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

Наблюдавайте създаването на модула, като използвате командата 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>

Още 2 нови модула (cluster1-pxc-3 и cluster1-pxc-4) бяха създадени на други 2 нови възела на Kubernetes (gke-my-k8s-cluster-pool-1-ab14a45e-h1pf и gke-my-k8s-cluster-pool-1-ab14a45e-01qn). За да намалите мащаба, просто променете стойността обратно на 3 в горната команда за корекция. Имайте предвид, че Percona XtraDB Cluster трябва да работи с нечетен брой възли, за да предотврати разделянето на мозъка.

Разгръщане на приложение (WordPress)

В този пример ще разположим приложение на WordPress върху нашия Percona XtraDB Cluster и HAProxy. Нека първо подготвим файла с дефиниция на YAML, както следва:

$ 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

Обърнете внимание на променливите на средата WORDPRESS_DB_HOST и WORDPRESS_DB_PASSWORD. Първата променлива, където дефинирахме "cluster1-haproxy" като хост на базата данни, вместо индивидуален възел на базата данни, а за втората посочихме root паролата, като инструктирахме Kubernetes да я прочете от my-cluster-secrets обекта под ключ "root", което е еквивалентно на "mypassword" (след като стойността на base64 е била декодирана). Пропускаме дефинирането на променливата на средата WORDPRESS_DB_USER, тъй като стойността по подразбиране е "root".

Сега можем да създадем нашето приложение:

$ kubectl apply -f wordpress-deployment.yaml

Проверете услугата:

$ 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

В този момент можем да се свържем с нашето WordPress приложение на адрес http://35.200.78.195/ (външният IP адрес) и да започнем да конфигурираме приложението WordPress. В този момент нашето приложение WordPress е свързано с един от Percona XtraDB Cluster (единична главна връзка) чрез един от модулите на HAProxy.

Това е всичко засега. За повече информация вижте документацията на Percona Kubernetes Operator за Percona XtraDB Cluster. Приятно контейнеризиране!