Menu Close

Serverless

OpenShift Container Platform 4.9

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

概要

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

第1章 リリースノート

リリースノートには、新機能、非推奨機能、互換性を損なう変更、既知の問題に関する情報が記載されています。以下のリリースノートは、OpenShift Container Platform 上の最新の OpenShift Serverless リリースに適用されます。

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

注記

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

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

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

API バージョンは、OpenShift Serverless の特定の機能およびカスタムリソースの開発状況を示す重要な指標です。正しい API バージョンを使用していないリソースをクラスター上に作成すると、デプロイメントで問題が発生する可能性があります。

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

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

1.2. 一般提供およびテクノロジープレビュー機能

一般提供 (GA) の機能は完全にサポートされており、実稼働での使用に適しています。テクノロジープレビュー (TP) 機能は実験的な機能であり、本番環境での使用を目的としたものではありません。TP 機能の詳細については、Red Hat Customer Portal の Technology Preview のサポート範囲 を参照してください。

次の表は、どの OpenShift Serverless 機能が GA であり、どの機能が TP であるかに関する情報を提供します。

表1.1 一般提供およびテクノロジープレビュー機能トラッカー

機能1.231.24

kn func

TP

TP

kn func invoke

TP

TP

サービスメッシュ mTLS

GA

GA

emptyDir ボリューム

GA

GA

HTTPS リダイレクト

GA

GA

Kafka ブローカー

TP

TP

Kafka シンクコ

TP

TP

Knative サービスの init コンテナーのサポート

TP

GA

Knative サービスの PVC サポート

TP

TP

1.3. 非推奨および削除された機能

以前のリリースで一般提供 (GA) またはテクノロジープレビュー (TP) であった一部の機能は、非推奨または削除されました。非推奨の機能は依然として OpenShift Serverless に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Serverless で非推奨となり、削除された主な機能の最新の一覧については、以下の表を参照してください。

表1.2 非推奨および削除機能のトラッカー

機能1.201.211.221.231.24

KafkaBinding API

非推奨

非推奨

廃止

廃止

廃止

kn func emit (1.21+ではkn func invoke)

非推奨

廃止

廃止

廃止

廃止

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

OpenShift Serverless 1.24.0 が公開されました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。

1.4.1. 新機能

  • OpenShift Serverless は Knative Serving 1.3 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 1.3 を使用するようになりました。
  • OpenShift Serverless は Kourier 1.3 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 1.3 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 1.3 を使用するようになりました。
  • kn func CLI プラグインは func 0.24 を使用するようになりました。
  • Knative サービスの init コンテナーのサポートが一般に利用可能(GA)になりました。
  • OpenShift Serverless ロジックが開発者プレビューとして利用可能になりました。これにより、サーバーレスアプリケーションを管理するための宣言型ワークフローモデルを定義できます。
  • OpenShift Serverless でコスト管理サービスを使用できるようになりました。

1.4.2. 修正された問題

  • OpenShift Serverless と Red Hat OpenShift Service Mesh を統合すると、クラスターにシークレットの数が多すぎると、net-istio-controller Pod が起動時にメモリーが不足します。

    シークレットのフィルタリングを有効化できるようになりました。これにより、net-istio-controllernetworking.internal.knative.dev/certificate-uid ラベルの付いたシークレットのみを考慮し、必要なメモリー量を減らすことができます。

  • OpenShift Serverless Functions テクノロジープレビューは、デフォルトで Cloud Native Buildpacks を使用してコンテナーイメージをビルドできるようになりました。

1.4.3. 既知の問題

  • 連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっています。
  • OpenShift Serverless 1.23 では、KafkaBinding および kafka-binding Webhook のサポートが削除されました。ただし、既存の kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration は残り、存在しない kafka-source-webhook サービスを参照する可能性があります。

    クラスター上の KafkaBinding の特定の仕様については、kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration が Webhook 経由で 作成 および 更新 イベントを各種リソースに渡すように設定できます。

    この問題を回避するには、OpenShift Serverless 1.23 へのアップグレード後に kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration を手動でクラスターから削除します。

    $ oc delete mutatingwebhookconfiguration kafkabindings.webhook.kafka.sources.knative.dev

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

OpenShift Serverless 1.23.0 が公開されました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。

1.5.1. 新機能

  • OpenShift Serverless は Knative Serving 1.2 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 1.2 を使用するようになりました。
  • OpenShift Serverless は Kourier 1.2 を使用するようになりました。
  • OpenShift Serverless は Knative(kn)CLI 1.2 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 1.2 を使用するようになりました。
  • kn func CLI プラグインは func 0.24 を使用するようになりました。
  • Kafka ブローカーで kafka.eventing.knative.dev/external.topic アノテーションを使用できるようになりました。このアノテーションを使用すると、ブローカー自体の内部トピックを作成する代わりに、既存の外部管理トピックを使用できます。
  • kafka-ch-controller および kafka-webhook Kafka コンポーネントが存在しなくなりました。これらのコンポーネントは kafka-webhook-eventing コンポーネントに置き換えられました。
  • OpenShift Serverless Functions Technology Preview は、デフォルトで Source-to-Image (S2I) を使用してコンテナーイメージをビルドするようになりました。

1.5.2. 既知の問題

  • 連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっています。
  • Kafka ブローカーを含む名前空間を削除する場合、ブローカーの auth.secret.ref.name シークレットがブローカーの前に削除されると、名前空間ファイナライザーが削除されない可能性があります。
  • 多数の Knative サービスで OpenShift Serverless を実行すると、Knative アクティベーター Pod がデフォルトのメモリー制限である 600MB 近くで実行される可能性があります。これらの Pod は、メモリー消費がこの制限に達すると再起動される可能性があります。アクティベーターデプロイメントの要求と制限は、KnativeServing カスタムリソースを変更することで設定できます。

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      deployments:
      - name: activator
        resources:
        - container: activator
          requests:
            cpu: 300m
            memory: 60Mi
          limits:
            cpu: 1000m
            memory: 1000Mi
  • 関数のローカルビルド戦略として CloudNativeBuildpack を使用している場合、kn func は podman を自動的に起動したり、リモートデーモンへの SSH トンネルを使用したりすることはできません。これらの問題の回避策は、関数をデプロイする前に、ローカル開発コンピューターで Docker または podman デーモンを既に実行していることです。
  • 現時点で、クラスター上の関数ビルドが Quarkus および Golang ランタイムで失敗します。これらは Node、Typescript、Python、および Springboot ランタイムで正常に機能します。

関連情報

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

OpenShift Serverless 1.22.0 が公開されました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。

1.6.1. 新機能

  • OpenShift Serverless は Knative Serving 1.1 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 1.1 を使用するようになりました。
  • OpenShift Serverless は Kourier 1.1 を使用するようになりました。
  • OpenShift Serverless は Knative(kn)CLI 1.1 を使用するようになりました。
  • OpenShift Serverless は KnativeKafka1.1 を使用するようになりました。
  • kn func CLI プラグインは func 0.23 を使用するようになりました。
  • Knative サービスの初期コンテナーサポートがテクノロジープレビューとして利用できるようになりました。
  • Knative サービスの永続ボリュームクレーム (PVC) サポートが、テクノロジープレビューとして利用できるようになりました。
  • knative-servingknative-serving-ingressknative-eventing、および knative-kafka システムネームボックスに、デフォルトで knative.openshift.io/part-of:"openshift-serverless" ラベルが付けられるようになりました。
  • Knative Eventing-Kafka Broker/Trigger ダッシュボードが追加されました。これにより、Web コンソールで Kafka ブローカーとトリガーメトリックを視覚化できます。
  • Knative Eventing-KafkaSink ダッシュボードが追加されました。これにより、Web コンソールで KafkaSink メトリックを視覚化できます。
  • Knative Eventing-Broker/Trigger ダッシュボードは、Knative Eventing-Channel-based Broker/Trigger と呼ばれるようになりました。
  • knative.openshift.io/part-of: " openshift-serverless " ラベルが、knative.openshift.io/system-namespace ラベルに置き換わりました。
  • Knative Serving YAML 設定ファイルの命名スタイルがキャメルケース (ExampleName) からハイフンスタイル (example-name) に変更されました。このリリース以降、Knative Serving YAML 設定ファイルを作成または編集するときは、ハイフンスタイルの表記を使用してください。

1.6.2. 既知の問題

  • 連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっています。

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

OpenShift Serverless 1.21.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。

1.7.1. 新機能

  • OpenShift Serverless は Knative Serving 1.0 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 1.0 を使用するようになりました。
  • OpenShift Serverless は Kourier 1.0 を使用するようになりました。
  • OpenShift Serverless は Knative(kn)CLI 1.0 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 1.0 を使用するようになりました。
  • kn func CLI プラグインは func 0.21 を使用するようになりました。
  • Kafka シンクがテクノロジープレビューとして利用できるようになりました。
  • Knative オープンソースプロジェクトは、camel-cased 設定キーを廃止し、kebab-cased キーを一貫して使用することを支持し始めました。その結果、OpenShift Serverless 1.18.0 リリースノートで前述した defaultExternalScheme キーは非推奨になり、default-external-scheme キーに置き換えられました。キーの使用方法は同じです。

1.7.2. 修正された問題

  • OpenShift Serverless 1.20.0 では、サービスにイベントを送信するための kn event send の使用に影響するイベント配信の問題がありました。この問題は修正されています。
  • OpenShift Serverless 1.20.0 (func0.20) では、http テンプレートを使用して作成された TypeScript 関数をクラスターにデプロイできませんでした。この問題は修正されています。
  • OpenShift Serverless 1.20.0 (func 0.20) では、gcr.io レジストリーを使用した関数のデプロイがエラーで失敗しました。この問題は修正されています。
  • OpenShift Serverless 1.20.0 (func 0.20) では、kn func create コマンドを使用して Springboot 関数プロジェクトディレクトリーを作成してから、kn func build コマンドを実行するとエラーメッセージが表示されて失敗しました。この問題は修正されています。
  • OpenShift Serverless 1.19.0 (func 0.19) では、一部のランタイムが podman を使用して関数をビルドできませんでした。この問題は修正されています。

1.7.3. 既知の問題

  • 現在、ドメインマッピングコントローラーは、現在サポートされていないパスを含むブローカーの URI を処理できません。

    つまり、DomainMapping カスタムリソース (CR) を使用してカスタムドメインをブローカーにマップする場合は、ブローカーの入力サービスを使用して DomainMapping CR を設定し、ブローカーの正確なパスをカスタムドメインに追加する必要があります。

    DomainMappingCR の例

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
      name: <domain-name>
      namespace: knative-eventing
    spec:
      ref:
        name: broker-ingress
        kind: Service
        apiVersion: v1

    その場合、ブローカーの URI は <domain-name>/<broker-namespace>/<broker-name> になります。

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

OpenShift Serverless 1.20.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。

1.8.1. 新機能

  • OpenShift Serverless は Knative Serving 0.26 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.26 を使用するようになりました。
  • OpenShift Serverless は Kourier 0.26 を使用するようになりました。
  • OpenShift Serverless は Knative(kn)CLI 0.26 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.26 を使用するようになりました。
  • kn func CLI プラグインは func 0.20 を使用するようになりました。
  • Kafka ブローカーがテクノロジープレビュー機能として利用可能になりました。

    重要

    現在テクノロジープレビューにある Kafka ブローカーは、FIPS ではサポートされていません。

  • kn event プラグインがテクノロジープレビュー機能として利用可能になりました。
  • knservicecreate コマンドの --min-scale フラグと --max-scale フラグは廃止されました。代わりに、-scale-min フラグと --scale-max フラグを使用してください。

1.8.2. 既知の問題

  • OpenShift Serverless は、HTTPS を使用するデフォルトアドレスで Knative サービスをデプロイします。クラスター内のリソースにイベントを送信する場合、送信側にはクラスターの認証局(CA)が設定されていません。これにより、クラスターがグローバルに受け入れ可能な証明書を使用しない限り、イベント配信は失敗します。

    たとえば、一般にアクセス可能なアドレスへのイベント配信は機能します。

    $ kn event send --to-url https://ce-api.foo.example.com/

    一方、サービスがカスタム CA によって発行された HTTPS 証明書でパブリックアドレスを使用する場合、この配信は失敗します。

    $ kn event send --to Service:serving.knative.dev/v1:event-display

    ブローカーやチャネルなどの他のアドレス指定可能なオブジェクトへのイベント送信は、この問題の影響を受けず、期待どおりに機能します。

  • 現在、Kafka ブローカーは Federal Information Processing Standards (FIPS)モードが有効になっているクラスターでは動作しません。
  • kn func create コマンドで Springboot 関数プロジェクトディレクトリーを作成する場合、それ以降のkn func build コマンドの実行は、以下のエラーメッセージと共に失敗します。

    [analyzer] no stack metadata found at path ''
    [analyzer] ERROR: failed to : set API for buildpack 'paketo-buildpacks/ca-certificates@3.0.2': buildpack API version '0.7' is incompatible with the lifecycle

    回避策として、関数設定ファイル func.yamlbuilder プロパティーを gcr.io/paketo-buildpacks/builder:base に変更します。

  • gcr.io レジストリーを使用した関数のデプロイは、以下のエラーメッセージと共に失敗します。

    Error: failed to get credentials: failed to verify credentials: status code: 404

    回避策として、quay.io または docker.io などの gcr.io 以外のレジストリーを使用します。

  • http テンプレートで作成された Typescript 関数は、クラスターへのデプロイに失敗します。

    回避策として、func.yaml ファイルで以下のセクションを置き換えます。

    buildEnvs: []

    上記を以下のように置き換えます。

    buildEnvs:
    - name: BP_NODE_RUN_SCRIPTS
      value: build
  • func バージョン 0.20 では、一部のランタイムが podman を使用して関数をビルドできない場合があります。以下のようなエラーメッセージが表示される場合があります。

    ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF
    • この問題には、以下の回避策があります。

      1. --time=0 をサービス ExecStart 定義に追加して、podman サービスを更新します。

        サービス設定の例

        ExecStart=/usr/bin/podman $LOGGING system service --time=0

      2. 以下のコマンドを実行して podman サービスを再起動します。

        $ systemctl --user daemon-reload
        $ systemctl restart --user podman.socket
    • または、TCP を使用して podman API を公開することもできます。

      $ podman system service --time=0 tcp:127.0.0.1:5534 &
      export DOCKER_HOST=tcp://127.0.0.1:5534

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

OpenShift Serverless 1.19.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。

1.9.1. 新機能

  • OpenShift Serverless は Knative Serving 0.25 を使用するようになりました。
  • OpenShift Serverless は Knative Eventing 0.25 を使用するようになりました。
  • OpenShift Serverless は Kourier 0.25 を使用するようになりました。
  • OpenShift Serverless は Knative(kn)CLI 0.25 を使用するようになりました。
  • OpenShift Serverless は Knative Kafka 0.25 を使用するようになりました。
  • kn func CLI プラグインは func 0.19 を使用するようになりました。
  • KafkaBinding API は OpenShift Serverless 1.19.0 で非推奨となり、今後のリリースで廃止される予定です。
  • HTTPS リダイレクトがサポートされ、クラスターに対してグローバルに設定することも、各 Knative サービスごとに設定することもできるようになりました。

1.9.2. 修正された問題

  • 以前のリリースでは、Kafka チャネルディスパッチャーは、ローカルコミットが成功するのを待ってからしか応答していませんでした。これにより、Apache Kafka ノードに障害が発生した場合に、イベントが失われる可能性がありました。Kafka チャネルディスパッチャーは、すべての同期レプリカがコミットするのを待ってから応答するようになりました。

1.9.3. 既知の問題

  • func バージョン 0.19 では、一部のランタイムが podman を使用して関数をビルドできない場合があります。以下のようなエラーメッセージが表示される場合があります。

    ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF
    • この問題には、以下の回避策があります。

      1. --time=0 をサービス ExecStart 定義に追加して、podman サービスを更新します。

        サービス設定の例

        ExecStart=/usr/bin/podman $LOGGING system service --time=0

      2. 以下のコマンドを実行して podman サービスを再起動します。

        $ systemctl --user daemon-reload
        $ systemctl restart --user podman.socket
    • または、TCP を使用して podman API を公開することもできます。

      $ podman system service --time=0 tcp:127.0.0.1:5534 &
      export DOCKER_HOST=tcp://127.0.0.1:5534

1.10. Red Hat OpenShift Serverless 1.18.0 のリリースノート

OpenShift Serverless 1.18.0 が利用可能になりました。以下では、OpenShift Container Platform 上のOpenShift Serverless に関連する新機能、変更点および既知の問題について説明します。

1.10.1. 新機能

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

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

    ...
    spec:
      config:
        network:
          defaultExternalScheme: "http"
    ...

    変更を 1.18.0 ですでに適用する必要がある場合には、以下の YAML を追加します。

    ...
    spec:
      config:
        network:
          defaultExternalScheme: "https"
    ...
  • 今後の OpenShift Serverless 1.19.0 リリースでは、Kourier ゲートウェイが公開されるデフォルトのサービスタイプは ClusterIP であり、LoadBalancer ではありません。

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

    ...
    spec:
      ingress:
        kourier:
          service-type: LoadBalancer
    ...
  • OpenShift Serverless で emptyDir ボリュームを使用できるようになりました。詳細は、Knative Serving に関する OpenShift Serverless ドキュメントを参照してください。
  • kn func を使用して関数を作成すると、Rust テンプレートが利用できるようになりました。

1.10.2. 修正された問題

  • 以前の 1.4 バージョンの Camel-K は OpenShift Serverless 1.17.0 と互換性がありませんでした。Camel-K の問題が修正され、Camel-K バージョン 1.4.1 を OpenShift Serverless 1.17.0 で使用できます。
  • 以前のバージョンでは、Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。

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

    OpenShift Serverless 1.18.0 では、問題が修正され、初期メッセージが失われなくなりました。この問題の詳細は、ナレッジベースの記事 #6343981 を参照してください。

1.10.3. 既知の問題

  • Knative kn CLI の古いバージョンは、Knative Serving および Knative Eventing API の古いバージョンを使用する可能性があります。たとえば、kn CLI のバージョン 0.23.2 は v1alpha1 API バージョンを使用します。

    一方、OpenShift Serverless の新しいリリースでは、古い API バージョンをサポートしない可能性があります。たとえば、OpenShift Serverless 1.18.0 は kafkasources.sources.knative.dev API のバージョン v1alpha1 をサポートしなくなりました。

    そのため、kn が古い API を検出できないため、新しい OpenShift Serverless で古いバージョンの Knative kn CLI を使用するとエラーが発生する可能性がありました。たとえば、kn CLI のバージョン 0.23.2 は OpenShift Serverless 1.18.0 では機能しません。

    問題を回避するには、OpenShift Serverless リリースで利用可能な最新の kn CLI バージョンを使用します。OpenShift Serverless 1.18.0 については、Knative kn CLI 0.24.0 を使用します。

第2章 発見

2.1. OpenShift Serverless について

OpenShift Serverless は、Kubernetes ネイティブなビルディングブロックを提供します。開発者はこれらを使用して、OpenShift Container Platform 上でサーバーレスのイベント駆動型アプリケーションを作成およびデプロイできます。OpenShift Serverless はオープンソースの Knative プロジェクトをベースとし、エンタープライズレベルのサーバーレスプラットフォームを有効にすることで、ハイブリッドおよびマルチクラウド環境に対して移植性と一貫性をもたらします。

2.1.1. Knative Serving

Knative Serving は、クラウドネイティブアプリケーション の作成、デプロイ、管理を希望する開発者をサポートします。これにより、オブジェクトのセットがOpenShift Container Platform クラスター上のサーバーレスワークロードの動作を定義し制御する Kubernetes カスタムリソース定義 (CRD) として提供されます。

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

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

2.1.1.1. Knative Serving リソース

サービス
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 は、デプロイメントの必要な状態を維持します。これにより、コードと設定を明確に分離できます。設定を変更すると、新規リビジョンが作成されます。

2.1.2. Knative Eventing

OpenShift Container Platform 上の Knative Eventing を使用すると、開発者はサーバーレスアプリケーションと共に イベント駆動型のアーキテクチャー を使用できます。イベント駆動型のアーキテクチャーは、イベントプロデューサーとイベントコンシューマー間の関係を切り離すという概念に基づいています。

イベントプロデューサーはイベントを作成し、イベントシンクまたはコンシューマーはイベントを受信します。Knative Eventing は、標準の HTTP POST リクエストを使用してイベントプロデューサーとシンク間でイベントを送受信します。これらのイベントは CloudEvents 仕様 に準拠しており、すべてのプログラミング言語でのイベントの作成、解析、および送受信を可能にします。

Knative Eventing は以下のユースケースをサポートします。

コンシューマーを作成せずにイベントを公開する
イベントを HTTP POST としてブローカーに送信し、バインディングを使用してイベントを生成するアプリケーションから宛先設定を分離できます。
パブリッシャーを作成せずにイベントを消費
Trigger を使用して、イベント属性に基づいて Broker からイベントを消費できます。アプリケーションはイベントを HTTP POST として受信します。

複数のタイプのシンクへの配信を有効にするために、Knative Eventing は複数の Kubernetes リソースで実装できる以下の汎用インターフェースを定義します。

アドレス指定可能なリソース
HTTP 経由でイベントの status.address.url フィールドに定義されるアドレスに配信されるイベントを受信し、確認することができます。Kubernetes Service リソースはアドレス指定可能なインターフェースにも対応します。
呼び出し可能なリソース
HTTP 経由で配信されるイベントを受信し、これを変換できます。HTTP 応答ペイロードで 0 または 1 の新規イベントを返します。返されるイベントは、外部イベントソースからのイベントが処理されるのと同じ方法で処理できます。

以下を使用して、イベントをイベントソースから複数のイベントシンクに伝播できます。

2.1.3. サポートされる構成

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

2.1.4. スケーラビリティーおよびパフォーマンス

OpenShift Serverless は、3 つのメインノードと 3 つのワーカーノードの設定でテストされています。各ノードには、64 個の CPU、457 GB のメモリー、および 394 GB のストレージがあります。

この設定を使用して作成できる Knative サービスの最大数は 3,000 です。これは、OpenShift Container Platform の Kubernetes サービスの制限である 10,000 に相当します。これは、1 つの Knative サービスが 3 つの Kubernetes サービスを作成するためです。

ゼロ応答時間からの平均スケールは約 3.4 秒で、最大応答時間は 8 秒で、単純な Quarkus アプリケーションの 99.9 パーセンタイルは 4.5 秒でした。これらの時間は、アプリケーションとアプリケーションの実行時間によって異なる場合があります。

2.1.5. 関連情報

2.2. OpenShift Serverless Functions について

OpenShift Serverless Functions により、開発者は OpenShift Container Platform で Knative サービスとしてステートレスでイベント駆動型の関数を作成およびデプロイできます。kn func CLI は Knative kn CLI のプラグインとして提供されます。kn func CLI を使用して、コンテナーイメージをクラスターで Knative サービスとして作成、ビルド、およびデプロイできます。

重要

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

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

2.2.1. 含まれるランタイム

OpenShift Serverless Functions は、以下のランタイムの基本機能を作成するために使用できるテンプレートを提供します。

2.2.2. 次のステップ

2.3. イベントソース

Knative イベントソース には、クラウドイベントの生成またはインポート、これらのイベントの別のエンドポイントへのリレー (sink とも呼ばれる) を行う Kubernetes オブジェクトを指定できます。イベントに対応する分散システムを開発するには、イベントのソースが重要になります。

OpenShift Container Platform Web コンソール、Knative(kn)CLI の Developer パースペクティブを使用するか、または YAML ファイルを適用して Knative イベントソースを作成および管理できます。

現時点で、OpenShift Serverless は以下のイベントソースタイプをサポートします。

API サーバーソース
Kubernetes API サーバーイベントを Knative に送ります。API サーバーソースは、Kubernetes リソースが作成、更新、または削除されるたびに新規イベントを送信します。
Ping ソース
指定された cron スケジュールに、固定ペイロードを使用してイベントを生成します。
Kafka イベントソース
Kafka クラスターをイベントソースとしてシンクに接続します。

カスタムイベントソース を作成することもできます。

2.4. チャネルおよびサブスクリプション

チャネルは、単一のイベント転送および永続レイヤーを定義するカスタムリソースです。イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。

チャネルワークフローの概要

サポートされている Channel オブジェクトをインスタンス化することでチャネルを作成し、Subscription オブジェクトの delivery 仕様を変更して再配信の試行を設定できます。

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 チャネルが作成されます。

バッキングチャネルは、サブスクリプションをユーザー作成のチャネルオブジェクトにコピーし、ユーザー作成チャネルオブジェクトのステータスを、バッキングチャネルのステータスを反映するように設定します。

2.4.1. チャネルの実装タイプ

InMemoryChannel および KafkaChannel チャネルの実装は、開発目的で OpenShift Serverless で使用できます。

以下は、InMemoryChannel タイプのチャネルの制限です。

  • イベントの永続性は利用できません。Pod がダウンすると、その Pod のイベントが失われます。
  • InMemoryChannel チャネルはイベントの順序を実装しないため、チャネルで同時に受信される 2 つのイベントはいずれの順序でもサブスクライバーに配信できます。
  • サブスクライバーがイベントを拒否する場合、再配信はデフォルトで試行されません。Subscription オブジェクトの delivery 仕様を変更することで、再配信の試行を設定できます。

Kafka チャネルの詳細は、Knative Kafka のドキュメントを参照してください。

2.4.2. 次のステップ

第3章 インストール

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

OpenShift Serverless Operator をインストールすると、OpenShift Container Platform クラスターに Knative Serving、Knative Eventing、Knative Kafka をインストールして使用することができます。OpenShift Serverless Operator は、クラスターの Knative カスタムリソース定義 (CRD) を管理し、各コンポーネントの個別の設定マップを直接修正することなくそれらを設定できるようにします。

3.1.1. 作業を開始する前に

OpenShift Serverless をインストールする前に、サポートされる構成および前提条件についての以下の情報を確認してください。

  • OpenShift Serverless は、ネットワークが制限された環境でのインストールに対してサポートされません。
  • 現時点で、OpenShift Serverless は単一クラスター上でのマルチテナント設定で使用することはできません。

3.1.1.1. クラスターサイズ要件の定義

OpenShift Serverless をインストールし、使用するには、OpenShift Container Platform クラスターのサイズを適切に設定する必要があります。OpenShift Serverless を実行するために必要な総サイズは、インストールされているコンポーネントとデプロイされているアプリケーションに依存し、デプロイメントによって異なる場合があります。

注記

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

デフォルトで、各 Pod は約 400m の CPU を要求し、推奨値のベースはこの値になります。アプリケーションの実際の CPU 要求を減らすと、レプリカ数が増える可能性があります。

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

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

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

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

OpenShift Container Platform Web コンソールを使用して、OperatorHub から OpenShift Serverless Operator をインストールできます。この Operator をインストールすることで、Knative コンポーネントをインストールして使用することができます。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift Container Platform Web コンソールにログインしている。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. スクロールするか、またはこれらのキーワード ServerlessFilter by keyword ボックス に入力して OpenShift Serverless Operator を検索します。
  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 のログで確認できます。
重要

OpenShift Serverless で Red Hat 分散トレースを使用する 場合は、KnativeServing または KnativeEventing をインストールする前に、Red Hat 分散トレースをインストールして設定する必要があります。

3.1.3. 関連情報

3.1.4. 次のステップ

3.2. Knative Serving のインストール

Knative Serving をインストールすると、クラスター上で Knative サービスや関数を作成することができます。また、オートスケーリングやネットワークオプションなどの追加機能をアプリケーションに利用することも可能です。

OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Serving をインストールするか、KnativeServing カスタムリソース (CR) でより高度な設定を行うことが可能です。KnativeServing CR の設定オプションの詳細については、グローバル設定を参照してください。

重要

OpenShift Serverless で Red Hat 分散トレースを使用する 場合は、KnativeServing をインストールする前に、Red Hat 分散トレースをインストールして設定する必要があります。

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

OpenShift Serverless Operator をインストールした後、OpenShift Container Platform の Web コンソールを使用して Knative Serving をインストールします。デフォルトの設定で Knative Serving をインストールするか、KnativeServing カスタムリソース (CR) でより詳細な設定を行うことが可能です。

前提条件

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

手順

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

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

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

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

      注記

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

  6. Knative Serving のインストール後に、KnativeServing オブジェクトが作成され、Knative Serving タブに自動的にダイレクトされます。リソースの一覧に knative-serving カスタムリソースが表示されます。

検証

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

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

    条件
    注記

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

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

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

OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Serving をインストールするか、KnativeServing カスタムリソース (CR) でより高度な設定を行うことが可能です。YAML ファイルとoc CLI を利用して、以下の手順で Knative Serving をインストールすることができます。

前提条件

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

手順

  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 リソースが作成されるまでに数分の時間がかかる場合があります。

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

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

    $ oc get pods -n knative-serving

    出力例

    NAME                                                        READY   STATUS      RESTARTS   AGE
    activator-67ddf8c9d7-p7rm5                                  2/2     Running     0          4m
    activator-67ddf8c9d7-q84fz                                  2/2     Running     0          4m
    autoscaler-5d87bc6dbf-6nqc6                                 2/2     Running     0          3m59s
    autoscaler-5d87bc6dbf-h64rl                                 2/2     Running     0          3m59s
    autoscaler-hpa-77f85f5cc4-lrts7                             2/2     Running     0          3m57s
    autoscaler-hpa-77f85f5cc4-zx7hl                             2/2     Running     0          3m56s
    controller-5cfc7cb8db-nlccl                                 2/2     Running     0          3m50s
    controller-5cfc7cb8db-rmv7r                                 2/2     Running     0          3m18s
    domain-mapping-86d84bb6b4-r746m                             2/2     Running     0          3m58s
    domain-mapping-86d84bb6b4-v7nh8                             2/2     Running     0          3m58s
    domainmapping-webhook-769d679d45-bkcnj                      2/2     Running     0          3m58s
    domainmapping-webhook-769d679d45-fff68                      2/2     Running     0          3m58s
    storage-version-migration-serving-serving-0.26.0--1-6qlkb   0/1     Completed   0          3m56s
    webhook-5fb774f8d8-6bqrt                                    2/2     Running     0          3m57s
    webhook-5fb774f8d8-b8lt5                                    2/2     Running     0          3m57s

  3. 必要なネットワークコンポーネントが、自動的に作成された knative-serving-ingress namespace にインストールされていることを確認します。

    $ oc get pods -n knative-serving-ingress

    出力例

    NAME                                      READY   STATUS    RESTARTS   AGE
    net-kourier-controller-7d4b6c5d95-62mkf   1/1     Running   0          76s
    net-kourier-controller-7d4b6c5d95-qmgm2   1/1     Running   0          76s
    3scale-kourier-gateway-6688b49568-987qz   1/1     Running   0          75s
    3scale-kourier-gateway-6688b49568-b5tnp   1/1     Running   0          75s

3.2.3. 次のステップ

3.3. Knative Eventing のインストール

クラスターでイベント駆動型アーキテクチャーを使用するには、Knative Eventing をインストールします。イベントソース、ブローカー、チャネルなどの Knative コンポーネントを作成し、それらを使用してアプリケーションや外部システムにイベントを送信することができます。

OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Eventing をインストールするか、KnativeEventing カスタムリソース (CR) でより高度な設定を行うことが可能です。KnativeEventing CR の設定オプションの詳細については、グローバル設定 を参照してください。

重要

OpenShift Serverless で Red Hat 分散トレースを使用する 場合は、Knative Eventing をインストールする前に、Red Hat 分散トレースをインストールして設定する必要があります。

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

OpenShift Serverless Operator をインストールした後、OpenShift Container Platform の Web コンソールを使用して Knative Eventing をインストールします。デフォルトの設定で Knative Eventing をインストールするか、KnativeEventing カスタムリソース (CR) でより詳細な設定を行うことが可能です。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorsInstalled Operators に移動します。
  2. ページ上部の Project ドロップダウンメニューが Project: knative-eventing に設定されていることを確認します。
  3. OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。
  4. Create Knative Eventing をクリックします。
  5. Create Knative Eventing ページでは、提供されるデフォルトのフォームを使用するか、または YAML を編集して KnativeEventing オブジェクトを設定できます。

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

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

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

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

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

  7. Create をクリックします。
  8. Knative Eventing のインストール後に、KnativeEventing オブジェクトが作成され、Knative Eventing タブに自動的にダイレクトされます。リソースの一覧に knative-eventing リソースが表示されます。

検証

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

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

    条件
    注記

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

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

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

OpenShift Serverless Operator をインストールした後、デフォルトの設定で Knative Eventing をインストールするか、KnativeEventing カスタムリソース (CR) でより高度な設定を行うことが可能です。YAML ファイルと oc CLI を利用して、以下の手順で Knative Eventing をインストールすることができます。

前提条件

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

手順

  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

3.3.3. 次のステップ

  • Knative サービスを使用する場合は、Knative Serving をインストールできます。

3.4. OpenShift Serverless の削除

必要に応じて OpenShift Serverless をクラスターから削除するには、OpenShift Serverless Operator およびその他の OpenShift Serverless コンポーネントを手動で削除します。OpenShift Serverless Operator を削除する前に、Knative Serving および Knative Eventing を削除する必要があります。

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

OpenShift Serverless Operator を削除する前に、Knative Serving を削除する必要があります。Knative Serving をアンインストールするには、KnativeServing カスタムリソース (CR) を削除してから knative-serving namespace を削除する必要があります。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) をインストールします。

手順

  1. KnativeServing CR を削除します。

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

    $ oc delete namespace knative-serving

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

OpenShift Serverless Operator を削除する前に、Knative Eventing を削除する必要があります。Knative Eventing をアンインストールするには、KnativeEventing カスタムリソース (CR) を削除してから knative-eventing namespace を削除する必要があります。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) をインストールします。

手順

  1. KnativeEventing CR を削除します。

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

    $ oc delete namespace knative-eventing

3.4.3. OpenShift Serverless Operator の削除

Knative Serving と Knative Eventing を削除した後、OpenShift Serverless Operator を削除することができます。これは、OpenShift Container Platform の Web コンソールまたは oc CLI を使用して行うことができます。

3.4.3.1. Web コンソールの使用によるクラスターからの Operator の削除

クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operator を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスター Web コンソールにアクセスできること。

手順

  1. OperatorsInstalled Operators ページに移動します。
  2. スクロールするか、またはキーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。
  3. Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。

    Uninstall Operator? ダイアログボックスが表示されます。

  4. Uninstall を選択し、Operator、Operator デプロイメント、および Pod を削除します。このアクションの後には、Operator は実行を停止し、更新を受信しなくなります。

    注記

    このアクションは、カスタムリソース定義(CRD)およびカスタムリソース(CR)など、Operator が管理するリソースは削除されません。Web コンソールおよび継続して実行されるクラスター外のリソースによって有効にされるダッシュボードおよびナビゲーションアイテムには、手動でのクリーンアップが必要になる場合があります。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。

3.4.3.2. CLI の使用によるクラスターからの Operator の削除

クラスター管理者は CLI を使用して、選択した namespace からインストールされた Operator を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできること。
  • oc コマンドがワークステーションにインストールされていること。

手順

  1. サブスクライブされた Operator (例: jaeger) の現行バージョンを currentCSV フィールドで確認します。

    $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV

    出力例

      currentCSV: jaeger-operator.v1.8.2

  2. サブスクリプション (例: jaeger) を削除します。

    $ oc delete subscription jaeger -n openshift-operators

    出力例

    subscription.operators.coreos.com "jaeger" deleted

  3. 直前の手順で currentCSV 値を使用し、ターゲット namespace の Operator の CSV を削除します。

    $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators

    出力例

    clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

3.4.3.3. 障害のあるサブスクリプションの更新

Operator Lifecycle Manager (OLM) で、ネットワークでアクセスできないイメージを参照する Operator をサブスクライブする場合、以下のエラーを出して失敗した openshift-marketplace namespace でジョブを見つけることができます。

出力例

ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

出力例

rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host

その結果、サブスクリプションはこの障害のある状態のままとなり、Operator はインストールまたはアップグレードを実行できません。

サブスクリプション、クラスターサービスバージョン (CSV) その他の関連オブジェクトを削除して、障害のあるサブスクリプションを更新できます。サブスクリプションを再作成した後に、OLM は Operator の正しいバージョンを再インストールします。

前提条件

  • アクセス不可能なバンドルイメージをプルできない障害のあるサブスクリプションがある。
  • 正しいバンドルイメージにアクセスできることを確認している。

手順

  1. Operator がインストールされている namespace から Subscription および ClusterServiceVersion オブジェクトの名前を取得します。

    $ oc get sub,csv -n <namespace>

    出力例

    NAME                                                       PACKAGE                  SOURCE             CHANNEL
    subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
    
    NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
    clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

  2. サブスクリプションを削除します。

    $ oc delete subscription <subscription_name> -n <namespace>
  3. クラスターサービスバージョンを削除します。

    $ oc delete csv <csv_name> -n <namespace>
  4. openshift-marketplace namespace の失敗したジョブおよび関連する設定マップの名前を取得します。

    $ oc get job,configmap -n openshift-marketplace

    出力例

    NAME                                                                        COMPLETIONS   DURATION   AGE
    job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
    
    NAME                                                                        DATA   AGE
    configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

  5. ジョブを削除します。

    $ oc delete job <job_name> -n openshift-marketplace

    これにより、アクセスできないイメージのプルを試行する Pod は再作成されなくなります。

  6. 設定マップを削除します。

    $ oc delete configmap <configmap_name> -n openshift-marketplace
  7. Web コンソールの OperatorHub を使用した Operator の再インストール

検証

  • Operator が正常に再インストールされていることを確認します。

    $ oc get sub,csv,installplan -n <namespace>

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

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

重要

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

前提条件

  • OpenShift CLI (oc) をインストールします。
  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • Knative Serving をアンインストールし、OpenShift Serverless Operator を削除している。

手順

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

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

第4章 Knative CLI

4.1. Knative CLI のインストール

Knative (kn) CLI には、独自のログインメカニズムがありません。クラスターにログインするには、OpenShift (oc) CLI をインストールし、oc login コマンドを使用する必要があります。CLI のインストールオプションは、オペレーティングシステムによって異なる場合があります。

ご使用のオペレーティングシステム用に OpenShift (oc) CLI をインストールする方法および oc でのログイン方法についての詳細は、OpenShift CLI の使用開始についてのドキュメントを参照してください。

Knative (kn) CLI を使用して OpenShift Serverless をインストールすることはできません。クラスター管理者は、OpenShift Serverless Operator のインストール のドキュメントで説明されているように、OpenShift Serverless Operator をインストールし、Knative コンポーネントをセットアップする必要があります。

重要

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

