Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

1.6. 可観測性の高度な設定

可観測性を有効にしたら、環境の特定のニーズに合わせて可観測性設定をさらにカスタマイズできます。可観測性サービスが収集するクラスターフリートデータを管理および表示します。

必要なアクセス権: クラスター管理者

以下のアプリケーション詳細設定のトピックを確認してください。

1.6.1. カスタムメトリクスの追加
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes を使用してリモートクラスターからのメトリクスを監視するには、そのメトリクスがプラットフォームまたはユーザーワークロードメトリクスとしてエクスポートされているかどうかを確認します。メトリクスタイプを確認するには、次の 3 つの方法のいずれかを使用します。

  • 監視対象とするソリューションのドキュメントでメトリクスタイプを確認します。
  • 製品のサポートに問い合わせてメトリクスタイプを確認します。

  • 監視対象リソースの ServiceMonitor が使用するアノテーションを確認して、メトリクスタイプを確認します。

    • プラットフォームメトリクスは、operator.prometheus.io/controller-id: openshift-platform-monitoring/prometheus-operator を使用します。
    • ユーザーワークロードメトリクスは、operator.prometheus.io/controller-id: openshift-user-workload-monitoring/prometheus-operator を使用します。

また、コンソールで Observe > Targets に移動し、右上の Source フィルターから Platform または User を選択することで、ServiceMonitor を見つけることもできます。

注記: Source フィルターは、メトリクスのリストではなく、サービスモニターまたはターゲットの情報を提供します。

メトリクスがプラットフォームの場合は、プラットフォームメトリクスの追加 に進んでください。メトリクスがユーザーワークロードの場合は、ユーザーワークロードメトリクスの追加 に進んでください。

必要なアクセス権: クラスター管理者

1.6.1.1. プラットフォームメトリクスの追加
リンクのコピー

ハブクラスターの open-cluster-management-observability namespace 内に ConfigMap を作成することで、プラットフォームメトリクスを監視できます。名前として observability-metrics-custom-allowlist を使用します。プラットフォームメトリクスを監視するために使用できる次の ConfigMap の例を参照してください。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: observability-metrics-custom-allowlist
  namespace: open-cluster-management-observability
  data:
  metrics_list.yaml: |
    names:
1 

      - node_memory_MemTotal_bytes
        recording_rules:
2 

      - record: apiserver_request_duration_seconds:histogram_quantile_90
        expr: histogram_quantile(0.90,sum(rate(apiserver_request_duration_seconds_bucket {job=\"apiserver\", verb!=\"WATCH\"}[5m])) by (verb,le))
Copy to Clipboard Toggle word wrap
1
オプション: マネージドクラスターから収集するカスタムメトリクスの名前を追加します。
2
オプション: expr と record パラメーターのペアに値を 1 つ追加して、クエリー式を定義します。

収集するメトリクスの名前は、マネージドクラスターの record パラメーターで定義した名前と同じです。クエリー式を実行すると、メトリクス値の結果が得られます。1 つのセクションまたは両方のセクションを使用できます。これは、モニタリングが有効なすべてのクラスターに当てはまります。

1 つのマネージドクラスターからのみカスタムメトリクスを収集する場合は、次の例を使用して、マネージドクラスターの open-cluster-management-addon-observability namespace 内で config map を適用します。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: observability-metrics-custom-allowlist
  namespace: open-cluster-management-addon-observability
  data:
  metrics_list.yaml: |
    names:
1 

      - node_memory_MemTotal_bytes
        recording_rules:
2 

      - record: apiserver_request_duration_seconds:histogram_quantile_90
        expr: histogram_quantile(0.90,sum(rate(apiserver_request_duration_seconds_bucket{job="apiserver", verb!="WATCH"}[5m])) by (verb,le))
Copy to Clipboard Toggle word wrap
1
オプション: マネージドクラスターから収集するカスタムメトリクスの名前を追加します。
2
オプション: expr と record パラメーターのペアに値を 1 つだけ入力して、クエリー式を定義します。

収集するメトリクスの名前は、マネージドクラスターの record パラメーターで定義した名前と同じです。クエリー式を実行すると、メトリクス値の結果が得られます。1 つのセクションまたは両方のセクションを使用できます。

1.6.1.2. ユーザーワークロードメトリクスの追加
リンクのコピー

メトリクスの取得対象とする namespace 内のマネージドクラスターで設定を指定することで、ユーザーワークロードメトリクスを監視できます。名前は observability-metrics-custom-allowlist である必要があります。形式は次の例と同じである必要があります。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: observability-metrics-custom-allowlist
  namespace: <monitored_namespace>
1 

data:
  uwl_metrics_list.yaml:
    names:
      - <sample_metrics>
2
Copy to Clipboard Toggle word wrap
1
メトリクスの取得対象とする namespace を追加します。
2
config map データの値を YAML 形式で追加します。test namespace から収集するメトリクス名のリストを names セクションに追加します。config map を作成すると、可観測性コレクターはメトリクスを収集し、ターゲット namespace からハブクラスターにプッシュします。

前の例では、namespace monitored_namespace からのユーザーワークロードメトリクス sample_metrics を監視します。代わりに、open-cluster-management-addon-observability namespace で設定を作成すると、マネージドクラスターのすべての namespace からメトリクスが収集されます。

1.6.1.3. デフォルトメトリクスの削除
リンクのコピー

マネージドクラスターから特定のメトリクスのデータを収集したくない場合は、observability-metrics-custom-allowlist.yaml ファイルからメトリクスを削除します。メトリクスを削除すると、マネージドクラスターからメトリクスデータが収集されなくなります。デフォルトのメトリクスを削除するには、次の手順を実行します。

  1. 以下のコマンドを使用して、mco observability が有効になっていることを確認します。 

    oc get mco observability -o yaml
    Copy to Clipboard Toggle word wrap

  2. metrics_list.yaml パラメーターにデフォルトのメトリクスの名前を追加します。メトリクス名の先頭にハイフン - を付けます。次のメトリクスの例を参照してください。 

    -cluster_infrastructure_provider
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドで、open-cluster-management-observability namespace に observability-metrics-custom-allowlist config map を作成します。 

    oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
    Copy to Clipboard Toggle word wrap
  4. 可観測性サービスがマネージドクラスターから特定のメトリクスを収集していないことを確認します。Grafana ダッシュボードからメトリクスをクエリーしても、メトリクスは表示されません。

1.6.1.4. シングルノード OpenShift クラスターの動的メトリクス
リンクのコピー

動的メトリクス収集では、特定の条件に基づいて自動的にメトリクスを収集できます。デフォルトでは、シングルノードの OpenShift クラスターは Pod およびコンテナーのリソースメトリクスを収集しません。シングルノードの OpenShift クラスターが特定のレベルのリソース消費に達すると、定義された詳細なメトリクスが動的に収集されます。一定期間にわたってクラスターリソースの消費量が常にしきい値を下回ると、詳細なメトリクスの収集が停止します。

メトリクスは、収集ルールによって指定されたマネージドクラスターの条件に基づいて動的に収集されます。これらのメトリクスは動的に収集されるため、次の Red Hat Advanced Cluster Management Grafana ダッシュボードにはデータが表示されません。収集ルールがアクティブ化され、対応するメトリクスが収集されると、収集ルールが起動している期間のデータが次のパネルに表示されます。

  • Kubernetes/コンピューティングリソース/namespace (Pod)
  • Kubernetes/コンピューティングリソース/namespace (ワークロード)
  • Kubernetes/コンピューティングリソース/ノード (Pod)
  • Kubernetes/コンピューティングリソース/Pod
  • Kubernetes/コンピューティングリソース/ワークロード

コレクションルールには、以下の条件が含まれます。

  • 動的に収集するメトリックのセット。
  • PromQL 式として記述された条件。
  • コレクションの間隔。true に設定する必要があります。
  • 収集ルールを評価する必要のあるクラスターを選択するための一致式。

デフォルトでは、コレクションルールは、30 秒ごとにマネージドクラスターで継続的に評価されるか、特定の間隔で評価されます。コレクションの間隔と時間間隔の最小値が優先されます。

収集ルールの条件が for 属性で指定された期間持続すると、収集ルールが開始され、ルールで指定されたメトリクスがマネージドクラスターに自動的に収集されます。メトリクスの収集は、収集ルールの条件がマネージドクラスターに存在しなくなった後、開始してから少なくとも 15 分後に自動的に停止します。

収集ルールは、collect_rules という名前のパラメーターセクションとしてグループ化され、グループとして有効または無効にできます。Red Hat Advanced Cluster Management インストールには、コレクションルールグループ (HighCPUUsage および HighMemoryUsage) のデフォルトコレクションルール SNOResourceUsage が含まれます。HighCPUUsage コレクションルールは、ノードの CPU 使用率が 70% を超えると開始されます。

HighMemoryUsage 収集ルールは、シングルノード OpenShift クラスターの全体的なメモリー使用率が使用可能なノードメモリーの 70% を超えると開始されます。現在、上記のしきい値は固定されており、変更できません。収集ルールが for 属性で指定された間隔を超えて開始すると、システムが dynamic_metrics セクションで指定されたメトリクスの収集を自動的に開始します。

次の YAML ファイルに含まれる collect_rules セクションの動的メトリクスのリストを参照してください。 

collect_rules:
  - group: SNOResourceUsage
    annotations:
      description: >
        By default, a {sno} cluster does not collect pod and container resource metrics. Once a {sno} cluster
        reaches a level of resource consumption, these granular metrics are collected dynamically.
        When the cluster resource consumption is consistently less than the threshold for a period of time,
        collection of the granular metrics stops.
    selector:
      matchExpressions:
        - key: clusterType
          operator: In
          values: ["{sno}"]
    rules:
    - collect: SNOHighCPUUsage
      annotations:
        description: >
          Collects the dynamic metrics specified if the cluster cpu usage is constantly more than 70% for 2 minutes
      expr: (1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))) * 100 > 70
      for: 2m
      dynamic_metrics:
        names:
          - container_cpu_cfs_periods_total
          - container_cpu_cfs_throttled_periods_total
          - kube_pod_container_resource_limits
          - kube_pod_container_resource_requests
          - namespace_workload_pod:kube_pod_owner:relabel
          - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate
          - node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate
    - collect: SNOHighMemoryUsage
      annotations:
        description: >
          Collects the dynamic metrics specified if the cluster memory usage is constantly more than 70% for 2 minutes
      expr: (1 - sum(:node_memory_MemAvailable_bytes:sum) / sum(kube_node_status_allocatable{resource=\"memory\"})) * 100 > 70
      for: 2m
      dynamic_metrics:
        names:
          - kube_pod_container_resource_limits
          - kube_pod_container_resource_requests
          - namespace_workload_pod:kube_pod_owner:relabel
        matches:
          - __name__="container_memory_cache",container!=""
          - __name__="container_memory_rss",container!=""
          - __name__="container_memory_swap",container!=""
          - __name__="container_memory_working_set_bytes",container!=""
Copy to Clipboard Toggle word wrap

以下の例のように、collect_rules.group は custom-allowlist で無効にできます。collect_rules.group を無効にすると、メトリクスの収集が以前の動作に戻ります。これらのメトリクスは、指定された間隔で定期的に収集されます。 

collect_rules:
  - group: -SNOResourceUsage
Copy to Clipboard Toggle word wrap

データは、ルールの開始時のみ Grafana に表示されます。

1.6.1.5. 関連情報
リンクのコピー

1.6.2. 可観測性アドオンのプロキシー設定
リンクのコピー

マネージドクラスターからの通信が HTTP および HTTPS プロキシーサーバー経由でハブクラスターにアクセスできるようにプロキシー設定を指定します。通常、アドオンでは、ハブクラスターとマネージドクラスターの間で HTTP および HTTPS プロキシーサーバーをサポートする特別な設定は必要ありません。ただし、可観測性アドオンを有効にしている場合は、プロキシー設定を完了する必要があります。

1.6.2.1. 前提条件
リンクのコピー

  • ハブクラスターがある。
  • ハブクラスターとマネージドクラスター間のプロキシー設定が有効にしている。

1.6.2.2. プロキシー設定
リンクのコピー

可観測性アドオンのプロキシー設定を指定するには、以下の手順を実行します。

  1. ハブクラスターのクラスター namespace に移動します。

  2. spec.proxyConfig パラメーターを追加して、プロキシー設定を使用して AddOnDeploymentConfig リソースを作成します。以下は、YAML の例です。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: <addon-deploy-config-name>
  namespace: <managed-cluster-name>
spec:
  agentInstallNamespace: open-cluster-management-addon-observability
  proxyConfig:
    httpsProxy: "http://<username>:<password>@<ip>:<port>"
    1 
    
    noProxy: ".cluster.local,.svc,172.30.0.1"
    2
    Copy to Clipboard Toggle word wrap
    1
    このフィールドには、HTTP プロキシーまたは HTTPS プロキシーのいずれかを指定できます。
    2
    kube-apiserver の IP アドレスを含めます。

  3. マネージドクラスターで IP アドレスを取得するには、以下のコマンドを実行します。 

    oc -n default describe svc kubernetes | grep IP:
    Copy to Clipboard Toggle word wrap

  4. ManagedClusterAddOn リソースに移動し、作成した AddOnDeploymentConfig リソースを参照して更新します。以下は、YAML の例です。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: observability-controller
  namespace: <managed-cluster-name>
spec:
  installNamespace: open-cluster-management-addon-observability
  configs:
  - group: addon.open-cluster-management.io
    resource: addondeploymentconfigs
    name: <addon-deploy-config-name>
    namespace: <managed-cluster-name>
    Copy to Clipboard Toggle word wrap

  5. プロキシー設定を検証します。プロキシー設定が正常に設定されている場合、マネージドクラスター上の可観測性アドオンエージェントによってデプロイされたメトリクスコレクターが、データをハブクラスターに送信します。以下の手順を実行します。

    1. ハブクラスターに移動し、Grafana ダッシュボードでマネージドクラスターに移動します。
    2. プロキシー設定のメトリクスを表示します。

1.6.2.3. 可観測性アドオンのプロキシー設定の無効化
リンクのコピー

開発に必要な変更がある場合は、ハブクラスターとマネージドクラスターに設定した可観測性アドオンのプロキシー設定を無効にすることが必要な場合があります。可観測性アドオンのプロキシー設定はいつでも無効にできます。以下の手順を実行します。

  1. ManagedClusterAddOn リソースに移動します。
  2. 参照される AddOnDeploymentConfig リソースを削除します。

1.6.3. ルート証明書のカスタマイズ
リンクのコピー

OpenShift Container Platform ルート認証をカスタマイズする場合は、ルートを alt_names セクションに追加する必要があります。OpenShift Container Platform ルートにアクセスできるようにするには、alertmanager.apps.<domainname>、observatorium-api.apps.<domainname>、rbac-query-proxy.apps.<domainname> の情報を追加します。

注記: ユーザーは証明書のローテーションおよび更新を行います。

1.6.3.1. オブジェクトストアにアクセスするための証明書のカスタマイズ
リンクのコピー

認証局を含む Secret リソースを作成し、MultiClusterObservability カスタムリソースを設定することで、監視オブジェクトストアとの安全な接続を設定できます。以下の手順を実行します。

  1. オブジェクトストア接続を検証するには、次のコマンドを使用して、認証局を含むファイルに Secret オブジェクトを作成します。 

    oc create secret generic <tls_secret_name> --from-file=ca.crt=<path_to_file> -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap
    1. あるいは、次の YAML を適用してシークレットを作成することもできます。 
    apiVersion: v1
kind: Secret
metadata:
  name: <tls_secret_name>
  namespace: open-cluster-management-observability
type: Opaque
data:
  ca.crt: <base64_encoded_ca_certificate>
    Copy to Clipboard Toggle word wrap

    オプション: 相互 TLS を有効にする場合は、前のシークレットに public.crt キーと private.key キーを追加する必要があります。

  2. 次のコマンドを使用して、metricObjectStorage セクションに TLS シークレットの詳細を追加します。 

    oc edit mco observability -o yaml
    Copy to Clipboard Toggle word wrap

    ファイルは次の YAML のようになります。 

    metricObjectStorage:
  key: thanos.yaml
  name: thanos-object-storage
  tlsSecretName: tls-certs-secret
    1 
    
  tlsSecretMountPath: /etc/<s3-directory>/certs
    2
    Copy to Clipboard Toggle word wrap
    1
    tlsSecretName の値は、以前に作成した Secret オブジェクトの名前です。
    2
    tlsSecretMountPath パラメーターに定義された /etc/<s3-directory>/certs/ パスは、Observability コンポーネント内で証明書がマウントされる場所を指定します。このパスは次のステップに必要です。

  3. 証明書の詳細を含む http_config.tls_config セクションを追加して、thanos-object-storage シークレットの thanos.yaml 定義を更新します。以下の例を参照してください。必要に応じて値を置き換えます。 

    thanos.yaml: |
   type: s3
   config:
     bucket: <bucket-name>
     endpoint: <s3.port>
     insecure: false
    1 
    
     access_key: <s3-access>
     secret_key: <s3-secret>
     http_config:
       tls_config:
         ca_file: /etc/<s3-directory>/certs/ca.crt
    2 
    
         insecure_skip_verify: false
    Copy to Clipboard Toggle word wrap
    1
    HTTPS を有効にするには、insecure パラメーターを false に設定します。
    2
    ca_file パラメーターのパスは、MultiClusterObservability カスタムリソースの tlsSecretMountPath と一致させる必要があります。ca.crt は、<tls_secret_name> Secret リソース内のキーと一致させる必要があります。

    オプション: 相互 TLS を有効にする場合は、tls_config セクションに cert_file キーと key_file キーを追加する必要があります。以下の例を参照してください。必要に応じて値を置き換えます。 

     thanos.yaml: |
    type: s3
    config:
      bucket: <bucket-name>
      endpoint: <s3.port>
      insecure: false
      access_key: <s3-access>
      secret_key: <s3-secret>
      http_config:
        tls_config:
          ca_file: /etc/<s3-directory>/certs/ca.crt
    1 
    
          cert_file: /etc/<s3-directory>/certs/public.crt
          key_file: /etc/<s3-directory>/certs/private.key
          insecure_skip_verify: false
    Copy to Clipboard Toggle word wrap
    1
    ca_file、cert_file、および key_file のパスは、MultiClusterObservability カスタムリソースの tlsSecretMountPath と一致させる必要があります。ca.crt、public.crt、private.crt は、tls_secret_name> Secret リソース内のそれぞれのキーと一致させる必要があります。

  4. オブジェクトストアにアクセスできることを確認するには、Pod がデプロイされていることを確認します。以下のコマンドを実行します。 

    oc -n open-cluster-management-observability get pods -l app.kubernetes.io/name=thanos-store
    Copy to Clipboard Toggle word wrap

1.6.3.2. 関連情報
リンクのコピー

1.6.4. カスタムルールの作成
リンクのコピー

可観測性リソースに、Prometheus レコードルール および アラートルール を追加して、可観測性インストールのカスタムルールを作成します。

高価な式を事前計算するには、Prometheus の記録ルール機能を使用してアラート条件を作成し、外部サービスにアラートを送信する方法に基づいて通知を送信します。結果は新たな時系列のセットとして保存されます。

thanos-ruler-custom-rules config map 内にカスタムアラートルールを作成するには、次の手順を実行します。

  1. CPU 使用率が定義した値を超えたときに通知を受け取るには、次のカスタムアラートルールを作成します。 

    data:
  custom_rules.yaml: |
    groups:
      - name: cluster-health
        rules:
        - alert: ClusterCPUHealth-jb
          annotations:
            summary: Notify when CPU utilization on a cluster is greater than the defined utilization limit
            description: "The cluster has a high CPU usage: {{ $value }} core for {{ $labels.cluster }} {{ $labels.clusterID }}."
          expr: |
            max(cluster:cpu_usage_cores:sum) by (clusterID, cluster, prometheus) > 0
          for: 5s
          labels:
            cluster: "{{ $labels.cluster }}"
            prometheus: "{{ $labels.prometheus }}"
            severity: critical
    Copy to Clipboard Toggle word wrap

    注記:

    • カスタムルールを更新すると、observability-thanos-rule Pod が自動的に再起動します。
    • 設定には、複数のルールを作成できます。
    • デフォルトのアラートルールは、open-cluster-management-observability namespace の observability-thanos-rule-default-rules config map にあります。

  2. Pod のコンテナーメモリーキャッシュの合計を取得するためのカスタム記録ルールを作成します。以下の例を参照してください。 

    data:
  custom_rules.yaml: |
    groups:
      - name: container-memory
        rules:
        - record: pod:container_memory_cache:sum
          expr: sum(container_memory_cache{pod!=""}) BY (pod, container)
    Copy to Clipboard Toggle word wrap

    注記: config map に変更を加えた後、設定は自動的に再読み込みされます。この設定は、observability-thanos-rule サイドカー内の config-reload により、設定が再読み込みされます。

アラートルールが正しく機能していることを確認するには、Grafana ダッシュボードに移動し、Explore ページを選択して、ALERTS にクエリーを実行します。アラートを作成した場合、アラートは Grafana でのみ使用できます。

1.6.4.1. 関連情報
リンクのコピー

1.6.5. コンソールからの MultiClusterObservability カスタムリソースレプリカの更新
リンクのコピー

ワークロードが増加する場合は、可観測性 Pod のレプリカ数を増やします。ハブクラスターからコンソールに移動します。MultiClusterObservability カスタムリソースを見つけて、レプリカを変更するコンポーネントの replicas パラメーター値を更新します。更新した YAML は以下のようになります。 

spec:
   advanced:
      receive:
         replicas: 6
Copy to Clipboard Toggle word wrap

mco observability カスタムリソース内のパラメーターの詳細は、可観測性 API ドキュメントを参照してください。

1.6.6. 永続ボリュームおよび永続ボリューム要求の増減
リンクのコピー

永続ボリュームと永続ボリューム要求を増減して、ストレージクラス内のストレージの量を変更します。以下の手順を実行します。

  1. ストレージクラスがボリュームの拡張をサポートしている場合は、MultiClusterObservability カスタムリソースを更新して、永続ボリュームのサイズを増やします。

  2. 永続ボリュームのサイズを小さくするには、永続ボリュームを使用している Pod を削除し、永続ボリュームを削除して再作成します。永続ボリュームでデータが失われる可能性があります。以下の手順を実行します。

    1. MultiClusterObservability カスタムリソースにアノテーション mco-pause: "true" を追加して、MultiClusterObservability Operator を一時停止します。

    2. 目的のコンポーネントのステートフルセットまたはデプロイメントを探します。レプリカ数を 0 に変更します。これによりシャットダウンが開始され、データの損失を避けるために、該当する場合はローカルデータがアップロードされます。たとえば、Thanos Receive ステートフルセットの名前は observability-thanos-receive-default で、デフォルトでは 3 つのレプリカがあります。したがって、次の永続ボリューム要求を探します。

      • data-observability-thanos-receive-default-0
      • data-observability-thanos-receive-default-1
      • data-observability-thanos-receive-default-2
    3. 必要なコンポーネントによって使用される永続ボリュームおよび永続ボリューム要求を削除します。
    4. MultiClusterObservability カスタムリソースで、コンポーネントの設定のストレージサイズを、ストレージサイズフィールドで必要な量に編集します。接頭辞にはコンポーネントの名前が付いています。
    5. 以前に追加したアノテーションを削除して MultiClusterObservability Operator の一時停止を解除します。
    6. Operator を一時停止した後に調整を開始するには、multicluster-observability-operator および observatorium-operator Pod を削除します。Pod はすぐに再作成され、調整されます。
  3. MultiClusterObservability カスタムリソースをチェックして、永続ボリュームとボリューム要求が更新されていることを確認します。

ロードバランサーまたはリザーブプロキシーを使用するときに、マネージドクラスターがハブクラスターとの通信に使用する Observatorium API および Alertmanager URL をカスタマイズして、すべての Red Hat Advanced Cluster Management 機能を維持できます。URL をカスタマイズするには、次の手順を実行します。

  1. MultiClusterObservability spec の advanced セクションに URL を追加します。以下の例を参照してください。 
spec:
  advanced:
    customObservabilityHubURL: <yourURL>
    customAlertmanagerHubURL: <yourURL>
Copy to Clipboard Toggle word wrap

注記:

  • HTTPS URL のみがサポートされます。URL に https:// を追加しない場合、スキームは自動的に追加されます。
  • customObservabilityHubURL spec に、リモート書き込み API の標準パス /api/metrics/v1/default/api/v1/receive を含めることができます。パスを含めない場合、Observability サービスは実行時にパスを自動的に追加します。

  • カスタム Observability ハブクラスター URL に使用する中間コンポーネントは MTLS 認証に依存しているため、TLS 終端を使用できません。カスタム Alertmanager ハブクラスター URL は、独自の既存の証明書手順を使用して中間コンポーネントの TLS 終端をサポートします。

    1. customObservabilityHubURL を使用している場合は、次のテンプレートを使用してルートオブジェクトを作成します。<intermediate_component_url> を中間コンポーネントの URL に置き換えます。 
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: proxy-observatorium-api
  namespace: open-cluster-management-observability
spec:
  host: <intermediate_component_url>
  port:
    targetPort: public
  tls:
    insecureEdgeTerminationPolicy: None
    termination: passthrough
  to:
    kind: Service
    name: observability-observatorium-api
    weight: 100
  wildcardPolicy: None
Copy to Clipboard Toggle word wrap
  1. customAlertmanagerHubURL を使用している場合は、次のテンプレートを使用してルートオブジェクトを作成します。<intermediate_component_url> を中間コンポーネントの URL に置き換えます。 
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: alertmanager-proxy
  namespace: open-cluster-management-observability
spec:
  host: <intermediate_component_url>
  path: /api/v2
  port:
    targetPort: oauth-proxy
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: reencrypt
  to:
    kind: Service
    name: alertmanager
    weight: 100
  wildcardPolicy: None
Copy to Clipboard Toggle word wrap

1.6.7.1. 関連情報
リンクのコピー

1.6.8. 詳細な RBAC の設定 (テクノロジープレビュー)
リンクのコピー

クラスター内の特定 namespace へのメトリクスアクセスを制限するには、詳細なロールベースアクセス制御 (RBAC) を使用します。詳細な RBAC を使用すると、アクセス権が付与された namespace のメトリクスのみの表示をアプリケーションチームに許可することができます。

ハブクラスターのユーザーのメトリクスアクセス制御は、ハブクラスター上で設定する必要があります。このハブクラスターでは、ManagedCluster カスタムリソースによってすべてのマネージドクラスターが表されます。RBAC を設定し、許可する namespace を選択するには、ManagedCluster カスタムリソースで指定されているルールとアクション動詞を使用します。

たとえば、my-awesome-app という名前のアプリケーションがあり、このアプリケーションが devcluster1 と devcluster2 という 2 つの異なるマネージドクラスター上にあるとします。どちらのクラスターも AwesomeAppNS namespace にあります。my-awesome-app-admins という名前の admin ユーザーグループがあり、このユーザーグループが、ハブクラスター上のこれら 2 つの namespace からのメトリクスにのみアクセスできるように制限するとします。

粒度の細かい RBAC を使用してユーザーグループのアクセスを制限するには、次の手順を実行します。

  1. メトリクスにアクセスする権限を持つ ClusterRole リソースを定義します。リソースは次の YAML のようになります。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: awesome-app-metrics-role
rules:
 - apiGroups:
     - "cluster.open-cluster-management.io"
   resources:
     - managedclusters:
    1 
    
   resourceNames:
    2 
    
     - devcluster1
     - devcluster2
   verbs:
    3 
    
     - metrics/AwesomeAppNS
    Copy to Clipboard Toggle word wrap
    1
    マネージドクラスターのパラメーター値を表します。
    2
    マネージドクラスターのリストを表します。
    3
    マネージドクラスターの namespace を表します。

  2. グループ my-awesome-app-admins を awesome-app-metrics-role の ClusterRole リソースにバインドする ClusterRoleBinding リソースを定義します。リソースは次の YAML のようになります。 

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: awesome-app-metrics-role-binding
subjects:
 - kind: Group
   apiGroup: rbac.authorization.k8s.io
   name: my-awesome-app-admins
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: awesome-app-metrics-role
    Copy to Clipboard Toggle word wrap

これらの手順を完了すると、my-awesome-app-admins のユーザーが Grafana コンソールにログインするときに、次の制限が適用されます。

  • フリートレベルのデータを要約したダッシュボードのデータがユーザーに表示されません。
  • ユーザーは、ClusterRole リソースで指定されているマネージドクラスターと namespace のみを選択できます。

異なるタイプのユーザーアクセスを設定するには、namespace 内の異なるマネージドクラスターを表す個別の ClusterRoles および ClusterRoleBindings リソースを定義します。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat