Eventing
OpenShift Serverless でのイベント駆動型アーキテクチャーの使用
概要
第1章 Knative Eventing リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 上の Knative Eventing を使用すると、開発者はサーバーレスアプリケーションと共に イベント駆動型のアーキテクチャー を使用できます。イベント駆動型のアーキテクチャーは、イベントプロデューサーとイベントコンシューマー間の関係を切り離すという概念に基づいています。
イベントプロデューサーはイベントを作成し、イベントシンクまたはコンシューマーはイベントを受信します。Knative Eventing は、標準の HTTP POST リクエストを使用してイベントプロデューサーとシンク間でイベントを送受信します。これらのイベントは CloudEvents 仕様 に準拠しており、すべてのプログラミング言語でのイベントの作成、解析、および送受信を可能にします。
1.1. Knative Eventing ユースケース リンクのコピーリンクがクリップボードにコピーされました!
Knative Eventing は以下のユースケースをサポートします。
- コンシューマーを作成せずにイベントを公開する
- イベントを HTTP POST としてブローカーに送信し、バインディングを使用してイベントを生成するアプリケーションから宛先設定を分離できます。
- パブリッシャーを作成せずにイベントを消費
- Trigger を使用して、イベント属性に基づいて Broker からイベントを消費できます。アプリケーションはイベントを HTTP POST として受信します。
複数のタイプのシンクへの配信を有効にするために、Knative Eventing は複数の Kubernetes リソースで実装できる以下の汎用インターフェイスを定義します。
- アドレス指定可能なリソース
-
HTTP 経由でイベントの
status.address.urlフィールドに定義されるアドレスに配信されるイベントを受信し、確認することができます。KubernetesServiceリソースはアドレス指定可能なインターフェイスにも対応します。 - 呼び出し可能なリソース
-
HTTP 経由で配信されるイベントを受信し、これを変換できます。HTTP 応答ペイロードで
0または1の新規イベントを返します。返されるイベントは、外部イベントソースからのイベントが処理されるのと同じ方法で処理できます。
第2章 イベントソース リンクのコピーリンクがクリップボードにコピーされました!
2.1. イベントソース リンクのコピーリンクがクリップボードにコピーされました!
Knative イベントソース には、クラウドイベントの生成またはインポート、これらのイベントの別のエンドポイントへのリレー (sink とも呼ばれる) を行う Kubernetes オブジェクトを指定できます。イベントに対応する分散システムを開発するには、イベントのソースが重要になります。
OpenShift Container Platform Web コンソールの Developer パースペクティブ、Knative (kn) CLI を使用するか、YAML ファイルを適用することで、Knative イベントソースを作成および管理できます。
現時点で、OpenShift Serverless は以下のイベントソースタイプをサポートします。
- API サーバーソース
- Kubernetes API サーバーイベントを Knative に送ります。API サーバーソースは、Kubernetes リソースが作成、更新、または削除されるたびに新規イベントを送信します。
- Ping ソース
- 指定された cron スケジュールに、固定ペイロードを使用してイベントを生成します。
- Kafka イベントソース
- Apache Kafka クラスターをイベントソースとしてシンクに接続します。
カスタムイベントソース を作成することもできます。
2.2. Administrator パースペクティブのイベントソース リンクのコピーリンクがクリップボードにコピーされました!
イベントに対応する分散システムを開発するには、イベントのソースが重要になります。
2.2.1. Administrator パースペクティブを使用したイベントソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
Knative イベントソース には、クラウドイベントの生成またはインポート、これらのイベントの別のエンドポイントへのリレー (sink とも呼ばれる) を行う Kubernetes オブジェクトを指定できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Administrator パースペクティブを使用している。
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 Serverless → Eventing に移動します。
- Create リストで、Event Source を選択します。Event Sources ページに移動します。
- 作成するイベントソースタイプを選択します。
2.3. API サーバーソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
API サーバーソースは、Knative サービスなどのイベントシンクを Kubernetes API サーバーに接続するために使用できるイベントソースです。API サーバーソースは Kubernetes イベントを監視し、それらを Knative Eventing ブローカーに転送します。
2.3.1. Web コンソールを使用した API サーバーソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
Knative Eventing がクラスターにインストールされると、Web コンソールを使用して API サーバーソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェイスが提供されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。
既存のサービスアカウントを再利用する必要がある場合は、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Developer パースペクティブで、+Add → Event Source に移動します。Event Sources ページが表示されます。
- オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。
- ApiServerSource を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。
Form view または YAML view を使用して、ApiServerSource 設定を設定します。
注記Form view と YAML view 間で切り換えることができます。ビューの切り替え時に、データは永続化されます。
-
APIVERSION に
v1を、KIND にEventを入力します。 - 作成したサービスアカウントの Service Account Name を選択します。
Target セクションで、イベントシンクを選択します。これは Resource または URI のいずれかです。
- Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。
- URI を選択して、イベントのルーティング先となる URI (Uniform Resource Identifier) を指定します。
-
APIVERSION に
- Create をクリックします。
検証
API サーバーソースを作成したら、それを トポロジー ビューで表示して、イベントシンクに接続されていることを確認します。
URI シンクが使用される場合は、URI sink → Edit URI を右クリックして URI を変更します。
API サーバーソースの削除
- Topology ビューに移動します。
API サーバーソースを右クリックし、Delete ApiServerSource を選択します。
2.3.2. Knative CLI を使用した API サーバーソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
kn source apiserver create コマンドを使用し、kn CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。 -
Knative (
kn) CLI がインストールされている。
既存のサービスアカウントを再利用する必要がある場合は、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow イベントシンクを持つ API サーバーソースを作成します。次の例では、シンクはブローカーです。
kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode ResourceCopy to Clipboard Copied! Toggle word wrap Toggle overflow API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。
kn service create event-display --image quay.io/openshift-knative/showcase
$ kn service create event-display --image quay.io/openshift-knative/showcaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、
defaultのブローカーからサービスへのイベントをフィルタリングします。kn trigger create <trigger_name> --sink ksvc:event-display
$ kn trigger create <trigger_name> --sink ksvc:event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルト namespace で Pod を起動してイベントを作成します。
oc create deployment event-origin --image quay.io/openshift-knative/showcase
$ oc create deployment event-origin --image quay.io/openshift-knative/showcaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。
kn source apiserver describe <source_name>
$ kn source apiserver describe <source_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Kubernetes イベントが Knative に送信されたことを確認するには、イベント表示ログを確認するか、Web ブラウザーを使用してイベントを確認します。
Web ブラウザーでイベントを表示するには、次のコマンドで返されたリンクを開きます。
kn service describe event-display -o url
$ kn service describe event-display -o urlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 図2.1 ブラウザーページの例
あるいは、ターミナルでログを確認するには、次のコマンドを入力して Pod のイベント表示ログを表示します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
API サーバーソースの削除
トリガーを削除します。
kn trigger delete <trigger_name>
$ kn trigger delete <trigger_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow イベントソースを削除します。
kn source apiserver delete <source_name>
$ kn source apiserver delete <source_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
oc delete -f authentication.yaml
$ oc delete -f authentication.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.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 \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.localのsvcは、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channelおよびbrokerが含まれます。
2.3.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 CLI (
oc) がインストールされている。
既存のサービスアカウントを再利用する必要がある場合は、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow API サーバーソースを YAML ファイルとして作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ApiServerSourceYAML ファイルを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを YAML ファイルとして作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ServiceYAML ファイルを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 直接の手順で作成下サービスに、
defaultブローカーからイベントをフィルターするTriggerオブジェクトを YAML ファイルとして作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow TriggerYAML ファイルを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルト namespace で Pod を起動してイベントを作成します。
oc create deployment event-origin --image=quay.io/openshift-knative/showcase
$ oc create deployment event-origin --image=quay.io/openshift-knative/showcaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
oc get apiserversource.sources.knative.dev testevents -o yaml
$ oc get apiserversource.sources.knative.dev testevents -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Kubernetes イベントが Knative に送信されたことを確認するには、イベント表示ログを確認するか、Web ブラウザーを使用してイベントを確認してください。
Web ブラウザーでイベントを表示するには、次のコマンドで返されたリンクを開きます。
oc get ksvc event-display -o jsonpath='{.status.url}'$ oc get ksvc event-display -o jsonpath='{.status.url}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 図2.2 ブラウザーページの例
ターミナルでログを確認するには、次のコマンドを入力して Pod のイベント表示ログを表示します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
API サーバーソースの削除
トリガーを削除します。
oc delete -f trigger.yaml
$ oc delete -f trigger.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow イベントソースを削除します。
oc delete -f k8s-events.yaml
$ oc delete -f k8s-events.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
oc delete -f authentication.yaml
$ oc delete -f authentication.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. ping ソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
ping ソースは、一定のペイロードを使用して ping イベントをイベントコンシューマーに定期的に送信するために使用されるイベントソースです。ping ソースを使用すると、タイマーと同様にイベントの送信をスケジュールできます。
2.4.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 をコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Create をクリックします。
直前の手順で作成したサービスと同じ namespace、またはイベントの送信先となる他のシンクと同じ namespace に ping ソースを作成します。
- Developer パースペクティブで、+Add → Event Source に移動します。Event Sources ページが表示されます。
- オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。
Ping Source を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。
注記Form view または YAML view を使用して PingSource 設定を設定し、これらのビューを切り換えることができます。ビューの切り替え時に、データは永続化されます。
-
Schedule の値を入力します。この例では、値は
*/2 * * * *であり、2 分ごとにメッセージを送信する PingSource を作成します。 - オプション: Data の値を入力できます。これはメッセージのペイロードです。
Target セクションで、イベントシンクを選択します。これは Resource または URI のいずれかです。
-
Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。この例では、前の手順で作成した
event-displayサービスをターゲット Resource として使用します。 - URI を選択して、イベントのルーティング先となる URI (Uniform Resource Identifier) を指定します。
-
Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。この例では、前の手順で作成した
- Create をクリックします。
検証
Topology ページを表示して、ping ソースが作成され、シンクに接続されていることを確認できます。
- Developer パースペクティブで、Topology に移動します。
ping ソースおよびシンクを表示します。
イベント表示サービスを Web ブラウザーで表示します。Web UI に ping ソースイベントが表示されるはずです。
ping ソースの削除
- Topology ビューに移動します。
- API サーバーソースを右クリックし、Delete Ping Source を選択します。
2.4.2. Knative CLI を使用した ping ソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
kn source ping create コマンドを使用し、Knative (kn) CLI を使用して ping ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
オプション: この手順の検証手順を使用する場合は、OpenShift CLI (
oc) がインストールされている。
手順
ping ソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。
kn service create event-display \ --image quay.io/openshift-knative/showcase$ kn service create event-display \ --image quay.io/openshift-knative/showcaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要求する必要のある ping イベントのセットごとに、PingSource をイベントコンシューマーと同じ namespace に作成します。
kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display$ kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
kn source ping describe test-ping-source
$ kn source ping describe test-ping-sourceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。
デフォルトでは、Knative サービスは、60 秒以内にトラフィックを受信しないと Pod を終了します。このガイドの例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する ping ソースを作成します。
作成された新規 Pod を監視します。
watch oc get pods
$ watch oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ping ソースの削除
ping ソースを削除します。
kn delete pingsources.sources.knative.dev <ping_source_name>
$ kn delete pingsources.sources.knative.dev <ping_source_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.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 \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.localのsvcは、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channelおよびbrokerが含まれます。
2.4.3. YAML を使用した ping ソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
YAML ファイルを使用して Knative リソースを作成する場合は、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述できます。YAML を使用してサーバーレス ping を作成するには、PingSource オブジェクトを定義する YAML ファイルを作成し、oc apply を使用してこれを適用する必要があります。
PingSource オブジェクトの例
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
ping ソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。
サービス YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを作成します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
要求する必要のある ping イベントのセットごとに、ping ソースをイベントコンシューマーと同じ namespace に作成します。
ping ソースの YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ping ソースを作成します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを入力し、コントローラーが正しくマップされていることを確認します。
oc get pingsource.sources.knative.dev <ping_source_name> -oyaml
$ oc get pingsource.sources.knative.dev <ping_source_name> -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。
デフォルトでは、Knative サービスは、60 秒以内にトラフィックを受信しないと Pod を終了します。このガイドの例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する PingSource を作成します。
作成された新規 Pod を監視します。
watch oc get pods
$ watch oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ping ソースの削除
ping ソースを削除します。
oc delete -f <filename>
$ oc delete -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの例
oc delete -f ping-source.yaml
$ oc delete -f ping-source.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. Apache Kafka のソース リンクのコピーリンクがクリップボードにコピーされました!
Apache Kafka クラスターからイベントを読み取り、これらのイベントをシンクに渡す Apache Kafka ソースを作成できます。Kafka ソースを作成するには、OpenShift Container Platform Web コンソールの Knative (kn) CLI を使用するか、KafkaSource オブジェクトを YAML ファイルとして直接作成し、OpenShift CLI (oc) を使用して適用します。
Apache Kafka の Knative ブローカーのインストール を参照してください。
2.5.1. Web コンソールを使用した Apache Kafka イベントソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
Apache Kafka の Knative ブローカー実装がクラスターにインストールされたら、Web コンソールを使用して Apache 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 を選択します。
Target セクションで、イベントシンクを選択します。これは Resource または URI のいずれかです。
- Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。
- URI を選択して、イベントのルーティング先となる URI (Uniform Resource Identifier) を指定します。
- Kafka イベントソースの Name を入力します。
- Create をクリックします。
検証
Topology ページを表示して、Kafka イベントソースが作成され、シンクに接続されていることを確認できます。
- Developer パースペクティブで、Topology に移動します。
Kafka イベントソースおよびシンクを表示します。
2.5.2. Knative CLI を使用した Apache Kafka イベントソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
kn source kafka create コマンドを使用し、Knative (kn) CLI を使用して Kafka ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、Knative Serving、および
KnativeKafkaカスタムリソース (CR) がクラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
-
Knative (
kn) CLI がインストールされている。 -
オプション: この手順で検証ステップを使用する場合は、OpenShift CLI (
oc) をインストールしている。
手順
Kafka イベントソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする Knative サービスを作成します。
kn service create event-display \ --image quay.io/openshift-knative/showcase$ kn service create event-display \ --image quay.io/openshift-knative/showcaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow KafkaSourceCR を作成します。kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display$ kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このコマンドのプレースホルダー値は、ソース名、ブートストラップサーバー、およびトピックの値に置き換えます。
--servers、--topics、および--consumergroupオプションは、Kafka クラスターへの接続パラメーターを指定します。--consumergroupオプションは任意です。オプション: 作成した
KafkaSourceCR の詳細を表示します。kn source kafka describe <kafka_source_name>
$ kn source kafka describe <kafka_source_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
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$ 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-topicCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロンプトにメッセージを入力します。このコマンドは、以下を前提とします。
-
Kafka クラスターが
kafkanamespace にインストールされている。 -
KafkaSourceオブジェクトがmy-topicトピックを使用するように設定されている。
-
Kafka クラスターが
ログを表示して、メッセージが到達していることを確認します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.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 \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.localのsvcは、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channelおよびbrokerが含まれます。
2.5.3. YAML を使用した Apache 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 ファイルとして作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要OpenShift Serverless 上の
KafkaSourceオブジェクトの API のv1beta1バージョンのみがサポートされます。非推奨となったv1alpha1バージョンの API は使用しないでください。KafkaSourceオブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow KafkaSourceYAML ファイルを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを入力して、Kafka イベントソースが作成されたことを確認します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE kafkasource-kafka-source-5ca0248f-... 1/1 Running 0 13m
NAME READY STATUS RESTARTS AGE kafkasource-kafka-source-5ca0248f-... 1/1 Running 0 13mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.4. Apache Kafka ソースの SASL 認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。
前提条件
- OpenShift Container Platform でクラスターまたは専用の管理者パーミッションを持っている。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaCR は、OpenShift Container Platform クラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Kafka クラスターのユーザー名およびパスワードがある。
-
使用する SASL メカニズムを選択している (例:
PLAIN、SCRAM-SHA-256、またはSCRAM-SHA-512)。 -
TLS が有効になっている場合は、Kafka クラスターの
ca.crt証明書ファイルがある。 -
OpenShift (
oc) CLI がインストールされている。
手順
選択された 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"
$ 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" \1 --from-literal=user="my-sasl-user"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- SASL タイプは
PLAIN、SCRAM-SHA-256、またはSCRAM-SHA-512です。
Kafka ソースを作成または変更して、次の
spec設定が含まれるようにします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パブリッククラウドの Kafka サービスを使用している場合は、
caCert仕様は必要ありません。
2.6. カスタムイベントソース リンクのコピーリンクがクリップボードにコピーされました!
Knative に含まれていないイベントプロデューサーや、CloudEvent 形式ではないイベントを生成するプロデューサーからイベントを Ingress する必要がある場合は、カスタムイベントソースを使用してこれを実行できます。カスタムイベントソースは、次のいずれかの方法で作成できます。
-
シンクバインディングを作成して、
PodSpecableオブジェクトをイベントソースとして使用します。 - コンテナーソースを作成して、コンテナーをイベントソースとして使用します。
2.6.1. シンクバインディング リンクのコピーリンクがクリップボードにコピーされました!
SinkBinding オブジェクトは、イベント生成を配信アドレス指定から切り離すことをサポートします。シンクバインディングは、イベントプロデューサー をイベントコンシューマーまたは シンク に接続するために使用されます。イベントプロデューサーは、PodSpec テンプレートを組み込む Kubernetes リソースであり、イベントを生成します。シンクは、イベントを受信できるアドレス指定可能な Kubernetes オブジェクトです。
SinkBinding オブジェクトは、環境変数をシンクの PodTemplateSpec に挿入します。つまり、アプリケーションコードが Kubernetes API と直接対話してイベントの宛先を見つける必要はありません。これらの環境変数は以下のとおりです。
K_SINK- 解決されたシンクの URL。
K_CE_OVERRIDES- アウトバウンドイベントの上書きを指定する JSON オブジェクト。
現在、SinkBinding オブジェクトはサービスのカスタムリビジョン名をサポートしません。
2.6.1.1. YAML を使用したシンクバインディングの作成 リンクのコピーリンクがクリップボードにコピーされました!
YAML ファイルを使用して Knative リソースを作成する場合は、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述できます。YAML を使用してシンクバインディングを作成するには、SinkBinding オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
シンクバインディングが正しく設定されていることを確認するには、受信メッセージをダンプする Knative イベント表示サービスまたはイベントシンクを作成します。
サービス YAML ファイルを作成します。
サービス YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを作成します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
イベントをサービスに転送するシンクバインディングインスタンスを作成します。
シンクバインディング YAML ファイルを作成します。
サービス YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、ラベル
app: heartbeat-cronを指定したジョブがイベントシンクにバインドされます。
シンクバインディングを作成します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
CronJobオブジェクトを作成します。cron ジョブの YAML ファイルを作成します。
cron ジョブの YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要シンクバインディングを使用するには、
bindings.knative.dev/include=trueラベルを Knative リソースに手動で追加する必要があります。たとえば、このラベルを
CronJobインスタンスに追加するには、以下の行をJobリソースの YAML 定義に追加します。jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true"jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow cron ジョブを作成します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
oc get sinkbindings.sources.knative.dev bind-heartbeat -oyaml
$ oc get sinkbindings.sources.knative.dev bind-heartbeat -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative イベントシンクに送信されていることを確認できます。
コマンドを入力します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドを入力します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.1.2. Knative CLI を使用したシンクバインディングの作成 リンクのコピーリンクがクリップボードにコピーされました!
kn source binding create コマンドを使用し、Knative (kn) を使用してシンクバインディングを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
Knative (
kn) CLI をインストールしている。 -
OpenShift CLI (
oc) がインストールされている。
以下の手順では、YAML ファイルを作成する必要があります。
サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。
手順
シンクバインディングが正しく設定されていることを確認するには、受信メッセージをダンプする Knative イベント表示サービスまたはイベントシンクを作成します。
kn service create event-display --image quay.io/openshift-knative/showcase
$ kn service create event-display --image quay.io/openshift-knative/showcaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow イベントをサービスに転送するシンクバインディングインスタンスを作成します。
kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink ksvc:event-display
$ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink ksvc:event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow CronJobオブジェクトを作成します。cron ジョブの YAML ファイルを作成します。
cron ジョブの YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要シンクバインディングを使用するには、
bindings.knative.dev/include=trueラベルを Knative CR に手動で追加する必要があります。たとえば、このラベルを
CronJobCR に追加するには、以下の行をJobCR の YAML 定義に追加します。jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true"jobTemplate: metadata: labels: app: heartbeat-cron bindings.knative.dev/include: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow cron ジョブを作成します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
kn source binding describe bind-heartbeat
$ kn source binding describe bind-heartbeatCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative イベントシンクに送信されていることを確認できます。
以下のコマンドを入力して、メッセージダンパー機能ログを表示します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.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 \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.localのsvcは、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channelおよびbrokerが含まれます。
2.6.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 をコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Create をクリックします。
イベントソースとして使用される
CronJobリソースを作成し、1 分ごとにイベントを送信します。- Developer パースペクティブで、+Add → YAML に移動します。
サンプル YAML をコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
bindings.knative.dev/include: trueラベルを含めるようにしてください。OpenShift Serverless のデフォルトの namespace 選択動作は包含モードを使用します。
- Create をクリックします。
直前の手順で作成したサービスと同じ namespace、またはイベントの送信先となる他のシンクと同じ namespace にシンクバインディングを作成します。
- Developer パースペクティブで、+Add → Event Source に移動します。Event Sources ページが表示されます。
- オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。
Sink Binding を選択し、Create Event Source をクリックします。Create Event Source ページが表示されます。
注記Form view または YAML view を使用して Sink Binding 設定を設定し、ビューを切り替えることができます。ビューの切り替え時に、データは永続化されます。
-
apiVersion フィールドに
batch/v1を入力します。 Kind フィールドに
Jobと入力します。注記CronJobの種類は OpenShift Serverless シンクバインディングで直接サポートされていないため、Kind フィールドは cron ジョブオブジェクト自体ではなく、cron ジョブで作成されるJobオブジェクトをターゲットにする必要があります。Target セクションで、イベントシンクを選択します。これは Resource または URI のいずれかです。
-
Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。この例では、前の手順で作成した
event-displayサービスをターゲット Resource として使用します。 - URI を選択して、イベントのルーティング先となる URI (Uniform Resource Identifier) を指定します。
-
Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。この例では、前の手順で作成した
Match labels セクションで以下を実行します。
-
Name フィールドに
appと入力します。 Value フィールドに
heartbeat-cronと入力します。注記ラベルセレクターは、リソース名ではなくシンクバインディングで cron ジョブを使用する場合に必要になります。これは、cron ジョブで作成されたジョブには予測可能な名前がなく、名前に無作為に生成される文字列が含まれているためです。たとえば、
hearthbeat-cron-1cc23fになります。
-
Name フィールドに
- Create をクリックします。
検証
Topology ページおよび Pod ログを表示して、シンクバインディング、シンク、および cron ジョブが正常に作成され、機能していることを確認できます。
- Developer パースペクティブで、Topology に移動します。
シンクバインディング、シンク、およびハートビートの cron ジョブを表示します。
- シンクバインディングが追加されると、正常なジョブが cron ジョブによって登録されていることを確認します。つまり、シンクバインディングは cron ジョブで作成されたジョブが正常に再設定されることを意味します。
イベント表示サービスを参照して、ハートビート cron ジョブによって生成されたイベントを確認します。
2.6.1.4. シンクバインディング参照 リンクのコピーリンクがクリップボードにコピーされました!
シンクバインディングを作成して、PodSpecable オブジェクトをイベントソースとして使用できます。SinkBinding オブジェクトを作成するときに、複数のパラメーターを設定できます。
SinkBinding オブジェクトは以下のパラメーターをサポートします。
| フィールド | 説明 | 必須またはオプション |
|---|---|---|
|
|
API バージョンを指定します (例: | 必須 |
|
|
このリソースオブジェクトを | 必須 |
|
|
| 必須 |
|
|
この | 必須 |
|
| シンクとして使用する URI に解決するオブジェクトへの参照。 | 必須 |
|
| ランタイムコントラクトがバインディング実装によって拡張されるリソースを参照します。 | 必須 |
|
| 上書きを定義して、シンクに送信されたイベントへの出力形式および変更を制御します。 | オプション |
2.6.1.4.1. Subject パラメーター リンクのコピーリンクがクリップボードにコピーされました!
Subject パラメーターは、ランタイムコントラクトがバインディング実装によって拡張されるリソースを参照します。Subject 定義に複数のフィールドを設定できます。
Subject 定義は、以下のフィールドをサポートします。
| フィールド | 説明 | 必須またはオプション |
|---|---|---|
|
| 参照先の API バージョン。 | 必須 |
|
| 参照先の種類。 | 必須 |
|
| 参照先の namespace。省略されている場合、デフォルトはオブジェクトの namespace に設定されます。 | オプション |
|
| 参照先の名前。 |
|
|
| 参照先のセレクター。 |
|
|
| ラベルセレクターの要件のリストです。 |
|
|
| セレクターが適用されるラベルキー。 |
|
|
|
キーと値のセットの関係を表します。有効な演算子は |
|
|
|
文字列値の配列。 |
|
|
|
キーと値のペアのマップ。 |
|
サブジェクトパラメーターの例
以下の YAML の場合は、default namespace の mysubject という名前の Deployment オブジェクトが選択されます。
以下の YAML の場合は、default namespace にラベル working=example が設定された Job オブジェクトが選択されます。
以下の YAML の場合は、default namespace にラベル working=example または working=sample が含まれる Pod オブジェクトが選択されます。
2.6.1.4.2. CloudEvent オーバーライド リンクのコピーリンクがクリップボードにコピーされました!
ceOverrides 定義は、シンクに送信される CloudEvent の出力形式および変更を制御するオーバーライドを提供します。ceOverrides 定義に複数のフィールドを設定できます。
ceOverrides の定義は、以下のフィールドをサポートします。
| フィールド | 説明 | 必須またはオプション |
|---|---|---|
|
|
アウトバウンドイベントで追加または上書きされる属性を指定します。各 | オプション |
拡張子として許可されるのは、有効な CloudEvent 属性名のみです。拡張機能オーバーライド設定から仕様定義属性を設定することはできません。たとえば、type 属性を変更することはできません。
CloudEvent オーバーライドの例
これにより、subject に K_CE_OVERRIDES 環境変数が設定されます。
出力例
{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }
{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }
2.6.1.4.3. include ラベル リンクのコピーリンクがクリップボードにコピーされました!
シンクバインディングを使用するには、bindings.knative.dev/include: "true" ラベルをリソースまたはリソースが含まれる namespace のいずれかに割り当てる必要があります。リソース定義にラベルが含まれていない場合、クラスター管理者は以下を実行してこれを namespace に割り当てることができます。
oc label namespace <namespace> bindings.knative.dev/include=true
$ oc label namespace <namespace> bindings.knative.dev/include=true
2.6.1.5. Service Mesh とシンクバインディングの統合 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Service Mesh を OpenShift Serverless と統合しました。
手順
ServiceMeshMemberRollのメンバーである namespace にServiceを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Serviceリソースを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SinkBindingリソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SinkBindingリソースを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow CronJobを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow CronJobリソースを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
イベントが Knative イベントシンクに送信されたことを確認するには、メッセージダンパー機能のログを調べます。
以下のコマンドを入力します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.2. コンテナーソース リンクのコピーリンクがクリップボードにコピーされました!
コンテナーソースは、イベントを生成し、イベントをシンクに送信するコンテナーイメージを作成します。コンテナーソースを使用して、イメージ URI を使用するコンテナーイメージおよび ContainerSource オブジェクトを作成して、カスタムイベントソースを作成できます。
2.6.2.1. コンテナーイメージを作成するためのガイドライン リンクのコピーリンクがクリップボードにコピーされました!
コンテナーソースコントローラーには、K_SINK および K_CE_OVERRIDES の 2 つの環境変数が注入されます。これらの変数は、それぞれ sink および ceOverrides 仕様から解決されます。イベントは、K_SINK 環境変数で指定されたシンク URI に送信されます。メッセージは、CloudEvent HTTP 形式を使用して POST として送信する必要があります。
コンテナーイメージの例
以下は、ハートビートコンテナーイメージの例になります。
以下は、以前のハートビートコンテナーイメージを参照するコンテナーソースの例です。
2.6.2.2. Knative CLI を使用したコンテナーソースの作成および管理 リンクのコピーリンクがクリップボードにコピーされました!
kn source container コマンドを使用し、Knative (kn) CLI を使用してコンテナーソースを作成および管理できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。
コンテナーソースの作成
kn source container create <container_source_name> --image <image_uri> --sink <sink>
$ kn source container create <container_source_name> --image <image_uri> --sink <sink>
コンテナーソースの削除
kn source container delete <container_source_name>
$ kn source container delete <container_source_name>
コンテナーソースの記述
kn source container describe <container_source_name>
$ kn source container describe <container_source_name>
既存のコンテナーソースをリスト表示
kn source container list
$ kn source container list
既存のコンテナーソースを YAML 形式でリスト表示
kn source container list -o yaml
$ kn source container list -o yaml
コンテナーソースの更新
このコマンドにより、既存のコンテナーソースのイメージ URI が更新されます。
kn source container update <container_source_name> --image <image_uri>
$ kn source container update <container_source_name> --image <image_uri>
2.6.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 を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。
Form view または YAML view を使用して、Container Source 設定を設定します。
注記Form view と YAML view 間で切り換えることができます。ビューの切り替え時に、データは永続化されます。
- Image フィールドに、コンテナーソースが作成したコンテナーで実行するイメージの URI を入力します。
- Name フィールドにイメージの名前を入力します。
- オプション: Arguments フィールドで、コンテナーに渡す引数を入力します。
- オプション: Environment variables フィールドで、コンテナーに設定する環境変数を追加します。
Target セクションで、イベントシンクを選択します。これは Resource または URI のいずれかです。
- Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。
- URI を選択して、イベントのルーティング先となる URI (Uniform Resource Identifier) を指定します。
- コンテナーソースの設定が完了したら、Create をクリックします。
2.6.2.4. コンテナーソースのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
ContainerSource オブジェクトを作成することにより、コンテナーをイベントソースとして使用できます。ContainerSource オブジェクトを作成するときに、複数のパラメーターを設定できます。
ContainerSource オブジェクトは以下のフィールドをサポートします。
| フィールド | 説明 | 必須またはオプション |
|---|---|---|
|
|
API バージョンを指定します (例: | 必須 |
|
|
このリソースオブジェクトを | 必須 |
|
|
| 必須 |
|
|
この | 必須 |
|
| シンクとして使用する URI に解決するオブジェクトへの参照。 | 必須 |
|
|
| 必須 |
|
| 上書きを定義して、シンクに送信されたイベントへの出力形式および変更を制御します。 | オプション |
テンプレートパラメーターの例
2.6.2.4.1. CloudEvent オーバーライド リンクのコピーリンクがクリップボードにコピーされました!
ceOverrides 定義は、シンクに送信される CloudEvent の出力形式および変更を制御するオーバーライドを提供します。ceOverrides 定義に複数のフィールドを設定できます。
ceOverrides の定義は、以下のフィールドをサポートします。
| フィールド | 説明 | 必須またはオプション |
|---|---|---|
|
|
アウトバウンドイベントで追加または上書きされる属性を指定します。各 | オプション |
拡張子として許可されるのは、有効な CloudEvent 属性名のみです。拡張機能オーバーライド設定から仕様定義属性を設定することはできません。たとえば、type 属性を変更することはできません。
CloudEvent オーバーライドの例
これにより、subject に K_CE_OVERRIDES 環境変数が設定されます。
出力例
{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }
{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }
2.6.2.5. Service Mesh と ContainerSource の統合 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Service Mesh を OpenShift Serverless と統合しました。
手順
ServiceMeshMemberRollのメンバーである namespace にServiceを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Serviceリソースを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ServiceMeshMemberRollのメンバーである namespace にContainerSourceオブジェクトを作成し、event-displayに設定されたシンクを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ContainerSourceリソースを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
イベントが Knative イベントシンクに送信されたことを確認するには、メッセージダンパー機能のログを調べます。
以下のコマンドを入力します。
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7. 開発者パースペクティブを使用してイベントソースをイベントシンクに接続する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用してイベントソースを作成する場合は、イベントがソースから送信されるターゲットイベントシンクを指定できます。このイベントシンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
2.7.1. 開発者パースペクティブを使用してイベントソースをイベントシンクに接続する リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Developer パースペクティブを使用している。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Knative サービス、チャネル、ブローカーなどのイベントシンクを作成している。
手順
- +Add → Event Source に移動して任意のタイプのイベントソースを作成し、作成するイベントソースを選択します。
Create Event Source フォームビューの Target セクションで、イベントシンクを選択します。これは Resource または URI のいずれかです。
- Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。
- URI を選択して、イベントのルーティング先となる URI (Uniform Resource Identifier) を指定します。
- Create をクリックします。
検証
Topology ページを表示して、イベントソースが作成され、シンクに接続されていることを確認できます。
- Developer パースペクティブで、Topology に移動します。
- イベントソースを表示し、接続されたイベントシンクをクリックして、右側のパネルにシンクの詳細を表示します。
第3章 イベントシンク リンクのコピーリンクがクリップボードにコピーされました!
3.1. イベントシンク リンクのコピーリンクがクリップボードにコピーされました!
イベントソースの作成時に、イベントをソースに対して送信するイベントシンクを指定できます。イベントシンクは、他のリソースから受信イベントを受信できる、アドレス指定可能なリソースまたは呼び出し可能なリソースです。Knative サービス、チャネル、ブローカーはすべてイベントシンクの例です。また、特定の Apache Kafka シンクタイプも利用できます。
アドレス指定可能なオブジェクトは、HTTP 経由で status.address.url フィールドに定義されるアドレスに配信されるイベントを受信し、確認することができます。特別な場合として、コア Kubernetes Service オブジェクトはアドレス指定可能なインターフェイスにも対応します。
呼び出し可能なオブジェクトは、HTTP 経由で配信されるイベントを受信し、そのイベントを変換できます。HTTP 応答で 0 または 1 の新規イベントを返します。返されるイベントは、外部イベントソースからのイベントが処理されるのと同じ方法で処理できます。
3.1.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 \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.localのsvcは、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channelおよびbrokerが含まれます。
kn のカスタマイズ により、どの CR が Knative (kn) CLI コマンドの --sink フラグと併用できるかを設定できます。
3.2. イベントシンクの作成 リンクのコピーリンクがクリップボードにコピーされました!
イベントソースの作成時に、イベントをソースに対して送信するイベントシンクを指定できます。イベントシンクは、他のリソースから受信イベントを受信できる、アドレス指定可能なリソースまたは呼び出し可能なリソースです。Knative サービス、チャネル、ブローカーはすべてイベントシンクの例です。また、特定の Apache Kafka シンクタイプも利用できます。
イベントシンクとして使用できるリソースを作成する方法は、次のドキュメントを参照してください。
3.3. Apache Kafka のシンク リンクのコピーリンクがクリップボードにコピーされました!
Apache Kafka シンクは、クラスター管理者がクラスターで Apache Kafka を有効にした場合に使用できる イベントシンク の一種です。Kafka シンクを使用して、イベントソースから Kafka トピックにイベントを直接送信できます。
3.3.1. YAML を使用した Apache Kafka シンクの作成 リンクのコピーリンクがクリップボードにコピーされました!
イベントを Kafka トピックに送信する Kafka シンクを作成できます。デフォルトでは、Kafka シンクはバイナリーコンテンツモードを使用します。これは、構造化モードよりも効率的です。YAML を使用して Kafka シンクを作成するには、KafkaSink オブジェクトを定義する YAML ファイルを作成してから、ocapply コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Serving、および
KnativeKafkaカスタムリソース (CR) がクラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。
手順
KafkaSinkオブジェクト定義を YAML ファイルとして作成します。Kafka シンク YAML
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kafka シンクを作成するには、
KafkaSinkYAML ファイルを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow シンクが仕様で指定されるようにイベントソースを設定します。
API サーバーソースに接続された Kafka シンクの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.2. OpenShift Container Platform Web コンソールを使用した Apache Kafka のイベントシンクの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールの Developer パースペクティブを使用して、イベントを Kafka トピックに送信する Kafka シンクを作成できます。デフォルトでは、Kafka シンクはバイナリーコンテンツモードを使用します。これは、構造化モードよりも効率的です。
開発者は、イベントシンクを作成して、特定のソースからイベントを受信し、それを Kafka トピックに送信できます。
前提条件
- OperatorHub から、Knative Serving、Knative Eventing、および Apache Kafka API 用の Knative ブローカーを使用して OpenShift Serverless Operator をインストールしている。
- Kafka 環境で Kafka トピックを作成しました。
手順
- Developer パースペクティブで、+Add ビューに移動します。
- Eventing カタログ で Event Sink をクリックします。
-
カタログ項目で
KafkaSinkを検索してクリックします。 - イベントシンクの作成 をクリックします。
フォームビューで、ホスト名とポートの組み合わせであるブートストラップサーバーの URL を入力します。
- イベントデータを送信するトピックの名前を入力します。
- イベントシンクの名前を入力します。
- Create をクリックします。
検証
- Developer パースペクティブで、Topology ビューに移動します。
- 作成したイベントシンクをクリックして、右側のパネルに詳細を表示します。
3.3.3. Apache Kafka シンクのセキュリティーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。TLS は、Apache Kafka の Knative ブローカー実装でサポートされている唯一のトラフィック暗号化方式です。
Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaカスタムリソース (CR) が OpenShift Container Platform クラスターにインストールされている。 -
Kafka シンクが
KnativeKafkaCR で有効になっている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
.pemファイルとして Kafka クラスター CA 証明書が保存されている。 -
Kafka クラスタークライアント証明書とキーが
.pemファイルとして保存されている。 -
OpenShift (
oc) CLI がインストールされている。 -
使用する SASL メカニズムを選択している (例:
PLAIN、SCRAM-SHA-256、またはSCRAM-SHA-512)。
手順
KafkaSinkオブジェクトと同じ namespace に証明書ファイルをシークレットとして作成します。重要証明書とキーは PEM 形式である必要があります。
暗号化なしで SASL を使用した認証の場合:
oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SASL_PLAINTEXT \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-literal=user=<username> \ --from-literal=password=<password>
$ oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SASL_PLAINTEXT \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-literal=user=<username> \ --from-literal=password=<password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SASL を使用した認証と TLS を使用した暗号化の場合:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パブリッククラウドで管理される Kafka サービスを使用している場合は、
ca.crtを省略してシステムのルート CA セットを使用できます。
TLS を使用した認証と暗号化の場合:
oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SSL \ --from-file=ca.crt=<my_caroot.pem_file_path> \ --from-file=user.crt=<my_cert.pem_file_path> \ --from-file=user.key=<my_key.pem_file_path>
$ oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SSL \ --from-file=ca.crt=<my_caroot.pem_file_path> \1 --from-file=user.crt=<my_cert.pem_file_path> \ --from-file=user.key=<my_key.pem_file_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パブリッククラウドで管理される Kafka サービスを使用している場合は、
ca.crtを省略してシステムのルート CA セットを使用できます。
KafkaSinkオブジェクトを作成または変更し、auth仕様にシークレットへの参照を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow KafkaSinkオブジェクトを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 ブローカー リンクのコピーリンクがクリップボードにコピーされました!
4.1. ブローカー リンクのコピーリンクがクリップボードにコピーされました!
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性 でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。
4.2. ブローカータイプ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのデフォルトブローカー実装を設定できます。ブローカーを作成する場合は、Broker オブジェクトで設定を指定しない限り、デフォルトのブローカー実装が使用されます。
4.2.1. 開発目的でのデフォルトブローカーの実装 リンクのコピーリンクがクリップボードにコピーされました!
Knative は、デフォルトのチャネルベースのブローカー実装を提供します。このチャネルベースのブローカーは、開発およびテストの目的で使用できますが、実稼働環境での適切なイベント配信の保証は提供しません。デフォルトのブローカーは、デフォルトで InMemoryChannel チャネル実装によってサポートされています。
Apache Kafka を使用してネットワークホップを削減する場合は、Apache Kafka の Knative ブローカー実装を使用します。チャネルベースのブローカーが KafkaChannel チャネル実装によってサポートされるように設定しないでください。
4.2.2. Apache Kafka の実稼働環境対応の Knative ブローカー実装 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境対応の Knative Eventing デプロイメントの場合、Red Hat は Apache Kafka に Knative ブローカー実装を使用することを推奨します。ブローカーは、Knative ブローカーの Apache Kafka ネイティブ実装であり、CloudEvents を Kafka インスタンスに直接送信します。
Kafka ブローカーは、イベントを保存してルーティングできるように Kafka とネイティブに統合されています。これにより、他のブローカータイプよりもブローカーとトリガーモデルの Kafka との統合性が向上し、ネットワークホップを削減することができます。Knative ブローカー実装のその他の利点は次のとおりです。
- 少なくとも 1 回の配信保証
- CloudEvents パーティショニング拡張機能に基づくイベントの順序付き配信
- コントロールプレーンの高可用性
- 水平方向にスケーラブルなデータプレーン
Apache Kafka の Knative ブローカー実装は、バイナリーコンテンツモードを使用して、受信した CloudEvent を Kafka レコードとして保存します。これは、CloudEvent のすべての属性と拡張機能が Kafka レコードのヘッダーとしてマップされ、CloudEvent の data 仕様が Kafka レコードの値に対応することを意味します。
4.3. ブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
Knative は、デフォルトのチャネルベースのブローカー実装を提供します。このチャネルベースのブローカーは、開発およびテストの目的で使用できますが、実稼働環境での適切なイベント配信の保証は提供しません。
クラスター管理者がデフォルトのブローカータイプとして Apache Kafka を使用するように OpenShift サーバーレスデプロイメントを設定している場合は、デフォルト設定を使用してブローカーを作成すると、Apache Kafka の Knative ブローカーが作成されます。
OpenShift Serverless デプロイメントが Apache Kafka の Kafka ブローカーをデフォルトのブローカータイプとして使用するように設定されていない場合は、以下の手順でデフォルト設定を使用すると、チャネルベースのブローカーが作成されます。
4.3.1. Knative CLI を使用したブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。ブローカーを作成するために Knative (kn) CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。kn broker create コマンドを使用して、ブローカーを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
ブローカーを作成します。
kn broker create <broker_name>
$ kn broker create <broker_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
knコマンドを使用して、既存のブローカーをリスト表示します。kn broker list
$ kn broker listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 True
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: OpenShift Container Platform Web コンソールを使用している場合は、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。
4.3.2. トリガーのアノテーションによるブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。eventing.knative.dev/injection: enabled アノテーションを Trigger オブジェクトに追加してブローカーを作成できます。
knative-eventing-injection: enabled アノテーションを使用してブローカーを作成する場合は、クラスター管理者パーミッションがなければこのブローカーを削除することができません。クラスター管理者が最初にこのアノテーションを削除せずにブローカーを削除すると、削除後にブローカーが再び作成されます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Triggerオブジェクトを、eventing.knative.dev/injection: enabledアノテーションを付けて YAML ファイルとして作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- トリガーがイベントを送信するイベントシンクまたは サブスクライバー の詳細を指定します。
TriggerYAML ファイルを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
oc CLI を使用してブローカーが正常に作成されていることを確認するか、または Web コンソールの Topology ビューでこれを確認できます。
以下の
ocコマンドを入力してブローカーを取得します。oc -n <namespace> get broker default
$ oc -n <namespace> get broker defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56s
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56sCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: OpenShift Container Platform Web コンソールを使用している場合は、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。
4.3.3. namespace へのラベル付けによるブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。所有しているか、または書き込みパーミッションのある namespace にラベルを付けて default ブローカーを自動的に作成できます。
この方法を使用して作成されたブローカーは、ラベルを削除すると削除されません。これらは手動で削除する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Red Hat OpenShift Service on AWS または OpenShift Dedicated を使用している場合は、クラスターまたは Dedicated 管理者権限が割り当てられている。
手順
eventing.knative.dev/injection=enabledで namespace にラベルを付ける。oc label namespace <namespace> eventing.knative.dev/injection=enabled
$ oc label namespace <namespace> eventing.knative.dev/injection=enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
oc CLI を使用してブローカーが正常に作成されていることを確認するか、または Web コンソールの Topology ビューでこれを確認できます。
ocコマンドを使用してブローカーを取得します。oc -n <namespace> get broker <broker_name>
$ oc -n <namespace> get broker <broker_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの例
oc -n default get broker default
$ oc -n default get broker defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56s
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56sCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: OpenShift Container Platform Web コンソールを使用している場合は、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。
4.3.4. 挿入 (injection) によって作成されたブローカーの削除 リンクのコピーリンクがクリップボードにコピーされました!
挿入によりブローカーを作成し、後でそれを削除する必要がある場合は、手動で削除する必要があります。namespace ラベルまたはトリガーアノテーションを使用して作成されたブローカーは、ラベルまたはアノテーションを削除した場合に永続的に削除されません。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
eventing.knative.dev/injection=enabledラベルを namespace から削除します。oc label namespace <namespace> eventing.knative.dev/injection-
$ oc label namespace <namespace> eventing.knative.dev/injection-Copy to Clipboard Copied! Toggle word wrap Toggle overflow アノテーションを削除すると、Knative では削除後にブローカーを再作成できなくなります。
選択された namespace からブローカーを削除します。
oc -n <namespace> delete broker <broker_name>
$ oc -n <namespace> delete broker <broker_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
ocコマンドを使用してブローカーを取得します。oc -n <namespace> get broker <broker_name>
$ oc -n <namespace> get broker <broker_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの例
oc -n default get broker default
$ oc -n default get broker defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resources found. Error from server (NotFound): brokers.eventing.knative.dev "default" not found
No resources found. Error from server (NotFound): brokers.eventing.knative.dev "default" not foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.5. Web コンソールを使用してブローカーを作成する リンクのコピーリンクがクリップボードにコピーされました!
Knative Eventing がクラスターにインストールされた後、Web コンソールを使用してブローカーを作成できます。OpenShift Container Platform Web コンソールを使用すると、ブローカーを作成するための合理的で直感的なユーザーインターフェイスが提供されます。
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
- Developer パースペクティブで、+Add → Broker に移動します。Broker ページが表示されます。
-
オプション:ブローカーの Name を更新します。名前を更新しないと、生成されたブローカーの名前は
defaultになります。 - Create をクリックします。
検証
トポロジー ページでブローカーコンポーネントを表示することにより、ブローカーが作成されたことを確認できます。
- Developer パースペクティブで、Topology に移動します。
mt-broker-ingress、mt-broker-filter、およびmt-broker-controllerコンポーネントを表示します。
4.3.6. Administrator パースペクティブを使用したブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性 でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Administrator パースペクティブを使用している。
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 Serverless → Eventing に移動します。
- Create リストで、Broker を選択します。Create Broker ページに移動します。
- オプション: ブローカーの YAML 設定を変更します。
- Create をクリックします。
4.3.7. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- イベントがイベントシンクに配信されなかった場合に適用される イベント配信パラメーター を設定します。
4.4. デフォルトのブローカーバッキングチャネルの設定 リンクのコピーリンクがクリップボードにコピーされました!
チャネルベースのブローカーを使用している場合は、ブローカーのデフォルトのバッキングチャネルタイプを InMemoryChannel または KafkaChannel に設定できます。
前提条件
- OpenShift Container Platform に対する管理者権限を持っている。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
OpenShift (
oc) CLI がインストールされている。 -
Apache Kafka チャネルをデフォルトのバッキングチャネルタイプとして使用する場合は、クラスターに
KnativeKafkaCR もインストールしている。
手順
KnativeEventingカスタムリソース (CR) を変更して、config-br-default-channelConfig Map の設定の詳細を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新された
KnativeEventingCR を適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. デフォルトブローカークラスの設定 リンクのコピーリンクがクリップボードにコピーされました!
config-br-defaults Config Map を使用して、Knative Eventing のデフォルトのブローカークラス設定を指定できます。クラスター全体または 1 つ以上の namespace に対して、デフォルトのブローカークラスを指定できます。現在、MTChannelBasedBroker および Kafka ブローカータイプがサポートされています。
前提条件
- OpenShift Container Platform に対する管理者権限を持っている。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Apache Kafka の Knative ブローカーをデフォルトのブローカー実装として使用する場合は、クラスターに
KnativeKafkaCR もインストールしている。
手順
KnativeEventingカスタムリソースを変更して、config-br-defaultsConfig Map の設定の詳細を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Knative Eventing のデフォルトのブローカークラス。
- 2
spec.configで、変更した設定を追加する Config Map を指定できます。- 3
config-br-defaultsConfig Map は、spec.config設定またはブローカークラスを指定しないブローカーのデフォルト設定を指定します。- 4
- クラスター全体のデフォルトのブローカークラス設定。この例では、クラスターのデフォルトのブローカークラスの実装は
Kafkaです。 - 5
kafka-broker-configConfig Map は、Kafka ブローカーのデフォルト設定を指定します。関連情報セクションの Apache Kafka 設定用の Knative ブローカーの設定を参照してください。- 6
kafka-broker-configConfig Map が存在する namespace。- 7
- namespace スコープのデフォルトブローカクラス設定。この例では、
my-namespacenamespace のデフォルトのブローカークラスの実装はMTChannelBasedBrokerです。複数の namespace に対してデフォルトのブローカークラスの実装を指定できます。 - 8
config-br-default-channelConfig Map は、ブローカーのデフォルトのバッキングチャネルを指定します。「関連情報」セクションの「デフォルトのブローカーバッキングチャネルの設定」を参照してください。- 9
config-br-default-channelConfig Map が存在する namespace。
重要namespace 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。
4.6. Apache Kafka の Knative ブローカー実装 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境対応の Knative Eventing デプロイメントの場合、Red Hat は Apache Kafka に Knative ブローカー実装を使用することを推奨します。ブローカーは、Knative ブローカーの Apache Kafka ネイティブ実装であり、CloudEvents を Kafka インスタンスに直接送信します。
Kafka ブローカーは、イベントを保存してルーティングできるように Kafka とネイティブに統合されています。これにより、他のブローカータイプよりもブローカーとトリガーモデルの Kafka との統合性が向上し、ネットワークホップを削減することができます。Knative ブローカー実装のその他の利点は次のとおりです。
- 少なくとも 1 回の配信保証
- CloudEvents パーティショニング拡張機能に基づくイベントの順序付き配信
- コントロールプレーンの高可用性
- 水平方向にスケーラブルなデータプレーン
Apache Kafka の Knative ブローカー実装は、バイナリーコンテンツモードを使用して、受信した CloudEvent を Kafka レコードとして保存します。これは、CloudEvent のすべての属性と拡張機能が Kafka レコードのヘッダーとしてマップされ、CloudEvent の data 仕様が Kafka レコードの値に対応することを意味します。
4.6.1. デフォルトのブローカータイプとして設定されていない場合の Apache Kafka ブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless デプロイメントがデフォルトのブローカータイプとして Kafka ブローカーを使用するように設定されていない場合は、以下の手順のいずれかを使用して、Kafka ベースのブローカーを作成できます。
4.6.1.1. YAML を使用した Apache Kafka ブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
YAML ファイルを使用して Knative リソースを作成する場合は、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述できます。YAML を使用して Kafka ブローカーを作成するには、Broker オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaカスタムリソースが OpenShift Container Platform クラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。
手順
Kafka ベースのブローカーを YAML ファイルとして作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kafka ベースのブローカー YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.1.2. 外部で管理される Kafka トピックを使用する Apache 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 CLI (
oc) がインストールされている。
手順
Kafka ベースのブローカーを YAML ファイルとして作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kafka ベースのブローカー YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.1.3. 分離されたデータプレーンのある Apache Kafka の Knative Broker 実装 リンクのコピーリンクがクリップボードにコピーされました!
分離されたデータプレーンを使用した Apache Kafka の Knative Broker 実装は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Apache Kafka の Knative Broker 実装には 2 つのプレーンがあります。
- コントロールプレーン
- Kubernetes API と通信し、カスタムオブジェクトを監視し、データプレーンを管理するコントローラーで設定されます。
- データプレーン
-
受信イベントをリッスンし、Apache Kafka と通信し、イベントをイベントシンクに送信するコンポーネントのコレクション。Apache Kafka データプレーンの Knative Broker 実装は、イベントが送信される場所です。この実装は、
kafka-broker-receiverおよびkafka-broker-dispatcherデプロイメントで設定されます。
Kafka の Broker クラスを設定する場合、Apache Kafka の Knative Broker 実装は共有データプレーンを使用します。つまり、knative-eventing namespace の kafka-broker-receiver および kafka-broker-dispatcher デプロイメントがクラスター内のすべての Apache Kafka Broker に使用されます。
ただし、KafkaNamespaced の Broker クラスを設定すると、Apache Kafka ブローカーコントローラーは、ブローカーが存在する namespace ごとに新しいデータプレーンを作成します。このデータプレーンは、その namespace のすべての KafkaNamespaced ブローカーによって使用されます。これにより、データプレーンが分離されるため、ユーザーの namespace の kafka-broker-receiver および kafka-broker-dispatcher デプロイメントは、その namespace のブローカーに対してのみ使用されます。
データプレーンを分離した結果、このセキュリティー機能はより多くのデプロイメントを作成し、より多くのリソースを使用します。このような分離要件がない限り、Kafka のクラスで 通常 の Broker を使用します。
4.6.1.4. 分離されたデータプレーンを使用する Apache Kafka の Knative ブローカーの作成 リンクのコピーリンクがクリップボードにコピーされました!
分離されたデータプレーンを使用した Apache Kafka の Knative Broker 実装は、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
KafkaNamespaced ブローカーを作成するには、eventing.knative.dev/broker.class アノテーションを KafkaNamespaced に設定する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaカスタムリソースが OpenShift Container Platform クラスターにインストールされている。 - Red Hat AMQ Streams などの Apache Kafka インスタンスにアクセスでき、Kafka トピックを作成している。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。
手順
YAML ファイルを使用して Apache Kafka ベースのブローカーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apache Kafka ベースのブローカー YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.config の ConfigMap オブジェクトは Broker オブジェクトと同じ namespace にある必要があります。
KafkaNamespaced クラスで最初の Broker オブジェクトを作成すると、kafka-broker-receiver および kafka-broker-dispatcher デプロイメントが namespace に作成されます。その後、同じ namespace 内で KafkaNamespaced クラスが含まれる全ブローカーにより、同じデータプレーンが使用されます。KafkaNamespaced クラスを持つブローカーが namespace に存在しない場合は、namespace のデータプレーンが削除されます。
4.6.2. Apache Kafka ブローカー設定 リンクのコピーリンクがクリップボードにコピーされました!
Config Map を作成し、Kafka Broker オブジェクトでこの ConfigMap を参照することで、レプリケーション係数、ブートストラップサーバー、および Kafka ブローカーのトピックパーティションの数を設定できます。
前提条件
- OpenShift Container Platform でクラスターまたは専用の管理者パーミッションを持っている。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaカスタムリソース (CR) が OpenShift Container Platform クラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。
手順
kafka-broker-configConfigMap を変更するか、以下の設定が含まれる独自の ConfigMap を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ConfigMap 名。
- 2
- ConfigMap が存在する namespace。
- 3
- Kafka ブローカーのトピックパーティションの数。これは、イベントをブローカーに送信する速度を制御します。パーティションが多い場合には、コンピュートリソースが多く必要です。
- 4
- トピックメッセージのレプリケーション係数。これにより、データ損失を防ぐことができます。レプリケーション係数を増やすには、より多くのコンピュートリソースとストレージが必要になります。
- 5
- ブートストラップサーバーのコンマ区切りリスト。これは、OpenShift Container Platform クラスターの内部または外部にある可能性があり、ブローカーがイベントを受信してイベントを送信する Kafka クラスターのリストです。
重要default.topic.replication.factorの値は、クラスター内の Kafka ブローカーインスタンスの数以下である必要があります。たとえば、Kafka ブローカーが 1 つしかない場合、default.topic.replication.factorの値は"1"より大きな値にすることはできません。Kafka ブローカーの ConfigMap の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ConfigMap を適用します。
$ oc apply -f <config_map_filename>
$ oc apply -f <config_map_filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kafka
Brokerオブジェクトの ConfigMap を指定します。Broker オブジェクトの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブローカーを適用します。
$ oc apply -f <broker_filename>
$ oc apply -f <broker_filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.3. Apache Kafka の Knative ブローカー実装のセキュリティー設定 リンクのコピーリンクがクリップボードにコピーされました!
Kafka クラスターは、通常、TLS または SASL 認証方法を使用して保護されます。TLS または SASL を使用して、保護された Red Hat AMQ Streams クラスターに対して動作するように Kafka ブローカーまたはチャネルを設定できます。
Red Hat は、SASL と TLS の両方を一緒に有効にすることを推奨します。
4.6.3.1. Apache Kafka ブローカーの TLS 認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。TLS は、Apache Kafka の Knative ブローカー実装でサポートされている唯一のトラフィック暗号化方式です。
前提条件
- OpenShift Container Platform でクラスターまたは専用の管理者パーミッションを持っている。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaCR は、OpenShift Container Platform クラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
.pemファイルとして Kafka クラスター CA 証明書が保存されている。 -
Kafka クラスタークライアント証明書とキーが
.pemファイルとして保存されている。 -
OpenShift CLI (
oc) がインストールされている。
手順
証明書ファイルを
knative-eventingnamespace にシークレットファイルとして作成します。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
$ 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.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要キー名に
ca.crt、user.crt、およびuser.keyを使用します。これらの値は変更しないでください。KnativeKafkaCR を編集し、broker仕様にシークレットへの参照を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.3.2. Apache Kafka ブローカーの SASL 認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。
前提条件
- OpenShift Container Platform でクラスターまたは専用の管理者パーミッションを持っている。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaCR は、OpenShift Container Platform クラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Kafka クラスターのユーザー名およびパスワードがある。
-
使用する SASL メカニズムを選択している (例:
PLAIN、SCRAM-SHA-256、またはSCRAM-SHA-512)。 -
TLS が有効になっている場合は、Kafka クラスターの
ca.crt証明書ファイルがある。 -
OpenShift CLI (
oc) がインストールされている。
手順
証明書ファイルを
knative-eventingnamespace にシークレットファイルとして作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
キー名に
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"
$ 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"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
キー名に
KnativeKafkaCR を編集し、broker仕様にシークレットへの参照を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7. ブローカーの管理 リンクのコピーリンクがクリップボードにコピーされました!
ブローカーを作成した後、Knative (kn) CLI コマンドを使用するか、OpenShift Container Platform Web コンソールでブローカーを変更することで、ブローカーを管理できます。
4.7.1. CLI を使用したブローカーの管理 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI は、既存のブローカーを記述およびリストするために使用できるコマンドを提供します。
4.7.1.1. Knative CLI を使用した既存ブローカーの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用してブローカーをリスト表示すると、合理的で直感的なユーザーインターフェイスが提供されます。kn broker list コマンドを使用し、Knative CLI を使用してクラスター内の既存ブローカーをリスト表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。
手順
既存ブローカーのリストを表示します。
kn broker list
$ kn broker listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 True
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.1.2. Knative CLI を使用した既存ブローカーの記述 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用してブローカーを記述すると、合理的で直感的なユーザーインターフェイスが提供されます。kn broker describe コマンドを使用し、Knative CLI を使用してクラスター内の既存ブローカーに関する情報を出力できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。
手順
既存ブローカーを記述します。
kn broker describe <broker_name>
$ kn broker describe <broker_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトブローカーを使用したコマンドの例
kn broker describe default
$ kn broker describe defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.2. 開発者パースペクティブを使用してブローカーをシンクに接続する リンクのコピーリンクがクリップボードにコピーされました!
トリガーを作成することで、OpenShift Container Platform Developer パースペクティブでブローカーをイベントシンクに接続できます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Developer パースペクティブを使用している。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Knative サービスやチャネルなどのシンクを作成しました。
- ブローカーを作成している。
手順
- Topology ビューで、作成したブローカーをポイントします。矢印が表示されます。矢印をブローカーに接続するシンクにドラッグします。この操作により、Add Trigger ダイアログボックスが開きます。
- Add Trigger ダイアログボックスで、トリガーの名前を入力し、Add をクリックします。
検証
Topology ページを表示すると、ブローカーがシンクに接続されていることを確認できます。
- Developer パースペクティブで、Topology に移動します。
- ブローカーをシンクに接続する線をクリックすると、Details パネルでトリガーの詳細が表示されます。
第5章 トリガー リンクのコピーリンクがクリップボードにコピーされました!
5.1. トリガーの概要 リンクのコピーリンクがクリップボードにコピーされました!
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性 でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。
Apache Kafka の Knative ブローカーを使用している場合は、トリガーからイベントシンクへのイベントの配信順序を設定できます。トリガーのイベント配信順序の設定 を参照してください。
5.1.1. トリガーのイベント配信順序の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kafka ブローカーを使用している場合は、トリガーからイベントシンクへのイベントの配信順序を設定できます。
前提条件
- OpenShift Serverless Operator、Knative Eventing、および Knative Kafka が OpenShift Container Platform クラスターにインストールされている。
- Kafka ブローカーがクラスターで使用可能であり、Kafka ブローカーが作成されている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc) CLI がインストールされている。
手順
Triggerオブジェクトを作成または変更し、kafka.eventing.knative.dev/delivery.orderアノテーションを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サポートされているコンシューマー配信保証は次のとおりです。
unordered- 順序付けられていないコンシューマーは、適切なオフセット管理を維持しながら、メッセージを順序付けずに配信するノンブロッキングコンシューマーです。
ordered順序付きコンシューマーは、CloudEvent サブスクライバーからの正常な応答を待ってから、パーティションの次のメッセージを配信する、パーティションごとのブロックコンシューマーです。
デフォルトの順序保証は
unorderedです。
Triggerオブジェクトを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- イベントがイベントシンクに配信されなかった場合に適用される イベント配信パラメーター を設定します。
5.2. トリガーの作成 リンクのコピーリンクがクリップボードにコピーされました!
ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性 でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。
5.2.1. Administrator パースペクティブを使用したトリガーの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用すると、トリガーを作成するための合理的で直感的なユーザーインターフェイスが提供されます。Knative Eventing がクラスターにインストールされ、ブローカーが作成されると、Web コンソールを使用してトリガーを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Administrator パースペクティブを使用している。
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- Knative ブローカーを作成している。
- サブスクライバーとして使用する Knative サービスを作成している。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 Serverless → Eventing に移動します。
-
Broker タブで、トリガーを追加するブローカーの Options メニュー
を選択します。
- リストで Add Trigger をクリックします。
- Add Trigger のダイアログボックスで、Trigger の Subscriber を選択します。サブスクライバーは、ブローカーからイベントを受信する Knative サービスです。
- Add をクリックします。
5.2.2. 開発者パースペクティブを使用したトリガーの作成 リンクのコピーリンクがクリップボードにコピーされました!
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.2.3. Knative CLI を使用したトリガーの作成 リンクのコピーリンクがクリップボードにコピーされました!
kn trigger create コマンドを使用して、トリガーを作成できます。
前提条件
- 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>
$ kn trigger create <trigger_name> --broker <broker_name> --filter <key=value> --sink <sink_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、トリガーを作成し、ブローカー挿入を使用して
defaultブローカーを同時に作成できます。kn trigger create <trigger_name> --inject-broker --filter <key=value> --sink <sink_name>
$ kn trigger create <trigger_name> --inject-broker --filter <key=value> --sink <sink_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトで、トリガーはブローカーに送信されたすべてのイベントを、そのブローカーにサブスクライブされるシンクに転送します。トリガーの
--filter属性を使用すると、ブローカーからイベントをフィルターできるため、サブスクライバーは定義された基準に基づくイベントのサブセットのみを受け取ることができます。
5.3. コマンドラインからのトリガーの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用してトリガーをリスト表示すると、合理的で直感的なユーザーインターフェイスが提供されます。
5.3.1. Knative CLI の使用によるトリガーの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
kn trigger list コマンドを使用して、クラスター内の既存トリガーを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。
手順
利用可能なトリガーのリストを出力します。
kn trigger list
$ kn trigger listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
NAME BROKER SINK AGE CONDITIONS READY REASON email default ksvc:edisplay 4s 5 OK / 5 True ping default ksvc:edisplay 32s 5 OK / 5 TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: JSON 形式でトリガーの一覧を出力します。
kn trigger list -o json
$ kn trigger list -o jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. コマンドラインからのトリガーの説明 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用してトリガーを記述すると、合理的で直感的なユーザーインターフェイスが提供されます。
5.4.1. Knative CLI を使用したトリガーの記述 リンクのコピーリンクがクリップボードにコピーされました!
kn trigger describe コマンドを使用し、Knative CLI を使用してクラスター内の既存トリガーに関する情報を出力できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。 - トリガーを作成している。
手順
コマンドを入力します。
kn trigger describe <trigger_name>
$ kn trigger describe <trigger_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. トリガーのシンクへの接続 リンクのコピーリンクがクリップボードにコピーされました!
トリガーをシンクに接続して、シンクへの送信前にブローカーからのイベントがフィルターされるようにします。トリガーに接続されているシンクは、Trigger オブジェクトのリソース仕様で subscriber として設定されます。
Apache Kafka シンクに接続された Trigger オブジェクトの例
5.6. コマンドラインからのトリガーのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用してイベントをフィルタリングすると、合理的で直感的なユーザーインターフェイスが提供されます。kn trigger create コマンドを適切なフラグとともに使用し、トリガーを使用してイベントをフィルタリングできます。
5.6.1. Knative CLI を使用したトリガーでのイベントのフィルター リンクのコピーリンクがクリップボードにコピーされました!
以下のトリガーの例では、type: dev.knative.samples.helloworld 属性のイベントのみがイベントシンクに送付されます。
kn trigger create <trigger_name> --broker <broker_name> --filter type=dev.knative.samples.helloworld --sink ksvc:<service_name>
$ 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
$ 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.7. コマンドラインからのトリガーの更新 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用してトリガーを更新すると、合理的で直感的なユーザーインターフェイスが提供されます。
5.7.1. Knative 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]
$ kn trigger update <trigger_name> --filter <key=value> --sink <sink_name> [flags]Copy to Clipboard Copied! Toggle word wrap Toggle overflow トリガーを、受信イベントに一致するイベント属性をフィルターするように更新できます。たとえば、
type属性を使用します。kn trigger update <trigger_name> --filter type=knative.dev.event
$ kn trigger update <trigger_name> --filter type=knative.dev.eventCopy to Clipboard Copied! Toggle word wrap Toggle overflow トリガーからフィルター属性を削除できます。たとえば、キー
typeを使用してフィルター属性を削除できます。kn trigger update <trigger_name> --filter type-
$ kn trigger update <trigger_name> --filter type-Copy to Clipboard Copied! Toggle word wrap Toggle overflow --sinkパラメーターを使用して、トリガーのイベントシンクを変更できます。kn trigger update <trigger_name> --sink ksvc:my-event-sink
$ kn trigger update <trigger_name> --sink ksvc:my-event-sinkCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8. コマンドラインからのトリガーの削除 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用してトリガーを削除すると、合理的で直感的なユーザーインターフェイスが提供されます。
5.8.1. Knative 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 delete <trigger_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
既存のトリガーをリスト表示します。
kn trigger list
$ kn trigger listCopy to Clipboard Copied! Toggle word wrap Toggle overflow トリガーが存在しないことを確認します。
出力例
No triggers found.
No triggers found.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 チャネル リンクのコピーリンクがクリップボードにコピーされました!
6.1. チャネルおよびサブスクリプション リンクのコピーリンクがクリップボードにコピーされました!
チャネルは、単一のイベント転送および永続レイヤーを定義するカスタムリソースです。イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。
サポートされている Channel オブジェクトをインスタンス化することでチャネルを作成し、Subscription オブジェクトの delivery 仕様を変更して再配信の試行を設定できます。
Channel オブジェクトが作成されると、変更用の受付 Webhook はデフォルトのチャネル実装に基づいて Channel オブジェクトの spec.channelTemplate プロパティーのセットを追加します。たとえば、InMemoryChannel のデフォルト実装の場合、Channel オブジェクトは以下のようになります。
チャネルコントローラーは、その後に spec.channelTemplate 設定に基づいてサポートするチャネルインスタンスを作成します。
spec.channelTemplate プロパティーは作成後に変更できません。それらは、ユーザーではなくデフォルトのチャネルメカニズムで設定されるためです。
このメカニズムが上記の例で使用される場合は、2 つのオブジェクト (汎用バッキングチャネルおよび InMemoryChannel チャネルなど) が作成されます。別のデフォルトチャネルの実装を使用している場合、InMemoryChannel は実装に固有のものに置き換えられます。たとえば、Apache Kafka の Knative ブローカーでは、KafkaChannel チャネルが作成されます。
バッキングチャネルは、サブスクリプションをユーザー作成のチャネルオブジェクトにコピーし、ユーザー作成チャネルオブジェクトのステータスを、バッキングチャネルのステータスを反映するように設定します。
6.1.1. チャネルの実装タイプ リンクのコピーリンクがクリップボードにコピーされました!
InMemoryChannel および KafkaChannel チャネルの実装は、開発目的で OpenShift Serverless で使用できます。
以下は、InMemoryChannel タイプのチャネルの制限です。
- イベントの永続性は利用できません。Pod がダウンすると、その Pod のイベントが失われます。
-
InMemoryChannelチャネルはイベントの順序を実装しないため、チャネルで同時に受信される 2 つのイベントはいずれの順序でもサブスクライバーに配信できます。 -
サブスクライバーがイベントを拒否する場合、再配信はデフォルトで試行されません。
Subscriptionオブジェクトのdelivery仕様を変更することで、再配信の試行を設定できます。
6.2. チャネルの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルは、単一のイベント転送および永続レイヤーを定義するカスタムリソースです。イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。
サポートされている Channel オブジェクトをインスタンス化することでチャネルを作成し、Subscription オブジェクトの delivery 仕様を変更して再配信の試行を設定できます。
6.2.1. Administrator パースペクティブを使用したチャネルの作成 リンクのコピーリンクがクリップボードにコピーされました!
Knative Eventing がクラスターにインストールされると、Administrator パースペクティブを使用してチャネルを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Administrator パースペクティブを使用している。
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 Serverless → Eventing に移動します。
- Create リストで、Channel を選択します。Channel ページに移動します。
タイプ リストで、作成する
Channelオブジェクトのタイプを選択します。注記現時点で、
InMemoryChannelチャネルオブジェクトのみがデフォルトでサポートされます。Apache Kafka の Knative チャネルは、OpenShift Serverless に Apache Kafka の Knative ブローカー実装をインストールしている場合に使用できます。- Create をクリックします。
6.2.2. 開発者パースペクティブを使用したチャネルの作成 リンクのコピーリンクがクリップボードにコピーされました!
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 に移動します。
-
タイプ リストで、作成する
Channelオブジェクトのタイプを選択します。 - Create をクリックします。
検証
Topology ページに移動して、チャネルが存在することを確認します。
6.2.3. Knative CLI を使用したチャネルの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルを作成するために Knative (kn) CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。kn channel create コマンドを使用してチャネルを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
チャネルを作成します。
kn channel create <channel_name> --type <channel_type>
$ kn channel create <channel_name> --type <channel_type>Copy to Clipboard Copied! Toggle word wrap Toggle overflow チャネルタイプはオプションですが、指定する場合は、
Group:Version:Kindの形式で指定する必要があります。たとえば、InMemoryChannelオブジェクトを作成できます。kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel
$ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannelCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Channel 'mychannel' created in namespace 'default'.
Channel 'mychannel' created in namespace 'default'.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
チャネルが存在することを確認するには、既存のチャネルをリスト表示し、出力を検査します。
kn channel list
$ kn channel listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
kn channel list NAME TYPE URL AGE READY REASON mychannel InMemoryChannel http://mychannel-kn-channel.default.svc.cluster.local 93s True
kn channel list NAME TYPE URL AGE READY REASON mychannel InMemoryChannel http://mychannel-kn-channel.default.svc.cluster.local 93s TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
チャネルの削除
チャネルを削除します。
kn channel delete <channel_name>
$ kn channel delete <channel_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.4. YAML を使用したデフォルト実装チャネルの作成 リンクのコピーリンクがクリップボードにコピーされました!
YAML ファイルを使用して Knative リソースを作成する場合は、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述できます。YAML を使用してサーバーレスチャネルを作成するには、Channel オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Channelオブジェクトを YAML ファイルとして作成します。apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: default
apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.5. YAML を使用した Apache Kafka のチャネルの作成 リンクのコピーリンクがクリップボードにコピーされました!
YAML ファイルを使用して Knative リソースを作成する場合は、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述できます。Kafka チャネルを作成することで、Kafka トピックに裏打ちされた Knative Eventing チャネルを作成できます。YAML を使用して Kafka チャネルを作成するには、KafkaChannel オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaカスタムリソースが OpenShift Container Platform クラスターにインストールされている。 -
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
KafkaChannelオブジェクトを YAML ファイルとして作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要OpenShift Serverless 上の
KafkaChannelオブジェクトの API のv1beta1バージョンのみがサポートされます。非推奨となったv1alpha1バージョンの API は使用しないでください。KafkaChannelYAML ファイルを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.6. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- チャネルを作成した後、チャネルをシンクに接続して、シンクがイベントを受信できるようにします。
- イベントがイベントシンクに配信されなかった場合に適用される イベント配信パラメーター を設定します。
6.3. チャネルのシンクへの接続 リンクのコピーリンクがクリップボードにコピーされました!
イベントソースまたはプロデューサーからチャネルに送信されたイベントは、サブスクリプション を使用して 1 つ以上のシンクに転送できます。サブスクリプションを作成するには、チャネルと、そのチャネルに送信されたイベントを消費するシンク (subscriber とも呼ばれる) を指定する Subscription オブジェクトを設定します。
6.3.1. 開発者パースペクティブを使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効できます。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 ビューでチャネルをサービスに接続する行として表示できます。
6.3.2. YAML を使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効できます。YAML ファイルを使用して Knative リソースを作成する場合は、宣言的 API を使用するため、再現性の高い方法でサブスクリプションを宣言的に記述できます。YAML を使用してサブスクリプションを作成するには、Subscription オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Subscriptionオブジェクトを作成します。YAML ファイルを作成し、以下のサンプルコードをこれにコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サブスクリプションの名前。
- 2
- サブスクリプションが接続するチャネルの設定。
- 3
- イベント配信の設定。これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。これが設定されると、使用できないイベントが
deadLetterSinkに送信されます。イベントがドロップされると、イベントの再配信は試行されず、エラーのログがシステムに記録されます。deadLetterSink値は Destination である必要があります。 - 4
- サブスクライバーの設定。これは、イベントがチャネルから送信されるイベントシンクです。
YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.3. Knative CLI を使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効できます。サブスクリプションを作成するために Knative (kn) CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。kn subscription create コマンドを適切なフラグとともに使用して、サブスクリプションを作成できます。
前提条件
- 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> \ --sink <sink_prefix>:<sink_name> \ --sink-dead-letter <sink_prefix>:<sink_name>
$ 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 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
$ kn subscription create mysubscription --channel mychannel --sink ksvc:event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Subscription 'mysubscription' created in namespace 'default'.
Subscription 'mysubscription' created in namespace 'default'.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
サブスクリプションを使用してチャネルがイベントシンクまたは サブスクライバー に接続されていることを確認するには、既存のサブスクリプションをリスト表示し、出力を検査します。
kn subscription list
$ kn subscription listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display True
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サブスクリプションの削除
サブスクリプションを削除します。
kn subscription delete <subscription_name>
$ kn subscription delete <subscription_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.4. Administrator パースペクティブを使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンク (subscriber とも呼ばれます) を作成したら、サブスクリプションを作成してイベント配信を有効にできます。サブスクリプションは、イベントを配信するチャネルとサブスクライバーを指定する Subscription オブジェクトを設定することによって作成されます。障害の処理方法など、サブスクライバー固有のオプションを指定することもできます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Administrator パースペクティブを使用している。
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- Knative チャネルを作成している。
- サブスクライバーとして使用する Knative サービスを作成している。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 Serverless → Eventing に移動します。
-
Channel タブで、サブスクリプションを追加するチャネルの Options メニュー
を選択します。
- リストで Add Subscription をクリックします。
- Add Subscription のダイアログボックスで、サブスクリプションの Subscriber を選択します。サブスクライバーは、チャネルからイベントを受信する Knative サービスです。
- Add をクリックします。
6.3.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- イベントがイベントシンクに配信されなかった場合に適用される イベント配信パラメーター を設定します。
6.4. デフォルトのチャネル実装 リンクのコピーリンクがクリップボードにコピーされました!
default-ch-webhook Config Map を使用して、Knative Eventing のデフォルトのチャネル実装を指定できます。クラスター全体または 1 つ以上の namespace に対して、デフォルトのチャネルの実装を指定できます。現在、InMemoryChannel および KafkaChannel チャネルタイプがサポートされています。
6.4.1. デフォルトチャネル実装の設定 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- OpenShift Container Platform に対する管理者権限を持っている。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Apache Kafka の Knative チャネルをデフォルトのチャネル実装として使用する場合は、クラスターに
KnativeKafkaCR もインストールする必要があります。
手順
KnativeEventingカスタムリソースを変更して、default-ch-webhookConfig Map の設定の詳細を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
spec.configで、変更した設定を追加する Config Map を指定できます。- 2
default-ch-webhookConfig Map は、クラスターまたは 1 つ以上の namespace のデフォルトチャネルの実装を指定するために使用できます。- 3
- クラスター全体のデフォルトのチャネルタイプの設定。この例では、クラスターのデフォルトのチャネル実装は
InMemoryChannelです。 - 4
- namespace スコープのデフォルトのチャネルタイプの設定。この例では、
my-namespacenamespace のデフォルトのチャネル実装はKafkaChannelです。
重要namespace 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。
6.5. チャネルのセキュリティー設定 リンクのコピーリンクがクリップボードにコピーされました!
6.5.1. Apache Kafka の Knative チャネルの TLS 認証設定 リンクのコピーリンクがクリップボードにコピーされました!
Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。TLS は、Apache Kafka の Knative ブローカー実装でサポートされている唯一のトラフィック暗号化方式です。
前提条件
- OpenShift Container Platform でクラスターまたは専用の管理者パーミッションを持っている。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaCR は、OpenShift Container Platform クラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
.pemファイルとして Kafka クラスター CA 証明書が保存されている。 -
Kafka クラスタークライアント証明書とキーが
.pemファイルとして保存されている。 -
OpenShift CLI (
oc) がインストールされている。
手順
選択された 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
$ 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.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要キー名に
ca.crt、user.crt、およびuser.keyを使用します。これらの値は変更しないでください。KnativeKafkaカスタムリソースの編集を開始します。oc edit knativekafka
$ oc edit knativekafkaCopy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットおよびシークレットの namespace を参照します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ブートストラップサーバーで一致するポートを指定するようにしてください。
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.2. Apache Kafka の Knative チャネルの SASL 認証設定 リンクのコピーリンクがクリップボードにコピーされました!
Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。
前提条件
- OpenShift Container Platform でクラスターまたは専用の管理者パーミッションを持っている。
-
OpenShift Serverless Operator、Knative Eventing、および
KnativeKafkaCR は、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"
$ 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"Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
キー名に
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"
$ 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"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
キー名に
KnativeKafkaカスタムリソースの編集を開始します。oc edit knativekafka
$ oc edit knativekafkaCopy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットおよびシークレットの namespace を参照します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ブートストラップサーバーで一致するポートを指定するようにしてください。
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 サブスクリプション リンクのコピーリンクがクリップボードにコピーされました!
7.1. サブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効できます。サブスクリプションは、イベントを配信するチャネルとシンク (サブスクライバーとも呼ばれます) を指定する Subscription オブジェクトを設定することによって作成されます。
7.1.1. Administrator パースペクティブを使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンク (subscriber とも呼ばれます) を作成したら、サブスクリプションを作成してイベント配信を有効にできます。サブスクリプションは、イベントを配信するチャネルとサブスクライバーを指定する Subscription オブジェクトを設定することによって作成されます。障害の処理方法など、サブスクライバー固有のオプションを指定することもできます。
前提条件
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- Web コンソールにログインしており、Administrator パースペクティブを使用している。
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- Knative チャネルを作成している。
- サブスクライバーとして使用する Knative サービスを作成している。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 Serverless → Eventing に移動します。
-
Channel タブで、サブスクリプションを追加するチャネルの Options メニュー
を選択します。
- リストで Add Subscription をクリックします。
- Add Subscription のダイアログボックスで、サブスクリプションの Subscriber を選択します。サブスクライバーは、チャネルからイベントを受信する Knative サービスです。
- Add をクリックします。
7.1.2. 開発者パースペクティブを使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効できます。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 ビューでチャネルをサービスに接続する行として表示できます。
7.1.3. YAML を使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効できます。YAML ファイルを使用して Knative リソースを作成する場合は、宣言的 API を使用するため、再現性の高い方法でサブスクリプションを宣言的に記述できます。YAML を使用してサブスクリプションを作成するには、Subscription オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Subscriptionオブジェクトを作成します。YAML ファイルを作成し、以下のサンプルコードをこれにコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サブスクリプションの名前。
- 2
- サブスクリプションが接続するチャネルの設定。
- 3
- イベント配信の設定。これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。これが設定されると、使用できないイベントが
deadLetterSinkに送信されます。イベントがドロップされると、イベントの再配信は試行されず、エラーのログがシステムに記録されます。deadLetterSink値は Destination である必要があります。 - 4
- サブスクライバーの設定。これは、イベントがチャネルから送信されるイベントシンクです。
YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.4. Knative CLI を使用したサブスクリプションの作成 リンクのコピーリンクがクリップボードにコピーされました!
チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効できます。サブスクリプションを作成するために Knative (kn) CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。kn subscription create コマンドを適切なフラグとともに使用して、サブスクリプションを作成できます。
前提条件
- 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> \ --sink <sink_prefix>:<sink_name> \ --sink-dead-letter <sink_prefix>:<sink_name>
$ 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 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
$ kn subscription create mysubscription --channel mychannel --sink ksvc:event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Subscription 'mysubscription' created in namespace 'default'.
Subscription 'mysubscription' created in namespace 'default'.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
サブスクリプションを使用してチャネルがイベントシンクまたは サブスクライバー に接続されていることを確認するには、既存のサブスクリプションをリスト表示し、出力を検査します。
kn subscription list
$ kn subscription listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display True
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サブスクリプションの削除
サブスクリプションを削除します。
kn subscription delete <subscription_name>
$ kn subscription delete <subscription_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- イベントがイベントシンクに配信されなかった場合に適用される イベント配信パラメーター を設定します。
7.2. サブスクリプションの管理 リンクのコピーリンクがクリップボードにコピーされました!
7.2.1. Knative CLI を使用したサブスクリプションの記述 リンクのコピーリンクがクリップボードにコピーされました!
kn subscription describe コマンドを使用し、Knative (kn) CLI を使用して、端末のサブスクリプションに関する情報を出力できます。サブスクリプションを記述するために Knative CLI を使用すると、YAML ファイルを直接表示するよりも合理的で直感的なユーザーインターフェイスが得られます。
前提条件
-
Knative (
kn) CLI がインストールされている。 - クラスターにサブスクリプションを作成している。
手順
サブスクリプションを記述します。
kn subscription describe <subscription_name>
$ kn subscription describe <subscription_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.2. Knative CLI を使用したサブスクリプションの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
kn subscription list コマンドを使用し、Knative (kn) CLI を使用してクラスター内の既存サブスクリプションをリスト表示できます。Knative CLI を使用してサブスクリプションをリスト表示すると、合理的で直感的なユーザーインターフェイスが提供されます。
前提条件
-
Knative (
kn) CLI がインストールされている。
手順
クラスターのサブスクリプションをリスト表示します。
kn subscription list
$ kn subscription listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display True
NAME CHANNEL SUBSCRIBER REPLY DEAD LETTER SINK READY REASON mysubscription Channel:mychannel ksvc:event-display TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2.3. Knative CLI を使用したサブスクリプションの更新 リンクのコピーリンクがクリップボードにコピーされました!
kn subscription update コマンドや適切なフラグを使用し、Knative (kn) CLI を使用してサブスクリプションを端末から更新できます。サブスクリプションを更新するために Knative CLI を使用すると、YAML ファイルを直接更新するよりも合理的で直感的なユーザーインターフェイスが得られます。
前提条件
-
Knative (
kn) CLI がインストールされている。 - サブスクリプションを作成している。
手順
サブスクリプションを更新します。
kn subscription update <subscription_name> \ --sink <sink_prefix>:<sink_name> \ --sink-dead-letter <sink_prefix>:<sink_name>
$ kn subscription update <subscription_name> \ --sink <sink_prefix>:<sink_name> \1 --sink-dead-letter <sink_prefix>:<sink_name>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--sinkは、イベントが配信される、更新されたターゲット宛先を指定します。以下の接頭辞のいずれかを使用して、シンクのタイプを指定できます。ksvc- Knative サービス
channel- 宛先として使用する必要のあるチャネル。ここで参照できるのは、デフォルトのチャネルタイプのみです。
broker- Eventing ブローカー。
- 2
- オプション:
--sink-dead-letterは、イベントが配信に失敗する場合にイベントを送信するシンクを指定するために使用できるオプションのフラグです。詳細は、OpenShift Serverless の Event 配信についてのドキュメントを参照してください。コマンドの例
kn subscription update mysubscription --sink ksvc:event-display
$ kn subscription update mysubscription --sink ksvc:event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第8章 イベント配信 リンクのコピーリンクがクリップボードにコピーされました!
イベントがイベントシンクに配信されなかった場合に適用されるイベント配信パラメーターを設定できます。さまざまなチャネルとブローカーのタイプには、イベント配信のために従う独自の動作パターンがあります。
デッドレターシンクを含むイベント配信パラメーターを設定すると、イベントシンクへの配信に失敗したすべてのイベントが再試行されるようになります。それ以外の場合は、未配信のイベントが破棄される。
イベントが、Apache Kafka のチャネルまたはブローカーレシーバーに正常に配信される場合、受信側は 202 ステータスコードで応答します。つまり、このイベントは Kafka トピック内に安全に保存され、失われることはありません。受信側がその他のステータスコードを返す場合は、イベントは安全に保存されず、ユーザーがこの問題を解決するために手順を実行する必要があります。
8.1. 設定可能なイベント配信パラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下のパラメーターはイベント配信用に設定できます。
- dead letter sink
-
deadLetterSink配信パラメーターを設定して、イベントが配信に失敗した場合にこれを指定されたイベントシンクに保存することができます。デッドレターシンクに格納されていない未配信のイベントは破棄されます。デッドレターシンクは、Knative サービス、Kubernetes サービス、または URI など、Knative Eventing シンクコントラクトに準拠する任意のアドレス指定可能なオブジェクトです。 - retries
-
retry配信パラメーターを整数値で設定することで、イベントが dead letter sink に送信される前に配信を再試行する必要のある最小回数を設定できます。 - back off delay
-
backoffDelay配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelayパラメーターの期間は ISO 8601 形式を使用して指定されます。たとえば、PT1Sは 1 秒の遅延を指定します。 - back off policy
-
backoffPolicy配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーはlinearまたはexponentialのいずれかとして指定できます。linearバックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay * <numberOfRetries>に等しくなります。exponentialバックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay*2^<numberOfRetries>と等しくなります。
8.2. イベント配信パラメーターの設定例 リンクのコピーリンクがクリップボードにコピーされました!
Broker、Trigger、Channel、および Subscription オブジェクトのイベント配信パラメーターを設定できます。ブローカーまたはチャネルのイベント配信パラメーターを設定すると、これらのパラメーターは、それらのオブジェクト用に作成されたトリガーまたはサブスクリプションに伝播されます。トリガーまたはサブスクリプションのイベント配信パラメーターを設定して、ブローカーまたはチャネルの設定をオーバーライドすることもできます。
Broker オブジェクトの例
Trigger オブジェクトの例
Channel オブジェクトの例
Subscription オブジェクトの例
8.3. トリガーのイベント配信順序の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kafka ブローカーを使用している場合は、トリガーからイベントシンクへのイベントの配信順序を設定できます。
前提条件
- OpenShift Serverless Operator、Knative Eventing、および Knative Kafka が OpenShift Container Platform クラスターにインストールされている。
- Kafka ブローカーがクラスターで使用可能であり、Kafka ブローカーが作成されている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc) CLI がインストールされている。
手順
Triggerオブジェクトを作成または変更し、kafka.eventing.knative.dev/delivery.orderアノテーションを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サポートされているコンシューマー配信保証は次のとおりです。
unordered- 順序付けられていないコンシューマーは、適切なオフセット管理を維持しながら、メッセージを順序付けずに配信するノンブロッキングコンシューマーです。
ordered順序付きコンシューマーは、CloudEvent サブスクライバーからの正常な応答を待ってから、パーティションの次のメッセージを配信する、パーティションごとのブロックコンシューマーです。
デフォルトの順序保証は
unorderedです。
Triggerオブジェクトを適用します。oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第9章 イベント検出 リンクのコピーリンクがクリップボードにコピーされました!
9.1. イベントソースおよびイベントソースタイプの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターに存在する、または使用可能なすべてのイベントソースやイベントソースタイプのリストを表示できます。OpenShift Container Platform Web コンソールの Knative (kn) CLI または Developer パースペクティブを使用し、利用可能なイベントソースまたはイベントソースタイプを一覧表示できます。
9.2. コマンドラインからのイベントソースタイプの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用すると、クラスターで使用可能なイベントソースタイプを表示するための合理的で直感的なユーザーインターフェイスが提供されます。
9.2.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
kn source list-types CLI コマンドを使用して、クラスターで作成して使用できるイベントソースタイプをリスト表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。
手順
ターミナルに利用可能なイベントソースタイプをリスト表示します。
kn source list-types
$ kn source list-typesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 sinkCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: OpenShift Container Platform では、利用可能なイベントソースタイプを YAML 形式でリストすることもできます。
kn source list-types -o yaml
$ kn source list-types -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3. 開発者パースペクティブからのイベントソースタイプの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで使用可能なすべてのイベントソースタイプを一覧表示できます。OpenShift Container Platform Web コンソールを使用すると、使用可能なイベントソースタイプを表示するための合理的で直感的なユーザーインターフェイスが提供されます。
9.3.1. 開発者パースペクティブ内での利用可能なイベントソースタイプの表示 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
- Developer パースペクティブにアクセスします。
- +Add をクリックします。
- Event source をクリックします。
- 利用可能なイベントソースタイプを表示します。
9.4. コマンドラインからのイベントソースの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
Knative (kn) CLI を使用すると、クラスターの既存イベントソースを表示するための合理的で直感的なユーザーインターフェイスが提供されます。
9.4.1. Knative CLI の使用による利用可能なイベントリソースの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
kn source list コマンドを使用して、既存のイベントソースを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn) CLI がインストールされている。
手順
ターミナルにある既存のイベントソースをリスト表示します。
kn source list
$ kn source listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプションで、
--typeフラグを使用して、特定タイプのイベントソースのみを一覧表示できます。kn source list --type <event_source_type>
$ kn source list --type <event_source_type>Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの例
kn source list --type PingSource
$ kn source list --type PingSourceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE RESOURCE SINK READY p1 PingSource pingsources.sources.knative.dev ksvc:eshow1 True
NAME TYPE RESOURCE SINK READY p1 PingSource pingsources.sources.knative.dev ksvc:eshow1 TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第10章 イベント設定のチューニング リンクのコピーリンクがクリップボードにコピーされました!
10.1. Knative Eventing システムのデプロイメント設定のオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
KnativeEventing カスタムリソース (CR) の deployments 仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、デフォルトの構成設定のオーバーライドは、eventing-controller、eventing-webhook、および imc-controller フィールド、およびプローブの readiness フィールドと liveness フィールドでサポートされています。
replicas の仕様は、Horizontal Pod Autoscaler (HPA) を使用するデプロイのレプリカの数をオーバーライドできず、eventing-webhook デプロイでは機能しません。
デフォルトでデプロイメントに定義されているプローブのみをオーバーライドできます。
Knative Serving デプロイメントはすべて、以下の例外を除き、デフォルトで readiness および liveness プローブを定義します。
-
net-kourier-controllerおよび3scale-kourier-gatewayは readiness プローブのみを定義します。 -
net-istio-controllerおよびnet-istio-webhookはプローブを定義しません。
10.1.1. デプロイメント設定のオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
現在、デフォルトの構成設定のオーバーライドは、eventing-controller、eventing-webhook、および imc-controller フィールド、およびプローブの readiness フィールドと liveness フィールドでサポートされています。
replicas の仕様は、Horizontal Pod Autoscaler (HPA) を使用するデプロイのレプリカの数をオーバーライドできず、eventing-webhook デプロイでは機能しません。
次の例では、KnativeEventing CR が eventing-controller デプロイメントをオーバーライドして、次のようにします。
-
readinessプローブのタイムアウトeventing-controllerは 10 秒に設定されています。 - デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
- デプロイメントには 3 つのレプリカがあります。
-
example-label:labellabelが追加されました。 -
example-annotation: annotationが追加されます。 -
nodeSelectorフィールドは、disktype: hddラベルを持つノードを選択するように設定されます。
KnativeEventing CR の例
- 1
readinessおよびlivenessプローブオーバーライドを使用して、プローブハンドラーに関連するフィールド (exec、grpc、httpGet、およびtcpSocket) を除き、Kubernetes API で指定されているデプロイメントのコンテナー内のプローブのすべてのフィールドをオーバーライドできます。
KnativeEventing CR ラベルおよびアノテーション設定は、デプロイメント自体と結果として生成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。
10.2. 高可用性 リンクのコピーリンクがクリップボードにコピーされました!
高可用性 (HA) は Kubernetes API の標準的な機能で、中断が生じる場合に API が稼働を継続するのに役立ちます。HA デプロイメントでは、アクティブなコントローラーがクラッシュまたは削除されると、別のコントローラーをすぐに使用できます。このコントローラーは、現在使用できないコントローラーによって処理されていた API の処理を引き継ぎます。
OpenShift Serverless の HA は、リーダーの選択によって利用できます。これは、Knative Serving または Eventing コントロールプレーンのインストール後にデフォルトで有効になります。リーダー選択の HA パターンを使用する場合は、必要時に備えてコントローラーのインスタンスがスケジュールされ、クラスター内で実行されます。このコントローラーインスタンスは、リーダー選出ロックと呼ばれる共有リソースを使用するために競合します。リーダー選択ロックのリソースにアクセスできるコントローラーのインスタンスはリーダーと呼ばれます。
OpenShift Serverless の HA は、リーダーの選択によって利用できます。これは、Knative Serving または Eventing コントロールプレーンのインストール後にデフォルトで有効になります。リーダー選択の HA パターンを使用する場合は、必要時に備えてコントローラーのインスタンスがスケジュールされ、クラスター内で実行されます。このコントローラーインスタンスは、リーダー選出ロックと呼ばれる共有リソースを使用するために競合します。リーダー選択ロックのリソースにアクセスできるコントローラーのインスタンスはリーダーと呼ばれます。
10.2.1. Knative Eventing の高可用性レプリカの設定 リンクのコピーリンクがクリップボードにコピーされました!
Knative Eventing の eventing-controller、eventing-webhook、imc-controller、imc-dispatcher、mt-broker-controller コンポーネントは、デフォルトでそれぞれ 2 つのレプリカを持つように設定されており、高可用性 (HA) を利用することができます。KnativeServing カスタムリソース (CR) の spec.high-availability.replicas 値を変更して、これらのコンポーネントのレプリカ数を変更できます。
Knative Eventing の場合、HA では mt-broker-filter および mt-broker-ingress デプロイメントはスケーリングされません。複数のデプロイメントが必要な場合は、これらのコンポーネントを手動でスケーリングします。
前提条件
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHub → Installed Operators に移動します。
-
knative-eventingnamespace を選択します。 - OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。
knative-serving をクリックしてから、knative-eventing ページの YAML タブに移動します。
KnativeEveningCR のレプリカ数を変更します。サンプル YAML
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2.2. Apache Kafka の Knative ブローカー実装の高可用性レプリカの設定 リンクのコピーリンクがクリップボードにコピーされました!
高可用性 (HA) は、Apache Kafka コンポーネント kafka-controller および kafka-webhook-eventing の Knative ブローカー実装にはデフォルトで提供されており、これらはデフォルトでそれぞれ 2 つのレプリカを持つように設定されています。KnativeKafka カスタムリソース (CR) の spec.high-availability.replicas 値を変更して、これらのコンポーネントのレプリカ数を変更できます。
前提条件
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- OpenShift Serverless Operator と Apache Kafka 用の Knative ブローカーがクラスターにインストールされている。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHub → Installed Operators に移動します。
-
knative-eventingnamespace を選択します。 - OpenShift Serverless Operator の Provided APIs の一覧で Knative Kafka をクリックし、 Knative Kafka タブに移動します。
knative-kafka をクリックしてから、knative-kafka ページの YAML タブに移動します。
KnativeKafkaCR のレプリカ数を変更します。サンプル YAML
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第11章 イベント用の kube-rbac-proxy の設定 リンクのコピーリンクがクリップボードにコピーされました!
kube-rbac-proxy コンポーネントは、Knative Eventing の内部認証および認可機能を提供します。
11.1. イベント用の kube-rbac-proxy リソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Operator CR を使用して、kube-rbac-proxy コンテナーのリソース割り当てをグローバルにオーバーライドできます。
You can also override resource allocation for a specific deployment.
You can also override resource allocation for a specific deployment.
次の設定では、Knative Eventing kube-rbac-proxy の最小および最大の CPU およびメモリー割り当てを設定します。
KnativeEventing CR の例
第12章 Service Mesh での ContainerSource の使用 リンクのコピーリンクがクリップボードにコピーされました!
Service Mesh でコンテナーソースを使用できます。
12.1. Service Mesh を使用した ContainerSource の設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、Service Mesh を使用してコンテナーソースを設定する方法を説明します。
前提条件
- Service Mesh と Serverless の統合が設定されている。
手順
ServiceMeshMemberRollのメンバーである namespace にServiceを作成します。events-display-service.yaml設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Serviceリソースを適用します。oc apply -f event-display-service.yaml
$ oc apply -f event-display-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ServiceMeshMemberRollのメンバーである namespace にContainerSource を作成し、event-displayに設定されたシンクを作成します。test-heartbeats-containersource.yaml設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ContainerSourceリソースを適用します。oc apply -f test-heartbeats-containersource.yaml
$ oc apply -f test-heartbeats-containersource.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: メッセージダンパー機能のログを調べて、イベントが Knative イベントシンクに送信されたことを確認します。
コマンドの例
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第13章 Service Mesh でのシンクバインディングの使用 リンクのコピーリンクがクリップボードにコピーされました!
Service Mesh でシンクバインディングを使用できます。
13.1. Service Mesh を使用したシンクバインディングの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、Service Mesh を使用してシンクバインディングを設定する方法を説明します。
前提条件
- Service Mesh と Serverless の統合が設定されている。
手順
ServiceMeshMemberRollのメンバーである namespace にServiceオブジェクトを作成します。events-display-service.yaml設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Serviceオブジェクトを適用します。oc apply -f event-display-service.yaml
$ oc apply -f event-display-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow SinkBindingオブジェクトを作成します。heartbeat-sinkbinding.yaml設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow SinkBindingオブジェクトを適用します。oc apply -f heartbeat-sinkbinding.yaml
$ oc apply -f heartbeat-sinkbinding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow CronJobオブジェクトを作成します。heartbeat-cronjob.yaml設定ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow CronJobオブジェクトを適用します。oc apply -f heartbeat-cronjob.yaml
$ oc apply -f heartbeat-cronjob.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: メッセージダンパー機能のログを調べて、イベントが Knative イベントシンクに送信されたことを確認します。
コマンドの例
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow