Knative CLI
Knative Functions、Serving、および Eventing の CLI コマンドの概要
概要
第1章 Knative Serving CLI コマンド
1.1. kn service コマンド
以下のコマンドを使用して Knative サービスを作成し、管理できます。
1.1.1. Knative CLI を使用したサーバーレスアプリケーションの作成
Knative (kn
) CLI を使用してサーバーレスアプリケーションを作成すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。kn service create
コマンドを使用して、基本的なサーバーレスアプリケーションを作成できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Knative サービスを作成します。
kn service create <service-name> --image <image> --tag <tag-value>
$ kn service create <service-name> --image <image> --tag <tag-value>
Copy to Clipboard Copied! ここでは、以下のようになります。
-
--image
は、アプリケーションのイメージの URI です。 --tag
は、サービスで作成される初期リビジョンにタグを追加するために使用できるオプションのフラグです。コマンドの例
kn service create showcase \ --image quay.io/openshift-knative/showcase
$ kn service create showcase \ --image quay.io/openshift-knative/showcase
Copy to Clipboard Copied! 出力例
Creating service 'showcase' in namespace 'default': 0.271s The Route is still working to reflect the latest desired specification. 0.580s Configuration "showcase" is waiting for a Revision to become ready. 3.857s ... 3.861s Ingress has not yet been reconciled. 4.270s Ready to serve. Service 'showcase' created with latest revision 'showcase-00001' and URL: http://showcase-default.apps-crc.testing
Creating service 'showcase' in namespace 'default': 0.271s The Route is still working to reflect the latest desired specification. 0.580s Configuration "showcase" is waiting for a Revision to become ready. 3.857s ... 3.861s Ingress has not yet been reconciled. 4.270s Ready to serve. Service 'showcase' created with latest revision 'showcase-00001' and URL: http://showcase-default.apps-crc.testing
Copy to Clipboard Copied!
-
1.1.2. Knative CLI を使用したサーバーレスアプリケーションの更新
サービスを段階的に構築する際に、コマンドラインで kn service update
コマンドを使用し、対話式のセッションを使用できます。kn service apply
コマンドとは対照的に、kn service update
コマンドを使用する際は、Knative サービスの完全な設定ではなく、更新が必要な変更のみを指定する必要があります。
コマンドの例
新規の環境変数を追加してサービスを更新します。
kn service update <service_name> --env <key>=<value>
$ kn service update <service_name> --env <key>=<value>
Copy to Clipboard Copied! 新しいポートを追加してサービスを更新します。
kn service update <service_name> --port 80
$ kn service update <service_name> --port 80
Copy to Clipboard Copied! 新しい要求および制限パラメーターを追加してサービスを更新します。
kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
$ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
Copy to Clipboard Copied! latest
タグをリビジョンに割り当てます。kn service update <service_name> --tag <revision_name>=latest
$ kn service update <service_name> --tag <revision_name>=latest
Copy to Clipboard Copied! サービスの最新の
READY
リビジョンについて、testing
からstaging
にタグを更新します。kn service update <service_name> --untag testing --tag @latest=staging
$ kn service update <service_name> --untag testing --tag @latest=staging
Copy to Clipboard Copied! test
タグをトラフィックの 10% を受信するリビジョンに追加し、残りのトラフィックをサービスの最新のREADY
リビジョンに送信します。kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90
$ kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90
Copy to Clipboard Copied!
1.1.3. サービス宣言の適用
kn service apply
コマンドを使用して Knative サービスを宣言的に設定できます。サービスが存在しない場合は、これが作成されますが、それ以外の場合は、既存のサービスが変更されたオプションで更新されます。
kn service apply
コマンドは、ユーザーがターゲットの状態を宣言するために単一コマンドでサービスの状態を詳細に指定したい場合など、とくにシェルスクリプトや継続的インテグレーションパイプラインで役に立ちます。
kn service apply
を使用する場合は、Knative サービスの詳細な設定を指定する必要があります。これは kn service update
コマンドとは異なります。このコマンドでは、更新する必要のあるオプションを指定するだけで済みます。
コマンドの例
サービスを作成します。
kn service apply <service_name> --image <image>
$ kn service apply <service_name> --image <image>
Copy to Clipboard Copied! 環境変数をサービスに追加します。
kn service apply <service_name> --image <image> --env <key>=<value>
$ kn service apply <service_name> --image <image> --env <key>=<value>
Copy to Clipboard Copied! JSON または YAML ファイルからサービス宣言を読み取ります。
kn service apply <service_name> -f <filename>
$ kn service apply <service_name> -f <filename>
Copy to Clipboard Copied!
1.1.4. Knative CLI を使用したサーバーレスアプリケーションの記述
kn service describe
コマンドを使用して Knative サービスを記述できます。
コマンドの例
サービスを記述します。
kn service describe --verbose <service_name>
$ kn service describe --verbose <service_name>
Copy to Clipboard Copied! --verbose
フラグは任意ですが、さらに詳細な説明を提供するために追加できます。通常の出力と詳細出力の違いを次の例に示します。--verbose
フラグを使用しない出力例Name: showcase Namespace: default Age: 2m URL: http://showcase-default.apps.ocp.example.com Revisions: 100% @latest (showcase-00001) [1] (2m) Image: quay.io/openshift-knative/showcase (pinned to aaea76) Conditions: OK TYPE AGE REASON ++ Ready 1m ++ ConfigurationsReady 1m ++ RoutesReady 1m
Name: showcase Namespace: default Age: 2m URL: http://showcase-default.apps.ocp.example.com Revisions: 100% @latest (showcase-00001) [1] (2m) Image: quay.io/openshift-knative/showcase (pinned to aaea76) Conditions: OK TYPE AGE REASON ++ Ready 1m ++ ConfigurationsReady 1m ++ RoutesReady 1m
Copy to Clipboard Copied! --verbose
フラグを使用する出力例Name: showcase Namespace: default Annotations: serving.knative.dev/creator=system:admin serving.knative.dev/lastModifier=system:admin Age: 3m URL: http://showcase-default.apps.ocp.example.com Cluster: http://showcase.default.svc.cluster.local Revisions: 100% @latest (showcase-00001) [1] (3m) Image: quay.io/openshift-knative/showcase (pinned to aaea76) Env: GREET=Bonjour Conditions: OK TYPE AGE REASON ++ Ready 3m ++ ConfigurationsReady 3m ++ RoutesReady 3m
Name: showcase Namespace: default Annotations: serving.knative.dev/creator=system:admin serving.knative.dev/lastModifier=system:admin Age: 3m URL: http://showcase-default.apps.ocp.example.com Cluster: http://showcase.default.svc.cluster.local Revisions: 100% @latest (showcase-00001) [1] (3m) Image: quay.io/openshift-knative/showcase (pinned to aaea76) Env: GREET=Bonjour Conditions: OK TYPE AGE REASON ++ Ready 3m ++ ConfigurationsReady 3m ++ RoutesReady 3m
Copy to Clipboard Copied! サービスを YAML 形式で記述します。
kn service describe <service_name> -o yaml
$ kn service describe <service_name> -o yaml
Copy to Clipboard Copied! サービスを JSON 形式で記述します。
kn service describe <service_name> -o json
$ kn service describe <service_name> -o json
Copy to Clipboard Copied! サービス URL のみを出力します。
kn service describe <service_name> -o url
$ kn service describe <service_name> -o url
Copy to Clipboard Copied!
1.2. オフラインモードの kn サービスコマンド
1.2.1. Knative CLI オフラインモードについて
kn service
コマンドを実行すると、変更が即座にクラスターに伝播されます。ただし、別の方法として、オフラインモードで kn service
コマンドを実行できます。オフラインモードでサービスを作成すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。
Knative CLI のオフラインモードはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
記述子ファイルの作成後、手動で変更し、バージョン管理システムで追跡できます。記述子ファイルで kn service create -f
、kn service apply -f
、または oc apply -f
、コマンドを使用して変更をクラスターに伝播することもできます。
オフラインモードには、いくつかの用途があります。
- 記述子ファイルを使用してクラスターで変更する前に、記述子ファイルを手動で変更できます。
- バージョン管理システムでは、サービスの記述子ファイルをローカルで追跡できます。これにより、継続的インテグレーション (CI) パイプライン、開発環境、デモなど、ターゲットクラスター以外の場所で記述子ファイルを再利用できるようになります。
-
作成した記述子ファイルを検証して Knative サービスを確認できます。特に、生成されるサービスが
kn
コマンドに渡されるさまざまな引数によってどのように影響するかを確認できます。
オフラインモードには、高速で、クラスターへの接続を必要としないという利点があります。ただし、オフラインモードではサーバー側の検証がありません。したがって、サービス名が一意であることや、指定のイメージをプルできることなどを確認できません。
1.2.2. オフラインモードを使用したサービスの作成
オフラインモードで kn service
コマンドを実行すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。記述子ファイルを作成した後、クラスターに変更を伝播する前にファイルを変更することができます。
Knative CLI のオフラインモードはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI がインストールされている。
手順
オフラインモードでは、ローカルの Knative サービス記述子ファイルを作成します。
kn service create showcase \ --image quay.io/openshift-knative/showcase \ --target ./ \ --namespace test
$ kn service create showcase \ --image quay.io/openshift-knative/showcase \ --target ./ \ --namespace test
Copy to Clipboard Copied! 出力例
Service 'showcase' created in namespace 'test'.
Service 'showcase' created in namespace 'test'.
Copy to Clipboard Copied! --target ./
フラグはオフラインモードを有効にし、./
を新しいディレクトリーツリーを保存するディレクトリーとして指定します。既存のディレクトリーを指定せずに、
--target my-service.yaml
などのファイル名を使用すると、ディレクトリーツリーは作成されません。代わりに、サービス記述子ファイルmy-service.yaml
のみが現在のディレクトリーに作成されます。ファイル名には、
.yaml
、.yml
または.json
拡張子を使用できます。.json
を選択すると、JSON 形式でサービス記述子ファイルが作成されます。--namespace test
オプションは、新規サービスをテスト
namespace に配置します。--namespace
を使用せずに OpenShift Container Platform クラスターにログインしていると、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルがdefault
の namespace に作成されます。
作成したディレクトリー構造を確認します。
tree ./
$ tree ./
Copy to Clipboard Copied! 出力例
./ └── test └── ksvc └── showcase.yaml 2 directories, 1 file
./ └── test └── ksvc └── showcase.yaml 2 directories, 1 file
Copy to Clipboard Copied! -
--target
で指定する現在の./
ディレクトリーには新しいtest/
ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。 -
test/
ディレクトリーには、リソースタイプの名前が付けられたksvc
ディレクトリーが含まれます。 -
ksvc
ディレクトリーには、指定のサービス名に従って名前が付けられる記述子ファイルshowcase.yaml
が含まれます。
-
生成されたサービス記述子ファイルを確認します。
cat test/ksvc/showcase.yaml
$ cat test/ksvc/showcase.yaml
Copy to Clipboard Copied! 出力例
apiVersion: serving.knative.dev/v1 kind: Service metadata: creationTimestamp: null name: showcase namespace: test spec: template: metadata: annotations: client.knative.dev/user-image: quay.io/openshift-knative/showcase creationTimestamp: null spec: containers: - image: quay.io/openshift-knative/showcase name: "" resources: {} status: {}
apiVersion: serving.knative.dev/v1 kind: Service metadata: creationTimestamp: null name: showcase namespace: test spec: template: metadata: annotations: client.knative.dev/user-image: quay.io/openshift-knative/showcase creationTimestamp: null spec: containers: - image: quay.io/openshift-knative/showcase name: "" resources: {} status: {}
Copy to Clipboard Copied! 新しいサービスに関する情報をリスト表示します。
kn service describe showcase --target ./ --namespace test
$ kn service describe showcase --target ./ --namespace test
Copy to Clipboard Copied! 出力例
Name: showcase Namespace: test Age: URL: Revisions: Conditions: OK TYPE AGE REASON
Name: showcase Namespace: test Age: URL: Revisions: Conditions: OK TYPE AGE REASON
Copy to Clipboard Copied! --target ./
オプションは、namespace サブディレクトリーを含むディレクトリー構造のルートディレクトリーを指定します。または、
--target
オプションで YAML または JSON ファイルを直接指定できます。使用可能なファイルの拡張子は、.yaml
、.yml
、および.json
です。--namespace
オプションは、namespace を指定し、この namespace は必要なサービス記述子ファイルを含むサブディレクトリーのkn
と通信します。--namespace
を使用せず、OpenShift Container Platform クラスターにログインしている場合、kn
は現在の namespace にちなんで名付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kn
はdefault/
サブディレクトリーで検索します。
サービス記述子ファイルを使用してクラスターでサービスを作成します。
kn service create -f test/ksvc/showcase.yaml
$ kn service create -f test/ksvc/showcase.yaml
Copy to Clipboard Copied! 出力例
Creating service 'showcase' in namespace 'test': 0.058s The Route is still working to reflect the latest desired specification. 0.098s ... 0.168s Configuration "showcase" is waiting for a Revision to become ready. 23.377s ... 23.419s Ingress has not yet been reconciled. 23.534s Waiting for load balancer to be ready 23.723s Ready to serve. Service 'showcase' created to latest revision 'showcase-00001' is available at URL: http://showcase-test.apps.example.com
Creating service 'showcase' in namespace 'test': 0.058s The Route is still working to reflect the latest desired specification. 0.098s ... 0.168s Configuration "showcase" is waiting for a Revision to become ready. 23.377s ... 23.419s Ingress has not yet been reconciled. 23.534s Waiting for load balancer to be ready 23.723s Ready to serve. Service 'showcase' created to latest revision 'showcase-00001' is available at URL: http://showcase-test.apps.example.com
Copy to Clipboard Copied!
1.3. kn container コマンド
以下のコマンドを使用して、Knative サービス仕様で複数のコンテナーを作成し、管理できます。
1.3.1. Knative クライアントマルチコンテナーのサポート
kn container add
コマンドを使用して、YAML コンテナーの仕様を標準出力に出力できます。このコマンドは、定義を作成するために他の標準の kn
フラグと共に使用できるため、マルチコンテナーのユースケースに役立ちます。
kn container add
コマンドは、kn service create
コマンドで使用できるコンテナー関連のすべてのフラグを受け入れます。UNIX パイプ (|
) を使用して kn container add
コマンドを連結して、一度に複数のコンテナー定義を作成することもできます。
コマンドの例
イメージからコンテナーを追加し、標準出力に出力します。
kn container add <container_name> --image <image_uri>
$ kn container add <container_name> --image <image_uri>
Copy to Clipboard Copied! コマンドの例
kn container add sidecar --image docker.io/example/sidecar
$ kn container add sidecar --image docker.io/example/sidecar
Copy to Clipboard Copied! 出力例
containers: - image: docker.io/example/sidecar name: sidecar resources: {}
containers: - image: docker.io/example/sidecar name: sidecar resources: {}
Copy to Clipboard Copied! 2 つの
kn container add
コマンドを連結してから、kn service create
コマンドに渡して、2 つのコンテナーで Knative サービスを作成します。kn container add <first_container_name> --image <image_uri> | \ kn container add <second_container_name> --image <image_uri> | \ kn service create <service_name> --image <image_uri> --extra-containers -
$ kn container add <first_container_name> --image <image_uri> | \ kn container add <second_container_name> --image <image_uri> | \ kn service create <service_name> --image <image_uri> --extra-containers -
Copy to Clipboard Copied! --extra-containers -
は、kn
が YAML ファイルの代わりにパイプ入力を読み取る特別なケースを指定します。コマンドの例
kn container add sidecar --image docker.io/example/sidecar:first | \ kn container add second --image docker.io/example/sidecar:second | \ kn service create my-service --image docker.io/example/my-app:latest --extra-containers -
$ kn container add sidecar --image docker.io/example/sidecar:first | \ kn container add second --image docker.io/example/sidecar:second | \ kn service create my-service --image docker.io/example/my-app:latest --extra-containers -
Copy to Clipboard Copied! --extra-containers
フラグは YAML ファイルへのパスを受け入れることもできます。kn service create <service_name> --image <image_uri> --extra-containers <filename>
$ kn service create <service_name> --image <image_uri> --extra-containers <filename>
Copy to Clipboard Copied! コマンドの例
kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml
$ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml
Copy to Clipboard Copied!
1.4. kn domain コマンド
以下のコマンドを使用して、ドメインマッピングを作成および管理できます。
1.4.1. Knative CLI を使用したカスタムドメインマッピングの作成
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
Knative サービスまたはルートを作成し、その CR にマップするカスタムドメインを制御している。
注記カスタムドメインは OpenShift Container Platform クラスターの DNS を参照する必要があります。
-
Knative (
kn
) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
ドメインを現在の namespace の CR にマップします。
kn domain create <domain_mapping_name> --ref <target_name>
$ kn domain create <domain_mapping_name> --ref <target_name>
Copy to Clipboard Copied! コマンドの例
kn domain create example.com --ref showcase
$ kn domain create example.com --ref showcase
Copy to Clipboard Copied! --ref
フラグは、ドメインマッピング用のアドレス指定可能なターゲット CR を指定します。--ref
フラグの使用時に接頭辞が指定されていない場合は、ターゲットが現在の namespace の Knative サービスであることを前提としています。ドメインを指定された namespace の Knative サービスにマップします。
kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>
$ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>
Copy to Clipboard Copied! コマンドの例
kn domain create example.com --ref ksvc:showcase:example-namespace
$ kn domain create example.com --ref ksvc:showcase:example-namespace
Copy to Clipboard Copied! ドメインを Knative ルートにマップします。
kn domain create <domain_mapping_name> --ref <kroute:route_name>
$ kn domain create <domain_mapping_name> --ref <kroute:route_name>
Copy to Clipboard Copied! コマンドの例
kn domain create example.com --ref kroute:example-route
$ kn domain create example.com --ref kroute:example-route
Copy to Clipboard Copied!
1.4.2. Knative CLI を使用したカスタムドメインマッピングの管理
DomainMapping
カスタムリソース (CR) の作成後に、既存の CR のリスト表示、既存の CR の情報の表示、CR の更新、または Knative (kn
) CLI を使用した CR の削除を実行できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
1 つ以上の
DomainMapping
CR を作成している。 -
Knative (
kn
) CLI ツールがインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
既存の
DomainMapping
CR をリスト表示します。kn domain list -n <domain_mapping_namespace>
$ kn domain list -n <domain_mapping_namespace>
Copy to Clipboard Copied! 既存の
DomainMapping
CR の詳細を表示します。kn domain describe <domain_mapping_name>
$ kn domain describe <domain_mapping_name>
Copy to Clipboard Copied! 新規ターゲットを参照するように
DomainMapping
CR を更新します。kn domain update --ref <target>
$ kn domain update --ref <target>
Copy to Clipboard Copied! DomainMapping
CR を削除します。kn domain delete <domain_mapping_name>
$ kn domain delete <domain_mapping_name>
Copy to Clipboard Copied!
第2章 Knative CLI の設定
config.yaml
設定ファイルを作成して、Knative (kn
) CLI セットアップをカスタマイズできます。--config
フラグを使用してこの設定を指定できます。指定しない場合は、設定がデフォルトの場所から選択されます。デフォルトの設定場所は XDG Base Directory 仕様 に準拠しており、UNIX システムと Windows システムでは異なります。
UNIX システムの場合:
-
XDG_CONFIG_HOME
環境変数が設定されている場合、Knative (kn
) CLI が検索するデフォルト設定の場所は$XDG_CONFIG_HOME/kn
になります。 -
XDG_CONFIG_HOME
環境変数が設定されていない場合、Knative (kn
) CLI は$HOME/.config/kn/config.yaml
のユーザーのホームディレクトリーにある設定を検索します。
Windows システムの場合、デフォルトの Knative (kn
) CLI 設定の場所は %APPDATA%\kn
です。
設定ファイルのサンプル
plugins: path-lookup: true directory: ~/.config/kn/plugins eventing: sink-mappings: - prefix: svc group: core version: v1 resource: services
plugins:
path-lookup: true
directory: ~/.config/kn/plugins
eventing:
sink-mappings:
- prefix: svc
group: core
version: v1
resource: services
- 1
- Knative (
kn
) CLI がPATH
環境変数でプラグインを検索するかどうかを指定します。これはブール型の設定オプションです。デフォルト値はfalse
です。 - 2
- Knative (
kn
) CLI がプラグインを検索するディレクトリーを指定します。前述のように、デフォルトのパスはオペレーティングシステムによって異なります。これには、ユーザーに表示される任意のディレクトリーを指定できます。 - 3
sink-mappings
仕様は、Knative (kn
) CLI コマンドで--sink
フラグを使用する場合に使用される Kubernetes のアドレス可能なリソースを定義します。- 4
- シンクの記述に使用する接頭辞。サービスの
svc
、channel
、およびbroker
は Knative (kn
) CLI で事前に定義される接頭辞です。 - 5
- Kubernetes リソースの API グループ。
- 6
- Kubernetes リソースのバージョン。
- 7
- Kubernetes リソースタイプの複数形の名前。例:
services
またはbrokers
第3章 Knative CLI プラグイン
Knative (kn
) CLI は、プラグインの使用をサポートします。これにより、カスタムコマンドとコアディストリビューションには含まれないその他の共有コマンドを追加でき、kn
インストールの機能の拡張を可能にします。Knative (kn
) CLI プラグインは主な kn
機能として同じ方法で使用されます。
現在、Red Hat は kn-source-kafka
プラグインと kn-event
プラグインをサポートしています。
3.1. kn-event プラグインを使用してイベントを作成する
kn event build
コマンドのビルダーのようなインターフェイスを使用して、イベントをビルドできます。その後、そのイベントを後で送信するか、別のコンテキストで使用できます。
前提条件
-
Knative (
kn
) CLI がインストールされている。
手順
イベントをビルドします。
kn event build --field <field-name>=<value> --type <type-name> --id <id> --output <format>
$ kn event build --field <field-name>=<value> --type <type-name> --id <id> --output <format>
Copy to Clipboard Copied! ここでは、以下のようになります。
-
--field
フラグは、データをフィールド/値のペアとしてイベントに追加します。これは複数回使用できます。 -
--type
フラグを使用すると、イベントのタイプを指定する文字列を指定できます。 -
--id
フラグは、イベントの ID を指定します。 json
またはyaml
引数を--output
フラグと共に使用して、イベントの出力形式を変更できます。これらのフラグはすべてオプションです。
簡単なイベントのビルド
kn event build -o yaml
$ kn event build -o yaml
Copy to Clipboard Copied! YAML 形式のビルドされたイベント
data: {} datacontenttype: application/json id: 81a402a2-9c29-4c27-b8ed-246a253c9e58 source: kn-event/v0.4.0 specversion: "1.0" time: "2021-10-15T10:42:57.713226203Z" type: dev.knative.cli.plugin.event.generic
data: {} datacontenttype: application/json id: 81a402a2-9c29-4c27-b8ed-246a253c9e58 source: kn-event/v0.4.0 specversion: "1.0" time: "2021-10-15T10:42:57.713226203Z" type: dev.knative.cli.plugin.event.generic
Copy to Clipboard Copied! サンプルトランザクションイベントのビルド
kn event build \ --field operation.type=local-wire-transfer \ --field operation.amount=2345.40 \ --field operation.from=87656231 \ --field operation.to=2344121 \ --field automated=true \ --field signature='FGzCPLvYWdEgsdpb3qXkaVp7Da0=' \ --type org.example.bank.bar \ --id $(head -c 10 < /dev/urandom | base64 -w 0) \ --output json
$ kn event build \ --field operation.type=local-wire-transfer \ --field operation.amount=2345.40 \ --field operation.from=87656231 \ --field operation.to=2344121 \ --field automated=true \ --field signature='FGzCPLvYWdEgsdpb3qXkaVp7Da0=' \ --type org.example.bank.bar \ --id $(head -c 10 < /dev/urandom | base64 -w 0) \ --output json
Copy to Clipboard Copied! JSON 形式のビルドされたイベント
{ "specversion": "1.0", "id": "RjtL8UH66X+UJg==", "source": "kn-event/v0.4.0", "type": "org.example.bank.bar", "datacontenttype": "application/json", "time": "2021-10-15T10:43:23.113187943Z", "data": { "automated": true, "operation": { "amount": "2345.40", "from": 87656231, "to": 2344121, "type": "local-wire-transfer" }, "signature": "FGzCPLvYWdEgsdpb3qXkaVp7Da0=" } }
{ "specversion": "1.0", "id": "RjtL8UH66X+UJg==", "source": "kn-event/v0.4.0", "type": "org.example.bank.bar", "datacontenttype": "application/json", "time": "2021-10-15T10:43:23.113187943Z", "data": { "automated": true, "operation": { "amount": "2345.40", "from": 87656231, "to": 2344121, "type": "local-wire-transfer" }, "signature": "FGzCPLvYWdEgsdpb3qXkaVp7Da0=" } }
Copy to Clipboard Copied!
-
3.2. kn-event プラグインを使用したイベントの送信
kn event send
コマンドを使用して、イベントを送信できます。イベントは、公開されているアドレス、または Kubernetes サービスや Knative サービス、ブローカー、チャネル等のクラスター内のアドレス指定可能なリソースのいずれかに送信できます。このコマンドは、kn event build
コマンドと同じビルダーのようなインターフェイスを使用します。
前提条件
-
Knative (
kn
) CLI がインストールされている。
手順
イベントの送信:
kn event send \ --field <field_name>=<value> \ --type <type_name> \ --id <id> \ --to <url_or_cluster_resource> \ --namespace <namespace>
$ kn event send \ --field <field_name>=<value> \ --type <type_name> \ --id <id> \ --to <url_or_cluster_resource> \ --namespace <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
-
--field
フラグは、データをフィールド/値のペアとしてイベントに追加します。これは複数回使用できます。 -
--type
フラグを使用すると、イベントのタイプを指定する文字列を指定できます。 -
--id
フラグは、イベントの ID を指定します。 -
-
to
フラグは、イベントの宛先を指定します。 --namespace
フラグは namespace を指定します。省略すると、namespace は現在のコンテキストから取得されます。宛先の仕様を除き、これらのフラグはすべてオプションです。
-
the- to フラグには、以下の宛先形式を
使用できます。
-
--to broker:<broker>
: ブローカーを指定します。 -
--to channel:<channel>
: チャネルを指定します。 -
--to ksvc:<
: 現在の namespace に Knative サービスを指定します。;service>
; または <service> -
--to ksvc:<service>:<namespace>
: 別の namespace に Knative サービスを指定します。 -
--to svc:<service>:<namespace>
: 別の namespace の Kubernetes サービスを指定します。 -
--to special.eventing.dev/v1alpha1/channels:<channel
> :v1alpha1
チャネルのGroupVersionResource
を指定します。 -
--to https://example.receiver.uri
: HTTP URL を指定します。
接頭辞を指定しない場合、宛先はデフォルトで現在の namespace の Knative サービスに設定されます。
イベントを URL に送信する
kn event send \ --field player.id=6354aa60-ddb1-452e-8c13-24893667de20 \ --field player.game=2345 \ --field points=456 \ --type org.example.gaming.foo \ --to http://ce-api.foo.example.com/
$ kn event send \
--field player.id=6354aa60-ddb1-452e-8c13-24893667de20 \
--field player.game=2345 \
--field points=456 \
--type org.example.gaming.foo \
--to http://ce-api.foo.example.com/
インクラスターリソースへの送信およびイベント
kn event send \ --type org.example.kn.ping \ --id $(uuidgen) \ --field event.type=test \ --field event.data=98765 \ --to ksvc:event-display
$ kn event send \
--type org.example.kn.ping \
--id $(uuidgen) \
--field event.type=test \
--field event.data=98765 \
--to ksvc:event-display
第4章 Knative Eventing CLI コマンド
4.1. kn source コマンド
以下のコマンドを使用して、Knative イベントソースをリスト表示、作成、および管理できます。
4.1.1. Knative CLI の使用による利用可能なイベントソースタイプの一覧表示
kn source list-types
CLI コマンドを使用して、クラスターで作成して使用できるイベントソースタイプをリスト表示できます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI がインストールされている。
手順
ターミナルに利用可能なイベントソースタイプをリスト表示します。
kn source list-types
$ kn source list-types
Copy to Clipboard Copied! 出力例
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
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
Copy to Clipboard Copied! オプション: OpenShift Container Platform では、利用可能なイベントソースタイプを YAML 形式でリストすることもできます。
kn source list-types -o yaml
$ kn source list-types -o yaml
Copy to Clipboard Copied!
4.1.2. Knative CLI シンクフラグ
Knative (kn
) CLI を使用してイベントソースを作成する場合は、--sink
フラグを使用して、そのリソースからイベントが送信されるシンクを指定できます。シンクは、他のリソースから受信イベントを受信できる、アドレス指定可能または呼び出し可能な任意のリソースです。
以下の例では、サービスの http://event-display.svc.cluster.local
をシンクとして使用するシンクバインディングを作成します。
シンクフラグを使用したコマンドの例
kn source binding create bind-heartbeat \ --namespace sinkbinding-example \ --subject "Job:batch/v1:app=heartbeat-cron" \ --sink http://event-display.svc.cluster.local \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
http://event-display.svc.cluster.local
のsvc
は、シンクが Knative サービスであることを判別します。他のデフォルトのシンクの接頭辞には、channel
およびbroker
が含まれます。
4.1.3. Knative CLI を使用したコンテナーソースの作成および管理
kn source container
コマンドを使用し、Knative (kn
) CLI を使用してコンテナーソースを作成および管理できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。
コンテナーソースの作成
kn source container create <container_source_name> --image <image_uri> --sink <sink>
$ kn source container create <container_source_name> --image <image_uri> --sink <sink>
コンテナーソースの削除
kn source container delete <container_source_name>
$ kn source container delete <container_source_name>
コンテナーソースの記述
kn source container describe <container_source_name>
$ kn source container describe <container_source_name>
既存のコンテナーソースをリスト表示
kn source container list
$ kn source container list
既存のコンテナーソースを YAML 形式でリスト表示
kn source container list -o yaml
$ kn source container list -o yaml
コンテナーソースの更新
このコマンドにより、既存のコンテナーソースのイメージ URI が更新されます。
kn source container update <container_source_name> --image <image_uri>
$ kn source container update <container_source_name> --image <image_uri>
4.1.4. Knative CLI を使用した API サーバーソースの作成
kn source apiserver create
コマンドを使用し、kn
CLI を使用して API サーバーソースを作成できます。API サーバーソースを作成するために kn
CLI を使用すると、YAML ファイルを直接修正するよりも合理的で直感的なユーザーインターフェイスが得られます。
前提条件
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc
) がインストールされている。 -
Knative (
kn
) CLI がインストールされている。
既存のサービスアカウントを再利用する必要がある場合は、既存の ServiceAccount
リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。
イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: events-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: event-watcher namespace: default rules: - apiGroups: - "" resources: - events verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: k8s-ra-event-watcher namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: event-watcher subjects: - kind: ServiceAccount name: events-sa namespace: default
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 Copy to Clipboard Copied! YAML ファイルを適用します。
oc apply -f <filename>
$ oc apply -f <filename>
Copy to Clipboard Copied! イベントシンクを持つ API サーバーソースを作成します。次の例では、シンクはブローカーです。
kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
Copy to Clipboard Copied! API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。
kn service create event-display --image quay.io/openshift-knative/showcase
$ kn service create event-display --image quay.io/openshift-knative/showcase
Copy to Clipboard Copied! ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、
default
のブローカーからサービスへのイベントをフィルタリングします。kn trigger create <trigger_name> --sink ksvc:event-display
$ kn trigger create <trigger_name> --sink ksvc:event-display
Copy to Clipboard Copied! デフォルト namespace で Pod を起動してイベントを作成します。
oc create deployment event-origin --image quay.io/openshift-knative/showcase
$ oc create deployment event-origin --image quay.io/openshift-knative/showcase
Copy to Clipboard Copied! 以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。
kn source apiserver describe <source_name>
$ kn source apiserver describe <source_name>
Copy to Clipboard Copied! 出力例
Name: mysource Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 3m ServiceAccountName: events-sa Mode: Resource Sink: Name: default Namespace: default Kind: Broker (eventing.knative.dev/v1) Resources: Kind: event (v1) Controller: false Conditions: OK TYPE AGE REASON ++ Ready 3m ++ Deployed 3m ++ SinkProvided 3m ++ SufficientPermissions 3m ++ EventTypesProvided 3m
Name: mysource Namespace: default Annotations: sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer Age: 3m ServiceAccountName: events-sa Mode: Resource Sink: Name: default Namespace: default Kind: Broker (eventing.knative.dev/v1) Resources: Kind: event (v1) Controller: false Conditions: OK TYPE AGE REASON ++ Ready 3m ++ Deployed 3m ++ SinkProvided 3m ++ SufficientPermissions 3m ++ EventTypesProvided 3m
Copy to Clipboard Copied!
検証
Kubernetes イベントが Knative に送信されたことを確認するには、イベント表示ログを確認するか、Web ブラウザーを使用してイベントを確認します。
Web ブラウザーでイベントを表示するには、次のコマンドで返されたリンクを開きます。
kn service describe event-display -o url
$ kn service describe event-display -o url
Copy to Clipboard Copied! 図4.1 ブラウザーページの例
あるいは、ターミナルでログを確認するには、次のコマンドを入力して Pod のイベント表示ログを表示します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
Copy to Clipboard Copied! 出力例
☁️ 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{event-origin}", "kind": "Pod", "name": "event-origin", "namespace": "default", ..... }, "kind": "Event", "message": "Started container", "metadata": { "name": "event-origin.159d7608e3a3572c", "namespace": "default", .... }, "reason": "Started", ... }
☁️ 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{event-origin}", "kind": "Pod", "name": "event-origin", "namespace": "default", ..... }, "kind": "Event", "message": "Started container", "metadata": { "name": "event-origin.159d7608e3a3572c", "namespace": "default", .... }, "reason": "Started", ... }
Copy to Clipboard Copied!
API サーバーソースの削除
トリガーを削除します。
kn trigger delete <trigger_name>
$ kn trigger delete <trigger_name>
Copy to Clipboard Copied! イベントソースを削除します。
kn source apiserver delete <source_name>
$ kn source apiserver delete <source_name>
Copy to Clipboard Copied! サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。
oc delete -f authentication.yaml
$ oc delete -f authentication.yaml
Copy to Clipboard Copied!
4.1.5. Knative CLI を使用した ping ソースの作成
kn source ping create
コマンドを使用し、Knative (kn
) CLI を使用して ping ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。
前提条件
- OpenShift Serverless Operator、Knative Serving、および Knative Eventing がクラスターにインストールされている。
-
Knative (
kn
) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
オプション: この手順の検証手順を使用する場合は、OpenShift CLI (
oc
) がインストールされている。
手順
ping ソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする単純な Knative サービスを作成します。
kn service create event-display \ --image quay.io/openshift-knative/showcase
$ kn service create event-display \ --image quay.io/openshift-knative/showcase
Copy to Clipboard Copied! 要求する必要のある ping イベントのセットごとに、ping ソースをイベントコンシューマーと同じ namespace に作成します。
kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display
$ kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display
Copy to Clipboard Copied! 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。
kn source ping describe test-ping-source
$ kn source ping describe test-ping-source
Copy to Clipboard Copied! 出力例
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
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
Copy to Clipboard Copied!
検証
シンク Pod のログを確認して、Kubernetes イベントが Knative イベントに送信されていることを確認できます。
デフォルトでは、Knative サービスは、60 秒以内にトラフィックを受信しないと Pod を終了します。このガイドの例では、新たに作成される Pod で各メッセージが確認されるように 2 分ごとにメッセージを送信する ping ソースを作成します。
作成された新規 Pod を監視します。
watch oc get pods
$ watch oc get pods
Copy to Clipboard Copied! Ctrl+C を使用して Pod の監視をキャンセルし、作成された Pod のログを確認します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
Copy to Clipboard Copied! 出力例
☁️ 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!" }
☁️ 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!" }
Copy to Clipboard Copied!
ping ソースの削除
ping ソースを削除します。
kn delete pingsources.sources.knative.dev <ping_source_name>
$ kn delete pingsources.sources.knative.dev <ping_source_name>
Copy to Clipboard Copied!
4.1.6. Knative CLI を使用した Apache Kafka イベントソースの作成
kn source kafka create
コマンドを使用し、Knative (kn
) CLI を使用して Kafka ソースを作成できます。Knative CLI を使用してイベントソースを作成すると、YAML ファイルを直接変更するよりも合理化された直感的なユーザーインターフェイスが提供されます。
前提条件
-
OpenShift Serverless Operator、Knative Eventing、Knative Serving、および
KnativeKafka
カスタムリソース (CR) がクラスターにインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- インポートする Kafka メッセージを生成する Red Hat AMQ Streams (Kafka) クラスターにアクセスできる。
-
Knative (
kn
) CLI がインストールされている。 -
オプション: この手順で検証ステップを使用する場合は、OpenShift CLI (
oc
) をインストールしている。
手順
Kafka イベントソースが機能していることを確認するには、受信メッセージをサービスのログにダンプする Knative サービスを作成します。
kn service create event-display \ --image quay.io/openshift-knative/showcase
$ kn service create event-display \ --image quay.io/openshift-knative/showcase
Copy to Clipboard Copied! KafkaSource
CR を作成します。kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display
$ kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display
Copy to Clipboard Copied! 注記このコマンドのプレースホルダー値は、ソース名、ブートストラップサーバー、およびトピックの値に置き換えます。
--servers
、--topics
、および--consumergroup
オプションは、Kafka クラスターへの接続パラメーターを指定します。--consumergroup
オプションは任意です。オプション: 作成した
KafkaSource
CR の詳細を表示します。kn source kafka describe <kafka_source_name>
$ kn source kafka describe <kafka_source_name>
Copy to Clipboard Copied! 出力例
Name: example-kafka-source Namespace: kafka Age: 1h BootstrapServers: example-cluster-kafka-bootstrap.kafka.svc:9092 Topics: example-topic ConsumerGroup: example-consumer-group Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 1h ++ Deployed 1h ++ SinkProvided 1h
Name: example-kafka-source Namespace: kafka Age: 1h BootstrapServers: example-cluster-kafka-bootstrap.kafka.svc:9092 Topics: example-topic ConsumerGroup: example-consumer-group Sink: Name: event-display Namespace: default Resource: Service (serving.knative.dev/v1) Conditions: OK TYPE AGE REASON ++ Ready 1h ++ Deployed 1h ++ SinkProvided 1h
Copy to Clipboard Copied!
検証手順
Kafka インスタンスをトリガーし、メッセージをトピックに送信します。
oc -n kafka run kafka-producer \ -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \ --restart=Never -- bin/kafka-console-producer.sh \ --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
$ oc -n kafka run kafka-producer \ -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \ --restart=Never -- bin/kafka-console-producer.sh \ --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
Copy to Clipboard Copied! プロンプトにメッセージを入力します。このコマンドは、以下を前提とします。
-
Kafka クラスターが
kafka
namespace にインストールされている。 -
KafkaSource
オブジェクトがmy-topic
トピックを使用するように設定されている。
-
Kafka クラスターが
ログを表示して、メッセージが到達していることを確認します。
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
Copy to Clipboard Copied! 出力例
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.kafka.event source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic subject: partition:46#0 id: partition:46/offset:0 time: 2021-03-10T11:21:49.4Z Extensions, traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00 Data, Hello!
☁️ cloudevents.Event Validation: valid Context Attributes, specversion: 1.0 type: dev.knative.kafka.event source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic subject: partition:46#0 id: partition:46/offset:0 time: 2021-03-10T11:21:49.4Z Extensions, traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00 Data, Hello!
Copy to Clipboard Copied!
第5章 Knative Functions CLI コマンド
5.1. kn 関数コマンド
5.1.1. Knative CLI を使用した関数の作成
コマンドラインで関数のパス、ランタイム、テンプレート、およびイメージレジストリーをフラグとして指定するか、-c
フラグを使用してターミナルで対話型エクスペリエンスを開始できます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI がインストールされている。
手順
関数プロジェクトを作成します。
kn func create -r <repository> -l <runtime> -t <template> <path>
$ kn func create -r <repository> -l <runtime> -t <template> <path>
Copy to Clipboard Copied! -
受け入れられるランタイム値には、
quarkus
、node
、typescript
、go
、python
、springboot
、およびrust
が含まれます。 受け入れられるテンプレート値には、
http
とcloudevents
が含まれます。コマンドの例
kn func create -l typescript -t cloudevents examplefunc
$ kn func create -l typescript -t cloudevents examplefunc
Copy to Clipboard Copied! 出力例
Created typescript function in /home/user/demo/examplefunc
Created typescript function in /home/user/demo/examplefunc
Copy to Clipboard Copied! または、カスタムテンプレートを含むリポジトリーを指定することもできます。
コマンドの例
kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc
$ kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc
Copy to Clipboard Copied! 出力例
Created node function in /home/user/demo/examplefunc
Created node function in /home/user/demo/examplefunc
Copy to Clipboard Copied!
-
受け入れられるランタイム値には、
5.1.2. 関数のローカルでの実行
kn func run
コマンドを使用すると、現在のディレクトリーまたは --path
フラグで指定されたディレクトリーで関数をローカルに実行できます。実行している関数が以前にビルドされたことがない場合、またはプロジェクトファイルが最後にビルドされてから変更されている場合、kn func run
コマンドは、デフォルトで関数を実行する前に関数をビルドします。
現在のディレクトリーで関数を実行するコマンドの例
kn func run
$ kn func run
パスとして指定されたディレクトリー内の関数を実行するコマンドの例
kn func run --path=<directory_path>
$ kn func run --path=<directory_path>
プロジェクトファイルに変更がない場合でも、--build
フラグを使用して、関数を実行する前に既存のイメージを強制的に再構築することもできます。
ビルドフラグを使用した実行コマンドの例
kn func run --build
$ kn func run --build
build
フラグを false に設定すると、イメージのビルドが無効になり、以前にビルドされたイメージを使用して関数が実行します。
ビルドフラグを使用した実行コマンドの例
kn func run --build=false
$ kn func run --build=false
help コマンドを使用して、kn func run
コマンドオプションの詳細を確認できます。
help コマンドのビルド
kn func help run
$ kn func help run
5.1.3. 関数の構築
関数を実行する前に、関数プロジェクトをビルドする必要があります。kn func run
コマンドを使用している場合は、関数が自動的に構築されます。ただし、kn func build
コマンドを使用すると、実行せずに関数をビルドできます。これは、上級ユーザーやデバッグシナリオに役立ちます。
kn func build
は、コンピューターまたは OpenShift Container Platform クラスターでローカルに実行できる OCI コンテナーイメージを作成します。このコマンドは、関数プロジェクト名とイメージレジストリー名を使用して、関数の完全修飾イメージ名を作成します。
5.1.3.1. イメージコンテナーの種類
デフォルトでは、kn func build
は、Red Hat Source-to-Image (S2I) テクノロジーを使用してコンテナーイメージを作成します。
Red Hat Source-to-Image (S2I) を使用したビルドコマンドの例
kn func build
$ kn func build
5.1.3.2. イメージレジストリーの種類
OpenShift Container Registry は、関数イメージを保存するためのイメージレジストリーとしてデフォルトで使用されます。
OpenShift Container Registry を使用したビルドコマンドの例
kn func build
$ kn func build
出力例
Building function image Function image has been built, image: registry.redhat.io/example/example-function:latest
Building function image
Function image has been built, image: registry.redhat.io/example/example-function:latest
--registry
フラグを使用して、OpenShift Container Registry をデフォルトのイメージレジストリーとして使用することをオーバーライドできます。
quay.io を使用するように OpenShift Container Registry をオーバーライドするビルドコマンドの例
kn func build --registry quay.io/username
$ kn func build --registry quay.io/username
出力例
Building function image Function image has been built, image: quay.io/username/example-function:latest
Building function image
Function image has been built, image: quay.io/username/example-function:latest
5.1.3.3. Push フラグ
--push
フラグを kn func build
コマンドに追加して、正常にビルドされた後に関数イメージを自動的にプッシュできます。
OpenShift Container Registry を使用したビルドコマンドの例
kn func build --push
$ kn func build --push
5.1.3.4. Help コマンド
kn func build
コマンドオプションの詳細は、help コマンドを使用できます。
help コマンドのビルド
kn func help build
$ kn func help build
5.1.4. 関数のデプロイ
kn func deploy
コマンドを使用して、関数を Knative サービスとしてクラスターにデプロイできます。ターゲット関数がすでにデプロイされている場合は、コンテナーイメージレジストリーにプッシュされている新規コンテナーイメージで更新され、Knative サービスが更新されます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- デプロイする関数を作成し、初期化している必要がある。
手順
関数をデプロイします。
kn func deploy [-n <namespace> -p <path> -i <image>]
$ kn func deploy [-n <namespace> -p <path> -i <image>]
Copy to Clipboard Copied! 出力例
Function deployed at: http://func.example.com
Function deployed at: http://func.example.com
Copy to Clipboard Copied! -
namespace
を指定しないと、関数は現在の namespace にデプロイされます。 -
この関数は、
path
が指定されない限り、現在のディレクトリーからデプロイされます。 - Knative サービス名はプロジェクト名から派生するため、以下のコマンドでは変更できません。
-
Developer パースペクティブの +Add ビューで Import from Git または Create Serverless Function を使用して、Git リポジトリー URL を使用してサーバーレス関数を作成できます。
5.1.5. 既存の関数のリスト表示
kn func list
を使用して既存の関数をリスト表示できます。Knative サービスとしてデプロイされた関数をリスト表示するには、kn service list
を使用することもできます。
手順
既存の関数をリスト表示します。
kn func list [-n <namespace> -p <path>]
$ kn func list [-n <namespace> -p <path>]
Copy to Clipboard Copied! 出力例
NAME NAMESPACE RUNTIME URL READY example-function default node http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com True
NAME NAMESPACE RUNTIME URL READY example-function default node http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com True
Copy to Clipboard Copied! Knative サービスとしてデプロイされた関数をリスト表示します。
kn service list -n <namespace>
$ kn service list -n <namespace>
Copy to Clipboard Copied! 出力例
NAME URL LATEST AGE CONDITIONS READY REASON example-function http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com example-function-gzl4c 16m 3 OK / 3 True
NAME URL LATEST AGE CONDITIONS READY REASON example-function http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com example-function-gzl4c 16m 3 OK / 3 True
Copy to Clipboard Copied!
5.1.6. 関数の記述
kn func info
コマンドは、関数名、イメージ、namespace、Knative サービス情報、ルート情報、イベントサブスクリプションなどのデプロイされた関数に関する情報を出力します。
手順
関数を説明します。
kn func info [-f <format> -n <namespace> -p <path>]
$ kn func info [-f <format> -n <namespace> -p <path>]
Copy to Clipboard Copied! コマンドの例
kn func info -p function/example-function
$ kn func info -p function/example-function
Copy to Clipboard Copied! 出力例
Function name: example-function Function is built in image: docker.io/user/example-function:latest Function is deployed as Knative Service: example-function Function is deployed in namespace: default Routes: http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com
Function name: example-function Function is built in image: docker.io/user/example-function:latest Function is deployed as Knative Service: example-function Function is deployed in namespace: default Routes: http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com
Copy to Clipboard Copied!
5.1.7. テストイベントでのデプロイされた関数の呼び出し
kn func invoke
CLI コマンドを使用して、ローカルまたは OpenShift Container Platform クラスター上で関数を呼び出すためのテストリクエストを送信できます。このコマンドを使用して、関数が機能し、イベントを正しく受信できることをテストできます。関数をローカルで呼び出すと、関数開発中の簡単なテストに役立ちます。クラスターで関数を呼び出すと、実稼働環境に近いテストに役立ちます。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
-
Knative (
kn
) CLI がインストールされている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- 呼び出す関数をすでにデプロイしている。
手順
関数を呼び出します。
kn func invoke
$ kn func invoke
Copy to Clipboard Copied! -
kn func invoke
コマンドは、ローカルのコンテナーイメージが実行中の場合や、クラスターにデプロイされた関数がある場合にのみ機能します。 -
kn func invoke
コマンドは、デフォルトでローカルディレクトリーで実行され、このディレクトリーが関数プロジェクトであると想定します。
-
5.1.7.1. kn func はオプションのパラメーターを呼び出します
次の kn func invoke
CLI コマンドフラグを使用して、リクエストのオプションパラメーターを指定できます。
フラグ | 説明 |
---|---|
|
呼び出された関数のターゲットインスタンスを指定します。たとえば、 |
|
メッセージの形式を指定します (例: |
| リクエストの一意の文字列識別子を指定します。 |
| クラスターの namespace を指定します。 |
|
リクエストの送信者名を指定します。これは、CloudEvent |
|
リクエストのタイプを指定します (例: |
|
リクエストの内容を指定します。CloudEvent リクエストの場合、これは CloudEvent |
| 送信するデータを含むローカルファイルへのパスを指定します。 |
| リクエストの MIME コンテンツタイプを指定します。 |
| プロジェクトディレクトリーへのパスを指定します。 |
| すべてのオプションを対話的に確認するように要求を有効にします。 |
| 詳細出力の出力を有効にします。 |
|
|
5.1.7.1.1. 主なパラメーター
次のパラメーターは、kn func invoke
コマンドの主なプロパティーを定義します。
- イベントターゲット (
-t
、-target
) -
呼び出された関数のターゲットインスタンス。ローカルにデプロイされた関数の
local
値、リモートにデプロイされた関数のremote
値、または任意のエンドポイントにデプロイされた関数の URL を受け入れます。ターゲットが指定されていない場合は、デフォルトでlocal
になります。 - イベントメッセージ形式 (
-f
、--format
) -
http
やcloudevent
などのイベントのメッセージ形式。これは、デフォルトで、関数の作成時に使用されたテンプレートの形式になります。 - イベントタイプ (
--type
) -
送信されるイベントのタイプ。各イベントプロデューサーのドキュメントで設定されている
type
パラメーターに関する情報を見つけることができます。たとえば、API サーバーソースは、生成されたイベントのtype
パラメーターをdev.knative.apiserver.resource.update
として設定する場合があります。 - イベントソース (
--source
) -
イベントを生成する一意のイベントソース。これは、
https://10.96.0.1/
などのイベントソースの URI、またはイベントソースの名前である可能性があります。 - イベント ID (
--id
) - イベントプロデューサーによって作成されるランダムな一意の ID。
- イベントデータ (
--data
) kn func invoke
コマンドで送信されるイベントのdata
値を指定できます。たとえば、イベントにこのデータ文字列が含まれるように、"Hello World"
などの--data
値を指定できます。デフォルトでは、kn func invoke
によって作成されたイベントにデータは含まれません。注記クラスターにデプロイされた関数は、
source
およびtype
などのプロパティーの値を提供する既存のイベントソースからのイベントに応答できます。多くの場合、これらのイベントには、イベントのドメイン固有のコンテキストをキャプチャーする JSON 形式のdata
値があります。このドキュメントに記載されている CLI フラグを使用して、開発者はローカルテスト用にこれらのイベントをシミュレートできます。--file
フラグを使用してイベントデータを送信し、イベントのデータを含むローカルファイルを指定することもできます。この場合は、--content-type
を使用してコンテンツタイプを指定します。- データコンテンツタイプ (
--content-type
) -
--data
フラグを使用してイベントのデータを追加している場合は、-content-type
フラグを使用して、イベントによって伝送されるデータのタイプを指定できます。前の例では、データはプレーンテキストであるため、kn func invoke --data "Hello world!" --content-type "text/plain"
を指定できます。
5.1.7.1.2. コマンドの例
これは、kn func invoke
コマンドの一般的な呼び出しです。
kn func invoke --type <event_type> --source <event_source> --data <event_data> --content-type <content_type> --id <event_ID> --format <format> --namespace <namespace>
$ kn func invoke --type <event_type> --source <event_source> --data <event_data> --content-type <content_type> --id <event_ID> --format <format> --namespace <namespace>
たとえば、"Hello world!" イベントを送信すると、以下を行うことができます。
kn func invoke --type ping --source example-ping --data "Hello world!" --content-type "text/plain" --id example-ID --format http --namespace my-ns
$ kn func invoke --type ping --source example-ping --data "Hello world!" --content-type "text/plain" --id example-ID --format http --namespace my-ns
5.1.7.1.2.1. データを使用したファイルの指定
イベントデータが含まれるディスクにファイルを指定するには、--file
フラグおよび --content-type
フラグを使用します。
kn func invoke --file <path> --content-type <content-type>
$ kn func invoke --file <path> --content-type <content-type>
たとえば、test.json
ファイルに保存されている JSON データを送信するには、以下のコマンドを使用します。
kn func invoke --file ./test.json --content-type application/json
$ kn func invoke --file ./test.json --content-type application/json
5.1.7.1.2.2. 関数プロジェクトの指定
--path
フラグを使用して、関数プロジェクトへのパスを指定できます。
kn func invoke --path <path_to_function>
$ kn func invoke --path <path_to_function>
たとえば、./example/example-
function ディレクトリーにある function プロジェクトを使用するには、以下のコマンドを使用します。
kn func invoke --path ./example/example-function
$ kn func invoke --path ./example/example-function
5.1.7.1.2.3. ターゲット関数がデプロイされる場所の指定
デフォルトでは、kn func invoke
は関数のローカルデプロイメントをターゲットにします。
kn func invoke
$ kn func invoke
別のデプロイメントを使用するには、--target
フラグを使用します。
kn func invoke --target <target>
$ kn func invoke --target <target>
たとえば、クラスターにデプロイされた関数を使用するには、-target remote
フラグを使用します。
kn func invoke --target remote
$ kn func invoke --target remote
任意の URL にデプロイされた関数を使用するには、-target <URL>
フラグを使用します。
kn func invoke --target "https://my-event-broker.example.com"
$ kn func invoke --target "https://my-event-broker.example.com"
ローカルデプロイメントを明示的にターゲットとして指定できます。この場合、関数がローカルで実行されていないと、コマンドは失敗します。
kn func invoke --target local
$ kn func invoke --target local
5.1.8. 関数の削除
kn func delete
コマンドを使用して関数を削除できます。これは、関数が不要になった場合に役立ち、クラスターのリソースを節約するのに役立ちます。
手順
関数を削除します。
kn func delete [<function_name> -n <namespace> -p <path>]
$ kn func delete [<function_name> -n <namespace> -p <path>]
Copy to Clipboard Copied! -
削除する関数の名前またはパスが指定されていない場合は、現在のディレクトリーで
func.yaml
ファイルを検索し、削除する関数を判断します。 -
namespace が指定されていない場合は、
func.yaml
のnamespace
の値にデフォルト設定されます。
-
削除する関数の名前またはパスが指定されていない場合は、現在のディレクトリーで