Considerations

推奨数の MongoDB レプリカセットを配置する

Kubernetes Operator の単一のインスタンスを使用して、最大 20 のレプリカセットを並列に配置することをお勧めします。

この数を50 に増やすと、Kubernetes Operator によるリソースのダウンロード、インストール、配置、調整にかかる時間がかなりの増加が予想されます。

レプリカセット 50 の場合、配置にかかる時間はさまざまで、最大 40 分かかる場合があります。 この時間は、Kubernetes クラスターのネットワーク帯域幅と、各 MongoDB Agent が各 MongoDB クラスター ノードの MongoDB インストール バイナリをインターネットからダウンロードするのにかかる時間によって異なります。

50 を超える MongoDB レプリカセットを並列に配置するには、Kubernetes 演算子の複数のインスタンスを使用します。

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

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

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

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

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

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

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

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

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

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

静的コンテナは、非静的コンテナよりも安全で簡単です。 静的コンテナは実行時に不変です。 さらに、

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

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

• 静的コンテナでは、コンテナのセキュリティ脆弱性についてコンテナをスキャンする必要はありません。これは、コンテナのセキュリティスキャンが必要な非静的コンテナとは対照的です。 静的コンテナを使用する場合、セキュリティ スキャンはコンテナ イメージ自体に対してのみ実行できますが、そのコンテナに対しては実行できません。

• 静的コンテナでは、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: "4.4.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 を参照してください。このディレクトリには、シャーディングされたクラスターとスタンドアロン配置のサンプル永続ボリューム構成も含まれています。

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

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

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

Kubernetes Operator と StatefulSets を設定して、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 配置向けのサンプルアフィニティと複数のゾーン構成も含まれています。