Menu Close

Serverless

OpenShift Container Platform 4.8

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

kn func

TP

TP

TP

TP

kn func invoke

-

-

-

TP

サービスメッシュ mTLS

GA

GA

GA

GA

emptyDir ボリューム

GA

GA

GA

GA

HTTPS リダイレクト

-

GA

GA

GA

Kafka ブローカー

-

-

TP

TP

Kafka シンクコ

-

-

-

TP

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

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

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

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

機能1.181.191.201.21

KafkaBinding API

GA

非推奨

非推奨

非推奨

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

TP

TP

非推奨

廃止

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

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

1.4.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.4.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.4.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.5. Red Hat OpenShift Serverless 1.20.0 のリリースノート

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

1.5.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 プラグインがテクノロジープレビュー機能として利用可能になりました。

1.5.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.6. Red Hat OpenShift Serverless 1.19.0 のリリースノート

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

1.6.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.6.2. 修正された問題

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

1.6.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.7. Red Hat OpenShift Serverless 1.18.0 のリリースノート

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

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

2.2. OpenShift Serverless Functions について

OpenShift Serverless Functions により、開発者は OpenShift Container Platform で Knative サービスとしてステートレスでイベント駆動型の関数を作成およびデプロイできます。kn func CLI は Knative kn CLI のプラグインとして提供されます。OpenShift Serverless Functions は、 CNCF Buildpack API を使用してコンテナーイメージを作成します。コンテナーイメージの作成後に、kn func を使用してコンテナーイメージをクラスターで 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 コンソール、kn CLI を使用するか、または YAML ファイルを適用して Developer パースペクティブで Knative イベントソースを作成したり、管理したりできます。

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

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

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

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

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

Channel workflow overview

サポートされている 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 のログで確認できます。

3.1.3. 関連情報

3.1.4. 次のステップ

3.2. Knative Serving のインストール

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

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

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

    Conditions
    注記

    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. 高度な設定オプション

デフォルトの設定で Knative Serving をインストールするか、KnativeServing カスタムリソース (CR) でより詳細な設定を行うことが可能です。これらの詳細設定を行うことで、Knative Serving のデプロイメントにおける証明書の使用や、利用可能な高可用性レプリカの数などの機能を変更することができます。

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

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

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

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

サンプル YAML

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

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

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

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

重要

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

3.2.3.2. 高可用性

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

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

サンプル YAML

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

3.2.4. 次のステップ

3.3. Knative Eventing のインストール

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

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

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

    Conditions
    注記

    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 ページからスクロールするか、または Filter by name にキーワードを入力して必要な Operator を見つけます。次に、それをクリックします。
  2. Operator Details ページの右側で、Actions ドロップダウンメニューから Uninstall Operator を選択します。

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

    Operator を削除しても、そのカスタムリソース定義や管理リソースは削除されません。Operator がクラスターにアプリケーションをデプロイしているか、またはクラスター外のリソースを設定している場合、それらは引き続き実行され、手動でクリーンアップする必要があります。

    このアクションにより、Operator および Operator のデプロイメントおよび Pod が削除されます(ある場合)。CRD および CR を含む Operator によって管理される Operand およびリソースは削除されません。Web コンソールは、一部の Operator のダッシュボードおよびナビゲーションアイテムを有効にします。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。

  3. Uninstall を選択します。この Operator は実行を停止し、更新を受信しなくなります。

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 Container Platform アカウントを使用できる。
  • Knative Serving をアンインストールし、OpenShift Serverless Operator を削除している。
  • OpenShift CLI (oc) をインストールします。

手順

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

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

第4章 開発

4.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 サービスの作成Developer パースペクティブを使用したアプリケーションの作成 についてのドキュメントを参照してください。
  • kn CLI を使用して Knative サービスを作成します。
  • oc CLI を使用して、Knative Service オブジェクトを YAML ファイルとして作成し、適用します。

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

サーバーレスアプリケーションを作成するために kn CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn service create コマンドを使えば、kn CLI を使用して基本的なサーバーレスアプリケーションを作成することができます。

前提条件

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

手順

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

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

    コマンドの例

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

    出力例

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

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

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

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

4.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) を両方のホストに追加します。

4.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。

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

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

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

4.1.8. 関連情報

4.2. 自動スケーリング

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

Knative サービスの自動スケーリング設定は、クラスター管理者によって設定されるグローバル設定とすることも、個別サービスに設定されるリビジョンごとの設定とすることもできます。OpenShift Container Platform Web コンソールを使用して、サービスの YAML ファイルを変更するか、または kn CLI を使用して、サービスのリビジョンごとの設定を変更できます。

注記

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

4.2.1. スケーリング限度

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

4.2.1.1. スケーリング下限

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

以下の条件が満たされている場合、minScale 値のデフォルトは 0 レプリカに設定されます。

  • minScale アノテーションが設定されていない
  • ゼロへのスケーリングが有効にされている
  • KPA クラスが使用されている

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

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

4.2.1.1.1. Knative CLI を使用した minScale アノテーションの設定

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

前提条件

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

手順

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

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

    コマンドの例

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

4.2.1.2. スケーリング上限

アプリケーションに対応できる最大のレプリカ数は、minScale アノテーションによって決定されます。maxScale アノテーションが設定されていない場合、作成されるレプリカ数の上限はありません。

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

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

4.2.1.2.1. Knative CLI を使用した maxScale アノテーションの設定

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

前提条件

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

手順

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

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

    コマンドの例

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

4.2.2. 並行処理性

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

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

    重要

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

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

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

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

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

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

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

たとえば、containerConcurrency アノテーションの値が 10 に設定され、targetUtilizationPercentage の値が 70 パーセントに設定されていると、すべての既存レプリカの並行処理リクエストの平均数が 7 に達すると、Autoscaler は新しいレプリカを作成します。7 番目から 10 番目のリクエストは引き続き既存のレプリカに送付されますが、containerConcurrency アノテーションのリミットに達すると追加のレプリカが必要になることを予想して、追加のレプリカを起動します。

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

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

4.2.3. 関連情報

4.3. トラフィック管理

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

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

Knative service architecture

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

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

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

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

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

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

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

以下の例は、トラフィックの 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

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

以下の例は、トラフィックの 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

4.3.2. 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 の一覧を表示します。

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

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

      odc serverless revisions

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

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

コマンドの例

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

ここで、

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

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

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

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

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

    重要

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

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

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

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

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

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

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

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

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

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

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

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

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

フラグ操作繰り返し

--traffic

RevisionName=Percent

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

はい

--traffic

Tag=Percent

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

はい

--traffic

@latest=Percent

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

いいえ

--tag

RevisionName=Tag

TagRevisionName に指定します。

はい

--tag

@latest=Tag

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

いいえ

--untag

Tag

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

はい

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

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

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

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

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

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

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

注記

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

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

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

4.3.4. 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 ファイルを適用 (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 にアクセスして、アプリケーションの古いバージョンに送信されていないことを確認します。

4.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 ルートと共に使用し、トラフィック分割などの詳細なルーティング機能を提供します。

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

    • 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
    ラベルおよびアノテーション名および値の値を使用します。

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

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

4.4.4. 関連情報

4.5. イベントシンク

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

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

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

4.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 のカスタマイズ により、どの CR が kn CLI コマンドの --sink フラグと併用できるかを設定できます。

4.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 Sources に移動して任意のタイプのイベントソースを作成し、作成するイベントソースを選択します。
  2. Event Sources フォームビューの Sink セクションで、Resource を選択します。次に、ドロップダウンを使用してシンクを選択します。
  3. Create をクリックします。

検証

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

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

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

4.6. イベント配信

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

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

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

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

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

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

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

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

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

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

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

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

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

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.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. 利用可能なイベントソースタイプを表示します。

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

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

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

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

4.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 view
注記

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

API サーバーソースの削除

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

    Delete the ApiServerSource

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

4.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 が含まれます。

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

4.9. ping ソースの作成

ping ソースは、一定のペイロードを使用して ping イベントをイベントコンシューマーに定期的に送信するために使用されるイベントソースです。ping ソースを使用すると、タイマーと同様にイベントの送信をスケジュールできます。

4.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 ソースおよびシンクを表示します。

    View the ping source and service in the Topology view

ping ソースの削除

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

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

kn source ping create コマンドを使用し、kn CLI を使用して ping ソースを作成できます。イベントソースを作成するために kn 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.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 が含まれます。

4.9.3. YAML を使用した ping ソースの作成

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

PingSource オブジェクトの例

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

1
CRON 式を使用して指定されるイベントのスケジュール。
2
JSON でエンコードされたデータ文字列として表現されるイベントメッセージの本体。
3
これらはイベントコンシューマーの詳細です。この例では、event-display という名前の Knative サービスを使用しています。

前提条件

  • 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/v1alpha2
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        jsonData: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
    2. ping ソースを作成します。

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

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

    出力例

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

検証

シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。

デフォルトで、Knative サービスは、トラフィックが 60 秒以内に受信されない場合に Pod を終了します。本書の例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する PingSource を作成します。

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

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

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

    出力例

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

ping ソースの削除

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

    $ oc delete -f <filename>

    コマンドの例

    $ oc delete -f ping-source.yaml

4.10. カスタムイベントソース

Knative に含まれていないイベントプロデューサーや、CloudEvent 形式ではないイベントを生成するプロデューサーからイベントを Ingress する必要がある場合は、カスタムイベントソースを使用してこれを実行できます。カスタムイベントソースは、次のいずれかの方法で作成できます。

  • シンクバインディングを作成して、PodSpecable オブジェクトをイベントソースとして使用します。
  • コンテナーソースを作成して、コンテナーをイベントソースとして使用します。

4.10.1. シンクバインディング

SinkBinding オブジェクトは、イベント生成を配信アドレス指定から切り離すことをサポートします。シンクバインディングは、イベントプロデューサー をイベントコンシューマーまたは シンク に接続するために使用されます。イベントプロデューサーは、PodSpec テンプレートを組み込む Kubernetes リソースであり、イベントを生成します。シンクは、イベントを受信できるアドレス指定可能な Kubernetes オブジェクトです。

SinkBinding オブジェクトは、環境変数をシンクの PodTemplateSpec に挿入します。つまり、アプリケーションコードが Kubernetes API と直接対話してイベントの宛先を見つける必要はありません。これらの環境変数は以下のとおりです。

K_SINK
解決されたシンクの URL。
K_CE_OVERRIDES
アウトバウンドイベントの上書きを指定する JSON オブジェクト。

4.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": ""
      }

4.10.1.2. Knative CLI を使用したシンクバインディングの作成

kn source binding create コマンドを使用し、kn を使用してシンクバインディングを作成できます。イベントソースを作成するために kn 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": ""
      }

4.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 が含まれます。

4.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 ジョブを表示します。

    View the sink binding and service in the Topology view
  3. シンクバインディングが追加されると、正常なジョブが cron ジョブによって登録されていることを確認します。つまり、シンクバインディングは cron ジョブで作成されたジョブが正常に再設定されることを意味します。
  4. event-display サービス Pod のログを参照し、ハートビート cron ジョブで生成されるイベントを表示します。

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

上書きを定義して、シンクに送信されたイベントへの出力形式および変更を制御します。

任意

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

4.10.1.4.3. include ラベル

シンクバインディングを使用するには、bindings.knative.dev/include: "true" ラベルをリソースまたはリソースが含まれる namespace のいずれかに割り当てる必要があります。リソース定義にラベルが含まれていない場合には、クラスター管理者は以下を実行してこれを namespace に割り当てることができます。

$ oc label namespace <namespace> bindings.knative.dev/include=true

4.10.2. コンテナーソース

コンテナーソースは、イベントを生成し、イベントをシンクに送信するコンテナーイメージを作成します。コンテナーソースを使用して、イメージ URI を使用するコンテナーイメージおよび ContainerSource オブジェクトを作成して、カスタムイベントソースを作成できます。

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

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

kn source container コマンドを使用し、kn CLI を使用してコンテナーソースを作成および管理できます。イベントソースを作成するために kn 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.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 をクリックします。

4.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"
  ...

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

4.11. チャネルの作成

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

Channel workflow overview

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

4.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. Type ドロップダウンから作成する Channel オブジェクトのタイプを選択します。
  3. Create をクリックします。

検証

  • Topology ページに移動して、チャネルが存在することを確認します。

    View the channel in the Topology view

4.11.2. Knative CLI を使用したチャネルの作成

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

前提条件

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

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

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

4.11.5. 次のステップ

4.12. サブスクリプションの作成および管理

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。サブスクリプションは、イベントを配信するチャネルとシンク (サブスクライバーとも呼ばれます) を指定する Subscription オブジェクトを設定することによって作成されます。障害の処理方法など、シンク固有のオプションを指定することもできます。

4.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 オプションが表示されます。

      Create a subscription for the channel
      1. ドロップダウンリストから、シンクをサブスクライバーとして選択します。
      2. Add をクリックします。
    2. このサービスが、チャネルと同じ namespace またはプロジェクトにある Topology ビューで利用可能な場合は、サブスクリプションを作成するチャネルをクリックし、矢印をサービスに直接ドラッグして、チャネルからそのサービスにサブスクリプションを即時に作成します。

検証

  • サブスクリプションの作成後に、これを Topology ビューでチャネルをサービスに接続する行として表示できます。

    Subscription in the Topology view

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

4.12.3. Knative CLI を使用したサブスクリプションの作成

チャネルとイベントシンクを作成したら、サブスクリプションを作成してイベント配信を有効にすることができます。サブスクリプションを作成するために kn CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn subscription create コマンドや適切なフラグを使用し、kn CLI を使用してサブスクリプションを作成できます。

前提条件

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

4.12.4. Knative CLI を使用したサブスクリプションの記述

kn subscription describe コマンドを使用し、kn CLI を使用して、端末のサブスクリプションに関する情報を出力できます。サブスクリプションを記述するために kn 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

4.12.5. Knative CLI を使用したサブスクリプションの一覧表示

kn subscription list コマンドを使用し、kn CLI を使用してクラスター内の既存サブスクリプションを一覧表示できます。kn CLI を使用してサブスクリプションを一覧表示すると、合理的で直感的なユーザーインターフェースが提供されます。

前提条件

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

手順

  • クラスターのサブスクリプションを一覧表示します。

    $ kn subscription list

    出力例

    NAME             CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
    mysubscription   Channel:mychannel   ksvc:event-display                              True

4.12.6. Knative CLI を使用したサブスクリプションの更新

kn subscription update コマンドや適切なフラグを使用し、kn CLI を使用してサブスクリプションを端末から更新できます。サブスクリプションを更新するために kn 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

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

4.13. ブローカー

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。

Broker event delivery overview

4.13.1. ブローカータイプ

OpenShift Serverless で使用できるブローカー実装は複数あり、それぞれのブローカー実装が異なるイベント配信保証を持ち、異なる基礎となるテクノロジーを使用します。ブローカークラスを指定して、ブローカーの作成時にブローカー実装を選択できます。指定しない場合は、デフォルトのブローカークラスが使用されます。デフォルトのブローカークラスは、クラスター管理者によって設定できます。

4.13.1.1. チャネルベースのブローカー

チャネルベースのブローカー実装は、内部的にイベント配信にチャネルを使用します。チャネルベースのブローカーは、ブローカーインスタンスが使用するチャネルの実装に基づいて、異なるイベント配信保証を提供します。以下に例を示します。

  • InMemoryChannel 実装を使用するブローカーは、開発およびテストの目的で役立ちますが、実稼働環境に対しては適切なイベント配信保証を提供しません。
  • KafkaChannel 実装を使用するブローカーは、実稼働環境に必要なイベント配信保証を提供します。

4.13.1.2. Kafka ブローカー

重要

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

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

Kafka ブローカーは、Kafka を内部的に使用して、少なくとも 1 回の配信保証を提供するブローカー実装です。複数の Kafka バージョンをサポートし、イベントの保存およびルーティングのために Kafka とネイティブに統合されています。

4.13.2. デフォルト設定を使用するブローカーの作成

OpenShift Serverless は、kn CLI を使用して作成できる default Knative ブローカーを提供します。また、eventing.knative.dev/injection: enabled アノテーションに追加するか、または eventing.knative.dev/injection=enabled ラベルを namespace に追加して、 default ブローカーを作成することもできます。

4.13.2.1. Knative CLI を使用したブローカーの作成

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。ブローカーを作成するために kn CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェースが得られます。kn broker create コマンドを使用し、kn CLI を使用してブローカーを作成できます。

前提条件

  • 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 ビューに移動し、ブローカーが存在することを確認できます。

    View the broker in the web console Topology view

4.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 ビューに移動し、ブローカーが存在することを確認できます。

    View the broker in the web console Topology view

4.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 ビューに移動し、ブローカーが存在することを確認できます。

    View the broker in the web console Topology view

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

4.13.3. ブローカーの管理

kn CLI は、ブローカーの一覧表示、説明、更新、および削除に使用できるコマンドを提供します。

4.13.3.1. Knative CLI を使用した既存ブローカーの一覧表示

kn CLI を使用してブローカーを一覧表示すると、合理的で直感的なユーザーインターフェースが提供されます。kn broker list コマンドを使用し、kn 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

4.13.3.2. Knative CLI を使用した既存ブローカーの記述

kn CLI を使用してブローカーを記述すると、合理的で直感的なユーザーインターフェースが提供されます。kn broker describe コマンドを使用し、kn 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

4.13.4. 関連情報

4.14. トリガー

ブローカーはトリガーと組み合わせて、イベントをイベントソースからイベントシンクに配信できます。イベントは、HTTP POST リクエストとしてイベントソースからブローカーに送信されます。イベントがブローカーに送信された後に、それらはトリガーを使用して CloudEvent 属性でフィルターされ、HTTP POST リクエストとしてイベントシンクに送信できます。

Broker event delivery overview

4.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 を選択します。

4.14.2. Knative CLI を使用したトリガーの作成

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

前提条件

  • 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 属性を使用すると、ブローカーからイベントをフィルターできるため、サブスクライバーは定義された基準に基づくイベントのサブセットのみを受け取ることができます。

4.14.3. Knative CLI の使用によるトリガーの一覧表示

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

4.14.4. Knative CLI を使用したトリガーの記述

kn CLI を使用してトリガーを記述すると、合理的で直感的なユーザーインターフェースが提供されます。kn trigger describe コマンドを使用し、kn 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

4.14.5. Knative CLI を使用したトリガーでのイベントのフィルター

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

4.14.6. Knative CLI を使用したトリガーの更新

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

4.14.7. Knative CLI を使用したトリガーの削除

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.

4.15. Knative Kafka

Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。Kafka は、イベントソース、チャネル、ブローカー、およびイベントシンク機能のオプションを提供します。

Knative Kafka 機能は、クラスター管理者が KnativeKafka カスタムリソースをインストールしている場合に、OpenShift Serverless インストールで利用できます。

注記

現時点で、Knative Kafka は IBM Z および IBM Power Systems ではサポートされていません。

Knative Kafka は、以下のような追加オプションを提供します。

  • Kafka ソース
  • Kafka チャネル
  • Kafka ブローカー (テクノロジープレビュー)
  • Kafka シンク (テクノロジープレビュー)

4.15.1. Kafka イベント配信およびリトライ

イベント駆動型のアーキテクチャーで Kafka コンポーネントを使用すると、「最低でも 1 度」のイベント配信が提供されます。これは、戻りコード値を受け取るまで操作がリトライされることを意味します。これにより、失われたイベントに対してアプリケーションの回復性が強化されます。ただし、重複するイベントが送信されてしまう可能性があります。

Kafka イベントソースでは、デフォルトでイベント配信のリトライ回数が固定されています。Kafka チャネルの場合、Kafka チャネルの Delivery 仕様に設定されている場合にのみリトライが実行されます。

配信保証に関する詳細は、イベント配信 のドキュメントを参照してください。

4.15.2. Kafka ソース

Apache Kafka クラスターからイベントを読み取り、これらのイベントをシンクに渡す Kafka ソースを作成できます。Kafka ソースを作成するには、OpenShift Container Platform Web コンソールの Knative (kn)CLI を使用するか、KafkaSource オブジェクトを YAML ファイルとして直接作成し、OpenShift (oc) CLI を使用して適用します。

4.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 イベントソースおよびシンクを表示します。

    View the Kafka source and service in the Topology view

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

kn source kafka create コマンドを使用し、kn CLI を使用して Kafka ソースを作成できます。イベントソースを作成するために kn 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.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 が含まれます。

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

4.15.3. 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/ を参照してください。

重要

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

4.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 CLI (oc) をインストールします。

手順

  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>

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

4.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/ を参照してください。

4.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 シンクの名前。

4.15.6. 関連情報

第5章 管理

5.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 で使用される値を持ちます。

5.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 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。

5.1.2. システムのデプロイメント設定の上書き

KnativeServing カスタムリソース(CR)の deployments 仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、replicaslabelsannotations、および nodeSelector フィールドのデフォルト設定を上書きすることがサポートされています。

以下の例では、KnativeServing CR は webhook デプロイメントをオーバーライドし、以下を確認します。

  • デプロイメントには 3 つのレプリカがあります。
  • ラベルは example-label: label に設定されます。
  • ラベル example-label: label が追加されます。
  • 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
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

5.1.3. EmptyDir 拡張機能の設定

emptyDir ボリュームは、Pod の作成時に作成される空のボリュームであり、一時的な作業ディスク領域を提供するために使用されます。emptyDir ボリュームは、それらが作成された Pod が削除されると削除されます。

"kubernetes.podspec-volumes-emptydir" 拡張機能は、emptyDir ボリュームを Knative Serving で使用できるかどうかを制御します。emptyDir ボリュームの使用を有効にするには、KnativeServing カスタムリソース(CR)を変更して以下の YAML を追加する必要があります。

...
spec:
  config:
    features:
      "kubernetes.podspec-volumes-emptydir": enabled
...

5.1.4. 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"
...

5.1.5. 外部ルートの 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"
...

5.1.6. Kourier Gateway サービスタイプの設定

Kourier Gateway は、デフォルトで ClusterIP サービスタイプとして公開されます。このサービスタイプは、KnativeServing カスタムリソース (CR) の service-type 入力仕様によって決定されます。

デフォルト仕様

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

service-type 仕様を変更することで、デフォルトのサービスタイプをオーバーライドして、代わりにロードバランサーサービスタイプを使用できます。

LoadBalancer オーバーライド仕様

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

5.1.7. 関連情報

5.2. Knative Kafka

Knative Kafka は、OpenShift Serverless でサポートされているバージョンの Apache Kafka メッセージストリーミングプラットフォームを使用する統合オプションを提供します。Kafka は、イベントソース、チャネル、ブローカー、およびイベントシンク機能のオプションを提供します。

OpenShift Serverless のコアインストールの一部として提供される Knative Eventing コンポーネントの他に、クラスター管理者は KnativeKafka カスタムリソース(CR)をインストールできます。

注記

現時点で、Knative Kafka は IBM Z および IBM Power Systems ではサポートされていません。

KnativeKafka CR は、ユーザーに以下のような追加オプションを提供します。

  • Kafka ソース
  • Kafka チャネル
  • Kafka ブローカー (テクノロジープレビュー)
  • Kafka シンク (テクノロジープレビュー)

5.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 page showing Conditions

    状態のステータスが Unknown または False である場合は、ページを更新するためにしばらく待機します。

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

    $ oc get pods -n knative-eventing

    出力例

    NAME                                            READY   STATUS    RESTARTS   AGE
    kafka-ch-controller-85f879d577-xcbjh            1/1     Running   0          44s
    kafka-ch-dispatcher-55d76d7db8-ggqjl            1/1     Running   0          44s
    kafka-controller-manager-bc994c465-pt7qd        1/1     Running   0          40s
    kafka-webhook-54646f474f-wr7bb                  1/1     Running   0          42s

5.2.2. Kafka ブローカーの TLS 認証の設定

Transport Layer Security (TLS) は、Apache Kafka クライアントおよびサーバーによって、Knative と Kafka 間のトラフィックを暗号化するため、および認証のために使用されます。KnativeKafka カスタムリソース (CR) を変更することにより、Kafka ブローカーの TLS を設定できます。

前提条件

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

5.2.3. Kafka ブローカーの SASL 認証の設定

Simple Authentication and Security Layer (SASL) は、Apache Kafka が認証に使用します。クラスターで SASL 認証を使用する場合、ユーザーは Kafka クラスターと通信するために Knative に認証情報を提供する必要があります。そうしないと、イベントを生成または消費できません。KnativeKafka カスタムリソース (CR) を変更することにより、Kafka ブローカーの SASL を設定できます。

前提条件

  • 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) をインストールします。
注記

SASL に加えて TLS を有効にすることが推奨されます。

手順

  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 を使用します。これらの値は変更しないでください。

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

5.2.4. 関連情報

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

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

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

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

前提条件

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

手順

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

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

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

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

前提条件

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

手順

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

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

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

前提条件

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

手順

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

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

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

前提条件

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

手順

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

    注記

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

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

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

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

前提条件

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

手順

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

5.3.6. 関連情報

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

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

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

前提条件

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

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

手順

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

5.5. 自動スケーリング

クラスター管理者は、KnativeServing カスタムリソース(CR)を変更することで、自動スケーリング機能のグローバルおよび namespace ごとにデフォルト設定を設定できます。これにより、変更が該当する設定マップに反映されます。

5.5.1. scale-to-zero の有効化

クラスター管理者は、クラスターでscale-to-zeroをグローバルに有効にしたり無効にしたりできます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • クラスター管理者のパーミッション。
  • デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。

手順

  • KnativeServing CR の enable-scale-to-zero 仕様を変更します。

    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"です。

5.5.2. scale-to-zero 猶予期間の設定

この設定は、Knative が scale-from-zero マシナリーの配置を待機する時間の上限を指定します。この時間を過ぎると、アプリケーションの最後のレプリカが削除されます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • クラスター管理者のパーミッション。
  • デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。

手順

  • KnativeServing CR の scale-to-zero-grace-period 仕様を変更します。

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          scale-to-zero-grace-period: "30s" 1
    1
    猶予期間(秒単位)。デフォルト値は 30 秒です。

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

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

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

重要

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

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

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

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

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

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

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

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

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

前提条件

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

手順

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

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

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

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

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

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

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

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

前提条件

  • Red Hat OpenShift Service Mesh がインストールされています。OpenShift Serverless with Service Mesh は、Red Hat OpenShift Service Mesh バージョン2.0.5 以降での使用でのみサポートされます。
  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift Serverless Operator がインストールされている。

    重要

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

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

手順

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    $ oc apply -f <filename>

検証

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

    $ curl --cacert root.crt <service_url>

    コマンドの例

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

    出力例

    Hello Openshift!

5.6.1.3. mTLS でService Meshを使用する場合の Knative Serving メトリクスの有効化

サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。このセクションでは、Service Mesh および mTLS を使用する際に Knative Serving メトリクスを有効にする方法を説明します。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • mTLS 機能を有効にして Red Hat OpenShift Service Mesh をインストールしています。
  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) をインストールします。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

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

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

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

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

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

    ...
    spec:
      proxy:
        networking:
          trafficControl:
            inbound:
              excludedPorts:
              - 8444
    ...

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

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift CLI (oc) をインストールします。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Red Hat OpenShift Service Mesh がインストールされています。OpenShift Serverless with Service Mesh and Kourier は、Red Hat OpenShift Service Mesh バージョン 1.x および 2.x の両方での使用がサポートされています。

手順

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

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

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

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

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

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

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

      $ oc apply -f <filename>

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

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

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

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

前提条件

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

手順

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

    Knative Health Status dashboard

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

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

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

前提条件

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

手順

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

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

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

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

前提条件

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

手順

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

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

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

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

前提条件

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

手順

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

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

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

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

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

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

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

前提条件

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

手順

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

    1. ブローカーの場合:

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

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

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

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

前提条件

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

手順

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

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

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

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

5.8. メトリクス

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

5.8.1. 前提条件

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

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

この問題の解決に関する詳細は、サービスメッシュと OpenShift Serverless の統合を参照してください。

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

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

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

work_queue_depth

ワークキューの深さ。

ゲージ

reconciler

整数 (単位なし)

reconcile_count

調整操作の数。

カウンター

reconcilersuccess

整数 (単位なし)

reconcile_latency

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

ヒストグラム

reconcilersuccess

ミリ秒

workqueue_adds_total

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

カウンター

name

整数 (単位なし)

workqueue_queue_latency_seconds

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

ヒストグラム

name

workqueue_retries_total

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

カウンター

name

整数 (単位なし)

workqueue_work_duration_seconds

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

ヒストグラム

name

workqueue_unfinished_work_seconds

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

ヒストグラム

name

workqueue_longest_running_processor_seconds

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

ヒストグラム

name

5.8.3. Webhook メトリクス

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

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

request_count

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

カウンター

admission_allowedkind_groupkind_kindkind_versionrequest_operationresource_groupresource_namespaceresource_resourceresource_version

整数 (単位なし)

request_latencies

Webhook 要求の応答時間。

ヒストグラム

admission_allowedkind_groupkind_kindkind_versionrequest_operationresource_groupresource_namespaceresource_resourceresource_version

ミリ秒

5.8.4. Knative Eventing メトリクス

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

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

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

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

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

event_count

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

カウンター

broker_nameevent_typenamespace_nameresponse_coderesponse_code_classunique_name

整数 (単位なし)

event_dispatch_latencies

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

ヒストグラム

broker_nameevent_typenamespace_nameresponse_coderesponse_code_classunique_name

ミリ秒

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

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

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

event_count

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

カウンター

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

整数 (単位なし)

event_dispatch_latencies

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

ヒストグラム

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

ミリ秒

event_processing_latencies

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

ヒストグラム

broker_namecontainer_namefilter_typenamespace_nametrigger_nameunique_name

ミリ秒

5.8.4.3. InMemoryChannel dispatcher メトリクス

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

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

event_count

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

カウンター

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

整数 (単位なし)

event_dispatch_latencies

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

ヒストグラム

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

ミリ秒

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

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

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

event_count

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

カウンター

broker_namecontainer_namefilter_typenamespace_nameresponse_coderesponse_code_classtrigger_nameunique_name

整数 (単位なし)

retry_event_count

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

カウンター

event_sourceevent_typenamenamespace_nameresource_groupresponse_coderesponse_code_classresponse_errorresponse_timeout

整数 (単位なし)

5.8.5. Knative Serving メトリクス

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

5.8.5.1. activator メトリクス

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

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

request_concurrency

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

ゲージ

configuration_namecontainer_namenamespace_namepod_namerevision_nameservice_name

整数 (単位なし)

request_count

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

カウンター

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

整数 (単位なし)

request_latencies

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

ヒストグラム

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

ミリ秒

5.8.5.2. Autoscaler メトリクス

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

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

desired_pods

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

excess_burst_capacity

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

stable_request_concurrency

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

panic_request_concurrency

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

target_concurrency_per_pod

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

stable_requests_per_second

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

panic_requests_per_second

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

target_requests_per_second

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

panic_mode

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

requested_pods

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

actual_pods

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

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

not_ready_pods

準備未完了状態の Pod 数。

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

pending_pods

現在保留中の Pod 数。

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

terminating_pods

現在終了中の Pod 数。

ゲージ

configuration_namenamespace_namerevision_nameservice_name

整数 (単位なし)

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

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

注記

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

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

go_alloc

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

ゲージ

name

整数 (単位なし)

go_total_alloc

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

ゲージ

name

整数 (単位なし)

go_sys

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

ゲージ

name

整数 (単位なし)

go_lookups

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

ゲージ

name

整数 (単位なし)

go_mallocs

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

ゲージ

name

整数 (単位なし)

go_frees

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

ゲージ

name

整数 (単位なし)

go_heap_alloc

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

ゲージ

name

整数 (単位なし)

go_heap_sys

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

ゲージ

name

整数 (単位なし)

go_heap_idle

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

ゲージ

name

整数 (単位なし)

go_heap_in_use

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

ゲージ

name

整数 (単位なし)

go_heap_released

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

ゲージ

name

整数 (単位なし)

go_heap_objects

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

ゲージ

name

整数 (単位なし)

go_stack_in_use

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

ゲージ

name

整数 (単位なし)

go_stack_sys

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

ゲージ

name

整数 (単位なし)

go_mspan_in_use

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

ゲージ

name

整数 (単位なし)

go_mspan_sys

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

ゲージ

name

整数 (単位なし)

go_mcache_in_use

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

ゲージ

name

整数 (単位なし)

go_mcache_sys

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

ゲージ

name

整数 (単位なし)

go_bucket_hash_sys

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

ゲージ

name

整数 (単位なし)

go_gc_sys

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

ゲージ

name

整数 (単位なし)

go_other_sys

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

ゲージ

name

整数 (単位なし)

go_next_gc

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

ゲージ

name

整数 (単位なし)

go_last_gc

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

ゲージ

name

ナノ秒

go_total_gc_pause_ns

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

ゲージ

name

ナノ秒

go_num_gc

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

ゲージ

name

整数 (単位なし)

go_num_forced_gc

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

ゲージ

name

整数 (単位なし)

go_gc_cpu_fraction

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

ゲージ

name

整数 (単位なし)

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

重要

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

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

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

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

注記

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

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

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

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

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

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

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

YAML ファイル

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

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

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

YAML ファイル

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

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

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

$ oc apply -f <datasource_name>.yaml

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

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

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

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

YAML ファイル

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

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

YAML ファイル

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

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

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

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

    コマンドの例

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

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

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

YAML ファイル

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

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

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

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

    $ oc apply -f <report-name>.yml
  2. 以下のコマンドを入力してレポートを確認できます。

    $ oc get report

    出力例

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

5.10. OpenShift Serverless での高可用性

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

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

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

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

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

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

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

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

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

5.10.1.1. Knative Serving の高可用性レプリカの設定

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

前提条件

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

手順

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

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

    サンプル YAML

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

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

5.10.1.2. Knative Eventing の高可用性レプリカの設定

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

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHubInstalled Operators に移動します。
  2. knative-eventing namespace を選択します。
  3. OpenShift Serverless Operator の Provided API 一覧で Knative Eventing をクリックし、Knative Eventing タブに移動します。
  4. knative-serving をクリックしてから、knative-eventing ページの YAML タブに移動します。

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

    サンプル YAML

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

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

5.10.1.3. Knative Kafka の高可用性レプリカの設定

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

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、OperatorHubInstalled Operators に移動します。
  2. knative-eventing namespace を選択します。
  3. OpenShift Serverless Operator の Provided APIs の一覧で Knative Kafka をクリックし、 Knative Kafka タブに移動します。
  4. knative-kafka をクリックしてから、knative-kafka ページの YAML タブに移動します。

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

    サンプル YAML

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

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

第6章 Monitor

6.1. OpenShift Serverless での OpenShift Logging の使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

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

前提条件

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

手順

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

    $ oc -n openshift-logging get route kibana
  2. ルートの URL を使用して Kibana ダッシュボードに移動し、ログインします。
  3. インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。
  4. knative-serving namespace を使用してログをフィルターします。kubernetes.namespace_name:knative-serving を検索ボックスに入力して結果をフィルターします。
注記

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

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

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

前提条件

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

手順

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

    $ oc -n openshift-logging get route kibana
  2. ルートの URL を使用して Kibana ダッシュボードに移動し、ログインします。
  3. インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。
  4. knative-serving namespace を使用してログをフィルターします。検索ボックスにサービスのフィルターを入力して、結果をフィルターします。

    フィルターの例

    kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{service_name}

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

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

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

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

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

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

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

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

分散トレーシングの詳細は、「distributed tracing architecture」および「Installing distributed tracing」を参照してください。

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

以下の手順を使用して、OpenShift Serverless で使用する Jaeger を設定できます。

前提条件

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

手順

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

    Jaeger CR

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

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

    トレース用の YAML の例

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

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

検証

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

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

    $ oc get route jaeger

    出力例

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

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

6.3. メトリクス

メトリクスを使用すると、開発者は Knative サービスのパフォーマンスを監視できます。

6.3.1. 前提条件

  • OpenShift Container Platform で Knative コンポーネントのメトリクスを表示するには、Web コンソールの Developer パースペクティブにアクセスできる必要があります。
警告

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

この問題の解決に関する詳細は、サービスメッシュと OpenShift Serverless の統合を参照してください。

6.3.2. キュープロキシーメトリクス

各 Knative サービスには、アプリケーションコンテナーへの接続をプロキシーするプロキシーコンテナーがあります。キュープロキシーのパフォーマンスについて多くのメトリクスが報告されます。

以下のメトリクスを使用して、要求がプロキシー側でキューに入れられているかどうか、およびアプリケーション側で要求を処理する際の実際の遅延を測定できます。

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

revision_request_count

queue-proxy Pod にルーティングされる要求の数。

カウンター

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

整数 (単位なし)

revision_request_latencies

リビジョン要求の応答時間。

ヒストグラム

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

ミリ秒

revision_app_request_count

user-container Pod にルーティングされる要求の数。

カウンター

configuration_namecontainer_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

整数 (単位なし)

revision_app_request_latencies

リビジョンアプリケーション要求の応答時間。

ヒストグラム

configuration_namenamespace_namepod_nameresponse_coderesponse_code_classrevision_nameservice_name

ミリ秒

revision_queue_depth

serving および waiting キューの現在の項目数。無制限の同時実行が設定されている場合には、このメトリクスは報告されません。

ゲージ

configuration_nameevent-displaycontainer_namenamespace_namepod_nameresponse_code_classrevision_nameservice_name

