13.5. クラスターの拡張
インストーラーでプロビジョニングされる OpenShift Container Platform クラスターのデプロイ後に、以下の手順を使用してワーカーノードの数を拡張することができます。それぞれの候補となるワーカーノードが前提条件を満たしていることを確認します。
RedFish Virtual Media を使用してクラスターを拡張するには、最低限のファームウェア要件を満たす必要があります。RedFish Virtual Media を使用したクラスターの拡張時についての詳細は、前提条件セクションの仮想メディアを使用したインストールのファームウェア要件を参照してください。
13.5.1. ベアメタルノードの準備
クラスターを拡張するには、ノードに関連する IP アドレスを提供する必要があります。これは、静的設定または DHCP (動的ホスト設定プロトコル) サーバーを使用して行うことができます。DHCP サーバーを使用してクラスターを拡張する場合、各ノードには DHCP 予約が必要です。
一部の管理者は、各ノードの IP アドレスが DHCP サーバーがない状態で一定になるように静的 IP アドレスの使用を選択します。NMState で静的 IP アドレスを設定するには、追加の詳細について、OpenShift インストールの環境のセットアップセクションの(オプション) install-config.yaml
でのホストネットワークインターフェイスの設定を参照してください。
ベアメタルノードを準備するには、プロビジョナーノードから以下の手順を実行する必要があります。
手順
oc
バイナリーを取得します。$ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux-$VERSION.tar.gz | tar zxvf - oc
$ sudo cp oc /usr/local/bin
- ベースボード管理コントローラー (BMC) を使用してベアメタルノードの電源を切り、オフになっていることを確認します。
ベアメタルノードのベースボード管理コントローラーのユーザー名およびパスワードを取得します。次に、ユーザー名とパスワードから
base64
文字列を作成します。$ echo -ne "root" | base64
$ echo -ne "password" | base64
ベアメタルノードの設定ファイルを作成します。静的設定または DHCP サーバーのどちらを使用しているかに応じて、次の例の
bmh.yaml
ファイルのいずれかを使用し、環境に合わせて YAML の値を置き換えます。$ vim bmh.yaml
静的設定
bmh.yaml
:--- apiVersion: v1 1 kind: Secret metadata: name: openshift-worker-<num>-network-config-secret 2 namespace: openshift-machine-api type: Opaque stringData: nmstate: | 3 interfaces: - name: <nic1_name> 4 type: ethernet state: up ipv4: address: - ip: <ip_address> 5 prefix-length: 24 enabled: true dns-resolver: config: server: - <dns_ip_address> 6 routes: config: - destination: 0.0.0.0/0 next-hop-address: <next_hop_ip_address> 7 next-hop-interface: <next_hop_nic1_name> 8 --- apiVersion: v1 kind: Secret metadata: name: openshift-worker-<num>-bmc-secret 9 namespace: openshift-machine-api type: Opaque data: username: <base64_of_uid> 10 password: <base64_of_pwd> 11 --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: openshift-worker-<num> 12 namespace: openshift-machine-api spec: online: True bootMACAddress: <nic1_mac_address> 13 bmc: address: <protocol>://<bmc_url> 14 credentialsName: openshift-worker-<num>-bmc-secret 15 disableCertificateVerification: True 16 username: <bmc_username> 17 password: <bmc_password> 18 rootDeviceHints: deviceName: <root_device_hint> 19 preprovisioningNetworkDataName: openshift-worker-<num>-network-config-secret 20
- 1
- 新しく作成されたノードのネットワークインターフェイスを設定するには、ネットワーク設定を含むシークレットの名前を指定します。
nmstate
構文に従って、ノードのネットワーク設定を定義します。NMState 構文の設定の詳細については、(オプション) install-config.yaml ファイルでのホストネットワークインターフェイスの設定を参照してください。 - 2 9 12 15
name
フィールド、credentialsName
フィールド、およびpreprovisioningNetworkDataName
フィールドで、ベアメタルノードのワーカー数の<num>
を置き換えます。- 3
- NMState YAML 構文を追加して、ホストインターフェイスを設定します。
- 4 5 6 7 8
<nic1_name>
、<ip_address>
、<dns_ip_address>
、<next_hop_ip_address>
、および<next_hop_nic1_name>
を適切な値に置き換えます。- 10 11
<base64_of_uid>
と<base64_of_pwd>
を、ユーザー名とパスワードの base64 文字列に置き換えます。- 13
<nic1_mac_address>
を、ベアメタルノードの最初の NIC の MAC アドレスに置き換えます。追加の BMC 設定オプションについては、BMC アドレス指定のセクションを参照してください。- 14
<protocol>
を、IPMI、 RedFish その他の BMC プロトコルに置き換えマス。<bmc_url>
を、ベアメタルノードのベースボード管理コントローラーの URL に置き換えます。- 16
- 証明書の検証をスキップするには、
disableCertificateVerification
を true に設定します。 - 17 18
<bmc_username>
と<bmc_password>
を BMC ユーザー名とパスワードの文字列に置き換えます。- 19
- オプション: root デバイスヒントを指定する場合は、
<root_device_hint>
をデバイスパスに置き換えます。 - 20
- オプション: 新しく作成されたノードのネットワークインターフェイスを設定した場合は、BareMetalHost CR の
preprovisioningNetworkDataName
にネットワーク設定のシークレット名を指定します。
DHCP 設定
bmh.yaml
:--- apiVersion: v1 kind: Secret metadata: name: openshift-worker-<num>-bmc-secret 1 namespace: openshift-machine-api type: Opaque data: username: <base64_of_uid> 2 password: <base64_of_pwd> 3 --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: openshift-worker-<num> 4 namespace: openshift-machine-api spec: online: True bootMACAddress: <nic1_mac_address> 5 bmc: address: <protocol>://<bmc_url> 6 credentialsName: openshift-worker-<num>-bmc-secret 7 disableCertificateVerification: True 8 username: <bmc_username> 9 password: <bmc_password> 10 rootDeviceHints: deviceName: <root_device_hint> 11 preprovisioningNetworkDataName: openshift-worker-<num>-network-config-secret 12
- 1 4 7
name
フィールド、credentialsName
フィールド、およびpreprovisioningNetworkDataName
フィールドで、ベアメタルノードのワーカー数の<num>
を置き換えます。- 2 3
<base64_of_uid>
と<base64_of_pwd>
を、ユーザー名とパスワードの base64 文字列に置き換えます。- 5
<nic1_mac_address>
を、ベアメタルノードの最初の NIC の MAC アドレスに置き換えます。追加の BMC 設定オプションについては、BMC アドレス指定のセクションを参照してください。- 6
<protocol>
を、IPMI、 RedFish その他の BMC プロトコルに置き換えマス。<bmc_url>
を、ベアメタルノードのベースボード管理コントローラーの URL に置き換えます。- 8
- 証明書の検証をスキップするには、
disableCertificateVerification
を true に設定します。 - 9 10
<bmc_username>
と<bmc_password>
を BMC ユーザー名とパスワードの文字列に置き換えます。- 11
- オプション: root デバイスヒントを指定する場合は、
<root_device_hint>
をデバイスパスに置き換えます。 - 12
- オプション: 新しく作成されたノードのネットワークインターフェイスを設定した場合は、BareMetalHost CR の
preprovisioningNetworkDataName
にネットワーク設定のシークレット名を指定します。
注記既存のベアメタルノードの MAC アドレスが、プロビジョニングしようとしているベアメタルホストの MAC アドレスと一致する場合、Ironic インストールは失敗します。ホストの登録、検査、クリーニング、または他の Ironic 手順が失敗する場合、ベアメタル Operator はインストールを継続的に再試行します。詳細については、ホストの重複した MAC アドレスの診断を参照してください。
ベアメタルノードを作成します。
$ oc -n openshift-machine-api create -f bmh.yaml
出力例
secret/openshift-worker-<num>-network-config-secret created secret/openshift-worker-<num>-bmc-secret created baremetalhost.metal3.io/openshift-worker-<num> created
ここで、
<num>
はワーカー数です。ベアメタルノードの電源をオンにし、これを検査します。
$ oc -n openshift-machine-api get bmh openshift-worker-<num>
ここで、
<num>
はワーカーノード数です。出力例
NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> available true
注記ワーカーノードがクラスターに参加できるようにするには、
machineset
オブジェクトをBareMetalHost
オブジェクトの数にスケーリングします。ノードは手動または自動でスケーリングできます。ノードを自動的にスケーリングするには、machineset
にmetal3.io/autoscale-to-hosts
アノテーションを使用します。
関連情報
- NMState 構文の設定に関する詳細は、(オプション) install-config.yaml ファイルでのホストネットワークインターフェイスの設定 を参照してください。
- マシンの自動スケーリングに関する詳細は、利用可能なベアメタルホストの数へのマシンの自動スケーリング を参照してください。
13.5.2. ベアメタルコントロールプレーンノードの交換
以下の手順を使用して、インストーラーによってプロビジョニングされた OpenShift Container Platform コントロールプレーンノードを置き換えます。
既存のコントロールプレーンホストから BareMetalHost
オブジェクト定義を再利用する場合は、externallyProvisioned
フィールドを true
に設定したままにしないでください。
既存のコントロールプレーン BareMetalHost
オブジェクトが、OpenShift Container Platform インストールプログラムによってプロビジョニングされた場合には、externallyProvisioned
フラグが true
に設定されている可能性があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 etcd のバックアップを取得している。
重要問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd のバックアップを作成してください。etcd バックアップの作成に関する詳細は、関連情報 セクションを参照してください。
手順
Bare Metal Operator が使用可能であることを確認します。
$ oc get clusteroperator baremetal
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE baremetal 4.10.12 True False False 3d15h
古い
BareMetalHost
オブジェクトおよびMachine
オブジェクトを削除します。$ oc delete bmh -n openshift-machine-api <host_name> $ oc delete machine -n openshift-machine-api <machine_name>
<host_name>
をホストの名前に、<machine_name>
をマシンの名前に置き換えます。マシン名はCONSUMER
フィールドの下に表示されます。BareMetalHost
オブジェクトとMachine
オブジェクトを削除すると、マシンコントローラーはNode
オブジェクトを自動的に削除します。新しい
BareMetalHost
オブジェクトとシークレットを作成して BMC 認証情報を保存します。$ cat <<EOF | oc apply -f - apiVersion: v1 kind: Secret metadata: name: control-plane-<num>-bmc-secret 1 namespace: openshift-machine-api data: username: <base64_of_uid> 2 password: <base64_of_pwd> 3 type: Opaque --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: control-plane-<num> 4 namespace: openshift-machine-api spec: automatedCleaningMode: disabled bmc: address: <protocol>://<bmc_ip> 5 credentialsName: control-plane-<num>-bmc-secret 6 bootMACAddress: <NIC1_mac_address> 7 bootMode: UEFI externallyProvisioned: false hardwareProfile: unknown online: true EOF
- 1 4 6
name
フィールドとcredentialsName
フィールドにあるベアメタルノードのコントロールプレーン数の<num>
を置き換えます。- 2
<base64_of_uid>
を、ユーザー名のbase64
文字列に置き換えます。- 3
<base64_of_pwd>>
を、パスワードのbase64
文字列に置き換えます。- 5
<protocol>
をredfish
、redfish-virtualmedia
、idrac-virtualmedia
などの BMC プロトコルに置き換えます。<bmc_ip>
を、ベアメタルノードのベースボード管理コントローラー (BMC) の IP アドレスに置き換えます。その他の BMC 設定オプションについては、関連情報 セクションのBMC アドレス指定を参照してください。- 7
<NIC1_mac_address>
を、ベアメタルの最初の NIC の MAC アドレスに置き換えます。
検査が完了すると、
BareMetalHost
オブジェクトが作成され、プロビジョニングできるようになります。利用可能な
BareMetalHost
オブジェクトを表示します。$ oc get bmh -n openshift-machine-api
出力例
NAME STATE CONSUMER ONLINE ERROR AGE control-plane-1.example.com available control-plane-1 true 1h10m control-plane-2.example.com externally provisioned control-plane-2 true 4h53m control-plane-3.example.com externally provisioned control-plane-3 true 4h53m compute-1.example.com provisioned compute-1-ktmmx true 4h53m compute-1.example.com provisioned compute-2-l2zmb true 4h53m
コントロールプレーンノード用の
MachineSet
オブジェクトがないため、代わりにMachine
オブジェクトを作成する必要があります。別のコントロールプレーンMachine
オブジェクトからproviderSpec
をコピーできます。Machine
オブジェクトを作成します。$ cat <<EOF | oc apply -f - apiVersion: machine.openshift.io/v1beta1 kind: Machine metadata: annotations: metal3.io/BareMetalHost: openshift-machine-api/control-plane-<num> 1 labels: machine.openshift.io/cluster-api-cluster: control-plane-<num> 2 machine.openshift.io/cluster-api-machine-role: master machine.openshift.io/cluster-api-machine-type: master name: control-plane-<num> 3 namespace: openshift-machine-api spec: metadata: {} providerSpec: value: apiVersion: baremetal.cluster.k8s.io/v1alpha1 customDeploy: method: install_coreos hostSelector: {} image: checksum: "" url: "" kind: BareMetalMachineProviderSpec metadata: creationTimestamp: null userData: name: master-user-data-managed EOF
BareMetalHost
オブジェクトを表示するには、次のコマンドを実行します。$ oc get bmh -A
出力例
NAME STATE CONSUMER ONLINE ERROR AGE control-plane-1.example.com provisioned control-plane-1 true 2h53m control-plane-2.example.com externally provisioned control-plane-2 true 5h53m control-plane-3.example.com externally provisioned control-plane-3 true 5h53m compute-1.example.com provisioned compute-1-ktmmx true 5h53m compute-2.example.com provisioned compute-2-l2zmb true 5h53m
RHCOS のインストール後、
BareMetalHost
がクラスターに追加されていることを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION control-plane-1.example.com available master 4m2s v1.18.2 control-plane-2.example.com available master 141m v1.18.2 control-plane-3.example.com available master 141m v1.18.2 compute-1.example.com available worker 87m v1.18.2 compute-2.example.com available worker 87m v1.18.2
注記新しいコントロールプレーンノードの交換後、新しいノードで実行されている etcd Pod は
crashloopback
ステータスになります。詳細は、関連情報 セクションの正常でない etcd メンバーの置き換えを参照してください。
13.5.3. ベアメタルネットワークに仮想メディアを使用してデプロイメントする準備
provisioning
ネットワークが有効で、baremetal
ネットワークで Virtual Media を使用してクラスターを拡張する場合は、以下の手順を使用します。
前提条件
-
baremetal
ネットワークおよびprovisioning
ネットワークを使用する既存のクラスターがあります。
手順
provisioning
カスタムリソース (CR) を編集して、baremetal
ネットワーク上の仮想メディアを使用したデプロイを有効にします。oc edit provisioning
apiVersion: metal3.io/v1alpha1 kind: Provisioning metadata: creationTimestamp: "2021-08-05T18:51:50Z" finalizers: - provisioning.metal3.io generation: 8 name: provisioning-configuration resourceVersion: "551591" uid: f76e956f-24c6-4361-aa5b-feaf72c5b526 spec: provisioningDHCPRange: 172.22.0.10,172.22.0.254 provisioningIP: 172.22.0.3 provisioningInterface: enp1s0 provisioningNetwork: Managed provisioningNetworkCIDR: 172.22.0.0/24 virtualMediaViaExternalNetwork: true 1 status: generations: - group: apps hash: "" lastGeneration: 7 name: metal3 namespace: openshift-machine-api resource: deployments - group: apps hash: "" lastGeneration: 1 name: metal3-image-cache namespace: openshift-machine-api resource: daemonsets observedGeneration: 8 readyReplicas: 0
- 1
virtualMediaViaExternalNetwork: true
をprovisioning
CR に追加します。
イメージ URL が存在する場合は、
machineset
を編集して API VIP アドレスを使用します。この手順は、バージョン 4.9 以前でインストールされたクラスターにのみ適用されます。oc edit machineset
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: creationTimestamp: "2021-08-05T18:51:52Z" generation: 11 labels: machine.openshift.io/cluster-api-cluster: ostest-hwmdt machine.openshift.io/cluster-api-machine-role: worker machine.openshift.io/cluster-api-machine-type: worker name: ostest-hwmdt-worker-0 namespace: openshift-machine-api resourceVersion: "551513" uid: fad1c6e0-b9da-4d4a-8d73-286f78788931 spec: replicas: 2 selector: matchLabels: machine.openshift.io/cluster-api-cluster: ostest-hwmdt machine.openshift.io/cluster-api-machineset: ostest-hwmdt-worker-0 template: metadata: labels: machine.openshift.io/cluster-api-cluster: ostest-hwmdt machine.openshift.io/cluster-api-machine-role: worker machine.openshift.io/cluster-api-machine-type: worker machine.openshift.io/cluster-api-machineset: ostest-hwmdt-worker-0 spec: metadata: {} providerSpec: value: apiVersion: baremetal.cluster.k8s.io/v1alpha1 hostSelector: {} image: checksum: http:/172.22.0.3:6181/images/rhcos-<version>.x86_64.qcow2.<md5sum> 1 url: http://172.22.0.3:6181/images/rhcos-<version>.x86_64.qcow2 2 kind: BareMetalMachineProviderSpec metadata: creationTimestamp: null userData: name: worker-user-data status: availableReplicas: 2 fullyLabeledReplicas: 2 observedGeneration: 11 readyReplicas: 2 replicas: 2
13.5.4. クラスター内の新しいホストをプロビジョニングする際の重複する MAC アドレスの診断
クラスター内の既存のベアメタルノードの MAC アドレスが、クラスターに追加しようとしているベアメタルホストの MAC アドレスと一致する場合、ベアメタル Operator はホストを既存のノードに関連付けます。ホストの登録、検査、クリーニング、または他の Ironic 手順が失敗する場合、ベアメタル Operator はインストールを継続的に再試行します。障害が発生したベアメタルホストの登録エラーが表示されます。
openshift-machine-api
namespace で実行されているベアメタルホストを調べることで、重複する MAC アドレスを診断できます。
前提条件
- ベアメタルに OpenShift Container Platform クラスターをインストールします。
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
プロビジョニングに失敗したベアメタルホストが既存のノードと同じ MAC アドレスを持つかどうかを判断するには、以下を実行します。
openshift-machine-api
namespace で実行されているベアメタルホストを取得します。$ oc get bmh -n openshift-machine-api
出力例
NAME STATUS PROVISIONING STATUS CONSUMER openshift-master-0 OK externally provisioned openshift-zpwpq-master-0 openshift-master-1 OK externally provisioned openshift-zpwpq-master-1 openshift-master-2 OK externally provisioned openshift-zpwpq-master-2 openshift-worker-0 OK provisioned openshift-zpwpq-worker-0-lv84n openshift-worker-1 OK provisioned openshift-zpwpq-worker-0-zd8lm openshift-worker-2 error registering
障害が発生したホストのステータスに関する詳細情報を表示するには、
<bare_metal_host_name>
をホストの名前に置き換えて、以下のコマンドを実行します。$ oc get -n openshift-machine-api bmh <bare_metal_host_name> -o yaml
出力例
... status: errorCount: 12 errorMessage: MAC address b4:96:91:1d:7c:20 conflicts with existing node openshift-worker-1 errorType: registration error ...
13.5.5. ベアメタルノードのプロビジョニング
ベアメタルノードをプロビジョニングするには、プロビジョナーノードから以下の手順を実行する必要があります。
手順
ベアメタルノードをプロビジョニングする前に、
STATE
がavailable
であることを確認してください。$ oc -n openshift-machine-api get bmh openshift-worker-<num>
ここで、
<num>
はワーカーノード数です。NAME STATE ONLINE ERROR AGE openshift-worker available true 34h
ワーカーノードの数を取得します。
$ oc get nodes
NAME STATUS ROLES AGE VERSION openshift-master-1.openshift.example.com Ready master 30h v1.23.0 openshift-master-2.openshift.example.com Ready master 30h v1.23.0 openshift-master-3.openshift.example.com Ready master 30h v1.23.0 openshift-worker-0.openshift.example.com Ready worker 30h v1.23.0 openshift-worker-1.openshift.example.com Ready worker 30h v1.23.0
マシンセットを取得します。
$ oc get machinesets -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE ... openshift-worker-0.example.com 1 1 1 1 55m openshift-worker-1.example.com 1 1 1 1 55m
ワーカーノードの数を 1 つずつ増やします。
$ oc scale --replicas=<num> machineset <machineset> -n openshift-machine-api
<num>
を、ワーカーノードの新たな数に置き換えます。<machineset>
を、直前の手順で設定されたマシン名に置き換えます。ベアメタルノードのステータスを確認します。
$ oc -n openshift-machine-api get bmh openshift-worker-<num>
ここで、
<num>
はワーカーノード数です。STATE がready
からprovisioning
に変わります。NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> provisioning openshift-worker-<num>-65tjz true
provisioning
ステータスは、OpenShift Container Platform クラスターがノードをプロビジョニングするまでそのままになります。この場合、30 分以上の時間がかかる場合があります。ノードがプロビジョニングされると、状態はprovisioned
に変わります。NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> provisioned openshift-worker-<num>-65tjz true
プロビジョニングが完了したら、ベアメタルノードが準備状態であることを確認します。
$ oc get nodes
NAME STATUS ROLES AGE VERSION openshift-master-1.openshift.example.com Ready master 30h v1.23.0 openshift-master-2.openshift.example.com Ready master 30h v1.23.0 openshift-master-3.openshift.example.com Ready master 30h v1.23.0 openshift-worker-0.openshift.example.com Ready worker 30h v1.23.0 openshift-worker-1.openshift.example.com Ready worker 30h v1.23.0 openshift-worker-<num>.openshift.example.com Ready worker 3m27s v1.23.0
kubelet を確認することもできます。
$ ssh openshift-worker-<num>
[kni@openshift-worker-<num>]$ journalctl -fu kubelet