1.9. 문제 해결

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

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

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

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

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

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

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 서버 인증서를 변경하거나 추가할 때 알 수 없는 권한 오류로 인해 클러스터를 다시 가져오는 데 실패할 수 있습니다.

관리형 클러스터를 다시 가져오지 못한 후 다음 명령을 실행하여 다중 클러스터 엔진 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"}, "namespace": "awscluster1", "awscluster1", "reconcileID": "reconcileID": "a2cccf24-2547-4e26-95b-f2580", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}

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

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

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

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

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

Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 가져온 후 클러스터는 보류 중 가져오기 상태와 함께 콘솔에 나타납니다.

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

사용자 정의 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 클러스터에서 분리하지 않습니다. 이 단계는 새 인증서 정보를 포함하여 관리형 클러스터의 현재 설정으로 필요한 매니페스트를 업데이트합니다.

관리 클러스터를 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의 베이스 보드 관리 컨트롤러에서 인증서 확인을 비활성화합니다.