Knative基本機能の詳細分析:Knative Services自動拡張容量Autoscaler
7450 ワード
Knative Servicesのデフォルトでは、開梱時にすぐに使用できる、要求に基づいた自動拡張機能-Knative Pod Autoscaler(KPA)が提供されます.次に、KnativeでAutoscalerを遊ぶ方法を体験します.
Autoscalerメカニズム
1:Revisionによって与えられたコンテナインスタンスによって一度に1つの要求のみが処理されることを保証する. 2-N:要求の同時値は2以上に制限される. 0:は制限せず、システム自身が決定していることを示している.
minScaleとmaxScaleでは、アプリケーションが提供するサービスの最小および最大Pod数を構成できます.この2つのパラメータ構成により、サービスの冷却起動または計算コストを制御できます.
minScaleとmaxScaleは、Revisionテンプレートで次のように構成できます.
Revisionテンプレートでこれらのパラメータを変更すると、PodAutoscalerオブジェクトに影響します.これは、Knative Servicesシステム構成を変更する必要がない場合、PodAutoscalerオブジェクトが変更可能であることを示しています.
注意:これらのコメントは、Revisionのライフサイクル全体に適用されます.Revisionがrouteに参照されていない場合でも、minscaleが指定した最小PODカウントは提供されます.ルーティング不可能なRevisionはゴミ収集される可能性があることを覚えておいてください.
minscaleコメントが設定されていない場合、podsはゼロにスケールされます(前述のconfigmapに従ってenable-scale-to-zeroがfalseの場合、1にスケールされます).
maxscaleコメントが設定されていない場合、作成されるPodの数に上限はありません.
KPA構成に基づく例
Autoscalerメカニズム
Knative Servicesは各PODにQUEUEエージェントコンテナ(queue-proxy)を注入し、このコンテナはAutoscalerにユーザコンテナの同時指標を報告する責任を負う.Autoscalerはこれらの指標を受信すると、同時要求数と対応するアルゴリズムに基づいてDeploymentのPOD数を調整し、自動拡張容量を実現します.
アルゴリズム#アルゴリズム#
Autoscalerは、PODごとの平均要求数(コンカレント数)に基づいて拡張処理を行う.デフォルトのコンカレント数は100です.POD数=コンカレント要求合計/コンテナコンカレント数
サービスのコンカレント数が10に設定されている場合、50個のコンカレント要求のサービスがロードされている場合、Autoscalerは5個のPOD(50個のコンカレント要求/10=POD)を作成します.
Autoscalerは、Stable(安定モード)とPanic(パニックモード)の2つの操作モードのスケーリングアルゴリズムを実現した.
あんていモード
安定モードでは、Autoscalerは、PODごとに必要な平均同時数を達成するためにDeploymentのサイズを調整します.PODのコンカレント数は,60秒ウィンドウ内ですべてのデータ要求を受信した平均数から算出した.
パニックモード
Autoscalerは60秒ウィンドウ内の平均コンカレント数を計算し、システムは必要なコンカレントレベルで1分安定する必要があります.しかし、Autoscalerは6秒のパニックウィンドウを計算し、ターゲットの2倍に達するとパニックモードになります.パニックモードでは、Autoscalerはより短く、より敏感な緊急ウィンドウで動作します.緊急事態が60秒続くと、Autoscalerは最初の60秒安定ウィンドウに戻ります.|
Panic Target---> +--| 20
| |
| +-------------------------|--| 10 CONCURRENCY
| | |
|
KPAの設定
上記の説明では、Knative Pod Autoscalerの動作メカニズムについて初歩的な理解を示しました.では、KPAの構成方法について説明します.KnativeでKPA情報を構成するには、knative-servingネーミングスペースの下にあるk 8 sのConfigMap:config-autoscalerを変更する必要があります.config-autoscalerを表示するには、次のコマンドを使用します.kubectl -n knative-serving get cm config-autoscaler
デフォルトのConfigMapは次のとおりです.apiVersion: v1
kind: ConfigMap
metadata:
name: config-autoscaler
namespace: knative-serving
data:
container-concurrency-target-default: 100
container-concurrency-target-percentage: 1.0
enable-scale-to-zero: true
enable-vertical-pod-autoscaling: false
max-scale-up-rate: 10
panic-window: 6s
scale-to-zero-grace-period: 30s
stable-window: 60s
tick-interval: 2s
KPAの構成を0に縮める
Revisionを0に縮めるように正しく設定するには、ConfigMapの次のパラメータを変更する必要があります.
scale-to-zero-grace-period
scale-to-zero-grace-periodは、0に縮小する前にinactive revisonが保持する実行時間(最小3 0 s)を表します.scale-to-zero-grace-period: 30s
stable-window
stable modeモードで動作する場合、autoscalerの安定したウィンドウ期間における平均同時数での動作.stable-window: 60s
stable-windowもRevisionコメントに設定できます.autoscaling.knative.dev/window: 60s
enable-scale-to-zero
enable-scale-to-zeroパラメータがtrueに設定されていることを保証します.
Termination period
Termination period(終了時間)は、PODが最後の要求が完了した後に閉じる時間である.PODの終了期間は、安定したウィンドウ値とゼロ猶予パラメータにスケーリングされた合計に等しい.この例では、Termination periodは90秒である.[]()
[](#ed 77725 a)コンカレント数の構成
Autoscalerのコンカレント数は、次の方法で設定できます.
target
targetは、指定された時間(ソフトリミット)にどれだけの同時要求が必要かを定義し、KnativeのAutoscalerの推奨構成です.
ConfigMapでデフォルト設定されている同時targetは100です.`container-concurrency-target-default: 100`
この値は、Revisionのautoscaling.knative.dev/target
コメントで変更できます.autoscaling.knative.dev/target: 50
containerConcurrency
注:containerConcurrency(コンテナ同時)は、指定された時間にどのくらいのリクエストがアプリケーションに到達するかを明確に制限する必要がある場合にのみ使用します.containerConcurrencyは、アプリケーションが強制的な同時制約を必要とする場合にのみ推奨されます.
containerConcurrencyは、所定の時間にコンカレント要求を許可する数(ハードリミット)を制限し、Revisionテンプレートで構成します.containerConcurrency: 0 | 1 | 2-N
|
Panic Target---> +--| 20
| |
| +-------------------------|--| 10 CONCURRENCY
| | |
|
上記の説明では、Knative Pod Autoscalerの動作メカニズムについて初歩的な理解を示しました.では、KPAの構成方法について説明します.KnativeでKPA情報を構成するには、knative-servingネーミングスペースの下にあるk 8 sのConfigMap:config-autoscalerを変更する必要があります.config-autoscalerを表示するには、次のコマンドを使用します.
kubectl -n knative-serving get cm config-autoscaler
デフォルトのConfigMapは次のとおりです.
apiVersion: v1
kind: ConfigMap
metadata:
name: config-autoscaler
namespace: knative-serving
data:
container-concurrency-target-default: 100
container-concurrency-target-percentage: 1.0
enable-scale-to-zero: true
enable-vertical-pod-autoscaling: false
max-scale-up-rate: 10
panic-window: 6s
scale-to-zero-grace-period: 30s
stable-window: 60s
tick-interval: 2s
KPAの構成を0に縮める
Revisionを0に縮めるように正しく設定するには、ConfigMapの次のパラメータを変更する必要があります.
scale-to-zero-grace-period
scale-to-zero-grace-periodは、0に縮小する前にinactive revisonが保持する実行時間(最小3 0 s)を表します.
scale-to-zero-grace-period: 30s
stable-window
stable modeモードで動作する場合、autoscalerの安定したウィンドウ期間における平均同時数での動作.
stable-window: 60s
stable-windowもRevisionコメントに設定できます.
autoscaling.knative.dev/window: 60s
enable-scale-to-zero
enable-scale-to-zeroパラメータがtrueに設定されていることを保証します.
Termination period
Termination period(終了時間)は、PODが最後の要求が完了した後に閉じる時間である.PODの終了期間は、安定したウィンドウ値とゼロ猶予パラメータにスケーリングされた合計に等しい.この例では、Termination periodは90秒である.[]()
[](#ed 77725 a)コンカレント数の構成
Autoscalerのコンカレント数は、次の方法で設定できます.
target
targetは、指定された時間(ソフトリミット)にどれだけの同時要求が必要かを定義し、KnativeのAutoscalerの推奨構成です.
ConfigMapでデフォルト設定されている同時targetは100です.
`container-concurrency-target-default: 100`
この値は、Revisionの
autoscaling.knative.dev/target
コメントで変更できます.autoscaling.knative.dev/target: 50
containerConcurrency
注:containerConcurrency(コンテナ同時)は、指定された時間にどのくらいのリクエストがアプリケーションに到達するかを明確に制限する必要がある場合にのみ使用します.containerConcurrencyは、アプリケーションが強制的な同時制約を必要とする場合にのみ推奨されます.
containerConcurrencyは、所定の時間にコンカレント要求を許可する数(ハードリミット)を制限し、Revisionテンプレートで構成します.
containerConcurrency: 0 | 1 | 2-N
拡張容量境界の設定(minScaleとmaxScale)
minScaleとmaxScaleでは、アプリケーションが提供するサービスの最小および最大Pod数を構成できます.この2つのパラメータ構成により、サービスの冷却起動または計算コストを制御できます.
minScaleとmaxScaleは、Revisionテンプレートで次のように構成できます.
spec:
template:
metadata:
autoscaling.knative.dev/minScale: "2"
autoscaling.knative.dev/maxScale: "10"
Revisionテンプレートでこれらのパラメータを変更すると、PodAutoscalerオブジェクトに影響します.これは、Knative Servicesシステム構成を変更する必要がない場合、PodAutoscalerオブジェクトが変更可能であることを示しています.
edit podautoscaler
注意:これらのコメントは、Revisionのライフサイクル全体に適用されます.Revisionがrouteに参照されていない場合でも、minscaleが指定した最小PODカウントは提供されます.ルーティング不可能なRevisionはゴミ収集される可能性があることを覚えておいてください.
デフォルト
minscaleコメントが設定されていない場合、podsはゼロにスケールされます(前述のconfigmapに従ってenable-scale-to-zeroがfalseの場合、1にスケールされます).
maxscaleコメントが設定されていない場合、作成されるPodの数に上限はありません.
KPA構成に基づく例
Knative 0.7バージョンの導入インストールは、アリクラウドの導入Knativeを参照してください.
公式に提供されたautoscale-goの例を用いて、サービスの例を示した.yamlは次のとおりです.apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
template:
metadata:
labels:
app: autoscale-go
annotations:
autoscaling.knative.dev/target: "10"
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
アクセスゲートウェイの取得:$ kubectl get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"
121.199.194.150
Knative 0.7バージョンでドメイン名情報を取得します.$ kubectl get route autoscale-go --output jsonpath="{.status.url}"| awk -F/ '{print $3}'
autoscale-go.default.example.com
シーン1:コンカレントリクエストの例
以上のように構成すると、現在の最大同時要求数は10です.30 s以内に50個の同時要求を保持し、実行状況を見てみましょう.hey -z 30s -c 50 -host "autoscale-go.default.example.com" "http://121.199.194.150?sleep=100&prime=10000&bloat=5"
結果は我々が予想したように5つのPODを拡張した.
シーン2:拡張境界の例
servcieを修正します.yamlの構成は次のとおりです.apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
template:
metadata:
labels:
app: autoscale-go
annotations:
autoscaling.knative.dev/target: "10"
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "3"
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
現在の最大同時要求数10、minScale最小保持インスタンス数1、maxScale最大拡張インスタンス数3.
私たちは依然として30 s以内に50個の同時要求を実行し、実行状況を見てみましょう.hey -z 30s -c 50 -host "autoscale-go.default.example.com" "http://121.199.194.150?sleep=100&prime=10000&bloat=5"
その結果,我々が予想したように,最大3つのPODが拡張され,アクセス要求トラフィックがなくても1つの実行されたPODが維持された.
結論
上記の紹介を見て、Knativeでアプリケーション拡張容量を構成するのはこんなに簡単だと思いますか?実はKnativeではKPA以外にもK 8 s HPAがサポートされています.CPUベースのHorizontal POD Autoscaler(HPA)を以下のように構成できます.
注記としてautoscaling.knative.dev/class
およびautoscaling.knative.dev/metric
の値を改訂テンプレートに追加または変更することにより、Knativeは、デフォルトの要求ベースのメトリックではなく、CPUベースの自動スケーリングを使用するように構成することができる.次のように構成されています.spec:
template:
metadata:
autoscaling.knative.dev/metric: concurrency
autoscaling.knative.dev/class: hpa.autoscaling.knative.dev
Knative Autoscalingは、デフォルトのKPAまたはHorizontal POD Autoscaler(HPA)を使用するように自由に構成できます.
Knative交流グループへようこそ
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
template:
metadata:
labels:
app: autoscale-go
annotations:
autoscaling.knative.dev/target: "10"
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
$ kubectl get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"
121.199.194.150
$ kubectl get route autoscale-go --output jsonpath="{.status.url}"| awk -F/ '{print $3}'
autoscale-go.default.example.com
hey -z 30s -c 50 -host "autoscale-go.default.example.com" "http://121.199.194.150?sleep=100&prime=10000&bloat=5"
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
template:
metadata:
labels:
app: autoscale-go
annotations:
autoscaling.knative.dev/target: "10"
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "3"
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
hey -z 30s -c 50 -host "autoscale-go.default.example.com" "http://121.199.194.150?sleep=100&prime=10000&bloat=5"
上記の紹介を見て、Knativeでアプリケーション拡張容量を構成するのはこんなに簡単だと思いますか?実はKnativeではKPA以外にもK 8 s HPAがサポートされています.CPUベースのHorizontal POD Autoscaler(HPA)を以下のように構成できます.
注記として
autoscaling.knative.dev/class
およびautoscaling.knative.dev/metric
の値を改訂テンプレートに追加または変更することにより、Knativeは、デフォルトの要求ベースのメトリックではなく、CPUベースの自動スケーリングを使用するように構成することができる.次のように構成されています.spec:
template:
metadata:
autoscaling.knative.dev/metric: concurrency
autoscaling.knative.dev/class: hpa.autoscaling.knative.dev
Knative Autoscalingは、デフォルトのKPAまたはHorizontal POD Autoscaler(HPA)を使用するように自由に構成できます.