手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。

2. スクロールするか、またはこれらのキーワード Serverless を Filter by keyword ボックス に入力して OpenShift Serverless Operator を検索します。

   

3. Operator についての情報を確認してから、Install をクリックします。

   

4. Create Operator Subscription ページで以下を実行します。

   
   1. Installation Mode は All namespaces on the cluster (default) になります。このモードは、デフォルトの openshift-operators namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。
   2. Installed Namespace は openshift-operators になります。
   3. Update Channel として 4.3 を選択します。
   4. Automatic または Manual 承認ストラテジーを選択します。
5. Subscribe をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。

6. Catalog → Operator Management ページから、OpenShift Serverless Operator サブスクリプションのインストールおよびアップグレードの進捗をモニターできます。

   1. 手動 の承認ストラテジーを選択している場合、サブスクリプションのアップグレードステータスは、その Install Plan を確認し、承認するまで Upgrading のままになります。Install Plan ページでの承認後に、サブスクリプションのアップグレードステータスは Up to date に移行します。
   2. 自動 の承認ストラテジーを選択している場合、アップグレードステータスは、介入なしに Up to date に解決するはずです。

1. Catalog → Operator Management ページに切り替え、Operator Subscriptions および Install Plans タブで Status の下の失敗またはエラーの有無を確認します。
2. さらにトラブルシューティングの必要な問題を報告している Pod のログについては、Workloads → Pods ページの openshift-operators プロジェクトの Pod のログで確認できます。

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
2. ページ上部の Project ドロップダウンメニューが Project: knative-serving に設定されていることを確認します。

3. OpenShift Serverless Operator の Provided API 一覧で Knative Serving をクリックし、Knative Serving タブに移動します。

   

4. Create Knative Serving ボタンをクリックします。

   

5. Create Knative Serving ページで、Create をクリックしてデフォルト設定を使用し、Knative Serving をインストールできます。

   また、Knative Serving インストールの設定を変更するには、提供されるフォームを使用するか、または YAML を編集して KnativeServing オブジェクトを編集します。

   • KnativeServing オブジェクト作成を完全に制御する必要がない単純な設定には、このフォームの使用が推奨されます。

   • KnativeServing オブジェクトの作成を完全に制御する必要のあるより複雑な設定には、YAML の編集が推奨されます。YAML にアクセスするには、Create Knative Serving ページの右上にある edit YAML リンクをクリックします。

     フォームを完了するか、または YAML の変更が完了したら、Create をクリックします。

     注記

     KnativeServing カスタムリソース定義の設定オプションについての詳細は、高度なインストール設定オプション についてのドキュメントを参照してください。

     
     

6. Knative Serving のインストール後に、KnativeServing オブジェクトが作成され、Knative Serving タブに自動的にダイレクトされます。

   

   リソースの一覧に knative-serving が表示されます。

検証手順

1. Knative Serving タブの knative-serving をクリックします。

2. Knative Serving Overview ページに自動的にダイレクトされます。

   
3. スクロールダウンして、Conditions の一覧を確認します。

4. ステータスが True の条件の一覧が表示されます（例のイメージを参照)。

   
   注記

   Knative Serving リソースが作成されるまでに数分の時間がかかる場合があります。Resources タブでステータスを確認できます。

5. 条件のステータスが Unknown または False である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。

手順

1. serving.yaml という名前のファイルを作成します。

2. 以下のサンプル YAML を serving.yaml にコピーします。

   apiVersion: operator.knative.dev/v1alpha1
   kind: KnativeServing
   metadata:
       name: knative-serving
       namespace: knative-serving

3. serving.yaml ファイルを適用します。

   $ oc apply -f serving.yaml

検証手順

1. インストールが完了したことを確認します。

   $ oc get knativeserving.operator.knative.dev/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

   出力例

   DependenciesInstalled=True
   DeploymentsAvailable=True
   InstallSucceeded=True
   Ready=True

   注記

   Knative Serving リソースが作成されるまでに数分の時間がかかる場合があります。

2. 条件のステータスが Unknown または False である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。

3. 以下を入力して Knative Serving リソースが作成されていることを確認します。

   $ oc get pods -n knative-serving

   出力例

   NAME                               READY   STATUS    RESTARTS   AGE
   activator-5c596cf8d6-5l86c         1/1     Running   0          9m37s
   activator-5c596cf8d6-gkn5k         1/1     Running   0          9m22s
   autoscaler-5854f586f6-gj597        1/1     Running   0          9m36s
   autoscaler-hpa-78665569b8-qmlmn    1/1     Running   0          9m26s
   autoscaler-hpa-78665569b8-tqwvw    1/1     Running   0          9m26s
   controller-7fd5655f49-9gxz5        1/1     Running   0          9m32s
   controller-7fd5655f49-pncv5        1/1     Running   0          9m14s
   kn-cli-downloads-8c65d4cbf-mt4t7   1/1     Running   0          9m42s
   webhook-5c7d878c7c-n267j           1/1     Running   0          9m35s

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
2. ページ上部の Project ドロップダウンメニューが Project: knative-eventing に設定されていることを確認します。

3. OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。

   

4. Create Knative Eventing ボタンをクリックします。

   

5. Create Knative Eventing ページでは、提供されるデフォルトのフォームを使用するか、または YAML を編集して KnativeEventing オブジェクトを設定できます。

   • KnativeEventing オブジェクト作成を完全に制御する必要がない単純な設定には、このフォームの使用が推奨されます。

     オプション。フォームを使用して KnativeEventing オブジェクトを設定する場合は、Knative Eventing デプロイメントに対して実装する必要のある変更を加えます。

6. Create をクリックします。

   

   • KnativeEventing オブジェクトの作成を完全に制御する必要のあるより複雑な設定には、YAML の編集が推奨されます。YAML にアクセスするには、Create Knative Eventing ページの右上にある edit YAML リンクをクリックします。

     オプション。YAML を編集して KnativeEventing オブジェクトを設定する場合は、Knative Eventing デプロイメントについて実装する必要のある変更を YAML に加えます。

7. Create をクリックします。

   

8. Knative Eventing のインストール後に、KnativeEventing オブジェクトが作成され、Knative Eventing タブに自動的にダイレクトされます。

   

   リソースの一覧に knative-eventing が表示されます。

検証手順

1. Knative Eventing タブの knative-eventing をクリックします。

2. Knative Eventing Overview ページに自動的にダイレクトされます。

   
3. スクロールダウンして、Conditions の一覧を確認します。

4. ステータスが True の条件の一覧が表示されます（例のイメージを参照)。

   
   注記

   Knative Eventing リソースが作成されるまでに数秒の時間がかかる場合があります。Resources タブでステータスを確認できます。

5. 条件のステータスが Unknown または False である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。

手順

1. eventing.yaml という名前のファイルを作成します。

2. 以下のサンプル YAML を eventing.yaml にコピーします。

   apiVersion: operator.knative.dev/v1alpha1
   kind: KnativeEventing
   metadata:
       name: knative-eventing
       namespace: knative-eventing

3. オプション。Knative Eventing デプロイメントについて実装する必要のある変更を YAML に加えます。

4. 以下を入力して eventing.yaml ファイルを適用します。

   $ oc apply -f eventing.yaml

検証手順

1. インストールが完了したことを確認します。

   $ oc get knativeeventing.operator.knative.dev/knative-eventing \
     -n knative-eventing \
     --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

   出力例

   InstallSucceeded=True
   Ready=True

   注記

   Knative Eventing リソースが作成されるまでに数秒の時間がかかる場合があります。

2. 条件のステータスが Unknown または False である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。

3. Knative Eventing リソースが作成されていることを確認します。

   $ oc get pods -n knative-eventing

   出力例

   NAME                                   READY   STATUS    RESTARTS   AGE
   broker-controller-58765d9d49-g9zp6     1/1     Running   0          7m21s
   eventing-controller-65fdd66b54-jw7bh   1/1     Running   0          7m31s
   eventing-webhook-57fd74b5bd-kvhlz      1/1     Running   0          7m31s
   imc-controller-5b75d458fc-ptvm2        1/1     Running   0          7m19s
   imc-dispatcher-64f6d5fccb-kkc4c        1/1     Running   0          7m18s

手順

1. OpenShift Container Platform Web コンソールで openshift-operators namespace を選択します。
2. Operators → Installed Operators ページに移動します。
3. OpenShift Serverless Operator を選択します。
4. Subscription → Channel をクリックします。
5. Change Subscription Update Channel ウィンドウで 4.3 を選択し、Save をクリックします。
6. すべての Pod が knative-serving namespace でアップグレードされ、KnativeServing カスタムリソースが最新の Knative Serving バージョンを報告するまで待機します。

1. Pod のステータスを確認します。

   $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

   上記のコマンドは True のステータスを返すはずです。

2. KnativeServing CR のバージョンを確認します。

   $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.version}'

   このコマンドは、Knative Serving の最新バージョンを返すはずです。OpenShift Serverless Operator リリースノートで最新バージョンを確認できます。

手順

1. knative-serving カスタムリソースを削除します。

   $ oc delete knativeservings.operator.knative.dev knative-serving -n knative-serving

2. コマンドが実行され、すべての Pod が knative-serving namespace から削除された後に、namespace を削除します。

   $ oc delete namespace knative-serving

手順

1. knative-eventing カスタムリソースを削除します。

   $ oc delete knativeeventings.operator.knative.dev knative-eventing -n knative-eventing

2. コマンドが実行され、すべての Pod が knative-eventing namespace から削除された後に、namespace を削除します。

   $ oc delete namespace knative-eventing

手順

1. 残りの OpenShift Serverless CRD を削除するには、以下のコマンドを実行します。

   $ oc get crd -oname | grep 'knative.dev' | xargs oc delete

手順

1. Command Line Tools ページから kn CLI をダウンロードします。

2. アーカイブを展開します。

   $ tar -xf <file>

3. kn バイナリーをパスにあるディレクトリーに移動します。

4. パスを確認します。

   $ echo $PATH

   注記

   RHEL または Fedora を使用しない場合は、libc がライブラリーパスのディレクトリーにインストールされていることを確認してください。libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

   $ kn: No such file or directory

手順

1. コマンドを入力します。

   # subscription-manager register

2. コマンドを入力します。

   # subscription-manager refresh

3. コマンドを入力します。

   # subscription-manager attach --pool=<pool_id> 1

   1

   有効な OpenShift Container Platform サブスクリプションのプール ID

4. コマンドを入力します。

   # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"

5. コマンドを入力します。

   # yum install openshift-serverless-clients

手順

1. CLI をダウンロードします。

2. アーカイブを展開します。

   $ tar -xf <file>

3. kn バイナリーをパスにあるディレクトリーに移動します。

4. パスを確認します。

   $ echo $PATH

   注記

   RHEL または Fedora を使用しない場合は、libc がライブラリーパスのディレクトリーにインストールされていることを確認してください。libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

   $ kn: No such file or directory

手順

1. CLI をダウンロードします。
2. アーカイブを展開および解凍します。
3. kn バイナリーをパスにあるディレクトリーに移動します。

4. パスを確認します。

   $ echo $PATH

手順

1. CLI をダウンロードします。
2. ZIP プログラムでアーカイブを解凍します。
3. kn バイナリーをパスにあるディレクトリーに移動します。

4. PATH を確認するには、コマンドプロンプトを開いて以下を入力します。

   C:\> path

手順

1. Serverless → Services ページに移動します。

   
2. Create Service をクリックします。

3. YAML または JSON 定義を手動で入力するか、またはファイルをエディターにドラッグし、ドロップします。

   
4. Create をクリックします。

手順

1. イメージからサービスを デフォルト namespace に作成します。

   $ kn service create hello --image docker.io/openshift/hello-openshift --env RESPONSE="Hello Serverless!"

   Creating service 'hello' in namespace 'default':
   
     0.085s The Route is still working to reflect the latest desired specification.
     0.101s Configuration "hello" is waiting for a Revision to become ready.
    11.590s ...
    11.650s Ingress has not yet been reconciled.
    11.726s Ready to serve.
   
   Service 'hello' created with latest revision 'hello-gsdks-1' and URL:
   http://hello-default.apps-crc.testing

