第9章 Knative Serving

9.1. kn の使用による Serving タスクの実行

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

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

以下の基本的なワークフローでは、環境変数 RESPONSE を読み取る単純な hello サービスをデプロイし、その出力を印刷します。

本書は、サービスでの作成、読み取り、更新、削除 (CRUD) 操作を実行する際の参照情報として使用できます。

手順

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

    $ kn service create hello --image docker.io/openshift/hello-openshift --env RESPONSE="Hello Serverless!"
    Creating service 'hello' in namespace 'default':

  0.085s The Route is still working to reflect the latest desired specification.
  0.101s Configuration "hello" is waiting for a Revision to become ready.
 11.590s ...
 11.650s Ingress has not yet been reconciled.
 11.726s Ready to serve.

Service 'hello' created with latest revision 'hello-gsdks-1' and URL:
http://hello-default.apps-crc.testing

  2. サービスを一覧表示します。 

    $ kn service list
    NAME    URL                                     LATEST          AGE     CONDITIONS   READY   REASON
hello   http://hello-default.apps-crc.testing   hello-gsdks-1   8m35s   3 OK / 3     True

  3. curl サービスエンドポイントコマンドを使用して、サービスが機能しているかどうかを確認します。 

    $ curl http://hello-default.apps-crc.testing
    Hello Serverless!

  4. サービスを更新します。 

    $ kn service update hello --env RESPONSE="Hello OpenShift!"
    Updating Service 'hello' in namespace 'default':

 10.136s Traffic is not yet migrated to the latest revision.
 10.175s Ingress has not yet been reconciled.
 10.348s Ready to serve.

Service 'hello' updated with latest revision 'hello-dghll-2' and URL:
http://hello-default.apps-crc.testing

    サービスの環境変数 RESPONSE は「Hello OpenShift!」に設定されるようになりました。

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

    $ kn service describe hello
    Name:       hello
Namespace:  default
Age:        13m
URL:        http://hello-default.apps-crc.testing

Revisions:
  100%  @latest (hello-dghll-2) [2] (1m)
        Image:  docker.io/openshift/hello-openshift (pinned to 5ea96b)

Conditions:
  OK TYPE                   AGE REASON
  ++ Ready                   1m
  ++ ConfigurationsReady     1m
  ++ RoutesReady             1m

  6. サービスを削除します。 

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

  7. hello サービスに対して list を試行し、これが削除されていることを確認しまう。 

    $ kn service list hello
    No services found.

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

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

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

フラグ説明

--concurrency-limit int

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

--concurrency-target int

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

--max-scale int

レプリカの最大数。

--min-scale int

レプリカの最小数。

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

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

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

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

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

手順

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

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

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

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

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

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

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

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

注記

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

手順

  • コマンドを入力します。 

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

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

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

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

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

注記

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

手順

  • タグの割り当てを解除します。 

    $ kn service update svc --untag candidate
注記

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

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

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

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

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

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

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

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

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

フラグ値操作繰り返し

--traffic

RevisionName=Percent

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

Yes

--traffic

Tag=Percent

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

Yes

--traffic

@latest=Percent

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

No

--tag

RevisionName=Tag

Tag を RevisionName に指定します。

Yes

--tag

@ latest = Tag

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

No

--untag

Tag

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

Yes