Serverless

OpenShift Container Platform 4.7

OpenShift Serverless のインストール、使用法、およびリリースノート

概要

本書では、OpenShift Container Platform で OpenShift Serverless を使用する方法について説明します。

第1章 OpenShift Serverless リリースノート

OpenShift Serverless 機能の概要については、「OpenShift Serverless の使用開始」を参照してください。

注記

OpenShift Serverless はオープンソースの Knative プロジェクトに基づいています。

最新の Knative コンポーネントリリースの詳細は、Knative ブログ を参照してください。

1.1. API バージョンについて

OpenShift Serverless Operator は、最新バージョンを使用するように非推奨の API を使用する古いリソースを自動的にアップグレードします。

たとえば、v1beta1 などの古いバージョンの ApiServerSource API を使用するクラスターにリソースを作成した場合、OpenShift Serverless Operator はこれらのリソースを自動的に更新し、これが利用可能な場合に API の v1 バージョンを使用するように、v1beta1 バージョンは非推奨になりました。

非推奨となった古いバージョンは、今後のリリースで削除される可能性があります。API の非推奨バージョンを使用すると、リソースが失敗することはありません。ただし、削除された API のバージョンを使用しようとすると、リソースが失敗します。問題を回避するために、マニフェストが最新バージョンを使用するように更新されていることを確認します。

1.2. Red Hat OpenShift Serverless 1.17.0 のリリースノート

1.2.1. 新機能

  • OpenShift Serverless は Knative Serving 0.23.0 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.23.0 を使用するようになりました。
  • OpenShift Serverless は Kourier 0.23.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.23.0 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.23.0 を使用するようになりました。
  • kn func CLI プラグインは func 0.17.0 を使用するようになりました。
  • 今後の OpenShift Serverless 1.19.0 リリースでは、外部ルートの URL スキームはデフォルトで HTTPS になり、セキュリティーが強化されます。

    この変更をワークロードに適用する必要がない場合は、以下の YAML を KnativeServing カスタムリソース定義 (CRD) に追加してから 1.19.0 にアップグレードする前にデフォルト設定を上書きできます。

    ...
    spec:
      config:
        network:
          defaultExternalScheme: "http"
    ...
  • mTLS 機能は一般に利用可能 (GA) になりました。
  • kn func を使用して関数を作成すると、Typescript テンプレートが利用できるようになりました。
  • Knative Eventing 0.23.0 で API バージョンへの変更

    • OpenShift Serverless バージョン 1.14.0 で非推奨となった KafkaChannel API の v1alpha1 バージョンが削除されました。設定マップの ChannelTemplateSpec パラメーターにこの古いバージョンの参照が含まれる場合は、これを仕様のこの部分を更新して、正しい API バージョンを使用する必要があります。

1.2.2. 既知の問題

  • 新しい OpenShift Serverless リリースで古いバージョンの Knative kn CLI の使用を試行する場合は、API が見つからないとエラーが発生します。

    たとえば、バージョン 0.22.0 を使用する kn CLI の 1.16.0 リリースと、Knative Serving および Knative Eventing API の 0.23.0 バージョンを使用する 1.17.0 OpenShift Serverless リリースを使用する場合、CLI は、古い 0.22.0 API バージョンを探し続けるため、機能しません。

    問題を回避するために、OpenShift Serverless リリースの最新の kn CLI バージョンを使用していることを確認してください。

  • 本リリースでは、Kafka チャネルメトリクスは、対応する Web コンソールダッシュボードで監視されず、表示されません。これは、Kafka ディスパッチャーの調整プロセスが大幅に変更されたためです。
  • Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。

    その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。

    この問題および回避策の詳細は、ナレッジ記事 #6343981 を参照してください。

  • Camel-K 1.4 リリースは、OpenShift Serverless バージョン 1.17.0 と互換性がありません。これは、Camel-K 1.4 が Knative バージョン 0.23.0 で削除された API を使用するためです。現在、この問題に対する回避策はありません。OpenShift Serverless で Camel-K 1.4 を使用する必要がある場合は、OpenShift Serverless バージョン 1.17.0 にアップグレードしないでください。

1.3. Red Hat OpenShift Serverless 1.16.0 のリリースノート

1.3.1. 新機能

  • OpenShift Serverless は Knative Serving 0.22.0 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.22.0 を使用するようになりました。
  • OpenShift Serverless は Kourier 0.22.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.22.0 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.22.0 を使用するようになりました。
  • kn func CLI プラグインは func 0.16.0 を使用するようになりました。
  • kn func emit コマンドが関数 kn プラグインに追加されました。このコマンドを使用してイベントを送信し、ローカルにデプロイされた機能をテストできます。

1.3.2. 既知の問題

  • OpenShift Serverless 1.16.0 にアップグレードする前に、OpenShift Container Platform をバージョン 4.6.30、4.7.11、またはそれ以降にアップグレードする必要があります。
  • AMQ Streams Operator は、OpenShift Serverless Operator のインストールまたはアップグレードを妨げる可能性があります。これが生じる場合、以下のエラーが Operator Lifecycle Manager (OLM) によってスローされます。

    WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.

    この問題を修正するには、OpenShift Serverless Operator をインストールまたはアップグレードする前に AMQ Streams Operator をアンインストールしてください。その後、AMQ Streams Operator を再インストールできます。

  • サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。

    サービスメッシュおよび mTLS で使用する Knative Serving メトリクスを有効にする必要がある場合は、以下の手順を実行する必要があります。

    1. prometheus を Knative Serving カスタムリソース (CR) の observability 仕様で metrics.backend-destination として指定します。

      apiVersion: operator.knative.dev/v1alpha1
      kind: KnativeServing
      metadata:
        name: knative-serving
      spec:
        config:
          observability:
            metrics.backend-destination: "prometheus"

      この手順により、メトリクスがデフォルトで無効になることを防ぎます。

    2. 以下のネットワークポリシーを適用して、Prometheus namespace からのトラフィックを許可します。

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring-ns
        namespace: knative-serving
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                name: "openshift-monitoring"
        podSelector: {}
        policyTypes:
        - Ingress
    3. istio-system namespace のデフォルトのサービスメッシュコントロールプレーンを変更して再適用し、以下の仕様が含まれるようにします。

      spec:
        proxy:
          networking:
            trafficControl:
              inbound:
                excludedPorts:
                - 8444
  • Istio Ingress を有効にしてサービスメッシュ CR をデプロイする場合、istio-ingressgateway Pod に以下の警告が表示される可能性があります。

    2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found

    Knative サービスにもアクセスできない場合があります。

    以下の回避策を使用して、knative-local-gateway サービスを再作成することでこの問題を修正できます。

    1. istio-system namespace の既存のknative-local-gateway サービスを削除します。

      $ oc delete services -n istio-system knative-local-gateway
    2. 以下の YAML が含まれる knative-local-gateway サービスを作成し、適用します。

      apiVersion: v1
      kind: Service
      metadata:
       name: knative-local-gateway
       namespace: istio-system
       labels:
         experimental.istio.io/disable-gateway-port-translation: "true"
      spec:
       type: ClusterIP
       selector:
         istio: ingressgateway
       ports:
         - name: http2
           port: 80
           targetPort: 8081
  • クラスターに 1000 の Knative サービスがあり、Knative Serving の再インストールまたはアップグレードを実行する場合、KnativeServing カスタムリソース定義 (CRD) の状態が Ready になった後に最初の新しいサービスを作成すると遅延が生じます。

    3scale-kourier-control サービスは、新しいサービスの作成を処理する前に、既存のすべての Knative サービスを調整します。これにより、新規サービスは状態が Ready に更新されるまで、IngressNotConfigured または Unknown の状態で約 800 秒を費やすことになります。

  • Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。

    その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。

    この問題および回避策の詳細は、ナレッジ記事 #6343981 を参照してください。

1.4. Red Hat OpenShift Serverless 1.15.0 のリリースノート

1.4.1. 新機能

  • OpenShift Serverless は Knative Serving 0.21.0 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing Operator 0.21.0 を使用するようになりました。
  • OpenShift Serverless は Kourier 0.21.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.21.0 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.21.1 を使用するようになりました。
  • OpenShift Serverless Functions はテクノロジープレビューとして利用可能になりました。
重要

これまでプライベートサービスの作成に使用されていた serving.knative.dev/visibility ラベルは非推奨になりました。既存のサービスを更新して、代わりに networking.knative.dev/visibility ラベルを使用する必要があります。

1.4.2. 既知の問題

  • Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。

    その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。

    この問題および回避策の詳細は、ナレッジ記事 #6343981 を参照してください。

1.5. Red Hat OpenShift Serverless 1.14.0 のリリースノート

1.5.1. 新機能

  • OpenShift Serverless は Knative Serving 0.20.0 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.20.0 を使用しています。
  • OpenShift Serverless は Kourier 0.20.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.20.0 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.20.0 を使用するようになりました。
  • OpenShift Serverless での Knative Kafka は一般に利用可能 (GA) になりました。

    重要

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

  • OpenShift Serverless のインストールおよびアップグレード用の Operator チャネルが OpenShift Container Platform 4.6 以降のバージョンで stable に更新されました。
  • OpenShift Serverless は、IBM Power Systems、IBM Z、および LinuxONE でサポートされるようになりましたが、以下の機能はまだサポートされていません。

    • Knative Kafka の機能。
    • OpenShift Serverless 機能の developer プレビュー。

1.5.2. 既知の問題

  • Kafka チャネルのサブスクリプションには READY のマークが付けられず、SubscriptionNotMarkedReadyByChannel 状態のままになることがあります。これを修正するには、Kafka チャネルの dispatcher を再起動します。
  • Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。

    その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。

    この問題および回避策の詳細は、ナレッジ記事 #6343981 を参照してください。

1.6. Red Hat OpenShift Serverless 1.13.0 のリリースノート

1.6.1. 新機能

  • OpenShift Serverless は Knative Serving 0.19.0 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.19.2 を使用しています。
  • OpenShift Serverless は Kourier 0.19.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.19.1 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.19.1 を使用するようになりました。
  • DomainMapping カスタムリソース (CR)が OpenShift Serverless に追加され、ユーザーがカスタムドメイン名を Knative Service にマッピングできるようになりました。Knative ドキュメントで、カスタムドメイン名と Knative Service 間のマッピングの作成 について参照してください。
  • Knative Serving 0.19.0 では、ServiceRouteConfiguration、および Revision リソースの v1alpha1 および v1beta1 バージョンが削除されました。OpenShift Serverless Operator は古いリソースを v1 に自動的にアップグレードするため、ユーザーアクションは必要ありません。

    注記

    新規リソースは v1alpha1 または v1beta1 バージョンとして作成することはできません。これによりエラーが発生する可能性があり、これらのリソースは自動的にアップグレードされないためです。

1.7. Red Hat OpenShift Serverless 1.12.0 のリリースノート

1.7.1. 新機能

  • OpenShift Serverless は Knative Serving 0.18.2 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.18.6 を使用しています。
  • OpenShift Serverless は Kourier 0.18.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.18.4 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.18.0 を使用するようになりました。

1.7.2. 修正された問題

  • 以前のバージョンでは、他のすべての Knative Eventing コンポーネントをアンインストールし、削除した後に OpenShift Serverless で ping source を使用した場合、pingsource-jobrunner デプロイメントは削除されませんでした。この問題は修正され、pingsource-jobrunner デプロイメントの名前が pingsource-mt-adapter に変更されました。
  • 以前のバージョンでは、接続された SinkBinding リソースを削除する前にシンクを削除すると、リソースの削除がハングしていました。この問題は修正されています。

1.7.3. 既知の問題

  • KafkaChannel オブジェクトの eventing.knative.dev/scope: namespace アノテーションの使用はサポートされていません。

1.8. Red Hat OpenShift Serverless 1.11.0 のリリースノート

1.8.1. 新機能

  • OpenShift Serverless での Knative Eventing は一般に利用可能 (GA) になりました。
  • Kafka チャネルや Kafka イベントソースなどの Knative Kafka 機能は、OpenShift Serverless でテクノロジープレビューとして利用できるようになりました。Kafka 統合は OpenShift Serverless Operator 経由で提供され、これに別個のコミュニティー Operator のインストールは必要ありません。
  • OpenShift Serverless 機能は、標準の Knative kn CLI インストールを使用して開発者プレビューとして提供されるようになりました。この機能は、Red Hat では実稼働デプロイメント用にはサポートされていませんが、開発およびテスト目的で使用することができます。kn func CLI の使用による OpenShift Serverless 機能の使用についての詳細は、OpenShift Serverless 機能の開発者プレビューについてのドキュメントを参照してください。
  • OpenShift Serverless は Knative Serving 0.17.3 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.17.2 を使用しています。
  • OpenShift Serverless は Kourier 0.17.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.17.3 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.17.1 を使用するようになりました。

1.8.2. 既知の問題

  • Horizontal Pod Autoscaler (HPA) が broker-ingress Pod をスケールアップする場合、imc-dispatcher Pod は返答を転送できない場合があります。これは、新規の broker-ingress Pod の場合、readiness プローブがないために接続を受け入れる前に Ready (準備状態) になるためです。HPA 自動スケーリングを使用し、broker-ingress Pod を手動でスケーリングする必要がない場合は、Broker.Spec.Delivery で再試行を設定する必要があります。
  • eventing.knative.dev/scope: namespace アノテーションと Kafka チャネルの使用はサポートされません。

1.9. Red Hat OpenShift Serverless 1.10.0 のリリースノート

1.9.1. 新機能

  • OpenShift Serverless は Knative Operator 0.16.0 を使用するようになりました。
  • OpenShift Serverless は Knative Serving 0.16.0 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.16.0 を使用しています。
  • OpenShift Serverless は Kourier 0.16.0 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.16.1 を使用するようになりました。
  • これまでブローカー作成の namespace にラベルを付けるために使用されていた knative-eventing-injection=enabled アノテーションが非推奨になりました。新しいアノテーションは eventing.knative.dev/injection=enabled です。詳細は、ブローカーおよびトリガーについて参照してください。
  • マルチコンテナーのサポートがテクノロジープレビュー機能として Knative で利用可能になりました。config-features 設定マップでマルチコンテナーのサポートを有効にすることができます。詳細は、Knative ドキュメント を参照してください。

1.9.2. 修正された問題

  • 以前のリリースでは、Knative Serving には queue-proxy 用に固定された最小の CPU 要求 25m が含まれていました。クラスターにこの値と競合する値が設定されていた場合、たとえば defaultRequest の最小 CPU 要求として 25m を超える値が設定されていた場合、Knative サービスはデプロイに失敗しました。この問題は 1.10.0 で修正されています。

第2章 OpenShift Serverless のサポート

2.1. サポート

