4.4. ベアメタル上でマルチアーキテクチャーコンピューティングマシンを使用したクラスターを作成する (テクノロジープレビュー)

手順

1. 次のコマンドを実行して、クラスターから Ignition 設定ファイルを抽出します。

   $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign

   Copy to Clipboard Toggle word wrap
2. クラスターからエクスポートした worker.ign Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。

3. Ignition ファイルが URL で利用可能であることを検証できます。次の例では、コンピュートノードの Ignition 設定ファイルを取得します。

   $ curl -k http://<HTTP_server>/worker.ign

   Copy to Clipboard Toggle word wrap

4. 次のコマンドを実行すると、新しいマシンを起動するための 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')

   Copy to Clipboard Toggle word wrap

5. ISO ファイルを使用して、追加のコンピュートマシンに RHCOS をインストールします。クラスターのインストール前にマシンを作成する際に使用したのと同じ方法を使用します。

   • ディスクに ISO イメージを書き込み、これを直接起動します。
   • LOM インターフェイスで ISO リダイレクトを使用します。

6. オプションを指定したり、ライブ起動シーケンスを中断したりせずに、RHCOS ISO イメージを起動します。インストーラーが RHCOS ライブ環境でシェルプロンプトを起動するのを待ちます。

   注記

   RHCOS インストールの起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに、次の手順で概説するように coreos-installer コマンドを使用する必要があります。

7. coreos-installer コマンドを実行し、インストール要件を満たすオプションを指定します。少なくとも、ノードタイプの Ignition 設定ファイルを参照する URL と、インストール先のデバイスを指定する必要があります。

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 

   1

   2

   Copy to Clipboard Toggle word wrap

   1

   コア ユーザーにはインストールを実行するために必要な root 権限がないため、sudo を使用して coreos-installer コマンドを実行する必要があります。

   2

   --ignition-hash オプションは、Ignition 設定ファイルを HTTP URL を使用して取得し、クラスターノードの Ignition 設定ファイルの信頼性を検証するために必要です。<digest> は、先の手順で取得した Ignition 設定ファイル SHA512 ダイジェストです。

   注記

   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

   Copy to Clipboard Toggle word wrap

8. マシンのコンソールで RHCOS インストールの進捗を監視します。

   重要

   OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。

9. 継続してクラスター用の追加のコンピュートマシンを作成します。

手順

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

     Copy to Clipboard Toggle word wrap

     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

     Copy to Clipboard Toggle word wrap

     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 アーキテクチャーで CoreOS kernel をネットワークブートするには、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

     
     }

     Copy to Clipboard Toggle word wrap

     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 ファイルの場所を指定します。

2. PXE または iPXE インフラストラクチャーを使用して、クラスターに必要なコンピュートマシンを作成します。

手順

1. クラスターがマシンを認識していることを確認します。

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.26.0
   master-1  Ready     master  63m  v1.26.0
   master-2  Ready     master  64m  v1.26.0

   Copy to Clipboard Toggle word wrap

   出力には作成したすべてのマシンがリスト表示されます。

   注記

   上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

   $ oc get csr

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

   この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

3. 追加したマシンの保留中の 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 サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。

   • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 

     1

     Copy to Clipboard Toggle word wrap

     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

     Copy to Clipboard Toggle word wrap
     注記

     一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 

     1

     Copy to Clipboard Toggle word wrap

     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

     Copy to Clipboard Toggle word wrap

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.26.0
   master-1  Ready     master  73m  v1.26.0
   master-2  Ready     master  74m  v1.26.0
   worker-0  Ready     worker  11m  v1.26.0
   worker-1  Ready     worker  11m  v1.26.0

   Copy to Clipboard Toggle word wrap

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。