MySQL Operator
Kubernetes Custom Resource for MySQL.
Running MySQL Operator
In order for the custom resources to be properly processed and an actual MySQL cluster
deployed, a running instance of the MySQL Operator is required inside your Kubernetes
infrastructure. The operator listens for changes on MySQLCluster and MySQLBackupSchedule
custom resources and creates the appropriate objects.
As a Kubernetes pod
This is the recommended option. MySQL Operator will run as a pod inside your
Kubernetes cluster.
kubectl run mysql-operator --image=grtl/mysql-operator:latest
As an out-of-cluster binary
Another option (suitable for development rather than a production-ready solution)
is to run the MySQL Operator binary outside of the Kubernetes cluster.
go get -u github.com/grtl/mysql-operator
mysql-operator -kubeconfig ~/.kube/config
Run code directly (ex. after making changes)
git clone https://github.com/grtl/mysql-operator && cd $_
go run -kubeconfig ~/.kube/config
MySQL Operator Docker image
Download from DockerHub
Download MySQL Operator image from DockerHub to easily deploy it in your
Kubernetes cluster.
docker pull grtl/mysql-operator
Build yourself
Or build it yourself
GOOS=linux GOARCH=amd64 go build -o mysql-operator && docker build .
Usage
Make sure the operator is up and running before creating any custom resources.
All resources may be created with standard Kubernetes yaml files.
Clusters
Creating a cluster
First, a Kubernetes Secret containing the database password needs to be created.
kubectl create secret generic my-secret --from-literal=password="P4sSw0rD"
Then you can create a cluster from a yaml file.
kubectl create -f cluster-config.yaml
Example cluster-config.yaml (minimal)
apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
name: "my-cluster"
spec:
secret: "my-secret"
Example cluster-config.yaml (fully customized)
apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
name: "my-cluster"
spec:
secret: "my-secret" # Name of the secret containing the password
port: 3306 # Port on which the service will expose the MySQL
replicas: 2 # Number of replicas
storage: "1Gi" # Persistance Volume Claim size for each replica
image: "mysql:latest" # MySQL image
Restoring a cluster from the backup
While creating a cluster its data may be restored from an existing
backup instance. The only difference between the
configuration files for creating a cluster and
the one to restore a cluster from backup is an additional field
fromBackup field pointing to the backup instance.
kubectl create -f cluster-restore-config.yaml
Example cluster-restore-config.yaml (minimal)
apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
name: "my-cluster"
spec:
secret: "my-secret"
fromBackup: "my-backup-2017-12-14-01-22"
Example cluster-restore-config.yaml (fully customized)
apiVersion: cr.mysqloperator.grtl.github.com/v1
kind: MySQLCluster
metadata:
name: "my-cluster"
spec:
secret: "my-secret"
fromBackup: "my-backup-2017-12-14-01-22"
port: 3306
replicas: 2
storage: "1Gi"
image: "mysql:latest"
Deleting a cluster
Simply delete the cluster custom resource
kubectl delete mc "my-cluster"
Backup Schedules
Creating a backup schedule
You can create a backup schedule, which will automatically create backups
according to the schedule (cron job style).
kubectl create -f backup-config.yaml
Example backup-config.yaml
apiVersion: cr.mysqlbackup.grtl.github.com/v1
kind: MySQLBackup
metadata:
name: "my-backup"
spec:
cluster: "my-cluster"
time: "*/5 * * * *" # Create a backup every 5 minutes
Deleting a backup schedule
Simply delete the backup schedule custom resource
kubectl delete mbs "my-backup"
Backup Instances
A backup schedule will create backup instances according to the schedule.
Getting backup instances
Get all backup instances
kubectl get mbi
Get all backup instances created within a given backup schedule
kubectl get mbi -l schedule="my-backup"
Get all backup instances created for a given cluster
kubectl get mbi -l cluster="my-cluster"
Standard kubectl output for backup instances lacks important fields, for
a valuable output we recommend using output flag with the following configuration.
kubectl get mbi -o custom-columns="NAME:metadata.name,STATUS:status.phase,\
SCHEDULE:spec.schedule,CLUSTER:spec.cluster,CREATED:metadata.creationTimestamp"
Example output:
NAME STATUS SCHEDULE CLUSTER CREATED
my-backup-instance Completed my-backup my-cluster 2018-04-27T14:42:33Z
Deleting a backup instance
Simply delete the backup instance custom resource
kubectl delete mbi "my-backup-instance"
Be aware that removing a backup instance will delete its contents from
the Persistent Volume.