On this page
kubectlto default to your namespace.
- Delete the StatefulSet that manages your Ops Manager Pods.
- Copy the fields of this Ops Manager resource.
- Paste the copied example section into your existing Ops Manager resource.
- Save your Ops Manager config file.
- Apply changes to your Ops Manager deployment.
- In a rolling fashion, delete your old Ops Manager Pods.
- Track the status of your Ops Manager instance.
- Download the MongoDB installation archive to your local machine.
- Copy the MongoDB archive to the Ops Manager Persistent Volume.
- Deploy a MongoDB Database Resource.
Configuring Ops Manager to use Local Mode in Kubernetes is not recommended. Consider configuring Ops Manager to use Remote Mode instead.
In a default configuration, the MongoDB Agents and Backup Daemons access MongoDB installation archives over the Internet from MongoDB, Inc.
You can configure Ops Manager to run in Local Mode with the Kubernetes Operator if the nodes in your Kubernetes cluster don't have access to the Internet. The Backup Daemons and managed MongoDB resources download installation archives only from a Persistent Volume that you create for the Ops Manager StatefulSet.
This procedure covers uploading installation archives to Ops Manager.
If Ops Manager has no internet access, see Configure Deployment to Have Limited Internet Access.
For compatbility, see MongoDB Enterprise Kubernetes Operator Compatibility. To view all available versions for each image, see Container Images.
To avoid downtime when you enable Local Mode, ensure that you set
spec.replicasto a value greater than
1in your Ops Manager resource definition.
If you updated your Ops Manager resource definition to make Ops Manager highly available, apply your changes before you begin this tutorial:
kubectl apply -f <opsmgr-resource>.yaml -n <metadata.namespace>
If you have not already, run the following command to execute all
kubectl commands in the namespace you created.
If you are deploying an Ops Manager resource in a multi-Kubernetes-cluster deployment:
contextto the name of the central cluster, such as:
kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".
--namespaceto the same scope that you used for your multi-Kubernetes-cluster deployment, such as:
kubectl config --namespace "mongodb".
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
Delete the StatefulSet that manages your Ops Manager Pods.
In this tutorial, you update the StatefulSet that manages the Ops Manager Pods in your Kubernetes cluster.
You must first delete the Ops Manager StatefulSet so that Kubernetes can apply the updates that Local Mode requires.
Find the name of your Ops Manager StatefulSet:
kubectl get statefulsets
The entry in the response that matches the
Your Ops Manager StatefulSet is the entry in the response that matches the
metadata.namein your Ops Manager resource definition.
kubectl get statefulsets -n mongodb NAME READY AGE ops-manager-localmode 2/2 2m31s ops-manager-localmode-db 3/3 4m46s
Delete the Ops Manager StatefulSet:
Ensure that you include the
--cascade=falseflag when you delete your Ops Manager StatefulSet. If you don't include this flag, Kubernetes also deletes your Ops Manager Pods.
kubectl delete statefulset --cascade=false <ops-manager-statefulset>
Copy Lines 9-31 of this example to:
Use the Ops Manager configuration setting
spec.configurationto enable Local Mode.
Define a Persistent Volume for the Ops Manager StatefulSet to store the MongoDB installation archive. MongoDB Agents running in MongoDB database resource containers that you create with the Kubernetes Operator download the installation archives from Ops Manager instead of from the Internet.
1 apiVersion: mongodb.com/v1 2 kind: MongoDBOpsManager 3 metadata: 4 name: ops-manager-localmode 5 spec: 6 replicas: 2 7 version: "6.0.0" 8 adminCredentials: ops-manager-admin-secret 9 configuration: 10 # this enables local mode in Ops Manager 11 automation.versions.source: local 12 statefulSet: 13 spec: 14 # the Persistent Volume Claim will be created for each Ops Manager Pod 15 volumeClaimTemplates: 16 - metadata: 17 name: mongodb-versions 18 spec: 19 accessModes: [ "ReadWriteOnce" ] 20 resources: 21 requests: 22 storage: "20Gi" 23 template: 24 spec: 25 containers: 26 - name: mongodb-ops-manager 27 volumeMounts: 28 - name: mongodb-versions 29 # this is the directory in each Pod where all MongoDB 30 # archives must be put 31 mountPath: /mongodb-ops-manager/mongodb-releases 32 backup: 33 enabled: false 34 applicationDatabase: 35 members: 3
Open your preferred text editor and paste the object specification into the appropriate location in your resource file.
Invoke the following
kubectlcommand on the filename of the Ops Manager resource definition:
kubectl apply -f <opsmgr-resource>.yaml
Kubernetes creates a new Ops Manager StatefulSet when you apply the changes to your Ops Manager resource definition. Before proceeding to the next step, run the following command to ensure that the Ops Manager StatefulSet exists:
kubectl get statefulsets
The new Ops Manager StatefulSet should show 0 members ready:
kubectl get statefulsets -n mongodb NAME READY AGE ops-manager-localmode 0/2 2m31s ops-manager-localmode-db 3/3 4m46s
List the Ops Manager Pods in your Kubernetes cluster:
kubectl get pods
Delete one Ops Manager Pod:
kubectl delete pod <om-pod-0>
Kubernetes recreates the Ops Manager Pod you deleted. Continue to get the status of the new Pod until it is ready:
kubectl get pods
When the new Pod is initializing, the output is similar to the following example:
NAME READY STATUS RESTARTS AGE mongodb-enterprise-operator-5648d4c86-k5brh 1/1 Running 0 5m24s ops-manager-localmode-0 0/1 Running 0 0m55s ops-manager-localmode-1 1/1 Running 0 5m45s ops-manager-localmode-db-0 1/1 Running 0 5m19s ops-manager-localmode-db-1 1/1 Running 0 4m54s ops-manager-localmode-db-2 1/1 Running 0 4m12s
When the new Pod is ready, the output is similar to the following example:
NAME READY STATUS RESTARTS AGE mongodb-enterprise-operator-5648d4c86-k5brh 1/1 Running 0 5m24s ops-manager-localmode-0 1/1 Running 0 3m55s ops-manager-localmode-1 1/1 Running 0 5m45s ops-manager-localmode-db-0 1/1 Running 0 5m19s ops-manager-localmode-db-1 1/1 Running 0 4m54s ops-manager-localmode-db-2 1/1 Running 0 4m12s
Repeat Steps b and c until you've deleted all of your Ops Manager Pods and confirmed that all of the new Pods are ready.
To check the status of your Ops Manager resource, invoke the following command:
kubectl get om -o yaml -w
See Troubleshoot the Kubernetes Operator for information about the resource deployment statuses.
After the Ops Manager resource completes the
Pending phase, the
command returns output similar to the following:
1 status: 2 applicationDatabase: 3 lastTransition: "2020-05-15T16:20:22Z" 4 members: 3 5 phase: Running 6 type: ReplicaSet 7 version: "4.4.5-ubi8" 8 backup: 9 phase: "" 10 opsManager: 11 lastTransition: "2020-05-15T16:20:26Z" 12 phase: Running 13 replicas: 1 14 url: http://ops-manager-localmode-svc.mongodb.svc.cluster.local:8080 15 version: "5.0.0"
Copy the value of the
status.opsManager.url field, which states
the resource's connection URL. You use this value when you create a
ConfigMap later in the procedure.
The installers that you download depend on the environment to which you deployed the operator:
The following example includes a link that allows you to download the specified version of MongoDB Community Edition. To download any other version of MongoDB Community Edition, visit the MongoDB Community Edition Download Center. To download MongoDB Enterprise Edition, visit the MongoDB Enterprise Download Center.
Download the RHEL installation tarball for the MongoDB Server version
you want the Kubernetes Operator to deploy. For example, to download the
curl -OL https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel80-6.0.1.tgz
Copy the MongoDB archive for each MongoDB version you intend to deploy to the Ops Manager Persistent Volume.
The commands that you use depend on the environment to which you deployed the Kubernetes Operator:
If you deployed more than one Ops Manager
replica, copy only the MongoDB
tarball packages to
Replica 1 and
If you have not done so already, complete the following prerequisites:
Deploy a MongoDB database resource in the same namespace to which you deployed Ops Manager. Ensure that you:
spec.opsManager.configMapRef.nameof the resource to the
metadata.nameof your ConfigMap.
spec.credentialsof the resource to the name of the secret you created that contains an Ops Manager programmatic API key pair.
MongoDB Agents run in MongoDB database resource containers that you create with the Kubernetes Operator. Download the installation archives from Ops Manager instead of downloading them from the Internet.