Operations
Backup And Restores
Custom Secret
tpl
This guide demonstrates how to vertically scale a MongoDB ReplicaSet Cluster managed by KubeBlocks by adjusting compute resources (CPU and memory) while maintaining the same number of replicas.
Vertical scaling modifies compute resources (CPU and memory) for MongoDB instances while maintaining replica count. Key characteristics:
KubeBlocks orchestrates scaling with minimal impact:
Updating
to Running
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:
Updating
to Running
Option 1: Using VerticalScaling OpsRequest
Apply the following YAML to scale up the resources for the mongodb component:
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: mongo-cluster-vscale-ops
namespace: demo
spec:
clusterName: mongo-cluster
type: VerticalScaling
verticalScaling:
- componentName: mongodb
requests:
cpu: '1'
memory: 1Gi
limits:
cpu: '1'
memory: 1Gi
What Happens During Vertical Scaling?
You can check the progress of the scaling operation with the following command:
kubectl -n demo get ops mongo-cluster-vscale-ops -w
Expected Result:
NAME TYPE CLUSTER STATUS PROGRESS AGE
mongo-cluster-vscale-ops VerticalScaling mongo-cluster Running 0/3 32s
mongo-cluster-vscale-ops VerticalScaling mongo-cluster Running 1/3 55s
mongo-cluster-vscale-ops VerticalScaling mongo-cluster Running 2/3 82s
mongo-cluster-vscale-ops VerticalScaling mongo-cluster Running 3/3 2m13s
Option 2: Direct Cluster API Update
Alternatively, you may update spec.componentSpecs.resources
field to the desired resources for vertical scale.
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
spec:
componentSpecs:
- name: mongodb
replicas: 3
resources:
requests:
cpu: "1" # Update the resources to your need.
memory: "1Gi" # Update the resources to your need.
limits:
cpu: "1" # Update the resources to your need.
memory: "1Gi" # Update the resources to your need.
...
Planning:
Execution:
Post-Scaling:
Verify the updated resources by inspecting the cluster configuration or Pod details:
kbcli cluster describe mongo-cluster -n demo
Expected Output:
Resources Allocation:
COMPONENT INSTANCE-TEMPLATE CPU(REQUEST/LIMIT) MEMORY(REQUEST/LIMIT) STORAGE-SIZE STORAGE-CLASS
mongodb 1 / 1 1Gi / 1Gi data:20Gi <none>
To remove all created resources, delete the MongoDB ReplicaSet Cluster along with its namespace:
kubectl delete cluster mongo-cluster -n demo
kubectl delete ns demo
In this guide, you learned how to:
Vertical scaling is a powerful tool for optimizing resource utilization and adapting to changing workload demands, ensuring your MongoDB ReplicaSet Cluster remains performant and resilient.