本書で説明されている手順で問題が発生した場合は、Red Hat カスタマーポータル (http://access.redhat.com) にアクセスしてください。カスタマーポータルでは、次のことができます。

  • Red Hat 製品に関する技術サポート記事の Red Hat ナレッジベースの検索またはブラウズ。
  • Red Hat グローバルサポートサービス (GSS) へのサポートケースの送信
  • その他の製品ドキュメントへのアクセス

本書の改善が提案されている場合やエラーが見つかった場合は、Documentation コンポーネントの Product に対して、http://bugzilla.redhat.com から Bugzilla レポートを送信してください。コンテンツを簡単に見つけられるよう、セクション番号、ガイド名、OpenShift Serverless のバージョンなどの詳細情報を記載してください。

2.2. サポート用の診断情報の収集

サポートケースを作成する際、ご使用のクラスターについてのデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。

must-gather ツールを使用すると、OpenShift Serverless に関連するデータを含む、 OpenShift Container Platform クラスターについての診断情報を収集できます。

迅速なサポートを得るには、OpenShift Container Platform と OpenShift Serverless の両方の診断情報を提供してください。

2.2.1. must-gather ツールについて

oc adm must-gather CLI コマンドは、以下のような問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。

  • リソース定義
  • 監査ログ
  • サービスログ

--image 引数を指定してコマンドを実行する際にイメージを指定できます。イメージを指定する際、ツールはその機能または製品に関連するデータを収集します。

oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

2.2.2. OpenShift Serverless データの収集について

oc adm must-gather CLI コマンドを使用してクラスターについての情報を収集できます。これには、OpenShift Serverless に関連する機能およびオブジェクトが含まれます。must-gather を使用して OpenShift Serverless データを収集するには、インストールされたバージョンの OpenShift Serverless イメージおよびイメージタグを指定する必要があります。

手順

  • oc adm must-gather コマンドを使用してデータを収集します。

    $ oc adm must-gather --image=registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8:<image_version_tag>

    コマンドの例

    $ oc adm must-gather --image=registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8:1.14.0

第3章 OpenShift Serverless の使用開始

OpenShift Serverless は、開発者のインフラストラクチャーのセットアップまたはバックエンド開発に対する要件を軽減することにより、開発から実稼働までのコードの提供プロセスを単純化します。

Serverless は、アプリケーション開発者がサーバーのプロビジョニングやアプリケーションのスケーリングを管理する必要がないクラウドコンピューティングのモデルです。これらのルーチンタスクはプラットフォームによって抽象化されるため、開発者は従来のモデルの場合よりも速くコードを実稼働にプッシュできます。

3.1. OpenShift Serverless の仕組み

OpenShift Serverless 上の開発者は、使い慣れた言語およびフレームワークと共に、提供される Kubernetes ネイティブの API を使用してアプリケーションおよびコンテナーのワークロードをデプロイできます。

OpenShift Container Platform 上の OpenShift Serverless を使用することにより、ステートレスのサーバーレスワークロードのすべてを、自動化された操作によって単一のマルチクラウドコンテナープラットフォームで実行することができます。開発者は、それぞれのマイクロサービス、レガシーおよびサーバーレスアプリケーションをホストするために単一プラットフォームを使用することができます。

OpenShift Serverless はオープンソースの Knative プロジェクトをベースとし、エンタープライズレベルのサーバーレスプラットフォームを有効にすることで、ハイブリッドおよびマルチクラウド環境における移植性と一貫性をもたらします。

3.2. サポートされる設定

OpenShift Serverless(最新バージョンおよび以前のバージョン) のサポートされる機能、設定、および統合のセットは、サポートされる設定についてのページで確認できます。

3.3. 次のステップ

第4章 管理ガイド

4.1. OpenShift Serverless Operator のインストール

以下では、クラスター管理者を対象に、OpenShift Serverless Operator の OpenShift Container Platform クラスターへのインストールについて説明します。

注記

OpenShift Serverless は、ネットワークが制限された環境でのインストールに対してサポートされません。詳細は、「ネットワークが制限された環境での Operator Lifecycle Manager の使用」を参照してください。

4.1.1. OpenShift Serverless インストールのクラスターサイズ要件の定義

OpenShift Serverless をインストールし、使用するには、OpenShift Container Platform クラスターのサイズを適切に設定する必要があります。

注記

以下の要件は、OpenShift Container Platform クラスターのワーカーマシンのプールにのみ関連します。コントロールプレーンは一般的なスケジューリングには使用されず、要件から省略されます。

OpenShift Serverless を実行するための合計サイズ要件は、デプロイされたアプリケーションによって異なります。デフォルトで、各 Pod は約 400m の CPU を要求し、推奨値のベースはこの値になります。アプリケーションの実際の CPU 要求を減らすと、レプリカ数が増える可能性があります。

注記

以下の制限は、すべての OpenShift Serverless デプロイメントに適用されます。

  • Knative サービスの最大数: 1000
  • Knative リビジョンの最大数: 1000

クラスターで高可用性 (HA) を有効にしている場合、これには Knative Serving コントロールプレーンの各レプリカについて 0.5 - 1.5 コアおよび 200MB - 2GB のメモリーが必要です。

HA は、デフォルトで一部の Knative Serving コンポーネントについて有効にされます。OpenShift Serverless での高可用性レプリカの設定についてのドキュメントに従って HA を無効にできます。

4.1.2. マシンセットを使用したクラスターのスケーリング

OpenShift Container Platform MachineSet API を使用して、クラスターを必要なサイズに手動でスケールアップすることができます。最小要件は、通常 2 つのマシンを追加することによってデフォルトのマシンセットのいずれかをスケールアップする必要があることを意味します。「マシンセットの手動によるスケーリング」を参照してください。

4.1.3. OpenShift Serverless Operator のインストール

この手順では、OpenShift Container Platform Web コンソールを使用して、OperatorHub から OpenShift Serverless Operator をインストールし、これにサブスクライブする方法を説明します。

重要

最新の Serverless リリースにアップグレードする前に、事前にインストールしている場合には、コミュニティー Knative Eventing Operator を削除する必要があります。Knative Eventing Operator をインストールすると、OpenShift Serverless Operator を使用して Knative Eventing の最新のバージョンをインストールできなくなります。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. スクロールするか、またはこれらのキーワード ServerlessFilter by keyword ボックス に入力して OpenShift Serverless Operator を検索します。

    OpenShift Serverless Operator in the OpenShift Container Platform web console
  3. Operator についての情報を確認してから、Install をクリックします。
  4. Install Operator ページで以下を行います。

    1. Installation ModeAll namespaces on the cluster (default) になります。このモードは、デフォルトの openshift-serverless namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。
    2. Installed Namespaceopenshift-serverless になります。
    3. Update Channel として stable チャネルを選択します。stable チャネルは、OpenShift Serverless Operator の最新の安定したリリースのインストールを可能にします。
    4. Automatic または Manual 承認ストラテジーを選択します。
  5. Install をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。
  6. CatalogOperator Management ページから、OpenShift Serverless Operator サブスクリプションのインストールおよびアップグレードの進捗をモニターできます。

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

検証

サブスクリプションのアップグレードステータスが Up to date に移行したら、CatalogInstalled Operators を選択して OpenShift Serverless Operator が表示され、その Status が最終的に関連する namespace で InstallSucceeded に解決することを確認します。

上記通りにならない場合:

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

4.1.4. 次のステップ

  • OpenShift Serverless Operator がインストールされた後に、Knative Serving コンポーネントをインストールできます。Knative Serving のインストールについてのドキュメントを参照してください。
  • OpenShift Serverless Operator がインストールされた後に、Knative Eventing コンポーネントをインストールできます。Knative Eventing のインストールについてのドキュメントを参照してください。

4.2. Knative Serving のインストール

OpenShift Serverless Operator をインストールした 後に、Knative Serving をインストールできます。

本書では、デフォルト設定を使用した Knative Serving のインストールについて説明します。ただし、KnativeServing カスタムリソース定義 (CRD) でより高度な設定を行うことができます。KnativeServing CRD の設定オプションの詳細は、Knative Serving 詳細設定オプション を参照してください。

4.2.1. 前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift Serverless Operator がインストールされている。

4.2.2. Web コンソールを使用した Knative Serving のインストール

手順

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

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

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

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

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

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

      注記

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

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

    Installed Operators page

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

検証

  1. Knative Serving タブで knative-serving カスタムリソースをクリックします。
  2. Knative Serving Overview ページに自動的にダイレクトされます。

    Installed Operators page
  3. スクロールダウンして、Conditions の一覧を確認します。
  4. ステータスが True の条件の一覧が表示されます(例のイメージを参照)。

    Conditions
    注記

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

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

4.2.3. YAML を使用した Knative Serving のインストール

手順

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

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
        name: knative-serving
        namespace: knative-serving
  2. 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
    webhook-5c7d878c7c-n267j           1/1     Running   0          9m35s

4.2.4. Knative Serving 詳細設定オプション

重要

config フィールドに含まれる YAML は変更しないでください。このフィールドの設定値の一部は OpenShift Serverless Operator によって挿入され、これらを変更すると、デプロイメントはサポートされなくなります。

Create Knative Serving form in web console Administrator Perspective

4.2.4.1. コントローラーのカスタム証明書

レジストリーが自己署名証明書を使用する場合、設定マップまたはシークレットを作成して、tag-to-digest の解決策を有効にする必要があります。tag-to-digest の解決策を有効にするには、Knative Serving コントローラーがコンテナーレジストリーにアクセスする必要があります。

以下の例の KnativeServing カスタムリソース設定は、knative-serving namespace の certs という名前の設定マップの証明書を使用します。この例では、以下を実行するために OpenShift Serverless Operator をトリガーします。

  1. コントローラーに証明書を含むボリュームを作成してマウントします。
  2. 必要な環境変数を適切に設定します。

サンプル YAML

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: config-service-ca
    type: ConfigMap 1

1
サポートされるタイプは ConfigMap および Secret です。

コントローラーカスタム証明書が指定されていない場合、この設定は config-service-ca 設定マップを使用するようにデフォルト設定されます。

tag-to-digest の解決策が有効にされた後に、OpenShift Serverless Operator は Knative Serving コントローラーをレジストリーにアクセスできるように自動的に設定します。

重要

設定マップまたはシークレットは Knative Serving カスタムリソース定義 (CRD) と同じ namespace になければなりません。

4.2.4.2. 高可用性

spec.high-availability フィールドを使用して設定できる高可用性は、Knative Serving のインストール時にユーザーがレプリカ数を指定されていない場合に、コントローラーごとに 2 レプリカにデフォルト設定されます。

これを 1 に設定して高可用性を無効にするか、またはより高い整数を設定してレプリカを追加できます。

サンプル YAML

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

4.2.5. 次のステップ

  • OpenShift Serverless のクラウドイベント機能については、Knative Eventing コンポーネントをインストールできます。Knative Eventing のインストールについてのドキュメントを参照してください。

4.3. Knative Eventing のインストール

OpenShift Serverless Operator のインストール後に、本書で説明されている手順に従って Knative Eventing をインストールできます。

本書では、デフォルト設定を使用した Knative Eventing のインストールについて説明します。

4.3.1. 前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift Serverless Operator がインストールされている。

4.3.2. Web コンソールを使用した Knative Eventing のインストール

手順

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

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

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

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

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

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

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

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

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

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

    Installed Operators page

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

検証

  1. Knative Eventing タブで knative-eventing カスタムリソースをクリックします。
  2. Knative Eventing Overview ページに自動的にダイレクトされます。

    Knative Eventing Overview page
  3. スクロールダウンして、Conditions の一覧を確認します。
  4. ステータスが True の条件の一覧が表示されます(例のイメージを参照)。

    Conditions
    注記

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

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

4.3.3. YAML を使用した Knative Eventing のインストール

手順

  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

4.4. OpenShift Serverless のアップグレード

以前のバージョンの OpenShift Serverless をインストールしている場合には、本ガイドの手順に従って最新バージョンにアップグレードしてください。

重要

最新の Serverless リリースにアップグレードする前に、事前にインストールしている場合には、コミュニティー Knative Eventing Operator を削除する必要があります。Knative Eventing Operator をインストールすると、OpenShift Serverless Operator を使用して Knative Eventing の最新のバージョンをインストールできなくなります。

4.4.1. サブスクリプションチャネルのアップグレード

前提条件

  • 以前のバージョンの OpenShift Serverless Operator をインストールし、インストールプロセス時に自動更新を選択している。

    注記

    手動更新を選択した場合は、本書で説明するようにチャネルの更新後に追加の手順を実行する必要があります。Subscription のアップグレードステータスは、その Install Plan を確認し、承認するまで Upgrading のままになります。Install Plan についての詳細は、OpenShift Container Platform Operator のドキュメントを参照してください。

  • OpenShift Container Platform Web コンソールにログインしている。

手順

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

検証

アップグレードが成功したことを確認するには、knative-serving namespace の Pod のステータスと KnativeServing カスタムリソースのバージョンを確認します。

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

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

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

  2. KnativeServing カスタムリソースのバージョンを確認します。

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

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

4.5. OpenShift Serverless の削除

本書では、OpenShift Serverless Operator および他の OpenShift Serverless コンポーネントを削除する方法を説明します。

注記

OpenShift Serverless Operator を削除する前に、Knative Serving および Knative Eventing を削除する必要があります。

4.5.1. Knative Serving のアンインストール

Knative Serving をアンインストールするには、そのカスタムリソースを削除してから knative-serving namespace を削除する必要があります。

手順

  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

4.5.2. Knative Eventing のアンインストール

Knative Eventing をアンインストールするには、そのカスタムリソースを削除してから knative-eventing namespace を削除する必要があります。

手順

  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

4.5.3. OpenShift Serverless Operator の削除

Operator のクラスターからの削除方法 についての OpenShift Container Platform の説明に従って、OpenShift Serverless Operator をホストクラスターから削除できます。

4.5.4. OpenShift Serverless カスタムリソース定義の削除

OpenShift Serverless のアンインストール後に、Operator および API カスタムリソース定義 (CRD) はクラスター上に残ります。以下の手順を使用して、残りの CRD を削除できます。

重要

Operator および API CRD を削除すると、Knative サービスを含む、それらを使用して定義されたすべてのリソースも削除されます。

前提条件

  • Knative Serving をアンインストールし、OpenShift Serverless Operator を削除していること。

手順

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

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

4.6. サービスメッシュと OpenShift Serverless の統合

OpenShift Serverless でサービスメッシュを使用すると、開発者は追加のネットワークおよびルーティングオプションを設定できます。

OpenShift Serverless Operator は、Knative のデフォルト Ingress として Kourier を提供します。ただし、Kourier が有効であるかどうかにかかわらず、OpenShift Serverless でサービスメッシュを使用できます。Kourierを無効にして統合すると、Kourier Ingress でサポートされていない追加のネットワークおよびルーティングオプションを設定できます。

重要

OpenShift Serverless は、本書で明示的に文書化されている Red Hat OpenShift Service Mesh 機能の使用のみをサポートし、文書化されていない他の機能はサポートしません。

4.6.1. サービスメッシュと OpenShift Serverless のネイティブに統合

サービスメッシュを Kourier なしで OpenShift Serverless とネイティブに統合すると、mTLS 機能などのデフォルトの Kourier Ingress でサポートされていない追加のネットワークおよびルーティングオプションを使用できます。

以下の手順の例では、ドメイン example.com を使用しています。このドメインの証明書のサンプルは、サブドメイン証明書に署名する認証局 (CA) として使用されます。

お使いのデプロイメントでこの手順を完了し、検証するには、一般に信頼されているパブリック CA によって署名された証明書、または組織が提供する CA のいずれかが必要です。コマンドの例は、ドメイン、サブドメイン、および CA に合わせて調整する必要があります。

ワイルドカード証明書を OpenShift Container Platform クラスターのドメインに一致するように設定する必要があります。たとえば、OpenShift Container Platform コンソールアドレスが https://console-openshift-console.apps.openshift.example.com の場合、ドメインが *.apps.openshift.example.com になるようにワイルドカード証明書を設定する必要があります。ワイルドカード証明書の設定に関する詳細は、「着信外部トラフィックを暗号化する証明書の作成」のトピックを参照してください。

デフォルトの OpenShift Container Platform クラスタードメインのサブドメインではないものを含むドメイン名を使用する必要がある場合は、これらのドメインのドメインマッピングを設定する必要があります。詳細は、OpenShift Serverless ドキュメントの「カスタムドメインマッピングの作成」を参照してください。

4.6.1.1. 着信外部トラフィックを暗号化する証明書の作成

デフォルトでは、サービスメッシュ mTLS 機能は、Ingress ゲートウェイとサイドカーを持つ個々の Pod 間で、サービスメッシュ自体内のトラフィックのみを保護します。OpenShift Container Platform クラスターに流入するトラフィックを暗号化するには、OpenShift Serverless とサービスメッシュの統合を有効にする前に証明書を生成する必要があります。

手順

  1. Knative サービスの証明書に署名する root 証明書と秘密鍵を作成します。

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example Inc./CN=example.com' \
        -keyout root.key \
        -out root.crt
  2. ワイルドカード証明書を作成します。

    $ openssl req -nodes -newkey rsa:2048 \
        -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \
        -keyout wildcard.key \
        -out wildcard.csr
  3. ワイルドカード証明書を署名します。

    $ openssl x509 -req -days 365 -set_serial 0 \
        -CA root.crt \
        -CAkey root.key \
        -in wildcard.csr \
        -out wildcard.crt
  4. ワイルドカード証明書を使用してシークレットを作成します。

    $ oc create -n istio-system secret tls wildcard-certs \
        --key=wildcard.key \
        --cert=wildcard.crt

    この証明書は、OpenShift Serverless をサービスメッシュと統合する際に作成されるゲートウェイによって取得され、Ingress ゲートウェイはこの証明書でトラフィックを提供します。

4.6.1.2. サービスメッシュと OpenShift Serverless の統合

以下の手順を実行して、Kourier を使用せずにサービスメッシュを OpenShift Serverless と統合できます。

前提条件

  • OpenShift Serverless Operator が OpenShift Container Platform クラスターにインストールされています。
  • Red Hat OpenShift Service Mesh がインストールされています。OpenShift Serverless with Service Mesh は、Red Hat OpenShift Service Mesh バージョン2.0.5 以降での使用でのみサポートされます。
重要

以下の手順を完了する前に、Knative Serving コンポーネントをインストールしないでください。Knative Serving をサービスメッシュと統合するために KnativeServing カスタムリソース定義 (CRD) を作成する際に必要な追加の手順があります。これは、管理ガイド の一般的な Knative Serving のインストール手順では説明されていません。

手順

  1. istio-system namespace に ServiceMeshControlPlane オブジェクトを作成します。mTLS 機能を使用する必要がある場合は、これを istio-system namespace に対して有効にする必要があります。
  2. サービスメッシュと統合する必要のある namespace をメンバーとして ServiceMeshMemberRoll オブジェクトに追加します。

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members: 1
        - knative-serving
        - <namespace>
    1
    サービスメッシュと統合する namespace の一覧。
    重要

    この namespace の一覧には、knative-serving namespace が含まれる必要があります。

  3. ServiceMeshMemberRoll リソースを適用します。

    $ oc apply -f <filename>
  4. サービスメッシュがトラフィックを受け入れることができるように、必要なゲートウェイを作成します。

    HTTP を使用した knative-local-gateway オブジェクトの例

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: knative-ingress-gateway
      namespace: knative-serving
    spec:
      selector:
        istio: ingressgateway
      servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
          hosts:
            - "*"
          tls:
            mode: SIMPLE
            credentialName: <wildcard_certs> 1
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
     name: knative-local-gateway
     namespace: knative-serving
    spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 8081
           name: http
           protocol: HTTP 2
         hosts:
           - "*"
    ---
    apiVersion: v1
    kind: Service
    metadata:
     name: knative-local-gateway
     namespace: istio-system
     labels:
       experimental.istio.io/disable-gateway-port-translation: "true"
    spec:
     type: ClusterIP
     selector:
       istio: ingressgateway
     ports:
       - name: http2
         port: 80
         targetPort: 8081

    1
    ワイルドカード証明書の名前を追加します。
    2
    knative-local-gateway は HTTP トラフィックに対応します。HTTP を使用するということは、サービスメッシュの外部から来るが、example.default.svc.cluster.local などの内部ホスト名を使用するトラフィックは、暗号化されていないことを意味します。別のワイルドカード証明書と、異なる protocol 仕様を使用する追加のゲートウェイを作成することで、このパスの暗号化を設定できます。

    HTTPS を使用した knative-local-gateway オブジェクトの例

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: knative-local-gateway
      namespace: knative-serving
    spec:
      selector:
        istio: ingressgateway
      servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
          hosts:
            - "*"
          tls:
            mode: SIMPLE
            credentialName: <wildcard_certs>

  5. Gateway リソースを適用します。

    $ oc apply -f <filename>
  6. 以下の KnativeServing カスタムリソース定義 (CRD) を作成して Knative Serving をインストールします。これにより、Istio 統合も有効化されます。

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      ingress:
        istio:
          enabled: true 1
      deployments: 2
      - name: activator
        annotations:
          "sidecar.istio.io/inject": "true"
          "sidecar.istio.io/rewriteAppHTTPProbers": "true"
      - name: autoscaler
        annotations:
          "sidecar.istio.io/inject": "true"
          "sidecar.istio.io/rewriteAppHTTPProbers": "true"
    1
    Istio 統合を有効にします。
    2
    Knative Serving データプレーン Pod のサイドカーの挿入を有効にします。
  7. KnativeServing リソースを適用します。

    $ oc apply -f <filename>
  8. サイドカー挿入が有効で、パススルールートを使用する Knative サービスを作成します。

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: <service_name>
      namespace: <namespace> 1
      annotations:
        serving.knative.openshift.io/enablePassthrough: "true" 2
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "true" 3
            sidecar.istio.io/rewriteAppHTTPProbers: "true"
        spec:
          containers:
          - image: <image_url>
    1
    サービスメッシュメンバーロールの一部である namespace。
    2
    OpenShift Container Platform のパススルーが有効化されたルートを生成するよう Knative Serving に指示します。これにより、生成した証明書は Ingress ゲートウェイ経由で直接提供されます。
    3
    Service Mesh サイドカーは Knative サービス Pod に挿入します。
  9. Service リソースを適用します。

    $ oc apply -f <filename>

検証

  • CA によって信頼されるようになった安全な接続を使用して、サーバーレスアプリケーションにアクセスします。

    $ curl --cacert root.crt <service_url>

    コマンドの例

    $ curl --cacert root.crt https://hello-default.apps.openshift.example.com

    出力例

    Hello Openshift!

4.6.2. Kourier が有効にされている場合のサービスメッシュの OpenShift Serverless との統合

前提条件

  • OpenShift Serverless Operator が OpenShift Container Platform クラスターにインストールされています。
  • Red Hat OpenShift Service Mesh がインストールされています。OpenShift Serverless with Service Mesh and Kourier は、Red Hat OpenShift Service Mesh バージョン 1.x および 2.x の両方での使用がサポートされています。
  • Knative Serving がインストールされています。

手順

  1. サービスメッシュと統合する必要のある namespace をメンバーとして ServiceMeshMemberRoll オブジェクトに追加します。

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        - <namespace> 1
    1
    サービスメッシュと統合する namespace の一覧。
  2. ServiceMeshMemberRoll リソースを適用します。

    $ oc apply -f <filename>
  3. Knative システム Pod から Knative サービスへのトラフィックフローを許可するネットワークポリシーを作成します。

    1. serving.knative.openshift.io/system-namespace=true ラベルを knative-serving namespace に追加します。

      $ oc label namespace knative-serving serving.knative.openshift.io/system-namespace=true
    2. serving.knative.openshift.io/system-namespace=true ラベルを knative-serving-ingress namespace に追加します。

      $ oc label namespace knative-serving-ingress serving.knative.openshift.io/system-namespace=true
    3. サービスメッシュと統合する必要のある namespace ごとに、NetworkPolicy リソースを作成します。

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-serving-system-namespace
        namespace: <namespace> 1
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                serving.knative.openshift.io/system-namespace: "true"
        podSelector: {}
        policyTypes:
        - Ingress
      1
      サービスメッシュと統合する必要のある namespace を追加します。
    4. NetworkPolicy リソースを適用します。

      $ oc apply -f <filename>

4.7. Administrator パースペクティブでの Eventing コンポーネントの作成

Web コンソールの Administrator パースペクティブで OpenShift Serverless を使用して Knative Eventing コンポーネントを作成できます。

4.7.1. Administrator パースペクティブを使用したイベントソースの作成

クラスター管理者のパーミッションを持つ場合、OpenShift Container Platform Web コンソールの Administrator パースペクティブを使用してイベントソースを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。

手順

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

サポートされるイベントソースのタイプや、OpenShift Serverless を使用して作成できるイベントソースのタイプについては、「イベントソースについて」を参照してください。

4.7.2. Administrator パースペクティブを使用したブローカーの作成

クラスター管理者のパーミッションを持つ場合、OpenShift Container Platform Web コンソールの Administrator パースペクティブを使用してブローカーを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 ServerlessEventing に移動します。
  2. Create 一覧で、Broker を選択します。Create Broker ページに移動します。
  3. オプション: ブローカーの YAML 設定を変更します。
  4. Create をクリックします。

4.7.3. Administrator パースペクティブを使用したトリガーの作成

クラスター管理者のパーミッションを持ち、ブローカーを作成している場合、Web コンソールの Administrator パースペクティブを使用してブローカーに接続するためのトリガーを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • ブローカーを作成している。
  • サブスクライバーとして使用する Knative サービスを作成している。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 ServerlessEventing に移動します。
  2. Broker タブで、トリガーを追加するブローカーの Options メニュー kebab を選択します。
  3. 一覧で Add Trigger をクリックします。
  4. Add Trigger のダイアログボックスで、Trigger の Subscriber を選択します。サブスクライバーは、ブローカーからイベントを受信する Knative サービスです。
  5. Add をクリックします。

4.7.4. Administrator パースペクティブを使用したチャネルの作成

クラスター管理者のパーミッションを持つ場合、Web コンソールの Administrator パースペクティブを使用してチャネルを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 ServerlessEventing に移動します。
  2. Create 一覧で、Channel を選択します。Channel ページに移動します。
  3. Type ドロップダウンから作成する Channel オブジェクトのタイプを選択します。

    注記

    現時点で、InMemoryChannel チャネルオブジェクトのみがデフォルトでサポートされます。OpenShift Serverless に Knative Kafka をインストールしている場合は、Kafka チャネルを利用できます。

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

4.7.5. Administrator パースペクティブを使用したサブスクリプションの作成

クラスター管理者のパーミッションを持ち、ブローカーを作成している場合、Web コンソールの Administrator パースペクティブを使用してブローカーをサブスクライバーに接続するためのサブスクリプションを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • チャネルを作成している。
  • サブスクライバーとして使用する Knative サービスを作成している。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、 ServerlessEventing に移動します。
  2. Channel タブで、サブスクリプションを追加するチャネルの Options メニュー kebab を選択します。
  3. 一覧で Add Subscription をクリックします。
  4. Add Subscription のダイアログボックスで、サブスクリプションの Subscriber を選択します。サブスクライバーは、チャネルからイベントを受信する Knative サービスです。
  5. Add をクリックします。

4.7.6. 関連情報

4.8. Administrator パースペクティブでの Knative Serving コンポーネントの作成

OpenShift Container Platform クラスターでクラスター管理者パーミッションを持つ場合、Web コンソールの Administrator パースペクティブで OpenShift Serverless を使用して Knative Serving コンポーネントを作成するか、または kn および oc CLI を使用して Knative Eventing コンポーネントを作成できます。

4.8.1. Administrator パースペクティブを使用したサーバーレスアプリケーションの作成

前提条件

Administrator パースペクティブを使用してサーバーレスアプリケーションを作成するには、以下の手順を完了していることを確認してください。

  • OpenShift Serverless Operator および Knative Serving がインストールされていること。
  • Web コンソールにログインしており、Administrator パースペクティブを使用している。

手順

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

4.9. サーバーレスコンポーネントのモニタリング

OpenShift Container Platform モニタリングダッシュボードを使用して、OpenShift Serverless コンポーネントのヘルスチェックおよびメトリクスを表示できます。

4.9.1. Knative コンポーネントの全体的なヘルスステータスのモニタリング

OpenShift Container Platform モニタリングダッシュボードを使用して、Knative の全体的なヘルスステータスを表示できます。

前提条件

  • クラスター管理者のパーミッションがあり、OpenShift Container Platform Web コンソールの Administrator パースペクティブへのアクセスがある。
  • Knative Serving および Knative Eventing コンポーネントと OpenShift Serverless Operator をインストールしている。
  • クラスターで OpenShift Container Platform モニタリングスタックが有効になっている。OpenShift Serverless Operator のインストール時に Operator の この namespace で Operator で推奨されるクラスターモニタリングを有効化する のボックスにチェックを入れてインストール中の OpenShift Serverless のモニタリングを有効にできます。

手順

  1. Administrator パースペクティブで、MonitoringDashboards に移動します。
  2. Dashboard ドロップダウンの Knative Health Status ダッシュボードを選択し、Knative の全体的なヘルスステータスを表示します。Knative デプロイメントが想定どおりに実行されている場合に、ダッシュボードには Ready ステータスが表示されます。

    Knative Health Status dashboard

    Knative Serving または Knative Eventing がインストールされている場合は、下方向にスクロールして各コンポーネントのヘルスステータスを確認することもできます。

4.9.2. Knative Serving リビジョン CPU およびメモリー使用状況のモニタリング

OpenShift Container Platform モニタリングダッシュボードを使用して、Knative Serving コンポーネントのリビジョン CPU およびメモリー使用状況のメトリクスを表示できます。

前提条件

  • クラスター管理者のパーミッションがあり、OpenShift Container Platform Web コンソールの Administrator パースペクティブへのアクセスがある。
  • OpenShift Serverless Operator および Knative Serving コンポーネントがインストールされていること。
  • クラスターで OpenShift Container Platform モニタリングスタックが有効になっている。OpenShift Serverless Operator のインストール時に Operator の この namespace で Operator で推奨されるクラスターモニタリングを有効化する のボックスにチェックを入れてインストール中の OpenShift Serverless のモニタリングを有効にできます。

手順

  1. Administrator パースペクティブで、MonitoringDashboards に移動します。
  2. Dashboard ドロップダウンリストで Knative Serving - Source CPU および Memory Usage ダッシュボードを選択して、以下のメトリクスを表示します。

    • CPU 使用率の合計 (1 分あたりの使用率)
    • メモリー使用量の合計 (バイト単位)
    • ネットワーク I/O の合計 (1 分あたりのレート)
    • ネットワークエラーの合計 (1 分あたりのレート)
  3. オプション: ドロップダウンリストからオプションを選択して、NamespaceConfiguration、または Revision でこのダッシュボードをフィルターできます。

4.9.3. Knative Eventing ソース CPU およびメモリー使用状況のモニタリング

OpenShift Container Platform モニタリングダッシュボードを使用して、Knative Eventing コンポーネントのソース CPU およびメモリー使用状況のメトリクスを表示できます。

前提条件

  • クラスター管理者のパーミッションがあり、OpenShift Container Platform Web コンソールの Administrator パースペクティブへのアクセスがある。
  • OpenShift Serverless Operator および Knative Eventing コンポーネントがインストールされていること。
  • クラスターで OpenShift Container Platform モニタリングスタックが有効になっている。OpenShift Serverless Operator のインストール時に Operator の この namespace で Operator で推奨されるクラスターモニタリングを有効化する のボックスにチェックを入れてインストール中の OpenShift Serverless のモニタリングを有効にできます。

手順

  1. Administrator パースペクティブで、MonitoringDashboards に移動します。
  2. Dashboard ドロップダウンリストで Knative Eventing - Source CPU および Memory Usage ダッシュボードを選択して、以下のメトリクスを表示します。

    • CPU 使用率の合計 (1 分あたりの使用率)
    • メモリー使用量の合計 (バイト単位)
    • ネットワーク I/O の合計 (1 分あたりのレート)
    • ネットワークエラーの合計 (1 分あたりのレート)

4.9.4. イベントソースのモニタリング

OpenShift Container Platform モニタリングダッシュボードを使用して、クラスター内のイベントソースのメトリクスを表示できます。

前提条件

  • クラスター管理者のパーミッションがあり、OpenShift Container Platform Web コンソールの Administrator パースペクティブへのアクセスがある。
  • OpenShift Serverless Operator および Knative Eventing コンポーネントがインストールされていること。
  • クラスターで OpenShift Container Platform モニタリングスタックが有効になっている。OpenShift Serverless Operator のインストール時に Operator の この namespace で Operator で推奨されるクラスターモニタリングを有効化する のボックスにチェックを入れてインストール中の OpenShift Serverless のモニタリングを有効にできます。

手順

  1. Administrator パースペクティブで、MonitoringDashboards に移動します。
  2. Dashboard のドロップダウンリストで Knative Eventing - Sources ダッシュボードを選択します。
  3. 以下のメトリクスを表示できるようになりました。

    1. API サーバーソースの場合:

      • イベント数 (1 分あたりレート)
      • 成功率 (2xx イベント、1 分あたりの配分率)
      • 応答コードクラスごとのイベント数 (1 分あたりのレート)
      • 失敗率 (2xx ではないイベント、1 分あたりの配分率)
    2. Ping ソースの場合:

      • イベント数 (1 分あたりレート)
      • 成功率 (2xx イベント、1 分あたりの配分率)
      • 応答コードクラスごとのイベント数 (1 分あたりのレート)
      • 失敗率 (2xx ではないイベント、1 分あたりの配分率)
    3. Kafka ソースの場合

      • イベント数 (1 分あたりレート)
      • 成功率 (2xx イベント、1 分あたりの配分率)
      • 応答コードクラスごとのイベント数 (1 分あたりのレート)
      • 失敗率 (2xx ではないイベント、1 分あたりの配分率)

4.9.5. Knative Eventing ブローカーおよびトリガーのモニタリング

OpenShift Container Platform モニタリングダッシュボードを使用して、クラスターでブローカーおよびトリガーのメトリクスを表示できます。

前提条件

  • クラスター管理者のパーミッションがあり、OpenShift Container Platform Web コンソールの Administrator パースペクティブへのアクセスがある。
  • OpenShift Serverless Operator および Knative Eventing コンポーネントがインストールされていること。
  • クラスターで OpenShift Container Platform モニタリングスタックが有効になっている。OpenShift Serverless Operator のインストール時に Operator の この namespace で Operator で推奨されるクラスターモニタリングを有効化する のボックスにチェックを入れてインストール中の OpenShift Serverless のモニタリングを有効にできます。

手順

  1. Administrator パースペクティブで、MonitoringDashboards に移動します。
  2. Dashboard のドロップダウンリストで Knative Eventing - Broker/Trigger ダッシュボードを選択します。
  3. 以下のメトリクスを表示できるようになりました。

    1. ブローカーの場合:

      • イベント数 (1 分あたりの avg/秒)
      • 成功率 (2xx イベント、1 分あたりの配分率)
      • イベントタイプ別のイベント数 (1 分あたりの avg/秒)
      • 応答コードクラスごとのイベント数 (1 分あたりの avg/秒)
      • 失敗率 (2xx ではないイベント、1 分あたりの配分率)
      • イベントディスパッチレイテンシー (ミリ秒)
    2. トリガーの場合:

      • イベント数 (1 分あたりの avg/秒)
      • 成功率 (2xx イベント、1 分あたりの配分率)
      • イベントタイプ別のイベント数 (1 分あたりの avg/秒)
      • 応答コードクラスごとのイベント数 (1 分あたりの avg/秒)
      • 失敗率 (2xx ではないイベント、1 分あたりの配分率)
      • イベントディスパッチレイテンシー (ミリ秒)
      • イベント処理レイテンシー (ミリ秒)

4.9.6. Knative Eventing チャネルのモニタリング

OpenShift Container Platform モニタリングダッシュボードを使用して、クラスター内のチャネルのメトリクスを表示できます。

前提条件

  • クラスター管理者のパーミッションがあり、OpenShift Container Platform Web コンソールの Administrator パースペクティブへのアクセスがある。
  • OpenShift Serverless Operator、Knative Eventing コンポーネント、および KnativeKafka カスタムリソースがインストールされている。
  • クラスターで OpenShift Container Platform モニタリングスタックが有効になっている。OpenShift Serverless Operator のインストール時に Operator の この namespace で Operator で推奨されるクラスターモニタリングを有効化する のボックスにチェックを入れてインストール中の OpenShift Serverless のモニタリングを有効にできます。

手順

  1. Administrator パースペクティブで、MonitoringDashboards に移動します。
  2. Dashboard ドロップダウンリストで Knative Eventing - Channel ダッシュボードを選択します。
  3. 以下のメトリクスを表示できるようになりました。

    1. インメモリーチャネルの場合:

      • イベント数 (1 分あたりの avg/秒)
      • 成功率 (2xx イベント、1 分あたりの配分率)
      • 応答コードクラスごとのイベント数 (1 分あたりの avg/秒)
      • 失敗率 (2xx ではないイベント、1 分あたりの配分率)
      • イベントディスパッチレイテンシー (ミリ秒)
    2. Kafka チャネルの場合:

      • イベント数 (1 分あたりの avg/秒)
      • 成功率 (2xx イベント、1 分あたりの配分率)
      • 応答コードクラスごとのイベント数 (1 分あたりの avg/秒)
      • 失敗率 (2xx ではないイベント、1 分あたりの配分率)
      • イベントディスパッチレイテンシー (ミリ秒)

4.10. メトリクス

メトリクスにより、クラスター管理者は OpenShift Serverless クラスターコンポーネントおよびワークロードのパフォーマンスを監視できます。

4.10.1. 前提条件

  • クラスターのメトリクスの有効化に関する詳細は、OpenShift Container Platform ドキュメントの「メトリクスの管理」を参照してください。
  • OpenShift Container Platform で Knative コンポーネントのメトリクスを表示するには、クラスター管理者権限と、Web コンソール管理者 パースペクティブへのアクセスが必要です。
警告

サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。

この問題の解決に関する詳細は、「Serverless 1.16.0 リリースノート」を参照してください。

4.10.2. コントローラーメトリクス

以下のメトリクスは、コントローラーロジックを実装するコンポーネントによって出力されます。これらのメトリクスは、調整要求がワークキューに追加される調整操作とワークキューの動作に関する詳細を示します。

メトリクス名詳細タイプタグ単位

work_queue_depth

ワークキューの深さ。

ゲージ

reconciler

整数 (単位なし)

reconcile_count

調整操作の数。

カウンター

reconcilersuccess

整数 (単位なし)

reconcile_latency

調整操作のレイテンシー。

ヒストグラム

reconcilersuccess

ミリ秒

workqueue_adds_total

ワークキューによって処理される追加アクションの合計数。

カウンター

名前

整数 (単位なし)

workqueue_queue_latency_seconds

アイテムが要求される前にワークキューにとどまる時間の長さ。

ヒストグラム

名前

workqueue_retries_total

ワークキューによって処理された再試行回数。

カウンター

名前

整数 (単位なし)

workqueue_work_duration_seconds

ワークキューからの項目の処理にかかる時間の長さ。

ヒストグラム

名前

workqueue_unfinished_work_seconds

未処理のワークキュー項目が進行中であった時間の長さ。

ヒストグラム

名前

workqueue_longest_running_processor_seconds

最も長い間未処理のワークキュー項目が進行中であった時間の長さ。

ヒストグラム

名前

4.10.3. Webhook メトリクス

Webhook メトリクスは操作に関する有用な情報を表示します。たとえば、多数の操作が失敗する場合は、これはユーザーが作成したリソースに問題があることを示している可能性があります。

メトリクス名詳細タイプタグ単位

request_count

Webhook にルーティングされる要求の数。

カウンター

admission_allowedkind_groupkind_kindkind_versionrequest_operationresource_groupresource_namespaceresource_resourceresource_version

整数 (単位なし)

request_latencies

Webhook 要求の応答時間。

ヒストグラム

admission_allowedkind_groupkind_kindkind_versionrequest_operationresource_groupresource_namespaceresource_resourceresource_version

ミリ秒

4.10.4. Knative Eventing メトリクス

クラスター管理者は、Knative Eventing コンポーネントの以下のメトリクスを表示できます。

HTTP コードからメトリクスを集計することで、イベントは正常なイベント (2xx) および失敗したイベント (5xx) の 2 つのカテゴリーに分類できます。

4.10.4.1. ブローカー Ingress メトリクス

以下のメトリクスを使用してブローカー Ingress をデバッグし、どのように実行されているかを確認し、どのイベントが Ingress コンポーネントによってディスパッチされているかを確認できます。

メトリクス名詳細タイプタグ単位

event_count

ブローカーによって受信されるイベントの数。

カウンター

broker_nameevent_typenamespace_nameresponse_coderesponse_code_classunique_name

整数 (単位なし)

event_dispatch_latencies

イベントのチャネルへのディスパッチにかかる時間。

ヒストグラム

broker_nameevent_typenamespace_nameresponse_coderesponse_code_classunique_name

ミリ秒

4.10.4.2. ブローカーフィルターメトリクス

以下のメトリクスを使用してブローカーフィルターをデバッグし、それらがどのように実行されているかを確認し、どのイベントがフィルターによってディスパッチされているかを確認できます。イベントでフィルタリングアクションのレイテンシーを測定することもできます。

メトリクス名詳細タイプタグ単位

event_count

ブローカーによって受信されるイベントの数。

カウンター

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

整数 (単位なし)

event_dispatch_latencies

イベントのチャネルへのディスパッチにかかる時間。

ヒストグラム

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

ミリ秒

event_processing_latencies

トリガーサブスクライバーにディスパッチされる前にイベントの処理にかかる時間。

ヒストグラム

broker_namecontainer_namefilter_typenamespace_nametrigger_nameunique_name

ミリ秒

4.10.4.3. InMemoryChannel dispatcher メトリクス

以下のメトリクスを使用して InMemoryChannel チャネルをデバッグし、それらがどのように実行されているかを確認し、どのイベントがチャネルによってディスパッチされているかを確認できます。

メトリクス名詳細タイプタグ単位

event_count

InMemoryChannel チャネルでディスパッチされるイベントの数。

カウンター

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

整数 (単位なし)

event_dispatch_latencies

InMemoryChannel チャネルからのイベントのディスパッチにかかる時間。

ヒストグラム

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

ミリ秒

4.10.4.4. イベントソースメトリクス

以下のメトリクスを使用して、イベントがイベントソースから接続されたイベントシンクに配信されていることを確認できます。

メトリクス名詳細タイプタグ単位

event_count

イベントソースによって送信されるイベントの数。

カウンター

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

整数 (単位なし)

retry_event_count

最初に配信に失敗した後にイベントソースによって送信される再試行イベントの数。

カウンター

event_sourceevent_typenamenamespace_nameresource_groupresponse_coderesponse_code_classresponse_errorresponse_timeout

整数 (単位なし)

4.10.5. Knative Serving メトリクス

クラスター管理者は、Knative Serving コンポーネントの以下のメトリクスを表示できます。

4.10.5.1. activator メトリクス

以下のメトリクスを使用して、トラフィックが activator 経由で渡されるときにアプリケーションがどのように応答するかを理解することができます。

メトリクス名詳細タイプタグ単位

request_concurrency

activator にルーティングされる同時要求の数、またはレポート期間における平均同時実行数。

ゲージ

configuration_namecontainer_namenamespace_namepod_namerevision_nameservice_name

整数 (単位なし)

request_count

activator にルーティングされる要求の数。これらは、activator ハンドラーから実行された要求です。

カウンター

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

整数 (単位なし)

request_latencies

実行され、ルーティングされた要求の応答時間 (ミリ秒単位)。

ヒストグラム

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

ミリ秒

4.10.5.2. Autoscaler メトリクス

Autoscaler コンポーネントは、それぞれのリビジョンの Autoscaler の動作に関連する多数のメトリクスを公開します。たとえば、任意の時点で、Autoscaler がサービスに割り当てようとする Pod のターゲット数、安定期間中の 1 秒あたりの要求の平均数、または Knative Pod Autoscaler (KPA) を使用している場合に Autoscaler がパニックモードであるかどうかなどを監視できます。

メトリクス名詳細タイプタグ単位

desired_pods

Autoscaler がサービスへの割り当てを試みる Pod 数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

excess_burst_capacity

stable ウインドウで提供される追加のバースト容量。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

stable_request_concurrency

stable ウィンドウで監視される各 Pod の要求数の平均。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

panic_request_concurrency

panic ウィンドウで監視される各 Pod の要求数の平均。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

target_concurrency_per_pod

Autoscaler が各 Pod への送信を試みる同時要求の数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

stable_requests_per_second

stable ウィンドウで監視される各 Pod の 1 秒当たりの要求数の平均。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

panic_requests_per_second

panic ウィンドウで監視される各 Pod の 1 秒当たりの要求数の平均。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

target_requests_per_second

Autoscaler が各 Pod をターゲットとする 1 秒あたりの要求の数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

panic_mode

この値は、Autoscaler がパニックモードの場合は 1 になります。Autoscaler がパニックモードではない場合は 0 になります。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

requested_pods

Autoscaler が Kubernetes クラスターから要求した Pod 数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

actual_pods

割り当てられ、現在準備完了状態にある Pod 数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

not_ready_pods

準備未完了状態の Pod 数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

pending_pods

現在保留中の Pod 数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

terminating_pods

現在終了中の Pod 数。

ゲージ

configuration_name, namespace_name, revision_name, service_name

整数 (単位なし)

4.10.5.3. Go ランタイムメトリクス

各 Knative Serving コントロールプレーンプロセスは、Go ランタイムメモリーの統計を多数出力します (MemStats) 。

注記

各メトリクスの name タグは空のタグです。

メトリクス名詳細タイプタグ単位

go_alloc

割り当てられたヒープオブジェクトのバイト数。このメトリクスは heap_alloc と同じです。

ゲージ

名前

整数 (単位なし)

go_total_alloc

ヒープオブジェクトに割り当てられる累積バイト数。

ゲージ

名前

整数 (単位なし)

go_sys

オペレーティングシステムから取得したメモリーの合計バイト数。

ゲージ

名前

整数 (単位なし)

go_lookups

ランタイムが実行したポインター検索の数。

ゲージ

名前

整数 (単位なし)

go_mallocs

割り当てられるヒープオブジェクトの累積数。

ゲージ

名前

整数 (単位なし)

go_frees

解放されているヒープオブジェクトの累積数。

ゲージ

名前

整数 (単位なし)

go_heap_alloc

割り当てられたヒープオブジェクトのバイト数。

ゲージ

名前

整数 (単位なし)

go_heap_sys

オペレーティングシステムから取得したヒープメモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_heap_idle

アイドル状態の未使用スパンのバイト数。

ゲージ

名前

整数 (単位なし)

go_heap_in_use

現在使用中のスパンのバイト数。

ゲージ

名前

整数 (単位なし)

go_heap_released

オペレーティングシステムに返された物理メモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_heap_objects

割り当てられるヒープオブジェクトの数。

ゲージ

名前

整数 (単位なし)

go_stack_in_use

現在使用中のスタックスパンのバイト数。

ゲージ

名前

整数 (単位なし)

go_stack_sys

オペレーティングシステムから取得したスタックメモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_mspan_in_use

割り当てられた mspan 構造のバイト数。

ゲージ

名前

整数 (単位なし)

go_mspan_sys

mspan 構造のオペレーティングシステムから取得したメモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_mcache_in_use

割り当てられた mcache 構造のバイト数。

ゲージ

名前

整数 (単位なし)

go_mcache_sys

mcache 構造のためにオペレーティングシステムから取得したメモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_bucket_hash_sys

バケットハッシュテーブルのプロファイリングにおけるメモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_gc_sys

ガべージコレクションメタデータのメモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_other_sys

その他のオフヒープランタイム割り当てのメモリーのバイト数。

ゲージ

名前

整数 (単位なし)

go_next_gc

次のガベージコレクションサイクルのターゲットヒープサイズ。

ゲージ

名前

整数 (単位なし)

go_last_gc

最後のガベージコレクションが完了した時間 (Epoch または Unix 時間)。

ゲージ

名前

ナノ秒

go_total_gc_pause_ns

プログラム開始以降のガベージコレクションの stop-the-world 停止の累積時間。

ゲージ

名前

ナノ秒

go_num_gc

完了したガベージコレクションサイクルの数。

ゲージ

名前

整数 (単位なし)

go_num_forced_gc

ガベージコレクションの機能を呼び出すアプリケーションが原因で強制されたガベージコレクションサイクルの数。

ゲージ

名前

整数 (単位なし)

go_gc_cpu_fraction

プログラムの開始以降にガベージコレクターによって使用されたプログラムの使用可能な CPU 時間の一部。

ゲージ

名前

整数 (単位なし)

4.11. OpenShift Serverless でのメータリングの使用

重要

メータリングは非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、または削除された主な機能の最新の一覧については、『OpenShift Container Platform リリースノート』の「 非推奨および削除された機能」セクションを参照してください。

クラスター管理者として、メータリングを使用して OpenShift Serverless クラスターで実行されている内容を分析できます。

OpenShift Container Platform のメータリングについての詳細は、「メータリングの概要」を参照してください。

注記

現時点で、メータリングは IBM Z および IBM Power Systems ではサポートされていません。

4.11.1. メータリングのインストール

OpenShift Container Platform でのメータリングのインストールについての詳細は、「メータリングのインストール」を参照してください。

4.11.2. Knative Serving メータリングのデータソース

以下の ReportDataSources は、Knative Serving を OpenShift Container Platform メータリングで使用する方法についての例です。

4.11.2.1. Knative Serving での CPU 使用状況のデータソース

このデータソースは、レポート期間における Knative サービスごとに使用される累積された CPU の秒数を示します。

YAML ファイル

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-cpu-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(rate(container_cpu_usage_seconds_total{container!="POD",container!="",pod!=""}[1m]), "pod", "$1", "pod", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

4.11.2.2. Knative Serving でのメモリー使用状況のデータソース

このデータソースは、レポート期間における Knative サービスごとの平均メモリー消費量を示します。

YAML ファイル

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-memory-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(container_memory_usage_bytes{container!="POD", container!="",pod!=""}, "pod", "$1", "pod", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

4.11.2.3. Knative Serving メータリングのデータソースの適用

以下のコマンドを使用して、ReportDataSources を適用することができます。

$ oc apply -f <datasource_name>.yaml

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

4.11.3. Knative Serving メータリングのクエリー

以下の ReportQuery リソースは、提供されるサンプルの DataSources を参照します。

4.11.3.1. Knative Serving での CPU 使用状況のクエリー

YAML ファイル

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-cpu-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-cpu-usage
    name: KnativeServiceCpuUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_cpu_seconds
    type: double
    unit: cpu_core_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_cpu_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceCpuUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

4.11.3.2. Knative Serving でのメモリー使用状況のクエリー

YAML ファイル

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-memory-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-memory-usage
    name: KnativeServiceMemoryUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_usage_memory_byte_seconds
    type: double
    unit: byte_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_usage_memory_byte_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceMemoryUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

4.11.3.3. Knative Serving メータリングのクエリーの適用

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

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

    コマンドの例

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

4.11.4. Knative Serving のメータリングレポート

Report リソースを作成し、Knative Serving に対してメータリングレポートを実行できます。レポートを実行する前に、レポート期間の開始日と終了日を指定するために、Report リソース内で入力パラメーターを変更する必要があります。

YAML ファイル

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: knative-service-cpu-usage
spec:
  reportingStart: '2019-06-01T00:00:00Z' 1
  reportingEnd: '2019-06-30T23:59:59Z' 2
  query: knative-service-cpu-usage 3
runImmediately: true

1
レポートの開始日 (ISO 8601 形式)。
2
レポートの終了日 (ISO 8601 形式)。
3
CPU 使用状況レポートの knative-service-cpu-usage、またはメモリー使用状況レポートの knative-service-memory-usage のいずれか。

4.11.4.1. メータリングレポートの実行

  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

4.12. OpenShift Serverless での高可用性

高可用性 (HA) は Kubernetes API の標準的な機能で、中断が生じる場合に API が稼働を継続するのに役立ちます。HA デプロイメントでは、アクティブなコントローラーがクラッシュするか、または削除されると、現在利用できないコントローラーが提供されている API の処理を引き継ぐために別のコントローラーが利用可能になります。

OpenShift Serverless の HA は、リーダーの選択によって利用できます。これは、Knative Serving または Eventing コントロールプレーンのインストール後にデフォルトで有効になります。

リーダー選択の HA パターンを使用する場合、必要時に備えてコントローラーのインスタンスはスケジュールされ、クラスター内で実行されます。これらのコントローラーインスタンスは、共有リソースの使用に向けて競います。これは、リーダー選択ロックとして知られています。リーダー選択ロックのリソースにアクセスできるコントローラーのインスタンスはリーダーと呼ばれます。

4.12.1. OpenShift Serverless での高可用性レプリカの設定

高可用性 (HA) 機能はデフォルトで、Knative Serving、Knative Eventing、および Knative Kafka の OpenShift Serverless 上の有効です。以下は、それぞれに合わせてスケーリングされるコンポーネントです。

  • Knative Serving: activator,autoscaler,autoscaler-hpa,controller,webhook,kourier-control,kourier-gateway
  • Knative Eventing: eventing-controller, eventing-webhook, imc-controller, imc-dispatcher, mt-broker-controller, sugar-controller.
  • Knative Kafka: kafka-ch-controller, kafka-controller-manager, kafka-webhook.

これらのコンポーネントは、デフォルトで 2 つのレプリカで設定されます。

Knative Eventing の場合には、HA では mt-broker-filter および mt-broker-ingress デプロイメントはスケーリングされません。複数のデプロイメントが必要な場合は、これらのコンポーネントを手動でスケーリングします。

KnativeServing カスタムリソース (CR)、KnativeEventing CR または KnativeKafka CR の spec.high-availability.replicas の設定を変更して、コンポーネントごとに作成されるレプリカの数を変更します。

4.12.1.1. Serving での高可用性レプリカの設定

Knative Serving コンポーネントは、KnativeServing カスタムリソースの spec.high-availability.replicas 値を変更してスケーリングできます。

前提条件

  • クラスター管理者のパーミッションを持つ OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHubInstalled Operators に移動します。

    Installed Operators page
  2. knative-serving namespace を選択します。
  3. OpenShift Serverless Operator の Provided API 一覧で Knative Serving をクリックし、Knative Serving タブに移動します。

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

    Knative Serving YAML
  5. KnativeServing CRD のレプリカ数を変更します。

    サンプル YAML

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

    1
    レプリカの数を 3 に設定します。
    重要

    config フィールドに含まれる YAML は変更しないでください。このフィールドの設定値の一部は OpenShift Serverless Operator によって挿入され、これらを変更すると、デプロイメントはサポートされなくなります。

    • replicas 値は、すべての HA コントローラーのレプリカ数を設定します。
    • デフォルトの replicas 値は 2 です。
    • 値を 3 以上に変更してレプリカの数を増やすことができます。

4.12.1.2. Eventing での高可用性レプリカの設定

Knative Eventing コンポーネントは、KnativeEventing カスタムリソースの spec.high-availability.replicas 値を変更してスケーリングできます。

前提条件

  • クラスター管理者のパーミッションを持つ OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHubInstalled Operators に移動します。

    Installed Operators page
  2. knative-eventing namespace を選択します。
  3. OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。

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

    Knative Eventing YAML
  5. KnativeEvening CRD のレプリカ数を変更します。

    サンプル YAML

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3 1

    1
    レプリカの数を 3 に設定します。
    重要

    config フィールドに含まれる YAML は変更しないでください。このフィールドの設定値の一部は OpenShift Serverless Operator によって挿入され、これらを変更すると、デプロイメントはサポートされなくなります。

    • replicas 値は、すべての HA コントローラーのレプリカ数を設定します。
    • デフォルトの replicas 値は 2 です。
    • 値を 3 以上に変更してレプリカの数を増やすことができます。

4.12.1.3. Kafka での高可用性レプリカの設定

Knative Kafka コンポーネントは、KnativeKafka カスタムリソースの spec.high-availability.replicas 値を変更してスケーリングできます。

前提条件

  • クラスター管理者のパーミッションを持つ OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift Serverless Operator および Knative Kafka がクラスターにインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHubInstalled Operators に移動します。

    Installed Operators page
  2. knative-eventing namespace を選択します。
  3. OpenShift Serverless Operator の Provided APIs の一覧で Knative Kafka をクリックし、 Knative Kafka タブに移動します。

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

    Knative Kafka YAML
  5. KnativeKafka CRD のレプリカ数を変更します。

    サンプル YAML

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      name: knative-kafka
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3 1

    1
    レプリカの数を 3 に設定します。
    重要

    config フィールドに含まれる YAML は変更しないでください。このフィールドの設定値の一部は OpenShift Serverless Operator によって挿入され、これらを変更すると、デプロイメントはサポートされなくなります。

    • replicas 値は、すべての HA コントローラーのレプリカ数を設定します。
    • デフォルトの replicas 値は 2 です。
    • 値を 3 以上に変更してレプリカの数を増やすことができます。

第5章 Knative Serving

5.1. Knative Serving について

OpenShift Container Platform 上の Knative Serving により、開発者はサーバーレスアーキテクチャーを使用して、クラウドネイティブアプリケーション を作成できます。

Knative Serving は、OpenShift Container Platform クラスター上のサーバーレスワークロードの動作を定義し、制御する Kubernetes カスタムリソース定義 (CRD) としてオブジェクトのセットを提供し、クラウドネイティブアプリケーションのデプロイおよび管理をサポートします。CRD についての詳細は、「カスタムリソース定義による Kubernetes API の拡張」を参照してください。

開発者はこれらの CRD を使用して、複雑なユースケースに対応するためにビルディングブロックとして使用できるカスタムリソース (CR) インスタンスを作成します。以下は例になります。

  • サーバーレスコンテナーの迅速なデプロイ
  • Pod の自動スケーリング

CR についての詳細は、「カスタムリソース定義からのリソースの管理」を参照してください。

5.1.1. Knative Serving カスタムリソース定義

Service
service.serving.knative.dev CRD はワークロードのライフサイクルを自動的に管理し、アプリケーションがネットワーク経由でデプロイされ、到達可能であることを確認します。これは、ユーザーが作成したサービスまたはカスタムリソースに対して加えられるそれぞれの変更についての ルート、設定、および新規リビジョンを作成します。Knative での開発者の対話のほとんどは、サービスを変更して実行されます。
Revision
revision.serving.knative.dev CRD は、ワークロードに対して加えられるそれぞれの変更についてのコードおよび設定の特定の時点におけるスナップショットです。Revision (リビジョン) はイミュータブル (変更不可) オブジェクトであり、必要な期間保持することができます。
Route
route.serving.knative.dev CRD は、ネットワークのエンドポイントを、1 つ以上のリビジョンにマップします。部分的なトラフィックや名前付きルートなどのトラフィックを複数の方法で管理することができます。
Configuration
configuration.serving.knative.dev CRD は、デプロイメントの必要な状態を維持します。これにより、コードと設定を明確に分離できます。設定を変更すると、新規リビジョンが作成されます。

5.2. Serverless アプリケーション

5.2.1. Knative サービスを使用した Serverless アプリケーション

OpenShift Serverless でサーバーレスアプリケーションをデプロイするには、Knative サービス を作成する必要があります。Knative サービスは、ルートおよび YAML ファイルに含まれる設定によって定義される Kubernetes サービスです。

Knative サービス YAML の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello 1
  namespace: default 2
spec:
  template:
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift 3
          env:
            - name: RESPONSE 4
              value: "Hello Serverless!"

1
アプリケーションの名前
2
アプリケーションが使用する namespace
3
アプリケーションのイメージ
4
サンプルアプリケーションで出力される環境変数

5.2.2. Serverless アプリケーションの作成

以下の方法のいずれかを使用してサーバーレスアプリケーションを作成できます。

  • OpenShift Container Platform Web コンソールからの Knative サービスの作成
  • kn CLI を使用して Knative サービスを作成します。
  • YAML ファイルを作成し、これを適用します。

5.2.2.1. Developer パースペクティブを使用したサーバーレスアプリケーションの作成

OpenShift Container Platform で Developer パースペクティブを使用してアプリケーションを作成する方法についての詳細は、「Developer パースペクティブを使用したアプリケーションの作成」ドキュメントを参照してください。

5.2.2.2. Knative CLI を使用したサーバーレスアプリケーションの作成

以下の手順では、kn CLI を使用して基本的なサーバーレスアプリケーションを作成する方法を説明します。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • kn CLI がインストールされている。

手順

  • Knative サービスを作成します。

    $ kn service create <service-name> --image <image> --env <key=value>

    コマンドの例

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

    出力例

    Creating service 'event-display' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "event-display" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL:
    http://event-display-default.apps-crc.testing

5.2.2.3. YAML を使用したサーバーレスアプリケーションの作成

YAML を使用してサーバーレスアプリケーションを作成するには、Service を定義する YAML ファイルを作成し、oc apply を使用してこれを適用する必要があります。

手順

  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>

サービスが作成され、アプリケーションがデプロイされると、Knative はこのバージョンのアプリケーションのイミュータブルなリビジョンを作成します。また、Knative はネットワークプログラミングを実行し、アプリケーションのルート、ingress、サービスおよびロードバランサーを作成し、アクティブでない Pod を含む Pod をトラフィックに基づいて自動的にスケールアップ/ダウンします。

5.2.3. Knative CLI を使用したサーバーレスアプリケーションの更新

サービスを段階的に構築する際に、コマンドラインで kn service update コマンドを使用し、対話式のセッションを使用できます。kn service apply コマンドとは対照的に、kn service update コマンドを使用する際は、Knative サービスの完全な設定ではなく、更新が必要な変更のみを指定する必要があります。

コマンドの例

  • 新規の環境変数を追加してサービスを更新します。

    $ kn service update <service_name> --env <key>=<value>
  • 新しいポートを追加してサービスを更新します。

    $ kn service update <service_name> --port 80
  • 新しい要求および制限パラメーターを追加してサービスを更新します。

    $ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
  • latest タグをリビジョンに割り当てます。

    $ kn service update <service_name> --tag <revision_name>=latest
  • サービスの最新の READY リビジョンについて、testing から staging にタグを更新します。

    $ kn service update <service_name> --untag testing --tag @latest=staging
  • test タグをトラフィックの 10% を受信するリビジョンに追加し、残りのトラフィックをサービスの最新の READY リビジョンに送信します。

    $ kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90

5.2.4. サービス宣言の適用

kn service apply コマンドを使用して Knative サービスを宣言的に設定できます。サービスが存在しない場合は、これが作成されますが、それ以外の場合は、既存のサービスが変更されたオプションで更新されます。

kn service apply コマンドは、ユーザーがターゲットの状態を宣言するために単一コマンドでサービスの状態を詳細に指定したい場合など、とくにシェルスクリプトや継続的インテグレーションパイプラインで役に立ちます。

kn service apply を使用する場合は、Knative サービスの詳細な設定を指定する必要があります。これは kn service update コマンドとは異なります。このコマンドでは、更新する必要のあるオプションを指定するだけで済みます。

コマンドの例

  • サービスを作成します。

    $ kn service apply <service_name> --image <image>
  • 環境変数をサービスに追加します。

    $ kn service apply <service_name> --image <image> --env <key>=<value>
  • JSON または YAML ファイルからサービス宣言を読み取ります。

    $ kn service apply <service_name> -f <filename>

5.2.5. Knative CLI を使用したサーバーレスアプリケーションの記述

kn service describe コマンドを使用して Knative サービスを記述できます。

コマンドの例

  • サービスを記述します。

    $ kn service describe --verbose <service_name>

    --verbose フラグは任意ですが、さらに詳細な説明を提供するために追加できます。通常の出力と詳細の出力の違いについては、以下の例に示されます。

    --verbose フラグを使用しない出力例

    Name:       hello
    Namespace:  default
    Age:        2m
    URL:        http://hello-default.apps.ocp.example.com
    
    Revisions:
      100%  @latest (hello-00001) [1] (2m)
            Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   1m
      ++ ConfigurationsReady     1m
      ++ RoutesReady             1m

    --verbose フラグを使用する出力例

    Name:         hello
    Namespace:    default
    Annotations:  serving.knative.dev/creator=system:admin
                  serving.knative.dev/lastModifier=system:admin
    Age:          3m
    URL:          http://hello-default.apps.ocp.example.com
    Cluster:      http://hello.default.svc.cluster.local
    
    Revisions:
      100%  @latest (hello-00001) [1] (3m)
            Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
            Env:    RESPONSE=Hello Serverless!
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   3m
      ++ ConfigurationsReady     3m
      ++ RoutesReady             3m

  • サービスを YAML 形式で記述します。

    $ kn service describe <service_name> -o yaml
  • サービスを JSON 形式で記述します。

    $ kn service describe <service_name> -o json
  • サービス URL のみを出力します。

    $ kn service describe <service_name> -o url

5.2.6. サーバーレスアプリケーションのデプロイメントの確認

サーバーレスアプリケーションが正常にデプロイされたことを確認するには、Knative によって作成されたアプリケーション URL を取得してから、その URL に要求を送信し、出力を確認する必要があります。

注記

OpenShift Serverless は HTTP および HTTPS URL の両方の使用をサポートしますが、oc get ksvc からの出力は常に http:// 形式を使用して URL を出力します。

手順

  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!

5.2.7. HTTP2 および gRPC を使用したサーバーレスアプリケーションとの対話

OpenShift Serverless はセキュアでないルートまたは edge termination ルートのみをサポートします。

非セキュアなルートまたは edge termination ルートは OpenShift Container Platform で HTTP2 をサポートしません。gRPC は HTTP2 によって転送されるため、これらのルートは gRPC もサポートしません。

アプリケーションでこれらのプロトコルを使用する場合は、Ingress ゲートウェイを使用してアプリケーションを直接呼び出す必要があります。これを実行するには、Ingress ゲートウェイのパブリックアドレスとアプリケーションの特定のホストを見つける必要があります。

手順

  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 要求を行うこともできます。

    grpc.Dial(
        "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
        grpc.WithAuthority("hello-default.example.com:80"),
        grpc.WithInsecure(),
    )
    注記

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

5.2.8. 制限のあるネットワークポリシーを持つクラスターでの Knative アプリケーションとの通信の有効化

複数のユーザーがアクセスできるクラスターを使用している場合、クラスターはネットワークポリシーを使用してネットワーク経由で相互に通信できる Pod、サービス、および namespace を制御する可能性があります。

クラスターで制限的なネットワークポリシーを使用する場合は、Knative システム Pod が Knative アプリケーションにアクセスできない可能性があります。たとえば、namespace に、すべての要求を拒否する以下のネットワークポリシーがある場合、Knative システム Pod は Knative アプリケーションにアクセスできません。

namespace へのすべての要求を拒否する NetworkPolicy オブジェクトの例

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: example-namespace
spec:
  podSelector:
  ingress: []

Knative システム Pod からアプリケーションへのアクセスを許可するには、ラベルを各 Knative システム namespace に追加し、このラベルを持つ他の namespace の namespace へのアクセスを許可する アプリケーション namespace に NetworkPolicy オブジェクトを作成する必要があります。

重要

クラスターの非 Knative サービスへの要求を拒否するネットワークポリシーは、これらのサービスへのアクセスを防止するネットワークポリシーです。ただし、Knative システム namespace から Knative アプリケーションへのアクセスを許可することにより、クラスターのすべての namespace から Knative アプリケーションへのアクセスを許可する必要があります。

クラスターのすべての namespace から Knative アプリケーションへのアクセスを許可しない場合は、代わりに Knative サービスの JSON Web Token 認証 を使用するようにしてください (Knative Serving ドキュメントを参照してください)。Knative サービスの JSON Web トークン認証にはサービスメッシュが必要です。

手順

  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
    アプリケーション (Knative サービス) が存在する namespace。

5.2.9. オフラインモードでの kn CLI の使用

重要

kn CLI のオフラインモードはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

5.2.9.1. オフラインモードについて

通常、kn service コマンドを実行すると、変更が即座にクラスターに伝播されます。ただし、別の方法として、オフラインモードで kn サービス コマンドを実行できます。

  1. オフラインモードでサービスを作成する場合には、クラスターで変更はありません。代わりに、ローカルマシンでサービス記述子ファイルの作成だけが行われます。
  2. 記述子ファイルの作成後、手動で変更し、バージョン管理システムで追跡できます。
  3. 最後に、記述子ファイルで kn service create -fkn service apply -f または oc apply -f コマンドを使用して変更をクラスターに伝播できます。

オフラインモードには、いくつかの用途があります。

  • 記述子ファイルを使用してクラスターで変更する前に、記述子ファイルを手動で変更できます。
  • バージョン管理システムでは、サービスの記述子ファイルをローカルで追跡できます。これにより、記述子ファイルを再利用できます。たとえば、継続的インテグレーション (CI) パイプライン、開発環境またはデモなどで、ターゲットクラスター以外の配置が可能になります。
  • 作成した記述子ファイルを検証して Knative サービスについて確認できます。特に、生成されるサービスが kn コマンドに渡されるさまざまな引数によってどのように影響するかを確認できます。

オフラインモードには、高速で、クラスターへの接続を必要としないという利点があります。ただし、オフラインモードではサーバー側の検証がありません。したがって、サービス名が一意であることや、指定のイメージをプルできることなどを確認できません。

5.2.9.2. オフラインモードを使用したサービスの作成

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • kn CLI がインストールされている。

手順

  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 クラスターにログインしている場合には、記述子ファイルが現在の 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 クラスターにログインしている場合には、kn は現在の namespace をもとに名前が付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kndefault/ サブディレクトリーで検索します。

  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

5.3. Knative Serving 自動スケーリングの設定

OpenShift Serverless は、非アクティブな Pod をゼロにスケーリングする機能など、Pod の自動スケーリングの機能を提供します。Knative Serving の自動スケーリングを有効にするには、リビジョンテンプレートで同時実行 (concurrency) およびスケール境界 (scale bound) を設定する必要があります。

注記

リビジョンテンプレートでの制限およびターゲットの設定は、アプリケーションの単一インスタンスに対して行われます。たとえば、target アノテーションを 50 に設定することにより、各リビジョンが一度に 50 要求を処理できるようアプリケーションをスケーリングするように Autoscaler が設定されます。

5.3.1. Knative CLI を使用した自動スケーリングのワークフロー

YAML ファイルを直接編集せずに kn を使用して Knative サービスを変更することで、クラスターの自動スケーリング機能を編集できます。

以下に示すように、適切なフラグと共に kn service create および kn service update コマンドを使用して、自動スケーリング動作を設定できます。

フラグ詳細

--concurrency-limit int

単一リビジョンによって処理される同時要求のハード制限を設定します。

--concurrency-target int

受信する同時要求の数に基づくリビジョンのスケールアップのタイミングの推奨を行います。デフォルトは --concurrency-limit に設定されます。

--max-scale int

リビジョンの最大数。

--min-scale int

リビジョンの最小数。

5.3.2. Knative Serving 自動スケーリングの同時要求の設定

リビジョンコンテナーの各インスタンスまたはアプリケーションによって処理される同時要求の数は、リビジョンテンプレートに target アノテーションまたは containerConcurrency フィールドを追加して指定できます。

ターゲットアノテーションを使用したリビジョンテンプレート YAML の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: 50
    spec:
      containers:
      - image: myimage

containerConcurrency アノテーションを使用したリビジョンテンプレート YAML の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
    spec:
      containerConcurrency: 100
      containers:
      - image: myimage

targetcontainerConcurrency の両方の値を追加することにより、同時要求の target 数をターゲットとして設定できますが、これにより要求の containerConcurrency 数のハード制限も設定されます。

たとえば、target 値が 50 で、containerConcurrency 値が 100 の場合、要求のターゲットに設定された数は 50 になりますが、ハード制限は 100 になります。

containerConcurrency 値が target 値よりも低い場合、実際に処理できる数よりも多くの要求をターゲットとして設定する必要はないため、target 値は小さい値に調整されます。

注記

containerConcurrency は、特定の時点にアプリケーションに到達する要求の数を制限する明らかな必要がある場合にのみ使用する必要があります。containerConcurrency は、アプリケーションで同時実行の制約を実行する必要がある場合にのみ使用することを推奨します。

5.3.2.1. ターゲットアノテーションの使用による同時要求の設定

同時要求数のデフォルトターゲットは 100 ですが、リビジョンテンプレートで autoscaling.knative.dev/target アノテーション値を追加または変更することによってこの値を上書きできます。

以下は、ターゲットを 50 に設定するためにこのアノテーションをリビジョンテンプレートで使用する方法の例を示しています。

autoscaling.knative.dev/target: 50

5.3.2.2. containerConcurrency フィールドを使用した同時要求の設定

containerConcurrency は、処理される同時要求数にハード制限を設定します。

containerConcurrency: 0 | 1 | 2-N
0
無制限の同時要求を許可します。
1
リビジョンコンテナーの所定インスタンスによって一度に処理される要求は 1 つのみであることを保証します。
2 以上
同時要求をこの数に制限します。
注記

target アノテーションがない場合、自動スケーリングは、targetcontainerConcurrency の値と等しい場合のように設定されます。

5.3.3. Knative Serving 自動スケーリングのスケール境界の設定

minScale および maxScale アノテーションは、アプリケーションを提供できる Pod の最小および最大数を設定するために使用できます。これらのアノテーションは、コールドスタートを防いだり、コンピューティングコストをコントロールするために使用できます。

minScale
minScale アノテーションが設定されていない場合、Pod はゼロ (または、enable-scale-to-zero が ConfigMap に基づいて false の場合は 1) にスケーリングします。
maxScale
maxScale アノテーションが設定されていない場合、作成される Pod 数の上限はありません。

minScale および maxScale は、リビジョンテンプレートで以下のように設定できます。

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "2"
        autoscaling.knative.dev/maxScale: "10"

これらのアノテーションをリビジョンテンプレートで使用することで、この設定が PodAutoscaler オブジェクトに伝播します。

注記

これらのアノテーションは、リビジョンの有効期間全体で適用されます。リビジョンがルートで参照されていない場合でも、 minScale によって指定される最小 Pod 数は依然として指定されます。ルーティングできないリビジョンについては、ガべージコレクションの対象になることに留意してください。これにより、Knative はリソースを回収できます。

5.4. トラフィック管理

リビジョンは、Knative サービスに加えられたそれぞれの変更についてのコードおよび設定の特定の時点のスナップショットです。サービスの設定が更新されるたびに、サービスの新規リビジョンが作成されます。リビジョンはイミュータブル(変更不可)オブジェクトであり、必要または使用されている限り保持することができます。Knative Serving リビジョンは、着信トラフィックに応じて自動的にスケールアップおよびスケールダウンできます。

サービスリソースのトラフィック仕様を変更することで、Knative サービスの異なるリビジョン へのトラフィックのルーティング を管理できます。

Knative service architecture

5.4.1. トラフィックルーティングの例

Knative サービスの作成時に、デフォルトの トラフィック 仕様設定は含まれません。traffic 仕様を設定することで、任意の数の固定リビジョンでトラフィックを分割したり、トラフィックを最新のリビジョンに送信することもできます。

5.4.1.1. 複数のリビジョン間のトラフィックルーティング

以下の例は、トラフィックが 複数のリビジョン間で分割されるように、トラフィック仕様のリビジョンの一覧を拡張する方法を示しています。

この例では、トラフィックを current としてタグ付けされたリビジョンに 50% を送信します。また、候補 としてタグ付けされたリビジョンの 50% を送信します。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 50
  - tag: candidate
    revisionName: example-service-2
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0

5.4.1.2. 最新リビジョンへのトラフィックルーティング

以下の例は、トラフィックの 100% がサービスの最新リビジョンにルーティングされるトラフィック仕様を示しています。ステータス では、latest Revision が解決する最新リビジョン の名前を確認できます。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - latestRevision: true
    percent: 100
status:
  ...
  traffic:
  - percent: 100
    revisionName: example-service

5.4.1.3. 現在のリビジョンへのトラフィックルーティング

以下の例は、トラフィックの 100% が 現行 としてタグ付けされたリビジョンにルーティングされ、そのリビジョンの名前は example-service として指定されるトラフィック仕様を示しています。latest とタグ付けされたリビジョンは、トラフィックが宛先にルーティングされない場合でも、利用可能な状態になります。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service
    percent: 100
  - tag: latest
    latestRevision: true
    percent: 0

5.4.2. OpenShift Container Platform Web コンソールを使用したリビジョン間のトラフィックの管理

サーバーレスアプリケーションの作成後、アプリケーションは OpenShift Container Platform Web コンソールの Developer パースペクティブの Topology ビューに表示されます。アプリケーションのリビジョンはノードによって表され、Knative サービスはノードの周りの四角形で示されます。

コードまたはサービス設定の新たな変更により、特定のタイミングでコードのスナップショットである新規リビジョンが作成されます。サービスの場合、必要に応じてこれを分割し、異なるリビジョンにルーティングして、サービスのリビジョン間のトラフィックを管理することができます。

手順

Topology ビューでアプリケーションの複数のリビジョン間でトラフィックを分割するには、以下を行います。

  1. Knative サービスをクリックし、サイドパネルの概要を表示します。
  2. Resources タブをクリックして、サービスの Revisions および Routes の一覧を表示します。

    図5.1 Serverless アプリケーション

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

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

      odc serverless revisions

5.4.3. Knative CLI を使用したトラフィック管理

kn service update コマンドを使用して、サービスのリビジョン間でトラフィックを分割できます。

コマンドの例

$ kn service update <service_name> --traffic <revision>=<percent>

ここで、

  • <service_name> は、トラフィックルーティングを設定する Knative サービスの名前です。
  • <revision> は、トラフィックの割合を受信するように設定するリビジョンです。リビジョンの名前または --tag フラグを使用して、リビジョンに割り当てたタグのいずれかを指定できます。
  • <percent> は、指定されたリビジョンに送信するトラフィックの割合です。

5.4.3.1. 複数のフラグおよび順序の優先順位

すべてのトラフィック関連のフラグは、単一の kn service update コマンドを使用して指定できます。kn は、これらのフラグの優先順位を定義します。コマンドの使用時に指定されるフラグの順番は考慮に入れられません。

kn で評価されるフラグの優先順位は以下のとおりです。

  1. --untag: このフラグで参照されるすべてのリビジョンはトラフィックブロックから削除されます。
  2. --tag: リビジョンはトラフィックブロックで指定されるようにタグ付けされます。
  3. --traffic: 参照されるリビジョンには、分割されたトラフィックの一部が割り当てられます。

    重要

    --traffic フラグは 1 つのコマンドで複数回指定でき、すべてのフラグの Percent 値の合計が 100 になる場合にのみ有効です。

タグをリビジョンに追加してから、設定したタグに応じてトラフィックを分割することができます。

5.4.3.2. トラフィック管理コマンドの例

以下のコマンドでは 、@latest タグが blue がサービスの最新リビジョンに解決することを意味します。

$ kn service update example-service --tag green=revision-0001 --tag blue=@latest

緑色の タグおよび blue タグが適用された後に、以下のコマンドを実行し、トラフィックのリビジョンの 80% をリビジョンの green および 20% に送信することで、example-service という名前のサービスのトラフィックを分割できます。

$ kn service update example-service --traffic green=80 --traffic blue=20

または、以下のコマンドを使用して、タグ を使用せずに、トラフィックの 80% を最新のリビジョンおよび 20% のリビジョンに送信できます。

$ kn service update example-service --traffic @latest=80 --traffic v1=20
注記

--traffic フラグを指定して、コマンドごとに識別子 @latest を 1 つだけ使用できます。

5.4.3.3. Knative CLI トラフィック管理フラグ

kn CLI は kn service update コマンドの一環として、サービスのトラフィックブロックでのトラフィック操作をサポートします。

以下の表は、トラフィック分割フラグ、値の形式、およびフラグが実行する操作の概要を表示しています。Repetition 列は、フラグの特定の値が kn service update コマンドで許可されるかどうかを示します。

フラグ操作繰り返し

--traffic

RevisionName=Percent

Percent トラフィックを RevisionName に指定します。

はい

--traffic

Tag=Percent

Percent トラフィックを、Tag を持つリビジョンに指定します。

はい

--traffic

@latest=Percent

Percent トラフィックを準備状態にある最新のリビジョンに指定します。

いいえ

--tag

RevisionName=Tag

TagRevisionName に指定します。

はい

--tag

@latest=Tag

Tag を準備状態にある最新リビジョンに指定します。

いいえ

--untag

Tag

リビジョンから Tag を削除します。

はい

5.4.3.4. リビジョンのカスタム URL

kn service update コマンドを使用して --tag フラグをサービスに割り当てると、サービスの更新時に作成されるリビジョンのカスタム URL が作成されます。カスタム URL は https://<tag>-<service_name>-<namespace>.<domain>; または http://<tag>-<service_name>-<namespace>.<domain>; パターンに従います。

--tag および --untag フラグは以下の構文を使用します。

  • 1 つの値が必要です。
  • サービスのトラフィックブロックに一意のタグを示します。
  • 1 つのコマンドで複数回指定できます。
5.4.3.4.1. 例: リビジョンへのタグの割り当て

以下の例では、tag latestexample-revision という名前のリビジョンに割り当てます。

$ kn service update <service_name> --tag @latest=example-tag
5.4.3.4.2. 例: リビジョンからのタグの削除

--untag フラグを使用して、カスタム URL を削除するタグを削除できます。

注記

リビジョンのタグが削除され、トラフィックの 0% が割り当てられる場合、リビジョンはトラフィックブロックから完全に削除されます。

以下のコマンドは、example-revision という名前のリビジョンからすべてのタグを削除します。

$ kn service update <service_name> --untag example-tag

5.4.4. blue-green デプロイメントストラテジーを使用したトラフィックのルーティングおよび管理

Blue-green デプロイメントストラテジー を使用して、実稼働バージョンのアプリケーションから新規バージョンにトラフィックを安全に再ルーティングすることができます。

手順

  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:
      traffic:
        - revisionName: <first_revision_name>
          percent: 100 # All traffic goes to this revision
    ...
  4. 以下のコマンドを実行して、URL の出力でアプリケーションを表示できることを確認します。

    $ oc get ksvc <service_name>
  5. サービスの テンプレート 仕様の少なくとも 1 つのフィールドを変更して、アプリケーションの 2 番目のリビジョンをデプロイし、これを再デプロイします。たとえば、サービスの イメージや 環境変数 を変更できます。サービス YAML ファイルを適用するか、または 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 リソースを再適用してこのサービスを再デプロイすると、アプリケーションの 2 番目のリビジョンがステージングされます。トラフィックはメイン 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. すべてのトラフィックを新しいバージョンのアプリケーションにルーティングできる状態になったら、再度サービスを更新して、トラフィックを 2 番目のリビジョンに送信します。

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

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

    ヒント

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

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

5.5. OpenShift Logging の使用

5.5.1. OpenShift Logging のデプロイについて

OpenShift Container Platform クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI コマンドを使用して OpenShift Logging をデプロイし、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator をインストールできます。Operator がインストールされている場合、 ClusterLogging カスタムリソース (Custom Resource、CR) を作成して OpenShift Logging Pod および OpenShift Logging のサポートに必要な他のリソースをスケジュールします。Operator は OpenShift Logging のデプロイ、アップグレード、および維持を行います。

ClusterLogging CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全な OpenShift Logging 環境を定義します。Red Hat OpenShift Logging Operator は OpenShift Logging CR を監視し、ロギングデプロイメントを適宜調整します。

管理者およびアプリケーション開発者は、表示アクセスのあるプロジェクトのログを表示できます。

5.5.2. OpenShift Logging のデプロイおよび設定について

OpenShift Logging は、小規模および中規模の OpenShift Container Platform クラスター用に調整されたデフォルト設定で使用されるように設計されています。

以下のインストール方法には、サンプルの ClusterLogging カスタムリソース (CR) が含まれます。これを使用して、OpenShift Logging インスタンスを作成し、OpenShift Logging 環境を設定することができます。

デフォルトの OpenShift Logging インストールを使用する必要がある場合は、サンプル CR を直接使用できます。

デプロイメントをカスタマイズする必要がある場合、必要に応じてサンプル CR に変更を加えます。以下では、OpenShift Logging インスタンスのインストール時に実行し、インストール後に変更する設定について説明します。ClusterLoggingカスタムリソース外で加える変更を含む、各コンポーネントの使用方法については、設定についてのセクションを参照してください。

5.5.2.1. OpenShift Logging の設定およびチューニング

OpenShift Logging 環境は、openshift-logging プロジェクトにデプロイされる ClusterLogging カスタムリソースを変更することによって設定できます。

インストール時またはインストール後に、以下のコンポーネントのいずれかを変更することができます。

メモリーおよび CPU
resources ブロックを有効なメモリーおよび CPU 値で変更することにより、各コンポーネントの CPU およびメモリーの両方の制限を調整することができます。
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
      type: kibana
Elasticsearch ストレージ
storageClass name および size パラメーターを使用し、Elasticsearch クラスターの永続ストレージのクラスおよびサイズを設定できます。Red Hat OpenShift Logging Operator は、これらのパラメーターに基づいて、Elasticsearch クラスターの各データノードについて永続ボリューム要求 (PVC) を作成します。
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

この例では、クラスターの各データノードが「gp2」ストレージの「200G」を要求する PVC にバインドされるように指定します。それぞれのプライマリーシャードは単一のレプリカによってサポートされます。

注記

storage ブロックを省略すると、一時ストレージのみを含むデプロイメントになります。

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Elasticsearch レプリケーションポリシー

Elasticsearch シャードをクラスター内のデータノードにレプリケートする方法を定義するポリシーを設定できます。

  • FullRedundancy:各インデックスのシャードはすべてのデータノードに完全にレプリケートされます。
  • MultipleRedundancy:各インデックスのシャードはデータノードの半分に分散します。
  • SingleRedundancy:各シャードの単一コピー。2 つ以上のデータノードが存在する限り、ログは常に利用可能かつ回復可能です。
  • ZeroRedundancy:シャードのコピーはありません。ログは、ノードの停止または失敗時に利用不可になる (または失われる) 可能性があります。

5.5.2.2. 変更された ClusterLogging カスタムリソースのサンプル

以下は、前述のオプションを使用して変更された ClusterLogging カスタムリソースの例です。

変更された ClusterLogging リソースのサンプル

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 32Gi
        requests:
          cpu: 3
          memory: 32Gi
        storage:
          storageClassName: "gp2"
          size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

5.5.3. OpenShift Logging の使用による Knative Serving コンポーネントのログの検索

手順

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

5.5.4. OpenShift Logging を使用した Knative Serving でデプロイされたサービスのログの検索

OpenShift Logging により、アプリケーションがコンソールに書き込むログは Elasticsearch で収集されます。以下の手順で、Knative Serving を使用してデプロイされたアプリケーションにこれらの機能を適用する方法の概要を示します。

手順

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

    $ oc -n openshift-logging get route kibana
  2. ルートの URL を使用して Kibana ダッシュボードに移動し、ログインします。
  3. インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。
  4. knative-serving 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 ベースの構造化ロギングを使用することで、実稼働環境でのこれらのログの迅速なフィルターを実行できます。

5.6. Jaeger を使用した要求のトレース

Jaeger を OpenShift Serverless で使用すると、OpenShift Container Platform でのサーバーレスアプリケーションの 分散トレース を有効にできます。

分散トレースは、アプリケーションを構成する各種のサービスを使用した要求のパスを記録します。

これは、各種の異なる作業単位についての情報を連携させ、分散トランザクションでのイベントチェーン全体を把握できるようにするために使用されます。作業単位は、異なるプロセスまたはホストで実行される場合があります。

開発者は分散トレースを使用し、大規模なアーキテクチャーで呼び出しフローを可視化できます。これは、シリアル化、並行処理、およびレイテンシーのソースについての理解に役立ちます。

Jaeger についての詳細は、「Jaeger アーキテクチャー」および「Jaeger のインストール」を参照してください。

5.6.1. OpenShift Serverless で使用する Jaeger の設定

前提条件

OpenShift Serverless で使用する Jaeger を設定するには、以下が必要です。

  • OpenShift Container Platform クラスターでのクラスター管理者パーミッション。
  • OpenShift Serverless Operator および Knative Serving が現時点でインストールされていること。
  • Jaeger Operator が現時点でインストールされていること。

手順

  1. 以下を含む Jaeger カスタムリソース YAML ファイルを作成し、これを適用します。

    Jaeger CR

    apiVersion: jaegertracing.io/v1
    kind: Jaeger
    metadata:
      name: jaeger
      namespace: default

  2. KnativeServing CR を編集し、トレース用に YAML 設定を追加して、Knative Serving のトレースを有効にします。

    トレース用の YAML の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        tracing:
          sample-rate: "0.1" 1
          backend: zipkin 2
          zipkin-endpoint: http://jaeger-collector.default.svc.cluster.local:9411/api/v2/spans 3
          debug: "false" 4

    1
    sample-rate はサンプリングの可能性を定義します。sample-rate: "0.1" を使用すると、10 トレースの内の 1 つがサンプリングされます。
    2
    backendzipkin に設定される必要があります。
    3
    zipkin-endpointjaeger-collector サービスエンドポイントを参照する必要があります。このエンドポイントを取得するには、Jaeger CR が適用される namespace を置き換えます。
    4
    デバッグは false に設定する必要があります。debug: "true" を設定してデバッグモードを有効にすることで、サンプリングをバイパスしてすべてのスパンがサーバーに送信されるようにします。

検証

jaeger ルートを使用して Jaeger Web コンソールにアクセスし、追跡データを表示できます。

  1. 以下のコマンドを入力して jaeger ルートのホスト名を取得します。

    $ oc get route jaeger

    出力例

    NAME     HOST/PORT                         PATH   SERVICES       PORT    TERMINATION   WILDCARD
    jaeger   jaeger-default.apps.example.com          jaeger-query   <all>   reencrypt     None

  2. ブラウザーでエンドポイントアドレスを開き、コンソールを表示します。

5.7. Knative サービスの JSON Web Token 認証の設定

サービスメッシュと OpenShift Serverless および Kourier との統合がクラスターに設定された後、Knative サービスの JSON Web Token (JWT) 認証を有効にすることができます。

重要

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

5.7.1. Knative サービスのサイドカーコンテナー挿入の有効化

sidecar.istio.io/inject="true" アノテーション を Knative サービスに追加し、そのサービスのサイドカーの挿入を有効にできます。

重要

knative-serving および knative-serving-ingress などのシステム namespace の Pod へのサイドカー挿入の追加は、Kourier が有効化されている場合はサポートされません。

これらの namespace の Pod にサイドカーの挿入が必要な場合は、「サービスメッシュと OpenShift Serverless のネイティブに統合」に関する OpenShift Serverless のドキュメントを参照してください。

手順

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

    サービスの例

    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
    オプション: JSON Web Token (JWT) 認証を有効にしている場合は、sidecar.istio.io/rewriteAppHTTPProbers="true" アノテーションを追加します。
  2. Service リソースの YAML ファイルを適用します。

    $ oc apply -f <filename>

5.7.2. Service Mesh 2.x および OpenShift Serverless での JSON Web トークン認証の使用

手順

  1. 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
  2. RequestAuthentication リソースを適用します。

    $ oc apply -f <filename>
  3. 以下の 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 でプローブするアプリケーションのパス。
  4. AuthorizationPolicy リソースを適用します。

    $ oc apply -f <filename>
  5. 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"]
  6. 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!

5.7.3. Service Mesh 1.x および OpenShift Serverless での JSON Web トークン認証の使用

手順

  1. 有効な 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 でプローブするアプリケーションのパス。
  2. 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!

5.8. Knative サービスのカスタムドメインの設定

Knative サービスには、クラスターの設定に基づいてデフォルトのドメイン名が自動的に割り当てられます。例: <service_name>.<namespace>.example.com

以下の方法のいずれかを使用して、Knative サービスのドメインをカスタマイズできます。

  • サービスをプライベートサービスとして設定し、必要なサービスメッシュリソースを作成します。

    重要

    カスタムドメインの設定方法は、Kourier が有効になっているクラスターでのみサポートされます。Kourier を有効化せずに、OpenShift Serverless with Service Mesh のみを使用してカスタムドメインを設定する必要がある場合は、代わりに DomainMapping リソースメソッドを使用します。

  • サービスの DomainMapping リソースを作成して、Knative サービスに独自のカスタムドメイン名をマップします。複数の DomainMapping を作成して、複数のドメインおよびサブドメインを単一サービスにマップすることもできます。

    重要

    DomainMapping リソースを使用して、クラスターでの Kourier の有効化の有無にかかわらず、カスタムドメインをマッピングできますが、Kourier とドメインマッピングの両方が有効になっているクラスターでは TLS はサポートされません。

5.8.1. カスタムドメインマッピングの作成

カスタムドメイン名をカスタムリソース (CR) にマッピングするには、Knative サービスまたは Knative ルートなどの Addressable target CR にマップする DomainMapping CR を作成する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Knative サービスを作成し、そのサービスにマップするカスタムドメインを制御できる。

    注記

    カスタムドメインは OpenShift Container Platform クラスターの IP アドレスを参照する必要があります。

手順

  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.com
     namespace: default
    spec:
     ref:
       name: example-service
       kind: Service
       apiVersion: serving.knative.dev/v1

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

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

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

    $ oc apply -f <filename>

5.8.2. Knative CLI を使用したカスタムドメインマッピングの作成

kn CLI を使用して、Knative サービスまたは Knative ルートなどのアドレス指定可能なターゲット CR にマップする DomainMapping カスタムリソース (CR) を作成できます。

--ref フラグは、ドメインマッピング用のアドレス指定可能なターゲット CR を指定します。

--ref フラグの使用時にプレフィックスが指定されていない場合、ターゲットが現在の namespace の Knative サービスであることを前提としています。以下の手順の例では、Knative サービスまたは Knative ルートにマップするプレフィックスを示しています。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Knative サービスまたはルートを作成し、その CR にマップするカスタムドメインを制御している。

    注記

    カスタムドメインは OpenShift Container Platform クラスターの DNS を参照する必要があります。

  • kn CLI ツールがインストールされている。

手順

  • ドメインを現在の namespace の CR にマップします。

    $ kn domain create <domain_mapping_name> --ref <target_name>

    コマンドの例

    $ kn domain create example.com --ref example-service

  • ドメインを指定された namespace の Knative サービスにマップします。

    $ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>

    コマンドの例

    $ kn domain create example.com --ref ksvc:example-service:example-namespace

  • ドメインを Knative ルートにマップします。

    $ kn domain create <domain_mapping_name> --ref <kroute:route_name>

    コマンドの例

    $ kn domain create example.com --ref kroute:example-route

5.8.3. プライベート Knative サービスのカスタムドメインの設定

以下の手順を完了して、既存の Knative サービスのカスタムドメインを設定できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving が OpenShift Container Platform クラスターにインストールされている。
  • Red Hat OpenShift Service Mesh バージョン 1.x または 2.x がクラスターにインストールされており、Red Hat OpenShift Service Mesh と OpenShift Serverless との統合が適切に設定されている。
重要

OpenShift Serverless は、本書で明示的に文書化されている Red Hat OpenShift Service Mesh 機能の使用のみをサポートし、文書化されていない他の機能はサポートしません。

5.8.3.1. クラスター可用性の cluster-local への設定

デフォルトで、Knative サービスはパブリック IP アドレスに公開されます。パブリック IP アドレスに公開されているとは、Knative サービスがパブリックアプリケーションであり、一般にアクセス可能な URL があることを意味します。

一般にアクセス可能な URL は、クラスター外からアクセスできます。ただし、開発者は プライベートサービス と呼ばれるクラスター内からのみアクセス可能なバックエンドサービスをビルドする必要がある場合があります。開発者は、クラスター内の個々のサービスに networking.knative.dev/visibility=cluster-local ラベルを使用してラベル付けし、それらをプライベートにすることができます。

重要

OpenShift Serverless 1.15.0 以降のバージョンの場合には、serving.knative.dev/visibility ラベルは利用できなくなりました。既存のサービスを更新して、代わりに networking.knative.dev/visibility ラベルを使用する必要があります。

手順

  • networking.knative.dev/visibility=cluster-local ラベルを追加して、サービスの可視性を設定します。

    $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local

検証

  • 以下のコマンドを入力して出力を確認し、サービスの URL の形式が http://<service_name>.<namespace>.svc.cluster.local であることを確認します。

    $ oc get ksvc

    出力例

    NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
    hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

5.8.3.2. 必要なサービスメッシュリソースの作成

サービスメッシュでカスタムドメインを使用するには、まず必要なサービスメッシュリソースを作成する必要があります。

手順

  1. トラフィックを受け入れる Istio ゲートウェイを作成します。

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: <namespace> 1
    spec:
      selector:
        istio: ingressgateway
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:
        - "*"
    1
    Knative サービスが作成された namespace。この namespace はサービスメッシュメンバーロールのメンバーである必要があります。
  2. Gateway リソースを適用します。

    $ oc apply -f <filename>
  3. Istio 仮想サービスを作成して、ホストヘッダーを書き換えます。

    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: hello
    spec:
      hosts:
      - custom-ksvc-domain.example.com
      gateways:
      - default-gateway
      http:
      - rewrite:
          authority: hello.default.svc 1
        route:
        - destination:
            host: hello.default.svc 2
            port:
              number: 80
    1 2
    Knative サービスは、<service_name>.<namespace>.svc 形式の Knative サービスです。
  4. VirtualService リソースを適用します。

    $ oc apply -f <filename>
  5. Istio サービスエントリーを作成します。これは、Kourier がサービスメッシュ外にあるため、OpenShift Serverless に必要です。

    apiVersion: networking.istio.io/v1alpha3
    kind: ServiceEntry
    metadata:
      name: hello.default.svc
    spec:
      hosts:
      - hello.default.svc 1
      location: MESH_EXTERNAL
      endpoints:
      - address: kourier-internal.knative-serving-ingress.svc
      ports:
      - number: 80
        name: http
        protocol: HTTP
      resolution: DNS
    1
    Knative サービスは、<service_name>.<namespace>.svc 形式の Knative サービスです。
  6. ServiceEntry リソースを適用します。

    $ oc apply -f <filename>
  7. VirtualService オブジェクトを参照する OpenShift Container Platform ルートを作成します。

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: hello
      namespace: istio-system 1
    spec:
      host: custom-ksvc-domain.example.com
      port:
        targetPort: 8080
      to:
        kind: Service
        name: istio-ingressgateway
    1
    OpenShift Container Platform ルートは ServiceMeshControlPlane と同じ namespace に作成される必要があります。この例では、ServiceMeshControlPlaneistio-system namespace にデプロイされます。
  8. Route リソースを適用します。

    $ oc apply -f <filename>

5.8.3.3. カスタムドメインを使用したサービスへのアクセス

手順

  1. curl 要求の Host ヘッダーを使用してカスタムドメインにアクセスします。以下は例になります。

    $ curl -H "Host: custom-ksvc-domain.example.com" http://<ip_address>

    ここで、<ip_address> は、OpenShift Container Platform Ingress ルーターが公開される IP アドレスになります。

    出力例

    Hello OpenShift!

5.8.4. 関連情報

5.9. Red Hat OpenShift Service Mesh および Kourier を使用したカスタムドメインの Transport Layer Security の設定

Red Hat OpenShift Service Mesh を使用して、カスタムドメインおよびサブドメインの TLS (Transport Layer Security) キーおよび証明書を作成できます。

重要

OpenShift Serverless は、本書で明示的に文書化されている Red Hat OpenShift Service Mesh 機能の使用のみをサポートし、文書化されていない他の機能はサポートしません。

5.9.1. 前提条件

  • OpenShift Serverless をインストールします。
  • Red Hat OpenShift Service Mesh 1.x または 2.x をインストールします。

    重要

    OpenShift Serverless は、Red Hat OpenShift Service Mesh 1.x または 2.x の完全な実装とのみ互換性があります。OpenShift Serverless は、同じデプロイメントにある一部の 1.x リソースと一部の 2.x リソースのカスタム使用をサポートしません。たとえば、コントロールプレーンの maistra.io/v1 仕様を依然として使用する際に 2.x にアップグレードすることはサポートされていません。

  • サービスメッシュと OpenShift Serverless の統合」の設定手順を完了します。
  • カスタムドメインを設定します。「Knative サービスのカスタムドメインの設定」を参照してください。
  • この例では、openssl を使用して証明書を生成しますが、これらを作成するには、任意の証明書生成ツールを使用できます。
重要

この例では、example.com ドメインを使用します。このドメインの証明書のサンプルは、サブドメイン証明書に署名する認証局 (CA) として使用されます。

実際のデプロイメントでこの手順を完了し、検証するには、一般に信頼されているパブリック CA または組織が提供する CA のいずれかが署名した証明書が必要になります。

コマンドの例は、ドメイン、サブドメイン、および CA に合わせて調整する必要があります。

5.9.2. Red Hat OpenShift Service Mesh 2.x を使用したカスタムドメインの Transport Layer Security の設定

Red Hat OpenShift Service Mesh を使用して、カスタムドメインおよびサブドメインの TLS (Transport Layer Security) キーおよび証明書を作成できます。

手順

  1. サービスの証明書の署名用にルート証明書およびプライベートキーを作成します。

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example Inc./CN=example.com' \
        -keyout example.com.key \
        -out example.com.crt
  2. ドメインの証明書署名要求を作成します。

    $ openssl req -out custom.example.com.csr -newkey rsa:2048 -nodes \
        -keyout custom.example.com.key \
        -subj "/CN=custom-ksvc-domain.example.com/O=Example Inc."
  3. CA を使用して要求に署名します。

    $ openssl x509 -req -days 365 -set_serial 0 \
        -CA example.com.crt \
        -CAkey example.com.key \
        -in custom.example.com.csr \
        -out custom.example.com.crt
  4. 証明書がディレクトリーに表示されることを確認します。

    $ ls -1

    出力例

    custom.example.com.crt
    custom.example.com.csr
    custom.example.com.key
    example.com.crt
    example.com.key

  5. シークレットを作成します。

    $ oc create -n istio-system secret tls custom.example.com \
        --key=custom.example.com.key \
        --cert=custom.example.com.crt
  6. ServiceMeshControlPlane リソースを編集して、シークレットを Istio Ingress ゲートウェイに割り当てます。

    1. ServiceMeshControlPlane リソースを編集します。

      $ oc edit -n istio-system ServiceMeshControlPlane <control-plane-name>
    2. 以下の行がリソースに存在することを確認します。存在しない場合は追加してください。

      spec:
        gateways:
          ingress:
            volumes:
            - volume:
                secret:
                  secretName: custom.example.com
              volumeMount:
                name: custom-example-com
                mountPath: /custom.example.com
  7. シークレットを使用するように Istio Ingress ゲートウェイを更新します。

    1. default-gateway リソースを編集します。

      $ oc edit gateway default-gateway
    2. 以下の行がリソースに存在することを確認します。存在しない場合は追加してください。

      - hosts:
        - custom-ksvc-domain.example.com
        port:
          name: https
          number: 443
          protocol: HTTPS
        tls:
          mode: SIMPLE
          privateKey: /custom.example.com/tls.key
          serverCertificate: /custom.example.com/tls.crt
  8. パススルー TLS および 8443spec.port.targetPort として使用するようにルートを更新します。

    1. ルートを編集します。

      $ oc edit route -n istio-system hello
    2. 以下の設定をルートに追加します。

      spec:
        host: custom-ksvc-domain.example.com
        port:
          targetPort: 8443
        tls:
          insecureEdgeTerminationPolicy: None
          termination: passthrough
        to:
          kind: Service
          name: istio-ingressgateway
          weight: 100
        wildcardPolicy: None

検証

  • CA によって信頼されるセキュアな接続でサーバーレスアプリケーションにアクセスします。

    $ curl --cacert example.com.crt \
        --header "Host: custom-ksvc-domain.example.com" \
        --resolve "custom-ksvc-domain.example.com:443:<ingress_router_IP>" \
         https://custom-ksvc-domain.example.com:443
    注記

    <ingress_router_IP> の独自の値に置き換える必要があります。この IP またはホスト名の値を検索する手順は、OpenShift Container Platform プロバイダープラットフォームによって異なります。

    Ingress IP を見つけるコマンドの例

    このコマンドは、GCP および Azure プロバイダープラットフォームに有効です。

    $ oc get svc -n openshift-ingress router-default \
        -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

    出力例

    Hello OpenShift!

5.9.3. Red Hat OpenShift Service Mesh 1.x を使用したカスタムドメインの Transport Layer Security の設定

Red Hat OpenShift Service Mesh を使用して、カスタムドメインおよびサブドメインの TLS (Transport Layer Security) キーおよび証明書を作成できます。

手順

  1. サービスの証明書の署名用にルート証明書およびプライベートキーを作成します。

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example Inc./CN=example.com' \
        -keyout example.com.key \
        -out example.com.crt
  2. ドメインの証明書署名要求を作成します。

    $ openssl req -out custom.example.com.csr -newkey rsa:2048 -nodes \
        -keyout custom.example.com.key \
        -subj "/CN=custom-ksvc-domain.example.com/O=Example Inc."
  3. CA を使用して要求に署名します。

    $ openssl x509 -req -days 365 -set_serial 0 \
        -CA example.com.crt \
        -CAkey example.com.key \
        -in custom.example.com.csr \
        -out custom.example.com.crt
  4. 証明書がディレクトリーに表示されることを確認します。

    $ ls -1

    出力例

    custom.example.com.crt
    custom.example.com.csr
    custom.example.com.key
    example.com.crt
    example.com.key

  5. シークレットを作成します。

    $ oc create -n istio-system secret tls custom.example.com \
        --key=custom.example.com.key \
        --cert=custom.example.com.crt
  6. ServiceMeshControlPlane リソースを編集して、シークレットを Istio Ingress ゲートウェイに割り当てます。

    1. ServiceMeshControlPlane リソースを編集します。

      $ oc edit -n istio-system ServiceMeshControlPlane <control_plane_name>
    2. 以下の行がリソースに存在することを確認します。存在しない場合は追加してください。

      spec:
        istio:
          gateways:
            istio-ingressgateway:
              secretVolumes:
              - mountPath: /custom.example.com
                name: custom-example-com
                secretName: custom.example.com
  7. シークレットを使用するように Istio Ingress ゲートウェイを更新します。

    1. default-gateway リソースを編集します。

      $ oc edit gateway default-gateway
    2. 以下の行がリソースに存在することを確認します。存在しない場合は追加してください。

      - hosts:
        - custom-ksvc-domain.example.com
        port:
          name: https
          number: 443
          protocol: HTTPS
        tls:
          mode: SIMPLE
          privateKey: /custom.example.com/tls.key
          serverCertificate: /custom.example.com/tls.crt
  8. パススルー TLS および 8443spec.port.targetPort として使用するようにルートを更新します。

    1. ルートを編集します。

      $ oc edit route -n istio-system hello
    2. 以下の設定をルートに追加します。

      spec:
        host: custom-ksvc-domain.example.com
        port:
          targetPort: 8443
        tls:
          insecureEdgeTerminationPolicy: None
          termination: passthrough
        to:
          kind: Service
          name: istio-ingressgateway
          weight: 100
        wildcardPolicy: None

検証

  • CA によって信頼されるセキュアな接続でサーバーレスアプリケーションにアクセスします。

    $ curl --cacert example.com.crt \
        --header "Host: custom-ksvc-domain.example.com" \
        --resolve "custom-ksvc-domain.example.com:443:<ingress_router_IP>" \
         https://custom-ksvc-domain.example.com:443
    注記

    <ingress_router_IP> の独自の値に置き換える必要があります。この IP またはホスト名の値を検索する手順は、OpenShift Container Platform プロバイダープラットフォームによって異なります。

    Ingress IP を見つけるコマンドの例

    このコマンドは、GCP および Azure プロバイダープラットフォームに有効です。

    $ oc get svc -n openshift-ingress router-default \
        -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

    出力例

    Hello OpenShift!

5.10. Knative サービスのルートの設定

Knative は OpenShift Container Platform TLS 終端を使用して Knative サービスのルーティングを提供します。Knative サービスが作成されると、OpenShift Container Platform ルートがサービス用に自動的に作成されます。このルートは OpenShift Serverless Operator によって管理されます。OpenShift Container Platform ルートは、OpenShift Container Platform クラスターと同じドメインで Knative サービスを公開します。

OpenShift Container Platform ルーティングの Operator 制御を無効にすることで、Knative ルートを TLS 証明書を直接使用するように設定できます。

Knative ルートは OpenShift Container Platform ルートと共に使用し、トラフィック分割などの詳細なルーティング機能を提供します。

5.10.1. OpenShift Container Platform ルートのラベルおよびアノテーションのカスタマイズ

OpenShift Container Platform ルートは、Knative サービスの metadata 仕様を変更して設定できるカスタムラベルおよびアノテーションの使用をサポートします。カスタムラベルおよびアノテーションはサービスから Knative ルートに伝番され、次に Knative ingress に、最後に OpenShift Container Platform ルートに伝播されます。

前提条件

  • OpenShift Serverless Operator および Knative Serving が OpenShift Container Platform クラスターにインストールされている必要があります。

手順

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

    • 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
    ラベルおよびアノテーション名および値の値を使用します。

5.10.2. OpenShift Container Platform ルートでの Knative サービスの設定

Knative サービスを OpenShift Container Platform で TLS 証明書を使用するように設定するには、OpenShift Serverless Operator によるサービスのルートの自動作成を無効にし、代わりにサービスのルートを手動で作成する必要があります。

注記

以下の手順を完了すると、knative-serving-ingress namespace のデフォルトの OpenShift Container Platform ルートは作成されません。ただし、アプリケーションの Knative ルートはこの namespace に引き続き作成されます。

前提条件

  • OpenShift Serverless Operator および Knative Serving コンポーネントが OpenShift Container Platform クラスターにインストールされている。
注記

以下の手順では、サンプルコマンドの置換可能な値を変更する必要があります。

手順

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

    重要

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

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

5.10.3. クラスター可用性の cluster-local への設定

デフォルトで、Knative サービスはパブリック IP アドレスに公開されます。パブリック IP アドレスに公開されているとは、Knative サービスがパブリックアプリケーションであり、一般にアクセス可能な URL があることを意味します。

一般にアクセス可能な URL は、クラスター外からアクセスできます。ただし、開発者は プライベートサービス と呼ばれるクラスター内からのみアクセス可能なバックエンドサービスをビルドする必要がある場合があります。開発者は、クラスター内の個々のサービスに networking.knative.dev/visibility=cluster-local ラベルを使用してラベル付けし、それらをプライベートにすることができます。

重要

OpenShift Serverless 1.15.0 以降のバージョンの場合には、serving.knative.dev/visibility ラベルは利用できなくなりました。既存のサービスを更新して、代わりに networking.knative.dev/visibility ラベルを使用する必要があります。

手順

  • networking.knative.dev/visibility=cluster-local ラベルを追加して、サービスの可視性を設定します。

    $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local

検証

  • 以下のコマンドを入力して出力を確認し、サービスの URL の形式が http://<service_name>.<namespace>.svc.cluster.local であることを確認します。

    $ oc get ksvc

    出力例

    NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
    hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

5.10.4. 関連情報

5.11. Knative サービスのモニタリング

OpenShift Container Platform モニタリングスタックを使用して、Knative サービスのヘルスチェックおよびメトリクスを記録し、表示できます。本セクションでは、以下のトピックについて説明します。

  • デフォルトで公開するメトリクス Knative サービス
  • カスタムメトリクスの公開設定方法
  • 公開されるメトリクスを収集するためにモニタリングスタックを設定する方法
  • サービスのメトリクスの表示方法
注記

メトリクスの収集は、Knative サービスの自動スケーリングには影響しません。これは、収集要求がアクティベーターを通過しないためです。その結果、Pod が実行していない場合に収集が行われることはありません。

関連情報

5.11.1. デフォルトで公開される Knative サービスメトリクス

表5.1 ポート 9090 の各 Knative サービスについてデフォルトで公開されるメトリクス

メトリクス名、単位、およびタイプ詳細メトリックのタグ

queue_requests_per_second

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

キュープロキシーに到達する、1 秒あたりのリクエスト数。

Formula: stats.RequestCount / r.reportingPeriodSeconds

stats.RequestCount は、指定のレポート期間のネットワーク pkg 統計から直接計算されます。

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

queue_proxied_operations_per_second

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

1 秒あたりのプロキシー化された要求の数。

Formula: stats.ProxiedRequestCount / r.reportingPeriodSeconds

stats.ProxiedRequestCount は指定されたレポート期間のネットワーク pkg 統計から直接計算されます。

 

queue_average_concurrent_requests

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

この Pod で現在処理されている要求の数。

平均同時実行性は、ネットワークの pkg 側で次のように計算されます。

  • req の変更が行われると、変更間の時間デルタが計算されます。この結果に基づいて、デルタ上の現在の同時実行数が計算され、現在計算されている同時実行数に追加されます。また、デルタの合計が保持されます。

    デルタでの現在の同時実行処理は、以下のように計算されます。

    global_concurrency × delta

  • レポートが実行されるたびに、合計および現在の計算された同時実行性がリセットされます。
  • 平均同時実行値を報告すると、現在の計算処理はデルタの合計で除算されます。
  • 新しいリクエストが出されると、グローバル同時実行カウンターが増えます。リクエストが完了すると、カウンターが減少します。

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

queue_average_proxied_concurrent_requests

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

この Pod で現在処理されているプロキシー要求の数:

stats.AverageProxiedConcurrency

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

process_uptime

メトリック単位: 秒

メトリックのタイプ: ゲージ

プロセスが起動している秒数。

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

表5.2 ポート 9091 の各 Knative サービスについてデフォルトで公開されるメトリクス

メトリクス名、単位、およびタイプ詳細メトリックのタグ

request_count

メトリックの単位: dimensionless

メトリックの型: counter

queue-proxy にルーティングされる要求の数。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

request_latencies

メトリックの単位: ミリ秒

メトリックのタイプ: histogram

応答時間 (ミリ秒単位)。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

app_request_count

メトリックの単位: dimensionless

メトリックの型: counter

user-container にルーティングされる要求の数。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

app_request_latencies

メトリックの単位: ミリ秒

メトリックのタイプ: histogram

応答時間 (ミリ秒単位)。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

queue_depth

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

提供および待機キューの現在の項目数。無制限の同時実行の場合は報告されません。breaker.inFlight が使用されます。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

5.11.2. カスタムアプリケーションメトリクスを含む Knative サービス

Knative サービスによってエクスポートされるメトリクスのセットを拡張できます。正確な実装は、使用するアプリケーションと言語によって異なります。

以下のリストは、処理されたイベントカスタムメトリクスの数をエクスポートするサンプル Go アプリケーションを実装します。

package main

import (
  "fmt"
  "log"
  "net/http"
  "os"

  "github.com/prometheus/client_golang/prometheus" 1
  "github.com/prometheus/client_golang/prometheus/promauto"
  "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
  opsProcessed = promauto.NewCounter(prometheus.CounterOpts{ 2
     Name: "myapp_processed_ops_total",
     Help: "The total number of processed events",
  })
)


func handler(w http.ResponseWriter, r *http.Request) {
  log.Print("helloworld: received a request")
  target := os.Getenv("TARGET")
  if target == "" {
     target = "World"
  }
  fmt.Fprintf(w, "Hello %s!\n", target)
  opsProcessed.Inc() 3
}

func main() {
  log.Print("helloworld: starting server...")

  port := os.Getenv("PORT")
  if port == "" {
     port = "8080"
  }

  http.HandleFunc("/", handler)

  // Separate server for metrics requests
  go func() { 4
     mux := http.NewServeMux()
     server := &http.Server{
        Addr: fmt.Sprintf(":%s", "9095"),
        Handler: mux,
     }
     mux.Handle("/metrics", promhttp.Handler())
     log.Printf("prometheus: listening on port %s", 9095)
     log.Fatal(server.ListenAndServe())
  }()

   // Use same port as normal requests for metrics
  //http.Handle("/metrics", promhttp.Handler()) 5
  log.Printf("helloworld: listening on port %s", port)
  log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
}
1
Prometheus パッケージの追加。
2
opsProcessed メトリクスの定義。
3
opsProcessed メトリクスのインクリメント。
4
メトリクス要求に別のサーバーを使用するように設定。
5
メトリクスおよび metrics サブパスの通常の要求と同じポートを使用するように設定。

5.11.3. カスタムメトリクスの収集の設定

カスタムメトリクスの収集は、ユーザーワークロードのモニタリング用に設計された Prometheus のインスタンスで実行されます。ユーザーのワークロードのモニタリングを有効にしてアプリケーションを作成した後に、モニタリングスタックがメトリクスを収集する方法を定義する設定が必要になります。

以下のサンプル設定は、アプリケーションの ksvc を定義し、サービスモニターを設定します。正確な設定は、アプリケーションおよびメトリクスのエクスポート方法によって異なります。

apiVersion: serving.knative.dev/v1 1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      labels:
        app: helloworld-go
      annotations:
    spec:
      containers:
      - image: docker.io/skonto/helloworld-go:metrics
        resources:
          requests:
            cpu: "200m"
        env:
        - name: TARGET
          value: "Go Sample v1"
---
apiVersion: monitoring.coreos.com/v1 2
kind: ServiceMonitor
metadata:
  labels:
  name: helloworld-go-sm
spec:
  endpoints:
  - port: queue-proxy-metrics
    scheme: http
  - port: app-metrics
    scheme: http
  namespaceSelector: {}
  selector:
    matchLabels:
       name:  helloworld-go-sm
---
apiVersion: v1 3
kind: Service
metadata:
  labels:
    name:  helloworld-go-sm
  name:  helloworld-go-sm
spec:
  ports:
  - name: queue-proxy-metrics
    port: 9091
    protocol: TCP
    targetPort: 9091
  - name: app-metrics
    port: 9095
    protocol: TCP
    targetPort: 9095
  selector:
    serving.knative.dev/service: helloworld-go
  type: ClusterIP
1
アプリケーション仕様。
2
アプリケーションのメトリクスが収集される設定。
3
メトリクスの収集方法の設定。

関連情報

5.11.4. サービスのメトリックの検証

メトリクスとモニタリングスタックをエクスポートするようにアプリケーションを設定したら、Web コンソールでメトリクスを検査できます。

手順

  1. オプション: メトリクスに表示できるアプリケーションに対する要求を実行します。

    $ hello_route=$(oc get ksvc helloworld-go -n ns1 -o jsonpath='{.status.url}') && \
        curl $hello_route

    出力例

    Hello Go Sample v1!

  2. Web コンソールで、MonitoringMetrics インターフェースに移動します。
  3. 入力フィールドに、監視するメトリクスのクエリーを入力します。以下に例を示します。

    revision_app_request_count{namespace="ns1", job="helloworld-go-sm"}

    別の例:

    myapp_processed_ops_total{namespace="ns1", job="helloworld-go-sm"}
  4. 可視化されたメトリクスを確認します。

    Observing metrics of a service
    Observing metrics of a service

5.11.5. ダッシュボードでのサービスのメトリクスの検証

namespace でキュープロキシーメトリクスを集約する専用のダッシュボードを使用してメトリクスを検査できます。

手順

  1. Web コンソールで、MonitoringMetrics インターフェースに移動します。
  2. Knative User Services (Queue Proxy metrics) ダッシュボードを選択します。
  3. アプリケーションに対応する NamespaceConfiguration、および Revision を選択します。
  4. 可視化されたメトリクスを確認します。

    Observing metrics of a service using a dashboard

5.12. メトリクス

メトリクスを使用すると、開発者は Knative サービスのパフォーマンスを監視できます。

5.12.1. 前提条件

  • OpenShift Container Platform で Knative コンポーネントのメトリクスを表示するには、Web コンソールの Developer パースペクティブにアクセスできる必要があります。
警告

サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。

この問題の解決に関する詳細は、「Serverless 1.16.0 リリースノート」を参照してください。

5.12.2. キュープロキシーメトリクス

各 Knative サービスには、アプリケーションコンテナーへの接続をプロキシーするプロキシーコンテナーがあります。キュープロキシーのパフォーマンスについて多くのメトリクスが報告されます。

以下のメトリクスを使用して、要求がプロキシー側でキューに入れられているかどうか、およびアプリケーション側で要求を処理する際の実際の遅延を測定できます。

メトリクス名詳細タイプタグ単位

revision_request_count

queue-proxy Pod にルーティングされる要求の数。

カウンター

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

整数 (単位なし)

revision_request_latencies

リビジョン要求の応答時間。

ヒストグラム

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

ミリ秒

revision_app_request_count

user-container Pod にルーティングされる要求の数。

カウンター

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

整数 (単位なし)

revision_app_request_latencies

リビジョンアプリケーション要求の応答時間。

ヒストグラム

configuration_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

ミリ秒

revision_queue_depth

serving および waiting キューの現在の項目数。無制限の同時実行が設定されている場合には、このメトリクスは報告されません。

ゲージ

configuration_nameevent-displaycontainer_namenamespace_namepod_nameresponse_code_classrevision_nameservice_name

整数 (単位なし)

第6章 Knative Eventing

6.1. Knative Eventing について

OpenShift Container Platform 上の Knative Eventing を使用すると、開発者はサーバーレスアプリケーションと共に イベント駆動型のアーキテクチャー を使用できます。

6.1.1. イベント駆動型のアーキテクチャー

イベント駆動型のアーキテクチャーは、イベントを作成するイベントプロデューサーと、イベントを受信するイベント シンク またはコンシューマーとの間の切り離された関係の概念に基づいています。

Knative Eventing は、標準の HTTP POST リクエストを使用してイベントプロデューサーとシンク間でイベントを送受信します。これらのイベントは CloudEvents 仕様 に準拠しており、すべてのプログラミング言語でのイベントの作成、解析、および送受信を可能にします。

6.1.2. Knative Eventing ユースケース

Knative Eventing は以下のユースケースをサポートします。

コンシューマーを作成せずにイベントを公開する
イベントを HTTP POST としてブローカーに送信し、バインディングを使用してイベントを生成するアプリケーションから宛先設定を分離できます。
パブリッシャーを作成せずにイベントを消費
Trigger を使用して、イベント属性に基づいて Broker からイベントを消費できます。アプリケーションはイベントを HTTP POST として受信します。

6.1.3. Knative Eventing カスタムリソース

複数のタイプのシンクへの配信を有効にするために、Knative Eventing は複数の Kubernetes リソースで実装できる以下の汎用インターフェースを定義します。

アドレス指定可能なリソース
HTTP 経由でイベントの status.address.url フィールドに定義されるアドレスに配信されるイベントを受信し、確認することができます。Kubernetes Service リソースはアドレス指定可能なインターフェースにも対応します。
呼び出し可能なリソース
HTTP 経由で配信されるイベントを受信し、これを変換できます。HTTP 応答ペイロードで 0 または 1 の新規イベントを返します。返されるイベントは、外部イベントソースからのイベントが処理されるのと同じ方法で処理できます。

以下を使用して、イベントをイベントソースから複数のイベントシンクに伝播できます。

6.2. イベントシンク

シンクは、他の Knative Eventing リソースから受信イベントを受信できるアドレス可能なリソース (CR) です。Knative サービス、チャネル、およびブローカーはすべてシンクのサンプルです。

ヒント

kn のカスタマイズ により、どの CR が kn CLI コマンドの --sink フラグと併用できるかを設定できます。

6.2.1. Knative CLI --sink フラグ

Knative (kn) CLI を使用して event-producing カスタムリソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

--sink フラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

6.2.2. Developer パースペクティブを使用してイベントソースをシンクに接続します。

シンクに接続できる OpenShift Container Platform で複数のイベントソースタイプを作成できます。

前提条件

Developer パースペクティブを使用してイベントソースをシンクに接続するには、以下を確認します。

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • シンクを作成している。
  • Web コンソールにログインしており、Developer パースペクティブを使用している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. +AddEvent Sources に移動して任意のタイプのイベントソースを作成し、作成するイベントソースを選択します。
  2. Event Sources フォームビューの Sink セクションで、Resource を選択します。次に、ドロップダウンを使用してシンクを選択します。
  3. Create をクリックします。

検証

Topology ページを表示して、イベントソースが作成され、シンクに接続されていることを確認できます。

  1. Developer パースペクティブで、Topology に移動します。
  2. イベントソースを表示し、接続されたシンクをクリックし、サイドパネルでシンクの詳細を表示します。

6.2.3. トリガーのシンクへの接続

トリガーをシンクに接続して、シンクへの送信前にブローカーからのイベントがフィルターされるようにします。トリガーに接続されているシンクは、Trigger リソース仕様で subscriber として設定されます。

Kafka シンクに接続されているトリガーの例

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: <trigger_name> 1
spec:
...
  subscriber:
    ref:
      apiVersion: eventing.knative.dev/v1alpha1
      kind: KafkaSink
      name: <kafka_sink_name> 2

1
シンクに接続されているトリガーの名前。
2
KafkaSink オブジェクトの名前。

6.3. ブローカー

ブローカーは トリガー と組み合わせて、イベントをイベントソースからイベントシンクに配信できます。

Broker event delivery overview

イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。

イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。

6.3.1. ブローカーの作成

OpenShift Serverless は、kn CLI を使用して作成できる default Knative ブローカーを提供します。また、eventing.knative.dev/injection: enabled アノテーションに追加するか、または eventing.knative.dev/injection=enabled ラベルを namespace に追加して、 default ブローカーを作成することもできます。

6.3.1.1. Knative CLI を使用したブローカーの作成

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

  • default ブローカーを作成します。

    $ kn broker create default

検証

  1. kn コマンドを使用して、既存のブローカーを一覧表示します。

    $ kn broker list

    出力例

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

  2. オプション: OpenShift Container Platform Web コンソールを使用している場合、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。

    View the broker in the web console Topology view

6.3.1.2. トリガーのアノテーションによるブローカーの作成

eventing.knative.dev/injection: enabled アノテーションを Trigger オブジェクトに追加してブローカーを作成できます。

重要

knative-eventing-injection: enabled アノテーションを使用してブローカーを作成する場合、クラスター管理者のパーミッションなしにこのブローカーを削除することはできません。クラスター管理者が最初にこのアノテーションを削除せずにブローカーを削除する場合、ブローカーは削除後に再び作成されます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • oc CLI がインストールされている。

手順

  1. Trigger オブジェクトを、eventing.knative.dev/injection: enabled アノテーションを付けて YAML ファイルとして作成します。

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      annotations:
        eventing.knative.dev/injection: enabled
      name: <trigger_name>
    spec:
      broker: default
      subscriber: 1
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: <service_name>
    1
    トリガーがイベントを送信するイベントシンクまたは サブスクライバー の詳細を指定します。
  2. Trigger YAML ファイルを適用します。

    $ oc apply -f <filename>

検証

oc CLI を使用してブローカーが正常に作成されていることを確認するか、または Web コンソールの Topology ビューでこれを確認できます。

  1. 以下の oc コマンドを入力してブローカーを取得します。

    $ oc -n <namespace> get broker default

    出力例

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. Web コンソールで Topology ビューに移動し、ブローカーが存在することを確認します。

    View the broker in the web console Topology view

6.3.1.3. namespace へのラベル付けによるブローカーの作成

所有しているか、または書き込みパーミッションのある namespace にラベルを付けて default ブローカーを自動的に作成できます。

注記

この方法を使用して作成されたブローカーは、ラベルを削除すると削除されません。これらは手動で削除する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。

手順

  • eventing.knative.dev/injection=enabled で namespace にラベルを付ける。

    $ oc label namespace <namespace> eventing.knative.dev/injection=enabled

検証

oc CLI を使用してブローカーが正常に作成されていることを確認するか、または Web コンソールの Topology ビューでこれを確認できます。

  1. oc コマンドを使用してブローカーを取得します。

    $ oc -n <namespace> get broker <broker_name>

    コマンドの例

    $ oc -n default get broker default

    出力例

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. Web コンソールで Topology ビューに移動し、ブローカーが存在することを確認します。

    View the broker in the web console Topology view

6.3.1.4. 挿入 (injection) によって作成されたブローカーの削除

namespace ラベルまたはトリガーアノテーションを使用して、挿入 (injection) によって作成されたブローカーは、開発者がラベルまたはアノテーションを削除した場合に永続的に削除されません。これらのブローカーは手動で削除する必要があります。

手順

  1. eventing.knative.dev/injection=enabled ラベルを namespace から削除します。

    $ oc label namespace <namespace> eventing.knative.dev/injection-

    アノテーションを削除すると、Knative では削除後にブローカーを再作成できなくなります。

  2. 選択された namespace からブローカーを削除します。

    $ oc -n <namespace> delete broker <broker_name>

検証

  • oc コマンドを使用してブローカーを取得します。

    $ oc -n <namespace> get broker <broker_name>

    コマンドの例

    $ oc -n default get broker default

    出力例

    No resources found.
    Error from server (NotFound): brokers.eventing.knative.dev "default" not found

6.3.2. ブローカーの管理

kn CLI は、ブローカーの一覧表示、説明、更新、および削除に使用できるコマンドを提供します。

6.3.2.1. Knative CLI を使用した既存ブローカーの一覧表示

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

  • 既存ブローカーの一覧を表示します。

    $ kn broker list

    出力例

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

6.3.2.2. Knative CLI を使用した既存ブローカーの記述

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

  • 既存ブローカーを記述します。

    $ kn broker describe <broker_name>

    デフォルトブローカーを使用したコマンドの例

    $ kn broker describe default

    出力例

    Name:         default
    Namespace:    default
    Annotations:  eventing.knative.dev/broker.class=MTChannelBasedBroker, eventing.knative.dev/creato ...
    Age:          22s
    
    Address:
      URL:    http://broker-ingress.knative-eventing.svc.cluster.local/default/default
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                  22s
      ++ Addressable            22s
      ++ FilterReady            22s
      ++ IngressReady           22s
      ++ TriggerChannelReady    22s

6.4. トリガーの使用によるブローカーからのイベントのフィルター

トリガーを使用すると、イベントシンクに配信するためにブローカーからイベントをフィルターできます。

6.4.1. 前提条件

  • Knative Eventing および kn CLI がインストールされている。
  • 利用可能なブローカーにアクセスできる。
  • Knative サービスなどの利用可能なイベントコンシューマーにアクセスできる。

6.4.2. Developer パースペクティブを使用したトリガーの作成

ブローカーの作成後は、Web コンソールの Developer パースペクティブでトリガーを作成できます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • Developer パースペクティブを使用している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • トリガーに接続するために、ブローカーおよび Knative サービスまたは他のイベントシンクを作成している。

手順

  1. Developer パースペクティブで、Topology ページに移動します。
  2. トリガーを作成するブローカーにカーソルを合わせ、矢印をドラッグします。Add Trigger オプションが表示されます。

    Create a trigger for the broker
  3. Add Trigger を クリックします。
  4. ドロップダウンリストから、シンクを Subscriber として選択します。
  5. Add をクリックします。

検証

  • サブスクリプションの作成後に、これを Topology ビューでブローカーをサービスに接続する行として表示できます。

    Trigger in the Topology view

6.4.3. Developer パースペクティブを使用したトリガーの削除

Web コンソールの Developer パースペクティブでトリガーを削除できます。

前提条件

  • Developer パースペクティブを使用してトリガーを削除するには、Web コンソールにログインしている必要があります。

手順

  1. Developer パースペクティブで、Topology ページに移動します。
  2. 削除するトリガーをクリックします。
  3. Actions コンテキストメニューで、Delete Trigger を選択します。

    Delete a trigger

6.4.4. Knative CLI を使用したトリガーの作成

kn trigger create コマンドを使用してトリガーを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

  • トリガーを作成します。

    $ kn trigger create <trigger_name> --broker <broker_name> --filter <key=value> --sink <sink_name>

    または、トリガーを作成し、ブローカー挿入を使用して default ブローカーを同時に作成できます。

    $ kn trigger create <trigger_name> --inject-broker --filter <key=value> --sink <sink_name>

    デフォルトで、トリガーはブローカーに送信されたすべてのイベントを、そのブローカーにサブスクライブされるシンクに転送します。トリガーの --filter 属性を使用すると、ブローカーからイベントをフィルターできるため、サブスクライバーは定義された基準に基づくイベントのサブセットのみを受け取ることができます。

6.4.5. Knative CLI の使用によるトリガーの一覧表示

kn trigger list コマンドは利用可能なトリガーの一覧を出力します。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

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

    $ kn trigger list

    出力例

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

  2. オプション: JSON 形式でトリガーの一覧を出力します。

    $ kn trigger list -o json

6.4.6. Knative CLI を使用したトリガーの記述

kn trigger describe コマンドを使用して、トリガーについての情報を出力できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

  • コマンドを入力します。

    $ kn trigger describe <trigger_name>

    出力例

    Name:         ping
    Namespace:    default
    Labels:       eventing.knative.dev/broker=default
    Annotations:  eventing.knative.dev/creator=kube:admin, eventing.knative.dev/lastModifier=kube:admin
    Age:          2m
    Broker:       default
    Filter:
      type:       dev.knative.event
    
    Sink:
      Name:       edisplay
      Namespace:  default
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE                  AGE REASON
      ++ Ready                  2m
      ++ BrokerReady            2m
      ++ DependencyReady        2m
      ++ Subscribed             2m
      ++ SubscriberResolved     2m

6.4.7. Knative CLI を使用したトリガーでのイベントのフィルター

以下のトリガーの例では、type: dev.knative.samples.helloworld 属性のあるイベントのみがイベントシンクに到達します。

$ kn trigger create <trigger_name> --broker <broker_name> --filter type=dev.knative.samples.helloworld --sink ksvc:<service_name>

複数の属性を使用してイベントをフィルターすることもできます。以下の例は、type、source、および extension 属性を使用してイベントをフィルターする方法を示しています。

$ kn trigger create <trigger_name> --broker <broker_name> --sink ksvc:<service_name> \
--filter type=dev.knative.samples.helloworld \
--filter source=dev.knative.samples/helloworldsource \
--filter myextension=my-extension-value

6.4.8. Knative CLI を使用したトリガーの更新

特定のフラグを指定して kn trigger update コマンドを使用して、トリガーの属性を更新できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

  • トリガーを更新します。

    $ kn trigger update <trigger_name> --filter <key=value> --sink <sink_name> [flags]
    • トリガーを、受信イベントに一致するイベント属性をフィルターするように更新できます。たとえば、type 属性を使用します。

      $ kn trigger update <trigger_name> --filter type=knative.dev.event
    • トリガーからフィルター属性を削除できます。たとえば、キー type を使用してフィルター属性を削除できます。

      $ kn trigger update <trigger_name> --filter type-
    • --sink パラメーターを使用して、トリガーのイベントシンクを変更できます。

      $ kn trigger update <trigger_name> --sink ksvc:my-event-sink

6.4.9. Knative CLI を使用したトリガーの削除

kn trigger delete コマンドを使用してトリガーを削除できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。

手順

  • トリガーを削除します。

    $ kn trigger delete <trigger_name>

検証

  1. 既存のトリガーを一覧表示します。

    $ kn trigger list
  2. トリガーが存在しないことを確認します。

    出力例

    No triggers found.

6.5. イベント配信

サブスクリプションでイベントが配信されない場合に適用される Knative Eventing のイベント配信パラメーターを設定できます。イベント配信パラメーターは、サブスクリプションごとに個別に設定されます。

6.5.1. Knative Eventing チャネルのイベント配信動作

Knative Eventing チャネルタイプのイベント配信に使用される動作パターンはそれぞれ異なります。開発者は、サブスクリプション設定でイベント配信パラメーターを設定して、チャネルからイベントシンクに配信できないイベントが再試行されるようにできます。また、最終的に配信されないイベントを保存できるシンクを提供する必要がある場合は、サブスクリプションの dead letter sink も設定する必要があります。これを設定しないと、配信されないイベントはドロップされます。

6.5.1.1. Knative Kafka チャネルのイベント配信動作

イベントが Kafka チャネルまたはブローカーレシーバーに正常に配信される場合、受信側は 202 ステータスコードで応答します。つまり、このイベントは Kafka トピック内に安全に保存され、失われることはありません。受信側がその他のステータスコードを返す場合は、イベントは安全に保存されず、ユーザーがこの問題を解決するために手順を実行する必要があります。

6.5.1.2. 配信失敗ステータスコード

チャネルまたはブローカーの受信側は、イベントが配信に失敗した場合に以下のステータスコードで応答する場合があります。

500
これは一般的なステータスコードで、イベントが正常に配信されなかったことを意味します。
404
このステータスコードは、イベントが配信されるチャネルまたはブローカーが存在しないか、または Host ヘッダーが正しくないことを意味します。
400
このステータスコードは、受信側に送信されるイベントが無効であることを意味します。

6.5.2. 設定可能なパラメーター

以下のパラメーターはイベント配信用に設定できます。

dead letter sink
deadLetterSink 配信パラメーターを設定して、イベントが配信に失敗した場合にこれを指定されたイベントシンクに送信することができます。
retries
retry 配信パラメーターを整数値で設定することで、イベントが dead letter sink に送信される前に配信を再試行する必要のある最小回数を設定できます。
back off delay
backoffDelay 配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelay パラメーターの期間は ISO 8601 形式を使用して指定されます。
back off policy
backoffPolicy 配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーは linear または exponential のいずれかとして指定できます。linear バックオフポリシーを使用する場合、バックオフの遅延は再試行間に指定される期間になります。exponential バックオフポリシーを使用する場合、バックオフ遅延は backoffDelay*2^<numberOfRetries> と等しくなります。

6.5.3. サブスクリプションを使用したイベント配信失敗パラメーターの設定

開発者は、Subscription オブジェクトの delivery 設定を変更して、個別のサブスクリプションのイベント配信パラメーターを設定できます。

サブスクリプション YAML の例

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: <subscription_name>
  namespace: <subscription_namespace>
spec:
  delivery:
    deadLetterSink: 1
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: <sink_name>
    backoffDelay: <duration> 2
    backoffPolicy: <policy_type> 3
    retry: <integer> 4

1
dead letter sink の使用を有効にするための設定内容これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。

これが設定されると、配信できないイベントが dead letter sink の宛先に送信されます。宛先は Knative サービスまたは URI にすることができます。

2
backoffDelay 配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelay パラメーターの期間は ISO 8601 形式を使用して指定されます。たとえば、PT1S は 1 秒の遅延を指定します。
3
backoffPolicy 配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーは linear または exponential のいずれかとして指定できます。linear バックオフポリシーを使用する場合、バックオフの遅延は再試行間に指定される期間になります。exponential バックオフポリシーを使用する場合、バックオフ遅延は backoffDelay*2^<numberOfRetries> と等しくなります。
4
イベントが dead letter sink に送信される前にイベント配信を再試行する回数。

6.5.4. 関連情報

6.6. Knative Kafka

OpenShift Serverless で KafkaChannel チャネルタイプおよび KafkaSource イベントソースを使用できます。これを実行するには、Knative Kafka コンポーネントをインストールし、OpenShift Serverless とサポートされる Red Hat AMQ Streams クラスター間の統合を設定する必要があります。

注記

現時点で、Knative Kafka は IBM Z および IBM Power Systems ではサポートされていません。

OpenShift Serverless Operator は、 KnativeKafka カスタムリソースを作成するために使用できる Knative Kafka API を提供します。

KnativeKafka カスタムリソースの例

apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
    name: knative-kafka
    namespace: knative-eventing
spec:
    channel:
        enabled: true 1
        bootstrapServers: <bootstrap_server> 2
    source:
        enabled: true 3

1
開発者はクラスターで KafkaChannel チャネルを使用できます。
2
AMQ Streams クラスターからのブートストラップサーバーのカンマ区切りの一覧。
3
開発者はクラスターで KafkaSource イベントソースタイプを使用できます。

6.6.1. Web コンソールを使用した Knative Kafka コンポーネントのインストール

クラスター管理者は、Knative Kafka OpenShift Serverless Operator API で提供される KnativeKafka カスタムリソース定義をインスタンス化し、OpenShift Serverless デプロイメントで Knative Kafka 機能の使用を有効にすることができます。

前提条件

  • Knative Eventing を含む OpenShift Serverless が OpenShift Container Platform クラスターにインストールされている。
  • Red Hat AMQ Streams クラスターにアクセスできる。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • Web コンソールにログインしている。

手順

  1. Administrator パースペクティブで、OperatorsInstalled Operators に移動します。
  2. ページ上部の Project ドロップダウンメニューが Project: knative-eventing に設定されていることを確認します。
  3. OpenShift Serverless Operator の Provided APIs の一覧で Knative Kafka ボックスを見つけ、Create Instance をクリックします。
  4. Create Knative Kafka ページで KnativeKafka オブジェクトを設定します。

    重要

    クラスターで Kafka チャネルまたは Kafka ソースを使用するには、使用するオプションの Enable スイッチを true に切り替える必要があります。これらのスイッチは、デフォルトで false に設定されます。さらに、Kafka チャネルを使用するには、Boostrap Server を指定する必要があります。

    1. KnativeKafka オブジェクトの作成を完全に制御する必要がない単純な設定に、このフォームの使用が推奨されます。
    2. KnativeKafka オブジェクトの作成を完全に制御する必要のあるより複雑な設定には、YAML の編集が推奨されます。YAML にアクセスするには、Create Knative Kafka ページの右上にある Edit YAML リンクをクリックします。
  5. Kafka のオプションの設定が完了したら、Create をクリックします。Knative Kafka タブに自動的にダイレクトされます。ここで、knative-kafka はリソースの一覧にあります。

検証

  1. Knative Kafka タブで knative-kafka リソースをクリックします。Knative Kafka Overview ページに自動的にダイレクトされます。
  2. リソースの Conditions (状態) の一覧を表示し、それらのステータスが True であることを確認します。

    Kafka Knative Overview page showing Conditions

    状態のステータスが Unknown または False である場合は、ページを更新するためにしばらく待機します。

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

    $ oc get pods -n knative-eventing

    出力例

    NAME                                            READY   STATUS    RESTARTS   AGE
    kafka-ch-controller-85f879d577-xcbjh            1/1     Running   0          44s
    kafka-ch-dispatcher-55d76d7db8-ggqjl            1/1     Running   0          44s
    kafka-controller-manager-bc994c465-pt7qd        1/1     Running   0          40s
    kafka-webhook-54646f474f-wr7bb                  1/1     Running   0          42s

6.6.4. Kafka の認証の設定

実稼働環境では、Kafka クラスターのセキュリティーは、TLS または SASL 認証を使用して保護されます。ここでは、TLS または SASL を使用して、保護された Red Hat AMQ Streams (Kafka) クラスターに対して機能するように Kafka チャネルを設定する方法を説明します。

注記

SASL の有効化を選択する場合、Red Hat では TLS も有効にすることを推奨します。

6.6.4.1. TLS 認証の設定

前提条件

  • Kafka クラスター CA 証明書 (.pem ファイル)
  • Kafka クラスタークライアント証明書およびキー (.pem ファイル)

手順

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

    $ kubectl create secret -n <namespace> generic <kafka_auth_secret> \
      --from-file=ca.crt=caroot.pem \
      --from-file=user.crt=certificate.pem \
      --from-file=user.key=key.pem
    重要

    キー名の ca.crtuser.crt、および user.key を使用します。これらの値は変更しないでください。

  2. KnativeKafka カスタムリソースの編集を開始します。

    $ oc edit knativekafka
  3. シークレットおよびシークレットの namespace を参照します。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: <kafka_auth_secret>
        authSecretNamespace: <kafka_auth_secret_namespace>
        bootstrapServers: <bootstrap_server>
        enabled: true
      source:
        enabled: true
    注記

    ブートストラップサーバーで一致するポートを指定するようにしてください。

    以下は例になります。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: tls-user
        authSecretNamespace: kafka
        bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9094
        enabled: true
      source:
        enabled: true

6.6.4.2. SASL 認証の設定

前提条件

  • Kafka クラスターのユーザー名およびパスワード。
  • 使用する SASL メカニズムを選択します (例: PLAINSCRAM-SHA-256、または SCRAM-SHA-512)。
  • TLS が有効にされている場合、Kafka クラスターの ca.crt 証明書ファイルも必要になります。
注記

Red Hat は、SASL に加えて TLS を有効にすることを推奨します。

手順

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

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

    キー名 ca.crtpassword、および saslType を使用します。これらの値は変更しないでください。

  2. KnativeKafka カスタムリソースの編集を開始します。

    $ oc edit knativekafka
  3. シークレットおよびシークレットの namespace を参照します。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: <kafka_auth_secret>
        authSecretNamespace: <kafka_auth_secret_namespace>
        bootstrapServers: <bootstrap_server>
        enabled: true
      source:
        enabled: true
    注記

    ブートストラップサーバーで一致するポートを指定するようにしてください。

    以下は例になります。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: scram-user
        authSecretNamespace: kafka
        bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9093
        enabled: true
      source:
        enabled: true

6.6.4.3. パブリック CA 証明書を使用した SASL 認証の設定

パブリック CA 証明書で SASL を使用する場合は、シークレットの作成時に ca.crt 引数ではなく tls.enabled=true フラグを使用する必要があります。以下は例になります。

$ oc create secret --namespace <namespace> generic <kafka_auth_secret> \
  --from-literal=tls.enabled=true \
  --from-literal=password="SecretPassword" \
  --from-literal=saslType="SCRAM-SHA-512" \
  --from-literal=user="my-sasl-user"

第7章 イベントソース

7.1. イベントソースについて

Knative イベントソース には、クラウドイベントの生成またはインポート、これらのイベントの別のエンドポイントへのリレー (sink とも呼ばれる) を行う Kubernetes オブジェクトを指定できます。イベントに対応する分散システムを開発するには、イベントのソースが重要になります。

OpenShift Container Platform Web コンソール、kn CLI を使用するか、または YAML ファイルを適用して Developer パースペクティブで Knative イベントソースを作成したり、管理したりできます。

現時点で、OpenShift Serverless は以下のイベントソースタイプをサポートします。

API サーバーソース
Kubernetes API サーバーイベントを Knative に送ります。API サーバーソースは、Kubernetes リソースが作成、更新、または削除されるたびに新規イベントを実行します。
Ping ソース
指定された cron スケジュールに、固定ペイロードを使用してイベントを生成します。
シンクバインディング
DeploymentJobStatefulSet オブジェクトなどのコア Kubernetes リソースオブジェクトをシンクに接続します。
コンテナーソース
クラウドイベントを生成して、シンクに送信するコンテナーイメージを起動します。コンテナーソースを使用して、Knative で独自のカスタムイベントソースをサポートすることもできます。
Kafka ソース
Kafka クラスターをイベントソースとしてシンクに接続します。

7.2. イベントソースおよびイベントソースタイプの一覧表示

OpenShift Container Platform Web コンソールの kn CLI または Developer パースペクティブを使用し、利用可能なイベントソースまたはイベントソースタイプを一覧表示し、管理できます。

現時点で、OpenShift Serverless は以下のイベントソースタイプをサポートします。

API サーバーソース
シンクを Kubernetes API サーバーに接続します。
Ping ソース
一定のペイロードを使用して ping イベントを定期的に送信します。これはタイマーとして使用できます。
シンクバインディング
DeploymentJobStatefulSet オブジェクトなどのコア Kubernetes リソースオブジェクトをシンクに接続します。
コンテナーソース
イメージを使用してカスタムイベントソースを作成します。
Knative Kafka ソース
Kafka クラスターをイベントソースとしてシンクに接続します。

7.2.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示

手順

  1. ターミナルに利用可能なイベントソースタイプを一覧表示します。

    $ kn source list-types

    出力例

    TYPE              NAME                                            DESCRIPTION
    ApiServerSource   apiserversources.sources.knative.dev            Watch and send Kubernetes API events to a sink
    PingSource        pingsources.sources.knative.dev                 Periodically send ping events to a sink
    SinkBinding       sinkbindings.sources.knative.dev                Binding for connecting a PodSpecable to a sink

  2. オプション: 利用可能なイベントソースタイプを YAML 形式で一覧表示することもできます。

    $ kn source list-types -o yaml

7.2.2. Developer パースペクティブ内での利用可能なイベントソースタイプの表示

Web コンソールを使用して、利用可能なイベントソースタイプを表示できます。

注記

Operator を OpenShift Container Platform にインストールすることで、クラスター管理者は追加のイベントソースタイプを追加できます。

手順

  1. Developer パースペクティブにアクセスします。
  2. +Add をクリックします。
  3. Event source をクリックします。

7.2.3. Knative CLI の使用による利用可能なイベントリソースの一覧表示

  • 利用可能なイベントソースを一覧表示します。

    $ kn source list

    出力例

    NAME   TYPE              RESOURCE                               SINK         READY
    a1     ApiServerSource   apiserversources.sources.knative.dev   ksvc:eshow2   True
    b1     SinkBinding       sinkbindings.sources.knative.dev       ksvc:eshow3   False
    p1     PingSource        pingsources.sources.knative.dev        ksvc:eshow1   True

7.2.3.1. 特定タイプのイベントソースのみの一覧表示

--type フラグを使用して、特定タイプのイベントソースのみを一覧表示できます。

  • 利用可能な ping ソースを一覧表示します。

    $ kn source list --type PingSource

    出力例

    NAME   TYPE              RESOURCE                               SINK         READY
    p1     PingSource        pingsources.sources.knative.dev        ksvc:eshow1   True

7.3. API サーバーソースの使用

API サーバーソースは、Knative サービスなどのイベントシンクを Kubernetes API サーバーに接続するために使用できるイベントソースです。API サーバーソースは Kubernetes イベントを監視し、それらを Knative Eventing ブローカーに転送します。

7.3.1. 前提条件

  • Knative Serving および Eventing を含む OpenShift Serverless を OpenShift Container Platform クラスターにインストールしている必要があります。クラスター管理者がこれをインストールできます。
  • イベントソースには、イベント シンク として使用するサービスが必要です。シンクは、イベントがイベントソースから送信されるサービスまたはアプリケーションです。
  • イベントソースのサービスアカウント、ロールおよびロールバインディングを作成または更新する必要があります。
注記

以下の手順の一部では、YAML ファイルの作成が必要になります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

7.3.2. イベントソースのサービスアカウント、ロールおよびロールバインディングの作成

手順

  1. イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。

    注記

    既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。

    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>

7.3.3. Developer パースペクティブを使用した API サーバーソースイベントソースの作成

手順

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

    注記

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

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

検証

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

    ApiServerSource Topology view
注記

URI シンクが使用される場合、URI sinkEdit URI を右クリックして URI を変更します。

7.3.4. Developer パースペクティブを使用した API サーバーソースの削除

手順

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

    Delete the ApiServerSource

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

以下のセクションでは、kn コマンドを使用して API サーバーソースを作成するために必要な手順を説明します。

前提条件

  • OpenShift Serverless、Knative Serving および Eventing コンポーネント、および kn CLI がインストールされている。

手順

  1. ブローカーをシンクとして使用する API サーバーソースを作成します。

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
  2. API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。

    $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  3. default ブローカーからサービスにイベントをフィルターするトリガーを作成します。

    $ kn trigger create <trigger_name> --sink ksvc:<service_name>
  4. デフォルト namespace で Pod を起動してイベントを作成します。

    $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  5. 以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ kn source apiserver describe <source_name>

    出力例

    Name:                mysource
    Namespace:           default
    Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
    Age:                 3m
    ServiceAccountName:  events-sa
    Mode:                Resource
    Sink:
      Name:       default
      Namespace:  default
      Kind:       Broker (eventing.knative.dev/v1)
    Resources:
      Kind:        event (v1)
      Controller:  false
    Conditions:
      OK TYPE                     AGE REASON
      ++ Ready                     3m
      ++ Deployed                  3m
      ++ SinkProvided              3m
      ++ SufficientPermissions     3m
      ++ EventTypesProvided        3m

検証

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

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

7.3.5.1. Knative CLI --sink フラグ

Knative (kn) CLI を使用して event-producing カスタムリソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

--sink フラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

7.3.6. Knative CLI を使用した API サーバーソースの削除

本セクションでは、kn コマンドおよび oc コマンドを使用して API サーバーソース、トリガー、サービス、サービスアカウント、クラスターロール、およびクラスターロールバインディングを削除するために使用される手順について説明します。

前提条件

  • kn CLI がインストールされていること。

手順

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

    $ kn trigger delete <trigger_name>
  2. イベントソースを削除します。

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

    $ oc delete -f authentication.yaml

7.3.7. YAML 方法での API サーバーソースの使用

以下では、YAML ファイルを使用して API サーバーソースを作成するために必要な手順を説明します。

前提条件

  • Knative Serving および Eventing のインストールが必要です。
  • default ブローカーは、API サーバーソース YAML ファイルで定義されるものと同じ namespace に作成している必要があります。

手順

  1. API サーバーソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。

    注記

    既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。

    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 に変更します。
  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

検証

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

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

7.3.8. API サーバーソースの削除

本セクションでは、YAML ファイルを削除して、API サーバーソース、トリガー、サービスアカウント、クラスターロール、およびクラスターロールバインディングを削除する方法について説明します。

手順

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

    $ oc delete -f trigger.yaml
  2. イベントソースを削除します。

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

    $ oc delete -f authentication.yaml

7.4. ping ソースの使用

ping ソースは、一定のペイロードを使用して ping イベントをイベントコンシューマーに定期的に送信するために使用されます。

ping ソースを使用すると、タイマーと同様にイベントの送信をスケジュールできます。

ping ソース YAML の例

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

1
CRON 式を使用して指定されるイベントのスケジュール。
2
JSON でエンコードされたデータ文字列として表現されるイベントメッセージの本体。
3
これらはイベントコンシューマーの詳細です。この例では、event-display という名前の Knative サービスを使用しています。

7.4.1. Developer パースペクティブを使用した ping ソースの作成

OpenShift Container Platform Web コンソールから基本的な ping ソースを作成し、検証できます。

前提条件

Developer パースペクティブを使用して ping ソースを作成するには、以下を確認してください。

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • Developer パースペクティブを使用している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

    1. Developer パースペクティブで、+AddYAML に移動します。
    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 パースペクティブで、+AddEvent 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 をクリックします。

検証

Topology ページを表示して、ping ソースが作成され、シンクに接続されていることを確認できます。

  1. Developer パースペクティブで、Topology に移動します。
  2. ping ソースおよびシンクを表示します。

    View the ping source and service in the Topology view

7.4.2. Knative CLI を使用した ping ソースの作成

以下の手順では、kn CLI を使用して基本的な ping ソースを作成する方法を説明します。

前提条件

  • Knative Serving および Eventing がインストールされている。
  • kn CLI がインストールされている。

手順

  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

検証

シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。

デフォルトで、Knative サービスは、トラフィックが 60 秒以内に受信されない場合に Pod を終了します。本書の例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する ping ソースを作成します。

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

7.4.2.1. Knative CLI --sink フラグ

Knative (kn) CLI を使用して event-producing カスタムリソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

--sink フラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

7.4.3. Knative CLI を使用した ping ソースの削除

以下の手順では、kn CLI を使用して ping ソースを削除する方法を説明します。

  • ping ソースを削除します。

    $ kn delete pingsources.sources.knative.dev <ping_source_name>

7.4.4. YAML での ping ソースの使用

以下のセクションでは、YAML ファイルを使用して基本的な ping ソースを作成する方法を説明します。

前提条件

  • Knative Serving および Eventing がインストールされている。
注記

以下の手順では、YAML ファイルを作成する必要があります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

手順

  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. サービスを作成します。

      $ oc apply --filename service.yaml
  2. 要求する必要のある ping イベントのセットごとに、ping ソースをイベントコンシューマーと同じ 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 ソースを作成します。

      $ 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

検証

シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。

デフォルトで、Knative サービスは、トラフィックが 60 秒以内に受信されない場合に Pod を終了します。本書の例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する PingSource を作成します。

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

7.4.5. YAML を使用して作成された ping ソースの削除

以下の手順では、YAML を使用して作成された ping ソースを削除する方法を説明します。

手順

  • ping ソースを削除します。

    $ oc delete -f <ping_source_yaml_filename>

    コマンドの例

    $ oc delete -f ping-source.yaml

7.5. シンクバインディングの使用

シンクバインディングは、イベントプロデューサーまたは イベントソース を Knative サービスやアプリケーションなどのイベントコンシューマーまたは イベントシンク に接続するために使用されます。

重要

開発者がシンクバインディングを使用できるようにするには、クラスター管理者は、 bindings.knative.dev/include:"true" を使用してシンクバインディングに設定される namespace にラベルを付ける必要があります。

$ oc label namespace <namespace> bindings.knative.dev/include=true

7.5.1. Developer パースペクティブを使用したシンクバインディングの作成

OpenShift Container Platform Web コンソールから基本的なシンクバインディングを作成し、検証できます。

前提条件

Developer パースペクティブを使用してシンクバインディングを作成するには、以下を確認してください。

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • Developer パースペクティブを使用している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. シンクとして使用する Knative サービスを作成します。

    1. Developer パースペクティブで、+AddYAML に移動します。
    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. イベントソースとして使用される CronJob リソースを作成し、1 分ごとにイベントを送信します。

    1. Developer パースペクティブで、+AddYAML に移動します。
    2. サンプル YAML をコピーします。

      apiVersion: batch/v1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
        # Run every minute
        schedule: "*/1 * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: true 1
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/heartbeats
                    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
      1
      bindings.knative.dev/include: true ラベルを含めるようにしてください。OpenShift Serverless のデフォルトの namespace 選択動作は包含モードを使用します。
    3. Create をクリックします。
  3. 直前の手順で作成したサービスと同じ namespace、またはイベントの送信先となる他のシンクと同じ namespace にシンクバインディングを作成します。

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

      注記

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

    4. apiVersion フィールドに batch/v1 を入力します。
    5. Kind フィールドに Job と入力します。

      注記

      CronJob の種類は OpenShift Serverless シンクバインディングで直接サポートされていないため、Kind フィールドは cron ジョブオブジェクト自体ではなく、cron ジョブで作成される Job オブジェクトをターゲットにする必要があります。

    6. Sink を選択します。これは Resource または URI のいずれかになります。この例では、直前の手順で作成された event-display サービスが Resources シンクとして使用されます。
    7. Match labels セクションで以下を実行します。

      1. Name フィールドに app と入力します。
      2. Value フィールドに heartbeat-cron と入力します。

        注記

        ラベルセレクターは、リソース名ではなくシンクバインディングで cron ジョブを使用する場合に必要になります。これは、cron ジョブで作成されたジョブには予測可能な名前がなく、名前に無作為に生成される文字列が含まれているためです。たとえば、hearthbeat-cron-1cc23f になります。

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

検証

Topology ページおよび Pod ログを表示して、シンクバインディング、シンク、および cron ジョブが正常に作成され、機能していることを確認できます。

  1. Developer パースペクティブで、Topology に移動します。
  2. シンクバインディング、シンク、およびハートビートの cron ジョブを表示します。

    View the sink binding and service in the Topology view
  3. シンクバインディングが追加されると、正常なジョブが cron ジョブによって登録されていることを確認します。つまり、シンクバインディングは cron ジョブで作成されたジョブが正常に再設定されることを意味します。
  4. event-display サービス Pod のログを参照し、ハートビート cron ジョブで生成されるイベントを表示します。

7.5.2. Knative CLI を使用したシンクバインディングの作成

以下に、kn コマンドを使用してシンクバインディングインスタンスを作成するために必要な手順を説明します。

前提条件

  • Knative Serving および Eventing がインストールされている。
  • kn CLI がインストールされている。
注記

以下の手順では、YAML ファイルを作成する必要があります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

重要

開発者がシンクバインディングを使用できるようにするには、クラスター管理者は、 bindings.knative.dev/include:"true" を使用してシンクバインディングに設定される namespace にラベルを付ける必要があります。

$ oc label namespace <namespace> bindings.knative.dev/include=true

手順

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

    $ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  2. イベントをサービスに転送するシンクバインディングインスタンスを作成します。

    $ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink ksvc:event-display
  3. CronJob カスタムリソース (CR) を作成します。

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

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
          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
      重要

      シンクバインディングを使用するには、bindings.knative.dev/include=true ラベルを Knative CR に手動で追加する必要があります。

      たとえば、このラベルを CronJob CR に追加するには、以下の行を Job CR の YAML 定義に追加します。

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
    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

検証

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

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

    $ 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": ""
      }

7.5.2.1. Knative CLI --sink フラグ

Knative (kn) CLI を使用して event-producing カスタムリソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

--sink フラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

7.5.3. YAML メソッドでのシンクバインディングの使用

以下に、YAML ファイルを使用してシンクバインディングインスタンスを作成するために必要な手順を説明します。

前提条件

  • Knative Serving および Eventing がインストールされている。
注記

以下の手順では、YAML ファイルを作成する必要があります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

重要

開発者が SinkBinding を使用できるようにするには、クラスター管理者は、bindings.knative.dev/include:"true" を使用して SinkBinding に設定される namespace にラベルを付ける必要があります。

$ oc label namespace <namespace> bindings.knative.dev/include=true

手順

  1. シンクバインディングが正しく設定されていることを確認するには、受信メッセージをダンプする 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. イベントをサービスに転送するシンクバインディングインスタンスを作成します。

    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:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
          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
      重要

      シンクバインディングを使用するには、bindings.knative.dev/include=true ラベルを Knative リソースに手動で追加する必要があります。

      たとえば、このラベルを CronJob インスタンスに追加するには、以下の行を Job リソースの YAML 定義に追加します。

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
    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

検証

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

  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": ""
      }

7.6. コンテナーソースの使用

コンテナーソースは、イベントを生成し、イベントをシンクに送信するコンテナーイメージを作成します。コンテナーソースを使用してカスタムイベントソースを作成できます。

7.6.1. コンテナーソースを使用したカスタムイベントソースの作成

コンテナーソースを使用して、カスタムイベントソースイメージのコンテナーを作成および管理できます。

コンテナーソースを使用してカスタムイベントソースを実装するには、まずイベントソースのコンテナーイメージを作成し、次にコンテナーイメージ URI を含む正しい設定を指定するコンテナーソースを作成する必要があります。

7.6.1.1. コンテナーイメージを作成するためのガイドライン

  • コンテナイメージは、どの言語を使用しても開発でき、どのツールを使用しても構築および公開できます。
  • コンテナーイメージの主なプロセスは、引数および環境変数のパラメーターを受け入れる必要があります。
  • コンテナーソースコントローラーには、K_SINK および K_CE_OVERRIDES の 2 つの環境変数が注入されます。これらの変数は、それぞれ sink および ceOverrides 仕様から解決されます。
  • イベントメッセージは、K_SINK 環境変数に指定されたシンク URI に送信されます。イベントメッセージは任意の形式にすることができますが、CloudEvent 仕様の使用が推奨されます。

7.6.1.2. コンテナーイメージの例

以下は、ハートビートコンテナーイメージの例になります。

package main

import (
	"context"
	"encoding/json"
	"flag"
	"fmt"
	"log"
	"os"
	"strconv"
	"time"

	duckv1 "knative.dev/pkg/apis/duck/v1"

	cloudevents "github.com/cloudevents/sdk-go/v2"
	"github.com/kelseyhightower/envconfig"
)

type Heartbeat struct {
	Sequence int    `json:"id"`
	Label    string `json:"label"`
}

var (
	eventSource string
	eventType   string
	sink        string
	label       string
	periodStr   string
)

func init() {
	flag.StringVar(&eventSource, "eventSource", "", "the event-source (CloudEvents)")
	flag.StringVar(&eventType, "eventType", "dev.knative.eventing.samples.heartbeat", "the event-type (CloudEvents)")
	flag.StringVar(&sink, "sink", "", "the host url to heartbeat to")
	flag.StringVar(&label, "label", "", "a special label")
	flag.StringVar(&periodStr, "period", "5", "the number of seconds between heartbeats")
}

type envConfig struct {
	// Sink URL where to send heartbeat cloud events
	Sink string `envconfig:"K_SINK"`

	// CEOverrides are the CloudEvents overrides to be applied to the outbound event.
	CEOverrides string `envconfig:"K_CE_OVERRIDES"`

	// Name of this pod.
	Name string `envconfig:"POD_NAME" required:"true"`

	// Namespace this pod exists in.
	Namespace string `envconfig:"POD_NAMESPACE" required:"true"`

	// Whether to run continuously or exit.
	OneShot bool `envconfig:"ONE_SHOT" default:"false"`
}

func main() {
	flag.Parse()

	var env envConfig
	if err := envconfig.Process("", &env); err != nil {
		log.Printf("[ERROR] Failed to process env var: %s", err)
		os.Exit(1)
	}

	if env.Sink != "" {
		sink = env.Sink
	}

	var ceOverrides *duckv1.CloudEventOverrides
	if len(env.CEOverrides) > 0 {
		overrides := duckv1.CloudEventOverrides{}
		err := json.Unmarshal([]byte(env.CEOverrides), &overrides)
		if err != nil {
			log.Printf("[ERROR] Unparseable CloudEvents overrides %s: %v", env.CEOverrides, err)
			os.Exit(1)
		}
		ceOverrides = &overrides
	}

	p, err := cloudevents.NewHTTP(cloudevents.WithTarget(sink))
	if err != nil {
		log.Fatalf("failed to create http protocol: %s", err.Error())
	}

	c, err := cloudevents.NewClient(p, cloudevents.WithUUIDs(), cloudevents.WithTimeNow())
	if err != nil {
		log.Fatalf("failed to create client: %s", err.Error())
	}

	var period time.Duration
	if p, err := strconv.Atoi(periodStr); err != nil {
		period = time.Duration(5) * time.Second
	} else {
		period = time.Duration(p) * time.Second
	}

	if eventSource == "" {
		eventSource = fmt.Sprintf("https://knative.dev/eventing-contrib/cmd/heartbeats/#%s/%s", env.Namespace, env.Name)
		log.Printf("Heartbeats Source: %s", eventSource)
	}

	if len(label) > 0 && label[0] == '"' {
		label, _ = strconv.Unquote(label)
	}
	hb := &Heartbeat{
		Sequence: 0,
		Label:    label,
	}
	ticker := time.NewTicker(period)
	for {
		hb.Sequence++

		event := cloudevents.NewEvent("1.0")
		event.SetType(eventType)
		event.SetSource(eventSource)
		event.SetExtension("the", 42)
		event.SetExtension("heart", "yes")
		event.SetExtension("beats", true)

		if ceOverrides != nil && ceOverrides.Extensions != nil {
			for n, v := range ceOverrides.Extensions {
				event.SetExtension(n, v)
			}
		}

		if err := event.SetData(cloudevents.ApplicationJSON, hb); err != nil {
			log.Printf("failed to set cloudevents data: %s", err.Error())
		}

		log.Printf("sending cloudevent to %s", sink)
		if res := c.Send(context.Background(), event); !cloudevents.IsACK(res) {
			log.Printf("failed to send cloudevent: %v", res)
		}

		if env.OneShot {
			return
		}

		// Wait for next tick
		<-ticker.C
	}
}

以下は、以前のハートビートコンテナーイメージを参照するコンテナーソースの例です。

apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: test-heartbeats
spec:
  template:
    spec:
      containers:
        # This corresponds to a heartbeats image URI that you have built and published
        - image: gcr.io/knative-releases/knative.dev/eventing/cmd/heartbeats
          name: heartbeats
          args:
            - --period=1
          env:
            - name: POD_NAME
              value: "example-pod"
            - name: POD_NAMESPACE
              value: "event-test"
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: example-service
...

7.6.2. Knative CLI を使用したコンテナーソースの作成および管理

以下の kn コマンドを使用して、コンテナーソースを作成して管理できます。

コンテナーソースを作成します。

$ kn source container create <container_source_name> --image <image_uri> --sink <sink>

コンテナーソースの削除

$ kn source container delete <container_source_name>

コンテナーソースを記述します。

$ kn source container describe <container_source_name>

既存のコンテナーソースを一覧表示

$ kn source container list

既存のコンテナーソースを YAML 形式で一覧表示

$ kn source container list -o yaml

コンテナーソースを更新します。

このコマンドにより、既存のコンテナーソースのイメージ URI が更新されます。

$ kn source container update <container_source_name> --image <image_uri>

7.6.3. Web コンソールを使用したコンテナーソースの作成

OpenShift Container Platform Web コンソールの Developer パースペクティブを使用して、コンテナーソースを作成できます。

前提条件

Developer パースペクティブを使用してコンテナーソースを作成するには、以下を確認してください。

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • Developer パースペクティブを使用している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. Developer パースペクティブで、+AddEvent Source に移動します。Event Sources ページが表示されます。
  2. Container Source を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。
  3. Form view または YAML view を使用して、Container Source 設定を構成します。

    注記

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

    1. Image フィールドに、コンテナーソースが作成したコンテナーで実行するイメージの URI を入力します。
    2. Name フィールドにイメージの名前を入力します。
    3. オプション: Arguments フィールドで、コンテナーに渡す引数を入力します。
    4. オプション: Environment variables フィールドで、コンテナーに設定する環境変数を追加します。
    5. Sink セクションで、コンテナーソースからのイベントがルーティングされるシンクを追加します。Form ビューを使用している場合は、以下のオプションから選択できます。

      1. Resource を選択して、チャネル、ブローカー、またはサービスをイベントソースのシンクとして使用します。
      2. URI を選択して、コンテナーソースからのイベントのルーティング先を指定します。
  4. コンテナーソースの設定が完了したら、Create をクリックします。

7.7. Kafka ソースの使用

Apache Kafka クラスターからイベントを読み取り、これらのイベントをシンクに渡す Knative Kafka イベントソースを作成できます。

7.7.1. 前提条件

Knative Eventing および Knative Kafka をクラスターにインストールした後に OpenShift Serverless で KafkaSource イベントソースを使用できます。

7.7.2. Web コンソールを使用した Kafka イベントソースの作成

OpenShift Container Platform Web コンソールから Kafka イベントソースを作成し、検証できます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および KnativeKafka カスタムリソースがクラスターにインストールされている。
  • Web コンソールにログインしている。
  • Developer パースペクティブを使用している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. 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 をクリックします。

検証

Topology ページを表示して、Kafka イベントソースが作成され、シンクに接続されていることを確認できます。

  1. Developer パースペクティブで、Topology に移動します。
  2. Kafka イベントソースおよびシンクを表示します。

    View the Kafka source and service in the Topology view

7.7.3. Knative CLI を使用した Kafka イベントソースの作成

ここでは、kn コマンドを使用して Kafka イベントソースを作成する方法を説明します。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、Knative Serving、および KnativeKafka カスタムリソース (CR) がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • インポートする Kafka メッセージを生成する Red Hat AMQ Streams (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!

7.7.3.1. Knative CLI --sink フラグ

Knative (kn) CLI を使用して event-producing カスタムリソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

--sink フラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

7.7.4. YAML を使用した Kafka イベントソースの作成

YAML を使用して Kafka イベントソースを作成できます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および KnativeKafka カスタムリソースがクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  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>

検証

  • 以下のコマンドを入力して、Kafka イベントソースが作成されたことを確認します。

    $ oc get pods

    出力例

    NAME                                    READY     STATUS    RESTARTS   AGE
    kafkasource-kafka-source-5ca0248f-...   1/1       Running   0          13m

7.7.5. 関連情報

第8章 チャンネル

8.1. チャネルについて

チャネルは、単一のイベント転送および永続レイヤーを定義するカスタムリソースです。

Channel workflow overview

イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。

InMemoryChannel および KafkaChannel チャネルの実装は、開発目的で OpenShift Serverless で使用できます。

以下は、InMemoryChannel タイプのチャネルの制限です。

  • イベントの永続性は利用できません。Pod がダウンすると、その Pod のイベントが失われます。
  • InMemoryChannel チャネルはイベントの順序を実装しないため、チャネルで同時に受信される 2 つのイベントはいずれの順序でもサブスクライバーに配信できます。
  • サブスクライバーがイベントを拒否する場合、再配信はデフォルトで試行されません。Subscription オブジェクトの delivery 仕様を変更することで、再配信の試行を設定できます。

8.1.1. 次のステップ

8.2. チャネルの作成および削除

開発者はサポートされている Channel オブジェクトをインスタンス化することでチャネルを作成できます。

Channel オブジェクトが作成されると、変更用の受付 Webhook はデフォルトのチャネル実装に基づいて Channel オブジェクトの spec.channelTemplate プロパティーのセットを追加します。たとえば、InMemoryChannel のデフォルト実装の場合、Channel オブジェクトは以下のようになります。

apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
  name: example-channel
  namespace: default
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel
注記

spec.channelTemplate プロパティーは作成後に変更できません。それらは、ユーザーではなくデフォルトのチャネルメカニズムで設定されるためです。

チャネルコントローラーは、その後に spec.channelTemplate 設定に基づいてサポートするチャネルインスタンスを作成します。

このメカニズムが上記の例で使用される場合、汎用バッキングチャネルおよび InMemoryChannel チャネルなど 2 つのオブジェクトが作成されます。別のデフォルトチャネルの実装を使用している場合、InMemoryChannel は実装に固有のものに置き換えられます。たとえば、Knative Kafka の場合、KafkaChannel チャネルが作成されます。

バッキングチャネルは、サブスクリプションをユーザー作成のチャネルオブジェクトにコピーし、ユーザー作成チャネルオブジェクトのステータスを、バッキングチャネルのステータスを反映するように設定します。

8.2.1. Developer パースペクティブを使用したチャネルの作成

OpenShift Container Platform Web コンソールを使用して、クラスターのデフォルト設定でチャネルを作成できます。

前提条件

Developer パースペクティブを使用してチャネルを作成するには、以下を確認してください。

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. Developer パースペクティブで、+AddChannel に移動します。
  2. Type ドロップダウンから作成する Channel オブジェクトのタイプを選択します。

    注記

    現時点で、InMemoryChannel タイプの Channel オブジェクトのみがサポートされます。

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

検証

  • Topology ページに移動して、チャネルが存在することを確認します。

    View the channel in the Topology view

8.2.2. Knative CLI を使用したチャネルの作成

kn CLI を使用して、クラスターのデフォルト設定でチャネルを作成できます。

前提条件

kn CLI を使用してチャネルを作成するには、以下を確認します。

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • チャネルを作成します。

    $ kn channel create <channel_name> --type <channel_type>

    チャネルタイプはオプションですが、指定する場合、Group:Version:Kind の形式で指定する必要があります。たとえば、InMemoryChannel オブジェクトを作成できます。

    $ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel

    出力例

    Channel 'mychannel' created in namespace 'default'.

検証

  • チャネルが存在することを確認するには、既存のチャネルを一覧表示し、出力を検査します。

    $ kn channel list

    出力例

    kn channel list
    NAME        TYPE              URL                                                     AGE   READY   REASON
    mychannel   InMemoryChannel   http://mychannel-kn-channel.default.svc.cluster.local   93s   True

8.2.3. YAML を使用したデフォルト実装チャネルの作成

クラスターのデフォルト設定で YAML を使用してチャネルを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

Channel オブジェクトを作成するには、以下を実行します。

  1. YAML ファイルを作成し、以下のサンプルコードをこれにコピーします。

    apiVersion: messaging.knative.dev/v1
    kind: Channel
    metadata:
      name: example-channel
      namespace: default
  2. YAML ファイルを適用します。

    $ oc apply -f <filename>

8.2.4. YAML を使用した Kafka チャネルの作成

YAML を使用して KafkaChannel オブジェクトを作成し、Kafka チャネルを作成できます。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka カスタムリソースは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

    apiVersion: messaging.knative.dev/v1beta1
    kind: KafkaChannel
    metadata:
      name: example-channel
      namespace: default
    spec:
      numPartitions: 3
      replicationFactor: 1
    重要

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

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

    $ oc apply -f <filename>

8.2.5. Knative CLI を使用したチャネルの削除

kn CLI を使用して、クラスターのデフォルト設定でチャネルを削除できます。

手順

  • チャネルを削除します。

    $ kn channel delete <channel_name>

8.2.6. 次のステップ

  • チャネルの作成後に、イベント配信のサブスクリプションの作成および使用については、 サブスクリプションの使用について参照してください。

8.3. サブスクリプション

イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。

Channel workflow overview

サブスクライバーがイベントを拒否する場合、再配信はデフォルトで試行されません。開発者は、Subscription オブジェクトで delivery 仕様を変更して再配信の試行を設定できます。

8.3.1. サブスクリプションの作成

開発者は、イベントシンクがチャネルにサブスクライブし、イベントを受信できるようにするサブスクリプションを作成できます。

8.3.1.1. Developer パースペクティブでのサブスクリプションの作成

前提条件

Developer パースペクティブを使用してサブスクリプションを作成するには、以下を確認してください。

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Knative サービスおよびチャネルなどのイベントシンクを作成している。

手順

  1. Developer パースペクティブで、Topology ページに移動します。
  2. 以下の方法のいずれかを使用してサブスクリプションを作成します。

    1. サブスクリプションを作成するチャネルにカーソルを合わせ、矢印をドラッグします。Add Subscription オプションが表示されます。

      Create a subscription for the channel
      1. ドロップダウンリストから、シンクをサブスクライバーとして選択します。
      2. Add をクリックします。
    2. このサービスが、チャネルと同じ namespace またはプロジェクトにある Topology ビューで利用可能な場合は、サブスクリプションを作成するチャネルをクリックし、矢印をサービスに直接ドラッグして、チャネルからそのサービスにサブスクリプションを即時に作成します。

検証

  • サブスクリプションの作成後に、これを Topology ビューでチャネルをサービスに接続する行として表示できます。

    Subscription in the Topology view

    サービスをクリックして、シンクのイベントソース、チャネル、およびサブスクリプションを表示できます。

8.3.1.2. Knative CLI を使用したサブスクリプションの作成

kn CLI を使用して、チャネルをシンクに接続するためにサブスクリプションを作成できます。

前提条件

kn CLI を使用してサブスクリプションを作成するには、以下を確認します。

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • サブスクリプションを作成し、シンクをチャネルに接続します。

    $ kn subscription create <subscription_name> \
      --channel <group:version:kind>:<channel_name> \ 1
      --sink <sink_prefix>:<sink_name> \ 2
      --sink-dead-letter <sink_prefix>:<sink_name> 3
    1
    --channel は、処理する必要のあるクラウドイベントのソースを指定します。チャネル名を指定する必要があります。Channel カスタムリソースでサポートされるデフォルトの InMemoryChannel チャネルを使用しない場合には、チャネル名に指定されたチャネルタイプの <group:version:kind> のプレフィックスを付ける必要があります。たとえば、これは Kafka 対応チャネルの messaging.knative.dev:v1beta1:KafkaChannel のようになります。
    2
    --sink は、イベントが配信されるターゲット宛先を指定します。デフォルトで、<sink_name> は、サブスクリプションと同じ namespace でこの名前の Knative サービスとして解釈されます。以下のプレフィックスのいずれかを使用して、シンクのタイプを指定できます。
    ksvc
    Knative サービス
    channel
    宛先として使用する必要のあるチャネル。ここで参照できるのは、デフォルトのチャネルタイプのみです。
    broker
    Eventing ブローカー。
    3
    オプション: --sink-dead-letter は、イベントが配信に失敗する場合にイベントを送信するシンクを指定するために使用できるオプションのフラグです。詳細は、OpenShift Serverless の Event 配信についてのドキュメントを参照してください。

    コマンドの例

    $ kn subscription create mysubscription --channel mychannel --sink ksvc:event-display

    出力例

    Subscription 'mysubscription' created in namespace 'default'.

検証

  • サブスクリプションを使用してチャネルがイベントシンクまたは サブスクライバー に接続されていることを確認するには、既存のサブスクリプションを一覧表示し、出力を検査します。

    $ kn subscription list

    出力例

    NAME            CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
    mysubscription   Channel:mychannel   ksvc:event-display                              True

8.3.1.3. YAML を使用したサブスクリプションの作成

YAML を作成して、チャネルをシンクに接続するためにサブスクリプションを作成できます。

手順

  • Subscription オブジェクトを作成します。

    • YAML ファイルを作成し、以下のサンプルコードをこれにコピーします。

      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
      サブスクライバーの設定。これは、イベントがチャネルから送信されるイベントシンクです。
    • YAML ファイルを適用します。

      $ oc apply -f <filename>

8.3.2. サブスクリプションを使用したイベント配信失敗パラメーターの設定

開発者は、Subscription オブジェクトの delivery 設定を変更して、個別のサブスクリプションのイベント配信パラメーターを設定できます。

サブスクリプション YAML の例

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: <subscription_name>
  namespace: <subscription_namespace>
spec:
  delivery:
    deadLetterSink: 1
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: <sink_name>
    backoffDelay: <duration> 2
    backoffPolicy: <policy_type> 3
    retry: <integer> 4

1
dead letter sink の使用を有効にするための設定内容これは、サブスクリプションに対してサブスクライバーに配信できないイベントに何が発生するかについて示します。

これが設定されると、配信できないイベントが dead letter sink の宛先に送信されます。宛先は Knative サービスまたは URI にすることができます。

2
backoffDelay 配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelay パラメーターの期間は ISO 8601 形式を使用して指定されます。たとえば、PT1S は 1 秒の遅延を指定します。
3
backoffPolicy 配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーは linear または exponential のいずれかとして指定できます。linear バックオフポリシーを使用する場合、バックオフの遅延は再試行間に指定される期間になります。exponential バックオフポリシーを使用する場合、バックオフ遅延は backoffDelay*2^<numberOfRetries> と等しくなります。
4
イベントが dead letter sink に送信される前にイベント配信を再試行する回数。

8.3.3. Knative CLI を使用したサブスクリプションの記述

kn CLI を使用して、ターミナルにサブスクリプションについての情報を出力できます。

前提条件

kn CLI を使用してサブスクリプションを記述するには、以下を確認します。

  • kn CLI がインストールされている。
  • クラスターにサブスクリプションを作成している。

手順

  • サブスクリプションを記述します。

    $ kn subscription describe <subscription_name>

    出力例

    Name:            my-subscription
    Namespace:       default
    Annotations:     messaging.knative.dev/creator=openshift-user, messaging.knative.dev/lastModifier=min ...
    Age:             43s
    Channel:         Channel:my-channel (messaging.knative.dev/v1)
    Subscriber:
      URI:           http://edisplay.default.example.com
    Reply:
      Name:          default
      Resource:      Broker (eventing.knative.dev/v1)
    DeadLetterSink:
      Name:          my-sink
      Resource:      Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE                  AGE REASON
      ++ Ready                 43s
      ++ AddedToChannel        43s
      ++ ChannelReady          43s
      ++ ReferencesResolved    43s

8.3.4. Knative CLI を使用したサブスクリプションの一覧表示

kn CLI を使用して、クラスターの既存のサブスクリプションを一覧表示できます。

前提条件

  • kn CLI がインストールされている。

手順

  • クラスターのサブスクリプションを一覧表示します。

    $ kn subscription list

    出力例

    NAME             CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
    mysubscription   Channel:mychannel   ksvc:event-display                              True

8.3.5. Knative CLI を使用したサブスクリプションの更新

kn CLI を使用してサブスクリプションを更新できます。

前提条件

kn CLI を使用してサブスクリプションを更新するには、以下を確認します。

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • kn CLI がインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、適切なロールおよびパーミッションでプロジェクトにアクセスできる。
  • サブスクリプションを作成している。

手順

  • サブスクリプションを更新します。

    $ kn subscription update <subscription_name> \
      --sink <sink_prefix>:<sink_name> \ 1
      --sink-dead-letter <sink_prefix>:<sink_name> 2
    1
    --sink は、イベントが配信される、更新されたターゲット宛先を指定します。以下のプレフィックスのいずれかを使用して、シンクのタイプを指定できます。
    ksvc
    Knative サービス
    channel
    宛先として使用する必要のあるチャネル。ここで参照できるのは、デフォルトのチャネルタイプのみです。
    broker
    Eventing ブローカー。
    2
    オプション: --sink-dead-letter は、イベントが配信に失敗する場合にイベントを送信するシンクを指定するために使用できるオプションのフラグです。詳細は、OpenShift Serverless の Event 配信についてのドキュメントを参照してください。

    コマンドの例

    $ kn subscription update mysubscription --sink ksvc:event-display

8.3.6. Knative CLI を使用したサブスクリプションの削除

kn CLI を使用してサブスクリプションを削除できます。

手順

  • サブスクリプションを削除します。

    $ kn subscription delete <subscription_name>

8.4. チャネルのデフォルトの設定

クラスター管理者のパーミッションがある場合は、クラスター全体または特定の namespace のいずれかでチャネルのデフォルトオプションを設定できます。これらのオプションは設定マップを使用して変更されます。

8.4.1. デフォルトチャネル実装の設定

default-ch-webhook 設定マップは、クラスターまたは 1 つ以上の namespace のデフォルトチャネルの実装を指定するために使用できます。

OpenShift Serverless Operator を使用して変更を伝播することで、default-ch-webhook 設定マップを含む、 knative-eventing namespace 設定マップへの変更を加えることができます。これを実行するには、KnativeEventing カスタムリソースを変更する必要があります。

前提条件

  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。

手順

  • KnativeEventing カスタムリソースを変更して、default-ch-webhook 設定マップの設定の詳細を追加します。

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      config: 1
        default-ch-webhook: 2
          default-ch-config: |
            clusterDefault: 3
              apiVersion: messaging.knative.dev/v1
              kind: InMemoryChannel
              spec:
                delivery:
                  backoffDelay: PT0.5S
                  backoffPolicy: exponential
                  retry: 5
            namespaceDefaults: 4
              my-namespace:
                apiVersion: messaging.knative.dev/v1beta1
                kind: KafkaChannel
                spec:
                  numPartitions: 1
                  replicationFactor: 1
    1
    spec.config で、変更した設定を追加する設定マップを指定できます。
    2
    default-ch-webhook 設定マップは、クラスターまたは 1 つ以上の namespace のデフォルトチャネルの実装を指定するために使用できます。
    3
    クラスター全体のデフォルトのチャネルタイプの設定。この例では、クラスターのデフォルトのチャネル実装は InMemoryChannel です。
    4
    namespace スコープのデフォルトのチャネルタイプの設定。この例では、my-namespace namespace のデフォルトのチャネル実装は KafkaChannel です。
    重要

    namespace 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。

第9章 関数

9.1. OpenShift Serverless Functions について

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

OpenShift Serverless Functions により、開発者は OpenShift Container Platform で Knative サービスとしてステートレスでイベント駆動型の関数を作成およびデプロイできます。

kn func CLI は Knative kn CLI のプラグインとして提供されます。OpenShift Serverless Functions は、 CNCF Buildpack API を使用してコンテナーイメージを作成します。コンテナーイメージの作成後に、kn func CLI を使用してコンテナーイメージをクラスターで Knative サービスとしてデプロイできます。

9.1.1. サポート対象のランタイム

OpenShift Serverless Functions は、以下のランタイムの基本機能を作成するために使用できるテンプレートを提供します。

9.1.2. 次のステップ

9.2. OpenShift Serverless Functions の設定

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

OpenShift Serverless で関数を開発する前に、セットアップの手順を実行する必要があります。

9.2.1. 前提条件

クラスターで OpenShift Serverless Functions の使用を有効にするには、以下の手順を実行する必要があります。

  • OpenShift Serverless がクラスターにインストールされている。
  • oc CLI がクラスターにインストールされている。
  • Knative (kn) CLI がクラスターにインストールされている。kn CLI をインストールすると、関数の作成および管理に使用できる kn func コマンドを使用できます。
  • Docker Container Engine または podman をインストールし、利用可能なイメージレジストリーにアクセスできる。
  • Quay.io をイメージレジストリーとして使用する場合は、リポジトリーがプライベートではないか確認するか、OpenShift Container Platform ドキュメント「Pod が他のセキュアなレジストリーからイメージを参照できるようにする設定」に従っていることを確認する必要があります。
  • OpenShift Container レジストリーを使用している場合には、クラスター管理者は レジストリーを公開する 必要があります。

9.2.2. Pod の使用

podman を使用している場合は、OpenShift Serverless 機能の使用を開始する前に以下のコマンドを実行する必要があります。

  1. ${XDG_RUNTIME_DIR}/podman/podman.sock で、UNIX ソケットで Docker API を提供する podman サービスを起動します。

    $ systemctl start --user podman.socket
    注記

    多くのシステムでは、このソケットは /run/user/$(id -u)/podman/podman.sock にあります。

  2. 関数のビルドに使用する環境変数を確立します。

    $ export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
  3. -v を指定して build コマンドを実行し、詳細な出力を表示します。ローカルの UNIX ソケットへの接続が表示されるはずです。

    $ kn func build -v

9.2.3. 次のステップ

9.3. 関数を使い始める

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

以下では、kn CLI を使用して OpenShift Serverless インストールで関数を作成し、管理する方法を説明します。

9.3.1. 前提条件

以下の手順を実行する前に、「OpenShift Serverless 機能の設定」の要件タスクをすべて完了している必要があります。

9.3.2. 関数の作成

kn CLI を使用して基本的なサーバーレス関数を作成できます。

パス、ランタイム、およびテンプレートは、コマンドラインでフラグとして指定するか、-c フラグを使用してターミナルでインタラクティブなエクスペリエンスを開始できます。

手順

  • 関数プロジェクトを作成します。

    $ kn func create <path> -l <runtime> -t <template>
    • サポートされるランタイムには、nodegopythonquarkus、および typescript が含まれます。
    • サポートされるテンプレートには http および events が含まれます。

      コマンドの例

      $ kn func create -l typescript -t events examplefunc

      出力例

      Project path:  /home/user/demo/examplefunc
      Function name: examplefunc
      Runtime:       typescript
      Template:      events
      Writing events to /home/user/demo/examplefunc

9.3.3. 関数のビルド

関数を実行する前に、kn func build コマンドを使用して機能プロジェクトをビルドする必要があります。build コマンドは、関数プロジェクトディレクトリーから func.yaml ファイルを読み取り、イメージ名とレジストリーを特定します。

func.yaml の例

name: example-function
namespace: default
runtime: node
image: <image_from_registry>
imageDigest: ""
trigger: http
builder: default
builderMap:
  default: quay.io/boson/faas-nodejs-builder
envs: {}

イメージ名とレジストリーが func.yaml ファイルで設定されていない場合には、kn func build コマンドの使用時に、レジストリーフラグ (-r) を指定してください。そうでない場合には、関数をビルドする時にターミナルでレジストリー値を指定するように求められます。イメージ名は、指定したレジストリーの値をもとに付けられます。

-r フラグを使用したコマンドの例

$ kn func build [-i <image> -r <registry> -p <path>]

出力例

Building function image
Function image has been built, image: quay.io/username/example-function:latest

このコマンドは、お使いのコンピューターまたは Kubernetes クラスターでローカルで実行できる OCI コンテナーイメージを作成します。

registry プロンプトの使用例

$ kn func build
A registry for function images is required (e.g. 'quay.io/boson').

Registry for function images: quay.io/username
Building function image
Function image has been built, image: quay.io/username/example-function:latest

イメージおよびレジストリーの値は、func.yaml ファイルに永続化されるため、後続の呼び出しでその値の呼び出しを再度指定する必要はありません。

9.3.4. 関数のデプロイ

kn func deploy コマンドを使用して、関数を Knative サービスとしてクラスターにデプロイできます。

ターゲット関数がすでにデプロイされている場合には、コンテナーイメージレジストリーにプッシュされている新規コンテナーイメージで更新され、Knative サービスが更新されます。

前提条件

  • デプロイする関数を初期化している。

手順

  • 関数をデプロイします。

    $ kn func deploy [-n <namespace> -p <path> -i <image> -r <registry>]

    出力例

    Function deployed at: http://func.example.com

    • namespace が指定されていない場合には、関数は現在の namespace にデプロイされます。
    • この関数は、パス が指定されない限り、現在のディレクトリーからデプロイされます。
    • Knative サービス名はプロジェクト名から派生するので、以下のコマンドでは変更できません。

9.3.5. OpenShift Container レジストリーを使用した関数のビルドとデプロイ

関数をビルドしてデプロイする場合には、作成されるコンテナーイメージはイメージレジストリーに保存されます。通常、これは Quay などのパブリックレジストリーになります。ただし、クラスター管理者が公開した場合には、統合 OpenShift Container レジストリーを使用できます。

手順

  • -r パラメーターに指定した OpenShift Container レジストリーで、kn func build コマンドまたは kn func deploy コマンドを実行します。

    build コマンドの例

    $ kn func build -r $(oc get route -n openshift-image-registry)

    deploy コマンドの例

    $ kn func deploy -r $(oc get route -n openshift-image-registry)

    テストイベントを出力して、関数が正常にデプロイされたことを確認できます。

9.3.6. デプロイされた関数へのテストイベントの出力

kn func emit CLI コマンドを使用して、ローカルにデプロイされた関数、または OpenShift Container Platform クラスターにデプロイされた関数のいずれかに CloudEvent を出力できます。このコマンドを使用して、関数が機能し、イベントを正しく受信できることをテストできます。

コマンドの例

$ kn func emit

kn func emit コマンドは、デフォルトでローカルディレクトリーで実行され、このディレクトリーが関数プロジェクトであることを前提とします。

9.4. Node.js 関数の開発

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

Node.js 関数プロジェクトを作成 したら、指定のテンプレートを変更して、関数にビジネスロジックを追加できます。

9.4.1. 前提条件

9.4.2. Node.js 関数テンプレート構造

kn CLI を使用して Node.js 関数を作成すると、プロジェクトディレクトリーは、一般的な Node. js プロジェクトと同じになります (追加の func.yaml 設定ファイルを除く)。

http および event トリガー関数のテンプレート構造はいずれも同じです。

テンプレート構造

.
├── func.yaml 1
├── index.js 2
├── package.json 3
├── README.md
└── test 4
    ├── integration.js
    └── unit.js

1
func.yaml 設定ファイルは、イメージ名とレジストリーを判断するために使用されます。
2
プロジェクトに関数を 1 つエクスポートする index.js ファイルを追加する必要があります。
3
テンプレート package.json ファイルにある依存関係に限定されるわけではありません。他の Node.js プロジェクトと同様に、別の依存関係を追加できます。

npm 依存関係の追加例

npm install --save opossum

デプロイメント用にプロジェクトをビルドすると、これらの依存関係は作成したランタイムコンテナーイメージに含まれます。

4
統合およびテストスクリプトは、関数テンプレートの一部として提供されます。

9.4.3. Node.js 関数の呼び出しについて

kn CLI を使用して関数プロジェクトを作成する場合に、CloudEvents に応答するプロジェクト、または単純な HTTP 要求に応答するプロジェクトを生成できます。Knative の CloudEvents は HTTP 経由で POST 要求として転送されるため、関数タイプはいずれも受信 HTTP イベントをリッスンして応答します。

Node.js 関数は、単純な HTTP 要求で呼び出すことができます。受信要求を受け取ると、関数は context オブジェクトで最初のパラメーターとして呼び出されます。

9.4.3.1. Node.js コンテキストオブジェクト

関数は、context オブジェクトを最初のパラメーターとして渡して呼び出されます。

コンテキストオブジェクトの例

function handle(context, data)

このオブジェクトは、HTTP 要求メソッド、要求、HTTP バージョン、要求ボディーを使用して送信されたクエリー文字列またはヘッダーなど、受信 HTTP 要求の情報を使用できるようにします。CloudEvent の受信インスタンスが含まれる受信要求はコンテキストオブジェクトにアタッチし、context.cloudevent を使用してアクセスできるようにします。

9.4.3.1.1. コンテキストオブジェクトメソッド

context オブジェクトには、データの値を受け入れ、CloudEvent を返す cloudEventResponse() メソッドが 1 つあります。

Knative システムでは、サービスとしてデプロイされた関数が CloudEvent を送信するイベントブローカーによって呼び出される場合に、ブローカーが応答を確認します。応答が CloudEvent の場合には、このイベントはブローカーにが処理します。

コンテキストオブジェクトメソッドの例

// Expects to receive a CloudEvent with customer data
function handle(context, customer) {
  // process the customer
  const processed = handle(customer);
  return context.cloudEventResponse(customer)
    .source('/handle')
    .type('fn.process.customer')
    .response();
}

9.4.3.1.2. CloudEvent data

受信要求が CloudEvent の場合は、CloudEvent に関連付けられたデータがすべてイベントから抽出され、2 番目のパラメーターとして提供されます。たとえば、以下のように data プロパティーに JSON 文字列が含まれる CloudEvent が受信された場合に、以下のようになります。

{
  "customerId": "0123456",
  "productId": "6543210"
}

呼び出されると、関数に対してcontext オブジェクト後に来る 2 番目のパラメーターは、JavaScript オブジェクトで、このオブジェクトには customerIdproductId プロパティーが含まれます。

署名の例

function handle(context, data)

この例の data パラメーターは、customerId および productId プロパティーが含まれる JavaScript オブジェクトです。

9.4.4. Node.js 関数の戻り値

この関数は有効な JavaScript タイプを返すことができます。がそれ以外は戻り値を持たせないようにすることもできます。関数に戻り値が指定されておらず、失敗を指定しないと、呼び出し元は 204 No Content 応答を受け取ります。

関数は、CloudEvent または Message オブジェクトを返してイベントを Knative Eventing システムにプッシュすることもできます。この場合に、開発者は CloudEvent メッセージング仕様の理解や実装は必要ありません。返された値からのヘッダーおよびその他の関連情報は抽出され、応答で送信されます。

function handle(context, customer) {
  // process customer and return a new CloudEvent
  return new CloudEvent({
    source: 'customer.processor',
    type: 'customer.processed'
  })
}

9.4.4.1. 返されるヘッダー

headers プロパティーを return オブジェクトに追加して応答ヘッダーを設定できます。これらのヘッダーは抽出され、呼び出し元に応答して送信されます。

応答ヘッダーの例

function handle(context, customer) {
  // process customer and return custom headers
  // the response will be '204 No content'
  return { headers: { customerid: customer.id } };
}

9.4.4.2. 返されるステータスコード

statusCode プロパティーを return オブジェクトに追加して、呼び出し元に返されるステータスコードを設定できます。

ステータスコード

function handle(context, customer) {
  // process customer
  if (customer.restricted) {
    return { statusCode: 451 }
  }
}

ステータスコードは、関数で作成およびスローされるエラーに対して設定することもできます。

エラーステータスコードの例

function handle(context, customer) {
  // process customer
  if (customer.restricted) {
    const err = new Error(‘Unavailable for legal reasons’);
    err.statusCode = 451;
    throw err;
  }
}

9.4.5. Node.js 関数のテスト

Node.js 関数は、コンピューターに対してローカルでテストできます。kn func create を使用した関数の作成時に作成される default プロジェクトには、test フォルダーがあり、一部の単純なユニットおよび統合テストが含まれます。

手順

  • テストを実行します。

    $ npm test

9.4.6. 次のステップ

  • Node.js コンテキストオブジェクトの参照ドキュメントを参照してください。
  • 関数を構築 して デプロイ します。

9.5. TypeScript 関数の開発

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

TypeScript 関数プロジェクトを作成 したら、指定のテンプレートを変更して、関数にビジネスロジックを追加できます。

9.5.1. 前提条件

9.5.2. Typescript 関数テンプレートの構造

kn CLI を使用して TypeScript 関数を作成すると、プロジェクトディレクトリーは、一般的な TypeScript プロジェクトと同じになります (追加の func.yaml 設定ファイルを除く)。

http および event トリガー関数のテンプレート構造はいずれも同じです。

テンプレート構造

.
├── func.yaml 1
├── package.json 2
├── package-lock.json
├── README.md
├── src
│   └── index.ts 3
├── test 4
│   ├── integration.ts
│   └── unit.ts
└── tsconfig.json

1
func.yaml 設定ファイルは、イメージ名とレジストリーを判断するために使用されます。
2
テンプレート package.json ファイルにある依存関係に限定されるわけではありません。他の TypeScript プロジェクトと同様に、別の依存関係を追加できます。

npm 依存関係の追加例

npm install --save opossum

デプロイメント用にプロジェクトをビルドすると、これらの依存関係は作成したランタイムコンテナーイメージに含まれます。

3
プロジェクトには、handle という名前の関数をエクスポートする src/index.js ファイルが含まれている必要があります。
4
統合およびテストスクリプトは、関数テンプレートの一部として提供されます。

9.5.3. TypeScript 関数の呼び出しについて

kn CLI を使用して関数プロジェクトを作成する場合に、CloudEvents に応答するプロジェクト、または単純な HTTP 要求に応答するプロジェクトを生成できます。Knative の CloudEvents は HTTP 経由で POST 要求として転送されるため、関数タイプはいずれも受信 HTTP イベントをリッスンして応答します。

Typescript 関数は、単純な HTTP 要求で呼び出すことができます。受信要求を受け取ると、関数は context オブジェクトで最初のパラメーターとして呼び出されます。

9.5.3.1. Typescript コンテキストオブジェクト

関数は、最初のパラメーターとして context オブジェクトで呼び出されます。

コンテキストオブジェクトの例

function handle(context:Context): string

このオブジェクトは、HTTP 要求メソッド、要求、HTTP バージョン、要求ボディーを使用して送信されたクエリー文字列またはヘッダーなど、受信 HTTP 要求の情報を使用できるようにします。CloudEvent の受信インスタンスが含まれる受信要求はコンテキストオブジェクトにアタッチし、context.cloudevent を使用してアクセスできるようにします。

9.5.3.1.1. コンテキストオブジェクトメソッド

context オブジェクトには、データの値を受け入れ、CloudEvent を返す cloudEventResponse() メソッドが 1 つあります。

Knative システムでは、サービスとしてデプロイされた関数が CloudEvent を送信するイベントブローカーによって呼び出される場合に、ブローカーが応答を確認します。応答が CloudEvent の場合には、このイベントはブローカーにが処理します。

コンテキストオブジェクトメソッドの例

// Expects to receive a CloudEvent with customer data
export function handle(context: Context, cloudevent?: CloudEvent): CloudEvent {
  // process the customer
  const customer = cloudevent.data;
  const processed = processCustomer(customer);
  return context.cloudEventResponse(customer)
    .source('/customer/process')
    .type('customer.processed')
    .response();
}

9.5.3.1.2. コンテキストタイプ

TypeScript タイプの定義ファイルは、関数で使用する以下のタイプをエクスポートします。

エクスポートタイプの定義

// Invokable is the expeted Function signature for user functions
export interface Invokable {
    (context: Context, cloudevent?: CloudEvent): any
}

// Logger can be used for structural logging to the console
export interface Logger {
  debug: (msg: any) => void,
  info:  (msg: any) => void,
  warn:  (msg: any) => void,
  error: (msg: any) => void,
  fatal: (msg: any) => void,
  trace: (msg: any) => void,
}

// Context represents the function invocation context, and provides
// access to the event itself as well as raw HTTP objects.
export interface Context {
    log: Logger;
    req: IncomingMessage;
    query?: Record<string, any>;
    body?: Record<string, any>|string;
    method: string;
    headers: IncomingHttpHeaders;
    httpVersion: string;
    httpVersionMajor: number;
    httpVersionMinor: number;
    cloudevent: CloudEvent;
    cloudEventResponse(data: string|object): CloudEventResponse;
}

// CloudEventResponse is a convenience class used to create
// CloudEvents on function returns
export interface CloudEventResponse {
    id(id: string): CloudEventResponse;
    source(source: string): CloudEventResponse;
    type(type: string): CloudEventResponse;
    version(version: string): CloudEventResponse;
    response(): CloudEvent;
}

9.5.3.1.3. CloudEvent data

受信要求が CloudEvent の場合は、CloudEvent に関連付けられたデータがすべてイベントから抽出され、2 番目のパラメーターとして提供されます。たとえば、以下のように data プロパティーに JSON 文字列が含まれる CloudEvent が受信された場合に、以下のようになります。

{
  "customerId": "0123456",
  "productId": "6543210"
}

呼び出されると、関数に対してcontext オブジェクト後に来る 2 番目のパラメーターは、JavaScript オブジェクトで、このオブジェクトには customerIdproductId プロパティーが含まれます。

署名の例

function handle(context: Context, cloudevent?: CloudEvent): CloudEvent

この例の cloudevent パラメーターは、customerId および productId プロパティーが含まれる JavaScript オブジェクトです。

9.5.4. Typescript 関数の戻り値

この関数は有効な JavaScript タイプを返すことができます。がそれ以外は戻り値を持たせないようにすることもできます。関数に戻り値が指定されておらず、失敗を指定しないと、呼び出し元は 204 No Content 応答を受け取ります。

関数は、CloudEvent または Message オブジェクトを返してイベントを Knative Eventing システムにプッシュすることもできます。この場合に、開発者は CloudEvent メッセージング仕様の理解や実装は必要ありません。返された値からのヘッダーおよびその他の関連情報は抽出され、応答で送信されます。

export const handle: Invokable = function (
  context: Context,
  cloudevent?: CloudEvent
): Message {
  // process customer and return a new CloudEvent
  const customer = cloudevent.data;
  return HTTP.binary(
    new CloudEvent({
      source: 'customer.processor',
      type: 'customer.processed'
    })
  );
};

9.5.4.1. 返されるヘッダー

headers プロパティーを return オブジェクトに追加して応答ヘッダーを設定できます。これらのヘッダーは抽出され、呼び出し元に応答して送信されます。

応答ヘッダーの例

export function handle(context: Context, cloudevent?: CloudEvent): Record<string, any> {
  // process customer and return custom headers
  const customer = cloudevent.data as Record<string, any>;
  return { headers: { 'customer-id': customer.id } };
}

9.5.4.2. 返されるステータスコード

statusCode プロパティーを return オブジェクトに追加して、呼び出し元に返されるステータスコードを設定できます。

ステータスコード

export function handle(context: Context, cloudevent?: CloudEvent): Record<string, any> {
  // process customer
  const customer = cloudevent.data as Record<string, any>;
  if (customer.restricted) {
    return {
      statusCode: 451
    }
  }
  // business logic, then
  return {
    statusCode: 240
  }
}

ステータスコードは、関数で作成およびスローされるエラーに対して設定することもできます。

エラーステータスコードの例

export function handle(context: Context, cloudevent?: CloudEvent): Record<string, string> {
  // process customer
  const customer = cloudevent.data as Record<string, any>;
  if (customer.restricted) {
    const err = new Error(‘Unavailable for legal reasons’);
    err.statusCode = 451;
    throw err;
  }
}

9.5.5. TypeScript 関数のテスト

Typescript 機能は、お使いのコンピューターでローカルでテストできます。kn func create を使用した関数の作成時に作成される default プロジェクトには、test フォルダーがあり、一部の単純なユニットおよび統合テストが含まれます。

手順

  1. テストを実行していない場合は、最初に依存関係をインストールします。

    $ npm install
  2. テストを実行します。

    $ npm test

9.5.6. 次のステップ

9.6. Golang 関数の開発

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

Golang 関数プロジェクトを作成 したら、指定のテンプレートを変更して、関数にビジネスロジックを追加できます。

9.6.1. 前提条件

9.6.2. golang 関数テンプレートの構造

kn CLI を使用して Golang 関数を作成すると、プロジェクトディレクトリーは、一般的な Golang プロジェクトと同じになります (追加の func.yaml 設定ファイルを除く)。

golang 関数にはいくつかの制限があります。唯一の要件として、プロジェクトが function モジュールで定義する必要があり、Handle() 関数をエクスポートする必要があります。

http および event トリガー関数のテンプレート構造はいずれも同じです。

テンプレート構造

fn
├── README.md
├── func.yaml 1
├── go.mod 2
├── go.sum
├── handle.go
└── handle_test.go

1
func.yaml 設定ファイルは、イメージ名とレジストリーを判断するために使用されます。
2
必要な依存関係を go.mod ファイルに追加できます。このファイルには、追加のローカル Golang ファイルを含めることができます。デプロイメント用にプロジェクトをビルドすると、これらの依存関係は作成したランタイムコンテナーイメージに含まれます。

依存関係の追加例

$ go get gopkg.in/yaml.v2@v2.4.0

9.6.3. Golang 関数の呼び出しについて

golang 関数は、HTTP 要求、CloudEvent のいずれかでトリガーされるかどうかによって、異なる方法を使用して呼び出されます。

9.6.3.1. HTTP 要求でトリガーされる関数

受信 HTTP 要求が受信されると、最初のパラメーターとして標準の Golang Context で関数が呼び出されます。次に 2 つのパラメーターが追加されます。

標準の Golang 技術を使用して要求にアクセスし、関数に適切な HTTP 応答を設定できます。

HTTP 応答の例

func Handle(ctx context.Context, res http.ResponseWriter, req *http.Request) {
  // Read body
  body, err := ioutil.ReadAll(req.Body)
  defer req.Body.Close()
  if err != nil {
	http.Error(res, err.Error(), 500)
	return
  }
  // Process body and function logic
  // ...
}

9.6.3.2. CloudEvent でトリガーされた関数

受信 CloudEvent が受信されると、イベントは CloudEvents Golang SDK および Event タイプにより、パラメーターとして呼び出さます。

サポート対象の関数署名のリストが示すように、Golang Context を関数契約のオプションのパラメーターとして使用できます。

サポート対象の関数署名

Handle()
Handle() error
Handle(context.Context)
Handle(context.Context) error
Handle(cloudevents.Event)
Handle(cloudevents.Event) error
Handle(context.Context, cloudevents.Event)
Handle(context.Context, cloudevents.Event) error
Handle(cloudevents.Event) *cloudevents.Event
Handle(cloudevents.Event) (*cloudevents.Event, error)
Handle(context.Context, cloudevents.Event) *cloudevents.Event
Handle(context.Context, cloudevents.Event) (*cloudevents.Event, error)

9.6.3.2.1. CloudEvent トリガーの例

CloudEvent が受信され、これには data プロパティーに JSON 文字列が含まれます。

{
  "customerId": "0123456",
  "productId": "6543210"
}

このデータにアクセスするには、CloudEvent データのプロパティーをマッピングし、受信イベントからデータを取得する構造を定義する必要があります。以下の例では、Purchase 構造を使用します。

type Purchase struct {
  CustomerId string `json:"customerId"`
  ProductId  string `json:"productId"`
}
func Handle(ctx context.Context, event cloudevents.Event) (err error) {

  purchase := &Purchase{}
  if err = event.DataAs(purchase); err != nil {
	fmt.Fprintf(os.Stderr, "failed to parse incoming CloudEvent %s\n", err)
	return
  }
  // ...
}

または、Golang encoding/json パッケージを使用して、バイトアレイ形式で直接 JSON として CloudEvent にアクセスできます。

func Handle(ctx context.Context, event cloudevents.Event) {
  bytes, err := json.Marshal(event)
  // ...
}

9.6.4. golang function の戻り値

HTTP トリガー関数は、Golang http.ResponseWriter を使用して応答を直接設定できます。

HTTP 応答の例

func Handle(ctx context.Context, res http.ResponseWriter, req *http.Request) {
  // Set response
  res.Header().Add("Content-Type", "text/plain")
  res.Header().Add("Content-Length", "3")
  res.WriteHeader(200)
  _, err := fmt.Fprintf(res, "OK\n")
  if err != nil {
	fmt.Fprintf(os.Stderr, "error or response write: %v", err)
  }
}

CloudEvent によってトリガーされる関数は、何も返さないか、error または CloudEvent を返し、Knative Eventing システムにイベントをプッシュする場合があります。この場合、CloudEvent に一意の ID、適切な ソース および 種別 を設定する必要があります。データは、定義した構造または マップ から入力できます。

CloudEvent 応答の例

func Handle(ctx context.Context, event cloudevents.Event) (resp *cloudevents.Event, err error) {
  // ...
  response := cloudevents.NewEvent()
  response.SetID("example-uuid-32943bac6fea")
  response.SetSource("purchase/getter")
  response.SetType("purchase")
  // Set the data from Purchase type
  response.SetData(cloudevents.ApplicationJSON, Purchase{
	CustomerId: custId,
	ProductId:  prodId,
  })
  // OR set the data directly from map
  response.SetData(cloudevents.ApplicationJSON, map[string]string{"customerId": custId, "productId": prodId})
  // Validate the response
  resp = &response
  if err = resp.Validate(); err != nil {
	fmt.Printf("invalid event created. %v", err)
  }
  return
}

9.6.5. Golang 関数のテスト

golang 機能は、お使いのコンピューターのローカルでテストできます。kn func create を使用した関数の作成時に作成される default プロジェクトには、一部の基本的なテストが含まれる handle_test.go ファイルがあります。これらのテストは、必要に応じて拡張できます。

手順

  • テストを実行します。

    $ go test

9.6.6. 次のステップ

9.7. Python 関数の開発

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

Python 関数プロジェクトを作成 したら、指定したテンプレートファイルを変更して、ビジネスロジックを機能に追加できます。

9.7.1. 前提条件

9.7.2. Python 関数テンプレート構造

kn CLI を使用して Python 機能を作成する場合の、プロジェクトディレクトリーは通常の Python プロジェクトに似ています。

Python 関数にはいくつかの制限があります。プロジェクトの要件として唯一、main() 関数と func.yaml 設定ファイルで構成される func.py が含まれることが挙げられます。

開発者は、テンプレート requirements.txt ファイルにある依存関係しか使用できないわけではありません。その他の依存関係は、他の Python プロジェクトに配置されるように追加できます。デプロイメント用にプロジェクトをビルドすると、これらの依存関係は作成したランタイムコンテナーイメージに含まれます。

http および event トリガー関数のテンプレート構造はいずれも同じです。

テンプレート構造

fn
├── func.py 1
├── func.yaml 2
├── requirements.txt 3
└── test_func.py 4

1
main() 関数が含まれます。
2
イメージ名とレジストリーを判断するために使用されます。
3
その他の依存関係は、他の Python プロジェクトにあるため、requirements.txt ファイルに追加できます。
4
関数のローカルでのテストに使用できる単純なユニットテストが含まれます。

9.7.3. Python 関数の呼び出しについて

Python 関数は、単純な HTTP 要求で呼び出すことができます。受信要求を受け取ると、関数は context オブジェクトで最初のパラメーターとして呼び出されます。context オブジェクトは、2 つの属性を持つ Python クラスです。

  • request 属性。この属性常に存在し、Flask request オブジェクトが含まれます。
  • 2 番目の属性 cloud_event。受信した要求が CloudEvent オブジェクトの場合に設定されます。

開発者はコンテキストオブジェクトから CloudEvent データすべてにアクセスできます。

コンテキストオブジェクトの例

def main(context: Context):
    """
    The context parameter contains the Flask request object and any
    CloudEvent received with the request.
    """
    print(f"Method: {context.request.method}")
    print(f"Event data {context.cloud_event.data}")
    # ... business logic here

9.7.4. Python 関数の戻り値

関数は、呼び出しのフレームワークは Flask サーバーに直接これらの値をプロキシーするので Flask でサポートされた値を返すことができます。

def main(context: Context):
    body = { "message": "Howdy!" }
    headers = { "content-type": "application/json" }
    return body, 200, headers

関数は、関数呼び出しの 2 番目および 3 番目の応答値として、ヘッダーと応答コードの両方を設定できます。

9.7.4.1. Returning CloudEvents

開発者は @event デコレーターを使用して、呼び出し元に対して、応答を送信する前に関数の戻り値を CloudEvent に変換する必要があることを指示できます。

@event("event_source"="/my/function", "event_type"="my.type")
def main(context):
    # business logic here
    data = do_something()
    # more data processing
    return data

この例では、タイプが "my.type"、ソースが "/my/function" の応答値として CloudEvent を送信します。CloudEvent data プロパティー は、返された data 変数に設定されます。event_source および event_type デコレーター属性は任意です。

9.7.5. Python 関数のテスト

Python 機能は、お使いのコンピューターのローカルにテストできます。デフォルトプロジェクトには、test_func.py ファイルが含まれており、関数の単純なユニットテストを提供します。

注記

Python 関数のデフォルトのテストフレームワークは unittest です。必要に応じて、別のテストフレームワークを使用できます。

前提条件

  • Python 関数テストをローカルで実行するには、必要な依存関係をインストールする必要があります。

    $ pip install -r requirements.txt

手順

  • 依存関係をインストールしたら、テストを実行します。

    $ python3 test_func.py

9.7.6. 次のステップ

9.8. Quarkus 関数の開発

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

Quarkus 関数プロジェクトを作成 したら、指定のテンプレートを変更して、関数にビジネスロジックを追加できます。

9.8.1. 前提条件

9.8.2. Quarkus 関数テンプレートの構造

kn CLI を使用して Quarkus 機能を作成する場合の、プロジェクトディレクトリーは通常の Maven プロジェクトに似ています。

http および event トリガー関数のテンプレート構造はいずれも同じです。

テンプレート構造

.
├── func.yaml 1
├── mvnw
├── mvnw.cmd
├── pom.xml 2
├── README.md
└── src
    ├── main
    │   ├── java
    │   │   └── functions
    │   │       ├── Function.java 3
    │   │       ├── Input.java
    │   │       └── Output.java
    │   └── resources
    │       └── application.properties
    └── test
        └── java
            └── functions 4
                ├── FunctionTest.java
                └── NativeFunctionIT.java

1
イメージ名とレジストリーを判断するために使用されます。
2
プロジェクトオブジェクトモデル (POM) ファイルには、依存関係に関する情報などのプロジェクト設定が含まれています。このファイルを変更して、別の依存関係を追加できます。

追加の依存関係の例

...
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.assertj</groupId>
      <artifactId>assertj-core</artifactId>
      <version>3.8.0</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
...

依存関係は、最初のコンパイル時にダウンロードされます。

3
関数プロジェクトには、@Funq アノテーションが付けられた Java メソッドが含まれている必要があります。このメソッドは Function.java クラスに配置できます。
4
関数のローカルでのテストに使用できる単純なテストケースが含まれます。

9.8.3. Quarkus 関数の呼び出しについて

CloudEvents に応答する Quarkus プロジェクトや、簡単な HTTP 要求に応答する Quarkus プロジェクトを作成できます。Knative の CloudEvents は HTTP 経由で POST 要求として転送されるため、いずれかの関数タイプは受信 HTTP 要求をリッスンして応答します。

受信要求が受信されると、Quarkus 関数は使用可能なタイプのインスタンスと合わせて呼び出されます。

表9.1 関数呼び出しオプション

呼び出しメソッドインスタンスに含まれるデータタイプデータの例

HTTP POST 要求

要求のボディーに含まれる JSON オブジェクト

{ "customerId": "0123456", "productId": "6543210" }

HTTP GET 要求

クエリー文字列のデータ

?customerId=0123456&productId=6543210

CloudEvent

data プロパティーの JSON オブジェクト

{ "customerId": "0123456", "productId": "6543210" }

以下の例は、以前の表に記載されている customerId および productId の購入データを受信して処理する関数です。

Quarkus 関数の例

public class Functions {
    @Funq
    public void processPurchase(Purchase purchase) {
        // process the purchase
    }
}

購入データが含まれる、該当の Purchase JavaBean クラスは以下のようになります。

クラスの例

public class Purchase {
    private long customerId;
    private long productId;
    // getters and setters
}

9.8.3.1. StorageLocation の例

以下のコード例は、withBeanswithCloudEvent、および withBinary の 3 つの関数を定義します。

import io.quarkus.funqy.Funq;
import io.quarkus.funqy.knative.events.CloudEvent;

public class Input {
    private String message;

    // getters and setters
}

public class Output {
    private String message;

    // getters and setters
}

public class Functions {
    @Funq
    public Output withBeans(Input in) {
        // function body
    }

    @Funq
    public CloudEvent<Output> withCloudEvent(CloudEvent<Input> in) {
        // function body
    }

    @Funq
    public void withBinary(byte[] in) {
        // function body
    }
}

Functions クラスの withBeans 機能は、以下にで呼び出すことができます。

  • JSON ボディーが含まれる HTTP POST 要求:

    $ curl "http://localhost:8080/withBeans" -X POST \
        -H "Content-Type: application/json" \
        -d '{"message": "Hello there."}'
  • クエリーパラメーターが含まれる HTTP GET 要求:

    $ curl "http://localhost:8080/withBeans?message=Hello%20there." -X GET
  • バイナリーエンコーディングの CloudEvent オブジェクト:

    $ curl "http://localhost:8080/" -X POST \
      -H "Content-Type: application/json" \
      -H "Ce-SpecVersion: 1.0" \
      -H "Ce-Type: withBeans" \
      -H "Ce-Source: cURL" \
      -H "Ce-Id: 42" \
      -d '{"message": "Hello there."}'
  • 構造化されたエンコーディングでの CloudEvent オブジェクト:

    $ curl http://localhost:8080/ \
        -H "Content-Type: application/cloudevents+json" \
        -d '{ "data": {"message":"Hello there."},
              "datacontenttype": "application/json",
              "id": "42",
              "source": "curl",
              "type": "withBeans",
              "specversion": "1.0"}'

Functions クラスの withCloudEvent 機能は、withBeans 関数 と同様に CloudEvent オブジェクトを使用して呼び出すことができます。ただし、withBeans とは異なり、withCloudEvent はプレーン HTTP 要求で呼び出すことはできません。

Functions クラスの withBinary 関数は、以下にで呼び出すことができます。

  • バイナリーエンコーディングの CloudEvent オブジェクト:

    $ curl "http://localhost:8080/" -X POST \
      -H "Content-Type: application/octet-stream" \
      -H "Ce-SpecVersion: 1.0"\
      -H "Ce-Type: withBinary" \
      -H "Ce-Source: cURL" \
      -H "Ce-Id: 42" \
      --data-binary '@img.jpg'
  • 構造化されたエンコーディングでの CloudEvent オブジェクト:

    $ curl http://localhost:8080/ \
      -H "Content-Type: application/cloudevents+json" \
      -d "{ \"data_base64\": \"$(base64 --wrap=0 img.jpg)\",
            \"datacontenttype\": \"application/octet-stream\",
            \"id\": \"42\",
            \"source\": \"curl\",
            \"type\": \"withBinary\",
            \"specversion\": \"1.0\"}"

9.8.4. CloudEvent 属性

type または subject など CloudEvent の属性を読み取るか、書き込む必要がある場合は、CloudEvent<T> 汎用インターフェースおよび CloudEventBuilder ビルダーを使用できます。<T> タイプパラメーターは使用可能なたタイプのいずれかでなければなりません。

以下の例では、CloudEventBuilder を使用して、購入処理の成功または失敗を返します。

public class Functions {

    private boolean _processPurchase(Purchase purchase) {
        // do stuff
    }

    public CloudEvent<Void> processPurchase(CloudEvent<Purchase> purchaseEvent) {
        System.out.println("subject is: " + purchaseEvent.subject());

        if (!_processPurchase(purchaseEvent.data())) {
            return CloudEventBuilder.create()
                    .type("purchase.error")
                    .build();
        }
        return CloudEventBuilder.create()
                .type("purchase.success")
                .build();
    }
}

9.8.5. Quarkus 関数の戻り値

この関数は、以下のインスタンスを返すことができます。

  • 使用可能なタイプの一覧にある全タイプ。
  • Uni<T> タイプ。<T> タイプパラメーターは、使用可能なタイプからどれでも使用できます。

Uni<T> タイプは、返されるオブジェクトが受信したオブジェクトと同じ形式でシリアライズされるため、関数が非同期 API を呼び出す場合に便利です。以下は例になります。

  • 関数が HTTP 要求を受信すると、返されるオブジェクトが HTTP 応答のボディーに送信されます。
  • 関数がバイナリーエンコーディングで CloudEvent オブジェクトを受信する場合に、返されるオブジェクトはバイナリーエンコードされた CloudEvent オブジェクトの data プロパティーで送信されます。

以下の例は、購入リストを取得する関数を示しています。

コマンドの例

public class Functions {
    @Funq
    public List<Purchase> getPurchasesByName(String name) {
      // logic to retrieve purchases
    }
}

  • HTTP 要求経由でこの関数を呼び出すと、応答のボディーに購入された一覧が含まれる HTTP 応答が生成されます。
  • 受信 CloudEvent オブジェクト経由でこの関数を呼び出すと、data プロパティーの購入リストが含まれる CloudEvent 応答が生成されます。

9.8.5.1. 使用可能なタイプ

関数の入力および出力タイプは以下のいずれかになります。

  • void
  • String
  • byte[]
  • プリミティブタイプおよびそのラッパー (例: int および Integer).
  • JavaBean (属性のタイプをここにリストしている場合)
  • この一覧にあるタイプのマップ、一覧、または配列。
  • 特別な CloudEvents <T> タイプ。<T> タイプパラメーターはこの一覧のタイプに置き換えます。

public class Functions {
    public List<Integer> getIds();
    public Purchase[] getPurchasesByName(String name);
    public String getNameById(int id);
    public Map<String,Integer> getNameIdMapping();
    public void processImage(byte[] img);
}

9.8.6. Quarkus 関数のテスト

プロジェクトテンプレートに含まれる Maven テストを実行すると、コンピューターで Quarkus 関数をローカルでテストできます。

手順

  • Maven テストを実行します。

    $ ./mvnw test

9.8.7. 次のステップ

9.9. func.yaml の関数プロジェクト設定

func.yaml ファイルには、関数プロジェクトの設定が含まれます。

通常、これらの値は kn func コマンドの実行時に使用されます。たとえば、kn func build コマンドを実行すると、builder フィールドの値が使用されます。

注記

多くの場合、この値はコマンドラインフラグまたは環境変数で上書きできます。

9.9.1. func.yaml の設定可能なフィールド

func.yaml のフィールドの多くは、関数の作成、ビルド、およびデプロイ時に自動的に生成されます。ただし、関数名またはイメージ名などの変更用に手動で変更するフィールドもあります。

9.9.1.1. builder

builder フィールドは、関数のビルド時に使用する Buildpack ビルダーイメージを指定します。ほとんどの場合、この値は変更できません。これを変更する場合は、builderMap フィールドに一覧表示されている値を使用してください。

9.9.1.2. builderMap

一部の関数ランタイムは複数の方法でビルドできます。たとえば、Quarkus 関数は JVM 用にビルドするか、ネイティブバイナリーとしてビルドできます。builderMap フィールドには、指定のランタイムで使用できるすべてのビルダーが含まれます。

9.9.1.3. envs

envs フィールドを使用すると、ランタイム時に関数で使用できるように環境変数を設定できます。環境変数は、複数の異なる方法で設定できます。

  1. 値から直接設定します。
  2. ローカル環境変数に割り当てられた値から設定します。詳細は、「func.yaml フィールドからのローカル環境変数の参照」のセクションを参照してください。
  3. シークレットまたは設定マップに格納されているキーと値のペアから設定します。
  4. 作成された環境変数の名前として使用されるキーを使用して、シークレットまたは設定マップに格納されているすべてのキーと値のペアをインポートすることもできます。

以下の例は、環境変数を設定するさまざまな方法を示しています。

name: test
namespace: ""
runtime: go
...
envs:
- name: EXAMPLE1 1
  value: value
- name: EXAMPLE2 2
  value: '{{ env:LOCAL_ENV_VALUE }}'
- name: EXAMPLE3 3
  value: '{{ secret:mysecret:key }}'
- name: EXAMPLE4 4
  value: '{{ configMap:myconfigmap:key }}'
- value: '{{ secret:mysecret2 }}' 5
- value: '{{ configMap:myconfigmap2 }}' 6
1
値から直接設定された環境変数。
2
ローカル環境変数に割り当てられた値から設定された環境変数。
3
シークレットに格納されているキーと値のペアから割り当てられた環境変数。
4
設定マップに保存されるキーと値のペアから割り当てられる環境変数。
5
シークレットのキーと値のペアからインポートされた環境変数のセット。
6
設定マップのキーと値のペアからインポートされた環境変数のセット。

9.9.1.4. ボリューム

以下の例のように、volumes フィールドを使用すると、指定したパスで関数にアクセスできるボリュームとしてシークレットと設定マップをマウントできます。

name: test
namespace: ""
runtime: go
...
volumes:
- secret: mysecret 1
  path: /workspace/secret
- configMap: myconfigmap 2
  path: /workspace/configmap
1
mysecret シークレットは、/workspace/secret にあるボリュームとしてマウントされます。
2
myconfigmap 設定マップは、/workspace/configmap にあるボリュームとしてマウントされます。

9.9.1.5. オプション

options フィールドを使用すると、自動スケーリングなど、デプロイされた関数の Knative Service プロパティーを変更できます。これらのオプションが設定されていない場合は、デフォルトのオプションが使用されます。

これらのオプションを利用できます。

  • scale

    • min: レプリカの最小数。負ではない整数でなければなりません。デフォルトは 0 です。
    • max: レプリカの最大数。負ではない整数でなければなりません。デフォルトは 0 で、これは制限がないことを意味します。
    • metric: Autoscaler によって監視されるメトリクスタイプを定義します。これは、デフォルトの concurrency、または rps に設定できます。
    • target: 同時に受信する要求の数に基づくスケールアップのタイミングの推奨。target オプションは、0.01 より大きい浮動小数点値を指定できます。options.resources.limits.concurrency が設定されていない限り、デフォルトは 100 になります。この場合、target はデフォルトでその値になります。
    • utilization: スケールアップする前に許可された同時リクエスト使用率のパーセンテージ。1 から 100 までの浮動小数点値を指定できます。デフォルトは 70 です。
  • リソース

    • requests

      • cpu: デプロイされた関数を持つコンテナーの CPU リソース要求。
      • memory: デプロイされた関数を持つコンテナーのメモリーリソース要求。
    • limits

      • cpu: デプロイされた関数を持つコンテナーの CPU リソース制限。
      • memory: デプロイされた関数を持つコンテナーのメモリーリソース制限。
      • concurrency: 単一レプリカによって処理される同時要求のハード制限。0 以上の整数値を指定できます。デフォルトは 0 です (制限なしを意味します)。

これは、scale オプションの設定例です。

name: test
namespace: ""
runtime: go
...
options:
  scale:
    min: 0
    max: 10
    metric: concurrency
    target: 75
    utilization: 75
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 1000m
      memory: 256Mi
      concurrency: 100

9.9.1.6. image

image フィールドは、関数がビルドされた後の関数のイメージ名を設定します。このフィールドは必要に応じて変更できます。変更する場合、次に kn func build または kn func deploy を実行すると、関数イメージは新しい名前で作成されます。

9.9.1.7. imageDigest

imageDigest フィールドには、関数のデプロイ時のイメージマニフェストの SHA256 ハッシュが含まれます。この値は変更しないでください。

9.9.1.8. 名前

name フィールドは、関数の名前を定義します。この値は、デプロイ時に Knative サービスの名前として使用されます。このフィールドを変更して、後続のデプロイメントで関数の名前を変更できます。

9.9.1.9. namespace

namespace フィールドは、関数がデプロイされる namespace を指定します。

9.9.1.10. runtime

runtime フィールドは、関数の言語ランタイムを指定します (例: python)。

9.9.1.11. template

template フィールドは、関数をトリガーする呼び出しイベントのタイプを指定します。プレーン HTTP 要求でトリガーする場合は http に設定し、CloudEvents でトリガーする場合は events に設定できます。

9.9.2. func.yaml フィールドからのローカル環境変数の参照

func.yamlenvs フィールドで、ローカル環境で利用可能な環境変数への参照を置くことができます。これは、関数設定の API キーなどの機密情報の格納を回避する場合に役立ちます。

手順

  • ローカル環境変数を参照するには、以下の構文を使用します。

    {{ env:ENV_VAR }}

    ENV_VAR を、使用するローカル環境の変数の名前に置き換えます。

    たとえば、ローカル環境で API_KEY 変数が利用可能な場合があります。その値を MY_API_KEY 変数に割り当てることができます。これにより、関数内で直接使用できます。

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - name: MY_API_KEY
      value: '{{ env:API_KEY }}'

関連情報

9.10. Serverless 関数からのシークレットおよび設定マップへのアクセス

クラスターにデプロイした後、関数はシークレットおよび設定マップに格納されているデータにアクセスできます。このデータはボリュームとしてマウントすることも、環境変数に割り当てることもできます。Knative CLI kn func コマンドを使用して、このアクセスを対話的に設定するか、関数設定ファイルを編集して手動で設定できます。

重要

シークレットおよび設定マップにアクセスするには、関数をクラスターにデプロイする必要があります。この機能は、ローカルで実行している関数では利用できません。

シークレットまたは設定マップの値にアクセスできない場合、デプロイメントは失敗し、アクセスできない値を指定するエラーメッセージが表示されます。

9.10.1. シークレットおよび設定マップへの関数アクセスの対話的な変更

kn func config 対話型ユーティリティーを使用して、関数がアクセスするシークレットおよび設定マップを管理できます。

手順

  1. 関数プロジェクトディレクトリーで以下のコマンドを実行します。

    $ kn func config

    あるいは、--path または -p オプションを使用して、関数プロジェクトディレクトリーを指定できます。

  2. 対話型インターフェースを使用して必要な操作を実行します。たとえば、ユーティリティーを使用して設定したボリュームの一覧を表示すると、以下のような出力が生成されます。

    $ kn func config
    ? What do you want to configure? Volumes
    ? What operation do you want to perform? List
    Configured Volumes mounts:
    - Secret "mysecret" mounted at path: "/workspace/secret"
    - Secret "mysecret2" mounted at path: "/workspace/secret2"

    このスキームは、対話型ユーティリティーで利用可能なすべての操作と、それらに移動する方法を示しています。

    kn func config
       ├─> Environment variables
       │               ├─> Add
       │               │    ├─> ConfigMap: Add all key-value pairs from a config map
       │               │    ├─> ConfigMap: Add value from a key in a config map
       │               │    ├─> Secret: Add all key-value pairs from a secret
       │               │    └─> Secret: Add value from a key in a secret
       │               ├─> List: List all configured environment variables
       │               └─> Remove: Remove a configured environment variable
       └─> Volumes
               ├─> Add
               │    ├─> ConfigMap: Mount a config map as a volume
               │    └─> Secret: Mount a secret as a volume
               ├─> List: List all configured volumes
               └─> Remove: Remove a configured volume
  3. オプション。変更を反映させるため、関数をデプロイします。

    $ kn func deploy -p test

9.10.2. シークレットおよび設定マップへの関数アクセスの特殊なコマンドを使用した対話的な変更

kn func config ユーティリティーを実行するたびにダイアログ全体を移動して、直前のセクションで示されているように、必要な操作を選択する必要があります。ステップを保存するには、kn func config コマンドのより具体的なフォームを実行することで、特定の操作を直接実行します。

  • 設定した環境変数を一覧表示するには、以下を実行します。

    $ kn func config envs [-p <function-project-path>]
  • 関数設定に環境変数を追加するには、以下を実行します。

    $ kn func config envs add [-p <function-project-path>]
  • 関数設定から環境変数を削除するには、以下を実行します。

    $ kn func config envs remove [-p <function-project-path>]
  • 設定したボリュームを一覧表示するには、以下を実行します。

    $ kn func config volumes [-p <function-project-path>]
  • 関数設定にボリュームを追加するには、以下を実行します。

    $ kn func config volumes add [-p <function-project-path>]
  • 関数設定からボリュームを削除するには、以下を実行します。

    $ kn func config volumes remove [-p <function-project-path>]

9.10.3. シークレットおよび設定マップへの関数アクセスの手動による追加

シークレットおよび設定マップにアクセスするための設定を手動で関数に追加できます。

9.10.3.1. シークレットのボリュームとしてのマウント

  1. 関数の func.yaml ファイルを開きます。
  2. ボリュームとしてマウントするシークレットごとに、以下の YAML を volumes セクションに追加します。

    name: test
    namespace: ""
    runtime: go
    ...
    volumes:
    - secret: mysecret
      path: /workspace/secret
    • mysecret をターゲットシークレットの名前に置き換えます。
    • /workspace/secret は、シークレットをマウントするパスに置き換えます。
  3. 設定を保存します。

9.10.3.2. 設定マップのボリュームとしてのマウント

  1. 関数の func.yaml ファイルを開きます。
  2. ボリュームとしてマウントする設定マップごとに、以下の YAML を volumes セクションに追加します。

    name: test
    namespace: ""
    runtime: go
    ...
    volumes:
    - configMap: myconfigmap
      path: /workspace/configmap
    • myconfigmap をターゲット設定マップの名前に置き換えます。
    • /workspace/configmap は、設定マップをマウントするパスに置き換えます。
  3. 設定を保存します。

9.10.3.3. シークレットで定義されるキー値からの環境変数の設定

  1. 関数の func.yaml ファイルを開きます。
  2. 環境変数に割り当てる秘密鍵と値のペアからの値ごとに、以下の YAML を envs セクションに追加します。

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - name: EXAMPLE
      value: '{{ secret:mysecret:key }}'
    • EXAMPLE を環境変数の名前に置き換えます。
    • mysecret をターゲットシークレットの名前に置き換えます。
    • key をターゲット値にマッピングしたキーに置き換えます。
  3. 設定を保存します。

9.10.3.4. 設定マップで定義されるキー値からの環境変数の設定

  1. 関数の func.yaml ファイルを開きます。
  2. 環境変数に割り当てる設定マップのキーと値のペアからの値ごとに、以下の YAML を envs セクションに追加します。

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - name: EXAMPLE
      value: '{{ configMap:myconfigmap:key }}'
    • EXAMPLE を環境変数の名前に置き換えます。
    • myconfigmap をターゲット設定マップの名前に置き換えます。
    • key をターゲット値にマッピングしたキーに置き換えます。
  3. 設定を保存します。

9.10.3.5. シークレットで定義されたすべての値からの環境変数の設定

  1. 関数の func.yaml ファイルを開きます。
  2. すべてのキーと値のペアを環境変数としてインポートするすべてのシークレットについて、以下の YAML を envs セクションに追加します。

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - value: '{{ secret:mysecret }}' 1
    1
    mysecret をターゲットシークレットの名前に置き換えます。
  3. 設定を保存します。

9.10.3.6. 設定マップで定義されたすべての値からの環境変数の設定

  1. 関数の func.yaml ファイルを開きます。
  2. すべてのキーと値のペアを環境変数としてインポートするすべての設定マップについて、以下の YAML を envs セクションに追加します。

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - value: '{{ configMap:myconfigmap }}' 1
    1
    myconfigmap をターゲット設定マップの名前に置き換えます。
  3. ファイルを保存します。

9.11. アノテーションの関数への追加

Kubernetes アノテーションは、func.yaml 設定ファイルの annotations セクションに追加することで、デプロイした Serverless 機能に追加できます。

重要

関数アノテーション機能には、以下の 2 つの制限があります。

  • 関数アノテーションがクラスター上の対応する Knative サービスに伝播されると、func.yaml ファイルから削除することでサービスから削除することはできません。サービスの YAML ファイルを直接変更するか、または開発者コンソールを使用して、Knative サービスからアノテーションを削除できます。
  • autoscaling アノテーションなど、Knative によって設定されるアノテーションを設定することはできません。

9.11.1. 関数へのアノテーションの追加

手順

  1. 関数の func.yaml ファイルを開きます。
  2. 追加するすべてのアノテーションについて、以下の YAML を annotations セクションに追加します。

    name: test
    namespace: ""
    runtime: go
    ...
    annotations:
      <annotation_name>: "<annotation_value>" 1
    1
    <annotation_name>: "<annotation_value>" をお使いのアノテーションに置き換えます。

    たとえば、関数が Alice によって作成者されたことを示すには、以下のアノテーションを含めることができます。

    name: test
    namespace: ""
    runtime: go
    ...
    annotations:
      author: "alice@example.com"
  3. 設定を保存します。

次に関数をクラスターにデプロイすると、アノテーションが対応する Knative サービスに追加されます。

9.12. 関数開発リファレンスガイド

重要

OpenShift Serverless Functions は、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

OpenShift Serverless Functions は、以下のランタイムの基本機能を作成するために使用できるテンプレートを提供します。

本ガイドでは、関数の開発に使用可能なリファレンス情報を提供します。

9.12.1. Node.js コンテキストオブジェクトのリファレンス

context オブジェクトには、関数開発者が利用可能なプロパティーが複数あります。

9.12.1.1. log

出力をクラスターロギングに書き込むために使用可能なロギングオブジェクトを提供します。ログは Pino logging API に準拠します。

ログの例

function handle(context) {
  context.log.info(“Processing customer”);
}

curl コマンドを使用してこの関数を呼び出すことができます。

コマンドの例

$ curl http://example.com

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"Processing customer"}

ログレベルは、fatalerrorwarninfodebugtrace、または silent のいずれかに設定できます。これを実行するには、config コマンドを使用してこれらの値のいずれかを環境変数 FUNC_LOG_LEVEL に割り当てて、logLevel の値を変更します。

9.12.1.2. query

要求のクエリー文字列 (ある場合) をキーと値のペアとして返します。これらの属性はコンテキストオブジェクト自体にも表示されます。

サンプルクエリー

function handle(context) {
  // Log the 'name' query parameter
  context.log.info(context.query.name);
  // Query parameters are also attached to the context
  context.log.info(context.name);
}

curl コマンドを使用してこの関数を呼び出すことができます。

コマンドの例

$ curl http://example.com?name=tiger

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"tiger"}

9.12.1.3. ボディー

要求ボディー (ある場合) を返します。要求ボディーに JSON コードが含まれる場合には、属性は直接利用できるように解析されます。

ボディーの例

function handle(context) {
  // log the incoming request body's 'hello' parameter
  context.log.info(context.body.hello);
}

curl コマンドを使用してこの関数を呼び出すことができます。

コマンドの例

$ curl -X POST -d '{"hello": "world"}' -H 'Content-type: application/json' http://example.com

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"world"}

9.12.1.4. ヘッダー

HTTP 要求ヘッダーをオブジェクトとして返します。