たとえば、バージョン 0.22.0 を使用する Knative (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 リリースの最新の Knative (kn) CLI バージョンを使用していることを確認してください。

4.1.1. OpenShift Container Platform Web コンソールを使用した Knative CLI のインストール

OpenShift Container Platform Web コンソールを使用すると、Knative (kn) CLI をインストールするための合理化された直感的なユーザーインターフェイスが提供されます。\OpenShift Serverless Operator をインストールすると、OpenShift Container PlatformWeb コンソールの コマンドラインツール ページから Linux (amd64、s390x、ppc64le)、macOS、または Windows 用の Knative (kn) CLI をダウンロードするためのリンクが表示されます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator が OpenShift Container Platform クラスターにインストールされている。

    重要

    libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

    $ kn: No such file or directory

手順

  1. Command Line Tools ページから Knative (kn) CLI をダウンロードします。Command Line Tools ページには、Web コンソールの右上の question circle アイコンをクリックして、リストの Command Line Tools を選択します。
  2. アーカイブを展開します。

    $ tar -xf <file>
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、以下を実行します。

    $ echo $PATH

4.1.2. RPM パッケージマネージャーを使用した Linux 用の Knative CLI のインストール

Red Hat Enterprise Linux (RHEL) の場合、yumdnf などのパッケージマネージャーを使用して、Knative (kn) CLI を RPM としてインストールできます。これにより、Knative CLI バージョンをシステムで自動的に管理できます。たとえば、dnf upgrade のようなコマンドを使用すると、新しいバージョンが利用可能な場合、kn を含むすべてのパッケージがアップグレードされます。

前提条件

  • お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがある。

手順

  1. Red Hat Subscription Manager に登録します。

    # subscription-manager register
  2. 最新のサブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 登録済みのシステムにサブスクリプションを添付します。

    # subscription-manager attach --pool=<pool_id> 1
    1
    有効な OpenShift Container Platform サブスクリプションのプール ID
  4. Knative (kn) CLI に必要なリポジトリーを有効にします。

    • Linux (x86_64, amd64)

      # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
    • Linux on IBM Z and LinuxONE (s390x)

      # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-s390x-rpms"
    • Linux on IBM Power (ppc64le)

      # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-ppc64le-rpms"
  5. パッケージマネージャーを使用して、Knative (kn) CLI を RPM としてインストールします。

    yum コマンドの例

    # yum install openshift-serverless-clients

4.1.3. Linux の Knative CLI のインストール

RPM または別のパッケージマネージャーがインストールされていない Linux ディストリビューションを使用している場合は、Knative (kn) CLI をバイナリーファイルとしてインストールできます。これを行うには、tar.gz アーカイブをダウンロードして解凍し、バイナリーを PATH のディレクトリーに追加する必要があります。

前提条件

  • RHEL または Fedora を使用していない場合は、ライブラリーパスのディレクトリーに libc がインストールされていることを確認してください。

    重要

    libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

    $ kn: No such file or directory

手順

  1. Knative (kn) CLI の tar.gz アーカイブをダウンロードします。

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

    $ tar -xf <filename>
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、以下を実行します。

    $ echo $PATH

4.1.4. macOS の Knative CLI のインストール

macOS を使用している場合は、Knative (kn) CLI をバイナリーファイルとしてインストールできます。これを行うには、tar.gz アーカイブをダウンロードして解凍し、バイナリーを PATH のディレクトリーに追加する必要があります。

手順

  1. Knative (kn) CLItar.gz アーカイブ をダウンロードします。
  2. アーカイブを解凍して解凍します。
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、ターミナルウィンドウを開き、以下を実行します。

    $ echo $PATH

4.1.5. Windows の Knative CLI のインストール

Windows を使用している場合は、Knative (kn) CLI をバイナリーファイルとしてインストールできます。これを行うには、ZIP アーカイブをダウンロードして解凍し、バイナリーを PATH のディレクトリーに追加する必要があります。

手順

  1. Knative (kn) CLIZIP アーカイブ をダウンロードします。
  2. ZIP プログラムでアーカイブを展開します。
  3. kn バイナリーを PATH にあるディレクトリーに移動します。
  4. PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

4.2. Knative CLI の設定

config.yaml 設定ファイルを作成することで、Knative (kn) CLI セットアップをカスタマイズできます。--config フラグを使用してこの設定を指定できます。指定しない場合、設定がデフォルトの場所から選択されます。デフォルトの設定場所は XDGBaseDirectory 仕様 に準拠しており、UNIX システムと Windows システムでは異なります。

UNIX システムの場合:

  • XDG_CONFIG_HOME 環境変数が設定されている場合、Knative (kn) CLI が検索するデフォルト設定の場所は $XDG_CONFIG_HOME/kn になります。
  • XDG_CONFIG_HOME 環境変数が設定されていない場合、Knative (kn) CLI は $HOME/.config/kn/config.yaml のユーザーのホームディレクトリーにある設定を検索します。

Windows システムの場合、デフォルトの Knative (kn) CLI 設定の場所は %APPDATA%\kn です。

設定ファイルのサンプル

plugins:
  path-lookup: true 1
  directory: ~/.config/kn/plugins 2
eventing:
  sink-mappings: 3
  - prefix: svc 4
    group: core 5
    version: v1 6
    resource: services 7

1
Knative (kn) CLI が PATH 環境変数でプラグインを検索するかどうかを指定します。これはブール型の設定オプションです。デフォルト値は false です。
2
Knative (kn) CLI がプラグインを検索するディレクトリーを指定します。前述のように、デフォルトのパスはオペレーティングシステムによって異なります。これには、ユーザーに表示される任意のディレクトリーを指定できます。
3
sink-mappings 仕様は、Knative (kn) CLI コマンドで --sink フラグを使用する場合に使用される Kubernetes のアドレス可能なリソースを定義します。
4
シンクの記述に使用するプレフィックス。サービスの svcchannel、および broker は Knative (kn) CLI で事前に定義されるプレフィックスです。
5
Kubernetes リソースの API グループ。
6
Kubernetes リソースのバージョン。
7
Kubernetes リソースタイプの複数形の名前。例: services または brokers

4.3. Knative CLI プラグイン

Knative (kn) CLI は、プラグインの使用をサポートします。これにより、カスタムコマンドとコアディストリビューションの一部ではない他の共有コマンドを追加でき、kn インストールの機能の拡張を可能にします。Knative (kn) CLI プラグインは主な kn 機能として同じ方法で使用されます。

現在、Red Hat は kn-source-kafka プラグインと kn-event プラグインをサポートしています。

重要

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

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

4.3.1. kn-event プラグインを使用してイベントを作成する

kn event build コマンドのビルダーのようなインターフェースを使用して、イベントをビルドできます。その後、そのイベントを後で送信するか、別のコンテキストで使用できます。

前提条件

  • Knative (kn) CLI をインストールしている。

手順

  • イベントをビルドします。

    $ kn event build --field <field-name>=<value> --type <type-name> --id <id> --output <format>

    ここで、

    • --field フラグは、データをフィールド/値のペアとしてイベントに追加します。これは複数回使用できます。
    • --type フラグを使用すると、イベントのタイプを指定する文字列を指定できます。
    • --id フラグは、イベントの ID を指定します。
    • json または yaml 引数を --output フラグと共に使用して、イベントの出力形式を変更できます。

      これらのフラグはすべてオプションです。

      簡単なイベントのビルド

      $ kn event build -o yaml

      YAML 形式のビルドされたイベント

      data: {}
      datacontenttype: application/json
      id: 81a402a2-9c29-4c27-b8ed-246a253c9e58
      source: kn-event/v0.4.0
      specversion: "1.0"
      time: "2021-10-15T10:42:57.713226203Z"
      type: dev.knative.cli.plugin.event.generic

      サンプルトランザクションイベントのビルド

      $ kn event build \
          --field operation.type=local-wire-transfer \
          --field operation.amount=2345.40 \
          --field operation.from=87656231 \
          --field operation.to=2344121 \
          --field automated=true \
          --field signature='FGzCPLvYWdEgsdpb3qXkaVp7Da0=' \
          --type org.example.bank.bar \
          --id $(head -c 10 < /dev/urandom | base64 -w 0) \
          --output json

      JSON 形式のビルドされたイベント

      {
        "specversion": "1.0",
        "id": "RjtL8UH66X+UJg==",
        "source": "kn-event/v0.4.0",
        "type": "org.example.bank.bar",
        "datacontenttype": "application/json",
        "time": "2021-10-15T10:43:23.113187943Z",
        "data": {
          "automated": true,
          "operation": {
            "amount": "2345.40",
            "from": 87656231,
            "to": 2344121,
            "type": "local-wire-transfer"
          },
          "signature": "FGzCPLvYWdEgsdpb3qXkaVp7Da0="
        }
      }

4.3.2. kn-event プラグインを使用したイベントの送信

kn event send コマンドを使用して、イベントを送信できます。イベントは、公開されているアドレス、または Kubernetes サービスやKnative サービス、ブローカー、チャネル等のクラスター内のアドレス指定可能なリソースのいずれかに送信できます。このコマンドは、kn event build コマンドと同じビルダーのようなインターフェースを使用します。

前提条件

  • Knative (kn) CLI をインストールしている。

手順

  • イベントの送信:

    $ kn event send --field <field-name>=<value> --type <type-name> --id <id> --to-url <url> --to <cluster-resource> --namespace <namespace>

    ここで、

    • --field フラグは、データをフィールド/値のペアとしてイベントに追加します。これは複数回使用できます。
    • --type フラグを使用すると、イベントのタイプを指定する文字列を指定できます。
    • --id フラグは、イベントの ID を指定します。
    • イベントを一般にアクセス可能な宛先に送信する場合は、--to-url フラグを使用して URL を指定します。
    • イベントをクラスター内の Kubernetes リソースに送信する場合は、--to フラグを使用して宛先を指定します。

      • <Kind>:<ApiVersion>:<name> 形式を使用して Kubernetes リソースを指定します。
    • --namespace フラグは namespace を指定します。省略すると、namespace は現在のコンテキストから取得されます。

      --to-url または --to のいずれかを使用する必要がある宛先の仕様を除き、これらのフラグはすべてオプションです。

      以下の例は、イベントを URL に送信するケースを示しています。

      コマンドの例

      $ kn event send \
          --field player.id=6354aa60-ddb1-452e-8c13-24893667de20 \
          --field player.game=2345 \
          --field points=456 \
          --type org.example.gaming.foo \
          --to-url http://ce-api.foo.example.com/

      以下の例は、イベントをクラスター内のリソースに送信するケースを示しています。

      コマンドの例

      $ kn event send \
          --type org.example.kn.ping \
          --id $(uuidgen) \
          --field event.type=test \
          --field event.data=98765 \
          --to Service:serving.knative.dev/v1:event-display

4.4. Knative Serving CLI コマンド

以下の Knative(kn)CLI コマンドを使用して、クラスター上で Knative Serving タスクを実行できます。

4.4.1. kn service コマンド

以下のコマンドを使用して Knative サービスを作成し、管理できます。

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

Knative(kn)CLI を使用してサーバーレスアプリケーションを作成することにより、YAML ファイルを直接変更することにより、より効率的な直感的なユーザーインターフェースが提供されます。kn service create コマンドを使用して、基本的なサーバーレスアプリケーションを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

    $ kn service create <service-name> --image <image> --tag <tag-value>

    ここで、

    • --image は、アプリケーションのイメージの URI です。
    • --tag は、サービスで作成される初期リビジョンにタグを追加するために使用できるオプションのフラグです。

      コマンドの例

      $ 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

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

4.4.1.3. サービス宣言の適用

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>

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

4.4.2. Knative CLI オフラインモードについて

kn service コマンドを実行すると、変更が即座にクラスターに伝播されます。ただし、別の方法として、オフラインモードで kn service コマンドを実行できます。オフラインモードでサービスを作成すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。

重要

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

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

記述子ファイルの作成後、手動で変更し、バージョン管理システムで追跡できます。記述子ファイルで kn service create -fkn service apply -f または oc apply -f コマンドを使用して変更をクラスターに伝播することもできます。

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

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

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

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

オフラインモードで kn service コマンドを実行すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。記述子ファイルを作成した後、クラスターに変更を伝播する前にファイルを変更することができます。

重要

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

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

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • Knative (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 Container Platform クラスターにログインしている場合には、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルが default の namespace に作成されます。

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

    $ tree ./

    出力例

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

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

    $ cat test/ksvc/event-display.yaml

    出力例

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

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

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

    出力例

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

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

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

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

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

4.4.3. kn container コマンド

以下のコマンドを使用して、Knative サービス仕様で複数のコンテナーを作成し、管理できます。

4.4.3.1. Knative クライアントマルチコンテナーのサポート

kn container add コマンドを使用して、YAML コンテナーの仕様を標準出力に出力できます。このコマンドは、定義を作成するために他の標準の kn フラグと共に使用できるため、マルチコンテナーのユースケースに役立ちます。

kn container add コマンドは、kn service create コマンドで使用できるコンテナー関連のすべてのフラグを受け入れます。UNIX パイプ(|)を使用してkn container add コマンドを連結して、一度に複数のコンテナー定義を作成することもできます。

コマンドの例
  • イメージからコンテナーを追加し、標準出力に出力します。

    $ kn container add <container_name> --image <image_uri>

    コマンドの例

    $ kn container add sidecar --image docker.io/example/sidecar

    出力例

    containers:
    - image: docker.io/example/sidecar
      name: sidecar
      resources: {}

  • 2 つの kn container add コマンドを連結してから、kn service create コマンドに渡して、2 つのコンテナーで Knative サービスを作成します。

    $ kn container add <first_container_name> --image <image_uri> | \
    kn container add <second_container_name> --image <image_uri> | \
    kn service create <service_name> --image <image_uri> --extra-containers -

    --extra-containers - は、kn が YAML ファイルの代わりにパイプ入力を読み取る特別なケースを指定します。

    コマンドの例

    $ kn container add sidecar --image docker.io/example/sidecar:first | \
    kn container add second --image docker.io/example/sidecar:second | \
    kn service create my-service --image docker.io/example/my-app:latest --extra-containers -

    --extra-containers フラグは YAML ファイルへのパスを受け入れることもできます。

    $ kn service create <service_name> --image <image_uri> --extra-containers <filename>

    コマンドの例

    $ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml

4.4.4. kn domain コマンド

以下のコマンドを使用して、ドメインマッピングを作成および管理できます。

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

独自のカスタムドメイン名を Knative サービスにマッピングして、Knative サービスのドメインをカスタマイズできます。Knative(kn)CLI を使用して、Knative サービスまたは Knative ルートなどの Addressable target CR にマップする DomainMapping カスタムリソース(CR)を作成できます。

前提条件

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

    注記

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

  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

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

    コマンドの例

    $ kn domain create example-domain-map --ref example-service

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

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

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

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

    コマンドの例

    $ kn domain create example-domain-map --ref ksvc:example-service:example-namespace

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

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

    コマンドの例

    $ kn domain create example-domain-map --ref kroute:example-route

4.4.4.2. Knative CLI を使用したカスタムドメインマッピングの管理

DomainMapping カスタムリソース(CR)の作成後に、既存の CR の一覧表示、既存の CR についての情報の表示、CR の更新、または Knative(kn)CLI を使用して CR の削除を実行できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • 1 つ以上の DomainMapping CR を作成している。
  • Knative(kn)CLI ツールがインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • 既存の DomainMapping CR を一覧表示します。

    $ kn domain list -n <domain_mapping_namespace>
  • 既存の DomainMapping CR の詳細を表示します。

    $ kn domain describe <domain_mapping_name>
  • 新規ターゲットを参照するように DomainMapping CR を更新します。

    $ kn domain update --ref <target>
  • DomainMapping CR を削除します。

    $ kn domain delete <domain_mapping_name>

4.5. Knative Eventing CLI コマンド

以下の Knative (kn) CLI コマンドを使用して、クラスター上で Knative Eventing タスクを実行できます。

4.5.1. kn source コマンド

以下のコマンドを使用して、Knative イベントソースを一覧表示、作成、および管理できます。

4.5.1.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示

Knative(kn)CLI を使用すると、クラスターで利用可能なイベントソースタイプを表示するための単純化された直感的なユーザーインターフェースが提供されます。kn source list-types CLI コマンドを使用して、クラスターで作成して使用できるイベントソースタイプを一覧表示できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • Knative (kn) 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

4.5.1.2. Knative CLI シンクフラグ

Knative (kn) CLI を使用してイベントソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

シンクフラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

4.5.1.3. Knative CLI を使用したコンテナーソースの作成および管理

kn source container コマンドを使用して、Knative(kn)CLI を使用してコンテナーソースを作成し、管理できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

コンテナーソースを作成します。

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

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

kn source apiserver create コマンドを使用し、kn CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift (oc) CLI がインストールされている。
  • Knative (kn) CLI をインストールしている。
手順

既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。

  1. イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    この namespace を、イベントソースのインストールに選択した namespace に変更します。
  2. YAML ファイルを適用します。

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

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
  4. API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。

    $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  5. ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、default のブローカーからサービスへのイベントをフィルタリングします。

    $ kn trigger create <trigger_name> --sink ksvc:<service_name>
  6. デフォルト namespace で Pod を起動してイベントを作成します。

    $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  7. 以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ kn source apiserver describe <source_name>

    出力例

    Name:                mysource
    Namespace:           default
    Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
    Age:                 3m
    ServiceAccountName:  events-sa
    Mode:                Resource
    Sink:
      Name:       default
      Namespace:  default
      Kind:       Broker (eventing.knative.dev/v1)
    Resources:
      Kind:        event (v1)
      Controller:  false
    Conditions:
      OK TYPE                     AGE REASON
      ++ Ready                     3m
      ++ Deployed                  3m
      ++ SinkProvided              3m
      ++ SufficientPermissions     3m
      ++ EventTypesProvided        3m

検証

メッセージダンパー機能ログを確認して、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",
        ...
      }

API サーバーソースの削除

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

    $ kn trigger delete <trigger_name>
  2. イベントソースを削除します。

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

    $ oc delete -f authentication.yaml

4.5.1.5. Knative CLI を使用した ping ソースの作成

kn source ping create コマンドを使用して、Knative(kn)CLI を使用して ping ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • オプション: この手順の検証手順を使用する場合は、OpenShift (oc) 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!"
      }

ping ソースの削除

  • ping ソースを削除します。

    $ kn delete pingsources.sources.knative.dev <ping_source_name>

4.5.1.6. Knative CLI を使用した Kafka イベントソースの作成

Knative(kn)CLI を使用して、kn source kafka create コマンドを使用して Kafka ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、Knative Serving、および KnativeKafka カスタムリソース (CR) がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
  • Knative (kn) CLI をインストールしている。
  • オプション: この手順で検証ステップを使用する場合は、OpenShift (oc) CLI をインストールします。

手順

  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!

4.6. 関数コマンド

4.6.1. 関数の作成

関数をビルドし、デプロイする前に、Knative(kn)CLI を使用してこれを作成する必要があります。コマンドラインでパス、ランタイム、テンプレート、およびイメージレジストリーをフラグとして指定するか、または -c フラグを使用してターミナルで対話的なエクスペリエンスを開始できます。

前提条件

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

手順

  • 関数プロジェクトを作成します。

    $ kn func create -r <repository> -l <runtime> -t <template> <path>
    • 許可されるランタイム値には、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

    • または、カスタムテンプレートを含むリポジトリーを指定することもできます。

      コマンドの例

      $ kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc

      出力例

      Project path:  /home/user/demo/examplefunc
      Function name: examplefunc
      Runtime:       node
      Template:      hello-world
      Writing events to /home/user/demo/examplefunc

4.6.2. 関数のビルド

関数を実行する前に、kn func build コマンドを使用して機能プロジェクトをビルドする必要があります。このコマンドは、コンピューターまたは OpenShift Container Platform クラスターでローカルに実行できる OCI コンテナーイメージを作成します。build コマンドは、関数プロジェクト名とイメージレジストリー名を使用して、関数の完全修飾イメージ名を作成します。

デフォルトでは、kn func build は Red Hat Source-to-Image(S2I)技術を使用してコンテナーイメージを作成します。代わりに CNCF Cloud Native Buildpacks テクノロジーを使用するには、-b フラグを指定します。

build コマンドの例

$ kn func build -b pack

出力例

Building function image
Function image has been built, image: registry.redhat.io/example/example-function:latest

OpenShift Container Registry は、関数イメージを保存するためのイメージレジストリーとしてデフォルトで使用されます。-r フラグを使用して、これをオーバーライドできます。

build コマンドの例

$ kn func build -r quay.io/username

出力例

Building function image
Function image has been built, image: quay.io/username/example-function:latest

kn func build コマンドオプションの詳細については、help コマンドを使用できます。

help コマンドの構築

$ kn func help build

4.6.3. 関数のデプロイ

kn func deploy コマンドを使用して、関数を Knative サービスとしてクラスターにデプロイできます。ターゲット関数がすでにデプロイされている場合には、コンテナーイメージレジストリーにプッシュされている新規コンテナーイメージで更新され、Knative サービスが更新されます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • デプロイする関数を作成し、初期化している必要があります。

手順

  • 関数をデプロイします。

    $ kn func deploy [-n <namespace> -p <path> -i <image>]

    出力例

    Function deployed at: http://func.example.com

    • namespace が指定されていない場合には、関数は現在の namespace にデプロイされます。
    • この関数は、パス が指定されない限り、現在のディレクトリーからデプロイされます。
    • Knative サービス名はプロジェクト名から派生するので、以下のコマンドでは変更できません。

4.6.4. 既存の関数の一覧表示

kn func list を使用して既存の関数を一覧表示できます。Knative サービスとしてデプロイされた関数を一覧表示するには、kn service list を使用することもできます。

手順

  • 既存の関数を一覧表示します。

    $ kn func list [-n <namespace> -p <path>]

    出力例

    NAME           NAMESPACE  RUNTIME  URL                                                                                      READY
    example-function  default    node     http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com  True

  • Knative サービスとしてデプロイされた関数を一覧表示します。

    $ kn service list -n <namespace>

    出力例

    NAME            URL                                                                                       LATEST                AGE   CONDITIONS   READY   REASON
    example-function   http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com   example-function-gzl4c   16m   3 OK / 3     True

4.6.5. 関数の記述

kn func info コマンドは、関数名、イメージ、namespace、Knative サービス情報、ルート情報、イベントサブスクリプションなどのデプロイされた関数に関する情報を出力します。

手順

  • 関数を説明します。

    $ kn func info [-f <format> -n <namespace> -p <path>]

    コマンドの例

    $ kn func info -p function/example-function

    出力例

    Function name:
      example-function
    Function is built in image:
      docker.io/user/example-function:latest
    Function is deployed as Knative Service:
      example-function
    Function is deployed in namespace:
      default
    Routes:
      http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com

4.6.6. テストイベントでのデプロイされた関数の呼び出し

kn func invoke CLI コマンドを使用して、ローカルまたは OpenShift Container Platform クラスター上で関数を呼び出すためのテストリクエストを送信できます。このコマンドを使用して、関数が機能し、イベントを正しく受信できることをテストできます。

コマンドの例

$ kn func invoke

kn func invoke コマンドは、デフォルトでローカルディレクトリーで実行され、このディレクトリーが関数プロジェクトであると想定します。

4.6.6.1. kn func はオプションのパラメーターを呼び出します

次の knfuncinvoke CLI コマンドフラグを使用して、リクエストのオプションのパラメーターを指定できます。

Flags説明

-t--target

呼び出された関数のターゲットインスタンスを指定します。たとえば、localremotehttps://staging.example.com/ などです。デフォルトのターゲットは local です。

-f-format

メッセージの形式を指定します (例: cloudevent または http)。

--id

リクエストの一意の文字列識別子を指定します。

-n-namespace

クラスターの名前空間を指定します。

--source

リクエストの送信者名を指定します。これは、CloudEvent source 属性に対応します。

--type

リクエストのタイプを指定します (例: boson.fn)。これは、CloudEvent type 属性に対応します。

--data

リクエストの内容を指定します。CloudEvent リクエストの場合、これは CloudEvent data 属性です。

--file

送信するデータを含むローカルファイルへのパスを指定します。

--content-type

リクエストの MIME コンテンツタイプを指定します。

-p--path

プロジェクトディレクトリーへのパスを指定します。

-c--confirm

すべてのオプションを対話的に確認するように要求を有効にします。

-v, --verbose

詳細出力の出力を有効にします。

-h--help

kn func invoke の使用法に関する情報を出力します。

4.6.6.1.1. 主なパラメーター

次のパラメーターは、kn func invoke コマンドの主なプロパティーを定義します。

イベントターゲット (-t-target)
呼び出された関数のターゲットインスタンス。ローカルにデプロイされた関数の local 値、リモートにデプロイされた関数の remote 値、または任意のエンドポイントにデプロイされた関数の URL を受け入れます。ターゲットが指定されていない場合、デフォルトで local になります。
イベントメッセージ形式 (-f--format)
httpcloudevent などのイベントのメッセージ形式。これは、デフォルトで、関数の作成時に使用されたテンプレートの形式になります。
イベントタイプ (--type)
送信されるイベントのタイプ。各イベントプロデューサーのドキュメントで設定されている type パラメーターに関する情報を見つけることができます。たとえば、API サーバーソースは、生成されたイベントの type パラメーターを dev.knative.apiserver.resource.update として設定する場合があります。
イベントソース (--source)
イベントを生成する一意のイベントソース。これは、https://10.96.0.1/ などのイベントソースの URI、またはイベントソースの名前である可能性があります。
イベント ID (--id)
イベントプロデューサーによって作成されるランダムな一意の ID。
イベントデータ (--data)

kn func invoke コマンドで送信されるイベントの data 値を指定できます。たとえば、イベントにこのデータ文字列が含まれるように、"Hello World" などの --data 値を指定できます。デフォルトでは、kn func invoke によって作成されたイベントにデータは含まれません。

注記

クラスターにデプロイされた関数は、source および type などのプロパティーの値を提供する既存のイベントソースからのイベントに応答できます。多くの場合、これらのイベントには、イベントのドメイン固有のコンテキストをキャプチャーする JSON 形式の data 値があります。本書に記載されている CLI フラグを使用して、開発者はローカルテスト用にこれらのイベントをシミュレートできます。

--file フラグを使用してイベントデータを送信し、イベントのデータを含むローカルファイルを指定することもできます。この場合は、--content-type を使用してコンテンツタイプを指定します。

データコンテンツタイプ (--content-type)
--data フラグを使用してイベントのデータを追加している場合は、-content-type フラグを使用して、イベントによって伝送されるデータのタイプを指定できます。前の例では、データはプレーンテキストであるため、kn func invoke --data "Hello world!" --content-type "text/plain" を指定できます。
4.6.6.1.2. コマンドの例

これは、kn func invoke コマンドの一般的な呼び出しです。

$ kn func invoke --type <event_type> --source <event_source> --data <event_data> --content-type <content_type> --id <event_ID> --format <format> --namespace <namespace>

たとえば、「Hello world!」イベントを送信すると、以下を行うことができます。

$ kn func invoke --type ping --source example-ping --data "Hello world!" --content-type "text/plain" --id example-ID --format http --namespace my-ns
4.6.6.1.2.1. データを使用したファイルの指定

イベントデータが含まれるディスクにファイルを指定するには、--file フラグおよび --content-type フラグを使用します。

$ kn func invoke --file <path> --content-type <content-type>

たとえば、test.json ファイルに保存されている JSON データを送信するには、以下のコマンドを使用します。

$ kn func invoke --file ./test.json --content-type application/json
4.6.6.1.2.2. 関数プロジェクトの指定

--path フラグを使用して、関数プロジェクトへのパスを指定できます。

$ kn func invoke --path <path_to_function>

たとえば、./example/example- function ディレクトリーにある function プロジェクトを使用するには、以下のコマンドを使用します。

$ kn func invoke --path ./example/example-function
4.6.6.1.2.3. ターゲット関数がデプロイされる場所の指定

デフォルトでは、kn func invoke は関数のローカルデプロイメントをターゲットにします。

$ kn func invoke

別のデプロイメントを使用するには、--target フラグを使用します。

$ kn func invoke --target <target>

たとえば、クラスターにデプロイされた関数を使用するには、-target remote フラグを使用します。

$ kn func invoke --target remote

任意の URL にデプロイされた関数を使用するには、-target <URL> フラグを使用します。

$ kn func invoke --target "https://my-event-broker.example.com"

ローカルデプロイメントを明示的にターゲットとして指定できます。この場合、関数がローカルで実行されていない場合、コマンドは失敗します。

$ kn func invoke --target local

4.6.7. 関数の削除

kn func delete コマンドを使用して、クラスターから関数を削除できます。

手順

  • 関数を削除します。

    $ kn func delete [<function_name> -n <namespace> -p <path>]
    • 削除する関数の名前またはパスが指定されていない場合には、現在のディレクトリーで func.yaml ファイルを検索し、削除する関数を判断します。
    • namespace が指定されていない場合には、func.yamlnamespace の値にデフォルト設定されます。

第5章 開発

5.1. Serverless アプリケーション

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

Knative Service オブジェクトの 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
サンプルアプリケーションで出力される環境変数

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

  • OpenShift Container Platform Web コンソールからの Knative サービスの作成

    詳細は、Creating applications using the Developer perspective を参照してください。

  • Knative(kn)CLI を使用して Knative サービスを作成します。
  • oc CLI を使用して、Knative Service オブジェクトを YAML ファイルとして作成し、適用します。

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

Knative(kn)CLI を使用してサーバーレスアプリケーションを作成することにより、YAML ファイルを直接変更することにより、より効率的な直感的なユーザーインターフェースが提供されます。kn service create コマンドを使用して、基本的なサーバーレスアプリケーションを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

    $ kn service create <service-name> --image <image> --tag <tag-value>

    ここで、

    • --image は、アプリケーションのイメージの URI です。
    • --tag は、サービスで作成される初期リビジョンにタグを追加するために使用できるオプションのフラグです。

      コマンドの例

      $ 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.1.2. オフラインモードを使用したサービスの作成

オフラインモードで kn service コマンドを実行すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。記述子ファイルを作成した後、クラスターに変更を伝播する前にファイルを変更することができます。

重要

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

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

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • Knative (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 Container Platform クラスターにログインしている場合には、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルが default の namespace に作成されます。

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

    $ tree ./

    出力例

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

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

    $ cat test/ksvc/event-display.yaml

    出力例

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

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

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

    出力例

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

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

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

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

      --namespace を使用せず、OpenShift Container Platform クラスターにログインしている場合には、kn は現在の namespace をもとに名前が付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、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.1.3. YAML を使用したサーバーレスアプリケーションの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用してサーバーレスアプリケーションを作成するには、Knative Service を定義する YAML ファイルを作成し、oc apply を使用してこれを適用する必要があります。

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

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift CLI (oc) をインストールします。

手順

  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>

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

サーバーレスアプリケーションが正常にデプロイされたことを確認するには、Knative によって作成されたアプリケーション URL を取得してから、その URL に要求を送信し、出力を確認する必要があります。OpenShift Serverless は HTTP および HTTPS URL の両方の使用をサポートしますが、oc get ksvc からの出力は常に http:// 形式を使用して URL を出力します。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • oc CLI がインストールされている。
  • Knative サービスを作成している。

前提条件

  • OpenShift CLI (oc) をインストールします。

手順

  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.1.5. HTTP2 および gRPC を使用したサーバーレスアプリケーションとの対話

OpenShift Serverless はセキュアでないルートまたは edge termination ルートのみをサポートします。非セキュアなルートまたは edge termination ルートは OpenShift Container Platform で HTTP2 をサポートしません。gRPC は HTTP2 によって転送されるため、これらのルートは gRPC もサポートしません。アプリケーションでこれらのプロトコルを使用する場合は、Ingress ゲートウェイを使用してアプリケーションを直接呼び出す必要があります。これを実行するには、Ingress ゲートウェイのパブリックアドレスとアプリケーションの特定のホストを見つける必要があります。

重要

この方法は、LoadBalancer サービスタイプを使用して Kourier Gateway を公開する必要があります。これは、以下の YAML を KnativeServing カスタムリソース定義(CRD)に追加して設定できます。

...
spec:
  ingress:
    kourier:
      service-type: LoadBalancer
...

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • OpenShift CLI (oc) をインストールします。
  • Knative サービスを作成している。

手順

  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.1.6. 制限のあるネットワークポリシーを持つクラスターでの 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 サービスの JSON Web トークン認証にはサービスメッシュが必要です。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。

手順

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

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

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

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
    3. knative-eventing namespace にラベルを付けます。

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
    4. knative-kafka namespace にラベルを付けます。

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

    サンプル NetworkPolicy オブジェクト

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

    1
    ネットワークポリシーの名前を指定します。
    2
    アプリケーションが存在する namespace。

5.1.7. init コンテナーの設定

Init コンテナー は、Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナーです。これらは通常、アプリケーションの初期化ロジックを実装するために使用されます。これには、セットアップスクリプトの実行や、必要な設定のダウンロードが含まれる場合があります。

注記

Init コンテナーを使用すると、アプリケーションの起動時間が長くなる可能性があるため、頻繁にスケールアップおよびスケールダウンすることが予想されるサーバーレスアプリケーションには注意して使用する必要があります。

複数の複数の init コンテナーは単一の Knative サービス仕様でサポートされます。テンプレート名が指定されていない場合、Knative はデフォルトの設定可能な名前付けテンプレートを提供します。初期化コンテナーテンプレートは、Knative Service オブジェクト仕様に適切な値を追加することで設定できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
  • Knative サービスに init コンテナーを使用する前に、管理者は kubernetes.podspec-init-containers フラグを KnativeServing カスタムリソース (CR) に追加する必要があります。詳細については、OpenShift Serverless のグローバルコンフィギュレーションドキュメントを参照してください。

手順

  • initContainers 仕様を KnativeService オブジェクトに追加します。

    サービス仕様の例

    apiVersion: serving.knative.dev/v1
    kind: Service
    ...
    spec:
      template:
        spec:
          initContainers:
            - imagePullPolicy: IfNotPresent 1
              image: <image_uri> 2
              volumeMounts: 3
                - name: data
                  mountPath: /data
    ...

    1
    イメージのダウンロード時の イメージプルポリシー
    2
    init コンテナーイメージの URI。
    3
    コンテナーファイルシステム内でボリュームがマウントされる場所。

5.1.8. サービスごとの HTTPS リダイレクト

networking.knative.dev/http-option アノテーションを設定することにより、サービスの HTTPS リダイレクトを有効または無効にできます。次の例は、Knative Service YAML オブジェクトでこのアノテーションを使用する方法を示しています。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example
  namespace: default
  annotations:
    networking.knative.dev/http-option: "redirected"
spec:
  ...

5.1.9. 関連情報

5.2. 自動スケーリング

Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング(autoscaling)を提供します。たとえば、アプリケーションがトラフィックを受信せず、scale-to-zeroが有効にされている場合、Knative Serving はアプリケーションをゼロレプリカにスケールダウンします。scale-to-zero が無効になっている場合、アプリケーションはクラスターのアプリケーションに設定された最小のレプリカ数にスケールダウンされます。アプリケーションへのトラフィックが増加したら、要求を満たすようにレプリカをスケールアップすることもできます。

Knative サービスの自動スケーリング設定は、クラスター管理者によって設定されるグローバル設定とすることも、個別サービスに設定されるリビジョンごとの設定とすることもできます。

サービスの YAML ファイルを変更するか、または Knative(kn)CLI を使用して、サービスのリビジョンごとの設定を変更できます。

注記

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

5.2.1. スケーリング限度

スケーリング限度は、任意の時点でアプリケーションに対応できる最小および最大のレプリカ数を決定します。アプリケーションのスケーリング限度を設定して、コールドスタートを防止したり、コンピューティングコストを制御したりできます。

5.2.1.1. スケーリング下限

アプリケーションにサービスを提供できるレプリカの最小数は、最小 min-scale のアノテーションによって決定されます。ゼロへのスケーリングが有効になっていない場合、min-Scale 値のデフォルトは1になります。

次の条件が満たされた場合、min-scale 値はデフォルトで 0 レプリカになります。

  • mi-scale の注釈が設定されていません
  • ゼロへのスケーリングが有効にされている
  • KPA クラスが使用されている

min-scale アノテーションを使用したサービス仕様の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
...

5.2.1.1.1. Knative CLI を使用した最小スケール注釈の設定

minScale アノテーションを設定するために Knative (kn) CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが提供されます。kn service コマンドを --scale-min フラグと共に使用して、サービスの --min-scale 値を作成または変更できます。

前提条件

  • Knative Serving がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。

手順

  • --scale-min フラグを使用して、サービスのレプリカの最小数を設定します。

    $ kn service create <service_name> --image <image_uri> --scale-min <integer>

    コマンドの例

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

5.2.1.2. スケーリング上限

アプリケーションにサービスを提供できるレプリカの最大数は、max-scale アノテーションによって決定されます。max-scale アノテーションが設定されていない場合、作成されるレプリカの数に上限はありません。

max-scale アノテーションを使用したサービス仕様の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "10"
...

5.2.1.2.1. Knative CLI を使用した最大スケール注釈の設定

Knative (kn) CLI を使用して max-scale の注釈を設定すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。--scale-max フラグを指定して knservice コマンドを使用すると、kn servicemax-scale 値を作成または変更できます。

前提条件

  • Knative Serving がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。

手順

  • --scale-max フラグを使用して、サービスのレプリカの最大数を設定します。

    $ kn service create <service_name> --image <image_uri> --scale-max <integer>

    コマンドの例

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

5.2.2. 並行処理性

並行処理性は、特定の時点でアプリケーションの各レプリカが処理できる同時リクエストの数を決定します。並行処理性は、ソフトリミットまたはハードリミットのいずれかとして設定できます。

  • ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。
  • ハードリミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。

    重要

    ハードリミット設定の使用は、アプリケーションに明確なユースケースがある場合にのみ推奨されます。ハードリミットを低い値に指定すると、アプリケーションのスループットとレイテンシーに悪影響を与える可能性があり、コールドスタートが発生する可能性があります。

ソフトターゲットとハードリミットを追加することは、Autoscaler は同時リクエストのソフトターゲット数を目標とするが、リクエストの最大数にハードリミット値のハードリミットを課すことを意味します。

ハードリミットの値がソフトリミットの値より小さい場合、実際に処理できる数よりも多くのリクエストを目標にする必要がないため、ソフトリミットの値が低減されます。

5.2.2.1. ソフト並行処理ターゲットの設定

ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。autoscaling.knative.dev/target アノテーションを仕様に設定するか、または正しいフラグを指定して kn service コマンドを使用して、Knative サービスにソフト並行処理ターゲットを指定できます。

手順

  • オプション:Service カスタムリソースの仕様で Knative サービスに autoscaling.knative.dev/target アノテーションを設定します。

    サービス仕様の例

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: example-service
      namespace: default
    spec:
      template:
        metadata:
          annotations:
            autoscaling.knative.dev/target: "200"

  • オプション:kn service コマンドを使用して --concurrency-target フラグを指定します。

    $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

    並行処理のターゲットを 50 リクエストに設定したサービスを作成するコマンドの例

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

5.2.2.2. ハード並行処理リミットの設定

ハード並行処理リミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。containerConcurrency 仕様を変更するか、または正しいフラグを指定して kn service コマンドを使用して、Knative サービスにハード並行処理リミットを指定できます。

手順

  • オプション:Service カスタムリソースの仕様で Knative サービスに containerConcurrency 仕様を設定します。

    サービス仕様の例

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: example-service
      namespace: default
    spec:
      template:
        spec:
          containerConcurrency: 50

    デフォルト値は 0 です。これは、サービスの 1 つのレプリカに一度に流れることができる同時リクエストの数に制限がないことを意味します。

    0 より大きい値は、サービスの 1 つのレプリカに一度に流れることができるリクエストの正確な数を指定します。この例では、50 リクエストのハード並行処理リミットを有効にします。

  • オプション:kn service コマンドを使用して --concurrency-limit フラグを指定します。

    $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

    並行処理のリミットを 50 リクエストに設定したサービスを作成するコマンドの例

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

5.2.2.3. 並行処理ターゲットの使用率

この値は、Autoscaler が実際に目標とする並行処理リミットのパーセンテージを指定します。これは、レプリカが実行する ホット度 を指定することとも呼ばれます。これにより、Autoscaler は定義されたハードリミットに達する前にスケールアップできるようになります。

たとえば、containerConcurrency 値が 10 に設定され、target-utilization-percentage 値が 70% に設定されている場合、既存のすべてのレプリカの同時リクエストの平均数が 7 に達すると、オートスケーラーは新しいレプリカを作成します。7 から 10 の番号が付けられたリクエストは引き続き既存のレプリカに送信されますが、containerConcurrency 値に達した後、必要になることを見越して追加のレプリカが開始されます。

target-utilization-percentage アノテーションを使用して設定されたサービスの例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
...

5.3. トラフィック管理

Knative アプリケーションでは、トラフィック分割を作成することでトラフィックを管理できます。トラフィック分割は、Knative サービスによって管理されるルートの一部として設定されます。

Knative アプリケーションのトラフィック管理

ルートを設定すると、サービスのさまざまなリビジョンにリクエストを送信できます。このルーティングは、Service オブジェクトの traffic 仕様によって決定されます。

traffic 仕様宣言は、1 つ以上のリビジョンで設定され、それぞれがトラフィック全体の一部を処理する責任があります。各リビジョンにルーティングされるトラフィックの割合は、合計で 100% になる必要があります。これは、Knative 検証によって保証されます。

traffic 仕様で指定されたリビジョンは、固定の名前付きリビジョンにすることも、サービスのすべてのリビジョンのリストの先頭を追跡する最新のリビジョンを指すこともできます。最新のリビジョンは、新しいリビジョンが作成された場合に更新される一種のフローティング参照です。各リビジョンには、そのリビジョンの追加のアクセス URL を作成するタグを付けることができます。

traffic 仕様は次の方法で変更できます。

  • Service オブジェクトの YAML を直接編集します。
  • Knative(kn)CLI --traffic フラグの使用。
  • OpenShift Container Platform コンソールの使用。

Knative サービスの作成時に、デフォルトの traffic 仕様設定は含まれません。

5.3.1. トラフィックスペックの例

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

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

以下の例は、トラフィックの 100% が current としてタグ付けされたリビジョンにルーティングされ、そのリビジョンの名前が example-service として指定される traffic 仕様を示しています。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

以下の例は、トラフィックが複数のリビジョン間で分割されるように、traffic 仕様のリビジョンの一覧を拡張する方法を示しています。この例では、トラフィックの 50% を、current としてタグ付けされたリビジョンに送信します。また、candidate としてタグ付けされたリビジョンにトラフィックの 50% を送信します。latest とタグ付けされたリビジョンは、トラフィックが宛先にルーティングされない場合でも、利用可能な状態になります。

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.3.2. Knative CLI トラフィック管理フラグ

Knative(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.3.2.1. 複数のフラグおよび順序の優先順位

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

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

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

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

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

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

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

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

以下の例では、タグ latest を、example-revision という名前のリビジョンに割り当てます。

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

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

注記

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

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

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

5.3.3. KnativeCLI を使用してトラフィック分割を作成する

Knative(kn)CLI を使用してトラフィック分割を作成し、YAML ファイルを直接変更することにより、より効率的な直感的なユーザーインターフェースを提供します。kn service update コマンドを使用して、サービスのリビジョン間でトラフィックを分割できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • Knative サービスを作成している。

手順

  • 標準の kn service update コマンドで --traffic タグを使用して、サービスのリビジョンとそれにルーティングするトラフィックの割合を指定します。

    コマンドの例

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

    ここで、

    • <service_name> は、トラフィックルーティングを設定する Knative サービスの名前です。
    • <revision> は、一定の割合のトラフィックを受信するように構成するリビジョンです。リビジョンの名前、または --tag フラグを使用してリビジョンに割り当てたタグのいずれかを指定できます。
    • <percentage> は、指定されたリビジョンに送信するトラフィックのパーセンテージです。
  • オプション: --traffic フラグは、1 つのコマンドで複数回指定できます。たとえば、@latest というタグの付いたリビジョンと stable という名前のリビジョンがある場合、次のように各リビジョンに分割するトラフィックの割合を指定できます。

    コマンドの例

    $ kn service update example-service --traffic @latest=20,stable=80

    複数のリビジョンがあり、最後のリビジョンに分割する必要があるトラフィックの割合を指定しない場合、-traffic フラグはこれを自動的に計算できます。たとえば、example という名前の 3 番目のリビジョンがあり、次のコマンドを使用する場合:

    コマンドの例

    $ kn service update example-service --traffic @latest=10,stable=60

    トラフィックの残りの 30% は、指定されていなくても、example リビジョンに分割されます。

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

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

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

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • OpenShift Container Platform Web コンソールにログインしている。

手順

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.3.5. blue-green デプロイメントストラテジーを使用したトラフィックのルーティングおよび管理

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

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • OpenShift CLI (oc) をインストールします。

手順

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

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

    コマンドの例

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

    出力例

    $ example-service-00001

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

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

    $ oc get ksvc <service_name>
  5. サービスの template 仕様の少なくとも 1 つのフィールドを変更してアプリケーションの 2 番目のリビジョンをデプロイし、これを再デプロイします。たとえば、サービスの imageenv 環境変数を変更できます。サービス YAML ファイルを適用するか、Knative(kn)CLI をインストールしている場合は kn service update コマンドを使用してサービスを再デプロイできます。
  6. 以下のコマンドを実行して、サービスを再デプロイする際に作成された 2 番目の最新のリビジョンの名前を見つけます。

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

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

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

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

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

    YAML リソースを再適用してこのサービスを再デプロイすると、アプリケーションの 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. すべてのトラフィックを新しいバージョンのアプリケーションにルーティングできる状態になったら、再度サービスを更新して、100% のトラフィックを 2 番目のリビジョンに送信します。

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

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

    ヒント

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

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

5.4. Routing

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.4.1. OpenShift Container Platform ルートのラベルおよびアノテーションのカスタマイズ

OpenShift Container Platform ルートは、Knative サービスの metadata 仕様を変更して設定できるカスタムラベルおよびアノテーションの使用をサポートします。カスタムラベルおよびアノテーションはサービスから Knative ルートに伝番され、次に Knative ingress に、最後に OpenShift Container Platform ルートに伝播されます。

前提条件

  • OpenShift Serverless Operator および Knative Serving が OpenShift Container Platform クラスターにインストールされている必要があります。
  • OpenShift CLI (oc) をインストールします。

手順

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

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

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

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

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

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

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

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

    検証のコマンドの例

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

    1
    サービスの名前を使用します。
    2
    サービスが作成された namespace を使用します。
    3
    ラベルおよびアノテーション名および値の値を使用します。

5.4.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 クラスターにインストールされている。
  • OpenShift CLI (oc) をインストールします。

手順

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

    重要

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

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

      リソースの例

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

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

      $ oc apply -f <filename>
    3. オプション:kn service create コマンドを使用して Knative サービスを作成します。

      kn コマンドの例

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

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

    コマンドの例

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

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

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

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      annotations:
        haproxy.router.openshift.io/timeout: 600s 1
      name: <route_name> 2
      namespace: knative-serving-ingress 3
    spec:
      host: <service_host> 4
      port:
        targetPort: http2
      to:
        kind: Service
        name: kourier
        weight: 100
      tls:
        insecureEdgeTerminationPolicy: Allow
        termination: edge 5
        key: |-
          -----BEGIN PRIVATE KEY-----
          [...]
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE----
      wildcardPolicy: None
    1
    OpenShift Container Platform ルートのタイムアウト値。max-revision-timeout-seconds 設定と同じ値を設定する必要があります(デフォルトでは 600s)。
    2
    OpenShift Container Platform ルートの名前。
    3
    OpenShift Container Platform ルートの namespace。これは knative-serving-ingress である必要があります。
    4
    外部アクセスのホスト名。これを <service_name>-<service_namespace>.<domain> に設定できます。
    5
    使用する証明書。現時点で、edge termination のみがサポートされています。
  4. Route リソースを適用します。

    $ oc apply -f <filename>

5.4.3. クラスターローカルへのクラスター可用性の設定

デフォルトで、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 ラベルを使用する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Knative サービスを作成している。

手順

  • 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.4.4. 関連情報

5.5. イベントシンク

イベントソースの作成時に、イベントがソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能なリソースです。Knative サービス、チャネル、およびブローカーはすべてシンクのサンプルです。

アドレス指定可能なオブジェクトは、HTTP 経由で status.address.url フィールドに定義されるアドレスに配信されるイベントを受信し、確認することができます。特別な場合として、コア Kubernetes Service オブジェクトはアドレス指定可能なインターフェースにも対応します。

呼び出し可能なオブジェクトは、HTTP 経由で配信されるイベントを受信し、そのイベントを変換できます。HTTP 応答で 0 または 1 の新規イベントを返します。返されるイベントは、外部イベントソースからのイベントが処理されるのと同じ方法で処理できます。

5.5.1. Knative CLI シンクフラグ

Knative (kn) CLI を使用してイベントソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

シンクフラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。
ヒント

kn のカスタマイズ により、Knative(kn)CLI コマンドの --sink フラグと共に使用できる CR を設定できます。

5.5.2. Developer パースペクティブを使用してイベントソースをシンクに接続します。

OpenShift Container Platform Web コンソールを使用してイベントソースを作成する場合、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしており、Developer パースペクティブを使用している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Knative サービス、チャネル、ブローカーなどのシンクを作成している。

手順

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

検証

Topology ページを表示して、イベントソースが作成され、シンクに接続されていることを確認できます。

  1. Developer パースペクティブで、Topology に移動します。
  2. イベントソースを表示し、接続されたシンクをクリックし、サイドパネルでシンクの詳細を表示します。

5.5.3. トリガーのシンクへの接続

トリガーをシンクに接続して、シンクへの送信前にブローカーからのイベントがフィルターされるようにします。トリガーに接続されているシンクは、Trigger オブジェクトのリソース仕様で subscriber として設定されます。

Kafka シンクに接続された Trigger オブジェクトの例

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 オブジェクトの名前。

5.6. イベント配信

サブスクライバーへのサブスクリプション または トリガーで配信されるイベントに失敗した場合に適用される Knative Eventing のイベント配信パラメーターを設定できます。イベント配信パラメーターは、サブスクライバーごとに個別に設定されます。

5.6.1. Knative Eventing チャネルのイベント配信動作

Knative Eventing チャネルタイプのイベント配信に使用される動作パターンはそれぞれ異なります。開発者は、サブスクリプション設定でイベント配信パラメーターを設定して、チャネルからイベントシンクに配信できないイベントが再試行されるようにできます。また、最終的に配信されないイベントを保存できるシンクを提供する必要がある場合は、サブスクリプションの dead letter sink も設定する必要があります。これを設定しないと、配信されないイベントはドロップされます。

5.6.1.1. Knative Kafka チャネルのイベント配信動作

イベントが Kafka チャネルまたはブローカーレシーバーに正常に配信される場合、受信側は 202 ステータスコードで応答します。つまり、このイベントは Kafka トピック内に安全に保存され、失われることはありません。受信側がその他のステータスコードを返す場合は、イベントは安全に保存されず、ユーザーがこの問題を解決するために手順を実行する必要があります。

5.6.1.2. 配信失敗ステータスコード

チャネルまたはブローカーの受信側は、イベントが配信に失敗した場合に以下のステータスコードで応答する場合があります。

500
これは一般的なステータスコードで、イベントが正常に配信されなかったことを意味します。
404
このステータスコードは、イベントが配信されるチャネルまたはブローカーが存在しないか、または Host ヘッダーが正しくないことを意味します。
400
このステータスコードは、受信側に送信されるイベントが無効であることを意味します。

5.6.2. 設定可能なイベント配信パラメーター

Knative Eventing は、イベントの配信に失敗した場合にイベントに何が起こるかを制御するために使用できる設定パラメーターを提供します。たとえば、消費に失敗したイベントの送信を再試行するように Knative を設定したり、これらのイベントを dead letter sink に転送したりできます。

以下のパラメーターはイベント配信用に設定できます。

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> と等しくなります。

5.6.3. サブスクリプションを使用したイベント配信失敗パラメーターの設定

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。Subscription オブジェクトの delivery 設定を変更して、個別のサブスクリプションのイベント配信パラメーターを設定できます。Knative Eventing は、イベントの配信に失敗した場合にイベントに何が起こるかを制御するために使用できるサブスクリプションの設定パラメーターを提供します。

Subscription オブジェクトの例

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 に送信される前にイベント配信を再試行する回数。

5.7. イベントソースおよびイベントソースタイプの一覧表示

OpenShift Container Platform クラスターに存在する、または使用可能なすべてのイベントソースやイベントソースタイプのリストを表示することができます。OpenShift Container Platform Web コンソールの Knative(kn)CLI または Developer パースペクティブを使用し、利用可能なイベントソースまたはイベントソースタイプを一覧表示できます。

5.7.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示

Knative(kn)CLI を使用すると、クラスターで利用可能なイベントソースタイプを表示するための単純化された直感的なユーザーインターフェースが提供されます。kn source list-types CLI コマンドを使用して、クラスターで作成して使用できるイベントソースタイプを一覧表示できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • Knative (kn) 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

5.7.2. Developer パースペクティブ内での利用可能なイベントソースタイプの表示

クラスターで使用可能なすべてのイベントソースタイプを一覧表示することができます。OpenShift Container Platform Web コンソールを使用すると、使用可能なイベントソースタイプを表示するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. Developer パースペクティブにアクセスします。
  2. +Add をクリックします。
  3. Event source をクリックします。
  4. 利用可能なイベントソースタイプを表示します。

5.7.3. Knative CLI の使用による利用可能なイベントリソースの一覧表示

Knative(kn)CLI を使用すると、クラスター上の既存のイベントソースを表示するための単純化された直感的なユーザーインターフェースが提供されます。kn source list コマンドを使用して、既存のイベントソースを一覧表示できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。

手順

  1. ターミナルにある既存のイベントソースを一覧表示します。

    $ 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

  2. オプションで、--type フラグを使用して、特定タイプのイベントソースのみを一覧表示できます。

    $ kn source list --type <event_source_type>

    コマンドの例

    $ kn source list --type PingSource

    出力例

    NAME   TYPE              RESOURCE                               SINK         READY
    p1     PingSource        pingsources.sources.knative.dev        ksvc:eshow1   True

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

API サーバーソースは、Knative サービスなどのイベントシンクを Kubernetes API サーバーに接続するために使用できるイベントソースです。API サーバーソースは Kubernetes イベントを監視し、それらを Knative Eventing ブローカーに転送します。

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

Knative Eventing がクラスターにインストールされると、Web コンソールを使用して API サーバーソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift (oc) CLI がインストールされている。
手順

既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。

  1. イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    この namespace を、イベントソースのインストールに選択した namespace に変更します。
  2. YAML ファイルを適用します。

    $ oc apply -f <filename>
  3. Developer パースペクティブで、+AddEvent Source に移動します。Event Sources ページが表示されます。
  4. オプション: イベントソースに複数のプロバイダーがある場合は、Providers 一覧から必要なプロバイダーを選択し、プロバイダーから利用可能なイベントソースをフィルターします。
  5. ApiServerSource を選択してから Create Event Source をクリックします。Create Event Source ページが表示されます。
  6. Form view または YAML view を使用して、ApiServerSource 設定を構成します。

    注記

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

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

検証

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

    ApiServerSource Topology ビュー
注記

URI シンクが使用される場合、URI sinkEdit URI を右クリックして URI を変更します。

API サーバーソースの削除

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

    ApiServerSource の削除

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

kn source apiserver create コマンドを使用し、kn CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift (oc) CLI がインストールされている。
  • Knative (kn) CLI をインストールしている。
手順

既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。

  1. イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    この namespace を、イベントソースのインストールに選択した namespace に変更します。
  2. YAML ファイルを適用します。

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

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
  4. API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。

    $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  5. ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、default のブローカーからサービスへのイベントをフィルタリングします。

    $ kn trigger create <trigger_name> --sink ksvc:<service_name>
  6. デフォルト namespace で Pod を起動してイベントを作成します。

    $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  7. 以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ kn source apiserver describe <source_name>

    出力例

    Name:                mysource
    Namespace:           default
    Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
    Age:                 3m
    ServiceAccountName:  events-sa
    Mode:                Resource
    Sink:
      Name:       default
      Namespace:  default
      Kind:       Broker (eventing.knative.dev/v1)
    Resources:
      Kind:        event (v1)
      Controller:  false
    Conditions:
      OK TYPE                     AGE REASON
      ++ Ready                     3m
      ++ Deployed                  3m
      ++ SinkProvided              3m
      ++ SufficientPermissions     3m
      ++ EventTypesProvided        3m

検証

メッセージダンパー機能ログを確認して、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",
        ...
      }

API サーバーソースの削除

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

    $ kn trigger delete <trigger_name>
  2. イベントソースを削除します。

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

    $ oc delete -f authentication.yaml

5.8.2.1. Knative CLI シンクフラグ

Knative (kn) CLI を使用してイベントソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

シンクフラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

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

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述することができます。YAML を使用して API サーバーソースを作成するには、ApiServerSource オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • API サーバーソース YAML ファイルで定義されるものと同じ namespace にdefault ブローカーを作成している。
  • OpenShift (oc) CLI をインストールしている。
手順

既存のサービスアカウントを再利用する必要がある場合には、既存の ServiceAccount リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。

  1. イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    この namespace を、イベントソースのインストールに選択した namespace に変更します。
  2. YAML ファイルを適用します。

    $ oc apply -f <filename>
  3. API サーバーソースを YAML ファイルとして作成します。

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      name: testevents
    spec:
      serviceAccountName: events-sa
      mode: Resource
      resources:
        - apiVersion: v1
          kind: Event
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default
  4. ApiServerSource YAML ファイルを適用します。

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

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: event-display
      namespace: default
    spec:
      template:
        spec:
          containers:
            - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  6. Service YAML ファイルを適用します。

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

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      name: event-display-trigger
      namespace: default
    spec:
      broker: default
      subscriber:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display
  8. Trigger YAML ファイルを適用します。

    $ oc apply -f <filename>
  9. デフォルト namespace で Pod を起動してイベントを作成します。

    $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display
  10. 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。

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

    出力例

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

検証

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

API サーバーソースの削除

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

    $ oc delete -f trigger.yaml
  2. イベントソースを削除します。

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

    $ oc delete -f authentication.yaml

5.9. ping ソースの作成

ping ソースは、一定のペイロードを使用して ping イベントをイベントコンシューマーに定期的に送信するために使用されるイベントソースです。ping ソースを使用すると、タイマーと同様にイベントの送信をスケジュールできます。

5.9.1. Web コンソールを使用した ping ソースの作成

Knative Eventing がクラスターにインストールされると、Web コンソールを使用して ping ソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
  • 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 ソースおよびシンクを表示します。

    Topology ビューでの ping ソースおよびサービスの表示

ping ソースの削除

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

5.9.2. Knative CLI を使用した ping ソースの作成

kn source ping create コマンドを使用して、Knative(kn)CLI を使用して ping ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • オプション: この手順の検証手順を使用する場合は、OpenShift (oc) 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!"
      }

ping ソースの削除

  • ping ソースを削除します。

    $ kn delete pingsources.sources.knative.dev <ping_source_name>

5.9.2.1. Knative CLI シンクフラグ

Knative (kn) CLI を使用してイベントソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

シンクフラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

5.9.3. YAML を使用した ping ソースの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述することができます。YAML を使用してサーバーレス ping を作成するには、PingSource オブジェクトを定義する YAML ファイルを作成し、oc apply を使用してこれを適用する必要があります。

PingSource オブジェクトの例

apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: test-ping-source
spec:
  schedule: "*/2 * * * *" 1
  data: '{"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 サービスを使用しています。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
  • OpenShift (oc) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

    1. サービス YAML ファイルを作成します。

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    2. サービスを作成します。

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

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

      apiVersion: sources.knative.dev/v1
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        data: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
    2. ping ソースを作成します。

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

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

    出力例

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

検証

シンク 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!"
      }

ping ソースの削除

  • ping ソースを削除します。

    $ oc delete -f <filename>

    コマンドの例

    $ oc delete -f ping-source.yaml

5.10. カスタムイベントソース

Knative に含まれていないイベントプロデューサーや、CloudEvent 形式ではないイベントを生成するプロデューサーからイベントを Ingress する必要がある場合は、カスタムイベントソースを使用してこれを実行できます。カスタムイベントソースは、次のいずれかの方法で作成できます。

  • シンクバインディングを作成して、PodSpecable オブジェクトをイベントソースとして使用します。
  • コンテナーソースを作成して、コンテナーをイベントソースとして使用します。

5.10.1. シンクバインディング

SinkBinding オブジェクトは、イベント生成を配信アドレス指定から切り離すことをサポートします。シンクバインディングは、イベントプロデューサー をイベントコンシューマーまたは シンク に接続するために使用されます。イベントプロデューサーは、PodSpec テンプレートを組み込む Kubernetes リソースであり、イベントを生成します。シンクは、イベントを受信できるアドレス指定可能な Kubernetes オブジェクトです。

SinkBinding オブジェクトは、環境変数をシンクの PodTemplateSpec に挿入します。つまり、アプリケーションコードが Kubernetes API と直接対話してイベントの宛先を見つける必要はありません。これらの環境変数は以下のとおりです。

K_SINK
解決されたシンクの URL。
K_CE_OVERRIDES
アウトバウンドイベントの上書きを指定する JSON オブジェクト。

5.10.1.1. YAML を使用したシンクバインディングの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でイベントソースを宣言的に記述することができます。YAML を使用してシンクバインディングを作成するには、SinkBinding オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
  • OpenShift (oc) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

    1. サービス YAML ファイルを作成します。

      サービス YAML ファイルの例

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

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

      $ oc apply -f <filename>
  2. イベントをサービスに転送するシンクバインディングインスタンスを作成します。

    1. シンクバインディング YAML ファイルを作成します。

      サービス 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. シンクバインディングを作成します。

      $ oc apply -f <filename>
  3. CronJob オブジェクトを作成します。

    1. cron ジョブの YAML ファイルを作成します。

      cron ジョブの YAML ファイルの例

      apiVersion: batch/v1
      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/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. cron ジョブを作成します。

      $ oc apply -f <filename>
  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": ""
      }

5.10.1.2. Knative CLI を使用したシンクバインディングの作成

kn source binding create コマンドを使用して、Knative(kn)CLI を使用してシンクバインディングを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Knative (kn) CLI をインストールしている。
  • OpenShift (oc) CLI をインストールしている。
注記

以下の手順では、YAML ファイルを作成する必要があります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

手順

  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 オブジェクトを作成します。

    1. cron ジョブの YAML ファイルを作成します。

      cron ジョブの YAML ファイルの例

      apiVersion: batch/v1
      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/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. cron ジョブを作成します。

      $ oc apply -f <filename>
  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": ""
      }

5.10.1.2.1. Knative CLI シンクフラグ

Knative (kn) CLI を使用してイベントソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

シンクフラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

5.10.1.3. Web コンソールを使用したシンクバインディングの作成

Knative Eventing がクラスターにインストールされると、Web コンソールを使用して シンクバインディングを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • 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 ジョブを表示します。

    Topology ビューでのシンクバインディングおよびサービスの表示
  3. シンクバインディングが追加されると、正常なジョブが cron ジョブによって登録されていることを確認します。つまり、シンクバインディングは cron ジョブで作成されたジョブが正常に再設定されることを意味します。
  4. event-display サービス Pod のログを参照し、ハートビート cron ジョブで生成されるイベントを表示します。

5.10.1.4. シンクバインディング参照

シンクバインディングを作成して、PodSpecable オブジェクトをイベントソースとして使用できます。SinkBinding オブジェクトを作成するときに、複数のパラメーターを設定できます。

SinkBinding オブジェクトは以下のパラメーターをサポートします。

フィールド説明必須またはオプション

apiVersion

API バージョンを指定します(例: sources.knative.dev/v1)。

必須

kind

このリソースオブジェクトを SinkBinding オブジェクトとして特定します。

必須

metadata

SinkBinding オブジェクトを一意に識別するメタデータを指定します。たとえば、name です。

必須

spec

この SinkBinding オブジェクトの設定情報を指定します。

必須

spec.sink

シンクとして使用する URI に解決するオブジェクトへの参照。

必須

spec.subject

ランタイムコントラクトがバインディング実装によって拡張されるリソースを参照します。

必須

spec.ceOverrides

上書きを定義して、シンクに送信されたイベントへの出力形式および変更を制御します。

任意

5.10.1.4.1. Subject パラメーター

Subject パラメーターは、ランタイムコントラクトがバインディング実装によって拡張されるリソースを参照します。Subject 定義に複数のフィールドを設定できます。

Subject 定義は、以下のフィールドをサポートします。

フィールド説明必須またはオプション

apiVersion

参照先の API バージョン。

必須

kind

参照先の種類。

必須

namespace

参照先の namespace。省略されている場合、デフォルトはオブジェクトの namespace に設定されます。

任意

name

参照先の名前。

selector を設定する場合は、使用しないでください。

selector

参照先のセレクター。

name を設定する場合は、使用しないでください。

selector.matchExpressions

ラベルセレクターの要件の一覧です。

matchExpressions または matchLabels のいずれかのみを使用します。

selector.matchExpressions.key

セレクターが適用されるラベルキー。

matchExpressions を使用する場合に必須です。

selector.matchExpressions.operator

キーと値のセットの関係を表します。有効な演算子は InNotInExists、および DoesNotExistです。

matchExpressions を使用する場合に必須です。

selector.matchExpressions.values

文字列値の配列。operator パラメーターの値が In または NotIn の場合、値配列が空でないようにする必要があります。operator パラメーターの値が Exists または DoesNotExist の場合、値の配列は空である必要があります。この配列は、ストラテジーに基づいたマージパッチの適用中に置き換えられます。

matchExpressions を使用する場合に必須です。

selector.matchLabels

キーと値のペアのマップ。matchLabels マップの各キーと値のペアは matchExpressions の要素と同じです。ここで、キーフィールドは matchLabels.<key> で、operatorIn で、values の配列には matchLabels.<value> のみが含まれます。

matchExpressions または matchLabels のいずれかのみを使用します。

サブジェクトパラメーターの例

以下の YAML の場合は、default namespace の mysubject という名前の Deployment オブジェクトが選択されます。

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  subject:
    apiVersion: apps/v1
    kind: Deployment
    namespace: default
    name: mysubject
  ...

以下の YAML の場合、default namespace にラベル working=example が設定された Job オブジェクトが選択されます。

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  subject:
    apiVersion: batch/v1
    kind: Job
    namespace: default
    selector:
      matchLabels:
        working: example
  ...

以下の YAML の場合、default namespace にラベル working=example または working=sample が含まれる Pod オブジェクトが選択されます。

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  subject:
    apiVersion: v1
    kind: Pod
    namespace: default
    selector:
      - matchExpression:
        key: working
        operator: In
        values:
          - example
          - sample
  ...
5.10.1.4.2. CloudEvent オーバーライド

ceOverrides 定義は、シンクに送信される CloudEvent の出力形式および変更を制御するオーバーライドを提供します。ceOverrides 定義に複数のフィールドを設定できます。

ceOverrides の定義は、以下のフィールドをサポートします。

フィールド説明必須またはオプション

extensions

アウトバウンドイベントで追加または上書きされる属性を指定します。各 extensions のキーと値のペアは、属性拡張機能としてイベントに個別に設定されます。

任意

注記

拡張子として許可されるのは、有効な CloudEvent 属性名のみです。拡張機能オーバーライド構成から仕様定義属性を設定することはできません。たとえば、type 属性を変更することはできません。

CloudEvent オーバーライドの例

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  ...
  ceOverrides:
    extensions:
      extra: this is an extra attribute
      additional: 42

これにより、subjectK_CE_OVERRIDES 環境変数が設定されます。

出力例

{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }

5.10.1.4.3. include ラベル

シンクバインディングを使用するには、bindings.knative.dev/include: "true" ラベルをリソースまたはリソースが含まれる namespace のいずれかに割り当てる必要があります。リソース定義にラベルが含まれていない場合には、クラスター管理者は以下を実行してこれを namespace に割り当てることができます。

$ oc label namespace <namespace> bindings.knative.dev/include=true

5.10.2. コンテナーソース

コンテナーソースは、イベントを生成し、イベントをシンクに送信するコンテナーイメージを作成します。コンテナーソースを使用して、イメージ URI を使用するコンテナーイメージおよび ContainerSource オブジェクトを作成して、カスタムイベントソースを作成できます。

5.10.2.1. コンテナーイメージを作成するためのガイドライン

コンテナーソースコントローラーには、K_SINK および K_CE_OVERRIDES の 2 つの環境変数が注入されます。これらの変数は、それぞれ sink および ceOverrides 仕様から解決されます。イベントは、K_SINK 環境変数で指定されたシンク URI に送信されます。メッセージは、CloudEvent HTTP 形式を使用して POST として送信する必要があります。

コンテナーイメージの例

以下は、ハートビートコンテナーイメージの例になります。

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

5.10.2.2. Knative CLI を使用したコンテナーソースの作成および管理

kn source container コマンドを使用して、Knative(kn)CLI を使用してコンテナーソースを作成し、管理できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

コンテナーソースを作成します。

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

5.10.2.3. Web コンソールを使用したコンテナーソースの作成

Knative Eventing がクラスターにインストールされると、Web コンソールを使用してコンテナーソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、イベントソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • 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 をクリックします。

5.10.2.4. コンテナーソースのリファレンス

ContainerSource オブジェクトを作成することにより、コンテナーをイベントソースとして使用できます。ContainerSource オブジェクトを作成するときに、複数のパラメーターを設定できます。

ContainerSource オブジェクトは以下のフィールドをサポートします。

フィールド説明必須またはオプション

apiVersion

API バージョンを指定します(例: sources.knative.dev/v1)。

必須

kind

このリソースオブジェクトを ContainerSource オブジェクトとして特定します。

必須

metadata

ContainerSource オブジェクトを一意に識別するメタデータを指定します。たとえば、name です。

必須

spec

この ContainerSource オブジェクトの設定情報を指定します。

必須

spec.sink

シンクとして使用する URI に解決するオブジェクトへの参照。

必須

spec.template

ContainerSource オブジェクトの template 仕様。

必須

spec.ceOverrides

上書きを定義して、シンクに送信されたイベントへの出力形式および変更を制御します。

任意

テンプレートパラメーターの例

apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: test-heartbeats
spec:
  template:
    spec:
      containers:
        - image: quay.io/openshift-knative/heartbeats:latest
          name: heartbeats
          args:
            - --period=1
          env:
            - name: POD_NAME
              value: "mypod"
            - name: POD_NAMESPACE
              value: "event-test"
  ...

5.10.2.4.1. CloudEvent オーバーライド

ceOverrides 定義は、シンクに送信される CloudEvent の出力形式および変更を制御するオーバーライドを提供します。ceOverrides 定義に複数のフィールドを設定できます。

ceOverrides の定義は、以下のフィールドをサポートします。

フィールド説明必須またはオプション

extensions

アウトバウンドイベントで追加または上書きされる属性を指定します。各 extensions のキーと値のペアは、属性拡張機能としてイベントに個別に設定されます。

任意

注記

拡張子として許可されるのは、有効な CloudEvent 属性名のみです。拡張機能オーバーライド構成から仕様定義属性を設定することはできません。たとえば、type 属性を変更することはできません。

CloudEvent オーバーライドの例

apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: test-heartbeats
spec:
  ...
  ceOverrides:
    extensions:
      extra: this is an extra attribute
      additional: 42

これにより、subjectK_CE_OVERRIDES 環境変数が設定されます。

出力例

{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }

5.11. チャネルの作成

チャネルは、単一のイベント転送および永続レイヤーを定義するカスタムリソースです。イベントがイベントソースまたは生成側からチャネルに送信された後に、これらのイベントはサブスクリプションを使用して複数の Knative サービスまたは他のシンクに送信できます。

チャネルワークフローの概要

サポートされている Channel オブジェクトをインスタンス化することでチャネルを作成し、Subscription オブジェクトの delivery 仕様を変更して再配信の試行を設定できます。

5.11.1. Web コンソールを使用したチャネルの作成

OpenShift Container Platform Web コンソールを使用すると、チャネルを作成するための合理的で直感的なユーザーインターフェースが提供されます。Knative Eventing がクラスターにインストールされると、Web コンソールを使用してチャネルを作成できます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. Developer パースペクティブで、+AddChannel に移動します。
  2. タイプ リストで、作成する Channel オブジェクトのタイプを選択します。
  3. Create をクリックします。

検証

  • Topology ページに移動して、チャネルが存在することを確認します。

    Topology ビューでチャネルの表示

5.11.2. Knative CLI を使用したチャネルの作成

