Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes Operator
/ /

Container Images

On this page

  • Static Containers (Public Preview)
  • Architecture
  • Limitations
  • Migrate to Static Containers
  • Migrate to Non-Static Containers

When you install the Kubernetes Operator, it pulls the images from the Quay.io container registry. The Kubernetes Operator images are based on the Red Hat UBI 8 operating system. MongoDB rebuilds Kubernetes Operator images daily for the latest operating system and supporting library updates.

Official images provide the following advantages:

  • They are rebuilt daily for the latest upstream vulnerability fixes.

  • MongoDB tests, maintains, and supports them.

To view all available versions for each image, see the following links.

Image Name
Description
mongodb-agent-ubi
MongoDB Agent image.
The Enterprise MongoDB image used for static containers and the Application Database.
initContainer image that contains the Application Database start-up scripts and the readiness probe.
MongoDB Database environment image used for non-static containers. To learn about static and non-static containers, see Static Containers (Public Preview).
initContainer image that contains the MongoDB Agent start-up scripts and the readiness probe.
Ops Manager image.
initContainer image that contains the Ops Manager start-up scripts and the readiness probe.

Static containers are more secure and simpler than non-static containers. Static containers are immutable at runtime. In addition:

  • While running, static containers can't download binaries or run scripts or other utilities over network connections. Static containers can only download runtime configuration files.

  • While running, static containers can't modify any file except storage volume mounts.

  • Static containers don't require that you scan the containers for security vulnerabilities, as opposed to non-static containers that require container security scanning. If you use static containers, you can only run security scans on the container images themselves but not on their containers.

  • If you have an air-gapped environment, static containers don't require that you host the MongoDB binary on the server that hosts Ops Manager or another HTTPS server.

  • You can't run extensive CMD scripts for the static container.

  • You can't copy files between static containers using initContainer.

Starting with MongoDB Enterprise Kubernetes Operator 1.25, you can use the Public Preview of static containers instead of the existing non-static containers that download the MongoDB binary from Cloud Manager or Ops Manager or the Internet at runtime. You can use the following procedures to enable or disable static containers for all or individual MongoDB deployments.

Static containers use the image from the mongodb-enterprise-server Quay.io repository.

The architecture of static and non-static containers differs significantly and requires several steps to migrate from one to the other. To learn more, see Migrate to Static Containers and Migrate to Non-Static Containers.

The default non-static container architecture assumes you bootstrap an empty-shell container, download and start the MongoDB Agent, which then downloads the binaries for mongod and mongosh from Cloud Manager or Ops Manager.

Diagram showing the high-level architecture of a MongoDB deployment with
non-static containers configured using the MongoDB Enterprise Kubernetes Operator.
click to enlarge

The static container architecture uses Kubernetes' shared namespace feature to run the MongoDB Agent as a separate process so it can control the full mongod lifecycle and avoid downloading files over a network.

Static containers are more secure and simpler than non-static containers. Static containers are immutable at runtime. In addition:

  • While running, static containers can't download binaries or run scripts or other utilities over network connections. Static containers can only download runtime configuration files.

  • While running, static containers can't modify any file except storage volume mounts.

  • Static containers don't require that you scan the containers for security vulnerabilities, as opposed to non-static containers that require container security scanning. If you use static containers, you can only run security scans on the container images themselves but not on their containers.

  • If you have an air-gapped environment, static containers don't require that you host the MongoDB binary on the server that hosts Ops Manager or another HTTPS server.

  • You can't run extensive CMD scripts for the static container.

  • You can't copy files between static containers using initContainer.

Diagram showing the high-level architecture of a MongoDB deployment with
static containers configured using the MongoDB Enterprise Kubernetes Operator.
click to enlarge

If you enable static containers:

  • You must Disable Queryable Backups so the Backup Daemon Service doesn't attempt to download the MongoDB binaries from Ops Manager, which undermines the immutable nature of static containers.

  • With Ops Manager, only versions 6.0.24, 7.0.5, or later are compatible. The Kubernetes Operator automatically uses the correct version of the MongoDB Agent container based on the Ops Manager version you select to manage a specific deployment.

  • With MongoDB Cloud Manager, your MongoDB Agent version could fall behind compatibility with the latest version of MongoDB Cloud Manager because the Kubernetes Operator can't call the agentVersion endpoint in MongoDB Cloud Manager. To ensure your MongoDB Agent is up to date with MongoDB Cloud Manager, you can perform one of the following actions:

    • Specify a compatible MongoDB Agent version in the MongoDB resource specification by overriding the StatefulSet container image for the MongoDB Agent. For example:

      podSpec:
      podTemplate:
      spec:
      containers:
      - name: mongodb-agent-ubi
      Image: 12.0.29.7785-1_1.24.0
    • Upgrade the Kubernetes Operator to the latest version, which automatically updates the MongoDB Agent.

  • Upgrading a MongoDB version triggers a rolling restart of all Pods, in order of last to first, and could cause more elections, up to the number of Pods. This is true of any updates that trigger a rolling restart.

  • You won't be able to determine whether a MongoDB database upgrade happened from the MongoDB Agent's status. When Kubernetes rotates Pods following an upgrade, the MongoDB Agent replaces the health status file so you can't tell from the health status that a version change happened, only the current health status.

To migrate from non-static to static containers, set the MongoDB Agent environment variables and enable static containers by following the steps below. You can also enable static containers during installation or upgrade.

1
2

Follow the procedure in Disable Queryable Backups.

3

In your Kubernetes Operator configuration file, define the MDB_AGENT_IMAGE_REPOSITORY environment variable to specify the repository from which the Kubernetes Operator downloads the MongoDB Agent image for static containers.

In your Kubernetes Operator Helm chart, define registry.agent and agent.name to specify the repository from which the Kubernetes Operator downloads the MongoDB Agent image for static containers.

4

After saving the changes, reapply your configuration.

If you use Kubernetes without OpenShift, run:

kubectl apply -f mongodb-enterprise.yaml

If you use Kubernetes with OpenShift:

oc apply -f mongodb-enterprise-openshift.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \
--set registry.pullPolicy='IfNotPresent'

This initiates a rolling restart of all Pods in your deployment.

5

Select the appropriate tab below to enable static containers for all your MongoDB deployments at once, including existing deployments, or one deployment at a time.

In your Kubernetes Operator configuration file, set MDB_DEFAULT_ARCHITECTURE or operator.mdbDefaultArchitecture to static.

In the MongoDB resource specification for a specific deployment, set the metadata.annotations.mongodb.com/v1.architecture annotation to static.

6

After saving the changes, reapply your configuration.

If you use Kubernetes without OpenShift, run:

kubectl apply -f <my-config-file>.yaml

If you use Kubernetes with OpenShift:

oc apply -f <my-config-file>.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \
--set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"

The Kubernetes Operator updates the StatefulSet images for your MongoDB deployment, transitioning from a single container that previously managed both the MongoDB Agent and MongoDB database, to a new configuration with two separate containers: one for the MongoDB Agent and another for the MongoDB database. This update initiates a rolling restart.

To migrate from static to non-static containers, disable static containers by following the steps below. You can also disable static containers during installation or upgrade.

1

Select the appropriate tab below to disable static containers for all your MongoDB deployments at once, including existing deployments, or one deployment at a time.

In your Kubernetes Operator configuration file, set MDB_DEFAULT_ARCHITECTURE or operator.mdbDefaultArchitecture to non-static.

In the MongoDB resource specification for a specific deployment, set the metadata.annotations.mongodb.com/v1.architecture annotation to non-static.

2

After saving the changes, reapply your configuration.

If you use Kubernetes without OpenShift, run:

kubectl apply -f <my-config-file>.yaml

If you use Kubernetes with OpenShift:

oc apply -f <my-config-file>.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \
--set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="non-static"

The Kubernetes Operator replaces the StatefulSet images of your MongoDB deployment and initiates a rolling restart of all Pods in your deployment.

Back

Compatibility

Next

Single- or Multi-Kubernetes Clusters