Advanced Horizontal Pod Autoscaler (AHPA) は、過去の使用量パターンを学習して将来のリソース需要を予測し、予測される需要のピークに先立って Pod のレプリカをスケーリングします。これにより、コールドスタートによる遅延が削減され、システムの安定性が向上します。需要の減少が予測される場合は、AHPA は早期にスケールインを行い、リソースコストを削減します。
前提条件
開始する前に、以下を確認してください：
Container Service for Kubernetes (ACK) マネージドクラスターまたは ACK サーバーレスクラスター。お持ちでない場合は、「ACK マネージドクラスターの作成」または「ACK サーバーレスクラスターの作成」をご参照ください。
クラスターで Managed Service for Prometheus が有効になっていること。有効になっていない場合は、「Managed Service for Prometheus への接続と設定」をご参照ください。
Prometheus によって収集された、CPU およびメモリ使用量データを含む、少なくとも 7 日間のアプリケーション統計。AHPA は、予測を生成するためにこの既存データを必要とします。Prometheus インスタンスを有効にしたばかりの場合は、7 日間待ってからステップ 4: AHPA のデプロイに進んでください。
ステップ 1: AHPA Controller のインストール
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、[アドオン] をクリックします。
[アドオン] ページで、[AHPA Controller] カードを見つけ、[インストール] をクリックします。画面上の指示に従って、インストールを完了します。
ステップ 2: データソースとしての Prometheus の設定
ARMS コンソールにログインします。
左側のナビゲーションウィンドウで、Managed Service for Prometheus ＞ インスタンス を選択します。
[インスタンス] ページで、Prometheus インスタンスがデプロイされているリージョンを選択します。Prometheus インスタンスの名前をクリックします。インスタンス名は ACK クラスターの名前と一致します。
[設定項目] ページで、[HTTP API URL (Grafana 読み取り URL)] セクションを見つけ、内部エンドポイントを記録します。クラスターでアクセストークンが有効になっている場合は、アクセストークンもメモしておきます。
次の内容で
application-intelligence.yamlという名前のファイルを作成します。プレースホルダーの値を、実際の Prometheus エンドポイントとアクセストークンに置き換えます。AHPA ダッシュボードで Prometheus Service のメトリックを表示するには、次のパラメーターを ConfigMap に追加します：
prometheus_writer_url(Remote Write の内部エンドポイント)、prometheus_writer_ak(AccessKey ID)、およびprometheus_writer_sk(AccessKey Secret)。詳細については、「AHPA の Prometheus ダッシュボードの有効化」をご参照ください。プレースホルダー 説明 prometheusUrlご利用の Prometheus インスタンスの内部エンドポイント tokenご利用の Prometheus インスタンスのアクセストークン。アクセストークンが有効な場合にのみ必須です apiVersion: v1 kind: ConfigMap metadata: name: application-intelligence namespace: kube-system data: prometheusUrl: "http://cn-hangzhou-intranet.arms.aliyuncs.com:9443/api/v1/prometheus/da9d7dece901db4c9fc7f5b9c40****/158120454317****/cc6df477a982145d986e3f79c985a****/cn-hangzhou" token: "eyJhxxxxx"ConfigMap を適用します：
kubectl apply -f application-intelligence.yaml
ステップ 3: テストサービスのデプロイ
このステップでは、テスト環境をデプロイして、AHPA の予測スケーリングを標準の Horizontal Pod Autoscaler (HPA) の動作と比較します。この環境は、以下で構成されます：
fib-deployment：ターゲットワークロードfib-svc：fib-deploymentにトラフィックをルーティングするサービスfib-loader：トラフィックの変動をシミュレートする負荷ジェネレーターfib-hpa：比較のためのベースラインを提供する HPA ポリシー
次の内容で demo.yaml という名前のファイルを作成します：
apiVersion: apps/v1
kind: Deployment
metadata:
name: fib-deployment
namespace: default
annotations:
k8s.aliyun.com/eci-use-specs: "1-2Gi"
spec:
replicas: 1
selector:
matchLabels:
app: fib-deployment
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: fib-deployment
spec:
containers:
- image: registry.cn-huhehaote.aliyuncs.com/kubeway/knative-sample-fib-server:20200820-171837
imagePullPolicy: IfNotPresent
name: user-container
ports:
- containerPort: 8080
name: user-port
protocol: TCP
resources:
limits:
cpu: "1"
memory: 2000Mi
requests:
cpu: "1"
memory: 2000Mi
---
apiVersion: v1
kind: Service
metadata:
name: fib-svc
namespace: default
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 8080
selector:
app: fib-deployment
sessionAffinity: None
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fib-loader
namespace: default
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: fib-loader
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: fib-loader
spec:
containers:
- args:
- -c
- |
/ko-app/fib-loader --service-url="http://fib-svc.${NAMESPACE}?size=35&interval=0" --save-path=/tmp/fib-loader-chart.html
command:
- sh
env:
- name: NAMESPACE
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
image: registry.cn-huhehaote.aliyuncs.com/kubeway/knative-sample-fib-loader:20201126-110434
imagePullPolicy: IfNotPresent
name: loader
ports:
- containerPort: 8090
name: chart
protocol: TCP
resources:
limits:
cpu: "8"
memory: 16000Mi
requests:
cpu: "2"
memory: 4000Mi
---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: fib-hpa
namespace: default
spec:
maxReplicas: 50
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: fib-deployment
targetCPUUtilizationPercentage: 50構成を適用します：
kubectl apply -f demo.yamlステップ 4: AHPA のデプロイ
AHPA を observer モードで開始します。このモードでは、AHPA はスケーリングの予測を記録しますが、それに基づいて動作はしません。これにより、自動スケーリングを有効にする前に予測の精度を検証できます。
次の内容で
ahpa-demo.yamlという名前のファイルを作成します：apiVersion: autoscaling.alibabacloud.com/v1beta1 kind: AdvancedHorizontalPodAutoscaler metadata: name: ahpa-demo spec: scaleStrategy: observer # まず予測を検証するためにオブザーバーモードで開始 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 40 # 平均 CPU 使用率が 40% を超えた場合にスケーリング scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: fib-deployment maxReplicas: 100 minReplicas: 2 stabilizationWindowSeconds: 300 # フラッピングを防ぐため、スケールイン信号の受信後、動作するまで 300 秒待機 prediction: quantile: 0.95 # 信頼度：過去のピークの 95% をカバー scaleUpForward: 180 # Pod のコールドスタート時間に対応するため、180 秒早くスケーリングを開始 instanceBounds: - startTime: "2021-12-16 00:00:00" endTime: "2031-12-16 00:00:00" bounds: - cron: "* 0-8 ? * MON-FRI" maxReplicas: 15 minReplicas: 4 - cron: "* 9-15 ? * MON-FRI" maxReplicas: 15 minReplicas: 10 - cron: "* 16-23 ? * MON-FRI" maxReplicas: 20 minReplicas: 15次の表に、主要なパラメーターを示します。
パラメーター 必須 デフォルト 説明 scaleTargetRefはい — 予測スケーリングを適用する Deployment metricsはい — スケーリングをトリガーするメトリック。サポート対象：CPU、GPU、メモリ、秒間クエリ数 (QPS)、レスポンスタイム (RT) target.averageUtilizationはい — スケーリングをトリガーする使用率のしきい値。たとえば、 40を指定すると、平均 CPU 使用率が 40% を超えたときにスケーリングがトリガーされますscaleStrategyいいえ observerスケーリングモード。有効な値については、以下の表をご参照ください maxReplicasはい — Pod レプリカの最大数 minReplicasはい — Pod レプリカの最小数 stabilizationWindowSecondsいいえ 300スケールインアクティビティのクールダウン時間 (秒) prediction.quantileはい 0.99予測の信頼度を分位数で表現します。値が大きいほど、より保守的な予測となり、十分なキャパシティを事前にプロビジョニングできる可能性が高くなります。有効な値： 0～1、小数点以下 2 桁まで。ほとんどのワークロードでは、0.90～0.99の値が推奨されますprediction.scaleUpForwardはい — 予測される需要のピークの何秒前に AHPA がスケーリングを開始するか。Pod のコールドスタート時間 (Pod の作成から Ready 状態になるまでの時間) に合わせて設定します instanceBoundsいいえ — スケーリング操作の持続時間。レプリカ Pod の数は、AHPA で定義されたレプリカ Pod の最大数と最小数によって制限されます instanceBounds.startTimeいいえ — インスタンスバウンドルールの開始時刻 instanceBounds.endTimeいいえ — インスタンスバウンドルールの終了時刻 instanceBounds.bounds.cronいいえ — レプリカ数の制限が適用されるタイミングを定義する cron 式 scaleStrategyフィールドには、次の値を指定できます：値 説明 observerスケーリングを実行せずに予測を記録します。本番環境に適用する前に、これを使用して AHPA の動作を検証します autoAHPA が自動的にスケーリング操作を実行します proactive過去のパターンに基づく予測スケーリングのみを適用します reactive標準の HPA と同様に、メトリック駆動のスケーリングのみを適用します cron 式のフォーマット
instanceBounds.bounds.cronフィールドは、次の 5 つのフィールド形式を使用します：フィールド 必須 有効な値 特殊文字 分 はい 0～59 */,-時 はい 0～23 */,-日 はい 1～31 */,-?月 はい 1～12 または JAN～DEC */,-曜日 いいえ 0～6 または SUN～SAT */,-?特殊文字：
*(すべての値)、/(増分)、,(リストの区切り文字)、-(範囲)、?(プレースホルダー)。月と曜日のフィールドでは大文字と小文字は区別されません (
SUN、Sun、sunは同等です)。曜日を省略した場合、デフォルトで*になります。cron 式の構文の詳細については、「cron 式」をご参照ください。
AHPA ポリシーを適用します：
kubectl apply -f ahpa-demo.yaml
ステップ 5: 予測の検証と自動スケーリングの有効化
AHPA は、過去 7 日間の既存データから予測を生成します。ポリシーを適用した後、予測が蓄積されるまで 7 日間待ちます。既存のアプリケーションに AHPA ポリシーを適用するには、AHPA ポリシー構成でアプリケーションを指定します。
7 日間の蓄積期間中に、構成が正しく機能していることを確認します：
# AHPA オブジェクトのステータスを確認
kubectl describe advancedhorizontalpodautoscaler ahpa-demo
# 予測されるレプリカ数が時間とともに更新されるのを監視
kubectl get advancedhorizontalpodautoscaler ahpa-demo -w7 日後、Prometheus ダッシュボードを使用して予測結果を確認します。設定手順については、「AHPA 用の Prometheus ダッシュボードを有効化する」をご参照ください。
この例では、AHPA は HPA ベースラインと並行して observer モードで実行されます。ダッシュボードには 2 つの比較チャートが表示されます：
CPU 使用量：緑色の線は実際の CPU 使用量 (HPA による) を示します。黄色の線は AHPA が予測した CPU 使用量を示します。
予測値は実際の値よりも高くなっています。これは、AHPA が十分なキャパシティを事前にプロビジョニングしていることを示します。
予測値は実際の値よりも早くピークに達します。これは、需要が発生する前にリソースが準備できていることを示します。
Pod 数：緑色の線は HPA によってプロビジョニングされた実際の Pod 数を示します。黄色の線は AHPA が予測した Pod 数を示します。
AHPA は短期的なスパイクを平滑化するため、予測された Pod 数 (黄色) は HPA の数 (緑色) よりも少なくなります。
黄色の曲線は緑色の曲線よりも滑らかです。急激な変更が少ないため、ワークロードの安定性が向上します。
自動スケーリングの有効化
予測が期待どおりになったら、AHPA を observer モードから auto モードに切り替えます。ahpa-demo.yaml を編集し、scaleStrategy を変更します：
scaleStrategy: auto次に、変更を適用します：
kubectl apply -f ahpa-demo.yamlこれで、AHPA は予測スケーリングを使用して fib-deployment を自動的にスケーリングします。