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 ファイルとして作成します。

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

1 2 3 4: この namespace を、イベントソースのインストールに選択した namespace に変更します。

YAML ファイルを適用します。
```
$ oc apply -f <filename>
```
Developer パースペクティブで、+Add Event Source に移動します。Event Sources ページが表示されます。
オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。
ApiServerSource を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。
Form view または YAML view を使用して、ApiServerSource 設定を設定します。
注記
Form view と YAML view 間で切り換えることができます。ビューの切り替え時に、データは永続化されます。
1. APIVERSION に v1 を、KIND に Event を入力します。
2. 作成したサービスアカウントの Service Account Name を選択します。
3. イベントソースの Sink を選択します。Sink は、チャネル、ブローカー、またはサービスなどの Resource、または URI のいずれかになります。
Create をクリックします。

検証

API サーバーソースの作成後、これが Topology ビューでシンクされるサービスに接続されていることを確認できます。

注記

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 がインストールされている。

手順

イベントソースのサービスアカウント、ロールおよびロールバインディングを 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

1 2 3 4: この namespace を、イベントソースのインストールに選択した namespace に変更します。

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
```

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 \ 1
  --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) がインストールされている。

手順

イベントソースのサービスアカウント、ロールおよびロールバインディングを 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

1 2 3 4: この namespace を、イベントソースのインストールに選択した namespace に変更します。

YAML ファイルを適用します。
```
$ oc apply -f <filename>
```

API サーバーソースを YAML ファイルとして作成します。

apiVersion: sources.knative.dev/v1alpha1
kind: ApiServerSource
metadata:
  name: testevents
spec:
  serviceAccountName: events-sa
  mode: Resource
  resources:
    - apiVersion: v1
      kind: Event
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: default

ApiServerSource YAML ファイルを適用します。
```
$ oc apply -f <filename>
```

API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを YAML ファイルとして作成します。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-display
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

Service YAML ファイルを適用します。
```
$ oc apply -f <filename>
```

直接の手順で作成下サービスに、default ブローカーからイベントをフィルターする Trigger オブジェクトを YAML ファイルとして作成します。

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: event-display-trigger
  namespace: default
spec:
  broker: default
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display

Trigger YAML ファイルを適用します。
```
$ oc apply -f <filename>
```

デフォルト namespace で Pod を起動してイベントを作成します。

$ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。

$ oc get apiserversource.sources.knative.dev testevents -o yaml

出力例

apiVersion: sources.knative.dev/v1alpha1
kind: ApiServerSource
metadata:
  annotations:
  creationTimestamp: "2020-04-07T17:24:54Z"
  generation: 1
  name: testevents
  namespace: default
  resourceVersion: "62868"
  selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
  uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
spec:
  mode: Resource
  resources:
  - apiVersion: v1
    controller: false
    controllerSelector:
      apiVersion: ""
      kind: ""
      name: ""
      uid: ""
    kind: Event
    labelSelector: {}
  serviceAccountName: events-sa
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: default

検証

Kubernetes イベントが Knative に送信されていることを確認するには、メッセージダンパー機能ログを確認します。

以下のコマンドを入力して Pod を取得します。
```
$ oc get pods
```

以下のコマンドを入力して、Pod のメッセージダンパー機能ログを表示します。

$ oc logs $(oc get pod -o name | grep event-display) -c user-container

出力例

☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: dev.knative.apiserver.resource.update
  datacontenttype: application/json
  ...
Data,
  {
    "apiVersion": "v1",
    "involvedObject": {
      "apiVersion": "v1",
      "fieldPath": "spec.containers{hello-node}",
      "kind": "Pod",
      "name": "hello-node",
      "namespace": "default",
       .....
    },
    "kind": "Event",
    "message": "Started container",
    "metadata": {
      "name": "hello-node.159d7608e3a3572c",
      "namespace": "default",
      ....
    },
    "reason": "Started",
    ...
  }

API サーバーソースの削除

トリガーを削除します。
```
$ oc delete -f trigger.yaml
```
イベントソースを削除します。
```
$ oc delete -f k8s-events.yaml
```
サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
```
$ oc delete -f authentication.yaml
```

2.3. API サーバーソースの作成

2.3.1. Web コンソールを使用した API サーバーソースの作成

2.3.2. Knative CLI を使用した API サーバーソースの作成

2.3.2.1. Knative CLI シンクフラグ

2.3.3. YAML ファイルを使用した API サーバーソースの作成

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links