バックグラウンド
K8s 1.18 より前では、HPA 拡張で感度を調整できません。
-
縮小の場合、 の パラメータ
kube-controller-managerを 使用して--horizontal-pod-autoscaler-downscale-stabilization-window縮小時間枠を制御します。デフォルトは 5 minutes です。つまり、負荷が減少した後に縮小するまでに少なくとも 5 分間待機する必要があります。 -
容量拡張の場合、拡張速度は hpa コントローラーの固定アルゴリズムとハードコードされた定数係数によって制御されますが、カスタマイズすることはできません。
このような設計ロジックにより、ユーザーは HPA の拡張と縮小の感度をカスタマイズできなくなります。また、ビジネス シナリオによっては、次のような容量拡張の感度に対する要件も異なる場合があります。
-
トラフィックのバーストが発生する重要なビジネスの場合、必要に応じて (必要でない可能性がある場合でも、念のため) 容量を迅速に拡張する必要がありますが、(トラフィックのピークが再び発生するのを防ぐために) 容量はゆっくりとスケールダウンする必要があります。
-
大量のデータを処理する必要がある一部のオフライン ビジネスでは、必要に応じて処理時間を短縮するためにできるだけ早く容量を拡張する必要があります。また、リソースが不足している場合には、できるだけ早く容量を削減してコストを節約する必要があります。必要です。
-
通常のデータ/ネットワーク トラフィックを扱う企業では、ジッターを軽減するために一般的な方法でスケールアップまたはスケールダウンすることがあります。
HPA は、K8s 1.18 のアップデートを導入しました。以前の v2beta2 バージョンでは、スケーリング感度の制御が追加されましたが、バージョン番号は v2beta2 でも変更されません。
使い方
behavior このアップデートでは、実際にHPA 仕様に 新しいフィールドが追加されています 。 展開と縮小の動作をそれぞれ制御するためのscaleUp 2 つのフィールドが以下にあります。詳細については、公式 API ドキュメントを参照してください: https://v1-18.docs.kubernetes scaleDownio /docs/reference/generated/kubernetes-api/v1.18/#horizontalpodautoscalerbehavior-v2beta2-autoscaling
使用シナリオの例をいくつか以下に示します。
急速な拡大
アプリケーションを迅速に拡張する必要がある場合は、次のような HPA 構成を使用できます。
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: web
spec:
minReplicas: 1
maxReplicas: 1000
metrics:
- pods:
metric:
name: k8s_pod_rate_cpu_core_used_limit
target:
averageValue: "80"
type: AverageValue
type: Pods
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
behavior: # 这里是重点
scaleUp:
policies:
- type: percent
value: 900%
上記の構成は、容量拡張時に現在の数の9倍のレプリカ数が即時に追加されること、つまり現在の数の10倍のPod数が即時に拡張されることを意味しており、もちろん制限はありませんを超えることはできません maxReplicas 。
最初に Pod が 1 つしかなかった場合、トラフィックバーストが発生すると急速に拡張されますが、拡張時の Pod 数の傾向は以下のようになります。
1 -> 10 -> 100 -> 1000
--horizontal-pod-autoscaler-downscale-stabilization-window縮小ポリシーが構成されていない場合、縮小はグローバルなデフォルトの縮小時間枠 ( 、デフォルトでは 5 分) の後に開始されます。
スケールアップは速く、スケールダウンはゆっくり
トラフィックのピークが過ぎて同時実行性が急激に低下した場合、デフォルトの縮小戦略を使用すると、数分後にはポッドの数も急激に減少します。結局のところ、拡張プロセスにはまだ一定の時間がかかります。トラフィックのピークが十分に高い場合、この期間中にバックエンドの処理能力が追いつかない可能性があり、その結果、一部のリクエストが失敗します。この時点で、HPA に縮小戦略を追加できます。HPA behavior 構成の例は次のとおりです。
behavior:
scaleUp:
policies:
- type: percent
value: 900%
scaleDown:
policies:
- type: pods
value: 1
periodSeconds: 600 # 每 10 分钟只缩掉 1 个 Pod
上記の例で追加した scaleDown 設定では、スケールダウン時に 10 分ごとに 1 つの Pod のみを縮小するように指定されており、スケールダウンの速度が大幅に低下します。スケールダウン中の Pod 数の傾向は次のとおりです。
1000 -> … (10 min later) -> 999
これにより、主要企業はトラフィックのバーストが発生する可能性がある場合でも処理能力を維持し、トラフィックのピークによって引き起こされる部分的なリクエストの失敗を回避できます。
ゆっくりとした拡大
アプリケーションの重要性を低くし、拡張時にあまり神経質になりたくない場合は、アプリケーションを着実かつゆっくりと拡張し、以下を HPA に追加できます behavior。
behavior:
scaleUp:
policies:
- type: pods
value: 1 # 每次扩容只新增 1 个 Pod
開始時に Pod が 1 つしかなかった場合、拡張中の Pod 数の傾向は次のようになります。
1 -> 2 -> 3 -> 4
自動スケーリングを無効にする
アプリケーションが非常に重要であり、拡張後に自動的に縮小したくない場合は、縮小条件を判断するために手動介入または他の独自開発のコントローラーが必要です。次の構成を使用して自動縮小を無効にできます behavior 。
behavior:
scaleDown:
policies:
- type: pods
value: 0
縮小時間枠の延長
容量縮小のデフォルトの時間枠は 5 分 ( --horizontal-pod-autoscaler-downscale-stabilization-window) です。トラフィックの不具合による異常を避けるために時間枠を延長する必要がある場合は、容量縮小の時間枠を指定できます。設定例は次のとおりですbehavior 。
behavior:
scaleDown:
stabilizationWindowSeconds: 600 # 等待 10 分钟再开始缩容
policies:
- type: pods
value: 5 # 每次只缩掉 5 个 Pod
上記の例は、負荷が低下すると、スケールダウンする前に 600 秒 (10 分) 待機し、毎回 5 つのポッドのみがスケールダウンされることを意味します。
拡張時間枠を延長する
一部のアプリケーションでは、頻繁に容量拡張につながるデータの不具合が頻繁に発生しますが、拡張された Pod は実際には不要であり、リソースを無駄にしています。たとえば、データ処理パイプラインのシナリオでは、拡張指標はキュー内のイベント数であり、キューに大量のイベントが蓄積された場合、すぐに容量を拡張できればよいのですが、実際には拡張できません。イベントは短期間でしか蓄積されないため、あまり敏感になりすぎないようにする必要がありますが、拡張にも迅速に対応できます。
デフォルトの拡張アルゴリズムでは、短期間で容量が拡張されます。このシナリオでは、不具合によるリソースの無駄を避けるために、容量拡張の時間枠を追加できます。構成例は次のとおりですbehavior 。
behavior:
scaleUp:
stabilizationWindowSeconds: 300 # 扩容前等待 5 分钟的时间窗口
policies:
- type: pods
value: 20 # 每次扩容新增 20 个 Pod
上の例は、容量を拡張するときに 5 分間待機する必要があることを示しています。この期間中に負荷が低下した場合、容量は拡張されません。負荷が容量拡張のしきい値を超え続ける場合、容量は拡張されません。拡張ごとに 20 個のポッドが追加されます。
まとめ
この記事では、K8s 1.18 の新しい HPA 機能を使用して拡張と縮小の感度を制御し、拡張速度に関するさまざまなシナリオのニーズをより適切に満たす方法を紹介します。