8.3. OpenShift インストールの環境のセットアップ

8.3.1. RHEL のプロビジョナーノードへのインストール

ネットワーク設定が完了すると、次の手順では、プロビジョナーノードに RHEL 8.x をインストールします。インストーラーは、OpenShift Container Platform クラスターをインストールする間にプロビジョナーノードをオーケレーターとして使用します。本書の目的上、RHEL のプロビジョナーノードへのインストールは対象外です。ただし、オプションには、RHEL Satellite サーバー、PXE、またはインストールメディアの使用も含まれますが、これらに限定されません。

8.3.2. OpenShift Container Platform インストールのプロビジョナーノードの準備

環境を準備するには、以下の手順を実行します。

手順

  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. ネットワークの設定

    注記

    Web コンソールからネットワークを設定することもできます。

    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
        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 接続が切断される可能性があります。

    IPv6 アドレスには、baremetal ネットワーク経由でルーティング可能でない限り、任意のアドレスを使用できます。

    IPv6 アドレスを使用する場合に UEFI PXE 設定が有効にされており、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

    Web ブラウザーで、Install OpenShift on Bare Metal with installer-provisioned infrastructure に移動し、Downloads セクションまでスクロールダウンします。Copy pull secret をクリックします。pull-secret.txt ファイルにコンテンツを貼り付け、そのコンテンツを kni ユーザーのホームディレクトリーに保存します。

8.3.3. OpenShift Container Platform インストーラーの取得

インストーラーの latest-4.x バージョンを使用して、OpenShift Container Platform の最新の一般公開バージョンをデプロイします。

$ export VERSION=latest-4.7
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}')

関連情報

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

8.3.5. RHCOS イメージキャッシュの作成 (オプション)

イメージのキャッシュを使用するには、ブートストラップ仮想マシンによって使用される Red Hat Enterprise Linux CoreOS (RHCOS) イメージと、異なるノードをプロビジョニングするためにインストーラーによって使用される RHCOS イメージという 2 つのイメージをダウンロードする必要があります。イメージのキャッシュはオプションですが、帯域幅が制限されたネットワークでインストーラーを実行する場合にとくに役立ちます。

帯域幅が制限されたネットワークでインストーラーを実行し、RHCOS イメージのダウンロードに 15 分から 20 分を超える時間がかかる場合、インストーラーはタイムアウトします。このような場合、Web サーバーでイメージをキャッシュすることができます。

イメージが含まれるコンテナーをインストールするには、以下の手順に従います。

  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. bootstraposimage および clusterosimage を保存するディレクトリーを作成します。

    $ 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 rhcos_image_cache/
  5. インストーラーからコミット ID を取得します。ID は、インストーラーがダウンロードする必要のあるイメージを判別します。

    $ export COMMIT_ID=$(/usr/local/bin/openshift-baremetal-install version | grep '^built from commit' | awk '{print $4}')
  6. インストーラーがノードにデプロイする RHCOS イメージの URI を取得します。

    $ export RHCOS_OPENSTACK_URI=$(curl -s -S https://raw.githubusercontent.com/openshift/installer/$COMMIT_ID/data/data/rhcos.json  | jq .images.openstack.path | sed 's/"//g')
  7. インストーラーがブートストラップ仮想マシンにデプロイする RHCOS イメージの URI を取得します。

    $ export RHCOS_QEMU_URI=$(curl -s -S https://raw.githubusercontent.com/openshift/installer/$COMMIT_ID/data/data/rhcos.json  | jq .images.qemu.path | sed 's/"//g')
  8. イメージが公開されるパスを取得します。

    $ export RHCOS_PATH=$(curl -s -S https://raw.githubusercontent.com/openshift/installer/$COMMIT_ID/data/data/rhcos.json | jq .baseURI | sed 's/"//g')
  9. ブートストラップ仮想マシンにデプロイされる RHCOS イメージの SHA ハッシュを取得します。

    $ export RHCOS_QEMU_SHA_UNCOMPRESSED=$(curl -s -S https://raw.githubusercontent.com/openshift/installer/$COMMIT_ID/data/data/rhcos.json  | jq -r '.images.qemu["uncompressed-sha256"]')
  10. ノードにデプロイされる RHCOS イメージの SHA ハッシュを取得します。

    $ export RHCOS_OPENSTACK_SHA_COMPRESSED=$(curl -s -S https://raw.githubusercontent.com/openshift/installer/$COMMIT_ID/data/data/rhcos.json  | jq -r '.images.openstack.sha256')
  11. イメージをダウンロードして、それらを /home/kni/rhcos_image_cache ディレクトリーに配置します。

    $ curl -L ${RHCOS_PATH}${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_URI}
    $ curl -L ${RHCOS_PATH}${RHCOS_OPENSTACK_URI} -o /home/kni/rhcos_image_cache/${RHCOS_OPENSTACK_URI}
  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

8.3.6. 設定ファイル

8.3.6.1. install-config.yaml ファイルの設定

install-config.yaml ファイルには、追加の詳細情報が必要です。それらの情報のほとんどは、インストーラーおよび結果として作成されるクラスターが利用可能なハードウェアを完全に管理するのに必要な利用可能なハードウェアについての十分な情報として提供されます。

  1. install-config.yaml を設定します。pullSecret および sshKey など、環境に合わせて適切な変数を変更します。

    apiVersion: v1
    baseDomain: <domain>
    metadata:
      name: <cluster-name>
    networking:
      machineCIDR: <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>
        provisioningNetworkInterface: <NIC1>
        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>
            hardwareProfile: default
          - name: <openshift-master-1>
            role: master
            bmc:
              address: ipmi://<out-of-band-ip> 3
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            hardwareProfile: default
          - name: <openshift-master-2>
            role: master
            bmc:
              address: ipmi://<out-of-band-ip> 4
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            hardwareProfile: default
          - name: <openshift-worker-0>
            role: worker
            bmc:
              address: ipmi://<out-of-band-ip> 5
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            hardwareProfile: unknown
          - name: <openshift-worker-1>
            role: worker
            bmc:
              address: ipmi://<out-of-band-ip>
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            hardwareProfile: unknown
    pullSecret: '<pull_secret>'
    sshKey: '<ssh_pub_key>'
    1
    OpenShift Container Platform クラスターの一部であるワーカーノードの数に基づいてワーカーマシンをスケーリングします。
    2 3 4 5
    その他のオプションについては、BMC アドレス指定のセクションを参照してください。
  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

8.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:// に変更します。
  • provisioning ネットワークを使用する場合、これを noProxy 設定に含めます。そうしない場合、インストーラーは失敗します。
  • プロビジョナーノード内の環境変数としてすべてのプロキシー設定を設定します。たとえば、HTTP_PROXYHTTPS_PROXY、および NO_PROXY が含まれます。
注記

IPv6 でプロビジョニングする場合、noProxy 設定で CIDR アドレスブロックを定義することはできません。各アドレスを個別に定義する必要があります。

8.3.6.3. provisioning ネットワークがない install-config.yaml ファイルの変更 (オプション)

provisioning ネットワークなしに OpenShift Container Platformmake をデプロイするには、install-config.yaml ファイルに以下の変更を加えます。

platform:
  baremetal:
    apiVIP: <apiVIP>
    ingressVIP: <ingress/wildcard VIP>
    provisioningNetwork: "Disabled"

8.3.6.4. install-config.yaml ファイルでの管理対象 Secure Boot の設定 (オプション)

redfishredfish-virtualmediaidrac-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
bmc.address 設定は、redfishredfish-virtualmedia、または idrac-virtualmedia をプロトコルとして使用することを確認します。詳細は、HPE iLO の BMC address for HPE iLO または BMC address for Dell iDRAC を参照してください。
2
bootMode 設定は、デフォルトで UEFI となります。管理対象 Secure Boot を有効にするには、これを UEFISecureBoot に変更します。
注記

ノードが管理対象 Secure Boot をサポートできるようにするには、前提条件のノードの設定を参照してください。ノードが管理対象 Secure Boot に対応していない場合には、ノードの設定セクションの手動での Secure Boot のノードの設定を参照してください。Secure Boot を手動で設定するには、Redfish 仮想メディアが必要です。

注記

IPMI は Secure Boot 管理機能を提供しないため、Red Hat では IPMI による Secure Boot のサポートはありません。

8.3.6.5. 追加の install-config パラメーター

install-config.yaml ファイルに必要なパラメーター hosts パラメーターおよび bmc パラメーターについては、以下の表を参照してください。

表8.2 必須パラメーター

パラメーターデフォルト説明

baseDomain

 

クラスターのドメイン名。例: example.com

sshKey

 

sshKey 設定には、コントロールプレーンノードおよびワーカーノードにアクセスするために必要な ~/.ssh/id_rsa.pub ファイルのキーが含まれます。通常、このキーは provisionaer ノードのキーです。

pullSecret

 

pullSecret 設定には、プロビジョナーノードの準備の際に Install OpenShift on Bare Metal ページからダウンロードしたプルシークレットのコピーが含まれます。

metadata:
    name:
 

OpenShift Container Platform クラスターに指定される名前。例: openshift

networking:
    machineCIDR:
 

外部ネットワークの公開 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 クラスターの一部として含まれるコントロールプレーン (マスター) ノードの数を設定します。

defaultMachinePlatform

 

プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。

apiVIP

api.<clustername.clusterdomain>

内部 API 通信に使用する VIP。

この設定は、デフォルト名が正しく解決されるように DNS で指定するか、または事前に設定する必要があります。

disableCertificateVerification

False

redfish および redfish-virtualmedia では、このパラメーターで BMC アドレスを管理する必要があります。BMC アドレスに自己署名証明書を使用する場合は、値が True である必要があります。

ingressVIP

test.apps.<clustername.clusterdomain>

Ingress トラフィックに使用する VIP。

表8.3 オプションのパラメーター

パラメーターデフォルト詳細

provisioningDHCPRange

172.22.0.10,172.22.0.100

provisioning ネットワークでノードの IP 範囲を定義します。

provisioningNetworkCIDR

172.22.0.0/24

プロビジョニングに使用するネットワークの CIDR。このオプションは、provisioning ネットワークでデフォルトのアドレス範囲を使用しない場合に必要です。

clusterProvisioningIP

provisioningNetworkCIDR の 3 番目の IP アドレス。

プロビジョニングサービスが実行されるクラスター内の IP アドレス。デフォルトは、provisioning サブネットの 3 番目の IP アドレスに設定されます。例: 172.22.0.3.

bootstrapProvisioningIP

provisioningNetworkCIDR の 2 番目の IP アドレス

インストーラーがコントロールプレーン (マスター) ノードをデプロイしている間にプロビジョニングサービスが実行されるブートストラップ仮想マシンの IP アドレス。デフォルトは、provisioning サブネットの 2 番目の 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

 

provisioning ネットワークの要件を無効にするには、このパラメーターを Disabled に設定します。ユーザーは仮想メディアベースのプロビジョニングのみを実行するか、またはアシストインストールを使用してクラスターを起動することができます。電源管理を使用する場合は、マシンネットワークから BMC にアクセスできる必要があります。ユーザーは、プロビジョニングサービスに使用する外部ネットワークに 2 つの IP アドレスを指定する必要があります。DHCP、TFTP などを含むプロビジョニングネットワークを完全に管理するには、このパラメーターを managed (デフォルト) に設定します。

このパラメーターを unmanaged に設定してプロビジョニングネットワークを引き続き有効にしますが、DHCP の手動設定を行います。仮想メディアのプロビジョニングが推奨されますが、必要に応じて PXE を引き続き利用できます。

httpProxy

 

このパラメーターを、環境内で使用する適切な HTTP プロキシーに設定します。

httpsProxy

 

このパラメーターを、環境内で使用する適切な HTTPS プロキシーに設定します。

noProxy

 

このパラメーターを、環境内のプロキシーの使用に対する例外の一覧に設定します。

ホスト

hosts パラメーターは、クラスターのビルドに使用される個別のベアメタルアセットの一覧です。

名前

デフォルト

詳細

name

 

詳細情報に関連付ける BareMetalHost リソースの名前。例: openshift-master-0

role

 

ベアメタルノードのロール。master または worker のいずれか。

bmc

 

ベースボード管理コントローラーの接続詳細。詳細は、BMC アドレス指定のセクションを参照してください。

bootMACAddress

 

ホストが provisioning ネットワークに使用する NIC の MAC アドレス。Ironic は、bootMACAddress 設定を使用して IP アドレスを取得します。次に、ホストにバインドします。

注記

provisioning ネットワークを無効にした場合は、ホストから有効な MAC アドレスを提供する必要があります。

8.3.6.6. BMC アドレス指定

ほとんどのベンダーは、Intelligent Platform Management Interface (IPMI) で BMC アドレス指定に対応しています。IPMI は通信を暗号化しません。これは、セキュリティーが保護された管理ネットワークまたは専用の管理ネットワークを介したデータセンター内での使用に適しています。ベンダーを確認して、Redfish ネットワークブートをサポートしているかどうかを確認します。Redfish は、コンバージド、ハイブリッド IT および Software Defined Data Center (SDDC) 向けのシンプルでセキュアな管理を行います。Redfish は人による判読が可能、かつ機械対応が可能であり、インターネットや Web サービスの標準を活用して、最新のツールチェーンに情報を直接公開します。ハードウェアが 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>

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

8.3.6.7. Dell の BMC アドレス指定

それぞれの bmc エントリーの address フィールドは、URL スキーム内のコントローラーのタイプやネットワーク上のその場所を含む、OpenShift Container Platform クラスターノードに接続する URL です。

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address>
          username: <user>
          password: <password>

Dell ハードウェアの場合、Red Hat は Redfish 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。

表8.4 Dell ハードウェアの BMC アドレス形式

プロトコルアドレスのフォーマット

Redfish 仮想メディア

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>

重要

idrac-virtualmedia を Redfish 仮想メディアのプロトコルとして使用します。redfish-virtualmedia は Dell ハードウェアでは機能しません。Dell の idrac-virtualmedia は、Dell の OEM 拡張機能が含まれる Redfish 標準を使用します。

詳細は、以下のセクションを参照してください。

Dell の 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 の場合、 Virtual Console プラグインはデフォルトで eHTML5 に設定されます。これにより、InsertVirtualMedia ワークフローに関する問題が生じます。この問題を回避するには、プラグインを HTML5 に設定します。メニューパスは以下の通りです。ConfigurationVirtual consolePlug-in TypeHTML5

OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。ConfigurationVirtual MediaAttach ModeAutoAttach

idrac-virtualmedia:// を Redfish 仮想メディアのプロトコルとして使用します。redfish-virtualmedia:// の使用は、 idrac-virtualmedia:// プロトコルが idrac ハードウェアタイプおよび Ironic の Redfish プロトコルに対応しているため、Dell ハードウェアでは機能しません。Dell の idrac-virtualmedia:// プロトコルは、Dell の OEM 拡張機能が含まれる Redfish 標準を使用します。Ironic は、WSMAN プロトコルのある idrac タイプもサポートします。したがって、Dell ハードウェア上の仮想メディアで Redfish を使用する際に予期しない動作を回避するために、idrac-virtualmedia:// を指定する必要があります。

Dell の 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/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 の場合、 Virtual Console プラグインはデフォルトで eHTML5 に設定されます。これにより、InsertVirtualMedia ワークフローに関する問題が生じます。この問題を回避するには、プラグインを HTML5 に設定します。メニューパスは以下の通りです。ConfigurationVirtual consolePlug-in TypeHTML5

OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。ConfigurationVirtual MediaAttach ModeAutoAttach

redfish:// URL プロトコルは、Ironic の redfish ハードウェアタイプに対応します。

8.3.6.8. HPE の BMC アドレス指定

それぞれの bmc エントリーの address フィールドは、URL スキーム内のコントローラーのタイプやネットワーク上のその場所を含む、OpenShift Container Platform クラスターノードに接続する URL です。

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address>
          username: <user>
          password: <password>

HPE ハードウェアの場合、Red Hat は Redfish 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。

表8.5 HPE ハードウェアの 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 の Redfish 仮想メディア

HPE サーバーについて RedFish Virtual Media を有効にするには、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 をサポートしないので、Redfish 仮想メディアは、iLO4 を実行する第 9 世代のシステムではサポートされません。

HPE の 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

8.3.6.9. ルートデバイスのヒント

rootDeviceHints パラメーターは、インストーラーが Red Hat Enterprise Linux CoreOS (RHCOS) イメージを特定のデバイスにプロビジョニングできるようにします。インストーラーは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。インストーラーは、ヒント値に一致する最初に検出されたデバイスを使用します。この設定は複数のヒントを組み合わせることができますが、デバイスは、インストーラーがこれを選択できるようにすべてのヒントに一致する必要があります。

表8.6 サブフィールド

サブフィールド説明

deviceName

/dev/vda などの Linux デバイス名を含む文字列。ヒントは、実際の値と完全に一致する必要があります。

hctl

0:0:0:0 などの SCSI バスアドレスを含む文字列。ヒントは、実際の値と完全に一致する必要があります。

model

ベンダー固有のデバイス識別子を含む文字列。ヒントは、実際の値のサブ文字列になります。

vendor

デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。

serialNumber

デバイスのシリアル番号を含む文字列。ヒントは、実際の値と完全に一致する必要があります。

minSizeGigabytes

デバイスの最小サイズ (ギガバイト単位) を表す整数。

wwn

一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。

wwnWithExtension

ベンダー拡張が追加された一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。

wwnVendorExtension

一意のベンダーストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。

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"

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

8.3.7. 非接続レジストリーの作成 (オプション)

インストールレジストリーのローカルコピーを使用して OpenShift Container Platform クラスターをインストールする必要がある場合があります。これにより、クラスターノードがインターネットにアクセスできないネットワーク上にあるため、ネットワークの効率が高まる可能性があります。

レジストリーのローカルまたはミラーリングされたコピーには、以下が必要です。

  • レジストリーの証明書。これには、自己署名証明書を使用できます。
  • システム上のコンテナーが提供する Web サーバー。
  • 証明書およびローカルリポジトリーの情報が含まれる更新されたプルシークレット。
注記

レジストリーノードでの非接続レジストリーの作成はオプションです。以下のセクションでは、それらの手順はレジストリーノードで非接続レジストリーを作成する場合にのみ実行する必要があるためにオプションであることを示しています。レジストリーノードで非接続レジストリーを作成する際に、(optional) というラベルが付けられたすべての後続のサブセクションを実行する必要があります。

8.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}

8.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> を置き換える場合には、2 文字のみを使用します。例: US

  2. レジストリーノードの ca-trust を新規証明書で更新します。

    $ sudo cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
    $ sudo update-ca-trust extract

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

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

8.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.7 など) を指定します。

    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

8.3.7.6. install-config.yaml ファイルを、非接続レジストリーを使用するように変更します (オプション)。

プロビジョナーノードでは、install-config.yaml ファイルは pull-secret-update.txt ファイルから新たに作成された pull-secret を使用する必要があります。install-config.yaml ファイルには、非接続レジストリーノードの証明書およびレジストリー情報も含まれる必要があります。

手順

  1. 非接続レジストリーノードの証明書を install-config.yaml ファイルに追加します。証明書は "additionalTrustBundle: |" 行に従い、通常は 2 つのスペースで適切にインデントされる必要があります。

    $ 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 をレジストリーの完全修飾ドメイン名に置き換えます。

8.3.8. ワーカーノードでのルーターのデプロイ

インストール時に、インストーラーはルーター Pod をワーカーノードにデプロイします。デフォルトで、インストーラーは 2 つのルーター Pod をインストールします。初期クラスターにワーカーノードが 1 つしかない場合や、デプロイされたクラスターで、OpenShift Container Platform クラスター内のサービスに対して予定される外部トラフィックを処理する追加のルーターが必要な場合、yaml ファイルを作成して適切なルーターレプリカ数を設定できます。

注記

デフォルトで、インストーラーは 2 つのルーターをデプロイします。クラスターにワーカーノードが 2 つ以上ある場合、このセクションを省略できます。

注記

クラスターにワーカーノードがない場合、インストーラーはデフォルトで 2 つのルーターをコントロールプレーンノードにデプロイします。クラスターにワーカーノードがない場合、このセクションを省略できます。

手順

  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> を適切な値に置き換えます。1 つのワーカーノードのみを使用している場合、replicas:1 に設定します。4 つ以上のワーカーノードを使用している場合、replicas: のデフォルトの値 2 を随時増やすことができます。

  2. router-replicas.yaml ファイルを保存し、これを clusterconfigs/openshift ディレクトリーにコピーします。

    cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml

8.3.9. インストールの検証チェックリスト

  • ❏ OpenShift Container Platform インストーラーが取得されている。
  • ❏ OpenShift Container Platform インストーラーが展開されている。
  • install-config.yaml の必須パラメーターが設定されている。
  • install-config.yamlhosts パラメーターが設定されている。
  • install-config.yamlbmc パラメーターが設定されている。
  • bmc address フィールドで設定されている値の変換が適用されている。
  • ❏ 非接続レジストリーを作成している (オプション)。
  • ❏ (オプション) 非接続レジストリー設定が使用されている場合にこれを検証する。
  • ❏ (オプション) ルーターをワーカーノードにデプロイしている。

8.3.10. OpenShift Container Platform インストーラーを使用したクラスターのデプロイ

OpenShift Container Platform インストーラーを実行します。

$ ./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster

8.3.11. インストール後

デプロイメントプロセスで、tail コマンドを install ディレクトリーフォルダーの .openshift_install.log ログファイルに対して実行して、インストールの全体のステータスを確認できます。

$ tail -f /path/to/install-dir/.openshift_install.log

8.3.12. ベアメタルにクラスターを再インストールする準備

ベアメタルにクラスターを再インストールする前に、クリーンアップ操作を実行する必要があります。

手順

  1. ブートストラップ、コントロールプレーンノード (マスターとも呼ばれる)、およびワーカーノードのディスクを削除または再フォーマットします。ハイパーバイザー環境で作業している場合は、削除したディスクを追加する必要があります。
  2. 以前のインストールで生成されたアーティファクトを削除します。

    $ cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \
    .openshift_install.log .openshift_install_state.json
  3. 新しいマニフェストと Ignition 設定ファイルを生成します。詳細は、Kubernetes マニフェストおよび Ignition 設定ファイルの作成を参照してください。
  4. インストールプログラムが作成した新規ブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これにより、以前の Ignition ファイルが上書きされます。