技術情報: 最も人気のあるオープンソースのサーバーレス フレームワークのエラスティック テクノロジの実装を解読します。

著者: ユアン・イー

Knative は、Kubernetes に基づいたオープン ソースのサーバーレス アプリケーション オーケストレーション フレームワークであり、その目標は、クラウドネイティブでクロスプラットフォームのサーバーレス アプリケーション オーケストレーション標準を開発することです。Knative の主な機能には、リクエストベースの自動弾力性、0 への縮小、マルチバージョン管理、トラフィックベースのグレースケールリリース、イベント駆動などが含まれます。

弾力性はサーバーレスの中核機能です。では、CNCF コミュニティで最も人気のあるオープンソースのサーバーレス アプリケーション フレームワークである Knative は、どのような独自の弾力性機能を提供するのでしょうか? この記事では、Knative の柔軟な実装について詳しく理解できます。(注: この記事は Knative 1.8.0 バージョンに基づいて分析しています)

Knative はリクエストベースの自動エラスティック実装 KPA (Knative Pod Autoscaler) を提供し、K8s では HPA もサポートしており、さらに Knative は独自のビジネス ニーズに基づいてエラスティック実装を拡張できる柔軟なエラスティック拡張メカニズムを提供します。ここでは、正確な弾性を実現する MSE との組み合わせ、およびリクエストベースの弾性予測を実現する AHPA との組み合わせについても紹介します。

まず、Knative の最も魅力的なネイティブの柔軟性である KPA を紹介します。

リクエストベースの自動エラスティック KPA

CPU またはメモリに基づく弾力性は、ビジネスの実際の使用状況を完全に反映していない場合がありますが、Web サービスの同時実行数または 1 秒あたりに処理されるリクエスト数 (QPS/RPS) に基づいて、より直接的に反映できます。 Knative は、リクエストベースの自動復元機能を提供します。現在のサービス リクエスト数を取得するために、Knative Serving は各ポッドに QUEUE プロキシ コンテナ (キュー プロキシ) を挿入します。このコンテナは、ユーザー コンテナの同時実行性 (concurrency) またはリクエスト カウント (rps) インジケーターの収集を担当します。Autoscaler はこれらのインジケーターを定期的に取得した後、対応するアルゴリズムに従ってデプロイメント内のポッドの数を調整し、リクエストに基づいて自動拡張および縮小を実現します。

画像ソース: https://knative.dev/docs/serving/request-flow/

リクエスト数に基づく弾力性アルゴリズム

Autoscaler は、各 Pod の平均リクエスト数 (または同時実行数) に基づいて柔軟な計算を実行します。デフォルトでは、Knative は同時実行数に基づいた自動弾力性を使用し、同時実行 Pod のデフォルトの最大数は 100 です。さらに、Knative には、ターゲット使用率と呼ばれる target-utilization-percentage という概念も用意されており、値の範囲は 0 ～ 1 で、デフォルトは 0.7 です。

同時実行性に基づく弾力性を例にとると、ポッドの数は次のように計算されます。

POD数=并发请求总数/(Pod最大并发数*目标使用率)

たとえば、サービス内の同時ポッドの最大数は 10 に設定されます。この時点で、100 個の同時リクエストを受信し、ターゲット使用量が 0.7 に設定されている場合、オートスケーラーは 15 個の POD (100/(0.7*10) を作成します。 ) は 15) にほぼ等しい。

0までスケールダウンする実装メカニズム

KPA を使用すると、トラフィック リクエストがない場合は Pod の数が自動的に 0 に減らされ、リクエストがある場合は Pod の数が 0 から拡張されます。では、Knative ではどのようにしてこれが起こるのでしょうか? 答えはモードの切り替えにあります。

Knative は、プロキシとサーブという 2 つのリクエスト アクセス モードを定義します。プロキシ 名前が示すように、プロキシ モード。つまり、リクエストはアクティベーター コンポーネントを介してプロキシによって転送されます。サーブ モードはダイレクト リクエスト モードで、アクティベータ プロキシを経由せずにゲートウェイから Pod に直接リクエストします。以下に示すように:

