2.4. Operator Lifecycle Manager (OLM)


2.4.1. Operator Lifecycle Manager の概念およびリソース

Operator Lifecycle Manager (OLM) を理解するための重要な概念には、クラスターサービスバージョン (CSV)、カタログソース、サブスクリプション、および Operator グループが含まれます。

2.4.1.1. Operator Lifecycle Manager (OLM) Classic について

Operator Lifecycle Manager (OLM) Classic は、ユーザーが OpenShift Container Platform クラスター全体で実行される Kubernetes ネイティブアプリケーション (Operator) と関連サービスをインストール、更新、およびそれらのライフサイクルを管理するのに役立ちます。Operator Lifecycle Manager (OLM) Classic は、Operator を効果的、自動的、かつ拡張可能な方法で管理するために設計されたオープンソースのツールキットである Operator Framework の一部を成しています。

図2.2 OLM (Classic) ワークフロー

olm workflow

OLM は OpenShift Container Platform 4.22 でデフォルトで実行されます。これは、クラスター管理者がクラスターで実行される Operator のインストール、アップグレード、およびアクセス権の付与を行うのに役立ちます。OpenShift Container Platform Web コンソールでは、クラスター管理者が Operator をインストールし、特定のプロジェクトアクセスを付与して、クラスターで利用可能な Operator のカタログを使用するための管理画面を利用できます。

開発者の場合は、セルフサービスを使用することで、専門的な知識がなくてもデータベースのインスタンスのプロビジョニングや設定、またモニタリング、ビッグデータサービスなどを実行できます。Operator にそれらに関するナレッジが織り込まれているためです。

2.4.1.2. OLM リソース

以下のカスタムリソース定義 (CRD) は、OpenShift Container Platform の Operator Lifecycle Manager (OLM) によって定義および管理されます。これらのリソースを使用して、カタログソース、サブスクリプション、インストールプラン、クラスターサービスバージョン (CSV)、および Operator グループを設定します。

表2.2 OLM およびカタログ Operators で管理される CRD
リソース短縮名説明

ClusterServiceVersion (CSV)

csv

アプリケーションメタデータ:例: 名前、バージョン、アイコン、必須リソース。

CatalogSource

catsrc

CSV、CRD、およびアプリケーションを定義するパッケージのリポジトリー。

Subscription

sub

パッケージのチャネルを追跡して CSV を最新の状態に保ちます。

InstallPlan

ip

CSV を自動的にインストールするか、アップグレードするために作成されるリソースの計算された一覧。

OperatorGroup

og

OperatorGroup オブジェクトと同じ namespace にデプロイされたすべての Operators を、namespace のリストまたはクラスター全体でカスタムリソース (CR) を監視できるように設定します。

OperatorConditions

-

OLM とそれが管理する Operator との間で通信チャネルを作成します。Operators は Status.Conditions 配列に書き込みを行い、複雑な状態を OLM と通信できます。

2.4.1.2.1. クラスターサービスバージョン

クラスターサービスバージョン (CSV) は、OpenShift Container Platform クラスター上で実行中の Operator の特定のバージョンを表す YAML マニフェストです。OLM は CSV メタデータを使用して、Operator を安全に実行し、新しいバージョンが公開された際にアップグレードを適用する方法を決定します。

CSV には、ユーザーインターフェイスに名前、バージョン、説明、ラベル、リポジトリーリンクおよびロゴなどの情報を設定するために使用される Operator コンテナーイメージに伴うメタデータが含まれます。

CSV は、Operator が管理したり、依存したりするカスタムリソース (CR)、RBAC ルール、クラスター要件、およびインストールストラテジーなどの Operator の実行に必要な技術情報の情報源でもあります。この情報は OLM に対して必要なリソースの作成方法と、Operator をデプロイメントとしてセットアップする方法を指示します。

2.4.1.2.2. カタログソース

