13.3. OpenShift インストールの環境のセットアップ
13.3.1. RHEL のプロビジョナーノードへのインストール
前提条件の設定が完了したら、次のステップは RHEL 8.x をプロビジョナーノードにインストールすることです。インストーラーは、OpenShift Container Platform クラスターをインストールする間にプロビジョナーノードをオーケレーターとして使用します。本書の目的上、RHEL のプロビジョナーノードへのインストールは対象外です。ただし、オプションには、RHEL Satellite サーバー、PXE、またはインストールメディアの使用も含まれますが、これらに限定されません。
13.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 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
接続が切断される可能性があります。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 に移動します。Copy pull secret をクリックします。
pull-secret.txt
ファイルにコンテンツを貼り付け、そのコンテンツをkni
ユーザーのホームディレクトリーに保存します。
13.3.3. サブネット間の通信を確立する
一般的な OpenShift Container Platform クラスター設定では、コントロールプレーンとワーカーノードを含むすべてのノードが同じネットワーク内に存在します。ただし、エッジコンピューティングのシナリオでは、ワーカーノードをエッジの近くに配置することが有益な場合があります。その場合、コントロールプレーンやローカルワーカーノードが使用するサブネットとは異なるネットワークセグメントまたはサブネットをリモートワーカーノードに使用されることもよくあります。このようなセットアップにより、エッジのレイテンシーが減少し、拡張性が向上します。ただし、リモートワーカーノードを含むエッジサブネットがコントロールプレーンノードを含むサブネットに到達し、コントロールプレーンからのトラフィックも受信するためには、OpenShift Container Platform をインストールする前にネットワークを適切に設定する必要があります。
すべてのコントロールプレーンノードは同じサブネット内で実行する必要があります。複数のサブネットを使用する場合、マニフェストを使用して、コントロールプレーンノード上で実行されるように Ingress VIP を設定することもできます。詳細は、「コントロールプレーンで実行するネットワークコンポーネントの設定」を参照してください。
複数のサブネットを持つクラスターをデプロイメントするには、仮想メディアを使用する必要があります。
この手順では、2 番目のサブネットにあるリモートワーカーノードが 1 番目のサブネットにあるコントロールプレーンノードと効果的に通信できるようにし、1 番目のサブネットにあるコントロールプレーンノードが 2 番目のサブネットにあるリモートワーカーノードと効果的に通信できるようにするために必要なネットワーク設定について詳しく説明します。
この手順では、クラスターは 2 つのサブネットにまたがります。
-
1 番目のサブネット (
10.0.0.0
) には、コントロールプレーンとローカルワーカーノードが含まれています。 -
2 番目のサブネット (
192.168.0.0
) にはエッジワーカーノードが含まれています。
手順
1 番目のサブネットが 2 番目のサブネットと通信するように設定します。
次のコマンドを実行して、コントロールプレーンノードに
root
としてログインします。$ sudo su -
ネットワークインターフェイスの名前を取得します。
# nmcli dev status
-
ゲートウェイ経由で 2 番目のサブネット (
192.168.0.0
) にルートを追加します: s+
# nmcli connection modify <interface_name> +ipv4.routes "192.168.0.0/24 via <gateway>"
+ <interface_name>
をインターフェイス名に置き換えます。<gateway>
を実際のゲートウェイの IP アドレスに置き換えます。
+ .例
+
# nmcli connection modify eth0 +ipv4.routes "192.168.0.0/24 via 192.168.0.1"
変更を適用します。
# nmcli connection up <interface_name>
<interface_name>
をインターフェイス名に置き換えます。ルーティングテーブルを検証して、ルートが正常に追加されたことを確認します。
# ip route
1 番目のサブネットの各コントロールプレーンノードに対して前の手順を繰り返します。
注記実際のインターフェイス名とゲートウェイに一致するようにコマンドを調整します。
- 1 番目のサブネットと通信するように 2 番目のサブネットを設定します。
root
としてリモートワーカーノードにログインします。$ sudo su -
ネットワークインターフェイスの名前を取得します。
# nmcli dev status
ゲートウェイ経由で 1 番目のサブネット (
10.0.0.0
) にルートを追加します。# nmcli connection modify <interface_name> +ipv4.routes "10.0.0.0/24 via <gateway>"
<interface_name>
をインターフェイス名に置き換えます。<gateway>
を実際のゲートウェイの IP アドレスに置き換えます。例
# nmcli connection modify eth0 +ipv4.routes "10.0.0.0/24 via 10.0.0.1"
変更を適用します。
# nmcli connection up <interface_name>
<interface_name>
をインターフェイス名に置き換えます。ルーティングテーブルを検証して、ルートが正常に追加されたことを確認します。
# ip route
2 番目のサブネット内の各ワーカーノードに対して前の手順を繰り返します。
注記実際のインターフェイス名とゲートウェイに一致するようにコマンドを調整します。
- ネットワークを設定したら、接続をテストして、リモートワーカーノードがコントロールプレーンノードに到達できること、およびコントロールプレーンノードがリモートワーカーノードに到達できることを確認します。
1 番目のサブネットのコントロールプレーンノードから、2 番目のサブネットのリモートワーカーノードに ping を送信します。
$ ping <remote_worker_node_ip_address>
ping が成功した場合は、1 番目のサブネットのコントロールプレーンノードが 2 番目のサブネットのリモートワーカーノードに到達できることを意味します。応答を受信しない場合は、ネットワーク設定を確認し、ノードに対して手順を繰り返します。
2 番目のサブネットのリモートワーカーノードから、1 番目のサブネットのコントロールプレーンノードに ping を送信します。
$ ping <control_plane_node_ip_address>
ping が成功した場合は、2 番目のサブネットのリモートワーカーノードが 1 番目のサブネットのコントロールプレーンに到達できることを意味します。応答を受信しない場合は、ネットワーク設定を確認し、ノードに対して手順を繰り返します。
13.3.4. OpenShift Container Platform インストーラーの取得
インストーラーの stable-4.x
バージョンを使用して、OpenShift Container Platform の一般公開の安定バージョンをデプロイします。
$ export VERSION=stable-4.10 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}')
13.3.5. 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
13.3.6. (オプション) RHCOS イメージキャッシュの作成
イメージキャッシングを使用するには、ブートストラップ VM がクラスターノードをプロビジョニングするために使用する Red Hat Enterprise Linux CoreOS(RHCOS) イメージをダウンロードする必要があります。イメージのキャッシュはオプションですが、帯域幅が制限されているネットワークでインストールプログラムを実行する場合に特に便利です。
正しいイメージがリリースペイロードにあるため、インストールプログラムは、clusterOSImage
RHCOS イメージを必要としなくなりました。
帯域幅が制限されたネットワークでインストールプログラムを実行していて、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
を保存するディレクトリーを作成します。$ mkdir /home/kni/rhcos_image_cache
新規に作成されたディレクトリーに適切な SELinux コンテキストを設定します。
$ sudo semanage fcontext -a -t httpd_sys_content_t "/home/kni/rhcos_image_cache(/.*)?"
$ sudo restorecon -Rv /home/kni/rhcos_image_cache/
インストールプログラムがブートストラップ VM にデプロイする RHCOS イメージの URI を取得します。
$ export RHCOS_QEMU_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk.location')
インストールプログラムがブートストラップ VM にデプロイするイメージの名前を取得します。
$ export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
ブートストラップ仮想マシンにデプロイされる RHCOS イメージの SHA ハッシュを取得します。
$ export RHCOS_QEMU_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk["uncompressed-sha256"]')
イメージをダウンロードして、
/home/kni/rhcos_image_cache
ディレクトリーに配置します。$ curl -L ${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_NAME}
新しいファイルの SELinux タイプが
httpd_sys_content_t
であることを確認します。$ ls -Z /home/kni/rhcos_image_cache
Pod を作成します。
$ podman run -d --name rhcos_image_cache \ 1 -v /home/kni/rhcos_image_cache:/var/www/html \ -p 8080:8080/tcp \ quay.io/centos7/httpd-24-centos7:latest
- 1
rhcos_image_cache
という名前のキャッシング Web サーバーを作成します。この Pod は、デプロイメント用にinstall-config.yaml
ファイルのbootstrapOSImage
イメージを提供します。
bootstrapOSImage
設定を生成します。$ 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}"
$ echo " bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}"
platform.baremetal
下のinstall-config.yaml
ファイルに必要な設定を追加します。platform: baremetal: bootstrapOSImage: <bootstrap_os_image> 1
- 1
<bootstrap_os_image>
を$BOOTSTRAP_OS_IMAGE
の値に置き換えます。
詳細は、Configuring the install-config.yaml file セクションを参照してください。
13.3.7. install-config.yaml ファイルの設定
13.3.7.1. install-config.yaml
ファイルの設定
install-config.yaml
ファイルには、追加の詳細情報が必要です。ほとんどの情報は、インストールプログラムと結果として作成されるクラスターに、完全に管理できる使用可能なハードウェアについて十分に説明しています。
正しいイメージがリリースペイロードにあるため、インストールプログラムは、clusterOSImage
RHCOS イメージを必要としなくなりました。
install-config.yaml
を設定します。pullSecret
およびsshKey
など、環境に合わせて適切な変数を変更します。apiVersion: v1 baseDomain: <domain> metadata: name: <cluster-name> networking: machineNetwork: - cidr: <public-cidr> networkType: OVNKubernetes compute: - name: worker replicas: 2 1 controlPlane: name: master replicas: 3 platform: baremetal: {} platform: baremetal: apiVIP: <api-ip> ingressVIP: <wildcard-ip> provisioningNetworkCIDR: <CIDR> hosts: - name: openshift-master-0 role: master bmc: address: ipmi://<out-of-band-ip> 2 username: <user> password: <password> bootMACAddress: <NIC1-mac-address> rootDeviceHints: deviceName: "<installation_disk_drive_path>" 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: "<installation_disk_drive_path>" 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: "<installation_disk_drive_path>" 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: "<installation_disk_drive_path>" 9 pullSecret: '<pull_secret>' sshKey: '<ssh_pub_key>'
- 1
- OpenShift Container Platform クラスターの一部であるワーカーノードの数に基づいてワーカーマシンをスケーリングします。
replicas
値の有効なオプションは0
で、2
以上の整数です。3 ノードクラスターのみが含まれる 3 ノードクラスターをデプロイするには、レプリカ数を0
に設定します。3 ノードクラスターは、テスト、開発、本番に使用できる、より小さく、よりリソース効率の良いクラスターです。ワーカーを 1 つだけにしてクラスターをインストールすることはできません。 - 2 4 6 8
- その他のオプションについては、BMC アドレス指定のセクションを参照してください。
- 3 5 7 9
- インストールディスクドライブへのパスを設定するには、ディスクのカーネル名を入力します。たとえば、
/dev/sda
です。重要ディスクの検出順序は保証されていないため、複数のディスクを備えたマシンの起動オプションによってディスクのカーネル名が変わる可能性があります。たとえば、
/dev/sda
は/dev/sdb
になり、その逆も同様です。この問題を回避するには、ディスクの World Wide Name (WWN) などの永続ディスク属性を使用する必要があります。ディスク WWN を使用するには、deviceName
パラメーターをwwnWithExtension
パラメーターに置き換えます。使用するパラメーターに応じて、/dev/sda
などのディスク名、または"0x64cd98f04fde100024684cf3034da5c2"
などのディスク WWN を入力します。ディスク WWN 値が 16 進数値ではなく文字列値として使用されるように、ディスク WWN 値を引用符で囲んで入力してください。これらの
rootDeviceHints
パラメーター要件を満たさない場合、次のエラーが発生する可能性があります。ironic-inspector inspection failed: No disks satisfied root device hints
クラスター設定を保存するディレクトリーを作成します。
$ mkdir ~/clusterconfigs
install-config.yaml
ファイルを新しいディレクトリーにコピーします。$ 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
13.3.7.2. 追加の install-config
パラメーター
install-config.yaml
ファイルに必要なパラメーター hosts
パラメーターおよび bmc
パラメーターについては、以下の表を参照してください。
パラメーター | デフォルト | 説明 |
---|---|---|
|
クラスターのドメイン名。例: | |
|
|
ノードのブートモード。オプションは、 |
|
| |
|
| |
metadata: name: |
OpenShift Container Platform クラスターに指定される名前。例: | |
networking: machineNetwork: - cidr: |
外部ネットワークの公開 CIDR (Classless Inter-Domain Routing)。例: | |
compute: - name: worker | OpenShift Container Platform クラスターでは、ノードがゼロであってもワーカー (またはコンピュート) ノードの名前を指定する必要があります。 | |
compute: replicas: 2 | レプリカは、OpenShift Container Platform クラスターのワーカー (またはコンピュート) ノードの数を設定します。 | |
controlPlane: name: master | OpenShift Container Platform クラスターには、コントロールプレーン (マスター) ノードの名前が必要です。 | |
controlPlane: replicas: 3 | レプリカは、OpenShift Container Platform クラスターの一部として含まれるコントロールプレーン (マスター) ノードの数を設定します。 | |
|
ベアメタルネットワークに接続されたノード上のネットワークインターフェイス名。OpenShift Container Platform 4.9 以降のリリースのために、NIC の名前を識別するために | |
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
| (オプション) Kubernetes API 通信の仮想 IP アドレス。
この設定は、Machine Network からの予約済み IP として | |
|
|
|
| (オプション) Ingress トラフィックの仮想 IP アドレス。
この設定は、Machine Network からの予約済み IP として |
パラメーター | デフォルト | 説明 |
---|---|---|
|
| プロビジョニングネットワークでノードの IP 範囲を定義します。 |
|
| プロビジョニングに使用するネットワークの CIDR。このオプションは、プロビジョニングネットワークでデフォルトのアドレス範囲を使用しない場合に必要です。 |
|
|
プロビジョニングサービスが実行されるクラスター内の IP アドレス。デフォルトは、プロビジョニングサブネットの 3 番目の IP アドレスに設定されます。例: |
|
|
インストーラーがコントロールプレーン (マスター) ノードをデプロイしている間にプロビジョニングサービスが実行されるブートストラップ仮想マシンの IP アドレス。デフォルトは、プロビジョニングサブネットの 2 番目の IP アドレスに設定されます。例: |
|
| ベアメタルネットワークに接続されたハイパーバイザーのベアメタルブリッジの名前。 |
|
|
プロビジョニングネットワークに接続されている |
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
|
ブートストラップノードのデフォルトのオペレーティングシステムイメージを上書きするための URL。URL にはイメージの SHA-256 ハッシュが含まれている必要があります。例: | |
|
| |
| このパラメーターを、環境内で使用する適切な HTTP プロキシーに設定します。 | |
| このパラメーターを、環境内で使用する適切な HTTPS プロキシーに設定します。 | |
| このパラメーターを、環境内のプロキシーの使用に対する例外のリストに設定します。 |
ホスト
hosts
パラメーターは、クラスターのビルドに使用される個別のベアメタルアセットのリストです。
名前 | デフォルト | 説明 |
---|---|---|
|
詳細情報に関連付ける | |
|
ベアメタルノードのロール。 | |
| ベースボード管理コントローラーの接続詳細。詳細は、BMC アドレス指定のセクションを参照してください。 | |
|
ホストがプロビジョニングネットワークに使用する NIC の MAC アドレス。Ironic は、 注記 プロビジョニングネットワークを無効にした場合は、ホストから有効な MAC アドレスを提供する必要があります。 | |
| このオプションのパラメーターを設定して、ホストのネットワークインターフェイスを設定します。詳細については、オプション: ホストネットワークインターフェイスの設定を参照してください。 |
13.3.7.3. 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>
BMC アドレス指定に IPMI を使用して PXE ブートする場合は、provisioning
ネットワークが必要です。provisioning
ネットワークなしでは、PXE ブートホストを行うことはできません。provisioning
ネットワークなしでデプロイする場合、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。詳細は、BMC addressing for HPE iLO セクションの Redfish virtual media for HPE iLO、または BMC addressing for Dell iDRAC セクションの 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
13.3.7.4. 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 は統合 Dell Remote Access Controller (iDRAC) 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。
Dell iDRAC の BMC アドレス形式
プロトコル | アドレスのフォーマット |
---|---|
iDRAC 仮想メディア |
|
Redfish ネットワークブート |
|
IPMI |
|
idrac-virtualmedia
を Redfish 仮想メディアのプロトコルとして使用します。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
ファームウェアバージョン 04.40.00.00
以降の Dell iDRAC 9 には、ベアメタルデプロイメントでのインストーラによるプロビジョニングインストールに関する既知の問題があります。Virtual Console プラグインは、HTML5 の拡張バージョンである eHTML5 にデフォルト設定されているため、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、HTML5 を使用するようにプラグインを設定します。メニューパスは以下の通りです。Configuration
OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration
idrac-virtualmedia://
を Redfish 仮想メディアのプロトコルとして使用します。redfish-virtualmedia://
の使用は、 idrac-virtualmedia://
プロトコルが idrac
ハードウェアタイプおよび Ironic の Redfish プロトコルに対応しているため、Dell ハードウェアでは機能しません。Dell の idrac-virtualmedia://
プロトコルは、Dell の OEM 拡張機能が含まれる Redfish 標準を使用します。Ironic は、WSMAN プロトコルのある idrac
タイプもサポートします。したがって、Dell ハードウェア上の仮想メディアで Redfish を使用する際に予期しない動作を回避するために、idrac-virtualmedia://
を指定する必要があります。
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/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
ファームウェアバージョン 04.40.00.00
を使用する Dell iDRAC 9 と、ベアメタルデプロイメントでインストーラーでプロビジョニングされるインストール用の 5.xx
シリーズを含むすべてのリリースには既知の問題があります。Virtual Console プラグインは、HTML5 の拡張バージョンである eHTML5 にデフォルト設定されているため、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、HTML5 を使用するようにプラグインを設定します。メニューパスは以下の通りです。Configuration
OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration
13.3.7.5. 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 integrated Lights Out (iLO) の場合、Red Hat は Redfish 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。
プロトコル | アドレスのフォーマット |
---|---|
Redfish 仮想メディア |
|
Redfish ネットワークブート |
|
IPMI |
|
詳細は、以下のセクションを参照してください。
HPE iLO の 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 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
13.3.7.6. 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 は、統合 Remote Management Controller (iRMC) および IPMI をサポートします。
プロトコル | アドレスのフォーマット |
---|---|
iRMC |
|
IPMI |
|
iRMC
Fujitsu ノードは irmc://<out-of-band-ip>
を使用し、デフォルトではポート 443
に設定されます。以下の例は、install-config.yaml
ファイル内の iRMC 設定を示しています。
platform: baremetal: hosts: - name: openshift-master-0 role: master bmc: address: irmc://<out-of-band-ip> username: <user> password: <password>
現在 Fujitsu は、ベアメタルへのインストーラーでプロビジョニングされるインストール用に iRMC S5 ファームウェアバージョン 3.05P 以降をサポートしています。
13.3.7.7. ルートデバイスのヒント
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"
13.3.7.8. (オプション) プロキシー設定の設定
プロキシーを使用して 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 アドレスブロックを定義することはできません。各アドレスを個別に定義する必要があります。
13.3.7.9. (オプション) provisioning
ネットワークを使用しないデプロイ
provisioning
ネットワークなしに OpenShift Container Platformmake をデプロイするには、install-config.yaml
ファイルに以下の変更を加えます。
platform:
baremetal:
apiVIP: <api_VIP>
ingressVIP: <ingress_VIP>
provisioningNetwork: "Disabled" 1
- 1
provisioningNetwork
設定を追加して、必要な場合はこれをDisabled
に設定します。
PXE ブートには provisioning
ネットワークが必要です。provisioning
ネットワークなしでデプロイする場合、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。詳細は、BMC addressing for HPE iLO セクションの Redfish virtual media for HPE iLO、または BMC addressing for Dell iDRAC セクションの Redfish virtual media for Dell iDRAC セクションを参照してください。
13.3.7.10. (オプション) デュアルスタックネットワークを使用したデプロイ
デュアルスタックネットワークを仕様して OpenShift Container Platform クラスターをデプロイするには、install-config.yaml
ファイルで machineNetwork
、clusterNetwork
、および serviceNetwork
設定を編集します。それぞれの設定には、それぞれ 2 つの CIDR エントリーが必要です。最初の CIDR エントリーは IPv4 設定で、2 つ目の 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 アドレスおよび Ingress VIP アドレスはプライマリー IP アドレスファミリーである必要があります。現在、Red Hat は、IPv6 をプライマリー IP アドレスファミリーとして使用するデュアルスタック VIP またはデュアルスタックネットワークをサポートしていません。ただし、Red Hat は、IPv4 をプライマリー IP アドレスファミリーとして使用するデュアルスタックネットワークをサポートしています。したがって、IPv4 エントリーは、IPv6 エントリーの 前 になければなりません。
13.3.7.11. (オプション) ホストネットワークインターフェイスの設定
インストールの前に、install-config.yaml
ファイルで networkConfig
設定を設定し、NMState を使用してホストネットワークインターフェイスを設定できます。
この機能の最も一般的な使用例は、ベアメタルネットワークで静的 IP アドレスを指定することですが、ストレージネットワークなどの他のネットワークを設定することもできます。この機能は、VLAN、VXLAN、ブリッジ、ボンド、ルート、MTU、DNS リゾルバー設定など、他の NMState 機能をサポートします。
前提条件
-
静的 IP アドレスを持つ各ノードの有効なホスト名で
PTR
DNS レコードを設定する。 -
NMState CLI (
nmstate
) をインストールする。
手順
オプション: インストーラーは NMState YAML 構文をチェックしないため、
install-config.yaml
ファイルに含める前にnmstatectl gc
で NMState 構文をテストすることを検討してください。注記YAML 構文にエラーがあると、ネットワーク設定の適用に失敗する可能性があります。さらに、検証済みの YAML 構文を維持すると、デプロイ後に Kubernetes NMState を使用して変更を適用する場合、またはクラスターを拡張する場合に役立ちます。
NMState YAML ファイルを作成します。
interfaces: - name: <nic1_name> 1 type: ethernet state: up ipv4: address: - ip: <ip_address> 2 prefix-length: 24 enabled: true dns-resolver: config: server: - <dns_ip_address> 3 routes: config: - destination: 0.0.0.0/0 next-hop-address: <next_hop_ip_address> 4 next-hop-interface: <next_hop_nic1_name> 5
次のコマンドを実行して、設定ファイルをテストします。
$ nmstatectl gc <nmstate_yaml_file>
<nmstate_yaml_file>
を設定ファイル名に置き換えます。
install-config.yaml
ファイル内のホストに NMState 設定を追加して、networkConfig
設定を使用します。hosts: - name: openshift-master-0 role: master bmc: address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/ username: <user> password: <password> disableCertificateVerification: null bootMACAddress: <NIC1_mac_address> bootMode: UEFI rootDeviceHints: deviceName: "/dev/sda" networkConfig: 1 interfaces: - name: <nic1_name> 2 type: ethernet state: up ipv4: address: - ip: <ip_address> 3 prefix-length: 24 enabled: true dns-resolver: config: server: - <dns_ip_address> 4 routes: config: - destination: 0.0.0.0/0 next-hop-address: <next_hop_ip_address> 5 next-hop-interface: <next_hop_nic1_name> 6
重要クラスターをデプロイした後、
install-config.yaml
ファイルのnetworkConfig
設定を変更して、ホストネットワークインターフェイスを変更することはできません。Kubernetes NMState Operator を使用して、デプロイ後にホストネットワークインターフェイスに変更を加えます。
関連情報
- NMState 構文のその他の例については、NMState のドキュメント を参照してください。
- OpenShift Container Platform 4.10 リリースノート
13.3.7.12. サブネット用のホストネットワークインターフェイスの設定
エッジコンピューティングのシナリオでは、ワーカーノードをエッジの近くに配置することが有益な場合があります。サブネット内のリモートワーカーノードを見つけるには、コントロールプレーンサブネットやローカルワーカーノードに使用したものとは異なるネットワークセグメントまたはサブネットをリモートワーカーノードに使用できます。エッジコンピューティングシナリオ用にサブネットを設定することで、エッジのレイテンシーが短縮され、拡張性が向上します。
「サブネット間の通信を確率する」セクションの説明どおりにリモートワーカーノードに異なるネットワークセグメントまたはサブネットを確立した場合、ワーカーが静的 IP アドレス、ボンド、またはその他の高度なネットワークを使用している場合は、machineNetwork
設定でサブネットを指定する必要があります。各リモートワーカーノードの networkConfig
パラメーターでノード IP アドレスを設定する場合、静的 IP アドレスを使用する際に、コントロールプレーンノードを含むサブネットのゲートウェイと DNS サーバーも指定する必要があります。これにより、リモートワーカーノードがコントロールプレーンノードを含むサブネットに到達し、コントロールプレーンからネットワークトラフィックを受信できるようになります。
すべてのコントロールプレーンノードは同じサブネット内で実行する必要があります。複数のサブネットを使用する場合、マニフェストを使用して、コントロールプレーンノード上で実行されるように Ingress VIP を設定することもできます。詳細は、「コントロールプレーンで実行するネットワークコンポーネントの設定」を参照してください。
複数のサブネットを持つクラスターをデプロイするには、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディアを使用する必要があります。
手順
静的 IP アドレスを使用する場合は、
install-config.yaml
ファイルのmachineNetwork
にサブネットを追加します。networking: machineNetwork: - cidr: 10.0.0.0/24 - cidr: 192.168.0.0/24 networkType: OVNKubernetes
静的 IP アドレスまたはボンドなどの高度なネットワークを使用する場合は、NMState 構文を使用して、各エッジワーカーノードの
networkConfig
パラメーターにゲートウェイと DNS 設定を追加します。networkConfig: nmstate: interfaces: - name: <interface_name> 1 type: ethernet state: up ipv4: enabled: true dhcp: false address: - ip: <node_ip> 2 prefix-length: 24 gateway: <gateway_ip> 3 dns-resolver: config: server: - <dns_ip> 4
13.3.7.13. 複数のクラスターノードの設定
同じ設定で OpenShift Container Platform クラスターノードを同時に設定できます。複数のクラスターノードを設定すると、各ノードの冗長な情報が install-config.yaml
ファイルに追加されることを回避できます。このファイルには、クラスター内の複数のノードに同一の設定を適用するための特定のパラメーターが含まれています。
コンピュートノードは、コントローラーノードとは別に設定されます。ただし、両方のノードタイプの設定では、install-config.yaml
ファイルで強調表示されているパラメーターを使用して、マルチノード設定を有効にします。次の例に示すように、networkConfig
パラメーターを BOND
に設定します。
hosts: - name: ostest-master-0 [...] networkConfig: &BOND interfaces: - name: bond0 type: bond state: up ipv4: dhcp: true enabled: true link-aggregation: mode: active-backup port: - enp2s0 - enp3s0 - name: ostest-master-1 [...] networkConfig: *BOND - name: ostest-master-2 [...] networkConfig: *BOND
複数のクラスターノードの設定は、インストーラーによってプロビジョニングされたインフラストラクチャーでの初期デプロイメントでのみ使用できます。
13.3.7.14. (オプション) マネージドセキュアブートの設定
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: <username> 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 のサポートはありません。
13.3.8. マニフェスト設定ファイル
13.3.8.1. 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
13.3.8.2. (オプション) 非接続クラスターの NTP 設定
OpenShift Container Platform は、クラスターノードに chrony
Network Time Protocol (NTP) サービスをインストールします。
![非接続クラスター向けの NTP 設定](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Installing-ja-JP/images/5e2bf8daa349716d7e204d523b95c48a/152_OpenShift_Config_NTP_0421.png)
OpenShift Container Platform ノードは、正しく実行するために日時について合意する必要があります。ワーカーノードがコントロールプレーンノードの NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続されていないクラスターのインストールおよび操作が有効になるため、上位の stratum の NTP サーバーにアクセスできなくなります。
手順
コントロールプレーンノードの
chrony.conf
ファイルのコンテンツを含む Butane 設定 (99-master-chrony-conf-override.bu
) を作成します。注記Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。
Butane 設定例
variant: openshift version: 4.10.0 metadata: name: 99-master-chrony-conf-override labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # Use public servers from the pool.ntp.org project. # Please consider joining the pool (https://www.pool.ntp.org/join.html). # The Machine Config Operator manages this file server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony # Configure the control plane nodes to serve as local NTP servers # for all worker nodes, even if they are not in sync with an # upstream NTP server. # Allow NTP client access from the local network. allow all # Serve time even if not synchronized to a time source. local stratum 3 orphan
- 1
<cluster-name>
はクラスターの名前に置き換え、<domain>
は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、コントロールプレーンノードに配信される設定が含まれる
MachineConfig
オブジェクトファイル (99-master-chrony-conf-override.yaml
) を生成します。$ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
コントロールプレーンノードの NTP サーバーを参照するワーカーノードの
chrony.conf
ファイルのコンテンツを含む Butane 設定 (99-worker-chrony-conf-override.bu
) を作成します。Butane 設定例
variant: openshift version: 4.10.0 metadata: name: 99-worker-chrony-conf-override labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # The Machine Config Operator manages this file. server openshift-master-0.<cluster-name>.<domain> iburst 1 server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony
- 1
<cluster-name>
はクラスターの名前に置き換え、<domain>
は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、ワーカーノードに配信される設定が含まれる
MachineConfig
オブジェクトファイル (99-worker-chrony-conf-override.yaml
) を生成します。$ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
13.3.8.3. (オプション) コントロールプレーンで実行されるネットワークコンポーネントの設定
コントロールプレーンノードでのみ実行されるようにネットワークコンポーネントを設定します。デフォルトで、OpenShift Container Platform はマシン設定プールの任意のノードが ingressVIP
仮想 IP アドレスをホストできるようにします。ただし、多くの環境は、コントロールプレーンノードとは異なるサブネットにワーカーノードをデプロイします。リモートワーカーを別々のサブネットにデプロイする場合は、コントロールプレーンノード専用に ingressVIP
仮想 IP アドレスを配置する必要があります。
![インストーラーがプロビジョニングしたネットワーク](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Installing-ja-JP/images/942999959aaf1ea56f554b78e481b40f/161_OpenShift_Baremetal_IPI_Deployment_updates_0521.png)
手順
install-config.yaml
ファイルを保存するディレクトリーに移動します。$ cd ~/clusterconfigs
manifests
サブディレクトリーに切り替えます。$ cd manifests
cluster-network-avoid-workers-99-config.yaml
という名前のファイルを作成します。$ touch cluster-network-avoid-workers-99-config.yaml
エディターで
cluster-network-avoid-workers-99-config.yaml
ファイルを開き、Operator 設定を記述するカスタムリソース (CR) を入力します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 50-worker-fix-ipi-rwn labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/kubernetes/manifests/keepalived.yaml mode: 0644 contents: source: data:,
このマニフェストは、
ingressVIP
仮想 IP アドレスをコントロールプレーンノードに配置します。また、このマニフェストは、コントロールプレーンノードにのみ以下のプロセスをデプロイします。-
openshift-ingress-operator
-
keepalived
-
-
cluster-network-avoid-workers-99-config.yaml
ファイルを保存します。 manifests/cluster-ingress-default-ingresscontroller.yaml
ファイルを作成します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/master: ""
-
manifests
ディレクトリーのバックアップの作成を検討してください。インストーラーは、クラスターの作成時にmanifests/
ディレクトリーを削除します。 cluster-scheduler-02-config.yml
マニフェストを変更し、mastersSchedulable
フィールドをtrue
に設定して、コントロールプレーンノードをスケジュール対象にします。デフォルトでは、コントロールプレーンノードはスケジュール対象ではありません。以下に例を示します。$ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml
注記この手順の完了後にコントロールプレーンノードをスケジュールできない場合には、クラスターのデプロイに失敗します。
13.3.8.4. (オプション) ワーカーノードへのルーターのデプロイ
インストール時に、インストーラーはルーター Pod をワーカーノードにデプロイします。デフォルトで、インストーラーは 2 つのルーター Pod をインストールします。デプロイされたクラスターが、OpenShift Container Platform クラスター内のサービスに対して予定される外部トラフィック負荷を処理するために追加のルーターを必要とする場合、yaml
ファイルを作成して適切なルーターレプリカ数を設定できます。
ワーカーノードが 1 つだけのクラスターのデプロイはサポートされていません。ルーターのレプリカを変更することで、1 つのワーカーでデプロイする場合の degraded
状態の問題は対処されますが、クラスターは Ingress API の高可用性を失うため、これは実稼働環境には適しません。
デフォルトで、インストーラーは 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
13.3.8.5. (オプション) ワーカーノードの BIOS の設定
次の手順では、インストールプロセス中にワーカーノードの BIOS を設定します。
手順
- マニフェストを作成します。
ワーカーに対応する BMH ファイルを変更します。
$ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-3.yaml
BMH ファイルの
spec
セクションに BIOS 設定を追加します。spec: firmware: simultaneousMultithreadingEnabled: true sriovEnabled: true virtualizationEnabled: true
注記-
Red Hat は 3 つの BIOS 設定をサポートしています。詳細は、 BMH のドキュメント を参照してください。BMC タイプ
irmc
のサーバーのみがサポートされます。他のタイプのサーバーは現在サポートされていません。
-
Red Hat は 3 つの BIOS 設定をサポートしています。詳細は、 BMH のドキュメント を参照してください。BMC タイプ
- クラスターを作成します。
関連情報
13.3.8.6. (オプション) ワーカーノードの RAID の設定
次の手順では、インストールプロセス中にワーカーノードの RAID (Redundant Array of Independent Disks) を設定します。
- OpenShift Container Platform は、iRMC プロトコルのみを使用してベースボード管理コントローラー (BMC) のハードウェア RAID をサポートします。OpenShift Container Platform 4.10 は、ソフトウェア RAID をサポートしていません。
- ノードにハードウェア RAID を設定する場合は、ノードに RAID コントローラーがあることを確認します。
手順
- マニフェストを作成します。
ワーカーに対応する BMH (Bare Metal Host) ファイルを変更します。
$ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-3.yaml
注記OpenShift Container Platform 4.10 はソフトウェア RAID をサポートしていないため、以下の例ではハードウェア RAID 設定を使用します。
特定の RAID 設定を
spec
セクションに追加した場合、これが原因でワーカーノードはpreparing
フェーズで元の RAID 設定を削除し、RAID で指定された設定を実行します。以下は例になります。spec: raid: hardwareRAIDVolumes: - level: "0" 1 name: "sda" numberOfPhysicalDisks: 1 rotational: true sizeGibibytes: 0
- 1
level
は必須フィールドであり、その他はオプションのフィールドです。
空の RAID 設定を
spec
セクションに追加した場合、この空の設定により、ワーカーノードはpreparing
フェーズで元の RAID 設定を削除しますが、新しい設定は実行しません。以下は例になります。spec: raid: hardwareRAIDVolumes: []
-
spec
セクションにraid
フィールドを追加しない場合、元の RAID 設定は削除されず、新しい設定は実行されません。
- クラスターを作成します。
関連情報
13.3.9. 非接続レジストリーの作成
インストールレジストリーのローカルコピーを使用して OpenShift Container Platform クラスターをインストールする必要がある場合があります。これにより、クラスターノードがインターネットにアクセスできないネットワーク上にあるため、ネットワークの効率が高まる可能性があります。
レジストリーのローカルまたはミラーリングされたコピーには、以下が必要です。
- レジストリーの証明書。これには、自己署名証明書を使用できます。
- システム上のコンテナーが提供する Web サーバー。
- 証明書およびローカルリポジトリーの情報が含まれる更新されたプルシークレット。
レジストリーノードでの非接続レジストリーの作成はオプションです。レジストリーノードで切断されたレジストリーを作成する必要がある場合は、次のサブセクションをすべて完了する必要があります。
前提条件
- 非接続インストールのイメージのミラーリング 用にミラーレジストリーをすでに準備している場合は、非接続レジストリーを使用するように install-config.yaml ファイルを変更する へそのままスキップできます。
13.3.9.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}
13.3.9.2. 切断されたレジストリーの OpenShift Container Platform イメージリポジトリーのミラーリング
以下の手順を実行して、切断されたレジストリーの OpenShift Container Platform イメージリポジトリーをミラーリングします。
前提条件
- ミラーホストがインターネットにアクセスできる。
- ネットワークが制限された環境で使用するミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできる。
- Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を含めるようにこれを変更している。
手順
- OpenShift Container Platform ダウンロード ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、Repository Tags ページで対応するタグを判別します。
必要な環境変数を設定します。
リリースバージョンをエクスポートします。
$ OCP_RELEASE=<release_version>
<release_version>
について、インストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例:4.5.4
)。ローカルレジストリー名とホストポートをエクスポートします。
$ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
<local_registry_host_name>
については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port>
については、コンテンツの送信に使用するポートを指定します。ローカルリポジトリー名をエクスポートします。
$ LOCAL_REPOSITORY='<local_repository_name>'
<local_repository_name>
については、ocp4/openshift4
などのレジストリーに作成するリポジトリーの名前を指定します。ミラーリングするリポジトリーの名前をエクスポートします。
$ PRODUCT_REPO='openshift-release-dev'
実稼働環境のリリースの場合には、
openshift-release-dev
を指定する必要があります。パスをレジストリープルシークレットにエクスポートします。
$ LOCAL_SECRET_JSON='<path_to_pull_secret>'
<path_to_pull_secret>
については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。リリースミラーをエクスポートします。
$ RELEASE_NAME="ocp-release"
実稼働環境のリリースについては、
ocp-release
を指定する必要があります。サーバーのアーキテクチャーのタイプをエクスポートします (例:
x86_64
)。$ ARCHITECTURE=<server_architecture>
ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。
$ REMOVABLE_MEDIA_PATH=<path> 1
- 1
- 最初のスラッシュ (/) 文字を含む完全パスを指定します。
バージョンイメージをミラーレジストリーにミラーリングします。
ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。
- リムーバブルメディアをインターネットに接続しているシステムに接続します。
ミラーリングするイメージおよび設定マニフェストを確認します。
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
-
直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。 イメージをリムーバブルメディア上のディレクトリーにミラーリングします。
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。
$ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1
- 1
REMOVABLE_MEDIA_PATH
の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。
ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。
以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な
imageContentSources
データが含まれます。直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。注記ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。
ミラーリングしたコンテンツをベースとしているインストールプログラムを作成するには、これをデプロイメントし、リリースに固定します。
ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下のコマンドを実行します。
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
重要選択した OpenShift Container Platform バージョンに適したイメージを使用するには、ミラーリングされたコンテンツからインストールプログラムをデプロイメントする必要があります。
インターネット接続のあるマシンで、このステップを実行する必要があります。
非接続環境を使用している場合には、must-gather の一部として
--image
フラグを使用し、ペイロードイメージを参照します。
インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの場合は、以下のコマンドを実行します。
$ openshift-install
13.3.9.3. 非接続レジストリーを使用するように install-config.yaml ファイルを変更する
プロビジョナーノードでは、install-config.yaml
ファイルは pull-secret-update.txt
ファイルから新たに作成された pull-secret を使用する必要があります。install-config.yaml
ファイルには、非接続レジストリーノードの証明書およびレジストリー情報も含まれる必要があります。
手順
非接続レジストリーノードの証明書を
install-config.yaml
ファイルに追加します。$ echo "additionalTrustBundle: |" >> install-config.yaml
証明書は
"additionalTrustBundle: |"
行に従い、通常は 2 つのスペースで適切にインデントされる必要があります。$ 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
registry.example.com
をレジストリーの完全修飾ドメイン名に置き換えます。$ 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
registry.example.com
をレジストリーの完全修飾ドメイン名に置き換えます。$ echo " source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml
13.3.10. ブートストラップ VM への静的 IP アドレスの割り当て
baremetal
ネットワークに DHCP サーバーを使用せずに OpenShift Container Platform をデプロイする場合は、Ignition を使用してブートストラップ VM の静的 IP アドレスを設定する必要があります。
手順
Ignition 設定ファイルを作成します。
$ ./openshift-baremetal-install --dir <cluster_configs> create ignition-configs
<cluster_configs>
をクラスター設定ファイルへのパスに置き換えます。bootstrap_config.sh
ファイルを作成します。#!/bin/bash BOOTSTRAP_CONFIG="[connection] type=ethernet interface-name=ens3 [ethernet] [ipv4] method=manual addresses=<ip_address>/<cidr> gateway=<gateway_ip_address> dns=<dns_ip_address>" cat <<_EOF_ > bootstrap_network_config.ign { "path": "/etc/NetworkManager/system-connections/ens3.nmconnection", "mode": 384, "contents": { "source": "data:text/plain;charset=utf-8;base64,$(echo "${BOOTSTRAP_CONFIG}" | base64 -w 0)" } } _EOF_ mv <cluster_configs>/bootstrap.ign <cluster_configs>/bootstrap.ign.orig jq '.storage.files += $input' <cluster_configs>/bootstrap.ign.orig --slurpfile input bootstrap_network_config.ign > <cluster_configs>/bootstrap.ign
<ip_address>
と<cidr>
をアドレス範囲の IP アドレスと CIDR に置き換えます。<gateway_ip_address>
を、baremetal
ネットワークのゲートウェイの IP アドレスに置き換えます。<dns_ip_address>
をbaremetal
ネットワーク上の DNS サーバーの IP アドレスに置き換えます。<cluster_configs>
をクラスター設定ファイルへのパスに置き換えます。bootstrap_config.sh
ファイルを実行可能にします。$ chmod 755 bootstrap_config.sh
bootstrap_config.sh
スクリプトを実行して、bootstrap_network_config.ign
ファイルを作成します。$ ./bootstrap_config.sh
13.3.11. インストールの検証チェックリスト
- ❏ OpenShift Container Platform インストーラーが取得されている。
- ❏ OpenShift Container Platform インストーラーがデプロイメントされている。
-
❏
install-config.yaml
の必須パラメーターが設定されている。 -
❏
install-config.yaml
のhosts
パラメーターが設定されている。 -
❏
install-config.yaml
のbmc
パラメーターが設定されている。 -
❏
bmc
address
フィールドで設定されている値の変換が適用されている。 - ❏ OpenShift Container Platform マニフェストが作成されている。
- ❏ (オプション) ルーターをワーカーノードにデプロイしている。
- ❏ (オプション) 切断されたレジストリーを作成している。
- ❏ (オプション) 非接続レジストリー設定が使用されている場合にこれを検証する。
13.3.12. OpenShift Container Platform インストーラーを使用したクラスターのデプロイ
OpenShift Container Platform インストーラーを実行します。
$ ./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster
13.3.13. インストール後
デプロイメントプロセスで、tail
コマンドを install ディレクトリーフォルダーの .openshift_install.log
ログファイルに対して実行して、インストールの全体のステータスを確認できます。
$ tail -f /path/to/install-dir/.openshift_install.log
13.3.14. 静的 IP アドレス設定の検証
クラスターノードの DHCP 予約で無限リースが指定されている場合、インストーラーがノードを正常にプロビジョニングした後に、dispatcher スクリプトはノードのネットワーク設定をチェックします。ネットワーク設定に無限 DHCP リースが含まれているとスクリプトが判断すると、DHCP リースの IP アドレスを静的 IP アドレスとして使用して新規接続を作成します。
dispatcher スクリプトは、クラスター内の他のノードのプロビジョニングの進行中に、正常にプロビジョニングされたノードで実行される場合があります。
ネットワーク設定が正しく機能していることを確認します。
手順
- ノードのネットワークインターフェイス設定を確認してください。
- DHCP サーバーをオフにし、OpenShift Container Platform ノードを再起動して、ネットワーク設定が適切に機能していることを確認します。