Release of MCK 1.3.0

MCK 1.3.0 Release Notes

New Features

Multi-Architecture Support

We've added comprehensive multi-architecture support for the kubernetes operator. This enhancement enables deployment on IBM Power (ppc64le) and IBM Z (s390x) architectures alongside
existing x86_64 support. Core images (operator, agent, init containers, database, readiness probe) now support multiple architectures. We do not add support IBM and ARM support for Ops-Manager and the init-ops-manager image.

• 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

• This change fixes 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 solve this by shifting 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.