Deploy MongoDB Resources across Multiple Kubernetes Clusters (Beta)


This feature is a beta release. Use multi-Kubernetes-cluster deployment deployments only in development environments.


Using multi-Kubernetes-cluster deployments, you can deploy MongoDB Enterprise Kubernetes Operator to manage MongoDB deployments that span two or more Kubernetes clusters. During the beta, the Kubernetes Operator supports deploying only replica sets across two or more Kubernetes clusters. Deploying sharded clusters across two or more Kubernetes clusters is not supported.

The beta release of the multi-Kubernetes-cluster deployments enables different levels of resilience, depending on the needs of your enterprise application:

  • Single Region, Multi AZ. One or more Kubernetes clusters where each cluster has nodes deployed in different zones in the same region. Such deployments protect MongoDB instances backing your enterprise applications against zone and Kubernetes cluster failures and offer increased availability, disaster recovery, and data distribution within one cloud region.
  • Multi Region. One or more Kubernetes clusters where you deploy each cluster in a different region, and within each region, deploy cluster nodes in different availability zones. This gives your database resilience against the loss of a Kubernetes cluster, a zone, or an entire cloud region.

Multi-Kubernetes-cluster deployment deployments allow you to add MongoDB instances in global clusters that span multiple geographic regions for increased availability and global distribution of data.

A service mesh is required to enable inter-cluster communication between the replica set members deployed in different Kubernetes clusters. MongoDB development has tested this feature using Istio, but any service mesh that provides FQDN resolution between Pods across clusters should work.

Central Cluster and Member Clusters

MongoDB recommends that you identify one cluster to act as a central cluster. The central cluster hosts the Kubernetes Operator and acts as the control plane for the multi-cluster deployment. This central cluster can also host replica set members. This documentation refers to other Kubernetes clusters that host replica set members as member clusters.

Communication between replica set members occurs over a service mesh, which means that your database doesn’t rely on the central cluster to function. Note that if the central cluster fails, you can’t use the Kubernetes Operator to change your deployment until access to this cluster is restored or until you redeploy the Kubernetes Operator to an available Kubernetes cluster.

You can host your application on any Kubernetes cluster in the service mesh. Your application can be co-located on a member cluster with one of the replica set nodes that you deployed using the Kubernetes Operator, or you can host your application on a cluster that doesn’t host replica set nodes or the Kubernetes Operator.

To learn more, see the Multi-Cluster Deployment Architecture.