geerlingguy / mariadb-operator

MariaDB operator for Kubernetes built with Ansible and the Operator SDK.

MariaDB Operator for Kubernetes

This is a MariaDB Operator, which makes management of MariaDB instances (or clusters) running inside Kubernetes clusters easy. It was built with the Operator SDK using Ansible.

Usage

This Kubernetes Operator is meant to be deployed in your Kubernetes cluster(s) and can manage one or more MariaDB database instances or clusters in any namespace.

First you need to deploy MariaDB Operator into your cluster:

kubectl apply -f https://raw.githubusercontent.com/geerlingguy/mariadb-operator/master/deploy/mariadb-operator.yaml

Then you can create instances of MariaDB in any namespace, for example:

1. Create a file named my-database.yml with the following contents:

   ---
   apiVersion: mariadb.mariadb.com/v1alpha1
   kind: MariaDB
   metadata:
     name: example-mariadb
     namespace: example-mariadb
   spec:
     masters: 1
     replicas: 0
     mariadb_password: CHANGEME
     mariadb_image: mariadb:10.4
     mariadb_pvc_storage_request: 1Gi
   

2. Use kubectl to create the MariaDB instance in your cluster:

   kubectl apply -f my-database.yml
   

You can also deploy MariaDB instances into other namespaces by changing metadata.namespace, or deploy multiple MariaDB instances into the same namespace by changing metadata.name.

Connecting to the running database

Once the database instance has been deployed and initialized (this can take up to a few minutes), you can connect to it using the MySQL CLI from within the same namespace as your database instance, for example:

kubectl -n example-mariadb run -it --rm mysql-client --image=arey/mysql-client --restart=Never -- -h example-mariadb-0.example-mariadb.example-mariadb.svc.cluster.local -u db_user -pCHANGEME -D db

Other applications can connect to the database instance from within the same namespace using the following connection parameters:

• Host: example-mariadb-0.example-mariadb.example-mariadb.svc.cluster.local
• Username: db_user
• Password: CHANGEME
• Database: db

Exposing an instance to the outside world

You can also expose a database instance to the outside world by adding a Service to connect to port 3360:

---
apiVersion: v1
kind: Service
metadata:
  name: mariadb-master
  namespace: example-mariadb
spec:
  type: NodePort
  selector:
    statefulset.kubernetes.io/example-mariadb: example-mariadb-0
  ports:
  - protocol: TCP
    port: 3360
    targetPort: 3360

Once you create that service in the same namespace, you can connect to MariaDB via the NodePort assigned to the service.

Development

Release Process

There are a few moving parts to this project:

1. The Docker image which powers MariaDB Operator.
2. The mariadb-operator.yaml Kubernetes manifest file which initially deploys the Operator into a cluster.

Each of these must be appropriately built in preparation for a new tag:

Build a new release of the Operator for Docker Hub

Run the following command inside this directory:

operator-sdk build geerlingguy/mariadb-operator:0.0.3

Then push the generated image to Docker Hub:

docker push geerlingguy/mariadb-operator:0.0.3

Build a new version of the mariadb-operator.yaml file

Verify the build/chain-operator-files.yml playbook has the most recent version/tag of the Docker image, then run the playbook in the build/ directory:

ansible-playbook chain-operator-files.yml

After it is built, test it on a local cluster:

minikube start
minikube addons enable ingress
kubectl apply -f deploy/mariadb-operator.yaml
kubectl create namespace example-mariadb
kubectl apply -f deploy/crds/mariadb_v1alpha1_mariadb_cr.yaml
<test everything>
minikube delete

If everything is deployed correctly, commit the updated version and push it up to GitHub, tagging a new repository release with the same tag as the Docker image.

Testing

Local tests with Molecule and KIND

Ensure you have the testing dependencies installed (in addition to Docker):

pip install docker molecule openshift jmespath

Run the local molecule test scenario:

molecule test -s test-local

Local tests with minikube

TODO.

Authors

This operator is maintained by Jeff Geerling, author of Ansible for DevOps and Ansible for Kubernetes.

mariadb-operator's Issues

Add option to back up database PVC

Using Kubernetes' Volume Snapshots, allow the configuration of a daily or weekly backup via snapshots in the CRD.

Operator not built for ARM

Can the mariadb operator be built for ARM? When running on a raspberry pi cluster (K3s), getting the dreaded

ansible standard_init_linux.go:219: exec user process caused: exec format error                                                                                                         ansible stream closed                                                                                                                                                                 
operator standard_init_linux.go:219: exec user process caused: exec format error                                                                                                        operator stream closed

which I think is architecture related?

Thanks

Port operator to Operator SDK 1.0 layout

See: https://sdk.operatorframework.io/docs/building-operators/ansible/migration/

Allow scaling from one master pod to replicas, and vice-versa

Since we have Ansible available, we should be able to detect when new replica pods have been added, and ensure they get synced to the master, e.g. if someone starts a MariaDB CR with just a single pod, then later adds replicas.

Update CI for Molecule v3, update base operator image

See title...

Update to operator sdk v0.16.0

This is the latest version—see similar changes required for the tower-operator here: geerlingguy/tower-operator@e22296a

Deployment of replication mariadb server

I am trying to deploy a Mariadb server with 1 master and 2 replicas. The database.yml is as follows:

apiVersion: mariadb.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: example-mariadb
  namespace: example-mariadb
spec:
  masters: 1
  replicas: 2
  mariadb_password: CHANGEME
  mariadb_image: mariadb:10.5
  mariadb_pvc_storage_request: 1Gi

The statefulset is getting deployed with just one pod. I think replicas: 1 is hardcorded which is the reason this is happening.

Specifying storage class

Hi,

This is a question. Apologize in advance if it is inappropriate.

I see that storage size is provided through mariadb_pvc_storage_request, how about storage class?

My usage case requires the pvc be provisioned from a non-default storage class. If I were to edit roles/mariadb/templates/mariadb_statefulset.yaml.j2, how are the changes reflected when 'kubectl apply -f my-database.yml' is executed?

Thanks,

Failover to replica automatically if master is absent

If set up as master/replica, also add logic to determine if the master is gone, and if so, promote one of the replicas to master, and when master is back, demote it to replica... something along those lines.

Blocked by #3.

Create thorough README with usage and maintenance information

I need a lot more info in the README to keep myself up to speed, and to onramp new users more easily. It's pretty sparse right now :)

One especially important thing is to show someone how, after they deploy the operator, they can test it out quickly:

kubectl -n example-mariadb run -it --rm mysql-client --image=arey/mysql-client --restart=Never -- -h example-mariadb.example-mariadb.svc.cluster.local -u db_user -pTODO -D db
MariaDB [db]>

Use StatefulSet instead of Deployment for MariaDB Pod(s)

From StatefulSets documentation.

StatefulSet is the workload API object used to manage stateful applications.

Manages the deployment and scaling of a set of Pods , and provides guarantees about the ordering and uniqueness of these Pods.

Like a Deployment , a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

StatefulSets are better for database use cases, where some level of persistence and statefulness is preferred.

Generate initial scaffold operator with one node, no cluster

There already exists a Percona Cluster operator, but it requires a minimum of three nodes (pods) to run, and I want a more flexible setup that can use anywhere from one to n(?) number of pods in a single master or replicated setup, with self-healing.

There will be other features coming soon, but for the first alpha, I just want an operator that scaffolds one single MariaDB instance, with a PVC for the data volume, a configurable root and/or extra non-root user, a database name, and a service by which other applications can access the MariaDB instance.

Add cluster management capability

Allow control over whether the MariaDB resource is a single-master configuration, or a cluster with a master and n slave/replica instances.

For now, just allowing the cluster to be configured this way is enough. In a follow-up issue, we'll deal with logic for what to do if master goes away, and how the K8s service should react.

The project is still alive ?

Hello,

Do you continue to maintain this project ?
I search a simple mariadb operator.

And how I can define the namesapce, ressources request and limits for the pods managed by the operator ?

Regards,

Thierry.