8.3. OpenShift インストールの環境のセットアップ
8.3.1. RHEL のプロビジョナーノードへのインストール
ネットワーク設定が完了すると、次の手順では、プロビジョナーノードに RHEL 8.x をインストールします。インストーラーは、OpenShift Container Platform クラスターをインストールする間にプロビジョナーノードをオーケレーターとして使用します。本書の目的上、RHEL のプロビジョナーノードへのインストールは対象外です。ただし、オプションには、RHEL Satellite サーバー、PXE、またはインストールメディアの使用も含まれますが、これらに限定されません。
8.3.2. OpenShift Container Platform インストールのプロビジョナーノードの準備
環境を準備するには、以下の手順を実行します。
手順
-
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
ネットワークの設定
注記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 プロトコルに設定されていることを確認します。
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
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}')
関連情報
- 異なるリリースチャネルの概要については、OpenShift Container Platform アップグレードチャネルおよびリリース について参照してください。
8.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
8.3.5. RHCOS イメージキャッシュの作成 (オプション)
イメージのキャッシュを使用するには、ブートストラップ仮想マシンによって使用される Red Hat Enterprise Linux CoreOS (RHCOS) イメージと、異なるノードをプロビジョニングするためにインストーラーによって使用される RHCOS イメージという 2 つのイメージをダウンロードする必要があります。イメージのキャッシュはオプションですが、帯域幅が制限されたネットワークでインストーラーを実行する場合にとくに役立ちます。
帯域幅が制限されたネットワークでインストーラーを実行し、RHCOS イメージのダウンロードに 15 分から 20 分を超える時間がかかる場合、インストーラーはタイムアウトします。このような場合、Web サーバーでイメージをキャッシュすることができます。
イメージが含まれるコンテナーをインストールするには、以下の手順に従います。
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 rhcos_image_cache/
インストーラーからコミット ID を取得します。ID は、インストーラーがダウンロードする必要のあるイメージを判別します。
$ export COMMIT_ID=$(/usr/local/bin/openshift-baremetal-install version | grep '^built from commit' | awk '{print $4}')
インストーラーがノードにデプロイする 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')
インストーラーがブートストラップ仮想マシンにデプロイする 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')
イメージが公開されるパスを取得します。
$ export RHCOS_PATH=$(curl -s -S https://raw.githubusercontent.com/openshift/installer/$COMMIT_ID/data/data/rhcos.json | jq .baseURI | sed 's/"//g')
ブートストラップ仮想マシンにデプロイされる 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"]')
ノードにデプロイされる 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')
イメージをダウンロードして、それらを
/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}
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
8.3.6. 設定ファイル
8.3.6.1. install-config.yaml
ファイルの設定
install-config.yaml
ファイルには、追加の詳細情報が必要です。それらの情報のほとんどは、インストーラーおよび結果として作成されるクラスターが利用可能なハードウェアを完全に管理するのに必要な利用可能なハードウェアについての十分な情報として提供されます。
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>'
クラスター設定を保存するディレクトリーを作成します。
$ 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
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_PROXY
、HTTPS_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 の設定 (オプション)
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
ノードが管理対象 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
パラメーターについては、以下の表を参照してください。
パラメーター | デフォルト | 説明 |
---|---|---|
|
クラスターのドメイン名。例: | |
|
| |
|
| |
metadata: name: |
OpenShift Container Platform クラスターに指定される名前。例: | |
networking: machineCIDR: |
外部ネットワークの公開 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 クラスターの一部として含まれるコントロールプレーン (マスター) ノードの数を設定します。 | |
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
|
| 内部 API 通信に使用する VIP。 この設定は、デフォルト名が正しく解決されるように DNS で指定するか、または事前に設定する必要があります。 |
|
|
|
|
| Ingress トラフィックに使用する VIP。 |
パラメーター | デフォルト | 詳細 |
---|---|---|
|
|
|
|
|
プロビジョニングに使用するネットワークの CIDR。このオプションは、 |
|
|
プロビジョニングサービスが実行されるクラスター内の IP アドレス。デフォルトは、 |
|
|
インストーラーがコントロールプレーン (マスター) ノードをデプロイしている間にプロビジョニングサービスが実行されるブートストラップ仮想マシンの IP アドレス。デフォルトは、 |
|
|
|
|
|
|
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
|
ブートストラップノードのデフォルトのオペレーティングシステムイメージを上書きするための URL。URL にはイメージの SHA-256 ハッシュが含まれている必要があります。例: | |
|
クラスターノードのデフォルトオペレーティングシステムを上書きするための URL。URL には、イメージの SHA-256 ハッシュを含める必要があります。例: | |
|
このパラメーターを | |
| このパラメーターを、環境内で使用する適切な HTTP プロキシーに設定します。 | |
| このパラメーターを、環境内で使用する適切な HTTPS プロキシーに設定します。 | |
| このパラメーターを、環境内のプロキシーの使用に対する例外の一覧に設定します。 |
ホスト
hosts
パラメーターは、クラスターのビルドに使用される個別のベアメタルアセットの一覧です。
名前 | デフォルト | 詳細 |
|
詳細情報に関連付ける | |
|
ベアメタルノードのロール。 | |
| ベースボード管理コントローラーの接続詳細。詳細は、BMC アドレス指定のセクションを参照してください。 | |
|
ホストが 注記
|
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 をサポートします。
プロトコル | アドレスのフォーマット |
---|---|
Redfish 仮想メディア |
|
Redfish ネットワークブート |
|
IPMI |
|
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
に設定します。メニューパスは以下の通りです。Configuration
OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration AutoAttach
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
に設定します。メニューパスは以下の通りです。Configuration
OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration
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 をサポートします。
プロトコル | アドレスのフォーマット |
---|---|
Redfish 仮想メディア |
|
Redfish ネットワークブート |
|
IPMI |
|
詳細は、以下のセクションを参照してください。
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) イメージを特定のデバイスにプロビジョニングできるようにします。インストーラーは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。インストーラーは、ヒント値に一致する最初に検出されたデバイスを使用します。この設定は複数のヒントを組み合わせることができますが、デバイスは、インストーラーがこれを選択できるようにすべてのヒントに一致する必要があります。
サブフィールド | 説明 |
---|---|
|
|
|
|
| ベンダー固有のデバイス識別子を含む文字列。ヒントは、実際の値のサブ文字列になります。 |
| デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。 |
| デバイスのシリアル番号を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| デバイスの最小サイズ (ギガバイト単位) を表す整数。 |
| 一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| ベンダー拡張が追加された一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| 一意のベンダーストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| デバイスがローテーションするディスクである (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 マニフェストの作成
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. ミラーリングされたレジストリーをホストするためのレジストリーノードの準備 (オプション)
レジストリーノードに以下の変更を加えます。
手順
レジストリーノードでファイアウォールポートを開きます。
$ 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}
8.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>
を置き換える場合には、2 文字のみを使用します。例:US
レジストリーノードの
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
ファイルが必要になります。
手順
コンテナーが使用する
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
8.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
8.3.7.5. リポジトリーのミラーリング (オプション)
手順
oc
バイナリーをプロビジョナーノードからレジストリーノードにコピーします。$ sudo scp kni@provisioner:/usr/local/bin/oc /usr/local/bin
必要な環境変数を設定します。
リリースバージョンを設定します。
$ VERSION=<release_version>
<release_version>
には、インストールする OpenShift Container Platform のバージョンに対応するタグ (4.7
など) を指定します。ローカルレジストリー名とホストポートを設定します。
$ 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
8.3.7.6. install-config.yaml
ファイルを、非接続レジストリーを使用するように変更します (オプション)。
プロビジョナーノードでは、install-config.yaml
ファイルは pull-secret-update.txt
ファイルから新たに作成された pull-secret を使用する必要があります。install-config.yaml
ファイルには、非接続レジストリーノードの証明書およびレジストリー情報も含まれる必要があります。
手順
非接続レジストリーノードの証明書を
install-config.yaml
ファイルに追加します。証明書は"additionalTrustBundle: |"
行に従い、通常は 2 つのスペースで適切にインデントされる必要があります。$ 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
をレジストリーの完全修飾ドメイン名に置き換えます。
8.3.8. ワーカーノードでのルーターのデプロイ
インストール時に、インストーラーはルーター Pod をワーカーノードにデプロイします。デフォルトで、インストーラーは 2 つのルーター Pod をインストールします。初期クラスターにワーカーノードが 1 つしかない場合や、デプロイされたクラスターで、OpenShift Container Platform クラスター内のサービスに対して予定される外部トラフィックを処理する追加のルーターが必要な場合、yaml
ファイルを作成して適切なルーターレプリカ数を設定できます。
デフォルトで、インストーラーは 2 つのルーターをデプロイします。クラスターにワーカーノードが 2 つ以上ある場合、このセクションを省略できます。
クラスターにワーカーノードがない場合、インストーラーはデフォルトで 2 つのルーターをコントロールプレーンノードにデプロイします。クラスターにワーカーノードがない場合、このセクションを省略できます。
手順
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
を随時増やすことができます。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.yaml
のhosts
パラメーターが設定されている。 -
❏
install-config.yaml
のbmc
パラメーターが設定されている。 -
❏
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. ベアメタルにクラスターを再インストールする準備
ベアメタルにクラスターを再インストールする前に、クリーンアップ操作を実行する必要があります。
手順
- ブートストラップ、コントロールプレーンノード (マスターとも呼ばれる)、およびワーカーノードのディスクを削除または再フォーマットします。ハイパーバイザー環境で作業している場合は、削除したディスクを追加する必要があります。
以前のインストールで生成されたアーティファクトを削除します。
$ cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \ .openshift_install.log .openshift_install_state.json
- 新しいマニフェストと Ignition 設定ファイルを生成します。詳細は、Kubernetes マニフェストおよび Ignition 設定ファイルの作成を参照してください。
- インストールプログラムが作成した新規ブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これにより、以前の Ignition ファイルが上書きされます。