Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/ /

コンテナのイメージ

項目一覧

  • 静的コンテナ(パブリック プレビュー)
  • アーキテクチャ
  • ローカル モードまたはリモート モードとの互換性
  • 制限
  • FAQ
  • 静的コンテナへの移行
  • 非静的コンテナへの移行

Kubernetes Operator をインストールすると、Qui.io コンテナ レジストリからイメージがプルされます。 Kubernetes Operator のイメージは、 Red Hat UBI8 に基づいています。 オペレーティング システム。MongoDB は、最新のオペレーティング システムとライブラリの更新をサポートするために Kubernetes Operator イメージを毎日再構築します。

公式イメージには、次の利点があります。

  • 最新のアップストリームの脆弱性修正のために毎日再ビルドされます。

  • MongoDB は、それらをテスト、維持、サポートします。

各イメージで利用可能なすべてのバージョンを表示するには、次のリンクを参照してください。

イメージ名
説明
MongoDB Agent のイメージ。
静的コンテナとアプリケーションデータベースに使用される Enterprise MongoDB イメージ。
initContainer アプリケーション データベースのスタートアップ スクリプトと準備状況調査が含まれるイメージ。
非静的コンテナに使用される MongoDB Database 環境イメージ。 静的コンテナと非静的コンテナの詳細については、「静的コンテナ(パブリック プレビュー) 」を参照してください。
initContainer MongoDB Agent 。
MongoDB Ops Managerのイメージ。
initContainer MongoDB Ops Manager のスタートアップ スクリプトと準備状況調査が含まれるイメージ。

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

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

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

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

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

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

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

MongoDBEnterprise Kubernetes Operator1.25以降では、既存の非静的コンテナの代わりに静的コンテナのパブリック プレビューを使用できます。これにより、実行時にMongoDB Cloud ManagerまたはMongoDB Ops Manager またはインターネットから バイナリがダウンロードされます。このページの手順を使用して、すべてまたは個々の MongoDB 配置の静的コンテナを有効または無効にできます。

静的コンテナは mongodb-enterprise-server のイメージを使用します デフォルトでは Query.io リポジトリを使用しますが、Kubernetes ノード に独自のレジストリを構成した場合は独自のレジストリを使用できます 。

静的コンテナと非静的コンテナのアーキテクチャは大きく異なるため、一方からもう一方の要素に移行するにはいくつかの手順が必要です。 詳細については、「静的コンテナへの移行 」および「非静的コンテナへの移行 」を参照してください。

デフォルトの非静的コンテナMongoDB Agent アーキテクチャでは、空の shellmongod コンテナをブートストラップすること、mongosh をダウンロードして起動すること、によりCloud Manager または から とMongoDB Ops Manager のバイナリをダウンロードすることを前提としています。

MongoDB Enterprise Kubernetes Operator を使用して構成された非静的コンテナを持つ MongoDB 配置の高レベルのアーキテクチャを示す図。
クリックして拡大します

静的コンテナ アーキテクチャは、Kubernetes の 共有名前空間機能 を使用します MongoDB Agent を別のプロセスとして実行することで、完全なmongod ライフサイクルを制御し、ネットワーク経由でのファイルのダウンロードを回避できます。

MongoDB Enterprise Kubernetes Operator を使用して構成された静的コンテナを持つ MongoDB 配置の高レベルのアーキテクチャを示す図。
クリックして拡大します

静的コンテナを使用する場合は、クエリ可能なバックアップを使用しない限り、 MongoDB Ops Managerを ローカル モードまたはリモート モードで実行するように構成する必要はありません。 静的コンテナ アーキテクチャでは、エージェントと mongod のバイナリに独自のコンテナ イメージがあり、これらはMongoDB Ops Managerからダウンロードされません。

クエリ可能なバックアップは例外です。非静的コンテナ アーキテクチャでは、デフォルトでは、バックアップデーモンがバックアップされているすべてのバージョンの MongoDB Server バイナリをダウンロードして実行します。 このデフォルトの MongoDB 動作は、バックアップデーモンの実行に使用されるコンテナの完全に静的な性質を低下させます。 クエリ可能なバックアップを使用する場合は、ローカル モードまたはリモート モードを使用して、関連する MongoDB Server バイナリをホストする必要があります。 詳細については、「ローカル モードを使用するようにMongoDB Ops ManagerリソースをMongoDB Ops Managerする 」または「 リモート モードを使用するように MongoDB Ops Manager リソースを構成する 」を参照してください。

以前にリモート モードまたはローカル モードを使用していて、クエリ可能なバックアップを使用しない場合は、次の操作を行って、mongodb-enterprise-server がイメージ ノード でダウンロードできます ポッドによって使用される場合があります。

  1. Kubernetes ノードの内部コンテナ レジストリを構成します。

    ノード Qui.io からイメージをダウンロードします ローカル コンテナ レジストリを使用する場合を除きます。

  2. mongodb-enterprise-serverイメージをダウンロードして追加します。

静的コンテナを有効にする場合:

  • バックアップデーモン サービスMongoDB がMongoDB Ops Manager から バイナリをダウンロードしようとしないように、 クエリ可能なバックアップ を 無効 にする 必要があります。これにより、静的コンテナの不変の性質が損なわれます。

  • MongoDB Ops Managerでは、バージョン 6.0.24 のみ、 7.0.5 、またはそれ以降と互換性があります。 KubernetesOperatorMongoDB Agent は、特定の配置を管理するために、選択した バージョンに基づいて、正しいバージョンのMongoDB Ops Manager コンテナを自動的に使用します。

  • MongoDB Cloud Manager では、Kubernetes Operator が MongoDB Cloud Manager のagentVersionエンドポイントを呼び出されないため、MongoDB Agent バージョンが MongoDB Cloud Manager の最新バージョンとの互換性を失う可能性があります。 MongoDB Agent が MongoDB Cloud Manager で最新の状態になるようにするには、次のいずれかのアクションを実行します。

    • ステートフルセット をオーバーライドして、 MongoDB リソース仕様 互換性 のある MongoDB Agent のバージョンを指定する MongoDB Agent のコンテナ イメージ。例:

      podSpec:
      podTemplate:
      spec:
      containers:
      - name: mongodb-agent-ubi
      Image: 12.0.29.7785-1_1.24.0
    • Kubernetes Operator を最新バージョンにアップグレードすると、MongoDB Agent が自動的に更新されます。

  • MongoDB のバージョンをアップグレードすると、最後から最初の順に、すべての ポッドのローリング再起動がトリガーされ、最大でポッドの数まで増加する選挙が発生する可能性があります。 これは、ローリング再起動をtriggerするすべての更新に当てはまります。

  • MongoDB Agent の ステータスから、MongoDB database のアップグレードが行われたかどうかを判断することはできません。 アップグレード後に Kubernetes がポッドをローテーションすると、MongoDB Agent はヘルス ステータス ファイルを置き換えるため、バージョンの変更が発生したことはヘルス ステータスからは判断できず、現在のヘルス ステータスのみが置き換えられます。

いいえ、静的コンテナを使用する場合は、クエリ可能なバックアップを使用しない限り、 MongoDB Ops Managerをローカル モードまたはリモート モードで実行するように構成する必要はありません。 詳しくは、「ローカル モードとリモート モード 」を参照してください。

静的コンテナは実行時に MongoDB バイナリをダウンロードしません。 代わりに、 mongodb-enterprise-server のイメージを使用します。 Qui.io リポジトリを参照してください。変更の詳細については、ステップ6を参照してください。

配置で静的コンテナが使用されているかどうかを判断するには、さまざまな方法があります。 詳しくは、ステップ7を参照してください。

非静的コンテナから静的コンテナに移行するには、MongoDB Agent 環境変数を設定し、以下の手順に従って静的コンテナを有効にします。 インストールまたはアップグレード時に静的コンテナを有効にすることもできます。

1
2

クエリ可能なバックアップを無効にする 」の手順に従います。

