Concepts
Overview
RabbitMQ is a lightweight, high-performance, open-source message broker that supports multiple messaging protocols including AMQP. It is widely used for building scalable and decoupled microservices and distributed systems.
When deployed using Portworx Data Services (PDS) on Kubernetes, RabbitMQ benefits from enhanced scalability, automation, persistent storage, and fault tolerance—all while maintaining a simplified operational experience. PDS enables users to deploy, scale, and monitor RabbitMQ seamlessly using Kubernetes-native constructs.
PDS supports the RabbitMQ Community Edition and tracks upstream releases to ensure compatibility and timely availability of new versions. Supported versions are listed here.
RabbitMQ instances in PDS are managed via a custom Kubernetes resource (rabbitmq
) by the PDS Deployments Operator.
Clustering
PDS supports deploying RabbitMQ in clustered mode, enabling high availability and improved throughput across nodes.
RabbitMQ clusters in PDS:
-
Consist of multiple broker pods running in a Kubernetes StatefulSet.
-
Automatically discover and connect with each other to form a cluster.
-
Can tolerate node failures and distribute load across nodes.
-
Use mirrored queues (quorum queues or classic mirrored queues) to ensure message redundancy and fault tolerance.
Cluster management is handled transparently by PDS with minimal configuration required.
Replication
RabbitMQ in PDS benefits from application-level and storage-level replication:
Application-Level Replication
-
PDS supports quorum queues for strong data safety and consistency.
-
Messages are replicated across multiple RabbitMQ nodes, ensuring durability in the event of node failure.
-
Queue replication policies can be customized as needed for workload requirements.
Storage-Level Replication
-
RabbitMQ data is persisted to Portworx volumes.
-
Volumes are configured with replication to ensure data availability across Kubernetes worker nodes or zones.
-
This allows RabbitMQ pods to be rescheduled quickly and serve traffic without data loss.
Configuration
RabbitMQ configurations in PDS are easily tunable via environment variables or configuration templates. PDS simplifies the process of customizing and managing these configurations at scale. For a full list of configurable parameters, refer to the PDS RabbitMQ Configuration Reference.
Scaling
PDS makes it easy to scale RabbitMQ vertically and horizontally:
Vertical Scaling
-
Adjust CPU and memory resources allocated to RabbitMQ pods dynamically.
-
Scaling changes are rolled out automatically with zero manual intervention.
Horizontal Scaling
-
Increase the number of RabbitMQ pods in the cluster to improve message throughput and resilience.
-
New nodes automatically join the cluster and sync state where needed.
This enables users to respond to increased load or redundancy needs with a single operation.
Connectivity
RabbitMQ deployments in PDS include managed service endpoints and DNS for stable connectivity:
Endpoints
Service Name | Details |
---|---|
rmq-<name>-<namespace>-<pod-id>-vip | Endpoint for each pod |
rmq-<name>-<namespace>-rr | Round Robin Endpoint to all pods |
-
Connection details (including credentials) are available directly in the PDS UI.
-
PDS creates a default pds user with administrator privileges.
Backups
Backup is not supported for RabbitMQ.
Monitoring
RabbitMQ deployments in PDS are equipped with built-in Prometheus exporters to expose key metrics. For the complete list of supported metrics and example usage, refer to the PDS RabbitMQ Metrics Reference.