4.7. RHEL KVM を使用した IBM Z および IBM LinuxONE 上でマルチアーキテクチャーのコンピュートマシンを含むクラスターを作成する

検証

1. 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用しています。

   {
    "release.openshift.io/architecture": "multi",
    "url": "https://access.redhat.com/errata/<errata_version>"
   }

   その後、クラスターへのマルチアーキテクチャーコンピュートノードの追加を開始できます。

2. 次の出力が表示された場合、クラスターはマルチアーキテクチャーペイロードを使用していません。

   {
    "url": "https://access.redhat.com/errata/<errata_version>"
   }

   重要

   クラスターを、マルチアーキテクチャーコンピュートマシンをサポートするクラスターに移行するには、マルチアーキテクチャーコンピュートマシンを含むクラスターへの移行 の手順に従ってください。

手順

1. UDP アグリゲーションを無効にします。

   現在、UDP アグリゲーションは IBM Z® ではサポートされておらず、x86_64 コントロールプレーンと追加の s390x コンピュートマシンを備えたマルチアーキテクチャーコンピュートクラスターでは自動的に非アクティブ化されません。追加のコンピュートノードがクラスターに正しく追加されるようにするには、UDP アグリゲーションを手動で無効にする必要があります。

   1. 次の内容を含む YAML ファイル udp-aggregation-config.yaml を作成します。

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator

   2. 次のコマンドを実行して、ConfigMap リソースを作成します。

      $ oc create -f udp-aggregation-config.yaml

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

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

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

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

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

5. 次のコマンドを実行して、RHEL ライブ kernel、initramfs、および rootfs ファイルをダウンロードします。

    $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')

   $ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \
   | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')

6. virt-install を起動する前に、ダウンロードした RHEL ライブの kernel ファイル、initramfs ファイル、および rootfs ファイルを HTTP または HTTPS サーバーに移動します。

7. RHEL kernel、initramfs、および Ignition ファイル、新規ディスクイメージ、および調整された parm 引数を使用して、新規 KVM ゲストノードを作成します。

   $ virt-install \
      --connect qemu:///system \
      --name <vm_name> \
      --autostart \
      --os-variant rhel9.2 \ 1
      --cpu host \
      --vcpus <vcpus> \
      --memory <memory_mb> \
      --disk <vm_name>.qcow2,size=<image_size> \
      --network network=<virt_network_parm> \
      --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \ 2
      --extra-args "rd.neednet=1" \
      --extra-args "coreos.inst.install_dev=/dev/vda" \
      --extra-args "coreos.inst.ignition_url=<worker_ign>" \ 3
      --extra-args "coreos.live.rootfs_url=<rhcos_rootfs>" \ 4
      --extra-args "ip=<ip>::<default_gateway>:<subnet_mask_length>:<hostname>::none:<MTU>" \ 5
      --extra-args "nameserver=<dns>" \
      --extra-args "console=ttysclp0" \
      --noautoconsole \
      --wait

   1

   os-variant には、RHCOS コンピュートマシンの RHEL バージョンを指定します。rhel9.2 が推奨バージョンです。オペレーティングシステムのサポートされている RHEL バージョンを照会するには、次のコマンドを実行します。

   $ osinfo-query os -f short-id

   注記

   os-variant では大文字と小文字が区別されます。

   2

   --location には、HTTP サーバーまたは HTTPS サーバーのカーネル/initrd の場所を指定します。

   3

   coreos.inst.ignition_url= には、マシンロールの worker.ign Ignition ファイルを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

   4

   coreos.live.rootfs_url= の場合、起動している kernel および initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

   5

   オプション: hostname には、クライアントマシンの完全修飾ホスト名を指定します。

   注記

   HAProxy をロードバランサーとして使用している場合は、/etc/haproxy/haproxy.cfg 設定ファイル内の ingress-router-443 および ingress-router-80 の HAProxy ルールを更新します。

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

手順

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

   $ 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 が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

2. 保留中の証明書署名要求 (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 が表示される可能性があります。

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 サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

   • それらを個別に承認するには、それぞれの有効な 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 が承認されるまで利用できない可能性があります。

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

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

5. 残りの 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

6. すべてのクライアントおよびサーバーの 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 ステータスに移行するまでに数分の時間がかかる場合があります。