4.5. IBM Z への Hosted Control Plane のデプロイ


クラスターを管理クラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。管理クラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。管理クラスターは ホスティング クラスターとも呼ばれます。

注記

管理 クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。管理 クラスターは、OpenShift Container Platform 4.17 以降および multicluster engine for Kubernetes Operator 2.7 以降でサポートされる x86_64 アーキテクチャー、または OpenShift Container Platform 4.20 以降および multicluster engine for Kubernetes Operator 2.10 以降でサポートされる s390x アーキテクチャーのいずれかで実行できます。

hypershift アドオンを使用してマネージドクラスターに HyperShift Operator をデプロイすることにより、そのマネージドクラスターを管理クラスターに変換できます。その後、ホステッドクラスターの作成を開始できます。

multicluster engine Operator は、マネージドのハブクラスターであるデフォルトの local-cluster と、管理クラスターとしてのハブクラスターのみをサポートしています。

ベアメタルに Hosted Control Plane をプロビジョニングするには、Agent プラットフォームを使用できます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。詳細は、「Central Infrastructure Management サービスの有効化」を参照してください。

各 IBM Z システムホストは、中央インフラストラクチャー管理によって提供される PXE または ISO イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。

Agent プラットフォームでホステッドクラスターを作成すると、HyperShift Operator は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。

4.5.1. IBM Z で Hosted Control Plane を設定するための前提条件

  • multicluster engine for Kubernetes Operator version 2.7 以降を OpenShift Container Platform クラスターにインストールする必要があります。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。
  • multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。multicluster engine Operator バージョン 2.7 以降では、local-cluster が自動的にインポートされます。local-cluster の詳細は、Red Hat Advanced Cluster Management ドキュメントの 詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • HyperShift Operator を実行するために 3 つ以上のワーカーノードを含むホスティングクラスターがある。
  • Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • Hosted Control Plane のコマンドラインインターフェイスをインストールする必要があります。詳細は、Hosted Control Plane のコマンドラインインターフェイスのインストール を参照してください。
注記

管理 クラスターは、OpenShift Container Platform 4.17 以降および multicluster engine for Kubernetes Operator 2.7 以降でサポートされる x86_64 アーキテクチャー、または OpenShift Container Platform 4.20 以降および multicluster engine for Kubernetes Operator 2.10 以降でサポートされる s390x アーキテクチャーのいずれかで実行できます。

4.5.2. IBM Z のインフラストラクチャー要件

Agent プラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャー用の次のリソースを必要とします。

  • Agents: Agent は Discovery イメージまたは PXE イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

Hosted Control Plane 機能はデフォルトで有効になっています。この機能を以前に無効にしていて手動で有効にする場合、またはこの機能を無効にする必要がある場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。

4.5.3. IBM Z での Hosted Control Plane の DNS 設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> の DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。

エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

次の DNS 設定の例を参照してください。

$ cat /var/named/<example.krnl.es.zone>
Copy to Clipboard Toggle word wrap

出力例

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx 
1

api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps        IN A 1xx.2x.2xx.1xx
;
;EOF
Copy to Clipboard Toggle word wrap

1
このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。

IBM z/VM の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy
Copy to Clipboard Toggle word wrap

4.5.3.1. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため。
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfig と DNS 設定を使用して、Show Login Command などの機能を使用可能にするため。

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
  • 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。

4.5.4. IBM Z 用のベアメタル上にホステッドクラスターを作成する

ホステッドクラスターの作成やインポートが可能です。Assisted Installer が multicluster engine Operator へのアドオンとして有効になっている場合に、エージェントプラットフォームでホステッドクラスターを作成すると、HyperShift Operator によって Agent Cluster API プロバイダーが Hosted Control Plane namespace にインストールされます。

4.5.4.1. IBM Z 用のベアメタル上にホステッドクラスターを作成する

ベアメタルインフラストラクチャーには、ホステッドクラスターを作成またはインポートできます。multicluster engine Operator へのアドオンとして Assisted Installer を有効にし、Agent プラットフォームを使用してホステッドクラスターを作成すると、HyperShift Operator によって Agent Cluster API プロバイダーが Hosted Control Plane namespace にインストールされます。Agent Cluster API プロバイダーは、コントロールプレーンをホストする管理クラスターと、コンピュートノードのみで構成されるホステッドクラスターを接続します。

前提条件

  • 各ホステッドクラスターの名前がクラスター全体で一意である。ホステッドクラスター名は、既存のマネージドクラスターと同じにすることはできません。この要件を満たさないと、multicluster engine Operator がホステッドクラスターを管理できません。
  • ホステッドクラスター名として clusters という単語を使用しない。
  • multicluster engine Operator のマネージドクラスターの namespace にホステッドクラスターを作成することはできない。
  • 最適なセキュリティーと管理プラクティスを実現するために、他のホステッドクラスターとは別にホステッドクラスターを作成する。
  • クラスターにデフォルトのストレージクラスが設定されていることを確認する。そうしない場合、保留中の永続ボリューム要求 (PVC) が表示されることがあります。

手順

  1. 次のコマンドを入力して namespace を作成します。

    $ oc create ns <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    <hosted_cluster_namespace> は、ホステッドクラスター namespace の識別子に置き換えます。namespace は HyperShift Operator によって作成されます。ベアメタルインフラストラクチャーにホステッドクラスターを作成するプロセスでは、Cluster API プロバイダー用のロールが生成されます。このロールを生成するには、namespace が事前に存在している必要があります。

  2. 次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。

    $ hcp create cluster agent \
      --name=<hosted_cluster_name> \
    1
    
      --pull-secret=<path_to_pull_secret> \
    2
    
      --agent-namespace=<hosted_control_plane_namespace> \
    3
    
      --base-domain=<base_domain> \
    4
    
      --api-server-address=api.<hosted_cluster_name>.<base_domain> \
    5
    
      --etcd-storage-class=<etcd_storage_class> \
    6
    
      --ssh-key=<path_to_ssh_key> \
    7
    
      --namespace=<hosted_cluster_namespace> \
    8
    
      --control-plane-availability-policy=HighlyAvailable \
    9
    
      --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>-multi \
    10
    
      --node-pool-replicas=<node_pool_replica_count> \
    11
    
      --render \
      --render-sensitive \
      --ssh-key <home_directory>/<path_to_ssh_key>/<ssh_key> > hosted-cluster-config.yaml 
    12
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: example) を指定します。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane の namespace を指定します (例: clusters-example)。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメイン (例: krnl.es) を指定します。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplicaHighlyAvailable です。デフォルト値は HighlyAvailable です。
    10
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
    11
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。この値を指定しない場合、ノードプールは作成されません。
    12
    --ssh-key フラグの後に、SSH 鍵へのパス (例: user/.ssh/id_rsa) を指定します。
  3. 次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。

    $ oc apply -f hosted_cluster_config.yaml
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。

    $ oc get hostedcluster \
      <hosted_cluster_name> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get hostedcluster \
      <nodepool_name> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get pods -n <hosted_control_plane_namespace>
    Copy to Clipboard Toggle word wrap
  5. ホステッドクラスターの準備ができていることを確認します。Available: True ステータスは、コントロールプレーンの準備状況を示します。

4.5.5. IBM Z 上の Hosted Control Plane 用の InfraEnv リソースを作成する

InfraEnv は、PXE イメージを使用して起動されるホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。

手順

  1. 設定を含む YAML ファイルを作成します。以下の例を参照してください。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>
      namespace: <hosted_control_plane_namespace>
    spec:
      cpuArchitecture: s390x
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_public_key>
    Copy to Clipboard Toggle word wrap
  2. ファイルを infraenv-config.yaml として保存します。
  3. 次のコマンドを入力して設定を適用します。

    $ oc apply -f infraenv-config.yaml
    Copy to Clipboard Toggle word wrap
  4. initrd.imgkernel.img、または rootfs.img などの PXE または ISO イメージをダウンロードする URL を取得するには、次のコマンドを入力します。このイメージは、IBM Z マシンがエージェントとして参加できるようにします。

    $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
    Copy to Clipboard Toggle word wrap

4.5.6. InfraEnv リソースへの IBM Z エージェントの追加

Hosted Control Plane にコンピュートノードをアタッチするには、ノードプールのスケーリングに役立つエージェントを作成します。IBM Z 環境にエージェントを追加するには、追加の手順が必要です。これは、このセクションで詳しく説明します。

特に明記されていない限り、以下の手順は IBM Z および IBM LinuxONE 上の z/VM と RHEL KVM の両方のインストールに適用されます。

4.5.6.1. IBM Z KVM をエージェントとして追加する

KVM を使用する IBM Z の場合は、次のコマンドを実行して、InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。

手順

  1. 以下のコマンドを実行します。

    virt-install \
       --name "<vm_name>" \ 
    1
    
       --autostart \
       --ram=16384 \
       --cpu host \
       --vcpus=4 \
       --location "<path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img" \ 
    2
    
       --disk <qcow_image_path> \ 
    3
    
       --network network:macvtap-net,mac=<mac_address> \ 
    4
    
       --graphics none \
       --noautoconsole \
       --wait=-1
       --extra-args "rd.neednet=1 nameserver=<nameserver>   coreos.live.rootfs_url=http://<http_server>/rootfs.img random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs=console=tty1 console=ttyS1,115200n8" 
    5
    Copy to Clipboard Toggle word wrap
    1
    仮想マシンの名前を指定します。
    2
    kernel_initrd_image ファイルの場所を指定します。
    3
    ディスクイメージのパスを指定します。
    4
    Mac アドレスを指定します。
    5
    エージェントのサーバー名を指定します。
  2. ISO ブートの場合は、InfraEnv リソースから ISO をダウンロードし、次のコマンドを実行してノードを起動します。

    virt-install \
      --name "<vm_name>" \ 
    1
    
      --autostart \
      --memory=16384 \
      --cpu host \
      --vcpus=4 \
      --network network:macvtap-net,mac=<mac_address> \ 
    2
    
      --cdrom "<path_to_image.iso>" \ 
    3
    
      --disk <qcow_image_path> \
      --graphics none \
      --noautoconsole \
      --os-variant <os_version> \ 
    4
    
      --wait=-1
    Copy to Clipboard Toggle word wrap
    1
    仮想マシンの名前を指定します。
    2
    Mac アドレスを指定します。
    3
    image.iso ファイルの場所を指定します。
    4
    使用しているオペレーティングシステムのバージョンを指定します。

4.5.6.2. IBM Z LPAR をエージェントとして追加する

IBM Z または IBM LinuxONE 上の論理パーティション (LPAR) をコンピュートノードとして Hosted Control Plane に追加できます。

手順

  1. エージェントのブートパラメーターファイルを作成します。

    パラメーターファイルの例

    rd.neednet=1 cio_ignore=all,!condev \
    console=ttysclp0 \
    ignition.firstboot ignition.platform.id=metal
    coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
    1
    
    coreos.inst.persistent-kargs=console=ttysclp0
    ip=<ip>::<gateway>:<netmask>::<interface>:none nameserver=<dns> \
    2
    
    rd.znet=qeth,<network_adaptor_range>,layer2=1
    rd.<disk_type>=<adapter> \
    3
    
    zfcp.allow_lun_scan=0
    ai.ip_cfg_override=1 \
    4
    
    random.trust_cpu=on rd.luks.options=discard
    Copy to Clipboard Toggle word wrap

    1
    coreos.live.rootfs_url アーティファクトには、起動する kernelinitramfs に合った rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    2
    ip パラメーターには、z/VM を使用したクラスターの IBM Z および IBM LinuxONE へのインストール の説明に従って、IP アドレスを手動で割り当てます。
    3
    DASD タイプのディスクにインストールする場合は、rd.dasd を使用して、Red Hat Enterprise Linux CoreOS (RHCOS) をインストールする DASD を指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp=<adapter>,<wwpn>,<lun> を使用して、RHCOS がインストールされる FCP ディスクを指定します。
    4
    Open Systems Adapter (OSA) または HiperSockets を使用する場合は、このパラメーターを指定します。
  2. InfraEnv リソースから .ins ファイルと initrd.img.addrsize ファイルをダウンロードします。

    デフォルトでは、.ins ファイルと initrd.img.addrsize ファイルの URL は、InfraEnv リソースにはありません。これらのアーティファクトを取得するには、URL を編集する必要があります。

    1. 次のコマンドを実行して、カーネル URL エンドポイントを更新し、ins-file を含めます。

      $ curl -k -L -o generic.ins "< url for ins-file >"
      Copy to Clipboard Toggle word wrap

      URL の例

      https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0
      Copy to Clipboard Toggle word wrap

    2. initrd URL エンドポイントを更新し、s390x-initrd-addrsize を含めます。

      URL の例

      https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0
      Copy to Clipboard Toggle word wrap

  3. initrdkernelgeneric.ins、および initrd.img.addrsize パラメーターファイルをファイルサーバーに転送します。FTP を使用してファイルを転送し、ブートする方法の詳細は、「LPAR へのインストール」を参照してください。
  4. マシンを起動します。
  5. クラスター内の他のマシンすべてに対してこの手順を繰り返します。

4.5.6.3. IBM z/VM をエージェントとして追加する

z/VM ゲストに静的 IP を使用する場合は、IP パラメーターが 2 回目の起動でも持続するように、z/VM エージェントの NMStateConfig 属性を設定する必要があります。

InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始するには、以下の手順を実行します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。

手順

  1. パラメーターファイルを更新して、rootfs_urlnetwork_adaptor、および disk_type の値を追加します。

    パラメーターファイルの例

    rd.neednet=1 cio_ignore=all,!condev \
    console=ttysclp0  \
    ignition.firstboot ignition.platform.id=metal \
    coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
    1
    
    coreos.inst.persistent-kargs=console=ttysclp0
    ip=<ip>::<gateway>:<netmask>::<interface>:none nameserver=<dns> \
    2
    
    rd.znet=qeth,<network_adaptor_range>,layer2=1
    rd.<disk_type>=<adapter> \
    3
    
    zfcp.allow_lun_scan=0
    ai.ip_cfg_override=1 \
    4
    Copy to Clipboard Toggle word wrap

    1
    coreos.live.rootfs_url アーティファクトには、起動する kernelinitramfs に合った rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    2
    ip パラメーターには、z/VM を使用したクラスターの IBM Z および IBM LinuxONE へのインストール の説明に従って、IP アドレスを手動で割り当てます。
    3
    DASD タイプのディスクにインストールする場合は、rd.dasd を使用して、Red Hat Enterprise Linux CoreOS (RHCOS) をインストールする DASD を指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp=<adapter>,<wwpn>,<lun> を使用して、RHCOS がインストールされる FCP ディスクを指定します。
    注記

    FCP マルチパス設定の場合、1 つのディスクではなく 2 つのディスクを用意します。

    rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
    rd.zfcp=<adapter2>,<wwpn2>,<lun2>
    Copy to Clipboard Toggle word wrap

    4
    Open Systems Adapter (OSA) または HiperSockets を使用する場合は、このパラメーターを指定します。
  2. 次のコマンドを実行して、initrd、カーネルイメージ、およびパラメーターファイルをゲスト VM に移動します。

    vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
    Copy to Clipboard Toggle word wrap
    vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
    Copy to Clipboard Toggle word wrap
    vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
    Copy to Clipboard Toggle word wrap
  3. ゲスト VM コンソールから次のコマンドを実行します。

    cp ipl c
    Copy to Clipboard Toggle word wrap
  4. エージェントとそのプロパティーをリスト表示するには、次のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME    CLUSTER APPROVED    ROLE    STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行してエージェントを承認します。

    $ oc -n <hosted_control_plane_namespace> patch agent \
      50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p \
      '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' \
    1
    
      --type merge
    Copy to Clipboard Toggle word wrap
    1
    必要に応じて、仕様でエージェント ID <installation_disk_id><hostname> を設定できます。
  6. 次のコマンドを実行して、エージェントが承認されていることを確認します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                            CLUSTER     APPROVED   ROLE          STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d             true       auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a             true       auto-assign
    Copy to Clipboard Toggle word wrap

4.5.7. IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング

NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。

ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。

手順

  1. 次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。

    $ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster
  2. 次のコマンドを実行して、スケールされた特定のエージェントのステータスを確認します。

    $ oc -n <hosted_control_plane_namespace> get agent -o \
      jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} \
      Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    出力例

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
    BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、移行フェーズを表示します。

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER           APPROVED       ROLE        STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true          auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a                      true          auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-assign
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。

    $ hcp create kubeconfig \
      --namespace <clusters_namespace> \
      --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap
  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             STATUS   ROLES    AGE      VERSION
    worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
    worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

    Cluster Operator は、ワークロードをノードに追加することによってリコンシリエーションを開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

    $ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                CLUSTER  NODENAME PROVIDERID     PHASE     AGE   VERSION
    hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.15.0
    hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを実行して、クラスターのバージョンを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version   4.15.0-ec.2   True        False         40h     Cluster version is 4.15.0-ec.2
    Copy to Clipboard Toggle word wrap

  8. 以下のコマンドを実行して、クラスター Operator のステータスを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
    Copy to Clipboard Toggle word wrap

クラスターの各コンポーネントの出力には、NAMEVERSIONAVAILABLEPROGRESSINGDEGRADEDSINCE、および MESSAGE のクラスター Operator のステータスが表示されます。

出力例は、Operator の初期設定 参照してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat