Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

Configurar TLS para uma migração para o Kubernetes

When you migrate a TLS-enabled replica set from virtual machines into Kubernetes, one replica set is one trust domain. Issue the Kubernetes member certificates from the same certificate authority (CA) that signed the virtual machine certificates. This is the only migration-specific TLS requirement. The general TLS documentation for Kubernetes Operator covers everything else about configuring TLS. A CA mismatch fails the dry run, by design. To learn how the dry run surfaces that failure, see Validate Migration Readiness with a Dry Run.

Importante

Os campos nesta página existem apenas para migração. Não os defina em um sistema nova do Kubernetes Operator, a menos que a descrição do campo especifique o contrário.

To learn how to issue certificates, structure Secrets and ConfigMaps, and configure the general TLS settings on the MongoDB custom resource, see:

When you follow that documentation for a migration, issue the Kubernetes member certificates from the same CA that signed the virtual machine certificates, not from a new CA. The CA ConfigMap named <resourceName>-ca must contain a ca-pem key populated from that same CA.

Você precisa do seguinte:

  • O certificado de CA e o material de chave existentes do sistema de máquina virtual.

  • cert-manager ou uma ferramenta equivalente para emitir os certificados de membro do Kubernetes dessa mesma CA.

  • The generated MongoDB custom resource from Migrate a Replica Set to Kubernetes.

1

Siga Configurar uma integração do cert-manager ou Gerar X.509 Certificados de Cliente para criar o kubernetes.io/tls Secret chamado <certsSecretPrefix>-<resourceName>-cert, emitindo o certificado da mesma CA que assinou os certificados da máquina virtual.

Create the CA ConfigMap named <resourceName>-ca with a ca-pem key populated from that same CA.

Se você usar a autenticação do agente X.509, crie também o <certsSecretPrefix>-<resourceName>-agent-certs Secret e defina o spec.security.authentication.agents.clientCertificateSecretRef para referenciá-lo. Esse requisito se aplica somente à autenticação do agente , não à autenticação interna do cluster (spec.security.authentication.internalCluster).

2

Esses campos existem apenas para fazer com que a visão do Kubernetes Operator sobre os caminhos de arquivo corresponda à forma como o sistema da máquina virtual já define seus certificados e arquivo de chave. Defina apenas as que se aplicam ao seu sistema de origem:

  • spec.security.tls.caFilePath: the absolute path the CA is projected to inside the Pod. Defaults to /mongodb-automation/tls/ca/ca-pem. The path must contain at least two path segments. This field is not supported for the Application Database. If your podTemplate mounts another volume over this path, that mount shadows the projected CA and the Ops Manager Agent cannot read it.

  • spec.security.authentication.agents.autoPEMKeyFilePath: the absolute path of the agent's combined PEM file inside database Pods. This field configures agent authentication only. Setting this field sets the Ops Manager tls.autoPEMKeyFilePath value and mounts the Secret referenced by clientCertificateSecretRef at that path. It defaults to a hash-derived agent certificate mount path, and setting it requires spec.security.authentication.agents.clientCertificateSecretRef to already be set. Set this field only when the virtual machine deployment uses a non-default agent PEM path.

  • spec.downloadBase: the directory where the Ops Manager Agent binary downloads. Defaults to /var/lib/mongodb-mms-automation. Kubernetes Operator derives the keyfile path from this value as <downloadBase>/keyfile.

3

If the virtual machine deployment never configured TLS, set net.tls.mode to disabled in Ops Manager or Cloud Manager on the existing virtual machine deployment before you migrate. Do not set this field on the MongoDB custom resource.

If you leave the source deployment's TLS mode unset, Kubernetes Operator attempts a deployment change that does not match the source automation config, because its default view of TLS differs from a deployment that never configured TLS at all. Setting the field to disabled on the source deployment makes Kubernetes Operator's view match the virtual machine deployment and avoids that spurious change.

4

Apply the resource with the dry-run annotation still present and check the NetworkConnectivityVerified condition. To learn how to read the result and what to do if it fails, see Validate Migration Readiness with a Dry Run.

A sharded cluster needs one certificate per component, following the pattern <resourceName>-config-* for the config server, <resourceName>-<shardIndex>-* for each shard, and <resourceName>-mongos-* for the mongos routers.

Observação

Confirm the exact per-component Secret names against the generated resource before you reconcile. To learn how a sharded cluster migration differs from a replica set migration, see Migrate a Sharded Cluster to Kubernetes.