手順

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.4 チャネルを選択します。4.4 チャネルは、OpenShift Serverless Operator の最新の安定したリリースのインストールを可能にします。
   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.4 を選択し、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. PATH を確認するには、以下を実行します。

   $ echo $PATH

   注記

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

   $ kn: No such file or directory

手順

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

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

   $ tar -xf <file>

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

4. PATH を確認するには、以下を実行します。

   $ 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. パスを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

   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 サービスが削除されていることを確認します。

   $ kn service list hello

   出力例

   No services found.

手順

1. Elasticsearch の仮想化ツール Kibana UI を開くには、 以下のコマンドを使用して 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 の一覧を表示します。

   図9.1 Serverless アプリケーション

   
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 つのノードを表示します。

      図9.2 Serverless アプリケーションのリビジョン

      

手順

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. 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 --filename 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 を指定したジョブがイベントシンクにバインドされます。

   1. 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

   $ 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 を、API サーバーのインストール用に選択した 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. 受信メッセージをログにダンプする 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

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

   $ kn source apiserver describe testevents

   出力例

   Name:                testevents
   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. API サーバーソースを削除します。

   $ kn source apiserver delete <source_name>

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

手順

1. API サーバーソースのサービスアカウント、ロールおよびロールバインディングを作成するには、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 を、API サーバーのインストール用に選択した 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. API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする 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. イベントを作成するには、default 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. API サーバーソースを削除します。

   $ oc delete -f k8s-events.yaml

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

   $ oc delete -f authentication.yaml

手順

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

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

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

   $ 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. ping ソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な 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 --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. ping-source.yaml ファイルを適用します。

      $ 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. これを YAML ファイルとして適用してレポートを実行します。

   $ oc apply -f <report_name>.yaml

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