Run and operate MariaDB in a cloud native way. Declaratively manage your MariaDB using Kubernetes CRDs rather than imperative commands.
- Easily provision MariaDB servers in Kubernetes.
- Highly configurable MariaDB servers.
- Multiple HA modes: SemiSync Replication and Galera.
- Automated primary failover.
- Automated Galera cluster recovery.
- Enhanced HA with MaxScale: a sophisticated database proxy, router, and load balancer designed specifically for and by MariaDB.
- Flexible storage configuration. Volume expansion.
- Take and restore backups.
- Scheduled backups.
- Multiple backup storage types: S3 compatible, PVCs and Kubernetes volumes.
- Backup retention policy.
- Target recovery time: infer which backup to restore.
- Bootstrap new instances from: Backups, S3, PVCs ...
- Rolling updates: roll out replica Pods one by one, wait for each of them to become ready, and then proceed with the primary Pod.
- my.cnf configuration. Automatically trigger rolling updates when my.cnf changes.
- Prometheus metrics via mysqld-exporter.
- Manage users, grants and logical databases.
- Configure connections for your applications.
- Orchestrate and schedule sql scripts.
- Validation webhooks to provide CRD immutability.
- 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.
Please, refer to the documentation, the API reference and the example suite for further detail.
This installation flavour provides the minimum resources required to run mariadb-operator
in your cluster.
helm repo add mariadb-operator https://helm.mariadb.com/mariadb-operator
helm install mariadb-operator mariadb-operator/mariadb-operator
The recommended installation includes the following features:
- Metrics: Leverage prometheus operator to scrape the
mariadb-operator
internal metrics. - 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://helm.mariadb.com/mariadb-operator
helm install mariadb-operator mariadb-operator/mariadb-operator \
--set metrics.enabled=true --set webhook.cert.certManager.enabled=true
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.
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.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/database.yaml
kubectl apply -f examples/manifests/user.yaml
kubectl apply -f examples/manifests/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
user True Created 20 29s
kubectl get grants
NAME READY STATUS DATABASE TABLE USERNAME GRANTOPT AGE
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/backup.yaml
kubectl get backups
NAME COMPLETE STATUS MARIADB AGE
backup True Success mariadb 15m
kubectl get jobs
NAME COMPLETIONS DURATION AGE
backup-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_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 embrace GitOps best practises by using this operator, just place your CRDs in a git repo and reconcile them with your favorite tool, see an example with flux:
Take a look at our roadmap and feel free to open an issue to suggest new features.
Please create a PR and add your company or project to our ADOPTERS.md file if you are using our project!
We welcome and encourage contributions to this project! Please check our contributing and development guides. PRs welcome!
- We Tested and Compared 6 Database Operators. The Results are In! - KubeCon EU, March 2024
- Get Started with MariaDB in Kubernetes and mariadb-operator - MariaDB Corporation blog, February 2024
- Run and operate MariaDB in Kubernetes with mariadb-operator - MariaDB Foundation blog, July 2023
- L'enfer des DB SQL sur Kubernetes face à la promesse des opérateurs - KCD France, March 2023