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.
Importante
Los clústeres fragmentados con un servidor de configuración integrado no son compatibles. Kubernetes Operator detecta esta topología y rechaza la importación.
Los miembros externos cubren todos los componentes.
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.
Las anulaciones de nombres conservan los nombres de configuración de automatización.
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.
Extienda uniformemente o por fragmento.
Puedes extender un clúster fragmentado a Kubernetes de dos maneras:
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.Nota
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:
Advertencia
Establezca spec.memberConfig antes de aumentar el número de miembros.
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.
Certificados TLS por componente
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.
Extiende y poda un componente a la vez.
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.
Condiciones de estado y verificación
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.