4.6. z/VM を使用した 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. ダウンロードした RHEL ライブ kernel、initramfs、および rootfs ファイルを、追加する z/VM ゲストからアクセスできる HTTP または HTTPS サーバーに移動します。

7. z/VM ゲストのパラメーターファイルを作成します。次のパラメーターは仮想マシンに固有です。

   • オプション: 静的 IP アドレスを指定するには、次のエントリーをコロンで区切って ip= パラメーターを追加します。

     1. マシンの IP アドレス。
     2. 空の文字列。
     3. ゲートウェイ。
     4. ネットマスク。
     5. hostname.domainname 形式のマシンホストおよびドメイン名。この値を省略して、RHCOS に決定させるようにします。
     6. ネットワークインターフェイス名。この値を省略して、RHCOS に決定させるようにします。
     7. 値 none。
   • coreos.inst.ignition_url= には、worker.ign ファイルへの URL を指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
   • coreos.live.rootfs_url= の場合、起動している kernel および initramfs の一致する rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。

   • DASD タイプのディスクへのインストールには、以下のタスクを実行します。

     1. coreos.inst.install_dev= には、/dev/dasda を指定します。
     2. rd.dasd= を使用して、RHCOS がインストールされる DASD を指定します。

     3. その他のパラメーターはすべて変更しません。

        以下はパラメーターファイルの例、additional-worker-dasd.parm です。

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/dasda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/worker.ign \
        ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.dasd=0.0.3490

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

   • FCP タイプのディスクへのインストールには、以下のタスクを実行します。

     1. rd.zfcp=<adapter>,<wwpn>,<lun> を使用して RHCOS がインストールされる FCP ディスクを指定します。マルチパスの場合、それぞれの追加のステップについてこのステップを繰り返します。

        注記

        複数のパスを使用してインストールする場合は、問題が発生する可能性があるため、後でではなくインストールの直後にマルチパスを有効にする必要があります。

     2. インストールデバイスを coreos.inst.install_dev=/dev/sda として設定します。

        注記

        追加の LUN が NPIV で設定される場合は、FCP に zfcp.allow_lun_scan=0 が必要です。CSI ドライバーを使用するために zfcp.allow_lun_scan=1 を有効にする必要がある場合などには、各ノードが別のノードのブートパーティションにアクセスできないように NPIV を設定する必要があります。

     3. その他のパラメーターはすべて変更しません。

        重要

        マルチパスを完全に有効にするには、インストール後の追加の手順が必要です。詳細は、インストール後のマシン設定タスク の “RHCOS でのカーネル引数を使用したマルチパスの有効化“ を参照してください。

        以下は、マルチパスを使用するワーカーノードのパラメーターファイルの例 additional-worker-fcp.parm です。

        rd.neednet=1 \
        console=ttysclp0 \
        coreos.inst.install_dev=/dev/sda \
        coreos.live.rootfs_url=http://cl1.provide.example.com:8080/assets/rhcos-live-rootfs.s390x.img \
        coreos.inst.ignition_url=http://cl1.provide.example.com:8080/ignition/worker.ign \
        ip=172.18.78.2::172.18.78.1:255.255.255.0:::none nameserver=172.18.78.1 \
        rd.znet=qeth,0.0.bdf0,0.0.bdf1,0.0.bdf2,layer2=1,portno=0 \
        zfcp.allow_lun_scan=0 \
        rd.zfcp=0.0.1987,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763070bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.1987,0x50050763071bc5e3,0x4008400B00000000 \
        rd.zfcp=0.0.19C7,0x50050763071bc5e3,0x4008400B00000000

        パラメーターファイルのすべてのオプションを 1 行で記述し、改行文字がないことを確認します。

8. FTP などを使用し、initramfs、kernel、パラメーターファイル、および RHCOS イメージを z/VM に転送します。FTP でファイルを転送し、仮想リーダーから起動する方法は、Z/VM 環境へのインストール を参照してください。

9. ファイルを z/VM ゲスト仮想マシンの仮想リーダーに punch します。

   IBM® ドキュメントの PUNCH を参照してください。

   ヒント

   CP PUNCH コマンドを使用するか、Linux を使用している場合は、vmur コマンドを使用して 2 つの z/VM ゲスト仮想マシン間でファイルを転送できます。

10. ブートストラップマシンで CMS にログインします。

11. 次のコマンドを実行して、リーダーからブートストラップマシンを IPL します。

    $ ipl c

    IBM® ドキュメントの IPL を参照してください。

手順

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 ステータスに移行するまでに数分の時間がかかる場合があります。