Considerations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 静的コンテナでは、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: "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

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

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 演算子とステートメントを設定する : 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 配置向けのサンプルアフィニティと複数のゾーン構成も含まれています。