1.4. 可観測性設定のカスタマイズ


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

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

1.4.1. カスタムルールの作成

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

高価な式を事前計算するには、Prometheus の記録ルール機能を使用してアラート条件を作成し、外部サービスにアラートを送信する方法に基づいて通知を送信します。結果は新たな時系列のセットとして保存されます。observability-thanos-rule-custom-rules config map 内にカスタムアラートルールを作成するには、次の例を参照してください。

  • 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

    注記:

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

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

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

1.4.2. カスタムメトリックの追加

metrics_list.yaml ファイルにメトリクスを追加して、マネージドクラスターから収集します。以下の手順を実行します。

  1. カスタムメトリックを追加する前に、次のコマンドを使用して mco observability が有効になっていることを確認します。

    oc get mco observability -o yaml
  2. status.conditions.message セクションで、以下のメッセージを確認します。

    Observability components are deployed and running
  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
  4. metrics_list.yaml パラメーターにカスタムメトリックの名前を追加します。config map の YAML は、以下の内容のようになります。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: observability-metrics-custom-allowlist
    data:
      metrics_list.yaml: |
        names: 1
          - node_memory_MemTotal_bytes
        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))
    1
    オプション: マネージドクラスターから収集されるカスタムメトリックの名前を追加します。
    2
    オプション: exprrecord パラメーターのペアに値を 1 つだけ入力して、クエリー式を定義します。メトリックは、マネージドクラスターの record パラメーターで定義される名前で収集されます。クエリー式の実行後の結果が、メトリックの値として返されます。

    セクションのいずれかまたは両方を使用できます。ユーザーワークロードメトリクスは、ユーザーワークロードメトリクスの追加 セクションを参照してください。

    注記: カスタムメトリクス許可リスト内の各マネージドクラスターを、フリート全体に適用するのではなく、個別にカスタマイズすることもできます。同じ YAML をマネージドクラスター上で直接作成してカスタマイズできます。

  5. Grafana ダッシュボードの Explore ページからメトリクスをクエリーして、カスタムメトリクスからのデータコレクションを確認します。独自のダッシュボードでカスタムメトリックを使用することもできます。

1.4.2.1. ユーザーワークロードメトリクスの追加

OpenShift Container Platform のワークロードから OpenShift Container Platform ユーザー定義のメトリクスを収集し、Grafana ダッシュボードからメトリクスを表示します。以下の手順を実行します。

  1. OpenShift Container Platform クラスターでモニタリングを有効にします。関連情報 セクションの ユーザー定義プロジェクトの監視の有効化 を参照してください。

    ユーザー定義のワークロードの監視が有効になっているマネージドクラスターがある場合、ユーザーのワークロードは test namespace に配置され、メトリクスを生成します。これらのメトリクスは、OpenShift Container Platform ユーザーワークロードから Prometheus によって収集されます。

  2. ユーザーワークロードメトリックを observability-metrics-custom-allowlist config map に追加して、test namespace のメトリックを収集します。以下の例を参照してください。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: observability-metrics-custom-allowlist
      namespace: test
    data:
      uwl_metrics_list.yaml: 1
        names: 2
          - sample_metrics
    1
    config map データのキーを入力します。
    2
    config map データの値を YAML 形式で入力します。names セクションには、test namespace から収集するメトリック名のリストが含まれます。config map を作成すると、可観測性コレクターはメトリクスを収集し、ターゲット namespace からハブクラスターにプッシュします。

1.4.2.2. デフォルトメトリックの削除

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

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

    oc get mco observability -o yaml
  2. メトリック名の先頭にハイフン - を指定して metrics_list.yaml パラメーターにデフォルトのメトリック名を追加します。次のメトリックの例を確認してください。

    -cluster_infrastructure_provider
  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
  4. 可観測性サービスがマネージドクラスターから特定のメトリクスを収集していないことを確認します。Grafana ダッシュボードからメトリックをクエリーしても、メトリックは表示されません。

1.4.3. 保持の詳細設定の追加

必要に応じて各可観測性コンポーネントの保持を更新するには、advanced 設定セクションを追加します。以下の手順を実行します。

  1. 次のコマンドを使用して、MultiClusterObservability カスタムリソースを編集します。

    oc edit mco observability -o yaml
  2. ファイルに advanced セクションを追加します。YAML ファイルは以下の内容のようになります。

    spec:
      advanced:
        retentionConfig:
          blockDuration: 2h
          deleteDelay: 48h
          retentionInLocal: 24h
          retentionResolutionRaw: 365d
          retentionResolution5m: 365d
          retentionResolution1h: 365d
        receive:
          resources:
            limits:
              memory: 4096Gi
          replicas: 3

    注記:

    • advanced 設定に追加できるすべてのパラメーターの説明は、Observability API ドキュメントを参照してください。
    • すべての解像度レベル (retentionResolutionRawretentionResolution5mretentionResolution1h など) のデフォルトの保持期間は 365 日 (365d) です。MultiClusterObservability spec.advanced.retentionConfig パラメーターで、解像度保持の明示的な値を設定する必要があります。
  3. 以前のバージョンからアップグレードし、そのバージョン保持設定を保持する場合は、前述の設定を追加します。以下の手順を実行します。

    1. 次のコマンドを実行して、MultiClusterObservability リソースに移動します。

      edit mco observability
    2. spec.advanced.retentionConfig パラメーターで、次の設定を適用します。
    spec:
      advanced:
        retentionConfig:
          retentionResolutionRaw: 365d
          retentionResolution5m: 365d
          retentionResolution1h: 365d

1.4.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!=""

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

collect_rules:
  - group: -SNOResourceUsage

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

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

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

spec:
   advanced:
      receive:
         replicas: 6

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

1.4.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 カスタムリソースをチェックして、永続ボリュームとボリューム要求が更新されていることを確認します。

1.4.7. ルート証明書のカスタマイズ

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

詳細は、ガバナンスドキュメントの alertmanager ルートの証明書の置き換え を参照してください。

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

1.4.8. オブジェクトストアにアクセスするための証明書のカスタマイズ

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

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

    oc create secret generic <tls_secret_name> --from-file=ca.crt=<path_to_file> -n open-cluster-management-observability
    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>

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

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

    oc edit mco observability -o yaml

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

    metricObjectStorage:
      key: thanos.yaml
      name: thanos-object-storage
      tlsSecretName: tls-certs-secret 1
      tlsSecretMountPath: /etc/minio/certs 2
    1
    tlsSecretName の値は、以前に作成した Secret オブジェクトの名前です。
    2
    tlsSecretMountPath パラメーターに定義された /etc/minio/certs/ パスは、Observability コンポーネント内で証明書がマウントされる場所を指定します。このパスは次のステップに必要です。
  3. 証明書の詳細を含む http_config.tls_config セクションを追加して、thanos-object-storage シークレットの thanos.yaml 定義を更新します。以下の例を参照してください。

    thanos.yaml: |
       type: s3
       config:
         bucket: "thanos"
         endpoint: "minio:9000"
         insecure: false 1
         access_key: "minio"
         secret_key: "minio123"
         http_config:
           tls_config:
             ca_file: /etc/minio/certs/ca.crt 2
             insecure_skip_verify: false
    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: "thanos"
          endpoint: "minio:9000"
          insecure: false
          access_key: "minio"
          secret_key: "minio123"
          http_config:
            tls_config:
              ca_file: /etc/minio/certs/ca.crt 1
              cert_file: /etc/minio/certs/public.crt
              key_file: /etc/minio/certs/private.key
              insecure_skip_verify: false
    1
    ca_filecert_file、および key_file のパスは、MultiClusterObservability カスタムリソースの tlsSecretMountPath と一致させる必要があります。ca.crtpublic.crtprivate.crt は、tls_secret_name> Secret リソース内のそれぞれのキーと一致させる必要があります。
  4. オブジェクトストアにアクセスできることを確認するには、Pod がデプロイされていることを確認します。以下のコマンドを実行します。

    oc -n open-cluster-management-observability get pods -l app.kubernetes.io/name=thanos-store

1.4.9. 可観測性アドオンのプロキシー設定

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

1.4.10. 前提条件

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

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

  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-managment-addon-observability
      proxyConfig:
        httpsProxy: "http://<username>:<password>@<ip>:<port>" 1
        noProxy: ".cluster.local,.svc,172.30.0.1" 2
    1
    このフィールドには、HTTP プロキシーまたは HTTPS プロキシーのいずれかを指定できます。
    2
    kube-apiserver の IP アドレスを含めます。
  3. マネージドクラスターで IP アドレスを取得するには、以下のコマンドを実行します。

    oc -n default describe svc kubernetes | grep IP:
  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-managment-addon-observability
      configs:
      - group: addon.open-cluster-management.io
        resource: AddonDeploymentConfig
        name: <addon-deploy-config-name>
        namespace: <managed-cluster-name>
  5. プロキシー設定を確認してください。プロキシー設定が正常に指定されている場合に、マネージドクラスター上の可観測性アドオンエージェントによってデプロイされたメトリックコレクターはデータをハブクラスターに送信します。以下の手順を実行します。

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

1.4.11. 可観測性アドオンのプロキシー設定の無効化

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

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

1.4.12. マネージドクラスター Observatorium API と Alertmanager URL のカスタマイズ (テクノロジープレビュー)

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

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

注記:

  • 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
  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

1.4.13. 詳細な RBAC の設定 (テクノロジープレビュー)

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

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

たとえば、my-awesome-app という名前のアプリケーションがあり、このアプリケーションが devcluster1devcluster2 という 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
    1
    マネージドクラスターのパラメーター値を表します。
    2
    マネージドクラスターのリストを表します。
    3
    マネージドクラスターの namespace を表します。
  2. グループ my-awesome-app-adminsawesome-app-metrics-roleClusterRole リソースにバインドする 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

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

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

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

1.4.14. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.