Release of MCK 1.12.0

MCK 1.12.0 Release Notes

New Features

Ops Manager Backup with MCK

MCK-managed Ops Manager deployments can now use an externally managed Application Database (AppDB), enabling Ops Manager backup and disaster recovery for Kubernetes deployments.

To use this capability, configure MongoDBOpsManager.spec.externalApplicationDatabaseRef to reference a standard MongoDB resource with spec.role: AppDB. MCK transfers ownership of the existing AppDB StatefulSet and Persistent Volumes to the MongoDB resource without copying or recreating the AppDB data.

This makes the AppDB available to the same MongoDB backup, monitoring, and lifecycle tooling used for the rest of the deployment. Existing Ops Manager deployments can use the forward-migration procedure; new deployments can use the external AppDB from the start, and the configuration can be reversed when needed.

The initial release supports single-cluster AppDB deployments referenced with kind: MongoDB. Multi-cluster AppDB support is not included in this release.

For a complete Ops Manager disaster-recovery setup, configure the external AppDB with a separate management (or “Meta”) Ops Manager. Do not configure the external AppDB to use the same Ops Manager instance that uses it as its AppDB.

This feature covers the AppDB and the Ops Manager backup metadata databases. Preserve the Ops Manager application configuration, gen.key, and other required host and agent configuration with your existing file-backup process.

For supported AppDB configuration, migration procedures, backup and restore setup, and known limitations, see [LINK DOCUMENTATION].

Configuration changes

• Added spec.externalApplicationDatabaseRef to MongoDBOpsManager.
• Added spec.role: AppDB to MongoDB resources.
• Added Fresh Start, Forward Migration, and Reverse Migration procedures for managing AppDB ownership.

Migration into Kubernetes

Customers can now move existing Ops Manager or Cloud Manager-managed replica sets or sharded clusters (such as those on VMs, bare-metal, or Kubernetes) into one or multiple Kubernetes clusters without downtime. The goal is to create a simpler path to adopt Kubernetes for existing on-prem MongoDB workloads. The migration would be considered successful once the Kubernetes Operator (MCK) manages 100% of the deployment members, there are no active members in the previous infrastructure and all data resides in PersistentVolumeClaims within the Kubernetes clusters.

This happens by letting a resource span both VM and Kubernetes members while members are moved across.

• spec.externalMembers (and the per-tier spec.{mongos,configSrv,shard}.externalMembers equivalents for sharded clusters) declare the members still running on VMs, so the operator includes them in the Ops Manager automation config, in generated connection strings and in MongoDB Search host seeds.
• To expose Sharded Clusters externally to be reachable by the external members, there are new fields for configuring external access and external domain per component: spec.mongos.externalAccess, spec.shard.externalAccess, spec.configSrv.externalAccess. The top level spec.externalAccess is unchanged and will only expose mongos.
• To assist with onboarding applications to the migrated cluster, a credential-less connection string secret is now generated for any MongoDB resource with name <metadata.name>-cluster-connection-string. This connection string is kept up to date with the active members including the new members in Kubernetes as well as the external members.
• Setting the mongodb.com/migration-dry-run annotation runs a connectivity validation Job that checks every external member is reachable from inside the cluster before anything is changed. The resource reports progress through status.migration and its conditions.
• kubectl mongodb migrate-to-mck generates the MongoDB and MongoDBUser resources for an existing Ops Manager deployment (replica set or sharded cluster), including TLS, authentication and Prometheus settings, and validates that the source deployment can be represented before writing anything.

The detailed process can be found in [LINK DOCUMENTATION].

Bug Fixes

• MongoDB (replica sets and sharded clusters): The connectionString.standardSrv value now uses spec.externalAccess.externalDomain when one is configured, so clients outside the cluster can use it. Previously it always returned the internal *.svc.cluster.local service FQDN, which is not reachable from outside. Provisioning the _mongodb._tcp SRV records in that zone is your responsibility, as it already is for the A records externalAccess depends on. For MongoDBMultiCluster resources, only a top-level spec.externalAccess.externalDomain is used; per-cluster externalDomain values in clusterSpecList are not yet honoured when building the SRV connection string.
• MongoDBOpsManager: MongoDBOpsManager resource now fails reconciliation, when the secret referenced by the field spec.applicationDatabase.passwordSecretKeyRef does not exist, instead of silently generating a random password.
• MongoDB: The validating webhook now rejects adding, changing or removing an external domain on an already deployed resource. This covers spec.externalAccess.externalDomain, the per-tier spec.{mongos,configSrv,shard}.externalAccess.externalDomain fields and their per-member-cluster equivalents in clusterSpecList. Any of these transitions repoints existing members at new hostnames, which is unsupported and will lead to a Failed resource.
• MongoDBMultiCluster: Fixed a bug where the connection string Secret generated for MongoDBUser resources referencing a MongoDBMultiCluster always used internal svc.cluster.local hostnames, ignoring the externalAccess.externalDomain configured per cluster or at the top level. The connection string now uses the configured external domains, matching the hostnames registered in Ops Manager.
• MongoDBSearch: MongoDB resources with spec.externalAccess.externalDomain set are now rejected as a Search source; the MongoDBSearch resource enters the Failed phase with a clear error.