Deploy a Sharded Cluster

Sharded clusters provide horizontal scaling for large data sets and enable high throughput operations by distributing the data set across a group of servers.

To learn more about sharding, see Sharding Introduction in the MongoDB manual.

Use this procedure to deploy a new sharded cluster that Ops Manager manages. Later, you can use Ops Manager to add shards and perform other maintenance operations on the cluster.

Added in Ops Manager 4.0

You can use Kubernetes to deploy MongoDB instances with Ops Manager version 4.0 or later.


To deploy a standalone using a object, you need to meet the prerequisites for, and complete the procedures on, the Install Kubernetes Operator page.


Unique Names for Sharded Clusters

Use unique names for the new cluster and its shards.


Replica set, sharded cluster, and shard names within the same project must be unique. Failure to have unique names for the deployments will result in broken backup snapshots.

Do Not Deploy Monitoring Agents inside and outside Kubernetes

Do not mix MongoDB deployments outside Kubernetes with ones insider Kubernetes in the same Project.

Due to Kubernetes network translation, a Monitoring Agent outside Kubernetes cannot monitor MongoDB instnaces inside Kubernetes. For this reason, k8s and non-k8s deployments in the same Project is not supported. Use separate projects.



Copy the following example sharded cluster Kubernetes object specification.

This is a YAML file that you can modify to meet your desired configuration. Change the highlighted settings to match your desired sharded cluster configuration.

kind: MongoDB
  name: <myshardedcluster>
  namespace: <metadata.namespace> # Should match metadata.namespace in
                                  # your configmap file.
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: 4.0.6
  project: <myconfigmap> # Should match in your
                         # configmap file.
  credentials: <mycredentials>
  type: ShardedCluster
  persistent: true

Open your preferred text editor and paste the object specification into a new text file.


Configure the settings highlighted in the preceeding step as follows.

Key Type Description Example string

Label for this Kubernetes sharded cluster object.

See also

metadata.namespace string

Scope of object names. Kubernetes namespace where this MongoDB Kubernetes resource and other objects are created.

Using two different namespaces allows you to delete your sharded cluster or all of the resources in the namespace without affecting your Kubernetes Operator.

See also

spec.shardCount integer Number of shards to deploy. 2
spec.mongodsPerShardCount integer Number of shard members per shard. 3
spec.mongosCount integer Number of shard routers to deploy. 2
spec.configServerCount integer Number of members of the config server replica set. 3
spec.version string

Version of MongoDB that this sharded cluster should run.

The format should be X.Y.Z for the Community edition and X.Y.Z-ent for the Enterprise edition.

To learn more about MongoDB versioning, see MongoDB Version Numbers in the MongoDB Manual.

spec.project string

Name of the ConfigMap with the Ops Manager connection configuration.

Value must match namespace and name of ConfigMap

This value must match the value you provided for in your Ops Manager project ConfigMap.

If this MongoDB Kubernetes resource is in a different namespace than the project ConfigMap, you should set this value to the namespace and name of the ConfigMap in this format: <namespace>/<myconfigmap>

Operator manages changes to the ConfigMap

The Kubernetes Operator tracks any changes to the ConfigMap and reconciles the state of the MongoDB Kubernetes resource.

<myproject> or <namespace>/<myconfigmap>
spec.credentials string

Name of the Kubernetes secret you created as Ops Manager API authentication credentials for the Kubernetes Operator to communicate with Ops Manager.

Value must use namespace and name of Secret

This value must match the value you provided for namespace and name for your Ops Manager Kubernetes Secret.

If this object is in a different namespace than the Secret, you should set this value to the namespace and name of the Secret in this format: <namespace>/<name>

Operator manages changes to the Secret

The Kubernetes Operator tracks any changes to the Secret and reconciles the state of the MongoDB Kubernetes resource.

<mycredentials> or <namespace>/<mycredentials>
spec.type string Type of MongoDB Kubernetes resource to create. ShardedCluster
spec.persistent string


Flag indicating if this MongoDB Kubernetes resource should use Persistent Volumes for storage. Persistent volumes are not deleted when the MongoDB Kubernetes resource is stopped or restarted.

If this value is true, then the following values are set to their default value of 16G:

To change your Persistent Volume Claims configuration, configure the following collections to meet your deployment requirements:


Your containers must have permissions to write to your Persistent Volume. The Kubernetes Operator sets fsGroup = 2000 in securityContext This makes Kubernetes try to fix write permissions for the Persistent Volume. If redeploying the deployment item does not fix issues with your Persistent Volumes, contact MongoDB support.


If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment.


Save this file with a .yaml file extension.


Start your sharded cluster deployment.

Invoke the following Kubernetes command to create your sharded cluster:

kubectl apply -f <sharded-cluster-conf>.yaml

Check the log after running this command. If the creation was successful, you should see a message similar to the following:

2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}

Track the status of your sharded cluster deployment.

To check the status of your MongoDB Kubernetes resource, invoke the following command:

kubectl get mdb <resource-name> -n <namespace> -o yaml -w

The -w flag means “watch”. With the “watch” flag set, the output refreshes immediately when something changes until the status phase achieves the Running state.

If the deployment fails, see Troubleshooting the Kubernetes Operator.

To troubleshoot your sharded cluster, see: