Menu Close
Serverless
OpenShift Serverless のインストール、使用法、およびリリースノート
概要
第1章 リリースノート
リリースノートには、新機能、非推奨機能、互換性を損なう変更、既知の問題に関する情報が記載されています。以下のリリースノートは、OpenShift Container Platform 上の最新の OpenShift Serverless リリースに適用されます。
OpenShift Serverless 機能の概要については、「OpenShift Serverless について」を参照してください。
OpenShift Serverless はオープンソースの Knative プロジェクトに基づいています。
最新の Knative コンポーネントリリースの詳細は、Knative ブログ を参照してください。
1.1. API バージョンについて
API バージョンは、OpenShift Serverless の特定の機能およびカスタムリソースの開発状況を示す重要な指標です。正しい API バージョンを使用していないリソースをクラスター上に作成すると、デプロイメントで問題が発生する可能性があります。
OpenShift Serverless Operator は、最新バージョンを使用するように非推奨の API を使用する古いリソースを自動的にアップグレードします。たとえば、v1beta1
などの古いバージョンの ApiServerSource
API を使用するクラスターにリソースを作成した場合、OpenShift Serverless Operator はこれらのリソースを自動的に更新し、これが利用可能な場合に API の v1
バージョンを使用するように、v1beta1
バージョンは非推奨になりました。
非推奨となった古いバージョンは、今後のリリースで削除される可能性があります。API の非推奨バージョンを使用すると、リソースが失敗することはありません。ただし、削除された API のバージョンを使用しようとすると、リソースが失敗します。問題を回避するために、マニフェストが最新バージョンを使用するように更新されていることを確認します。
1.2. 一般提供およびテクノロジープレビュー機能
一般提供 (GA) の機能は完全にサポートされており、実稼働での使用に適しています。テクノロジープレビュー (TP) 機能は実験的な機能であり、本番環境での使用を目的としたものではありません。TP 機能の詳細については、Red Hat Customer Portal の Technology Preview のサポート範囲 を参照してください。
次の表は、どの OpenShift Serverless 機能が GA であり、どの機能が TP であるかに関する情報を提供します。
表1.1 一般提供およびテクノロジープレビュー機能トラッカー
機能 | 1.20 | 1.21 | 1.22 | 1.23 |
---|---|---|---|---|
| TP | TP | TP | TP |
| - | TP | TP | TP |
サービスメッシュ mTLS | GA | GA | GA | GA |
| GA | GA | GA | GA |
HTTPS リダイレクト | GA | GA | GA | GA |
Kafka ブローカー | TP | TP | TP | TP |
Kafka シンクコ | - | TP | TP | TP |
Knative サービスの初期化コンテナーのサポート | - | - | TP | TP |
Knative サービスの PVC サポート | - | - | TP | TP |
1.3. 非推奨および削除された機能
以前のリリースで一般提供 (GA) またはテクノロジープレビュー (TP) であった一部の機能は、非推奨または削除されました。非推奨の機能は依然として OpenShift Serverless に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
OpenShift Serverless で非推奨となり、削除された主な機能の最新の一覧については、以下の表を参照してください。
表1.2 非推奨および削除機能のトラッカー
機能 | 1.20 | 1.21 | 1.22 | 1.23 |
---|---|---|---|---|
| 非推奨 | 非推奨 | 廃止 | 廃止 |
| 非推奨 | 廃止 | 廃止 | 廃止 |
1.4. Red Hat OpenShift Serverless 1.23.0 のリリースノート
OpenShift Serverless 1.23.0 が公開されました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.4.1. 新機能
- OpenShift Serverless は Knative Serving 1.2 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 1.2 を使用するようになりました。
- OpenShift Serverless は Kourier 1.2 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 1.2 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 1.2 を使用するようになりました。
-
kn func
CLI プラグインはfunc
0.24 を使用するようになりました。 -
Kafka ブローカーで
kafka.eventing.knative.dev/external.topic
アノテーションを使用できるようになりました。このアノテーションを使用すると、ブローカー自体の内部トピックを作成する代わりに、既存の外部管理トピックを使用できます。 -
kafka-ch-controller
およびkafka-webhook
Kafka コンポーネントが存在しなくなりました。これらのコンポーネントはkafka-webhook-eventing
コンポーネントに置き換えられました。 - OpenShift Serverless Functions テクノロジープレビューは、デフォルトで Source-to-Image(S2I)を使用してコンテナーイメージをビルドできるようになりました。
1.4.2. 既知の問題
- 連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっています。
-
Kafka ブローカーを含む namespace を削除する場合、ブローカーの前にブローカーの
auth.secret.ref.name
シークレットが削除されると、namespace ファイナライザーが削除される可能性があります。 多数の Knative サービスで OpenShift Serverless を実行すると、Knative Activator Pod がデフォルトのメモリー制限 600MB に近い状態になる可能性があります。これらの Pod は、メモリー消費がこの制限に達すると再起動される可能性があります。activator デプロイメントの要求および制限は、
KnativeServing
カスタムリソースを変更して設定できます。apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: deployments: - name: activator resources: - container: activator requests: cpu: 300m memory: 60Mi limits: cpu: 1000m memory: 1000Mi
-
Cloud Native Buildpacks を関数のローカルビルドストラテジーとして使用する場合、
kn func
は podman を自動的に起動したり、リモートデーモンに対して SSH トンネルを使用したりできません。これらの問題の回避策として、関数をデプロイする前に Docker または podman デーモンがローカル開発コンピューターですでに実行されていることです。 - 現時点で、クラスター上の関数ビルドが Quarkus および Golang ランタイムで失敗します。これらは Node、Typescript、Python、および Springboot ランタイムで正常に機能します。
1.5. Red Hat OpenShift Serverless 1.22.0 のリリースノート
OpenShift Serverless 1.22.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.5.1. 新機能
- OpenShift Serverless は Knative Serving 1.1 を使用するようになりました。
- OpenShift Serverless は KnativeEventing1.1 を使用するようになりました。
- OpenShift Serverless は Kourier1.1 を使用するようになりました。
-
OpenShift Serverless は
KnativeknCLI1.1
を使用するようになりました。 - OpenShift Serverless は KnativeKafka1.1 を使用するようになりました。
-
knfuncCLI
プラグインはfunc0.23
を使用するようになりました。 - Knative サービスの初期コンテナーサポートがテクノロジープレビューとして利用できるようになりました。
- Knative サービスの永続ボリュームクレーム (PVC) サポートが、テクノロジープレビューとして利用できるようになりました。
-
knative-serving
、knative-serving-ingress
、knative-eventing
、およびknative-kafka
システムネームボックスに、デフォルトでknative.openshift.io/part-of:"openshift-serverless"
ラベルが付けられるようになりました。 - Knative Eventing-Kafka Broker/Trigger ダッシュボードが追加されました。これにより、Web コンソールで Kafka ブローカーとトリガーメトリックを視覚化できます。
- Knative Eventing-KafkaSink ダッシュボードが追加されました。これにより、Web コンソールで KafkaSink メトリックを視覚化できます。
- Knative Eventing-Broker/Trigger ダッシュボードは、Knative Eventing-Channel-based Broker/Trigger と呼ばれるようになりました。
-
knative.openshift.io/part-of: " openshift-serverless "
ラベルが、knative.openshift.io/system-namespace
ラベルに置き換わりました。 -
Knative Serving YAML 設定ファイルの命名スタイルがキャメルケース (
ExampleName
) からハイフンスタイル (example-name
) に変更されました。このリリース以降、Knative Serving YAML 設定ファイルを作成または編集するときは、ハイフンスタイルの表記を使用してください。
1.5.2. 既知の問題
- 連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっています。
1.6. Red Hat OpenShift Serverless 1.21.0 のリリースノート
OpenShift Serverless 1.21.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.6.1. 新機能
- OpenShift Serverless は Knative Serving 1.0 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 1.0 を使用するようになりました。
- OpenShift Serverless は Kourier 1.0 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 1.0 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 1.0 を使用するようになりました。
-
kn func
CLI プラグインはfunc
0.21 を使用するようになりました。 - Kafka シンクがテクノロジープレビューとして利用できるようになりました。
-
Knative オープンソースプロジェクトは、camel-cased 設定キーを廃止し、kebab-cased キーを一貫して使用することを支持し始めました。その結果、OpenShift Serverless 1.18.0 リリースノートで前述した
defaultExternalScheme
キーは非推奨になり、default-external-scheme
キーに置き換えられました。キーの使用方法は同じです。
1.6.2. 修正された問題
-
OpenShift Serverless 1.20.0 では、サービスにイベントを送信するための
kn event send
の使用に影響するイベント配信の問題がありました。この問題は修正されています。 -
OpenShift Serverless 1.20.0 (
func
0.20) では、http
テンプレートを使用して作成された TypeScript 関数をクラスターにデプロイできませんでした。この問題は修正されています。 -
OpenShift Serverless 1.20.0 (
func
0.20) では、gcr.io
レジストリーを使用した関数のデプロイがエラーで失敗しました。この問題は修正されています。 -
OpenShift Serverless 1.20.0 (
func
0.20) では、kn func create
コマンドを使用して Springboot 関数プロジェクトディレクトリーを作成してから、kn func build
コマンドを実行するとエラーメッセージが表示されて失敗しました。この問題は修正されています。 -
OpenShift Serverless 1.19.0 (
func
0.19) では、一部のランタイムが podman を使用して関数をビルドできませんでした。この問題は修正されています。
1.6.3. 既知の問題
現在、ドメインマッピングコントローラーは、現在サポートされていないパスを含むブローカーの URI を処理できません。
つまり、
DomainMapping
カスタムリソース (CR) を使用してカスタムドメインをブローカーにマップする場合は、ブローカーの入力サービスを使用してDomainMapping
CR を設定し、ブローカーの正確なパスをカスタムドメインに追加する必要があります。DomainMappingCR
の例apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: <domain-name> namespace: knative-eventing spec: ref: name: broker-ingress kind: Service apiVersion: v1
その場合、ブローカーの URI は
<domain-name>/<broker-namespace>/<broker-name>
になります。
1.7. Red Hat OpenShift Serverless 1.20.0 のリリースノート
OpenShift Serverless 1.20.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.7.1. 新機能
- OpenShift Serverless は Knative Serving 0.26 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 0.26 を使用するようになりました。
- OpenShift Serverless は Kourier 0.26 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 0.26 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 0.26 を使用するようになりました。
-
kn func
CLI プラグインはfunc
0.20 を使用するようになりました。 Kafka ブローカーがテクノロジープレビュー機能として利用可能になりました。
重要現在テクノロジープレビューにある Kafka ブローカーは、FIPS ではサポートされていません。
-
kn event
プラグインがテクノロジープレビュー機能として利用可能になりました。 -
knservicecreate
コマンドの--min-scale
フラグと--max-scale
フラグは廃止されました。代わりに、-scale-min
フラグと--scale-max
フラグを使用してください。
1.7.2. 既知の問題
OpenShift Serverless は、HTTPS を使用するデフォルトアドレスで Knative サービスをデプロイします。クラスター内のリソースにイベントを送信する場合、送信側にはクラスターの認証局(CA)が設定されていません。これにより、クラスターがグローバルに受け入れ可能な証明書を使用しない限り、イベント配信は失敗します。
たとえば、一般にアクセス可能なアドレスへのイベント配信は機能します。
$ kn event send --to-url https://ce-api.foo.example.com/
一方、サービスがカスタム CA によって発行された HTTPS 証明書でパブリックアドレスを使用する場合、この配信は失敗します。
$ kn event send --to Service:serving.knative.dev/v1:event-display
ブローカーやチャネルなどの他のアドレス指定可能なオブジェクトへのイベント送信は、この問題の影響を受けず、期待どおりに機能します。
- 現在、Kafka ブローカーは Federal Information Processing Standards (FIPS)モードが有効になっているクラスターでは動作しません。
kn func create
コマンドで Springboot 関数プロジェクトディレクトリーを作成する場合、それ以降のkn func build
コマンドの実行は、以下のエラーメッセージと共に失敗します。[analyzer] no stack metadata found at path '' [analyzer] ERROR: failed to : set API for buildpack 'paketo-buildpacks/ca-certificates@3.0.2': buildpack API version '0.7' is incompatible with the lifecycle
回避策として、関数設定ファイル
func.yaml
でbuilder
プロパティーをgcr.io/paketo-buildpacks/builder:base
に変更します。gcr.io
レジストリーを使用した関数のデプロイは、以下のエラーメッセージと共に失敗します。Error: failed to get credentials: failed to verify credentials: status code: 404
回避策として、
quay.io
またはdocker.io
などのgcr.io
以外のレジストリーを使用します。http
テンプレートで作成された Typescript 関数は、クラスターへのデプロイに失敗します。回避策として、
func.yaml
ファイルで以下のセクションを置き換えます。buildEnvs: []
上記を以下のように置き換えます。
buildEnvs: - name: BP_NODE_RUN_SCRIPTS value: build
func
バージョン 0.20 では、一部のランタイムが podman を使用して関数をビルドできない場合があります。以下のようなエラーメッセージが表示される場合があります。ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF
この問題には、以下の回避策があります。
--time=0
をサービスExecStart
定義に追加して、podman サービスを更新します。サービス設定の例
ExecStart=/usr/bin/podman $LOGGING system service --time=0
以下のコマンドを実行して podman サービスを再起動します。
$ systemctl --user daemon-reload
$ systemctl restart --user podman.socket
または、TCP を使用して podman API を公開することもできます。
$ podman system service --time=0 tcp:127.0.0.1:5534 & export DOCKER_HOST=tcp://127.0.0.1:5534
1.8. Red Hat OpenShift Serverless 1.19.0 のリリースノート
OpenShift Serverless 1.19.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.8.1. 新機能
- OpenShift Serverless は Knative Serving 0.25 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 0.25 を使用するようになりました。
- OpenShift Serverless は Kourier 0.25 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 0.25 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 0.25 を使用するようになりました。
-
kn func
CLI プラグインはfunc
0.19 を使用するようになりました。 -
KafkaBinding
API は OpenShift Serverless 1.19.0 で非推奨となり、今後のリリースで廃止される予定です。 - HTTPS リダイレクトがサポートされ、クラスターに対してグローバルに設定することも、各 Knative サービスごとに設定することもできるようになりました。
1.8.2. 修正された問題
- 以前のリリースでは、Kafka チャネルディスパッチャーは、ローカルコミットが成功するのを待ってからしか応答していませんでした。これにより、Apache Kafka ノードに障害が発生した場合に、イベントが失われる可能性がありました。Kafka チャネルディスパッチャーは、すべての同期レプリカがコミットするのを待ってから応答するようになりました。
1.8.3. 既知の問題
func
バージョン 0.19 では、一部のランタイムが podman を使用して関数をビルドできない場合があります。以下のようなエラーメッセージが表示される場合があります。ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF
この問題には、以下の回避策があります。
--time=0
をサービスExecStart
定義に追加して、podman サービスを更新します。サービス設定の例
ExecStart=/usr/bin/podman $LOGGING system service --time=0
以下のコマンドを実行して podman サービスを再起動します。
$ systemctl --user daemon-reload
$ systemctl restart --user podman.socket
または、TCP を使用して podman API を公開することもできます。
$ podman system service --time=0 tcp:127.0.0.1:5534 & export DOCKER_HOST=tcp://127.0.0.1:5534
1.9. Red Hat OpenShift Serverless 1.18.0 のリリースノート
OpenShift Serverless 1.18.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.9.1. 新機能
- OpenShift Serverless は Knative Serving 0.24.0 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 0.24.0 を使用するようになりました。
- OpenShift Serverless は Kourier 0.24.0 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 0.24.0 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 0.24.7 を使用するようになりました。
-
kn func
CLI プラグインはfunc
0.18.0 を使用するようになりました。 今後の OpenShift Serverless 1.19.0 リリースでは、外部ルートの URL スキームはデフォルトで HTTPS になり、セキュリティーが強化されます。
この変更をワークロードに適用する必要がない場合は、以下の YAML を
KnativeServing
カスタムリソース (CR) に追加してから 1.19.0 にアップグレードする前にデフォルト設定を上書きできます。... spec: config: network: defaultExternalScheme: "http" ...
変更を 1.18.0 ですでに適用する必要がある場合には、以下の YAML を追加します。
... spec: config: network: defaultExternalScheme: "https" ...
今後の OpenShift Serverless 1.19.0 リリースでは、Kourier ゲートウェイが公開されるデフォルトのサービスタイプは
ClusterIP
であり、LoadBalancer
ではありません。この変更をワークロードに適用する必要がない場合は、以下の YAML を
KnativeServing
カスタムリソース定義 (CRD) に追加してから 1.19.0 にアップグレードする前にデフォルト設定を上書きできます。... spec: ingress: kourier: service-type: LoadBalancer ...
-
OpenShift Serverless で
emptyDir
ボリュームを使用できるようになりました。詳細は、Knative Serving に関する OpenShift Serverless ドキュメントを参照してください。 -
kn func
を使用して関数を作成すると、Rust テンプレートが利用できるようになりました。
1.9.2. 修正された問題
- 以前の 1.4 バージョンの Camel-K は OpenShift Serverless 1.17.0 と互換性がありませんでした。Camel-K の問題が修正され、Camel-K バージョン 1.4.1 を OpenShift Serverless 1.17.0 で使用できます。
以前のバージョンでは、Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。
その結果、データプレーンが準備完了ステータスを報告していないときに送信されたメッセージは、サブスクライバーまたはシンクに配信されない可能性があります。
OpenShift Serverless 1.18.0 では、問題が修正され、初期メッセージが失われなくなりました。この問題の詳細は、ナレッジベースの記事 #6343981 を参照してください。
1.9.3. 既知の問題
Knative
kn
CLI の古いバージョンは、Knative Serving および Knative Eventing API の古いバージョンを使用する可能性があります。たとえば、kn
CLI のバージョン 0.23.2 はv1alpha1
API バージョンを使用します。一方、OpenShift Serverless の新しいリリースでは、古い API バージョンをサポートしない可能性があります。たとえば、OpenShift Serverless 1.18.0 は
kafkasources.sources.knative.dev
API のバージョンv1alpha1
をサポートしなくなりました。そのため、
kn
が古い API を検出できないため、新しい OpenShift Serverless で古いバージョンの Knativekn
CLI を使用するとエラーが発生する可能性がありました。たとえば、kn
CLI のバージョン 0.23.2 は OpenShift Serverless 1.18.0 では機能しません。問題を回避するには、OpenShift Serverless リリースで利用可能な最新の
kn
CLI バージョンを使用します。OpenShift Serverless 1.18.0 については、Knativekn
CLI 0.24.0 を使用します。
1.10. Red Hat OpenShift Serverless 1.17.0 のリリースノート
OpenShift Serverless 1.17.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.10.1. 新機能
- OpenShift Serverless は Knative Serving 0.23.0 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 0.23.0 を使用するようになりました。
- OpenShift Serverless は Kourier 0.23.0 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 0.23.0 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 0.23.0 を使用するようになりました。
-
kn func
CLI プラグインはfunc
0.17.0 を使用するようになりました。 今後の OpenShift Serverless 1.19.0 リリースでは、外部ルートの URL スキームはデフォルトで HTTPS になり、セキュリティーが強化されます。
この変更をワークロードに適用する必要がない場合は、以下の YAML を
KnativeServing
カスタムリソース (CR) に追加してから 1.19.0 にアップグレードする前にデフォルト設定を上書きできます。... spec: config: network: defaultExternalScheme: "http" ...
- mTLS 機能は一般に利用可能 (GA) になりました。
-
kn func
を使用して関数を作成すると、Typescript テンプレートが利用できるようになりました。 Knative Eventing 0.23.0 で API バージョンへの変更
-
OpenShift Serverless バージョン 1.14.0 で非推奨となった
KafkaChannel
API のv1alpha1
バージョンが削除されました。設定マップのChannelTemplateSpec
パラメーターにこの古いバージョンの参照が含まれる場合は、これを仕様のこの部分を更新して、正しい API バージョンを使用する必要があります。
-
OpenShift Serverless バージョン 1.14.0 で非推奨となった
1.10.2. 既知の問題
新しい OpenShift Serverless リリースで古いバージョンの Knative
kn
CLI の使用を試行する場合は、API が見つからないとエラーが発生します。たとえば、バージョン 0.22.0 を使用する
kn
CLI の 1.16.0 リリースと、Knative Serving および Knative Eventing API の 0.23.0 バージョンを使用する 1.17.0 OpenShift Serverless リリースを使用する場合、CLI は、古い 0.22.0 API バージョンを探し続けるため、機能しません。問題を回避するために、OpenShift Serverless リリースの最新の
kn
CLI バージョンを使用していることを確認してください。- 本リリースでは、Kafka チャネルメトリクスは、対応する Web コンソールダッシュボードで監視されず、表示されません。これは、Kafka ディスパッチャーの調整プロセスが大幅に変更されたためです。
Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。
その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。
この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。
Camel-K 1.4 リリースは、OpenShift Serverless バージョン 1.17.0 と互換性がありません。これは、Camel-K 1.4 が Knative バージョン 0.23.0 で削除された API を使用するためです。現在、この問題に対する回避策はありません。OpenShift Serverless で Camel-K 1.4 を使用する必要がある場合は、OpenShift Serverless バージョン 1.17.0 にアップグレードしないでください。
注記この問題は修正され、Camel-K バージョン 1.4.1 は OpenShift Serverless 1.17.0 と互換性があります。
1.11. Red Hat OpenShift Serverless 1.16.0 のリリースノート
OpenShift Serverless 1.16.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.11.1. 新機能
- OpenShift Serverless は Knative Serving 0.22.0 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 0.22.0 を使用するようになりました。
- OpenShift Serverless は Kourier 0.22.0 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 0.22.0 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 0.22.0 を使用するようになりました。
-
kn func
CLI プラグインはfunc
0.16.0 を使用するようになりました。 -
kn func emit
コマンドが関数kn
プラグインに追加されました。このコマンドを使用してイベントを送信し、ローカルにデプロイされた機能をテストできます。
1.11.2. 既知の問題
- OpenShift Serverless 1.16.0 にアップグレードする前に、OpenShift Container Platform をバージョン 4.6.30、4.7.11、またはそれ以降にアップグレードする必要があります。
AMQ Streams Operator は、OpenShift Serverless Operator のインストールまたはアップグレードを妨げる可能性があります。これが生じる場合、以下のエラーが Operator Lifecycle Manager (OLM) によってスローされます。
WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.
この問題を修正するには、OpenShift Serverless Operator をインストールまたはアップグレードする前に AMQ Streams Operator をアンインストールしてください。その後、AMQ Streams Operator を再インストールできます。
- サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。Service Mesh および mTLS で使用する Knative Serving メトリクスを有効にする方法は、Serverless ドキュメントの「Integrating Service Mesh with OpenShift Serverless」セクションを参照してください。
Istio Ingress を有効にしてサービスメッシュ CR をデプロイする場合、
istio-ingressgateway
Pod に以下の警告が表示される可能性があります。2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found
Knative サービスにもアクセスできない場合があります。
以下の回避策を使用して、
knative-local-gateway
サービスを再作成することでこの問題を修正できます。istio-system
namespace の既存のknative-local-gateway
サービスを削除します。$ oc delete services -n istio-system knative-local-gateway
以下の YAML が含まれる
knative-local-gateway
サービスを作成し、適用します。apiVersion: v1 kind: Service metadata: name: knative-local-gateway namespace: istio-system labels: experimental.istio.io/disable-gateway-port-translation: "true" spec: type: ClusterIP selector: istio: ingressgateway ports: - name: http2 port: 80 targetPort: 8081
クラスターに 1000 の Knative サービスがあり、Knative Serving の再インストールまたはアップグレードを実行する場合、
KnativeServing
カスタムリソース (CR) の状態がReady
になった後に最初の新しいサービスを作成すると遅延が生じます。3scale-kourier-control
サービスは、新しいサービスの作成を処理する前に、既存のすべての Knative サービスを調整します。これにより、新規サービスは状態がReady
に更新されるまで、IngressNotConfigured
またはUnknown
の状態で約 800 秒を費やすことになります。Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。
その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。
この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。
1.12. Red Hat OpenShift Serverless 1.15.0 のリリースノート
OpenShift Serverless 1.15.0 が公開されました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.12.1. 新機能
- OpenShift Serverless は Knative Serving 0.21.0 を使用するようになりました。
- OpenShift Serverless は Knative Eventing Operator 0.21.0 を使用するようになりました。
- OpenShift Serverless は Kourier 0.21.0 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 0.21.0 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 0.21.1 を使用するようになりました。
- OpenShift Serverless Functions はテクノロジープレビューとして利用可能になりました。
これまでプライベートサービスの作成に使用されていた serving.knative.dev/visibility
ラベルは非推奨になりました。既存のサービスを更新して、代わりに networking.knative.dev/visibility
ラベルを使用する必要があります。
1.12.2. 既知の問題
Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。
その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。
この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。
1.13. Red Hat OpenShift Serverless 1.14.0 のリリースノート
OpenShift Serverless 1.14.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。
1.13.1. 新機能
- OpenShift Serverless は Knative Serving 0.20.0 を使用するようになりました。
- OpenShift Serverless は Knative Eventing 0.20.0 を使用しています。
- OpenShift Serverless は Kourier 0.20.0 を使用するようになりました。
-
OpenShift Serverless は Knative
kn
CLI 0.20.0 を使用するようになりました。 - OpenShift Serverless は Knative Kafka 0.20.0 を使用するようになりました。
OpenShift Serverless での Knative Kafka は一般に利用可能 (GA) になりました。
重要OpenShift Serverless の
KafkaChannel
およびKafkaSource
オブジェクトの API のv1beta1
バージョンのみがサポートされます。非推奨となったv1alpha1
バージョンの API は使用しないでください。-
OpenShift Serverless のインストールおよびアップグレード用の Operator チャネルが OpenShift Container Platform 4.6 以降のバージョンで
stable
に更新されました。 OpenShift Serverless は、IBM Power Systems、IBM Z、および LinuxONE でサポートされるようになりましたが、以下の機能はまだサポートされていません。
- Knative Kafka の機能。
- OpenShift Serverless 機能の developer プレビュー。
1.13.2. 既知の問題
-
Kafka チャネルのサブスクリプションには
READY
のマークが付けられず、SubscriptionNotMarkedReadyByChannel
状態のままになることがあります。これを修正するには、Kafka チャネルの dispatcher を再起動します。 Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。
その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。
この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。
第2章 発見
2.1. OpenShift Serverless について
OpenShift Serverless は、Kubernetes ネイティブなビルディングブロックを提供します。開発者はこれらを使用して、OpenShift Container Platform 上でサーバーレスのイベント駆動型アプリケーションを作成およびデプロイできます。OpenShift Serverless はオープンソースの Knative プロジェクトをベースとし、エンタープライズレベルのサーバーレスプラットフォームを有効にすることで、ハイブリッドおよびマルチクラウド環境に対して移植性と一貫性をもたらします。
2.1.1. Knative Serving
Knative Serving は、クラウドネイティブアプリケーション の作成、デプロイ、管理を希望する開発者をサポートします。これにより、オブジェクトのセットがOpenShift Container Platform クラスター上のサーバーレスワークロードの動作を定義し制御する Kubernetes カスタムリソース定義 (CRD) として提供されます。
開発者はこれらの CRD を使用して、複雑なユースケースに対応するためにビルディングブロックとして使用できるカスタムリソース (CR) インスタンスを作成します。以下に例を示します。
- サーバーレスコンテナーの迅速なデプロイ
- Pod の自動スケーリング
2.1.1.1. Knative Serving リソース
- サービス
-
service.serving.knative.dev
CRD はワークロードのライフサイクルを自動的に管理し、アプリケーションがネットワーク経由でデプロイされ、到達可能であることを確認します。これは、ユーザーが作成したサービスまたはカスタムリソースに対して加えられるそれぞれの変更についての ルート、設定、および新規リビジョンを作成します。Knative での開発者の対話のほとんどは、サービスを変更して実行されます。 - Revision
-
revision.serving.knative.dev
CRD は、ワークロードに対して加えられるそれぞれの変更についてのコードおよび設定の特定の時点におけるスナップショットです。Revision (リビジョン) はイミュータブル (変更不可) オブジェクトであり、必要な期間保持することができます。 - Route
-
route.serving.knative.dev
CRD は、ネットワークのエンドポイントを、1 つ以上のリビジョンにマップします。部分的なトラフィックや名前付きルートなどのトラフィックを複数の方法で管理することができます。 - Configuration
-
configuration.serving.knative.dev
CRD は、デプロイメントの必要な状態を維持します。これにより、コードと設定を明確に分離できます。設定を変更すると、新規リビジョンが作成されます。
2.1.2. Knative Eventing
OpenShift Container Platform 上の Knative Eventing を使用すると、開発者はサーバーレスアプリケーションと共に イベント駆動型のアーキテクチャー を使用できます。イベント駆動型のアーキテクチャーは、イベントプロデューサーとイベントコンシューマー間の関係を切り離すという概念に基づいています。
イベントプロデューサーはイベントを作成し、イベントシンクまたはコンシューマーはイベントを受信します。Knative Eventing は、標準の HTTP POST リクエストを使用してイベントプロデューサーとシンク間でイベントを送受信します。これらのイベントは CloudEvents 仕様 に準拠しており、すべてのプログラミング言語でのイベントの作成、解析、および送受信を可能にします。
Knative Eventing は以下のユースケースをサポートします。
- コンシューマーを作成せずにイベントを公開する
- イベントを HTTP POST としてブローカーに送信し、バインディングを使用してイベントを生成するアプリケーションから宛先設定を分離できます。
- パブリッシャーを作成せずにイベントを消費
- Trigger を使用して、イベント属性に基づいて Broker からイベントを消費できます。アプリケーションはイベントを HTTP POST として受信します。
複数のタイプのシンクへの配信を有効にするために、Knative Eventing は複数の Kubernetes リソースで実装できる以下の汎用インターフェースを定義します。
- アドレス指定可能なリソース
-
HTTP 経由でイベントの
status.address.url
フィールドに定義されるアドレスに配信されるイベントを受信し、確認することができます。KubernetesService
リソースはアドレス指定可能なインターフェースにも対応します。 - 呼び出し可能なリソース
-
HTTP 経由で配信されるイベントを受信し、これを変換できます。HTTP 応答ペイロードで
0
または1
の新規イベントを返します。返されるイベントは、外部イベントソースからのイベントが処理されるのと同じ方法で処理できます。
以下を使用して、イベントをイベントソースから複数のイベントシンクに伝播できます。
- Channels and subscriptions、または
- ブローカー と トリガー。
2.1.3. サポートされる構成
OpenShift Serverless(最新バージョンおよび以前のバージョン) のサポートされる機能、設定、および統合のセットは、サポートされる設定についてのページで確認できます。
2.1.4. スケーラビリティーおよびパフォーマンス
OpenShift Serverless は、3 つのメインノードと 3 つのワーカーノードの設定でテストされています。各ノードには 64 CPU、457 GB のメモリー、および 394 GB のストレージがあります。
この設定を使用して作成できる Knative サービスの最大数は pid です。これは、1 Knative サービスが 3 つの Kubernetes サービスを作成するため、OpenShift Container Platform Kubernetes サービスの制限に 10,000 に対応します。
ゼロ応答時間の平均スケールは約 3.4 秒で、最大応答時間は 8 秒で、単純な Quarkus アプリケーションに対して 99.9 パーセンタイルが 4.5 秒となっています。これらの時間は、アプリケーションとアプリケーションのランタイムによって異なる場合があります。
2.1.5. 関連情報
2.2. OpenShift Serverless Functions について
OpenShift Serverless Functions により、開発者は OpenShift Container Platform で Knative サービスとしてステートレスでイベント駆動型の関数を作成およびデプロイできます。kn func CLI
は Knative kn
CLI のプラグインとして提供されます。OpenShift Serverless Functions は、 CNCF Buildpack API を使用してコンテナーイメージを作成します。コンテナーイメージの作成後に、kn func
を使用してコンテナーイメージをクラスターで Knative サービスとしてデプロイできます。
OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
2.2.1. 含まれるランタイム
OpenShift Serverless Functions は、以下のランタイムの基本機能を作成するために使用できるテンプレートを提供します。
2.2.2. 次のステップ
2.3. イベントソース
Knative イベントソース には、クラウドイベントの生成またはインポート、これらのイベントの別のエンドポイントへのリレー (sink とも呼ばれる) を行う Kubernetes オブジェクトを指定できます。イベントに対応する分散システムを開発するには、イベントのソースが重要になります。
OpenShift Container Platform Web コンソール、kn
CLI を使用するか、または YAML ファイルを適用して Developer パースペクティブで Knative イベントソースを作成したり、管理したりできます。
現時点で、OpenShift Serverless は以下のイベントソースタイプをサポートします。
- API サーバーソース
- Kubernetes API サーバーイベントを Knative に送ります。API サーバーソースは、Kubernetes リソースが作成、更新、または削除されるたびに新規イベントを送信します。
- Ping ソース
- 指定された cron スケジュールに、固定ペイロードを使用してイベントを生成します。
- Kafka イベントソース
- Kafka クラスターをイベントソースとしてシンクに接続します。
カスタムイベントソース を作成することもできます。
2.4. チャネルおよびサブスクリプション
チャネルは、単一のイベント転送および永続レイヤーを定義するカスタムリソースです。イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。

