MongoDB Operator can only deploy and manage MongoDB in a single Kubernetes cluster. However, for DR and global apps, it is important to deploy a single DataBase across multiple Kubernetes clusters to allow for DR or globally distributed apps.

Currently Ops Manager CRD deployment requires configuration using GUI which is a manual step. An option completely define all OPS Manager settings / Org in declarative manner via yaml will be great in building completely automated CI/CD Pipelines

Please, build a course like you already have but now for Kubernetes Operator. I had serious troubles implementing it.

For the purpose of regularly performing backups of the AppDB using mongodump --oplog.

It's still very new and only kube-router is the only "free" one that supports it. But this is great simplify the network configurations to connect to replicas and shards.

Route Sharing is currently supported on Red Hat OpenShift 4.4+

So that way multiple projects can leverage the single operator to provision mongodb. https://github.com/mongodb/mongodb-enterprise-kubernetes/issues/164

So that way multiple projects can leverage the single operator to provision mongodb. https://github.com/mongodb/mongodb-enterprise-kubernetes/issues/164

> 1.) What is the limiting factor of the Operator? Is it number of Pods, number of Custom Resources (e.g. MongoDB, MongoDBUser) or something else?

> 2.) What does the number of "Clusters" refer to? Does it differ for Standalone, ReplicaSet and ShardedCluster?

> 3.) How many instances of the "Clusters" in 2.) are supported per MongoDB Operator?

Is there any way to add this sort of data to our documentation?

Thanks

Since the kube CA integration is deprecated, the operator should have an option to integrate with cert-manager and external-dns for automatic tls and dns records.

Provide a helm chart that deploys MongoDB, MongoDBUser, secrets and all other resources needed.

The goal is to simplify the deployment of a MongoDB instance and everything that comes with it down to a helm one-liner.

As PodAntiAffinity does not really give enough flexibility in achieving High Availability and enforcing distribution across nodes, it should be possible to add topologySpreadConstraints to the podSpec (of both ShardedCluster and other deployment types). As of now topologySpreadConstraints are ignored by the Operator.

https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#comparison-with-podaffinity-podantiaffinity

In ops-manager.yaml, can we define the number of the initial backup daemons?

The additionalMongodConfig feature was a great addition to the Operator.

Setting the spec.additionalMongodConfig.net.port to a value other than the default 27017 is not working as expected. The default port is still used despite the custom port value appearing in the MongoDB resource description/manifest. A common security compliance checklist often includes running services on non-default ports.

Please consider allowing the net.port to be set to a custom value; this may have implications with the services that are automatically created in the cluster.

Support arbiters with MongoDB Kubernetes Operator so that Replicasets should be deployed in PSA configuration.

Show some of the Kubernetes resources in Ops Manager
1. show namespaces in projects,
2. Show list of resources in cluster view

Allow configuration of backup settings in MongoDB Custom resource.
This includes management of backed up resources when updating, moving or deleting clusters