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 は 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 グループを設定します。
| リソース | 短縮名 | 説明 |
|---|---|---|
|
|
| アプリケーションメタデータ:例: 名前、バージョン、アイコン、必須リソース。 |
|
|
| CSV、CRD、およびアプリケーションを定義するパッケージのリポジトリー。 |
|
|
| パッケージのチャネルを追跡して CSV を最新の状態に保ちます。 |
|
|
| CSV を自動的にインストールするか、アップグレードするために作成されるリソースの計算された一覧。 |
|
|
|
|
|
| - |
OLM とそれが管理する Operator との間で通信チャネルを作成します。Operators は |
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
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-marketplacenamespace を使用します。それ以外の場合は、値を特定の 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 オブジェクトに存在しません。