클러스터
클러스터 관리
초록
1장. 다중 클러스터 엔진 Operator가 포함된 클러스터 라이프사이클 개요
멀티 클러스터 엔진 Operator는 OpenShift Container Platform 및 Red Hat Advanced Cluster Management Hub 클러스터에 대한 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. 허브 클러스터에서 클러스터를 생성 및 관리하고 생성한 클러스터를 제거할 수 있습니다. 또한 클러스터를 hibernate, 재개 및 분리할 수도 있습니다. 다음 문서에서 클러스터 라이프사이클 기능에 대해 자세히 알아보십시오.
지원 매트릭스 에 액세스하여 허브 클러스터 및 관리형 클러스터 요구 사항 및 지원에 대해 알아보십시오.
정보:
- 클러스터는 Hive 리소스와 함께 OpenShift Container Platform 클러스터 설치 프로그램을 사용하여 생성됩니다. OpenShift Container Platform 클러스터 설치 및 구성 시 OpenShift Container Platform 클러스터 설치 및 구성에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 확인할 수 있습니다.
- OpenShift Container Platform 클러스터를 사용하면 다중 클러스터 엔진 Operator를 클러스터 라이프사이클 기능의 독립 실행형 클러스터 관리자로 사용하거나 Red Hat Advanced Cluster Management Hub 클러스터의 일부로 사용할 수 있습니다.
- OpenShift Container Platform만 사용하는 경우 Operator는 서브스크립션에 포함됩니다. OpenShift Container Platform 설명서에서 Kubernetes Operator용 다중 클러스터 엔진 정보를 참조하십시오.
- Red Hat Advanced Cluster Management를 구독하면 설치가 포함된 Operator도 제공됩니다. Red Hat Advanced Cluster Management Hub 클러스터를 사용하여 다른 Kubernetes 클러스터를 생성, 관리 및 모니터링할 수 있습니다. Red Hat Advanced Cluster Management 설치 및 업그레이드 설명서를 참조하십시오.
릴리스 이미지는 클러스터를 생성할 때 사용하는 OpenShift Container Platform 버전입니다. Red Hat Advanced Cluster Management를 사용하여 생성된 클러스터의 경우 릴리스 이미지의 자동 업그레이드를 활성화할 수 있습니다. Red Hat Advanced Cluster Management의 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
클러스터 라이프사이클 관리 아키텍처의 구성 요소는 클러스터 라이프사이클 아키텍처에 포함되어 있습니다.
1.1. 릴리스 노트
현재 릴리스에 대해 알아보십시오.
더 이상 사용되지 않음: 다중 클러스터 엔진 Operator 2.2 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 에라타 또는 기타 업데이트는 사용할 수 없습니다.
모범 사례: 최신 버전으로 업그레이드합니다.
현재 지원되는 릴리스 중 하나 또는 제품 문서에 문제가 발생하는 경우 Red Hat 지원팀으로 이동하여 문제를 해결하거나 기술 자료 문서를 보거나 지원 팀과 연결하거나 케이스를 열 수 있습니다. 인증 정보를 사용하여 로그인해야 합니다.
Red Hat 고객 포털 FAQ에서 고객 포털 설명서에 대해 자세히 알아볼 수도 있습니다.
이 문서는 특정 구성 요소 또는 기능이 도입되어 최신 버전의 OpenShift Container Platform에서만 테스트되지 않는 한 가장 빨리 지원되는 OpenShift Container Platform 버전을 참조합니다.
전체 지원 정보는 지원 매트릭스 를 참조하십시오. 라이프 사이클 정보는 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.
1.1.1. 다중 클러스터 엔진 Operator를 사용한 클러스터 라이프사이클의 새로운 기능
중요: 일부 기능 및 구성 요소는 기술 프리뷰로 확인 및 릴리스됩니다.
이 릴리스의 새로운 기능에 대해 자세히 알아보기:
1.1.1.1. 클러스터 라이프사이클
다중 클러스터 엔진 Operator의 클러스터 라이프사이클과 관련된 새로운 기능에 대해 알아보십시오.
- 이제 관리 클러스터가 HTTP 및 HTTPS 프록시 서버를 통해 hub 클러스터와 통신할 수 있도록 클러스터 프록시 애드온의 프록시 설정을 구성할 수 있습니다. 자세한 내용은 클러스터 프록시 애드온 구성 을 참조하십시오.
-
이제
ManagedServiceAccount
애드온이 기본적으로 활성화되어 있습니다. 다중 클러스터 엔진 Operator 버전 2.4에서 업그레이드하는 경우 애드온 활성화에 대한 자세한 내용은 ManagedServiceAccount 애드온 활성화를 참조하십시오. - 기술 프리뷰: 이제 중간 구성 요소가 있는 경우에도 다중 클러스터 엔진 Operator 허브 클러스터에서 관리 클러스터를 가져올 수 있도록 서버 URL 및 허브 클러스터 API CA 번들을 사용자 지정할 수 있습니다. 자세한 내용은 서버 URL 사용자 지정 및 허브 클러스터 API CA 번들(기술 프리뷰) 을 참조하십시오.
- 이제 각 요청에서 HTTP/HTTPS 헤더 및 쿼리 매개변수를 전달하여 OS 이미지를 가져올 수 있습니다. 자세한 내용은 연결이 끊긴 환경에서 중앙 인프라 관리 활성화를 참조하십시오.
-
이제 인증을 위해 자체 서명 또는 타사 CA 인증서를 사용하여 TLS가 활성화된 HTTPS
osImages
를 저장하고 다운로드할 수 있습니다. 자세한 내용은 연결이 끊긴 환경에서 중앙 인프라 관리 활성화를 참조하십시오.
1.1.1.2. 인증 정보
- 이제 VMware vSphere에서 연결이 끊긴 설치에 통합 콘솔을 사용하여 인증 정보를 생성하도록 Cluster OS 이미지 필드를 구성할 수 있습니다. 자세한 내용은 콘솔을 사용하여 인증 정보 관리를 참조하십시오.
1.1.1.3. 호스팅된 컨트롤 플레인
- 기술 프리뷰: 베어 메탈이 아닌 에이전트 시스템을 사용하여 호스팅된 컨트롤 플레인 클러스터를 프로비저닝할 수 있습니다. 자세한 내용은 베어 메탈 에이전트 머신을 사용하여 호스팅되는 컨트롤 플레인 클러스터 구성 을 참조하십시오.
- 콘솔을 사용하여 KubeVirt 플랫폼으로 호스팅 클러스터를 생성할 수 있습니다. 자세한 내용은 콘솔을 사용하여 호스팅 클러스터 생성을 참조하십시오.
- 이제 추가 네트워크를 구성하고 VM(가상 머신)에 대한 보장된 CPU 액세스를 요청하며 노드 풀의 KubeVirt VM 예약을 관리할 수 있습니다. 자세한 내용은 노드 풀의 추가 네트워크, 보장된 CPU 및 VM 스케줄링 구성을 참조하십시오.
1.1.1.4. Red Hat Advanced Cluster Management 통합
Red Hat Advanced Cluster Management를 설치한 후 Observability를 활성화하면 Grafana 대시보드를 사용하여 호스팅된 컨트롤 플레인 클러스터 용량 추정 및 기존 호스팅 컨트롤 플레인 리소스 사용률을 확인할 수 있습니다. 자세한 내용은 Red Hat Advanced Cluster Management integration 에서 참조하십시오.
1.1.2. 클러스터 라이프사이클의 알려진 문제
다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클의 알려진 문제를 검토합니다. 다음 목록에는 이 릴리스에 대한 알려진 문제 또는 이전 릴리스에서 계속되는 알려진 문제가 포함되어 있습니다. OpenShift Container Platform 클러스터의 경우 OpenShift Container Platform 릴리스 노트를 참조하십시오.
1.1.2.1. 클러스터 관리
클러스터 라이프사이클 알려진 문제 및 제한 사항은 다중 클러스터 엔진 Operator 문서가 있는 클러스터 라이프사이클의 일부입니다.
1.1.2.1.1. nmstate로 제한
복사 및 붙여넣기 기능을 구성하여 더 빠르게 개발하십시오. assisted-installer
에서 copy-from-mac
기능을 구성하려면 nmstate
정의 인터페이스 및 mac-mapping
인터페이스에 mac-address
를 추가해야 합니다. mac-mapping
인터페이스는 nmstate
정의 인터페이스 외부에 제공됩니다. 따라서 동일한 mac-address
를 두 번 제공해야 합니다.
1.1.2.1.2. Prehook 실패가 호스트된 클러스터 생성에 실패하지 않음
호스팅된 클러스터 생성에 자동화 템플릿을 사용하고 prehook 작업이 실패하면 호스팅된 클러스터 생성이 여전히 진행 중인 것처럼 보입니다. 호스트 클러스터가 완전한 실패 상태로 설계되었으므로 클러스터를 계속 생성하려고 하기 때문에 이는 정상입니다.
1.1.2.1.3. add-on을 제거할 때 관리형 클러스터에 필요한volSync CSV 수동 제거
hub 클러스터에서volSync ManagedClusterAddOn
을 제거하면 관리 클러스터에서volSync Operator 서브스크립션을 제거하지만 CSV(클러스터 서비스 버전)는 제거되지 않습니다. 관리형 클러스터에서 CSV를 제거하려면volSync를 제거하는 각 관리 클러스터에서 다음 명령을 실행합니다.
oc delete csv -n openshift-operators volsync-product.v0.6.0
다른 버전의 CryostatSync가 설치되어 있는 경우 v0.6.0
을 설치된 버전으로 교체합니다.
1.1.2.1.4. 관리형 클러스터 세트를 삭제해도 레이블이 자동으로 제거되지는 않습니다.
ManagedClusterSet
을 삭제한 후 클러스터를 클러스터 세트에 연결하는 각 관리 클러스터에 추가된 레이블은 자동으로 제거되지 않습니다. 삭제된 관리 클러스터 세트에 포함된 각 관리 클러스터에서 레이블을 수동으로 제거합니다. 레이블은 cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> 과 유사합니다
.
1.1.2.1.5. ClusterClaim 오류
ClusterPool
에 대해 Hive ClusterClaim
을 생성하고 ClusterClaimspec
라이프 사이클 필드를 잘못된 golang 시간 값으로 수동으로 설정하는 경우 제품은 잘못된 형식의 클레임뿐만 아니라 모든 ClusterClaims
이행 및 재조정을 중지합니다.
이 오류가 발생하면 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.1.2.1.6. 제품 채널이 프로비저닝된 클러스터와 동기화되지 않음
clusterimageset
은 fast
채널이지만 프로비저닝된 클러스터는 stable
채널에 있습니다. 현재 제품은 채널을
프로비저닝된 OpenShift Container Platform 클러스터와 동기화하지 않습니다.
OpenShift Container Platform 콘솔에서 올바른 채널로 변경합니다. Administration > Cluster Settings > Details Channel 을 클릭합니다.
1.1.2.1.7. 사용자 정의 CA 인증서가 있는 관리형 클러스터 연결을 복원하면 복원된 허브 클러스터에 실패할 수 있습니다.
사용자 정의 CA 인증서로 클러스터를 관리하는 허브 클러스터의 백업을 복원한 후 관리 클러스터와 hub 클러스터 간의 연결이 실패할 수 있습니다. 이는 복원된 허브 클러스터에서 CA 인증서가 백업되지 않았기 때문입니다. 연결을 복원하려면 관리 클러스터의 네임스페이스에 있는 사용자 정의 CA 인증서 정보를 복원된 허브 클러스터의 < managed_cluster>-admin-kubeconfig
시크릿에 복사합니다.
팁: 백업 사본을 생성하기 전에 이 CA 인증서를 hub 클러스터에 복사하는 경우 백업 사본에 시크릿 정보가 포함됩니다. 나중에 백업 사본을 사용하여 복원하면 허브와 관리 클러스터 간의 연결이 자동으로 완료됩니다.
1.1.2.1.8. local-cluster가 자동으로 다시 생성되지 않을 수 있습니다.
disableHubSelfManagement
를 false
로 설정하는 동안 local-cluster가 삭제되면 MulticlusterHub
Operator가 local-cluster를 다시 생성합니다. local-cluster를 분리하면 local-cluster가 자동으로 다시 생성되지 않을 수 있습니다.
이 문제를 해결하려면
MulticlusterHub
Operator에서 조사한 리소스를 수정합니다. 다음 예제를 참조하십시오.oc delete deployment multiclusterhub-repo -n <namespace>
-
local-cluster를 올바르게 분리하려면
MultiClusterHub
에서disableHubSelfManagement
를 true로 설정합니다.
1.1.2.1.9. 온-프레미스 클러스터를 만들 때 서브넷을 선택해야 합니다.
콘솔을 사용하여 온-프레미스 클러스터를 만들 때 클러스터에 사용 가능한 서브넷을 선택해야 합니다. 필수 필드로 표시되지 않습니다.
1.1.2.1.10. Infrastructure Operator를 통한 클러스터 프로비저닝 실패
Infrastructure 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 ...
이 문제가 발생하면 인프라 Operator가 이미지 서비스를 사용하지 않았기 때문에 일반적으로 다음 버전의 OpenShift Container Platform에 있습니다.
- 4.8.17 및 이전 버전
- 4.9.6 이전
이 오류를 방지하려면 OpenShift Container Platform을 버전 4.8.18 이상 또는 4.9.7 이상으로 업그레이드하십시오.
1.1.2.1.11. 호스트 인벤토리를 사용하여 검색 이미지로 부팅하고 호스트를 자동으로 추가할 수 없습니다
검색 이미지로 부팅하고 호스트를 자동으로 추가하기 위해 호스트 인벤토리 또는 InfraEnv
사용자 정의 리소스를 사용할 수 없습니다. BareMetalHost
리소스에 이전 InfraEnv
리소스를 사용한 후 이미지를 직접 부팅하려는 경우 새 InfraEnv
리소스를 생성하여 문제를 해결할 수 있습니다.
1.1.2.1.12. 다른 이름으로 다시 가져온 후 로컬 클러스터 상태 오프라인
실수로
라는 클러스터를 다른 이름으로 다시 가져오려고 하면 local 클러스터의 상태 및 다시 가져오기된 클러스터의 상태가 local-cluster
오프라인으로
표시됩니다.
이 경우 복구하려면 다음 단계를 완료합니다.
hub 클러스터에서 다음 명령을 실행하여 허브 클러스터의 자체 관리 설정을 일시적으로 편집합니다.
oc edit mch -n open-cluster-management multiclusterhub
-
spec.disableSelfManagement=true
설정을 추가합니다. hub 클러스터에서 다음 명령을 실행하여 local-cluster를 삭제하고 재배포합니다.
oc delete managedcluster local-cluster
다음 명령을 입력하여
local-cluster
관리 설정을 제거합니다.oc edit mch -n open-cluster-management multiclusterhub
-
이전에 추가한
spec.disableSelfManagement=true
를 제거합니다.
1.1.2.1.13. 프록시 환경에서 Ansible 자동화를 통한 클러스터 프로비저닝 실패
관리 클러스터를 자동으로 프로비저닝하도록 구성된 자동화 템플릿은 다음 두 조건이 충족되면 실패할 수 있습니다.
- hub 클러스터에는 클러스터 전체 프록시가 활성화되어 있습니다.
- Ansible Automation Platform은 프록시를 통해서만 연결할 수 있습니다.
1.1.2.1.14. klusterlet Operator의 버전은 hub 클러스터와 동일해야 합니다.
klusterlet Operator를 설치하여 관리 클러스터를 가져오는 경우 klusterlet Operator의 버전이 Hub 클러스터 버전과 동일하거나 klusterlet Operator가 작동하지 않아야 합니다.
1.1.2.1.15. 관리되는 클러스터 네임스페이스를 수동으로 삭제할 수 없음
관리 클러스터의 네임스페이스를 수동으로 삭제할 수 없습니다. 관리형 클러스터 네임스페이스는 관리 클러스터를 분리한 후 자동으로 삭제됩니다. 관리 클러스터가 분리되기 전에 관리 클러스터 네임스페이스를 수동으로 삭제하는 경우 관리 클러스터에 관리 클러스터를 삭제한 후 지속적인 종료 상태가 표시됩니다. 이 종료 관리 클러스터를 삭제하려면 분리된 관리 클러스터에서 종료자를 수동으로 제거합니다.
1.1.2.1.16. Hub 클러스터 및 관리형 클러스터 클럭이 동기화되지 않음
Hub 클러스터 및 관리 클러스터 시간이 동기화되지 않아 알
수 없고 결국 몇 분 내에 사용할 수 있습니다
. OpenShift Container Platform 허브 클러스터 시간이 올바르게 구성되었는지 확인합니다. 노드 사용자 지정을 참조하십시오.
1.1.2.1.17. 특정 버전의 IBM OpenShift Container Platform Kubernetes Service 클러스터 가져오기는 지원되지 않습니다.
IBM OpenShift Container Platform Kubernetes Service 버전 3.11 클러스터를 가져올 수 없습니다. 이후 버전의 IBM OpenShift Kubernetes Service가 지원됩니다.
1.1.2.1.18. 프로비저닝된 클러스터의 자동 시크릿 업데이트는 지원되지 않습니다.
클라우드 공급자 측에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 이 클라우드 공급자에 대한 해당 인증 정보도 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.
1.1.2.1.19. 관리 클러스터의 노드 정보는 검색에서 볼 수 없습니다
hub 클러스터에서 리소스에 대한 맵을 검색합니다. 사용자 RBAC 설정에 따라 사용자가 관리 클러스터의 노드 데이터를 볼 수 없습니다. 검색 결과는 클러스터의 노드 페이지에 표시되는 결과와 다를 수 있습니다.
1.1.2.1.20. 클러스터 제거 프로세스가 완료되지 않음
관리 클러스터를 삭제하면 1시간 후에도 상태가 계속 Destroying
으로 표시되고 클러스터가 삭제되지 않습니다. 이 문제를 해결하려면 다음 단계를 완료합니다.
- 클라우드에 고립된 리소스가 없고 관리 클러스터와 연결된 모든 공급자 리소스가 정리되었는지 수동으로 확인합니다.
다음 명령을 입력하여 제거 중인 관리 클러스터의
ClusterDeployment
정보를 엽니다.oc edit clusterdeployment/<mycluster> -n <namespace>
mycluster
를 제거하려는 관리 클러스터의 이름으로 바꿉니다.namespace
를 관리 클러스터의 네임스페이스로 바꿉니다.-
hive.openshift.io/deprovision
종료자를 제거하여 클라우드에서 클러스터 리소스를 정리하려는 프로세스를 강제로 중지합니다. -
변경 사항을 저장하고
ClusterDeployment
이 사라졌는지 확인합니다. 다음 명령을 실행하여 관리 클러스터의 네임스페이스를 수동으로 제거합니다.
oc delete ns <namespace>
namespace
를 관리 클러스터의 네임스페이스로 바꿉니다.
1.1.2.1.21. 콘솔을 사용하여 OpenShift Container Platform Dedicated에서 OpenShift Container Platform 관리형 클러스터를 업그레이드할 수 없습니다
Red Hat Advanced Cluster Management 콘솔을 사용하여 OpenShift Container Platform Dedicated 환경에 있는 OpenShift Container Platform 관리 클러스터를 업그레이드할 수 없습니다.
1.1.2.1.22. 작업 관리자 애드온 검색 세부 정보
특정 관리 클러스터에서 특정 리소스의 검색 세부 정보 페이지가 실패할 수 있습니다. 검색하려면 먼저 관리 클러스터의 work-manager 애드온이 Available
상태에 있는지 확인해야 합니다.
1.1.2.1.23. 비 Red Hat OpenShift Container Platform 관리형 클러스터에는 업그레이드 후 Pod 로그에 ManagedServiceAccount 또는 LoadBalancer 가 필요합니다.
Red Hat OpenShift Container Platform 및 비 OpenShift Container Platform 클러스터는 모두 Red Hat Advanced Cluster Management 2.10 이상의 새로 설치를 사용하는 경우 Pod 로그 기능을 지원합니다.
Red Hat Advanced Cluster Management 2.9에서 2.10으로 업그레이드한 경우 OpenShift Container Platform 관리형 클러스터에서 Pod 로그 기능을 사용하려면 ManagedServiceAccount
애드온을 수동으로 활성화해야 합니다. ManagedServiceAccount를 활성화하는 방법을 알아보려면 ManagedServiceAccount
애드온 을 참조하십시오.
또는 ManagedServiceAccount
대신 LoadBalancer
를 사용하여 비 OpenShift Container Platform 관리 클러스터에서 Pod 로그 기능을 활성화할 수 있습니다.
LoadBalancer
를 활성화하려면 다음 단계를 완료합니다.
-
클라우드 공급자에는 서로 다른
LoadBalancer
구성이 있습니다. 자세한 내용은 클라우드 공급자 설명서를 참조하십시오. -
managedClusterInfo
상태의loggingEndpoint
를 확인하여 Red Hat Advanced Cluster Management에서LoadBalancer
가 활성화되어 있는지 확인합니다. 다음 명령을 실행하여
loggingEndpoint.IP
또는loggingEndpoint.Host
에 유효한 IP 주소 또는 호스트 이름이 있는지 확인합니다.oc get managedclusterinfo <clusterName> -n <clusterNamespace> -o json | jq -r '.status.loggingEndpoint'
LoadBalancer
유형에 대한 자세한 내용은 Kubernetes 문서의 서비스 페이지를 참조하십시오.
1.1.2.1.24. OpenShift Container Platform 4.10.z는 프록시 구성이 있는 호스팅된 컨트롤 플레인 클러스터를 지원하지 않습니다.
OpenShift Container Platform 4.10.z에서 클러스터 전체 프록시 구성으로 호스팅 서비스 클러스터를 생성하면 nodeip-configuration.service
서비스가 작업자 노드에서 시작되지 않습니다.
1.1.2.1.25. Azure에서 OpenShift Container Platform 4.11 클러스터를 프로비저닝할 수 없음
Azure에서 OpenShift Container Platform 4.11 클러스터를 프로비저닝하면 인증 Operator 시간 초과 오류로 인해 실패합니다. 이 문제를 해결하려면 install-config.yaml
파일에서 다른 작업자 노드 유형을 사용하거나 vmNetworkingType
매개변수를 Basic
으로 설정합니다. 다음 install-config.yaml
예제를 참조하십시오.
compute: - hyperthreading: Enabled name: 'worker' replicas: 3 platform: azure: type: Standard_D2s_v3 osDisk: diskSizeGB: 128 vmNetworkingType: 'Basic'
1.1.2.1.26. 클라이언트가 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.1.2.1.27. 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.1.2.1.28. 중앙 인프라 관리 서비스를 사용하여 연결이 끊긴 환경에 배포된 클러스터는 설치되지 않을 수 있습니다.
중앙 인프라 관리 서비스를 사용하여 연결이 끊긴 환경에 클러스터를 배포할 때 클러스터 노드가 설치를 시작하지 못할 수 있습니다.
이 문제는 클러스터가 OpenShift Container Platform 버전 4.12.0에서 4.12.2를 통해 제공되는 Red Hat Enterprise Linux CoreOS 라이브 ISO 이미지에서 생성된 검색 ISO 이미지를 사용하기 때문에 발생합니다. 이미지에는 registry.redhat.io
및 registry.access.redhat.com
에서 소싱한 이미지의 서명이 필요한 제한적인 /etc/containers/policy.json
파일이 포함되어 있습니다. 연결이 끊긴 환경에서 미러링된 이미지에 서명이 미러링되지 않아 검색 시 이미지 풀링이 실패할 수 있습니다. 에이전트 이미지가 클러스터 노드와 연결되지 않아 지원 서비스와의 통신이 실패합니다.
이 문제를 해결하려면 /etc/containers/policy.json
파일을 제한 없이 설정하는 클러스터에 ignition 덮어쓰기를 적용합니다. Ignition 재정의는 InfraEnv
사용자 정의 리소스 정의에서 설정할 수 있습니다. 다음 예제에서는 재정의가 있는 InfraEnv
사용자 정의 리소스 정의를 보여줍니다.
apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: cluster namespace: cluster spec: ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'
다음 예제에서는 생성된 제한되지 않은 파일을 보여줍니다.
{ "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "docker-daemon": { "": [ { "type": "insecureAcceptAnything" } ] } } }
이 설정이 변경되면 클러스터가 설치됩니다.
1.1.2.1.29. 배포 후 관리 클러스터가 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.1.2.1.30. ManagedClusterSet API 사양 제한
Clustersets API 를 사용하는 경우 selectorType: LaberSelector
설정은 지원되지 않습니다. selectorType: ExclusiveClusterSetLabel
설정이 지원됩니다.
1.1.2.1.31. Hub 클러스터 통신 제한 사항
hub 클러스터가 관리 클러스터에 도달하거나 통신할 수 없는 경우 다음과 같은 제한 사항이 발생합니다.
- 콘솔을 사용하여 새 관리 클러스터를 생성할 수 없습니다. 명령행 인터페이스를 사용하거나 콘솔에서 수동으로 가져오기 명령 실행 옵션을 사용하여 관리 클러스터를 수동으로 가져올 수 있습니다.
- 콘솔을 사용하여 Application 또는 ApplicationSet을 배포하거나 관리 클러스터를 ArgoCD로 가져오는 경우 hub 클러스터 ArgoCD 컨트롤러는 관리 클러스터 API 서버를 호출합니다. AppSub 또는 ArgoCD 풀 모델을 사용하여 문제를 해결할 수 있습니다.
Pod 로그의 콘솔 페이지가 작동하지 않으며 다음과 유사한 오류 메시지가 표시됩니다.
Error querying resource logs: Service unavailable
1.1.2.1.32. 관리 서비스 계정 애드온 제한 사항
다음은 managed-serviceaccount
애드온에 대한 알려진 문제 및 제한 사항입니다.
1.1.2.1.32.1. installNamespace 필드에는 하나의 값만 있을 수 있습니다.
managed-serviceaccount
애드온을 활성화할 때 ManagedClusterAddOn
리소스의 installNamespace
필드에 값으로 open-cluster-management-agent-addon
이 있어야 합니다. 다른 값은 무시됩니다. managed-serviceaccount
애드온 에이전트는 항상 관리 클러스터의 open-cluster-management-agent-addon
네임스페이스에 배포됩니다.
1.1.2.1.32.2. 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.1.2.1.33. KubeVirt 호스트 클러스터의 대량 제거 옵션이 호스팅된 클러스터를 제거하지 않음
KubeVirt 호스팅 클러스터의 콘솔에서 대량 제거 옵션을 사용하면 KubeVirt 호스팅 클러스터가 제거되지 않습니다.
행 작업 드롭다운 메뉴를 사용하여 KubeVirt 호스팅 클러스터를 대신 삭제합니다.
1.1.2.1.34. 클러스터 큐레이터는 OpenShift Container Platform Dedicated 클러스터를 지원하지 않습니다.
ClusterCurator
리소스를 사용하여 OpenShift Container Platform Dedicated 클러스터를 업그레이드하면 클러스터 큐레이터가 OpenShift Container Platform Dedicated 클러스터를 지원하지 않기 때문에 업그레이드가 실패합니다.
1.1.2.1.35. 사용자 정의 수신 도메인이 올바르게 적용되지 않음
관리형 클러스터를 설치하는 동안 ClusterDeployment
리소스를 사용하여 사용자 정의 인그레스 도메인을 지정할 수 있지만, SyncSet
리소스를 사용하여 설치 후에만 변경 사항을 적용합니다. 결과적으로 clusterdeployment.yaml
파일의 spec
필드에 사용자가 지정한 Ingress 도메인이 표시되지만 상태는
여전히 기본 도메인을 표시합니다.
1.1.2.1.36. 단일 노드 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.1.2.2. 호스팅된 컨트롤 플레인
1.1.2.2.1. 콘솔이 호스트된 클러스터를 Pending 가져오기로 표시
주석 및 ManagedCluster
이름이 일치하지 않으면 콘솔에 클러스터가 Pending 가져오기
로 표시됩니다. 다중 클러스터 엔진 Operator는 클러스터를 사용할 수 없습니다. 주석이 없고 ManagedCluster
이름이 HostedCluster
리소스의 Infra-ID
값과 일치하지 않는 경우에도 동일한 문제가 발생합니다."
1.1.2.2.2. 호스트된 클러스터에 노드 풀을 추가할 때 콘솔이 동일한 버전을 여러 번 나열할 수 있습니다.
콘솔을 사용하여 기존 호스트 클러스터에 새 노드 풀을 추가하면 동일한 버전의 OpenShift Container Platform이 옵션 목록에 두 번 이상 표시될 수 있습니다. 원하는 버전의 목록에서 인스턴스를 선택할 수 있습니다.
1.1.2.2.3. 웹 콘솔은 클러스터에서 제거된 후에도 노드를 나열하고 인프라 환경으로 돌아갑니다.
노드 풀이 작업자가 0개로 축소되면 콘솔의 호스트 목록에는 노드가 준비
됨 상태로 계속 표시됩니다. 다음 두 가지 방법으로 노드 수를 확인할 수 있습니다.
- 콘솔에서 노드 풀로 이동하여 0개의 노드가 있는지 확인합니다.
명령줄 인터페이스에서 다음 명령을 실행합니다.
다음 명령을 실행하여 0개의 노드가 노드 풀에 있는지 확인합니다.
oc get nodepool -A
다음 명령을 실행하여 0 노드가 클러스터에 있는지 확인합니다.
oc get nodes --kubeconfig
- 다음 명령을 실행하여 0 에이전트가 클러스터에 바인딩된 것으로 보고되었는지 확인합니다.
oc get agents -A
1.1.2.2.4. 듀얼 스택 네트워크에 대해 구성된 호스트 클러스터의 잠재적인 DNS 문제
듀얼 스택 네트워크를 사용하는 환경에서 호스팅 클러스터를 생성할 때 다음과 같은 DNS 관련 문제가 발생할 수 있습니다.
-
service-ca-operator
pod의CrashLoopBackOff
상태: Pod가 호스팅된 컨트롤 플레인을 통해 Kubernetes API 서버에 연결하려고 하면kube-system
네임스페이스의 데이터 플레인 프록시가 요청을 확인할 수 없기 때문에 Pod는 서버에 연결할 수 없습니다. 이 문제는 HAProxy 설정에서 프런트 엔드에서 IP 주소를 사용하고 백엔드에서 Pod를 확인할 수 없는 DNS 이름을 사용하므로 발생합니다. -
Pod가
ContainerCreating
상태로 유지됨:openshift-service-ca-operator
에서 DNS pod에 DNS 확인에 필요한metrics-tls
시크릿을 생성할 수 없기 때문에 이 문제가 발생합니다. 결과적으로 Pod는 Kubernetes API 서버를 확인할 수 없습니다.
이러한 문제를 해결하려면 듀얼 스택 네트워크의 DNS 구성 지침에 따라 DNS 서버 설정을 구성합니다.
1.1.2.2.5. 베어 메탈 플랫폼에서 에이전트 리소스가 Ignition을 가져오지 못할 수 있습니다.
베어 메탈(Agent) 플랫폼에서 호스팅된 컨트롤 플레인 기능은 에이전트가 Ignition을 가져오는 데 사용하는 토큰을 주기적으로 순환합니다. 버그로 인해 새 토큰이 전파되지 않습니다. 그 결과 잠시 전에 생성된 에이전트 리소스가 있는 경우 Ignition을 가져오지 못할 수 있습니다.
이 문제를 해결하려면 에이전트 사양에서 IgnitionEndpointTokenReference
속성이 참조하는 보안을 삭제한 다음 에이전트 리소스에서 레이블을 추가하거나 수정합니다. 그런 다음 시스템은 에이전트 리소스가 수정되었음을 감지하고 새 토큰을 사용하여 시크릿을 다시 생성할 수 있습니다.
1.1.3. 에라타 업데이트
다중 클러스터 엔진 Operator의 경우 에라타 업데이트가 릴리스될 때 자동으로 적용됩니다.
중요: 참조를 위해 에라타 링크와 GitHub 번호가 콘텐츠에 추가되어 내부적으로 사용될 수 있습니다. 액세스가 필요한 링크는 사용자에게 제공되지 않을 수 있습니다.
1.1.3.1. 에라타 2.5.7
- 하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
1.1.3.2. 에라타 2.5.6
-
동시에 실행 중인 두 버전의
cluster-proxy-addon
의 업그레이드 문제를 해결하여 매니페스트가 서로 재정의되었습니다. (ACM-12411) - 하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
1.1.3.3. Errata 2.5.5
-
멀티 클러스터 엔진 Operator 버전 2.5.3 또는 버전 2.5.4로 업그레이드한 후 단일 노드 OpenShift 관리 클러스터에
알 수 없는
상태가 표시되는 문제가 해결되었습니다. (ACM-12584) - 하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
1.1.3.4. Errata 2.5.4
- 하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
1.1.3.5. Errata 2.5.3
-
호스팅된 컨트롤 플레인 클러스터의 기본 모드를
HighAvailability
모드로 설정하는 KubeVirt 생성 마법사에 필드를 추가했습니다. (ACM-10580) - 하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
1.1.3.6. Errata 2.5.2
- 백업 복원 시나리오를 실행하고 Red Hat OpenShift Data Foundation(ODF)용 Regional-DR 솔루션을 사용할 때 데이터 손실을 일으킬 수 있는 문제를 해결합니다. (ACM-10407)
- 하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
1.1.3.7. Errata 2.5.1
- 하나 이상의 제품 컨테이너 이미지에 대한 업데이트를 제공합니다.
1.1.4. 클러스터 라이프사이클 사용 중단 및 제거
제품의 일부가 다중 클러스터 엔진 Operator에서 더 이상 사용되지 않거나 제거되는 시기를 알아봅니다. 현재 릴리스와 두 개의 이전 릴리스의 테이블에 표시되는 권장 작업 및 세부 사항의 대체 작업을 고려하십시오.
더 이상 사용되지 않음: 다중 클러스터 엔진 Operator 2.2 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 에라타 또는 기타 업데이트는 사용할 수 없습니다.
모범 사례: 최신 버전으로 업그레이드합니다.
1.1.4.1. API 사용 중단 및 제거
다중 클러스터 엔진 Operator는 API에 대한 Kubernetes 사용 중단 지침을 따릅니다. 해당 정책에 대한 자세한 내용은 Kubernetes 사용 중단 정책을 참조하십시오. 다중 클러스터 엔진 Operator API는 다음 타임라인 외부에서만 더 이상 사용되지 않거나 제거됩니다.
-
모든
V1
API는 일반적으로 12개월 또는 3개의 릴리스에서 더 큰 릴리스에서 일반적으로 사용할 수 있습니다. V1 API는 제거되지 않지만 시간 제한 외부에서 더 이상 사용되지 않을 수 있습니다. -
모든
베타
API는 일반적으로 9 개월 또는 세 번 릴리스에서 사용할 수 있습니다. 베타 API는 해당 시간 제한 외부에서 제거되지 않습니다. -
모든
알파
API는 지원되지 않아도 되지만 사용자에게 도움이 되는 경우 더 이상 사용되지 않거나 제거될 수 있습니다.
1.1.4.1.1. API 사용 중단
제품 또는 카테고리 | 영향을 받는 항목 | 버전 | 권장 작업 | 자세한 내용 및 링크 |
---|---|---|---|---|
ManagedServiceAccount |
| 2.9 |
| 없음 |
1.1.4.1.2. API 제거
제품 또는 카테고리 | 영향을 받는 항목 | 버전 | 권장 작업 | 자세한 내용 및 링크 |
1.1.4.2. deprecations
더 이상 사용되지 않는 구성 요소, 기능 또는 서비스가 지원되지만 더 이상 사용하지 않는 것은 권장되지 않으며 향후 릴리스에서 더 이상 사용되지 않을 수 있습니다. 권장 작업 및 다음 표에 제공되는 세부 사항의 대체 작업을 고려하십시오.
제품 또는 카테고리 | 영향을 받는 항목 | 버전 | 권장 작업 | 자세한 내용 및 링크 |
---|---|---|---|---|
클러스터 라이프사이클 | Red Hat Virtualization에서 클러스터 생성 | 2.9 | 없음 | 없음 |
클러스터 라이프사이클 | Klusterlet OLM Operator | 2.4 | 없음 | 없음 |
1.1.4.3. 제거
삭제된 항목은 일반적으로 이전 릴리스에서 더 이상 사용되지 않으며 제품에서 더 이상 사용할 수 없는 기능입니다. 제거된 함수에 대한 대안을 사용해야 합니다. 권장 작업 및 다음 표에 제공되는 세부 사항의 대체 작업을 고려하십시오.
제품 또는 카테고리 | 영향을 받는 항목 | 버전 | 권장 작업 | 자세한 내용 및 링크 |
1.2. 다중 클러스터 엔진 Operator를 사용하는 클러스터 라이프사이클 정보
Kubernetes Operator용 멀티 클러스터 엔진은 Red Hat OpenShift Container Platform 및 Red Hat Advanced Cluster Management Hub 클러스터를 위한 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. Red Hat Advanced Cluster Management를 설치한 경우 자동으로 설치되므로 다중 클러스터 엔진 Operator를 설치할 필요가 없습니다.
허브 클러스터 및 관리형 클러스터 요구 사항 및 지원에 대한 자세한 내용과 지원 매트릭스 를 참조하십시오.
계속하려면 다중 클러스터 엔진 Operator 개요를 사용하여 클러스터 라이프사이클에서 나머지 클러스터 라이프 사이클 문서를 참조하십시오.
1.2.1. 콘솔 개요
OpenShift Container Platform 콘솔 플러그인은 OpenShift Container Platform 웹 콘솔에서 사용할 수 있으며 통합할 수 있습니다. 이 기능을 사용하려면 콘솔 플러그인을 계속 활성화해야 합니다. 다중 클러스터 엔진 Operator는 인프라 및 인증 정보 탐색 항목의 특정 콘솔 기능을 표시합니다. Red Hat Advanced Cluster Management를 설치하는 경우 더 많은 콘솔 기능이 표시됩니다.
참고: 플러그인을 활성화하면 드롭다운 메뉴에서 모든 클러스터를 선택하여 클러스터 전환기에서 OpenShift Container Platform 콘솔 내에서 Red Hat Advanced Cluster Management에 액세스할 수 있습니다.
- 플러그인을 비활성화하려면 OpenShift Container Platform 콘솔의 관리자 화면에 있는지 확인합니다.
- 탐색에서 Administration 을 찾고 Cluster Settings 를 클릭한 다음 Configuration 탭을 클릭합니다.
-
구성 리소스 목록에서 웹 콘솔에 대한 클러스터 전체 구성이 포함된
operator.openshift.io
API 그룹이 있는 Console 리소스를 클릭합니다. -
콘솔 플러그인 탭을 클릭합니다.
mce
플러그인이 나열됩니다. 참고: Red Hat Advanced Cluster Management가 설치된 경우acm
로도 나열됩니다. - 표에서 플러그인 상태를 수정합니다. 잠시 후 콘솔을 새로 고침하라는 메시지가 표시됩니다.
1.2.2. 다중 클러스터 엔진 Operator 역할 기반 액세스 제어
RBAC는 콘솔 수준 및 API 수준에서 검증됩니다. 콘솔의 작업은 사용자 액세스 역할 권한에 따라 활성화하거나 비활성화할 수 있습니다. 제품의 특정 라이프사이클에 대한 RBAC에 대한 자세한 내용은 다음 섹션을 참조하십시오.
1.2.2.1. 역할 개요
일부 제품 리소스는 클러스터 전체이며 일부는 네임스페이스 범위입니다. 일관된 액세스 제어를 위해 사용자에게 클러스터 역할 바인딩 및 네임스페이스 역할 바인딩을 적용해야 합니다. 지원되는 다음 역할 정의의 표 목록을 확인합니다.
1.2.2.1.1. 역할 정의 표
Role | 정의 |
---|---|
|
OpenShift Container Platform 기본 역할입니다. |
|
|
|
|
|
|
|
|
|
|
|
admin, edit, view는 OpenShift Container Platform 기본 역할입니다. 이러한 역할에 대한 네임스페이스 범위 바인딩이 있는 사용자는 특정 네임스페이스의 |
중요:
- 모든 사용자는 OpenShift Container Platform에서 프로젝트를 생성할 수 있으므로 네임스페이스에 대한 관리자 역할 권한이 부여됩니다.
-
사용자에게 클러스터에 대한 역할 액세스 권한이 없는 경우 클러스터 이름이 표시되지 않습니다. 클러스터 이름은 다음 기호와 함께 표시됩니다.
-
.
RBAC는 콘솔 수준 및 API 수준에서 검증됩니다. 콘솔의 작업은 사용자 액세스 역할 권한에 따라 활성화하거나 비활성화할 수 있습니다. 제품의 특정 라이프사이클에 대한 RBAC에 대한 자세한 내용은 다음 섹션을 참조하십시오.
1.2.2.2. 클러스터 라이프사이클 RBAC
다음 클러스터 라이프사이클 RBAC 작업을 확인합니다.
모든 관리 클러스터에 대한 클러스터 역할 바인딩을 생성하고 관리합니다. 예를 들어 다음 명령을 입력하여 클러스터 역할
open-cluster-management:cluster-manager-admin
에 대한 클러스터 역할 바인딩을 생성합니다.oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin --user=<username>
이 역할은 모든 리소스 및 작업에 액세스할 수 있는 슈퍼유저입니다. 클러스터 범위의
관리 클러스터
리소스, 관리 클러스터를 관리하는 리소스의 네임스페이스, 이 역할이 있는 네임스페이스의 리소스를 생성할 수 있습니다. 권한 오류를 방지하기 위해 역할연결이 필요한 ID의 사용자 이름을
추가해야 할 수 있습니다.다음 명령을 실행하여
cluster-name
이라는 관리 클러스터의 클러스터 역할 바인딩을 관리합니다.oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>
이 역할에는 클러스터 범위의
managedcluster
리소스에 대한 읽기 및 쓰기 권한이 있습니다. 이는managedcluster
가 네임스페이스 범위 리소스가 아닌 클러스터 범위 리소스이므로 필요합니다.다음 명령을 입력하여 클러스터 역할
admin
에 대한 네임스페이스 역할 바인딩을 생성합니다.oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin --user=<username>
이 역할에는 관리 클러스터의 네임스페이스의 리소스에 대한 읽기 및 쓰기 권한이 있습니다.
open-cluster-management:view:<cluster-name
> 클러스터 역할에 대한 클러스터 역할 바인딩을 생성하여cluster-name
이라는 관리 클러스터를 확인합니다.oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>
이 역할은 클러스터 범위의
managedcluster
리소스에 대한 읽기 액세스 권한이 있습니다. 이는managedcluster
가 클러스터 범위 리소스이므로 필요합니다.다음 명령을 입력하여 클러스터 역할
뷰에 대한
네임스페이스 역할 바인딩을 생성합니다.oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view --user=<username>
이 역할에는 관리 클러스터의 네임스페이스의 리소스에 대한 읽기 전용 권한이 있습니다.
다음 명령을 입력하여 액세스할 수 있는 관리 클러스터 목록을 확인합니다.
oc get managedclusters.clusterview.open-cluster-management.io
이 명령은 클러스터 관리자 권한이 없는 관리자와 사용자가 사용합니다.
다음 명령을 입력하여 액세스할 수 있는 관리 클러스터 세트 목록을 확인합니다.
oc get managedclustersets.clusterview.open-cluster-management.io
이 명령은 클러스터 관리자 권한이 없는 관리자와 사용자가 사용합니다.
1.2.2.2.1. 클러스터 풀 RBAC
다음 클러스터 풀 RBAC 작업을 확인합니다.
클러스터 관리자는 관리 클러스터 세트를 생성하고 그룹에 역할을 추가하여 관리자 권한을 부여하여 클러스터 풀 프로비저닝 클러스터를 사용합니다. 다음 예제를 확인합니다.
다음 명령을 사용하여
server-foundation-clusterset
관리 클러스터 세트에관리자
권한을 부여합니다.oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-admin:server-foundation-clusterset server-foundation-team-admin
다음 명령을 사용하여
server-foundation-clusterset
관리 클러스터 세트에보기
권한을 부여합니다.oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-view:server-foundation-clusterset server-foundation-team-user
클러스터 풀
server-foundation-clusterpool
의 네임스페이스를 만듭니다. 역할 권한을 부여하려면 다음 예제를 확인합니다.다음 명령을 실행하여 server-foundation-
team-
에 부여합니다.admin
에 대한 관리자 권한을server-foundation-
clusterpooloc adm new-project server-foundation-clusterpool oc adm policy add-role-to-group admin server-foundation-team-admin --namespace server-foundation-clusterpool
팀 관리자로 클러스터 세트 레이블
cluster.open-cluster-management.io/clusterset=server-foundation-clusterset
를 사용하여ocp46-aws-clusterpool
이라는 클러스터 풀을 생성합니다.-
server-foundation-webhook
는 클러스터 풀에 클러스터 세트 레이블이 있는지, 사용자가 클러스터 세트에 클러스터 풀을 생성할 수 있는 권한이 있는지 확인합니다. -
server-foundation-controller
는server-foundation-team-user
의server-foundation-clusterpool
네임스페이스에 대한보기
권한을 부여합니다.
-
클러스터 풀이 생성되면 클러스터 풀이
클러스터 배포를
생성합니다. 자세한 내용은 계속 읽으십시오.-
server-foundation-controller
는server-foundation-team-
의admin
clusterdeployment
네임스페이스에 대한 관리자 권한을 부여합니다. server-foundation-controller
는server-foundation-team-user
에 대한보기
권한클러스터 배포
네임스페이스를 부여합니다.참고:
team-admin
및team-user
로clusterpool
,clusterdeployment
,clusterclaim
에 대한관리자
권한이 있습니다.
-
1.2.2.2.2. 클러스터 라이프사이클을 위한 콘솔 및 API RBAC 테이블
클러스터 라이프사이클에 대해 다음 콘솔 및 API RBAC 테이블을 확인합니다.
리소스 | 관리자 | edit | view |
---|---|---|---|
클러스터 | 읽기, 업데이트, 삭제 | - | 읽기 |
클러스터 세트 | get, update, bind, join | 언급되지 않은 편집 역할 | get |
관리형 클러스터 | 읽기, 업데이트, 삭제 | 언급된 편집 역할 없음 | get |
공급자 연결 | 생성, 읽기, 업데이트 및 삭제 | - | 읽기 |
API | 관리자 | edit | view |
---|---|---|---|
이 API의 명령에 | 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
이 API의 명령에서 | 읽기 | 읽기 | 읽기 |
| 업데이트 | 업데이트 | |
이 API의 명령에 | 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 읽기 | 읽기 | 읽기 |
이 API의 명령에 | 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
| 생성, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | 읽기 |
1.2.2.2.3. 인증 정보 역할 기반 액세스 제어
인증 정보에 대한 액세스는 Kubernetes에서 제어합니다. 인증 정보는 Kubernetes 시크릿으로 저장되고 보호됩니다. 다음 권한은 Red Hat Advanced Cluster Management for Kubernetes의 보안에 적용됩니다.
- 네임스페이스에서 보안을 생성할 수 있는 액세스 권한이 있는 사용자는 인증 정보를 생성할 수 있습니다.
- 네임스페이스에서 시크릿 읽기에 대한 액세스 권한이 있는 사용자는 인증 정보를 볼 수도 있습니다.
-
admin
의 Kubernetes 클러스터 역할이 있는 사용자는 시크릿을 생성하고편집할
수 있습니다. -
Kubernetes 클러스터 역할의 사용자는 시크릿 내용을 읽을 수 없으므로 시크릿을
볼
수 없습니다. 서비스 계정 자격 증명에 액세스할 수 있기 때문입니다.
1.2.3. 네트워크 구성
연결을 허용하도록 네트워크 설정을 구성합니다.
중요: 신뢰할 수 있는 CA 번들은 다중 클러스터 엔진 Operator 네임스페이스에서 사용할 수 있지만 이를 개선하려면 네트워크를 변경해야 합니다. 신뢰할 수 있는 CA 번들 ConfigMap은 기본 이름 trusted-ca-bundle
을 사용합니다. TRUSTED_CA_BUNDLE
이라는 환경 변수에 Operator에 제공하여 이 이름을 변경할 수 있습니다. 자세한 내용은 Red Hat OpenShift Container Platform의 네트워킹 섹션에서 클러스터 전체 프록시 구성 을 참조하십시오.
참고: 관리형 클러스터의 등록
는 프록시를 통과할 수 없는 mTLS 연결을 설정하여 hub 클러스터에서 에이전트
및 작업 에이전트apiserver
와 통신하기 때문에 프록시 설정을 지원하지 않습니다.
다중 클러스터 엔진 Operator 클러스터 네트워킹 요구 사항은 다음 표를 참조하십시오.
방향 | 프로토콜 | 연결 | 포트(지정된 경우) |
---|---|---|---|
아웃바운드 | 프로비저닝된 관리형 클러스터의 Kubernetes API 서버 | 6443 | |
OpenShift Container Platform 관리 클러스터에서 허브 클러스터로의 아웃 바운드 | TCP | hub 클러스터의 Ironic Python 에이전트와 베어 메탈 Operator 간 통신 | 6180, 6183, 6385 및 5050 |
hub 클러스터에서 관리 클러스터의 Ironic Python Agent로의 아웃 바운드 | TCP | Ironic Python Agent가 실행 중인 베어 메탈 노드와 Ironic conductor 서비스 간의 통신 | 9999 |
아웃바운드 및 인바운드 |
관리 클러스터의 | 443 | |
인바운드 | 관리 클러스터의 Kubernetes Operator 클러스터에 대한 다중 클러스터 엔진의 Kubernetes API 서버 | 6443 |
참고: 관리 클러스터는 hub 클러스터 컨트롤 플레인 노드 IP 주소에 연결할 수 있어야 합니다.
1.3. 다중 클러스터 엔진 Operator 설치 및 업그레이드
다중 클러스터 엔진 Operator는 클러스터 플릿 관리를 개선하는 소프트웨어 운영자입니다. 멀티 클러스터 엔진 Operator는 클라우드 및 데이터 센터 전체에서 Red Hat OpenShift Container Platform 및 Kubernetes 클러스터 라이프사이클 관리를 지원합니다.
더 이상 사용되지 않음: 다중 클러스터 엔진 Operator 2.2 및 이전 버전은 더 이상 지원되지 않습니다. 문서는 사용할 수 있지만 에라타 또는 기타 업데이트는 사용할 수 없습니다.
모범 사례: 최신 버전으로 업그레이드합니다.
이 문서는 특정 구성 요소 또는 기능이 도입되어 최신 버전의 OpenShift Container Platform에서만 테스트되지 않는 한 가장 빨리 지원되는 OpenShift Container Platform 버전을 참조합니다.
전체 지원 정보는 지원 매트릭스 를 참조하십시오. 라이프 사이클 정보는 Red Hat OpenShift Container Platform 라이프 사이클 정책을 참조하십시오.
중요: Red Hat Advanced Cluster Management 버전 2.5 이상을 사용하는 경우 Kubernetes Operator용 다중 클러스터 엔진이 클러스터에 이미 설치되어 있습니다.
다음 설명서를 참조하십시오.
1.3.1. 온라인으로 연결하는 동안 설치
다중 클러스터 엔진 Operator는 다중 클러스터 엔진 Operator를 포함하는 구성 요소의 설치, 업그레이드 및 제거를 관리하는 Operator Lifecycle Manager와 함께 설치됩니다.
필수 액세스: 클러스터 관리자
중요:
-
OpenShift Container Platform Dedicated 환경의 경우
cluster-admin
권한이 있어야 합니다. 기본적으로dedicated-admin
역할에는 OpenShift Container Platform Dedicated 환경에서 네임스페이스를 생성하는 데 필요한 권한이 없습니다. - 기본적으로 다중 클러스터 엔진 Operator 구성 요소는 추가 구성없이 OpenShift Container Platform 클러스터의 작업자 노드에 설치됩니다. OpenShift Container Platform OperatorHub 웹 콘솔 인터페이스를 사용하거나 OpenShift Container Platform CLI를 사용하여 다중 클러스터 엔진 Operator를 작업자 노드에 설치할 수 있습니다.
- 인프라 노드를 사용하여 OpenShift Container Platform 클러스터를 구성한 경우 추가 리소스 매개변수와 함께 OpenShift Container Platform CLI를 사용하여 다중 클러스터 엔진 Operator를 해당 인프라 노드에 설치할 수 있습니다. 자세한 내용은 인프라 노드에 다중 클러스터 엔진 설치 섹션을 참조하십시오.
Kubernetes Operator를 위해 OpenShift Container Platform 또는 다중 클러스터 엔진에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 이미지 가져오기 보안을 구성해야 합니다. 이미지 풀 시크릿 및 기타 고급 구성을 구성하는 방법에 대한 자세한 내용은 이 설명서의 고급 구성 섹션에 있는 옵션을 참조하십시오.
1.3.1.1. 사전 요구 사항
Kubernetes Operator용 다중 클러스터 엔진을 설치하기 전에 다음 요구 사항을 참조하십시오.
- Red Hat OpenShift Container Platform 클러스터는 OpenShift Container Platform 콘솔의 OperatorHub 카탈로그에서 다중 클러스터 엔진 Operator에 액세스할 수 있어야 합니다.
- catalog.redhat.com 에 액세스해야 합니다.
OpenShift Container Platform 4.13 이상은 환경에 배포되어야 하며 OpenShift Container Platform CLI로 로그인해야 합니다. OpenShift Container Platform에 대한 다음 설치 설명서를 참조하십시오.
-
oc
명령을 실행하도록 OpenShift Container Platform CLI(명령줄 인터페이스)를 구성해야 합니다. OpenShift Container Platform CLI 설치 및 구성에 대한 정보는 CLI로 시작하기 를 참조하십시오. - OpenShift Container Platform 권한에서 네임스페이스를 생성할 수 있어야 합니다.
- Operator의 종속 항목에 액세스하려면 인터넷 연결이 있어야 합니다.
OpenShift Container Platform Dedicated 환경에 설치하려면 다음을 참조하십시오.
- OpenShift Container Platform Dedicated 환경이 구성되어 실행되고 있어야 합니다.
-
엔진을 설치하는 OpenShift Container Platform Dedicated 환경에 대한
cluster-admin
권한이 있어야 합니다.
- Red Hat OpenShift Container Platform과 함께 제공되는 지원 설치 관리자를 사용하여 관리 클러스터를 생성하려면 요구 사항에 대한 OpenShift Container Platform 설명서의 지원 설치 관리자 준비를 참조하십시오.
1.3.1.2. OpenShift Container Platform 설치 확인
레지스트리 및 스토리지 서비스를 포함하여 지원되는 OpenShift Container Platform 버전이 설치되어 작동해야 합니다. OpenShift Container Platform 설치에 대한 자세한 내용은 OpenShift Container Platform 설명서를 참조하십시오.
- 다중 클러스터 엔진 Operator가 OpenShift Container Platform 클러스터에 아직 설치되지 않았는지 확인합니다. 다중 클러스터 엔진 Operator는 각 OpenShift Container Platform 클러스터에서 하나의 단일 설치만 허용합니다. 설치가 없는 경우 다음 단계를 계속 진행합니다.
OpenShift Container Platform 클러스터가 올바르게 설정되었는지 확인하려면 다음 명령을 사용하여 OpenShift Container Platform 웹 콘솔에 액세스합니다.
kubectl -n openshift-console get route console
다음 예제 출력을 참조하십시오.
console console-openshift-console.apps.new-coral.purple-chesterfield.com console https reencrypt/Redirect None
-
브라우저에서 URL을 열고 결과를 확인합니다. 콘솔 URL에
console-openshift-console.router.default.svc.cluster.local
이 표시되면 OpenShift Container Platform을 설치할 때openshift_master_default_subdomain
값을 설정합니다. URL의 다음 예제를 참조하십시오.https://console-openshift-console.apps.new-coral.purple-chesterfield.com
.
다중 클러스터 엔진 Operator 설치를 진행할 수 있습니다.
1.3.1.3. OperatorHub 웹 콘솔 인터페이스에서 설치
모범 사례: OpenShift Container Platform 탐색의 관리자 보기에서 OpenShift Container Platform과 함께 제공되는 OperatorHub 웹 콘솔 인터페이스를 설치합니다.
- Operator > OperatorHub 를 선택하여 사용 가능한 Operator 목록에 액세스하고 Kubernetes Operator의 다중 클러스터 엔진을 선택합니다.
-
설치를
클릭합니다. Operator 설치 페이지에서 설치 옵션을 선택합니다.
namespace:
- 다중 클러스터 엔진 Operator 엔진은 자체 네임스페이스 또는 프로젝트에 설치해야 합니다.
-
기본적으로 OperatorHub 콘솔 설치 프로세스는
multicluster-engine
이라는 네임스페이스를 생성합니다. 모범 사례: 사용 가능한 경우multicluster-engine
네임스페이스를 계속 사용합니다. -
이미
multicluster-engine
이라는 네임스페이스가 있는 경우 다른 네임스페이스를 선택합니다.
- 채널: 선택한 채널은 설치 중인 릴리스에 해당합니다. 채널을 선택하면 식별된 릴리스를 설치하고 해당 릴리스 내에서 향후 에라타가 업데이트되도록 설정합니다.
승인 전략: 승인 전략은 서브스크립션한 채널 또는 릴리스에 업데이트를 적용하는 데 필요한 인적 상호 작용을 식별합니다.
- 기본적으로 선택한 자동 을 선택하여 해당 릴리스 내의 업데이트가 자동으로 적용되도록 합니다.
- 업데이트를 사용할 수 있을 때 알림을 받으려면 수동 을 선택합니다. 업데이트가 적용되는 시기에 대해 우려 사항이 있는 경우 이 방법을 사용하는 것이 좋습니다.
참고: 다음 마이너 릴리스로 업그레이드하려면 OperatorHub 페이지로 돌아가서 최신 릴리스의 새 채널을 선택해야 합니다.
- 설치를 선택하여 변경 사항을 적용하고 Operator를 생성합니다.
MultiClusterEngine 사용자 정의 리소스를 생성하려면 다음 프로세스를 참조하십시오.
- OpenShift Container Platform 콘솔 탐색에서 Installed Operators > multicluster engine for Kubernetes 를 선택합니다.
- MultiCluster Engine 탭을 선택합니다.
- Create MultiClusterEngine 을 선택합니다.
YAML 파일에서 기본값을 업데이트합니다. 문서의 MultiClusterEngine 고급 구성 섹션의 옵션을 참조하십시오.
- 다음 예제에서는 편집기에 복사할 수 있는 기본 템플릿을 보여줍니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: {}
생성 을 선택하여 사용자 지정 리소스를 초기화합니다. 다중 클러스터 엔진 Operator 엔진을 빌드하고 시작하는 데 최대 10분이 걸릴 수 있습니다.
MultiClusterEngine 리소스가 생성되면 MultiCluster Engine 탭에서 리소스 상태가
Available
(사용 가능)입니다.
1.3.1.4. OpenShift Container Platform CLI에서 설치
Operator 요구 사항이 포함된 다중 클러스터 엔진 Operator 엔진 네임스페이스를 생성합니다. 다음 명령을 실행합니다. 여기서
namespace
는 Kubernetes Operator 네임스페이스의 다중 클러스터 엔진의 이름입니다.namespace
값은 OpenShift Container Platform 환경에서 Project 라고 할 수 있습니다.oc create namespace <namespace>
프로젝트 네임스페이스를 생성한 네임스페이스로 전환합니다. 1단계에서 생성한 Kubernetes Operator 네임스페이스의 다중 클러스터 엔진 이름으로
namespace
를 바꿉니다.oc project <namespace>
YAML 파일을 생성하여
OperatorGroup
리소스를 구성합니다. 각 네임스페이스에는 하나의 operator 그룹만 있을 수 있습니다.default
를 operator 그룹의 이름으로 바꿉니다.namespace
를 프로젝트 네임스페이스의 이름으로 교체합니다. 다음 예제를 참조하십시오.apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <default> namespace: <namespace> spec: targetNamespaces: - <namespace>
다음 명령을 실행하여
OperatorGroup
리소스를 생성합니다.operator-group
을 생성한 operator 그룹 YAML 파일의 이름으로 교체합니다.oc apply -f <path-to-file>/<operator-group>.yaml
YAML 파일을 생성하여 OpenShift Container Platform 서브스크립션을 구성합니다. 파일은 다음 예와 유사해야 합니다.
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: multicluster-engine spec: sourceNamespace: openshift-marketplace source: redhat-operators channel: stable-2.5 installPlanApproval: Automatic name: multicluster-engine
참고: 인프라 노드에 Kubernetes Operator용 다중 클러스터 엔진을 설치하려면 Operator Lifecycle Manager 서브스크립션 추가 구성 섹션을 참조하십시오.
다음 명령을 실행하여 OpenShift Container Platform 서브스크립션을 생성합니다.
서브스크립션
을 생성한 서브스크립션 파일의 이름으로 교체합니다.oc apply -f <path-to-file>/<subscription>.yaml
YAML 파일을 생성하여
MultiClusterEngine
사용자 정의 리소스를 구성합니다. 기본 템플릿은 다음 예와 유사해야 합니다.apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: {}
참고: 인프라 노드에 다중 클러스터 엔진 Operator를 설치하는 경우 MultiClusterEngine 사용자 정의 리소스 추가 구성 섹션을 참조하십시오.
다음 명령을 실행하여
MultiClusterEngine
사용자 정의 리소스를 생성합니다.custom-resource
를 사용자 정의 리소스 파일의 이름으로 교체합니다.oc apply -f <path-to-file>/<custom-resource>.yaml
다음 오류와 함께 이 단계가 실패하면 리소스가 계속 생성되고 적용됩니다. 리소스가 생성될 때 몇 분 후에 명령을 다시 실행합니다.
error: unable to recognize "./mce.yaml": no matches for kind "MultiClusterEngine" in version "operator.multicluster-engine.io/v1"
다음 명령을 실행하여 사용자 정의 리소스를 가져옵니다. 다음 명령을 실행한 후
MultiClusterEngine
사용자 정의 리소스 상태가Available
으로 Available로 표시되는 데 최대 10분이 걸릴 수 있습니다.
oc get mce -o=jsonpath='{.items[0].status.phase}'
다중 클러스터 엔진 Operator를 다시 설치하고 Pod가 시작되지 않는 경우 이 문제를 해결하기 위한 단계의 재생성 문제 해결을 참조하십시오.
참고:
-
ClusterRoleBinding
이 있는ServiceAccount
는 다중 클러스터 엔진 Operator 및 다중 클러스터 엔진 Operator를 설치하는 네임스페이스에 대한 액세스 권한이 있는 모든 사용자 인증 정보에 자동으로 클러스터 관리자 권한을 부여합니다.
1.3.1.5. 인프라 노드에 설치
OpenShift Container Platform 클러스터는 승인된 관리 구성 요소를 실행하기 위한 인프라 노드를 포함하도록 구성할 수 있습니다. 인프라 노드에서 구성 요소를 실행하면 해당 관리 구성 요소를 실행하는 노드에 OpenShift Container Platform 서브스크립션 할당량이 할당되지 않습니다.
OpenShift Container Platform 클러스터에 인프라 노드를 추가한 후 OpenShift Container Platform CLI에서 설치 지침을 따르고 Operator Lifecycle Manager 서브스크립션 및 MultiClusterEngine
사용자 정의 리소스에 다음 구성을 추가합니다.
1.3.1.5.1. OpenShift Container Platform 클러스터에 인프라 노드 추가
OpenShift Container Platform 설명서에서 인프라 머신 세트 생성에 설명된 절차를 따르십시오. 인프라 노드는 관리되지 않은 워크로드가 해당 워크로드가 실행되지 않도록 Kubernetes taint
및 레이블
로 구성됩니다.
다중 클러스터 엔진 Operator에서 제공하는 인프라 노드 활성화와 호환되려면 인프라 노드에 다음과 같은 테인트
및 라벨이
적용되어야 합니다.
metadata: labels: node-role.kubernetes.io/infra: "" spec: taints: - effect: NoSchedule key: node-role.kubernetes.io/infra
1.3.1.5.2. Operator Lifecycle Manager 서브스크립션 추가 구성
Operator Lifecycle Manager 서브스크립션을 적용하기 전에 다음 추가 구성을 추가합니다.
spec: config: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra effect: NoSchedule operator: Exists
1.3.1.5.3. MultiClusterEngine 사용자 정의 리소스 추가 구성
MultiClusterEngine
사용자 정의 리소스를 적용하기 전에 다음 추가 구성을 추가합니다.
spec: nodeSelector: node-role.kubernetes.io/infra: ""
1.3.2. 연결이 끊긴 네트워크에 설치
인터넷에 연결되지 않은 Red Hat OpenShift Container Platform 클러스터에 다중 클러스터 엔진 Operator를 설치해야 할 수 있습니다. 연결이 끊긴 엔진에 설치하려면 연결된 설치와 동일한 단계가 필요합니다.
중요: 두 제품에서 동일한 관리 구성 요소를 제공하므로 Red Hat Advanced Cluster Management가 설치되지 않은 클러스터에 다중 클러스터 엔진 Operator를 설치합니다. 이전에 Red Hat Advanced Cluster Management를 설치하지 않은 클러스터에 다중 클러스터 엔진 Operator를 설치합니다. Red Hat Advanced Cluster Management 버전 2.5.0 이상을 사용하는 경우 다중 클러스터 엔진 Operator가 클러스터에 이미 설치되어 있습니다.
설치 중에 네트워크에서 직접 액세스하는 대신 설치 중에 패키지 사본을 다운로드하여 설치 중에 액세스해야 합니다.
1.3.2.1. 사전 요구 사항
다중 클러스터 엔진 Operator를 설치하기 전에 다음 요구 사항을 충족해야 합니다.
- Red Hat OpenShift Container Platform 버전 4.13 이상을 환경에 배포해야 하며 CLI(명령줄 인터페이스)를 사용하여 로그인해야 합니다.
catalog.redhat.com 에 액세스해야 합니다.
참고: 베어 메탈 클러스터를 관리하려면 OpenShift Container Platform 버전 4.13 이상이 있어야 합니다.
-
Red Hat OpenShift Container Platform CLI는 버전 4.13 이상이어야 하며
oc
명령을 실행하도록 구성해야 합니다. - Red Hat OpenShift Container Platform 권한에서 네임스페이스를 생성할 수 있도록 허용해야 합니다.
- Operator에 대한 종속성을 다운로드하려면 인터넷 연결이 있는 워크스테이션이 있어야 합니다.
1.3.2.2. OpenShift Container Platform 설치 확인
- 레지스트리 및 스토리지 서비스를 포함하여 지원되는 OpenShift Container Platform 버전이 클러스터에 설치되어 작동해야 합니다. OpenShift Container Platform 버전 4.13에 대한 자세한 내용은 OpenShift Container Platform 설명서를 참조하십시오.
연결된 경우 다음 명령을 사용하여 OpenShift Container Platform 웹 콘솔에 액세스하여 OpenShift Container Platform 클러스터가 올바르게 설정되었는지 확인할 수 있습니다.
kubectl -n openshift-console get route console
다음 예제 출력을 참조하십시오.
console console-openshift-console.apps.new-coral.purple-chesterfield.com console https reencrypt/Redirect None
이 예제의 콘솔 URL은
https:// console-openshift-console.apps.new-coral.purple-chesterfield.com
입니다. 브라우저에서 URL을 열고 결과를 확인합니다.콘솔 URL에
console-openshift-console.router.default.svc.cluster.local
이 표시되면 OpenShift Container Platform을 설치할 때openshift_master_default_subdomain
값을 설정합니다.
1.3.2.3. 연결이 끊긴 환경에 설치
중요: 연결이 끊긴 환경에서 Operator를 설치하려면 필요한 이미지를 미러링 레지스트리에 다운로드해야 합니다. 다운로드하지 않으면 배포 중에 ImagePullBackOff
오류가 표시될 수 있습니다.
다음 단계에 따라 연결이 끊긴 환경에 다중 클러스터 엔진 Operator를 설치합니다.
미러 레지스트리를 생성합니다. 미러 레지스트리가 아직 없는 경우 Red Hat OpenShift Container Platform 설명서의 연결 해제 설치 미러링 주제에서 절차를 완료하여 하나의 레지스트리를 생성합니다.
미러 레지스트리가 이미 있는 경우 기존 레지스트리를 구성하고 사용할 수 있습니다.
참고: 베어 메탈의 경우
install-config.yaml
파일에서 연결이 끊긴 레지스트리에 대한 인증서 정보를 제공해야 합니다. 보호된 연결이 끊긴 레지스트리에서 이미지에 액세스하려면 다중 클러스터 엔진 운영자가 레지스트리에 액세스할 수 있도록 인증서 정보를 제공해야 합니다.- 레지스트리에서 인증서 정보를 복사합니다.
-
편집기에서
install-config.yaml
파일을 엽니다. -
additionalTrustBundle: |
의 항목을 찾습니다. additionalTrustBundle
줄 뒤에 인증서 정보를 추가합니다. 결과 콘텐츠는 다음 예와 유사해야 합니다.additionalTrustBundle: | -----BEGIN CERTIFICATE----- certificate_content -----END CERTIFICATE----- sshKey: >-
중요: 다음 Governance 정책이 필요한 경우 연결이 끊긴 이미지 레지스트리에 대한 추가 미러가 필요합니다.
-
Container Security Operator 정책:
registry.redhat.io/quay
소스의 이미지를 찾습니다. -
Compliance Operator 정책:
registry.redhat.io/compliance
소스의 이미지를 찾습니다. Gatekeeper Operator 정책:
registry.redhat.io/gatekeeper
소스에 이미지를 찾습니다.세 가지 연산자 모두에 대한 미러 목록의 다음 예제를 참조하십시오.
- mirrors: - <your_registry>/rhacm2 source: registry.redhat.io/rhacm2 - mirrors: - <your_registry>/quay source: registry.redhat.io/quay - mirrors: - <your_registry>/compliance source: registry.redhat.io/compliance
-
Container Security Operator 정책:
-
install-config.yaml
파일을 저장합니다. mce-policy.yaml
이라는 이름으로ImageContentSourcePolicy
가 포함된 YAML 파일을 생성합니다. 참고: 실행 중인 클러스터에서 이 값을 수정하면 모든 노드가 롤링 재시작됩니다.apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: mce-repo spec: repositoryDigestMirrors: - mirrors: - mirror.registry.com:5000/multicluster-engine source: registry.redhat.io/multicluster-engine
다음 명령을 입력하여 ImageContentSourcePolicy 파일을 적용합니다.
oc apply -f mce-policy.yaml
연결이 끊긴 Operator Lifecycle Manager Red Hat Operator 및 Community Operator를 활성화합니다.
멀티 클러스터 엔진 Operator는 Operator Lifecycle Manager Red Hat Operator 카탈로그에 포함되어 있습니다.
- Red Hat Operator 카탈로그에 대해 연결이 끊긴 Operator Lifecycle Manager를 구성합니다. Red Hat OpenShift Container Platform 설명서의 제한된 네트워크에서 Operator Lifecycle Manager 사용 주제의 단계를 따르십시오.
- 이제 연결이 끊긴 Operator Lifecycle Manager에 이미지가 있으므로 Operator Lifecycle Manager 카탈로그에서 Kubernetes용 다중 클러스터 엔진 Operator를 계속 설치합니다.
필요한 단계는 온라인에 연결된 동안 설치를 참조하십시오.
1.3.3. 고급 구성
다중 클러스터 엔진 Operator는 필요한 모든 구성 요소를 배포하는 Operator를 사용하여 설치됩니다. 멀티 클러스터 엔진 Operator는 설치 중 또는 설치 후 추가로 구성할 수 있습니다. 고급 구성 옵션에 대해 자세히 알아보십시오.
1.3.3.1. 배포된 구성 요소
MultiClusterEngine
사용자 정의 리소스에 다음 속성 중 하나 이상을 추가합니다.
이름 | 설명 | 활성화됨 |
assisted-service | 최소한의 인프라 사전 요구 사항 및 포괄적인 사전 요구 사항으로 OpenShift Container Platform 설치 | True |
cluster-lifecycle | OpenShift Container Platform 및 Kubernetes 허브 클러스터를 위한 클러스터 관리 기능 제공 | True |
cluster-manager | 클러스터 환경 내에서 다양한 클러스터 관련 작업 관리 | True |
cluster-proxy-addon |
역방향 프록시 서버를 사용하여 허브 및 관리 클러스터에 | True |
console-mce | 다중 클러스터 엔진 Operator 콘솔 플러그인 활성화 | True |
discovery | OpenShift Cluster Manager 내에서 새 클러스터를 검색하고 식별합니다. | True |
Hive | OpenShift Container Platform 클러스터의 초기 구성 프로비저닝 및 수행 | True |
hypershift | 비용 및 시간 효율성과 클라우드 간 이식성으로 규모에 맞게 OpenShift Container Platform 컨트롤 플레인 호스트 | True |
hypershift-local-hosting | 로컬 클러스터 환경 내의 로컬 호스팅 기능 활성화 | True |
local-cluster | 다중 클러스터 엔진 Operator가 배포된 로컬 허브 클러스터의 가져오기 및 자체 관리를 활성화합니다. | True |
managedserviceacccount | 서비스 계정을 관리 클러스터에 동기화하고 Hub 클러스터로 토큰을 다시 시크릿 리소스로 수집 | False |
server-foundation | 다중 클러스터 환경 내에서 서버 측 작업에 대한 기본 서비스 제공 | True |
다중 클러스터 엔진 Operator를 클러스터에 설치할 때 나열된 모든 구성 요소가 기본적으로 활성화되어 있는 것은 아닙니다.
MultiClusterEngine
사용자 정의 리소스에 하나 이상의 속성을 추가하여 설치 중 또는 설치 후 다중 클러스터 엔진 Operator를 추가로 구성할 수 있습니다. 추가할 수 있는 속성에 대한 정보를 계속 읽습니다.
1.3.3.2. 콘솔 및 구성 요소 구성
다음 예제는 구성 요소를 활성화하거나 비활성화하는 데 사용할 수 있는 spec.overrides
기본 템플릿을 표시합니다.
apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterEngine
metadata:
name: multiclusterengine
spec:
overrides:
components:
- name: <name> 1
enabled: true
-
name
을 구성 요소의 이름으로 바꿉니다.
또는 다음 명령을 실행할 수 있습니다. namespace
를 프로젝트 및 name
의 이름으로 구성 요소 이름으로 교체합니다.
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"<name>","enabled":true}}]'
1.3.3.3. local-cluster 활성화
기본적으로 다중 클러스터 엔진 Operator를 실행하는 클러스터는 자체적으로 관리합니다. 클러스터 관리 자체 없이 다중 클러스터 엔진 Operator를 설치하려면 MultiClusterEngine
섹션의 spec.overrides.components
설정에 다음 값을 지정합니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: local-cluster enabled: false
-
name
값은 hub 클러스터를local-cluster
로 식별합니다. -
enabled
설정은 기능이 활성화되어 있는지 여부를 지정합니다. 값이true
이면 hub 클러스터는 자체적으로 관리합니다. 값이false
이면 hub 클러스터에서 자체적으로 관리하지 않습니다.
자체적으로 관리하는 허브 클러스터는 클러스터 목록에서 local-cluster
로 지정됩니다.
1.3.3.4. 사용자 정의 이미지 풀 시크릿
OpenShift Container Platform 또는 다중 클러스터 엔진 Operator에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 배포 레지스트리에서 권한이 있는 콘텐츠에 액세스하기 위해 OpenShift Container Platform pull secret 정보가 포함된 시크릿을 생성합니다.
OpenShift Container Platform 클러스터의 시크릿 요구 사항은 Kubernetes Operator의 OpenShift Container Platform 및 다중 클러스터 엔진에서 자동으로 해결되므로 관리할 다른 유형의 Kubernetes 클러스터를 가져오지 않는 경우 시크릿을 생성할 필요가 없습니다.
중요: 이러한 시크릿은 네임스페이스에 고유하므로 엔진에 사용하는 네임스페이스에 있는지 확인합니다.
- 풀 시크릿 다운로드를 선택하여 cloud.redhat.com/openshift/install/pull-secret 에서 OpenShift Container Platform 풀 시크릿 파일을 다운로드합니다. OpenShift Container Platform 풀 시크릿은 Red Hat Customer Portal ID와 연결되며 모든 Kubernetes 공급자에서 동일합니다.
다음 명령을 실행하여 보안을 생성합니다.
oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
-
secret
을 생성하려는 시크릿 이름으로 교체합니다. -
시크릿은
네임스페이스에
따라 네임스페이스를 사용하므로 네임스페이스를 프로젝트 네임스페이스로 교체합니다. -
다운로드한 OpenShift Container Platform 풀 시크릿의 경로로
path-to-pull-secret
을 교체합니다.
-
다음 예제는 사용자 정의 풀 시크릿을 사용하려는 경우 사용할 spec.imagePullSecret
템플릿을 표시합니다. secret
을 풀 시크릿 이름으로 교체합니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: imagePullSecret: <secret>
1.3.3.5. 대상 네임스페이스
피연산자는 MultiClusterEngine
사용자 정의 리소스에 위치를 지정하여 지정된 네임스페이스에 설치할 수 있습니다. 이 네임스페이스는 MultiClusterEngine
사용자 정의 리소스의 애플리케이션 시 생성됩니다.
중요: 대상 네임스페이스를 지정하지 않으면 Operator는 multicluster-engine
네임스페이스에 설치하고 MultiClusterEngine
사용자 정의 리소스 사양에 설정합니다.
다음 예제는 대상 네임스페이스를 지정하는 데 사용할 수 있는 spec.targetNamespace
템플릿을 표시합니다. target
을 대상 네임스페이스의 이름으로 교체합니다. 참고: 대상
네임스페이스는 기본
네임스페이스가 될 수 없습니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: targetNamespace: <target>
1.3.3.6. availabilityConfig
hub 클러스터에는 High
및 Basic
이라는 두 가지 가능성이 있습니다. 기본적으로 허브 클러스터의 가용성은 High
이며 hub 클러스터 구성 요소에 2
의 replicaCount
를 제공합니다. 이는 장애 조치의 경우 더 나은 지원을 제공하지만 기본
가용성보다 많은 리소스를 사용하므로 구성 요소에 1
의 replicaCount
가 제공됩니다.
중요: 단일 노드 OpenShift 클러스터에서 다중 클러스터 엔진 Operator를 사용하는 경우 spec.availabilityConfig
를 Basic
으로 설정합니다.
다음 예제에서는 기본
가용성이 있는 spec.availabilityConfig
템플릿을 보여줍니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: availabilityConfig: "Basic"
1.3.3.7. nodeSelector
클러스터의 특정 노드에 설치할 MultiClusterEngine
에서 노드 선택기 세트를 정의할 수 있습니다. 다음 예제에서는 node-role.kubernetes.io/infra
: 레이블이 있는 노드에 Pod를 할당하는 spec.nodeSelector
를 보여줍니다.
spec: nodeSelector: node-role.kubernetes.io/infra: ""
1.3.3.8. 허용 오차
허용 오차 목록을 정의하여 MultiClusterEngine
이 클러스터에 정의된 특정 테인트를 허용할 수 있습니다. 다음 예제는 node-role.kubernetes.io/infra
테인트와 일치하는 spec.tolerations
를 보여줍니다.
spec: tolerations: - key: node-role.kubernetes.io/infra effect: NoSchedule operator: Exists
이전 infra-node 허용 오차는 구성에 허용 오차를 지정하지 않고 기본적으로 Pod에 설정됩니다. 구성에서 허용 오차를 사용자 정의하면 이 기본 동작이 대체됩니다.
1.3.3.9. ManagedServiceAccount 애드온
ManagedServiceAccount
애드온을 사용하면 관리 클러스터에서 서비스 계정을 생성하거나 삭제할 수 있습니다. 이 애드온을 사용하여 설치하려면 spec.overrides
의 MultiClusterEngine
사양에 다음을 포함합니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: managedserviceaccount enabled: true
명령줄에서 리소스를 편집하고 managedserviceaccount
구성 요소를 enabled: true
로 설정하여 ManagedServiceAccount
애드온을 MultiClusterEngine
을 생성한 후 활성화할 수 있습니다. 또는 다음 명령을 실행하고 <multiclusterengine-name>을 MultiClusterEngine
리소스의 이름으로 교체할 수 있습니다.
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount","enabled":true}}]'
1.3.4. 설치 제거
Kubernetes Operator에 대한 다중 클러스터 엔진을 설치 제거할 때 프로세스의 두 가지 수준인 사용자 정의 리소스 제거 및 전체 Operator 설치 제거가 표시됩니다. 제거 프로세스를 완료하는 데 최대 5분이 걸릴 수 있습니다.
-
사용자 정의 리소스 제거는
MultiClusterEngine
인스턴스의 사용자 정의 리소스를 제거하지만 다른 필요한 Operator 리소스를 제거하는 가장 기본적인 유형의 설치 제거입니다. 이 설치 제거 수준은 동일한 설정 및 구성 요소를 사용하여 다시 설치하려는 경우 유용합니다. - 두 번째 수준은 사용자 정의 리소스 정의와 같은 구성 요소를 제외하고 대부분의 Operator 구성 요소를 제거하는 더 완전한 제거 사항입니다. 이 단계를 계속할 때 사용자 정의 리소스 제거와 함께 제거되지 않은 모든 구성 요소 및 서브스크립션을 제거합니다. 이 제거 후 사용자 정의 리소스를 다시 설치하기 전에 Operator를 다시 설치해야 합니다.
1.3.4.1. 사전 요구 사항: 사용 가능한 서비스 분리
Kubernetes Operator용 다중 클러스터 엔진을 제거하기 전에 해당 엔진에서 관리하는 모든 클러스터를 분리해야 합니다. 오류를 방지하려면 엔진에서 계속 관리하는 모든 클러스터를 분리한 다음 다시 제거하십시오.
관리 클러스터가 연결되어 있는 경우 다음 메시지가 표시될 수 있습니다.
Cannot delete MultiClusterEngine resource because ManagedCluster resource(s) exist
클러스터 분리에 대한 자세한 내용은 클러스터 생성 소개에서 공급자의 정보를 선택하여 관리에서 클러스터 제거 섹션을 참조하십시오.
1.3.4.2. 명령을 사용하여 리소스 제거
-
아직 설치되지 않은 경우 OpenShift Container Platform CLI가
oc
명령을 실행하도록 구성되어 있는지 확인합니다.oc
명령 구성에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 OpenShift CLI 시작하기 를 참조하십시오. 다음 명령을 입력하여 프로젝트 네임스페이스로 변경합니다. namespace 를 프로젝트 네임스페이스의 이름으로 교체합니다.
oc project <namespace>
다음 명령을 입력하여
MultiClusterEngine
사용자 정의 리소스를 제거합니다.oc delete multiclusterengine --all
다음 명령을 입력하여 진행 상황을 볼 수 있습니다.
oc get multiclusterengine -o yaml
-
설치된 네임스페이스에서 다중 클러스터 엔진
ClusterServiceVersion
을 삭제하려면 다음 명령을 입력합니다.
❯ oc get csv NAME DISPLAY VERSION REPLACES PHASE multicluster-engine.v2.0.0 multicluster engine for Kubernetes 2.0.0 Succeeded ❯ oc delete clusterserviceversion multicluster-engine.v2.0.0 ❯ oc delete sub multicluster-engine
여기에 표시된 CSV 버전은 다를 수 있습니다.
1.3.4.3. 콘솔을 사용하여 구성 요소 삭제
RedHat OpenShift Container Platform 콘솔을 사용하여 설치 제거할 때 Operator를 제거합니다. 콘솔을 사용하여 설치 제거하려면 다음 단계를 완료합니다.
- OpenShift Container Platform 콘솔 탐색에서 Operator > 설치된 Operator > Kubernetes용 멀티 클러스터 엔진을 선택합니다.
MultiClusterEngine
사용자 정의 리소스를 제거합니다.- Multiclusterengine 의 탭을 선택합니다.
- MultiClusterEngine 사용자 정의 리소스의 옵션 메뉴를 선택합니다.
- MultiClusterEngine 삭제를 선택합니다.
다음 섹션의 절차에 따라 정리 스크립트를 실행합니다.
팁: Kubernetes Operator 버전에 대해 동일한 다중 클러스터 엔진을 다시 설치하려는 경우 이 절차의 나머지 단계를 건너뛰고 사용자 정의 리소스를 다시 설치할 수 있습니다.
- 설치된 Operator로 이동합니다.
- 옵션 메뉴를 선택하고 Uninstall operator 를 선택하여 Kubernetes_ operator의 _ 다중 클러스터 엔진을 제거합니다.
1.3.4.4. 문제 해결 설치 제거
다중 클러스터 엔진 사용자 정의 리소스가 제거되지 않는 경우 정리 스크립트를 실행하여 나머지 아티팩트를 제거합니다.
다음 스크립트를 파일에 복사합니다.
#!/bin/bash oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io oc delete validatingwebhookconfiguration multiclusterengines.multicluster.openshift.io oc delete mce --all
자세한 내용은 Disconnected installation mirroring 에서 참조하십시오.
1.3.5. Red Hat Advanced Cluster Management 통합
Red Hat Advanced Cluster Management가 활성화된 다중 클러스터 엔진 Operator를 사용하는 경우 추가 멀티 클러스터 관리 기능을 활용할 수 있습니다.
1.3.5.1. 사전 요구 사항
Red Hat Advanced Cluster Management 기능과 통합하려면 다음 사전 요구 사항을 참조하십시오.
- Red Hat Advanced Cluster Management를 설치해야 합니다. 설치하려면 설치 및 업그레이드 를 참조하십시오.
1.3.5.2. 관찰 기능 통합
multicluster-observability
Pod를 활성화한 후 Red Hat Advanced Cluster Management Observability Grafana 대시보드를 사용하여 호스팅된 컨트롤 플레인에 대한 다음 정보를 볼 수 있습니다.
- ACM > 호스팅 컨트롤 플레인 개요 대시보드를 통해 호스팅되는 컨트롤 플레인, 관련 클러스터 리소스 및 기존 호스팅 컨트롤 플레인의 목록 및 상태에 대한 클러스터 용량 추정치를 확인할 수 있습니다.
- ACM > 리소스 > 개요 페이지에서 액세스할 수 있는 호스팅된 컨트롤 플레인 대시보드를 통해 선택한 호스팅 컨트롤 플레인의 리소스 사용률을 확인할 수 있습니다.
활성화하려면 Observability 서비스 소개 를 참조하십시오.
1.4. 인증 정보 관리
다중 클러스터 엔진 Operator가 있는 클라우드 서비스 공급자에서 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다. 자격 증명은 클라우드 공급자의 액세스 정보를 저장합니다. 각 공급자 계정에는 단일 공급자의 각 도메인과 마찬가지로 자체 인증 정보가 필요합니다.
클러스터 인증 정보를 생성하고 관리할 수 있습니다. 인증 정보는 Kubernetes 시크릿으로 저장됩니다. 관리 클러스터의 컨트롤러에서 시크릿에 액세스할 수 있도록 보안이 관리되는 클러스터의 네임스페이스에 복사됩니다. 인증 정보가 업데이트되면 관리 클러스터 네임스페이스에서 시크릿 복사본이 자동으로 업데이트됩니다.
참고: 클라우드 공급자 인증 정보의 풀 시크릿, SSH 키 또는 기본 도메인에 대한 변경 사항은 기존 관리 클러스터에 반영되지 않습니다. 원래 인증 정보를 사용하여 이미 프로비저닝되었기 때문입니다.
필요한 액세스: 편집
1.4.1. Amazon Web Services의 인증 정보 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 AWS(Amazon Web Services)에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 인증 정보가 필요합니다.
필요한 액세스: 편집
참고: 다중 클러스터 엔진 Operator를 사용하여 클러스터를 생성하려면 이 절차를 수행해야 합니다.
1.4.1.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 배포된 다중 클러스터 엔진 Operator 허브 클러스터
- 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스를 통해 AWS(Amazon Web Services)에서 Kubernetes 클러스터를 생성할 수 있습니다.
- AWS 로그인 인증 정보: 액세스 키 ID 및 시크릿 액세스 키가 포함됩니다. 보안 인증 정보 이해 및 가져오기를 참조하십시오.
- AWS에 클러스터를 설치할 수 있는 계정 권한 AWS 계정 구성 방법에 대한 지침은 AWS 계정 구성을 참조하십시오.
1.4.1.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.
선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. 다음 단계를 참조하십시오.
- AWS 계정의 AWS 액세스 키 ID 를 추가합니다. ID 를 찾으려면 AWS 에 로그인을 참조하십시오.
- 새 AWS Secret Access 키 의 콘텐츠를 제공합니다.
프록시를 활성화하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및HTTPS
모두에HTTP
프록시 URL -
프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다
.
를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
-
HTTP 프록시 URL:
- Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
- 클러스터에 연결할 수 있는 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램으로 새 키 쌍을 만들 수 있습니다.
Amazon Web Services에서 클러스터 생성 또는 Amazon Web Services GovCloud에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다. 이 공급자 연결을 사용하여 클러스터가 생성된 경우 < cluster-
> 시크릿이 새 인증 정보로 업데이트됩니다.
namespace>의 <cluster-name>-aws-
creds
참고: 인증 정보를 업데이트해도 클러스터 풀 클레임 클러스터에서는 작동하지 않습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.4.1.2.1. S3 시크릿 생성
Amazon S3(Simple Storage Service) 시크릿을 생성하려면 콘솔에서 다음 작업을 완료합니다.
- Add credential > AWS > S3 Bucket 을 클릭합니다. For Hosted Control Plane 을 클릭하면 이름과 네임스페이스가 제공됩니다.
제공된 다음 필드에 대한 정보를 입력합니다.
-
bucket name
: S3 버킷의 이름을 추가합니다. -
AWS
_ACCESS_KEY_ID
: AWS 계정의 AWS 액세스 키 ID를 추가합니다. AWS에 로그인하여 ID를 찾습니다. -
AWS
_SECRET_ACCESS_KEY
: 새로운 AWS Secret Access 키의 콘텐츠를 제공합니다. -
리전
: AWS 리전을 입력합니다.
-
1.4.1.3. API를 사용하여 불투명 보안 생성
API를 사용하여 Amazon Web Services에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다.
kind: Secret metadata: name: <managed-cluster-name>-aws-creds namespace: <managed-cluster-namespace> type: Opaque data: aws_access_key_id: $(echo -n "${AWS_KEY}" | base64 -w0) aws_secret_access_key: $(echo -n "${AWS_SECRET}" | base64 -w0)
참고:
- 불투명한 시크릿은 콘솔에 표시되지 않습니다.
- opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
-
인증 정보에 라벨을 추가하여 콘솔에서 시크릿을 확인합니다. 예를 들어 다음 AWS S3 Bucket
oc 레이블 시크릿에
는type=awss3
및인증 정보 --from-file=…이 추가됩니다.
oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster "cluster.open-cluster-management.io/type=awss3" oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster "cluster.open-cluster-management.io/credentials=credentials="
1.4.1.4. 추가 리소스
- 보안 인증 정보 이해 및 가져오기를 참조하십시오.
- AWS 계정 구성을 참조하십시오.
- AWS에 로그인합니다.
- Red Hat OpenShift 풀 시크릿을 다운로드합니다.
- 키를 생성하는 방법에 대한 자세한 내용은 클러스터 노드 SSH 액세스에 대한 키 쌍 생성을 참조하십시오.
- Amazon Web Services에서 클러스터 생성 을 참조하십시오.
- Amazon Web Services GovCloud에서 클러스터 생성 을 참조하십시오.
- Amazon Web Services의 인증 정보 생성 으로 돌아갑니다.
1.4.2. Microsoft Azure에 대한 인증 정보 생성
Microsoft Azure 또는 Microsoft Azure Government에서 다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다.
필요한 액세스: 편집
참고: 이 절차는 다중 클러스터 엔진 Operator가 있는 클러스터를 생성하기 위한 사전 요구 사항입니다.
1.4.2.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 배포된 다중 클러스터 엔진 Operator 허브 클러스터입니다.
- Azure에서 Kubernetes 클러스터를 생성할 수 있도록 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스
- 기본 도메인 리소스 그룹 및 Azure 서비스 주체 JSON을 포함하는 Azure 로그인 자격 증명입니다. 로그인 인증 정보를 얻으려면 Microsoft Azure Portal 을 참조하십시오.
- Azure에 클러스터를 설치할 수 있는 계정 권한 자세한 내용은 클라우드 서비스 구성 및 Azure 계정 구성을 참조하십시오.
1.4.2.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다. 탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.
- 선택 사항: 인증 정보에 대한 기본 DNS 도메인 을 추가합니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다.
-
클러스터의 환경이
AzurePublicCloud
또는AzureUSGovernmentCloud
인지 여부를 선택합니다. Azure Government 환경에 대해 설정이 다르므로 이 설정이 올바르게 설정되어 있는지 확인합니다. - Azure 계정에 대한 기본 도메인 리소스 그룹 이름을 추가합니다. 이 항목은 Azure 계정으로 생성한 리소스 이름입니다. Azure 인터페이스에서 홈 > DNS 영역을 선택하여 기본 도메인 리소스 그룹 이름을 찾을 수 있습니다. Azure CLI를 사용하여 Azure 서비스 주체 생성 을 참조하여 기본 도메인 리소스 그룹 이름을 찾습니다.
클라이언트 ID 의 콘텐츠를 제공합니다. 이 값은 다음 명령을 사용하여 서비스 주체를 생성할 때
appId
속성으로 생성됩니다.az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>
service_principal 을 서비스 주체의 이름으로 교체합니다.
클라이언트 시크릿 을 추가합니다. 이 값은 다음 명령을 사용하여 서비스 주체를 생성할 때
password
속성으로 생성됩니다.az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>
service_principal 을 서비스 주체의 이름으로 교체합니다.
서브스크립션 ID 를 추가합니다. 이 값은 다음 명령의 출력에 있는
id
속성입니다.az account show
테넌트 ID 를 추가합니다. 이 값은 다음 명령의 출력에 있는
tenantId
속성입니다.az account show
프록시를 활성화하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및HTTPS
모두에HTTP
프록시 URL -
프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다
.
를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
-
HTTP 프록시 URL:
- Red Hat OpenShift 풀 시크릿 을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
- 클러스터에 연결하는 데 사용할 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램을 사용하여 새 쌍을 만들 수 있습니다.
Microsoft Azure에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.4.2.3. API를 사용하여 불투명 보안 생성
콘솔 대신 API를 사용하여 Microsoft Azure에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다.
kind: Secret metadata: name: <managed-cluster-name>-azure-creds namespace: <managed-cluster-namespace> type: Opaque data: baseDomainResourceGroupName: $(echo -n "${azure_resource_group_name}" | base64 -w0) osServicePrincipal.json: $(base64 -w0 "${AZURE_CRED_JSON}")
참고:
- 불투명한 시크릿은 콘솔에 표시되지 않습니다.
- opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.4.2.4. 추가 리소스
- Microsoft Azure Portal 을 참조하십시오.
- 클라우드 서비스 구성 방법을 참조하십시오.
- Azure 계정 구성을 참조하십시오.
- Azure CLI를 사용하여 Azure 서비스 주체 생성 을 참조하여 기본 도메인 리소스 그룹 이름을 찾습니다.
- Red Hat OpenShift 풀 시크릿을 다운로드합니다.
- 키를 생성하는 방법에 대한 자세한 내용은 클러스터 노드 SSH 액세스에 대한 키 쌍 생성을 참조하십시오.
- Microsoft Azure에서 클러스터 생성 을 참조하십시오.
- Microsoft Azure의 인증 정보 생성으로 돌아갑니다.
1.4.3. Google Cloud Platform의 인증 정보 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 GCP(Google Cloud Platform)에서 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다.
필요한 액세스: 편집
참고: 이 절차는 다중 클러스터 엔진 Operator가 있는 클러스터를 생성하기 위한 사전 요구 사항입니다.
1.4.3.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 배포된 다중 클러스터 엔진 Operator 허브 클러스터
- GCP에서 Kubernetes 클러스터를 생성할 수 있도록 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스
- 사용자 Google Cloud Platform 프로젝트 ID 및 Google Cloud Platform 서비스 계정 JSON 키가 포함된 GCP 로그인 인증 정보입니다. 프로젝트 생성 및 관리를 참조하십시오.
- GCP에 클러스터를 설치할 수 있는 계정 권한. 계정 구성 방법에 대한 지침은 GCP 프로젝트 구성을 참조하십시오.
1.4.3.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 인증 정보를 호스팅하기 위해 특별히 네임스페이스를 만듭니다.
선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. 다음 단계를 참조하십시오.
- GCP 계정의 Google Cloud Platform 프로젝트 ID 를 추가합니다. 설정을 검색하려면 GCP에 로그인을 참조하십시오.
- Google Cloud Platform 서비스 계정 JSON 키를 추가합니다. 서비스 계정 JSON 키를 생성하려면 서비스 계정 생성 설명서를 참조하십시오. GCP 콘솔의 단계를 따르십시오.
- 새 Google Cloud Platform 서비스 계정 JSON 키 의 콘텐츠를 제공합니다.
프록시를 사용하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및HTTPS
모두에HTTP
프록시 URL -
프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다
.
를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면*
를 추가하고 별표를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
-
HTTP 프록시 URL:
- Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
- 클러스터에 액세스할 수 있도록 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램을 사용하여 새 쌍을 만들 수 있습니다.
Google Cloud Platform에서 클러스터 생성 단계를 완료하여 클러스터를 생성할 때 이 연결을 사용할 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.4.3.3. API를 사용하여 불투명 보안 생성
콘솔 대신 API를 사용하여 Google Cloud Platform에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다.
kind: Secret metadata: name: <managed-cluster-name>-gcp-creds namespace: <managed-cluster-namespace> type: Opaque data: osServiceAccount.json: $(base64 -w0 "${GCP_CRED_JSON}")
참고:
- 불투명한 시크릿은 콘솔에 표시되지 않습니다.
- opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.4.3.4. 추가 리소스
- 프로젝트 생성 및 관리를 참조하십시오.
- GCP 프로젝트 구성을 참조하십시오.
- GCP에 로그인합니다.
- 서비스 계정 JSON 키를 생성하려면 서비스 계정 생성 을 참조하십시오.
- Red Hat OpenShift 풀 시크릿을 다운로드합니다.
- 키를 생성하는 방법에 대한 자세한 내용은 클러스터 노드 SSH 액세스에 대한 키 쌍 생성을 참조하십시오.
- Google Cloud Platform에서 클러스터 생성 을 참조하십시오.
Google Cloud Platform의 인증 정보 생성 으로 돌아갑니다.
1.4.4. VMware vSphere의 인증 정보 생성
VMware vSphere에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 다중 클러스터 엔진 Operator 콘솔을 사용하려면 인증 정보가 필요합니다.
필요한 액세스: 편집
참고:
- 다중 클러스터 엔진 Operator로 클러스터를 생성하려면 먼저 VMware vSphere에 대한 인증 정보를 생성해야 합니다.
- OpenShift Container Platform 버전 4.13 이상이 지원됩니다.
1.4.4.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- OpenShift Container Platform 버전 4.13 이상에 배포된 허브 클러스터입니다.
- VMware vSphere에서 Kubernetes 클러스터를 생성할 수 있도록 허브 클러스터에 대한 인터넷 액세스.
설치 관리자 프로비저닝 인프라를 사용하는 경우 OpenShift Container Platform에 대해 구성된 VMware vSphere 로그인 인증 정보 및 vCenter 요구 사항 사용자 지정을 사용하여 vSphere에 클러스터 설치를 참조하십시오. 이러한 인증 정보에는 다음 정보가 포함됩니다.
- vCenter 계정 권한.
- 클러스터 리소스.
- DHCP 사용 가능
- ESXi 호스트는 시간 동기화(예: NTP)입니다.
1.4.4.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.
선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. 다음 단계를 참조하십시오.
- VMware vCenter 서버 정규화된 호스트 이름 또는 IP 주소를 추가합니다. 값은 vCenter 서버 루트 CA 인증서에 정의해야 합니다. 가능한 경우 정규화된 호스트 이름을 사용합니다.
- VMware vCenter 사용자 이름을 추가합니다.
- VMware vCenter 암호를 추가합니다.
VMware vCenter 루트 CA 인증서를 추가합니다.
-
VMware vCenter 서버에서 인증서를 사용하여
https://<vCenter_address>/certs/
수 있습니다. vCenter_address 를 vCenter 서버의 주소로 바꿉니다.download.zip
.zip 패키지에 인증서를 다운로드할 -
download.zip
의 패키지를 해제합니다. .0
확장자가 있는certs/<platform
> 디렉터리의 인증서를 사용합니다.팁:
ls certs/<platform
> 명령을 사용하여 플랫폼에 사용 가능한 모든 인증서를 나열할 수 있습니다.&
lt;platform
>을 플랫폼의 약어로 바꿉니다.lin
,mac
또는win
.예:
certs/lin/3a343545.0
모범 사례:
cat certs/lin/*
확장자와 여러 인증서를 연결합니다..0
> ca.crt 명령을 실행하여 .0- VMware vSphere 클러스터 이름을 추가합니다.
- VMware vSphere 데이터 센터를 추가합니다.
- VMware vSphere 기본 데이터 저장소를 추가합니다.
- VMware vSphere 디스크 유형을 추가합니다.
- VMware vSphere 폴더 를 추가합니다.
- VMware vSphere 리소스 풀 을 추가합니다.
-
VMware vCenter 서버에서 인증서를 사용하여
연결 해제된 설치의 경우: 필요한 정보를 사용하여 구성 연결이 끊긴 설치 하위 섹션의 필드를 완료합니다.
- Cluster OS image: 이 값에는 Red Hat OpenShift Container Platform 클러스터 머신에 사용할 이미지의 URL이 포함되어 있습니다.
이미지 콘텐츠 소스: 이 값에는 연결이 끊긴 레지스트리 경로가 포함됩니다. 경로에는 연결이 끊긴 설치를 위한 모든 설치 이미지의 호스트 이름, 포트, 리포지토리 경로가 포함됩니다. 예:
repository.com:5000/openshift/ocp-release
.경로는
install-config.yaml
에서 Red Hat OpenShift Container Platform 릴리스 이미지로 이미지 콘텐츠 소스 정책 매핑을 생성합니다. 예를 들어repository.com:5000
은 이imageContentSource
콘텐츠를 생성합니다.- mirrors: - registry.example.com:5000/ocp4 source: quay.io/openshift-release-dev/ocp-release-nightly - mirrors: - registry.example.com:5000/ocp4 source: quay.io/openshift-release-dev/ocp-release - mirrors: - registry.example.com:5000/ocp4 source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
추가 신뢰 번들: 이 값은 미러 레지스트리에 액세스하는 데 필요한 인증서 파일의 내용을 제공합니다.
참고: 연결이 끊긴 환경에 있는 허브에서 관리 클러스터를 배포하고 자동으로 설치되도록 하려면
YAML
편집기를 사용하여 Image Content Source Policy를install-config.yaml
파일에 추가합니다. 다음 예제에 샘플 항목이 표시되어 있습니다.- mirrors: - registry.example.com:5000/rhacm2 source: registry.redhat.io/rhacm2
프록시를 활성화하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및HTTPS
모두에HTTP
프록시 URL -
프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다
.
를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면*
를 추가하고 별표를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
-
HTTP 프록시 URL:
- Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
클러스터에 연결할 수 있는 SSH 개인 키 및 SSH 공개 키를 추가합니다.
기존 키 쌍을 사용하거나 키 생성 프로그램으로 새 키 쌍을 만들 수 있습니다.
VMware vSphere에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.4.4.3. API를 사용하여 불투명 보안 생성
콘솔 대신 API를 사용하여 VMware vSphere에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다.
kind: Secret metadata: name: <managed-cluster-name>-vsphere-creds namespace: <managed-cluster-namespace> type: Opaque data: username: $(echo -n "${VMW_USERNAME}" | base64 -w0) password.json: $(base64 -w0 "${VMW_PASSWORD}")
참고:
- 불투명한 시크릿은 콘솔에 표시되지 않습니다.
- opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.4.4.4. 추가 리소스
- 사용자 지정을 사용하여 vSphere에 클러스터 설치를 참조하십시오.
- Red Hat OpenShift 풀 시크릿을 다운로드합니다.
- 자세한 내용은 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 을 참조하십시오.
- VMware vSphere에서 클러스터 생성 을 참조하십시오.
- VMware vSphere의 인증 정보 생성으로 돌아갑니다.
1.4.5. Red Hat OpenStack의 인증 정보 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenStack Platform에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 인증 정보가 필요합니다.
참고:
- 다중 클러스터 엔진 Operator를 사용하여 클러스터를 생성하려면 Red Hat OpenStack Platform의 인증 정보를 생성해야 합니다.
- OpenShift Container Platform 버전 4.13 이상만 지원됩니다.
1.4.5.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- OpenShift Container Platform 버전 4.13 이상에 배포된 허브 클러스터입니다.
- 허브 클러스터에 대한 인터넷 액세스를 통해 Red Hat OpenStack Platform에서 Kubernetes 클러스터를 생성할 수 있습니다.
- 설치 관리자 프로비저닝 인프라를 사용할 때 OpenShift Container Platform에 대해 구성된 Red Hat OpenStack Platform 로그인 인증 정보 및 Red Hat OpenStack Platform 요구 사항. 사용자 지정을 사용하여 OpenStack에 클러스터 설치를 참조하십시오.
CloudStack API에 액세스하기 위한
clouds.yaml
파일을 다운로드하거나 생성합니다.clouds.yaml
파일 내에서 다음을 수행합니다.- 사용할 클라우드 인증 섹션 이름을 확인합니다.
- username 행 바로 뒤에 암호에 대한 행을 추가합니다.
1.4.5.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 보안 및 편의성을 개선하기 위해 특별히 인증 정보를 호스팅하는 네임스페이스를 생성할 수 있습니다.
- 선택 사항: 인증 정보에 대한 기본 DNS 도메인을 추가할 수 있습니다. 기본 DNS 도메인을 추가하면 이 인증 정보를 사용하여 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다.
-
Red Hat OpenStack Platform
clouds.yaml
파일 내용을 추가합니다. password를 포함하여clouds.yaml
파일의 내용은 Red Hat OpenStack Platform 서버에 연결하는 데 필요한 정보를 제공합니다. 파일 콘텐츠에는 사용자 이름 직후 새 행에 추가하는 암호가 포함되어야합니다
. -
Red Hat OpenStack Platform 클라우드 이름을 추가합니다. 이 항목은 Red Hat OpenStack Platform 서버와의 통신을 설정하는 데 사용할
clouds.yaml
의 cloud 섹션에 지정된 이름입니다. -
선택 사항: 내부 인증 기관을 사용하는 구성의 경우 내부 CA 인증서 필드에 인증서를 입력하여 인증서 정보를 사용하여
clouds.yaml
을 자동으로 업데이트합니다. 연결이 끊긴 설치의 경우에만 해당: 필요한 정보를 사용하여 구성 연결이 끊긴 설치 하위 섹션의 필드를 완료합니다.
- Cluster OS image: 이 값에는 Red Hat OpenShift Container Platform 클러스터 머신에 사용할 이미지의 URL이 포함되어 있습니다.
이미지 콘텐츠 소스: 이 값에는 연결이 끊긴 레지스트리 경로가 포함됩니다. 경로에는 연결이 끊긴 설치를 위한 모든 설치 이미지의 호스트 이름, 포트, 리포지토리 경로가 포함됩니다. 예:
repository.com:5000/openshift/ocp-release
.경로는
install-config.yaml
에서 Red Hat OpenShift Container Platform 릴리스 이미지로 이미지 콘텐츠 소스 정책 매핑을 생성합니다. 예를 들어repository.com:5000
은 이imageContentSource
콘텐츠를 생성합니다.- mirrors: - registry.example.com:5000/ocp4 source: quay.io/openshift-release-dev/ocp-release-nightly - mirrors: - registry.example.com:5000/ocp4 source: quay.io/openshift-release-dev/ocp-release - mirrors: - registry.example.com:5000/ocp4 source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
추가 신뢰 번들: 이 값은 미러 레지스트리에 액세스하는 데 필요한 인증서 파일의 내용을 제공합니다.
참고: 연결이 끊긴 환경에 있는 허브에서 관리 클러스터를 배포하고 자동으로 설치되도록 하려면
YAML
편집기를 사용하여 Image Content Source Policy를install-config.yaml
파일에 추가합니다. 다음 예제에 샘플 항목이 표시되어 있습니다.- mirrors: - registry.example.com:5000/rhacm2 source: registry.redhat.io/rhacm2
프록시를 활성화하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및HTTPS
모두에HTTP
프록시 URL -
프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다
.
를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 하나 이상의 추가 CA 인증서입니다.
-
HTTP 프록시 URL:
- Red Hat OpenShift 풀 시크릿을 입력합니다. 풀 시크릿 을 다운로드하려면 Red Hat OpenShift 풀 시크릿 다운로드를 참조하십시오.
- 클러스터에 연결할 수 있는 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램으로 새 키 쌍을 만들 수 있습니다.
- 생성을 클릭합니다.
- 새 인증 정보 를 검토한 다음 추가 를 클릭합니다. 인증 정보를 추가하면 인증 정보 목록에 추가됩니다.
Red Hat OpenStack Platform에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.4.5.3. API를 사용하여 불투명 보안 생성
콘솔 대신 API를 사용하여 Red Hat OpenStack Platform에 대한 불투명 시크릿을 생성하려면 다음 예와 유사한 YAML 프리뷰 창에 YAML 콘텐츠를 적용합니다.
kind: Secret metadata: name: <managed-cluster-name>-osp-creds namespace: <managed-cluster-namespace> type: Opaque data: clouds.yaml: $(base64 -w0 "${OSP_CRED_YAML}") cloud: $(echo -n "openstack" | base64 -w0)
참고:
- 불투명한 시크릿은 콘솔에 표시되지 않습니다.
- opaque 보안은 선택한 관리 클러스터 네임스페이스에서 생성됩니다. Hive는 불투명 시크릿을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 미리 생성된 인증 정보가 opaque 시크릿으로 관리 클러스터 네임스페이스에 복사됩니다.
1.4.5.4. 추가 리소스
- 사용자 지정을 사용하여 OpenStack에 클러스터 설치를 참조하십시오.
- Red Hat OpenShift 풀 시크릿을 다운로드합니다.
- 자세한 내용은 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 을 참조하십시오.
- Red Hat OpenStack Platform에서 클러스터 생성 을 참조하십시오.
- Red Hat OpenStack에 대한 인증 정보 생성 으로 돌아갑니다.
1.4.6. Red Hat Virtualization의 인증 정보 생성
더 이상 사용되지 않음: Red Hat Virtualization 인증 정보 및 클러스터 생성 기능은 더 이상 사용되지 않으며 더 이상 지원되지 않습니다.
다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat Virtualization에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 인증 정보가 필요합니다.
참고: 다중 클러스터 엔진 Operator를 사용하여 클러스터를 생성하려면 이 절차를 수행해야 합니다.
1.4.6.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- OpenShift Container Platform 버전 4.13 이상에 배포된 허브 클러스터입니다.
- 허브 클러스터에 대한 인터넷 액세스를 통해 Red Hat Virtualization에서 Kubernetes 클러스터를 만들 수 있습니다.
구성된 Red Hat Virtualization 환경에 대한 Red Hat Virtualization 로그인 인증 정보. Red Hat Virtualization 설명서의 설치 가이드를 참조하십시오. 다음 목록은 필요한 정보를 보여줍니다.
- ovirt URL
- ovirt FQDN(정규화된 도메인 이름)
- ovirt 사용자 이름
- ovirt 암호
- ovirt CA/Certificate
- 선택 사항: 프록시를 활성화하는 경우 프록시 정보입니다.
- Red Hat OpenShift Container Platform 풀 시크릿 정보. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
- 최종 클러스터의 정보를 전송하는 SSH 개인 키 및 공개 키입니다.
- oVirt에 클러스터를 설치할 수 있는 계정 권한.
1.4.6.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 제공하고 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.
- 새 인증 정보에 대한 기본 정보를 추가합니다. 선택적으로 이 인증 정보를 사용하여 클러스터를 생성할 때 올바른 필드에 자동으로 채워지는 기본 DNS 도메인을 추가할 수 있습니다. 인증 정보에 추가하지 않으면 클러스터를 생성할 때 추가할 수 있습니다.
- Red Hat Virtualization 환경에 필요한 정보를 추가합니다.
프록시를 활성화하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽을 사용할 때 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면 HTTP 및HTTPS
모두에HTTP
프록시 URL -
프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 마침표로 도메인 이름을 시작합니다
.
를 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표*
를 추가합니다.
-
HTTP 프록시 URL:
- Red Hat OpenShift Container Platform 풀 시크릿을 입력합니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
- 클러스터에 연결할 수 있는 SSH 개인 키 및 SSH 공개 키를 추가합니다. 기존 키 쌍을 사용하거나 키 생성 프로그램을 사용하여 새 키 쌍을 만들 수 있습니다. 자세한 내용은 클러스터 노드 SSH 액세스에 대한 키 쌍 생성 을 참조하십시오.
- 새 인증 정보 를 검토한 다음 추가 를 클릭합니다. 인증 정보를 추가하면 인증 정보 목록에 추가됩니다.
Red Hat Virtualization (더 이상 사용되지 않음)에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.4.7. Red Hat OpenShift Cluster Manager의 인증 정보 생성
클러스터를 검색할 수 있도록 OpenShift Cluster Manager 인증 정보를 추가합니다.
필수 액세스: 관리자
1.4.7.1. 사전 요구 사항
console.redhat.com 계정에 액세스해야 합니다. 나중에 console.redhat.com/openshift/token 에서 가져올 수 있는 값이 필요합니다.
1.4.7.2. 콘솔을 사용하여 인증 정보 관리
클러스터를 검색하려면 인증 정보를 추가해야 합니다. 다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.
OpenShift Cluster Manager API 토큰은 console.redhat.com/openshift/token 에서 가져올 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
인증 정보가 제거되거나 OpenShift Cluster Manager API 토큰이 만료되거나 취소되면 관련 검색 클러스터가 제거됩니다.
1.4.8. Ansible Automation Platform의 인증 정보 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat Ansible Automation Platform을 사용하는 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 인증 정보가 필요합니다.
필요한 액세스: 편집
참고: 클러스터에서 자동화를 활성화하려면 자동화 템플릿을 생성하기 전에 이 절차를 수행해야 합니다.
1.4.8.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 배포된 다중 클러스터 엔진 Operator 허브 클러스터
- 다중 클러스터 엔진 Operator 허브 클러스터에 대한 인터넷 액세스
- Ansible Automation Platform 호스트 이름 및 OAuth 토큰이 포함된 Ansible 로그인 인증 정보는 Ansible Automation Platform용 인증 정보를 참조하십시오.
- 허브 클러스터를 설치하고 Ansible을 사용할 수 있는 계정 권한. Ansible 사용자에 대해 자세히 알아보기 .
1.4.8.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.
Ansible 인증 정보를 생성할 때 제공하는 Ansible 토큰 및 호스트 URL은 인증 정보를 편집할 때 해당 인증 정보를 사용하는 자동화에 대해 자동으로 업데이트됩니다. 업데이트는 클러스터 라이프사이클, 거버넌스 및 애플리케이션 관리 자동화와 관련된 Ansible 자격 증명을 사용하는 모든 자동화에 복사됩니다. 이렇게 하면 인증 정보를 업데이트한 후 자동화가 계속 실행됩니다.
콘솔에서 인증 정보를 편집할 수 있습니다. Ansible 인증 정보는 인증 정보에서 업데이트할 때 해당 인증 정보를 사용하는 자동화에서 자동으로 업데이트됩니다.
관리 클러스터에서 실행되도록 Ansible Automation Platform 작업 구성 단계를 완료하여 이 인증 정보를 사용하는 Ansible 작업을 생성할 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.4.9. 온-프레미스 환경에 대한 인증 정보 생성
온-프레미스 환경에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 콘솔을 사용하는 인증 정보가 필요합니다. 인증 정보는 클러스터에 사용되는 연결을 지정합니다.
필요한 액세스: 편집
1.4.9.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 필요합니다.
- 배포된 허브 클러스터입니다.
- 인프라 환경에서 Kubernetes 클러스터를 생성할 수 있도록 허브 클러스터에 대한 인터넷 액세스.
- 연결이 끊긴 환경의 경우 클러스터 생성을 위해 릴리스 이미지를 복사할 수 있는 구성된 미러 레지스트리가 있어야 합니다. 자세한 내용은 OpenShift Container Platform 설명서에서 연결 해제 설치 미러링 을 참조하십시오.
- 온-프레미스 환경에 클러스터 설치를 지원하는 계정 권한.
1.4.9.2. 콘솔을 사용하여 인증 정보 관리
콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. 인증 정보를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 네임스페이스를 생성하여 인증 정보를 호스팅합니다.
- 인증 정보 유형에 대한 호스트 인벤토리 를 선택합니다.
- 선택적으로 인증 정보에 대한 기본 DNS 도메인 을 추가할 수 있습니다. 기본 DNS 도메인을 인증 정보에 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 올바른 필드에 자동으로 채워집니다. DNS 도메인을 추가하지 않으면 클러스터를 생성할 때 추가할 수 있습니다.
- Red Hat OpenShift 풀 시크릿 을 입력합니다. 이 풀 시크릿은 클러스터를 생성하고 이 인증 정보를 지정할 때 자동으로 입력됩니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다. 가져오기 보안에 대한 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
-
SSH 공개 키를
입력합니다. 클러스터를 생성하고 이 인증 정보를 지정할 때 이SSH 공개 키도
자동으로 입력됩니다. - 추가 를 선택하여 인증 정보를 생성합니다.
온-프레미스 환경에서 클러스터 생성 단계를 완료하여 이 인증 정보를 사용하는 클러스터를 만들 수 있습니다.
인증 정보를 사용하는 클러스터를 더 이상 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 인증 정보 옆에 있는 옵션 메뉴를 선택합니다.
1.5. 클러스터 라이프사이클 소개
멀티 클러스터 엔진 Operator는 OpenShift Container Platform 및 Red Hat Advanced Cluster Management Hub 클러스터에 대한 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. 다중 클러스터 엔진 Operator는 클러스터 관리를 개선하고 클라우드 및 데이터 센터 전체에서 OpenShift Container Platform 클러스터 라이프사이클 관리를 지원하는 소프트웨어 운영자입니다. Red Hat Advanced Cluster Management를 사용하거나 사용하지 않고 다중 클러스터 엔진 Operator를 사용할 수 있습니다. Red Hat Advanced Cluster Management는 멀티 클러스터 엔진 Operator도 자동으로 설치하고 추가 다중 클러스터 기능을 제공합니다.
다음 설명서를 참조하십시오.
- 클러스터 라이프사이클 아키텍처
- 인증 정보 관리 개요
- 호스트 인벤토리 소개
- CLI를 사용하여 클러스터 생성
- 클러스터 생성 중 추가 매니페스트 구성
- Amazon Web Services에서 클러스터 생성
- Amazon Web Services GovCloud에서 클러스터 생성
- Microsoft Azure에 클러스터 생성
- Google Cloud Platform에서 클러스터 생성
- VMware vSphere에서 클러스터 생성
- Red Hat OpenStack Platform에서 클러스터 생성
- Red Hat Virtualization에서 클러스터 생성 (더 이상 사용되지 않음)
- 온프레미스 환경에서 클러스터 생성
- 프록시 환경에서 클러스터 생성
- 클러스터에 액세스
- 관리형 클러스터 확장
- 생성된 클러스터 완화
- 클러스터 프록시 애드온 활성화
- 관리 클러스터에서 실행되도록 Ansible Automation Platform 작업 구성
- 배치
- ManagedServiceAccount 활성화
- 클러스터 라이프사이클 고급 구성
- 관리에서 클러스터 제거
1.5.1. 클러스터 라이프사이클 아키텍처
클러스터 라이프사이클에는 허브 클러스터와 관리 클러스터의 두 가지 유형이 필요합니다.
hub 클러스터는 다중 클러스터 엔진 Operator가 자동으로 설치된 OpenShift Container Platform (또는 Red Hat Advanced Cluster Management) 기본 클러스터입니다. hub 클러스터를 사용하여 다른 Kubernetes 클러스터를 생성, 관리 및 모니터링할 수 있습니다. hub 클러스터에서 관리할 기존 클러스터를 가져오는 동안 hub 클러스터를 사용하여 클러스터를 생성할 수 있습니다.
관리형 클러스터를 생성할 때 Hive 리소스와 함께 Red Hat OpenShift Container Platform 클러스터 설치 프로그램을 사용하여 클러스터가 생성됩니다. OpenShift Container Platform 설치 프로그램을 사용하여 클러스터 설치 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 OpenShift Container Platform 클러스터 설치 및 구성 을 읽고 확인할 수 있습니다.
다음 다이어그램은 클러스터 관리를 위해 Kubernetes Operator용 다중 클러스터 엔진과 함께 설치된 구성 요소를 보여줍니다.
클러스터 라이프사이클 관리 아키텍처의 구성 요소에는 다음 항목이 포함됩니다.
1.5.1.1. hub 클러스터
- 관리 클러스터 가져오기 컨트롤러는 klusterlet Operator를 관리 클러스터에 배포합니다.
- Hive 컨트롤러는 Kubernetes Operator에 다중 클러스터 엔진을 사용하여 생성하는 클러스터를 프로비저닝합니다. Hive 컨트롤러는 Kubernetes Operator를 위해 다중 클러스터 엔진에 의해 생성된 관리형 클러스터도 제거합니다.
- 클러스터 큐레이터 컨트롤러는 관리 클러스터를 생성하거나 업그레이드할 때 클러스터 인프라 환경을 구성하기 위해 pre-hook 또는 post-hook로 Ansible 작업을 생성합니다.
- hub 클러스터에서 관리되는 클러스터 애드온이 활성화되면 허브 클러스터에 해당 애드온 허브 컨트롤러가 배포됩니다. 애드온 허브 컨트롤러는 관리형 클러스터에 애드온 에이전트 를 배포합니다.
1.5.1.2. 관리형 클러스터
- klusterlet Operator 는 관리 클러스터에 등록 및 작업 컨트롤러를 배포합니다.
등록 에이전트 는 관리 클러스터와 관리형 클러스터 애드온을 hub 클러스터에 등록합니다. 또한 등록 에이전트는 관리 클러스터 및 관리 클러스터 애드온의 상태를 유지 관리합니다. 다음 권한은 관리 클러스터가 hub 클러스터에 액세스할 수 있도록 Clusterrole 내에 자동으로 생성됩니다.
- 에이전트가 hub 클러스터에서 관리하는 소유 클러스터를 가져오거나 업데이트할 수 있습니다.
- 에이전트가 hub 클러스터에서 관리하는 소유 클러스터의 상태를 업데이트할 수 있습니다.
- 에이전트가 인증서를 회전하도록 허용
-
에이전트가 reconcile
.k8s.io
리스를얻거나
업데이트
하도록 허용 -
에이전트가 관리 클러스터 애드온을
가져올 수
있도록 허용 - 에이전트가 관리 클러스터 애드온의 상태를 업데이트하도록 허용
- 작업 에이전트 는 Add-on Agent를 관리 클러스터에 적용합니다. 관리 클러스터가 hub 클러스터에 액세스할 수 있도록 허용하는 권한은 Clusterrole 내에서 자동으로 생성되고 에이전트가 hub 클러스터에 이벤트를 보낼 수 있습니다.
클러스터를 계속 추가하고 관리하려면 클러스터 라이프사이클 소개 를 참조하십시오.
1.5.2. 이미지 릴리스
클러스터를 빌드할 때 릴리스 이미지가 지정하는 Red Hat OpenShift Container Platform 버전을 사용하십시오. 기본적으로 OpenShift Container Platform은 clusterImageSets
리소스를 사용하여 지원되는 릴리스 이미지 목록을 가져옵니다.
계속 읽고 릴리스 이미지에 대한 자세한 내용을 확인하십시오.
1.5.2.1. 릴리스 이미지 지정
Kubernetes Operator에 다중 클러스터 엔진을 사용하여 공급자에 클러스터를 생성하는 경우 새 클러스터에 사용할 릴리스 이미지를 지정합니다. 릴리스 이미지를 지정하려면 다음 항목을 참조하십시오.
1.5.2.1.1. ClusterImageSets위치
릴리스 이미지를 참조하는 YAML 파일은 acm-hive-openshift-releases GitHub 리포지토리에서 유지 관리됩니다. 파일은 콘솔에서 사용 가능한 릴리스 이미지 목록을 생성하는 데 사용됩니다. 여기에는 OpenShift Container Platform의 최신 빠른 채널 이미지가 포함됩니다.
콘솔에는 세 가지 최신 버전의 OpenShift Container Platform의 최신 릴리스 이미지만 표시됩니다. 예를 들어 콘솔 옵션에 다음 릴리스 이미지가 표시될 수 있습니다.
quay.io/openshift-release-dev/ocp-release:4.13.1-x86_64
콘솔에 최신 릴리스 이미지로 클러스터를 생성하는 데 도움이 되는 최신 버전이 표시됩니다. 특정 버전의 클러스터를 생성해야 하는 경우 이전 릴리스 이미지 버전도 사용할 수 있습니다.
참고: 콘솔에 클러스터를 생성할 때 표시되는 이미지: 'true'
레이블이 있는 이미지만 선택할 수 있습니다. ClusterImageSet
리소스의 이 레이블의 예는 다음 콘텐츠에 제공됩니다. 4.x.1
을 제품의 현재 버전으로 바꿉니다.
apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: fast visible: 'true' name: img4.x.1-x86-64-appsub spec: releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64
추가 릴리스 이미지가 저장되지만 콘솔에는 표시되지 않습니다. 사용 가능한 모든 릴리스 이미지를 보려면 다음 명령을 실행합니다.
oc get clusterimageset
리포지토리에는 릴리스 이미지로 작업할 때 사용하는 디렉터리인 clusterImageSets
디렉터리가 있습니다. clusterImageSets
디렉터리에는 다음과 같은 디렉터리가 있습니다.
- fast: 지원되는 각 OpenShift Container Platform 버전에 대한 최신 버전의 릴리스 이미지를 참조하는 파일이 포함되어 있습니다. 이 폴더의 릴리스 이미지는 테스트, 확인 및 지원됩니다.
릴리스: 각 OpenShift Container Platform 버전 (stable, fast, and candidate 채널)의 모든 릴리스 이미지를 참조하는 파일이 포함되어 있습니다.
참고: 이 릴리스는 모두 테스트된 것이 아니며 안정적인 것으로 확인되었습니다.
stable: 지원되는 각 OpenShift Container Platform 버전에 대해 안정적인 최신 버전의 릴리스 이미지를 참조하는 파일이 포함되어 있습니다.
참고: 기본적으로 현재 릴리스 이미지 목록은 시간마다 한 번씩 업데이트됩니다. 제품을 업그레이드한 후 새 버전의 제품에 권장되는 릴리스 이미지 버전을 반영하는 데 최대 1시간이 걸릴 수 있습니다.
1.5.2.1.2. ClusterImageSets구성
다음 옵션을 사용하여 ClusterImageSet
을 구성할 수 있습니다.
옵션 1: 콘솔에서 클러스터를 만들려면 원하는 특정
ClusterImageSet
에 대한 이미지 참조를 지정합니다. 유지를 지정하는 각 새 항목은 향후 모든 클러스터 프로비저닝에 대해 사용할 수 있으며 다음 예제 항목을 참조하십시오.quay.io/openshift-release-dev/ocp-release:4.6.8-x86_64
-
옵션 2:
acm-hive-openshift-releases
GitHub 리포지토리에서ClusterImageSets
YAML 파일을 수동으로 생성하고 적용합니다. -
옵션 3: 분기된 GitHub 리포지토리에서
ClusterImageSets
의 자동 업데이트를 활성화하려면 cluster-image-set-controller GitHub 리포지토리의README.md
를 따릅니다.
1.5.2.1.3. 다른 아키텍처에 클러스터를 배포할 릴리스 이미지 생성
두 아키텍처의 파일이 있는 릴리스 이미지를 수동으로 생성하여 허브 클러스터의 아키텍처와 다른 아키텍처에 클러스터를 생성할 수 있습니다.
예를 들어 ppc64le
,aarch64
또는 s390x
아키텍처에서 실행 중인 hub 클러스터에서 x86_64
클러스터를 생성해야 할 수 있습니다. 두 파일 세트를 모두 사용하여 릴리스 이미지를 생성하는 경우 새 릴리스 이미지를 사용하면 OpenShift Container Platform 릴리스 레지스트리에서 다중 아키텍처 이미지 매니페스트를 제공할 수 있으므로 클러스터 생성이 성공합니다.
OpenShift Container Platform 4.13 이상에서는 기본적으로 여러 아키텍처를 지원합니다. 다음 clusterImageSet
을 사용하여 클러스터를 프로비저닝할 수 있습니다. 4.x.0
을 현재 버전으로 바꿉니다.
apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: fast visible: 'true' name: img4.x.0-multi-appsub spec: releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.0-multi
여러 아키텍처를 지원하지 않는 OpenShift Container Platform 이미지의 릴리스 이미지를 생성하려면 아키텍처 유형에 대해 다음 예와 유사한 단계를 완료합니다.
OpenShift Container Platform 릴리스 레지스트리에서
x86_64
,s390x
,aarch64
,ppc64le
릴리스 이미지가 포함된 매니페스트 목록을 생성합니다.다음 예제 명령을 실행하여 Quay 리포지토리에서 두 아키텍처 모두에 대한 매니페스트 목록을 가져옵니다.
4.x.1
을 제품의 현재 버전으로 바꿉니다.podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-s390x podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64
다음 명령을 실행하여 이미지를 유지 관리하는 개인 리포지토리에 로그인합니다. &
lt;private-repo
>를 리포지토리 경로로 바꿉니다.podman login <private-repo>
환경에 적용되는 다음 명령을 실행하여 프라이빗 리포지토리에 릴리스 이미지 매니페스트를 추가합니다.
4.x.1
을 제품의 현재 버전으로 바꿉니다. <private-repo
>를 리포지토리 경로로 바꿉니다.podman push quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 <private-repo>/ocp-release:4.x.1-x86_64 podman push quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le <private-repo>/ocp-release:4.x.1-ppc64le podman push quay.io/openshift-release-dev/ocp-release:4.x.1-s390x <private-repo>/ocp-release:4.x.1-s390x podman push quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64 <private-repo>/ocp-release:4.x.1-aarch64
다음 명령을 실행하여 새 정보에 대한 매니페스트를 생성합니다.
podman manifest create mymanifest
다음 명령을 실행하여 두 릴리스 이미지에 대한 참조를 매니페스트 목록에 추가합니다.
4.x.1
을 제품의 현재 버전으로 바꿉니다. <private-repo
>를 리포지토리 경로로 바꿉니다.podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-x86_64 podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-ppc64le podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-s390x podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-aarch64
다음 명령을 실행하여 매니페스트 목록의 목록을 기존 매니페스트와 병합합니다. &
lt;private-repo
>를 리포지토리 경로로 바꿉니다.4.x.1
을 현재 버전으로 바꿉니다.podman manifest push mymanifest docker://<private-repo>/ocp-release:4.x.1
허브 클러스터에서 리포지토리의 매니페스트를 참조하는 릴리스 이미지를 생성합니다.
다음 예와 유사한 정보가 포함된 YAML 파일을 생성합니다. &
lt;private-repo
>를 리포지토리 경로로 바꿉니다.4.x.1
을 현재 버전으로 바꿉니다.apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: fast visible: "true" name: img4.x.1-appsub spec: releaseImage: <private-repo>/ocp-release:4.x.1
허브 클러스터에서 다음 명령을 실행하여 변경 사항을 적용합니다. &
lt;file-name
>을 이전 단계에서 생성한 YAML 파일의 이름으로 바꿉니다.oc apply -f <file-name>.yaml
- OpenShift Container Platform 클러스터를 생성할 때 새 릴리스 이미지를 선택합니다.
- Red Hat Advanced Cluster Management 콘솔을 사용하여 관리 클러스터를 배포하는 경우 클러스터 생성 프로세스 중 Architecture 필드에 관리 클러스터의 아키텍처를 지정합니다.
생성 프로세스에서는 병합된 릴리스 이미지를 사용하여 클러스터를 생성합니다.
1.5.2.1.4. 추가 리소스
- 릴리스 이미지를 참조하는 YAML 파일의 acm-hive-openshift-releases GitHub 리포지토리를 참조하십시오.
-
분기된 GitHub 리포지토리에서
ClusterImage
Set의 자동 업데이트를 활성화하는 방법을 알아보려면 cluster-image-set-controller GitHub 리포지토리를 참조하십시오.
1.5.2.2. 연결된 경우 사용자 정의 릴리스 이미지 목록 유지
모든 클러스터에 동일한 릴리스 이미지를 사용해야 할 수 있습니다. 단순화하기 위해 클러스터를 생성할 때 사용할 수 있는 고유한 릴리스 이미지 목록을 생성할 수 있습니다. 사용 가능한 릴리스 이미지를 관리하려면 다음 단계를 완료합니다.
- acm-hive-openshift-releases GitHub 를 분기합니다.
-
클러스터를 생성할 때 사용할 수 있는 이미지의 YAML 파일을 추가합니다. Git 콘솔 또는 터미널을 사용하여 이미지를
./clusterImageSets/stable/
또는./clusterImageSets/fast/
디렉터리에 추가합니다. -
cluster-image-set-git-repo
라는multicluster-engine
네임스페이스에ConfigMap
을 생성합니다. 다음 예제를 참조하지만2.x
를 2.5로 바꿉니다.
apiVersion: v1 kind: ConfigMap metadata: name: cluster-image-set-git-repo namespace: multicluster-engine data: gitRepoUrl: <forked acm-hive-openshift-releases repository URL> gitRepoBranch: backplane-<2.x> gitRepoPath: clusterImageSets channel: <fast or stable>
다음 절차에 따라 분기된 리포지토리에 변경 사항을 병합하여 기본 리포지토리에서 사용 가능한 YAML 파일을 검색할 수 있습니다.
- 분기된 리포지토리에 변경 사항을 커밋하고 병합합니다.
-
acm-hive-openshift-releases
리포지토리를 복제한 후 빠른 릴리스 이미지 목록을 동기화하려면cluster-image-set-git-repo
ConfigMap
의 channel 필드를fast
로 업데이트합니다. -
안정적인 릴리스 이미지를 동기화하고 표시하려면
cluster-image-set-git-repo
ConfigMap
의 channel 필드 값을stable
로 업데이트합니다.
ConfigMap
을 업데이트한 후 사용 가능한 안정적인 릴리스 이미지 목록이 약 1분 내에 현재 사용 가능한 이미지로 업데이트됩니다.
다음 명령을 사용하여 사용 가능한 항목을 나열하고 기본값을 제거할 수 있습니다. &
lt;clusterImageSet_NAME>
;을 올바른 이름으로 바꿉니다.oc get clusterImageSets oc delete clusterImageSet <clusterImageSet_NAME>
클러스터를 생성할 때 콘솔에서 현재 사용 가능한 릴리스 이미지 목록을 확인합니다.
ConfigMap
을 통해 사용할 수 있는 다른 필드에 대한 자세한 내용은 cluster-image-set-controller GitHub 리포지토리 README를 참조하십시오.
1.5.2.3. 연결이 끊긴 동안 사용자 정의 릴리스 이미지 목록 유지 관리
hub 클러스터에 인터넷 연결이 없는 경우 사용자 정의 릴리스 이미지 목록을 유지 관리해야 하는 경우도 있습니다. 클러스터를 생성할 때 사용 가능한 자체 릴리스 이미지 목록을 생성할 수 있습니다. 연결이 끊긴 동안 사용 가능한 릴리스 이미지를 관리하려면 다음 단계를 완료합니다.
- 연결된 시스템에 있는 동안 acm-hive-openshift-releases GitHub 리포지토리로 이동하여 사용 가능한 클러스터 이미지 세트에 액세스합니다.
-
연결이 끊긴 다중 클러스터 엔진 Operator 클러스터에 액세스할 수 있는 시스템에
clusterImageSets
디렉터리를 복사합니다. 관리 클러스터에 적합한 다음 단계를 완료하여 관리 클러스터와 클러스터 이미지 세트와 연결이 끊긴 리포지토리 간의 매핑을 추가합니다.
-
OpenShift Container Platform 관리형 클러스터의 경우
ImageContentSourcePolicy
개체를 사용하여 매핑을 완료하는 방법에 대한 자세한 내용은 이미지 레지스트리 저장소 미러링 구성 을 참조하십시오. -
OpenShift Container Platform 클러스터가 아닌 관리형 클러스터의 경우
ManageClusterImageRegistry
사용자 정의 리소스 정의를 사용하여 이미지 세트의 위치를 재정의합니다. 매핑에 대한 클러스터를 재정의하는 방법에 대한 정보는 가져오기에서 관리 클러스터에서 레지스트리 이미지 지정을 참조하십시오.
-
OpenShift Container Platform 관리형 클러스터의 경우
-
콘솔 또는 CLI를 사용하여
clusterImageSet
YAML 콘텐츠를 수동으로 추가하여 클러스터를 생성할 때 사용할 수 있는 이미지의 YAML 파일을 추가합니다. 이미지를 저장하는 올바른 오프라인 리포지토리를 참조하도록 나머지 OpenShift Container Platform 릴리스 이미지의
clusterImageSet
YAML 파일을 수정합니다. 업데이트는spec.releaseImage
에서 릴리스 이미지의 오프라인 이미지 레지스트리를 사용하고 다이제스트에서 릴리스 이미지를 참조하는 다음 예와 유사합니다.apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: fast name: img<4.x.x>-x86-64-appsub spec: releaseImage: IMAGE_REGISTRY_IPADDRESS_or__DNSNAME/REPO_PATH/ocp-release@sha256:073a4e46289be25e2a05f5264c8f1d697410db66b960c9ceeddebd1c61e58717
- 이미지가 YAML 파일에서 참조되는 오프라인 이미지 레지스트리에 로드되었는지 확인합니다.
다음 명령을 실행하여 이미지 다이제스트를 가져옵니다.
oc adm release info <tagged_openshift_release_image> | grep "Pull From"
&
lt;tagged_openshift_release_image
>를 지원되는 OpenShift Container Platform 버전에 대한 태그된 이미지로 바꿉니다. 다음 예제 출력을 참조하십시오.Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
이미지 태그 및 다이제스트에 대한 자세한 내용은 이미지 스트림의 이미지 참조를 참조하십시오.
각 YAML 파일에 다음 명령을 입력하여 각
clusterImageSets
를 생성합니다.oc create -f <clusterImageSet_FILE>
clusterImageSet_FILE
을 클러스터 이미지 세트 파일의 이름으로 교체합니다. 예를 들면 다음과 같습니다.oc create -f img4.11.9-x86_64.yaml
추가할 각 리소스에 대해 이 명령을 실행하면 사용 가능한 릴리스 이미지 목록을 사용할 수 있습니다.
-
또는 클러스터 콘솔 생성에 이미지 URL을 직접 붙여넣을 수 있습니다. 이미지 URL을 추가하면 새
clusterImageSets
가 없는 경우 생성됩니다. - 클러스터를 생성할 때 콘솔에서 현재 사용 가능한 릴리스 이미지 목록을 확인합니다.
1.5.3. 호스트 인벤토리 소개
호스트 인벤토리 관리 및 온-프레미스 클러스터 설치는 다중 클러스터 엔진 Operator 중앙 인프라 관리 기능을 사용하여 사용할 수 있습니다. 중앙 인프라 관리는 허브 클러스터에서 Operator로 지원 설치 관리자 (인프라 운영자라고도 함)를 실행합니다.
콘솔을 사용하여 온프레미스 OpenShift Container Platform 클러스터를 생성하는 데 사용할 수 있는 베어 메탈 또는 가상 머신 풀인 호스트 인벤토리를 생성할 수 있습니다. 이러한 클러스터는 컨트롤 플레인 전용 머신 또는 컨트롤 플레인의 전용 머신이 있는 독립 실행형 클러스터일 수 있습니다. 여기서 컨트롤 플레인은 허브 클러스터에서 Pod로 실행됩니다. ../../html-single/..#hosted-control-planes-intro
ZTP(ZTP)를 사용하여 콘솔, API 또는 GitOps를 사용하여 독립 실행형 클러스터를 설치할 수 있습니다. ZTP에 대한 자세한 내용은 Red Hat OpenShift Container Platform 설명서의 연결이 끊긴 환경에 GitOps ZTP 설치를 참조하십시오.
시스템은 Discovery Image로 부팅한 후 호스트 인벤토리를 결합합니다. Discovery Image는 다음이 포함된 Red Hat CoreOS 라이브 이미지입니다.
- 검색, 검증 및 설치 작업을 수행하는 에이전트입니다.
- 해당하는 경우 엔드포인트, 토큰, 정적 네트워크 구성을 포함하여 허브 클러스터에서 서비스에 연결하는 데 필요한 구성입니다.
일반적으로 공통 속성 세트를 공유하는 호스트 세트인 각 인프라 환경에 대해 단일 검색 이미지가 있습니다. InfraEnv
사용자 정의 리소스 정의는 이 인프라 환경 및 관련 Discovery Image를 나타냅니다. 사용되는 이미지는 선택한 운영 체제 버전을 결정하는 OpenShift Container Platform 버전을 기반으로 합니다.
호스트가 부팅되고 에이전트가 서비스에 연결되면 서비스는 해당 호스트를 나타내는 허브 클러스터에 새 Agent
사용자 정의 리소스를 생성합니다. 에이전트
리소스는 호스트 인벤토리를 구성합니다.
나중에 OpenShift 노드로 인벤토리에 호스트를 설치할 수 있습니다. 에이전트는 필요한 구성과 함께 운영 체제를 디스크에 쓰고 호스트를 재부팅합니다.
참고: Red Hat Advanced Cluster Management 2.9 이상 및 중앙 인프라 관리는 Nutanix 가상 머신을 생성하여 추가 구성이 필요한 AgentClusterInstall
을 사용하여 Nutanix 플랫폼을 지원합니다. 자세한 내용은 지원 설치 관리자 설명서의 선택적: Nutanix에 설치를 참조하십시오.
호스트 인벤토리 및 중앙 인프라 관리에 대해 자세히 알아보려면 계속 읽으십시오.
1.5.3.1. 중앙 인프라 관리 서비스 활성화
중앙 인프라 관리 서비스는 다중 클러스터 엔진 Operator와 함께 제공되며 OpenShift Container Platform 클러스터를 배포합니다. 허브 클러스터에서 MultiClusterHub Operator를 활성화하면 중앙 인프라 관리는 자동으로 배포되지만 서비스를 수동으로 활성화해야 합니다.
1.5.3.1.1. 사전 요구 사항
중앙 인프라 관리 서비스를 활성화하기 전에 다음 사전 요구 사항을 참조하십시오.
- 지원되는 Red Hat Advanced Cluster Management for Kubernetes 버전이 있는 OpenShift Container Platform 4.13 이상에 배포된 허브 클러스터가 있어야 합니다.
- 허브 클러스터(연결됨)에 대한 인터넷 액세스 또는 환경 생성에 필요한 이미지를 검색하기 위해 인터넷에 연결되어 있는 내부 또는 미러 레지스트리에 대한 연결이 필요합니다.
- 베어 메탈 프로비저닝에 필요한 포트를 열어야 합니다. OpenShift Container Platform 설명서에서 필요한 포트 활성화를 참조하십시오.
- 베어 메탈 호스트 사용자 정의 리소스 정의가 필요합니다.
- OpenShift Container Platform 풀 시크릿 이 필요합니다. 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
- 구성된 기본 스토리지 클래스가 필요합니다.
- 연결이 끊긴 환경의 경우 OpenShift Container Platform 설명서에서 네트워크 맨 엣지에서 클러스터에 대한 절차를 완료합니다.
1.5.3.1.2. 베어 메탈 호스트 사용자 정의 리소스 정의 생성
중앙 인프라 관리 서비스를 활성화하기 전에 베어 메탈 호스트 사용자 정의 리소스 정의가 필요합니다.
다음 명령을 실행하여 베어 메탈 호스트 사용자 정의 리소스 정의가 있는지 확인합니다.
oc get crd baremetalhosts.metal3.io
- 베어 메탈 호스트 사용자 정의 리소스 정의가 있는 경우 출력에 리소스가 생성된 날짜가 표시됩니다.
리소스가 없는 경우 다음과 유사한 오류가 표시됩니다.
Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not found
베어 메탈 호스트 사용자 정의 리소스 정의가 없는 경우 metal3.io_baremetalhosts.yaml 파일을 다운로드하고 다음 명령을 실행하여 리소스를 생성하여 콘텐츠를 적용합니다.
oc apply -f
1.5.3.1.3. 프로비저닝 리소스 생성 또는 수정
중앙 인프라 관리 서비스를 활성화하려면 프로비저닝
리소스가 필요합니다.
다음 명령을 실행하여
프로비저닝
리소스가 있는지 확인합니다.oc get provisioning
-
프로비저닝 리소스가 이미 있는 경우
프로비저닝
리소스 를 계속 수정합니다. -
프로비저닝
리소스가 없는 경우 리소스를 찾을 수 없음
오류가 표시됩니다.프로비저닝
리소스 생성을 계속합니다.
-
프로비저닝 리소스가 이미 있는 경우
1.5.3.1.3.1. 프로비저닝 리소스 수정
프로비저닝
리소스가 이미 있는 경우 hub 클러스터가 다음 플랫폼 중 하나에 설치된 경우 리소스를 수정해야 합니다.
- 베어 메탈
- Red Hat OpenStack Platform
- VMware vSphere
-
사용자 프로비저닝 인프라(UPI) 방법 및 플랫폼은
None
입니다.
허브 클러스터가 다른 플랫폼에 설치된 경우 연결이 끊긴 환경에서 중앙 인프라 관리 활성화 또는 연결된 환경에서 중앙 인프라 관리 활성화에서 계속 진행하십시오.
다음 명령을 실행하여 Bare Metal Operator가 모든 네임스페이스를 조사할 수 있도록
프로비저닝
리소스를 수정합니다.oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
1.5.3.1.3.2. 프로비저닝 리소스 생성
프로비저닝
리소스가 없는 경우 다음 단계를 완료합니다.
다음 YAML 콘텐츠를 추가하여
프로비저닝
리소스를 생성합니다.apiVersion: metal3.io/v1alpha1 kind: Provisioning metadata: name: provisioning-configuration spec: provisioningNetwork: "Disabled" watchAllNamespaces: true
다음 명령을 실행하여 콘텐츠를 적용합니다.
oc apply -f
1.5.3.1.4. 연결이 끊긴 환경에서 중앙 인프라 관리 활성화
연결이 끊긴 환경에서 중앙 인프라 관리를 활성화하려면 다음 단계를 완료합니다.
인프라 Operator와 동일한 네임스페이스에
ConfigMap
을 생성하여 미러 레지스트리의ca-bundle.crt
및registries.conf
값을 지정합니다. 파일ConfigMap
은 다음 예와 유사할 수 있습니다.apiVersion: v1 kind: ConfigMap metadata: name: <mirror-config> namespace: multicluster-engine labels: app: assisted-service data: ca-bundle.crt: | <certificate-content> registries.conf: | unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "registry.redhat.io/multicluster-engine" mirror-by-digest-only = true [[registry.mirror]] location = "mirror.registry.com:5000/multicluster-engine"
참고: 다이제스트를 사용하여 릴리스 이미지가 지정되므로
mirror-by-digest-only
를true
로 설정해야 합니다.unqualified-search-registries
목록의 레지스트리는PUBLIC_CONTAINER_REGISTRIES
환경 변수의 인증 무시 목록에 자동으로 추가됩니다. 관리 클러스터의 풀 시크릿을 검증할 때 지정된 레지스트리는 인증이 필요하지 않습니다.-
모든
osImage
요청과 함께 보낼 헤더 및 쿼리 매개변수를 나타내는 키 쌍을 작성합니다. 두 매개변수가 모두 필요하지 않은 경우 헤더 또는 쿼리 매개변수에만 대한 키 쌍을 작성합니다.
중요: 헤더 및 쿼리 매개변수는 HTTPS를 사용하는 경우에만 암호화됩니다. 보안 문제를 방지하려면 HTTPS를 사용해야 합니다.
headers
라는 파일을 생성하고 다음 예제와 유사한 콘텐츠를 추가합니다.{ "Authorization": "Basic xyz" }
query_params
라는 파일을 생성하고 다음 예와 유사한 콘텐츠를 추가합니다.{ "api_key": "myexampleapikey", }
다음 명령을 실행하여 생성한 매개변수 파일에서 시크릿을 생성합니다. 하나의 매개변수 파일만 생성한 경우 생성하지 않은 파일의 인수를 제거합니다.
oc create secret generic -n multicluster-engine os-images-http-auth --from-file=./query_params --from-file=./headers
자체 서명 또는 타사 CA 인증서와 함께 HTTPS
osImages
를 사용하려면image-service-additional-ca
ConfigMap
에 인증서를 추가합니다. 인증서를 생성하려면 다음 명령을 실행합니다.oc -n multicluster-engine create configmap image-service-additional-ca --from-file=tls.crt
agent_service_config.yaml
파일에 다음 YAML 콘텐츠를 저장하여AgentServiceConfig
사용자 지정 리소스를 생성합니다.apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: name: agent spec: databaseStorage: accessModes: - ReadWriteOnce resources: requests: storage: <db_volume_size> filesystemStorage: accessModes: - ReadWriteOnce resources: requests: storage: <fs_volume_size> mirrorRegistryRef: name: <mirror_config> 1 unauthenticatedRegistries: - <unauthenticated_registry> 2 imageStorage: accessModes: - ReadWriteOnce resources: requests: storage: <img_volume_size> 3 OSImageAdditionalParamsRef: name: os-images-http-auth OSImageCACertRef: name: image-service-additional-ca osImages: - openshiftVersion: "<ocp_version>" 4 version: "<ocp_release_version>" 5 url: "<iso_url>" 6 cpuArchitecture: "x86_64"
- 1 1
mirror_config
를 미러 레지스트리 구성 세부 정보가 포함된ConfigMap
의 이름으로 교체합니다.- 2
- 인증이 필요하지 않은 미러 레지스트리를 사용하는 경우 선택적
unauthenticated_registry
매개변수를 포함합니다. 이 목록의 항목은 검증되지 않았거나 풀 시크릿에 항목이 있어야 합니다. - 3
img_volume_size
를imageStorage
필드의 볼륨 크기로 바꿉니다(예: 운영 체제 이미지당10Gi
). 최소 값은10Gi
이지만 권장 값은 최소50Gi
입니다. 이 값은 클러스터 이미지에 할당된 스토리지 양을 지정합니다. 실행 중인 Red Hat Enterprise Linux CoreOS의 각 인스턴스에 대해 1GB의 이미지 스토리지를 허용해야 합니다. Red Hat Enterprise Linux CoreOS 클러스터 및 인스턴스가 많은 경우 더 높은 값을 사용해야 할 수 있습니다.- 4
ocp_version
을 설치할 OpenShift Container Platform 버전으로 교체합니다(예:4.13
).- 5
ocp_release_version
을 특정 설치 버전 (예:49.83.202103251640-0
)으로 바꿉니다.- 6
iso_url
을 ISO URL로 바꿉니다(예:https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.13/4.13.3/rhcos-4.13.3-x86_64-live.x86_64.iso
). 다른 값은 4.12.3 종속 항목에서 찾을 수 있습니다.
자체 서명 또는 타사 CA 인증서가 있는 HTTPS osImages
를 사용하는 경우 OSImageCACertRef
사양의 인증서를 참조하십시오.
중요: AgentServiceConfig
사용자 정의 리소스의 spec.osImages
릴리스를 버전 4.13 이상인 경우 클러스터를 생성할 때 사용하는 OpenShift Container Platform 릴리스 이미지는 버전 4.13 이상이어야 합니다. 버전 4.13 이상용 Red Hat Enterprise Linux CoreOS 이미지는 버전 4.13 이전의 이미지와 호환되지 않습니다.
assisted-service
및 assisted-image-service
배포를 확인하고 Pod가 준비되어 실행 중인지 확인하여 중앙 인프라 관리 서비스가 정상인지 확인할 수 있습니다.
1.5.3.1.5. 연결된 환경에서 중앙 인프라 관리 활성화
연결된 환경에서 중앙 인프라 관리를 활성화하려면 agent_service_config.yaml
파일에 다음 YAML 콘텐츠를 저장하여 AgentServiceConfig
사용자 지정 리소스를 생성합니다.
apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: name: agent spec: databaseStorage: accessModes: - ReadWriteOnce resources: requests: storage: <db_volume_size> 1 filesystemStorage: accessModes: - ReadWriteOnce resources: requests: storage: <fs_volume_size> 2 imageStorage: accessModes: - ReadWriteOnce resources: requests: storage: <img_volume_size> 3
- 1
db_volume_size
를databaseStorage
필드의 볼륨 크기(예:10Gi
)로 바꿉니다. 이 값은 클러스터의 데이터베이스 테이블 및 데이터베이스 뷰와 같은 파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 필요한 최소 값은1Gi
입니다. 클러스터가 여러 개인 경우 더 높은 값을 사용해야 할 수 있습니다.- 2
fs_volume_size
를filesystemStorage
필드의 볼륨 크기로 바꿉니다(예: 클러스터당200M
, 지원되는 OpenShift Container Platform 버전당2-3Gi
). 필요한 최소 값은1Gi
이지만 권장 값은100Gi
이상이어야 합니다. 이 값은 클러스터의 로그, 매니페스트 및kubeconfig
파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 클러스터가 여러 개인 경우 더 높은 값을 사용해야 할 수 있습니다.- 3
img_volume_size
를imageStorage
필드의 볼륨 크기로 바꿉니다(예: 운영 체제 이미지당10Gi
). 최소 값은10Gi
이지만 권장 값은 최소50Gi
입니다. 이 값은 클러스터 이미지에 할당된 스토리지 양을 지정합니다. 실행 중인 Red Hat Enterprise Linux CoreOS의 각 인스턴스에 대해 1GB의 이미지 스토리지를 허용해야 합니다. Red Hat Enterprise Linux CoreOS 클러스터 및 인스턴스가 많은 경우 더 높은 값을 사용해야 할 수 있습니다.
중앙 인프라 관리 서비스가 구성되어 있습니다. assisted-service
및 assisted-image-service
배포를 확인하고 Pod가 준비되고 실행 중인지 확인하여 정상 상태인지 확인할 수 있습니다.
1.5.3.1.6. 추가 리소스
- 제로 터치 프로비저닝에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 네트워크 맨 위에 있는 클러스터를 참조하십시오.
- 이미지 풀 시크릿 사용을참조하십시오.
1.5.3.2. Amazon Web Services에서 중앙 인프라 관리 활성화
Amazon Web Services에서 Hub 클러스터를 실행하고 중앙 인프라 관리 서비스를 활성화하려면 중앙 인프라 관리 서비스를 활성화한 후 다음 단계를 완료합니다.
hub 클러스터에 로그인했는지 확인하고 다음 명령을 실행하여
assisted-image-service
에 구성된 고유한 도메인을 찾습니다.oc get routes --all-namespaces | grep assisted-image-service
도메인은 다음 예와 유사할 수 있습니다.
assisted-image-service-multicluster-engine.apps.<yourdomain>.com
hub 클러스터에 로그인했는지 확인하고
NLB
type
매개변수를 사용하여 고유한 도메인으로 새IngressController
를 생성합니다. 다음 예제를 참조하십시오.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: ingress-controller-with-nlb namespace: openshift-ingress-operator spec: domain: nlb-apps.<domain>.com routeSelector: matchLabels: router-type: nlb endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: External providerParameters: type: AWS aws: type: NLB
-
nlb-apps.<
매개변수에 <domain
>.com에서 <yourdomain
>을 <yourdomain>으로 교체하여IngressController
의 domainyourdomain
>을 추가합니다. 다음 명령을 실행하여 새
IngressController
를 적용합니다.oc apply -f ingresscontroller.yaml
다음 단계를 완료하여 새
IngressController
의spec.domain
매개변수 값이 기존IngressController
와 충돌하지 않는지 확인합니다.다음 명령을 실행하여 모든
IngressController
를 나열합니다.oc get ingresscontroller -n openshift-ingress-operator
방금 생성한
ingress-controller-with-nlb
를 제외하고 각IngressController
에서 다음 명령을 실행합니다.oc edit ingresscontroller <name> -n openshift-ingress-operator
spec.domain
보고서가 없는 경우nlb-apps.<domain>.com을 제외한 클러스터에 노출된 모든 경로와 일치하는 기본 도메인
을 추가합니다.spec.domain
보고서가 제공된 경우nlb-apps.<domain>.com
경로가 지정된 범위에서 제외되었는지 확인합니다.
다음 명령을 실행하여
nlb-apps
위치를 사용하도록assisted-image-service
경로를 편집합니다.oc edit route assisted-image-service -n <namespace>
기본 네임스페이스는 다중 클러스터 엔진 Operator를 설치한 위치입니다.
assisted-image-service
경로에 다음 행을 추가합니다.metadata: labels: router-type: nlb name: assisted-image-service
assisted-image-service
경로에서spec.host
의 URL 값을 찾습니다. URL은 다음 예와 유사할 수 있습니다.assisted-image-service-multicluster-engine.apps.<yourdomain>.com
-
새
IngressController
에 구성된 도메인과 일치하도록 URL의 앱을nlb-
로 교체합니다.apps
Amazon Web Services에서 중앙 인프라 관리 서비스가 활성화되어 있는지 확인하려면 다음 명령을 실행하여 Pod가 정상 상태인지 확인합니다.
oc get pods -n multicluster-engine | grep assist
-
새 호스트 인벤토리를 생성하고 다운로드 URL이 새
nlb-apps
URL을 사용하는지 확인합니다.
1.5.3.3. 콘솔을 사용하여 호스트 인벤토리 생성
호스트 인벤토리(인프라 환경)를 생성하여 OpenShift Container Platform 클러스터를 설치할 수 있는 물리적 또는 가상 머신을 검색할 수 있습니다.
1.5.3.3.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
1.5.3.3.2. 호스트 인벤토리 생성
콘솔을 사용하여 호스트 인벤토리를 생성하려면 다음 단계를 완료합니다.
- 콘솔에서 인프라 > 호스트 인벤토리 로 이동하여 인프라 환경 생성 을 클릭합니다.
호스트 인벤토리 설정에 다음 정보를 추가합니다.
-
이름: 인프라 환경의 고유 이름입니다. 콘솔을 사용하여 인프라 환경을 생성하면 선택한 이름으로
InfraEnv
리소스의 새 네임스페이스도 생성됩니다. 명령줄 인터페이스를 사용하여InfraEnv
리소스를 생성하고 콘솔에서 리소스를 모니터링하려면 네임스페이스와InfraEnv
에 동일한 이름을 사용합니다. - 네트워크 유형: 인프라 환경에 추가하는 호스트가 DHCP 또는 정적 네트워킹을 사용하는지 여부를 지정합니다. 정적 네트워킹 구성에는 추가 단계가 필요합니다.
- Location: 호스트의 지리적 위치를 지정합니다. 지리적 위치는 호스트가 있는 데이터 센터를 정의하는 데 사용할 수 있습니다.
- labels: 이 인프라 환경에서 검색된 호스트에 레이블을 추가할 수 있는 선택적 필드입니다. 지정된 위치가 레이블 목록에 자동으로 추가됩니다.
- 인프라 공급자 인증 정보: 인프라 공급자 인증 정보를 선택하면 풀 시크릿 및 SSH 공개 키 필드가 인증 정보에 자동으로 채워집니다. 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.
- 풀 시크릿: OpenShift Container Platform 리소스에 액세스할 수 있는 OpenShift Container Platform 풀 시크릿 입니다. 인프라 공급자 인증 정보를 선택한 경우 이 필드가 자동으로 채워집니다.
-
SSH 공개 키: 호스트와의 보안 통신을 활성화하는 SSH 키입니다. 문제 해결을 위해 호스트에 연결하는 데 사용할 수 있습니다. 클러스터를 설치한 후에는 더 이상 SSH 키를 사용하여 호스트에 연결할 수 없습니다. 키는 일반적으로
id_rsa.pub
파일에 있습니다. 기본 파일 경로는~/.ssh/id_rsa.pub
입니다. SSH 공개 키 값이 포함된 인프라 공급자 인증 정보를 선택한 경우 이 필드가 자동으로 채워집니다. 호스트에 프록시 설정을 활성화하려면 활성화할 설정을 선택하고 다음 정보를 입력합니다.
- HTTP 프록시 URL: HTTP 요청에 대한 프록시의 URL입니다.
- HTTPS 프록시 URL: HTTP 요청에 대한 프록시의 URL입니다. URL은 HTTP로 시작해야 합니다. HTTPS는 지원되지 않습니다. 값을 지정하지 않으면 HTTP 프록시 URL이 기본적으로 HTTP 및 HTTPS 연결에 사용됩니다.
-
프록시 도메인 없음: 프록시를 사용하지 않으려는 쉼표로 구분된 도메인 목록입니다. 마침표(
.
)로 도메인 이름을 시작하여 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표(*
)를 추가합니다.
- 선택적으로 NTP 풀 또는 서버의 쉼표로 구분된 IP 또는 도메인 이름 목록을 제공하여 고유한 NTP(Network Time Protocol) 소스를 추가합니다.
-
이름: 인프라 환경의 고유 이름입니다. 콘솔을 사용하여 인프라 환경을 생성하면 선택한 이름으로
콘솔에서 사용할 수 없는 고급 구성 옵션이 필요한 경우 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을 계속합니다.
고급 구성 옵션이 필요하지 않은 경우 정적 네트워킹을 구성하여 계속해서 인프라 환경에 호스트를 추가할 수 있습니다.
1.5.3.3.3. 호스트 인벤토리에 액세스
호스트 인벤토리에 액세스하려면 콘솔에서 인프라 > 호스트 인벤토리 를 선택합니다. 목록에서 인프라 환경을 선택하여 세부 정보 및 호스트를 확인합니다.
1.5.3.3.4. 추가 리소스
- 중앙 인프라 관리 서비스 활성화를참조하십시오.
- 온-프레미스 환경에 대한 인증 정보 생성을 참조하십시오.
- 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을참조하십시오.
베어 메탈에서 호스팅된 컨트롤 플레인을 구성하는 프로세스의 일부로 이 절차를 완료한 경우 다음 절차를 완료하는 것입니다.
1.5.3.4. 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성
호스트 인벤토리(인프라 환경)를 생성하여 OpenShift Container Platform 클러스터를 설치할 수 있는 물리적 또는 가상 머신을 검색할 수 있습니다. 자동화된 배포 또는 다음 고급 구성 옵션에는 콘솔 대신 명령줄 인터페이스를 사용합니다.
- 검색된 호스트를 기존 클러스터 정의에 자동으로 바인딩
- Discovery Image의 ignition 구성 덮어쓰기
- iPXE 동작 제어
- Discovery Image의 커널 인수 수정
- 검색 단계에서 호스트가 신뢰할 수 있는 추가 인증서 전달
- 최신 버전의 기본 옵션이 아닌 테스트를 위해 부팅할 Red Hat CoreOS 버전을 선택합니다.
1.5.3.4.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
1.5.3.4.2. 호스트 인벤토리 생성
명령줄 인터페이스를 사용하여 호스트 인벤토리(인프라 환경)를 생성하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 허브 클러스터에 로그인합니다.
oc login
리소스의 네임스페이스를 생성합니다.
namespace.yaml
파일을 생성하고 다음 콘텐츠를 추가합니다.apiVersion: v1 kind: Namespace metadata: name: <your_namespace> 1
- 1
- 네임스페이스에서 동일한 이름을 사용하여 콘솔에서 인벤토리를 모니터링합니다.
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f namespace.yaml
OpenShift Container Platform 풀 보안이 포함된
Secret
사용자 정의 리소스를 생성합니다.pull-secret.yaml
파일을 생성하고 다음 콘텐츠를 추가합니다.apiVersion: v1 kind: Secret type: kubernetes.io/dockerconfigjson metadata: name: pull-secret 1 namespace: <your_namespace> stringData: .dockerconfigjson: <your_pull_secret> 2
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f pull-secret.yaml
인프라 환경을 생성합니다.
infra-env.yaml
파일을 생성하고 다음 콘텐츠를 추가합니다. 필요한 경우 값을 바꿉니다.apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: myinfraenv namespace: <your_namespace> spec: proxy: httpProxy: <http://user:password@ipaddr:port> httpsProxy: <http://user:password@ipaddr:port> noProxy: additionalNTPSources: sshAuthorizedKey: pullSecretRef: name: <name> agentLabels: <key>: <value> nmStateConfigLabelSelector: matchLabels: <key>: <value> clusterRef: name: <cluster_name> namespace: <project_name> ignitionConfigOverride: '{"ignition": {"version": "3.1.0"}, …}' cpuArchitecture: x86_64 ipxeScriptType: DiscoveryImageAlways kernelArguments: - operation: append value: audit=0 additionalTrustBundle: <bundle> osImageVersion: <version>
필드 | 선택 사항 또는 필수 | 설명 |
---|---|---|
| 선택 사항 |
|
| 선택 사항 |
HTTP 요청에 대한 프록시의 URL입니다. URL은 |
| 선택 사항 |
HTTP 요청에 대한 프록시의 URL입니다. URL은 |
| 선택 사항 | 프록시를 사용하지 않으려는 쉼표로 구분된 도메인 및 CIDR 목록입니다. |
| 선택 사항 | 모든 호스트에 추가할 NTP(Network Time Protocol) 소스(hostname 또는 IP) 목록입니다. DHCP와 같은 다른 옵션을 사용하여 구성된 NTP 소스에 추가됩니다. |
| 선택 사항 | 검색 단계에서 디버깅에 사용할 수 있도록 모든 호스트에 추가된 SSH 공개 키입니다. 검색 단계는 호스트가 검색 이미지를 부팅하는 단계입니다. |
| 필수 항목 | 풀 보안이 포함된 Kubernetes 시크릿의 이름입니다. |
| 선택 사항 |
|
| 선택 사항 |
호스트의 고정 IP, 브리지 및 본딩과 같은 고급 네트워크 구성을 통합합니다. 호스트 네트워크 구성은 선택한 라벨을 사용하여 하나 이상의 |
| 선택 사항 |
독립 실행형 온-프레미스 클러스터를 설명하는 기존 |
| 선택 사항 |
Red Hat CoreOS 라이브 이미지의 ignition 구성(예: 파일 추가)을 수정합니다. 필요한 경우에만 |
| 선택 사항 | 지원되는 CPU 아키텍처(x86_64, aarch64, ppc64le 또는 s390x) 중 하나를 선택합니다. 기본값은 x86_64입니다. |
| 선택 사항 |
|
| 선택 사항 |
Discovery Image가 부팅될 때 에 대한 커널 인수를 수정할 수 있습니다. |
| 선택 사항 |
PEM 인코딩 X.509 인증서 번들, 일반적으로 호스트가 다시 암호화하는 MITTM(man-in-the-middle) 프록시가 있는 네트워크에 있거나 호스트가 컨테이너 이미지 레지스트리와 같은 다른 목적으로 인증서를 신뢰해야 하는 경우 필요합니다. |
| 선택 사항 |
|
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f infra-env.yaml
호스트 인벤토리가 생성되었는지 확인하려면 다음 명령을 사용하여 상태를 확인합니다.
oc describe infraenv myinfraenv -n <your_namespace>
다음 주요 속성 목록을 참조하십시오.
-
conditions
: 이미지가 생성되었는지를 나타내는 표준 Kubernetes 상태입니다. -
isoDownloadURL
: Discovery Image를 다운로드할 URL입니다. -
createdTime
: 이미지가 마지막으로 생성된 시간입니다.InfraEnv
를 수정하는 경우 새 이미지를 다운로드하기 전에 타임스탬프가 업데이트되었는지 확인합니다.
참고: InfraEnv
리소스를 수정하는 경우, createdTime
속성을 확인하여 InfraEnv
에서 새 Discovery Image를 생성했는지 확인합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.
필요한 경우 정적 네트워킹을 구성하고 인프라 환경에 호스트를 추가할 수 있습니다.
1.5.3.4.3. 추가 리소스
- 중앙 인프라 관리 서비스 활성화를 참조하십시오.
1.5.3.5. 인프라 환경에 대한 고급 네트워킹 구성
단일 인터페이스에서 DHCP 이외의 네트워킹이 필요한 호스트의 경우 고급 네트워킹을 구성해야 합니다. 필수 구성에는 하나 이상의 호스트에 대한 네트워킹을 설명하는 NMStateConfig
리소스의 인스턴스 생성이 포함됩니다.
각 NMStateConfig
리소스에는 InfraEnv
리소스의 nmStateConfigLabelSelector
와 일치하는 레이블이 포함되어야 합니다. nmStateConfigLabelSelector
에 대한 자세한 내용은 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성 을 참조하십시오.
Discovery Image에는 참조된 모든 NMStateConfig
리소스에 정의된 네트워크 구성이 포함되어 있습니다. 부팅 후 각 호스트는 각 구성을 네트워크 인터페이스와 비교하고 적절한 구성을 적용합니다.
1.5.3.5.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다.
- 호스트 인벤토리를 생성해야 합니다.
1.5.3.5.2. 명령줄 인터페이스를 사용하여 고급 네트워킹 구성
명령줄 인터페이스를 사용하여 인프라 환경에 대한 고급 네트워킹을 구성하려면 다음 단계를 완료합니다.
nmstateconfig.yaml
이라는 파일을 생성하고 다음 템플릿과 유사한 콘텐츠를 추가합니다. 필요한 경우 값을 바꿉니다.apiVersion: agent-install.openshift.io/v1beta1 kind: NMStateConfig metadata: name: mynmstateconfig namespace: <your-infraenv-namespace> labels: some-key: <some-value> spec: config: interfaces: - name: eth0 type: ethernet state: up mac-address: 02:00:00:80:12:14 ipv4: enabled: true address: - ip: 192.168.111.30 prefix-length: 24 dhcp: false - name: eth1 type: ethernet state: up mac-address: 02:00:00:80:12:15 ipv4: enabled: true address: - ip: 192.168.140.30 prefix-length: 24 dhcp: false dns-resolver: config: server: - 192.168.126.1 routes: config: - destination: 0.0.0.0/0 next-hop-address: 192.168.111.1 next-hop-interface: eth1 table-id: 254 - destination: 0.0.0.0/0 next-hop-address: 192.168.140.1 next-hop-interface: eth1 table-id: 254 interfaces: - name: "eth0" macAddress: "02:00:00:80:12:14" - name: "eth1" macAddress: "02:00:00:80:12:15"
필드 | 선택 사항 또는 필수 | 설명 |
---|---|---|
| 필수 항목 | 구성 중인 호스트 또는 호스트와 관련된 이름을 사용합니다. |
| 필수 항목 |
네임스페이스는 |
| 필수 항목 |
|
| 선택 사항 |
|
| 선택 사항 |
지정된 |
참고: 이미지 서비스는 InfraEnv
속성을 업데이트하거나 레이블 선택기와 일치하는 NMStateConfig
리소스를 변경할 때 새 이미지를 자동으로 생성합니다.
리소스를 생성한 후 InfraEnv
NMStateConfig
리소스를 추가하는 경우 InfraEnv에서 InfraEnv
에서 createdTime
속성을 확인하여 새 Discovery Image를 생성해야 합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f nmstateconfig.yaml
1.5.3.5.3. 추가 리소스
- 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을참조하십시오.
- 선언 네트워크 API참조
1.5.3.6. Discovery Image를 사용하여 호스트 인벤토리에 호스트 추가
호스트 인벤토리(인프라 환경)를 생성한 후 호스트를 검색하여 인벤토리에 추가할 수 있습니다. 인벤토리에 호스트를 추가하려면 ISO를 다운로드하여 각 서버에 연결할 방법을 선택합니다. 예를 들어 가상 미디어를 사용하거나 USB 드라이브에 ISO를 작성하여 ISO를 다운로드할 수 있습니다.
중요: 설치에 실패하지 않도록 설치 프로세스 중에 장치에 Discovery ISO 미디어를 계속 연결하고 각 호스트를 한 번에 부팅하도록 설정합니다.
1.5.3.6.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
- 호스트 인벤토리를 생성해야 합니다. 자세한 내용은 콘솔을 사용하여 호스트 인벤토리 생성 을 참조하십시오.
1.5.3.6.2. 콘솔을 사용하여 호스트 추가
다음 단계를 완료하여 ISO를 다운로드합니다.
- 콘솔에서 Infrastructure > Host inventory 를 선택합니다.
- 목록에서 인프라 환경을 선택합니다.
- 호스트 추가를 클릭하고 Discovery ISO 사용을 선택합니다.
이제 ISO를 다운로드할 URL이 표시됩니다. 부팅된 호스트가 호스트 인벤토리 테이블에 나타납니다. 호스트가 표시되는 데 몇 분이 걸릴 수 있습니다. 각 호스트를 사용하려면 먼저 승인해야 합니다. 작업을 클릭하고 승인을 선택하여 인벤토리 테이블에서 호스트를 선택할 수 있습니다.
1.5.3.6.3. 명령줄 인터페이스를 사용하여 호스트 추가
InfraEnv
리소스의 상태에서 isoDownloadURL
속성에서 ISO를 다운로드하는 URL을 볼 수 있습니다. InfraEnv
리소스에 대한 자세한 내용은 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을 참조하십시오.
부팅된 각 호스트는 동일한 네임스페이스에 에이전트
리소스를 생성합니다. 각 호스트를 사용하려면 먼저 승인해야 합니다.
1.5.3.6.4. 추가 리소스
- 중앙 인프라 관리 서비스 활성화를참조하십시오.
- 콘솔을 사용하여 호스트 인벤토리 생성을참조하십시오.
- 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을참조하십시오.
1.5.3.7. 호스트 인벤토리에 베어 메탈 호스트 자동 추가
호스트 인벤토리(인프라 환경)를 생성한 후 호스트를 검색하여 인벤토리에 추가할 수 있습니다. 베어 메탈 Operator가 각 베어 메탈 호스트의 BMC(Baseboard Management Controller)와 각 호스트에 대해 BareMetalHost
리소스 및 관련 BMC 시크릿을 생성하여 인프라 환경의 검색 이미지 부팅을 자동화할 수 있습니다. 자동화는 인프라 환경을 참조하는 BareMetalHost
의 레이블로 설정됩니다.
자동화는 다음 작업을 수행합니다.
- 인프라 환경에서 표시하는 Discovery Image를 사용하여 각 베어 메탈 호스트 부팅
- 인프라 환경 또는 관련 네트워크 구성이 업데이트되는 경우 각 호스트를 최신 검색 이미지로 재부팅
-
검색 시 각
에이전트
리소스를 해당BareMetalHost
리소스와 연결합니다. -
호스트 이름, 역할 및 설치 디스크와 같은
BareMetalHost
의 정보를 기반으로에이전트
리소스 속성 업데이트 -
클러스터 노드로 사용할
에이전트
승인
1.5.3.7.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다.
- 호스트 인벤토리를 생성해야 합니다.
1.5.3.7.2. 콘솔을 사용하여 베어 메탈 호스트 추가
콘솔을 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.
- 콘솔에서 Infrastructure > Host inventory 를 선택합니다.
- 목록에서 인프라 환경을 선택합니다.
- 호스트 추가를 클릭하고 BMC 양식으로 를 선택합니다.
- 필요한 정보를 추가하고 생성 을 클릭합니다.
1.5.3.7.3. 명령줄 인터페이스를 사용하여 베어 메탈 호스트 추가
명령줄 인터페이스를 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.
다음 YAML 콘텐츠를 적용하고 필요한 경우 값을 교체하여 BMC 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <bmc-secret-name> namespace: <your_infraenv_namespace> 1 type: Opaque data: username: <username> password: <password>
- 1
- 네임스페이스는
InfraEnv
의 네임스페이스와 동일해야 합니다.
다음 YAML 콘텐츠를 적용하고 필요한 경우 값을 교체하여 베어 메탈 호스트를 생성합니다.
apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: <bmh-name> namespace: <your_infraenv_namespace> 1 annotations: inspect.metal3.io: disabled labels: infraenvs.agent-install.openshift.io: <your-infraenv> 2 spec: online: true automatedCleaningMode: disabled 3 bootMACAddress: <your-mac-address> 4 bmc: address: <machine-address> 5 credentialsName: <bmc-secret-name> 6 rootDeviceHints: deviceName: /dev/sda 7
- 1
- 네임스페이스는
InfraEnv
의 네임스페이스와 동일해야 합니다. - 2
- 이름은
InfrEnv
의 이름과 일치해야 하며 동일한 네임스페이스에 있어야 합니다. - 3
- 값을 설정하지 않으면
메타데이터
값이 자동으로 사용됩니다. - 4
- MAC 주소가 호스트의 상호 작용 중 하나의 MAC 주소와 일치하는지 확인합니다.
- 5
- BMC 주소를 사용합니다. 자세한 내용은 대역 외 관리 IP 주소에 대한 포트 액세스를 참조하십시오.
- 6
credentialsName
값이 생성한 BMC 시크릿의 이름과 일치하는지 확인합니다.- 7
- 선택 사항: 설치 디스크를 선택합니다. 사용 가능한 루트 장치 팁은 BareMetalHost 사양 을 참조하십시오. 호스트를 검색 이미지로 부팅하고 해당
에이전트
리소스가 생성되면 이 팁에 따라 설치 디스크가 설정됩니다.
호스트를 켜면 이미지가 다운로드되기 시작합니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. 호스트가 검색되면 에이전트
사용자 지정 리소스가 자동으로 생성됩니다.
1.5.3.7.4. 통합 흐름 비활성화
통합 흐름은 기본적으로 활성화되어 있습니다. 호스트가 나타나지 않으면 통합 흐름을 일시적으로 비활성화해야 할 수 있습니다. 통합 흐름을 비활성화하려면 다음 단계를 완료합니다.
허브 클러스터에 다음 구성 맵을 생성합니다.
apiVersion: v1 kind: ConfigMap metadata: name: my-assisted-service-config namespace: multicluster-engine data: ALLOW_CONVERGED_FLOW: "false"
참고:
ALLOW_CONVERGED_FLOW
를"false"
로 설정하면 Ironic Python 에이전트에서 활성화한 모든 기능도 비활성화합니다.다음 명령을 실행하여 구성 맵을 적용합니다.
oc annotate --overwrite AgentServiceConfig agent unsupported.agent-install.openshift.io/assisted-service-configmap=my-assisted-service-config
1.5.3.7.5. 명령줄 인터페이스를 사용하여 관리형 클러스터 노드 제거
관리형 클러스터에서 관리형 클러스터 노드를 제거하려면 OpenShift Container Platform 버전 4.13 이상을 실행 중인 허브 클러스터가 필요합니다. 노드를 부팅하는 데 필요한 정적 네트워킹 구성을 사용할 수 있어야 합니다. 에이전트 및 베어 메탈 호스트를 삭제할 때 NMStateConfig
리소스를 삭제하지 마십시오.
1.5.3.7.5.1. 베어 메탈 호스트를 사용하여 관리형 클러스터 노드 제거
허브 클러스터에 베어 메탈 호스트가 있고 관리 클러스터에서 관리 클러스터 노드를 제거하려면 다음 단계를 완료합니다.
삭제하려는 노드의
BareMetalHost
리소스에 다음 주석을 추가합니다.bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
다음 명령을 실행하여
BareMetalHost
리소스를 삭제합니다. <bmh-name&
gt;을BareMetalHost
의 이름으로 바꿉니다.oc delete bmh <bmh-name>
1.5.3.7.5.2. 베어 메탈 호스트 없이 관리형 클러스터 노드 제거
hub 클러스터에 베어 메탈 호스트가 없고 관리 클러스터에서 관리 클러스터 노드를 제거하려면 OpenShift Container Platform 설명서의 노드 삭제 지침을 따르십시오.
1.5.3.7.6. 추가 리소스
- 제로 터치 프로비저닝에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 네트워크 맨 위에 있는 클러스터를 참조하십시오.
- 베어 메탈 호스트 사용에 필요한 포트에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 대역 외 관리 IP 주소에 대한 포트 액세스를 참조하십시오.
- 루트 장치 팁에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 BareMetalHost 사양 을 참조하십시오.
- 이미지 풀 시크릿 사용을참조하십시오.
- 온-프레미스 환경에 대한 인증 정보 생성을 참조하십시오.
- 컴퓨팅 머신 스케일링에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 컴퓨팅 머신 세트 수동 스케일링을 참조하십시오.
- 통합 흐름에 대한 자세한 내용은 배포 후 보류 중 상태의 관리형 클러스터를 참조하십시오.
1.5.3.8. 호스트 인벤토리 관리
콘솔을 사용하거나 명령줄 인터페이스를 사용하여 호스트 인벤토리를 관리하고 기존 호스트를 편집하고 Agent
리소스를 편집할 수 있습니다.
1.5.3.8.1. 콘솔을 사용하여 호스트 인벤토리 관리
Discovery ISO로 성공적으로 부팅한 각 호스트는 호스트 인벤토리에 행으로 표시됩니다. 콘솔을 사용하여 호스트를 편집하고 관리할 수 있습니다. 호스트를 수동으로 부팅하고 베어 메탈 Operator 자동화를 사용하지 않는 경우 콘솔에서 호스트를 승인해야 사용할 수 있습니다. OpenShift 노드로 설치할 준비가 된 호스트의 상태는 Available
입니다.
1.5.3.8.2. 명령줄 인터페이스를 사용하여 호스트 인벤토리 관리
에이전트 리소스는
각 호스트를 나타냅니다. 에이전트
리소스에서 다음 속성을 설정할 수 있습니다.
clusterDeploymentName
이 속성을 클러스터에 노드로 설치하려는 경우 사용할
ClusterDeployment
의 네임스페이스 및 이름으로 설정합니다.선택 사항:
role
클러스터에서 호스트의 역할을 설정합니다. 가능한 값은
master
,worker
,auto-assign
입니다. 기본값은auto-assign
입니다.hostname
호스트의 호스트 이름을 설정합니다. 호스트에 유효한 호스트 이름이 자동으로 할당되는 경우(예: DHCP 사용) 선택 사항입니다.
승인됨
호스트를 OpenShift 노드로 설치할 수 있는지 여부를 나타냅니다. 이 속성은 기본값이
False
인 부울입니다. 호스트를 수동으로 부팅하고 베어 메탈 Operator 자동화를 사용하지 않는 경우 호스트를 설치하기 전에 이 속성을True
로 설정해야 합니다.installation_disk_id
선택한 설치 디스크의 ID가 호스트의 인벤토리에 표시됩니다.
installerArgs
호스트의 coreos-installer 인수에 대한 덮어쓰기가 포함된 JSON 형식의 문자열입니다. 이 속성을 사용하여 커널 인수를 수정할 수 있습니다. 다음 예제 구문을 참조하십시오.
["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]
ignitionConfigOverrides
호스트의 ignition 구성에 대한 덮어쓰기가 포함된 JSON 형식의 문자열입니다. 이 속성을 사용하여 ignition을 사용하여 호스트에 파일을 추가할 수 있습니다. 다음 예제 구문을 참조하십시오.
{"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}
nodeLabels
호스트를 설치한 후 노드에 적용되는 라벨 목록입니다.
에이전트
리소스의 상태에
는 다음과 같은 속성이 있습니다.
role
클러스터에서 호스트의 역할을 설정합니다. 이전에
Agent
리소스에서역할을
설정하면 값이상태에
표시됩니다.인벤토리
호스트에서 실행 중인 에이전트가 검색하는 호스트 속성을 포함합니다.
진행 상황
호스트 설치 진행 중입니다.
ntpSources
호스트의 구성된 NTP(Network Time Protocol) 소스입니다.
conditions
True
또는False
값과 함께 다음 표준 Kubernetes 조건을 포함합니다.-
SpecSynced: 지정된 모든 속성이 성공적으로 적용되면
True
입니다.false
오류가 발생하면 false입니다. -
connected: 설치 서비스에 대한 에이전트 연결이 중단되지 않으면
True
입니다. 에이전트가 잠시 후에 설치 서비스에 도달하지 않은 경우false
입니다. -
RequirementsMet: 호스트가 설치를 시작할 준비가 되면
True
입니다. -
validated: 모든 호스트 검증이 통과하면
True
입니다. -
installed: 호스트가 OpenShift 노드로 설치된 경우
True
입니다. -
Bound: 호스트가 클러스터에 바인딩된 경우
True
입니다. -
cleanup:
Agent
resouce를 삭제하라는 요청이 실패하면False
입니다.
-
SpecSynced: 지정된 모든 속성이 성공적으로 적용되면
debugInfo
설치 로그 및 이벤트를 다운로드하기 위한 URL이 포함되어 있습니다.
validationsInfo
설치에 성공했는지 확인하기 위해 호스트가 검색된 후 에이전트가 실행되는 검증에 대한 정보가 포함되어 있습니다. 값이
False
인 경우 문제를 해결합니다.installation_disk_id
선택한 설치 디스크의 ID가 호스트의 인벤토리에 표시됩니다.
1.5.3.8.3. 추가 리소스
- 호스트 인벤토리 액세스를참조하십시오.
- coreos-installer 설치참조
1.5.4. 클러스터 생성
다중 클러스터 엔진 Operator를 사용하여 클라우드 공급자 간에 Red Hat OpenShift Container Platform 클러스터를 생성하는 방법을 알아봅니다.
다중 클러스터 엔진 Operator는 OpenShift Container Platform과 함께 제공되는 Hive Operator를 사용하여 온프레미스 클러스터 및 호스팅 컨트롤 플레인을 제외한 모든 공급자의 클러스터를 프로비저닝합니다. 온프레미스 클러스터를 프로비저닝할 때 다중 클러스터 엔진 Operator는 OpenShift Container Platform과 함께 제공되는 중앙 인프라 관리 및 지원 설치 관리자 기능을 사용합니다. 호스팅된 컨트롤 플레인의 호스트 클러스터는 HyperShift Operator를 사용하여 프로비저닝됩니다.
- 클러스터 생성 중 추가 매니페스트 구성
- Amazon Web Services에서 클러스터 생성
- Amazon Web Services GovCloud에서 클러스터 생성
- Microsoft Azure에 클러스터 생성
- Google Cloud Platform에서 클러스터 생성
- VMware vSphere에서 클러스터 생성
- Red Hat OpenStack Platform에서 클러스터 생성
- Red Hat Virtualization에서 클러스터 생성 (더 이상 사용되지 않음)
- 온-프레미스 환경에서 클러스터 생성
- AgentClusterInstall 프록시 구성
- 호스팅된 컨트롤 플레인
1.5.4.1. CLI를 사용하여 클러스터 생성
Kubernetes Operator용 멀티 클러스터 엔진은 내부 Hive 구성 요소를 사용하여 Red Hat OpenShift Container Platform 클러스터를 생성합니다. 클러스터 생성 방법을 알아보려면 다음 정보를 참조하십시오.
1.5.4.1.1. 사전 요구 사항
클러스터를 생성하기 전에 clusterImageSets 리포지토리를 복제하여 hub 클러스터에 적용해야 합니다. 다음 단계를 참조하십시오.
다음 명령을 실행하여 복제하지만
2.x
를 2.5로 바꿉니다.git clone https://github.com/stolostron/acm-hive-openshift-releases.git cd acm-hive-openshift-releases git checkout origin/backplane-<2.x>
다음 명령을 실행하여 hub 클러스터에 적용합니다.
find clusterImageSets/fast -type d -exec oc apply -f {} \; 2> /dev/null
클러스터를 생성할 때 Red Hat OpenShift Container Platform 릴리스 이미지를 선택합니다.
참고: Nutanix 플랫폼을 사용하는 경우 ClusterImageSet
리소스의 releaseImage
에 x86_64
아키텍처를 사용하고 표시되는
라벨 값을 'true'
로 설정해야 합니다. 다음 예제를 참조하십시오.
apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: stable visible: 'true' name: img4.x.47-x86-64-appsub spec: releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.47-x86_64
1.5.4.1.2. ClusterDeployment을 사용하여 클러스터 생성
ClusterDeployment
은 클러스터의 라이프사이클을 제어하는 데 사용되는 Hive 사용자 정의 리소스입니다.
Hive 사용 설명서에 따라 ClusterDeployment
사용자 정의 리소스를 생성하고 개별 클러스터를 생성합니다.
1.5.4.1.3. ClusterPool로 클러스터 생성
ClusterPool
은 여러 클러스터를 생성하는 데 사용되는 Hive 사용자 정의 리소스이기도 합니다.
Cluster Pools 문서에 따라 Hive ClusterPool
API로 클러스터를 생성합니다.
1.5.4.2. 클러스터 생성 중 추가 매니페스트 구성
클러스터를 생성하는 설치 프로세스 중에 추가 Kubernetes 리소스 매니페스트를 구성할 수 있습니다. 이는 네트워킹 구성 또는 로드 밸런서 설정과 같은 시나리오에 대한 추가 매니페스트를 구성해야 하는 경우 도움이 될 수 있습니다.
클러스터를 생성하기 전에 추가 리소스 매니페스트가 포함된 ConfigMap
을 지정하는 ClusterDeployment
리소스에 대한 참조를 추가해야 합니다.
참고: ClusterDeployment
리소스 및 ConfigMap
은 동일한 네임스페이스에 있어야 합니다. 다음 예제에서는 콘텐츠 표시 방법을 보여줍니다.
리소스 매니페스트가 있는 ConfigMap
다른
ConfigMap
리소스가 포함된 매니페스트가 포함된ConfigMap
입니다. 리소스 매니페스트ConfigMap
은data.<resource_name>\.yaml 패턴에 추가된 리소스
구성으로 여러 키를 포함할 수 있습니다.kind: ConfigMap apiVersion: v1 metadata: name: <my-baremetal-cluster-install-manifests> namespace: <mynamespace> data: 99_metal3-config.yaml: | kind: ConfigMap apiVersion: v1 metadata: name: metal3-config namespace: openshift-machine-api data: http_port: "6180" provisioning_interface: "enp1s0" provisioning_ip: "172.00.0.3/24" dhcp_range: "172.00.0.10,172.00.0.100" deploy_kernel_url: "http://172.00.0.3:6180/images/ironic-python-agent.kernel" deploy_ramdisk_url: "http://172.00.0.3:6180/images/ironic-python-agent.initramfs" ironic_endpoint: "http://172.00.0.3:6385/v1/" ironic_inspector_endpoint: "http://172.00.0.3:5150/v1/" cache_url: "http://192.168.111.1/images" rhcos_image_url: "https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.3/43.81.201911192044.0/x86_64/rhcos-43.81.201911192044.0-openstack.x86_64.qcow2.gz"
리소스 매니페스트
ConfigMap
을 참조하는 ClusterDeployment리소스 매니페스트
ConfigMap
은spec.provisioning.manifestsConfigMapRef
에서 참조됩니다.apiVersion: hive.openshift.io/v1 kind: ClusterDeployment metadata: name: <my-baremetal-cluster> namespace: <mynamespace> annotations: hive.openshift.io/try-install-once: "true" spec: baseDomain: test.example.com clusterName: <my-baremetal-cluster> controlPlaneConfig: servingCertificates: {} platform: baremetal: libvirtSSHPrivateKeySecretRef: name: provisioning-host-ssh-private-key provisioning: installConfigSecretRef: name: <my-baremetal-cluster-install-config> sshPrivateKeySecretRef: name: <my-baremetal-hosts-ssh-private-key> manifestsConfigMapRef: name: <my-baremetal-cluster-install-manifests> imageSetRef: name: <my-clusterimageset> sshKnownHosts: - "10.1.8.90 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXvVVVKUYVkuyvkuygkuyTCYTytfkufTYAAAAIbmlzdHAyNTYAAABBBKWjJRzeUVuZs4yxSy4eu45xiANFIIbwE3e1aPzGD58x/NX7Yf+S8eFKq4RrsfSaK2hVJyJjvVIhUsU9z2sBJP8=" pullSecretRef: name: <my-baremetal-cluster-pull-secret>
1.5.4.3. Amazon Web Services에서 클러스터 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 AWS(Amazon Web Services)에서 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다.
클러스터를 생성할 때 생성 프로세스는 OpenShift Container Platform 설치 프로그램을 Hive 리소스와 함께 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 OpenShift Container Platform 설명서에서 AWS에 설치 프로세스를 참조하십시오.