Docs Menu

Docs HomeMongoDB Enterprise Kubernetes Operator

Deploy Replica Sets in a Multi-Kubernetes Cluster without a Service Mesh

On this page

  • Before You Begin
  • Overview
  • Deploy a MongoDBMultiCluster Resource without a Service Mesh

Use this procedure to deploy a replica set in a multi-Kubernetes-cluster deployment without using a service mesh for establishing external connectivity between member Kubernetes clusters.

As an alternative to using this procedure, you can use the Multi-Kubernetes-Cluster Quick Start, which uses a service mesh.

In a multi-Kubernetes-cluster deployment without a service mesh, use the following MongoDBMultiCluster resource settings:

The following procedure establishes TLS-encrypted connections between MongoDB hosts in a replica set, and between client applications and MongoDB deployments.


Run the kubectl command to create a new secret that stores the MongoDBMultiCluster resource certificate:

kubectl --context $MDB_CENTRAL_CLUSTER_FULL_NAME \
--namespace=<metadata.namespace> \
create secret tls <prefix>-<>-cert \
--cert=<resource-tls-cert> \


You must prefix your secrets with <prefix>-<>.


If you call your deployment my-deployment and you set the prefix to mdb, you must name the TLS secret for the client TLS communications mdb-my-deployment-cert. Also, you must name the TLS secret for internal cluster authentication (if enabled) mdb-my-deployment-clusterfile.


Run the kubectl command to link your CA to your MongoDBMultiCluster resource. Specify the CA certificate file that you must always name ca-pem for the MongoDBMultiCluster resource:

kubectl --context $MDB_CENTRAL_CLUSTER_FULL_NAME \
--namespace=<metadata.namespace> \
create configmap custom-ca -from-file=ca-pem=<your-custom-ca-file>

If you have not done so already, run the following commands to run all kubectl commands on the central cluster in the default namespace.

kubectl config use-context $MDB_CENTRAL_CLUSTER_FULL_NAME
kubectl config set-context $(kubectl config current-context) \
  1. Copy the sample replica set YAML file and paste it into a new text file.

  2. Change the file's settings to match your desired replica set configuration.

1# Provides statefulSet override per cluster
4kind: MongoDBMultiCluster
6 name: multi-replica-set
8 version: 4.4.0-ent
9 type: ReplicaSet
10 credentials: my-credentials
11 opsManager:
12 configMapRef:
13 name: my-project
14 externalAccess:
15 externalService:
16 annotations:
17 # Global cloud-specific annotations added to external services in all clusters
18 spec:
19 # ServiceSpec attributes to override in external services in all clusters
20 clusterSpecList:
21 - clusterName:
22 members: 2
23 externalAccess:
24 # Domain suffix that mongod processes will use in cluster1
25 externalDomain:
26 externalService:
27 annotations:
28 # Cloud-specific annotations for external services
29 spec:
30 # ServiceSpec attributes to override if necessary
31 - clusterName:
32 members: 1
33 externalAccess:
34 # Domain suffix that mongod processes will use in cluster2
35 externalDomain:
36 externalService:
37 annotations:
38 # Cloud-specific annotations for external services
39 spec:
40 # ServiceSpec attributes to override if necessary
41 - clusterName:
42 members: 1
43 externalAccess:
44 # Domain suffix that mongod processes will use in cluster3
45 externalDomain:
46 externalService:
47 annotations:
48 # Cloud-specific annotations for external services
49 spec:
50 # ServiceSpec attributes to override if necessary

Specify global values that affect all clusters in a multi-Kubernetes-cluster deployment using the spec.externalAccess settings and cluster-specific overrides using the spec.clusterSpecList.externalAccess.externalService settings.

When you provide these settings in the MongoDBMultiCluster resource specification, the Kubernetes Operator creates external services for each Pod in all Kubernetes clusters. You then use these services to establish external connectivity to all mongod processes in your deployment.


Define an external domain for each member cluster using the spec.clusterSpecList.externalAccess.externalDomain setting.

As a result, the Kubernetes Operator registers all mongod processes in the Kubernetes member cluster under a hostname according to the following convention:


For example, a mongod process may have the following hostname:


Label for the MongoDBMultiCluster resource.

Resource names must be 44 characters or less.

See also and names in the Kubernetes documentation.


Version of MongoDB that this MongoDBMultiCluster resource 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.


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 resource.

Name of the cluster in the MongoDBMultiCluster resource.
The number of members in this cluster.


Provides the configuration for the StatefulSet override for each of the cluster's StatefulSets in a multi-Kubernetes-cluster deployment. If specified at an individual cluster level under clusterSpecList, overrides the global configuration for the StatefulSet for the entire multi-Kubernetes-cluster deployment. See Multi-Kubernetes-Cluster Resource Specification and StatefulSet v1 apps Kubernetes documentation.

See the example.
Optional. If specified, provides a per-cluster override for the default storage size of the volumeClaimtemplates, for the persistent volume that stores the data.
See the example.

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 resource.

Type of MongoDB resource to create. The only supported value for this field is ReplicaSet. See Limitations.

You can also add any optional settings to the object specification. See Multi-Kubernetes-Cluster Resource Specification.


In any directory, invoke the following Kubernetes command to create your replica set:

kubectl apply -f <replica-set-conf>.yaml
  1. Check the status of external services in all member clusters:

    kubectl get services

    Kubernetes should return one external service created for each Pod of the replica set in all member clusters.

  2. Verify that each external service is exposed externally and is reachable. Run the command similar to the following example:

    mongosh mongodb:// \
    -tls -tlsCAFile "issuer-ca.pem"

    Connecting to should direct client traffic to an external service named my-replica-set-0-0-svc-external, which, in turn, directs traffic to the mongod process.

  3. Configure your DNS zone for the specified external domain to point to the corresponding external services. This configuration depends on your environment or the cloud provider you are using.


To check the status of your MongoDBMultiCluster resource, use the following command on the central cluster:

kubectl get mdbmc <resource-name> -o yaml -w

With the -w (watch) flag set, when the configuration changes, the output refreshes immediately until the status phase achieves the Running state. To learn more about resource deployment statuses, see Troubleshoot the Kubernetes Operator.

←  Deploy Replica Sets in a Multi-Kubernetes ClusterEdit a MongoDBMultiCluster Resource →