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
) がインストールされている。
手順
まだの場合は、モニタリングコンポーネントを実行するノードにラベルを追加します。
$ oc label nodes <node_name> <node_label> 1
- 1
- &
lt;node_name&
gt; を、ラベルを追加するノードの名前に置き換えます。<node_label>
; を必要なラベルの名前に置き換えます。
openshift-monitoring
プロジェクトでcluster-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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 # ...
注記nodeSelector
の制約を設定した後もモニタリングコンポーネントがPending
状態のままになっている場合は、Pod イベントで taint および toleration に関連するエラーの有無を確認します。- 変更を適用するためにファイルを保存します。新しい設定で指定されたコンポーネントは自動的に新しいノードに移動され、新しい設定の影響を受ける Pod は再デプロイされます。
関連情報
- コアプラットフォームモニタリングスタックの設定の準備
- ノードでラベルを更新する方法について
- ノードセレクターの使用による特定ノードへの Pod の配置
- nodeSelector (Kubernetes ドキュメント)
3.2.1.2. モニタリングコンポーネントへの toleration の割り当て
toleration をモニタリングスタックのコンポーネントに割り当て、それらを taint されたノードに移動することができます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
コンポーネントの
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
で、値がvalue1
のnode1
に 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"
- 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。
関連情報
- コアプラットフォームモニタリングスタックの設定の準備
- ノード taint を使用した Pod 配置の制御
- テイントおよび容認 (Kubernetes ドキュメント)
3.2.2. メトリクススクレイピング (収集) のボディーサイズ制限の設定
デフォルトでは、スクレイピングされたメトリクスターゲットから返されるデータの圧縮されていない本文のサイズに制限はありません。スクレイピングされたターゲットが大量のデータを含む応答を返したときに、Prometheus が大量のメモリーを消費する状況を回避するために、ボディサイズの制限を設定できます。さらに、本体のサイズ制限を設定することで、悪意のあるターゲットが Prometheus およびクラスター全体に与える影響を軽減できます。
enforcedBodySizeLimit
の値を設定した後、少なくとも 1 つの Prometheus スクレイプターゲットが、設定された値より大きい応答本文で応答すると、アラート PrometheusScrapeBodySizeLimitHit
が発生します。
ターゲットからスクレイピングされたメトリクスデータの非圧縮ボディサイズが設定されたサイズ制限を超えていると、スクレイピングは失敗します。次に、Prometheus はこのターゲットがダウンしていると見なし、その up
メトリクス値を 0
に設定します。これにより、TargetDown
アラートをトリガーできます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
openshift-monitoring
namespace でcluster-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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
に設定して、クラスターの容量に基づいて制限を自動的に計算することもできます。
- 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。
関連情報
- scrape_config 設定 (Prometheus ドキュメント)
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
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
値を追加して、設定する各コンポーネントのリソース制限および要求を定義します。
重要制限に設定した値が常に要求に設定された値よりも大きくなることを確認してください。そうでない場合、エラーが発生し、コンテナーは実行されません。
リソース制限および要求を設定する例
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
- 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。
関連情報
- 制限およびリクエストの指定
- Kubernetes requests and limits documentation (Kubernetes ドキュメント)
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
クラスターロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
ConfigMap
オブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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.2.5. Pod トポロジー分散制約の設定
Cluster Monitoring Operator によってデプロイされたすべての Pod に対して Pod トポロジーの分散制約を設定し、ゾーン全体のノードに Pod レプリカをスケジュールする方法を制御できます。これにより、ワークロードが異なるデータセンターまたは階層型インフラストラクチャーゾーンのノードに分散されるため、Pod の可用性が高まり、より効率的に実行されるようになります。
cluster-monitoring-config
設定マップを使用して、Pod を監視するための Pod トポロジー分散制約を設定できます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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
の値を指定します。利用可能なオプションはDoNotSchedule
とScheduleAnyway
です。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
- 変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされます。
関連情報
- モニタリングのための Pod トポロジー分散制約について
- Pod トポロジー分散制約を使用した Pod 配置の制御
- Pod Topology Spread Constraints (Kubernetes ドキュメント)