1.4. 관찰 기능 구성 사용자 정의


관찰 기능을 활성화한 후 환경의 특정 요구 사항에 맞게 관찰 기능 구성을 사용자 지정합니다. 관찰 기능 서비스에서 수집하는 클러스터 플릿 데이터를 관리하고 확인합니다.

필수 액세스: 클러스터 관리자

1.4.1. 사용자 정의 규칙 생성

관찰 가능성 리소스에 Prometheus 기록 규칙 및 경고 규칙을 추가하여 관찰 기능 설치에 대한 사용자 정의 규칙을 생성합니다.

비용이 많이 드는 표현식을 미리 계산하려면 Prometheus와 함께 레코딩 규칙 기능을 사용하여 경고 조건을 생성하고 외부 서비스에 경고를 보내는 방법에 따라 알림을 보냅니다. 결과는 새로운 시계열로 저장됩니다. observability-thanos-rule-custom-rules 구성 맵에 사용자 정의 경고 규칙을 생성하려면 다음 예제를 확인합니다.

  • 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 네임스페이스의 observability-thanos-rule-default-rules 구성 맵에 있습니다.
  • 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)

    참고: 구성 맵을 변경한 후 구성이 자동으로 다시 로드됩니다. observability-thanos-rule 사이드카 내의 config-reload 로 인해 구성이 다시 로드됩니다.

경고 규칙이 올바르게 작동하는지 확인하려면 Grafana 대시보드로 이동하여 탐색 페이지를 선택하고 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 네임스페이스에 observability-metrics-custom-allowlist 구성 맵을 생성합니다.

    oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
  4. 사용자 지정 지표의 이름을 metrics_list.yaml 매개변수에 추가합니다. 구성 맵의 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 매개변수 쌍에 대해 하나의 값만 입력하여 쿼리 표현식을 정의합니다. 메트릭은 관리 클러스터의 record 매개변수에 정의된 이름으로 수집됩니다. 반환된 메트릭 값은 쿼리 표현식을 실행한 후 결과입니다.

    하나 또는 두 개의 섹션을 사용할 수 있습니다. 사용자 워크로드 메트릭은 사용자 워크로드 메트릭 추가 섹션을 참조하십시오.

    참고: 전체 함대에 적용하는 대신 사용자 지정 메트릭 허용 목록에서 각 관리 클러스터를 개별적으로 사용자 지정할 수도 있습니다. 관리 클러스터에서 직접 동일한 YAML을 생성하여 사용자 지정할 수 있습니다.

  5. Grafana 대시보드 탐색 페이지에서 지표를 쿼리하여 사용자 지정 지표에서 데이터 수집을 확인합니다. 자체 대시보드에서 사용자 지정 메트릭을 사용할 수도 있습니다.

1.4.2.1. 사용자 워크로드 메트릭 추가

OpenShift Container Platform의 워크로드에서 OpenShift Container Platform 사용자 정의 메트릭을 수집하여 Grafana 대시보드의 지표를 표시합니다. 다음 단계를 완료합니다.

  1. OpenShift Container Platform 클러스터에서 모니터링을 활성화합니다. 추가 리소스 섹션에서 사용자 정의 프로젝트에 대한 모니터링 활성화를 참조하십시오.

    사용자 정의 워크로드가 활성화된 관리형 클러스터가 있는 경우 사용자 워크로드는 테스트 네임스페이스에 있으며 메트릭을 생성합니다. 이러한 메트릭은 OpenShift Container Platform 사용자 워크로드에서 Prometheus에 의해 수집됩니다.

  2. observability-metrics-custom-allowlist 구성 맵에 사용자 워크로드 지표를 추가하여 테스트 네임스페이스에서 지표를 수집합니다. 다음 예제를 확인합니다.

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: observability-metrics-custom-allowlist
      namespace: test
    data:
      uwl_metrics_list.yaml: 1
        names: 2
          - sample_metrics
    1
    구성 맵 데이터의 키를 입력합니다.
    2
    YAML 형식으로 구성 맵 데이터의 값을 입력합니다. names 섹션에는 테스트 네임스페이스에서 수집할 지표 이름 목록이 포함되어 있습니다. 구성 맵을 생성한 후 관찰 가능 수집기는 대상 네임스페이스에서 허브 클러스터로 지표를 수집하고 푸시합니다.

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 네임스페이스에 observability-metrics-custom-allowlist 구성 맵을 생성합니다.

    oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
  4. 관찰 기능 서비스가 관리 클러스터에서 특정 지표를 수집하지 않는지 확인합니다. Grafana 대시보드에서 지표를 쿼리하면 지표가 표시되지 않습니다.

1.4.3. 보존을 위한 고급 구성 추가

필요에 따라 각 관찰 가능성 구성 요소의 보존을 업데이트하려면 고급 구성 섹션을 추가합니다. 다음 단계를 완료합니다.

  1. 다음 명령을 사용하여 MultiClusterObservability 사용자 정의 리소스를 편집합니다.

    oc edit mco observability -o yaml
  2. 고급 섹션을 파일에 추가합니다. YAML 파일은 다음 내용과 유사할 수 있습니다.

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

    참고:

    • 고급 구성에 추가할 수 있는 모든 매개변수에 대한 설명은 Observability API 설명서를 참조하십시오.
    • retentionResolutionRaw,retentionResolution5m 또는 retentionResolution1h 와 같은 모든 해결 수준에 대한 기본 보존은 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 클러스터는 포드 및 컨테이너 리소스 지표를 수집하지 않습니다. 단일 노드 OpenShift 클러스터가 특정 리소스 소비 수준에 도달하면 정의된 세분화된 메트릭이 동적으로 수집됩니다. 일정 기간 동안 클러스터 리소스 사용량이 임계값보다 일관되게 작으면 세분화된 메트릭 수집이 중지됩니다.

메트릭은 컬렉션 규칙에 의해 지정된 관리 클러스터의 조건에 따라 동적으로 수집됩니다. 이러한 메트릭은 동적으로 수집되므로 다음 Red Hat Advanced Cluster Management Grafana 대시보드는 데이터를 표시하지 않습니다. 컬렉션 규칙이 활성화되고 해당 메트릭이 수집되면 다음 패널은 수집 규칙이 시작되는 기간 동안 데이터를 표시합니다.

  • Kubernetes/Compute 리소스/네임스페이스(Pods)
  • Kubernetes/Compute 리소스/네임스페이스(워크로드)
  • Kubernetes/Compute 리소스/노드(Pods)
  • Kubernetes/Compute 리소스/Pod
  • Kubernetes/Compute Resources/Workload 컬렉션 규칙에는 다음 조건이 포함됩니다.
  • 동적으로 수집할 지표 세트입니다.
  • PromQL 표현식으로 작성된 조건입니다.
  • 컬렉션의 시간 간격을 true 로 설정해야 합니다.
  • 수집 규칙을 평가해야 하는 클러스터를 선택하는 일치 표현식입니다.

기본적으로 컬렉션 규칙은 관리 클러스터에서 30초마다 또는 특정 시간 간격으로 지속적으로 평가됩니다. 컬렉션 간격과 시간 간격 사이의 가장 낮은 값이 우선합니다. for 속성에서 지정한 기간 동안 컬렉션 규칙 조건이 지속되면 컬렉션 규칙이 시작되고 규칙에서 지정한 메트릭이 관리 클러스터에서 자동으로 수집됩니다. 메트릭 컬렉션은 컬렉션 규칙 조건이 더 이상 관리 클러스터에 없는 후 15분 이상 시작된 후 자동으로 중지됩니다.

컬렉션 규칙은 collect_rules 라는 매개 변수 섹션으로 그룹화됩니다. 여기서 그룹으로 활성화하거나 비활성화할 수 있습니다. Red Hat Advanced Cluster Management 설치에는 HighCPUUsageHighMemoryUsage 의 두 가지 기본 컬렉션 규칙이 있는 SNOResourceUsage SNOResourceUsage가 포함되어 있습니다. 노드 CPU 사용량이 70%를 초과하면 HighCPUUsage 컬렉션 규칙이 시작됩니다. 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의 복제본 수를 늘립니다. hub 클러스터에서 Red Hat OpenShift Container Platform 콘솔로 이동합니다. MultiClusterObservability 사용자 정의 리소스를 찾고 복제본을 변경하려는 구성 요소의 replicas 매개변수 값을 업데이트합니다. 업데이트된 YAML은 다음 콘텐츠와 유사할 수 있습니다.

spec:
   advanced:
      receive:
         replicas: 6

mco observability 사용자 정의 리소스 내의 매개변수에 대한 자세한 내용은 Observability API 설명서를 참조하십시오.

1.4.6. 영구 볼륨 및 영구 볼륨 클레임 증가 및 감소

영구 볼륨 및 영구 볼륨 클레임을 늘리고 줄여 스토리지 클래스의 스토리지 양을 변경합니다. 다음 단계를 완료합니다.

  1. 스토리지 클래스가 볼륨 확장을 지원하는 경우 영구 볼륨의 크기를 늘리려면 MultiClusterObservability 사용자 정의 리소스를 업데이트합니다.
  2. 영구 볼륨의 크기를 줄이려면 영구 볼륨을 사용하여 Pod를 제거한 후 영구 볼륨을 삭제하고 다시 생성합니다. 영구 볼륨에서 데이터 손실이 발생할 수 있습니다. 다음 단계를 완료합니다.

    1. MultiClusterObservability 사용자 정의 리소스에 주석 mco-pause: "true" 주석을 추가하여 MultiClusterObservability Operator를 일시 중지합니다.
    2. 원하는 구성 요소의 상태 저장 세트 또는 배포를 찾습니다. 복제본 수를 0 으로 변경합니다. 이렇게 하면 종료가 시작되어 데이터 손실을 방지하는 데 적용 가능한 경우 로컬 데이터를 업로드해야 합니다. 예를 들어 Thanos Receive stateful 세트의 이름은 observability-thanos-receive-default 이며 기본적으로 세 개의 복제본이 있습니다. 따라서 다음과 같은 영구 볼륨 클레임을 찾고 있습니다.

      • 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-operatorobservatorium-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 > 이라는 정보를 추가합니다.

자세한 내용은 Governance 문서의 alertmanager 경로에 대한 인증서 교체 를 참조하십시오.

참고: 사용자는 인증서 교체 및 업데이트를 담당합니다.

1.4.8. 오브젝트 저장소에 액세스하기 위한 인증서 사용자 정의

인증 기관이 포함된 Secret 리소스를 생성하고 MultiClusterObservability 사용자 정의 리소스를 구성하여 observability 오브젝트 저장소를 사용하여 보안 연결을 구성할 수 있습니다. 다음 단계를 완료합니다.

  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.crtprivate.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> 시크릿 리소스의 키와 일치해야 합니다.

    선택 사항: 상호 TLS를 활성화하려면 cert_filekey_file 키를 tls_config 섹션에 추가해야 합니다. 다음 예제를 참조하십시오.

     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_file,cert_file, key_file 의 경로는 MultiClusterObservability 사용자 정의 리소스의 tlsSecretMountPath 와 일치해야 합니다. ca.crt,public.crt, private.crttls_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 프록시 서버를 통해 hub 클러스터에 액세스할 수 있도록 프록시 설정을 구성합니다. 일반적으로 애드온은 허브 클러스터와 관리 클러스터 간에 HTTP 및 HTTPS 프록시 서버를 지원하기 위해 특별한 구성이 필요하지 않습니다. 그러나 관찰 기능 애드온을 활성화한 경우 프록시 구성을 완료해야 합니다.

1.4.10. 사전 요구 사항

  • 허브 클러스터가 있어야 합니다.
  • hub 클러스터와 관리 클러스터 간에 프록시 설정을 활성화했습니다.

관찰 기능 애드온에 대한 프록시 설정을 구성하려면 다음 단계를 완료합니다.

  1. hub 클러스터의 클러스터 네임스페이스로 이동합니다.
  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. hub 클러스터로 이동한 다음 Grafana 대시보드의 관리 클러스터로 이동합니다.
    2. 프록시 설정에 대한 메트릭을 확인합니다.

1.4.11. 관찰 기능 애드온에 대한 프록시 설정 비활성화

개발이 필요한 경우 hub 클러스터 및 관리 클러스터에 대해 구성한 관찰 기능 애드온에 대한 프록시 설정을 비활성화해야 할 수 있습니다. 언제든지 관찰 기능 애드온의 프록시 설정을 비활성화할 수 있습니다. 다음 단계를 완료합니다.

  1. ManagedClusterAddOn 리소스로 이동합니다.
  2. 참조된 AddOnDeploymentConfig 리소스를 제거합니다.

1.4.12. 관리형 클러스터 Observatorium API 및 Alertmanager URL 사용자 정의 (기술 프리뷰)

로드 밸런서 또는 예약 프록시를 사용할 때 관리 클러스터가 허브 클러스터와 통신하는 데 사용하는 Observatorium API 및 Alertmanager URL을 사용자 지정하여 모든 Red Hat Advanced Cluster Management 기능을 유지 관리할 수 있습니다. URL을 사용자 지정하려면 다음 단계를 완료합니다.

  1. MultiClusterObservability 사양고급 섹션에 URL을 추가합니다. 다음 예제를 참조하십시오.
spec:
  advanced:
    customObservabilityHubURL: <yourURL>
    customAlertmanagerHubURL: <yourURL>

참고:

  • HTTPS URL만 지원됩니다. URL에 https:// 를 추가하지 않으면 스키마가 자동으로 추가됩니다.
  • customObservabilityHubURL 사양에 Remote Write API의 표준 경로 /api/metrics/v1/default/api/v1/receive 를 포함할 수 있습니다. 경로를 포함하지 않으면 Observability 서비스가 런타임 시 경로를 자동으로 추가합니다.
  • 사용자 정의 Observability 허브 클러스터 URL에 사용하는 중간 구성 요소는 구성 요소가 MTLS 인증을 사용하므로 TLS 종료를 사용할 수 없습니다. 사용자 정의 Alertmanager 허브 클러스터 URL은 기존 인증서 지침을 사용하여 중간 구성 요소 TLS 종료를 지원합니다.

    1. customObservabilityHubURL 을 사용하는 경우 다음 템플릿을 사용하여 경로 오브젝트를 생성합니다. &lt ;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 을 사용하는 경우 다음 템플릿을 사용하여 경로 오브젝트를 생성합니다. &lt ;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 구성 (기술 프리뷰)

클러스터 내의 특정 네임스페이스에 대한 메트릭 액세스를 제한하려면 세분화된 역할 기반 액세스 제어(RBAC)를 사용합니다. 세분화된 RBAC를 사용하면 애플리케이션 팀이 액세스 권한을 부여하는 네임스페이스에 대한 메트릭만 볼 수 있습니다.

해당 허브 클러스터 사용자의 허브 클러스터에서 메트릭 액세스 제어를 구성해야 합니다. 이 허브 클러스터에서 ManagedCluster 사용자 정의 리소스는 모든 관리 클러스터를 나타냅니다. RBAC를 구성하고 허용된 네임스페이스를 선택하려면 ManagedCluster 사용자 정의 리소스에 지정된 규칙 및 작업 동사를 사용합니다.

예를 들어 my-awesome-app 이라는 애플리케이션이 있으며 이 애플리케이션은 devcluster1devcluster2 라는 두 개의 다른 관리 클러스터에 있습니다. 두 클러스터 모두 AwesomeAppNS 네임스페이스에 있습니다. admin 사용자 그룹 my-awesome-app-admins 가 있으며 이 사용자 그룹은 hub 클러스터의 두 네임 스페이스에서만 메트릭에 액세스할 수 있도록 제한하려고 합니다.

이 예제에서는 세분화된 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
    관리 클러스터의 네임스페이스를 나타냅니다.
  2. huge-app- metrics-role 에 대한 ClusterRole 리소스를 사용하여 my-awesome-app-admins 그룹을 바인딩하는 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 리소스에 지정된 관리 클러스터 및 네임스페이스만 선택할 수 있습니다.

다양한 유형의 사용자 액세스를 설정하려면 별도의 ClusterRolesClusterRoleBindings 리소스를 정의하여 네임스페이스의 다른 관리 클러스터를 나타냅니다.

1.4.14. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.