17.5. ZTP로 단일 노드 OpenShift 클러스터 수동 설치

절차

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

   $ mkdir -p ./out

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

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 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을 수정하여 설치하려는 사이트 및 베어 메탈 호스트의 세부 정보와 일치하도록 수정합니다.

   단일 노드 OpenShift 클러스터 siteConfig CR의 예

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "<site_name>"
     namespace: "<site_name>"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret" 1
     clusterImageSetNameRef: "openshift-4.12" 2
     sshPublicKey: "ssh-rsa AAAA..." 3
     clusters:
     - clusterName: "<site_name>"
       networkType: "OVNKubernetes"
       clusterLabels: 4
         common: true
         group-du-sno: ""
         sites : "<site_name>"
       clusterNetwork:
         - cidr: 1001:1::/48
           hostPrefix: 64
       machineNetwork:
         - cidr: 1111:2222:3333:4444::/64
       serviceNetwork:
         - 1001:2::/112
       additionalNTPSources:
         - 1111:2222:3333:4444::2
       #crTemplates:
       #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
       nodes:
         - hostName: "example-node.example.com" 6
           role: "master"
           bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 7
           bmcCredentialsName:
             name: "bmh-secret" 8
           bootMACAddress: "AA:BB:CC:DD:EE:11"
           bootMode: "UEFI" 9
           rootDeviceHints:
             wwn: "0x11111000000asd123"
           cpuset: "0-1,52-53"  10
           nodeNetwork: 11
             interfaces:
               - name: eno1
                 macAddress: "AA:BB:CC:DD:EE:11"
             config:
               interfaces:
                 - name: eno1
                   type: ethernet
                   state: up
                   ipv4:
                     enabled: false
                   ipv6: 12
                     enabled: true
                     address:
                     - ip: 1111:2222:3333:4444::aaaa:1
                       prefix-length: 64
               dns-resolver:
                 config:
                   search:
                   - example.com
                   server:
                   - 1111:2222:3333:4444::2
               routes:
                 config:
                 - destination: ::/0
                   next-hop-interface: eno1
                   next-hop-address: 1111:2222:3333:4444::1
                   table-id: 254

   1

   site Config CR과 동일한 네임스페이스를 사용하여 assisted-deployment-pull-secret CR 을 생성합니다.

   2

   clusterImageSetNameRef 는 hub 클러스터에서 사용 가능한 이미지 세트를 정의합니다. hub 클러스터에서 지원되는 버전 목록을 보려면 oc get clusterimagesets 를 실행합니다.

   3

   클러스터에 액세스하는 데 사용되는 SSH 공개 키를 구성합니다.

   4

   클러스터 레이블은 사용자가 정의한 PolicyGenTemplate CR의 bindingRules 필드에 대응해야 합니다. 예를 들어 policygentemplates/common-ranGen.yaml 은 common: true set, policygentemplates/group-du-sno-ranGen.yaml 이 group-du-sno: "" 가 설정된 모든 클러스터에 적용됩니다.

   5

   선택 사항: KlusterletAddonConfig 아래에 있는 CR 사양을 사용하여 클러스터에 대해 생성된 기본 KlusterletAddonConfig 를 덮어씁니다.

   6

   단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 3개의 호스트를 정의합니다. 표준 배포의 경우 master와 role 으로 정의된 두 개 이상의 호스트인 worker 를 사용하여 3개의 호스트를 정의합니다.

   7

   호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다.

   8

   호스트 BMC 자격 증명을 사용하여 별도로 생성하는 bmh-secret CR의 이름입니다. bmh-secret CR을 생성할 때 호스트를 프로비저닝하는 site Config CR 과 동일한 네임스페이스를 사용합니다.

   9

   호스트의 부팅 모드를 구성합니다. 기본값은 UEFI 입니다. UEFISecureBoot 를 사용하여 호스트에서 보안 부팅을 활성화합니다.

   10

   cpuset 는 워크로드 파티셔닝을 위해 클러스터 PerformanceProfile CR spec.cpu.reserved 필드에 설정된 값과 일치해야 합니다.

   11

   노드의 네트워크 설정을 지정합니다.

   12

   호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다.

5. 다음 명령을 실행하여 수정된 site Config CR site-1-sno.yaml 을 처리하여 day-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.12.1 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 옵션을 사용하여 참조 site Config 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.12.1 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. 이전 단계의 참조를 사용하여 Day-2 구성 CR 을 생성하고 내보냅니다. 다음 명령을 실행합니다.

   1. 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.12.1 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(Host Baseboard Management Controller) 및 풀 시크릿(pull secret)의 인증 정보가 포함된 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

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

      2

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

      3

      관련 site Config 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.12.yaml ). ClusterImageSet 의 형식은 다음과 같습니다.

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

   1

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

   2

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

2. clusterImageSet CR을 적용합니다.

   $ oc apply -f clusterImageSet-4.12.yaml

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

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

   1 2

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

4. 다음 명령을 실행하여 Namespace 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 명령을 사용하여 에이전트 상태에 대한 심층적인 설명을 제공합니다. Statuss to be aware of include BackendError,InputError,ValidationsFailing,InstallationFailed, and AgentIsConnected. 이러한 상태는 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 열의 상태가 알 수 없는 경우 관리 클러스터는 허브에서 관리하지 않습니다. 더 많은 정보를 얻으려면 다음 단계를 따르십시오.

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. 관리 클러스터의 사용자 정의 리소스를 다시 생성합니다.