Provision and manage RabbitMQ clusters on Kubernetes! This operator currently has the following features:
You must have a Kubernetes cluster. Standard Pod and Service networking must work.
You must also have a Docker registry that both your development environment and the Kubernetes cluster can access via the CNAME
The example assumes you have Rook-managed storage deployed. You can read about Rook at https://rook.io/.
Use the script
deploy-operator.sh to build and push the operator image. At the end you should see a
rabbitmq-operator pod spin up in the
Apply the example RabbitMQCustomResource. By default, this deploys a cluster with 3 instances in the
kubectl apply -f examples/rabbitmq_instance.yaml
For each cluster, a service called
<cluster name>-svc will be created. This is a standard (non-headless) service. Nodes will be added to the relevant Endpoints as soon as their healthcheck returns ok. A cluster named
myrabbitmq in namespace
rabbitmqs can be internally accessed at
myrabbitmq.rabbitmqs.svc.cluster.local. Standard RabbitMQ ports are exposed.
To access a RabbitMQ cluster from outside the Kubernetes cluster, you need to either expose the Rabbit cluster using a NodePort or set
true. This will provision a LoadBalancer service with name
<cluster-name>-svc-lb (assuming your environment supports it). You can then access your cluster using the LoadBalancer IP and standard RabbitMQ ports.
For more information on Service DNS and routing, see https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/.
||string||Name of RabbitMQ image|
||string||Name of initContainer image|
||boolean||Whether to create a LoadBalancer service|
||boolean||When scaling down a cluster, whether to preserve "orphaned" PVCs; this field is optional and defaults to false|
||number||Number of cluster nodes|
||string||CPU request per node, ex: "500m"|
||string||Memory request per node, ex: "512Mi"|
||string||Storage class to use for persistent storage (immutable)|
||string||PersistentVolume size per cluster node (immutable)|
||string||RabbitMQ high watermark, ex: 0.4|
Note: Scaling replicas down is a dangerous operation. The operator does not currently make any safety guarantees when scaling down replicas.
This operator is very much a work-in-progress. Features that we want to implement in the near future include:
Operator for RabbitMQ is governed by the Contributor Covenant v 1.4.1.
Operator for RabbitMQ is licensed under the Apache 2 License.
Check the GitHub releases page for the latest version and from that determine the next version to release. On master, create a tag (
git tag <the new version>) and push it (
git push --tags). release.sh will see the tag is on master and push the new version to DockerHub automatically (via Travis).
Finally, add a
New Features section for the next version.