19.3. RHACM 및 siteConfig 리소스를 사용하여 관리형 클러스터 설치
지원 서비스 및 core-reduction 기술이 활성화된 GitOps 플러그인 정책 생성기를 사용하여 RHACM(Red Hat Advanced Cluster Management)을 사용하여 OpenShift Container Platform 클러스터를 스케일링하여 프로비저닝할 수 있습니다. GitOps Zero ScanSetting Provisioning (ZTP) 파이프라인은 클러스터 설치를 수행합니다. GitOps ZTP는 연결이 끊긴 환경에서 사용할 수 있습니다.
19.3.1. GitOps ZTP 및 토폴로지 Aware Lifecycle Manager
GTP(HITOP) provisioning(ZTP)은 Git에 저장된 매니페스트에서 설치 및 구성 CR을 생성합니다. 이러한 아티팩트는 RHACM(Red Hat Advanced Cluster Management), 지원 서비스 및 TALM( Topology Aware Lifecycle Manager)이 CR을 사용하여 관리되는 클러스터를 설치 및 구성하는 중앙 집중식 허브 클러스터에 적용됩니다. GitOps ZTP 파이프라인의 구성 단계는 TALM을 사용하여 클러스터에 대한 구성 CR의 애플리케이션을 오케스트레이션합니다. GitOps ZTP와 TALM 사이에 몇 가지 주요 통합 지점이 있습니다.
- 정책 정보
-
기본적으로 GitOps ZTP는 정보 수정 작업으로 모든 정책을
생성합니다
. 이러한 정책을 통해 RHACM은 정책과 관련된 클러스터의 컴플라이언스 상태를 보고하지만 원하는 구성은 적용하지 않습니다. GitOps ZTP 프로세스 중에 OpenShift 설치 후 생성된정보 정책을 통한
TALM 단계는 대상 관리 클러스터에 적용합니다. 이는 관리 클러스터에 구성을 적용합니다. 클러스터 라이프사이클의 GitOps ZTP 단계 외부에서 이러한 변경 사항을 영향을 받는 관리형 클러스터로 즉시 롤아웃할 위험없이 정책을 변경할 수 있습니다. TALM을 사용하여 시간 및 수정된 클러스터 세트를 제어할 수 있습니다. - ClusterGroupUpgrade CR 자동 생성
새로 배포된 클러스터의 초기 구성을 자동화하기 위해 TALM은 hub 클러스터에서 모든
ManagedCluster
CR의 상태를 모니터링합니다. 새로 생성된ManagedCluster
CR을 포함하여ztp-done
레이블이 적용되지 않은ManagedCluster
CR을 사용하면 TALM이 다음과 같은 특성을 가진ClusterGroupUpgrade
CR을 자동으로 생성합니다.-
ClusterGroupUpgrade
CR이ztp-install
네임스페이스에서 생성되고 활성화됩니다. -
ClusterGroupUpgrade
CR은ManagedCluster
CR과 이름이 동일합니다. -
클러스터 선택기에는 해당
ManagedCluster
CR과 연결된 클러스터만 포함됩니다. -
관리형 정책 세트에는
ClusterGroupUpgrade
를 생성할 때 RHACM이 클러스터에 바인딩한 모든 정책이 포함됩니다. - 사전 캐싱이 비활성화되어 있습니다.
- 타임아웃은 4시간(240분)으로 설정합니다.
활성화된
ClusterGroupUpgrade
를 자동으로 생성하면 사용자 개입 없이 클러스터의 초기 제로트 배포가 진행됩니다. 또한ztp-done
레이블이 없는ManagedCluster
에 대한ClusterGroupUpgrade
CR 자동 생성을 사용하면 클러스터의ClusterGroupUpgrade
CR을 간단히 삭제하여 실패한 GitOps ZTP 설치를 다시 시작할 수 있습니다.-
- disappears
PolicyGenTemplate
CR에서 생성된 각 정책에는ztp-deploy-ECDHE 주석이 포함되어
있습니다. 이 주석은 해당 정책에 포함된 각 CR의 동일한 주석을 기반으로 합니다. 분리 주석은 자동 생성된ClusterGroupUpgrade
CR에서 정책을 정렬하는 데 사용됩니다. parse 주석은 자동 생성된ClusterGroupUpgrade
CR 이외의 용도로 사용되지 않습니다.참고동일한 정책에 있는 모든 CR은
ztp-deploy-
ECDHE 주석에 대해 동일한 설정을 가져야 합니다. 각 CR에 대한 이 주석의 기본값은PolicyGenTemplate
에서 재정의할 수 있습니다. 소스 CR의 parse 주석은 정책 파도 주석을 결정하고 설정하는 데 사용됩니다. 이 주석은 런타임 시 생성된 정책에 포함된 빌드 CR마다 제거됩니다.TALM은 파기 주석에 의해 지정된 순서대로 구성 정책을 적용합니다. TALM은 다음 정책으로 이동하기 전에 각 정책을 준수할 때까지 기다립니다. 각 CR에 대한 파도 주석이 클러스터에 적용되는 CR의 사전 요구 사항을 고려해야 합니다. 예를 들어 Operator의 구성을 사용하여 Operator 앞에 설치하거나 동시에 설치해야 합니다. 마찬가지로 Operator의
CatalogSource
를 Operator 서브스크립션 앞에 또는 동시에 설치해야 합니다. 각 CR의 기본 전달 값은 이러한 사전 요구 사항을 고려합니다.여러 CR과 정책이 동일한 중단 번호를 공유할 수 있습니다. 정책을 줄이면 배포 속도가 빨라지고 CPU 사용량이 줄어들 수 있습니다. 많은 CR을 상대적으로 소수의 파도로 그룹화하는 것이 가장 좋습니다.
각 소스 CR의 기본 중단 값을 확인하려면 ztp-site-generate
컨테이너 이미지에서 추출된 out/source-crs
디렉터리에 대해 다음 명령을 실행합니다.
$ grep -r "ztp-deploy-wave" out/source-crs
- 단계 라벨
ClusterGroupUpgrade
CR이 자동으로 생성되고 GitOps ZTP 프로세스의 시작 및 끝에 라벨이 있는ManagedCluster
CR에 주석을 달 수 있는 지시문이 포함되어 있습니다.GitOps ZTP 구성 후 설치가 시작되면
ManagedCluster
에ztp-running
레이블이 적용됩니다. 모든 정책이 클러스터에 수정되고 완전히 호환되면 TALM이ztp-running
레이블을 제거하고ztp-done
라벨을 적용합니다.informDuValidator
정책을 사용하는 배포의 경우 클러스터가 애플리케이션 배포를 완전히 준비할 때ztp-done
레이블이 적용됩니다. 여기에는 모든 조정 및 GitOps ZTP 적용된 구성 CR의 결과가 포함됩니다.ztp-done
레이블은 TALM의 자동ClusterGroupUpgrade
CR 생성에 영향을 미칩니다. 클러스터의 초기 GitOps ZTP 설치 후 이 레이블을 조작하지 마십시오.- 연결된 CR
-
자동으로 생성된
ClusterGroupUpgrade
CR에는 소유자 참조가 파생된ManagedCluster
로 설정됩니다. 이 참조를 통해ManagedCluster
CR을 삭제하면 지원되는 리소스와 함께ClusterGroupUpgrade
인스턴스가 삭제됩니다.
19.3.2. GitOps ZTP를 사용하여 관리형 클러스터 배포 개요
RHACM(Red Hat Advanced Cluster Management)은 GitOps ZeroForwarded Provisioning (ZTP)을 사용하여 단일 노드 OpenShift Container Platform 클러스터, 3 노드 클러스터 및 표준 클러스터를 배포합니다. Git 리포지토리에서 사이트 구성 데이터를 OpenShift Container Platform CR(사용자 정의 리소스)으로 관리합니다. GitOps 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 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.
19.3.3. 관리형 베어 메탈 호스트 시크릿 생성
관리 베어 메탈 호스트에 필요한 Secret
CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. BMC(Baseboard Management Controller)에 액세스하려면 GTP(Baseboard Management Controller) 파이프라인과 지원 설치 관리자 서비스에 대한 시크릿이 레지스트리에서 클러스터 설치 이미지를 가져오는 데 필요한 secret이 필요합니다.
보안은 이름으로 site Config CR
에서 참조됩니다. 네임스페이스는 site Config 네임스페이스와
일치해야 합니다.
절차
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
에 추가합니다.
19.3.4. GitOps ZTP를 사용하여 설치를 위한 Discovery ISO 커널 인수 구성
GitOps Zero 10.0.0.1 Provisioning (ZTP) 워크플로우는 관리 베어 메탈 호스트에서 OpenShift Container Platform 설치 프로세스의 일부로 Discovery ISO를 사용합니다. InfraEnv
리소스를 편집하여 Discovery ISO에 대한 커널 인수를 지정할 수 있습니다. 이는 특정 환경 요구 사항이 있는 클러스터 설치에 유용합니다. 예를 들어 Discovery ISO의 rd.net.timeout.carrier
커널 인수를 구성하여 클러스터의 정적 네트워킹을 용이하게 하거나 설치 중에 루트 파일 시스템을 다운로드하기 전에 DHCP 주소를 수신합니다.
OpenShift Container Platform 4.13에서는 커널 인수만 추가할 수 있습니다. 커널 인수를 교체하거나 삭제할 수 없습니다.
사전 요구 사항
- OpenShift CLI(oc)가 설치되어 있습니다.
- cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
InfraEnv
CR을 생성하고spec.kernelArguments
사양을 편집하여 커널 인수를 구성합니다.다음 YAML을
InfraEnv-example.yaml
파일에 저장합니다.참고이 예제의
InfraEnv
CR은SiteConfig
CR의 값에 따라 채워진{{ .Cluster.ClusterName }}
과 같은 템플릿 구문을 사용합니다.SiteConfig
CR은 배포 중에 이러한 템플릿의 값을 자동으로 채웁니다. 템플릿을 수동으로 편집하지 마십시오.apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: annotations: argocd.argoproj.io/sync-wave: "1" name: "{{ .Cluster.ClusterName }}" namespace: "{{ .Cluster.ClusterName }}" spec: clusterRef: name: "{{ .Cluster.ClusterName }}" namespace: "{{ .Cluster.ClusterName }}" kernelArguments: - operation: append 1 value: audit=0 2 - operation: append value: trace=1 sshAuthorizedKey: "{{ .Site.SshPublicKey }}" proxy: "{{ .Cluster.ProxySettings }}" pullSecretRef: name: "{{ .Site.PullSecretRef.Name }}" ignitionConfigOverride: "{{ .Cluster.IgnitionConfigOverride }}" nmStateConfigLabelSelector: matchLabels: nmstate-label: "{{ .Cluster.ClusterName }}" additionalNTPSources: "{{ .Cluster.AdditionalNTPSources }}"
InfraEnv-example.yaml
CR을 Git 리포지토리의 동일한 위치에 커밋하고 변경 사항을 푸시합니다.다음 예제는 샘플 Git 리포지토리 구조를 보여줍니다.
~/example-ztp/install └── site-install ├── siteconfig-example.yaml ├── InfraEnv-example.yaml ...
Git 리포지토리의
InfraEnv-example.yaml
CR을 참조하도록SiteConfig
CR에서spec.clusters.crTemplates
사양을 편집합니다.clusters: crTemplates: InfraEnv: "InfraEnv-example.yaml"
SiteConfig
CR을 커밋하고 푸시하여 클러스터를 배포할 준비가 되면 빌드 파이프라인은 Git 리포지토리에서 사용자 지정InfraEnv-example
CR을 사용하여 사용자 지정 커널 인수를 포함하여 인프라 환경을 구성합니다.
검증
커널 인수가 적용되었는지 확인하려면 Discovery 이미지가 OpenShift Container Platform을 설치할 준비가 되었는지 확인한 후 설치 프로세스를 시작하기 전에 대상 호스트에 SSH를 실행할 수 있습니다. 이 시점에서 /proc/cmdline
파일에서 Discovery ISO에 대한 커널 인수를 볼 수 있습니다.
대상 호스트로 SSH 세션을 시작합니다.
$ ssh -i /path/to/privatekey core@<host_name>
다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.
$ cat /proc/cmdline
19.3.5. SiteConfig 및 GitOps ZTP를 사용하여 관리형 클러스터 배포
다음 절차에 따라 SiteConfig
CR(사용자 정의 리소스) 및 관련 파일을 생성하고 GitOps ZeroForwarded 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) 세부 정보
-
GitOps 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를 설치하는 데 필요한 모든 인증 정보가 포함되어야 합니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오.참고보안은 이름으로 site
Config
CR(사용자 정의 리소스)에서 참조합니다. 네임스페이스는 siteConfig 네임스페이스와
일치해야 합니다.Git 리포지토리의 로컬 복제본에 클러스터용 site
Config
CR을 생성합니다.out/argocd/example/siteconfig/
폴더에 있는 CR에 대한 적절한 예를 선택합니다. 폴더에는 단일 노드, 3 노드 및 표준 클러스터의 예제 파일이 포함되어 있습니다.-
example-sno.yaml
-
example-3node.yaml
-
example-standard.yaml
-
원하는 클러스터 유형과 일치하도록 예제 파일의 클러스터 및 호스트 세부 정보를 변경합니다. 예를 들면 다음과 같습니다.
단일 노드 OpenShift SiteConfig CR의 예
# example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno --- apiVersion: ran.openshift.io/v1 kind: SiteConfig metadata: name: "example-sno" namespace: "example-sno" spec: baseDomain: "example.com" cpuPartitioningMode: AllNodes pullSecretRef: name: "assisted-deployment-pull-secret" clusterImageSetNameRef: "openshift-4.10" sshPublicKey: "ssh-rsa AAAA..." clusters: - clusterName: "example-sno" networkType: "OVNKubernetes" installConfigOverrides: | { "capabilities": { "baselineCapabilitySet": "None", "additionalEnabledCapabilities": [ "marketplace", "NodeTuning" ] } } clusterLabels: common: true group-du-sno: "" sites : "example-sno" 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" nodes: - hostName: "example-node1.example.com" role: "master" bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1" bmcCredentialsName: name: "example-node1-bmh-secret" bootMACAddress: "AA:BB:CC:DD:EE:11" bootMode: "UEFI" rootDeviceHints: wwn: "0x11111000000asd123" # diskPartition: # - device: /dev/disk/by-id/wwn-0x11111000000asd123 # match rootDeviceHints # partitions: # - mount_point: /var/imageregistry # size: 102500 # start: 344844 ignitionConfigOverride: | { "ignition": { "version": "3.2.0" }, "storage": { "disks": [ { "device": "/dev/disk/by-id/wwn-0x11111000000asd123", "wipeTable": false, "partitions": [ { "sizeMiB": 16, "label": "httpevent1", "startMiB": 350000 }, { "sizeMiB": 16, "label": "httpevent2", "startMiB": 350016 } ] } ], "filesystem": [ { "device": "/dev/disk/by-partlabel/httpevent1", "format": "xfs", "wipeFilesystem": true }, { "device": "/dev/disk/by-partlabel/httpevent2", "format": "xfs", "wipeFilesystem": true } ] } } nodeNetwork: interfaces: - name: eno1 macAddress: "AA:BB:CC:DD:EE:11" config: interfaces: - name: eno1 type: ethernet state: up ipv4: enabled: false ipv6: 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
참고BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.
installConfigOverrides
및ignitionConfigOverride
필드는 쉽게 읽을 수 있도록 확장됩니다.-
out/argocd/extra-manifest
에서 기본 extra-manifestMachineConfig
CR 세트를 검사할 수 있습니다. 설치 시 클러스터에 자동으로 적용됩니다. 선택 사항: 프로비저닝된 클러스터에 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 리포지토리에 디렉터리를 생성합니다(예:
sno-extra-manifest/
), 사용자 정의 매니페스트 CR을 이 디렉터리에 추가합니다. siteConfig.yaml
이extraManifestPath
필드의 이 디렉터리를 참조하는 경우 이 참조 디렉터리의 모든 CR이 기본 추가 매니페스트 세트에 추가됩니다.crun OCI 컨테이너 런타임 활성화최적의 클러스터 성능을 위해 단일 노드 OpenShift, 추가 작업자 노드 3 노드, 3 노드 OpenShift 및 표준 클러스터가 있는 단일 노드 OpenShift의 마스터 및 작업자 노드에 대해 crun을 활성화합니다.
클러스터를 재부팅하지 않도록
ContainerRuntimeConfig
CR에서 0일 추가 설치 시간 매니페스트로 crun을 활성화합니다.enable-crun-master.yaml
및enable-crun-worker.yaml
CR 파일은ztp-site-generate
컨테이너에서 추출할 수 있는out/source-crs/optional-extra-manifest/
폴더에 있습니다. 자세한 내용은 " GitOps ZTP 파이프라인에서 추가 설치 매니페스트 사용자 정의"를 참조하십시오.
-
out/argocd/example/siteconfig/
에 표시된 예제와 유사하게kustomization.yaml
generators
섹션의 kustomization.yaml 파일에 siteConfig
CR을 추가합니다. Git 리포지토리
에서 siteConfig
CR 및 관련kustomization.yaml
변경 사항을 커밋하고 변경 사항을 내보냅니다.ArgoCD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.
19.3.5.1. 단일 노드 OpenShift SiteConfig CR 설치 참조
siteConfig CR 필드 | 설명 |
---|---|
|
참고
|
|
|
|
사이트의 모든 클러스터에 대해 hub 클러스터에서 사용 가능한 이미지 세트를 구성합니다. hub 클러스터에서 지원되는 버전 목록을 보려면 |
|
클러스터 설치 전에 선택적 구성 요소를 활성화하거나 비활성화하려면 중요
예제 |
|
개별 클러스터를 배포하는 데 사용되는 클러스터 이미지 세트를 지정합니다. 정의된 경우 사이트 수준에서 |
|
사용자가 정의한 |
|
선택 사항: |
|
단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 3개의 호스트를 정의합니다. 표준 배포의 경우 |
| 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오. |
| 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오. 참고 지금까지 엣지 Telco 사용 사례에서는 GitOps ZTP에서 사용할 수 있도록 가상 미디어만 지원됩니다. |
|
호스트 BMC 인증 정보를 사용하여 별도로 생성하는 |
|
호스트의 부팅 모드를 |
|
배포 장치를 지정합니다. 재부팅 시 안정적인 식별자를 사용하는 것이 좋습니다. 예를 들어 |
|
워크로드 파티셔닝을 위해 클러스터 |
| 선택 사항: 이 필드를 사용하여 영구 스토리지의 파티션을 할당합니다. 디스크 ID와 크기를 특정 하드웨어에 조정합니다. |
| 노드의 네트워크 설정을 구성합니다. |
| 호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다. |
19.3.6. 관리형 클러스터 설치 진행 상황 모니터링
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]'
19.3.7. 설치 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
19.3.8. Supermicro 서버에서 GitOps 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 클러스터를 배포하려면 단계를 계속합니다.
19.3.9. GitOps ZTP 파이프라인에서 관리형 클러스터 사이트 제거
관리 사이트 및 관련 설치 및 구성 정책 CR은 GitOps Zero CloudEvent Provisioning (ZTP) 파이프라인에서 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
kustomization.yaml
파일에서 관련 siteConfig 및
및 관련 CR을 제거합니다.PolicyGenTemplate
파일을 제거하여 사이트GitOps ZTP 파이프라인을 다시 실행하면 생성된 CR이 제거됩니다.
-
선택 사항: 사이트를 영구적으로 제거하려면 Git 리포지토리에서 site
Config
및 사이트별PolicyGenTemplate
파일도 제거해야 합니다. -
선택 사항: 사이트를 임시로 제거하려면 예를 들어 사이트를 재배포할 때 사이트별
PolicyGenTemplate
CR을 Git 리포지토리에 남겨 둘 수 있습니다.
추가 리소스
- 클러스터 제거에 대한 자세한 내용은 관리에서 클러스터 제거를 참조하십시오.
19.3.10. GitOps ZTP 파이프라인에서 더 이상 사용되지 않는 콘텐츠 제거
PolicyGenTemplate
구성을 변경하면 정책과 같이 더 이상 사용되지 않는 정책이 생성되는 경우 다음 절차를 사용하여 더 이상 사용되지 않는 정책을 제거합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
-
Git 리포지토리에서 영향을 받는
PolicyGenTemplate
파일을 제거하고 원격 리포지토리로 커밋하고 내보냅니다. - 변경 사항이 애플리케이션을 통해 동기화되고 영향을 받는 정책이 hub 클러스터에서 제거될 때까지 기다립니다.
업데이트된
PolicyGenTemplate
파일을 Git 리포지토리에 다시 추가한 다음, 원격 리포지토리를 커밋하고 내보냅니다.참고Git 리포지토리에서 GitOps ZeroForwarded Provisioning (ZTP) 정책을 제거하고 hub 클러스터에서도 제거해도 관리 클러스터의 구성에 영향을 미치지 않습니다. 해당 정책에서 관리하는 정책 및 CR은 관리형 클러스터에서 유지됩니다.
선택 사항: 더 이상 사용되지 않는 정책을 생성하는
PolicyGenTemplate
CR을 변경한 후 허브 클러스터에서 이러한 정책을 수동으로 제거할 수 있습니다. Governance 탭을 사용하거나 다음 명령을 실행하여 RHACM 콘솔에서 정책을 삭제할 수 있습니다.$ oc delete policy -n <namespace> <policy_name>
19.3.11. GitOps ZTP 파이프라인 삭제
ArgoCD 파이프라인 및 생성된 모든 GitOps Zero CloudEvent Provisioning (ZTP) 아티팩트를 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
- hub 클러스터의 RHACM(Red Hat Advanced Cluster Management)에서 모든 클러스터를 분리합니다.
다음 명령을 사용하여
배포
디렉터리에서kustomization.yaml
파일을 삭제합니다.$ oc delete -k out/argocd/deployment
- 변경 사항을 커밋하고 사이트 리포지토리로 내보냅니다.