mariadb-operator

README

🦭 mariadb-operator

Run and operate MariaDB in a cloud native way. Declaratively manage your MariaDB using Kubernetes CRDs rather than imperative commands.

• Provisioning highly configurable MariaDB servers
• Multi-master HA via Galera✨. Automatic Galera cluster recovery ✨
• Single-master HA via SemiSync replication. Primary switchover. Automatic primary failover
• Take and restore backups. Scheduled backups. Backup rotation
• PVCs and Kubernetes volumes (i.e. NFS) backup storage
• Bootstrap new instances from backups and volumes (i.e NFS)
• Manage users, grants and logical databases
• Configure connections for your applications
• Orchestrate and schedule sql scripts
• Prometheus metrics
• Validation webhooks to provide CRD inmutability
• Additional printer columns to report the current CRD status
• CRDs designed according to the Kubernetes API conventions
• GitOps friendly
• Multi-arch distroless based image
• Install it using kubectl, helm or OLM

Bare minimum installation

This installation flavour provides the minimum resources required to run mariadb-operator in your cluster.

helm repo add mariadb-operator https://mariadb-operator.github.io/mariadb-operator
helm install mariadb-operator mariadb-operator/mariadb-operator

Recommended installation

The recommended installation includes the following features to provide a better user experiende and reliability:

• Metrics: Leverage prometheus operator to scrape metrics from both the mariadb-operator and the provisioned MariaDB instances.
• Webhook certificate renewal: Automatic webhook certificate issuance and renewal using cert-manager. By default, a static self-signed certificate is generated.

helm repo add mariadb-operator https://mariadb-operator.github.io/mariadb-operator
helm install mariadb-operator mariadb-operator/mariadb-operator \
  --set metrics.enabled=true --set webhook.certificate.certManager=true

Openshift

The Openshift installation is managed separately in the mariadb-operator-helm repository, which contains a helm based operator that allows you to install mariadb-operator via OLM.

Quickstart

Let's see mariadb-operator🦭 in action! First of all, install the following configuration manifests that will be referenced by the CRDs further:

kubectl apply -f examples/manifests/config

Next, you can proceed with the installation of a MariaDB instance:

kubectl apply -f examples/manifests/mariadb_v1alpha1_mariadb.yaml

kubectl get mariadbs
NAME      READY   STATUS    PRIMARY POD     AGE
mariadb   True    Running   mariadb-0       3m57s

kubectl get statefulsets
NAME      READY   AGE
mariadb   1/1     2m12s

kubectl get services
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mariadb      ClusterIP   10.96.235.145   <none>        3306/TCP,9104/TCP   2m17s

Up and running 🚀, we can now create our first logical database and grant access to users:

kubectl apply -f examples/manifests/mariadb_v1alpha1_database.yaml
kubectl apply -f examples/manifests/mariadb_v1alpha1_user.yaml
kubectl apply -f examples/manifests/mariadb_v1alpha1_grant.yaml

kubectl get databases
NAME        READY   STATUS    CHARSET   COLLATE           AGE
data-test   True    Created   utf8      utf8_general_ci   22s

kubectl get users
NAME              READY   STATUS    MAXCONNS   AGE
mariadb-metrics   True    Created   3          19m
user              True    Created   20         29s

kubectl get grants
NAME              READY   STATUS    DATABASE   TABLE   USERNAME          GRANTOPT   AGE
mariadb-metrics   True    Created   *          *       mariadb-metrics   false      19m
user              True    Created   *          *       user              true       36s

At this point, we can run our database initialization scripts:

kubectl apply -f examples/manifests/sqljobs

kubectl get sqljobs
NAME       COMPLETE   STATUS    MARIADB   AGE
01-users   True       Success   mariadb   2m47s
02-repos   True       Success   mariadb   2m47s
03-stars   True       Success   mariadb   2m47s

kubectl get jobs
NAME                  COMPLETIONS   DURATION   AGE
01-users              1/1           10s        3m23s
02-repos              1/1           11s        3m13s
03-stars-28067562     1/1           10s        106s

kubectl get cronjobs
NAME       SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
03-stars   */1 * * * *   False     0        57s             2m33s

Now that the database has been initialized, let's take a backup:

kubectl apply -f examples/manifests/mariadb_v1alpha1_backup_scheduled.yaml

After one minute, the backup should have completed:

kubectl get backups
NAME               COMPLETE   STATUS    MARIADB   AGE
backup-scheduled   True       Success   mariadb   15m

kubectl get cronjobs
NAME               SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
backup-scheduled   */1 * * * *   False     0        56s             15m

kubectl get jobs
NAME                                    COMPLETIONS   DURATION   AGE
backup-scheduled-27782894               1/1           4s         3m2s

Last but not least, let's provision a second MariaDB instance bootstrapping from the previous backup:

kubectl apply -f examples/manifests/mariadb_v1alpha1_mariadb_from_backup.yaml

kubectl get mariadbs
NAME                  READY   STATUS    PRIMARY POD             AGE
mariadb               True    Running   mariadb-0               7m47s
mariadb-from-backup   True    Running   mariadb-from-backup-0   53s

kubectl get restores
NAME                                         COMPLETE   STATUS    MARIADB               AGE
bootstrap-restore-mariadb-from-backup        True       Success   mariadb-from-backup   72s

kubectl get jobs
NAME                                         COMPLETIONS   DURATION   AGE
backup                                       1/1           9s         12m
bootstrap-restore-mariadb-from-backup        1/1           5s         84s

You can take a look at the whole suite of example CRDs available in examples/manifests.

High availavility

This operator supports two different modes of HA:

• Multi master HA via Galera ✨: All nodes support both reads and writes.
• Single master HA via SemiSync replication: The primary node allows both reads and writes, while secondary nodes only allow reads. To facilitate writes in the primary node, an additional primary-<mariadb-name> Service and Connection are created for convenience.

Whenever possible, it is recommended to use the Galera ✨ mode, as it provides improved resilience and simplifies write operations.

GitOps

You can configure mariadb-operator's CRDs in your git repo and reconcile them using your favorite GitOps tool, see an example with flux:

• Run and operate MariaDB in a GitOps fashion using Flux

Roadmap

Take a look at our 🛣️ roadmap and feel free to open an issue to suggest new features.

Contributing

If you want to report a 🐛 or you think something can be improved, please check our contributing guide and take a look at our open issues. PRs are welcome!

Get in touch

• Slack
• mariadb-operator@proton.me

Documentation

Overview

Copyright © 2023 Martín Montes <martin11lrx@gmail.com>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.