MongoDBカスタム リソースの構成

配置タイプの選択

最初に行う必要がある決定は、作成する MongoDB 配置の種類です。spec.type フィールドは 3 つの値を受け入れます。各値は、異なるワークロードと操作要件のセットを対象としています。YAML のコードを 1 行でも書き始める前に、それらのトレードオフを理解することが重要です。

スタンドアロンインスタンスは、単一の mongod プロセスを実行します。これらは、ローカル開発、テストシナリオ、または冗長性が問題にならない機能の評価に最適です。スタンドアロン配置にはレプリケーションがないため、自動フェイルオーバーはサポートされず、プロダクション データには推奨されません。

レプリカセットは、MongoDB のデフォルトの本番環境トポロジーです。レプリカセットは、データの完全に同じコピーを維持する複数の mongod ノード (通常 3 つ以上) で構成されています。プライマリが失敗した場合は、残存しているノードが手動での介入なしに新しいプライマリを選出します。レプリカセットを選択すると、高可用性、セカンダリの読み取りによる読み取りのスケーラビリティ、ローリングメンテナンスを実行する能力が得られます。ほとんどのチームでは、ここから始めます。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-replica-set
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

シャーディングされたクラスターは、データを複数のシャードに分散します。各シャードはそれ自身がレプリカセットです。シャードの前には、クライアントのトラフィックを指定する mongos 台のルーターと、クラスターのメタデータを保存する専用のコンフィギュレーションサーバーのレプリカセットがあります。単一のレプリカセットで効率的に勤めることができないほどデータセットが増えている場合、または書き込みを水平方向に増やす必要がある場合は、シャーディングされたクラスターが適切な選択肢となります。シャードの数、シャードごとの mongod インスタンス、 mongos 台のルーター、およびコンフィギュレーションサーバーの数を指定する必要があるため、設定はより複雑になります。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  type: ShardedCluster
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

各配置タイプに固有のすべてのフィールドの詳細については、仕様リファレンスの「スタンドアロン」、「レプリカセット」、および「シャーディングされたクラスター」の項を参照してください。

MongoDB Ops Manager への接続

すべての MongoDB カスタム リソースは、MongoDB Ops Manager プロジェクトにリンクされている必要があります。この接続により、Kubernetes 演算子はモニタリング、オートメーション、バックアップの配置を登録します。接続を機能させるには、プロジェクトを識別する ConfigMap と、API 認証情報を保存する Secret の 2 つの構成が必要です。

ConfigMap は、Kubernetes 演算子に、配置を配置する Ops Manager プロジェクトを指定します。最低でも、Ops Manager インスタンスを指す projectName と baseUrl を含める必要があります。オプションで、orgId を使用して配置を特定の組織に固定できます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-project-configmap
data:
  projectName: "MyKubernetesProject"
  baseUrl: "https://ops-manager.example.com"
  orgId: "5e8f8b8b8b8b8b8b8b8b8b8b"

シークレットには、Kubernetes 演算子がユーザに代わってMongoDB Ops Manager APIに認証するために使用するプログラムによるAPIキーペアが保存されています。

kubectl create secret generic my-credentials \
  --from-literal="publicKey=<public-api-key>" \
  --from-literal="privateKey=<private-api-key>"

その後、MongoDB CR 内で両方を参照します。

spec:
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials

これらの前提条件の作成について詳しくは、「Kubernetes Operator の認証情報の作成」および「ConfigMap を使用して MongoDB デプロイメントごとにプロジェクトを作成するを参照してください。

MongoDB バージョンと機能の互換性

spec.version フィールドは、Kubernetes Operator が配置する MongoDB サーバー バージョンを設定します（例："8.0.0"）。適切なバージョンを選択するというのは、最新の機能を入手するだけではありません。ドライバー ライブラリ、実行中の MongoDB Ops Manager バージョン、チームのアップグレードの頻度とのバージョン互換性マトリックスも考慮する必要があります。

メジャーバージョン間でアップグレードする場合、featureCompatibilityVersion (機能の互換性バージョン) フィールドによりセーフティネットが提供されます。機能の互換性バージョン は、ストレージエンジンとレプリケーションのどの機能が有効になっているかを制御し、バイナリバージョン自体よりも低い値に設定できます。これにより、まずバイナリをアップグレードし、安定性を確認した後、別の意図的なステップで FCV を上げて新しい機能を解除できます。ロールバックする必要がある場合は、機能の互換性バージョン を低く設定することで、データファイルと前のバイナリバージョンの互換性が維持されます。

spec:
  version: "8.0.0"
  featureCompatibilityVersion: "7.0"

参照については、仕様のspec.versionとspec.featureCompatibilityVersionを参照してください。

配置のセキュリティ強化

Kubernetes上のMongoDB配置におけるセキュリティには、TLSによるネットワークトラフィックの暗号化と、クライアントおよびクラスターノードの認証という2つの側面があります。どちらも spec.security ブロックの下で設定されます。それらがどのように交流するかを理解することは、セキュアであり機能的な配置を実現する上で非常に重要です。

spec:
  security:
    certsSecretPrefix: "mdb"
    tls:
      enabled: true
      ca: "custom-ca-configmap"

spec:
  security:
    tls:
      enabled: true
    authentication:
      enabled: true
      modes: ["SCRAM", "X509"]
      internalCluster: "X509"

ストレージと永続性

MongoDB はステートフルなワークロードであり、ストレージの構成方法は、パフォーマンス、耐久性、障害からの復旧能力に直接影響します。データ損失が許容できない環境 (つまり、ステータステスト以外のすべての環境) では、spec.persistent フィールドを true に設定する必要があります。永続性が有効になっている場合、Kubernetes 演算子は、Pod の再起動と再スケジューリングによっても残る PersistentVolumeClaims (PVC) を作成します。

spec:
  podSpec:
    persistence:
      multiple:
        data:
          storage: "200Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "50Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "20Gi"
          storageClass: "standard"

spec:
  podSpec:
    persistence:
      single:
        storage: "100Gi"
        storageClass: "standard"

リソース割り当てと Pod テンプレート

MongoDB Pod の CPU とメモリの適正なサイズ設定は、配置時に行う決定の中でも最も影響の大きいものの 1 つであり、ワークロードの進化に伴い再検討する可能性が高いでしょう。Kubernetes Operator は、podSpec (レプリカセットとスタンドアロンの場合)と shardPodSpec、configSrvPodSpec、mongosPodSpec (シャーディングされたクラスターの場合)を通じてリソース制御を公開します。

CPU とメモリの両方に requests と limits を設定すると、Kubernetes は十分なキャパシティーのノードに Pod をスケジュールし、暴走プロセスが同じノード上の他のワークロードに影響するのを防止できます。次の例は、開始点として使用できる構成を示しています。この構成では、リクエストとして少なくとも 2 つの CPU コアと 4 GiB のメモリを持つ本番レプリカセットのノードを作成し、これらの値に一致するか、それを超えるように制限を設定します。

spec:
  podSpec:
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "4Gi"
              limits:
                cpu: "4"
                memory: "8Gi"

Pod テンプレートでは、ラベル、アノテーション、許容範囲、およびアフィニティルールも設定できます。アフィニティルールは、レプリカセットが Kubernetes ノードと障害ドメインにどのように分散されたかを制御するため、本番では特に重要です。

例えば、次のアフィニティルールは、ノードをアベイラビリティーゾーンに分散させて、ゾーンレベルの停止時に備えます。

spec:
  podSpec:
    podTemplate:
      spec:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: my-replica-set
                topologyKey: "topology.kubernetes.io/zone"

podTemplate フィールドの完全なリストについては、仕様リファレンス、特に spec.podSpec.podTemplate.spec.affinity を参照してください。

バックアップの構成

Kubernetes 演算子のバックアップでは、MongoDB Ops Manager にビルドされている継続バックアップ機能が使用されます。有効にすると、MongoDB Ops Manager は oplog をリアルタイムでキャプチャし、定期的なスナップショットを実行します。これらにより、ポイントインタイムの復元が可能になります。これは、最後のスナップショットのタイムスタンプだけでなく、設定された保持期間内の任意の秒に復元できることを意味します。

