Considerations

複数の MongoDB レプリカセットの配置

MongoDB レプリカセットの配置および管理には、Kubernetes Operator の単一のインスタンスを使用することをお勧めします。

10を超える MongoDB レプリカセットを並列に配置するには、Kubernetes Operator インスタンスのスレッド数を増やしてください。

CPU とメモリのリソース要件の指定

Kubernetesでは、各 ポッドには 、ポッド内の各コンテナの CPU リソース とメモリ リソースを指定できるパラメーターが含まれています。

リソースの限界を示すために、Kubernetes は の リクエストと制限 を使用します。 パラメーターを使用します。

• リクエストは、リソースの下限を示します。

• limitはリソースの上限を示します。

次のセクションでは、次の方法を説明します。

• 演算子ポッドの CPU とメモリを設定します。

• MongoDB ポッドの CPU とメモリを設定します。

MongoDB Ops Managerをホストしているポッドには、 デフォルトの リソース制限 構成を使用します。

ストレージの推奨プラクティスを検討する

次の推奨事項は、MongoDB 配置とMongoDB Ops Manager KubernetesOperator によって管理される アプリケーションデータベース配置に適用されます。

• 制約に応じて最高のパフォーマンスを提供するストレージ クラスを使用してください。 詳細については、 配置のスケーリングを参照してください。

• 永続的なボリュームの プロビジョニング ストレージ クラスのReadWriteOnce をサポートする:

• ワーカー ノード レベルで、 Linux 上の MongoDB のベストプラクティスを適用します。

• ボリューム展開 をサポートするストレージ クラスを使用していることを確認する : データベース ボリュームのサイズ変更を有効にします。

静的コンテナの使用（パブリック プレビュー）

静的コンテナは、非静的コンテナよりも簡単で安全です。 静的コンテナは実行時に不変であるため、コンテナの作成に使用されるイメージから変更されることはありません。 さらに、

• 静的コンテナは実行中、バイナリをダウンロードしたり、ネットワーク接続を介してスクリプトやその他のユーティリティを実行したりしません。 静的コンテナはランタイム構成ファイルのみをダウンロードします。

• 静的コンテナは実行中、ストレージ ボリュームのマウント以外のファイルを変更しません。

• コンテナ イメージでセキュリティ スキャンを実行して、ライブ コンテナとして実際に実行されるものを判断できます。 を実行するコンテナは、イメージに定義されているもの以外のバイナリは実行しません。

• 静的コンテナでは、MongoDB または別のMongoDB Ops Manager HTTPS サーバーで バイナリをホストする必要はありません。これは、層が含まれた環境がある場合に特に便利です。

• 静的コンテナでは大量のCMDスクリプトを実行できません。

• initContainerを使用して静的コンテナ間でファイルをコピーすることはできません。

詳細については、「静的コンテナ（パブリック プレビュー） 」を参照してください。

ポッドをアプリケーションと並行して配置mongos

同じ ノード で軽量のmongos インスタンスを実行できます : MongoDB を使用するアプリとして表示されます。Kubernetes 演算子は、標準の Kubernetes ノードのアフィニティと非アフィニティを サポートします 機能。これらの機能を使用すると、アプリケーションと同じノードにmongosを強制的にインストールできます。

次の省略された例は、アフィニティと複数のアベイラビリティーゾーンの構成を示しています。

podAffinityキーは、アプリケーションを別のアプリケーションと同じポッド、ノード、またはデータセンターにインストールするかどうかを決定します。

ポッドのアフィニティを指定するには

1. 配置にタグを付けるには、 spec.podSpec.podTemplate.metadata.labels YAMLコレクションにラベルと値を追加します。 spec.podSpec.podTemplate.metadataと Kubernetes PodSpec v1 Core API を参照してください。

2. mongosがspec.mongosPodSpec.podAffinity .requiredDuringSchedulingIgnoredDuringExecution.labelSelector YAMLコレクションで使用するラベルを指定します。 matchExpressionsコレクションは、Kubernetes Operator がmongosをホストするためのポッドを識別するために使用するlabelを定義します。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: 4.2.1-ent
8
  service: my-service
9
10
  ...
11
    podTemplate:
12
      spec:
13
        affinity:
14
          podAffinity:
15
            requiredDuringSchedulingIgnoredDuringExecution:
16
              - labelSelector:
17
                  matchExpressions:
18
                    - key: security
19
                      operator: In
20
                      values:
21
                        - S1
22
                topologyKey: failure-domain.beta.kubernetes.io/zone
23
          nodeAffinity:
24
            requiredDuringSchedulingIgnoredDuringExecution:
25
              nodeSelectorTerms:
26
                - matchExpressions:
27
                    - key: kubernetes.io/e2e-az-name
28
                      operator: In
29
                      values:
30
                        - e2e-az1
31
                        - e2e-az2
32
          podAntiAffinity:
33
            requiredDuringSchedulingIgnoredDuringExecution:
34
            - podAffinityTerm:
35
                topologyKey: nodeId

レプリカ-セット-アフィニティ.YAML で複数のアベイラビリティーゾーンとノードのアフィニティ構成に関する完全な例を参照してください アフィニティ サンプル の ディレクトリ。

このディレクトリには、シャーディングされたクラスターとスタンドアロンの MongoDB 配置向けのサンプルアフィニティと複数のゾーン構成も含まれています。

MongoDB サービスの目的に応じて名前を付ける

次の例に示すように、この配置の目的を識別する値にspec.serviceパラメータを設定します。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: "6.0.0-ent"
8
  service: drilling-pumps-geosensors
9
  featureCompatibilityVersion: "4.0"

ラベルを使用して配置を区別する

ポッドのアフィニティ を使用する Kubernetes の機能:

• test 、 staging 、 production環境などの異なる MongoDB リソースを分離します。

• 配置 ポッド SSD サポートなどの機能を活用するために、一部の特定のノードで を使用します。

1
mongosPodSpec:
2
  podAffinity:
3
    requiredDuringSchedulingIgnoredDuringExecution:
4
      - labelSelector:
5
        matchExpressions:
6
        - key: security
7
          operator: In
8
          values:
9
          - S1
10
        topologyKey: failure-domain.beta.kubernetes.io/zone

Kubernetes Operator が監視する CustomResourceDefinitions をカスタマイズします

Kubernetes Operator が監視するカスタム リソースを指定できます。 これにより、Kubernetes Operator で管理するリソースのみに CustomResourceDefinition をインストールできます。

指定したカスタム リソースのみを監視するように Kubernetes Operator を構成するには、 helmを使用する必要があります。 関連するhelmインストール手順に従いますが、次の調整を行います。

1. インストールする CustomResourceDefinitions を決定します。 次のものは任意の数インストールできます。

   値	説明
   mongodb	データベース リソースの CustomResourceDefinitions をインストールし、それらのリソースを監視します。
   mongodbusers	MongoDB ユーザー リソース用に CustomResourceDefinitions をインストールし、それらのリソースを監視します。
   opsmanagers	MongoDB Ops Managerリソース用の CustomResourceDefinitions をインストールし、それらのリソースを監視します。

2. Helm Chart をインストールし、Kubernetes Operator が監視する CustomResourceDefinitions を指定します。

   各カスタム リソースは次のようにカンマで区切ります。

   helm install <deployment-name> mongodb/enterprise-operator \
     --set operator.watchedResources="{mongodb,mongodbusers}" \
        --skip-crds

適切な永続性構成を確保する

Kubernetes Operator によってオーケストレーションされる Kubernetes 配置はステートフルです。 Kubernetes コンテナは 永続ボリューム を使用します 再起動間でクラスターの状態を維持するため。

ステートメント要件を満たすために、Kubernetes Operator は次のアクションを実行します。

• 永続的なボリューム を作成します : MongoDB 配置用。

• ストレージ デバイスを マウント ポイントと呼ばれる 1 つ以上のディレクトリにマウントします。

• MongoDB マウント ポイントごとに 1 つの永続ボリュームを作成します。

• 各 Kubernetes コンテナ内のデフォルト パスを/dataに設定します。

MongoDB クラスターのストレージ ニーズを満たすには、Kubernetes Operator を使用して配置された各レプリカセットの構成を次のように変更します。

• spec.persistentで永続ボリュームが有効になっていることを確認します。 この設定のデフォルトはtrueです。

