3.10. カスタムメトリクスオートスケーラーの追加方法について
カスタムメトリクスオートスケーラーを追加するには、デプロイメント、ステートフルセット、またはカスタムリソース用の ScaledObject
カスタムリソースを作成します。ジョブの ScaledJob
カスタムリソースを作成します。
スケーリングするワークロードごとに、スケーリングされたオブジェクトを 1 つだけ作成できます。スケーリングされたオブジェクトと水平 Pod オートスケーラー (HPA) は、同じワークロードで使用できません。
3.10.1. ワークロードへのカスタムメトリクスオートスケーラーの追加
Deployment
、StatefulSet
、または custom resource
オブジェクトによって作成されるワークロード用のカスタムメトリクスオートスケーラーを作成できます。
前提条件
- Custom Metrics Autoscaler Operator をインストールしている。
CPU またはメモリーに基づくスケーリングにカスタムメトリクスオートスケーラーを使用する場合:
クラスター管理者は、クラスターメトリクスを適切に設定する必要があります。メトリクスが設定されているかどうかは、
oc describe PodMetrics <pod-name>
コマンドを使用して判断できます。メトリクスが設定されている場合、出力は以下の Usage の下にある CPU と Memory のように表示されます。$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
出力例
Name: openshift-kube-scheduler-ip-10-0-135-131.ec2.internal Namespace: openshift-kube-scheduler Labels: <none> Annotations: <none> API Version: metrics.k8s.io/v1beta1 Containers: Name: wait-for-host-port Usage: Memory: 0 Name: scheduler Usage: Cpu: 8m Memory: 45440Ki Kind: PodMetrics Metadata: Creation Timestamp: 2019-05-23T18:47:56Z Self Link: /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal Timestamp: 2019-05-23T18:47:56Z Window: 1m0s Events: <none>
スケーリングするオブジェクトに関連付けられた Pod には、指定されたメモリーと CPU の制限が含まれている必要があります。以下に例を示します。
Pod 仕様の例
apiVersion: v1 kind: Pod # ... spec: containers: - name: app image: images.my-company.example/app:v4 resources: limits: memory: "128Mi" cpu: "500m" # ...
手順
以下のような YAML ファイルを作成します。名前
<2>
、オブジェクト名<4>
、およびオブジェクトの種類<5>
のみが必要です。スケーリングされたオブジェクトの例
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" 1 name: scaledobject 2 namespace: my-namespace spec: scaleTargetRef: apiVersion: apps/v1 3 name: example-deployment 4 kind: Deployment 5 envSourceContainerName: .spec.template.spec.containers[0] 6 cooldownPeriod: 200 7 maxReplicaCount: 100 8 minReplicaCount: 0 9 metricsServer: 10 auditConfig: logFormat: "json" logOutputVolumeClaim: "persistentVolumeClaimName" policy: rules: - level: Metadata omitStages: "RequestReceived" omitManagedFields: false lifetime: maxAge: "2" maxBackup: "1" maxSize: "50" fallback: 11 failureThreshold: 3 replicas: 6 pollingInterval: 30 12 advanced: restoreToOriginalReplicaCount: false 13 horizontalPodAutoscalerConfig: name: keda-hpa-scale-down 14 behavior: 15 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: - type: prometheus 16 metadata: serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 namespace: kedatest metricName: http_requests_total threshold: '5' query: sum(rate(http_requests_total{job="test-app"}[1m])) authModes: basic authenticationRef: 17 name: prom-triggerauthentication kind: TriggerAuthentication
- 1
- オプション: 「ワークロードのカスタムメトリクスオートスケーラーの一時停止」セクションで説明されているように、Custom Metrics Autoscaler Operator がレプリカを指定された値にスケーリングし、自動スケーリングを停止するよう指定します。
- 2
- このカスタムメトリクスオートスケーラーの名前を指定します。
- 3
- オプション: ターゲットリソースの API バージョンを指定します。デフォルトは
apps/v1
です。 - 4
- スケーリングするオブジェクトの名前を指定します。
- 5
kind
をDeployment
、StatefulSet
またはCustomResource
として指定します。- 6
- オプション: カスタムメトリクスオートスケーラーがシークレットなどを保持する環境変数を取得する、ターゲットリソース内のコンテナーの名前を指定します。デフォルトは
.spec.template.spec.containers[0]
です。 - 7
- オプション:
minReplicaCount
が0
に設定されている場合、最後のトリガーが報告されてからデプロイメントを0
にスケールバックするまでの待機時間を秒単位で指定します。デフォルトは300
です。 - 8
- オプション: スケールアップ時のレプリカの最大数を指定します。デフォルトは
100
です。 - 9
- オプション: スケールダウン時のレプリカの最小数を指定します。
- 10
- オプション: 「監査ログの設定」セクションで説明されているように、監査ログのパラメーターを指定します。
- 11
- オプション:
failureThreshold
パラメーターで定義された回数だけスケーラーがソースからメトリクスを取得できなかった場合に、フォールバックするレプリカの数を指定します。フォールバック動作の詳細は、KEDA のドキュメント を参照してください。 - 12
- オプション: 各トリガーをチェックする間隔を秒単位で指定します。デフォルトは
30
です。 - 13
- オプション: スケーリングされたオブジェクトが削除された後に、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します。デフォルトは
false
で、スケーリングされたオブジェクトが削除されたときのレプリカ数をそのまま保持します。 - 14
- オプション: Horizontal Pod Autoscaler の名前を指定します。デフォルトは
keda-hpa-{scaled-object-name}
です。 - 15
- オプション: 「スケーリングポリシー」セクションで説明されているように、Pod をスケールアップまたはスケールダウンするレートを制御するために使用するスケーリングポリシーを指定します。
- 16
- 「カスタムメトリクスオートスケーラートリガーについて」セクションで説明されているように、スケーリングの基準として使用するトリガーを指定します。この例では、Red Hat OpenShift Service on AWS モニタリングを使用します。
- 17
- オプション: トリガー認証またはクラスタートリガー認証を指定します。詳細は、関連情報 セクションの カスタムメトリクスオートスケーラー認証について を参照してください。
-
トリガー認証を使用するには、
TriggerAuthentication
と入力します。これはデフォルトになります。 -
クラスタートリガー認証を使用するには、
ClusterTriggerAuthentication
と入力します。
-
トリガー認証を使用するには、
次のコマンドを実行して、カスタムメトリクスオートスケーラーを作成します。
$ oc create -f <filename>.yaml
検証
コマンド出力を表示して、カスタムメトリクスオートスケーラーが作成されたことを確認します。
$ oc get scaledobject <scaled_object_name>
出力例
NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE scaledobject apps/v1.Deployment example-deployment 0 50 prometheus prom-triggerauthentication True True True 17s
出力の次のフィールドに注意してください。
-
TRIGGERS
: 使用されているトリガーまたはスケーラーを示します。 -
AUTHENTICATION
: 使用されているトリガー認証の名前を示します。 READY
: スケーリングされたオブジェクトがスケーリングを開始する準備ができているかどうかを示します。-
True
の場合、スケーリングされたオブジェクトの準備は完了しています。 -
False
の場合、作成したオブジェクトの 1 つ以上に問題があるため、スケーリングされたオブジェクトの準備は完了していません。
-
ACTIVE
: スケーリングが行われているかどうかを示します。-
True
の場合、スケーリングが行われています。 -
False
の場合、メトリクスがないか、作成したオブジェクトの 1 つ以上に問題があるため、スケーリングは行われていません。
-
FALLBACK
: カスタムメトリクスオートスケーラーがソースからメトリクスを取得できるかどうかを示します。-
False
の場合、カスタムメトリクスオートスケーラーはメトリクスを取得しています。 -
True
の場合、メトリクスがないか、作成したオブジェクトの 1 つ以上に問題があるため、カスタムメトリクスオートスケーラーはメトリクスを取得しています。
-
-