Container Service for Kubernetesは、Advanced Horizontal Pod Autoscaler (AHPA) をサポートしています。 AHPAは、過去データを学習および分析してポッドレプリカの数を動的に調整することにより、将来のリソース需要を予測します。 これは、リソースが予測される需要ピークに先立ってスケールアウトされ、プリフェッチされることを保証し、システムの応答速度および安定性を高める。 逆に、AHPAは、リソースコストを節約するために、予測される需要の谷に先立ってリソースを縮小します。
前提条件
ACK管理クラスターまたはACKサーバーレスクラスターが作成されます。 詳細については、「ACKマネージドクラスターの作成」または「ACKサーバーレスクラスターの作成」をご参照ください。
Prometheusのマネージドサービス (Prometheus) が有効になり、少なくとも過去7日間のアプリケーション統計がPrometheusによって収集されます。 統計には、アプリケーションによって使用されるCPUおよびメモリリソースの詳細が含まれます。 Prometheusを有効にする方法の詳細については、「Prometheusのマネージドサービス」をご参照ください。
ステップ1: AHPAコントローラのインストール
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
[アドオン] ページで、AHPA Controllerカードを見つけます。 AHPA Controllerカードで [インストール] をクリックし、画面の指示に従ってコンポーネントをインストールします。
ステップ2: Prometheusをデータソースとして追加する
ARMSコンソールにログインします。
左側のナビゲーションウィンドウで、を選択します。
[インスタンス] ページの左上隅で、Prometheusインスタンスがデプロイされているリージョンを選択します。 管理するPrometheusインスタンスを見つけ、その名前をクリックします。 Prometheusインスタンスの名前は、ACKクラスターの名前と同じです。
[設定] ページで、[HTTP API URL (Grafana読み取りURL)] セクションを見つけ、次の情報を記録します。
必要に応じて、 アクセストークンが有効になっている場合は、クラスターのアクセストークンを設定する必要があります。
内部エンドポイントを表示および記録します。
ACKクラスター設定でPrometheusインスタンスのエンドポイントを指定します。
application-intelligence.yamlという名前のファイルを作成します。 次の内容をコピーしてファイルに貼り付けます。
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"
説明AHPAダッシュボードに表示されるPrometheus Serviceメトリクスを表示する場合は、ConfigMapで次のパラメーターを設定します。
prometheus_writer_url
: Prometheusインスタンスの内部リモート書き込みエンドポイントを指定します。prometheus_writer_ak
: Alibaba CloudアカウントのAccessKey IDを指定します。prometheus_writer_sk
: Alibaba CloudアカウントのAccessKeyシークレットを指定します。
詳細については、「Prometheus For AHPAのマネージドサービスの有効化」をご参照ください。
次のコマンドを実行してapplication-intelligenceをデプロイします。
kubectl apply -f application-intelligence.yaml
手順3: テストサービスのデプロイ
fib-Deploymentという名前のdeploymentとfib-svcという名前のserviceで構成されるテストサービスをデプロイします。 トラフィック変動をシミュレートするためにテストサービスに要求を送信するために使用されるfib-loaderという名前のアプリケーションをデプロイします。 次に、Horizontal Pod Autoscaler (HPA) を展開して、テストサービスをスケーリングします。 これにより、HPAスケーリングの結果とAHPA予測の結果を比較できます。
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
---
ステップ4: AHPAのデプロイ
AHPAをデプロイして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 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: fib-deployment maxReplicas: 100 minReplicas: 2 stabilizationWindowSeconds: 300 prediction: quantile: 95 scaleUpForward: 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
可
予測スケーリングを設定する対象のデプロイ。
メトリクス
可
AHPAポリシーの実装に基づくメトリック。 次のメトリックがサポートされています: CPU、GPU、メモリ、1秒あたりのクエリ数 (QPS) 、および応答時間 (RT) 。
ターゲット
可
スケーリングしきい値。 たとえば、
averageUtilization: 40
を指定した場合、スケーリングを開始するためのCPU使用率のしきい値は40% です。scaleStrategy
不可
AHPAのスケーリングモード。 デフォルト値: observer。 有効な値:
auto: AHPAは自動的にスケーリング操作を実行します。
observer: AHPAはリソース使用量を監視しますが、スケーリング操作は実行しません。 オブザーバーモードを使用して、AHPAが期待どおりに機能するかどうかを確認できます。
scalingUpOnly: AHPAはスケールアウト操作のみを実行しますが、スケールイン操作は実行しません。
proactive: アクティブな予測のみが有効になります。
reactive: パッシブ予測のみが有効になります。
maxReplicas
可
許可されるレプリケートポッドの最大数。
minReplicas
可
保証する必要があるレプリケートされたポッドの最小数。
stabilizationWindowSeconds
不可
スケールイン活動のクールダウン時間。 デフォルト値は 300 です。 単位は秒です。
予測を実行します。 quantile
可
実際のメトリック値がスケーリングしきい値を下回ると予想される分位数。 値が大きいほど、より保守的な予測を示します。これは、システムがビジネスの安定性を確保するためにリソースをスケールインまたはスケールアウトする可能性が高いことを示します。 有効な値は 0~1 です。 デフォルト値: 0.99 値は小数点以下2桁まで正確です。 パラメーターを0.90から0.99の値に設定することを推奨します。
予測を実行します。 scaleUpForward
可
コールドスタートの継続時間。ポッドが作成された時点からポッドが準備完了状態にある時点までの期間です。
instanceBounds
不可
スケーリング操作の期間。 複製ポッドの数は、AHPAで定義されている複製ポッドの最大数と最小数によって制限されます。
startTime: スケーリング操作の開始時刻。
endTime: スケーリング操作の終了時刻。
instanceBounds。 bounds。 cron
不可
このパラメーターは、スケジュールされたスケーリングジョブを作成するために使用されます。 CRON式
- cron: "* 0-8? * MON-FRI "
は、スケーリングジョブを毎月月曜日から金曜日の00:00:00から08:00:00まで実行することを指定します。次の表に、CRON式に含まれるフィールドを示します。 詳細については、「Cron式」をご参照ください。
項目
必須 / 任意
有効値
有効な特殊文字
分
可
0から59
* / , -
時間
可
0から23
* / , -
月の日
可
1から31
* / , – ?
1 か月
可
1〜12またはJAN〜DEC
* / , -
バックアップ日付
不可
0に6またはSUNにSAT
* / , – ?
説明月と曜日のフィールドは大文字と小文字を区別しません。 たとえば、
SUN
、Sun
、またはsun
を指定できます。曜日フィールドを指定しない場合、デフォルト値
*
が使用されます。次のリストでは、特殊文字について説明します。
*
: 任意の値を指定します。/
: インクリメントを指定します。,
: 値のリストを区切ります。-
: 範囲を指定します。?
: プレースホルダーを指定します。
次のコマンドを実行して、AHPAポリシーを適用します。
kubectl apply -f fib-deployment.yaml
ステップ5: 予測結果を表示する
AHPAが期待どおりに機能するかどうかを確認します。 Prometheusを使用して結果を表示できます。 詳細については、「Prometheus For AHPAのマネージドサービスの有効化」をご参照ください。
AHPA予測結果は、過去7日間の履歴データに基づいて生成されます。 したがって、AHPAポリシーを適用してから7日待つ必要があります。 既存のアプリケーションにAHPAポリシーを適用するには、AHPAポリシー設定でアプリケーションを指定します。
この例では、AHPAポリシーはオブザーバー
スケーリングモードを使用します。 次の図は、HPAスケーリング結果と比較されるAHPA予測結果を示しています。 HPAスケーリングの結果は、アプリケーションランタイム中の実際のリソース消費を示す。 比較を使用して、AHPA予測結果が期待どおりであるかどうかを確認できます。
実際のCPU使用量と予測CPU使用量: HPAに基づく実際のCPU使用量は緑色の線で表されます。 AHPAによって予測されるCPU使用率は、黄色の線によって表される。
上の図は、予測されるCPU使用率が実際のCPU使用率よりも高いことを示しています。 これは、予測されるCPU容量が十分であることを示す。
上の図は、予測されたCPU使用率が実際のCPU使用率よりも早く特定の値に達することを示しています。 これは、必要なリソースが予め用意されていることを示す。
ポッドの傾向: HPAによってプロビジョニングされたポッドの実際の数は、緑色の線で表されます。 AHPAによって予測されるポッドの数は、黄色の線によって表される。
前の図は、黄色の線で表される値が緑色の線で表される値よりも小さいことを示しています。 これは、ポッドの予測数が実際のポッド数よりも少ないことを示しています。
上の図は、黄色のカーブが緑色のカーブよりも滑らかであることを示しています。 これは、AHPAスケーリングサービスを使用することによるポッド数の変化が穏やかであり、ビジネスの安定性が向上することを示しています。
結果は、AHPAが予測スケーリングを使用して、変動するワークロードを予想どおりに処理できることを示しています。 予測結果を確認したら、スケーリングモードをauto
に設定できます。これにより、AHPAはポッドを自動的にスケーリングできます。
関連ドキュメント
Prometheusを使用してGPUメトリックを監視する方法、およびAHPAを使用してGPUメトリックに基づいて予測スケーリングを実行する方法の詳細については、「AHPAを使用してGPUメトリックに基づいて予測スケーリングを実行する」をご参照ください。
Prometheusが提供するダッシュボードを使用してアプリケーションを監視する方法の詳細については、「Prometheus For AHPAのマネージドサービスの有効化」をご参照ください。