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

• 連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっています。
• Kafka ブローカーを含む namespace を削除する場合、ブローカーの前にブローカーの auth.secret.ref.name シークレットが削除されると、namespace ファイナライザーが削除される可能性があります。

• 多数の Knative サービスで OpenShift Serverless を実行すると、Knative Activator Pod がデフォルトのメモリー制限 600MB に近い状態になる可能性があります。これらの Pod は、メモリー消費がこの制限に達すると再起動される可能性があります。activator デプロイメントの要求および制限は、KnativeServing カスタムリソースを変更して設定できます。

  apiVersion: operator.knative.dev/v1alpha1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    deployments:
    - name: activator
      resources:
      - container: activator
        requests:
          cpu: 300m
          memory: 60Mi
        limits:
          cpu: 1000m
          memory: 1000Mi

• Cloud Native Buildpacks を関数のローカルビルドストラテジーとして使用する場合、kn func は podman を自動的に起動したり、リモートデーモンに対して SSH トンネルを使用したりできません。これらの問題の回避策として、関数をデプロイする前に Docker または podman デーモンがローカル開発コンピューターですでに実行されていることです。
• 現時点で、クラスター上の関数ビルドが Quarkus および Golang ランタイムで失敗します。これらは Node、Typescript、Python、および Springboot ランタイムで正常に機能します。

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

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

• 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 キーに置き換えられました。キーの使用方法は同じです。

• 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 を使用して関数をビルドできませんでした。この問題は修正されています。

• 現在、ドメインマッピングコントローラーは、現在サポートされていないパスを含むブローカーの 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> になります。

• OpenShift Serverless は Knative Serving 0.26 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 0.26 を使用するようになりました。
• OpenShift Serverless は Kourier 0.26 を使用するようになりました。
• OpenShift Serverless は Knative kn CLI 0.26 を使用するようになりました。
• OpenShift Serverless は Knative Kafka 0.26 を使用するようになりました。
• kn func CLI プラグインは func 0.20 を使用するようになりました。

• Kafka ブローカーがテクノロジープレビュー機能として利用可能になりました。

  重要

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

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

• 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.yaml で builder プロパティーを 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

• 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 サービスごとに設定することもできるようになりました。

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

• 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

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

• 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 を使用します。

• OpenShift Serverless は Knative Serving 0.23.0 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 0.23.0 を使用するようになりました。
• OpenShift Serverless は Kourier 0.23.0 を使用するようになりました。
• OpenShift Serverless は Knative kn CLI 0.23.0 を使用するようになりました。
• OpenShift Serverless は Knative Kafka 0.23.0 を使用するようになりました。
• kn func CLI プラグインは func 0.17.0 を使用するようになりました。

• 今後の OpenShift Serverless 1.19.0 リリースでは、外部ルートの URL スキームはデフォルトで HTTPS になり、セキュリティーが強化されます。

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

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

• mTLS 機能は一般に利用可能 (GA) になりました。
• kn func を使用して関数を作成すると、Typescript テンプレートが利用できるようになりました。

• Knative Eventing 0.23.0 で API バージョンへの変更

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

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

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

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

• 本リリースでは、Kafka チャネルメトリクスは、対応する Web コンソールダッシュボードで監視されず、表示されません。これは、Kafka ディスパッチャーの調整プロセスが大幅に変更されたためです。

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

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

  この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。

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

  注記

  この問題は修正され、Camel-K バージョン 1.4.1 は OpenShift Serverless 1.17.0 と互換性があります。

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

• OpenShift Serverless 1.16.0 にアップグレードする前に、OpenShift Container Platform をバージョン 4.6.30、4.7.11、またはそれ以降にアップグレードする必要があります。

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

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

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

• サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。Service Mesh および mTLS で使用する Knative Serving メトリクスを有効にする方法は、Serverless ドキュメントの「Integrating Service Mesh with OpenShift Serverless」セクションを参照してください。

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

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

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

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

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

     $ oc delete services -n istio-system knative-local-gateway

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

     apiVersion: v1
     kind: Service
     metadata:
      name: knative-local-gateway
      namespace: istio-system
      labels:
        experimental.istio.io/disable-gateway-port-translation: "true"
     spec:
      type: ClusterIP
      selector:
        istio: ingressgateway
      ports:
        - name: http2
          port: 80
          targetPort: 8081

• クラスターに 1000 の Knative サービスがあり、Knative Serving の再インストールまたはアップグレードを実行する場合、KnativeServing カスタムリソース (CR) の状態が Ready になった後に最初の新しいサービスを作成すると遅延が生じます。

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

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

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

  この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。

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

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

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

  この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。

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

• OpenShift Serverless での Knative Kafka は一般に利用可能 (GA) になりました。

  重要

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

• OpenShift Serverless のインストールおよびアップグレード用の Operator チャネルが OpenShift Container Platform 4.6 以降のバージョンで stable に更新されました。

• OpenShift Serverless は、IBM Power Systems、IBM Z、および LinuxONE でサポートされるようになりましたが、以下の機能はまだサポートされていません。

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

• Kafka チャネルのサブスクリプションには READY のマークが付けられず、SubscriptionNotMarkedReadyByChannel 状態のままになることがあります。これを修正するには、Kafka チャネルの dispatcher を再起動します。

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

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

  この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。

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

• Channels and subscriptions、または
• ブローカー と トリガー。

• Node.js
• Python
• golang
• Quarkus
• TypeScript

• Getting started with functions。

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

• チャネルおよび サブスクリプション を作成します。これにより、イベントシンクがチャネルにサブスクライブし、イベントを受信できるようになります。
• クラスター管理者の場合、チャネルのデフォルト設定を設定できます。チャネルのデフォルトの設定 を参照してください。

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

前提条件

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

• OpenShift Serverless Operator のインストール後に、Knative Serving をインストールするか、Knative Eventing をインストールする ことができます。

前提条件

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

前提条件

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

• Knative イベント駆動型アーキテクチャーを使用する必要がある場合は、Knative Eventing をインストール できます。

前提条件

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

前提条件

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

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

前提条件

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

前提条件

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

前提条件

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

手順

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

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

前提条件

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

• OpenShift Serverless Operator が OpenShift Container Platform クラスターにインストールされている。

  重要

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

  $ kn: No such file or directory

前提条件

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

前提条件

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

  重要

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

  $ kn: No such file or directory

前提条件

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

手順

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

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

  ここで、

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

  • json または yaml 引数を --output フラグと共に使用して、イベントの出力形式を変更できます。

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

    簡単なイベントのビルド

    $ kn event build -o yaml

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

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

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

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

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

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

前提条件

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

手順

• イベントの送信：

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

  ここで、

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

  • イベントをクラスター内の Kubernetes リソースに送信する場合は、--to フラグを使用して宛先を指定します。

    • <Kind>:<ApiVersion>:<name> 形式を使用して Kubernetes リソースを指定します。

  • --namespace フラグは namespace を指定します。省略すると、namespace は現在のコンテキストから取得されます。

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

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

    コマンドの例

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

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

    コマンドの例

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

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

前提条件

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

手順

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

  $ kn func create -r <repository> -l <runtime> -t <template> <path>

  • 許可されるランタイム値には、node、go、python、quarkus、および typescript が含まれます。

  • 許可されるテンプレート値には、http および events が含まれます。

    コマンドの例

    $ kn func create -l typescript -t events examplefunc

    出力例

    Project path:  /home/user/demo/examplefunc
    Function name: examplefunc
    Runtime:       typescript
    Template:      events
    Writing events to /home/user/demo/examplefunc

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

    コマンドの例

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

    出力例

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

前提条件

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

手順

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

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

  出力例

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

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

手順

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

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

  出力例

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

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

  $ kn service list -n <namespace>

  出力例

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

手順

• 関数を説明します。

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

  コマンドの例

  $ kn func info -p function/example-function

  出力例

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

手順

• 関数を削除します。

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

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

前提条件

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

手順

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

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

  詳細は以下のようになります。

  • --image は、アプリケーションのイメージの URI です。

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

    コマンドの例

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

    出力例

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

手順

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

  サービス仕様の例

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

  1

  イメージのダウンロード時の イメージプルポリシー。

  2

  init コンテナーイメージの URI。

  3

  コンテナーファイルシステム内でボリュームがマウントされる場所。

• ソフトリミットは、厳格に強制される限度ではなく、目標となるリクエストの限度です。たとえば、トラフィックの急増が発生した場合、ソフトリミットのターゲットを超過できます。

• ハードリミットは、リクエストに対して厳密に適用される上限です。並行処理がハードリミットに達すると、それ以降のリクエストはバッファー処理され、リクエストを実行するのに十分な空き容量ができるまで待機する必要があります。

  重要

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

前提条件

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

手順

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

  コマンドの例

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

  詳細は以下のようになります。

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

• オプション: --traffic フラグは、1 つのコマンドで複数回指定できます。たとえば、@latest というタグの付いたリビジョンと stable という名前のリビジョンがある場合、次のように各リビジョンに分割するトラフィックの割合を指定できます。

  コマンドの例

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

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

  コマンドの例

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

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

• 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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

検証

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

  

前提条件

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

前提条件

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

前提条件

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

前提条件

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

ping ソースの削除

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

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

前提条件

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

ping ソースの削除

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

  $ oc delete -f <filename>

  コマンドの例

  $ oc delete -f ping-source.yaml

前提条件

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

検証

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

  

前提条件

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

前提条件

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

前提条件

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

• チャネルの作成後に、イベントシンクがチャネルにサブスクライブしてイベントを受信できるように、サブスクリプションを作成します。

前提条件

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

検証

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

  

前提条件

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

前提条件

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

前提条件

• 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

前提条件

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

手順

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

  $ kn subscription list

  出力例

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

前提条件

• 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