整数 (単位なし)

6.4. Knative サービスのモニタリング

OpenShift Container Platform モニタリングスタックを使用して、Knative サービスのヘルスチェックおよびメトリクスを記録し、表示できます。本セクションでは、以下のトピックについて説明します。

  • デフォルトで公開するメトリクス Knative サービス
  • カスタムメトリクスの公開設定方法
  • 公開されるメトリクスを収集するためにモニタリングスタックを設定する方法
  • サービスのメトリクスの表示方法
注記

メトリクスの収集は、Knative サービスの自動スケーリングには影響しません。これは、収集要求がアクティベーターを通過しないためです。その結果、Pod が実行していない場合に収集が行われることはありません。

6.4.1. デフォルトで公開される Knative サービスメトリクス

表6.1 ポート 9090 の各 Knative サービスについてデフォルトで公開されるメトリクス

メトリクス名、単位、およびタイプ詳細メトリックのタグ

queue_requests_per_second

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

キュープロキシーに到達する、1 秒あたりのリクエスト数。

Formula: stats.RequestCount / r.reportingPeriodSeconds

stats.RequestCount は、指定のレポート期間のネットワーク pkg 統計から直接計算されます。

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

queue_proxied_operations_per_second

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

1 秒あたりのプロキシー化された要求の数。

Formula: stats.ProxiedRequestCount / r.reportingPeriodSeconds

stats.ProxiedRequestCount は指定されたレポート期間のネットワーク pkg 統計から直接計算されます。

 

queue_average_concurrent_requests

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

この Pod で現在処理されている要求の数。

平均同時実行性は、ネットワークの pkg 側で次のように計算されます。

  • req の変更が行われると、変更間の時間デルタが計算されます。この結果に基づいて、デルタ上の現在の同時実行数が計算され、現在計算されている同時実行数に追加されます。また、デルタの合計が保持されます。

    デルタでの現在の同時実行処理は、以下のように計算されます。

    global_concurrency × デルタ

  • レポートが実行されるたびに、合計および現在の計算された同時実行性がリセットされます。
  • 平均同時実行値を報告すると、現在の計算処理はデルタの合計で除算されます。
  • 新しいリクエストが出されると、グローバル同時実行カウンターが増えます。リクエストが完了すると、カウンターが減少します。

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

queue_average_proxied_concurrent_requests

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

この Pod で現在処理されているプロキシー要求の数:

stats.AverageProxiedConcurrency

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

process_uptime

メトリック単位: 秒

メトリックのタイプ: ゲージ

プロセスが起動している秒数。

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

表6.2 ポート 9091 の各 Knative サービスについてデフォルトで公開されるメトリクス

メトリクス名、単位、およびタイプ詳細メトリックのタグ

request_count

メトリックの単位: dimensionless

メトリックの型: counter

queue-proxy にルーティングされる要求の数。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

request_latencies

メトリックの単位: ミリ秒

メトリックのタイプ: histogram

応答時間 (ミリ秒単位)。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

app_request_count

メトリックの単位: dimensionless

メトリックの型: counter

user-container にルーティングされる要求の数。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

app_request_latencies

メトリックの単位: ミリ秒

メトリックのタイプ: histogram

応答時間 (ミリ秒単位)。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

queue_depth

メトリックの単位: dimensionless

メトリックのタイプ: ゲージ

提供および待機キューの現在の項目数。無制限の同時実行の場合は報告されません。breaker.inFlight が使用されます。

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

6.4.2. カスタムアプリケーションメトリクスを含む Knative サービス

Knative サービスによってエクスポートされるメトリクスのセットを拡張できます。正確な実装は、使用するアプリケーションと言語によって異なります。

以下のリストは、処理されたイベントカスタムメトリクスの数をエクスポートするサンプル Go アプリケーションを実装します。

package main

import (
  "fmt"
  "log"
  "net/http"
  "os"

  "github.com/prometheus/client_golang/prometheus" 1
  "github.com/prometheus/client_golang/prometheus/promauto"
  "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
  opsProcessed = promauto.NewCounter(prometheus.CounterOpts{ 2
     Name: "myapp_processed_ops_total",
     Help: "The total number of processed events",
  })
)


func handler(w http.ResponseWriter, r *http.Request) {
  log.Print("helloworld: received a request")
  target := os.Getenv("TARGET")
  if target == "" {
     target = "World"
  }
  fmt.Fprintf(w, "Hello %s!\n", target)
  opsProcessed.Inc() 3
}

func main() {
  log.Print("helloworld: starting server...")

  port := os.Getenv("PORT")
  if port == "" {
     port = "8080"
  }

  http.HandleFunc("/", handler)

  // Separate server for metrics requests
  go func() { 4
     mux := http.NewServeMux()
     server := &http.Server{
        Addr: fmt.Sprintf(":%s", "9095"),
        Handler: mux,
     }
     mux.Handle("/metrics", promhttp.Handler())
     log.Printf("prometheus: listening on port %s", 9095)
     log.Fatal(server.ListenAndServe())
  }()

   // Use same port as normal requests for metrics
  //http.Handle("/metrics", promhttp.Handler()) 5
  log.Printf("helloworld: listening on port %s", port)
  log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
}
1
Prometheus パッケージの追加。
2
opsProcessed メトリクスの定義。
3
opsProcessed メトリクスのインクリメント。
4
メトリクス要求に別のサーバーを使用するように設定。
5
メトリクスおよび metrics サブパスの通常の要求と同じポートを使用するように設定。