Operations
Backup And Restores
Custom Secret
tpl
This guide explains how to perform horizontal scaling (scale-out and scale-in) on a MongoDB cluster managed by KubeBlocks. You'll learn how to use both OpsRequest and direct Cluster API updates to achieve this.
Before proceeding, ensure the following:
kubectl create ns demo
namespace/demo created
KubeBlocks uses a declarative approach for managing MongoDB Replication Clusters. Below is an example configuration for deploying a MongoDB ReplicaSet Cluster with one primary replica and two secondary replicas.
Apply the following YAML configuration to deploy the cluster:
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
name: mongo-cluster
namespace: demo
spec:
terminationPolicy: Delete
clusterDef: mongodb
topology: replicaset
componentSpecs:
- name: mongodb
serviceVersion: "6.0.16"
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
Monitor the cluster status until it transitions to the Running state:
kubectl get cluster mongo-cluster -n demo -w
Expected Output:
kubectl get cluster mongo-cluster -n demo
NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE
mongo-cluster mongodb Delete Creating 49s
mongo-cluster mongodb Delete Running 62s
Check the pod status and roles:
kubectl get pods -l app.kubernetes.io/instance=mongo-cluster -L kubeblocks.io/role -n demo
Expected Output:
NAME READY STATUS RESTARTS AGE ROLE
mongo-cluster-mongodb-0 2/2 Running 0 78s primary
mongo-cluster-mongodb-1 2/2 Running 0 63s secondary
mongo-cluster-mongodb-2 2/2 Running 0 48s secondary
Once the cluster status becomes Running, your MongoDB cluster is ready for use.
If you are creating the cluster for the very first time, it may take some time to pull images before running.
Expected Workflow:
Pending
to Running
with secondary
roleUpdating
to Running
Option 1: Using Horizontal Scaling OpsRequest
Scale out the MongoDB cluster by adding 1 replica to mongodb component:
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: mongo-cluster-scale-out-ops
namespace: demo
spec:
clusterName: mongo-cluster
type: HorizontalScaling
horizontalScaling:
- componentName: mongodb
# 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 mongo-cluster-scale-out-ops -n demo -w
Expected Result:
NAME TYPE CLUSTER STATUS PROGRESS AGE
mongo-cluster-scale-out-ops HorizontalScaling mongo-cluster Running 0/1 9s
mongo-cluster-scale-out-ops HorizontalScaling mongo-cluster Running 1/1 20s
mongo-cluster-scale-out-ops HorizontalScaling mongo-cluster Succeed 1/1 20s
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: mongodb
replicas: 4 # increase replicas to scale-out
...
Or you can patch the cluster CR with command:
kubectl patch cluster mongo-cluster -n demo --type=json -p='[{"op": "replace", "path": "/spec/componentSpecs/0/replicas", "value": 4}]'
After applying the operation, you will see a new pod created and the MongoDB cluster status goes from Updating
to Running
, and the newly created pod has a new role secondary
.
New replicas automatically join as secondary nodes.
kubectl get pods -n demo -l app.kubernetes.io/instance=mongo-cluster -L kubeblocks.io/role
Example Output:
NAME READY STATUS RESTARTS AGE ROLE
mongo-cluster-mongodb-0 2/2 Running 0 6m24s primary
mongo-cluster-mongodb-1 2/2 Running 0 7m19s secondary
mongo-cluster-mongodb-2 2/2 Running 0 5m57s secondary
mongo-cluster-mongodb-3 2/2 Running 0 3m54s secondary
Verify mongodb internal status using:
kubectl exec -it -n demo mongo-cluster-mongodb-0 -- /bin/bash
mongosh "mongodb://${MONGODB_ROOT_USER}:${MONGODB_ROOT_PASSWORD}@127.0.0.1:27017/admin"
rs.status()
# login to mongodb and query
mongo-cluster-mongodb [direct: secondary] admin> rs.status()
Expected Workflow:
Updating
to Running
If the replica being scaled-in happens to be a primary replica, KubeBlocks will trigger a Switchover actions. And this pod will not be terminated until this Switchover action succeeds.
Option 1: Using Horizontal Scaling OpsRequest
Scale in the MongoDB cluster by removing ONE replica:
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: mongo-cluster-scale-in-ops
namespace: demo
spec:
clusterName: mongo-cluster
type: HorizontalScaling
horizontalScaling:
- componentName: mongodb
# 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 mongo-cluster-scale-in-ops -n demo -w
Expected Result:
NAME TYPE CLUSTER STATUS PROGRESS AGE
mongo-cluster-scale-in-ops HorizontalScaling mongo-cluster Running 0/1 8s
mongo-cluster-scale-in-ops HorizontalScaling mongo-cluster Running 1/1 24s
mongo-cluster-scale-in-ops HorizontalScaling mongo-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: mongodb
replicas: 1 # decrease replicas to scale-out
Or you can patch the cluster CR with command:
kubectl patch cluster mongo-cluster -n demo --type=json -p='[{"op": "replace", "path": "/spec/componentSpecs/0/replicas", "value": 1}]'
Example Output (ONE Pod):
kubectl get pods -n demo -l app.kubernetes.io/instance=mongo-cluster,apps.kubeblocks.io/component-name=mongodb
NAME READY STATUS RESTARTS AGE
mongo-cluster-mongodb-0 2/2 Running 0 18m
If the scale-in operation gets stuck for quite a long time, please check these resources:
# Check agent logs on both current primary and candidate
kubectl logs -n demo <primary-pod> -c kbagent
kubectl logs -n demo <candidate-pod> -c kbagent
# Check cluster events for errors
kubectl get events -n demo --field-selector involvedObject.name=pg-cluster
# Check kubeblocks logs
kubectl -n kb-system logs deploy/kubeblocks
If you get errors like the following from the primary replica:
INFO Action Executed {"action": "switchover", "result": "exit code: 1: failed"}
INFO HTTP API Called {"user-agent": "Go-http-client/1.1", "method": "POST", "path": "/v1.0/action", "status code": 200, "cost": 7}
It could be a switchover error, and please check KubeBlocks logs for more details.
When performing horizontal scaling:
To remove all created resources, delete the MongoDB cluster along with its namespace:
kubectl delete cluster mongo-cluster -n demo
kubectl delete ns demo
In this guide you learned how to:
KubeBlocks ensures seamless scaling with minimal disruption to your database operations.