Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

3.4. カスタムメトリクスオートスケーラートリガーについて

スケーラーとも呼ばれるトリガーは、Custom Metrics Autoscaler Operator が Pod をスケーリングするために使用するメトリクスを提供します。

カスタムメトリクスオートスケーラーは現在、Prometheus、CPU、メモリー、Apache Kafka、cron トリガーをサポートしています。

以下のセクションで説明するように、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 

      timeout: 1000
11

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 の場合、証明書のチェックは実行されません。

    重要

    チェックのスキップは推奨されません。

11
オプション: この Prometheus トリガーで使用される HTTP クライアントの HTTP 要求タイムアウトをミリ秒単位で指定します。この値は、グローバルタイムアウト設定をオーバーライドします。

3.4.1.1. Prometheus と DCGM メトリクスを使用した GPU ベースの自動スケーリングの設定
リンクのコピー

カスタムメトリクスオートスケーラーを NVIDIA データセンター GPU マネージャー (DCGM) メトリクスとともに使用すると、GPU 使用率に基づいてワークロードをスケーリングできます。これは、GPU リソースを必要とする AI および機械学習のワークロードに特に役立ちます。

GPU ベースの自動スケーリングのために Prometheus ターゲットを使用する scaled object の例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: gpu-scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    kind: Deployment
    name: gpu-deployment
  minReplicaCount: 1
1 

  maxReplicaCount: 5
2 

  triggers:
  - type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: my-namespace
      metricName: gpu_utilization
      threshold: '90'
3 

      query: SUM(DCGM_FI_DEV_GPU_UTIL{instance=~".+", gpu=~".+"})
4 

      authModes: bearer
    authenticationRef:
      name: keda-trigger-auth-prometheus

1
維持するレプリカの最小数を指定します。GPU ワークロードの場合は、メトリクスが継続的に収集されるように、これを 0 に設定しないください。
2
スケールアップ操作中に許可するレプリカの最大数を指定します。
3
スケーリングをトリガーする GPU 使用率のしきい値をパーセンテージで指定します。GPU の平均使用率が 90% を超えると、オートスケーラーがデプロイメントをスケールアップします。
4
すべての GPU デバイスの GPU 使用率を監視するために、NVIDIA DCGM メトリクスを使用して Prometheus クエリーを指定します。DCGM_FI_DEV_GPU_UTIL メトリクスは、GPU 使用率を提供します。

カスタムメトリクスオートスケーラーが使用するメトリクスのソースとして、インストール済みの OpenShift Container Platform Prometheus モニタリングを使用できます。ただし、実行する必要がある追加の設定がいくつかあります。

scaled object が OpenShift Container Platform Prometheus メトリクスを読み取れるように、トリガー認証またはクラスタートリガー認証を使用して、必要な認証情報を提供する必要があります。以下の手順は、使用するトリガー認証方式によって異なります。トリガー認証の詳細は、「カスタムメトリクスオートスケーラーのトリガー認証について」を参照してください。

注記

これらの手順は、外部 Prometheus ソースには必要ありません。

このセクションで説明するように、次のタスクを実行する必要があります。

  • サービスアカウントを作成します。
  • トリガー認証を作成します。
  • ロールを作成します。
  • そのロールをサービスアカウントに追加します。
  • Prometheus が使用するトリガー認証オブジェクトでトークンを参照します。

前提条件

  • OpenShift Container Platform モニタリングをインストールしている必要がある。
  • ユーザー定義のワークロードのモニタリングを、OpenShift Container Platform モニタリングで有効にする必要がある (ユーザー定義のワークロードモニタリング設定マップの作成 セクションで説明)。
  • Custom Metrics Autoscaler Operator をインストールしている。

手順

  1. 適切なプロジェクトに切り替えます。 

    $ oc project <project_name>
    1
    1
    次のプロジェクトのいずれかを指定します。
    • トリガー認証を使用している場合は、スケーリングするオブジェクトを含むプロジェクトを指定します。
    • クラスタートリガー認証を使用している場合は、openshift-keda プロジェクトを指定します。

  2. クラスターにサービスアカウントがない場合は作成します。

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

      $ oc create serviceaccount thanos
      1
      1
      サービスアカウントの名前を指定します。

  3. サービスアカウントトークンを使用してトリガー認証を作成します。

    1. 以下のような YAML ファイルを作成します。 

      apiVersion: keda.sh/v1alpha1
kind: <authentication_method>
      1 
      
metadata:
  name: keda-trigger-auth-prometheus
spec:
  boundServiceAccountToken:
      2 
      
    - parameter: bearerToken
      3 
      
      serviceAccountName: thanos
      4
      1
      次のいずれかのトリガー認証方法を指定します。
      • トリガー認証を使用している場合は、TriggerAuthentication を指定します。この例では、トリガー認証を設定します。
      • クラスタートリガー認証を使用している場合は、ClusterTriggerAuthentication を指定します。
      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: <binding_type>
      1 
      
metadata:
  name: thanos-metrics-reader
      2 
      
  namespace: my-project
      3 
      
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: thanos-metrics-reader
subjects:
- kind: ServiceAccount
  name: thanos
      4 
      
  namespace: <namespace_name>
      5
      1
      次のオブジェクト型のいずれかを指定します。
      • トリガー認証を使用している場合は、RoleBinding を指定します。
      • クラスタートリガー認証を使用している場合は、ClusterRoleBinding を指定します。
      2
      作成したロールの名前を指定します。
      3
      次のプロジェクトのいずれかを指定します。
      • トリガー認証を使用している場合は、スケーリングするオブジェクトを含むプロジェクトを指定します。
      • クラスタートリガー認証を使用している場合は、openshift-keda プロジェクトを指定します。
      4
      ロールにバインドするサービスアカウントの名前を指定します。
      5
      サービスアカウントを先に作成したプロジェクトを指定します。

    2. 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 は、直前の手順で指定されたトリガー認証リソースを指す必要があります。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る