Deploy an Ops Manager Instance

Alpha Release of Ops Manager Resource

Don’t use the Ops Manager resource in production environments.

You can deploy Ops Manager in a container with the Kubernetes Operator.


To deploy an Ops Manager resource you must:

  1. Install the MongoDB Enterprise Kubernetes Operator 1.3.0 or newer.

  2. Ensure that the host on which you want to deploy Ops Manager has a minimum of five gigabytes of memory.

  3. Create a Kubernetes secret for an admin user in the same namespace as the Ops Manager resource.

    When you deploy the Ops Manager resource, Ops Manager creates a user with these credentials and grants it the Global Owner role. Use these credentials to log in to Ops Manager for the first time. Once Ops Manager is deployed, you should change the password or remove this secret.

    kubectl create secret generic <adminusercredentials>
      -n <namespace>


Encryption Key

The Kubernetes Operator generates an encryption key to protect sensitive information in the Ops Manager Application Database. The Kubernetes Operator saves this key in a secret in the same namespace as the Ops Manager resource. The Kubernetes Operator names the secret <om-resource-name>-gen-key.

If you remove the Ops Manager resource, the key remains stored in the secret on Kubernetes cluster. If you stored the Application Database in a Persistent Volume and you create another Ops Manager resource with the same name, the Kubernetes Operator reuses the secret. If you create an Ops Manager resource with a different name, then Kubernetes Operator creates a new secret and Application Database, and the old secret isn’t reused.

Application Database Replica Set

When you create an instance of Ops Manager through the Kubernetes Operator, the Ops Manager Application Database is deployed as a replica set. You can’t configure the Application Database as a standalone database or sharded cluster. If you have concerns about performance or size requirements for the Application Database, contact MongoDB Support.



Copy the following example Ops Manager Kubernetes object.

Change the highlighted settings to match your desired Ops Manager configuration.

kind: MongoDBOpsManager
  name: <myopsmanager>
  version: <opsmanagerversion>
  adminCredentials: <adminusercredentials> # Should match
                                           # in the Kubernetes secret
                                           # for the admin user
    members: 3
    version: <mongodbversion>
    persistent: true

Open your preferred text editor and paste the object specification into a new text file.


Configure the settings highlighted in the prior example.

Key Type Description Example string

Name for this Kubernetes Ops Manager object.

See also

spec.version string

Version of Ops Manager to be installed.

The format should be X.Y.Z. To view available Ops Manager versions, view the container registry.

spec.adminCredentials string

Name of the secret you created for the Ops Manager admin user.


Configure the secret to use the same namespace as the Ops Manager resource.

integer Number of members of the Ops Manager Application Database replica set. 3

Version of MongoDB that the Ops Manager Application Database should run.

The format should be X.Y.Z for the Community edition and X.Y.Z-ent for the Enterprise edition.

To learn more about MongoDB versioning, see see MongoDB Versioning in the MongoDB Manual.



Flag indicating if this MongoDB Kubernetes resource should use Persistent Volumes for storage. Persistent volumes are not deleted when the MongoDB Kubernetes resource is stopped or restarted.

If this value is true, then spec.applicationDatabase.podSpec.persistence. single is set to its default value of 16G.

To change your Persistent Volume Claims configuration, configure the following collections to meet your deployment requirements:

  • If you want one Persistent Volume for each pod, configure the spec.applicationDatabase. single collection.

  • If you want separate Persistent Volumes for data, journals, and logs for each pod, configure the following collections:

    • spec.applicationDatabase
    • spec.applicationDatabase
    • spec.applicationDatabase


Grant your containers permission to write to your Persistent Volume. The Kubernetes Operator sets fsGroup = 2000 in securityContext This makes Kubernetes try to fix write permissions for the Persistent Volume. If redeploying the resource does not fix issues with your Persistent Volumes, contact MongoDB support.


(Optional) Configure any additional settings for an Ops Manager deployment.

You can add any of the following optional settings to the object specification file for an Ops Manager deployment:


Save this file with a .yaml file extension.


Create your Ops Manager instance.

Invoke the following kubectl command on the filename of the Ops Manager resource definition:

kubectl apply -f <opsmgr-resource>.yaml

Track the status of your Ops Manager instance.

To check the status of your Ops Manager resource, invoke the following command:

kubectl get om -n <namespace> -o yaml -w

The -w flag means “watch”. With the “watch” flag set, the output refreshes immediately when something changes.

If the deployment fails, see Troubleshooting the Kubernetes Operator.


Access your Ops Manager instance from a browser.

  1. After the resource deploys successfully, find the external port to your Ops Manager instance.

    Invoke the following kubectl command on <>-svc-external: :

    kubectl get svc <>-svc-external -n <namespace>

    The command returns the external port in the PORT(S) column. In the following example output, the external port is 30036:

    NAME                            TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
    <>-svc-external    NodePort    <none>        8080:30036/TCP    1d
  2. Set your firewall rules to allow access from the Internet to the external port on the host.

  3. Open a browser window and navigate to the Ops Manager application using the FQDN and port number.
  4. Log in to Ops Manager using the admin user credentials.