11.4. コンピュートマシンのベアメタルへの追加
ベアメタルの OpenShift Container Platform クラスターにコンピュートマシンを追加することができます。
11.4.1. 前提条件
- クラスターをベアメタルにインストールしている。
- クラスターの作成に使用したインストールメディアおよび Red Hat Enterprise Linux CoreOS (RHCOS) イメージがある。これらのファイルがない場合は、インストール手順 に従って取得する必要があります。
- ユーザーがプロビジョニングするインフラストラクチャーに DHCP サーバーを利用できる場合には追加のコンピュートマシンの詳細を DHCP サーバー設定に追加している。これには、永続的な IP アドレス、DNS サーバー情報、および各マシンのホスト名が含まれます。
- 追加する各コンピュートマシンのレコード名と IP アドレスを追加するように DNS 設定を更新している。DNS ルックアップおよび逆引き DNS ルックアップが正しく解決されていることを検証している。
クラスターの作成に使用された Red Hat Enterprise Linux CoreOS (RHCOS) イメージへのアクセスがない場合、より新しいバージョンの Red Hat Enterprise Linux CoreOS (RHCOS) イメージと共にコンピュートマシンを OpenShift Container Platform クラスターに追加できます。手順は、OpenShift 4.6+ へのアップグレード後の新規ノードの UPI クラスターへの追加の失敗 を参照してください。
11.4.2. Red Hat Enterprise Linux CoreOS (RHCOS) マシンの作成
ベアメタルインフラストラクチャーにインストールされているクラスターにコンピュートマシンを追加する前に、それが使用する RHCOS マシンを作成する必要があります。ISO イメージまたはネットワーク PXE ブートを使用してマシンを作成できます。
クラスターに新しいノードをすべてデプロイするには、クラスターのインストールに使用した ISO イメージと同じ ISO イメージを使用する必要があります。同じ Ignition 設定ファイルを使用することが推奨されます。ノードは、ワークロードを実行する前に初回起動時に自動的にアップグレードされます。アップグレードの前後にノードを追加することができます。
11.4.2.1. ISO イメージを使用した RHCOS マシンの作成
ISO イメージを使用して、ベアメタルクラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。
前提条件
- クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、クラスターから Ignition 設定ファイルを抽出します。
$ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
-
クラスターからエクスポートした
worker.ign
Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。 Ignition ファイルが URL で利用可能であることを検証できます。次の例では、コンピュートノードの Ignition 設定ファイルを取得します。
$ curl -k http://<HTTP_server>/worker.ign
次のコマンドを実行すると、新しいマシンを起動するための ISO イメージにアクセスできます。
RHCOS_VHD_ORIGIN_URL=$(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' | jq -r '.architectures.<architecture>.artifacts.metal.formats.iso.disk.location')
ISO ファイルを使用して、追加のコンピュートマシンに RHCOS をインストールします。クラスターのインストール前にマシンを作成する際に使用したのと同じ方法を使用します。
- ディスクに ISO イメージを書き込み、これを直接起動します。
- LOM インターフェイスで ISO リダイレクトを使用します。
オプションを指定したり、ライブ起動シーケンスを中断したりせずに、RHCOS ISO イメージを起動します。インストーラーが RHCOS ライブ環境でシェルプロンプトを起動するのを待ちます。
注記RHCOS インストールの起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに、次の手順で概説するように
coreos-installer
コマンドを使用する必要があります。coreos-installer
コマンドを実行し、インストール要件を満たすオプションを指定します。少なくとも、ノードタイプの Ignition 設定ファイルを参照する URL と、インストール先のデバイスを指定する必要があります。$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12
注記TLS を使用する HTTPS サーバーを使用して Ignition 設定ファイルを提供する場合は、
coreos-installer
を実行する前に、内部認証局 (CA) をシステムのトラストストアに追加できます。以下の例では、
/dev/sda
デバイスへのブートストラップノードのインストールを初期化します。ブートストラップノードの Ignition 設定ファイルは、IP アドレス 192.168.1.2 で HTTP Web サーバーから取得されます。$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
マシンのコンソールで RHCOS インストールの進捗を監視します。
重要OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
- 継続してクラスター用の追加のコンピュートマシンを作成します。
11.4.2.2. PXE または iPXE ブートによる RHCOS マシンの作成
PXE または iPXE ブートを使用して、ベアメタルクラスターの追加の Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンを作成できます。
前提条件
- クラスターのコンピュートマシンの Ignition 設定ファイルの URL を取得します。このファイルがインストール時に HTTP サーバーにアップロードされている必要があります。
-
クラスターのインストール時に HTTP サーバーにアップロードした RHCOS ISO イメージ、圧縮されたメタル BIOS、
kernel
、およびinitramfs
ファイルの URL を取得します。 - インストール時に OpenShift Container Platform クラスターのマシンを作成するために使用した PXE ブートインフラストラクチャーにアクセスできる必要があります。RHCOS のインストール後にマシンはローカルディスクから起動する必要があります。
-
UEFI を使用する場合、OpenShift Container Platform のインストール時に変更した
grub.conf
ファイルにアクセスできます。
手順
RHCOS イメージの PXE または iPXE インストールが正常に行われていることを確認します。
PXE の場合:
DEFAULT pxeboot TIMEOUT 20 PROMPT 0 LABEL pxeboot KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1 APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2
- 1
- HTTP サーバーにアップロードしたライブ
kernel
ファイルの場所を指定します。 - 2
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
initrd
パラメーターはライブinitramfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値はワーカー Ignition 設定ファイルの場所であり、coreos.live.rootfs_url
パラメーター値はライブrootfs
ファイルの場所になります。coreos.inst.ignition_url
およびcoreos.live.rootfs_url
パラメーターは HTTP および HTTPS のみをサポートします。
注記この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、
APPEND
行に 1 つ以上のconsole=
引数を追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? を参照してください。iPXE (
x86_
64 +aarch64
):kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2 initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 3 boot
- 1
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値はkernel
ファイルの場所であり、initrd=main
引数は UEFI システムでの起動に必要であり、coreos.live.rootfs_url
パラメーター値はワーカー Ignition 設定ファイルの場所であり、coreos.inst.ignition_url
パラメーター値はrootfs
のライブファイルの場所です。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- HTTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
注記この設定では、グラフィカルコンソールを備えたマシンでのシリアルコンソールアクセスは有効になりません。別のコンソールを設定するには、
kernel
行に 1 つ以上のconsole=
引数を追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。注記aarch64
アーキテクチャーで CoreOSkernel
をネットワークブートするには、IMAGE_GZIP
オプションが有効になっているバージョンの iPXE ビルドを使用する必要があります。iPXE のIMAGE_GZIP
オプション を参照してください。aarch64
上の PXE (第 2 段階として UEFI および GRUB を使用) の場合:menuentry 'Install CoreOS' { linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign 1 2 initrd rhcos-<version>-live-initramfs.<architecture>.img 3 }
- 1
- HTTP/TFTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値は、TFTP サーバー上のkernel
ファイルの場所になります。coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値は HTTP サーバー上のブートストラップ Ignition 設定ファイルの場所になります。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- TFTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
- PXE または iPXE インフラストラクチャーを使用して、クラスターに必要なコンピュートマシンを作成します。
11.4.3. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.27.3 master-1 Ready master 63m v1.27.3 master-2 Ready master 64m v1.27.3
出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
Pending
またはApproved
ステータスが表示されていることを確認します。$ oc get csr
出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ oc get csr
出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
残りの CSR が承認されず、それらが
Pending
ステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 73m v1.27.3 master-1 Ready master 73m v1.27.3 master-2 Ready master 74m v1.27.3 worker-0 Ready worker 11m v1.27.3 worker-1 Ready worker 11m v1.27.3
注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。