1.9. 문제 해결

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

oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v2.5 --dest-dir=<directory>

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

REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel9@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8>

oc adm must-gather --image=$IMAGE --dest-dir=./data

여기에서 제품 팀의 Jira 버그를 열 수 있습니다.

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

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

Discover 단계 후에는 호스트가 재부팅되어 설치를 계속하지만 네트워크를 구성할 수 없습니다. 다음 증상 및 메시지를 확인합니다.

info: networking config is defined in the real root

info: will not attempt to propagate initramfs networking

로그에 마지막 메시지가 표시되면 이전에 Symptom 에 나열된 폴더에 기존 네트워크 구성이 이미 발견되었기 때문에 네트워킹 구성이 전파되지 않습니다.

설치 중에 적절한 네트워크 구성을 사용하려면 다음 작업을 수행합니다.

노드가 설치를 시작합니다. 검색 단계 후 노드는 기존 클러스터의 변경 사항과 초기 구성 간의 네트워크 구성을 병합합니다.

에이전트 플랫폼에서 호스트된 컨트롤 플레인 클러스터를 제거하려고 하면 다음과 같은 오류와 함께 hcp destroy 명령이 실패합니다.

+

2024-02-22T09:56:19-05:00    ERROR    HostedCluster deletion failed    {"namespace": "clusters", "name": "hosted-0", "error": "context deadline exceeded"}
2024-02-22T09:56:19-05:00    ERROR    Failed to destroy cluster    {"error": "context deadline exceeded"}

에이전트 플랫폼에서 호스트된 컨트롤 플레인 클러스터를 성공적으로 제거하려면 다음 단계를 완료합니다.

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

MultiClusterEngine 이 설치된 네임스페이스에서 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.'

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

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

다중 클러스터 엔진 Operator를 설치한 후 Pod가 시작되지 않는 경우 이전 멀티 클러스터 엔진 Operator의 항목이 제거될 때 올바르게 제거되지 않았기 때문에 종종 Pod가 시작되지 않습니다.

이 경우 설치 프로세스를 완료한 후 Pod가 시작되지 않습니다.

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

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

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

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

다중 클러스터 엔진 Operator를 사용하여 OpenShift Container Platform 클러스터를 프로비저닝한 후 OpenShift Container Platform 클러스터에 API 서버 인증서를 변경하거나 API 서버 인증서를 추가할 때 알 수 없는 기관에서 서명한 x509: 인증서로 클러스터를 다시 가져올 수 있습니다.

관리 클러스터를 다시 가져오지 못한 후 다음 명령을 실행하여 다중 클러스터 엔진 Operator 허브 클러스터에서 가져오기 컨트롤러 로그를 가져옵니다.

kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f

다음 오류 로그가 표시되면 관리 클러스터 API 서버 인증서가 변경될 수 있습니다.

ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace": "awscluster1", "name": "awscluster1", "reconcileID": "reconcileID": "a2cccf24-2547-4e26-f258a6710", "a2cccf24-2547-4e26-f258a6710", "error": "awscluster1"}

관리형 클러스터 API 서버 인증서가 변경되었는지 확인하려면 다음 단계를 완료합니다.

다음 메시지와 유사한 오류가 발생하면 클러스터 API 서버 ceritificates가 변경되었으며 kubeconfig 파일이 유효하지 않습니다.

서버에 연결할 수 없음: x509: 알 수 없는 기관에서 서명한 인증서

관리 클러스터 관리자는 관리 클러스터에 유효한 새 kubeconfig 파일을 생성해야 합니다.

새 kubeconfig 를 생성한 후 다음 단계를 완료하여 관리 클러스터의 새 kubeconfig 를 업데이트합니다.

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

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

사용자 정의 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

관리 클러스터가 로컬 클러스터이거나 관리되는 클러스터 가 다중 클러스터 엔진 Operator에 의해 생성된 경우 관리 클러스터를 복구하기 위해 10분 이상 기다려야 합니다.

관리 클러스터를 즉시 복구하려면 hub 클러스터에서 관리 클러스터 가져오기 보안을 삭제하고 다중 클러스터 엔진 Operator를 사용하여 복구할 수 있습니다. 다음 명령을 실행합니다.

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

& lt;cluster_name >을 복구하려는 관리 클러스터의 이름으로 바꿉니다.

다중 클러스터 엔진 Operator를 사용하여 가져온 관리 클러스터를 복구하려면 다음 단계를 완료하십시오. 관리 클러스터를 다시 가져옵니다.

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

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

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

콘솔을 사용하여 새 클러스터를 생성하면 Pending 상태 이상으로 클러스터가 진행되지 않거나 Failed 상태가 표시됩니다.

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

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

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

No subnets provided for zones

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

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

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

Red Hat OpenShift Container Platform 버전 3.11 클러스터를 가져오려고 하면 다음 콘텐츠와 유사한 로그 메시지와 함께 가져오기가 실패합니다.

customresourcedefinition.apiextensions.k8s.io/klusterlets.operator.open-cluster-management.io configured
clusterrole.rbac.authorization.k8s.io/klusterlet configured
clusterrole.rbac.authorization.k8s.io/open-cluster-management:klusterlet-admin-aggregate-clusterrole configured
clusterrolebinding.rbac.authorization.k8s.io/klusterlet configured
namespace/open-cluster-management-agent configured
secret/open-cluster-management-image-pull-credentials unchanged
serviceaccount/klusterlet configured
deployment.apps/klusterlet unchanged
klusterlet.operator.open-cluster-management.io/klusterlet configured
Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret:
v1.Secret.ObjectMeta:
v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 1313, error found in #10 byte of ...|dhruy45="},"kind":"|..., bigger context ...|tye56u56u568yuo7i67i67i67o556574i"},"kind":"Secret","metadata":{"annotations":{"kube|...

이는 설치된 kubectl 명령줄 툴이 1.11 이하이기 때문에 발생하는 경우가 많습니다. 다음 명령을 실행하여 실행 중인 kubectl 명령줄 툴 버전을 확인합니다.

kubectl version

반환된 데이터에 버전 1.11 또는 이전 버전이 나열된 경우 문제 해결 방법 중 하나를 완료하십시오: OpenShift Container Platform 버전 3.11 클러스터 가져오기 실패.

다음 절차 중 하나를 완료하여 이 문제를 해결할 수 있습니다.

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

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

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

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

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

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

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

배치를 생성하면 Placement Descision 이 자동으로 생성되지 않습니다.

이 문제를 해결하려면 다음 단계를 완료합니다.

베이스 보드 관리 컨트롤러를 사용하여 베어 메탈 호스트를 검색하는 절차를 완료하면 다음과 유사한 오류 메시지가 표시됩니다.

ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]

iDRAC는 알 수 없는 인증 기관의 인증서를 수락하지 않도록 구성되어 있습니다.

이 문제를 바이패스하려면 다음 단계를 완료하여 호스트 iDRAC의 베이스 보드 관리 컨트롤러에서 인증서 확인을 비활성화합니다.

부팅 화면에서 호스트가 루트 파일 시스템 이미지를 다운로드하지 못했음을 보여줍니다.

문제 해결 방법을 알아보려면 OpenShift Container Platform 설명서의 지원 설치 관리자에서 최소한의 ISO 부팅 실패 문제 해결을 참조하십시오.

HostedCluster 리소스가 보류 중이므로 호스트 컨트롤 플레인이 완전히 온라인 상태가 아닙니다.

호스팅된 컨트롤 플레인에 등록된 작업자 노드가 없으므로 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닙니다.

클러스터 생성 중에 네트워킹 스택이 롤아웃되는 동안 노드가 일시적으로 NotReady 상태로 들어갑니다. 이 과정의 일부는 정상입니다. 그러나 프로세스의 이 부분이 15분 이상 걸리는 경우 문제가 발생할 수 있습니다.

Ingress 및 콘솔 클러스터 Operator가 온라인 상태가 아니므로 호스팅 컨트롤 플레인이 완전히 온라인 상태가 아닙니다.

로드 밸런서 서비스를 사용할 수 없기 때문에 호스팅 컨트롤 플레인이 완전히 온라인 상태가 되지 않습니다.

호스트 클러스터의 PVC(영구 볼륨 클레임)를 사용할 수 없기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닙니다.

VM 노드가 클러스터에 올바르게 참여하지 않기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닙니다.

BareMetalHosts 없이 늦은 바인딩 관리 클러스터를 사용하는 경우 늦은 바인딩 클러스터를 제거하고 노드를 Discovery ISO로 반환하려면 추가 수동 단계를 완료해야 합니다.

호스팅된 컨트롤 플레인 클러스터가 있는 AWS(ROSA)에 Kubernetes Operator를 위한 다중 클러스터 엔진을 설치할 때 다중 클러스터 엔진 Operator는 설치 단계에서 중단되고 local-cluster 는 알 수 없는 상태로 유지됩니다.

E0809 18:45:29.450874       1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority

annotations:
  agent.open-cluster-management.io/klusterlet-config: isrg-root-x1-ca

호스팅된 컨트롤 플레인 클러스터가 있는 AWS(Red Hat OpenShift Service on AWS)에서 모든 관리 클러스터의 상태가 알 수 없음 으로 전환될 수 있습니다.

E0809 18:45:29.450874       1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority

annotations:
  agent.open-cluster-management.io/klusterlet-config: isrg-root-x1-ca