4.5. Knative Eventing CLI コマンド
以下の Knative (kn
) CLI コマンドを使用して、クラスター上で Knative Eventing タスクを実行できます。
4.5.1. kn source コマンド
以下のコマンドを使用して、Knative イベントソースを一覧表示、作成、および管理できます。
4.5.1.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示
Knative (kn
) CLI を使用すると、クラスターで使用可能なイベントソースタイプを表示するための合理的で直感的なユーザーインターフェイスが提供されます。kn source list-types
CLI コマンドを使用して、クラスターで作成して使用できるイベントソースタイプを一覧表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI をインストールしている。
手順
ターミナルに利用可能なイベントソースタイプを一覧表示します。
$ kn source list-types
出力例
TYPE NAME DESCRIPTION ApiServerSource apiserversources.sources.knative.dev Watch and send Kubernetes API events to a sink PingSource pingsources.sources.knative.dev Periodically send ping events to a sink SinkBinding sinkbindings.sources.knative.dev Binding for connecting a PodSpecable to a sink
オプション: 利用可能なイベントソースタイプを YAML 形式で一覧表示することもできます。
$ kn source list-types -o yaml
4.5.1.2. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channel
およびbroker
が含まれます。
4.5.1.3. Knative CLI を使用したコンテナーソースの作成および管理
kn source container
コマンドを使用し、Knative (kn
) CLI を使用してコンテナーソースを作成および管理できます。イベントソースを作成するために Knative CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。
コンテナーソースを作成します。
$ kn source container create <container_source_name> --image <image_uri> --sink <sink>
コンテナーソースの削除
$ kn source container delete <container_source_name>
コンテナーソースを記述します。
$ kn source container describe <container_source_name>
既存のコンテナーソースを一覧表示
$ kn source container list
既存のコンテナーソースを YAML 形式で一覧表示
$ kn source container list -o yaml
コンテナーソースを更新します。
このコマンドにより、既存のコンテナーソースのイメージ URI が更新されます。
$ kn source container update <container_source_name> --image <image_uri>
4.5.1.4. Knative CLI を使用した API サーバーソースの作成
kn source apiserver create
コマンドを使用し、kn
CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc
) がインストールされている。 -
Knative (
kn
) CLI をインストールしている。
既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount
リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: events-sa namespace: default 1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: event-watcher namespace: default 2 rules: - apiGroups: - "" resources: - events verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k8s-ra-event-watcher namespace: default 3 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: event-watcher subjects: - kind: ServiceAccount name: events-sa namespace: default 4
YAML ファイルを適用します。
$ oc apply -f <filename>
イベントシンクを持つ API サーバーソースを作成します。次の例では、シンクはブローカーです。
$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。
$ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、
default
のブローカーからサービスへのイベントをフィルターリングします。$ kn trigger create <trigger_name> --sink ksvc:<service_name>
デフォルト namespace で Pod を起動してイベントを作成します。
$ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。
$ kn source apiserver describe <source_name>
出力例
Name: mysource Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 3m ServiceAccountName: events-sa Mode: Resource Sink: Name: default Namespace: default Kind: Broker (eventing.knative.dev/v1) Resources: Kind: event (v1) Controller: false Conditions: OK TYPE AGE REASON ++ Ready 3m ++ Deployed 3m ++ SinkProvided 3m ++ SufficientPermissions 3m ++ EventTypesProvided 3m
検証
メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative に送信されていることを確認できます。
Pod を取得します。
$ oc get pods
Pod のメッセージダンパー機能ログを表示します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.apiserver.resource.update datacontenttype: application/json ... Data, { "apiVersion": "v1", "involvedObject": { "apiVersion": "v1", "fieldPath": "spec.containers{hello-node}", "kind": "Pod", "name": "hello-node", "namespace": "default", ..... }, "kind": "Event", "message": "Started container", "metadata": { "name": "hello-node.159d7608e3a3572c", "namespace": "default", .... }, "reason": "Started", ... }
API サーバーソースの削除
トリガーを削除します。
$ kn trigger delete <trigger_name>
イベントソースを削除します。
$ kn source apiserver delete <source_name>
サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
$ oc delete -f authentication.yaml
4.5.1.5. Knative CLI を使用した ping ソースの作成
kn source ping create
コマンドを使用し、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/knative-eventing-sources-event-display:latest
要求する必要のある ping イベントのセットごとに、PingSource をイベントコンシューマーと同じ namespace に作成します。
$ kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display
以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
$ kn source ping describe test-ping-source
出力例
Name: test-ping-source Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 15s Schedule: */2 * * * * Data: {"message": "Hello world!"} Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 8s ++ Deployed 8s ++ SinkProvided 15s ++ ValidSchedule 15s ++ EventTypeProvided 15s ++ ResourcesCorrect 15s
検証
シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。
デフォルトで、Knative サービスは、トラフィックが 60 秒以内に受信されない場合に Pod を終了します。本書の例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する ping ソースを作成します。
作成された新規 Pod を監視します。
$ watch oc get pods
Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.sources.ping source: /apis/v1/namespaces/default/pingsources/test-ping-source id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9 time: 2020-04-07T16:16:00.000601161Z datacontenttype: application/json Data, { "message": "Hello world!" }
ping ソースの削除
ping ソースを削除します。
$ kn delete pingsources.sources.knative.dev <ping_source_name>
4.5.1.6. Knative CLI を使用した Kafka イベントソースの作成
kn source kafka create
コマンドを使用し、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/knative-eventing-sources-event-display
KafkaSource
CR を作成します。$ kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display
注記このコマンドのプレースホルダー値は、ソース名、ブートストラップサーバー、およびトピックの値に置き換えます。
--servers
、--topics
、および--consumergroup
オプションは、Kafka クラスターへの接続パラメーターを指定します。--consumergroup
オプションは任意です。オプション: 作成した
KafkaSource
CR の詳細を表示します。$ kn source kafka describe <kafka_source_name>
出力例
Name: example-kafka-source Namespace: kafka Age: 1h BootstrapServers: example-cluster-kafka-bootstrap.kafka.svc:9092 Topics: example-topic ConsumerGroup: example-consumer-group Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 1h ++ Deployed 1h ++ SinkProvided 1h
検証手順
Kafka インスタンスをトリガーし、メッセージをトピックに送信します。
$ oc -n kafka run kafka-producer \ -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \ --restart=Never -- bin/kafka-console-producer.sh \ --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
プロンプトにメッセージを入力します。このコマンドは、以下を前提とします。
-
Kafka クラスターが
kafka
namespace にインストールされている。 -
KafkaSource
オブジェクトは、my-topic
トピックを使用するように設定されている。
-
Kafka クラスターが
ログを表示して、メッセージが到達していることを確認します。
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.kafka.event source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic subject: partition:46#0 id: partition:46/offset:0 time: 2021-03-10T11:21:49.4Z Extensions, traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00 Data, Hello!