クエリ可能なバックアップ を使用する場合は、使用中のすべてのバージョンのバイナリを からプルできるように、MongoDB Ops Manager リソースを ローカル モード または リモート モードMongoDB Ops Manager を使用するように構成する必要があります。

3

Kubernetes Operator の構成ファイルで、 MDB_AGEN環境変数を定義し、Kubernetes Operator が静的コンテナ用の MongoDB Agent イメージをダウンロードするリポジトリを指定します。

Kubernetes Operator Helm チャートで、 registry.agentAgent.nameを定義し、Kubernetes Operator が静的コンテナ用に MongoDB Agent イメージをダウンロードするリポジトリを指定します。

4

変更を保存した後、構成を再適用します。

OpenShift なしで Kubernetes を使用している場合は、次を実行します。

kubectl apply -f mongodb-enterprise.yaml

OpenShift で Kubernetes を使用する場合:

oc apply -f mongodb-enterprise-openshift.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \
--set registry.pullPolicy='IfNotPresent'

これにより、配置内のすべてのポッドのローリング再起動が開始されます。

5

以下の適切なタブを選択して、既存の配置を含むすべての MongoDB 配置の静的コンテナを一度に有効にする、または一度に 1 つの配置を有効にします。

Kubernetes Operator の構成ファイルで、 MDB_DEFAULT_ARCHIVECUREまたはオペレーター.mdbDefaultアーキテクチャを設定します からstaticへのリンク

特定の配置のMongoDB リソース仕様で、 metadata.annotations.mongodb.com/v1.architectureアノテーションをstaticに設定します。

6

変更を保存した後、構成を再適用します。

OpenShift なしで Kubernetes を使用している場合は、次を実行します。

kubectl apply -f <my-config-file>.yaml

OpenShift で Kubernetes を使用する場合:

oc apply -f <my-config-file>.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \
--set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"

Kubernetes 演算子によるステートメント更新 MongoDB 配置のイメージは、以前は MongoDB Agent と MongoDB database の両方を管理していた単一のコンテナから、MongoDB Agent 用と MongoDB データベース用の 2 つの個別のコンテナを持つ新しい構成に移行します。この更新により、ローリング再起動が開始されます。

静的コンテナに移行すると、次の変更が適用されます。

  • Kubernetes ノード 構成されたコンテナ レジストリを使用してダウンロードを実行します。

  • モニタリングエージェントとオートメーションエージェントのバージョンは一致しています。

  • エージェントではなく Kubernetes Operator が MongoDB のアップグレードを処理します。

  • Kubernetes Operator は既存のイメージを置き換え、ローリング再起動を発生させます。

7
  • 次のいずれかの変数の値を確認します。この変数はstaticに設定する必要があります。

    MDB_DEFAULT_ARCHITECTURE
    すべての配置で変数。
    metadata.annotations[mongodb.com/v1.architecture]
    配置ごとの変数。
  • データベースの配置をチェックして、エージェントと MongoDB の 2 つの個別のイメージが使用されていることを確認し、初期化コンテナが配置されていないことを確認します。

静的コンテナから非静的コンテナに移行するには、以下の手順に従って静的コンテナを無効にします。 インストールまたはアップグレード中に静的コンテナを無効にすることもできます。

1

既存の配置を含むすべての MongoDB 配置の静的コンテナ、または一度に 1 つの配置を無効にするには、以下の適切なタブを選択します。

Kubernetes Operator の構成ファイルで、 MDB_DEFAULT_ARCHIVECUREまたはオペレーター.mdbDefaultアーキテクチャを設定します からnon-staticへのリンク

特定の配置のMongoDB リソース仕様で、 metadata.annotations.mongodb.com/v1.architectureアノテーションをnon-staticに設定します。

2

変更を保存した後、構成を再適用します。

OpenShift なしで Kubernetes を使用している場合は、次を実行します。

kubectl apply -f <my-config-file>.yaml

OpenShift で Kubernetes を使用する場合:

oc apply -f <my-config-file>.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \
--set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="non-static"

Kubernetes 演算子へのステートメント MongoDB 配置のイメージを作成し、配置内のすべてのポッドのローリング再起動を開始します。

戻る

互換性