1.3. Red Hat Advanced Cluster Management의 알려진 문제 및 제한 사항

OpenShift Container Platform 4.18을 사용하여 기존 Red Hat Advanced Cluster Management 2.12 클러스터를 업그레이드하는 경우 MultiClusterHub 사용자 정의 리소스 인스턴스에 Observability 구성 요소를 설치하는 동안 오류가 발생했습니다.

참고: 이는 Red Hat Advanced Cluster Management 2.12.2 이전 버전에만 적용됩니다. Red Hat Advanced Cluster Management 2.12.2로 직접 업그레이드하는 경우 이 오류가 발생하지 않습니다. OpenShift Container Platform 4.18을 사용하여 Red Hat Advanced Cluster Management 2.12를 처음 설치하는 경우 이 오류가 발생하지 않습니다.

OpenShift Container Platform에서 Red Hat Advanced Cluster Management를 설치 제거하면 나중에 이전 버전을 설치한 다음 업그레이드하려는 경우 문제가 발생할 수 있습니다. 예를 들어 Red Hat Advanced Cluster Management를 제거한 다음 이전 버전의 Red Hat Advanced Cluster Management를 설치하고 해당 버전을 업그레이드하면 업그레이드가 실패할 수 있습니다. 사용자 정의 리소스가 제거되지 않은 경우 업그레이드가 실패합니다.

이 문제를 방지하려면 다시 설치하기 전에 아티팩트 정리 를 따르십시오.

infrastructure-operator 를 설치할 때 ARM과 통합 흐름이 작동하지 않습니다. 이 문제를 해결하려면 ALLOW_CONVERGED_FLOW 를 false 로 설정합니다.

문제가 해결되면 에이전트가 인벤토리에 나타납니다.

사용 가능한 경우 해결 방법과 함께 알려진 문제 및 제한 사항이 여기에 나열되어 있습니다.

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterSelector:
    matchLabels:
      environment: dev

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

콘솔에서 OpenShift Dedicated 클러스터에 대한 업그레이드를 요청할 수 있지만 openshift 클러스터 이외의 클러스터 오류 메시지와 함께 업그레이드할 수 없습니다. 현재는 해결방법이 없습니다.

search-postgres Pod는 CrashLoopBackoff 상태입니다. Red Hat Advanced Cluster Management가 hugepages 매개변수가 활성화된 노드가 있는 클러스터에 배포하고 search-postgres Pod가 이러한 노드에서 예약되는 경우 Pod가 시작되지 않습니다.

search-postgres Pod의 메모리를 늘리려면 다음 단계를 완료합니다.

다음 값이 512Mi 로 표시됩니다.

admin 역할 또는 bind 역할을 사용하여 클러스터 세트의 네임스페이스 바인딩을 편집하면 다음 메시지와 유사한 오류가 발생할 수 있습니다.

ResourceError: managedclustersetbindings.cluster.open-cluster-management.io "<cluster-set>" is forbidden: User "<user>" cannot create/delete resource "managedclustersetbindings" in API group "cluster.open-cluster-management.io".

이 문제를 해결하려면 바인딩하려는 네임스페이스에서 ManagedClusterSetBinding 리소스를 생성하거나 삭제할 수 있는 권한도 있어야 합니다. 역할 바인딩을 사용하면 클러스터 세트를 네임스페이스로 바인딩할 수 있습니다.

호스팅된 컨트롤 플레인 클러스터를 프로비저닝한 후 ClusterVersionUpgradeable 매개변수가 너무 길면 Red Hat Advanced Cluster Management 콘솔의 클러스터 개요에서 수평으로 스크롤하지 못할 수 있습니다. 결과적으로 숨겨진 데이터를 볼 수 없습니다.

이 문제를 해결하려면 브라우저 확대 컨트롤을 사용하여 축소하거나, Red Hat Advanced Cluster Management 콘솔 창을 늘리거나, 텍스트를 복사하여 다른 위치에 붙여넣습니다.

여러 레이블 표현식을 추가하거나 ApplicationSet 에 대한 클러스터 선택기를 입력하려고 하면 다음 메시지가 반복적으로 표시될 수 있습니다. "Expand to enter expression". 이 문제에도 클러스터 선택을 입력할 수 있습니다.

외부 ID 공급자를 사용하여 Red Hat Advanced Cluster Management에 로그인하는 경우 Red Hat Advanced Cluster Management에서 로그아웃하지 못할 수 있습니다. 이는 IBM Cloud 및 Keycloak과 함께 설치된 Red Hat Advanced Cluster Management를 ID 공급자로 사용할 때 발생합니다.

Red Hat Advanced Cluster Management에서 로그아웃하기 전에 외부 ID 공급자에서 로그아웃해야 합니다.

OpenShift Cloud Manager 콘솔에서 cluster-ID 에 액세스하지 않은 경우 터미널에서 AWS 클러스터 ID의 OpenShift Service에 대한 설명을 계속 가져올 수 있습니다. AWS 명령줄 인터페이스에 OpenShift Service가 필요합니다. AWS CLI에서 OpenShift 서비스 시작하기 설명서를 참조하십시오.

cluster-ID 를 가져오려면 AWS 명령줄 인터페이스의 OpenShift Service에서 다음 명령을 실행합니다.

rosa describe cluster --cluster=<cluster-name> | grep -o ’^ID:.*

rosa describe cluster --cluster=<cluster-name> | grep -o ’^ID:.*

hub 클러스터가 관리 클러스터에 도달하거나 통신할 수 없는 경우 다음과 같은 제한 사항이 발생합니다.

disableHubSelfManagement 를 false 로 설정하는 동안 local-cluster가 삭제되면 MulticlusterHub Operator가 local-cluster를 다시 생성합니다. local-cluster를 분리하면 local-cluster가 자동으로 다시 생성되지 않을 수 있습니다.

실수로 local-cluster 라는 클러스터를 다른 이름으로 다시 가져오려고 하면 local 클러스터의 상태 및 다시 가져오기된 클러스터의 상태가 오프라인으로 표시됩니다.

이 경우 복구하려면 다음 단계를 완료합니다.

Hub 클러스터 및 관리 클러스터 시간이 동기화되지 않아 알 수 없고 결국 몇 분 내에 사용할 수 있습니다. OpenShift Container Platform 허브 클러스터 시간이 올바르게 구성되었는지 확인합니다. 노드 사용자 지정을 참조하십시오.

배치 리소스에서 Exist 또는 DoesNotExist Operator를 사용하는 경우 애플리케이션 토폴로지 노드 세부 정보에 #invalidExpr. 이 디스플레이는 잘못된 것이며 표현식은 계속 유효하며 배치 리소스에서 작동합니다. 이 문제를 해결하려면 배치 리소스 YAML 내부의 표현식을 편집합니다.

PlacementRule 리소스를 참조하는 서브스크립션 애플리케이션을 생성하면 서브스크립션 YAML이 콘솔의 YAML 편집기에 표시되지 않습니다. 터미널을 사용하여 서브스크립션 YAML 파일을 편집합니다.

Helm 차트를 사용하여 Kubernetes 보안에 개인 정보 데이터를 정의하고 Helm 차트의 value.yaml 파일 내에서 이 시크릿을 참조할 수 있습니다.

사용자 이름과 암호는 참조된 Kubernetes 시크릿 리소스 dbsecret 에서 제공합니다. 예를 들어 다음 샘플 value.yaml 파일을 참조하십시오.

credentials:
  secretName: dbsecret
  usernameSecretKey: username
  passwordSecretKey: password

credentials:
  secretName: dbsecret
  usernameSecretKey: username
  passwordSecretKey: password

보안 종속 항목이 있는 Helm 차트는 Helm 바이너리 CLI에서만 지원됩니다. Operator SDK Helm 라이브러리에서는 지원되지 않습니다. Red Hat Advanced Cluster Management 서브스크립션 컨트롤러는 Operator SDK Helm 라이브러리를 적용하여 Helm 차트를 설치하고 업그레이드합니다. 따라서 Red Hat Advanced Cluster Management 서브스크립션은 시크릿 종속성을 사용하여 Helm 차트를 배포할 수 없습니다.

Argo CD 가져오기 모델을 사용하여 ApplicationSet 애플리케이션을 배포하고 애플리케이션 리소스 이름이 사용자 지정되면 각 클러스터에 따라 리소스 이름이 다르게 표시될 수 있습니다. 이 경우 토폴로지에서 애플리케이션을 올바르게 표시하지 않습니다.

허브 클러스터 애플리케이션 세트는 대상 관리 클러스터에 배포되지만 관리 허브 클러스터인 로컬 클러스터는 대상 관리 클러스터로 제외됩니다.

결과적으로 Argo CD 애플리케이션이 Argo CD 풀 모델을 통해 로컬 클러스터에 전파되면 로컬 클러스터 Argo CD 애플리케이션이 Argo CD ApplicationSet 리소스의 배치 결정에서 제거되더라도 로컬 클러스터 Argo CD 애플리케이션이 정리되지 않습니다.

