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
- 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
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
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 provisionedMariaDB
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
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 config/samples/config
To start with, let's provision a MariaDB
instance:
kubectl apply -f config/samples/mariadb_v1alpha1_mariadb.yaml
kubectl get mariadbs
NAME READY STATUS PRIMARY 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 config/samples/mariadb_v1alpha1_database.yaml
kubectl apply -f config/samples/mariadb_v1alpha1_user.yaml
kubectl apply -f config/samples/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 config/samples/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 config/samples/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 config/samples/mariadb_v1alpha1_mariadb_from_backup.yaml
kubectl get mariadbs
NAME READY STATUS PRIMARY AGE
mariadb True Running mariadb-0 30m57s
mariadb-from-backup True Running mariadb-0 85s
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 config/samples.
You can configure mariadb-operator
's CRDs in your git repo and reconcile them using your favorite GitOps tool, see an example with flux:
Take a look at our 🛣️ roadmap and feel free to open an issue to suggest new features.
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!