OpenShift Serverless について

• OpenShift Serverless は Knative Serving 1.14 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.14 を使用するようになりました。
• OpenShift Serverless は Kourier 1.14 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.14 を使用するようになりました。
• OpenShift Serverless は、Apache Kafka 1.14 に Knative を使用するようになりました。
• kn func CLI プラグインが func 1.15 を使用するようになりました。
• OpenShift Serverless Logic は、同じ namespace で OpenAPI の複数の設定をサポートするようになりました。
• OpenShift Serverless Logic の管理コンソールが、テクノロジープレビュー (TP) 機能として利用できるようになり、開発プロセスの効率化を実現します。
• OpenShift Serverless Logic 1.34 では、ワークフローが設定を通じてさまざまな OpenShift Container Platform クラスターにアクセスできるようにする新しい機能が導入されています。この機能により、ユーザーはワークフロー内で REST 呼び出しを定義して、複数のクラスターとシームレスに対話できるようになります。
• OpenShift Serverless Logic では、Job Service liveness チェックが強化され、リーダーステータスの取得に必要な時間を抑えることができるようになりました。新しいシステムプロパティー kogito.jobs-service.management.leader-check.expiration-in-seconds が導入され、リーダーステータスチェックに許可される最大時間を設定できるようになりました。
• 自動 EventType 登録は、テクノロジープレビュー (TP) として利用できるイベント機能です。ブローカーの Ingress とメモリー内チャネルで処理されたイベントに基づいて EventTypes オブジェクトを自動的に作成し、EventTypes の使用と作成のエクスペリエンスを向上させます。
• 暗号化サービスは、テクノロジープレビュー (TP) 機能として利用できるようになりました。
• スタートアッププローブがサポートされるようになり、コールドスタート時間が短縮され、アプリケーションの起動が高速化され、パフォーマンスが向上します。これらのプローブは、コンテナーの起動プロセスが遅いに特に役立ちます。
• OpenShift Serverless Serving のトランスポート暗号化機能により、TLS を使用してセキュリティーで保護され暗号化された HTTPS 接続を介してデータを転送できます。これは現在、テクノロジープレビュー (TP) 機能として利用できます。
• S2I ビルダーを使用する Go 関数が、Linux および Mac 開発者向けのテクノロジープレビュー (TP) 機能として利用できるようになりました。これにより、開発者はこれらのプラットフォームで Go 関数を実装および構築できます。
• Knative Serving のマルチコンテナーサポートにより、単一の Knative サービスを使用してマルチコンテナー Pod をデプロイできます。また、複数のコンテナーの readiness と liveness のプローブ値もサポートします。
• Knative Kafka トリガーの自動スケーリングが、テクノロジープレビュー (TP) として KEDA (Kubernetes Event-Driven Autoscaling) によって強化されました。CMA/KEDA を使用した自動スケーリングは、Kafka トリガーと KafkaSource オブジェクトのリソース割り当てを最適化することでパフォーマンスをさらに向上させ、イベント駆動型ワークロードでのスケーラビリティーを向上します。
• Knative Eventing は、テクノロジープレビュー (TP) 機能として、転送中のデータの暗号化 (Eventing TLS) のサポートを提供するようになりました。Knative Eventing コンポーネントを設定して、HTTPS アドレスを公開したり、ユーザー提供の CA 信頼バンドルをクライアントに追加したりできます。

• 以前は、KafkaSource.spec.net.tls.key の読み込みに失敗しても、KafkaSource オブジェクトが誤って Ready ステータスのままになっていました。この問題は解決されています。PKCS #1 (Public-Key Cryptography Standards#1) 形式のサポートされていない TLS 証明書を使用して Kafka Broker、KafkaChannel、KafkaSource、または KafkaSink オブジェクトを作成するとエラーが報告されるようになり、設定の問題が適切に処理され、通知されるようになりました。
• Eventing コントローラーが間違ったオブジェクトタイプ (Namespace) を誤って再キューに入れたため、"resource not found" というログエラーが発生しました。この問題は解決され、コントローラーがオブジェクトの再キューイングを処理するようになり、ロギングとリソース管理の正確性が向上されるようになります。

• 以前は、ユーザー namespace で KnativeServing や KnativeEventing などの Knative インストールリソースを作成すると、OpenShift Serverless Operator で無限調整ループが発生していました。この問題は、knative-serving または knative-eventing 以外の namespace で Knative インストールリソースが作成されないようにするアドミッション Webhook を再導入することで解決されました。
• 以前は、インストール後のバッチジョブは一定期間後に削除され、特権サービスアカウントはバインドされていない状態のままでした。これにより、コンプライアンスシステムが問題を警告しました。この問題は、完了したジョブを保持し、サービスアカウントがバインドされたままになることで解決されました。

• OpenShift Serverless は Knative Serving 1.12 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.12 を使用するようになりました。
• OpenShift Serverless は Kourier 1.12 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.12 を使用するようになりました。
• OpenShift Serverless は、Apache Kafka 1.12 に Knative を使用するようになりました。
• kn func CLI プラグインが func 1.14 を使用するようになりました。

• OpenShift Serverless Logic が一般提供 (GA) されました。このリリースには、OpenShift Serverless Logic の概要、ワークフローの作成、実行、デプロイの手順、OpenShift Serverless Logic Operator のインストールとアンインストールのガイドラインが含まれています。さらに、OpenAPI サービスとエンドポイントを設定する手順と、サービスのトラブルシューティングの手法も含まれています。詳細は、OpenShift Serverless Logic overview を参照してください。

  追加のドキュメントを参照することもできます。詳細は、Serverless Logic のドキュメント を参照してください。

• ARM64 上の OpenShift Serverless がテクノロジープレビューとして利用可能になりました。
• NamespacedKafka アノテーションは非推奨になりました。代わりに、データプレーン分離のない標準の Kafka ブローカーを使用します。
• 自動 EventType の自動作成を有効にすると、クラスター内で利用可能なイベントを簡単に検出できるようになります。この機能は開発者プレビューとして利用できます。
• OpenShift 開発者コンソールの開発者ビューの Observe タブ内で、Knative Eventing モニタリングダッシュボードを直接使用できるようになりました。
• Custom Metrics Autoscaler Operator を使用して、KafkaSource オブジェクトが定義する Apache Kafka ソースの Knative Eventing ソースを自動スケーリングできるようになりました。この機能はテクノロジープレビュー機能として利用可能で、Knative Eventing 内の Kafka ベースのイベントソースに対して強化されたスケーラビリティーと効率性を提供します。
• Kafka 実装を使用して Knative Broker を作成するときに、内部の Kafka トピックプロパティーをカスタマイズできるようになりました。これにより効率が向上し、管理が簡素化されます。
• 新しいトリガーフィルター機能がテクノロジープレビューとして利用できるようになりました。これらのフィルターはデフォルトで有効になっており、ユーザーは一連のフィルター式を指定できます。各式は各イベントに対して true または false に評価されます。

• マウントポイントの権限が異なるため、クラスタービルドでの直接アップロードは IBM zSystems (s390x) および IBM Power (ppc64le) では機能しません。

• Podman バージョン 4.6 を使用した関数のビルドとデプロイは invalid pull policy "1" エラーで失敗します。

  この問題を回避するには、Podman バージョン 4.5 を使用します。

• 以前は、インストール後のバッチジョブは一定期間後に削除され、特権サービスアカウントはバインドされていない状態のままでした。これにより、コンプライアンスシステムが問題を警告しました。この問題は、完了したジョブを保持し、サービスアカウントがバインドされたままになることで解決されました。

• OpenShift Serverless は Knative Serving 1.11 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.11 を使用するようになりました。
• OpenShift Serverless は Kourier 1.11 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.11 を使用するようになりました。
• OpenShift Serverless は、Apache Kafka 1.11 に Knative を使用するようになりました。
• kn func CLI プラグインが func 1.13 を使用するようになりました。

• テクノロジープレビュー (TP) 機能として利用可能な Serverless Logic が更新されました。

  使用方法は、Serverless Logic のドキュメント を参照してください。

