Knative CLI


Red Hat OpenShift Serverless 1.36

Knative Functions、Serving、および Eventing の CLI コマンドの概要

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Knative Functions、Serving、Eventing で使用できる CLI コマンドの概要を説明します。また、Knative 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>
    Copy to Clipboard

    ここでは、以下のようになります。

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

      コマンドの例

      $ kn service create showcase \
          --image quay.io/openshift-knative/showcase
      Copy to Clipboard

      出力例

      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

1.1.2. Knative CLI を使用したサーバーレスアプリケーションの更新

サービスを段階的に構築する際に、コマンドラインで kn service update コマンドを使用し、対話式のセッションを使用できます。kn service apply コマンドとは対照的に、kn service update コマンドを使用する際は、Knative サービスの完全な設定ではなく、更新が必要な変更のみを指定する必要があります。

コマンドの例

  • 新規の環境変数を追加してサービスを更新します。

    $ kn service update <service_name> --env <key>=<value>
    Copy to Clipboard
  • 新しいポートを追加してサービスを更新します。

    $ kn service update <service_name> --port 80
    Copy to Clipboard
  • 新しい要求および制限パラメーターを追加してサービスを更新します。

    $ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
    Copy to Clipboard
  • latest タグをリビジョンに割り当てます。

    $ kn service update <service_name> --tag <revision_name>=latest
    Copy to Clipboard
  • サービスの最新の READY リビジョンについて、testing から staging にタグを更新します。

    $ kn service update <service_name> --untag testing --tag @latest=staging
    Copy to Clipboard
  • test タグをトラフィックの 10% を受信するリビジョンに追加し、残りのトラフィックをサービスの最新の READY リビジョンに送信します。

    $ kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90
    Copy to Clipboard

1.1.3. サービス宣言の適用

kn service apply コマンドを使用して Knative サービスを宣言的に設定できます。サービスが存在しない場合は、これが作成されますが、それ以外の場合は、既存のサービスが変更されたオプションで更新されます。

kn service apply コマンドは、ユーザーがターゲットの状態を宣言するために単一コマンドでサービスの状態を詳細に指定したい場合など、とくにシェルスクリプトや継続的インテグレーションパイプラインで役に立ちます。

kn service apply を使用する場合は、Knative サービスの詳細な設定を指定する必要があります。これは kn service update コマンドとは異なります。このコマンドでは、更新する必要のあるオプションを指定するだけで済みます。

コマンドの例

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

    $ kn service apply <service_name> --image <image>
    Copy to Clipboard
  • 環境変数をサービスに追加します。

    $ kn service apply <service_name> --image <image> --env <key>=<value>
    Copy to Clipboard
  • JSON または YAML ファイルからサービス宣言を読み取ります。

    $ kn service apply <service_name> -f <filename>
    Copy to Clipboard

1.1.4. Knative CLI を使用したサーバーレスアプリケーションの記述

kn service describe コマンドを使用して Knative サービスを記述できます。

コマンドの例

  • サービスを記述します。

    $ kn service describe --verbose <service_name>
    Copy to Clipboard

    --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
    Copy to Clipboard

    --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
    Copy to Clipboard

  • サービスを YAML 形式で記述します。

    $ kn service describe <service_name> -o yaml
    Copy to Clipboard
  • サービスを JSON 形式で記述します。

    $ kn service describe <service_name> -o json
    Copy to Clipboard
  • サービス URL のみを出力します。

    $ kn service describe <service_name> -o url
    Copy to Clipboard

1.2. オフラインモードの kn サービスコマンド

1.2.1. Knative CLI オフラインモードについて

kn service コマンドを実行すると、変更が即座にクラスターに伝播されます。ただし、別の方法として、オフラインモードで kn service コマンドを実行できます。オフラインモードでサービスを作成すると、クラスター上で変更は発生せず、代わりにサービス記述子ファイルがローカルマシンに作成されます。

重要

Knative CLI のオフラインモードはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

記述子ファイルの作成後、手動で変更し、バージョン管理システムで追跡できます。記述子ファイルで kn service create -fkn 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 がインストールされている。

手順

  1. オフラインモードでは、ローカルの Knative サービス記述子ファイルを作成します。

    $ kn service create showcase \
        --image quay.io/openshift-knative/showcase \
        --target ./ \
        --namespace test
    Copy to Clipboard

    出力例

    Service 'showcase' created in namespace 'test'.
    Copy to Clipboard

    • --target ./ フラグはオフラインモードを有効にし、./ を新しいディレクトリーツリーを保存するディレクトリーとして指定します。

      既存のディレクトリーを指定せずに、--target my-service.yaml などのファイル名を使用すると、ディレクトリーツリーは作成されません。代わりに、サービス記述子ファイル my-service.yaml のみが現在のディレクトリーに作成されます。

      ファイル名には、.yaml.yml または .json 拡張子を使用できます。.json を選択すると、JSON 形式でサービス記述子ファイルが作成されます。

    • --namespace test オプションは、新規サービスを テスト namespace に配置します。

      --namespace を使用せずに OpenShift Container Platform クラスターにログインしていると、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルが default の namespace に作成されます。

  2. 作成したディレクトリー構造を確認します。

    $ tree ./
    Copy to Clipboard

    出力例

    ./
    └── test
        └── ksvc
            └── showcase.yaml
    
    2 directories, 1 file
    Copy to Clipboard

    • --target で指定する現在の ./ ディレクトリーには新しい test/ ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。
    • test/ ディレクトリーには、リソースタイプの名前が付けられた ksvc ディレクトリーが含まれます。
    • ksvc ディレクトリーには、指定のサービス名に従って名前が付けられる記述子ファイル showcase.yaml が含まれます。
  3. 生成されたサービス記述子ファイルを確認します。

    $ cat test/ksvc/showcase.yaml
    Copy to Clipboard

    出力例

    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

  4. 新しいサービスに関する情報をリスト表示します。

    $ kn service describe showcase --target ./ --namespace test
    Copy to Clipboard

    出力例

    Name:       showcase
    Namespace:  test
    Age:
    URL:
    
    Revisions:
    
    Conditions:
      OK TYPE    AGE REASON
    Copy to Clipboard

    • --target ./ オプションは、namespace サブディレクトリーを含むディレクトリー構造のルートディレクトリーを指定します。

      または、--target オプションで YAML または JSON ファイルを直接指定できます。使用可能なファイルの拡張子は、.yaml.yml、および .json です。

    • --namespace オプションは、namespace を指定し、この namespace は必要なサービス記述子ファイルを含むサブディレクトリーの kn と通信します。

      --namespace を使用せず、OpenShift Container Platform クラスターにログインしている場合、kn は現在の namespace にちなんで名付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kndefault/ サブディレクトリーで検索します。

  5. サービス記述子ファイルを使用してクラスターでサービスを作成します。

    $ kn service create -f test/ksvc/showcase.yaml
    Copy to Clipboard

    出力例

    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

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>
    Copy to Clipboard

    コマンドの例

    $ kn container add sidecar --image docker.io/example/sidecar
    Copy to Clipboard

    出力例

    containers:
    - image: docker.io/example/sidecar
      name: sidecar
      resources: {}
    Copy to Clipboard

  • 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 -
    Copy to Clipboard

    --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 -
    Copy to Clipboard

    --extra-containers フラグは YAML ファイルへのパスを受け入れることもできます。

    $ kn service create <service_name> --image <image_uri> --extra-containers <filename>
    Copy to Clipboard

    コマンドの例

    $ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml
    Copy to Clipboard

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>
    Copy to Clipboard

    コマンドの例

    $ kn domain create example.com --ref showcase
    Copy to Clipboard

    --ref フラグは、ドメインマッピング用のアドレス指定可能なターゲット CR を指定します。

    --ref フラグの使用時に接頭辞が指定されていない場合は、ターゲットが現在の namespace の Knative サービスであることを前提としています。

  • ドメインを指定された namespace の Knative サービスにマップします。

    $ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>
    Copy to Clipboard

    コマンドの例

    $ kn domain create example.com --ref ksvc:showcase:example-namespace
    Copy to Clipboard

  • ドメインを Knative ルートにマップします。

    $ kn domain create <domain_mapping_name> --ref <kroute:route_name>
    Copy to Clipboard

    コマンドの例

    $ kn domain create example.com --ref kroute:example-route
    Copy to Clipboard

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>
    Copy to Clipboard
  • 既存の DomainMapping CR の詳細を表示します。

    $ kn domain describe <domain_mapping_name>
    Copy to Clipboard
  • 新規ターゲットを参照するように DomainMapping CR を更新します。

    $ kn domain update --ref <target>
    Copy to Clipboard
  • DomainMapping CR を削除します。

    $ kn domain delete <domain_mapping_name>
    Copy to Clipboard

