KubeBlocks
BlogsKubeBlocks Cloud
⌘K
​
Overview
Quickstart

Operations

Lifecycle Management
Vertical Scaling
Horizontal Scaling
Volume Expansion
Manage RabbitMQ Services
Decommission RabbitMQ Replica

Monitoring

Observability for RabbitMQ Clusters

tpl

  1. Prerequisites
  2. Deploy a RabbitMQ Cluster
  3. Verifying the Deployment
  4. Scale-out (Add Replicas)
    1. Verify Scale-Out
  5. Scale-in (Remove Replicas)
    1. Verify Scale-In
  6. Best Practices
  7. Cleanup
  8. Summary

Horizontal Scaling for RabbitMQ Clusters with KubeBlocks

This guide explains how to perform horizontal scaling (scale-out and scale-in) on a RabbitMQ cluster managed by KubeBlocks. You'll learn how to use both OpsRequest and direct Cluster API updates to achieve this.

Prerequisites

    Before proceeding, ensure the following:

    • Environment Setup:
      • A Kubernetes cluster is up and running.
      • The kubectl CLI tool is configured to communicate with your cluster.
      • KubeBlocks CLI and KubeBlocks Operator are installed. Follow the installation instructions here.
    • Namespace Preparation: To keep resources isolated, create a dedicated namespace for this tutorial:
    kubectl create ns demo
namespace/demo created

    Deploy a RabbitMQ Cluster

      KubeBlocks uses a declarative approach for managing RabbitMQ Clusters. Below is an example configuration for deploying a RabbitMQ Cluster with 3 replicas.

      Apply the following YAML configuration to deploy the cluster:

      apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: rabbitmq-cluster
  namespace: demo
spec:
  terminationPolicy: Delete
  clusterDef: rabbitmq
  topology: clustermode
  componentSpecs:
    - name: rabbitmq
      serviceVersion: 3.13.7
      replicas: 3
      resources:
        limits:
          cpu: "0.5"
          memory: "0.5Gi"
        requests:
          cpu: "0.5"
          memory: "0.5Gi"
      volumeClaimTemplates:
        - name: data
          spec:
            storageClassName: ""
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 20Gi

      Verifying the Deployment

        Monitor the cluster status until it transitions to the Running state:

        kubectl get cluster rabbitmq-cluster -n demo -w

        Expected Output:

        kubectl get cluster rabbitmq-cluster -n demo
NAME               CLUSTER-DEFINITION   TERMINATION-POLICY   STATUS     AGE
rabbitmq-cluster   rabbitmq             Delete               Creating   15s
rabbitmq-cluster   rabbitmq             Delete               Running    83s

        Check the pod status and roles:

        kubectl get pods -l app.kubernetes.io/instance=rabbitmq-cluster -n demo

        Expected Output:

        NAME                          READY   STATUS    RESTARTS   AGE
rabbitmq-cluster-rabbitmq-0   2/2     Running   0          106s
rabbitmq-cluster-rabbitmq-1   2/2     Running   0          82s
rabbitmq-cluster-rabbitmq-2   2/2     Running   0          47s

        Once the cluster status becomes Running, your RabbitMQ cluster is ready for use.

        TIP

        If you are creating the cluster for the very first time, it may take some time to pull images before running.

        Scale-out (Add Replicas)

        Expected Workflow:

        1. New pod is provisioned, and transitions from Pending to Running.
        2. Cluster status changes from Updating to Running
        NOTE

        RabbitMQ quorum queue are designed based on the Raft consensus algorithm. Better to have an odd number of replicas, such as 3, 5, 7, to avoid split-brain scenarios, after scaling out/in the cluster.

        Option 1: Using Horizontal Scaling OpsRequest

        Scale out the RabbitMQ cluster by adding 1 replica to rabbitmq component:

        apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: rabbitmq-cluster-scale-out-ops
  namespace: demo
spec:
  clusterName: rabbitmq-cluster
  type: HorizontalScaling
  horizontalScaling:
  - componentName: rabbitmq
    # Specifies the replica changes for scaling in components
    scaleOut:
      # Specifies the replica changes for the component.
      # add one more replica to current component
      replicaChanges: 1

        Monitor the progress of the scaling operation:

        kubectl get ops rabbitmq-cluster-scale-out-ops -n demo -w

        Expected Result:

        NAME                             TYPE                CLUSTER          STATUS    PROGRESS   AGE
rabbitmq-cluster-scale-out-ops   HorizontalScaling   rabbitmq-cluster   Running   0/1        9s
rabbitmq-cluster-scale-out-ops   HorizontalScaling   rabbitmq-cluster   Running   1/1        16s
rabbitmq-cluster-scale-out-ops   HorizontalScaling   rabbitmq-cluster   Succeed   1/1        16s

        Option 2: Direct Cluster API Update

        Alternatively, you can perform a direct update to the replicas field in the Cluster resource:

        apiVersion: apps.kubeblocks.io/v1
kind: Cluster
spec:
  componentSpecs:
    - name: rabbitmq
      replicas: 4 # increase replicas to scale-out
...

        Or you can patch the cluster CR with command:

        kubectl patch cluster rabbitmq-cluster -n demo --type=json -p='[{"op": "replace", "path": "/spec/componentSpecs/0/replicas", "value": 4}]'

        Verify Scale-Out

        After applying the operation, you will see a new pod created and the RabbitMQ cluster status goes from Updating to Running, and the newly created pod has a new role secondary.

        kubectl get pods -n demo -l app.kubernetes.io/instance=rabbitmq-cluster

        Example Output:

        NAME                          READY   STATUS    RESTARTS   AGE
rabbitmq-cluster-rabbitmq-0   2/2     Running   0          6m24s
rabbitmq-cluster-rabbitmq-1   2/2     Running   0          7m19s
rabbitmq-cluster-rabbitmq-2   2/2     Running   0          5m57s
rabbitmq-cluster-rabbitmq-3   2/2     Running   0          3m54s

        Scale-in (Remove Replicas)

        Expected Workflow:

        1. Selected replica (the one with the largest ordinal) is removed
        2. Pod is terminated gracefully
        3. Cluster status changes from Updating to Running

        Option 1: Using Horizontal Scaling OpsRequest

        Scale in the RabbitMQ cluster by removing ONE replica:

        apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: rabbitmq-cluster-scale-in-ops
  namespace: demo
spec:
  clusterName: rabbitmq-cluster
  type: HorizontalScaling
  horizontalScaling:
  - componentName: rabbitmq
    # Specifies the replica changes for scaling in components
    scaleIn:
      # Specifies the replica changes for the component.
      # remove one replica from current component
      replicaChanges: 1

        Monitor progress:

        kubectl get ops rabbitmq-cluster-scale-in-ops -n demo -w

        Expected Result:

        NAME                            TYPE                 CLUSTER          STATUS    PROGRESS   AGE
rabbitmq-cluster-scale-in-ops   HorizontalScaling   rabbitmq-cluster   Running   0/1        8s
rabbitmq-cluster-scale-in-ops   HorizontalScaling   rabbitmq-cluster   Running   1/1        24s
rabbitmq-cluster-scale-in-ops   HorizontalScaling   rabbitmq-cluster   Succeed   1/1        24s

        Option 2: Direct Cluster API Update

        Alternatively, you can perform a direct update to the replicas field in the Cluster resource:

        apiVersion: apps.kubeblocks.io/v1
kind: Cluster
spec:
  componentSpecs:
    - name: rabbitmq
      replicas: 2 # decrease replicas to scale-in

        Or you can patch the cluster CR with command:

        kubectl patch cluster rabbitmq-cluster -n demo --type=json -p='[{"op": "replace", "path": "/spec/componentSpecs/0/replicas", "value": 2}]'

        Verify Scale-In

        Example Output (ONE Pod):

        kubectl get pods -n demo -l app.kubernetes.io/instance=rabbitmq-cluster
NAME                            READY   STATUS   RESTARTS   AGE
rabbitmq-cluster-rabbitmq-0     2/2     Running  0          18m

        Best Practices

        When performing horizontal scaling:

        • Scale during low-traffic periods when possible
        • Monitor cluster health during scaling operations
        • Verify sufficient resources exist before scaling out
        • Consider storage requirements for new replicas

        Cleanup

        To remove all created resources, delete the RabbitMQ cluster along with its namespace:

        kubectl delete cluster rabbitmq-cluster -n demo
kubectl delete ns demo

        Summary

        In this guide you learned how to:

        • Perform scale-out operations to add replicas to a RabbitMQ cluster.
        • Perform scale-in operations to remove replicas from a RabbitMQ cluster.
        • Use both OpsRequest and direct Cluster API updates for horizontal scaling.

        KubeBlocks ensures seamless scaling with minimal disruption to your database operations. with minimal disruption to your database operations.

        © 2025 ApeCloud PTE. Ltd.