Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes Operator
/

Architecture, Capabilities, and Limitations

On this page

  • Limitations
  • Multi-Cluster Deployment Capabilities
  • Connect with DNS SRV Records
  • Manage Security for Database Users
  • Set up Queryable Backups for Single-Cluster Ops Manager Resources
  • Deployment Architecture and Diagrams
  • Diagram: Multi-Kubernetes Cluster Deployment with a Service Mesh
  • Diagram: Multi-Kubernetes Cluster Deployment without a Service Mesh

The following limitations exist for multi-Kubernetes cluster MongoDB deployments:

  • Deploy only replica sets of MongoDBMultiCluster resources. Sharded cluster deployments aren't supported.

  • Use Ops Manager versions later than 5.0.7.

  • Use only Kubernetes secrets for your secret storage tool. The HashiCorp Vault secret storage tool isn't supported.

  • For deployments where the same Kubernetes Operator instance is not managing both the MongoDBOpsManager and MongoDB custom resources, you must manually configure KMIP backup encryption client settings in Ops Manager. To learn more, see Manually Configure KMIP Backup Encryption.

  • Don't add a ServiceMonitor to your MongoDBMultiCluster resources. The Kubernetes Operator doesn't support integration with Prometheus.

  • You can create a new multi-Kubernetes cluster MongoDB deployment and contact MongoDB Support to help you migrate data from your existing Kubernetes deployment to a multi-Kubernetes cluster MongoDB deployment. You can't extend an existing single-Kubernetes cluster deployment to new Kubernetes clusters.

This section describes the multi-Kubernetes cluster MongoDB deployment capabilities that you can configure using the same procedures as the procedures for single clusters of MongoDB resources deployed with the Kubernetes Operator. Other multi-Kubernetes cluster MongoDB deployment capabilities have their own documentation in this guide.

To connect to the multi-Kubernetes cluster MongoDB deployment database as a user, you can use the connectionString.standardSrv: DNS seed list connection string. This string is included in the secret that the Kubernetes Operator creates for your multi-Kubernetes cluster MongoDB deployment. Use the same procedure for connecting to the multi-Kubernetes cluster MongoDB deployment as for single clusters deployed with Kubernetes Operator. See Connect to a MongoDB Database Resource from Inside Kubernetes and select the tab Using the Kubernetes Secret.

Use these methods to manage security for database users:

These procedures are the same as the procedures for single clusters deployed with the Kubernetes Operator, with the following exceptions:

  • The procedures apply to replica sets only. Multi-Kubernetes cluster MongoBB deployments don't support creating sharded clusters.

  • In the mongodbResourceRef, specify the name of the multi-Kubernetes cluster MongoDB deployment replica set: name: "<my-multi-cluster-replica-set>".

If you deploy an Ops Manager instance on a single Kubernetes cluster with the Kubernetes Operator, the operator-hosting cluster may also host Ops Manager. In this case, you can configure queryable backups for Ops Manager resources. Queryable backups aren't supported in deployments of Ops Manager resources on multiple Kubernetes clusters.

You can create multi-Kubernetes cluster MongoDB deployments with or without relying on a service mesh. To learn more, see Plan for External Connectivity: Should You Use a Service Mesh?

In both the following diagrams, the MongoDB Enterprise Kubernetes Operator performs these actions:

  • Watches for the MongoDBMultiCluster resource spec creation in the central cluster.

  • Uses the mounted kubeconfig file to communicate with member clusters.

  • Creates the necessary resources, such as ConfigMaps, Secrets, Services and StatefulSet Kubernetes objects in each member cluster corresponding to the number of replica set members in the MongoDB cluster.

  • Identifies the cluster for deploying each MongoDB replica set using the corresponding MongoDBMultiCluster resource spec, and deploys the MongoDB replica sets.

  • Watches for the CentralCluster and MemberCluster events.

  • Reconciles the resources it created to confirm that the multi-Kubernetes cluster MongoDB deployment is in the desired state.

A multi-Kubernetes cluster MongoDB deployment that uses the MongoDB Enterprise Kubernetes Operator consists of one central cluster and one or more member clusters in Kubernetes:

  • The central cluster has the following role:

    • Hosts the MongoDB Enterprise Kubernetes Operator

    • Acts as the control plane for the multi-Kubernetes cluster MongoDB deployment

    • Hosts the MongoDBMultiCluster resource spec for the MongoDB replica set

    • Hosts Ops Manager, if you deploy Ops Manager with the Kubernetes Operator

    • Can also host members of the MongoDB replica set

    Important

    The central cluster is also known as the operator cluster. References to the central cluster might be renamed to refer to the operator cluster in the future releases.

  • Member clusters host the MongoDB replica sets.

Note that if the central cluster (also known as the operator cluster) fails, you can't use the Kubernetes Operator to change your deployment until you restore access to this cluster or until you redeploy the Kubernetes Operator to another available Kubernetes cluster. To learn more, see Disaster Recovery.

The following diagram shows the high-level architecture of a multi-Kubernetes cluster MongoDB deployment across regions and availability zones. This deployment uses a service mesh, such as Istio. The service mesh:

  • Manages the discovery of MongoDB nodes deployed in different Kubernetes member clusters.

  • Handles communication between replica set members.

You can host your application on any of the member clusters inside the service mesh, such as:

  • On Kubernetes clusters outside of the ones that you deploy with the Kubernetes Operator, or

  • On the member clusters in a multi-Kubernetes cluster MongoDB deployment.

Diagram showing the high-level architecture of a multi-cluster-Kubernetes
deployment across regions and availability zones using the
MongoDB Enterprise Kubernetes Operator, with a service mesh
click to enlarge

The following diagram shows the high-level architecture of a multi-Kubernetes cluster MongoDB deployment across regions and availability zones. This deployment doesn't rely on a service mesh for connectivity between the Kubernetes clusters hosting Pods with MongoDB instances.

To handle external communication between MongoDB replica set members hosted on Pods in distinct Kubernetes clusters, use external domains and DNS zones.

Diagram showing the high-level architecture of a multi-cluster-Kubernetes
deployment across regions and availability zones using the
MongoDB Enterprise Kubernetes Operator, and without a service mesh
click to enlarge

You can host your application on any of the member clusters.

← Overview