3.4. カスタムメトリクスオートスケーラートリガーについて
スケーラーとも呼ばれるトリガーは、Custom Metrics Autoscaler Operator が Pod をスケーリングするために使用するメトリクスを提供します。
カスタムメトリクスオートスケーラーは現在、Prometheus、CPU、メモリー、および Apache Kafka トリガーのみをサポートしています。
以下のセクションで説明するように、ScaledObject
または ScaledJob
カスタムリソースを使用して、特定のオブジェクトのトリガーを設定します。
scaled object で使用 する認証局、または クラスター内のすべてのスケーラー用 の認証局を設定できます。
3.4.1. Prometheus トリガーについて
Prometheus メトリクスに基づいて Pod をスケーリングできます。このメトリクスは、インストール済みの OpenShift Container Platform モニタリングまたは外部 Prometheus サーバーをメトリクスソースとして使用できます。OpenShift Container Platform モニタリングをメトリクスのソースとして使用するために必要な設定は、「OpenShift Container Platform モニタリングを使用するためのカスタムメトリクスオートスケーラーの設定」を参照してください。
カスタムメトリクスオートスケーラーがスケーリングしているアプリケーションから Prometheus がメトリクスを収集している場合は、カスタムリソースで最小レプリカ数を 0
に設定しないでください。アプリケーション Pod がないと、カスタムメトリクスオートスケーラーにスケーリングの基準となるメトリクスが提供されません。
Prometheus ターゲットを使用した scaled object の例
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 認証 (basic
)、または TLS 認証 (tls
) をサポートしています。以下のセクションで説明するように、トリガー認証で特定の認証パラメーターを設定します。必要に応じて、シークレットを使用することもできます。 - 8
- 9
- オプション: Prometheus ターゲットが失われた場合のトリガーの処理方法を指定します。
-
true
の場合、Prometheus ターゲットが失われても、トリガーは動作し続けます。これがデフォルトの動作です。 -
false
の場合、Prometheus ターゲットが失われると、トリガーはエラーを返します。
-
- 10
- オプション: 証明書チェックをスキップするかどうかを指定します。たとえば、テスト環境で実行しており、Prometheus エンドポイントで自己署名証明書を使用している場合は、チェックをスキップできます。
-
false
の場合、証明書のチェックが実行されます。これがデフォルトの動作です。 true
の場合、証明書のチェックは実行されません。重要チェックのスキップは推奨されません。
-
3.4.1.1. OpenShift Container Platform モニタリングを使用するためのカスタムメトリクスオートスケーラーの設定
カスタムメトリクスオートスケーラーが使用するメトリクスのソースとして、インストール済みの OpenShift Container Platform Prometheus モニタリングを使用できます。ただし、実行する必要がある追加の設定がいくつかあります。
これらの手順は、外部 Prometheus ソースには必要ありません。
このセクションで説明するように、次のタスクを実行する必要があります。
- サービスアカウントを作成します。
- サービスアカウントのトークンを生成するシークレットを作成します。
- トリガー認証を作成します。
- ロールを作成します。
- そのロールをサービスアカウントに追加します。
- Prometheus が使用するトリガー認証オブジェクトでトークンを参照します。
前提条件
- OpenShift Container Platform モニタリングをインストールしている必要がある。
- ユーザー定義のワークロードのモニタリングを、OpenShift Container Platform モニタリングで有効にする必要がある (ユーザー定義のワークロードモニタリング設定マップの作成 セクションで説明)。
- Custom Metrics Autoscaler Operator をインストールしている。
手順
スケーリングするオブジェクトを含むプロジェクトに変更します。
$ oc project my-project
クラスターにサービスアカウントおよびトークンがない場合は、これを作成します。
次のコマンドを使用して、
service account
オブジェクトを作成します。$ oc create serviceaccount thanos 1
- 1
- サービスアカウントの名前を指定します。
secret
YAML を作成し、サービスアカウントトークンを生成します。重要ImageRegistry
機能を無効にした場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にした場合、イメージプルシークレットはサービスアカウントごとに生成されません。この状況では、この手順を実行する必要があります。apiVersion: v1 kind: Secret metadata: name: thanos-token annotations: kubernetes.io/service-account.name: thanos 1 type: kubernetes.io/service-account-token
- 1
- サービスアカウントの名前を指定します。
次のコマンドを使用してシークレットオブジェクトを作成します。
$ oc create -f <file_name>.yaml
次のコマンドを使用して、サービスアカウントに割り当てられたトークンを見つけます。
$ oc describe serviceaccount thanos 1
- 1
- サービスアカウントの名前を指定します。
出力例
Name: thanos Namespace: my-project Labels: <none> Annotations: <none> Image pull secrets: thanos-dockercfg-nnwgj Mountable secrets: thanos-dockercfg-nnwgj Tokens: thanos-token 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 3 key: token 4 - parameter: ca name: thanos-token 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 ターゲットを使用した scaled object の例
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 minReplicaCount: 1 4
- 1
- トリガータイプとして CPU を指定します。
- 2
- 使用するメトリクスのタイプ (
Utilization
またはAverageValue
のいずれか) を指定します。 - 3
- スケーリングをトリガーする値を指定します。引用符で囲まれた文字列値として指定する必要があります。
-
Utilization
を使用する場合、ターゲット値は、関連する全 Pod のリソースメトリクスの平均値であり、Pod のリソースの要求値に占めるパーセンテージとして表されます。 -
AverageValue
を使用する場合、ターゲット値は、関連する全 Pod のメトリクスの平均値です。
-
- 4
- スケールダウン時のレプリカの最小数を指定します。CPU トリガーの場合は、
1
以上の値を入力します。CPU メトリクスのみを使用している場合、HPA はゼロにスケールできないためです。
3.4.3. メモリートリガーについて
メモリーメトリクスに基づいて Pod をスケーリングできます。このトリガーは、クラスターメトリクスをメトリクスのソースとして使用します。
カスタムメトリクスオートスケーラーは、オブジェクトに関連付けられた Pod をスケーリングして、指定されたメモリー使用率を維持します。オートスケーラーは、すべての Pod で指定のメモリー使用率を維持するために、最小数と最大数の間でレプリカ数を増減します。メモリートリガーは、Pod 全体のメモリー使用率を考慮します。Pod に複数のコンテナーがある場合、メモリー使用率はすべてのコンテナーの合計になります。
-
このトリガーは、
ScaledJob
カスタムリソースでは使用できません。 -
メモリートリガーを使用してオブジェクトをスケーリングすると、複数のトリガーを使用している場合でも、オブジェクトは
0
にスケーリングされません。
メモリーターゲットを使用した scaled object の例
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 ターゲットを使用した scaled object の例
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 tls: enable 13
- 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 のみが考慮されます。引用符で囲まれた文字列値として指定する必要があります。デフォルトでは、すべてのパーティションが考慮されます。
- 13
- オプション: Kafka に TSL クライアント認証を使用するかどうかを指定します。デフォルトは
disable
です。TLS の設定の詳細は、「カスタムメトリクスオートスケーラートリガー認証について」を参照してください。
3.4.5. Cron トリガーについて
Pod は時間範囲に基づいてスケーリングできます。
時間範囲の開始時に、カスタムメトリクスオートスケーラーが、オブジェクトに関連する Pod を、設定された最小 Pod 数から指定された必要な Pod 数にスケーリングします。時間範囲の終了時に、Pod は設定された最小値にスケールダウンされます。期間は cron 形式 で設定する必要があります。
次の例では、この scaled object に関連する Pod を、インド標準時の午前 6 時から午後 6 時 30 分まで 0
から 100
にスケーリングします。
Cron トリガーを使用した scaled object の例
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 1 maxReplicaCount: 100 2 cooldownPeriod: 300 triggers: - type: cron 3 metadata: timezone: Asia/Kolkata 4 start: "0 6 * * *" 5 end: "30 18 * * *" 6 desiredReplicas: "100" 7
- 1
- 時間枠の終了時にスケールダウンする Pod の最小数を指定します。
- 2
- スケールアップ時のレプリカの最大数を指定します。この値は
desiredReplicas
と同じである必要があります。デフォルトは100
です。 - 3
- Cron トリガーを指定します。
- 4
- 時間枠のタイムゾーンを指定します。この値は、IANA Time Zone Database から取得する必要があります。
- 5
- 時間枠の始点を指定します。
- 6
- 時間枠の終点を指定します。
- 7
- 時間枠の始点から終点までの間にスケーリングする Pod の数を指定します。この値は
maxReplicaCount
と同じである必要があります。