5.8.2. Knative CLI を使用した API サーバーソースの作成
kn source apiserver create
コマンドを使用し、kn
CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift 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
5.8.2.1. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合、--sink
フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \ 1
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channel
およびbroker
が含まれます。