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
Não são permitidos clusters fragmentados com um servidor de configuração incorporado. O Kubernetes Operator detecta esta topologia e rejeita a importação.
Membros externos abrangem todos os 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.
Substituições de nome preservam os nomes de configuração de automação
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.
Estender uniformemente ou por fragmento
Você pode estender um cluster fragmentado para o Kubernetes de duas maneiras:
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.Observação
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:
Aviso
Definir spec.memberConfig antes de aumentar a contagem de membros
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.
Estender e podar um componente por 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.
Condições de status e verificação
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.