이 문제를 해결하고 로컬 클러스터 Argo CD 애플리케이션을 정리하려면 로컬 클러스터 Argo CD 애플리케이션에서 skip-reconcile 주석을 제거합니다. 다음 주석을 참조하십시오.

annotations:
    argocd.argoproj.io/skip-reconcile: "true"

annotations:
    argocd.argoproj.io/skip-reconcile: "true"

또한 Argo CD 콘솔의 애플리케이션 섹션에서 가져오기 모델 Argo CD 애플리케이션을 수동으로 새로 고침하면 새로 고침이 처리되지 않으며 Argo CD 콘솔의 REFRESH 버튼이 비활성화됩니다.

이 문제를 해결하려면 Argo CD 애플리케이션에서 새로 고침 주석을 제거합니다. 다음 주석을 참조하십시오.

annotations:
    argocd.argoproj.io/refresh: normal

annotations:
    argocd.argoproj.io/refresh: normal

Argo CD 컨트롤러와 전파 컨트롤러는 모두 동일한 애플리케이션 리소스에서 조정할 수 있으며 관리형 클러스터에서 애플리케이션 배포 인스턴스가 중복되지만 다른 배포 모델에서 발생할 수 있습니다.

가져오기 모델을 사용하여 애플리케이션을 배포하기 위해 Argo CD 컨트롤러는 Argo CD argocd.argoproj.io/skip-reconcile 주석이 ApplicationSet 의 template 섹션에 추가되면 Argo CD 컨트롤러에서 이러한 애플리케이션 리소스를 무시합니다.

argocd.argoproj.io/skip-reconcile 주석은 GitOps Operator 버전 1.9.0 이상에서만 사용할 수 있습니다. 충돌을 방지하려면 허브 클러스터 및 모든 관리 클러스터가 가져오기 모델을 구현하기 전에 GitOps Operator 버전 1.9.0으로 업그레이드할 때까지 기다립니다.

MulticlusterApplicationSetReport 에 나열된 모든 리소스는 실제로 관리 클러스터에 배포됩니다. 리소스를 배포하지 못하면 리소스가 리소스 목록에 포함되지 않지만 원인은 오류 메시지에 나열됩니다.

수백 개의 관리형 클러스터에 배포된 관리 클러스터 및 Argo CD 애플리케이션 세트가 있는 대규모 환경의 경우 허브 클러스터에서 Argo CD 애플리케이션 생성에 몇 분이 걸릴 수 있습니다. 다음 예제 파일에 표시되므로 애플리케이션 세트의 clusterDecisionResource 생성기에서 requeueAfterSeconds 를 0 으로 설정할 수 있습니다.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cm-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: app-placement
      requeueAfterSeconds: 0

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cm-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: app-placement
      requeueAfterSeconds: 0

subscription-admin 역할에 ObjectBucket 채널 유형의 허용 및 거부 목록을 지정할 수 없습니다. 다른 채널 유형에서 서브스크립션의 허용 및 거부 목록은 배포할 수 있는 Kubernetes 리소스와 배포해서는 안 되는 Kubernetes 리소스를 나타냅니다.

관리 클러스터에서 실행 중인 application-manager 애드온은 이전에 klusterlet Operator가 처리한 경우 서브스크립션 운영자가 처리합니다. 서브스크립션 Operator는 multicluster-hub 를 관리하지 않으므로 multicluster-hub 이미지 매니페스트 ConfigMap의 multicluster_operators_subscription 이미지에 대한 변경 사항이 자동으로 적용되지 않습니다.

multicluster-hub 이미지 매니페스트 ConfigMap에서 multicluster_operators_subscription 이미지를 변경하여 서브스크립션 Operator에서 사용하는 이미지를 재정의하는 경우 관리 클러스터의 application-manager 애드온은 서브스크립션 Operator pod가 다시 시작될 때까지 새 이미지를 사용하지 않습니다. Pod를 다시 시작해야 합니다.

policy.open-cluster-management.io/v1 리소스는 Red Hat Advanced Cluster Management 버전 2.4에 기본적으로 애플리케이션 서브스크립션에 의해 배포되지 않습니다.

서브스크립션 관리자는 이 기본 동작을 변경하기 위해 애플리케이션 서브스크립션을 배포해야 합니다.

자세한 내용은 서브스크립션 관리자로서 허용 및 거부 목록 생성 을 참조하십시오. 이전 Red Hat Advanced Cluster Management 버전에서 기존 애플리케이션 서브스크립션에 의해 배포된 policy.open-cluster-management.io/v1 리소스는 서브스크립션 관리자가 애플리케이션 서브스크립션을 배포하지 않는 한 소스 리포지토리와 더 이상 조정되지 않습니다.

Ansible 후크 독립 실행형 모드는 지원되지 않습니다. 서브스크립션과 함께 허브 클러스터에 Ansible 후크를 배포하려면 다음 서브스크립션 YAML을 사용할 수 있습니다.

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

그러나 spec.placement.local:true 에 독립 실행형 모드에서 실행되는 서브스크립션이 있으므로 이 구성은 Ansible 인스턴스를 생성하지 않을 수 있습니다. 허브 모드에서 서브스크립션을 생성해야 합니다.

둘 다 적용하면 hub 클러스터에 생성된 Ansible 인스턴스가 표시됩니다.

배치 규칙을 업데이트한 후 애플리케이션이 배포되지 않은 경우 application-manager 포드가 실행 중인지 확인합니다. application-manager 는 관리 클러스터에서 실행해야 하는 서브스크립션 컨테이너입니다.

oc get pods -n open-cluster-management-agent-addon |grep application-manager 를 실행하여 확인할 수 있습니다.

콘솔에서 kind:pod cluster:yourcluster 를 검색하고 application-manager 가 실행 중인지 확인할 수도 있습니다.

확인할 수 없는 경우 클러스터를 다시 가져오고 다시 확인합니다.

관리형 클러스터에 필요한 추가 구성인 보안 컨텍스트 제약 조건 관리에서 Red Hat OpenShift Container Platform SCC에 대해 알아봅니다.

배포마다 보안 컨텍스트와 서비스 계정이 다릅니다. 서브스크립션 Operator는 SCC CR을 자동으로 생성할 수 없습니다. 관리자는 Pod에 대한 권한을 제어합니다. 상대 서비스 계정에 적절한 권한을 활성화하려면 기본이 아닌 네임스페이스에서 Pod를 생성하려면 SCC(보안 컨텍스트 제약 조건) CR이 필요합니다. 네임스페이스에서 SCC CR을 수동으로 생성하려면 다음 단계를 완료합니다.

동일한 네임스페이스에 두 개 이상의 채널을 생성하면 hub 클러스터에 오류가 발생할 수 있습니다.

예를 들어, 네임스페이스 charts-v1 은 설치 프로그램에서 Helm 유형 채널로 사용하므로 charts-v1 에 추가 채널을 생성하지 마십시오. 고유한 네임스페이스에 채널을 생성해야 합니다. 모든 채널에는 다른 GitHub 채널과 네임스페이스를 공유할 수 있는 GitHub 채널을 제외한 개별 네임스페이스가 필요합니다.

호환되지 않는 옵션을 선택할 때 Ansible 작업이 실행되지 않습니다. Ansible Automation Platform은 -cluster 범위의 채널 옵션이 선택된 경우에만 작동합니다. 이는 Ansible 작업을 수행해야 하는 모든 구성 요소에 영향을 미칩니다.

Red Hat Ansible Automation Platform Operator는 프록시 지원 OpenShift Container Platform 클러스터 외부에서 Ansible Automation Platform에 액세스할 수 없습니다. 해결하려면 프록시에 Ansible Automation Platform을 설치할 수 있습니다. Ansible Automation Platform에서 제공하는 설치 단계를 참조하십시오.

애플리케이션 이름은 37자를 초과할 수 없습니다. 문자가 이 양을 초과하면 애플리케이션 배포에 다음 오류가 표시됩니다.

status:
  phase: PropagationFailed
  reason: 'Deployable.apps.open-cluster-management.io "_long_lengthy_name_" is invalid: metadata.labels: Invalid value: "_long_lengthy_name_": must be no more than 63 characters/n'

status:
  phase: PropagationFailed
  reason: 'Deployable.apps.open-cluster-management.io "_long_lengthy_name_" is invalid: metadata.labels: Invalid value: "_long_lengthy_name_": must be no more than 63 characters/n'

콘솔의 다양한 애플리케이션 테이블에 대한 다음 제한 사항을 참조하십시오.

2.12에 대한 애플리케이션 변경의 콘솔 및 토폴로지 입니다. 콘솔 토폴로지 페이지의 필터링 기능은 없습니다.

오브젝트 스토리지 애플리케이션 서브스크립션에서는 허용 및 거부 목록 기능이 작동하지 않습니다.

Grafana 인스턴스를 실행한 후 Grafana 대시보드를 로드하지 못할 수 있습니다. 다음 단계를 완료합니다.

retentionResolutionRaw,retentionResolution5m 또는 retentionResolution1h 와 같은 모든 해결 수준에 대한 기본 보존은 365 일 (365d)입니다. 이 365d 기본 보존은 1 시간 해상도의 기본 보존이 0d 에서 365d 로 감소했음을 의미합니다. 이러한 변경으로 인해 데이터가 손실될 수 있습니다. MultiClusterObservability spec.advanced.retentionConfig 매개변수에서 해결 보존에 대한 명시적 값을 설정하지 않은 경우 데이터가 손실될 수 있습니다.

자세한 내용은 보존을 위한 고급 구성 추가를 참조하십시오.

복원된 허브 클러스터의 Observatorium API 게이트웨이 Pod에는 Kubernetes 제한으로 인해 백업 후 오래된 테넌트 데이터가 포함될 수 있습니다. 제한에 대한 자세한 내용은 마운트된 ConfigMaps가 자동으로 업데이트 되는 것을 참조하십시오.

결과적으로 Observatorium API 및 Thanos 게이트웨이는 수집기에서 메트릭을 거부하고 Red Hat Advanced Cluster Management Grafana 대시보드는 데이터를 표시하지 않습니다.

Observatorium API 게이트웨이 Pod 로그에서 다음 오류를 참조하십시오.

level=error name=observatorium caller=logchannel.go:129 msg="failed to forward metrics" returncode="500 Internal Server Error" response="no matching hashring to handle tenant\n"

level=error name=observatorium caller=logchannel.go:129 msg="failed to forward metrics" returncode="500 Internal Server Error" response="no matching hashring to handle tenant\n"

Thanos는 다음 오류와 함께 Pod 로그를 수신합니다.

caller=handler.go:551 level=error component=receive component=receive-handler tenant=xxxx err="no matching hashring to handle tenant" msg="internal server error"

caller=handler.go:551 level=error component=receive component=receive-handler tenant=xxxx err="no matching hashring to handle tenant" msg="internal server error"

이 문제를 해결하려면 다음 절차를 참조하십시오.

참고: 기본적으로 N = 2 이지만 일부 사용자 지정 구성 환경에서는 2 보다 클 수 있습니다.

이렇게 하면 올바른 테넌트 정보를 사용하여 모든 Observatorium API 게이트웨이 Pod가 다시 시작되고 수집기의 데이터가 5-10분 내에 Grafana에 표시되기 시작합니다.

Red Hat Advanced Cluster Management 2.9부터는 정의된 Red Hat Advanced Cluster Management Hub 클러스터 네임스페이스에 라벨을 사용해야 합니다. 레이블 openshift.io/cluster-monitoring: "true" 로 인해 Cluster Monitoring Operator가 메트릭의 네임스페이스를 스크랩합니다.

Red Hat Advanced Cluster Management 2.9가 배포되거나 설치가 2.9로 업그레이드되면 Red Hat Advanced Cluster Management Observability ServiceMonitor 및 PrometheusRule 리소스가 더 이상 openshift-monitoring 네임스페이스에 표시되지 않습니다.

observability 애드온의 additional AlertManagerConfig 리소스는 프록시 설정을 지원하지 않습니다. 관찰 기능 경고 전달 기능을 비활성화해야 합니다.

경고 전달을 비활성화하려면 다음 단계를 완료합니다.

자체 서명된 CA 인증서가 있는 HTTPS 프록시는 지원되지 않습니다.

다양한 허브 클러스터에서 동일한 S3 스토리지를 사용하여 Red Hat Advanced Cluster Management 관찰 기능을 배포할 때 Kubernetes/Service -Level Overview/API Server 대시보드 내에서 중복 로컬 클러스터를 감지하고 표시할 수 있습니다. 중복 클러스터는 다음 패널의 결과에 영향을 미칩니다. 상위 클러스터,SLO를 초과한 클러스터 수, SLO를 충족하는 클러스터 수 local-cluster는 공유 S3 스토리지와 연결된 고유한 클러스터입니다. 여러 로컬 클러스터 가 대시보드 내에 표시되지 않도록 하려면 각 고유한 허브 클러스터가 허브 클러스터에 특별히 S3 버킷을 사용하여 관찰 기능을 배포하는 것이 좋습니다.

MultiClusterObservability CustomResource(CR)에 배포할 풀 시크릿을 생성하고 open-cluster-management-observability 네임스페이스에 pull-secret이 없는 경우 observability 엔드포인트 Operator가 실패합니다. 새 클러스터를 가져오거나 Red Hat Advanced Cluster Management를 사용하여 생성된 Hive 클러스터를 가져오는 경우 관리 클러스터에서 풀 이미지 시크릿을 수동으로 생성해야 합니다.

자세한 내용은 관찰 기능 활성화를 참조하십시오.

