注意
このページのMongoDB Ops Managerが表示されている場所では、 Cloud Managerを置き換えることができます。
重要
Kubernetes演算子を使用して、MongoDB Cloud ManagerMongoDB Ops Managerおよび バージョン6.0 .x 以降で リソースを配置できます。
Atlas 演算子 を使用して、 MongoDBリソースを Atlas に配置できます。
警告
Kubernetes Operator はアービタノードをサポートしていません。
シャーディングされたクラスターは、大規模なデータセットの水平スケーリングを提供し、データセットをサーバーのグループ全体に分散することで高スループット操作を可能にします。
シャーディング の詳細については、 MongoDBマニュアルの シャーディングの概要 を参照してください。
Ops Manager が管理する新しいシャーディングされたクラスターを配置するには、この手順を使用します。後で、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 Operator 用のMongoDB Controls を用意するか、インストールします。
注意
単一クラスターの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
プロジェクトの 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 Operator 用のMongoDB Controls を用意するか、インストールします。
注意
単一クラスターの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 をシャーディングされたクラスターにリンクし、 リソースに対して常に という名前を付ける必要がある CAca-pem MongoDB証明書ファイルを指定します。
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: "8.0.0" 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 | Kubernetes Operator が MongoDB Ops Manager と通信するための Ops Manager API認証情報として作成したシークレットの名前。 認証情報を保持する Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は、シークレットへの変更を追跡し、 |
| |
string | 作成する |
| |
string | 任意。 この この値が 永続ボリューム要求の構成を変更するには、配置要件を満たすように次のコレクションを構成します。
警告: コンテナに永続ボリュームへの書込み (write) 権限を付与します。 Kubernetes演算子は、 Disk Usage永続ボリュームを使用しない場合、この配置のデータを確認するときに、Disk IOPS チャートとProcesses Deploymentチャートは ページまたはMetrics ページの タブに表示されません。 |
|
カスタム認証局（CA）を使用して、シャーディングされたクラスターリソースの TLS 設定を構成します。
配置で TLS を有効にするには、 Kubernetesオブジェクトで次の設定を構成します。
キー | タイプ | 必要性 | 説明 | 例 |
|---|---|---|---|---|
| string | 必須 | 配置の TLS 証明書に署名するために使用したカスタム CA を保存する ConfigMap の名前を追加します。 |
|
| string | 必須 |
例、配置を と呼び出し、プレフィックスを |
|
シャーディングされたクラスターの配置に追加の 設定を追加します。
また、シャーディングされたクラスター配置のオブジェクト仕様ファイルに、次のいずれかのオプション設定を追加することもできます。
警告
spec.clusterDomainKubernetesクラスターにデフォルトの 以外のデフォルトのドメインがある場合は、 cluster.localを設定する必要があります。デフォルトを使用せず、 オプションも設定しない場合、spec.clusterDomain Kubernetes演算子が期待どおりに機能しない可能性があります。
For config server
シャード ルーターの場合
シャード ノードの場合
シャーディングされたクラスターの配置を開始します。
次のKubernetesコマンドを呼び出して、シャーディングされたクラスターを作成します。
kubectl apply -f <sharded-cluster-conf>.yaml
このコマンドを実行した後、ログを確認します。 作成が成功した場合は、次のようなメッセージが表示されます。
2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
シャーディングされたクラスターの配置のステータスを追跡します。
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: "8.0.0" 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 | Kubernetes Operator が MongoDB Ops Manager と通信するための Ops Manager API認証情報として作成したシークレットの名前。 認証情報を保持する Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。 重要: Kubernetes Operator は、シークレットへの変更を追跡し、 |
| |
string | 作成する |
| |
string | 任意。 この この値が 永続ボリューム要求の構成を変更するには、配置要件を満たすように次のコレクションを構成します。
警告: コンテナに永続ボリュームへの書込み (write) 権限を付与します。 Kubernetes演算子は、 Disk Usage永続ボリュームを使用しない場合、この配置のデータを確認するときに、Disk IOPS チャートとProcesses Deploymentチャートは ページまたはMetrics ページの タブに表示されません。 |
|
シャーディングされたクラスターの配置に追加の 設定を追加します。
また、シャーディングされたクラスター配置のオブジェクト仕様ファイルに、次のいずれかのオプション設定を追加することもできます。
警告
spec.clusterDomainKubernetesクラスターにデフォルトの 以外のデフォルトのドメインがある場合は、 cluster.localを設定する必要があります。デフォルトを使用せず、 オプションも設定しない場合、spec.clusterDomain Kubernetes演算子が期待どおりに機能しない可能性があります。
For config server
シャード ルーターの場合
シャード ノードの場合
シャーディングされたクラスターの配置を開始します。
次のKubernetesコマンドを呼び出して、シャーディングされたクラスターを作成します。
kubectl apply -f <sharded-cluster-conf>.yaml
このコマンドを実行した後、ログを確認します。 作成が成功した場合は、次のようなメッセージが表示されます。
2018-06-26T10:30:30.346Z INFO operator/shardedclusterkube.go:52 Created! {"sharded cluster": "my-sharded-cluster"}
シャーディングされたクラスターの配置のステータスを追跡します。
MongoDBリソースのステータスを確認するには、次のコマンドを使用します。
kubectl get mdb <resource-name> -o yaml -w
-w （監視）フラグが設定されている場合、構成が変更されると、ステータスフェーズがRunning状態に達するまで出力が直ちに更新されます。 リソース配置ステータスの詳細については、 「 Kubernetes 演算子のトラブルシューティング 」を参照してください。