This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Kubernetes Operator, refer to the upgrade documentation.
  • Reference >
  • Known Issues in the MongoDB Enterprise Kubernetes Operator

Known Issues in the MongoDB Enterprise Kubernetes Operator

Deleting a Resource with Backups Removes All Snapshots

When you delete a resource that has backup configured, the Kubernetes Operator terminates all backups. Deleting a resource removes all existing snapshots without warning.

Configure Persistent Storage Correctly

If there are no persistent volumes available when you create a resource, the resulting pod stays in transient state and the Operator fails (after 20 retries) with the following error:

Failed to update Ops Manager automation config: Some agents failed to register

To prevent this error, either:

For testing only, you may also set persistent : false. This must not be used in production, as data is not preserved between restarts.

Remove Resources before Removing Kubernetes

Sometimes Ops Manager can diverge from Kubernetes. This mostly occurs when Kubernetes resources are removed manually. Ops Manager can keep displaying an Automation Agent which has been shut down.

If you want to remove deployments of MongoDB on Kubernetes, use the resource specification to delete resources first so no dead Automation Agents remain.

Create Separate Namespaces for Kubernetes Operator and MongoDB Resources

The best strategy is to create Kubernetes Operator and its resources in different namespaces so that the following operations would work correctly:

kubectl delete pods --all


kubectl delete namespace mongodb

If the Kubernetes Operator and resources sit in the same mongodb namespace, then operator would also be removed in the same operation. This would mean that it could not clean the configurations, which would have to be done in the Ops Manager Application.

Difficulties with Updates

In some cases, the Kubernetes Operator can stop receiving change events. As this problem is hard to reproduce, the recommended workaround is to delete the operator pod. Kubernetes starts the new Kubernetes Operator automatically and starts working correctly:

kubectl get pods;
kubectl delete pod mongodb-enterprise-operator-<podId>`

Machine Memory vs. Container Memory

MongoDB versions older than 3.6.13, 4.0.9, and 4.1.9 report host system RAM, not container RAM.

Changes to Avoid

The Kubernetes Operator will not be able to apply the following change on a MongoDB Deployment simultaneously:

  • The TLS configuration is disabled (security.tls.enabled: false)
  • The number of members in a Replica Set is increased

If both operations are applied at the same time, the MongoDB Resource could go into a unrecoverable state.