Navigation
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.

Deploy a Standalone MongoDB Instance

Supported with Cloud Manager and Ops Manager 4.0

You can use Kubernetes Operator to deploy MongoDB instances with Ops Manager version 4.0 or later and Cloud Manager. At any place in this guide that says Ops Manager, you can substitute Cloud Manager.

You can deploy a standalone MongoDB instance for Ops Manager to manage. Use standalone instances for testing and development. Do not use these deployments for production systems as they lack replication and high availability. For all production deployments use replica sets. To learn about replica sets, see Deploy a Replica Set.

Prerequisites

To deploy a standalone using an object, you need to complete the following procedures:

Considerations

Starting in MongoDB Enterprise Kubernetes Operator version 1.3.0, you can only have one MongoDB resource per project. To learn how to migrate your project to a single-cluster configuration, see Migrate to One Resource per Project (Required for Version 1.3.0).

Procedure

1

Copy the following example standalone Kubernetes object.

This is a YAML file that you can modify to meet your desired configuration. Change the highlighted settings to match your desired standalone configuration.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-standalone>
  namespace: <metadata.namespace>       # Should match
                                        # metadata.namespace in
                                        # your configmap file.
spec:
  version: 4.2.1
  opsManager:                           # Alias of cloudManager
    configMapRef:
      name: <configMap.metadata.name>   # Should match metadata.name
                                        # in your configmap file.
  credentials: <mycredentials>
  type: Standalone
  persistent: true
...
2

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

3

Configure the settings highlighted in the preceeding step as follows.

Key Type Description Example
metadata.name string

Label for this Kubernetes standalone object.

See also

my-project
metadata.namespace string

Scope of object names. Kubernetes namespace where this MongoDB Kubernetes resource and other objects are created.

Using two different namespaces allows you to delete your standalone or all of the resources in the namespace without affecting your Kubernetes Operator.

See also

mongodb
spec.version string

Version of MongoDB that is installed on this standalone.

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 MongoDB Versioning in the MongoDB Manual.

3.6.7
spec.opsManager.configMapRef.name string

Name of the ConfigMap with the Ops Manager connection configuration. The spec.cloudManager.configMapRef.name setting is an alias for this setting and can be used in its place.

Value must match namespace and name of ConfigMap

This value must match the value you provided for metadata.name in your Ops Manager project ConfigMap.

Operator manages changes to the ConfigMap

The Kubernetes Operator tracks any changes to the ConfigMap and reconciles the state of the MongoDB Kubernetes resource.

<myproject>
spec.credentials string

Name of the Kubernetes secret you created as Ops Manager API authentication credentials for the Kubernetes Operator to communicate with Ops Manager.

Value must use namespace and name of Secret

This value must match the value you provided for namespace and name for your Ops Manager Kubernetes Secret.

Operator manages changes to the Secret

The Kubernetes Operator tracks any changes to the Secret and reconciles the state of the MongoDB Kubernetes resource.

<mycredentials>
spec.type string Type of MongoDB Kubernetes resource to create. Standalone
spec.persistent string

Optional.

If this value is true, then spec.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:

Warning

Your containers must have permissions 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 deployment item does not fix issues with your Persistent Volumes, contact MongoDB Support.

Note

If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment.

true
5

Save this file with a .yaml file extension.

6

Start your Standalone deployment.

Invoke the following Kubernetes command to create your standalone:

kubectl apply -f <standalone-conf>.yaml
7

Track the status of your standalone deployment.

To check the status of your MongoDB Kubernetes resource, invoke the following command:

kubectl get mdb <resource-name> -n <namespace> -o yaml -w

The -w flag means “watch”. With the “watch” flag set, the output refreshes immediately when something changes until the status phase achieves the Running state.

See Troubleshooting the Kubernetes Operator for information about the resource deployment statuses.

To troubleshoot your sharded cluster, see: