클러스터
클러스터 라이프사이클 및 멀티 클러스터 엔진을 사용하면 클러스터를 생성하고 관리할 수 있습니다. 클러스터 라이프사이클은 다중 클러스터 엔진 Operator를 통해 사용할 수 있습니다.
초록
1장. 멀티 클러스터 엔진 Operator 개요가 있는 클러스터 라이프사이클
멀티 클러스터 엔진 Operator는 OpenShift Container Platform 및 Red Hat Advanced Cluster Management 허브 클러스터에 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. hub 클러스터에서 클러스터를 생성 및 관리하고 생성한 클러스터를 삭제할 수 있습니다. 클러스터를 다시 시작, 재개 및 분리할 수도 있습니다. 다음 문서에서 클러스터 라이프사이클 용량에 대해 자세히 알아보십시오.
정보:
- 클러스터는 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. 릴리스 노트
현재 릴리스에 대해 알아보십시오.
참고: Red Hat Advanced Cluster Management 2.4 및 이전 버전은 서비스에서 제거 되며 더 이상 지원되지 않습니다. 버전 2.4 및 이전 버전에 대한 문서는 업데이트되지 않습니다. 이 문서는 사용 가능한 상태로 남아 있을 수 있지만 에라타 또는 기타 사용 가능한 업데이트없이 더 이상 사용되지 않습니다.
현재 지원되는 릴리스 중 하나 또는 제품 설명서에 문제가 있는 경우 문제를 해결하거나 지식베이스 문서를 보거나 지원 팀에 연결하거나 케이스를 열 수 있는 Red Hat 지원으로 이동하십시오. 자격 증명을 사용하여 로그인해야 합니다.
Red Hat 고객 포털 FAQ에서 고객 포털 문서에 대한 자세한 내용을 확인할 수도 있습니다.
1.1.1. 다중 클러스터 엔진 Operator가 있는 클러스터 라이프사이클의 새로운 기능
중요: 일부 기능 및 구성 요소는 기술 프리뷰 로 확인 및 릴리스됩니다.
이 릴리스의 새로운 기능에 대해 자세히 알아보십시오.
- Red Hat Advanced Cluster Management를 설치한 경우 welcome에서 Red Hat Advanced Cluster Management for Kubernetes로 제품 및 릴리스에 대한 개요를 확인하십시오.
- 오픈 소스 오픈 클러스터 관리 리포지토리는 오픈 커뮤니티의 상호 작용, 성장 및 기여를 위한 준비가 되어 있습니다. 참여하려면 open-cluster-management.io 를 참조하십시오. 자세한 내용은 GitHub 리포지토리에 액세스할 수 있습니다.
- 설치
- 클러스터 라이프사이클
- 호스트된 컨트롤 플레인
1.1.1.1. 설치
OpenShift Container Platform 또는 Red Hat Advanced Cluster Management를 설치한 경우 멀티 클러스터 엔진 Operator가 자동으로 제공됩니다. 다중 클러스터 엔진 Operator 설치에만 새로운 기능이 있는 경우 이 섹션에서 해당 기능을 볼 수 있습니다.
1.1.1.2. 클러스터 라이프사이클
멀티 클러스터 엔진 Operator의 클러스터 라이프사이클과 관련된 새로운 기능에 대해 알아보십시오.
-
이제 프록시를 사용하여 관리 클러스터의 모든 서비스에 연결하는 데
cluster-proxy-addon
을 사용할 수 있습니다. 허브에서 관리되는 클러스터에 직접 연결하여 일부 서비스와 상호 작용합니다. 자세한 내용은 클러스터 프록시 애드온 사용을 참조하십시오. - 이제 Amazon Web Services GovCloud에서 클러스터를 생성할 수 있습니다. 자세한 내용은 Amazon Web Services GovCloud에서 클러스터 생성을 참조하십시오.
새로운 버전의 API가 있습니다. - Clusterset
: v1beta2 - ClustersetBinding
: v1beta2 See API for more information.
- 두 가지 컨트롤 플레인 유형( hosted 및 standalone)을 사용할 수 있습니다. 독립 실행형 은 콘솔 마법사 기능이며 호스팅 은 CLI에서 클러스터를 생성할 수 있도록 특정 단계 및 지침을 제공합니다.
-
이제
MultiClusterEngine
사용자 정의 리소스를 업데이트하여 허브 클러스터가 자체적으로 관리되는지 여부를 지정할 수 있습니다. 자세한 내용은 로컬 클러스터 활성화를 참조하십시오. -
ConfigMap
및AgentServiceConfig
파일에서 설정을 수정하여 연결이 끊긴 환경에서 인프라 환경을 생성할 때 인증되지 않은 레지스트리를 지정할 수 있습니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오. - 이제 MachinePool을 사용한 스케일링을 일반적으로 사용할 수 있으므로 리소스를 확장하도록 자동 스케일링을 쉽게 구성할 수 있습니다. 자세한 내용은 MachinePool을 사용한 확장을 참조하십시오.
1.1.1.3. 호스트된 컨트롤 플레인
- 기술 프리뷰: Amazon Web Services 또는 베어 메탈 플랫폼에서 호스팅된 컨트롤 플레인 클러스터를 프로비저닝할 수 있습니다. 자세한 내용은 호스팅 컨트롤 플레인(기술 프리뷰) 을 참조하십시오.
1.1.2. 클러스터 라이프사이클 알려진 문제
다중 클러스터 엔진 Operator를 사용하여 클러스터 라이프사이클의 알려진 문제를 검토합니다. 다음 목록에는 이 릴리스의 알려진 문제 또는 이전 릴리스에서 계속된 알려진 문제가 포함되어 있습니다. OpenShift Container Platform 클러스터의 경우 OpenShift Container Platform 릴리스 노트를 참조하십시오.
1.1.2.1. 클러스터 관리
클러스터 라이프사이클 알려진 문제 및 제한 사항은 다중 클러스터 엔진 Operator 설명서의 클러스터 라이프사이클의 일부입니다.
1.1.2.1.1. 애드온을 제거할 때 관리된 클러스터에 대한 VPASync CSV 수동 제거가 필요합니다.
hub 클러스터에서 61Sync ManagedClusterAddOn
을 제거하면 관리 클러스터에서 desilSync Operator 서브스크립션을 제거하지만 CSV(클러스터 서비스 버전)는 제거하지 않습니다. 관리형 클러스터에서 CSV를 제거하려면 CloudEventSync를 제거할 각 관리형 클러스터에서 다음 명령을 실행합니다.
oc delete csv -n openshift-operators volsync-product.v0.6.0
다른 버전이 설치되어 있는 경우 v0.6.0
을 설치된 버전으로 교체합니다.
1.1.2.1.2. 관리형 클러스터 세트를 삭제해도 라벨이 자동으로 제거되지는 않습니다.
ManagedClusterSet
을 삭제한 후 클러스터를 클러스터 세트에 연결하는 각 관리 클러스터에 추가된 레이블은 자동으로 제거되지 않습니다. 삭제된 관리 클러스터 세트에 포함된 각 관리 클러스터에서 레이블을 수동으로 제거합니다. 레이블은 cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name>과 유사합니다
.
1.1.2.1.3. ClusterClaim 오류
ClusterPool
에 대해 Hive ClusterClaim
을 생성하고 수동으로 ClusterClaim
라이프사이클 필드를 잘못된 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.4. 프로비저닝된 클러스터와 동기화되지 않는 제품 채널
clusterimageset
는 fast
채널에 있지만 프로비저닝된 클러스터는 stable
채널에 있습니다. 현재 제품은 프로비저닝된 OpenShift Container Platform 클러스터와 채널을
동기화하지 않습니다.
OpenShift Container Platform 콘솔에서 올바른 채널로 변경합니다. Administration > Cluster Settings > Details Channel 을 클릭합니다.
1.1.2.1.5. 사용자 정의 CA 인증서가 있는 관리형 클러스터의 복원 허브 클러스터에 대한 연결을 복원하지 못할 수 있습니다.
사용자 정의 CA 인증서로 클러스터를 관리하는 허브 클러스터의 백업을 복원한 후 관리형 클러스터와 허브 클러스터 간의 연결이 실패할 수 있습니다. 이는 복원된 허브 클러스터에서 CA 인증서가 백업되지 않았기 때문입니다. 연결을 복원하려면 관리 클러스터의 네임스페이스에 있는 사용자 정의 CA 인증서 정보를 복원된 허브 클러스터의 < managed_cluster>-admin-kubeconfig
시크릿에 복사합니다.
팁: 백업 사본을 생성하기 전에 이 CA 인증서를 hub 클러스터에 복사하면 백업 사본에 시크릿 정보가 포함됩니다. 나중에 백업 사본을 사용하여 복원하면 허브와 관리 클러스터 간의 연결이 자동으로 완료됩니다.
1.1.2.1.6. local-cluster가 자동으로 다시 생성되지 않을 수 있습니다.
disableHubSelfManagement
가 false
로 설정된 동안 local-cluster가 삭제되면 MulticlusterHub
Operator가 로컬 클러스터를 다시 생성합니다. 로컬 클러스터를 분리한 후 로컬 클러스터가 자동으로 다시 생성되지 않을 수 있습니다.
이 문제를 해결하려면
MulticlusterHub
Operator에서 조사하는 리소스를 수정합니다. 다음 예제를 참조하십시오.oc delete deployment multiclusterhub-repo -n <namespace>
-
로컬 클러스터를 올바르게 분리하려면
MultiClusterHub
에서disableHubSelfManagement
를 true로 설정합니다.
1.1.2.1.7. 온-프레미스 클러스터를 만들 때 서브넷 선택
콘솔을 사용하여 온-프레미스 클러스터를 만드는 경우 클러스터에 사용 가능한 서브넷을 선택해야 합니다. 필수 필드로 표시되지 않습니다.
1.1.2.1.8. 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.9. 다른 이름으로 다시 가져온 후 로컬 클러스터 상태 오프라인
실수로 다른 이름으로 local-cluster
라는 클러스터를 다시 가져오려고 하면 로컬 클러스터 상태 및 다시 가져온 클러스터
디스플레이 오프라인에서
.
이 경우 복구하려면 다음 단계를 완료합니다.
hub 클러스터에서 다음 명령을 실행하여 허브 클러스터의 자체 관리에 대한 설정을 일시적으로 편집합니다.
oc edit mch -n open-cluster-management multiclusterhub
-
spec.disableSelfManagement=true
설정을 추가합니다. hub 클러스터에서 다음 명령을 실행하여 로컬 클러스터를 삭제하고 재배포합니다.
oc delete managedcluster local-cluster
다음 명령을 입력하여
local-cluster
관리 설정을 제거합니다.oc edit mch -n open-cluster-management multiclusterhub
-
이전에 추가한
spec.disableSelfManagement=true
를 제거합니다.
1.1.2.1.10. 프록시 환경에서 Ansible 자동화로 클러스터 프로비저닝 실패
다음 조건이 모두 충족되면 관리형 클러스터를 자동으로 프로비저닝하도록 구성된 자동화 템플릿이 실패할 수 있습니다.
- hub 클러스터에는 클러스터 전체 프록시가 활성화되어 있습니다.
- Ansible Automation Platform은 프록시를 통해서만 도달할 수 있습니다.
1.1.2.1.11. klusterlet Operator의 버전은 hub 클러스터와 동일해야 합니다.
klusterlet Operator를 설치하여 관리형 클러스터를 가져오는 경우 klusterlet Operator 버전은 hub 클러스터 버전과 동일해야 합니다. 그렇지 않으면 klusterlet Operator가 작동하지 않습니다.
1.1.2.1.12. 관리형 클러스터 네임스페이스를 수동으로 삭제할 수 없음
관리 클러스터의 네임스페이스를 수동으로 삭제할 수 없습니다. 관리 대상 클러스터 네임스페이스는 관리 클러스터가 분리되면 자동으로 삭제됩니다. 관리 클러스터 네임스페이스를 분리하기 전에 관리형 클러스터 네임스페이스를 수동으로 삭제하면 관리 클러스터에 관리 클러스터를 삭제한 후 연속 종료 상태가 표시됩니다. 이 종료 관리 클러스터를 삭제하려면 분리한 관리 클러스터에서 종료자를 수동으로 제거합니다.
1.1.2.1.13. Hub 클러스터 및 관리형 클러스터 시계가 동기화되지 않음
Hub 클러스터 및 클러스터 시간을 동기화가 부족하여 콘솔에 표시되지 않고
결국 몇 분 내에 사용할 수 있습니다
. OpenShift Container Platform 허브 클러스터 시간이 올바르게 구성되었는지 확인합니다. 노드 사용자 지정을 참조하십시오.
1.1.2.1.14. 특정 버전의 IBM OpenShift Container Platform Kubernetes Service 클러스터 가져오기는 지원되지 않습니다.
IBM OpenShift Container Platform Kubernetes Service 버전 3.11 클러스터를 가져올 수 없습니다. 이후 버전의 IBM OpenShift Kubernetes Service가 지원됩니다.
1.1.2.1.15. 프로비저닝된 클러스터에 대한 자동 시크릿 업데이트가 지원되지 않음
클라우드 공급자 측에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 이 클라우드 공급자의 해당 인증 정보를 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리형 클러스터를 삭제하려고 할 때 필요합니다.
1.1.2.1.16. 관리형 클러스터의 노드 정보를 검색에서 볼 수 없음
검색은 hub 클러스터에서 리소스에 대한 RBAC를 매핑합니다. 사용자 RBAC 설정에 따라 관리 클러스터의 노드 데이터가 표시되지 않을 수 있습니다. 검색 결과는 클러스터의 노드 페이지에 표시되는 내용과 다를 수 있습니다.
1.1.2.1.17. 클러스터 삭제 프로세스가 완료되지 않음
관리형 클러스터를 제거해도 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.18. 콘솔과 함께 OpenShift Container Platform Dedicated에서 OpenShift Container Platform 관리 클러스터를 업그레이드할 수 없음
Red Hat Advanced Cluster Management 콘솔을 사용하여 OpenShift Container Platform Dedicated 환경에 있는 OpenShift Container Platform 관리 클러스터를 업그레이드할 수 없습니다.
1.1.2.1.19. 작업 관리자 애드온 검색 세부 정보
특정 관리 클러스터에서 특정 리소스에 대한 검색 세부 정보 페이지가 실패할 수 있습니다. 관리 클러스터의 work-manager 애드온이 Available
상태인지 확인해야 검색할 수 있습니다.
1.1.2.1.20. Red Hat OpenShift Container Platform 관리형 클러스터에 LoadBalancer가 활성화되어 있어야 합니다.
Red Hat OpenShift Container Platform 및 비OpenShift Container Platform 클러스터 모두 Pod 로그 기능을 지원하지만 이 기능을 사용하려면 OpenShift Container Platform 클러스터가 LoadBalancer
를 활성화해야 합니다. 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.21. OpenShift Container Platform 4.10.z는 프록시 설정이 있는 호스트 컨트롤 플레인 클러스터를 지원하지 않습니다.
OpenShift Container Platform 4.10.z에서 클러스터 전체 프록시 구성으로 호스팅 서비스 클러스터를 생성할 때 nodeip-configuration.service
서비스가 작업자 노드에서 시작되지 않습니다.
1.1.2.1.22. Azure에서 OpenShift Container Platform 4.11 클러스터를 프로비저닝할 수 없음
인증 Operator 시간 초과 오류로 인해 Azure에 OpenShift Container Platform 4.11 클러스터를 프로비저닝하지 못합니다. 이 문제를 해결하려면 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.23. 클라이언트가 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.11/latest/rhcos-live-kernel-x86_64 rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.11/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.24. 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.25. CIM 서비스를 사용하여 연결이 끊긴 환경에 배포된 클러스터가 설치되지 않을 수 있습니다.
중앙 인프라 관리 서비스를 사용하여 연결이 끊긴 환경에 클러스터를 배포할 때 클러스터 노드가 설치되지 않을 수 있습니다.
이 문제는 클러스터가 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
파일을 unrestrictive로 설정하는 클러스터에 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.2. 호스팅 컨트롤 플레인
1.1.2.2.1. 콘솔이 호스팅된 클러스터를 Pending 가져오기로 표시
주석 및 ManagedCluster
이름이 일치하지 않으면 콘솔에 보류 중 가져오기
로 클러스터가 표시됩니다. 멀티 클러스터 엔진 Operator는 클러스터를 사용할 수 없습니다. 주석이 없고 ManagedCluster
이름이 HostedCluster
리소스의 Infra-ID
값과 일치하지 않는 경우 동일한 문제가 발생합니다."
1.1.2.2.2. 호스트된 클러스터에 노드 풀을 추가할 때 콘솔에서 동일한 버전을 여러 번 나열할 수 있습니다.
콘솔을 사용하여 기존 호스트 클러스터에 새 노드 풀을 추가하면 동일한 버전의 OpenShift Container Platform이 옵션 목록에 두 번 이상 표시될 수 있습니다. 원하는 버전의 목록에서 인스턴스를 선택할 수 있습니다.
1.1.3. 에라타 업데이트
멀티 클러스터 엔진 Operator의 경우 릴리스 시 에라타 업데이트가 자동으로 적용됩니다.
중요: 참조를 위해 에라타 링크 및 GitHub 번호가 콘텐츠에 추가되어 내부적으로 사용될 수 있습니다. 액세스 권한이 필요한 링크는 사용자가 사용할 수 없습니다.
FIPS 알림: spec.ingress.sslCiphers
에서 자체 암호를 지정하지 않으면 multiclusterhub-operator
에서 기본 암호 목록을 제공합니다. 2.4의 경우 이 목록에는 FIPS에서 승인하지 않은 두 개의 암호가 포함되어 있습니다. 버전 2.4.x 또는 이전 버전에서 업그레이드하고 FIPS 준수를 원하는 경우 다중 클러스터 허브
리소스에서 다음 두 암호를 제거하십시오. ECDHE-ECDSA-CHACHA20-POLY1305
및 ECDHE-RSA-CHACHA20-POLY1305
.
1.1.3.1. 에라타 2.2.1
- 하나 이상의 제품 컨테이너 이미지 및 보안 수정 사항에 대한 업데이트를 제공합니다.
1.1.4. 중단 및 제거
제품의 일부가 더 이상 사용되지 않거나 멀티 클러스터 엔진 Operator에서 제거된 경우를 알아봅니다. 현재 릴리스 및 두 개의 이전 릴리스에 대한 표에 표시되는 권장 동작 및 세부 사항의 대체 작업을 고려하십시오.
1.1.4.1. API 사용 중단 및 제거
다중 클러스터 엔진 Operator는 API에 대한 Kubernetes 사용 중단 지침을 따릅니다. 해당 정책에 대한 자세한 내용은 Kubernetes 사용 중단 정책을 참조하십시오. 다중 클러스터 엔진 Operator API는 다음 타임라인 외부에서만 더 이상 사용되지 않거나 제거됩니다.
-
모든
V1
API는 일반적으로 12 개월 또는 3 개의 릴리스에서 사용할 수 있으며 지원됩니다. V1 API는 제거되지 않지만 해당 시간 제한 외부에서 더 이상 사용되지 않을 수 있습니다. -
모든
베타
API는 일반적으로 9 개월 또는 3 개의 릴리스에서 사용할 수 있습니다. 베타 API는 해당 시간 제한 외부에서 제거되지 않습니다. -
모든
alpha
API는 지원되지 않아도 되지만 사용자에게 도움이 되는 경우 더 이상 사용되지 않거나 제거될 수 있습니다.
1.1.4.1.1. API 사용 중단
제품 또는 카테고리 | 영향을 받는 항목 | 버전 | 권장 작업 | 자세한 내용 및 링크 |
1.1.4.1.2. API 제거
제품 또는 카테고리 | 영향을 받는 항목 | 버전 | 권장 작업 | 자세한 내용 및 링크 |
1.1.4.2. 다중 클러스터 엔진 Operator 사용 중단
더 이상 사용되지 않는 구성 요소, 기능 또는 서비스가 지원되지만 더 이상 사용하지 않으며 향후 릴리스에서 더 이상 사용되지 않을 수 있습니다. 권장 동작 의 대체 작업과 다음 표에 제공된 세부 사항을 고려하십시오.
제품 또는 카테고리 | 영향을 받는 항목 | 버전 | 권장 작업 | 자세한 내용 및 링크 |
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를 설치할 필요가 없습니다.
지원 정보는 Kubernetes Operator 2.2 지원 매트릭스를 위한 멀티 클러스터 엔진과 다음 설명서를 참조하십시오.
계속하려면 다중 클러스터 엔진 Operator 개요가 있는 클러스터 라이프사이클의 나머지 클러스터 라이프 사이클 설명서를 참조하십시오.
1.2.1. 요구 사항 및 권장 사항
다중 클러스터 엔진 Operator를 설치하기 전에 다음 시스템 구성 요구 사항 및 설정을 검토하십시오.
중요: 2.5 이전의 Kubernetes용 Red Hat Advanced Cluster Management가 없는 클러스터에 다중 클러스터 엔진 Operator를 설치해야 합니다. Red Hat Advanced Cluster Management 버전 2.5 이상을 사용하는 경우 Kubernetes용 다중 클러스터 엔진이 클러스터에 이미 설치되어 있습니다.
1.2.1.1. 지원되는 브라우저 및 플랫폼
The multicluster engine for Kubernetes operator 2.2 지원 매트릭스 에서 지원되는 브라우저 및 기능에 대한 중요한 정보를 참조하십시오.
1.2.1.2. 네트워크 구성
중요: 신뢰할 수 있는 CA 번들은 다중 클러스터 엔진 Operator 네임스페이스에서 사용할 수 있지만 개선 사항을 적용하려면 네트워크를 변경해야 합니다. 신뢰할 수 있는 CA 번들 ConfigMap은 trusted-ca-bundle
의 기본 이름을 사용합니다. TRUSTED_CA_BUNDLE
이라는 환경 변수에서 이 이름을 operator에 제공하여 이름을 변경할 수 있습니다. 자세한 내용은 Red Hat OpenShift Container Platform의 네트워킹 섹션에서 클러스터 전체 프록시 구성을 참조하십시오.
참고: 관리형 클러스터의 등록
프록시를 통과할 수 없는 mTLS 연결을 설정하여 허브 클러스터에서 에이전트
및 작업 에이전트는apiserver
와 통신하기 때문에 프록시 설정을 지원하지 않습니다.
다음 섹션에서 연결을 허용하도록 네트워크 설정을 구성합니다.
1.2.1.2.1. 멀티 클러스터 엔진 Operator 네트워킹 요구 사항
다중 클러스터 엔진 Operator 클러스터 네트워킹 요구 사항은 다음 표를 참조하십시오.
direction | 연결 | 포트(지정된 경우) |
---|---|---|
outbound | 프로비저닝된 관리 클러스터의 Kubernetes API 서버 | 6443 |
아웃바운드 및 인바운드 |
관리 클러스터의 | 443 |
인바운드 | 관리 클러스터에서 Kubernetes 클러스터에 대한 멀티 클러스터 엔진의 Kubernetes API 서버 | 6443 |
1.2.2. 콘솔 개요
OpenShift Container Platform 콘솔 플러그인은 OpenShift Container Platform 4.10 웹 콘솔에서 사용할 수 있으며 통합할 수 있습니다. 이 기능을 사용하려면 콘솔 플러그인이 활성화된 상태를 유지해야 합니다. 멀티 클러스터 엔진 Operator는 인프라 및 인증 정보 탐색 항목에서 특정 콘솔 기능을 표시합니다. Red Hat Advanced Cluster Management를 설치하는 경우 더 많은 콘솔 기능이 표시됩니다.
참고: 플러그인이 활성화된 OpenShift Container Platform 4.10의 경우 드롭다운 메뉴에서 모든 클러스터를 선택하여 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.3. 다중 클러스터 엔진 Operator 역할 기반 액세스 제어
RBAC는 콘솔 수준 및 API 수준에서 검증됩니다. 사용자 액세스 역할 권한에 따라 콘솔의 작업을 활성화하거나 비활성화할 수 있습니다. 제품의 특정 라이프사이클에 대한 RBAC에 대한 자세한 내용은 다음 섹션을 참조하십시오.
1.2.3.1. 역할 개요
일부 제품 리소스는 클러스터 전체이며 일부는 네임스페이스 범위입니다. 일관된 액세스 제어를 위해 사용자에게 클러스터 역할 바인딩 및 네임스페이스 역할 바인딩을 적용해야 합니다. 지원되는 다음 역할 정의의 표 목록을 확인합니다.
1.2.3.1.1. 역할 정의 테이블
Role | 정의 |
---|---|
|
이는 OpenShift Container Platform 기본 역할입니다. |
|
|
|
|
|
|
|
|
|
|
|
admin, edit, view는 OpenShift Container Platform 기본 역할입니다. 이러한 역할에 대한 네임스페이스 범위 바인딩이 있는 사용자는 특정 네임스페이스의 |
중요:
- 모든 사용자는 OpenShift Container Platform에서 프로젝트를 생성할 수 있으므로 네임스페이스에 대한 관리자 역할 권한을 제공합니다.
-
사용자에게 클러스터에 대한 역할 액세스 권한이 없는 경우 클러스터 이름이 표시되지 않습니다. 클러스터 이름은 다음 기호
-
를 사용하여 표시됩니다.
RBAC는 콘솔 수준 및 API 수준에서 검증됩니다. 사용자 액세스 역할 권한에 따라 콘솔의 작업을 활성화하거나 비활성화할 수 있습니다. 제품의 특정 라이프사이클에 대한 RBAC에 대한 자세한 내용은 다음 섹션을 참조하십시오.
1.2.3.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
가 네임스페이스 범위 리소스가 아닌 클러스터 범위 리소스이므로 필요합니다.다음 명령을 입력하여 클러스터 역할
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.3.2.1. 클러스터 풀 RBAC
다음 클러스터 풀 RBAC 작업을 확인합니다.
클러스터 관리자는 관리형 클러스터를 생성하여 클러스터 풀 프로비저닝 클러스터를 사용하고 그룹에 역할을 추가하여 관리자 권한을 부여합니다. 다음 예제를 참조하십시오.
다음 명령을 사용하여
server-foundation-clusterset
관리 클러스터에admin
권한을 부여합니다.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-clusterpool
에 admin 권한을 부여합니다.oc 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
네임스페이스에보기
권한을 부여합니다.
-
클러스터 풀이 생성되면 클러스터 풀이
clusterdeployment
을 생성합니다. 자세한 내용은 계속 읽기:-
server-foundation-controller
는server-foundation-team-
의admin
clusterdeployment
네임스페이스에 admin 권한을 부여합니다. server-foundation-controller
는server-foundation-team-user
에 대해view
권한clusterdeployment
네임스페이스를 부여합니다.참고:
team-admin
및team-user
로clusterpool
,clusterdeployment
및clusterclaim
에 대한관리자
권한이 있습니다.
-
1.2.3.2.2. 클러스터 라이프사이클을 위한 콘솔 및 API RBAC 테이블
클러스터 라이프사이클에 대한 다음 콘솔 및 API RBAC 테이블을 확인합니다.
리소스 | admin | edit | view |
---|---|---|---|
클러스터 | 읽기, 업데이트, 삭제 | - | read |
클러스터 세트 | get, update, bind, join | 언급되지 않은 edit 역할 | get |
관리형 클러스터 | 읽기, 업데이트, 삭제 | 언급된 편집 역할 없음 | get |
공급자 연결 | 생성, 읽기, 업데이트 및 삭제 | - | read |
API | admin | edit | view |
---|---|---|---|
이 API의 명령에 | 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
이 API의 명령에 | read | read | read |
| 업데이트 | 업데이트 | |
이 API의 명령에 | 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| read | read | read |
이 API에 대한 명령에 | 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
| 만들기, 읽기, 업데이트, 삭제 | 읽기, 업데이트 | read |
1.2.3.2.3. 인증 정보 역할 기반 액세스 제어
자격 증명에 대한 액세스는 Kubernetes에서 제어합니다. 인증 정보는 Kubernetes 시크릿으로 저장되고 보호됩니다. 다음 권한은 Red Hat Advanced Cluster Management for Kubernetes에서 시크릿에 액세스하는 데 적용됩니다.
- 네임스페이스에서 보안을 생성할 수 있는 액세스 권한이 있는 사용자는 인증 정보를 생성할 수 있습니다.
- 네임스페이스의 읽기 보안에 액세스할 수 있는 사용자는 인증 정보를 볼 수도 있습니다.
-
admin
및edit
의 Kubernetes 클러스터 역할이 있는 사용자는 시크릿을 생성하고 편집할 수 있습니다. -
Kubernetes 클러스터 역할이 있는 사용자는 시크릿 내용을 읽고 서비스 계정 자격 증명에 액세스할 수 있으므로 시크릿을 볼 수 없습니다.
1.3. 멀티 클러스터 엔진 Operator 설치
멀티 클러스터 엔진 운영자는 클러스터의 관리를 개선하는 소프트웨어 운영자입니다. 멀티 클러스터 엔진 Operator는 클라우드 및 데이터 센터 전반에서 Red Hat OpenShift Container Platform 및 Kubernetes 클러스터 라이프사이클 관리를 지원합니다.
다음 설명서를 참조하십시오.
1.3.1. 온라인 연결 중 설치
다중 클러스터 엔진 Operator는 다중 클러스터 엔진 Operator를 포함하는 구성 요소의 설치, 업그레이드 및 제거를 관리하는 Operator Lifecycle Manager를 사용하여 설치됩니다.
필수 액세스 권한: 클러스터 관리자
중요:
- 2.5 이전의 Kubernetes용 Red Hat Advanced Cluster Management가 없는 클러스터에 다중 클러스터 엔진 Operator를 설치해야 합니다. 멀티 클러스터 엔진 Operator는 2.5 이전 버전에서 Red Hat Advanced Cluster Management for Kubernetes와 공존할 수 없습니다. 동일한 관리 구성 요소를 제공하기 때문입니다. 이전에 Red Hat Advanced Cluster Management를 설치하지 않은 클러스터에 다중 클러스터 엔진 Operator를 설치하는 것이 좋습니다. 버전 2.5 이상에서 Kubernetes용 Red Hat Advanced Cluster Management를 사용하는 경우 멀티 클러스터 엔진 Operator가 클러스터에 이미 설치되어 있습니다.
-
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를 해당 인프라 노드에 설치할 수 있습니다. 모든 다중 클러스터 엔진 Operator 구성 요소가 인프라 노드를 지원하는 것은 아니므로 인프라 노드에 다중 클러스터 엔진 Operator를 설치할 때 일부 작업자 노드가 필요합니다. 자세한 내용은 인프라 노드에 다중 클러스터 엔진 설치 섹션을 참조하십시오.
OpenShift Container Platform 또는 Kubernetes용 다중 클러스터 엔진에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 이미지 가져오기 보안을 구성해야 합니다. 이미지 풀 시크릿 및 기타 고급 구성을 구성하는 방법에 대한 자세한 내용은 이 문서의 고급 구성 섹션의 옵션을 참조하십시오.
1.3.1.1. 사전 요구 사항
Kubernetes용 멀티 클러스터 엔진을 설치하기 전에 다음 요구사항을 참조하십시오.
- Red Hat OpenShift Container Platform 클러스터는 OpenShift Container Platform 콘솔에서 OperatorHub 카탈로그의 다중 클러스터 엔진 Operator에 액세스할 수 있어야 합니다.
- catalog.redhat.com 에 액세스해야 합니다.
OpenShift Container Platform 버전 4.8 이상은 사용자 환경에 배포해야 하며 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 설치 페이지에서 설치 옵션을 선택합니다.
네임스페이스:
- 다중 클러스터 엔진 Operator 엔진을 자체 네임스페이스 또는 프로젝트에 설치해야 합니다.
-
기본적으로 OperatorHub 콘솔 설치 프로세스는
다중 클러스터 엔진
이라는 네임스페이스를 생성합니다. 모범 사례: 사용 가능한 경우multicluster-engine
네임스페이스를 계속 사용합니다. -
이미
multicluster-engine
이라는 네임스페이스가 있는 경우 다른 네임스페이스를 선택합니다.
- Channel: 선택한 채널은 설치 중인 릴리스에 해당합니다. 채널을 선택하면 확인된 릴리스를 설치하고 해당 릴리스 내에서 향후 에라타 업데이트를 가져옵니다.
승인 전략: 승인 전략은 구독한 채널에 업데이트를 적용하는 데 필요한 사람 상호 작용을 식별합니다.
- 기본적으로 선택되어 있는 자동 을 선택하여 해당 릴리스 내의 모든 업데이트가 자동으로 적용되도록 합니다.
- 업데이트를 사용할 수 있을 때 알림을 받으려면 수동 을 선택합니다. 언제 업데이트가 적용되었는지에 대한 우려가 있는 경우 이 방법이 모범 사례일 수 있습니다.
참고: 다음 마이너 릴리스로 업그레이드하려면 OperatorHub 페이지로 돌아가 최신 릴리스의 새 채널을 선택해야 합니다.
- 설치를 선택하여 변경 사항을 적용하고 Operator를 생성합니다.
MultiClusterEngine 사용자 정의 리소스를 생성하려면 다음 프로세스를 참조하십시오.
- OpenShift Container Platform 콘솔 탐색에서 설치된 Operator > Kubernetes용 다중 클러스터 엔진을 선택합니다.
- MultiCluster Engine 탭을 선택합니다.
- MultiClusterEngine 생성을 선택합니다.
YAML 파일에서 기본값을 업데이트합니다. 문서의 MultiClusterEngine 고급 구성 섹션의 옵션을 참조하십시오.
- 다음 예제에서는 편집기에 복사할 수 있는 기본 템플릿을 보여줍니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: {}
생성을 선택하여 사용자 정의 리소스를 초기화합니다. 멀티 클러스터 엔진 Operator 엔진을 빌드하고 시작하는 데 최대 10분이 걸릴 수 있습니다.
MultiClusterEngine 리소스가 생성되면 MultiCluster Engine 탭에서 리소스의 상태를 사용할 수 있습니다.
1.3.1.4. OpenShift Container Platform CLI에서 설치
Operator 요구 사항이 포함된 다중 클러스터 엔진 Operator 엔진 네임스페이스를 생성합니다. 다음 명령을 실행합니다. 여기서
namespace
는 Kubernetes 엔진 네임스페이스의 다중 클러스터 엔진의 이름입니다.네임스페이스
값은 OpenShift Container Platform 환경에서 Project 라고 할 수 있습니다.oc create namespace <namespace>
프로젝트 네임스페이스를 생성한 네임스페이스로 전환합니다.
namespace
를 1단계에서 생성한 Kubernetes 엔진의 다중 클러스터 엔진 이름으로 바꿉니다.oc project <namespace>
YAML 파일을 생성하여
OperatorGroup
리소스를 구성합니다. 각 네임스페이스에는 Operator 그룹이 하나만 있을 수 있습니다.default
를 Operator 그룹의 이름으로 바꿉니다.namespace
를 프로젝트 네임스페이스의 이름으로 바꿉니다. 다음 예제를 참조하십시오.apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: <default> 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.1 installPlanApproval: Automatic name: multicluster-engine
참고: 인프라 노드에 Kubernetes 엔진의 다중 클러스터 엔진을 설치하려면 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
사용자 정의 리소스 상태가status.phase
필드에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 설명서의 인프라 머신 세트 생성에 설명된 절차를 따르십시오. 인프라 노드는 관리 이외의 워크로드가 실행되지 않도록 쿠버네티스 테인트
및 라벨
을 사용하여 구성됩니다.
다중 클러스터 엔진 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를 설치해야 할 수 있습니다. 연결이 끊긴 엔진에 설치하려면 연결된 설치와 동일한 몇 가지 단계가 필요합니다.
중요: 2.5 이전의 Kubernetes용 Red Hat Advanced Cluster Management가 없는 클러스터에 다중 클러스터 엔진 Operator를 설치해야 합니다. 멀티 클러스터 엔진 Operator는 2.5 이전 버전에서 Red Hat Advanced Cluster Management for Kubernetes와 공존할 수 없습니다. 동일한 관리 구성 요소를 제공하기 때문입니다. 이전에 Red Hat Advanced Cluster Management를 설치하지 않은 클러스터에 다중 클러스터 엔진 Operator를 설치하는 것이 좋습니다. 버전 2.5.0 이상에서 Kubernetes용 Red Hat Advanced Cluster Management를 사용하는 경우 멀티 클러스터 엔진 Operator가 클러스터에 이미 설치되어 있습니다.
설치하는 동안 네트워크에서 직접 액세스하는 대신 설치 중에 액세스하려면 패키지 사본을 다운로드해야 합니다.
1.3.2.1. 사전 요구 사항
The multicluster engine Operator를 설치하기 전에 다음 요구 사항을 충족해야 합니다.
- Red Hat OpenShift Container Platform 버전 4.8 이상은 사용자 환경에 배포해야 하며 CLI(명령줄 인터페이스)로 로그인해야 합니다.
catalog.redhat.com 에 액세스해야 합니다.
참고: 베어 메탈 클러스터를 관리하려면 OpenShift Container Platform 버전 4.8 이상이 있어야 합니다.
OpenShift Container Platform 버전 4.10,OpenShift Container Platform 버전 4.8 을 참조하십시오.
-
Red Hat OpenShift Container Platform CLI는 버전 4.8 이상이어야 하며
oc
명령을 실행하도록 구성해야 합니다. Red Hat OpenShift CLI 설치 및 구성에 대한 정보는 CLI 시작하기 를 참조하십시오. - Red Hat OpenShift Container Platform 권한을 통해 네임스페이스를 생성할 수 있어야 합니다.
- Operator의 종속성을 다운로드하려면 인터넷 연결이 있는 워크스테이션이 있어야 합니다.
1.3.2.2. OpenShift Container Platform 설치 확인
- 클러스터에서 설치 및 작동하는 레지스트리 및 스토리지 서비스를 포함하여 지원되는 OpenShift Container Platform 버전이 있어야 합니다. OpenShift Container Platform 버전 4.8에 대한 자세한 내용은 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. 연결이 끊긴 환경에 설치
중요: 연결이 끊긴 환경에서 운영자를 설치하려면 필요한 이미지를 미러링 레지스트리에 다운로드해야 합니다. 다운로드하지 않으면 배포 중에 ImagePullBackOff
오류가 발생할 수 있습니다.
다음 단계에 따라 연결이 끊긴 환경에 다중 클러스터 엔진 Operator를 설치합니다.
미러 레지스트리를 생성합니다. 미러 레지스트리가 아직 없는 경우 Red Hat OpenShift Container Platform 설명서의 연결되지 않은 설치 미러링 주제에서 절차를 완료하여 생성합니다.
미러 레지스트리가 이미 있는 경우 기존 레지스트리를 구성하고 사용할 수 있습니다.
참고: 베어 메탈의 경우
install-config.yaml
파일에서 연결이 끊긴 레지스트리의 인증서 정보를 제공해야 합니다. 연결이 끊긴 레지스트리에서 이미지에 액세스하려면 다중 클러스터 엔진 운영자가 레지스트리에 액세스할 수 있도록 인증서 정보를 제공해야 합니다.- 레지스트리에서 인증서 정보를 복사합니다.
-
편집기에서
install-config.yaml
파일을 엽니다. -
additionalTrustBundle: |
에 대한 항목을 찾습니다. additionalTrustBundle
행 뒤에 인증서 정보를 추가합니다. 결과 내용은 다음 예와 유사해야 합니다.additionalTrustBundle: | -----BEGIN CERTIFICATE----- certificate_content -----END CERTIFICATE----- sshKey: >-
중요: 다음 관리 정책이 필요한 경우 연결 해제된 이미지 레지스트리의 미러가 필요합니다.
-
Container Security Operator 정책: 이미지는 소스
registry.redhat.io/quay
에 있습니다. -
Compliance Operator 정책: 이미지는 소스
registry.redhat.io/compliance
에 있습니다. 더 이상 사용되지 않는 Gatekeeper operator 정책: 이미지는 소스
registry.redhat.io/rhacm2
에 있습니다.Gatekeeper Operator는 Gatekeeper 커뮤니티 노력 및 릴리스에 맞게 더 이상 사용되지 않습니다. 대신 서브스크립션으로 설치합니다.
세 가지 Operator 모두의 미러 목록의 다음 예제를 참조하십시오.
- 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 및 커뮤니티 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를 사용하여 설치됩니다. MultiClusterEngine
사용자 정의 리소스에 다음 속성 중 하나 이상을 추가하여 설치 중 또는 설치 후에 다중 클러스터 엔진 Operator를 추가로 구성할 수 있습니다.
1.3.3.1. 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 클러스터를로컬 클러스터로
식별합니다. -
enabled
설정은 기능이 활성화되었는지 여부를 지정합니다. 값이true
이면 hub 클러스터가 자체적으로 관리됩니다. 값이false
이면 hub 클러스터가 자체적으로 관리되지 않습니다.
자체적으로 관리하는 허브 클러스터는 클러스터 목록에서 로컬
클러스터로 지정됩니다.
1.3.3.2. 사용자 정의 이미지 가져오기 보안
OpenShift Container Platform 또는 다중 클러스터 엔진 Operator에서 생성하지 않은 Kubernetes 클러스터를 가져오려면 OpenShift Container Platform 풀 시크릿 정보가 포함된 시크릿을 생성하여 배포 레지스트리에서 권한이 있는 콘텐츠에 액세스합니다.
OpenShift Container Platform 클러스터의 보안 요구 사항은 OpenShift Container Platform 및 Kubernetes용 다중 클러스터 엔진에 의해 자동으로 해결되므로 관리할 다른 유형의 Kubernetes 클러스터를 가져오지 않는 경우 시크릿을 생성할 필요가 없습니다.
중요: 이러한 보안은 네임스페이스별이므로 엔진에 사용하는 네임스페이스에 있는지 확인합니다.
- 가져오기 시크릿 다운로드를 선택하여 cloud.redhat.com/openshift/install/pull-secret 에서 OpenShift Container Platform 풀 시크릿 파일을 다운로드합니다. OpenShift Container Platform 풀 시크릿은 Red Hat 고객 포털 ID와 연결되어 있으며 모든 Kubernetes 공급자에서 동일합니다.
다음 명령을 실행하여 보안을 생성합니다.
oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
-
보안을
생성하려는 보안의 이름으로 교체합니다. -
보안이
네임스페이스
와 일치하므로 네임스페이스를 프로젝트 네임스페이스로 바꿉니다. -
다운로드한 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.3. 대상 네임스페이스
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.4. availabilityConfig
hub 클러스터에는 High
및 Basic
이라는 두 가지 기능이 있습니다. 기본적으로 hub 클러스터는 고가용성으로, 허브 클러스터 구성 요소에 2
의 replicaCount
를 제공합니다. 이를 통해 페일오버의 경우 지원이 향상되지만
기본
가용성보다 많은 리소스를 소비하여 구성 요소에 1
의 replicaCount
를 제공합니다.
다음 예제에서는 기본
가용성이 있는 spec.availabilityConfig
템플릿을 보여줍니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: availabilityConfig: "Basic"
1.3.3.5. nodeSelector
클러스터의 특정 노드에 설치할 MultiClusterEngine
에서 노드 선택기 세트를 정의할 수 있습니다. 다음 예제에서는 라벨이 node-role.kubernetes.io/infra
인 노드에 Pod를 할당하는 spec.nodeSelector
를 보여줍니다.
spec: nodeSelector: node-role.kubernetes.io/infra: ""
1.3.3.6. 허용 오차
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.7. ManagedServiceAccount 애드온 (기술 프리뷰)
기본적으로 Managed-ServiceAccount
애드온은 비활성화되어 있습니다. 이 구성 요소를 활성화하면 관리형 클러스터에서 서비스 계정을 생성하거나 삭제할 수 있습니다. 이 애드온을 사용하여 설치하려면 spec.overrides
의 MultiClusterEngine
사양에 다음을 포함합니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: managedserviceaccount-preview enabled: true
명령줄에서 리소스를 편집하고 managedserviceaccount-preview
구성 요소를 enabled: true
로 설정하여 Managed-ServiceAccount
애드온을 활성화할 수 있습니다. 또는 다음 명령을 실행하고 <multiclusterengine-name>을
MultiClusterEngine
리소스의 이름으로 교체할 수 있습니다.
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount-preview","enabled":true}}]'
1.3.3.8. Hypershift 애드온 (기술 프리뷰)
기본적으로 Hypershift
애드온은 비활성화되어 있습니다. 이 애드온을 사용하여 설치하려면 spec.overrides
의 MultiClusterEngine
값에 다음을 포함합니다.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: hypershift-preview enabled: true
명령줄에서 리소스를 편집하여 MultiClusterEngine
을 생성한 후 Hypershift
-preview 구성 요소를
추가 기능을 활성화할 수 있습니다. 또는 다음 명령을 실행하고 <multiclusterengine-name>을 enabled: true
로 설정하여 HypershiftMultiClusterEngine
리소스의 이름으로 교체할 수 있습니다.
oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"hypershift-preview","enabled":true}}]'
1.3.4. 설치 제거
Kubernetes용 다중 클러스터 엔진을 제거하면 프로세스의 두 가지 수준인 사용자 정의 리소스 제거 및 전체 Operator 제거가 표시됩니다. 제거 프로세스를 완료하는 데 최대 5분이 걸릴 수 있습니다.
-
사용자 정의 리소스 제거는
MultiClusterEngine
인스턴스의 사용자 정의 리소스를 제거하는 가장 기본적인 제거 유형이지만 다른 필수 Operator 리소스를 남겨 둡니다. 이 설치 제거 수준은 동일한 설정 및 구성 요소를 사용하여 다시 설치하려는 경우 유용합니다. - 두 번째 수준은 사용자 정의 리소스 정의와 같은 구성 요소를 제외하고 대부분의 Operator 구성 요소를 제거하는 더 완전한 설치 제거입니다. 이 단계를 계속 수행하면 사용자 정의 리소스 제거로 제거되지 않은 모든 구성 요소와 서브스크립션이 제거됩니다. 이 제거 후 사용자 정의 리소스를 다시 설치하기 전에 Operator를 다시 설치해야 합니다.
1.3.4.1. 사전 요구 사항: Detach enabled services
Kubernetes 엔진의 다중 클러스터 엔진을 설치 제거하려면 먼저 해당 엔진에서 관리하는 모든 클러스터를 분리해야 합니다. 오류를 방지하려면 엔진에서 여전히 관리하는 모든 클러스터를 분리한 다음 제거를 다시 시도합니다.
관리 클러스터가 연결된 경우 다음 메시지가 표시될 수 있습니다.
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 사용자 정의 리소스의 옵션 메뉴를 선택합니다.
- Delete MultiClusterEngine 을 선택합니다.
다음 섹션의 절차에 따라 정리 스크립트를 실행합니다.
팁: Kubernetes 버전에 대해 동일한 다중 클러스터 엔진을 다시 설치하려는 경우 이 절차의 나머지 단계를 건너뛰고 사용자 정의 리소스를 다시 설치할 수 있습니다.
- 설치된 Operator로 이동합니다.
- 옵션 메뉴를 선택하고 Uninstall operator 를 선택하여 Kubernetes_ operator용 _ 다중 클러스터 엔진을 제거합니다.
1.3.4.4. 문제 해결 Uninstall
다중 클러스터 엔진 사용자 정의 리소스가 제거되지 않은 경우 정리 스크립트를 실행하여 남아 있는 잠재적인 아티팩트를 제거하십시오.
다음 스크립트를 파일에 복사합니다.
#!/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
1.4. 인증 정보 관리
다중 클러스터 엔진 Operator가 있는 클라우드 서비스 공급자에서 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다. 자격 증명은 클라우드 공급자의 액세스 정보를 저장합니다. 각 공급자 계정에는 단일 공급자의 각 도메인을 수행하는 자체 인증 정보가 필요합니다.
클러스터 인증 정보를 생성하고 관리할 수 있습니다. 인증 정보는 Kubernetes 시크릿으로 저장됩니다. 관리 클러스터의 컨트롤러가 보안에 액세스할 수 있도록 보안이 관리 클러스터의 네임스페이스에 복사됩니다. 인증 정보가 업데이트되면 관리 클러스터 네임스페이스에서 보안 복사본이 자동으로 업데이트됩니다.
참고: 클라우드 공급자 인증 정보의 풀 시크릿, SSH 키 또는 기본 도메인의 변경 사항은 원래 인증 정보를 사용하여 이미 프로비저닝된 기존 관리형 클러스터에 반영되지 않습니다.
필수 액세스: 편집
- Amazon Web Services에 대한 인증 정보 생성
- Microsoft Azure에 대한 인증 정보 생성
- Google Cloud Platform에 대한 인증 정보 생성
- VMware vSphere에 대한 인증 정보 생성
- Red Hat OpenStack Platform 인증 정보 생성
- Red Hat Virtualization 인증 정보 생성
- Red Hat OpenShift Cluster Manager에 대한 인증 정보 생성
- Ansible Automation Platform에 대한 인증 정보 생성
- 온-프레미스 환경에 대한 자격 증명 만들기Create a credential for an on-premises environment
1.4.1. Amazon Web Services에 대한 인증 정보 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 AWS(Amazon Web Services)에서 Red Hat OpenShift Container Platform 클러스터를 배포 및 관리하려면 인증 정보가 필요합니다.
필수 액세스: 편집
참고: 이 절차는 다중 클러스터 엔진 Operator로 클러스터를 생성하기 전에 수행해야 합니다.
1.4.1.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 배포된 다중 클러스터 엔진 Operator 허브 클러스터
- 다중 클러스터 엔진 Operator Hub 클러스터의 인터넷 액세스로 AWS(Amazon Web Services)에서 Kubernetes 클러스터를 생성할 수 있습니다.
- 액세스 키 ID 및 시크릿 액세스 키를 포함하는 AWS 로그인 인증 정보입니다. 보안 인증 정보 이해 및 가져오기를 참조하십시오.
- AWS에 클러스터를 설치할 수 있는 계정 권한 구성 방법에 대한 지침은 AWS 계정 구성을 참조하십시오.
1.4.1.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 특히 자격 증명을 호스팅할 네임스페이스를 만듭니다.
인증 정보에 대한 기본 DNS 도메인을 선택적으로 추가할 수 있습니다. 인증 정보에 기본 DNS 도메인을 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 자동으로 올바른 필드에 채워집니다. 다음 단계를 참조하십시오.
- AWS 계정의 AWS 액세스 키 ID 를 추가합니다. AWS 에 로그인하여 ID를 찾습니다.
- 새로운 AWS Secret Access Key 에 대한 콘텐츠를 제공하십시오.
프록시를 활성화하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 도메인이 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 및 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
-
HTTP 프록시 URL:
- Red Hat OpenShift 풀 시크릿 을 입력합니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
- SSH 개인 키 및 SSH 공개 키 를 추가하여 클러스터에 연결할 수 있습니다. 기존 키 쌍을 사용하거나 키 생성 프로그램으로 새 키 쌍을 만들 수 있습니다.
키를 생성하는 방법에 대한 자세한 내용은 SSH 개인 키 생성 및 에이전트에 추가 를 참조하십시오.
Amazon Web Services에서 클러스터 생성 또는 Amazon Web Services GovCloud에서 클러스터 생성 단계를 완료하면 이 인증 정보를 사용하는 클러스터를 생성할 수 있습니다.
콘솔에서 인증 정보를 편집할 수 있습니다. 이 공급자 연결을 사용하여 클러스터가 생성된 경우 < cluster-
> 시크릿이 새 인증 정보로 업데이트됩니다.
namespace>의 <cluster-name>-aws-
creds
참고: 클러스터 풀이 요청한 클러스터 풀에서 인증 정보 업데이트가 작동하지 않습니다.
더 이상 인증 정보를 사용하는 클러스터를 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 자격 증명 옆에 있는 옵션 메뉴를 선택합니다.
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)
참고: 선택한 관리형 클러스터 네임스페이스에 불투명 보안이 생성됩니다. Hive는 불투명 보안을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 사전 생성된 인증 정보가 불투명 보안으로 관리 클러스터 네임 스페이스에 복사됩니다.
1.4.2. Microsoft Azure에 대한 인증 정보 생성
Microsoft Azure 또는 Microsoft Azure Government에서 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 다중 클러스터 엔진 Operator 콘솔을 사용하는 인증 정보가 필요합니다.
필수 액세스: 편집
참고: 이 절차는 다중 클러스터 엔진 Operator를 사용하여 클러스터를 생성하기 위한 전제 조건입니다.
1.4.2.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 배포된 다중 클러스터 엔진 Operator 허브 클러스터입니다.
- Azure에서 Kubernetes 클러스터를 생성할 수 있도록 멀티 클러스터 엔진 운영자 허브 클러스터의 인터넷 액세스.
- Azure 로그인 인증 정보에는 기본 도메인 리소스 그룹 및 Azure Service Principal JSON이 포함됩니다. azure.microsoft.com 을 참조하십시오.
- Azure에 클러스터를 설치할 수 있는 계정 권한 자세한 내용은 클라우드 서비스 구성 및 Azure 계정 구성을 참조하십시오.
1.4.2.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다. 탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 특히 자격 증명을 호스팅할 네임스페이스를 만듭니다.
- 선택 사항: 인증 정보에 기본 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 을 서비스 주체의 이름으로 교체합니다.
클라이언트 시크릿 을 추가합니다. 이 값은 다음 명령을 사용하여 서비스 주체를 생성할 때
암호
속성으로 생성됩니다.az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>
service_principal 을 서비스 주체의 이름으로 교체합니다. 자세한 내용은 Azure CLI를 사용하여 Azure 서비스 주체 만들기 를 참조하십시오.
서브스크립션 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 풀 시크릿 을 입력합니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
- 클러스터에 연결하는 데 사용할 SSH 개인 키 및 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}")
참고: 선택한 관리형 클러스터 네임스페이스에 불투명 보안이 생성됩니다. Hive는 불투명 보안을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 사전 생성된 인증 정보가 불투명 보안으로 관리 클러스터 네임 스페이스에 복사됩니다.
1.4.3. Google Cloud Platform에 대한 인증 정보 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 GCP(Google Cloud Platform)에서 Red Hat OpenShift Container Platform 클러스터를 생성하고 관리하려면 인증 정보가 필요합니다.
필수 액세스: 편집
참고: 이 절차는 다중 클러스터 엔진 Operator를 사용하여 클러스터를 생성하기 위한 전제 조건입니다.
1.4.3.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 배포된 다중 클러스터 엔진 Operator 허브 클러스터
- 다중 클러스터 엔진 Operator Hub 클러스터의 인터넷 액세스로 GCP에서 Kubernetes 클러스터를 생성할 수 있습니다.
- 사용자 Google Cloud Platform 프로젝트 ID 및 Google Cloud Platform 서비스 계정 JSON 키가 포함된 GCP 로그인 인증 정보 프로젝트 생성 및 관리를 참조하십시오.
- GCP에 클러스터를 설치할 수 있는 계정 권한 계정 구성 방법에 대한 지침은 GCP 프로젝트 구성을 참조하십시오.
1.4.3.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 특히 사용자 자격 증명을 호스팅할 네임스페이스를 만듭니다.
인증 정보에 대한 기본 DNS 도메인을 선택적으로 추가할 수 있습니다. 인증 정보에 기본 DNS 도메인을 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 자동으로 올바른 필드에 채워집니다. 다음 단계를 참조하십시오.
- GCP 계정의 Google Cloud Platform 프로젝트 ID 를 추가합니다. GCP 에 로그인하여 설정을 검색합니다.
- Google Cloud Platform 서비스 계정 JSON 키 를 추가합니다. 서비스 계정 JSON 키를 생성하려면 (https://cloud.google.com/iam/docs/creating-managing-service-accounts)를 참조하십시오. GCP 콘솔의 단계를 따르십시오.
- 새로운 Google Cloud Platform 서비스 계정 JSON 키에 대한 콘텐츠를 제공하십시오.
프록시를 활성화하려면 프록시 정보를 입력합니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 도메인이 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 및 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
-
HTTP 프록시 URL:
- Red Hat OpenShift 풀 시크릿 을 입력합니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
- 클러스터에 액세스할 수 있도록 SSH 개인 키 및 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}")
참고: 선택한 관리형 클러스터 네임스페이스에 불투명 보안이 생성됩니다. Hive는 불투명 보안을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 사전 생성된 인증 정보가 불투명 보안으로 관리 클러스터 네임 스페이스에 복사됩니다.
1.4.4. VMware vSphere에 대한 인증 정보 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 VMware vSphere에서 Red Hat OpenShift Container Platform 클러스터를 배포 및 관리하려면 인증 정보가 필요합니다. 참고: OpenShift Container Platform 버전 4.5.x 이상만 지원됩니다.
필수 액세스: 편집
참고: 이 절차는 다중 클러스터 엔진 Operator로 클러스터를 생성하기 전에 수행해야 합니다.
1.4.4.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- OpenShift Container Platform 버전 4.6 이상에 배포된 hub 클러스터입니다.
- VMware vSphere에서 Kubernetes 클러스터를 생성할 수 있도록 hub 클러스터의 인터넷 액세스.
설치 관리자 프로비저닝 인프라를 사용할 때 OpenShift Container Platform에 대해 구성된 VMware vSphere 로그인 자격 증명 및 vCenter 요구 사항입니다. 사용자 지정으로 vSphere에 클러스터 설치를 참조하십시오. 이러한 인증 정보에는 다음 정보가 포함됩니다.
- vCenter 계정 권한.
- 클러스터 리소스.
- DHCP 사용 가능
- ESXi 호스트에는 시간이 동기화되어 있습니다(예: NTP).
1.4.4.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 특히 자격 증명을 호스팅할 네임스페이스를 만듭니다.
인증 정보에 대한 기본 DNS 도메인을 선택적으로 추가할 수 있습니다. 인증 정보에 기본 DNS 도메인을 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 자동으로 올바른 필드에 채워집니다. 다음 단계를 참조하십시오.
- VMware vCenter 서버의 정규화된 호스트 이름 또는 IP 주소를 추가합니다. 값은 vCenter 서버 루트 CA 인증서에 정의해야 합니다. 가능한 경우 정규화된 호스트 이름을 사용합니다.
- VMware vCenter 사용자 이름을 추가합니다.
- VMware vCenter 암호 를 추가합니다.
VMware vCenter 루트 CA 인증서를 추가합니다.
-
VMware vCenter 서버에서 인증서를 사용하여
download.zip
패키지에서 인증서를 다운로드할 수 있습니다.https://<vCenter_address>/certs/download.zip
. vCenter_address 를 vCenter 서버의 주소로 바꿉니다. -
download.zip
의 압축을 해제합니다. .0
확장자가 있는certs/<platform
> 디렉터리의 인증서를 사용합니다. 팁:ls certs/<platform
> 명령을 사용하여 플랫폼에 사용 가능한 모든 인증서를 나열할 수 있습니다.&
lt;platform&
gt;를 플랫폼의 약어로 바꿉니다.lin
,mac
또는win
.예:
certs/lin/3a343545.0
모범 사례: 다음 명령을 사용하여
.0
확장자가 있는 여러 인증서를 함께 연결합니다.cat certs/lin/*.0 > ca.crt
-
VMware vCenter 서버에서 인증서를 사용하여
- VMware vSphere 클러스터 이름을 추가합니다.
- VMware vSphere 데이터 센터를 추가합니다.
- VMware vSphere 기본 데이터 저장소를 추가합니다.
- VMware vSphere 디스크 유형을 추가합니다.
- VMware vSphere 폴더 를 추가합니다.
- VMware vSphere 리소스 풀 을 추가합니다.
연결 해제된 설치만 해당: 연결이 끊긴 설치 하위 섹션에 있는 필드를 필수 정보로 완료합니다.
이미지 콘텐츠 소스: 이 값에는 연결이 끊긴 레지스트리 경로가 포함되어 있습니다. 경로에는 연결이 끊긴 설치를 위한 모든 설치 이미지의 호스트 이름, 포트, 리포지토리 경로가 포함됩니다. 예:
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 풀 시크릿 을 입력합니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
SSH 개인 키 및 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}")
참고: 선택한 관리형 클러스터 네임스페이스에 불투명 보안이 생성됩니다. Hive는 불투명 보안을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 사전 생성된 인증 정보가 불투명 보안으로 관리 클러스터 네임 스페이스에 복사됩니다.
1.4.5. Red Hat OpenStack에 대한 인증 정보 생성
Red Hat OpenStack Platform에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 다중 클러스터 엔진 Operator 콘솔을 사용하는 인증 정보가 필요합니다. 참고: OpenShift Container Platform 버전 4.5.x 이상만 지원됩니다.
참고: 이 절차는 다중 클러스터 엔진 Operator로 클러스터를 생성하기 전에 수행해야 합니다.
1.4.5.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- OpenShift Container Platform 버전 4.6 이상에 배포된 hub 클러스터입니다.
- Red Hat OpenStack Platform에서 Kubernetes 클러스터를 생성할 수 있도록 hub 클러스터의 인터넷 액세스가 가능합니다.
- 설치 관리자 프로비저닝 인프라를 사용할 때 OpenShift Container Platform에 대해 구성된 Red Hat OpenStack Platform 로그인 자격 증명 및 Red Hat OpenStack Platform 요구 사항입니다. 사용자 지정으로 OpenStack에 클러스터 설치를 참조하십시오.
CloudStack API에 액세스하기 위한
clouds.yaml
파일을 다운로드하거나 생성합니다.clouds.yaml
파일 내에서:- 사용할 클라우드 인증 섹션 이름을 결정합니다.
- 사용자 이름 행 바로 뒤에 암호 에 대한 행 을 추가합니다.
1.4.5.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 사용자 자격 증명을 호스팅할 네임스페이스를 만듭니다.
-
Red Hat OpenStack Platform
clouds.yaml
파일 콘텐츠를 추가합니다. 암호를 포함하여clouds.yaml
파일의 콘텐츠는 Red Hat OpenStack Platform 서버에 연결하는 데 필요한 정보를 제공합니다. 파일 콘텐츠에는 사용자 이름 뒤의 새 행에 추가하는 암호가 포함되어야합니다
. 내부 인증 기관을 사용하는 구성의 경우 Hive 배포자 Pod 내의 인증서 번들의 최종 위치를 참조하도록
clouds.yaml
파일을 수정합니다. Hive는 배포자 Pod 내의/etc/openstack-ca
에 인증서 번들 시크릿을 마운트합니다. 해당 디렉터리 내의 파일은 클러스터를 생성할 때 제공되는 시크릿의 키에 해당합니다.보안에서
ca.crt
키가 사용되었다고 가정하면 다음 예와 같이cacert
매개변수를clouds.yaml
파일에 추가합니다.clouds: openstack: auth: auth_url: https://openstack.example.local:13000 username: "svc-openshift" project_id: aa0owet0wfwerj user_domain_name: "idm" password: REDACTED region_name: "regionOne" interface: "public" identity_api_version: 3 cacert: /etc/openstack-ca/ca.crt
-
Red Hat OpenStack Platform 클라우드 이름을 추가합니다. 이 항목은 Red Hat OpenStack Platform 서버와의 통신을 설정하는 데 사용할
clouds.yaml
의 클라우드 섹션에 지정된 이름입니다. - 인증 정보에 대한 기본 DNS 도메인을 선택적으로 추가할 수 있습니다. 인증 정보에 기본 DNS 도메인을 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 자동으로 올바른 필드에 채워집니다.
연결이 끊긴 설치만 해당: 연결이 끊긴 설치 하위 섹션에 있는 필드를 필수 정보로 완료합니다.
- 클러스터 OS 이미지: 이 값은 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 가져오기 시크릿을 입력합니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
- 클러스터에 연결할 수 있는 SSH 개인 키 및 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)
참고: 선택한 관리형 클러스터 네임스페이스에 불투명 보안이 생성됩니다. Hive는 불투명 보안을 사용하여 클러스터를 프로비저닝합니다. Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 프로비저닝할 때 사전 생성된 인증 정보가 불투명 보안으로 관리 클러스터 네임 스페이스에 복사됩니다.
1.4.6. Red Hat Virtualization 인증 정보 생성
Red Hat Virtualization에서 Red Hat OpenShift Container Platform 클러스터를 배포하고 관리하려면 다중 클러스터 엔진 Operator 콘솔을 사용하는 인증 정보가 필요합니다.
참고: 이 절차는 다중 클러스터 엔진 Operator로 클러스터를 생성하기 전에 수행해야 합니다.
1.4.6.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- OpenShift Container Platform 버전 4.7 이상에 배포된 hub 클러스터입니다.
- Red Hat Virtualization에서 Kubernetes 클러스터를 생성할 수 있도록 hub 클러스터의 인터넷 액세스가 가능합니다.
구성된 Red Hat Virtualization 환경의 Red Hat Virtualization 로그인 자격 증명입니다. Red Hat Virtualization 설명서의 설치 가이드를 참조하십시오. 다음 목록은 필요한 정보를 보여줍니다.
- oVirt URL
- ovirt 정규화된 도메인 이름(FQDN)
- oVirt username
- ovirt 암호
- oVirt CA/Certificate
- 선택 사항: 프록시를 활성화하는 경우 프록시 정보입니다.
- Red Hat OpenShift Container Platform은 시크릿 정보를 가져옵니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다.
- 최종 클러스터에 대한 정보를 전송하기 위한 SSH 개인 키 및 공개 키입니다.
- oVirt에 클러스터를 설치할 수 있는 계정 권한
1.4.6.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의를 위해 보안을 강화하기 위해 특별히 사용자 자격 증명을 호스팅할 네임스페이스를 만듭니다.
- 새 인증 정보에 대한 기본 정보를 추가합니다. 선택적으로 이 인증 정보를 사용하여 클러스터를 생성할 때 올바른 필드에 자동으로 채워지는 기본 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 액세스의 akey 쌍 생성을 참조하십시오.
- 새 인증 정보 정보를 검토한 다음 추가 를 클릭합니다. 인증 정보를 추가하면 인증 정보 목록에 추가됩니다.
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 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 특히 자격 증명을 호스팅할 네임스페이스를 만듭니다.
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 허브 클러스터
- Multicluster engine operator hub cluster의 인터넷 액세스
- Ansible Automation Platform 호스트 이름 및 OAuth 토큰을 포함하는 Ansible 로그인 자격 증명. Ansible Automation Platform 의 인증 정보를 참조하십시오.
- 허브 클러스터를 설치하고 Ansible을 사용할 수 있는 계정 권한입니다. Ansible 사용자에 대해 자세히 알아보십시오.
1.4.8.2. 콘솔을 사용하여 인증 정보 관리
다중 클러스터 엔진 Operator 콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 특히 자격 증명을 호스팅할 네임스페이스를 만듭니다.
Ansible 인증 정보를 생성할 때 제공하는 Ansible 토큰 및 호스트 URL은 인증 정보를 편집할 때 해당 인증 정보를 사용하는 자동화를 위해 자동으로 업데이트됩니다. 업데이트는 클러스터 라이프사이클, 거버넌스 및 애플리케이션 관리 자동화와 관련된 Ansible 인증 정보를 사용하는 모든 자동화에 복사됩니다. 이렇게 하면 인증 정보를 업데이트한 후에도 자동화가 계속 실행됩니다.
콘솔에서 인증 정보를 편집할 수 있습니다. Ansible 인증 정보는 인증 정보에서 업데이트할 때 해당 인증 정보를 사용하는 자동화에서 자동으로 업데이트됩니다.
관리형 클러스터에서 실행하도록 Ansible Automation Platform 작업 구성 단계를 완료하여 이 인증 정보를 사용하는 Ansible 작업을 생성할 수 있습니다.
더 이상 인증 정보를 사용하는 클러스터를 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 자격 증명 옆에 있는 옵션 메뉴를 선택합니다.
1.4.9. 온-프레미스 환경에 대한 자격 증명 만들기Create a credential for an on-premises environment
콘솔을 사용하여 온-프레미스 환경에서 Red Hat OpenShift Container Platform 클러스터를 배포 및 관리하려면 인증 정보가 필요합니다. 인증 정보는 클러스터에 사용되는 연결을 지정합니다.
필수 액세스: 편집
1.4.9.1. 사전 요구 사항
인증 정보를 생성하기 전에 다음 사전 요구 사항이 필요합니다.
- 배포된 hub 클러스터입니다.
- 허브 클러스터의 인터넷 액세스로 인프라 환경에 Kubernetes 클러스터를 생성할 수 있습니다.
- 연결이 끊긴 환경의 경우 클러스터 생성을 위해 릴리스 이미지를 복사할 수 있는 구성된 미러 레지스트리가 있어야 합니다. 자세한 내용은 OpenShift Container Platform 설명서에서 연결이 끊긴 설치의 이미지 미러링 을 참조하십시오.
- 온-프레미스 환경에 클러스터 설치를 지원하는 계정 권한입니다.
1.4.9.2. 콘솔을 사용하여 인증 정보 관리
콘솔에서 인증 정보를 생성하려면 콘솔의 단계를 완료합니다.
탐색 메뉴에서 시작합니다. Credentials 를 클릭하여 기존 인증 정보 옵션에서 선택합니다. 팁: 편의성과 보안을 위해 특히 자격 증명을 호스팅할 네임스페이스를 만듭니다.
- 인증 정보 유형으로 호스트 인벤토리 를 선택합니다.
- 인증 정보에 대한 기본 DNS 도메인을 선택적으로 추가할 수 있습니다. 인증 정보에 기본 DNS 도메인을 추가하면 이 인증 정보가 있는 클러스터를 생성할 때 자동으로 올바른 필드에 채워집니다. DNS 도메인을 추가하지 않으면 클러스터를 생성할 때 추가할 수 있습니다.
- Red Hat OpenShift 풀 시크릿 을 입력합니다. Pull secret 에서 풀 시크릿을 다운로드할 수 있습니다. 가져오기 보안에 대한 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
- Add 를 선택하여 자격 증명을 생성합니다.
온-프레미스 환경에서 클러스터 만들기의 단계를 완료하여 이 자격 증명을 사용하는 클러스터를 만들 수 있습니다.
더 이상 인증 정보를 사용하는 클러스터를 관리하지 않는 경우 인증 정보를 삭제하여 인증 정보의 정보를 보호합니다. 대규모로 삭제할 작업을 선택하거나 삭제할 자격 증명 옆에 있는 옵션 메뉴를 선택합니다.
1.5. 클러스터 라이프사이클 소개
멀티 클러스터 엔진 Operator는 OpenShift Container Platform 및 Red Hat Advanced Cluster Management 허브 클러스터에 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 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 작업 구성
- 배치와 함께 ManagedClusterSets 사용
- Enabling 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 cluster
- 관리 클러스터 가져오기 컨트롤러 는 klusterlet Operator를 관리 클러스터에 배포합니다.
- Hive 컨트롤러 는 Kubernetes Operator용 다중 클러스터 엔진을 사용하여 생성한 클러스터를 프로비저닝합니다. Hive 컨트롤러는 Kubernetes Operator용 다중 클러스터 엔진에서 생성한 관리형 클러스터도 제거합니다.
- 클러스터 Curator 컨트롤러 에서 Ansible 작업을 pre-hook 또는 post-hook로 생성하여 관리 클러스터를 생성하거나 업그레이드할 때 클러스터 인프라 환경을 구성합니다.
- 관리형 클러스터 애드온이 hub 클러스터에서 활성화되면 해당 애드온 허브 컨트롤러가 hub 클러스터에 배포됩니다. 애드온 허브 컨트롤러 는 애드온 에이전트를 관리형 클러스터에 배포합니다.
1.5.1.2. 관리형 클러스터
- klusterlet Operator 는 관리형 클러스터에 등록 및 작업 컨트롤러를 배포합니다.
등록 에이전트는 관리 클러스터와 관리 클러스터 애드온을 hub 클러스터와 함께 등록합니다. registration Agent는 관리 클러스터 및 관리 클러스터 애드온의 상태도 유지합니다. 관리형 클러스터가 hub 클러스터에 액세스할 수 있도록 다음 권한이 Clusterrole 내에 자동으로 생성됩니다.
- 에이전트가 hub 클러스터에서 관리하는 자체 클러스터를 가져오거나 업데이트할 수 있습니다.
- 에이전트에서 허브 클러스터에서 관리하는 소유 클러스터의 상태를 업데이트할 수 있습니다.
- 에이전트가 인증서를 순환할 수 있도록 허용
-
에이전트가
coordination.k8s.io
리스를가져오
거나업데이트할
수 있도록 허용 -
에이전트에서 관리 클러스터 애드온을
가져올 수
있음 - 에이전트가 관리 클러스터 애드온의 상태를 업데이트할 수 있음
- 작업 에이전트는 관리되는 클러스터에 애드온 에이전트를 적용합니다. 관리 클러스터가 Hub 클러스터에 액세스할 수 있도록 허용하는 권한은 Clusterrole 내에 자동으로 생성되며 에이전트가 허브 클러스터에 이벤트를 보낼 수 있습니다.
클러스터를 계속 추가하고 관리하려면 클러스터 라이프사이클 소개를 참조하십시오.
1.5.2. 이미지 릴리스
다중 클러스터 엔진 Operator를 사용하여 공급자에 클러스터를 생성할 때 새 클러스터에 사용할 릴리스 이미지를 지정해야 합니다. 릴리스 이미지는 클러스터를 빌드하는 데 사용되는 Red Hat OpenShift Container Platform 버전을 지정합니다.
릴리스 이미지를 참조하는 파일은 acm-hive-openshift-releases
GitHub 리포지토리에서 유지 관리되는 YAML 파일입니다. Red Hat Advanced Cluster Management는 해당 파일을 사용하여 콘솔에서 사용 가능한 릴리스 이미지 목록을 생성합니다. 여기에는 OpenShift Container Platform의 최신 빠른 채널 이미지가 포함됩니다. 콘솔은 최신 OpenShift Container Platform의 최신 버전용 최신 릴리스 이미지만 표시합니다. 예를 들어 콘솔 옵션에 다음 릴리스 이미지가 표시될 수 있습니다.
- quay.io/openshift-release-dev/ocp-release:4.6.23-x86_64
- quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64
참고: console에서 클러스터를 생성할 때: visible: 'true'
레이블이 있는 이미지만 선택할 수 있습니다. ClusterImageSet
리소스의 이 레이블 예는 다음 콘텐츠에서 제공됩니다.
apiVersion: config.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: fast visible: 'true' name: img4.10.1-x86-64-appsub spec: releaseImage: quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64
추가 릴리스 이미지가 저장되지만 콘솔에는 표시되지 않습니다. 사용 가능한 릴리스 이미지를 모두 보려면 CLI에서 kubectl get clusterimageset
를 실행합니다. 최신 릴리스 이미지로 클러스터를 생성하도록 최신 버전만 콘솔에 있습니다. 경우에 따라 특정 버전인 클러스터를 생성해야 할 수도 있습니다. 따라서 이전 버전을 사용할 수 있습니다. Red Hat Advanced Cluster Management는 해당 파일을 사용하여 콘솔에서 사용 가능한 릴리스 이미지 목록을 생성합니다. 여기에는 OpenShift Container Platform의 최신 빠른 채널 이미지가 포함됩니다.
리포지토리에는 릴리스 이미지로 작업할 때 사용하는 디렉터리인 clusterImageSets
디렉터리와 서브스크립션
디렉터리가 포함되어 있습니다.
clusterImageSets
디렉터리에는 다음 디렉터리가 포함되어 있습니다.
- fast: 지원되는 각 OpenShift Container Platform 버전의 최신 릴리스 이미지를 참조하는 파일이 포함되어 있습니다. 이 폴더의 릴리스 이미지는 테스트, 확인 및 지원됩니다.
- 릴리스: 각 OpenShift Container Platform 버전(테이블, 빠른, 후보 채널)의 모든 릴리스 이미지를 참조하는 파일이 포함되어 있습니다. 이러한 릴리스는 모두 테스트되고 안정적인 것으로 확인되지 않았습니다.
- stable: 지원되는 각 OpenShift Container Platform 버전에 대한 릴리스 이미지의 최신 두 가지 안정적인 버전을 참조하는 파일이 포함되어 있습니다.
참고: 기본적으로 현재 릴리스 이미지 목록은 한 시간씩 업데이트됩니다. 제품을 업그레이드한 후 새 버전의 제품에 권장되는 릴리스 이미지 버전을 반영하는 데 최대 1시간이 걸릴 수 있습니다.
다음과 같은 세 가지 방법으로 자체 ClusterImageSets
를 큐레이션할 수 있습니다.
세 가지 방법 중 첫 번째 단계는 포함된 서브스크립션을 비활성화하여 최신 빠른 채널 이미지를 자동으로 업데이트하는 것입니다. multiclusterhub
리소스에서 installer 매개변수를 사용하여 최신 fast ClusterImageSets
의 자동 큐레이션을 비활성화할 수 있습니다. spec.disableUpdateClusterImageSets
매개변수를 true
와 false
로 전환하면 Red Hat Advanced Cluster Management와 함께 설치된 서브스크립션이 각각 비활성화 또는 활성화됩니다. 자체 이미지를 큐레이팅하려면 spec.disableUpdateClusterImageSets
를 true
로 설정하여 서브스크립션을 비활성화합니다.
옵션 1: 클러스터를 생성할 때 콘솔에서 사용할 특정 ClusterImageSet
의 이미지 참조를 지정합니다. 지정한 각 새 항목은 persists이며 향후 모든 클러스터 프로비저닝에 사용할 수 있습니다. 항목의 예는 quay.io/openshift-release-dev/ocp-release:4.6.8-x86_64
입니다.
옵션 2: acm-hive-openshift-releases
GitHub 리포지토리에서 ClusterImageSets
YAML 파일을 수동으로 생성하고 적용합니다.
옵션 3: acm-hive-openshift-releases
GitHub 리포지토리의 README.md
를 따라 분기된 GitHub 리포지토리에서 ClusterImageSets
자동 업데이트를 활성화합니다.
Subscription
디렉터리에는 릴리스 이미지 목록을 가져올 위치를 지정하는 파일이 포함되어 있습니다.
Red Hat Advanced Cluster Management의 기본 릴리스 이미지는 Quay.io 디렉터리에 제공됩니다.
이미지는 릴리스 2.5의 acm-hive-openshift-releases GitHub 리포지토리에 있는 파일에서 참조합니다.
1.5.2.1. 다른 아키텍처에 클러스터를 배포할 릴리스 이미지 생성
두 아키텍처의 파일이 포함된 릴리스 이미지를 수동으로 생성하여 허브 클러스터의 아키텍처와 다른 아키텍처에 클러스터를 생성할 수 있습니다.
예를 들어 ppc64le
,aarch64
또는 s390x
아키텍처에서 실행 중인 허브 클러스터에서 x86_64
클러스터를 생성해야 할 수 있습니다. 새 릴리스 이미지를 사용하면 OpenShift Container Platform 릴리스 레지스트리에서 다중 아키텍처 이미지 매니페스트를 제공할 수 있으므로 두 파일 세트로 릴리스 이미지를 생성하면 클러스터 생성에 성공합니다.
OpenShift Container Platform 4.11 이상에서는 기본적으로 여러 아키텍처를 지원합니다. 다음 clusterImageSet
을 사용하여 클러스터를 프로비저닝할 수 있습니다.
apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: fast visible: 'true' name: img4.12.0-multi-appsub spec: releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-multi
여러 아키텍처를 지원하지 않는 OpenShift Container Platform 이미지의 릴리스 이미지를 생성하려면 아키텍처 유형에 대한 다음 예와 유사한 단계를 완료합니다.
OpenShift Container Platform 릴리스 레지스트리에서
x86_64
,s390x
,aarch64
및ppc64le
릴리스 이미지가 포함된 매니페스트 목록을 생성합니다.다음 예제 명령을 사용하여 Quay 리포지토리에서 해당 환경의 두 아키텍처에 대한 매니페스트 목록을 가져옵니다.
podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64 podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-ppc64le podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-s390x podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-aarch64
이미지를 유지보수하는 프라이빗 리포지토리에 로그인합니다.
podman login <private-repo>
private-repo
를 리포지토리 경로로 바꿉니다.환경에 적용되는 다음 명령을 실행하여 프라이빗 리포지토리에 릴리스 이미지 매니페스트를 추가합니다.
podman push quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64 <private-repo>/ocp-release:4.10.1-x86_64 podman push quay.io/openshift-release-dev/ocp-release:4.10.1-ppc64le <private-repo>/ocp-release:4.10.1-ppc64le podman push quay.io/openshift-release-dev/ocp-release:4.10.1-s390x <private-repo>/ocp-release:4.10.1-s390x podman push quay.io/openshift-release-dev/ocp-release:4.10.1-aarch64 <private-repo>/ocp-release:4.10.1-aarch64
private-repo
를 리포지토리 경로로 바꿉니다.새 정보에 대한 매니페스트를 생성합니다.
podman manifest create mymanifest
두 릴리스 이미지에 대한 참조를 매니페스트 목록에 추가합니다.
podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-x86_64 podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-ppc64le podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-s390x podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-aarch64
private-repo
를 리포지토리 경로로 바꿉니다.매니페스트 목록의 목록을 기존 매니페스트와 병합합니다.
podman manifest push mymanifest docker://<private-repo>/ocp-release:4.10.1
private-repo
를 리포지토리 경로로 바꿉니다.
hub 클러스터에서 리포지터리의 매니페스트를 참조하는 릴리스 이미지를 만듭니다.
다음 예와 유사한 정보가 포함된 YAML 파일을 생성합니다.
apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: labels: channel: fast visible: "true" name: img4.10.1-appsub spec: releaseImage: <private-repo>/ocp-release:4.10.1
private-repo
를 리포지토리 경로로 바꿉니다.hub 클러스터에서 다음 명령을 실행하여 변경 사항을 적용합니다.
oc apply -f <file-name>.yaml
file-name
을 방금 생성한 YAML 파일의 이름으로 바꿉니다.
- OpenShift Container Platform 클러스터를 생성할 때 새 릴리스 이미지를 선택합니다.
- Red Hat Advanced Cluster Management 콘솔을 사용하여 관리형 클러스터를 배포하는 경우 클러스터 생성 프로세스 중 아키텍처 필드에서 관리 클러스터의 아키텍처를 지정합니다.
생성 프로세스에서는 병합된 릴리스 이미지를 사용하여 클러스터를 생성합니다.
1.5.2.2. 연결이 끊긴 동안 사용자 정의 릴리스 이미지 목록 유지
허브 클러스터에 인터넷 연결이 없는 경우 릴리스 이미지의 사용자 정의 목록을 유지 관리해야 하는 경우도 있습니다. 클러스터를 생성할 때 사용 가능한 릴리스 이미지의 자체 사용자 정의 목록을 생성할 수 있습니다. 연결이 끊긴 동안 사용 가능한 릴리스 이미지를 관리하려면 다음 단계를 완료합니다.
- 연결된 시스템에 있는 동안 acm-hive-openshift-releases GitHub 리포지토리로 이동하여 버전 2.6에서 사용할 수 있는 클러스터 이미지 세트에 액세스합니다.
-
연결이 끊긴 다중 클러스터 엔진 Operator 허브 클러스터에 액세스할 수 있는 시스템에
clusterImageSets
디렉터리를 복사합니다. 관리형 클러스터에 적합한 다음 단계를 완료하여 관리 대상 클러스터와 연결이 끊긴 리포지토리와 클러스터 이미지 세트 간의 매핑을 추가합니다.
-
OpenShift Container Platform 관리 클러스터의 경우
ImageContentSourcePolicy
오브젝트를 사용하여 매핑을 완료하는 방법에 대한 정보는 이미지 레지스트리 저장소 미러링 구성을 참조하십시오. -
OpenShift Container Platform 클러스터가 아닌 관리형 클러스터의 경우
ManageClusterImageRegistry
사용자 정의 리소스 정의를 사용하여 이미지 세트의 위치를 덮어씁니다. 매핑 을 위해 클러스터를 재정의하는 방법에 대한 정보는 관리형 클러스터에서 레지스트리 이미지 지정에서 가져오기 를 참조하십시오.
-
OpenShift Container Platform 관리 클러스터의 경우
-
clusterImageSet
YAML 콘텐츠를 수동으로 추가하여 콘솔을 사용하여 클러스터를 생성할 때 사용할 수 있는 이미지의 YAML 파일을 추가합니다. 나머지 OpenShift Container Platform 릴리스 이미지의
clusterImageSet
YAML 파일을 수정하여 이미지를 저장하는 올바른 오프라인 리포지토리를 참조합니다. 업데이트는 다음 예와 유사해야 합니다.apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: name: img4.4.0-rc.6-x86-64 spec: releaseImage: IMAGE_REGISTRY_IPADDRESS_or_DNSNAME/REPO_PATH/ocp-release:4.4.0-rc.6-x86_64
이미지가 YAML 파일에서 참조되는 오프라인 이미지 레지스트리에 로드되었는지 확인합니다.
각 YAML 파일에 대해 다음 명령을 입력하여 각
clusterImageSets
를 생성합니다.oc create -f <clusterImageSet_FILE>
clusterImageSet_FILE
을 클러스터 이미지 세트 파일의 이름으로 교체합니다. 예를 들면 다음과 같습니다.oc create -f img4.11.9-x86_64.yaml
추가할 각 리소스에 대해 이 명령을 실행하면 사용 가능한 릴리스 이미지 목록이 제공됩니다.
- 또는 create 클러스터 콘솔에 이미지 URL을 직접 붙여넣을 수 있습니다. 이미지 URL을 추가하면 새 clusterImageSets가 생성되지 않는 경우 생성됩니다.
- 클러스터를 생성할 때 콘솔에서 현재 사용 가능한 릴리스 이미지 목록을 확인합니다.
1.5.3. 인프라 환경 생성
콘솔을 사용하여 호스트를 관리하고 해당 호스트에 클러스터를 생성할 수 있는 인프라 환경을 생성할 수 있습니다.
인프라 환경은 다음과 같은 기능을 지원합니다.
- 클러스터의 제로 프로비저닝: 스크립트를 사용하여 클러스터를 배포합니다. 자세한 내용은 Red Hat OpenShift Container Platform 설명서의 연결이 끊긴 환경에서 대규모로 분산 단위 배포를 참조하십시오.
- 늦은 바인딩: 인프라 관리자가 호스트를 부팅하고 클러스터 작성자는 나중에 해당 호스트에 클러스터를 바인딩할 수 있습니다. 클러스터 작성자는 늦은 바인딩을 사용할 때 인프라에 대한 관리자 권한이 필요하지 않습니다.
-
듀얼 스택: IPv4 및 IPv6 주소가 모두 있는 클러스터를 배포합니다. 듀얼 스택은
OVN-Kubernetes
네트워킹 구현을 사용하여 여러 서브넷을 지원합니다. - 원격 작업자 노드 추가: 생성 및 실행 후 클러스터에 원격 작업자 노드를 추가하여 백업 목적으로 다른 위치에 노드를 추가할 수 있는 유연성을 제공합니다.
- NMState를 사용하는 고정 IP: NMState API를 사용하여 환경에 대한 고정 IP 주소를 정의합니다.
1.5.3.1. 사전 요구 사항
인프라 환경을 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- OpenShift Container Platform 버전 4.11 이상에 배포된 허브 클러스터가 있어야 합니다.
- 허브 클러스터(연결됨)에 대한 인터넷 액세스 또는 환경 생성에 필요한 이미지를 검색하는 데 인터넷(연결이 끊어진)이 인터넷에 연결되어 있는 내부 또는 미러 레지스트리에 연결해야 합니다.
- 허브 클러스터에 구성된 CIM(Central Infrastructure Management) 기능의 구성된 인스턴스가 필요합니다.
- OpenShift Container Platform 풀 시크릿이 필요합니다. 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
-
기본적으로
~/.ssh/id_rsa.pub
파일에 있는 SSH 키가 필요합니다. - 구성된 스토리지 클래스가 필요합니다.
- 연결이 끊긴 환경만 해당: OpenShift Container Platform 설명서 의 네트워크의 엣지 네트워크에서 클러스터에 대한 절차를 완료합니다.
1.5.3.2. 중앙 인프라 관리 서비스 활성화
CIM 서비스는 멀티 클러스터 엔진 Operator와 함께 제공되며 OpenShift Container Platform 클러스터를 배포합니다. CIM은 허브 클러스터에서 MultiClusterHub Operator를 활성화할 때 배포되지만 활성화해야 합니다.
CIM 서비스를 활성화하려면 다음 단계를 완료합니다.
이 단계는 베어 메탈, Red Hat OpenStack Platform, VMware vSphere 또는 사용자 프로비저닝 인프라(UPI) 방법을 사용하여 설치되었으며 플랫폼이
None
입니다. hub 클러스터가 다른 플랫폼에 있는 경우 이 단계를 건너뜁니다.다음 명령을 실행하여 Bare Metal Operator가 모든 네임스페이스를 조사할 수 있도록
프로비저닝
리소스를 수정합니다.oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
연결이 끊긴 환경의 경우 인프라 Operator와 동일한 네임스페이스에
ConfigMap
을 생성하여 미러 레지스트리의ca-bundle.crt
및registries.conf
값을 지정합니다. 파일ConfigMap
은 다음 예와 유사해야 합니다.apiVersion: v1 kind: ConfigMap metadata: name: <mirror-config> namespace: "<infrastructure-operator-namespace>" labels: app: assisted-service data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- certificate contents -----END CERTIFICATE----- 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"
unqualified-search-registries
목록에 있는 레지스트리는 ECDHELIC_CONTAINER_REGISTRIES
환경 변수의 인증 무시 목록에 자동으로 추가됩니다. 관리 클러스터의 풀 시크릿을 검증할 때 지정된 레지스트리가 인증이 필요하지 않습니다.다음 단계를 완료하여
AgentServiceConfig
사용자 지정 리소스를 생성합니다.연결이 끊긴 환경의 경우
agent_service_config.yaml
파일에 다음YAML
콘텐츠를 저장합니다.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> unauthenticatedRegistries: - <unauthenticated_registry> imageStorage: accessModes: - ReadWriteOnce resources: requests: storage: <img_volume_size> osImages: - openshiftVersion: "<ocp_version>" version: "<ocp_release_version>" url: "<iso_url>" cpuArchitecture: "x86_64"
mirror_config
를 미러 레지스트리 구성 세부 정보가 포함된ConfigMap
의 이름으로 교체합니다.인증이 필요하지 않은 미러 레지스트리를 사용하는 경우 선택적
unauthenticated_registry
매개변수를 포함합니다. 이 목록의 항목은 검증되지 않거나 가져오기 시크릿에 항목이 있어야 합니다.연결된 환경의 경우
agent_service_config.yaml
파일에 다음YAML
콘텐츠를 저장합니다.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> imageStorage: accessModes: - ReadWriteOnce resources: requests: storage: <img_volume_size>
db_volume_size
를databaseStorage
필드의 볼륨 크기로 교체합니다(예:1Gi
). 이 값은 클러스터의 데이터베이스 테이블 및 데이터베이스 뷰와 같은 파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 필요한 최소 값은1Gi
입니다. 클러스터가 많은 경우 더 높은 값을 사용해야 할 수 있습니다.fs_volume_size
를filesystemStorage
필드의 볼륨 크기로 교체합니다(예: 클러스터당200M
, 지원되는 OpenShift Container Platform 버전당2-3Gi
). 필요한 최소 값은1Gi
이지만 권장 값은100Gi
이상입니다. 이 값은 클러스터의 로그, 매니페스트,kubeconfig
파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 클러스터가 많은 경우 더 높은 값을 사용해야 할 수 있습니다.img_volume_size
를imageStorage
필드의 볼륨 크기로 교체합니다(예: 운영 체제 이미지당2Gi
). 최소 값은10Gi
이지만 권장 값은50Gi
이상입니다. 이 값은 클러스터 이미지에 할당되는 스토리지 양을 지정합니다. 실행 중인 Red Hat Enterprise Linux CoreOS 인스턴스마다 1GB의 이미지 스토리지를 허용해야 합니다. Red Hat Enterprise Linux CoreOS의 여러 클러스터와 인스턴스가 있는 경우 더 높은 값을 사용해야 할 수 있습니다.ocp_version
을 설치할 OpenShift Container Platform 버전으로 교체합니다(예:4.12
).ocp_release_version
을 특정 설치 버전 (예:49.83.202103251640-0
)으로 바꿉니다.iso_url
을 ISO URL로 교체합니다(예:https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/rhcos-4.10.3-x86_64-live.x86_64.iso
). 다른 값은 https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/ 에서 확인할 수 있습니다.다음 명령을 실행하여 AgentServiceConfig 사용자 지정 리소스를 생성합니다.
oc create -f agent_service_config.yaml
출력은 다음 예와 유사할 수 있습니다.
agentserviceconfig.agent-install.openshift.io/agent created
CIM 서비스가 구성되어 있습니다. assisted-service
및 assisted-image-service
배포를 확인하고 해당 Pod가 준비되고 실행 중인지 확인할 수 있습니다.
1.5.3.2.1. 프로비저닝 사용자 정의 리소스(CR)를 수동으로 생성
다음 명령을 사용하여 자동화된 프로비저닝
용 서비스를 활성화하는 프로비저닝 사용자 정의 리소스를 수동으로 생성합니다.
oc create -f provisioning-configuration.yaml
사용자 정의 리소스는 다음 샘플과 유사할 수 있습니다.
apiVersion: metal3.io/v1alpha1 kind: Provisioning metadata: name: provisioning-configuration spec: provisioningNetwork: Disabled watchAllNamespaces: true
1.5.3.2.2. Amazon Web Services에서 중앙 인프라 관리 활성화
Amazon Web Services에서 hub 클러스터를 실행하고 CIM 서비스를 활성화하려면 CIM 활성화 후 다음 추가 단계를 완료합니다.
허브에 로그인했는지 확인하고 다음 명령을 실행하여
assisted-image-service
에서 구성된 고유 도메인을 찾습니다.oc get routes --all-namespaces | grep assisted-image-service
도메인은
assisted-image-service-multicluster-engine.apps.<yourdomain>.com과 유사할 수 있습니다.
허브에 로그인했는지 확인하고
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에서 CIM 서비스가 활성화되어 있는지 확인하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 Pod가 정상인지 확인합니다.
oc get pods -n multicluster-engine | grep assist
-
새 인프라 환경을 생성하고 다운로드 URL에서 새
nlb-apps
URL을 사용하는지 확인합니다.
1.5.3.3. 콘솔을 사용하여 인프라 환경 생성
콘솔에서 인프라 환경을 생성하려면 다음 단계를 완료합니다.
- 탐색 메뉴에서 인프라 > 호스트 인벤토리 로 이동하여 인프라 환경 생성을 클릭합니다.
인프라 환경 설정에 다음 정보를 추가합니다.
- 이름: 인프라 환경의 고유한 이름입니다.
- 네트워크 유형: 인프라 환경에 추가할 수 있는 호스트 유형을 지정합니다. 베어 메탈 호스트를 사용하는 경우에만 고정 IP 옵션을 사용할 수 있습니다.
- Location: 호스트의 지리적 위치를 지정합니다. 지리적 위치를 사용하여 클러스터를 생성할 때 클러스터의 데이터가 저장되는 위치를 쉽게 확인할 수 있습니다.
- 레이블: 인프라 환경에 레이블을 추가할 수 있는 선택적 필드로, 보다 쉽게 찾아 특성을 공유하는 다른 환경으로 환경을 그룹화할 수 있습니다. 네트워크 유형 및 위치에 대한 선택 사항이 레이블 목록에 자동으로 추가됩니다.
- 풀 시크릿: OpenShift Container Platform 리소스에 액세스할 수 있는 OpenShift Container Platform 풀 시크릿 입니다.
-
SSH 공개 키: 호스트와의 보안 통신을 활성화하는 SSH 키입니다. 기본적으로
~/.ssh/id_rsa.pub
파일에 있습니다. 모든 클러스터에서 프록시 설정을 활성화하려면 설정을 선택하여 활성화합니다. 이를 위해서는 다음 정보를 입력해야 합니다.
- HTTP 프록시 URL: 검색 서비스에 액세스할 때 사용해야 하는 URL입니다.
-
HTTPS 프록시 URL: 검색 서비스에 액세스할 때 사용해야 하는 보안 프록시 URL입니다.
https
는 아직 지원되지 않으므로http
형식이어야 합니다. -
프록시 도메인 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 및 별표*
를 추가합니다.
이제 인프라 환경에 호스트를 추가하여 계속할 수 있습니다.
1.5.3.4. 인프라 환경에 액세스
인프라 환경에 액세스하려면 콘솔에서 Infrastructure > Host inventory 를 선택합니다. 목록에서 인프라 환경을 선택하여 해당 인프라 환경에 대한 세부 정보 및 호스트를 확인합니다.
1.5.4. 클러스터 생성
멀티 클러스터 엔진 Operator가 있는 클라우드 공급자 전반에서 Red Hat OpenShift Container Platform 클러스터를 생성하는 방법을 알아봅니다.
멀티 클러스터 엔진 Operator는 OpenShift Container Platform과 함께 제공되는 Hive Operator를 사용하여 온프레미스 클러스터 및 호스트된 컨트롤 플레인을 제외한 모든 공급자에 대한 클러스터를 프로비저닝합니다. 온프레미스 클러스터를 프로비저닝할 때 멀티 클러스터 엔진 Operator는 OpenShift Container Platform과 함께 제공되는 CIM(Central Infrastructure Management) 및 지원 설치 관리자 기능을 사용합니다. 호스트된 컨트롤 플레인의 호스트 클러스터는 HyperShift Operator를 사용하여 프로비저닝됩니다.
1.5.4.1. CLI를 사용하여 클러스터 생성
Kubernetes용 멀티 클러스터 엔진은 내부 Hive 구성 요소를 사용하여 Red Hat OpenShift Container Platform 클러스터를 생성합니다. 클러스터 생성 방법을 알아보려면 다음 정보를 참조하십시오.
1.5.4.1.1. 사전 요구 사항
클러스터를 생성하기 전에 clusterImageSets 리포지토리를 복제하고 hub 클러스터에 적용해야 합니다. 다음 단계를 참조하십시오.
다음 명령을 실행하여 복제합니다.
git clone https://github.com/stolostron/acm-hive-openshift-releases.git cd acm-hive-openshift-releases git checkout origin/release-2.7
다음 명령을 실행하여 hub 클러스터에 적용합니다.
find clusterImageSets/fast -type d -exec oc apply -f {} \; 2> /dev/null
클러스터를 생성할 때 Red Hat OpenShift Container Platform 릴리스 이미지를 선택합니다.
1.5.4.1.2. ClusterDeployment를 사용하여 클러스터 생성
ClusterDeployment
는 클러스터의 라이프사이클을 제어하는 데 사용되는 Hive 사용자 정의 리소스입니다.
Hive 사용 설명서에 따라 ClusterDeployment
사용자 정의 리소스를 생성하고 개별 클러스터를 생성합니다.
1.5.4.1.3. ClusterPool을 사용하여 클러스터 생성
ClusterPool
은 여러 클러스터를 생성하는 데 사용되는 Hive 사용자 정의 리소스이기도 합니다.
클러스터 풀 문서에 따라 Hive Cluster
Pool 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 클러스터를 생성할 수 있습니다.
클러스터를 생성할 때 생성 프로세스는 Hive 리소스와 함께 OpenShift Container Platform 설치 프로그램을 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서의 AWS 에 설치를 참조하십시오.
1.5.4.3.1. 사전 요구 사항
AWS에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- 배포된 허브 클러스터가 있어야 합니다.
- AWS 인증 정보가 필요합니다. 자세한 내용은 Amazon Web Services에 대한 인증 정보 생성을 참조하십시오.
- AWS에서 구성된 도메인이 필요합니다. 도메인을 구성하는 방법에 대한 지침은 AWS 계정 구성을 참조하십시오.
- 사용자 이름, 암호, 액세스 키 ID 및 시크릿 액세스 키를 포함하는 AWS(Amazon Web Services) 로그인 키가 있어야 합니다. 보안 인증 정보 이해 및 가져오기 를 참조하십시오.
- OpenShift Container Platform 이미지 풀 시크릿이 있어야 합니다. 이미지 풀 시크릿 사용을 참조하십시오.
참고: 클라우드 공급자의 클라우드 공급자 액세스 키를 변경하는 경우 콘솔에서 클라우드 공급자의 해당 인증 정보를 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리형 클러스터를 삭제하려고 할 때 필요합니다.
1.5.4.3.2. 콘솔을 사용하여 클러스터 생성
콘솔에서 클러스터를 생성하려면 인프라 > ; 클러스터로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.
참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계를 위해 대상 관리 클러스터 가져오기를 hub 클러스터로 참조하십시오.
인증 정보를 생성해야 하는 경우 자세한 내용은 Amazon Web Services의 인증 정보 생성을 참조하십시오.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
AWS 계정으로 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어쓰는 방식으로 변경할 수 있습니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다. 자세한 내용은 AWS 계정 구성을 참조하십시오.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동의 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.
- region: 노드 풀을 원하는 리전을 지정합니다.
- CPU 아키텍처: 관리형 클러스터의 아키텍처 유형이 hub 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 머신의 명령어 집합 아키텍처의 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x, cover 64 입니다.
- zones: 컨트롤 플레인 풀을 실행할 위치를 지정합니다. 더 분산된 컨트롤 플레인 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 떨어져 있는 영역이 더 분산될 수 있습니다.
- 인스턴스 유형: 컨트롤 플레인 노드의 인스턴스 유형을 지정합니다. 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
- 루트 스토리지: 클러스터에 할당할 루트 스토리지의 양을 지정합니다.
작업자 풀에 0개 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 작업자 노드가 0개 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 선택적 정보에는 다음 필드가 포함됩니다.
- zones: 작업자 풀을 실행할 위치를 지정합니다. 더 분산된 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 떨어져 있는 영역이 더 분산될 수 있습니다.
- 인스턴스 유형: 작업자 풀의 인스턴스 유형을 지정합니다. 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
- 노드 수: 작업자 풀의 노드 수를 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
- 루트 스토리지: 작업자 풀에 할당된 루트 스토리지의 양을 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
클러스터에 네트워킹 세부 정보가 필요하며 IPv6를 사용하는 데 여러 네트워크가 필요합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.
인증 정보에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시:
HTTP
트래픽의 프록시로 사용해야 하는 URL을 지정합니다. -
HTTPS 프록시:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL을 지정합니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 사이트 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
AWS GovCloud 클러스터를 생성할 때 AWS 개인 구성 정보가 사용됩니다. 해당 환경에서 클러스터를 생성하는 방법에 대한 자세한 내용은 을 참조하십시오.
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML: On 을 선택하여 패널에서 install-config.yaml
파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 oc
명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator의 관리 아래에 자동으로 구성됩니다.
1.5.4.4. Amazon Web Services GovCloud에서 클러스터 생성
콘솔을 사용하여 AWS(Amazon Web Services) 또는 AWS GovCloud에서 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다. 다음 절차에서는 AWS GovCloud에서 클러스터를 생성하는 방법을 설명합니다. AWS 에서 클러스터를 생성하는 방법은 Amazon Web Services에서 클러스터 생성을 참조하십시오.
AWS GovCloud는 정부 문서를 클라우드에 저장하는 데 필요한 추가 요구 사항을 충족하는 클라우드 서비스를 제공합니다. AWS GovCloud에서 클러스터를 생성할 때 환경을 준비하기 위해 추가 단계를 완료해야 합니다.
클러스터를 생성할 때 생성 프로세스는 Hive 리소스와 함께 OpenShift Container Platform 설치 프로그램을 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서의 정부 리전에 AWS의 클러스터 설치를 참조하십시오. 다음 섹션에서는 AWS GovCloud에서 클러스터를 생성하는 단계를 설명합니다.
1.5.4.4.1. 사전 요구 사항
AWS GovCloud 클러스터를 생성하기 전에 다음 사전 요구 사항이 있어야 합니다.
- 사용자 이름, 암호, 액세스 키 ID 및 시크릿 액세스 키를 포함하는 AWS 로그인 인증 정보가 있어야 합니다. 보안 인증 정보 이해 및 가져오기 를 참조하십시오.
- AWS 인증 정보가 필요합니다. 자세한 내용은 Amazon Web Services에 대한 인증 정보 생성을 참조하십시오.
- AWS에서 구성된 도메인이 필요합니다. 도메인을 구성하는 방법에 대한 지침은 AWS 계정 구성을 참조하십시오.
- OpenShift Container Platform 이미지 풀 시크릿이 있어야 합니다. 이미지 풀 시크릿 사용을 참조하십시오.
- 허브 클러스터용 기존 Red Hat OpenShift Container Platform 클러스터가 있는 Amazon VPC(Virtual Private Cloud)가 있어야 합니다. 이 VPC는 관리형 클러스터 리소스 또는 관리형 클러스터 서비스 끝점에 사용되는 VPC와 달라야 합니다.
- 관리 클러스터 리소스가 배포된 VPC가 필요합니다. 허브 클러스터 또는 관리형 클러스터 서비스 끝점에 사용되는 VPC와 같을 수 없습니다.
- 관리형 클러스터 서비스 엔드 포인트를 제공하는 하나 이상의 VPC가 필요합니다. 허브 클러스터 또는 관리형 클러스터 리소스에 사용되는 VPC와 같을 수 없습니다.
- CIDR(Classless Inter-Domain Routing)으로 지정된 VPC의 IP 주소가 겹치지 않는지 확인합니다.
-
Hive 네임스페이스 내의 인증 정보를 참조하는
HiveConfig
사용자 지정 리소스가 필요합니다. 이 사용자 정의 리소스는 관리형 클러스터 서비스 엔드 포인트에 생성한 리소스를 VPC에 생성할 수 있어야 합니다.
참고: 클라우드 공급자의 클라우드 공급자 액세스 키를 변경하는 경우 멀티 클러스터 엔진 Operator 콘솔에서 클라우드 공급자의 해당 인증 정보를 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리형 클러스터를 삭제하려고 할 때 필요합니다.
1.5.4.4.2. AWS GovCloud에 배포하도록 Hive 구성
AWS GovCloud에 클러스터를 생성하는 것은 표준 AWS에서 클러스터를 생성하는 것과 거의 동일하지만 AWS GovCloud에서 클러스터에 대한 AWS PrivateLink를 준비하기 위해 몇 가지 추가 단계를 완료해야 합니다.
1.5.4.4.2.1. 리소스 및 끝점에 대한 VPC 생성
사전 요구 사항에 나열된 대로 허브 클러스터가 포함된 VPC 외에도 두 개의 VPC가 필요합니다. VPC를 생성하는 특정 단계는 Amazon Web Services 설명서에서 VPC 생성 설명서를 참조하십시오.
- 프라이빗 서브넷을 사용하여 관리형 클러스터의 VPC를 생성합니다.
- 프라이빗 서브넷을 사용하여 관리형 클러스터 서비스 엔드포인트에 대해 하나 이상의 VPC를 생성합니다. 한 리전의 각 VPC에는 255개의 VPC 끝점이 제한되어 있으므로 해당 리전에서 255개 이상의 클러스터를 지원하려면 여러 개의 VPC가 필요합니다.
각 VPC에 대해 해당 리전에서 지원되는 모든 가용성 영역에 서브넷을 생성합니다. 컨트롤러 요구 사항으로 인해 각 서브넷에 최소 255개의 사용 가능한 IP 주소가 있어야 합니다.
다음 예제에서는
us-gov-east-1
리전에 6개의 가용성 영역이 있는 VPC의 서브넷을 구성하는 방법을 보여줍니다.vpc-1 (us-gov-east-1) : 10.0.0.0/20 subnet-11 (us-gov-east-1a): 10.0.0.0/23 subnet-12 (us-gov-east-1b): 10.0.2.0/23 subnet-13 (us-gov-east-1c): 10.0.4.0/23 subnet-12 (us-gov-east-1d): 10.0.8.0/23 subnet-12 (us-gov-east-1e): 10.0.10.0/23 subnet-12 (us-gov-east-1f): 10.0.12.0/2
vpc-2 (us-gov-east-1) : 10.0.16.0/20 subnet-21 (us-gov-east-1a): 10.0.16.0/23 subnet-22 (us-gov-east-1b): 10.0.18.0/23 subnet-23 (us-gov-east-1c): 10.0.20.0/23 subnet-24 (us-gov-east-1d): 10.0.22.0/23 subnet-25 (us-gov-east-1e): 10.0.24.0/23 subnet-26 (us-gov-east-1f): 10.0.28.0/23
- 모든 hub 환경(hub 클러스터 VPC)이 피어링, 전송 게이트웨이 및 모든 DNS 설정이 활성화되어 있는 VPC 엔드포인트에 대해 생성한 VPC에 네트워크로 연결되어 있는지 확인합니다.
- AWS GovCloud 연결에 필요한 AWS PrivateLink의 DNS 설정을 확인하는 데 필요한 VPC 목록을 수집합니다. 여기에는 구성 중인 다중 클러스터 엔진 Operator 인스턴스의 VPC가 포함되어 있으며 다양한 Hive 컨트롤러가 존재하는 모든 VPC 목록을 포함할 수 있습니다.
1.5.4.4.2.2. VPC 끝점에 대한 보안 그룹 구성
AWS의 각 VPC 끝점에는 엔드포인트에 대한 액세스를 제어하는 보안 그룹이 연결되어 있습니다. Hive는 VPC 끝점을 생성할 때 보안 그룹을 지정하지 않습니다. VPC의 기본 보안 그룹은 VPC 끝점에 연결되어 있습니다. VPC의 기본 보안 그룹에는 Hive 설치 프로그램 Pod에서 VPC 끝점이 생성되는 트래픽을 허용하는 규칙이 있어야 합니다. 자세한 내용은 AWS 문서의 엔드 포인트 정책을 사용하여 VPC 끝점에 대한 액세스 제어를 참조하십시오.
예를 들어 Hive가 hive-vpc(10.1.0.0/16)
에서 실행중인 경우 10.1.0.0/16
의 수신을 허용하는 VPC 끝점이 생성되는 VPC의 기본 보안 그룹에 규칙이 있어야 합니다.
1.5.4.4.2.3. AWS PrivateLink에 대한 권한 설정
AWS PrivateLink를 구성하려면 여러 인증 정보가 필요합니다. 이러한 인증 정보에 필요한 권한은 인증 정보 유형에 따라 다릅니다.
ClusterDeployment의 인증 정보에는 다음과 같은 권한이 필요합니다.
ec2:CreateVpcEndpointServiceConfiguration ec2:DescribeVpcEndpointServiceConfigurations ec2:ModifyVpcEndpointServiceConfiguration ec2:DescribeVpcEndpointServicePermissions ec2:ModifyVpcEndpointServicePermissions ec2:DeleteVpcEndpointServiceConfigurations
끝점 VPC의 HiveConfig 계정
.spec.awsPrivateLink.credentialsSecretRef
의 인증 정보에는 다음과 같은 권한이 필요합니다.ec2:DescribeVpcEndpointServices ec2:DescribeVpcEndpoints ec2:CreateVpcEndpoint ec2:CreateTags ec2:DescribeNetworkInterfaces ec2:DescribeVPCs ec2:DeleteVpcEndpoints route53:CreateHostedZone route53:GetHostedZone route53:ListHostedZonesByVPC route53:AssociateVPCWithHostedZone route53:DisassociateVPCFromHostedZone route53:CreateVPCAssociationAuthorization route53:DeleteVPCAssociationAuthorization route53:ListResourceRecordSets route53:ChangeResourceRecordSets route53:DeleteHostedZone
VPC를 프라이빗 호스팅 영역과 연결하기 위해
HiveConfig
사용자 지정 리소스에 지정된 인증 정보(.spec.awsPrivateLink.associatedVPCs[$idx].credentialsSecretRef
). VPC가 있는 계정에는 다음과 같은 권한이 필요합니다.route53:AssociateVPCWithHostedZone route53:DisassociateVPCFromHostedZone ec2:DescribeVPCs
hub 클러스터의 Hive 네임스페이스에 인증 정보 시크릿이 있는지 확인합니다.
HiveConfig
사용자 지정 리소스는 특정 제공된 VPC에서 리소스를 생성할 수 있는 권한이 있는 Hive 네임스페이스 내의 인증 정보를 참조해야 합니다. AWS GovCloud에서 AWS 클러스터를 프로비저닝하는 데 사용 중인 인증 정보가 이미 Hive 네임스페이스에 있는 경우 다른 인증 정보를 생성할 필요가 없습니다. AWS GovCloud에서 AWS 클러스터를 프로비저닝하는 데 사용하는 인증 정보가 Hive 네임스페이스에 없는 경우 현재 인증 정보를 교체하거나 Hive 네임스페이스에 추가 인증 정보를 생성할 수 있습니다.
HiveConfig
사용자 지정 리소스에는 다음 콘텐츠를 포함해야 합니다.
- 지정된 VPC에 리소스를 프로비저닝하는 데 필요한 권한이 있는 AWS GovCloud 인증 정보입니다.
OpenShift Container Platform 클러스터 설치의 VPC 주소와 관리형 클러스터의 서비스 끝점입니다.
모범 사례: OpenShift Container Platform 클러스터 설치 및 서비스 끝점에 다른 VPC를 사용합니다.
다음 예제에서는 인증 정보 콘텐츠를 보여줍니다.
spec: awsPrivateLink: ## The list of inventory of VPCs that can be used to create VPC ## endpoints by the controller. endpointVPCInventory: - region: us-east-1 vpcID: vpc-1 subnets: - availabilityZone: us-east-1a subnetID: subnet-11 - availabilityZone: us-east-1b subnetID: subnet-12 - availabilityZone: us-east-1c subnetID: subnet-13 - availabilityZone: us-east-1d subnetID: subnet-14 - availabilityZone: us-east-1e subnetID: subnet-15 - availabilityZone: us-east-1f subnetID: subnet-16 - region: us-east-1 vpcID: vpc-2 subnets: - availabilityZone: us-east-1a subnetID: subnet-21 - availabilityZone: us-east-1b subnetID: subnet-22 - availabilityZone: us-east-1c subnetID: subnet-23 - availabilityZone: us-east-1d subnetID: subnet-24 - availabilityZone: us-east-1e subnetID: subnet-25 - availabilityZone: us-east-1f subnetID: subnet-26 ## The credentialsSecretRef points to a secret with permissions to create. ## The resources in the account where the inventory of VPCs exist. credentialsSecretRef: name: <hub-account-credentials-secret-name> ## A list of VPC where various mce clusters exists. associatedVPCs: - region: region-mce1 vpcID: vpc-mce1 credentialsSecretRef: name: <credentials-that-have-access-to-account-where-MCE1-VPC-exists> - region: region-mce2 vpcID: vpc-mce2 credentialsSecretRef: name: <credentials-that-have-access-to-account-where-MCE2-VPC-exists>
AWS PrivateLink가 endpointVPCECDHE 목록에서 지원되는 모든 리전의 VPC
를 포함할 수 있습니다. 컨트롤러는 ClusterDeployment의 요구사항을 충족하는 VPC를 선택합니다.
자세한 내용은 Hive 문서를 참조하십시오.
1.5.4.4.3. 콘솔을 사용하여 클러스터 생성
콘솔에서 클러스터를 생성하려면 Infrastructure > Clusters > Create cluster AWS > Standalone 으로 이동하여 콘솔의 단계를 완료합니다.
참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계를 위해 대상 관리 클러스터 가져오기를 hub 클러스터로 참조하십시오.
선택한 인증 정보가 AWS GovCloud 클러스터를 생성하는 경우 AWS GovCloud 리전의 리소스에 액세스할 수 있어야 합니다. 클러스터를 배포하는 데 필요한 권한이 있는 경우 Hive 네임스페이스에 이미 있는 AWS GovCloud 보안을 사용할 수 있습니다. 기존 인증 정보가 콘솔에 표시됩니다. 인증 정보를 생성해야 하는 경우 자세한 내용은 Amazon Web Services의 인증 정보 생성을 참조하십시오.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
AWS 또는 AWS GovCloud 계정으로 구성한 선택한 인증 정보에 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어쓰는 방식으로 변경할 수 있습니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다. 자세한 내용은 AWS 계정 구성을 참조하십시오.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동의 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.
-
region: 클러스터 리소스를 생성하는 리전입니다. AWS GovCloud 공급자에 클러스터를 생성하는 경우 노드 풀의 AWS GovCloud 리전을 포함해야 합니다. 예를 들어
us-gov-west-1
입니다. - CPU 아키텍처: 관리형 클러스터의 아키텍처 유형이 hub 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 머신의 명령어 집합 아키텍처의 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x, cover 64 입니다.
- zones: 컨트롤 플레인 풀을 실행할 위치를 지정합니다. 더 분산된 컨트롤 플레인 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 떨어져 있는 영역이 더 분산될 수 있습니다.
- 인스턴스 유형: 이전에 표시된 CPU 아키텍처 와 동일해야 하는 컨트롤 플레인 노드의 인스턴스 유형을 지정합니다. 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
- 루트 스토리지: 클러스터에 할당할 루트 스토리지의 양을 지정합니다.
작업자 풀에 0개 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 작업자 노드가 0개 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 선택적 정보에는 다음 필드가 포함됩니다.
- 풀 이름: 풀의 고유한 이름을 입력합니다.
- zones: 작업자 풀을 실행할 위치를 지정합니다. 더 분산된 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 떨어져 있는 영역이 더 분산될 수 있습니다.
- 인스턴스 유형: 작업자 풀의 인스턴스 유형을 지정합니다. 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
- 노드 수: 작업자 풀의 노드 수를 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
- 루트 스토리지: 작업자 풀에 할당된 루트 스토리지의 양을 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
클러스터에 네트워킹 세부 정보가 필요하며 IPv6를 사용하는 데 여러 네트워크가 필요합니다. AWS GovCloud 클러스터의 경우 Machine CIDR 필드에 Hive VPC의 주소 블록 값을 입력합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.
인증 정보에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL을 지정합니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL을 지정합니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 도메인이 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
AWS GovCloud 클러스터를 생성하거나 프라이빗 환경을 사용할 때 AMI ID 및 서브넷 값을 사용하여 AWS 개인 구성 페이지에서 필드를 완료합니다. 개인 구성 사용을 선택할 때 자동으로 설정된 ClusterDeployment.yaml
파일에서 spec:platform:aws:private
Link:enabled 값이 true
로 설정되어 있는지 확인합니다.
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML: On 을 선택하여 패널에서 install-config.yaml
파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 oc
명령을 실행할 필요가 없습니다. 클러스터를 생성하면 Kubernetes Operator용 다중 클러스터 엔진 관리에서 자동으로 구성됩니다.
1.5.4.5. Microsoft Azure에서 클러스터 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 Microsoft Azure 또는 Microsoft Azure Government에 Red Hat OpenShift Container Platform 클러스터를 배포할 수 있습니다.
클러스터를 생성할 때 생성 프로세스는 Hive 리소스와 함께 OpenShift Container Platform 설치 프로그램을 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서의 Azure 에 설치를 참조하십시오.
1.5.4.5.1. 사전 요구 사항
Azure에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- 배포된 허브 클러스터가 있어야 합니다.
- Azure 인증 정보가 필요합니다. 자세한 내용은 Microsoft Azure에 대한 인증 정보 생성을 참조하십시오.
- Azure 또는 Azure Government에 구성된 도메인이 필요합니다. 도메인 구성 방법에 대한 지침은 Azure 클라우드 서비스의 사용자 정의 도메인 이름 구성을 참조하십시오.
- 사용자 이름과 암호를 포함하는 Azure 로그인 자격 증명이 필요합니다. Microsoft Azure 포털 을 참조하십시오.
-
clientId
,clientSecret
,tenantId
를 포함하는 Azure 서비스 주체가 필요합니다. azure.microsoft.com 을 참조하십시오. - OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.
참고: 클라우드 공급자에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 클라우드 공급자의 해당 인증 정보를 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리형 클러스터를 삭제하려고 할 때 필요합니다.
1.5.4.5.2. 콘솔을 사용하여 클러스터 생성
멀티 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 인프라 > ; 클러스터로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.
참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계를 위해 대상 관리 클러스터 가져오기를 hub 클러스터로 참조하십시오.
자세한 내용은 Microsoft Azure에 대한 인증 정보 생성을 참조하십시오.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
Azure 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 필드에 채워집니다. 값을 덮어쓰는 방식으로 변경할 수 있습니다. 자세한 내용은 Azure 클라우드 서비스의 사용자 정의 도메인 이름 구성을 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동의 관리를 공유합니다. 정보에는 다음과 같은 선택적 필드가 포함됩니다.
- region: 노드 풀을 실행할 리전을 지정합니다. 더 분산된 컨트롤 플레인 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 떨어져 있는 영역이 더 분산될 수 있습니다.
- CPU 아키텍처: 관리형 클러스터의 아키텍처 유형이 hub 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 머신의 명령어 집합 아키텍처의 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x, cover 64 입니다.
클러스터를 생성한 후 인스턴스 유형 및 루트 스토리지 할당(필수)의 유형과 크기를 변경할 수 있습니다.
작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 작업자 노드가 0개 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.
- zones: 작업자 풀을 실행할 여기에 지정합니다. 더 분산된 노드 그룹에 대해 리전 내에서 여러 영역을 선택할 수 있습니다. 더 가까운 영역은 더 빠른 성능을 제공할 수 있지만 더 멀리 떨어져 있는 영역이 더 분산될 수 있습니다.
- 인스턴스 유형: 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 네트워크가 두 개 이상 있어야 합니다.
인증 정보에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
no proxy: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML 스위치를 클릭하여 패널에서 install-config.yaml
파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 oc
명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator의 관리 아래에 자동으로 구성됩니다.
1.5.4.6. Google Cloud Platform에서 클러스터 생성
GCP(Google Cloud Platform)에서 Red Hat OpenShift Container Platform 클러스터를 생성하는 절차를 따르십시오. GCP에 대한 자세한 내용은 Google Cloud Platform 을 참조하십시오.
클러스터를 생성할 때 생성 프로세스는 Hive 리소스와 함께 OpenShift Container Platform 설치 프로그램을 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서의 GCP 에 설치를 참조하십시오.
1.5.4.6.1. 사전 요구 사항
GCP에 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- 배포된 허브 클러스터가 있어야 합니다.
- GCP 인증 정보가 있어야 합니다. 자세한 내용은 Google Cloud Platform에 대한 인증 정보 생성을 참조하십시오.
- GCP에 구성된 도메인이 있어야 합니다. 도메인 구성 방법에 대한 지침은 사용자 정의 도메인 설정을 참조하십시오.
- 사용자 이름과 암호를 포함하는 GCP 로그인 인증 정보가 필요합니다.
- OpenShift Container Platform 이미지 풀 시크릿이 있어야 합니다. 이미지 풀 시크릿 사용을 참조하십시오.
참고: 클라우드 공급자에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 클라우드 공급자의 해당 인증 정보를 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리형 클러스터를 삭제하려고 할 때 필요합니다.
1.5.4.6.2. 콘솔을 사용하여 클러스터 생성
멀티 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 인프라 > ; 클러스터로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.
참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계를 위해 대상 관리 클러스터 가져오기를 hub 클러스터로 참조하십시오.
인증 정보를 생성해야 하는 경우 자세한 내용은 Google Cloud Platform의 인증 정보 생성을 참조하십시오.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다. GCP 클러스터 이름 지정에 적용되는 몇 가지 제한 사항이 있습니다. 이러한 제한에는 goog
으로 이름을 시작하지 않거나 이름의 모든 위치에서 Google
과 유사한 문자 및 숫자 그룹을 포함하지 않습니다. 전체 제한 목록은 Bucket 이름 지정 지침을 참조하십시오.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
GCP 계정에 대해 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어쓰는 방식으로 변경할 수 있습니다. 자세한 내용은 사용자 정의 도메인 설정을 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동의 관리를 공유합니다. 정보에는 다음 필드가 포함됩니다.
- region: 컨트롤 플레인 풀을 실행할 리전을 지정합니다. 더 가까운 지역이 더 빠른 성능을 제공할 수 있지만 더 멀리 있는 영역이 더 분산될 수 있습니다.
- CPU 아키텍처: 관리형 클러스터의 아키텍처 유형이 hub 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 머신의 명령어 집합 아키텍처의 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x, cover 64 입니다.
컨트롤 플레인 풀의 인스턴스 유형을 지정할 수 있습니다. 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 작업자 노드가 0개 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.
- 인스턴스 유형: 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
- 노드 수: 이 설정은 작업자 풀을 정의할 때 필요합니다.
네트워킹 세부 정보가 필요하며 IPv6 주소를 사용하는 데 여러 네트워크가 필요합니다. 네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다.
인증 정보에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 사이트 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML: On 을 선택하여 패널에서 install-config.yaml
파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 oc
명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator의 관리 아래에 자동으로 구성됩니다.
1.5.4.7. VMware vSphere에서 클러스터 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 VMware vSphere에 Red Hat OpenShift Container Platform 클러스터를 배포할 수 있습니다.
클러스터를 생성할 때 생성 프로세스는 Hive 리소스와 함께 OpenShift Container Platform 설치 프로그램을 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서의 vSphere 에 설치를 참조하십시오.
1.5.4.7.1. 사전 요구 사항
vSphere에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- OpenShift Container Platform 버전 4.6 이상에 배포된 허브 클러스터가 있어야 합니다.
- vSphere 인증 정보가 필요합니다. 자세한 내용은 VMware vSphere에 대한 인증 정보 생성을 참조하십시오.
- OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.
배포 중인 VMware 인스턴스에 대해 다음 정보가 있어야 합니다.
- API 및 Ingress 인스턴스에 필요한 고정 IP 주소
다음을 위한 DNS 레코드
-
api.<cluster_name>.<base_domain
>은 정적 API VIP를 가리켜야 합니다. -
*.apps.<cluster_name>.<base_domain
>은 Ingress VIP의 고정 IP 주소를 가리켜야 합니다.
-
1.5.4.7.2. 콘솔을 사용하여 클러스터 생성
멀티 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 인프라 > ; 클러스터로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.
참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계를 위해 대상 관리 클러스터 가져오기를 hub 클러스터로 참조하십시오.
인증 정보를 생성해야 하는 경우 인증 정보 생성에 대한 자세한 내용은 VMware vSphere 의 인증 정보 생성을 참조하십시오.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
vSphere 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어쓰는 방식으로 변경할 수 있습니다. 자세한 내용은 사용자 지정으로 vSphere에 클러스터 설치를 참조하십시오. 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 만드는 데 사용한 이름과 일치해야 합니다. 이 이름은 클러스터의 호스트 이름에 사용됩니다.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
참고: OpenShift Container Platform 버전 4.5.x 이상의 릴리스 이미지만 지원됩니다.
노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동의 관리를 공유합니다. 정보에는 CPU 아키텍처 필드가 포함됩니다. 다음 필드 설명을 확인합니다.
- CPU 아키텍처: 관리형 클러스터의 아키텍처 유형이 hub 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 머신의 명령어 집합 아키텍처의 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x, cover 64 입니다.
작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 작업자 노드가 0개 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 이 정보에는 소켓당 코어,CPU,Memory_min MiB, _Disk 크기 (GiB) 및 노드 수가 포함됩니다.
네트워킹 정보가 필요합니다. IPv6를 사용하려면 여러 네트워크가 필요합니다. 필수 네트워킹 정보 중 일부는 다음 필드를 포함합니다.
- vSphere 네트워크 이름: VMware vSphere 네트워크 이름을 지정합니다.
API VIP: 내부 API 통신에 사용할 IP 주소를 지정합니다.
참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 만드는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우
api.
가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.Ingress VIP: 인그레스 트래픽에 사용할 IP 주소를 지정합니다.
참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 만드는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우
test.apps
가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.
네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 네트워크가 두 개 이상 있어야 합니다.
인증 정보에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시:
HTTP
트래픽의 프록시로 사용해야 하는 URL을 지정합니다. -
HTTPS 프록시:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL을 지정합니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 사이트 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록을 제공합니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
설치 분리를 클릭하여 연결 해제된 설치 이미지를 정의할 수 있습니다. Red Hat OpenStack Platform 공급자와 연결이 끊긴 설치를 사용하여 클러스터를 생성할 때 인증서가 미러 레지스트리에 액세스해야 하는 경우 클러스터를 생성할 때 인증 정보 또는 연결되지 않은 설치 섹션에 대한 구성 섹션의 추가 신뢰 번들 필드에 입력해야 합니다.
자동화 템플릿 추가를 클릭하여 템플릿을 생성할 수 있습니다.
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML 스위치를 클릭하여 패널에서 install-config.yaml
파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 oc
명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator의 관리 아래에 자동으로 구성됩니다.
1.5.4.8. Red Hat OpenStack Platform에서 클러스터 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenStack Platform에 Red Hat OpenShift Container Platform 클러스터를 배포할 수 있습니다.
클러스터를 생성할 때 생성 프로세스는 Hive 리소스와 함께 OpenShift Container Platform 설치 프로그램을 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서의 OpenStack 에 설치를 참조하십시오.
1.5.4.8.1. 사전 요구 사항
Red Hat OpenStack Platform에서 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- OpenShift Container Platform 버전 4.6 이상에 배포된 허브 클러스터가 있어야 합니다.
- Red Hat OpenStack Platform 인증 정보가 있어야 합니다. 자세한 내용은 Red Hat OpenStack Platform의 인증 정보 생성을 참조하십시오.
- OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.
배포 중인 Red Hat OpenStack Platform 인스턴스에 대해 다음 정보가 필요합니다.
-
컨트롤 플레인 및 작업자 인스턴스의 플레이버 이름입니다(예:
m1.xlarge
). - 유동 IP 주소를 제공하는 외부 네트워크의 네트워크 이름
- API 및 Ingress 인스턴스에 필요한 부동 IP 주소
다음을 위한 DNS 레코드
-
api.<cluster_name>.<base_domain
> .이는 API의 부동 IP 주소를 가리켜야 합니다. -
*.apps.<cluster_name>.<base_domain
> , 수신의 부동 IP 주소를 가리켜야 합니다.
-
-
컨트롤 플레인 및 작업자 인스턴스의 플레이버 이름입니다(예:
1.5.4.8.2. 콘솔을 사용하여 클러스터 생성
멀티 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 인프라 > ; 클러스터로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.
참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계를 위해 대상 관리 클러스터 가져오기를 hub 클러스터로 참조하십시오.
인증 정보를 생성해야 하는 경우 자세한 내용은 Red Hat OpenStack Platform의 인증 정보 생성을 참조하십시오.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다. 이름에는 15자 미만이 포함되어야 합니다. 이 값은 자격 증명 사전 요구 사항 섹션에 나열된 DNS 레코드를 생성하는 데 사용한 이름과 일치해야 합니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
Red Hat OpenStack Platform 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 값이 필드에 채워집니다. 값을 덮어쓰는 방식으로 변경할 수 있습니다. 자세한 내용은 Red Hat OpenStack Platform 설명서의 도메인 관리를 참조하십시오. 이 이름은 클러스터의 호스트 이름에 사용됩니다.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오. OpenShift Container Platform 버전 4.6.x 이상의 릴리스 이미지만 지원됩니다.
노드 풀에는 컨트롤 플레인 풀과 작업자 풀이 포함됩니다. 컨트롤 플레인 노드는 클러스터 활동의 관리를 공유합니다. 관리형 클러스터의 아키텍처 유형이 hub 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 머신의 명령어 집합 아키텍처 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x, cover 64 입니다.
컨트롤 플레인 풀에 인스턴스 유형을 추가해야 하지만 인스턴스 생성 후 인스턴스 유형과 크기를 변경할 수 있습니다.
작업자 풀에서 하나 이상의 작업자 노드를 생성하여 클러스터의 컨테이너 워크로드를 실행할 수 있습니다. 단일 작업자 풀에 있거나 여러 작업자 풀에 배포할 수 있습니다. 작업자 노드가 0개 지정되면 컨트롤 플레인 노드도 작업자 노드로 작동합니다. 정보에는 다음 필드가 포함됩니다.
- 인스턴스 유형: 인스턴스 생성 후 인스턴스의 유형과 크기를 변경할 수 있습니다.
- 노드 수: 작업자 풀의 노드 수를 지정합니다. 이 설정은 작업자 풀을 정의할 때 필요합니다.
클러스터에 대한 네트워킹 세부 정보가 필요합니다. IPv4 네트워크의 하나 이상의 네트워크에 대한 값을 제공해야 합니다. IPv6 네트워크의 경우 둘 이상의 네트워크를 정의해야 합니다.
네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 네트워크가 두 개 이상 있어야 합니다.
인증 정보에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시:
HTTP
트래픽의 프록시로 사용해야 하는 URL을 지정합니다. -
HTTPS 프록시:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시
와 동일한 값이 사용됩니다. -
프록시 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록을 정의합니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
설치 분리를 클릭하여 연결 해제된 설치 이미지를 정의할 수 있습니다. Red Hat OpenStack Platform 공급자와 연결이 끊긴 설치를 사용하여 클러스터를 생성할 때 인증서가 미러 레지스트리에 액세스해야 하는 경우 클러스터를 생성할 때 인증 정보 또는 연결되지 않은 설치 섹션에 대한 구성 섹션의 추가 신뢰 번들 필드에 입력해야 합니다.
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML 스위치를 클릭하여 패널에서 install-config.yaml
파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
내부 CA(인증 기관)를 사용하는 클러스터를 생성할 때 다음 단계를 완료하여 클러스터의 YAML 파일을 사용자 지정해야 합니다.
검토 단계에서 YAML 스위치를 사용하여 CA 인증서 번들이 있는 목록의 상단에
Secret
오브젝트를 삽입합니다. 참고: Red Hat OpenStack Platform 환경에서 여러 기관에서 서명한 인증서를 사용하여 서비스를 제공하는 경우 필요한 모든 끝점을 검증하기 위해 번들에 인증서가 포함되어야 합니다.ocp3
이라는 클러스터 추가는 다음 예와 유사합니다.apiVersion: v1 kind: Secret type: Opaque metadata: name: ocp3-openstack-trust namespace: ocp3 stringData: ca.crt: | -----BEGIN CERTIFICATE----- <Base64 certificate contents here> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <Base64 certificate contents here> -----END CERTIFICATE----
다음 예와 유사하게
spec.platform.openstack
에서certificatesSecretRef
값을 지정하도록 HiveClusterDeployment
오브젝트를 수정합니다.platform: openstack: certificatesSecretRef: name: ocp3-openstack-trust credentialsSecretRef: name: ocp3-openstack-creds cloud: openstack
이전 예에서는
clouds.yaml
파일의 클라우드 이름이openstack
이라고 가정합니다.
참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 oc
명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator의 관리 아래에 자동으로 구성됩니다.
1.5.4.9. Red Hat Virtualization에서 클러스터 생성
다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat Virtualization에 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다.
클러스터를 생성할 때 생성 프로세스는 Hive 리소스와 함께 OpenShift Container Platform 설치 프로그램을 사용합니다. 이 절차를 완료한 후 클러스터 생성에 대한 질문이 있는 경우 프로세스에 대한 자세한 내용은 OpenShift Container Platform 설명서의 RHV 에 설치를 참조하십시오.
1.5.4.9.1. 사전 요구 사항
Red Hat Virtualization에 클러스터를 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- 배포된 허브 클러스터가 있어야 합니다.
- Red Hat Virtualization 인증 정보가 필요합니다. 자세한 내용은 Red Hat Virtualization에 대한 인증 정보 생성을 참조하십시오.
- oVirt Engine 가상 머신에 대해 구성된 도메인 및 가상 머신 프록시가 필요합니다. 도메인 구성 방법에 대한 자세한 내용은 Red Hat OpenShift Container Platform 설명서의 RHV 에 설치를 참조하십시오.
- Red Hat 고객 포털 사용자 이름 및 암호를 포함하는 Red Hat Virtualization 로그인 자격 증명이 있어야 합니다.
- OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 풀 시크릿은 Pull secret 에서 다운로드할 수 있습니다. 가져오기 보안에 대한 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
참고: 클라우드 공급자에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 클라우드 공급자의 해당 인증 정보를 수동으로 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리형 클러스터를 삭제하려고 할 때 필요합니다.
1.5.4.9.2. 콘솔을 사용하여 클러스터 생성
멀티 클러스터 엔진 Operator 콘솔에서 클러스터를 생성하려면 인프라 > ; 클러스터로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.
참고: 이 절차는 클러스터를 생성하기 위한 것입니다. 가져올 기존 클러스터가 있는 경우 해당 단계를 위해 대상 관리 클러스터 가져오기를 hub 클러스터로 참조하십시오.
인증 정보를 생성해야 하는 경우 자세한 내용은 Red Hat Virtualization에 대한 인증 정보 생성을 참조하십시오.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
Red Hat Virtualization 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 필드에 채워집니다. 값을 덮어쓰고 변경할 수 있습니다.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
노드 풀 정보에는 컨트롤 플레인 풀의 코어, 소켓, 메모리 및 디스크 크기가 포함됩니다. 세 개의 컨트롤 플레인 노드는 클러스터 활동 관리를 공유합니다. 정보에는 아키텍처 필드가 포함됩니다. 다음 필드 설명을 확인합니다.
- CPU 아키텍처: 관리형 클러스터의 아키텍처 유형이 hub 클러스터의 아키텍처와 동일하지 않은 경우 풀에 있는 머신의 명령어 집합 아키텍처의 값을 입력합니다. 유효한 값은 amd64,ppc64le,s390x, cover 64 입니다.
작업자 풀 정보에는 작업자 풀의 풀 이름, 코어 수, 메모리 할당, 디스크 크기 할당 및 노드 수가 필요합니다. 작업자 풀 내의 작업자 노드는 단일 작업자 풀에 있거나 여러 작업자 풀에 분산될 수 있습니다.
사전 구성된 oVirt 환경에서 다음 네트워킹 세부 정보가 필요합니다.
- ovirt 네트워크 이름
- vNIC 프로필 ID: 가상 네트워크 인터페이스 카드 프로필 ID를 지정합니다.
API VIP: 내부 API 통신에 사용할 IP 주소를 지정합니다.
참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 만드는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우
api.
가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.Ingress VIP: 인그레스 트래픽에 사용할 IP 주소를 지정합니다.
참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 만드는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우
test.apps
가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.-
네트워크 유형: 기본값은
OpenShiftSDN
입니다. OVNKubernetes는 IPv6 사용에 필요한 설정입니다. -
클러스터 네트워크 CIDR: Pod IP 주소에 사용할 수 있는 IP 주소 수 및 목록입니다. 이 블록은 다른 네트워크 블록을 겹치지 않아야 합니다. 기본값은
10.128.0.0/14
입니다. -
네트워크 호스트 접두사: 각 노드의 서브넷 접두사 길이를 설정합니다. 기본값은
23
입니다. -
서비스 네트워크 CIDR: 서비스의 IP 주소 블록을 제공합니다. 이 블록은 다른 네트워크 블록을 겹치지 않아야 합니다. 기본값은
172.30.0.0/16
입니다. Machine CIDR: OpenShift Container Platform 호스트에서 사용하는 IP 주소 블록을 제공합니다. 이 블록은 다른 네트워크 블록을 겹치지 않아야 합니다. 기본값은
10.0.0.0/16
입니다.네트워크 추가를 클릭하여 추가 네트워크를 추가할 수 있습니다. IPv6 주소를 사용하는 경우 네트워크가 두 개 이상 있어야 합니다.
인증 정보에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 정보를 그대로 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시:
HTTP
트래픽의 프록시로 사용해야 하는 URL을 지정합니다. -
HTTPS 프록시:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL을 지정합니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 사이트 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 사이트 목록을 제공합니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서 하나 이상
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML 스위치를 클릭하여 패널에서 install-config.yaml
파일 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
참고: 클러스터를 가져오기 위해 클러스터 세부 정보와 함께 제공된 oc
명령을 실행할 필요가 없습니다. 클러스터를 생성할 때 다중 클러스터 엔진 Operator의 관리 아래에 자동으로 구성됩니다.
1.5.4.10. 온-프레미스 환경에서 클러스터 생성
콘솔을 사용하여 온프레미스 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다.
단일 노드 OpenShift(SNO) 클러스터를 생성하는 데 이 절차를 사용하는 것이 좋습니다. VMware vSphere, Red Hat OpenStack, Red Hat Virtualization Platform 및 베어 메탈 환경에서 단일 노드 OpenShift 클러스터를 생성할 수 있습니다. 플랫폼 값이 platform=none
으로 설정되어 있으므로 클러스터를 설치하는 플랫폼과의 통합은 없습니다. 단일 노드 OpenShift 클러스터에는 컨트롤 플레인 서비스와 사용자 워크로드를 호스팅하는 단일 노드만 포함되어 있습니다. 이 구성은 클러스터의 리소스 풋프린트를 최소화하려는 경우 유용할 수 있습니다.
또한 Red Hat OpenShift Container Platform에서 사용할 수 있는 기술 프리뷰 기능인 제로 태그 프로비저닝 기능을 사용하여 엣지 리소스에 여러 단일 노드 OpenShift 클러스터를 프로비저닝하는 절차를 테스트할 수도 있습니다. 해당 절차에 대한 자세한 내용은 OpenShift Container Platform 설명서의 연결이 끊긴 환경에서 대규모로 분산 장치 배포를 참조하십시오.
1.5.4.10.1. 사전 요구 사항
온-프레미스 환경에서 클러스터를 만들기 전에 다음 사전 요구 사항을 참조하십시오.
- OpenShift Container Platform 버전 4.9 이상에 배포된 허브 클러스터가 있어야 합니다.
- 구성된 호스트의 호스트 인벤토리가 있는 구성된 인프라 환경이 필요합니다.
- hub 클러스터(연결)에 대한 인터넷 액세스 또는 클러스터를 생성하는 데 필요한 이미지를 검색하려면 인터넷에 연결되어 있지 않은 내부 또는 미러 레지스트리에 대한 연결이 있어야 합니다.
- 구성된 온-프레미스 인증 정보가 필요합니다.
- OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
1.5.4.10.2. 콘솔을 사용하여 클러스터 생성
콘솔에서 클러스터를 생성하려면 인프라 > ; 클러스터로 이동합니다. 클러스터 페이지에서 클러스터 생성을 클릭하고 콘솔의 단계를 완료합니다.
- 클러스터 유형으로 호스트 인벤토리 를 선택합니다.
지원되는 설치에 다음 옵션을 사용할 수 있습니다.
- 기존 검색된 호스트 사용: 기존 호스트 인벤토리에 있는 호스트 목록에서 호스트를 선택합니다.
- 새 호스트 검색: 기존 인프라 환경에 아직 없는 호스트를 검색합니다. 인프라 환경에 이미 있는 호스트를 사용하지 않고 자체 호스트를 검색합니다.
자세한 내용은 온-프레미스 환경에 대한 자격 증명 만들기를 참조하십시오.If you need to create a credential, see Creating a credential for an on-premises environment for more information.
클러스터의 이름은 클러스터의 호스트 이름에 사용됩니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
tips: 콘솔의 정보를 입력할 때 콘텐츠 업데이트를 보려면 YAML: on 을 선택합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공하기 위해 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
공급자 계정에 대해 구성한 선택한 인증 정보와 연결된 기본 DNS 도메인이 이미 있는 경우 해당 필드에 채워집니다. 값을 수정하여 변경할 수 있지만 이 설정은 클러스터를 생성한 후에는 변경할 수 없습니다. 공급자의 기본 도메인은 Red Hat OpenShift Container Platform 클러스터 구성 요소에 대한 경로를 생성하는 데 사용됩니다. 클러스터 공급자의 DNS에서 SOA(Start of Authority) 레코드로 구성됩니다.
OpenShift 버전 은 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 사용하려는 버전이 사용 가능한 경우 이미지 목록에서 이미지를 선택할 수 있습니다. 사용하려는 이미지가 표준 이미지가 아닌 경우 사용하려는 이미지에 URL을 입력할 수 있습니다. 릴리스 이미지에 대한 자세한 내용은 릴리스 이미지를 참조하십시오.
4.9 이상 OpenShift 버전을 선택하면 Install single node OpenShift (SNO) 를 선택하는 옵션이 표시됩니다. 단일 노드 OpenShift 클러스터에는 컨트롤 플레인 서비스와 사용자 워크로드를 호스팅하는 단일 노드가 포함되어 있습니다. 생성된 후에는 단일 노드 OpenShift 클러스터에 노드를 추가할 수 없습니다.
클러스터가 단일 노드 OpenShift 클러스터가 되도록 하려면 단일 노드 OpenShift 옵션을 선택합니다. 다음 단계를 완료하여 단일 노드 OpenShift 클러스터에 추가 작업자를 추가할 수 있습니다.
- 콘솔에서 Infrastructure > Clusters 로 이동하여 생성하거나 액세스하려는 클러스터 이름을 선택합니다.
- 작업 > 호스트 추가를 선택하여 작업자를 추가합니다.
참고: 단일 노드 OpenShift 컨트롤 플레인에는 8개의 CPU 코어가 필요하지만 다중 노드 컨트롤 플레인 클러스터의 컨트롤 플레인 노드에는 4개의 CPU 코어만 필요합니다.
클러스터를 검토하고 저장하면 클러스터가 초안 클러스터로 저장됩니다. 클러스터 페이지에서 클러스터 이름을 선택하여 생성 프로세스를 종료하고 나중에 프로세스를 완료할 수 있습니다.
기존 호스트를 사용하는 경우 호스트를 직접 선택할지 또는 호스트를 자동으로 선택할지 선택합니다. 호스트 수는 선택한 노드 수를 기반으로 합니다. 예를 들어 SNO 클러스터에는 하나의 호스트만 필요하지만 표준 3-노드 클러스터에는 3개의 호스트가 필요합니다.
이 클러스터의 요구 사항을 충족하는 사용 가능한 호스트의 위치는 호스트 위치 목록에 표시됩니다. 호스트 배포 및 고가용성 구성의 경우 여러 위치를 선택합니다.
기존 인프라 환경 없이 새 호스트를 검색하는 경우 4단계로 시작하여 호스트를 정의하는 인프라 환경으로 호스트 확장 단계를 완료합니다.
호스트가 바인딩되고 검증이 통과되면 다음 IP 주소를 추가하여 클러스터의 네트워킹 정보를 완료합니다.
API VIP: 내부 API 통신에 사용할 IP 주소를 지정합니다.
참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 만드는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우
api.
가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.Ingress VIP: Ingress 트래픽에 사용할 IP 주소를 지정합니다.
참고: 이 값은 사전 요구 사항 섹션에 나열된 DNS 레코드를 만드는 데 사용한 이름과 일치해야 합니다. 제공되지 않는 경우
test.apps
가 올바르게 확인되도록 DNS를 사전 구성해야 합니다.
클러스터 탐색 페이지에서 설치 상태를 볼 수 있습니다.
1.5.4.11. 생성된 클러스터 분리(기술 프리뷰)
멀티 클러스터 엔진 Operator를 사용하여 생성된 클러스터를 사용하여 리소스를 보존할 수 있습니다. 하이베이팅 클러스터에는 실행 중인 리소스보다 훨씬 적은 리소스가 필요하므로 하이베이팅 상태의 클러스터를 이동하거나 부족하여 공급자 비용을 절감할 수 있습니다. 이 기능은 다음 환경에서 다중 클러스터 엔진 Operator가 생성한 클러스터에만 적용됩니다.
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
1.5.4.11.1. 콘솔을 사용하여 클러스터의 iPXE
콘솔을 사용하여 다중 클러스터 엔진 Operator가 생성한 클러스터를 사용하려면 다음 단계를 완료하십시오.
- 탐색 메뉴에서 인프라 > 클러스터를 선택합니다. Manage clusters 탭이 선택되어 있는지 확인합니다.
- 클러스터 의 옵션 메뉴에서 iPXE 클러스터를 선택합니다. 참고: iPXE 클러스터 옵션을 사용할 수 없는 경우 클러스터를 사용할 수 없습니다. 이는 클러스터를 가져오고 다중 클러스터 엔진 Operator에서 생성하지 않는 경우 발생할 수 있습니다.
클러스터 페이지의 클러스터 상태는 프로세스가 완료되면 Hibernating
입니다.
팁: 클러스터 페이지에서 클러스터를 선택하고 Actions > iPXE 클러스터를 선택하여 여러 클러스터를 할 수 있습니다.
선택한 클러스터가 hibernating입니다.
1.5.4.11.2. CLI를 사용하여 클러스터 way
CLI를 사용하여 다중 클러스터 엔진 Operator가 생성한 클러스터를 사용하려면 다음 단계를 완료하십시오.
다음 명령을 입력하여 ECDHE할 클러스터의 설정을 편집합니다.
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
name-of-cluster
를 ECDHE 클러스터의 이름으로 바꿉니다.namespace-of-cluster
를 ECDHE 클러스터의 네임스페이스로 바꿉니다.-
spec.powerState
의 값을Hibernating
으로 변경합니다. 다음 명령을 입력하여 클러스터 상태를 확인합니다.
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
name-of-cluster
를 ECDHE 클러스터의 이름으로 바꿉니다.namespace-of-cluster
를 ECDHE 클러스터의 네임스페이스로 바꿉니다.클러스터를 분리하는 프로세스가 완료되면 클러스터 유형 값이
type=Hibernating
입니다.
선택한 클러스터가 hibernating입니다.
1.5.4.11.3. 콘솔을 사용하여 임시 클러스터의 정상적인 작업 재시작
콘솔을 사용하여 상위 클러스터의 정상적인 작동을 다시 시작하려면 다음 단계를 완료하십시오.
- 탐색 메뉴에서 인프라 > 클러스터를 선택합니다. Manage clusters 탭이 선택되어 있는지 확인합니다.
- 재개하려는 클러스터 의 옵션 메뉴에서 클러스터 다시 시작을 선택합니다.
프로세스가 완료되면 클러스터 페이지의 클러스터 상태가 Ready
입니다.
팁: 클러스터 페이지에서 재개할 클러스터를 선택하고 작업 > 클러스터 재시작을 선택하여 여러 클러스터를 다시 시작할 수 있습니다.
선택한 클러스터가 정상적인 작업을 다시 시작합니다.
1.5.4.11.4. CLI를 사용하여 상위 클러스터의 정상적인 작업 재시작
CLI를 사용하여 상위 클러스터의 정상적인 작동을 다시 시작하려면 다음 단계를 완료합니다.
다음 명령을 입력하여 클러스터의 설정을 편집합니다.
oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
name-of-cluster
를 ECDHE 클러스터의 이름으로 바꿉니다.namespace-of-cluster
를 ECDHE 클러스터의 네임스페이스로 바꿉니다.-
spec.powerState
의 값을Running
으로 변경합니다. 다음 명령을 입력하여 클러스터 상태를 확인합니다.
oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
name-of-cluster
를 ECDHE 클러스터의 이름으로 바꿉니다.namespace-of-cluster
를 ECDHE 클러스터의 네임스페이스로 바꿉니다.클러스터를 재시작하는 프로세스가 완료되면 클러스터 유형 값이
type=Running
입니다.
선택한 클러스터가 정상적인 작업을 다시 시작합니다.
1.5.4.12. 프록시 환경에서 클러스터 생성
프록시 서버를 통해 허브 클러스터가 연결된 경우 Red Hat OpenShift Container Platform 클러스터를 생성할 수 있습니다. 클러스터 생성에 성공하려면 다음 상황 중 하나가 true여야 합니다.
- 다중 클러스터 엔진 Operator에는 프록시를 사용하여 인터넷에 대한 관리형 클러스터 액세스가 있는 생성 중인 관리형 클러스터와의 프라이빗 네트워크 연결이 있습니다.
- 관리 클러스터는 인프라 공급자에 있지만 방화벽 포트는 관리 클러스터에서 허브 클러스터로 통신할 수 있습니다.
프록시로 구성된 클러스터를 생성하려면 다음 단계를 완료합니다.
Secret에 저장된
install-config
YAML에 다음 정보를 추가하여 hub 클러스터에서cluster-wide-proxy
설정을 구성합니다.apiVersion: v1 kind: Proxy baseDomain: <domain> proxy: httpProxy: http://<username>:<password>@<proxy.example.com>:<port> httpsProxy: https://<username>:<password>@<proxy.example.com>:<port> noProxy: <wildcard-of-domain>,<provisioning-network/CIDR>,<BMC-address-range/CIDR>
username
을 프록시 서버의 사용자 이름으로 바꿉니다.프록시 서버에 액세스하려면
password
를 암호로 바꿉니다.proxy.example.com
을 프록시 서버의 경로로 바꿉니다.포트를
프록시 서버와 통신 포트로 바꿉니다.wildcard-of-domain
을 프록시를 바이패스해야 하는 도메인의 항목으로 바꿉니다.CIDR 표기법에서
provisioning-network/CIDR
를 provisioning 네트워크의 IP 주소 및 할당된 IP 주소 수로 바꿉니다.CIDR 표기법에서
BMC-address-range/CIDR
를 BMC 주소 및 주소 수로 바꿉니다.이전 값을 추가한 후 설정이 클러스터에 적용됩니다.
- 클러스터 생성 절차를 완료하여 클러스터를 프로비저닝합니다. 공급자를 선택하려면 클러스터 생성을 참조하십시오.
1.5.5. 대상 관리 클러스터를 허브 클러스터로 가져오기
다른 Kubernetes 클라우드 공급자에서 클러스터를 가져올 수 있습니다. 가져온 후 대상 클러스터는 다중 클러스터 엔진 Operator 허브 클러스터의 관리 클러스터가 됩니다. 별도로 지정하지 않는 한 허브 클러스터 및 대상 관리 클러스터에 액세스할 수 있는 모든 위치에서 가져오기 작업을 완료합니다.
허브 클러스터는 다른 허브 클러스터를 관리할 수 없지만 자체적으로 관리할 수 있습니다. hub 클러스터는 자동으로 가져오고 자체 관리되도록 구성됩니다. hub 클러스터를 수동으로 가져올 필요가 없습니다.
그러나 hub 클러스터를 제거하고 다시 가져오려는 경우 ManagedCluster
리소스에 local-cluster:true
레이블을 추가해야 합니다.
콘솔 또는 CLI에서 관리되는 클러스터를 설정하려면 다음 지침에서 선택합니다.
필수 사용자 유형 또는 액세스 수준: 클러스터 관리자
1.5.5.1. 콘솔을 사용하여 관리형 클러스터 가져오기
Kubernetes Operator용 멀티 클러스터 엔진을 설치한 후 관리할 클러스터를 가져올 준비가 된 것입니다. 다음 주제를 계속 읽고 콘솔을 사용하여 관리되는 클러스터를 가져오는 방법을 알아봅니다. 이 절차 중에 인증을 위해 터미널이 필요합니다. CLI를 사용하여 관리형 클러스터를 가져오려면 CLI를 사용하여 관리형 클러스터 가져오기를 참조하십시오.
1.5.5.1.1. 사전 요구 사항
- 배포된 hub 클러스터입니다. 베어 메탈 클러스터를 가져오는 경우 Red Hat OpenShift Container Platform 버전 4.8 이상에 hub 클러스터를 설치해야 합니다.
- 관리할 클러스터입니다.
-
base64
명령줄 툴입니다. OpenShift Container Platform에서 생성되지 않은 클러스터를 가져오는 경우 정의된
multiclusterhub.spec.imagePullSecret
이 보안은 Kubernetes Operator의 다중 클러스터 엔진을 설치할 때 생성될 수 있습니다. 이 보안을 정의하는 방법에 대한 자세한 내용은 사용자 정의 이미지 가져오기 보안을 참조하십시오.새 시크릿을 생성해야 하는 경우 새 풀 시크릿 생성을참조하십시오.
필수 사용자 유형 또는 액세스 수준: 클러스터 관리자
1.5.5.1.2. 새 풀 시크릿 생성
새 풀 시크릿을 생성해야 하는 경우 다음 단계를 완료합니다.
- cloud.redhat.com 에서 Kubernetes 풀 시크릿을 다운로드합니다.
- hub 클러스터의 네임스페이스에 풀 시크릿을 추가합니다.
다음 명령을 실행하여
open-cluster-management
네임스페이스에 새 보안을 생성합니다.oc create secret generic pull-secret -n <open-cluster-management> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
open-cluster-management
를 hub 클러스터의 네임스페이스 이름으로 교체합니다. hub 클러스터의 기본 네임스페이스는open-cluster-management
입니다.다운로드한 풀 시크릿 경로로
path-to-pull-secret
을 교체합니다.시크릿을 가져오면 관리 클러스터에 자동으로 복사됩니다.
이 보안을 정의하는 방법에 대한 자세한 내용은 사용자 정의 이미지 가져오기 보안을 참조하십시오.
-
이전에 설치한 에이전트가 가져오려는 클러스터에서 삭제되었는지 확인합니다. 오류를 방지하려면
open-cluster-management-agent
및open-cluster-management-agent-addon
네임스페이스를 제거해야 합니다. Red Hat OpenShift Dedicated 환경에서 가져오려면 다음 정보를 참조하십시오.
- Red Hat OpenShift Dedicated 환경에 허브 클러스터가 배포되어 있어야 합니다.
-
Red Hat OpenShift Dedicated의 기본 권한은 dedicated-admin이지만 네임스페이스를 생성할 수 있는 권한은 모두 포함되어 있지 않습니다. 멀티 클러스터 엔진 Operator가 있는 클러스터를 가져오고 관리하려면
cluster-admin
권한이 있어야 합니다.
-
이전에 설치한 에이전트가 가져오려는 클러스터에서 삭제되었는지 확인합니다. 오류를 방지하려면
1.5.5.1.3. 클러스터 가져오기
사용 가능한 각 클라우드 공급자에 대해 콘솔에서 기존 클러스터를 가져올 수 있습니다.
참고: 허브 클러스터는 다른 허브 클러스터를 관리할 수 없습니다. hub 클러스터는 자동으로 가져오고 관리하도록 설정되어 있으므로 자체적으로 관리하기 위해 hub 클러스터를 수동으로 가져올 필요가 없습니다.
기본적으로 네임스페이스는 클러스터 이름과 네임스페이스에 사용되지만 변경할 수 있습니다.
중요: 클러스터를 생성할 때 컨트롤러는 클러스터 및 해당 리소스에 대한 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 클러스터는 기본
관리 클러스터 세트에 자동으로 추가됩니다.
다른 클러스터 세트에 클러스터를 추가하려면 클러스터 세트에 clusterset-admin
권한이 있어야 합니다. 클러스터를 가져올 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 가져오기에 실패합니다. 클러스터 관리자에게 문의하여 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 클러스터에 제공합니다.
OpenShift Container Platform Dedicated 클러스터를 가져오고 vendor=OpenShiftDedicated
레이블을 추가하여 공급 업체를 지정하지 않거나 vendor=auto-detect
에 대한 라벨을 추가하면 managed-by=platform
레이블이 클러스터에 자동으로 추가됩니다. 이 추가된 레이블을 사용하여 클러스터를 OpenShift Container Platform Dedicated 클러스터로 식별하고 그룹으로 OpenShift Container Platform Dedicated 클러스터를 검색할 수 있습니다.
다음 표에서는 클러스터를 가져오는 방법을 지정하는 가져오기 모드에 사용할 수 있는 옵션을 제공합니다.
수동으로 가져오기 명령 실행 | Red Hat Ansible Automation Platform 템플릿을 포함하여 콘솔에 정보를 작성하고 제출한 후 대상 클러스터에서 제공된 명령을 실행하여 클러스터를 가져옵니다. |
기존 클러스터의 서버 URL 및 API 토큰을 입력합니다. | 가져오는 클러스터의 서버 URL 및 API 토큰을 제공합니다. 클러스터가 업그레이드될 때 실행할 Red Hat Ansible Automation Platform 템플릿을 지정할 수 있습니다. |
|
가져올 클러스터의 |
참고: Ansible Automation Platform 작업을 생성하고 실행하려면 OperatorHub에서 Red Hat Ansible Automation Platform Resource Operator가 설치되어 있어야 합니다. 클러스터 API 주소를 구성하려면 선택 사항: 클러스터 API 주소 구성을참조하십시오.
1.5.5.1.3.1. 수동으로 가져오기 명령을 실행하기 위한 추가 단계
대상 클러스터에서 제공된 명령을 실행하여 클러스터를 가져옵니다.
클러스터 세부 정보 및 자동화 정보를 제출한 후 복사 명령을 선택하여 생성된 명령과 토큰을 클립보드에 복사합니다.
중요: 이 명령에는 가져온 각 클러스터에 복사되는 풀 시크릿 정보가 포함되어 있습니다. 가져온 클러스터에 액세스할 수 있는 모든 사용자는 풀 시크릿 정보도 볼 수 있습니다. https://cloud.redhat.com/ 에서 보조 풀 시크릿을 생성하거나 서비스 계정을 생성하여 개인 인증 정보를 보호하는 것이 좋습니다.
- 가져오려는 관리형 클러스터에 로그인합니다.
OpenShift Container Platform Dedicated 환경의 경우에만 다음 단계를 완료합니다(OpenShift Container Platform Dedicated environnet을 사용하지 않는 경우 3 단계로 건너뜁니다).
-
관리 클러스터에서
open-cluster-management-agent
및open-cluster-management
네임스페이스 또는 프로젝트를 생성합니다. - OpenShift Container Platform 카탈로그에서 klusterlet Operator를 찾습니다.
생성한
open-cluster-management
네임스페이스 또는 프로젝트에 설치합니다.중요:
open-cluster-management-agent
네임스페이스에 Operator를 설치하지 마십시오.다음 단계를 완료하여 가져오기 명령에서 부트스트랩 보안을 추출합니다.
가져오기 명령을 생성합니다.
- 콘솔 탐색에서 인프라 > 클러스터를 선택합니다.
- Add a cluster > Import an existing cluster 를 선택합니다.
- 클러스터 정보를 추가하고 Save import and generate code 를 선택합니다.
- 가져오기 명령을 복사합니다.
-
import-command
라는 파일에 가져오기 명령을 붙여넣습니다. 다음 명령을 실행하여 새 파일에 콘텐츠를 삽입합니다.
cat import-command | awk '{split($0,a,"&&"); print a[3]}' | awk '{split($0,a,"|"); print a[1]}' | sed -e "s/^ echo //" | base64 -d
-
출력에서
bootstrap-hub-kubeconfig
라는 이름으로 시크릿을 찾아서 복사합니다. -
관리 클러스터의
open-cluster-management-agent
네임스페이스에 보안을 적용합니다. 설치된 Operator의 예제를 사용하여 klusterlet 리소스를 생성합니다.
clusterName
값을 가져오기 중에 설정된 클러스터 이름과 동일한 이름으로 변경합니다.참고:
managedcluster
리소스가 허브에 성공적으로 등록되면 설치된 klusterlet Operator 두 개가 있습니다. 하나의 klusterlet Operator는open-cluster-management
네임스페이스에 있으며 다른 하나는open-cluster-management-agent
네임스페이스에 있습니다. 여러 Operator가 있으면 klusterlet의 기능에는 영향을 미치지 않습니다.
-
관리 클러스터에서
OpenShift Container Platform Dedicated 환경에 없는 클러스터 가져오기의 경우 다음 단계를 완료합니다.
-
필요한 경우 관리 클러스터에 대한
kubeconfig
파일을 구성합니다. -
open-cluster-management-agent-addon
을 관리형 클러스터에 배포하려면 복사한 명령과 토큰을 실행합니다.
-
필요한 경우 관리 클러스터에 대한
클러스터 보기 를 선택하여 개요 페이지에서 클러스터의 요약을 확인합니다.
클러스터의 클러스터 세부 정보 페이지에서 진행률을 가져올 수 있습니다.
클러스터 API 주소를 구성하려면 선택 사항의 단계를 계속 진행하십시오. 클러스터 API 주소 구성.
1.5.5.1.3.2. 선택사항: 클러스터 API 주소 구성
oc get managedcluster
명령을 실행할 때 표에 표시된 URL을 구성하여 클러스터 세부 정보 페이지에 있는 Cluster API 주소를 선택적으로 구성하려면 다음 단계를 완료합니다.
-
cluster-admin
권한이 있는 ID로 hub 클러스터에 로그인합니다. -
대상 관리 클러스터에 대한
kubeconfig
파일을 구성합니다. 다음 명령을 실행하여 가져오는 클러스터의 관리형 클러스터 항목을 편집합니다.
oc edit managedcluster <cluster-name>
cluster-name
을 관리형 클러스터의 이름으로 변경합니다.다음 예와 같이 YAML 파일의
ManagedCluster
ClientConfigsspec: hubAcceptsClient: true managedClusterClientConfigs: - url: <https://api.new-managed.dev.redhat.com>
가져올 관리형 클러스터에 대한 외부 액세스를 제공하는 URL로 URL 값을 바꿉니다.
1.5.5.1.4. 가져온 클러스터 제거
가져온 클러스터와 관리 클러스터에서 생성된 open-cluster-management-agent-addon
을 제거하려면 다음 절차를 완료합니다.
클러스터 페이지에서 Actions > Detach cluster 를 클릭하여 클러스터를 관리에서 제거합니다.
참고: local-cluster
라는 hub 클러스터를 분리하려고 하면 disableHubSelfManagement
의 기본 설정은 false
입니다. 이 설정을 사용하면 허브 클러스터가 분리될 때 자체적으로 다시 가져오고 자체적으로 관리되고 MultiClusterHub
컨트롤러를 조정합니다. 허브 클러스터가 분리 프로세스를 완료하고 다시 가져오는 데 시간이 걸릴 수 있습니다. 프로세스가 완료될 때까지 기다리지 않고 hub 클러스터를 다시 가져오려면 다음 명령을 실행하여 multiclusterhub-operator
Pod를 재시작하고 더 빨리 다시 가져올 수 있습니다.
oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`
disableHubSelfManagement
값을 true
로 변경하여 hub 클러스터의 값을 자동으로 가져오지 않도록 변경할 수 있습니다. 자세한 내용은 disableHubSelfManagement 주제를 참조하십시오.
1.5.5.2. CLI를 사용하여 관리 클러스터 가져오기
Kubernetes Operator용 멀티 클러스터 엔진을 설치한 후 Red Hat OpenShift Container Platform CLI를 사용하여 클러스터를 가져와서 관리할 수 있습니다. 다음 주제를 계속 읽고 자동 가져오기 보안을 사용하거나 수동 명령을 사용하여 CLI로 관리 클러스터를 가져오는 방법을 알아봅니다. 콘솔을 사용하여 관리형 클러스터를 가져오려면 콘솔 을 사용하여 관리형 클러스터 가져오기를 참조하십시오.
중요: 허브 클러스터는 다른 허브 클러스터를 관리할 수 없습니다. hub 클러스터는 자체적으로 자동으로 가져오고 관리하도록 설정되어 있습니다. 자체적으로 관리하기 위해 허브 클러스터를 수동으로 가져올 필요는 없습니다. hub 클러스터를 제거하고 다시 가져오려는 경우 local-cluster:true
레이블을 추가해야 합니다.
1.5.5.2.1. 사전 요구 사항
- 배포된 hub 클러스터입니다. 베어 메탈 클러스터를 가져오는 경우 OpenShift Container Platform 버전 4.6 이상에 hub 클러스터를 설치해야 합니다.
- 관리하려는 별도의 클러스터입니다.
-
OpenShift Container Platform CLI 버전 4.6 이상에서
oc
명령을 실행합니다. OpenShift Container Platform CLI 설치 및 구성에 대한 정보는 OpenShift CLI 시작하기 를 참조하십시오. -
OpenShift Container Platform에서 생성되지 않은 클러스터를 가져오는 경우 정의된
multiclusterhub.spec.imagePullSecret
이 보안은 Kubernetes Operator의 다중 클러스터 엔진을 설치할 때 생성될 수 있습니다. 이 보안을 정의하는 방법에 대한 자세한 내용은 사용자 정의 이미지 가져오기 보안을 참조하십시오.
1.5.5.2.2. 지원되는 아키텍처
- Linux (x86_64, s390x, ppc64le)
- macOS
1.5.5.2.3. 클러스터 가져오기 준비
CLI를 사용하여 관리형 클러스터를 가져오기 전에 다음 단계를 완료해야 합니다.
다음 명령을 실행하여 hub 클러스터에 로그인합니다.
oc login
hub 클러스터에서 다음 명령을 실행하여 프로젝트와 네임스페이스를 생성합니다. <
cluster_name&
gt;에 정의된 클러스터 이름도 YAML 파일 및 명령에서 클러스터 네임스페이스로 사용됩니다.oc new-project <cluster_name>
중요:
cluster.open-cluster-management.io/managedCluster
레이블이 관리형 클러스터 네임스페이스에 자동으로 추가 및 제거됩니다. 관리형 클러스터에서 수동으로 추가하거나 제거하지 마십시오.다음 예제 콘텐츠를 사용하여
managed-cluster.yaml
이라는 파일을 생성합니다.apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: <cluster_name> labels: cloud: auto-detect vendor: auto-detect spec: hubAcceptsClient: true
클라우드
및공급 업체
의 값이자동 감지
로 설정된 경우 Red Hat Advanced Cluster Management는 가져올 클러스터에서 클라우드 및 벤더 유형을 자동으로 탐지합니다.자동 감지
값을 클러스터의 클라우드 및 벤더 값으로 선택적으로 교체할 수 있습니다. 다음 예제를 참조하십시오.cloud: Amazon vendor: OpenShift
다음 명령을 실행하여
ManagedCluster
리소스에 YAML 파일을 적용합니다.oc apply -f managed-cluster.yaml
1.5.5.2.4. 자동 가져오기 보안을 사용하여 클러스터 가져오기
자동 가져오기 보안을 사용하여 관리형 클러스터를 가져오려면 클러스터의 kubeconfig
파일 또는 클러스터의 kube API 서버 및 토큰 쌍에 대한 참조가 포함된 시크릿을 생성해야 합니다. 자동 가져오기 보안을 사용하여 클러스터를 가져오려면 다음 단계를 완료합니다.
-
가져오려는 관리 클러스터의
kubeconfig
파일 또는 kube API 서버 및 토큰을 검색합니다.kubeconfig
파일 또는 kube API 서버 및 토큰을 찾을 위치를 알아보려면 Kubernetes 클러스터 설명서를 참조하십시오. ${CLUSTER_NAME} 네임스페이스에
auto-import-secret.yaml
파일을 생성합니다.다음 템플릿과 유사한 콘텐츠를 사용하여
auto-import-secret.yaml
이라는 YAML 파일을 생성합니다.apiVersion: v1 kind: Secret metadata: name: auto-import-secret namespace: <cluster_name> stringData: autoImportRetry: "5" # If you are using the kubeconfig file, add the following value for the kubeconfig file # that has the current context set to the cluster to import: kubeconfig: |- <kubeconfig_file> # If you are using the token/server pair, add the following two values instead of # the kubeconfig file: token: <Token to access the cluster> server: <cluster_api_url> type: Opaque
다음 명령을 실행하여 <cluster_name> 네임스페이스에 YAML 파일을 적용합니다.
oc apply -f auto-import-secret.yaml
참고: 기본적으로 자동 가져오기 시크릿은 한 번 사용되며 가져오기 프로세스가 완료되면 삭제됩니다. 자동 가져오기 보안을 유지하려면
managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret
을 시크릿에 추가합니다. 다음 명령을 실행하여 추가할 수 있습니다.oc -n <cluster_name> annotate secrets auto-import-secret managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret=""
가져온 클러스터에 대한 status
ED
및AVAILABLE
상태를 검증합니다. hub 클러스터에서 다음 명령을 실행합니다.oc get managedcluster <cluster_name>
클러스터에서 다음 명령을 실행하여 관리형 클러스터에 로그인합니다.
oc login
다음 명령을 실행하여 가져오는 클러스터에서 Pod 상태를 확인할 수 있습니다.
oc get pod -n open-cluster-management-agent
1.5.5.2.5. 수동으로 클러스터 가져오기
중요: 가져오기 명령에는 가져온 각 관리 클러스터에 복사되는 풀 시크릿 정보가 포함되어 있습니다. 가져온 클러스터에 액세스할 수 있는 모든 사용자는 풀 시크릿 정보도 볼 수 있습니다.
관리형 클러스터를 수동으로 가져오려면 다음 단계를 완료합니다.
다음 명령을 실행하여 hub 클러스터의 가져오기 컨트롤러에서 생성한
klusterlet-crd.yaml
파일을 가져옵니다.oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yaml
다음 명령을 실행하여 hub 클러스터에서 가져오기 컨트롤러에서 생성된
import.yaml
파일을 가져옵니다.oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yaml
가져올 클러스터에서 다음 단계를 진행합니다.
다음 명령을 입력하여 가져올 관리형 클러스터에 로그인합니다.
oc login
다음 명령을 실행하여 1단계에서 생성한
klusterlet-crd.yaml
을 적용합니다.oc apply -f klusterlet-crd.yaml
다음 명령을 실행하여 이전에 생성한
import.yaml
파일을 적용합니다.oc apply -f import.yaml
hub 클러스터에서 다음 명령을 실행하여 가져올 관리형 클러스터에 대한 192.0.2.
ED
및AVAILABLE
상태를 검증할 수 있습니다.oc get managedcluster <cluster_name>
1.5.5.2.6. klusterlet 애드온 가져오기
다음 단계를 완료하여 klusterlet 추가 기능 구성 파일을 생성하고 적용할 수 있습니다.
다음 예와 유사한 YAML 파일을 생성합니다.
apiVersion: agent.open-cluster-management.io/v1 kind: KlusterletAddonConfig metadata: name: <cluster_name> namespace: <cluster_name> spec: applicationManager: enabled: true certPolicyController: enabled: true iamPolicyController: enabled: true policyController: enabled: true searchCollector: enabled: true
-
파일을
klusterlet-addon-config.yaml
로 저장합니다. 다음 명령을 실행하여 YAML을 적용합니다.
oc apply -f klusterlet-addon-config.yaml
가져올 관리형 클러스터 상태 뒤에 애드온은
AVAILABLE
입니다.다음 명령을 실행하여 가져오는 클러스터에서 애드온의 Pod 상태를 확인할 수 있습니다.
oc get pod -n open-cluster-management-agent-addon
1.5.5.2.7. CLI를 사용하여 가져온 클러스터 제거
CLI를 사용하여 관리형 클러스터를 제거하려면 다음 명령을 실행합니다.
oc delete managedcluster <cluster_name>
& lt;cluster_name
>을 클러스터 이름으로 바꿉니다.
1.5.5.3. 가져오기를 위해 관리 클러스터에서 이미지 레지스트리 지정
가져오려는 관리 클러스터에서 이미지 레지스트리를 재정의해야 할 수 있습니다. ManagedClusterImageRegistry
사용자 정의 리소스 정의를 생성하여 이 작업을 수행할 수 있습니다.
ManagedClusterImageRegistry
사용자 정의 리소스 정의는 네임스페이스 범위 리소스입니다.
ManagedClusterImageRegistry
사용자 정의 리소스 정의는 배치가 선택할 수 있는 관리형 클러스터 세트를 지정하지만 사용자 정의 이미지 레지스트리의 다른 이미지가 필요합니다. 관리형 클러스터가 새 이미지로 업데이트되면 식별을 위해 각 관리 클러스터에 다음 레이블이 추가됩니다. open-cluster-management.io/image-registry=<namespace>.<managedClusterImageRegistryName
> .
다음 예제는 ManagedClusterImageRegistry
사용자 정의 리소스 정의를 보여줍니다.
apiVersion: imageregistry.open-cluster-management.io/v1alpha1 kind: ManagedClusterImageRegistry metadata: name: <imageRegistryName> namespace: <namespace> spec: placementRef: group: cluster.open-cluster-management.io resource: placements name: <placementName> pullSecret: name: <pullSecretName> registries: - mirror: <mirrored-image-registry-address> source: <image-registry-address> - mirror: <mirrored-image-registry-address> source: <image-registry-address>
spec
섹션에서 다음을 수행합니다.
-
placementName
을 관리 클러스터 세트를 선택하는 동일한 네임스페이스에 있는 배치 이름으로 교체합니다. -
pullSecretName
을 사용자 정의 이미지 레지스트리에서 이미지를 가져오는 데 사용되는 풀 시크릿의 이름으로 교체합니다. 각
소스
및미러
레지스트리의 값을 나열합니다.mirrored-image-registry-address
및image-registry-address
를 각미러
값과 레지스트리의소스
값으로 교체합니다.예 1:
registry.redhat.io/rhacm2
라는 소스 이미지 레지스트리를localhost:5000/rhacm2
로 교체하고registry.redhat.io/multicluster-engine
을localhost:5000/multicluster-engine
으로 교체하려면 다음 예제를 사용합니다.registries: - mirror: localhost:5000/rhacm2/ source: registry.redhat.io/rhacm2 - mirror: localhost:5000/multicluster-engine source: registry.redhat.io/multicluster-engine
예 2: 소스 이미지
registry.redhat.io/rhacm2/registration-rhel8-operator
를localhost:5000/rhacm2-registration-rhel8-operator
로 교체하려면 다음 예제를 사용합니다.registries: - mirror: localhost:5000/rhacm2-registration-rhel8-operator source: registry.redhat.io/rhacm2/registration-rhel8-operator
1.5.5.3.1. ManagedClusterImageRegistry가 있는 클러스터 가져오기
ManagedClusterImageRegistry 사용자 정의 리소스 정의로 사용자 지정된 클러스터를 가져오려면 다음 단계를 완료합니다.
클러스터를 가져오려는 네임스페이스에 풀 시크릿을 생성합니다. 이 단계의 경우 네임스페이스는
myNamespace
입니다.$ kubectl create secret docker-registry myPullSecret \ --docker-server=<your-registry-server> \ --docker-username=<my-name> \ --docker-password=<my-password>
생성한 네임스페이스에 배치를 생성합니다.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: myPlacement namespace: myNamespace spec: clusterSets: - myClusterSet tolerations: - key: "cluster.open-cluster-management.io/unreachable" operator: Exists
참고: 배치에서 클러스터를 선택하는 데
연결할 수 없는
허용 오차가 필요합니다.ManagedClusterSet
리소스를 생성하여 네임스페이스에 바인딩합니다.apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSet metadata: name: myClusterSet --- apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSetBinding metadata: name: myClusterSet namespace: myNamespace spec: clusterSet: myClusterSet
네임스페이스에서
ManagedClusterImageRegistry
사용자 정의 리소스 정의를 생성합니다.apiVersion: imageregistry.open-cluster-management.io/v1alpha1 kind: ManagedClusterImageRegistry metadata: name: myImageRegistry namespace: myNamespace spec: placementRef: group: cluster.open-cluster-management.io resource: placements name: myPlacement pullSecret: name: myPullSecret registry: myRegistryAddress
- 콘솔에서 관리형 클러스터를 가져와서 관리형 클러스터 세트에 추가합니다.
-
open-cluster-management.io/image-registry=myNamespace.myImageRegistry
레이블이 관리형 클러스터에 추가된 후 관리 클러스터에서 가져오기 명령을 복사하고 실행합니다.
1.5.6. 클러스터에 액세스
생성 및 관리되는 Red Hat OpenShift Container Platform 클러스터에 액세스하려면 다음 단계를 완료하십시오.
- 콘솔에서 Infrastructure > Clusters 로 이동하여 생성하거나 액세스하려는 클러스터 이름을 선택합니다.
Reveal credentials 를 선택하여 클러스터의 사용자 이름과 암호를 확인합니다. 클러스터에 로그인할 때 사용할 다음 값을 기록해 두십시오.
참고: 가져온 클러스터에서는 Reveal credentials 옵션을 사용할 수 없습니다.
- 클러스터에 연결할 콘솔 URL 을 선택합니다.
- 3단계에서 찾은 사용자 ID와 암호를 사용하여 클러스터에 로그인합니다.
1.5.7. 관리형 클러스터 스케일링
생성한 클러스터의 경우 가상 머신 크기 및 노드 수와 같은 관리형 클러스터 사양을 사용자 지정하고 조정할 수 있습니다. 다음 옵션을 참조하십시오.
1.5.7.1. MachinePool을 사용하여 스케일링
다중 클러스터 엔진 Operator를 사용하여 프로비저닝하는 클러스터의 경우 MachinePool
리소스가 자동으로 생성됩니다. MachinePool
을 사용하여 가상 머신 크기 및 노드 수와 같은 관리형 클러스터 사양을 추가로 사용자 지정하고 조정할 수 있습니다.
-
베어 메탈 클러스터에서는
MachinePool
리소스를 사용할 수 없습니다. -
MachinePool
리소스는 관리 클러스터에서MachineSet
리소스를 그룹화하는 hub 클러스터의 Kubernetes 리소스입니다. -
MachinePool
리소스는 영역 구성, 인스턴스 유형, 루트 스토리지를 포함하여 머신 리소스 집합을 균일하게 구성합니다. -
MachinePool
을 사용하면 원하는 노드 수를 수동으로 구성하거나 관리형 클러스터에서 노드 자동 스케일링을 구성할 수 있습니다.
1.5.7.1.1. 자동 스케일링 구성
자동 스케일링을 구성하면 트래픽이 부족할 때 리소스 비용을 줄이고 리소스에 대한 수요가 증가할 때 리소스가 충분한지 확인하기 위해 필요에 따라 확장할 수 있는 클러스터의 유연성을 제공합니다.
콘솔을 사용하여
MachinePool
리소스에서 자동 스케일링을 활성화하려면 다음 단계를 완료합니다.- 탐색에서 인프라 > 클러스터를 선택합니다.
- 대상 클러스터의 이름을 클릭하고 머신 풀 탭을 선택합니다.
- 시스템 풀 페이지의 대상 시스템 풀의 옵션 메뉴에서 자동 스케일링 활성화를 선택합니다.
최소 및 최대 머신 세트 복제본 수를 선택합니다. 머신 세트 복제본은 클러스터의 노드에 직접 매핑됩니다.
스케일 을 클릭한 후 콘솔에 반영하는 데 몇 분이 걸릴 수 있습니다. 머신 풀 탭 알림에서 시스템 보기 를 클릭하여 스케일링 작업의 상태를 볼 수 있습니다.
명령줄을 사용하여
MachinePool
리소스에서 자동 스케일링을 활성화하려면 다음 단계를 완료합니다.다음 명령을 입력하여 머신 풀 목록을 표시하고
managed-cluster-namespace
를 대상 관리 클러스터의 네임스페이스로 바꿉니다.oc get machinepools -n <managed-cluster-namespace>
다음 명령을 입력하여 머신 풀의 YAML 파일을 편집합니다.
oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
-
MachinePool-resource-name
을MachinePool
리소스 이름으로 바꿉니다. -
managed-cluster-namespace
를 관리 클러스터의 네임스페이스 이름으로 교체합니다.
-
-
YAML 파일에서
spec.replicas
필드를 삭제합니다. -
spec.autoscaling.minReplicas
설정 및spec.autoscaling.maxReplicas
필드를 리소스 YAML에 추가합니다. -
minReplicas
설정에 최소 복제본 수를 추가합니다. -
최대 복제본 수를
maxReplicas
설정에 추가합니다. - 파일을 저장하여 변경 사항을 제출합니다.
1.5.7.1.2. 자동 스케일링 비활성화
콘솔 또는 명령줄을 사용하여 자동 스케일링을 비활성화할 수 있습니다.
콘솔을 사용하여 자동 스케일링을 비활성화하려면 다음 단계를 완료합니다.
- 탐색에서 인프라 > 클러스터를 선택합니다.
- 대상 클러스터의 이름을 클릭하고 머신 풀 탭을 선택합니다.
- 시스템 풀 페이지의 대상 시스템 풀의 Options 메뉴에서 Disable autoscale 을 선택합니다.
원하는 머신 세트 복제본 수를 선택합니다. 머신 세트 복제본은 클러스터의 노드와 직접 매핑됩니다.
스케일 을 클릭한 후 콘솔에 표시되는 데 몇 분이 걸릴 수 있습니다. 머신 풀 탭의 알림에서 머신 보기 를 클릭하여 스케일링 상태를 볼 수 있습니다.
명령줄을 사용하여 자동 스케일링을 비활성화하려면 다음 단계를 완료합니다.
다음 명령을 입력하여 머신 풀 목록을 확인합니다.
oc get machinepools -n <managed-cluster-namespace>
managed-cluster-namespace
를 대상 관리 클러스터의 네임스페이스로 교체합니다.다음 명령을 입력하여 머신 풀의 YAML 파일을 편집합니다.
oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>
name-of-MachinePool-resource
를MachinePool
리소스의 이름으로 바꿉니다.namespace-of-managed-cluster
를 관리 클러스터의 네임스페이스 이름으로 교체합니다.-
YAML 파일에서
spec.autoscaling
필드를 삭제합니다. -
spec.replicas
필드를 리소스 YAML에 추가합니다. -
replicas
설정에 복제본 수를 추가합니다. - 파일을 저장하여 변경 사항을 제출합니다.
1.5.7.1.3. 수동 스케일링 활성화
콘솔과 명령줄에서 수동으로 확장할 수 있습니다.
1.5.7.1.3.1. 콘솔을 사용하여 수동 스케일링 활성화
콘솔을 사용하여 MachinePool
리소스를 확장하려면 다음 단계를 완료합니다.
-
MachinePool
이 활성화된 경우 자동 스케일링을 비활성화합니다. 이전 단계를 참조하십시오. - 콘솔에서 Infrastructure > Clusters 를 클릭합니다.
- 대상 클러스터의 이름을 클릭하고 머신 풀 탭을 선택합니다.
- 시스템 풀 페이지의 옵션 메뉴에서 대상 시스템 풀의 스케일 머신 풀을 선택합니다.
- 원하는 머신 세트 복제본 수를 선택합니다. 머신 세트 복제본은 클러스터의 노드와 직접 매핑됩니다. 스케일 을 클릭한 후 콘솔에 반영하는 데 몇 분이 걸릴 수 있습니다. 머신 풀 탭 알림에서 시스템 보기 를 클릭하여 스케일링 작업의 상태를 볼 수 있습니다.
1.5.7.1.3.2. 명령줄을 사용하여 수동 스케일링 활성화
명령줄을 사용하여 MachinePool
리소스를 확장하려면 다음 단계를 완료합니다.
다음 명령을 입력하여 머신 풀 목록을 표시하고 <
managed-cluster-namespace
>를 대상 관리 클러스터 네임스페이스의 네임스페이스로 바꿉니다.oc get machinepools -n <managed-cluster-namespace>
다음 명령을 입력하여 머신 풀의 YAML 파일을 편집합니다.
oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
-
MachinePool-resource-name
을MachinePool
리소스 이름으로 바꿉니다. -
managed-cluster-namespace
를 관리 클러스터의 네임스페이스 이름으로 교체합니다.
-
-
YAML 파일에서
spec.autoscaling
필드를 삭제합니다. -
YAML 파일의
spec.replicas
필드를 원하는 복제본 수로 수정합니다. - 파일을 저장하여 변경 사항을 제출합니다.
1.5.7.2. 인프라 환경으로 호스트 확장
콘솔을 사용하여 인프라 환경에 호스트를 추가할 수 있습니다. 호스트를 추가하면 클러스터를 생성할 때 이미 구성된 호스트를 더 쉽게 선택할 수 있습니다.
호스트를 추가하려면 다음 단계를 완료합니다.
- 탐색 메뉴에서 Infrastructure > Host inventory 를 선택합니다.
- 설정을 볼 호스트를 추가할 호스트 인벤토리를 선택합니다.
- 호스트 탭을 선택하여 이미 해당 환경에 추가된 호스트를 확인하고 호스트를 추가합니다. 사용 가능한 호스트가 테이블에 표시되는 데 몇 분이 걸릴 수 있습니다.
- Discovery ISO 사용을 선택하고iPXE,BMC 양식으로 또는 호스트에 대한 정보를 입력하도록 YAML을 업로드하여 선택합니다.
Discovery ISO 사용 옵션을 선택하는 경우 다음 단계를 완료합니다.
- 콘솔에 제공된 명령을 복사하여 ISO를 다운로드하거나 Discovery ISO 다운로드를 선택합니다.
- 부팅 가능한 장치에서 명령을 실행하여 각 호스트를 시작합니다.
- 보안을 강화하기 위해 검색된 각 호스트에 대해 Approve host 를 선택합니다. 이 추가 단계는 ISO 파일이 변경되어 인증되지 않은 사람이 실행하는 경우 일부 보호 조치를 제공합니다.
-
이름이 지정된 호스트,
localhost
의 이름을 고유한 이름으로 변경합니다.
iPXE를 사용하여 선택하는 경우 다음 단계를 완료합니다.
- 스크립트 파일 생성을 클릭합니다.
- 스크립트 파일 다운로드를 클릭하고 콘솔 지침에 따라 iPXE를 사용하여 호스트를 부팅합니다.
BMC 양식으로 선택하는 경우 다음 단계를 완료합니다.
참고: 호스트 추가를 위한 BMC 옵션은 허브 클러스터의 플랫폼이 베어 메탈, Red Hat OpenStack Platform, VMware vSphere이고 사용자 프로비저닝 인프라(UPI) 방법을 사용하여 설치된 경우에만 사용할 수 있으며 플랫폼은
None
입니다.- 호스트의 BMC에 대한 연결 세부 정보를 추가합니다.
부팅 프로세스를 시작하려면 호스트 추가 를 선택합니다. 호스트는 검색 ISO 이미지를 사용하여 자동으로 부팅되며 호스트 목록이 시작될 때 추가됩니다.
BMC 옵션을 사용하여 호스트를 추가하면 호스트가 자동으로 승인됩니다.
YAML을 업로드하는 방법 옵션을 선택하는 경우 다음 단계를 완료합니다.
참고: YAML 옵션을 사용할 때 여러 호스트를 동시에 업로드할 수 있습니다.
- 템플릿 다운로드를 선택하여 제공된 YAML을 작성합니다.
- 업로드 를 선택하고 완료된 YAML 템플릿으로 이동하여 호스트를 여러 개 추가합니다.
이제 이 인프라 환경에서 온-프레미스 클러스터를 만들 수 있습니다. 클러스터 생성에 대한 자세한 내용은 온-프레미스 환경에서 클러스터 생성을 참조하십시오.
1.5.7.2.1. CIM으로 배포된 기존 OpenShift Container Platform 클러스터에 노드 추가
CIM으로 배포된 기존 OpenShift Container Platform 클러스터에 노드를 추가하려면 이전 단계를 완료한 다음 agentSelector
매개변수에 추가하여 새 에이전트
사용자 정의 리소스 정의를 ClusterDeployment
사용자 정의 리소스에 연결합니다.
1.5.8. 클러스터 프록시 애드온 사용
일부 환경에서는 관리형 클러스터가 방화벽 뒤에 있으며 hub 클러스터에서 직접 액세스할 수 없습니다. 액세스할 수 있도록 보다 안전한 연결을 제공하기 위해 관리형 클러스터의 kube-apiserver
에 액세스하도록 프록시 애드온을 설정할 수 있습니다.
중요: 허브 클러스터 또는 관리형 클러스터에 [ 클러스터 전체 프록시](https://docs.openshift.com/container-platform/4.12/networking/enable-cluster-wide-proxy.html) 구성이 있는 경우 cluster-proxy-addon
이 작동하지 않습니다.
필수 액세스: 편집기
hub 클러스터 및 관리 클러스터에 대한 클러스터 프록시 애드온을 구성하려면 다음 단계를 완료하십시오.
다음 단계를 완료하여 관리 클러스터
kube-apiserver
에 액세스하도록kubeconfig
파일을 구성합니다.관리 클러스터에 유효한 액세스 토큰을 제공합니다.
참고: 서비스 계정의 해당 토큰을 사용할 수 있습니다. 기본 네임스페이스에 있는 기본 서비스 계정을 사용할 수도 있습니다.
다음 명령을 실행하여 관리 클러스터의
kubeconfig
파일을 내보냅니다.export KUBECONFIG=<managed-cluster-kubeconfig>
다음 명령을 실행하여 Pod에 액세스할 수 있는 서비스 계정에 역할을 추가합니다.
oc create role -n default test-role --verb=list,get --resource=pods oc create rolebinding -n default test-rolebinding --serviceaccount=default:default --role=test-role
다음 명령을 실행하여 서비스 계정 토큰의 보안을 찾습니다.
oc get secret -n default | grep <default-token>
default-token
을 보안 이름으로 교체합니다.다음 명령을 실행하여 토큰을 복사합니다.
export MANAGED_CLUSTER_TOKEN=$(kubectl -n default get secret <default-token> -o jsonpath={.data.token} | base64 -d)
default-token
을 보안 이름으로 교체합니다.
Red Hat Advanced Cluster Management hub 클러스터에서
kubeconfig
파일을 구성합니다.다음 명령을 실행하여 hub 클러스터에서 현재
kubeconfig
파일을 내보냅니다.oc config view --minify --raw=true > cluster-proxy.kubeconfig
편집기로
서버
파일을 수정합니다. 이 예제에서는sed
를 사용할 때 명령을 사용합니다. OSX를 사용하는 경우별칭 sed=gsed
를 실행합니다.export TARGET_MANAGED_CLUSTER=<managed-cluster-name> export NEW_SERVER=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/$TARGET_MANAGED_CLUSTER sed -i'' -e '/server:/c\ server: '"$NEW_SERVER"'' cluster-proxy.kubeconfig export CADATA=$(oc get configmap -n openshift-service-ca kube-root-ca.crt -o=go-template='{{index .data "ca.crt"}}' | base64) sed -i'' -e '/certificate-authority-data:/c\ certificate-authority-data: '"$CADATA"'' cluster-proxy.kubeconfig
다음 명령을 입력하여 원래 사용자 자격 증명을 삭제합니다.
sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig sed -i'' -e '/token/d' cluster-proxy.kubeconfig
서비스 계정의 토큰을 추가합니다.
sed -i'' -e '$a\ token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig
다음 명령을 실행하여 대상 관리 클러스터의 대상 네임스페이스에 있는 모든 Pod를 나열합니다.
oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>
default
네임스페이스를 사용하려는 네임스페이스로 바꿉니다.관리형 클러스터에서 다른 서비스에 액세스합니다. 이 기능은 관리 클러스터가 Red Hat OpenShift Container Platform 클러스터인 경우 사용할 수 있습니다. 서비스는 서버 인증서를 생성하려면
service-serving-certificate
를 사용해야 합니다.관리형 클러스터에서 다음 서비스 계정 토큰을 사용합니다.
export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)
hub 클러스터에서 다음 명령을 실행하여 인증 기관을 파일로 변환합니다.
oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crt
다음 명령을 사용하여 관리 클러스터의 Prometheus 지표를 가져옵니다.
export SERVICE_NAMESPACE=openshift-monitoring export SERVICE_NAME=prometheus-k8s export SERVICE_PORT=9091 export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets" curl --cacert hub-ca.crt $NEW_SERVER/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"
1.5.9. 관리 클러스터에서 실행되도록 Ansible Automation Platform 작업 구성
멀티 클러스터 엔진 Operator는 Red Hat Ansible Automation Platform과 통합되어 클러스터를 생성하거나 업그레이드하기 전이나 업그레이드 후 발생하는 prehook 및 posthook Ansible 작업 인스턴스를 생성할 수 있습니다. 클러스터 제거에 대한 prehook 및 posthook 작업을 구성하고 클러스터 스케일링 작업은 지원되지 않습니다.
필수 액세스 권한: 클러스터 관리자
1.5.9.1. 사전 요구 사항
클러스터에서 Automation 템플릿을 실행하려면 다음 사전 요구 사항을 충족해야 합니다.
- OpenShift Container Platform 4.6 이상
- Ansible Automation Platform Resource Operator를 설치하여 Ansible 작업을 Git 서브스크립션 라이프사이클에 연결합니다. Automation 템플릿을 사용하여 Ansible Automation Platform 작업을 시작할 때 최상의 결과를 얻으려면 Ansible Automation Platform 작업 템플릿이 멱등이어야 합니다. OpenShift Container Platform OperatorHub 에서 Ansible Automation Platform Resource Operator를 찾을 수 있습니다.
1.5.9.2. 콘솔을 사용하여 클러스터에서 실행되도록 자동화 템플릿 구성
클러스터를 가져올 때, 클러스터를 가져올 때 또는 클러스터를 생성한 후 클러스터에 사용할 Automation 템플릿을 지정할 수 있습니다.
클러스터를 생성하거나 가져올 때 템플릿을 지정하려면 자동화 단계에서 클러스터에 적용할 Ansible 템플릿을 선택합니다. 자동화 템플릿이 없는 경우 자동화 템플릿 추가를 클릭하여 템플릿을 생성합니다.
클러스터를 생성한 후 템플릿을 지정하려면 기존 클러스터의 작업 메뉴에서 자동화 템플릿 업데이트를 클릭합니다. Update 자동화 템플릿 옵션을 사용하여 기존 자동화 템플릿을 업데이트할 수도 있습니다.
1.5.9.3. 자동화 템플릿 생성
클러스터 설치 또는 업그레이드를 사용하여 Ansible 작업을 시작하려면 작업을 실행할 시기를 지정할 Automation 템플릿을 생성해야 합니다. 클러스터 설치 또는 업그레이드 전후에 실행되도록 구성할 수 있습니다.
템플릿을 생성하는 동안 Ansible 템플릿 실행에 대한 세부 정보를 지정하려면 콘솔의 단계를 완료합니다.
- 탐색에서 인프라 > 자동화 를 선택합니다.
상황에 맞는 경로를 선택합니다.
- 새 템플릿을 생성하려면 Create Ansible template 을 클릭하고 3단계를 계속합니다.
- 기존 템플릿을 수정하려면 수정하려는 템플릿의 옵션 메뉴에서 템플릿 편집 을 클릭하고 5단계로 진행합니다.
- 템플릿의 고유 이름을 입력합니다. 소문자 영숫자 또는 하이픈(-)을 포함합니다.
새 템플릿에 사용할 인증 정보를 선택합니다. Ansible 자격 증명을 Ansible 템플릿에 연결하려면 다음 단계를 완료합니다.
- 탐색에서 Automation 을 선택합니다. 인증 정보에 연결되지 않은 템플릿 목록에 있는 템플릿에는 템플릿을 기존 인증 정보에 연결하는 데 사용할 수 있는 인증 정보 링크 아이콘이 포함되어 있습니다. 템플릿과 동일한 네임스페이스에 있는 인증 정보만 표시됩니다.
- 선택할 수 있는 인증 정보가 없거나 기존 인증 정보를 사용하지 않으려면 연결할 템플릿의 옵션 메뉴에서 템플릿 편집 을 선택합니다.
- 인증 정보 추가 를 클릭하고 인증 정보를 생성해야 하는 경우 Ansible Automation Platform에 대한 인증 정보 생성 절차를 완료합니다.
- 템플릿과 동일한 네임스페이스에 인증 정보를 생성한 후 템플릿을 편집할 때 Ansible Automation Platform 인증 정보 필드에서 인증 정보를 선택합니다.
- 클러스터를 설치하기 전에 Ansible 작업을 시작하려면 Pre-install Automation templates 섹션에서 Add an Automation template 을 선택합니다.
클러스터 설치 또는 업그레이드에 추가할 prehook 및 posthook Ansible 작업의 이름을 선택하거나 입력합니다.
참고: 자동화 템플릿 이름은 Ansible Automation Platform의 Ansible 작업 이름과 일치해야 합니다.
- 필요한 경우 Ansible 작업을 끌어서 순서를 변경합니다.
- 클러스터가 설치 후 자동화 템플릿 섹션, 사전 업그레이드 자동화 템플릿 섹션, 업그레이드 후 자동화 템플릿 섹션에 설치된 후 시작하려는 모든 자동화 템플릿에 대해 5~7단계를 반복합니다.
Ansible 템플릿은 지정된 작업이 발생할 때 이 템플릿을 지정하는 클러스터에서 실행되도록 구성됩니다.
1.5.9.4. Ansible 작업 상태 보기
실행 중인 Ansible 작업의 상태를 보고 시작했으며 성공적으로 실행되고 있는지 확인할 수 있습니다. 실행 중인 Ansible 작업의 현재 상태를 보려면 다음 단계를 완료합니다.
- 메뉴에서 Infrastructure > Clusters 를 선택하여 클러스터 페이지에 액세스합니다.
- 클러스터 이름을 선택하여 세부 정보를 확인합니다.
클러스터 정보에 대해 Ansible 작업의 마지막 실행 상태를 봅니다. 이 항목은 다음 상태 중 하나를 보여줍니다.
-
설치 prehook 또는 posthook 작업이 실패하면 클러스터 상태에
Failed
가 표시됩니다. 업그레이드 prehook 또는 posthook 작업이 실패하면 업그레이드에 실패한 배포 필드에 경고가 표시됩니다.
팁: 클러스터 prehook 또는 posthook 가 실패한 경우 클러스터 페이지에서 업그레이드를 재시도할 수 있습니다.
-
설치 prehook 또는 posthook 작업이 실패하면 클러스터 상태에
1.5.10. ClusterClaims
ClusterClaim
은 관리형 클러스터의 클러스터 범위의 CRD(사용자 정의 리소스 정의)입니다. ClusterClaim은 관리형 클러스터가 클레임하는 정보를 나타냅니다. ClusterClaim을 사용하여 대상 클러스터에서 리소스의 배치를 차단 해제할 수 있습니다.
다음 예제는 YAML 파일에서 식별되는 ClusterClaim을 보여줍니다.
apiVersion: cluster.open-cluster-management.io/v1alpha1 kind: ClusterClaim metadata: name: id.openshift.io spec: value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
다음 표는 다중 클러스터 엔진 Operator가 관리하는 클러스터에 있을 수 있는 정의된 ClusterClaims를 보여줍니다.
클레임 이름 | reserved | 변경 가능 | 설명 |
---|---|---|---|
| true | false | 업스트림 제안에 정의된 ClusterID |
| true | true | Kubernetes 버전 |
| true | false | 관리형 클러스터가 AWS, GCE, Equinix Metal과 같은 플랫폼에서 실행 중입니다. |
| true | false | OpenShift,anchorhos, EKS 및 GKE와 같은 제품 이름 |
| false | false | OpenShift Container Platform 클러스터에서만 사용할 수 있는 OpenShift Container Platform 외부 ID |
| false | true | OpenShift Container Platform 클러스터에서만 사용할 수 있는 관리 콘솔의 URL |
| false | true | OpenShift Container Platform 클러스터에서만 사용할 수 있는 OpenShift Container Platform 버전 |
이전 클레임이 삭제되거나 관리되는 클러스터에서 업데이트되면 자동으로 이전 버전으로 복원되거나 롤백됩니다.
관리형 클러스터가 허브에 참여하면 관리 클러스터에서 생성된 ClusterClaims가 허브의 ManagedCluster
리소스 상태와 동기화됩니다. ClusterClaims가 있는 관리형 클러스터는 다음 예와 유사할 수 있습니다.
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: labels: cloud: Amazon clusterID: 95f91f25-d7a2-4fc3-9237-2ef633d8451c installer.name: multiclusterhub installer.namespace: open-cluster-management name: cluster1 vendor: OpenShift name: cluster1 spec: hubAcceptsClient: true leaseDurationSeconds: 60 status: allocatable: cpu: '15' memory: 65257Mi capacity: cpu: '18' memory: 72001Mi clusterClaims: - name: id.k8s.io value: cluster1 - name: kubeversion.open-cluster-management.io value: v1.18.3+6c42de8 - name: platform.open-cluster-management.io value: AWS - name: product.open-cluster-management.io value: OpenShift - name: id.openshift.io value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c - name: consoleurl.openshift.io value: 'https://console-openshift-console.apps.xxxx.dev04.red-chesterfield.com' - name: version.openshift.io value: '4.5' conditions: - lastTransitionTime: '2020-10-26T07:08:49Z' message: Accepted by hub cluster admin reason: HubClusterAdminAccepted status: 'True' type: HubAcceptedManagedCluster - lastTransitionTime: '2020-10-26T07:09:18Z' message: Managed cluster joined reason: ManagedClusterJoined status: 'True' type: ManagedClusterJoined - lastTransitionTime: '2020-10-30T07:20:20Z' message: Managed cluster is available reason: ManagedClusterAvailable status: 'True' type: ManagedClusterConditionAvailable version: kubernetes: v1.18.3+6c42de8
1.5.10.1. 기존 ClusterClaims 나열
kubectl
명령을 사용하여 관리 클러스터에 적용되는 ClusterClaim을 나열할 수 있습니다. 이는 ClusterClaim을 오류 메시지와 비교하려는 경우에 유용합니다.
참고: resource clusterclaims.cluster.open-cluster-management.io
에 대한 목록
권한이 있는지 확인합니다.
다음 명령을 실행하여 관리형 클러스터에 있는 기존 ClusterClaim을 모두 나열합니다.
kubectl get clusterclaims.cluster.open-cluster-management.io
1.5.10.2. 사용자 정의 ClusterClaims 생성
관리형 클러스터에서 사용자 지정 이름을 사용하여 ClusterClaims를 생성하여 쉽게 식별할 수 있습니다. 사용자 지정 ClusterClaims는 허브 클러스터에서 ManagedCluster
리소스의 상태와 동기화됩니다. 다음 콘텐츠는 사용자 정의된 ClusterClaim
정의의 예를 보여줍니다.
apiVersion: cluster.open-cluster-management.io/v1alpha1 kind: ClusterClaim metadata: name: <custom_claim_name> spec: value: <custom_claim_value>
spec.value
필드의 최대 길이는 1024입니다. ClusterClaim을 생성하려면
resource clusterclaims.cluster.open-cluster-management.io
에 대한 생성 권한이 필요합니다.
1.5.11. ManagedClusterSets
ManagedClusterSet
은 관리형 클러스터 그룹입니다. 관리형 클러스터 세트를 사용하면 모든 관리 클러스터에 대한 액세스를 관리할 수 있습니다. ManagedClusterSetBinding
리소스를 생성하여 ManagedClusterSet
리소스를 네임스페이스에 바인딩할 수도 있습니다.
각 클러스터는 관리형 클러스터 세트의 멤버여야 합니다. hub 클러스터를 설치하면 ManagedClusterSet
리소스가 default
라고 합니다. 관리형 클러스터 세트에 할당되지 않은 모든 클러스터는 기본
관리 클러스터 세트에 자동으로 할당됩니다. 기본
관리 클러스터 세트를 삭제하거나 업데이트할 수 없습니다.
관리되는 클러스터 세트를 생성하고 관리하는 방법에 대한 자세한 내용은 계속 읽어 보십시오.
1.5.11.1. ManagedClusterSet생성
관리형 클러스터에서 함께 관리 클러스터를 그룹화하여 관리형 클러스터에서 사용자 액세스를 제한할 수 있습니다.
필수 액세스 권한: 클러스터 관리자
ManagedClusterSet
은 클러스터 범위 리소스이므로 ManagedClusterSet
을 생성하는 클러스터의 클러스터 관리 권한이 있어야 합니다. 관리 클러스터는 둘 이상의 ManagedClusterSet
에 포함할 수 없습니다. 멀티 클러스터 엔진 Operator 콘솔 또는 CLI에서 관리형 클러스터 세트를 생성할 수 있습니다.
참고: 관리형 클러스터 세트에 추가되지 않은 클러스터 풀은 기본 ManagedClusterSet
리소스에 추가되지 않습니다. 클러스터 풀에서 클러스터를 요청하면 기본 ManagedClusterSet
에 클러스터가 추가됩니다.
관리형 클러스터를 생성하면 쉽게 관리할 수 있도록 다음이 자동으로 생성됩니다.
-
global
이라는ManagedClusterSet
. -
open-cluster-management-global-set
라는 네임스페이스입니다. 글로벌
ManagedClusterSet
을open-cluster-management-
네임스페이스에 바인딩하는 글로벌이라는global
-setManagedClusterSetBinding
.중요:
글로벌
관리 클러스터 세트를 삭제, 업데이트 또는 편집할 수 없습니다.글로벌
관리형 클러스터에는 모든 관리 클러스터가 포함됩니다. 다음 예제를 참조하십시오.apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSetBinding metadata: name: global namespace: open-cluster-management-global-set spec: clusterSet: global
1.5.11.1.1. CLI를 사용하여 ManagedClusterSet 생성
관리 클러스터 세트의 다음 정의를 YAML 파일에 추가하여 CLI를 사용하여 설정된 관리형 클러스터를 생성합니다.
apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSet metadata: name: <cluster_set>
& lt;cluster_set&
gt;를 관리형 클러스터 세트의 이름으로 바꿉니다.
1.5.11.1.2. ManagedClusterSet에 클러스터 추가
ManagedClusterSet
을 생성한 후 콘솔의 지침에 따라 또는 CLI를 사용하여 설정된 관리형 클러스터에 클러스터를 추가할 수 있습니다.
1.5.11.1.3. CLI를 사용하여 ManagedClusterSet 에 클러스터 추가
CLI를 사용하여 설정한 관리형 클러스터에 클러스터를 추가하려면 다음 단계를 완료합니다.
managedclustersets/join
의 가상 하위 리소스에서 생성할 수 있는 RBACClusterRole
항목이 있는지 확인합니다.참고: 이 권한이 없으면
ManagedClusterSet
에 관리 클러스터를 할당할 수 없습니다. 이 항목이 없는 경우 YAML 파일에 추가합니다. 다음 예제를 참조하십시오.kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: clusterrole1 rules: - apiGroups: ["cluster.open-cluster-management.io"] resources: ["managedclustersets/join"] resourceNames: ["<cluster_set>"] verbs: ["create"]
&
lt;cluster_set&
gt;를ManagedClusterSet
의 이름으로 바꿉니다.참고: 관리 클러스터를 하나의
ManagedClusterSet
에서 다른 클러스터로 이동하는 경우 두 관리 클러스터 세트 모두에서 사용 가능한 권한이 있어야 합니다.YAML 파일에서 관리 클러스터의 정의를 찾습니다. 다음 예제 정의를 참조하십시오.
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: <cluster_name> spec: hubAcceptsClient: true
cluster.open-cluster-management.io/clusterset
paremeter를 추가하고ManagedClusterSet
의 이름을 지정합니다. 다음 예제를 참조하십시오.apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: <cluster_name> labels: cluster.open-cluster-management.io/clusterset: <cluster_set> spec: hubAcceptsClient: true
1.5.11.2. ManagedClusterSet에 RBAC 권한 할당
hub 클러스터에서 구성된 ID 공급자가 제공하는 사용자 또는 그룹을 클러스터에 할당할 수 있습니다.
필수 액세스 권한: 클러스터 관리자
세 가지 ManagedClusterSet
API RBAC 권한 수준은 다음 표를 참조하십시오.
클러스터 세트 | 액세스 권한 | 권한 생성 |
---|---|---|
| 관리형 클러스터 세트에 할당된 모든 클러스터 및 클러스터 풀 리소스에 대한 전체 액세스 권한입니다. | 클러스터를 생성하고, 클러스터를 가져오고, 클러스터 풀을 생성할 수 있는 권한입니다. 권한을 생성할 때 관리 클러스터에 할당해야 합니다. |
|
| 클러스터를 생성하거나 클러스터를 가져오거나 클러스터 풀을 생성할 수 있는 권한이 없습니다. |
| 관리형 클러스터 세트에 할당된 모든 클러스터 및 클러스터 풀 리소스에 대한 권한만 읽습니다. | 클러스터를 생성하거나 클러스터를 가져오거나 클러스터 풀을 생성할 수 있는 권한이 없습니다. |
참고: 글로벌 클러스터 세트에 대한 Cluster set admin
권한을 적용할 수 없습니다.
콘솔에서 관리형 클러스터에 사용자 또는 그룹을 할당하려면 다음 단계를 완료합니다.
- OpenShift Container Platform 콘솔에서 인프라 > ; 클러스터로 이동합니다.
- 클러스터 세트 탭을 선택합니다.
- 대상 클러스터 세트를 선택합니다.
- 액세스 관리 탭을 선택합니다.
- 사용자 또는 그룹 추가를 선택합니다.
- 액세스 권한을 검색하고 제공할 사용자 또는 그룹을 선택합니다.
- Cluster set admin 또는 Cluster set view 역할을 선택하여 선택한 사용자 또는 사용자 그룹에 제공합니다. 자세한 내용은 다중 클러스터 엔진 운영자 역할 기반 액세스 제어 의 역할 개요 를 참조하십시오.
- 추가 를 선택하여 변경 사항을 제출합니다.
사용자 또는 그룹이 테이블에 표시됩니다. 모든 관리 클러스터 세트 리소스가 사용자 또는 그룹에 전파되도록 권한 할당에 대해 권한 할당이 몇 초 정도 걸릴 수 있습니다.
배치 정보는 ManagedClusterSets를 배치와 함께 사용을 참조하십시오.
1.5.11.3. ManagedClusterSetBinding 리소스 생성
ManagedClusterSetBinding
리소스는 ManagedClusterSet
리소스를 네임스페이스에 바인딩합니다. 동일한 네임스페이스에서 생성되는 애플리케이션 및 정책은 바인딩된 관리 클러스터 세트 리소스에 포함된 클러스터에만 액세스할 수 있습니다.
네임스페이스에 대한 액세스 권한은 해당 네임스페이스에 바인딩된 관리형 클러스터 세트에 자동으로 적용됩니다. 해당 네임스페이스에 대한 액세스 권한이 있는 경우 해당 네임스페이스에 바인딩된 모든 관리 클러스터 세트에 액세스할 수 있는 권한이 자동으로 있습니다. 관리 클러스터 세트에 액세스할 수 있는 권한만 있는 경우, 네임스페이스의 다른 관리 클러스터 세트에 액세스할 수 있는 권한이 자동으로 부여되지 않습니다.
콘솔 또는 명령줄을 사용하여 관리형 클러스터 세트 바인딩을 생성할 수 있습니다.
1.5.11.3.1. 콘솔을 사용하여 ManagedClusterSetBinding 생성
콘솔을 사용하여 ManagedClusterSetBinding
을 생성하려면 다음 단계를 완료합니다.
- OpenShift Container Platform 콘솔에서 인프라 > ; 클러스터로 이동 하여 클러스터 세트 탭을 선택합니다.
- 바인딩을 생성할 클러스터 세트의 이름을 선택합니다.
- Actions > Edit namespace bindings 로 이동합니다.
- 네임스페이스 바인딩 편집 페이지의 드롭다운 메뉴에서 클러스터 세트를 바인딩할 네임스페이스를 선택합니다.
1.5.11.3.2. CLI를 사용하여 ManagedClusterSetBinding 생성
CLI를 사용하여 ManagedClusterSetBinding
을 생성하려면 다음 단계를 완료합니다.
YAML 파일에
ManagedClusterSetBinding
리소스를 생성합니다.참고: 관리형 클러스터 세트 바인딩을 생성할 때 관리형 클러스터 세트 바인딩의 이름은 바인딩할 관리형 클러스터 세트의 이름과 일치해야 합니다.
ManagedClusterSetBinding
리소스는 다음 정보와 유사합니다.apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSetBinding metadata: namespace: <namespace> name: <cluster_name> spec: clusterSet: <cluster_set>
대상 관리 클러스터에 대한 바인딩 권한이 설정되어 있는지 확인합니다. 사용자가 <
cluster_set
>에 바인딩할 수 있도록 하는 규칙이 포함된ClusterRole
리소스의 다음 예제를 봅니다.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <clusterrole> rules: - apiGroups: ["cluster.open-cluster-management.io"] resources: ["managedclustersets/bind"] resourceNames: ["<cluster_set>"] verbs: ["create"]
1.5.11.4. 테인트 및 톨러레이션을 사용하여 관리형 클러스터 배치
테인트 및 톨러레이션을 사용하여 관리 클러스터 또는 관리형 클러스터 세트의 배치를 제어할 수 있습니다. 테인트 및 허용 오차는 관리 클러스터가 특정 배치에 대해 선택되지 않도록 하는 방법을 제공합니다. 특정 관리 클러스터가 일부 배치에 포함되지 않도록 하려면 이 제어가 유용할 수 있습니다. 관리형 클러스터에 테인트를 추가하고 배치에 허용 오차를 추가할 수 있습니다. 테인트 및 허용 오차가 일치하지 않으면 해당 배치에 대해 관리 클러스터가 선택되지 않습니다.
1.5.11.4.1. 관리형 클러스터에 테인트 추가
테인트는 관리형 클러스터의 속성에 지정되며, 배치가 관리 클러스터 또는 관리되는 클러스터 집합을 거절할 수 있습니다. 다음 예와 유사한 명령을 입력하여 관리형 클러스터에 테인트를 추가할 수 있습니다.
oc taint ManagedCluster <managed_cluster_name> key=value:NoSelect
테인트 사양에는 다음 필드가 포함됩니다.
-
필수 키 - 클러스터에 적용되는 테인트 키입니다. 이 값은 해당 배치에 추가되는 기준을 충족하는 관리형 클러스터의 허용 오차 값과 일치해야 합니다. 이 값을 확인할 수 있습니다. 예를 들어 이 값은
bar
또는foo.example.com/bar
일 수 있습니다. -
선택사항 값 - taint 키의 taint 값입니다. 이 값은 해당 배치에 추가되는 기준을 충족하는 관리형 클러스터의 허용 오차 값과 일치해야 합니다. 예를 들어 이 값은
value
일 수 있습니다. 필수 Effect - 테인트를 허용하지 않는 배치 또는 배치의 허용 오차가 일치하지 않을 때 발생하는 항목에 대한 테인트의 영향입니다. 효과 값은 다음 값 중 하나여야 합니다.
-
NoSelect
- 배치는 이 테인트를 허용하지 않는 한 클러스터를 선택할 수 없습니다. 테인트를 설정하기 전에 배치에 의해 클러스터를 선택하면 배치 결정에서 클러스터가 제거됩니다. -
NoSelectIfNew
- 스케줄러가 새 클러스터인 경우 클러스터를 선택할 수 없습니다. 배치는 테인트를 허용하고 클러스터가 이미 클러스터가 결정되도록 하는 경우에만 클러스터를 선택할 수 있습니다.
-
-
필수
TimeAdded
- 테인트가 추가된 시간입니다. 이 값은 자동으로 설정됩니다.
1.5.11.4.2. 관리형 클러스터의 상태를 반영하기 위해 기본 제공 테인트 식별
관리형 클러스터에 액세스할 수 없는 경우 클러스터를 배치에 추가하지 않도록 합니다. 다음 테인트는 액세스할 수 없는 관리형 클러스터에 자동으로 추가됩니다.
cluster.open-cluster-management.io/unavailable
- 이 테인트는 클러스터에False
상태의ManagedClusterConditionAvailable
조건이 있는 경우 관리 클러스터에 추가됩니다. 테인트는NoSelect
의 효과가 있으며, 사용할 수 없는 클러스터가 예약되지 않도록 하는 빈 값이 비어 있습니다. 이 테인트의 예는 다음 콘텐츠에 제공됩니다.apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: cluster.open-cluster-management.io/unavailable timeAdded: '2022-02-21T08:11:54Z'
cluster.open-cluster-management.io/unreachable
- 이 테인트는ManagedClusterConditionAvailable
조건의 상태가Unknown
이거나 조건이 없는 경우 관리형 클러스터에 추가됩니다. 테인트는NoSelect
의 효과가 있으며 연결할 수 없는 클러스터가 예약되지 않도록 하는 빈 값이 비어 있습니다. 이 테인트의 예는 다음 콘텐츠에 제공됩니다.apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: cluster.open-cluster-management.io/unreachable timeAdded: '2022-02-21T08:11:06Z'
1.5.11.4.3. 배치에 허용 오차 추가
허용 오차는 배치에 적용되며 배치 허용 오차와 일치하는 테인트가 없는 관리형 클러스터를 배치할 수 있습니다. 허용 오차 사양에는 다음 필드가 포함됩니다.
- 선택 사항 키 - 키가 배치를 허용하는 taint 키와 일치합니다.
- 선택 사항 - 허용 오차의 값은 배치를 허용하려면 허용 오차의 테인트 값과 일치해야 합니다.
선택적 Operator - 연산자는 키와 값 간의 관계를 나타냅니다. 유효한 연산자는
동일
하고존재합니다
. 기본값은동일합니다
. 키가 동일하고 효과가 동일할 때 허용 오차가 테인트와 일치하며 Operator는 다음 값 중 하나입니다.-
equal
- Operator가동일
하고 값은 테인트 및 허용 오차에서 동일합니다. -
exists
- 값의 와일드카드로, 배치가 특정 카테고리의 모든 테인트를 허용할 수 있습니다.
-
-
선택사항 Effect - 일치시킬 테인트 효과입니다. 비워 두면 모든 테인트 효과와 일치합니다. 지정된 경우 허용되는 값은
NoSelect
또는NoSelectIfNew
입니다. -
선택 사항 TolerationSeconds - 관리 클러스터를 새 배치로 이동하기 전에 허용 오차가 테인트를 허용하는 시간(초)입니다. 효과 값이
NoSelect
또는PreferNoSelect
가 아닌 경우 이 필드는 무시됩니다. 기본값은nil
로, 시간 제한이 없음을 나타냅니다.TolerationSeconds
의 계산 시작 시간은 클러스터 예약 시간 값 또는TolerationSeconds
추가 시간이 아닌 테인트의TimeAdded
값으로 자동으로 나열됩니다.
다음 예제에서는 테인트가 있는 클러스터를 허용하는 허용 오차를 구성하는 방법을 보여줍니다.
이 예에는 관리형 클러스터의 테인트가 있습니다.
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: gpu value: "true" timeAdded: '2022-02-21T08:11:06Z'
테인트를 허용할 수 있는 배치에 대한 허용 오차
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement1 namespace: default spec: tolerations: - key: gpu value: "true" operator: Equal
허용 오차 예제를 정의하면
key: gpu
및value: "true"
가 일치하므로 배치에서cluster1
을 선택할 수 있습니다.
참고: 관리형 클러스터는 테인트에 대한 허용 오차가 포함된 배치에 배치할 수 없습니다. 다른 배치에 동일한 허용 오차가 포함된 경우 관리형 클러스터가 해당 배치 중 하나에 배치될 수 있습니다.
1.5.11.4.4. 임시 허용 오차 지정
TolerationSeconds
값은 허용 오차가 테인트를 허용하는 기간을 지정합니다. 이 임시 허용 오차는 관리 클러스터가 오프라인 상태이고 허용되는 시간 동안 이 클러스터에 배포된 애플리케이션을 다른 관리형 클러스터로 전송할 수 있는 경우 유용할 수 있습니다.
예를 들어 다음 테인트가 있는 관리형 클러스터에 연결할 수 없게 됩니다.
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: cluster.open-cluster-management.io/unreachable timeAdded: '2022-02-21T08:11:06Z'
다음 예와 같이 TolerationSeconds
값을 사용하여 배치를 정의하는 경우 워크로드는 5분 후에 사용 가능한 다른 관리 클러스터로 전송됩니다.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: demo4 namespace: demo1 spec: tolerations: - key: cluster.open-cluster-management.io/unreachable operator: Exists tolerationSeconds: 300
관리 클러스터에 5분 동안 연결할 수 없는 후 애플리케이션을 다른 관리형 클러스터로 이동합니다.
1.5.11.5. ManagedClusterSet에서 관리형 클러스터 제거
관리형 클러스터 세트에서 관리 클러스터를 제거하여 다른 관리 클러스터 세트로 이동하거나 세트의 관리 설정에서 제거할 수 있습니다. 콘솔 또는 CLI를 사용하여 설정된 관리형 클러스터에서 관리형 클러스터를 제거할 수 있습니다.
참고: 관리되는 모든 클러스터는 관리형 클러스터 세트에 할당해야 합니다. ManagedClusterSet
에서 관리 클러스터를 제거하고 다른 ManagedClusterSet
에 할당하지 않으면 클러스터는 기본
관리 클러스터 세트에 자동으로 추가됩니다.
1.5.11.5.1. 콘솔을 사용하여 ManagedClusterSet에서 클러스터 제거
콘솔을 사용하여 설정한 관리형 클러스터에서 클러스터를 제거하려면 다음 단계를 완료합니다.
- Infrastructure > Clusters 를 클릭하고 클러스터 설정 탭이 선택되어 있는지 확인합니다.
- 클러스터 세트 세부 정보를 보려면 관리형 클러스터에서 제거할 클러스터 세트의 이름을 선택합니다.
- 작업 > 리소스 할당 관리를 선택합니다.
리소스 할당 관리 페이지에서 클러스터 세트에서 제거할 리소스의 확인란을 제거합니다.
이 단계에서는 이미 클러스터 세트의 멤버인 리소스를 제거합니다. 관리 클러스터의 세부 정보를 확인하여 리소스가 이미 클러스터 세트의 멤버인지 확인할 수 있습니다.
참고: 관리 대상 클러스터에서 다른 클러스터로 설정된 관리 클러스터를 이동하는 경우 두 관리 클러스터 세트에 대해 필요한 RBAC 권한이 있어야 합니다.
1.5.11.5.2. CLI를 사용하여 ManagedClusterSet에서 클러스터 제거
명령줄을 사용하여 설정된 관리형 클러스터에서 클러스터를 제거하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 관리형 클러스터 세트의 관리형 클러스터 목록을 표시합니다.
oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>
cluster_set
를 관리 클러스터 세트의 이름으로 교체합니다.- 제거할 클러스터의 항목을 찾습니다.
제거할 클러스터의 YAML 항목에서 레이블을 제거합니다. 레이블 예제는 다음 코드를 참조하십시오.
labels: cluster.open-cluster-management.io/clusterset: clusterset1
참고: 한 클러스터에서 다른 클러스터로 설정된 관리형 클러스터를 다른 클러스터로 이동하는 경우 두 관리 클러스터 세트 모두에 대해 필요한 RBAC 권한이 있어야 합니다.
1.5.12. 배치와 함께 ManagedClusterSets 사용
배치 리소스는 배치
네임스페이스에 바인딩된 ManagedClusterSets
에서 ManagedClusters
세트를 선택하는 규칙을 정의하는 네임스페이스 범위 리소스입니다.
필수 액세스: 클러스터 관리자, 클러스터 세트 관리자
1.5.12.1. 배치 개요
관리형 클러스터의 배치 작동 방식에 대한 다음 정보를 참조하십시오.
-
Kubernetes 클러스터는 클러스터 범위의
ManagedClusters
로 허브 클러스터에 등록됩니다. -
ManagedClusters
는 클러스터 범위ManagedClusterSets
로 구성됩니다. -
ManagedClusterSets
는 워크로드 네임스페이스에 바인딩됩니다. -
네임스페이스 범위
배치는 잠재적인
의 작업 세트를 선택하는ManagedClusters
ManagedClusterSets
의 일부를 지정합니다. -
배치는
라벨 및 클레임 선택기를 사용하여 설정된 관리 클러스터의ManagedClusters
를 필터링합니다. -
ManagedClusters
배치는 테인트 및 톨러레이션을 사용하여 제어할 수 있습니다. 자세한 내용은 테인트 및 허용 오차를 사용하여 관리 클러스터 배치를 참조하십시오. -
배치는 요구 사항에 따라 클러스터의
순위를 정하고 클러스터의 하위 집합을 선택합니다.
참고:
-
해당 네임스페이스에서
ManagedClusterSet
Binding -
managedclustersets/bind
의 가상 하위 리소스에서CREATE
에 대한 역할 기반 액세스가 필요합니다.
API에 대한 자세한 내용은 배치 API를 참조하십시오.
1.5.12.2. Deployment LabelSelector 및 ClaimSelector
labelSelector
를 사용하여ManagedClusters
를 선택할 수 있습니다.labelSelector
만 라벨공급 업체의 클러스터와 일치하는 다음 샘플을 참조하십시오. OpenShift :
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchLabels: vendor: OpenShift
claimSelector
를 사용하여ManagedClusters
를 선택할 수 있습니다.claimSelector
만region.open-cluster-management.io
와us-west-1
과 일치하는 다음 샘플을 참조하십시오.apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: predicates: - requiredClusterSelector: claimSelector: matchExpressions: - key: region.open-cluster-management.io operator: In values: - us-west-1
특정
clusterSets
에서ManagedClusters
를 선택할 수 있습니다.claimSelector
만clusterSets:
clusterset1
clusterset2
와 일치하는 다음 샘플을 참조하십시오.apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: clusterSets: - clusterset1 - clusterset2 predicates: - requiredClusterSelector: claimSelector: matchExpressions: - key: region.open-cluster-management.io operator: In values: - us-west-1
원하는 수의
ManagedClusters
를 선택합니다.numberOfClusters
가3
인 다음 샘플을 참조하십시오.apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: numberOfClusters: 3 predicates: - requiredClusterSelector: labelSelector: matchLabels: vendor: OpenShift claimSelector: matchExpressions: - key: region.open-cluster-management.io operator: In values: - us-west-1
1.5.12.3. 배치 허용
-
일치하는 테인트가 있는
ManagedClusters
를 선택합니다.
관리형 클러스터에 다음 예와 같이 테인트가 있다고 가정합니다.
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: gpu value: "true" timeAdded: '2022-02-21T08:11:06Z'
기본적으로 다음 예와 같이 허용 오차를 정의하지 않으면 배치에서 이 클러스터를 선택할 수 없습니다.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: tolerations: - key: gpu value: "true" operator: Equal
-
지정된 기간 동안 테인트가 일치하는
ManagedClusters
를 선택합니다.
TolerationSeconds
값은 허용 오차가 테인트를 허용하는 시간을 나타냅니다. 관리형 클러스터가 오프라인인 경우 사용자는 허용 오차가 부여된 후 다른 사용 가능한 관리 클러스터로 애플리케이션을 전송하도록 이 클러스터에 배포할 수 있습니다. TolerationSeconds
는 지정된 시간 후에 오프라인으로 전환되는 클러스터에 배포된 애플리케이션을 자동으로 전송할 수 있습니다.
예를 들어 다음 예제 콘텐츠에서 정의한 관리형 클러스터에 연결할 수 없습니다.
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: cluster.open-cluster-management.io/unreachable timeAdded: '2022-02-21T08:11:06Z'
다음 예에 표시된 대로 TolerationSeconds
를 사용하여 배치를 정의하면 워크로드가 5분 후에 사용 가능한 다른 관리 클러스터로 전송됩니다.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: tolerations: - key: cluster.open-cluster-management.io/unreachable operator: Exists tolerationSeconds: 300
1.5.12.4. placement PrioritizerPolicy
가장 큰 할당 가능 메모리가 있는 클러스터를 선택합니다.
참고: Kubernetes Node Allocatable 과 달리 '모든 할당 가능'은 각 클러스터의 Pod에 사용할 수 있는 컴퓨팅 리소스의 양으로 정의됩니다.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: numberOfClusters: 1 prioritizerPolicy: configurations: - scoreCoordinate: builtIn: ResourceAllocatableMemory
할당 가능한 가장 큰 CPU 및 메모리가 있는 클러스터를 선택하고 리소스 변경에 민감하게 배치합니다.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: numberOfClusters: 1 prioritizerPolicy: configurations: - scoreCoordinate: builtIn: ResourceAllocatableCPU weight: 2 - scoreCoordinate: builtIn: ResourceAllocatableMemory weight: 2
애드온
점수 CPU 비율이 가장 큰 두 클러스터를 선택하고 배치 결정을 고정합니다.apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement namespace: ns1 spec: numberOfClusters: 2 prioritizerPolicy: mode: Exact configurations: - scoreCoordinate: builtIn: Steady weight: 3 - scoreCoordinate: type: AddOn addOn: resourceName: default scoreName: cpuratio
1.5.12.5. 배치 결정
cluster.open-cluster-management.io/placement name}
레이블이 있는 하나 이상의
를 나타냅니다.
Placement
Decision s
가 생성되어 배치에서 선택한 ManagedCluster
ManagedCluster
를 선택하고
에 추가하면 이 배치를 사용하는 구성 요소가 이 Placement
DecisionManagedCluster
에 워크로드를 적용할 수 있습니다. ManagedCluster
가 더 이상 선택되지 않고 PlacementDecisions
에서 제거된 후 이 ManagedCluster
에 적용되는 워크로드를 제거해야 합니다.
API에 대한 자세한 내용은 PlacementDecisions API 를 참조하십시오.
다음 PlacementDecision
샘플을 참조하십시오.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: PlacementDecision metadata: labels: cluster.open-cluster-management.io/placement: placement1 name: placement1-kbc7q namespace: ns1 ownerReferences: - apiVersion: cluster.open-cluster-management.io/v1beta1 blockOwnerDeletion: true controller: true kind: Placement name: placement1 uid: 05441cf6-2543-4ecc-8389-1079b42fe63e status: decisions: - clusterName: cluster1 reason: '' - clusterName: cluster2 reason: '' - clusterName: cluster3 reason: ''
1.5.12.6. 애드온 상태
배포된 애드온의 상태에 따라 배치에 사용할 관리 클러스터를 선택할 수 있습니다. 예를 들어 클러스터에 활성화된 특정 추가 기능이 있는 경우에만 배치용으로 관리 클러스터를 선택하려고 합니다.
배치를 생성할 때 애드온의 라벨과 해당 상태를 지정합니다. 클러스터에서 애드온이 활성화된 경우 ManagedCluster
리소스에 레이블이 자동으로 생성됩니다. 애드온이 비활성화된 경우 라벨이 자동으로 제거됩니다.
각 애드온은 feature.open-cluster-management.io/addon-<addon-<addon_name>=<status_of_addon
> 형식의 레이블로 표시됩니다.
addon_name
을 선택할 관리 클러스터에서 활성화해야 하는 애드온의 이름으로 바꿉니다.
클러스터를 선택한 경우 status_of_addon
을 애드온에 보유해야 하는 상태로 교체합니다. status_of_addon
의 가능한 값은 다음 목록에 있습니다.
-
사용 가능
: 애드온이 활성화되어 사용 가능합니다. -
비정상
: 애드온이 활성화되어 있지만 리스가 지속적으로 업데이트되지 않습니다. -
unreachable
: 애드온이 활성화되어 있지만 리스가 없습니다. 이는 관리 클러스터가 오프라인 상태일 때도 발생할 수 있습니다.
예를 들어 사용 가능한 application-manager
애드온은 다음과 같은 관리 대상 클러스터의 레이블로 표시됩니다.
feature.open-cluster-management.io/addon-application-manager: available
애드온 및 해당 상태를 기반으로 배치를 생성하는 다음 예제를 참조하십시오.
다음 YAML 콘텐츠를 추가하여
application-manager
가 활성화된 모든 관리 클러스터를 포함하는 배치를 생성할 수 있습니다.apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement1 namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: - key: feature.open-cluster-management.io/addon-application-manager operator: Exists
다음 YAML 콘텐츠를 추가하여
application-manager
가사용 가능한
상태로 활성화된 모든 관리 클러스터를 포함하는 배치를 생성할 수 있습니다.apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement2 namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchLabels: "feature.open-cluster-management.io/addon-application-manager": "available"
다음 YAML 콘텐츠를 추가하여
application-manager
가 비활성화된 모든 관리 클러스터를 포함하는 배치를 생성할 수 있습니다.apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement3 namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: - key: feature.open-cluster-management.io/addon-application-manager operator: DoesNotExist
1.5.13. 클러스터 풀 관리 (기술 프리뷰)
클러스터 풀은 필요에 따라 구성된 Red Hat OpenShift Container Platform 클러스터에 신속하고 비용 효율적인 액세스를 제공합니다. 클러스터 풀은 필요할 때 요청할 수 있는 Amazon Web Services, Google Cloud Platform 또는 Microsoft Azure에서 구성 가능하고 확장 가능한 수의 OpenShift Container Platform 클러스터를 프로비저닝합니다. 개발, 지속적 통합 및 프로덕션 시나리오를 위해 클러스터 환경을 제공하거나 교체할 때 특히 유용합니다. 실행을 유지할 여러 클러스터를 지정할 수 있으며, 클러스터의 나머지는 몇 분 내에 다시 시작하고 요청할 수 있도록 클러스터의 나머지 부분을 하향식 상태로 유지할 수 있습니다.
ClusterClaim
리소스는 클러스터 풀에서 클러스터를 확인하는 데 사용됩니다. 클러스터 클레임이 생성되면 풀에서 실행 중인 클러스터를 할당합니다. 실행 중인 클러스터를 사용할 수 없는 경우 클러스터를 제공하기 위해 하이버네이션 클러스터가 다시 시작되거나 새 클러스터가 프로비저닝됩니다. 클러스터 풀은 새 클러스터를 자동으로 생성하고 계층화 클러스터를 다시 시작하여 풀에서 지정된 크기와 사용 가능한 실행 클러스터 수를 유지합니다.
클러스터 풀을 생성하는 절차는 클러스터를 생성하는 절차와 유사합니다. 클러스터 풀의 클러스터는 즉시 사용할 수 있도록 생성되지 않습니다.
1.5.13.1. 클러스터 풀 생성
클러스터 풀을 생성하는 절차는 클러스터를 생성하는 절차와 유사합니다. 클러스터 풀의 클러스터는 즉시 사용할 수 있도록 생성되지 않습니다.
필수 액세스: 관리자
1.5.13.1.1. 사전 요구 사항
클러스터 풀을 생성하기 전에 다음 사전 요구 사항을 참조하십시오.
- 다중 클러스터 엔진 Operator hub 클러스터를 배포해야 합니다.
- 공급자 환경에서 Kubernetes 클러스터를 생성할 수 있도록 다중 클러스터 엔진 운영자 허브 클러스터의 인터넷 액세스가 필요합니다.
- AWS, GCP 또는 Microsoft Azure 공급자 인증 정보가 필요합니다. 자세한 내용은 인증 정보 관리 개요 를 참조하십시오.
- 공급자 환경에 구성된 도메인이 필요합니다. 도메인을 구성하는 방법에 대한 자세한 내용은 공급자 설명서를 참조하십시오.
- 공급자 로그인 자격 증명이 필요합니다.
- OpenShift Container Platform 이미지 풀 시크릿이 필요합니다. 이미지 풀 시크릿 사용을 참조하십시오.
참고: 이 절차를 사용하여 클러스터 풀을 추가하면 풀에서 클러스터를 요청할 때 다중 클러스터 엔진 Operator가 관리할 클러스터를 자동으로 가져올 수 있습니다. 클러스터 클레임을 사용하여 관리하기 위해 클레임된 클러스터를 자동으로 가져오지 않는 클러스터 풀을 생성하려면 clusterClaim
리소스에 다음 주석을 추가합니다.
kind: ClusterClaim metadata: annotations: cluster.open-cluster-management.io/createmanagedcluster: "false"
"false"
라는 단어는 문자열임을 나타내기 위해 따옴표로 묶어야 합니다.
1.5.13.1.2. 클러스터 풀 생성
클러스터 풀을 생성하려면 탐색 메뉴에서 인프라 > 클러스터를 선택합니다. 클러스터 풀 탭에는 액세스할 수 있는 클러스터 풀이 나열됩니다. Create cluster pool 을 선택하고 콘솔의 단계를 완료합니다.
클러스터 풀에 사용하려는 인프라 인증 정보가 없는 경우 인증 정보 추가 를 선택하여 생성합니다.
목록에서 기존 네임스페이스를 선택하거나 생성할 새 네임스페이스의 이름을 입력할 수 있습니다. 클러스터 풀은 클러스터와 동일한 네임스페이스에 있을 필요가 없습니다.
클러스터 풀의 RBAC 역할을 기존 클러스터 세트의 역할 할당을 공유하도록 하려면 클러스터 세트 이름을 선택할 수 있습니다. 클러스터 풀의 클러스터에 대한 클러스터 세트는 클러스터 풀을 생성할 때만 설정할 수 있습니다. 클러스터 풀을 생성한 후에는 클러스터 풀 또는 클러스터 풀의 클러스터에 대한 클러스터 세트 연결을 변경할 수 없습니다. 클러스터 풀에서 요청하는 클러스터는 클러스터 풀과 동일한 클러스터에 자동으로 추가됩니다.
참고: 클러스터 관리자
권한이 없는 경우 클러스터 세트를 선택해야 합니다. 이 경우 클러스터 세트 이름을 포함하지 않으면 클러스터 세트 생성 요청이 금지된 오류로 인해 거부됩니다. 선택할 수 있는 클러스터 세트가 없는 경우 클러스터 관리자에게 문의하여 클러스터 세트를 생성하고 클러스터 세트 관리자
권한을 부여합니다.
클러스터 풀 크기는
클러스터 풀에서 프로비저닝할 클러스터 수를 지정하는 반면, 실행 중인 클러스터 풀은 풀이 계속 실행되고 즉시 사용할 것을 요청할 수 있는 클러스터 수를 지정합니다.
절차는 클러스터 생성 절차와 매우 유사합니다.
공급자에 필요한 정보에 대한 자세한 내용은 다음 정보를 참조하십시오.
1.5.13.2. 클러스터 풀에서 클러스터 요청
ClusterClaim
리소스는 클러스터 풀에서 클러스터를 확인하는 데 사용됩니다. 클러스터가 실행 중이고 클러스터 풀에서 준비되면 클레임이 완료됩니다. 클러스터 풀은 클러스터 풀에 지정된 요구 사항을 유지하기 위해 클러스터 풀에 실행 중인 새 클러스터를 자동으로 생성합니다.
참고: 클러스터 풀에서 요청한 클러스터가 더 이상 필요하지 않고 삭제되면 리소스가 삭제됩니다. 클러스터가 클러스터 풀로 돌아가지 않습니다.
필수 액세스: 관리자
1.5.13.2.1. 사전 요구 사항
클러스터 풀에서 클러스터를 요청하기 전에 다음을 사용할 수 있어야 합니다.
사용 가능한 클러스터가 있거나 없는 클러스터 풀입니다. 클러스터 풀에 사용 가능한 클러스터가 있는 경우 사용 가능한 클러스터가 요청됩니다. 클러스터 풀에 사용 가능한 클러스터가 없는 경우 클레임을 충족하기 위해 클러스터가 생성됩니다. 클러스터 풀을 생성하는 방법에 대한 자세한 내용은 클러스터 풀 생성을 참조하십시오.
1.5.13.2.2. 클러스터 풀에서 클러스터 클레임
클러스터 클레임을 생성할 때 클러스터 풀에서 새 클러스터를 요청합니다. 클러스터를 사용할 수 있는 경우 클러스터에서 풀에서 확인합니다. 자동 가져오기를 비활성화하지 않는 한 클레임된 클러스터는 관리 클러스터 중 하나로 자동으로 가져옵니다.
클러스터를 요청하려면 다음 단계를 완료합니다.
- 탐색 메뉴에서 인프라 > 클러스터를 클릭하고 클러스터 풀 탭을 선택합니다.
- 클러스터를 클레임할 클러스터 풀의 이름을 찾아 클레임 클러스터를 선택합니다.
클러스터를 사용할 수 있는 경우 요청되고 Managed 클러스터 탭에 즉시 표시됩니다. 사용 가능한 클러스터가 없는 경우 클러스터를 다시 시작하거나 새 클러스터를 프로비저닝하는 데 몇 분이 걸릴 수 있습니다. 이 기간 동안 클레임 상태는 보류
중입니다. 클러스터 풀을 확장하여 보류 중인 클레임을 보거나 삭제합니다.
클레임된 클러스터는 클러스터 풀에 있을 때 연결된 클러스터 세트의 멤버로 유지됩니다. 클레임할 때 클레임된 클러스터의 클러스터 세트를 변경할 수 없습니다.
참고: 클라우드 공급자 인증 정보의 풀 시크릿, SSH 키 또는 기본 도메인의 변경 사항은 원래 인증 정보를 사용하여 이미 프로비저닝되었기 때문에 클러스터 풀에서 요청하는 기존 클러스터에 반영되지 않습니다. 콘솔을 사용하여 클러스터 풀 정보를 편집할 수는 없지만 CLI 인터페이스를 사용하여 정보를 업데이트하여 업데이트할 수 있습니다. 업데이트된 정보가 포함된 인증 정보를 사용하여 새 클러스터 풀을 생성할 수도 있습니다. 새 풀에 생성된 클러스터는 새 인증 정보에 제공된 설정을 사용합니다.
1.5.13.3. 클러스터 풀 릴리스 이미지 업데이트
클러스터 풀의 클러스터가 잠시 동안 정지 상태로 남아 있으면 클러스터의 Red Hat OpenShift Container Platform 릴리스 이미지가 역순 상태가 될 수 있습니다. 이 경우 클러스터 풀에 있는 클러스터의 릴리스 이미지 버전을 업그레이드할 수 있습니다.
필수 액세스: 편집
클러스터 풀의 클러스터의 OpenShift Container Platform 릴리스 이미지를 업데이트하려면 다음 단계를 완료합니다.
참고: 이 절차에서는 클러스터 풀에 이미 클레임된 클러스터 풀에서 클러스터를 업데이트하지 않습니다. 이 절차를 완료하면 릴리스 이미지에 대한 업데이트는 클러스터 풀과 관련된 다음 클러스터에만 적용됩니다.
- 이 절차로 릴리스 이미지를 업데이트한 후 클러스터 풀에서 생성한 클러스터입니다.
- 클러스터 풀에서 계층화된 클러스터입니다. 이전 릴리스 이미지가 있는 기존의 계층 구조 클러스터가 제거되고 새 릴리스 이미지가 있는 새 클러스터가 교체됩니다.
- 탐색 메뉴에서 인프라 > 클러스터를 클릭합니다.
- 클러스터 풀 탭을 선택합니다.
- 클러스터 풀 표에서 업데이트할 클러스터 풀의 이름을 찾습니다.
- 표에서 클러스터 풀 의 옵션 메뉴를 클릭하고 릴리스 이미지 업데이트를 선택합니다.
- 이 클러스터 풀에서 향후 클러스터 생성에 사용할 새 릴리스 이미지를 선택합니다.
클러스터 풀 릴리스 이미지가 업데이트되었습니다.
팁: 클러스터 풀 각각에 대한 상자를 선택하고 작업 메뉴를 사용하여 선택한 클러스터 풀의 릴리스 이미지를 업데이트하여 여러 클러스터 풀의 릴리스 이미지를 업데이트할 수 있습니다.
1.5.13.4. 클러스터 풀 스케일링 (기술 프리뷰)
클러스터 풀 크기의 클러스터 수를 늘리거나 줄여 클러스터 풀의 클러스터 수를 변경할 수 있습니다.
필수 액세스: 클러스터 관리자
클러스터 풀의 클러스터 수를 변경하려면 다음 단계를 완료합니다.
- 탐색 메뉴에서 인프라 > 클러스터를 클릭합니다.
- 클러스터 풀 탭을 선택합니다.
- 변경할 클러스터 풀의 옵션 메뉴에서 스케일링 클러스터 풀 을 선택합니다.
- 풀 크기의 값을 변경합니다.
- 필요한 경우 실행 중인 클러스터의 수를 업데이트하여 클레임할 때 즉시 사용 가능한 클러스터 수를 늘리거나 줄일 수 있습니다.
새 값을 반영하도록 클러스터 풀이 확장됩니다.
1.5.13.5. 클러스터 풀 삭제
클러스터 풀을 생성하고 더 이상 필요하지 않다고 결정하는 경우 클러스터 풀을 제거할 수 있습니다. 클러스터 풀을 삭제하면 승인되지 않은 하버네이션 클러스터가 모두 제거되고 해당 리소스가 해제됩니다.
필수 액세스: 클러스터 관리자
클러스터 풀을 삭제하려면 다음 단계를 완료합니다.
- 탐색 메뉴에서 인프라 > 클러스터를 클릭합니다.
- 클러스터 풀 탭을 선택합니다.
삭제할 클러스터 풀의 옵션 메뉴에서 Destroy 클러스터 풀 삭제를 선택합니다. 클러스터 풀에서 처리되지 않은 클러스터는 모두 삭제됩니다. 모든 리소스를 삭제하는 데 시간이 걸릴 수 있으며 모든 리소스가 삭제될 때까지 클러스터 풀이 콘솔에 계속 표시됩니다.
ClusterPool이 포함된 네임스페이스는 삭제되지 않습니다. 이러한 클러스터의 ClusterClaim 리소스가 동일한 네임스페이스에 생성되므로 네임스페이스를 삭제하면 ClusterPool에서 요청한 모든 클러스터가 제거됩니다.
팁: 클러스터 풀 각각에 대한 상자를 선택하고 작업 메뉴를 사용하여 선택한 클러스터 풀을 제거함으로써 하나의 작업으로 여러 클러스터 풀을 제거할 수 있습니다.
1.5.14. ManagedServiceAccount 애드온 활성화 (기술 프리뷰)
다중 클러스터 엔진 Operator를 설치하면 ManagedServiceAccount
애드온이 기본적으로 비활성화되어 있습니다. 이 구성 요소를 활성화하면 관리형 클러스터에서 서비스 계정을 생성하거나 삭제할 수 있습니다.
필수 액세스: 편집기
hub 클러스터의 < managed_cluster
> 네임스페이스에 ManagedServiceAccount
사용자 지정 리소스가 생성되면 관리 클러스터에서 ServiceAccount
가 생성됩니다.
TokenRequest
는 관리 클러스터의 ServiceAccount
를 사용하여 관리 클러스터의 Kubernetes API 서버에 대해 수행됩니다. 그런 다음 토큰은 hub 클러스터의 < target_managed_cluster>
네임스페이스의 Secret
에 저장됩니다.
참고: 토큰이 만료되고 순환될 수 있습니다. 토큰 요청에 대한 자세한 내용은 TokenRequest 를 참조하십시오.
1.5.14.1. 사전 요구 사항
- Red Hat OpenShift Container Platform 버전 4.11 이상은 사용자 환경에 배포해야 하며 CLI(명령줄 인터페이스)로 로그인해야 합니다.
- 다중 클러스터 엔진 Operator가 설치되어 있어야 합니다.
1.5.14.2. Enabling ManagedServiceAccount
hub 클러스터 및 관리 클러스터에 Managed-ServiceAccount
애드온을 활성화하려면 다음 단계를 완료하십시오.
-
hub 클러스터에서
ManagedServiceAccount
애드온을 활성화합니다. 자세한 내용은 고급 구성을 참조하십시오. ManagedServiceAccount
애드온을 배포하고 대상 관리 클러스터에 적용합니다. 다음 YAML 파일을 생성하고target_managed_cluster
를Managed-ServiceAccount
애드온을 적용하는 관리 클러스터의 이름으로 교체합니다.apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: managed-serviceaccount namespace: <target_managed_cluster> spec: installNamespace: open-cluster-management-agent-addon
다음 명령을 실행하여 파일을 적용합니다.
oc apply -f -
이제 관리형 클러스터의
Managed-ServiceAccount
플러그인을 활성화했습니다.ManagedServiceAccount
를 구성하려면 다음 단계를 참조하십시오.다음 YAML 소스를 사용하여
ManagedServiceAccount
사용자 정의 리소스를 생성합니다.apiVersion: authentication.open-cluster-management.io/v1alpha1 kind: ManagedServiceAccount metadata: name: <managed_serviceaccount_name> namespace: <target_managed_cluster> spec: rotation: {}
-
managed_serviceaccount_name
을ManagedServiceAccount
의 이름으로 교체합니다. -
target_managed_cluster
를ManagedServiceAccount
를 적용하는 관리 클러스터의 이름으로 교체합니다.
-
확인하려면
ManagedServiceAccount
오브젝트 상태에서tokenSecretRef
특성을 보고 시크릿 이름과 네임스페이스를 찾습니다. 계정 및 클러스터 이름을 사용하여 다음 명령을 실행합니다.oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
관리 클러스터에서 생성된
ServiceAccount
에 연결된 검색된 토큰이 포함된 보안을 확인합니다.다음 명령을 실행합니다.
oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
1.5.15. 클러스터 업그레이드
멀티 클러스터 엔진 Operator로 관리하려는 Red Hat OpenShift Container Platform 클러스터를 생성한 후 다중 클러스터 엔진 Operator 콘솔을 사용하여 해당 클러스터를 관리형 클러스터가 사용하는 버전 채널에서 사용할 수 있는 최신 마이너 버전으로 업그레이드할 수 있습니다.
연결된 환경에서 업데이트는 Red Hat Advanced Cluster Management 콘솔에서 업그레이드해야 하는 각 클러스터에 대해 제공되는 알림으로 자동 식별됩니다.
참고:
주요 버전으로 업그레이드하려면 해당 버전으로 업그레이드하기 위한 모든 사전 요구 사항을 충족하는지 확인해야 합니다. 콘솔을 사용하여 클러스터를 업그레이드하기 전에 관리형 클러스터에서 버전 채널을 업데이트해야 합니다.
관리 클러스터에서 버전 채널을 업데이트한 후 다중 클러스터 엔진 Operator 콘솔에 업그레이드에 사용 가능한 최신 버전이 표시됩니다.
이 업그레이드 방법은 Ready 상태인 OpenShift Container Platform 관리 클러스터에서만 작동합니다.
중요: 다중 클러스터 엔진 Operator 콘솔을 사용하여 Red Hat OpenShift Kubernetes Service 관리 클러스터 또는 OpenShift Container Platform 관리 클러스터를 Red Hat OpenShift Dedicated에서 업그레이드할 수 없습니다.
연결된 환경에서 클러스터를 업그레이드하려면 다음 단계를 완료합니다.
- 탐색 메뉴에서 인프라 > ; 클러스터로 이동합니다. 업그레이드를 사용할 수 있는 경우 배포 버전 열에 표시됩니다.
- 업그레이드하려는 Ready 상태에서 클러스터를 선택합니다. 콘솔을 사용하여 업그레이드하려면 클러스터가 OpenShift Container Platform 클러스터여야 합니다.
- 업그레이드를 선택합니다.
- 각 클러스터의 새 버전을 선택합니다.
- 업그레이드를 선택합니다.
클러스터 업그레이드가 실패하면 Operator는 일반적으로 업그레이드를 몇 번 재시도하고 중지한 후 실패한 구성 요소의 상태를 보고합니다. 경우에 따라 업그레이드 프로세스가 프로세스를 완료하기 위한 시도로 계속 순환됩니다. 실패한 업그레이드 후 클러스터를 이전 버전으로 롤백하는 것은 지원되지 않습니다. 클러스터 업그레이드가 실패하는 경우 Red Hat 지원에 문의하십시오.
1.5.15.1. 채널 선택
Red Hat Advanced Cluster Management 콘솔을 사용하여 OpenShift Container Platform 버전 4.6 이상에서 클러스터 업그레이드 채널을 선택할 수 있습니다. 채널을 선택하면 에라타 버전 (4.8.1 > 4.8.2 > 4.8.3 등)과 릴리스 버전 (4.8 > 4.9 등) 모두에서 사용할 수 있는 클러스터 업그레이드를 자동으로 상기시킵니다.
클러스터 채널을 선택하려면 다음 단계를 완료합니다.
- Red Hat Advanced Cluster Management 탐색에서 인프라 > 클러스터를 선택합니다.
- 클러스터 세부 정보 페이지를 보려면 변경할 클러스터 이름을 선택합니다. 클러스터에 다른 채널을 사용할 수 있는 경우 채널 필드에 편집 아이콘이 표시됩니다.
- 편집 아이콘을 클릭하여 필드의 설정을 수정합니다.
- 새 채널 필드에서 채널을 선택합니다.
클러스터의 클러스터 세부 정보 페이지에서 사용 가능한 채널 업데이트에 대한 알림을 확인할 수 있습니다.
1.5.16. 관리에서 클러스터 제거
다중 클러스터 엔진 Operator를 사용하여 생성된 관리에서 OpenShift Container Platform 클러스터를 제거하면 이를 분리 하거나 삭제 할 수 있습니다. 클러스터를 분리하면 관리에서 제거되지만 완전히 삭제되지는 않습니다. 관리하려는 경우 다시 가져올 수 있습니다. 이는 클러스터가 Ready 상태인 경우에만 옵션입니다.
다음 절차에서는 다음 상황 중 하나에서 클러스터를 제거합니다.
- 이미 클러스터를 삭제하고 Red Hat Advanced Cluster Management에서 삭제된 클러스터를 삭제하려고 합니다.
- 관리에서 클러스터를 제거하려고 하지만 클러스터를 삭제하지 않았습니다.
중요:
- 클러스터를 삭제하면 관리에서 클러스터가 제거되고 클러스터의 구성 요소가 삭제됩니다.
관리형 클러스터를 분리하면 관련 네임스페이스가 자동으로 삭제됩니다. 이 네임스페이스에 사용자 정의 리소스를 배치하지 마십시오.
1.5.16.1. 콘솔을 사용하여 클러스터 제거
탐색 메뉴에서 Infrastructure > Clusters 로 이동하여 관리에서 삭제하려는 클러스터 옆에 있는 옵션 메뉴 옆에 있는 클러스터의 Destroy cluster 또는 Detach 클러스터를 선택합니다.
+ 팁: 분리 또는 제거하려는 클러스터의 확인란을 선택하고 Detach 또는 Destroy 를 선택하여 여러 클러스터를 분리하거나 제거할 수 있습니다.
참고: 로컬
클러스터라고 하는 동안 hub 클러스터를 분리하려고 하면 disableHubSelfManagement
의 기본 설정이 false
인지 확인하십시오. 이 설정을 사용하면 hub 클러스터가 분리될 때 자체적으로 다시 가져오고 자체적으로 관리되며 MultiClusterHub
컨트롤러를 조정합니다. 허브 클러스터가 분리 프로세스를 완료하고 다시 가져오는 데 시간이 걸릴 수 있습니다.
프로세스가 완료될 때까지 기다리지 않고 hub 클러스터를 다시 가져오려면 다음 명령을 입력하여 multiclusterhub-operator
Pod를 다시 시작하고 더 빨리 다시 가져올 수 있습니다.
oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`
온라인 상태에서 설치 시 설명된 대로 disableHubSelfManagement
값을 true
로 변경하여 hub 클러스터의 값을 자동으로 가져오지 않도록 변경할 수 있습니다.
1.5.16.2. 명령줄을 사용하여 클러스터 제거
hub 클러스터의 명령줄을 사용하여 관리형 클러스터를 분리하려면 다음 명령을 실행합니다.
oc delete managedcluster $CLUSTER_NAME
분리 후 관리형 클러스터를 삭제하려면 다음 명령을 실행합니다.
oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME
참고: local-cluster
라는 hub 클러스터를 분리하려고 하면 disableHubSelfManagement
의 기본 설정은 false
입니다. 이 설정을 사용하면 허브 클러스터가 분리될 때 자체적으로 다시 가져오고 자체적으로 관리되고 MultiClusterHub
컨트롤러를 조정합니다. 허브 클러스터가 분리 프로세스를 완료하고 다시 가져오는 데 시간이 걸릴 수 있습니다. 프로세스가 완료될 때까지 기다리지 않고 hub 클러스터를 다시 가져오려면 다음 명령을 입력하여 multiclusterhub-operator
Pod를 재시작하고 더 빨리 다시 가져올 수 있습니다.
oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`
온라인 상태에서 설치 시 설명된 대로 disableHubSelfManagement
값을 true
로 변경하여 hub 클러스터의 값을 자동으로 가져오지 않도록 변경할 수 있습니다.
1.5.16.3. 클러스터를 제거한 후 나머지 리소스 제거
제거한 관리형 클러스터에 나머지 리소스가 있는 경우 나머지 구성 요소를 모두 제거하는 데 필요한 추가 단계가 있습니다. 이러한 추가 단계가 필요한 경우 다음 예제를 포함합니다.
-
관리 클러스터는 완전히 생성되기 전에 분리되었으며
klusterlet
과 같은 구성 요소는 관리형 클러스터에 남아 있습니다. - 관리형 클러스터를 분리하기 전에 클러스터를 관리하는 허브가 손실되거나 삭제되었으며 관리 대상 클러스터를 허브에서 분리할 수 없습니다.
- 관리 클러스터는 분리될 때 온라인 상태가 아닙니다.
이러한 상황 중 하나가 관리형 클러스터의 시도된 분리에 적용되는 경우 관리 클러스터에서 제거할 수 없는 일부 리소스가 있습니다. 관리형 클러스터를 분리하려면 다음 단계를 완료합니다.
-
oc
명령행 인터페이스가 구성되어 있는지 확인합니다. 관리 클러스터에
KUBECONFIG
가 구성되어 있는지 확인합니다.oc get ns | grep open-cluster-management-agent
를 실행하는 경우 두 개의 네임스페이스가 표시됩니다.open-cluster-management-agent Active 10m open-cluster-management-agent-addon Active 10m
나머지 리소스를 제거하려면 다음 명령을 실행합니다.
oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'
다음 명령을 실행하여 네임스페이스와 모든 열린 클러스터 관리 CR이 모두 제거되었는지 확인합니다.
oc get crds | grep open-cluster-management.io | awk '{print $1}' oc get ns | grep open-cluster-management-agent
1.5.16.4. 클러스터를 제거한 후 etcd 데이터베이스 조각 모음
많은 관리형 클러스터가 있으면 hub 클러스터의 etcd
데이터베이스 크기에 영향을 미칠 수 있습니다. OpenShift Container Platform 4.8에서는 관리형 클러스터를 삭제하면 hub 클러스터의 etcd
데이터베이스 크기가 자동으로 줄어들지 않습니다. 일부 시나리오에서는 etcd
데이터베이스가 공간이 부족해질 수 있습니다. etcdserver: mvcc: 데이터베이스 공간이 초과된
오류가 표시됩니다. 이 오류를 수정하려면 데이터베이스 기록을 압축하고 etcd
데이터베이스를 조각 모음하여 etcd
데이터베이스의 크기를 줄입니다.
참고: OpenShift Container Platform 버전 4.9 이상에서는 etcd Operator가 디스크를 자동으로 조각 모음하고 etcd
기록을 압축합니다. 수동 조작이 필요하지 않습니다. 다음 절차는 OpenShift Container Platform 버전 4.8 및 이전 버전에 적용됩니다.
다음 절차를 완료하여 etcd
기록을 압축하고 hub 클러스터에서 etcd
데이터베이스 조각 모음을 풉니다.
1.5.16.4.1. 사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
1.5.16.4.2. 절차
etcd
기록을 압축합니다.etcd
멤버에 대한 원격 쉘 세션을 엽니다. 예를 들면 다음과 같습니다.$ oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table
다음 명령을 실행하여
etcd
기록을 압축하십시오.sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)
출력 예
$ compacted revision 158774421
-
etcd
데이터베이스 조각 모음 및etcd
데이터 조각 모음 에 설명된 대로NOSPACE
경고를 지웁니다.
1.6. Discovery 서비스 소개
OpenShift Cluster Manager 에서 사용할 수 있는 OpenShift 4 클러스터를 검색할 수 있습니다. 검색 후 관리할 클러스터를 가져올 수 있습니다. Discovery 서비스는 백엔드 및 콘솔 사용에 Discover Operator를 사용합니다.
OpenShift Cluster Manager 인증 정보가 있어야 합니다. 인증 정보를 생성해야 하는 경우 Red Hat OpenShift Cluster Manager에 대한 인증 정보 생성을 참조하십시오.
필수 액세스: 관리자
1.6.1. 콘솔을 사용하여 Discovery 구성
제품 콘솔을 사용하여 Discovery를 활성화합니다.
필수 액세스: 인증 정보가 생성된 네임스페이스에 액세스합니다.
1.6.1.1. 사전 요구 사항
- 인증 정보가 필요합니다. OpenShift Cluster Manager 에 연결할 Red Hat OpenShift Cluster Manager에 대한 인증 정보 생성을 참조하십시오.
1.6.1.2. Discovery 구성
클러스터를 찾도록 콘솔에서 Discovery를 구성합니다. 별도의 인증 정보를 사용하여 여러 DiscoveryConfig
리소스를 생성할 수 있습니다. 콘솔의 지침을 따르십시오.
1.6.1.3. 검색된 클러스터 보기
인증 정보를 설정하고 가져올 클러스터를 검색한 후 콘솔에서 해당 인증서를 볼 수 있습니다.
- 클러스터 > 검색된 클러스터를클릭합니다.
다음 정보를 사용하여 채워진 테이블을 확인합니다.
- name 은 OpenShift Cluster Manager에서 지정된 표시 이름입니다. 클러스터에 표시 이름이 없으면 클러스터 콘솔 URL을 기반으로 생성된 이름이 표시됩니다. 콘솔 URL이 없거나 OpenShift Cluster Manager에서 수동으로 수정된 경우 클러스터 외부 ID가 표시됩니다.
- namespace 는 인증 정보 및 검색된 클러스터를 생성한 네임스페이스입니다.
- type 은 검색된 클러스터 Red Hat OpenShift 유형입니다.
- 배포 버전 은 검색된 클러스터 Red Hat OpenShift 버전입니다.
- 인프라 공급자는 검색된 클러스터의 클라우드 공급자입니다.
- 마지막 활성 은 검색된 클러스터가 활성화된 마지막 시간입니다.
- 검색된 클러스터가 생성될 때 생성됩니다.
- 검색된 클러스터가 검색될 때 검색됩니다.
- 테이블에서도 모든 정보를 검색할 수 있습니다. 예를 들어 특정 네임스페이스에 검색된 클러스터 만 표시하려면 해당 네임스페이스를 검색합니다.
- 이제 클러스터 가져오기를 클릭하여 관리 클러스터를 생성할 수 있습니다. 검색된 클러스터 가져오기 를 참조하십시오.
1.6.1.4. 검색된 클러스터 가져오기
클러스터를 검색한 후 콘솔의 Discovered 클러스터 탭에 표시되는 클러스터를 가져올 수 있습니다.
1.6.1.5. 사전 요구 사항
Discovery를 구성하는 데 사용된 네임스페이스에 액세스해야 합니다.
1.6.1.6. 검색된 클러스터 가져오기
- 기존 클러스터 페이지로 이동하여 Discovered 클러스터 탭을 클릭합니다.
- Discovered 클러스터 표에서 가져올 클러스터를 찾습니다.
- 옵션 메뉴에서 클러스터 가져오기 를 선택합니다.
- 검색된 클러스터의 경우 문서를 사용하여 수동으로 가져오거나 클러스터 가져오기를 자동으로 선택할 수 있습니다.
- 인증 정보 또는 Kubeconfig 파일을 사용하여 자동으로 가져오려면 콘텐츠를 복사하여 붙여넣습니다.
- Import 를 클릭합니다.
1.6.2. CLI를 사용하여 Discovery 활성화
CLI를 사용하여 검색을 활성화하여 Red Hat OpenShift Cluster Manager에서 사용할 수 있는 클러스터를 찾습니다.
필수 액세스: 관리자
1.6.2.1. 사전 요구 사항
- Red Hat OpenShift Cluster Manager에 연결할 자격 증명을 만듭니다.
1.6.2.2. Discovery 설정 및 프로세스
참고: DiscoveryConfig
의 이름은 discovery
여야 하며 선택한 인증
정보와 동일한 네임스페이스에 생성해야 합니다. 다음 DiscoveryConfig
샘플을 참조하십시오.
apiVersion: discovery.open-cluster-management.io/v1 kind: DiscoveryConfig metadata: name: discovery namespace: <NAMESPACE_NAME> spec: credential: <SECRET_NAME> filters: lastActive: 7 openshiftVersions: - "4.10" - "4.11" - "4.8"
-
SECRET_NAME
을 이전에 설정한 자격 증명으로 바꿉니다. -
NAMESPACE_NAME
을SECRET_NAME
의 네임스페이스로 바꿉니다. -
검색할 클러스터의 마지막 활동(일) 이후의 최대 시간을 입력합니다. 예를 들어
lastActive: 7
을 사용하면 지난 7일 동안 활성화된 클러스터가 검색됩니다. -
검색할 Red Hat OpenShift 클러스터 버전을 문자열 목록으로 입력합니다. 참고:
openshiftVersions
목록의 모든 항목은 OpenShift 주 및 부 버전을 지정합니다. 예를 들어"4.11"
을 지정하면 OpenShift 버전4.11
의 모든 패치 릴리스 (예:4.11.1
,4.11.2)가 포함됩니다
.
1.6.2.3. 검색된 클러스터 보기
oc get discoveredclusters -n <namespace
>를 실행하여 검색된 클러스터를 확인합니다. 여기서 namespace
는 검색 인증 정보가 존재하는 네임스페이스입니다.
1.6.2.3.1. DiscoveredClusters
오브젝트는 Discovery 컨트롤러에서 생성합니다. 이러한 DiscoveredClusters
는 DiscoveryConfig
discoveredclusters.discovery.open-cluster-management.io
API에 지정된 필터 및 인증 정보를 사용하여 OpenShift Cluster Manager에 있는 클러스터를 나타냅니다. name
값은 클러스터 외부 ID입니다.
apiVersion: discovery.open-cluster-management.io/v1 kind: DiscoveredCluster metadata: name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e namespace: <NAMESPACE_NAME> spec: activity_timestamp: "2021-04-19T21:06:14Z" cloudProvider: vsphere console: https://console-openshift-console.apps.qe1-vmware-pkt.dev02.red-chesterfield.com creation_timestamp: "2021-04-19T16:29:53Z" credential: apiVersion: v1 kind: Secret name: <SECRET_NAME> namespace: <NAMESPACE_NAME> display_name: qe1-vmware-pkt.dev02.red-chesterfield.com name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e openshiftVersion: 4.10 status: Stale
1.7. 호스트된 컨트롤 플레인(기술 프리뷰)
멀티 클러스터 엔진 Operator 클러스터 관리를 사용하면 독립 실행형 또는 호스트된 컨트롤 플레인이라는 두 가지 컨트롤 플레인 구성을 사용하여 OpenShift Container Platform 클러스터를 배포할 수 있습니다. 독립 실행형 구성은 전용 가상 머신 또는 물리적 머신을 사용하여 OpenShift Container Platform 컨트롤 플레인을 호스팅합니다. OpenShift Container Platform용 호스트 컨트롤 플레인을 사용하면 컨트롤 플레인을 각 컨트롤 플레인의 전용 물리적 머신 없이도 호스팅 클러스터에서 Pod로 생성할 수 있습니다.
OpenShift Container Platform의 호스트 컨트롤 플레인은 AWS(Amazon Web Services) 및 베어 메탈 또는 가상 환경에서 기술 프리뷰 기능으로 사용할 수 있습니다. OpenShift Container Platform 버전 4.10.7 이상에서 컨트롤 플레인을 호스팅할 수 있습니다.
참고: 호스팅된 컨트롤 플레인과 동일한 플랫폼에서 hub 클러스터 및 작업자를 실행합니다.
컨트롤 플레인은 단일 네임스페이스에 포함되어 호스팅된 컨트롤 플레인 클러스터와 연결된 Pod로 실행됩니다. OpenShift Container Platform에서 이러한 유형의 호스팅 클러스터를 생성할 때 컨트롤 플레인과 독립적인 작업자 노드를 생성합니다.
호스트된 컨트롤 플레인 클러스터는 다음과 같은 몇 가지 이점을 제공합니다.
- 전용 컨트롤 플레인 노드를 호스팅할 필요가 없어 비용 절감
- 컨트롤 플레인과 워크로드를 분리하여 격리를 개선하고 변경이 필요할 수 있는 구성 오류를 줄입니다.
- 컨트롤 플레인 노드 부트스트랩에 대한 요구 사항을 제거하여 클러스터 생성 시간을 줄입니다.
- turn-key 배포 지원 또는 완전히 사용자 지정된 OpenShift Container Platform 프로비저닝
호스팅된 컨트롤 플레인에 대한 자세한 내용은 다음 주제를 계속 읽습니다.
1.7.1. AWS에서 호스팅 클러스터 구성 (기술 프리뷰)
호스팅 컨트롤 플레인을 구성하려면 호스팅 클러스터 및 호스트 클러스터가 필요합니다. hypershift-addon
관리 클러스터 애드온을 사용하여 기존 관리 클러스터에 HyperShift Operator를 배포하면 해당 클러스터를 호스팅 클러스터로 활성화하고 호스팅 클러스터 생성을 시작할 수 있습니다.
멀티 클러스터 엔진 Operator 2.2는 호스팅 클러스터로 기본 로컬 클러스터
및 허브 클러스터만 지원합니다.
호스트된 컨트롤 플레인은 기술 프리뷰 기능이므로 관련 구성 요소는 기본적으로 비활성화되어 있습니다.
호스팅 클러스터로 작동하도록 기존 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 호스팅 클러스터는 컨트롤 플레인이 호스팅되는 Red Hat OpenShift Container Platform 클러스터입니다. Red Hat Advanced Cluster Management 2.7은 로컬 클러스터라고도 하는 허브 클러스터를
호스팅 클러스터로 사용할 수 있습니다. 로컬 클러스터를
호스팅 클러스터로 구성하는 방법을 알아보려면 다음 주제를 참조하십시오.
모범 사례: 호스팅된 컨트롤 플레인에서 동일한 플랫폼에서 허브 클러스터 및 작업자를 실행해야 합니다.
1.7.1.1. 사전 요구 사항
호스팅 클러스터를 구성하려면 다음 사전 요구 사항이 있어야 합니다.
- Kubernetes operator 2.2 이상은 OpenShift Container Platform 클러스터에 설치된 다중 클러스터 엔진입니다. Red Hat Advanced Cluster Management를 설치하면 다중 클러스터 엔진 Operator가 자동으로 설치됩니다. 멀티 클러스터 엔진 Operator는 Red Hat Advanced Cluster Management 없이 OpenShift Container Platform OperatorHub의 Operator로 설치할 수도 있습니다.
멀티 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다.
로컬 클러스터는 멀티 클러스터
엔진 Operator 2.2 이상에서 자동으로 가져옵니다.로컬 클러스터에
대한 자세한 내용은 고급 구성을 참조하십시오. 다음 명령을 실행하여 hub 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
- HyperShift Operator를 실행하기 위해 작업자 노드가 3개 이상인 호스팅 클러스터입니다.
1.7.1.2. Amazon Web Services S3 OIDC 시크릿 생성
AWS에서 호스팅 클러스터를 생성하고 관리하려면 다음 단계를 완료하십시오.
-
HyperShift Operator에 대해
hypershift-operator-oidc-provider-s3-credentials
라는 OIDC S3 시크릿을 생성합니다. -
local-cluster
네임스페이스에 보안을 저장합니다. 다음 표를 참조하여 시크릿에 다음 필드가 포함되어 있는지 확인합니다.
필드 이름 설명 bucket
호스트 OIDC 검색 문서에 대한 공용 액세스 권한이 있는 S3 버킷이 포함되어 있습니다.
credentials
버킷에 액세스할 수 있는
기본
프로필의 자격 증명이 포함된 파일에 대한 참조입니다. 기본적으로 HyperShift는기본
프로필만 사용하여버킷
을 작동합니다.region
S3 버킷의 리전을 지정합니다.
보안에 대한 자세한 내용은 HyperShift 설명서에서 시작하기 를 참조하십시오. 다음 예제에서는 샘플 AWS 시크릿 템플릿을 보여줍니다.
oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=$HOME/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster
참고: 시크릿에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 다음 명령을 실행하여 재해 복구를 위해
hypershift-operator-oidc-provider-s3-credentials
보안을 백업할 수 있는 레이블을 추가합니다.oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true
1.7.1.3. 라우팅 가능한 퍼블릭 영역 생성
게스트 클러스터의 애플리케이션에 액세스하려면 퍼블릭 영역을 라우팅할 수 있어야 합니다. 퍼블릭 영역이 있는 경우 이 단계를 건너뜁니다. 그렇지 않으면 퍼블릭 영역이 기존 기능에 영향을 미칩니다.
다음 명령을 실행하여 클러스터 DNS 레코드에 대한 퍼블릭 영역을 생성합니다.
BASE_DOMAIN=www.example.com aws route53 create-hosted-zone --name $BASE_DOMAIN --caller-reference $(whoami)-$(date --rfc-3339=date)
1.7.1.4. 외부 DNS 활성화
서비스 수준 DNS(외부 DNS)를 사용하여 호스트 컨트롤 플레인 클러스터를 프로비저닝하려면 다음 단계를 완료합니다.
-
HyperShift Operator의 AWS 인증 정보 시크릿을 생성하고
local-cluster
네임스페이스에서hypershift-operator-external-dns-credentials
이름을 지정합니다. 다음 표를 참조하여 시크릿에 필수 필드가 포함되어 있는지 확인합니다.
필드 이름 설명 선택적 또는 필수 공급자
서비스 수준 DNS 영역을 관리하는 DNS 공급자입니다.
필수 항목
domain-filter
서비스 수준 도메인입니다.
필수 항목
credentials
모든 외부 DNS 유형을 지원하는 자격 증명 파일입니다.
AWS 키를 사용하는 경우 선택 사항
aws-access-key-id
인증 정보 액세스 키 ID입니다.
AWS DNS 서비스를 사용하는 경우 선택 사항
aws-secret-access-key
인증 정보 액세스 키 시크릿입니다.
AWS DNS 서비스를 사용하는 경우 선택 사항
자세한 내용은 HyperShift 설명서에서 외부 DNS 를 참조하십시오. 다음 예제에서는 샘플
hypershift-operator-external-dns-credentials
시크릿 템플릿을 보여줍니다.oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=service.my.domain.com --from-file=credentials=<credentials-file> -n local-cluster
참고: 시크릿에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 다음 명령을 실행하여 재해 복구를 위해
hypershift-operator-external-dns-credentials
보안을 백업할 수 있는 레이블을 추가합니다.oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.1.5. AWS PrivateLink 활성화
PrivateLink를 사용하여 AWS 플랫폼에서 호스팅된 컨트롤 플레인 클러스터를 프로비저닝하려면 다음 단계를 완료하십시오.
-
HyperShift Operator에 대한 AWS 인증 정보 시크릿을 생성하고 이름을
hypershift-operator-private-link-credentials
로 지정합니다. 보안은 호스팅 클러스터로 사용되는 관리 대상 클러스터의 네임스페이스인 관리형 클러스터 네임스페이스에 있어야 합니다.local-cluster
를 사용한 경우local-cluster
네임스페이스에 보안을 생성합니다. 다음 표를 참조하여 시크릿에 필수 필드가 포함되어 있는지 확인합니다.
필드 이름
설명
선택적 또는 필수
region
Private Link와 함께 사용할 리전
필수 항목
aws-access-key-id
인증 정보 액세스 키 ID입니다.
필수 항목
aws-secret-access-key
인증 정보 액세스 키 시크릿입니다.
필수 항목
자세한 내용은 HyperShift 설명서에서 AWS 개인 클러스터 배포 단원을 참조하십시오. 다음 예제는 샘플
hypershift-operator-private-link-credentials
시크릿 템플릿을 보여줍니다.oc create secret generic hypershift-operator-private-link-credentials --from-literal=aws-access-key-id=<aws-access-key-id> --from-literal=aws-secret-access-key=<aws-secret-access-key> --from-literal=region=<region> -n local-cluster
참고: 시크릿에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 다음 명령을 실행하여 재해 복구를 위해
hypershift-operator-private-link-credentials
보안을 백업할 수 있는 레이블을 추가합니다.oc label secret hypershift-operator-private-link-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.1.6. 호스팅된 컨트롤 플레인 기능 활성화
호스팅된 컨트롤 플레인 기능은 기본적으로 비활성화되어 있습니다. 기능을 활성화하면 hypershift-addon
관리 클러스터 애드온도 자동으로 활성화됩니다. 다음 명령을 실행하여 기능을 활성화할 수 있습니다.
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": true}]}}}'
다음 명령을 실행하여 MultiClusterEngine
사용자 정의 리소스에서 hypershift-preview
및 hypershift-local-hosting
기능이 활성화되어 있는지 확인합니다.
oc get mce multiclusterengine -o yaml
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: hypershift-preview enabled: true - name: hypershift-local-hosting enabled: true
1.7.1.6.1. 로컬 클러스터에 대해 hypershift-addon 관리 클러스터 애드온 수동 활성화
호스팅된 컨트롤 플레인 기능을 활성화하면 hypershift-addon
관리 클러스터 애드온이 자동으로 활성화됩니다. hypershift-addon
관리 클러스터 애드온을 수동으로 활성화해야 하는 경우 hypershift-addon
을 사용하여 로컬 클러스터에
HyperShift Operator를 설치하려면 다음 단계를 완료합니다.
다음 예와 유사한 파일을 생성하여
ManagedClusterAddon
HyperShift 애드온을 생성합니다.apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: hypershift-addon namespace: local-cluster spec: installNamespace: open-cluster-management-agent-addon
다음 명령을 실행하여 파일을 적용합니다.
oc apply -f <filename>
파일
이름을 생성한 파일의 이름으로 바꿉니다.다음 명령을 실행하여
hypershift-addon
이 설치되었는지 확인합니다.oc get managedclusteraddons -n local-cluster hypershift-addon
추가 기능이 설치된 경우 출력은 다음 예와 유사합니다.
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True
HyperShift 애드온이 설치되어 호스팅 클러스터를 생성하고 관리할 수 있습니다.
1.7.1.7. 호스팅된 컨트롤 플레인 CLI 설치
호스팅된 컨트롤 플레인(HyperShift) CLI는 OpenShift Container Platform 호스팅 컨트롤 플레인 클러스터를 생성하고 관리하는 데 사용됩니다. 호스팅된 컨트롤 플레인 기능을 활성화한 후 다음 단계를 완료하여 호스팅된 컨트롤 플레인 CLI를 설치할 수 있습니다.
- OpenShift Container Platform 콘솔에서 도움말 아이콘 > 명령줄 툴 을 클릭합니다.
플랫폼에 대해 Hypershift CLI 다운로드를 클릭합니다.
참고:
hypershift-preview
기능을 활성화한 경우에만 다운로드가 표시됩니다.다음 명령을 실행하여 다운로드한 아카이브의 압축을 풉니다.
tar xvzf hypershift.tar.gz
다음 명령을 실행하여 바이너리 파일을 실행 가능하게 합니다.
chmod +x hypershift
다음 명령을 실행하여 바이너리 파일을 경로의 디렉터리로 이동합니다.
sudo mv hypershift /usr/local/bin/.
이제 hypershift create cluster
명령을 사용하여 호스팅 클러스터를 생성하고 관리할 수 있습니다. 다음 명령을 사용하여 사용 가능한 매개변수를 나열합니다.
hypershift create cluster aws --help
1.7.1.8. 추가 리소스
- S3 OIDC 보안에 대한 자세한 내용은 HyperShift 설명서에서 시작하기 를 참조하십시오.
- AWS 인증 정보 시크릿에 대한 자세한 내용은 HyperShift 설명서에서 AWS 프라이빗 클러스터 배포를 참조하십시오.
- 외부 DNS에 대한 자세한 내용은 HyperShift 설명서의 외부 DNS 를 참조하십시오.
- 이제 SR-IOV Operator를 배포할 수 있습니다. SR-IOV Operator 배포에 대한 자세한 내용은 호스팅 컨트롤 플레인 의 SR-IOV Operator 배포를 참조하십시오.
1.7.2. AWS에서 호스트된 컨트롤 플레인 클러스터 관리 (기술 프리뷰)
Kubernetes Operator 콘솔의 다중 클러스터 엔진을 사용하여 Red Hat OpenShift Container Platform 호스트 클러스터를 생성할 수 있습니다. 호스트된 컨트롤 플레인은 AWS(Amazon Web Services)에서 기술 프리뷰로 사용할 수 있습니다. AWS에서 호스팅된 컨트롤 플레인을 사용하는 경우 콘솔을 사용하여 호스팅된 클러스터를 생성하거나 콘솔 또는 명령줄 인터페이스를 사용하여 호스팅된 클러스터를 가져올 수 있습니다.
1.7.2.1. 사전 요구 사항
호스트된 컨트롤 플레인 클러스터를 생성하기 전에 호스트된 컨트롤 플레인을 구성해야 합니다. 자세한 내용은 호스팅된 컨트롤 플레인 구성(기술 프리뷰) 을 참조하십시오.
1.7.2.2. 콘솔을 사용하여 AWS에서 호스팅 컨트롤 플레인 클러스터 생성
멀티 클러스터 엔진 Operator 콘솔에서 호스팅된 컨트롤 플레인 클러스터를 생성하려면 Infrastructure > Clusters 로 이동합니다. 클러스터 페이지에서 클러스터 > 호스트 인벤토리 만들기 > 호스팅을 클릭하고 콘솔의 단계를 완료합니다.
중요: 클러스터를 생성할 때 다중 클러스터 엔진 Operator 컨트롤러에서 클러스터와 해당 리소스의 네임스페이스를 생성합니다. 해당 네임스페이스에 해당 클러스터 인스턴스의 리소스만 포함해야 합니다. 클러스터를 삭제하면 네임스페이스와 그 안에 있는 모든 리소스가 삭제됩니다.
YAML: On 을 선택하여 콘솔에 정보를 입력할 때 콘텐츠 업데이트를 확인합니다.
기존 클러스터 세트에 클러스터를 추가하려면 클러스터에 대한 올바른 권한이 있어야 합니다. 클러스터를 생성할 때 cluster-admin
권한이 없는 경우 clusterset-admin
권한이 있는 클러스터를 선택해야 합니다. 지정된 클러스터 세트에 대한 올바른 권한이 없으면 클러스터 생성에 실패합니다. 선택할 클러스터 설정 옵션이 없는 경우 clusterset-admin
권한을 제공하려면 클러스터 관리자에게 문의하십시오.
관리되는 모든 클러스터는 관리형 클러스터 세트와 연결되어야 합니다. 관리 클러스터를 ManagedClusterSet
에 할당하지 않으면 기본
관리 클러스터 세트에 자동으로 추가됩니다.
릴리스 이미지는 클러스터를 생성하는 데 사용되는 OpenShift Container Platform 이미지의 버전을 식별합니다. 호스트된 컨트롤 플레인 클러스터는 제공된 릴리스 이미지 중 하나를 사용해야 합니다.
인프라 환경에서 제공되는 프록시 정보는 프록시 필드에 자동으로 추가됩니다. 기존 정보를 사용하거나 덮어쓰거나 프록시를 활성화하려면 정보를 추가할 수 있습니다. 다음 목록에는 프록시 생성에 필요한 정보가 포함되어 있습니다.
-
HTTP 프록시 URL:
HTTP
트래픽의 프록시로 사용해야 하는 URL입니다. -
HTTPS 프록시 URL:
HTTPS
트래픽에 사용해야 하는 보안 프록시 URL입니다. 값을 제공하지 않으면HTTP
및HTTPS
모두에 대해HTTP 프록시 URL
과 동일한 값이 사용됩니다. -
프록시 도메인이 없음: 프록시를 바이패스해야 하는 쉼표로 구분된 도메인 목록입니다. 해당 도메인에 있는 모든 하위 도메인을 포함하려면 마침표로 도메인 이름을 시작합니다
.
모든 대상에 대한 프록시를 바이패스하려면 별표*
를 추가합니다. - 추가 신뢰 번들: 미러 레지스트리에 액세스하는 데 필요한 인증서 파일의 콘텐츠입니다.
클러스터를 생성하기 전에 정보를 검토하고 선택적으로 사용자 지정할 때 YAML: On 을 선택하여 패널의 YAML 콘텐츠를 볼 수 있습니다. 업데이트가 있는 경우 사용자 지정 설정으로 YAML 파일을 편집할 수 있습니다.
참고: 클러스터를 가져오려면 클러스터 세부 정보와 함께 제공되는 oc
명령을 실행해야 합니다. 클러스터를 생성할 때 Red Hat Advanced Cluster Management의 관리로 자동 구성되지 않습니다.
1.7.2.3. AWS에 호스트 클러스터 배포
호스팅된 컨트롤 플레인(Hypershift
) 명령줄 인터페이스를 설정하고 호스팅 클러스터로 로컬 클러스터를
활성화한 후 다음 단계를 완료하여 AWS에 호스트 클러스터를 배포할 수 있습니다.
다음과 같이 환경 변수를 설정하여 필요에 따라 변수를 인증 정보로 교체합니다.
export REGION=us-east-1 export CLUSTER_NAME=clc-name-hs1 export INFRA_ID=clc-name-hs1 export BASE_DOMAIN=dev09.red-chesterfield.com export AWS_CREDS=$HOME/name-aws export PULL_SECRET=/Users/username/pull-secret.txt export BUCKET_NAME=acmqe-hypershift export BUCKET_REGION=us-east-1
CLUSTER_NAME
및INFRA_ID
가 동일한 값이 있는지 확인합니다. 그러지 않으면 Kubernetes Operator 콘솔의 멀티 클러스터 엔진에 클러스터가 올바르게 표시되지 않을 수 있습니다. 각 변수에 대한 설명을 보려면 다음 명령을 실행합니다.hypershift create cluster aws --help
- hub 클러스터에 로그인했는지 확인합니다.
다음 명령을 실행하여 호스트된 클러스터를 생성합니다.
hypershift create cluster aws \ --name $CLUSTER_NAME \ --infra-id $INFRA_ID \ --aws-creds $AWS_CREDS \ --pull-secret $PULL_SECRET \ --region $REGION \ --generate-ssh \ --node-pool-replicas 3 \ --namespace <hypershift-hosting-service-cluster>
참고: 기본적으로 모든
HostedCluster
및NodePool
사용자 정의 리소스가클러스터
네임스페이스에 생성됩니다.--namespace <namespace> 매개변수를 지정하면 선택한 네임스페이스에
HostedCluster
및NodePool
사용자 정의 리소스가 생성됩니다.다음 명령을 실행하여 호스팅된 클러스터의 상태를 확인할 수 있습니다.
oc get hostedclusters -n <hypershift-hosting-service-cluster>
1.7.2.4. AWS에서 호스팅 컨트롤 플레인 클러스터 가져오기
콘솔을 사용하여 호스트된 컨트롤 플레인 클러스터를 가져올 수 있습니다.
- Infrastructure > Clusters 로 이동하여 가져올 호스트 클러스터를 선택합니다.
Import hosted cluster 를 클릭합니다.
참고: 검색된 호스트 클러스터의 경우 콘솔에서 가져올 수도 있지만 클러스터는 업그레이드 가능한 상태여야 합니다. 호스팅 컨트롤 플레인을 사용할 수 없기 때문에 호스팅된 클러스터가 업그레이드 가능한 상태가 아닌 경우 클러스터에서 가져오기가 비활성화됩니다. Import (가져오기)를 클릭하여 프로세스를 시작합니다. 클러스터가 업데이트를 수신하는 동안 상태가
Importing
된 후Ready
로 변경됩니다.
다음 단계를 완료하여 명령줄 인터페이스를 사용하여 AWS에서 호스팅 컨트롤 플레인 클러스터를 가져올 수도 있습니다.
다음 명령을 실행하여
HostedCluster
사용자 정의 리소스에 주석을 추가합니다.oc edit hostedcluster <cluster_name> -n clusters
&
lt;cluster_name
>을 호스트 클러스터 이름으로 바꿉니다.다음 명령을 실행하여
HostedCluster
사용자 정의 리소스에 주석을 추가합니다.cluster.open-cluster-management.io/hypershiftdeployment: local-cluster/<cluster_name> cluster.open-cluster-management.io/managedcluster-name: <cluster_name>
&
lt;cluster_name
>을 호스트 클러스터 이름으로 바꿉니다.다음 샘플 YAML 파일을 사용하여
ManagedCluster
리소스를 생성합니다.apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: annotations: import.open-cluster-management.io/hosting-cluster-name: local-cluster import.open-cluster-management.io/klusterlet-deploy-mode: Hosted open-cluster-management/created-via: other labels: cloud: auto-detect cluster.open-cluster-management.io/clusterset: default name: <cluster_name> vendor: OpenShift name: <cluster_name> spec: hubAcceptsClient: true leaseDurationSeconds: 60
&
lt;cluster_name
>을 호스트 클러스터 이름으로 바꿉니다.다음 명령을 실행하여 리소스를 적용합니다.
oc apply -f <file_name>
<file_name>을 이전 단계에서 생성한 YAML 파일 이름으로 바꿉니다.
다음 샘플 YAML 파일을 사용하여
KlusterletAddonConfig
리소스를 생성합니다. 이는 Red Hat Advanced Cluster Management에만 적용됩니다. 다중 클러스터 엔진 Operator만 설치한 경우 다음 단계를 건너뜁니다.apiVersion: agent.open-cluster-management.io/v1 kind: KlusterletAddonConfig metadata: name: <cluster_name> namespace: <cluster_name> spec: clusterName: <cluster_name> clusterNamespace: <cluster_name> clusterLabels: cloud: auto-detect vendor: auto-detect applicationManager: enabled: true certPolicyController: enabled: true iamPolicyController: enabled: true policyController: enabled: true searchCollector: enabled: false
&
lt;cluster_name
>을 호스트 클러스터 이름으로 바꿉니다.다음 명령을 실행하여 리소스를 적용합니다.
oc apply -f <file_name>
<file_name>을 이전 단계에서 생성한 YAML 파일 이름으로 바꿉니다.
가져오기 프로세스가 완료되면 호스트된 클러스터가 콘솔에 표시됩니다. 다음 명령을 실행하여 호스팅된 클러스터의 상태를 확인할 수도 있습니다.
oc get managedcluster <cluster_name>
1.7.2.5. AWS의 호스팅 클러스터에 액세스
호스팅된 컨트롤 플레인 클러스터의 액세스 보안은 hypershift-management-cluster
네임스페이스에 저장됩니다. 다음 보안 이름 형식에 대해 알아봅니다.
-
kubeconfig
secret: <hostingNamespace>-<name>-admin-kubeconfig
(clusters-hypershift-demo-admin-kubeconfig) -
kubeadmin
암호 보안: <hostingNamespace>-<name>-kubeadmin-password
(clusters-hypershift-demo-kubeadmin-password)
1.7.2.6. ARM64 OpenShift Container Platform 클러스터에서 호스트된 컨트롤 플레인 활성화
ARM64 호스팅 컨트롤 플레인을 활성화하여 관리 클러스터 환경에서 OpenShift Container Platform ARM64 데이터 플레인에서 작동할 수 있습니다. 이 기능은 AWS의 호스팅 컨트롤 플레인에서만 사용할 수 있습니다.
1.7.2.6.1. 사전 요구 사항
시작하기 전에 다음 사전 요구 사항을 충족해야 합니다.
- 64비트 ARM 인프라에 설치된 OpenShift Container Platform 클러스터가 있어야 합니다. 자세한 내용은 Create an OpenShift Cluster: AWS (ARM) 를 참조하십시오.
-
64비트 ARM 인프라를 기반으로 하는 HyperShift Operator가 있어야 합니다. Hyper shift/hypershift-operator 리포지토리로 이동하고
4.13-
arm64 태그가 있는 빌드를 선택하여 HyperShift Operator를 가져올 수 있습니다.
ARM64 OpenShift Container Platform 클러스터에서 호스팅된 클러스터를 실행하려면 다음 단계를 따르십시오.
관리 클러스터에 ARM64용 HyperShift Operator를 설치하여 기본 HyperShift Operator 이미지를 재정의합니다.
예를 들어 호스트된 컨트롤 플레인(
hypershift
) 명령줄 인터페이스를 통해 다음 명령을 입력합니다. 버킷 이름, AWS 인증 정보 및 리전을 정보로 교체하십시오.hypershift install \ --oidc-storage-provider-s3-bucket-name $BUCKET_NAME \ --oidc-storage-provider-s3-credentials $AWS_CREDS \ --oidc-storage-provider-s3-region $REGION \ --hypershift-image quay.io/hypershift/hypershift-operator:4.13-arm64
다중 아키텍처 릴리스 이미지로 기본 릴리스 이미지를 재정의하는 호스트 클러스터를 생성합니다.
예를 들어 호스트된 컨트롤 플레인(
hypershift
) 명령줄 인터페이스를 통해 다음 명령을 입력합니다. 이 명령을 입력하여 클러스터 이름, 노드 풀 복제본, 기본 도메인, 풀 시크릿, AWS 인증 정보 및 리전을 정보로 교체하십시오.hypershift create cluster aws \ --name $CLUSTER_NAME \ --node-pool-replicas=$NODEPOOL_REPLICAS \ --base-domain $BASE_DOMAIN \ --pull-secret $PULL_SECRET \ --aws-creds $AWS_CREDS \ --region $REGION \ --release-image quay.io/openshift-release-dev/ocp-release:4.13.0-rc.0-multi
이 예제에서는
--node-pool-replicas
플래그를 통해 기본NodePool
오브젝트를 추가합니다.호스트된 클러스터에 64비트 x86
NodePool
개체를 추가합니다.예를 들어 호스트된 컨트롤 플레인(
hypershift
) 명령줄 인터페이스를 통해 다음 명령을 입력합니다. 클러스터 이름, 노드 풀 이름 및 노드 풀 복제본을 사용자의 정보로 교체하십시오.hypershift create nodepool aws \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count=$NODEPOOL_REPLICAS
1.7.2.7. AWS에서 호스트 클러스터 삭제
호스팅 클러스터 및 관리되는 클러스터 리소스를 제거하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 호스팅 클러스터 및 해당 백엔드 리소스를 삭제합니다.
hypershift destroy cluster aws --name <cluster_name> --infra-id <infra_id> --aws-creds <aws-credentials> --base-domain <base_domain> --destroy-cloud-resources
필요한 경우 이름을 바꿉니다.
다음 명령을 실행하여 다중 클러스터 엔진 Operator에서 관리형 클러스터 리소스를 삭제합니다.
oc delete managedcluster <cluster_name>
cluster_name
을 클러스터 이름으로 바꿉니다.
1.7.3. 베어 메탈에서 호스팅 클러스터 구성 (기술 프리뷰)
호스팅 컨트롤 플레인을 구성하려면 호스팅 클러스터 및 호스트 클러스터가 필요합니다. hypershift-addon
관리 클러스터 애드온을 사용하여 기존 관리 클러스터에 HyperShift Operator를 배포하면 해당 클러스터를 호스팅 클러스터로 활성화하고 호스팅 클러스터 생성을 시작할 수 있습니다.
멀티 클러스터 엔진 Operator 2.2는 호스팅 클러스터로 기본 로컬 클러스터
및 허브 클러스터만 지원합니다.
호스트된 컨트롤 플레인은 기술 프리뷰 기능이므로 관련 구성 요소는 기본적으로 비활성화되어 있습니다. AWS(Amazon Web Services)에서 호스팅 컨트롤 플레인을 활성화하는 방법에 대한 자세한 내용은 다음 주제를 참조하십시오.
호스팅 클러스터로 작동하도록 기존 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 호스팅 클러스터는 컨트롤 플레인이 호스팅되는 {ocp-cluster} 클러스터입니다.
Red Hat Advanced Cluster Management 2.7 사용자는 호스팅 클러스터로 로컬 클러스터라고도 하는 관리형 허브 클러스터를
사용할 수 있습니다. 로컬 클러스터를
호스팅 클러스터로 구성하는 방법을 알아보려면 다음 주제를 참조하십시오.
중요:
- 호스팅된 컨트롤 플레인과 동일한 플랫폼에서 hub 클러스터 및 작업자를 실행합니다.
- 베어 메탈에서 호스트된 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 CIM(Central Infrastructure Management) 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다.
-
각 베어 메탈 호스트는 CIM에서 제공하는 검색 이미지를 사용하여 시작해야 합니다.
Cluster-Baremetal-Operator
를 사용하여 수동으로 또는 자동화를 통해 호스트를 시작할 수 있습니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트 세부 정보를 검색하고 설치를 완료합니다.에이전트
사용자 정의 리소스는 각 호스트를 나타냅니다. - 에이전트 플랫폼으로 호스트된 클러스터를 생성할 때 HyperShift는 호스트된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.
- 노드 풀을 확장하면 머신이 생성됩니다. Cluster API 공급자는 승인된 에이전트를 찾고, 검증을 통과하고, 현재 사용되지 않고, 노드 풀 사양에 지정된 요구 사항을 충족합니다. 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
- 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 클러스터를 재사용하려면 먼저 Discovery 이미지를 사용하여 노드 수를 업데이트하여 클러스터를 다시 시작해야 합니다.
1.7.3.1. 사전 요구 사항
호스팅 클러스터를 구성하려면 다음 사전 요구 사항이 있어야 합니다.
- Kubernetes operator 2.2 이상은 OpenShift Container Platform 클러스터에 설치되어 있어야 합니다. Red Hat Advanced Cluster Management를 설치하면 다중 클러스터 엔진 Operator가 자동으로 설치됩니다. OpenShift Container Platform OperatorHub에서 Operator로 Red Hat Advanced Cluster Management 없이 다중 클러스터 엔진 Operator를 설치할 수도 있습니다.
멀티 클러스터 엔진 Operator에 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다.
로컬 클러스터는 멀티 클러스터
엔진 Operator 2.2 이상에서 자동으로 가져옵니다.로컬 클러스터에
대한 자세한 내용은 고급 구성을 참조하십시오. 다음 명령을 실행하여 hub 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
- HyperShift Operator를 실행하려면 작업자 노드가 3개 이상인 호스팅 클러스터가 있어야 합니다.
- 호스팅된 컨트롤 플레인 기능을 활성화해야 합니다. 자세한 내용은 호스팅된 컨트롤 플레인 기능 활성화를 참조하십시오.
1.7.3.2. DNS 구성
호스트된 클러스터의 API 서버는 NodePort
서비스로 노출됩니다. API 서버에 도달할 수 있는 대상을 가리키는 api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN}
에 대한 DNS 항목이 있어야 합니다.
DNS 항목은 호스팅 컨트롤 플레인을 실행 중인 관리형 클러스터의 노드 중 하나를 가리키는 레코드만큼 간단할 수 있습니다. 이 항목은 들어오는 트래픽을 수신 pod로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.
다음 DNS 구성 예를 참조하십시오.
api.example.krnl.es. IN A 192.168.122.20 api.example.krnl.es. IN A 192.168.122.21 api.example.krnl.es. IN A 192.168.122.22 api-int.example.krnl.es. IN A 192.168.122.20 api-int.example.krnl.es. IN A 192.168.122.21 api-int.example.krnl.es. IN A 192.168.122.22 `*`.apps.example.krnl.es. IN A 192.168.122.23
1.7.3.3. 추가 리소스
- CIM 서비스에 대한 소개는 Kube API - 시작하기 가이드를 참조하십시오.
- 로드 밸런서에 대한 자세한 내용은 사용자 프로비저닝 인프라에 대한 로드 밸런싱 요구 사항을 참조하십시오.
- 이제 SR-IOV Operator를 배포할 수 있습니다. SR-IOV Operator 배포에 대한 자세한 내용은 호스팅 컨트롤 플레인 의 SR-IOV Operator 배포를 참조하십시오.
1.7.4. 베어 메탈에서 호스트된 컨트롤 플레인 클러스터 관리 (기술 프리뷰)
Kubernetes Operator 콘솔의 다중 클러스터 엔진을 사용하여 Red Hat OpenShift Container Platform 호스트 클러스터를 생성하고 관리할 수 있습니다. 호스트된 컨트롤 플레인은 AWS(Amazon Web Services) 및 베어 메탈에서 기술 프리뷰로 사용할 수 있습니다.
1.7.4.1. 사전 요구 사항
호스트된 컨트롤 플레인 클러스터를 생성하기 전에 베어 메탈에 호스트된 컨트롤 플레인을 구성해야 합니다. 자세한 내용은 베어 메탈에서 호스팅 클러스터 구성(기술 프리뷰) 을 참조하십시오.
1.7.4.2. 베어 메탈에서 호스트된 클러스터 생성
클러스터에 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그렇지 않으면 보류 중인 PVC로 끝날 수 있습니다.
다음 명령을 입력합니다.
export CLUSTERS_NAMESPACE="clusters" export HOSTED_CLUSTER_NAME="example" export HOSTED_CONTROL_PLANE_NAMESPACE="${CLUSTERS_NAMESPACE}-${HOSTED_CLUSTER_NAME}" export BASEDOMAIN="krnl.es" export PULL_SECRET_FILE=$PWD/pull-secret export MACHINE_CIDR=192.168.122.0/24 # Typically the namespace is created by the hypershift-operator # but agent cluster creation generates a capi-provider role that # needs the namespace to already exist oc create ns ${HOSTED_CONTROL_PLANE_NAMESPACE} hypershift create cluster agent \ --name=${HOSTED_CLUSTER_NAME} \ --pull-secret=${PULL_SECRET_FILE} \ --agent-namespace=${HOSTED_CONTROL_PLANE_NAMESPACE} \ --base-domain=${BASEDOMAIN} \ --api-server-address=api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} \
잠시 후 다음 명령을 입력하여 호스팅 컨트롤 플레인 Pod가 실행 중인지 확인합니다.
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get pods
출력 예
NAME READY STATUS RESTARTS AGE capi-provider-7dcf5fc4c4-nr9sq 1/1 Running 0 4m32s catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s certified-operators-catalog-884c756c4-zdt64 1/1 Running 0 2m51s cluster-api-f75d86f8c-56wfz 1/1 Running 0 4m32s cluster-autoscaler-7977864686-2rz4c 1/1 Running 0 4m13s cluster-network-operator-754cf4ffd6-lwfm2 1/1 Running 0 2m51s cluster-policy-controller-784f995d5-7cbrz 1/1 Running 0 2m51s cluster-version-operator-5c68f7f4f8-lqzcm 1/1 Running 0 2m51s community-operators-catalog-58599d96cd-vpj2v 1/1 Running 0 2m51s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s etcd-0 1/1 Running 0 4m13s hosted-cluster-config-operator-c4776f89f-dt46j 1/1 Running 0 2m51s ignition-server-7cd8676fc5-hjx29 1/1 Running 0 4m22s ingress-operator-75484cdc8c-zhdz5 1/2 Running 0 2m51s konnectivity-agent-c5485c9df-jsm9s 1/1 Running 0 4m13s konnectivity-server-85dc754888-7z8vm 1/1 Running 0 4m13s kube-apiserver-db5fb5549-zlvpq 3/3 Running 0 4m13s kube-controller-manager-5fbf7b7b7b-mrtjj 1/1 Running 0 90s kube-scheduler-776c59d757-kfhv6 1/1 Running 0 3m12s machine-approver-c6b947895-lkdbk 1/1 Running 0 4m13s oauth-openshift-787b87cff6-trvd6 2/2 Running 0 87s olm-operator-69c4657864-hxwzk 2/2 Running 0 2m50s openshift-apiserver-67f9d9c5c7-c9bmv 2/2 Running 0 89s openshift-controller-manager-5899fc8778-q89xh 1/1 Running 0 2m51s openshift-oauth-apiserver-569c78c4d-568v8 1/1 Running 0 2m52s packageserver-ddfffb8d7-wlz6l 2/2 Running 0 2m50s redhat-marketplace-catalog-7dd77d896-jtxkd 1/1 Running 0 2m51s redhat-operators-catalog-d66b5c965-qwhn7 1/1 Running 0 2m51s
1.7.4.3. InfraEnv 생성
InfraEnv
는 라이브 ISO를 시작하는 호스트가 에이전트로 참여할 수 있는 환경입니다. 이 경우 에이전트는 호스트 컨트롤 플레인과 동일한 네임스페이스에 생성됩니다.
InfraEnv
를 만들려면 다음 명령을 입력합니다.export SSH_PUB_KEY=$(cat $HOME/.ssh/id_rsa.pub) envsubst <<"EOF" | oc apply -f - apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: ${HOSTED_CLUSTER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} spec: pullSecretRef: name: pull-secret sshAuthorizedKey: ${SSH_PUB_KEY} EOF
가상 머신 또는 베어 메탈 머신이 에이전트로 참여할 수 있는 라이브 ISO를 생성하려면 다음 명령을 입력합니다.
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get InfraEnv ${HOSTED_CLUSTER_NAME} -ojsonpath="{.status.isoDownloadURL}"
1.7.4.4. 에이전트 추가
라이브 ISO로 시작하거나 Metal3을 사용하여 머신을 수동으로 구성하여 에이전트를 추가할 수 있습니다.
에이전트를 수동으로 추가하려면 다음 단계를 수행합니다.
-
라이브 ISO를 다운로드하여 이를 사용하여 노드를 시작합니다(베어 메탈 또는 VM). 시작 시 노드는 지원 서비스와 통신하고
InfraEnv
와 동일한 네임스페이스에 있는 에이전트로 등록합니다. 각 에이전트가 생성되면 선택적으로 사양에
installation_disk_id
및hostname
을 설정할 수 있습니다. 그런 다음 이를 승인하여 에이전트가 사용할 준비가 되었음을 나타냅니다.oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents
출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents
출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
-
라이브 ISO를 다운로드하여 이를 사용하여 노드를 시작합니다(베어 메탈 또는 VM). 시작 시 노드는 지원 서비스와 통신하고
Metal3을 사용하여 에이전트를 추가하려면 다음 지침을 따르십시오.
Assisted Service를 사용하여 사용자 정의 ISO 및 Baremetal Operator를 생성하여 설치를 수행합니다.
중요:
BaremetalHost
오브젝트가 baremetal-operator 네임스페이스 외부에서 생성되므로 모든 네임스페이스를 조사하도록 Operator를 구성해야 합니다.oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
metal3
Pod는openshift-machine-api
네임스페이스에서 다시 시작됩니다.metal3
Pod가 다시 준비될 때까지 기다립니다.until oc wait -n openshift-machine-api $(oc get pods -n openshift-machine-api -l baremetal.openshift.io/cluster-baremetal-operator=metal3-state -o name) --for condition=containersready --timeout 10s >/dev/null 2>&1 ; do sleep 1 ; done
BaremetalHost 오브젝트를 생성합니다. 베어 메탈 노드를 시작하는 데 필요한 몇 가지 변수를 구성해야 합니다.
-
BMC_USERNAME
: BMC에 연결할 사용자 이름입니다. -
BMC_PASSWORD
: BMC에 연결할 암호입니다. -
BMC_IP
: Metal3에서 BMC에 연결하는 데 사용하는 IP입니다. -
WORKER_NAME
: BaremetalHost 오브젝트의 이름(이 값은 호스트 이름으로도 사용) -
BOOT_MAC_ADDRESS
: MachineNetwork에 연결된 NIC의 MAC 주소입니다. -
UUID
: Redfish UUID, 일반적으로1
입니다. sushy-tools를 사용하는 경우 이 값은 긴 UUID입니다. iDrac를 사용하는 경우 이 값은System.Embedded.1
입니다. 판매자에게 확인해야 할 수도 있습니다. -
REDFISH_SCHEME
: 사용할 Redfish 공급자입니다. 표준 Redfish 구현을 사용하는 하드웨어를 사용하는 경우 이 값을redfish-virtualmedia
로 설정할 수 있습니다. iDRAC는idrac-virtualmedia
를 사용합니다. iLO5는ilo5-virtualmedia
를 사용합니다. 판매자에게 확인해야 할 수도 있습니다. REDFISH
: Redfish 연결 끝점.export BMC_USERNAME=$(echo -n "root" | base64 -w0) export BMC_PASSWORD=$(echo -n "calvin" | base64 -w0) export BMC_IP="192.168.124.228" export WORKER_NAME="ocp-worker-0" export BOOT_MAC_ADDRESS="aa:bb:cc:dd:ee:ff" export UUID="1" export REDFISH_SCHEME="redfish-virtualmedia" export REDFISH="${REDFISH_SCHEME}://${BMC_IP}/redfish/v1/Systems/${UUID}"
-
다음 단계를 수행하여 BaremetalHost를 생성합니다.
BMC 시크릿을 생성합니다.
oc apply -f - apiVersion: v1 data: password: ${BMC_PASSWORD} username: ${BMC_USERNAME} kind: Secret metadata: name: ${WORKER_NAME}-bmc-secret namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} type: Opaque
BMH를 생성합니다.
참고:
infraenvs.agent-install.openshift.io
레이블은 BMH를 시작하는 데 사용되는InfraEnv
를 지정하는 데 사용됩니다.bmac.agent-install.openshift.io/hostname
레이블은 호스트 이름을 수동으로 설정하는 데 사용됩니다.설치 디스크를 수동으로 지정하려면 BMH 사양에서
rootDeviceHints
를 사용할 수 있습니다.rootDeviceHints
가 제공되지 않으면 에이전트는 설치 요구 사항에 더 적합한 설치 디스크를 선택합니다.rootDeviceHints
에 대한 자세한 내용은 BareMetalHost 설명서의 rootDeviceHints 섹션을 참조하십시오.oc apply -f - apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: ${WORKER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} labels: infraenvs.agent-install.openshift.io: ${HOSTED_CLUSTER_NAME} annotations: inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: ${WORKER_NAME} spec: automatedCleaningMode: disabled bmc: disableCertificateVerification: True address: ${REDFISH} credentialsName: ${WORKER_NAME}-bmc-secret bootMACAddress: ${BOOT_MAC_ADDRESS} online: true
에이전트가 자동으로 승인됩니다. 승인되지 않은 경우
bootMACAddress
가 올바른지 확인합니다.BMH가 프로비저닝됩니다.
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh
출력 예
NAME STATE CONSUMER ONLINE ERROR AGE ocp-worker-0 provisioning true 2m50s
결국 BMH는
프로비저닝된
상태에 도달합니다.oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh
출력 예
NAME STATE CONSUMER ONLINE ERROR AGE ocp-worker-0 provisioned true 72s
provisioned는 노드가 virtualCD에서 시작하도록 올바르게 구성되었음을 의미합니다. 에이전트가 표시되는 데 다소 시간이 걸립니다.
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent
출력 예
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 true auto-assign
에이전트가 자동으로 승인됩니다.
나머지 두 노드에서 이 프로세스를 반복합니다.
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent
출력 예
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 true auto-assign
1.7.4.5. 호스트된 클러스터에 액세스
호스트된 컨트롤 플레인이 실행 중이며 에이전트는 호스팅된 클러스터에 참여할 준비가 되어 있습니다. 에이전트가 호스트된 클러스터에 참여하기 전에 호스트 클러스터에 액세스해야 합니다.
다음 명령을 입력하여 kubeconfig를 생성합니다.
hypershift create kubeconfig --namespace ${CLUSTERS_NAMESPACE} --name ${HOSTED_CLUSTER_NAME} > ${HOSTED_CLUSTER_NAME}.kubeconfig
클러스터에 액세스하는 경우 노드가 없고 ClusterVersion에서 Red Hat OpenShift Container Platform 릴리스를 조정하려는 것을 확인할 수 있습니다.
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,nodes
출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version False True 8m6s Unable to apply 4.12z: some cluster operators have not yet rolled out
클러스터를 실행하려면 노드를 추가해야 합니다.
1.7.4.6. NodePool 오브젝트 스케일링
NodePool 오브젝트를 스케일링하여 호스팅 클러스터에 노드를 추가합니다.
NodePool 오브젝트를 두 개의 노드로 확장합니다.
oc -n ${CLUSTERS_NAMESPACE} scale nodepool ${NODEPOOL_NAME} --replicas 2
ClusterAPI 에이전트 공급자는 호스트된 클러스터에 할당된 두 에이전트를 임의로 선택합니다. 이러한 에이전트는 다양한 상태를 살펴보고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 상태가
바인딩
에서 전달되어 존재하지 않는 클러스터 (Add-to-existing
.-cluster)에 install-in-progress에 설치에
충분하지
않음으로 검색합니다oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent
출력 예
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}' BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
에이전트가 Add
-to-existing-cluster
상태에 도달하면 OpenShift Container Platform 노드가 표시되는지 확인합니다.oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
출력 예
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
clusteroperators는 노드에 워크로드를 추가하여 조정하기 시작합니다.
NodePool
오브젝트를 확장할 때 두 개의 머신이 생성된 것을 확인할 수도 있습니다.oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get machines
출력 예
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.12z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.12z
clusterversion
조정은 결국 Ingress 및 Console 클러스터 Operator만 누락되는 시점에 도달합니다.oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version False True 40m Unable to apply 4.12z: the cluster operator console has not yet successfully rolled out NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z False False False 11m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 10m clusteroperator.config.openshift.io/dns 4.12z True False False 9m16s clusteroperator.config.openshift.io/image-registry 4.12z True False False 9m5s clusteroperator.config.openshift.io/ingress 4.12z True False True 39m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing) clusteroperator.config.openshift.io/insights 4.12z True False False 11m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 40m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 10m clusteroperator.config.openshift.io/monitoring 4.12z True False False 7m38s clusteroperator.config.openshift.io/network 4.12z True False False 11m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 8m54s clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 40m clusteroperator.config.openshift.io/service-ca 4.12z True False False 11m clusteroperator.config.openshift.io/storage 4.12z True False False 11m
1.7.4.7. Ingress 처리
모든 OpenShift Container Platform 클러스터는 기본 애플리케이션 인그레스 컨트롤러에서 설정되며, 이 컨트롤러와 연결된 외부 DNS 레코드가 필요합니다. 예를 들어 기본 도메인 krnl.es
를 사용하여 example
이라는 HyperShift 클러스터를 생성하는 경우 와일드카드 도메인 *.apps.example.krnl.es
를 라우팅할 수 있습니다.
*.apps
.apps에 로드 밸런서 및 와일드카드 DNS 레코드를 설정할 수 있습니다. 이 프로세스에서는 CloudEvent를 배포하고, 인그레스 배포로 라우팅하는 새 로드 밸런서 서비스를 구성하고, 로드 밸런서 IP 주소에 와일드카드 DNS 항목을 할당해야 합니다.
LoadBalancer
유형의 서비스를 생성할 때 service에 대한 외부 IP 주소를 추가하도록 CloudEvent를 설정합니다.cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - --- apiVersion: v1 kind: Namespace metadata: name: metallb labels: openshift.io/cluster-monitoring: "true" annotations: workload.openshift.io/allowed: management --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: metallb-operator-operatorgroup namespace: metallb --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: metallb-operator namespace: metallb spec: channel: "stable" name: metallb-operator source: redhat-operators sourceNamespace: openshift-marketplace
Operator가 실행된 후 CloudEvent 인스턴스를 생성합니다.
cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb EOF
단일 IP 주소로
IPAddressPool
을 생성하여 ScanSetting Operator를 구성합니다. 이 IP 주소는 클러스터 노드가 사용하는 네트워크와 동일한 서브넷에 있어야 합니다.중요:
INGRESS_IP
환경 변수를 사용자 환경 주소와 일치하도록 변경합니다.export INGRESS_IP=192.168.122.23 envsubst <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: ingress-public-ip namespace: metallb spec: protocol: layer2 autoAssign: false addresses: - ${INGRESS_IP}-${INGRESS_IP} EOF
다음 단계에 따라 CloudEvent를 통해 OpenShift Container Platform 라우터를 노출합니다.
수신 트래픽을 수신 배포로 라우팅하는 LoadBalancer 서비스를 설정합니다.
cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - kind: Service apiVersion: v1 metadata: annotations: metallb.universe.tf/address-pool: ingress-public-ip name: metallb-ingress namespace: openshift-ingress spec: ports: - name: http protocol: TCP port: 80 targetPort: 80 - name: https protocol: TCP port: 443 targetPort: 443 selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default type: LoadBalancer EOF
OpenShift Container Platform 콘솔에 연결하려면 다음 명령을 입력합니다.
curl -kI https://console-openshift-console.apps.example.krnl.es HTTP/1.1 200 OK
clusterversion
및clusteroperator
값을 확인하여 모든 항목이 실행 중인지 확인합니다. 다음 명령을 실행합니다.oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co
출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.12z True False 3m32s Cluster version is 4.12z NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z True False False 3m50s clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 25m clusteroperator.config.openshift.io/dns 4.12z True False False 23m clusteroperator.config.openshift.io/image-registry 4.12z True False False 23m clusteroperator.config.openshift.io/ingress 4.12z True False False 53m clusteroperator.config.openshift.io/insights 4.12z True False False 25m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 54m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 25m clusteroperator.config.openshift.io/monitoring 4.12z True False False 21m clusteroperator.config.openshift.io/network 4.12z True False False 25m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 23m clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 54m clusteroperator.config.openshift.io/service-ca 4.12z True False False 25m clusteroperator.config.openshift.io/storage 4.12z True False False 25m
1.7.4.8. 호스팅된 클러스터의 노드 자동 확장 활성화
호스트 클러스터에 더 많은 용량이 필요하고 예비 에이전트를 사용할 수 있는 경우 자동 스케일링을 활성화하여 새 에이전트를 설치할 수 있습니다.
자동 확장을 활성화하려면 다음 명령을 입력합니다. 이 경우 최소 노드 수는 2이고 최대 개수는 5입니다.
oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
추가 용량을 요구하지 않고 10분이 경과하면 에이전트가 해제되어 예비 대기열에 다시 배치됩니다.
새 노드가 필요한 워크로드를 생성합니다.
cat <<EOF | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f - apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: reversewords name: reversewords namespace: default spec: replicas: 40 selector: matchLabels: app: reversewords strategy: {} template: metadata: creationTimestamp: null labels: app: reversewords spec: containers: - image: quay.io/mavazque/reversewords:latest name: reversewords resources: requests: memory: 2Gi status: {} EOF
다음 명령을 입력하여 나머지 에이전트가 배포되었는지 확인합니다. 이 예에서는 예비 에이전트인
d9198891-39f4-4930-a679-65fb142b108b
가 프로비저닝됩니다.oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
출력 예
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: installing-in-progress BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster
다음 명령을 입력하여 노드를 확인하면 새 노드가 출력에 표시됩니다. 이 예에서는
ocp-worker-0
이 클러스터에 추가되었습니다.oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
출력 예
NAME STATUS ROLES AGE VERSION ocp-worker-0 Ready worker 35s v1.24.0+3882f8f ocp-worker-1 Ready worker 40m v1.24.0+3882f8f ocp-worker-2 Ready worker 41m v1.24.0+3882f8f
노드를 삭제하려면 다음 명령을 입력하여 워크로드를 삭제합니다.
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig -n default delete deployment reversewords
10분 동안 기다린 후 다음 명령을 입력하여 노드가 제거되었는지 확인합니다.
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
출력 예
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 51m v1.24.0+3882f8f ocp-worker-2 Ready worker 52m v1.24.0+3882f8f
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}' BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster
1.7.4.9. 호스트된 클러스터 생성 확인
배포 프로세스가 완료되면 호스팅된 클러스터가 성공적으로 생성되었는지 확인할 수 있습니다. 호스팅된 클러스터를 생성한 후 몇 분 후에 다음 단계를 따르십시오.
extract 명령을 입력하여 새 호스트 클러스터의 kubeconfig를 가져옵니다.
oc extract -n kni21 secret/kni21-admin-kubeconfig --to=- > kubeconfig-kni21 # kubeconfig
kubeconfig를 사용하여 호스팅 클러스터의 클러스터 Operator를 봅니다. 다음 명령을 실행합니다.
oc get co --kubeconfig=kubeconfig-kni21
출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s image-registry 4.10.26 True False False 2m8s ingress 4.10.26 True False False 22m kube-apiserver 4.10.26 True False False 23m kube-controller-manager 4.10.26 True False False 23m kube-scheduler 4.10.26 True False False 23m kube-storage-version-migrator 4.10.26 True False False 4m52s monitoring 4.10.26 True False False 69s network 4.10.26 True False False 4m3s node-tuning 4.10.26 True False False 2m22s openshift-apiserver 4.10.26 True False False 23m openshift-controller-manager 4.10.26 True False False 23m openshift-samples 4.10.26 True False False 2m15s operator-lifecycle-manager 4.10.26 True False False 22m operator-lifecycle-manager-catalog 4.10.26 True False False 23m operator-lifecycle-manager-packageserver 4.10.26 True False False 23m service-ca 4.10.26 True False False 4m41s storage 4.10.26 True False False 4m43s
다음 명령을 입력하여 호스팅된 클러스터에서 실행 중인 Pod를 볼 수도 있습니다.
oc get pods -A --kubeconfig=kubeconfig-kni21
출력 예
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s kube-system konnectivity-agent-nrbvw 0/1 Running 0 4m24s kube-system konnectivity-agent-s5p7g 0/1 Running 0 4m14s kube-system kube-apiserver-proxy-asus3-vm1.kni.schmaustech.com 1/1 Running 0 5m56s kube-system kube-apiserver-proxy-asus3-vm2.kni.schmaustech.com 1/1 Running 0 6m37s kube-system kube-apiserver-proxy-asus3-vm3.kni.schmaustech.com 1/1 Running 0 6m17s openshift-cluster-node-tuning-operator cluster-node-tuning-operator-798fcd89dc-9cf2k 1/1 Running 0 20m openshift-cluster-node-tuning-operator tuned-dhw5p 1/1 Running 0 109s openshift-cluster-node-tuning-operator tuned-dlp8f 1/1 Running 0 110s openshift-cluster-node-tuning-operator tuned-l569k 1/1 Running 0 109s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-cluster-storage-operator cluster-storage-operator-5f784969f5-vwzgz 1/1 Running 1 (113s ago) 20m openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-7nrfw 1/1 Running 0 3m8s openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-csksg 1/1 Running 0 3m9s openshift-cluster-storage-operator csi-snapshot-controller-operator-7f4d9fc5b8-hkvrk 1/1 Running 0 20m openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-7qltn 1/1 Running 0 3m12s openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-f8bqk 1/1 Running 0 3m12s openshift-console-operator console-operator-8675b58c4c-flc5p 1/1 Running 1 (96s ago) 20m openshift-console console-5cbf6c7969-6gk6z 1/1 Running 0 119s openshift-console downloads-7bcd756565-6wj5j 1/1 Running 0 4m3s openshift-dns-operator dns-operator-77d755cd8c-xjfbn 2/2 Running 0 21m openshift-dns dns-default-jwjkz 2/2 Running 0 113s openshift-dns dns-default-kfqnh 2/2 Running 0 113s openshift-dns dns-default-xlqsm 2/2 Running 0 113s openshift-dns node-resolver-jzxnd 1/1 Running 0 110s openshift-dns node-resolver-xqdr5 1/1 Running 0 110s openshift-dns node-resolver-zl6h4 1/1 Running 0 110s openshift-image-registry cluster-image-registry-operator-64fcfdbf5-r7d5t 1/1 Running 0 20m openshift-image-registry image-registry-7fdfd99d68-t9pq9 1/1 Running 0 53s openshift-image-registry node-ca-hkfnr 1/1 Running 0 56s openshift-image-registry node-ca-vlsdl 1/1 Running 0 56s openshift-image-registry node-ca-xqnsw 1/1 Running 0 56s openshift-ingress-canary ingress-canary-86z6r 1/1 Running 0 4m13s openshift-ingress-canary ingress-canary-8jhxk 1/1 Running 0 3m52s openshift-ingress-canary ingress-canary-cv45h 1/1 Running 0 4m24s openshift-ingress router-default-6bb8944f66-z2lxr 1/1 Running 0 20m openshift-kube-storage-version-migrator-operator kube-storage-version-migrator-operator-56b57b4844-p9zgp 1/1 Running 1 (2m16s ago) 20m openshift-kube-storage-version-migrator migrator-58bb4d89d5-5sl9w 1/1 Running 0 3m30s openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring cluster-monitoring-operator-5bc5885cd4-dwbc4 2/2 Running 0 20m openshift-monitoring grafana-78f798868c-wd84p 3/3 Running 0 94s openshift-monitoring kube-state-metrics-58b8f97f6c-6kp4v 3/3 Running 0 104s openshift-monitoring node-exporter-ll7cp 2/2 Running 0 103s openshift-monitoring node-exporter-tgsqg 2/2 Running 0 103s openshift-monitoring node-exporter-z99gr 2/2 Running 0 103s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s openshift-monitoring prometheus-adapter-f69fff5f9-7tdn9 0/1 Running 0 17s openshift-monitoring prometheus-k8s-0 6/6 Running 0 93s openshift-monitoring prometheus-operator-6b9d4fd9bd-tqfcx 2/2 Running 0 2m2s openshift-monitoring telemeter-client-74d599658c-wqw5j 3/3 Running 0 101s openshift-monitoring thanos-querier-64c8757854-z4lll 6/6 Running 0 98s openshift-multus multus-additional-cni-plugins-cqst9 1/1 Running 0 6m14s openshift-multus multus-additional-cni-plugins-dbmkj 1/1 Running 0 5m56s openshift-multus multus-additional-cni-plugins-kcwl9 1/1 Running 0 6m14s openshift-multus multus-admission-controller-22cmb 2/2 Running 0 3m52s openshift-multus multus-admission-controller-256tn 2/2 Running 0 4m13s openshift-multus multus-admission-controller-mz9jm 2/2 Running 0 4m24s openshift-multus multus-bxgvr 1/1 Running 0 6m14s openshift-multus multus-dmkdc 1/1 Running 0 6m14s openshift-multus multus-gqw2f 1/1 Running 0 5m56s openshift-multus network-metrics-daemon-6cx4x 2/2 Running 0 5m56s openshift-multus network-metrics-daemon-gz4jp 2/2 Running 0 6m13s openshift-multus network-metrics-daemon-jq9j4 2/2 Running 0 6m13s openshift-network-diagnostics network-check-source-8497dc8f86-cn4nm 1/1 Running 0 5m59s openshift-network-diagnostics network-check-target-d8db9 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-jdbv8 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-zzmdv 1/1 Running 0 5m55s openshift-network-operator network-operator-f5b48cd67-x5dcz 1/1 Running 0 21m openshift-sdn sdn-452r2 2/2 Running 0 5m56s openshift-sdn sdn-68g69 2/2 Running 0 6m openshift-sdn sdn-controller-4v5mv 2/2 Running 0 5m56s openshift-sdn sdn-controller-crscc 2/2 Running 0 6m1s openshift-sdn sdn-controller-fxtn9 2/2 Running 0 6m1s openshift-sdn sdn-n5jm5 2/2 Running 0 6m openshift-service-ca-operator service-ca-operator-5bf7f9d958-vnqcg 1/1 Running 1 (2m ago) 20m openshift-service-ca service-ca-6c54d7944b-v5mrw 1/1 Running 0 3m8s
1.7.4.10. 베어 메탈에서 호스트된 클러스터 삭제
콘솔을 사용하여 베어 메탈 호스트 클러스터를 제거할 수 있습니다. 베어 메탈에서 호스팅된 클러스터를 삭제하려면 다음 단계를 완료합니다.
- 콘솔에서 Infrastructure > Clusters 로 이동합니다.
- 클러스터 페이지에서 삭제할 클러스터를 선택합니다.
- 작업 메뉴에서 클러스터 삭제 를 선택하여 클러스터를 제거합니다.
1.7.4.11. 추가 리소스
- CloudEvent에 대한 자세한 내용은 OpenShift Container Platform 설명서의 About CloudEvent 및 the 10.0.0.1 Operator 를 참조하십시오.
-
rootDeviceHints
에 대한 자세한 내용은 BareMetalHost 설명서의 rootDeviceHints 섹션 을 참조하십시오.
1.7.5. 호스팅된 컨트롤 플레인 기능 비활성화
HyperShift Operator를 설치 제거하고 호스팅 컨트롤 플레인을 비활성화할 수 있습니다. 호스팅된 컨트롤 플레인 클러스터 기능을 비활성화하는 경우 호스팅된 컨트롤 플레인 클러스터 항목에 설명된 대로 멀티 클러스터 엔진 Operator에서 호스팅 클러스터 및 관리 클러스터 리소스를 제거해야 합니다.
1.7.5.1. HyperShift Operator 설치 제거
HyperShift Operator를 제거하고 로컬 클러스터에서
hypershift-addon
을 비활성화하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 실행 중인 호스팅 클러스터가 없는지 확인합니다.
oc get hostedcluster -A
중요: 호스트된 클러스터가 실행 중인 경우
hypershift-addon
이 비활성화된 경우에도 HyperShift Operator가 제거되지 않습니다.다음 명령을 실행하여
hypershift-addon
을 비활성화합니다.oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'
팁:
hypershift-addon
을 비활성화한 후 다중클러스터 엔진 Operator 콘솔에서 로컬
클러스터에 대한hypershift-addon
을 비활성화할 수도 있습니다.
1.7.5.2. 호스팅된 컨트롤 플레인 기능 비활성화
호스트된 컨트롤 플레인 기능을 비활성화하기 전에 HyperShift Operator를 먼저 제거해야 합니다. 다음 명령을 실행하여 호스팅된 컨트롤 플레인 기능을 비활성화합니다.
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": false}]}}}'
다음 명령을 실행하여 MultiClusterEngine
사용자 정의 리소스에서 hypershift-preview
및 hypershift-local-hosting
기능이 비활성화되어 있는지 확인할 수 있습니다.
oc get mce multiclusterengine -o yaml
hypershift-preview
및 hypershift-local-hosting
의 enabled:
플래그가 false
로 설정된 다음 예제를 참조하십시오.
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: hypershift-preview enabled: false - name: hypershift-local-hosting enabled: false
1.7.5.3. 추가 리소스
1.8. api
다중 클러스터 엔진 Operator를 사용하여 클러스터 라이프사이클 관리를 위한 다음 API에 액세스할 수 있습니다. 사용자 필수 액세스: 역할이 할당된 작업만 수행할 수 있습니다. 자세한 내용은 다음 리소스 각각에 대한 API 설명서를 참조하십시오.
1.8.1. 클러스터 API
1.8.1.1. 개요
이 문서는 Kubernetes용 다중 클러스터 엔진의 클러스터 리소스에 대한 것입니다. 클러스터 리소스에는 생성, 쿼리, 삭제 및 업데이트 등 네 가지 요청이 있습니다.
1.8.1.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.1.1.2. 태그
- cluster.open-cluster-management.io : 클러스터 생성 및 관리
1.8.1.2. 경로
1.8.1.2.1. 모든 클러스터 쿼리
GET /cluster.open-cluster-management.io/v1/managedclusters
1.8.1.2.1.1. 설명
자세한 내용은 클러스터를 쿼리합니다.
1.8.1.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
1.8.1.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.1.2.1.4. Use
-
cluster/yaml
1.8.1.2.1.5. 태그
- cluster.open-cluster-management.io
1.8.1.2.2. 클러스터 생성
POST /cluster.open-cluster-management.io/v1/managedclusters
1.8.1.2.2.1. 설명
클러스터 생성
1.8.1.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
body |
본문 | 생성할 클러스터를 설명하는 매개변수입니다. |
1.8.1.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.1.2.2.4. Use
-
cluster/yaml
1.8.1.2.2.5. 태그
- cluster.open-cluster-management.io
1.8.1.2.2.6. HTTP 요청의 예
1.8.1.2.2.6.1. 요청 본문
{ "apiVersion" : "cluster.open-cluster-management.io/v1", "kind" : "ManagedCluster", "metadata" : { "labels" : { "vendor" : "OpenShift" }, "name" : "cluster1" }, "spec": { "hubAcceptsClient": true, "managedClusterClientConfigs": [ { "caBundle": "test", "url": "https://test.com" } ] }, "status" : { } }
1.8.1.2.3. 단일 클러스터 쿼리
GET /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
1.8.1.2.3.1. 설명
자세한 내용은 단일 클러스터를 쿼리합니다.
1.8.1.2.3.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
cluster_name | 쿼리할 클러스터의 이름입니다. | string |
1.8.1.2.3.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.1.2.3.4. 태그
- cluster.open-cluster-management.io
1.8.1.2.4. 클러스터 삭제
DELETE /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
1.8.1.2.4.1. 설명
단일 클러스터 삭제
1.8.1.2.4.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
cluster_name | 삭제할 클러스터의 이름입니다. | string |
1.8.1.2.4.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.1.2.4.4. 태그
- cluster.open-cluster-management.io
1.8.1.3. 정의
1.8.1.3.1. Cluster
이름 | 스키마 |
---|---|
apiVersion | string |
kind | string |
메타데이터 | object |
spec |
spec
이름 | 스키마 |
---|---|
hubAcceptsClient | bool |
managedClusterClientConfigs | < managedClusterClientConfigs > array |
leaseDurationSeconds | 정수(int32) |
managedClusterClientConfigs
이름 | 설명 | 스키마 |
---|---|---|
URL | string | |
cabundle | 패턴 : "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$" | 문자열(바이트) |
1.8.2. Clustersets API (v1beta2)
1.8.2.1. 개요
이 문서는 Kubernetes용 다중 클러스터 엔진의 Clusterset 리소스에 대한 것입니다. Clusterset 리소스에는 생성, 쿼리, 삭제 및 업데이트 등 네 가지 요청이 있습니다.
1.8.2.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.2.1.2. 태그
- cluster.open-cluster-management.io : Clustersets 생성 및 관리
1.8.2.2. 경로
1.8.2.2.1. 모든 클러스터 세트 쿼리
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets
1.8.2.2.1.1. 설명
자세한 내용은 클러스터 세트를 쿼리합니다.
1.8.2.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
1.8.2.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.2.2.1.4. Use
-
clusterset/yaml
1.8.2.2.1.5. 태그
- cluster.open-cluster-management.io
1.8.2.2.2. 클러스터 세트 생성
POST /cluster.open-cluster-management.io/v1beta2/managedclustersets
1.8.2.2.2.1. 설명
클러스터 세트를 생성합니다.
1.8.2.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
body |
본문 | 생성할 clusterset을 설명하는 매개변수입니다. |
1.8.2.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.2.2.2.4. Use
-
clusterset/yaml
1.8.2.2.2.5. 태그
- cluster.open-cluster-management.io
1.8.2.2.2.6. HTTP 요청의 예
1.8.2.2.2.6.1. 요청 본문
{ "apiVersion" : "cluster.open-cluster-management.io/v1beta2", "kind" : "ManagedClusterSet", "metadata" : { "name" : "clusterset1" }, "spec": { }, "status" : { } }
1.8.2.2.3. 단일 클러스터 세트 쿼리
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
1.8.2.2.3.1. 설명
자세한 내용은 단일 클러스터 세트를 쿼리합니다.
1.8.2.2.3.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
clusterset_name | 쿼리할 클러스터 세트의 이름입니다. | string |
1.8.2.2.3.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.2.2.3.4. 태그
- cluster.open-cluster-management.io
1.8.2.2.4. 클러스터 세트 삭제
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
1.8.2.2.4.1. 설명
단일 클러스터 세트를 삭제합니다.
1.8.2.2.4.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
clusterset_name | 삭제할 클러스터 세트의 이름입니다. | string |
1.8.2.2.4.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.2.2.4.4. 태그
- cluster.open-cluster-management.io
1.8.2.3. 정의
1.8.2.3.1. Clusterset
이름 | 스키마 |
---|---|
apiVersion | string |
kind | string |
메타데이터 | object |
1.8.3. Clustersetbindings API (v1beta2)
1.8.3.1. 개요
이 문서는 Kubernetes의 다중 클러스터 엔진의 clustersetbinding 리소스에 대한 것입니다. Clustersetbinding 리소스에는 생성, 쿼리, 삭제, 업데이트 등 네 가지 요청이 있습니다.
1.8.3.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.3.1.2. 태그
- cluster.open-cluster-management.io : clustersetbindings 생성 및 관리
1.8.3.2. 경로
1.8.3.2.1. 모든 clustersetbindings 쿼리
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
1.8.3.2.1.1. 설명
자세한 내용은 clustersetbindings를 쿼리합니다.
1.8.3.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
네임스페이스 | 사용하려는 네임스페이스(예: default)입니다. | string |
1.8.3.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.3.2.1.4. Use
-
clustersetbinding/yaml
1.8.3.2.1.5. 태그
- cluster.open-cluster-management.io
1.8.3.2.2. clustersetbinding 생성
POST /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
1.8.3.2.2.1. 설명
clustersetbinding을 생성합니다.
1.8.3.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
네임스페이스 | 사용하려는 네임스페이스(예: default)입니다. | string |
body |
본문 | 생성할 clustersetbinding을 설명하는 매개변수입니다. |
1.8.3.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.3.2.2.4. Use
-
clustersetbinding/yaml
1.8.3.2.2.5. 태그
- cluster.open-cluster-management.io
1.8.3.2.2.6. HTTP 요청의 예
1.8.3.2.2.6.1. 요청 본문
{ "apiVersion" : "cluster.open-cluster-management.io/v1", "kind" : "ManagedClusterSetBinding", "metadata" : { "name" : "clusterset1", "namespace" : "ns1" }, "spec": { "clusterSet": "clusterset1" }, "status" : { } }
1.8.3.2.3. 단일 clustersetbinding 쿼리
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings/{clustersetbinding_name}
1.8.3.2.3.1. 설명
자세한 내용은 단일 clustersetbinding을 쿼리합니다.
1.8.3.2.3.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
네임스페이스 | 사용하려는 네임스페이스(예: default)입니다. | string |
경로 |
clustersetbinding_name | 쿼리할 clustersetbinding의 이름입니다. | string |
1.8.3.2.3.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.3.2.3.4. 태그
- cluster.open-cluster-management.io
1.8.3.2.4. clustersetbinding 삭제
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersetbindings/{clustersetbinding_name}
1.8.3.2.4.1. 설명
단일 clustersetbinding을 삭제합니다.
1.8.3.2.4.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
네임스페이스 | 사용하려는 네임스페이스(예: default)입니다. | string |
경로 |
clustersetbinding_name | 삭제할 clustersetbinding의 이름입니다. | string |
1.8.3.2.4.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.3.2.4.4. 태그
- cluster.open-cluster-management.io
1.8.3.3. 정의
1.8.3.3.1. clustersetbinding
이름 | 스키마 |
---|---|
apiVersion | string |
kind | string |
메타데이터 | object |
spec |
spec
이름 | 스키마 |
---|---|
clusterSet | string |
1.8.4. Clusterview API (v1alpha1)
1.8.4.1. 개요
이 문서는 Kubernetes용 다중 클러스터 엔진의 clusterview
리소스에 대한 것입니다. clusterview
리소스는 액세스할 수 있는 관리형 클러스터 및 관리형 클러스터 세트의 목록을 볼 수 있는 CLI 명령을 제공합니다. 사용 가능한 세 가지 요청은 list, get, watch입니다.
1.8.4.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.4.1.2. 태그
- clusterview.open-cluster-management.io: ID에서 액세스할 수 있는 관리형 클러스터 목록을 확인합니다.
1.8.4.2. 경로
1.8.4.2.1. 관리 클러스터 가져오기
GET /managedclusters.clusterview.open-cluster-management.io
1.8.4.2.1.1. 설명
액세스할 수 있는 관리형 클러스터 목록을 확인합니다.
1.8.4.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
1.8.4.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.4.2.1.4. Use
-
managedcluster/yaml
1.8.4.2.1.5. 태그
- clusterview.open-cluster-management.io
1.8.4.2.2. 관리형 클러스터 나열
LIST /managedclusters.clusterview.open-cluster-management.io
1.8.4.2.2.1. 설명
액세스할 수 있는 관리형 클러스터 목록을 확인합니다.
1.8.4.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
body |
본문 | 관리 클러스터를 나열할 사용자 ID의 이름입니다. | string |
1.8.4.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.4.2.2.4. Use
-
managedcluster/yaml
1.8.4.2.2.5. 태그
- clusterview.open-cluster-management.io
1.8.4.2.2.6. HTTP 요청의 예
1.8.4.2.2.6.1. 요청 본문
{ "apiVersion" : "clusterview.open-cluster-management.io/v1alpha1", "kind" : "ClusterView", "metadata" : { "name" : "<user_ID>" }, "spec": { }, "status" : { } }
1.8.4.2.3. 관리형 클러스터 세트 조사
WATCH /managedclusters.clusterview.open-cluster-management.io
1.8.4.2.3.1. 설명
액세스할 수 있는 관리형 클러스터를 확인합니다.
1.8.4.2.3.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
clusterview_name | 조사할 사용자 ID의 이름입니다. | string |
1.8.4.2.3.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.4.2.4. 관리형 클러스터 세트를 나열합니다.
GET /managedclustersets.clusterview.open-cluster-management.io
1.8.4.2.4.1. 설명
액세스할 수 있는 관리형 클러스터를 나열합니다.
1.8.4.2.4.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
clusterview_name | 조사할 사용자 ID의 이름입니다. | string |
1.8.4.2.4.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.4.2.5. 관리형 클러스터 세트를 나열합니다.
LIST /managedclustersets.clusterview.open-cluster-management.io
1.8.4.2.5.1. 설명
액세스할 수 있는 관리형 클러스터를 나열합니다.
1.8.4.2.5.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
clusterview_name | 조사할 사용자 ID의 이름입니다. | string |
1.8.4.2.5.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.4.2.6. 관리형 클러스터 세트를 확인합니다.
WATCH /managedclustersets.clusterview.open-cluster-management.io
1.8.4.2.6.1. 설명
액세스할 수 있는 관리형 클러스터를 확인합니다.
1.8.4.2.6.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
clusterview_name | 조사할 사용자 ID의 이름입니다. | string |
1.8.4.2.6.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.5. 관리형 서비스 계정(기술 프리뷰)
1.8.5.1. 개요
이 문서는 다중 클러스터 엔진 Operator의 ManagedServiceAccount
리소스에 대한 것입니다. ManagedServiceAccount
리소스에는 생성, 쿼리, 삭제, 업데이트 등 네 가지 요청이 있습니다.
1.8.5.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.5.1.2. 태그
-
Managed
serviceaccounts.multicluster.openshift.io'
:ManagedServiceAccounts
생성 및 관리
1.8.5.2. 경로
1.8.5.2.1. Create a ManagedServiceAccount
POST /apis/multicluster.openshift.io/v1alpha1/ManagedServiceAccounts
1.8.5.2.1.1. 설명
ManagedServiceAccount
를 생성합니다.
1.8.5.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
body |
본문 | 생성할 ManagedServiceAccount를 설명하는 매개변수입니다. | ManagedServiceAccount |
1.8.5.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.5.2.1.4. Use
-
managedserviceaccount/yaml
1.8.5.2.1.5. 태그
- managedserviceaccount.multicluster.openshift.io
1.8.5.2.1.5.1. 요청 본문
{ "apiVersion": "apiextensions.k8s.io/v1", "kind": "CustomResourceDefinition", "metadata": { "annotations": { "controller-gen.kubebuilder.io/version": "v0.4.1" }, "creationTimestamp": null, "name": "managedserviceaccount.authentication.open-cluster-management.io" }, "spec": { "group": "authentication.open-cluster-management.io", "names": { "kind": "ManagedServiceAccount", "listKind": "ManagedServiceAccountList", "plural": "managedserviceaccounts", "singular": "managedserviceaccount" }, "scope": "Namespaced", "versions": [ { "name": "v1alpha1", "schema": { "openAPIV3Schema": { "description": "ManagedServiceAccount is the Schema for the managedserviceaccounts\nAPI", "properties": { "apiVersion": { "description": "APIVersion defines the versioned schema of this representation\nof an object. Servers should convert recognized schemas to the latest\ninternal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources", "type": "string" }, "kind": { "description": "Kind is a string value representing the REST resource this\nobject represents. Servers may infer this from the endpoint the client\nsubmits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds", "type": "string" }, "metadata": { "type": "object" }, "spec": { "description": "ManagedServiceAccountSpec defines the desired state of ManagedServiceAccount", "properties": { "rotation": { "description": "Rotation is the policy for rotation the credentials.", "properties": { "enabled": { "default": true, "description": "Enabled prescribes whether the ServiceAccount token\nwill be rotated from the upstream", "type": "boolean" }, "validity": { "default": "8640h0m0s", "description": "Validity is the duration for which the signed ServiceAccount\ntoken is valid.", "type": "string" } }, "type": "object" }, "ttlSecondsAfterCreation": { "description": "ttlSecondsAfterCreation limits the lifetime of a ManagedServiceAccount.\nIf the ttlSecondsAfterCreation field is set, the ManagedServiceAccount\nwill be automatically deleted regardless of the ManagedServiceAccount's\nstatus. When the ManagedServiceAccount is deleted, its lifecycle\nguarantees (e.g. finalizers) will be honored. If this field is unset,\nthe ManagedServiceAccount won't be automatically deleted. If this\nfield is set to zero, the ManagedServiceAccount becomes eligible\nfor deletion immediately after its creation. In order to use ttlSecondsAfterCreation,\nthe EphemeralIdentity feature gate must be enabled.", "exclusiveMinimum": true, "format": "int32", "minimum": 0, "type": "integer" } }, "required": [ "rotation" ], "type": "object" }, "status": { "description": "ManagedServiceAccountStatus defines the observed state of\nManagedServiceAccount", "properties": { "conditions": { "description": "Conditions is the condition list.", "items": { "description": "Condition contains details for one aspect of the current\nstate of this API Resource. --- This struct is intended for direct\nuse as an array at the field path .status.conditions. For example,\ntype FooStatus struct{ // Represents the observations of a\nfoo's current state. // Known .status.conditions.type are:\n\"Available\", \"Progressing\", and \"Degraded\" // +patchMergeKey=type\n // +patchStrategy=merge // +listType=map // +listMapKey=type\n Conditions []metav1.Condition `json:\"conditions,omitempty\"\npatchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n // other fields }", "properties": { "lastTransitionTime": { "description": "lastTransitionTime is the last time the condition\ntransitioned from one status to another. This should be when\nthe underlying condition changed. If that is not known, then\nusing the time when the API field changed is acceptable.", "format": "date-time", "type": "string" }, "message": { "description": "message is a human readable message indicating\ndetails about the transition. This may be an empty string.", "maxLength": 32768, "type": "string" }, "observedGeneration": { "description": "observedGeneration represents the .metadata.generation\nthat the condition was set based upon. For instance, if .metadata.generation\nis currently 12, but the .status.conditions[x].observedGeneration\nis 9, the condition is out of date with respect to the current\nstate of the instance.", "format": "int64", "minimum": 0, "type": "integer" }, "reason": { "description": "reason contains a programmatic identifier indicating\nthe reason for the condition's last transition. Producers\nof specific condition types may define expected values and\nmeanings for this field, and whether the values are considered\na guaranteed API. The value should be a CamelCase string.\nThis field may not be empty.", "maxLength": 1024, "minLength": 1, "pattern": "^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$", "type": "string" }, "status": { "description": "status of the condition, one of True, False, Unknown.", "enum": [ "True", "False", "Unknown" ], "type": "string" }, "type": { "description": "type of condition in CamelCase or in foo.example.com/CamelCase.\n--- Many .condition.type values are consistent across resources\nlike Available, but because arbitrary conditions can be useful\n(see .node.status.conditions), the ability to deconflict is\nimportant. The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)", "maxLength": 316, "pattern": "^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$", "type": "string" } }, "required": [ "lastTransitionTime", "message", "reason", "status", "type" ], "type": "object" }, "type": "array" }, "expirationTimestamp": { "description": "ExpirationTimestamp is the time when the token will expire.", "format": "date-time", "type": "string" }, "tokenSecretRef": { "description": "TokenSecretRef is a reference to the corresponding ServiceAccount's\nSecret, which stores the CA certficate and token from the managed\ncluster.", "properties": { "lastRefreshTimestamp": { "description": "LastRefreshTimestamp is the timestamp indicating\nwhen the token in the Secret is refreshed.", "format": "date-time", "type": "string" }, "name": { "description": "Name is the name of the referenced secret.", "type": "string" } }, "required": [ "lastRefreshTimestamp", "name" ], "type": "object" } }, "type": "object" } }, "type": "object" } }, "served": true, "storage": true, "subresources": { "status": {} } } ] }, "status": { "acceptedNames": { "kind": "", "plural": "" }, "conditions": [], "storedVersions": [] } }
1.8.5.2.2. 하나의 ManagedServiceAccount 쿼리
GET /cluster.open-cluster-management.io/v1alpha1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
1.8.5.2.2.1. 설명
자세한 내용은 하나의 ManagedServiceAccount
를 쿼리합니다.
1.8.5.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
managedserviceaccount_name |
쿼리할 | string |
1.8.5.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.5.2.2.4. 태그
- cluster.open-cluster-management.io
1.8.5.2.3. ManagedServiceAccount
삭제
DELETE /cluster.open-cluster-management.io/v1alpha1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
1.8.5.2.3.1. 설명
하나의 ManagedServiceAccount
를 삭제합니다.
1.8.5.2.3.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
managedserviceaccount_name |
삭제할 | string |
1.8.5.2.3.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.5.2.3.4. 태그
- cluster.open-cluster-management.io
1.8.5.3. 정의
1.8.5.3.1. ManagedServiceAccount
이름 | 설명 | 스키마 |
---|---|---|
apiVersion |
| string |
kind | REST 리소스를 나타내는 문자열 값입니다. | string |
메타데이터 |
| object |
spec |
|
1.8.6. MultiClusterEngine API
1.8.6.1. 개요
이 문서는 Kubernetes용 다중 클러스터 엔진의 MultiClusterEngine 리소스에 대한 것입니다. MultiClusterEngine
리소스에는 생성, 쿼리, 삭제, 업데이트 등 네 가지 요청이 있습니다.
1.8.6.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.6.1.2. 태그
- Multiclusterengines.multicluster.openshift.io : MultiClusterEngines 생성 및 관리
1.8.6.2. 경로
1.8.6.2.1. Create a MultiClusterEngine
POST /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
1.8.6.2.1.1. 설명
MultiClusterEngine을 생성합니다.
1.8.6.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
body |
본문 | 생성할 MultiClusterEngine을 설명하는 매개변수입니다. | MultiClusterEngine |
1.8.6.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.6.2.1.4. Use
-
MultiClusterEngines/yaml
1.8.6.2.1.5. 태그
- multiclusterengines.multicluster.openshift.io
1.8.6.2.1.5.1. 요청 본문
{ "apiVersion": "apiextensions.k8s.io/v1", "kind": "CustomResourceDefinition", "metadata": { "annotations": { "controller-gen.kubebuilder.io/version": "v0.4.1" }, "creationTimestamp": null, "name": "multiclusterengines.multicluster.openshift.io" }, "spec": { "group": "multicluster.openshift.io", "names": { "kind": "MultiClusterEngine", "listKind": "MultiClusterEngineList", "plural": "multiclusterengines", "shortNames": [ "mce" ], "singular": "multiclusterengine" }, "scope": "Cluster", "versions": [ { "additionalPrinterColumns": [ { "description": "The overall state of the MultiClusterEngine", "jsonPath": ".status.phase", "name": "Status", "type": "string" }, { "jsonPath": ".metadata.creationTimestamp", "name": "Age", "type": "date" } ], "name": "v1alpha1", "schema": { "openAPIV3Schema": { "description": "MultiClusterEngine is the Schema for the multiclusterengines\nAPI", "properties": { "apiVersion": { "description": "APIVersion defines the versioned schema of this representation\nof an object. Servers should convert recognized schemas to the latest\ninternal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources", "type": "string" }, "kind": { "description": "Kind is a string value representing the REST resource this\nobject represents. Servers may infer this from the endpoint the client\nsubmits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds", "type": "string" }, "metadata": { "type": "object" }, "spec": { "description": "MultiClusterEngineSpec defines the desired state of MultiClusterEngine", "properties": { "imagePullSecret": { "description": "Override pull secret for accessing MultiClusterEngine\noperand and endpoint images", "type": "string" }, "nodeSelector": { "additionalProperties": { "type": "string" }, "description": "Set the nodeselectors", "type": "object" }, "targetNamespace": { "description": "Location where MCE resources will be placed", "type": "string" }, "tolerations": { "description": "Tolerations causes all components to tolerate any taints.", "items": { "description": "The pod this Toleration is attached to tolerates any\ntaint that matches the triple <key,value,effect> using the matching\noperator <operator>.", "properties": { "effect": { "description": "Effect indicates the taint effect to match. Empty\nmeans match all taint effects. When specified, allowed values\nare NoSchedule, PreferNoSchedule and NoExecute.", "type": "string" }, "key": { "description": "Key is the taint key that the toleration applies\nto. Empty means match all taint keys. If the key is empty,\noperator must be Exists; this combination means to match all\nvalues and all keys.", "type": "string" }, "operator": { "description": "Operator represents a key's relationship to the\nvalue. Valid operators are Exists and Equal. Defaults to Equal.\nExists is equivalent to wildcard for value, so that a pod\ncan tolerate all taints of a particular category.", "type": "string" }, "tolerationSeconds": { "description": "TolerationSeconds represents the period of time\nthe toleration (which must be of effect NoExecute, otherwise\nthis field is ignored) tolerates the taint. By default, it\nis not set, which means tolerate the taint forever (do not\nevict). Zero and negative values will be treated as 0 (evict\nimmediately) by the system.", "format": "int64", "type": "integer" }, "value": { "description": "Value is the taint value the toleration matches\nto. If the operator is Exists, the value should be empty,\notherwise just a regular string.", "type": "string" } }, "type": "object" }, "type": "array" } }, "type": "object" }, "status": { "description": "MultiClusterEngineStatus defines the observed state of MultiClusterEngine", "properties": { "components": { "items": { "description": "ComponentCondition contains condition information for\ntracked components", "properties": { "kind": { "description": "The resource kind this condition represents", "type": "string" }, "lastTransitionTime": { "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.", "format": "date-time", "type": "string" }, "message": { "description": "Message is a human-readable message indicating\ndetails about the last status change.", "type": "string" }, "name": { "description": "The component name", "type": "string" }, "reason": { "description": "Reason is a (brief) reason for the condition's\nlast status change.", "type": "string" }, "status": { "description": "Status is the status of the condition. One of True,\nFalse, Unknown.", "type": "string" }, "type": { "description": "Type is the type of the cluster condition.", "type": "string" } }, "type": "object" }, "type": "array" }, "conditions": { "items": { "properties": { "lastTransitionTime": { "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.", "format": "date-time", "type": "string" }, "lastUpdateTime": { "description": "The last time this condition was updated.", "format": "date-time", "type": "string" }, "message": { "description": "Message is a human-readable message indicating\ndetails about the last status change.", "type": "string" }, "reason": { "description": "Reason is a (brief) reason for the condition's\nlast status change.", "type": "string" }, "status": { "description": "Status is the status of the condition. One of True,\nFalse, Unknown.", "type": "string" }, "type": { "description": "Type is the type of the cluster condition.", "type": "string" } }, "type": "object" }, "type": "array" }, "phase": { "description": "Latest observed overall state", "type": "string" } }, "type": "object" } }, "type": "object" } }, "served": true, "storage": true, "subresources": { "status": {} } } ] }, "status": { "acceptedNames": { "kind": "", "plural": "" }, "conditions": [], "storedVersions": [] } }
1.8.6.2.2. 모든 MultiClusterEngines 쿼리
GET /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
1.8.6.2.2.1. 설명
자세한 내용은 다중 클러스터 엔진을 쿼리합니다.
1.8.6.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
1.8.6.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.6.2.2.4. Use
-
operator/yaml
1.8.6.2.2.5. 태그
- multiclusterengines.multicluster.openshift.io
1.8.6.2.3. MultiClusterEngine Operator 삭제
DELETE /apis/multicluster.openshift.io/v1alpha1/multiclusterengines/{name}
1.8.6.2.3.1. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
이름 | 삭제할 다중 클러스터 엔진의 이름입니다. | string |
1.8.6.2.3.2. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.6.2.3.3. 태그
- multiclusterengines.multicluster.openshift.io
1.8.6.3. 정의
1.8.6.3.1. MultiClusterEngine
이름 | 설명 | 스키마 |
---|---|---|
apiVersion | 버전이 지정된 MultiClusterEngines 스키마입니다. | string |
kind | REST 리소스를 나타내는 문자열 값입니다. | string |
메타데이터 | 리소스를 정의하는 규칙을 설명합니다. | object |
spec | MultiClusterEngineSpec은 원하는 MultiClusterEngine 상태를 정의합니다. | 사양 목록보기 |
1.8.6.3.2. 사양 목록
이름 | 설명 | 스키마 |
---|---|---|
nodeSelector | 노드 선택기를 설정합니다. | map[string]string |
imagePullSecret | MultiClusterEngine 피연산자 및 끝점 이미지에 액세스하기 위해 가져오기 보안을 재정의합니다. | string |
허용 오차 | 허용 오차는 모든 구성 요소가 테인트를 허용하도록 합니다. | []corev1.Toleration |
targetNamespace | MCE 리소스가 배치될 위치입니다. | string |
1.8.7. placements API (v1beta1)
1.8.7.1. 개요
이 문서는 Kubernetes용 다중 클러스터 엔진의 배치 리소스에 대한 것입니다. 배치 리소스에는 생성, 쿼리, 삭제 및 업데이트 등 네 가지 요청이 있습니다.
1.8.7.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.7.1.2. 태그
- cluster.open-cluster-management.io : 배치 생성 및 관리
1.8.7.2. 경로
1.8.7.2.1. 모든 배치 쿼리
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
1.8.7.2.1.1. 설명
자세한 내용은 배치를 쿼리합니다.
1.8.7.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
1.8.7.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.7.2.1.4. Use
-
placement/yaml
1.8.7.2.1.5. 태그
- cluster.open-cluster-management.io
1.8.7.2.2. 배치 생성
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
1.8.7.2.2.1. 설명
배치 생성.
1.8.7.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
body |
본문 | 생성할 배치를 설명하는 매개변수입니다. |
1.8.7.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.7.2.2.4. Use
-
placement/yaml
1.8.7.2.2.5. 태그
- cluster.open-cluster-management.io
1.8.7.2.2.6. HTTP 요청의 예
1.8.7.2.2.6.1. 요청 본문
{ "apiVersion" : "cluster.open-cluster-management.io/v1beta1", "kind" : "Placement", "metadata" : { "name" : "placement1", "namespace": "ns1" }, "spec": { "predicates": [ { "requiredClusterSelector": { "labelSelector": { "matchLabels": { "vendor": "OpenShift" } } } } ] }, "status" : { } }
1.8.7.2.3. 단일 배치 쿼리
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
1.8.7.2.3.1. 설명
자세한 내용은 단일 배치를 쿼리합니다.
1.8.7.2.3.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
placement_name | 쿼리할 배치의 이름입니다. | string |
1.8.7.2.3.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.7.2.3.4. 태그
- cluster.open-cluster-management.io
1.8.7.2.4. 배치 삭제
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
1.8.7.2.4.1. 설명
단일 배치 삭제.
1.8.7.2.4.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
placement_name | 삭제할 배치의 이름입니다. | string |
1.8.7.2.4.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.7.2.4.4. 태그
- cluster.open-cluster-management.io
1.8.7.3. 정의
1.8.7.3.1. placement
이름 | 설명 | 스키마 |
---|---|---|
apiVersion | 배치의 버전이 지정된 스키마입니다. | string |
kind | REST 리소스를 나타내는 문자열 값입니다. | string |
메타데이터 | 배치의 메타 데이터입니다. | object |
spec | 배치 사양입니다. |
spec
이름 | 설명 | 스키마 |
---|---|---|
ClusterSets | ManagedClusters가 선택된 ManagedClusterSets의 하위 집합입니다. 비어 있는 경우 배치 네임스페이스에 바인딩된 ManagedClusterSets에서 ManagedClusters가 선택됩니다. 그렇지 않으면 ManagedClusters가 이 하위 집합의 교집합에서 선택되고 ManagedClusterSets는 placement 네임스페이스에 바인딩됩니다. | 문자열 배열 |
numberOfClusters | 선택할 ManagedCluster의 수입니다. | 정수(int32) |
서술자 | ManagedClusters를 선택할 클러스터 서술자의 하위 집합입니다. 조건부 논리는 OR 입니다. |
clusterPredicate
이름 | 설명 | 스키마 |
---|---|---|
requiredClusterSelector | 레이블 및 클러스터 클레임을 사용하여 ManagedClusters를 선택하는 클러스터 선택기입니다. |
clusterSelector
이름 | 설명 | 스키마 |
---|---|---|
labelSelector | 라벨별 ManagedClusters의 선택기입니다. | object |
claimSelector | 클레임별 ManagedClusters의 선택기입니다. |
clusterClaimSelector
이름 | 설명 | 스키마 |
---|---|---|
matchExpressions | 클러스터 클레임 선택기 요구 사항의 하위 집합입니다. 조건부 논리는 AND 입니다. | < object > array |
1.8.8. PlacementDecisions API (v1beta1)
1.8.8.1. 개요
이 문서는 Kubernetes용 다중 클러스터 엔진의 PlacementDecision 리소스를 위한 것입니다. PlacementDecision 리소스에는 네 가지 요청(생성, 쿼리, 삭제 및 업데이트)이 있습니다.
1.8.8.1.1. URI 스키마
BasePath : /kubernetes/apis
Schemes : HTTPS
1.8.8.1.2. 태그
- cluster.open-cluster-management.io : PlacementDecisions 생성 및 관리
1.8.8.2. 경로
1.8.8.2.1. 모든 PlacementDecisions 쿼리
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
1.8.8.2.1.1. 설명
자세한 내용은 PlacementDecisions를 쿼리합니다.
1.8.8.2.1.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
1.8.8.2.1.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.8.2.1.4. Use
-
placementdecision/yaml
1.8.8.2.1.5. 태그
- cluster.open-cluster-management.io
1.8.8.2.2. PlacementDecision 생성
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
1.8.8.2.2.1. 설명
PlacementDecision 생성.
1.8.8.2.2.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
body |
본문 | 생성할 PlacementDecision을 설명하는 매개변수입니다. |
1.8.8.2.2.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.8.2.2.4. Use
-
placementdecision/yaml
1.8.8.2.2.5. 태그
- cluster.open-cluster-management.io
1.8.8.2.2.6. HTTP 요청의 예
1.8.8.2.2.6.1. 요청 본문
{ "apiVersion" : "cluster.open-cluster-management.io/v1beta1", "kind" : "PlacementDecision", "metadata" : { "labels" : { "cluster.open-cluster-management.io/placement" : "placement1" }, "name" : "placement1-decision1", "namespace": "ns1" }, "status" : { } }
1.8.8.2.3. 단일 PlacementDecision 쿼리
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
1.8.8.2.3.1. 설명
자세한 내용은 단일 PlacementDecision을 쿼리합니다.
1.8.8.2.3.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
placementdecision_name | 쿼리할 PlacementDecision의 이름입니다. | string |
1.8.8.2.3.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.8.2.3.4. 태그
- cluster.open-cluster-management.io
1.8.8.2.4. PlacementDecision 삭제
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
1.8.8.2.4.1. 설명
단일 PlacementDecision 삭제
1.8.8.2.4.2. 매개 변수
유형 | 이름 | 설명 | 스키마 |
---|---|---|---|
header |
COOKIE | 권한 부여: 베어러 {ACCESS_TOKEN} ; ACCESS_TOKEN은 사용자 액세스 토큰입니다. | string |
경로 |
placementdecision_name | 삭제할 PlacementDecision의 이름입니다. | string |
1.8.8.2.4.3. 응답
HTTP 코드 | 설명 | 스키마 |
---|---|---|
200 | 성공 | 콘텐츠 없음 |
403 | 액세스 금지 | 콘텐츠 없음 |
404 | 리소스를 찾을 수 없음 | 콘텐츠 없음 |
500 | 내부 서비스 오류 | 콘텐츠 없음 |
503 | 서비스를 사용할 수 없음 | 콘텐츠 없음 |
1.8.8.2.4.4. 태그
- cluster.open-cluster-management.io
1.8.8.3. 정의
1.8.8.3.1. PlacementDecision
이름 | 설명 | 스키마 |
---|---|---|
apiVersion | PlacementDecision의 버전이 지정된 스키마입니다. | string |
kind | REST 리소스를 나타내는 문자열 값입니다. | string |
메타데이터 | PlacementDecision의 메타 데이터입니다. | object |
1.9. 문제 해결
문제 해결 가이드를 사용하기 전에 oc adm must-gather
명령을 실행하여 세부 정보를 수집하고, 로그를 수집하고, 문제 디버깅 단계를 수행할 수 있습니다. 자세한 내용은 문제를 해결하려면 must-gather 명령 실행을 참조하십시오.
또한 역할 기반 액세스를 확인합니다. 자세한 내용은 다중 클러스터 엔진 Operator 역할 기반 액세스 제어를 참조하십시오.
1.9.1. 문서화된 문제 해결
다중 클러스터 엔진 Operator의 문제 해결 주제 목록을 확인합니다.
설치:
설치 작업에 대한 기본 문서를 보려면 다중 클러스터 엔진 Operator 설치를 참조하십시오.
클러스터 관리:
클러스터 관리에 대한 기본 문서를 보려면 클러스터 라이프사이클 소개를 참조하십시오.
- 오프라인 클러스터 문제 해결
- 관리형 클러스터 가져오기 장애 문제 해결
- 알 수 없는 권한 오류로 클러스터 다시 가져오기 실패
- 보류 중인 가져오기 상태로 클러스터 문제 해결
- 인증서 변경 후 가져온 클러스터 문제 해결
- 클러스터 상태 변경 문제 해결
- VMware vSphere에서 클러스터 생성 문제 해결
- 보류 중 또는 실패 상태의 콘솔에서 클러스터 문제 해결
- OpenShift Container Platform 버전 3.11 클러스터 가져오기 장애 문제 해결
- 성능 저하된 조건이 있는 Klusterlet 문제 해결
- 클러스터를 삭제한 후 네임스페이스가 남아 있음
- 클러스터를 가져올 때 Auto-import-secret-exists 오류
- 배치 생성 후 누락된 PlacementDecision 문제 해결
- Dell 하드웨어에서 베어 메탈 호스트의 검색 오류 문제 해결
1.9.2. 문제를 해결하기 위해 must-gather 명령 실행
문제 해결을 시작하려면 사용자가 must-gather
명령을 실행하여 문제를 디버깅할 수 있는 문제 해결 시나리오에 대해 알아보고 명령을 사용하여 시작하는 절차를 참조하십시오.
필수 액세스 권한: 클러스터 관리자
1.9.2.1. must-gather 시나리오
시나리오 1: 문제 해결 방법에 대한 자세한 내용은 문서화된 문제 해결 섹션을 참조하십시오. 이 가이드는 제품의 주요 기능에 따라 구성됩니다.
이 시나리오에서는 가이드에서 해결 방법이 문서에 있는지 확인합니다.
-
시나리오 2: 해결 단계에 문제가 문서화되지 않은 경우
must-gather
명령을 실행하고 출력을 사용하여 문제를 디버깅합니다. -
시나리오 3:
must-gather
명령의 출력을 사용하여 문제를 디버깅할 수 없는 경우 Red Hat 지원과 출력을 공유하십시오.
1.9.2.2. must-gather 절차
must-gather
명령 사용을 시작하려면 다음 절차를 참조하십시오.
-
must-gather
명령에 대해 알아보고 RedHat OpenShift Container Platform 설명서에서 클러스터에 대한 데이터를 수집하는 데 필요한 사전 요구 사항을 설치합니다. 클러스터에 로그인합니다. 일반적인 사용 사례의 경우 엔진 클러스터에 로그인하는 동안
must-gather
를 실행해야 합니다.참고: 관리 클러스터를 확인하려면
cluster-scoped-resources
디렉터리에 있는gather-managed.log
파일을 찾습니다.<your-directory>/cluster-scoped-resources/gather-managed.log>
iPXEED 및 AVAILABLE 열에
True
가 설정되지 않은 관리형 클러스터가 있는지 확인합니다.True
상태로 연결되지 않은 클러스터에서must-gather
명령을 실행할 수 있습니다.데이터 및 디렉터리를 수집하는 데 사용되는 Kubernetes 이미지의 다중 클러스터 엔진을 추가합니다. 출력에 대한 이미지와 디렉터리를 삽입한 다음 명령을 실행합니다.
oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.2.0 --dest-dir=<directory>
지정된 디렉터리로 이동하여 다음 수준으로 구성된 출력을 확인합니다.
-
두 개의 피어 수준:
cluster-scoped-resources
및namespace
리소스입니다. - 각 하위 수준: 클러스터 범위 및 네임스페이스 범위 리소스의 사용자 정의 리소스 정의의 API 그룹입니다.
-
각각에 대한 다음 수준: YAML 파일은
종류
별로 정렬됩니다.
-
두 개의 피어 수준:
1.9.2.3. 연결이 끊긴 환경의 must-gather
연결이 끊긴 환경에서 must-gather
명령을 실행하려면 다음 단계를 완료합니다.
- 연결이 끊긴 환경에서 Red Hat Operator 카탈로그 이미지를 미러 레지스트리에 미러링합니다. 자세한 내용은 연결이 끊긴 네트워크에 설치를 참조하십시오.
- 다음 명령을 실행하여 미러 레지스트리에서 이미지를 참조하는 로그를 추출합니다.
REGISTRY=registry.example.com:5000 IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8 oc adm must-gather --image=$IMAGE --dest-dir=./data
1.9.3. 설치 또는 보류 중 설치 상태 문제 해결
다중 클러스터 엔진 Operator를 설치할 때 MultiClusterEngine
은 Installing
단계에 남아 있거나 여러 Pod는 보류 중
상태를 유지합니다.
1.9.3.1. 증상: 보류 중 상태로 작동
MultiClusterEngine을 설치한 후 10분 이상 경과한
리소스 보고서 MultiClusterEngine
ProgressDeadlineExceeded
의 status.components
필드에서 하나 이상의 구성 요소가 전달됩니다. 클러스터의 리소스 제약 조건이 문제가 될 수 있습니다.
MultiClusterEngine
이 설치된 네임스페이스에서 Pod를 확인합니다. 보류 중
상태가 다음과 유사한 것으로 표시될 수 있습니다.
reason: Unschedulable message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.'
이 경우 작업자 노드 리소스가 클러스터에 부족하여 제품을 실행할 수 없습니다.
1.9.3.2. 문제 해결: 작업자 노드 크기 조정
이 문제가 발생하면 더 큰 작업자 노드로 클러스터를 업데이트해야 합니다. 클러스터 크기 조정에 대한 지침은 클러스터 스케일링을 참조하십시오.
1.9.4. 재설치 실패 문제 해결
다중 클러스터 엔진 Operator를 다시 설치할 때 Pod가 시작되지 않습니다.
1.9.4.1. 증상: 재설치 실패
다중 클러스터 엔진 Operator를 설치한 후 Pod가 시작되지 않으면 이전 다중 클러스터 엔진 Operator 설치의 항목이 제거될 때 올바르게 제거되지 않았기 때문에 Pod가 시작되지 않는 경우가 많습니다.
이 경우 설치 프로세스를 완료한 후 Pod가 시작되지 않습니다.
1.9.4.2. 문제 해결: 재설치 실패
이 문제가 있는 경우 다음 단계를 완료합니다.
- 설치 제거 프로세스를 실행하여 설치 제거의 단계에 따라 현재 구성 요소를 제거합니다. ???
- Helm 설치 지침에 따라 Helm CLI 바이너리 버전 3.2.0 이상을 설치합니다. https://helm.sh/docs/intro/install/
-
Red Hat OpenShift Container Platform CLI가
oc
명령을 실행하도록 구성되어 있는지 확인합니다.oc
명령을 구성하는 방법에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 OpenShift CLI 시작하기 를 참조하십시오. 다음 스크립트를 파일에 복사합니다.
#!/bin/bash MCE_NAMESPACE=<namespace> oc delete multiclusterengine --all oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io oc delete crd discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io oc delete mutatingwebhookconfiguration ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io oc delete validatingwebhookconfiguration ocm-validating-webhook oc delete ns $MCE_NAMESPACE
스크립트의 &
lt;namespace
>를 다중 클러스터 엔진 Operator가 설치된 네임스페이스 이름으로 바꿉니다. 네임스페이스가 정리되고 삭제되므로 올바른 네임스페이스를 지정해야 합니다.- 스크립트를 실행하여 이전 설치에서 아티팩트를 제거합니다.
- 설치를 실행합니다. 온라인에 연결된 동안 설치를 참조하십시오.
1.9.5. 오프라인 클러스터 문제 해결
오프라인 상태를 표시하는 클러스터의 일반적인 원인은 몇 가지 있습니다.
1.9.5.1. 증상: 클러스터 상태가 오프라인입니다.
클러스터 생성 절차를 완료한 후에는 Red Hat Advanced Cluster Management 콘솔에서 액세스할 수 없으며 오프라인
상태의 상태가 표시됩니다.
1.9.5.2. 문제 해결: 클러스터 상태가 오프라인 상태임
관리 클러스터를 사용할 수 있는지 확인합니다. Red Hat Advanced Cluster Management 콘솔의 Clusters 영역에서 이를 확인할 수 있습니다.
사용할 수 없는 경우 관리 클러스터를 다시 시작해 봅니다.
관리형 클러스터 상태가 여전히 오프라인인 경우 다음 단계를 완료합니다.
-
hub 클러스터에서
oc get managedcluster <cluster_name> -o yaml
명령을 실행합니다. <cluster_name
>을 클러스터 이름으로 바꿉니다. -
status.conditions
섹션을 찾습니다. -
type: ManagedClusterConditionAvailable
의 메시지를 확인하고 문제를 해결합니다.
-
hub 클러스터에서
1.9.6. 관리형 클러스터 가져오기 장애 문제 해결
클러스터 가져오기에 실패하는 경우 클러스터 가져오기에 실패한 이유를 확인하기 위해 몇 가지 단계를 수행할 수 있습니다.
1.9.6.1. 증상: 가져온 클러스터를 사용할 수 없음
클러스터 가져오기 절차를 완료한 후에는 콘솔에서 액세스할 수 없습니다.
1.9.6.2. 문제 해결: Imported cluster not available
가져오기를 시도한 후 가져온 클러스터를 사용할 수 없는 몇 가지 이유가 있을 수 있습니다. 클러스터 가져오기에 실패한 경우 가져오기 실패 이유를 찾을 때까지 다음 단계를 완료합니다.
hub 클러스터에서 다음 명령을 실행하여 가져오기 컨트롤러가 실행 중인지 확인합니다.
kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2
실행 중인 포드 두 개가 표시되어야 합니다. Pod 중 하나가 실행되고 있지 않은 경우 다음 명령을 실행하여 로그를 확인하여 이유를 확인합니다.
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1
hub 클러스터에서 다음 명령을 실행하여 가져오기 컨트롤러에서 관리형 클러스터 가져오기 시크릿이 성공적으로 생성되었는지 확인합니다.
kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import
가져오기 보안이 없는 경우 다음 명령을 실행하여 가져오기 컨트롤러의 로그 항목을 보고 생성되지 않은 이유를 확인합니다.
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller
hub 클러스터에서 관리 클러스터가
로컬
클러스터 되거나 Hive에 의해 프로비저닝되거나 자동 가져오기 보안이 있는 경우 다음 명령을 실행하여 관리형 클러스터의 가져오기 상태를 확인합니다.kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceeded
ManagedClusterImportSucceeded
조건이true
가 아닌 경우 명령 결과는 실패 이유를 나타냅니다.- 성능 저하된 상태의 관리형 클러스터의 Klusterlet 상태를 확인합니다. Klusterlet이 성능 저하된 이유를 찾으려면 성능이 저하된 조건을 가진 Klusterlet 문제 해결을 참조하십시오.
1.9.7. 알 수 없는 권한 오류로 클러스터 다시 가져오기 실패
관리 클러스터를 멀티 클러스터 엔진 Operator 허브 클러스터로 다시 가져올 때 문제가 발생하는 경우 절차에 따라 문제를 해결합니다.
1.9.7.1. 증상: 클러스터 가져오기가 실패하고 권한 없는 오류와 함께 클러스터 가져오기가 실패합니다.
멀티 클러스터 엔진 Operator를 사용하여 OpenShift Container Platform 클러스터를 프로비저닝한 후 OpenShift Container Platform 클러스터에 API 서버 인증서를 변경하거나 추가할 때 알 수 없는 권한 오류로 인해
클러스터를 다시 가져오는 데 실패할 수 있습니다.
1.9.7.2. 문제 식별: 클러스터 가져오기 실패 및 알 수 없는 권한 오류 발생
관리형 클러스터를 다시 가져오지 못한 후 다음 명령을 실행하여 다중 클러스터 엔진 Operator 허브 클러스터에서 가져오기 컨트롤러 로그를 가져옵니다.
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f
다음 오류 로그가 표시되면 관리형 클러스터 API 서버 인증서가 변경될 수 있습니다.
ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace":"awscluster1"}, "namespace": "awscluster1", "awscluster1", "reconcileID": "reconcileID": "a2cccf24-2547-4e26-95b-f2580", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}
관리형 클러스터 API 서버 인증서가 변경되었는지 확인하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 your-managed-cluster
-name을 관리형 클러스터의 이름으로
교체하여 관리형 클러스터 이름을 지정합니다.cluster_name=<your-managed-cluster-name>
다음 명령을 실행하여 관리형 클러스터
kubeconfig
보안 이름을 가져옵니다.kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
다음 명령을 실행하여
kubeconfig
를 새 파일로 내보냅니다.oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.old
export KUBECONFIG=kubeconfig.old
다음 명령을 실행하여
kubeconfig
를 사용하여 관리 클러스터에서 네임스페이스를 가져옵니다.oc get ns
다음 메시지와 유사한 오류가 발생하면 클러스터 API 서버ceritificates가 변경되어 kubeconfig
파일이 유효하지 않습니다.
서버에 연결할 수 없음: x509: 알 수 없는 기관에서 서명한 인증서
1.9.7.3. 문제 해결: Reimporting cluster fails with unknown authority error
관리형 클러스터 관리자는 관리 클러스터에 유효한 새 kubeconfig
파일을 생성해야 합니다.
새 kubeconfig
를 생성한 후 다음 단계를 완료하여 관리 클러스터의 새 kubeconfig
를 업데이트합니다.
다음 명령을 실행하여
kubeconfig
파일 경로와 클러스터 이름을 설정합니다. <path_to_kubeconfig&
gt;를 새kubeconfig
파일의 경로로 바꿉니다. <managed_cluster_name
>을 관리형 클러스터 이름으로 교체합니다.cluster_name=<managed_cluster_name> kubeconfig_file=<path_to_kubeconfig>
다음 명령을 실행하여 새
kubeconfig
를 인코딩합니다.kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)
참고: macOS에서는 대신 다음 명령을 실행합니다.
kubeconfig=$(cat ${kubeconfig_file} | base64)
다음 명령을 실행하여
kubeconfig
json 패치를 정의합니다.kubeconfig_patch="[{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}]"
다음 명령을 실행하여 관리 대상 클러스터에서 관리자
kubeconfig
보안 이름을 검색합니다.kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
다음 명령을 실행하여 관리자
kubeconfig
보안을 새kubeconfig
와 패치합니다.oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p=${kubeconfig_patch}
1.9.8. 보류 중인 가져오기 상태로 클러스터 문제 해결
클러스터 콘솔에서 보류 중 가져오기 가 계속되는 경우 절차에 따라 문제를 해결합니다.
1.9.8.1. 증상: 보류 중인 가져오기 상태가 있는 클러스터
Red Hat Advanced Cluster Management 콘솔을 사용하여 클러스터를 가져온 후 클러스터는 보류 중 가져오기 상태와 함께 콘솔에 나타납니다.
1.9.8.2. 문제 확인: 가져오기 상태가 보류 중인 클러스터
문제가 있는 Kubernetes Pod 이름을 보려면 관리형 클러스터에서 다음 명령을 실행합니다.
kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent
관리형 클러스터에서 다음 명령을 실행하여 오류에 대한 로그 항목을 찾습니다.
kubectl logs <registration_agent_pod> -n open-cluster-management-agent
registration_agent_pod 를 1단계에서 확인한 Pod 이름으로 교체합니다.
-
네트워킹 연결 문제가 있음을 나타내는 텍스트에 대해 반환된 결과를 검색합니다. 예에는 다음이 포함됩니다.
이러한 호스트는 없습니다
.
1.9.8.3. 문제 해결: 가져오기 상태가 보류 중인 클러스터
hub 클러스터에 다음 명령을 입력하여 문제가 있는 포트 번호를 검색합니다.
oc get infrastructure cluster -o yaml | grep apiServerURL
관리 클러스터의 호스트 이름을 확인하고 호스트 및 포트에 대한 아웃바운드 연결이 발생하는지 확인합니다.
관리형 클러스터에서 통신을 설정할 수 없는 경우 클러스터 가져오기가 완료되지 않습니다. 관리 클러스터의 클러스터 상태는 Pending import 입니다.
1.9.9. 인증서 변경 후 가져온 클러스터 문제 해결
사용자 정의 apiserver
인증서 설치는 지원되지만 인증서 정보를 변경하기 전에 가져온 하나 이상의 클러스터가 오프라인
상태를 가질 수 있습니다.
1.9.9.1. 증상: 인증서 변경 후 오프라인 클러스터
인증서 보안 업데이트 절차를 완료한 후 온라인 상태인 하나 이상의 클러스터가 콘솔에 오프라인
상태를 표시합니다.
1.9.9.2. 문제 확인: 인증서 변경 후 오프라인 클러스터
사용자 정의 API 서버 인증서에 대한 정보를 업데이트한 후 새 인증서를 가져 와서 실행 중인 클러스터는 이제 오프라인
상태가 됩니다.
인증서가 문제가 있음을 나타내는 오류는 오프라인 관리 클러스터의 open-cluster-management-agent
네임스페이스에 있는 Pod 로그에서 확인할 수 있습니다. 다음 예제는 로그에 표시되는 오류와 유사합니다.
work-agent
로그:
E0917 03:04:05.874759 1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority E0917 03:04:05.874887 1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority E0917 03:04:37.245859 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority
registration-agent
로그:
I0917 02:27:41.525026 1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available" E0917 02:58:26.315984 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority E0917 02:58:26.598343 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority E0917 02:58:27.613963 1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
1.9.9.3. 문제 해결: 인증서 변경 후 오프라인 클러스터
관리형 클러스터가 다중 클러스터 엔진 Operator를 사용하여 로컬
클러스터 또는 관리형 클러스터인 경우 관리 클러스터를 다시 가져오려면 10분 이상 기다려야 합니다.
관리형 클러스터를 즉시 가져오기 위해 hub 클러스터에서 관리형 클러스터 가져오기 보안을 삭제하고 멀티 클러스터 엔진 Operator를 사용하여 다시 가져올 수 있습니다. 다음 명령을 실행합니다.
oc delete secret -n <cluster_name> <cluster_name>-import
& lt;cluster_name
>을 가져올 관리형 클러스터 이름으로 바꿉니다.
다중 클러스터 엔진 Operator를 사용하여 가져온 관리형 클러스터를 다시 가져오려면 다음 단계를 다시 완료하기 위해 관리 클러스터를 다시 가져옵니다.
hub 클러스터에서 다음 명령을 실행하여 관리형 클러스터 가져오기 보안을 다시 생성합니다.
oc delete secret -n <cluster_name> <cluster_name>-import
&
lt;cluster_name
>을 가져올 관리형 클러스터 이름으로 바꿉니다.hub 클러스터에서 다음 명령을 실행하여 관리 대상 클러스터 가져오기 보안을 YAML 파일에 노출합니다.
oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode > import.yaml
&
lt;cluster_name
>을 가져올 관리형 클러스터 이름으로 바꿉니다.관리형 클러스터에서 다음 명령을 실행하는
import.yaml
파일을 적용합니다.oc apply -f import.yaml
참고: 이전 단계에서는 관리 대상 클러스터를 hub 클러스터에서 분리하지 않습니다. 이 단계는 새 인증서 정보를 포함하여 관리형 클러스터의 현재 설정으로 필요한 매니페스트를 업데이트합니다.
1.9.10. 클러스터 상태 변경 문제 해결
환경 또는 클러스터를 수동으로 변경하지 않고 관리형 클러스터의 상태가 오프라인
과 사용 가능
간에 전환됩니다.
1.9.10.1. 증상: 클러스터 상태가 오프라인에서 사용 가능으로 변경됩니다.
관리 클러스터를 hub 클러스터에 연결하는 네트워크가 불안정할 때 오프라인
과 사용 가능한
허브 클러스터 사이클에 의해 보고되는 관리 클러스터의 상태가 설정됩니다.
1.9.10.2. 문제 해결: 클러스터 상태가 오프라인에서 사용 가능으로 변경
이 문제를 해결하려면 다음 단계를 완료합니다.
다음 명령을 입력하여 hub 클러스터에서
ManagedCluster
사양을 편집합니다.oc edit managedcluster <cluster-name>
cluster-name 을 관리 클러스터의 이름으로 바꿉니다.
-
ManagedCluster
사양에서leaseDurationSeconds
값을 늘립니다. 기본값은 5분이지만 네트워크 문제와의 연결을 유지하기에 시간이 충분하지 않을 수 있습니다. 임대 시간을 더 많이 지정합니다. 예를 들어 설정을 20분으로 늘릴 수 있습니다.
1.9.11. VMware vSphere에서 클러스터 생성 문제 해결
VMware vSphere에서 Red Hat OpenShift Container Platform 클러스터를 생성할 때 문제가 발생하는 경우 다음 문제 해결 정보를 참조하십시오.
참고: 경우에 따라 VMware vSphere에서 클러스터 생성 프로세스가 실패하면 해당 링크가 로그를 볼 수 없습니다. 이 경우 hive-controllers
Pod의 로그를 확인하여 문제를 식별할 수 있습니다. hive-controllers
로그는 hive
네임스페이스에 있습니다.
1.9.11.1. 인증서 IP SAN 오류와 함께 관리형 클러스터 생성 실패
1.9.11.1.1. 증상: 관리형 클러스터 생성 실패 인증서 IP SAN 오류
VMware vSphere에 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 클러스터가 인증서 IP SAN 오류를 나타내는 오류 메시지와 함께 실패합니다.
1.9.11.1.2. 문제 확인: 관리형 클러스터 생성 실패 인증서 IP SAN 오류 발생
관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다.
time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs" time="2020-08-07T15:27:55Z" level=error
1.9.11.1.3. 문제 해결: 관리형 클러스터 생성 실패 인증서 IP SAN 오류 발생
자격 증명의 IP 주소 대신 VMware vCenter 서버 정규화된 호스트 이름을 사용합니다. IP SAN을 포함하도록 VMware vCenter CA 인증서를 업데이트할 수도 있습니다.
1.9.11.2. 알 수 없는 인증 기관과 함께 관리되는 클러스터 생성 실패
1.9.11.2.1. 증상: 관리형 클러스터 생성이 알 수 없는 인증 기관과 함께 실패합니다.
VMware vSphere에 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 인증서가 알 수 없는 기관에서 서명되므로 클러스터가 실패합니다.
1.9.11.2.2. 문제 확인: 관리형 클러스터 생성이 알 수 없는 인증 기관과 함께 실패했습니다.
관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다.
Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.9.11.2.3. 문제 해결: 관리형 클러스터 생성이 알 수 없는 인증 기관과 함께 실패했습니다.
인증 정보를 생성할 때 인증 기관에서 올바른 인증서를 입력했는지 확인합니다.
1.9.11.3. 만료된 인증서로 관리되는 클러스터 생성 실패
1.9.11.3.1. 증상: 관리형 클러스터 생성 실패 with expired certificate
VMware vSphere에 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 인증서가 만료되었거나 아직 유효하지 않기 때문에 클러스터가 실패합니다.
1.9.11.3.2. 문제 확인: 관리형 클러스터 생성이 만료된 인증서로 실패했습니다.
관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다.
x509: certificate has expired or is not yet valid
1.9.11.3.3. 문제 해결: Managed cluster creation fails with expired certificate
ESXi 호스트의 시간이 동기화되었는지 확인합니다.
1.9.11.4. 관리형 클러스터 생성이 실패하여 태그 지정에 대한 권한이 부족함
1.9.11.4.1. 증상: 관리형 클러스터 생성이 실패하고 태그 지정에 필요한 권한이 충분하지 않음
VMware vSphere에 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 태그 지정을 사용할 수 있는 권한이 부족하기 때문에 클러스터가 실패합니다.
1.9.11.4.2. 문제 확인: 관리형 클러스터 생성 실패와 태그 지정에 대한 권한이 충분하지 않음
관리 클러스터의 배포가 실패하고 배포 로그에 다음 오류를 반환합니다.
time="2020-08-07T19:41:58Z" level=debug msg="vsphere_tag_category.category: Creating..." time="2020-08-07T19:41:58Z" level=error time="2020-08-07T19:41:58Z" level=error msg="Error: could not create category: POST https://vspherehost.com/rest/com/vmware/cis/tagging/category: 403 Forbidden" time="2020-08-07T19:41:58Z" level=error time="2020-08-07T19:41:58Z" level=error msg=" on ../tmp/openshift-install-436877649/main.tf line 54, in resource \"vsphere_tag_category\" \"category\":" time="2020-08-07T19:41:58Z" level=error msg=" 54: resource \"vsphere_tag_category\" \"category\" {"
1.9.11.4.3. 문제 해결: 관리형 클러스터 생성 실패와 태그 지정에 대한 권한이 충분하지 않음
VMware vCenter 필수 계정 권한이 올바른지 확인합니다. 자세한 내용은 이미지 레지스트리 를 참조하십시오.
1.9.11.5. 잘못된 dnsVIP로 관리되는 클러스터 생성 실패
1.9.11.5.1. 증상: 관리형 클러스터 생성 실패와 함께 잘못된 dnsVIP
VMware vSphere에 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 유효하지 않은 dnsVIP가 있기 때문에 클러스터가 실패합니다.
1.9.11.5.2. 문제 확인: 관리형 클러스터 생성 실패 잘못된 dnsVIP
VMware vSphere를 사용하여 새 관리 클러스터를 배포하려고 할 때 다음 메시지가 표시되면 VMware Installer Provisioned Infrastructure(IPI)를 지원하지 않는 이전 OpenShift Container Platform 릴리스 이미지가 있기 때문입니다.
failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
1.9.11.5.3. 문제 해결: Managed 클러스터 생성 실패 잘못된 dnsVIP
최신 버전의 OpenShift Container Platform에서 VMware Installer Provisioned Infrastructure를 지원하는 릴리스 이미지를 선택합니다.
1.9.11.6. 잘못된 네트워크 유형으로 관리 클러스터 생성 실패
1.9.11.6.1. 증상: 관리형 클러스터 생성이 잘못된 네트워크 유형과 함께 실패합니다.
VMware vSphere에서 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 잘못된 네트워크 유형이 지정되어 있기 때문에 클러스터가 실패합니다.
1.9.11.6.2. 문제 확인: 관리형 클러스터 생성 실패 잘못된 네트워크 유형
VMware vSphere를 사용하여 새 관리 클러스터를 배포하려고 할 때 다음 메시지가 표시되면 VMware Installer Provisioned Infrastructure(IPI)를 지원하지 않는 이전 OpenShift Container Platform 이미지가 있기 때문입니다.
time="2020-08-11T14:31:38-04:00" level=debug msg="vsphereprivate_import_ova.import: Creating..." time="2020-08-11T14:31:39-04:00" level=error time="2020-08-11T14:31:39-04:00" level=error msg="Error: rpc error: code = Unavailable desc = transport is closing" time="2020-08-11T14:31:39-04:00" level=error time="2020-08-11T14:31:39-04:00" level=error time="2020-08-11T14:31:39-04:00" level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply Terraform: failed to complete the change"
1.9.11.6.3. 문제 해결: 관리형 클러스터 생성 실패 잘못된 네트워크 유형
지정된 VMware 클러스터에 유효한 VMware vSphere 네트워크 유형을 선택합니다.
1.9.11.7. 관리 클러스터 생성 실패 오류 처리 디스크 변경
1.9.11.7.1. 증상: 디스크 처리 디스크 변경으로 인해 VMware vSphere 관리 클러스터 추가 실패
VMware vSphere에 새 Red Hat OpenShift Container Platform 클러스터를 생성하면 디스크 변경 처리 시 오류가 있기 때문에 클러스터가 실패합니다.
1.9.11.7.2. 문제 확인: 오류 처리 디스크 변경으로 인해 VMware vSphere 관리 클러스터 추가 실패
다음과 유사한 메시지가 로그에 표시됩니다.
ERROR ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
1.9.11.7.3. 문제 해결: 오류 처리 디스크 변경으로 인해 VMware vSphere 관리 클러스터 추가 실패
VMware vSphere 클라이언트를 사용하여 프로필 중심 스토리지 권한에 대한 모든 권한을 사용자에게 부여합니다.
1.9.12. 보류 중 또는 실패 상태의 콘솔에서 클러스터 문제 해결
생성한 클러스터의 보류 중 상태 또는 실패 상태를 확인하는 경우 절차에 따라 문제를 해결합니다.
1.9.12.1. 증상: 보류 중 또는 실패한 상태의 콘솔에서 클러스터
콘솔을 사용하여 새 클러스터를 생성한 후 클러스터는 Pending 상태로 진행되지 않거나 Failed 상태가 표시됩니다.
1.9.12.2. 문제 확인: 보류 중 또는 실패 상태의 콘솔에서 클러스터
클러스터에 Failed 상태가 표시되면 클러스터의 세부 정보 페이지로 이동하여 제공된 로그 링크를 따릅니다. 로그를 찾을 수 없거나 클러스터에서 Pending 상태를 표시하는 경우 다음 절차에 따라 로그를 확인합니다.
절차 1
hub 클러스터에서 다음 명령을 실행하여 새 클러스터의 네임스페이스에서 생성된 Kubernetes 포드의 이름을 확인합니다.
oc get pod -n <new_cluster_name>
new_cluster_name
을 생성한 클러스터 이름으로 교체합니다.이름에
provision
문자열이 포함된 Pod가 나열되지 않은 경우 2 절차로 계속 진행합니다. 제목에프로비저닝
이 있는 Pod가 있는 경우 hub 클러스터에서 다음 명령을 실행하여 해당 Pod의 로그를 확인합니다.oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive
new_cluster_name_provision_pod_name
을 생성한 클러스터의 이름으로 교체한 다음provision
가 포함된 Pod 이름으로 교체합니다.- 로그에서 문제의 원인을 설명할 수 있는 오류를 검색합니다.
절차 2
이름에
provision
가 있는 Pod가 없는 경우 프로세스의 앞부분에서 문제가 발생했습니다. 로그를 확인하려면 다음 절차를 완료합니다.hub 클러스터에서 다음 명령을 실행합니다.
oc describe clusterdeployments -n <new_cluster_name>
new_cluster_name
을 생성한 클러스터 이름으로 교체합니다. 클러스터 설치 로그에 대한 자세한 내용은 Red Hat OpenShift 문서의 설치 로그 수집 을 참조하십시오.- 리소스의 Status.Conditions.Message 및 Status.Conditions.Reason 항목에 문제에 대한 추가 정보가 있는지 확인합니다.
1.9.12.3. 문제 해결: 보류 중 또는 실패한 상태의 콘솔의 클러스터
로그에서 오류를 확인한 후 클러스터를 삭제하고 다시 생성하기 전에 오류를 해결하는 방법을 확인합니다.
다음 예제에서는 지원되지 않는 영역을 선택하는 경우 가능한 로그 오류와 이를 해결하는 데 필요한 작업을 제공합니다.
No subnets provided for zones
클러스터를 생성할 때 지원되지 않는 리전 내에서 하나 이상의 영역을 선택했습니다. 클러스터를 다시 생성하여 문제를 해결할 때 다음 작업 중 하나를 완료합니다.
- 리전 내에서 다른 영역을 선택합니다.
- 다른 영역이 나열된 경우 지원을 제공하지 않는 영역을 생략합니다.
- 클러스터의 다른 리전을 선택합니다.
로그에서 문제를 확인한 후 클러스터를 제거하고 다시 생성합니다.
클러스터 생성에 대한 자세한 내용은 클러스터 생성을 참조하십시오.
1.9.13. OpenShift Container Platform 버전 3.11 클러스터 가져오기 장애 문제 해결
1.9.13.1. 증상: OpenShift Container Platform 버전 3.11 클러스터 가져오기 실패
Red Hat OpenShift Container Platform 버전 3.11 클러스터를 가져오려고 하면 가져오기에 실패하고 다음 콘텐츠와 유사한 로그 메시지가 표시됩니다.
customresourcedefinition.apiextensions.k8s.io/klusterlets.operator.open-cluster-management.io configured clusterrole.rbac.authorization.k8s.io/klusterlet configured clusterrole.rbac.authorization.k8s.io/open-cluster-management:klusterlet-admin-aggregate-clusterrole configured clusterrolebinding.rbac.authorization.k8s.io/klusterlet configured namespace/open-cluster-management-agent configured secret/open-cluster-management-image-pull-credentials unchanged serviceaccount/klusterlet configured deployment.apps/klusterlet unchanged klusterlet.operator.open-cluster-management.io/klusterlet configured Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret: v1.Secret.ObjectMeta: v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 1313, error found in #10 byte of ...|dhruy45="},"kind":"|..., bigger context ...|tye56u56u568yuo7i67i67i67o556574i"},"kind":"Secret","metadata":{"annotations":{"kube|...
1.9.13.2. 문제 확인: OpenShift Container Platform 버전 3.11 클러스터 가져오기 실패
이는 kubectl
명령줄 도구의 설치된 버전이 1.11 또는 이전 버전이므로 종종 발생합니다. 다음 명령을 실행하여 실행 중인 kubectl
명령줄 도구 버전을 확인합니다.
kubectl version
반환된 데이터에 버전 1.11 또는 이전 버전이 나열된 경우 문제 해결 방법 (OpenShift Container Platform 버전 3.11 클러스터 가져오기 실패 )을 완료합니다.
1.9.13.3. 문제 해결: OpenShift Container Platform 버전 3.11 클러스터 가져오기 실패
다음 절차 중 하나를 완료하여 이 문제를 해결할 수 있습니다.
kubectl
명령줄 도구의 최신 버전을 설치합니다.-
Kubernetes 설명서에서
kubectl
툴의 최신 버전을 다운로드합니다: Install and Set Up kubectl in the Kubernetes documentation. -
kubectl
툴을 업그레이드한 후 클러스터를 다시 가져옵니다.
-
Kubernetes 설명서에서
가져오기 명령이 포함된 파일을 실행합니다.
- CLI를 사용하여 관리 클러스터 가져오기 절차를 시작합니다.
-
클러스터를 가져올 명령을 생성할 때
import.yaml
이라는 YAML 파일에 해당 명령을 복사합니다. 다음 명령을 실행하여 파일에서 클러스터를 다시 가져옵니다.
oc apply -f import.yaml
1.9.14. 성능 저하된 조건이 있는 Klusterlet 문제 해결
Klusterlet 성능 저하 조건은 관리 클러스터에서 Klusterlet 에이전트의 상태를 진단하는 데 도움이 될 수 있습니다. Klusterlet이 성능 저하 상태에 있는 경우 관리 클러스터의 Klusterlet 에이전트에 문제를 해결해야 하는 오류가 있을 수 있습니다. True
로 설정된 Klusterlet 성능 저하 상태에 대한 다음 정보를 참조하십시오.
1.9.14.1. 증상: Klusterlet이 성능 저하 상태에 있습니다.
관리되는 클러스터에 Klusterlet을 배포한 후 KlusterletRegistrationDegraded
또는 KlusterletWorkDegraded
조건이 True 임을 표시합니다.
1.9.14.2. 문제 확인: Klusterlet이 성능 저하된 상태에 있습니다.
관리 클러스터에서 다음 명령을 실행하여 Klusterlet 상태를 확인합니다.
kubectl get klusterlets klusterlet -oyaml
-
KlusterletRegistrationDegraded
또는KlusterletWorkDegraded
를 확인하여 조건이True
로 설정되어 있는지 확인하십시오. 나열된 성능이 저하된 조건에 대해 문제를 해결하도록 진행합니다.
1.9.14.3. 문제 해결: Klusterlet이 성능 저하 상태에 있습니다.
다음 성능 저하 상태 목록과 이러한 문제를 해결하는 방법을 참조하십시오.
-
상태가 True인
KlusterletRegistrationDegraded
조건이 True 이고 조건 이유인 경우 BootStrapSecretMissing,open-cluster-management-agent
네임스페이스에서 부트스트랩 시크릿을 생성해야 합니다. -
KlusterletRegistrationDegraded
조건이 True 로 표시되고 조건 이유가 BootstrapSecretError 또는 BootstrapSecretUnauthorized 인 경우 현재 부트스트랩 시크릿이 유효하지 않습니다. 현재 부트스트랩 보안을 삭제하고open-cluster-management-agent
네임스페이스에서 유효한 부트스트랩 보안을 다시 생성합니다. -
KlusterletRegistrationDegraded
및KlusterletWorkDegraded
가 True 로 표시되고 조건 이유는 HubKubeConfigSecretMissing 이므로 Klusterlet을 삭제하고 다시 생성합니다. -
KlusterletRegistrationDegraded
및KlusterletWorkDegraded
가 True 로 표시되고 조건 이유는 ClusterNameMissing, HubConfigMissing,HubConfigSecretError, HubConfigSecretUnauthorized,open-cluster-management-agent
네임스페이스에서 hub cluster kubeconfig 시크릿을 삭제합니다. 등록 에이전트는 새 허브 클러스터 kubeconfig 보안을 가져오기 위해 다시 부트스트랩합니다. -
KlusterletRegistrationDegraded
에 True 가 표시되고 조건 이유가 GetRegistrationDeploymentFailed 또는 UnavailableRegistrationPod 인 경우 상태 메시지를 확인하여 문제 세부 정보를 가져오고 해결하려고 할 수 있습니다. -
KlusterletWorkDegraded
에 True 가 표시되고 조건 이유가 GetWorkDeploymentFailed 또는 UnavailableWorkPod 인 경우 상태 메시지를 확인하여 문제 세부 정보를 가져오고 문제를 해결할 수 있습니다.
1.9.15. 클러스터를 삭제한 후 네임스페이스가 남아 있음
관리형 클러스터를 제거하면 일반적으로 네임스페이스가 클러스터 제거 프로세스의 일부로 제거됩니다. 드문 경우지만 네임스페이스는 일부 아티팩트와 함께 남아 있습니다. 이 경우 네임스페이스를 수동으로 제거해야 합니다.
1.9.15.1. 증상: 클러스터를 삭제한 후에도 네임스페이스가 유지됩니다.
관리형 클러스터를 제거하면 네임스페이스가 제거되지 않습니다.
1.9.15.2. 문제 해결: 클러스터를 삭제한 후에도 네임스페이스가 유지됩니다.
네임스페이스를 수동으로 제거하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 <cluster_name> 네임스페이스에 남아 있는 리소스 목록을 생성합니다.
oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>
cluster_name
을 삭제하려는 클러스터의 네임스페이스 이름으로 바꿉니다.다음 명령을 입력하여 목록을 편집하여 삭제 상태가 아닌 목록에서 식별된 각 리소스를
삭제합니다
.oc edit <resource_kind> <resource_name> -n <namespace>
resource_kind
를 리소스 종류로 교체합니다.resource_name
을 리소스 이름으로 교체합니다.namespace
를 리소스의 네임스페이스 이름으로 바꿉니다.-
메타데이터
의 에서 종료자
속성을 찾습니다. -
vi editor
dd
명령을 사용하여 비Kubernetes 종료자를 삭제합니다. -
목록을 저장하고
:wq
명령을 입력하여vi
편집기를 종료합니다. 다음 명령을 입력하여 네임스페이스를 삭제합니다.
oc delete ns <cluster-name>
cluster-name
을 삭제하려는 네임스페이스의 이름으로 바꿉니다.
1.9.16. 클러스터를 가져올 때 Auto-import-secret-exists 오류
자동 가져오기 시크릿을 읽는 오류 메시지와 함께 클러스터 가져오기가 실패합니다.
1.9.16.1. 증상: 클러스터를 가져올 때 자동 가져오기 시크릿이 존재하는 경우 오류
관리를 위해 하이브 클러스터를 가져오는 경우 자동 가져오기-비밀번호 오류가 이미 존재합니다
.
1.9.16.2. 문제 해결: 클러스터를 가져올 때 자동 가져오기-secret-exists 오류
이 문제는 이전에 관리되는 클러스터를 가져오려고 할 때 발생합니다. 이 경우 클러스터를 다시 가져오려고 할 때 보안이 충돌합니다.
이 문제를 해결하려면 다음 단계를 완료하십시오.
기존
auto-import-secret
을 수동으로 삭제하려면 hub 클러스터에서 다음 명령을 실행합니다.oc delete secret auto-import-secret -n <cluster-namespace>
cluster-namespace
를 클러스터 네임스페이스로 교체합니다.- 대상 관리 클러스터를 허브 클러스터로 가져오는 절차를 사용하여 클러스터를 다시 가져옵니다.
클러스터를 가져옵니다.
1.9.17. 배치 생성 후 누락된 PlacementDecision 문제 해결
배치를 생성한 후
이 생성되지 않는 경우 절차에 따라 문제를 해결합니다.
Placement
Descision
1.9.17.1. 증상: 배치 생성 후 배치 감소
배치 생성 후
이 자동으로 생성되지 않습니다.
Placement
Descision
1.9.17.2. 문제 해결: 배치 생성 후 PlacementDecision 미러링
이 문제를 해결하려면 다음 단계를 완료하십시오.
다음 명령을 실행하여
배치
조건을 확인합니다.kubectl describe placement <placement-name>
placement-name
을배치
의 이름으로 교체합니다.출력은 다음 예와 유사할 수 있습니다.
Name: demo-placement Namespace: default Labels: <none> Annotations: <none> API Version: cluster.open-cluster-management.io/v1beta1 Kind: Placement Status: Conditions: Last Transition Time: 2022-09-30T07:39:45Z Message: Placement configurations check pass Reason: Succeedconfigured Status: False Type: PlacementMisconfigured Last Transition Time: 2022-09-30T07:39:45Z Message: No valid ManagedClusterSetBindings found in placement namespace Reason: NoManagedClusterSetBindings Status: False Type: PlacementSatisfied Number Of Selected Clusters: 0
PlacementMis configured
및PlacementSatisfied
의Status
를 확인합니다.-
Placement
Mis configuredStatus
가 true인 경우 배치에 구성 오류가 있습니다. 구성 오류 및 해결 방법에 대한 자세한 내용은 포함된 메시지를 확인하십시오. -
Placement
SatisfiedStatus
가 false인 경우 관리 클러스터는 배치를 충족하지 않습니다. 보다 자세한 내용과 오류 해결 방법은 포함된 메시지를 확인하십시오. 이전 예에서는 placement 네임스페이스에ManagedClusterSetBindings
를 찾을 수 없었습니다.
-
이벤트에서 각 클러스터의 점수를 확인하여 점수
가
낮은 일부 클러스터가 선택되지 않은 이유를 확인할 수 있습니다. 출력은 다음 예와 유사할 수 있습니다.Name: demo-placement Namespace: default Labels: <none> Annotations: <none> API Version: cluster.open-cluster-management.io/v1beta1 Kind: Placement Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal DecisionCreate 2m10s placementController Decision demo-placement-decision-1 is created with placement demo-placement in namespace default Normal DecisionUpdate 2m10s placementController Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default Normal ScoreUpdate 2m10s placementController cluster1:0 cluster2:100 cluster3:200 Normal DecisionUpdate 3s placementController Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default Normal ScoreUpdate 3s placementController cluster1:200 cluster2:145 cluster3:189 cluster4:200
참고: 배치 컨트롤러는 점수를 할당하고 각 필터링된
ManagedCluster
에 대한 이벤트를 생성합니다. 배치 컨트롤러는 클러스터 점수가 변경될 때 새 이벤트를 발생시킵니다.
1.9.18. Dell 하드웨어에서 베어 메탈 호스트의 검색 오류 문제 해결
Dell 하드웨어에서 베어 메탈 호스트를 검색하지 못하면 Integrated Dell Remote Access Controller(iDRAC)가 알 수 없는 인증 기관의 인증서를 허용하지 않도록 구성됩니다.
1.9.18.1. 증상: Dell 하드웨어에서 베어 메탈 호스트의 검색 실패
베이스 보드 관리 컨트롤러를 사용하여 베어 메탈 호스트 검색 절차를 완료하면 다음과 유사한 오류 메시지가 표시됩니다.
ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [ {"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"} ]
1.9.18.2. 문제 해결: Dell 하드웨어에서 베어 메탈 호스트의 검색 실패
iDRAC는 알 수 없는 인증 기관의 인증서를 수락하지 않도록 설정되어 있습니다.
문제를 바이패스하려면 다음 단계를 완료하여 호스트 iDRAC의 베이스 보드 관리 컨트롤러에서 인증서 확인을 비활성화합니다.
- iDRAC 콘솔에서 Configuration > Virtual media > Remote file share 로 이동합니다.
-
Expired 또는 유효하지 않은 인증서 작업의 값을
Yes
로 변경합니다.