에이전트 기반 설치 관리자를 사용하여 온프레미스 클러스터 설치

1. 기본 방법: install-config.yaml 및 agent-config.yaml

   agent-config.yaml.file 샘플

   cat > agent-config.yaml << EOF
   apiVersion: v1alpha1
   kind: AgentConfig
   metadata:
     name: sno-cluster
   rendezvousIP: 192.168.111.80 1
   hosts:
     - hostname: master-0
       interfaces:
         - name: eno1
           macAddress: 00:ef:44:21:e6:a5 2
       networkConfig:
         interfaces:
           - name: eno1
             type: ethernet
             state: up
             mac-address: 00:ef:44:21:e6:a5
             ipv4:
               enabled: true
               address:
                 - ip: 192.168.111.80 3
                   prefix-length: 23 4
               dhcp: false
         dns-resolver:
           config:
             server:
               - 192.168.111.1 5
         routes:
           config:
             - destination: 0.0.0.0/0
               next-hop-address: 192.168.111.1 6
               next-hop-interface: eno1
               table-id: 254
   EOF

   1

   rendezvousIP 필드에 값을 지정하지 않으면 networkConfig 필드에 지정된 고정 IP 주소에서 하나의 주소가 선택됩니다.

   2

   호스트에 있는 인터페이스의 MAC 주소로, 구성을 적용할 호스트를 결정하는 데 사용됩니다.

   3

   대상 베어 메탈 호스트의 고정 IP 주소입니다.

   4

   대상 베어 메탈 호스트의 고정 IP 주소의 서브넷 접두사입니다.

   5

   대상 베어 메탈 호스트의 DNS 서버입니다.

   6

   노드 트래픽의 다음 홉 주소입니다. 지정된 인터페이스에 설정된 IP 주소와 동일한 서브넷에 있어야 합니다.

2. 선택적 방법: GitOps ZTP 매니페스트

   GitOps ZTP 사용자 정의 리소스의 선택적 방법은 6개의 사용자 지정 리소스로 구성됩니다. nmstateconfig.yaml 파일에서 고정 IP를 구성할 수 있습니다.

   apiVersion: agent-install.openshift.io/v1beta1
   kind: NMStateConfig
   metadata:
     name: master-0
     namespace: openshift-machine-api
     labels:
       cluster0-nmstate-label-name: cluster0-nmstate-label-value
   spec:
     config:
       interfaces:
         - name: eth0
           type: ethernet
           state: up
           mac-address: 52:54:01:aa:aa:a1
           ipv4:
             enabled: true
             address:
               - ip: 192.168.122.2 1
                 prefix-length: 23 2
             dhcp: false
       dns-resolver:
         config:
           server:
             - 192.168.122.1 3
       routes:
         config:
           - destination: 0.0.0.0/0
             next-hop-address: 192.168.122.1 4
             next-hop-interface: eth0
             table-id: 254
     interfaces:
       - name: eth0
         macAddress: 52:54:01:aa:aa:a1 5

   1

   대상 베어 메탈 호스트의 고정 IP 주소입니다.

   2

   대상 베어 메탈 호스트의 고정 IP 주소의 서브넷 접두사입니다.

   3

   대상 베어 메탈 호스트의 DNS 서버입니다.

   4

   노드 트래픽의 다음 홉 주소입니다. 지정된 인터페이스에 설정된 IP 주소와 동일한 서브넷에 있어야 합니다.

   5

   호스트에 있는 인터페이스의 MAC 주소로, 구성을 적용할 호스트를 결정하는 데 사용됩니다.

1. API 로드 밸런서: 플랫폼과 상호 작용하고 플랫폼을 구성할 수 있도록 사용자(인간과 시스템 모두)에게 공통 끝점을 제공합니다. 다음 조건을 설정합니다.

   • Layer 4 로드 밸런싱 전용입니다. 이를 Raw TCP, SSL Passthrough 또는 SSL Bridge 모드라고 합니다. SSL Bridge 모드를 사용하는 경우, API 경로에 대해 SNI(Server Name Indication, 서버 이름 표시)를 활성화해야 합니다.
   • 스테이트리스 로드 밸런싱 알고리즘입니다. 옵션은 로드 밸런서 구현에 따라 달라집니다.
   중요

   API 로드 밸런서에 대한 세션 지속성을 구성하지 마십시오.

   로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.

   표 1.5. API 로드 밸런서

   포트	백엔드 시스템(풀 멤버)	내부	외부	설명
   6443	컨트롤 플레인. API 서버 상태 검사 프로브에 대한 /readyz 끝점을 구성해야 합니다.	X	X	Kubernetes API 서버
   22623	컨트롤 플레인.	X		시스템 구성 서버

   참고

   API 서버가 /readyz 엔드포인트를 해제하는 시점부터 풀에서 API 서버 인스턴스가 제거되는 시점까지 시간이 30초를 넘지 않도록 로드 밸런서를 구성해야 합니다. /readyz가 오류를 반환하거나 정상 상태가 된 후 정해진 시간 안에 끝점이 제거 또는 추가되어야 합니다. 5초 또는 10초의 프로빙 주기(두 번의 성공적인 요청은 정상 상태, 세 번의 요청은 비정상 상태)는 충분한 테스트를 거친 값입니다.

2. 애플리케이션 인그레스 로드 밸런서: 클러스터 외부에서 유입되는 애플리케이션 트래픽에 대한 수신 지점을 제공합니다. 인그레스 라우터에 대한 작업 구성이 OpenShift Container Platform 클러스터에 필요합니다.

   다음 조건을 설정합니다.

   • Layer 4 로드 밸런싱 전용입니다. 이를 Raw TCP, SSL Passthrough 또는 SSL Bridge 모드라고 합니다. SSL Bridge 모드를 사용하는 경우 인그레스 경로에 대해 SNI(Server Name Indication, 서버 이름 표시)를 활성화해야 합니다.
   • 사용 가능한 옵션과 플랫폼에서 호스팅되는 애플리케이션 유형에 따라 연결 기반 또는 세션 기반 지속성이 권장됩니다.
   작은 정보

   애플리케이션 Ingress 로드 밸런서에서 클라이언트의 실제 IP 주소를 확인할 수 있는 경우 소스 IP 기반 세션 지속성을 활성화하면 엔드 투 엔드 TLS 암호화를 사용하는 애플리케이션의 성능을 향상시킬 수 있습니다.

   로드 밸런서의 전면과 후면 모두에서 다음 포트를 구성하십시오.

   표 1.6. 애플리케이션 인그레스 로드 밸런서

   포트	백엔드 시스템(풀 멤버)	내부	외부	설명
   443	기본적으로 인그레스 컨트롤러 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.	X	X	HTTPS 트래픽
   80	기본적으로 인그레스 컨트롤러 pod, 컴퓨팅 또는 작업자를 실행하는 시스템입니다.	X	X	HTTP 트래픽

   참고

   컴퓨팅 노드가 0인 3-노드 클러스터를 배포하는 경우 Ingress 컨트롤러 Pod는 컨트롤 플레인 노드에서 실행됩니다. 3-노드 클러스터 배포에서 HTTP 및 HTTPS 트래픽을 컨트롤 플레인 노드로 라우팅하도록 애플리케이션 인그레스 로드 밸런서를 구성해야 합니다.

프로세스

1. oc-mirror 플러그인을 사용하여 릴리스 이미지를 미러링한 경우 다음을 수행합니다.

   1. 결과 디렉터리에 있는 imageContentSourcePolicy.yaml 을 엽니다(예: oc-mirror-workspace/results-1682697932/ ).
   2. yaml 파일의 repositoryDigestMirrors 섹션에 텍스트를 복사합니다.

2. oc adm release mirror 명령을 사용하여 릴리스 이미지를 미러링한 경우 다음을 수행합니다.

   • 명령 출력의 imageContentSources 섹션에 텍스트를 복사합니다.
3. 복사된 텍스트를 install-config.yaml 파일의 imageContentSources 필드에 붙여넣습니다.

4. 미러 레지스트리에 사용된 인증서 파일을 yaml 파일의 additionalTrustBundle 필드에 추가합니다.

   중요

   값은 미러 레지스트리에 사용한 인증서 파일의 내용이어야 합니다. 인증서 파일은 신뢰할 수 있는 기존 인증 기관 또는 미러 레지스트리에 대해 생성한 자체 서명 인증서일 수 있습니다.

   install-config.yaml 파일 예

     additionalTrustBundle: |
       -----BEGIN CERTIFICATE-----
       ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
       -----END CERTIFICATE-----

5. GitOps ZTP 매니페스트를 사용하는 경우: registries.conf 및 ca-bundle.crt 파일을 미러 경로에 추가하여 에이전트 ISO 이미지에 미러 구성을 추가합니다.

   참고

   oc adm release mirror 명령 또는 oc mirror 플러그인의 출력에서 registries.conf 파일을 생성할 수 있습니다. /etc/containers/registries.conf 파일의 형식이 변경되었습니다. 현재 버전은 TOML 형식의 버전 2입니다.

   registries.conf 파일 예

   [[registry]]
   location = "registry.ci.openshift.org/ocp/release" mirror-by-digest-only = true
   
   [[registry.mirror]] location = "virthost.ostest.test.metalkube.org:5000/localimages/local-release-image"
   
   [[registry]]
   location = "quay.io/openshift-release-dev/ocp-v4.0-art-dev" mirror-by-digest-only = true
   
   [[registry.mirror]] location = "virthost.ostest.test.metalkube.org:5000/localimages/local-release-image"

프로세스

1. 로그인 인증 정보를 사용하여 OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Datacenter 로 이동합니다.
3. 로컬 에서 에이전트 기반 설치 관리자 실행을 클릭합니다.
4. OpenShift 설치 프로그램 및 명령줄 인터페이스 의 운영 체제 및 아키텍처를 선택합니다.
5. 설치 프로그램 다운로드를 클릭하여 설치 프로그램을 다운로드하고 추출합니다.
6. 풀 시크릿 다운로드를 클릭하거나 풀 시크릿 복사를 클릭하여 풀 시크릿을 다운로드하거나 복사합니다.
7. 명령행 툴 다운로드를 클릭하고 openshift-install 바이너리를 PATH 에 있는 디렉터리에 배치합니다.

프로세스

1. openshift-install 바이너리를 PATH에 있는 디렉터리에 배치합니다.

2. 다음 명령을 실행하여 설치 구성을 저장할 디렉터리를 생성합니다.

   $ mkdir ~/<directory_name>

3. 다음 명령을 실행하여 install-config.yaml 파일을 생성합니다.

   $ cat << EOF > ./my-cluster/install-config.yaml
   apiVersion: v1
   baseDomain: test.example.com
   compute:
   - architecture: amd64 1
     hyperthreading: Enabled
     name: worker
     replicas: 0
   controlPlane:
     architecture: amd64
     hyperthreading: Enabled
     name: master
     replicas: 1
   metadata:
     name: sno-cluster 2
   networking:
     clusterNetwork:
     - cidr: fd01::/48
       hostPrefix: 64
     machineNetwork:
     - cidr: fd2e:6f44:5dd8:c956::/120
     networkType: OVNKubernetes 3
     serviceNetwork:
     - fd02::/112
   platform: 4
     none: {}
   pullSecret: '<pull_secret>' 5
   sshKey: '<ssh_pub_key>' 6
   additionalTrustBundle: | 7
     -----BEGIN CERTIFICATE-----
     ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
     -----END CERTIFICATE-----
   imageContentSources: 8
   - mirrors:
     - <local_registry>/<local_repository_name>/release
     source: quay.io/openshift-release-dev/ocp-release
   - mirrors:
     - <local_registry>/<local_repository_name>/release
     source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
   EOF

   1

   시스템 아키텍처를 지정합니다. 유효한 값은 amd64,arm64,ppc64le, s390x 입니다.

   다중 페이로드와 함께 릴리스 이미지를 사용하는 경우 arm64,amd64,s390x 및 ppc64le 과 같은 다양한 아키텍처에 클러스터를 설치할 수 있습니다. 그러지 않으면 openshift-install version 명령의 출력에 표시된 릴리스 아키텍처에 만 클러스터를 설치할 수 있습니다. 자세한 내용은 " 에이전트 기반 설치 관리자 클러스터 설치를 위해 지원되는 아키텍처 확인"을 참조하십시오.

   2

   필수 항목입니다. 클러스터 이름을 지정합니다.

   3

   설치할 클러스터 네트워크 플러그인입니다. 기본 값 OVNKubernetes 는 지원되는 유일한 값입니다.

   4

   플랫폼을 지정합니다.

   참고

   베어 메탈 플랫폼의 경우 agent-config.yaml 파일에서 만든 구성으로 재정의하지 않는 한 install-config.yaml 파일의 platform 섹션에서 만든 호스트 설정이 기본적으로 사용됩니다.

   5

   풀 시크릿을 지정합니다.

   6

   SSH 공개 키를 지정합니다.

   7

   미러 레지스트리에 사용한 인증서 파일의 내용을 제공하십시오. 인증서 파일은 신뢰할 수 있는 기존 인증 기관 또는 미러 레지스트리에 대해 생성한 자체 서명 인증서일 수 있습니다. 연결이 끊긴 미러 레지스트리를 사용하는 경우 이 매개변수를 지정해야 합니다.

   8

   리포지토리를 미러링하는 데 사용한 명령의 출력에 따라 imageContentSources 섹션을 제공합니다. 연결이 끊긴 미러 레지스트리를 사용하는 경우 이 매개변수를 지정해야 합니다.

   중요

   • oc adm release mirror 명령을 사용하는 경우 imageContentSources 섹션의 출력을 사용합니다.
   • oc mirror 명령을 사용하는 경우 명령을 실행한 결과 ImageContentSourcePolicy 파일의 repositoryDigestMirrors 섹션을 사용합니다.
   • ImageContentSourcePolicy 리소스는 더 이상 사용되지 않습니다.

