The RabbitMQ chart deploys a single RabbitMQ installation using a Kubernetes StatefulSet object (together with Services, PVCs, ConfigMaps, etc.). The figure below shows the deployed objects in the cluster after chart installation:
+--+ +--+ | | +-+ Configmaps | | Secrets | ++
Its lifecycle is managed using Helm and, at the RabbitMQ container level, the following operations are automated: persistence management, configuration based on environment variables and plugin initialization. The StatefulSet does not require any ServiceAccounts with special RBAC privileges, so this solution fits better in more restricted Kubernetes installations.
The RabbitMQ Operator chart deploys a RabbitMQ Operator installation using a Kubernetes Deployment. The figure below shows the RabbitMQ operator deployment after chart installation:
+--+ | | +--+ | +-+ ++ | RabbitMQ Operator | | | | | | RBAC | | Deployment | | Privileges | +-++ +-+-+ | ^ | | | ++ Service Account +<--+ | | | | | |--+ | | | | | | | | |--+ | | | | | | +-+ Configmaps | | | | Secrets | | | ++ | | | | | |-----|
This RabbitMQ Operator chart allows users to easily deploy multiple RabbitMQ instances compared to the RabbitMQ chart.
NOTE: As the Operator automatically deploys RabbitMQ installations, the RabbitMQ Operator pods will require a ServiceAccount with privileges to create and destroy multiple Kubernetes objects. This may be problematic for Kubernetes clusters with strict role-based access policies.