Serverless アプリケーション

Azure Red Hat OpenShift 4

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

Red Hat OpenShift Documentation Team

概要

本書では、Azure Red Hat OpenShift 4 で OpenShift Serverless を使用する方法について説明します。

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

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

1.1. サポート

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

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

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

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

1.2.1. 新機能

  • OpenShift Serverless 1.7.0 は、Azure Red Hat OpenShift 4.3 以降のバージョンで一般に利用可能 (GA) になりました。以前のバージョンでは、OpenShift Serverless はテクノロジープレビューでした。
  • OpenShift Serverless は Knative Serving 0.13.2 を使用するようになりました。
  • OpenShift Serverless は Knative Serving Operator 0.13.2 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.13.2 を使用するようになりました。
  • Knative kn CLI ダウンロードが、非接続またはネットワークが制限されたインストールをサポートするようになりました。
  • Knative kn CLI ライブラリーが Red Hat によって署名されるようになりました。
  • Knative Eventing が OpenShift Serverless でテクノロジープレビューとして利用可能になりました。OpenShift Serverless は Knative Eventing 0.13.2 を使用するようになりました。
重要

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

  • 高可用性 (HA) は、autoscaler-hpacontrolleractivatorkourier-control、および kourier-gateway コンポーネントに対してデフォルトで有効にされます。

    以前のバージョンの OpenShift Serverless をインストールしている場合、KnativeServing カスタムリソース (CR) が更新されると、デプロイメントはデフォルトで KnativeServing.spec.high-availability.replicas = 2 が指定される HA 設定になります。

    高可用性コンポーネントの設定」の手順を実行して、これらのコンポーネントの HA を無効にすることができます。

  • OpenShift Serverless は、Azure Red Hat OpenShift のクラスター全体のプロキシーで trustedCA 設定をサポートし、Azure Red Hat OpenShift のプロキシー設定と完全に互換性があります。
  • OpenShift Serverless は、Azure Red Hat OpenShift ルートに登録されているワイルドカード証明書を使用して HTTPS をサポートするようになりました。Knative Serving の http および https の詳細は、「サーバーレスアプリケーションのデプロイメントの確認」を参照してください。

1.2.2. 修正された問題

  • 以前のバージョンでは、API グループを指定せずに KnativeServing カスタムリソース (CR) を要求 (oc get knativeserving -n knative-serving などを実行) すると、エラーが発生することがありました。この問題は OpenShift Serverless 1.7.0 で修正されました。
  • 以前のバージョンでは、Knative Serving コントローラーは、サービス CA 証明書のローテーションにより新規サービス CA 証明書が生成されても通知されませんでした。サービス CA 証明書のローテーション後に作成された新規リビジョンはエラーを出して失敗しました。

    Revision "foo-1" failed with message: Unable to fetch image "image-registry.openshift-image-registry.svc:5000/eap/eap-app": failed to resolve image to digest: failed to fetch image information: Get https://image-registry.openshift-image-registry.svc:5000/v2/: x509: certificate signed by unknown authority.

    OpenShift Serverless Operator は、新規サービス CA 証明書が生成されるたびに Knative Serving コントローラーを再起動するようになりました。これにより、コントローラーは常に現在のサービス CA 証明書を使用するように設定されます。詳細は、Azure Red Hat OpenShift ドキュメントの『 認証』の「サービス提供証明書のシークレットによるサービストラフィックのセキュリティー保護」を参照してください。

1.2.3. 既知の問題

  • OpenShift Serverless 1.6.0 から 1.7.0 にアップグレードする場合、HTTPS のサポートではルートの形式を変更する必要があります。OpenShift Serverless 1.6.0 で作成された Knative サービスは、古い形式の URL で到達できなくなりました。OpenShift Serverless のアップグレード後に、各サービスの新規 URL を取得する必要があります。詳細は、OpenShift Serverless のアップグレードについてのドキュメントを参照してください。
  • Azure クラスターで Knative Eventing を使用している場合、 imc-dispatcher Pod が起動しない可能性があります。これは、Pod のデフォルト resources 設定によって生じます。回避策として、resources 設定を削除できます。
  • クラスターに 1000 の Knative サービスがあり、Knative Serving の再インストールまたはアップグレードを実行する場合、KnativeServing の状態が Ready になった後に最初の新規サービスを作成すると遅延が生じます。

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

1.3. Red Hat OpenShift Serverless テクノロジープレビューリリースノート (1.6.0)

1.3.1. 新機能

  • OpenShift Serverless 1.6.0 は Azure Red Hat OpenShift 4.3 以降のバージョンで利用できます。
  • OpenShift Serverless は Knative Serving 0.13.1 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.13.1 を使用するようになりました。
  • OpenShift Serverless は Knative Serving Operator 0.13.1 を使用するようになりました。
  • serving.knative.dev API グループは完全に非推奨となり、operator.knative.dev API グループによって置き換えられました。

    OpenShift Serverless 1.4.0 リリースノートで説明されている手順を完了して、serving.knative.dev API グループを operator.knative.dev API グループに置き換えてから、OpenShift Serverless の最新バージョンにアップグレードできるようにする必要があります。

    重要

    この変更により、oc get knativeserving などの完全修飾 APIGroup および kind がないコマンドの信頼性は低くなり、常に正常に機能する状態を保てなくなります。

    OpenShift Serverless 1.6.0 へのアップグレード後に、この問題を解決するために古い CRD を削除する必要があります。以下のコマンドを実行して古い CRD を削除できます。

    $ oc delete crd knativeservings.serving.knative.dev
  • 新規 OpenShift Serverless リリースの Subscription Update Channel は、 techpreview から preview-4.3 に更新されました。

    重要

    アップグレードについてのドキュメントに従ってチャネルを更新し、最新の OpenShift Serverless バージョンを使用できるようにする必要があります。

  • OpenShift Serverless が HTTP_PROXY の使用をサポートするようになりました。
  • OpenShift Serverless は HTTPS_PROXY クラスタープロキシー設定をサポートするようになりました。

    注記

    この HTTP_PROXY サポートにはカスタム証明書の使用は含まれません。

  • KnativeServing CRD はデフォルトで Developer Catalog から非表示になり、クラスター管理者のパーミッションを持つユーザーのみがこれを表示できるようになりました。
  • KnativeServing コントロールプレーンおよびデータプレーンの一部は、デフォルトで可用性が高い (HA) ものとしてデプロイされるようになりました。
  • Kourier はアクティブに監視され、変更を自動的に調整するようになりました。
  • OpenShift Serverless は Azure Red Hat OpenShift の夜間ビルドでの使用をサポートするようになりました。

1.3.2. 修正された問題

  • 以前のバージョンでは、oc explain コマンドが適切に動作しませんでした。KnativeServing CRD の構造スキーマが OpenShift Serverless 1.6.0 で更新され、oc explain コマンドが正常に機能するようになりました。
  • 以前のバージョンでは、複数の KnativeServing CR を作成できました。OpenShift Serverless 1.6.0 では、複数の KnativeServing CR が同期的に回避されるようになりました。複数の KnativeServing CR を作成しようとすると、エラーが発生します。
  • 以前のバージョンでは、OpenShift Serverless には GCP での Azure Red Hat OpenShift デプロイメントとの互換性がありませんでした。この問題は OpenShift Serverless 1.6.0 で修正されました。
  • 以前のリリースでは、Knative Serving Webhook は、クラスターに 170 を超える namespace がある場合にメモリー不足のエラーでクラッシュしていました。この問題は OpenShift Serverless 1.6.0 で修正されました。
  • 以前のリリースでは、OpenShift Serverless は、ルートが別のコンポーネントによって変更された場合に作成された Azure Red Hat OpenShift ルートを自動的に修正しませんでした。この問題は OpenShift Serverless 1.6.0 で修正されました。
  • 以前のバージョンでは、KnativeServing CR を削除すると、システムがハングすることがありました。この問題は OpenShift Serverless 1.6.0 で修正されました。
  • OpenShift Serverless 1.5.0 で発生したサービスメッシュから Kourier への ingress の移行により、孤立した VirtualServices がシステムに残ることがありました。OpenShift Serverless 1.6.0 では、孤立した VirtualServices が自動的に削除されます。

1.3.3. 既知の問題

  • OpenShift Serverless 1.6.0 では、クラスター管理者がドキュメントで説明されているアンインストール手順に従って OpenShift Serverless をアンインストールしても、Serverless のドロップダウンは Azure Red Hat OpenShift Web コンソールの Administrator パースペクティブに依然として表示され、Knative Service リソースは Azure Red Hat OpenShift Web コンソールの Developer パースペクティブに依然として表示されます。このオプションを使用して Knative サービスを作成することはできますが、これらの Knative サービスは動作しません。

    OpenShift Serverless が Azure Red Hat OpenShift Web コンソールに表示されないようにするには、クラスター管理者は Knative Serving CR を削除した後にデプロイメントから追加の CRD を削除する必要があります。

    クラスター管理者は、以下のコマンドを実行してこれらのロールを削除できます。

    $ oc get crd -oname | grep -E '(serving|internal).knative.dev' | xargs oc delete

1.4. Red Hat OpenShift Serverless テクノロジープレビューリリースノート (1.5.0)

1.4.1. 新機能

  • OpenShift Serverless 1.5.0 は Azure Red Hat OpenShift 4.3 以降のバージョンで利用できます。
  • OpenShift Serverless は Knative Serving 0.12.1 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.12.0 を使用するようになりました。
  • OpenShift Serverless は Knative Serving Operator 0.12.1 を使用するようになりました。
  • OpenShift Serverless ingress 実装は、サービスメッシュの代わりに Kourier を使用するように更新されました。OpenShift Serverless Operator が 1.5.0 にアップグレードされる際にこの変更は自動的に実行されるため、ユーザーの介入は必要ありません。

1.4.2. 修正された問題

  • 以前のリリースでは、Azure Red Hat OpenShift がゼロレイテンシーからスケーリングすると、Pod の作成時に約 10 秒の遅延が発生しました。この問題は、Azure Red Hat OpenShift 4.3.5 バグ修正の更新で修正されました。

1.4.3. 既知の問題

  • KnativeServing.operator.knative.devknative-serving namespace から削除すると、削除プロセスがハングする可能性があります。これは、CRD の削除と knative-openshift-ingress がファイナライザーを削除する間に競合状態が生じるためです。

1.5. Red Hat OpenShift Serverless テクノロジープレビューリリースノート (1.4.0)

重要

OpenShift Serverless 1.4.0 には不適切な所有者の参照が含まれており、これにより Kubernetes Ggarbage Collector はすべてのサービスを含む、Knative コントロールプレーン全体を誤って削除してしまいます。この問題を修正するには、OpenShift Serverless 1.4.1 をインストールする必要があります。

1.5.1. 新機能

  • OpenShift Serverless 1.4.0 は Azure Red Hat OpenShift 4.2 以降のバージョンで利用できます。
  • OpenShift Serverless は Knative Serving 0.11.1 を使用するようになりました。
  • OpenShift Serverless は Knative kn CLI 0.11.0 を使用するようになりました。
  • OpenShift Serverless は Knative Serving Operator 0.11.1 を使用するようになりました。
  • kn CLI は、Azure Red Hat OpenShift Web コンソールの「Command Line Tools」ページからダウンロードできるようになりました。
  • KnativeServing オブジェクトの API グループは、本リリースで serving.knative.dev から operator.knative.dev に変更されました。古い API グループに依存するスクリプトまたはアプリケーションのいずれかを調整して、新規 API グループを使用する必要があります。OpenShift Serverless のインストール手順が更新され、新規 API グループを使用できるようになりました。

    古いグループを一時的に使用し続ける必要がある場合には、これまでのように古いカスタムリソース (CR) を使用できます。ただし、この CR は非推奨となり、最終的には削除されます。

    新規 API グループへの参照を更新した後に、古い CR バージョンを削除し、代わりに新たにデプロイされた KnativeServing CR を使用できます。ダウンタイムなしにこれを安全に行うには、以下を使用して、新たにデプロイされた KnativeServing CR から所有者の参照を削除します。

     $ oc edit knativeserving.operator.knative.dev knative-serving -n knative-serving

    所有者の参照を削除した後には、古い CR バージョンを安全に削除し、新規 CR の使用を開始できます。

    重要

    CR の以前のバージョンが存在する場合、新規 CR への変更は OpenShift Serverless Operator によって上書きされます。古い CR は引き続きアクティブな状態ですが、その CR に対してすべての変更を加える必要があります。

1.5.2. 修正された問題

  • knative-serving-ingress Service Mesh の一部ではない namespace からプライベートのクラスターのローカル Knative Service に接続すると、i/o timeout で失敗しました。この問題は修正されています。
  • container_name および pod_name メトリクスラベルは Azure Red Hat OpenShift 4.3 で削除されました。本書は、新規の container および pod メトリクスラベルを代わりに使用するように更新されています。Azure Red Hat OpenShift 4.3 以降の Serverless でメータリングを使用している場合、Serverless のメータリングについてのドキュメントの現行バージョンに基づいて Prometheus クエリーを更新する必要があります。

1.5.3. 既知の問題

  • oc コマンドでの knativeserving の不適切な使用は、新規 API グループへの移行により機能しなくなりました。たとえば、このコマンドは機能しません。

    $ oc get knativeserving -n knative-serving

    代わりに明示的な完全修飾形式を使用します。例:

    $ oc get knativeserving.operator.knative.dev -n knative-serving
  • Azure Red Hat OpenShift がゼロレイテンシーからスケーリングすると、Pod の作成時に約 10 秒の遅延が発生します。これは、現在の Azure Red Hat OpenShift の制限です。

1.6. 追加リソース

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

第2章 OpenShift Serverless のサポート

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

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

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

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

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

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

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

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

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

oc adm must-gather CLI コマンドを使用してクラスターについての情報を収集できます。これには、OpenShift Serverless に関連する機能およびオブジェクトが含まれます。

must-gather を使用して OpenShift Serverless データを収集するには、OpenShift Serverless イメージを指定する必要があります。

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

第3章 OpenShift Serverless の使用開始

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

3.1. OpenShift Serverless の仕組み

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

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

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

3.2. サポートされる設定

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

3.3. OpenShift Serverless コンポーネント

このセクションでは、OpenShift Serverless のコンポーネントについて説明します。

3.3.1. Knative Serving

Azure Red Hat OpenShift 上の Knative Serving は、サーバーレスアプリケーションのデプロイおよび管理をサポートするために Kubernetes および Kourier をベースにビルドされます。

これは、Azure Red Hat OpenShift クラスター上のサーバーレスワークロードの動作を定義し、制御するために使用される Kubernetes カスタムリソース定義 (CRD) のセットを作成します。

これらの CRD は、以下のような複雑なユースケースに対応するビルディングブロックです。

  • サーバーレスコンテナーの迅速なデプロイ
  • Pod の自動スケーリング
  • デプロイされたコードおよび設定のポイントインタイムスナップショットの表示

3.3.2. Knative Eventing

Azure Red Hat OpenShift の Knative Eventing を使用すると、開発者はサーバーレスアプリケーションのイベント駆動型アーキテクチャーを使用して、システムのコンポーネントがどのように通信するかについてより簡単に宣言できます。イベント駆動型のアーキテクチャーは、イベントプロデューサーとイベントコンシューマー間の関係を切り離すという概念に基づいています。

イベント駆動型のアーキテクチャーについての詳細は、「 イベント駆動型アーキテクチャとは」を参照してください。

第4章 OpenShift Serverless のインストール

4.1. OpenShift Serverless のインストール

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

注記

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

4.1.1. クラスターサイジングの要件

OpenShift Serverless を実行するには、Azure Red Hat OpenShift クラスターのサイズを適切に設定する必要があります。OpenShift Serverless を使用する最小要件は、10 CPU および 40GB メモリーを持つクラスターです。

OpenShift Serverless を実行するための合計サイズ要件は、デプロイされたアプリケーションによって異なります。デフォルトで、各 Pod は CPU ~400m を要求し、推奨値のベースはこの値になります。

指定されるサイズ要件において、アプリケーションはレプリカを最大 10 つにスケールアップできます。アプリケーションの実際の CPU 要求を減らすと、レプリカ数が増える可能性があります。

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

MachineSet の手動によるスケーリングについての詳細は、MachineSet の手動によるスケーリングについてのドキュメントを参照してください。

注記

指定される要件は、Azure Red Hat OpenShift クラスターのワーカーマシンのプールにのみ関連します。マスターノードは一般的なスケジューリングには使用されず、要件から省略されます。

注記

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

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

4.1.1.1. 高度なユースケースの追加要件

Azure Red Hat OpenShift でのロギングまたはメータリングなどの高度なユースケースの場合は、追加のリソースをデプロイする必要があります。このようなユースケースで推奨される要件は 24 vCPU および 96GB メモリーです。

クラスターで高可用性 (HA) を有効にしている場合、これには Knative Serving コントロールプレーンの各レプリカについて 0.5 - 1.5 コアおよび 200MB - 2GB のメモリーが必要です。HA は、デフォルトで一部の Knative Serving コンポーネントについて有効にされます。「高可用性コンポーネントの設定」のドキュメントに従って HA を無効にできます。

重要

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

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

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

手順

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

    Azure Red Hat OpenShift Web コンソールでの OpenShift Serverless Operator
  3. Operator についての情報を確認してから、Install をクリックします。

    OpenShift Serverless Operator の情報
  4. Create Operator Subscription ページで以下を実行します。

    Create Operator Subscription ページ
    1. Installation ModeAll namespaces on the cluster (default) になります。このモードは、デフォルトの openshift-operators namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。
    2. Installed Namespaceopenshift-operators になります。
    3. Update Channel を選択します。

      1. 4.3 チャネルは、OpenShift Serverless Operator の最新の安定したリリースのインストールを有効にします。
      2. preview-4.3 チャネルは、OpenShift Serverless Operator の最新プレビューバージョンのインストールを有効にします。これには、4.3 更新チャネルでは利用できない機能が含まれる場合があります。
    4. Automatic または Manual 承認ストラテジーを選択します。
  5. Subscribe をクリックし、Operator をこの Azure Red Hat OpenShift クラスターの選択した 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 に解決することを確認します。

Installed Operators ページ

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

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

追加リソース

  • 詳細は、Azure Red Hat OpenShift ドキュメントの Operator のクラスターへの追加 について参照してください。

4.1.3. 次のステップ

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

4.2. Knative Serving のインストール

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

4.2.1. knative-serving namespace の作成

knative-serving namespace を作成する際に、knative-serving プロジェクトも作成されます。

重要

Knative Serving をインストールする前に、この手順を完了する必要があります。

Knative Serving のインストール時に作成された KnativeServing オブジェクトが knative-serving namespace で作成されていない場合、これは無視されます。

前提条件

  • クラスター管理者のアクセスを持つ Azure Red Hat OpenShift アカウント
  • OpenShift Serverless Operator がインストールされていること。