2. サービスを一覧表示します。

   $ kn service list

   NAME    URL                                     LATEST          AGE     CONDITIONS   READY   REASON
   hello   http://hello-default.apps-crc.testing   hello-gsdks-1   8m35s   3 OK / 3     True

3. curl サービスエンドポイントコマンドを使用して、サービスが機能しているかどうかを確認します。

   $ curl http://hello-default.apps-crc.testing

   Hello Serverless!

4. サービスを更新します。

   $ kn service update hello --env RESPONSE="Hello OpenShift!"

   Updating Service 'hello' in namespace 'default':
   
    10.136s Traffic is not yet migrated to the latest revision.
    10.175s Ingress has not yet been reconciled.
    10.348s Ready to serve.
   
   Service 'hello' updated with latest revision 'hello-dghll-2' and URL:
   http://hello-default.apps-crc.testing

   サービスの環境変数 RESPONSE は「Hello OpenShift!」に設定されるようになりました。

5. サービスを記述します。

   $ kn service describe hello

   Name:       hello
   Namespace:  default
   Age:        13m
   URL:        http://hello-default.apps-crc.testing
   
   Revisions:
     100%  @latest (hello-dghll-2) [2] (1m)
           Image:  docker.io/openshift/hello-openshift (pinned to 5ea96b)
   
   Conditions:
     OK TYPE                   AGE REASON
     ++ Ready                   1m
     ++ ConfigurationsReady     1m
     ++ RoutesReady             1m

6. サービスを削除します。

   $ kn service delete hello

   Service 'hello' successfully deleted in namespace 'default'.

7. hello サービスに対して list を試行し、これが削除されていることを確認しまう。

   $ kn service list hello

   No services found.

手順

1. Kibana ルートを取得します。

   $ oc -n openshift-logging get route kibana

2. ルートの URL を使用して Kibana ダッシュボードに移動し、ログインします。
3. インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。

4. knative-serving namespace を使用してログをフィルターできます。kubernetes.namespace_name:knative-serving を検索ボックスに入力して結果をフィルターします。

   注記

   Knative Serving はデフォルトで構造化ロギングを使用します。クラスターロギング Fluentd 設定をカスタマイズしてこれらのログの解析を有効にできます。これにより、ログの検索がより容易になり、ログレベルでのフィルターにより問題を迅速に特定できるようになります。

手順

1. Kibana URL を取得します。

   $ oc -n cluster-logging get route kibana`

2. URL をブラウザーに入力し、Kibana UI を開きます。
3. インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。

4. サービスがデプロイされている Kubernetes namespace を使用してログをフィルターします。フィルターを追加してサービス自体を特定します: kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}

   注記

   /configuration または /revision を使用してフィルターすることもできます。

5. kubernetes.container_name:<user-container> を使用して検索を絞り込み、ご使用のアプリケーションで生成されるログのみを表示することができます。それ以外の場合は、queue-proxy からのログが表示されます。

   注記

   アプリケーションで JSON ベースの構造化ロギングを使用することで、実稼働環境でのこれらのログの迅速なフィルターを実行できます。

1. 四角形のマークが付けられたサーバーレスリソースサービスをクリックし、その概要をサイドパネルに表示します。

2. Resources タブをクリックして、サービスの Revisions および Routes の一覧を表示します。

   
3. サイドパネルの上部にある S アイコンで示されるサービスをクリックし、サービスの詳細の概要を確認します。
4. YAML タブをクリックし、YAML エディターでサービス設定を変更し、Save をクリックします。たとえば、timeoutseconds を 300 から 301 に変更します。この設定の変更により、新規リビジョンがトリガーされます。Topology ビューでは、最新のリビジョンが表示され、サービスの Resources タブに 2 つのリビジョンが表示されるようになります。

5. Resources タブで Set Traffic Distribution ボタンをクリックして、トラフィック分配ダイアログボックスを表示します。

   1. Splits フィールドに、2 つのリビジョンのそれぞれの分割されたトラフィックパーセンテージを追加します。
   2. 2 つのリビジョンのカスタム URL を作成するタグを追加します。

   3. Save をクリックし、Topology ビューで 2 つのリビジョンを表す 2 つのノードを表示します。

      

手順

1. ServiceAccount オブジェクトを作成します。

   1. 以下のコマンドを入力して eventing-broker-ingress オブジェクトを作成します。

      $ oc -n <namespace> create serviceaccount eventing-broker-ingress

   2. 以下のコマンドを入力して eventing-broker-filter オブジェクトを作成します。

      $ oc -n <namespace> create serviceaccount eventing-broker-filter

2. RBAC パーミッションを作成したオブジェクトに指定します。

   $ oc -n default create rolebinding eventing-broker-ingress \
     --clusterrole=eventing-broker-ingress \
     --serviceaccount=default:eventing-broker-ingress

   $ oc -n default create rolebinding eventing-broker-filter \
     --clusterrole=eventing-broker-filter \
     --serviceaccount=default:eventing-broker-filter

3. 以下を含む YAML ファイルを作成し、適用してブローカーを作成します。

   apiVersion: eventing.knative.dev/v1beta1
   kind: Broker
   metadata:
     namespace: default
     name: default 1

   1

   この例では、default という名前を使用していますが、これを他の有効な名前に置き換えることができます。

手順

1. 以下のコマンドを入力して namespace にアノテーションを付けます。

   $ oc label namespace default knative-eventing-injection=enabled 1
   $ oc -n default get broker default

   1

   default を必要な namespace に置き換えます。

   以下の例で示されている行は、default という名前のブローカーを default namespace に自動的に作成します。

1. 選択した namespace（この例では default namespace) から挿入されたブローカーを削除します。

   $ oc -n default delete broker default

手順

1. 以下を含む YAML ファイルを作成して、チャネルをサービスに接続するために Subscription オブジェクトを作成します。

   apiVersion: messaging.knative.dev/v1beta1
   kind: Subscription
   metadata:
     name: my-subscription 1
     namespace: default
   spec:
     channel: 2
       apiVersion: messaging.knative.dev/v1beta1
       kind: Channel
       name: example-channel
     delivery: 3
       deadLetterSink:
         ref:
           apiVersion: serving.knative.dev/v1
           kind: Service
           name: error-handler
     subscriber: 4
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

   1

   サブスクリプションの名前。

   2

   サブスクリプションが接続するチャネルの設定。

   3

   イベント配信の設定。これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。これが設定されると、使用できないイベントが deadLetterSink に送信されます。イベントがドロップされると、イベントの再配信は試行されず、エラーのログがシステムに記録されます。deadLetterSink 値は Destination である必要があります。

   4

   サブスクライバーの設定。これは、イベントがチャネルから送信されるイベントシンクです。

2. 以下を入力して YAML ファイルを適用します。

   $ oc apply -f <filename>

手順

1. 利用可能なトリガーの一覧を出力します。

   $ kn trigger list

   出力例

   NAME    BROKER    SINK           AGE   CONDITIONS   READY   REASON
   email   default   svc:edisplay   4s    5 OK / 5     True
   ping    default   svc:edisplay   32s   5 OK / 5     True

手順

1. JSON 形式でトリガーの一覧を出力します。

   $ kn trigger list -o json

例

1. トリガーを、受信イベントに一致するイベント属性をフィルターするように更新できます (例: type=knative.dev.event)。

   $ kn trigger update <trigger_name> --filter type=knative.dev.event

2. キー type でフィルター属性を削除します。

   $ kn trigger update mytrigger --filter type-

3. トリガーのシンクを更新し、event-display という名前のサービスを使用できるようにします。

   $ kn trigger update <trigger_name> --sink svc:event-display

手順

1. SinkBinding が正しく設定されていることを確認するには、受信メッセージをダンプする Knative イベント表示サービスまたはイベントシンクを作成します。

   $ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

2. イベントをサービスに転送する SinkBinding を作成します。

   $ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink svc:event-display

3. CronJob を作成します。

   1. heartbeats-cronjob.yaml という名前のファイルを作成し、以下のサンプルコードをこれにコピーします。

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace

   2. heartbeats-cronjob.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply -f heartbeats-cronjob.yaml

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

   $ kn source binding describe bind-heartbeat

   Name:         bind-heartbeat
   Namespace:    demo-2
   Annotations:  sources.knative.dev/creator=minikube-user, sources.knative.dev/lastModifier=minikub ...
   Age:          2m
   Subject:
     Resource:   job (batch/v1)
     Selector:
       app:      heartbeat-cron
   Sink:
     Name:       event-display
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE     AGE REASON
     ++ Ready     2m

手順

1. SinkBinding が正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative イベント表示サービスまたはイベントシンクを作成します。

   1. 以下のサンプル YAML を service.yaml という名前のファイルにコピーします。

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

   2. service.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply -f service.yaml

2. イベントをサービスに転送する SinkBinding を作成します。

   1. sinkbinding.yaml という名前のファイルを作成し、以下のサンプルコードをこれにコピーします。

      apiVersion: sources.knative.dev/v1alpha1
      kind: SinkBinding
      metadata:
        name: bind-heartbeat
      spec:
        subject:
          apiVersion: batch/v1
          kind: Job 1
          selector:
            matchLabels:
              app: heartbeat-cron
      
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

      1

      この例では、ラベル app: heartbeat-cron を指定したジョブがイベントシンクにバインドされます。

   2. sinkbinding.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply -f sinkbinding.yaml

3. CronJob を作成します。

   1. heartbeats-cronjob.yaml という名前のファイルを作成し、以下のサンプルコードをこれにコピーします。

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace

   2. heartbeats-cronjob.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply -f heartbeats-cronjob.yaml

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

   $ oc get sinkbindings.sources.knative.dev bind-heartbeat -oyaml

   spec:
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default
     subject:
       apiVersion: batch/v1
       kind: Job
       namespace: default
       selector:
         matchLabels:
           app: heartbeat-cron

1. コマンドを入力します。

   $ oc get pods

2. コマンドを入力します。

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

   出力例

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.eventing.samples.heartbeat
     source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod
     id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596
     time: 2019-10-18T15:23:20.809775386Z
     contenttype: application/json
   Extensions,
     beats: true
     heart: yes
     the: 42
   Data,
     {
       "id": 1,
       "label": ""
     }

手順

1. ApiServerSource のサービスアカウント、ロール、およびロールバインディングを作成します。

   authentication.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 を、ApiServerSource のインストールに選択した namespace に変更します。

   注記

   適切なパーミッションを持つ既存のサービスアカウントを再利用する必要がある場合、そのサービスアカウントの authentication.yaml を変更する必要があります。

   サービスアカウント、ロールバインディング、およびクラスターバインディングを作成します。

   $ oc apply -f authentication.yaml

2. ブローカーをイベントシンクとして使用する ApiServerSource を作成します。

   $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource

3. ApiServerSource が正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。

   $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

4. default ブローカーからサービスにイベントをフィルターするトリガーを作成します。

   $ kn trigger create <trigger_name> --sink svc:<service_name>

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

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

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

   $ 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/v1alpha1)
   Resources:
     Kind:        event (v1)
     Controller:  false
   Conditions:
     OK TYPE                     AGE REASON
     ++ Ready                     3m
     ++ Deployed                  3m
     ++ SinkProvided              3m
     ++ SufficientPermissions     3m
     ++ EventTypesProvided        3m

1. Pod を取得します。

   $ oc get pods

2. 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",
       ...
     }

手順

1. トリガーを削除します。

   $ kn trigger delete <trigger_name>

2. サービスを削除します。

   $ kn service delete <service_name>

3. イベントソースを削除します。

   $ kn source apiserver delete <source_name>

4. サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。

手順

1. ApiServerSource のサービスアカウント、ロールおよびロールバインディングを作成するには、authentication.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 を、ApiServerSource のインストールに選択した namespace に変更します。

   注記

   適切なパーミッションを持つ既存のサービスアカウントを再利用する必要がある場合、そのサービスアカウントの authentication.yaml を変更する必要があります。

   authentication.yaml ファイルを作成した後に、これを適用します。

   $ oc apply -f authentication.yaml

2. ApiServerSource イベントソースを作成するには、k8s-events.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/v1beta1
         kind: Broker
         name: default

   k8s-events.yaml ファイルを作成した後に、これを適用します。

   $ oc apply -f k8s-events.yaml

3. ApiServerSource が正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。

   以下のサンプル YAML を service.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:v0.13.2

   service.yaml ファイルを作成した後に、これを適用します。

   $ oc apply -f service.yaml

4. イベントを直前の手順で作成したサービスにフィルターする default ブローカーからトリガーを作成するには、trigger.yaml という名前のファイルを作成し、以下のサンプルコードをこれにコピーします。

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

   trigger.yaml ファイルを作成した後に、これを適用します。

   $ oc apply -f trigger.yaml

5. イベントを作成するには、デフォルト namespace で Pod を起動します。

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

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

   $ 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/v1beta1
         kind: Broker
         name: default

1. Pod を取得します。

   $ oc get pods

2. 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",
       ...
     }

手順

1. トリガーを削除します。

   $ oc delete -f trigger.yaml

2. サービスを削除します。

   $ oc delete -f service.yaml

3. イベントソースを削除します。

   $ oc delete -f k8s-events.yaml

4. サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。

   $ oc delete -f authentication.yaml

手順

1. PingSource が機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

2. 要求する必要のある ping イベントのセットごとに、イベントコンシューマーと同じ namespace に PingSource を作成します。

   $ kn source ping create test-ping-source \
       --schedule "*/2 * * * *" \
       --data '{"message": "Hello world!"}' \
       --sink svc:event-display

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

   $ 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

1. 作成された新規 Pod を監視します。

   $ watch oc get pods

2. 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!"
     }

手順

1. PingSource が機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。

   1. サンプル YAML を service.yaml という名前のファイルにコピーします。

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

   2. サービスを作成します。

      $ oc apply --filename service.yaml

2. 要求する必要のある ping イベントのセットごとに、PingSource をイベントコンシューマーと同じ namespace に作成します。

   1. サンプル YAML を ping-source.yamlという名前のファイルにコピーします。

      apiVersion: sources.knative.dev/v1alpha2
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        jsonData: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

   2. PingSource を作成します。

      $ oc apply --filename ping-source.yaml

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

   $ oc get pingsource.sources.knative.dev test-ping-source -oyaml

   apiVersion: sources.knative.dev/v1alpha2
   kind: PingSource
   metadata:
     annotations:
       sources.knative.dev/creator: developer
       sources.knative.dev/lastModifier: developer
     creationTimestamp: "2020-04-07T16:11:14Z"
     generation: 1
     name: test-ping-source
     namespace: default
     resourceVersion: "55257"
     selfLink: /apis/sources.knative.dev/v1alpha2/namespaces/default/pingsources/test-ping-source
     uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
   spec:
     jsonData: '{ value: "hello" }'
     schedule: '*/2 * * * *'
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default

1. 作成された新規 Pod を監視します。

   $ watch oc get pods

2. Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。

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

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 042ff529-240e-45ee-b40c-3a908129853e
     time: 2020-04-07T16:22:00.000791674Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

1. ReportDataSources を適用します。

1. 以下のコマンドを使用して、ReportQuery を適用できます。

   $ oc apply -f <query-name>.yaml

   $ oc apply -f knative-service-memory-usage.yaml

1. 以下のコマンドを入力してレポートを実行します。

   $ oc apply -f <report-name>.yml

2. 以下のコマンドを入力してレポートを確認できます。

   $ oc get report

   NAME                        QUERY                       SCHEDULE   RUNNING    FAILED   LAST REPORT TIME       AGE
   knative-service-cpu-usage   knative-service-cpu-usage              Finished            2019-06-30T23:59:59Z   10h