Knative(kn)CLI を使用してチャネルを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。kn channel create コマンドを使用してチャネルを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • Knative (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

チャネルの削除

  • チャネルを削除します。

    $ kn channel delete <channel_name>

5.11.3. YAML を使用したデフォルト実装チャネルの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述することができます。YAML を使用してサーバーレスチャネルを作成するには、Channel オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • OpenShift (oc) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

    apiVersion: messaging.knative.dev/v1
    kind: Channel
    metadata:
      name: example-channel
      namespace: default
  2. YAML ファイルを適用します。

    $ oc apply -f <filename>

5.11.4. YAML を使用した Kafka チャネルの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述することができます。Kafka チャネルを作成することで、Kafka トピックに裏打ちされた Knative Eventing チャネルを作成できます。YAML を使用して Kafka チャネルを作成するには、KafkaChannel オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka カスタムリソースは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift (oc) CLI をインストールしている。
  • 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>

5.11.5. 次のステップ

5.12. サブスクリプションの作成および管理

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。サブスクリプションは、イベントを配信するチャネルとシンク (サブスクライバーとも呼ばれます) を指定する Subscription オブジェクトを設定することによって作成されます。障害の処理方法など、シンク固有のオプションを指定することもできます。

5.12.1. Web コンソールを使用したサブスクリプションの作成

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。OpenShift Container Platform Web コンソールを使用すると、サブスクリプションを作成するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • Knative サービスおよびチャネルなどのイベントシンクを作成している。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. Developer パースペクティブで、Topology ページに移動します。
  2. 以下の方法のいずれかを使用してサブスクリプションを作成します。

    1. サブスクリプションを作成するチャネルにカーソルを合わせ、矢印をドラッグします。Add Subscription オプションが表示されます。

      チャネルのサブスクリプションの作成
      1. Subscriber 一覧でシンクを選択します。
      2. Add をクリックします。
    2. このサービスが、チャネルと同じ namespace またはプロジェクトにある Topology ビューで利用可能な場合は、サブスクリプションを作成するチャネルをクリックし、矢印をサービスに直接ドラッグして、チャネルからそのサービスにサブスクリプションを即時に作成します。

検証

  • サブスクリプションの作成後に、これを Topology ビューでチャネルをサービスに接続する行として表示できます。

    Topology ビューのサブスクリプション

5.12.2. YAML を使用したサブスクリプションの作成

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でサブスクリプションを宣言的に記述することができます。YAML を使用してサブスクリプションを作成するには、Subscription オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
  • OpenShift (oc) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

5.12.3. Knative CLI を使用したサブスクリプションの作成

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。Knative(kn)CLI を使用してサブスクリプションを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。適切なフラグと共に kn subscription create コマンドを使用して、サブスクリプションを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (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

サブスクリプションの削除

  • サブスクリプションを削除します。

    $ kn subscription delete <subscription_name>

5.12.4. Knative CLI を使用したサブスクリプションの記述

kn subscription describe コマンドを使用して、Knative(kn)CLI を使用してターミナルでサブスクリプションについての情報を出力できます。Knative CLI を使用してサブスクリプションを記述すると、YAML ファイルを直接表示するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

前提条件

  • Knative (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

5.12.5. Knative CLI を使用したサブスクリプションの一覧表示

Knative(kn)CLI を使用して、kn subscription list コマンドを使用してクラスターの既存のサブスクリプションを一覧表示できます。Knative CLI を使用してサブスクリプションを一覧表示すると、単純化された直感的なユーザーインターフェースが提供されます。

前提条件

  • Knative (kn) CLI をインストールしている。

手順

  • クラスターのサブスクリプションを一覧表示します。

    $ kn subscription list

    出力例

    NAME             CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
    mysubscription   Channel:mychannel   ksvc:event-display                              True

5.12.6. Knative CLI を使用したサブスクリプションの更新

kn subscription update コマンドおよび適切なフラグを使用し、Knative(kn)CLI を使用してターミナルからサブスクリプションを更新できます。Knative CLI を使用してサブスクリプションを更新すると、YAML ファイルを直接更新するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

前提条件

  • Knative (kn) CLI をインストールしている。
  • サブスクリプションを作成している。

手順

  • サブスクリプションを更新します。

    $ 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

5.12.7. サブスクリプションを使用したイベント配信失敗パラメーターの設定

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。Subscription オブジェクトの delivery 設定を変更して、個別のサブスクリプションのイベント配信パラメーターを設定できます。Knative Eventing は、イベントの配信に失敗した場合にイベントに何が起こるかを制御するために使用できるサブスクリプションの設定パラメーターを提供します。

Subscription オブジェクトの例

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 に送信される前にイベント配信を再試行する回数。

5.13. ブローカー

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。

ブローカーイベント配信の概要

5.13.1. ブローカータイプ

OpenShift Serverless で使用できるブローカー実装は複数あり、それぞれのブローカー実装が異なるイベント配信保証を持ち、異なる基礎となるテクノロジーを使用します。ブローカークラスを指定して、ブローカーの作成時にブローカー実装を選択できます。指定しない場合は、デフォルトのブローカークラスが使用されます。デフォルトのブローカークラスは、クラスター管理者によって設定できます。

5.13.1.1. チャネルベースのブローカー

チャネルベースのブローカー実装は、内部的にイベント配信にチャネルを使用します。チャネルベースのブローカーは、ブローカーインスタンスが使用するチャネルの実装に基づいて、異なるイベント配信保証を提供します。以下に例を示します。

  • InMemoryChannel 実装を使用するブローカーは、開発およびテストの目的で役立ちますが、実稼働環境に対しては適切なイベント配信保証を提供しません。
  • KafkaChannel 実装を使用するブローカーは、実稼働環境に必要なイベント配信保証を提供します。

5.13.1.2. Kafka ブローカー

Kafka ブローカーは、Kafka を内部的に使用して、少なくとも 1 回の配信保証を提供するブローカー実装です。複数の Kafka バージョンをサポートし、イベントの保存およびルーティングのために Kafka とネイティブに統合されています。

重要

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

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

5.13.2. デフォルト設定を使用するブローカーの作成

OpenShift Serverless は、Knative(kn)CLI を使用して作成できる デフォルト の Knative ブローカーを提供します。また、eventing.knative.dev/injection: enabled アノテーションに追加するか、または eventing.knative.dev/injection=enabled ラベルを namespace に追加して、 default ブローカーを作成することもできます。

5.13.2.1. Knative CLI を使用したブローカーの作成

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。Knative(kn)CLI を使用してブローカーを作成すれば、YAML ファイルを直接変更することにより、より効率的な直感的なユーザーインターフェースが提供されます。kn broker create コマンドを使用してブローカーを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • 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 ビューに移動し、ブローカーが存在することを確認できます。

    Web コンソールの Topology ビューでのブローカーの表示

5.13.2.2. トリガーのアノテーションによるブローカーの作成

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。eventing.knative.dev/injection: enabled アノテーションを Trigger オブジェクトに追加してブローカーを作成できます。

重要

knative-eventing-injection: enabled アノテーションを使用してブローカーを作成する場合、クラスター管理者のパーミッションなしにこのブローカーを削除することはできません。クラスター管理者が最初にこのアノテーションを削除せずにブローカーを削除する場合、ブローカーは削除後に再び作成されます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift (oc) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  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. オプション: OpenShift Container Platform Web コンソールを使用している場合、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。

    Web コンソールの Topology ビューでのブローカーの表示

5.13.2.3. namespace へのラベル付けによるブローカーの作成

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。所有しているか、または書き込みパーミッションのある namespace にラベルを付けて default ブローカーを自動的に作成できます。

注記

この方法を使用して作成されたブローカーは、ラベルを削除すると削除されません。これらは手動で削除する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • OpenShift (oc) CLI をインストールしている。
  • 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. オプション: OpenShift Container Platform Web コンソールを使用している場合、Developer パースペクティブの Topology ビューに移動し、ブローカーが存在することを確認できます。

    Web コンソールの Topology ビューでのブローカーの表示

5.13.2.4. 挿入 (injection) によって作成されたブローカーの削除

挿入によりブローカーを作成し、後でそれを削除する必要がある場合は、手動で削除する必要があります。namespace ラベルまたはトリガーアノテーションを使用して作成されたブローカーは、ラベルまたはアノテーションを削除した場合に永続的に削除されません。

前提条件

  • OpenShift (oc) CLI をインストールしている。

手順

  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

5.13.2.5. Web コンソールを使用してブローカーを作成する

Knative Eventing がクラスターにインストールされた後、Web コンソールを使用してブローカーを作成できます。OpenShift Container Platform Web コンソールを使用すると、ブローカーを作成するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. Developer パースペクティブで、+AddBroker に移動します。Broker ページが表示されます。
  2. オプション:ブローカーの Name を更新します。名前を更新しない場合、生成されたブローカーの名前は default になります。
  3. Create をクリックします。

検証

トポロジー ページでブローカーコンポーネントを表示することにより、ブローカーが作成されたことを確認できます。

  1. Developer パースペクティブで、Topology に移動します。
  2. mt-broker-ingressmt-broker-filter、および mt-broker-controller コンポーネントを表示します。

    トポロジービューでブローカーコンポーネントを表示する

5.13.3. Kafka ブローカー

Knative Kafka ブローカーは、Knative ブローカー API の Apache Kafka ネイティブ実装です。ブローカーに対して Kafka との統合が改善され、他のブローカータイプでモデルをトリガーし、ネットワークホップを削減します。

重要

現在テクノロジープレビューにある Kafka ブローカーは、FIPS ではサポートされていません。

Knative Kafka ブローカーは、バイナリーコンテンツモードを使用して、受信 CloudEvents を Kafka レコードとして保存します。つまり、すべての CloudEvent 属性とエクステンションは Kafka レコードのヘッダーとしてマッピングされ、CloudEvent の data 仕様は Kafka レコードの値に対応します。

クラスター管理者がデフォルトのブローカータイプとして Kafka を使用するように OpenShift Serverless デプロイメントを設定している場合、デフォルト設定を使用してブローカーを作成すると、Kafka ベースの Broker オブジェクトが作成されます。OpenShift Serverless デプロイメントがデフォルトのブローカータイプとして Kafka ブローカーを使用するように設定されていない場合は、以下の手順のいずれかを使用して、Kafka ベースのブローカーを作成できます。

重要

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

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

5.13.3.1. YAML を使用した Kafka ブローカーの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka ブローカーを作成するには、Broker オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka カスタムリソースは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift (oc) CLI がインストールされている。

手順

  1. Kafka ベースのブローカーを YAML ファイルとして作成します。

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka 1
      name: example-kafka-broker
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: kafka-broker-config 2
        namespace: knative-eventing
    1
    ブローカークラス。指定されていない場合、ブローカーはクラスター管理者の設定に従ってデフォルトクラスを使用します。Kafka ブローカーを使用するには、この値を Kafka にする必要があります。
    2
    Knative Kafka ブローカーのデフォルトの設定マップ。この設定マップは、クラスター管理者がクラスター上で Kafka ブローカー機能を有効にした場合に作成されます。
  2. Kafka ベースのブローカー YAML ファイルを適用します。

    $ oc apply -f <filename>

5.13.3.2. 外部で管理されている Kafka トピックを使用する Kafka ブローカーの作成

独自の内部トピックの作成を許可せずに Kafka ブローカーを使用する場合は、代わりに外部で管理される Kafka トピックを使用できます。これを実行するには、kafka.eventing.knative.dev/external.topic アノテーションを使用する Kafka Broker オブジェクトを作成する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka カスタムリソースは OpenShift Container Platform クラスターにインストールされます。
  • Red Hat AMQ Streams などの Kafka インスタンスにアクセスでき、Kafka トピックを作成しました。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift (oc) CLI がインストールされている。

手順

  1. Kafka ベースのブローカーを YAML ファイルとして作成します。

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka 1
        kafka.eventing.knative.dev/external.topic: <topic_name> 2
    ...
    1
    ブローカークラス。指定されていない場合、ブローカーはクラスター管理者の設定に従ってデフォルトクラスを使用します。Kafka ブローカーを使用するには、この値を Kafka にする必要があります。
    2
    使用する Kafka トピックの名前。
  2. Kafka ベースのブローカー YAML ファイルを適用します。

    $ oc apply -f <filename>

5.13.4. ブローカーの管理

Knative(kn)CLI は、ブローカーの一覧表示、説明、更新、および削除に使用できるコマンドを提供します。

5.13.4.1. Knative CLI を使用した既存ブローカーの一覧表示

Knative(kn)CLI を使用してブローカーをリストすると、単純化された直感的なユーザーインターフェースが提供されます。kn broker list コマンドを使用して、Knative CLI を使用してクラスターの既存ブローカーを一覧表示できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (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

5.13.4.2. Knative CLI を使用した既存ブローカーの記述

Knative(kn)CLI を使用してブローカーを記述すると、単純化された直感的なユーザーインターフェースが提供されます。kn broker describe コマンドを使用して、Knative CLI を使用してクラスター内の既存ブローカーについての情報を出力できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (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

5.13.5. 関連情報

5.14. トリガー

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。

ブローカーイベント配信の概要

5.14.1. Web コンソールを使用したトリガーの作成

OpenShift Container Platform Web コンソールを使用すると、トリガーを作成するための合理的で直感的なユーザーインターフェースが提供されます。Knative Eventing がクラスターにインストールされ、ブローカーが作成されると、Web コンソールを使用してトリガーを作成できます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • トリガーに接続するために、ブローカーおよび Knative サービスまたは他のイベントシンクを作成している。

手順

  1. Developer パースペクティブで、Topology ページに移動します。
  2. トリガーを作成するブローカーにカーソルを合わせ、矢印をドラッグします。Add Trigger オプションが表示されます。
  3. Add Trigger を クリックします。
  4. Subscriber 一覧でシンクを選択します。
  5. Add をクリックします。

検証

  • サブスクリプションの作成後に、これを Topology ページで表示できます。ここでは、ブローカーをイベントシンクに接続する線として表されます。

トリガーの削除

  1. Developer パースペクティブで、Topology ページに移動します。
  2. 削除するトリガーをクリックします。
  3. Actions コンテキストメニューで、Delete Trigger を選択します。

5.14.2. Knative CLI を使用したトリガーの作成

Knative(kn)CLI を使用してトリガーを作成し、YAML ファイルを直接変更することにより、より効率的な直感的なユーザーインターフェースを提供します。kn trigger create コマンドを使用してトリガーを作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • トリガーを作成します。

    $ 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 属性を使用すると、ブローカーからイベントをフィルターできるため、サブスクライバーは定義された基準に基づくイベントのサブセットのみを受け取ることができます。

5.14.3. Knative CLI の使用によるトリガーの一覧表示

Knative(kn)CLI を使用してトリガーの一覧を表示すると、単純化された直感的なユーザーインターフェースが提供されます。kn trigger list コマンドを使用して、クラスター内の既存トリガーを一覧表示できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (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

5.14.4. Knative CLI を使用したトリガーの記述

Knative(kn)CLI を使用してトリガーを記述すると、単純化された直感的なユーザーインターフェースが提供されます。kn trigger describe コマンドを使用して、Knative CLI を使用してクラスター内の既存のトリガーについての情報を出力できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (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

5.14.5. Knative CLI を使用したトリガーでのイベントのフィルター

Knative(kn)CLI を使用してトリガーを使用してイベントをフィルターすると、単純化された直感的なユーザーインターフェースが提供されます。kn trigger create コマンドを適切なフラグとともに使用し、トリガーを使用してイベントをフィルタリングできます。

以下のトリガーの例では、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

5.14.6. Knative CLI を使用したトリガーの更新

Knative(kn)CLI を使用してトリガーを更新することで、単純化された直感的なユーザーインターフェースが提供されます。特定のフラグを指定して kn trigger update コマンドを使用して、トリガーの属性を更新できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • トリガーを更新します。

    $ 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

5.14.7. Knative CLI を使用したトリガーの削除

Knative(kn)CLI を使用してトリガーを削除することで、単純化された直感的なユーザーインターフェースが提供されます。kn trigger delete コマンドを使用してトリガーを削除できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • トリガーを削除します。

    $ kn trigger delete <trigger_name>

検証

  1. 既存のトリガーを一覧表示します。

    $ kn trigger list
  2. トリガーが存在しないことを確認します。

    出力例

    No triggers found.

5.15. Knative Kafka の使用

Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。Kafka は、イベントソース、チャネル、ブローカー、およびイベントシンク機能のオプションを提供します。

Knative Kafka 機能は、クラスター管理者が KnativeKafka カスタムリソースをインストールしている場合に、OpenShift Serverless インストールで利用できます。

注記

現時点で、Knative Kafka は IBM Z および IBM Power ではサポートされていません。

Knative Kafka は、以下のような追加オプションを提供します。

  • Kafka ソース
  • Kafka チャネル
  • Kafka ブローカー (テクノロジープレビュー)
  • Kafka シンク (テクノロジープレビュー)

5.15.1. Kafka イベント配信およびリトライ

イベント駆動型のアーキテクチャーで Kafka コンポーネントを使用すると、「最低でも 1 度」のイベント配信が提供されます。これは、戻りコード値を受け取るまで操作がリトライされることを意味します。これにより、失われたイベントに対してアプリケーションの回復性が強化されます。ただし、重複するイベントが送信されてしまう可能性があります。

Kafka イベントソースでは、デフォルトでイベント配信のリトライ回数が固定されています。Kafka チャネルの場合、Kafka チャネルの Delivery 仕様に設定されている場合にのみリトライが実行されます。

配信保証に関する詳細は、イベント配信 のドキュメントを参照してください。

5.15.2. Kafka ソース

Apache Kafka クラスターからイベントを読み取り、これらのイベントをシンクに渡す Kafka ソースを作成できます。Kafka ソースを作成するには、OpenShift Container Platform Web コンソールの Knative (kn)CLI を使用するか、KafkaSource オブジェクトを YAML ファイルとして直接作成し、OpenShift (oc) CLI を使用して適用します。

5.15.2.1. Web コンソールを使用した Kafka イベントソースの作成

Knative Kafka をクラスターにインストールした後、Web コンソールを使用して Kafka ソースを作成できます。OpenShift Container Platform Web コンソールを使用すると、Kafka ソースを作成するための合理的で直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および KnativeKafka カスタムリソースがクラスターにインストールされている。
  • Web コンソールにログインしている。
  • インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  1. Developer パースペクティブで、+Add ページに移動し、Event Source を選択します。
  2. Event Sources ページで、Type セクションの Kafka Source を選択します。
  3. Kafka Source 設定を設定します。

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

検証

Topology ページを表示して、Kafka イベントソースが作成され、シンクに接続されていることを確認できます。

  1. Developer パースペクティブで、Topology に移動します。
  2. Kafka イベントソースおよびシンクを表示します。

    Topology ビューでの Kafka ソースおよびサービスの表示

5.15.2.2. Knative CLI を使用した Kafka イベントソースの作成

Knative(kn)CLI を使用して、kn source kafka create コマンドを使用して Kafka ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するのではなく、より効率的な直感的なユーザーインターフェースが提供されます。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、Knative Serving、および KnativeKafka カスタムリソース (CR) がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
  • Knative (kn) CLI をインストールしている。
  • オプション: この手順で検証ステップを使用する場合は、OpenShift (oc) CLI をインストールします。

手順

  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!

5.15.2.2.1. Knative CLI シンクフラグ

Knative (kn) CLI を使用してイベントソースを作成する場合、--sink フラグを使用して、イベントがリソースから送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。

以下の例では、サービスの http://event-display.svc.cluster.local をシンクとして使用するシンクバインディングを作成します。

シンクフラグを使用したコマンドの例

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクのプレフィックスには、channel および broker が含まれます。

5.15.2.3. YAML を使用した Kafka イベントソースの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka ソースを作成するには、KafkaSource オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および KnativeKafka カスタムリソースがクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
  • OpenShift CLI (oc) をインストールします。

手順

  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

5.15.3. Kafka ブローカー

Knative Kafka ブローカーは、Knative ブローカー API の Apache Kafka ネイティブ実装です。ブローカーに対して Kafka との統合が改善され、他のブローカータイプでモデルをトリガーし、ネットワークホップを削減します。

重要

現在テクノロジープレビューにある Kafka ブローカーは、FIPS ではサポートされていません。

Knative Kafka ブローカーは、バイナリーコンテンツモードを使用して、受信 CloudEvents を Kafka レコードとして保存します。つまり、すべての CloudEvent 属性とエクステンションは Kafka レコードのヘッダーとしてマッピングされ、CloudEvent の data 仕様は Kafka レコードの値に対応します。

クラスター管理者がデフォルトのブローカータイプとして Kafka を使用するように OpenShift Serverless デプロイメントを設定している場合、デフォルト設定を使用してブローカーを作成すると、Kafka ベースの Broker オブジェクトが作成されます。OpenShift Serverless デプロイメントがデフォルトのブローカータイプとして Kafka ブローカーを使用するように設定されていない場合は、以下の手順のいずれかを使用して、Kafka ベースのブローカーを作成できます。

重要

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

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

5.15.3.1. YAML を使用した Kafka ブローカーの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka ブローカーを作成するには、Broker オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka カスタムリソースは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift (oc) CLI がインストールされている。

手順

  1. Kafka ベースのブローカーを YAML ファイルとして作成します。

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka 1
      name: example-kafka-broker
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: kafka-broker-config 2
        namespace: knative-eventing
    1
    ブローカークラス。指定されていない場合、ブローカーはクラスター管理者の設定に従ってデフォルトクラスを使用します。Kafka ブローカーを使用するには、この値を Kafka にする必要があります。
    2
    Knative Kafka ブローカーのデフォルトの設定マップ。この設定マップは、クラスター管理者がクラスター上で Kafka ブローカー機能を有効にした場合に作成されます。
  2. Kafka ベースのブローカー YAML ファイルを適用します。

    $ oc apply -f <filename>

5.15.3.2. 外部で管理されている Kafka トピックを使用する Kafka ブローカーの作成

独自の内部トピックの作成を許可せずに Kafka ブローカーを使用する場合は、代わりに外部で管理される Kafka トピックを使用できます。これを実行するには、kafka.eventing.knative.dev/external.topic アノテーションを使用する Kafka Broker オブジェクトを作成する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka カスタムリソースは OpenShift Container Platform クラスターにインストールされます。
  • Red Hat AMQ Streams などの Kafka インスタンスにアクセスでき、Kafka トピックを作成しました。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift (oc) CLI がインストールされている。

手順

  1. Kafka ベースのブローカーを YAML ファイルとして作成します。

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka 1
        kafka.eventing.knative.dev/external.topic: <topic_name> 2
    ...
    1
    ブローカークラス。指定されていない場合、ブローカーはクラスター管理者の設定に従ってデフォルトクラスを使用します。Kafka ブローカーを使用するには、この値を Kafka にする必要があります。
    2
    使用する Kafka トピックの名前。
  2. Kafka ベースのブローカー YAML ファイルを適用します。

    $ oc apply -f <filename>

5.15.4. YAML を使用した Kafka チャネルの作成

YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でチャネルを宣言的に記述することができます。Kafka チャネルを作成することで、Kafka トピックに裏打ちされた Knative Eventing チャネルを作成できます。YAML を使用して Kafka チャネルを作成するには、KafkaChannel オブジェクトを定義する YAML ファイルを作成し、oc apply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka カスタムリソースは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift (oc) CLI をインストールしている。
  • 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>

5.15.5. Kafka シンクコ

Kafka シンクは、クラスター管理者がクラスターで Kafka を有効にした場合に使用できるイベントシンクの一種です。Kafka シンクを使用して、イベントソースから Kafka トピックにイベントを直接送信できます。

重要

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

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

5.15.5.1. Kafka シンクの使用

Kafka トピックにイベントを送信する Kafka シンクと呼ばれるイベントシンクを作成できます。YAML ファイルを使用して Knative リソースを作成する場合、宣言的 API を使用するため、再現性の高い方法でアプリケーションを宣言的に記述することができます。YAML を使用して Kafka シンクを作成するには、KafkaSink オブジェクトを定義する YAML ファイルを作成してから、ocapply コマンドを使用してそれを適用する必要があります。

前提条件

  • OpenShift Serverless Operator、Knative Serving、および KnativeKafka カスタムリソース (CR) がクラスターにインストールされている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
  • OpenShift (oc) CLI をインストールしている。

手順

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

    Kafka シンク YAML

    apiVersion: eventing.knative.dev/v1alpha1
    kind: KafkaSink
    metadata:
      name: <sink-name>
      namespace: <namespace>
    spec:
      topic: <topic-name>
      bootstrapServers:
       - <bootstrap-server>

  2. Kafka シンクを作成するには、KafkaSink YAML ファイルを適用します。

    $ oc apply -f <filename>
  3. シンクが仕様で指定されるようにイベントソースを設定します。

    API サーバーソースに接続された Kafka シンクの例

    apiVersion: sources.knative.dev/v1alpha2
    kind: ApiServerSource
    metadata:
      name: <source-name> 1
      namespace: <namespace> 2
    spec:
      serviceAccountName: <service-account-name> 3
      mode: Resource
      resources:
      - apiVersion: v1
        kind: Event
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1alpha1
          kind: KafkaSink
          name: <sink-name> 4

    1
    イベントソースの名前。
    2
    イベントソースの名前空間。
    3
    イベントソースのサービスアカウント。
    4
    Kafka シンクの名前。

5.15.6. 関連情報

第6章 管理

6.1. グローバル設定

OpenShift Serverless Operator は、KnativeServing および KnativeEventing カスタムリソースからシステムの 設定マップ への値の反映を含む Knative インストールのグローバル設定を管理します。手動で適用される設定マップの更新は Operator によって上書きされます。ただし、Knative カスタムリソースを変更すると、これらの設定マップの値を設定できます。

Knative には、名前にプレフィックス config- が付けられた複数の設定マップがあります。すべての Knative 設定マップは、適用するカスタムリソースと同じ namespace に作成されます。たとえば、KnativeServing カスタムリソースが knative-serving namespace に作成される場合、すべての Knative Serving 設定マップもこの namespace に作成されます。

Knative カスタムリソースの spec.config には、設定マップごとにconfig-<name> という名前の <name> エントリーが1つあり、設定マップ data で使用される値を持ちます。

6.1.1. デフォルトチャネル実装の設定

default-ch-webhook 設定マップを使用して、Knative Eventing のデフォルトのチャネル実装を指定できます。デフォルトのチャネル実装は、クラスター全体、および 1 つ以上の namespace に対して指定できます。現在、InMemoryChannel および KafkaChannel チャネルタイプがサポートされています。

前提条件

  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
  • デフォルトのチャネル実装として Kafka チャネルを使用する場合は、クラスターに KnativeKafka CR もインストールする必要があります。

手順

  • 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 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。

6.1.2. scale-to-zero の有効化

Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング(autoscaling)を提供します。enable-scale-to-zero 仕様を使用して、クラスター上のアプリケーションの scale-to-zero をグローバルに有効または無効にすることができます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • クラスター管理者のパーミッション。
  • デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。

手順

  • KnativeServing カスタムリソース (CR) の enable-scale-to-zero 仕様を変更します。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          enable-scale-to-zero: "false" 1

    1
    enable-scale-to-zero 仕様は、「true」または「false」 のいずれかです。true に設定すると、scale-to-zero が有効にされます。false に設定すると、アプリケーションは設定された スケーリング下限 にスケールダウンされます。デフォルト値は "true"です。

6.1.3. scale-to-zero 猶予期間の設定

Knative Serving は、アプリケーションの Pod をゼロにスケールダウンします。scale-to-zero-grace-period 仕様を使用して、アプリケーションの最後のレプリカが削除される前に Knative が scale-to-zero 機構が配置されるのを待機する上限時間を定義できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • クラスター管理者のパーミッション。
  • デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。

手順

  • KnativeServing カスタムリソース CR の scale-to-zero-grace-period 仕様を変更します。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          scale-to-zero-grace-period: "30s" 1

    1
    猶予期間(秒単位)。デフォルト値は 30 秒です。

6.1.4. システムのデプロイメント設定の上書き

KnativeServing および KnativeEventing カスタムリソース(CR)の deployments 仕様を変更して、一部の特定のデプロイメントのデフォルト設定を上書きできます。

6.1.4.1. Knative Serving システムデプロイメント設定の上書き

KnativeServing カスタムリソース(CR)の deployments 仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、デフォルトの設定設定のオーバーライドは、resourcereplicalabelsannotations、および nodeSelector フィールドでサポートされています。

以下の例では、KnativeServing CR は webhook デプロイメントをオーバーライドし、以下を確認します。

  • デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
  • デプロイメントには 3 つのレプリカがあります。
  • example-label:labellabel が追加されました。
  • example-annotation: annotation が追加されます。
  • nodeSelector フィールドは、disktype: hdd ラベルを持つノードを選択するように設定されます。
注記

KnativeServing CR ラベルおよびアノテーション設定は、デプロイメント自体と結果として生成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。

KnativeServing CR の例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: ks
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2
  deployments:
  - name: webhook
    resources:
    - container: webhook
      requests:
        cpu: 300m
        memory: 60Mi
      limits:
        cpu: 1000m
        memory: 1000Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

6.1.4.2. Knative Eventing システムのデプロイメント設定の上書き

KnativeEventing カスタムリソース(CR)の deployments 仕様を変更することで、一部の特定のデプロイメントのデフォルト設定を上書きできます。現時点で、デフォルト設定のオーバーライドは eventing-controllereventing-webhook、および imc-controller フィールドでサポートされます。

重要

replicas 仕様は Horizontal Pod Autoscaler(HPA)を使用するデプロイメントのレプリカ数を上書きすることはできず、eventing-webhook デプロイメントでは機能しません。

以下の例では、KnativeEventing CR は eventing-controller デプロイメントを上書きするため、以下が可能になります。

  • デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
  • デプロイメントには 3 つのレプリカがあります。
  • example-label:labellabel が追加されました。
  • example-annotation: annotation が追加されます。
  • nodeSelector フィールドは、disktype: hdd ラベルを持つノードを選択するように設定されます。

KnativeEventing CR の例

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  deployments:
  - name: eventing-controller
    resources:
    - container: eventing-controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

注記

KnativeEventing CR ラベルおよびアノテーション設定は、デプロイメント自体と作成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。

6.1.5. EmptyDir 拡張機能の設定

emptyDir ボリュームは、Pod の作成時に作成される空のボリュームであり、一時的な作業ディスク領域を提供するために使用されます。emptyDir ボリュームは、それらが作成された Pod が削除されると削除されます。

kubernetes.podspec-volumes-emptydir の拡張は、emptyDir ボリュームを Knative Serving で使用できるかどうかを制御します。emptyDir ボリュームの使用を有効にするには、KnativeServing カスタムリソース(CR)を変更して以下の YAML を追加する必要があります。

KnativeServing CR の例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    features:
      kubernetes.podspec-volumes-emptydir: enabled
...

6.1.6. HTTPS リダイレクトのグローバル設定

HTTPS リダイレクトは、着信 HTTP リクエストのリダイレクトを提供します。これらのリダイレクトされた HTTP リクエストは暗号化されます。KnativeServing カスタムリソース (CR) の httpProtocol 仕様を設定して、クラスターのすべてのサービスに対して HTTPS リダイレクトを有効にできます。

HTTPS リダイレクトを有効にする KnativeServing CR の例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    network:
      httpProtocol: "redirected"
...

6.1.7. 外部ルートの URL スキームの設定

セキュリティーを強化するために、外部ルートの URL スキームはデフォルトで HTTPS に設定されています。このスキームは、KnativeServingカスタムリソース (CR) 仕様のdefault-external-schemeキーによって決定されます。

デフォルト仕様

...
spec:
  config:
    network:
      default-external-scheme: "https"
...

default-external-schemeキーを変更することにより、HTTP を使用するようにデフォルトの仕様をオーバーライドできます。

HTTP オーバーライド仕様

...
spec:
  config:
    network:
      default-external-scheme: "http"
...

6.1.8. Kourier Gateway サービスタイプの設定

Kourier Gateway は、デフォルトで ClusterIP サービスタイプとして公開されます。このサービスタイプは、KnativeServing カスタムリソース (CR) の service-type 入力仕様によって決定されます。

デフォルト仕様

...
spec:
  ingress:
    kourier:
      service-type: ClusterIP
...

service-type 仕様を変更することで、デフォルトのサービスタイプをオーバーライドして、代わりにロードバランサーサービスタイプを使用できます。

LoadBalancer オーバーライド仕様

...
spec:
  ingress:
    kourier:
      service-type: LoadBalancer
...

6.1.9. PVC サポートの有効化

一部のサーバーレスアプリケーションには、永続的なデータストレージが必要です。これを実現するために、Knative サービスの永続ボリュームクレーム (PVC) を設定できます。

重要

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

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

手順

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

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

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

    • kubernetes.podspec-persistent-volume-claim 拡張機能は、永続ボリューム (PV) を Knative Serving で使用できるかどうかを制御します。
    • kubernetes.podspec-persistent-volume-write 拡張機能は、書き込みアクセスで Knative Serving が PV を利用できるかどうかを制御します。
  2. PV を要求するには、PV 設定を含めるようにサービスを変更します。たとえば、次の設定で永続的なボリュームクレームがある場合があります。

    注記

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

    PersistentVolumeClaim 設定

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

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

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

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

    1
    ボリュームマウント仕様。
    2
    永続的なボリュームクレームの仕様。
    3
    読み取り専用アクセスを有効にするフラグ。
    注記

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

6.1.10. init コンテナーの有効化

Init コンテナー は、Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナーです。これらは通常、アプリケーションの初期化ロジックを実装するために使用されます。これには、セットアップスクリプトの実行や、必要な設定のダウンロードが含まれる場合があります。KnativeServing カスタムリソース (CR) を変更することにより、Knative サービスの init コンテナーの使用を有効にできます。

重要

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

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

注記

Init コンテナーを使用すると、アプリケーションの起動時間が長くなる可能性があるため、頻繁にスケールアップおよびスケールダウンすることが予想されるサーバーレスアプリケーションには注意して使用する必要があります。

前提条件

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

手順

  • KnativeServing CR に kubernetes.podspec-init-containers フラグを追加して、init コンテナーの使用を有効にします。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        features:
          kubernetes.podspec-init-containers: enabled
    ...

6.1.11. タグからダイジェストへの解決

Knative Serving コントローラーがコンテナーレジストリーにアクセスできる場合、Knative Serving は、サービスのリビジョンを作成するときにイメージタグをダイジェストに解決します。これはタグからダイジェストへの解決と呼ばれ、デプロイメントの一貫性を提供するのに役立ちます。

コントローラーに OpenShift Container Platform のコンテナーレジストリーへのアクセスを許可するには、シークレットを作成してから、コントローラーのカスタム証明書を設定する必要があります。KnativeServing カスタムリソース (CR) の controller-custom-certs 仕様を変更することにより、コントローラーカスタム証明書を設定できます。シークレットは、KnativeServing CR と同じ namespace に存在する必要があります。

シークレットが KnativeServing CR に含まれていない場合、この設定はデフォルトで公開鍵インフラストラクチャー (PKI) を使用します。PKI を使用する場合、クラスター全体の証明書は、config-service-sa 設定マップを使用して KnativeServing コントローラーに自動的に挿入されます。OpenShift Serverless Operator は、config-service-sa 設定 マップにクラスター全体の証明書を設定し、設定マップをボリュームとしてコントローラーにマウントします。

6.1.11.1. シークレットを使用したタグからダイジェストへの解決の設定

controller-custom-certs 仕様で Secret タイプが使用されている場合、シークレットはシークレットボリュームとしてマウントされます。シークレットに必要な証明書があると仮定すると、ネイティブコンポーネントはシークレットを直接消費します。

前提条件

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

手順

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

    コマンドの例

    $ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>

  2. Secret タイプを使用するように、KnativeServing カスタムリソース (CR) で controller-custom-certs 仕様を設定します。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      controller-custom-certs:
        name: custom-secret
        type: Secret

6.1.12. 関連情報

6.2. Knative Kafka の設定

Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。Kafka は、イベントソース、チャネル、ブローカー、およびイベントシンク機能のオプションを提供します。

OpenShift Serverless のコアインストールの一部として提供される Knative Eventing コンポーネントの他に、クラスター管理者は KnativeKafka カスタムリソース(CR)をインストールできます。

注記

現時点で、Knative Kafka は IBM Z および IBM Power ではサポートされていません。

KnativeKafka CR は、ユーザーに以下のような追加オプションを提供します。

  • Kafka ソース
  • Kafka チャネル
  • Kafka ブローカー (テクノロジープレビュー)
  • Kafka シンク (テクノロジープレビュー)

6.2.1. Knative Kafka のインストール

Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。KnativeKafka カスタムリソースをインストールしている場合、Knative Kafka 機能は OpenShift Serverless インストールで使用できます。

前提条件

  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
  • Red Hat AMQ Streams クラスターにアクセスできる。
  • 検証手順を使用する場合は、OpenShift CLI (oc) をインストールします。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • 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 チャネル、ソース、ブローカー、またはシンクを使用するには、使用するオプションの 有効な スイッチを true に切り替える必要があります。これらのスイッチは、デフォルトで false に設定されます。さらに、Kafka チャネル、ブローカー、またはシンクを使用するには、ブートストラップサーバーを指定する必要があります。

    KnativeKafka カスタムリソースの例

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
        name: knative-kafka
        namespace: knative-eventing
    spec:
        channel:
            enabled: true 1
            bootstrapServers: <bootstrap_servers> 2
        source:
            enabled: true 3
        broker:
            enabled: true 4
            defaultConfig:
                bootstrapServers: <bootstrap_servers> 5
                numPartitions: <num_partitions> 6
                replicationFactor: <replication_factor> 7
        sink:
            enabled: true 8

    1
    開発者はクラスターで KafkaChannel チャネルを使用できます。
    2
    AMQ Streams クラスターからのブートストラップサーバーのカンマ区切りの一覧。
    3
    開発者はクラスターで KafkaSource イベントソースタイプを使用できます。
    4
    開発者はクラスターで Knative Kafka ブローカー実装を使用できます。
    5
    Red Hat AMQ Streams クラスターからのブートストラップサーバーのコンマ区切りリスト。
    6
    Broker オブジェクトでサポートされる Kafka トピックのパーティション数を定義します。デフォルトは10です。
    7
    Broker オブジェクトでサポートされる Kafka トピックのレプリケーション係数を定義します。デフォルトは 3 です。
    8
    開発者がクラスター内で Kafka シンクを使用できるようにします。
    注記

    replicationFactor の値は、Red Hat AMQ Streams クラスターのノード数以下である必要があります。

    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 ページ

    状態のステータスが Unknown または False である場合は、ページを更新するためにしばらく待機します。

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

    $ oc get pods -n knative-eventing

    出力例

    NAME                                        READY   STATUS    RESTARTS   AGE
    kafka-broker-dispatcher-7769fbbcbb-xgffn    2/2     Running   0          44s
    kafka-broker-receiver-5fb56f7656-fhq8d      2/2     Running   0          44s
    kafka-channel-dispatcher-84fd6cb7f9-k2tjv   2/2     Running   0          44s
    kafka-channel-receiver-9b7f795d5-c76xr      2/2     Running   0          44s
    kafka-controller-6f95659bf6-trd6r           2/2     Running   0          44s
    kafka-source-dispatcher-6bf98bdfff-8bcsn    2/2     Running   0          44s
    kafka-webhook-eventing-68dc95d54b-825xs     2/2     Running   0          44s

6.2.2. Knative Kafka のセキュリティー設定

通常、Kafka クラスターは TLS または SASL 認証を使用して保護されます。TLS または SASL を使用して、保護された Red Hat AMQ Streams クラスターに対して Kafka ブローカーまたはチャネルを設定できます。

注記

Red Hat は、SASL と TLS の両方を有効にすることを推奨します。

6.2.2.1. Kafka ブローカーの TLS 認証の設定

Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。TLS は、Knative Kafka のトラフィック暗号化でサポートされる唯一の方法です。

前提条件

  • OpenShift Container Platform でのクラスターまたは専用の管理者パーミッションがある。
  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka CRは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • .pem ファイルとして Kafka クラスター CA 証明書が保存されている。
  • Kafka クラスタークライアント証明書とキーが .pem ファイルとして保存されている。
  • OpenShift (oc) CLI をインストールしている。

手順

  1. 証明書ファイルを knative-eventing namespace にシークレットファイルとして作成します。

    $ oc create secret -n knative-eventing generic <secret_name> \
      --from-literal=protocol=SSL \
      --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 CR を編集し、broker 仕様にシークレットへの参照を追加します。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      broker:
        enabled: true
        defaultConfig:
          authSecretName: <secret_name>
    ...

6.2.2.2. Kafka ブローカーの SASL 認証の設定

Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。

前提条件

  • OpenShift Container Platform でのクラスターまたは専用の管理者パーミッションがある。
  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka CRは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Kafka クラスターのユーザー名およびパスワードがある。
  • 使用する SASL メカニズムを選択している (例: PLAINSCRAM-SHA-256、または SCRAM-SHA-512)。
  • TLS が有効にされている場合、Kafka クラスターの ca.crt 証明書ファイルも必要になります。
  • OpenShift CLI (oc) をインストールします。

手順

  1. 証明書ファイルを knative-eventing namespace にシークレットファイルとして作成します。

    $ oc create secret -n knative-eventing generic <secret_name> \
      --from-literal=protocol=SASL_SSL \
      --from-literal=sasl.mechanism=<sasl_mechanism> \
      --from-file=ca.crt=caroot.pem \
      --from-literal=password="SecretPassword" \
      --from-literal=user="my-sasl-user"
    • キー名に ca.crtpassword、および sasl.mechanism を使用します。これらの値は変更しないでください。
    • パブリック CA 証明書で SASL を使用する場合は、シークレットの作成時に ca.crt 引数ではなく tls.enabled=true フラグを使用する必要があります。以下は例になります。

      $ oc create secret -n <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"
  2. KnativeKafka CR を編集し、broker 仕様にシークレットへの参照を追加します。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      broker:
        enabled: true
        defaultConfig:
          authSecretName: <secret_name>
    ...

6.2.2.3. Kafka チャネルの TLS 認証の設定

Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。TLS は、Knative Kafka のトラフィック暗号化でサポートされる唯一の方法です。

前提条件

  • OpenShift Container Platform でのクラスターまたは専用の管理者パーミッションがある。
  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka CRは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • .pem ファイルとして Kafka クラスター CA 証明書が保存されている。
  • Kafka クラスタークライアント証明書とキーが .pem ファイルとして保存されている。
  • OpenShift (oc) CLI をインストールしている。

手順

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

    $ oc 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_servers>
        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.2.2.4. Kafka チャネルの SASL 認証の設定

Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。

前提条件

  • OpenShift Container Platform でのクラスターまたは専用の管理者パーミッションがある。
  • OpenShift Serverless Operator、Knative Eventing、および KnativeKafka CRは OpenShift Container Platform クラスターにインストールされます。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Kafka クラスターのユーザー名およびパスワードがある。
  • 使用する SASL メカニズムを選択している (例: PLAINSCRAM-SHA-256、または SCRAM-SHA-512)。
  • TLS が有効にされている場合、Kafka クラスターの ca.crt 証明書ファイルも必要になります。
  • OpenShift CLI (oc) をインストールします。

手順

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

    $ oc create secret -n <namespace> generic <kafka_auth_secret> \
      --from-file=ca.crt=caroot.pem \
      --from-literal=password="SecretPassword" \
      --from-literal=saslType="SCRAM-SHA-512" \
      --from-literal=user="my-sasl-user"
    • キー名に ca.crtpassword、および sasl.mechanism を使用します。これらの値は変更しないでください。
    • パブリック CA 証明書で SASL を使用する場合は、シークレットの作成時に ca.crt 引数ではなく tls.enabled=true フラグを使用する必要があります。以下は例になります。

      $ oc create secret -n <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"
  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_servers>
        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.2.3. 関連情報

6.3. 管理者の観点から見たサーバーレスコンポーネント

OpenShift Container Platform Web コンソールで Developer パースペクティブに切り替えたくない場合、または Knative (kn) CLI または YAML ファイルを使用したくない場合は、OpenShift Container PlatformWeb コンソールの Administator パースペクティブを使用して Knative コンポーネントを作成できます。

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

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

Knative Service オブジェクトの 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
サンプルアプリケーションで出力される環境変数

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

前提条件

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

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

手順

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

6.3.2. Administrator パースペクティブを使用したカスタムドメインのサービスへのマッピング

Knative サービスには、クラスターの設定に基づいてデフォルトのドメイン名が自動的に割り当てられます。例: &lt ;service_name>-<namespace>.example.com独自のカスタムドメイン名を Knative サービスにマッピングして、Knative サービスのドメインをカスタマイズできます。

そのためには、サービスの DomainMapping リソースを作成します。複数の DomainMapping を作成して、複数のドメインおよびサブドメインを単一サービスにマップすることもできます。

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

前提条件

  • Web コンソールにログインしている。
  • Administrator パースペクティブに切り替えられている。
  • OpenShift Serverless Operator がインストールされている。
  • Knative Serving がインストールされています。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Knative サービスを作成し、そのサービスにマップするカスタムドメインを制御できる。

    注記

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

手順

  1. CustomResourceDefinitions に移動し、検索ボックスを使用して DomainMapping カスタムリソース定義(CRD)を検索します。
  2. DomainMapping CRD をクリックしてから Instances タブに移動します。
  3. Create DomainMapping をクリックします。
  4. インスタンスの以下の情報が含まれるように DomainMapping CR の YAML を変更します。

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: <domain_name> 1
     namespace: <namespace> 2
    spec:
     ref:
       name: <target_name> 3
       kind: <target_type> 4
       apiVersion: serving.knative.dev/v1
    1
    ターゲット CR にマップするカスタムドメイン名。
    2
    DomainMapping CR とターゲット CR の両方の namespace。
    3
    カスタムドメインにマップするサービス名。
    4
    カスタムドメインにマップされる CR のタイプ。

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

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

検証

  • curl リクエストを使用してカスタムドメインにアクセスします。以下は例になります。

    コマンドの例

    $ curl custom-ksvc-domain.example.com

    出力例

    Hello OpenShift!

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

Knative イベントソース には、クラウドイベントの生成またはインポート、これらのイベントの別のエンドポイントへのリレー (sink とも呼ばれる) を行う Kubernetes オブジェクトを指定できます。イベントに対応する分散システムを開発するには、イベントのソースが重要になります。

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールにログインしており、Administrator パースペクティブを使用している。
  • OpenShift Container Platform のクラスター管理者パーミッションがある。

手順

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

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

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。

ブローカーイベント配信の概要

前提条件

  • OpenShift Serverless Operator および Knative Eventing が OpenShift Container Platform クラスターにインストールされている。
  • Web コンソールに