From Manual to Automated: MongoDB on Kubernetes

Deploying MongoDB on Kubernetes brings scalability, automation, and resilience—but it also demands careful design to handle stateful workloads. This guide takes you through the complete journey: understanding the manual deployment process, its complexities, and then discovering how the MongoDB Controllers for Kubernetes (MCK) eliminates all that complexity.

Note: MongoDB Controllers for Kubernetes is the unified operator that combines the capabilities of the former MongoDB Community Operator and MongoDB Enterprise Kubernetes Operator into a single solution.

Why Running MongoDB on Kubernetes Requires Special Consideration?

Stateless apps, APIs, frontends, and microservices are a natural fit for Kubernetes. They can be restarted, rescheduled, or replicated freely without worrying about local data.

MongoDB is different. It's a stateful database that depends on:

• Persistent storage to ensure data integrity.
• Stable identity across replica members.
• Predictable communication to maintain the replica set quorum.

Kubernetes, by default, was designed for ephemeral workloads, not databases that care about state consistency. To deploy MongoDB effectively, you must teach Kubernetes how to manage state predictably, without breaking its automation model.

The challenge isn't just running MongoDB on Kubernetes; it's keeping it resilient, predictable, and operationally efficient while managing all the complexity manually.

1. Traditional Manual Approach

Let's first understand what it takes to deploy MongoDB on Kubernetes manually. This will help you appreciate the complexity involved and understand exactly what automation solves.

1.1 Create StatefulSets for Predictable Identity

StatefulSets are the foundation for running stateful workloads. They provide fixed pod identities (mongodb-0, mongodb-1, mongodb-2) and automatically bind each pod to its own persistent volume. Without this, pods would get random names upon restart, breaking the replica set configuration.

//yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongodb
spec:
serviceName: "mongodb"
  replicas: 3
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
  spec:
      containers:
        - name: mongod
          image: mongo:7.0
          command: ["mongod", "--replSet", "rs0", "--bind_ip_all"]
  ports:
            - containerPort: 27017
          volumeMounts:
            - name: data
              mountPath: /data/db
   volumeClaimTemplates:
    - metadata:
        name: data
   spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

1.2 Configure Persistent Storage

Each pod needs its own PersistentVolumeClaim (PVC). You must manually:

• Define appropriate storage classes.
• Size volumes correctly.
• Ensure volumes survive pod failures.
• Handle storage expansion when needed.

1.3 Set up Headless Services for Replica Communication

MongoDB replicas need to communicate directly with each other, not through load balancers. This requires a headless service, defined with clusterIP: None.

This allows each pod to get its own DNS record:

//yaml

apiVersion: v1
kind: Service
metadata:
  name: mongodb
spec:
  clusterIP: None
  selector:
    app: mongodb
  ports:
    - port: 27017

This creates predictable DNS names:

• mongodb-0.mongodb
• mongodb-1.mongodb
• mongodb-2.mongodb

1.4 Manually Initialize the Replica Set

Once all pods are running, you must manually connect to the primary and initialize the replica set:

kubectl exec -it mongodb-0 -- mongosh --eval 'rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongodb-0.mongodb:27017" },
    { _id: 1, host: "mongodb-1.mongodb:27017" },
    { _id: 2, host: "mongodb-2.mongodb:27017" }
  ]
})'

Check the status:

kubectl exec -it mongodb-0 -- mongosh --eval 'rs.status()'

1.5 Configure Security Manually

Security requires multiple manual steps:

• Create admin users with proper passwords.
• Enable authentication by updating the StatefulSet with auth flags.
• Configure TLS certificates for encrypted communication.
• Set up SCRAM authentication.
• Manage secrets in Kubernetes.

1.6 Implement High Availability Features

For production resilience, you need to manually configure:

• Pod Anti-Affinity to spread replicas across nodes.
• Pod Disruption Budgets to prevent simultaneous restarts.
• Readiness and Liveness Probes to monitor pod health.

1.7 Handle Upgrades Manually

Upgrading MongoDB versions requires careful orchestration:

• Verify replica set health before starting.
• Update secondary members first, one at a time.
• Step down the primary to elect a new one.
• Upgrade the former primary.
• Monitor replication lag throughout.
• Roll back if issues occur.

1.8 Set up Monitoring and Backup

Production deployments need monitoring with manual metric collection and backup automation with CronJobs. This requires creating and maintaining custom scripts and Kubernetes CronJob resources.

1.9 Handle Scaling Operations

To add or remove replica set members:

• Scale the StatefulSet.
• Manually add new members to the replica set.
• Wait for synchronization.
• Update connection strings in applications.
• Rebalance data if using sharding.

1.10 Implement Sharding (if needed)

For horizontal scaling with sharding, the complexity multiplies:

• Deploy Config Server Replica Set (three members minimum)
• Deploy Multiple Shard Replica Sets
• Deploy mongos Routers
• Configure shard zones
• Manage chunk migrations
• Handle balancer configuration

