Kubernetes Operator Deployment
Parent: MongoDB Ops Manager and Cloud Manager · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-aa8dae0ac5e2
↓ Facts as markdownall context files
Source-anchored research for Kubernetes Operator Deployment. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- For a deployment stuck in Pending or Failed, inspect the custom-resource status and Operator logs. Ops Manager resources expose separate application-database, backup and application status fields, which help identify which component failed. (medium confidence) [source]
How it works
- The MongoDBOpsManager custom resource covers the Ops Manager application, its backing Application Database, and the Backup Daemon. The operator deploys the Application Database before the application and starts the Backup Daemon only when backup is enabled. (high confidence) [source]
- MongoDB documents a StatefulSet recovery case where correcting the custom-resource configuration is insufficient: after fixing the cause, delete the hung Pending pod so the StatefulSet can recreate it with the corrected configuration. (low confidence) [source]
- In its deployment walkthrough, Kinekube bootstraps Ops Manager with backup disabled, creates the managed oplog-store database, then enables backup to avoid a dependency cycle. Treat this as a walkthrough pattern requiring validation against the selected Operator version. (low confidence) [source]
Facts and statements
- The Operator extends Kubernetes with MongoDB and Ops Manager custom resources; it reconciles their declared configuration into native objects such as StatefulSets, Services, Secrets and ConfigMaps. (high confidence) [source]
- The Enterprise path integrates with Ops Manager or Cloud Manager for automation, monitoring, and backups. Ops Manager can run inside Kubernetes under operator management or be installed outside Kubernetes. (high confidence) [source]
- Kubernetes custom-resource manifests can be managed in Git, allowing database configuration changes to use the same declarative review workflow as application deployments. (high confidence) [source]
- The deployment connection pattern uses a ConfigMap for the Ops Manager endpoint and project reference, plus a Kubernetes Secret for API credentials; the database resource references both. (high confidence) [source]
- Choose the operator's watched namespace scope before deployment. If multiple operator instances are necessary, give them non-overlapping namespaces or different resource types so two controllers do not reconcile the same resource. (high confidence) [source]
- Plan persistent storage independently of installing the Operator. MongoDB recommends separate member volumes, ReadWriteOnce support and an expandable storage class; the Portworx deployment guide likewise configures a StorageClass before deploying database resources. (high confidence) [source]
- MCK 1.12.0 introduced referencing an external Application Database through MongoDBOpsManager.spec.externalApplicationDatabaseRef and a MongoDB resource with spec.role: AppDB. Its initial release limited this feature to single-cluster AppDB deployments and called for a separate management Ops Manager for disaster recovery. (low confidence) (verified as of 2026-09-08) [source]
- Operator automation does not remove responsibility for Kubernetes storage, networking, security, and compute. MongoDB's FAQ explicitly requires users to configure those dependencies, and its production guide supplies storage and namespace requirements. (high confidence) [source]
- In the repository snapshot checked on 2026-10-23, MongoDB Controllers for Kubernetes unifies the former Enterprise and Community operators. Its Community path manages Community Server replica sets but has no Ops Manager or Cloud Manager integration. (low confidence) (verified as of 2026-10-23) [source]
- The Application Database runs as a replica set with per-Pod persistent volume claims. Its primary election requires a majority; spreading members across clusters preserves availability only if the surviving clusters retain that majority. (low confidence) [source]
- MongoDB recommends persistent volumes supporting ReadWriteOnce for managed database and Ops Manager Application Database workloads. Replica-set members must not share storage; database volume resizing requires a storage class that supports expansion. (low confidence) [source]
- In its June 3, 2024 OpenShift support guidance, Red Hat identifies MongoDB as the provider of MongoDB Enterprise Operator licences and support. The current MongoDB repository likewise directs operator support to MongoDB; OpenShift certification alone does not supply those entitlements. (medium confidence) (verified as of 2024-06-03) [source]
- The operator's Apache 2.0 licence does not change entitlements for Enterprise Server or Ops Manager. MongoDB states that those product entitlements remain unchanged; Red Hat's Enterprise Operator guidance separately describes Enterprise Advanced subscription entitlements. (medium confidence) (verified as of 2026-10-23) [source]
- Deleting an operator-managed MongoDB resource does not automatically remove its monitoring entry or retained backup snapshots from Ops Manager. The troubleshooting guide requires separate monitoring cleanup and explicit snapshot deletion. (low confidence) [source]
- Percona's May 2, 2025 comparison describes its own operator as using Percona Backup for MongoDB for backups and Percona Monitoring and Management for monitoring. That is a separate management stack, not evidence of an Ops Manager integration. (low confidence) (verified as of 2025-05-02) [source]
Children
- Operator namespace scope and RBAC (frontier)
- Ops Manager Application Database persistence (frontier)
- Operator reconciliation troubleshooting (frontier)
- Ops Manager backup bootstrap dependencies (frontier)
- Ops Manager Application Database quorum (frontier)
- Operator persistent storage and backup lifecycle (frontier)
Frontier under this node: Operator namespace scope and RBAC, Operator persistent storage and backup lifecycle, Operator reconciliation troubleshooting, Ops Manager Application Database persistence, Ops Manager Application Database quorum, Ops Manager backup bootstrap dependencies