/ /

Supported Topologies

You can deploy MongoDB Search and Vector Search with the Kubernetes Operator against a range of MongoDB deployment topologies. The topology that you choose determines how the Kubernetes Operator deploys and connects the mongot process to your MongoDB deployment.

Use this page to confirm that your planned topology is supported before you deploy. To confirm the MongoDB Server, mongot, and Kubernetes Operator versions that you need, see Search and Vector Search Compatibility and Requirements.

Deployment Dimensions

A supported topology is a combination of the following dimensions:

MongoDB Cluster topology. Whether the mongot process serves a MongoDB replica set or a sharded cluster. For sharded clusters, the Kubernetes Operator deploys a separate mongot group for each shard.
Deployment type. Whether your MongoDB deployment runs in a single Kubernetes cluster (single-cluster) or spans multiple Kubernetes clusters (multi-cluster). In a multi-cluster topology, a single Kubernetes Operator in a central cluster manages the mongot processes in all member clusters.
Load balancer mode. When you run multiple mongot instances, you must place an L7 load balancer between mongod and the mongot pods. You can use one of the following options:
- Managed load balancer. The Kubernetes Operator deploys and configures an Envoy proxy.
- Unmanaged load balancer. You provide and configure your own L7 load balancer.
A single mongot instance connects directly to mongod and does not require a load balancer.
MongoDB source mode. Whether the MongoDBSearch resource uses spec.source.mongodbResourceRef to reference a MongoDB resource that the Kubernetes Operator manages (managed) or uses spec.source.external to configure the connection (external).

Supported Topology Matrix

The following table lists the support status for each combination of deployment dimensions:

Important

External MongoDB sources and multi-cluster topologies require MongoDB Enterprise. MongoDB Community supports only replica set deployments that the Kubernetes Operator manages inside Kubernetes.

Cluster Topology	Deployment Type	Load Balancer Mode	MongoDB Source Mode	Support Status
Replica set	Single-cluster	Managed	Managed	Supported
Replica set	Single-cluster	Managed	External	Supported
Replica set	Single-cluster	Unmanaged	Managed	Supported
Replica set	Single-cluster	Unmanaged	External	Supported
Replica set	Multi-cluster	Managed	Managed	Not supported
Replica set	Multi-cluster	Managed	External	Supported
Replica set	Multi-cluster	Unmanaged	Managed	Not supported
Replica set	Multi-cluster	Unmanaged	External	Not supported
Sharded cluster	Single-cluster	Managed	Managed	Supported
Sharded cluster	Single-cluster	Managed	External	Supported
Sharded cluster	Single-cluster	Unmanaged	Managed	Supported
Sharded cluster	Single-cluster	Unmanaged	External	Supported
Sharded cluster	Multi-cluster	Managed	Managed	Not supported
Sharded cluster	Multi-cluster	Managed	External	Supported
Sharded cluster	Multi-cluster	Unmanaged	Managed	Not supported
Sharded cluster	Multi-cluster	Unmanaged	External	Not supported

Topology Considerations

Review the following considerations when you choose a topology:

External MongoDB sources and multi-cluster topologies are available only for MongoDB Enterprise. MongoDB Community supports replica set deployments that the Kubernetes Operator manages inside Kubernetes.
In a multi-cluster topology, configure the MongoDB source using spec.source.external, even if the Kubernetes Operator manages the MongoDB deployment. Multi-cluster topologies don't support spec.source.mongodbResourceRef.
Multi-cluster topologies require the managed load balancer. The Kubernetes Operator supports unmanaged load balancers only in single-cluster topologies.
Multi-cluster topologies require network connectivity between the central cluster and the Kubernetes API server of each member cluster.

For other deployment limitations, see mongot Deployment Limitations.

Back

Deploy Search & Vector Search

Compatibility and Requirements