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
オプション: X-Scope-OrgID ヘッダーを Prometheus のマルチテナント Cortex または Mimir ストレージに渡します。このパラメーターは、Prometheus が返す必要のあるデータを示すために、マルチテナント Prometheus ストレージでのみ必要です。
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 をインストールしている必要がある。

手順

  1. スケーリングするオブジェクトを含むプロジェクトに変更します。

    $ oc project my-project
  2. クラスターにサービスアカウントがない場合は、次のコマンドを使用してサービスアカウントを作成します。

    $ oc create serviceaccount <service_account>

    ここでは、以下のようになります。

    <service_account>
    サービスアカウントの名前を指定します。
  3. 次のコマンドを使用して、サービスアカウントに割り当てられたトークンを見つけます。

    $ 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
    トリガー認証でこのトークンを使用します。
  4. サービスアカウントトークンを使用してトリガー認証を作成します。

    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
      1
      このオブジェクトが承認にシークレットを使用することを指定します。
      2
      トークンを使用して提供する認証パラメーターを指定します。
      3
      使用するトークンの名前を指定します。
      4
      指定されたパラメーターで使用するトークン内のキーを指定します。
    2. CR オブジェクトを作成します。

      $ oc create -f <file-name>.yaml
  5. Thanos メトリックを読み取るためのロールを作成します。

    1. 次のパラメーターを使用して 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
    2. CR オブジェクトを作成します。

      $ oc create -f <file-name>.yaml
  6. Thanos メトリックを読み取るためのロールバインディングを作成します。

    1. 以下のような 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
      1
      作成したロールの名前を指定します。
      2
      スケーリングするオブジェクトの namespace を指定します。
      3
      ロールにバインドするサービスアカウントの名前を指定します。
      4
      スケーリングするオブジェクトの namespace を指定します。
    2. CR オブジェクトを作成します。

      $ oc create -f <file-name>.yaml

「カスタムメトリクスオートスケーラーの追加方法について」で説明されているとおり、スケーリングされたオブジェクトまたはスケーリングされたジョブをデプロイして、アプリケーションの自動スケーリングを有効化できます。OpenShift Container Platform モニタリングをソースとして使用するには、トリガーまたはスケーラーに以下のパラメーターを含める必要があります。

  • triggers.typeprometheus にしてください。
  • triggers.metadata.serverAddresshttps://thanos-querier.openshift-monitoring.svc.cluster.local:9092 にしてください。
  • triggers.metadata.authModesbearer にしてください。
  • 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 のみが考慮されます。引用符で囲まれた文字列値として指定する必要があります。デフォルトでは、すべてのパーティションが考慮されます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.