Release of MCK 1.4.0

We are excited to announce the release of the MongoDB Controller for Kubernetes (MCK) 1.4, which introduces the Public Preview of Search and Vector Search for use with self-managed MongoDB Enterprise Server deployments.

This release brings powerful, proven search capabilities from MongoDB Atlas directly to your self-managed environments, enabling you to build, test, and run modern, AI-powered applications on your own infrastructure. You can now eliminate the architectural complexity and operational overhead of managing separate search systems or standalone vector databases.

New Features: Search & Vector Search (Public Preview)

This public preview is the first milestone in bringing fully integrated full-text and vector search to your enterprise deployments.

• MongoDB Enterprise Server Support: This preview is compatible with MongoDB Enterprise Server version 8.0.10+ and is intended for testing, evaluation, and feedback.
• Flexible Topologies: The search process (mongot) must run in Kubernetes, but your database cluster (mongod) can run on your existing infrastructure—either inside the same Kubernetes cluster or on external VMs and bare-metal servers. This allows you to adopt powerful search features without needing to migrate your current database workloads.
• Replica Set Support: The initial preview supports deployments running as replica sets.
• Secure Connectivity: All communication between the mongod and mongot processes can be secured using TLS encryption.

Coming Soon

This release is the first in a series of incremental updates planned through the end of 2025. While it already delivers important functionality, several key enhancements are on our short-term roadmap, including:

• Support for sharded clusters.
• High availability via multiple mongot instances.
• Support for gRPC and mTLS.

Learn More

• Check out the public preview documentation for setup and configuration details
• Read our blog post for a deep dive into this release and its capabilities

Release of MCK 1.3.0

MCK 1.3.0 Release Notes

New Features

Multi-Architecture Support

The Kubernetes Operator now supports deployment on multiple CPU architectures, allowing for greater flexibility in your environment. Current supported architectures:

• ARM64 (arm64)
• IBM Power (ppc64le)
• IBM Z (s390x)
• Intel/AMD (x86_64) (existing)

Affected Components: Multi-architecture support has been enabled for all core container images, including the operator, agent, init containers, database, and readiness probe. The container runtime will automatically pull the correct image for your node's architecture.

Important Limitation: Please note that Ops Manager and the init-ops-manager image are not included in this update.

Additionally:

• MongoDB Agent images have been migrated to new container repository: quay.io/mongodb/mongodb-agent.
  • the agents in the new repository will support the x86-64, ARM64, s390x, and ppc64le architectures. More can be read in the public docs.
  • operator running >=MCK1.3.0 and static cannot use the agent images from the old container repository quay.io/mongodb/mongodb-agent-ubi.
• quay.io/mongodb/mongodb-agent-ubi should not be used anymore, it's only there for backwards compatibility.

Bug Fixes

• We've fixed the current complex and difficult-to-maintain architecture for stateful set containers, which relies on an "agent matrix" to map operator and agent versions which led to a sheer amount of images.
• We've shifted to a 3-container setup. This new design eliminates the need for the operator-version/agent-version matrix by adding one additional container containing all required binaries. This architecture maps to what we already do with the mongodb-database container.
• Fixed an issue where the readiness probe reported the node as ready even when its authentication mechanism was not in sync with the other nodes, potentially causing premature restarts.
• Fixed an issue where the MongoDB Agents did not adhere to the NO_PROXY environment variable configured on the operator.
• Changed webhook ClusterRole and ClusterRoleBinding default names to include the namespace. This ensures that multiple operator installations in different namespaces don't conflict with each other.

Other Changes

• Optional permissions for PersistentVolumeClaim moved to a separate role. When managing the operator with Helm it is possible to disable permissions for PersistentVolumeClaim resources by setting operator.enablePVCResize value to false (true by default). When enabled, previously these permissions were part of the primary operator role. With this change, permissions have a separate role.
• subresourceEnabled Helm value was removed. This setting used to be true by default and made it possible to exclude subresource permissions from the operator role by specifying false as the value. We are removing this configuration option, making the operator roles always have subresource permissions. This setting was introduced as a temporary solution for this OpenShift issue. The issue has since been resolved and the setting is no longer needed.
• We have deliberately not published the container images for OpsManager versions 7.0.16, 8.0.8, 8.0.9 and 8.0.10 due to a bug in the OpsManager which prevents MCK customers to upgrade their OpsManager deployments to those versions.

Release of MCK 1.2.0

MCK 1.2.0 Release Notes

New Features

OpenID Connect (OIDC) user authentication

Adds support for OpenID Connect (OIDC) user authentication.

• You can configure OIDC authentication with the spec.security.authentication.modes=OIDC and spec.security.authentication.oidcProviderConfigs.
• Minimum MongoDB version requirements:
  • 7.0.11, 8.0.0
  • Only supported with MongoDB Enterprise Server
• For more information please see:
  • Secure Client Authentication with OIDC
  • Manage Database Users using OIDC
  • Authentication and Authorization with OIDC/OAuth 2.0

New ClusterMongoDBRole CRD

Adds new ClusterMongoDBRole CRD to support reusable roles across multiple MongoDB clusters. This allows users to define roles once and reuse them in multiple MongoDB or MongoDBMultiCluster resources.

• You can reference this role using the .spec.security.roleRefs field. Note that only one of .spec.security.roles and .spec.security.roleRefs can be used at a time.
• ClusterMongoDBRole resources are treated by the operator as a custom role templates that are only used when referenced by the database resources.
• The operator watches the new resource by default. This means that the operator requires you to create a new ClusterRole and ClusterRoleBinding. The helm chart or the kubectl mongodb plugin create these ClusterRole and ClusterRoleBindingby default. You must create them manually if you use a different installation method.
• The new ClusterMongoDBRole resource is designed to be read-only, meaning it can be used by MongoDB deployments managed by different operators.
• You can delete the ClusterMongoDBRole resource at any time, but the operator will not delete any roles that were created using this resource. To properly remove access, you must manually remove the reference to the ClusterMongoDBRole in the MongoDB or MongoDBMultiCluster resources.
• The reference documentation for this resource can be found here

Bug Fixes

• Fixed an issue where moving a MongoDBMultiCluster resource to a new project (or a new OM instance) would leave the deployment in a failed state.

Release of MCK 1.1.0

MCK 1.1.0 Release Notes

New Features

• MongoDBSearch (Community Private Preview): Added support for deploying MongoDB Search (Community Private Preview Edition) that enables full-text and vector search capabilities for MongoDBCommunity deployments.
  • Added new MongoDB CRD which is watched by default by the operator.
    • For more information please see: docs/community-search/quick-start/README.md
  • Private Preview phase comes with some limitations:
    • minimum MongoDB Community version: 8.0.
    • TLS must be disabled in MongoDB (communication between mongot and mongod is in plaintext for now).

Release of MCK 1.0.1

MCK 1.0.1 Release Notes

Bug Fixes

• Fix missing agent images in the operator bundle in OpenShift catalog and operatorhub.io.
• MongoDBCommunity resource was missing from watched list in Helm Charts

Release of MCK 1.0.0

MCK 1.0.0 Release Notes

Exciting news for MongoDB on Kubernetes! We're happy to announce the first release of MongoDB Controllers for Kubernetes (MCK), a unified open-source operator merging our support of MongoDB Community and Enterprise in Kubernetes.

Acronyms

• MCK: MongoDB Controllers for Kubernetes
• MCO: MongoDB Community Operator
• MEKO: MongoDB Enterprise Kubernetes Operator

TL;DR:

• MCK: A unified MongoDB Kubernetes Operator, merging MCO and MEKO.
• This initial release provides the combined functionality of the latest MCO and MEKO so migration is seamless: no changes are required in your current deployments.
• No impact on current contracts or agreements.
• We are adopting Semantic Versioning (SemVer), so any future breaking changes will only occur in new major versions of the Operator.
• MCO End-of-Life (EOL): Support for MCO is best efforts, with no formal EOL for each version. For the last version of MCO, we will continue to offer best efforts guidance, but there will be no further releases.
• MEKO End-of-Life (EOL): No change to the current EOL for each individual MEKO version.

About the First MCK Release

MongoDB is unifying its Kubernetes offerings with the introduction of MongoDB Controllers for Kubernetes (MCK). This new operator is an open-source project and represents a merge of the previous MongoDB Community Operator (MCO) and the MongoDB Enterprise Kubernetes Operator (MEKO).

This release brings MongoDB Community and Enterprise editions together under a single, unified operator, making it easier to manage, scale, and upgrade your deployments. While the first version simply brings the capabilities of both into a single Operator, future changes will build on this to more closely align how Community and Enterprise are managed in Kubernetes, to offer an even more seamless and streamlined experience. As an open-source project, it now allows for community contributions, helping drive quicker bug fixes and ongoing innovation.

License

Customers with contracts that allowed use of the Enterprise Operator will still be able to leverage the new replacement, allowing customers to adopt it without contract changes. The Operator itself is licensed under the Apache 2.0, and a license file included in the repository provides further detail. License entitlements for all other MongoDB products and tools remain unchanged (for example Enterprise Server and Ops Manager) - if in doubt, contact your MongoDB account team.

Migration

Migration from MCO and MEKO to MCK is seamless: your MongoDB deployments are not impacted by the upgrade and require no changes. Simply follow the upgrade instructions provided in the MCK documentation. See our migration guidance.

Deprecation and EOL for MCO and MEKO

We will continue best efforts support of MCO for 6 months (until November, 2025), and versions of MEKO will remain supported according to the current current EOL guidance. All future bug fixes and improvements will be released in new versions of MCK. We encourage all users to plan their migration to MCK within these timelines.