1.4. 다중 클러스터 엔진 Operator를 사용한 클러스터 라이프사이클 릴리스 정보

새로운 기능 및 개선 사항, 지원, 사용 중단, 제거 및 에라타 버그 수정에 대해 알아보십시오.

중요: OpenShift Container Platform 릴리스 노트는 이 제품 문서에 포함되어 있지 않습니다. OpenShift Container Platform 클러스터의 경우 OpenShift Container Platform 릴리스 노트를 참조하십시오.

더 이상 사용되지 않음: 다중 클러스터 엔진 Operator 2.2 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 에라타 또는 기타 업데이트는 사용할 수 없습니다.

모범 사례: 최신 버전으로 업그레이드합니다.

이 문서는 특정 구성 요소 또는 기능이 도입되어 최신 버전의 OpenShift Container Platform에서만 테스트되지 않는 한 가장 빨리 지원되는 OpenShift Container Platform 버전을 참조합니다.
전체 지원 정보는 다중 클러스터 엔진 Operator 지원 매트릭스 를 참조하십시오. 라이프 사이클 정보는 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.
현재 지원되는 릴리스 중 하나 또는 제품 문서에 문제가 발생하는 경우 Red Hat 지원팀으로 이동하여 문제를 해결하거나 기술 자료 문서를 보거나 지원 팀과 연결하거나 케이스를 열 수 있습니다. 인증 정보를 사용하여 로그인해야 합니다.
Red Hat 고객 포털 FAQ에서 고객 포털 설명서에 대해 자세히 알아볼 수도 있습니다.

1.4.1. 다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클의 새로운 기능

다양한 인프라 클라우드 공급자, 프라이빗 클라우드 및 온프레미스 데이터 센터에서 Kubernetes 클러스터를 생성, 가져오기, 관리 및 제거하기 위한 새로운 기능에 대해 알아봅니다.

전체 지원 정보는 다중 클러스터 엔진 Operator 지원 매트릭스 를 참조하십시오. 라이프 사이클 정보는 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.

중요: 클러스터 관리는 이제 CCNCF(Cloud Native Computing Foundation) Kubernetes 적합성 프로그램을 통해 인증된 모든 공급자를 지원합니다. 하이브리드 클라우드 멀티 클러스터 관리를 위해 CNFC에서 인식하는 공급 업체를 선택합니다.

CNFC 공급자 사용에 대한 다음 정보를 참조하십시오.

CNFC 공급자가 인증된 Kubernetes 적합성에서 인증 하는 방법을 알아보십시오.
CNFC 타사 공급자에 대한 Red Hat 지원 정보는 타사 구성 요소와의 Red Hat 지원 또는 Red Hat 지원 문의 를 참조하십시오.
자체 CNFC 적합성 인증 클러스터를 가져오는 경우 OpenShift Container Platform CLI oc 명령을 Kubernetes CLI 명령 kubectl 로 변경해야 합니다.

1.4.1.1. 구성 요소에 대한 새로운 기능 및 개선 사항

특정 구성 요소의 새로운 기능에 대해 자세히 알아보십시오.

참고: 일부 기능 및 구성 요소는 기술 프리뷰로 확인 및 릴리스됩니다.

중요: 호스팅된 컨트롤 플레인 문서가 OpenShift Container Platform 설명서에 있습니다. OpenShift Container Platform 설명서의 호스팅 컨트롤 플레인 개요 를 참조하십시오.

다중 클러스터 엔진 Operator 2.6 및 이전 버전을 사용하는 경우 호스팅되는 컨트롤 플레인 문서는 Red Hat Advanced Cluster Management 제품 설명서에 있습니다. Red Hat Advanced Cluster Management Hosted Control Plane을 참조하십시오.

1.4.1.2. 클러스터 관리

다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클의 새로운 기능 및 개선 사항에 대해 알아보십시오.

이제 klusterlet 매니페스트의 kubeconfig 부트스트랩이 만료될 때 선택할 기간을 설정할 수 있습니다. 자세한 내용은 클러스터 가져오기를 참조하십시오.
이제 모든 클러스터 리소스를 가져오고 하나의 허브 클러스터에서 다른 허브 클러스터로 지원 설치 관리자가 설치한 클러스터를 이동한 후 해당 리소스를 계속 사용할 수 있습니다. 자세한 내용은 클러스터 리소스 가져오기를 참조하십시오.
이제 서비스 계정 자격 증명을 사용하여 OpenShift Cluster Manager에 연결할 수 있습니다. 자세한 내용은 Red Hat OpenShift Cluster Manager에 대한 인증 정보 생성 을 참조하십시오.
이제 관리 클러스터를 가져올 때 CA 번들을 지정할 수 있습니다. 자세한 내용은 관리 클러스터(기술 프리뷰)를 가져올 때 hub 클러스터 API 서버의 서버 URL 및 CA 번들 사용자 지정을 참조하십시오.
이제 허브 클러스터 KubeAPIServer 확인 전략을 수동으로 구성할 수 있습니다. 자세한 내용은 Hub 클러스터 KubeAPIServer 확인 전략 구성을참조하십시오.

1.4.2. 다중 클러스터 엔진 Operator를 사용하여 클러스터 라이프사이클에 대한 에라타 업데이트

다중 클러스터 엔진 Operator의 경우 에라타 업데이트가 릴리스될 때 자동으로 적용됩니다.

나열된 릴리스 노트가 없는 경우 현재 제품에 에라타 릴리스가 없습니다.

중요: 참조를 위해 Jira 링크 및 Jira 번호가 콘텐츠에 추가되고 내부적으로 사용될 수 있습니다. 액세스가 필요한 링크는 사용자에게 제공되지 않을 수 있습니다.

1.4.2.1. Errata 2.7.1

하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.

1.4.2.2. 에라타 2.7.2

하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
Clear all filters 버튼을 사용하여 오류를 수정합니다. (ACM-15277)
Detach 클러스터 작업이 호스팅된 클러스터를 삭제하지 못하도록 중지합니다. (ACM-15018)
유효한 OpenShift Cluster Manager 인증 정보를 잘못된 것으로 업데이트한 후 콘솔의 Discovery 탭에 관리 클러스터가 표시되지 않도록 합니다. (ACM-15010)
cluster-proxy-addon 이 Progressing 상태로 유지되지 않습니다. (ACM-14863)

1.4.3. 다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클의 알려진 문제 및 제한 사항

이 릴리스에 대해 다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클 의 알려진 문제 및 제한 사항 또는 이전 릴리스에서 계속되는 알려진 문제를 검토하십시오.

클러스터 관리 알려진 문제 및 제한 사항은 다중 클러스터 엔진 Operator 문서가 있는 클러스터 라이프사이클 의 일부입니다. Red Hat Advanced Cluster Management 와 통합된 {mce-short의 알려진 문제는 Red Hat Advanced Cluster Management의 릴리스 노트에 설명되어 있습니다.

1.4.3.1. 설치

다중 클러스터 엔진 Operator 설치 중에 알려진 문제 및 제한 사항에 대해 알아봅니다.

1.4.3.1.1. 호스팅된 컨트롤 플레인 클러스터를 사용하여 AWS의 OpenShift Service에 설치할 때 상태가 중단됨

호스트된 컨트롤 플레인 클러스터가 있는 AWS의 OpenShift 서비스에 다중 클러스터 엔진 Operator를 설치할 때 설치 상태가 설치 중일 수 있습니다. local-cluster 도 Unknown 상태로 남아 있을 수 있습니다.

klusterlet-agent Pod가 hub 클러스터의 open-cluster-management-agent 네임스페이스에 로그인하면 다음과 유사한 오류가 표시됩니다.

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

이 문제를 해결하려면 hub 클러스터 API 서버 확인 전략을 구성합니다. 다음 단계를 완료합니다.

이름이 global 인 KlusterletConfig 리소스가 없는 경우 해당 리소스를 생성합니다.

spec.hubKubeAPIServerConfig.serverVerificationStrategy 를 UseSystemTruststore 로 설정합니다. 다음 예제를 참조하십시오.

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerConfig:
    serverVerificationStrategy: UseSystemTruststore

hub 클러스터에서 다음 명령을 실행하여 리소스를 적용합니다. & lt;filename >을 파일 이름으로 바꿉니다.
```
oc apply -f <filename>
```
local-cluster 상태가 1분 내에 복구되지 않으면 hub 클러스터에서 다음 명령을 실행하여 import.yaml 파일을 내보내고 디코딩합니다.
```
oc get secret local-cluster-import -n local-cluster -o jsonpath={.data.import\.yaml} | base64 --decode > import.yaml
```
hub 클러스터에서 다음 명령을 실행하여 파일을 적용합니다.
```
oc apply -f import.yaml
```

1.4.3.1.2. installNamespace 필드에는 하나의 값만 있을 수 있습니다.

managed-serviceaccount 애드온을 활성화할 때 ManagedClusterAddOn 리소스의 installNamespace 필드에 값으로 open-cluster-management-agent-addon 이 있어야 합니다. 다른 값은 무시됩니다. managed-serviceaccount 애드온 에이전트는 항상 관리 클러스터의 open-cluster-management-agent-addon 네임스페이스에 배포됩니다.

1.4.3.2. Cluster

멀티 클러스터 엔진 Operator 생성, 검색, 가져오기 및 제거 문제 및 다중 클러스터 엔진 Operator의 클러스터 관리 문제와 같은 클러스터 라이프사이클의 알려진 문제 및 제한 사항에 대해 알아봅니다.

1.4.3.2.1. nmstate로 제한

복사 및 붙여넣기 기능을 구성하여 더 빠르게 개발하십시오. assisted-installer 에서 copy-from-mac 기능을 구성하려면 nmstate 정의 인터페이스 및 mac-mapping 인터페이스에 mac-address 를 추가해야 합니다. mac-mapping 인터페이스는 nmstate 정의 인터페이스 외부에 제공됩니다. 따라서 동일한 mac-address 를 두 번 제공해야 합니다.

다른 버전의 CryostatSync가 설치되어 있는 경우 v0.6.0 을 설치된 버전으로 교체합니다.

1.4.3.2.2. 관리형 클러스터 세트를 삭제해도 레이블이 자동으로 제거되지는 않습니다.

ManagedClusterSet 을 삭제한 후 클러스터를 클러스터 세트에 연결하는 각 관리 클러스터에 추가된 레이블은 자동으로 제거되지 않습니다. 삭제된 관리 클러스터 세트에 포함된 각 관리 클러스터에서 레이블을 수동으로 제거합니다. 레이블은 cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> 과 유사합니다.

1.4.3.2.3. ClusterClaim 오류

ClusterPool 에 대해 Hive ClusterClaim 을 생성하고 ClusterClaimspec 라이프 사이클 필드를 잘못된 golang 시간 값으로 수동으로 설정하는 경우 제품은 잘못된 형식의 클레임뿐만 아니라 모든 ClusterClaims 이행 및 재조정을 중지합니다.

poolName 및 invalid lifetime 이 포함된 특정 예인 clusterclaim-controller Pod 로그에 다음 오류가 표시됩니다.

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...

유효하지 않은 클레임을 삭제할 수 있습니다.

잘못된 클레임이 삭제되면 클레임이 추가 상호 작용 없이 성공적으로 조정되기 시작합니다.

1.4.3.2.4. 제품 채널이 프로비저닝된 클러스터와 동기화되지 않음

clusterimageset 은 fast 채널이지만 프로비저닝된 클러스터는 stable 채널에 있습니다. 현재 제품은 채널을 프로비저닝된 OpenShift Container Platform 클러스터와 동기화하지 않습니다.

OpenShift Container Platform 콘솔에서 올바른 채널로 변경합니다. Administration > Cluster Settings > Details Channel 을 클릭합니다.

1.4.3.2.5. 온-프레미스 클러스터를 만들 때 서브넷을 선택해야 합니다.

콘솔을 사용하여 온-프레미스 클러스터를 만들 때 클러스터에 사용 가능한 서브넷을 선택해야 합니다. 필수 필드로 표시되지 않습니다.

1.4.3.2.6. 프록시 환경에서 Ansible 자동화를 통한 클러스터 프로비저닝 실패

관리 클러스터를 자동으로 프로비저닝하도록 구성된 자동화 템플릿은 다음 두 조건이 충족되면 실패할 수 있습니다.

hub 클러스터에는 클러스터 전체 프록시가 활성화되어 있습니다.
Ansible Automation Platform은 프록시를 통해서만 연결할 수 있습니다.

1.4.3.2.7. 관리되는 클러스터 네임스페이스를 수동으로 삭제할 수 없음

관리 클러스터의 네임스페이스를 수동으로 삭제할 수 없습니다. 관리형 클러스터 네임스페이스는 관리 클러스터를 분리한 후 자동으로 삭제됩니다. 관리 클러스터가 분리되기 전에 관리 클러스터 네임스페이스를 수동으로 삭제하는 경우 관리 클러스터에 관리 클러스터를 삭제한 후 지속적인 종료 상태가 표시됩니다. 이 종료 관리 클러스터를 삭제하려면 분리된 관리 클러스터에서 종료자를 수동으로 제거합니다.

1.4.3.2.8. 프로비저닝된 클러스터의 자동 시크릿 업데이트는 지원되지 않습니다.

클라우드 공급자 측에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 이 클라우드 공급자에 대한 해당 인증 정보도 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.

1.4.3.2.9. 클러스터 제거 프로세스가 완료되지 않음

관리 클러스터를 삭제하면 1시간 후에도 상태가 계속 Destroying 으로 표시되고 클러스터가 삭제되지 않습니다. 이 문제를 해결하려면 다음 단계를 완료합니다.

클라우드에 고립된 리소스가 없고 관리 클러스터와 연결된 모든 공급자 리소스가 정리되었는지 수동으로 확인합니다.
다음 명령을 입력하여 제거 중인 관리 클러스터의 ClusterDeployment 정보를 엽니다.
```
oc edit clusterdeployment/<mycluster> -n <namespace>
```
mycluster 를 제거하려는 관리 클러스터의 이름으로 바꿉니다.
namespace 를 관리 클러스터의 네임스페이스로 바꿉니다.
hive.openshift.io/deprovision 종료자를 제거하여 클라우드에서 클러스터 리소스를 정리하려는 프로세스를 강제로 중지합니다.
변경 사항을 저장하고 ClusterDeployment 이 사라졌는지 확인합니다.
다음 명령을 실행하여 관리 클러스터의 네임스페이스를 수동으로 제거합니다.
```
oc delete ns <namespace>
```
namespace 를 관리 클러스터의 네임스페이스로 바꿉니다.

1.4.3.2.10. 콘솔을 사용하여 OpenShift Container Platform Dedicated에서 OpenShift Container Platform 관리형 클러스터를 업그레이드할 수 없습니다

Red Hat Advanced Cluster Management 콘솔을 사용하여 OpenShift Container Platform Dedicated 환경에 있는 OpenShift Container Platform 관리 클러스터를 업그레이드할 수 없습니다.

1.4.3.2.11. 작업 관리자 애드온 검색 세부 정보

특정 관리 클러스터에서 특정 리소스의 검색 세부 정보 페이지가 실패할 수 있습니다. 검색하려면 먼저 관리 클러스터의 work-manager 애드온이 Available 상태에 있는지 확인해야 합니다.

1.4.3.2.12. 비 OpenShift Container Platform 관리형 클러스터에는 Pod 로그에 ManagedServiceAccount 또는 LoadBalancer 가 필요합니다.

ManagedServiceAccount 및 클러스터 프록시 애드온은 Red Hat Advanced Cluster Management 버전 2.10 이상에서 기본적으로 활성화됩니다. 업그레이드 후 애드온이 비활성화된 경우 OpenShift Container Platform 관리 클러스터에서 Pod 로그 기능을 사용하려면 ManagedServiceAccount 및 클러스터 프록시 애드온을 수동으로 활성화해야 합니다.

ManagedServiceAccount 를 활성화하고 클러스터 프록시 애드온을 활성화하는 방법을 알아보려면 ManagedServiceAccount 애드온 을 참조하십시오.

1.4.3.2.13. OpenShift Container Platform 4.10.z는 프록시 구성이 있는 호스팅된 컨트롤 플레인 클러스터를 지원하지 않습니다.

OpenShift Container Platform 4.10.z에서 클러스터 전체 프록시 구성으로 호스팅 서비스 클러스터를 생성하면 nodeip-configuration.service 서비스가 작업자 노드에서 시작되지 않습니다.

1.4.3.2.14. 클라이언트가 iPXE 스크립트에 연결할 수 없음

iPXE는 오픈 소스 네트워크 부팅 펌웨어입니다. 자세한 내용은 iPXE 를 참조하십시오.

노드를 부팅할 때 일부 DHCP 서버의 URL 길이 제한이 InfraEnv 사용자 정의 리소스 정의의 ipxeScript URL을 차단하여 콘솔에 다음과 같은 오류 메시지가 표시됩니다.

부팅 가능한 장치 없음

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

지원 설치를 사용할 때 다음 파일과 유사할 수 있는 bootArtifacts 를 노출할 때 InfraEnv 사용자 정의 리소스 정의를 적용합니다.

status:
  agentLabelSelector:
    matchLabels:
      infraenvs.agent-install.openshift.io: qe2
  bootArtifacts:
    initrd: https://assisted-image-service-multicluster-engine.redhat.com/images/0000/pxe-initrd?api_key=0000000&arch=x86_64&version=4.11
    ipxeScript: https://assisted-service-multicluster-engine.redhat.com/api/assisted-install/v2/infra-envs/00000/downloads/files?api_key=000000000&file_name=ipxe-script
    kernel: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-kernel-x86_64
    rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-rootfs.x86_64.img

짧은 URL로 bootArtifacts 를 노출하는 프록시 서버를 생성합니다.

bootArtifacts 를 복사하여 다음 명령을 실행하여 프록시에 추가합니다.

for artifact in oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts}" | jq ". | keys[]" | sed "s/\"//g"
do curl -k oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts.${artifact}}"` -o $artifact

libvirt.xml 의 bootp 매개변수에 ipxeScript 아티팩트 프록시 URL을 추가합니다.

1.4.3.2.15. Red Hat Advanced Cluster Management를 업그레이드한 후 ClusterDeployment 을 삭제할 수 없음

Red Hat Advanced Cluster Management 2.6에서 삭제된 BareMetalAssets API를 사용하는 경우 BareMetalAssets API가 ClusterDeployment 에 바인딩되어 있으므로 Red Hat Advanced Cluster Management 2.7로 업그레이드한 후 ClusterDeployment 을 삭제할 수 없습니다.

이 문제를 해결하려면 Red Hat Advanced Cluster Management 2.7로 업그레이드하기 전에 종료자 를 제거하려면 다음 명령을 실행합니다.

oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge

1.4.3.2.16. 배포 후 관리 클러스터가 Pending 상태로 유지됨

통합 흐름은 기본 프로비저닝 프로세스입니다. Bare Metal Operator(BMO)에 BareMetalHost 리소스를 사용하여 호스트를 라이브 ISO에 연결하는 경우 Ironic Python 에이전트는 다음 작업을 수행합니다.

베어 메탈 설치 관리자 프로비저닝-infrastructure에서 단계를 실행합니다.
지원 설치 관리자 에이전트를 시작하고 에이전트는 설치 및 프로비저닝 프로세스의 나머지 부분을 처리합니다.

지원 설치 관리자 에이전트가 느리게 시작되고 관리 클러스터를 배포하는 경우 관리 클러스터가 Pending 상태로 중단되고 에이전트 리소스가 없을 수 있습니다. 통합 흐름을 비활성화하여 문제를 해결할 수 있습니다.

중요: 통합 흐름을 비활성화할 때 지원 설치 관리자 에이전트만 라이브 ISO에서 실행되므로 열려 있는 포트 수를 줄이고 Ironic Python 에이전트 에이전트에서 활성화한 기능을 비활성화합니다.

디스크 정리 사전 프로비저닝
iPXE 부팅 펌웨어
BIOS 구성

통합 흐름을 비활성화하지 않고 활성화하거나 비활성화할 포트 번호를 결정하려면 네트워크 구성 을 참조하십시오.

통합 흐름을 비활성화하려면 다음 단계를 완료합니다.

hub 클러스터에 다음 ConfigMap을 생성합니다.
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-assisted-service-config
  namespace: multicluster-engine
data:
  ALLOW_CONVERGED_FLOW: "false" 1
```
1
매개변수 값을 "false"로 설정하면 Ironic Python Agent에서 활성화한 기능도 비활성화합니다.

다음 명령을 실행하여 ConfigMap을 적용합니다.

oc annotate --overwrite AgentServiceConfig agent unsupported.agent-install.openshift.io/assisted-service-configmap=my-assisted-service-config

1.4.3.2.17. ManagedClusterSet API 사양 제한

Clustersets API 를 사용하는 경우 selectorType: LaberSelector 설정은 지원되지 않습니다. selectorType: ExclusiveClusterSetLabel 설정이 지원됩니다.

1.4.3.2.18. 클러스터 큐레이터는 OpenShift Container Platform Dedicated 클러스터를 지원하지 않습니다.

ClusterCurator 리소스를 사용하여 OpenShift Container Platform Dedicated 클러스터를 업그레이드하면 클러스터 큐레이터가 OpenShift Container Platform Dedicated 클러스터를 지원하지 않기 때문에 업그레이드가 실패합니다.

1.4.3.2.19. 사용자 정의 수신 도메인이 올바르게 적용되지 않음

관리형 클러스터를 설치하는 동안 ClusterDeployment 리소스를 사용하여 사용자 정의 인그레스 도메인을 지정할 수 있지만, SyncSet 리소스를 사용하여 설치 후에만 변경 사항을 적용합니다. 결과적으로 clusterdeployment.yaml 파일의 spec 필드에 사용자가 지정한 Ingress 도메인이 표시되지만 상태는 여전히 기본 도메인을 표시합니다.

1.4.3.2.20. `ManagedClusterAddon` 상태가 고정됨

ManagedClusterAddon 에서 구성을 정의하여 ClusterManagementAddon 의 일부 구성을 재정의하면 ManagedClusterAddon 이 다음 상태로 고정될 수 있습니다.

progressing... mca and work configs mismatch

ManagedClusterAddon 상태를 확인할 때 구성의 일부에는 구성이 있더라도 빈 사양 해시가 있습니다. 다음 예제를 참조하십시오.

status:
  conditions:
  - lastTransitionTime: "2024-09-09T16:08:42Z"
    message: progressing... mca and work configs mismatch
    reason: Progressing
    status: "True"
    type: Progressing
...
  configReferences:
  - desiredConfig:
      name: deploy-config
      namespace: open-cluster-management-hub
      specHash: b81380f1f1a1920388d90859a5d51f5521cecd77752755ba05ece495f551ebd0
    group: addon.open-cluster-management.io
    lastObservedGeneration: 1
    name: deploy-config
    namespace: open-cluster-management-hub
    resource: addondeploymentconfigs
  - desiredConfig:
      name: cluster-proxy
      specHash: ""
    group: proxy.open-cluster-management.io
    lastObservedGeneration: 1
    name: cluster-proxy
    resource: managedproxyconfigurations

문제를 해결하려면 다음 명령을 실행하여 ManagedClusterAddon 을 다시 설치하고 복구하여 ManagedClusterAddon 을 삭제합니다. &lt ;cluster-name&gt;을 ManagedClusterAddon 네임스페이스로 바꿉니다. & lt;addon-name& gt;을 ManagedClusterAddon 이름으로 바꿉니다.

oc -n <cluster-name> delete managedclusteraddon <addon-name>

1.4.3.3. 중앙 인프라 관리

1.4.3.3.1. infrastructure operator for Red Hat OpenShift를 사용한 클러스터 프로비저닝 실패

Red Hat OpenShift용 인프라 Operator를 사용하여 OpenShift Container Platform 클러스터를 생성할 때 ISO 이미지의 파일 이름이 너무 길 수 있습니다. 긴 이미지 이름을 사용하면 이미지 프로비저닝과 클러스터 프로비저닝이 실패합니다. 이 문제가 있는지 확인하려면 다음 단계를 완료합니다.

다음 명령을 실행하여 프로비저닝 중인 클러스터의 베어 메탈 호스트 정보를 확인합니다.
```
oc get bmh -n <cluster_provisioning_namespace>
```
describe 명령을 실행하여 오류 정보를 확인합니다.
```
oc describe bmh -n <cluster_provisioning_namespace> <bmh_name>
```

다음 예제와 유사한 오류는 파일 이름의 길이가 문제임을 나타냅니다.

Status:
  Error Count:    1
  Error Message:  Image provisioning failed: ... [Errno 36] File name too long ...

이 문제가 발생하면 일반적으로 Red Hat OpenShift용 인프라 Operator가 이미지 서비스를 사용하지 않았기 때문에 다음 버전의 OpenShift Container Platform에 있습니다.

4.8.17 및 이전 버전
4.9.6 이전

이 오류를 방지하려면 OpenShift Container Platform을 버전 4.8.18 이상 또는 4.9.7 이상으로 업그레이드하십시오.

1.4.3.3.2. 호스트 인벤토리를 사용하여 검색 이미지로 부팅하고 호스트를 자동으로 추가할 수 없습니다

검색 이미지로 부팅하고 호스트를 자동으로 추가하기 위해 호스트 인벤토리 또는 InfraEnv 사용자 정의 리소스를 사용할 수 없습니다. BareMetalHost 리소스에 이전 InfraEnv 리소스를 사용한 후 이미지를 직접 부팅하려는 경우 새 InfraEnv 리소스를 생성하여 문제를 해결할 수 있습니다.

1.4.3.3.3. 단일 노드 OpenShift 클러스터 설치에는 Red Hat OpenShift용 인프라 Operator와 일치하는 OpenShift Container Platform이 필요합니다.

4.16 이전 Red Hat OpenShift Container Platform 버전으로 단일 노드 OpenShift 클러스터를 설치하려면 InfraEnv 사용자 정의 리소스 및 부팅된 호스트에서 단일 노드 OpenShift 클러스터를 설치하기 위해 사용 중인 동일한 OpenShift Container Platform 버전을 사용해야 합니다. 버전이 일치하지 않으면 설치에 실패합니다.

이 문제를 해결하려면 Discovery ISO로 호스트를 부팅하기 전에 InfraEnv 리소스를 편집하고 다음 콘텐츠를 포함합니다.

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
spec:
  osImageVersion: 4.15

osImageVersion 필드는 설치하려는 Red Hat OpenShift Container Platform 클러스터 버전과 일치해야 합니다.

1.4.3.3.4. tolerations 및 nodeSelector 설정은 managed-serviceaccount 에이전트에 영향을 미치지 않습니다.

MultiClusterEngine 및 MultiClusterHub 리소스에 구성된 tolerations 및 nodeSelector 설정은 로컬 클러스터에 배포된 관리-serviceaccount 에이전트에 영향을 미치지 않습니다. 로컬 클러스터에서 managed-serviceaccount 애드온이 항상 필요한 것은 아닙니다.

managed-serviceaccount 애드온이 필요한 경우 다음 단계를 완료하여 문제를 해결할 수 있습니다.

addonDeploymentConfig 사용자 정의 리소스를 생성합니다.
로컬 클러스터 및 managed-serviceaccount 에이전트의 tolerations 및 nodeSelector 값을 설정합니다.
생성한 addonDeploymentConfig 사용자 정의 리소스를 사용하도록 로컬 클러스터 네임스페이스에서 managed-serviceaccount ManagedClusterAddon 을 업데이트합니다.

addonDeploymentConfig 사용자 정의 리소스 를 사용하여 애드온에 대한 허용 오차 및 nodeSelector를 구성하는 방법에 대한 자세한 내용은 klusterlet 애드온에 대한 nodeSelector 및 허용 오차 구성을 참조하십시오.

1.4.3.3.5. `BareMetalHost` 리소스를 제거한 후 노드 종료

hub 클러스터에서 BareMetalHost 리소스를 제거하면 노드가 종료됩니다. 노드의 전원을 수동으로 다시 켜면 됩니다.

1.4.4. 다중 클러스터 엔진 Operator를 사용하여 클러스터 라이프사이클의 사용 중단 및 제거

제품의 일부가 다중 클러스터 엔진 Operator에서 더 이상 사용되지 않거나 제거되는 시기를 알아봅니다. 현재 릴리스와 두 개의 이전 릴리스의 테이블에 표시되는 권장 작업 및 세부 사항의 대체 작업을 고려하십시오. 이 릴리스에 대한 항목이 추가되지 않으면 테이블이 제거됩니다.