Deploy a Sharded Cluster


At any place on this page that says Ops Manager, you can substitute Cloud Manager.


  • You can use the Kubernetes Operator to deploy MongoDB resources with Cloud Manager and with Ops Manager version 4.4.x or later.
  • You can use the Atlas Operator to deploy MongoDB resources to Atlas.

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.


To deploy a sharded cluster using an object, you need to complete the following procedures:

Alternatively, for MongoDB Cloud Manager, after installing the Kubernetes Operator, you can use the Cloud Manager UI to automatically generate the ConfigMap and Kubernetes secret YAML files, which you can then apply to your Kubernetes environment.


To avoid storing secrets in Kubernetes, you can migrate all secrets to a secret storage tool.


Starting in Kubernetes Operator version 1.11.0, you must migrate all deployed MongoDBOpsManager custom resources to a specified MongoDB version.

Do Not Deploy Monitoring Agents inside and outside Kubernetes

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

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


The procedure for deploying a sharded cluster depends on whether you require the deployment to run with TLS enabled for intra-cluster communication and clients connecting to the database:


Configure kubectl to default to your namespace.

If you have not already, run the following command to execute all kubectl commands in the namespace you created:

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>

Copy the sample sharded cluster resource.

Change the settings of this YAML file to match your desired sharded cluster configuration.

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

kind: MongoDB
  name: <my-sharded-cluster>
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: "4.2.2-ent"
      name: <>
            # Must match in ConfigMap file
  credentials: <mycredentials>
  type: ShardedCluster
  persistent: true

Paste the copied example to create a new sharded cluster resource.

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


Configure the settings highlighted in the preceding step as follows.

Key Type Description Example string

Label for this Kubernetes sharded cluster object.

Resource names must be 44 characters or less.

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.


Ensure that you choose a compatible MongoDB Server version.

Compatible versions differ depending on the base image that the MongoDB database resource uses.

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

For best results, use the latest available enterprise MongoDB version that is compatible with your Ops Manager version. string

Name of the ConfigMap with the Ops Manager connection configuration. The setting is an alias for this setting and can be used in its place.


This value must exist on the same namespace as the resource you want to create.

Operator manages changes to the ConfigMap

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

spec.credentials string

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

The Ops Manager Kubernetes Secret object holding the Credentials must exist on the same Namespace as the resource you want to create.

Operator manages changes to the Secret

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

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 16Gi:

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


Grant your containers permission to write to your Persistent Volume. The Kubernetes Operator sets fsGroup = 2000, runAsUser = 2000, and runAsNonRoot = true in securityContext. Kubernetes Operator sets fsgroup equal to runAsUser to make the volume writable for a user that runs the main process in the container. To learn more, see Configure a Security Context for a Pod or Container and the related discussion in the Kubernetes documentation. If redeploying the resource doesn’t fix issues with your Persistent Volume, 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.


Add any additional accepted settings for a sharded cluster deployment.

You can also add any of the following optional settings to the object specification file for a sharded cluster deployment:


You must set spec.clusterDomain if your Kubernetes cluster has a default domain other than the default cluster.local. If you neither use the default nor set the spec.clusterDomain option, the Kubernetes Operator might not function as expected.

For config server

For shard routers

For shard members


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> -o yaml -w

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

See Troubleshoot the Kubernetes Operator for information about the resource deployment statuses.