MongoDB on Kubernetes
MongoDB on Kubernetes
In short: Running MongoDB on Kubernetes means using an operator — the MongoDB Community Operator or the Percona Operator for MongoDB — to deploy replica sets (or sharded config-server, shard, and mongos tiers) as StatefulSets. Each pod gets a PersistentVolumeClaim, with headless Services for discovery, automated elections, rolling upgrades, and PBM point-in-time backups.
Deploy and manage production MongoDB on Kubernetes with operator-driven automation, Helm charts, replica sets, and sharded clusters for cloud-native scalability and resilience.
JusDB engineers production-grade MongoDB on Kubernetes deployments leveraging the MongoDB Community Operator and Percona Server for MongoDB Operator. JusDB DBREs configure multi-AZ replica sets and sharded clusters, provision dedicated local NVMe storage classes, enforce PodDisruptionBudgets, and execute zero-downtime rolling stateful upgrades.
Comprehensive MongoDB on Kubernetes Services
From operator deployment to production monitoring, we provide end-to-end MongoDB on Kubernetes solutions for cloud-native environments.
Operator Deployment
Deploy and configure MongoDB operators for automated lifecycle management on Kubernetes
- MongoDB Community Operator setup
- MongoDB Enterprise Operator deployment
- Percona Operator for MongoDB installation
- Custom resource definition (CRD) configuration
Helm Chart Management
Customized Helm chart deployment with production-grade configuration and tuning
- Helm chart customization and overrides
- Values file management per environment
- MongoDB configuration tuning (mongod.conf)
- Resource limits, requests, and affinity rules
Replica Sets & Sharding on K8s
Design and deploy MongoDB replica set topologies and sharded clusters on Kubernetes
- Replica set topology and member sizing
- Sharded cluster with config servers and mongos
- Shard key design and balancer tuning
- Cross-zone and cross-region replica placement
Storage & Persistence
Persistent volume configuration optimized for MongoDB WiredTiger engine performance
- PVC and StorageClass configuration
- WiredTiger cache sizing and tuning
- Separate journal volume mounts
- Volume expansion and snapshot policies
Monitoring on K8s
Full-stack MongoDB observability with Prometheus, Grafana, and dedicated exporters
- MongoDB Exporter for Prometheus
- Grafana dashboard provisioning
- Oplog lag and replication alerting
- WiredTiger cache and connection metrics
Backup & DR
Automated backup pipelines and disaster recovery for MongoDB on Kubernetes
- mongodump CronJobs on K8s
- Percona Backup for MongoDB (PBM) setup
- S3-compatible backup storage
- Point-in-time recovery (PITR) configuration
MongoDB Kubernetes Operators Compared
Choose the right operator for your MongoDB on Kubernetes deployment based on your licensing, feature, and support requirements.
Open Source
MongoDB Community Operator
Official MongoDB operator for community edition
Best for: Open-source deployments, replica sets, standard workloads
Commercial
MongoDB Enterprise Operator
Official enterprise operator with Ops Manager integration
Best for: Enterprise edition, Ops Manager, compliance and auditing
Full-Featured Open Source
Percona Operator for MongoDB
Enterprise-grade operator with built-in backup and sharding
Best for: Sharded clusters, backup/PITR, enterprise-grade open source
Our MongoDB on Kubernetes Implementation Process
A proven methodology for deploying production-ready MongoDB on Kubernetes with operator-driven automation and comprehensive validation.
Assessment & Planning
Evaluate workload requirements, data volume, availability targets, and K8s cluster topology. Select the right operator, storage class, and replica set or sharded architecture.
Operator & Cluster Deployment
Install the chosen operator via Helm, configure custom resources for replica sets or sharded clusters, set up PVCs, TLS, authentication, and network policies.
Integration & Validation
Migrate data, validate application connectivity, test failover scenarios, configure backups to S3, and set up Prometheus/Grafana monitoring and alerting.
Production Go-Live & Support
Cut over to production with runbooks, backup verification, scaling procedures, and ongoing monitoring and support for your MongoDB K8s deployment.
How JusDB Kubernetes DBRE compares to alternative models.
Standard Kubernetes platforms and generic DevOps teams frequently treat MongoDB as a generic stateless workload, causing quorum loss, persistent storage deadlocks, and corrupted unverified backups. Here is how our MongoDB DBREs compare:
| Evaluation Vector | JusDB DBRE | In-House DBA | Legacy Agency | Developer Generalist |
|---|---|---|---|---|
| MongoDB Community Operator vs Percona Server for MongoDB Operator | Assesses enterprise requirements (LDAP/OIDC, physical hot backups, and encryption) to deploy either official MongoDBCommunity or PerconaServerMongoDB CRDs with custom controller tuning. | Deploys manual StatefulSets without an operator, requiring custom shell scripts for rs.initiate() and pod lifecycle management. | Forces deprecated Helm charts and unmaintained community operators that fail during Kubernetes API version upgrades. | Pulls community operator Helm charts blindly without configuring RBAC security contexts, pod service accounts, or custom resource definitions. |
| Multi-AZ Replica Set Topology & Hard Anti-Affinity | Configures requiredDuringSchedulingIgnoredDuringExecution topologySpreadConstraints and hard podAntiAffinity across availability zones, ensuring surviving quorum during AZ loss. | Uses soft anti-affinity, allowing the Kubernetes scheduler to co-locate multiple replica set members on the same node or single AZ during worker drains. | Deploys pods into a single worker node pool without node affinity, failing cross-AZ disaster recovery requirements. | Ignores topology spread constraints entirely, resulting in total cluster downtime during routine cloud provider spot node reclamation. |
| Dedicated Local NVMe StorageClasses & XFS Mount Tuning | Provisions dedicated local NVMe persistent volumes with tuned XFS mount options (noatime, nodiratime, allocsize=64m) and separate journal paths for sub-10ms P99 disk latencies. | Relies on default cloud networked block storage (e.g. EBS gp2/gp3) with uncalibrated burst IOPS, hitting I/O throttling during checkpoint flushes. | Uses NFS or shared storage classes for mongod data directories, triggering lock deadlocks, WiredTiger corruption, and fatal server crashes. | Uses ext4 formatted PVCs with standard mount options and single-volume journal paths, incurring high filesystem journaling write amplification. |
| Sharded Cluster Architecture (mongos Routers & Config Servers) | Deploys distributed sharded clusters with dedicated Config Server replica sets, stateless mongos deployment pools with HPA, and zone-aware chunk balancing. | Runs monolithic single-replica sets beyond 4TB working sets due to operational fear of managing Kubernetes sharding CRDs. | Co-locates mongos query routers and mongod data pods on the same nodes without CPU requests/limits, causing severe CPU contention. | Deploys mongos routers as stateful pods with improper DNS resolution, causing connection drops and random routing timeouts across services. |
| PodDisruptionBudgets (PDB) & Rolling Upgrades | Enforces strict PodDisruptionBudgets (minAvailable: 2) with automated stepDown pre-stop hooks, so cluster autoscaling and node drains cause only brief, planned primary step-downs. | Upgrades nodes manually with kubectl delete pod, triggering unexpected primary elections and breaking in-flight transactions. | Schedules wide maintenance outage windows, cordoning and draining nodes simultaneously without verifying replica set election health. | Omits PDBs completely, allowing Kubernetes cluster upgrades (e.g., EKS/GKE control plane upgrades) to terminate all mongod pods at once. |
| Kubernetes Automated Backups, S3 Snapshots & Oplog PITR | Deploys automated Percona Backup for MongoDB (PBM) or Ops Manager sidecars with continuous oplog streaming to S3/GCS and automated point-in-time recovery testing. | Runs unmonitored cron jobs executing mongodump inside a container, lacking continuous oplog streaming or point-in-time recovery capabilities. | Relies on generic Kubernetes CSI volume snapshots without flushing WiredTiger dirty pages, producing crash-inconsistent corrupted restores. | Stores backups on local ephemeral node storage or neglects automated backup verification entirely, discovering unrecoverable dumps during incidents. |
Critical Kubernetes Outage Modes We Eliminate
Running mission-critical stateful document databases on Kubernetes introduces complex failure domains. Node drains without disruption budgets, cloud CSI volume detachment deadlocks, and WiredTiger cache memory miscalculations create catastrophic outages. Our DBREs mitigate these critical breakdown modes:
Node Eviction Breaking Replica Set Quorum & Forcing Election Loops
Unscheduled node drains, spot instance preemptions, or memory pressure evict multiple MongoDB pods simultaneously without respect for replica set voting majority. Surviving secondaries cannot establish a quorum, resulting in continuous primary election loops and persistent write unavailability.
JusDB provisions PodDisruptionBudgets (minAvailable: 2), applies zone-aware hard anti-affinity, configures preStop hooks with rs.stepDown(60), and enforces terminationGracePeriodSeconds >= 120s.
Kubernetes Volume Attachment Deadlock Stalling Primary Pod
When a node crashes or cordons, cloud CSI volume drivers (AWS EBS, GCP Persistent Disk) frequently retain volume attachments on the terminated host. The rescheduling primary pod becomes stuck in ContainerCreating with VolumeAttachment deadlock errors for 15+ minutes.
JusDB deploys dedicated local NVMe storage classes with local volume provisioners or configures automated force-detach CSI controller timeouts and volume health monitoring.
WiredTiger Cache Sizing Mismatch Triggering Container OOM Kill
Default mongod configuration allocates 50% of available host RAM minus 1GB to the WiredTiger cache. In Kubernetes, if container memory limits are set below host RAM or cgroup v2 limits are unread, mongod and background threads exceed container limits and are terminated by Linux OOM killer.
JusDB explicitly calibrates wiredTiger.engineConfig.cacheSizeGB to exactly 50% of the Kubernetes container memory request (not the host capacity), leaving headroom for connection threads and index builds.
Our Kubernetes DBREs execute non-blocking cluster inspection commands to verify operator reconcile phases, StatefulSet health, and replica set synchronization without disrupting active client sessions:
Inspects custom resource definition phase, controller reconcile status, pod node placement, IP assignments, and readiness probes.
# 1. Inspect MongoDB operator CRD phase, pod status, and node placement kubectl get mongodbcommunity,pods -n mongodb -o wide # 2. Verify PersistentVolumeClaim binding and storage class status kubectl get pvc,pv -n mongodb -l app.kubernetes.io/component=database
Audits member voting states, health indicators, replication optime timestamps, and heartbeat latency directly within the container runtime.
# 1. Audit replica set election health, primary assignment, and member optime kubectl exec -it -n mongodb example-mongodb-0 -- mongosh --eval "rs.status()" | grep -E "(name|stateStr|health|optimeDate)" # 2. Check replication lag between primary and secondary members kubectl exec -it -n mongodb example-mongodb-0 -- mongosh --eval "rs.printSecondaryReplicationInfo()"
MongoDB on Kubernetes — Frequently Asked Questions
Common questions about running MongoDB on Kubernetes with operators, Helm charts, and production best practices.
Ready to Run MongoDB on Kubernetes?
Let our experts deploy and manage production MongoDB on Kubernetes with operator-driven automation, automated backups, and enterprise-grade monitoring.
Related MongoDB Services
Explore more ways our MongoDB consultants can help optimize your database infrastructure
Need a different MongoDB service? Browse our complete offerings.