手順

1. 以下のサンプルコードを含む YAML ファイルを作成します。

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-delivery
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

2. YAML ファイルが含まれるディレクトリーに移動し、YAML ファイルを適用してアプリケーションをデプロイします。

   $ oc apply -f <filename>

手順

1. Serverless → Serving ページに移動します。
2. Create 一覧で、Service を選択します。
3. YAML または JSON 定義を手動で入力するか、またはファイルをエディターにドラッグし、ドロップします。
4. Create をクリックします。

手順

1. オフラインモードでは、ローカルの Knative サービス記述子ファイルを作成します。

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

   出力例

   Service 'event-display' created in namespace 'test'.

   • --target ./ フラグはオフラインモードを有効にし、./ を新しいディレクトリーツリーを保存するディレクトリーとして指定します。

     既存のディレクトリーを指定せずに、--target my-service.yaml などのファイル名を使用すると、ディレクトリーツリーは作成されません。代わりに、サービス記述子ファイル my-service.yaml のみが現在のディレクトリーに作成されます。

     ファイル名には、.yaml、.yml または .json 拡張子を使用できます。.json を選択すると、JSON 形式でサービス記述子ファイルが作成されます。

   • --namespace test オプションは、新規サービスを テスト namespace に配置します。

     --namespace を使用せずに、OpenShift Container Platform クラスターにログインしている場合には、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルが default の namespace に作成されます。

2. 作成したディレクトリー構造を確認します。

   $ tree ./

   出力例

   ./
   └── test
       └── ksvc
           └── event-display.yaml
   
   2 directories, 1 file

   • --target で指定する現在の ./ ディレクトリーには新しい test/ ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。
   • test/ ディレクトリーには、リソースタイプの名前が付けられた ksvc ディレクトリーが含まれます。
   • ksvc ディレクトリーには、指定のサービス名に従って命名される記述子ファイル event-display.yaml が含まれます。

3. 生成されたサービス記述子ファイルを確認します。

   $ cat test/ksvc/event-display.yaml

   出力例

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     creationTimestamp: null
     name: event-display
     namespace: test
   spec:
     template:
       metadata:
         annotations:
           client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
         creationTimestamp: null
       spec:
         containers:
         - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
           name: ""
           resources: {}
   status: {}

4. 新しいサービスに関する情報を一覧表示します。

   $ kn service describe event-display --target ./ --namespace test

   出力例

   Name:       event-display
   Namespace:  test
   Age:
   URL:
   
   Revisions:
   
   Conditions:
     OK TYPE    AGE REASON

   • --target ./ オプションは、namespace サブディレクトリーを含むディレクトリー構造のルートディレクトリーを指定します。

     または、--target オプションで YAML または JSON ファイルを直接指定できます。使用可能なファイルの拡張子は、.yaml、.yml、および .json です。

   • --namespace オプションは、namespace を指定し、この namespace は必要なサービス記述子ファイルを含むサブディレクトリーの kn と通信します。

     --namespace を使用せず、OpenShift Container Platform クラスターにログインしている場合には、kn は現在の namespace をもとに名前が付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kn は default/ サブディレクトリーで検索します。

5. サービス記述子ファイルを使用してクラスターでサービスを作成します。

   $ kn service create -f test/ksvc/event-display.yaml

   出力例

   Creating service 'event-display' in namespace 'test':
   
     0.058s The Route is still working to reflect the latest desired specification.
     0.098s ...
     0.168s Configuration "event-display" is waiting for a Revision to become ready.
    23.377s ...
    23.419s Ingress has not yet been reconciled.
    23.534s Waiting for load balancer to be ready
    23.723s Ready to serve.
   
   Service 'event-display' created to latest revision 'event-display-00001' is available at URL:
   http://event-display-test.apps.example.com

手順

1. アプリケーション URL を検索します。

   $ oc get ksvc <service_name>

   出力例

   NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
   event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

2. クラスターに対して要求を実行し、出力を確認します。

   HTTP 要求の例

   $ curl http://event-delivery-default.example.com

   HTTPS 要求の例

   $ curl https://event-delivery-default.example.com

   出力例

   Hello Serverless!

3. オプション:証明書チェーンで自己署名証明書に関連するエラーが発生した場合は、curl コマンドに --insecure フラグを追加して、エラーを無視できます。

   $ curl https://event-delivery-default.example.com --insecure

   出力例

   Hello Serverless!

   重要

   自己署名証明書は、実稼働デプロイメントでは使用しないでください。この方法は、テスト目的にのみ使用されます。

4. オプション:OpenShift Container Platform クラスターが認証局 (CA) で署名されているが、システムにグローバルに設定されていない証明書で設定されている場合、curl コマンドでこれを指定できます。証明書へのパスは、--cacert フラグを使用して curl コマンドに渡すことができます。

   $ curl https://event-delivery-default.example.com --cacert <file>

   出力例

   Hello Serverless!

手順

1. サービスを変更して、追加のコンテナーを追加します。リクエストを処理できるコンテナーは 1 つだけであるため、ポート は 1 つのコンテナーにのみ指定してください。以下は、2 つのコンテナーの設定例です。

   複数のコンテナー設定

   apiVersion: serving.knative.dev/v1
   kind: Service
   ...
   spec:
     template:
       spec:
         containers:
           - name: first-container 1
             image: gcr.io/knative-samples/helloworld-go
             ports:
               - containerPort: 8080 2
           - name: second-container 3
             image: gcr.io/knative-samples/helloworld-java

   1

   最初のコンテナー設定。

   2

   最初のコンテナーのポート仕様。

   3

   2 つ目のコンテナー設定。

手順

1. Knative Serving が PVC を使用して書き込むことができるようにするには、KnativeServing カスタムリソース (CR) を変更して次の YAML を含めます。

   書き込みアクセスで PVC を有効にする

   ...
   spec:
     config:
       features:
         "kubernetes.podspec-persistent-volume-claim": enabled
         "kubernetes.podspec-persistent-volume-write": enabled
   ...

   • kubernetes.podspec-persistent-volume-claim 拡張機能は、永続ボリューム (PV) を Knative Serving で使用できるかどうかを制御します。
   • kubernetes.podspec-persistent-volume-write 拡張機能は、書き込みアクセスで Knative Serving が PV を利用できるかどうかを制御します。

2. PV を要求するには、PV 設定を含めるようにサービスを変更します。たとえば、次の設定で永続的なボリュームクレームがある場合があります。

   注記

   要求しているアクセスモードをサポートするストレージクラスを使用してください。たとえば、ReadWriteMany アクセスモードの ocs-storagecluster-cephfs クラスを使用できます。

   PersistentVolumeClaim 設定

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: example-pv-claim
     namespace: my-ns
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: ocs-storagecluster-cephfs
     resources:
       requests:
         storage: 1Gi

   この場合、書き込みアクセス権を持つ PV を要求するには、次のようにサービスを変更します。

   ネイティブサービス PVC 設定

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     namespace: my-ns
   ...
   spec:
    template:
      spec:
        containers:
            ...
            volumeMounts: 1
              - mountPath: /data
                name: mydata
                readOnly: false
        volumes:
          - name: mydata
            persistentVolumeClaim: 2
              claimName: example-pv-claim
              readOnly: false 3

   1

   ボリュームマウント仕様。

   2

   永続的なボリュームクレームの仕様。

   3

   読み取り専用アクセスを有効にするフラグ。

   注記

   Knative サービスで永続ストレージを正常に使用するには、Knative コンテナーユーザーのユーザー権限などの追加の設定が必要です。

手順

1. 仕様に internal-encryption: "true" フィールドを含む Knative サービスを作成します。

   ...
   spec:
     config:
       network:
         internal-encryption: "true"
   ...

2. knative-serving namespace でアクティベーター Pod を再起動して、証明書を読み込みます。

   $ oc delete pod -n knative-serving --selector app=activator

手順

1. アプリケーションへのアクセスを必要とする各 Knative システム namespace に knative.openshift.io/system-namespace=true ラベルを追加します。

   1. knative-serving namespace にラベルを付けます。

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true

   2. knative-serving-ingress namespace にラベルを付けます。

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true

   3. knative-eventing namespace にラベルを付けます。

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true

   4. knative-kafka namespace にラベルを付けます。

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true

2. アプリケーション namespace で NetworkPolicy オブジェクトを作成し、knative.openshift.io/system-namespace ラベルのある namespace からのアクセスを許可します。

   サンプル NetworkPolicy オブジェクト

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: <network_policy_name> 1
     namespace: <namespace> 2
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             knative.openshift.io/system-namespace: "true"
     podSelector: {}
     policyTypes:
     - Ingress

   1

   ネットワークポリシーの名前を指定します。

   2

   アプリケーションが存在する namespace。

1. Knative サービスをクリックし、サイドパネルの概要を表示します。

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

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

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

      

手順

1. アプリケーションを Knative サービスとして作成し、デプロイします。

2. 以下のコマンドから出力を表示して、サービスのデプロイ時に作成された最初のリビジョンの名前を検索します。

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   コマンドの例

   $ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'

   出力例

   $ example-service-00001

3. 以下の YAML をサービスの spec に追加して、受信トラフィックをリビジョンに送信します。

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic goes to this revision
   ...

4. 以下のコマンドを実行して、URL の出力でアプリケーションを表示できることを確認します。

   $ oc get ksvc <service_name>

5. サービスの template 仕様の少なくとも 1 つのフィールドを変更してアプリケーションの 2 番目のリビジョンをデプロイし、これを再デプロイします。たとえば、サービスの image や env 環境変数を変更できます。サービスの再デプロイは、サービスの YAML ファイルを適用するか、Knative (kn) CLI をインストールしている場合は、kn service update コマンドを使用します。

6. 以下のコマンドを実行して、サービスを再デプロイする際に作成された 2 番目の最新のリビジョンの名前を見つけます。

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   この時点で、サービスの最初のバージョンと 2 番目のリビジョンの両方がデプロイされ、実行されます。

7. 既存のサービスを更新して、2 番目のリビジョンの新規テストエンドポイントを作成し、他のすべてのトラフィックを最初のリビジョンに送信します。

   テストエンドポイントのある更新されたサービス仕様の例

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic is still being routed to the first revision
       - revisionName: <second_revision_name>
         percent: 0 # No traffic is routed to the second revision
         tag: v2 # A named route
   ...

   YAML リソースを再適用してこのサービスを再デプロイすると、アプリケーションの 番目のリビジョンがステージングされます。トラフィックはメインの URL の 2 番目のリビジョンにルーティングされず、Knative は新たにデプロイされたリビジョンをテストするために v2 という名前の新規サービスを作成します。

8. 以下のコマンドを実行して、2 番目のリビジョンの新規サービスの URL を取得します。

   $ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"

   この URL を使用して、トラフィックをルーティングする前に、新しいバージョンのアプリケーションが予想通りに機能していることを検証できます。

9. 既存のサービスを再度更新して、トラフィックの 50% が最初のリビジョンに送信され、50% が 2 番目のリビジョンに送信されます。

   リビジョン間でトラフィックを 50/50 に分割する更新サービス仕様の例

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 50
       - revisionName: <second_revision_name>
         percent: 50
         tag: v2
   ...

10. すべてのトラフィックを新しいバージョンのアプリケーションにルーティングできる状態になったら、再度サービスを更新して、100% のトラフィックを 2 番目のリビジョンに送信します。

    すべてのトラフィックを 2 番目のリビジョンに送信する更新済みのサービス仕様の例

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 0
        - revisionName: <second_revision_name>
          percent: 100
          tag: v2
    ...

    ヒント

    リビジョンのロールバックを計画しない場合は、これを 0% に設定する代わりに最初のリビジョンを削除できます。その後、ルーティング不可能なリビジョンオブジェクトにはガベージコレクションが行われます。

11. 最初のリビジョンの URL にアクセスして、アプリケーションの古いバージョンに送信されていないことを確認します。

手順

1. OpenShift Container Platform ルートに伝播するラベルまたはアノテーションが含まれる Knative サービスを作成します。

   • YAML を使用してサービスを作成するには、以下を実行します。

     YAML を使用して作成されるサービスの例

     apiVersion: serving.knative.dev/v1
     kind: Service
     metadata:
       name: <service_name>
       labels:
         <label_name>: <label_value>
       annotations:
         <annotation_name>: <annotation_value>
     ...

   • Knative (kn) CLI を使用してサービスを作成するには、次のように入力します。

     kn コマンドを使用して作成されるサービスの例

     $ kn service create <service_name> \
       --image=<image> \
       --annotation <annotation_name>=<annotation_value> \
       --label <label_value>=<label_value>

2. 以下のコマンドからの出力を検査して、OpenShift Container Platform ルートが追加したアノテーションまたはラベルで作成されていることを確認します。

   検証のコマンドの例

   $ oc get routes.route.openshift.io \
        -l serving.knative.openshift.io/ingressName=<service_name> \ 1
        -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ 2
        -n knative-serving-ingress -o yaml \
            | grep -e "<label_name>: \"<label_value>\""  -e "<annotation_name>: <annotation_value>" 3

   1

   サービスの名前を使用します。

   2

   サービスが作成された namespace を使用します。

   3

   ラベルおよびアノテーション名および値の値を使用します。

手順

1. serving.knative.openshift.io/disableRoute=true アノテーションが含まれる Knative サービスを作成します。

   重要

   serving.knative.openshift.io/disableRoute=true アノテーションは、OpenShift Serverless に対してルートを自動的に作成しないように指示します。ただし、サービスには URL が表示され、ステータスが Ready に達します。URL のホスト名と同じホスト名を使用して独自のルートを作成するまで、この URL は外部では機能しません。

   1. Service サービスリソースを作成します。

      リソースの例

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: <service_name>
        annotations:
          serving.knative.openshift.io/disableRoute: "true"
      spec:
        template:
          spec:
            containers:
            - image: <image>
      ...

   2. Service リソースを適用します。

      $ oc apply -f <filename>

   3. オプション:kn service create コマンドを使用して Knative サービスを作成します。

      kn コマンドの例

      $ kn service create <service_name> \
        --image=gcr.io/knative-samples/helloworld-go \
        --annotation serving.knative.openshift.io/disableRoute=true

2. サービス用に OpenShift Container Platform ルートが作成されていないことを確認します。

   コマンドの例

   $ $ oc get routes.route.openshift.io \
     -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \
     -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \
     -n knative-serving-ingress

   以下の出力が表示されるはずです。

   No resources found in knative-serving-ingress namespace.

3. knative-serving-ingress namespace で Route リソースを作成します。

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     annotations:
       haproxy.router.openshift.io/timeout: 600s 1
     name: <route_name> 2
     namespace: knative-serving-ingress 3
   spec:
     host: <service_host> 4
     port:
       targetPort: http2
     to:
       kind: Service
       name: kourier
       weight: 100
     tls:
       insecureEdgeTerminationPolicy: Allow
       termination: edge 5
       key: |-
         -----BEGIN PRIVATE KEY-----
         [...]
         -----END PRIVATE KEY-----
       certificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
       caCertificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE----
     wildcardPolicy: None

   1

   OpenShift Container Platform ルートのタイムアウト値。max-revision-timeout-seconds 設定と同じ値を設定する必要があります (デフォルトでは 600s)。

   2

   OpenShift Container Platform ルートの名前。

   3

   OpenShift Container Platform ルートの namespace。これは knative-serving-ingress である必要があります。

   4

   外部アクセスのホスト名。これを <service_name>-<service_namespace>.<domain> に設定できます。

   5

   使用する証明書。現時点で、edge termination のみがサポートされています。

4. Route リソースを適用します。

   $ oc apply -f <filename>

手順

1. サーバー証明書を knative-serving-ingress namespace にデプロイします。

   $ export san="knative"

   注記

   これらの証明書が <app_name>.<namespace>.svc.cluster.local への要求を処理できるように、Subject Alternative Name (SAN) の検証が必要です。

2. ルートキーと証明書を生成します。

   $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
       -subj '/O=Example/CN=Example' \
       -keyout ca.key \
       -out ca.crt

3. SAN 検証を使用するサーバーキーを生成します。

   $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
     -subj "/CN=Example/O=Example" \
     -addext "subjectAltName = DNS:$san"

4. サーバー証明書を作成します。

   $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
     -days 365 -in tls.csr \
     -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt

5. Courier ローカルゲートウェイのシークレットを設定します。

   1. 前の手順で作成した証明書から、knative-serving-ingress namespace にシークレットをデプロイします。

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -

   2. KnativeServing カスタムリソース (CR) 仕様を更新して、Kourier ゲートウェイによって作成されたシークレットを使用します。

      KnativeServing CR の例

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

手順

1. serverless.openshift.io/default-enable-http2=true アノテーションを KnativeServing カスタムリソースに追加します。

   $ oc annotate knativeserving <your_knative_CR> -n knative-serving serverless.openshift.io/default-enable-http2=true

2. アノテーションが追加されたら、Kourier サービスの appProtocol 値が h2c であることを確認できます。

   $ oc get svc -n knative-serving-ingress kourier -o jsonpath="{.spec.ports[0].appProtocol}"

   出力例

   h2c

3. 以下のように、外部トラフィックに HTTP/2 プロトコルで gRPC フレームワークを使用できるようになりました。

   import "google.golang.org/grpc"
   
   grpc.Dial(
      YOUR_URL, 1
      grpc.WithTransportCredentials(insecure.NewCredentials())), 2
   )

   1

   ksvc URL。

   2

   証明書。

手順

1. アプリケーションホストを検索します。サーバーレスアプリケーションのデプロイメントの確認の説明を参照してください。

2. Ingress ゲートウェイのパブリックアドレスを見つけます。

   $ oc -n knative-serving-ingress get svc kourier

   出力例

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
   kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

   パブリックアドレスは EXTERNAL-IP フィールドで表示され、この場合は a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com になります。

3. HTTP 要求のホストヘッダーを手動でアプリケーションのホストに手動で設定しますが、Ingress ゲートウェイのパブリックアドレスに対して要求自体をダイレクトします。

   $ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

   出力例

   Hello Serverless!

   Ingress ゲートウェイに対して直接 gRPC 要求を行うこともできます。

   import "google.golang.org/grpc"
   
   grpc.Dial(
       "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
       grpc.WithAuthority("hello-default.example.com:80"),
       grpc.WithInsecure(),
   )

   注記

   直前の例のように、それぞれのポート (デフォルトでは 80) を両方のホストに追加します。

手順

1. sidecar.istio.io/inject="true" アノテーションをサービスに追加します。

   サービスの例

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   sidecar.istio.io/inject="true" アノテーションを追加します。

   2

   OpenShift Serverless バージョン 1.14.0 以降では、HTTP プローブをデフォルトで Knative サービスの readiness プローブとして使用することから、Knative サービスでアノテーション sidecar.istio.io/rewriteAppHTTPProbers: "true" を設定する必要があります。

2. Service リソースを適用します。

   $ oc apply -f <filename>

3. ServiceMeshMemberRoll オブジェクトのメンバーである各サーバーレスアプリケーション namespace に RequestAuthentication リソースを作成します。

   apiVersion: security.istio.io/v1beta1
   kind: RequestAuthentication
   metadata:
     name: jwt-example
     namespace: <namespace>
   spec:
     jwtRules:
     - issuer: testing@secure.istio.io
       jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json

4. RequestAuthentication リソースを適用します。

   $ oc apply -f <filename>

5. 以下の AuthorizationPolicy リソースを作成して、ServiceMeshMemberRoll オブジェクトのメンバーである各サーバーレスアプリケーション namespace のシステム Pod からの RequestAuthenticaton リソースへのアクセスを許可します。

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allowlist-by-paths
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - to:
       - operation:
           paths:
           - /metrics 1
           - /healthz 2

   1

   システム Pod でメトリクスを収集するためのアプリケーションのパス。

   2

   システム Pod でプローブするアプリケーションのパス。

6. AuthorizationPolicy リソースを適用します。

   $ oc apply -f <filename>

7. ServiceMeshMemberRoll オブジェクトのメンバーであるサーバーレスアプリケーション namespace ごとに、以下の AuthorizationPolicy リソースを作成します。

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-jwt
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - from:
       - source:
          requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]

8. AuthorizationPolicy リソースを適用します。

   $ oc apply -f <filename>

検証

1. curl 要求を使用して Knative サービス URL を取得しようとすると、これは拒否されます。

   コマンドの例

   $ curl http://hello-example-1-default.apps.mycluster.example.com/

   出力例

   RBAC: access denied

2. 有効な JWT で要求を確認します。

   1. 有効な JWT トークンを取得します。

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. curl 要求ヘッダーで有効なトークンを使用してサービスにアクセスします。

      $ curl -H "Authorization: Bearer $TOKEN"  http://hello-example-1-default.apps.example.com

      これで要求が許可されます。

      出力例

      Hello OpenShift!

手順

1. sidecar.istio.io/inject="true" アノテーションをサービスに追加します。

   サービスの例

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   sidecar.istio.io/inject="true" アノテーションを追加します。

   2

   OpenShift Serverless バージョン 1.14.0 以降では、HTTP プローブをデフォルトで Knative サービスの readiness プローブとして使用することから、Knative サービスでアノテーション sidecar.istio.io/rewriteAppHTTPProbers: "true" を設定する必要があります。

2. Service リソースを適用します。

   $ oc apply -f <filename>

3. 有効な JSON Web Tokens (JWT) の要求のみを許可する ServiceMeshMemberRoll オブジェクトのメンバーであるサーバーレスアプリケーション namespace でポリシーを作成します。

   重要

   パスの /metrics および /healthz は、knative-serving namespace のシステム Pod からアクセスされるため、excludedPaths に組み込まれる必要があります。

   apiVersion: authentication.istio.io/v1alpha1
   kind: Policy
   metadata:
     name: default
     namespace: <namespace>
   spec:
     origins:
     - jwt:
         issuer: testing@secure.istio.io
         jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json"
         triggerRules:
         - excludedPaths:
           - prefix: /metrics 1
           - prefix: /healthz 2
     principalBinding: USE_ORIGIN

   1

   システム Pod でメトリクスを収集するためのアプリケーションのパス。

   2

   システム Pod でプローブするアプリケーションのパス。

4. Policy リソースを適用します。

   $ oc apply -f <filename>

検証

1. curl 要求を使用して Knative サービス URL を取得しようとすると、これは拒否されます。

   $ curl http://hello-example-default.apps.mycluster.example.com/

   出力例

   Origin authentication failed.

2. 有効な JWT で要求を確認します。

   1. 有効な JWT トークンを取得します。

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. curl 要求ヘッダーで有効なトークンを使用してサービスにアクセスします。

      $ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"

      これで要求が許可されます。

      出力例

      Hello OpenShift!

手順

1. マップ先となるターゲット CR と同じ namespace に DomainMapping CR が含まれる YAML ファイルを作成します。

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   ターゲット CR にマップするカスタムドメイン名。

   2

   DomainMapping CR とターゲット CR の両方の namespace。

   3

   カスタムドメインにマップするサービス名。

   4

   カスタムドメインにマップされる CR のタイプ。

   サービスドメインマッピングの例

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example-domain
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

   ルートドメインマッピングの例

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example-domain
    namespace: default
   spec:
    ref:
      name: example-route
      kind: Route
      apiVersion: serving.knative.dev/v1

2. DomainMapping CR を YAML ファイルとして適用します。

   $ oc apply -f <filename>

手順

1. Topology ページに移動します。
2. ドメインにマッピングするサービスを右クリックし、サービス名が含まれる Edit オプションを選択します。たとえば、サービスの名前が example-service である場合は、Edit example-service オプションを選択します。

3. Advanced options セクションで、Show advanced Routing options をクリックします。

   1. サービスにマッピングするドメインマッピング CR がすでに存在する場合は、ドメインマッピング リストで選択できます。
   2. 新規ドメインマッピング CR を作成する場合は、ドメイン名をボックスに入力し、Create オプションを選択します。たとえば、example.com と入力すると、Create オプションは Create "example.com" になります。
4. Save をクリックしてサービスへの変更を保存します。

検証

1. Topology ページに移動します。
2. 作成したサービスをクリックします。
3. サービス情報ウィンドウの Resources タブで、Domain mappings セクションにサービスにマッピングしたドメインが表示されます。

手順

1. CustomResourceDefinitions に移動し、検索ボックスを使用して DomainMapping カスタムリソース定義 (CRD) を検索します。
2. DomainMapping CRD をクリックしてから Instances タブに移動します。
3. Create DomainMapping をクリックします。

4. インスタンスの以下の情報が含まれるように DomainMapping CR の YAML を変更します。

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   ターゲット CR にマップするカスタムドメイン名。

   2

   DomainMapping CR とターゲット CR の両方の namespace。

   3

   カスタムドメインにマップするサービス名。

   4

   カスタムドメインにマップされる CR のタイプ。

   Knative サービスへのドメインマッピングの例

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: custom-ksvc-domain.example.com
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

手順

1. Kubernetes TLS シークレットを作成します。

   $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>

2. networking.internal.knative.dev/certificate-uid: <id>' ラベル を Kubernetes TLS シークレットに追加します。

   $ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"

   cert-manager などのサードパーティーのシークレットプロバイダーを使用している場合は、Kubernetes TLS シークレットに自動的にラベルを付けるようにシークレットマネージャーを設定できます。Cert-manager ユーザーは、提供されたシークレットテンプレートを使用して、正しいラベルを持つシークレットを自動的に生成できます。この場合、シークレットのフィルタリングはキーのみに基づいて行われますが、この値には、シークレットに含まれる証明書 ID などの有用な情報が含まれている可能性があります。

   注記

   Red Hat OpenShift の cert-manager Operator は、テクノロジープレビューの機能です。詳細は、Red Hat OpenShift ドキュメントの cert-manager Operator のインストール を参照してください。

3. 作成した TLS シークレットを使用するように DomainMapping CR を更新します。

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
     name: <domain_name>
     namespace: <namespace>
   spec:
     ref:
       name: <service_name>
       kind: Service
       apiVersion: serving.knative.dev/v1
   # TLS block specifies the secret to be used
     tls:
       secretName: <tls_secret_name>

検証

1. DomainMapping CR のステータスが True であることを確認し、出力の URL 列に、マップされたドメインをスキームの https で表示していることを確認します。

   $ oc get domainmapping <domain_name>

   出力例

   NAME                      URL                               READY   REASON
   example.com               https://example.com               True

2. オプション: サービスが公開されている場合は、以下のコマンドを実行してこれが利用可能であることを確認します。

   $ curl https://<domain_name>

   証明書が自己署名されている場合は、curl コマンドに -k フラグを追加して検証を省略します。

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHub → Installed Operators に移動します。
2. knative-serving namespace を選択します。
3. OpenShift Serverless Operator の Provided API 一覧で Knative Serving をクリックし、Knative Serving タブに移動します。

4. knative-serving をクリックしてから、knative-serving ページの YAML タブに移動します。

   

5. KnativeServing CR のレプリカ数を変更します。

   サンプル YAML

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     high-availability:
       replicas: 3

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 Serverless → Eventing に移動します。
2. Create 一覧で、Event Source を選択します。Event Sources ページに移動します。
3. 作成するイベントソースタイプを選択します。

1. イベントソースのサービスアカウント、ロールおよびロールバインディングを 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 に変更します。

2. YAML ファイルを適用します。

   $ oc apply -f <filename>

3. Developer パースペクティブで、+Add → Event Source に移動します。Event Sources ページが表示されます。
4. オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。
5. ApiServerSource を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。

6. Form view または YAML view を使用して、ApiServerSource 設定を設定します。

   注記

   Form view と YAML view 間で切り換えることができます。ビューの切り替え時に、データは永続化されます。

   1. APIVERSION に v1 を、KIND に Event を入力します。
   2. 作成したサービスアカウントの Service Account Name を選択します。
   3. イベントソースの Sink を選択します。Sink は、チャネル、ブローカー、またはサービスなどの Resource、または URI のいずれかになります。
7. Create をクリックします。

API サーバーソースの削除

1. Topology ビューに移動します。

2. API サーバーソースを右クリックし、Delete ApiServerSource を選択します。

   

1. イベントソースのサービスアカウント、ロールおよびロールバインディングを 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 に変更します。

2. YAML ファイルを適用します。

   $ oc apply -f <filename>

3. イベントシンクを持つ API サーバーソースを作成します。次の例では、シンクはブローカーです。

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

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

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

5. ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、default のブローカーからサービスへのイベントをフィルタリングします。

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

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

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

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

   $ 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

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

API サーバーソースの削除

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

   $ kn trigger delete <trigger_name>

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

   $ kn source apiserver delete <source_name>

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

   $ oc delete -f authentication.yaml

1. イベントソースのサービスアカウント、ロールおよびロールバインディングを 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 に変更します。

2. YAML ファイルを適用します。

   $ oc apply -f <filename>

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

4. ApiServerSource YAML ファイルを適用します。

   $ oc apply -f <filename>

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

6. Service YAML ファイルを適用します。

   $ oc apply -f <filename>

7. 直接の手順で作成下サービスに、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

8. Trigger YAML ファイルを適用します。

   $ oc apply -f <filename>

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

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

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

    $ 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

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

API サーバーソースの削除

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

   $ oc delete -f trigger.yaml

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

   $ oc delete -f k8s-events.yaml

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

   $ oc delete -f authentication.yaml

手順

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

   1. Developer パースペクティブで、+Add → YAML に移動します。

   2. サンプル 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

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

2. 直前の手順で作成したサービスと同じ namespace、またはイベントの送信先となる他のシンクと同じ namespace に ping ソースを作成します。

   1. Developer パースペクティブで、+Add → Event Source に移動します。Event Sources ページが表示されます。
   2. オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。

   3. Ping Source を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。

      注記

      Form view または YAML view を使用して PingSource 設定を設定し、これらのビューを切り換えることができます。ビューの切り替え時に、データは永続化されます。

   4. Schedule の値を入力します。この例では、値は */2 * * * * であり、2 分ごとにメッセージを送信する PingSource を作成します。
   5. オプション: Data の値を入力できます。これはメッセージのペイロードです。
   6. Sink を選択します。これは Resource または URI のいずれかになります。この例では、直前の手順で作成された event-display サービスが Resources シンクとして使用されます。
   7. Create をクリックします。

1. Developer パースペクティブで、Topology に移動します。

2. ping ソースおよびシンクを表示します。

   

ping ソースの削除

1. Topology ビューに移動します。
2. API サーバーソースを右クリックし、Delete Ping Source を選択します。

手順

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 ksvc: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 ファイルを作成します。

      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 -f <filename>

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

   1. ping ソースの YAML ファイルを作成します。

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

   2. ping ソースを作成します。

      $ oc apply -f <filename>

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

   $ oc get pingsource.sources.knative.dev <ping_source_name> -oyaml

   出力例

   apiVersion: sources.knative.dev/v1
   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/v1/namespaces/default/pingsources/test-ping-source
     uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
   spec:
     data: '{ 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. Developer パースペクティブで、+Add ページに移動し、Event Source を選択します。
2. Event Sources ページで、Type セクションの Kafka Source を選択します。

3. Kafka Source 設定を設定します。

   1. ブートストラップサーバー のコンマ区切りの一覧を追加します。
   2. トピック のコンマ区切りの一覧を追加します。
   3. コンシューマーグループ を追加します。
   4. 作成したサービスアカウントの Service Account Name を選択します。
   5. イベントソースの Sink を選択します。Sink は、チャネル、ブローカー、またはサービスなどの Resource、または URI のいずれかになります。
   6. Kafka イベントソースの Name を入力します。
4. Create をクリックします。

1. Developer パースペクティブで、Topology に移動します。

2. Kafka イベントソースおよびシンクを表示します。

   

手順

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

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

2. 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 オプションは任意です。

3. オプション: 作成した 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

検証手順

1. 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 トピックを使用するように設定されている。

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

手順

1. KafkaSource オブジェクトを YAML ファイルとして作成します。

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: <source_name>
   spec:
     consumerGroup: <group_name> 1
     bootstrapServers:
     - <list_of_bootstrap_servers>
     topics:
     - <list_of_topics> 2
     sink:
     - <list_of_sinks> 3

   1

   コンシューマーグループは、同じグループ ID を使用し、トピックからデータを消費するコンシューマーのグループです。

   2

   トピックは、データの保存先を提供します。各トピックは、1 つまたは複数のパーティションに分割されます。

   3

   シンクは、イベントがソースから送信される場所を指定します。

   重要

   OpenShift Serverless 上の KafkaSource オブジェクトの API の v1beta1 バージョンのみがサポートされます。非推奨となった v1alpha1 バージョンの API は使用しないでください。

   KafkaSource オブジェクトの例

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: kafka-source
   spec:
     consumerGroup: knative-group
     bootstrapServers:
     - my-cluster-kafka-bootstrap.kafka:9092
     topics:
     - knative-demo-topic
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

2. KafkaSource YAML ファイルを適用します。

   $ oc apply -f <filename>

手順

1. 選択された namespace にシークレットとして証明書ファイルを作成します。

   $ oc create secret -n <namespace> generic <kafka_auth_secret> \
     --from-file=ca.crt=caroot.pem \
     --from-literal=password="SecretPassword" \
     --from-literal=saslType="SCRAM-SHA-512" \ 1
     --from-literal=user="my-sasl-user"

   1

   SASL タイプは PLAIN、SCRAM-SHA-256、または SCRAM-SHA-512 です。

2. Kafka ソースを作成または変更して、次の spec 設定が含まれるようにします。

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: example-source
   spec:
   ...
     net:
       sasl:
         enable: true
         user:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: user
         password:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: password
         type:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: saslType
       tls:
         enable: true
         caCert: 1
           secretKeyRef:
             name: <kafka_auth_secret>
             key: ca.crt
   ...

   1

   パブリッククラウドの Kafka サービスを使用している場合は、caCert 仕様は必要ありません。

手順

1. +Add → Event Source に移動して任意のタイプのイベントソースを作成し、作成するイベントソースを選択します。
2. イベントソースの作成 フォームビューの シンク セクションで、リソース リストからシンクを選択します。
3. Create をクリックします。