Frequently Asked Questions

What is an Operator?

An operator is a standard mechanism that extends the control plane of Kubernetes to managing custom Kubernetes resources. Because each operator is built for its own Custom Resources (CRs), it can contain logic that addresses the type of service that the operator is built for. For the Kubernetes Operator, the operator includes the logic for the deployment of MongoDB Server and Ops Manager instances.

Each CR used by the Kubernetes Operator represents an element of a MongoDB Server deployment in Kubernetes, and has options for customizing that part of the deployment. Once you configure these objects in the Kubernetes deployment, the operator builds native Kubernetes objects, such as Stateful Sets that are necessary to create Pods according to your specified requirements for MongoDB Servers. The Kubernetes Operator also facilitates configuration of MongoDB Server features, such as database backups, through interaction with MongoDB Cloud Manager or Ops Manager.

Why should I run MongoDB Server and MongoDB Enterprise Advanced in Kubernetes?

When you deploy MongoDB Server or MongoDB Enterprise Advanced in Kubernetes through the MongoDB Enterprise Kubernetes Operator, your deployments can benefit from the resilience and simple orchestration that Kubernetes provides.

The only supported way to deploy MongoDB Enterprise Advanced in Kubernetes is through the MongoDB Enterprise Kubernetes Operator. The MongoDB Enterprise Kubernetes Operator simplifies your daily workflows and makes it easier for MongoDB technical support staff to assist you when needed.

Which Kubernetes platforms are supported for MongoDB Server deployments?

MongoDB Server supports any platform that builds upon native Kubernetes without changing the default logic or behavior. In practice, this means that MongoDB Server supports any Kubernetes platform certified by the Cloud Native Computing Foundation. To learn more, see MongoDB Kubernetes Operator Compatibility.

How many deployments can MongoDB Enterprise Kubernetes Operator support?

Kubernetes Operator can support up to 50 deployments. However, changes made to large numbers of deployments at the same time result in long reconciliation times. To avoid prolonged reconciliation times, limit a given Kubernetes Operator instance to 20 deployments. To learn more, see the Deploy the Recommended Number of MongoDB Replica Sets.

Should I run MongoDB Server in Kubernetes in the same cluster as the application using it?

To help minimize latency, consider colocating your database and applications on the same Kubernetes cluster if your deployment architecture allows this.

Can I deploy MongoDB Server across multiple Kubernetes clusters?

Yes. To learn more, see Deploy MongoDB Resources on Multiple Kubernetes Clusters. For help, contact MongoDB Support.

What is the difference between using the Kubernetes Operator for managing multi-Kubernetes-cluster deployments and managing a single Kubernetes cluster?

To use the Kubernetes Operator for managing a multi-Kubernetes-cluster deployment, you must set up a specific set of Kubernetes Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and ServiceAccounts.

The Kubernetes Operator used for a multi-Kubernetes-cluster deployment can also reconcile a single Kubernetes cluster resource. To learn more, see Does MongoDB support running more than one Kubernetes Operator instance?.

Does MongoDB support running more than one Kubernetes Operator instance?

If possible, we recommend that you set up a single Kubernetes Operator instance to watch one, many, or all namespaces within your Kubernetes cluster. By default, the Kubernetes Operator watches all custom resource types that you choose to deploy, and you don't need to configure it to watch specific resource types.

However, once you reach a performance limit for the number of deployments a single Kubernetes Operator instance can support, you can set up an additional Kubernetes Operator instance. At this point, consider how you want to divide up management of resources in the Kubernetes cluster. Use the following recommendations listed in the order of priority:

• Ensure that each Kubernetes Operator instance is watching different and non-overlapping namespaces within the Kubernetes cluster.

• Alternatively, configure different instances of the Kubernetes Operator to watch different resource types, either in different namespaces or overlapping namespaces.

  If you choose to use overlapping namespaces, ensure that each Kubernetes Operator instance watches different types of resources to avoid conflict that would result in two instances of the Kubernetes Operator attempting to manage the same resources.