MongoDB リソースでバックアップを有効にするには、spec.backup.mode を enabled に設定します。次の例に示すように、スナップショットが取られる頻度と保持期間を制御するスナップショットスケジュールを構成することもできます。

spec:
  backup:
    mode: enabled
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 24

組織で保管中のデータのバックアップの暗号化が必要な場合は、次の例に示すように、KMIP準拠のキーマネジメントサーバーと統合できます。

spec:
  backup:
    mode: enabled
    encryption:
      kmip:
        client:
          clientCertificatePrefix: "backup-kmip"

autoTerminateOnDeletionフラグは、MongoDB リソースが削除されたときにバックアップデータがクリーンアップされるかどうかを制御します。非製品環境ではtrueに設定して、オーファンバックアップ状態を回避します。製品環境ではfalseのままにして、事故によるリソース削除後もバックアップデータが残るようにします。

spec:
  backup:
    mode: enabled
    autoTerminateOnDeletion: false

割り当てラベルを使用すると、特定の配置が使用するバックアップ インフラスト（oplog ストア、スナップショット ストア）を制御できます。これは複数の配置が単一の Ops Manager インスタンスを共有する場合に便利です。

バックアップ設定の全セットについては、仕様リファレンスの レプリカセット設定 を参照してください。バックアップインフラスト自体の配置方法を学ぶには、MongoDB データベースのバックアップの構成 を参照してください。

配置を外部に公開する

デフォルトでは、KubernetesのMongoDB配置はクラスター内からのみアクセス可能です。多くのチームは、Kubernetes外で実行されているアプリケーションから、開発中のクライアントツールから、またはマルチリージョンアーキテクチャの別のKubernetesクラスターからデータベースにアクセスする必要があります。

spec.externalAccess ブロックは、Kubernetes Operator に、外部トラフィックを MongoDB Pod にルーティングする Kubernetes Service を作成するように指示します。次の例に示すように、クラウドプロバイダーのロードバランサーをプロビジョニングする LoadBalancer サービスと、すべてのクラスターノードで静的ポートを公開する NodePort サービスから選択できます。

spec:
  externalAccess:
    externalService:
      spec:
        type: LoadBalancer
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

レプリカセットの場合は、クライアント側での接続文字列の構築を簡約化するため、各ノードに予測可能な DNS ホスト名を割り当てるようにexternalDomainを追加で構成できます。

spec:
  externalAccess:
    externalDomain: "mongodb.example.com"
    externalService:
      spec:
        type: LoadBalancer

詳細については、Kubernetes の外から MongoDB Database リソースへの接続を参照してください。

MongoDB Server パラメータのチューニング

MongoDB のチューニング設定のすべてに、カスタム リソースにファーストクラス フィールドがあるわけではありません。Kubernetes Operator の明示的なスキーマに含まれていない設定については、spec.additionalMongodConfig ブロックで任意の mongod 構成オプションを渡すことができます。これらは、MongoDB Ops Manager が適用するサーバー構成に直接翻訳されます。

additionalMongodConfig の一般的な使用方法には、WiredTiger キャッシュ サイズの調整、TLS プロトコル バージョンの制限、またはリスニング ポートの変更があります。詳細は次の例を参照してください。

spec:
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 4

In a sharded cluster, each component (shard, config server, mongos) has its own additionalMongodConfig field, so you can tune them independently. For the full list of supported options, see MongoDB Server Parameters in the MongoDB Manual.

MongoDB Agent 構成

各 MongoDB Pod は、mongod プロセスを管理し、オートメーション タスクを処理し、MongoDB Ops Manager に状態を報告する MongoDB Agent を実行します。次の例に示すように、ログローテーション制限や接続タイムアウトなどのスタートアップ オプションを含め、spec.agent を使用して MongoDB Agent の動作をチューニングできます。

spec:
  agent:
    startupOptions:
      maxLogFiles: "10"
      maxLogFileSize: "100"
      dialTimeout: "20"

