Operator for RabbitMQ
Status: Pre-alpha! Not for production use! Breaking changes can appear at anytime without notice!
Provision and manage RabbitMQ clusters on Kubernetes! This operator currently has the following features:
- Deploy N-node RabbitMQ clusters, utilizing auto-discovery for automatic clustering
- Scale cluster replicas, storage, and CPU
- Specify persistent volume storage class
- Expose clusters to external clients using a LoadBalancer
- Datadog auto-discovery annotations
- Safely resolve network partitions without dropping messages (experimental, requires manual custom resource creation)
You must have a Kubernetes cluster. Standard Pod and Service networking must work.
The example assumes you have Rook-managed storage deployed. You can read about Rook at https://rook.io/.
Deploying the operator
Apply the operator configuration yaml. You should see a
rabbitmq-operator pod spin up in the
kubectl apply -f examples/rabbitmq_operator.yaml
Deploying a cluster
Apply the example RabbitMQCustomResource. By default, this deploys a cluster with 3 instances in the
kubectl apply -f examples/rabbitmq_instance.yaml
Connecting to the cluster
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/.
Custom Resource Schema
||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:
- Shovel configuration
- Policy configuration
- Improvements to user management
Code of Conduct
Operator for RabbitMQ is governed by the Contributor Covenant v 1.4.1.
Operator for RabbitMQ is licensed under the Apache 2 License.