3.2. コアプラットフォーム監視のパフォーマンスおよびスケーラビリティーの設定


クラスターのパフォーマンスとスケールを最適化するために、モニタリングスタックを設定できます。以下のドキュメントでは、監視コンポーネントを配布し、CPU およびメモリーリソースに対するモニタリングスタックの影響を制御する方法について説明します。

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

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

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

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

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

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

モニタリングスタックコンポーネントが実行されるクラスター内のノードを指定するには、cluster-monitoring-config config map 内のコンポーネントの nodeSelector 制約を、ノードに割り当てられたラベルと一致するように設定します。

注記

ノードセレクター制約を既存のスケジュール済み Pod に直接追加することはできません。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc label nodes <node_name> <node_label> 1
    1
    & lt;node_name& gt; を、ラベルを追加するノードの名前に置き換えます。&lt ;node_label&gt; を必要なラベルの名前に置き換えます。
  2. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

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

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

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

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

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

toleration をモニタリングスタックのコンポーネントに割り当て、それらを taint されたノードに移動することができます。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

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

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. コンポーネントの tolerations を指定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        <component>:
          tolerations:
            <toleration_specification>

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

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

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

3.2.2. メトリクススクレイピング (収集) のボディーサイズ制限の設定

デフォルトでは、スクレイピングされたメトリクスターゲットから返されるデータの圧縮されていない本文のサイズに制限はありません。スクレイピングされたターゲットが大量のデータを含む応答を返したときに、Prometheus が大量のメモリーを消費する状況を回避するために、ボディサイズの制限を設定できます。さらに、本体のサイズ制限を設定することで、悪意のあるターゲットが Prometheus およびクラスター全体に与える影響を軽減できます。

enforcedBodySizeLimit の値を設定した後、少なくとも 1 つの Prometheus スクレイプターゲットが、設定された値より大きい応答本文で応答すると、アラート PrometheusScrapeBodySizeLimitHit が発生します。

注記

ターゲットからスクレイピングされたメトリクスデータの非圧縮ボディサイズが設定されたサイズ制限を超えていると、スクレイピングは失敗します。次に、Prometheus はこのターゲットがダウンしていると見なし、その up メトリクス値を 0 に設定します。これにより、TargetDown アラートをトリガーできます。

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. openshift-monitoring namespace で cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. enforcedBodySizeLimit の値を data/config.yaml/prometheusK8s に追加して、ターゲットスクレイプごとに受け入れられるボディサイズを制限します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |-
        prometheusK8s:
          enforcedBodySizeLimit: 40MB 1
    1
    スクレイピングされたメトリクスターゲットの最大ボディサイズを指定します。この enforcedBodySizeLimit の例では、ターゲットスクレイプごとの非圧縮サイズを 40 メガバイトに制限しています。有効な数値は、B (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)、TB (テラバイト)、PB (ペタバイト)、および EB (エクサバイト) の Prometheus データサイズ形式を使用します。デフォルト値は 0 で、制限は指定されません。値を automatic に設定して、クラスターの容量に基づいて制限を自動的に計算することもできます。
  3. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

関連情報

3.2.3. コンポーネントのモニタリングに使用する CPU およびメモリーリソースの管理

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

これらの制限および要求は、openshift-monitoring namespace 内のコアプラットフォームモニタリングコンポーネントで設定できます。

3.2.3.1. 制限およびリクエストの指定

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config という名前の ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

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

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

    重要

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

    リソース制限および要求を設定する例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        alertmanagerMain:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        prometheusK8s:
          resources:
            limits:
              cpu: 500m
              memory: 3Gi
            requests:
              cpu: 200m
              memory: 500Mi
        thanosQuerier:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        prometheusOperator:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        metricsServer:
          resources:
            requests:
              cpu: 10m
              memory: 50Mi
            limits:
              cpu: 50m
              memory: 500Mi
        kubeStateMetrics:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        telemeterClient:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        openshiftStateMetrics:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        nodeExporter:
          resources:
            limits:
              cpu: 50m
              memory: 150Mi
            requests:
              cpu: 20m
              memory: 50Mi
        monitoringPlugin:
          resources:
            limits:
              cpu: 500m
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 500Mi
        prometheusOperatorAdmissionWebhook:
          resources:
            limits:
              cpu: 50m
              memory: 100Mi
            requests:
              cpu: 20m
              memory: 50Mi

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

3.2.4. メトリクス収集プロファイルの選択

重要

メトリクスコレクションプロファイルは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

コア OpenShift Container Platform モニタリングコンポーネントのメトリクス収集プロファイルを選択するには、cluster-monitoring-config ConfigMap オブジェクトを編集します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • FeatureGate カスタムリソース (CR) を使用して、テクノロジープレビュー機能を有効にしました。
  • cluster-monitoring-config ConfigMap オブジェクトを作成している。
  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。

手順

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

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. data/config.yaml/prometheusK8s の下にメトリクス収集プロファイル設定を追加します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          collectionProfile: <metrics_collection_profile_name> 1
    1
    メトリクス収集プロファイルの名前。使用可能な値は full または minimal です。値を指定しない場合、または collectionProfile キー名が config map に存在しない場合は、デフォルト設定の full が使用されます。

    次の例では、Prometheus のコアプラットフォームインスタンスのメトリクスコレクションプロファイルを minimal に設定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          collectionProfile: minimal
  3. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

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

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

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

前提条件

  • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

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

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

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

    Prometheus の設定例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    data:
      config.yaml: |
        prometheusK8s:
          topologySpreadConstraints:
          - maxSkew: 1
            topologyKey: monitoring
            whenUnsatisfiable: DoNotSchedule
            labelSelector:
              matchLabels:
                app.kubernetes.io/name: prometheus

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.