22.3. RHACM 및 siteConfig 리소스를 사용하여 관리형 클러스터 설치
지원 서비스 및 core-reduction 기술이 활성화된 GitOps 플러그인 정책 생성기를 사용하여 RHACM(Red Hat Advanced Cluster Management)을 사용하여 OpenShift Container Platform 클러스터를 스케일링하여 프로비저닝할 수 있습니다. zero touch priovisioning (ZTP) 파이프라인은 클러스터 설치를 수행합니다. ZTP는 연결이 끊긴 환경에서 사용할 수 있습니다.
22.3.1. GitOps ZTP 및 토폴로지 Aware Lifecycle Manager
GitOps zero touch provisioning (ZTP)은 Git에 저장된 매니페스트에서 설치 및 구성 CR을 생성합니다. 이러한 아티팩트는 RHACM(Red Hat Advanced Cluster Management), 지원 서비스 및 TALM( Topology Aware Lifecycle Manager)이 CR을 사용하여 관리되는 클러스터를 설치 및 구성하는 중앙 집중식 허브 클러스터에 적용됩니다. ZTP 파이프라인의 구성 단계에서는 TALM을 사용하여 구성 CR의 애플리케이션을 클러스터에 오케스트레이션합니다. GitOps ZTP와 TALM 간에는 몇 가지 주요 통합 지점이 있습니다.
- 정책 정보
-
기본적으로 GitOps ZTP는 알림 수정 작업을 사용하여 모든 정책을
생성합니다
. 이러한 정책을 통해 RHACM은 정책과 관련된 클러스터의 규정 준수 상태를 보고하지만 원하는 구성은 적용하지 않습니다. ZTP 프로세스 중에 OpenShift를 설치한 후 TALM은 생성된정보
보호 정책을 단계별로 진행하여 대상 관리 클러스터에서 이를 적용합니다. 이는 관리 클러스터에 구성을 적용합니다. 클러스터 라이프사이클의 ZTP 단계 외부에서는 영향을 받는 관리형 클러스터로 변경 사항을 즉시 롤아웃할 위험 없이 정책을 변경할 수 있습니다. TALM을 사용하여 시간 및 수정된 클러스터 세트를 제어할 수 있습니다. - ClusterGroupUpgrade CR 자동 생성
새로 배포된 클러스터의 초기 구성을 자동화하기 위해 TALM은 hub 클러스터에서 모든
ManagedCluster
CR의 상태를 모니터링합니다. 새로 생성된ManagedCluster
CR을 포함하여ztp-done
레이블이 적용되지 않은ManagedCluster
CR을 사용하면 TALM이 다음과 같은 특성을 가진ClusterGroupUpgrade
CR을 자동으로 생성합니다.-
ztp-install
네임스페이스에서ClusterGroupUpgrade
CR이 생성되고 활성화됩니다. -
ClusterGroupUpgrade
CR은ManagedCluster
CR과 이름이 동일합니다. -
클러스터 선택기에는 해당
ManagedCluster
CR과 연결된 클러스터만 포함됩니다. -
관리 정책 세트에는 RHACM이
ClusterGroupUpgrade
가 생성될 때 클러스터에 바인딩한 모든 정책이 포함됩니다. - 사전 캐싱이 비활성화되어 있습니다.
- 시간 제한은 4시간(240분)으로 설정합니다.
활성화된
ClusterGroupUpgrade
의 자동 생성을 통해 클러스터의 초기 배포를 사용자 개입할 필요 없이 진행할 수 있습니다. 또한ztp-done
라벨이 없는ManagedCluster
에 대한ClusterGroupUpgrade
CR을 자동으로 생성하면 클러스터의ClusterGroupUpgrade
CR을 간단히 삭제하여 ZTP 설치를 시작할 수 있습니다.-
- 웨이브
PolicyGenTemplate
CR에서 생성된 각 정책에는ztp-deploy-wave
주석이 포함됩니다. 이 주석은 해당 정책에 포함된 각 CR의 동일한 주석을 기반으로 합니다. 웨이브 주석은 자동 생성된ClusterGroupUpgrade
CR에서 정책을 주문하는 데 사용됩니다. parse 주석은 자동 생성된ClusterGroupUpgrade
CR 이외의 용도로 사용되지 않습니다.참고동일한 정책에 있는 모든 CR에는
ztp-deploy-wave
주석에 동일한 설정이 있어야 합니다. 각 CR에 대한 이 주석의 기본값은PolicyGenTemplate
에서 재정의할 수 있습니다. 소스 CR의 웨이브 주석은 정책 웨이브 주석을 결정하고 설정하는 데 사용됩니다. 이 주석은 런타임에 생성된 정책에 포함된 각 빌드 CR에서 제거됩니다.TALM은 웨이브 주석에 지정된 순서로 구성 정책을 적용합니다. TALM은 다음 정책으로 이동하기 전에 각 정책을 준수할 때까지 기다립니다. 각 CR의 웨이브 주석이 클러스터에 적용되려면 해당 CR의 사전 요구 사항을 고려해야 합니다. 예를 들어 Operator의 구성 전 또는 동시에 Operator를 설치해야 합니다. 마찬가지로 Operator 서브스크립션 이전 또는 동시에 Operator의
CatalogSource
를 웨이브에 설치해야 합니다. 각 CR의 기본 웨이브 값은 이러한 사전 요구 사항을 고려합니다.여러 CR 및 정책이 동일한 파동 번호를 공유할 수 있습니다. 정책이 줄어들면 배포 속도가 빨라지고 CPU 사용량을 줄일 수 있습니다. 많은 CR을 비교적 몇 개의 파도로 그룹화하는 것이 가장 좋습니다.
각 소스 CR의 기본 파도 값을 확인하려면 ztp-site-generate
컨테이너 이미지에서 추출된 out/source-crs
디렉터리에 대해 다음 명령을 실행합니다.
$ grep -r "ztp-deploy-wave" out/source-crs
- 단계 라벨
ClusterGroupUpgrade
CR은 자동으로 생성되며 ZTP 프로세스의 시작 및 종료 시 라벨을 사용하여ManagedCluster
CR에 주석을 답니다.ZTP 구성 후 설치가 시작되면
ManagedCluster
에ztp-running
레이블이 적용됩니다. 모든 정책이 클러스터로 수정되고 완전히 호환되면 이러한 지시문으로 인해 TALM이ztp-running
레이블을 제거하고ztp-done
레이블을 적용합니다.informDuValidator
정책을 사용하는 배포의 경우 클러스터가 애플리케이션 배포를 완전히 준비할 때ztp-done
레이블이 적용됩니다. 여기에는 ZTP 적용 구성 CR의 모든 조정 및 결과 효과가 포함됩니다.ztp-done
레이블은 TALM의 자동ClusterGroupUpgrade
CR 생성에 영향을 미칩니다. 클러스터의 초기 ZTP 설치 후 이 라벨을 조작하지 마십시오.- 연결된 CR
-
자동으로 생성된
ClusterGroupUpgrade
CR에는 파생된ManagedCluster
로 설정된 소유자 참조가 있습니다. 이 참조를 사용하면ManagedCluster
CR을 삭제하면 지원 리소스와 함께ClusterGroupUpgrade
인스턴스가 삭제됩니다.
22.3.2. ZTP를 사용하여 관리형 클러스터 배포 개요
RHACM(Red Hat Advanced Cluster Management)은 zero touch provisioning(ZTP)을 사용하여 단일 노드 OpenShift Container Platform 클러스터, 3노드 클러스터 및 표준 클러스터를 배포합니다. Git 리포지토리에서 사이트 구성 데이터를 OpenShift Container Platform CR(사용자 정의 리소스)으로 관리합니다. ZTP는 선언적 GitOps 접근 방식을 사용하여 한 번 개발하여 관리 클러스터를 배포합니다.
클러스터 배포에는 다음이 포함됩니다.
- 빈 서버에 호스트 운영 체제(RHCOS) 설치
- OpenShift Container Platform 배포
- 클러스터 정책 및 사이트 서브스크립션 생성
- 서버 운영 체제에 필요한 네트워크 구성
- 프로필 Operator 배포 및 성능 프로필, PTP 및 SR-IOV와 같은 필요한 소프트웨어 관련 구성 수행
관리되는 사이트 설치 프로세스 개요
hub 클러스터에서 관리 사이트 CR(사용자 정의 리소스)을 적용하면 다음 작업이 자동으로 수행됩니다.
- 검색 이미지 ISO 파일이 생성되어 대상 호스트에서 부팅됩니다.
- ISO 파일이 대상 호스트에서 성공적으로 부팅되면 호스트 하드웨어 정보를 RHACM에 보고합니다.
- 모든 호스트가 발견되면 OpenShift Container Platform이 설치됩니다.
-
OpenShift Container Platform 설치가 완료되면 허브가 대상 클러스터에
klusterlet
서비스를 설치합니다. - 요청된 애드온 서비스가 대상 클러스터에 설치되어 있습니다.
hub 클러스터에서 관리 클러스터의 에이전트
CR이 생성되면 검색 이미지 ISO 프로세스가 완료됩니다.
대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대한 권장 단일 노드 OpenShift 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.
22.3.3. 관리형 베어 메탈 호스트 시크릿 생성
관리 베어 메탈 호스트에 필요한 Secret
CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. 레지스트리에서 클러스터 설치 이미지를 가져오기 위해 BMC(Baseboard Management Controller) 및 지원 설치 서비스 시크릿에 액세스하려면 ZTP 파이프라인의 시크릿이 필요합니다.
보안은 이름으로 site Config CR
에서 참조됩니다. 네임스페이스는 SiteConfig
네임스페이스와 일치해야 합니다.
절차
OpenShift 및 모든 애드온 클러스터 Operator를 설치하는 데 필요한 BMC(Host Baseboard Management Controller) 및 풀 시크릿(pull secret)의 인증 정보가 포함된 YAML 시크릿 파일을 생성합니다.
다음 YAML을
example-sno-secret.yaml
파일로 저장합니다.apiVersion: v1 kind: Secret metadata: name: example-sno-bmc-secret namespace: example-sno 1 data: 2 password: <base64_password> username: <base64_username> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: pull-secret namespace: example-sno 3 data: .dockerconfigjson: <pull_secret> 4 type: kubernetes.io/dockerconfigjson
-
클러스터를 설치하는 데 사용하는
kustomization.yaml
파일에 상대 경로를example-sno-secret.yaml
에 추가합니다.
22.3.4. siteConfig 및 ZTP를 사용하여 관리형 클러스터 배포
다음 절차에 따라 site Config
CR(사용자 정의 리소스) 및 관련 파일을 생성하고 zero touch provisioning (ZTP) 클러스터 배포를 시작합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 필요한 설치 및 정책 CR을 생성하기 위해 hub 클러스터를 구성하셨습니다.
사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 ArgoCD 애플리케이션의 소스 리포지토리로 구성해야 합니다. 자세한 내용은 "GITOP ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
참고소스 리포지토리를 생성할 때
ztp-site-generate
컨테이너에서 추출한argocd/deployment/argocd-openshift-gitops-patch.json
patch-file을 사용하여 ArgoCD 애플리케이션을 패치해야 합니다. " ArgoCD를 사용하여 hub 클러스터 구성"을 참조하십시오.관리 클러스터를 프로비저닝할 준비를 하려면 각 베어 메탈 호스트에 대해 다음이 필요합니다.
- 네트워크 연결
- 네트워크에는 DNS가 필요합니다. hub 클러스터에서 관리 클러스터 호스트에 연결할 수 있어야 합니다. hub 클러스터와 관리 클러스터 호스트 간에 계층 3 연결이 있는지 확인합니다.
- BMC(Baseboard Management Controller) 세부 정보
-
ZTP는 BMC 사용자 이름과 암호 세부 정보를 사용하여 클러스터 설치 중에 BMC에 연결합니다. GitOps ZTP 플러그인은 사이트 Git 리포지토리의 site
Config
CR을 기반으로 hub 클러스터에서ManagedCluster
CR을 관리합니다. 각 호스트에 대해 개별BMCSecret
CR을 수동으로 생성합니다.
절차
hub 클러스터에서 필요한 관리 클러스터 시크릿을 생성합니다. 이러한 리소스는 클러스터 이름과 일치하는 이름이 있는 네임스페이스에 있어야 합니다. 예를 들어
out/argocd/example/siteconfig/example-sno.yaml
에서 클러스터 이름과 네임스페이스는example-sno
입니다.다음 명령을 실행하여 클러스터 네임스페이스를 내보냅니다.
$ export CLUSTERNS=example-sno
네임스페이스를 생성합니다.
$ oc create namespace $CLUSTERNS
관리형 클러스터의 pull secret 및 BMC
Secret
CR을 생성합니다. 풀 시크릿에는 OpenShift Container Platform 및 모든 필수 Operator 설치에 필요한 모든 인증 정보가 포함되어야 합니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오.참고보안은 이름별로
SiteConfig
CR(사용자 정의 리소스)에서 참조합니다. 네임스페이스는SiteConfig
네임스페이스와 일치해야 합니다.Git 리포지토리의 로컬 복제본에 클러스터용
SiteConfig
CR을 생성합니다.out/argocd/example/siteconfig/
디렉터리에서 CR에 대한 적절한 예제를 선택합니다. 폴더에는 단일 노드, 3-노드 및 표준 클러스터의 예제 파일이 포함되어 있습니다.-
example-sno.yaml
-
example-3node.yaml
-
example-standard.yaml
-
예제 파일의 클러스터와 호스트 세부 정보를 원하는 클러스터 유형과 일치하도록 변경합니다. 예를 들어 다음과 같습니다.
단일 노드 OpenShift 클러스터 siteConfig CR의 예
apiVersion: ran.openshift.io/v1 kind: SiteConfig metadata: name: "<site_name>" namespace: "<site_name>" spec: baseDomain: "example.com" pullSecretRef: name: "assisted-deployment-pull-secret" 1 clusterImageSetNameRef: "openshift-4.11" 2 sshPublicKey: "ssh-rsa AAAA..." 3 clusters: - clusterName: "<site_name>" networkType: "OVNKubernetes" clusterLabels: 4 common: true group-du-sno: "" sites : "<site_name>" clusterNetwork: - cidr: 1001:1::/48 hostPrefix: 64 machineNetwork: - cidr: 1111:2222:3333:4444::/64 serviceNetwork: - 1001:2::/112 additionalNTPSources: - 1111:2222:3333:4444::2 #crTemplates: # KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5 nodes: - hostName: "example-node.example.com" 6 role: "master" bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 7 bmcCredentialsName: name: "bmh-secret" 8 bootMACAddress: "AA:BB:CC:DD:EE:11" bootMode: "UEFI" 9 rootDeviceHints: wwn: "0x11111000000asd123" cpuset: "0-1,52-53" 10 nodeNetwork: 11 interfaces: - name: eno1 macAddress: "AA:BB:CC:DD:EE:11" config: interfaces: - name: eno1 type: ethernet state: up ipv4: enabled: false ipv6: 12 enabled: true address: - ip: 1111:2222:3333:4444::aaaa:1 prefix-length: 64 dns-resolver: config: search: - example.com server: - 1111:2222:3333:4444::2 routes: config: - destination: ::/0 next-hop-interface: eno1 next-hop-address: 1111:2222:3333:4444::1 table-id: 254
- 1
- site
Config CR과 동일한 네임스페이스를 사용하여
을 생성합니다.assisted-deployment-pull-secret
CR - 2
clusterImageSetNameRef
는 hub 클러스터에서 사용 가능한 이미지 세트를 정의합니다. hub 클러스터에서 지원되는 버전 목록을 보려면oc get clusterimagesets
를 실행합니다.- 3
- 클러스터에 액세스하는 데 사용되는 SSH 공개 키를 구성합니다.
- 4
- 클러스터 레이블은 사용자가 정의한
PolicyGenTemplate
CR의bindingRules
필드에 대응해야 합니다. 예를 들어policygentemplates/common-ranGen.yaml
은common: true
set,policygentemplates/group-du-sno-ranGen.yaml
이group-du-sno: ""
가 설정된 모든 클러스터에 적용됩니다. - 5
- 선택사항입니다.
KlusterletAddonConfig
아래에 있는 CR 사양을 사용하여 클러스터에 대해 생성된 기본KlusterletAddonConfig
를 덮어씁니다. - 6
- 단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 3개의 호스트를 정의합니다. 표준 배포의 경우
master와 role
으로 정의된 두 개 이상의 호스트인worker
를 사용하여 3개의 호스트를 정의합니다. - 7
- 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다.
- 8
- 호스트 BMC 자격 증명을 사용하여 별도로 생성하는
bmh-secret
CR의 이름입니다.bmh-secret
CR을 생성할 때 호스트를 프로비저닝하는 siteConfig CR
과 동일한 네임스페이스를 사용합니다. - 9
- 호스트의 부팅 모드를 구성합니다. 기본값은
UEFI
입니다.UEFISecureBoot
를 사용하여 호스트에서 보안 부팅을 활성화합니다. - 10
cpuset
는 워크로드 파티셔닝을 위해 클러스터PerformanceProfile
CRspec.cpu.reserved
필드에 설정된 값과 일치해야 합니다.- 11
- 노드의 네트워크 설정을 지정합니다.
- 12
- 호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다.
참고BMC 주소 지정에 대한 자세한 내용은 "ECDHE 리소스" 섹션을 참조하십시오.
-
out/argocd/extra-manifest
에서 기본 extra-manifestMachineConfig
CR 세트를 검사할 수 있습니다. 이는 설치 시 클러스터에 자동으로 적용됩니다. -
선택 사항: 프로비저닝된 클러스터에서 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 리포지토리에 디렉터리(예:
sno-extra-manifest/
)를 생성하고 사용자 정의 매니페스트 CR을 이 디렉터리에 추가합니다.SiteConfig.yaml
이extraManifestPath
필드에서 이 디렉터리를 참조하는 경우 이 참조되는 디렉터리의 모든 CR이 기본 매니페스트 세트에 추가됩니다.
-
out/argocd/example/siteconfig/
에 표시된 예와 유사하게kustomization.yaml
generators
섹션의 kustomization.yaml 파일에SiteConfig
CR을 추가합니다. Git 리포지토리
에서 siteConfig
CR 및 관련kustomization.yaml
변경 사항을 커밋하고 변경 사항을 내보냅니다.ArgoCD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.
22.3.5. 관리형 클러스터 설치 진행 상황 모니터링
ArgoCD 파이프라인은 siteConfig
CR을 사용하여 클러스터 구성 CR을 생성하고 hub 클러스터와 동기화합니다. ArgoCD 대시보드에서 동기화 진행 상황을 모니터링할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
동기화가 완료되면 설치는 일반적으로 다음과 같이 진행됩니다.
Assisted Service Operator는 클러스터에 OpenShift Container Platform을 설치합니다. RHACM 대시보드 또는 명령줄에서 다음 명령을 실행하여 클러스터 설치 진행 상황을 모니터링할 수 있습니다.
클러스터 이름을 내보냅니다.
$ export CLUSTER=<clusterName>
관리 클러스터의
AgentClusterInstall
CR을 쿼리합니다.$ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
클러스터의 설치 이벤트를 가져옵니다.
$ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'
22.3.6. 설치 CR을 검증하여 GitOps ZTP 문제 해결
ArgoCD 파이프라인은 site Config
및 PolicyGenTemplate
사용자 정의 리소스(CR)를 사용하여 클러스터 구성 CR 및 RHACM(Red Hat Advanced Cluster Management) 정책을 생성합니다. 다음 단계를 사용하여 이 프로세스 중에 발생할 수 있는 문제를 해결합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
다음 명령을 사용하여 설치 CR이 생성되었는지 확인합니다.
$ oc get AgentClusterInstall -n <cluster_name>
반환된 오브젝트가 없는 경우 다음 단계를 사용하여 site
Config
파일에서 설치 CR로의 ArgoCD 파이프라인 흐름 문제를 해결합니다.hub 클러스터에서 site
Config
CR을 사용하여ManagedCluster
CR이 생성되었는지 확인합니다.$ oc get managedcluster
ManagedCluster
가 누락된 경우클러스터
애플리케이션이 Git 리포지토리에서 hub 클러스터와 파일을 동기화하지 못하는지 확인합니다.$ oc describe -n openshift-gitops application clusters
Status.Conditions
필드가 있는지 확인하여 관리형 클러스터의 오류 로그를 확인합니다. 예를 들어, siteConfig
CR에서extraManifestPath:
에 유효하지 않은 값을 설정하면 다음 오류가 발생합니다.Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1 Type: ComparisonError
Status.Sync
필드를 확인합니다. 로그 오류가 있는 경우Status.Sync
필드에Unknown
오류가 표시될 수 있습니다.Status: Sync: Compared To: Destination: Namespace: clusters-sub Server: https://kubernetes.default.svc Source: Path: sites-config Repo URL: https://git.com/ran-sites/siteconfigs/.git Target Revision: master Status: Unknown
22.3.7. Supermicro 서버에서 {ztp} 가상 미디어 부팅 문제 해결
Supermicro X11 서버는 https
프로토콜을 사용하여 이미지를 제공하는 경우 가상 미디어 설치를 지원하지 않습니다. 결과적으로 이 환경의 단일 노드 OpenShift 배포가 대상 노드에서 부팅되지 않습니다. 이 문제를 방지하려면 hub 클러스터에 로그인하고 프로비저닝
리소스에서 TLS(Transport Layer Security)를 비활성화합니다. 이렇게 하면 이미지 주소가 https
스키마를 사용하더라도 TLS로 이미지가 제공되지 않습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
다음 명령을 실행하여
프로비저닝
리소스에서 TLS를 비활성화합니다.$ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'
- 단일 노드 OpenShift 클러스터를 배포하려면 단계를 계속합니다.
22.3.8. ZTP 파이프라인에서 관리형 클러스터 사이트 제거
ZTP 파이프라인에서 관리되는 사이트 및 관련 설치 및 구성 정책 CR을 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
kustomization.yaml
파일에서 관련 siteConfig 및
및 관련 CR을 제거합니다.PolicyGenTemplate
파일을 제거하여 사이트ZTP 파이프라인을 다시 실행하면 생성된 CR이 제거됩니다.
-
선택 사항: 사이트를 영구적으로 제거하려면 Git 리포지토리에서 site
Config
및 사이트별PolicyGenTemplate
파일도 제거해야 합니다. -
선택 사항: 사이트를 임시로 제거하려면 예를 들어 사이트를 재배포할 때 사이트별
PolicyGenTemplate
CR을 Git 리포지토리에 남겨 둘 수 있습니다.
Git 리포지토리에서 site Config
파일을 제거한 후 해당 클러스터가 분리 프로세스에 있는 경우 hub 클러스터에서 RHACM(Red Hat Advanced Cluster Management)을 확인하고 분리된 클러스터를 정리하는 방법에 대한 정보를 확인합니다.
추가 리소스
- 클러스터 제거에 대한 자세한 내용은 관리에서 클러스터 제거를 참조하십시오.
22.3.9. ZTP 파이프라인에서 더 이상 사용되지 않는 콘텐츠 제거
PolicyGenTemplate
구성을 변경하면 정책과 같이 더 이상 사용되지 않는 정책이 생성되는 경우 다음 절차를 사용하여 더 이상 사용되지 않는 정책을 제거합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
-
Git 리포지토리에서 영향을 받는
PolicyGenTemplate
파일을 제거하고 원격 리포지토리로 커밋하고 내보냅니다. - 애플리케이션 및 영향을 받는 정책이 hub 클러스터에서 제거될 때까지 변경 사항이 동기화될 때까지 기다립니다.
업데이트된
PolicyGenTemplate
파일을 Git 리포지토리에 다시 추가한 다음 원격 리포지토리를 커밋하고 내보냅니다.참고Git 리포지토리에서 zero touch provisioning(ZTP) 정책을 제거하면 hub 클러스터에서도 해당 정책을 제거하면 관리 클러스터 구성에 영향을 미치지 않습니다. 해당 정책에서 관리하는 정책 및 CR은 관리형 클러스터에서 유지됩니다.
선택 사항: 더 이상 사용되지 않는 정책을 생성하는
PolicyGenTemplate
CR을 변경한 후 허브 클러스터에서 이러한 정책을 수동으로 제거할 수 있습니다. Governance 탭을 사용하거나 다음 명령을 실행하여 RHACM 콘솔에서 정책을 삭제할 수 있습니다.$ oc delete policy -n <namespace> <policy_name>
22.3.10. ZTP 파이프라인 제거
ArgoCD 파이프라인 및 생성된 모든 ZTP 아티팩트를 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
- hub 클러스터의 RHACM(Red Hat Advanced Cluster Management)에서 모든 클러스터를 분리합니다.
다음 명령을 사용하여
배포
디렉터리에서kustomization.yaml
파일을 삭제합니다.$ oc delete -k out/argocd/deployment
- 변경 사항을 커밋하고 사이트 리포지토리로 내보냅니다.