Manage RabbitMQ with KubeBlocks
RabbitMQ is a reliable and mature messaging and streaming broker, which is easy to deploy on cloud environments, on-premises, and on your local machine.
KubeBlocks supports the management of RabbitMQ.
Currently, KubeBlocks only supports managing RabbitMQ by kubectl
.
Before you start
Create a cluster
KubeBlocks implements a Cluster CRD to define a cluster. Here is an example of creating a RabbitMQ cluster with three replicas. Pods are distributed on different nodes by default. But if you only have one node for a cluster with three replicas, set spec.affinity.topologyKeys
as null
.
cat <<EOF | kubectl apply -f -
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
labels:
helm.sh/chart: rabbitmq-cluster-0.9.0
app.kubernetes.io/version: "3.13.2"
app.kubernetes.io/instance: mycluster
spec:
terminationPolicy: Delete
affinity:
podAntiAffinity: Preferred
topologyKeys:
- kubernetes.io/hostname
componentSpecs:
- name: rabbitmq
componentDef: rabbitmq
serviceVersion: 3.13.2
replicas: 3
serviceAccountName: kb-mycluster
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
volumeClaimTemplates:
- name: data # ref clusterDefinition components.containers.volumeMounts.name
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
services:
EOF
Field | Definition |
---|---|
spec.terminationPolicy | It is the policy of cluster termination. The default value is Delete . Valid values are DoNotTerminate , Delete , WipeOut . For the detailed definition, you can refer to Termination Policy. |
spec.affinity | It defines a set of node affinity scheduling rules for the cluster's Pods. This field helps control the placement of Pods on nodes within the cluster. |
spec.affinity.podAntiAffinity | It specifies the anti-affinity level of Pods within a component. It determines how pods should spread across nodes to improve availability and performance. |
spec.affinity.topologyKeys | It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints. |
spec.componentSpecs | It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster. |
spec.componentSpecs.componentDefRef | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with kubectl get clusterdefinition qdrant -o json \| jq '.spec.componentDefs[].name' . |
spec.componentSpecs.name | It specifies the name of the component. |
spec.componentSpecs.disableExporter | It defines whether the monitoring function is enabled. |
spec.componentSpecs.replicas | It specifies the number of replicas of the component. |
spec.componentSpecs.resources | It specifies the resource requirements of the component. |
KubeBlocks operator watches for the Cluster
CRD and creates the cluster and all dependent resources. You can get all the resources created by the cluster with kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo
.
kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo
Run the following command to see the created RabbitMQ cluster object:
kubectl get cluster mycluster -n demo -o yaml
Connect to the cluster
Use the RabbitMQ tools to connect to and manage the RabbitMQ cluster.
Scale
Scale vertically
Before you start, check whether the cluster status is Running
. Otherwise, the following operations may fail.
kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster Delete Running 47m
Option 1. Apply an OpsRequest
Apply an OpsRequest to the specified cluster. Configure the parameters according to your needs.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-vertical-scaling
namespace: demo
spec:
clusterName: mycluster
type: VerticalScaling
verticalScaling:
- componentName: rabbitmq
requests:
memory: "2Gi"
cpu: "1"
limits:
memory: "4Gi"
cpu: "2"
EOFCheck the operation status to validate the vertical scaling.
kubectl get ops -n demo
>
NAME TYPE CLUSTER STATUS PROGRESS AGE
ops-vertical-scaling VerticalScaling mycluster Succeed 3/3 6mIf an error occurs, you can troubleshoot it with
kubectl describe ops -n demo
command to view the events of this operation.Check whether the corresponding resources change.
kubectl describe cluster mycluster -n demo
Option 2. Edit the cluster YAML file
Change the configuration of
spec.componentSpecs.resources
in the YAML file.spec.componentSpecs.resources
controls the requirement and limit of resources and changing them triggers a vertical scaling.apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
componentSpecs:
- name: rabbitmq
componentDefRef: rabbitmq
replicas: 3
resources: # Change the values of resources.
requests:
memory: "2Gi"
cpu: "1"
limits:
memory: "4Gi"
cpu: "2"
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
terminationPolicy: DeleteCheck whether the corresponding resources change.
kubectl describe cluster mycluster -n demo
Scale horizontally
Horizontal scaling changes the amount of pods. For example, you can scale out replicas from three to five.
From v0.9.0, besides replicas, KubeBlocks also supports scaling in and out instances, refer to the Horizontal Scale tutorial for more details and examples.
Before you start, check whether the cluster status is Running
. Otherwise, the following operations may fail.
kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster Delete Running 47m
Option 1. Apply an OpsRequest
Apply an OpsRequest to a specified cluster. Configure the parameters according to your needs.
The example below means deleting two replicas.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-horizontal-scaling
namespace: demo
spec:
clusterName: mycluster
type: HorizontalScaling
horizontalScaling:
- componentName: rabbitmq
scaleIn:
replicaChanges: 2
EOFIf you want to scale in replicas, replace
scaleOut
withscaleIn
and change the value inreplicaChanges
.Check the operation status to validate the horizontal scaling status.
kubectl get ops -n demo
>
NAME TYPE CLUSTER STATUS PROGRESS AGE
ops-horizontal-scaling HorizontalScaling mycluster Succeed 2/2 6mIf an error occurs, you can troubleshoot it with
kubectl describe ops -n demo
command to view the events of this operation.Check whether the corresponding resources change.
kubectl describe cluster mycluster -n demo
Option 2. Edit the cluster YAML file
Change the configuration of
spec.componentSpecs.replicas
in the YAML file.spec.componentSpecs.replicas
stands for the pod amount and changing this value triggers a horizontal scaling of a cluster.kubectl edit cluster mycluster -n demo
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
componentSpecs:
- name: rabbitmq
componentDefRef: rabbitmq
replicas: 1 # Change the amount
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
terminationPolicy: DeleteCheck whether the corresponding resources change.
kubectl describe cluster mycluster -n demo
Volume expansion
Before you start, check whether the cluster status is Running
. Otherwise, the following operations may fail.
kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster Delete Running 47m
Option 1. Apply an OpsRequest
Change the value of storage according to your need and run the command below to expand the volume of a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-volume-expansion
namespace: demo
spec:
clusterName: mycluster
type: VolumeExpansion
volumeExpansion:
- componentName: rabbitmq
volumeClaimTemplates:
- name: data
storage: "40Gi"
EOFValidate the volume expansion operation.
kubectl get ops -n demo
>
NAME TYPE CLUSTER STATUS PROGRESS AGE
ops-volume-expansion VolumeExpansion mycluster Succeed 1/1 6mIf an error occurs, you can troubleshoot it with
kubectl describe ops -n demo
command to view the events of this operation.Check whether the corresponding cluster resources change.
kubectl describe cluster mycluster -n demo
Option 2. Edit the cluster YAML file
Change the value of
spec.componentSpecs.volumeClaimTemplates.spec.resources
in the cluster YAML file.spec.componentSpecs.volumeClaimTemplates.spec.resources
is the storage resource information of the pod and changing this value triggers the volume expansion of a cluster.kubectl edit cluster mycluster -n demo
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
componentSpecs:
- name: rabbitmq
componentDefRef: rabbitmq
replicas: 2
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 40Gi # Change the volume storage size.
terminationPolicy: DeleteCheck whether the corresponding cluster resources change.
kubectl describe cluster mycluster -n demo
Restart
Restart a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: mycluster-restart
namespace: demo
spec:
clusterName: mycluster
type: Restart
restart:
- componentName: rabbitmq
EOFCheck the pod and operation status to validate the restarting.
kubectl get pod -n demo
kubectl get ops -n demoDuring the restarting process, there are two status types for pods.
- STATUS=Terminating: it means the cluster restart is in progress.
- STATUS=Running: it means the cluster has been restarted.
Stop/Start a cluster
You can stop/start a cluster to save computing resources. When a cluster is stopped, the computing resources of this cluster are released, which means the pods of Kubernetes are released, but the storage resources are reserved. You can start this cluster again by snapshots if you want to restore the cluster resources.
Stop a cluster
Option 1. Apply an OpsRequest
Run the command below to stop a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: mycluster-stop
namespace: demo
spec:
clusterName: mycluster
type: Stop
EOF
Option 2. Edit the cluster YAML file
Configure replicas
as 0 to delete pods.
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
labels:
helm.sh/chart: rabbitmq-cluster-0.9.0
app.kubernetes.io/version: "3.13.2"
app.kubernetes.io/instance: mycluster
spec:
terminationPolicy: Delete
affinity:
podAntiAffinity: Preferred
topologyKeys:
- kubernetes.io/hostname
componentSpecs:
- name: rabbitmq
componentDef: rabbitmq
serviceVersion: 3.13.2
replicas: 0
serviceAccountName: kb-mycluster
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
volumeClaimTemplates:
- name: data # ref clusterDefinition components.containers.volumeMounts.name
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
services:
Start a cluster
Option 1. Apply an OpsRequest
Run the command below to start a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: mycluster-start
namespace: demo
spec:
clusterName: mycluster
type: Start
EOF
Option 2. Edit the cluster YAML file
Change replicas back to the original amount to start this cluster again.
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
labels:
helm.sh/chart: rabbitmq-cluster-0.9.0
app.kubernetes.io/version: "3.13.2"
app.kubernetes.io/instance: mycluster
spec:
terminationPolicy: Delete
affinity:
podAntiAffinity: Preferred
topologyKeys:
- kubernetes.io/hostname
componentSpecs:
- name: rabbitmq
componentDef: rabbitmq
serviceVersion: 3.13.2
replicas: 3
serviceAccountName: kb-mycluster
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
volumeClaimTemplates:
- name: data # ref clusterDefinition components.containers.volumeMounts.name
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
services:
Delete a cluster
Termination policy
The termination policy determines how a cluster is deleted.
terminationPolicy | Deleting Operation |
---|---|
DoNotTerminate | DoNotTerminate blocks delete operation. |
Halt | Halt deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations. Halt policy is deprecated in v0.9.1 and will have same meaning as DoNotTerminate. |
Delete | Delete extends the Halt policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data. |
WipeOut | WipeOut deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, especially in non-production environments, to avoid irreversible data loss. |
To check the termination policy, execute the following command.
kbcli cluster list mycluster -n demo
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
mycluster demo Delete Running Sep 30,2024 13:03 UTC+0800
kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster Delete Running 55m
Steps
Run the command below to delete a specified cluster.
kbcli cluster delete mycluster -n demo
If you want to delete a cluster and its all related resources, you can modify the termination policy to WipeOut
, then delete the cluster.
kubectl patch -n demo cluster mycluster -p '{"spec":{"terminationPolicy":"WipeOut"}}' --type="merge"
kubectl delete -n demo cluster mycluster
Monitor
The monitoring function of RabbitMQ is the same as other engines. For details, refer to related docs: