10.3. OpenShift 설치를 위한 환경 설정
10.3.1. 프로비저너 노드에 RHEL 설치
네트워킹 구성이 완료되면 다음 단계는 프로비저너 노드에 RHEL 8.x를 설치하는 것입니다. 설치 프로그램은 OpenShift Container Platform 클러스터를 설치하는 동안 프로비저너 노드를 오케스트레이터로 사용합니다. 이 문서에서는 프로비저너 노드에 RHEL을 설치하는 것은 다루지 않습니다. 선택 옵션에는 RHEL Satellite 서버, PXE 또는 설치 미디어 사용이 포함되지어 있지만 이에 국한되지는 않습니다.
10.3.2. OpenShift Container Platform 설치를 위한 provisioner 노드 준비
환경을 준비하려면 다음 단계를 수행하십시오.
프로세스
-
ssh
를 통해 프로비저너 노드에 로그인합니다. root가 아닌 사용자 (
kni
)를 만들고 해당 사용자에게sudo
권한을 부여합니다.# useradd kni # passwd kni # echo "kni ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/kni # chmod 0440 /etc/sudoers.d/kni
새 사용자에 대한
ssh
키를 만듭니다.# su - kni -c "ssh-keygen -t ed25519 -f /home/kni/.ssh/id_rsa -N ''"
프로비저너 노드에서 새 사용자로 로그인합니다.
# su - kni $
Red Hat Subscription Manager를 사용하여 프로비저닝 노드를 등록합니다.
$ sudo subscription-manager register --username=<user> --password=<pass> --auto-attach $ sudo subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-baseos-rpms
참고Red Hat Subscription Manager에 대한 자세한 내용은 Using and Configuring Red Hat Subscription Manager에서 참조하십시오.
다음 패키지를 설치합니다.
$ sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool
사용자를 변경하여
libvirt
그룹을 새로 만든 사용자에 추가합니다.$ sudo usermod --append --groups libvirt <user>
firewalld
를 다시 시작하고http
서비스를 활성화합니다.$ sudo systemctl start firewalld $ sudo firewall-cmd --zone=public --add-service=http --permanent $ sudo firewall-cmd --reload
libvirtd
서비스를 시작하고 활성화합니다.$ sudo systemctl enable libvirtd --now
default
스토리지 풀을 생성하고 시작합니다.$ sudo virsh pool-define-as --name default --type dir --target /var/lib/libvirt/images $ sudo virsh pool-start default $ sudo virsh pool-autostart default
네트워킹을 설정합니다.
참고웹 콘솔에서 네트워킹을 구성할 수도 있습니다.
baremetal
네트워크 NIC 이름을 내보냅니다.$ export PUB_CONN=<baremetal_nic_name>
baremetal
네트워크를 구성합니다.$ sudo nohup bash -c " nmcli con down \"$PUB_CONN\" nmcli con delete \"$PUB_CONN\" # RHEL 8.1 appends the word \"System\" in front of the connection, delete in case it exists nmcli con down \"System $PUB_CONN\" nmcli con delete \"System $PUB_CONN\" nmcli connection add ifname baremetal type bridge con-name baremetal bridge.stp no nmcli con add type bridge-slave ifname \"$PUB_CONN\" master baremetal pkill dhclient;dhclient baremetal "
provisioning
네트워크를 사용하여 배포하는 경우provisioning
네트워크 NIC 이름을 내보냅니다.$ export PROV_CONN=<prov_nic_name>
provisioning
네트워크를 사용하여 배포하는 경우provisioning
네트워크를 구성합니다.$ sudo nohup bash -c " nmcli con down \"$PROV_CONN\" nmcli con delete \"$PROV_CONN\" nmcli connection add ifname provisioning type bridge con-name provisioning nmcli con add type bridge-slave ifname \"$PROV_CONN\" master provisioning nmcli connection modify provisioning ipv6.addresses fd00:1101::1/64 ipv6.method manual nmcli con down provisioning nmcli con up provisioning "
참고이 단계를 실행한 후
ssh
연결이 끊어 질 수 있습니다.baremetal
네트워크를 통해 라우팅 할 수 없는 한 IPv6 주소는 모든 주소를 사용할 수 있습니다.Pv6 주소를 사용하는 경우 UEFI가 활성화되고 UEFI PXE 설정이 IPv6 프로토콜로 설정되어 있는지 확인하십시오.
provisioning
네트워크 연결에서 IPv4 주소를 구성합니다.$ nmcli connection modify provisioning ipv4.addresses 172.22.0.254/24 ipv4.method manual
provisioner
노드로ssh
를 실행합니다 (필요한 경우).# ssh kni@provisioner.<cluster-name>.<domain>
연결 브리지가 제대로 생성되었는지 확인합니다.
$ sudo nmcli con show
NAME UUID TYPE DEVICE baremetal 4d5133a5-8351-4bb9-bfd4-3af264801530 bridge baremetal provisioning 43942805-017f-4d7d-a2c2-7cb3324482ed bridge provisioning virbr0 d9bca40f-eee1-410b-8879-a2d4bb0465e7 bridge virbr0 bridge-slave-eno1 76a8ed50-c7e5-4999-b4f6-6d9014dd0812 ethernet eno1 bridge-slave-eno2 f31c3353-54b7-48de-893a-02d2b34c4736 ethernet eno2
pull-secret.txt
파일을 만듭니다.$ vim pull-secret.txt
웹 브라우저에서 설치 관리자 프로비저닝 인프라가 있는 베어 메탈에 OpenShift 설치 로 이동하고 Downloads 섹션 아래로 스크롤합니다. Copy pull secret을 클릭합니다.
pull-secret.txt
파일에 내용을 붙여 넣고kni
사용자의 홈 디렉터리에 저장합니다.
10.3.3. OpenShift Container Platform 설치 프로그램 검색
설치 프로그램의 stable-4.x
버전을 사용하여 일반적으로 사용 가능한 안정적인 OpenShift Container Platform 버전을 배포합니다.
$ export VERSION=stable-4.9 export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}')
10.3.4. OpenShift Container Platform 설치 프로그램 추출
설치 프로그램을 가져온 후 다음 단계로 압축을 풉니다.
프로세스
환경 변수를 설정합니다.
$ export cmd=openshift-baremetal-install $ export pullsecret_file=~/pull-secret.txt $ export extract_dir=$(pwd)
oc
바이너리를 가져옵니다.$ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc
설치 프로그램 압축을 풉니다.
$ sudo cp oc /usr/local/bin $ oc adm release extract --registry-config "${pullsecret_file}" --command=$cmd --to "${extract_dir}" ${RELEASE_IMAGE} $ sudo cp openshift-baremetal-install /usr/local/bin
10.3.5. RHCOS 이미지 캐시 만들기 (선택 사항)
이미지 캐싱을 사용하려면 부트스트랩 VM에서 사용하는 RHCOS (Red Hat Enterprise Linux CoreOS) 이미지와 다른 노드를 프로비저닝하기 위해 설치 프로그램에서 사용하는 RHCOS 이미지의 두 가지 이미지를 다운로드해야 합니다. 이미지 캐싱은 선택 사항이지만 대역폭이 제한된 네트워크에서 설치 프로그램을 실행할 때 특히 유용합니다.
대역폭이 제한된 네트워크에서 설치 프로그램을 실행 중이고 RHCOS 이미지 다운로드에 15-20 분 이상 걸리는 경우 설치 프로그램이 시간 초과됩니다. 이러한 경우 웹 서버에서 이미지를 캐시할 수 있습니다.
이미지가 포함된 컨테이너를 설치합니다.
프로세스
podman
을 설치합니다.$ sudo dnf install -y podman
RHCOS 이미지 캐싱에 사용할 방화벽 포트
8080
을 엽니다.$ sudo firewall-cmd --add-port=8080/tcp --zone=public --permanent
$ sudo firewall-cmd --reload
bootstraposimage
및clusterosimage
를 저장할 디렉터리를 만듭니다.$ mkdir /home/kni/rhcos_image_cache
새로 생성된 디렉터리에 적절한 SELinux 컨텍스트를 설정합니다.
$ sudo semanage fcontext -a -t httpd_sys_content_t "/home/kni/rhcos_image_cache(/.*)?"
$ sudo restorecon -Rv /home/kni/rhcos_image_cache/
설치 프로그램이 부트스트랩 VM에 배포할 RHCOS 이미지의 URI를 가져옵니다.
$ export RHCOS_QEMU_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk.location')
설치 프로그램이 부트스트랩 VM에 배포할 이미지의 이름을 가져옵니다.
$ export export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
노드에 배포되는 RHCOS 이미지의 SHA 해시를 가져옵니다.
$ export RHCOS_QEMU_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk["uncompressed-sha256"]')
설치 프로그램이 클러스터 노드에 배포할 이미지의 URI를 가져옵니다.
$ export RHCOS_OPENSTACK_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.openstack.formats["qcow2.gz"].disk.location')
설치 프로그램이 클러스터 노드에 배포할 이미지의 이름을 가져옵니다.
$ export RHCOS_OPENSTACK_NAME=${RHCOS_OPENSTACK_URI##*/}
설치 프로그램이 클러스터 노드에 배포할 이미지의 SHA 해시를 가져옵니다.
$ export RHCOS_OPENSTACK_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.openstack.formats["qcow2.gz"].disk["uncompressed-sha256"]')
이미지를 다운로드하여
/home/kni/rhcos_image_cache
디렉터리에 저장합니다.$ curl -L ${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_NAME}
$ curl -L ${RHCOS_OPENSTACK_URI} -o /home/kni/rhcos_image_cache/${RHCOS_OPENSTACK_NAME}
SELinux 유형이 새로 생성된 파일의
httpd_sys_content_t
임을 확인합니다.$ ls -Z /home/kni/rhcos_image_cache
Pod를 생성합니다.
$ podman run -d --name rhcos_image_cache \ -v /home/kni/rhcos_image_cache:/var/www/html \ -p 8080:8080/tcp \ quay.io/centos7/httpd-24-centos7:latest
위의 명령은 배포용 이미지를 제공하는
rhcos_image_cache라는
이름의 캐싱 웹 서버를 생성합니다. 첫 번째 이미지${RHCOS_PATH}${RHCOS_QEMU_URI}?sha256=${RHCOS_QEMU_SHA_UNCOMPRESSED}
는bootstrapOSImage
이고 두 번째 이미지${RHCOS_PATH}${RHCOS_OP ENSTACK_URI}?sha256=${RHCOS_OPENSTACK_SHA_COMPRESSED}
는install-config.yaml
파일의clusterOSImage
입니다.bootstrapOSImage
및clusterOSImage
구성을 만듭니다.$ export BAREMETAL_IP=$(ip addr show dev baremetal | awk '/inet /{print $2}' | cut -d"/" -f1)
$ export BOOTSTRAP_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_QEMU_NAME}?sha256=${RHCOS_QEMU_UNCOMPRESSED_SHA256}"
$ export CLUSTER_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_OPENSTACK_NAME}?sha256=${RHCOS_OPENSTACK_UNCOMPRESSED_SHA256}"
$ echo " bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}"
$ echo " clusterOSImage=${CLUSTER_OS_IMAGE}"
platform.baremetal
아래의install-config.yaml
파일에 필요한 구성을 추가합니다.platform: baremetal: bootstrapOSImage: <bootstrap_os_image> 1 clusterOSImage: <cluster_os_image> 2
자세한 내용은 "구성 파일" 섹션을 참조하십시오.
10.3.6. 구성 파일
10.3.6.1. install-config.yaml
파일을 생성합니다.
install-config.yaml
파일에는 몇 가지 추가 정보가 필요합니다. 대부분의 정보는 설치된 클러스터가 사용 가능한 하드웨어를 완벽하게 관리하는 데 필요한 정보를 충분히 갖도록 설치 프로세스를 안내하는 데 사용됩니다.
install-config.yaml
을 설정합니다.pullSecret
및sshKey
등 환경에 맞게 적절한 변수를 변경합니다.apiVersion: v1 baseDomain: <domain> metadata: name: <cluster-name> networking: machineNetwork: - cidr: <public-cidr> networkType: OVNKubernetes compute: - name: worker replicas: 2 1 controlPlane: name: master replicas: 3 platform: baremetal: {} platform: baremetal: apiVIP: <api-ip> ingressVIP: <wildcard-ip> provisioningNetworkCIDR: <CIDR> hosts: - name: openshift-master-0 role: master bmc: address: ipmi://<out-of-band-ip> 2 username: <user> password: <password> bootMACAddress: <NIC1-mac-address> rootDeviceHints: deviceName: "/dev/disk/by-id/<disk_id>" 3 - name: <openshift-master-1> role: master bmc: address: ipmi://<out-of-band-ip> 4 username: <user> password: <password> bootMACAddress: <NIC1-mac-address> rootDeviceHints: deviceName: "/dev/disk/by-id/<disk_id>" 5 - name: <openshift-master-2> role: master bmc: address: ipmi://<out-of-band-ip> 6 username: <user> password: <password> bootMACAddress: <NIC1-mac-address> rootDeviceHints: deviceName: "/dev/disk/by-id/<disk_id>" 7 - name: <openshift-worker-0> role: worker bmc: address: ipmi://<out-of-band-ip> 8 username: <user> password: <password> bootMACAddress: <NIC1-mac-address> - name: <openshift-worker-1> role: worker bmc: address: ipmi://<out-of-band-ip> username: <user> password: <password> bootMACAddress: <NIC1-mac-address> rootDeviceHints: deviceName: "/dev/disk/by-id/<disk_id>" 9 pullSecret: '<pull_secret>' sshKey: '<ssh_pub_key>'
- 1
- OpenShift Container Platform 클러스터의 일부인 작업자 노드 수를 기준으로 작업자 머신을 스케일링합니다.
replicas
값의 유효한 옵션은0
과2
보다 크거나 같은 정수입니다. 세 개의 컨트롤 플레인 시스템만 포함된 3 노드 클러스터를 배포하려면 복제본 수를0
으로 설정합니다. 3-노드 클러스터는 테스트, 개발 및 프로덕션에 사용할 수 있는 더 작고 리소스 효율적인 클러스터입니다. 작업자가 하나만 있는 클러스터를 설치할 수 없습니다. - 2 4 6 8
- 자세한 옵션은 BMC 주소 지정 섹션을 참조하십시오.
- 3 5 7 9
- 설치 디스크 드라이브의 경로를 설정합니다(예:
/dev/disk/by-id/wwn-0x64cd98f04fde100024684cf3034da5c2
).
클러스터 설정을 저장할 디렉터리를 만듭니다.
$ mkdir ~/clusterconfigs $ cp install-config.yaml ~/clusterconfigs
OpenShift Container Platform 클러스터를 설치하기 전에 모든 베어 메탈 노드의 전원이 꺼져 있는지 확인합니다.
$ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
이전 배포 시도에서 이전 부트스트랩 리소스가 남아 있는 경우 이전 부트스트랩 리소스를 삭제합니다.
for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'}); do sudo virsh destroy $i; sudo virsh undefine $i; sudo virsh vol-delete $i --pool $i; sudo virsh vol-delete $i.ign --pool $i; sudo virsh pool-destroy $i; sudo virsh pool-undefine $i; done
10.3.6.2. install-config.yaml
파일 내에서 프록시 설정 (선택 사항)
프록시를 사용하여 OpenShift Container Platform 클러스터를 배포하려면 install-config.yaml
파일을 다음과 같이 변경합니다.
apiVersion: v1 baseDomain: <domain> proxy: httpProxy: http://USERNAME:PASSWORD@proxy.example.com:PORT httpsProxy: https://USERNAME:PASSWORD@proxy.example.com:PORT noProxy: <WILDCARD_OF_DOMAIN>,<PROVISIONING_NETWORK/CIDR>,<BMC_ADDRESS_RANGE/CIDR>
다음은 값을 포함하는 noProxy
의 예입니다.
noProxy: .example.com,172.22.0.0/24,10.10.0.0/24
프록시가 활성화된 상태에서 해당 키 / 값 쌍에 적절한 프록시 값을 설정합니다.
주요 고려 사항:
-
프록시에 HTTPS 프록시가 없는 경우
httpsProxy
값을https://
에서http://
로 변경합니다. -
프로비저닝 네트워크를 사용하는 경우 이를
noProxy
설정에 포함하십시오. 그렇지 않으면 설치 프로그램이 실패합니다. -
모든 프록시 설정을 프로버저너 노드 내에서 환경 변수로 설정합니다. 예를 들어,
HTTP_PROXY,
https_proxy
,NO_PROXY
가 포함됩니다.
IPv6으로 프로비저닝할 때 noProxy
설정에서 CIDR 주소 블록을 정의할 수 없습니다. 각 주소를 개별적으로 정의해야 합니다.
10.3.6.3. provisioning
네트워크가 없는 경우 install-config.yaml
파일 변경 (선택 사항)
provisioning
네트워크없이 OpenShift Container Platform 클러스터를 배포하려면 install-config.yaml
파일을 다음과 같이 변경하십시오.
platform:
baremetal:
apiVIP: <api_VIP>
ingressVIP: <ingress_VIP>
provisioningNetwork: "Disabled" 1
- 1
- 필요한 경우
provisioningNetwork
구성 설정을 추가하고Disabled
로 설정합니다.
프로비저닝
네트워크는 PXE 부팅에 필요합니다. provisioning
네트워크 없이 배포하는 경우 redfish-virtualmedia 또는
와 같은 가상 미디어 BMC 주소 지정 옵션을 사용해야 합니다. 자세한 내용은 "HPE iLO용 BMC 주소 지정" 섹션의 "Redfish virtual media for HPE iLO"를 참조하거나 "Dell iDRAC용 BMC 주소 지정" 섹션의 "Redfish virtual media for Dell iDRAC" 섹션을 참조하십시오.
idrac-virtualmedia
10.3.6.4. 이중 스택 네트워크의 install-config.yaml
파일 변경 (선택 사항)
듀얼 스택 네트워킹으로 OpenShift Container Platform 클러스터를 배포하려면 install-config.yaml
파일에서
구성 설정을 편집합니다. 각 설정에는 각각 두 개의 CIDR 항목이 있어야 합니다. 첫 번째 CIDR 항목이 IPv4 설정이며 두 번째 CIDR 항목이 IPv6 설정인지 확인합니다.
machineNetwork
,clusterNetwork
및 serviceNetwork
machineNetwork: - cidr: {{ extcidrnet }} - cidr: {{ extcidrnet6 }} clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 - cidr: fd02::/48 hostPrefix: 64 serviceNetwork: - 172.30.0.0/16 - fd03::/112
듀얼 스택 네트워킹을 사용하는 경우 API VIP IP 주소와 Ingress VIP 주소가 기본 IP 주소 제품군이어야 합니다. 현재 Red Hat은 IPv6를 기본 IP 주소 제품군으로 사용하여 듀얼 스택 VIP 또는 듀얼 스택 네트워킹을 지원하지 않습니다. 하지만 Red Hat은 IPv4를 기본 IP 주소 제품군으로 사용하는 듀얼 스택 네트워킹을 지원합니다. 따라서 IPv4 항목은 IPv6 항목보다 먼저 이동해야 합니다.
10.3.6.5. install-config.yaml
파일에서 관리형 Secure Boot 구성 (선택 사항)
redfish, redfish
-virtualmedia 또는 idrac
와 같은 Redfish BMC 주소 지정을 사용하여 설치 관리자 프로비저닝 클러스터를 배포할 때 관리형 Secure Boot를 활성화할 수 있습니다. 관리형 Secure Boot를 활성화하려면 각 노드에 -virtualmedia
bootMode
구성 설정을 추가합니다.
예제
hosts: - name: openshift-master-0 role: master bmc: address: redfish://<out_of_band_ip> 1 username: <user> password: <password> bootMACAddress: <NIC1_mac_address> rootDeviceHints: deviceName: "/dev/sda" bootMode: UEFISecureBoot 2
노드가 관리형 Secure Boot를 지원할 수 있는지 확인하려면 "사전 요구 사항"의 "노드 구성"을 참조하십시오. 노드가 관리형 Secure Boot를 지원하지 않는 경우 "노드 구성" 섹션의 "수동으로 Secure Boot의 노드 구성"을 참조하십시오. Secure Boot를 수동으로 구성하려면 Redfish 가상 미디어가 필요합니다.
IPMI는 Secure Boot 관리 기능을 제공하지 않으므로 Red Hat은 IPMI를 사용하여 Secure Boot를 지원하지 않습니다.
10.3.6.6. 추가 install-config
매개 변수
install-config.yaml
파일의 필수 매개 변수 hosts
매개 변수 및 bmc
매개 변수는 다음 표를 참조하십시오.
매개 변수 | 기본 | 설명 |
---|---|---|
|
클러스터의 도메인 이름입니다. 예: | |
|
|
노드의 부팅 모드입니다. 옵션은 |
|
| |
|
| |
metadata: name: |
OpenShift Container Platform 클러스터에 지정되는 이름입니다. 예: | |
networking: machineNetwork: - cidr: |
외부 네트워크의 공개 CIDR (Classless Inter-Domain Routing)입니다. 예: | |
compute: - name: worker | OpenShift Container Platform 클러스터에는 노드가 없는 경우에도 작업자 (또는 컴퓨팅) 노드에 이름을 지정해야 합니다. | |
compute: replicas: 2 | 복제는 OpenShift Container Platform 클러스터의 작업자 (또는 컴퓨팅) 노드 수를 설정합니다. | |
controlPlane: name: master | OpenShift Container Platform 클러스터에는 컨트롤 플레인 (마스터) 노드의 이름이 필요합니다. | |
controlPlane: replicas: 3 | 복제는 OpenShift Container Platform 클러스터의 일부로 포함된 컨트롤 플레인 (마스터) 노드의 수를 설정합니다. | |
|
| |
| 플랫폼 구성없이 머신 풀에 사용되는 기본 설정입니다. | |
| (선택 사항) Kubernetes API 통신의 가상 IP 주소입니다.
이 설정은 | |
|
|
|
| (선택 사항) 수신 트래픽의 가상 IP 주소입니다.
이 설정은 |
매개 변수 | 기본 | 설명 |
---|---|---|
|
|
|
|
|
프로비저닝에 사용할 네트워크의 CIDR입니다. 이 옵션은 |
|
|
프로비저닝 서비스가 실행되는 클러스터 내의 IP 주소입니다. 기본값은 |
|
|
설치 프로그램이 컨트롤 플레인 (마스터) 노드를 배포하는 동안 프로비저닝 서비스가 실행되는 부트스트랩 VM의 IP 주소입니다. 기본값은 |
|
|
|
|
|
|
| 플랫폼 구성없이 머신 풀에 사용되는 기본 설정입니다. | |
|
부트스트랩 노드의 기본 운영 체제 이미지를 재정의하는 URL입니다. URL에는 이미지의 SHA-256 해시가 포함되어 있어야합니다. 예: | |
|
클러스터 노드의 기본 운영 체제를 재정의하는 URL입니다. URL에는 이미지의 SHA-256 해시가 포함되어 있어야 합니다. 예: | |
|
| |
| 이 매개 변수를 환경 내에서 사용되는 적절한 HTTP 프록시로 설정합니다. | |
| 이 매개 변수를 환경 내에서 사용되는 적절한 HTTPS 프록시로 설정합니다. | |
| 이 매개 변수를 환경 내 프록시 사용에 대한 적절한 예외 목록으로 설정합니다. |
호스트
hosts
매개 변수는 클러스터를 빌드하는 데 사용되는 별도의 베어 메탈 자산 목록입니다.
이름 | 기본 | 설명 |
---|---|---|
|
세부 정보와 연결할 | |
|
베어 메탈 노드의 역할입니다. | |
| 베이스 보드 관리 컨트롤러에 대한 연결 세부 정보입니다. 자세한 내용은 BMC 주소 지정 섹션을 참조하십시오. | |
|
호스트가 참고
|
10.3.6.7. BMC 주소 지정
대부분의 공급업체는 IPMI(Intelligent Platform Management Interface)를 사용하여 BMC(Baseboard Management Controller) 처리를 지원합니다. IPMI는 통신을 암호화하지 않습니다. 보안 또는 전용 관리 네트워크를 통해 데이터 센터 내에서 사용하기에 적합합니다. 공급 업체에 문의하여 Redfish 네트워크 부팅을 지원하는지 확인합니다. Redfish는 통합, 하이브리드 IT 및 소프트웨어 정의 데이터 센터 (SDDC)를 위한 간편한 보안 관리 기능을 제공합니다. Redfish는 사람이 읽을 수 있고 머신을 사용할 수 있으며 일반적인 인터넷 및 웹 서비스 표준을 활용하여 최신 툴 체인에 직접 정보를 노출합니다. 하드웨어에서 Redfish 네트워크 부팅을 지원하지 않는 경우 IPMI를 사용합니다.
IPMI
IPMI를 사용하는 호스트는 ipmi://<out-of-band-ip>:<port>
주소 형식을 사용하며 지정되지 않은 경우 기본적으로 포트 623
으로 설정됩니다. 다음 예제는 install-config.yaml
파일 내의 IPMI 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: ipmi://<out-of-band-ip> username: <user> password: <password>
BMC 주소 지정에 IPMI를 사용하여 PXE 부팅 시 프로비저닝
네트워크가 필요합니다. provisioning
네트워크없이는 PXE 부팅 호스트를 사용할 수 없습니다. provisioning
네트워크 없이 배포하는 경우 redfish-virtualmedia 또는
와 같은 가상 미디어 BMC 주소 지정 옵션을 사용해야 합니다. 자세한 내용은 "HPE iLO용 BMC 주소 지정" 섹션의 "Redfish virtual media for HPE iLO"를 참조하거나 "Dell iDRAC용 BMC 주소 지정" 섹션의 "Redfish virtual media for Dell iDRAC" 섹션을 참조하십시오.
idrac-virtualmedia
Redfish 네트워크 부팅
Redfish를 활성화하려면 redfish://
또는 redfish+http://
를 사용하여 TLS를 비활성화합니다. 설치 프로그램에는 호스트 이름 또는 IP 주소와 시스템 ID 경로가 모두 필요합니다. 다음 예제는 install-config.yaml
파일 내의 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish://<out-of-band-ip>/redfish/v1/Systems/1 username: <user> password: <password>
대역 외 관리 주소에 대한 인증 기관의 인증서를 사용하는 것이 좋지만 자체 서명 된 인증서를 사용하는 경우 bmc
설정에 disableCertificateVerification:True
를 포함해야 합니다. 다음 예제는 install-config.yaml
파일 내의 disableCertificateVerification:True
설정 매개 변수를 사용하는 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish://<out-of-band-ip>/redfish/v1/Systems/1 username: <user> password: <password> disableCertificateVerification: True
10.3.6.8. Dell iDRAC용 BMC 주소 지정
각 bmc
항목의 address
필드는 URL 체계의 컨트롤러 유형 및 네트워크에서의 위치를 포함하여 OpenShift Container Platform 클러스터 노드에 연결하기 위한 URL입니다.
platform:
baremetal:
hosts:
- name: <hostname>
role: <master | worker>
bmc:
address: <address> 1
username: <user>
password: <password>
- 1
address
구성 설정은 프로토콜을 지정합니다.
Dell 하드웨어의 경우 Red Hat은 통합 iDRAC(Dell Remote Access Controller) 가상 미디어, Redfish 네트워크 부팅 및 IPMI를 지원합니다.
Dell iDRAC의 BMC 주소 형식
프로토콜 | 주소 형식 |
---|---|
iDRAC 가상 미디어 |
|
Redfish 네트워크 부팅 |
|
IPMI |
|
Redfish 가상 미디어의 프로토콜로 idrac-virtualmedia
를 사용합니다. redfish-virtualmedia
는 Dell 하드웨어에서 작동하지 않습니다. Dell의 idrac-virtualmedia
는 Dell의 OEM 확장 기능과 함께 Redfish 표준을 사용합니다.
자세한 내용은 다음 섹션을 참조하십시오.
Dell iDRAC 용 Redfish 가상 미디어
Dell 서버의 Redfish 가상 미디어의 경우 address
설정에서 idrac-virtualmedia://
를 사용합니다. redfish-virtualmedia://
를 사용하는 것은 작동하지 않습니다.
다음 예는 install-config.yaml
파일 내에서 iDRAC 가상 미디어를 사용하는 방법을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: idrac-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/System.Embedded.1 username: <user> password: <password>
대역 외 관리 주소에 대한 인증 기관의 인증서를 사용하는 것이 좋지만 자체 서명 된 인증서를 사용하는 경우 bmc
설정에 disableCertificateVerification:True
를 포함해야 합니다. 다음 예제는 install-config.yaml
파일 내의 disableCertificateVerification:True
설정 매개 변수를 사용하는 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: idrac-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/System.Embedded.1 username: <user> password: <password> disableCertificateVerification: True
현재 Redfish는 베어 메탈 배포 환경에서 설치 관리자가 프로비저닝한 설치에 대해 iDRAC 펌웨어 버전 4.20.20.20
~ 04.40.00.00
을 사용하는 Dell에서만 지원됩니다. 04.40.00.00
버전에 알려진 문제가 있습니다. iDRAC 9 펌웨어 버전 04.40.00.00
을 사용하면 가상 콘솔 플러그인이 기본적으로 eHTML5
로 설정되어 InsertVirtualMedia 워크플로우에 문제가 발생합니다. 이 문제를 방지하려면 플러그인을 HTML5
로 설정합니다. 메뉴 경로는 설정
OpenShift Container Platform 클러스터 노드에 iDRAC 콘솔을 통해 AutoAttach가 활성화되어 있는지 확인합니다. 메뉴 경로는 구성 자동 연결
입니다 .
idrac-virtualmedia://
를 Redfish 가상 미디어의 프로토콜로 사용합니다. idrac -virtualmedia://
프로토콜은 Ironic의 idrac
하드웨어 유형 및 Redfish 프로토콜에 해당하므로 redfish-virtualmedia://
를 사용하면 Dell 하드웨어에서 작동하지 않습니다. Dell의 idrac-virtualmedia://
프로토콜은 Dell의 OEM 확장에 Redfish 표준을 사용합니다. Ironic은 WSMAN 프로토콜로 idrac
유형도 지원합니다. 따라서 Dell 하드웨어에서 가상 미디어와 함께 Redfish를 사용하도록 선택할 때 예기치 않은 동작을 방지하려면 idrac-virtualmedia://
를 지정해야 합니다.
iDRAC 용 Redfish 네트워크 부팅
Redfish를 활성화하려면 redfish://
또는 redfish+http://
를 사용하여 TLS(transport layer security)를 비활성화합니다. 설치 프로그램에는 호스트 이름 또는 IP 주소와 시스템 ID 경로가 모두 필요합니다. 다음 예제는 install-config.yaml
파일 내의 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish://<out-of-band-ip>/redfish/v1/Systems/System.Embedded.1 username: <user> password: <password>
대역 외 관리 주소에 대한 인증 기관의 인증서를 사용하는 것이 좋지만 자체 서명 된 인증서를 사용하는 경우 bmc
설정에 disableCertificateVerification:True
를 포함해야 합니다. 다음 예제는 install-config.yaml
파일 내의 disableCertificateVerification:True
설정 매개 변수를 사용하는 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish://<out-of-band-ip>/redfish/v1/Systems/System.Embedded.1 username: <user> password: <password> disableCertificateVerification: True
현재 Redfish는 베어 메탈 배포 환경에서 설치 관리자가 프로비저닝한 설치에 대해 iDRAC 펌웨어 버전 4.20.20.20
~ 04.40.00.00
을 사용하는 Dell 하드웨어에서만 지원됩니다. 04.40.00.00
버전에 알려진 문제가 있습니다. iDRAC 9 펌웨어 버전 04.40.00.00
을 사용하면 가상 콘솔 플러그인이 기본적으로 eHTML5
로 설정되어 InsertVirtualMedia 워크플로우에 문제가 발생합니다. 이 문제를 방지하려면 플러그인을 HTML5
로 설정합니다. 메뉴 경로는 설정
OpenShift Container Platform 클러스터 노드에 iDRAC 콘솔을 통해 AutoAttach가 활성화되어 있는지 확인합니다. 메뉴 경로는 구성
redfish://
URL 프로토콜은 Ironic의 redfish
하드웨어 유형에 해당합니다.
10.3.6.9. HPE iLO용 BMC 주소 지정
각 bmc
항목의 address
필드는 URL 체계의 컨트롤러 유형 및 네트워크에서의 위치를 포함하여 OpenShift Container Platform 클러스터 노드에 연결하기 위한 URL입니다.
platform:
baremetal:
hosts:
- name: <hostname>
role: <master | worker>
bmc:
address: <address> 1
username: <user>
password: <password>
- 1
address
구성 설정은 프로토콜을 지정합니다.
HPE iLO(integrated Lights Out)의 경우 Red Hat은 Redfish 가상 미디어, Redfish 네트워크 부팅 및 IPMI를 지원합니다.
프로토콜 | 주소 형식 |
---|---|
RedFish 가상 미디어 |
|
Redfish 네트워크 부팅 |
|
IPMI |
|
자세한 내용은 다음 섹션을 참조하십시오.
HPE iLO용 Redfish 가상 미디어
HPE 서버용 Redfish 가상 미디어를 활성화하려면 address
설정에서 redfish-virtualmedia://
를 사용합니다. 다음 예제는 install-config.yaml
파일 내에서 Redfish 가상 미디어를 사용하는 방법을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/1 username: <user> password: <password>
대역 외 관리 주소에 대한 인증 기관의 인증서를 사용하는 것이 좋지만 자체 서명 된 인증서를 사용하는 경우 bmc
설정에 disableCertificateVerification:True
를 포함해야 합니다. 다음 예제는 install-config.yaml
파일 내의 disableCertificateVerification:True
설정 매개 변수를 사용하는 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/1 username: <user> password: <password> disableCertificateVerification: True
Ironic은 가상 미디어에서 iLO4를 지원하지 않으므로 iLO4를 실행하는 9세대 시스템에서 Redfish 가상 미디어가 지원되지 않습니다.
HPE iLO용 Redfish 네트워크 부팅
Redfish를 활성화하려면 redfish://
또는 redfish+http://
를 사용하여 TLS를 비활성화합니다. 설치 프로그램에는 호스트 이름 또는 IP 주소와 시스템 ID 경로가 모두 필요합니다. 다음 예제는 install-config.yaml
파일 내의 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish://<out-of-band-ip>/redfish/v1/Systems/1 username: <user> password: <password>
대역 외 관리 주소에 대한 인증 기관의 인증서를 사용하는 것이 좋지만 자체 서명 된 인증서를 사용하는 경우 bmc
설정에 disableCertificateVerification:True
를 포함해야 합니다. 다음 예제는 install-config.yaml
파일 내의 disableCertificateVerification:True
설정 매개 변수를 사용하는 Redfish 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: redfish://<out-of-band-ip>/redfish/v1/Systems/1 username: <user> password: <password> disableCertificateVerification: True
10.3.6.10. Fujitsu iRMC용 BMC 주소 지정
각 bmc
항목의 address
필드는 URL 체계의 컨트롤러 유형 및 네트워크에서의 위치를 포함하여 OpenShift Container Platform 클러스터 노드에 연결하기 위한 URL입니다.
platform:
baremetal:
hosts:
- name: <hostname>
role: <master | worker>
bmc:
address: <address> 1
username: <user>
password: <password>
- 1
address
구성 설정은 프로토콜을 지정합니다.
Fujitsu 하드웨어의 경우 Red Hat은 통합된 iRMC(Remote Management Controller) 및 IPMI를 지원합니다.
프로토콜 | 주소 형식 |
---|---|
iRMC |
|
IPMI |
|
iRMC
Fujitsu 노드는 irmc://<out-of-band-ip
>를 사용할 수 있으며 기본값은 포트 443
입니다. 다음 예제는 install-config.yaml
파일 내의 iRMC 설정을 보여줍니다.
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: irmc://<out-of-band-ip> username: <user> password: <password>
현재 Fujitsu는 베어 메탈에 설치 관리자 프로비저닝 설치를 위해 iRMC S5 펌웨어 버전 3.05P 이상을 지원합니다.
10.3.6.11. 루트 장치 팁
rootDeviceHints
매개 변수를 사용하면 설치 프로그램이 RHCOS (Red Hat Enterprise Linux CoreOS) 이미지를 특정 장치에 프로비저닝할 수 있습니다. 설치 프로그램은 장치를 검색한 순서대로 검사하고 검색된 값을 팁과 비교합니다. 설치 프로그램은 팁과 일치하는 첫 번째 검색된 장치를 사용합니다. 이 설정은 여러 팁을 결합할 수 있지만 장치는 설치 프로그램이이를 선택할 수 있도록 모든 팁과 일치해야 합니다.
서브 필드 | 설명 |
---|---|
|
|
|
|
| 공급 업체별 장치 식별자가 포함된 문자열. 팁은 실제 값의 하위 문자열입니다. |
| 장치의 공급 업체 또는 제조업체 이름이 포함된 문자열입니다. 팁은 실제 값의 하위 문자열입니다. |
| 장치 일련 번호가 포함된 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다. |
| 장치의 최소 크기 (기가 바이트)를 나타내는 정수입니다. |
| 고유 저장소 식별자를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다. |
| 공급 업체 확장이 추가된 고유 한 저장소 식별자가 포함된 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다. |
| 고유 공급 업체 저장소 식별자를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다. |
| 장치가 회전 디스크 여야하는지 (true) 아닌지 (false)를 나타내는 부울 값입니다. |
사용 예
- name: master-0 role: master bmc: address: ipmi://10.10.0.3:6203 username: admin password: redhat bootMACAddress: de:ad:be:ef:00:40 rootDeviceHints: deviceName: "/dev/sda"
10.3.6.12. OpenShift Container Platform 매니페스트 만들기
OpenShift Container Platform 매니페스트를 만듭니다.
$ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests
INFO Consuming Install Config from target directory WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings WARNING Discarding the OpenShift Manifest that was provided in the target directory because its dependencies are dirty and it needs to be regenerated
10.3.6.13. 연결이 끊긴 클러스터의 NTP 구성 (선택 사항)
OpenShift Container Platform은 클러스터 노드에 chrony
Network Time Protocol(NTP) 서비스를 설치합니다.
OpenShift Container Platform 노드는 올바로 실행되려면 날짜와 시간에 동의해야 합니다. 작업자 노드는 컨트롤 플레인 노드의 NTP 서버에서 날짜와 시간을 검색하면 라우팅 가능한 네트워크에 연결되지 않은 클러스터를 설치 및 운영할 수 있으므로 상위 계층 NTP 서버에 액세스할 수 없습니다.
절차
컨트롤 플레인 노드에 대한
chrony.conf
파일의 콘텐츠를 포함하여 Butane 구성,99-master-chrony-conf-override.bu
를 만듭니다.참고Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.
Butane 구성의 예
variant: openshift version: 4.9.0 metadata: name: 99-master-chrony-conf-override labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # Use public servers from the pool.ntp.org project. # Please consider joining the pool (https://www.pool.ntp.org/join.html). # The Machine Config Operator manages this file server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony # Configure the control plane nodes to serve as local NTP servers # for all worker nodes, even if they are not in sync with an # upstream NTP server. # Allow NTP client access from the local network. allow all # Serve time even if not synchronized to a time source. local stratum 3 orphan
- 1
<cluster-name>
을 클러스터 이름으로 바꾸고<domain>
을 정규화된 도메인 이름으로 교체해야 합니다.
Butane을 사용하여 컨트롤 플레인 노드에 전달할 구성이 포함된
MachineConfig
파일99-master-chrony-conf-override.yaml
을 생성합니다.$ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
컨트롤 플레인 노드의 NTP 서버를 참조하는 작업자 노드의
chrony.conf
파일의 내용을 포함하여 Butane 구성99-worker-chrony-conf-override.bu
를 만듭니다.Butane 구성의 예
variant: openshift version: 4.9.0 metadata: name: 99-worker-chrony-conf-override labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # The Machine Config Operator manages this file. server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony
- 1
<cluster-name>
을 클러스터 이름으로 바꾸고<domain>
을 정규화된 도메인 이름으로 교체해야 합니다.
Butane을 사용하여 작업자 노드로 전달할 구성이 포함된
MachineConfig
개체 파일99-worker-chrony-conf-override.yaml
을 생성합니다.$ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
10.3.6.14. (선택 사항) 컨트롤 플레인에서 실행되도록 네트워크 구성 요소 구성
컨트롤 플레인 노드에서 독점적으로 실행되도록 네트워킹 구성 요소를 구성할 수 있습니다. 기본적으로 OpenShift Container Platform에서는 머신 구성 풀의 모든 노드가 ingressVIP
가상 IP 주소를 호스팅할 수 있습니다. 그러나 일부 환경에서는 컨트롤 플레인 노드와 별도의 서브넷에 작업자 노드를 배포합니다. 별도의 서브넷에 원격 작업자를 배포하는 경우 ingressVIP
가상 IP 주소를 컨트롤 플레인 노드 전용으로 배치해야 합니다.
절차
install-config.yaml
파일을 저장하는 디렉터리로 변경합니다.$ cd ~/clusterconfigs
manifests
하위 디렉터리로 전환합니다.$ cd manifests
cluster-network-avoid-workers-99-config.yaml
이라는 파일을 생성합니다.$ touch cluster-network-avoid-workers-99-config.yaml
편집기에서
cluster-network-avoid-workers-99-config.yaml
파일을 열고 Operator 구성을 설명하는 CR(사용자 정의 리소스)을 입력합니다.apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 50-worker-fix-ipi-rwn labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/kubernetes/manifests/keepalived.yaml mode: 0644 contents: source: data:,
이 매니페스트는 컨트롤 플레인 노드에
ingressVIP
가상 IP 주소를 배치합니다. 또한 이 매니페스트는 컨트롤 플레인 노드에 다음 프로세스를 배포합니다.-
openshift-ingress-operator
-
keepalived
-
-
cluster-network-avoid-workers-99-config.yaml
파일을 저장합니다. manifests/cluster-ingress-default-ingresscontroller.yaml
파일을 생성합니다.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/master: ""
-
manifests
디렉터리를 백업하는 것이 좋습니다. 설치 프로그램은 클러스터를 생성할 때manifests/
디렉터리를 삭제합니다. mastersSchedulable
필드를true
로 설정하여 컨트롤 플레인 노드를 예약할 수 있도록cluster-scheduler-02-config.yml
매니페스트를 수정합니다. 기본적으로 컨트롤 플레인 노드는 예약할 수 없습니다. 예를 들면 다음과 같습니다.$ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml
참고이 절차를 완료한 후 컨트롤 플레인 노드를 예약할 수 없는 경우 클러스터 배포가 실패합니다.
10.3.6.15. 작업자 노드용 BIOS 구성
다음 절차에서는 설치 프로세스 중에 작업자 노드에 대한 BIOS를 구성합니다.
절차
- 매니페스트를 생성합니다.
작업자에 해당하는 BMH 파일을 수정합니다.
$ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-3.yaml
BMH 파일의
spec
섹션에 BIOS 구성을 추가합니다.spec: firmware: simultaneousMultithreadingEnabled: true sriovEnabled: true virtualizationEnabled: true
참고-
Red Hat은 다음 세 가지 BIOS 설정을 지원합니다. 자세한 내용은 BMH 설명서 를 참조하십시오. bmc 유형
irmc
가 있는 서버만 지원됩니다. 다른 유형의 서버는 현재 지원되지 않습니다.
-
Red Hat은 다음 세 가지 BIOS 설정을 지원합니다. 자세한 내용은 BMH 설명서 를 참조하십시오. bmc 유형
- 클러스터 생성.
10.3.7. 비 연결 레지스트리 만들기 (선택 사항)
설치 레지스트리의 로컬 사본을 사용하여 OpenShift Container Platform 클러스터를 설치해야하는 경우가 있습니다. 이는 클러스터 노드가 인터넷에 액세스할 수 없는 네트워크에 있기 때문에 네트워크 효율성을 향상시키기 위한 것일 수 있습니다.
로컬 또는 미러링된 레지스트리 사본에는 다음이 필요합니다.
- 레지스트리 노드의 인증서. 자체 서명된 인증서를 사용할 수 있습니다.
- 시스템의 컨테이너가 제공할 웹 서버입니다.
- 인증서 및 로컬 저장소 정보를 포함하는 업데이트된 풀 시크릿.
레지스트리 노드에 연결되지 않은 레지스트리를 만드는 것은 선택 사항입니다. 다음 섹션은 선택 사항으로 레지스트리 노드에 연결되지 않은 레지스트리를 만드는 경우에만 실행해야 하는 단계입니다. 레지스트리 노드에 연결되지 않은 레지스트리를 만들 때 "(선택 사항)"레이블이 붙은 모든 후속 하위 섹션을 실행해야 합니다.
10.3.7.1. 미러링된 레지스트리를 호스팅할 레지스트리 노드 준비 (선택 사항)
레지스트리 노드를 다음과 같이 변경합니다.
절차
레지스트리 노드에서 방화벽 포트를 엽니다.
$ sudo firewall-cmd --add-port=5000/tcp --zone=libvirt --permanent $ sudo firewall-cmd --add-port=5000/tcp --zone=public --permanent $ sudo firewall-cmd --reload
레지스트리 노드에 필요한 패키지를 설치합니다.
$ sudo yum -y install python3 podman httpd httpd-tools jq
저장소 정보가 보관될 디렉터리 구조를 만듭니다.
$ sudo mkdir -p /opt/registry/{auth,certs,data}
10.3.7.2. 자체 서명 인증서 생성 (선택 사항)
레지스트리 노드의 자체 서명된 인증서를 생성하고 이를 /opt/registry/certs
디렉터리에 배치합니다.
절차
인증서 정보를 적절하게 조정합니다.
$ host_fqdn=$( hostname --long ) $ cert_c="<Country Name>" # Country Name (C, 2 letter code) $ cert_s="<State>" # Certificate State (S) $ cert_l="<Locality>" # Certificate Locality (L) $ cert_o="<Organization>" # Certificate Organization (O) $ cert_ou="<Org Unit>" # Certificate Organizational Unit (OU) $ cert_cn="${host_fqdn}" # Certificate Common Name (CN) $ openssl req \ -newkey rsa:4096 \ -nodes \ -sha256 \ -keyout /opt/registry/certs/domain.key \ -x509 \ -days 365 \ -out /opt/registry/certs/domain.crt \ -addext "subjectAltName = DNS:${host_fqdn}" \ -subj "/C=${cert_c}/ST=${cert_s}/L=${cert_l}/O=${cert_o}/OU=${cert_ou}/CN=${cert_cn}"
참고<Country Name>
을 바꾸는 경우에는 두 문자 만 사용합니다. 예:US
새 인증서로 레지스트리 노드의
ca-trust
를 업데이트합니다.$ sudo cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust extract
10.3.7.3. 레지스트리 podman 컨테이너 만들기 (선택 사항)
레지스트리 컨테이너는 인증서, 인증 파일 및 데이터 파일 저장에 /opt/registry
디렉터리를 사용합니다.
레지스트리 컨테이너는 httpd
를 사용하며 인증을 위해 htpasswd
파일이 필요합니다.
절차
컨테이너에서 사용할
htpasswd
파일을/opt/registry/auth
에 만듭니다.$ htpasswd -bBc /opt/registry/auth/htpasswd <user> <passwd>
<user>
를 사용자 이름으로,<passwd>
를 암호로 바꿉니다.레지스트리 컨테이너를 만들고 시작합니다.
$ podman create \ --name ocpdiscon-registry \ -p 5000:5000 \ -e "REGISTRY_AUTH=htpasswd" \ -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" \ -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" \ -e "REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd" \ -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \ -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \ -e "REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true" \ -v /opt/registry/data:/var/lib/registry:z \ -v /opt/registry/auth:/auth:z \ -v /opt/registry/certs:/certs:z \ docker.io/library/registry:2
$ podman start ocpdiscon-registry
10.3.7.4. 풀 시크릿(pull-secret) 복사 및 업데이트 (선택 사항)
프로비저너 노드에서 레지스트리 노드로 풀 시크릿 파일을 복사하고 이를 새 레지스트리 노드의 인증 정보를 포함하도록 변경합니다.
절차
pull-secret.txt
파일을 복사합니다.$ scp kni@provisioner:/home/kni/pull-secret.txt pull-secret.txt
host_fqdn
환경 변수를 레지스트리 노드의 완전한 도메인 이름으로 업데이트합니다.$ host_fqdn=$( hostname --long )
htpasswd
파일을 만드는 데 사용되는http
인증 정보의 base64 인코딩으로b64auth
환경 변수를 업데이트합니다.$ b64auth=$( echo -n '<username>:<passwd>' | openssl base64 )
<username>
을 사용자 이름으로,<passwd>
를 암호로 바꿉니다.base64
승인 문자열을 사용하도록AUTHSTRING
환경 변수를 설정합니다.$USER
변수는 현재 사용자의 이름을 포함하는 환경 변수입니다.$ AUTHSTRING="{\"$host_fqdn:5000\": {\"auth\": \"$b64auth\",\"email\": \"$USER@redhat.com\"}}"
pull-secret.txt
파일을 업데이트합니다.$ jq ".auths += $AUTHSTRING" < pull-secret.txt > pull-secret-update.txt
10.3.7.5. 저장소 미러링 (선택 사항)
프로세스
프로비저너 노드에서 레지스트리 노드에
oc
바이너리를 복사합니다.$ sudo scp kni@provisioner:/usr/local/bin/oc /usr/local/bin
필요한 환경 변수를 설정합니다.
릴리스 버전을 설정합니다.
$ VERSION=<release_version>
<release_version>
에 대해 설치할 OpenShift Container Platform 버전에 해당하는 태그를 지정합니다 (예:4.9
).로컬 레지스트리 이름 및 호스트 포트를 설정합니다.
$ LOCAL_REG='<local_registry_host_name>:<local_registry_host_port>'
<local_registry_host_name>
의 경우 미러 저장소의 레지스트리 도메인 이름을 지정하고<local_registry_host_port>
의 경우 콘텐츠를 제공하는데 사용되는 포트를 지정합니다.로컬 리포지터리 이름을 설정합니다.
$ LOCAL_REPO='<local_repository_name>'
<local_repository_name>
의 경우 레지스트리에 작성할 저장소 이름 (예:ocp4/openshift4
)을 지정합니다.
원격 설치 이미지를 로컬 저장소에 미러링합니다.
$ /usr/local/bin/oc adm release mirror \ -a pull-secret-update.txt \ --from=$UPSTREAM_REPO \ --to-release-image=$LOCAL_REG/$LOCAL_REPO:${VERSION} \ --to=$LOCAL_REG/$LOCAL_REPO
10.3.7.6. 비 연결 레지스트리를 사용하도록 install-config.yaml
파일 변경 (선택 사항)
프로비저너 노드에서 install-config.yaml
파일은 pull-secret-update.txt
파일에서 새로 생성된 풀 시크릿(pull-secret)을 사용해야 합니다. install-config.yaml
파일에는 연결되지 않은 레지스트리 노드 인증서 및 레지스트리 정보도 포함되어야합니다.
프로세스
비 연결 레지스트리 노드의 인증서를
install-config.yaml
파일에 추가합니다. 인증서는"additionalTrustBundle:|"
뒤에 있어야 하며 보통 두 개의 공백으로 적절하게 들여 쓰기합니다.$ echo "additionalTrustBundle: |" >> install-config.yaml $ sed -e 's/^/ /' /opt/registry/certs/domain.crt >> install-config.yaml
레지스트리의 미러 정보를
install-config.yaml
파일에 추가합니다.$ echo "imageContentSources:" >> install-config.yaml $ echo "- mirrors:" >> install-config.yaml $ echo " - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml $ echo " source: quay.io/openshift-release-dev/ocp-release" >> install-config.yaml $ echo "- mirrors:" >> install-config.yaml $ echo " - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml $ echo " source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml
참고registry.example.com
을 레지스트리의 정규화된 도메인 이름으로 바꿉니다.
10.3.8. 작업자 노드에 라우터 배치
설치 중에 설치 프로그램은 작업자 노드에 라우터 pod를 배포합니다. 기본적으로 설치 프로그램은 두 개의 라우터 pod를 설치합니다. 초기 클러스터에 작업자 노드가 하나만 있거나 배포된 클러스터에서 OpenShift Container Platform 클러스터 내의 서비스에 대해 외부 트래픽 로드를 처리하기 위해 추가 라우터가 필요한 경우 yaml
파일을 작성하여 적절한 라우터 복제 수를 설정할 수 있습니다.
기본적으로 설치 프로그램은 두 개의 라우터를 배포합니다. 클러스터에 작업자 노드가 두 개 이상있는 경우 이 섹션을 생략할 수 있습니다.
클러스터에 작업자 노드가 없는 경우 설치 프로그램은 기본적으로 컨트롤 플레인 노드에 두 개의 라우터를 배포합니다. 클러스터에 작업자 노드가없는 경우 이 섹션을 생략할 수 있습니다.
프로세스
router-replicas.yaml
파일을 만듭니다.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: <num-of-router-pods> endpointPublishingStrategy: type: HostNetwork nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/worker: ""
참고<num-of-router-pods>
를 적절한 값으로 바꿉니다. 하나의 작업자 노드로만 작업하는 경우replicas :
를1
로 설정합니다. 3 개 이상의 작업자 노드로 작업하는 경우 필요에 따라replicas:
을 기본값2
에서 늘릴 수 있습니다.router-replicas.yaml
파일을clusterconfigs/openshift
디렉터리에 저장 및 복사합니다.cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml
10.3.9. 설치 확인 체크리스트
- ❏ OpenShift Container Platform 설치 프로그램이 검색되었습니다.
- ❏ OpenShift Container Platform 설치 프로그램이 추출되었습니다.
-
❏
install-config.yaml
의 필수 매개 변수가 설정되었습니다. -
❏
install-config.yaml
의hosts
매개 변수가 구성되었습니다. -
❏
install-config.yaml
의bmc
매개 변수가 구성되었습니다. -
❏
bmc
address
필드에 구성된 값에 대한 규칙이 적용되었습니다. - ❏ 비 연결 레지스트리를 생성했습니다 (선택 사항).
- ❏ (선택 사항) 비 연결 레지스트리 설정을 사용하고 있는 경우 이를 확인합니다.
- ❏ (선택 사항) 작업자 노드에 라우터를 배포했습니다.
10.3.10. OpenShift Container Platform 설치 프로그램을 통해 클러스터 배포
OpenShift Container Platform 설치 프로그램을 실행합니다.
$ ./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster
10.3.11. 설치 후
배포 프로세스 중에 설치 디렉터리 폴더의 .openshift_install.log
로그 파일에 tail
명령을 실행하여 설치의 전체 상태를 확인할 수 있습니다.
$ tail -f /path/to/install-dir/.openshift_install.log
10.3.12. 고정 IP 주소 구성 확인
클러스터 노드의 DHCP 예약에서 무한 리스를 지정하는 경우 설치 프로그램이 노드를 성공적으로 프로비저닝한 후 디스패치 스크립트에서 노드의 네트워크 구성을 확인합니다. 스크립트에서 네트워크 구성에 무한 DHCP 리스가 포함되어 있음을 확인하면 DHCP 리스의 IP 주소를 고정 IP 주소로 사용하여 새 연결을 생성합니다.
클러스터에 있는 다른 노드의 프로비저닝이 진행되는 동안 디스패치 스크립트는 성공적으로 프로비저닝된 노드에서 실행될 수 있습니다.
네트워크 구성이 제대로 작동하는지 확인합니다.
프로세스
- 노드의 네트워크 인터페이스 구성을 확인합니다.
- DHCP 서버를 끄고 OpenShift Container Platform 노드를 재부팅하고 네트워크 구성이 제대로 작동하는지 확인합니다.
추가 리소스
- 다양한 릴리스 채널에 대한 자세한 내용은 OpenShift Container Platform 업그레이드 채널 및 릴리스를 참조하십시오.