• Kubernetes Operator が各ボリュームに割り当てる十分な量のストレージを指定します。 ボリュームにはデータとログが保存されます。

  • データ、ログ、 oplogにそれぞれ複数のボリュームを設定するには、 spec.podSpec.persistence.multiple.dataを使用します。

  • データ、ログ、 oplogを保存する単一のボリュームを設定するには、 spec.podSpec.persistence.singleを使用します。

次の省略された例は、推奨される永続ストレージ サイズを示しています。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-cluster
5
spec:
6
7
  ...
8
  persistent: true
9
10
11
  shardPodSpec:
12
  ...
13
    persistence:
14
      multiple:
15
        data:
16
          storage: "20Gi"
17
        logs:
18
          storage: "4Gi"
19
          storageClass: standard

永続的ボリューム構成の完全な例については、 レプリカ-セット-永続 的ボリューム を参照してください。 永続的なボリューム サンプル の ディレクトリ。このディレクトリには、シャーディングされたクラスターとスタンドアロン配置のサンプル永続ボリューム構成も含まれています。

Kubernetes Operator ポッドの CPU とメモリ使用率の限界の設定

Kubernetes Operator を使用して MongoDB レプリカセットを配置すると、最初の調整プロセスによって Kubernetes Operator を実行しているポッドの CPU 使用量が増加します。 ただし、レプリカセットの配置プロセスが完了すると、Kubernetes Operator による CPU 使用率は大幅に減少します。

実稼働環境で最大 50 個の MongoDB レプリカセットまたはシャーディングされたクラスターを Kubernetes Operator と並行して配置するには、Kubernetes Operator ポッドの CPU とメモリ リソースと制限を次のように設定します。

• spec.template.spec.containers.resources.requests.cpu から 500m

• spec.template.spec.containers.resources.limits.cpu から 1100m

• spec.template.spec.containers.resources.requests.memory から 200Mi

• spec.template.spec.containers.resources.limits.memory から 1Gi

Helm を使用してリソースを配置する場合は、 values.YAML ファイルでこれらの値を定義します。

次の省略された例は、50 のレプリカセットまたはシャーディングされたクラスターの配置における Kubernetes Operator ポッドに推奨される CPU とメモリが含まれる構成を示しています。 配置する MongoDB クラスターが 50 未満の場合は、Kubernetes Operator ポッドの構成ファイルでより低い数値を使用できます。

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
 name: mongodb-enterprise-operator
5
 namespace: mongodb
6
spec:
7
 replicas: 1
8
 selector:
9
  matchLabels:
10
     app.kubernetes.io/component: controller
11
     app.kubernetes.io/name: mongodb-enterprise-operator
12
     app.kubernetes.io/instance: mongodb-enterprise-operator
13
 template:
14
  metadata:
15
   labels:
16
     app.kubernetes.io/component: controller
17
     app.kubernetes.io/name: mongodb-enterprise-operator
18
     app.kubernetes.io/instance: mongodb-enterprise-operator
19
   spec:
20
     serviceAccountName: mongodb-enterprise-operator
21
     securityContext:
22
       runAsNonRoot: true
23
       runAsUser: 2000
24
     containers:
25
     - name: mongodb-enterprise-operator
26
       image: quay.io/mongodb/mongodb-enterprise-operator:1.9.2
27
       imagePullPolicy: Always
28
       args:
29
        - "-watch-resource=mongodb"
30
        - "-watch-resource=opsmanagers"
31
        - "-watch-resource=mongodbusers"
32
       command:
33
        - "/usr/local/bin/mongodb-enterprise-operator"
34
       resources:
35
         limits:
36
           cpu: 1100m
37
           memory: 1Gi
38
         requests:
39
           cpu: 500m
40
           memory: 200Mi

最大50 MongoDB レプリカセットの並列配置を満たす Kubernetes Operator ポッドの CPU およびメモリ使用率のリソースと制限の完全な例については、 mongodb-enterprise.YAML ファイル。

MongoDB ポッドの CPU とメモリ使用率の限界を設定する

レプリカセットまたはシャーディングされたクラスターをホストしているポッドの値は、 リクエスト フィールド にマップされます 作成された ポッドの CPU とメモリ用。これらの値は、MongoDB ホストに記載されている考慮事項と一致します。