Red Hat Advanced Cluster Management observability는 기본 제공 대시보드 내의 일부 패널에 있는 ROKS 클러스터의 데이터를 표시하지 않습니다. 이는 ROKS가 관리하는 서버에서 API 서버 메트릭을 노출하지 않기 때문입니다. 다음 Grafana 대시보드에는 ROKS 클러스터를 지원하지 않는 패널이 포함되어 있습니다. Kubernetes/API 서버,Kubernetes/Compute Resources/Workload,Kubernetes/Compute Resources/Namespace(Workload)

ROKS 클러스터의 경우 Red Hat Advanced Cluster Management observability는 대시보드의 etcd 패널에 데이터를 표시하지 않습니다.

기본적으로 OpenShift의 Prometheus는 임시 스토리지를 사용합니다. Prometheus는 재시작할 때마다 모든 메트릭 데이터를 손실됩니다.

Red Hat Advanced Cluster Management에서 관리하는 OpenShift Container Platform 관리 클러스터에서 관찰 기능이 활성화되거나 비활성화되면 observability 엔드포인트 Operator는 로컬 Prometheus를 자동으로 재시작하는 alertmanager 구성을 추가하여 cluster-monitoring-config ConfigMap 을 업데이트합니다.

관찰 기능 수신 Pod는 다음 오류 메시지를 보고합니다.

Error on ingesting out-of-order samples

Error on ingesting out-of-order samples

오류 메시지는 메트릭 컬렉션 간격 동안 관리 클러스터에서 전송한 시계열 데이터가 이전 컬렉션 간격으로 전송된 시계열 데이터보다 오래됨을 의미합니다. 이 문제가 발생하면 Thanos 수신자에 의해 데이터가 삭제되므로 Grafana 대시보드에 표시된 데이터에 차이가 발생할 수 있습니다. 오류가 자주 표시되는 경우 메트릭 컬렉션 간격을 더 높은 값으로 늘리는 것이 좋습니다. 예를 들어 간격을 60 초로 늘릴 수 있습니다.

문제는 시계열 간격이 30초와 같은 더 낮은 값으로 설정된 경우에만 발견됩니다. 이 문제는 메트릭 컬렉션 간격이 기본값인 300초로 설정된 경우 표시되지 않습니다.

이전 버전의 2.6에서 배포한 grafana-dev 인스턴스가 있고 환경을 2.6로 업그레이드하는 경우 grafana-dev 가 작동하지 않습니다. 다음 명령을 실행하여 기존 grafana-dev 인스턴스를 삭제해야 합니다.

./setup-grafana-dev.sh --clean

./setup-grafana-dev.sh --clean

다음 명령을 사용하여 인스턴스를 다시 생성합니다.

./setup-grafana-dev.sh --deploy

./setup-grafana-dev.sh --deploy

메모리 제한에 도달하여 klusterlet-addon-search Pod가 실패합니다. 관리 클러스터에서 klusterlet-addon-search 배포를 사용자 정의하여 메모리 요청 및 제한을 업데이트해야 합니다. hub 클러스터에서 search-collector 라는 ManagedclusterAddon 사용자 정의 리소스를 편집합니다. search-collector 에 다음 주석을 추가하고 addon.open-cluster-management.io/search_memory_request=512Mi 및 addon.open-cluster-management.io/search_memory_limit=1024Mi 를 업데이트합니다.

예를 들어 foobar 라는 관리 클러스터가 있는 경우 다음 명령을 실행하여 메모리 요청을 512Mi 로 변경하고 메모리 제한을 1024Mi 로 변경합니다.

oc annotate managedclusteraddon search-collector -n foobar \
addon.open-cluster-management.io/search_memory_request=512Mi \
addon.open-cluster-management.io/search_memory_limit=1024Mi

oc annotate managedclusteraddon search-collector -n foobar \
addon.open-cluster-management.io/search_memory_request=512Mi \
addon.open-cluster-management.io/search_memory_limit=1024Mi

mulitclusterengine 사용자 정의 리소스에서 disableHubSelfManagement 매개변수가 true 로 설정된 경우 Grafana 대시보드에 빈 레이블 목록이 표시됩니다. 레이블 목록을 보려면 매개변수를 false 로 설정하거나 매개변수를 제거해야 합니다. 자세한 내용은 disableHubSelfManagement 를 참조하십시오.

Endpoint url cannot have fully qualified paths

Endpoint url cannot have fully qualified paths

endpoint: example.com:443

endpoint: example.com:443

addonDeploymentConfig 를 사용하여 구성한 관리 클러스터의 프록시 구성은 메트릭 수집기에서 탐지되지 않습니다. 이 문제를 해결하려면 관리 클러스터 ManifestWork 를 제거하여 프록시를 활성화할 수 있습니다. ManifestWork 를 제거하면 addonDeploymentConfig 의 변경 사항을 적용해야 합니다.

사용자 정의 Observatorium API 및 Alertmanager URL은 TLS 패스스루가 있는 중간 구성 요소만 지원합니다. 두 사용자 정의 URL이 동일한 중간 구성 요소를 가리키는 경우 OpenShift Container Platform 라우터가 동일한 호스트의 두 개의 개별 경로 오브젝트를 지원하지 않기 때문에 별도의 하위 도메인을 사용해야 합니다.

complianceType 매개변수에 대해 mustnothave 를 사용하여 구성된 구성 정책이 있고 remediationAction 매개변수에 대한 적용이 Kubernetes API에 대한 삭제 요청이 수행될 때 정책을 준수하도록 나열됩니다. 따라서 정책이 준수로 나열되는 동안 Kubernetes 오브젝트는 Terminating 상태로 고정될 수 있습니다.

ARM 환경에 설치할 수 있지만 정책과 함께 배포된 Operator는 ARM 환경을 지원하지 않을 수 있습니다. Operator를 설치하는 다음 정책은 ARM 환경을 지원하지 않습니다.

KlusterletAddonConfig 에서 정책 컨트롤러를 비활성화하거나 클러스터를 분리하여 관리 클러스터에서 config-policy-controller 애드온을 제거하면 ConfigurationPolicy 사용자 정의 리소스 정의가 종료 상태가 될 수 있습니다. ConfigurationPolicy 사용자 정의 리소스 정의가 종료 상태에 있는 경우 나중에 애드온을 다시 설치하는 경우 새 정책이 클러스터에 추가되지 않을 수 있습니다. 다음과 같은 오류도 표시될 수 있습니다.

template-error; Failed to create policy template: create not allowed while custom resource definition is terminating

template-error; Failed to create policy template: create not allowed while custom resource definition is terminating

다음 명령을 사용하여 사용자 정의 리소스 정의가 고정되었는지 확인합니다.

oc get crd configurationpolicies.policy.open-cluster-management.io -o=jsonpath='{.metadata.deletionTimestamp}'

oc get crd configurationpolicies.policy.open-cluster-management.io -o=jsonpath='{.metadata.deletionTimestamp}'

삭제 타임스탬프가 리소스에 있으면 사용자 정의 리소스 정의가 고정됩니다. 이 문제를 해결하려면 클러스터에 남아 있는 구성 정책에서 모든 종료자를 제거합니다. 관리 클러스터에서 다음 명령을 사용하고 < cluster-namespace >를 관리 클러스터 네임스페이스로 바꿉니다.

oc get configurationpolicy -n <cluster-namespace> -o name | xargs oc patch -n <cluster-namespace> --type=merge -p '{"metadata":{"finalizers": []}}'

oc get configurationpolicy -n <cluster-namespace> -o name | xargs oc patch -n <cluster-namespace> --type=merge -p '{"metadata":{"finalizers": []}}'

구성 정책 리소스는 클러스터에서 자동으로 제거되고 사용자 정의 리소스 정의는 종료 상태를 종료합니다. 애드온을 이미 다시 설치한 경우 삭제 타임스탬프 없이 사용자 정의 리소스 정의가 자동으로 다시 생성됩니다.

정책이 remediationAction: enforce and is repeatedly updated로 설정된 경우 Red Hat Advanced Cluster Management 콘솔에는 성공적인 업데이트로 인해 반복된 위반이 표시됩니다. 반복된 업데이트로 여러 정책 이벤트가 생성되어 governance-policy-framework-addon Pod가 메모리가 부족하고 충돌이 발생할 수 있습니다. 오류에 대한 다음 두 가지 원인 및 해결 방법을 참조하십시오.

동일한 정책 템플릿 이름으로 정책을 생성하면 탐지되지 않은 결과가 표시되지만 원인을 모를 수 있습니다. 예를 들어 create-pod 라는 여러 구성 정책으로 정책을 정의하면 일관되지 않은 결과가 발생합니다. 모범 사례: 정책 템플릿에 중복 이름을 사용하지 마십시오.

데이터베이스 및 정책 준수 기록 API 중단에 대한 복원력이 기본 제공되어 있지만 관리 클러스터에서 기록할 수 없는 규정 준수 이벤트는 성공적으로 기록될 때까지 메모리에 대기열에 추가됩니다. 즉, 관리 클러스터의 중단 및 governance-policy-framework Pod가 다시 시작되면 대기 중인 모든 규정 준수 이벤트가 손실됩니다.

데이터베이스 중단 중에 새 정책을 생성하거나 업데이트하는 경우 데이터베이스 ID에 대한 정책 매핑은 업데이트할 수 없으므로 이 새 정책에 대해 전송된 규정 준수 이벤트를 기록할 수 없습니다. 데이터베이스가 다시 온라인 상태가 되면 매핑이 자동으로 업데이트되고 해당 정책에서 향후 규정 준수 이벤트가 기록됩니다.

최신 데이터 없이 백업 복원과 같은 PostgreSQL 서버에 데이터가 손실되는 경우, Red Hat Advanced Cluster Management Hub 클러스터에서 거버넌스 정책 전파를 다시 시작하여 정책의 매핑을 데이터베이스 ID로 업데이트해야 합니다. 거버넌스 정책 전파를 다시 시작할 때까지 데이터베이스에 존재한 정책과 관련된 새로운 규정 준수 이벤트가 더 이상 기록되지 않습니다.

거버넌스 정책 전파기를 다시 시작하려면 Red Hat Advanced Cluster Management Hub 클러스터에서 다음 명령을 실행합니다.

oc -n open-cluster-management rollout restart deployment/grc-policy-propagator

oc -n open-cluster-management rollout restart deployment/grc-policy-propagator

Kyverno 정책은 Red Hat Advanced Cluster Management 클러스터에서 다음 메시지를 보고합니다.

violation - couldn't find mapping resource with kind ClusterPolicyReport, please check if you have CRD deployed;
violation - couldn't find mapping resource with kind PolicyReport, please check if you have CRD deployed

violation - couldn't find mapping resource with kind ClusterPolicyReport, please check if you have CRD deployed;
violation - couldn't find mapping resource with kind PolicyReport, please check if you have CRD deployed

원인은 PolicyReport API 버전이 생성기에서 잘못되어 Kyverno가 배포된 것과 일치하지 않기 때문입니다.

네트워킹 기능을 사용하는 동안 발생할 수 있는 다음과 같은 알려진 문제 및 제한 사항을 참조하십시오.

graceful termination failed, controllers failed with error: the server could not find the requested resource (post clustermanagementaddons.addon.open-cluster-management.io)

graceful termination failed, controllers failed with error: the server could not find the requested resource (post clustermanagementaddons.addon.open-cluster-management.io)

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   insecureBrokerConnection: true

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   insecureBrokerConnection: true

호스팅 모드에서 관리 허브 클러스터를 가져오고 이 관리 허브 클러스터를 분리하면 open-cluster-management-agent-addon 네임스페이스를 삭제하고 다시 생성합니다. 분리된 허브 클러스터는 이 네임스페이스 내의 모든 관련 애드온 리소스도 삭제하고 다시 생성합니다.

현재 이 문제에 대한 해결방법이 없습니다.

FIPS(Federal Information Processing Standard) 환경에서 Kafka Operator는 OOM(메모리 부족) 상태로 인해 다시 시작됩니다. 이 문제를 해결하려면 리소스 제한을 512M 이상으로 설정합니다. 이 제한을 설정하는 방법에 대한 자세한 단계는 amq stream doc 를 참조하십시오.

원래 다중 클러스터 글로벌 허브 클러스터가 충돌하면 다중 클러스터 글로벌 허브가 생성된 이벤트 및 cron 작업이 손실됩니다. 새 다중 클러스터 글로벌 허브 클러스터를 복원하더라도 이벤트 및 cron 작업이 복원되지 않습니다. 이 문제를 해결하려면 cron 작업을 수동으로 실행할 수 있습니다. https://docs.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.9/html/multicluster_global_hub/multicluster-global-hub#global-hub-compliance-manual

성공적으로 생성되지 않은 관리 클러스터입니다. 즉 clusterclaim id.k8s.io 는 관리 클러스터에 존재하지 않으며 정책 준수 대시보드에 포함되지 않지만 정책 콘솔에 표시됩니다.

다중 클러스터 글로벌 허브 Operator가 OpenShift Container Platform 4.13에 설치된 경우 관리 클러스터 목록에 연결되는 모든 하이퍼링크와 대시보드의 세부 페이지가 Red Hat Advanced Cluster Management 홈페이지로 리디렉션될 수 있습니다.

대상 페이지로 수동으로 이동해야 합니다.

Global Hub Policy Group Compliancy Overview Hub Dashboard에서 View Offending Policies for standard group 을 클릭하여 하나의 데이터 포인트를 확인할 수 있지만 이 링크를 클릭하면 표준 그룹 필터가 새 페이지로 이동할 수 없습니다.

이는 클러스터 그룹 호환 개요에도 문제가 있습니다.