3.2. OpenShift Serverless Operator のインストール
OpenShift Serverless Operator をインストールすると、OpenShift Container Platform クラスターに Knative Serving、Knative Eventing、Knative Kafka をインストールして使用することができます。OpenShift Serverless Operator は、クラスターの Knative カスタムリソース定義 (CRD) を管理し、各コンポーネントの個別の設定マップを直接修正することなくそれらを設定できるようにします。
3.2.1. Web コンソールからの OpenShift Serverless Operator のインストール
OpenShift Container Platform Web コンソールを使用して、OperatorHub から OpenShift Serverless Operator をインストールできます。この Operator をインストールすることで、Knative コンポーネントをインストールして使用することができます。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Container Platform Web コンソールにログインしている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub ページに移動します。 - スクロールするか、またはこれらのキーワード Serverless を Filter by keyword ボックス に入力して OpenShift Serverless Operator を検索します。
- Operator についての情報を確認してから、Install をクリックします。
Install Operator ページで以下を行います。
-
Installation Mode は All namespaces on the cluster (default) になります。このモードは、デフォルトの
openshift-serverless
namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。 -
Installed Namespace は
openshift-serverless
です。 - Update Channel として stable チャネルを選択します。stable チャネルは、OpenShift Serverless Operator の最新の安定したリリースのインストールを可能にします。
- Automatic または Manual 承認ストラテジーを選択します。
-
Installation Mode は All namespaces on the cluster (default) になります。このモードは、デフォルトの
- Install をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。
Catalog
Operator Management ページから、OpenShift Serverless Operator サブスクリプションのインストールおよびアップグレードの進捗をモニターできます。 - 手動 の承認ストラテジーを選択している場合、サブスクリプションのアップグレードステータスは、その Install Plan を確認し、承認するまで Upgrading のままになります。Install Plan ページでの承認後に、サブスクリプションのアップグレードステータスは Up to date に移行します。
- 自動 の承認ストラテジーを選択している場合、アップグレードステータスは、介入なしに Up to date に解決するはずです。
検証
サブスクリプションのアップグレードステータスが Up to date に移行したら、Catalog
上記通りにならない場合:
-
Catalog
Operator Management ページに切り替え、Operator Subscriptions および Install Plans タブで Status の下の失敗またはエラーの有無を確認します。 -
さらにトラブルシューティングの必要な問題を報告している Pod のログについては、Workloads
Pods ページの openshift-serverless
プロジェクトの Pod のログで確認できます。
OpenShift Serverless で Red Hat 分散トレースを使用する 場合は、KnativeServing または KnativeEventing をインストールする前に、Red Hat 分散トレースをインストールして設定する必要があります。
3.2.2. CLI からの OpenShift Serverless Operator のインストール
CLI を使用して、OperatorHub から OpenShift Serverless Operator をインストールできます。この Operator をインストールすることで、Knative コンポーネントをインストールして使用することができます。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- クラスターで Marketplace 機能が有効になっているか、Red Hat Operator カタログソースが手動で設定されています。
- OpenShift Container Platform クラスターにログインしている。
手順
Namespace
、OperatorGroup
、およびSubscription
オブジェクトを含む YAML ファイルを作成して、namespace を OpenShift Serverless Operator にサブスクライブします。たとえば、次の内容でファイルserverless-subscription.yaml
を作成します。Subscription の例
--- apiVersion: v1 kind: Namespace metadata: name: openshift-serverless --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: serverless-operators namespace: openshift-serverless spec: {} --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: serverless-operator namespace: openshift-serverless spec: channel: stable 1 name: serverless-operator 2 source: redhat-operators 3 sourceNamespace: openshift-marketplace 4
- 1
- Operator のチャンネル名。
stable
チャネルを使用すると、OpenShift Serverless Operator の最新の安定したバージョンをインストールできます。 - 2
- サブスクライブする Operator の名前。OpenShift Serverless Operator の場合、これは常に
serverless-operator
です。 - 3
- Operator を提供する CatalogSource の名前。デフォルトの OperatorHub カタログソースには
redhat-operators
を使用します。 - 4
- CatalogSource の namespace。デフォルトの OperatorHub カタログソースには
openshift-marketplace
を使用します。
Subscription
オブジェクトを作成します。$ oc apply -f serverless-subscription.yaml
検証
クラスターサービスバージョン (CSV) が Succeeded
フェーズに達したことを確認します。
コマンドの例
$ oc get csv
出力例
NAME DISPLAY VERSION REPLACES PHASE serverless-operator.v1.25.0 Red Hat OpenShift Serverless 1.25.0 serverless-operator.v1.24.0 Succeeded
OpenShift Serverless で Red Hat 分散トレースを使用する 場合は、KnativeServing または KnativeEventing をインストールする前に、Red Hat 分散トレースをインストールして設定する必要があります。
3.2.3. グローバル設定
OpenShift Serverless Operator は、KnativeServing
および KnativeEventing
カスタムリソースからシステムの 設定マップ への値の反映を含む Knative インストールのグローバル設定を管理します。手動で適用される設定マップの更新は Operator によって上書きされます。ただし、Knative カスタムリソースを変更すると、これらの設定マップの値を設定できます。
Knative には、名前に接頭辞 config-
が付けられた複数の設定マップがあります。すべての Knative 設定マップは、適用するカスタムリソースと同じ namespace に作成されます。たとえば、KnativeServing
カスタムリソースが knative-serving
namespace に作成される場合、すべての Knative Serving 設定マップもこの namespace に作成されます。
Knative カスタムリソースの spec.config
には、設定マップごとに config-<name>
という名前の <name>
エントリーが 1 つあり、設定マップ data
で使用される値を持ちます。
3.2.4. 関連情報
3.2.5. 次のステップ
- OpenShift Serverless Operator のインストール後に、Knative Serving をインストールするか、Knative Eventing をインストールする ことができます。