カタログソース は、通常コンテナーレジストリーに保存されている インデックスイメージ を参照してメタデータのストアを表します。Operator Lifecycle Manager(OLM) はカタログソースをクエリーし、Operators およびそれらの依存関係を検出してインストールします。OpenShift Container Platform Web コンソールのソフトウェアカタログには、カタログソースによって提供される Operator も表示されます。

ヒント

クラスター管理者は、Web コンソールの Administration Cluster Settings Configuration OperatorHub ページを使用して、クラスターで有効なログソースにより提供される Operators の詳細一覧を表示できます。

CatalogSource オブジェクトの spec は、Pod の構築方法、または Operator Registry gRPC API を提供するサービスとの通信方法を示します。

CatalogSource オブジェクトの例

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog
  namespace: openshift-marketplace
  annotations:
    olm.catalogImageTemplate:
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
spec:
  displayName: Example Catalog
  image: quay.io/example-org/example-catalog:v1
  priority: -400
  publisher: Example Org
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: <security_mode>
    nodeSelector:
      custom_label: <label>
    priorityClassName: system-cluster-critical
    tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
  updateStrategy:
    registryPoll:
      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY
  latestImageRegistryPoll: 2021-08-26T18:46:25Z
  registryService:
    createdAt: 2021-08-26T16:16:37Z
    port: 50051
    protocol: grpc
    serviceName: example-catalog
    serviceNamespace: openshift-marketplace

各項目の説明:

metadata.name
CatalogSource オブジェクトの名前を指定します。この値は、要求された namespace で作成される、関連の Pod 名の一部としても使用されます。
metadata.namespace
カタログを作成する namespace を指定します。カタログを全 namespace のクラスター全体で利用可能にするには、この値を openshift-marketplace に設定します。Red Hat が提供するデフォルトのカタログソースも openshift-marketplace namespace を使用します。それ以外の場合は、値を特定の namespace に設定し、Operator をその namespace でのみ利用可能にします。
metadata.annotations.olm.catalogImageTemplate

クラスターのアップグレードにより、Operator のインストールがサポートされていない状態になったり、更新パスが継続されなかったりする可能性を回避するために、クラスターのアップグレードの一環として、Operator カタログのインデックスイメージのバージョンを自動的に変更するように有効化することができます。このフィールドは任意です。

olm.catalogImageTemplate アノテーションをインデックスイメージ名に設定し、イメージタグのテンプレートを作成する際に、1 つ以上の Kubernetes クラスターバージョン変数を使用します。アノテーションは、実行時に spec.image フィールドを上書きします。詳細は、「カスタムカタログソースのイメージテンプレート」のセクションを参照してください。

spec.displayName
Web コンソールおよび CLI におけるカタログの表示名を指定します。
spec.image
カタログのインデックスイメージを指定します。オプションとして、olm.catalogImageTemplate アノテーションを使用する場合は、この仕様を省略できます。このアノテーションは、実行時にプル仕様を設定します。
spec.priority
カタログソースの重みを指定します。OLM は重みを使用して依存関係の解決時に優先順位付けします。重みが大きい場合は、カタログが重みの小さいカタログよりも優先されることを示します。
spec.sourceType

以下のソースタイプのいずれかを指定します。

  • image 参照のある grpc: OLM はイメージをポーリングし、Pod を実行します。これにより、準拠 API が提供されることが予想されます。
  • address フィールドのある grpc: OLM は所定アドレスでの gRPC API へのアクセスを試行します。これはほとんどの場合使用することができません。
  • configmap: OLM は config map データを解析し、gRPC API を提供できる Pod を実行します。
spec.grpcPodConfig.securityContextConfig

カタログソース Pod の Pod セキュリティーアドミッション (PSA) ポリシーを指定します。legacy または restricted の値を受け入れます。フィールドが設定されていない場合、デフォルト値は legacy です。今後の OpenShift Container Platform リリースでは、デフォルト値が restricted になる予定です。

注記

restricted 権限でカタログを実行できない場合は、このフィールドを手動で legacy に設定することを推奨します。

spec.grpcPodConfig.nodeSelector
grpc タイプカタログソースの spec.image 内のコンテンツを提供する Pod のデフォルトのノードセレクターをオーバーライドします。このフィールドは任意です。
spec.grpcPodConfig.priorityClassName
grpc タイプカタログソースの spec.image 内のコンテンツを提供する Pod のデフォルトのプライオリティークラス名をオーバーライドします。Kubernetes は、デフォルトで優先度クラス system-cluster-critical および system-node-critical を提供します。フィールドを空 ("") に設定すると、Pod にデフォルトの優先度が割り当てられます。他の優先度クラスは、手動で定義できます。このフィールドは任意です。
spec.grpcPodConfig.tolerations
grpc タイプカタログソースの spec.image 内のコンテンツを提供する Pod のデフォルトの toleration をオーバーライドします。このフィールドは任意です。
spec.updateStrategy.registryPoll
OLM がコンテナーレジストリーの更新をポーリングする頻度を指定します。
status.connectionState.lastObservedState

カタログ接続の直近の観測状態を表示します。以下に例を示します。

  • READY: 接続が正常に確立されました。
  • CONNECTING: 接続が確立中です。
  • TRANSIENT_FAILURE: タイムアウトなど、接続の確立時一時的な問題が発生しました。状態は最終的に CONNECTING に戻り、再試行されます。
status.latestImageRegistryPoll
OLM がカタログイメージの更新用にコンテナーレジストリーをポーリングした最後の時刻を表示します。
status.registryService
カタログの Operator Registry サービスのステータス情報を表示します。

サブスクリプションの CatalogSource オブジェクトの name を参照すると、要求された Operator を検索する場所を、OLM に指示します。

カタログソースを参照する Subscription オブジェクトの例

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

2.4.1.2.2.1. カスタムカタログソースのイメージテンプレート

基礎となるクラスターとの Operator との互換性は、さまざまな方法でカタログソースにより表現できます。1 つの方法は、OpenShift Container Platform 4.22 など、特定のプラットフォームリリース用に特別に作成したインデックスイメージのイメージタグを指定することです。この方法は、デフォルトの Red Hat 提供のカタログソースに使用されています。

クラスターのアップグレード時に、Red Hat が提供するデフォルトのカタログソースのインデックスイメージのタグは、Operator Lifecycle Manager (OLM) が最新版のカタログをプルするように、Cluster Version Operator (CVO) により自動更新されます。たとえば、OpenShift Container Platform 4.21 から 4.22 へのアップグレード時に、redhat-operators カタログの CatalogSource オブジェクトの spec.image フィールドは以下のようになります。

registry.redhat.io/redhat/redhat-operator-index:v4.22

更新後は次のようになります。

registry.redhat.io/redhat/redhat-operator-index:v4.22

ただし、CVO ではカスタムカタログのイメージタグは自動更新されません。クラスターのアップグレード後、ユーザーが互換性があり、サポート対象の Operator のインストールを確実に行えるようにするには、カスタムカタログも更新して、更新されたインデックスイメージを参照する必要があります。

OpenShift Container Platform 4.9 以降、クラスター管理者はカスタムカタログの CatalogSource オブジェクトの olm.catalogImageTemplate アノテーションを、テンプレートなどのイメージ参照に追加できます。以下の Kubernetes バージョン変数は、テンプレートで使用できるようにサポートされています。

  • kube_major_version
  • kube_minor_version
  • kube_patch_version
注記

OpenShift Container Platform クラスターのバージョンはテンプレートに現在使用できないため、Kubernetes クラスターのバージョンを指定する必要があります。

更新された Kubernetes バージョンを指定するタグでインデックスイメージを作成してプッシュしている場合に、このアノテーションを設定すると、カスタムカタログのインデックスイメージのバージョンがクラスターのアップグレード後に自動的に変更されます。アノテーションの値は、CatalogSource オブジェクトの spec.image フィールドでイメージ参照を設定したり、更新したりするために使用されます。こうすることで、サポートなしの状態や、継続する更新パスなしの状態で Operator がインストールされないようにします。

重要

格納されているレジストリーがどれであっても、クラスターのアップグレード時に、クラスターが、更新されたタグを含むインデックスイメージにアクセスできるようにする必要があります。

例2.4 イメージテンプレートを含むカタログソースの例

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog
  namespace: openshift-marketplace
  annotations:
    olm.catalogImageTemplate:
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}"
spec:
  displayName: Example Catalog
  image: quay.io/example-org/example-catalog:v1.35
  priority: -400
  publisher: Example Org
注記

spec.image フィールドおよび olm.catalogImageTemplate アノテーションの両方が設定されている場合には、spec.image フィールドはアノテーションから解決された値で上書きされます。アノテーションが使用可能なプル仕様に対して解決されない場合は、カタログソースは spec.image 値にフォールバックします。

spec.image フィールドが設定されていない場合に、アノテーションが使用可能なプル仕様に対して解決されない場合は、OLM はカタログソースの調整を停止し、人間が判読できるエラー条件に設定します。

Kubernetes 1.35 を使用する OpenShift Container Platform 4.22 クラスターでは、前述の例の olm.catalogImageTemplate アノテーションは以下のイメージ参照に解決されます。

quay.io/example-org/example-catalog:v1.35

OpenShift Container Platform の今後のリリースでは、より新しい OpenShift Container Platform バージョンが使用する、より新しい Kubernetes バージョンを対象とした、カスタムカタログの更新済みインデックスイメージを作成できます。アップグレード前に olm.catalogImageTemplate アノテーションを設定してから、クラスターを新しい OpenShift Container Platform バージョンにアップグレードすると、カタログのインデックスイメージも自動的に更新されます。

2.4.1.2.2.2. カタログの正常性要件

Operator Lifecycle Manager (OLM) では、共有グローバル namespace 内のすべての Operator カタログが正常な状態である必要があります。カタログが正常でない場合、その namespace における Operator のインストールおよび更新操作は、CatalogSourcesUnhealthy 状態により失敗します。

クラスター上の Operator カタログは、インストール解決の観点から相互に置き換え可能です。Subscription オブジェクトは特定のカタログを参照する場合がありますが、依存関係はクラスターのすべてのカタログを使用して解決されます。

たとえば、カタログ A が正常でない場合、カタログ A を参照するサブスクリプションはカタログ B の依存関係を解決する可能性があります。通常、B のカタログ優先度は A よりも低いため、クラスター管理者はこれおを想定していない可能性があります。

クラスター管理者として、正常でないカタログが見つかった際にそのカタログを無効とみなして Operator のインストールを再開する場合は、「カスタムカタログの削除」または「デフォルトのソフトウェアカタログソースの無効化」セクションで、正常でないカタログを削除する方法を確認してください。

2.4.1.2.3. サブスクリプション

サブスクリプション は、Subscription オブジェクトによって定義され、Operator をインストールする意図を表します。これは、Operator をカタログソースに関連付けるカスタムリソースです。

サブスクリプションは、サブスクライブする Operator パッケージのチャネルや、更新を自動または手動で実行するかどうかを記述します。サブスクリプションが自動に設定された場合、Operator Lifecycle Manager (OLM) が Operator を管理し、アップグレードして、最新バージョンがクラスター内で常に実行されるようにします。

Subscription オブジェクトの例

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

この Subscription オブジェクトは、Operator の名前と namespace、および Operator データのあるカタログを定義します。alpha、beta、または stable などのチャネルは、カタログソースからインストールする必要のある Operator ストリームを判別するのに役立ちます。