Kubernetes Operator は、割り当てられたメモリを処理、WiredTiger キャッシュ、および配置中のパッケージの保存に使用します。

本番環境には、MongoDB ポッドの CPU とメモリのリソースと制限を次のように設定します。

• spec.podSpec.podTemplate.spec.containers.resources.requests.cpu から 0.25

• spec.podSpec.podTemplate.spec.containers.resources.limits.cpu から 0.25

• spec.podSpec.podTemplate.spec.containers.resources.requests.memory から 512M

• spec.podSpec.podTemplate.spec.containers.resources.limits.memory から 512M

Helm を使用してリソースを配置する場合は、 values.YAML ファイルでこれらの値を定義します。

次の省略された例は、配置内で MongoDB レプリカセット ノードをホストしている各ポッドに推奨される CPU とメモリが含まれる構成を示しています。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
name: my-replica-set
5
spec:
6
  members: 3
7
  version: 4.0.0-ent
8
  service: my-service
9
  ...
10
11
  persistent: true
12
  podSpec:
13
    podTemplate:
14
      spec:
15
        containers:
16
        - name: mongodb-enterprise-database
17
          resources:
18
            limits:
19
              cpu: "0.25"
20
              memory: 512M

MongoDB レプリカセット ノードをホストしているポッドの CPU とメモリ使用率のリソースと制限の完全な例については、 レプリカセット -podspec.YAML MongoDB Podspec サンプル 内の ファイル ディレクトリ。

このディレクトリには、次の目的で使用されるポッドのサンプル CPU とメモリ制限の構成も含まれています。

• シャーディングされたクラスター（ sharded-cluster-podspec.YAML 内）。

• スタンドアロンの MongoDB 配置（ スタンドアロン-podspec.YAML）。

複数のアベイラビリティーゾーンの使用

Kubernetes Operator と ステートメント を設定する: 1 つのレプリカセットのすべてのノードを異なる ノード に分散 高可用性を確保します。

次の省略された例は、アフィニティと複数のアベイラビリティーゾーンの構成を示しています。

1
apiVersion: mongodb.com/v1
2
kind: MongoDB
3
metadata:
4
  name: my-replica-set
5
spec:
6
  members: 3
7
  version: 4.2.1-ent
8
  service: my-service
9
  ...
10
    podAntiAffinityTopologyKey: nodeId
11
    podAffinity:
12
      requiredDuringSchedulingIgnoredDuringExecution:
13
      - labelSelector:
14
        matchExpressions:
15
        - key: security
16
          operator: In
17
          values:
18
          - S1
19
        topologyKey: failure-domain.beta.kubernetes.io/zone
20
21
    nodeAffinity:
22
       requiredDuringSchedulingIgnoredDuringExecution:
23
         nodeSelectorTerms:
24
         - matchExpressions:
25
           - key: kubernetes.io/e2e-az-name
26
           operator: In
27
           values:
28
           - e2e-az1
29
           - e2e-az2

この例では、Kubernetes Operator は、 e2e-az1またはe2e-az2アベイラビリティーゾーン内のラベルkubernetes.io/e2e-az-nameを持つノードへのポッドの配置をスケジュールします。 目的のアベイラビリティーゾーンへのポッドの配置をスケジュールするには、 nodeAffinityを変更します。

レプリカ-セット-アフィニティ.YAML で複数のアベイラビリティーゾーンを構成する完全な例を参照してください アフィニティ サンプル の ディレクトリ。

このディレクトリには、シャーディングされたクラスターとスタンドアロンの MongoDB 配置向けのサンプルアフィニティと複数のゾーン構成も含まれています。

スレッド数を増やして複数の調整プロセスを並行して実行

10MongoDBを超えるKubernetes レプリカセットを並行して配置する予定の場合は、 Operator Kubernetesの配置で MDB_MAX_CONCURRENT_RECONC ファイルHelm values.yamlファイルの フィールドを使用して、より高いスレッド数を設定します。

Kubernetes Operator のスレッド数を増やすと、Kubernetes Operator の配置を Kubernetes クラスター内で実行されている数百のMongoDBリソースに垂直にスケーリングし、CPU 使用率を最適化できます。

Kubernetes API サーバーと Kubernetes Operator のリソース使用状況を監視し、必要に応じてそれぞれのリソース割り当てを調整してください。