18.2. ZTP용 허브 클러스터 준비
연결이 끊긴 환경에서 RHACM을 사용하려면 필요한 Operator 이미지가 포함된 OpenShift Container Platform 릴리스 이미지 및 OLM(Operator Lifecycle Manager) 카탈로그를 미러링하는 미러 레지스트리를 생성합니다. OLM은 Operator 및 클러스터의 종속 항목을 관리, 설치 및 업그레이드합니다. 연결이 끊긴 미러 호스트를 사용하여 베어 메탈 호스트를 프로비저닝하는 데 사용되는 RHCOS ISO 및 RootFS 디스크 이미지를 제공할 수도 있습니다.
18.2.1. Telco RAN DU 4.14 검증 소프트웨어 구성 요소
Red Hat telco RAN DU 4.14 솔루션은 OpenShift Container Platform 관리 클러스터 및 허브 클러스터에 대해 다음과 같은 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.
Component | 소프트웨어 버전 |
---|---|
관리형 클러스터 버전 | 4.14 |
Cluster Logging Operator | 5.7 |
Local Storage Operator | 4.14 |
PTP Operator | 4.14 |
SRIOV Operator | 4.14 |
Node Tuning Operator | 4.14 |
Logging Operator | 4.14 |
SRIOV-FEC Operator | 2.7 |
Component | 소프트웨어 버전 |
---|---|
hub 클러스터 버전 | 4.14 |
GitOps ZTP 플러그인 | 4.14 |
Red Hat Advanced Cluster Management(RHACM) | 2.9, 2.10 |
Red Hat OpenShift GitOps | 1.9, 1.10 |
토폴로지 인식 라이프사이클 관리자(TALM) | 4.14 |
18.2.2. GitOps ZTP에 대한 권장 허브 클러스터 사양 및 관리 클러스터 제한
GitOps Zero Touch Provisioning (ZTP)을 사용하면 지리적으로 분산된 지역 및 네트워크에서 수천 개의 클러스터를 관리할 수 있습니다. Red Hat Performance 및 Scale 랩은 랩 환경에서 단일 RHACM(Red Hat Advanced Cluster Management) 허브 클러스터에서 DU 프로필이 감소하여 3500개의 가상 단일 노드 OpenShift 클러스터를 성공적으로 생성 및 관리합니다.
실제 상황에서 관리할 수 있는 클러스터 수에 대한 스케일링 제한은 hub 클러스터에 영향을 미치는 다양한 요인에 따라 달라집니다. 예를 들면 다음과 같습니다.
- hub 클러스터 리소스
- 사용 가능한 허브 클러스터 호스트 리소스(CPU, 메모리, 스토리지)는 허브 클러스터가 관리할 수 있는 클러스터 수를 결정하는 데 중요한 요소입니다. 허브 클러스터에 할당될수록 더 많은 관리 클러스터를 수용할 수 있습니다.
- hub 클러스터 스토리지
- 허브 클러스터 호스트 스토리지 IOPS 등급과 허브 클러스터 호스트가 NVMe 스토리지를 사용하는지 여부는 허브 클러스터 성능과 관리할 수 있는 클러스터 수에 영향을 미칠 수 있습니다.
- 네트워크 대역폭 및 대기 시간
- 허브 클러스터와 관리 클러스터 간의 대기 시간이 느리거나 대기 시간이 긴 네트워크 연결은 허브 클러스터가 여러 클러스터를 관리하는 방법에 영향을 미칠 수 있습니다.
- 관리형 클러스터 크기 및 복잡성
- 관리 클러스터의 크기와 복잡성은 허브 클러스터의 용량에도 영향을 미칩니다. 더 많은 노드, 네임스페이스 및 리소스가 있는 대규모 관리 클러스터에는 추가 처리 및 관리 리소스가 필요합니다. 마찬가지로 RAN DU 프로필 또는 다양한 워크로드와 같은 복잡한 구성이 있는 클러스터에는 허브 클러스터의 더 많은 리소스가 필요할 수 있습니다.
- 관리 정책 수
- 해당 정책에 바인딩된 관리 클러스터 수를 통해 확장되는 허브 클러스터에서 관리하는 정책 수는 관리할 수 있는 클러스터 수를 결정하는 중요한 요소입니다.
- 모니터링 및 관리 워크로드
- RHACM은 관리 클러스터를 지속적으로 모니터링하고 관리합니다. 허브 클러스터에서 실행되는 모니터링 및 관리 워크로드의 수와 복잡성은 용량에 영향을 미칠 수 있습니다. 집중적인 모니터링 또는 빈번한 조정 작업에는 추가 리소스가 필요할 수 있으므로 관리 가능한 클러스터 수를 제한할 수 있습니다.
- RHACM 버전 및 구성
- RHACM의 다른 버전에는 다양한 성능 특성과 리소스 요구 사항이 있을 수 있습니다. 또한 동시 조정 수 또는 상태 점검 빈도와 같은 RHACM의 구성 설정은 허브 클러스터의 관리 클러스터 용량에 영향을 미칠 수 있습니다.
다음 대표 구성 및 네트워크 사양을 사용하여 자체 Hub 클러스터 및 네트워크 사양을 개발합니다.
다음 지침은 내부 랩 벤치마크 테스트만 기반으로 하며 완전한 베어 메탈 호스트 사양을 나타내지 않습니다.
요구 사항 | 설명 |
---|---|
OpenShift Container Platform | 버전 4.13 |
RHACM | 버전 2.7 |
토폴로지 인식 라이프사이클 관리자(TALM) | 버전 4.13 |
서버 하드웨어 | 3개의 x Dell PowerEdge R650 랙 서버 |
NVMe 하드 디스크 |
|
SSD 하드 디스크 |
|
적용되는 DU 프로파일 정책 수 | 5 |
다음 네트워크 사양은 일반적인 실제 RAN 네트워크를 나타내며 테스트 중에 스케일 랩 환경에 적용되었습니다.
사양 | 설명 |
---|---|
Round-trip Time (RTT) 대기 시간 | 50 MS |
패킷 손실 | 0.02% 패킷 손실 |
네트워크 대역폭 제한 | 20Mbps |
18.2.3. 연결이 끊긴 환경에서 GitOps ZTP 설치
연결이 끊긴 환경의 허브 클러스터에서 RHACM(Red Hat Advanced Cluster Management), Red Hat OpenShift GitOps 및 Topology Aware Lifecycle Manager(TALM)를 사용하여 여러 관리 클러스터의 배포를 관리합니다.
사전 요구 사항
-
OpenShift Container Platform CLI(
oc
)를 설치했습니다. -
cluster-admin
권한이 있는 사용자로 로그인했습니다. 클러스터에서 사용할 연결이 끊긴 미러 레지스트리가 구성되어 있습니다.
참고생성하는 연결이 끊긴 미러 레지스트리에는 허브 클러스터에서 실행 중인 TALM 버전과 일치하는 TALM 백업 및 사전 캐시 이미지가 포함되어야 합니다. spoke 클러스터는 연결이 끊긴 미러 레지스트리에서 이러한 이미지를 확인할 수 있어야 합니다.
프로세스
- hub 클러스터에 RHACM을 설치합니다. 연결이 끊긴 환경에서 RHACM 설치를 참조하십시오.
- hub 클러스터에 GitOps 및 TALM을 설치합니다.
18.2.4. 연결이 끊긴 미러 호스트에 RHCOS ISO 및 RootFS 이미지 추가
RHACM(Red Hat Advanced Cluster Management)을 사용하여 연결이 끊긴 환경에 클러스터를 설치하기 전에 먼저 사용할 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅해야 합니다. 연결이 끊긴 미러를 사용하여 RHCOS 이미지를 호스팅합니다.
사전 요구 사항
- 네트워크에서 RHCOS 이미지 리소스를 호스팅하도록 HTTP 서버를 배포하고 구성합니다. 사용자 컴퓨터에서 및 사용자가 생성한 시스템에서 HTTP 서버에 액세스할 수 있어야 합니다.
RHCOS 이미지는 OpenShift Container Platform 릴리스에 따라 변경되지 않을 수 있습니다. 설치하는 버전보다 작거나 같은 최신 버전의 이미지를 다운로드해야 합니다. 사용 가능한 경우 OpenShift Container Platform 버전과 일치하는 이미지 버전을 사용합니다. 호스트에 RHCOS를 설치하려면 ISO 및 RootFS 이미지가 필요합니다. 이 설치 유형에서는 RHCOS QCOW2 이미지가 지원되지 않습니다.
프로세스
- 미러 호스트에 로그인합니다.
mirror.openshift.com 에서 RHCOS ISO 및 RootFS 이미지를 가져옵니다. 예를 들면 다음과 같습니다.
필요한 이미지 이름 및 OpenShift Container Platform 버전을 환경 변수로 내보냅니다.
$ export ISO_IMAGE_NAME=<iso_image_name> 1
$ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1
$ export OCP_VERSION=<ocp_version> 1
필요한 이미지를 다운로드합니다.
$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.14/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.14/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}
검증 단계
다음과 같이 이미지가 성공적으로 다운로드되고 연결이 끊긴 미러 호스트에서 제공되고 있는지 확인합니다.
$ wget http://$(hostname)/${ISO_IMAGE_NAME}
출력 예
Saving to: rhcos-4.14.1-x86_64-live.x86_64.iso rhcos-4.14.1-x86_64-live.x86_64.iso- 11%[====> ] 10.01M 4.71MB/s
추가 리소스
18.2.5. 지원 서비스 활성화
RHACM(Red Hat Advanced Cluster Management)은 지원 서비스를 사용하여 OpenShift Container Platform 클러스터를 배포합니다. RHACM(Red Hat Advanced Cluster Management)에서 MultiClusterHub Operator를 활성화하면 Helped 서비스가 자동으로 배포됩니다. 그 후에는 모든 네임스페이스를 감시하고 AgentServiceConfig
CR(사용자 정의 리소스)을 미러 레지스트리 HTTP 서버에서 호스팅되는 ISO 및 RootFS 이미지에 대한 참조로 업데이트하도록 Provisioning
리소스를 구성해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - MultiClusterHub가 활성화된 RHACM이 있어야 합니다.
프로세스
-
프로비저닝
리소스를 활성화하여 모든 네임스페이스를 조사하고 연결이 끊긴 환경에 대한 미러를 구성합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오. 다음 명령을 실행하여
AgentServiceConfig
CR을 업데이트합니다.$ oc edit AgentServiceConfig
CR의
items.spec.osImages
필드에 다음 항목을 추가합니다.- cpuArchitecture: x86_64 openshiftVersion: "4.14" rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso
다음과 같습니다.
- <host>
- 대상 미러 레지스트리 HTTP 서버의 FQDN(정규화된 도메인 이름)입니다.
- <path>
- 대상 미러 레지스트리의 이미지 경로입니다.
편집기를 저장하고 종료하여 변경 사항을 적용합니다.
18.2.6. 연결이 끊긴 미러 레지스트리를 사용하도록 허브 클러스터 구성
연결이 끊긴 환경에서 연결이 끊긴 미러 레지스트리를 사용하도록 허브 클러스터를 구성할 수 있습니다.
사전 요구 사항
- RHACM(Red Hat Advanced Cluster Management) 2.8이 설치된 연결이 끊긴 허브 클러스터 설치가 있어야 합니다.
-
HTTP 서버의
rootfs
및iso
이미지를 호스팅했습니다. OpenShift Container Platform 이미지 리포지토리 미러링에 대한 지침은 추가 리소스 섹션을 참조하십시오.
HTTP 서버에 대해 TLS를 활성화하면 루트 인증서가 클라이언트가 신뢰하는 기관에서 서명했는지 확인하고 OpenShift Container Platform 허브와 관리 클러스터와 HTTP 서버 간의 신뢰할 수 있는 인증서 체인을 확인해야 합니다. 신뢰할 수 없는 인증서로 구성된 서버를 사용하면 이미지가 이미지 생성 서비스로 다운로드되지 않습니다. 신뢰할 수 없는 HTTPS 서버 사용은 지원되지 않습니다.
프로세스
미러 레지스트리 구성이 포함된
ConfigMap
을 생성합니다.apiVersion: v1 kind: ConfigMap metadata: name: assisted-installer-mirror-config namespace: multicluster-engine 1 labels: app: assisted-service data: ca-bundle.crt: | 2 -----BEGIN CERTIFICATE----- <certificate_contents> -----END CERTIFICATE----- registries.conf: | 3 unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "quay.io/example-repository" 4 mirror-by-digest-only = true [[registry.mirror]] location = "mirror1.registry.corp.com:5000/example-repository" 5
- 1
ConfigMap
네임스페이스는multicluster-engine
으로 설정해야 합니다.- 2
- 미러 레지스트리를 생성할 때 사용되는 미러 레지스트리의 인증서입니다.
- 3
- 미러 레지스트리의 구성 파일입니다. 미러 레지스트리 구성은 검색 이미지의
/etc/containers/registries.conf
파일에 미러 정보를 추가합니다. 미러 정보는 정보가 설치 프로그램에 전달될 때install-config.yaml
파일의imageContentSources
섹션에 저장됩니다. hub 클러스터에서 실행되는 지원 서비스 Pod는 구성된 미러 레지스트리에서 컨테이너 이미지를 가져옵니다. - 4
- 미러 레지스트리의 URL입니다. 미러 레지스트리를 구성할 때
oc adm release mirror
명령을 실행하여imageContentSources
섹션의 URL을 사용해야 합니다. 자세한 내용은 OpenShift Container Platform 이미지 저장소 미러링 섹션을 참조하십시오. - 5
registries.conf
파일에 정의된 레지스트리는 레지스트리가 아닌 리포지터리로 범위를 지정해야 합니다. 이 예에서quay.io/example-repository
및mirror1.registry.corp.com:5000/example-repository
리포지토리의 범위는example-repository
리포지토리로 지정됩니다.
이 업데이트는 다음과 같이
AgentServiceConfig
사용자 정의 리소스에서mirrorRegistryRef
를 업데이트합니다.출력 예
apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: name: agent namespace: multicluster-engine 1 spec: databaseStorage: volumeName: <db_pv_name> accessModes: - ReadWriteOnce resources: requests: storage: <db_storage_size> filesystemStorage: volumeName: <fs_pv_name> accessModes: - ReadWriteOnce resources: requests: storage: <fs_storage_size> mirrorRegistryRef: name: assisted-installer-mirror-config 2 osImages: - openshiftVersion: <ocp_version> url: <iso_url> 3
클러스터 설치 중에 유효한 NTP 서버가 필요합니다. 적절한 NTP 서버를 사용할 수 있고 연결이 끊긴 네트워크를 통해 설치된 클러스터에서 연결할 수 있는지 확인합니다.
18.2.7. 인증되지 않은 레지스트리를 사용하도록 허브 클러스터 구성
인증되지 않은 레지스트리를 사용하도록 허브 클러스터를 구성할 수 있습니다. 인증되지 않은 레지스트리는 이미지에 액세스하고 다운로드하는 데 인증이 필요하지 않습니다.
사전 요구 사항
- hub 클러스터를 설치 및 구성하고 hub 클러스터에 Red Hat Advanced Cluster Management(RHACM)를 설치 및 구성했습니다.
- OpenShift Container Platform CLI(oc)가 설치되어 있습니다.
-
cluster-admin
권한이 있는 사용자로 로그인했습니다. - hub 클러스터에서 사용할 인증되지 않은 레지스트리를 구성했습니다.
프로세스
다음 명령을 실행하여
AgentServiceConfig
CR(사용자 정의 리소스)을 업데이트합니다.$ oc edit AgentServiceConfig agent
CR에
unauthenticatedRegistries
필드를 추가합니다.apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: name: agent spec: unauthenticatedRegistries: - example.registry.com - example.registry2.com ...
인증되지 않은 레지스트리는
AgentServiceConfig
리소스의spec.unauthenticatedRegistries
에 나열됩니다. 이 목록의 레지스트리에는 spoke 클러스터 설치에 사용되는 풀 시크릿에 항목이 필요하지 않습니다.assisted-service
는 설치에 사용되는 모든 이미지 레지스트리에 대한 인증 정보가 포함되어 있는지 확인하여 풀 시크릿을 검증합니다.
미러 레지스트리는 무시 목록에 자동으로 추가되며 spec.unauthenticatedRegistries
아래에 추가할 필요가 없습니다. ConfigMap
에서 PUBLIC_CONTAINER_REGISTRIES
환경 변수를 지정하면 지정된 값이 있는 기본값이 재정의됩니다. PUBLIC_CONTAINER_REGISTRIES
기본값은 quay.io 및 registry.svc.ci.openshift.org 입니다.
검증
다음 명령을 실행하여 hub 클러스터에서 새로 추가된 레지스트리에 액세스할 수 있는지 확인합니다.
hub 클러스터에 대한 디버그 쉘 프롬프트를 엽니다.
$ oc debug node/<node_name>
다음 명령을 실행하여 인증되지 않은 레지스트리에 대한 액세스를 테스트합니다.
sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>
다음과 같습니다.
- <unauthenticated_registry>
-
새 레지스트리입니다(예:
unauthenticated-image-registry.openshift-image-registry.svc:5000
).
출력 예
Login Succeeded!
18.2.8. ArgoCD를 사용하여 허브 클러스터 구성
ZTP(ZTP)를 사용하여 각 사이트에 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하는 ArgoCD 애플리케이션 세트를 사용하여 허브 클러스터를 구성할 수 있습니다.
RHACM(Red Hat Advanced Cluster Management)은 site Config
CR을 사용하여 ArgoCD의 Day 1 관리형 클러스터 설치 CR을 생성합니다. 각 ArgoCD 애플리케이션은 최대 300개의 site Config
CR을 관리할 수 있습니다.
사전 요구 사항
- RHACM(Red Hat Advanced Cluster Management) 및 Red Hat OpenShift GitOps가 설치된 OpenShift Container Platform 허브 클러스터가 있어야 합니다.
-
" GitOps ZTP 사이트 구성 리포지토리 준비" 섹션에 설명된 대로 GitOps ZTP 플러그인 컨테이너에서 참조 배포를 추출했습니다. 참조 배포를 추출하면 다음 절차에서 참조되는
out/argocd/deployment
디렉터리가 생성됩니다.
프로세스
ArgoCD 파이프라인 구성을 준비합니다.
- 예제 디렉터리와 유사한 디렉터리 구조를 사용하여 Git 리포지토리를 생성합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
ArgoCD UI를 사용하여 리포지토리에 대한 액세스를 구성합니다. 설정에서 다음을 구성합니다.
-
리포지토리 - 연결 정보를 추가합니다. URL은
.git
로 끝나야 합니다(예:https://repo.example.com/repo.git
및 인증 정보). - certificates - 필요한 경우 리포지토리의 공용 인증서를 추가합니다.
-
리포지토리 - 연결 정보를 추가합니다. URL은
Git 리포지토리에 따라 2개의 ArgoCD 애플리케이션(
out/argocd/deployment/clusters-app.yaml
및out/argocd/deployment/policies-app.yaml
)을 수정합니다.-
Git 리포지토리를 가리키도록 URL을 업데이트합니다. URL은
.git
로 끝납니다(예:https://repo.example.com/repo.git
). -
targetRevision
은 모니터링할 Git 리포지토리 분기를 나타냅니다. -
path
는 각각SiteConfig
및PolicyGenTemplate
CR의 경로를 지정합니다.
-
Git 리포지토리를 가리키도록 URL을 업데이트합니다. URL은
GitOps ZTP 플러그인을 설치하려면 허브 클러스터의 ArgoCD 인스턴스를 관련 MCCE(Multicluster engine) 서브스크립션 이미지로 패치합니다. 이전에 추출한 패치 파일을 사용자 환경의
out/argocd/deployment/
디렉터리에 사용자 지정합니다.RHACM 버전과 일치하는
multicluster-operators-subscription
이미지를 선택합니다.표 18.6. multicluster-operators-subscription 이미지 버전 OpenShift Container Platform 버전 RHACM 버전 MCE 버전 MCE RHEL 버전 MCE 이미지 4.14, 4.15, 4.16
2.8, 2.9
2.8, 2.9
RHEL 8
registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.8
registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.9
4.14, 4.15, 4.16
2.10
2.10
RHEL 9
registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10
중요multicluster-operators-subscription
이미지의 버전은 RHACM 버전과 일치해야 합니다. MCE 2.10 릴리스부터 RHEL 9는multicluster-operators-subscription
이미지의 기본 이미지입니다.out/argocd/deployment/argocd-openshift-gitops-patch.json
파일에 다음 구성을 추가합니다.{ "args": [ "-c", "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1 ], "command": [ "/bin/bash" ], "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3 "name": "policy-generator-install", "imagePullPolicy": "Always", "volumeMounts": [ { "mountPath": "/.config", "name": "kustomize" } ] }
ArgoCD 인스턴스를 패치합니다. 다음 명령을 실행합니다.
$ oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
RHACM 2.7 이상에서는 다중 클러스터 엔진에서 기본적으로
cluster-proxy-addon
기능을 활성화합니다. 다음 패치를 적용하여cluster-proxy-addon
기능을 비활성화하고 이 애드온을 담당하는 관련 허브 클러스터 및 관리 Pod를 제거합니다. 다음 명령을 실행합니다.$ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
다음 명령을 실행하여 허브 클러스터에 파이프라인 구성을 적용합니다.
$ oc apply -k out/argocd/deployment
18.2.9. GitOps ZTP 사이트 구성 리포지토리 준비
GitOps ZTP(ZTP) 파이프라인을 사용하려면 사이트 구성 데이터를 호스팅하기 위해 Git 리포지토리를 준비해야 합니다.
사전 요구 사항
- 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하도록 Hub 클러스터 GitOps 애플리케이션을 구성했습니다.
- GitOps ZTP를 사용하여 관리 클러스터를 배포했습니다.
프로세스
SiteConfig
및PolicyGenTemplate
CR에 대한 별도의 경로를 사용하여 디렉터리 구조를 생성합니다.참고site
Config
및PolicyGenTemplate
CR을 별도의 디렉터리에 보관합니다.SiteConfig
및PolicyGenTemplate
디렉터리에는 둘 다 해당 디렉터리에 파일을 명시적으로 포함하는kustomization.yaml
파일이 포함되어야 합니다.다음 명령을 사용하여
ztp-site-generate
컨테이너 이미지에서argocd
디렉터리를 내보냅니다.$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14
$ mkdir -p ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14 extract /home/ztp --tar | tar x -C ./out
out
디렉터리에 다음 하위 디렉터리가 포함되어 있는지 확인합니다.-
out/extra-manifest
에는SiteConfig
에서 추가 매니페스트configMap
을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다. -
Out/source-crs
에는PolicyGenTemplate
이 RHACM(Red Hat Advanced Cluster Management) 정책을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다. -
out/argocd/deployment
에는 이 절차의 다음 단계에서 사용할 허브 클러스터에 적용할 패치 및 YAML 파일이 포함되어 있습니다. -
out/argocd/example
에는 권장 구성을 나타내는SiteConfig
및PolicyGenTemplate
파일의 예가 포함되어 있습니다.
-
-
out/source-crs
폴더 및 콘텐츠를PolicyGentemplate
디렉터리에 복사합니다. out/extra-manifests 디렉터리에는 RAN DU 클러스터에 대한 참조 매니페스트가 포함되어 있습니다.
out/extra-manifests
디렉터리를 siteConfig
폴더에 복사합니다. 이 디렉터리에는ztp-site-generate
컨테이너의 CR만 포함되어야 합니다. 여기에 사용자 제공 CR을 추가하지 마십시오. 사용자 제공 CR을 사용하려면 해당 콘텐츠에 대한 다른 디렉터리를 생성해야 합니다. 예를 들면 다음과 같습니다.example/ ├── policygentemplates │ ├── kustomization.yaml │ └── source-crs/ └── siteconfig ├── extra-manifests └── kustomization.yaml
-
디렉터리 구조와
kustomization.yaml
파일을 커밋하고 Git 리포지토리로 내보냅니다. Git으로의 초기 내보내기에는kustomization.yaml
파일이 포함되어야 합니다.
out/argocd/example
아래의 디렉터리 구조를 Git 리포지토리의 구조 및 콘텐츠에 대한 참조로 사용할 수 있습니다. 이러한 구조에는 단일 노드, 3-노드 및 표준 클러스터에 대한 SiteConfig
및 PolicyGenTemplate
참조 CR이 포함됩니다. 사용하지 않는 클러스터 유형에 대한 참조를 제거합니다.
모든 클러스터 유형의 경우 다음을 수행해야 합니다.
-
source-crs
하위 디렉터리를policygentemplate
디렉터리에 추가합니다. -
extra-manifests
디렉터리를siteconfig
디렉터리에 추가합니다.
다음 예제에서는 단일 노드 클러스터 네트워크에 대한 CR 세트를 설명합니다.
example/ ├── policygentemplates │ ├── common-ranGen.yaml │ ├── example-sno-site.yaml │ ├── group-du-sno-ranGen.yaml │ ├── group-du-sno-validator-ranGen.yaml │ ├── kustomization.yaml │ ├── source-crs/ │ └── ns.yaml └── siteconfig ├── example-sno.yaml ├── extra-manifests/ 1 ├── custom-manifests/ 2 ├── KlusterletAddonConfigOverride.yaml └── kustomization.yaml
18.2.9.1. 버전 독립성을 위한 GitOps ZTP 사이트 구성 리포지토리 준비
GitOps ZTP를 사용하여 다른 버전의 OpenShift Container Platform을 실행하는 관리 클러스터의 소스 CR(사용자 정의 리소스)을 관리할 수 있습니다. 즉, hub 클러스터에서 실행되는 OpenShift Container Platform 버전은 관리 클러스터에서 실행되는 버전과 독립적일 수 있습니다.
프로세스
-
SiteConfig
및PolicyGenTemplate
CR에 대한 별도의 경로를 사용하여 디렉터리 구조를 생성합니다. PolicyGenTemplate
디렉터리 내에서 사용할 각 OpenShift Container Platform 버전에 대한 디렉터리를 생성합니다. 각 버전에 다음 리소스를 생성합니다.-
해당 디렉터리에 파일을 명시적으로 포함하는
kustomization.yaml
파일 ztp-site-generate
컨테이너의 참조 CR 구성 파일을 포함하는source-crs
디렉터리사용자 제공 CR을 사용하려면 이를 위해 별도의 디렉터리를 생성해야 합니다.
-
해당 디렉터리에 파일을 명시적으로 포함하는
/siteconfig
디렉터리에서 사용할 각 OpenShift Container Platform 버전의 하위 디렉터리를 생성합니다. 각 버전에 대해 컨테이너에서 복사할 참조 CR을 참조하기 위해 하나 이상의 디렉터리를 생성합니다. 디렉터리 이름 지정 또는 참조 디렉터리 수에는 제한이 없습니다. 사용자 정의 매니페스트를 사용하려면 이를 위해 별도의 디렉터리를 생성해야 합니다.다음 예제에서는 다른 OpenShift Container Platform 버전에 대해 사용자 제공 매니페스트 및 CR을 사용하는 구조를 설명합니다.
├── policygentemplates │ ├── kustomization.yaml 1 │ ├── version_4.13 2 │ │ ├── common-ranGen.yaml │ │ ├── group-du-sno-ranGen.yaml │ │ ├── group-du-sno-validator-ranGen.yaml │ │ ├── helix56-v413.yaml │ │ ├── kustomization.yaml 3 │ │ ├── ns.yaml │ │ └── source-crs/ 4 │ │ └── reference-crs/ 5 │ │ └── custom-crs/ 6 │ └── version_4.14 7 │ ├── common-ranGen.yaml │ ├── group-du-sno-ranGen.yaml │ ├── group-du-sno-validator-ranGen.yaml │ ├── helix56-v414.yaml │ ├── kustomization.yaml 8 │ ├── ns.yaml │ └── source-crs/ 9 │ └── reference-crs/ 10 │ └── custom-crs/ 11 └── siteconfig ├── kustomization.yaml ├── version_4.13 │ ├── helix56-v413.yaml │ ├── kustomization.yaml │ ├── extra-manifest/ 12 │ └── custom-manifest/ 13 └── version_4.14 ├── helix57-v414.yaml ├── kustomization.yaml ├── extra-manifest/ 14 └── custom-manifest/ 15
- 1
- 최상위
kustomization
YAML 파일을 생성합니다. - 2 7
- 사용자 지정
/policygentemplates
디렉터리 내에 버전별 디렉터리를 생성합니다. - 3 8
- 각 버전에 대한
kustomization.yaml
파일을 생성합니다. - 4 9
ztp-site-generate
컨테이너의 참조 CR을 포함하도록 각 버전의source-crs
디렉터리를 생성합니다.- 5 10
- ZTP 컨테이너에서 추출된 정책 CR에 대한
reference-crs
디렉터리를 생성합니다. - 6 11
- 선택 사항: 사용자 제공 CR에 대한 사용자
정의
CR 디렉터리를 생성합니다. - 12 14
- 사용자 지정
/siteconfig
디렉터리에 디렉터리를 생성하여ztp-site-generate
컨테이너의 추가 매니페스트를 포함합니다. - 13 15
- 사용자 제공 매니페스트를 저장할 폴더를 생성합니다.
참고이전 예에서 사용자 지정
/siteconfig
디렉터리의 각 버전 하위 디렉터리에는 컨테이너에서 복사한 참조 매니페스트가 포함된 두 개의 하위 디렉터리가 있으며, 다른 하나는 사용자가 제공하는 사용자 정의 매니페스트를 위한 것입니다. 해당 디렉터리에 할당된 이름은 예입니다. 사용자 제공 CR을 사용하는 경우SiteConfig
CR의extraManifests.searchPaths
아래에 나열된 마지막 디렉터리는 사용자 제공 CR이 포함된 디렉터리여야 합니다.생성한 디렉터리의 검색 경로를 포함하도록
SiteConfig
CR을 편집합니다.extraManifests.searchPaths
아래에 나열된 첫 번째 디렉터리는 참조 매니페스트가 포함된 디렉터리여야 합니다. 디렉터리가 나열되는 순서를 고려하십시오. 디렉터리에 이름이 같은 파일이 포함된 경우 최종 디렉터리의 파일이 우선합니다.siteConfig CR의 예
extraManifests: searchPaths: - extra-manifest/ 1 - custom-manifest/ 2
최상위
kustomization.yaml
파일을 편집하여 활성 상태인 OpenShift Container Platform 버전을 제어합니다. 다음은 최상위 수준의kustomization.yaml
파일의 예입니다.resources: - version_4.13 1 #- version_4.14 2