Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/
MongoDB Database リソースの配置
/
MongoDB Database リソースの配置

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

項目一覧

  • Considerations
  • 前提条件
  • シャーディングされたクラスターの配置

注意

このページの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 ポッドのmongos SAN を証明書に追加することを確認します。

      TLS 証明書では、各 ポッドのmongos SAN は次の形式を使用する必要があります。

      <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 などのシークレット ストレージ ツールへのシークレットの保存はサポートされていません。 。

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

1

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>
2

シャードの 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 シークレットを作成 できます。

3

コンフィギュレーションサーバーの TLS 証明書のシークレットを作成します。

次のkubectlコマンドを実行して、シャーディングされたクラスター コンフィギュレーションサーバーの証明書を保存する新しいシークレットを作成します。

kubectl -n mongodb create secret tls <prefix>-<metadata.name>-config-cert \
  --cert=<config-tls-cert> \
  --key=<config-tls-key>

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

4

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 シークレットを作成 できます。

5

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

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

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

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

6

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

次のkubectlコマンドを実行してCAをシャーディングされたクラスターにリンクし、 MongoDBリソースに対して常にca-pemという名前を付ける必要があるCA証明書ファイルを指定します。

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

サンプルの シャーディングされたクラスター リソースをコピーします。

このYAMLファイルの設定を、シャーディングされたクラスターの構成に合わせて変更します。

必要なシャーディングされたクラスターの構成に合わせて設定を変更します。

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-sharded-cluster>
6spec:
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...
8

コピーした例を貼り付けて、新しい シャーディングされたクラスター リソースを作成します。

希望のテキストエディタを開き、 オブジェクト を貼り付けます 指定されたドキュメントを新しいテキストファイルに置き換えます。

9

前の手順で強調表示された設定を次のように構成します。

キー
タイプ
説明
例
string

この Kubernetes シャーディングされた クラスター オブジェクト のラベル 。

リソース名は 44 文字以下にする必要があります。

詳しくは、metadata.name 名前 に関する と Kubernetes のドキュメントを参照してください。

myproject
integer
配置するシャードの数。
2
integer
シャードあたりの シャード ノードの数。
3
integer
配置するシャード ルーターの数。
2
integer
コンフィギュレーションサーバー レプリカセットのノードの数。
3
string

このシャーディングされたクラスターが実行する MongoDB のバージョン。

形式は、 MongoDB Community Editionでは X.Y.Z、Enterprise エディションでは X.Y.Z-ent です。

重要

互換性のある MongoDB Server バージョンを選択していることを確認してください。

互換性のあるバージョンは、MongoDB database リソースが使用する基本イメージによって異なります。

MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理 」を参照してください。

最良の結果を得るには、利用 可能な最新のエンタープライズ MongoDB バージョン を使用してください MongoDB Ops Manager のバージョンと 互換性 のある 。

string

ConfigMap MongoDB Ops Managerの名前 接続構成の場合spec.cloudManager.configMapRef.name設定はこの設定のエイリアスであり、代わりに使用できます。

この値は、作成するリソースと同じ名前空間に存在する必要があります。

重要

演算子が ConfigMap への変更を管理

Kubernetes 演算子は、ConfigMap への変更を追跡し、 MongoDBリソースの状態を調整します。

<myproject>
string

Operator が と通信するための MongoDB Ops ManagerAPI認証情報として 作成KubernetesMongoDB Ops Manager したシークレットの名前。

認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。

重要

演算子がシークレットへの変更を管理

Kubernetes Operator は、シークレットへの変更を追跡し、 MongoDBリソースの状態を調整します。

<mycredentials>
string
作成するMongoDBリソースのタイプ。
ShardedCluster
string

任意。

このMongoDB リソースが 永続的なボリューム を使用するかどうかを示すフラグ ストレージ用。MongoDBリソースを停止または再起動しても、永続的なボリュームは削除されません。

この値がtrueの場合、次の値はデフォルト値の16Giに設定されます。

永続的なボリュームクレーム を変更するには 構成では、配置の要件を満たすように次のコレクションを構成します。

警告: コンテナに 永続ボリューム への書込み (write) 権限を付与 。Kubernetes 演算子は、 securityContextでfsGroup = 2000 、 runAsUser = 2000 、 runAsNonRoot = trueを設定します。 Kubernetes Operator は、 fsgroupをrunAsUserと等しく設定して、コンテナでメイン プロセスを実行するユーザーがボリュームを書込み可能にします。 詳細については、「 ポッドまたはコンテナのセキュリティ コンテキストの構成 」を参照してください および関連する ディスカッション （Kubernetes ドキュメント）。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDB サポートにお問い合わせください。

永続的なボリューム を使用しない場合 では、この配置Disk Usage Disk IOPSProcessesDeploymentMetricsのデータ を確認するときに、 ページまたは ページの は表示されません。

true
10

カスタム認証局（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
11

シャーディングされた クラスター の配置に追加の 設定を追加します。

また、次の任意設定のいずれかを オブジェクト に追加できます。 シャーディングされた クラスター 配置の仕様ファイル

警告

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

For config server

シャード ルーターの場合

シャード ノードの場合

12

このファイルは、.yaml ファイル拡張子で保存します。

13

シャーディングされた クラスター の配置を開始します。

次の 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"}
14

シャーディングされた クラスター の配置のステータスを追跡します。

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

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

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

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

シャーディングされたクラスターの TLS 証明書の更新

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

1

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>
2

シークレット を更新する シャードの 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 -
3

シークレット を更新する 取得します。

既存の シークレット を更新するには、この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 -
4

シークレット を更新する 使用している 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 -
1

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>
2

サンプルの シャーディングされたクラスター リソースをコピーします。

このYAMLファイルの設定を、シャーディングされたクラスターの構成に合わせて変更します。

これは、必要な構成に合わせて変更できるYAMLファイルです。 必要なシャーディングされたクラスターの構成に合わせて設定を変更します。

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-sharded-cluster>
6spec:
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...
3

コピーした例を貼り付けて、新しい シャーディングされたクラスター リソースを作成します。

希望のテキストエディタを開き、 オブジェクト を貼り付けます 指定されたドキュメントを新しいテキストファイルに置き換えます。

4

前の手順で強調表示された設定を次のように構成します。

キー
タイプ
説明
例
string

この Kubernetes シャーディングされた クラスター オブジェクト のラベル 。

リソース名は 44 文字以下にする必要があります。

詳しくは、metadata.name 名前 に関する と Kubernetes のドキュメントを参照してください。

myproject
integer
配置するシャードの数。
2
integer
シャードあたりの シャード ノードの数。
3
integer
配置するシャード ルーターの数。
2
integer
コンフィギュレーションサーバー レプリカセットのノードの数。
3
string

このシャーディングされたクラスターが実行する MongoDB のバージョン。

形式は、 MongoDB Community Editionでは X.Y.Z、Enterprise エディションでは X.Y.Z-ent です。

重要

互換性のある MongoDB Server バージョンを選択していることを確認してください。

互換性のあるバージョンは、MongoDB database リソースが使用する基本イメージによって異なります。

MongoDB のバージョン管理の詳細については、MongoDB マニュアルの「 MongoDBのバージョン管理 」を参照してください。

最良の結果を得るには、利用 可能な最新のエンタープライズ MongoDB バージョン を使用してください MongoDB Ops Manager のバージョンと 互換性 のある 。

string

ConfigMap MongoDB Ops Managerの名前 接続構成の場合spec.cloudManager.configMapRef.name設定はこの設定のエイリアスであり、代わりに使用できます。

この値は、作成するリソースと同じ名前空間に存在する必要があります。

重要

演算子が ConfigMap への変更を管理

Kubernetes 演算子は、ConfigMap への変更を追跡し、 MongoDBリソースの状態を調整します。

<myproject>
string

Operator が と通信するための MongoDB Ops ManagerAPI認証情報として 作成KubernetesMongoDB Ops Manager したシークレットの名前。

認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。

重要

演算子がシークレットへの変更を管理

Kubernetes Operator は、シークレットへの変更を追跡し、 MongoDBリソースの状態を調整します。

<mycredentials>
string
作成するMongoDBリソースのタイプ。
ShardedCluster
string

任意。

このMongoDB リソースが 永続的なボリューム を使用するかどうかを示すフラグ ストレージ用。MongoDBリソースを停止または再起動しても、永続的なボリュームは削除されません。

この値がtrueの場合、次の値はデフォルト値の16Giに設定されます。

永続的なボリュームクレーム を変更するには 構成では、配置の要件を満たすように次のコレクションを構成します。

警告: コンテナに 永続ボリューム への書込み (write) 権限を付与 。Kubernetes 演算子は、 securityContextでfsGroup = 2000 、 runAsUser = 2000 、 runAsNonRoot = trueを設定します。 Kubernetes Operator は、 fsgroupをrunAsUserと等しく設定して、コンテナでメイン プロセスを実行するユーザーがボリュームを書込み可能にします。 詳細については、「 ポッドまたはコンテナのセキュリティ コンテキストの構成 」を参照してください および関連する ディスカッション （Kubernetes ドキュメント）。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDB サポートにお問い合わせください。

永続的なボリューム を使用しない場合 では、この配置Disk Usage Disk IOPSProcessesDeploymentMetricsのデータ を確認するときに、 ページまたは ページの は表示されません。

true
5

シャーディングされた クラスター の配置に追加の 設定を追加します。

また、次の任意設定のいずれかを オブジェクト に追加できます。 シャーディングされた クラスター 配置の仕様ファイル

警告

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

For config server

シャード ルーターの場合

シャード ノードの場合

6

このファイルは、.yaml ファイル拡張子で保存します。

7

シャーディングされた クラスター の配置を開始します。

次の 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"}
8

シャーディングされた クラスター の配置のステータスを追跡します。

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

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

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

戻る

レプリカセットの配置