4. 다음 명령을 실행하여 agent-config.yaml 파일을 생성합니다.

   $ cat > agent-config.yaml << EOF
   apiVersion: v1beta1
   kind: AgentConfig
   metadata:
     name: sno-cluster
   rendezvousIP: fd2e:6f44:5dd8:c956::50 1
   EOF

   1

   이 IP 주소는 부트스트랩 프로세스를 수행하고 assisted-service 구성 요소를 실행하는 노드를 결정하는 데 사용됩니다. networkConfig 매개변수에 하나 이상의 호스트 IP 주소를 지정하지 않는 경우 rendezvous IP 주소를 제공해야 합니다. 이 주소를 제공하지 않으면 제공된 호스트 networkConfig 매개변수에서 하나의 IP 주소가 선택됩니다.

프로세스

1. 다음 명령을 실행하여 에이전트 이미지를 생성합니다.

   $ openshift-install --dir <install_directory> agent create image

   참고

   RHCOS(Red Hat Enterprise Linux CoreOS)는 기본 디스크에서 다중 경로를 지원하므로 하드웨어 장애에 대한 탄력성이 강화된 호스트 가용성을 높일 수 있습니다. 기본 /etc/multipath.conf 구성이 있는 에이전트 ISO 이미지에서 멀티패스는 기본적으로 활성화됩니다.

2. 베어 메탈 시스템에서 agent.x86_64.iso 또는 agent.aarch64.iso 이미지를 부팅합니다.

프로세스

1. 에이전트 콘솔 애플리케이션이 레지스트리에서 구성된 릴리스 이미지를 가져올 수 있는지 여부를 확인할 때까지 기다립니다.

2. 에이전트 콘솔 애플리케이션에서 설치 프로그램 연결 확인이 전달되었다고 표시되면 프롬프트가 설치를 계속할 때까지 기다립니다.

   참고

   연결 검사에서 통과한 경우에도 네트워크 구성 설정을 보거나 변경하도록 선택할 수 있습니다.

   그러나 시간 초과를 두는 대신 에이전트 콘솔 애플리케이션과 상호 작용하도록 선택하는 경우 TUI를 수동으로 종료하여 설치를 진행해야 합니다.

3. 에이전트 콘솔 애플리케이션 검사에 실패한 경우 릴리스 이미지 URL 가져오기 확인 옆에 빨간색 아이콘으로 표시되는 다음 단계를 사용하여 호스트의 네트워크 설정을 재구성합니다.

   1. TUI의 Check Errors 섹션을 읽으십시오. 이 섹션에는 실패한 검사와 관련된 오류 메시지가 표시됩니다.

      
   2. Configure network 를 선택하여 NetworkManager TUI를 시작합니다.
   3. 연결 편집을 선택하고 재구성할 연결을 선택합니다.
   4. 구성을 편집하고 OK 를 선택하여 변경 사항을 저장합니다.
   5. Back 을 선택하여 NetworkManager TUI의 기본 화면으로 돌아갑니다.
   6. 연결 활성화를 선택합니다.
   7. 재구성된 네트워크를 선택하여 비활성화합니다.
   8. 재구성된 네트워크를 다시 선택하여 다시 활성화합니다.
   9. Back 을 선택한 다음 Quit 를 선택하여 에이전트 콘솔 애플리케이션으로 돌아갑니다.
   10. 새 네트워크 구성을 사용하여 연속 네트워크 검사를 다시 시작할 때까지 5초 이상 기다립니다.
   11. 릴리스 이미지 URL 가져오기 검사가 성공하고 URL 옆에 녹색 아이콘이 표시되면 Quit 를 선택하여 에이전트 콘솔 애플리케이션을 종료하고 설치를 계속합니다.

프로세스

1. 선택 사항: 부트스트랩 호스트(신규 호스트)가 재부팅되는 시기를 확인하려면 다음 명령을 실행합니다.

   $ ./openshift-install --dir <install_directory> agent wait-for bootstrap-complete \1
       --log-level=info 2

   1

   & lt;install_directory > 의 경우 에이전트 ISO가 생성된 디렉터리의 경로를 지정합니다.

   2

   다른 설치 세부 사항을 보려면 info 대신 warn, debug 또는 error를 지정합니다.

   출력 예

   ...................................................................
   ...................................................................
   INFO Bootstrap configMap status is complete
   INFO cluster bootstrap is complete

   이 명령은 Kubernetes API 서버가 컨트롤 플레인 시스템에서 부트스트랩되었다는 신호를 보낼 때 성공합니다.

2. 진행 상황을 추적하고 성공적으로 설치를 확인하려면 다음 명령을 실행합니다.

   $ openshift-install --dir <install_directory> agent wait-for install-complete 1

   1

   & lt;install_directory > 디렉터리에 대해 에이전트 ISO가 생성된 디렉터리의 경로를 지정합니다.

   출력 예

   ...................................................................
   ...................................................................
   INFO Cluster is installed
   INFO Install complete!
   INFO To access the cluster as the system:admin user when using 'oc', run
   INFO     export KUBECONFIG=/home/core/installer/auth/kubeconfig
   INFO Access the OpenShift web-console here: https://console-openshift-console.apps.sno-cluster.test.example.com

프로세스

1. 로그인 인증 정보를 사용하여 OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Datacenter 로 이동합니다.
3. 로컬 에서 에이전트 기반 설치 관리자 실행을 클릭합니다.
4. OpenShift 설치 프로그램 및 명령줄 인터페이스 의 운영 체제 및 아키텍처를 선택합니다.
5. 설치 프로그램 다운로드를 클릭하여 설치 프로그램을 다운로드하고 추출합니다.
6. 풀 시크릿 다운로드를 클릭하거나 풀 시크릿 복사를 클릭하여 풀 시크릿을 다운로드하거나 복사합니다.
7. 명령행 툴 다운로드를 클릭하고 openshift-install 바이너리를 PATH 에 있는 디렉터리에 배치합니다.

프로세스

1. 다음 명령을 실행하여 nmstate 종속성을 설치합니다.

   $ sudo dnf install /usr/bin/nmstatectl -y

2. openshift-install 바이너리를 PATH에 있는 디렉터리에 배치합니다.

3. 다음 명령을 실행하여 설치 구성을 저장할 디렉터리를 생성합니다.

   $ mkdir ~/<directory_name>

   참고

   에이전트 기반 설치에 권장되는 방법입니다. GitOps ZTP 매니페스트 사용은 선택 사항입니다.

4. 다음 명령을 실행하여 install-config.yaml 파일을 생성합니다.

   $ cat << EOF > ./<directory_name>/install-config.yaml
   apiVersion: v1
   baseDomain: test.example.com
   compute:
   - architecture: amd64 1
     hyperthreading: Enabled
     name: worker
     replicas: 0
   controlPlane:
     architecture: amd64
     hyperthreading: Enabled
     name: master
     replicas: 1
   metadata:
     name: sno-cluster 2
   networking:
     clusterNetwork:
     - cidr: 10.128.0.0/14
       hostPrefix: 23
     machineNetwork:
     - cidr: 192.168.0.0/16
     networkType: OVNKubernetes 3
     serviceNetwork:
     - 172.30.0.0/16
   platform: 4
     none: {}
   pullSecret: '<pull_secret>' 5
   sshKey: '<ssh_pub_key>' 6
   EOF

   1

   시스템 아키텍처를 지정하고 유효한 값은 amd64,arm64,ppc64le, s390x 입니다.

   2

   필수 항목입니다. 클러스터 이름을 지정합니다.

   3

   설치할 클러스터 네트워크 플러그인입니다. 기본 값 OVNKubernetes 는 지원되는 유일한 값입니다.

   4

   플랫폼을 지정합니다.

   참고

   베어 메탈 플랫폼의 경우 agent-config.yaml 파일에서 만든 구성으로 재정의하지 않는 한 install-config.yaml 파일의 platform 섹션에서 만든 호스트 설정이 기본적으로 사용됩니다.

   5

   풀 시크릿을 지정합니다.

   6

   SSH 공개 키를 지정합니다.

   참고

   플랫폼을 vSphere 또는 baremetal 로 설정하면 다음 세 가지 방법으로 클러스터 노드의 IP 주소 끝점을 구성할 수 있습니다.

   • IPv4
   • IPv6
   • IPv4 및 IPv6 병렬(dual-stack)

   IPv6는 베어 메탈 플랫폼에서만 지원됩니다.

   듀얼 스택 네트워킹의 예

   networking:
     clusterNetwork:
       - cidr: 172.21.0.0/16
         hostPrefix: 23
       - cidr: fd02::/48
         hostPrefix: 64
     machineNetwork:
       - cidr: 192.168.11.0/16
       - cidr: 2001:DB8::/32
     serviceNetwork:
       - 172.22.0.0/16
       - fd03::/112
     networkType: OVNKubernetes
   platform:
     baremetal:
       apiVIPs:
       - 192.168.11.3
       - 2001:DB8::4
       ingressVIPs:
       - 192.168.11.4
       - 2001:DB8::5

   참고

   연결이 끊긴 미러 레지스트리를 사용하는 경우 미러 레지스트리에 대해 이전에 생성한 인증서 파일을 install-config.yaml 파일의 additionalTrustBundle 필드에 추가해야 합니다.

5. 다음 명령을 실행하여 agent-config.yaml 파일을 생성합니다.

   $ cat > agent-config.yaml << EOF
   apiVersion: v1beta1
   kind: AgentConfig
   metadata:
     name: sno-cluster
   rendezvousIP: 192.168.111.80 1
   hosts: 2
     - hostname: master-0 3
       interfaces:
         - name: eno1
           macAddress: 00:ef:44:21:e6:a5
       rootDeviceHints: 4
         deviceName: /dev/sdb
       networkConfig: 5
         interfaces:
           - name: eno1
             type: ethernet
             state: up
             mac-address: 00:ef:44:21:e6:a5
             ipv4:
               enabled: true
               address:
                 - ip: 192.168.111.80
                   prefix-length: 23
               dhcp: false
         dns-resolver:
           config:
             server:
               - 192.168.111.1
         routes:
           config:
             - destination: 0.0.0.0/0
               next-hop-address: 192.168.111.2
               next-hop-interface: eno1
               table-id: 254
   EOF

   1

   이 IP 주소는 부트스트랩 프로세스를 수행하고 assisted-service 구성 요소를 실행하는 노드를 결정하는 데 사용됩니다. networkConfig 매개변수에 하나 이상의 호스트의 IP 주소를 지정하지 않는 경우 rendezvous IP 주소를 제공해야 합니다. 이 주소를 제공하지 않으면 제공된 호스트의 networkConfig 에서 하나의 IP 주소가 선택됩니다.

   2

   선택 사항: 호스트 구성. 정의된 호스트 수는 compute.replicas 및 controlPlane.replicas 매개변수 값의 합계인 install-config.yaml 파일에 정의된 총 호스트 수를 초과해서는 안 됩니다.

   3

   선택 사항: DHCP(Dynamic Host Configuration Protocol) 또는 역방향 DNS 조회에서 얻은 호스트 이름을 재정의합니다. 각 호스트에는 이러한 방법 중 하나에서 제공하는 고유한 호스트 이름이 있어야 합니다.

   4

   특정 장치에 대한 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지의 프로비저닝을 활성화합니다. 설치 프로그램은 장치를 검색한 순서대로 검사하고 검색된 값을 팁과 비교합니다. 힌트 값과 일치하는 첫 번째 검색된 장치를 사용합니다.

   5

   선택 사항: NMState 형식으로 호스트의 네트워크 인터페이스를 구성합니다.

프로세스

1. 다음 명령을 실행하여 ZTP 클러스터 매니페스트를 생성합니다.

   $ openshift-install agent create cluster-manifests --dir <installation_directory>

   중요

   install-config.yaml 및 agent-config.yaml 파일을 생성한 경우 해당 파일이 삭제되고 이 명령을 통해 생성된 클러스터 매니페스트로 교체됩니다.

   openshift-install agent create cluster-manifests 명령을 실행할 때 install-config.yaml 및 agent-config.yaml 파일에 대한 구성은 ZTP 클러스터 매니페스트로 가져옵니다.

2. 다음 명령을 실행하여 cluster-manifests 디렉터리로 이동합니다.

   $ cd <installation_directory>/cluster-manifests

3. cluster-manifests 디렉터리에서 매니페스트 파일을 구성합니다. 샘플 파일의 경우 "Sample GitOps ZTP 사용자 정의 리소스" 섹션을 참조하십시오.

4. 연결이 끊긴 클러스터: ZTP 매니페스트를 생성하기 전에 install-config.yaml 파일에 미러 구성을 정의하지 않은 경우 다음 단계를 수행합니다.

   1. 다음 명령을 실행하여 미러 디렉터리로 이동합니다.

      $ cd ../mirror

   2. 미러 디렉터리에 매니페스트 파일을 구성합니다.

프로세스

1. 다음 명령을 실행하여 ZTP 클러스터 매니페스트를 생성합니다.

   $ openshift-install agent create cluster-manifests --dir <installation_directory>

   중요

   install-config.yaml 및 agent-config.yaml 파일을 생성한 경우 해당 파일이 삭제되고 이 명령을 통해 생성된 클러스터 매니페스트로 교체됩니다.

   openshift-install agent create cluster-manifests 명령을 실행할 때 install-config.yaml 및 agent-config.yaml 파일에 대한 구성은 ZTP 클러스터 매니페스트로 가져옵니다.

   참고

   이미 ZTP 매니페스트를 생성한 경우 이 단계를 건너뜁니다.

2. 다음 명령을 실행하여 cluster-manifests 디렉터리로 이동합니다.

   $ cd <installation_directory>/cluster-manifests

3. agent-cluster-install.yaml 파일에 다음 섹션을 추가합니다.

   diskEncryption:
       enableOn: all 1
       mode: tang 2
       tangServers: "server1": "http://tang-server-1.example.com:7500" 3

   1

   디스크 암호화를 활성화할 노드를 지정합니다. 유효한 값은 none,all,master, worker 입니다.

   2

   사용할 디스크 암호화 모드를 지정합니다. 유효한 값은 tpmv2 및 tang 입니다.

   3

   선택 사항: Tang을 사용하는 경우 Tang 서버를 지정합니다.

프로세스

1. 다음 명령을 실행하여 에이전트 이미지를 생성합니다.

   $ openshift-install --dir <install_directory> agent create image

   참고

   RHCOS(Red Hat Enterprise Linux CoreOS)는 기본 디스크에서 다중 경로를 지원하므로 하드웨어 장애에 대한 탄력성이 강화된 호스트 가용성을 높일 수 있습니다. 기본 /etc/multipath.conf 구성이 있는 에이전트 ISO 이미지에서 멀티패스는 기본적으로 활성화됩니다.

2. 베어 메탈 시스템에서 agent.x86_64.iso 또는 agent.aarch64.iso 이미지를 부팅합니다.

프로세스

1. 에이전트 콘솔 애플리케이션이 레지스트리에서 구성된 릴리스 이미지를 가져올 수 있는지 여부를 확인할 때까지 기다립니다.

2. 에이전트 콘솔 애플리케이션에서 설치 프로그램 연결 확인이 전달되었다고 표시되면 프롬프트가 설치를 계속할 때까지 기다립니다.

   참고

   연결 검사에서 통과한 경우에도 네트워크 구성 설정을 보거나 변경하도록 선택할 수 있습니다.

   그러나 시간 초과를 두는 대신 에이전트 콘솔 애플리케이션과 상호 작용하도록 선택하는 경우 TUI를 수동으로 종료하여 설치를 진행해야 합니다.

3. 에이전트 콘솔 애플리케이션 검사에 실패한 경우 릴리스 이미지 URL 가져오기 확인 옆에 빨간색 아이콘으로 표시되는 다음 단계를 사용하여 호스트의 네트워크 설정을 재구성합니다.

   1. TUI의 Check Errors 섹션을 읽으십시오. 이 섹션에는 실패한 검사와 관련된 오류 메시지가 표시됩니다.

      
   2. Configure network 를 선택하여 NetworkManager TUI를 시작합니다.
   3. 연결 편집을 선택하고 재구성할 연결을 선택합니다.
   4. 구성을 편집하고 OK 를 선택하여 변경 사항을 저장합니다.
   5. Back 을 선택하여 NetworkManager TUI의 기본 화면으로 돌아갑니다.
   6. 연결 활성화를 선택합니다.
   7. 재구성된 네트워크를 선택하여 비활성화합니다.
   8. 재구성된 네트워크를 다시 선택하여 다시 활성화합니다.
   9. Back 을 선택한 다음 Quit 를 선택하여 에이전트 콘솔 애플리케이션으로 돌아갑니다.
   10. 새 네트워크 구성을 사용하여 연속 네트워크 검사를 다시 시작할 때까지 5초 이상 기다립니다.
   11. 릴리스 이미지 URL 가져오기 검사가 성공하고 URL 옆에 녹색 아이콘이 표시되면 Quit 를 선택하여 에이전트 콘솔 애플리케이션을 종료하고 설치를 계속합니다.

프로세스

1. 선택 사항: 부트스트랩 호스트(신규 호스트)가 재부팅되는 시기를 확인하려면 다음 명령을 실행합니다.

   $ ./openshift-install --dir <install_directory> agent wait-for bootstrap-complete \1
       --log-level=info 2

   1

   & lt;install_directory > 의 경우 에이전트 ISO가 생성된 디렉터리의 경로를 지정합니다.

   2

   다른 설치 세부 사항을 보려면 info 대신 warn, debug 또는 error를 지정합니다.

   출력 예

   ...................................................................
   ...................................................................
   INFO Bootstrap configMap status is complete
   INFO cluster bootstrap is complete

   이 명령은 Kubernetes API 서버가 컨트롤 플레인 시스템에서 부트스트랩되었다는 신호를 보낼 때 성공합니다.

2. 진행 상황을 추적하고 성공적으로 설치를 확인하려면 다음 명령을 실행합니다.

   $ openshift-install --dir <install_directory> agent wait-for install-complete 1

   1

   & lt;install_directory > 디렉터리에 대해 에이전트 ISO가 생성된 디렉터리의 경로를 지정합니다.

   출력 예

   ...................................................................
   ...................................................................
   INFO Cluster is installed
   INFO Install complete!
   INFO To access the cluster as the system:admin user when using 'oc', run
   INFO     export KUBECONFIG=/home/core/installer/auth/kubeconfig
   INFO Access the OpenShift web-console here: https://console-openshift-console.apps.sno-cluster.test.example.com

프로세스

1. z/VM 게스트에 대한 매개변수 파일을 생성합니다.

   매개변수 파일 예

   rd.neednet=1 \
   console=ttysclp0 \
   coreos.live.rootfs_url=<rootfs_url> \ 1
   ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \ 2
   zfcp.allow_lun_scan=0 \ 3
   rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
   rd.dasd=0.0.4411 \ 4
   rd.zfcp=0.0.8001,0x50050763040051e3,0x4000406300000000 \ 5
   random.trust_cpu=on rd.luks.options=discard \
   ignition.firstboot ignition.platform.id=metal \
   console=tty1 console=ttyS1,115200n8 \
   coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8"

   1

   coreos.live.rootfs_url 아티팩트의 경우 부팅 중인 커널 및 initramfs 와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

   2

   ip 매개변수의 경우 "IBM Z® 및 IBM® LinuxONE에 z/VM으로 클러스터 설치"에 설명된 대로 DHCP를 사용하여 자동으로 IP 주소를 할당하거나 IP 주소를 수동으로 할당합니다.

   3

   기본값은 1입니다. OSA 네트워크 어댑터를 사용하는 경우 이 항목을 생략합니다.

   4

   DASD 유형 디스크에 설치하는 경우 rd.dasd 를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS)를 설치할 DASD를 지정합니다. FCP 유형 디스크에 대해 이 항목을 생략합니다.

   5

   FCP 유형 디스크에 설치하려면 rd.zfcp=<adapter>,<wwpn>,<lun >을 사용하여 RHCOS를 설치할 FCP 디스크를 지정합니다. DASD 유형 디스크에 이 항목을 생략합니다.

   변경되지 않은 다른 모든 매개변수는 그대로 두십시오.

2. kernel.img,generic.parm, initrd.img 파일을 z/VM 게스트 가상 머신의 가상 리더로 실행합니다.

   자세한 내용은 PUNCH (IBM 문서)를 참조하십시오.

   작은 정보

   CP PUNCH 명령을 사용하거나 Linux를 사용하는 경우 vmur 명령을 사용하여 두 개의 z/VM 게스트 가상 머신 간에 파일을 전송할 수 있습니다.

3. 부트스트랩 머신의 대화식 모니터 시스템(CMS)에 로그인합니다.

4. 다음 명령을 실행하여 리더의 부트스트랩 시스템을 IPL합니다.

   $ ipl c

   자세한 내용은 IPL (IBM 문서)을 참조하십시오.

프로세스

1. RHEL KVM 머신을 부팅합니다.

2. 가상 서버를 배포하려면 다음 매개변수를 사용하여 virt-install 명령을 실행합니다.

   $ virt-install \
      --name <vm_name> \
      --autostart \
      --ram=16384 \
      --cpu host \
      --vcpus=8 \
      --location <path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img \1
      --disk <qcow_image_path> \
      --network network:macvtap ,mac=<mac_address> \
      --graphics none \
      --noautoconsole \
      --wait=-1 \
      --extra-args "rd.neednet=1 nameserver=<nameserver>" \
      --extra-args "ip=<IP>::<nameserver>::<hostname>:enc1:none" \
      --extra-args "coreos.live.rootfs_url=http://<http_server>:8080/agent.s390x-rootfs.img" \
      --extra-args "random.trust_cpu=on rd.luks.options=discard" \
      --extra-args "ignition.firstboot ignition.platform.id=metal" \
      --extra-args "console=tty1 console=ttyS1,115200n8" \
      --extra-args "coreos.inst.persistent-kargs=console=tty1 console=ttyS1,115200n8" \
      --osinfo detect=on,require=off

   1

   --location 매개변수의 경우 HTTP 또는 HTTPS 서버의 kernel/initrd 위치를 지정합니다.

1. 모든 클라우드 공급자에서 모든 CCO 모드가 지원되는 것은 아닙니다. CCO 모드에 대한 자세한 내용은 인증 및 권한 부여 콘텐츠의 "클라우드 공급자 인증 정보 관리" 항목을 참조하십시오.