Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

3.3.1. RHEL のプロビジョナーノードへのインストール
リンクのコピー

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

3.3.2. OpenShift Container Platform インストールのプロビジョナーノードの準備
リンクのコピー

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

手順

  1. ssh でプロビジョナーノードにログインします。

  2. root 以外のユーザー (kni) を作成し、そのユーザーに sudo 権限を付与します。 

    # useradd kni
    Copy to Clipboard Toggle word wrap 
    # passwd kni
    Copy to Clipboard Toggle word wrap 
    # echo "kni ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/kni
    Copy to Clipboard Toggle word wrap 
    # chmod 0440 /etc/sudoers.d/kni
    Copy to Clipboard Toggle word wrap

  3. 新規ユーザーの ssh キーを作成します。 

    # su - kni -c "ssh-keygen -t ed25519 -f /home/kni/.ssh/id_rsa -N ''"
    Copy to Clipboard Toggle word wrap

  4. プロビジョナーノードで新規ユーザーとしてログインします。 

    # su - kni
    Copy to Clipboard Toggle word wrap

  5. Red Hat Subscription Manager を使用してプロビジョナーノードを登録します。 

    $ sudo subscription-manager register --username=<user> --password=<pass> --auto-attach
    Copy to Clipboard Toggle word wrap 
    $ sudo subscription-manager repos --enable=rhel-9-for-<architecture>-appstream-rpms --enable=rhel-9-for-<architecture>-baseos-rpms
    Copy to Clipboard Toggle word wrap
    注記

    Red Hat Subscription Manager の詳細は、コマンドラインツールを使用した RHEL システムの登録 を参照してください。

  6. 以下のパッケージをインストールします。 

    $ sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool
    Copy to Clipboard Toggle word wrap

  7. ユーザーを変更して、新たに作成したユーザーに libvirt グループを追加します。 

    $ sudo usermod --append --groups libvirt <user>
    Copy to Clipboard Toggle word wrap

  8. firewalld を再起動して、http サービスを有効にします。 

    $ sudo systemctl start firewalld
    Copy to Clipboard Toggle word wrap 
    $ sudo firewall-cmd --zone=public --add-service=http --permanent
    Copy to Clipboard Toggle word wrap 
    $ sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

  9. モジュラー libvirt デーモンのソケットを起動します。 

    $ for drv in qemu interface network nodedev nwfilter secret storage; do sudo systemctl start virt${drv}d{,-ro,-admin}.socket; done
    Copy to Clipboard Toggle word wrap

  10. default ストレージプールを作成して、これを起動します。 

    $ sudo virsh pool-define-as --name default --type dir --target /var/lib/libvirt/images
    Copy to Clipboard Toggle word wrap 
    $ sudo virsh pool-start default
    Copy to Clipboard Toggle word wrap 
    $ sudo virsh pool-autostart default
    Copy to Clipboard Toggle word wrap

  11. pull-secret.txt ファイルを作成します。 

    $ vim pull-secret.txt
    Copy to Clipboard Toggle word wrap

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

3.3.3. NTP サーバーの同期を確認する
リンクのコピー

OpenShift Container Platform インストールプログラムは、chrony Network Time Protocol (NTP) サービスをクラスターノードにインストールします。インストールを完了するには、各ノードが NTP タイムサーバーにアクセスできる必要があります。chrony サービスを使用して、NTP サーバーの同期を確認できます。

切断されたクラスターの場合は、コントロールプレーンノード上で NTP サーバーを設定する必要があります。詳細は、関連情報 セクションを参照してください。

前提条件

  • ターゲットノードに chrony パッケージがインストールされました。

手順

  1. ssh コマンドを使用してノードにログインします。

  2. 次のコマンドを実行して、ノードで利用可能な NTP サーバーを表示します。 

    $ chronyc sources
    Copy to Clipboard Toggle word wrap

    出力例

    MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^+ time.cloudflare.com           3  10   377   187   -209us[ -209us] +/-   32ms
^+ t1.time.ir2.yahoo.com         2  10   377   185  -4382us[-4382us] +/-   23ms
^+ time.cloudflare.com           3  10   377   198   -996us[-1220us] +/-   33ms
^* brenbox.westnet.ie            1  10   377   193  -9538us[-9761us] +/-   24ms
    Copy to Clipboard Toggle word wrap

  3. ping コマンドを使用して、ノードが NTP サーバーにアクセスできることを確認します。次に例を示します。 

    $ ping time.cloudflare.com
    Copy to Clipboard Toggle word wrap

    出力例

    PING time.cloudflare.com (162.159.200.123) 56(84) bytes of data.
64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=1 ttl=54 time=32.3 ms
64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=2 ttl=54 time=30.9 ms
64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=3 ttl=54 time=36.7 ms
...
    Copy to Clipboard Toggle word wrap

3.3.4. ネットワークの設定
リンクのコピー

インストールの前に、プロビジョナーノードでネットワークを設定する必要があります。installer-provisioned クラスターは、ベアメタルブリッジとネットワーク、およびオプションのプロビジョニングブリッジとネットワークを使用してデプロイされます。

ネットワークの設定
View larger image
ネットワークの設定
注記

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

手順

  1. 次のコマンドを実行して、ベアメタルネットワーク NIC 名をエクスポートします。 

    $ export PUB_CONN=<baremetal_nic_name>
    Copy to Clipboard Toggle word wrap

  2. ベアメタルネットワークを設定します。

    注記

    これらの手順を実行した後、SSH 接続が切断される場合があります。

    1. DHCP を使用するネットワークの場合は、次のコマンドを実行します。 

      $ 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
      1 
      
    nmcli con add type bridge-slave ifname \"$PUB_CONN\" master baremetal
    pkill dhclient;dhclient baremetal
"
      Copy to Clipboard Toggle word wrap
      1
      <con_name> を接続名に置き換えます。

    2. 静的 IP アドレスを使用し、DHCP ネットワークを使用しないネットワークの場合は、次のコマンドを実行します。 

      $ 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 ipv4.method manual ipv4.addr "x.x.x.x/yy" ipv4.gateway "a.a.a.a" ipv4.dns "b.b.b.b"
      1 
      
    nmcli con add type bridge-slave ifname \"$PUB_CONN\" master baremetal
    nmcli con up baremetal
"
      Copy to Clipboard Toggle word wrap
      1
      <con_name> を接続名に置き換えます。x.x.x.x/yy をネットワークの IP アドレスと CIDR に置き換えます。a.a.a.a をネットワークゲートウェイに置き換えます。b.b.b.b を DNS サーバーの IP アドレスに置き換えます。

  3. オプション: プロビジョニングネットワークを使用してデプロイする場合は、次のコマンドを実行してプロビジョニングネットワークの NIC 名をエクスポートします。 

    $ export PROV_CONN=<prov_nic_name>
    Copy to Clipboard Toggle word wrap

  4. オプション: プロビジョニングネットワークを使用してデプロイする場合は、次のコマンドを実行してプロビジョニングネットワークを設定します。 

    $ 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
"
    Copy to Clipboard Toggle word wrap
    注記

    これらの手順を実行した後、SSH 接続が切断される場合があります。

    IPv6 アドレスは、ベアメタルネットワーク経由でルーティングできない任意のアドレスにすることができます。

    IPv6 アドレスを使用する場合に UEFI PXE 設定が有効にされており、UEFI PXE 設定が IPv6 プロトコルに設定されていることを確認します。

  5. オプション: プロビジョニングネットワークを使用してデプロイする場合は、次のコマンドを実行して、プロビジョニングネットワーク接続で IPv4 アドレスを設定します。 

    $ nmcli connection modify provisioning ipv4.addresses 172.22.0.254/24 ipv4.method manual
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを実行して、provisioner ノードに SSH で戻ります (必要な場合)。 

    # ssh kni@provisioner.<cluster-name>.<domain>
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを実行して、接続ブリッジが適切に作成されたことを確認します。 

    $ sudo nmcli con show
    Copy to Clipboard Toggle word wrap

    出力例

    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
    Copy to Clipboard Toggle word wrap

3.3.5. カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成
リンクのコピー

configure-ovs.sh シェルスクリプトを使用してベアメタルプラットフォームで br-ex ブリッジを設定する代わりに、NMState 設定ファイルを含む MachineConfig オブジェクトを作成できます。ホスト nmstate-configuration.service および nmstate.service により、クラスター内で実行される各ノードに NMState 設定ファイルが適用されます。

カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。

  • Open vSwitch (OVS) または OVN-Kubernetes br-ex ブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.sh シェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。
  • ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
  • configure-ovs.sh シェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。
注記

単一のネットワークインターフェイスコントローラー (NIC) とデフォルトのネットワーク設定を備えた環境が必要な場合は、configure-ovs.sh シェルスクリプトを使用します。

Red Hat Enterprise Linux CoreOS (RHCOS) をインストールしてシステムを再起動すると、Machine Config Operator がクラスター内の各ノードに Ignition 設定ファイルを挿入し、各ノードが br-ex ブリッジネットワーク設定を受け取るようになります。設定の競合を防ぐために、configure-ovs.sh シェルスクリプトは、br-ex ブリッジを設定しない信号を受け取ります。

警告

次のインターフェイス名は予約されており、NMstate 設定では使用できません。

  • br-ext
  • br-int
  • br-local
  • br-nexthop
  • br0
  • ext-vxlan
  • ext
  • genev_sys_*
  • int
  • k8s-*
  • ovn-k8s-*
  • patch-br-*
  • tun0
  • vxlan_sys_*

前提条件

  • オプション: NMState 設定を検証できるように、nmstate API をインストールしました。

手順

  1. カスタマイズされた br-ex ブリッジネットワークの base64 情報をデコードした NMState 設定ファイルを作成します。

    カスタマイズされた br-ex ブリッジネットワークの NMState 設定の例

    interfaces:
- name: enp2s0
    1 
    
  type: ethernet
    2 
    
  state: up
    3 
    
  ipv4:
    enabled: false
    4 
    
  ipv6:
    enabled: false
- name: br-ex
  type: ovs-bridge
  state: up
  ipv4:
    enabled: false
    dhcp: false
  ipv6:
    enabled: false
    dhcp: false
  bridge:
    options:
      mcast-snooping-enable: true
    port:
    - name: enp2s0
    5 
    
    - name: br-ex
- name: br-ex
  type: ovs-interface
  state: up
  copy-mac-from: enp2s0
  ipv4:
    enabled: true
    dhcp: true
    auto-route-metric: 48
    6 
    
  ipv6:
    enabled: true
    dhcp: true
    auto-route-metric: 48
# ...
    Copy to Clipboard Toggle word wrap

    1
    インターフェイスの名前。
    2
    イーサネットのタイプ。
    3
    作成後のインターフェイスの要求された状態。
    4
    この例では、IPv4 と IPv6 を無効にします。
    5
    ブリッジが接続されるノードの NIC。
    6
    br-ex デフォルトルートに常に最高の優先度 (最も低いメトリック値) を付与するには、パラメーターを 48 に設定します。この設定により、NetworkManager サービスによって自動的に設定される他のインターフェイスとのルーティングの競合が防止されます。

  2. cat コマンドを使用して、NMState 設定の内容を base64 でエンコードします。 

    $ cat <nmstate_configuration>.yaml | base64
    1
    Copy to Clipboard Toggle word wrap
    1
    <nmstate_configuration> を NMState リソース YAML ファイルの名前に置き換えます。

  3. MachineConfig マニフェストファイルを作成し、次の例に類似したカスタマイズされた br-ex ブリッジネットワーク設定を定義します。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 10-br-ex-worker
    1 
    
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
    2 
    
        mode: 0644
        overwrite: true
        path: /etc/nmstate/openshift/worker-0.yml
    3 
    
      - contents:
          source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
        mode: 0644
        overwrite: true
        path: /etc/nmstate/openshift/worker-1.yml
    4 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    ポリシーの名前。
    2
    エンコードされた base64 情報を指定されたパスに書き込みます。
    3 4
    クラスター内の各ノードに対して、ノードへのホスト名パスと、マシンタイプに応じた base-64 でエンコードされた Ignition 設定ファイルデータを指定します。worker ロールは、クラスター内のノードのデフォルトロールです。MachineConfig マニフェストファイルで各ノードまたはすべてのノードに対して短いホスト名 (hostname -s で得られるもの) のパスを指定する際に、.yaml 拡張子は機能しません。

    クラスター内のすべてのノードに適用する単一のグローバル設定が /etc/nmstate/openshift/cluster.yml 設定ファイルで指定されている場合は、各ノードの短いホスト名パス (例: /etc/nmstate/openshift/<node_hostname>.yml) を指定する必要はありません。以下に例を示します。 

    # ...
      - contents:
          source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
        mode: 0644
        overwrite: true
        path: /etc/nmstate/openshift/cluster.yml
# ...
    Copy to Clipboard Toggle word wrap

次のステップ

  • コンピュートノードをスケーリングして、クラスター内に存在する各コンピュートノードに、カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトを適用します。詳細は、関連情報 セクションの「クラスターの拡張」を参照してください。

3.3.5.1. 各マシンセットをコンピュートノードにスケーリング
リンクのコピー

カスタマイズされた br-ex ブリッジ設定を OpenShift Container Platform クラスター内のすべてのコンピュートノードに適用するには、MachineConfig カスタムリソース (CR) を編集し、そのロールを変更する必要があります。さらに、ホスト名、認証情報など、ベアメタルマシンの情報を定義する BareMetalHost CR を作成する必要があります。

これらのリソースを設定した後、マシンセットをスケーリングして、マシンセットが各コンピュートノードにリソース設定を適用し、ノードを再起動できるようにする必要があります。

前提条件

  • カスタマイズされた br-ex ブリッジ設定を含む MachineConfig マニフェストオブジェクトを作成しました。

手順

  1. 次のコマンドを入力して MachineConfig CR を編集します。 

    $ oc edit mc <machineconfig_custom_resource_name>
    Copy to Clipboard Toggle word wrap
  2. 各コンピュートノード設定を CR に追加して、CR がクラスター内の定義済みコンピュートノードごとにロールを管理できるようにします。
  3. 最小限の静的 IP 設定を持つ extraworker-secret という名前の Secret オブジェクトを作成します。

  4. 次のコマンドを入力して、クラスター内の各ノードに extraworker-secret シークレットを適用します。このステップでは、各コンピュートノードに Ignition 設定ファイルへのアクセスを提供します。 

    $ oc apply -f ./extraworker-secret.yaml
    Copy to Clipboard Toggle word wrap

  5. BareMetalHost リソースを作成し、preprovisioningNetworkDataName パラメーターでネットワークシークレットを指定します。

    ネットワークシークレットが添付された BareMetalHost リソースの例

    apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
spec:
# ...
  preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
# ...
    Copy to Clipboard Toggle word wrap

  6. クラスターの openshift-machine-api namespace 内で BareMetalHost オブジェクトを管理するために、次のコマンドを入力して namespace に変更します。 

    $ oc project openshift-machine-api
    Copy to Clipboard Toggle word wrap

  7. マシンセットを取得します。 

    $ oc get machinesets
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを入力して、各マシンセットをスケールします。このコマンドはマシンセットごとに実行する必要があります。 

    $ oc scale machineset <machineset_name> --replicas=<n>
    1
    Copy to Clipboard Toggle word wrap
    1
    <machineset_name> はマシンセットの名前です。<n> はコンピュートノードの数です。

3.3.6. クラスターで OVS balance-slb モードを有効にする
リンクのコピー

2 つ以上の物理インターフェイスがネットワークトラフィックを共有できるように、Open vSwitch (OVS) の balance-slb モードを有効にできます。balance-slb モードのインターフェイスは、ネットワークスイッチとのソースロードバランシングを必要とせずに、仮想化ワークロードを実行するクラスターにソース負荷分散 (SLB) 機能を提供できます。

現在、ソースロードバランシングはボンディングインターフェイスで実行されます。このインターフェイスは br-phy などの補助ブリッジに接続します。ソースロードバランシングは、Media Access Control (MAC) アドレスと仮想ローカルエリアネットワーク (VLAN) の組み合わせが複数存在する場合にのみ、負荷分散を行います。OVN-Kubernetes Pod のトラフィックはすべて同じ MAC アドレスと VLAN を使用するため、このトラフィックを多数の物理インターフェイス間で負荷分散することはできないことに注意してください。

次の図は、単純なクラスターインフラストラクチャーレイアウトでの balance-slb モードを示しています。仮想マシン (VM) は、特定の localnet NetworkAttachmentDefinition (NAD) カスタムリソース定義 (CRD)、NAD 0 または NAD 1 に接続します。各 NAD は、仮想マシンに基盤となる物理ネットワークへのアクセスを提供し、タグ付きまたはタグなしの VLAN トラフィックをサポートしています。br-ex OVS ブリッジは仮想マシンからのトラフィックを受信し、そのトラフィックを次の OVS ブリッジである br-phy に渡します。br-phy ブリッジは SLB ボンディングのコントローラーとして機能します。SLB ボンディングは、eno0 や eno1 などの物理インターフェイスリンクを介して、異なる仮想マシンポートからのトラフィックを分散します。さらに、どちらの物理インターフェイスからの Ingress トラフィックも、OVS ブリッジのセットを通過して仮想マシンに到達できます。

図3.1 2 つの NAD CRD を持つ localnet で動作する OVS balance-slb モード

2 つの NAD CRD を持つ localnet で動作する OVS 'balance-slb' モード
View larger image
2 つの NAD CRD を持つ localnet で動作する OVS 'balance-slb' モード

OVS ボンディングを使用して、balance-slb モードインターフェイスをプライマリーまたはセカンダリーネットワークタイプに統合できます。OVS ボンディングでは、次の点に注意してください。

  • OVN-Kubernetes CNI プラグインをサポートし、プラグインと簡単に統合できます。
  • ネイティブで balance-slb モードをサポートします。

前提条件

  • プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを MachineConfig ファイルで定義した。
  • マニフェストオブジェクトを作成し、カスタマイズした br-ex ブリッジをオブジェクト設定ファイルで定義した。
  • プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを NAD CRD ファイルで定義した。

手順

  1. クラスター内に存在するベアメタルホストごとに、クラスターの install-config.yaml ファイルで、次の例のように networkConfig セクションを定義します。 

    apiVersion: v1
kind: InstallConfig
metadata:
  name: <cluster-name>
# ...
networkConfig:
  interfaces:
    - name: enp1s0
    1 
    
      type: ethernet
      state: up
      ipv4:
        dhcp: true
        enabled: true
      ipv6:
        enabled: false
    - name: enp2s0
    2 
    
      type: ethernet
      state: up
      mtu: 1500
    3 
    
      ipv4:
        dhcp: true
        enabled: true
      ipv6:
        dhcp: true
        enabled: true
    - name: enp3s0
    4 
    
      type: ethernet
      state: up
      mtu: 1500
      ipv4:
        enabled: false
      ipv6:
        enabled: false
# ...
    Copy to Clipboard Toggle word wrap
    1
    プロビジョニングされるネットワークインターフェイスコントローラー (NIC) のインターフェイス。
    2
    ボンディングインターフェイス用の Ignition 設定ファイルを取り込む最初のボンディングされたインターフェイス。
    3
    ボンディングポートの br-ex 最大伝送単位 (MTU) を手動で設定します。
    4
    2 つ目のボンディングされたインターフェイスは、クラスターのインストール中に Ignition を実行する最小設定の一部です。

  2. NMState 設定ファイルで各ネットワークインターフェイスを定義します。

    多数のネットワークインターフェイスを定義する NMState 設定ファイルの例

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
# ...
ovn:
  bridge-mappings:
    - localnet: localnet-network
      bridge: br-ex
      state: present
interfaces:
  - name: br-ex
    type: ovs-bridge
    state: up
    bridge:
      allow-extra-patch-ports: true
      port:
        - name: br-ex
        - name: patch-ex-to-phy
    ovs-db:
      external_ids:
        bridge-uplink: "patch-ex-to-phy"
  - name: br-ex
    type: ovs-interface
    state: up
    mtu: 1500
    1 
    
    ipv4:
      enabled: true
      dhcp: true
      auto-route-metric: 48
    ipv6:
      enabled: false
      dhcp: false
      auto-route-metric: 48
  - name: br-phy
    type: ovs-bridge
    state: up
    bridge:
      allow-extra-patch-ports: true
      port:
        - name: patch-phy-to-ex
        - name: ovs-bond
          link-aggregation:
            mode: balance-slb
            port:
              - name: enp2s0
              - name: enp3s0
  - name: patch-ex-to-phy
    type: ovs-interface
    state: up
    patch:
      peer: patch-phy-to-ex
  - name: patch-phy-to-ex
    type: ovs-interface
    state: up
    patch:
      peer: patch-ex-to-phy
  - name: enp1s0
    type: ethernet
    state: up
    ipv4:
      dhcp: true
      enabled: true
    ipv6:
      enabled: false
  - name: enp2s0
    type: ethernet
    state: up
    mtu: 1500
    ipv4:
      enabled: false
    ipv6:
      enabled: false
  - name: enp3s0
    type: ethernet
    state: up
    mtu: 1500
    ipv4:
      enabled: false
    ipv6:
      enabled: false
# ...
    Copy to Clipboard Toggle word wrap

    1
    ボンディングポートの br-ex MTU を手動で設定します。

  3. base64 コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。 

    $ base64 -w0  <nmstate_configuration>.yml
    1
    Copy to Clipboard Toggle word wrap
    1
    -w0 オプションは、base64 エンコード操作中に行の折り返しを防止します。

  4. master ロールと worker ロールの MachineConfig マニフェストファイルを作成します。前のコマンドからの base64 エンコード文字列を各 MachineConfig マニフェストファイルに必ず埋め込んでください。次のマニフェストファイルの例では、クラスター内に存在するすべてのノードに対して master ロールを設定します。ノード固有の master ロールと worker ロールのマニフェストファイルを作成することもできます。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 10-br-ex-master
    1 
    
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
    2 
    
        mode: 0644
        overwrite: true
        path: /etc/nmstate/openshift/cluster.yml
    3
    Copy to Clipboard Toggle word wrap
    1
    ポリシーの名前。
    2
    エンコードされた base64 情報を指定されたパスに書き込みます。
    3
    cluster.yml ファイルへのパスを指定します。クラスター内の各ノードに対して、<node_short_hostname>.yml など、ノードへの短いホスト名パスを指定できます。

  5. 各 MachineConfig マニフェストファイルを ./<installation_directory>/manifests ディレクトリーに保存します。<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーです。

    Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。

3.3.7. サブネット間の通信を確立する
リンクのコピー

一般的な OpenShift Container Platform クラスターのセットアップでは、コントロールプレーンとコンピュートノードを含むすべてのノードが同じネットワーク内に存在します。ただし、エッジコンピューティングのシナリオでは、コンピュートノードをエッジの近くに配置することが有益な場合があります。その場合、コントロールプレーンやローカルコンピュートノードが使用するサブネットとは異なるネットワークセグメントまたはサブネットをリモートノードに使用することもよくあります。このようなセットアップにより、エッジのレイテンシーが減少し、拡張性が向上します。

OpenShift Container Platform をインストールする前に、リモートノードを含むエッジサブネットがコントロールプレーンノードを含むサブネットに到達し、コントロールプレーンからのトラフィックも受信できるように、ネットワークを適切に設定する必要があります。

重要

クラスターのインストール中に、install-config.yaml 設定ファイルのネットワーク設定でノードに永続的な IP アドレスを割り当てます。これを行わないと、ノードに一時的な IP アドレスが割り当てられ、トラフィックがノードに到達する方法に影響する可能性があります。たとえば、ノードに一時的な IP アドレスが割り当てられていて、ノードに対して結合されたインターフェイスを設定した場合、結合されたインターフェイスは別の IP アドレスを受け取る可能性があります。

デフォルトのロードバランサーの代わりにユーザー管理のロードバランサーを設定することで、同じサブネットまたは複数のサブネットでコントロールプレーンノードを実行できます。複数のサブネット環境を使用すると、ハードウェア障害やネットワーク停止によって OpenShift Container Platform クラスターが失敗するリスクを軽減できます。詳細は、「ユーザー管理ロードバランサーのサービス」および「ユーザー管理ロードバランサーの設定」を参照してください。

複数のサブネット環境でコントロールプレーンノードを実行するには、次の主要なタスクを完了する必要があります。

  • install-config.yaml ファイルの loadBalancer.type パラメーターで UserManaged を指定して、デフォルトのロードバランサーの代わりにユーザー管理のロードバランサーを設定します。
  • install-config.yaml ファイルの ingressVIPs および apiVIPs パラメーターでユーザー管理のロードバランサーのアドレスを設定します。
  • 複数のサブネットの Classless Inter-Domain Routing (CIDR) とユーザー管理のロードバランサーの IP アドレスを、install-config.yaml ファイルの networking.machineNetworks パラメーターに追加します。
注記

複数のサブネットを持つクラスターをデプロイするには、redfish-virtualmedia や idrac-virtualmedia などの仮想メディアを使用する必要があります。

この手順では、2 番目のサブネットにあるリモートコンピュートノードが 1 番目のサブネットにあるコントロールプレーンノードと効果的に通信できるようにするために必要なネットワーク設定と、1 番目のサブネットにあるコントロールプレーンノードが 2 番目のサブネットにあるリモートコンピュートノードと効果的に通信できるようにするために必要なネットワーク設定を詳しく説明します。

この手順では、クラスターは 2 つのサブネットにまたがります。

  • 1 番目のサブネット (10.0.0.0) には、コントロールプレーンとローカルコンピュートノードが含まれています。
  • 2 番目のサブネット (192.168.0.0) には、エッジコンピュートノードが含まれています。

手順

  1. 1 番目のサブネットが 2 番目のサブネットと通信するように設定します。

    1. 次のコマンドを実行して、コントロールプレーンノードに root としてログインします。 

      $ sudo su -
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、ネットワークインターフェイスの名前を取得します。 

      # nmcli dev status
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して、ゲートウェイを経由する 2 番目のサブネット (192.168.0.0) へのルートを追加します。 

      # nmcli connection modify <interface_name> +ipv4.routes "192.168.0.0/24 via <gateway>"
      Copy to Clipboard Toggle word wrap

      <interface_name> をインターフェイス名に置き換えます。<gateway> を実際のゲートウェイの IP アドレスに置き換えます。

      例

      # nmcli connection modify eth0 +ipv4.routes "192.168.0.0/24 via 192.168.0.1"
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して変更を適用します。 

      # nmcli connection up <interface_name>
      Copy to Clipboard Toggle word wrap

      <interface_name> をインターフェイス名に置き換えます。

    5. ルーティングテーブルを検証して、ルートが正常に追加されたことを確認します。 

      # ip route
      Copy to Clipboard Toggle word wrap

    6. 1 番目のサブネットの各コントロールプレーンノードに対して前の手順を繰り返します。

      注記

      コマンドは、実際のインターフェイス名とゲートウェイに合わせて調整してください。

  2. 1 番目のサブネットと通信するように 2 番目のサブネットを設定します。

    1. 次のコマンドを実行して、リモートコンピュートノードに root としてログインします。 

      $ sudo su -
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、ネットワークインターフェイスの名前を取得します。 

      # nmcli dev status
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して、ゲートウェイを経由する最初のサブネット (10.0.0.0) へのルートを追加します。 

      # nmcli connection modify <interface_name> +ipv4.routes "10.0.0.0/24 via <gateway>"
      Copy to Clipboard Toggle word wrap

      <interface_name> をインターフェイス名に置き換えます。<gateway> を実際のゲートウェイの IP アドレスに置き換えます。

      例

      # nmcli connection modify eth0 +ipv4.routes "10.0.0.0/24 via 10.0.0.1"
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して変更を適用します。 

      # nmcli connection up <interface_name>
      Copy to Clipboard Toggle word wrap

      <interface_name> をインターフェイス名に置き換えます。

    5. 次のコマンドを実行して、ルーティングテーブルを検証し、ルートが正常に追加されたことを確認します。 

      # ip route
      Copy to Clipboard Toggle word wrap

    6. 2 番目のサブネット内の各コンピュートノードに対して、上記の手順を繰り返します。

      注記

      コマンドは、実際のインターフェイス名とゲートウェイに合わせて調整してください。

  3. ネットワークを設定したら、接続をテストして、リモートノードがコントロールプレーンノードに到達できること、およびコントロールプレーンノードがリモートノードに到達できることを確認します。

    1. 1 番目のサブネットのコントロールプレーンノードから、次のコマンドを実行して、2 番目のサブネットのリモートノードに ping を実行します。 

      $ ping <remote_node_ip_address>
      Copy to Clipboard Toggle word wrap

      ping が成功した場合は、1 番目のサブネットのコントロールプレーンノードが 2 番目のサブネットのリモートノードに到達できています。応答がない場合は、ネットワーク設定を確認し、ノードに対して手順を繰り返します。

    2. 2 番目のサブネットのリモートノードから、次のコマンドを実行して、1 番目のサブネットのコントロールプレーンノードに ping を実行します。 

      $ ping <control_plane_node_ip_address>
      Copy to Clipboard Toggle word wrap

      ping が成功した場合は、2 番目のサブネットのリモートコンピュートノードが 1 番目のサブネットのコントロールプレーンに到達できています。応答がない場合は、ネットワーク設定を確認し、ノードに対して手順を繰り返します。

3.3.8. OpenShift Container Platform インストーラーの取得
リンクのコピー

インストールプログラムの stable-4.x バージョンと選択したアーキテクチャーを使用して、OpenShift Container Platform の一般公開の安定バージョンをデプロイします。 

$ export VERSION=stable-4.18
Copy to Clipboard Toggle word wrap 
$ export RELEASE_ARCH=<architecture>
Copy to Clipboard Toggle word wrap 
$ export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/$RELEASE_ARCH/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}')
Copy to Clipboard Toggle word wrap

3.3.9. OpenShift Container Platform インストーラーの展開
リンクのコピー

インストーラーを取得したら、インストーラーを展開します。

手順

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

    $ export cmd=openshift-baremetal-install
    Copy to Clipboard Toggle word wrap 
    $ export pullsecret_file=~/pull-secret.txt
    Copy to Clipboard Toggle word wrap 
    $ export extract_dir=$(pwd)
    Copy to Clipboard Toggle word wrap

  2. oc バイナリーを取得します。 

    $ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc
    Copy to Clipboard Toggle word wrap

  3. インストーラーを実行します。 

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

3.3.10. RHCOS イメージキャッシュの作成
リンクのコピー

イメージキャッシングを使用するには、ブートストラップ VM がクラスターノードをプロビジョニングするために使用する Red Hat Enterprise Linux CoreOS(RHCOS) イメージをダウンロードする必要があります。イメージのキャッシュはオプションですが、帯域幅が制限されているネットワークでインストールプログラムを実行する場合に特に便利です。

注記

正しいイメージがリリースペイロードにあるため、インストールプログラムは、clusterOSImage RHCOS イメージを必要としなくなりました。

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

警告

HTTPD サーバーに対して TLS を有効にする場合、ルート証明書がクライアントによって信頼された機関によって署名されていることを確認し、OpenShift Container Platform ハブおよびスポーククラスターと HTTPD サーバー間の信頼された証明書チェーンを検証する必要があります。信頼されていない証明書で設定されたサーバーを使用すると、イメージがイメージ作成サービスにダウンロードされなくなります。信頼されていない HTTPS サーバーの使用はサポートされていません。

イメージを含むコンテナーをインストールします。

手順

  1. podman をインストールします。 

    $ sudo dnf install -y podman
    Copy to Clipboard Toggle word wrap

  2. RHCOS イメージのキャッシュに使用されるファイアウォールのポート 8080 を開きます。 

    $ sudo firewall-cmd --add-port=8080/tcp --zone=public --permanent
    Copy to Clipboard Toggle word wrap 
    $ sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

  3. bootstraposimage を保存するディレクトリーを作成します。 

    $ mkdir /home/kni/rhcos_image_cache
    Copy to Clipboard Toggle word wrap

  4. 新規に作成されたディレクトリーに適切な SELinux コンテキストを設定します。 

    $ sudo semanage fcontext -a -t httpd_sys_content_t "/home/kni/rhcos_image_cache(/.*)?"
    Copy to Clipboard Toggle word wrap 
    $ sudo restorecon -Rv /home/kni/rhcos_image_cache/
    Copy to Clipboard Toggle word wrap

  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')
    Copy to Clipboard Toggle word wrap

  6. インストールプログラムがブートストラップ VM にデプロイするイメージの名前を取得します。 

    $ export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
    Copy to Clipboard Toggle word wrap

  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"]')
    Copy to Clipboard Toggle word wrap

  8. イメージをダウンロードして、/home/kni/rhcos_image_cache ディレクトリーに配置します。 

    $ curl -L ${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_NAME}
    Copy to Clipboard Toggle word wrap

  9. 新しいファイルの SELinux タイプが httpd_sys_content_t であることを確認します。 

    $ ls -Z /home/kni/rhcos_image_cache
    Copy to Clipboard Toggle word wrap

  10. Pod を作成します。 

    $ podman run -d --name rhcos_image_cache \
    1 
    
-v /home/kni/rhcos_image_cache:/var/www/html \
-p 8080:8080/tcp \
registry.access.redhat.com/ubi9/httpd-24
    Copy to Clipboard Toggle word wrap
    1
    rhcos_image_cache という名前のキャッシング Web サーバーを作成します。この Pod は、デプロイメント用に install-config.yaml ファイルの bootstrapOSImage イメージを提供します。

  11. bootstrapOSImage 設定を生成します。 

    $ export BAREMETAL_IP=$(ip addr show dev baremetal | awk '/inet /{print $2}' | cut -d"/" -f1)
    Copy to Clipboard Toggle word wrap 
    $ export BOOTSTRAP_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_QEMU_NAME}?sha256=${RHCOS_QEMU_UNCOMPRESSED_SHA256}"
    Copy to Clipboard Toggle word wrap 
    $ echo "    bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}"
    Copy to Clipboard Toggle word wrap

  12. platform.baremetal 下の install-config.yaml ファイルに必要な設定を追加します。 

    platform:
  baremetal:
    bootstrapOSImage: <bootstrap_os_image>
    1
    Copy to Clipboard Toggle word wrap
    1
    <bootstrap_os_image> を $BOOTSTRAP_OS_IMAGE の値に置き換えます。

    詳細は、「install-config.yaml ファイルの設定」セクションを参照してください。

3.3.11. ユーザー管理ロードバランサーのサービス
リンクのコピー

デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。

重要

ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。

このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。

Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。

図3.2 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。
View larger image
OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。

図3.3 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。
View larger image
OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。

図3.4 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift MachineConfig API のネットワークワークフローの例を示すイメージ。
View larger image
OpenShift Container Platform 環境で動作する OpenShift MachineConfig API のネットワークワークフローの例を示すイメージ。

ユーザー管理ロードバランサーでは、次の設定オプションがサポートされています。

  • ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。

  • サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。/27 や /28 などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。

    ヒント

    マシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。

OpenShift Container Platform クラスターのユーザー管理ロードバランサーを設定する前に、以下の情報を考慮してください。

  • フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能は、ベンダーのドキュメントを確認してください。

  • バックエンド IP アドレスの場合、ユーザー管理ロードバランサーの有効期間中に OpenShift Container Platform コントロールプレーンノードの IP アドレスが変更されないことを確認します。次のいずれかのアクションを実行すると、これを実現できます。

    • 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
    • ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
  • Ingress Controller バックエンドサービスのユーザー管理ロードバランサーで Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。

3.3.11.1. ユーザー管理ロードバランサーの設定
リンクのコピー

デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。

重要

ユーザー管理ロードバランサーを設定する前に、「ユーザー管理ロードバランサーのサービス」セクションを必ずお読みください。

ユーザー管理ロードバランサー用に設定するサービスに適用される次の前提条件をお読みください。

注記

クラスター上で実行される MetalLB は、ユーザー管理ロードバランサーとして機能します。

OpenShift API の前提条件

  • フロントエンド IP アドレスを定義している。

  • TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。

    • ポート 6443 が OpenShift API サービスにアクセスできる。
    • ポート 22623 が Ignition 起動設定をノードに提供できる。
  • フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
  • フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
  • ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。

Ingress Controller の前提条件

  • フロントエンド IP アドレスを定義している。
  • TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
  • フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
  • フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
  • ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。

ヘルスチェック URL 仕様の前提条件

ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できます。OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。

次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。

Kubernetes API ヘルスチェック仕様の例

Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Machine Config API ヘルスチェック仕様の例

Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Copy to Clipboard Toggle word wrap

Ingress Controller のヘルスチェック仕様の例

Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
Copy to Clipboard Toggle word wrap

手順

  1. HAProxy Ingress Controller を設定して、ポート 6443、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。

    1 つのサブネットをリストした HAProxy 設定の例

    # ...
listen my-cluster-api-6443
    bind 192.168.1.100:6443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /readyz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2

listen my-cluster-machine-config-api-22623
    bind 192.168.1.100:22623
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz
  http-check expect status 200
    server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
    server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2

listen my-cluster-apps-443
    bind 192.168.1.100:443
    mode tcp
    balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2

listen my-cluster-apps-80
   bind 192.168.1.100:80
   mode tcp
   balance roundrobin
  option httpchk
  http-check connect
  http-check send meth GET uri /healthz/ready
  http-check expect status 200
    server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
    server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
# ...
    Copy to Clipboard Toggle word wrap

    複数のサブネットをリストした HAProxy 設定の例

    # ...
listen api-server-6443
    bind *:6443
    mode tcp
      server master-00 192.168.83.89:6443 check inter 1s
      server master-01 192.168.84.90:6443 check inter 1s
      server master-02 192.168.85.99:6443 check inter 1s
      server bootstrap 192.168.80.89:6443 check inter 1s

listen machine-config-server-22623
    bind *:22623
    mode tcp
      server master-00 192.168.83.89:22623 check inter 1s
      server master-01 192.168.84.90:22623 check inter 1s
      server master-02 192.168.85.99:22623 check inter 1s
      server bootstrap 192.168.80.89:22623 check inter 1s

listen ingress-router-80
    bind *:80
    mode tcp
    balance source
      server worker-00 192.168.83.100:80 check inter 1s
      server worker-01 192.168.83.101:80 check inter 1s

listen ingress-router-443
    bind *:443
    mode tcp
    balance source
      server worker-00 192.168.83.100:443 check inter 1s
      server worker-01 192.168.83.101:443 check inter 1s

listen ironic-api-6385
    bind *:6385
    mode tcp
    balance source
      server master-00 192.168.83.89:6385 check inter 1s
      server master-01 192.168.84.90:6385 check inter 1s
      server master-02 192.168.85.99:6385 check inter 1s
      server bootstrap 192.168.80.89:6385 check inter 1s

listen inspector-api-5050
    bind *:5050
    mode tcp
    balance source
      server master-00 192.168.83.89:5050 check inter 1s
      server master-01 192.168.84.90:5050 check inter 1s
      server master-02 192.168.85.99:5050 check inter 1s
      server bootstrap 192.168.80.89:5050 check inter 1s
# ...
    Copy to Clipboard Toggle word wrap

  2. curl CLI コマンドを使用して、ユーザー管理ロードバランサーとそのリソースが動作していることを確認します。

    1. 次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。 

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合は、応答として JSON オブジェクトを受信します。 

      {
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
}
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。 

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
Content-Length: 0
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。 

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.ocp4.private.opequon.net/
cache-control: no-cache
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。 

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

  3. ユーザー管理ロードバランサーのフロントエンド IP アドレスをターゲットにするようにクラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。

    変更された DNS レコードの例

    <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap 

    <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
A record pointing to Load Balancer Front End
    Copy to Clipboard Toggle word wrap
    重要

    DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。

  4. OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの install-config.yaml ファイルで次の設定を指定する必要があります。 

    # ...
platform:
  baremetal:
    loadBalancer:
      type: UserManaged
    1 
    
    apiVIPs:
    - <api_ip>
    2 
    
    ingressVIPs:
    - <ingress_ip>
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    クラスターのユーザー管理ロードバランサーを指定するには、type パラメーターに UserManaged を設定します。パラメーターのデフォルトは OpenShiftManagedDefault で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra namespace で定義されたサービスの場合、ユーザー管理ロードバランサーは coredns サービスをクラスター内の Pod にデプロイできますが、keepalived および haproxy サービスは無視します。
    2
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
    3
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。

検証

  1. curl CLI コマンドを使用して、ユーザー管理ロードバランサーと DNS レコード設定が動作していることを確認します。

    1. 次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。 

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合は、応答として JSON オブジェクトを受信します。 

      {
  "major": "1",
  "minor": "11+",
  "gitVersion": "v1.11.0+ad103ed",
  "gitCommit": "ad103ed",
  "gitTreeState": "clean",
  "buildDate": "2019-01-09T06:44:10Z",
  "goVersion": "go1.10.3",
  "compiler": "gc",
  "platform": "linux/amd64"
  }
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。 

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
Content-Length: 0
      Copy to Clipboard Toggle word wrap

    3. 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。 

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 302 Found
content-length: 0
location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
cache-control: no-cacheHTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Tue, 17 Nov 2020 08:42:10 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。 

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
      Copy to Clipboard Toggle word wrap

      設定が正しい場合、コマンドの出力には次の応答が表示されます。 

      HTTP/1.1 200 OK
referrer-policy: strict-origin-when-cross-origin
set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
x-content-type-options: nosniff
x-dns-prefetch-control: off
x-frame-options: DENY
x-xss-protection: 1; mode=block
date: Wed, 04 Oct 2023 16:29:38 GMT
content-type: text/html; charset=utf-8
set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
cache-control: private
      Copy to Clipboard Toggle word wrap

3.3.12. DHCP を使用したクラスターノードのホスト名の設定
リンクのコピー

Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、NetworkManager がホスト名を設定します。デフォルトでは、DHCP が NetworkManager にホスト名を提供します。これが推奨される方法です。NetworkManager は、次の場合に逆 DNS ルックアップを通じてホスト名を取得します。

  • DHCP がホスト名を提供しない場合
  • カーネル引数を使用してホスト名を設定する場合
  • 別の方法でホスト名を設定する場合

逆 DNS ルックアップは、ノード上でネットワークが初期化された後に実行し、NetworkManager がホスト名を設定するのにかかる時間が長くなる可能性があります。NetworkManager がホスト名を設定する前に他のシステムサービスが起動することがあり、その場合は、それらのサービスが localhost などのデフォルトのホスト名を使用する可能性があります。

ヒント

DHCP を使用して各クラスターノードにホスト名を提供することで、ホスト名の設定の遅延を回避できます。また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。

3.3.13. install-config.yaml ファイルの設定
リンクのコピー

3.3.13.1. install-config.yaml ファイルの設定
リンクのコピー

install-config.yaml ファイルには、追加の詳細情報が必要です。ほとんどの情報は、インストールプログラムと結果として作成されるクラスターに、完全に管理できる使用可能なハードウェアを十分に説明しています。

注記

正しいイメージがリリースペイロードにあるため、インストールプログラムは、clusterOSImage RHCOS イメージを必要としなくなりました。

  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:
    additionalNTPServers:
    2 
    
      - <ntp_domain_or_ip>
    apiVIPs:
      - <api_ip>
    ingressVIPs:
      - <wildcard_ip>
    provisioningNetworkCIDR: <CIDR>
    bootstrapExternalStaticIP: <bootstrap_static_ip_address>
    3 
    
    bootstrapExternalStaticGateway: <bootstrap_static_gateway>
    4 
    
    bootstrapExternalStaticDNS: <bootstrap_static_dns>
    5 
    
    hosts:
      - name: openshift-master-0
        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_master_1>
        role: master
        bmc:
          address: ipmi://<out_of_band_ip>
          username: <user>
          password: <password>
        bootMACAddress: <NIC1_mac_address>
        rootDeviceHints:
         deviceName: "<installation_disk_drive_path>"
      - name: <openshift_master_2>
        role: master
        bmc:
          address: ipmi://<out_of_band_ip>
          username: <user>
          password: <password>
        bootMACAddress: <NIC1_mac_address>
        rootDeviceHints:
         deviceName: "<installation_disk_drive_path>"
      - name: <openshift_worker_0>
        role: worker
        bmc:
          address: ipmi://<out_of_band_ip>
          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>"
pullSecret: '<pull_secret>'
sshKey: '<ssh_pub_key>'
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform クラスターの一部であるコンピュートノードの数に基づいて、コンピュートマシンをスケーリングします。replicas 値の有効なオプションは 0 で、2 以上の整数です。3 ノードクラスターのみが含まれる 3 ノードクラスターをデプロイするには、レプリカ数を 0 に設定します。3 ノードクラスターは、テスト、開発、本番に使用できる、より小さく、よりリソース効率の良いクラスターです。コンピュートノードが 1 つだけのクラスターをインストールすることはできません。
    2
    クラスターホストのクロックが同期していない場合に各ホスト設定に追加する追加 NTP サーバーのドメイン名または IP アドレスのリスト (任意)。
    3
    静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、bootstrapExternalStaticIP 設定を設定して、ブートストラップ仮想マシンの静的 IP アドレスを指定する必要があります。
    4
    静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、bootstrapExternalStaticGateway 設定を設定して、ブートストラップ仮想マシンのゲートウェイ IP アドレスを指定する必要があります。
    5
    静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、bootstrapExternalStaticDNS 設定を設定して、ブートストラップ仮想マシンの DNS アドレスを指定する必要があります。
    6
    その他のオプションは、BMC アドレス指定のセクションを参照してください。
    7
    インストールディスクドライブへのパスを設定するには、ディスクのカーネル名を入力します。たとえば、/dev/sda です。
    重要

    ディスクの検出順序は保証されていないため、複数のディスクを持つマシンでは、起動オプションによってディスクのカーネル名が変わる可能性があります。たとえば、/dev/sda は /dev/sdb になり、その逆も同様です。この問題を回避するには、ディスクの World Wide Name (WWN) や /dev/disk/by-path/ などの永続的なディスク属性を使用する必要があります。ストレージの場所への /dev/disk/by-path/<device_path> リンクを使用することを推奨します。ディスク WWN を使用するには、deviceName パラメーターを wwnWithExtension パラメーターに置き換えます。使用するパラメーターに応じて、次のいずれかの値を入力します。

    • ディスク名。たとえば、/dev/sda、または /dev/disk/by-path/ です。
    • ディスクの WWN。たとえば、"0x64cd98f04fde100024684cf3034da5c2" です。ディスク WWN 値が 16 進数値ではなく文字列値として使用されるように、ディスク WWN 値を引用符で囲んで入力してください。

    これらの rootDeviceHints パラメーター要件を満たさない場合、次のエラーが発生する可能性があります。 

    ironic-inspector inspection failed: No disks satisfied root device hints
    Copy to Clipboard Toggle word wrap
    注記

    OpenShift Container Platform 4.12 より前では、クラスターインストールプログラムが、apiVIP および ingressVIP 設定の IPv4 アドレスまたは IPv6 アドレスのみを受け入れていました。OpenShift Container Platform 4.12 以降では、これらの設定は非推奨です。代わりに、apiVIPs および ingressVIPs 設定でリスト形式を使用して、IPv4 アドレス、IPv6 アドレス、または両方の IP アドレス形式を指定してください。

  2. クラスター設定を保存するディレクトリーを作成します。 

    $ mkdir ~/clusterconfigs
    Copy to Clipboard Toggle word wrap

  3. install-config.yaml ファイルを新しいディレクトリーにコピーします。 

    $ cp install-config.yaml ~/clusterconfigs
    Copy to Clipboard Toggle word wrap

  4. OpenShift Container Platform クラスターをインストールする前に、すべてのベアメタルノードの電源がオフになっていることを確認します。 

    $ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
    Copy to Clipboard Toggle word wrap

  5. 以前に試行したデプロイメントにより古いブートストラップリソースが残っている場合は、これを削除します。 

    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
    Copy to Clipboard Toggle word wrap

3.3.13.2. 追加の install-config パラメーター
リンクのコピー

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

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

baseDomain

 

クラスターのドメイン名。たとえば、example.com です。

bootMode

UEFI

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

platform:
  baremetal:
    bootstrapExternalStaticDNS
Copy to Clipboard Toggle word wrap
 

ブートストラップノードの静的ネットワーク DNS。ベアメタルネットワークに Dynamic Host Configuration Protocol (DHCP) サーバーがない場合に、静的 IP アドレスを使用してクラスターをデプロイする場合は、この値を設定する必要があります。この値を設定しないと、インストールプログラムが bootstrapExternalStaticGateway の値を使用します。そのため、ゲートウェイと DNS の IP アドレス値が異なる場合に問題が発生します。 

platform:
  baremetal:
    bootstrapExternalStaticIP
Copy to Clipboard Toggle word wrap
 

ブートストラップ VM の静的 IP アドレス。ベアメタルネットワークに DHCP サーバーがない場合に、静的 IP アドレスを使用してクラスターをデプロイする場合は、この値を設定する必要があります。 

platform:
  baremetal:
    bootstrapExternalStaticGateway
Copy to Clipboard Toggle word wrap
 

ブートストラップ VM のゲートウェイの静的 IP アドレス。ベアメタルネットワークに DHCP サーバーがない場合に、静的 IP アドレスを使用してクラスターをデプロイする場合は、この値を設定する必要があります。

sshKey

 

sshKey 設定には、コントロールプレーンノードとコンピュートノードにアクセスするために必要な、~/.ssh/id_rsa.pub ファイル内のキーを含めます。通常、このキーは provisioner ノードのキーです。

pullSecret

 

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

metadata:
    name:
Copy to Clipboard Toggle word wrap
 

OpenShift Container Platform クラスターの名前。たとえば、openshift です。 

networking:
    machineNetwork:
    - cidr:
Copy to Clipboard Toggle word wrap
 

外部ネットワークの公開 CIDR (Classless Inter-Domain Routing)。たとえば、10.0.0.0/24 です。 

compute:
  - name: worker
Copy to Clipboard Toggle word wrap
 

OpenShift Container Platform クラスターでは、ノードがゼロの場合でも、コンピュートノードに名前を付ける必要があります。 

compute:
    replicas: 2
Copy to Clipboard Toggle word wrap
 

replicas は、OpenShift Container Platform クラスターのコンピュートノードの数を設定します。 

controlPlane:
    name: master
Copy to Clipboard Toggle word wrap
 

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

controlPlane:
    replicas: 3
Copy to Clipboard Toggle word wrap
 

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

provisioningNetworkInterface

 

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

defaultMachinePlatform

 

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

apiVIPs

 

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

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

注記

OpenShift Container Platform 4.12 より前では、クラスターのインストールプログラムは apiVIP 設定の IPv4 アドレスまたは IPv6 アドレスのみを受け入れていました。OpenShift Container Platform 4.12 以降から、apiVIP 設定は非推奨になりました。代わりに、apiVIPs 設定のリスト形式を使用して、IPv4 アドレス、IPv6 アドレス、または両方の IP アドレス形式を指定します。

disableCertificateVerification

False

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

ingressVIPs

 

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

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

注記

OpenShift Container Platform 4.12 より前では、クラスターのインストールプログラムは ingressVIP 設定の IPv4 アドレスまたは IPv6 アドレスのみを受け入れていました。OpenShift Container Platform 4.12 以降では、ingressVIP 設定は非推奨です。代わりに、ingressVIPs 設定のリスト形式を使用して、IPv4 アドレス、IPv6 アドレス、または両方の IP アドレス形式を指定します。

Expand
表3.8 オプションのパラメーター
パラメーターデフォルト説明
platform:
  baremetal:
    additionalNTPServers:
    - <ip_address_or_domain_name>
Copy to Clipboard Toggle word wrap
 

各ホストに追加する追加 NTP サーバーのリスト (任意)。IP アドレスまたはドメイン名を使用して各 NTP サーバーを指定できます。追加 NTP サーバーは、クラスターホストのクロックが同期されていない場合にインストール前のクロック同期を有効にするユーザー定義の NTP サーバーです。

provisioningDHCPRange

172.22.0.10,172.22.0.100

プロビジョニングネットワークでノードの IP 範囲を定義します。

provisioningNetworkCIDR

172.22.0.0/24

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

clusterProvisioningIP

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

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

bootstrapProvisioningIP

provisioningNetworkCIDR の 2 番目の IP アドレス

インストールプログラムがコントロールプレーン (マスター) ノードをデプロイしている間にプロビジョニングサービスが実行されるブートストラップ仮想マシンの IP アドレス。デフォルトは、プロビジョニングサブネットの 2 番目の IP アドレスに設定されます。たとえば、172.22.0.2 または 2620:52:0:1307::2 です。

externalBridge

baremetal

ベアメタルネットワークに接続されたハイパーバイザーのベアメタルブリッジの名前。

provisioningBridge

provisioning

プロビジョニングネットワークに接続されている provisioner ホストのプロビジョニングブリッジの名前。

architecture

 

クラスターのホストアーキテクチャーを定義します。有効な値は amd64 または arm64 です。

defaultMachinePlatform

 

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

bootstrapOSImage

 

ブートストラップノードのデフォルトのオペレーティングシステムイメージを上書きするための URL。URL にはイメージの SHA-256 ハッシュが含まれている必要があります。たとえば、https://mirror.openshift.com/rhcos-<version>-qemu.qcow2.gz?sha256=<uncompressed_sha256> です。

provisioningNetwork

 

provisioningNetwork 設定は、クラスターがプロビジョニングネットワークを使用するかどうかを決定します。これが存在すると、設定はクラスターがネットワークを管理するかどうかも決定します。

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

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

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

httpProxy

 

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

httpsProxy

 

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

noProxy

 

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

3.3.13.2.1. ホスト
リンクのコピー

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

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

name

 

詳細情報に関連付ける BareMetalHost リソースの名前。たとえば、openshift-master-0 です。

role

 

ベアメタルノードのロール。master (コントロールプレーンノード) または worker (コンピュートノード) のいずれか。

bmc

 

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

bootMACAddress

 

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

注記

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

networkConfig

 

このオプションのパラメーターを設定して、ホストのネットワークインターフェイスを設定します。詳細は、「(オプション) ホストネットワークインターフェイスの設定」を参照してください。

3.3.13.3. BMC アドレス指定
リンクのコピー

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

ノードが Registering 状態にある間、インストール中に BMC アドレスを変更できます。ノードの Registering 状態が終了した後に BMC アドレスを変更する必要がある場合は、ノードを Ironic から切断し、BareMetalHost リソースを編集して、ノードを Ironic に再接続する必要があります。詳細は、BareMetalHost リソースの編集 セクションを参照してください。

3.3.13.3.1. 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>
Copy to Clipboard Toggle word wrap
重要

BMC アドレス指定に IPMI を使用して PXE ブートする場合は、provisioning ネットワークが必要です。provisioning ネットワークなしでは、PXE ブートホストを行うことはできません。provisioning ネットワークなしでデプロイする場合、redfish-virtualmedia や idrac-virtualmedia などの仮想メディア BMC アドレス指定オプションを使用する必要があります。詳細は、「HPE iLO の BMC アドレス指定」セクションの「HPE iLO の Redfish 仮想メディア」、または「Dell iDRAC の BMC アドレス指定」セクションの「Dell iDRAC の Redfish 仮想メディア」を参照してください。

3.3.13.3.2. 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>
Copy to Clipboard Toggle word wrap

アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、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
Copy to Clipboard Toggle word wrap

3.3.13.4. Redfish API のサポートの確認
リンクのコピー

Redfish API を使用してインストールする場合、ベアメタル上で installer-provisioned infrastructure を使用する際に、インストールプログラムはベースボード管理コントローラー (BMC) 上の複数の Redfish エンドポイントを呼び出します。Redfish を使用する場合は、インストール前に BMC がすべての Redfish API をサポートしていることを確認してください。

手順

  1. 次のコマンドを実行して、BMC の IP アドレスまたはホスト名を設定します。 

    $ export SERVER=<ip_address>
    1
    Copy to Clipboard Toggle word wrap
    1
    <ip_address> を、BMC の IP アドレスまたはホスト名に置き換えます。

  2. 次のコマンドを実行して、システムの ID を設定します。 

    $ export SystemID=<system_id>
    1
    Copy to Clipboard Toggle word wrap
    1
    <system_id> をシステム ID に置き換えます。たとえば、System.Embedded.1 または 1 です。詳細は、以下のベンダー固有 BMC セクションを参照してください。

Redfish API のリスト

  1. 次のコマンドを実行して、power on のサポートを確認します。 

    $ curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "On"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、power off のサポートを確認します。 

    $ curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "ForceOff"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、pxe を使用する一時的なブート実装を確認します。 

    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、Legacy または UEFI を使用するファームウェアブートモードの設定ステータスを確認します。 

    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
    Copy to Clipboard Toggle word wrap

Redfish 仮想メディア API のリスト

  1. 次のコマンドを実行して、cd または dvd を使用する一時ブートデバイスを設定できるか確認します。 

    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
    Copy to Clipboard Toggle word wrap

  2. 仮想メディアは、ハードウェアに応じて POST または PATCH を使用する場合があります。次のいずれかのコマンドを実行して、仮想メディアをマウントできるかどうかを確認します。 

    $ curl -u $USER:$PASS -X POST -H "Content-Type: application/json" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
    Copy to Clipboard Toggle word wrap 
    $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
    Copy to Clipboard Toggle word wrap
注記

Redfish API の PowerOn および PowerOff コマンドは、Redfish 仮想メディア API と同じです。一部のハードウェアでは、VirtualMedia リソースが Managers/$ManagerID ではなく Systems/$SystemID にのみ存在する場合があります。VirtualMedia リソースの場合、UserName と Password のフィールドはオプションです。

重要

TransferProtocolTypes でサポートされているパラメータータイプは、HTTPS と HTTP のみです。

3.3.13.5. Dell iDRAC の BMC アドレス指定
リンクのコピー

各 bmc エントリーの address 設定は、URL スキーム内のコントローラーのタイプとネットワーク上の場所を含む、OpenShift Container Platform クラスターノードに接続するための URL です。各 bmc エントリーの username 設定では、Administrator 権限を持つユーザーを指定する必要があります。 

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address>
1 

          username: <user>
2 

          password: <password>
Copy to Clipboard Toggle word wrap
1
address 設定ではプロトコルを指定します。
2
username 設定では、Administrator 権限を持つユーザーを指定する必要があります。

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

3.3.13.5.1. Dell iDRAC の BMC アドレス形式
リンクのコピー
Expand
プロトコルアドレスのフォーマット

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 標準を使用します。

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

3.3.13.5.2. Dell iDRAC の Redfish 仮想メディア
リンクのコピー

Dell サーバーの Redfish 仮想メディアには、address 設定で idrac-virtualmedia:// を使用します。redfish-virtualmedia:// を使用しても機能しません。

注記

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

アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、bmc 設定に disableCertificateVerification: True を含める必要があります。

注記

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

次の例は、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
Copy to Clipboard Toggle word wrap
3.3.13.5.3. 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>
Copy to Clipboard Toggle word wrap

アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、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
Copy to Clipboard Toggle word wrap
注記

ファームウェアバージョン 04.40.00.00 を使用する Dell iDRAC 9 と、ベアメタルデプロイメントで installer-provisioned installation 用の 5.xx シリーズを含むすべてのリリースには既知の問題があります。Virtual Console プラグインは、HTML5 の拡張バージョンである eHTML5 にデフォルト設定されているため、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、HTML5 を使用するようにプラグインを設定します。メニューパスは以下の通りです。Configuration Virtual console Plug-in Type HTML5

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

3.3.13.6. 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>
Copy to Clipboard Toggle word wrap
1
address 設定ではプロトコルを指定します。

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

Expand
表3.10 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>

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

3.3.13.6.1. HPE iLO の Redfish 仮想メディア
リンクのコピー

HPE サーバーの Redfish 仮想メディアを有効にするには、address 設定で redfish-virtualmedia:// を使用します。以下の例は、install-config.yaml ファイル内で Redfish 仮想メディアを使用する方法を示しています。 

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish-virtualmedia://<out-of-band-ip>/redfish/v1/Systems/1
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、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
Copy to Clipboard Toggle word wrap
注記

Ironic は、仮想メディアで iLO4 をサポートしないので、Redfish 仮想メディアは、iLO4 を実行する第 9 世代のシステムではサポートされません。

3.3.13.6.2. 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>
Copy to Clipboard Toggle word wrap

アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、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
Copy to Clipboard Toggle word wrap

3.3.13.7. 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>
Copy to Clipboard Toggle word wrap
1
address 設定ではプロトコルを指定します。

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

Expand
表3.11 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>
Copy to Clipboard Toggle word wrap
注記

現在 Fujitsu は、ベアメタルへの installer-provisioned installation 用に iRMC S5 ファームウェアバージョン 3.05P 以降をサポートしています。

3.3.13.8. Cisco CIMC の BMC アドレス指定
リンクのコピー

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

platform:
  baremetal:
    hosts:
      - name: <hostname>
        role: <master | worker>
        bmc:
          address: <address>
1 

          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap
1
address 設定ではプロトコルを指定します。

Cisco UCS C シリーズおよび X シリーズサーバーの場合、Red Hat は Cisco Integrated Management Controller (CIMC) をサポートしています。

Expand
表3.12 Cisco CIMC の BMC アドレス形式
プロトコルアドレスのフォーマット

Redfish 仮想メディア

redfish-virtualmedia://<server_kvm_ip>/redfish/v1/Systems/<serial_number>

Cisco UCS C シリーズおよび X シリーズサーバーで Redfish 仮想メディアを有効にするには、address 設定で redfish-virtualmedia:// を使用します。以下の例は、install-config.yaml ファイル内で Redfish 仮想メディアを使用する方法を示しています。 

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish-virtualmedia://<server_kvm_ip>/redfish/v1/Systems/<serial_number>
          username: <user>
          password: <password>
Copy to Clipboard Toggle word wrap

アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、bmc 設定に disableCertificateVerification: True を含める必要があります。次の例は、install-config.yaml ファイル内の disableCertificateVerification: True 設定パラメーターを使用した Redfish 設定を示しています。 

platform:
  baremetal:
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: redfish-virtualmedia://<server_kvm_ip>/redfish/v1/Systems/<serial_number>
          username: <user>
          password: <password>
          disableCertificateVerification: True
Copy to Clipboard Toggle word wrap

3.3.13.9. ルートデバイスのヒント
リンクのコピー

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

Expand
表3.13 サブフィールド
サブフィールド説明

deviceName

/dev/vda や /dev/disk/by-path/ などの Linux デバイス名を含む文字列。

注記

ストレージの場所への /dev/disk/by-path/<device_path> リンクを使用することを推奨します。

ヒントは、実際の値と完全に一致する必要があります。

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"
Copy to Clipboard Toggle word wrap

3.3.13.10. プロキシーの設定
リンクのコピー

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

手順

  1. proxy キーマッピングの下にプロキシー値を追加します。 

    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>
    Copy to Clipboard Toggle word wrap

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

    noProxy: .example.com,172.22.0.0/24,10.10.0.0/24
    Copy to Clipboard Toggle word wrap

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

    主な留意事項:

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

3.3.13.11. プロビジョニングネットワークを使用しないデプロイ
リンクのコピー

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

platform:
  baremetal:
    apiVIPs:
      - <api_VIP>
    ingressVIPs:
      - <ingress_VIP>
    provisioningNetwork: "Disabled"
1
Copy to Clipboard Toggle word wrap
1
provisioningNetwork 設定を追加して、必要な場合はこれを Disabled に設定します。
重要

PXE ブートには provisioning ネットワークが必要です。provisioning ネットワークなしでデプロイする場合、redfish-virtualmedia や idrac-virtualmedia などの仮想メディア BMC アドレス指定オプションを使用する必要があります。詳細は、「HPE iLO の BMC アドレス指定」セクションの「HPE iLO の Redfish 仮想メディア」、または「Dell iDRAC の BMC アドレス指定」セクションの「Dell iDRAC の Redfish 仮想メディア」を参照してください。

3.3.13.12. デュアルスタックネットワークを使用したデプロイメント
リンクのコピー

OpenShift Container Platform クラスターのデュアルスタックネットワークでは、クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定できます。クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定するには、install-config.yaml ファイルで machineNetwork、clusterNetwork、および serviceNetwork 設定を編集します。それぞれの設定には、それぞれ 2 つの CIDR エントリーが必要です。プライマリーアドレスファミリーとして IPv4 ファミリーを持つクラスターの場合は、最初に IPv4 設定を指定します。プライマリーアドレスファミリーとして IPv6 ファミリーを持つクラスターの場合は、最初に 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
Copy to Clipboard Toggle word wrap
重要

ベアメタルプラットフォームで、install-config.yaml ファイルの networkConfig セクションで NMState 設定を指定した場合は、クラスターをデュアルスタックネットワークにデプロイできない問題を解決するために、interfaces.wait-ip: ipv4+ipv6 を NMState YAML ファイルに追加し、あし。

wait-ip パラメーターを含む NMState YAML 設定ファイルの例

networkConfig:
  nmstate:
    interfaces:
    - name: <interface_name>
# ...
      wait-ip: ipv4+ipv6
# ...
Copy to Clipboard Toggle word wrap

IPv4 および IPv6 アドレスを使用するアプリケーションのクラスターへのインターフェイスを提供するには、Ingress VIP および API VIP サービスの IPv4 および IPv6 仮想 IP (VIP) アドレスエンドポイントを設定します。IPv4 および IPv6 アドレスエンドポイントを設定するには、install-config.yaml ファイルで apiVIPs および ingressVIPs 設定を編集します。apiVIPs および ingressVIPs 設定では、リスト形式を使用します。リストの順序は、各サービスのプライマリーおよびセカンダリー VIP アドレスを示しています。 

platform:
  baremetal:
    apiVIPs:
      - <api_ipv4>
      - <api_ipv6>
    ingressVIPs:
      - <wildcard_ipv4>
      - <wildcard_ipv6>
Copy to Clipboard Toggle word wrap
注記

デュアルスタックネットワーク設定のクラスターの場合、IPv4 アドレスと IPv6 アドレスの両方を同じインターフェイスに割り当てる必要があります。

3.3.13.13. ホストネットワークインターフェイスの設定
リンクのコピー

インストールの前に、install-config.yaml ファイルで networkConfig 設定を設定し、NMState を使用してホストネットワークインターフェイスを設定できます。

この機能の最も一般的な使用例は、ベアメタルネットワークで静的 IP アドレスを指定することですが、ストレージネットワークなどの他のネットワークを設定することもできます。この機能は、VLAN、VXLAN、ブリッジ、ボンド、ルート、MTU、DNS リゾルバー設定など、他の NMState 機能をサポートします。

警告

クラスターの DNS リゾルバー設定で、サポートされていない rotate オプションを設定しないでください。このオプションは、内部 API の DNS 解決機能を妨害します。

前提条件

  • 静的 IP アドレスを持つ各ノードの有効なホスト名で PTR DNS レコードを設定する。
  • NMState CLI (nmstate) をインストールする。
重要

プロビジョニングネットワークを使用する場合は、Ironic の dnsmasq ツールを使用して設定してください。完全に静的なデプロイメントを行うには、仮想メディアを使用する必要があります。

手順

  1. オプション: インストールプログラムは NMState YAML 構文をチェックしないため、install-config.yaml ファイルに NMState 構文を含める前に、nmstatectl gc を使用して NMState 構文をテストすることを検討してください。

    注記

    YAML 構文にエラーがあると、ネットワーク設定の適用に失敗する可能性があります。YAML 構文を検証して管理することは、デプロイ後に Kubernetes NMState を使用して変更を適用するときや、クラスターを拡張するときに役立ちます。

    1. NMState YAML ファイルを作成します。 

      interfaces:
      1 
      
- name: <nic1_name>
  type: ethernet
  state: up
  ipv4:
    address:
    - ip: <ip_address>
      prefix-length: 24
    enabled: true
dns-resolver:
  config:
    server:
    - <dns_ip_address>
routes:
  config:
  - destination: 0.0.0.0/0
    next-hop-address: <next_hop_ip_address>
    next-hop-interface: <next_hop_nic1_name>
      Copy to Clipboard Toggle word wrap
      1
      <nic1_name>、<ip_address>、<dns_ip_address>、<next_hop_ip_address>、および <next_hop_nic1_name> を適切な値に置き換えます。

    2. 次のコマンドを実行して、設定ファイルをテストします。 

      $ nmstatectl gc <nmstate_yaml_file>
      Copy to Clipboard Toggle word wrap

      <nmstate_yaml_file> を設定ファイル名に置き換えます。

  2. 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:
    2 
    
          - name: <nic1_name>
            type: ethernet
            state: up
            ipv4:
              address:
              - ip: <ip_address>
                prefix-length: 24
              enabled: true
          dns-resolver:
            config:
              server:
              - <dns_ip_address>
          routes:
            config:
            - destination: 0.0.0.0/0
              next-hop-address: <next_hop_ip_address>
              next-hop-interface: <next_hop_nic1_name>
    Copy to Clipboard Toggle word wrap
    1
    NMState YAML 構文を追加して、ホストインターフェイスを設定します。
    2
    <nic1_name>、<ip_address>、<dns_ip_address>、<next_hop_ip_address>、および <next_hop_nic1_name> を適切な値に置き換えます。
    重要

    クラスターをデプロイした後、install-config.yaml ファイルの networkConfig 設定を変更して、ホストネットワークインターフェイスを変更することはできません。Kubernetes NMState Operator を使用して、デプロイ後にホストネットワークインターフェイスに変更を加えます。

3.3.13.14. サブネット用のホストネットワークインターフェイスの設定
リンクのコピー

エッジコンピューティングのシナリオでは、コンピュートノードをエッジの近くに配置することが有益な場合があります。サブネット内のリモートノードを見つけるために、コントロールプレーンサブネットやローカルコンピュートノードに使用したものとは異なるネットワークセグメントまたはサブネットをリモートノードに使用できます。エッジコンピューティングシナリオ用にサブネットを設定することで、エッジのレイテンシーが短縮され、拡張性が向上します。

重要

デフォルトのロードバランサー OpenShiftManagedDefault を使用してリモートノードを OpenShift Container Platform クラスターに追加する場合は、すべてのコントロールプレーンノードが同じサブネット内で実行されている必要があります。複数のサブネットを使用する場合、マニフェストを使用して、コントロールプレーンノード上で実行されるように Ingress VIP を設定することもできます。詳細は、「コントロールプレーンで実行するネットワークコンポーネントの設定」を参照してください。

「サブネット間の通信を確立する」セクションの説明どおりにリモートノードに異なるネットワークセグメントまたはサブネットを確立した場合、ワーカーが静的 IP アドレス、ボンディング、またはその他の高度なネットワークを使用している場合は、machineNetwork 設定でサブネットを指定する必要があります。各リモートノードの networkConfig パラメーターでノード IP アドレスを設定する場合、静的 IP アドレスを使用する際に、コントロールプレーンノードを含むサブネットのゲートウェイと DNS サーバーも指定する必要があります。これにより、リモートノードがコントロールプレーンを含むサブネットに到達し、コントロールプレーンからネットワークトラフィックを受信できるようになります。

注記

複数のサブネットを持つクラスターをデプロイするには、redfish-virtualmedia や idrac-virtualmedia などの仮想メディアを使用する必要があります。リモートノードがローカルプロビジョニングネットワークにアクセスできないためです。

手順

  1. 静的 IP アドレスを使用する場合は、install-config.yaml ファイルの machineNetwork にサブネットを追加します。 

    networking:
  machineNetwork:
  - cidr: 10.0.0.0/24
  - cidr: 192.168.0.0/24
  networkType: OVNKubernetes
    Copy to Clipboard Toggle word wrap

  2. 静的 IP アドレスまたはボンディングなどの高度なネットワークを使用する場合は、NMState 構文を使用して、各エッジコンピュートノードの networkConfig パラメーターにゲートウェイと DNS 設定を追加します。 

    networkConfig:
  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
    Copy to Clipboard Toggle word wrap
    1
    <interface_name> をインターフェイス名に置き換えます。
    2
    <node_ip> をノードの IP アドレスに置き換えます。
    3
    <gateway_ip> をゲートウェイの IP アドレスに置き換えます。
    4
    <dns_ip> を DNS サーバーの IP アドレスに置き換えます。

3.3.13.15. デュアルスタックネットワーク内における SLAAC のアドレス生成モードの設定
リンクのコピー

Stateless Address AutoConfiguration (SLAAC) を使用するデュアルスタッククラスターの場合は、ipv6.addr-gen-mode ネットワーク設定のグローバル値を指定する必要があります。NMState を使用してこの値を設定し、RAM ディスクとクラスター設定ファイルを設定できます。これらの場所で一貫した ipv6.addr-gen-mode を設定しないと、クラスター内の CSR リソースと BareMetalHost リソース間で IPv6 アドレスの不一致が発生する可能性があります。

前提条件

  • NMState CLI (nmstate) をインストールする。

手順

  1. オプション: インストールプログラムは NMState YAML 構文をチェックしないため、install-config.yaml ファイルに含める前に nmstatectl gc コマンドを使用して NMState YAML 構文をテストすることを検討してください。

    1. NMState YAML ファイルを作成します。 

      interfaces:
- name: eth0
  ipv6:
    addr-gen-mode: <address_mode>
      1
      Copy to Clipboard Toggle word wrap
      1
      <address_mode> を、クラスター内の IPv6 アドレスに必要なアドレス生成モードのタイプに置き換えます。有効な値は、eui64、stable-privacy、または random です。

    2. 次のコマンドを実行して、設定ファイルをテストします。 

      $ nmstatectl gc <nmstate_yaml_file>
      1
      Copy to Clipboard Toggle word wrap
      1
      <nmstate_yaml_file> を、テスト設定ファイルの名前に置き換えます。

  2. NMState 設定を、install-config.yaml ファイル内の hosts.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:
          interfaces:
          - name: eth0
            ipv6:
              addr-gen-mode: <address_mode>
    1 
    
...
    Copy to Clipboard Toggle word wrap
    1
    <address_mode> を、クラスター内の IPv6 アドレスに必要なアドレス生成モードのタイプに置き換えます。有効な値は、eui64、stable-privacy、または random です。

3.3.13.16. デュアルポート NIC 用のホストネットワークインターフェイスの設定
リンクのコピー

インストール前に、install-config.yaml ファイルで networkConfig を設定し、NMState を使用してデュアルポートネットワークインターフェイスコントローラー (NIC) をサポートすることで、ホストネットワークインターフェイスを設定できます。

OpenShift Virtualization は以下のボンドモードのみをサポートします。

  • mode=1 active-backup
  • mode=2 balance-xor
  • mode=4 802.3ad

前提条件

  • 静的 IP アドレスを持つ各ノードの有効なホスト名で PTR DNS レコードを設定する。
  • NMState CLI (nmstate) をインストールする。
注記

YAML 構文にエラーがあると、ネットワーク設定の適用に失敗する可能性があります。YAML 構文を検証して管理することは、デプロイ後に Kubernetes NMState を使用して変更を適用するときや、クラスターを拡張するときに役立ちます。

手順

  1. install-config.yaml ファイル内のホストの networkConfig フィールドに NMState 設定を追加します。 

        hosts:
      - name: worker-0
        role: worker
        bmc:
          address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
          username: <user>
          password: <password>
          disableCertificateVerification: false
        bootMACAddress: <NIC1_mac_address>
        bootMode: UEFI
        networkConfig:
    1 
    
          interfaces:
    2 
    
           - name: eno1
    3 
    
             type: ethernet
    4 
    
             state: up
             mac-address: 0c:42:a1:55:f3:06
             ipv4:
               enabled: true
               dhcp: false
    5 
    
             ethernet:
               sr-iov:
                 total-vfs: 2
    6 
    
             ipv6:
               enabled: false
               dhcp: false
           - name: sriov:eno1:0
             type: ethernet
             state: up
    7 
    
             ipv4:
               enabled: false
    8 
    
             ipv6:
               enabled: false
           - name: sriov:eno1:1
             type: ethernet
             state: down
           - name: eno2
             type: ethernet
             state: up
             mac-address: 0c:42:a1:55:f3:07
             ipv4:
               enabled: true
             ethernet:
               sr-iov:
                 total-vfs: 2
             ipv6:
               enabled: false
           - name: sriov:eno2:0
             type: ethernet
             state: up
             ipv4:
               enabled: false
             ipv6:
               enabled: false
           - name: sriov:eno2:1
             type: ethernet
             state: down
           - name: bond0
             type: bond
             state: up
             min-tx-rate: 100
    9 
    
             max-tx-rate: 200
    10 
    
             link-aggregation:
               mode: active-backup
    11 
    
               options:
                 primary: sriov:eno1:0
    12 
    
               port:
                 - sriov:eno1:0
                 - sriov:eno2:0
             ipv4:
               address:
                 - ip: 10.19.16.57
    13 
    
                   prefix-length: 23
               dhcp: false
               enabled: true
             ipv6:
               enabled: false
          dns-resolver:
            config:
              server:
                - 10.11.5.160
                - 10.2.70.215
          routes:
            config:
              - destination: 0.0.0.0/0
                next-hop-address: 10.19.17.254
                next-hop-interface: bond0
    14 
    
                table-id: 254
    Copy to Clipboard Toggle word wrap
    1
    networkConfig フィールドには、ホストのネットワーク設定に関する情報を含めます。interfaces、dns-resolver、routes などのサブフィールドがあります。
    2
    interfaces フィールドは、ホスト用に定義されたネットワークインターフェイスの配列です。
    3
    インターフェイスの名前。
    4
    インターフェイスのタイプ。この例では、イーサネットインターフェイスを作成します。
    5
    厳密に必要ではない場合、物理機能 (PF) の DHCP を無効にするには、これを false に設定します。
    6
    インスタンス化する SR-IOV 仮想機能 (VF) の数に設定します。
    7
    これを up に設定します。
    8
    ボンドに接続された VF の IPv4 アドレス指定を無効にするには、これを false に設定します。
    9
    VF の最小伝送速度 (Mbps) を設定します。このサンプル値は、100 Mbps のレートを設定します。
    • この値は、最大伝送レート以下である必要があります。
    • Intel NIC は min-tx-rate パラメーターをサポートしていません。詳細は、BZ#1772847 を参照してください。
    10
    VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。
    11
    必要なボンディングモードを設定します。
    12
    ボンディングインターフェイスの優先ポートを設定します。ボンディングは、プライマリーデバイスをボンディングインターフェイスの最初のデバイスとして使用します。ボンディングは、障害が発生しない限り、プライマリーデバイスインターフェイスを放棄しません。この設定が特に役立つのは、ボンディングインターフェイスの NIC の 1 つが高速なため、大規模な負荷に対応できる場合です。この設定は、ボンディングインターフェイスが active-backup モード (モード 1) の場合にのみ有効です。
    13
    ボンドインターフェイスの静的 IP アドレスを設定します。これはノードの IP アドレスです。
    14
    デフォルトルートのゲートウェイとして bond0 を設定します。
    重要

    クラスターをデプロイした後は、install-config.yaml ファイルの networkConfig 設定を変更してホストネットワークインターフェイスを変更することはできません。Kubernetes NMState Operator を使用して、デプロイ後にホストネットワークインターフェイスに変更を加えます。

3.3.13.17. 複数のクラスターノードの設定
リンクのコピー

同じ設定で 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
Copy to Clipboard Toggle word wrap
注記

複数のクラスターノードの設定は、installer-provisioned infrastructure での初期デプロイメントでのみ使用できます。

3.3.13.18. マネージドセキュアブートの設定
リンクのコピー

redfish、redfish-virtualmedia、idrac-virtualmedia などの Redfish BMC アドレス指定を使用して、installer-provisioned クラスターをデプロイする際に管理対象 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
Copy to Clipboard Toggle word wrap

1
bmc.address 設定は、redfish、redfish-virtualmedia、または idrac-virtualmedia をプロトコルとして使用することを確認します。詳細は、「HPE iLO の BMC アドレス指定」または「Dell iDRAC の BMC アドレス指定」を参照してください。
2
bootMode 設定は、デフォルトで UEFI となります。これを UEFISecureBoot に変更して、マネージド Secure Boot を有効にします。
注記

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

注記

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

3.3.14. マニフェスト設定ファイル
リンクのコピー

3.3.14.1. OpenShift Container Platform マニフェストの作成
リンクのコピー

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

    $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests
    Copy to Clipboard Toggle word wrap 
    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
    Copy to Clipboard Toggle word wrap

3.3.14.2. 非接続クラスター向けの NTP 設定
リンクのコピー

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

非接続クラスター向けの NTP 設定
View larger image
非接続クラスター向けの NTP 設定

OpenShift Container Platform のノードは、適切に実行するために日付と時刻が一致している必要があります。コンピュートノードがコントロールプレーンノード上の NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続していないために上位層の NTP サーバーにアクセスできないクラスターのインストールと操作が可能になります。

手順

  1. 次のコマンドを使用して、インストールホストに Butane をインストールします。 

    $ sudo dnf -y install butane
    Copy to Clipboard Toggle word wrap

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

    注記

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

    Butane 設定例

    variant: openshift
version: 4.18.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 compute 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
    Copy to Clipboard Toggle word wrap

    1
    <cluster-name> はクラスターの名前に置き換え、<domain> は完全修飾ドメイン名に置き換える必要があります。

  3. Butane を使用して、コントロールプレーンノードに配信される設定が含まれる MachineConfig オブジェクトファイル (99-master-chrony-conf-override.yaml) を生成します。 

    $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap

  4. コントロールプレーンノード上の NTP サーバーを参照するコンピュートノードの chrony.conf ファイルの内容を含む Butane 設定 99-worker-chrony-conf-override.bu を作成します。

    Butane 設定例

    variant: openshift
version: 4.18.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
    Copy to Clipboard Toggle word wrap

    1
    <cluster-name> はクラスターの名前に置き換え、<domain> は完全修飾ドメイン名に置き換える必要があります。

  5. Butane を使用して、ワーカーノードに配信される設定が含まれる MachineConfig オブジェクトファイル (99-worker-chrony-conf-override.yaml) を生成します。 

    $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
    Copy to Clipboard Toggle word wrap

3.3.14.3. コントロールプレーンで実行されるネットワークコンポーネントの設定
リンクのコピー

ネットワークコンポーネントは、コントロールプレーンノードでのみ実行するように設定できます。デフォルトで、OpenShift Container Platform はマシン設定プールの任意のノードが ingressVIP 仮想 IP アドレスをホストできるようにします。ただし、環境によっては、コントロールプレーンノードとは別のサブネットにコンピュートノードがデプロイされるため、コントロールプレーンノードで実行するために ingressVIP 仮想 IP アドレスを設定する必要があります。

重要

リモートノードを別々のサブネットにデプロイする場合は、コントロールプレーンノード専用に ingressVIP 仮想 IP アドレスを配置する必要があります。

installer-provisioned ネットワーク
View larger image
installer-provisioned ネットワーク

手順

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

    $ cd ~/clusterconfigs
    Copy to Clipboard Toggle word wrap

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

    $ cd manifests
    Copy to Clipboard Toggle word wrap

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

    $ touch cluster-network-avoid-workers-99-config.yaml
    Copy to Clipboard Toggle word wrap

  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:,
    Copy to Clipboard Toggle word wrap

    このマニフェストは、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: ""
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    注記

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

3.3.14.4. コンピュートノードへのルーターのデプロイ
リンクのコピー

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

重要

コンピュートノードが 1 つだけのクラスターのデプロイはサポートされていません。ルーターのレプリカを変更すると、1 つのコンピュートノードでデプロイする場合の degraded 状態の問題が解決されますが、クラスターで Ingress API の高可用性が失われるため、実稼働環境には適していません。

注記

デフォルトでは、インストールプログラムは 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: ""
    Copy to Clipboard Toggle word wrap
    注記

    <num-of-router-pods> を適切な値に置き換えます。1 つのコンピュートノードのみを使用する場合は、replicas: を 1 に設定します。3 つ以上のコンピュートノードを使用する場合は、必要に応じて、replicas: をデフォルト値 2 から増やすことができます。

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

    $ cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml
    Copy to Clipboard Toggle word wrap

3.3.14.5. BIOS の設定
リンクのコピー

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

手順

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

  2. ノードに対応する BareMetalHost リソースファイルを変更します。 

    $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
    Copy to Clipboard Toggle word wrap

  3. BIOS 設定を BareMetalHost リソースの spec セクションに追加します。 

    spec:
  firmware:
    simultaneousMultithreadingEnabled: true
    sriovEnabled: true
    virtualizationEnabled: true
    Copy to Clipboard Toggle word wrap
    注記

    Red Hat は 3 つの BIOS 設定をサポートしています。BMC タイプ irmc のサーバーのみがサポートされます。他のタイプのサーバーは現在サポートされていません。

  4. クラスターを作成します。

3.3.14.6. RAID の設定
リンクのコピー

次の手順では、インストールプロセス中にベースボード管理コントローラー (BMC) を使用して Redundant Array of Independent Disks (RAID) を構成します。

注記

ノードにハードウェア RAID を設定する場合は、ノードにサポートされている RAID コントローラーがあることを確認してください。OpenShift Container Platform 4.18 は、ソフトウェア RAID をサポートしていません。

Expand
表3.14 ベンダーによるハードウェア RAID のサポート
ベンターBMC とプロトコルファームウェアのバージョンRAID レベル

Fujitsu

iRMC

該当なし

0、1、5、6、10

Dell

iDRAC と Redfish

バージョン 6.10.30.20 以降

0、1、5

手順

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

  2. ノードに対応する BareMetalHost リソースを変更します。 

    $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
    Copy to Clipboard Toggle word wrap
    注記

    OpenShift Container Platform 4.18 はソフトウェア RAID をサポートしていないため、次の例ではハードウェア RAID 設定を使用します。

    1. 特定の RAID 設定を spec セクションに追加した場合、これが原因でノードは preparing フェーズで元の RAID 設定を削除し、RAID で指定された設定を実行します。以下に例を示します。 

      spec:
  raid:
    hardwareRAIDVolumes:
    - level: "0"
      1 
      
      name: "sda"
      numberOfPhysicalDisks: 1
      rotational: true
      sizeGibibytes: 0
      Copy to Clipboard Toggle word wrap
      1
      level は必須フィールドであり、その他はオプションのフィールドです。

    2. spec セクションに空の RAID 設定を追加した場合、空の設定が原因で、ノードは preparing フェーズで元の RAID 設定を削除しますが、新しい設定は実行しません。以下に例を示します。 

      spec:
  raid:
    hardwareRAIDVolumes: []
      Copy to Clipboard Toggle word wrap
    3. spec セクションに raid フィールドを追加しない場合、元の RAID 設定は削除されず、新しい設定は実行されません。
  3. クラスターを作成します。

3.3.14.7. ノード上のストレージの設定
リンクのコピー

Machine Config Operator (MCO) によって管理される MachineConfig オブジェクトを作成することにより、OpenShift Container Platform ノード上のオペレーティングシステムに変更を加えることができます。

MachineConfig 仕様には、最初の起動時にマシンを設定するための点火設定が含まれています。この設定オブジェクトを使用して、OpenShift Container Platform マシン上で実行されているファイル、systemd サービス、およびその他のオペレーティングシステム機能を変更できます。

手順

ignition config を使用して、ノード上のストレージを設定します。次の MachineSet マニフェストの例は、プライマリーノード上のデバイスにパーティションを追加する方法を示しています。この例では、インストール前にマニフェストを適用して、プライマリーノードでサイズが 16 GiB の recovery という名前のパーティションを設定します。

  1. custom-partitions.yaml ファイルを作成し、パーティションレイアウトを含む MachineConfig オブジェクトを含めます。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: primary
  name: 10_primary_storage_config
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      disks:
        - device: </dev/xxyN>
          partitions:
            - label: recovery
              startMiB: 32768
              sizeMiB: 16384
      filesystems:
        - device: /dev/disk/by-partlabel/recovery
          label: recovery
          format: xfs
    Copy to Clipboard Toggle word wrap

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

    $ cp ~/<MachineConfig_manifest> ~/clusterconfigs/openshift
    Copy to Clipboard Toggle word wrap

3.3.15. 非接続レジストリーの作成
リンクのコピー

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

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

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

レジストリーノードでの非接続レジストリーの作成はオプションです。レジストリーノードで切断されたレジストリーを作成する必要がある場合は、次のサブセクションをすべて完了する必要があります。

3.3.15.1. 前提条件
リンクのコピー

3.3.15.2. ミラーリングされたレジストリーをホストするためのレジストリーノードの準備
リンクのコピー

ベアメタルでミラー化されたレジストリーをホストする前に、次の手順を完了する必要があります。

手順

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

    $ sudo firewall-cmd --add-port=5000/tcp --zone=libvirt  --permanent
    Copy to Clipboard Toggle word wrap 
    $ sudo firewall-cmd --add-port=5000/tcp --zone=public   --permanent
    Copy to Clipboard Toggle word wrap 
    $ sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

  2. レジストリーノードに必要なパッケージをインストールします。 

    $ sudo yum -y install python3 podman httpd httpd-tools jq
    Copy to Clipboard Toggle word wrap

  3. リポジトリー情報が保持されるディレクトリー構造を作成します。 

    $ sudo mkdir -p /opt/registry/{auth,certs,data}
    Copy to Clipboard Toggle word wrap

以下の手順を実行して、切断されたレジストリーの OpenShift Container Platform イメージリポジトリーをミラーリングします。

前提条件

  • ミラーホストがインターネットにアクセスできる。
  • ネットワークが制限された環境で使用するミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできる。
  • Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を組み込むように変更している。

手順

  1. OpenShift Container Platform ダウンロード ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、Repository Tags ページで対応するタグを判別します。

  2. 必要な環境変数を設定します。

    1. リリースバージョンをエクスポートします。 

      $ OCP_RELEASE=<release_version>
      Copy to Clipboard Toggle word wrap

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

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

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
      Copy to Clipboard Toggle word wrap

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

    3. ローカルリポジトリー名をエクスポートします。 

      $ LOCAL_REPOSITORY='<local_repository_name>'
      Copy to Clipboard Toggle word wrap

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

    4. ミラーリングするリポジトリーの名前をエクスポートします。 

      $ PRODUCT_REPO='openshift-release-dev'
      Copy to Clipboard Toggle word wrap

      実稼働環境のリリースの場合には、openshift-release-dev を指定する必要があります。

    5. パスをレジストリープルシークレットにエクスポートします。 

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'
      Copy to Clipboard Toggle word wrap

      <path_to_pull_secret> には、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。

    6. リリースミラーをエクスポートします。 

      $ RELEASE_NAME="ocp-release"
      Copy to Clipboard Toggle word wrap

      実稼働環境のリリースは、ocp-release を指定する必要があります。

    7. クラスターのアーキテクチャーのタイプをエクスポートします。 

      $ ARCHITECTURE=<cluster_architecture>
      1
      Copy to Clipboard Toggle word wrap
      1
      x86_64、aarch64、s390x、または ppc64le など、クラスターのアーキテクチャーを指定します。

    8. ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。 

      $ REMOVABLE_MEDIA_PATH=<path>
      1
      Copy to Clipboard Toggle word wrap
      1
      最初のスラッシュ (/) 文字を含む完全パスを指定します。

  3. バージョンイメージをミラーレジストリーにミラーリングします。

    • ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。

      1. リムーバブルメディアをインターネットに接続しているシステムに接続します。

      2. ミラーリングするイメージおよび設定マニフェストを確認します。 

        $ 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
        Copy to Clipboard Toggle word wrap
      3. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

      4. イメージをリムーバブルメディア上のディレクトリーにミラーリングします。 

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
        Copy to Clipboard Toggle word wrap

      5. メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。 

        $ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
        1
        Copy to Clipboard Toggle word wrap
        1
        REMOVABLE_MEDIA_PATH の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。

    • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。

      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}
        Copy to Clipboard Toggle word wrap

        このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な imageContentSources データが含まれます。

      2. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

        注記

        ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。

  4. ミラーリングしたコンテンツに基づくインストールプログラムを作成するために、インストールプログラムを展開してリリースに固定します。

    • ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。 

      $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
      Copy to Clipboard Toggle word wrap

    • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下のコマンドを実行します。 

      $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
      Copy to Clipboard Toggle word wrap
      重要

      選択した OpenShift Container Platform のバージョンに適したイメージを確実に使用するために、ミラーリングしたコンテンツからインストールプログラムを展開する必要があります。

      インターネット接続のあるマシンで、このステップを実行する必要があります。

      非接続環境を使用している場合には、must-gather の一部として --image フラグを使用し、ペイロードイメージを参照します。

  5. installer-provisioned infrastructure を使用するクラスターの場合は、以下のコマンドを実行します。 

    $ openshift-baremetal-install
    Copy to Clipboard Toggle word wrap

3.3.15.4. 非接続レジストリーを使用するように install-config.yaml ファイルを変更する
リンクのコピー

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

手順

  1. 非接続レジストリーノードの証明書を install-config.yaml ファイルに追加します。 

    $ echo "additionalTrustBundle: |" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

    証明書は "additionalTrustBundle: |" 行に従い、通常は 2 つのスペースで適切にインデントされる必要があります。 

    $ sed -e 's/^/  /' /opt/registry/certs/domain.crt >> install-config.yaml
    Copy to Clipboard Toggle word wrap

  2. レジストリーのミラー情報を install-config.yaml ファイルに追加します。 

    $ echo "imageContentSources:" >> install-config.yaml
    Copy to Clipboard Toggle word wrap 
    $ echo "- mirrors:" >> install-config.yaml
    Copy to Clipboard Toggle word wrap 
    $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

    registry.example.com をレジストリーの完全修飾ドメイン名に置き換えます。 

    $ echo "  source: quay.io/openshift-release-dev/ocp-release" >> install-config.yaml
    Copy to Clipboard Toggle word wrap 
    $ echo "- mirrors:" >> install-config.yaml
    Copy to Clipboard Toggle word wrap 
    $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

    registry.example.com をレジストリーの完全修飾ドメイン名に置き換えます。 

    $ echo "  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml
    Copy to Clipboard Toggle word wrap

3.3.16. インストールの検証チェックリスト
リンクのコピー

  • ❏ OpenShift Container Platform インストーラーが取得されている。
  • ❏ OpenShift Container Platform インストーラーが展開されている。
  • ❏ install-config.yaml の必須パラメーターが設定されている。
  • ❏ install-config.yaml の hosts パラメーターが設定されている。
  • ❏ install-config.yaml の bmc パラメーターが設定されている。
  • ❏ bmc address フィールドで設定されている値の変換が適用されている。
  • ❏ OpenShift Container Platform マニフェストが作成されている。
  • ❏ (オプション) コンピュートノードにルーターがデプロイされている。
  • ❏ (オプション) 切断されたレジストリーを作成している。
  • ❏ (オプション) 非接続レジストリー設定が使用されている場合にこれを検証する。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat