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.
重要
このページのフィールドは移行専用に存在します。フィールドの説明に特に明示がない限り、greenフィールドKubernetes Operator 配置ではこれらを設定しないでください。
このタスクについて
To learn how to issue certificates, structure Secrets and ConfigMaps, and configure the general TLS settings on the MongoDB custom resource, see:
Security Settings for the full list of
spec.security.tlsand related fields.Set Up a cert-manager Integration to issue certificates with
cert-manager.X.509 クライアント証明書を生成 して、証明書を手動で発行します。
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.
始める前に
次のものが必要です。
仮想マシン配置の既存の CA 証明書とキーマテリアル。
cert-managerまたは同等のツールを使用して、同じ CA からKubernetesノード証明書を発行します。The generated
MongoDBcustom resource from Migrate a Replica Set to Kubernetes.
手順
ソース CA から証明書と CA リソースを作成します。
「 認証マネージャー統合を設定する 」または「 X.509 クライアント証明書の生成 kubernetes.io/tlsSecret<certsSecretPrefix>-<resourceName>-cert」に従って、 という名前の を作成し、仮想マシン証明書に署名したのと同じ CA から証明書を発行します。
Create the CA ConfigMap named <resourceName>-ca with a ca-pem key populated from that same CA.
X.509エージェント認証 を使用する場合は、<certsSecretPrefix>-<resourceName>-agent-certs Secret も作成し、それを参照ように spec.security.authentication.agents.clientCertificateSecretRef を設定します。この要件は、内部クラスター認証ではなく、エージェント認証にのみ適用されます（spec.security.authentication.internalCluster）。
ソース配置と一致するようにパス互換性フィールドを設定します。
これらのフィールドは、 Kubernetes Operator のファイルパスのビューを、仮想マシンの配置がすでに証明書とキーファイルの配置方法と一致させるためにのみ存在します。ソース配置に適用するもののみを設定します。
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 yourpodTemplatemounts 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 Managertls.autoPEMKeyFilePathvalue and mounts theSecretreferenced byclientCertificateSecretRefat that path. It defaults to a hash-derived agent certificate mount path, and setting it requiresspec.security.authentication.agents.clientCertificateSecretRefto 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.
ソース配置で TLS が使用されていない場合は、ソース配置で TLS を無効にします。
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.
ドライバーを実行して、CA が一致することを確認します。
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.
注意
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.