3.4. カスタムメトリックオートスケーラートリガーについて
スケーラーとも呼ばれるトリガーは、Custom Metrics Autoscaler Operator が Pod をスケーリングするために使用するメトリックを提供します。
カスタムメトリクスオートスケーラーは現在、Prometheus、CPU、メモリー、および Apache Kafka トリガーのみをサポートしています。
以下のセクションで説明するように、ScaledObject
または ScaledJob
カスタムリソースを使用して、特定のオブジェクトのトリガーを設定します。
3.4.1. Prometheus トリガーについて
Prometheus メトリクスに基づいて Pod をスケーリングできます。このメトリクスは、インストール済みの OpenShift Container Platform モニタリングまたは外部 Prometheus サーバーをメトリクスソースとして使用できます。OpenShift Container Platform モニタリングをメトリクスのソースとして使用するために必要な設定は、「関連情報」を参照してください。
カスタムメトリクスオートスケーラーがスケーリングしているアプリケーションから Prometheus がメトリクスを収集している場合は、カスタムリソースで最小レプリカ数を 0
に設定しないでください。アプリケーション Pod がない場合、カスタムメトリックオートスケーラーにはスケールするメトリックがありません。
Prometheus ターゲットを使用したスケーリングされたオブジェクトの例
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prom-scaledobject namespace: my-namespace spec: # ... triggers: - type: prometheus 1 metadata: serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 2 namespace: kedatest 3 metricName: http_requests_total 4 threshold: '5' 5 query: sum(rate(http_requests_total{job="test-app"}[1m])) 6 authModes: basic 7 cortexOrgID: my-org 8 ignoreNullValues: false 9 unsafeSsl: false 10
- 1
- Prometheus をトリガータイプとして指定します。
- 2
- Prometheus サーバーのアドレスを指定します。この例では、OpenShift Container Platform モニタリングを使用します。
- 3
- オプション: スケーリングするオブジェクトの namespace を指定します。メトリクスのソースとして OpenShift Container Platform モニタリングを使用する場合、このパラメーターは必須です。
- 4
external.metrics.k8s.io
API でメトリックを識別する名前を指定します。複数のトリガーを使用している場合、すべてのメトリック名は一意である必要があります。- 5
- スケーリングをトリガーする値を指定します。引用符で囲まれた文字列値として指定する必要があります。
- 6
- 使用する Prometheus クエリーを指定します。
- 7
- 使用する認証方法を指定します。Prometheus スケーラーは、ベアラー認証 (
bearer
)、基本認証 (basic
)、または TLS 認証 (tls
) をサポートしています。以下のセクションで説明するように、トリガー認証で特定の認証パラメーターを設定します。必要に応じて、シークレットを使用することもできます。 - 8
- 9
- オプション: Prometheus ターゲットが失われた場合のトリガーの処理方法を指定します。
-
true
の場合、Prometheus ターゲットが失われても、トリガーは動作し続けます。これがデフォルトの動作です。 -
false
の場合、Prometheus ターゲットが失われると、トリガーはエラーを返します。
-
- 10
- オプション: 証明書チェックをスキップするかどうかを指定します。たとえば、Prometheus エンドポイントで自己署名証明書を使用する場合は、チェックをスキップできます。
-
true
の場合、証明書チェックが実行されます。 -
false
の場合、証明書チェックは実行されません。これがデフォルトの動作です。
-
3.4.1.1. Configuring the custom metrics autoscaler to use OpenShift Container Platform monitoring
カスタムメトリクスオートスケーラーが使用するメトリクスのソースとして、インストール済みの OpenShift Container Platform Prometheus モニタリングを使用できます。ただし、実行する必要がある追加の設定がいくつかあります。
これらの手順は、外部 Prometheus ソースには必要ありません。
このセクションで説明するように、次のタスクを実行する必要があります。
- トークンを取得するためのサービスアカウントを作成します。
- ロールを作成します。
- そのロールをサービスアカウントに追加します。
- Prometheus が使用するトリガー認証オブジェクトでトークンを参照します。
前提条件
- OpenShift Container Platform モニタリングをインストールしている必要がある。
- ユーザー定義のワークロードのモニタリングを、OpenShift Container Platform モニタリングで有効にする必要がある (ユーザー定義のワークロードモニタリング設定マップの作成 セクションで説明)。
- Custom Metrics Autoscaler Operator をインストールしている必要がある。
手順
スケーリングするオブジェクトを含むプロジェクトに変更します。
$ oc project my-project
クラスターにサービスアカウントがない場合は、次のコマンドを使用してサービスアカウントを作成します。
$ oc create serviceaccount <service_account>
ここでは、以下のようになります。
- <service_account>
- サービスアカウントの名前を指定します。
次のコマンドを使用して、サービスアカウントに割り当てられたトークンを見つけます。
$ oc describe serviceaccount <service_account>
ここでは、以下のようになります。
- <service_account>
- サービスアカウントの名前を指定します。
出力例
Name: thanos Namespace: my-project Labels: <none> Annotations: <none> Image pull secrets: thanos-dockercfg-nnwgj Mountable secrets: thanos-dockercfg-nnwgj Tokens: thanos-token-9g4n5 1 Events: <none>
- 1
- トリガー認証でこのトークンを使用します。
サービスアカウントトークンを使用してトリガー認証を作成します。
以下のような YAML ファイルを作成します。
apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-prometheus spec: secretTargetRef: 1 - parameter: bearerToken 2 name: thanos-token-9g4n5 3 key: token 4 - parameter: ca name: thanos-token-9g4n5 key: ca.crt
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
Thanos メトリックを読み取るためのロールを作成します。
次のパラメーターを使用して YAML ファイルを作成します。
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: thanos-metrics-reader rules: - apiGroups: - "" resources: - pods verbs: - get - apiGroups: - metrics.k8s.io resources: - pods - nodes verbs: - get - list - watch
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
Thanos メトリックを読み取るためのロールバインディングを作成します。
以下のような YAML ファイルを作成します。
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: thanos-metrics-reader 1 namespace: my-project 2 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: thanos-metrics-reader subjects: - kind: ServiceAccount name: thanos 3 namespace: my-project 4
CR オブジェクトを作成します。
$ oc create -f <file-name>.yaml
「カスタムメトリクスオートスケーラーの追加方法について」で説明されているとおり、スケーリングされたオブジェクトまたはスケーリングされたジョブをデプロイして、アプリケーションの自動スケーリングを有効化できます。OpenShift Container Platform モニタリングをソースとして使用するには、トリガーまたはスケーラーに以下のパラメーターを含める必要があります。
-
triggers.type
はprometheus
にしてください。 -
triggers.metadata.serverAddress
はhttps://thanos-querier.openshift-monitoring.svc.cluster.local:9092
にしてください。 -
triggers.metadata.authModes
はbearer
にしてください。 -
triggers.metadata.namespace
は、スケーリングするオブジェクトの namespace に設定してください。 -
triggers.authenticationRef
は、直前の手順で指定されたトリガー認証リソースを指す必要があります。
3.4.2. CPU トリガーについて
CPU メトリクスに基づいて Pod をスケーリングできます。このトリガーは、クラスターメトリクスをメトリクスのソースとして使用します。
カスタムメトリクスオートスケーラーは、オブジェクトに関連付けられた Pod をスケーリングして、指定された CPU 使用率を維持します。オートスケーラーは、すべての Pod で指定された CPU 使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。メモリートリガーは、Pod 全体のメモリー使用率を考慮します。Pod に複数のコンテナーがある場合、メモリートリガーは Pod 内にあるすべてのコンテナーの合計メモリー使用率を考慮します。
-
このトリガーは、
ScaledJob
カスタムリソースでは使用できません。 -
メモリートリガーを使用してオブジェクトをスケーリングすると、複数のトリガーを使用している場合でも、オブジェクトは
0
にスケーリングされません。
CPU ターゲットを使用してスケーリングされたオブジェクトの例
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: my-namespace spec: # ... triggers: - type: cpu 1 metricType: Utilization 2 metadata: value: '60' 3 containerName: api 4
- 1
- トリガータイプとして CPU を指定します。
- 2
- 使用するメトリックのタイプ (
Utilization
またはAverageValue
のいずれか) を指定します。 - 3
- スケーリングをトリガーする値を指定します。引用符で囲まれた文字列値として指定する必要があります。
-
Utilization
を使用する場合、ターゲット値は、関連する全 Pod のリソースメトリクスの平均値であり、Pod のリソースの要求値に占めるパーセンテージとして表されます。 -
AverageValue
を使用する場合、ターゲット値は、関連する全 Pod のメトリクスの平均値です。
-
- 4
- オプション: Pod 全体ではなく、そのコンテナーのみのメモリー使用率に基づいて、スケーリングする個々のコンテナーを指定します。この例では、
api
という名前のコンテナーのみがスケーリングされます。
3.4.3. メモリートリガーについて
メモリーメトリクスに基づいて Pod をスケーリングできます。このトリガーは、クラスターメトリクスをメトリクスのソースとして使用します。
カスタムメトリクスオートスケーラーは、オブジェクトに関連付けられた Pod をスケーリングして、指定されたメモリー使用率を維持します。オートスケーラーは、すべての Pod で指定のメモリー使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。メモリートリガーは、Pod 全体のメモリー使用率を考慮します。Pod に複数のコンテナーがある場合、メモリー使用率はすべてのコンテナーの合計になります。
-
このトリガーは、
ScaledJob
カスタムリソースでは使用できません。 -
メモリートリガーを使用してオブジェクトをスケーリングすると、複数のトリガーを使用している場合でも、オブジェクトは
0
にスケーリングされません。
メモリーターゲットを使用してスケーリングされたオブジェクトの例
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: my-namespace spec: # ... triggers: - type: memory 1 metricType: Utilization 2 metadata: value: '60' 3 containerName: api 4
- 1
- トリガータイプとしてメモリーを指定します。
- 2
- 使用するメトリックのタイプ (
Utilization
またはAverageValue
のいずれか) を指定します。 - 3
- スケーリングをトリガーする値を指定します。引用符で囲まれた文字列値として指定する必要があります。
-
Utilization
を使用する場合、ターゲット値は、関連する全 Pod のリソースメトリクスの平均値であり、Pod のリソースの要求値に占めるパーセンテージとして表されます。 -
AverageValue
を使用する場合、ターゲット値は、関連する全 Pod のメトリクスの平均値です。
-
- 4
- オプション: Pod 全体ではなく、そのコンテナーのみのメモリー使用率に基づいて、スケーリングする個々のコンテナーを指定します。この例では、
api
という名前のコンテナーのみがスケーリングされます。
3.4.4. Kafka トリガーについて
Apache Kafka トピックまたは Kafka プロトコルをサポートするその他のサービスに基づいて Pod をスケーリングできます。カスタムメトリクスオートスケーラーは、スケーリングされるオブジェクトまたはスケーリングされるジョブで allowIdleConsumers
パラメーターを true
に設定しない限り、Kafka パーティションの数を超えてスケーリングしません。
コンシューマーグループの数がトピック内のパーティションの数を超えると、余分なコンシューマーグループはそのままアイドル状態になります。これを回避するために、デフォルトではレプリカの数は次の値を超えません。
- トピックのパーティションの数 (トピックが指定されている場合)。
- コンシューマーグループ内の全トピックのパーティション数 (トピックが指定されていない場合)。
-
スケーリングされるオブジェクトまたはスケーリングされるジョブの CR で指定された
maxReplicaCount
。
これらのデフォルトの動作は、allowIdleConsumers
パラメーターを使用して無効にすることができます。
Kafka ターゲットを使用してスケーリングされたオブジェクトの例
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: my-namespace spec: # ... triggers: - type: kafka 1 metadata: topic: my-topic 2 bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 3 consumerGroup: my-group 4 lagThreshold: '10' 5 activationLagThreshold: '5' 6 offsetResetPolicy: latest 7 allowIdleConsumers: true 8 scaleToZeroOnInvalidOffset: false 9 excludePersistentLag: false 10 version: '1.0.0' 11 partitionLimitation: '1,2,10-20,31' 12
- 1
- トリガータイプとして Kafka を指定します。
- 2
- Kafka がオフセットラグを処理している Kafka トピックの名前を指定します。
- 3
- 接続する Kafka ブローカーのコンマ区切りリストを指定します。
- 4
- トピックのオフセットの確認と、関連するラグの処理に使用される Kafka コンシューマーグループの名前を指定します。
- 5
- オプション: スケーリングをトリガーする平均ターゲット値を指定します。引用符で囲まれた文字列値として指定する必要があります。デフォルトは
5
です。 - 6
- オプション: アクティベーションフェーズのターゲット値を指定します。引用符で囲まれた文字列値として指定する必要があります。
- 7
- オプション: Kafka コンシューマーの Kafka オフセットリセットポリシーを指定します。使用可能な値は
latest
およびearliest
です。デフォルトはlatest
です。 - 8
- オプション: Kafka レプリカの数がトピックのパーティションの数を超えることを許可するかどうかを指定します。
-
true
の場合、Kafka レプリカの数はトピックのパーティションの数を超えることができます。これにより、Kafka コンシューマーがアイドル状態になることが許容されます。 -
false
の場合、Kafka レプリカの数はトピックのパーティションの数を超えることはできません。これはデフォルトになります。
-
- 9
- Kafka パーティションに有効なオフセットがない場合のトリガーの動作を指定します。
-
true
の場合、そのパーティションのコンシューマーはゼロにスケーリングされます。 -
false
の場合、スケーラーはそのパーティションのために 1 つのコンシューマーを保持します。これはデフォルトになります。
-
- 10
- オプション: 現在のオフセットが前のポーリングサイクルの現在のオフセットと同じであるパーティションのパーティションラグをトリガーに含めるか除外するかを指定します。
-
true
の場合、スケーラーはこれらのパーティションのパーティションラグを除外します。 -
false
の場合、すべてのパーティションのコンシューマーラグがすべてトリガーに含まれます。これはデフォルトになります。
-
- 11
- オプション: Kafka ブローカーのバージョンを指定します。引用符で囲まれた文字列値として指定する必要があります。デフォルトは
1.0.0
です。 - 12
- オプション: スケーリングのスコープを適用するパーティション ID のコンマ区切りリストを指定します。指定されている場合、ラグの計算時にリスト内の ID のみが考慮されます。引用符で囲まれた文字列値として指定する必要があります。デフォルトでは、すべてのパーティションが考慮されます。