ヘッダーの例

function handle(context) {
  context.log.info(context.headers["custom-header"]);
}

curl コマンドを使用してこの関数を呼び出すことができます。

コマンドの例

$ curl -H 'x-custom-header: some-value’' http://example.com

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"some-value"}

9.12.1.5. HTTP 要求

方法
HTTP 要求メソッドを文字列として返します。
httpVersion
HTTP バージョンを文字列として返します。
httpVersionMajor
HTTP メジャーバージョン番号を文字列として返します。
httpVersionMinor
HTTP マイナーバージョン番号を文字列として返します。

9.12.2. Typescript コンテキストオブジェクトの参照

context オブジェクトには、関数開発者が利用可能なプロパティーが複数あります。

9.12.2.1. log

出力をクラスターロギングに書き込むために使用可能なロギングオブジェクトを提供します。ログは Pino logging API に準拠します。

ログの例

export function handle(context: Context): string {
    // log the incoming request body's 'hello' parameter
    if (context.body) {
      context.log.info((context.body as Record<string, string>).hello);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

この関数にアクセスするには、kn func emit コマンドを使用して関数を呼び出します。

コマンドの例

$ kn func emit --sink 'http://example.function.com'

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"Processing customer"}

ログレベルは、fatalerrorwarninfodebugtrace、または silent のいずれかに設定できます。これを実行するには、config コマンドを使用してこれらの値のいずれかを環境変数 FUNC_LOG_LEVEL に割り当てて、logLevel の値を変更します。

9.12.2.2. query

要求のクエリー文字列 (ある場合) をキーと値のペアとして返します。これらの属性はコンテキストオブジェクト自体にも表示されます。

サンプルクエリー

export function handle(context: Context): string {
      // log the 'name' query parameter
    if (context.query) {
      context.log.info((context.query as Record<string, string>).name);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

この関数にアクセスするには、kn func emit コマンドを使用して関数を呼び出します。

コマンドの例

$ kn func emit --sink 'http://example.function.com' --data '{"name": "tiger"}'

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"tiger"}
{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"tiger"}

9.12.2.3. ボディー

要求ボディー (ある場合) を返します。要求ボディーに JSON コードが含まれる場合には、属性は直接利用できるように解析されます。

ボディーの例

export function handle(context: Context): string {
    // log the incoming request body's 'hello' parameter
    if (context.body) {
      context.log.info((context.body as Record<string, string>).hello);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

この関数にアクセスするには、kn func emit コマンドを使用して関数を呼び出します。

コマンドの例

$ kn func emit --sink 'http://example.function.com' --data '{"hello": "world"}'

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"world"}

9.12.2.4. ヘッダー

HTTP 要求ヘッダーをオブジェクトとして返します。

ヘッダーの例

export function handle(context: Context): string {
    // log the incoming request body's 'hello' parameter
    if (context.body) {
      context.log.info((context.headers as Record<string, string>)['custom-header']);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

curl コマンドを使用してこの関数を呼び出すことができます。

コマンドの例

$ curl -H'x-custom-header: some-value’' http://example.function.com

出力例

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"some-value"}

9.12.2.5. HTTP 要求

方法
HTTP 要求メソッドを文字列として返します。
httpVersion
HTTP バージョンを文字列として返します。
httpVersionMajor
HTTP メジャーバージョン番号を文字列として返します。
httpVersionMinor
HTTP マイナーバージョン番号を文字列として返します。

第10章 統合

10.1. サーバーレスアプリケーションでの NVIDIA GPU リソースの使用

Nvidia は、OpenShift Container Platform での GPU リソースの実験的な使用をサポートします。OpenShift Container Platform での GPU リソースの設定に関する詳細は、「OpenShift Container Platform on NVIDIA GPU accelerated clusters」を参照してください。

10.1.1. サービスの GPU 要件の指定

OpenShift Container Platform クラスターについて GPU リソースが有効にされた後に、kn CLI を使用して Knative サービスの GPU 要件を指定できます。

注記

NVIDIA GPU リソースの使用は IBM Z および IBM Power Systems ではサポートされません。

手順

  1. Knative サービスを作成し、--limit nvidia.com/gpu=1 フラグを使用して、GPU リソース要件の制限を 1 に設定します。

    $ kn service create hello --image <service-image> --limit nvidia.com/gpu=1

    GPU リソース要件の制限が 1 の場合、サービスには専用の GPU リソースが 1 つ必要です。サービスは、GPU リソースを共有しません。GPU リソースを必要とするその他のサービスは、GPU リソースが使用されなくなるまで待機する必要があります。

    1 GPU の制限は、1 GPU リソースの使用を超えるアプリケーションが制限されることも意味します。サービスが 2 つ以上の GPU リソースを要求する場合、これは GPU リソース要件を満たしているノードにデプロイされます。

  2. オプション:既存のサービスについては、--limit nvidia.com/gpu=3 フラグを使用して、GPU リソース要件の制限を 3 に変更できます。

    $ kn service update hello --limit nvidia.com/gpu=3

10.1.2. 関連情報

第11章 CLI ツール

11.1. Knative CLI のインストール

Knative CLI (kn) には、独自のログインメカニズムは含まれません。クラスターにログインするには、 oc CLI をインストールし、 oc login コマンドを使用する必要があります。

oc CLI のインストールオプションは、お使いのオペレーティングシステムによって異なります。

ご使用のオペレーティングシステム用に oc CLI をインストールする方法および oc でのログイン方法についての詳細は、OpenShift CLI の使用開始についてのドキュメントを参照してください。

重要

新しい OpenShift Serverless リリースで古いバージョンの Knative kn CLI の使用を試行する場合は、API が見つからないとエラーが発生します。

たとえば、バージョン 0.22.0 を使用する kn CLI の 1.16.0 リリースと、Knative Serving および Knative Eventing API の 0.23.0 バージョンを使用する 1.17.0 OpenShift Serverless リリースを使用する場合、CLI は、古い 0.22.0 API バージョンを探し続けるため、機能しません。

問題を回避するために、OpenShift Serverless リリースの最新の kn CLI バージョンを使用していることを確認してください。

11.1.1. OpenShift Container Platform Web コンソールを使用した Knative CLI のインストール

OpenShift Serverless Operator がインストールされると、OpenShift Container Platform Web コンソールの Command Line Tools ページから Linux (x86_64, amd64, s390x, ppc64le)、macOS および Windows の Knative CLI (kn) をダウンロードするためのリンクが表示されます。

Command Line Tools ページには、Web コンソールの右上の question circle アイコンをクリックして、ドロップダウンメニューの Command Line Tools を選択します。

手順

  1. Command Line Tools ページから kn CLI をダウンロードします。
  2. アーカイブを展開します。

    $ tar -xf <file>
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、以下を実行します。

    $ echo $PATH
    注記

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

    $ kn: No such file or directory

11.1.2. RPM を使用した Linux 用の Knative CLI のインストール

Red Hat Enterprise Linux (RHEL) の場合、Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがある場合は、Knative CLI (kn) を RPM としてインストールできます。

手順

  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

11.1.3. Linux の Knative CLI のインストール

Linux ディストリビューションの場合、 Knative CLI (kn) ディレクトリーを tar.gz アーカイブとして直接ダウンロードできます。

手順

  1. kn CLI をダウンロードします。
  2. アーカイブを展開します。

    $ tar -xf <file>
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、以下を実行します。

    $ echo $PATH
    注記

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

    $ kn: No such file or directory

11.1.4. RPM を使用した IBM Power Systems への Linux 用の Knative CLI のインストール

Red Hat Enterprise Linux (RHEL) の場合、Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがある場合は、Knative CLI (kn) を RPM としてインストールできます。

手順

  1. 初回の起動プロセスで Red Hat Subscription Management (RHSM) サービスに登録します。

    # subscription-manager register
  2. RHSM を更新します。

    # subscription-manager refresh
  3. --pool オプションを使用して、サブスクリプションプールの ID を指定し、サブスクリプションをシステムに割り当てます。

    # subscription-manager attach --pool=<pool_id> 1
    1
    有効な OpenShift Container Platform サブスクリプションのプール ID
  4. Red Hat Subscription Manager を使用してリポジトリーを有効にします。

    # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-ppc64le-rpms"
  5. openshift-serverless-clients をシステムにインストールします。

    # yum install openshift-serverless-clients

11.1.5. IBM Power Systems への Linux 用の Knative CLI のインストール

Linux ディストリビューションの場合、 Knative CLI (kn) ディレクトリーを tar.gz アーカイブとして直接ダウンロードできます。

手順

  1. kn CLI をダウンロードします。
  2. アーカイブを展開します。

    $ tar -xf <file>
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、以下を実行します。

    $ echo $PATH
    注記

    RHEL を使用しない場合は、libc がライブラリーパスのディレクトリーにインストールされていることを確認してください。

    libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

    $ kn: No such file or directory

11.1.6. RPM を使用した IBM Z および LinuxONE への Linux 用の Knative CLI のインストール

Red Hat Enterprise Linux (RHEL) の場合、Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがある場合は、Knative CLI (kn) を RPM としてインストールできます。

手順

  1. 初回の起動プロセスで Red Hat Subscription Management (RHSM) サービスに登録します。

    # subscription-manager register
  2. RHSM を更新します。

    # subscription-manager refresh
  3. --pool オプションを使用して、サブスクリプションプールの ID を指定し、サブスクリプションをシステムに割り当てます。

    # subscription-manager attach --pool=<pool_id> 1
    1
    有効な OpenShift Container Platform サブスクリプションのプール ID
  4. Red Hat Subscription Manager を使用してリポジトリーを有効にします。

    # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-s390x-rpms"
  5. openshift-serverless-clients をシステムにインストールします。

    # yum install openshift-serverless-clients

11.1.7. IBM Z および LinuxONE への Linux 用の Knative CLI のインストール

Linux ディストリビューションの場合、 Knative CLI (kn) ディレクトリーを tar.gz アーカイブとして直接ダウンロードできます。

手順

  1. kn CLI をダウンロードします。
  2. アーカイブを展開します。

    $ tar -xf <file>
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、以下を実行します。

    $ echo $PATH
    注記

    RHEL を使用しない場合は、libc がライブラリーパスのディレクトリーにインストールされていることを確認してください。

    libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

    $ kn: No such file or directory

11.1.8. macOS の Knative CLI のインストール

macOS の Knative CLI (kn) は tar.gz アーカイブとして提供されます。

手順

  1. kn CLI をダウンロードします。
  2. アーカイブを展開し、解凍します。
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、ターミナルウィンドウを開き、以下を実行します。

    $ echo $PATH

11.1.9. Windows の Knative CLI のインストール

Windows の CLI (kn) は zip アーカイブとして提供されます。

手順

  1. kn CLI をダウンロードします。
  2. ZIP プログラムでアーカイブを展開します。
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

11.1.10. Knative CLI のカスタマイズ

config.yaml 設定ファイルを作成して、kn CLI 設定をカスタマイズできます。--config フラグを使用してこの設定を指定できます。指定しない場合、設定がデフォルトの場所から選択されます。デフォルト設定の場所は XDG Base Directory Specification に準拠し、Unix システムおよび Windows システムの場合とは異なります。

Unix システムの場合: