検索

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

download PDF

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

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

10.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 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 プロトコルに設定されていることを確認します。

  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 ユーザーのホームディレクトリーに保存します。

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

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

$ export VERSION=stable-4.9
export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}')

10.3.4. OpenShift Container Platform インストールの展開

インストーラーの取得後、次のステップとしてこれを展開します。

手順

  1. 環境変数を設定します。

    $ export cmd=openshift-baremetal-install
    $ export pullsecret_file=~/pull-secret.txt
    $ export extract_dir=$(pwd)
  2. oc バイナリーを取得します。

    $ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc
  3. インストーラーを実行します。

    $ sudo cp oc /usr/local/bin
    $ oc adm release extract --registry-config "${pullsecret_file}" --command=$cmd --to "${extract_dir}" ${RELEASE_IMAGE}
    $ sudo cp openshift-baremetal-install /usr/local/bin

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

イメージのキャッシュを使用するには、ブートストラップ仮想マシンによって使用される 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 /home/kni/rhcos_image_cache/
  5. インストールプログラムがブートストラップ VM にデプロイする RHCOS イメージの URI を取得します。

    $ export RHCOS_QEMU_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk.location')
  6. インストールプログラムがブートストラップ VM にデプロイするイメージの名前を取得します。

    $ export export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
  7. ノードにデプロイされる RHCOS イメージの SHA ハッシュを取得します。

    $ export RHCOS_QEMU_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk["uncompressed-sha256"]')
  8. インストールプログラムがクラスターノードにデプロイするイメージの URI を取得します。

    $ export RHCOS_OPENSTACK_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.openstack.formats["qcow2.gz"].disk.location')
  9. インストールプログラムがクラスターノードにデプロイするイメージの名前を取得します。

    $ export RHCOS_OPENSTACK_NAME=${RHCOS_OPENSTACK_URI##*/}
  10. インストールプログラムがクラスターノードに展開するイメージの SHA ハッシュを取得します。

    $ export RHCOS_OPENSTACK_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.openstack.formats["qcow2.gz"].disk["uncompressed-sha256"]')
  11. イメージをダウンロードして、それらを /home/kni/rhcos_image_cache ディレクトリーに配置します。

    $ curl -L ${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_NAME}
    $ curl -L ${RHCOS_OPENSTACK_URI} -o /home/kni/rhcos_image_cache/${RHCOS_OPENSTACK_NAME}
  12. SELinux タイプが、新しく作成されたファイルの httpd_sys_content_t であることを確認します。

    $ ls -Z /home/kni/rhcos_image_cache
  13. Pod を作成します。

    $ podman run -d --name rhcos_image_cache \
    -v /home/kni/rhcos_image_cache:/var/www/html \
    -p 8080:8080/tcp \
    quay.io/centos7/httpd-24-centos7:latest

    上記のコマンドは、デプロイメントのイメージを提供する rhcos_image_cache という名前のキャッシュ Web サーバーを作成します。最初のイメージ ${RHCOS_PATH}${RHCOS_QEMU_URI}?sha256=${RHCOS_QEMU_SHA_UNCOMPRESSED}bootstrapOSImage で、2 つ目のイメージ ${RHCOS_PATH}${RHCOS_OPENSTACK_URI}?sha256=${RHCOS_OPENSTACK_SHA_COMPRESSED}install-config.yaml ファイルの clusterOSImage です。

  14. bootstrapOSImage および clusterOSImage 設定を生成します。

    $ export BAREMETAL_IP=$(ip addr show dev baremetal | awk '/inet /{print $2}' | cut -d"/" -f1)
    $ export BOOTSTRAP_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_QEMU_NAME}?sha256=${RHCOS_QEMU_UNCOMPRESSED_SHA256}"
    $ export CLUSTER_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_OPENSTACK_NAME}?sha256=${RHCOS_OPENSTACK_UNCOMPRESSED_SHA256}"
    $ echo "    bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}"
    $ echo "    clusterOSImage=${CLUSTER_OS_IMAGE}"
  15. platform.baremetal 下の install-config.yaml ファイルに必要な設定を追加します。

    platform:
      baremetal:
        bootstrapOSImage: <bootstrap_os_image>  1
        clusterOSImage: <cluster_os_image>  2
    1
    <bootstrap_os_image>$BOOTSTRAP_OS_IMAGE の値に置き換えます。
    2
    <cluster_os_image>$CLUSTER_OS_IMAGE の値に置き換えます。

    詳細は、設定ファイルのセクションを参照してください。

10.3.6. 設定ファイル

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

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

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

    apiVersion: v1
    baseDomain: <domain>
    metadata:
      name: <cluster-name>
    networking:
      machineNetwork:
      - cidr: <public-cidr>
      networkType: OVNKubernetes
    compute:
    - name: worker
      replicas: 2 1
    controlPlane:
      name: master
      replicas: 3
      platform:
        baremetal: {}
    platform:
      baremetal:
        apiVIP: <api-ip>
        ingressVIP: <wildcard-ip>
        provisioningNetworkCIDR: <CIDR>
        hosts:
          - name: openshift-master-0
            role: master
            bmc:
              address: ipmi://<out-of-band-ip> 2
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            rootDeviceHints:
             deviceName: "/dev/disk/by-id/<disk_id>" 3
          - name: <openshift-master-1>
            role: master
            bmc:
              address: ipmi://<out-of-band-ip> 4
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            rootDeviceHints:
             deviceName: "/dev/disk/by-id/<disk_id>" 5
          - name: <openshift-master-2>
            role: master
            bmc:
              address: ipmi://<out-of-band-ip> 6
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            rootDeviceHints:
             deviceName: "/dev/disk/by-id/<disk_id>" 7
          - name: <openshift-worker-0>
            role: worker
            bmc:
              address: ipmi://<out-of-band-ip> 8
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
          - name: <openshift-worker-1>
            role: worker
            bmc:
              address: ipmi://<out-of-band-ip>
              username: <user>
              password: <password>
            bootMACAddress: <NIC1-mac-address>
            rootDeviceHints:
             deviceName: "/dev/disk/by-id/<disk_id>" 9
    pullSecret: '<pull_secret>'
    sshKey: '<ssh_pub_key>'
    1
    OpenShift Container Platform クラスターの一部であるワーカーノードの数に基づいてワーカーマシンをスケーリングします。replicas 値の有効なオプションは 0 で、2 以上の整数です。3 ノードクラスターのみが含まれる 3 ノードクラスターをデプロイするには、レプリカ数を 0 に設定します。3 ノードクラスターは、テスト、開発、本番に使用できる、より小さく、よりリソース効率の良いクラスターです。ワーカーを 1 つだけにしてクラスターをインストールすることはできません。
    2 4 6 8
    その他のオプションについては、BMC アドレス指定のセクションを参照してください。
    3 5 7 9
    インストールディスクドライブへのパスを設定します (例: /dev/disk/by-id/wwn-0x64cd98f04fde100024684cf3034da5c2)
  2. クラスター設定を保存するディレクトリーを作成します。

    $ mkdir ~/clusterconfigs
    $ cp install-config.yaml ~/clusterconfigs
  3. OpenShift Container Platform クラスターをインストールする前に、すべてのベアメタルノードの電源がオフになっていることを確認します。

    $ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
  4. 以前に試行したデプロイメントにより古いブートストラップリソースが残っている場合は、これを削除します。

    for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
    do
      sudo virsh destroy $i;
      sudo virsh undefine $i;
      sudo virsh vol-delete $i --pool $i;
      sudo virsh vol-delete $i.ign --pool $i;
      sudo virsh pool-destroy $i;
      sudo virsh pool-undefine $i;
    done

10.3.6.2. install-config.yaml ファイル内でのプロキシー設定 (オプション)

プロキシーを使用して OpenShift Container Platform クラスターをデプロイするには、 install-config.yaml ファイルに以下の変更を加えます。

apiVersion: v1
baseDomain: <domain>
proxy:
  httpProxy: http://USERNAME:PASSWORD@proxy.example.com:PORT
  httpsProxy: https://USERNAME:PASSWORD@proxy.example.com:PORT
  noProxy: <WILDCARD_OF_DOMAIN>,<PROVISIONING_NETWORK/CIDR>,<BMC_ADDRESS_RANGE/CIDR>

以下は、値を含む noProxy の例です。

noProxy: .example.com,172.22.0.0/24,10.10.0.0/24

プロキシーを有効な状態にして、対応するキー/値のペアでプロキシーの適切な値を設定します。

主な留意事項:

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

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

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

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-virtualmediaidrac-virtualmedia などの仮想メディア BMC アドレス指定オプションを使用する必要があります。詳細は、BMC addressing for HPE iLO セクションの Redfish virtual media for HPE iLO、または BMC addressing for Dell iDRAC セクションの Redfish virtual media for Dell iDRAC セクションを参照してください。

10.3.6.4. dual-stack ネットワーク用の install-config.yaml ファイルの変更 (オプション)

デュアルスタックネットワークを仕様して OpenShift Container Platform クラスターをデプロイするには、install-config.yaml ファイルで machineNetworkclusterNetwork、および 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 エントリーの になければなりません。

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

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

注記

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

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

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

表10.3 必須パラメーター
パラメーターデフォルト説明

baseDomain

 

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

bootMode

UEFI

ノードのブートモード。オプションは、legacyUEFI、および UEFISecureBoot です。bootMode が設定されていない場合は、ノードを検査する間に Ironic がこれを設定します。

sshKey

 

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

pullSecret

 

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

metadata:
    name:
 

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

networking:
    machineNetwork:
    - cidr:
 

外部ネットワークの公開 CIDR (Classless Inter-Domain Routing)。例: 10.0.0.0/24

compute:
  - name: worker
 

OpenShift Container Platform クラスターでは、ノードがゼロであってもワーカー (またはコンピュート) ノードの名前を指定する必要があります。

compute:
    replicas: 2
 

レプリカは、OpenShift Container Platform クラスターのワーカー (またはコンピュート) ノードの数を設定します。

controlPlane:
    name: master
 

OpenShift Container Platform クラスターには、コントロールプレーン (マスター) ノードの名前が必要です。

controlPlane:
    replicas: 3
 

レプリカは、OpenShift Container Platform クラスターの一部として含まれるコントロールプレーン (マスター) ノードの数を設定します。

provisioningNetworkInterface

 

provisioning ネットワークに接続されたノード上のネットワークインターフェイス名。OpenShift Container Platform 4.9 以降のリリースのために、NIC の名前を識別するために provisioningNetworkInterface 設定を使用する代わりに、Ironic が NIC の IP アドレスを識別できるように bootMACAddress 設定を使用します。

defaultMachinePlatform

 

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

apiVIP

 

(オプション) Kubernetes API 通信の仮想 IP アドレス。

この設定は、Machine Network からの予約済み IP として install-config.yaml ファイルで提供するか、デフォルト名が正しく解決されるように DNS で事前設定する必要があります。install-config.yaml ファイルの apiVIP 設定設定に値を追加するときは、FQDN ではなく仮想 IP アドレスを使用してください。デュアルスタックネットワークを使用する場合には、IP アドレスはプライマリー IPv4 ネットワークからのものである必要があります。設定されていない場合、インストーラーは api.<cluster_name>.<base_domain> を使用して DNS から IP アドレスを取得します。

disableCertificateVerification

False

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

ingressVIP

 

(オプション) Ingress トラフィックの仮想 IP アドレス。

この設定は、Machine Network からの予約済み IP として install-config.yaml ファイルで提供するか、デフォルト名が正しく解決されるように DNS で事前設定する必要があります。install-config.yaml ファイルの ingressVIP 設定設定に値を追加するときは、FQDN ではなく仮想 IP アドレスを使用してください。デュアルスタックネットワークを使用する場合には、IP アドレスはプライマリー IPv4 ネットワークからのものである必要があります。設定されていない場合、インストーラーは test.apps.<cluster_name>.<base_domain> を使用して DNS から IP アドレスを取得します。

表10.4 オプションのパラメーター
パラメーターデフォルト説明

provisioningDHCPRange

172.22.0.10,172.22.0.100

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

provisioningNetworkCIDR

172.22.0.0/24

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

clusterProvisioningIP

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

 

provisioningNetwork 設定は、クラスターが provisioning ネットワークを使用するかどうかを決定します。存在する場合、設定はクラスターがネットワークを管理するかどうかも決定します。

Disabled: provisioning ネットワークの要件を無効にするには、このパラメーターを Disabled に設定します。Disabled に設定すると、仮想メディアベースのプロビジョニングのみを使用するか、またはアシステッドインストーラーを使用してクラスターを起動する必要があります。Disabled にして、電源管理を使用する場合、BMC は baremetal ネットワークからアクセスできる必要があります。Disabled の場合は、プロビジョニングサービスに使用される baremetal ネットワークで 2 つの IP アドレスを指定する必要があります。

Managed: DHCP、TFTP などを含むプロビジョニングネットワークを完全に管理するには、このパラメーターを Managed(デフォルト) に設定します。

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

httpProxy

 

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

httpsProxy

 

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

noProxy

 

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

ホスト

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

表10.5 ホスト
名前デフォルト説明

name

 

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

role

 

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

bmc

 

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

bootMACAddress

 

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

注記

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

10.3.6.7. BMC アドレス指定

ほとんどのベンダーは、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-virtualmediaidrac-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

10.3.6.8. Dell iDRAC の BMC アドレス指定

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

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address> 1
          username: <user>
          password: <password>
1
address 設定はプロトコルを指定します。

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

Dell iDRAC の BMC アドレス形式
プロトコルアドレスのフォーマット

iDRAC 仮想メディア

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

Redfish ネットワークブート

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

IPMI

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

重要

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
注記

現時点で Redfish は、ベアメタルデプロイメント上のインストーラーでプロビジョニングされるインストール向け iDRAC ファームウェアのバージョン 4.20.20.20 から 04.40.00.00 のある Dell でのみサポートされます。バージョン 04.40.00.00 には既知の問題があります。iDRAC 9 ファームウェアバージョン 04.40.00.00 では、仮想コンソールプラグインがデフォルトで eHTML5 になり、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、プラグインを HTML5 に設定します。メニューパスは以下の通りです。Configuration Virtual console Plug-in Type HTML5

OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration Virtual Media Attach Mode 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:// を指定する必要があります。

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
注記

現時点で Redfish は、ベアメタルデプロイメント上のインストーラーでプロビジョニングされるインストール向け iDRAC ファームウェアのバージョン 4.20.20.20 から 04.40.00.00 の Dell ハードウェアでのみサポートされます。バージョン 04.40.00.00 には既知の問題があります。iDRAC 9 ファームウェアバージョン 04.40.00.00 では、仮想コンソールプラグインがデフォルトで eHTML5 になり、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、プラグインを HTML5 に設定します。メニューパスは以下の通りです。Configuration Virtual console Plug-in Type HTML5

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

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

10.3.6.9. HPE iLO の BMC アドレス指定

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

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address> 1
          username: <user>
          password: <password>
1
address 設定はプロトコルを指定します。

HPE integrated Lights Out (iLO) の場合、Red Hat は Redfish 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。

表10.6 HPE iLO の BMC アドレス形式
プロトコルアドレスのフォーマット

Redfish 仮想メディア

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

Redfish ネットワークブート

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

IPMI

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

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

HPE iLO の Redfish 仮想メディア

HPE サーバーについて RedFish 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

10.3.6.10. Fujitsu iRMC の BMC アドレス指定

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

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address> 1
          username: <user>
          password: <password>
1
address 設定はプロトコルを指定します。

Fujitsu ハードウェアの場合、Red Hat は、統合 Remote Management Controller (iRMC) および IPMI をサポートします。

表10.7 Fujitsu iRMC の BMC アドレス形式
プロトコルアドレスのフォーマット

iRMC

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

IPMI

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

iRMC

Fujitsu ノードは irmc://<out-of-band-ip> を使用し、デフォルトではポート 443 に設定されます。以下の例は、install-config.yaml ファイル内の iRMC 設定を示しています。

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: irmc://<out-of-band-ip>
          username: <user>
          password: <password>
注記

現在 Fujitsu は、ベアメタルへのインストーラーでプロビジョニングされるインストール用に iRMC S5 ファームウェアバージョン 3.05P 以降をサポートしています。

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

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

表10.8 サブフィールド
サブフィールド説明

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"

10.3.6.12. OpenShift Container Platform マニフェストの作成

  1. OpenShift Container Platform マニフェストを作成します。

    $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests
    INFO Consuming Install Config from target directory
    WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
    WARNING Discarding the OpenShift Manifest that was provided in the target directory because its dependencies are dirty and it needs to be regenerated

10.3.6.13. 非接続クラスター向けの NTP 設定 (オプション)

OpenShift Container Platform は、クラスターノードに chrony Network Time Protocol (NTP) サービスをインストールします。

OpenShift Container Platform ノードは、正しく実行するために日時について合意する必要があります。ワーカーノードがコントロールプレーンノードの NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続されていないクラスターのインストールおよび操作が有効になるため、上位の stratum の NTP サーバーにアクセスできなくなります。

手順

  1. コントロールプレーンノードの chrony.conf ファイルのコンテンツを含む Butane 設定 (99-master-chrony-conf-override.bu) を作成します。

    注記

    Butane の詳細は、Butane を使用したマシン設定の作成を参照してください。

    Butane 設定例

    variant: openshift
    version: 4.9.0
    metadata:
      name: 99-master-chrony-conf-override
      labels:
        machineconfiguration.openshift.io/role: master
    storage:
      files:
        - path: /etc/chrony.conf
          mode: 0644
          overwrite: true
          contents:
            inline: |
              # Use public servers from the pool.ntp.org project.
              # Please consider joining the pool (https://www.pool.ntp.org/join.html).
    
              # The Machine Config Operator manages this file
              server openshift-master-0.<cluster-name>.<domain> iburst 1
              server openshift-master-1.<cluster-name>.<domain> iburst
              server openshift-master-2.<cluster-name>.<domain> iburst
    
              stratumweight 0
              driftfile /var/lib/chrony/drift
              rtcsync
              makestep 10 3
              bindcmdaddress 127.0.0.1
              bindcmdaddress ::1
              keyfile /etc/chrony.keys
              commandkey 1
              generatecommandkey
              noclientlog
              logchange 0.5
              logdir /var/log/chrony
    
              # Configure the control plane nodes to serve as local NTP servers
              # for all worker nodes, even if they are not in sync with an
              # upstream NTP server.
    
              # Allow NTP client access from the local network.
              allow all
              # Serve time even if not synchronized to a time source.
              local stratum 3 orphan

    1
    <cluster-name> はクラスターの名前に置き換え、<domain> は完全修飾ドメイン名に置き換える必要があります。
  2. Butane を使用して、コントロールプレーンノードに配信される設定が含まれる MachineConfig オブジェクトファイル (99-master-chrony-conf-override.yaml) を生成します。

    $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
  3. コントロールプレーンノードの NTP サーバーを参照するワーカーノードの chrony.conf ファイルのコンテンツを含む Butane 設定 (99-worker-chrony-conf-override.bu) を作成します。

    Butane 設定例

    variant: openshift
    version: 4.9.0
    metadata:
      name: 99-worker-chrony-conf-override
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
        - path: /etc/chrony.conf
          mode: 0644
          overwrite: true
          contents:
            inline: |
              # The Machine Config Operator manages this file.
              server openshift-master-0.<cluster-name>.<domain> iburst 1
              server openshift-master-1.<cluster-name>.<domain> iburst
              server openshift-master-2.<cluster-name>.<domain> iburst
    
              stratumweight 0
              driftfile /var/lib/chrony/drift
              rtcsync
              makestep 10 3
              bindcmdaddress 127.0.0.1
              bindcmdaddress ::1
              keyfile /etc/chrony.keys
              commandkey 1
              generatecommandkey
              noclientlog
              logchange 0.5
              logdir /var/log/chrony

    1
    <cluster-name> はクラスターの名前に置き換え、<domain> は完全修飾ドメイン名に置き換える必要があります。
  4. Butane を使用して、ワーカーノードに配信される設定が含まれる MachineConfig オブジェクトファイル (99-worker-chrony-conf-override.yaml) を生成します。

    $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml

10.3.6.14. (オプション) コントロールプレーンで実行されるネットワークコンポーネントの設定

コントロールプレーンノードでのみ実行されるようにネットワークコンポーネントを設定します。デフォルトで、OpenShift Container Platform はマシン設定プールの任意のノードが ingressVIP 仮想 IP アドレスをホストできるようにします。ただし、多くの環境は、コントロールプレーンノードとは異なるサブネットにワーカーノードをデプロイします。リモートワーカーを別々のサブネットにデプロイする場合は、コントロールプレーンノード専用に ingressVIP 仮想 IP アドレスを配置する必要があります。

手順

  1. install-config.yaml ファイルを保存するディレクトリーに移動します。

    $ cd ~/clusterconfigs
  2. manifests サブディレクトリーに切り替えます。

    $ cd manifests
  3. cluster-network-avoid-workers-99-config.yaml という名前のファイルを作成します。

    $ touch cluster-network-avoid-workers-99-config.yaml
  4. エディターで cluster-network-avoid-workers-99-config.yaml ファイルを開き、Operator 設定を記述するカスタムリソース (CR) を入力します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: 50-worker-fix-ipi-rwn
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/kubernetes/manifests/keepalived.yaml
              mode: 0644
              contents:
                source: data:,

    このマニフェストは、 ingressVIP 仮想 IP アドレスをコントロールプレーンノードに配置します。また、このマニフェストは、コントロールプレーンノードにのみ以下のプロセスをデプロイします。

    • openshift-ingress-operator
    • keepalived
  5. cluster-network-avoid-workers-99-config.yaml ファイルを保存します。
  6. manifests/cluster-ingress-default-ingresscontroller.yaml ファイルを作成します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/master: ""
  7. manifests ディレクトリーのバックアップの作成を検討してください。インストーラーは、クラスターの作成時に manifests/ ディレクトリーを削除します。
  8. cluster-scheduler-02-config.yml マニフェストを変更し、mastersSchedulable フィールドを true に設定して、コントロールプレーンノードをスケジュール対象にします。デフォルトでは、コントロールプレーンノードはスケジュール対象ではありません。以下に例を示します。

    $ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml
    注記

    この手順の完了後にコントロールプレーンノードをスケジュールできない場合には、クラスターのデプロイに失敗します。

10.3.6.15. ワーカーノードの BIOS 設定

次の手順では、インストールプロセス中にワーカーノードの BIOS を設定します。

手順

  1. マニフェストの作成
  2. ワーカーに対応する BMH ファイルを変更します。

    $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-3.yaml
  3. BMH ファイルの spec セクションに BIOS 設定を追加します。

    spec:
      firmware:
        simultaneousMultithreadingEnabled: true
        sriovEnabled: true
        virtualizationEnabled: true
    注記
    1. Red Hat は 3 つの BIOS 設定をサポートしています。詳細は、 BMH のドキュメント を参照してください。bmc タイプ irmc のサーバーのみがサポートされます。他のタイプのサーバーは現在サポートされていません。
  4. クラスターを作成します。

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

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

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

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

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

10.3.7.1. ミラーリングされたレジストリーをホストするためのレジストリーノードの準備 (オプション)

レジストリーノードに以下の変更を加えます。

手順

  1. レジストリーノードでファイアウォールポートを開きます。

    $ sudo firewall-cmd --add-port=5000/tcp --zone=libvirt  --permanent
    $ sudo firewall-cmd --add-port=5000/tcp --zone=public   --permanent
    $ sudo firewall-cmd --reload
  2. レジストリーノードに必要なパッケージをインストールします。

    $ sudo yum -y install python3 podman httpd httpd-tools jq
  3. リポジトリー情報が保持されるディレクトリー構造を作成します。

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

10.3.7.2. 自己署名証明書の生成 (オプション)

レジストリーノードの自己署名証明書を生成し、これを /opt/registry/certs ディレクトリーに配置します。

手順

  1. 必要に応じて証明書情報を調整します。

    $ host_fqdn=$( hostname --long )
    $ cert_c="<Country Name>"   # Country Name (C, 2 letter code)
    $ cert_s="<State>"          # Certificate State (S)
    $ cert_l="<Locality>"       # Certificate Locality (L)
    $ cert_o="<Organization>"   # Certificate Organization (O)
    $ cert_ou="<Org Unit>"      # Certificate Organizational Unit (OU)
    $ cert_cn="${host_fqdn}"    # Certificate Common Name (CN)
    
    $ openssl req \
        -newkey rsa:4096 \
        -nodes \
        -sha256 \
        -keyout /opt/registry/certs/domain.key \
        -x509 \
        -days 365 \
        -out /opt/registry/certs/domain.crt \
        -addext "subjectAltName = DNS:${host_fqdn}" \
        -subj "/C=${cert_c}/ST=${cert_s}/L=${cert_l}/O=${cert_o}/OU=${cert_ou}/CN=${cert_cn}"
    注記

    <Country Name> を置き換える場合には、2 文字のみを使用します。例: US

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

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

10.3.7.3. レジストリー podman コンテナーの作成 (オプション)

レジストリーコンテナーは、証明書、認証ファイルの /opt/registry ディレクトリーを使用し、そのデータファイルを保存するためにこれを使用します。

レジストリーコンテナーは httpd を使用し、認証に htpasswd ファイルが必要になります。

手順

  1. コンテナーが使用する htpasswd ファイルを /opt/registry/auth に作成します。

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

    <user> をユーザー名に、<passwd> をパスワードに置き換えます。

  2. レジストリーコンテナーを作成し、起動します。

    $ podman create \
      --name ocpdiscon-registry \
      -p 5000:5000 \
      -e "REGISTRY_AUTH=htpasswd" \
      -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" \
      -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" \
      -e "REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd" \
      -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
      -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
      -e "REGISTRY_COMPATIBILITY_SCHEMA1_ENABLED=true" \
      -v /opt/registry/data:/var/lib/registry:z \
      -v /opt/registry/auth:/auth:z \
      -v /opt/registry/certs:/certs:z \
      docker.io/library/registry:2
    $ podman start ocpdiscon-registry

10.3.7.4. pull-secret のコピーおよび更新 (オプション)

プロビジョナーノードからレジストリーノードにプルシークレットファイルをコピーし、これを新規レジストリーノードの認証情報を含めるように変更します。

手順

  1. pull-secret.txt ファイルをコピーします。

    $ scp kni@provisioner:/home/kni/pull-secret.txt pull-secret.txt
  2. host_fqdn 環境変数をレジストリーノードの完全修飾ドメイン名で更新します。

    $ host_fqdn=$( hostname --long )
  3. htpasswd ファイルの作成に使用される http 認証情報の base64 エンコーディングで b64auth 環境変数を更新します。

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

    <username> をユーザー名に、<passwd> をパスワードに置き換えます。

  4. base64 承認文字列を使用するように AUTHSTRING 環境変数を設定します。$USER 変数は、現行ユーザーの名前が含まれる環境変数です。

    $ AUTHSTRING="{\"$host_fqdn:5000\": {\"auth\": \"$b64auth\",\"email\": \"$USER@redhat.com\"}}"
  5. pull-secret.txt ファイルを更新します。

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

10.3.7.5. リポジトリーのミラーリング (オプション)

手順

  1. oc バイナリーをプロビジョナーノードからレジストリーノードにコピーします。

    $ sudo scp kni@provisioner:/usr/local/bin/oc /usr/local/bin
  2. 必要な環境変数を設定します。

    1. リリースバージョンを設定します。

      $ VERSION=<release_version>

      <release_version> について、インストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例: 4.9)。

    2. ローカルレジストリー名とホストポートを設定します。

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

      <local_registry_host_name> については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port> については、コンテンツの送信に使用するポートを指定します。

    3. ローカルリポジトリー名を設定します。

      $ LOCAL_REPO='<local_repository_name>'

      <local_repository_name> については、ocp4/openshift4 などのレジストリーに作成するリポジトリーの名前を指定します。

  3. リモートインストールイメージをローカルリポジトリーにミラーリングします。

    $ /usr/local/bin/oc adm release mirror \
      -a pull-secret-update.txt \
      --from=$UPSTREAM_REPO \
      --to-release-image=$LOCAL_REG/$LOCAL_REPO:${VERSION} \
      --to=$LOCAL_REG/$LOCAL_REPO

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

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

手順

  1. 非接続レジストリーノードの証明書を install-config.yaml ファイルに追加します。証明書は "additionalTrustBundle: |" 行に従い、通常は 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 をレジストリーの完全修飾ドメイン名に置き換えます。

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

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

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

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

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

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

10.3.11. インストール後

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

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

10.3.12. 静的 IP アドレス設定の検証

クラスターノードの DHCP 予約で無限リースが指定されている場合、インストーラーがノードを正常にプロビジョニングした後に、dispatcher スクリプトはノードのネットワーク設定をチェックします。ネットワーク設定に無限 DHCP リースが含まれているとスクリプトが判断すると、DHCP リースの IP アドレスを静的 IP アドレスとして使用して新規接続を作成します。

注記

dispatcher スクリプトは、クラスター内の他のノードのプロビジョニングの進行中に、正常にプロビジョニングされたノードで実行される場合があります。

ネットワーク設定が正しく機能していることを確認します。

手順

  1. ノードのネットワークインターフェイス設定を確認してください。
  2. DHCP サーバーをオフにし、OpenShift Container Platform ノードを再起動して、ネットワーク設定が適切に機能していることを確認します。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.