• user コンテナーと queue-proxy コンテナーの OpenShift Serverless Functions の readiness と liveness プローブ設定を指定できます。
• OpenShift Serverless Functions は、OpenShift Pipelines バージョン 1.10 から 1.14 (最新) までをサポートするようになりました。OpenShift Pipelines の古いバージョンは、OpenShift Serverless Functions と互換性がなくなりました。
• Pipelines as Code の使用を含むクラスター内関数の構築は、OpenShift Data Foundation ストレージ上の IBM zSystems (s390x) および IBM Power (ppc64le) でのみサポートされるようになりました。
• func subscribe コマンドを使用して、関数を一連のイベントにサブスクライブできるようになりました。これにより、関数がフィルターによって定義された CloudEvent オブジェクトにリンクされ、自動応答が可能になります。
• 内部トラフィックの Knative Serving TLS 暗号化機能は非推奨になりました。それはテクニカルプレビュー機能でした。internal-encryption 設定フラグを使用した機能は利用できなくなり、今後のリリースで新しい設定フラグに置き換えられます。
• シークレットのフィルタリングは、OpenShift Serverless Operator 側でデフォルトで有効化されています。環境変数 ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID=true は、デフォルトで net-istio and net-kourier コントローラー Pod に追加されます。
• knative-serving namespace の domain-mapping および domain-mapping-webhook デプロイメント機能が削除されました。これらは現在、Serving Webhook および Serving Controller と統合されています。
• KnativeServing カスタムリソース (CR) で spec.config.domain フィールドを設定すると、デフォルトの外部ドメインは、knative-serving namespace の config-domain config map に自動的に入力されなくなります。ここで、正確なドメイン設定を確実にするために、config-domain config map を手動で設定する必要があります。
• net-kourier デプロイメントに gRPC ヘルスプローブを使用できるようになりました。Kourier コントローラーは、以前の exec コマンドとカスタムコマンドではなく、readiness と liveness の両方に標準の Kubernetes gRPC ヘルスプローブを使用するようになりました。より信頼性の高いプローブ応答を確保するために、timeoutSeconds 値が 100 ミリ秒から 1 秒に調整されました。
• 新しいトリガーフィルター機能がテクノロジープレビューとして利用できるようになりました。新しいトリガーフィルターがデフォルトで有効になりました。これにより、ユーザーはフィルター式のセットを指定できます。各式は、イベントごとに true または false に評価されます。
• Knative Eventing は、開発者プレビューとして、転送中のデータの暗号化 (Eventing TLS) のサポートを提供するようになりました。Knative Eventing コンポーネントを設定して、HTTPS アドレスを公開したり、ユーザー提供の CA 信頼バンドルをクライアントに追加したりできます。
• OpenShift Serverless は、システムコンポーネントのカスタム OpenShift CA バンドル注入をサポートするようになりました。詳細は、カスタム PKI の設定 を参照してください。
• Custom Metrics Autoscaler Operator を使用して、Apache Kafka ソースの Knative Eventing ソースを自動スケーリングできるようになりました。この機能は開発者プレビューとして利用可能で、Knative Eventing 内の Kafka ベースのイベントソースのスケーラビリティーと効率性が向上します。
• OpenShift 開発者コンソールの開発者ビューの Observe タブ内で、Knative Eventing モニタリングダッシュボードを直接使用できるようになりました。
• 同梱の Knative の EventTypes v1beta1 のサポートは、OpenShift Serverless 1.32 では非推奨になりました。OpenShift Serverless 1.32 では、Knative CLI は EventType v1beta2 API を使用してを促進します。以前のリリースでは、kn CLI は EventType API v1beta1 と下位互換性がなく、kn eventtypes サブコマンドグループに制限されています。したがって、最高のユーザーエクスペリエンスを得るには、一致する kn バージョンを使用することが推奨されます。

• 3scale-kourier-gateways のデフォルトの CPU 制限が 500m から 1s に増加されました。500 を超える Knative Service インスタンスが作成されると、CPU リソースがなくなり、3scale-kourier-gateways Pod で readiness および liveness プローブの失敗が発生する可能性があります。この調整は、上記の障害を減らし、高負荷時でもスムーズに動作させることを目的としています。

• マウントポイントの権限が異なるため、クラスタービルドでの直接アップロードは IBM zSystems (s390x) および IBM Power (ppc64le) では機能しません。

• Podman バージョン 4.6 を使用した関数のビルドとデプロイは invalid pull policy "1" エラーで失敗します。

  この問題を回避するには、Podman バージョン 4.5 を使用します。

• OpenShift Serverless は Knative Serving 1.10 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.10 を使用するようになりました。
• OpenShift Serverless は Kourier 1.10 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.10 を使用するようになりました。
• OpenShift Serverless は、Apache Kafka 1.10 に Knative を使用するようになりました。
• kn func CLI プラグインは func 1.11 を使用するようになりました。
• Service Mesh を使用した OpenShift Serverless マルチテナントがテクノロジープレビュー (TP) 機能として利用できるようになりました。

• テクノロジープレビュー (TP) 機能として利用可能な Serverless Logic が更新されました。

  使用方法は、Serverless Logic のドキュメント を参照してください。

• OpenShift Serverless を単一ノード OpenShift にインストールして使用できるようになりました。
• 既存の PersistentVolume オブジェクトの永続ボリューム要求 (PVC) を設定して、Serverless 機能で使用できるようになりました。
• Ingress に Kourier を指定し、DomainMapping を使用する場合、OpenShift Route の TLS はパススルーに設定され、TLS は Kourier Gateway によって処理されます。Serverless 1.31 以降では、Kourier Gateway 側で有効な暗号スイートを指定できるようになりました。

• Kourier が有効な場合の Red Hat OpenShift Service Mesh と Serverless の統合は非推奨になりました。Service Mesh の統合には net-kourier ではなく net-istio を使用してください。

  詳細は、「Red Hat OpenShift Service Mesh と Serverless の統合」セクションを参照してください。

• PodDistruptionBudget オブジェクトと HorizontalPodAutoscaler オブジェクトが 3scale-kourier-gateway デプロイメント用に追加されました。

  • PodDistruptionBudget は、デプロイメント内の Pod の最小可用性要件を定義するために使用されます。
  • HorizontalPodAutoscaler は、デプロイメント内の Pod の数を需要またはカスタムメトリクスに基づいて自動的にスケーリングするために使用されます。
• Knative ブローカーと Apache Kafka のチャネルによって使用される Apache Kafka トピック名のパターンを変更できるようになりました。
• DomainMapping v1alpha1 カスタムリソース定義 (CRD) は非推奨になりました。代わりに v1beta1 CRD を使用してください。
• テクノロジープレビュー (TP) 機能であった NamespacedKafka アノテーションは現在非推奨になり、データプレーン分離のない標準の Kafka ブローカーが優先されます。

• 以前は、完全な Red Hat OpenShift Service Mesh 統合と STRICT ピア認証を使用して Knative Eventing をデプロイする場合、PingSource アダプターのメトリクスは利用できませんでした。

  この問題は修正され、PingSource アダプターのメトリクスは、別の job と service ラベルの値を使用して収集されるようになりました。以前の値は pingsource-mt-adapter でしたが、新しい値は pingsource-mt-adapter-sm-service です。

• OpenShift Serverless は Knative Serving 1.9 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.9 を使用するようになりました。
• OpenShift Serverless は Kourier 1.9 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.9 を使用するようになりました。
• OpenShift Serverless は、Apache Kafka 1.9 に Knative を使用するようになりました。
• kn func CLI プラグインは func 1.10.1 を使用するようになりました。
• OpenShift Serverless は、HyperShift でホストされるクラスター上で実行されるようになりました。
• OpenShift Serverless は単一ノード OpenShift 上で実行されるようになりました。
• OpenShift Serverless に関する開発者エクスペリエンスは、Visual Studio Code (VSCode) の OpenShift IDE 拡張機能である OpenShift Toolkit を通じて利用できるようになりました。拡張機能は、VSCode Extension タブおよび VSCode Marketplace からインストールできます。Visual Studio Code OpenShift Toolkit 拡張機能については、Marketplace ページ を参照してください。
• OpenShift Serverless Functions は、Red Hat OpenShift Pipelines バージョン 1.10 および 1.11 をサポートするようになりました。Red Hat OpenShift Pipelines の古いバージョンは、OpenShift Serverless Functions と互換性がなくなりました。

• Serverless Logic は、テクノロジープレビュー (TP) 機能として利用できるようになりました。

  詳細は、Serverless Logic のドキュメント を参照してください。

• OpenShift Serverless 1.30.0 以降、s2i ビルダーを使用する IBM zSystems で次のランタイム環境がサポートされます。

  • NodeJS
  • Python
  • TypeScript
  • Quarkus

• Red Hat OpenShift Service Mesh とのイベント統合が、テクノロジープレビュー (TP) 機能として利用できるようになりました。

  このインテグレーションには次のものが含まれます。

  • PingSource
  • ApiServerSource
  • Knative Source for Apache Kafka
  • Knative Broker for Apache Kafka
  • Knative Sink for Apache Kafka
  • ContainerSource
  • SinkBinding
  • InMemoryChannel
  • KafkaChannel
  • Channel-based Knative Broker
• OpenShift Serverless Functions の Pipelines-as-code がテクノロジープレビュー機能として利用可能になりました。
• net-kourier のバースト値と 1 秒あたりのクエリー (QPS) の値を設定できるようになりました。

• OpenShift Serverless Functions ユーザーは、個々の Quarkus 関数の func.yaml ファイル内の readiness プローブ値と liveness プローブ値をオーバーライドできるようになりました。

  Quarkus、TypeScript、および Node.js 関数のガイダンスについては、「関数開発リファレンスガイド」を参照してください。

• OpenShift Serverless 1.30.0 以降、Kourier コントローラーとゲートウェイのマニフェストには、デフォルトで次の制限とリクエストがあります。

  • リクエスト:

    • cpu: 200m
    • memory: 200Mi

  • 制限:

    • cpu: 500m

    • memory: 500Mi

      OpenShift Serverless ドキュメントの「Knative Serving システムのデプロイメント設定のオーバーライド」セクションを参照してください。

• テクノロジープレビュー (TP) 機能であった NamespacedKafka アノテーションは現在非推奨になり、データプレーン分離のない標準の Kafka ブローカーが優先されます。

• 以前では、3scale-jourier-gateway Pod が毎日数千の net-jourier-controller DNS クエリーを送信していました。NXDOMAIN 応答ごとに新しいクエリーが送信されていました。これは、正しい DNS クエリーが生成されるまで続いていました。

  このクエリーには net-kourier-controller.knative-serving-ingress.svc.<cluster domain>. 完全修飾ドメイン名 (FQDN) が含まれるようになり、問題が解決されています。

• Podman バージョン 4.6 を使用した関数のビルドとデプロイは invalid pull policy "1" エラーで失敗します。

  この問題を回避するには、Podman バージョン 4.5 を使用します。

• Pipelines-as-code の使用を含むクラスター上での関数の構築は、IBM zSystems および IBM Power ではサポートされていません。
• Buildpack ビルダーは、IBM zSystems および IBM Power ではサポートされていません。

• 以前は、liveness プローブエラーが原因で net-kourier-controller が起動に失敗することがありました。これは修正されています。

• OpenShift Serverless は Knative Serving 1.8 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.8 を使用するようになりました。
• OpenShift Serverless は Kourier 1.8 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.8 を使用するようになりました。
• OpenShift Serverless は、Apache Kafka 1.8 に Knative を使用するようになりました。
• kn func CLI プラグインは func 1.10 を使用するようになりました。

• OpenShift Serverless 1.29 以降、次のようなさまざまな製品バージョンが利用できます。

  • 最新リリースは stable チャネルから入手できます。

  • 最新よりも古いリリースは、バージョンベースのチャネルを通じて入手できます。

    これを使用するには、サブスクリプションオブジェクト YAML ファイルのチャネルパラメーターを stable 版から対応するバージョンベースのチャネル (stable-1.29 など) に更新します。

    この変更により、最新リリースだけでなく、メンテナンス段階のリリースの更新も受け取れるようになります。

    さらに、Knative (kn) CLI のバージョンをロックできます。詳細は、「Knative CLI のインストール」セクションを参照してください。

• OpenShift Container Platform Pipelines を使用して、開発者コンソールから OpenShift Serverless 関数を作成できるようになりました。
• Knative Serving のマルチコンテナーのサポートが一般提供 (GA) になりました。この機能を使用すると、単一の Knative サービスを使用してマルチコンテナー Pod をデプロイできます。
• OpenShift Serverless 関数は、個々の Node.js および TypeScript 関数の func.yaml ファイル内の readiness プローブ値と liveness プローブ値をオーバーライドできるようになりました。
• GitHub リポジトリー内のソースコードが変更されたときに、関数がクラスターに自動的に再デプロイされるように設定できるようになりました。これにより、よりシームレスな CI/CD 統合が可能になります。
• Service Mesh とのイベント統合が開発者プレビュー機能として利用できるようになりました。統合には、PingSource、ApiServerSource、Knative Source for Apache Kafka、Knative Broker for Apache Kafka、Knative Sink for Apache Kafka、ContainerSource、および SinkBinding が含まれます。
• このリリースには、アップグレードされた OpenShift Serverless Logic の開発者プレビューが含まれています。
• Knative Operator Serving and Eventings CRD の API バージョン v1alpha1 は削除されました。代わりに v1beta1 バージョンを使用する必要があります。Serverless Operator のアップグレード時に CRD が自動的に更新されるため、これは既存のインストールには影響しません。

• DomainMapping で指定されたシークレットを更新する場合は、シークレットを更新するだけでは調整ループはトリガーされません。調整ループをトリガーするには、シークレットの名前を変更するか、Knative Ingress リソースを削除する必要があります。
• Webhook Horizontal Pod Autoscaler (HPA) 設定は、OpenShift Serverless Operator によってオーバーライドされます。その結果、より高いワークロードに対応することができなくなります。この問題を回避するには、ワークロードに対応する初期レプリカ値を手動で設定します。
• Red Hat OpenShift Serverless 1.27 より前に作成された KafkaSource リソースは、削除時にスタックします。この問題を回避するには、KafkaSource の削除を開始した後、リソースからファイナライザーを削除します。
• liveness プローブエラーが原因で net-kourier-controller を起動できない可能性があります。ナレッジベースのソリューションを使用して問題を回避できます。

• OpenShift Serverless は Knative Serving 1.7 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.7 を使用するようになりました。
• OpenShift Serverless は Kourier 1.7 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.7 を使用するようになりました。
• OpenShift Serverless は、Apache Kafka 1.7 に Knative ブローカー実装を使用するようになりました。
• kn func CLI プラグインは func 1.9.1 バージョンを使用するようになりました。
• OpenShift Serverless Functions の Node.js および TypeScript ランタイムが一般提供 (GA) になりました。
• OpenShift Serverless Functions の Python ランタイムがテクノロジープレビューとして利用可能になりました。
• Knative Serving のマルチコンテナーサポートがテクノロジープレビューとして利用可能になりました。この機能を使用すると、単一の Knative サービスを使用してマルチコンテナー Pod をデプロイできます。

• OpenShift Serverless 1.29 以降では、Knative Eventing の以下のコンポーネントが 2 つの Pod から 1 つにスケールダウンされます。

  • imc-controller
  • imc-dispatcher
  • mt-broker-controller
  • mt-broker-filter
  • mt-broker-ingress

• Serving CR の serverless.openshift.io/enable-secret-informer-filtering アノテーションが非推奨になりました。アノテーションは Istio に対してのみ有効ですが、Kourier では有効ではありません。

  OpenShift Serverless 1.28 では、OpenShift Serverless Operator は net-istio と net-kourier の両方の環境変数 ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID を挿入できます。

  シークレットフィルタリングを有効にする場合は、すべてのシークレットに networking.internal.knative.dev/certificate-uid: "<id>" というラベルを付ける必要があります。そうしないと、Knative Serving がシークレットを検出しないため、障害が発生します。新規および既存のシークレットの両方にラベルを付ける必要があります。

  次の OpenShift Serverless リリースのいずれかでは、シークレットフィルタリングがデフォルトで有効になります。障害が発生しないように、事前にシークレットにラベルを付けます。

• 現在、Python のランタイムは、IBM Power、IBM zSystems、および IBM® LinuxONE の OpenShift Serverless Functions ではサポートされません。

  Node.js、TypeScript、および Quarkus 関数は、これらのアーキテクチャーでサポートされます。

• Windows プラットフォームでは、app.sh ファイルのパーミッションが原因で、Source-to-Image ビルダーを使用して Python 関数をローカルで構築、実行、またはデプロイできません。

  この問題を回避するには、Windows Subsystem for Linux を使用します。

• Red Hat OpenShift Serverless 1.27 より前に作成された KafkaSource リソースは、削除時にスタックします。この問題を回避するには、KafkaSource の削除を開始した後、リソースからファイナライザーを削除します。

• OpenShift Serverless は Knative Serving 1.6 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.6 を使用するようになりました。
• OpenShift Serverless は Kourier 1.6 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.6 を使用するようになりました。
• OpenShift Serverless は Knative Kafka 1.6 を使用するようになりました。
• kn func CLI プラグインは func 1.8.1 を使用するようになりました。
• namespace スコープのブローカーがテクノロジープレビューとして利用できるようになりました。このブローカーは、たとえば、ロールベースのアクセス制御 (RBAC) ポリシーを実装するために使用できます。
• KafkaSink は、 デフォルトで CloudEvent バイナリーコンテンツモードを使用するようになりました。バイナリーコンテンツモードは、CloudEvent の代わりにボディーのヘッダーを使用するため、構造化モードよりも効率的です。たとえば、HTTP プロトコルの場合、HTTP ヘッダーを使用します。
• OpenShift Container Platform 4.10 以降で OpenShift Route を使用して、外部トラフィックに HTTP/2 プロトコルを介して gRPC フレームワークを使用できるようになりました。これにより、クライアントとサーバー間の通信の効率と速度が向上します。
• Knative Operator Serving および Eventings CRD の API バージョン v1alpha1 は、1.27 で非推奨になりました。これは今後のバージョンで削除される予定です。Red Hat は、代わりに v1beta1 バージョンを使用することを強く推奨しています。Serverless Operator のアップグレード時に CRD が自動的に更新されるため、これは既存のインストールには影響しません。
• 配信タイムアウト機能がデフォルトで有効になりました。これを使用すると、送信される HTTP リクエストごとにタイムアウトを指定できます。この機能は、引き続きテクノロジープレビューです。

• 以前は、Knative サービスが Ready 状態にならないことがあり、ロードバランサーの準備が整うのを待っていると報告されていました。この問題は修正されました。

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

• namespace スコープブローカーは、namespace スコープブローカーを削除した後でも、ClusterRoleBindings をユーザーの namespace に残す場合があります。

  これが発生した場合は、ユーザー namespace で rbac-proxy-reviews-prom-rb-knative-kafka-broker-data-plane-{{.Namespace}}という名前の ClusterRoleBinding を削除します。

• Quarkus を使用した OpenShift Serverless Functions が GA になりました。
• OpenShift Serverless は Knative Serving 1.5 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.5 を使用するようになりました。
• OpenShift Serverless は Kourier 1.5 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.5 を使用するようになりました。
• OpenShift Serverless は Knative Kafka 1.5 を使用するようになりました。
• OpenShift Serverless は Knative Operator 1.3 を使用するようになりました。
• kn func CLI プラグインは func 1.8.1 を使用するようになりました。
• 永続ボリューム要求 (PVC) が GA になりました。PVC は、Knative サービスに永続的なデータストレージを提供します。

• 新しいトリガーフィルター機能が開発者プレビューとして利用できるようになりました。これにより、ユーザーはフィルター式のセットを指定できます。各式は、イベントごとに true または false に評価されます。

  新しいトリガーフィルターを有効にするには、Operator config map の KnativeEventing タイプのセクションに new-trigger-filters: enabled エントリーを追加します。

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...
  ...
  spec:
    config:
      features:
        new-trigger-filters: enabled
  ...

  Copy to Clipboard Toggle word wrap

• Knative Operator 1.3 は、operator.knative.dev の更新された v1beta1 バージョンの API を追加します。

  KnativeServing および KnativeEventing カスタムリソース config map で v1alpha1 から v1beta1 に更新するには、apiVersion キーを編集します。

  KnativeServing カスタムリソース config map の例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  ...

  Copy to Clipboard Toggle word wrap

  KnativeEventing カスタムリソース config map の例

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...

  Copy to Clipboard Toggle word wrap

• 以前、連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっていました。これは修正され、FIPS モードが利用できるようになりました。

• OpenShift Serverless は Knative Serving 1.4 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.4 を使用するようになりました。
• OpenShift Serverless は Kourier 1.4 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.4 を使用するようになりました。
• OpenShift Serverless は Knative Kafka 1.4 を使用するようになりました。
• kn func CLI プラグインは func 1.7.0 を使用するようになりました。
• 関数を作成およびデプロイするための統合開発環境 (IDE) プラグインが、Visual Studio Code および IntelliJ で利用できるようになりました。

• Knative Kafka ブローカーが一般提供されるようになりました。Knative Kafka ブローカーは、Apache Kafka を直接ターゲットとする、Knative ブローカー API の高性能な実装です。

  MT-Channel-Broker ではなく、Knative Kafka ブローカーを使用することを推奨します。

• Knative Kafka シンクが一般提供されるようになりました。KafkaSink は CloudEvent を取得し、Apache Kafka トピックに送信します。イベントは、構造化コンテンツモードまたはバイナリーコンテンツモードのいずれかで指定できます。
• 内部トラフィックの TLS の有効化がテクノロジープレビューとして利用可能になりました。

• 以前のバージョンでは、Knative Serving には liveness プローブの失敗後にコンテナーが再起動された場合に readiness プローブが失敗する問題がありました。この問題は修正されました。

• 連邦情報処理標準 (FIPS) モードは、Kafka ブローカー、Kafka ソース、および Kafka シンクに対して無効になっています。
• SinkBinding オブジェクトは、サービスのカスタムリビジョン名をサポートしません。

• Knative Serving Controller Pod は、クラスター内のシークレットを監視するための新しいインフォーマーを追加します。インフォーマーはシークレットをキャッシュに含めるため、コントローラー Pod のメモリー消費量が増加します。

  Pod のメモリーが不足している場合は、デプロイのメモリー制限を増やすことで問題を回避できます。

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

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

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

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

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

• OpenShift Serverless 1.23 では、KafkaBindings および kafka -binding Webhook のサポートが削除されました。ただし、既存の kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration が残り、もはや存在しない kafka-source-webhook サービスを指している可能性があります。

  クラスター上の KafkaBindings の特定の仕様では、kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration が、Webhook を介して、デプロイメント、Knative Services、ジョブなどのさまざまなリソースに作成および更新イベントを渡すように設定されている場合がありますが、そのように設定されていると失敗します。

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

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

  Copy to Clipboard Toggle word wrap

• 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 アクティベーター Pod がデフォルトのメモリー制限である 600MB 近くで実行される可能性があります。これらの Pod は、メモリー消費がこの制限に達すると再起動される可能性があります。アクティベーターデプロイメントの要求と制限は、KnativeServing カスタムリソースを変更することで設定できます。

  apiVersion: operator.knative.dev/v1beta1
  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

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

• OpenShift Serverless は Knative Serving 1.1 を使用するようになりました。
• OpenShift Serverless は Knative Eventing 1.1 を使用するようになりました。
• OpenShift Serverless は Kourier 1.1 を使用するようになりました。
• OpenShift Serverless は Knative (kn) CLI 1.1 を使用するようになりました。
• OpenShift Serverless は Knative Kafka1.1 を使用するようになりました。
• kn func CLI プラグインは func 0.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 を設定し、ブローカーの正確なパスをカスタムドメインに追加する必要があります。

  DomainMapping CR の例

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

  Copy to Clipboard Toggle word wrap

  その場合、ブローカーの 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 プラグインがテクノロジープレビューとして利用できるようになりました。
• kn service create コマンドの --min-scale フラグと --max-scale フラグは非推奨になりました。代わりに、-scale-min フラグと --scale-max フラグを使用してください。

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

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

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

  Copy to Clipboard Toggle word wrap

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

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

  Copy to Clipboard Toggle word wrap

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

• 現在、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

  Copy to Clipboard Toggle word wrap

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

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

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

  Copy to Clipboard Toggle word wrap

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

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

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

  buildEnvs: []

  Copy to Clipboard Toggle word wrap

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

  buildEnvs:
  - name: BP_NODE_RUN_SCRIPTS
    value: build

  Copy to Clipboard Toggle word wrap

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

  ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF

  Copy to Clipboard Toggle word wrap

  • この問題には、以下の回避策があります。

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

       サービス設定の例

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

       Copy to Clipboard Toggle word wrap

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

       $ systemctl --user daemon-reload

       Copy to Clipboard Toggle word wrap

       $ systemctl restart --user podman.socket

       Copy to Clipboard Toggle word wrap

  • または、TCP を使用して podman API を公開することもできます。

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

    Copy to Clipboard Toggle word wrap

• 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

  Copy to Clipboard Toggle word wrap

  • この問題には、以下の回避策があります。

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

       サービス設定の例

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

       Copy to Clipboard Toggle word wrap

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

       $ systemctl --user daemon-reload

       Copy to Clipboard Toggle word wrap

       $ systemctl restart --user podman.socket

       Copy to Clipboard Toggle word wrap

  • または、TCP を使用して podman API を公開することもできます。

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

    Copy to Clipboard Toggle word wrap

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

  Copy to Clipboard Toggle word wrap

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

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "https"
  ...

  Copy to Clipboard Toggle word wrap

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

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

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

  Copy to Clipboard Toggle word wrap
• 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 を使用します。

• サーバーレスコンテナーの簡素化されたデプロイメント
• scale-to-zero を含むトラフィックベースの自動スケーリング
• ルーティングおよびネットワークプログラミング
• 特定の時点のアプリケーションスナップショットとその設定

• サービスは開発中に疎結合され、実稼働環境に独立してデプロイされます。
• プロデューサーは、コンシューマーがリッスンする前にイベントを生成できます。また、コンシューマーはまだ生成されていないイベントまたはイベントのクラスに対して、リソースを受信する意思を示すことができます。
• サービスを接続して、プロデューサーやコンシューマーを変更せずに新しいアプリケーションを作成でき、特定のプロデューサーから特定のイベントのサブセットを選択することもできます。

• 以下のビルドストラテジーをサポートします。

  • Source-to-Image (S2I)
  • buildpacks
• 複数のランタイム
• Knative (kn) CLI によるローカル開発者エクスペリエンス
• プロジェクトテンプレート
• CloudEvents およびプレーン HTTP リクエストを受信するサポート

• 次の Knative Serving 機能の管理をサポートします。

  • サービス
  • リビジョン
  • ルート

• 次の Knative Eventing エンティティーの管理をサポートします。

  • ソース
  • ブローカー
  • トリガー
  • チャネル
  • サブスクリプション
• Kubernetes (kubectl) CLI ツールの設計に基づいたプラグインアーキテクチャー
• Knative の Tekton パイプラインへの統合

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

• 1 つ以上の特定の機能に関連するデータを収集するには、以下のセクションに示すように、イメージと共に --image 引数を使用します。

  以下に例を示します。

  $ oc adm must-gather  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.13.0

  Copy to Clipboard Toggle word wrap

• 監査ログを収集するには、以下のセクションで説明されているように -- /usr/bin/gather_audit_logs 引数を使用します。

  以下に例を示します。

  $ oc adm must-gather -- /usr/bin/gather_audit_logs

  Copy to Clipboard Toggle word wrap
  注記

  ファイルのサイズを小さくするために、監査ログはデフォルトの情報セットの一部として収集されません。

前提条件

• OpenShift CLI (oc) がインストールされている。

手順

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

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

  Copy to Clipboard Toggle word wrap

  コマンドの例

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

  Copy to Clipboard Toggle word wrap