シャーディングされたクラスターの配置
注意
このページの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 演算子は kubernetes.io/tls を使用しますMongoDB Ops Manager と MongoDB リソースのTLS証明書と秘密キーを保存するためのシークレット。 Kubernetes Operator バージョン1 以降。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のバージョン管理 」を参照してください。 | 最良の結果を得るには、利用 可能な最新のエンタープライズ MongoDB バージョン を使用してください MongoDB Ops Manager のバージョンと 互換性 のある 。 | |
string | ConfigMap MongoDB Ops Managerの名前 接続構成の場合 この値は、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は ConfigMap への変更を追跡し、 |
| |
string | Operator が と通信するための MongoDB Ops ManagerAPI認証情報として 作成KubernetesMongoDB Ops Manager したシークレットの名前。 認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は、シークレットへの変更を追跡し、 |
| |
string | 作成する |
| |
string | 任意。 この この値が 永続的なボリュームクレーム を変更するには 構成では、配置の要件を満たすように次のコレクションを構成します。
警告: コンテナに 永続ボリューム への書込み (write) 権限を付与 。Kubernetes 演算子は、 永続的なボリューム を使用しない場合 では、この配置Disk Usage Disk IOPSProcessesDeploymentMetricsのデータ を確認するときに、 ページまたは ページの は表示されません。 |
|
カスタム認証局（CA）を使用して、シャーディングされた シャーディングされたクラスター リソースの TLS 設定を構成します。
配置でTLSを有効にするには、Kubernetes オブジェクトで次の設定を構成します。
キー | タイプ | 必要性 | 説明 | 例 |
|---|---|---|---|---|
spec.security | string | 必須 | ConfigMap を追加する 配置の TLS 証明書に署名するために使用したカスタム CA を保存する の名前。 |
|
spec.security | string | 必須 | MongoDB 配置のTLS証明書を含むシークレット名の たとえば、配置を |
|
シャーディングされたシャーディングされたクラスターの配置に追加の 設定を追加します。
また、次の任意設定のいずれかを オブジェクト に追加できます。 シャーディングされた クラスター 配置の仕様ファイル
警告
Kubernetes クラスターに デフォルトのドメインspec.clusterDomain がある場合は、 を設定する必要があります デフォルトの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 -
コンフィギュレーションサーバーの TLS 証明書のシークレットを更新します。
既存の シークレット を更新するには、このkubectl コマンドを実行します シャーディングされたクラスター コンフィギュレーションサーバー の証明書を保存する:
kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \ --cert=<config-tls-cert> \ --key=<config-tls-key> \ --dry-run=client \ -o yaml | kubectl apply -f -
mongos サーバーの TLS 証明書のシークレットを更新します。
既存の シークレット を更新するには、このkubectlmongos コマンドを実行します シャーディングされたクラスター 証明書を保存する:
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のバージョン管理 」を参照してください。 | 最良の結果を得るには、利用 可能な最新のエンタープライズ MongoDB バージョン を使用してください MongoDB Ops Manager のバージョンと 互換性 のある 。 | |
string | ConfigMap MongoDB Ops Managerの名前 接続構成の場合 この値は、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は ConfigMap への変更を追跡し、 |
| |
string | Operator が と通信するための MongoDB Ops ManagerAPI認証情報として 作成KubernetesMongoDB Ops Manager したシークレットの名前。 認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は、シークレットへの変更を追跡し、 |
| |
string | 作成する |
| |
string | 任意。 この この値が 永続的なボリュームクレーム を変更するには 構成では、配置の要件を満たすように次のコレクションを構成します。
警告: コンテナに 永続ボリューム への書込み (write) 権限を付与 。Kubernetes 演算子は、 永続的なボリューム を使用しない場合 では、この配置Disk Usage Disk IOPSProcessesDeploymentMetricsのデータ を確認するときに、 ページまたは ページの は表示されません。 |
|
シャーディングされたシャーディングされたクラスターの配置に追加の 設定を追加します。
また、次の任意設定のいずれかを オブジェクト に追加できます。 シャーディングされた クラスター 配置の仕様ファイル
警告
Kubernetes クラスターに デフォルトのドメインspec.clusterDomain がある場合は、 を設定する必要があります デフォルトのcluster.local 以外。デフォルトを使用せず、 spec.clusterDomainオプションを設定しない場合、Kubernetes 演算子が期待どおりに機能しない可能性があります。
For config server
シャード ルーターの場合
シャード ノードの場合
シャーディングされたシャーディングされたクラスターの配置のステータスを追跡します。
MongoDBリソースのステータスを確認するには、次のコマンドを使用します。
kubectl get mdb <resource-name> -o yaml -w
-w （監視）フラグが設定されている場合、構成が変更されると、ステータスフェーズがRunning状態に達するまで出力が直ちに更新されます。 リソース配置ステータスの詳細については、 「 Kubernetes 演算子のトラブルシューティング 」を参照してください。