サブスクリプションのチャネルの名前は Operators 間で異なる可能性がありますが、命名スキームは指定された Operator 内の一般的な規則に従う必要があります。たとえば、チャネル名は Operator によって提供されるアプリケーションのマイナーリリース更新ストリーム (1.2、1.3) またはリリース頻度 (stable、fast) に基づく可能性があります。

OpenShift Container Platform Web コンソールから簡単に表示されるだけでなく、関連するサブスクリプションのステータスを確認して、Operator の新規バージョンが利用可能になるタイミングを特定できます。currentCSV フィールドに関連付けられる値は OLM に認識される最新のバージョンであり、installedCSV はクラスターにインストールされるバージョンです。

2.4.1.2.4. インストール計画

InstallPlan オブジェクトによって定義される インストール計画 は、Operator Lifecycle Manager(OLM) が特定バージョンの Operator をインストールまたはアップグレードするために作成するリソースのセットを記述します。バージョンはクラスターサービスバージョン (CSV) で定義されます。

Operator、クラスター管理者、または Operator インストールパーミッションが付与されているユーザーをインストールするには、まず Subscription オブジェクトを作成する必要があります。サブスクリプションでは、カタログソースから利用可能なバージョンの Operator のストリームにサブスクライブする意図を表します。次に、サブスクリプションは InstallPlan オブジェクトを作成し、Operator のリソースのインストールを容易にします。

その後、インストール計画は、以下の承認ストラテジーのいずれかをもとに承認される必要があります。

  • サブスクリプションの spec.installPlanApproval フィールドが Automatic に設定されている場合には、インストール計画は自動的に承認されます。
  • サブスクリプションの spec.installPlanApproval フィールドが Manual に設定されている場合には、インストール計画はクラスター管理者または適切なパーミッションが割り当てられたユーザーによって手動で承認する必要があります。

インストール計画が承認されると、OLM は指定されたリソースを作成し、サブスクリプションで指定された namespace に Operator をインストールします。

例2.5 InstallPlan オブジェクトの例

apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
  name: install-abcde
  namespace: operators
spec:
  approval: Automatic
  approved: true
  clusterServiceVersionNames:
    - my-operator.v1.0.1
  generation: 1
status:
  ...
  catalogSources: []
  conditions:
    - lastTransitionTime: '2021-01-01T20:17:27Z'
      lastUpdateTime: '2021-01-01T20:17:27Z'
      status: 'True'
      type: Installed
  phase: Complete
  plan:
    - resolving: my-operator.v1.0.1
      resource:
        group: operators.coreos.com
        kind: ClusterServiceVersion
        manifest: >-
        ...
        name: my-operator.v1.0.1
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1alpha1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: apiextensions.k8s.io
        kind: CustomResourceDefinition
        manifest: >-
        ...
        name: webservers.web.servers.org
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1beta1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: ''
        kind: ServiceAccount
        manifest: >-
        ...
        name: my-operator
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: Role
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: RoleBinding
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
      ...
2.4.1.2.5. Operator グループ

Operator グループは、OperatorGroup リソースを通じて、OLM にインストールされた Operator のマルチテナント設定を定義します。Operator グループは、メンバー Operator に必要な RBAC アクセスが生成されるターゲット namespaces を選択します。

ターゲット namespace のセットは、クラスターサービスバージョン (CSV) の olm.targetNamespaces アノテーションに保存されるコンマ区切りの文字列によって指定されます。このアノテーションは、メンバー Operator の CSV インスタンスに適用され、そのデプロイメントに反映されます。

関連情報

2.4.1.2.6. Operator 条件

Operator Lifecycle Manager (OLM) は Kubernetes リソースから Operator の状態を推測しますが、一部の条件では明示的な通信が必要です。OperatorCondition カスタムリソース定義 (CRD) を使用すると、ライフサイクル管理に影響を与えるサポート対象の条件を OLM に通知できます。

注記

デフォルトでは、Spec.Conditions 配列は、ユーザーによって追加されるか、カスタム Operator ロジックの結果として追加されるまで、OperatorCondition オブジェクトに存在しません。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る