3.2. コアプラットフォームモニタリングのパフォーマンスとスケーラビリティーの設定
モニタリングスタックを設定して、クラスターのパフォーマンスとスケールを最適化できます。次のドキュメントでは、モニタリングコンポーネントを分散する方法と、モニタリングスタックが CPU およびメモリーリソースに与える影響を制御する方法を説明します。
3.2.1. モニタリングコンポーネントの配置と分散の制御 リンクのコピーリンクがクリップボードにコピーされました!
次の方法で、モニタリングスタックコンポーネントを特定のノードに移動できます。
-
ラベル付きノードで
nodeSelector制約を使用して、任意のモニタリングスタックコンポーネントを特定のノードに移動します。 - taint されたノードにコンポーネントを移動できるように toleration を割り当てます。
これにより、クラスター全体のモニタリングコンポーネントの配置と分散を制御できます。
モニタリングコンポーネントの配置と分散を制御して、システムリソースの使用を最適化し、パフォーマンスを高め、特定の要件やポリシーに基づいてワークロードを分離できます。
3.2.1.1. モニタリングコンポーネントの異なるノードへの移動 リンクのコピーリンクがクリップボードにコピーされました!
モニタリングスタックコンポーネントを実行するクラスター内のノードを指定するには、ノードに割り当てられたラベルと一致するように、cluster-monitoring-config config map 内のコンポーネントの nodeSelector 制約を設定します。
ノードセレクター制約を既存のスケジュール済み Pod に直接追加することはできません。
前提条件
-
cluster-adminクラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-configConfigMapオブジェクトを作成している。 -
OpenShift CLI (
oc) がインストールされている。
手順
まだの場合は、モニタリングコンポーネントを実行するノードにラベルを追加します。
$ oc label nodes <node_name> <node_label>1 - 1
<node_name>は、ラベルを追加するノードの名前に置き換えます。<node_label>は、必要なラベルの名前に置き換えます。
openshift-monitoringプロジェクトでcluster-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-configdata/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 は再デプロイされます。
3.2.1.2. モニタリングコンポーネントへの toleration の割り当て リンクのコピーリンクがクリップボードにコピーされました!
toleration をモニタリングスタックのコンポーネントに割り当て、それらを taint されたノードに移動することができます。
前提条件
-
cluster-adminクラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-configConfigMapオブジェクトを作成している。 -
OpenShift CLI (
oc) がインストールされている。
手順
openshift-monitoringプロジェクトでcluster-monitoring-configconfig 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 は自動的に再デプロイされます。
3.2.2. メトリクススクレイピング (収集) のボディーサイズ制限の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、スクレイピングされたメトリクスターゲットから返されるデータの非圧縮のボディーサイズに制限はありません。スクレイピングされたターゲットが大量のデータを含む応答を返すときに Prometheus が過剰にメモリーを消費する状況を回避するために、ボディーサイズの制限を設定できます。さらに、ボディーサイズ制限を設定することで、悪意のあるターゲットが Prometheus およびクラスター全体に与える影響を軽減できます。
enforcedBodySizeLimit の値を設定した後、少なくとも 1 つの Prometheus スクレイプターゲットが、設定された値より大きいレスポンスボディーで応答すると、アラート PrometheusScrapeBodySizeLimitHit が発生します。
ターゲットからスクレイピングされたメトリクスデータの非圧縮ボディーサイズが、設定されたサイズ制限を超えていると、スクレイピングは失敗します。次に、Prometheus はこのターゲットがダウンしていると見なし、その up メトリクス値を 0 に設定します。これにより、TargetDown アラートをトリガーできます。
前提条件
-
cluster-adminクラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
openshift-monitoringnamespace でcluster-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-configenforcedBodySizeLimitの値をdata/config.yaml/prometheusK8sに追加して、ターゲットスクレイプごとに受け入れ可能なボディーサイズを制限します。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |- prometheusK8s: enforcedBodySizeLimit: 40MB1 - 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-configconfig 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 k8sPrometheusAdapter: resources: limits: cpu: 500m memory: 1Gi requests: cpu: 200m 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-configConfigMapオブジェクトを作成している。 -
cluster-adminクラスターロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-monitoringプロジェクトでcluster-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-configdata/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 config map を使用して、Pod を監視するための Pod トポロジーの分散制約を設定できます。
前提条件
-
cluster-adminクラスターロールを持つユーザーとしてクラスターにアクセスできる。 -
cluster-monitoring-configConfigMapオブジェクトを作成している。 -
OpenShift CLI (
oc) がインストールされている。
手順
openshift-monitoringプロジェクトでcluster-monitoring-configconfig map を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-configPod トポロジーの分散制約を設定するには、
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 は自動的に再デプロイされます。