モードの切り替えはオートスケーラー コンポーネントによって実行され、リクエストが 0 の場合、オートスケーラーはリクエスト モードをプロキシ モードに切り替えます。このとき、リクエストはゲートウェイ経由でアクティベーター コンポーネントに送信されます。リクエストを受信した後、アクティベーターはリクエストをキューに入れ、インジケーターをプッシュしてオートスケーラーに拡張を通知します。アクティベーターが準備が完了したポッドを検出すると、拡張する場合は、リクエストを転送します。オートスケーラーは Ready Pod を決定し、モードを Serve モードに切り替えます。

バーストトラフィックに対処する

突然のトラフィック下でリソースを素早くバウンスする方法

KPA には、弾力性に関する 2 つの概念、Stable (安定モード) と Panic (パニック モード) が含まれており、これら 2 つのモードに基づいて、KPA がリクエストに基づいてどのように洗練された弾力性を実現できるかを理解できます。

まず、安定モードは安定ウィンドウ期間に基づいており、デフォルトでは 60 秒です。つまり、同時ポッドの平均数は 60 秒以内に計算されます。

パニック モードは、安定ウィンドウ期間とパニック ウィンドウ パーセンテージ パラメーターを通じて計算されるパニック ウィンドウ期間に基づいています。Panic-window-percentage の値は 0 ～ 1 で、デフォルトは 0.1 です。パニック ウィンドウ期間の計算方法は、パニック ウィンドウ期間 = 安定ウィンドウ期間 * パニック ウィンドウの割合です。デフォルトは 6 秒です。6 秒間の同時ポッドの平均数を計算します。

KPA は、安定モードとパニック モードでの同時ポッドの平均数に基づいて、必要なポッドの数を計算します。

では、弾性を有効にするために実際にどの値が使用されるのでしょうか? パニックモードで計算されたPod数がパニック閾値PanicThresholdを超えるかどうかで判定されます。パニックしきい値は、panic-threshold-percentage/100 で計算されます。panic-threshold-percentage パラメーターのデフォルトは 200 で、これはパニックしきい値のデフォルトが 2 であることを意味します。パニック モードで計算されたポッドの数が現在の準備完了ポッドの数の 2 倍以上の場合、パニック モードのポッドの数がエラスティック検証に使用され、それ以外の場合は安定モードのポッドの数が使用されます。

明らかに、パニック モードは突然の交通状況に対処するように設計されています。弾性感度に関しては、上記の構成可能なパラメータを通じて調整できます。

突然のトラフィックでポッドが爆発するのを防ぐ方法

バースト要求容量 (target-burst-capacity) は、予期しないトラフィックによって圧倒される Pod に対処するために KPA で設定できます。つまり、このパラメーター値の計算を通じて、リクエストをプロキシ モードに切り替えるかどうかを調整し、それによってアクティベーター コンポーネントをリクエスト バッファーとして使用することができます。現在の準備完了ポッドの数 * 同時実行の最大数 - バースト リクエストの容量 - パニック モードで計算された同時実行の数 < 0 の場合、バースト トラフィックが容量のしきい値を超えていることを意味し、リクエスト バッファリングのアクティベーターに切り替わります。バースト リクエストの容量値が 0 の場合、Pod が 0 に縮小した場合にのみアクティベーターが切り替えられます。0 より大きく、container-concurrency-target-percentage が 100 に設定されている場合、リクエストは常にアクティベータを通過します。-1 は、無制限のリクエスト バースト容量を示します。リクエストは常にアクティベータを経由します。

コールドスタートを減らすためのヒント

遅延スケーリング

起動コストが高い Pod の場合、KPA を使用して、Pod 遅延削減時間と Pod 削減を 0 保持期間に設定することで、Pod の拡張と縮小の頻度を減らすことができます。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-down-delay: ""60s"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

リソースをウォームアップするために目標使用率を下げる

ターゲットしきい値使用量の構成は Knative で提供されます。この値を小さくすることで、実際に必要な使用量を超えるPod数を事前に拡張することができ、リクエストが目標同時数に達する前に容量を拡張することができ、間接的にリソースをウォーミングアップすることができます。たとえば、containerConcurrency が 10 に設定され、ターゲット使用率の値が 70 (パーセンテージ) に設定されている場合、既存のすべての Pod の同時リクエストの平均数が 7 に達すると、オートスケーラーは新しい Pod を作成します。Pod は準備が完了するまでにある程度の時間がかかるため、目標使用率を下げることで事前に Pod を拡張することができ、コールドスタートによる応答遅延などの問題を軽減できます。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

KPAの構成

ここまでで Knative Pod Autoscaler の仕組みを理解できたので、次に KPA の設定方法を紹介します。Knative では、グローバル モードとリビジョン モードという 2 つの方法で KPA を構成できます。

グローバルモード

グローバル モードでは、K8s の ConfigMap を変更できます: config-autoscaler. config-autoscaler を表示するには、次のコマンドを使用します。

kubectl -n knative-serving get cm config-autoscaler

apiVersion: v1
kind: ConfigMap
metadata:
 name: config-autoscaler
 namespace: knative-serving
data:
 container-concurrency-target-default: "100"
 container-concurrency-target-percentage: "70"
 requests-per-second-target-default: "200"
 target-burst-capacity: "211"
 stable-window: "60s"
 panic-window-percentage: "10.0"
 panic-threshold-percentage: "200.0"
 max-scale-up-rate: "1000.0"
 max-scale-down-rate: "2.0"
 enable-scale-to-zero: "true"
 scale-to-zero-grace-period: "30s"
 scale-to-zero-pod-retention-period: "0s"
 pod-autoscaler-class: "kpa.autoscaling.knative.dev"
 activator-capacity: "100.0"
 initial-scale: "1"
 allow-zero-initial-scale: "false"
 min-scale: "0"
 max-scale: "0"
 scale-down-delay: "0s"

パラメータの説明:

パラメータ	説明する
コンテナ同時実行ターゲットのデフォルト	同時ポッドのデフォルトの最大数。デフォルト値は 100 です。
コンテナ同時実行ターゲットの割合	同時実行ターゲットの使用量、70 は実際には 0.7 を意味します
1 秒あたりのリクエスト数ターゲットのデフォルト	デフォルトの 1 秒あたりのリクエスト数 (rps)、デフォルト値は 200
ターゲットバースト容量	バーストリクエスト容量
安定したウィンドウ	安定ウィンドウ、デフォルトは 60 秒
パニックウィンドウの割合	パニック ウィンドウ率。デフォルト値は 10 です。これは、デフォルトのパニック ウィンドウ期間が 6 秒であることを意味します (60*0.1=6)。
パニックしきい値パーセンテージ	パニックしきい値比率、デフォルト値 200
最大スケールアップ率	最大伸縮率は一度に拡張できる最大数を表し、実際の計算方法は math.Ceil(MaxScaleUpRate * readyPodsCount) となります。
最大スケールダウン率	最大スケーリング レートは一度に行うスケーリングの最大数を表し、実際の計算方法は math.Floor(readyPodsCount / MaxScaleDownRate) です。デフォルト値 2 は、毎回半分に縮小することを意味します。
ゼロへのスケールを有効にする	0 への縮小を開始するかどうか (デフォルトで有効)
ゼロへのスケール猶予期間	0 に正常に縮小する時間、つまり 0 への縮小を遅らせるのにかかる時間。デフォルトは 30 秒です。
ゼロへのスケールポッド保持期間	ポッドの保持期間は 0 に短縮されます。このパラメーターは、ポッドの起動コストが高い状況に適しています。
ポッドオートスケーラークラス	Elastic プラグイン タイプ。現在サポートされている Elastic プラグインには、kpa、hpa、ahpa、mpa が含まれます (ask シナリオでは、mse による 0 への縮小をサポートします)
活性化剤の容量	アクティベータリクエスト容量
初期スケール	リビジョンの作成時に、開始するポッドの数を初期化します。デフォルトは 1 です。
許可ゼロ初期スケール	リビジョンの作成時に 0 個の Pod の初期化を許可するかどうか。デフォルトは false で、許可されていないことを意味します。
最小スケール	リビジョン レベルで保持する Pod の最小数。デフォルトの 0 は、最小値を 0 にすることができることを意味します
最大スケール	リビジョンレベルで拡張できるポッドの最大数。デフォルトの 0 は、最大拡張制限がないことを意味します
スケールダウン遅延	遅延スケーリング時間を示します。デフォルトの 0 は即時スケーリングを意味します

リビジョンバージョンモード

Knative では、弾性インジケーターをリビジョンごとに構成できます。一部の構成パラメーターは次のとおりです。

• インジケーターの種類

<!---->

• • 各リビジョンインジケーターの注釈: autoscaling.knative.dev/metric
  • サポートされているインジケーター:「同時実行性」、「rps」、「cpu」、「メモリー」およびその他のカスタムインジケーター
  • デフォルトのインジケーター:「同時実行性」

<!---->

• 目標閾値

<!---->

• • autoscaling.knative.dev/target
  • デフォルト値：「100」

<!---->

• ポッドは保持期間 0 にスケールダウンします

<!---->

• • autoscaling.knative.dev/scale-to-zero-pod-retention-period

<!---->

• 目標使用量

<!---->

• • autoscaling.knative.dev/target-utilization-percentage

構成例は以下のとおりです。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "concurrency"
        autoscaling.knative.dev/target: "50"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
        autoscaling.knative.dev/target-utilization-percentage: "80"

HPAのサポート

K8s HPA の場合、Knative は自然な構成サポートも提供しており、Knative の CPU またはメモリに基づいた自動弾力性機能を使用できます。

• CPUに基づいた柔軟な構成

<!---->

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "cpu"

• メモリベースの柔軟な構成

<!---->

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "memory"

回復力の向上

Knative は、さまざまなエラスティック戦略をサポートできる柔軟なプラグイン メカニズム (pod-autoscaler-class) を提供します。Alibaba Cloud Container Service Knative で現在サポートされているエラスティック プラグインには、kpa、hpa、正確な弾性伸縮 mpa、予測機能を備えた ahpa が含まれます。

予約済みリソースプール

ネイティブ KPA 機能に加えて、リソース プールを予約する機能が提供されます。この機能は次のシナリオに適用できます。

• ECS は ECI と混合されます。通常の状況では ECS リソースを使用し、バースト トラフィックには ECI を使用したい場合は、リソース プールを予約することでこれを実現できます。たとえば、単一のポッドが 10 個の同時リクエストを処理し、予約されたリソース プール内のポッドの数が 5 個の場合、通常の状況では、ECS リソースは最大 50 個の同時リクエストを処理できます。同時実行数が 50 を超える場合、Knative は需要を満たすために新しい Pod の数を拡張し、新しく拡張されたリソースは ECI を使用します。

• リソースのウォームアップ。ECI が完全に使用されるシナリオでは、リソース プールを予約することによってリソースの予熱を実現することもできます。ビジネスの低迷期にリザーブド インスタンスを使用してデフォルトのコンピューティング インスタンスを置き換えると、最初のリクエストが来たときにそのリザーブド インスタンスがサービスを提供するために使用され、これによりデフォルトの仕様インスタンスの拡張もトリガーされます。デフォルト仕様インスタンスの拡張が完了すると、すべての新しいリクエストはデフォルト仕様に転送されます。同時に、リザーブド インスタンスは新しいリクエストを受け入れず、リザーブド インスタンスが受信したすべてのリクエストが処理された後、オフラインになります。 。このシームレスな置き換え方法により、コストと効率のバランスが達成されます。つまり、コールド スタートに大幅な時間を費やすことなく、常駐インスタンスのコストが削減されます。

正確な弾性伸縮

1つのPodでリクエストを処理するスループットには限界があり、複数のリクエストを同じPodに転送するとサーバー側で過負荷例外が発生するため、1つのPodのリクエストの同時処理数を正確に制御する必要がある。特に一部の AIGC シナリオでは、単一のリクエストが多くの GPU リソースを占有するため、各ポッドで処理される同時リクエストの数を厳密に制限する必要があります。

Knative は MSE クラウド ネイティブ ゲートウェイと組み合わされて、同時実行性に基づいた正確なエラスティック制御の実装、つまり mpa エラスティック プラグインを提供します。

mpa は MSE ゲートウェイから同時実行数を取得し、拡張と縮小に必要なポッドの数を計算します。MSE ゲートウェイはリクエストに基づいて正確に転送できます。

構成例は以下のとおりです。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: mpa.autoscaling.knative.dev
        autoscaling.knative.dev/max-scale: '20'
    spec:
      containerConcurrency: 5
      containers:
      - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

パラメータの説明:

パラメータ	説明する
autoscaling.knative.dev/クラス: mpa.autoscaling.knative.dev	mpa は、MSE インジケーターが拡大と縮小に使用されることを示し、0 への縮小をサポートします。
autoscaling.knative.dev/max-scale: '20'	拡張ポッド数の上限は20です
コンテナ同時実行数: 5	単一のポッドが処理できる同時実行の最大数が 5 であることを示します

弾性予測 AHPA

コンテナー サービス AHPA (Advanced horizo​​ntal Pod Autoscaler) は、弾性サイクルを自動的に特定し、過去のビジネス指標に基づいて容量を予測し、弾性ラグの問題を解決できます。

現在、Knative は AHPA (Advanced horizo​​ntal Pod Autoscaler) のエラスティック機能をサポートしており、リクエストが定期的である場合、エラスティック予測を通じてリソースを予熱できます。リソースの予熱のしきい値を下げる場合と比較して、AHPA はリソースの使用率を最大化できます。

さらに、AHPA はカスタム インジケーター構成をサポートしているため、Knative と AHPA を組み合わせることで、メッセージ キューと応答遅延 rt に基づいた自動弾力性を実現できます。

rps ベースの AHPA を使用する構成例は次のとおりです。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/metric: "rps"
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "30"
        autoscaling.alibabacloud.com/scaleStrategy: "observer"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

パラメータの説明:

パラメータ	説明する
autoscaling.knative.dev/クラス: ahpa.autoscaling.knative.dev	Elastic プラグイン AHPA を指定します。
autoscaling.knative.dev/metric: "rps"	AHPAインジケーターを設定します。現在、同時実行性、rps、および応答時間 rt をサポートしています。
autoscaling.knative.dev/target: "10"	AHPA インジケーターのしきい値を設定します。この例では、rps しきい値は 10 です。これは、単一のポッドによって処理される 1 秒あたりの最大リクエスト数が 10 であることを意味します。
autoscaling.knative.dev/minScale: "1"	エラスティック ポリシー インスタンスの最小数を 1 に設定します。
autoscaling.knative.dev/maxScale: "30"	エラスティック ポリシー インスタンスの最大数を 30 に設定します。
autoscaling.alibabacloud.com/scaleStrategy: "オブザーバー"	オートスケールモードを設定します。デフォルト値はオブザーバーです。 オブザーバー:観察するだけで、実際のスケーリング アクションは実行しないことを示します。こうすることで、AHPA が期待どおりに動作しているかどうかを観察できます。予測には 7 日間の履歴データが必要なため、デフォルトのサービス作成モードはオブザーバー モードです。auto: AHPA が拡張と縮小を担当することを示します。AHPA 指標としきい値は AHPA に入力され、AHPA が最終的に有効にするかどうかを決定します。

まとめ

この記事では、Knative の代表的なエラスティック実装 KPA から始まり、リクエストに基づく自動エラスティックの実装方法、0 への縮小、突然のトラフィックへの対処方法、予約されたリソース プール、正確なリソース プールなどの Knative エラスティック機能の拡張と強化を含めて紹介します。弾力性と弾性予測能力。

AIGC シーンで Knative を使用した体験アクティビティも提供します。参加歓迎: ぜひあなたのかわいいペットの限定 AI 画像のロックを解除してください! 開催期間：2023/08/24～09/24。

あなたのかわいいペットの独占的な AI 画像のロックを解除してください!

https://developer.aliyun.com/adc/series/petsai#J_2264716120

オープンソース フレームワーク NanUI の作者がスチールの販売に切り替えたため、プロジェクトは中断されました。Apple App Store の無料リストのナンバー 1 はポルノ ソフトウェア TypeScript です。人気が出てきたばかりなのに、なぜ大手はそれを放棄し始めるのでしょうか。 ? TIOBE 10月リスト：Javaが最大の下落、C#はJavaに迫る Rust 1.73.0リリース AIガールフレンドにイギリス女王暗殺を勧められた男性に懲役9年の実刑判決 Qt 6.6正式リリース ロイター：RISC-Vテクノロジーが中米テクノロジー戦争の鍵となる 新たな戦場 RISC-V: 単一の企業や国に支配されない レノボ、Android PC の発売を計画

{{名前}}

{{名前}}