チャネルは、サポートされている Channel
オブジェクトをインスタンス化することで作成でき、Subscription
オブジェクトの delivery 仕様を変更することで再 配信
の試行を設定できます。
Channel
オブジェクトが作成されると、変更用の受付 Webhook はデフォルトのチャネル実装に基づいて Channel
オブジェクトの spec.channelTemplate
プロパティーのセットを追加します。たとえば、InMemoryChannel
のデフォルト実装の場合、Channel
オブジェクトは以下のようになります。
apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: default spec: channelTemplate: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel
チャネルコントローラーは、その後に spec.channelTemplate
設定に基づいてサポートするチャネルインスタンスを作成します。
spec.channelTemplate
プロパティーは作成後に変更できません。それらは、ユーザーではなくデフォルトのチャネルメカニズムで設定されるためです。
このメカニズムが上記の例で使用される場合、汎用バッキングチャネルおよび InMemoryChannel
チャネルなど 2 つのオブジェクトが作成されます。別のデフォルトチャネルの実装を使用している場合、InMemoryChannel
は実装に固有のものに置き換えられます。たとえば、Knative Kafka の場合、KafkaChannel
チャネルが作成されます。
バッキングチャネルは、サブスクリプションをユーザー作成のチャネルオブジェクトにコピーし、ユーザー作成チャネルオブジェクトのステータスを、バッキングチャネルのステータスを反映するように設定します。
2.4.1. チャネルの実装タイプ
InMemoryChannel
および KafkaChannel
チャネルの実装は、開発目的で OpenShift Serverless で使用できます。
以下は、InMemoryChannel
タイプのチャネルの制限です。
- イベントの永続性は利用できません。Pod がダウンすると、その Pod のイベントが失われます。
-
InMemoryChannel
チャネルはイベントの順序を実装しないため、チャネルで同時に受信される 2 つのイベントはいずれの順序でもサブスクライバーに配信できます。 -
サブスクライバーがイベントを拒否する場合、再配信はデフォルトで試行されません。
Subscription
オブジェクトのdelivery
仕様を変更することで、再配信の試行を設定できます。
Kafka チャネルの詳細は、Knative Kafka のドキュメントを参照してください。
2.4.2. 次のステップ
- チャネルおよび サブスクリプション を作成します。これにより、イベントシンクがチャネルにサブスクライブし、イベントを受信できるようになります。
- クラスター管理者の場合、チャネルのデフォルト設定を設定できます。チャネルのデフォルトの設定 を参照してください。
第3章 インストール
3.1. OpenShift Serverless Operator のインストール
OpenShift Serverless Operator をインストールすると、OpenShift Container Platform クラスターに Knative Serving、Knative Eventing、Knative Kafka をインストールして使用することができます。OpenShift Serverless Operator は、クラスターの Knative カスタムリソース定義 (CRD) を管理し、各コンポーネントの個別の設定マップを直接修正することなくそれらを設定できるようにします。
3.1.1. 作業を開始する前に
OpenShift Serverless をインストールする前に、サポートされる構成および前提条件についての以下の情報を確認してください。
- OpenShift Serverless は、ネットワークが制限された環境でのインストールに対してサポートされません。
- 現時点で、OpenShift Serverless は単一クラスター上でのマルチテナント設定で使用することはできません。
3.1.1.1. クラスターサイズ要件の定義
OpenShift Serverless をインストールし、使用するには、OpenShift Container Platform クラスターのサイズを適切に設定する必要があります。OpenShift Serverless を実行するために必要な総サイズは、インストールされているコンポーネントとデプロイされているアプリケーションに依存し、デプロイメントによって異なる場合があります。
以下の要件は、OpenShift Container Platform クラスターのワーカーマシンのプールにのみ関連します。コントロールプレーンは一般的なスケジューリングには使用されず、要件から省略されます。
デフォルトで、各 Pod は約 400m の CPU を要求し、推奨値のベースはこの値になります。アプリケーションの実際の CPU 要求を減らすと、レプリカ数が増える可能性があります。
クラスターで高可用性 (HA) を有効にしている場合、これには Knative Serving コントロールプレーンの各レプリカについて 0.5 - 1.5 コアおよび 200MB - 2GB のメモリーが必要です。
3.1.1.2. マシンセットを使用したクラスターのスケーリング
OpenShift Container Platform MachineSet
API を使用して、クラスターを必要なサイズに手動でスケールアップすることができます。最小要件は、通常 2 つのマシンを追加することによってデフォルトのマシンセットのいずれかをスケールアップする必要があることを意味します。「マシンセットの手動によるスケーリング」を参照してください。
3.1.2. 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 → Installed Operators を選択して OpenShift Serverless Operator が表示され、その Status が最終的に関連する namespace で InstallSucceeded に解決することを確認します。
上記通りにならない場合:
- Catalog → Operator Management ページに切り替え、Operator Subscriptions および Install Plans タブで Status の下の失敗またはエラーの有無を確認します。
-
さらにトラブルシューティングの必要な問題を報告している Pod のログについては、Workloads → Pods ページの
openshift-serverless
プロジェクトの Pod のログで確認できます。
Red Hat OpenShift 分散トレースを OpenShift Serverless で使用 する場合、Knative Serving または Knative Eventing をインストールする前に、Red Hat OpenShift 分散トレースをインストールし、設定する必要があります。
3.1.3. 関連情報
3.1.4. 次のステップ
- OpenShift Serverless Operator のインストール後に、Knative Serving をインストールするか、Knative Eventing をインストールする ことができます。
3.2. Knative Serving のインストール
Knative Serving をインストールすると、クラスター上で Knative サービスや関数を作成することができます。また、オートスケーリングやネットワークオプションなどの追加機能をアプリケーションに利用することも可能です。
OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Serving をインストールするか、KnativeServing
カスタムリソース (CR) でより高度な設定を行うことが可能です。KnativeServing
CR の設定オプションの詳細は、「 グローバル設定 」を参照してください。
Red Hat OpenShift 分散トレースを OpenShift Serverless で使用 する場合、Knative Serving をインストールする前に Red Hat OpenShift 分散トレースをインストールし、設定する必要があります。
3.2.1. Web コンソールを使用した Knative Serving のインストール
OpenShift Serverless Operator をインストールした後、OpenShift Container Platform の Web コンソールを使用して Knative Serving をインストールします。デフォルトの設定で Knative Serving をインストールするか、KnativeServing
カスタムリソース (CR) でより詳細な設定を行うことが可能です。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator がインストールされている。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- ページ上部の Project ドロップダウンメニューが Project: knative-serving に設定されていることを確認します。
- OpenShift Serverless Operator の Provided API 一覧で Knative Serving をクリックし、Knative Serving タブに移動します。
- Create Knative Serving をクリックします。
Create Knative Serving ページで、Create をクリックしてデフォルト設定を使用し、Knative Serving をインストールできます。
また、Knative Serving インストールの設定を変更するには、提供されるフォームを使用するか、または YAML を編集して
KnativeServing
オブジェクトを編集します。-
KnativeServing
オブジェクト作成を完全に制御する必要がない単純な設定には、このフォームの使用が推奨されます。 KnativeServing
オブジェクトの作成を完全に制御する必要のあるより複雑な設定には、YAML の編集が推奨されます。YAML にアクセスするには、Create Knative Serving ページの右上にある edit YAML リンクをクリックします。フォームを完了するか、または YAML の変更が完了したら、Create をクリックします。
注記KnativeServing カスタムリソース定義の設定オプションについての詳細は、高度なインストール設定オプション についてのドキュメントを参照してください。
-
-
Knative Serving のインストール後に、
KnativeServing
オブジェクトが作成され、Knative Serving タブに自動的にダイレクトされます。リソースの一覧にknative-serving
カスタムリソースが表示されます。
検証
-
Knative Serving タブで
knative-serving
カスタムリソースをクリックします。 Knative Serving Overview ページに自動的にダイレクトされます。
- スクロールダウンして、Conditions の一覧を確認します。
ステータスが True の条件の一覧が表示されます(例のイメージを参照)。
注記Knative Serving リソースが作成されるまでに数分の時間がかかる場合があります。Resources タブでステータスを確認できます。
- 条件のステータスが Unknown または False である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。
3.2.2. YAML を使用した Knative Serving のインストール
OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Serving をインストールするか、KnativeServing
カスタムリソース (CR) でより高度な設定を行うことが可能です。YAML ファイルとoc
CLI を利用して、以下の手順で Knative Serving をインストールすることができます。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Serverless Operator がインストールされている。
-
OpenShift CLI (
oc
) をインストールしている。
手順
serving.yaml
という名前のファイルを作成し、以下の YAML サンプルをこれにコピーします。apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving
serving.yaml
ファイルを適用します。$ oc apply -f serving.yaml
検証
インストールが完了したことを確認するには、以下のコマンドを実行します。
$ oc get knativeserving.operator.knative.dev/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'
出力例
DependenciesInstalled=True DeploymentsAvailable=True InstallSucceeded=True Ready=True
注記Knative Serving リソースが作成されるまでに数分の時間がかかる場合があります。
条件のステータスが
Unknown
またはFalse
である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。Knative Serving リソースが作成されていることを確認します。
$ oc get pods -n knative-serving
出力例
NAME READY STATUS RESTARTS AGE activator-67ddf8c9d7-p7rm5 2/2 Running 0 4m activator-67ddf8c9d7-q84fz 2/2 Running 0 4m autoscaler-5d87bc6dbf-6nqc6 2/2 Running 0 3m59s autoscaler-5d87bc6dbf-h64rl 2/2 Running 0 3m59s autoscaler-hpa-77f85f5cc4-lrts7 2/2 Running 0 3m57s autoscaler-hpa-77f85f5cc4-zx7hl 2/2 Running 0 3m56s controller-5cfc7cb8db-nlccl 2/2 Running 0 3m50s controller-5cfc7cb8db-rmv7r 2/2 Running 0 3m18s domain-mapping-86d84bb6b4-r746m 2/2 Running 0 3m58s domain-mapping-86d84bb6b4-v7nh8 2/2 Running 0 3m58s domainmapping-webhook-769d679d45-bkcnj 2/2 Running 0 3m58s domainmapping-webhook-769d679d45-fff68 2/2 Running 0 3m58s storage-version-migration-serving-serving-0.26.0--1-6qlkb 0/1 Completed 0 3m56s webhook-5fb774f8d8-6bqrt 2/2 Running 0 3m57s webhook-5fb774f8d8-b8lt5 2/2 Running 0 3m57s
必要なネットワークコンポーネントが、自動的に作成された
knative-serving-ingress
namespace にインストールされていることを確認します。$ oc get pods -n knative-serving-ingress
出力例
NAME READY STATUS RESTARTS AGE net-kourier-controller-7d4b6c5d95-62mkf 1/1 Running 0 76s net-kourier-controller-7d4b6c5d95-qmgm2 1/1 Running 0 76s 3scale-kourier-gateway-6688b49568-987qz 1/1 Running 0 75s 3scale-kourier-gateway-6688b49568-b5tnp 1/1 Running 0 75s
3.2.3. 次のステップ
- Knative イベント駆動型アーキテクチャーを使用する必要がある場合は、Knative Eventing をインストール できます。
3.3. Knative Eventing のインストール
クラスターでイベント駆動型アーキテクチャーを使用するには、Knative Eventing をインストールします。イベントソース、ブローカー、チャネルなどの Knative コンポーネントを作成し、それらを使用してアプリケーションや外部システムにイベントを送信することができます。
OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Eventing をインストールするか、KnativeEventing
カスタムリソース (CR) でより高度な設定を行うことが可能です。KnativeEventing
CR の設定オプションの詳細は、「 グローバル設定 」を参照してください。
Red Hat OpenShift 分散トレースを OpenShift Serverless で使用 する場合、Knative Eventing をインストールする前に Red Hat OpenShift 分散トレースをインストールし、設定する必要があります。
3.3.1. Web コンソールを使用した Knative Eventing のインストール
OpenShift Serverless Operator をインストールした後、OpenShift Container Platform の Web コンソールを使用して Knative Eventing をインストールします。デフォルトの設定で Knative Eventing をインストールするか、KnativeEventing
カスタムリソース (CR) でより詳細な設定を行うことが可能です。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator がインストールされている。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- ページ上部の Project ドロップダウンメニューが Project: knative-eventing に設定されていることを確認します。
- OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。
- Create Knative Eventing をクリックします。
Create Knative Eventing ページでは、提供されるデフォルトのフォームを使用するか、または YAML を編集して
KnativeEventing
オブジェクトを設定できます。KnativeEventing
オブジェクト作成を完全に制御する必要がない単純な設定には、このフォームの使用が推奨されます。オプション:フォームを使用して
KnativeEventing
オブジェクトを設定する場合は、Knative Eventing デプロイメントに対して実装する必要のある変更を加えます。
作成 をクリックします。
KnativeEventing
オブジェクトの作成を完全に制御する必要のあるより複雑な設定には、YAML の編集が推奨されます。YAML にアクセスするには、Create Knative Eventing ページの右上にある edit YAML リンクをクリックします。オプション:YAML を編集して
KnativeEventing
オブジェクトを設定する場合は、Knative Eventing デプロイメントについて実装する必要のある変更を YAML に加えます。
- 作成 をクリックします。
-
Knative Eventing のインストール後に、
KnativeEventing
オブジェクトが作成され、Knative Eventing タブに自動的にダイレクトされます。リソースの一覧にknative-eventing
リソースが表示されます。
検証
-
Knative Eventing タブで
knative-eventing
カスタムリソースをクリックします。 Knative Eventing Overview ページに自動的にダイレクトされます。
- スクロールダウンして、Conditions の一覧を確認します。
ステータスが True の条件の一覧が表示されます(例のイメージを参照)。
注記Knative Eventing リソースが作成されるまでに数秒の時間がかかる場合があります。Resources タブでステータスを確認できます。
- 条件のステータスが Unknown または False である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。
3.3.2. YAML を使用した Knative Eventing のインストール
OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Eventing をインストールするか、KnativeEventing
カスタムリソース (CR) でより高度な設定を行うことが可能です。YAML ファイルと oc
CLI を利用して、以下の手順で Knative Eventing をインストールすることができます。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Serverless Operator がインストールされている。
-
OpenShift CLI (
oc
) をインストールしている。
手順
-
eventing.yaml
という名前のファイルを作成します。 以下のサンプル YAML を
eventing.yaml
にコピーします。apiVersion: operator.knative.dev/v1alpha1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing
- オプション:Knative Eventing デプロイメントについて実装する必要のある変更を YAML に加えます。
以下を入力して
eventing.yaml
ファイルを適用します。$ oc apply -f eventing.yaml
検証
以下のコマンドを入力して出力を確認し、インストールが完了したことを確認します。
$ oc get knativeeventing.operator.knative.dev/knative-eventing \ -n knative-eventing \ --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'
出力例
InstallSucceeded=True Ready=True
注記Knative Eventing リソースが作成されるまでに数秒の時間がかかる場合があります。
-
条件のステータスが
Unknown
またはFalse
である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。 以下のコマンドを実行して Knative Eventing リソースが作成されていることを確認します。
$ oc get pods -n knative-eventing
出力例
NAME READY STATUS RESTARTS AGE broker-controller-58765d9d49-g9zp6 1/1 Running 0 7m21s eventing-controller-65fdd66b54-jw7bh 1/1 Running 0 7m31s eventing-webhook-57fd74b5bd-kvhlz 1/1 Running 0 7m31s imc-controller-5b75d458fc-ptvm2 1/1 Running 0 7m19s imc-dispatcher-64f6d5fccb-kkc4c 1/1 Running 0 7m18s
3.3.3. 次のステップ
- Knative サービスを使用する場合は、Knative Serving をインストールできます。
3.4. OpenShift Serverless の削除
必要に応じて OpenShift Serverless をクラスターから削除するには、OpenShift Serverless Operator およびその他の OpenShift Serverless コンポーネントを手動で削除します。OpenShift Serverless Operator を削除する前に、Knative Serving および Knative Eventing を削除する必要があります。
3.4.1. Knative Serving のアンインストール
OpenShift Serverless Operator を削除する前に、Knative Serving を削除する必要があります。Knative Serving をアンインストールするには、KnativeServing
カスタムリソース (CR) を削除してから knative-serving
namespace を削除する必要があります。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) をインストールしている。
手順
KnativeServing
CR を削除します。$ oc delete knativeservings.operator.knative.dev knative-serving -n knative-serving
コマンドが実行され、すべての Pod が
knative-serving
namespace から削除された後に、namespace を削除します。$ oc delete namespace knative-serving
3.4.2. Knative Eventing のアンインストール
OpenShift Serverless Operator を削除する前に、Knative Eventing を削除する必要があります。Knative Eventing をアンインストールするには、KnativeEventing
カスタムリソース (CR) を削除してから knative-eventing
namespace を削除する必要があります。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) をインストールしている。
手順
KnativeEventing
CR を削除します。$ oc delete knativeeventings.operator.knative.dev knative-eventing -n knative-eventing
コマンドが実行され、すべての Pod が
knative-eventing
namespace から削除された後に、namespace を削除します。$ oc delete namespace knative-eventing
3.4.3. OpenShift Serverless Operator の削除
Knative Serving と Knative Eventing を削除した後、OpenShift Serverless Operator を削除することができます。これは、OpenShift Container Platform の Web コンソールまたは oc
CLI を使用して行うことができます。
3.4.3.1. Web コンソールの使用によるクラスターからの Operator の削除
クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operator を削除できます。
前提条件
-
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスター Web コンソールにアクセスできること。
手順
- Operators → Installed Operators ページからスクロールするか、または Filter by name にキーワードを入力して必要な Operator を見つけます。次に、それをクリックします。
Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。
Uninstall Operator? ダイアログボックスが表示され、以下が通知されます。
Operator を削除しても、そのカスタムリソース定義や管理リソースは削除されません。Operator がクラスターにアプリケーションをデプロイしているか、またはクラスター外のリソースを設定している場合、それらは引き続き実行され、手動でクリーンアップする必要があります。
このアクションにより、Operator および Operator のデプロイメントおよび Pod が削除されます(ある場合)。CRD および CR を含む Operator によって管理される Operand およびリソースは削除されません。Web コンソールは、一部の Operator のダッシュボードおよびナビゲーションアイテムを有効にします。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。
- Uninstall を選択します。この Operator は実行を停止し、更新を受信しなくなります。
3.4.3.2. CLI の使用によるクラスターからの Operator の削除
クラスター管理者は CLI を使用して、選択した namespace からインストールされた Operator を削除できます。
前提条件
-
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできること。 -
oc
コマンドがワークステーションにインストールされていること。
手順
サブスクライブされた Operator (例:
jaeger
) の現行バージョンをcurrentCSV
フィールドで確認します。$ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV
出力例
currentCSV: jaeger-operator.v1.8.2
サブスクリプション (例:
jaeger
) を削除します。$ oc delete subscription jaeger -n openshift-operators
出力例
subscription.operators.coreos.com "jaeger" deleted
直前の手順で
currentCSV
値を使用し、ターゲット namespace の Operator の CSV を削除します。$ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators
出力例
clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted
3.4.3.3. 障害のあるサブスクリプションの更新
Operator Lifecycle Manager (OLM) で、ネットワークでアクセスできないイメージを参照する Operator をサブスクライブする場合、以下のエラーを出して失敗した openshift-marketplace
namespace でジョブを見つけることができます。
出力例
ImagePullBackOff for Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"
出力例
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host
その結果、サブスクリプションはこの障害のある状態のままとなり、Operator はインストールまたはアップグレードを実行できません。
サブスクリプション、クラスターサービスバージョン (CSV) その他の関連オブジェクトを削除して、障害のあるサブスクリプションを更新できます。サブスクリプションを再作成した後に、OLM は Operator の正しいバージョンを再インストールします。
前提条件
- アクセス不可能なバンドルイメージをプルできない障害のあるサブスクリプションがある。
- 正しいバンドルイメージにアクセスできることを確認している。
手順
Operator がインストールされている namespace から
Subscription
およびClusterServiceVersion
オブジェクトの名前を取得します。$ oc get sub,csv -n <namespace>
出力例
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 Succeeded
サブスクリプションを削除します。
$ oc delete subscription <subscription_name> -n <namespace>
クラスターサービスバージョンを削除します。
$ oc delete csv <csv_name> -n <namespace>
openshift-marketplace
namespace の失敗したジョブおよび関連する設定マップの名前を取得します。$ oc get job,configmap -n openshift-marketplace
出力例
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30s
ジョブを削除します。
$ oc delete job <job_name> -n openshift-marketplace
これにより、アクセスできないイメージのプルを試行する Pod は再作成されなくなります。
設定マップを削除します。
$ oc delete configmap <configmap_name> -n openshift-marketplace
- Web コンソールの OperatorHub を使用した Operator の再インストール
検証
Operator が正常に再インストールされていることを確認します。
$ oc get sub,csv,installplan -n <namespace>
3.4.4. OpenShift Serverless カスタムリソース定義の削除
OpenShift Serverless のアンインストール後に、Operator および API カスタムリソース定義 (CRD) はクラスター上に残ります。以下の手順を使用して、残りの CRD を削除できます。
Operator および API CRD を削除すると、Knative サービスを含む、それらを使用して定義されたすべてのリソースも削除されます。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- Knative Serving をアンインストールし、OpenShift Serverless Operator を削除している。
-
OpenShift CLI (
oc
) をインストールしている。
手順
残りの OpenShift Serverless CRD を削除するには、以下のコマンドを実行します。
$ oc get crd -oname | grep 'knative.dev' | xargs oc delete
第4章 Knative CLI
4.1. Knative CLI のインストール
Knative (kn
) CLI には、独自のログインメカニズムがありません。クラスターにログインするには、OpenShift (oc
) CLI をインストールし、oc login
コマンドを使用する必要があります。CLI のインストールオプションは、オペレーティングシステムによって異なる場合があります。
ご使用のオペレーティングシステム用に oc
CLI をインストールする方法および oc
でのログイン方法についての詳細は、OpenShift CLI の使用開始についてのドキュメントを参照してください。
Knative (kn
) CLI を使用して OpenShift Serverless をインストールすることはできません。クラスター管理者は、OpenShift Serverless Operator のインストール のドキュメントで説明されているように、OpenShift Serverless Operator をインストールし、Knative コンポーネントをセットアップする必要があります。
古いバージョンの Knative(kn
)CLI を新規の OpenShift Serverless リリースで使用しようとする場合、API は見つからず、エラーが発生します。
たとえば、Knative Serving および Knative Eventing API の 0.23.0 バージョンを使用する Knative(kn
)CLI の 1.16.0 リリースをバージョン 0.22.0 と共に使用する場合、Knative Serving および Knative Eventing API の 0.23.0 バージョンを引き続き使用するため、CLI は動作しません。
問題を回避するために、OpenShift Serverless リリースに最新の Knative(kn
)CLI バージョンを使用していることを確認します。
4.1.1. OpenShift Container Platform Web コンソールを使用した Knative CLI のインストール
OpenShift Container Platform Web コンソールを使用すると、Knative (kn
) CLI をインストールするための合理化された直感的なユーザーインターフェイスが提供されます。OpenShift Serverless Operator をインストールすると、OpenShift Container PlatformWeb コンソールの コマンドラインツール ページから Linux (amd64、s390x、ppc64le)、macOS、または Windows 用の Knative (kn
) CLI をダウンロードするためのリンクが表示されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
OpenShift Serverless Operator が OpenShift Container Platform クラスターにインストールされている。
重要libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。
$ kn: No such file or directory
手順
-
コマンドラインツールページから Knative(
kn
)CLI を ダウンロードします。Command Line Tools ページには、Web コンソールの右上隅にあるアイコンをクリックして、一覧で Command Line Tools を選択します。
アーカイブを展開します。
$ tar -xf <file>
-
kn
バイナリーをPATH
にあるディレクトリーに移動します。 PATH
を確認するには、以下を実行します。$ echo $PATH
4.1.2. RPM パッケージマネージャーを使用した Linux 用の KnativeCLI のインストール
Red Hat Enterprise Linux (RHEL) の場合、yum
や dnf
などのパッケージマネージャーを使用して、Knative (kn
) CLI を RPM としてインストールできます。これにより、Knative CLI バージョンをシステムで自動的に管理できます。たとえば、dnf upgrade
のようなコマンドを使用すると、新しいバージョンが利用可能な場合、kn
を含むすべてのパッケージがアップグレードされます。
前提条件
- お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがある。
手順
Red Hat Subscription Manager に登録します。
# subscription-manager register
最新のサブスクリプションデータをプルします。
# subscription-manager refresh
登録済みのシステムにサブスクリプションを添付します。
# subscription-manager attach --pool=<pool_id> 1
- 1
- 有効な OpenShift Container Platform サブスクリプションのプール ID
Knative (
kn
) CLI に必要なリポジトリーを有効にします。Linux (x86_64, amd64)
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
Linux on IBM Z and LinuxONE (s390x)
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-s390x-rpms"
Linux on IBM Power (ppc64le)
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-ppc64le-rpms"
パッケージマネージャーを使用して、Knative (
kn
) CLI を RPM としてインストールします。yum
コマンドの例# yum install openshift-serverless-clients
4.1.3. Linux の Knative CLI のインストール
RPM または別のパッケージマネージャーがインストールされていない Linux ディストリビューションを使用している場合は、Knative (kn
) CLI をバイナリーファイルとしてインストールできます。これを行うには、tar.gz
アーカイブをダウンロードして解凍し、バイナリーを PATH
のディレクトリーに追加する必要があります。
前提条件
RHEL または Fedora を使用していない場合は、ライブラリーパスのディレクトリーに libc がインストールされていることを確認してください。
重要libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。
$ kn: No such file or directory
手順
関連する Knative(
kn
)CLItar.gz
アーカイブをダウンロードします。アーカイブを展開します。
$ tar -xf <filename>
-
kn
バイナリーをPATH
にあるディレクトリーに移動します。 PATH
を確認するには、以下を実行します。$ echo $PATH
4.1.4. macOS の Knative CLI のインストール
macOS を使用している場合は、Knative (kn
) CLI をバイナリーファイルとしてインストールできます。これを行うには、tar.gz
アーカイブをダウンロードして解凍し、バイナリーを PATH
のディレクトリーに追加する必要があります。
手順
-
Knative (
kn
)CLItar.gz
アーカイブ をダウンロードします。 - アーカイブを解凍して解凍します。
-
kn
バイナリーをPATH
にあるディレクトリーに移動します。 PATH
を確認するには、ターミナルウィンドウを開き、以下を実行します。$ echo $PATH
4.1.5. Windows の Knative CLI のインストール
Windows を使用している場合は、Knative (kn
) CLI をバイナリーファイルとしてインストールできます。これを行うには、ZIP アーカイブをダウンロードして解凍し、バイナリーを PATH
のディレクトリーに追加する必要があります。
手順
-
Knative (
kn
) CLIZIP アーカイブ をダウンロードします。 - ZIP プログラムでアーカイブを展開します。
-
kn
バイナリーをPATH
にあるディレクトリーに移動します。 PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
4.2. KnativeCLI の設定
config.yaml
設定ファイルを作成することで、Knative (kn
) CLI セットアップをカスタマイズできます。--config
フラグを使用してこの設定を指定できます。指定しない場合、設定がデフォルトの場所から選択されます。デフォルトの設定場所は XDGBaseDirectory 仕様 に準拠しており、UNIX システムと Windows システムでは異なります。
UNIX システムの場合:
-
XDG_CONFIG_HOME
環境変数が設定されている場合、Knative (kn
) CLI が検索するデフォルト設定の場所は$XDG_CONFIG_HOME/kn
になります。 -
XDG_CONFIG_HOME
環境変数が設定されていない場合、Knative (kn
) CLI は$HOME/.config/kn/config.yaml
のユーザーのホームディレクトリーにある設定を検索します。
Windows システムの場合、デフォルトの Knative (kn
) CLI 設定の場所は %APPDATA%\kn
です。
設定ファイルのサンプル
plugins: path-lookup: true 1 directory: ~/.config/kn/plugins 2 eventing: sink-mappings: 3 - prefix: svc 4 group: core 5 version: v1 6 resource: services 7
- 1
- Knative (
kn
) CLI がPATH
環境変数でプラグインを検索するかどうかを指定します。これはブール型の設定オプションです。デフォルト値はfalse
です。 - 2
- Knative (
kn
) CLI がプラグインを検索するディレクトリーを指定します。前述のように、デフォルトのパスはオペレーティングシステムによって異なります。これには、ユーザーに表示される任意のディレクトリーを指定できます。 - 3
sink-mappings
仕様は、Knative (kn
) CLI コマンドで--sink
フラグを使用する場合に使用される Kubernetes のアドレス可能なリソースを定義します。- 4
- シンクの記述に使用するプレフィックス。サービスの
svc
、channel
、およびbroker
は Knative (kn
) CLI で事前に定義されるプレフィックスです。 - 5
- Kubernetes リソースの API グループ。
- 6
- Kubernetes リソースのバージョン。
- 7
- Kubernetes リソースタイプの複数形の名前。例:
services
またはbrokers
4.3. Knative CLI プラグイン
Knative (kn
) CLI は、プラグインの使用をサポートします。これにより、カスタムコマンドとコアディストリビューションの一部ではない他の共有コマンドを追加でき、kn
インストールの機能の拡張を可能にします。Knative (kn
) CLI プラグインは主な kn
機能として同じ方法で使用されます。
現在、Red Hat は kn-source-kafka
プラグインと kn-event
プラグインをサポートしています。
kn-event
プラグインは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
4.3.1. kn-event プラグインを使用してイベントを作成する
kn event build
コマンドのビルダーのようなインターフェースを使用して、イベントをビルドできます。その後、そのイベントを後で送信するか、別のコンテキストで使用できます。
前提条件
-
Knative (
kn
) CLI をインストールしている。
手順
イベントをビルドします。
$ kn event build --field <field-name>=<value> --type <type-name> --id <id> --output <format>
ここで、
-
--field
フラグは、データをフィールド/値のペアとしてイベントに追加します。これは複数回使用できます。 -
--type
フラグを使用すると、イベントのタイプを指定する文字列を指定できます。 -
--id
フラグは、イベントの ID を指定します。 json
またはyaml
引数を--output
フラグと共に使用して、イベントの出力形式を変更できます。これらのフラグはすべてオプションです。
簡単なイベントのビルド
$ kn event build -o yaml
YAML 形式のビルドされたイベント
data: {} datacontenttype: application/json id: 81a402a2-9c29-4c27-b8ed-246a253c9e58 source: kn-event/v0.4.0 specversion: "1.0" time: "2021-10-15T10:42:57.713226203Z" type: dev.knative.cli.plugin.event.generic
サンプルトランザクションイベントのビルド
$ kn event build \ --field operation.type=local-wire-transfer \ --field operation.amount=2345.40 \ --field operation.from=87656231 \ --field operation.to=2344121 \ --field automated=true \ --field signature='FGzCPLvYWdEgsdpb3qXkaVp7Da0=' \ --type org.example.bank.bar \ --id $(head -c 10 < /dev/urandom | base64 -w 0) \ --output json
JSON 形式のビルドされたイベント
{ "specversion": "1.0", "id": "RjtL8UH66X+UJg==", "source": "kn-event/v0.4.0", "type": "org.example.bank.bar", "datacontenttype": "application/json", "time": "2021-10-15T10:43:23.113187943Z", "data": { "automated": true, "operation": { "amount": "2345.40", "from": 87656231, "to": 2344121, "type": "local-wire-transfer" }, "signature": "FGzCPLvYWdEgsdpb3qXkaVp7Da0=" } }
-
4.3.2. kn-event プラグインを使用してイベントを送信する
kn event send
コマンドを使用して、イベントを送信できます。イベントは、公開されているアドレス、または Kubernetes サービスやKnative サービス、ブローカー、チャネル等のクラスター内のアドレス指定可能なリソースのいずれかに送信できます。このコマンドは、kn event build
コマンドと同じビルダーのようなインターフェースを使用します。
前提条件
-
Knative (
kn
) CLI をインストールしている。
手順
イベントの送信:
$ kn event send --field <field-name>=<value> --type <type-name> --id <id> --to-url <url> --to <cluster-resource> --namespace <namespace>
ここで、
-
--field
フラグは、データをフィールド/値のペアとしてイベントに追加します。これは複数回使用できます。 -
--type
フラグを使用すると、イベントのタイプを指定する文字列を指定できます。 -
--id
フラグは、イベントの ID を指定します。 -
イベントを一般にアクセス可能な宛先に送信する場合は、
--to-url
フラグを使用して URL を指定します。 イベントをクラスター内の Kubernetes リソースに送信する場合は、
--to
フラグを使用して宛先を指定します。-
<Kind>:<ApiVersion>:<name>
形式を使用して Kubernetes リソースを指定します。
-
--namespace
フラグは namespace を指定します。省略すると、namespace は現在のコンテキストから取得されます。--to-url
または--to
のいずれかを使用する必要がある宛先の仕様を除き、これらのフラグはすべてオプションです。以下の例は、イベントを URL に送信するケースを示しています。
コマンドの例
$ kn event send \ --field player.id=6354aa60-ddb1-452e-8c13-24893667de20 \ --field player.game=2345 \ --field points=456 \ --type org.example.gaming.foo \ --to-url http://ce-api.foo.example.com/
以下の例は、イベントをクラスター内のリソースに送信するケースを示しています。
コマンドの例
$ kn event send \ --type org.example.kn.ping \ --id $(uuidgen) \ --field event.type=test \ --field event.data=98765 \ --to Service:serving.knative.dev/v1:event-display
-
4.4. Knative Serving CLI コマンド
以下の kn
CLI コマンドを使用して、クラスター上で Knative Serving タスクを実行できます。
4.4.1. kn service コマンド
以下のコマンドを使用して Knative サービスを作成し、管理できます。
4.4.1.1. Knative CLI を使用したサーバーレスアプリケーションの作成
サーバーレスアプリケーションを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn service create
コマンドを使えば、kn
CLI を使用して基本的なサーバーレスアプリケーションを作成することができます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
-
kn
CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Knative サービスを作成します。
$ kn service create <service_name> --image <image> --tag <tag-value>
詳細は以下のようになります。
-
--image
は、アプリケーションのイメージの URI です。 --tag
は、サービスで作成された初期リビジョンにタグを追加するために使用できるオプションのフラグです。コマンドの例
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
出力例
Creating service 'event-display' in namespace 'default': 0.271s The Route is still working to reflect the latest desired specification. 0.580s Configuration "event-display" is waiting for a Revision to become ready. 3.857s ... 3.861s Ingress has not yet been reconciled. 4.270s Ready to serve. Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL: http://event-display-default.apps-crc.testing
-
4.4.1.2. Knative CLI を使用したサーバーレスアプリケーションの更新
サービスを段階的に構築する際に、コマンドラインで kn service update
コマンドを使用し、対話式のセッションを使用できます。kn service apply
コマンドとは対照的に、kn service update
コマンドを使用する際は、Knative サービスの完全な設定ではなく、更新が必要な変更のみを指定する必要があります。
コマンドの例
新規の環境変数を追加してサービスを更新します。
$ kn service update <service_name> --env <key>=<value>
新しいポートを追加してサービスを更新します。
$ kn service update <service_name> --port 80
新しい要求および制限パラメーターを追加してサービスを更新します。
$ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
latest
タグをリビジョンに割り当てます。$ kn service update <service_name> --tag <revision_name>=latest
サービスの最新の
READY
リビジョンについて、testing
からstaging
にタグを更新します。$ kn service update <service_name> --untag testing --tag @latest=staging
test
タグをトラフィックの 10% を受信するリビジョンに追加し、残りのトラフィックをサービスの最新のREADY
リビジョンに送信します。$ kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90
4.4.1.3. サービス宣言の適用
kn service apply
コマンドを使用して Knative サービスを宣言的に設定できます。サービスが存在しない場合は、これが作成されますが、それ以外の場合は、既存のサービスが変更されたオプションで更新されます。
kn service apply
コマンドは、ユーザーがターゲットの状態を宣言するために単一コマンドでサービスの状態を詳細に指定したい場合など、とくにシェルスクリプトや継続的インテグレーションパイプラインで役に立ちます。
kn service apply
を使用する場合は、Knative サービスの詳細な設定を指定する必要があります。これは kn service update
コマンドとは異なります。このコマンドでは、更新する必要のあるオプションを指定するだけで済みます。
コマンドの例
サービスを作成します。
$ kn service apply <service_name> --image <image>
環境変数をサービスに追加します。
$ kn service apply <service_name> --image <image> --env <key>=<value>
JSON または YAML ファイルからサービス宣言を読み取ります。
$ kn service apply <service_name> -f <filename>
4.4.1.4. Knative CLI を使用したサーバーレスアプリケーションの記述
kn service describe
コマンドを使用して Knative サービスを記述できます。
コマンドの例
サービスを記述します。
$ kn service describe --verbose <service_name>
--verbose
フラグは任意ですが、さらに詳細な説明を提供するために追加できます。通常の出力と詳細の出力の違いについては、以下の例に示されます。--verbose
フラグを使用しない出力例Name: hello Namespace: default Age: 2m URL: http://hello-default.apps.ocp.example.com Revisions: 100% @latest (hello-00001) [1] (2m) Image: docker.io/openshift/hello-openshift (pinned to aaea76) Conditions: OK TYPE AGE REASON ++ Ready 1m ++ ConfigurationsReady 1m ++ RoutesReady 1m
--verbose
フラグを使用する出力例Name: hello Namespace: default Annotations: serving.knative.dev/creator=system:admin serving.knative.dev/lastModifier=system:admin Age: 3m URL: http://hello-default.apps.ocp.example.com Cluster: http://hello.default.svc.cluster.local Revisions: 100% @latest (hello-00001) [1] (3m) Image: docker.io/openshift/hello-openshift (pinned to aaea76) Env: RESPONSE=Hello Serverless! Conditions: OK TYPE AGE REASON ++ Ready 3m ++ ConfigurationsReady 3m ++ RoutesReady 3m
サービスを YAML 形式で記述します。
$ kn service describe <service_name> -o yaml
サービスを JSON 形式で記述します。
$ kn service describe <service_name> -o json
サービス URL のみを出力します。
$ kn service describe <service_name> -o url
4.4.2. Knative CLI オフラインモードについて
kn service
コマンドを実行すると、変更が即座にクラスターに伝播されます。ただし、別の方法として、オフラインモードで kn service
コマンドを実行できます。オフラインモードでサービスを作成すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。
Knative CLI のオフラインモードはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
記述子ファイルの作成後、手動で変更し、バージョン管理システムで追跡できます。記述子ファイルで kn service create -f
、kn service apply -f
または oc apply -f
コマンドを使用して変更をクラスターに伝播することもできます。
オフラインモードには、いくつかの用途があります。
- 記述子ファイルを使用してクラスターで変更する前に、記述子ファイルを手動で変更できます。
- バージョン管理システムでは、サービスの記述子ファイルをローカルで追跡できます。これにより、記述子ファイルを再利用できます。たとえば、継続的インテグレーション (CI) パイプライン、開発環境またはデモなどで、ターゲットクラスター以外の配置が可能になります。
-
作成した記述子ファイルを検証して Knative サービスについて確認できます。特に、生成されるサービスが
kn
コマンドに渡されるさまざまな引数によってどのように影響するかを確認できます。
オフラインモードには、高速で、クラスターへの接続を必要としないという利点があります。ただし、オフラインモードではサーバー側の検証がありません。したがって、サービス名が一意であることや、指定のイメージをプルできることなどを確認できません。
4.4.2.1. オフラインモードを使用したサービスの作成
オフラインモードで kn service
コマンドを実行すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。記述子ファイルを作成した後、クラスターに変更を伝播する前にファイルを変更することができます。
Knative CLI のオフラインモードはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
-
Knative (
kn
) CLI をインストールしている。
手順
オフラインモードでは、ローカルの Knative サービス記述子ファイルを作成します。
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \ --target ./ \ --namespace test
出力例
Service 'event-display' created in namespace 'test'.
--target ./
フラグはオフラインモードを有効にし、./
を新しいディレクトリーツリーを保存するディレクトリーとして指定します。既存のディレクトリーを指定せずに、
--target my-service.yaml
などのファイル名を使用すると、ディレクトリーツリーは作成されません。代わりに、サービス記述子ファイルmy-service.yaml
のみが現在のディレクトリーに作成されます。ファイル名には、
.yaml
、.yml
または.json
拡張子を使用できます。.json
を選択すると、JSON 形式でサービス記述子ファイルが作成されます。--namespace test
オプションは、新規サービスをテスト
namespace に配置します。--namespace
を使用せずに、OpenShift クラスターにログインしている場合には、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルがdefault
の namespace に作成されます。
作成したディレクトリー構造を確認します。
$ tree ./
出力例
./ └── test └── ksvc └── event-display.yaml 2 directories, 1 file
-
--target
で指定する現在の./
ディレクトリーには新しいtest/
ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。 -
test/
ディレクトリーには、リソースタイプの名前が付けられたksvc
ディレクトリーが含まれます。 -
ksvc
ディレクトリーには、指定のサービス名に従って命名される記述子ファイルevent-display.yaml
が含まれます。
-
生成されたサービス記述子ファイルを確認します。
$ cat test/ksvc/event-display.yaml
出力例
apiVersion: serving.knative.dev/v1 kind: Service metadata: creationTimestamp: null name: event-display namespace: test spec: template: metadata: annotations: client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest creationTimestamp: null spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest name: "" resources: {} status: {}
新しいサービスに関する情報を一覧表示します。
$ kn service describe event-display --target ./ --namespace test
出力例
Name: event-display Namespace: test Age: URL: Revisions: Conditions: OK TYPE AGE REASON
--target ./
オプションは、namespace サブディレクトリーを含むディレクトリー構造のルートディレクトリーを指定します。または、
--target
オプションで YAML または JSON ファイルを直接指定できます。使用可能なファイルの拡張子は、.yaml
、.yml
、および.json
です。--namespace
オプションは、namespace を指定し、この namespace は必要なサービス記述子ファイルを含むサブディレクトリーのkn
と通信します。--namespace
を使用せず、OpenShift クラスターにログインしている場合には、kn
は現在の namespace をもとに名前が付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kn
はdefault/
サブディレクトリーで検索します。
サービス記述子ファイルを使用してクラスターでサービスを作成します。
$ kn service create -f test/ksvc/event-display.yaml
出力例
Creating service 'event-display' in namespace 'test': 0.058s The Route is still working to reflect the latest desired specification. 0.098s ... 0.168s Configuration "event-display" is waiting for a Revision to become ready. 23.377s ... 23.419s Ingress has not yet been reconciled. 23.534s Waiting for load balancer to be ready 23.723s Ready to serve. Service 'event-display' created to latest revision 'event-display-00001' is available at URL: http://event-display-test.apps.example.com
4.4.3. kn container コマンド
以下のコマンドを使用して、Knative サービス仕様で複数のコンテナーを作成し、管理できます。
4.4.3.1. Knative クライアントマルチコンテナーのサポート
kn container add
コマンドを使用して、YAML コンテナーの仕様を標準出力に出力できます。このコマンドは、定義を作成するために他の標準の kn
フラグと共に使用できるため、マルチコンテナーのユースケースに役立ちます。
kn container add
コマンドは、kn service create
コマンドで使用できるコンテナー関連のすべてのフラグを受け入れます。UNIX パイプ(|
)を使用してkn container add
コマンドを連結して、一度に複数のコンテナー定義を作成することもできます。
コマンドの例
イメージからコンテナーを追加し、標準出力に出力します。
$ kn container add <container_name> --image <image_uri>
コマンドの例
$ kn container add sidecar --image docker.io/example/sidecar
出力例
containers: - image: docker.io/example/sidecar name: sidecar resources: {}
2 つの
kn container add
コマンドを連結してから、kn service create
コマンドに渡して、2 つのコンテナーで Knative サービスを作成します。$ kn container add <first_container_name> --image <image_uri> | \ kn container add <second_container_name> --image <image_uri> | \ kn service create <service_name> --image <image_uri> --extra-containers -
--extra-containers -
は、kn
が YAML ファイルの代わりにパイプ入力を読み取る特別なケースを指定します。コマンドの例
$ kn container add sidecar --image docker.io/example/sidecar:first | \ kn container add second --image docker.io/example/sidecar:second | \ kn service create my-service --image docker.io/example/my-app:latest --extra-containers -
--extra-containers
フラグは YAML ファイルへのパスを受け入れることもできます。$ kn service create <service_name> --image <image_uri> --extra-containers <filename>
コマンドの例
$ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml
4.4.4. kn domain コマンド
以下のコマンドを使用して、ドメインマッピングを作成および管理できます。
4.4.4.1. Knative CLI を使用したカスタムドメインマッピングの作成
独自のカスタムドメイン名を Knative サービスにマッピングして、Knative サービスのドメインをカスタマイズできます。Knative(kn
)CLI を使用して、Knative サービスまたは Knative ルートなどの Addressable target CR にマップする DomainMapping
カスタムリソース(CR)を作成できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
Knative サービスまたはルートを作成し、その CR にマップするカスタムドメインを制御している。
注記カスタムドメインは OpenShift Container Platform クラスターの DNS を参照する必要があります。
-
kn
CLI ツールがインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
ドメインを現在の namespace の CR にマップします。
$ kn domain create <domain_mapping_name> --ref <target_name>
コマンドの例
$ kn domain create example.com --ref example-service
--ref
フラグは、ドメインマッピング用のアドレス指定可能なターゲット CR を指定します。--ref
フラグの使用時にプレフィックスが指定されていない場合、ターゲットが現在の namespace の Knative サービスであることを前提としています。ドメインを指定された namespace の Knative サービスにマップします。
$ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>
コマンドの例
$ kn domain create example.com --ref ksvc:example-service:example-namespace
ドメインを Knative ルートにマップします。
$ kn domain create <domain_mapping_name> --ref <kroute:route_name>
コマンドの例
$ kn domain create example.com --ref kroute:example-route
4.4.4.2. Knative CLI を使用したカスタムドメインマッピングの管理
DomainMapping
カスタムリソース (CR) の作成後に、既存の CR の一覧表示、既存の CR の情報の表示、CR の更新、または kn
CLI を使用した CR の削除を実行できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
1 つ以上の
DomainMapping
CR を作成している。 -
kn
CLI ツールがインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
既存の
DomainMapping
CR を一覧表示します。$ kn domain list -n <domain_mapping_namespace>
既存の
DomainMapping
CR の詳細を表示します。$ kn domain describe <domain_mapping_name>
新規ターゲットを参照するように
DomainMapping
CR を更新します。$ kn domain update --ref <target>
DomainMapping
CR を削除します。$ kn domain delete <domain_mapping_name>
4.5. Knative Eventing CLI コマンド
以下の Knative (kn
) CLI コマンドを使用して、クラスター上で Knative Eventing タスクを実行できます。
4.5.1. kn source コマンド
以下のコマンドを使用して、Knative イベントソースを一覧表示、作成、および管理できます。
4.5.1.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示
kn
CLI を使用すると、クラスターで使用可能なイベントソースタイプを表示するための合理的で直感的なユーザーインターフェースが提供されます。kn source list-types
CLI コマンドを使用して、クラスターで作成して使用できるイベントソースタイプを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
ターミナルに利用可能なイベントソースタイプを一覧表示します。
$ kn source list-types
出力例
TYPE NAME DESCRIPTION ApiServerSource apiserversources.sources.knative.dev Watch and send Kubernetes API events to a sink PingSource pingsources.sources.knative.dev Periodically send ping events to a sink SinkBinding sinkbindings.sources.knative.dev Binding for connecting a PodSpecable to a sink
オプション: 利用可能なイベントソースタイプを YAML 形式で一覧表示することもできます。
$ kn source list-types -o yaml
4.5.1.2. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel
およびbroker
が含まれます。
4.5.1.3. Knative CLI を使用したコンテナーソースの作成および管理
kn source container
コマンドを使用し、kn
CLI を使用してコンテナーソースを作成および管理できます。イベントソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
コンテナーソースを作成します。
$ kn source container create <container_source_name> --image <image_uri> --sink <sink>
コンテナーソースの削除
$ kn source container delete <container_source_name>
コンテナーソースを記述します。
$ kn source container describe <container_source_name>
既存のコンテナーソースを一覧表示
$ kn source container list
既存のコンテナーソースを YAML 形式で一覧表示
$ kn source container list -o yaml
コンテナーソースを更新します。
このコマンドにより、既存のコンテナーソースのイメージ URI が更新されます。
$ kn source container update <container_source_name> --image <image_uri>
4.5.1.4. Knative CLI を使用した API サーバーソースの作成
kn source apiserver create
コマンドを使用し、kn
CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc
) CLI がインストールされている。 -
Knative (
kn
) CLI をインストールしている。
既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount
リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: events-sa namespace: default 1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: event-watcher namespace: default 2 rules: - apiGroups: - "" resources: - events verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k8s-ra-event-watcher namespace: default 3 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: event-watcher subjects: - kind: ServiceAccount name: events-sa namespace: default 4
YAML ファイルを適用します。
$ oc apply -f <filename>
イベントシンクを持つ API サーバーソースを作成します。次の例では、シンクはブローカーです。
$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。
$ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、
default
のブローカーからサービスへのイベントをフィルタリングします。$ kn trigger create <trigger_name> --sink ksvc:<service_name>
デフォルト namespace で Pod を起動してイベントを作成します。
$ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。
$ kn source apiserver describe <source_name>
出力例
Name: mysource Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 3m ServiceAccountName: events-sa Mode: Resource Sink: Name: default Namespace: default Kind: Broker (eventing.knative.dev/v1) Resources: Kind: event (v1) Controller: false Conditions: OK TYPE AGE REASON ++ Ready 3m ++ Deployed 3m ++ SinkProvided 3m ++ SufficientPermissions 3m ++ EventTypesProvided 3m
検証
メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative に送信されていることを確認できます。
Pod を取得します。
$ oc get pods
Pod のメッセージダンパー機能ログを表示します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.apiserver.resource.update datacontenttype: application/json ... Data, { "apiVersion": "v1", "involvedObject": { "apiVersion": "v1", "fieldPath": "spec.containers{hello-node}", "kind": "Pod", "name": "hello-node", "namespace": "default", ..... }, "kind": "Event", "message": "Started container", "metadata": { "name": "hello-node.159d7608e3a3572c", "namespace": "default", .... }, "reason": "Started", ... }
API サーバーソースの削除
トリガーを削除します。
$ kn trigger delete <trigger_name>
イベントソースを削除します。
$ kn source apiserver delete <source_name>
サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
$ oc delete -f authentication.yaml
4.5.1.5. Knative CLI を使用した ping ソースの作成
kn source ping create
コマンドを使用し、kn
CLI を使用して ping ソースを作成できます。イベントソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
オプション: この手順の検証手順を使用する場合は、OpenShift (
oc
) CLI をインストールします。
手順
ping ソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
要求する必要のある ping イベントのセットごとに、PingSource をイベントコンシューマーと同じ namespace に作成します。
$ kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
$ kn source ping describe test-ping-source
出力例
Name: test-ping-source Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 15s Schedule: */2 * * * * Data: {"message": "Hello world!"} Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 8s ++ Deployed 8s ++ SinkProvided 15s ++ ValidSchedule 15s ++ EventTypeProvided 15s ++ ResourcesCorrect 15s
検証
シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。
デフォルトで、Knative サービスは、トラフィックが 60 秒以内に受信されない場合に Pod を終了します。本書の例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する ping ソースを作成します。
作成された新規 Pod を監視します。
$ watch oc get pods
Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.sources.ping source: /apis/v1/namespaces/default/pingsources/test-ping-source id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9 time: 2020-04-07T16:16:00.000601161Z datacontenttype: application/json Data, { "message": "Hello world!" }
ping ソースの削除
ping ソースを削除します。
$ kn delete pingsources.sources.knative.dev <ping_source_name>
4.5.1.6. Knative CLI を使用した Kafka イベントソースの作成
kn source kafka create
コマンドを使用し、kn
CLI を使用して Kafka ソースを作成できます。イベントソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、Knative Serving、および
KnativeKafka
カスタムリソース (CR) がクラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
-
Knative (
kn
) CLI をインストールしている。 -
オプション: この手順で検証ステップを使用する場合は、OpenShift (
oc
) CLI をインストールします。
手順
Kafka イベントソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする Knative サービスを作成します。
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display
KafkaSource
CR を作成します。$ kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display
注記このコマンドのプレースホルダー値は、ソース名、ブートストラップサーバー、およびトピックの値に置き換えます。
--servers
、--topics
、および--consumergroup
オプションは、Kafka クラスターへの接続パラメーターを指定します。--consumergroup
オプションは任意です。オプション: 作成した
KafkaSource
CR の詳細を表示します。$ kn source kafka describe <kafka_source_name>
出力例
Name: example-kafka-source Namespace: kafka Age: 1h BootstrapServers: example-cluster-kafka-bootstrap.kafka.svc:9092 Topics: example-topic ConsumerGroup: example-consumer-group Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 1h ++ Deployed 1h ++ SinkProvided 1h
検証手順
Kafka インスタンスをトリガーし、メッセージをトピックに送信します。
$ oc -n kafka run kafka-producer \ -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \ --restart=Never -- bin/kafka-console-producer.sh \ --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
プロンプトにメッセージを入力します。このコマンドは、以下を前提とします。
-
Kafka クラスターが
kafka
namespace にインストールされている。 -
KafkaSource
オブジェクトは、my-topic
トピックを使用するように設定されている。
-
Kafka クラスターが
ログを表示して、メッセージが到達していることを確認します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.kafka.event source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic subject: partition:46#0 id: partition:46/offset:0 time: 2021-03-10T11:21:49.4Z Extensions, traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00 Data, Hello!
4.6. 関数コマンド
4.6.1. 関数の作成
kn
CLI を使用して基本的なサーバーレス関数を作成できます。
パス、ランタイム、テンプレート、およびリポジトリーをコマンドラインでフラグとして指定するか、-c
フラグを使用してターミナルでインタラクティブなエクスペリエンスを開始できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
kn
CLI がインストールされている。
手順
関数プロジェクトを作成します。
$ kn func create -r <repository> -l <runtime> -t <template> <path>
-
許可されるランタイム値には、
node
、go
、python
、quarkus
、およびtypescript
が含まれます。 許可されるテンプレート値には、
http
およびevents
が含まれます。コマンドの例
$ kn func create -l typescript -t events examplefunc
出力例
Project path: /home/user/demo/examplefunc Function name: examplefunc Runtime: typescript Template: events Writing events to /home/user/demo/examplefunc
または、カスタムテンプレートを含むリポジトリーを指定することもできます。
コマンドの例
$ kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc
出力例
Project path: /home/user/demo/examplefunc Function name: examplefunc Runtime: node Template: hello-world Writing events to /home/user/demo/examplefunc
-
許可されるランタイム値には、
4.6.2. 関数のビルド
関数を実行する前に、kn func build
コマンドを使用して機能プロジェクトをビルドする必要があります。このコマンドは、お使いのコンピューターまたは OpenShift Container Platform クラスターでローカルで実行できる OCI コンテナーイメージを作成します。build コマンドは、関数プロジェクト名とイメージレジストリー名を使用して、関数の完全修飾イメージ名を作成します。
OpenShift Container レジストリーは、デフォルトで機能イメージを保存するためのイメージレジストリーとして使用されます。これは、-r
フラグを使用して上書きできます。
build コマンドの例
$ kn func build -r quay.io/username
出力例
Building function image Function image has been built, image: quay.io/username/example-function:latest
kn func build
コマンドオプションの詳細は、help コマンドを使用できます。
build help コマンド
$ kn func help build
4.6.3. 関数のデプロイ
kn func deploy
コマンドを使用して、関数を Knative サービスとしてクラスターにデプロイできます。ターゲット関数がすでにデプロイされている場合には、コンテナーイメージレジストリーにプッシュされている新規コンテナーイメージで更新され、Knative サービスが更新されます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- デプロイする関数を作成し、初期化している必要があります。
手順
関数をデプロイします。
$ kn func deploy [-n <namespace> -p <path> -i <image>]
出力例
Function deployed at: http://func.example.com
-
namespace
が指定されていない場合には、関数は現在の namespace にデプロイされます。 -
この関数は、
パス
が指定されない限り、現在のディレクトリーからデプロイされます。 - Knative サービス名はプロジェクト名から派生するので、以下のコマンドでは変更できません。
-
4.6.4. 既存の関数の一覧表示
kn func list
を使用して既存の関数を一覧表示できます。Knative サービスとしてデプロイされた関数を一覧表示するには、kn service list
を使用することもできます。
手順
既存の関数を一覧表示します。
$ kn func list [-n <namespace> -p <path>]
出力例
NAME NAMESPACE RUNTIME URL READY example-function default node http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com True
Knative サービスとしてデプロイされた関数を一覧表示します。
$ kn service list -n <namespace>
出力例
NAME URL LATEST AGE CONDITIONS READY REASON example-function http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com example-function-gzl4c 16m 3 OK / 3 True
4.6.5. 関数の記述
kn func info
コマンドは、関数名、イメージ、namespace、Knative サービス情報、ルート情報、イベントサブスクリプションなどのデプロイされた関数に関する情報を出力します。
手順
関数を説明します。
$ kn func info [-f <format> -n <namespace> -p <path>]
コマンドの例
$ kn func info -p function/example-function
出力例
Function name: example-function Function is built in image: docker.io/user/example-function:latest Function is deployed as Knative Service: example-function Function is deployed in namespace: default Routes: http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com
4.6.6. テストイベントを使用してデプロイされた関数を呼び出す
kn func invoke
CLI コマンドを使用して、ローカルまたは OpenShift Container Platform クラスター上で関数を呼び出すためのテストリクエストを送信できます。このコマンドを使用して、関数が機能し、イベントを正しく受信できることをテストできます。
コマンドの例
$ kn func invoke
kn func invoke
コマンドは、デフォルトでローカルディレクトリーで実行され、このディレクトリーが関数プロジェクトであると想定します。
4.6.6.1. kn func はオプションのパラメーターを呼び出します
次の knfuncinvoke
CLI コマンドフラグを使用して、リクエストのオプションのパラメーターを指定できます。
Flags | 説明 |
---|---|
|
呼び出された関数のターゲットインスタンスを指定します。たとえば、 |
|
メッセージの形式を指定します (例: |
| リクエストの一意の文字列識別子を指定します。 |
| クラスターの名前空間を指定します。 |
|
リクエストの送信者名を指定します。これは、CloudEvent |
|
リクエストのタイプを指定します (例: |
|
リクエストの内容を指定します。CloudEvent リクエストの場合、これは CloudEvent |
| 送信するデータを含むローカルファイルへのパスを指定します。 |
| リクエストの MIME コンテンツタイプを指定します。 |
| プロジェクトディレクトリーへのパスを指定します。 |
| すべてのオプションをインタラクティブに確認するためのプロンプトを有効にします。 |
| 詳細出力の印刷を有効にします。 |
|
|
4.6.6.1.1. 主なパラメーター
次のパラメーターは、kn func invoke
コマンドの主なプロパティーを定義します。
- イベントターゲット (
-t
、-target
) -
呼び出された関数のターゲットインスタンス。ローカルにデプロイされた関数の
local
値、リモートにデプロイされた関数のremote
値、または任意のエンドポイントにデプロイされた関数の URL を受け入れます。ターゲットが指定されていない場合、デフォルトでlocal
になります。 - イベントメッセージ形式 (
-f
、--format
) -
http
やcloudevent
などのイベントのメッセージ形式。これは、デフォルトで、関数の作成時に使用されたテンプレートの形式になります。 - イベントタイプ (
--type
) -
送信されるイベントのタイプ。各イベントプロデューサーのドキュメントで設定されている
type
パラメーターに関する情報を見つけることができます。たとえば、API サーバーソースは、生成されたイベントのtype
パラメーターをdev.knative.apiserver.resource.update
として設定する場合があります。 - イベントソース (
--source
) -
イベントを生成する一意のイベントソース。これは、
https://10.96.0.1/
などのイベントソースの URI、またはイベントソースの名前である可能性があります。 - イベント ID (
--id
) - イベントプロデューサーによって作成されるランダムな一意の ID。
- イベントデータ (
--data
) knfuncinvoke
コマンドによって送信されるイベントのdata
値を指定できます。たとえば、イベントにこのデータ文字列が含まれるように、"Hello World"
などの--data
値を指定できます。デフォルトでは、kn func invoke
によって作成されたイベントにデータは含まれていません。注記クラスターにデプロイされた関数は、
source
およびtype
などのプロパティーの値を提供する既存のイベントソースからのイベントに応答できます。これらのイベントには、多くの場合、イベントのドメイン固有のコンテキストをキャプチャする JSON 形式のdata
値があります。このドキュメントに記載されている CLI フラグを使用することで、開発者はローカルテスト用にこれらのイベントをシミュレートできます。--file
フラグを使用してイベントデータを送信し、イベントのデータを含むローカルファイルを指定することもできます。この場合、-content-type
を使用してコンテンツタイプを指定します。- データコンテンツタイプ (
--content-type
) -
--data
フラグを使用してイベントのデータを追加している場合は、-content-type
フラグを使用して、イベントによって伝送されるデータのタイプを指定できます。前の例では、データはプレーンテキストであるため、kn func invoke --data "Hello world!" --content-type "text/plain"
を指定できます。
4.6.6.1.2. コマンドの例
これは、kn func invoke
コマンドの一般的な呼び出しです。
$ kn func invoke --type <event_type> --source <event_source> --data <event_data> --content-type <content_type> --id <event_ID> --format <format> --namespace <namespace>
たとえば、"Hello world!"イベントを送信すると、以下を行うことができます。
$ kn func invoke --type ping --source example-ping --data "Hello world!" --content-type "text/plain" --id example-ID --format http --namespace my-ns
4.6.6.1.2.1. データを含むファイルの指定
イベントデータを含むディスク上のファイルを指定するには、--file
および --content-type
フラグを使用します。
$ kn func invoke --file <path> --content-type <content-type>
たとえば、test.json
ファイルに保存されている JSON データを送信するには、次のコマンドを使用します。
$ kn func invoke --file ./test.json --content-type application/json
4.6.6.1.2.2. 関数プロジェクトの指定
--path
フラグを使用して、関数プロジェクトへのパスを指定できます。
$ kn func invoke --path <path_to_function>
たとえば、/example/example-function
ディレクトリーにある関数プロジェクトを使用するには、次のコマンドを使用します。
$ kn func invoke --path ./example/example-function
4.6.6.1.2.3. ターゲット関数がデプロイされる場所の指定
デフォルトでは、knfuncinvoke
は関数のローカル展開を対象としています。
$ kn func invoke
別のデプロイメントを使用するには、-target
フラグを使用します。
$ kn func invoke --target <target>
たとえば、クラスターにデプロイされた関数を使用するには、-target remote
フラグを使用します。
$ kn func invoke --target remote
任意の URL にデプロイされた関数を使用するには、-target <URL>
フラグを使用します。
$ kn func invoke --target "https://my-event-broker.example.com"
ローカル展開を明示的にターゲットにすることができます。この場合、関数がローカルで実行されていない場合、コマンドは失敗します。
$ kn func invoke --target local
4.6.7. 関数の削除
kn func delete
コマンドを使用して、クラスターから関数を削除できます。
手順
関数を削除します。
$ kn func delete [<function_name> -n <namespace> -p <path>]
-
削除する関数の名前またはパスが指定されていない場合には、現在のディレクトリーで
func.yaml
ファイルを検索し、削除する関数を判断します。 -
namespace が指定されていない場合には、
func.yaml
のnamespace
の値にデフォルト設定されます。
-
削除する関数の名前またはパスが指定されていない場合には、現在のディレクトリーで
第5章 開発
5.1. Serverless アプリケーション
サーバーレスアプリケーションは、ルートと設定で定義され、YAML ファイルに含まれる Kubernetes サービスとして作成およびデプロイされます。OpenShift Serverless を使用してサーバーレスアプリケーションをデプロイするには、Knative Service
オブジェクトを作成する必要があります。
Knative Service
オブジェクトの YAML ファイルの例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello 1 namespace: default 2 spec: template: spec: containers: - image: docker.io/openshift/hello-openshift 3 env: - name: RESPONSE 4 value: "Hello Serverless!"
以下の方法のいずれかを使用してサーバーレスアプリケーションを作成できます。
- OpenShift Container Platform Web コンソールからの Knative サービスの作成Developer パースペクティブを使用したアプリケーションの作成 についてのドキュメントを参照してください。
-
kn
CLI を使用して Knative サービスを作成します。 -
oc
CLI を使用して、KnativeService
オブジェクトを YAML ファイルとして作成し、適用します。
5.1.1. Knative CLI を使用したサーバーレスアプリケーションの作成
サーバーレスアプリケーションを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn service create
コマンドを使えば、kn
CLI を使用して基本的なサーバーレスアプリケーションを作成することができます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
-
kn
CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Knative サービスを作成します。
$ kn service create <service_name> --image <image> --tag <tag-value>
詳細は以下のようになります。
-
--image
は、アプリケーションのイメージの URI です。 --tag
は、サービスで作成された初期リビジョンにタグを追加するために使用できるオプションのフラグです。コマンドの例
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
出力例
Creating service 'event-display' in namespace 'default': 0.271s The Route is still working to reflect the latest desired specification. 0.580s Configuration "event-display" is waiting for a Revision to become ready. 3.857s ... 3.861s Ingress has not yet been reconciled. 4.270s Ready to serve. Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL: http://event-display-default.apps-crc.testing
-
5.1.2. オフラインモードを使用したサービスの作成
オフラインモードで kn service
コマンドを実行すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。記述子ファイルを作成した後、クラスターに変更を伝播する前にファイルを変更することができます。
Knative CLI のオフラインモードはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
-
Knative (
kn
) CLI をインストールしている。
手順
オフラインモードでは、ローカルの Knative サービス記述子ファイルを作成します。
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \ --target ./ \ --namespace test
出力例
Service 'event-display' created in namespace 'test'.
--target ./
フラグはオフラインモードを有効にし、./
を新しいディレクトリーツリーを保存するディレクトリーとして指定します。既存のディレクトリーを指定せずに、
--target my-service.yaml
などのファイル名を使用すると、ディレクトリーツリーは作成されません。代わりに、サービス記述子ファイルmy-service.yaml
のみが現在のディレクトリーに作成されます。ファイル名には、
.yaml
、.yml
または.json
拡張子を使用できます。.json
を選択すると、JSON 形式でサービス記述子ファイルが作成されます。--namespace test
オプションは、新規サービスをテスト
namespace に配置します。--namespace
を使用せずに、OpenShift クラスターにログインしている場合には、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルがdefault
の namespace に作成されます。
作成したディレクトリー構造を確認します。
$ tree ./
出力例
./ └── test └── ksvc └── event-display.yaml 2 directories, 1 file
-
--target
で指定する現在の./
ディレクトリーには新しいtest/
ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。 -
test/
ディレクトリーには、リソースタイプの名前が付けられたksvc
ディレクトリーが含まれます。 -
ksvc
ディレクトリーには、指定のサービス名に従って命名される記述子ファイルevent-display.yaml
が含まれます。
-
生成されたサービス記述子ファイルを確認します。
$ cat test/ksvc/event-display.yaml
出力例
apiVersion: serving.knative.dev/v1 kind: Service metadata: creationTimestamp: null name: event-display namespace: test spec: template: metadata: annotations: client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest creationTimestamp: null spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest name: "" resources: {} status: {}
新しいサービスに関する情報を一覧表示します。
$ kn service describe event-display --target ./ --namespace test
出力例
Name: event-display Namespace: test Age: URL: Revisions: Conditions: OK TYPE AGE REASON
--target ./
オプションは、namespace サブディレクトリーを含むディレクトリー構造のルートディレクトリーを指定します。または、
--target
オプションで YAML または JSON ファイルを直接指定できます。使用可能なファイルの拡張子は、.yaml
、.yml
、および.json
です。--namespace
オプションは、namespace を指定し、この namespace は必要なサービス記述子ファイルを含むサブディレクトリーのkn
と通信します。--namespace
を使用せず、OpenShift クラスターにログインしている場合には、kn
は現在の namespace をもとに名前が付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kn
はdefault/
サブディレクトリーで検索します。
サービス記述子ファイルを使用してクラスターでサービスを作成します。
$ kn service create -f test/ksvc/event-display.yaml
出力例
Creating service 'event-display' in namespace 'test': 0.058s The Route is still working to reflect the latest desired specification. 0.098s ... 0.168s Configuration "event-display" is waiting for a Revision to become ready. 23.377s ... 23.419s Ingress has not yet been reconciled. 23.534s Waiting for load balancer to be ready 23.723s Ready to serve. Service 'event-display' created to latest revision 'event-display-00001' is available at URL: http://event-display-test.apps.example.com
5.1.3. YAML を使用したサーバーレスアプリケーションの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用してサーバーレスアプリケーションを作成するには、Knative Service
を定義する YAML ファイルを作成し、oc apply
を使用してこれを適用する必要があります。
サービスが作成され、アプリケーションがデプロイされると、Knative はこのバージョンのアプリケーションのイミュータブルなリビジョンを作成します。また、Knative はネットワークプログラミングを実行し、アプリケーションのルート、ingress、サービスおよびロードバランサーを作成し、Pod をトラフィックに基づいて自動的にスケールアップ/ダウンします。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc
) をインストールしている。
手順
以下のサンプルコードを含む YAML ファイルを作成します。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: event-delivery namespace: default spec: template: spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest env: - name: RESPONSE value: "Hello Serverless!"
YAML ファイルが含まれるディレクトリーに移動し、YAML ファイルを適用してアプリケーションをデプロイします。
$ oc apply -f <filename>
5.1.4. サーバーレスアプリケーションのデプロイメントの確認
サーバーレスアプリケーションが正常にデプロイされたことを確認するには、Knative によって作成されたアプリケーション URL を取得してから、その URL に要求を送信し、出力を確認する必要があります。OpenShift Serverless は HTTP および HTTPS URL の両方の使用をサポートしますが、oc get ksvc
からの出力は常に http://
形式を使用して URL を出力します。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
-
oc
CLI がインストールされている。 - Knative サービスを作成している。
前提条件
-
OpenShift CLI (
oc
) をインストールします。
手順
アプリケーション URL を検索します。
$ oc get ksvc <service_name>
コマンドの例
$ oc get ksvc event-delivery
出力例
NAME URL LATESTCREATED LATESTREADY READY REASON event-delivery http://event-delivery-default.example.com event-delivery-4wsd2 event-delivery-4wsd2 True
クラスターに対して要求を実行し、出力を確認します。
HTTP 要求の例
$ curl http://event-delivery-default.example.com
HTTPS 要求の例
$ curl https://event-delivery-default.example.com
出力例
Hello Serverless!
オプション:証明書チェーンで自己署名証明書に関連するエラーが発生した場合は、curl コマンドに
--insecure
フラグを追加して、エラーを無視できます。$ curl https://event-delivery-default.example.com --insecure
出力例
Hello Serverless!
重要自己署名証明書は、実稼働デプロイメントでは使用しないでください。この方法は、テスト目的にのみ使用されます。
オプション:OpenShift Container Platform クラスターが認証局 (CA) で署名されているが、システムにグローバルに設定されていない証明書で設定されている場合、
curl
コマンドでこれを指定できます。証明書へのパスは、--cacert
フラグを使用して curl コマンドに渡すことができます。$ curl https://event-delivery-default.example.com --cacert <file>
出力例
Hello Serverless!
5.1.5. HTTP2 および gRPC を使用したサーバーレスアプリケーションとの対話
OpenShift Serverless はセキュアでないルートまたは edge termination ルートのみをサポートします。非セキュアなルートまたは edge termination ルートは OpenShift Container Platform で HTTP2 をサポートしません。gRPC は HTTP2 によって転送されるため、これらのルートは gRPC もサポートしません。アプリケーションでこれらのプロトコルを使用する場合は、Ingress ゲートウェイを使用してアプリケーションを直接呼び出す必要があります。これを実行するには、Ingress ゲートウェイのパブリックアドレスとアプリケーションの特定のホストを見つける必要があります。
この方法は、LoadBalancer
サービスタイプを使用して Kourier Gateway を公開する必要があります。これは、以下の YAML を KnativeServing
カスタムリソース定義(CRD)に追加して設定できます。
... spec: ingress: kourier: service-type: LoadBalancer ...
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
-
OpenShift CLI (
oc
) をインストールしている。 - Knative サービスを作成している。
手順
- アプリケーションホストを検索します。「サーバーレスアプリケーションのデプロイメントの確認」の説明を参照してください。
Ingress ゲートウェイのパブリックアドレスを見つけます。
$ oc -n knative-serving-ingress get svc kourier
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kourier LoadBalancer 172.30.51.103 a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com 80:31380/TCP,443:31390/TCP 67m
パブリックアドレスは
EXTERNAL-IP
フィールドで表示され、この場合はa83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
になります。HTTP 要求のホストヘッダーを手動でアプリケーションのホストに手動で設定しますが、Ingress ゲートウェイのパブリックアドレスに対して要求自体をダイレクトします。
$ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
出力例
Hello Serverless!
Ingress ゲートウェイに対して要求を直接ダイレクトする間に、権限をアプリケーションのホストに設定して gRPC 要求を行うこともできます。
grpc.Dial( "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80", grpc.WithAuthority("hello-default.example.com:80"), grpc.WithInsecure(), )
注記直前の例のように、それぞれのポート (デフォルトでは 80) を両方のホストに追加します。
5.1.6. 制限のあるネットワークポリシーを持つクラスターでの Knative アプリケーションとの通信の有効化
複数のユーザーがアクセスできるクラスターを使用している場合、クラスターはネットワークポリシーを使用してネットワーク経由で相互に通信できる Pod、サービス、および namespace を制御する可能性があります。クラスターで制限的なネットワークポリシーを使用する場合は、Knative システム Pod が Knative アプリケーションにアクセスできない可能性があります。たとえば、namespace に、すべての要求を拒否する以下のネットワークポリシーがある場合、Knative システム Pod は Knative アプリケーションにアクセスできません。
namespace へのすべての要求を拒否する NetworkPolicy オブジェクトの例
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: example-namespace spec: podSelector: ingress: []
Knative システム Pod からアプリケーションへのアクセスを許可するには、ラベルを各 Knative システム namespace に追加し、このラベルを持つ他の namespace の namespace へのアクセスを許可する アプリケーション namespace に NetworkPolicy
オブジェクトを作成する必要があります。
クラスターの非 Knative サービスへの要求を拒否するネットワークポリシーは、これらのサービスへのアクセスを防止するネットワークポリシーです。ただし、Knative システム namespace から Knative アプリケーションへのアクセスを許可することにより、クラスターのすべての namespace から Knative アプリケーションへのアクセスを許可する必要があります。
クラスターのすべての namespace から Knative アプリケーションへのアクセスを許可しない場合は、代わりに Knative サービスの JSON Web Token 認証 を使用するようにしてください。Knative サービスの JSON Web トークン認証にはサービスメッシュが必要です。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。 - OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
手順
アプリケーションへのアクセスを必要とする各 Knative システム namespace に
knative.openshift.io/system-namespace=true
ラベルを追加します。knative-serving
namespace にラベルを付けます。$ oc label namespace knative-serving knative.openshift.io/system-namespace=true
knative-serving-ingress
namespace にラベルを付けます。$ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
knative-eventing namespace
にラベルを付けます。$ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
knative-kafka namespace
にラベルを付けます。$ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
アプリケーション namespace で
NetworkPolicy
オブジェクトを作成し、knative.openshift.io/system-namespace
ラベルのある namespace からのアクセスを許可します。サンプル
NetworkPolicy
オブジェクトapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: <network_policy_name> 1 namespace: <namespace> 2 spec: ingress: - from: - namespaceSelector: matchLabels: knative.openshift.io/system-namespace: "true" podSelector: {} policyTypes: - Ingress
5.1.7. init コンテナーの設定
Init コンテナー は、Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナーです。これらは通常、アプリケーションの初期化ロジックを実装するために使用されます。これには、セットアップスクリプトの実行や、必要な設定のダウンロードが含まれる場合があります。
Init コンテナーを使用すると、アプリケーションの起動時間が長くなる可能性があるため、頻繁にスケールアップおよびスケールダウンすることが予想されるサーバーレスアプリケーションには注意して使用する必要があります。
複数の init コンテナーが単一の Knative サービス仕様でサポートされています。テンプレート名が指定されていない場合、Knative はデフォルトの設定可能な名前付けテンプレートを提供します。初期化コンテナーテンプレートは、Knative Service
オブジェクト仕様に適切な値を追加することで設定できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
-
Knative サービスに init コンテナーを使用する前に、管理者は
kubernetes.podspec-init-containers
フラグをKnativeServing
カスタムリソース (CR) に追加する必要があります。詳細については、OpenShift Serverless のグローバルコンフィギュレーションドキュメントを参照してください。
手順
initContainers
仕様をKnativeService
オブジェクトに追加します。サービス仕様の例
apiVersion: serving.knative.dev/v1 kind: Service ... spec: template: spec: initContainers: - imagePullPolicy: IfNotPresent 1 image: <image_uri> 2 volumeMounts: 3 - name: data mountPath: /data ...
- 1
- イメージのダウンロード時の イメージプルポリシー。
- 2
- init コンテナーイメージの URI。
- 3
- コンテナーファイルシステム内でボリュームがマウントされる場所。
5.1.8. サービスごとの HTTPS リダイレクト
networking.knative.dev/http-option
アノテーションを設定することにより、サービスの HTTPS リダイレクトを有効または無効にできます。次の例は、Knative Service
YAML オブジェクトでこのアノテーションを使用する方法を示しています。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example namespace: default annotations: networking.knative.dev/http-option: "redirected" spec: ...
5.1.9. 関連情報
5.2. 自動スケーリング
Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング(autoscaling)を提供します。たとえば、アプリケーションがトラフィックを受信せず、scale-to-zeroが有効にされている場合、Knative Serving はアプリケーションをゼロレプリカにスケールダウンします。scale-to-zero が無効になっている場合、アプリケーションはクラスターのアプリケーションに設定された最小のレプリカ数にスケールダウンされます。アプリケーションへのトラフィックが増加したら、要求を満たすようにレプリカをスケールアップすることもできます。
Knative サービスの自動スケーリング設定は、クラスター管理者によって設定されるグローバル設定とすることも、個別サービスに設定されるリビジョンごとの設定とすることもできます。OpenShift Container Platform Web コンソールを使用して、サービスの YAML ファイルを変更するか、または kn
CLI を使用して、サービスのリビジョンごとの設定を変更できます。
サービスに設定した制限またはターゲットは、アプリケーションの単一インスタンスに対して測定されます。たとえば、target
アノテーションを 50
に設定することにより、各リビジョンが一度に 50 の要求を処理できるようアプリケーションをスケーリングするように Autoscaler が設定されます。
5.2.1. スケーリング限度
スケーリング限度は、任意の時点でアプリケーションに対応できる最小および最大のレプリカ数を決定します。アプリケーションのスケーリング限度を設定して、コールドスタートを防止したり、コンピューティングコストを制御したりできます。
5.2.1.1. スケーリング下限
アプリケーションにサービスを提供できるレプリカの最小数は、最小 min-scale
のアノテーションによって決定されます。ゼロへのスケーリングが有効になっていない場合、min-Scale
値のデフォルトは1
になります。
次の条件が満たされた場合、min-scale
値はデフォルトで 0
レプリカになります。
-
mi-scale
の注釈が設定されていません - ゼロへのスケーリングが有効にされている
-
KPA
クラスが使用されている
min-scale
アノテーションを使用したサービス仕様の例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/min-scale: "0" ...
5.2.1.1.1. Knative CLI を使用した最小スケール注釈の設定
minScale
アノテーションを設定するために Knative (kn
) CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが提供されます。kn service
コマンドを --scale-min
フラグと共に使用して、サービスの --min-scale
値を作成または変更できます。
前提条件
- Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
--scale-min
フラグを使用して、サービスのレプリカの最小数を設定します。$ kn service create <service_name> --image <image_uri> --scale-min <integer>
コマンドの例
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-min 2
5.2.1.2. スケーリング上限
アプリケーションにサービスを提供できるレプリカの最大数は、max-scale
アノテーションによって決定されます。max-scale
アノテーションが設定されていない場合、作成されるレプリカの数に上限はありません。
max-scale
アノテーションを使用したサービス仕様の例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/max-scale: "10" ...
5.2.1.2.1. Knative CLI を使用した最大スケール注釈の設定
Knative (kn
) CLI を使用して max-scale
の注釈を設定すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。--scale-max
フラグを指定して knservice コマンドを使用すると、kn service
の max-scale
値を作成または変更できます。
前提条件
- Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
--scale-max
フラグを使用して、サービスのレプリカの最大数を設定します。$ kn service create <service_name> --image <image_uri> --scale-max <integer>
コマンドの例
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-max 10
5.2.2. 並行処理性
並行処理性は、特定の時点でアプリケーションの各レプリカが処理できる同時リクエストの数を決定します。並行処理性は、ソフトリミットまたはハードリミットのいずれかとして設定できます。
- ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。
ハードリミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。
重要ハードリミット設定の使用は、アプリケーションに明確なユースケースがある場合にのみ推奨されます。ハードリミットを低い値に指定すると、アプリケーションのスループットとレイテンシーに悪影響を与える可能性があり、コールドスタートが発生する可能性があります。
ソフトターゲットとハードリミットを追加することは、Autoscaler は同時リクエストのソフトターゲット数を目標とするが、リクエストの最大数にハードリミット値のハードリミットを課すことを意味します。
ハードリミットの値がソフトリミットの値より小さい場合、実際に処理できる数よりも多くのリクエストを目標にする必要がないため、ソフトリミットの値が低減されます。
5.2.2.1. ソフト並行処理ターゲットの設定
ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。autoscaling.knative.dev/target
アノテーションを仕様に設定するか、または正しいフラグを指定して kn service
コマンドを使用して、Knative サービスにソフト並行処理ターゲットを指定できます。
手順
オプション:
Service
カスタムリソースの仕様で Knative サービスにautoscaling.knative.dev/target
アノテーションを設定します。サービス仕様の例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/target: "200"
オプション:
kn service
コマンドを使用して--concurrency-target
フラグを指定します。$ kn service create <service_name> --image <image_uri> --concurrency-target <integer>
並行処理のターゲットを 50 リクエストに設定したサービスを作成するコマンドの例
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50
5.2.2.2. ハード並行処理リミットの設定
ハード並行処理リミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。containerConcurrency
仕様を変更するか、または正しいフラグを指定して kn service
コマンドを使用して、Knative サービスにハード並行処理リミットを指定できます。
手順
オプション:
Service
カスタムリソースの仕様で Knative サービスにcontainerConcurrency
仕様を設定します。サービス仕様の例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: spec: containerConcurrency: 50
デフォルト値は
0
です。これは、サービスの 1 つのレプリカに一度に流れることができる同時リクエストの数に制限がないことを意味します。0
より大きい値は、サービスの 1 つのレプリカに一度に流れることができるリクエストの正確な数を指定します。この例では、50 リクエストのハード並行処理リミットを有効にします。オプション:
kn service
コマンドを使用して--concurrency-limit
フラグを指定します。$ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>
並行処理のリミットを 50 リクエストに設定したサービスを作成するコマンドの例
$ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50
5.2.2.3. 並行処理ターゲットの使用率
この値は、Autoscaler が実際に目標とする並行処理リミットのパーセンテージを指定します。これは、レプリカが実行する ホット度 を指定することとも呼ばれます。これにより、Autoscaler は定義されたハードリミットに達する前にスケールアップできるようになります。
たとえば、containerConcurrency
値が 10 に設定され、target-utilization-percentage
値が 70% に設定されている場合、既存のすべてのレプリカの同時リクエストの平均数が 7 に達すると、オートスケーラーは新しいレプリカを作成します。7 から 10 の番号が付けられたリクエストは引き続き既存のレプリカに送信されますが、containerConcurrency
値に達した後、必要になることを見越して追加のレプリカが開始されます。
target-utilization-percentage アノテーションを使用して設定されたサービスの例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/target-utilization-percentage: "70" ...
5.3. トラフィック管理
Knative アプリケーションでは、トラフィック分割を作成することでトラフィックを管理できます。トラフィック分割は、Knative サービスによって管理されるルートの一部として設定されます。

ルートを設定すると、サービスのさまざまなリビジョンにリクエストを送信できます。このルーティングは、Service
オブジェクトの traffic
仕様によって決定されます。
traffic
仕様宣言は、1 つ以上のリビジョンで設定され、それぞれがトラフィック全体の一部を処理する責任があります。各リビジョンにルーティングされるトラフィックの割合は、合計で 100% になる必要があります。これは、Knative 検証によって保証されます。
traffic
仕様で指定されたリビジョンは、固定の名前付きリビジョンにすることも、サービスのすべてのリビジョンのリストの先頭を追跡する最新のリビジョンを指すこともできます。最新のリビジョンは、新しいリビジョンが作成された場合に更新される一種のフローティング参照です。各リビジョンには、そのリビジョンの追加のアクセス URL を作成するタグを付けることができます。
traffic
仕様は次の方法で変更できます。
-
Service
オブジェクトの YAML を直接編集します。 -
kn
CLI の--traffic
フラグ を使用します。 - OpenShift Container Platform コンソールの使用。
Knative サービスの作成時に、デフォルトの traffic
仕様設定は含まれません。
5.3.1. トラフィックスペックの例
以下の例は、トラフィックの 100% がサービスの最新リビジョンにルーティングされる traffic
仕様を示しています。status
では、latestRevision
が解決する最新リビジョンの名前を確認できます。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: ... traffic: - latestRevision: true percent: 100 status: ... traffic: - percent: 100 revisionName: example-service
以下の例は、トラフィックの 100% が current
としてタグ付けされたリビジョンにルーティングされ、そのリビジョンの名前が example-service
として指定される traffic
仕様を示しています。latest
とタグ付けされたリビジョンは、トラフィックが宛先にルーティングされない場合でも、利用可能な状態になります。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: ... traffic: - tag: current revisionName: example-service percent: 100 - tag: latest latestRevision: true percent: 0
以下の例は、トラフィックが複数のリビジョン間で分割されるように、traffic
仕様のリビジョンの一覧を拡張する方法を示しています。この例では、トラフィックの 50% を、current
としてタグ付けされたリビジョンに送信します。また、candidate
としてタグ付けされたリビジョンにトラフィックの 50% を送信します。latest
とタグ付けされたリビジョンは、トラフィックが宛先にルーティングされない場合でも、利用可能な状態になります。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: ... traffic: - tag: current revisionName: example-service-1 percent: 50 - tag: candidate revisionName: example-service-2 percent: 50 - tag: latest latestRevision: true percent: 0
5.3.2. Knative CLI トラフィック管理フラグ
kn
CLI は kn service update
コマンドの一環として、サービスのトラフィックブロックでのトラフィック操作をサポートします。
以下の表は、トラフィック分割フラグ、値の形式、およびフラグが実行する操作の概要を表示しています。Repetition 列は、フラグの特定の値が kn service update
コマンドで許可されるかどうかを示します。
フラグ | 値 | 操作 | 繰り返し |
---|---|---|---|
|
|
| はい |
|
|
| はい |
|
|
| いいえ |
|
|
| はい |
|
|
| いいえ |
|
|
リビジョンから | はい |
5.3.2.1. 複数のフラグおよび順序の優先順位
すべてのトラフィック関連のフラグは、単一の kn service update
コマンドを使用して指定できます。kn
は、これらのフラグの優先順位を定義します。コマンドの使用時に指定されるフラグの順番は考慮に入れられません。
kn
で評価されるフラグの優先順位は以下のとおりです。
-
--untag
: このフラグで参照されるすべてのリビジョンはトラフィックブロックから削除されます。 -
--tag
: リビジョンはトラフィックブロックで指定されるようにタグ付けされます。 -
--traffic
: 参照されるリビジョンには、分割されたトラフィックの一部が割り当てられます。
タグをリビジョンに追加してから、設定したタグに応じてトラフィックを分割することができます。
5.3.2.2. リビジョンのカスタム URL
kn service update
コマンドを使用して --tag
フラグをサービスに割り当てると、サービスの更新時に作成されるリビジョンのカスタム URL が作成されます。カスタム URL は、https://<tag>-<service_name>-<namespace>.<domain>;
パターンまたは http://<tag>-<service_name>-<namespace>.<domain>;
パターンに従います。
--tag
フラグおよび --untag
フラグは以下の構文を使用します。
- 1 つの値が必要です。
- サービスのトラフィックブロックに一意のタグを示します。
- 1 つのコマンドで複数回指定できます。
5.3.2.2.1. 例: リビジョンへのタグの割り当て
以下の例では、タグ latest
を、example-revision
という名前のリビジョンに割り当てます。
$ kn service update <service_name> --tag @latest=example-tag
5.3.2.2.2. 例: リビジョンからのタグの削除
--untag
フラグを使用して、カスタム URL を削除するタグを削除できます。
リビジョンのタグが削除され、トラフィックの 0% が割り当てられる場合、リビジョンはトラフィックブロックから完全に削除されます。
以下のコマンドは、example-revision
という名前のリビジョンからすべてのタグを削除します。
$ kn service update <service_name> --untag example-tag
5.3.3. KnativeCLI を使用してトラフィック分割を作成する
kn
CLI を使用してトラフィック分割を作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。kn service update
コマンドを使用して、サービスのリビジョン間でトラフィックを分割できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
kn
CLI がインストールされている。 - Knative サービスを作成している。
手順
標準の
kn service update
コマンドで--traffic
タグを使用して、サービスのリビジョンとそれにルーティングするトラフィックの割合を指定します。コマンドの例
$ kn service update <service_name> --traffic <revision>=<percentage>
詳細は以下のようになります。
-
<service_name>
は、トラフィックルーティングを設定する Knative サービスの名前です。 -
<revision>
は、一定の割合のトラフィックを受信するように構成するリビジョンです。リビジョンの名前、または--tag
フラグを使用してリビジョンに割り当てたタグのいずれかを指定できます。 -
<percentage>
は、指定されたリビジョンに送信するトラフィックのパーセンテージです。
-
オプション:
--traffic
フラグは、1 つのコマンドで複数回指定できます。たとえば、@latest
というタグの付いたリビジョンとstable
という名前のリビジョンがある場合、次のように各リビジョンに分割するトラフィックの割合を指定できます。コマンドの例
$ kn service update example-service --traffic @latest=20,stable=80
複数のリビジョンがあり、最後のリビジョンに分割する必要があるトラフィックの割合を指定しない場合、
-traffic
フラグはこれを自動的に計算できます。たとえば、example
という名前の 3 番目のリビジョンがあり、次のコマンドを使用する場合:コマンドの例
$ kn service update example-service --traffic @latest=10,stable=60
トラフィックの残りの 30% は、指定されていなくても、
example
リビジョンに分割されます。
5.3.4. OpenShift Container Platform Web コンソールを使用したリビジョン間のトラフィックの管理
サーバーレスアプリケーションの作成後、アプリケーションは OpenShift Container Platform Web コンソールの Developer パースペクティブの Topology ビューに表示されます。アプリケーションのリビジョンはノードによって表され、Knative サービスはノードの周りの四角形のマークが付けられます。
コードまたはサービス設定の新たな変更により、特定のタイミングでコードのスナップショットである新規リビジョンが作成されます。サービスの場合、必要に応じてこれを分割し、異なるリビジョンにルーティングして、サービスのリビジョン間のトラフィックを管理することができます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- OpenShift Container Platform Web コンソールにログインしている。
手順
Topology ビューでアプリケーションの複数のリビジョン間でトラフィックを分割するには、以下を行います。
- Knative サービスをクリックし、サイドパネルの概要を表示します。
Resources タブをクリックして、サービスの Revisions および Routes の一覧を表示します。
図5.1 Serverless アプリケーション
- サイドパネルの上部にある S アイコンで示されるサービスをクリックし、サービスの詳細の概要を確認します。
-
YAML タブをクリックし、YAML エディターでサービス設定を変更し、Save をクリックします。たとえば、
timeoutseconds
を 300 から 301 に変更します。この設定の変更により、新規リビジョンがトリガーされます。Topology ビューでは、最新のリビジョンが表示され、サービスの Resources タブに 2 つのリビジョンが表示されるようになります。 Resources タブで Set Traffic Distribution をクリックして、トラフィック分配ダイアログボックスを表示します。
- Splits フィールドに、2 つのリビジョンのそれぞれの分割されたトラフィックパーセンテージを追加します。
- 2 つのリビジョンのカスタム URL を作成するタグを追加します。
Save をクリックし、Topology ビューで 2 つのリビジョンを表す 2 つのノードを表示します。
図5.2 Serverless アプリケーションのリビジョン
5.3.5. blue-green デプロイメントストラテジーを使用したトラフィックのルーティングおよび管理
Blue-green デプロイメントストラテジー を使用して、実稼働バージョンのアプリケーションから新規バージョンにトラフィックを安全に再ルーティングすることができます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
OpenShift CLI (
oc
) をインストールしている。
手順
- アプリケーションを Knative サービスとして作成し、デプロイします。
以下のコマンドから出力を表示して、サービスのデプロイ時に作成された最初のリビジョンの名前を検索します。
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
コマンドの例
$ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'
出力例
$ example-service-00001
以下の YAML をサービスの
spec
に追加して、受信トラフィックをリビジョンに送信します。... spec: traffic: - revisionName: <first_revision_name> percent: 100 # All traffic goes to this revision ...
以下のコマンドを実行して、URL の出力でアプリケーションを表示できることを確認します。
$ oc get ksvc <service_name>
-
サービスの
template
仕様の少なくとも 1 つのフィールドを変更してアプリケーションの 2 番目のリビジョンをデプロイし、これを再デプロイします。たとえば、サービスのimage
やenv
環境変数を変更できます。サービス YAML ファイルを適用 (kn
CLI がインストールされている場合はkn service update
コマンドを使用) してサービスを再デプロイできます。 以下のコマンドを実行して、サービスを再デプロイする際に作成された 2 番目の最新のリビジョンの名前を見つけます。
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
この時点で、サービスの最初のバージョンと 2 番目のリビジョンの両方がデプロイされ、実行されます。
既存のサービスを更新して、2 番目のリビジョンの新規テストエンドポイントを作成し、他のすべてのトラフィックを最初のリビジョンに送信します。
テストエンドポイントのある更新されたサービス仕様の例
... spec: traffic: - revisionName: <first_revision_name> percent: 100 # All traffic is still being routed to the first revision - revisionName: <second_revision_name> percent: 0 # No traffic is routed to the second revision tag: v2 # A named route ...
YAML リソースを再適用してこのサービスを再デプロイすると、アプリケーションの 2 番目のリビジョンがステージングされます。トラフィックはメインの URL の 2 番目のリビジョンにルーティングされず、Knative は新たにデプロイされたリビジョンをテストするために
v2
という名前の新規サービスを作成します。以下のコマンドを実行して、2 番目のリビジョンの新規サービスの URL を取得します。
$ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"
この URL を使用して、トラフィックをルーティングする前に、新しいバージョンのアプリケーションが予想通りに機能していることを検証できます。
既存のサービスを再度更新して、トラフィックの 50% が最初のリビジョンに送信され、50% が 2 番目のリビジョンに送信されます。
リビジョン間でトラフィックを 50/50 に分割する更新サービス仕様の例
... spec: traffic: - revisionName: <first_revision_name> percent: 50 - revisionName: <second_revision_name> percent: 50 tag: v2 ...
すべてのトラフィックを新しいバージョンのアプリケーションにルーティングできる状態になったら、再度サービスを更新して、100% のトラフィックを 2 番目のリビジョンに送信します。
すべてのトラフィックを 2 番目のリビジョンに送信する更新済みのサービス仕様の例
... spec: traffic: - revisionName: <first_revision_name> percent: 0 - revisionName: <second_revision_name> percent: 100 tag: v2 ...
ヒントリビジョンのロールバックを計画しない場合は、これを 0% に設定する代わりに最初のリビジョンを削除できます。その後、ルーティング不可能なリビジョンオブジェクトにはガベージコレクションが行われます。
- 最初のリビジョンの URL にアクセスして、アプリケーションの古いバージョンに送信されていないことを確認します。
5.4. Routing
Knative は OpenShift Container Platform TLS 終端を使用して Knative サービスのルーティングを提供します。Knative サービスが作成されると、OpenShift Container Platform ルートがサービス用に自動的に作成されます。このルートは OpenShift Serverless Operator によって管理されます。OpenShift Container Platform ルートは、OpenShift Container Platform クラスターと同じドメインで Knative サービスを公開します。
OpenShift Container Platform ルーティングの Operator 制御を無効にすることで、Knative ルートを TLS 証明書を直接使用するように設定できます。
Knative ルートは OpenShift Container Platform ルートと共に使用し、トラフィック分割などの詳細なルーティング機能を提供します。
5.4.1. OpenShift Container Platform ルートのラベルおよびアノテーションのカスタマイズ
OpenShift Container Platform ルートは、Knative サービスの metadata
仕様を変更して設定できるカスタムラベルおよびアノテーションの使用をサポートします。カスタムラベルおよびアノテーションはサービスから Knative ルートに伝番され、次に Knative ingress に、最後に OpenShift Container Platform ルートに伝播されます。
前提条件
- OpenShift Serverless Operator および Knative Serving が OpenShift Container Platform クラスターにインストールされている必要があります。
-
OpenShift CLI (
oc
) をインストールしている。
手順
OpenShift Container Platform ルートに伝播するラベルまたはアノテーションが含まれる Knative サービスを作成します。
YAML を使用してサービスを作成するには、以下を実行します。
YAML を使用して作成されるサービスの例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <service_name> labels: <label_name>: <label_value> annotations: <annotation_name>: <annotation_value> ...
kn
CLI を使用してサービスを作成するには、以下を実行します。kn
コマンドを使用して作成されるサービスの例$ kn service create <service_name> \ --image=<image> \ --annotation <annotation_name>=<annotation_value> \ --label <label_value>=<label_value>
以下のコマンドからの出力を検査して、OpenShift Container Platform ルートが追加したアノテーションまたはラベルで作成されていることを確認します。
検証のコマンドの例
$ oc get routes.route.openshift.io \ -l serving.knative.openshift.io/ingressName=<service_name> \ 1 -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ 2 -n knative-serving-ingress -o yaml \ | grep -e "<label_name>: \"<label_value>\"" -e "<annotation_name>: <annotation_value>" 3
5.4.2. OpenShift Container Platform ルートでの Knative サービスの設定
Knative サービスを OpenShift Container Platform で TLS 証明書を使用するように設定するには、OpenShift Serverless Operator によるサービスのルートの自動作成を無効にし、代わりにサービスのルートを手動で作成する必要があります。
以下の手順を完了すると、knative-serving-ingress
namespace のデフォルトの OpenShift Container Platform ルートは作成されません。ただし、アプリケーションの Knative ルートはこの namespace に引き続き作成されます。
前提条件
- OpenShift Serverless Operator および Knative Serving コンポーネントが OpenShift Container Platform クラスターにインストールされている。
-
OpenShift CLI (
oc
) をインストールしている。
手順
serving.knative.openshift.io/disableRoute=true
アノテーションが含まれる Knative サービスを作成します。重要serving.knative.openshift.io/disableRoute=true
アノテーションは、OpenShift Serverless に対してルートを自動的に作成しないように指示します。ただし、サービスには URL が表示され、ステータスがReady
に達します。URL のホスト名と同じホスト名を使用して独自のルートを作成するまで、この URL は外部では機能しません。Service
サービスリソースを作成します。リソースの例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <service_name> annotations: serving.knative.openshift.io/disableRoute: "true" spec: template: spec: containers: - image: <image> ...
Service
リソースを適用します。$ oc apply -f <filename>
オプション:
kn service create
コマンドを使用して Knative サービスを作成します。kn
コマンドの例$ kn service create <service_name> \ --image=gcr.io/knative-samples/helloworld-go \ --annotation serving.knative.openshift.io/disableRoute=true
サービス用に OpenShift Container Platform ルートが作成されていないことを確認します。
コマンドの例
$ $ oc get routes.route.openshift.io \ -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \ -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \ -n knative-serving-ingress
以下の出力が表示されるはずです。
No resources found in knative-serving-ingress namespace.
knative-serving-ingress
namespace でRoute
リソースを作成します。apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/timeout: 600s 1 name: <route_name> 2 namespace: knative-serving-ingress 3 spec: host: <service_host> 4 port: targetPort: http2 to: kind: Service name: kourier weight: 100 tls: insecureEdgeTerminationPolicy: Allow termination: edge 5 key: |- -----BEGIN PRIVATE KEY----- [...] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE---- wildcardPolicy: None
- 1
- OpenShift Container Platform ルートのタイムアウト値。
max-revision-timeout-seconds
設定と同じ値を設定する必要があります(デフォルトでは600s
)。 - 2
- OpenShift Container Platform ルートの名前。
- 3
- OpenShift Container Platform ルートの namespace。これは
knative-serving-ingress
である必要があります。 - 4
- 外部アクセスのホスト名。これを
<service_name>-<service_namespace>.<domain>
に設定できます。 - 5
- 使用する証明書。現時点で、
edge
termination のみがサポートされています。
Route
リソースを適用します。$ oc apply -f <filename>
5.4.3. クラスターローカルへのクラスター可用性の設定
デフォルトで、Knative サービスはパブリック IP アドレスに公開されます。パブリック IP アドレスに公開されているとは、Knative サービスがパブリックアプリケーションであり、一般にアクセス可能な URL があることを意味します。
一般にアクセス可能な URL は、クラスター外からアクセスできます。ただし、開発者は プライベートサービス と呼ばれるクラスター内からのみアクセス可能なバックエンドサービスをビルドする必要がある場合があります。開発者は、クラスター内の個々のサービスに networking.knative.dev/visibility=cluster-local
ラベルを使用してラベル付けし、それらをプライベートにすることができます。
OpenShift Serverless 1.15.0 以降のバージョンの場合には、serving.knative.dev/visibility
ラベルは利用できなくなりました。既存のサービスを更新して、代わりに networking.knative.dev/visibility
ラベルを使用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- Knative サービスを作成している。
手順
networking.knative.dev/visibility=cluster-local
ラベルを追加して、サービスの可視性を設定します。$ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local
検証
以下のコマンドを入力して出力を確認し、サービスの URL の形式が
http://<service_name>.<namespace>.svc.cluster.local
であることを確認します。$ oc get ksvc
出力例
NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello.default.svc.cluster.local hello-tx2g7 hello-tx2g7 True
5.4.4. 関連情報
5.5. イベントシンク
イベントソースの作成時に、イベントがソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能なリソースです。Knative サービス、チャネル、およびブローカーはすべてシンクのサンプルです。
アドレス指定可能なオブジェクトは、HTTP 経由で status.address.url
フィールドに定義されるアドレスに配信されるイベントを受信し、確認することができます。特別な場合として、コア Kubernetes Service
オブジェクトはアドレス指定可能なインターフェースにも対応します。
呼び出し可能なオブジェクトは、HTTP 経由で配信されるイベントを受信し、そのイベントを変換できます。HTTP 応答で 0
または 1
の新規イベントを返します。返されるイベントは、外部イベントソースからのイベントが処理されるのと同じ方法で処理できます。
5.5.1. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel
およびbroker
が含まれます。
kn
のカスタマイズ により、どの CR が kn
CLI コマンドの --sink
フラグと併用できるかを設定できます。
5.5.2. Developer パースペクティブを使用してイベントソースをシンクに接続します。
OpenShift Container Platform Web コンソールを使用してイベントソースを作成する場合、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Developer パースペクティブを使用している。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Knative サービス、チャネル、ブローカーなどのシンクを作成している。
手順
- +Add → Event Sources に移動して任意のタイプのイベントソースを作成し、作成するイベントソースを選択します。
- Create Event Source フォームビューの Sink セクションで、Resource 一覧でシンクを選択します。
- 作成 をクリックします。
検証
Topology ページを表示して、イベントソースが作成され、シンクに接続されていることを確認できます。Developer パースペクティブで、Topology に移動します。
- イベントソースを表示し、接続されたシンクをクリックし、サイドパネルでシンクの詳細を表示します。
5.5.3. トリガーのシンクへの接続
トリガーをシンクに接続して、シンクへの送信前にブローカーからのイベントがフィルターされるようにします。トリガーに接続されているシンクは、Trigger
オブジェクトのリソース仕様で subscriber
として設定されます。
Kafka シンクに接続された Trigger
オブジェクトの例
apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: <trigger_name> 1 spec: ... subscriber: ref: apiVersion: eventing.knative.dev/v1alpha1 kind: KafkaSink name: <kafka_sink_name> 2
5.6. イベント配信
サブスクライバーへのサブスクリプション または トリガーで配信されるイベントに失敗した場合に適用される Knative Eventing のイベント配信パラメーターを設定できます。イベント配信パラメーターは、サブスクライバーごとに個別に設定されます。
5.6.1. Knative Eventing チャネルのイベント配信動作
Knative Eventing チャネルタイプのイベント配信に使用される動作パターンはそれぞれ異なります。開発者は、サブスクリプション設定でイベント配信パラメーターを設定して、チャネルからイベントシンクに配信できないイベントが再試行されるようにできます。また、最終的に配信されないイベントを保存できるシンクを提供する必要がある場合は、サブスクリプションの dead letter sink も設定する必要があります。これを設定しないと、配信されないイベントはドロップされます。
5.6.1.1. Knative Kafka チャネルのイベント配信動作
イベントが Kafka チャネルまたはブローカーレシーバーに正常に配信される場合、受信側は 202
ステータスコードで応答します。つまり、このイベントは Kafka トピック内に安全に保存され、失われることはありません。受信側がその他のステータスコードを返す場合は、イベントは安全に保存されず、ユーザーがこの問題を解決するために手順を実行する必要があります。
5.6.1.2. 配信失敗ステータスコード
チャネルまたはブローカーの受信側は、イベントが配信に失敗した場合に以下のステータスコードで応答する場合があります。
500
- これは一般的なステータスコードで、イベントが正常に配信されなかったことを意味します。
404
-
このステータスコードは、イベントが配信されるチャネルまたはブローカーが存在しないか、または
Host
ヘッダーが正しくないことを意味します。 400
- このステータスコードは、受信側に送信されるイベントが無効であることを意味します。
5.6.2. 設定可能なイベント配信パラメーター
Knative Eventing は、イベントの配信に失敗した場合にイベントに何が起こるかを制御するために使用できる設定パラメーターを提供します。たとえば、消費に失敗したイベントの送信を再試行するように Knative を設定したり、これらのイベントを dead letter sink に転送したりできます。
以下のパラメーターはイベント配信用に設定できます。
- dead letter sink
-
deadLetterSink
配信パラメーターを設定して、イベントが配信に失敗した場合にこれを指定されたイベントシンクに送信することができます。 - retries
-
retry
配信パラメーターを整数値で設定することで、イベントが dead letter sink に送信される前に配信を再試行する必要のある最小回数を設定できます。 - back off delay
-
backoffDelay
配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelay
パラメーターの期間は ISO 8601 形式を使用して指定されます。 - back off policy
-
backoffPolicy
配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーはlinear
またはexponential
のいずれかとして指定できます。linear
バックオフポリシーを使用する場合、バックオフの遅延は再試行間に指定される期間になります。exponential
バックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay*2^<numberOfRetries>
と等しくなります。
5.6.3. サブスクリプションを使用したイベント配信失敗パラメーターの設定
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。Subscription
オブジェクトの delivery
設定を変更して、個別のサブスクリプションのイベント配信パラメーターを設定できます。Knative Eventing は、イベントの配信に失敗した場合にイベントに何が起こるかを制御するために使用できるサブスクリプションの設定パラメーターを提供します。
Subscription
オブジェクトの例
apiVersion: messaging.knative.dev/v1 kind: Subscription metadata: name: <subscription_name> namespace: <subscription_namespace> spec: delivery: deadLetterSink: 1 ref: apiVersion: serving.knative.dev/v1 kind: Service name: <sink_name> backoffDelay: <duration> 2 backoffPolicy: <policy_type> 3 retry: <integer> 4
- 1
- dead letter sink の使用を有効にするための設定内容これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。
これが設定されると、配信できないイベントが dead letter sink の宛先に送信されます。宛先は Knative サービスまたは URI にすることができます。
- 2
backoffDelay
配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelay
パラメーターの期間は ISO 8601 形式を使用して指定されます。たとえば、PT1S
は 1 秒の遅延を指定します。- 3
backoffPolicy
配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーはlinear
またはexponential
のいずれかとして指定できます。linear
バックオフポリシーを使用する場合、バックオフの遅延は再試行間に指定される期間になります。exponential
バックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay*2^<numberOfRetries>
と等しくなります。- 4
- イベントが dead letter sink に送信される前にイベント配信を再試行する回数。
5.7. イベントソースおよびイベントソースタイプの一覧表示
OpenShift Container Platform クラスターに存在する、または使用可能なすべてのイベントソースやイベントソースタイプのリストを表示することができます。OpenShift Container Platform Web コンソールの kn
CLI または Developer パースペクティブを使用し、利用可能なイベントソースまたはイベントソースタイプを一覧表示できます。
5.7.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示
kn
CLI を使用すると、クラスターで使用可能なイベントソースタイプを表示するための合理的で直感的なユーザーインターフェースが提供されます。kn source list-types
CLI コマンドを使用して、クラスターで作成して使用できるイベントソースタイプを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
ターミナルに利用可能なイベントソースタイプを一覧表示します。
$ kn source list-types
出力例
TYPE NAME DESCRIPTION ApiServerSource apiserversources.sources.knative.dev Watch and send Kubernetes API events to a sink PingSource pingsources.sources.knative.dev Periodically send ping events to a sink SinkBinding sinkbindings.sources.knative.dev Binding for connecting a PodSpecable to a sink
オプション: 利用可能なイベントソースタイプを YAML 形式で一覧表示することもできます。
$ kn source list-types -o yaml
5.7.2. Developer パースペクティブ内での利用可能なイベントソースタイプの表示
クラスターで使用可能なすべてのイベントソースタイプを一覧表示することができます。OpenShift Container Platform Web コンソールを使用すると、使用可能なイベントソースタイプを表示するための合理的で直感的なユーザーインターフェースが提供されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
- Developer パースペクティブにアクセスします。
- +Add をクリックします。
- Event source をクリックします。
- 利用可能なイベントソースタイプを表示します。
5.7.3. Knative CLI の使用による利用可能なイベントリソースの一覧表示
kn
CLI を使用すると、クラスターの既存イベントソースを表示するための合理的で直感的なユーザーインターフェースが提供されます。kn source list
コマンドを使用して、既存のイベントソースを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
ターミナルにある既存のイベントソースを一覧表示します。
$ kn source list
出力例
NAME TYPE RESOURCE SINK READY a1 ApiServerSource apiserversources.sources.knative.dev ksvc:eshow2 True b1 SinkBinding sinkbindings.sources.knative.dev ksvc:eshow3 False p1 PingSource pingsources.sources.knative.dev ksvc:eshow1 True
オプションで、
--type
フラグを使用して、特定タイプのイベントソースのみを一覧表示できます。$ kn source list --type <event_source_type>
コマンドの例
$ kn source list --type PingSource
出力例
NAME TYPE RESOURCE SINK READY p1 PingSource pingsources.sources.knative.dev ksvc:eshow1 True
5.8. API サーバーソースの作成
API サーバーソースは、Knative サービスなどのイベントシンクを Kubernetes API サーバーに接続するために使用できるイベントソースです。API サーバーソースは Kubernetes イベントを監視し、それらを Knative Eventing ブローカーに転送します。
5.8.1. Web コンソールを使用した API サーバーソースの作成
Knative Eventing がクラスターにインストールされると、Web コンソールを使用して API サーバーソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc
) CLI がインストールされている。
手順
- Add ページに移動し、Event Source を選択します。
- Event Sources ページで、Type セクションで ApiServerSource を選択します。
ApiServerSource を設定します。
-
APIVERSION に
v1
を、KIND にEvent
を入力します。 - 作成したサービスアカウントの Service Account Name を選択します。
- イベントソースの Sink を選択します。Sink は、チャネル、ブローカー、またはサービスなどの Resource、または URI のいずれかになります。
-
APIVERSION に
- Create をクリックします。
検証
API サーバーソースの作成後、これが Topology ビューでシンクされるサービスに接続されていることを確認できます。
URI シンクが使用される場合、URI sink → Edit URI を右クリックして URI を変更します。
API サーバーソースの削除
- Topology ビューに移動します。
API サーバーソースを右クリックし、Delete ApiServerSource を選択します。
5.8.2. Knative CLI を使用した API サーバーソースの作成
kn source apiserver create
コマンドを使用し、kn
CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc
) CLI がインストールされている。 -
Knative (
kn
) CLI をインストールしている。
既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount
リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: events-sa namespace: default 1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: event-watcher namespace: default 2 rules: - apiGroups: - "" resources: - events verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k8s-ra-event-watcher namespace: default 3 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: event-watcher subjects: - kind: ServiceAccount name: events-sa namespace: default 4
YAML ファイルを適用します。
$ oc apply -f <filename>
イベントシンクを持つ API サーバーソースを作成します。次の例では、シンクはブローカーです。
$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。
$ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、
default
のブローカーからサービスへのイベントをフィルタリングします。$ kn trigger create <trigger_name> --sink ksvc:<service_name>
デフォルト namespace で Pod を起動してイベントを作成します。
$ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。
$ kn source apiserver describe <source_name>
出力例
Name: mysource Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 3m ServiceAccountName: events-sa Mode: Resource Sink: Name: default Namespace: default Kind: Broker (eventing.knative.dev/v1) Resources: Kind: event (v1) Controller: false Conditions: OK TYPE AGE REASON ++ Ready 3m ++ Deployed 3m ++ SinkProvided 3m ++ SufficientPermissions 3m ++ EventTypesProvided 3m
検証
メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative に送信されていることを確認できます。
Pod を取得します。
$ oc get pods
Pod のメッセージダンパー機能ログを表示します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.apiserver.resource.update datacontenttype: application/json ... Data, { "apiVersion": "v1", "involvedObject": { "apiVersion": "v1", "fieldPath": "spec.containers{hello-node}", "kind": "Pod", "name": "hello-node", "namespace": "default", ..... }, "kind": "Event", "message": "Started container", "metadata": { "name": "hello-node.159d7608e3a3572c", "namespace": "default", .... }, "reason": "Started", ... }
API サーバーソースの削除
トリガーを削除します。
$ kn trigger delete <trigger_name>
イベントソースを削除します。
$ kn source apiserver delete <source_name>
サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
$ oc delete -f authentication.yaml
5.8.2.1. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel
およびbroker
が含まれます。
5.8.3. YAML ファイルを使用した API サーバーソースの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述することができます。YAML を使用して API サーバーソースを作成するには、ApiServerSource
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
API サーバーソース YAML ファイルで定義されるものと同じ namespace に
default
ブローカーを作成している。 -
OpenShift (
oc
) CLI をインストールしている。
既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount
リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: events-sa namespace: default 1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: event-watcher namespace: default 2 rules: - apiGroups: - "" resources: - events verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k8s-ra-event-watcher namespace: default 3 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: event-watcher subjects: - kind: ServiceAccount name: events-sa namespace: default 4
YAML ファイルを適用します。
$ oc apply -f <filename>
API サーバーソースを YAML ファイルとして作成します。
apiVersion: sources.knative.dev/v1alpha1 kind: ApiServerSource metadata: name: testevents spec: serviceAccountName: events-sa mode: Resource resources: - apiVersion: v1 kind: Event sink: ref: apiVersion: eventing.knative.dev/v1 kind: Broker name: default
ApiServerSource
YAML ファイルを適用します。$ oc apply -f <filename>
API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを YAML ファイルとして作成します。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: event-display namespace: default spec: template: spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
Service
YAML ファイルを適用します。$ oc apply -f <filename>
直接の手順で作成下サービスに、
default
ブローカーからイベントをフィルターするTrigger
オブジェクトを YAML ファイルとして作成します。apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: event-display-trigger namespace: default spec: broker: default subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display
Trigger
YAML ファイルを適用します。$ oc apply -f <filename>
デフォルト namespace で Pod を起動してイベントを作成します。
$ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
$ oc get apiserversource.sources.knative.dev testevents -o yaml
出力例
apiVersion: sources.knative.dev/v1alpha1 kind: ApiServerSource metadata: annotations: creationTimestamp: "2020-04-07T17:24:54Z" generation: 1 name: testevents namespace: default resourceVersion: "62868" selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2 uid: 1603d863-bb06-4d1c-b371-f580b4db99fa spec: mode: Resource resources: - apiVersion: v1 controller: false controllerSelector: apiVersion: "" kind: "" name: "" uid: "" kind: Event labelSelector: {} serviceAccountName: events-sa sink: ref: apiVersion: eventing.knative.dev/v1 kind: Broker name: default
検証
Kubernetes イベントが Knative に送信されていることを確認するには、メッセージダンパー機能ログを確認します。
以下のコマンドを入力して Pod を取得します。
$ oc get pods
以下のコマンドを入力して、Pod のメッセージダンパー機能ログを表示します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.apiserver.resource.update datacontenttype: application/json ... Data, { "apiVersion": "v1", "involvedObject": { "apiVersion": "v1", "fieldPath": "spec.containers{hello-node}", "kind": "Pod", "name": "hello-node", "namespace": "default", ..... }, "kind": "Event", "message": "Started container", "metadata": { "name": "hello-node.159d7608e3a3572c", "namespace": "default", .... }, "reason": "Started", ... }
API サーバーソースの削除
トリガーを削除します。
$ oc delete -f trigger.yaml
イベントソースを削除します。
$ oc delete -f k8s-events.yaml
サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
$ oc delete -f authentication.yaml
5.9. ping ソースの作成
ping ソースは、一定のペイロードを使用して ping イベントをイベントコンシューマーに定期的に送信するために使用されるイベントソースです。ping ソースを使用すると、タイマーと同様にイベントの送信をスケジュールできます。
5.9.1. Web コンソールを使用した ping ソースの作成
Knative Eventing がクラスターにインストールされると、Web コンソールを使用して ping ソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
PingSource が機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。
- Developer パースペクティブで、+Add → YAML に移動します。
サンプル YAML をコピーします。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: event-display spec: template: spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
- Create をクリックします。
直前の手順で作成したサービスと同じ namespace、またはイベントの送信先となる他のシンクと同じ namespace に ping ソースを作成します。
- Developer パースペクティブで、+Add → Event Source に移動します。
- Ping Source を選択します。
- オプション: Data の値を入力できます。これはメッセージのペイロードです。
-
Schedule の値を入力します。この例では、値は
*/2 * * * *
であり、2 分ごとにメッセージを送信する ping ソースを作成します。 -
Sink を選択します。これは Resource または URI のいずれかになります。この例では、直前の手順で作成された
event-display
サービスが Resources シンクとして使用されます。 - Create をクリックします。
検証
Topology ページを表示して、ping ソースが作成され、シンクに接続されていることを確認できます。
- Developer パースペクティブで、Topology に移動します。
ping ソースおよびシンクを表示します。
ping ソースの削除
- Topology ビューに移動します。
- API サーバーソースを右クリックし、Delete Ping Source を選択します。
5.9.2. Knative CLI を使用した ping ソースの作成
kn source ping create
コマンドを使用し、kn
CLI を使用して ping ソースを作成できます。イベントソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
オプション: この手順の検証手順を使用する場合は、OpenShift (
oc
) CLI をインストールします。
手順
ping ソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
要求する必要のある ping イベントのセットごとに、PingSource をイベントコンシューマーと同じ namespace に作成します。
$ kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
$ kn source ping describe test-ping-source
出力例
Name: test-ping-source Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 15s Schedule: */2 * * * * Data: {"message": "Hello world!"} Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 8s ++ Deployed 8s ++ SinkProvided 15s ++ ValidSchedule 15s ++ EventTypeProvided 15s ++ ResourcesCorrect 15s
検証
シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。
デフォルトで、Knative サービスは、トラフィックが 60 秒以内に受信されない場合に Pod を終了します。本書の例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する ping ソースを作成します。
作成された新規 Pod を監視します。
$ watch oc get pods
Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.sources.ping source: /apis/v1/namespaces/default/pingsources/test-ping-source id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9 time: 2020-04-07T16:16:00.000601161Z datacontenttype: application/json Data, { "message": "Hello world!" }
ping ソースの削除
ping ソースを削除します。
$ kn delete pingsources.sources.knative.dev <ping_source_name>
5.9.2.1. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel
およびbroker
が含まれます。
5.9.3. YAML を使用した ping ソースの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述することができます。YAML を使用してサーバーレス ping を作成するには、PingSource
オブジェクトを定義する YAML ファイルを作成し、oc apply
を使用してこれを適用する必要があります。
PingSource
オブジェクトの例
apiVersion: sources.knative.dev/v1 kind: PingSource metadata: name: test-ping-source spec: schedule: "*/2 * * * *" 1 data: '{"message": "Hello world!"}' 2 sink: 3 ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
ping ソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。
サービス YAML ファイルを作成します。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: event-display spec: template: spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
サービスを作成します。
$ oc apply -f <filename>
要求する必要のある ping イベントのセットごとに、ping ソースをイベントコンシューマーと同じ namespace に作成します。
ping ソースの YAML ファイルを作成します。
apiVersion: sources.knative.dev/v1 kind: PingSource metadata: name: test-ping-source spec: schedule: "*/2 * * * *" data: '{"message": "Hello world!"}' sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display
ping ソースを作成します。
$ oc apply -f <filename>
以下のコマンドを入力し、コントローラーが正しくマップされていることを確認します。
$ oc get pingsource.sources.knative.dev <ping_source_name> -oyaml
出力例
apiVersion: sources.knative.dev/v1 kind: PingSource metadata: annotations: sources.knative.dev/creator: developer sources.knative.dev/lastModifier: developer creationTimestamp: "2020-04-07T16:11:14Z" generation: 1 name: test-ping-source namespace: default resourceVersion: "55257" selfLink: /apis/sources.knative.dev/v1/namespaces/default/pingsources/test-ping-source uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164 spec: data: '{ value: "hello" }' schedule: '*/2 * * * *' sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display namespace: default
検証
シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。
デフォルトで、Knative サービスは、トラフィックが 60 秒以内に受信されない場合に Pod を終了します。本書の例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する PingSource を作成します。
作成された新規 Pod を監視します。
$ watch oc get pods
Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.sources.ping source: /apis/v1/namespaces/default/pingsources/test-ping-source id: 042ff529-240e-45ee-b40c-3a908129853e time: 2020-04-07T16:22:00.000791674Z datacontenttype: application/json Data, { "message": "Hello world!" }
ping ソースの削除
ping ソースを削除します。
$ oc delete -f <filename>
コマンドの例
$ oc delete -f ping-source.yaml
5.10. カスタムイベントソース
Knative に含まれていないイベントプロデューサーや、CloudEvent
形式ではないイベントを生成するプロデューサーからイベントを Ingress する必要がある場合は、カスタムイベントソースを使用してこれを実行できます。カスタムイベントソースは、次のいずれかの方法で作成できます。
-
シンクバインディングを作成して、
PodSpecable
オブジェクトをイベントソースとして使用します。 - コンテナーソースを作成して、コンテナーをイベントソースとして使用します。
5.10.1. シンクバインディング
SinkBinding
オブジェクトは、イベント生成を配信アドレス指定から切り離すことをサポートします。シンクバインディングは、イベントプロデューサー をイベントコンシューマーまたは シンク に接続するために使用されます。イベントプロデューサーは、PodSpec
テンプレートを組み込む Kubernetes リソースであり、イベントを生成します。シンクは、イベントを受信できるアドレス指定可能な Kubernetes オブジェクトです。
SinkBinding
オブジェクトは、環境変数をシンクの PodTemplateSpec
に挿入します。つまり、アプリケーションコードが Kubernetes API と直接対話してイベントの宛先を見つける必要はありません。これらの環境変数は以下のとおりです。
K_SINK
- 解決されたシンクの URL。
K_CE_OVERRIDES
- アウトバウンドイベントの上書きを指定する JSON オブジェクト。
5.10.1.1. YAML を使用したシンクバインディングの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述することができます。YAML を使用してシンクバインディングを作成するには、SinkBinding
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
シンクバインディングが正しく設定されていることを確認するには、受信メッセージをダンプする Knative イベント表示サービスまたはイベントシンクを作成します。
サービス YAML ファイルを作成します。
サービス YAML ファイルの例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: event-display spec: template: spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
サービスを作成します。
$ oc apply -f <filename>
イベントをサービスに転送するシンクバインディングインスタンスを作成します。
シンクバインディング YAML ファイルを作成します。
サービス YAML ファイルの例
apiVersion: sources.knative.dev/v1alpha1 kind: SinkBinding metadata: name: bind-heartbeat spec: subject: apiVersion: batch/v1 kind: Job 1 selector: matchLabels: app: heartbeat-cron sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display
- 1
- この例では、ラベル
app: heartbeat-cron
を指定したジョブがイベントシンクにバインドされます。
シンクバインディングを作成します。
$ oc apply -f <filename>
CronJob
オブジェクトを作成します。cron ジョブの YAML ファイルを作成します。
cron ジョブの YAML ファイルの例
apiVersion: batch/v1beta1 kind: CronJob metadata: name: heartbeat-cron spec: # Run every minute schedule: "* * * * *" jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true" spec: template: spec: restartPolicy: Never containers: - name: single-heartbeat image: quay.io/openshift-knative/heartbeats:latest args: - --period=1 env: - name: ONE_SHOT value: "true" - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace
重要シンクバインディングを使用するには、
bindings.knative.dev/include=true
ラベルを Knative リソースに手動で追加する必要があります。たとえば、このラベルを
CronJob
インスタンスに追加するには、以下の行をJob
リソースの YAML 定義に追加します。jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true"
cron ジョブを作成します。
$ oc apply -f <filename>
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
$ oc get sinkbindings.sources.knative.dev bind-heartbeat -oyaml
出力例
spec: sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display namespace: default subject: apiVersion: batch/v1 kind: Job namespace: default selector: matchLabels: app: heartbeat-cron
検証
メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative イベントシンクに送信されていることを確認できます。
コマンドを入力します。
$ oc get pods
コマンドを入力します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.eventing.samples.heartbeat source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596 time: 2019-10-18T15:23:20.809775386Z contenttype: application/json Extensions, beats: true heart: yes the: 42 Data, { "id": 1, "label": "" }
5.10.1.2. Knative CLI を使用したシンクバインディングの作成
kn source binding create
コマンドを使用し、kn
を使用してシンクバインディングを作成できます。イベントソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
Knative (
kn
) CLI をインストールしている。 -
OpenShift (
oc
) CLI をインストールしている。
以下の手順では、YAML ファイルを作成する必要があります。
サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。
手順
シンクバインディングが正しく設定されていることを確認するには、受信メッセージをダンプする Knative イベント表示サービスまたはイベントシンクを作成します。
$ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
イベントをサービスに転送するシンクバインディングインスタンスを作成します。
$ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink ksvc:event-display
CronJob
オブジェクトを作成します。cron ジョブの YAML ファイルを作成します。
cron ジョブの YAML ファイルの例
apiVersion: batch/v1beta1 kind: CronJob metadata: name: heartbeat-cron spec: # Run every minute schedule: "* * * * *" jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true" spec: template: spec: restartPolicy: Never containers: - name: single-heartbeat image: quay.io/openshift-knative/heartbeats:latest args: - --period=1 env: - name: ONE_SHOT value: "true" - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace
重要シンクバインディングを使用するには、
bindings.knative.dev/include=true
ラベルを Knative CR に手動で追加する必要があります。たとえば、このラベルを
CronJob
CR に追加するには、以下の行をJob
CR の YAML 定義に追加します。jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true"
cron ジョブを作成します。
$ oc apply -f <filename>
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
$ kn source binding describe bind-heartbeat
出力例
Name: bind-heartbeat Namespace: demo-2 Annotations: sources.knative.dev/creator=minikube-user, sources.knative.dev/lastModifier=minikub ... Age: 2m Subject: Resource: job (batch/v1) Selector: app: heartbeat-cron Sink: Name: event-display Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 2m
検証
メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative イベントシンクに送信されていることを確認できます。
以下のコマンドを入力して、メッセージダンパー機能ログを表示します。
$ oc get pods
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.eventing.samples.heartbeat source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596 time: 2019-10-18T15:23:20.809775386Z contenttype: application/json Extensions, beats: true heart: yes the: 42 Data, { "id": 1, "label": "" }
5.10.1.2.1. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel
およびbroker
が含まれます。
5.10.1.3. Web コンソールを使用したシンクバインディングの作成
Knative Eventing がクラスターにインストールされると、Web コンソールを使用して シンクバインディングを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
シンクとして使用する Knative サービスを作成します。
- Developer パースペクティブで、+Add → YAML に移動します。
サンプル YAML をコピーします。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: event-display spec: template: spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
- 作成 をクリックします。
イベントソースとして使用される
CronJob
リソースを作成し、1 分ごとにイベントを送信します。- Developer パースペクティブで、+Add → YAML に移動します。
サンプル YAML をコピーします。
apiVersion: batch/v1 kind: CronJob metadata: name: heartbeat-cron spec: # Run every minute schedule: "*/1 * * * *" jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: true 1 spec: template: spec: restartPolicy: Never containers: - name: single-heartbeat image: quay.io/openshift-knative/heartbeats args: - --period=1 env: - name: ONE_SHOT value: "true" - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace
- 1
bindings.knative.dev/include: true
ラベルを含めるようにしてください。OpenShift Serverless のデフォルトの namespace 選択動作は包含モードを使用します。
- 作成 をクリックします。
直前の手順で作成したサービスと同じ namespace、またはイベントの送信先となる他のシンクと同じ namespace にシンクバインディングを作成します。
- Developer パースペクティブで、+Add → Event Source に移動します。Event Sources ページが表示されます。
- オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。
- Sink Binding を選択し、Create Event Source をクリックします。Create Event Source ページが表示されます。
-
apiVersion フィールドに
batch/v1
を入力します。 Kind フィールドに
Job
と入力します。注記CronJob
の種類は OpenShift Serverless シンクバインディングで直接サポートされていないため、Kind フィールドは cron ジョブオブジェクト自体ではなく、cron ジョブで作成されるJob
オブジェクトをターゲットにする必要があります。-
Sink を選択します。これは Resource または URI のいずれかになります。この例では、直前の手順で作成された
event-display
サービスが Resources シンクとして使用されます。 Match labels セクションで以下を実行します。
-
Name フィールドに
app
と入力します。 Value フィールドに
heartbeat-cron
と入力します。注記ラベルセレクターは、リソース名ではなくシンクバインディングで cron ジョブを使用する場合に必要になります。これは、cron ジョブで作成されたジョブには予測可能な名前がなく、名前に無作為に生成される文字列が含まれているためです。たとえば、
hearthbeat-cron-1cc23f
になります。
-
Name フィールドに
- 作成 をクリックします。
検証
Topology ページおよび Pod ログを表示して、シンクバインディング、シンク、および cron ジョブが正常に作成され、機能していることを確認できます。
- Developer パースペクティブで、Topology に移動します。
シンクバインディング、シンク、およびハートビートの cron ジョブを表示します。
- シンクバインディングが追加されると、正常なジョブが cron ジョブによって登録されていることを確認します。つまり、シンクバインディングは cron ジョブで作成されたジョブが正常に再設定されることを意味します。
-
event-display
サービス Pod のログを参照し、ハートビート cron ジョブで生成されるイベントを表示します。
5.10.1.4. シンクバインディング参照
シンクバインディングを作成して、PodSpecable
オブジェクトをイベントソースとして使用できます。SinkBinding
オブジェクトを作成するときに、複数のパラメーターを設定できます。
SinkBinding
オブジェクトは以下のパラメーターをサポートします。
フィールド | 説明 | 必須またはオプション |
---|---|---|
|
API バージョンを指定します(例: | 必須 |
|
このリソースオブジェクトを | 必須 |
|
| 必須 |
|
この | 必須 |
| シンクとして使用する URI に解決するオブジェクトへの参照。 | 必須 |
| ランタイムコントラクトがバインディング実装によって拡張されるリソースを参照します。 | 必須 |
| 上書きを定義して、シンクに送信されたイベントへの出力形式および変更を制御します。 | 任意 |
5.10.1.4.1. Subject パラメーター
Subject
パラメーターは、ランタイムコントラクトがバインディング実装によって拡張されるリソースを参照します。Subject
定義に複数のフィールドを設定できます。
Subject
定義は、以下のフィールドをサポートします。
フィールド | 説明 | 必須またはオプション |
---|---|---|
| 参照先の API バージョン。 | 必須 |
| 参照先の種類。 | 必須 |
| 参照先の namespace。省略されている場合、デフォルトはオブジェクトの namespace に設定されます。 | 任意 |
| 参照先の名前。 |
|
| 参照先のセレクター。 |
|
| ラベルセレクターの要件の一覧です。 |
|
| セレクターが適用されるラベルキー。 |
|
|
キーと値のセットの関係を表します。有効な演算子は |
|
|
文字列値の配列。 |
|
|
キーと値のペアのマップ。 |
|
サブジェクトパラメーターの例
以下の YAML の場合は、default
namespace の mysubject
という名前の Deployment
オブジェクトが選択されます。
apiVersion: sources.knative.dev/v1 kind: SinkBinding metadata: name: bind-heartbeat spec: subject: apiVersion: apps/v1 kind: Deployment namespace: default name: mysubject ...
以下の YAML の場合、default
namespace にラベル working=example
が設定された Job
オブジェクトが選択されます。
apiVersion: sources.knative.dev/v1 kind: SinkBinding metadata: name: bind-heartbeat spec: subject: apiVersion: batch/v1 kind: Job namespace: default selector: matchLabels: working: example ...
以下の YAML の場合、default
namespace にラベル working=example
または working=sample
が含まれる Pod
オブジェクトが選択されます。
apiVersion: sources.knative.dev/v1 kind: SinkBinding metadata: name: bind-heartbeat spec: subject: apiVersion: v1 kind: Pod namespace: default selector: - matchExpression: key: working operator: In values: - example - sample ...
5.10.1.4.2. CloudEvent オーバーライド
ceOverrides
定義は、シンクに送信される CloudEvent の出力形式および変更を制御するオーバーライドを提供します。ceOverrides
定義に複数のフィールドを設定できます。
ceOverrides
の定義は、以下のフィールドをサポートします。
フィールド | 説明 | 必須またはオプション |
---|---|---|
|
アウトバウンドイベントで追加または上書きされる属性を指定します。各 | 任意 |
拡張子として許可されるのは、有効な CloudEvent
属性名のみです。拡張機能オーバーライド構成から仕様定義属性を設定することはできません。たとえば、type
属性を変更することはできません。
CloudEvent オーバーライドの例
apiVersion: sources.knative.dev/v1 kind: SinkBinding metadata: name: bind-heartbeat spec: ... ceOverrides: extensions: extra: this is an extra attribute additional: 42
これにより、subject
に K_CE_OVERRIDES
環境変数が設定されます。
出力例
{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }
5.10.1.4.3. include ラベル
シンクバインディングを使用するには、bindings.knative.dev/include: "true"
ラベルをリソースまたはリソースが含まれる namespace のいずれかに割り当てる必要があります。リソース定義にラベルが含まれていない場合には、クラスター管理者は以下を実行してこれを namespace に割り当てることができます。
$ oc label namespace <namespace> bindings.knative.dev/include=true
5.10.2. コンテナーソース
コンテナーソースは、イベントを生成し、イベントをシンクに送信するコンテナーイメージを作成します。コンテナーソースを使用して、イメージ URI を使用するコンテナーイメージおよび ContainerSource
オブジェクトを作成して、カスタムイベントソースを作成できます。
5.10.2.1. コンテナーイメージを作成するためのガイドライン
コンテナーソースコントローラーには、K_SINK
および K_CE_OVERRIDES
の 2 つの環境変数が注入されます。これらの変数は、それぞれ sink
および ceOverrides
仕様から解決されます。イベントは、K_SINK
環境変数で指定されたシンク URI に送信されます。メッセージは、CloudEvent
HTTP 形式を使用して POST
として送信する必要があります。
コンテナーイメージの例
以下は、ハートビートコンテナーイメージの例になります。
package main import ( "context" "encoding/json" "flag" "fmt" "log" "os" "strconv" "time" duckv1 "knative.dev/pkg/apis/duck/v1" cloudevents "github.com/cloudevents/sdk-go/v2" "github.com/kelseyhightower/envconfig" ) type Heartbeat struct { Sequence int `json:"id"` Label string `json:"label"` } var ( eventSource string eventType string sink string label string periodStr string ) func init() { flag.StringVar(&eventSource, "eventSource", "", "the event-source (CloudEvents)") flag.StringVar(&eventType, "eventType", "dev.knative.eventing.samples.heartbeat", "the event-type (CloudEvents)") flag.StringVar(&sink, "sink", "", "the host url to heartbeat to") flag.StringVar(&label, "label", "", "a special label") flag.StringVar(&periodStr, "period", "5", "the number of seconds between heartbeats") } type envConfig struct { // Sink URL where to send heartbeat cloud events Sink string `envconfig:"K_SINK"` // CEOverrides are the CloudEvents overrides to be applied to the outbound event. CEOverrides string `envconfig:"K_CE_OVERRIDES"` // Name of this pod. Name string `envconfig:"POD_NAME" required:"true"` // Namespace this pod exists in. Namespace string `envconfig:"POD_NAMESPACE" required:"true"` // Whether to run continuously or exit. OneShot bool `envconfig:"ONE_SHOT" default:"false"` } func main() { flag.Parse() var env envConfig if err := envconfig.Process("", &env); err != nil { log.Printf("[ERROR] Failed to process env var: %s", err) os.Exit(1) } if env.Sink != "" { sink = env.Sink } var ceOverrides *duckv1.CloudEventOverrides if len(env.CEOverrides) > 0 { overrides := duckv1.CloudEventOverrides{} err := json.Unmarshal([]byte(env.CEOverrides), &overrides) if err != nil { log.Printf("[ERROR] Unparseable CloudEvents overrides %s: %v", env.CEOverrides, err) os.Exit(1) } ceOverrides = &overrides } p, err := cloudevents.NewHTTP(cloudevents.WithTarget(sink)) if err != nil { log.Fatalf("failed to create http protocol: %s", err.Error()) } c, err := cloudevents.NewClient(p, cloudevents.WithUUIDs(), cloudevents.WithTimeNow()) if err != nil { log.Fatalf("failed to create client: %s", err.Error()) } var period time.Duration if p, err := strconv.Atoi(periodStr); err != nil { period = time.Duration(5) * time.Second } else { period = time.Duration(p) * time.Second } if eventSource == "" { eventSource = fmt.Sprintf("https://knative.dev/eventing-contrib/cmd/heartbeats/#%s/%s", env.Namespace, env.Name) log.Printf("Heartbeats Source: %s", eventSource) } if len(label) > 0 && label[0] == '"' { label, _ = strconv.Unquote(label) } hb := &Heartbeat{ Sequence: 0, Label: label, } ticker := time.NewTicker(period) for { hb.Sequence++ event := cloudevents.NewEvent("1.0") event.SetType(eventType) event.SetSource(eventSource) event.SetExtension("the", 42) event.SetExtension("heart", "yes") event.SetExtension("beats", true) if ceOverrides != nil && ceOverrides.Extensions != nil { for n, v := range ceOverrides.Extensions { event.SetExtension(n, v) } } if err := event.SetData(cloudevents.ApplicationJSON, hb); err != nil { log.Printf("failed to set cloudevents data: %s", err.Error()) } log.Printf("sending cloudevent to %s", sink) if res := c.Send(context.Background(), event); !cloudevents.IsACK(res) { log.Printf("failed to send cloudevent: %v", res) } if env.OneShot { return } // Wait for next tick <-ticker.C } }
以下は、以前のハートビートコンテナーイメージを参照するコンテナーソースの例です。
apiVersion: sources.knative.dev/v1 kind: ContainerSource metadata: name: test-heartbeats spec: template: spec: containers: # This corresponds to a heartbeats image URI that you have built and published - image: gcr.io/knative-releases/knative.dev/eventing/cmd/heartbeats name: heartbeats args: - --period=1 env: - name: POD_NAME value: "example-pod" - name: POD_NAMESPACE value: "event-test" sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: example-service ...
5.10.2.2. Knative CLI を使用したコンテナーソースの作成および管理
kn source container
コマンドを使用し、kn
CLI を使用してコンテナーソースを作成および管理できます。イベントソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
コンテナーソースを作成します。
$ kn source container create <container_source_name> --image <image_uri> --sink <sink>
コンテナーソースの削除
$ kn source container delete <container_source_name>
コンテナーソースを記述します。
$ kn source container describe <container_source_name>
既存のコンテナーソースを一覧表示
$ kn source container list
既存のコンテナーソースを YAML 形式で一覧表示
$ kn source container list -o yaml
コンテナーソースを更新します。
このコマンドにより、既存のコンテナーソースのイメージ URI が更新されます。
$ kn source container update <container_source_name> --image <image_uri>
5.10.2.3. Web コンソールを使用したコンテナーソースの作成
Knative Eventing がクラスターにインストールされると、Web コンソールを使用してコンテナーソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
- Developer パースペクティブで、+Add → Event Source に移動します。Event Sources ページが表示されます。
- Container Source を選択します。
Container Source 設定を構成します。
- Image フィールドに、コンテナーソースが作成したコンテナーで実行するイメージの URI を入力します。
- Name フィールドにイメージの名前を入力します。
- オプション: Arguments フィールドで、コンテナーに渡す引数を入力します。
- オプション: Environment variables フィールドで、コンテナーに設定する環境変数を追加します。
Sink セクションで、コンテナーソースからのイベントがルーティングされるシンクを追加します。
- Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。
- URI を選択して、コンテナーソースからのイベントのルーティング先を指定します。
- コンテナーソースの設定が完了したら、Create をクリックします。
5.10.2.4. コンテナーソースのリファレンス
ContainerSource
オブジェクトを作成することにより、コンテナーをイベントソースとして使用できます。ContainerSource
オブジェクトを作成するときに、複数のパラメーターを設定できます。
ContainerSource
オブジェクトは以下のフィールドをサポートします。
フィールド | 説明 | 必須またはオプション |
---|---|---|
|
API バージョンを指定します(例: | 必須 |
|
このリソースオブジェクトを | 必須 |
|
| 必須 |
|
この | 必須 |
| シンクとして使用する URI に解決するオブジェクトへの参照。 | 必須 |
|
| 必須 |
| 上書きを定義して、シンクに送信されたイベントへの出力形式および変更を制御します。 | 任意 |
テンプレートパラメーターの例
apiVersion: sources.knative.dev/v1 kind: ContainerSource metadata: name: test-heartbeats spec: template: spec: containers: - image: quay.io/openshift-knative/heartbeats:latest name: heartbeats args: - --period=1 env: - name: POD_NAME value: "mypod" - name: POD_NAMESPACE value: "event-test" ...
5.10.2.4.1. CloudEvent オーバーライド
ceOverrides
定義は、シンクに送信される CloudEvent の出力形式および変更を制御するオーバーライドを提供します。ceOverrides
定義に複数のフィールドを設定できます。
ceOverrides
の定義は、以下のフィールドをサポートします。
フィールド | 説明 | 必須またはオプション |
---|---|---|
|
アウトバウンドイベントで追加または上書きされる属性を指定します。各 | 任意 |
拡張子として許可されるのは、有効な CloudEvent
属性名のみです。拡張機能オーバーライド構成から仕様定義属性を設定することはできません。たとえば、type
属性を変更することはできません。
CloudEvent オーバーライドの例
apiVersion: sources.knative.dev/v1 kind: ContainerSource metadata: name: test-heartbeats spec: ... ceOverrides: extensions: extra: this is an extra attribute additional: 42
これにより、subject
に K_CE_OVERRIDES
環境変数が設定されます。
出力例
{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }
5.11. チャネルの作成
チャネルは、単一のイベント転送および永続レイヤーを定義するカスタムリソースです。イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。

チャネルは、サポートされている Channel
オブジェクトをインスタンス化することで作成でき、Subscription
オブジェクトの delivery 仕様を変更することで再 配信
の試行を設定できます。
5.11.1. Web コンソールを使用したチャネルの作成
OpenShift Container Platform Web コンソールを使用すると、チャネルを作成するための合理的で直感的なユーザーインターフェースが提供されます。Knative Eventing がクラスターにインストールされると、Web コンソールを使用してチャネルを作成できます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
- Developer パースペクティブで、+Add → Channel に移動します。
-
Type リストで作成する
Channel
オブジェクトのタイプを選択します。 - 作成 をクリックします。
検証
Topology ページに移動して、チャネルが存在することを確認します。
5.11.2. Knative CLI を使用したチャネルの作成
チャネルを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn channel create
コマンドを使用し、kn
CLI を使用してチャネルを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
チャネルを作成します。
$ kn channel create <channel_name> --type <channel_type>
チャネルタイプはオプションですが、指定する場合、
Group:Version:Kind
の形式で指定する必要があります。たとえば、InMemoryChannel
オブジェクトを作成できます。$ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel
出力例
Channel 'mychannel' created in namespace 'default'.
検証
チャネルが存在することを確認するには、既存のチャネルを一覧表示し、出力を検査します。
$ kn channel list
出力例
kn channel list NAME TYPE URL AGE READY REASON mychannel InMemoryChannel http://mychannel-kn-channel.default.svc.cluster.local 93s True
チャネルの削除
チャネルを削除します。
$ kn channel delete <channel_name>
5.11.3. YAML を使用したデフォルト実装チャネルの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述することができます。YAML を使用してサーバーレスチャネルを作成するには、Channel
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Channel
オブジェクトを YAML ファイルとして作成します。apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: default
YAML ファイルを適用します。
$ oc apply -f <filename>
5.11.4. YAML を使用した Kafka チャネルの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述することができます。Kafka チャネルを作成することで、Kafka トピックに裏打ちされた Knative Eventing チャネルを作成できます。YAML を使用して Kafka チャネルを作成するには、KafkaChannel
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
カスタムリソースは OpenShift Container Platform クラスターにインストールされます。 -
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
KafkaChannel
オブジェクトを YAML ファイルとして作成します。apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel metadata: name: example-channel namespace: default spec: numPartitions: 3 replicationFactor: 1
重要OpenShift Serverless 上の
KafkaChannel
オブジェクトの API のv1beta1
バージョンのみがサポートされます。非推奨となったv1alpha1
バージョンの API は使用しないでください。KafkaChannel
YAML ファイルを適用します。$ oc apply -f <filename>
5.11.5. 次のステップ
- チャネルの作成後に、イベントシンクがチャネルにサブスクライブしてイベントを受信できるように、サブスクリプションを作成します。
5.12. サブスクリプションの作成および管理
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。サブスクリプションは、イベントを配信するチャネルとシンク (サブスクライバーとも呼ばれます) を指定する Subscription
オブジェクトを設定することによって作成されます。障害の処理方法など、シンク固有のオプションを指定することもできます。
5.12.1. Web コンソールを使用したサブスクリプションの作成
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。OpenShift Container Platform Web コンソールを使用すると、サブスクリプションを作成するための合理的で直感的なユーザーインターフェースが提供されます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしている。
- Knative サービスおよびチャネルなどのイベントシンクを作成している。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
- Developer パースペクティブで、Topology ページに移動します。
以下の方法のいずれかを使用してサブスクリプションを作成します。
サブスクリプションを作成するチャネルにカーソルを合わせ、矢印をドラッグします。Add Subscription オプションが表示されます。
- Subscriber 一覧でシンクを選択します。
- Add をクリックします。
- このサービスが、チャネルと同じ namespace またはプロジェクトにある Topology ビューで利用可能な場合は、サブスクリプションを作成するチャネルをクリックし、矢印をサービスに直接ドラッグして、チャネルからそのサービスにサブスクリプションを即時に作成します。
検証
サブスクリプションの作成後に、これを Topology ビューでチャネルをサービスに接続する行として表示できます。
5.12.2. YAML を使用したサブスクリプションの作成
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でサブスクリプションを宣言的に記述することができます。YAML を使用してサブスクリプションを作成するには、Subscription
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Subscription
オブジェクトを作成します。YAML ファイルを作成し、以下のサンプルコードをこれにコピーします。
apiVersion: messaging.knative.dev/v1beta1 kind: Subscription metadata: name: my-subscription 1 namespace: default spec: channel: 2 apiVersion: messaging.knative.dev/v1beta1 kind: Channel name: example-channel delivery: 3 deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: error-handler subscriber: 4 ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display
- 1
- サブスクリプションの名前。
- 2
- サブスクリプションが接続するチャネルの設定。
- 3
- イベント配信の設定。これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。これが設定されると、使用できないイベントが
deadLetterSink
に送信されます。イベントがドロップされると、イベントの再配信は試行されず、エラーのログがシステムに記録されます。deadLetterSink
値は Destination である必要があります。 - 4
- サブスクライバーの設定。これは、イベントがチャネルから送信されるイベントシンクです。
YAML ファイルを適用します。
$ oc apply -f <filename>
5.12.3. Knative CLI を使用したサブスクリプションの作成
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。サブスクリプションを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn subscription create
コマンドや適切なフラグを使用し、kn
CLI を使用してサブスクリプションを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
サブスクリプションを作成し、シンクをチャネルに接続します。
$ kn subscription create <subscription_name> \ --channel <group:version:kind>:<channel_name> \ 1 --sink <sink_prefix>:<sink_name> \ 2 --sink-dead-letter <sink_prefix>:<sink_name> 3
- 1
--channel
は、処理する必要のあるクラウドイベントのソースを指定します。チャネル名を指定する必要があります。Channel
カスタムリソースでサポートされるデフォルトのInMemoryChannel
チャネルを使用しない場合には、チャネル名に指定されたチャネルタイプの<group:version:kind>
のプレフィックスを付ける必要があります。たとえば、これは Kafka 対応チャネルのmessaging.knative.dev:v1beta1:KafkaChannel
のようになります。- 2
--sink
は、イベントが配信されるターゲット宛先を指定します。デフォルトで、<sink_name>
は、サブスクリプションと同じ namespace でこの名前の Knative サービスとして解釈されます。以下のプレフィックスのいずれかを使用して、シンクのタイプを指定できます。ksvc
- Knative サービス
channel
- 宛先として使用する必要のあるチャネル。ここで参照できるのは、デフォルトのチャネルタイプのみです。
broker
- Eventing ブローカー。
- 3
- オプション:
--sink-dead-letter
は、イベントが配信に失敗する場合にイベントを送信するシンクを指定するために使用できるオプションのフラグです。詳細は、OpenShift Serverless の Event 配信についてのドキュメントを参照してください。コマンドの例
$ kn subscription create mysubscription --channel mychannel --sink ksvc:event-display
出力例
Subscription 'mysubscription' created in namespace 'default'.
検証
サブスクリプションを使用してチャネルがイベントシンクまたは サブスクライバー に接続されていることを確認するには、既存のサブスクリプションを一覧表示し、出力を検査します。
$ kn subscription list
出力例
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display True
サブスクリプションの削除
サブスクリプションを削除します。
$ kn subscription delete <subscription_name>
5.12.4. Knative CLI を使用したサブスクリプションの記述
kn subscription describe
コマンドを使用し、kn
CLI を使用して、端末のサブスクリプションに関する情報を出力できます。サブスクリプションを記述するために kn
CLI を使用すると、YAML ファイルを直接表示するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
-
Knative (
kn
) CLI をインストールしている。 - クラスターにサブスクリプションを作成している。
手順
サブスクリプションを記述します。
$ kn subscription describe <subscription_name>
出力例
Name: my-subscription Namespace: default Annotations: messaging.knative.dev/creator=openshift-user, messaging.knative.dev/lastModifier=min ... Age: 43s Channel: Channel:my-channel (messaging.knative.dev/v1) Subscriber: URI: http://edisplay.default.example.com Reply: Name: default Resource: Broker (eventing.knative.dev/v1) DeadLetterSink: Name: my-sink Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 43s ++ AddedToChannel 43s ++ ChannelReady 43s ++ ReferencesResolved 43s
5.12.5. Knative CLI を使用したサブスクリプションの一覧表示
kn subscription list
コマンドを使用し、kn
CLI を使用してクラスター内の既存サブスクリプションを一覧表示できます。kn
CLI を使用してサブスクリプションを一覧表示すると、合理的で直感的なユーザーインターフェースが提供されます。
前提条件
-
Knative (
kn
) CLI をインストールしている。
手順
クラスターのサブスクリプションを一覧表示します。
$ kn subscription list
出力例
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display True
5.12.6. Knative CLI を使用したサブスクリプションの更新
kn subscription update
コマンドや適切なフラグを使用し、kn
CLI を使用してサブスクリプションを端末から更新できます。サブスクリプションを更新するために kn
CLI を使用すると、YAML ファイルを直接更新するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
-
Knative (
kn
) CLI をインストールしている。 - サブスクリプションを作成している。
手順
サブスクリプションを更新します。
$ kn subscription update <subscription_name> \ --sink <sink_prefix>:<sink_name> \ 1 --sink-dead-letter <sink_prefix>:<sink_name> 2
- 1
--sink
は、イベントが配信される、更新されたターゲット宛先を指定します。以下のプレフィックスのいずれかを使用して、シンクのタイプを指定できます。ksvc
- Knative サービス
channel
- 宛先として使用する必要のあるチャネル。ここで参照できるのは、デフォルトのチャネルタイプのみです。
broker
- Eventing ブローカー。
- 2
- オプション:
--sink-dead-letter
は、イベントが配信に失敗する場合にイベントを送信するシンクを指定するために使用できるオプションのフラグです。詳細は、OpenShift Serverless の Event 配信についてのドキュメントを参照してください。コマンドの例
$ kn subscription update mysubscription --sink ksvc:event-display
5.12.7. サブスクリプションを使用したイベント配信失敗パラメーターの設定
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。Subscription
オブジェクトの delivery
設定を変更して、個別のサブスクリプションのイベント配信パラメーターを設定できます。Knative Eventing は、イベントの配信に失敗した場合にイベントに何が起こるかを制御するために使用できるサブスクリプションの設定パラメーターを提供します。
Subscription
オブジェクトの例
apiVersion: messaging.knative.dev/v1 kind: Subscription metadata: name: <subscription_name> namespace: <subscription_namespace> spec: delivery: deadLetterSink: 1 ref: apiVersion: serving.knative.dev/v1 kind: Service name: <sink_name> backoffDelay: <duration> 2 backoffPolicy: <policy_type> 3 retry: <integer> 4
- 1
- dead letter sink の使用を有効にするための設定内容これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。
これが設定されると、配信できないイベントが dead letter sink の宛先に送信されます。宛先は Knative サービスまたは URI にすることができます。
- 2
backoffDelay
配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelay
パラメーターの期間は ISO 8601 形式を使用して指定されます。たとえば、PT1S
は 1 秒の遅延を指定します。- 3
backoffPolicy
配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーはlinear
またはexponential
のいずれかとして指定できます。linear
バックオフポリシーを使用する場合、バックオフの遅延は再試行間に指定される期間になります。exponential
バックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay*2^<numberOfRetries>
と等しくなります。- 4
- イベントが dead letter sink に送信される前にイベント配信を再試行する回数。
5.13. ブローカー
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST
リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST
リクエストとしてイベントシンクに送信できます。

5.13.1. ブローカータイプ
OpenShift Serverless で使用できるブローカー実装は複数あり、それぞれのブローカー実装が異なるイベント配信保証を持ち、異なる基礎となるテクノロジーを使用します。ブローカークラスを指定して、ブローカーの作成時にブローカー実装を選択できます。指定しない場合は、デフォルトのブローカークラスが使用されます。デフォルトのブローカークラスは、クラスター管理者によって設定できます。
5.13.1.1. チャネルベースのブローカー
チャネルベースのブローカー実装は、内部的にイベント配信にチャネルを使用します。チャネルベースのブローカーは、ブローカーインスタンスが使用するチャネルの実装に基づいて、異なるイベント配信保証を提供します。以下に例を示します。
-
InMemoryChannel
実装を使用するブローカーは、開発およびテストの目的で役立ちますが、実稼働環境に対しては適切なイベント配信保証を提供しません。 -
KafkaChannel
実装を使用するブローカーは、実稼働環境に必要なイベント配信保証を提供します。
5.13.1.2. Kafka ブローカー
Kafka ブローカーは、Kafka を内部的に使用して、少なくとも 1 回の配信保証を提供するブローカー実装です。複数の Kafka バージョンをサポートし、イベントの保存およびルーティングのために Kafka とネイティブに統合されています。
Kafka ブローカーは、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
5.13.2. デフォルト設定を使用するブローカーの作成
OpenShift Serverless は、kn
CLI を使用して作成できる default
Knative ブローカーを提供します。また、eventing.knative.dev/injection: enabled
アノテーションに追加するか、または eventing.knative.dev/injection=enabled
ラベルを namespace に追加して、 default
ブローカーを作成することもできます。
5.13.2.1. Knative CLI を使用したブローカーの作成
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。ブローカーを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn broker create
コマンドを使用し、kn
CLI を使用してブローカーを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
default
ブローカーを作成します。$ kn broker create default
検証
kn
コマンドを使用して、既存のブローカーを一覧表示します。$ kn broker list
出力例
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 True
オプション: OpenShift Container Platform Web コンソールを使用している場合、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。
5.13.2.2. トリガーのアノテーションによるブローカーの作成
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。eventing.knative.dev/injection: enabled
アノテーションを Trigger
オブジェクトに追加してブローカーを作成できます。
knative-eventing-injection: enabled
アノテーションを使用してブローカーを作成する場合、クラスター管理者のパーミッションなしにこのブローカーを削除することはできません。クラスター管理者が最初にこのアノテーションを削除せずにブローカーを削除する場合、ブローカーは削除後に再び作成されます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Trigger
オブジェクトを、eventing.knative.dev/injection: enabled
アノテーションを付けて YAML ファイルとして作成します。apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: annotations: eventing.knative.dev/injection: enabled name: <trigger_name> spec: broker: default subscriber: 1 ref: apiVersion: serving.knative.dev/v1 kind: Service name: <service_name>
- 1
- トリガーがイベントを送信するイベントシンクまたは サブスクライバー の詳細を指定します。
Trigger
YAML ファイルを適用します。$ oc apply -f <filename>
検証
oc
CLI を使用してブローカーが正常に作成されていることを確認するか、または Web コンソールの Topology ビューでこれを確認できます。
以下の
oc
コマンドを入力してブローカーを取得します。$ oc -n <namespace> get broker default
出力例
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56s
オプション: OpenShift Container Platform Web コンソールを使用している場合、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。
5.13.2.3. namespace へのラベル付けによるブローカーの作成
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。所有しているか、または書き込みパーミッションのある namespace にラベルを付けて default
ブローカーを自動的に作成できます。
この方法を使用して作成されたブローカーは、ラベルを削除すると削除されません。これらは手動で削除する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
eventing.knative.dev/injection=enabled
で namespace にラベルを付ける。$ oc label namespace <namespace> eventing.knative.dev/injection=enabled
検証
oc
CLI を使用してブローカーが正常に作成されていることを確認するか、または Web コンソールの Topology ビューでこれを確認できます。
oc
コマンドを使用してブローカーを取得します。$ oc -n <namespace> get broker <broker_name>
コマンドの例
$ oc -n default get broker default
出力例
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56s
オプション: OpenShift Container Platform Web コンソールを使用している場合、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。
5.13.2.4. 挿入 (injection) によって作成されたブローカーの削除
挿入によりブローカーを作成し、後でそれを削除する必要がある場合は、手動で削除する必要があります。namespace ラベルまたはトリガーアノテーションを使用して作成されたブローカーは、ラベルまたはアノテーションを削除した場合に永続的に削除されません。
前提条件
-
OpenShift (
oc
) CLI をインストールしている。
手順
eventing.knative.dev/injection=enabled
ラベルを namespace から削除します。$ oc label namespace <namespace> eventing.knative.dev/injection-
アノテーションを削除すると、Knative では削除後にブローカーを再作成できなくなります。
選択された namespace からブローカーを削除します。
$ oc -n <namespace> delete broker <broker_name>
検証
oc
コマンドを使用してブローカーを取得します。$ oc -n <namespace> get broker <broker_name>
コマンドの例
$ oc -n default get broker default
出力例
No resources found. Error from server (NotFound): brokers.eventing.knative.dev "default" not found
5.13.3. Kafka ブローカー
Knative Kafka ブローカーは、Knative ブローカー API の Apache Kafka ネイティブ実装です。ブローカーに対して Kafka との統合が改善され、他のブローカータイプでモデルをトリガーし、ネットワークホップを削減します。
現在テクノロジープレビューにある Kafka ブローカーは、FIPS ではサポートされていません。
Knative Kafka ブローカーは、バイナリーコンテンツモードを使用して、受信 CloudEvents を Kafka レコードとして保存します。つまり、すべての CloudEvent 属性とエクステンションは Kafka レコードのヘッダーとしてマッピングされ、CloudEvent の data
仕様は Kafka レコードの値に対応します。
クラスター管理者が、Kafka をデフォルトのブローカータイプとして使用するように OpenShift Serverless デプロイメントを設定している場合、デフォルト設定を使用してブローカーを作成すると、Kafka ベースの Broker
オブジェクトが作成されます。OpenShift Serverless デプロイメントが Kafka ブローカーをデフォルトのブローカータイプとして使用するよう設定されていない場合、以下のいずれかの手順を使用して Kafka ベースのブローカーを作成できます。
Kafka ブローカーは、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
5.13.3.1. YAML を使用した Kafka ブローカーの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka ブローカーを作成するには、Broker
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
カスタムリソースは OpenShift Container Platform クラスターにインストールされます。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc
) CLI がインストールされている。
手順
Kafka ベースのブローカーを YAML ファイルとして作成します。
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: Kafka 1 name: example-kafka-broker spec: config: apiVersion: v1 kind: ConfigMap name: kafka-broker-config 2 namespace: knative-eventing
Kafka ベースのブローカー YAML ファイルを適用します。
$ oc apply -f <filename>
5.13.3.2. 外部管理の Kafka トピックを使用する Kafka ブローカーの作成
独自の内部トピックを作成せずに Kafka ブローカーを使用する場合は、代わりに外部管理の Kafka トピックを使用できます。これを実行するには、kafka.eventing.knative.dev/external.topic
アノテーションを使用する Kafka Broker
オブジェクトを作成する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
カスタムリソースは OpenShift Container Platform クラスターにインストールされます。 - Red Hat AMQ Streams などの Kafka インスタンスにアクセスでき、Kafka トピックを作成している。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc
) CLI がインストールされている。
手順
Kafka ベースのブローカーを YAML ファイルとして作成します。
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: Kafka 1 kafka.eventing.knative.dev/external.topic: <topic_name> 2 ...
Kafka ベースのブローカー YAML ファイルを適用します。
$ oc apply -f <filename>
5.13.4. ブローカーの管理
kn
CLI は、ブローカーの一覧表示、説明、更新、および削除に使用できるコマンドを提供します。
5.13.4.1. Knative CLI を使用した既存ブローカーの一覧表示
kn
CLI を使用してブローカーを一覧表示すると、合理的で直感的なユーザーインターフェースが提供されます。kn broker list
コマンドを使用し、kn
CLI を使用してクラスター内の既存ブローカーを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
既存ブローカーの一覧を表示します。
$ kn broker list
出力例
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 True
5.13.4.2. Knative CLI を使用した既存ブローカーの記述
kn
CLI を使用してブローカーを記述すると、合理的で直感的なユーザーインターフェースが提供されます。kn broker describe
コマンドを使用し、kn
CLI を使用してクラスター内の既存ブローカーに関する情報を出力できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
既存ブローカーを記述します。
$ kn broker describe <broker_name>
デフォルトブローカーを使用したコマンドの例
$ kn broker describe default
出力例
Name: default Namespace: default Annotations: eventing.knative.dev/broker.class=MTChannelBasedBroker, eventing.knative.dev/creato ... Age: 22s Address: URL: http://broker-ingress.knative-eventing.svc.cluster.local/default/default Conditions: OK TYPE AGE REASON ++ Ready 22s ++ Addressable 22s ++ FilterReady 22s ++ IngressReady 22s ++ TriggerChannelReady 22s
5.13.5. 関連情報
5.14. トリガー
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST
リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST
リクエストとしてイベントシンクに送信できます。

5.14.1. Web コンソールを使用したトリガーの作成
OpenShift Container Platform Web コンソールを使用すると、トリガーを作成するための合理的で直感的なユーザーインターフェースが提供されます。Knative Eventing がクラスターにインストールされ、ブローカーが作成されると、Web コンソールを使用してトリガーを作成できます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- トリガーに接続するために、ブローカーおよび Knative サービスまたは他のイベントシンクを作成している。
手順
- Developer パースペクティブで、Topology ページに移動します。
- トリガーを作成するブローカーにカーソルを合わせ、矢印をドラッグします。Add Trigger オプションが表示されます。
- Add Trigger を クリックします。
- Subscriber 一覧でシンクを選択します。
- Add をクリックします。
検証
- サブスクリプションの作成後に、これを Topology ページで表示できます。ここでは、ブローカーをイベントシンクに接続する線として表されます。
トリガーの削除
- Developer パースペクティブで、Topology ページに移動します。
- 削除するトリガーをクリックします。
- Actions コンテキストメニューで、Delete Trigger を選択します。
5.14.2. Knative CLI を使用したトリガーの作成
トリガーを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn trigger create
コマンドを使用し、kn
CLI を使用してトリガーを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
トリガーを作成します。
$ kn trigger create <trigger_name> --broker <broker_name> --filter <key=value> --sink <sink_name>
または、トリガーを作成し、ブローカー挿入を使用して
default
ブローカーを同時に作成できます。$ kn trigger create <trigger_name> --inject-broker --filter <key=value> --sink <sink_name>
デフォルトで、トリガーはブローカーに送信されたすべてのイベントを、そのブローカーにサブスクライブされるシンクに転送します。トリガーの
--filter
属性を使用すると、ブローカーからイベントをフィルターできるため、サブスクライバーは定義された基準に基づくイベントのサブセットのみを受け取ることができます。
5.14.3. Knative CLI の使用によるトリガーの一覧表示
kn
CLI を使用してトリガーを一覧表示すると、合理的で直感的なユーザーインターフェースが提供されます。kn trigger list
コマンドを使用して、クラスター内の既存トリガーを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
利用可能なトリガーの一覧を出力します。
$ kn trigger list
出力例
NAME BROKER SINK AGE CONDITIONS READY REASON email default ksvc:edisplay 4s 5 OK / 5 True ping default ksvc:edisplay 32s 5 OK / 5 True
オプション: JSON 形式でトリガーの一覧を出力します。
$ kn trigger list -o json
5.14.4. Knative CLI を使用したトリガーの記述
kn
CLI を使用してトリガーを記述すると、合理的で直感的なユーザーインターフェースが提供されます。kn trigger describe
コマンドを使用し、kn
CLI を使用してクラスター内の既存トリガーに関する情報を出力できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - トリガーを作成している。
手順
コマンドを入力します。
$ kn trigger describe <trigger_name>
出力例
Name: ping Namespace: default Labels: eventing.knative.dev/broker=default Annotations: eventing.knative.dev/creator=kube:admin, eventing.knative.dev/lastModifier=kube:admin Age: 2m Broker: default Filter: type: dev.knative.event Sink: Name: edisplay Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 2m ++ BrokerReady 2m ++ DependencyReady 2m ++ Subscribed 2m ++ SubscriberResolved 2m
5.14.5. Knative CLI を使用したトリガーでのイベントのフィルター
kn
CLI を使用してイベントをフィルタリングすると、合理的で直感的なユーザーインターフェースが提供されます。kn trigger create
コマンドを適切なフラグとともに使用し、トリガーを使用してイベントをフィルタリングできます。
以下のトリガーの例では、type: dev.knative.samples.helloworld
属性のイベントのみがイベントシンクに送付されます。
$ kn trigger create <trigger_name> --broker <broker_name> --filter type=dev.knative.samples.helloworld --sink ksvc:<service_name>
複数の属性を使用してイベントをフィルターすることもできます。以下の例は、type、source、および extension 属性を使用してイベントをフィルターする方法を示しています。
$ kn trigger create <trigger_name> --broker <broker_name> --sink ksvc:<service_name> \ --filter type=dev.knative.samples.helloworld \ --filter source=dev.knative.samples/helloworldsource \ --filter myextension=my-extension-value
5.14.6. Knative CLI を使用したトリガーの更新
kn
CLI を使用してトリガーを更新すると、合理的で直感的なユーザーインターフェースが提供されます。特定のフラグを指定して kn trigger update
コマンドを使用して、トリガーの属性を更新できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
トリガーを更新します。
$ kn trigger update <trigger_name> --filter <key=value> --sink <sink_name> [flags]
トリガーを、受信イベントに一致するイベント属性をフィルターするように更新できます。たとえば、
type
属性を使用します。$ kn trigger update <trigger_name> --filter type=knative.dev.event
トリガーからフィルター属性を削除できます。たとえば、キー
type
を使用してフィルター属性を削除できます。$ kn trigger update <trigger_name> --filter type-
--sink
パラメーターを使用して、トリガーのイベントシンクを変更できます。$ kn trigger update <trigger_name> --sink ksvc:my-event-sink
5.14.7. Knative CLI を使用したトリガーの削除
kn
CLI を使用してトリガーを削除すると、合理的で直感的なユーザーインターフェースが提供されます。kn trigger delete
コマンドを使用してトリガーを削除できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
トリガーを削除します。
$ kn trigger delete <trigger_name>
検証
既存のトリガーを一覧表示します。
$ kn trigger list
トリガーが存在しないことを確認します。
出力例
No triggers found.
5.15. Knative Kafka の使用
Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。Kafka は、イベントソース、チャネル、ブローカー、およびイベントシンク機能のオプションを提供します。
Knative Kafka 機能は、クラスター管理者が KnativeKafka
カスタムリソースをインストールしている場合に、OpenShift Serverless インストールで利用できます。
現時点で、Knative Kafka は IBM Z および IBM Power Systems ではサポートされていません。
Knative Kafka は、以下のような追加オプションを提供します。
- Kafka ソース
- Kafka チャネル
- Kafka ブローカー (テクノロジープレビュー)
- Kafka シンク (テクノロジープレビュー)
5.15.1. Kafka イベント配信およびリトライ
イベント駆動型のアーキテクチャーで Kafka コンポーネントを使用すると、「最低でも 1 度」のイベント配信が提供されます。これは、戻りコード値を受け取るまで操作がリトライされることを意味します。これにより、失われたイベントに対してアプリケーションの回復性が強化されます。ただし、重複するイベントが送信されてしまう可能性があります。
Kafka イベントソースでは、デフォルトでイベント配信のリトライ回数が固定されています。Kafka チャネルの場合、Kafka チャネルの Delivery
仕様に設定されている場合にのみリトライが実行されます。
配信保証に関する詳細は、イベント配信 のドキュメントを参照してください。
5.15.2. Kafka ソース
Apache Kafka クラスターからイベントを読み取り、これらのイベントをシンクに渡す Kafka ソースを作成できます。Kafka ソースを作成するには、OpenShift Container Platform Web コンソールの Knative (kn
)CLI を使用するか、KafkaSource
オブジェクトを YAML ファイルとして直接作成し、OpenShift (oc
) CLI を使用して適用します。
5.15.2.1. Web コンソールを使用した Kafka イベントソースの作成
Knative Kafka をクラスターにインストールした後、Web コンソールを使用して Kafka ソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、Kafka ソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。
前提条件
-
OpenShift Serverless Operator、Knative Serving、および
KnativeKafka
カスタムリソースがクラスターにインストールされている。 - Web コンソールにログインしている。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
- Developer パースペクティブで、Add ページに移動し、Event Source を選択します。
- Event Sources ページで、Type セクションの Kafka Source を選択します。
Kafka Source 設定を設定します。
- ブートストラップサーバー のカンマ区切りの一覧を追加します。
- トピック のカンマ区切りの一覧を追加します。
- コンシューマーグループ を追加します。
- 作成したサービスアカウントの Service Account Name を選択します。
- イベントソースの Sink を選択します。Sink は、チャネル、ブローカー、またはサービスなどの Resource、または URI のいずれかになります。
- Kafka イベントソースの Name を入力します。
- Create をクリックします。
検証
Topology ページを表示して、Kafka イベントソースが作成され、シンクに接続されていることを確認できます。
- Developer パースペクティブで、Topology に移動します。
Kafka イベントソースおよびシンクを表示します。
5.15.2.2. Knative CLI を使用した Kafka イベントソースの作成
kn source kafka create
コマンドを使用し、kn
CLI を使用して Kafka ソースを作成できます。イベントソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、Knative Serving、および
KnativeKafka
カスタムリソース (CR) がクラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
-
Knative (
kn
) CLI をインストールしている。 -
オプション: この手順で検証ステップを使用する場合は、OpenShift (
oc
) CLI をインストールします。
手順
Kafka イベントソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする Knative サービスを作成します。
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display
KafkaSource
CR を作成します。$ kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display
注記このコマンドのプレースホルダー値は、ソース名、ブートストラップサーバー、およびトピックの値に置き換えます。
--servers
、--topics
、および--consumergroup
オプションは、Kafka クラスターへの接続パラメーターを指定します。--consumergroup
オプションは任意です。オプション: 作成した
KafkaSource
CR の詳細を表示します。$ kn source kafka describe <kafka_source_name>
出力例
Name: example-kafka-source Namespace: kafka Age: 1h BootstrapServers: example-cluster-kafka-bootstrap.kafka.svc:9092 Topics: example-topic ConsumerGroup: example-consumer-group Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 1h ++ Deployed 1h ++ SinkProvided 1h
検証手順
Kafka インスタンスをトリガーし、メッセージをトピックに送信します。
$ oc -n kafka run kafka-producer \ -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \ --restart=Never -- bin/kafka-console-producer.sh \ --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
プロンプトにメッセージを入力します。このコマンドは、以下を前提とします。
-
Kafka クラスターが
kafka
namespace にインストールされている。 -
KafkaSource
オブジェクトは、my-topic
トピックを使用するように設定されている。
-
Kafka クラスターが
ログを表示して、メッセージが到達していることを確認します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.kafka.event source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic subject: partition:46#0 id: partition:46/offset:0 time: 2021-03-10T11:21:49.4Z Extensions, traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00 Data, Hello!
5.15.2.2.1. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel
およびbroker
が含まれます。
5.15.2.3. YAML を使用した Kafka イベントソースの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka ソースを作成するには、KafkaSource
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Serving、および
KnativeKafka
カスタムリソースがクラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
-
OpenShift CLI (
oc
) をインストールしている。
手順
KafkaSource
オブジェクトを YAML ファイルとして作成します。apiVersion: sources.knative.dev/v1beta1 kind: KafkaSource metadata: name: <source_name> spec: consumerGroup: <group_name> 1 bootstrapServers: - <list_of_bootstrap_servers> topics: - <list_of_topics> 2 sink: - <list_of_sinks> 3
重要OpenShift Serverless 上の
KafkaSource
オブジェクトの API のv1beta1
バージョンのみがサポートされます。非推奨となったv1alpha1
バージョンの API は使用しないでください。KafkaSource
オブジェクトの例apiVersion: sources.knative.dev/v1beta1 kind: KafkaSource metadata: name: kafka-source spec: consumerGroup: knative-group bootstrapServers: - my-cluster-kafka-bootstrap.kafka:9092 topics: - knative-demo-topic sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display
KafkaSource
YAML ファイルを適用します。$ oc apply -f <filename>
検証
以下のコマンドを入力して、Kafka イベントソースが作成されたことを確認します。
$ oc get pods
出力例
NAME READY STATUS RESTARTS AGE kafkasource-kafka-source-5ca0248f-... 1/1 Running 0 13m
5.15.3. Kafka ブローカー
Knative Kafka ブローカーは、Knative ブローカー API の Apache Kafka ネイティブ実装です。ブローカーに対して Kafka との統合が改善され、他のブローカータイプでモデルをトリガーし、ネットワークホップを削減します。
現在テクノロジープレビューにある Kafka ブローカーは、FIPS ではサポートされていません。
Knative Kafka ブローカーは、バイナリーコンテンツモードを使用して、受信 CloudEvents を Kafka レコードとして保存します。つまり、すべての CloudEvent 属性とエクステンションは Kafka レコードのヘッダーとしてマッピングされ、CloudEvent の data
仕様は Kafka レコードの値に対応します。
クラスター管理者が、Kafka をデフォルトのブローカータイプとして使用するように OpenShift Serverless デプロイメントを設定している場合、デフォルト設定を使用してブローカーを作成すると、Kafka ベースの Broker
オブジェクトが作成されます。OpenShift Serverless デプロイメントが Kafka ブローカーをデフォルトのブローカータイプとして使用するよう設定されていない場合、以下のいずれかの手順を使用して Kafka ベースのブローカーを作成できます。
Kafka ブローカーは、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
5.15.3.1. YAML を使用した Kafka ブローカーの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka ブローカーを作成するには、Broker
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
カスタムリソースは OpenShift Container Platform クラスターにインストールされます。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc
) CLI がインストールされている。
手順
Kafka ベースのブローカーを YAML ファイルとして作成します。
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: Kafka 1 name: example-kafka-broker spec: config: apiVersion: v1 kind: ConfigMap name: kafka-broker-config 2 namespace: knative-eventing
Kafka ベースのブローカー YAML ファイルを適用します。
$ oc apply -f <filename>
5.15.3.2. 外部管理の Kafka トピックを使用する Kafka ブローカーの作成
独自の内部トピックを作成せずに Kafka ブローカーを使用する場合は、代わりに外部管理の Kafka トピックを使用できます。これを実行するには、kafka.eventing.knative.dev/external.topic
アノテーションを使用する Kafka Broker
オブジェクトを作成する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
カスタムリソースは OpenShift Container Platform クラスターにインストールされます。 - Red Hat AMQ Streams などの Kafka インスタンスにアクセスでき、Kafka トピックを作成している。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc
) CLI がインストールされている。
手順
Kafka ベースのブローカーを YAML ファイルとして作成します。
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: Kafka 1 kafka.eventing.knative.dev/external.topic: <topic_name> 2 ...
Kafka ベースのブローカー YAML ファイルを適用します。
$ oc apply -f <filename>
5.15.4. YAML を使用した Kafka チャネルの作成
YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述することができます。Kafka チャネルを作成することで、Kafka トピックに裏打ちされた Knative Eventing チャネルを作成できます。YAML を使用して Kafka チャネルを作成するには、KafkaChannel
オブジェクトを定義する YAML ファイルを作成し、oc apply
コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
カスタムリソースは OpenShift Container Platform クラスターにインストールされます。 -
OpenShift (
oc
) CLI をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
KafkaChannel
オブジェクトを YAML ファイルとして作成します。apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel metadata: name: example-channel namespace: default spec: numPartitions: 3 replicationFactor: 1
重要OpenShift Serverless 上の
KafkaChannel
オブジェクトの API のv1beta1
バージョンのみがサポートされます。非推奨となったv1alpha1
バージョンの API は使用しないでください。KafkaChannel
YAML ファイルを適用します。$ oc apply -f <filename>
5.15.5. Kafka シンクコ
Kafka シンクは、クラスター管理者がクラスターで Kafka を有効にした場合に使用できるイベントシンクの一種です。Kafka シンクを使用して、イベントソースから Kafka トピックにイベントを直接送信できます。
Kafka シンクはテクノロジープレビュー機能のみです。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
5.15.5.1. Kafka シンクの使用
Kafka トピックにイベントを送信する Kafka シンクと呼ばれるイベントシンクを作成できます。YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka シンクを作成するには、KafkaSink
オブジェクトを定義する YAML ファイルを作成してから、ocapply
コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Serving、および
KnativeKafka
カスタムリソース (CR) がクラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
-
OpenShift (
oc
) CLI をインストールしている。
手順
KafkaSink
オブジェクト定義を YAML ファイルとして作成します。Kafka シンク YAML
apiVersion: eventing.knative.dev/v1alpha1 kind: KafkaSink metadata: name: <sink-name> namespace: <namespace> spec: topic: <topic-name> bootstrapServers: - <bootstrap-server>
Kafka シンクを作成するには、
KafkaSink
YAML ファイルを適用します。$ oc apply -f <filename>
シンクが仕様で指定されるようにイベントソースを設定します。
API サーバーソースに接続された Kafka シンクの例
apiVersion: sources.knative.dev/v1alpha2 kind: ApiServerSource metadata: name: <source-name> 1 namespace: <namespace> 2 spec: serviceAccountName: <service-account-name> 3 mode: Resource resources: - apiVersion: v1 kind: Event sink: ref: apiVersion: eventing.knative.dev/v1alpha1 kind: KafkaSink name: <sink-name> 4
5.15.6. 関連情報
第6章 管理
6.1. グローバル設定
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
で使用される値を持ちます。
6.1.1. デフォルトチャネル実装の設定
default-ch-webhook
設定マップを使用して、Knative Eventing のデフォルトのチャネル実装を指定できます。デフォルトのチャネル実装は、クラスター全体、および 1 つ以上の namespace に対して指定できます。現在、InMemoryChannel
および KafkaChannel
チャネルタイプがサポートされています。
前提条件
- OpenShift Container Platform のクラスター管理者パーミッションがある。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
-
デフォルトのチャネル実装として Kafka チャネルを使用する場合は、クラスターに
KnativeKafka
CR もインストールする必要があります。
手順
KnativeEventing
カスタムリソースを変更して、default-ch-webhook
設定マップの設定の詳細を追加します。apiVersion: operator.knative.dev/v1alpha1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: config: 1 default-ch-webhook: 2 default-ch-config: | clusterDefault: 3 apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel spec: delivery: backoffDelay: PT0.5S backoffPolicy: exponential retry: 5 namespaceDefaults: 4 my-namespace: apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel spec: numPartitions: 1 replicationFactor: 1
重要namespace 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。
6.1.2. scale-to-zero の有効化
Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング(autoscaling)を提供します。enable-scale-to-zero
仕様を使用して、クラスター上のアプリケーションにスケールをグローバルに有効または無効にできます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- クラスター管理者のパーミッション。
- デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。
手順
KnativeServing
カスタムリソース(CR)のenable-scale-to-zero
仕様を変更します。KnativeServingCR の例
apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: enable-scale-to-zero: "false" 1
- 1
enable-scale-to-zero
仕様は、「true」
または「false」
のいずれかです。true に設定すると、scale-to-zero が有効にされます。false に設定すると、アプリケーションは設定された スケーリング下限 にスケールダウンされます。デフォルト値は"true"
です。
6.1.3. scale-to-zero 猶予期間の設定
Knative Serving は、アプリケーションの Pod をゼロにスケールダウンします。scale-to-zero-grace-period
仕様を使用して、Knative がアプリケーションの最後のレプリカが削除される前にゼロまでのスケーリングを待つ上限時間制限を定義できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- クラスター管理者のパーミッション。
- デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。
手順
KnativeServing
カスタムリソース(CR)のscale-to-zero-grace-period
仕様を変更します。KnativeServingCR の例
apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: scale-to-zero-grace-period: "30s" 1
- 1
- 猶予期間(秒単位)。デフォルト値は 30 秒です。
6.1.4. システムのデプロイメント設定の上書き
KnativeServing
および KnativeEventing
カスタムリソース(CR)の deployments
仕様を変更して、一部の特定のデプロイメントのデフォルト設定を上書きできます。
6.1.4.1. Knative Serving システムデプロイメント設定の上書き
KnativeServing
カスタムリソース(CR)の deployments
仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現時点で、デフォルト設定の上書きは リソース
、レプリカ
、ラベル
、アノテーション
、および nodeSelector
フィールドでサポートされています。
以下の例では、KnativeServing
CR は webhook
デプロイメントをオーバーライドし、以下を確認します。
- デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
- デプロイメントには 3 つのレプリカがあります。
-
example-label: ラベルラベル
が追加されます。 -
example-annotation: アノテーションアノテーション
が追加されます。 -
nodeSelector
フィールドは、disktype: hdd
ラベルを持つノードを選択するように設定されます。
KnativeServing
CR ラベルおよびアノテーション設定は、デプロイメント自体と結果として生成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。
KnativeServing CR の例
apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: ks namespace: knative-serving spec: high-availability: replicas: 2 deployments: - name: webhook resources: - container: webhook requests: cpu: 300m memory: 60Mi limits: cpu: 1000m memory: 1000Mi replicas: 3 labels: example-label: label annotations: example-annotation: annotation nodeSelector: disktype: hdd
6.1.4.2. Knative Eventing システムのデプロイメント設定の上書き
KnativeEventing
カスタムリソース(CR)の deployments
仕様を変更することで、一部の特定のデプロイメントのデフォルト設定を上書きできます。現時点で、デフォルト設定のオーバーライドは eventing-controller
、eventing-webhook
、および imc-controller
フィールドでサポートされます。
replicas
仕様は Horizontal Pod Autoscaler(HPA)を使用するデプロイメントのレプリカ数を上書きすることはできず、eventing-webhook
デプロイメントでは機能しません。
以下の例では、KnativeEventing
CR は eventing-controller
デプロイメントを上書きするため、以下が可能になります。
- デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
- デプロイメントには 3 つのレプリカがあります。
-
example-label: ラベルラベル
が追加されます。 -
example-annotation: アノテーションアノテーション
が追加されます。 -
nodeSelector
フィールドは、disktype: hdd
ラベルを持つノードを選択するように設定されます。
KnativeEventing CR の例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: deployments: - name: eventing-controller resources: - container: eventing-controller requests: cpu: 300m memory: 100Mi limits: cpu: 1000m memory: 250Mi replicas: 3 labels: example-label: label annotations: example-annotation: annotation nodeSelector: disktype: hdd
KnativeEventing
CR ラベルおよびアノテーション設定は、デプロイメント自体と作成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。
6.1.5. EmptyDir 拡張機能の設定
emptyDir
ボリュームは、Pod の作成時に作成される空のボリュームであり、一時的な作業ディスク領域を提供するために使用されます。emptyDir
ボリュームは、それらが作成された Pod が削除されると削除されます。
kubernetes.podspec-volumes-emptydir
拡張機能は、emptyDir
ボリュームを KnativeServing で使用できるかどうかを制御します。emptyDir
ボリュームの使用を有効にするには、KnativeServing
カスタムリソース(CR)を変更して以下の YAML を追加する必要があります。
KnativeServingCR の例
apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-volumes-emptydir: enabled ...
6.1.6. HTTPS リダイレクトのグローバル設定
HTTPS リダイレクトは、着信 HTTP リクエストのリダイレクトを提供します。これらのリダイレクトされた HTTP リクエストは暗号化されます。KnativeServing
カスタムリソース (CR) の httpProtocol
仕様を設定して、クラスターのすべてのサービスに対して HTTPS リダイレクトを有効にできます。
HTTPS リダイレクトを有効にする KnativeServing
CR の例
apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: network: httpProtocol: "redirected" ...
6.1.7. 外部ルートの URL スキームの設定
セキュリティーを強化するために、外部ルートの URL スキームはデフォルトで HTTPS に設定されています。このスキームは、KnativeServing
カスタムリソース (CR) 仕様のdefault-external-scheme
キーによって決定されます。
デフォルト仕様
... spec: config: network: default-external-scheme: "https" ...
default-external-scheme
キーを変更することにより、HTTP を使用するようにデフォルトの仕様をオーバーライドできます。
HTTP オーバーライド仕様
... spec: config: network: default-external-scheme: "http" ...
6.1.8. Kourier Gateway サービスタイプの設定
Kourier Gateway は、デフォルトで ClusterIP
サービスタイプとして公開されます。このサービスタイプは、KnativeServing
カスタムリソース (CR) の service-type
入力仕様によって決定されます。
デフォルト仕様
... spec: ingress: kourier: service-type: ClusterIP ...
service-type
仕様を変更することで、デフォルトのサービスタイプをオーバーライドして、代わりにロードバランサーサービスタイプを使用できます。
LoadBalancer オーバーライド仕様
... spec: ingress: kourier: service-type: LoadBalancer ...
6.1.9. PVC サポートの有効化
一部のサーバーレスアプリケーションには、永続的なデータストレージが必要です。これを実現するために、Knative サービスの永続ボリュームクレーム (PVC) を設定できます。
Knative サービスの PVC サポートは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
手順
Knative Serving が PVC を使用して書き込むことができるようにするには、
KnativeServing
カスタムリソース (CR) を変更して次の YAML を含めます。書き込みアクセスで PVC を有効にする
... spec: config: features: "kubernetes.podspec-persistent-volume-claim": enabled "kubernetes.podspec-persistent-volume-write": enabled ...
-
kubernetes.podspec-persistent-volume-claim
拡張機能は、永続ボリューム (PV) を Knative Serving で使用できるかどうかを制御します。 -
kubernetes.podspec-persistent-volume-write
拡張機能は、書き込みアクセスで Knative Serving が PV を利用できるかどうかを制御します。
-
PV を要求するには、PV 設定を含めるようにサービスを変更します。たとえば、次の設定で永続的なボリュームクレームがある場合があります。
注記要求しているアクセスモードをサポートするストレージクラスを使用してください。たとえば、
ReadWriteMany
アクセスモードにocs-storagecluster-cephfs
クラスを使用できます。PersistentVolumeClaim 設定
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: example-pv-claim namespace: my-ns spec: accessModes: - ReadWriteMany storageClassName: ocs-storagecluster-cephfs resources: requests: storage: 1Gi
この場合、書き込みアクセス権を持つ PV を要求するには、次のようにサービスを変更します。
ネイティブサービス PVC 設定
apiVersion: serving.knative.dev/v1 kind: Service metadata: namespace: my-ns ... spec: template: spec: containers: ... volumeMounts: 1 - mountPath: /data name: mydata readOnly: false volumes: - name: mydata persistentVolumeClaim: 2 claimName: example-pv-claim readOnly: false 3
注記Knative サービスで永続ストレージを正常に使用するには、Knative コンテナーユーザーのユーザー権限などの追加の設定が必要です。
6.1.10. init コンテナーの有効化
Init コンテナー は、Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナーです。これらは通常、アプリケーションの初期化ロジックを実装するために使用されます。これには、セットアップスクリプトの実行や、必要な設定のダウンロードが含まれる場合があります。KnativeServing
カスタムリソース (CR) を変更することにより、Knative サービスの init コンテナーの使用を有効にできます。
Knative サービスの初期化コンテナーはテクノロジープレビュー機能のみです。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。
Init コンテナーを使用すると、アプリケーションの起動時間が長くなる可能性があるため、頻繁にスケールアップおよびスケールダウンすることが予想されるサーバーレスアプリケーションには注意して使用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- クラスター管理者のパーミッション。
手順
KnativeServing
CR にkubernetes.podspec-init-containers
フラグを追加して、init コンテナーの使用を有効にします。KnativeServingCR の例
apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-init-containers: enabled ...
6.1.11. tag-to-digest の解決策
Knative Serving コントローラーがコンテナーレジストリーにアクセスできる場合、Knative Serving はサービスのリビジョンの作成時にイメージタグをダイジェストに解決します。これは tag-to-digest 解決 と呼ばれ、デプロイメントの一貫性を提供するのに役立ちます。
コントローラーが OpenShift Container Platform のコンテナーレジストリーにアクセスできるようにするには、シークレットを作成してからコントローラーのカスタム証明書を設定する必要があります。KnativeServing
カスタムリソース(CR)の controller-custom-certs
仕様を変更して、コントローラーのカスタム証明書を設定できます。シークレットは KnativeServing
CR と同じ namespace にある必要があります。
シークレットが KnativeServing
CR に含まれない場合、この設定はパブリックキーインフラストラクチャー(PKI)の使用にデフォルト設定されます。PKI を使用する場合、クラスター全体の証明書は config-service-sa
設定マップを使用して Knative Serving コントローラーに自動的に挿入されます。OpenShift Serverless Operator は config-service-sa
設定マップをクラスター全体の証明書で設定し、設定マップをボリュームとしてコントローラーにマウントします。
6.1.11.1. シークレットの使用による tag-to-digest 解決の設定
controller-custom-certs
仕様が Secret
タイプを使用する場合、シークレットはシークレットボリュームとしてマウントされます。Knative コンポーネントは、シークレットに必要な証明書があることを前提として、シークレットを直接使用します。
前提条件
- OpenShift Container Platform のクラスター管理者パーミッションがある。
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
手順
シークレットを作成します。
コマンドの例
$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>
KnativeServing
カスタムリソース(CR)のcontroller-custom-certs
仕様をSecret
タイプを使用するように設定します。KnativeServingCR の例
apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: controller-custom-certs: name: custom-secret type: Secret
6.1.12. 関連情報
6.2. Knative Kafka の設定
Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。Kafka は、イベントソース、チャネル、ブローカー、およびイベントシンク機能のオプションを提供します。
OpenShift Serverless のコアインストールの一部として提供される Knative Eventing コンポーネントの他に、クラスター管理者は KnativeKafka
カスタムリソース(CR)をインストールできます。
現時点で、Knative Kafka は IBM Z および IBM Power Systems ではサポートされていません。
KnativeKafka
CR は、ユーザーに以下のような追加オプションを提供します。
- Kafka ソース
- Kafka チャネル
- Kafka ブローカー (テクノロジープレビュー)
- Kafka シンク (テクノロジープレビュー)
6.2.1. Knative Kafka のインストール
Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。KnativeKafka
カスタムリソースをインストールしている場合、Knative Kafka 機能は OpenShift Serverless インストールで使用できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
- Red Hat AMQ Streams クラスターにアクセスできる。
-
検証手順を使用する場合は、OpenShift CLI (
oc
) をインストールします。 - OpenShift Container Platform のクラスター管理者パーミッションがある。
- OpenShift Container Platform Web コンソールにログインしている。
手順
- Administrator パースペクティブで、Operators → Installed Operators に移動します。
- ページ上部の Project ドロップダウンメニューが Project: knative-eventing に設定されていることを確認します。
- OpenShift Serverless Operator の Provided APIs の一覧で Knative Kafka ボックスを見つけ、Create Instance をクリックします。
Create Knative Kafka ページで KnativeKafka オブジェクトを設定します。
重要クラスターで Kafka チャネル、ソース、ブローカー、またはシンクを使用するには、使用するオプションの 有効な スイッチを true に切り替える必要があります。これらのスイッチは、デフォルトで false に設定されます。さらに、Kafka チャネル、ブローカー、またはシンクを使用するには、ブートストラップサーバーを指定する必要があります。
KnativeKafka
カスタムリソースの例apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: name: knative-kafka namespace: knative-eventing spec: channel: enabled: true 1 bootstrapServers: <bootstrap_servers> 2 source: enabled: true 3 broker: enabled: true 4 defaultConfig: bootstrapServers: <bootstrap_servers> 5 numPartitions: <num_partitions> 6 replicationFactor: <replication_factor> 7 sink: enabled: true 8
- 1
- 開発者はクラスターで
KafkaChannel
チャネルを使用できます。 - 2
- AMQ Streams クラスターからのブートストラップサーバーのカンマ区切りの一覧。
- 3
- 開発者はクラスターで
KafkaSource
イベントソースタイプを使用できます。 - 4
- 開発者はクラスターで Knative Kafka ブローカー実装を使用できます。
- 5
- Red Hat AMQ Streams クラスターからのブートストラップサーバーのコンマ区切りリスト。
- 6
Broker
オブジェクトでサポートされる Kafka トピックのパーティション数を定義します。デフォルトは10
です。- 7
Broker
オブジェクトでサポートされる Kafka トピックのレプリケーション係数を定義します。デフォルトは3
です。- 8
- 開発者がクラスター内で Kafka シンクを使用できるようにします。
注記replicationFactor
の値は、Red Hat AMQ Streams クラスターのノード数以下である必要があります。- KnativeKafka オブジェクトの作成を完全に制御する必要がない単純な設定に、このフォームの使用が推奨されます。
- KnativeKafka オブジェクトの作成を完全に制御する必要のあるより複雑な設定には、YAML の編集が推奨されます。YAML にアクセスするには、Create Knative Kafka ページの右上にある Edit YAML リンクをクリックします。
- Kafka のオプションの設定が完了したら、Create をクリックします。Knative Kafka タブに自動的にダイレクトされます。ここで、knative-kafka はリソースの一覧にあります。
検証
- Knative Kafka タブで knative-kafka リソースをクリックします。Knative Kafka Overview ページに自動的にダイレクトされます。
リソースの Conditions (状態) の一覧を表示し、それらのステータスが True であることを確認します。
状態のステータスが Unknown または False である場合は、ページを更新するためにしばらく待機します。
Knative Eventing リソースが作成されていることを確認します。
$ oc get pods -n knative-eventing
出力例
NAME READY STATUS RESTARTS AGE kafka-broker-dispatcher-7769fbbcbb-xgffn 2/2 Running 0 44s kafka-broker-receiver-5fb56f7656-fhq8d 2/2 Running 0 44s kafka-channel-dispatcher-84fd6cb7f9-k2tjv 2/2 Running 0 44s kafka-channel-receiver-9b7f795d5-c76xr 2/2 Running 0 44s kafka-controller-6f95659bf6-trd6r 2/2 Running 0 44s kafka-source-dispatcher-6bf98bdfff-8bcsn 2/2 Running 0 44s kafka-webhook-eventing-68dc95d54b-825xs 2/2 Running 0 44s
6.2.2. Knative Kafka のセキュリティー設定
通常、Kafka クラスターは TLS または SASL 認証を使用して保護されます。TLS または SASL を使用して、保護された Red Hat AMQ Streams クラスターに対して Kafka ブローカーまたはチャネルを設定できます。
Red Hat は、SASL と TLS の両方を有効にすることを推奨します。
6.2.2.1. Kafka ブローカーの TLS 認証の設定
Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。TLS は、Knative Kafka のトラフィック暗号化でサポートされる唯一の方法です。
前提条件
- OpenShift Container Platform のクラスター管理者パーミッションがある。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
CRは OpenShift Container Platform クラスターにインストールされます。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
.pem
ファイルとして Kafka クラスター CA 証明書が保存されている。 -
Kafka クラスタークライアント証明書とキーが
.pem
ファイルとして保存されている。 -
OpenShift (
oc
) CLI をインストールしている。
手順
証明書ファイルを
knative-eventing
namespace にシークレットファイルとして作成します。$ oc create secret -n knative-eventing generic <secret_name> \ --from-literal=protocol=SSL \ --from-file=ca.crt=caroot.pem \ --from-file=user.crt=certificate.pem \ --from-file=user.key=key.pem
重要キー名に
ca.crt
、user.crt
、およびuser.key
を使用します。これらの値は変更しないでください。KnativeKafka
CR を編集し、broker
仕様にシークレットへの参照を追加します。apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: broker: enabled: true defaultConfig: authSecretName: <secret_name> ...
6.2.2.2. Kafka ブローカーの SASL 認証の設定
Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。
前提条件
- OpenShift Container Platform のクラスター管理者パーミッションがある。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
CRは OpenShift Container Platform クラスターにインストールされます。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Kafka クラスターのユーザー名およびパスワードがある。
-
使用する SASL メカニズムを選択している (例:
PLAIN
、SCRAM-SHA-256
、またはSCRAM-SHA-512
)。 -
TLS が有効にされている場合、Kafka クラスターの
ca.crt
証明書ファイルも必要になります。 -
OpenShift CLI (
oc
) をインストールしている。
手順
証明書ファイルを
knative-eventing
namespace にシークレットファイルとして作成します。$ oc create secret -n knative-eventing generic <secret_name> \ --from-literal=protocol=SASL_SSL \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-file=ca.crt=caroot.pem \ --from-literal=password="SecretPassword" \ --from-literal=user="my-sasl-user"
-
キー名に
ca.crt
、password
、およびsasl.mechanism
を使用します。これらの値は変更しないでください。 パブリック CA 証明書で SASL を使用する場合は、シークレットの作成時に
ca.crt
引数ではなくtls.enabled=true
フラグを使用する必要があります。以下は例になります。$ oc create secret -n <namespace> generic <kafka_auth_secret> \ --from-literal=tls.enabled=true \ --from-literal=password="SecretPassword" \ --from-literal=saslType="SCRAM-SHA-512" \ --from-literal=user="my-sasl-user"
-
キー名に
KnativeKafka
CR を編集し、broker
仕様にシークレットへの参照を追加します。apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: broker: enabled: true defaultConfig: authSecretName: <secret_name> ...
6.2.2.3. Kafka チャネルの TLS 認証の設定
Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。TLS は、Knative Kafka のトラフィック暗号化でサポートされる唯一の方法です。
前提条件
- OpenShift Container Platform のクラスター管理者パーミッションがある。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
CRは OpenShift Container Platform クラスターにインストールされます。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
.pem
ファイルとして Kafka クラスター CA 証明書が保存されている。 -
Kafka クラスタークライアント証明書とキーが
.pem
ファイルとして保存されている。 -
OpenShift (
oc
) CLI をインストールしている。
手順
選択された namespace にシークレットとして証明書ファイルを作成します。
$ oc create secret -n <namespace> generic <kafka_auth_secret> \ --from-file=ca.crt=caroot.pem \ --from-file=user.crt=certificate.pem \ --from-file=user.key=key.pem
重要キー名に
ca.crt
、user.crt
、およびuser.key
を使用します。これらの値は変更しないでください。KnativeKafka
カスタムリソースの編集を開始します。$ oc edit knativekafka
シークレットおよびシークレットの namespace を参照します。
apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: channel: authSecretName: <kafka_auth_secret> authSecretNamespace: <kafka_auth_secret_namespace> bootstrapServers: <bootstrap_servers> enabled: true source: enabled: true
注記ブートストラップサーバーで一致するポートを指定するようにしてください。
以下は例になります。
apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: channel: authSecretName: tls-user authSecretNamespace: kafka bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9094 enabled: true source: enabled: true
6.2.2.4. Kafka チャネルの SASL 認証の設定
Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。
前提条件
- OpenShift Container Platform のクラスター管理者パーミッションがある。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafka
CRは OpenShift Container Platform クラスターにインストールされます。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Kafka クラスターのユーザー名およびパスワードがある。
-
使用する SASL メカニズムを選択している (例:
PLAIN
、SCRAM-SHA-256
、またはSCRAM-SHA-512
)。 -
TLS が有効にされている場合、Kafka クラスターの
ca.crt
証明書ファイルも必要になります。 -
OpenShift CLI (
oc
) をインストールしている。
手順
選択された namespace にシークレットとして証明書ファイルを作成します。
$ oc create secret -n <namespace> generic <kafka_auth_secret> \ --from-file=ca.crt=caroot.pem \ --from-literal=password="SecretPassword" \ --from-literal=saslType="SCRAM-SHA-512" \ --from-literal=user="my-sasl-user"
-
キー名に
ca.crt
、password
、およびsasl.mechanism
を使用します。これらの値は変更しないでください。 パブリック CA 証明書で SASL を使用する場合は、シークレットの作成時に
ca.crt
引数ではなくtls.enabled=true
フラグを使用する必要があります。以下は例になります。$ oc create secret -n <namespace> generic <kafka_auth_secret> \ --from-literal=tls.enabled=true \ --from-literal=password="SecretPassword" \ --from-literal=saslType="SCRAM-SHA-512" \ --from-literal=user="my-sasl-user"
-
キー名に
KnativeKafka
カスタムリソースの編集を開始します。$ oc edit knativekafka
シークレットおよびシークレットの namespace を参照します。
apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: channel: authSecretName: <kafka_auth_secret> authSecretNamespace: <kafka_auth_secret_namespace> bootstrapServers: <bootstrap_servers> enabled: true source: enabled: true
注記ブートストラップサーバーで一致するポートを指定するようにしてください。
以下は例になります。
apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: channel: authSecretName: scram-user authSecretNamespace: kafka bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9093 enabled: true source: enabled: true
6.2.3. 関連情報
6.3. Administrator パースペクティブの Serverless コンポーネント
OpenShift Container Platform Web コンソールの Developer パースペクティブに切り替えない場合や、Knative(kn
)CLI または YAML ファイルを使用する場合、OpenShift Container Platform Web コンソールの Administator パースペクティブを使用して Knative コンポーネントを作成できます。
6.3.1. Administrator パースペクティブを使用したサーバーレスアプリケーションの作成
サーバーレスアプリケーションは、ルートと設定で定義され、YAML ファイルに含まれる Kubernetes サービスとして作成およびデプロイされます。OpenShift Serverless を使用してサーバーレスアプリケーションをデプロイするには、Knative Service
オブジェクトを作成する必要があります。
Knative Service
オブジェクトの YAML ファイルの例
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello