프로세스

1. 미러 호스트에 로그인합니다.

2. mirror.openshift.com 에서 RHCOS ISO 및 RootFS 이미지를 가져옵니다. 예를 들면 다음과 같습니다.

   1. 필요한 이미지 이름 및 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

      1

      ISO 이미지 이름(예: rhcos-4.15.1-x86_64-live.x86_64.iso)

      1

      rootfs 이미지 이름(예: rhcos-4.15.1-x86_64-live-rootfs.x86_64.img

      1

      OpenShift Container Platform 버전 (예: 4.15.1)

   2. 필요한 이미지를 다운로드합니다.

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.15/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.15/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

프로세스

1. 프로비저닝 리소스를 활성화하여 모든 네임스페이스를 조사하고 연결이 끊긴 환경에 대한 미러를 구성합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.

2. 다음 명령을 실행하여 AgentServiceConfig CR을 업데이트합니다.

   $ oc edit AgentServiceConfig

3. CR의 items.spec.osImages 필드에 다음 항목을 추가합니다.

   - cpuArchitecture: x86_64
       openshiftVersion: "4.15"
       rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
       url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

   다음과 같습니다.

   <host>

   대상 미러 레지스트리 HTTP 서버의 FQDN(정규화된 도메인 이름)입니다.

   <path>

   대상 미러 레지스트리의 이미지 경로입니다.

   편집기를 저장하고 종료하여 변경 사항을 적용합니다.

프로세스

1. 미러 레지스트리 구성이 포함된 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

   1

   ConfigMap 네임스페이스와 일치하도록 AgentServiceConfig 네임스페이스를 multicluster-engine 으로 설정합니다.

   2

   관련 ConfigMap CR에 지정된 정의와 일치하도록 mirrorRegistryRef.name 을 설정합니다.

   3

   httpd 서버에서 호스팅되는 ISO의 URL 설정

프로세스

1. 다음 명령을 실행하여 AgentServiceConfig CR(사용자 정의 리소스)을 업데이트합니다.

   $ oc edit AgentServiceConfig agent

2. 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 는 설치에 사용되는 모든 이미지 레지스트리에 대한 인증 정보가 포함되어 있는지 확인하여 풀 시크릿을 검증합니다.

1. hub 클러스터에 대한 디버그 쉘 프롬프트를 엽니다.

   $ oc debug node/<node_name>

2. 다음 명령을 실행하여 인증되지 않은 레지스트리에 대한 액세스를 테스트합니다.

   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!

프로세스

1. ArgoCD 파이프라인 구성을 준비합니다.

   1. 예제 디렉터리와 유사한 디렉터리 구조를 사용하여 Git 리포지토리를 생성합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.

   2. ArgoCD UI를 사용하여 리포지토리에 대한 액세스를 구성합니다. 설정에서 다음을 구성합니다.

      • 리포지토리 - 연결 정보를 추가합니다. URL은 .git 로 끝나야 합니다(예: https://repo.example.com/repo.git 및 인증 정보).
      • certificates - 필요한 경우 리포지토리의 공용 인증서를 추가합니다.

   3. 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의 경로를 지정합니다.

2. GitOps ZTP 플러그인을 설치하려면 이전에 out/argocd/deployment/ 디렉터리에 추출한 패치 파일을 사용하여 hub 클러스터의 ArgoCD 인스턴스를 패치합니다. 다음 명령을 실행합니다.

   $ oc patch argocd openshift-gitops \
   -n openshift-gitops --type=merge \
   --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

3. 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

4. 다음 명령을 실행하여 허브 클러스터에 파이프라인 구성을 적용합니다.

   $ oc apply -k out/argocd/deployment

프로세스

1. SiteConfig 및 PolicyGenTemplate CR에 대한 별도의 경로를 사용하여 디렉터리 구조를 생성합니다.

   참고

   site Config 및 PolicyGenTemplate CR을 별도의 디렉터리에 보관합니다. SiteConfig 및 PolicyGenTemplate 디렉터리에는 둘 다 해당 디렉터리에 파일을 명시적으로 포함하는 kustomization.yaml 파일이 포함되어야 합니다.

2. 다음 명령을 사용하여 ztp-site-generate 컨테이너 이미지에서 argocd 디렉터리를 내보냅니다.

   $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15

   $ mkdir -p ./out

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./out

3. 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 파일의 예가 포함되어 있습니다.
4. out/source-crs 폴더 및 콘텐츠를 PolicyGentemplate 디렉터리에 복사합니다.

5. out/extra-manifests 디렉터리에는 RAN DU 클러스터에 대한 참조 매니페스트가 포함되어 있습니다. out/extra-manifests 디렉터리를 site Config 폴더에 복사합니다. 이 디렉터리에는 ztp-site-generate 컨테이너의 CR만 포함되어야 합니다. 여기에 사용자 제공 CR을 추가하지 마십시오. 사용자 제공 CR을 사용하려면 해당 콘텐츠에 대한 다른 디렉터리를 생성해야 합니다. 예를 들면 다음과 같습니다.

   example/
     ├── policygentemplates
     │   ├── kustomization.yaml
     │   └── source-crs/
     └── siteconfig
           ├── extra-manifests
           └── kustomization.yaml

6. 디렉터리 구조와 kustomization.yaml 파일을 커밋하고 Git 리포지토리로 내보냅니다. Git으로의 초기 내보내기에는 kustomization.yaml 파일이 포함되어야 합니다.

1. 기존 클러스터에 ztp-done 라벨을 지정합니다.
2. ArgoCD 애플리케이션을 중지합니다.
3. 새 GitOps ZTP 툴을 설치합니다.
4. Git 리포지토리에서 필요한 콘텐츠 및 선택적 변경 사항을 업데이트합니다.
5. 애플리케이션 구성을 업데이트하고 다시 시작합니다.

프로세스

1. GitOps ZTP와 함께 사용하도록 Red Hat OpenShift GitOps를 구성하는 데 사용되는 사용자 정의 리소스(CR)가 있는 GitOps ZTP 컨테이너의 최신 버전을 가져옵니다.

2. 다음 명령을 사용하여 argocd/deployment 디렉터리를 추출합니다.

   $ mkdir -p ./update

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./update

   /update 디렉터리에는 다음 하위 디렉터리가 포함되어 있습니다.

   • update/extra-manifest: SiteConfig CR에서 추가 매니페스트 configMap 을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
   • update/source-crs: PolicyGenTemplate CR에서 RHACM(Red Hat Advanced Cluster Management) 정책을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
   • update/argocd/deployment: 이 절차의 다음 단계에서 사용할 허브 클러스터에 적용할 패치 및 YAML 파일이 포함되어 있습니다.
   • update/argocd/example: 권장 구성 을 나타내는 example siteConfig 및 PolicyGenTemplate 파일이 포함되어 있습니다.

3. 애플리케이션 이름과 Git 리포지토리의 URL, 분기 및 경로를 반영하도록 cluster-app.yaml 및 policies-app.yaml 파일을 업데이트합니다.

   업그레이드에 더 이상 사용되지 않는 정책이 생성되는 변경 사항이 포함된 경우 업그레이드를 수행하기 전에 더 이상 사용되지 않는 정책을 제거해야 합니다.

4. 플릿 사이트 CR을 관리하는 /update 폴더 및 Git 리포지터리의 구성 및 배포 소스 CR 간 변경 사항을 diffe the changes between the configuration and deployment source CRs in the /update folder and Git repo where you manage your fleet site CRs. 필요한 변경 사항을 적용하고 사이트 리포지토리에 내보냅니다.

   중요

   GitOps ZTP를 최신 버전으로 업데이트할 때 update/argocd/deployment 디렉터리의 변경 사항을 사이트 리포지토리에 적용해야 합니다. 이전 버전의 argocd/deployment/ 파일을 사용하지 마십시오.

프로세스

1. local-cluster!=true 와 같이 GitOps ZTP(ZTP)와 함께 배포된 관리 클러스터를 나열하는 라벨 선택기를 찾습니다.

   $ oc get managedcluster -l 'local-cluster!=true'

2. 결과 목록에 GitOps ZTP와 함께 배포된 모든 관리 클러스터가 포함되어 있는지 확인한 다음 해당 선택기를 사용하여 ztp-done 레이블을 추가합니다.

   $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

프로세스

1. 클러스터 애플리케이션에서 캐스케이딩되지 않은 삭제를 수행하여 생성된 모든 리소스를 제자리에 남겨 둡니다.

   $ oc delete -f update/argocd/deployment/clusters-app.yaml

2. 정책 애플리케이션에서 계단식 삭제를 수행하여 이전 정책을 모두 제거합니다.

   $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge

   $ oc delete -f update/argocd/deployment/policies-app.yaml

프로세스

1. GitOps ZTP 플러그인을 설치하려면 이전에 out/argocd/deployment/ 디렉터리에 추출한 패치 파일을 사용하여 hub 클러스터의 ArgoCD 인스턴스를 패치합니다. 다음 명령을 실행합니다.

   $ oc patch argocd openshift-gitops \
   -n openshift-gitops --type=merge \
   --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

2. 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

3. 다음 명령을 실행하여 허브 클러스터에 파이프라인 구성을 적용합니다.

   $ oc apply -k out/argocd/deployment

1. 검색 이미지 ISO 파일이 생성되어 대상 호스트에서 부팅됩니다.
2. 대상 호스트에서 ISO 파일이 성공적으로 부팅되면 호스트 하드웨어 정보를 RHACM에 보고합니다.
3. 모든 호스트가 검색되면 OpenShift Container Platform이 설치됩니다.
4. OpenShift Container Platform 설치가 완료되면 허브가 대상 클러스터에 klusterlet 서비스를 설치합니다.
5. 요청된 애드온 서비스가 대상 클러스터에 설치되어 있습니다.

프로세스

1. OpenShift 및 모든 추가 기능 클러스터 Operator 설치에 필요한 호스트 BMC(Baseboard Management Controller)에 대한 인증 정보와 풀 시크릿을 포함하는 YAML 시크릿 파일을 생성합니다.

   1. 다음 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

      1

      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.

      2

      암호 및 사용자이름에 대한 base64로 인코딩된 값

      3

      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.

      4

      base64로 인코딩된 풀 시크릿

2. 클러스터를 설치하는 데 사용하는 kustomization.yaml 파일에 example-sno-secret.yaml 에 상대 경로를 추가합니다.

프로세스

1. InfraEnv CR을 생성하고 spec.kernelArguments 사양을 편집하여 커널 인수를 구성합니다.

   1. 다음 YAML을 InfraEnv-example.yaml 파일에 저장합니다.

      참고

      이 예제의 InfraEnv CR은 site Config 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 }}"

      1

      커널 인수를 추가하려면 추가 작업을 지정합니다.

      2

      구성할 커널 인수를 지정합니다. 이 예제에서는 audit 커널 인수와 trace 커널 인수를 구성합니다.

2. InfraEnv-example.yaml CR을 site Config CR이 있는 Git 리포지토리의 동일한 위치에 커밋하고 변경 사항을 내보냅니다. 다음 예제에서는 샘플 Git 리포지토리 구조를 보여줍니다.

   ~/example-ztp/install
             └── site-install
                  ├── siteconfig-example.yaml
                  ├── InfraEnv-example.yaml
                  ...

3. SiteConfig CR에서 spec.clusters.crTemplates 사양을 편집하여 Git 리포지토리의 InfraEnv-example.yaml CR을 참조합니다.

   clusters:
     crTemplates:
       InfraEnv: "InfraEnv-example.yaml"

   SiteConfig CR을 커밋하고 푸시하여 클러스터를 배포할 준비가 되면 빌드 파이프라인은 Git 리포지토리의 사용자 지정 InfraEnv-example CR을 사용하여 사용자 지정 커널 인수를 포함하여 인프라 환경을 구성합니다.

1. 대상 호스트를 사용하여 SSH 세션을 시작합니다.

   $ ssh -i /path/to/privatekey core@<host_name>

2. 다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.

   $ cat /proc/cmdline

1. Assisted Service Operator는 클러스터에 OpenShift Container Platform을 설치합니다. 다음 명령을 실행하여 RHACM 대시보드 또는 명령줄에서 클러스터 설치 진행 상황을 모니터링할 수 있습니다.

   1. 클러스터 이름을 내보냅니다.

      $ export CLUSTER=<clusterName>

   2. 관리 클러스터의 AgentClusterInstall CR을 쿼리합니다.

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq

   3. 클러스터의 설치 이벤트를 가져옵니다.

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

프로세스

1. 다음 명령을 사용하여 설치 CR이 생성되었는지 확인합니다.

   $ oc get AgentClusterInstall -n <cluster_name>

   오브젝트가 반환되지 않은 경우 다음 단계를 사용하여 SiteConfig 파일에서 설치 CR로 ArgoCD 파이프라인 흐름의 문제를 해결합니다.

2. hub 클러스터의 SiteConfig CR을 사용하여 ManagedCluster CR이 생성되었는지 확인합니다.

   $ oc get managedcluster

3. ManagedCluster 가 없는 경우 클러스터 애플리케이션이 Git 리포지토리의 파일을 hub 클러스터와 동기화하지 않았는지 확인합니다.

   $ oc describe -n openshift-gitops application clusters

   1. 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

   2. 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

프로세스

1. 다음 명령을 실행하여 프로비저닝 리소스에서 TLS를 비활성화합니다.

   $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'

2. 단일 노드 OpenShift 클러스터를 배포하려면 단계를 계속합니다.

프로세스

1. kustomization.yaml 파일에서 관련 SiteConfig 및 PolicyGenTemplate 파일을 제거하여 사이트 및 관련 CR을 제거합니다.

   GitOps ZTP 파이프라인을 다시 실행하면 생성된 CR이 제거됩니다.

2. 선택 사항: 사이트를 영구적으로 제거하려면 Git 리포지토리에서 site Config 및 사이트별 PolicyGenTemplate 파일을 제거해야 합니다.
3. 선택 사항: 예를 들어 사이트를 재배포할 때 사이트를 일시적으로 제거하려면 site Config 및 사이트 별 PolicyGenTemplate CR을 Git 리포지토리에 남겨 둘 수 있습니다.

프로세스

1. Git 리포지토리에서 영향을 받는 PolicyGenTemplate 파일을 제거하고 원격 리포지토리를 커밋하고 내보냅니다.
2. 변경 사항이 애플리케이션을 통해 동기화되고 영향을 받는 정책이 허브 클러스터에서 제거될 때까지 기다립니다.

3. 업데이트된 PolicyGenTemplate 파일을 Git 리포지토리에 다시 추가한 다음 원격 리포지토리를 커밋하고 내보냅니다.

   참고

   Git 리포지토리에서 GitOps Zero Touch Provisioning(ZTP) 정책을 제거하면 허브 클러스터에서도 해당 정책을 제거해도 관리 클러스터의 구성에 영향을 미치지 않습니다. 해당 정책에서 관리하는 정책 및 CR은 관리 클러스터에 남아 있습니다.

4. 선택 사항: 대신 더 이상 사용되지 않는 정책을 생성하는 PolicyGenTemplate CR을 변경한 후 hub 클러스터에서 이러한 정책을 수동으로 제거할 수 있습니다. Governance 탭을 사용하거나 다음 명령을 실행하여 RHACM 콘솔에서 정책을 삭제할 수 있습니다.

   $ oc delete policy -n <namespace> <policy_name>

프로세스

1. hub 클러스터의 RHACM(Red Hat Advanced Cluster Management)에서 모든 클러스터를 분리합니다.

2. 다음 명령을 사용하여 배포 디렉터리에서 kustomization.yaml 파일을 삭제합니다.

   $ oc delete -k out/argocd/deployment

3. 변경 사항을 커밋하고 사이트 리포지토리로 내보냅니다.

프로세스

1. 사이트별 구성 CR에 대한 PolicyGenTemplate CR을 생성합니다.

   1. out/argocd/example/policygentemplates 폴더에서 CR에 대한 적절한 예를 선택합니다(예: example-sno-site.yaml 또는 example-multinode-site.yaml ).

   2. 예제 파일의 bindingRules 필드를 site Config CR에 포함된 사이트별 레이블과 일치하도록 변경합니다. 예제 SiteConfig 파일에서 사이트별 레이블은 sites: example-sno 입니다.

      참고

      PolicyGenTemplate bindingRules 필드에 정의된 라벨이 관련 관리 클러스터 site Config CR에 정의된 라벨에 해당하는지 확인합니다.

   3. 예제 파일의 콘텐츠를 원하는 구성과 일치하도록 변경합니다.

2. 선택 사항: 전체 클러스터에 적용되는 일반적인 구성 CR에 대한 PolicyGenTemplate CR을 생성합니다.

   1. out/argocd/example/policygentemplates 폴더에서 CR에 대한 적절한 예를 선택합니다(예: common-ranGen.yaml ).
   2. 예제 파일의 콘텐츠를 원하는 구성과 일치하도록 변경합니다.

3. 선택 사항: 플릿의 특정 클러스터 그룹에 적용되는 모든 그룹 구성 CR에 대해 PolicyGenTemplate CR을 생성합니다.

   overlaid 사양 파일의 내용이 원하는 최종 상태와 일치하는지 확인합니다. 참조로 out/source-crs 디렉터리에는 PolicyGenTemplate 템플릿에서 포함할 수 있는 source-crs의 전체 목록이 포함되어 있습니다.

   참고

   클러스터의 특정 요구 사항에 따라 클러스터 유형당 단일 그룹 정책이 필요할 수 있습니다. 특히 예제 그룹 정책에는 각각 동일한 하드웨어 구성으로 구성된 클러스터 집합에서만 공유할 수 있는 단일 PerformancePolicy.yaml 파일이 있습니다.

   1. out/argocd/example/policygentemplates 폴더에서 CR에 대한 적절한 예를 선택합니다(예: group-du-sno-ranGen.yaml ).
   2. 예제 파일의 콘텐츠를 원하는 구성과 일치하도록 변경합니다.
4. 선택 사항: 배포된 클러스터의 GitOps ZTP 설치 및 구성이 완료되면 정책 PolicyGenTemplate CR을 생성합니다. 자세한 내용은 "검토 확인 정보 정책 생성"을 참조하십시오.

5. example out/argocd/example/policygentemplates/ns.yaml 파일과 유사한 YAML 파일에서 모든 정책 네임스페이스를 정의합니다.

   중요

   PolicyGenTemplate CR과 동일한 파일에 Namespace CR을 포함하지 마십시오.

6. out/argocd/example/policygentemplates/ kustomization.yaml 에 표시된 예제와 유사하게 PolicyGenTemplate CR 및 Namespace CR을 generators 섹션의 kustomization.yaml 파일에 추가합니다.

7. Git 리포지토리에서 PolicyGenTemplate CR, Namespace CR 및 관련 kustomization.yaml 파일을 커밋하고 변경 사항을 내보냅니다.

   ArgoCD 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다. 변경 사항을 SiteConfig CR 및 PolicyGenTemplate CR에 동시에 푸시할 수 있습니다.

프로세스

1. Topology Aware Lifecycle Manager(TALM)는 클러스터에 바인딩된 구성 정책을 적용합니다.

   클러스터 설치가 완료되고 클러스터가 Ready 가 되면 ran.openshift.io/ztp-deploy-ECDHE 주석에 의해 정의된 정렬된 정책 목록과 함께 이 클러스터에 해당하는 ClusterGroupUpgrade CR이 TALM에 의해 자동으로 생성됩니다. 클러스터의 정책은 ClusterGroupUpgrade CR에 나열된 순서대로 적용됩니다.

   다음 명령을 사용하여 구성 정책 조정의 고급 진행 상황을 모니터링할 수 있습니다.

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

   출력 예

   {
     "lastTransitionTime": "2022-11-09T07:28:09Z",
     "message": "Remediating non-compliant policies",
     "reason": "InProgress",
     "status": "True",
     "type": "Progressing"
   }

2. RHACM 대시보드 또는 명령줄을 사용하여 자세한 클러스터 정책 규정 준수 상태를 모니터링할 수 있습니다.

   1. oc 를 사용하여 정책 규정 준수를 확인하려면 다음 명령을 실행합니다.

      $ oc get policies -n $CLUSTER

      출력 예

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

   2. RHACM 웹 콘솔에서 정책 상태를 확인하려면 다음 작업을 수행합니다.

      1. Governance → policies 찾기를 클릭합니다.
      2. 클러스터 정책을 클릭하여 상태를 확인합니다.

프로세스

1. 정책에 대한 자세한 정보를 표시하려면 다음 명령을 실행합니다.

   $ oc describe -n openshift-gitops application policies

2. Status: Conditions: 를 확인하여 오류 로그를 표시합니다. 예를 들어 잘못된 sourceFile CryostatfileName: 을 설정하면 다음과 같은 오류가 생성됩니다.

   Status:
     Conditions:
       Last Transition Time:  2021-11-26T17:21:39Z
       Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
       Type:  ComparisonError

3. 상태 확인: 동기화:. Status: Conditions: 에 로그 오류가 있는 경우 Status: Sync: shows Unknown or Error:

   Status:
     Sync:
       Compared To:
         Destination:
           Namespace:  policies-sub
           Server:     https://kubernetes.default.svc
         Source:
           Path:             policies
           Repo URL:         https://git.com/ran-sites/policies/.git
           Target Revision:  master
       Status:               Error

4. RHACM(Red Hat Advanced Cluster Management)에서 ManagedCluster 오브젝트에 정책이 적용되는 것을 인식하면 정책 CR 오브젝트가 클러스터 네임스페이스에 적용됩니다. 정책이 클러스터 네임스페이스에 복사되었는지 확인합니다.

   $ oc get policy -n $CLUSTER

   출력 예:

   NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
   ztp-common.common-config-policy              inform               Compliant          13d
   ztp-common.common-subscriptions-policy       inform               Compliant          13d
   ztp-group.group-du-sno-config-policy         inform               Compliant          13d
   Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
   ztp-site.example-sno-config-policy           inform               Compliant          13d

   RHACM은 적용 가능한 모든 정책을 클러스터 네임스페이스에 복사합니다. 복사된 정책 이름의 형식은 < policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName >입니다.

5. 클러스터 네임스페이스에 복사되지 않은 모든 정책의 배치 규칙을 확인합니다. 해당 정책에 대한 PlacementRule 의 matchSelector 는 ManagedCluster 오브젝트의 라벨과 일치해야 합니다.

   $ oc get placementrule -n $NS

6. 다음 명령을 사용하여 누락된 정책, 공통, 그룹 또는 사이트에 적절한 PlacementRule 이름을 확인합니다.

   $ oc get placementrule -n $NS <placementRuleName> -o yaml

   • status-decisions에는 클러스터 이름이 포함되어야 합니다.
   • 사양에 있는 matchSelector 의 키-값 쌍은 관리 클러스터의 라벨과 일치해야 합니다.

7. 다음 명령을 사용하여 ManagedCluster 오브젝트에서 라벨을 확인합니다.

   $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq

8. 다음 명령을 사용하여 호환되는 정책을 확인합니다.

   $ oc get policy -n $CLUSTER

   네임스페이스 ,OperatorGroup 및 서브스크립션 정책이 호환되지만 Operator 구성 정책이 적용되지 않은 경우 Operator가 관리 클러스터에 설치되지 않을 수 있습니다. 이로 인해 CRD가 아직 spoke에 적용되지 않았기 때문에 Operator 구성 정책이 적용되지 않습니다.

프로세스

1. ClusterGroupUpgrade CR은 관리 클러스터가 Ready 가 된 후 토폴로지 Aware Lifecycle Manager를 통해 ztp-install 네임스페이스에 생성됩니다.

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER

2. 예기치 않은 문제가 있고 정책이 구성된 시간 내에 불만이 발생하지 않는 경우(기본값은 4시간) ClusterGroupUpgrade CR의 상태에 UpgradeTimedOut 이 표시됩니다.

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'

3. UpgradeTimedOut 상태의 ClusterGroupUpgrade CR은 시간마다 정책 조정을 자동으로 다시 시작합니다. 정책을 변경한 경우 기존 ClusterGroupUpgrade CR을 삭제하여 즉시 재시도를 시작할 수 있습니다. 이렇게 하면 새 ClusterGroupUpgrade CR의 자동 생성이 트리거되고 즉시 정책 조정이 시작됩니다.

   $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

프로세스

1. 영향을 받는 CR에서 더 이상 필요하지 않은 콘텐츠를 제거합니다. 이 예에서는 disableDrain: false 행이 SriovOperatorConfig CR에서 제거되었습니다.

   CR 예

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovOperatorConfig
   metadata:
     name: default
     namespace: openshift-sriov-network-operator
   spec:
     configDaemonNodeSelector:
       "node-role.kubernetes.io/$mcp": ""
     disableDrain: true
     enableInjector: true
     enableOperatorWebhook: true

2. 영향을 받는 정책의 complianceType 을 group-du-sno-ranGen.yaml 파일에서 mustonlyhave 로 변경합니다.

   YAML의 예

   # ...
   - fileName: SriovOperatorConfig.yaml
     policyName: "config-policy"
     complianceType: mustonlyhave
   # ...

3. ClusterGroupUpdates CR을 생성하고 CR 변경 사항을 받아야 하는 클러스터를 지정합니다.

   ClusterGroupUpdates CR의 예

   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: cgu-remove
     namespace: default
   spec:
     managedPolicies:
       - ztp-group.group-du-sno-config-policy
     enable: false
     clusters:
     - spoke1
     - spoke2
     remediationStrategy:
       maxConcurrency: 2
       timeout: 240
     batchTimeoutAction:

4. 다음 명령을 실행하여 ClusterGroupUpgrade CR을 생성합니다.

   $ oc create -f cgu-remove.yaml

5. 적절한 유지 관리 기간 동안 변경 사항을 적용할 준비가 되면 다음 명령을 실행하여 spec.enable 필드의 값을 true 로 변경합니다.

   $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
   --patch '{"spec":{"enable":true}}' --type=merge

검증

1. 다음 명령을 실행하여 정책의 상태를 확인합니다.

   $ oc get <kind> <changed_cr_name>

   출력 예

   NAMESPACE   NAME                                                   REMEDIATION ACTION   COMPLIANCE STATE   AGE
   default     cgu-ztp-group.group-du-sno-config-policy               enforce                                 17m
   default     ztp-group.group-du-sno-config-policy                   inform               NonCompliant       15h

   정책의 COMPLIANCE STATE 가 Compliant 인 경우 CR이 업데이트되고 원하지 않는 콘텐츠가 제거됨을 의미합니다.

2. 관리 클러스터에서 다음 명령을 실행하여 정책이 대상 클러스터에서 제거되었는지 확인합니다.

   $ oc get <kind> <changed_cr_name>

   결과가 없는 경우 관리 클러스터에서 CR이 제거됩니다.

프로세스

1. 다음 명령을 실행하여 출력 폴더를 생성합니다.

   $ mkdir -p ./out

2. ztp-site-generate 컨테이너 이미지에서 argocd 디렉터리를 내보냅니다.

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./out

   ./out 디렉터리에는 out/argocd/example/ 폴더에 PolicyGenTemplate 및 SiteConfig CR이 있습니다.

   출력 예

   out
    └── argocd
         └── example
              ├── policygentemplates
              │     ├── common-ranGen.yaml
              │     ├── example-sno-site.yaml
              │     ├── group-du-sno-ranGen.yaml
              │     ├── group-du-sno-validator-ranGen.yaml
              │     ├── kustomization.yaml
              │     └── ns.yaml
              └── siteconfig
                     ├── example-sno.yaml
                     ├── KlusterletAddonConfigOverride.yaml
                     └── kustomization.yaml

3. 사이트 설치 CR의 출력 폴더를 생성합니다.

   $ mkdir -p ./site-install

4. 설치할 클러스터 유형에 대한 SiteConfig CR 예제를 수정합니다. example-sno.yaml 을 site-1-sno.yaml 에 복사하고 설치할 사이트 및 베어 메탈 호스트의 세부 정보와 일치하도록 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:
         # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
         installConfigOverrides: "{\"capabilities\":{\"baselineCapabilitySet\": \"None\", \"additionalEnabledCapabilities\": [ \"marketplace\", \"NodeTuning\" ] }}"
         # 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: "4.14"
           # 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:
               wwn: "0x11111000000asd123"
               # example of diskPartition below is used for image registry (check ImageRegistry.md for more details), but it's not limited to this use case
             #        diskPartition:
             #          - device: /dev/disk/by-id/wwn-0x11111000000asd123 # match rootDeviceHints
             #            partitions:
             #              - mount_point: /var/imageregistry
             #                size: 102500
             #                start: 344844
   
             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

   참고

   ztp-site-generate 컨테이너의 out/extra-manifest 디렉터리에서 참조 CR 구성 파일을 추출하면 extraManifests.searchPaths 를 사용하여 해당 파일이 포함된 git 디렉터리의 경로를 포함할 수 있습니다. 그러면 GitOps ZTP 파이프라인에서 클러스터 설치 중에 해당 CR 파일을 적용할 수 있습니다. searchPaths 디렉터리를 구성하면 GitOps ZTP 파이프라인에서 사이트를 설치하는 동안 ztp-site-generate 컨테이너에서 매니페스트를 가져오지 않습니다.

5. 다음 명령을 실행하여 수정된 SiteConfig CR site-1-sno.yaml 을 처리하여 0일 설치 CR을 생성합니다.

   $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator install site-1-sno.yaml /output

   출력 예

   site-install
   └── site-1-sno
       ├── site-1_agentclusterinstall_example-sno.yaml
       ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
       ├── site-1-sno_clusterdeployment_example-sno.yaml
       ├── site-1-sno_configmap_example-sno.yaml
       ├── site-1-sno_infraenv_example-sno.yaml
       ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
       ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
       ├── site-1-sno_managedcluster_example-sno.yaml
       ├── site-1-sno_namespace_example-sno.yaml
       └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

6. 선택 사항: -E 옵션으로 참조 SiteConfig CR을 처리하여 특정 클러스터 유형에 대한 Day 0 MachineConfig 설치 CR만 생성합니다. 예를 들어 다음 명령을 실행합니다.

   1. MachineConfig CR의 출력 폴더를 생성합니다.

      $ mkdir -p ./site-machineconfig

   2. MachineConfig 설치 CR을 생성합니다.

      $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator install -E site-1-sno.yaml /output

      출력 예

      site-machineconfig
      └── site-1-sno
          ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
          ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
          └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml

7. 이전 단계의 PolicyGenTemplate CR 참조를 사용하여 Day 2 구성 CR을 생성하고 내보냅니다. 다음 명령을 실행합니다.

   1. Day 2 CR의 출력 폴더를 생성합니다.

      $ mkdir -p ./ref

   2. Day 2 구성 CR을 생성하고 내보냅니다.

      $ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator config -N . /output

      이 명령은 단일 노드 OpenShift, 3-노드 클러스터, ./ref 폴더에 표준 클러스터를 위한 예제 그룹 및 사이트별 PolicyGenTemplate CR을 생성합니다.

      출력 예

      ref
       └── customResource
            ├── common
            ├── example-multinode-site
            ├── example-sno
            ├── group-du-3node
            ├── group-du-3node-validator
            │    └── Multiple-validatorCRs
            ├── group-du-sno
            ├── group-du-sno-validator
            ├── group-du-standard
            └── group-du-standard-validator
                 └── Multiple-validatorCRs

8. 생성된 CR을 클러스터를 설치하는 데 사용하는 CR의 기반으로 사용합니다. "단일 관리 클러스터 설치"에 설명된 대로 hub 클러스터에 설치 CR을 적용합니다. 클러스터 설치가 완료된 후 구성 CR을 클러스터에 적용할 수 있습니다.

프로세스

1. OpenShift 및 모든 추가 기능 클러스터 Operator 설치에 필요한 호스트 BMC(Baseboard Management Controller)에 대한 인증 정보와 풀 시크릿을 포함하는 YAML 시크릿 파일을 생성합니다.

   1. 다음 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

      1

      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.

      2

      암호 및 사용자이름에 대한 base64로 인코딩된 값

      3

      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.

      4

      base64로 인코딩된 풀 시크릿

2. 클러스터를 설치하는 데 사용하는 kustomization.yaml 파일에 example-sno-secret.yaml 에 상대 경로를 추가합니다.

프로세스

1. InfraEnv CR에서 spec.kernelArguments 사양을 편집하여 커널 인수를 구성합니다.

1. 대상 호스트를 사용하여 SSH 세션을 시작합니다.

   $ ssh -i /path/to/privatekey core@<host_name>

2. 다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.

   $ cat /proc/cmdline

프로세스

1. 배포할 각 특정 클러스터 버전에 대한 ClusterImageSet 을 만듭니다(예: clusterImageSet-4.15.yaml ). ClusterImageSet 의 형식은 다음과 같습니다.

   apiVersion: hive.openshift.io/v1
   kind: ClusterImageSet
   metadata:
     name: openshift-4.15.0 1
   spec:
      releaseImage: quay.io/openshift-release-dev/ocp-release:4.15.0-x86_64 2

   1

   배포하려는 설명 버전입니다.

   2

   배포할 releaseImage 를 지정하고 운영 체제 이미지 버전을 결정합니다. 검색 ISO는 releaseImage 에서 설정한 이미지 버전 또는 정확한 버전을 사용할 수 없는 경우 최신 버전을 기반으로 합니다.

2. clusterImageSet CR을 적용합니다.

   $ oc apply -f clusterImageSet-4.15.yaml

3. cluster-namespace.yaml 파일에 Namespace CR을 생성합니다.

   apiVersion: v1
   kind: Namespace
   metadata:
        name: <cluster_name> 1
        labels:
           name: <cluster_name> 2

   1 2

   프로비저닝할 관리 클러스터의 이름입니다.

4. 다음 명령을 실행하여 네임스페이스 CR을 적용합니다.

   $ oc apply -f cluster-namespace.yaml

5. ztp-site-generate 컨테이너에서 추출하고 요구 사항을 충족하도록 사용자 지정된 생성된 day-0 CR을 적용합니다.

   $ oc apply -R ./site-install/site-sno-1

프로세스

1. 관리 클러스터의 상태를 확인합니다.

   $ oc get managedcluster

   true 는 관리 클러스터가 준비되었음을 나타냅니다.

2. 에이전트 상태를 확인합니다.

   $ oc get agent -n <cluster_name>

3. describe 명령을 사용하여 에이전트의 상태에 대한 심층적인 설명을 제공합니다. 알 수 있는 상태에는 BackendError,InputError,ValidationsFailing,InstallationFailed, AgentIConnected 가 포함됩니다. 이러한 상태는 Agent 및 AgentClusterInstall 사용자 정의 리소스와 관련이 있습니다.

   $ oc describe agent -n <cluster_name>

4. 클러스터 프로비저닝 상태를 확인합니다.

   $ oc get agentclusterinstall -n <cluster_name>

5. describe 명령을 사용하여 클러스터 프로비저닝 상태에 대한 심층적인 설명을 제공합니다.

   $ oc describe agentclusterinstall -n <cluster_name>

6. 관리 클러스터의 애드온 서비스의 상태를 확인합니다.

   $ oc get managedclusteraddon -n <cluster_name>

7. 관리 클러스터에 대한 kubeconfig 파일의 인증 정보를 검색합니다.

   $ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig

프로세스

1. 관리 클러스터의 상태를 확인합니다.

   $ oc get managedcluster

   출력 예

   NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
   SNO-cluster     true                                   True     True      2d19h

   AVAILABLE 열의 상태가 True 이면 관리 클러스터가 허브에 의해 관리되고 있습니다.

   AVAILABLE 열의 상태가 Unknown 인 경우 관리 클러스터는 허브에 의해 관리되지 않습니다. 자세한 정보를 얻으려면 다음 단계를 계속 확인하십시오.

2. AgentClusterInstall 설치 상태를 확인합니다.

   $ oc get clusterdeployment -n <cluster_name>

   출력 예

   NAME        PLATFORM            REGION   CLUSTERTYPE   INSTALLED    INFRAID    VERSION  POWERSTATE AGE
   Sno0026    agent-baremetal                               false                          Initialized
   2d14h

   INSTALLED 열의 상태가 false 이면 설치에 실패했습니다.

3. 설치에 실패한 경우 다음 명령을 입력하여 AgentClusterInstall 리소스의 상태를 검토합니다.

   $ oc describe agentclusterinstall -n <cluster_name> <cluster_name>

4. 오류를 해결하고 클러스터를 재설정합니다.

   1. 클러스터의 관리 클러스터 리소스를 제거합니다.

      $ oc delete managedcluster <cluster_name>

   2. 클러스터의 네임스페이스를 제거합니다.

      $ oc delete namespace <cluster_name>

      이렇게 하면 이 클러스터에 대해 생성된 네임스페이스 범위 사용자 정의 리소스가 모두 삭제됩니다. 계속하기 전에 ManagedCluster CR 삭제가 완료될 때까지 기다려야 합니다.

   3. 관리 클러스터에 대한 사용자 정의 리소스를 다시 생성합니다.

프로세스

1. UEFI/BIOS 부팅 모드를 UEFI 로 설정합니다.
2. 호스트 부팅 순서에서 먼저 하드 드라이브를 설정합니다.

3. 하드웨어에 대한 특정 펌웨어 구성을 적용합니다. 다음 표에서는 Intel FlexRAN 4G 및 5G 베이스band CryostatY 참조 설계를 기반으로 하는 Intel Xeon Skylake 또는 Intel Cascade Lake 서버의 대표적인 펌웨어 구성에 대해 설명합니다.

   중요

   정확한 펌웨어 구성은 특정 하드웨어 및 네트워크 요구 사항에 따라 다릅니다. 다음 샘플 구성은 예시적인 목적으로만 사용됩니다.

   표 7.2. Intel Xeon Skylake 또는 Cascade Lake 서버의 펌웨어 구성 샘플

   펌웨어 설정	설정
   CPU 전원 및 성능 정책	성능
   코어 빈도 확장 해제	비활성화됨
   성능 P-limit	비활성화됨
   Enhanced Intel SpeedStep ® Tech	활성화됨
   Intel Configurable TDP	활성화됨
   구성 가능한 TDP 수준	수준 2
   Intel® Turbo Boost Technology	활성화됨
   에너지 효율성:	비활성화됨
   하드웨어 P-States	비활성화됨
   Package C-State	C0/C1 상태
   C1E	비활성화됨
   Processor C6	비활성화됨

프로세스

1. 기본 OperatorHub 소스가 비활성화되어 있는지 확인합니다. 다음 명령을 실행합니다.

   $ oc get operatorhub cluster -o yaml

   출력 예

   spec:
       disableAllDefaultSources: true

2. 다음 명령을 실행하여 모든 필요한 CatalogSource 리소스에 워크로드 파티셔닝(PreferredDuringScheduling)에 대한 주석이 있는지 확인합니다.

   $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

   출력 예

   certified-operators -- {"effect": "PreferredDuringScheduling"}
   community-operators -- {"effect": "PreferredDuringScheduling"}
   ran-operators 1
   redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
   redhat-operators -- {"effect": "PreferredDuringScheduling"}

   1

   주석이 없는 CatalogSource 리소스도 반환됩니다. 이 예에서 ran-operators CatalogSource 리소스에는 주석이 추가되지 않으며 PreferredDuringScheduling 주석이 없습니다.

   참고

   올바르게 구성된 vDU 클러스터에는 주석이 지정된 단일 카탈로그 소스만 나열됩니다.

3. 워크로드 파티셔닝을 위해 해당하는 모든 OpenShift Container Platform Operator 네임스페이스에 주석이 추가되었는지 확인합니다. 여기에는 코어 OpenShift Container Platform과 함께 설치된 모든 Operator 및 참조 DU 튜닝 구성에 포함된 추가 Operator 세트가 포함됩니다. 다음 명령을 실행합니다.

   $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

   출력 예

   default --
   openshift-apiserver -- management
   openshift-apiserver-operator -- management
   openshift-authentication -- management
   openshift-authentication-operator -- management

   중요

   추가 Operator는 워크로드 파티셔닝을 위해 주석을 달 수 없습니다. 이전 명령의 출력에서 -- separator 오른쪽에 값을 지정하지 않고 추가 Operator를 나열해야 합니다.

4. ClusterLogging 구성이 올바른지 확인합니다. 다음 명령을 실행합니다.

   1. 적절한 입력 및 출력 로그가 구성되어 있는지 확인합니다.

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      출력 예

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
        creationTimestamp: "2022-07-19T21:51:41Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "1030342"
        uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
      spec:
        inputs:
        - infrastructure: {}
          name: infra-logs
        outputs:
        - name: kafka-open
          type: kafka
          url: tcp://10.46.55.190:9092/test
        pipelines:
        - inputRefs:
          - audit
          name: audit-logs
          outputRefs:
          - kafka-open
        - inputRefs:
          - infrastructure
          name: infrastructure-logs
          outputRefs:
          - kafka-open
      ...

   2. 큐레이션 일정이 애플리케이션에 적합한지 확인합니다.

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      출력 예

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        creationTimestamp: "2022-07-07T18:22:56Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "235796"
        uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
      spec:
        collection:
          logs:
            fluentd: {}
            type: fluentd
        curation:
          curator:
            schedule: 30 3 * * *
          type: curator
        managementState: Managed
      ...

5. 다음 명령을 실행하여 웹 콘솔이 비활성화(managementState: Removed)인지 확인합니다.

   $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

   출력 예

   Removed

6. 다음 명령을 실행하여 클러스터 노드에서 chronyd 가 비활성화되어 있는지 확인합니다.

   $ oc debug node/<node_name>

   노드에서 chronyd 의 상태를 확인합니다.

   sh-4.4# chroot /host

   sh-4.4# systemctl status chronyd

   출력 예

   ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:chronyd(8)
               man:chrony.conf(5)

7. linuxptp-daemon 컨테이너 및 PTP 관리 클라이언트(pmc) 툴에 대한 원격 쉘 연결을 사용하여 PTP 인터페이스가 기본 클록에 성공적으로 동기화되었는지 확인합니다.

   1. 다음 명령을 실행하여 linuxptp-daemon Pod의 이름으로 $PTP_POD_NAME 변수를 설정합니다.

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

   2. 다음 명령을 실행하여 PTP 장치의 동기화 상태를 확인합니다.

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      출력 예

      sending: GET PORT_DATA_SET
        3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-1
          portState               SLAVE
          logMinDelayReqInterval  -4
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2
        3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-2
          portState               LISTENING
          logMinDelayReqInterval  0
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2

   3. 다음 pmc 명령을 실행하여 PTP 클럭 상태를 확인합니다.

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      출력 예

      sending: GET TIME_STATUS_NP
        3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
          master_offset              10 1
          ingress_time               1657275432697400530
          cumulativeScaledRateOffset +0.000000000
          scaledLastGmPhaseChange    0
          gmTimeBaseIndicator        0
          lastGmPhaseChange          0x0000'0000000000000000.0000
          gmPresent                  true 2
          gmIdentity                 3c2c30.ffff.670e00

      1

      master_offset 은 -100과 100 ns 사이여야 합니다.

      2

      PTP 시계가 마스터에 동기화되고 로컬 클록이 마스터 클록이 아님을 나타냅니다.

   4. /var/run/ptp4l.0.config 의 값에 해당하는 예상 마스터 오프셋 값이 linuxptp-daemon-container 로그에 있는지 확인합니다.

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      출력 예

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
      ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
      ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

8. 다음 명령을 실행하여 SR-IOV 구성이 올바른지 확인합니다.

   1. SriovOperatorConfig 리소스의 disableDrain 값이 true 로 설정되어 있는지 확인합니다.

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      출력 예

      true

   2. 다음 명령을 실행하여 SriovNetworkNodeState 동기화 상태가 Succeeded 인지 확인합니다.

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      출력 예

      Succeeded

   3. SR-IOV용으로 구성된 각 인터페이스에서Vfs(가상 기능)의 예상 수와 구성이 있고 .status.interfaces 필드에 올바른지 확인합니다. 예를 들면 다음과 같습니다.

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      출력 예

      apiVersion: v1
      items:
      - apiVersion: sriovnetwork.openshift.io/v1
        kind: SriovNetworkNodeState
      ...
        status:
          interfaces:
          ...
          - Vfs:
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.0
              vendor: "8086"
              vfID: 0
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.1
              vendor: "8086"
              vfID: 1
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.2
              vendor: "8086"
              vfID: 2
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.3
              vendor: "8086"
              vfID: 3
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.4
              vendor: "8086"
              vfID: 4
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.5
              vendor: "8086"
              vfID: 5
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.6
              vendor: "8086"
              vfID: 6
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.7
              vendor: "8086"
              vfID: 7

9. 클러스터 성능 프로필이 올바른지 확인합니다. cpu 및 hugepages 섹션은 하드웨어 구성에 따라 다릅니다. 다음 명령을 실행합니다.

   $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

   출력 예

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     creationTimestamp: "2022-07-19T21:51:31Z"
     finalizers:
     - foreground-deletion
     generation: 1
     name: openshift-node-performance-profile
     resourceVersion: "33558"
     uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
   spec:
     additionalKernelArgs:
     - idle=poll
     - rcupdate.rcu_normal_after_boot=0
     - efi=runtime
     cpu:
       isolated: 2-51,54-103
       reserved: 0-1,52-53
     hugepages:
       defaultHugepagesSize: 1G
       pages:
       - count: 32
         size: 1G
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/master: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/master: ""
     numa:
       topologyPolicy: restricted
     realTimeKernel:
       enabled: true
   status:
     conditions:
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Available
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Upgradeable
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Progressing
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Degraded
     runtimeClass: performance-openshift-node-performance-profile
     tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

   참고

   CPU 설정은 서버에서 사용 가능한 코어 수에 따라 다르며 워크로드 파티셔닝 설정과 일치해야 합니다. hugepages 구성은 서버와 애플리케이션에 따라 다릅니다.

10. 다음 명령을 실행하여 PerformanceProfile 이 클러스터에 성공적으로 적용되었는지 확인합니다.

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    출력 예

    Available -- True
    Upgradeable -- True
    Progressing -- False
    Degraded -- False

11. 다음 명령을 실행하여 Tuned 성능 패치 설정을 확인합니다.

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    출력 예

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      creationTimestamp: "2022-07-18T10:33:52Z"
      generation: 1
      name: performance-patch
      namespace: openshift-cluster-node-tuning-operator
      resourceVersion: "34024"
      uid: f9799811-f744-4179-bf00-32d4436c08fd
    spec:
      profile:
      - data: |
          [main]
          summary=Configuration changes profile inherited from performance created tuned
          include=openshift-node-performance-openshift-node-performance-profile
          [bootloader]
          cmdline_crash=nohz_full=2-23,26-47 1
          [sysctl]
          kernel.timer_migration=1
          [scheduler]
          group.ice-ptp=0:f:10:*:ice-ptp.*
          [service]
          service.stalld=start,enable
          service.chronyd=stop,disable
        name: performance-patch
      recommend:
      - machineConfigLabels:
          machineconfiguration.openshift.io/role: master
        priority: 19
        profile: performance-patch

    1

    cmdline=nohz_full= 의 cpu 목록은 하드웨어 구성에 따라 다릅니다.

12. 다음 명령을 실행하여 클러스터 네트워킹 진단이 비활성화되었는지 확인합니다.

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    출력 예

    true

13. Kubelet 하우스키핑 간격이 느린 속도로 조정되었는지 확인합니다. 이는 containerMountNS 머신 구성에 설정됩니다. 다음 명령을 실행합니다.

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    출력 예

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

14. 다음 명령을 실행하여 Grafana 및 alertManagerMain 이 비활성화되어 Prometheus 보존 기간이 24h로 설정되어 있는지 확인합니다.

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    출력 예

    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    prometheusK8s:
       retention: 24h

    1. 다음 명령을 사용하여 Grafana 및 alertManagerMain 경로가 클러스터에 없는지 확인합니다.

       $ oc get route -n openshift-monitoring alertmanager-main

       $ oc get route -n openshift-monitoring grafana

       두 쿼리 모두 서버 오류(NotFound) 메시지를 반환해야 합니다.

15. 다음 명령을 실행하여 PerformanceProfile,Tuned performance-patch, 워크로드 파티셔닝 및 커널 명령줄 인수에 대해 예약된 CPU가 최소 4개 이상 있는지 확인합니다.

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    출력 예

    0-3

    참고

    워크로드 요구 사항에 따라 추가 예약된 CPU를 할당해야 할 수 있습니다.

프로세스

1. GitOps ZTP 파이프라인에서 클러스터 설치를 사용자 정의하는 데 사용하는 추가 매니페스트 CR 세트를 생성합니다.

2. 사용자 지정 /siteconfig 디렉터리에서 추가 매니페스트를 위한 하위 디렉터리 /custom-manifest 를 생성합니다. 다음 예제에서는 /custom-manifest 폴더가 있는 샘플 /siteconfig 를 보여줍니다.

   siteconfig
   ├── site1-sno-du.yaml
   ├── site2-standard-du.yaml
   ├── extra-manifest/
   └── custom-manifest
       └── 01-example-machine-config.yaml

   참고

   전체에서 사용되는 하위 디렉터리 이름 /custom-manifest 및 /extra-manifest 는 예제 이름 전용입니다. 이러한 이름을 사용할 필요는 없으며 이러한 하위 디렉터리의 이름을 지정하는 방법에 대한 제한은 없습니다. 이 예에서 /extra-manifest 는 ztp-site-generate 컨테이너에서 /extra-manifest 의 콘텐츠를 저장하는 Git 하위 디렉터리를 나타냅니다.

3. 사용자 정의 매니페스트 CR을 siteconfig/custom-manifest 디렉터리에 추가합니다.

4. SiteConfig CR에서 extraManifests.searchPaths 필드에 디렉터리 이름을 입력합니다. 예를 들면 다음과 같습니다.

   clusters:
   - clusterName: "example-sno"
     networkType: "OVNKubernetes"
     extraManifests:
       searchPaths:
         - extra-manifest/ 1
         - custom-manifest/ 2

   1

   ztp-site-generate 컨테이너에서 복사한 매니페스트의 폴더입니다.

   2

   사용자 정의 매니페스트용 폴더입니다.

5. SiteConfig,/extra-manifest CR 및 /custom-manifest CR을 저장하고 사이트 구성 리포지터리로 푸시합니다.

프로세스

1. GitOps ZTP 파이프라인이 03-sctp-machine-config-worker.yaml CR 파일을 적용하지 못하도록 site Config CR에 다음 YAML을 적용합니다.

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "site1-sno-du"
     namespace: "site1-sno-du"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.15"
     sshPublicKey: "<ssh_public_key>"
     clusters:
   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         exclude:
           - 03-sctp-machine-config-worker.yaml

   GitOps ZTP 파이프라인은 설치 중에 03-sctp-machine-config-worker.yaml CR을 건너뜁니다. /source-crs/extra-manifest 의 다른 모든 CR이 적용됩니다.

2. SiteConfig CR을 저장하고 사이트 구성 리포지토리로 변경 사항을 내보냅니다.

   GitOps ZTP 파이프라인은 site Config 필터 명령에 따라 적용되는 CR을 모니터링하고 조정합니다.

3. 선택 사항: GitOps ZTP 파이프라인이 클러스터 설치 중에 모든 /source-crs/extra-manifest CR을 적용하지 않도록 하려면 site Config CR에서 다음 YAML을 적용합니다.

   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         inclusionDefault: exclude

4. 선택 사항: /source-crs/extra-manifest RAN CR을 모두 제외하고 설치 중에 사용자 지정 CR 파일을 포함하려면 사용자 정의 SiteConfig CR을 편집하여 사용자 정의 매니페스트 폴더 및 포함 파일을 설정합니다. 예를 들면 다음과 같습니다.

   clusters:
   - clusterName: "site1-sno-du"
     extraManifestPath: "<custom_manifest_folder>" 1
     extraManifests:
       filter:
         inclusionDefault: exclude  2
         include:
           - custom-sctp-machine-config-worker.yaml

   1

   < custom_manifest_folder >를 사용자 정의 설치 CR이 포함된 폴더의 이름으로 바꿉니다(예: user-custom-manifest/ ).

   2

   GitOps ZTP 파이프라인이 설치 중에 /source-crs/extra-manifest 에 파일을 적용하지 못하도록 inclusionDefault 를 exclude 로 설정합니다.

   다음 예제에서는 사용자 지정 폴더 구조를 보여줍니다.

   siteconfig
     ├── site1-sno-du.yaml
     └── user-custom-manifest
           └── custom-sctp-machine-config-worker.yaml

프로세스

1. bmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true 주석을 포함하도록 SiteConfig CR을 업데이트합니다.

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     Clusters:
       nodes:
       - hostname: node6
         role: "worker"
         crAnnotations:
           add:
             BareMetalHost:
               bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
   # ...

2. crSuppression.BareMetalHost 주석을 포함하도록 SiteConfig CR을 업데이트하여 BareMetalHost CR 생성을 비활성화합니다.

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     clusters:
     - nodes:
       - hostName: node6
         role: "worker"
         crSuppression:
         - BareMetalHost
   # ...

3. 변경 사항을 Git 리포지토리로 푸시하고 프로비저닝 해제가 시작될 때까지 기다립니다. BareMetalHost CR의 상태는 프로비저닝 해제 로 변경되어야 합니다. BareMetalHost 가 프로비저닝 해제가 완료될 때까지 기다린 후 완전히 삭제됩니다.

검증

1. 다음 명령을 실행하여 작업자 노드의 BareMetalHost 및 Agent CR이 hub 클러스터에서 삭제되었는지 확인합니다.

   $ oc get bmh -n <cluster-ns>

   $ oc get agent -n <cluster-ns>

2. 다음 명령을 실행하여 노드 레코드가 spoke 클러스터에서 삭제되었는지 확인합니다.

   $ oc get nodes

   참고

   시크릿을 사용하여 작업하는 경우 ArgoCD에는 삭제 후 다시 동기화를 완료하기 위해 시크릿이 필요하므로 시크릿을 너무 빨리 삭제하면 문제가 발생할 수 있습니다. 현재 ArgoCD 동기화가 완료되면 노드 정리 후에만 보안을 삭제합니다.

프로세스

1. 기존 콘텐츠의 기본 소스 CR을 검토합니다. ZTP(ZTP) 컨테이너에서 해당 CR을 추출하여 참조 PolicyGenTemplate CR에 나열된 소스 CR을 검토할 수 있습니다.

   1. /out 폴더를 생성합니다.

      $ mkdir -p ./out

   2. 소스 CR을 추출합니다.

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15.1 extract /home/ztp --tar | tar x -C ./out

2. ./out/source-crs/ PerformanceProfile.yaml 의 기준 PerformanceProfile CR을 검토합니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: $name
     annotations:
       ran.openshift.io/ztp-deploy-wave: "10"
   spec:
     additionalKernelArgs:
     - "idle=poll"
     - "rcupdate.rcu_normal_after_boot=0"
     cpu:
       isolated: $isolated
       reserved: $reserved
     hugepages:
       defaultHugepagesSize: $defaultHugepagesSize
       pages:
         - size: $size
           count: $count
           node: $node
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/$mcp: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/$mcp: ''
     numa:
       topologyPolicy: "restricted"
     realTimeKernel:
       enabled: true

   참고

   $…​ 이 포함된 소스 CR의 모든 필드는 PolicyGenTemplate CR에 제공되지 않는 경우 생성된 CR에서 제거됩니다.

3. group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfile 의 PolicyGenTemplate 항목을 업데이트합니다. 다음 예제 PolicyGenTemplate CR 스탠자는 적절한 CPU 사양을 제공하고 hugepages 구성을 설정하며 globallyDisableIrqLoadBalancing 을 false로 설정하는 새 필드를 추가합니다.

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       name: openshift-node-performance-profile
     spec:
       cpu:
         # These must be tailored for the specific hardware platform
         isolated: "2-19,22-39"
         reserved: "0-1,20-21"
       hugepages:
         defaultHugepagesSize: 1G
         pages:
           - size: 1G
             count: 10
       globallyDisableIrqLoadBalancing: false

4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

프로세스

1. PolicyGenTemplate CR(사용자 정의 리소스)에 대한 kustomization.yaml 파일이 포함된 디렉터리에 source-crs 라는 하위 디렉터리를 생성합니다.

2. 다음 예와 같이 사용자 제공 CR을 source-crs 하위 디렉터리에 추가합니다.

   example
   └── policygentemplates
       ├── dev.yaml
       ├── kustomization.yaml
       ├── mec-edge-sno1.yaml
       ├── sno.yaml
       └── source-crs 1
           ├── PaoCatalogSource.yaml
           ├── PaoSubscription.yaml
           ├── custom-crs
           |   ├── apiserver-config.yaml
           |   └── disable-nic-lldp.yaml
           └── elasticsearch
               ├── ElasticsearchNS.yaml
               └── ElasticsearchOperatorGroup.yaml

   1

   source-crs 하위 디렉터리는 kustomization.yaml 파일과 동일한 디렉터리에 있어야 합니다.

3. source-crs/custom-crs 및 source-crs/elasticsearch 디렉터리에 추가한 콘텐츠에 대한 참조를 포함하도록 필요한 PolicyGenTemplate CR을 업데이트합니다. 예를 들면 다음과 같습니다.

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-dev"
     namespace: "ztp-clusters"
   spec:
     bindingRules:
       dev: "true"
     mcp: "master"
     sourceFiles:
       # These policies/CRs come from the internal container Image
       #Cluster Logging
       - fileName: ClusterLogNS.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-ns"
       - fileName: ClusterLogOperGroup.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-operator-group"
       - fileName: ClusterLogSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-sub"
       #Local Storage Operator
       - fileName: StorageNS.yaml
         remediationAction: inform
         policyName: "group-dev-lso-ns"
       - fileName: StorageOperGroup.yaml
         remediationAction: inform
         policyName: "group-dev-lso-operator-group"
       - fileName: StorageSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-lso-sub"
       #These are custom local polices that come from the source-crs directory in the git repo
       # Performance Addon Operator
       - fileName: PaoSubscriptionNS.yaml
         remediationAction: inform
         policyName: "group-dev-pao-ns"
       - fileName: PaoSubscriptionCatalogSource.yaml
         remediationAction: inform
         policyName: "group-dev-pao-cat-source"
         spec:
           image: <image_URL_here>
       - fileName: PaoSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-pao-sub"
       #Elasticsearch Operator
       - fileName: elasticsearch/ElasticsearchNS.yaml 1
         remediationAction: inform
         policyName: "group-dev-elasticsearch-ns"
       - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml
         remediationAction: inform
         policyName: "group-dev-elasticsearch-operator-group"
       #Custom Resources
       - fileName: custom-crs/apiserver-config.yaml 2
         remediationAction: inform
         policyName: "group-dev-apiserver-config"
       - fileName: custom-crs/disable-nic-lldp.yaml
         remediationAction: inform
         policyName: "group-dev-disable-nic-lldp"

   1 2

   /source-crs 상위 디렉터리에서 파일의 상대 경로를 포함하도록 fileName 을 설정합니다.

4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 정책 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

5. 변경된 PolicyGenTemplate 을 포함하도록 ClusterGroupUpgrade CR을 업데이트하고 cgu-test.yaml 로 저장합니다. 다음 예제는 생성된 cgu-test.yaml 파일을 보여줍니다.

   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: custom-source-cr
     namespace: ztp-clusters
   spec:
     managedPolicies:
       - group-dev-config-policy
     enable: true
     clusters:
     - cluster1
     remediationStrategy:
       maxConcurrency: 2
       timeout: 240

6. 다음 명령을 실행하여 업데이트된 ClusterGroupUpgrade CR을 적용합니다.

   $ oc apply -f cgu-test.yaml

프로세스

1. PolicyGenTemplate CR의 모든 정책에 대한 평가 간격을 구성하려면 spec 필드에 evaluationInterval 를 추가한 다음 적절한 준수 및 비준수 값을 설정합니다. 예를 들면 다음과 같습니다.

   spec:
     evaluationInterval:
       compliant: 30m
       noncompliant: 20s

2. PolicyGenTemplate CR에서 spec.sourceFiles 오브젝트의 평가 간격을 구성하려면 sourceFiles 필드에 evaluationInterval 을 추가합니다. 예를 들면 다음과 같습니다.

   spec:
     sourceFiles:
      - fileName: SriovSubscription.yaml
        policyName: "sriov-sub-policy"
        evaluationInterval:
          compliant: never
          noncompliant: 10s

3. Git 리포지토리에서 PolicyGenTemplate CR 파일을 커밋하고 변경 사항을 내보냅니다.

1. 관리 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.

2. open-cluster-management-agent-addon 네임스페이스에서 실행 중인 Pod를 가져옵니다. 다음 명령을 실행합니다.

   $ oc get pods -n open-cluster-management-agent-addon

   출력 예

   NAME                                         READY   STATUS    RESTARTS        AGE
   config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d

3. config-policy-controller Pod에 대한 로그에서 적용된 정책이 예상 간격으로 평가되고 있는지 확인합니다.

   $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb

   출력 예

   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-config-policy-config"}
   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-common-compute-1-catalog-policy-config"}

프로세스

1. 소스 파일 validatorCRs/informDuValidator.yaml 을 포함하는 독립 실행형 PolicyGenTemplate CR(사용자 정의 리소스)을 생성합니다. 각 클러스터 유형에 대해 하나의 독립 실행형 PolicyGenTemplate CR만 있으면 됩니다. 예를 들어 이 CR은 단일 노드 OpenShift 클러스터에 대한 검증기 정보 정책을 적용합니다.

   single-node 클러스터 검증기 정보 정책 CR의 예 (group-du-sno-validator-ranGen.yaml)

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-du-sno-validator" 1
     namespace: "ztp-group" 2
   spec:
     bindingRules:
       group-du-sno: "" 3
     bindingExcludedRules:
       ztp-done: "" 4
     mcp: "master" 5
     sourceFiles:
       - fileName: validatorCRs/informDuValidator.yaml
         remediationAction: inform 6
         policyName: "du-policy" 7

   1

   PolicyGenTemplates 오브젝트의 이름입니다. 이 이름은 요청된 네임스페이스에 생성된 placementBinding,placementRule 및 정책의 일부로 사용됩니다.

   2

   이 값은 PolicyGenTemplates 그룹에 사용된 네임스페이스 와 일치해야 합니다.

   3

   bindingRules 에 정의된 group-du-* 레이블은 site Config 파일에 있어야 합니다.

   4

   bindingExcludedRules 에 정의된 레이블은'ztp-done:'이어야 합니다. ztp-done 레이블은 토폴로지 Aware Lifecycle Manager와의 조정에 사용됩니다.

   5

   MCP 는 소스 파일 validatorCRs/informDuValidator.yaml 에 사용되는 MachineConfigPool 오브젝트를 정의합니다. 단일 노드와 3-노드 클러스터 배포의 경우 마스터 이고 표준 클러스터 배포의 경우 worker 여야 합니다.

   6

   선택 사항: 기본값은 inform 입니다.

   7

   이 값은 생성된 RHACM 정책의 이름으로 사용됩니다. 단일 노드 예에 대해 생성된 검증 검증 정책은 group-du-sno-validator-du-policy 입니다.

2. Git 리포지토리에서 PolicyGenTemplate CR 파일을 커밋하고 변경 사항을 내보냅니다.

프로세스

1. 새 관리 클러스터에 대해 LVM 스토리지를 구성하려면 common-ranGen.yaml 파일의 spec.sourceFiles 에 다음 YAML을 추가합니다.

   - fileName: StorageLVMOSubscriptionNS.yaml
     policyName: subscription-policies
   - fileName: StorageLVMOSubscriptionOperGroup.yaml
     policyName: subscription-policies
   - fileName: StorageLVMOSubscription.yaml
     spec:
       name: lvms-operator
       channel: stable-4.15
     policyName: subscription-policies

   참고

   스토리지 LVMO 서브스크립션은 더 이상 사용되지 않습니다. 향후 OpenShift Container Platform 릴리스에서는 스토리지 LVMO 서브스크립션을 사용할 수 없습니다. 대신 Storage LVMS 서브스크립션을 사용해야 합니다.

   OpenShift Container Platform 4.15에서는 LVMO 서브스크립션 대신 스토리지 LVMS 서브스크립션을 사용할 수 있습니다. LVMS 서브스크립션에는 common-ranGen.yaml 파일의 수동 덮어쓰기가 필요하지 않습니다. 스토리지 LVMS 서브스크립션을 사용하려면 common-ranGen.yaml 파일의 spec.sourceFiles 에 다음 YAML을 추가합니다.

   - fileName: StorageLVMSubscriptionNS.yaml
     policyName: subscription-policies
   - fileName: StorageLVMSubscriptionOperGroup.yaml
     policyName: subscription-policies
   - fileName: StorageLVMSubscription.yaml
     policyName: subscription-policies

2. 특정 그룹 또는 개별 사이트 구성 파일의 spec.sourceFiles 에 LVMCluster CR을 추가합니다. 예를 들어 group-du-sno-ranGen.yaml 파일에서 다음을 추가합니다.

   - fileName: StorageLVMCluster.yaml
     policyName: "lvms-config" 1
     spec:
       storage:
         deviceClasses:
         - name: vg1
           thinPoolConfig:
             name: thin-pool-1
             sizePercent: 90
             overprovisionRatio: 10

   1

   이 예제 구성은 OpenShift Container Platform이 설치된 디스크를 제외하고 사용 가능한 모든 장치가 포함된 볼륨 그룹( Cryostat1)을 생성합니다. thin-pool 논리 볼륨도 생성됩니다.

3. 기타 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 사이트 구성 리포지토리로 변경 사항을 내보내 GitOps ZTP를 사용하여 새 사이트에 LVM 스토리지를 배포합니다.

프로세스

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub로 이동합니다.
2. 사용 가능한 Operator 목록에서 토폴로지 Aware Lifecycle Manager 를 검색한 다음 설치를 클릭합니다.
3. 기본 설치 모드 ["기본"] 및 설치된 네임스페이스("openshift-operators")를 계속 선택하여 Operator가 올바르게 설치되었는지 확인합니다.
4. 설치를 클릭합니다.

1. Operator → 설치된 Operator 페이지로 이동합니다.
2. Operator가 모든 네임스페이스 네임스페이스에 설치되어 있고 해당 상태가 Succeeded 인지 확인합니다.

1. Operator → 설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
2. 워크로드 → Pod 페이지로 이동하여 문제를 보고하는 cluster-group-upgrades-controller-manager Pod에서 컨테이너의 로그를 확인합니다.

프로세스

1. 서브스크립션 CR을 생성합니다.

   1. Subscription CR을 정의하고 YAML 파일을 저장합니다(예: talm-subscription.yaml ):

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-topology-aware-lifecycle-manager-subscription
        namespace: openshift-operators
      spec:
        channel: "stable"
        name: topology-aware-lifecycle-manager
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다.

      $ oc create -f talm-subscription.yaml

검증

1. CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.

   $ oc get csv -n openshift-operators

   출력 예

   NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
   topology-aware-lifecycle-manager.4.15.x   Topology Aware Lifecycle Manager   4.15.x                                      Succeeded

2. TALM이 실행 중인지 확인합니다.

   $ oc get deploy -n openshift-operators

   출력 예

   NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
   openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s