Navigation

Modify Ops Manager or MongoDB Kubernetes Resource Containers

You can modify the containers in the pods in which Ops Manager and MongoDB database resources run using the template or podTemplate setting that applies to your deployment:

To review which fields you can add to a template or a podTemplate, see the Kubernetes documentation.

When you create containers with a template or podTemplate, the Kubernetes Operator handles container creation differently based on the name you provide for each container in the containers array:

  • If the name field matches the name of the applicable resource image, the Kubernetes Operator updates the Ops Manager or MongoDB database container in the pod to which the template or podTemplate applies:
    • Ops Manager: mongodb-enterprise-ops-manager
    • Backup Daemon Service: mongodb-backup-daemon
    • MongoDB database: mongodb-enterprise-database
    • Application Database: mongodb-enterprise-appdb
  • If the name field does not match the name of the applicable resource image, the Kubernetes Operator creates a new container in each pod to which the template or podTemplate applies.

Define a Volume Mount for a MongoDB Kubernetes Resource

On-disk files in containers in pods don’t survive container crashes or restarts. Using the spec.podSpec.podTemplate setting, you can add a volume mount to persist data in a MongoDB database resource for the life of the pod.

To create a volume mount for a MongoDB database resource:

  1. Update the MongoDB database resource definition to include a volume mount for containers in the database pods that the Kubernetes Operator creates.

    Example

    Use spec.podSpec.podTemplate to define a volume mount:

    podSpec:
      podTemplate:
        spec:
          containers:
          - name: mongodb-enterprise-database
            volumeMounts:
            - mountPath: </new/mount/path>
              name: survives-restart
          volumes:
          - name: survives-restart
            emptyDir: {}
    
  2. Apply the updated resource definition:

    kubectl apply -f <database-resource-conf>.yaml -n <namespace>
    

Tune MongoDB Kubernetes Resource Docker Images with an InitContainer

MongoDB Kubernetes resource Docker images run on Ubuntu and use Ubuntu’s default system configuration. To tune the underlying Ubuntu system configuration in the MongoDB Kubernetes resource containers, add a privileged InitContainer init container using one of the following settings:

Example

MongoDB database resource Docker images use the Ubuntu default keepalive time of 7200. MongoDB recommends a shorter keepalive time of 120 for database deployments.

You can tune the keepalive time in the database resource Docker images if you experience network timeouts or socket errors in communication between clients and the database resources.

To tune Docker images for a MongoDB database resource container:

  1. Update the MongoDB database resource definition to append a privileged InitContainer to the database pods that the Kubernetes Operator creates.

    Example

    Change spec.podSpec.podTemplate the keepalive value to the recommended value of 120:

    spec:
      podSpec:
        podTemplate:
          spec:
            initContainers:
            - name: "adjust-tcp-keepalive"
              image: "busybox:latest"
              securityContext:
                privileged: true
              command: ["sysctl", "-w", "net.ipv4.tcp_keepalive_time=120"]
    
  2. Apply the updated resource definition:

    kubectl apply -f <database-resource-conf>.yaml -n <namespace>
    

Kubernetes adds a privileged InitContainer to each pod that the Kubernetes Operator creates using the MongoDB Kubernetes resource definition.

Open a shell session to a running container in your database resource pod and verify your changes.

Example

To follow the previous keepalive example, invoke the following command to get the current keepalive value:

> kubectl exec -n <namespace> -it <pod-name> -- cat /proc/sys/net/ipv4/tcp_keepalive_time


> 120

See also

Operating System Configuration in the MongoDB Manual.