Kubernetes の単一クラスター配置でシークレットが保存されないようにするには、すべてのシークレットをシークレットストレージツールに移行します。複数のKubernetesクラスターでの配置では、HashiCorp Vault などのシークレットストレージツールへのシークレットの保存はサポートされていません。

次のコンポーネントごとに 1 つの TLS 証明書を生成します。
- レプリカセット。レプリカセットのノードをホストする各 Kubernetes ポッドのSANを証明書に追加することを確認します。
  
  TLS 証明書では、各ポッドの SAN は次の形式を使用する必要があります。
  <pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local
  重要
  let の暗号化などの AME ベースのサービスプロバイダーを使用して TLS 証明書を発行している場合、プロバイダーは証明書にポッドのデフォルトの FQDN （*.svc.cluster.local ）を SAN に追加することを禁止する可能性があります。
  ACMEベースの証明書を使用するには、レプリカセットリソースの証明書を構成する必要があります。詳細については、手順の「 ACMEベースのTLS証明書」に関するステップを参照してください。
- プロジェクトの MongoDB Agent。 MongoDB Agent 証明書については、次の要件を満たしていることを確認してください。
  - TLS 証明書のコモンネームが空ではない。
  - 各TLS証明書内の組織と組織単位の組み合わせは、レプリカセットノードのTLS証明書内の組織と組織単位とは異なります。
CA 証明書ファイルが必要で、ca-pem という名前を付ける必要があります。
TLS証明書の署名に使用したキーが必要です。

重要

Kubernetes Operator は kubernetes.io/tls シークレットを使用して、Ops Manager およびMongoDBリソースの TLS 証明書と秘密キーを保存します。 Kubernetes Operator1 17バージョン..0 以降、 Kubernetes Operator は Opaque シークレットとして保存される連結 PEM ファイルをサポートしていません。

レプリカセットの配置

`kubectl`をデフォルトで名前空間に設定します。

まだ作成していない場合は、次のコマンドを実行して、作成した名前空間ですべてのkubectlコマンドを実行します。

注意

MongoDB Ops Manager リソースを複数の Kubernetes クラスター MongoDB 配置に配置している場合、次の手順に従います。

contextを中央クラスターの名前に設定します（ kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"など）。
MongoDB のマルチ配置に使用したのと同じスコープ（例: kubectl config --namespace "mongodb"に--namespaceを設定します。

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>

レプリカセットの TLS 証明書のシークレットを作成します。

次のkubectl コマンドを実行して、レプリカセットの証明書を保存する新しいシークレットを作成します。

kubectl create secret tls <prefix>-<metadata.name>-cert \
  --cert=<replica-set-tls-cert> \
  --key=<replica-set-tls-key>

注意

シークレットの前に<prefix>-<metadata.name>を付ける必要があります。

例、配置をと呼び出し、プレフィックスをmy-deployment mdbに設定する場合は、クライアントTLS 通信の TLS シークレットにmdb-my-deployment-cert という名前を付ける必要があります。また、内部クラスター認証用の TLS シークレット（有効になっている場合）mdb-my-deployment-clusterfile という名前を付ける必要があります。

シークレットストレージツールとして HashiCorp Vault を使用している場合は、代わりに Vault シークレットを作成できます。

シークレットストレージのオプションの詳細については、「シークレットストレージの構成」を参照してください。

エージェントの TLS 証明書のシークレットを作成します。

次の kubectl コマンドを実行して、エージェントの TLS 証明書を保存する新しいシークレットを作成します。

kubectl create secret tls <prefix>-<metadata.name>-agent-certs \
  --cert=<agent-tls-cert> \
  --key=<agent-tls-key>

シークレットストレージツールとして HashiCorp Vault を使用している場合は、代わりに Vault シークレットを作成できます。

ConfigMap を作成して、CA を配置にリンクします。

このkubectl コマンドを実行して CA をレプリカセットにリンクし、 CA 証明書ファイルを指定します。

重要

Kubernetes Operator では、ConfigMap でMongoDBリソースの証明書がca-pemという名前を持つ必要があります。

kubectl create configmap custom-ca --from-file=ca-pem=<your-custom-ca-file>

サンプルレプリカセットリソースをコピーします。

この YAMLファイルの設定を、必要なレプリカセット構成に合わせて変更します。

1 ---
2 apiVersion: mongodb.com/v1
3 kind: MongoDB
4 metadata:
5   name: <my-replica-set>
6 spec:
7   members: 3
8   version: "8.0.0"
9   opsManager:
10     configMapRef:
11            # Must match metadata.name in ConfigMap file
12       name: <configMap.metadata.name>
13   credentials: <mycredentials>
14   type: ReplicaSet
15   persistent: true
16 ...

16   security:
17     tls:
18       ca: <custom-ca>
19     certsSecretPrefix: <prefix>
20 ...

コピーした例を貼り付けて、新しいレプリカセットリソースを作成します。

任意のテキストエディタを開き、オブジェクト仕様を新しいテキストファイルに貼り付けます。

設定を希望する値に変更します。

キー	タイプ	説明	例
`metadata.name`	string	この Kubernetes レプリカセットオブジェクトのラベル。リソース名は 44 文字以下にする必要があります。 `metadata.name`詳しくは、名前に関するとKubernetes のドキュメントを参照してください。	`myproject`
`spec.members`	integer	レプリカセットのメンバーの数。	`3`
`spec.version`	string	このレプリカセットが実行する MongoDB のバージョン。形式は、 MongoDB Community Editionでは `X.Y.Z`、Enterprise エディションでは `X.Y.Z-ent` です。重要:互換性のあるMongoDB Serverバージョンを選択していることを確認してください。互換性のあるバージョンは、 MongoDBデータベースリソースが使用する基本イメージによって異なります。 MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理」を参照してください。	`8.0.0`
`spec` `.opsManager` `.configMapRef` `.name`	string	Ops Manager 接続構成を含む ConfigMap `spec.cloudManager.configMapRef.name` の名前。設定はこの設定のエイリアスであり、代わりに使用できます。この値は、作成するリソースと同じ名前空間に存在する必要があります。重要: Kubernetes Operator は ConfigMap への変更を追跡し、`MongoDB` リソースの状態を調整します。	`<myconfigmap>`
`spec.credentials`	string	Kubernetes Operator が MongoDB Ops Manager と通信するための Ops Manager API認証情報として作成したシークレットの名前。認証情報を保持する Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。重要: Kubernetes Operator は、シークレットへの変更を追跡し、`MongoDB` リソースの状態を調整します。	`<mycredentials>`
`spec.type`	string	作成する`MongoDB`リソースのタイプ。	`ReplicaSet`
`spec.persistent`	string	任意。この`MongoDB` リソースがストレージに永続的なボリュームを使用するかどうかを示すフラグ。`MongoDB` リソースを停止または再起動しても、永続的なボリュームは削除されません。この値が`true`の場合、 `spec.podSpec.persistence.single`はデフォルト値の`16Gi`に設定されます。永続的なボリュームクレームを変更するには構成では、配置の要件を満たすように次のコレクションを構成します。各ポッドに 1 `spec.podSpec.persistence.single`つの永続ボリュームが必要な場合は、コレクションを構成します。個別の永続ボリュームが必要な場合各ポッドのデータ、ジャーナル、およびログ用では、次のコレクションを構成します。 `spec.podSpec.persistence.multiple.data` `spec.podSpec.persistence.multiple.journal` `spec.podSpec.persistence.multiple.logs` 警告: コンテナに永続ボリュームへの書込み (write) 権限を付与します。 Kubernetes演算子は、`fsGroup = 2000` `runAsUser = 2000`で、、を設定します。 Kubernetes Operator は、を`runAsNonRoot = true` `securityContextfsgrouprunAsUser`と等しく設定して、コンテナでメインプロセスを実行するユーザーがボリュームを書込み可能にします。詳細については、 Kubernetesドキュメントの「ポッドまたはコンテナのセキュリティコンテキストの構成」および関連するディスカッションを参照してください。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDBサポートにお問い合わせください。 Disk Usage永続ボリュームを使用しない場合、この配置のデータを確認するときに、Disk IOPS チャートとProcesses DeploymentチャートはページまたはMetrics ページのタブに表示されません。	`true`

カスタム認証局（CA）を使用して、レプリカセットリソースの TLS 設定を構成します。

配置でTLSを有効にするには、Kubernetes オブジェクトで次の設定を構成します。

キー	タイプ	必要性	説明	例
`spec.security` `.tls.ca`	string	必須	ConfigMap を追加する配置の TLS 証明書に署名するために使用したカスタム CA を保存するの名前。	`<custom-ca>`
`spec.security` `.certsSecretPrefix`	string	必須	MongoDB 配置のTLS証明書を含むシークレット名の`<prefix>`を追加します。例、配置をと呼び出し、プレフィックスを`my-deployment` `mdb`に設定する場合は、クライアントTLS 通信の TLS シークレットに`mdb-my-deployment-cert` という名前を付ける必要があります。また、内部クラスター認証用の TLS シークレット（有効になっている場合）`mdb-my-deployment-clusterfile` という名前を付ける必要があります。	`devDb`

オプション:レプリカセットリソース用の AME ベースの TLS 証明書を構成します。

let の暗号化などの AME ベースのサービスプロバイダーを使用して TLS 証明書を発行している場合、プロバイダーは証明書にポッドのデフォルトの FQDN （*.svc.cluster.local ）を SAN に追加することを禁止する可能性があります。

ポッドの FQDN を含まない証明書を設定するには、次の手順に従います。

外部ドメインの証明書を発行します。詳細については、let の暗号化のドキュメント、またはプロバイダーのドキュメントを参照してください。
証明書にレプリカセットに配置するすべてのホスト名が含まれていることを確認します。あるいは、 *.<externalDomain>のワイルドカード証明書を発行することもできます。
レプリカセットの配置で外部ドメインのみを含む証明書を使用するには、レプリカセットで使用されるデフォルトのホスト名を変更する必要があります。
- Kubernetesクラスターの作成中にホスト名を設定する場合は、 cluster.localKubernetesクラスターを作成または再作成するときに、デフォルトのドメインをから外部ドメインに変更します。次に、設定を使用してMongoDBリソースでこのドメインを設定します。spec.clusterDomain
- それ以外の場合は、Kubernetes オブジェクトで構成されている次の設定を使用して MongoDB 配置を作成します。

キー

タイプ

必要性

説明

spec.externalAccess
.externalDomain

string

必須

レプリカセットの配置を外部で公開するために使用される外部ドメイン。

デフォルトでは、各レプリカセットノードはKubernetesポッドの FQDN（ *.svc.cluster.local）をデフォルトのホスト名として使用します。ただし、この設定に外部ドメインを追加すると、レプリカセットは代わりに、指定されたドメインのサブドメインであるホスト名を使用します。このホスト名は、次の形式を使用します。

<replica-set-name>-<pod-idx>.<externalDomain>

以下に例を挙げます。

replica-set-1.example.com

この設定でレプリカセットを配置すると、 Kubernetes Operatorprocesses[n].hostname は外部ドメインを含むホスト名を使用して、Ops Managerオートメーション構成のフィールドを上書きします。次に、 MongoDB Agent はこのホスト名を使用してmongod に接続します。

レプリカセットに接続するための他のホスト名を指定するには、 spec.connectivity.replicaSetHorizons設定を使用できます。ただし、次の接続では、外部ドメインを含むホスト名は引き続き使用されます。

に接続するMongoDB Agent。mongod
mongodを使用して他のmongod インスタンスに接続します。

警告: このフィールドを指定すると、Ops Manager がmongod プロセスを登録する方法が変更されます。このフィールドまたは実行中のレプリカセット配置のprocesses[n].hostname Ops Managerオートメーション構成内の任意のフィールドの値は変更できません。

spec.externalAccess
.externalService.spec

コレクション

任意

ServiceSpec の構成。

spec.externalAccess設定を設定すると、 Kubernetes Operator はデフォルト値を持つ外部ロードバランサーサービスを自動的に作成します。ニーズに応じて、特定の値を上書きしたり、新しい値を追加したりできます。例、NodePort サービスを作成し、ロードバランサーが必要ない場合は、 Kubernetes仕様でオーバーライドを構成する必要があります。

externalAccess:
  externalService:
    annotations:
      # cloud-specific annotations for the service
    spec:
      type: NodePort # default is LoadBalancer
      # you can specify other spec overrides if necessary

Kubernetes仕様の詳細については、 Kubernetesドキュメントの ServiceSpec を参照してください。

spec.externalAccess
.externalService.annotations

コレクション

任意

配置内のすべてのクラスターにクラウドプロバイダー固有の構成設定を追加できるキーと値のペア。詳しくは、「 Kubernetesクラウドプロバイダー」の注釈とドキュメントを参照してください。

プレースホルダー値を指定して注釈をカスタマイズできます。詳しくは、 spec.externalAccess.externalService.annotationsを参照してください。

レプリカセットの配置に追加で許容される設定を追加します。

また、次の任意設定のいずれかをオブジェクトに追加できます。レプリカセット配置の仕様ファイル。

警告

spec.clusterDomainKubernetesクラスターにデフォルトの以外のデフォルトのドメインがある場合は、 cluster.localを設定する必要があります。デフォルトを使用せず、オプションも設定しない場合、spec.clusterDomain Kubernetes演算子が期待どおりに機能しない可能性があります。

このレプリカセット構成ファイルを`.yaml` 拡張子で保存します。

レプリカセットの配置を開始します。

任意のディレクトリで、次のKubernetesコマンドを呼び出してレプリカセットを作成します。

kubectl apply -f <replica-set-conf>.yaml

レプリカセットの配置のステータスを追跡します。

MongoDBリソースのステータスを確認するには、次のコマンドを使用します。

kubectl get mdb <resource-name> -o yaml -w

-w （監視）フラグが設定されている場合、構成が変更されると、ステータスフェーズがRunning状態に達するまで出力が直ちに更新されます。リソース配置ステータスの詳細については、「 Kubernetes 演算子のトラブルシューティング」を参照してください。

TLSを使用してデータベースリソースを暗号化すると、以下を保護できます。

レプリカセットの TLS 証明書の更新

次の手順で、 TLS証明書を定期的に更新します。

`kubectl`をデフォルトで名前空間に設定します。

まだ作成していない場合は、次のコマンドを実行して、作成した名前空間ですべてのkubectlコマンドを実行します。

注意

MongoDB Ops Manager リソースを複数の Kubernetes クラスター MongoDB 配置に配置している場合、次の手順に従います。

contextを中央クラスターの名前に設定します（ kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"など）。
MongoDB のマルチ配置に使用したのと同じスコープ（例: kubectl config --namespace "mongodb"に--namespaceを設定します。

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>

TLS 証明書のシークレットを更新します。

kubectlレプリカセットの証明書を保存する既存のシークレットを更新するには、次のコマンドを実行します。

kubectl create secret tls <prefix>-<metadata.name>-cert \
  --cert=<replica-set-tls-cert> \
  --key=<replica-set-tls-key> \
  --dry-run=client \
   -o yaml |
kubectl apply -f -

`kubectl`をデフォルトで名前空間に設定します。

まだ作成していない場合は、次のコマンドを実行して、作成した名前空間ですべてのkubectlコマンドを実行します。

注意

MongoDB Ops Manager リソースを複数の Kubernetes クラスター MongoDB 配置に配置している場合、次の手順に従います。

contextを中央クラスターの名前に設定します（ kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"など）。
MongoDB のマルチ配置に使用したのと同じスコープ（例: kubectl config --namespace "mongodb"に--namespaceを設定します。

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>

サンプルレプリカセットリソースをコピーします。

この YAMLファイルの設定を、必要なレプリカセット構成に合わせて変更します。

1 ---
2 apiVersion: mongodb.com/v1
3 kind: MongoDB
4 metadata:
5   name: <my-replica-set>
6 spec:
7   members: 3
8   version: "8.0.0"
9   opsManager:
10     configMapRef:
11            # Must match metadata.name in ConfigMap file
12       name: <configMap.metadata.name>
13   credentials: <mycredentials>
14   type: ReplicaSet
15   persistent: true
16 ...

コピーした例を貼り付けて、新しいレプリカセットリソースを作成します。

任意のテキストエディタを開き、オブジェクト仕様を新しいテキストファイルに貼り付けます。

設定を希望する値に変更します。

キー	タイプ	説明	例
`metadata.name`	string	この Kubernetes レプリカセットオブジェクトのラベル。リソース名は 44 文字以下にする必要があります。 `metadata.name`詳しくは、名前に関するとKubernetes のドキュメントを参照してください。	`myproject`
`spec.members`	integer	レプリカセットのメンバーの数。	`3`
`spec.version`	string	このレプリカセットが実行する MongoDB のバージョン。形式は、 MongoDB Community Editionでは `X.Y.Z`、Enterprise エディションでは `X.Y.Z-ent` です。重要:互換性のあるMongoDB Serverバージョンを選択していることを確認してください。互換性のあるバージョンは、 MongoDBデータベースリソースが使用する基本イメージによって異なります。 MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理」を参照してください。	`8.0.0`
`spec` `.opsManager` `.configMapRef` `.name`	string	Ops Manager 接続構成を含む ConfigMap `spec.cloudManager.configMapRef.name` の名前。設定はこの設定のエイリアスであり、代わりに使用できます。この値は、作成するリソースと同じ名前空間に存在する必要があります。重要: Kubernetes Operator は ConfigMap への変更を追跡し、`MongoDB` リソースの状態を調整します。	`<myconfigmap>`
`spec.credentials`	string	Kubernetes Operator が MongoDB Ops Manager と通信するための Ops Manager API認証情報として作成したシークレットの名前。認証情報を保持する Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。重要: Kubernetes Operator は、シークレットへの変更を追跡し、`MongoDB` リソースの状態を調整します。	`<mycredentials>`
`spec.type`	string	作成する`MongoDB`リソースのタイプ。	`ReplicaSet`
`spec.persistent`	string	任意。この`MongoDB` リソースがストレージに永続的なボリュームを使用するかどうかを示すフラグ。`MongoDB` リソースを停止または再起動しても、永続的なボリュームは削除されません。この値が`true`の場合、 `spec.podSpec.persistence.single`はデフォルト値の`16Gi`に設定されます。永続的なボリュームクレームを変更するには構成では、配置の要件を満たすように次のコレクションを構成します。各ポッドに 1 `spec.podSpec.persistence.single`つの永続ボリュームが必要な場合は、コレクションを構成します。個別の永続ボリュームが必要な場合各ポッドのデータ、ジャーナル、およびログ用では、次のコレクションを構成します。 `spec.podSpec.persistence.multiple.data` `spec.podSpec.persistence.multiple.journal` `spec.podSpec.persistence.multiple.logs` 警告: コンテナに永続ボリュームへの書込み (write) 権限を付与します。 Kubernetes演算子は、`fsGroup = 2000` `runAsUser = 2000`で、、を設定します。 Kubernetes Operator は、を`runAsNonRoot = true` `securityContextfsgrouprunAsUser`と等しく設定して、コンテナでメインプロセスを実行するユーザーがボリュームを書込み可能にします。詳細については、 Kubernetesドキュメントの「ポッドまたはコンテナのセキュリティコンテキストの構成」および関連するディスカッションを参照してください。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDBサポートにお問い合わせください。 Disk Usage永続ボリュームを使用しない場合、この配置のデータを確認するときに、Disk IOPS チャートとProcesses DeploymentチャートはページまたはMetrics ページのタブに表示されません。	`true`

レプリカセットの配置に追加で許容される設定を追加します。

また、次の任意設定のいずれかをオブジェクトに追加できます。レプリカセット配置の仕様ファイル。

警告

このレプリカセット構成ファイルを`.yaml` 拡張子で保存します。

レプリカセットの配置を開始します。

任意のディレクトリで、次のKubernetesコマンドを呼び出してレプリカセットを作成します。

kubectl apply -f <replica-set-conf>.yaml

レプリカセットの配置のステータスを追跡します。

MongoDBリソースのステータスを確認するには、次のコマンドを使用します。

kubectl get mdb <resource-name> -o yaml -w

戻る

スタンドアロンインスタンス

シャーディングされたクラスター

1	---
2	apiVersion: mongodb.com/v1
3	kind: MongoDB
4	metadata:
5	name: <my-replica-set>
6	spec:
7	members: 3
8	version: "8.0.0"
9	opsManager:
10	configMapRef:
11	# Must match metadata.name in ConfigMap file
12	name: <configMap.metadata.name>
13	credentials: <mycredentials>
14	type: ReplicaSet
15	persistent: true
16	...

16	security:
17	tls:
18	ca: <custom-ca>
19	certsSecretPrefix: <prefix>
20	...

レプリカセットの配置

Considerations

前提条件