18.4. RHACM 및 siteConfig 리소스를 사용하여 관리형 클러스터 설치
지원 서비스 및 core-reduction 기술이 활성화된 GitOps 플러그인 정책 생성기를 사용하여 RHACM(Red Hat Advanced Cluster Management)을 사용하여 대규모로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. GitOps ZTP(ZTP) 파이프라인은 클러스터 설치를 수행합니다. GitOps ZTP는 연결이 끊긴 환경에서 사용할 수 있습니다.
18.4.1. GitOps ZTP 및 토폴로지 인식 라이프사이클 관리자
GitOps ZTP(ZTP)는 Git에 저장된 매니페스트에서 설치 및 구성 CR을 생성합니다. 이러한 아티팩트는 RHACM(Red Hat Advanced Cluster Management), 지원 서비스, 토폴로지 Aware Lifecycle Manager(TALM)에서 CR을 사용하여 관리 클러스터를 설치하고 구성하는 중앙 집중식 허브 클러스터에 적용됩니다. GitOps ZTP 파이프라인의 구성 단계는 TALM을 사용하여 구성 CR의 애플리케이션을 클러스터에 오케스트레이션합니다. GitOps ZTP와 TALM 사이에는 몇 가지 주요 통합 지점이 있습니다.
- 정책 정보
-
기본적으로 GitOps ZTP는
inform
이라는 수정 작업을 사용하여 모든 정책을 생성합니다. 이러한 정책을 사용하면 RHACM에서 정책과 관련된 클러스터의 규정 준수 상태를 보고하지만 원하는 구성은 적용되지 않습니다. GitOps ZTP 프로세스 중에 OpenShift를 설치한 후 생성된정보
정책을 통해 TALM을 단계화하고 대상 관리 클러스터에 적용합니다. 이렇게 하면 구성이 관리 클러스터에 적용됩니다. 클러스터 라이프사이클의 GitOps 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과 연결된 클러스터만 포함됩니다. -
관리 정책 세트에는
ClusterGroupUpgrade
가 생성될 때 RHACM이 클러스터에 바인딩한 모든 정책이 포함됩니다. - 사전 캐싱은 비활성화되어 있습니다.
- 시간 초과가 4시간(240분)으로 설정됩니다.
활성화된
ClusterGroupUpgrade
의 자동 생성을 통해 사용자 개입 없이도 초기 무차별 클러스터 배포를 진행할 수 있습니다. 또한ztp-done
레이블이 없는ManagedCluster
에 대한ClusterGroupUpgrade
CR을 자동으로 생성하면 클러스터에 대한ClusterGroupUpgrade
CR을 간단히 삭제하여 실패한 GitOps ZTP 설치를 다시 시작할 수 있습니다.-
- 웨이브
PolicyGenTemplate
CR에서 생성된 각 정책에는ztp-deploy-ECDSA 주석이
포함됩니다. 이 주석은 해당 정책에 포함된 각 CR에서 동일한 주석을 기반으로 합니다. 웨이브 주석은 자동 생성된ClusterGroupUpgrade
CR의 정책을 정렬하는 데 사용됩니다. 웨이브 주석은 자동 생성된ClusterGroupUpgrade
CR 이외의 용도로는 사용되지 않습니다.참고동일한 정책의 모든 CR에는
ztp-deploy-
Cryostat 주석에 대해 동일한 설정이 있어야 합니다. 각 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이 자동으로 생성되고 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
로 설정된 owner 참조가 있습니다. 이 참조를 사용하면ManagedCluster
CR을 삭제하면 지원되는 리소스와 함께ClusterGroupUpgrade
인스턴스가 삭제됩니다.
18.4.2. GitOps ZTP를 사용하여 관리형 클러스터 배포 개요
RHACM(Red Hat Advanced Cluster Management)은 GitOps ZTP(ZTP)를 사용하여 단일 노드 OpenShift Container Platform 클러스터, 3노드 클러스터 및 표준 클러스터를 배포합니다. Git 리포지토리에서 사이트 구성 데이터를 OpenShift Container Platform CR(사용자 정의 리소스)으로 관리합니다. GitOps ZTP는 선언적 GitOps 접근 방식을 사용하여 한 번 개발하고 모델을 배포하여 관리 클러스터를 배포합니다.
클러스터 배포에는 다음이 포함됩니다.
- 빈 서버에 호스트 운영 체제(RHCOS) 설치
- OpenShift Container Platform 배포
- 클러스터 정책 및 사이트 서브스크립션 생성
- 서버 운영 체제에 필요한 네트워크 구성 만들기
- 프로파일 Operator 배포 및 성능 프로필, PTP 및 SR-IOV와 같은 필요한 소프트웨어 관련 구성 수행
관리 사이트 설치 프로세스 개요
허브 클러스터에 관리 사이트 CR(사용자 정의 리소스)을 적용한 후 다음 작업이 자동으로 수행됩니다.
- 검색 이미지 ISO 파일이 생성되어 대상 호스트에서 부팅됩니다.
- 대상 호스트에서 ISO 파일이 성공적으로 부팅되면 호스트 하드웨어 정보를 RHACM에 보고합니다.
- 모든 호스트가 검색되면 OpenShift Container Platform이 설치됩니다.
-
OpenShift Container Platform 설치가 완료되면 허브가 대상 클러스터에
klusterlet
서비스를 설치합니다. - 요청된 애드온 서비스가 대상 클러스터에 설치되어 있습니다.
hub 클러스터에서 관리 클러스터의 Agent
CR이 생성되면 Discovery 이미지 ISO 프로세스가 완료됩니다.
대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대해 권장 단일 노드 OpenShift 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.
18.4.3. 관리형 베어 메탈 호스트 시크릿 생성
관리 베어 메탈 호스트에 필요한 Secret
CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. BMC(Baseboard Management Controller)에 액세스하려면 GitOps ZTP(ZTP) 파이프라인의 시크릿과 지원되는 설치 프로그램 서비스에서 레지스트리에서 클러스터 설치 이미지를 가져오는 시크릿이 필요합니다.
보안은 site Config CR에서
이름으로 참조됩니다. 네임스페이스는 site Config 네임스페이스와
일치해야 합니다.
프로세스
OpenShift 및 모든 추가 기능 클러스터 Operator 설치에 필요한 호스트 BMC(Baseboard Management Controller)에 대한 인증 정보와 풀 시크릿을 포함하는 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
에 상대 경로를 추가합니다.
18.4.4. GitOps ZTP를 사용하여 설치를 위한 Discovery ISO 커널 인수 구성
GitOps ZTP(ZTP) 워크플로는 관리형 베어 메탈 호스트에서 OpenShift Container Platform 설치 프로세스의 일부로 Discovery ISO를 사용합니다. InfraEnv
리소스를 편집하여 Discovery ISO에 대한 커널 인수를 지정할 수 있습니다. 이는 특정 환경 요구 사항이 있는 클러스터 설치에 유용합니다. 예를 들어 클러스터의 정적 네트워킹을 용이하게 하거나 설치 중에 루트 파일 시스템을 다운로드하기 전에 DHCP 주소를 수신하도록 Discovery ISO에 rd.net.timeout.carrier
커널 인수를 구성합니다.
OpenShift Container Platform 4.14에서는 커널 인수만 추가할 수 있습니다. 커널 인수를 교체하거나 삭제할 수 없습니다.
사전 요구 사항
- 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을 siteConfig
CR이 있는 Git 리포지토리의 동일한 위치에 커밋하고 변경 사항을 내보냅니다. 다음 예제에서는 샘플 Git 리포지토리 구조를 보여줍니다.~/example-ztp/install └── site-install ├── siteconfig-example.yaml ├── InfraEnv-example.yaml ...
SiteConfig
CR에서spec.clusters.crTemplates
사양을 편집하여 Git 리포지토리의InfraEnv-example.yaml
CR을 참조합니다.clusters: crTemplates: InfraEnv: "InfraEnv-example.yaml"
SiteConfig
CR을 커밋하고 푸시하여 클러스터를 배포할 준비가 되면 빌드 파이프라인은 Git 리포지토리의 사용자 지정InfraEnv-example
CR을 사용하여 사용자 지정 커널 인수를 포함하여 인프라 환경을 구성합니다.
검증
커널 인수가 적용되었는지 확인하려면 검색 이미지에서 OpenShift Container Platform을 설치할 준비가 되었는지 확인한 후 설치 프로세스가 시작되기 전에 대상 호스트에 SSH를 수행할 수 있습니다. 이때 /proc/cmdline
파일에서 Discovery ISO의 커널 인수를 볼 수 있습니다.
대상 호스트를 사용하여 SSH 세션을 시작합니다.
$ ssh -i /path/to/privatekey core@<host_name>
다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.
$ cat /proc/cmdline
18.4.5. SiteConfig 및 GitOps ZTP를 사용하여 관리형 클러스터 배포
다음 절차에 따라 SiteConfig
CR(사용자 정의 리소스) 및 관련 파일을 생성하고 ZTP( GitOps Zero Touch Provisioning) 클러스터 배포를 시작합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 필요한 설치 및 정책 CR을 생성하도록 허브 클러스터를 구성했습니다.
사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 ArgoCD 애플리케이션의 소스 리포지토리로 구성해야 합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
참고소스 리포지토리를 생성할 때
ztp-site-generate
컨테이너에서 추출한argocd/deployment/argocd-openshift-gitops-patch.json
patch-file을 사용하여 ArgoCD 애플리케이션을 패치하는지 확인합니다. " ArgoCD를 사용하여 허브 클러스터 구성"을 참조하십시오.관리 클러스터 프로비저닝을 준비하려면 각 베어 메탈 호스트에 대해 다음이 필요합니다.
- 네트워크 연결
- 네트워크에는 DNS가 필요합니다. 허브 클러스터에서 관리 클러스터 호스트에 연결할 수 있어야 합니다. 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
관리 클러스터에 대한 풀 시크릿 및 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" pullSecretRef: name: "assisted-deployment-pull-secret" clusterImageSetNameRef: "openshift-4.10" sshPublicKey: "ssh-rsa AAAA..." clusters: - clusterName: "example-sno" networkType: "OVNKubernetes" # installConfigOverrides is a generic way of passing install-config # parameters through the siteConfig. The 'capabilities' field configures # the composable openshift feature. In this 'capabilities' setting, we # remove all but the marketplace component from the optional set of # components. # Notes: # - OperatorLifecycleManager is needed for 4.15 and later # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier installConfigOverrides: | { "capabilities": { "baselineCapabilitySet": "None", "additionalEnabledCapabilities": [ "NodeTuning", "OperatorLifecycleManager" ] } } # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+. # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest. # extraManifestPath: sno-extra-manifest clusterLabels: # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples du-profile: "latest" # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates: # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true' common: true # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""' group-du-sno: "" # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"' # Normally this should match or contain the cluster name so it only applies to a single cluster 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 # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate # please see Workload Partitioning Feature for a complete guide. cpuPartitioningMode: AllNodes # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster: #crTemplates: # KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" nodes: - hostName: "example-node1.example.com" role: "master" # Optionally; This can be used to configure desired BIOS setting on a host: #biosConfigRef: # filePath: "example-hw.profile" 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" # Use UEFISecureBoot to enable secure boot bootMode: "UEFI" rootDeviceHints: deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0" # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details ignitionConfigOverride: | { "ignition": { "version": "3.2.0" }, "storage": { "disks": [ { "device": "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0", "partitions": [ { "label": "var-lib-containers", "sizeMiB": 0, "startMiB": 250000 } ], "wipeTable": false } ], "filesystems": [ { "device": "/dev/disk/by-partlabel/var-lib-containers", "format": "xfs", "mountOptions": [ "defaults", "prjquota" ], "path": "/var/lib/containers", "wipeFilesystem": true } ] }, "systemd": { "units": [ { "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target", "enabled": true, "name": "var-lib-containers.mount" } ] } } 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: # For SNO sites with static IP addresses, the node-specific, # API and Ingress IPs should all be the same and configured on # the interface - 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
필드는 쉽게 읽을 수 있도록 확장됩니다.-
외부/argocd/extra-manifest에서
기본 extra-manifestMachineConfig
CR 세트를 검사할 수 있습니다. 설치 시 클러스터에 자동으로 적용됩니다. 선택 사항: 프로비저닝된 클러스터에서 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 리포지토리에 디렉터리를 생성하고 (예:
sno-extra-manifest/
) 사용자 정의 매니페스트 CR을 이 디렉터리에 추가합니다.SiteConfig.yaml
이extraManifestPath
필드의 이 디렉터리를 참조하는 경우 이 참조 디렉터리의 모든 CR이 기본 추가 매니페스트 세트에 추가됩니다.crun OCI 컨테이너 런타임 활성화최적의 클러스터 성능을 위해서는 단일 노드 OpenShift에서 마스터 및 작업자 노드에 대해 crun, 추가 작업자 노드가 있는 단일 노드 OpenShift, 3-노드 OpenShift 및 표준 클러스터를 활성화합니다.
클러스터를 재부팅하지 않도록
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 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다.
검증
노드가 배포된 후 사용자 정의 역할 및 라벨이 적용되는지 확인합니다.
$ oc describe node example-node.example.com
출력 예
Name: example-node.example.com
Roles: control-plane,example-label,master,worker
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
custom-label/parameter1=true
kubernetes.io/arch=amd64
kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
kubernetes.io/os=linux
node-role.kubernetes.io/control-plane=
node-role.kubernetes.io/example-label= 1
node-role.kubernetes.io/master=
node-role.kubernetes.io/worker=
node.openshift.io/os_id=rhcos
- 1
- 사용자 정의 레이블이 노드에 적용됩니다.
18.4.5.1. 단일 노드 OpenShift SiteConfig CR 설치 참조
siteConfig CR 필드 | 설명 |
---|---|
|
참고
|
|
|
|
사이트의 모든 클러스터에 대해 hub 클러스터에서 사용 가능한 이미지 세트를 구성합니다. hub 클러스터에서 지원되는 버전 목록을 보려면 |
|
클러스터 설치 전에 선택적 구성 요소를 활성화하거나 비활성화하려면 중요
예제 |
|
개별 클러스터를 배포하는 데 사용되는 클러스터 이미지 세트를 지정합니다. 정의된 경우 사이트 수준에서 |
|
사용자가 정의한 |
|
선택 사항: |
|
단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 세 개의 호스트를 정의합니다. 표준 배포의 경우 역할이 있는 세 개의 호스트( |
| 관리 클러스터에서 노드의 사용자 지정 역할을 지정합니다. 추가 역할은 사용자만 OpenShift Container Platform 구성 요소에서 사용하지 않습니다. 사용자 지정 역할을 추가하면 해당 역할의 특정 구성을 참조하는 사용자 지정 머신 구성 풀과 연결할 수 있습니다. 설치 중에 사용자 정의 레이블 또는 역할을 추가하면 배포 프로세스가 더 효과적이며 설치가 완료된 후 추가 재부팅이 필요하지 않습니다. |
|
선택 사항: 디스크를 완전히 삭제하지 않고 값의 주석을 |
| 호스트에 액세스하는 데 사용하는 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가 동일해야 합니다. |
18.4.6. 관리형 클러스터 설치 진행 상황 모니터링
ArgoCD 파이프라인은 site Config
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]'
18.4.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>
오브젝트가 반환되지 않은 경우 다음 단계를 사용하여
SiteConfig
파일에서 설치 CR로 ArgoCD 파이프라인 흐름의 문제를 해결합니다.hub 클러스터의
SiteConfig
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
필드에 알 수없는
오류가 표시될 수 있습니다.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
18.4.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 클러스터를 배포하려면 단계를 계속합니다.
18.4.9. GitOps ZTP 파이프라인에서 관리되는 클러스터 사이트 제거
GitOps ZTP(ZTP) 파이프라인에서 관리 사이트 및 관련 설치 및 구성 정책 CR을 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
프로세스
-
kustomization.yaml
파일에서 관련SiteConfig
및PolicyGenTemplate
파일을 제거하여 사이트 및 관련 CR을 제거합니다. SiteConfig
애플리케이션에 다음syncOptions
필드를 추가합니다.kind: Application spec: syncPolicy: syncOptions: - PrunePropagationPolicy=background
GitOps ZTP 파이프라인을 다시 실행하면 생성된 CR이 제거됩니다.
-
선택 사항: 사이트를 영구적으로 제거하려면 Git 리포지토리에서 site
Config
및 사이트별PolicyGenTemplate
파일을 제거해야 합니다. -
선택 사항: 예를 들어 사이트를 재배포할 때 사이트를 일시적으로 제거하려면 site
Config 및 사이트
별PolicyGenTemplate
CR을 Git 리포지토리에 남겨 둘 수 있습니다.
추가 리소스
- 클러스터 제거에 대한 자세한 내용은 관리에서 클러스터 제거를 참조하십시오.
18.4.10. GitOps ZTP 파이프라인에서 더 이상 사용되지 않는 콘텐츠 제거
PolicyGenTemplate
구성을 변경하면 더 이상 사용되지 않는 정책이 생성되는 경우(예: 정책 이름 변경) 다음 절차를 사용하여 더 이상 사용되지 않는 정책을 제거합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
프로세스
-
Git 리포지토리에서 영향을 받는
PolicyGenTemplate
파일을 제거하고 원격 리포지토리를 커밋하고 내보냅니다. - 변경 사항이 애플리케이션을 통해 동기화되고 영향을 받는 정책이 허브 클러스터에서 제거될 때까지 기다립니다.
업데이트된
PolicyGenTemplate
파일을 Git 리포지토리에 다시 추가한 다음 원격 리포지토리를 커밋하고 내보냅니다.참고Git 리포지토리에서 GitOps Zero Touch Provisioning(ZTP) 정책을 제거하면 허브 클러스터에서도 해당 정책을 제거해도 관리 클러스터의 구성에 영향을 미치지 않습니다. 해당 정책에서 관리하는 정책 및 CR은 관리 클러스터에 남아 있습니다.
선택 사항: 대신 더 이상 사용되지 않는 정책을 생성하는
PolicyGenTemplate
CR을 변경한 후 hub 클러스터에서 이러한 정책을 수동으로 제거할 수 있습니다. Governance 탭을 사용하거나 다음 명령을 실행하여 RHACM 콘솔에서 정책을 삭제할 수 있습니다.$ oc delete policy -n <namespace> <policy_name>
18.4.11. GitOps ZTP 파이프라인 종료
ArgoCD 파이프라인 및 생성된 모든 ZTP(ZTP) 아티팩트를 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
프로세스
- hub 클러스터의 RHACM(Red Hat Advanced Cluster Management)에서 모든 클러스터를 분리합니다.
다음 명령을 사용하여
배포
디렉터리에서kustomization.yaml
파일을 삭제합니다.$ oc delete -k out/argocd/deployment
- 변경 사항을 커밋하고 사이트 리포지토리로 내보냅니다.