3.2. コアプラットフォームモニタリングのパフォーマンスとスケーラビリティーの設定
モニタリングスタックを設定して、クラスターのパフォーマンスとスケールを最適化できます。次のドキュメントでは、モニタリングコンポーネントを分散する方法と、モニタリングスタックが CPU およびメモリーリソースに与える影響を制御する方法について説明します。
3.2.1. モニタリングコンポーネントの配置と分散の制御
次の方法で、モニタリングスタックコンポーネントを特定のノードに移動できます。
-
ラベル付きノードで
nodeSelector
制約を使用して、任意のモニタリングスタックコンポーネントを特定のノードに移動します。 - taint されたノードにコンポーネントを移動できるように toleration を割り当てます。
これにより、クラスター全体のモニタリングコンポーネントの配置と分散を制御できます。
モニタリングコンポーネントの配置と分散を制御して、システムリソースの使用を最適化し、パフォーマンスを高め、特定の要件やポリシーに基づいてワークロードを分離できます。
3.2.1.1. モニタリングコンポーネントの異なるノードへの移動
モニタリングスタックコンポーネントを実行するクラスター内のノードを指定するには、ノードに割り当てられたラベルと一致するように、cluster-monitoring-config
config map 内のコンポーネントの nodeSelector
制約を設定します。
ノードセレクター制約を既存のスケジュール済み Pod に直接追加することはできません。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
まだの場合は、モニタリングコンポーネントを実行するノードにラベルを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label nodes <node_name> <node_label>
$ oc label nodes <node_name> <node_label>
1 - 1
<node_name>
は、ラベルを追加するノードの名前に置き換えます。<node_label>
は、必要なラベルの名前に置き換えます。
openshift-monitoring
プロジェクトでcluster-monitoring-config
ConfigMap
オブジェクトを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
data/config.yaml
でコンポーネントのnodeSelector
制約のノードラベルを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | # ... <component>: nodeSelector: <node_label_1> <node_label_2> # ...
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 は再デプロイされます。
3.2.1.2. モニタリングコンポーネントへの toleration の割り当て
toleration をモニタリングスタックのコンポーネントに割り当て、それらを taint されたノードに移動することができます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
コンポーネントの
tolerations
を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | <component>: tolerations: <toleration_specification>
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
コンポーネントを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
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 は自動的に再デプロイされます。
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
オブジェクトを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
enforcedBodySizeLimit
の値をdata/config.yaml/prometheusK8s
に追加して、ターゲットスクレイプごとに受け入れ可能なボディーサイズを制限します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |- prometheusK8s: enforcedBodySizeLimit: 40MB
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.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 を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
値を追加して、設定する各コンポーネントのリソース制限および要求を定義します。
重要制限に設定した値が常に要求に設定された値よりも大きくなることを確認してください。そうでない場合、エラーが発生し、コンテナーは実行されません。
リソース制限とリクエストの設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 は自動的に再デプロイされます。
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
オブジェクトを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
data/config.yaml/prometheusK8s
の下にメトリクス収集プロファイル設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: collectionProfile: <metrics_collection_profile_name>
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
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: collectionProfile: 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
config map を使用して、Pod を監視するための Pod トポロジーの分散制約を設定できます。
前提条件
-
cluster-admin
クラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-config
ConfigMap
オブジェクトを作成している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
openshift-monitoring
プロジェクトでcluster-monitoring-config
config map を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-monitoring edit configmap cluster-monitoring-config
$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
Pod トポロジーの分散制約を設定するには、
data/config.yaml
フィールドの下に次の設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | <component>: topologySpreadConstraints: - maxSkew: <n> topologyKey: <key> whenUnsatisfiable: <value> labelSelector: <match_option>
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 の設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 は自動的に再デプロイされます。