4.2.1.1. Web コンソールを使用した knative-serving namespace の作成

手順

  1. Azure Red Hat OpenShift Web コンソールで、 AdministrationNamespaces に移動します。

    Namespaces page
  2. プロジェクトの Name として knative-serving を入力します。他のフィールドはオプションです。

    `knative-eventing` namespace の作成
  3. Create をクリックします。

4.2.1.2. CLI を使用した knative-serving namespace の作成

手順

  1. 以下を入力して knative-serving namespace を作成します。

    $ oc create namespace knative-serving

4.2.2. Knative Serving のインストール

前提条件

  • クラスター管理者のアクセスを持つ Azure Red Hat OpenShift アカウント
  • OpenShift Serverless Operator がインストールされていること。
  • knative-serving namespace が作成されていること。

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

手順

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

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

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

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

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

      フォームが完了したら、Create をクリックします。

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

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

      YAML の変更が完了したら、Create をクリックします。

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

    Installed Operators ページ

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

検証手順

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

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

    条件
    注記

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

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

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

手順

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

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
        name: knative-serving
        namespace: knative-serving
  3. serving.yaml ファイルを適用します。

    $ oc apply -f serving.yaml

検証手順

  1. インストールが完了したことを確認するには、以下のコマンドを実行します。

    $ oc get knativeserving.operator.knative.dev/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

    出力は以下のようになります。

    DependenciesInstalled=True
    DeploymentsAvailable=True
    InstallSucceeded=True
    Ready=True
    注記

    Knative Serving リソースが作成されるまでに数分の時間がかかる場合があります。

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

    $ oc get pods -n knative-serving

    出力は以下のようになります。

    NAME                               READY   STATUS    RESTARTS   AGE
    activator-5c596cf8d6-5l86c         1/1     Running   0          9m37s
    activator-5c596cf8d6-gkn5k         1/1     Running   0          9m22s
    autoscaler-5854f586f6-gj597        1/1     Running   0          9m36s
    autoscaler-hpa-78665569b8-qmlmn    1/1     Running   0          9m26s
    autoscaler-hpa-78665569b8-tqwvw    1/1     Running   0          9m26s
    controller-7fd5655f49-9gxz5        1/1     Running   0          9m32s
    controller-7fd5655f49-pncv5        1/1     Running   0          9m14s
    kn-cli-downloads-8c65d4cbf-mt4t7   1/1     Running   0          9m42s
    webhook-5c7d878c7c-n267j           1/1     Running   0          9m35s

4.2.3. 次のステップ

  • OpenShift Serverless のクラウドイベント機能については、Knative Eventing コンポーネントをインストールできます。Knative Eventing のインストールについてのドキュメントを参照してください。
  • Knative CLI をインストールして、Knative Serving で kn コマンドを使用します。例: kn service コマンドKnative CLI (kn) のインストール についてのドキュメントを参照してください。

4.3. Knative Eventing のインストール

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

4.3.1. knative-eventing namespace の作成

knative-eventing namespace の作成時に、 knative-eventing プロジェクトも作成されます。

重要

Knative Serving をインストールする前に、この手順を実行する必要があります。

Knative Eventing のインストール時に作成された KnativeEventing オブジェクトが knative-eventing namespace で作成されていない場合、これは無視されます。

前提条件

  • クラスター管理者のアクセスを持つ Azure Red Hat OpenShift アカウント
  • OpenShift Serverless Operator がインストールされていること。

4.3.1.1. Web コンソールを使用した knative-eventing namespace の作成

手順

  1. Azure Red Hat OpenShift Web コンソールで、 AdministrationNamespaces に移動します。
  2. Create Namespace をクリックします。

    Namespaces page
  3. プロジェクトの Name として knative-eventing を入力します。他のフィールドはオプションです。

    `knative-eventing` namespace の作成
  4. Create をクリックします。

4.3.1.2. CLI を使用した knative-eventing namespace の作成

手順

  1. 以下を入力して knative-eventing namespace を作成します。

    $ oc create namespace knative-eventing

4.3.2. Knative Eventing のインストール

前提条件

  • クラスター管理者のアクセスを持つ Azure Red Hat OpenShift アカウント
  • OpenShift Serverless Operator がインストールされていること。
  • knative-eventing namespace が作成されていること。

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

手順

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

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

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

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

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

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

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

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

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

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

    Installed Operators ページ

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

検証手順

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

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

    条件
    注記

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

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

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

手順

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

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
        name: knative-eventing
        namespace: knative-eventing
  3. オプション。Knative Eventing デプロイメントについて実装する必要のある変更を YAML に加えます。
  4. 以下を入力して eventing.yaml ファイルを適用します。

    $ oc apply -f eventing.yaml

検証手順

  1. インストールが完了したことを確認するには、以下を入力します。

    $ oc get knativeeventing.operator.knative.dev/knative-eventing \
      -n knative-eventing \
      --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

    出力は以下のようになります。

    InstallSucceeded=True
    Ready=True
    注記

    Knative Eventing リソースが作成されるまでに数秒の時間がかかる場合があります。

  2. 条件のステータスが Unknown または False である場合は、しばらく待ってから、リソースが作成されたことを再度確認します。
  3. 以下のコマンドを実行して Knative Eventing リソースが作成されていることを確認します。

    $ oc get pods -n knative-eventing

    出力は以下のようになります。

    NAME                                   READY   STATUS    RESTARTS   AGE
    broker-controller-58765d9d49-g9zp6     1/1     Running   0          7m21s
    eventing-controller-65fdd66b54-jw7bh   1/1     Running   0          7m31s
    eventing-webhook-57fd74b5bd-kvhlz      1/1     Running   0          7m31s
    imc-controller-5b75d458fc-ptvm2        1/1     Running   0          7m19s
    imc-dispatcher-64f6d5fccb-kkc4c        1/1     Running   0          7m18s

4.3.3. 次のステップ

  • OpenShift Serverless のサービスおよび提供側の機能については、Knative Serving コンポーネントをインストールできます。Knative Serving のインストールについてのドキュメントを参照してください。
  • Knative CLI をインストールして、Knative Eventing で kn コマンドを使用します。例: kn source コマンドKnative CLI (kn) のインストール についてのドキュメントを参照してください。

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

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

重要

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

4.4.1. Knative サービス URL 形式の更新

以前のバージョンの OpenShift Serverless から 1.7.0 にアップグレードする場合、HTTPS のサポートではルートの形式への変更が必要です。OpenShift Serverless 1.6.0 以前のバージョンで作成された Knative サービスには、以前の形式の URL で到達できなくなりました。OpenShift Serverless のアップグレード後に、各サービスの新規 URL を取得する必要があります。

Knative サービス URL の取得に関する詳細は、サーバーレスアプリケーションとの対話についてのドキュメントを参照してください。

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

OpenShift Serverless バージョン 1.6.0 では、利用可能な唯一の Subscription Update Channel は preview-4.3 でした。1.6.0 から最新バージョンにアップグレードするには、チャネルを 4.3 に更新する必要があります。

OpenShift Serverless バージョン 1.5.0 以前からバージョン 1.7.0 にアップグレードする場合は、以下の手順を実行する必要があります。

  • techpreview チャネルを選択して、OpenShift Serverless バージョン 1.5.0 にアップグレードします。
  • 1.5.0 にアップグレードしたら、preview-4.3 チャネルを選択して 1.6.0 にアップグレードします。
  • 最後に、1.6.0 にアップグレードしたら、4.3 チャネルを選択して最新バージョンにアップグレードします。
重要

各チャネルの変更後に、knative-serving namespace の Pod がアップグレードされるのを待機してから、チャネルを再度変更します。

前提条件

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

    注記

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

  • Azure Red Hat OpenShift Web コンソールにログインしている。

手順

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

検証手順

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

  1. 以下のコマンドを実行して Pod のステータスを確認します。

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

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

  2. 以下のコマンドを実行して、KnativeServing CR のバージョンを確認します。

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

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

4.4.3. API グループの更新

OpenShift Serverless 1.4.0 以降のバージョンで、KnativeServing オブジェクトの API グループは serving.knative.dev から operator.knative.dev に変更されました。古い API グループに依存するスクリプトまたはアプリケーションのいずれかを調整して、新規 API グループを使用する必要があります。

手順

  1. 古い API グループに依存するスクリプトまたはアプリケーションを更新して、新規 API グループを使用します。
  2. 新規 API グループへの参照を更新した後に、古いカスタムリソース (CR) バージョンを削除し、代わりに新たにデプロイされた KnativeServing CR を使用する必要があります。

    ダウンタイムなしにこれを安全に行うには、以下のコマンドを実行して新たにデプロイされた KnativeServing CR から所有者の参照を削除します。

     $ oc edit knativeserving.operator.knative.dev knative-serving -n knative-serving
  3. 所有者の参照を削除した後には、古い CR バージョンを安全に削除し、新規 CR の使用を開始できます。
  4. この API グループへの変更により、oc get knativeserving などの完全修飾 API グループなどがないコマンドの信頼性は低くなり、常に正常に機能する状態を保てなくなります。

    OpenShift Serverless 1.6.0 へのアップグレード後に、古いカスタムリソース定義 (CRD) を削除してこの問題を修正する必要があります。

    以下のコマンドを実行して古い CRD を削除できます。

    $ oc delete crd knativeservings.serving.knative.dev
重要

CR の以前のバージョンが存在する場合、新規 CR への変更は OpenShift Serverless Operator によって上書きされます。古い CR は引き続きアクティブな状態ですが、その CR に対してすべての変更を加える必要があります。

4.5. Knative CLI (kn) のインストール

注記

kn には、独自のログインメカニズムは含まれません。クラスターにログインするには、oc CLI をインストールし、oc ログインを使用する必要があります。

oc CLI のインストールオプションは、お使いのオペレーティングシステムによって異なります。

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

4.5.1. Azure Red Hat OpenShift Web コンソールを使用した kn CLI のインストール

OpenShift Serverless Operator がインストールされると、Azure Red Hat OpenShift Web コンソールの Command Line Tools ページから Linux、macOS および Windows の kn CLI をダウンロードするためのリンクが表示されます。

Command Line Tools ページには、 question circle アイコンをクリックしてアクセスできます。 このアイコンは Web コンソールの右上隅にあります。次に、ドロップダウンメニューの Command Line Tools を選択します。

手順

  1. Command Line Tools ページから kn CLI をダウンロードします。
  2. アーカイブを展開します。

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

    $ echo $PATH
    注記

    RHEL または Fedora を使用しない場合は、libc がライブラリーパスのディレクトリーにインストールされていることを確認してください。libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

    $ kn: No such file or directory

4.5.2. RPM を使用した Linux 用の kn CLI のインストール

Red Hat Enterprise Linux (RHEL) の場合、Red Hat アカウントに有効な Azure Red Hat OpenShift サブスクリプションがある場合は、kn を RPM としてインストールできます。

手順

  • 以下のコマンドを使用して、knをインストールします。
# subscription-manager register
# subscription-manager refresh
# subscription-manager attach --pool=<pool_id> 1
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
# yum install openshift-serverless-clients
1
有効な Azure Red Hat OpenShift サブスクリプションのプール ID

4.5.3. Linux の kn CLI のインストール

Linux ディストリビューションの場合、CLI を tar.gz アーカイブとして直接ダウンロードできます。

手順

  1. CLI をダウンロードします。
  2. アーカイブを展開します。

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

    $ echo $PATH
    注記

    RHEL または Fedora を使用しない場合は、libc がライブラリーパスのディレクトリーにインストールされていることを確認してください。libc が利用できない場合は、CLI コマンドの実行時に以下のエラーが表示される場合があります。

    $ kn: No such file or directory

4.5.4. macOS の kn CLI のインストール

macOS のknは、tar.gzアーカイブとして提供されます。

手順

  1. CLI をダウンロードします。
  2. アーカイブを展開および解凍します。
  3. kn バイナリーをパスにあるディレクトリーに移動します。
  4. パスを確認するには、ターミナルウィンドウを開き、以下を実行します。

    $ echo $PATH

4.5.5. Windows の kn CLI のインストール

Windows の CLI は zip アーカイブとして提供されます。

手順

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

    C:\> path

4.6. OpenShift Serverless の削除

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

注記

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

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

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

手順

  1. Knative Serving を削除するには、以下のコマンドを実行します。

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

    $ oc delete namespace knative-serving

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

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

手順

  1. Knative Eventing を削除するには、以下のコマンドを実行します。

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

    $ oc delete namespace knative-eventing

4.6.3. OpenShift Serverless Operator の削除

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

4.6.4. OpenShift Serverless CRD の削除

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

重要

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

前提条件

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

手順

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

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

第5章 サーバーレスアプリケーションの作成および管理

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

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

Knative サービス YAML の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go 1
  namespace: default 2
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go 3
          env:
            - name: TARGET 4
              value: "Go Sample v1"

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

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

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

5.2. Azure Red Hat OpenShift Web コンソールでのサーバーレスアプリケーションの作成

Azure Red Hat OpenShift Web コンソールの Developer または Administrator パースペクティブのいずれかを使用してサーバーレスアプリケーションを作成できます。

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

前提条件

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

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

手順

  1. ServerlessServices ページに移動します。

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

    テキストエディター
  4. Create をクリックします。

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

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

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

前提条件

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

手順

  1. 以下のコマンドを入力して Knative サービスを作成します。

    $ kn service create <SERVICE-NAME> --image <IMAGE> --env <KEY=VALUE>
    $ kn service create hello --image gcr.io/knative-samples/helloworld-go --env TARGET=Knative
    
    Creating service 'hello' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "hello" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'hello' created with latest revision 'hello-bxshg-1' and URL:
    http://hello-default.apps-crc.testing

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

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

以下のサンプルをコピーして YAML ファイルを作成できます。

Knative サービス YAML の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "Go Sample v1"

この例では、YAML ファイルの名前は hello-service.yaml です。

手順

  1. hello-service.yaml ファイルが含まれているディレクトリーに移動します。
  2. YAML ファイルを適用してアプリケーションをデプロイします。

    $ oc apply --filename hello-service.yaml

サービスが作成され、アプリケーションがデプロイされた後に、Knative はこのバージョンのアプリケーションのイミュータブルなリビジョンを新規に作成します。

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

第6章 OpenShift Serverless での高可用性

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

OpenShift Serverless のアクティブ/パッシブ HA は、リーダーの選択によって利用できます。これは、Knative Serving コントロールプレーンのインストール後にデフォルトで有効になります。

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

6.1. 高可用性 OpenShift Serverless コンポーネントの設定

以下に、デフォルトで 高可用性 (HA) として設定される OpenShift Serverless のコンポーネントや、HA 設定を変更する方法について説明します。

HA 機能は、autoscaler-hpacontrolleractivatorkourier-control、および kourier-gateway コンポーネントについてデフォルトで OpenShift Serverless で利用できます。これらのコンポーネントは、デフォルトで 2 つのレプリカで設定されます。

6.1.1. 高可用性の無効化

KnativeServing.spec.highAvailability フィールドの設定を変更して、Knative Serving コンポーネントの HA を無効にすることができます。

重要

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

前提条件

  • クラスター管理者のアクセスを持つ Azure Red Hat OpenShift アカウント
  • OpenShift Serverless Operator および Knative Serving がインストールされていること。

手順

  1. Azure Red Hat OpenShift Web コンソールで、CatalogOperatorHubInstalled Operators ページに移動します。
  2. OpenShift Serverless Operator を選択します。
  3. OpenShift Serverless Operator の Provided API 一覧で Knative Serving をクリックし、Knative Serving タブに移動します。

    Installed Operators ページ
  4. Knative Serving タブの knative-serving をクリックします。
  5. knative-serving ページで YAML をクリックします。

    Knative Serving YAML
  6. YAML の spec セクションで、high-availability.replicas フィールドを 1 に更新します。

      high-availability:
        replicas: 1

第7章 Knative CLI

7.1. Knative CLI (kn) の使用開始

Knative CLI (kn) は、oc または kubectl ツールの機能を拡張し、Azure Red Hat OpenShift での Knative コンポーネントとの対話を可能にします。kn は、開発者が YAML ファイルを直接編集しなくてもアプリケーションをデプロイし、管理できるようにします。

7.1.1. kn を使用した基本ワークフロー

この基本的なワークフローを使用して、サービス上で作成 (create)、読み取り (read)、更新 (update)、削除 (delete) (CRUD) 操作を行います。以下の例では、環境変数 TARGET を読み取る単純な Hello World サービスをデプロイし、その出力を印刷します。

手順

  1. イメージからサービスを デフォルト namespace に作成します。

    $ kn service create hello --image gcr.io/knative-samples/helloworld-go --env TARGET=Knative
    Creating service 'hello' in namespace 'default':
    
      0.085s The Route is still working to reflect the latest desired specification.
      0.101s Configuration "hello" is waiting for a Revision to become ready.
     11.590s ...
     11.650s Ingress has not yet been reconciled.
     11.726s Ready to serve.
    
    Service 'hello' created with latest revision 'hello-gsdks-1' and URL:
    http://hello.default.apps-crc.testing
  2. サービスを一覧表示します。

    $ kn service list
    NAME    URL                                     LATEST          AGE     CONDITIONS   READY   REASON
    hello   http://hello.default.apps-crc.testing   hello-gsdks-1   8m35s   3 OK / 3     True
  3. curl サービスエンドポイントコマンドを使用して、サービスが機能しているかどうかを確認します。

    $ curl http://hello.default.apps-crc.testing
    
    Hello Knative!
  4. サービスを更新します。

    $ kn service update hello --env TARGET=Kn
    Updating Service 'hello' in namespace 'default':
    
     10.136s Traffic is not yet migrated to the latest revision.
     10.175s Ingress has not yet been reconciled.
     10.348s Ready to serve.
    
    Service 'hello' updated with latest revision 'hello-dghll-2' and URL:
    http://hello.default.apps-crc.testing

    サービスの環境変数 TARGETKn に設定されます。

  5. サービスを記述します。

    $ kn service describe hello
    Name:       hello
    Namespace:  default
    Age:        13m
    URL:        http://hello.default.apps-crc.testing
    Address:    http://hello.default.svc.cluster.local
    
    Revisions:
      100%  @latest (hello-dghll-2) [2] (1m)
            Image:  gcr.io/knative-samples/helloworld-go (pinned to 5ea96b)
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   1m
      ++ ConfigurationsReady     1m
      ++ RoutesReady             1m
  6. サービスを削除します。

    $ kn service delete hello
    Service 'hello' successfully deleted in namespace 'default'.

    次に、hello サービスに対して list を試行することにより、このサービスが削除されていることを確認できます。

    $ kn service list hello
    No services found.

7.1.2. kn を使用した自動スケーリングのワークフロー

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

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

フラグ説明

--concurrency-limit int

単一レプリカによって処理される同時要求のハード制限。

--concurrency-target int

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

--max-scale int

レプリカの最大数。

--min-scale int

レプリカの最小数。

7.1.3. kn を使用したトラフィック分割

kn は、Knative サービス上でルート指定されたトラフィックを取得するリビジョンを制御するのに役立ちます。

Knative サービスは、トラフィックのマッピングを許可します。これは、サービスのリビジョンのトラフィックの割り当てられた部分へのマッピングです。これは特定のリビジョンに固有の URL を作成するオプションを提供し、トラフィックを最新リビジョンに割り当てる機能を持ちます。

サービスの設定が更新されるたびに、サービスルートがすべてのトラフィックを準備状態にある最新リビジョンにポイントする状態で、新規リビジョンが作成されます。

この動作は、トラフィックの一部を取得するリビジョンを定義して変更することができます。

手順

  • kn service update コマンドを --traffic フラグと共に使用して、トラフィックを更新します。
注記

--traffic RevisionName=Percent は以下の構文を使用します。

  • --traffic フラグには、等号 (=) で区切られた 2 つの値が必要です。
  • RevisionName 文字列はリビジョンの名前を参照します。
  • Percent 整数はトラフィックのリビジョンに割り当てられた部分を示します。
  • RevisionName の識別子 @latest を使用して、サービスの準備状態にある最新のリビジョンを参照します。この識別子は --traffic フラグと共に 1 回のみ使用できます。
  • service update コマンドがトラフィックフラグと共にサービスの設定値を更新する場合、 @latest 参照は更新が適用される作成済みリビジョンをポイントします。
  • --traffic フラグは複数回指定でき、すべてのフラグの Percent 値の合計が 100 になる場合にのみ有効です。
注記

たとえば、すべてのトラフィックを配置する前に 10% のトラフィックを新規リビジョンにルート指定するには、以下のコマンドを使用します。

$ kn service update svc --traffic @latest=10 --traffic svc-vwxyz=90

7.1.3.1. タグリビジョンの割り当て

サービスのトラフィックブロック内のタグは、参照されるリビジョンをポイントするカスタム URL を作成します。ユーザーは、http(s)://TAG-SERVICE.DOMAIN 形式を使用して、カスタム URL を作成するサービスの利用可能なリビジョンの固有タグを定義できます。

指定されたタグは、サービスのトラフィックブロックに固有のものである必要があります。knkn service update コマンドの一環として、サービスのリビジョンのカスタムタグの割り当ておよび割り当て解除に対応します。

注記

タグを特定のリビジョンに割り当てた場合、ユーザーは、--traffic フラグ内で --traffic Tag=Percent として示されるタグでこのリビジョンを参照できます。

手順

  • 以下のコマンドを使用します。

    $ kn service update svc --tag @latest=candidate --tag svc-vwxyz=current
注記

--tag RevisionName=Tag は以下の構文を使用します。

  • --tag フラグには、= で区切られる 2 つの値が必要です。
  • RevisionName 文字列は Revision の名前を参照します。
  • Tag 文字列は、このリビジョンに指定されるカスタムタグを示します。
  • RevisionName の識別子 @latest を使用して、サービスの準備状態にある最新のリビジョンを参照します。この識別子は --tag フラグで 1 回のみ使用できます。
  • service update コマンドがサービスの設定値を (タグフラグと共に) 更新している場合、@latest 参照は更新の適用後に作成されるリビジョンをポイントします。
  • --tag フラグは複数回指定できます。
  • --tag フラグは、同じリビジョンに複数の異なるタグを割り当てる場合があります。

7.1.3.2. タグリビジョンの割り当て解除

トラフィックブロックのリビジョンに割り当てられたタグは、割り当て解除できます。タグの割り当てを解除すると、カスタム URL が削除されます。

注記

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

手順

  • ユーザーは、kn service update コマンドを使用してリビジョンのタグの割り当てを解除できます。

    $ kn service update svc --untag candidate
注記

--untag Tag は以下の構文を使用します。

  • --untag フラグには 1 つの値が必要です。
  • tag 文字列は、割り当てを解除する必要のあるサービスのトラフィックブロックの固有のタグを示します。これにより、それぞれのカスタム URL も削除されます。
  • --untag フラグは複数回指定できます。

7.1.3.3. トラフィックフラグ操作の優先順位

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

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

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

7.1.3.4. トラフィック分割フラグ

knkn service update コマンドの一環として、サービスのトラフィックブロックでのトラフィック操作に対応します。

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

フラグ操作繰り返し

--traffic

RevisionName=Percent

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

Yes

--traffic

Tag=Percent

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

Yes

--traffic

@latest=Percent

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

No

--tag

RevisionName=Tag

TagRevisionName に指定します。

Yes

--tag

@ latest = Tag

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

No

--untag

Tag

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

Yes

第8章 Knative Serving

8.1. Knative Serving の機能

Azure Red Hat OpenShift 上の Knative Serving は、サーバーレスアプリケーションのデプロイおよび管理をサポートするために Kubernetes および Kourier をベースにビルドされます。

これは、Azure Red Hat OpenShift クラスター上のサーバーレスワークロードの動作を定義し、制御するために使用される Kubernetes カスタムリソース定義 (CRD) のセットを作成します。

これらの CRD は、以下のような複雑なユースケースに対応するビルディングブロックです。

  • サーバーレスコンテナーの迅速なデプロイ
  • Pod の自動スケーリング
  • デプロイされたコードおよび設定のポイントインタイムスナップショットの表示

8.1.1. Knative Serving リソース

このセクションで説明するリソースは、Knative Serving が正しく設定され、実行されるために必要です。

Knative サービスリソース
service.serving.knative.dev リソースは、クラスター上のサーバーレスワークロードのライフサイクル全体を自動的に管理します。これは、サービスの各アップデートについてのルート、設定、および新規リビジョンがアプリケーションに設定されるように他のオブジェクトの作成を制御します。サービスは、トラフィックを最新バージョンまたは固定されたバージョンに常にルーティングするように定義できます。
Knative ルートリソース
route.serving.knative.dev リソースは、ネットワークのエンドポイントを、1 つ以上の Knative リビジョンにマップします。部分的なトラフィックや名前付きルートなどのトラフィックを複数の方法で管理することができます。
Knative 設定リソース
configuration.serving.knative.dev リソースは、デプロイメントの必要な状態を維持します。設定を変更すると、新規リビジョンが作成されます。
Knative リビジョンリソース
revision.serving.knative.dev リソースは、ワークロードに対して加えられるそれぞれの変更についてのコードおよび設定の特定の時点におけるスナップショットです。リビジョンはイミュータブル (変更不可) オブジェクトであり、必要な期間保持することができます。クラスター管理者は、revision.serving.knative.dev リソースを変更して、Azure Red Hat OpenShift クラスターでの Pod の自動スケーリングを有効にできます。

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

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

Knative サービス YAML の例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go 1
  namespace: default 2
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go 3
          env:
            - name: TARGET 4
              value: "Go Sample v1"

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

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

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

8.1.3. 次のステップ

8.2. サーバーレスアプリケーションとの対話

このセクションでは、サーバーレスアプリケーションを正常に作成した後に実行できる各種タスクについての情報を提供します。

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

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

注記

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

手順

  1. 以下を入力してアプリケーション URL を検索します。

    $ oc get ksvc helloworld-go

    出力例

    NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
    helloworld-go   http://helloworld-go.default.example.com   helloworld-go-4wsd2   helloworld-go-4wsd2   True

  2. クラスターに対して要求を実行し、出力を確認します。

    HTTP 要求の例

    $ curl http://helloworld-go.default.example.com
    Hello World: Go Sample v1!

    HTTPS 要求の例

    $ curl https://helloworld-go.default.example.com
    Hello World: Go Sample v1!

  3. オプション。証明書チェーンで自己署名証明書に関連するエラーが発生した場合は、curl コマンドに --insecure フラグを追加して、エラーを無視できます。

    重要

    自己署名証明書は、実稼働デプロイメントでは使用しないでください。この方法は、テスト目的にのみ使用されます。

    $ curl https://helloworld-go.default.example.com --insecure
    Hello World: Go Sample v1!

  4. オプション。Azure Red Hat OpenShift クラスターが認証局 (CA) で署名されているが、システムにグローバルに設定されていない証明書で設定されている場合、curl コマンドでこれを指定できます。証明書へのパスは、--cacert フラグを使用して curl コマンドに渡すことができます。

    $ curl https://helloworld-go.default.example.com --cacert <file>
    Hello World: Go Sample v1!

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

Azure Red Hat OpenShift ルートは HTTP2 をサポートしません。gRPC も HTTP2 によるトランスポートが使用されるため、サポートされません。アプリケーションでこれらのプロトコルを使用する場合は、Ingress ゲートウェイを使用してアプリケーションを直接呼び出す必要があります。これを実行するには、Ingress ゲートウェイのパブリックアドレスとアプリケーションの特定のホストを見つける必要があります。

手順

  1. アプリケーションホストを検索します。「サーバーレスアプリケーションのデプロイメントの確認」の説明を参照してください。
  2. Ingress ゲートウェイのパブリックアドレスは、以下のコマンドを使用して判別できます。

    $ oc -n knative-serving-ingress get svc kourier

    出力は以下のようになります。

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
    kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

    パブリックアドレスは EXTERNAL-IP フィールドで表示され、この場合は以下のようになります。

    a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
  3. HTTP 要求のホストヘッダーを手動でアプリケーションのホストに手動で設定しますが、Ingress ゲートウェイのパブリックアドレスに対して要求自体をダイレクトします。

    以下は、「サーバーレスアプリケーションのデプロイメントの確認」の手順で記載された情報を使用した例です。

    $ curl -H "Host: helloworld-go.default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
    Hello Go Sample v1!

    Ingress ゲートウェイに対して要求を直接ダイレクトする間に、権限をアプリケーションのホストに設定して gRPC 要求を行うこともできます。

    以下は、Golang gRPC クライアントの内容の例です。

    注記

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

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

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

OpenShift Serverless は、Knative Serving 自動スケーリングシステムを Azure Red Hat OpenShift クラスターで有効にすることで、アクティブでない Pod をゼロにスケーリングする機能など、Pod の自動スケーリングの各種機能を提供します。

Knative Serving の自動スケーリングを有効にするには、リビジョンテンプレートで同時実行 (concurrency) およびスケール境界 (scale bound) を設定する必要があります。

注記

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

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

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

以下は、リビジョンテンプレートで使用される target のサンプルです。

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

以下は、リビジョンテンプレートで使用される containerConcurrency のサンプルです。

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

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

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

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

注記

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

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

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

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

autoscaling.knative.dev/target: 50

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

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

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

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

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

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

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

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

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

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

注記

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

8.4. OpenShift Serverless を使用したクラスターロギング

8.4.1. クラスターロギング

クラスターロギングは、instance という名前のクラスターロギングのカスタムリソース (CR) を変更することで設定できます。CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全なクラスターロギングデプロイメントを定義します。Cluster Logging Operator は ClusterLogging カスタムリソースを監視し、ロギングデプロイメントを適宜調整します。

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

8.4.2. クラスターロギングのデプロイおよび設定について

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

以下のインストール方法には、サンプルのクラスターロギングのカスタムリソース (CR) が含まれます。これを使用して、クラスターロギングインスタンスを作成し、クラスターロギングのデプロイメントを設定することができます。

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

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

8.4.2.1. クラスターロギングの設定およびチューニング

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

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

メモリーおよび CPU
resources ブロックを有効なメモリーおよび CPU 値で変更することにより、各コンポーネントの CPU およびメモリーの両方の制限を調整することができます。
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu: 1
          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
  curation:
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      type: "curator"
Elasticsearch ストレージ
storageClass name および size パラメーターを使用し、Elasticsearch クラスターの永続ストレージのクラスおよびサイズを設定できます。Cluster Logging Operator は、これらのパラメーターに基づいて、Elasticsearch クラスターの各データノードについて PersistentVolumeClaim を作成します。
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

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

注記

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

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

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

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

8.4.2.2. 変更されたクラスターロギングカスタムリソースのサンプル

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

変更されたクラスターロギングカスタムリソースのサンプル

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 2
      resources:
        limits:
          memory: 2Gi
        requests:
          cpu: 200m
          memory: 2Gi
      storage: {}
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/5 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

8.4.3. クラスターロギングの使用による Knative Serving コンポーネントのログの検索

手順

  1. Elasticsearch の仮想化ツール Kibana UI を開くには、 以下のコマンドを使用して 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 はデフォルトで構造化ロギングを使用します。クラスターロギング Fluentd 設定をカスタマイズしてこれらのログの解析を有効にできます。これにより、ログの検索がより容易になり、ログレベルでのフィルターにより問題を迅速に特定できるようになります。

8.4.4. クラスターロギングを使用した Knative Serving でデプロイされたサービスのログの検索

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

手順

  1. 以下のコマンドを使用して、Kibana の URL を見つけます。

    $ oc -n cluster-logging get route kibana`
  2. URL をブラウザーに入力し、Kibana UI を開きます。
  3. インデックスが .all に設定されていることを確認します。インデックスが .all に設定されていない場合、OpenShift システムログのみが一覧表示されます。
  4. サービスがデプロイされている Kubernetes 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 ベースの構造化ロギングを使用することで、実稼働環境でのこれらのログの迅速なフィルターを実行できます。

8.5. リビジョン間でのトラフィックの分割

8.5.1. Developer パースペクティブを使用したリビジョン間のトラフィックの分離

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

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

手順

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

  1. 四角形のマークが付けられたサーバーレスリソースサービスをクリックし、その概要をサイドパネルに表示します。
  2. Resources タブをクリックして、サービスの Revisions および Routes の一覧を表示します。

    Serverless アプリケーション
  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 つのノードを表示します。

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

第9章 Knative Eventing

9.1. Knative Eventing のしくみ

Azure Red Hat OpenShift の Knative Eventing を使用すると、開発者はサーバーレスアプリケーションのイベント駆動型アーキテクチャーを使用して、システムのコンポーネントがどのように通信するかについてより簡単に宣言できます。

イベント駆動型のアーキテクチャーは、イベントプロデューサーとイベントコンシューマー間の関係を切り離すという概念に基づいています。

イベント駆動型のアーキテクチャーについての詳細は、「 イベント駆動型アーキテクチャとは」を参照してください。

9.1.1. Knative Eventing ワークフロー

Knative Eventing ワークフローでは、event producers はシステムの状態への変更についての情報をイベントソースに送信します。イベントプロデューサーの例には、Kafka クラスターまたは Kubernetes API サーバーが含まれます。

イベントソース は、イベントプロデューサーと、それらのイベントを受信する シンク (またはコンシューマー) 間のリンクであるリソースオブジェクトです。現時点で、OpenShift Serverless は以下のイベントソースタイプをサポートします。

ApiServerSource
シンクを Kubernetes API サーバーに接続します。
PingSource
一定のペイロードを使用して ping イベントを定期的に送信します。これはタイマーとして使用できます。

SinkBinding もサポートされます。これにより、シンクを使用して DeploymentJob、または StatefulSet などのコア Kubernetes リソースを接続できます。

シンクの例として、Knative サービスおよびチャネルがあります。イベントは以下に送信することもできます。

  • ブローカー: シンクに送信される前に トリガー を使用したフィルターを実行できます。ブローカーとトリガーを一緒に使用すると、イベントプロデューサーおよびイベントコンシューマーからイベントルーティングの詳細を非表示にするイベント配信メカニズムが有効になります。
  • チャネル: Knative サービスは特定タイプのイベントを受信するために「サブスクライブ」できます。

9.1.2. 追加リソース

9.2. kn CLI を使用したイベントソースおよびイベントソースタイプの一覧表示

kn CLI を使用して、Knative Eventing で使用するために利用できるイベントソースまたはイベントソースのタイプを一覧表示し、管理できます。

現在、kn は以下のイベントソースタイプの管理をサポートします。

ApiServerSource
シンクを Kubernetes API サーバーに接続します。
PingSource
一定のペイロードを使用して ping イベントを定期的に送信します。これはタイマーとして使用できます。

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

以下のコマンドを使用して、ターミナルに利用可能なイベントソースタイプを一覧表示できます。

$ 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

利用可能なイベントソースタイプを YAML 形式で一覧表示することもできます。

$ kn source list-types -o yaml

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

以下のコマンドを使用して、利用可能なイベントソースを一覧表示できます。

$ kn source list

以下は出力例です。

NAME   TYPE              RESOURCE                               SINK         READY
a1     ApiServerSource   apiserversources.sources.knative.dev   svc:eshow2   True
b1     SinkBinding       sinkbindings.sources.knative.dev       svc:eshow3   False
p1     PingSource        pingsources.sources.knative.dev        svc:eshow1   True

9.2.2.1. 特定タイプのイベントソースのみの一覧表示

--type フラグを使用して、特定タイプのイベントソースのみを一覧表示できます。たとえば、タイプ PingSource のすべてのイベントソースを一覧表示するには、以下を実行します。

$ kn source list --type PingSource

以下は出力例です。

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

次のステップ

9.3. ApiServerSource の使用

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

注記

以下の手順では、どちらの場合も YAML ファイルを作成する必要があります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

9.3.1. Knative CLI (kn) での ApiServerSource の使用

以下に、kn コマンドを使用して ApiServerSource を作成し、管理し、削除するために必要な手順を説明します。

前提条件

  • Knative Serving および Eventing のインストールが必要です。
  • ApiServerSource がインストールされるのと同じ namespace に default ブローカーを作成している必要があります。
  • kn CLI がインストールされている必要があります。

手順

  1. ApiServerSource のサービスアカウント、ロール、およびロールバインディングを作成します。

    authentication.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 を、ApiServerSource のインストールに選択した namespace に変更します。
    注記

    適切なパーミッションを持つ既存のサービスアカウントを再利用する必要がある場合、そのサービスアカウントの authentication.yaml を変更する必要があります。

    以下のコマンドを入力して、サービスアカウント、ロールバインディング、およびクラスターバインディングを作成します。

    $ oc apply --filename authentication.yaml
  2. 以下のコマンドを入力して ApiServerSource イベントソースを作成します。

    $ kn source apiserver create testevents --sink broker:default --resource "event:v1" --service-account events-sa --mode Resource
  3. ApiServerSource が正しく設定されていることを確認するには、以下のコマンドを入力して、受信メッセージをログにダンプする Knative サービスを作成します。

    $ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2
  4. 以下の kn コマンドを入力して、default ブローカーからトリガーを作成し、イベントを直前の手順で作成したサービスにフィルターします。

    $ kn trigger create event-display-trigger --sink svc:event-display
  5. デフォルト namespace で Pod を起動してイベントを作成します。これは、以下のコマンドを入力して実行できます。

    $ oc create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
  6. 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ kn source apiserver describe testevents

    出力は以下のようになります。

    Name:                testevents
    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/v1alpha1)
    Resources:
      Kind:        event (v1)
      Controller:  false
    Conditions:
      OK TYPE                     AGE REASON
      ++ Ready                     3m
      ++ Deployed                  3m
      ++ SinkProvided              3m
      ++ SufficientPermissions     3m
      ++ EventTypesProvided        3m

検証手順

メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative Eventing システムに送信されていることを確認できます。

以下のコマンドを入力して、メッセージダンパー機能ログを表示できます。

$ 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.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",
    ...
  }

9.3.1.1. ApiServerSource の削除

以下の kn コマンドおよび oc コマンドを入力して、本書で作成した ApiServerSource、トリガー、サービス、サービスアカウント、クラスターロール、およびクラスターバインディングを削除できます。

$ kn trigger delete event-display-trigger
$ kn service delete event-display
$ kn source apiserver delete testevents
$ oc delete -f authentication.yaml

9.3.2. YAML メソッドでの ApiServerSource の使用

以下に、YAML ファイルを使用して ApiServerSource を作成し、管理し、削除するために必要な手順を説明します。

前提条件

  • Knative Serving および Eventing のインストールが必要です。
  • default ブローカーは、ApiServerSource YAML ファイルで定義されるものと同じ namespace に作成している必要があります。

手順

  1. ApiServerSource のサービスアカウント、ロール、およびロールバインディングを作成します。

    authentication.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 を、ApiServerSource のインストールに選択した namespace に変更します。
    注記

    適切なパーミッションを持つ既存のサービスアカウントを再利用する必要がある場合、そのサービスアカウントの authentication.yaml を変更する必要があります。

    authentication.yaml ファイルを作成した後に、以下のコマンドを入力してこれを適用します。

    $ oc apply --filename authentication.yaml
  2. ApiServerSource イベントソースを作成します。

    これは、k8s-events.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/v1beta1
          kind: Broker
          name: default

    k8s-events.yaml ファイルを作成した後に、以下のコマンドを入力してこれを適用します。

    $ oc apply --filename k8s-events.yaml
  3. ApiServerSource が正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。

    以下のサンプル YAML を service.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:v0.13.2

    service.yaml ファイルを作成した後に、以下のコマンドを入力してこれを適用します。

    $ oc apply --filename service.yaml
  4. default ブローカーからトリガーを作成し、イベントを直前の手順で作成したサービスにフィルターします。

    トリガーは、trigger.yaml という名前のファイルを作成し、以下のサンプルコードをこれにコピーして作成できます。

    apiVersion: eventing.knative.dev/v1alpha1
    kind: Trigger
    metadata:
      name: event-display-trigger
      namespace: default
    spec:
      subscriber:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display

    trigger.yaml ファイルを作成した後に、以下のコマンドを入力してこれを適用します。

    $ oc apply --filename trigger.yaml
  5. デフォルト namespace で Pod を起動してイベントを作成します。これは、以下のコマンドを入力して実行できます。

    $ oc create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
  6. 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ 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/v1beta1
          kind: Broker
          name: default

検証手順

メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative Eventing システムに送信されていることを確認できます。

以下のコマンドを入力して、メッセージダンパー機能ログを表示できます。

$ 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.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",
    ...
  }

9.3.2.1. ApiServerSource の削除

以下の oc コマンドを入力して、本書で作成した ApiServerSource、トリガー、サービス、サービスアカウント、クラスターロール、およびクラスターバインディングを削除できます。

$ oc delete --filename trigger.yaml
$ oc delete --filename service.yaml
$ oc delete --filename k8s-events.yaml
$ oc delete --filename authentication.yaml

9.4. PingSource の使用

PingSource は、一定のペイロードを使用して ping イベントをイベントコンシューマーに定期的に送信するために使用されます。

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 サービスを使用しています。

9.4.1. kn CLI での PingSource の使用

以下のセクションでは、kn CLI を使用して基本的な PingSource を作成し、検証し、削除する方法を説明します。

前提条件

  • Knative Serving および Eventing がインストールされている。
  • kn CLI がインストールされている。

手順

  1. PingSource が機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2
  2. 要求する必要のある ping イベントのセットごとに、イベントコンシューマーと同じ namespace に PingSource を作成します。

    $ kn source ping create test-ping-source \
        --schedule "*/2 * * * *" \
        --data '{"message": "Hello world!"}' \
        --sink svc: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 分ごとにメッセージを送信する 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: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
      time: 2020-04-07T16:16:00.000601161Z
      datacontenttype: application/json
    Data,
      {
        "message": "Hello world!"
      }

9.4.1.1. PingSource の削除

以下のコマンドを入力して、PingSource および作成したサービスを削除できます。

$ kn delete pingsources.sources.knative.dev test-ping-source
$ kn delete service.serving.knative.dev event-display

9.4.2. YAML での PingSource の使用

以下のセクションでは、YAML ファイルを使用して基本的な PingSource を作成し、検証し、削除する方法を説明します。

前提条件

  • Knative Serving および Eventing がインストールされている。
注記

以下の手順では、YAML ファイルを作成する必要があります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

手順

  1. PingSource が機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。

    1. サンプル YAML を service.yaml という名前のファイルにコピーします。

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2
    2. サービスを作成します。

      $ oc apply --filename service.yaml
  2. 要求する必要のある ping イベントのセットごとに、PingSource をイベントコンシューマーと同じ namespace に作成します。

    1. サンプル YAML を ping-source.yamlという名前のファイルにコピーします。

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

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

    $ oc get pingsource.sources.knative.dev test-ping-source -oyaml

    出力は以下のようになります。

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

検証手順

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

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

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

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

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

    ログには以下のような行が含まれるはずです。

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

9.4.2.1. PingSource の削除

以下のコマンドを入力して、PingSource および作成したサービスを削除できます。

$ oc delete --filename service.yaml
$ oc delete --filename ping-source.yaml

9.5. SinkBinding の使用

SinkBinding は、イベントプロデューサーまたは イベントソース を Knative サービスやアプリケーションなどのイベントコンシューマーまたは イベントシンク に接続するために使用されます。

注記

以下の手順では、どちらの場合も YAML ファイルを作成する必要があります。

サンプルで使用されたもので YAML ファイルの名前を変更する場合は、必ず対応する CLI コマンドを更新する必要があります。

9.5.1. Knative CLI (kn) による SinkBinding の使用

以下に、kn コマンドを使用して SinkBinding インスタンスを作成し、管理し、削除するために必要な手順を説明します。

前提条件

  • Knative Serving および Eventing がインストールされている。
  • kn CLI がインストールされている。

手順

  1. SinkBinding が正しく設定されていることを確認するには、受信メッセージをダンプする Knative イベント表示サービスまたはイベントシンクを作成します。

    $ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2
  2. イベントをサービスに転送する SinkBinding を作成します。

    $ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink svc:event-display
  3. CronJob を作成します。

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

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:v0.13.2
                    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
    2. heartbeats-cronjob.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply --filename heartbeats-cronjob.yaml
  4. 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ kn source binding describe bind-heartbeat

    出力は以下のようになります。

    Name:         bind-heartbeat
    Namespace:    demo-2
    Annotations:  sources.knative.dev/creator=minikube-user, sources.knative.dev/lastModifier=minikub ...
    Age:          2m
    Subject:
      Resource:   job (batch/v1)
      Selector:
        app:      heartbeat-cron
    Sink:
      Name:       event-display
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE     AGE REASON
      ++ Ready     2m

検証手順

メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative イベントシンクに送信されていることを確認できます。

以下を入力して、メッセージダンパー機能ログを表示できます。

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

ログには以下のような行が含まれるはずです。

☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: dev.knative.eventing.samples.heartbeat
  source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod
  id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596
  time: 2019-10-18T15:23:20.809775386Z
  contenttype: application/json
Extensions,
  beats: true
  heart: yes
  the: 42
Data,
  {
    "id": 1,
    "label": ""
  }

9.5.2. YAML メソッドでの SinkBinding の使用

This guide describes the steps required to create, manage, and delete a SinkBinding instance using YAML files.

前提条件

  • Knative Serving および Eventing がインストールされている。

手順

  1. SinkBinding が正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative イベント表示サービスまたはイベントシンクを作成します。

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

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2
    2. service.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply --filename service.yaml
  2. イベントをサービスに転送する SinkBinding を作成します。

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

      apiVersion: sources.knative.dev/v1alpha1
      kind: SinkBinding
      metadata:
        name: bind-heartbeat
      spec:
        subject:
          apiVersion: batch/v1
          kind: Job 1
          selector:
            matchLabels:
              app: heartbeat-cron
      
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
      1
      この例では、ラベル app: heartbeat-cron を指定したジョブがイベントシンクにバインドされます。
    2. sinkbinding.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply --filename sinkbinding.yaml
  3. CronJob を作成します。

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

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:v0.13.2
                    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
    2. heartbeats-cronjob.yaml ファイルを作成した後に、以下を入力してこれを適用します。

      $ oc apply --filename heartbeats-cronjob.yaml
  4. 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ oc get sinkbindings.sources.knative.dev bind-heartbeat -oyaml

    出力は以下のようになります。

    spec:
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display
          namespace: default
      subject:
        apiVersion: batch/v1
        kind: Job
        namespace: default
        selector:
          matchLabels:
            app: heartbeat-cron

検証手順

メッセージダンパー機能ログを確認して、Kubernetes イベントが Knative イベントシンクに送信されていることを確認できます。

以下を入力して、メッセージダンパー機能ログを表示できます。

$ 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": ""
  }

9.6. トリガーの使用

チャネルまたはブローカーに送信されたすべてのイベントは、デフォルトでそのチャネルまたはブローカーのすべてのサブスクライバーに送信されます。

トリガーを使用すると、チャネルまたはブローカーからイベントをフィルターできるため、サブスクライバーは定義された基準に基づくイベントのサブセットのみを受け取ることができます。

Knative CLI は、トリガーの作成および管理に使用できる kn trigger コマンドのセットを提供します。

前提条件

トリガーを使用する前に、以下が必要になります。

  • Knative Eventing および kn がインストールされている。
  • default ブローカーまたは作成したブローカーのいずれかの利用可能なブローカー。

    default ブローカーは、「Knative Eventing でのブローカーの使用」の説明に従うか、またはトリガーの作成時に --inject-broker フラグを使用して作成できます。このフラグの使用方法については、以下の手順で説明します。

  • Knative サービスなどの利用可能なイベントコンシューマー。

9.6.1. kn を使用したトリガーの作成

手順

トリガーを作成するには、以下のコマンドを入力します。

$ kn trigger create <TRIGGER-NAME> --broker <BROKER-NAME> --filter <KEY=VALUE> --sink <SINK>

トリガーを作成し、またブローカー挿入を使用して default ブローカーを作成するには、以下のコマンドを入力します。

$ kn trigger create <TRIGGER-NAME> --inject-broker --filter <KEY=VALUE> --sink <SINK>

トリガー YAML の例:

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: trigger-example 1
spec:
 broker: default 2
 subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: my-service 3

1
トリガーの名前。
2
イベントのフィルターに使用されるブローカーの名前。ブローカーが指定されていない場合、トリガーは default ブローカーの使用に戻ります。
3
フィルターされたイベントを使用するサービスの名前。

9.6.2. kn を使用したトリガーの一覧表示

kn trigger list コマンドは利用可能なトリガーの一覧を出力します。

手順

  • 利用可能なトリガーの一覧を出力するには、以下のコマンドを入力します。

    $ kn trigger list

    出力例:

    $ kn trigger list
    NAME    BROKER    SINK           AGE   CONDITIONS   READY   REASON
    email   default   svc:edisplay   4s    5 OK / 5     True
    ping    default   svc:edisplay   32s   5 OK / 5     True
  • JSON 形式でトリガーの一覧を出力するには、以下のコマンドを入力します。

    $ kn trigger list -o json

9.6.3. kn を使用したトリガーの記述

kn trigger describe コマンドは、トリガーについての情報を出力します。

手順

トリガーについての情報を出力するには、以下のコマンドを入力します。

$ kn trigger describe <TRIGGER-NAME>

出力例:

$ kn trigger describe ping
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

9.6.4. kn を使用したトリガーの削除

手順

トリガーを削除するには、以下のコマンドを入力します。

$ kn trigger delete <TRIGGER-NAME>

9.6.5. kn を使用したトリガーの更新

特定のフラグを指定して kn trigger update コマンドを使用して、トリガーの属性を迅速に更新できます。

手順

トリガーを更新するには、以下のコマンドを入力します。

$ kn trigger update NAME --filter KEY=VALUE --sink SINK [flags]

トリガーを、受信イベントに一致するイベント属性をフィルターするように更新できます (例: type=knative.dev.event)。例:

$ kn trigger update mytrigger --filter type=knative.dev.event

トリガーからフィルター属性を削除することもできます。たとえば、キー type を使用してフィルター属性を削除できます。

$ kn trigger update mytrigger --filter type-

以下の例は、トリガーのシンクを svc:new-service に更新する方法を示しています。

$ kn trigger update mytrigger --sink svc:new-service

9.6.6. トリガーを使用したイベントのフィルター

以下のトリガーの例では、type: dev.knative.samples.helloworld 属性のあるイベントのみがイベントコンシューマーに到達します。

$ kn trigger create foo --broker default --filter type=dev.knative.samples.helloworld --sink svc:mysvc

複数の属性を使用してイベントをフィルターすることもできます。以下の例は、type、source、および extension 属性を使用してイベントをフィルターする方法を示しています。

$ kn trigger create foo --broker default --sink svc:mysvc \
--filter type=dev.knative.samples.helloworld \
--filter source=dev.knative.samples/helloworldsource \
--filter myextension=my-extension-value

9.7. Knative Eventing でのブローカーの使用

Knative Eventing は、特に指定がない場合は default ブローカーを使用します。

クラスター管理者のパーミッションがある場合は、namespace アノテーションを使用して default ブローカーを自動的に作成できます。

その他のすべてのユーザーは、本書で説明されている手動プロセスを使用してブローカーを作成する必要があります。

9.7.1. ブローカーの手動による作成

ブローカーを作成するには、それぞれの namespace に ServiceAccount を作成し、その ServiceAccount に必要な RBAC パーミッションを付与する必要があります。

前提条件

  • ClusterRole を含む Knative Eventing がインストールされている。

手順

  1. ServiceAccount オブジェクトを作成します。

    $ oc -n default create serviceaccount eventing-broker-ingress
    $ oc -n default create serviceaccount eventing-broker-filter
  2. それらのオブジェクトに RBAC パーミッションを付与します。

    $ oc -n default create rolebinding eventing-broker-ingress \
      --clusterrole=eventing-broker-ingress \
      --serviceaccount=default:eventing-broker-ingress
    $ oc -n default create rolebinding eventing-broker-filter \
      --clusterrole=eventing-broker-filter \
      --serviceaccount=default:eventing-broker-filter
  3. ブローカーを作成します。

    cat << EOF | oc apply -f -
    apiVersion: eventing.knative.dev/v1beta1
    kind: Broker
    metadata:
      namespace: default
      name: default 1
    EOF
    1
    この例では、default という名前を使用していますが、これを他の有効な名前に置き換えることができます。

9.7.2. namespace アノテーションを使用したブローカーの自動作成

クラスター管理者のパーミッションがある場合は、namespace にアノテーションを付けることでブローカーを自動的に作成できます。

前提条件

  • Knative Eventing がインストールされている。
  • Azure Red Hat OpenShift のクラスター管理者パーミッション。

手順

  1. 以下のコマンドを入力して namespace にアノテーションを付けます。

    $ oc label namespace default knative-eventing-injection=enabled 1
    $ oc -n default get broker default
    1
    default を必要な namespace に置き換えます。

    以下の例で示されている行は、default という名前のブローカーを default namespace に自動的に作成します。

注記

アノテーションによって作成されたブローカーは、アノテーションを削除しても削除されません。これらは手動で削除する必要があります。

9.7.3. namespace アノテーションを使用して作成されたブローカーの削除

  1. 選択した namespace(この例では default namespace) から挿入されたブローカーを削除します。

    $ oc -n default delete broker default

9.8. チャネルの使用

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

チャネルインスタンスのデフォルト設定は default-ch-webhook ConfigMap で定義されます。ただし、開発者はサポートされているチャネルオブジェクトをインスタンス化することで、独自のチャネルを直接作成できます。

9.8.1. サポートされているチャネルタイプ

現時点で、OpenShift Serverless は Knative Eventing テクノロジープレビューの一部として InMemoryChannel チャネルの使用のみをサポートします。

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

  • イベントの永続性は利用できません。Pod がダウンすると、その Pod のイベントが失われます。
  • InMemoryChannel チャネルはイベントの順序を実装しないため、チャネルで同時に受信される 2 つのイベントはいずれの順序でもサブスクライバーに配信できます。
  • サブスクライバーがイベントを拒否する場合、再配信は試行されません。代わりに、拒否されたイベントは、シンクが存在する場合は dead letter sink に送信されます。これが存在しない場合にはドロップされます。

9.8.2. クラスターのデフォルト設定でのチャネルの作成

クラスター管理者が設定したクラスターのデフォルト設定を使用してチャネルを作成するには、汎用の Channel カスタムオブジェクトを作成する必要があります。

Channel オブジェクトの例

apiVersion: messaging.knative.dev/v1beta1
kind: Channel
metadata:
  name: example-channel
  namespace: default

上記の Channel オブジェクトが作成されると、変更用の受付 Webhook はクラスター管理者が選択するデフォルトのチャネル実装に基づいて Channel オブジェクトの spec.channelTemplate プロパティーのセットを追加します。

spec.channelTemplate プロパティーを持つ Channel オブジェクトの例

apiVersion: messaging.knative.dev/v1beta1
kind: Channel
metadata:
  name: example-channel
  namespace: default
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1beta1
    kind: InMemoryChannel

チャネルコントローラーは、その後に spec.channelTemplate 設定に基づいてサポートするチャネルインスタンスを作成します。spec.channelTemplate プロパティーは作成後に変更できません。それらは、ユーザーではなくデフォルトのチャネルメカニズムで設定されるためです。

このメカニズムが使用される場合、汎用チャネル、および InMemoryChannel チャネルなど 2 つのオブジェクトが作成されます。

汎用チャネルは、サブスクリプションを InMemoryChannel にコピーするプロキシーとして機能し、サポートする InMemoryChannel チャネルのステータスを反映するようにそのステータスを設定します。

この例のチャネルはデフォルトの namespace で作成されるため、チャネルはクラスターのデフォルト (InMemoryChannel) を使用します。

第10章 OpenShift Serverless でのメータリングの使用

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

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

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

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

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

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

10.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!=""}
          )

10.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!=""}
          )

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

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

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

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

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

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

10.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']

10.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']

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

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

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

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

10.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 のいずれか。

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

入力パラメーターを入力すると、以下のコマンドを使用してレポートを実行できます。

$ oc apply -f <report-name>.yml

以下の例のようにレポートを確認できます。

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

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

このページには機械翻訳が使用されている場合があります (詳細はこちら)。