문제 해결

must-gather 명령을 사용하려면 다음 절차를 참조하십시오.

연결이 끊긴 환경에서 must-gather 명령을 실행하려면 다음 단계를 완료합니다.

현재 지원되는 릴리스 중 하나 또는 제품 문서에 문제가 발생하는 경우 Red Hat 지원팀으로 이동하여 추가 문제를 해결하거나 기술 자료 문서를 보거나 지원 팀과 연결하거나 케이스를 열 수 있습니다. Red Hat 인증 정보를 사용하여 로그인해야 합니다.

호스팅된 컨트롤 플레인 클러스터에 문제가 발생하는 경우 must-gather 명령을 실행하여 문제 해결에 도움이 되는 정보를 수집할 수 있습니다.

MultiClusterHub를 설치한 후 10 분 이상 전달되었으며 MultiClusterHub 리소스의 status.components 필드에서 하나 이상의 구성 요소가 ProgressDeadlineExceeded. 클러스터의 리소스 제약 조건이 문제가 될 수 있습니다.

Multiclusterhub 가 설치된 네임스페이스에서 Pod를 확인합니다. 다음과 유사한 상태로 보류 중이 표시될 수 있습니다.

reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
        }, that the pod didn't tolerate.'

이 경우 제품을 실행하기 위해 작업자 노드 리소스가 클러스터에 충분하지 않습니다.

이 문제가 있는 경우 더 큰 작업자 노드로 클러스터를 업데이트해야 합니다. 클러스터 크기 지정에 대한 지침은 클러스터 크기 조정을 참조하십시오.

ManagedClusterSet 및 ManagedClusterSetBinding 사용자 정의 리소스 정의를 나열하려는 후 다음 오류 메시지가 표시됩니다.

Error from server: request to convert CR from an invalid group/version: cluster.open-cluster-management.io/v1beta1

이전 메시지는 ManagedClusterSets 및 ManagedClusterSetBindings 사용자 정의 리소스 정의 v1beta1 에서 v1beta2 로의 사용자 정의 리소스 정의가 실패했음을 나타냅니다.

이 오류를 해결하려면 API 마이그레이션을 수동으로 시작해야 합니다. 다음 단계를 완료합니다.

oc get managedclusterset
oc get managedclustersetbinding -A

클러스터 생성 절차를 완료한 후에는 Red Hat Advanced Cluster Management 콘솔에서 액세스할 수 없으며 오프라인 상태가 표시됩니다.

클러스터 가져오기 절차를 완료한 후에는 Kubernetes 콘솔용 Red Hat Advanced Cluster Management에서 액세스할 수 없습니다.

가져오기를 시도한 후에는 가져온 클러스터를 사용할 수 없는 몇 가지 이유가 있을 수 있습니다. 클러스터 가져오기에 실패하면 가져오기에 실패한 이유를 찾을 때까지 다음 단계를 완료합니다.

Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 가져온 후 클러스터에 Pending import 상태로 콘솔에 표시됩니다.

OpenShift Container Platform 클러스터를 Red Hat Advanced Cluster Management MultiClusterHub 로 가져올 때 오류 로그가 표시됩니다.

error log:
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
Error from server (AlreadyExists): error when creating "STDIN": customresourcedefinitions.apiextensions.k8s.io "klusterlets.operator.open-cluster-management.io" already exists
The cluster cannot be imported because its Klusterlet CRD already exists.
Either the cluster was already imported, or it was not detached completely during a previous detach process.
Detach the existing cluster before trying the import again."

다음 명령을 실행하여 새 Red Hat Advanced Cluster Management MultiClusterHub 로 가져올 Red Hat Advanced Cluster Management 관련 리소스가 있는지 확인합니다.

oc get all -n open-cluster-management-agent
oc get all -n open-cluster-management-agent-addon

다음 명령을 사용하여 klusterlet 사용자 정의 리소스를 제거합니다.

oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'

다음 명령을 실행하여 기존 리소스를 제거합니다.

oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'

자체 서명된 인증서를 사용하여 Red Hat OpenStack Platform에서 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 알 수 없는 권한 오류를 나타내는 오류 메시지와 함께 클러스터가 실패합니다.

관리 클러스터의 배포가 실패하고 다음 오류 메시지를 반환합니다.

x509: 알 수 없는 기관에서 서명한 인증서

다음 파일이 올바르게 구성되었는지 확인합니다.

인증서 보안 업데이트 절차를 완료한 후 온라인 클러스터 중 하나 이상에 이제 콘솔에 오프라인 상태가 표시됩니다.

사용자 정의 API 서버 인증서에 대한 정보를 업데이트한 후 새 인증서가 이제 오프라인 상태가 되기 전에 가져온 클러스터입니다.

인증서가 문제가 있음을 나타내는 오류는 오프라인 관리 클러스터의 open-cluster-management-agent 네임스페이스에 있는 Pod 로그에서 확인할 수 있습니다. 다음 예제는 로그에 표시되는 오류와 유사합니다.

다음 work-agent 로그를 참조하십시오.

E0917 03:04:05.874759       1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887       1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority

다음 registration-agent 로그를 참조하십시오.

I0917 02:27:41.525026       1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority

관리 클러스터가 로컬 클러스터 이거나 Red Hat Advanced Cluster Management for Kubernetes를 사용하여 관리되는 클러스터를 생성한 경우 관리 클러스터를 다시 가져오는 데 10분 이상 기다려야 합니다.

관리 클러스터를 즉시 다시 가져오려면 hub 클러스터에서 관리 클러스터 가져오기 보안을 삭제하고 Red Hat Advanced Cluster Management를 사용하여 다시 가져올 수 있습니다. 다음 명령을 실행합니다.

oc delete secret -n <cluster_name> <cluster_name>-import

& lt;cluster_name >을 가져올 관리 클러스터의 이름으로 바꿉니다.

Red Hat Advanced Cluster Management를 사용하여 가져온 관리형 클러스터를 다시 가져오려면 다음 단계를 완료하여 관리 클러스터를 다시 가져옵니다.

참고: 이전 단계에서는 hub 클러스터에서 관리 클러스터를 분리하지 않습니다. 이 단계에서는 새 인증서 정보를 포함하여 관리 클러스터의 현재 설정으로 필요한 매니페스트를 업데이트합니다.

관리 클러스터를 제거한 후 네임스페이스는 제거되지 않습니다.

네임스페이스를 수동으로 제거하려면 다음 단계를 완료합니다.

관리를 위해 하이브 클러스터를 가져올 때 자동 가져오기 보안 오류가 이미 표시됩니다.

이 문제는 Red Hat Advanced Cluster Management에서 이전에 관리하는 클러스터를 가져오려고 할 때 발생합니다. 이 경우 클러스터를 다시 가져오려고 할 때 보안이 충돌합니다.

이 문제를 해결하려면 다음 단계를 완료하십시오.

스냅샷을 사용하도록 EgressSync ReplicationSource 또는 ReplicationDestination 을 구성할 수 있습니다. 또한 ReplicationSource 및 ReplicationDestination 에서 storageclass 및 volumesnapshotclass 를 구성할 수 있습니다. 값이 false 인 force-create 라는 cinder volumesnapshotclass 에 매개 변수가 있습니다. volumesnapshotclass 의 이 force-create 매개변수는 cinder가 volumesnapshot 을 사용 중인 PVC를 사용하도록 허용하지 않음을 의미합니다. 결과적으로 volumesnapshot 이 오류 상태입니다.

다중 클러스터 글로벌 허브에 다양한 오류가 발생할 수 있습니다. must-gather 명령을 실행하여 다중 클러스터 글로벌 허브와 관련된 문제를 해결할 수 있습니다.

must-gather 명령을 실행하여 세부 정보, 로그 및 디버깅 문제 단계를 수집합니다. 이 디버깅 정보는 지원 요청을 열 때 유용합니다. oc adm must-gather CLI 명령은 다음을 포함하여 문제를 디버깅하는 데 종종 필요한 정보를 클러스터에서 수집합니다.

다중 클러스터 글로벌 허브에 다양한 오류가 발생할 수 있습니다. 프로비저닝된 PostgreSQL 데이터베이스에 액세스하여 다중 클러스터 글로벌 허브 문제 해결에 도움이 될 수 있는 메시지를 볼 수 있습니다.

There are two ways to access the provisioned PostgreSQL database.

다중 클러스터 글로벌 허브에 다양한 오류가 발생할 수 있습니다. 다중 클러스터 글로벌 허브의 문제 해결에 데이터베이스 덤프 및 복원을 사용할 수 있습니다.

multicluster 글로벌 허브 데이터베이스의 출력을 덤프하여 문제를 디버깅하는 경우가 있습니다. PostgreSQL 데이터베이스는 데이터베이스 콘텐츠를 덤프하는 pg_dump 명령줄 툴을 제공합니다. localhost 데이터베이스 서버에서 데이터를 덤프하려면 다음 명령을 실행합니다.

pg_dump hoh > hoh.sql

압축 형식이 있는 원격 서버에 있는 다중 클러스터 글로벌 허브 데이터베이스를 덤프하려면 다음 예와 같이 명령줄 옵션을 사용하여 연결 세부 정보를 제어합니다.

pg_dump -h my.host.com -p 5432 -U postgres -F t hoh -f hoh-$(date +%d-%m-%y_%H-%M).tar

PostgreSQL 데이터베이스를 복원하려면 psql 또는 pg_restore 명령줄 툴을 사용할 수 있습니다. psql 툴은 pg_dump 로 생성된 일반 텍스트 파일을 복원하는 데 사용됩니다.

psql -h another.host.com -p 5432 -U postgres -d hoh < hoh.sql

pg_restore 툴은 pg_dump 가 아닌 텍스트 형식(custom, tar 또는 directory) 중 하나로 생성된 아카이브에서 PostgreSQL 데이터베이스를 복원하는 데 사용됩니다.

pg_restore -h another.host.com -p 5432 -U postgres -d hoh hoh-$(date +%d-%m-%y_%H-%M).tar

관리 클러스터를 허브 클러스터에 연결하는 네트워크가 불안정한 경우 허브 클러스터 사이클에 의해 오프라인 과 사용 가능 으로 보고되는 관리 클러스터의 상태가 불안정합니다.

허브 클러스터와 관리형 클러스터 간의 연결은 leaseDurationSeconds 간격 값에 유효한 리스를 통해 유지 관리됩니다. leaseDurationSeconds 값의 5번 연속 시도 내에서 리스를 검증하지 않으면 클러스터가 오프라인으로 표시됩니다.

예를 들어, 리스DurationSeconds 간격이 60초 인 5분 후에 클러스터가 오프라인 상태로 표시됩니다. 이 구성은 연결 문제 또는 대기 시간과 같은 이유로 부적절하여 불안정성을 유발할 수 있습니다.

5개의 검증 시도는 기본값이며 변경할 수 없지만 leaseDurationSeconds 간격을 변경할 수 있습니다.

클러스터를 오프라인으로 표시할 시간(분)을 확인한 다음 해당 값을 60으로 곱하여 초로 변환합니다. 그런 다음 기본 5개의 시도로 나눕니다. 그 결과 리스DurationSeconds 값이 됩니다.

Red Hat Advanced Cluster Management for Kubernetes 콘솔을 사용하여 새 클러스터를 생성한 후 클러스터는 Pending 상태를 초과하지 않거나 Failed 상태를 표시합니다.

클러스터에 Failed 상태가 표시되면 클러스터의 세부 정보 페이지로 이동하여 제공된 로그 링크를 따릅니다. 로그를 찾을 수 없거나 클러스터에 Pending 상태가 표시되면 다음 절차를 계속 실행하여 로그를 확인합니다.

로그에서 오류를 확인한 후 클러스터를 제거하고 다시 생성하기 전에 오류를 해결하는 방법을 확인합니다.

다음 예제에서는 지원되지 않는 영역을 선택할 때 발생할 수 있는 로그 오류와 이를 해결하는 데 필요한 작업을 제공합니다.

No subnets provided for zones

클러스터를 생성할 때 지원되지 않는 리전 내에서 하나 이상의 영역을 선택했습니다. 클러스터를 재생성하여 문제를 해결할 때 다음 작업 중 하나를 완료합니다.

로그에서 문제를 확인한 후 클러스터를 제거하고 다시 생성합니다.

클러스터 생성에 대한 자세한 내용은 클러스터 생성 을 참조하십시오.

Grafana explorer에서 시간이 많이 걸리는 메트릭을 쿼리할 때 게이트웨이 시간 제한 오류가 발생하면 open-cluster-management-observability 네임스페이스의 Grafana로 인해 시간 초과가 발생할 수 있습니다.

이 문제가 있는 경우 다음 단계를 완료합니다.

Grafana 페이지를 새로 고치고 메트릭을 다시 쿼리합니다. 게이트웨이 시간 제한 오류가 더 이상 표시되지 않습니다.

모든 관리 클러스터는 배치 규칙으로 선택되지만 local-cluster 는 그렇지 않습니다. 배치 규칙 사용자에게는 local-cluster 네임스페이스에서 관리 클러스터 리소스를 가져올 수 있는 권한이 부여되지 않습니다.

더 이상 사용되지 않음: PlacementRule

이 문제를 해결하려면 local-cluster 네임스페이스에서 managedcluster 관리 권한을 부여해야 합니다. 다음 단계를 완료합니다.

Subscription YAML 파일에서 하나 이상의 애플리케이션 리소스가 더 이상 사용되지 않는 API를 사용하는 경우 다음 오류와 유사한 오류가 표시될 수 있습니다.

failed to install release: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for
kind "Deployment" in version "extensions/v1beta1"

또는 인스턴스의 경우 이름이 old.yaml 인 YAML 파일의 새 Kubernetes API 버전이 있으면 다음과 같은 오류가 발생할 수 있습니다.

error: unable to recognize "old.yaml": no matches for kind "Deployment" in version "deployment/v1beta1"

관리 클러스터에 Klusterlet을 배포한 후 KlusterletRegistrationDegraded 또는 KlusterletWorkDegraded 상태가 True 로 표시됩니다.

다음 성능 저하 상태의 목록과 이러한 문제를 해결하는 방법을 참조하십시오.

오브젝트 스토리지 채널의 서브스크립션은 업데이트된 보안을 자동으로 선택할 수 없습니다. 이렇게 하면 서브스크립션 Operator가 오브젝트 스토리지에서 관리 클러스터로 리소스를 조정하지 못하도록 합니다.

시크릿을 생성하기 위해 인증 정보를 수동으로 입력한 다음 채널 내의 시크릿을 참조해야 합니다.

명령을 실행한 후 애플리케이션 콘솔로 이동하여 리소스가 관리되는 클러스터에 배포되었는지 확인할 수 있습니다. 또는 관리 클러스터에 로그인하여 애플리케이션 리소스가 지정된 네임스페이스에서 생성되었는지 확인할 수 있습니다.

설치 후 Observability CRD(사용자 정의 리소스 정의)를 생성한 후 observability 상태가 Installing 상태에 있는 경우 spec:storageConfig:storageClass 매개변수에 대해 정의된 값이 없을 수 있습니다. 또는 관찰 기능 구성 요소에서 기본 storageClass 를 자동으로 찾지만 스토리지 값이 없는 경우 구성 요소는 Installing 상태로 유지됩니다.

이 문제가 있는 경우 다음 단계를 완료합니다.

storageclass.kubernetes.io/is-default-class: "true"

설치가 완료되면 관찰 기능 구성 요소 상태가 Ready 상태로 업데이트됩니다. 설치가 실패하면 Fail 상태가 표시됩니다.

endpoint-observability-operator-x Pod는 openshift-monitoring 네임스페이스에서 prometheus-k8s 서비스를 사용할 수 있는지 확인합니다. 서비스가 openshift-monitoring 네임스페이스에 없으면 metrics-collector 가 배포되지 않습니다. 다음과 같은 오류 메시지가 표시될 수 있습니다. prometheus 리소스를 가져오지 못했습니다.

이 문제가 있는 경우 다음 단계를 완료합니다.

메트릭을 사용할 수 없는 관리형 클러스터가 있을 수 있습니다. 이 경우 metrics-collector 배포에서 다음 오류가 발생할 수 있습니다.

error: response status code is 500 Internal Server Error, response body is x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "observability-client-ca-certificate")

이 문제가 있는 경우 다음 단계를 완료합니다.

metrics-collector 배포가 다시 생성되고 observability-controller-open-cluster-management.io-observability-signer-client-cert 시크릿이 업데이트됩니다.

검색-api 로그에 다음과 같은 오류 메시지가 표시됩니다. ERROR: could not resize shared memory segment "/PostgreSQL.1083654800" to 25031264 bytes: No space left on device (SQLSTATE 53100)

문제를 해결하려면 search-postgres ConfigMap에 있는 PostgreSQL 리소스를 업데이트합니다. 리소스를 업데이트하려면 다음 단계를 완료합니다.

환경 변수 추가에 대한 자세한 내용은 사용자 지정 및 구성 검색을 참조하십시오.

Kubernetes용 Red Hat Advanced Cluster Management를 업그레이드한 후 oc logs observability-thanos-compact-0 명령을 사용하여 Thanos compactor의 로그를 확인한 후 로그에 다음 오류 메시지가 표시됩니다.

ts=2024-01-24T15:34:51.948653839Z caller=compact.go:491 level=error msg="critical error detected; halting" err="compaction: group 0@15699422364132557315: compact blocks [/var/thanos/compact/compact/0@15699422364132557315/01HKZGQGJCKQWF3XMA8EXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HKZQK7TD06J2XWGR5EXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HKZYEZ2DVDQXF1STVEXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HM05APAHXBQSNC0N5EXAMPLE]: populate block: chunk iter: cannot populate chunk 8 from block 01HKZYEZ2DVDQXF1STVEXAMPLE: segment index 0 out of range"

오브젝트 스토리지 구성에 thanos bucket verify 명령을 추가합니다. 다음 단계를 완료합니다.

설치 후 하위 네트워크가 통신하지 않습니다.

Submariner 배포 후 네트워크 연결이 설정되지 않은 경우 문제 해결 단계를 시작합니다. Submariner를 배포할 때 프로세스가 완료될 때까지 몇 분이 걸릴 수 있습니다.

배포 후 Submariner가 올바르게 실행되지 않으면 다음 단계를 완료합니다.

엔드 투 엔드 데이터 플레인 테스트에 실패하면 Submariner 테스트에서 커넥터 Pod가 리스너 Pod에 연결할 수 있지만 나중에 커넥터 Pod가 수신 대기 단계에서 중단되는 것을 보여줍니다.

MTU(최대 전송 단위)는 엔드 투 엔드 데이터 플레인 테스트 실패를 유발할 수 있습니다. 예를 들어 MTU로 인해 IPsec(Internet Protocol Security)을 통한 클러스터 간 트래픽이 실패할 수 있습니다. 작은 패킷 크기를 사용하는 엔드 투 엔드 데이터 플레인 테스트를 실행하여 MTU가 실패했는지 확인합니다.

이 유형의 테스트를 실행하려면 Submariner 작업 영역에서 다음 명령을 실행합니다.

subctl verify --verbose --only connectivity --context <from_context> --tocontext <to_context> --image-override submariner-nettest=quay.io/submariner/nettest:devel --packet-size 200

테스트에 이 작은 패킷 크기로 성공하면 TCP(전송 제어 프로토콜) 최대 세그먼트 크기(MSS)를 설정하여 연결 문제를 해결할 수 있습니다. 다음 단계를 완료하여 TCP MSS를 설정합니다.

컨테이너 네트워크 인터페이스(CNI)가 OpenShiftSDN인 경우 엔드 투 엔드 데이터 플레인 테스트가 없거나 클러스터 간 터널에 가상 확장 가능한 로컬 영역 네트워크(VXLAN)가 사용되는 경우 베어 메탈 클러스터에 실패할 수 있습니다.

하드웨어에서 UDP(User Datagram Protocal) 체크섬 계산의 버그는 베어 메탈 클러스터의 엔드 투 엔드 데이터 플레인 테스트 실패의 근본 원인이 될 수 있습니다. 이 버그 문제를 해결하려면 다음 YAML 파일을 적용하여 하드웨어 오프로드를 비활성화합니다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: disable-offload
  namespace: submariner-operator
spec:
  selector:
    matchLabels:
      app: disable-offload
  template:
    metadata:
      labels:
        app: disable-offload
    spec:
      tolerations:
      - operator: Exists
      containers:
        - name: disable-offload
          image: nicolaka/netshoot
          imagePullPolicy: IfNotPresent
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              add:
              - net_admin
              drop:
              - all
            privileged: true
            readOnlyRootFilesystem: false
            runAsNonRoot: false
          command: ["/bin/sh", "-c"]
          args:
            - ethtool --offload vxlan-tunnel rx off tx off;
              ethtool --offload vx-submariner rx off tx off;
sleep infinity
      restartPolicy: Always
      securityContext: {}
      serviceAccount: submariner-routeagent
      serviceAccountName: submariner-routeagent
      hostNetwork: true

Red Hat Advanced Cluster Management에는 FinishedWithErrors 상태가 표시되고 Red Hat Advanced Cluster Management 복원에서 생성한 하나 이상의 Velero 복원 리소스에는 PartiallyFailed 상태가 표시됩니다.

비어 있는 백업에서 복원하는 경우 FinishedWithErrors 상태를 무시해도 됩니다.

Kubernetes 복원용 Red Hat Advanced Cluster Management에는 모든 Velero 복원 리소스의 누적 상태가 표시됩니다. 하나의 상태가 PartiallyFailed 이고 다른 하나는 Completed 인 경우 표시되는 누적 상태는 하나 이상의 문제가 있음을 알리는 PartiallyFailed 입니다.

이 문제를 해결하려면 PartiallyFailed 상태로 모든 개별 Velero 복원 리소스의 상태를 확인하고 자세한 내용은 로그를 확인합니다. 오브젝트 스토리지에서 직접 로그를 가져오거나 DownloadRequest 사용자 정의 리소스를 사용하여 OADP Operator에서 로그를 다운로드할 수 있습니다.

콘솔에서 DownloadRequest 를 생성하려면 다음 단계를 완료합니다.

관리 클러스터 및 허브 클러스터가 동일한 클러스터인 경우 인증서 데이터가 수정되므로 내용이 템플릿 JSON 문자열로 구문 분석되지 않습니다. 다음과 같은 오류 메시지가 표시될 수 있습니다.

message: >-
            [spec.tls.caCertificate: Invalid value: "redacted ca certificate
            data": failed to parse CA certificate: data does not contain any
            valid RSA or ECDSA certificates, spec.tls.certificate: Invalid
            value: "redacted certificate data": data does not contain any valid
            RSA or ECDSA certificates, spec.tls.key: Invalid value: "": no key specified]

hub 클러스터 및 관리 클러스터 fromSecret 값을 검색하도록 인증서 정책을 구성합니다. autoindent 함수를 사용하여 다음 콘텐츠로 인증서 정책을 업데이트합니다.

                 tls:
                    certificate: |
                      {{ print "{{hub fromSecret "open-cluster-management" "minio-cert" "tls.crt" hub}}" | base64dec | autoindent }}