Menu

RabbitMQ Cluster Operator for Kubernetes

RabbitMQ Cluster Kubernetes Operator is a Kubernetes operator that automates provisioning, management, and operations of RabbitMQ clusters running on Kubernetes.

Kubernetes Operators are software extensions to Kubernetes that provide custom resources for management of applications, services and their components.

In this and other Operator related guides, we use "Operator" (with a capital O) to refer to a Kubernetes Operator pattern implementation and "operator" (with a lowercase o) to refer to a technical operations engineer (administrator).

The Operator provides a consistent and easy way to deploy RabbitMQ clusters to Kubernetes and run them, including "day two" (continuous) operations. RabbitMQ clusters deployed using the operator can be used by applications running on Kubernetes or outside of Kubernetes.

Documentation of the Operator spans several guides:

Source Code

The Operator is open source. You can contribute to its development on GitHub.

License

The Operator is released under the Mozilla Public License 2.0.

Key Features

The operator provides the following key features:

  • Provisioning of single-node and multi-node RabbitMQ clusters
  • Automatic reconciliation of deployed clusters whenever their actual state does not match the expected state
  • Monitoring of RabbitMQ clusters using Prometheus and Grafana

Automated rolling upgrades of RabbitMQ clusters is a feature that will be provided in later versions.

Supported Kubernetes Versions

The Operator requires

Installation

The Kubernetes Operator has a dedicated installation guide.

Limitations

General Limitations

  • This product is intended to be used with any Kubernetes distribution. However, given the number of Kubernetes vendors, versions, and configurations, not all of them have been tested.
  • This product has been tested with Google Kubernetes Engine (GKE).
  • Kubernetes Operator upgrades are not currently supported. To deploy a newer version, delete the previous version first.

RabbitMQ Cluster Reconciliation

Deleted Secret objects will be recreated by the Kubernetes Operator but the newly generated secret value will not be deployed to the RabbitMQ cluster. For example, if the Secret with administrator credentials is deleted, a new Secret will be created with new username and password, but those will not be reflected in the RabbitMQ cluster. It works the same way for any Secret value, e.g. the value of the shared inter-node authentication secret known as the Erlang cookie.

Getting Help and Providing Feedback

If you have questions about the contents of this guide or any other topic related to RabbitMQ, don't hesitate to ask them on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you'd like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!