7.2. コンポーネントとアーキテクチャー

Operator Lifecycle Manager (OLM) 1.0 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。

次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。

CR でチャネルを指定すると、OLM 1.0 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM 1.0 はそのチャネルから解決できる最新リリースに自動的に更新します。

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: latest 1

CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM 1.0 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM 1.0 はターゲットバージョンを変更しません。

クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: 1.11.1 1

Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM 1.0 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: >1.11.1 1

CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。

$ oc apply -f <extension_name>.yaml

Bundle オブジェクトが API サーバーによって受け入れられると、そのバンドルは RukPak システムの残りの部分によって不変のアーティファクトと見なされます。この動作により、バンドルはクラスターにソーシングする一意の静的なコンテンツを表すという概念が適用されます。ユーザーは、特定のバンドルが特定の一連のマニフェストを指していて、新しいバンドルを作成しないと更新できないという確信を持つことができます。このプロパティーは、スタンドアロンバンドルと、組み込みの BundleTemplate オブジェクトによって作成された動的バンドルの両方に当てはまります。

バンドルの不変性は、コア RukPak Webhook によって適用されます。この Webhook は Bundle オブジェクトイベントを監視し、バンドルの更新について、既存のバンドルの spec フィールドが提案された更新されたバンドルのそれと意味的に等しいかどうかをチェックします。それらが等しくない場合、更新は Webhook によって拒否されます。metadata や status などの他の Bundle オブジェクトフィールドは、バンドルのライフサイクル中に更新されます。不変と見なされるのは spec フィールドのみです。

Bundle オブジェクトを適用してからその仕様を更新しようとすると失敗するはずです。たとえば、次の例はバンドルを作成します。

$ oc apply -f -<<EOF
apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: combo-tag-ref
spec:
  source:
    type: git
    git:
      ref:
        tag: v0.0.2
      repository: https://github.com/operator-framework/combo
  provisionerClassName: core-rukpak-io-plain
EOF

bundle.core.rukpak.io/combo-tag-ref created

次に、新しいタグを指すようにバンドルにパッチを適用すると、エラーが返されます。

$ oc patch bundle combo-tag-ref --type='merge' -p '{"spec":{"source":{"git":{"ref":{"tag":"v0.0.3"}}}}}'

Error from server (bundle.spec is immutable): admission webhook "vbundles.core.rukpak.io" denied the request: bundle.spec is immutable

コアの RukPak 受付 Webhook は、バンドルの仕様が不変であるため、パッチを拒否しました。バンドルのコンテンツを変更するための推奨される方法は、インプレースで更新するのではなく、新しい Bundle オブジェクトを作成することです。

不変性に関するその他の考慮事項

Bundle オブジェクトの spec フィールドは不変ですが、基本となる spec フィールドを変更せずに、BundleDeployment オブジェクトを新しいバージョンのバンドルコンテンツにピボットすることは可能です。この意図しないピボットは、次のシナリオで発生する可能性があります。

このシナリオが発生した場合、手順 2 の新しいコンテンツは、手順 3 の結果としてアンパックされます。バンドルのデプロイメントにより、変更が検出され、新しいバージョンのコンテンツにピボットされます。

これは、Pod のコンテナーイメージの 1 つがタグを使用し、そのタグが別のダイジェストに移動され、将来のある時点で既存の Pod が別のノードで再スケジュールされる Pod の動作に似ています。その時点で、ノードは新しいダイジェストで新しいイメージをプルし、ユーザーが明示的に要求することなく別の何かを実行します。

基になる Bundle 仕様コンテンツが変更されないことを確信するには、バンドルを作成するときにダイジェストベースのイメージまたは Git コミット参照を使用します。

RukPak のプレーンバンドルは、特定のディレクトリーにある静的で任意の Kubernetes YAML マニフェストのコレクションです。

現在実装されているプレーンバンドル形式は、plain+v0 形式です。バンドル形式の名前 plain+v0 は、バンドルのタイプ (plain) と現在のスキーマバージョン (v0) を組み合わせたものです。

たとえば、以下は、plain+v0 バンドルのファイルツリーを示しています。アプリケーションのデプロイに必要な Kubernetes リソースを含む manifests/ ディレクトリーが必要です。

$ tree manifests

manifests
├── namespace.yaml
├── service_account.yaml
├── cluster_role.yaml
├── cluster_role_binding.yaml
└── deployment.yaml

静的マニフェストは、プロビジョナーがアンパックできる有効な plain+v0 バンドルになるように、少なくとも 1 つのリソースを含む manifests/ ディレクトリーに配置する必要があります。manifests/ ディレクトリーもフラットである必要があります。すべてのマニフェストは、サブディレクトリーのない最上位にある必要があります。

レジストリーバンドル、または registry+v1 バンドルには、従来の Operator Lifecycle Manager (OLM) バンドル形式で編成された一連の静的 Kubernetes YAML マニフェストが含まれています。

ユーザーは、次の依存関係を持つパッケージ A および B をインストールしたいと考えています。

さらに、ユーザーは A のバージョンを v0.1.0 に固定したいと考えています。

OLM 1.0 に渡されたパッケージと制約

ユーザーは、次の依存関係を持つパッケージ A および B をインストールしたいと考えています。

さらに、ユーザーは A のバージョンを v0.1.0 に固定したいと考えています。

OLM 1.0 に渡されたパッケージと制約

Operator Lifecycle Manager (OLM) 1.0 には、デフォルトでは Red Hat が提供する Operator カタログが含まれていません。Red Hat が提供するカタログをクラスターに追加する場合は、カタログのカスタムリソース (CR) を作成し、クラスターに適用します。次のカスタムリソース (CR) の例は、OLM 1.0 のカタログリソースを作成する方法を示しています。

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: <poll_interval_duration> 1

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: certified-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/certified-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: community-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/community-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

次のコマンドは、クラスターにカタログを追加します。

$ oc apply -f <catalog_name>.yaml 1