spec.logLevel フィールドは、MongoDB Agent のログの冗長を設定します。初期設定またはトラブルシューティング中は DEBUG が非常に役に立つ可能性がありますが、安定した状態の本番環境では INFO または WARN を使用することで、過剰なログボリュームを回避できます。

spec:
  logLevel: "DEBUG"

MongoDB Agent に関連する完全な設定については、仕様リファレンスを参照してください。

マルチクラスター配置

単一の MongoDB 配置を複数の Kubernetes クラスターに分散させる必要があるチームの場合、地理的な多重化、障害復旧、またはデータの主権のために、Kubernetes Operator は複数のクラスタートポロジーをサポートします。spec.topology を MultiCluster に設定すると、Kubernetes 演算子 に、spec.clusterSpecList で定義されたレプリカセットが異なる Kubernetes クラスターに存在することを指示します。次の例に示すように、

spec:
  topology: MultiCluster
  clusterSpecList:
    - clusterName: "cluster-us-east"
      members: 2
    - clusterName: "cluster-us-west"
      members: 2
    - clusterName: "cluster-eu-west"
      members: 1

複数のクラスター配置では、クラスター間のネットワーキング、サービス メッシュ、または外部 DNS 構成などの追加の前提条件が必要になります。続行する前に、複数のクラスターの前提条件と複数のクラスターのアーキテクチャを検討してください。

マルチクラスター仕様フィールドについては、マルチ Kubernetes クラスター仕様を参照してください。

時間の経過とともに MongoDB カスタム リソースの設定を維持する

MongoDB カスタム リソースは一度だけのアーティファクトではありません。チームの要件の進化に合わせて、ノードを増やしたり、シャードを追加したり、バックアップを有効にしたり、TLS 証明書をローテートしたり、MongoDB バージョンをアップグレードしたり、リソース制限を調整したりします。Kubernetes Operator はこのために設計されています。YAML マニフェストを更新し、kubectl apply を使用して適用すると、Kubernetes Operator は変更を漸進的に調和します。

安全な反復のガイドライン:

• ノードを少しずつ増やします。レプリカセットを 1 つずつ追加または除くことにより、選挙の中断のリスクが低減されます。

• バージョンを2ステップでアップグレードします。まず、featureCompatibilityVersionを前のレベルに保持しながらバイナリバージョンを引き上げ、次に安定性を確認してから機能の互換性バージョンを上げます。

• 有効期限切れの前に証明書をローテートします。TLS 証明書には有限の有効期限があります。cert-manager で自動化されたローテーションプロセスを計画し、まず非本番環境でテストします。

• ストレージの変更は慎重にテストしてください。ストレージの変更（ストレージ クラスの切り替えなど）によっては、ボリュームの手動移行が必要になる場合があります。ステージング環境クラスターで常に検証します。

• リソースの状態をモニターします。変更後は、kubectl get mdb でリソースの状態を確認し、Kubernetes Operator ログで調和エラーを確認することで、Kubernetes Operator が変更を正常に調和したことを検証します。

配置を変更するための実際の手順については、「データベースリソースを編集する」を参照してください。

すべてをまとめる

次の例は、このページで説明されている概念を組み合わせて、本番環境で使用できるレプリカセット構成にします。TLS、SCRAM 認証、バックアップ、アンチアフィニティスケジューリング、データ/ジャーナル/ログの分割ボリューム、WiredTiger チューニングが含まれています。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: prod-replica-set
  namespace: mongodb-production
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  featureCompatibilityVersion: "8.0"
  opsManager:
    configMapRef:
      name: prod-project-configmap
  credentials: prod-credentials
  persistent: true
  security:
    certsSecretPrefix: "prod-mdb"
    tls:
      enabled: true
      ca: "prod-ca-configmap"
    authentication:
      enabled: true
      modes: ["SCRAM"]
      internalCluster: "X509"
  backup:
    mode: enabled
    autoTerminateOnDeletion: false
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 48
  podSpec:
    persistence:
      multiple:
        data:
          storage: "500Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "100Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "50Gi"
          storageClass: "standard"
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "8Gi"
              limits:
                cpu: "4"
                memory: "16Gi"
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: prod-replica-set
                topologyKey: "topology.kubernetes.io/zone"
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 8