- Deploy and Configure MongoDB Database Resources >
- Deploy a MongoDB Database Resource >
- Deploy a Sharded Cluster
Deploy a Sharded Cluster¶
On this page
Note
At any place on this page that says Ops Manager, you can substitute Cloud Manager.
Important
- You can use the Kubernetes Operator to deploy MongoDB resources with Ops Manager version 4.0.11 or later and Cloud Manager.
- You can’t use the Kubernetes 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.
Prerequisites¶
To deploy a sharded cluster using an object, you need to complete the following procedures:
Considerations¶
Starting in MongoDB Enterprise Kubernetes Operator version 1.3.0, you can only have one MongoDB resource per project. To learn how to migrate your project to a single-cluster configuration, see Migrate to One Resource per Project (Required for Version 1.3.0).
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 instances inside Kubernetes. For this reason, k8s and non-k8s deployments in the same Project is not supported. Use separate projects.
Procedure¶
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:
Copy the highlighted section of this sharded cluster resource.¶
Change the highlighted 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 highlighted settings to match your desired sharded cluster configuration.
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 |
---|---|---|---|
metadata.name |
string | Label for this Kubernetes sharded cluster object. Resource names must be 44 characters or less. See also
|
myproject |
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 To learn more about MongoDB versioning, see MongoDB Versioning in the MongoDB Manual. |
4.2.2-ent |
spec.opsManager.configMapRef.name |
string | Name of the ConfigMap with the Ops Manager connection
configuration. The
Value must match namespace and name of ConfigMap This value must match the namespace in which you created the Ops Manager project ConfigMap. 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> |
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 namespace in which you created the
secret and the 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> |
spec.type |
string | Type of MongoDB Kubernetes resource to create. | ShardedCluster |
spec.persistent |
string | Optional. 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 To change your Persistent Volume Claims configuration, configure the following collections to meet your deployment requirements:
Warning Your containers must have permissions to write to your Persistent Volume.
The Kubernetes Operator sets Note 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. |
true |
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:
spec.clusterDomain
spec.exposedExternally
spec.logLevel
spec.featureCompatibilityVersion
spec.connectivity.replicaSetHorizons
Warning
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
spec.configSrvPodSpec.cpu
spec.configSrvPodSpec.cpuRequests
spec.configSrvPodSpec.memory
spec.configSrvPodSpec.memoryRequests
spec.configSrvPodSpec.persistence.single
spec.configSrvPodSpec.persistence.multiple.data
spec.configSrvPodSpec.persistence.multiple.journal
spec.configSrvPodSpec.persistence.multiple.logs
spec.configSrvPodSpec.nodeAffinity
spec.configSrvPodSpec.podAffinity
spec.configSrvPodSpec.podAntiAffinityTopologyKey
spec.configSrvPodSpec.podTemplate.metadata
spec.configSrvPodSpec.podTemplate.spec
For shard routers
spec.mongosPodSpec.cpu
spec.mongosPodSpec.cpuRequests
spec.mongosPodSpec.memory
spec.mongosPodSpec.memoryRequests
spec.mongosPodSpec.nodeAffinity
spec.mongosPodSpec.podAffinity
spec.mongosPodSpec.podAntiAffinityTopologyKey
spec.mongosPodSpec.podTemplate.metadata
spec.mongosPodSpec.podTemplate.spec
For shard members
spec.shardPodSpec.cpu
spec.shardPodSpec.cpuRequests
spec.shardPodSpec.memory
spec.shardPodSpec.memoryRequests
spec.shardPodSpec.nodeAffinity
spec.shardPodSpec.persistence.single
spec.shardPodSpec.persistence.multiple.data
spec.shardPodSpec.persistence.multiple.journal
spec.shardPodSpec.persistence.multiple.logs
spec.shardPodSpec.podAffinity
spec.shardPodSpec.podAntiAffinityTopologyKey
spec.shardPodSpec.podTemplate.metadata
spec.shardPodSpec.podTemplate.spec
Save this file with a .yaml
file extension.¶
Start your sharded cluster deployment.¶
Invoke the following Kubernetes command to create your sharded cluster:
Check the log after running this command. If the creation was successful, you should see a message similar to the following:
Track the status of your sharded cluster deployment.¶
To check the status of your MongoDB Kubernetes resource, invoke the following command:
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.
See Troubleshooting the Kubernetes Operator for information about the resource deployment statuses.