10.5. クラスターの拡張
インストーラーでプロビジョニングされる OpenShift Container Platform クラスターのデプロイ後に、以下の手順を使用してワーカーノードの数を拡張することができます。それぞれの候補となるワーカーノードが前提条件を満たしていることを確認します。
RedFish Virtual Media を使用してクラスターを拡張するには、最低限のファームウェア要件を満たす必要があります。RedFish Virtual Media を使用したクラスターの拡張時についての詳細は、前提条件セクションの仮想メディアを使用したインストールのファームウェア要件を参照してください。
10.5.1. ベアメタルノードの準備
クラスターを拡張するには、DHCP サーバーが必要です。各ノードに DHCP 予約が必要です。
一部の管理者は、各ノードの IP アドレスが DHCP サーバーがない状態で一定になるように静的 IP アドレスの使用を選択します。OpenShift Container Platform クラスターで静的 IP アドレスを使用するには、DHCP サーバーの IP アドレスを無限リースで予約 します。インストーラーがノードを正常にプロビジョニングした後に、dispatcher スクリプトがノードのネットワーク設定をチェックします。dispatcher スクリプトがネットワーク設定に DHCP 無限リースが含まれていることを検出すると、DHCP の無限リースの IP アドレスを使用して接続を静的 IP 接続として再作成します。DHCP 無限リースのない NIC は変更されないままになります。
IP アドレスを無限リースで設定することは、Machine Config Operator を使用してデプロイされるネットワーク設定と互換性がありません。
ベアメタルノードを準備するには、プロビジョナーノードから以下の手順を実行する必要があります。
手順
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
- ベースボード管理コントローラーを使用してベアメタルノードの電源を切り、オフになっていることを確認します。
ベアメタルノードのベースボード管理コントローラーのユーザー名およびパスワードを取得します。次に、ユーザー名とパスワードから
base64文字列を作成します。$ echo -ne "root" | base64
$ echo -ne "password" | base64
ベアメタルノードの設定ファイルを作成します。
$ vim bmh.yaml
--- apiVersion: v1 kind: Secret metadata: name: openshift-worker-<num>-bmc-secret type: Opaque data: username: <base64-of-uid> password: <base64-of-pwd> --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: openshift-worker-<num> spec: online: true bootMACAddress: <NIC1-mac-address> bmc: address: <protocol>://<bmc-ip> credentialsName: openshift-worker-<num>-bmc-secret2 つの
nameフィールドおよびcredentialsNameフィールドのベアメタルのワーカー数の<num>を置き換えます。<base64-of-uid>を、ユーザー名のbase64文字列に置き換えます。<base64-of-pwd>を、パスワードのbase64文字列に置き換えます。<NIC1-mac-address>を、ベアメタルの最初の NIC の MAC アドレスに置き換えます。追加の BMC 設定オプションについては、BMC アドレスのセクションを参照してください。
<protocol>を、IPMI、 RedFish その他の BMC プロトコルに置き換えマス。<bmc-ip>を、ベアメタルノードのベースボード管理コントローラー (BMC) の IP アドレスに置き換えます。注記既存のベアメタルノードの MAC アドレスが、プロビジョニングしようとしているベアメタルホストの MAC アドレスと一致する場合、Ironic インストールは失敗します。ホストの登録、検査、クリーニング、または他の Ironic 手順が失敗する場合、ベアメタル Operator はインストールを継続的に再試行します。詳細は、ホストが重複する MAC アドレスの診断 を参照してください。
ベアメタルノードを作成します。
$ oc -n openshift-machine-api create -f bmh.yaml
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> ready true
10.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.9.0 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 EOFBareMetalHostオブジェクトを表示するには、次のコマンドを実行します。$ 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 メンバーの置き換えを参照してください。
10.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: preProvisioningOSDownloadURLs: {} provisioningDHCPRange: 172.22.0.10,172.22.0.254 provisioningIP: 172.22.0.3 provisioningInterface: enp1s0 provisioningNetwork: Managed provisioningNetworkCIDR: 172.22.0.0/24 provisioningOSDownloadURL: http://192.168.111.1/images/rhcos-<version>.x86_64.qcow2.gz?sha256=<sha256> 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をprovisioningCR に追加します。
API VIP アドレスを使用するようにマシンセットを編集します。
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
10.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-apinamespace で実行されているベアメタルホストを取得します。$ 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 ...
10.5.5. ベアメタルノードのプロビジョニング
ベアメタルノードをプロビジョニングするには、プロビジョナーノードから以下の手順を実行する必要があります。
手順
ベアメタルノードをプロビジョニングする前に、
STATEがreadyにあることを確認します。$ oc -n openshift-machine-api get bmh openshift-worker-<num>
ここで、
<num>はワーカーノード数です。NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> ready true
ワーカーノードの数を取得します。
$ oc get nodes
NAME STATUS ROLES AGE VERSION provisioner.openshift.example.com Ready master 30h v1.22.1 openshift-master-1.openshift.example.com Ready master 30h v1.22.1 openshift-master-2.openshift.example.com Ready master 30h v1.22.1 openshift-master-3.openshift.example.com Ready master 30h v1.22.1 openshift-worker-0.openshift.example.com Ready master 30h v1.22.1 openshift-worker-1.openshift.example.com Ready master 30h v1.22.1
マシンセットを取得します。
$ 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> provisioning openshift-worker-<num>-65tjz true
プロビジョニングが完了したら、ベアメタルノードが準備状態であることを確認します。
$ oc get nodes
NAME STATUS ROLES AGE VERSION provisioner.openshift.example.com Ready master 30h v1.22.1 openshift-master-1.openshift.example.com Ready master 30h v1.22.1 openshift-master-2.openshift.example.com Ready master 30h v1.22.1 openshift-master-3.openshift.example.com Ready master 30h v1.22.1 openshift-worker-0.openshift.example.com Ready master 30h v1.22.1 openshift-worker-1.openshift.example.com Ready master 30h v1.22.1 openshift-worker-<num>.openshift.example.com Ready worker 3m27s v1.22.1
kubelet を確認することもできます。
$ ssh openshift-worker-<num>
[kni@openshift-worker-<num>]$ journalctl -fu kubelet
