10.3. OpenShift 설치를 위한 환경 설정


10.3.1. 프로비저너 노드에 RHEL 설치

네트워킹 구성이 완료되면 다음 단계는 프로비저너 노드에 RHEL 8.x를 설치하는 것입니다. 설치 프로그램은 OpenShift Container Platform 클러스터를 설치하는 동안 프로비저너 노드를 오케스트레이터로 사용합니다. 이 문서에서는 프로비저너 노드에 RHEL을 설치하는 것은 다루지 않습니다. 선택 옵션에는 RHEL Satellite 서버, PXE 또는 설치 미디어 사용이 포함되지어 있지만 이에 국한되지는 않습니다.

10.3.2. OpenShift Container Platform 설치를 위한 provisioner 노드 준비

환경을 준비하려면 다음 단계를 수행하십시오.

프로세스

  1. ssh를 통해 프로비저너 노드에 로그인합니다.
  2. 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
  3. 새 사용자에 대한 ssh 키를 만듭니다.

    # su - kni -c "ssh-keygen -t ed25519 -f /home/kni/.ssh/id_rsa -N ''"
  4. 프로비저너 노드에서 새 사용자로 로그인합니다.

    # su - kni
    $
  5. 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에서 참조하십시오.

  6. 다음 패키지를 설치합니다.

    $ sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool
  7. 사용자를 변경하여 libvirt 그룹을 새로 만든 사용자에 추가합니다.

    $ sudo usermod --append --groups libvirt <user>
  8. firewalld를 다시 시작하고 http 서비스를 활성화합니다.

    $ sudo systemctl start firewalld
    $ sudo firewall-cmd --zone=public --add-service=http --permanent
    $ sudo firewall-cmd --reload
  9. libvirtd 서비스를 시작하고 활성화합니다.

    $ sudo systemctl enable libvirtd --now
  10. 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
  11. 네트워킹을 설정합니다.

    참고

    웹 콘솔에서 네트워킹을 구성할 수도 있습니다.

    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 프로토콜로 설정되어 있는지 확인하십시오.

  12. provisioning 네트워크 연결에서 IPv4 주소를 구성합니다.

    $ nmcli connection modify provisioning ipv4.addresses 172.22.0.254/24 ipv4.method manual
  13. provisioner 노드로 ssh를 실행합니다 (필요한 경우).

    # ssh kni@provisioner.<cluster-name>.<domain>
  14. 연결 브리지가 제대로 생성되었는지 확인합니다.

    $ 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
  15. 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 설치 프로그램 추출

설치 프로그램을 가져온 후 다음 단계로 압축을 풉니다.

프로세스

  1. 환경 변수를 설정합니다.

    $ export cmd=openshift-baremetal-install
    $ export pullsecret_file=~/pull-secret.txt
    $ export extract_dir=$(pwd)
  2. oc 바이너리를 가져옵니다.

    $ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc
  3. 설치 프로그램 압축을 풉니다.

    $ 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 분 이상 걸리는 경우 설치 프로그램이 시간 초과됩니다. 이러한 경우 웹 서버에서 이미지를 캐시할 수 있습니다.

이미지가 포함된 컨테이너를 설치합니다.

프로세스

  1. podman을 설치합니다.

    $ sudo dnf install -y podman
  2. RHCOS 이미지 캐싱에 사용할 방화벽 포트 8080 을 엽니다.

    $ sudo firewall-cmd --add-port=8080/tcp --zone=public --permanent
    $ sudo firewall-cmd --reload
  3. bootstraposimageclusterosimage를 저장할 디렉터리를 만듭니다.

    $ mkdir /home/kni/rhcos_image_cache
  4. 새로 생성된 디렉터리에 적절한 SELinux 컨텍스트를 설정합니다.

    $ sudo semanage fcontext -a -t httpd_sys_content_t "/home/kni/rhcos_image_cache(/.*)?"
    $ sudo restorecon -Rv /home/kni/rhcos_image_cache/
  5. 설치 프로그램이 부트스트랩 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')
  6. 설치 프로그램이 부트스트랩 VM에 배포할 이미지의 이름을 가져옵니다.

    $ export export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
  7. 노드에 배포되는 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"]')
  8. 설치 프로그램이 클러스터 노드에 배포할 이미지의 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')
  9. 설치 프로그램이 클러스터 노드에 배포할 이미지의 이름을 가져옵니다.

    $ export RHCOS_OPENSTACK_NAME=${RHCOS_OPENSTACK_URI##*/}
  10. 설치 프로그램이 클러스터 노드에 배포할 이미지의 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"]')
  11. 이미지를 다운로드하여 /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}
  12. SELinux 유형이 새로 생성된 파일의 httpd_sys_content_t임을 확인합니다.

    $ ls -Z /home/kni/rhcos_image_cache
  13. 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입니다.

  14. bootstrapOSImageclusterOSImage 구성을 만듭니다.

    $ 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}"
  15. platform.baremetal 아래의 install-config.yaml 파일에 필요한 구성을 추가합니다.

    platform:
      baremetal:
        bootstrapOSImage: <bootstrap_os_image>  1
        clusterOSImage: <cluster_os_image>  2
    1
    & lt;bootstrap_os_image >를 $BOOTSTRAP_OS_IMAGE 값으로 바꿉니다.
    2
    & lt;cluster_os_image& gt;를 $CLUSTER_OS_IMAGE 값으로 바꿉니다.

    자세한 내용은 "구성 파일" 섹션을 참조하십시오.

10.3.6. 구성 파일

10.3.6.1. install-config.yaml 파일을 생성합니다.

install-config.yaml 파일에는 몇 가지 추가 정보가 필요합니다. 대부분의 정보는 설치된 클러스터가 사용 가능한 하드웨어를 완벽하게 관리하는 데 필요한 정보를 충분히 갖도록 설치 프로세스를 안내하는 데 사용됩니다.

  1. install-config.yaml을 설정합니다. pullSecretsshKey 등 환경에 맞게 적절한 변수를 변경합니다.

    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 값의 유효한 옵션은 02 보다 크거나 같은 정수입니다. 세 개의 컨트롤 플레인 시스템만 포함된 3 노드 클러스터를 배포하려면 복제본 수를 0 으로 설정합니다. 3-노드 클러스터는 테스트, 개발 및 프로덕션에 사용할 수 있는 더 작고 리소스 효율적인 클러스터입니다. 작업자가 하나만 있는 클러스터를 설치할 수 없습니다.
    2 4 6 8
    자세한 옵션은 BMC 주소 지정 섹션을 참조하십시오.
    3 5 7 9
    설치 디스크 드라이브의 경로를 설정합니다(예: /dev/disk/by-id/wwn-0x64cd98f04fde100024684cf3034da5c2 ).
  2. 클러스터 설정을 저장할 디렉터리를 만듭니다.

    $ mkdir ~/clusterconfigs
    $ cp install-config.yaml ~/clusterconfigs
  3. OpenShift Container Platform 클러스터를 설치하기 전에 모든 베어 메탈 노드의 전원이 꺼져 있는지 확인합니다.

    $ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
  4. 이전 배포 시도에서 이전 부트스트랩 리소스가 남아 있는 경우 이전 부트스트랩 리소스를 삭제합니다.

    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 또는 idrac-virtualmedia 와 같은 가상 미디어 BMC 주소 지정 옵션을 사용해야 합니다. 자세한 내용은 "HPE iLO용 BMC 주소 지정" 섹션의 "Redfish virtual media for HPE iLO"를 참조하거나 "Dell iDRAC용 BMC 주소 지정" 섹션의 "Redfish virtual media for Dell iDRAC" 섹션을 참조하십시오.

10.3.6.4. 이중 스택 네트워크의 install-config.yaml 파일 변경 (선택 사항)

듀얼 스택 네트워킹으로 OpenShift Container Platform 클러스터를 배포하려면 install-config.yaml 파일에서 machineNetwork,clusterNetwork 및 serviceNetwork 구성 설정을 편집합니다. 각 설정에는 각각 두 개의 CIDR 항목이 있어야 합니다. 첫 번째 CIDR 항목이 IPv4 설정이며 두 번째 CIDR 항목이 IPv6 설정인지 확인합니다.

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-virtualmedia 와 같은 Redfish BMC 주소 지정을 사용하여 설치 관리자 프로비저닝 클러스터를 배포할 때 관리형 Secure Boot를 활성화할 수 있습니다. 관리형 Secure Boot를 활성화하려면 각 노드에 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

1
the bmc.address 설정이 redfish, redfish -virtualmedia 또는 idrac-virtualmedia를 프로토콜로 사용하는지 확인합니다. 자세한 내용은 "HPE iLO용 BMC 주소 지정" 또는 "Dell iDRAC의 BMC 주소 지정"을 참조하십시오.
2
bootMode 설정의 기본값은 UEFI입니다. 이 파일을 UEFISecureBoot로 변경하여 관리되는 Secure Boot를 활성화합니다.
참고

노드가 관리형 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 매개 변수는 다음 표를 참조하십시오.

표 10.3. 필수 매개 변수
매개 변수기본설명

baseDomain

 

클러스터의 도메인 이름입니다. 예: example.com

bootMode

UEFI

노드의 부팅 모드입니다. 옵션은 legacy, UEFIUEFISecureBoot입니다. bootMode가 설정되지 않은 경우 Ironic은 노드를 검사하는 동안 해당 노드를 설정합니다.

sshKey

 

sshKey 구성 설정에는 컨트롤 플레인 노드 및 작업자 노드에 액세스하는 데 필요한 ~/.ssh/id_rsa.pub 파일의 키가 포함되어 있습니다. 일반적으로 이 키는 provisioner 노드에서 가져옵니다.

pullSecret

 

pullSecret 구성 설정에는 프로비저너 노드를 준비할 때 Install OpenShift on Bare Metal 페이지에서 다운로드한 풀 시크릿 사본이 포함되어 있습니다.

metadata:
    name:
 

OpenShift Container Platform 클러스터에 지정되는 이름입니다. 예: openshift

networking:
    machineNetwork:
    - cidr:
 

외부 네트워크의 공개 CIDR (Classless Inter-Domain Routing)입니다. 예: 10.0.0.0/24

compute:
  - name: worker
 

OpenShift Container Platform 클러스터에는 노드가 없는 경우에도 작업자 (또는 컴퓨팅) 노드에 이름을 지정해야 합니다.

compute:
    replicas: 2
 

복제는 OpenShift Container Platform 클러스터의 작업자 (또는 컴퓨팅) 노드 수를 설정합니다.

controlPlane:
    name: master
 

OpenShift Container Platform 클러스터에는 컨트롤 플레인 (마스터) 노드의 이름이 필요합니다.

controlPlane:
    replicas: 3
 

복제는 OpenShift Container Platform 클러스터의 일부로 포함된 컨트롤 플레인 (마스터) 노드의 수를 설정합니다.

provisioningNetworkInterface

 

provisioning 네트워크에 연결된 노드의 네트워크 인터페이스 이름입니다. OpenShift Container Platform 4.9 이상 릴리스의 경우 bootMACAddress 구성 설정을 사용하여 NIC 이름을 식별하는 대신 provisioningNetworkInterface 구성 설정을 사용하는 대신 NIC의 IP 주소를 식별할 수 있도록 Ironic을 활성화합니다.

defaultMachinePlatform

 

플랫폼 구성없이 머신 풀에 사용되는 기본 설정입니다.

apiVIP

 

(선택 사항) Kubernetes API 통신의 가상 IP 주소입니다.

이 설정은 install-config.yaml 파일에서 MachineNetwork에서 예약된 IP로 제공되거나 기본 이름이 올바르게 확인되도록 DNS에서 사전 구성해야 합니다. install-config.yaml 파일의 apiVIP 구성 설정에 값을 추가할 때 FQDN이 아닌 가상 IP 주소를 사용합니다. 듀얼 스택 네트워킹을 사용하는 경우 IP 주소는 기본 IPv4 네트워크에서여야 합니다. 설정하지 않으면 설치 프로그램에서 api.<cluster_name>.<base_domain> 을 사용하여 DNS에서 IP 주소를 파생합니다.

disableCertificateVerification

False

redfishredfish-virtualmedia 는 BMC 주소를 관리하기 위해 이 매개 변수가 필요합니다. BMC 주소에 자체 서명된 인증서를 사용하는 경우 값은 True 여야합니다.

ingressVIP

 

(선택 사항) 수신 트래픽의 가상 IP 주소입니다.

이 설정은 install-config.yaml 파일에서 MachineNetwork에서 예약된 IP로 제공되거나 기본 이름이 올바르게 확인되도록 DNS에서 사전 구성해야 합니다. install-config.yaml 파일의 ingressVIP 구성 설정에 값을 추가할 때 FQDN이 아닌 가상 IP 주소를 사용합니다. 듀얼 스택 네트워킹을 사용하는 경우 IP 주소는 기본 IPv4 네트워크에서여야 합니다. 설정되지 않은 경우 설치 프로그램은 test.apps.<cluster_name>.<base_domain> 을 사용하여 DNS에서 IP 주소를 파생합니다.

표 10.4. 선택적 매개변수
매개 변수기본설명

provisioningDHCPRange

172.22.0.10,172.22.0.100

provisioning 네트워크에서 노드의 IP 범위를 정의합니다.

provisioningNetworkCIDR

172.22.0.0/24

프로비저닝에 사용할 네트워크의 CIDR입니다. 이 옵션은 provisioning 네트워크에서 기본 주소 범위를 사용하지 않는 경우에 필요합니다.

clusterProvisioningIP

provisioningNetworkCIDR의 세 번째 IP 주소입니다.

프로비저닝 서비스가 실행되는 클러스터 내의 IP 주소입니다. 기본값은 provisioning 서브넷의 세 번째 IP 주소입니다. 예: 172.22.0.3

bootstrapProvisioningIP

provisioningNetworkCIDR의 두 번째 IP 주소입니다.

설치 프로그램이 컨트롤 플레인 (마스터) 노드를 배포하는 동안 프로비저닝 서비스가 실행되는 부트스트랩 VM의 IP 주소입니다. 기본값은 provisioning 서브넷의 두 번째 IP 주소입니다. 예를 들면 172.22.0.2 또는 2620:52:0:1307::2 입니다.

externalBridge

baremetal

baremetal 네트워크에 연결된 하이퍼 바이저의 baremetal 브리지 이름입니다.

provisioningBridge

provisioning

provisioning 네트워크에 연결된 provisioner 호스트의 provisioning 브리지 이름입니다.

defaultMachinePlatform

 

플랫폼 구성없이 머신 풀에 사용되는 기본 설정입니다.

bootstrapOSImage

 

부트스트랩 노드의 기본 운영 체제 이미지를 재정의하는 URL입니다. URL에는 이미지의 SHA-256 해시가 포함되어 있어야합니다. 예: https://mirror.openshift.com/rhcos-<version>-qemu.qcow2.gz?sha256=<uncompressed_sha256 > .

clusterOSImage

 

클러스터 노드의 기본 운영 체제를 재정의하는 URL입니다. URL에는 이미지의 SHA-256 해시가 포함되어 있어야 합니다. 예: https://mirror.openshift.com/images/rhcos-<version>-openstack.qcow2.gz?sha256=<compressed_sha256>.

provisioningNetwork

 

provisioningNetwork 구성 설정은 클러스터가 provisioning 네트워크를 사용하는지 여부를 결정합니다. 이 기능이 있는 경우 구성 설정은 클러스터가 네트워크를 관리하는지도 결정합니다.

disabled: provisioning 네트워크의 요구 사항을 비활성화하려면 이 매개변수를 Disabled 로 설정합니다. Disabled(비활성화됨 )로 설정하는 경우 가상 미디어 기반 프로비저닝만 사용하거나 지원 설치 프로그램을 사용하여 클러스터를 가져와야 합니다. Disabled 및 power management를 사용하는 경우 baremetal 네트워크에서 BMC에 액세스할 수 있어야 합니다. Disabled 인 경우 프로비저닝 서비스에 사용되는 baremetal 네트워크에 두 개의 IP 주소를 제공해야 합니다.

Managed: DHCP, TFTP 등을 포함한 프로비저닝 네트워크를 완전히 관리하려면 이 매개 변수를 기본값인 Managed 로 설정합니다.

Unmanaged: 이 매개변수를 Unmanaged 로 설정하여 프로비저닝 네트워크를 활성화하지만 DHCP 수동 구성을 처리합니다. 가상 미디어의 프로비저닝이 권장되지만 필요한 경우 PXE를 계속 사용할 수 있습니다.

httpProxy

 

이 매개 변수를 환경 내에서 사용되는 적절한 HTTP 프록시로 설정합니다.

httpsProxy

 

이 매개 변수를 환경 내에서 사용되는 적절한 HTTPS 프록시로 설정합니다.

noProxy

 

이 매개 변수를 환경 내 프록시 사용에 대한 적절한 예외 목록으로 설정합니다.

호스트

hosts 매개 변수는 클러스터를 빌드하는 데 사용되는 별도의 베어 메탈 자산 목록입니다.

표 10.5. 호스트
이름기본설명

name

 

세부 정보와 연결할 BareMetalHost 리소스의 이름입니다. 예: openshift-master-0

role

 

베어 메탈 노드의 역할입니다. master 또는 worker 중 하나입니다.

bmc

 

베이스 보드 관리 컨트롤러에 대한 연결 세부 정보입니다. 자세한 내용은 BMC 주소 지정 섹션을 참조하십시오.

bootMACAddress

 

호스트가 provisioning 네트워크에 사용하는 NIC의 MAC 주소입니다. Ironic은 bootMACAddress 구성 설정을 사용하여 IP 주소를 검색합니다. 그런 다음 호스트에 바인딩됩니다.

참고

provisioning 네트워크를 비활성화한 경우 호스트에서 유효한 MAC 주소를 제공해야 합니다.

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 또는 idrac-virtualmedia 와 같은 가상 미디어 BMC 주소 지정 옵션을 사용해야 합니다. 자세한 내용은 "HPE iLO용 BMC 주소 지정" 섹션의 "Redfish virtual media for HPE iLO"를 참조하거나 "Dell iDRAC용 BMC 주소 지정" 섹션의 "Redfish virtual media for Dell iDRAC" 섹션을 참조하십시오.

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 가상 미디어

idrac-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/System.Embedded.1

Redfish 네트워크 부팅

redfish://<out-of-band-ip>/redfish/v1/Systems/System.Embedded.1

IPMI

ipmi://<out-of-band-ip>

중요

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 로 설정합니다. 메뉴 경로는 설정 가상 콘솔 플러그인 유형 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 로 설정합니다. 메뉴 경로는 설정 가상 콘솔 플러그인 유형 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를 지원합니다.

표 10.6. HPE iLO의 BMC 주소 형식
프로토콜주소 형식

RedFish 가상 미디어

redfish-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/1

Redfish 네트워크 부팅

redfish://<out-of-band-ip>/redfish/v1/Systems/1

IPMI

ipmi://<out-of-band-ip>

자세한 내용은 다음 섹션을 참조하십시오.

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를 지원합니다.

표 10.7. Fujitsu iRMC의 BMC 주소 형식
프로토콜주소 형식

iRMC

irmc://<out-of-band-ip>

IPMI

ipmi://<out-of-band-ip>

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) 이미지를 특정 장치에 프로비저닝할 수 있습니다. 설치 프로그램은 장치를 검색한 순서대로 검사하고 검색된 값을 팁과 비교합니다. 설치 프로그램은 팁과 일치하는 첫 번째 검색된 장치를 사용합니다. 이 설정은 여러 팁을 결합할 수 있지만 장치는 설치 프로그램이이를 선택할 수 있도록 모든 팁과 일치해야 합니다.

표 10.8. 서브 필드
서브 필드설명

deviceName

/dev/vda와 같은 Linux 장치 이름을 포함하는 문자열. 팁은 실제 값과 정확히 일치해야 합니다.

hctl

0:0:0:0과 같은 SCSI 버스 주소를 포함하는 문자열. 팁은 실제 값과 정확히 일치해야 합니다.

model

공급 업체별 장치 식별자가 포함된 문자열. 팁은 실제 값의 하위 문자열입니다.

vendor

장치의 공급 업체 또는 제조업체 이름이 포함된 문자열입니다. 팁은 실제 값의 하위 문자열입니다.

serialNumber

장치 일련 번호가 포함된 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.

minSizeGigabytes

장치의 최소 크기 (기가 바이트)를 나타내는 정수입니다.

wwn

고유 저장소 식별자를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.

wwnWithExtension

공급 업체 확장이 추가된 고유 한 저장소 식별자가 포함된 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.

wwnVendorExtension

고유 공급 업체 저장소 식별자를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.

rotational

장치가 회전 디스크 여야하는지 (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 매니페스트 만들기

  1. 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 서버에 액세스할 수 없습니다.

절차

  1. 컨트롤 플레인 노드에 대한 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>을 정규화된 도메인 이름으로 교체해야 합니다.
  2. Butane을 사용하여 컨트롤 플레인 노드에 전달할 구성이 포함된 MachineConfig 파일 99-master-chrony-conf-override.yaml을 생성합니다.

    $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
  3. 컨트롤 플레인 노드의 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>을 정규화된 도메인 이름으로 교체해야 합니다.
  4. 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 주소를 컨트롤 플레인 노드 전용으로 배치해야 합니다.

절차

  1. install-config.yaml 파일을 저장하는 디렉터리로 변경합니다.

    $ cd ~/clusterconfigs
  2. manifests 하위 디렉터리로 전환합니다.

    $ cd manifests
  3. cluster-network-avoid-workers-99-config.yaml이라는 파일을 생성합니다.

    $ touch cluster-network-avoid-workers-99-config.yaml
  4. 편집기에서 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
  5. cluster-network-avoid-workers-99-config.yaml 파일을 저장합니다.
  6. 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: ""
  7. manifests 디렉터리를 백업하는 것이 좋습니다. 설치 프로그램은 클러스터를 생성할 때 manifests/ 디렉터리를 삭제합니다.
  8. 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를 구성합니다.

절차

  1. 매니페스트를 생성합니다.
  2. 작업자에 해당하는 BMH 파일을 수정합니다.

    $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-3.yaml
  3. BMH 파일의 spec 섹션에 BIOS 구성을 추가합니다.

    spec:
      firmware:
        simultaneousMultithreadingEnabled: true
        sriovEnabled: true
        virtualizationEnabled: true
    참고
    1. Red Hat은 다음 세 가지 BIOS 설정을 지원합니다. 자세한 내용은 BMH 설명서 를 참조하십시오. bmc 유형 irmc 가 있는 서버만 지원됩니다. 다른 유형의 서버는 현재 지원되지 않습니다.
  4. 클러스터 생성.

10.3.7. 비 연결 레지스트리 만들기 (선택 사항)

설치 레지스트리의 로컬 사본을 사용하여 OpenShift Container Platform 클러스터를 설치해야하는 경우가 있습니다. 이는 클러스터 노드가 인터넷에 액세스할 수 없는 네트워크에 있기 때문에 네트워크 효율성을 향상시키기 위한 것일 수 있습니다.

로컬 또는 미러링된 레지스트리 사본에는 다음이 필요합니다.

  • 레지스트리 노드의 인증서. 자체 서명된 인증서를 사용할 수 있습니다.
  • 시스템의 컨테이너가 제공할 웹 서버입니다.
  • 인증서 및 로컬 저장소 정보를 포함하는 업데이트된 풀 시크릿.
참고

레지스트리 노드에 연결되지 않은 레지스트리를 만드는 것은 선택 사항입니다. 다음 섹션은 선택 사항으로 레지스트리 노드에 연결되지 않은 레지스트리를 만드는 경우에만 실행해야 하는 단계입니다. 레지스트리 노드에 연결되지 않은 레지스트리를 만들 때 "(선택 사항)"레이블이 붙은 모든 후속 하위 섹션을 실행해야 합니다.

10.3.7.1. 미러링된 레지스트리를 호스팅할 레지스트리 노드 준비 (선택 사항)

레지스트리 노드를 다음과 같이 변경합니다.

절차

  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
  2. 레지스트리 노드에 필요한 패키지를 설치합니다.

    $ sudo yum -y install python3 podman httpd httpd-tools jq
  3. 저장소 정보가 보관될 디렉터리 구조를 만듭니다.

    $ sudo mkdir -p /opt/registry/{auth,certs,data}

10.3.7.2. 자체 서명 인증서 생성 (선택 사항)

레지스트리 노드의 자체 서명된 인증서를 생성하고 이를 /opt/registry/certs 디렉터리에 배치합니다.

절차

  1. 인증서 정보를 적절하게 조정합니다.

    $ 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

  2. 새 인증서로 레지스트리 노드의 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 파일이 필요합니다.

절차

  1. 컨테이너에서 사용할 htpasswd 파일을 /opt/registry/auth에 만듭니다.

    $ htpasswd -bBc /opt/registry/auth/htpasswd <user> <passwd>

    <user>를 사용자 이름으로, <passwd>를 암호로 바꿉니다.

  2. 레지스트리 컨테이너를 만들고 시작합니다.

    $ 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) 복사 및 업데이트 (선택 사항)

프로비저너 노드에서 레지스트리 노드로 풀 시크릿 파일을 복사하고 이를 새 레지스트리 노드의 인증 정보를 포함하도록 변경합니다.

절차

  1. pull-secret.txt 파일을 복사합니다.

    $ scp kni@provisioner:/home/kni/pull-secret.txt pull-secret.txt
  2. host_fqdn 환경 변수를 레지스트리 노드의 완전한 도메인 이름으로 업데이트합니다.

    $ host_fqdn=$( hostname --long )
  3. htpasswd 파일을 만드는 데 사용되는 http 인증 정보의 base64 인코딩으로 b64auth 환경 변수를 업데이트합니다.

    $ b64auth=$( echo -n '<username>:<passwd>' | openssl base64 )

    <username>을 사용자 이름으로, <passwd>를 암호로 바꿉니다.

  4. base64 승인 문자열을 사용하도록 AUTHSTRING 환경 변수를 설정합니다. $USER 변수는 현재 사용자의 이름을 포함하는 환경 변수입니다.

    $ AUTHSTRING="{\"$host_fqdn:5000\": {\"auth\": \"$b64auth\",\"email\": \"$USER@redhat.com\"}}"
  5. pull-secret.txt 파일을 업데이트합니다.

    $ jq ".auths += $AUTHSTRING" < pull-secret.txt > pull-secret-update.txt

10.3.7.5. 저장소 미러링 (선택 사항)

프로세스

  1. 프로비저너 노드에서 레지스트리 노드에 oc 바이너리를 복사합니다.

    $ sudo scp kni@provisioner:/usr/local/bin/oc /usr/local/bin
  2. 필요한 환경 변수를 설정합니다.

    1. 릴리스 버전을 설정합니다.

      $ VERSION=<release_version>

      <release_version> 에 대해 설치할 OpenShift Container Platform 버전에 해당하는 태그를 지정합니다 (예: 4.9 ).

    2. 로컬 레지스트리 이름 및 호스트 포트를 설정합니다.

      $ LOCAL_REG='<local_registry_host_name>:<local_registry_host_port>'

      <local_registry_host_name>의 경우 미러 저장소의 레지스트리 도메인 이름을 지정하고 <local_registry_host_port>의 경우 콘텐츠를 제공하는데 사용되는 포트를 지정합니다.

    3. 로컬 리포지터리 이름을 설정합니다.

      $ LOCAL_REPO='<local_repository_name>'

      <local_repository_name>의 경우 레지스트리에 작성할 저장소 이름 (예: ocp4/openshift4)을 지정합니다.

  3. 원격 설치 이미지를 로컬 저장소에 미러링합니다.

    $ /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 파일에는 연결되지 않은 레지스트리 노드 인증서 및 레지스트리 정보도 포함되어야합니다.

프로세스

  1. 비 연결 레지스트리 노드의 인증서를 install-config.yaml 파일에 추가합니다. 인증서는 "additionalTrustBundle:|" 뒤에 있어야 하며 보통 두 개의 공백으로 적절하게 들여 쓰기합니다.

    $ echo "additionalTrustBundle: |" >> install-config.yaml
    $ sed -e 's/^/  /' /opt/registry/certs/domain.crt >> install-config.yaml
  2. 레지스트리의 미러 정보를 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 파일을 작성하여 적절한 라우터 복제 수를 설정할 수 있습니다.

참고

기본적으로 설치 프로그램은 두 개의 라우터를 배포합니다. 클러스터에 작업자 노드가 두 개 이상있는 경우 이 섹션을 생략할 수 있습니다.

참고

클러스터에 작업자 노드가 없는 경우 설치 프로그램은 기본적으로 컨트롤 플레인 노드에 두 개의 라우터를 배포합니다. 클러스터에 작업자 노드가없는 경우 이 섹션을 생략할 수 있습니다.

프로세스

  1. 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에서 늘릴 수 있습니다.

  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.yamlhosts 매개 변수가 구성되었습니다.
  • install-config.yamlbmc 매개 변수가 구성되었습니다.
  • 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 주소로 사용하여 새 연결을 생성합니다.

참고

클러스터에 있는 다른 노드의 프로비저닝이 진행되는 동안 디스패치 스크립트는 성공적으로 프로비저닝된 노드에서 실행될 수 있습니다.

네트워크 구성이 제대로 작동하는지 확인합니다.

프로세스

  1. 노드의 네트워크 인터페이스 구성을 확인합니다.
  2. DHCP 서버를 끄고 OpenShift Container Platform 노드를 재부팅하고 네트워크 구성이 제대로 작동하는지 확인합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.