This procedure migrates a sharded cluster that Ops Manager or Cloud Manager manages into Kubernetes under Kubernetes Operator, using the same live, incremental extend-promote-prune workflow as Migrate a Replica Set to Kubernetes. Follow that procedure, applying the differences described on this page. Where this page does not mention a step, it works the same as the replica set procedure.
Important
Sharded clusters with an embedded config server are not supported. Kubernetes Operator detects this topology and rejects the import.
External Members Cover Every Component
For a sharded cluster, spec.externalMembers is a single flat list covering every process: config server mongods, each shard's mongods, and the mongos routers. Every entry sets spec.externalMembers[].type, and every mongod entry also sets spec.externalMembers[].replicaSetName to identify whether the process belongs to the config server replica set or to a specific shard's replica set. For the full field reference, see MongoDB Migration Resource Settings.
Name Overrides Preserve the Automation Config Names
The kubectl mongodb migrate-to-mck plugin sets spec.configServerNameOverride and spec.shardNameOverrides so that Kubernetes Operator extends the existing config server and shard replica sets instead of creating new ones. The plugin also sets the Kubernetes-side member counts to 0.
Extend Uniformly or Per Shard
You can extend a sharded cluster into Kubernetes in two ways:
Uniformly, by raising the per-component counts
spec.mongodsPerShardCount,spec.configServerCount, andspec.mongosCount. Use this when every shard receives the same number of Kubernetes members.Per shard, using
spec.shardOverridesentries that name the shard and set its member count, either directly or inclusterSpecList[]. Use this when shards are sized differently, when you migrate shard by shard, or when a shard needs its own member layout.Note
spec.shardOverrides[].memberConfigat the entry's top level is ignored. The nestedspec.shardOverrides[].clusterSpecList[].memberConfigis the one that applies.Do not confuse
spec.shardOverrides(per-shard configuration) withspec.shardNameOverrides(automation config replica set naming). The two settings are unrelated.
As with the replica set procedure, hand-write memberConfig for every new Kubernetes member on the relevant component before you raise its count:
Warning
Set spec.memberConfig before you raise the member count
By default, new Kubernetes members join as voting members. The CRD defaults are votes: 1 and priority: "1", which let a still-syncing member participate in an election before it has finished its initial sync.
MongoDB recommends that you write one spec.memberConfig entry per new Kubernetes member with votes: 0 and priority: "0" before you raise the member count, so that a still-syncing member cannot win an election. votes is an integer. priority is a string.
TLS Certificates Per Component
Issue one certificate per component, using the naming pattern for each: <name>-config-* for the config server, <name>-<i>-* for each shard, and <name>-mongos-* for the mongos routers.
Extend and Prune One Component at a Time
There is no required order for extending or pruning the config server, shards, or mongos routers. Extend or prune exactly one component at a time, and wait for goal state before you move to the next component or the next entry.
Status Conditions and Verification
Status conditions and reasons work the same as for a replica set, computed from an override-aware member total across all components. kubectl wait --for=condition=Migrating=False is valid for a sharded cluster migration.
Verify the migration through a mongos Pod, not a shard member.