Knative CLI

前提条件

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

手順

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

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

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

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

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

    コマンドの例

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

    出力例

    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

コマンドの例

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

  $ kn service update <service_name> --env <key>=<value>

• 新しいポートを追加してサービスを更新します。

  $ kn service update <service_name> --port 80

• 新しい要求および制限パラメーターを追加してサービスを更新します。

  $ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m

• latest タグをリビジョンに割り当てます。

  $ kn service update <service_name> --tag <revision_name>=latest

• サービスの最新の READY リビジョンについて、testing から staging にタグを更新します。

  $ kn service update <service_name> --untag testing --tag @latest=staging

• test タグをトラフィックの 10% を受信するリビジョンに追加し、残りのトラフィックをサービスの最新の READY リビジョンに送信します。

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

コマンドの例

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

  $ kn service apply <service_name> --image <image>

• 環境変数をサービスに追加します。

  $ kn service apply <service_name> --image <image> --env <key>=<value>

• JSON または YAML ファイルからサービス宣言を読み取ります。

  $ kn service apply <service_name> -f <filename>

コマンドの例

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

  $ kn service describe --verbose <service_name>

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

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

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

  $ kn service describe <service_name> -o yaml

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

  $ kn service describe <service_name> -o json

• サービス URL のみを出力します。

  $ kn service describe <service_name> -o url

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

前提条件

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

• イメージからコンテナーを追加し、標準出力に出力します。

  $ kn container add <container_name> --image <image_uri>

  コマンドの例

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

  出力例

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

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

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

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

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

  コマンドの例

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

前提条件

• 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 example.com --ref showcase

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

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

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

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

  コマンドの例

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

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

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

  コマンドの例

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

前提条件

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

手順

• 既存の DomainMapping CR をリスト表示します。

  $ kn domain list -n <domain_mapping_namespace>

• 既存の DomainMapping CR の詳細を表示します。

  $ kn domain describe <domain_mapping_name>

• 新規ターゲットを参照するように DomainMapping CR を更新します。

  $ kn domain update --ref <target>

• DomainMapping CR を削除します。

  $ kn domain delete <domain_mapping_name>

前提条件

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

前提条件

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

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

  $ kn service describe event-display -o url

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

  

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

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

  出力例

  ☁️  cloudevents.Event
  Validation: valid
  Context Attributes,
    specversion: 1.0
    type: dev.knative.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",
      ...
    }

前提条件

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

ping ソースの削除

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

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

前提条件

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

前提条件

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

手順

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

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

  • 受け入れられるランタイム値には、quarkus、node、typescript、go、python、springboot、および rust が含まれます。

  • 受け入れられるテンプレート値には、http と cloudevents が含まれます。

    コマンドの例

    $ kn func create -l typescript -t cloudevents examplefunc

    出力例

    Created typescript function in /home/user/demo/examplefunc

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

    コマンドの例

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

    出力例

    Created node function in /home/user/demo/examplefunc

前提条件

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

手順

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

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

  出力例

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

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

手順

• 既存の関数をリスト表示します。

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

  出力例

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

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

  $ kn service list -n <namespace>

  出力例

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

手順

• 関数を説明します。

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

  コマンドの例

  $ kn func info -p function/example-function

  出力例

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

前提条件

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

手順

• 関数を呼び出します。

  $ kn func invoke

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

手順

• 関数を削除します。

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

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