3.2. ユーザーワークロードモニタリングのパフォーマンスとスケーラビリティーの設定


モニタリングスタックを設定して、クラスターのパフォーマンスとスケールを最適化できます。次のドキュメントでは、モニタリングコンポーネントを分散する方法と、モニタリングスタックが CPU およびメモリーリソースに与える影響を制御する方法を説明します。

3.2.1. モニタリングコンポーネントの配置と分散の制御

次の方法で、モニタリングスタックコンポーネントを特定のノードに移動できます。

  • ラベル付きノードで nodeSelector 制約を使用して、任意のモニタリングスタックコンポーネントを特定のノードに移動します。
  • taint されたノードにコンポーネントを移動できるように toleration を割り当てます。

これにより、クラスター全体のモニタリングコンポーネントの配置と分散を制御できます。

モニタリングコンポーネントの配置と分散を制御して、システムリソースの使用を最適化し、パフォーマンスを高め、特定の要件やポリシーに基づいてワークロードを分離できます。

3.2.1.1. モニタリングコンポーネントの異なるノードへの移動

ユーザー定義プロジェクトのワークロードをモニターする任意のコンポーネントを特定のワーカーノードに移動できます。

警告

コンポーネントをコントロールプレーンまたはインフラストラクチャーノードに移動することは許可されていません。

前提条件

  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • user-workload-monitoring-config ConfigMap オブジェクトが存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. まだの場合は、モニタリングコンポーネントを実行するノードにラベルを追加します。

    $ oc label nodes <node_name> <node_label> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> は、ラベルを追加するノードの名前に置き換えます。<node_label> は、必要なラベルの名前に置き換えます。
  2. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    Copy to Clipboard Toggle word wrap
  3. data/config.yaml でコンポーネントの nodeSelector 制約のノードラベルを指定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        # ...
        <component>: 
    1
    
          nodeSelector:
            <node_label_1> 
    2
    
            <node_label_2> 
    3
    
        # ...
    Copy to Clipboard Toggle word wrap
    1
    <component> を適切なモニタリングスタックコンポーネント名に置き換えます。
    2
    <node_label_1> は、ノードに追加したラベルに置き換えます。
    3
    オプション: 追加のラベルを指定します。追加のラベルを指定すると、コンポーネントの Pod は、指定されたすべてのラベルを含むノード上でのみスケジュールされます。
    注記

    nodeSelector の制約を設定した後もモニタリングコンポーネントが Pending 状態のままになっている場合は、Pod イベントで taint および toleration に関連するエラーの有無を確認します。

  4. 変更を適用するためにファイルを保存します。新しい設定で指定されたコンポーネントは自動的に新しいノードに移動され、新しい設定の影響を受ける Pod は再デプロイされます。

3.2.1.2. モニタリングコンポーネントへの toleration の割り当て

ユーザー定義プロジェクトをモニターするコンポーネントに許容値を割り当てて、テイントされたワーカーノードにプロジェクトを移動できるようにすることができます。コントロールプレーンまたはインフラストラクチャーノードでのスケジューリングは許可されていません。

前提条件

  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • user-workload-monitoring-config ConfigMap オブジェクトは、openshift-user-workload-monitoring namespace に存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config config map を編集します。

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    Copy to Clipboard Toggle word wrap
  2. コンポーネントの tolerations を指定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        <component>:
          tolerations:
            <toleration_specification>
    Copy to Clipboard Toggle word wrap

    <component> および <toleration_specification> を随時置き換えます。

    たとえば、oc adm taint nodes node1 key1=value1:NoSchedule は、キーが key1 で、値が value1node1 に taint を追加します。これにより、モニタリングコンポーネントが node1 に Pod をデプロイするのを防ぎます。ただし、その taint に対して toleration が設定されている場合を除きます。以下の例では、サンプルの taint を容認するように thanosRuler コンポーネントを設定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          tolerations:
          - key: "key1"
            operator: "Equal"
            value: "value1"
            effect: "NoSchedule"
    Copy to Clipboard Toggle word wrap
  3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。

3.2.2. モニタリングコンポーネントの CPU およびメモリーリソースの管理

モニタリングコンポーネントを実行するコンテナーに十分な CPU リソースとメモリーリソースを確保するには、これらのコンポーネントのリソース制限および要求の値を指定します。

openshift-user-workload-monitoring namespace で、ユーザー定義プロジェクトを監視するモニタリングコンポーネントのリソース制限および要求を設定できます。

3.2.2.1. 制限および要求の指定

CPU およびメモリーリソースを設定するには、openshift-user-workload-monitoring namespace の user-workload-monitoring-config ConfigMap オブジェクトでリソース制限と要求の値を指定します。

前提条件

  • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config config map を編集します。

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    Copy to Clipboard Toggle word wrap
  2. 値を追加して、設定する各コンポーネントのリソース制限および要求を定義します。

    重要

    制限に設定した値が常に要求に設定された値よりも大きくなることを確認してください。そうでない場合、エラーが発生し、コンテナーは実行されません。

    リソース制限とリクエストの設定例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        alertmanager:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        prometheus:
          resources:
            limits:
              cpu: 500m
              memory: 3Gi
            requests:
              cpu: 200m
              memory: 500Mi
        thanosRuler:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
    Copy to Clipboard Toggle word wrap

  3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。

3.2.3. ユーザー定義プロジェクトでバインドされていないメトリクス属性の影響の制御

dedicated-admin は、以下の手段を使用して、ユーザー定義プロジェクトでのバインドされていないメトリクス属性の影響を制御できます。

  • ユーザー定義プロジェクトでターゲットスクレイピングごとの許容可能なサンプル数を制限する
  • スクレイピングするラベルの数、ラベル名の長さ、ラベル値の長さを制限する
  • 連続するスクレイピング間および Prometheus ルール評価間の間隔を設定する
注記

スクレイピングサンプル数を制限すると、ラベルにバインドされない属性を多数追加することによって発生する問題を防ぐことができます。さらに開発者は、メトリクスに定義するバインドされていない属性の数を制限することにより、根本的な原因を防ぐことができます。使用可能な値の制限されたセットにバインドされる属性を使用すると、可能なキーと値のペアの組み合わせの数が減ります。

3.2.3.1. ユーザー定義プロジェクトのスクレイピング間隔、評価間隔、および制限適用の設定

ユーザー定義プロジェクトに対して、次のスクレイピングおよびラベルの制限を設定できます。

  • ターゲットスクレイピングごとの許容可能なサンプル数を制限する
  • スクレイピングするラベルの数を制限する
  • ラベル名とラベル値の長さを制限する

連続するスクレイピング間および Prometheus ルール評価間の間隔を設定することもできます。

警告

サンプルまたはラベルの制限を設定している場合、制限に達した後にそのターゲット収集に関する追加のサンプルデータは取得されません。

前提条件

  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • user-workload-monitoring-config ConfigMap オブジェクトが存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    Copy to Clipboard Toggle word wrap
  2. 適用する制限と時間間隔の設定を data/config.yaml に追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        prometheus:
          enforcedSampleLimit: 50000 
    1
    
          enforcedLabelLimit: 500 
    2
    
          enforcedLabelNameLengthLimit: 50 
    3
    
          enforcedLabelValueLengthLimit: 600 
    4
    
          scrapeInterval: 1m30s 
    5
    
          evaluationInterval: 1m15s 
    6
    Copy to Clipboard Toggle word wrap
    1
    このパラメーターが指定されている場合は、値が必要です。この enforcedSampleLimit の例では、ユーザー定義プロジェクトのターゲット収集ごとに受け入れ可能なサンプル数を 50,000 に制限します。
    2
    収集ごとのラベルの最大数を指定します。デフォルト値は 0 で、制限は指定されません。
    3
    ラベル名の最大文字長を指定します。デフォルト値は 0 で、制限は指定されません。
    4
    ラベル値の最大文字長を指定します。デフォルト値は 0 で、制限は指定されません。
    5
    連続するスクレイピング間の間隔を指定します。間隔は 5 秒から 5 分の間で設定する必要があります。デフォルト値は 30s です。
    6
    Prometheus ルールの評価間隔を指定します。間隔は 5 秒から 5 分の間で設定する必要があります。Prometheus のデフォルト値は 30s です。
    注記

    data/config.yaml/thanosRuler フィールドを通じて Thanos Ruler の evaluationInterval プロパティーを設定することもできます。Thanos Ruler のデフォルト値は 15s です。

  3. 変更を適用するためにファイルを保存します。制限は自動的に適用されます。

3.2.4. Pod トポロジー分散制約の設定

ユーザー定義のモニタリング用にすべての Pod に対して Pod トポロジーの拡散制約を設定し、ゾーン全体のノードに Pod レプリカをスケジュールする方法を制御できます。これにより、ワークロードが異なるデータセンターまたは階層型インフラストラクチャーゾーンのノードに分散されるため、Pod の可用性が高まり、より効率的に実行されるようになります。

user-workload-monitoring-config config map を使用して、Pod を監視するための Pod トポロジーの分散制約を設定できます。

前提条件

  • dedicated-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • user-workload-monitoring-config ConfigMap オブジェクトが存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config config map を編集します。

    $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
    Copy to Clipboard Toggle word wrap
  2. Pod トポロジーの分散制約を設定するには、data/config.yaml フィールドの下に次の設定を追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        <component>: 
    1
    
          topologySpreadConstraints:
          - maxSkew: <n> 
    2
    
            topologyKey: <key> 
    3
    
            whenUnsatisfiable: <value> 
    4
    
            labelSelector: 
    5
    
              <match_option>
    Copy to Clipboard Toggle word wrap
    1
    Pod トポロジーの分散制約を設定するコンポーネントの名前を指定します。
    2
    maxSkew の数値を指定します。これは、どの程度まで Pod が不均等に分散されることを許可するか定義します。
    3
    topologyKey にノードラベルのキーを指定します。このキーと同じ値のラベルを持つノードは、同じトポロジーにあると見なされます。スケジューラーは、各ドメインにバランスの取れた数の Pod を配置しようとします。
    4
    whenUnsatisfiable の値を指定します。利用可能なオプションは DoNotScheduleScheduleAnyway です。maxSkew 値で、ターゲットトポロジー内の一致する Pod の数とグローバル最小値との間で許容される最大差を定義する場合は、DoNotSchedule を指定します。スケジューラーが引き続き Pod をスケジュールするが、スキューを減らす可能性のあるノードにより高い優先度を与える場合は、ScheduleAnyway を指定します。
    5
    一致する Pod を見つけるには、labelSelector を指定します。このラベルセレクターに一致する Pod は、対応するトポロジードメイン内の Pod の数を決定するためにカウントされます。

    Thanos Ruler の設定例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        thanosRuler:
          topologySpreadConstraints:
          - maxSkew: 1
            topologyKey: monitoring
            whenUnsatisfiable: ScheduleAnyway
            labelSelector:
              matchLabels:
                app.kubernetes.io/name: thanos-ruler
    Copy to Clipboard Toggle word wrap

  3. 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat