MongoDB ReplicaSet Cluster Lifecycle Management

This guide demonstrates how to manage a MongoDB ReplicaSet Cluster's operational state in KubeBlocks, including:

• Stopping the cluster to conserve resources
• Starting a stopped cluster
• Restarting cluster components

These operations help optimize resource usage and reduce operational costs in Kubernetes environments.

Lifecycle management operations in KubeBlocks:

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 MongoDB ReplicaSet Cluster

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

Verifying the Deployment

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.

Cluster Lifecycle Operations

Stopping the Cluster

Stopping a MongoDB ReplicaSet Cluster in KubeBlocks will:

1. Terminates all running pods
2. Retains persistent storage (PVCs)
3. Maintains cluster configuration

This operation is ideal for:

• Temporary cost savings
• Maintenance windows
• Development environment pauses

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: mongo-cluster-stop-ops
  namespace: demo
spec:
  clusterName: mongo-cluster
  type: Stop

kubectl patch cluster mongo-cluster -n demo --type='json' -p='[
{
  "op": "add",
  "path": "/spec/componentSpecs/0/stop",
  "value": true
}
]'

Verifying Cluster Stop

To confirm a successful stop operation:

1. Check cluster status transition:

   kubectl get cluster mongo-cluster -n demo -w
   

   Example Output:

   NAME            CLUSTER-DEFINITION   TERMINATION-POLICY   STATUS     AGE
   mongo-cluster   mongodb              Delete               Stopping   6m3s
   mongo-cluster   mongodb              Delete               Stopped    6m55s
   
   

2. Verify no running pods:

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

   Example Output:

   No resources found in demo namespace.
   

3. Confirm persistent volumes remain:

   kubectl get pvc -l app.kubernetes.io/instance=mongo-cluster -n demo
   

   Example Output:

   NAME                           STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS         VOLUMEATTRIBUTESCLASS   AGE
   data-mongo-cluster-mongodb-0   Bound    pvc-uuid   20Gi       RWO            <STORAGECLASS>       <unset>                 22m
   data-mongo-cluster-mongodb-1   Bound    pvc-uuid   20Gi       RWO            <STORAGECLASS>       <unset>                 21m
   data-mongo-cluster-mongodb-2   Bound    pvc-uuid   20Gi       RWO            <STORAGECLASS>       <unset>                 21m
   

Starting the Cluster

Starting a stopped MongoDB ReplicaSet Cluster:

1. Recreates all pods
2. Reattaches persistent storage
3. Restores service endpoints

Expected behavior:

• Cluster returns to previous state
• No data loss occurs
• Services resume automatically

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: mongo-cluster-start-ops
  namespace: demo
spec:
  # Specifies the name of the Cluster resource that this operation is targeting.
  clusterName: mongo-cluster
  type: Start

kubectl patch cluster mongo-cluster -n demo --type='json' -p='[
{
  "op": "remove",
  "path": "/spec/componentSpecs/0/stop"
}
]'

Verifying Cluster Start

To confirm a successful start operation:

1. Check cluster status transition:

   kubectl get cluster mongo-cluster -n demo -w
   

   Example Output:

   NAME            CLUSTER-DEFINITION   TERMINATION-POLICY   STATUS     AGE
   mongo-cluster   mongodb              Delete               Updating   24m
   mongo-cluster   mongodb              Delete               Running    24m
   mongo-cluster   mongodb              Delete               Running    24m
   

2. Verify pod recreation:

   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          55s   primary
   mongo-cluster-mongodb-1   2/2     Running   0          44s   secondary
   mongo-cluster-mongodb-2   2/2     Running   0          33s   secondary
   

Restarting Cluster

Restart operations provide:

• Pod recreation without full cluster stop
• Component-level granularity
• Minimal service disruption

Use cases:

• Configuration changes requiring restart
• Resource refresh
• Troubleshooting

Using OpsRequest API

Target specific components mongodb for restart:

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: mongo-cluster-restart-ops
  namespace: demo
spec:
  clusterName: mongo-cluster
  type: Restart
  restart:
  - componentName: mongodb

Verifying Restart Completion

To verify a successful component restart:

1. Track OpsRequest progress:

   kubectl get opsrequest mongo-cluster-restart-ops -n demo -w
   

   Example Output:

   NAME                        TYPE      CLUSTER         STATUS    PROGRESS   AGE
   mongo-cluster-restart-ops   Restart   mongo-cluster   Running   0/3        4s
   mongo-cluster-restart-ops   Restart   mongo-cluster   Running   1/3        28s
   mongo-cluster-restart-ops   Restart   mongo-cluster   Running   2/3        56s
   mongo-cluster-restart-ops   Restart   mongo-cluster   Running   2/3        109s
   

2. Check pod status:

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

   Note: Pods will show new creation timestamps after restart

3. Verify component health:

   kbcli cluster describe mongo-cluster -n demo
   

Once the operation is complete, the cluster will return to the Running state.

Summary

In this guide, you learned how to:

1. Stop a MongoDB ReplicaSet Cluster to suspend operations while retaining persistent storage.
2. Start a stopped cluster to bring it back online.
3. Restart specific cluster components to recreate their Pods without stopping the entire cluster.

By managing the lifecycle of your MongoDB ReplicaSet Cluster, you can optimize resource utilization, reduce costs, and maintain flexibility in your Kubernetes environment. KubeBlocks provides a seamless way to perform these operations, ensuring high availability and minimal disruption.