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

mongosMongoDBを使用して、アプリと同じノードで軽量の インスタンスを実行できます。Kubernetes Operator は、標準の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

アフィニティ サンプルディレクトリの レプリカセット -になり例。

このディレクトリには、シャーディングされたクラスターとスタンドアロンの 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

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

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 およびメモリ使用率のリソースと制限の完全な例については、 MongoDB Podspec サンプルディレクトリの replica-set-podspec.YAMLファイルを参照してください。

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

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

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

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

Kubernetes Operator と StateftSets を設定して、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 のリソース使用状況を監視し、必要に応じてそれぞれのリソース割り当てを調整してください。