第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) 操作を実行する際の参照情報として使用できます。
手順
イメージからサービスを
デフォルト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
サービスを一覧表示します。
$ 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
curlサービスエンドポイントコマンドを使用して、サービスが機能しているかどうかを確認します。$ curl http://hello-default.apps-crc.testing
Hello Serverless!
サービスを更新します。
$ 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!」に設定されるようになりました。サービスを記述します。
$ 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サービスを削除します。
$ kn service delete hello
Service 'hello' successfully deleted in namespace 'default'.
helloサービスに対してlistを試行し、これが削除されていることを確認しまう。$ kn service list hello
No services found.
9.1.2. kn を使用した自動スケーリングのワークフロー
YAML ファイルを直接編集せずに kn を使用して Knative サービスを変更することで、自動スケーリング機能にアクセスできます。
適切なフラグと共に service create および service update コマンドを使用して、自動スケーリング動作を設定します。
| フラグ | 説明 |
|---|---|
|
| 単一レプリカによって処理される同時要求のハード制限。 |
|
|
受信する同時要求の数に基づくスケールアップのタイミングの推奨。デフォルトは |
|
| レプリカの最大数。 |
|
| レプリカの最小数。 |
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 で評価されるフラグの優先順位は以下のとおりです。
-
--untag: このフラグで参照されるすべてのリビジョンはトラフィックブロックから削除されます。 -
--tag: リビジョンはトラフィックブロックで指定されるようにタグ付けされます。 -
--traffic: 参照されるリビジョンには、分割されたトラフィックの一部が割り当てられます。
9.1.3.4. トラフィック分割フラグ
kn は kn service update コマンドの一環として、サービスのトラフィックブロックでのトラフィック操作に対応します。
以下の表は、トラフィック分割フラグ、値の形式、およびフラグが実行する操作の概要を表示しています。「繰り返し」列は、フラグの特定の値が kn service update コマンドで許可されるかどうかを示します。
| フラグ | 値 | 操作 | 繰り返し |
|---|---|---|---|
|
|
|
| Yes |
|
|
|
| Yes |
|
|
|
| No |
|
|
|
| Yes |
|
|
|
| No |
|
|
|
リビジョンから | Yes |
