注意
このページのMongoDB Ops Managerが表示されている場所では、 Cloud Managerを置き換えることができます。
重要
Kubernetes演算子を使用して、MongoDB Cloud ManagerMongoDB Ops Managerおよび バージョン6.0 .x 以降で リソースを配置できます。
Atlas 演算子を使用して、MongoDB リソースを Atlas に配置できます。
警告
Kubernetes Operator はアービタ ノードをサポートしていません。
シャーディングされたクラスターは、大規模なデータセットの水平スケーリングを提供し、データセットをサーバーのグループ全体に分散することで高スループット操作を可能にします。
シャーディングの詳細については、MongoDB マニュアルの「 シャーディングの概要 」を参照してください。
MongoDB Ops Managerが管理する新しいシャーディングされたクラスターを配置するには、この手順を使用します。 後で、 MongoDB Ops Managerを使用してシャードを追加し、クラスターでその他のメンテナンス操作を実行できます。
Considerations
Kubernetes 内と外部でモニタリングエージェントを配置しない
Kubernetes ネットワーク変換のため、Kubernetes 外の監視エージェントは Kubernetes 内の MongoDB インスタンスを監視できません。 このため、同じプロジェクト内で k 8と非 k 8の配置はサポートされていません。 別々のプロジェクトを使用します。
接続を暗号化するかどうかの選択
Kubernetes Operator 経由でシャーディングされたクラスターを配置する場合は、 TLS証明書を使用して接続を暗号化するかどうかを選択する必要があります。
TLS-Encrypted接続の次の手順:
クラスター シャード間でTLS暗号化接続を確立します。
クライアント アプリケーションと MongoDB 配置間でTLS暗号化接続を確立します。
TLS暗号化の有効な証明書が必要です。
Non-Encrypted Connectionsの次の手順:
クラスター シャード間の接続を暗号化しません。
クライアント アプリケーションと MongoDB 配置間の接続を暗号化しません。
TLS暗号化接続を使用した配置よりもセットアップ要件が少なくなります。
注意
Kubernetes クラスターでは MongoDB のスタンドアロン インスタンスを保護することはできません。
レプリカセットのTLS暗号化を設定するには、「 レプリカセットの配置 」を参照してください。
TLSを使用してレプリカセット接続を暗号化するかどうかに応じて、適切なタブを選択します。
前提条件
オブジェクトを使用してシャーディングされたクラスターを配置するには、以下の手順を実行する必要があります。
注意
Kubernetes の単一クラスター配置でシークレットが保存されないようにするには、 すべてのシークレットをシークレットストレージツールに移行 します。複数のKubernetesクラスターでの配置では、 HashiCorp Vault などのシークレットストレージツールへのシークレットの保存はサポートされていません。
次のコンポーネントごとに 1 つのTLS証明書を生成します。
シャーディングされたクラスター内の各シャード。 シャード ノードをホストする各 Kubernetes ポッドのSANを証明書に追加することを確認します。
TLS証明書では、各シャード ポッドのSANは次の形式を使用する必要があります。
<pod-name>.<metadata.name>-sh.<namespace>.svc.cluster.local コンフィギュレーションサーバー。 コンフィギュレーションサーバーをホストする各 Kubernetes ポッドのSANを証明書に追加することを確認します。
TLS証明書では、各コンフィギュレーションサーバー ポッドのSANは次の形式を使用する必要があります。
<pod-name>.<metadata.name>-cs.<namespace>.svc.cluster.local mongosインスタンス。 をホストする各 Kubernetes ポッドのmongosSAN を証明書に追加することを確認します。TLS 証明書では、各 ポッドの
mongosSAN は次の形式を使用する必要があります。<pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local
プロジェクトの MongoDB Agent。 MongoDB Agent 証明書については、次の要件を満たしていることを確認してください。
TLS証明書のコモン ネームが空ではない。
各TLS証明書内の組織と組織単位の組み合わせは、レプリカセット ノードのTLS証明書内の組織と組織単位とは異なります。
CA証明書と、 TLS証明書の署名に使用したキーが必要です。
重要
Kubernetes Operator は kubernetes.io/tls シークレット を使用して、Ops Manager およびMongoDBリソースの TLS 証明書と秘密キーを保存します。 Kubernetes Operator1 17バージョン..0 以降、 Kubernetes Operator は Opaque シークレットとして保存される連結 PEM ファイルをサポートしていません。
オブジェクトを使用してシャーディングされたクラスターを配置するには、以下の手順を実行する必要があります。
注意
Kubernetes の単一クラスター配置でシークレットが保存されないようにするには、 すべてのシークレットをシークレットストレージツールに移行 します。複数のKubernetesクラスターでの配置では、 HashiCorp Vault などのシークレットストレージツールへのシークレットの保存はサポートされていません。
シャーディングされたクラスターの配置
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 -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \ --cert=<shard-0-tls-cert> \ --key=<shard-0-tls-key> kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \ --cert=<shard-1-tls-cert> \ --key=<shard-1-tls-key>
HashiCorp Vault を シークレットストレージツール として使用している場合は、代わりに Vault シークレットを作成 できます。
コンフィギュレーションサーバーの TLS 証明書のシークレットを作成します。
次のkubectlコマンドを実行して、シャーディングされたクラスター コンフィギュレーションサーバーの証明書を保存する新しいシークレットを作成します。
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \ --cert=<config-tls-cert> \ --key=<config-tls-key>
HashiCorp Vault を シークレットストレージツール として使用している場合は、代わりに Vault シークレットを作成 できます。
mongos サーバーの TLS 証明書のシークレットを作成します。
次のkubectlコマンドを実行して、シャーディングされたクラスターmongos証明書を保存する新しいシークレットを作成します。
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \ --cert=<mongos-tls-cert> \ --key=<mongos-tls-key>
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をシャーディングされたクラスターにリンクし、 MongoDBリソースに対して常にca-pemという名前を付ける必要があるCA証明書ファイルを指定します。
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-sharded-cluster> 6 spec: 7 shardCount: 2 8 mongodsPerShardCount: 3 9 mongosCount: 2 10 configServerCount: 3 11 version: "4.2.2-ent" 12 opsManager: 13 configMapRef: 14 name: <configMap.metadata.name> 15 # Must match metadata.name in ConfigMap file 16 credentials: <mycredentials> 17 type: ShardedCluster 18 persistent: true 19 ...
19 security: 20 tls: 21 ca: <custom-ca> 22 certsSecretPrefix: <prefix> 23 ...
前の手順で強調表示された設定を次のように構成します。
キー | タイプ | 説明 | 例 |
|---|---|---|---|
string | このKubernetesシャーディングされたクラスターオブジェクトのラベル。 リソース名は 44 文字以下にする必要があります。
|
| |
integer | 配置するシャードの数。 |
| |
integer | シャードあたりの シャード ノードの数。 |
| |
integer | 配置するシャード ルーターの数。 |
| |
integer | コンフィギュレーションサーバー レプリカセットのノードの数。 |
| |
string | このシャーディングされたクラスターが実行する MongoDB のバージョン。 形式は、 MongoDB Community Editionでは 重要:互換性のあるMongoDB Serverバージョンを選択していることを確認してください。 互換性のあるバージョンは、 MongoDBデータベースリソースが使用する基本イメージによって異なります。 MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理 」を参照してください。 | 最良の結果を得るには、Ops Manager のバージョンと互換性のある、利用可能な最新のエンタープライズMongoDBバージョンを使用してください。 | |
string | Ops Manager 接続構成を含む ConfigMap この値は、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は ConfigMap への変更を追跡し、 |
| |
string | Operator が と通信するための MongoDB Ops ManagerAPI認証情報として 作成KubernetesMongoDB Ops Manager したシークレットの名前。 認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は、シークレットへの変更を追跡し、 |
| |
string | 作成する |
| |
string | 任意。 この この値が 永続ボリューム要求の構成を変更するには、配置要件を満たすように次のコレクションを構成します。
警告: コンテナに 永続ボリュームへの書込み (write) 権限を付与します。 Kubernetes演算子は、 永続ボリューム Disk UsageDisk IOPSを使用しない場合、この配置のデータを確認するときに、Processes Deploymentページまたは ページの タブに チャートとMetrics チャートを表示することはできません。 |
|
カスタム認証局（CA）を使用して、シャーディングされたクラスターリソースの TLS 設定を構成します。
配置でTLSを有効にするには、Kubernetes オブジェクトで次の設定を構成します。
キー | タイプ | 必要性 | 説明 | 例 |
|---|---|---|---|---|
spec.security | string | 必須 | 配置の TLS 証明書に署名するために使用したカスタム CA を保存する ConfigMap の名前を追加します。 |
|
spec.security | string | 必須 | MongoDB 配置のTLS証明書を含むシークレット名の たとえば、配置を |
|
シャーディングされたシャーディングされたクラスターの配置に追加の 設定を追加します。
また、シャーディングされたクラスター配置のオブジェクト仕様ファイルに、次のいずれかのオプション設定を追加することもできます。
警告
spec.clusterDomainKubernetesクラスターにデフォルトの 以外のデフォルトのドメインがある場合は、 cluster.localを設定する必要があります。デフォルトを使用せず、 オプションを設定しない場合、spec.clusterDomain Kubernetes演算子が期待どおりに機能しない可能性があります。
For config server
シャード ルーターの場合
シャード ノードの場合
シャーディングされたシャーディングされたクラスターの配置のステータスを追跡します。
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 -n mongodb create secret tls <prefix>-<metadata.name>-0-cert \ --cert=<shard-0-tls-cert> \ --key=<shard-0-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f - kubectl -n mongodb create secret tls <prefix>-<metadata.name>-1-cert \ --cert=<shard-1-tls-cert> \ --key=<shard-1-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
mongos サーバーの TLS 証明書のシークレットを更新します。
kubectlシャーディングされたクラスターのmongos 証明書を保存する既存のシークレットを更新するには、次の コマンドを実行します。
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-mongos-cert \ --cert=<mongos-tls-cert> \ --key=<mongos-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ファイルの設定を、シャーディングされたクラスターの構成に合わせて変更します。
これは、必要な構成に合わせて変更できるYAMLファイルです。 必要なシャーディングされたクラスターの構成に合わせて設定を変更します。
1 2 apiVersion: mongodb.com/v1 3 kind: MongoDB 4 metadata: 5 name: <my-sharded-cluster> 6 spec: 7 shardCount: 2 8 mongodsPerShardCount: 3 9 mongosCount: 2 10 configServerCount: 3 11 version: "4.2.2-ent" 12 opsManager: 13 configMapRef: 14 name: <configMap.metadata.name> 15 # Must match metadata.name in ConfigMap file 16 credentials: <mycredentials> 17 type: ShardedCluster 18 persistent: true 19 ...
前の手順で強調表示された設定を次のように構成します。
キー | タイプ | 説明 | 例 |
|---|---|---|---|
string | このKubernetesシャーディングされたクラスターオブジェクトのラベル。 リソース名は 44 文字以下にする必要があります。
|
| |
integer | 配置するシャードの数。 |
| |
integer | シャードあたりの シャード ノードの数。 |
| |
integer | 配置するシャード ルーターの数。 |
| |
integer | コンフィギュレーションサーバー レプリカセットのノードの数。 |
| |
string | このシャーディングされたクラスターが実行する MongoDB のバージョン。 形式は、 MongoDB Community Editionでは 重要:互換性のあるMongoDB Serverバージョンを選択していることを確認してください。 互換性のあるバージョンは、 MongoDBデータベースリソースが使用する基本イメージによって異なります。 MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理 」を参照してください。 | 最良の結果を得るには、Ops Manager のバージョンと互換性のある、利用可能な最新のエンタープライズMongoDBバージョンを使用してください。 | |
string | Ops Manager 接続構成を含む ConfigMap この値は、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は ConfigMap への変更を追跡し、 |
| |
string | Operator が と通信するための MongoDB Ops ManagerAPI認証情報として 作成KubernetesMongoDB Ops Manager したシークレットの名前。 認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は、シークレットへの変更を追跡し、 |
| |
string | 作成する |
| |
string | 任意。 この この値が 永続ボリューム要求の構成を変更するには、配置要件を満たすように次のコレクションを構成します。
警告: コンテナに 永続ボリュームへの書込み (write) 権限を付与します。 Kubernetes演算子は、 永続ボリューム Disk UsageDisk IOPSを使用しない場合、この配置のデータを確認するときに、Processes Deploymentページまたは ページの タブに チャートとMetrics チャートを表示することはできません。 |
|
シャーディングされたシャーディングされたクラスターの配置に追加の 設定を追加します。
また、シャーディングされたクラスター配置のオブジェクト仕様ファイルに、次のいずれかのオプション設定を追加することもできます。
警告
spec.clusterDomainKubernetesクラスターにデフォルトの 以外のデフォルトのドメインがある場合は、 cluster.localを設定する必要があります。デフォルトを使用せず、 オプションを設定しない場合、spec.clusterDomain Kubernetes演算子が期待どおりに機能しない可能性があります。
For config server
シャード ルーターの場合
シャード ノードの場合
シャーディングされたシャーディングされたクラスターの配置のステータスを追跡します。
MongoDBリソースのステータスを確認するには、次のコマンドを使用します。
kubectl get mdb <resource-name> -o yaml -w
-w （監視）フラグが設定されている場合、構成が変更されると、ステータスフェーズがRunning状態に達するまで出力が直ちに更新されます。 リソース配置ステータスの詳細については、 「 Kubernetes 演算子のトラブルシューティング 」を参照してください。