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

手順

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

    $ oc project my-project
  2. クラスターにサービスアカウントおよびトークンがない場合は、これを作成します。

    1. 次のコマンドを使用して、service account オブジェクトを作成します。

      $ oc create serviceaccount thanos 1
      1
      サービスアカウントの名前を指定します。
    2. secret YAML を作成し、サービスアカウントトークンを生成します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: thanos-token
        annotations:
          kubernetes.io/service-account.name: thanos 1
      type: kubernetes.io/service-account-token
      1
      サービスアカウントの名前を指定します。
    3. 次のコマンドを使用してシークレットオブジェクトを作成します。

      $ oc create -f <file_name>.yaml
    4. 次のコマンドを使用して、サービスアカウントに割り当てられたトークンを見つけます。

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

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

      $ oc create -f <file-name>.yaml
  4. 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
  5. 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 ターゲットを使用した 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 と同じである必要があります。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.