Each component needs its own StatefulSet, Service, and configuration.

The Problems with Manual Management

After seeing all these steps, the challenges become clear:

• Complexity: dozens of manual steps, each prone to human error
• Time investment: hours or days to set up properly
• Operational overhead: constant manual intervention for upgrades, scaling, and maintenance
• Inconsistency: different teams might implement differently
• Recovery difficulty: manual disaster recovery is slow and error-prone
• Knowledge requirements: deep expertise needed in both MongoDB and Kubernetes
• Configuration drift: environments diverge over time
• Upgrade risk: manual upgrades are dangerous and time-consuming

2. Modern Solution: MongoDB Controllers for Kubernetes (MCK)

After understanding the complexity of manual deployment, you'll appreciate what the MongoDB Controllers for Kubernetes (MCK) brings to the table. It automates most of the manual steps above, reducing a multi-day deployment to minutes.

MCK is a unified operator that supports both MongoDB Community and MongoDB Enterprise deployments:

2.1 For MongoDB Community Edition:

• Manages replica sets
• Handles user creation and SCRAM authentication
• Custom role management
• Prometheus metrics integration
• Automated scaling and upgrades

2.2 For MongoDB Enterprise Advanced:

All Community features plus:

• Full backup and restore capabilities
• Advanced monitoring and alerting
• Point-in-time recovery
• Sharded cluster support
• Multi-cluster deployments

2.3 What the Operator Automates

The MCK handles:

• StatefulSet creation: automatically creates properly configured StatefulSets
• Replica set initialization: no manual rs.initiate() needed
• Security setup: auto-generates users, passwords, TLS certificates
• High availability: configures anti-affinity, PDBs, and probes
• Automated upgrades: safe, rolling updates with automatic rollback
• Health monitoring: detects and repairs unhealthy members
• Backup management: scheduled backups with point-in-time recovery
• Scaling operations: automatically adds/removes replica members
• Configuration management: prevents drift with declarative configs
• Disaster recovery: automated failover and recovery procedures

2.4 Declarative Management

Instead of executing dozens of manual steps, you define your desired state in a single YAML file:

// yaml

apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: production-mongodb
spec:
  type: ReplicaSet
  members: 3
  version: "7.0.3"
  security:
    authentication:
      modes: ["SCRAM"]
    tls:
      enabled: true
      certificateKeySecretRef:
        name: mongodb-tls
  users:
    - name: appuser
      db: myapp
      passwordSecretRef:
        name: app-user-password
      roles:
        - name: readWrite
          db: myapp
  backup:
    enabled: true
    schedule: "0 3 * * *"
  statefulSet:
    spec:
      volumeClaimTemplates:
        - metadata:
            name: data-volume
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 100Gi

The Operator reads this specification and automatically creates all Kubernetes resources, initializes the replica set, sets up authentication and TLS, configures high availability features, implements backup schedules, monitors health continuously, and handles failures and recovery.

3. Installing MongoDB Controllers for Kubernetes

This is a one-time setup for your cluster. Once installed, you can deploy multiple MongoDB instances using the Operator.

3.1 Prerequisites

• kubectl installed and configured
• Helm 3.x installed
• A Kubernetes cluster (Minikube, Kind, or production cluster)
• Cluster admin permissions

3.2 Installation Steps

Step 1: Add the MongoDB Helm repository

helm repo add mongodb https://mongodb.github.io/helm-charts

helm repo update

Step 2: Create a dedicated namespace for the Operator

kubectl create namespace mongodb-operator

Step 3: Install the MongoDB Kubernetes Operator

helm install community-operator mongodb/community-operator \

--namespace mongodb-operator \

--create-namespace

Step 4: Verify the installation

kubectl get pods -n mongodb-operator

You should see the Operator pod running. The installation is now complete and ready to manage MongoDB deployments.

3.3 Hands-on Lab: Deploy MongoDB with the Operator

Now that the Operator is installed, let's deploy a MongoDB replica set in minutes.

Step 1: Prepare your environment

If using Minikube for this lab:

minikube start --cpus=2 --memory=4096

kubectl create namespace demo

Step 2: Create security credentials

Create a Kubernetes secret for the MongoDB admin password:

kubectl create secret generic admin-secret -n demo \

--from-literal=password='DemoPass123'

Step 3: Deploy MongoDB cluster

Create a MongoDB resource definition:

cat <<EOF | kubectl apply -n demo -f -
apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: demo-mongodb
spec:
  type: ReplicaSet
  members: 3
  version: "7.0.3"
  security:
    authentication:
      modes: ["SCRAM"]
  users:
    - name: admin
      db: admin
      passwordSecretRef:
        name: admin-secret
      roles:
        - name: root
          db: admin
  statefulSet:
    spec:
      volumeClaimTemplates:
        - metadata:
            name: data
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 1Gi
EOF

Step 4: Watch the magic happen

Monitor the deployment:

kubectl get pods -n demo -w

In minutes, you have a fully configured, production-ready MongoDB replica set! The Operator automatically handled all the complexity we saw in the manual approach.

3.4 Automated Operations Examples

Upgrading MongoDB Version

Simply change the version in your YAML and apply:

// yaml

spec:

version: "7.0.5" # Changed from 7.0.3

The Operator performs a safe, rolling upgrade automatically.

Scaling the Replica Set

Just change the member count:

// yaml

spec:

members: 5 # Changed from 3

The Operator adds new members and reconfigures the replica set.

Enabling Backups

// yaml

spec:

backup:

enabled: true

schedule: "0 */6 * * *" # Every 6 hours

s3:

bucket: mongodb-backups

prefix: production

The Operator sets up automated backups without manual CronJob configuration.

4. Comparison: Manual vs Operator

5. What the Community Operator Actually Provides

The MongoDB Community Operator focuses on core deployment and management features. It's important to understand what it does and doesn't include:

5.1 Built-in Features

Deployment and Lifecycle Management

• Automated replica set deployment and initialization
• Rolling upgrades with zero downtime
• Automatic pod recovery and self-healing
• Declarative scaling of replica sets

Security Features

• SCRAM authentication configuration
• TLS/SSL certificate management
• User and role management
• Integration with Kubernetes secrets

Monitoring Integration

The Operator can expose metrics endpoint for Prometheus monitoring:

// yaml

spec:

prometheus:

username: metrics-endpoint-user

passwordSecretRef:

name: metrics-endpoint-password

5.2 Features NOT included in Community Edition

The following features require MongoDB Enterprise Advanced and the Enterprise Operator:

• Automated backups: built-in backup scheduling and management (Community requires custom solutions)
• Point-in-time recovery: restore to specific timestamps
• Ops manager integration: advanced monitoring and alerting
• Sharded clusters: automatic sharding configuration and management
• Multi-Kubernetes cluster: cross-cluster deployments

Community Workarounds

For features not included in the Community Operator, you can implement your own solutions:

• Backups: Use Kubernetes CronJobs with mongodump/mongorestore.
• Monitoring: Deploy Prometheus and MongoDB Exporter separately.
• Sharding: Manually deploy config servers, shards, and mongos routers.

GitOps Integration

The declarative nature of the Operator makes it perfect for GitOps workflows:

• Store all MongoDB configurations in Git repositories.
• Use ArgoCD or Flux CD to automatically sync changes to your cluster.
• Track all infrastructure changes through Git history.
• Roll back easily by reverting Git commits.
• Maintain consistency across development, staging, and production environments.
• Monitoring and observability

The Operator exposes Metrics and Status Information for Monitoring:

# Check MongoDB cluster status

kubectl get mongodbcommunity -n production

# View detailed status

kubectl describe mongodbcommunity production-mongodb -n production

# Check Operator logs for issues

kubectl logs -n mongodb-operator deployment/mongodb-kubernetes-operator

5.3 Best Practices with the Operator

• Use Git for configuration management: Store all MongoDB resources in version control.
• Separate namespaces: Isolate environments (dev, staging, prod).
• Resource limits: Define CPU and memory limits in the StatefulSet spec.
• Monitoring: Deploy Prometheus ServiceMonitor for metrics.
• Backup testing: Regularly test backup restoration procedures.
• Security scanning: Scan container images before deployment.
• High availability: Deploy at least three replica members across different availability zones.
• Storage planning: Use fast storage classes (SSD) and monitor disk usage proactively.

5.4 Migration Path: From Manual to Operator

If you have existing manually-deployed MongoDB clusters, here's how to migrate:

• Take a complete backup of your current deployment using mongodump.
• Install the Operator in a new namespace.
• Create matching configuration in Operator format (YAML).
• Deploy the new Operator-managed cluster.
• Restore data to the Operator-managed cluster using mongorestore.
• Test thoroughly before switching traffic (connection strings, performance, failover).
• Update application connection strings to point to the new cluster.
• Monitor the new cluster for several days before decommissioning the old one.
• Decommission old manual deployment only after confirming stability.

6. Conclusion

Understanding the manual deployment process reveals the true complexity of running MongoDB on Kubernetes. The dozens of steps, configuration files, and operational procedures required for a production-ready deployment represent significant investment and ongoing maintenance burden.

The MongoDB Kubernetes Operator transforms this complexity into simplicity. What once took days of setup and ongoing manual intervention now takes minutes and runs itself. It's not just automation, it's a fundamental shift in how we manage stateful workloads on Kubernetes.

Key Takeaways:

• Manual deployment requires deep expertise and constant attention.
• The Operator automates ALL manual steps, plus adds self-healing.
• Declarative configuration ensures consistency and enables GitOps.
• Automated operations reduce risk and save countless hours.
• The complexity hasn't disappeared—it's been abstracted away.

Whether you're starting fresh or managing existing deployments, the MongoDB Kubernetes Operator represents the modern, production-ready approach to running MongoDB on Kubernetes. The manual approach taught us what needs to be done; the Operator ensures it's done right, every time, automatically.