コンテナのイメージ
Kubernetes Operator をインストールすると、Qui.ioコンテナレジストリからイメージがプルされます。 Kubernetes Operator のイメージは、 Red Hat UBI オペレーティング8 システムに基づいています。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
を使用して静的コンテナ間でファイルをコピーすることはできません。
注意
静的コンテナとして配置する場合、 Kubernetes Operator の配置は、mongodb-agent
コンテナと mongodb-enterprise-server
コンテナの 2 つのコンテナで構成されます。MongoDBデータベースのカスタムリソースは、静的コンテナ配置で mongod
プロセスを実行する mongodb-agent
コンテナからリソース制限の定義を継承します。MongoDBデータベースリソースのリソース制限を変更するには、mongodb-agent
コンテナに必要なリソース制限を指定する必要があります。
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 のバイナリをダウンロードすることを前提としています。
静的コンテナ アーキテクチャ
静的コンテナ アーキテクチャは、Kubernetes の 共有名前空間機能 を使用します MongoDB Agent を別のプロセスとして実行することで、完全なmongod
ライフサイクルを制御し、ネットワーク経由でのファイルのダウンロードを回避できます。
ローカル モードまたはリモート モードとの互換性
静的コンテナを使用する場合は、クエリ可能なバックアップを使用しない限り、 MongoDB Ops Managerを ローカル モードまたはリモート モードで実行するように構成する必要はありません。 静的コンテナ アーキテクチャでは、エージェントと mongod
のバイナリに独自のコンテナ イメージがあり、これらはMongoDB Ops Managerからダウンロードされません。
クエリ可能なバックアップは例外です。非静的コンテナ アーキテクチャでは、デフォルトでは、バックアップデーモンがバックアップされているすべてのバージョンの MongoDB Server バイナリをダウンロードして実行します。 このデフォルトの MongoDB 動作は、バックアップデーモンの実行に使用されるコンテナの完全に静的な性質を低下させます。 クエリ可能なバックアップを使用する場合は、ローカル モードまたはリモート モードを使用して、関連する MongoDB Server バイナリをホストする必要があります。 詳細については、「ローカル モードを使用するようにMongoDB Ops ManagerリソースをMongoDB Ops Managerする 」または「 リモート モードを使用するように MongoDB Ops Manager リソースを構成する 」を参照してください。
以前にリモート モードまたはローカル モードを使用していて、クエリ可能なバックアップを使用しない場合は、次の操作を行って、mongodb-enterprise-server
がイメージ は ノード でダウンロードできます ポッドによって使用される場合があります。
Kubernetes ノードの内部コンテナ レジストリを構成します。
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 はヘルス ステータス ファイルを置き換えるため、バージョンの変更が発生したことはヘルス ステータスからは判断できず、現在のヘルス ステータスのみが置き換えられます。
FAQ
静的コンテナはローカル モードとリモート モードをサポートしていますか?
いいえ、静的コンテナを使用する場合は、クエリ可能なバックアップを使用しない限り、 MongoDB Ops Managerをローカル モードまたはリモート モードで実行するように構成する必要はありません。 詳しくは、「ローカル モードとリモート モード 」を参照してください。
静的コンテナの変更は何ですか。
静的コンテナは実行時に MongoDB バイナリをダウンロードしません。 代わりに、 mongodb-enterprise-server のイメージを使用します。 Qui.io リポジトリを参照してください。変更の詳細については、ステップ6を参照してください。
配置が静的に実行されているかどうかを確認するにはどうすればよいですか。
配置で静的コンテナが使用されているかどうかを判断するには、さまざまな方法があります。 詳しくは、ステップ7を参照してください。
静的コンテナへの移行
非静的コンテナから静的コンテナに移行するには、MongoDB Agent 環境変数を設定し、以下の手順に従って静的コンテナを有効にします。 インストールまたはアップグレード時に静的コンテナを有効にすることもできます。
制限事項 を確認します。
クエリ可能なバックアップを無効にします。
「クエリ可能なバックアップを無効にする 」の手順に従います。
クエリ可能なバックアップ を使用する場合は、使用中のすべてのバージョンのバイナリを からプルできるように、MongoDB Ops Manager リソースを ローカル モード または リモート モードMongoDB Ops Manager を使用するように構成する必要があります。
初期化コンテナのステートフルセット オーバーライドがある場合は、削除します。
静的コンテナアーキテクチャでは、初期化コンテナは使用されません。 初期コンテナのオーバーライドが存在する場合、非静的コンテナから静的コンテナへの移行は失敗します。
MongoDB Ops ManagerMongoDBリソース仕様 またはMongoDB Ops MongoDBManagerリソース仕様 から初期化コンテナの Atlas Set オーバーライドを削除します。例、initContainers
で次の設定のいずれも構成されていないことを確認します。
MongoDB Ops Manager :
spec.statefulSet.spec
アプリケーション データベース :
spec.applicationDatabase.podSpec
Database: StateftSet 設定
マルチクラスター: spec. StateftSet.spec
MongoDB Agent イメージの環境変数を設定します。
Kubernetes Operator Helm チャートで、 registry.agentとAgent.nameを定義し、Kubernetes Operator が静的コンテナ用に MongoDB Agent イメージをダウンロードするリポジトリを指定します。
ファイルを保存して適用します。
変更を保存した後、構成を再適用します。
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'
これにより、配置内のすべてのポッドのローリング再起動が開始されます。
静的コンテナを有効にします。
以下の適切なタブを選択して、既存の配置を含むすべての MongoDB 配置の静的コンテナを一度に有効にする、または一度に 1 つの配置を有効にします。
Kubernetes Operator の構成ファイルで、 MDB_DEFAULT_ARCHIVECUREまたはオペレーター.mdbDefaultアーキテクチャを設定します からstatic
へのリンク
特定の配置のMongoDB リソース仕様で、 metadata.annotations.mongodb.com/v1.architecture
アノテーションをstatic
に設定します。
ファイルを保存して適用します。
変更を保存した後、構成を再適用します。
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 つの個別のコンテナを持つ新しい構成に移行します。この更新により、ローリング再起動が開始されます。
静的コンテナに移行すると、次の変更が適用されます。
非静的コンテナへの移行
静的コンテナから非静的コンテナに移行するには、以下の手順に従って静的コンテナを無効にします。 インストールまたはアップグレード中に静的コンテナを無効にすることもできます。
静的コンテナを無効にします。
既存の配置を含むすべての MongoDB 配置の静的コンテナ、または一度に 1 つの配置を無効にするには、以下の適切なタブを選択します。
Kubernetes Operator の構成ファイルで、 MDB_DEFAULT_ARCHIVECUREまたはオペレーター.mdbDefaultアーキテクチャを設定します からnon-static
へのリンク
特定の配置のMongoDB リソース仕様で、 metadata.annotations.mongodb.com/v1.architecture
アノテーションをnon-static
に設定します。
ファイルを保存して適用します。
変更を保存した後、構成を再適用します。
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 配置のイメージを作成し、配置内のすべてのポッドのローリング再起動を開始します。