第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 
1

  directory: ~/.config/kn/plugins 
2

eventing:
  sink-mappings: 
3

  - prefix: svc 
4

    group: core 
5

    version: v1 
6

    resource: services 
7
Copy to Clipboard

1
Knative (kn) CLI が PATH 環境変数でプラグインを検索するかどうかを指定します。これはブール型の設定オプションです。デフォルト値は false です。
2
Knative (kn) CLI がプラグインを検索するディレクトリーを指定します。前述のように、デフォルトのパスはオペレーティングシステムによって異なります。これには、ユーザーに表示される任意のディレクトリーを指定できます。
3
sink-mappings 仕様は、Knative (kn) CLI コマンドで --sink フラグを使用する場合に使用される Kubernetes のアドレス可能なリソースを定義します。
4
シンクの記述に使用する接頭辞。サービスの svcchannel、および 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>
    Copy to Clipboard

    ここでは、以下のようになります。

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

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

      簡単なイベントのビルド

      $ kn event build -o yaml
      Copy to Clipboard

      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
      Copy to Clipboard

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

      $ 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

      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="
        }
      }
      Copy to Clipboard

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>
    Copy to Clipboard

    ここでは、以下のようになります。

    • --field フラグは、データをフィールド/値のペアとしてイベントに追加します。これは複数回使用できます。
    • --type フラグを使用すると、イベントのタイプを指定する文字列を指定できます。
    • --id フラグは、イベントの ID を指定します。
    • - to フラグは、イベントの宛先を指定します。
    • --namespace フラグは namespace を指定します。省略すると、namespace は現在のコンテキストから取得されます。

      宛先の仕様を除き、これらのフラグはすべてオプションです。

注記

the- to フラグには、以下の宛先形式を 使用できます。

  • --to broker:<broker>: ブローカーを指定します。
  • --to channel:<channel>: チャネルを指定します。
  • --to ksvc:&lt ;service&gt; または <service>: 現在の namespace に Knative サービスを指定します。
  • --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/
Copy to Clipboard

インクラスターリソースへの送信およびイベント

$ kn event send \
    --type org.example.kn.ping \
    --id $(uuidgen) \
    --field event.type=test \
    --field event.data=98765 \
    --to ksvc:event-display
Copy to Clipboard

第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 がインストールされている。

手順

  1. ターミナルに利用可能なイベントソースタイプをリスト表示します。

    $ kn source list-types
    Copy to Clipboard

    出力例

    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

  2. オプション: OpenShift Container Platform では、利用可能なイベントソースタイプを YAML 形式でリストすることもできます。

    $ kn source list-types -o yaml
    Copy to Clipboard

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 \ 
1

  --ce-override "sink=bound"
Copy to Clipboard

1
http://event-display.svc.cluster.localsvc は、シンクが 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>
Copy to Clipboard

コンテナーソースの削除

$ kn source container delete <container_source_name>
Copy to Clipboard

コンテナーソースの記述

$ kn source container describe <container_source_name>
Copy to Clipboard

既存のコンテナーソースをリスト表示

$ kn source container list
Copy to Clipboard

既存のコンテナーソースを YAML 形式でリスト表示

$ kn source container list -o yaml
Copy to Clipboard

コンテナーソースの更新

このコマンドにより、既存のコンテナーソースのイメージ URI が更新されます。

$ kn source container update <container_source_name> --image <image_uri>
Copy to Clipboard

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 リソースを変更して、新規リソースを作成せずに、必要なパーミッションを含めることができます。

  1. イベントソースのサービスアカウント、ロールおよびロールバインディングを YAML ファイルとして作成します。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 
    1
    
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 
    2
    
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 
    3
    
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 
    4
    Copy to Clipboard
    1 2 3 4
    この namespace を、イベントソースのインストールに選択した namespace に変更します。
  2. YAML ファイルを適用します。

    $ oc apply -f <filename>
    Copy to Clipboard
  3. イベントシンクを持つ API サーバーソースを作成します。次の例では、シンクはブローカーです。

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
    Copy to Clipboard
  4. API サーバーソースが正しく設定されていることを確認するには、受信メッセージをログにダンプする Knative サービスを作成します。

    $ kn service create event-display --image quay.io/openshift-knative/showcase
    Copy to Clipboard
  5. ブローカーをイベントシンクとして使用した場合は、トリガーを作成して、default のブローカーからサービスへのイベントをフィルタリングします。

    $ kn trigger create <trigger_name> --sink ksvc:event-display
    Copy to Clipboard
  6. デフォルト namespace で Pod を起動してイベントを作成します。

    $ oc create deployment event-origin --image quay.io/openshift-knative/showcase
    Copy to Clipboard
  7. 以下のコマンドを入力し、生成される出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ kn source apiserver describe <source_name>
    Copy to Clipboard

    出力例

    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

検証

Kubernetes イベントが Knative に送信されたことを確認するには、イベント表示ログを確認するか、Web ブラウザーを使用してイベントを確認します。

  • Web ブラウザーでイベントを表示するには、次のコマンドで返されたリンクを開きます。

    $ kn service describe event-display -o url
    Copy to Clipboard

    図4.1 ブラウザーページの例

    ApiServerSource イベントの視覚化の例
  • あるいは、ターミナルでログを確認するには、次のコマンドを入力して Pod のイベント表示ログを表示します。

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

    出力例

    ☁️  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

API サーバーソースの削除

  1. トリガーを削除します。

    $ kn trigger delete <trigger_name>
    Copy to Clipboard
  2. イベントソースを削除します。

    $ kn source apiserver delete <source_name>
    Copy to Clipboard
  3. サービスアカウント、クラスターロール、およびクラスターバインディングを削除します。

    $ oc delete -f authentication.yaml
    Copy to Clipboard

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) がインストールされている。

手順

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

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

    $ kn source ping create test-ping-source \
        --schedule "*/2 * * * *" \
        --data '{"message": "Hello world!"}' \
        --sink ksvc:event-display
    Copy to Clipboard
  3. 以下のコマンドを入力し、出力を検査して、コントローラーが正しくマップされていることを確認します。

    $ kn source ping describe test-ping-source
    Copy to Clipboard

    出力例

    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

検証

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

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

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

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

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

    出力例

    ☁️  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

ping ソースの削除

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

    $ kn delete pingsources.sources.knative.dev <ping_source_name>
    Copy to Clipboard

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) をインストールしている。

手順

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

    $ kn service create event-display \
        --image quay.io/openshift-knative/showcase
    Copy to Clipboard
  2. KafkaSource CR を作成します。

    $ kn source kafka create <kafka_source_name> \
        --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \
        --topics <topic_name> --consumergroup my-consumer-group \
        --sink event-display
    Copy to Clipboard
    注記

    このコマンドのプレースホルダー値は、ソース名、ブートストラップサーバー、およびトピックの値に置き換えます。

    --servers--topics、および --consumergroup オプションは、Kafka クラスターへの接続パラメーターを指定します。--consumergroup オプションは任意です。

  3. オプション: 作成した KafkaSource CR の詳細を表示します。

    $ kn source kafka describe <kafka_source_name>
    Copy to Clipboard

    出力例

    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

検証手順

  1. Kafka インスタンスをトリガーし、メッセージをトピックに送信します。

    $ oc -n kafka run kafka-producer \
        -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \
        --restart=Never -- bin/kafka-console-producer.sh \
        --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
    Copy to Clipboard

    プロンプトにメッセージを入力します。このコマンドは、以下を前提とします。

    • Kafka クラスターが kafka namespace にインストールされている。
    • KafkaSource オブジェクトが my-topic トピックを使用するように設定されている。
  2. ログを表示して、メッセージが到達していることを確認します。

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

    出力例

    ☁️  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

第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>
    Copy to Clipboard
    • 受け入れられるランタイム値には、quarkusnodetypescriptgopythonspringboot、および rust が含まれます。
    • 受け入れられるテンプレート値には、httpcloudevents が含まれます。

      コマンドの例

      $ kn func create -l typescript -t cloudevents examplefunc
      Copy to Clipboard

      出力例

      Created typescript function in /home/user/demo/examplefunc
      Copy to Clipboard

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

      コマンドの例

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

      出力例

      Created node function in /home/user/demo/examplefunc
      Copy to Clipboard

5.1.2. 関数のローカルでの実行

kn func run コマンドを使用すると、現在のディレクトリーまたは --path フラグで指定されたディレクトリーで関数をローカルに実行できます。実行している関数が以前にビルドされたことがない場合、またはプロジェクトファイルが最後にビルドされてから変更されている場合、kn func run コマンドは、デフォルトで関数を実行する前に関数をビルドします。

現在のディレクトリーで関数を実行するコマンドの例

$ kn func run
Copy to Clipboard

パスとして指定されたディレクトリー内の関数を実行するコマンドの例

$ kn func run --path=<directory_path>
Copy to Clipboard

プロジェクトファイルに変更がない場合でも、--build フラグを使用して、関数を実行する前に既存のイメージを強制的に再構築することもできます。

ビルドフラグを使用した実行コマンドの例

$ kn func run --build
Copy to Clipboard

build フラグを false に設定すると、イメージのビルドが無効になり、以前にビルドされたイメージを使用して関数が実行します。

ビルドフラグを使用した実行コマンドの例

$ kn func run --build=false
Copy to Clipboard

help コマンドを使用して、kn func run コマンドオプションの詳細を確認できます。

help コマンドのビルド

$ kn func help run
Copy to Clipboard

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
Copy to Clipboard

5.1.3.2. イメージレジストリーの種類

OpenShift Container Registry は、関数イメージを保存するためのイメージレジストリーとしてデフォルトで使用されます。

OpenShift Container Registry を使用したビルドコマンドの例

$ kn func build
Copy to Clipboard

出力例

Building function image
Function image has been built, image: registry.redhat.io/example/example-function:latest
Copy to Clipboard

--registry フラグを使用して、OpenShift Container Registry をデフォルトのイメージレジストリーとして使用することをオーバーライドできます。

quay.io を使用するように OpenShift Container Registry をオーバーライドするビルドコマンドの例

$ kn func build --registry quay.io/username
Copy to Clipboard

出力例

Building function image
Function image has been built, image: quay.io/username/example-function:latest
Copy to Clipboard

5.1.3.3. Push フラグ

--push フラグを kn func build コマンドに追加して、正常にビルドされた後に関数イメージを自動的にプッシュできます。

OpenShift Container Registry を使用したビルドコマンドの例

$ kn func build --push
Copy to Clipboard

5.1.3.4. Help コマンド

kn func build コマンドオプションの詳細は、help コマンドを使用できます。

help コマンドのビルド

$ kn func help build
Copy to Clipboard

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>]
    Copy to Clipboard

    出力例

    Function deployed at: http://func.example.com
    Copy to Clipboard

    • 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>]
    Copy to Clipboard

    出力例

    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

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

    $ kn service list -n <namespace>
    Copy to Clipboard

    出力例

    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

5.1.6. 関数の記述

kn func info コマンドは、関数名、イメージ、namespace、Knative サービス情報、ルート情報、イベントサブスクリプションなどのデプロイされた関数に関する情報を出力します。

手順

  • 関数を説明します。

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

    コマンドの例

    $ kn func info -p function/example-function
    Copy to Clipboard

    出力例

    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

5.1.7. テストイベントでのデプロイされた関数の呼び出し

kn func invoke CLI コマンドを使用して、ローカルまたは OpenShift Container Platform クラスター上で関数を呼び出すためのテストリクエストを送信できます。このコマンドを使用して、関数が機能し、イベントを正しく受信できることをテストできます。関数をローカルで呼び出すと、関数開発中の簡単なテストに役立ちます。クラスターで関数を呼び出すと、実稼働環境に近いテストに役立ちます。

前提条件

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

手順

  • 関数を呼び出します。

    $ kn func invoke
    Copy to Clipboard
    • kn func invoke コマンドは、ローカルのコンテナーイメージが実行中の場合や、クラスターにデプロイされた関数がある場合にのみ機能します。
    • kn func invoke コマンドは、デフォルトでローカルディレクトリーで実行され、このディレクトリーが関数プロジェクトであると想定します。
5.1.7.1. kn func はオプションのパラメーターを呼び出します

次の kn func invoke CLI コマンドフラグを使用して、リクエストのオプションパラメーターを指定できます。

フラグ説明

-t--target

呼び出された関数のターゲットインスタンスを指定します。たとえば、localremotehttps://staging.example.com/ などです。デフォルトのターゲットは local です。

-f-format

メッセージの形式を指定します (例: cloudevent または http)。

--id

リクエストの一意の文字列識別子を指定します。

-n-namespace

クラスターの namespace を指定します。

--source

リクエストの送信者名を指定します。これは、CloudEvent source 属性に対応します。

--type

リクエストのタイプを指定します (例: boson.fn)。これは、CloudEvent type 属性に対応します。

--data

リクエストの内容を指定します。CloudEvent リクエストの場合、これは CloudEvent data 属性です。

--file

送信するデータを含むローカルファイルへのパスを指定します。

--content-type

リクエストの MIME コンテンツタイプを指定します。

-p--path

プロジェクトディレクトリーへのパスを指定します。

-c--confirm

すべてのオプションを対話的に確認するように要求を有効にします。

-v, --verbose

詳細出力の出力を有効にします。

-h--help

kn func invoke の使用法に関する情報を出力します。

5.1.7.1.1. 主なパラメーター

次のパラメーターは、kn func invoke コマンドの主なプロパティーを定義します。

イベントターゲット (-t-target)
呼び出された関数のターゲットインスタンス。ローカルにデプロイされた関数の local 値、リモートにデプロイされた関数の remote 値、または任意のエンドポイントにデプロイされた関数の URL を受け入れます。ターゲットが指定されていない場合は、デフォルトで local になります。
イベントメッセージ形式 (-f--format)
httpcloudevent などのイベントのメッセージ形式。これは、デフォルトで、関数の作成時に使用されたテンプレートの形式になります。
イベントタイプ (--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>
Copy to Clipboard

たとえば、"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
Copy to Clipboard
5.1.7.1.2.1. データを使用したファイルの指定

イベントデータが含まれるディスクにファイルを指定するには、--file フラグおよび --content-type フラグを使用します。

$ kn func invoke --file <path> --content-type <content-type>
Copy to Clipboard

たとえば、test.json ファイルに保存されている JSON データを送信するには、以下のコマンドを使用します。

$ kn func invoke --file ./test.json --content-type application/json
Copy to Clipboard
5.1.7.1.2.2. 関数プロジェクトの指定

--path フラグを使用して、関数プロジェクトへのパスを指定できます。

$ kn func invoke --path <path_to_function>
Copy to Clipboard

たとえば、./example/example- function ディレクトリーにある function プロジェクトを使用するには、以下のコマンドを使用します。

$ kn func invoke --path ./example/example-function
Copy to Clipboard
5.1.7.1.2.3. ターゲット関数がデプロイされる場所の指定

デフォルトでは、kn func invoke は関数のローカルデプロイメントをターゲットにします。

$ kn func invoke
Copy to Clipboard

別のデプロイメントを使用するには、--target フラグを使用します。

$ kn func invoke --target <target>
Copy to Clipboard

たとえば、クラスターにデプロイされた関数を使用するには、-target remote フラグを使用します。

$ kn func invoke --target remote
Copy to Clipboard

任意の URL にデプロイされた関数を使用するには、-target <URL> フラグを使用します。

$ kn func invoke --target "https://my-event-broker.example.com"
Copy to Clipboard

ローカルデプロイメントを明示的にターゲットとして指定できます。この場合、関数がローカルで実行されていないと、コマンドは失敗します。

$ kn func invoke --target local
Copy to Clipboard

5.1.8. 関数の削除

kn func delete コマンドを使用して関数を削除できます。これは、関数が不要になった場合に役立ち、クラスターのリソースを節約するのに役立ちます。

手順

  • 関数を削除します。

    $ kn func delete [<function_name> -n <namespace> -p <path>]
    Copy to Clipboard
    • 削除する関数の名前またはパスが指定されていない場合は、現在のディレクトリーで func.yaml ファイルを検索し、削除する関数を判断します。
    • namespace が指定されていない場合は、func.yamlnamespace の値にデフォルト設定されます。

法律上の通知

Copyright © 2025 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.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat