Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Docs Menu
Docs Home
/
Enterprise Kubernetes 演算子
/
データベース リソースの配置
/
配置

レプリカセットの配置

注意

このページのMongoDB Ops Managerが表示されている場所では、 Cloud Managerを置き換えることができます。

重要

  • Kubernetes演算子を使用して、MongoDB Cloud ManagerMongoDB Ops Managerおよび バージョン6.0 .x 以降で リソースを配置できます。

  • Atlas 演算子を使用して、MongoDB リソースを Atlas に配置できます。

警告

Kubernetes Operator はアービタ ノードをサポートしていません。

レプリカセットは、同じデータセットを保持する MongoDB 配置のグループです。 レプリカセットは冗長性と高可用性を提供し、すべての配置環境の基盤となります。

レプリカセットの詳細については、MongoDB マニュアルの 「レプリケーションの概要」を参照してください。

MongoDB Ops Managerが管理する新しいレプリカセットを配置するには、次の手順を使用します。 配置後は、 MongoDB Ops Managerを使用して、ノードの追加、削除、再構成などの操作を含むレプリカセットを管理します。

Considerations

Kubernetes Operator 経由でレプリカセットを配置する場合、 TLS証明書を使用して接続を暗号化するかどうかを選択する必要があります。

TLS-Encrypted接続の次の手順:

  • レプリカセット内の MongoDB ホスト間でTLS暗号化接続を確立します。

  • クライアント アプリケーションと MongoDB 配置間でTLS暗号化接続を確立します。

  • TLS暗号化の有効な証明書が必要です。

Non-Encrypted Connectionsの次の手順:

  • レプリカセット内の MongoDB ホスト間の接続を暗号化しません。

  • クライアント アプリケーションと MongoDB 配置間の接続を暗号化しません。

  • TLS暗号化接続を使用した配置よりもセットアップ要件が少なくなります。

注意

Kubernetes クラスターでは MongoDB のスタンドアロン インスタンスを保護することはできません。

シャーディングされたクラスターのTLS暗号化を設定するには、「 シャーディングされたクラスターの配置 」を参照してください。

TLSを使用してレプリカセット接続を暗号化するかどうかに応じて、適切なタブを選択します。

前提条件

オブジェクトを使用してレプリカセットを配置するには、以下を行う必要があります。

注意

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

  • 次のコンポーネントごとに 1 つのTLS証明書を生成します。

    • レプリカセット。 レプリカセットのノードをホストする各 Kubernetes ポッドのSANを証明書に追加することを確認します。

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

      <pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local

      重要

      let*.svc.cluster.local の暗号化などの AME ベースのサービスプロバイダーを使用して TLS 証明書を発行している場合、プロバイダーはポッドのデフォルトのFQDN （ ）を証明書に 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 ファイルをサポートしていません。

オブジェクトを使用してレプリカセットを配置するには、以下を行う必要があります。

注意

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

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

3

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

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

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

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

4

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

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

重要

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

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

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

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

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-replica-set>
6spec:
7  members: 3
8  version: "4.2.2-ent"
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...
6

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

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

7

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

キー
タイプ
説明
例

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のバージョン管理 」を参照してください。

6.0.0-ent

spec
.opsManager
.configMapRef
.name

string

Ops Manager 接続構成を含む ConfigMapspec.cloudManager.configMapRef.name の名前。 設定はこの設定のエイリアスであり、代わりに使用できます。

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

重要: Kubernetes Operator は ConfigMap への変更を追跡し、MongoDB リソースの状態を調整します。

<myconfigmap>

spec.credentials

string

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

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

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

<mycredentials>

spec.type

string

作成するMongoDBリソースのタイプ。

ReplicaSet

spec.persistent

string

任意。

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

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

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

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

永続ボリューム Disk UsageDisk IOPSを使用しない場合、この配置のデータを確認するときに、Processes Deploymentページまたは ページの タブに チャートとMetrics チャートを表示することはできません。

true

8

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

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

キー
タイプ
必要性
説明
例
spec.security
.tls.ca

string

必須

配置の TLS 証明書に署名するために使用したカスタム CA を保存する ConfigMap の名前を追加します。

<custom-ca>

spec.security
.certsSecretPrefix

string

必須

MongoDB 配置のTLS証明書を含むシークレット名の<prefix>を追加します。

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

devDb

9

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

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

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

  1. 外部ドメインの証明書を発行します。詳細については、 let の暗号化のドキュメント 、または プロバイダーのドキュメント を参照してください。

  2. 証明書にレプリカセットに配置するすべてのホスト名が含まれていることを確認します。 あるいは、 *.<externalDomain>の ワイルドカード 証明書を発行することもできます。

  3. レプリカセットの配置で外部ドメインのみを含む証明書を使用するには、レプリカセットで使用されるデフォルトのホスト名を変更する必要があります。

    • 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 Operator は外部ドメインを含むホスト名を使用して、 MongoDB Ops Managerオートメーション構成の processes[n].hostname フィールドを上書きします。 次に、MongoDB Agent はこのホスト名を使用してmongodに接続します。

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

  • mongodに接続する MongoDB Agent

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

警告:このフィールドを指定すると、 MongoDB Ops Managerがmongodプロセスを登録する方法が変更されます。 このフィールドは、Kubernetes Operator バージョン1.19以降の新しいレプリカセット配置でのみ指定できます。 実行中のレプリカセット配置のMongoDB Ops Manager自動化構成で、このフィールドまたは任意の processes[n].hostname フィールドの値を変更することはできません。

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を参照してください。

10

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

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

警告

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

11

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

12

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

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

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

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

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 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 -
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ファイルの設定を、必要なレプリカセット構成に合わせて変更します。

1---
2apiVersion: mongodb.com/v1
3kind: MongoDB
4metadata:
5  name: <my-replica-set>
6spec:
7  members: 3
8  version: "4.2.2-ent"
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...
3

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

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

4

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

キー
タイプ
説明
例

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のバージョン管理 」を参照してください。

6.0.0-ent

spec
.opsManager
.configMapRef
.name

string

Ops Manager 接続構成を含む ConfigMapspec.cloudManager.configMapRef.name の名前。 設定はこの設定のエイリアスであり、代わりに使用できます。

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

重要: Kubernetes Operator は ConfigMap への変更を追跡し、MongoDB リソースの状態を調整します。

<myconfigmap>

spec.credentials

string

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

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

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

<mycredentials>

spec.type

string

作成するMongoDBリソースのタイプ。

ReplicaSet

spec.persistent

string

任意。

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

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

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

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

永続ボリューム Disk UsageDisk IOPSを使用しない場合、この配置のデータを確認するときに、Processes Deploymentページまたは ページの タブに チャートとMetrics チャートを表示することはできません。

true

5

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

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

警告

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

6

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

7

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

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

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

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

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

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

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

戻る

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

次へ

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

項目一覧