HTTPリクエストフロー¶

概要では論理コンポーネントが説明されており、アーキテクチャではKnative Serving全体のアーキテクチャが説明されていますが、このページではKnative Serving上で実行されているアプリケーションへのHTTPリクエストの動作とフローについて説明します。

次の図は、Knative Servingのさまざまなリクエストフローとコントロールプレーンループを示しています。オートスケーラーやAPIサーバーなどの一部のコンポーネントは、すべてのリクエストで更新されるのではなく、定期的にシステムを測定することに注意してください（これはコントロールプレーンと呼ばれます）。

Diagram of Knative request flow through HTTP router to optional Activator, then queue-proxy and user container

HTTPルーター、アクティベーター、オートスケーラーはすべて、クラスターレベルで共有されるリソースです。これにより、Knativeサービスが使用されていない場合のオーバーヘッドをメタデータのみに減らし、これらの共有コンポーネントのより効率的な管理とアップグレードが可能になります。

ルーティングの決定は、HTTPルーター（プラガブルなイングレスレイヤー）でリクエストごとに1回行われ、内部ヘッダーのリクエストに記録されます。リクエストがリビジョンに割り当てられると、後続のルーティングは測定されたトラフィックフローに依存します。トラフィックが少ないまたはゼロの場合、着信リクエストはアクティベーターにルーティングされます。トラフィックレベルが高い場合（予備容量がtarget-burst-capacityより大きい場合）、トラフィックはアプリケーションポッドに直接ルーティングされます。

ゼロからのスケール¶

特定のリビジョンへのトラフィックが少ないまたはゼロの場合、HTTPルーターは選択されたリビジョンを示すヘッダーを含め、トラフィックをアクティベーターに送信します。アクティベーターは、着信リクエストのバッファーまたはキューとして機能します。リクエストが現在利用可能な容量がないリビジョンにルーティングされる場合、アクティベーターはリクエストを遅延させ、追加の容量が必要であることをオートスケーラーに通知します。

オートスケーラーは、リビジョンの利用可能な容量が要求された容量を下回っていることを検出すると、Kubernetesから要求されたポッド数を増やします。

これらの新しいポッドの準備が整うか、既存のポッドに容量がある場合、アクティベーターは遅延されたリクエストを準備完了のポッドに転送します。リクエストを処理するために新しいポッドを開始する必要がある場合、これは*コールドスタート*と呼ばれます。

高スケール¶

リビジョンのトラフィックが多い場合（予備容量がtarget-burst-capacityより大きい場合）、イングレスルーターにはリビジョンのポッドアドレスが直接プログラムされ、トラフィックフローからアクティベーターが削除されます。これにより、アクティベーターの追加バッファリングが不要な場合に、レイテンシーが減少し、効率が向上します。すべての場合において、queue-proxyはリクエストパスに残ります。

トラフィックがバースト容量のしきい値（current_demand + target-burst-capacity > (pods * concurrency-target)として計算）を下回った場合、イングレスルーターは、トラフィックをアクティベーターポッドに送信するように再プログラムされます。

イングレスとアクティベーター間のトラフィックのルーティングは、リビジョンのサービスのエンドポイントにアクティベーターエンドポイントのサブセットを書き込むことによって行われます。リビジョンに対応するKubernetesサービスはセレクターなしであり、リビジョンのポッドエンドポイントまたはアクティベーターエンドポイントのいずれかを含めることができます。セレクターなしのサービスを使用する理由は次のとおりです。

一部のイングレス実装では、クロスネームスペースサービス参照が許可されていません。アクティベーターはknative-servingネームスペースで実行されます。
一部のイングレス実装では、ルーティングエンドポイントのバッキングKubernetesサービスをシームレスに変更することを処理しません。
リビジョンごとにサブセットを使用することにより、着信リクエストは、準備完了/準備未完了の容量の決定をより効率的に行うことができる少数のアクティベーターに絞られます。リビジョンごとの有効なアクティベーターの数が少ないことは、リビジョンがより多くのトラフィックを受信するようにスケールアップするとリクエストパスからアクティベーターが削除されるため、スケーリングの問題ではありません。

Queue-Proxy¶

queue-proxyコンポーネントは、Knativeの信頼性とスケーリングを向上させるための多くの機能を実装しています。

特にアクティベーターがリクエストパスから削除された場合に、オートスケーラーの同時リクエストを測定します。
要求された場合は、リクエスト同時実行に関するcontainerConcurrencyハードリミットを実装します。
ポッドの終了時に正常なシャットダウンを処理します（新しいリクエストを拒否し、準備状況チェックを失敗させ、既存のリクエストの処理を続行します）。
インフラストラクチャのレイテンシーの寄与を測定できるように、ユーザーコンテナのすぐ外側からHTTPメトリクスとトレースを報告します。
起動中（準備完了前）、Kubeletプローブ（1秒に最大1回プローブ可能）よりも早期のサービスを可能にするために、ユーザーコンテナをより積極的にプローブします。
この機能をサポートするために、Knative ServingはユーザーコンテナのreadinessProbeをqueue-proxyへの引数に書き換えます。queue-proxyの準備状況チェックには、queue-proxy自身の準備状況とユーザーコンテナの両方が組み込まれています。