OpenShift Container Platform の Assisted Installer

手順

1. Red Hat Hybrid Cloud Console にログインします。
2. Red Hat OpenShift タイルで、Scale your applications をクリックします。
3. メニューで、Clusters をクリックします。
4. Create cluster をクリックします。
5. Datacenter タブをクリックします。
6. Assisted Installer で、Create cluster をクリックします。
7. Cluster Name フィールドにクラスターの名前を入力します。

8. Base domain フィールドに、クラスターのベースドメインを入力します。クラスターのすべてのサブドメインは、この基本ドメインを使用します。

   注記

   ベースドメインは有効な DNS 名である必要があります。ベースドメインにワイルドカードドメインをセットアップしないでください。

9. インストールする OpenShift Container Platform のバージョンを選択します。

   重要
   • IBM Power および IBM zSystems プラットフォームの場合、OpenShift Container Platform バージョン 4.13 以降のみがサポートされます。
   • 混合アーキテクチャーのクラスターのインストールの場合は、OpenShift Container Platform バージョン 4.12 以降を選択し、-multi オプションを使用します。混合アーキテクチャーのクラスターのインストール手順は、関連情報 を参照し てください。

10. オプション: OpenShift Container Platform を単一のノードにインストールする場合は、Install single node Openshift (SNO) を選択します。

    注記

    現在、SNO は IBM zSystems および IBM Power プラットフォームではサポートされていません。

11. オプション: Assisted Installer には、アカウントに関連付けられたプルシークレットがすでにあります。別のプルシークレットを使用する場合は、Edit pull secret を選択します。

12. オプション：OpenShift Container Platform をサードパーティーのプラットフォームにインストールする場合は、Integrate with external parter platforms リストからプラットフォームを選択します。有効な値は Nutanix、vSphere、または Oracle Cloud Infrastructure です。アシステッドインストーラーはデフォルトで、プラットフォームの統合はありません。

    注記

    各外部パートナーインテグレーションの詳細は、関連情報を参照し てください。

    重要

    Assisted Installer は、OpenShift Container Platform 4.14 以降からの Oracle Cloud Infrastructure (OCI)統合をサポートします。OpenShift Container Platform 4.14 の場合、OCI 統合はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

    Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

13. オプション: Assisted Installer は、デフォルトで x86_64 CPU アーキテクチャーを使用します。OpenShift Container Platform を別のアーキテクチャーにインストールする場合は、使用するそれぞれのアーキテクチャーを選択します。有効な値は、arm64、ppc64le、および s390x です。一部の機能は、arm64、ppc64le、および s390x CPU アーキテクチャーでは利用できないことに注意してください。

    重要

    混合アーキテクチャーのクラスターのインストールには、デフォルトの x86_64 アーキテクチャーを使用します。混合アーキテクチャーのクラスターのインストール手順は、関連情報 を参照し てください。

14. オプション: Assisted Installer はデフォルトで DHCP ネットワークに設定されます。DHCP 予約の代わりにクラスターノードに静的 IP 設定、ブリッジ、または結合を使用している場合は、静的 IP、ブリッジ、および結合 を 選択します。

    注記

    静的 IP 設定は、Oracle Cloud Infrastructure (OCI)上の OpenShift Container Platform インストールではサポートされていません。

15. オプション: インストールディスクの暗号化を有効にする場合は、インストールディスクの 暗号化を有効に するで、単一ノード OpenShift の コントロールプレーンノード、ワーカー を選択できます。マルチノードクラスターの場合、コントロールプレーンノード を選択してコントロールプレーンノードのインストールディスクを暗号化し、ワーカー を選択してワーカーノードのインストールディスクを暗号化できます。

手順

1. インターネットプロトコルのバージョンを選択します。有効なオプションは IPv4 と Dual stack です。
2. クラスターホストが共有 VLAN 上にある場合は、VLAN ID を入力します。

3. ネットワーク全体の IP アドレスを入力します。Dual stack ネットワークを選択した場合は、IPv4 と IPv6 の両方のアドレスを入力する必要があります。

   1. クラスターネットワークの IP アドレス範囲を CIDR 表記で入力します。
   2. デフォルトゲートウェイの IP アドレスを入力します。
   3. DNS サーバーの IP アドレスを入力します。

4. ホスト固有の設定を入力します。

   1. 単一のネットワークインターフェイスを使用する静的 IP アドレスのみを設定する場合は、フォームビューを使用して、各ホストの IP アドレスと MAC アドレスを入力します。
   2. 複数のインターフェイス、ボンディング、またはその他の高度なネットワーク機能を使用している場合は、YAML ビューを使用し、NMState 構文を使用して各ホストに必要なネットワーク状態を入力します。次に、ネットワーク設定で使用される各ホストインターフェイスの MAC アドレスとインターフェイス名を追加します。

手順

1. OpenShift Virtualization をインストールするには、Install OpenShift Virtualization を選択します。
2. Multicluster Engine (MCE) をインストールするには、Install multicluster engine を選択します。
3. OpenShift Data Foundation をインストールするには、Install OpenShift Data Foundation を選択します。
4. 論理ボリュームマネージャーをインストールするには、Install Logical Volume Manager を選択します。
5. Next をクリックして、次の手順に進みます。

手順

1. Add hosts ボタンをクリックし、プロビジョニングタイプを選択します。

   1. Minimal image file: Provision with virtual media を選択して、起動に必要なデータを取得する小さなイメージをダウンロードします。ノードには仮想メディア機能が必要です。これは、x86_64 および arm64 アーキテクチャーで推奨される方法です。
   2. Full image file: Provision with physical media を選択して、より大きなフルイメージをダウンロードします。これは、RHEL KVM を使用してインストールする場合、ppc64le アーキテクチャーおよび s390x アーキテクチャーで推奨される方法です。

   3. iPXE: Provision from your network server を選択して、iPXE を使用してホストを起動します。

      注記
      • iPXE を使用して RHEL KVM にインストールする場合、KVM ホスト上の VM が初回起動時に再起動されず、手動での起動が必要になることがあります。
      • OpenShift Container Platform を Oracle Cloud Infrastructure にインストールする場合は、Minimal image file: Provision with virtual media only を選択します。
2. オプション: クラスターホストがプロキシーの使用を必要とするファイアウォールの内側にある場合は、Configure cluster-wide proxy settings を選択します。プロキシーサーバーの HTTP および HTTPS URL のユーザー名、パスワード、IP アドレス、およびポートを入力します。

3. core ユーザーとしてクラスターノードに接続できるように、SSH 公開キーを追加します。クラスターノードにログインすると、インストール中にデバッグ情報を入手できます。

   重要

   障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

   1. ローカルマシンに既存の SSH キーペアがない場合は、クラスターノード SSH アクセス用のキーペアの生成 の手順に従います。
   2. SSH public key フィールドで Browse をクリックして、SSH 公開鍵を含む id_rsa.pub ファイルをアップロードします。または、ファイルマネージャーからフィールドにファイルをドラッグアンドドロップします。ファイルマネージャーでファイルを表示するには、メニューで 非表示ファイル を表示を選択します。
4. オプション: クラスターホストが再暗号化中間者 (MITM) プロキシーを使用するネットワーク内にある場合、またはクラスターがコンテナーイメージレジストリーなどの他の目的で証明書を信頼する必要がある場合は、Configure cluster-wide trusted certificates を選択します。X.509 形式で追加の証明書を追加します。
5. 必要に応じて検出イメージを設定します。
6. オプション: 仮想化プラットフォームにインストールし、プラットフォームと統合する場合は、Integrate with platform を選択します。すべてのホストを起動し、それらがホストインベントリーに表示されることを確認する必要があります。すべてのホストが同じプラットフォーム上にある必要があります。
7. Generate Discovery ISO または Generate Script File をクリックします。
8. 検出 ISO または iPXE スクリプトをダウンロードします。
9. 検出イメージまたは iPXE スクリプトを使用してホストを起動します。

手順

1. ホストの Options (⋮) メニューから ホスト名の Change hostname を選択します。必要に応じて、ホストの新しい名前を入力し、Change をクリックします。各ホストに有効で一意のホスト名があることを確認する必要があります。

   または、Actions リストから Change hostname を選択して、複数の選択したホストの名前を変更します。Change Hostname ダイアログで新しい名前を入力し、{{n}} を含めて各ホスト名を一意にします。次に、Change をクリックします。

   注記

   入力すると、Preview ペインに新しい名前が表示されます。名前は、ホストごとに 1 桁ずつ増加する点を除き、選択したすべてのホストで同一になります。

2. Options (⋮) メニューから、Delete host を選択してホストを削除できます。Delete をクリックして削除を確定します。

   または、Actions リストから Delete を選択して、選択した複数のホストを同時に削除します。次に、Delete hosts をクリックします。

   注記

   通常のデプロイメントでは、クラスターには 3 つ以上のホストを含めることができ、これら 3 つはコントロールプレーンホストである必要があります。コントロールプレーンでもあるホストを削除した場合、またはホストが 2 つだけ残った場合は、システムの準備ができていないことを示すメッセージが表示されます。ホストを復元するには、検出 ISO からホストを再起動する必要があります。

3. ホストの オプション (⋮) メニューから、必要に応じて View host events を選択します。リスト内のイベントは時系列に表示されます。

4. マルチホストクラスターの場合、ホスト名の横にある Role 列で、メニューをクリックしてホストのロールを変更できます。

   ロールを選択しない場合、Assisted Installer がロールを自動的に割り当てます。コントロールプレーンノードの最小ハードウェア要件は、ワーカーノードの要件を超えています。ホストにロールを割り当てる場合は、ハードウェアの最小要件を満たすホストにコントロールプレーンのロールを割り当てるようにしてください。

5. Status リンクをクリックして、ホストのハードウェア、ネットワーク、および Operator の検証を表示します。
6. ホスト名の左側にある矢印をクリックして、ホストの詳細を展開します。

手順

1. ホスト名の横にあるチェックボックスの左側をクリックし、そのホストのストレージディスクを表示します。
2. ホストに複数のストレージディスクがある場合は、別のディスクを選択してインストールディスクとして機能させることができます。ディスクの Role ドロップダウンリストをクリックし、Installation disk を選択します。以前のインストールディスクのロールは None に変わります。
3. CDROM などの読み取り専用ディスクを除くすべてのブート可能ディスクは、デフォルトでインストール中に再フォーマットするようにマークされます。Format チェックボックスの選択を解除して、ディスクが再フォーマットされないようにします。インストールディスクは、再フォーマットする必要があります。機密データをバックアップしてから次に進んでください。

手順

1. Networking ページで、まだ選択されていない場合は、次のいずれかを選択します。

   • クラスター管理ネットワーク: クラスター管理ネットワークを選択すると、Assisted Installer は、API および Ingress VIP アドレスを管理するための keepalived および Virtual Router Redundancy Protocol (VRRP) を含む標準ネットワークトポロジーを設定することを意味します。

     注記
     • 現在、クラスター管理ネットワークは、OpenShift Container Platform バージョン 4.13 の IBM zSystems および IBM Power ではサポートされていません。
     • Oracle Cloud Infrastructure (OCI)は、ユーザー管理のネットワーク設定を備えた OpenShift Container Platform 4.14 でのみ利用できます。
   • User-Managed Networking: ユーザー管理のネットワークを選択すると、OpenShift Container Platform を非標準のネットワークトポロジーでデプロイできます。たとえば、keepalived や VRRP の代わりに外部ロードバランサーを使用してデプロイする場合や、多数の異なる L2 ネットワークセグメントにクラスターノードをデプロイする場合などです。

2. クラスター管理ネットワークの場合は、以下の設定を設定します。

   1. マシンネットワーク を定義します。デフォルトのネットワークを使用するか、サブネットを選択できます。
   2. API 仮想 IP を定義します。API 仮想 IP は、すべてのユーザーが対話し、プラットフォームを設定するためのエンドポイントを提供します。
   3. Ingress 仮想 IP を定義します。Ingress 仮想 IP は、クラスターの外部から流れるアプリケーショントラフィックのエンドポイントを提供します。

3. ユーザー管理のネットワークの場合は、次の設定を設定します。

   1. Networking stack type を選択します。

      • IPv4 : ホストが IPv4 のみを使用している場合は、このタイプを選択します。
      • デュアルスタック: ホストが IPv4 と IPv6 を併用している場合、デュアルスタックを選択できます。
   2. マシンネットワーク を定義します。デフォルトのネットワークを使用するか、サブネットを選択できます。
   3. API 仮想 IP を定義します。API 仮想 IP は、すべてのユーザーが対話し、プラットフォームを設定するためのエンドポイントを提供します。
   4. Ingress 仮想 IP を定義します。Ingress 仮想 IP は、クラスターの外部から流れるアプリケーショントラフィックのエンドポイントを提供します。
   5. オプション: Allocate IPs via DHCP server を選択して、DHCP サーバーを使用して API IP と Ingress IP を自動的に割り当てることができます。

4. オプション: Use advanced networking を選択して、以下の高度なネットワークプロパティーを設定します。

   • クラスターネットワーク CIDR: Pod IP アドレスが割り当てられる IP アドレスブロックを定義します。
   • クラスターネットワークホストプリフィックス: 各ノードに割り当てるサブネットプリフィックス長を定義します。
   • サービスネットワーク CIDR: サービス IP アドレスに使用する IP アドレスを定義します。
   • Network type: 標準ネットワーク用の Software-Defined Networking (SDN) または IPv6、デュアルスタックネットワーク、Telco 機能用の Open Virtual Networking (OVN) のいずれかを選択します。OpenShift Container Platform 4.12 以降のリリースでは、OVN がデフォルトの Container Network Interface (CNI) です。

手順

1. Begin installation を押します。
2. 特定のホストのインストールステータスを表示するには、Host Inventory リストの Status 列のリンクをクリックします。

手順

1. kubeadmin のユーザー名とパスワードのコピーを作成します。

2. kubeconfig ファイルをダウンロードして、作業ディレクトリーの下の auth ディレクトリーにコピーします。

   $ mkdir -p <working_directory>/auth

   $ cp kubeadmin <working_directory>/auth

   注記

   kubeconfig ファイルは、インストールの完了後 24 時間はダウンロードできます。

3. kubeconfig ファイルをお使いの環境に追加します。

   $ export KUBECONFIG=<your working directory>/auth/kubeconfig

4. oc CLI ツールでログインします。

   $ oc login -u kubeadmin -p <password>

   <password> を kubeadmin ユーザーのパスワードに置き換えます。

5. Web コンソールの URL をクリックするか、Launch OpenShift Console をクリックしてコンソールを開きます。
6. kubeadmin のユーザー名とパスワードを入力します。OpenShift Container Platform コンソールの指示に従って、アイデンティティープロバイダーを設定し、アラートレシーバーを設定します。
7. OpenShift Container Platform コンソールのブックマークを追加します。
8. インストール後のプラットフォーム統合手順を完了します。

手順

1. メニューで OpenShift をクリックします。
2. サブメニューで Downloads をクリックします。
3. OpenShift Cluster Manager API Token の下の Tokens セクションで、View API Token をクリックします。

4. Load Token をクリックします。

   重要

   ポップアップブロッカーを無効にします。

5. Your API token セクションで、オフライントークンをコピーします。

6. 端末で、オフライントークンを OFFLINE_TOKEN 変数に設定します。

   $ export OFFLINE_TOKEN=<copied_api_token>

   ヒント

   オフライントークンを永続的にするには、プロファイルに追加します。

7. ocm CLI のダウンロード をクリックします。
8. ダウンロードしたファイルをパスにコピーします。たとえば、ファイルを /usr/bin または ~/.local/bin にコピーして、ocm シンボリックリンクを作成します。

9. 認証コマンドを端末にコピーアンドペーストし、Enter キー を押してログインします。

   $ ocm login --token="${OFFLINE_TOKEN}"

手順

1. OFFLINE_TOKEN を使用して API_TOKEN 変数を設定し、ユーザーを検証します。

   1. (オプション) コマンドラインターミナルで、次のコマンドを実行します。

      $ export API_TOKEN=$( \
        curl \
        --silent \
        --header "Accept: application/json" \
        --header "Content-Type: application/x-www-form-urlencoded" \
        --data-urlencode "grant_type=refresh_token" \
        --data-urlencode "client_id=cloud-services" \
        --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \
        "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \
        | jq --raw-output ".access_token" \
      )

   2. (オプション) コマンドライン端末で、ocm クライアントにログインします。

      $ ocm login --token="${OFFLINE_TOKEN}"

      次に、API トークンを生成します。

      $ export API_TOKEN=$(ocm token)

2. トークン生成方法の 1 つのパスにスクリプトを作成します。以下に例を示します。

   $ vim ~/.local/bin/refresh-token

   export API_TOKEN=$( \
     curl \
     --silent \
     --header "Accept: application/json" \
     --header "Content-Type: application/x-www-form-urlencoded" \
     --data-urlencode "grant_type=refresh_token" \
     --data-urlencode "client_id=cloud-services" \
     --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \
     "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \
     | jq --raw-output ".access_token" \
   )

   次に、ファイルを保存します。

3. ファイルモードを変更して実行可能にします。

   $ chmod +x ~/.local/bin/refresh-token

4. API トークンを更新します。

   $ source refresh-token

5. 次のコマンドを実行して、API にアクセスできることを確認します。

   $ curl -s https://api.openshift.com/api/assisted-install/v2/component-versions -H "Authorization: Bearer ${API_TOKEN}" | jq

   出力例

   {
     "release_tag": "v2.11.3",
     "versions": {
       "assisted-installer": "registry.redhat.io/rhai-tech-preview/assisted-installer-rhel8:v1.0.0-211",
       "assisted-installer-controller": "registry.redhat.io/rhai-tech-preview/assisted-installer-reporter-rhel8:v1.0.0-266",
       "assisted-installer-service": "quay.io/app-sre/assisted-service:78d113a",
       "discovery-agent": "registry.redhat.io/rhai-tech-preview/assisted-installer-agent-rhel8:v1.0.0-195"
     }
   }

手順

1. メニューで OpenShift をクリックします。
2. サブメニューで Downloads をクリックします。
3. Pull secret の下の Tokens セクションで、Download をクリックします。

4. シェル変数からプルシークレットを使用するには、次のコマンドを実行します。

   $ export PULL_SECRET=$(cat ~/Downloads/pull-secret.txt | jq -R .)

5. jq を使用してプルシークレットファイルを丸呑みするには、pull_secret 変数で参照し、値を tojson にパイプして、エスケープされた JSON として適切にフォーマットされていることを確認します。以下に例を示します。

   $ curl https://api.openshift.com/api/assisted-install/v2/clusters \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d "$(jq --null-input \
           --slurpfile pull_secret ~/Downloads/pull-secret.txt ' 1
       {
           "name": "testcluster",
           "high_availability_mode": "None",
           "openshift_version": "4.11",
           "pull_secret": $pull_secret[0] | tojson, 2
           "base_dns_domain": "example.com"
       }
   ')"

   1

   プルシークレットファイルを丸呑みします。

   2

   プルシークレットをエスケープされた JSON 形式にフォーマットします。

手順

1. API トークンを更新します。

   $ source refresh-token

2. 新しいクラスターを登録します。

   1. オプション: リクエストでプルシークレットファイルを一気に読み込むことで、新しいクラスターを登録できます。

      $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
          --slurpfile pull_secret ~/Downloads/pull-secret.txt '
      {
          "name": "testcluster",
          "openshift_version": "4.11",
          "cpu_architecture" : "<architecture_name>" 1
          "high_availability_mode": <cluster_type>, 2
          "base_dns_domain": "example.com",
          "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'

      注記

      1

      次の値のいずれかを使用します: x86_64、arm64、ppc64le、s390x、multi。混合アーキテクチャーのクラスターの場合、multi のみを使用します。

      2

      マルチノード OpenShift クラスターを表すにはデフォルト値 full を使用し、単一ノード OpenShift クラスターを表すには none を使用します。

   2. オプション: 設定を JSON ファイルに書き込み、それをリクエストで参照することにより、新しいクラスターを登録できます。

      cat << EOF > cluster.json
      {
        "name": "testcluster",
        "openshift_version": "4.11",
        "high_availability_mode": "<cluster_type>",
        "base_dns_domain": "example.com",
        "pull_secret": $PULL_SECRET
      }
      EOF

      $ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/clusters" \
        -d @./cluster.json \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
        | jq '.id'

3. 返された cluster_id を CLUSTER_ID 変数に割り当て、エクスポートします。

   $ export CLUSTER_ID=<cluster_id>

   注記

   ターミナルセッションを閉じる場合は、新しいターミナルセッションで CLUSTER_ID 変数を再度エクスポートする必要があります。

4. 新しいクラスターのステータスを確認します。

   $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $API_TOKEN" \
     | jq

手順

1. API トークンを更新します。

   $ source refresh-token

2. クラスターを変更します。以下に例を示します。

   $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
   -X PATCH \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '
   {
       "ssh_public_key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDZrD4LMkAEeoU2vShhF8VM+cCZtVRgB7tqtsMxms2q3TOJZAgfuqReKYWm+OLOZTD+DO3Hn1pah/mU3u7uJfTUg4wEX0Le8zBu9xJVym0BVmSFkzHfIJVTn6SfZ81NqcalisGWkpmkKXVCdnVAX6RsbHfpGKk9YPQarmRCn5KzkelJK4hrSWpBPjdzkFXaIpf64JBZtew9XVYA3QeXkIcFuq7NBuUH9BonroPEmIXNOa41PUP1IWq3mERNgzHZiuU8Ks/pFuU5HCMvv4qbTOIhiig7vidImHPpqYT/TCkuVi5w0ZZgkkBeLnxWxH0ldrfzgFBYAxnpTU8Ih/4VhG538Ix1hxPaM6cXds2ic71mBbtbSrk+zjtNPaeYk1O7UpcCw4jjHspU/rVV/DY51D5gSiiuaFPBMucnYPgUxy4FMBFfGrmGLIzTKiLzcz0DiSz1jBeTQOX++1nz+KDLBD8CPdi5k4dq7lLkapRk85qdEvgaG5RlHMSPSS3wDrQ51fD8= user@hostname"
   }
   ' | jq

手順

1. API トークンを更新します。

   $ source refresh-token

2. 新しいインフラストラクチャー環境を登録します。できればクラスター名を含む名前を指定します。この例では、クラスター ID を提供して、インフラストラクチャー環境をクラスターリソースに関連付けます。次の例では、image_type を指定しています。full-iso または minimum- iso のいずれかを指定できます。デフォルト値は minimal-iso です。

   1. オプション: リクエストでプルシークレットファイルを丸呑みすることで、新しいインフラストラクチャー環境を登録できます。

      $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
        --slurpfile pull_secret ~/Downloads/pull-secret.txt \
        --arg cluster_id ${CLUSTER_ID} '
          {
            "name": "testcluster-infra-env",
            "image_type":"full-iso",
            "cluster_id": $cluster_id,
            "cpu_architecture" : "<architecture_name>" 1
            "pull_secret": $pull_secret[0] | tojson
          }
      ')" | jq '.id'

      注記

      1

      有効な値を指定してください。x86_64、arm64、ppc64le、s390x、multi が有効です。

   2. オプション: 設定を JSON ファイルに書き込み、それを要求で参照することにより、新しいインフラストラクチャー環境を登録できます。

      $ cat << EOF > infra-envs.json
      {
       "name": "testcluster-infra-env",
       "image_type": "full-iso",
       "cluster_id": "$CLUSTER_ID",
       "pull_secret": $PULL_SECRET
      }
      EOF

      $ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/infra-envs" \
       -d @./infra-envs.json \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer $API_TOKEN" \
       | jq '.id'

3. 返された ID を INFRA_ENV_ID 変数に割り当て、エクスポートします。

   $ export INFRA_ENV_ID=<id>

手順

1. API トークンを更新します。

   $ source refresh-token

2. インフラストラクチャー環境を変更します。

   $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID} \
   -X PATCH \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d "$(jq --null-input \
     --slurpfile pull_secret ~/Downloads/pull-secret.txt '
       {
         "image_type":"minimal-iso",
         "pull_secret": $pull_secret[0] | tojson
       }
   ')" | jq

手順

1. 必要に応じて検出イメージを設定します。追加リソース の iPXE を使用したホストの起動 を参照してください。

2. API トークンを更新します。

   $ source refresh-token

3. ダウンロード URL を取得します。

   $ curl -H "Authorization: Bearer ${API_TOKEN}" \
   https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/downloads/image-url

4. 検出イメージをダウンロードします。

   $ wget -O discovery.iso '<url>'

   <url> を前の手順のダウンロード URL に置き換えます。

5. 検出イメージを使用してホストを起動します。プラットフォームにインストールし、プラットフォームと統合したい場合は、詳細について以下の追加リソースを参照してください。
6. ホストにロールを割り当てます。

手順

1. API トークンを更新します。

   $ source refresh-token

2. ホスト ID を取得します。

   $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
   --header "Content-Type: application/json" \
     -H "Authorization: Bearer $API_TOKEN" \
   | jq '.host_networks[].host_ids'

3. z/VM を使用した IBM Z (s390x)へのインストールには、追加のカーネル引数が必要です。

   1. 一致するノードの hostID を取得するには、以下のコマンドを実行します。

      curl https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts -H "Authorization: Bearer ${API_TOKEN}" | jq '.[]|[.id,.requested_hostname] | join("|")'

   2. 必要なカーネル引数を指定するには、以下のコマンドを実行します。

      curl https://api.stage.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/$1/installer-args \
      -X PATCH \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d '
      {
      "args": [
      "--append-karg", "rd.neednet=1",
      "--append-karg", "ip=10.14.6.3::10.14.6.1:255.255.255.0:master-0.boea3e06.lnxero1.boe:encbdd0:none",
      "--append-karg", "nameserver=10.14.6.1",
      "--append-karg", "ip=[fd00::3]::[fd00::1]:64::encbdd0:none",
      "--append-karg", "nameserver=[fd00::1]",
      "--append-karg", "zfcp.allow_lun_scan=0",
      "--append-karg", "rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1",
      "--append-karg", "rd.dasd=0.0.5235"
      ]
      }
      ' | jq

      注記

      各ホストに特定のカーネル引数が含まれる場合があります。

      出力例

      [
        "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5"
      ]

4. ホストを変更します。

   $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \ 1
   -X PATCH \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '
       {
         "host_role":"worker"
         "host_name" : "worker-1"
       }
   ' | jq

   1

   <host_id> をホストの ID に置き換えます。

手順

1. API トークンを更新します。

   $ source refresh-token

2. クラスターをインストールします。

   $ curl -H "Authorization: Bearer $API_TOKEN" \
   -X POST \
   https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/actions/install | jq

3. インストール後のプラットフォーム統合手順を完了します。

手順

1. オプション: UI を使用して、ユーザーインターフェイスウィザードの クラスターの詳細 ステップで、コントロールプレーンノード、ワーカー、またはその両方で TPM v2 暗号化を有効にすることを選択します。

2. オプション: API を使用して、ホストの変更手順に従います。disk_encryption.enable_on 設定を all、masters、または worker に設定します。disk_encryption.mode 設定を tpmv2 に設定します。

   1. API トークンを更新します。

      $ source refresh-token

   2. TPM v2 暗号化を有効にします。

      $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
      -X PATCH \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d '
      {
        "disk_encryption": {
          "enable_on": "none",
          "mode": "tpmv2"
        }
      }
      ' | jq

      enable_on の有効な設定は、all、master、worker、または none です。

手順

1. Tang サーバーを設定するか、既存のサーバーにアクセスします。手順については、NBDE (Network-Bound Disk Encryption) を参照してください。複数の Tang サーバーを設定できますが、Assisted Installer はインストール中にすべてのサーバーに接続できる必要があります。

2. Tang サーバーで、tang-show-keys を使用して Tang サーバーのサムプリントを取得します。

   $ tang-show-keys <port>

   オプション: <port> ポート番号に置き換えます。デフォルトのポート番号は 80 です。

   サムプリントの例

   1gYTN_LpU9ZMB35yn5IbADY5OQ0

3. オプション: jose を使用して Tang サーバーのサムプリントを取得します。

   1. jose が Tang サーバーにインストールされていることを確認します。

      $ sudo dnf install jose

   2. Tang サーバーで、jose を使用してサムプリントを取得します。

      $ sudo jose jwk thp -i /var/db/tang/<public_key>.jwk

      <public_key> を Tang サーバーの公開交換キーに置き換えます。

      サムプリントの例

      1gYTN_LpU9ZMB35yn5IbADY5OQ0

4. オプション: ユーザーインターフェイスウィザードの クラスターの詳細 ステップで、コントロールプレーンノード、ワーカー、またはその両方で Tang 暗号化を有効にすることを選択します。Tang サーバーの URL と拇印を入力する必要があります。

5. オプション: API を使用して、ホストの変更手順に従います。

   1. API トークンを更新します。

      $ source refresh-token

   2. disk_encryption.enable_on 設定を all、masters、または worker に設定します。disk_encryption.mode 設定を tang に設定します。disk_encyrption.tang_servers を設定して、1 つ以上の Tang サーバーに関する URL と拇印の詳細を提供します。

      $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
      -X PATCH \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d '
      {
        "disk_encryption": {
          "enable_on": "all",
          "mode": "tang",
          "tang_servers": "[{\"url\":\"http://tang.example.com:7500\",\"thumbprint\":\"PLjNyRdGw03zlRoGjQYMahSZGu9\"},{\"url\":\"http://tang2.example.com:7500\",\"thumbprint\":\"XYjNyRdGw03zlRoGjQYMahSZGu3\"}]"
        }
      }
      ' | jq

      enable_on の有効な設定は、all、master、worker、または none です。tang_servers 値内で、オブジェクト内の引用符をコメントアウトします。

手順

1. API トークンを更新します。

   $ source refresh-token

2. 以下のように既存のクラスターをリストして、CLUSTER_ID 変数を特定します。

   $ curl -s https://api.openshift.com/api/assisted-install/v2/clusters -H "Authorization: Bearer ${API_TOKEN}" | jq '[ .[] | { "name": .name, "id": .id } ]'

   出力例

   [
     {
       "name": "lvmtest",
       "id": "475358f9-ed3a-442f-ab9e-48fd68bc8188" 1
     },
     {
       "name": "mcetest",
       "id": "b5259f97-be09-430e-b5eb-d78420ee509a"
     }
   ]

   注記

   1

   id の値は <cluster_id> です。

3. 返された cluster_id を CLUSTER_ID 変数に割り当て、エクスポートします。

   $ export CLUSTER_ID=<cluster_id>

4. 新しい Operator でクラスターを更新します。

   $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
   -X PATCH \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '
   {
       "olm_operators": [{"name": "mce"}, {"name": "cnv"}], 1
   }
   ' | jq '.id'

   注記

   1

   インストールする Operator を示します。有効な値は、mce、cnv、lvm、odf などになります。以前にインストールされた Operator を削除するには、これを値の一覧から除外します。以前にインストールされた Operator をすべて削除するには、"olm_operators": [] を入力します。

   出力例

   {
     <various cluster properties>,
     "monitored_operators": [
       {
         "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
         "name": "console",
         "operator_type": "builtin",
         "status_updated_at": "0001-01-01T00:00:00.000Z",
         "timeout_seconds": 3600
       },
       {
         "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
         "name": "cvo",
         "operator_type": "builtin",
         "status_updated_at": "0001-01-01T00:00:00.000Z",
         "timeout_seconds": 3600
       },
       {
         "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
         "name": "mce",
         "namespace": "multicluster-engine",
         "operator_type": "olm",
         "status_updated_at": "0001-01-01T00:00:00.000Z",
         "subscription_name": "multicluster-engine",
         "timeout_seconds": 3600
       },
       {
         "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
         "name": "cnv",
         "namespace": "openshift-cnv",
         "operator_type": "olm",
         "status_updated_at": "0001-01-01T00:00:00.000Z",
         "subscription_name": "hco-operatorhub",
         "timeout_seconds": 3600
       },
       {
         "cluster_id": "b5259f97-be09-430e-b5eb-d78420ee509a",
         "name": "lvm",
         "namespace": "openshift-local-storage",
         "operator_type": "olm",
         "status_updated_at": "0001-01-01T00:00:00.000Z",
         "subscription_name": "local-storage-operator",
         "timeout_seconds": 4200
       }
     ],
     <more cluster properties>

   注記

   この出力は、新しいクラスターの状態の説明になります。出力の monitored_operators プロパティーには、次の 2 つのタイプの Operator が含まれます。

   • "operator_type": "builtin": このタイプの Operator は、OpenShift Container Platform の不可欠な部分です。
   • "operator_type": "olm": このタイプの Operator は、ユーザーによって手動で追加されるか、依存関係により自動的に追加されます。この例では、lso Operator は、cnv Operator によって必要とされるため、自動的に追加されていました。

手順

1. Ignition ファイルを作成し、設定仕様のバージョンを指定します。

   $ vim ~/ignition.conf

   {
     "ignition": { "version": "3.1.0" }
   }

2. 設定データを Ignition ファイルに追加します。たとえば、core ユーザーにパスワードを追加します。

   1. パスワードハッシュを生成します。

      $ openssl passwd -6

   2. 生成されたパスワードハッシュを core ユーザーに追加します。

      {
        "ignition": { "version": "3.1.0" },
        "passwd": {
          "users": [
            {
              "name": "core",
              "passwordHash": "$6$spam$M5LGSMGyVD.9XOboxcwrsnwNdF4irpJdAWy.1Ry55syyUiUssIzIAHaOrUHr2zg6ruD8YNBPW9kW0H8EnKXyc1"
            }
          ]
        }
      }

3. Ignition ファイルを保存し、IGNITION_FILE 変数にエクスポートします。

   $ export IGNITION_FILE=~/ignition.conf

手順

1. lightning_config_override JSON オブジェクトを作成し、ファイルにリダイレクトします。

   $ jq -n \
     --arg IGNITION "$(jq -c . $IGNITION_FILE)" \
     '{ignition_config_override: $IGNITION}' \
     > discovery_ignition.json

2. API トークンを更新します。

   $ source refresh-token

3. インフラストラクチャー環境にパッチを適用します。

   $ curl \
     --header "Authorization: Bearer $API_TOKEN" \
     --header "Content-Type: application/json" \
     -XPATCH \
     -d @discovery_ignition.json \
     https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID | jq

   lightning_config_override オブジェクトは、Ignition ファイルを参照します。

4. 更新された検出イメージをダウンロードします。

手順

1. 管理ホストで、USB ドライブを USB ポートに挿入します。

2. ISO イメージを USB ドライブにコピーします。次に例を示します。

   # dd if=<path_to_iso> of=<path_to_usb> status=progress

   ここでは、以下のようになります。

   <path_to_iso>

   ダウンロードした検出 ISO ファイルへの相対パスです (たとえば、discovery.iso)。

   <path_to_usb>

   /dev/sdb など、接続された USB ドライブの場所です。

   ISO が USB ドライブにコピーされたら、USB ドライブを使用してクラスターホストに Assisted Installer エージェントをインストールできます。

手順

1. RHCOS ディスカバリー ISO USB ドライブをターゲットホストに挿入します。
2. サーバーのファームウェア設定で起動ドライブの順序を設定し、アタッチされた検出 ISO から起動して、サーバーを再起動します。

3. ホストが起動するまで待ちます。

   1. UI インストールの場合、管理ホストでブラウザーに戻ります。ホストが、検出されたホストのリストに表示されるまで待ちます。

   2. API インストールの場合、トークンを更新し、有効なホスト数を確認して、ホスト ID を収集します。

      $ source refresh-token

      $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
      --header "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
      | jq '.enabled_host_count'

      $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
      --header "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
      | jq '.host_networks[].host_ids'

      出力例

      [
        "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5"
      ]

手順

1. ネットワークでアクセス可能な HTTP サーバーに ISO ファイルをコピーします。

2. ホストされている ISO ファイルからホストを起動します。以下に例を示します。

   1. 次のコマンドを実行して、redfish API を呼び出し、ホストされている ISO を VirtualMedia ブートメディアとして設定します。

      $ curl -k -u <bmc_username>:<bmc_password> \
      -d '{"Image":"<hosted_iso_file>", "Inserted": true}' \
      -H "Content-Type: application/json" \
      -X POST <host_bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia

      詳細は以下のようになります。

      <bmc_username>:<bmc_password>

      ターゲットホスト BMC のユーザー名とパスワードです。

      <hosted_iso_file>

      ホストされたインストール ISO の URL です (例: http://webserver.example.com/rhcos-live-minimal.iso)。ISO は、ターゲットホストマシンからアクセスできる必要があります。

      <host_bmc_address>

      ターゲットホストマシンの BMC IP アドレスです。

   2. 次のコマンドを実行して、VirtualMedia デバイスから起動するようにホストを設定します。

      $ curl -k -u <bmc_username>:<bmc_password> \
      -X PATCH -H 'Content-Type: application/json' \
      -d '{"Boot": {"BootSourceOverrideTarget": "Cd", "BootSourceOverrideMode": "UEFI", "BootSourceOverrideEnabled": "Once"}}' \
      <host_bmc_address>/redfish/v1/Systems/System.Embedded.1

   3. ホストを再起動します。

      $ curl -k -u <bmc_username>:<bmc_password> \
      -d '{"ResetType": "ForceRestart"}' \
      -H 'Content-type: application/json' \
      -X POST <host_bmc_address>/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset

   4. オプション: ホストの電源がオフになっている場合は、{"ResetType": "On"} スイッチを使用して起動できます。以下のコマンドを実行します。

      $ curl -k -u <bmc_username>:<bmc_password> \
      -d '{"ResetType": "On"}' -H 'Content-type: application/json' \
      -X POST <host_bmc_address>/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset

手順

1. UI から直接 iPXE スクリプトをダウンロードするか、Assisted Installer から iPXE スクリプトを取得します。

   $ curl \
     --silent \
     --header "Authorization: Bearer $API_TOKEN" \
     https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/downloads/files?file_name=ipxe-script > ipxe-script

   例

   #!ipxe
   initrd --name initrd http://api.openshift.com/api/assisted-images/images/<infra_env_id>/pxe-initrd?arch=x86_64&image_token=<token_string>&version=4.10
   kernel http://api.openshift.com/api/assisted-images/boot-artifacts/kernel?arch=x86_64&version=4.10 initrd=initrd coreos.live.rootfs_url=http://api.openshift.com/api/assisted-images/boot-artifacts/rootfs?arch=x86_64&version=4.10 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"
   boot

2. ipxe-script から URL を抽出して、必要なアーティファクトをダウンロードします。

   1. 初期 RAM ディスクをダウンロードします。

      $ awk '/^initrd /{print $NF}' ipxe-script | curl -o initrd.img

   2. Linux カーネルをダウンロードします。

      $ awk '/^kernel /{print $2}' ipxe-script | curl -o kernel

   3. ルートファイルシステムをダウンロードします。

      $ grep ^kernel ipxe-script | xargs -n1| grep ^coreos.live.rootfs_url | cut -d = -f 2- | curl -o rootfs.img

3. URL を ipxe-script` 内のさまざまなアーティファクトに変更して、ローカル HTTP サーバーに一致させます。以下に例を示します。

   #!ipxe
   set webserver http://192.168.0.1
   initrd --name initrd $webserver/initrd.img
   kernel $webserver/kernel initrd=initrd coreos.live.rootfs_url=$webserver/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"
   boot

4. オプション: IBM zSystems に RHEL KVM を使用してインストールする場合は、追加のカーネル引数を指定してホストを起動する必要があります。

   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

   注記

   iPXE を使用して RHEL KVM にインストールする場合、VM ホスト上の VM が初回起動時に再起動されず、手動での起動が必要になることがあります。

5. オプション: IBM Power にインストールする場合は、次のように intramfs、カーネル、および root をダウンロードする必要があります。

   1. initrd.img と kernel.img を PXE ディレクトリー `/var/lib/tftpboot/rhcos` にコピーします。
   2. rootfs.img を HTTPD ディレクトリー `/var/www/html/install` にコピーします。

   3. 次のエントリーを `/var/lib/tftpboot/boot/grub2/grub.cfg` に追加します。

      if [ ${net_default_mac} == fa:1d:67:35:13:20 ]; then
      default=0
      fallback=1
      timeout=1
      menuentry "CoreOS (BIOS)" {
      echo "Loading kernel"
      linux "/rhcos/kernel.img" ip=dhcp rd.neednet=1 ignition.platform.id=metal ignition.firstboot coreos.live.rootfs_url=http://9.114.98.8:8000/install/rootfs.img
      echo "Loading initrd"
      initrd "/rhcos/initrd.img"
      }
      fi

手順

1. Host Discovery タブに移動し、Host Inventory テーブルまで下にスクロールします。

2. 必要なホストの Auto-assign ドロップダウンを選択します。

   1. Control plane node を選択して、このホストにコントロールプレーンロールを割り当てます。
   2. Worker を選択して、このホストにワーカーロールを割り当てます。
3. バリデーションステータスを確認します。

手順

1. API トークンを更新します。

   $ source refresh-token

2. ホスト ID を取得します。

   $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID" \
   --header "Content-Type: application/json" \
     -H "Authorization: Bearer $API_TOKEN" \
   | jq '.host_networks[].host_ids'

   出力例

   [
     "1062663e-7989-8b2d-7fbb-e6f4d5bb28e5"
   ]

3. host_role 設定を変更します。

   $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \
   -X PATCH \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '
       {
         "host_role":"worker"
       }
   ' | jq

   <host_id> をホストの ID に置き換えます。

前提条件

1. API を使用してインフラストラクチャー環境を作成したか、UI を使用してクラスターを作成している。
2. インフラストラクチャー環境 ID がシェルに $INFRA_ENV_ID としてエクスポートされている。
3. API にアクセスするときに使用する認証情報があり、シェルで $API_TOKEN としてトークンをエクスポートしました。
4. server-a.yaml および server-b.yaml として利用可能な静的ネットワーク設定を持つ YAML ファイルがあります。

手順

1. API リクエストを含む一時ファイル /tmp/request-body.txt を作成します。

   ---
   jq -n --arg NMSTATE_YAML1 "$(cat server-a.yaml)" --arg NMSTATE_YAML2 "$(cat server-b.yaml)" \
   '{
     "static_network_config": [
       {
         "network_yaml": $NMSTATE_YAML1,
         "mac_interface_map": [{"mac_address": "02:00:00:2c:23:a5", "logical_nic_name": "eth0"}, {"mac_address": "02:00:00:68:73:dc", "logical_nic_name": "eth1"}]
       },
       {
         "network_yaml": $NMSTATE_YAML2,
         "mac_interface_map": [{"mac_address": "02:00:00:9f:85:eb", "logical_nic_name": "eth1"}, {"mac_address": "02:00:00:c8:be:9b", "logical_nic_name": "eth0"}]
        }
     ]
   }' >> /tmp/request-body.txt
   ---

2. API トークンを更新します。

   $ source refresh-token

3. Assisted Service API エンドポイントにリクエストを送信します。

   ---
   curl -H "Content-Type: application/json" \
   -X PATCH -d @/tmp/request-body.txt \
   -H "Authorization: Bearer ${API_TOKEN}" \
   https://api.openshift.com/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID
   ---

手順

1. CLI を使用してクラスターにログインします。

2. architecture 設定を確認します。

   $ oc adm release info -o json | jq .metadata.metadata

   architecture 設定が 'multi' に設定されていることを確認します。

   {
     "release.openshift.io/architecture": "multi"
   }

手順

1. OpenShift Cluster Manager にログインし、拡張するクラスターをクリックします。
2. Add hosts をクリックし、新規ホストの検出 ISO をダウンロードし、必要に応じて SSH 公開鍵を追加し、クラスター全体のプロキシーを設定します。
3. オプション: 必要に応じて、Ignition ファイルを変更します。
4. 検出 ISO を使用してターゲットホストを起動し、ホストがコンソールで検出されるまで待ちます。
5. ホストロールを選択します。worker または control plane ホストのいずれかになります。
6. インストールを開始します。

7. インストールが進行すると、ホストに対して保留中の証明書署名要求 (CSR) が生成されます。プロンプトが表示されたら、保留中の CSR を承認してインストールを完了します。

   ホストが正常にインストールされると、クラスター Web コンソールにホストとしてリストされます。

手順

1. Assisted Installer の REST API に対して認証し、セッションの API トークンを生成します。生成されたトークンは 15 分間のみ有効です。

2. 次のコマンドを実行して、$API_URL 変数を設定します。

   $ export API_URL=<api_url> 1

   1

   <api_url> を Assisted Installer API の URL に置き換えます (例: https://api.openshift.com)。

3. 以下のコマンドを実行してクラスターをインポートします。

   1. $CLUSTER_ID 変数を設定します。クラスターにログインし、次のコマンドを実行します。

      $ export CLUSTER_ID=$(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}')

   2. クラスターのインポートに使用される $CLUSTER_REQUEST 変数を設定します。

      $ export CLUSTER_REQUEST=$(jq --null-input --arg openshift_cluster_id "$CLUSTER_ID" '{
        "api_vip_dnsname": "<api_vip>", 1
        "openshift_cluster_id": $CLUSTER_ID,
        "name": "<openshift_cluster_name>" 2
      }')

      1

      <api_vip> をクラスターの API サーバーのホスト名に置き換えます。これは、API サーバーの DNS ドメイン、またはホストが到達できる単一ノードの IP アドレスになります。たとえば、api.compute-1.example.com です。

      2

      <openshift_cluster_name> をクラスターのプレーンテキスト名に置き換えます。クラスター名は、Day 1 クラスターのインストール中に設定されたクラスター名と一致する必要があります。

   3. クラスターをインポートし、$CLUSTER_ID 変数を設定します。以下のコマンドを実行します。

      $ CLUSTER_ID=$(curl "$API_URL/api/assisted-install/v2/clusters/import" -H "Authorization: Bearer ${API_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' \
        -d "$CLUSTER_REQUEST" | tee /dev/stderr | jq -r '.id')

4. 次のコマンドを実行して、クラスターの InfraEnv リソースを生成し、$INFRA_ENV_ID 変数を設定します。

   1. console.redhat.com の Red Hat OpenShift Cluster Manager からプルシークレットファイルをダウンロードします。

   2. $INFRA_ENV_REQUEST 変数を設定します。

      export INFRA_ENV_REQUEST=$(jq --null-input \
          --slurpfile pull_secret <path_to_pull_secret_file> \1
          --arg ssh_pub_key "$(cat <path_to_ssh_pub_key>)" \2
          --arg cluster_id "$CLUSTER_ID" '{
        "name": "<infraenv_name>", 3
        "pull_secret": $pull_secret[0] | tojson,
        "cluster_id": $cluster_id,
        "ssh_authorized_key": $ssh_pub_key,
        "image_type": "<iso_image_type>" 4
      }')

      1

      <path_to_pull_secret_file> を、console.redhat.com の Red Hat OpenShift Cluster Manager からダウンロードしたプルシークレットを含むローカルファイルへのパスに置き換えます。

      2

      <path_to_ssh_pub_key> を、ホストへのアクセスに必要な公開 SSH キーへのパスに置き換えます。この値を設定しないと、検出モードでホストにアクセスできません。

      3

      <infraenv_name> を InfraEnv リソースのプレーンテキスト名に置き換えます。

      4

      <iso_image_type> を full-iso または minimal-iso のいずれかの ISO イメージタイプに置き換えます。

   3. $INFRA_ENV_REQUEST を /v2/infra-envs API に送信し、$INFRA_ENV_ID 変数を設定します。

      $ INFRA_ENV_ID=$(curl "$API_URL/api/assisted-install/v2/infra-envs" -H "Authorization: Bearer ${API_TOKEN}" -H 'accept: application/json' -H 'Content-Type: application/json' -d "$INFRA_ENV_REQUEST" | tee /dev/stderr | jq -r '.id')

5. 次のコマンドを実行して、クラスターホストの検出 ISO の URL を取得します。

   $ curl -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq -r '.download_url'

   出力例

   https://api.openshift.com/api/assisted-images/images/41b91e72-c33e-42ee-b80f-b5c5bbf6431a?arch=x86_64&image_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTYwMjYzNzEsInN1YiI6IjQxYjkxZTcyLWMzM2UtNDJlZS1iODBmLWI1YzViYmY2NDMxYSJ9.1EX_VGaMNejMhrAvVRBS7PDPIQtbOOc8LtG8OukE1a4&type=minimal-iso&version=4.12

6. ISO をダウンロードします。

   $ curl -L -s '<iso_url>' --output rhcos-live-minimal.iso 1

   1

   <iso_url> を前の手順の ISO の URL に置き換えます。

7. ダウンロードした rhcos-live-minimal.iso から新しいワーカーホストを起動します。

8. インストールされていない クラスター内のホストのリストを取得します。新しいホストが表示されるまで、次のコマンドを実行し続けます。

   $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq -r '.hosts[] | select(.status != "installed").id'

   出力例

   2294ba03-c264-4f11-ac08-2f1bb2f8c296

9. 新しいホストの $HOST_ID 変数を設定します。以下に例を示します。

   $ HOST_ID=<host_id> 1

   1

   <host_id> を前の手順のホスト ID に置き換えます。

10. 以下のコマンドを実行して、ホストがインストールできる状態であることを確認します。

    注記

    完全な jq 式を含むコマンド全体をコピーしてください。

    $ curl -s $API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID -H "Authorization: Bearer ${API_TOKEN}" | jq '
    def host_name($host):
        if (.suggested_hostname // "") == "" then
            if (.inventory // "") == "" then
                "Unknown hostname, please wait"
            else
                .inventory | fromjson | .hostname
            end
        else
            .suggested_hostname
        end;
    
    def is_notable($validation):
        ["failure", "pending", "error"] | any(. == $validation.status);
    
    def notable_validations($validations_info):
        [
            $validations_info // "{}"
            | fromjson
            | to_entries[].value[]
            | select(is_notable(.))
        ];
    
    {
        "Hosts validations": {
            "Hosts": [
                .hosts[]
                | select(.status != "installed")
                | {
                    "id": .id,
                    "name": host_name(.),
                    "status": .status,
                    "notable_validations": notable_validations(.validations_info)
                }
            ]
        },
        "Cluster validations info": {
            "notable_validations": notable_validations(.validations_info)
        }
    }
    ' -r

    出力例

    {
      "Hosts validations": {
        "Hosts": [
          {
            "id": "97ec378c-3568-460c-bc22-df54534ff08f",
            "name": "localhost.localdomain",
            "status": "insufficient",
            "notable_validations": [
              {
                "id": "ntp-synced",
                "status": "failure",
                "message": "Host couldn't synchronize with any NTP server"
              },
              {
                "id": "api-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "api-int-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              },
              {
                "id": "apps-domain-name-resolved-correctly",
                "status": "error",
                "message": "Parse error for domain name resolutions result"
              }
            ]
          }
        ]
      },
      "Cluster validations info": {
        "notable_validations": []
      }
    }

11. 前のコマンドでホストの準備ができていることが示されたら、次のコマンドを実行し、/v2/infra-envs/{infra_env_id}/hosts/{host_id}/actions/install API を使用してインストールを開始します。

    $ curl -X POST -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install"  -H "Authorization: Bearer ${API_TOKEN}"

12. インストールが進行すると、ホストに対して保留中の証明書署名要求 (CSR) が生成されます。

    重要

    インストールを完了するには、CSR を承認する必要があります。

    次の API 呼び出しを実行し続けて、クラスターのインストールを監視します。

    $ curl -s "$API_URL/api/assisted-install/v2/clusters/$CLUSTER_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq '{
        "Cluster day-2 hosts":
            [
                .hosts[]
                | select(.status != "installed")
                | {id, requested_hostname, status, status_info, progress, status_updated_at, updated_at, infra_env_id, cluster_id, created_at}
            ]
    }'

    出力例

    {
      "Cluster day-2 hosts": [
        {
          "id": "a1c52dde-3432-4f59-b2ae-0a530c851480",
          "requested_hostname": "control-plane-1",
          "status": "added-to-existing-cluster",
          "status_info": "Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs",
          "progress": {
            "current_stage": "Done",
            "installation_percentage": 100,
            "stage_started_at": "2022-07-08T10:56:20.476Z",
            "stage_updated_at": "2022-07-08T10:56:20.476Z"
          },
          "status_updated_at": "2022-07-08T10:56:20.476Z",
          "updated_at": "2022-07-08T10:57:15.306369Z",
          "infra_env_id": "b74ec0c3-d5b5-4717-a866-5b6854791bd3",
          "cluster_id": "8f721322-419d-4eed-aa5b-61b50ea586ae",
          "created_at": "2022-07-06T22:54:57.161614Z"
        }
      ]
    }

13. オプション: 次のコマンドを実行して、クラスターのすべてのイベントを表示します。

    $ curl -s "$API_URL/api/assisted-install/v2/events?cluster_id=$CLUSTER_ID" -H "Authorization: Bearer ${API_TOKEN}" | jq -c '.[] | {severity, message, event_time, host_id}'

    出力例

    {"severity":"info","message":"Host compute-0: updated status from insufficient to known (Host is ready to be installed)","event_time":"2022-07-08T11:21:46.346Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from known to installing (Installation is in progress)","event_time":"2022-07-08T11:28:28.647Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing to installing-in-progress (Starting installation)","event_time":"2022-07-08T11:28:52.068Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Uploaded logs for host compute-0 cluster 8f721322-419d-4eed-aa5b-61b50ea586ae","event_time":"2022-07-08T11:29:47.802Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host compute-0: updated status from installing-in-progress to added-to-existing-cluster (Host has rebooted and no further updates will be posted. Please check console for progress and to possibly approve pending CSRs)","event_time":"2022-07-08T11:29:48.259Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}
    {"severity":"info","message":"Host: compute-0, reached installation stage Rebooting","event_time":"2022-07-08T11:29:48.261Z","host_id":"9d7b3b44-1125-4ad0-9b14-76550087b445"}

14. クラスターにログインし、保留中の CSR を承認してインストールを完了します。

1. マルチアーキテクチャークラスターを作成して登録します。
2. x86_64 インフラストラクチャー環境を作成し、x86_64 用の ISO をダウンロードし、コントロールプレーンを追加します。コントロールプレーンには x86_64 アーキテクチャーが必要です。
3. arm64、IBM Power または IBM zSystems インフラストラクチャー環境を作成し、arm64、IBM Power または IBM zSystems の ISO をダウンロードし、ワーカーノードを追加します。

主なステップ

1. API を使用して OpenShift Container Platform をインストールする手順を開始します。詳細は、関連情報 セクション の アシステッドインストーラー API を使用したインストール を参照 してください。

2. インストールの "Registering a new cluster" ステップに達したら、クラスターを マルチアーキテクチャー クラスターとして登録します。

   $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d "$(jq --null-input \
      --slurpfile pull_secret ~/Downloads/pull-secret.txt '
   {
      "name": "testcluster",
      "openshift_version": "<version-number>-multi", 1
      "cpu_architecture" : "multi" 2
      "high_availability_mode": "full" 3
      "base_dns_domain": "example.com",
      "pull_secret": $pull_secret[0] | tojson
   }
   ')" | jq '.id'

   注記

   1

   OpenShift バージョン番号には multi- オプションを使用します（例： "4.12-multi "）。

   2

   CPU アーキテクチャーを multi に設定します。

   3

   full 値を使用して、マルチノードの OpenShift を示します。

3. インストールの「新しいインフラストラクチャー環境の登録」手順に達したら、cpu_architecture を x86 _64 に設定します。

   $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d "$(jq --null-input \
    --slurpfile pull_secret ~/Downloads/pull-secret.txt \
    --arg cluster_id ${CLUSTER_ID} '
      {
        "name": "testcluster-infra-env",
        "image_type":"full-iso",
        "cluster_id": $cluster_id,
        "cpu_architecture" : "x86_64"
        "pull_secret": $pull_secret[0] | tojson
      }
   ')" | jq '.id'

4. インストールのホストの追加ステップに達したら、host_role を master に設定します。

   注記

   詳細は、関連情報 の ホストへのロールの割り当て を 参照してください。

   $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \
   -X PATCH \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '
      {
        "host_role":"master"
      }
   ' | jq

5. x86_64 アーキテクチャーの検出イメージをダウンロードします。
6. 生成された検出イメージを使用して x86_64 アーキテクチャーホストを起動します。
7. インストールを開始し、クラスターが完全にインストールされるまで待ちます。

8. インストールの新しいインフラストラクチャー環境の登録ステップを繰り返します。今回は、cpu_architecture を、ppc64le (IBM Power 用)、s390x (IBM Z 用)、または arm64 のいずれかに設定します。以下に例を示します。

   $ curl -s -X POST https://api.openshift.com/api/assisted-install/v2/clusters \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d "$(jq --null-input \
      --slurpfile pull_secret ~/Downloads/pull-secret.txt '
   {
      "name": "testcluster",
      "openshift_version": "4.12",
      "cpu_architecture" : "arm64"
      "high_availability_mode": "full"
      "base_dns_domain": "example.com",
      "pull_secret": $pull_secret[0] | tojson
   }
   ')" | jq '.id'

9. インストールのホストの追加手順を繰り返します。今回は、host_role を worker に設定します。

   注記

   詳細は、Additional Resources の Assigning roles to Hosts を 参照してください。

   $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/hosts/<host_id> \
   -X PATCH \
   -H "Authorization: Bearer ${API_TOKEN}" \
   -H "Content-Type: application/json" \
   -d '
      {
        "host_role":"worker"
      }
   ' | jq

10. arm64、ppc64le、または s390x アーキテクチャーの検出イメージをダウンロードします。
11. 生成された検出イメージを使用してアーキテクチャーホストを起動します。
12. インストールを開始し、クラスターが完全にインストールされるまで待ちます。

手順

1. CSR の確認して承認します。

   1. CertificateSigningRequests (CSR) を確認します。

      $ oc get csr | grep Pending

      出力例

      csr-5sd59   8m19s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   <none>              Pending
      csr-xzqts   10s     kubernetes.io/kubelet-serving                 system:node:worker-6                                                   <none>              Pending

   2. 保留中の 全 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

      重要

      インストールを完了するには、CSR を承認する必要があります。

2. プライマリーノードが Ready ステータスであることを確認します。

   $ oc get nodes

   出力例

   NAME       STATUS   ROLES    AGE     VERSION
   master-0   Ready    master   4h42m   v1.24.0+3882f8f
   worker-1   Ready    worker   4h29m   v1.24.0+3882f8f
   master-2   Ready    master   4h43m   v1.24.0+3882f8f
   master-3   Ready    master   4h27m   v1.24.0+3882f8f
   worker-4   Ready    worker   4h30m   v1.24.0+3882f8f
   master-5   Ready    master   105s    v1.24.0+3882f8f

   注記

   機能する Machine API を使用してクラスターを実行する場合、etcd-operator に、新しいノードを参照する Machine カスタムリソース (CR) が必要です。

3. Machine CR を BareMetalHost および Node にリンクします。

   1. 一意の .metadata.name の値を使用して BareMetalHost CR を作成します。

      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: custom-master3
        namespace: openshift-machine-api
        annotations:
      spec:
        automatedCleaningMode: metadata
        bootMACAddress: 00:00:00:00:00:02
        bootMode: UEFI
        customDeploy:
          method: install_coreos
        externallyProvisioned: true
        online: true
        userData:
          name: master-user-data-managed
          namespace: openshift-machine-api

      $ oc create -f <filename>

   2. BareMetalHost CR を適用します。

      $ oc apply -f <filename>

   3. 一意の .machine.name 値を使用して Machine CR を作成します。

      apiVersion: machine.openshift.io/v1beta1
      kind: Machine
      metadata:
        annotations:
          machine.openshift.io/instance-state: externally provisioned
          metal3.io/BareMetalHost: openshift-machine-api/custom-master3
        finalizers:
        - machine.machine.openshift.io
        generation: 3
        labels:
          machine.openshift.io/cluster-api-cluster: test-day2-1-6qv96
          machine.openshift.io/cluster-api-machine-role: master
          machine.openshift.io/cluster-api-machine-type: master
        name: custom-master3
        namespace: openshift-machine-api
      spec:
        metadata: {}
        providerSpec:
          value:
            apiVersion: baremetal.cluster.k8s.io/v1alpha1
            customDeploy:
              method: install_coreos
            hostSelector: {}
            image:
              checksum: ""
              url: ""
            kind: BareMetalMachineProviderSpec
            metadata:
              creationTimestamp: null
            userData:
              name: master-user-data-managed

      $ oc create -f <filename>

   4. Machine CR を適用します。

      $ oc apply -f <filename>

   5. link-machine-and-node.sh スクリプトを使用して、BareMetalHost、Machine、および Node をリンクします。

      #!/bin/bash
      
      # Credit goes to https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
      # This script will link Machine object and Node object. This is needed
      # in order to have IP address of the Node present in the status of the Machine.
      
      set -x
      set -e
      
      machine="$1"
      node="$2"
      
      if [ -z "$machine" -o -z "$node" ]; then
          echo "Usage: $0 MACHINE NODE"
          exit 1
      fi
      
      uid=$(echo $node | cut -f1 -d':')
      node_name=$(echo $node | cut -f2 -d':')
      
      oc proxy &
      proxy_pid=$!
      function kill_proxy {
          kill $proxy_pid
      }
      trap kill_proxy EXIT SIGINT
      
      HOST_PROXY_API_PATH="http://localhost:8001/apis/metal3.io/v1alpha1/namespaces/openshift-machine-api/baremetalhosts"
      
      function wait_for_json() {
          local name
          local url
          local curl_opts
          local timeout
      
          local start_time
          local curr_time
          local time_diff
      
          name="$1"
          url="$2"
          timeout="$3"
          shift 3
          curl_opts="$@"
          echo -n "Waiting for $name to respond"
          start_time=$(date +%s)
          until curl -g -X GET "$url" "${curl_opts[@]}" 2> /dev/null | jq '.' 2> /dev/null > /dev/null; do
              echo -n "."
              curr_time=$(date +%s)
              time_diff=$(($curr_time - $start_time))
              if [[ $time_diff -gt $timeout ]]; then
                  echo "\nTimed out waiting for $name"
                  return 1
              fi
              sleep 5
          done
          echo " Success!"
          return 0
      }
      wait_for_json oc_proxy "${HOST_PROXY_API_PATH}" 10 -H "Accept: application/json" -H "Content-Type: application/json"
      
      addresses=$(oc get node -n openshift-machine-api ${node_name} -o json | jq -c '.status.addresses')
      
      machine_data=$(oc get machine -n openshift-machine-api -o json ${machine})
      host=$(echo "$machine_data" | jq '.metadata.annotations["metal3.io/BareMetalHost"]' | cut -f2 -d/ | sed 's/"//g')
      
      if [ -z "$host" ]; then
          echo "Machine $machine is not linked to a host yet." 1>&2
          exit 1
      fi
      
      # The address structure on the host doesn't match the node, so extract
      # the values we want into separate variables so we can build the patch
      # we need.
      hostname=$(echo "${addresses}" | jq '.[] | select(. | .type == "Hostname") | .address' | sed 's/"//g')
      ipaddr=$(echo "${addresses}" | jq '.[] | select(. | .type == "InternalIP") | .address' | sed 's/"//g')
      
      host_patch='
      {
        "status": {
          "hardware": {
            "hostname": "'${hostname}'",
            "nics": [
              {
                "ip": "'${ipaddr}'",
                "mac": "00:00:00:00:00:00",
                "model": "unknown",
                "speedGbps": 10,
                "vlanId": 0,
                "pxe": true,
                "name": "eth1"
              }
            ],
            "systemVendor": {
              "manufacturer": "Red Hat",
              "productName": "product name",
              "serialNumber": ""
            },
            "firmware": {
              "bios": {
                "date": "04/01/2014",
                "vendor": "SeaBIOS",
                "version": "1.11.0-2.el7"
              }
            },
            "ramMebibytes": 0,
            "storage": [],
            "cpu": {
              "arch": "x86_64",
              "model": "Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz",
              "clockMegahertz": 2199.998,
              "count": 4,
              "flags": []
            }
          }
        }
      }
      '
      
      echo "PATCHING HOST"
      echo "${host_patch}" | jq .
      
      curl -s \
           -X PATCH \
           ${HOST_PROXY_API_PATH}/${host}/status \
           -H "Content-type: application/merge-patch+json" \
           -d "${host_patch}"
      
      oc get baremetalhost -n openshift-machine-api -o yaml "${host}"

      $ bash link-machine-and-node.sh custom-master3 worker-5

4. etcd メンバーを確認します。

   $ oc rsh -n openshift-etcd etcd-worker-2
   etcdctl member list -w table

   出力例

   +--------+---------+--------+--------------+--------------+---------+
   |   ID   |  STATUS |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
   +--------+---------+--------+--------------+--------------+---------+
   |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
   |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
   |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
   +--------+---------+--------+--------------+--------------+---------+

5. etcd-operator 設定がすべてのノードに適用されていることを確認します。

   $ oc get clusteroperator etcd

   出力例

   NAME   VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
   etcd   4.11.5    True        False         False      5h54m

6. etcd-operator の正常性を確認します。

   $ oc rsh -n openshift-etcd etcd-worker-0
   etcdctl endpoint health

   出力例

   192.168.111.26 is healthy: committed proposal: took = 11.297561ms
   192.168.111.25 is healthy: committed proposal: took = 13.892416ms
   192.168.111.28 is healthy: committed proposal: took = 11.870755ms

7. ノードの正常性を確認します。

   $ oc get Nodes

   出力例

   NAME       STATUS   ROLES    AGE     VERSION
   master-0   Ready    master   6h20m   v1.24.0+3882f8f
   worker-1   Ready    worker   6h7m    v1.24.0+3882f8f
   master-2   Ready    master   6h20m   v1.24.0+3882f8f
   master-3   Ready    master   6h4m    v1.24.0+3882f8f
   worker-4   Ready    worker   6h7m    v1.24.0+3882f8f
   master-5   Ready    master   99m     v1.24.0+3882f8f

8. ClusterOperators の正常性を確認します。

   $ oc get ClusterOperators

   出力例

   NAME                                      VERSION AVAILABLE PROGRESSING DEGRADED SINCE MSG
   authentication                            4.11.5  True      False       False    5h57m
   baremetal                                 4.11.5  True      False       False    6h19m
   cloud-controller-manager                  4.11.5  True      False       False    6h20m
   cloud-credential                          4.11.5  True      False       False    6h23m
   cluster-autoscaler                        4.11.5  True      False       False    6h18m
   config-operator                           4.11.5  True      False       False    6h19m
   console                                   4.11.5  True      False       False    6h4m
   csi-snapshot-controller                   4.11.5  True      False       False    6h19m
   dns                                       4.11.5  True      False       False    6h18m
   etcd                                      4.11.5  True      False       False    6h17m
   image-registry                            4.11.5  True      False       False    6h7m
   ingress                                   4.11.5  True      False       False    6h6m
   insights                                  4.11.5  True      False       False    6h12m
   kube-apiserver                            4.11.5  True      False       False    6h16m
   kube-controller-manager                   4.11.5  True      False       False    6h16m
   kube-scheduler                            4.11.5  True      False       False    6h16m
   kube-storage-version-migrator             4.11.5  True      False       False    6h19m
   machine-api                               4.11.5  True      False       False    6h15m
   machine-approver                          4.11.5  True      False       False    6h19m
   machine-config                            4.11.5  True      False       False    6h18m
   marketplace                               4.11.5  True      False       False    6h18m
   monitoring                                4.11.5  True      False       False    6h4m
   network                                   4.11.5  True      False       False    6h20m
   node-tuning                               4.11.5  True      False       False    6h18m
   openshift-apiserver                       4.11.5  True      False       False    6h8m
   openshift-controller-manager              4.11.5  True      False       False    6h7m
   openshift-samples                         4.11.5  True      False       False    6h12m
   operator-lifecycle-manager                4.11.5  True      False       False    6h18m
   operator-lifecycle-manager-catalog        4.11.5  True      False       False    6h19m
   operator-lifecycle-manager-pkgsvr         4.11.5  True      False       False    6h12m
   service-ca                                4.11.5  True      False       False    6h19m
   storage                                   4.11.5  True      False       False    6h19m

9. ClusterVersion を確認します。

   $ oc get ClusterVersion

   出力例

   NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
   version   4.11.5    True        False         5h57m   Cluster version is 4.11.5

10. 古いコントロールプレーンノードを削除します。

    1. BareMetalHost CR を削除します。

       $ oc delete bmh -n openshift-machine-api custom-master3

    2. Machine が正常でないことを確認します。

       $ oc get machine -A

       出力例

       NAMESPACE              NAME                              PHASE    AGE
       openshift-machine-api  custom-master3                    Running  14h
       openshift-machine-api  test-day2-1-6qv96-master-0        Failed   20h
       openshift-machine-api  test-day2-1-6qv96-master-1        Running  20h
       openshift-machine-api  test-day2-1-6qv96-master-2        Running  20h
       openshift-machine-api  test-day2-1-6qv96-worker-0-8w7vr  Running  19h
       openshift-machine-api  test-day2-1-6qv96-worker-0-rxddj  Running  19h

    3. Machine CR を削除します。

       $ oc delete machine -n openshift-machine-api   test-day2-1-6qv96-master-0
       machine.machine.openshift.io "test-day2-1-6qv96-master-0" deleted

    4. Node CR の削除を確認します。

       $ oc get nodes

       出力例

       NAME       STATUS   ROLES    AGE   VERSION
       worker-1   Ready    worker   19h   v1.24.0+3882f8f
       master-2   Ready    master   20h   v1.24.0+3882f8f
       master-3   Ready    master   19h   v1.24.0+3882f8f
       worker-4   Ready    worker   19h   v1.24.0+3882f8f
       master-5   Ready    master   15h   v1.24.0+3882f8f

11. etcd-operator ログをチェックして、etcd クラスターのステータスを確認します。

    $ oc logs -n openshift-etcd-operator etcd-operator-8668df65d-lvpjf

    出力例

    E0927 07:53:10.597523       1 base_controller.go:272] ClusterMemberRemovalController reconciliation failed: cannot remove member: 192.168.111.23 because it is reported as healthy but it doesn't have a machine nor a node resource

12. 物理マシンを削除して、etcd-operator がクラスターメンバーを調整できるようにします。

    $ oc rsh -n openshift-etcd etcd-worker-2
    etcdctl member list -w table; etcdctl endpoint health

    出力例

    +--------+---------+--------+--------------+--------------+---------+
    |   ID   |  STATUS |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
    +--------+---------+--------+--------------+--------------+---------+
    |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
    |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
    |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
    +--------+---------+--------+--------------+--------------+---------+
    192.168.111.26 is healthy: committed proposal: took = 10.458132ms
    192.168.111.25 is healthy: committed proposal: took = 11.047349ms
    192.168.111.28 is healthy: committed proposal: took = 11.414402ms

手順

1. クラスターの初期状態を確認します。

   $ oc get nodes

   出力例

   NAME       STATUS     ROLES    AGE   VERSION
   worker-1   Ready      worker   20h   v1.24.0+3882f8f
   master-2   NotReady   master   20h   v1.24.0+3882f8f
   master-3   Ready      master   20h   v1.24.0+3882f8f
   worker-4   Ready      worker   20h   v1.24.0+3882f8f
   master-5   Ready      master   15h   v1.24.0+3882f8f

2. etcd-operator がクラスターを正常ではないと検出していることを確認します。

   $ oc logs -n openshift-etcd-operator etcd-operator-8668df65d-lvpjf

   出力例

   E0927 08:24:23.983733       1 base_controller.go:272] DefragController reconciliation failed: cluster is unhealthy: 2 of 3 members are available, worker-2 is unhealthy

3. etcdctl メンバーを確認します。

   $ oc rsh -n openshift-etcd etcd-worker-3
   etcdctl member list -w table

   出力例

   +--------+---------+--------+--------------+--------------+---------+
   |   ID   | STATUS  |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
   +--------+---------+--------+--------------+--------------+---------+
   |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
   |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
   |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
   +--------+---------+--------+--------------+--------------+---------+

4. etcdctl がクラスターの正常でないメンバーを報告していることを確認します。

   $ etcdctl endpoint health

   出力例

   {"level":"warn","ts":"2022-09-27T08:25:35.953Z","logger":"client","caller":"v3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc000680380/192.168.111.25","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 192.168.111.25: connect: no route to host\""}
   192.168.111.28 is healthy: committed proposal: took = 12.465641ms
   192.168.111.26 is healthy: committed proposal: took = 12.297059ms
   192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceeded
   Error: unhealthy cluster

5. Machine カスタムリソースを削除して、正常でないコントロールプレーンを削除します。

   $ oc delete machine -n openshift-machine-api test-day2-1-6qv96-master-2

   注記

   正常でないクラスターを正常に実行できない場合、Machine および Node のカスタムリソース (CR) は削除されません。

6. etcd-operator が正常でないマシンを削除していないことを確認します。

   $ oc logs -n openshift-etcd-operator etcd-operator-8668df65d-lvpjf -f

   出力例

   I0927 08:58:41.249222       1 machinedeletionhooks.go:135] skip removing the deletion hook from machine test-day2-1-6qv96-master-2 since its member is still present with any of: [{InternalIP } {InternalIP 192.168.111.26}]

7. 正常でない etcdctl メンバーを手動で削除します。

   $ oc rsh -n openshift-etcd etcd-worker-3\
   etcdctl member list -w table

   出力例

   +--------+---------+--------+--------------+--------------+---------+
   |   ID   |  STATUS |  NAME  |  PEER ADDRS  | CLIENT ADDRS | LEARNER |
   +--------+---------+--------+--------------+--------------+---------+
   |2c18942f| started |worker-3|192.168.111.26|192.168.111.26|  false  |
   |61e2a860| started |worker-2|192.168.111.25|192.168.111.25|  false  |
   |ead4f280| started |worker-5|192.168.111.28|192.168.111.28|  false  |
   +--------+---------+--------+--------------+--------------+---------+

8. etcdctl がクラスターの正常でないメンバーを報告していることを確認します。

   $ etcdctl endpoint health

   出力例

   {"level":"warn","ts":"2022-09-27T10:31:07.227Z","logger":"client","caller":"v3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0000d6e00/192.168.111.25","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = latest balancer error: last connection error: connection error: desc = \"transport: Error while dialing dial tcp 192.168.111.25: connect: no route to host\""}
   192.168.111.28 is healthy: committed proposal: took = 13.038278ms
   192.168.111.26 is healthy: committed proposal: took = 12.950355ms
   192.168.111.25 is unhealthy: failed to commit proposal: context deadline exceeded
   Error: unhealthy cluster

9. etcdctl メンバーのカスタムリソースを削除して正常でないクラスターを削除します。

   $ etcdctl member remove 61e2a86084aafa62

   出力例

   Member 61e2a86084aafa62 removed from cluster 6881c977b97990d7

10. 次のコマンドを実行して etcdctl のメンバーを確認します。

    $ etcdctl member list -w table

    出力例

    +----------+---------+--------+--------------+--------------+-------+
    |    ID    | STATUS  |  NAME  |  PEER ADDRS  | CLIENT ADDRS |LEARNER|
    +----------+---------+--------+--------------+--------------+-------+
    | 2c18942f | started |worker-3|192.168.111.26|192.168.111.26| false |
    | ead4f280 | started |worker-5|192.168.111.28|192.168.111.28| false |
    +----------+---------+--------+--------------+--------------+-------+

11. 証明書署名要求を確認して承認します。

    1. 証明書署名要求 (CSR) を確認します。

       $ oc get csr | grep Pending

       出力例

       csr-5sd59   8m19s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   <none>              Pending
       csr-xzqts   10s     kubernetes.io/kubelet-serving                 system:node:worker-6                                                   <none>              Pending

    2. 保留中の 全 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

       注記

       インストールを完了するには、CSR を承認する必要があります。

12. コントロールプレーンノードが Ready ステータスであることを確認します。

    $ oc get nodes

    出力例

    NAME       STATUS   ROLES    AGE     VERSION
    worker-1   Ready    worker   22h     v1.24.0+3882f8f
    master-3   Ready    master   22h     v1.24.0+3882f8f
    worker-4   Ready    worker   22h     v1.24.0+3882f8f
    master-5   Ready    master   17h     v1.24.0+3882f8f
    master-6   Ready    master   2m52s   v1.24.0+3882f8f

13. Machine、Node、および BareMetalHost カスタムリソースを検証します。

    機能する Machine API を使用してクラスターを実行する場合、etcd-operator に Machine CR が存在する必要があります。Machine CR は、存在する場合は Running フェーズ中に表示されます。

14. BareMetalHost および Node にリンクされた Machine カスタムリソースを作成します。

    新しく追加されたノードを参照する Machine CR があることを確認します。

    重要

    Boot-it-yourself では BareMetalHost および Machine CR は作成されないため、これらを作成する必要があります。BareMetalHost および Machine CR の作成に失敗すると、etcd-operator の実行時にエラーが生成されます。

15. BareMetalHost カスタムリソースを追加します。

    $ oc create bmh -n openshift-machine-api custom-master3

16. Machine カスタムリソースを追加します。

    $ oc create machine -n openshift-machine-api custom-master3

17. link-machine-and-node.sh スクリプトを実行して、BareMetalHost、Machine、および Node をリンクします。

    #!/bin/bash
    
    # Credit goes to https://bugzilla.redhat.com/show_bug.cgi?id=1801238.
    # This script will link Machine object and Node object. This is needed
    # in order to have IP address of the Node present in the status of the Machine.
    
    set -x
    set -e
    
    machine="$1"
    node="$2"
    
    if [ -z "$machine" -o -z "$node" ]; then
        echo "Usage: $0 MACHINE NODE"
        exit 1
    fi
    
    uid=$(echo $node | cut -f1 -d':')
    node_name=$(echo $node | cut -f2 -d':')
    
    oc proxy &
    proxy_pid=$!
    function kill_proxy {
        kill $proxy_pid
    }
    trap kill_proxy EXIT SIGINT
    
    HOST_PROXY_API_PATH="http://localhost:8001/apis/metal3.io/v1alpha1/namespaces/openshift-machine-api/baremetalhosts"
    
    function wait_for_json() {
        local name
        local url
        local curl_opts
        local timeout
    
        local start_time
        local curr_time
        local time_diff
    
        name="$1"
        url="$2"
        timeout="$3"
        shift 3
        curl_opts="$@"
        echo -n "Waiting for $name to respond"
        start_time=$(date +%s)
        until curl -g -X GET "$url" "${curl_opts[@]}" 2> /dev/null | jq '.' 2> /dev/null > /dev/null; do
            echo -n "."
            curr_time=$(date +%s)
            time_diff=$(($curr_time - $start_time))
            if [[ $time_diff -gt $timeout ]]; then
                echo "\nTimed out waiting for $name"
                return 1
            fi
            sleep 5
        done
        echo " Success!"
        return 0
    }
    wait_for_json oc_proxy "${HOST_PROXY_API_PATH}" 10 -H "Accept: application/json" -H "Content-Type: application/json"
    
    addresses=$(oc get node -n openshift-machine-api ${node_name} -o json | jq -c '.status.addresses')
    
    machine_data=$(oc get machine -n openshift-machine-api -o json ${machine})
    host=$(echo "$machine_data" | jq '.metadata.annotations["metal3.io/BareMetalHost"]' | cut -f2 -d/ | sed 's/"//g')
    
    if [ -z "$host" ]; then
        echo "Machine $machine is not linked to a host yet." 1>&2
        exit 1
    fi
    
    # The address structure on the host doesn't match the node, so extract
    # the values we want into separate variables so we can build the patch
    # we need.
    hostname=$(echo "${addresses}" | jq '.[] | select(. | .type == "Hostname") | .address' | sed 's/"//g')
    ipaddr=$(echo "${addresses}" | jq '.[] | select(. | .type == "InternalIP") | .address' | sed 's/"//g')
    
    host_patch='
    {
      "status": {
        "hardware": {
          "hostname": "'${hostname}'",
          "nics": [
            {
              "ip": "'${ipaddr}'",
              "mac": "00:00:00:00:00:00",
              "model": "unknown",
              "speedGbps": 10,
              "vlanId": 0,
              "pxe": true,
              "name": "eth1"
            }
          ],
          "systemVendor": {
            "manufacturer": "Red Hat",
            "productName": "product name",
            "serialNumber": ""
          },
          "firmware": {
            "bios": {
              "date": "04/01/2014",
              "vendor": "SeaBIOS",
              "version": "1.11.0-2.el7"
            }
          },
          "ramMebibytes": 0,
          "storage": [],
          "cpu": {
            "arch": "x86_64",
            "model": "Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz",
            "clockMegahertz": 2199.998,
            "count": 4,
            "flags": []
          }
        }
      }
    }
    '
    
    echo "PATCHING HOST"
    echo "${host_patch}" | jq .
    
    curl -s \
         -X PATCH \
         ${HOST_PROXY_API_PATH}/${host}/status \
         -H "Content-type: application/merge-patch+json" \
         -d "${host_patch}"
    
    oc get baremetalhost -n openshift-machine-api -o yaml "${host}"

    $ bash link-machine-and-node.sh custom-master3 worker-3

18. 次のコマンドを実行して etcdctl のメンバーを確認します。

    $ oc rsh -n openshift-etcd etcd-worker-3
    etcdctl member list -w table

    出力例

    +---------+-------+--------+--------------+--------------+-------+
    |   ID    | STATUS|  NAME  |   PEER ADDRS | CLIENT ADDRS |LEARNER|
    +---------+-------+--------+--------------+--------------+-------+
    | 2c18942f|started|worker-3|192.168.111.26|192.168.111.26| false |
    | ead4f280|started|worker-5|192.168.111.28|192.168.111.28| false |
    | 79153c5a|started|worker-6|192.168.111.29|192.168.111.29| false |
    +---------+-------+--------+--------------+--------------+-------+

19. etcd Operator がすべてのノードを設定したことを確認します。

    $ oc get clusteroperator etcd

    出力例

    NAME   VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    etcd   4.11.5    True        False         False      22h

20. etcdctl の正常性を確認します。

    $ oc rsh -n openshift-etcd etcd-worker-3
    etcdctl endpoint health

    出力例

    192.168.111.26 is healthy: committed proposal: took = 9.105375ms
    192.168.111.28 is healthy: committed proposal: took = 9.15205ms
    192.168.111.29 is healthy: committed proposal: took = 10.277577ms

21. ノードの正常性を確認します。

    $ oc get Nodes

    出力例

    NAME       STATUS   ROLES    AGE   VERSION
    worker-1   Ready    worker   22h   v1.24.0+3882f8f
    master-3   Ready    master   22h   v1.24.0+3882f8f
    worker-4   Ready    worker   22h   v1.24.0+3882f8f
    master-5   Ready    master   18h   v1.24.0+3882f8f
    master-6   Ready    master   40m   v1.24.0+3882f8f

22. ClusterOperators の正常性を確認します。

    $ oc get ClusterOperators

    出力例

    NAME                               VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                     4.11.5    True        False         False      150m
    baremetal                          4.11.5    True        False         False      22h
    cloud-controller-manager           4.11.5    True        False         False      22h
    cloud-credential                   4.11.5    True        False         False      22h
    cluster-autoscaler                 4.11.5    True        False         False      22h
    config-operator                    4.11.5    True        False         False      22h
    console                            4.11.5    True        False         False      145m
    csi-snapshot-controller            4.11.5    True        False         False      22h
    dns                                4.11.5    True        False         False      22h
    etcd                               4.11.5    True        False         False      22h
    image-registry                     4.11.5    True        False         False      22h
    ingress                            4.11.5    True        False         False      22h
    insights                           4.11.5    True        False         False      22h
    kube-apiserver                     4.11.5    True        False         False      22h
    kube-controller-manager            4.11.5    True        False         False      22h
    kube-scheduler                     4.11.5    True        False         False      22h
    kube-storage-version-migrator      4.11.5    True        False         False      148m
    machine-api                        4.11.5    True        False         False      22h
    machine-approver                   4.11.5    True        False         False      22h
    machine-config                     4.11.5    True        False         False      110m
    marketplace                        4.11.5    True        False         False      22h
    monitoring                         4.11.5    True        False         False      22h
    network                            4.11.5    True        False         False      22h
    node-tuning                        4.11.5    True        False         False      22h
    openshift-apiserver                4.11.5    True        False         False      163m
    openshift-controller-manager       4.11.5    True        False         False      22h
    openshift-samples                  4.11.5    True        False         False      22h
    operator-lifecycle-manager         4.11.5    True        False         False      22h
    operator-lifecycle-manager-catalog 4.11.5    True        False         False      22h
    operator-lifecycle-manager-pkgsvr  4.11.5    True        False         False      22h
    service-ca                         4.11.5    True        False         False      22h
    storage                            4.11.5    True        False         False      22h

23. ClusterVersion を確認します。

    $ oc get ClusterVersion

    出力例

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    version   4.11.5    True        False         22h     Cluster version is 4.11.5

手順

1. Cluster details の Integrate with external partner platforms ドロップダウンリストから Nutanix を選択します。Include custom manifest チェックボックスはオプションです。
2. Host discovery で、Add hosts ボタンをクリックします。

3. core ユーザーとして Nutanix 仮想マシンに接続できるように、SSH 公開鍵を追加します。クラスターホストにログインすると、インストール中にデバッグ情報を入手できます。

   1. ローカルマシンに既存の SSH キーペアがない場合は、クラスターノード SSH アクセス用のキーペアの生成 の手順に従います。
   2. SSH public key フィールドで Browse をクリックして、SSH 公開鍵を含む id_rsa.pub ファイルをアップロードします。または、ファイルマネージャーからフィールドにファイルをドラッグアンドドロップします。ファイルマネージャーでファイルを表示するには、メニューで 非表示ファイル を表示を選択します。

4. 必要なプロビジョニングタイプを選択します。

   注記

   最小イメージファイル：仮想メディアのプロビジョニング は、起動に必要なデータを取得する小さなイメージをダウンロードします。

5. Networking で、Cluster-managed networking を選択します。Nutanix はユーザー 管理のネットワークをサポートしません。

   1. オプション: クラスターホストがプロキシーの使用を必要とするファイアウォールの内側にある場合は、Configure cluster-wide proxy settings を選択します。プロキシーサーバーの HTTP および HTTPS URL のユーザー名、パスワード、IP アドレス、およびポートを入力します。
   2. オプション: Ignition ファイルを使用して起動する場合は、検出イメージを設定します。詳しくは、検出イメージの設定 を参照してください。
6. Generate Discovery ISO をクリックします。
7. Discovery ISO URL をコピーします。
8. Nutanix Prism UI で、指示に従って Assisted Installer から検出イメージをアップロード します。

9. Nutanix Prism UI で、Prism Central を介して コントロールプレーン (マスター) 仮想マシンを作成します。

   1. Name を入力します。たとえば、control-plane または master と入力します。
   2. Number of VMs を入力します。これは、コントロールプレーンの場合は 3 である必要があります。
   3. 残りの設定がコントロールプレーンホストの最小要件を満たしていることを確認します。

10. Nutanix Prism UI で、Prism Central を介して ワーカー仮想マシンを作成します。

    1. Name を入力します。たとえば、worker と入力します。
    2. Number of VMs を入力します。少なくとも 2 つのワーカーノードを作成する必要があります。
    3. 残りの設定がワーカーホストの最小要件を満たしていることを確認します。
11. Assisted Installer のユーザーインターフェイスに戻り、Assisted Installer がホストを検出し、それぞれが Ready ステータスになるまで待ちます。
12. インストール手順を続行します。

手順

1. Ignition ファイルを使用して起動する場合は、検出イメージを設定します。

2. 環境変数を保持する Nutanix クラスター設定ファイルを作成します。

   $ touch ~/nutanix-cluster-env.sh

   $ chmod +x ~/nutanix-cluster-env.sh

   新しいターミナルセッションを開始する必要がある場合は、環境変数を簡単に再読み込みできます。以下に例を示します。

   $ source ~/nutanix-cluster-env.sh

3. Nutanix クラスターの名前を設定ファイルの NTX_CLUSTER_NAME 環境変数に割り当てます。

   $ cat << EOF >> ~/nutanix-cluster-env.sh
   export NTX_CLUSTER_NAME=<cluster_name>
   EOF

   <cluster_name> を Nutanix クラスターの名前に置き換えます。

4. Nutanix クラスターのサブネット名を設定ファイルの NTX_SUBNET_NAME 環境変数に割り当てます。

   $ cat << EOF >> ~/nutanix-cluster-env.sh
   export NTX_SUBNET_NAME=<subnet_name>
   EOF

   <subnet_name> を Nutanix クラスターのサブネットの名前に置き換えます。

5. API トークンを更新します。

   $ source refresh-token

6. ダウンロード URL を取得します。

   $ curl -H "Authorization: Bearer ${API_TOKEN}" \
   https://api.openshift.com/api/assisted-install/v2/infra-envs/${INFRA_ENV_ID}/downloads/image-url

7. Nutanix イメージ設定ファイルを作成します。

   $ cat << EOF > create-image.json
   {
     "spec": {
       "name": "ocp_ai_discovery_image.iso",
       "description": "ocp_ai_discovery_image.iso",
       "resources": {
         "architecture": "X86_64",
         "image_type": "ISO_IMAGE",
         "source_uri": "<image_url>",
         "source_options": {
           "allow_insecure_connection": true
         }
       }
     },
     "metadata": {
       "spec_version": 3,
       "kind": "image"
     }
   }
   EOF

   <image_url> を、前の手順でダウンロードしたイメージの URL に置き換えます。

8. Nutanix イメージを作成します。

   $ curl  -k -u <user>:'<password>' -X 'POST' \
   'https://<domain-or-ip>:<port>/api/nutanix/v3/images \
     -H 'accept: application/json' \
     -H 'Content-Type: application/json' \
     -d @./create-image.json | jq '.metadata.uuid'

   <user> を Nutanix ユーザー名に置き換えます。'<password>' を Nutanix パスワードに置き換えます。<domain-or-ip> を Nutanix プラットフォームのドメイン名または IP アドレスに置き換えます。<port> を Nutanix サーバーのポートに置き換えます。ポートのデフォルトは 9440 です。

9. 返された UUID を設定ファイルの NTX_IMAGE_UUID 環境変数に割り当てます。

   $ cat << EOF >> ~/nutanix-cluster-env.sh
   export NTX_IMAGE_UUID=<uuid>
   EOF

10. Nutanix クラスターの UUID を取得します。

    $ curl -k -u <user>:'<password>' -X 'POST' \
      'https://<domain-or-ip>:<port>/api/nutanix/v3/clusters/list' \
      -H 'accept: application/json' \
      -H 'Content-Type: application/json' \
      -d '{
      "kind": "cluster"
    }'  | jq '.entities[] | select(.spec.name=="<nutanix_cluster_name>") | .metadata.uuid'

    <user> を Nutanix ユーザー名に置き換えます。'<password>' を Nutanix パスワードに置き換えます。<domain-or-ip> を Nutanix プラットフォームのドメイン名または IP アドレスに置き換えます。<port> を Nutanix サーバーのポートに置き換えます。ポートのデフォルトは 9440 です。<nutanix_cluster_name> を Nutanix クラスターの名前に置き換えます。

11. 返された Nutanix クラスター UUID を設定ファイルの NTX_CLUSTER_UUID 環境変数に割り当てます。

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_CLUSTER_UUID=<uuid>
    EOF

    <uuid> を Nutanix クラスターの返された UUID に置き換えます。

12. Nutanix クラスターのサブネット UUID を取得します。

    $ curl -k -u <user>:'<password>' -X 'POST' \
      'https://<domain-or-ip>:<port>/api/nutanix/v3/subnets/list' \
      -H 'accept: application/json' \
      -H 'Content-Type: application/json' \
      -d '{
      "kind": "subnet",
      "filter": "name==<subnet_name>"
    }' | jq '.entities[].metadata.uuid'

    <user> を Nutanix ユーザー名に置き換えます。'<password>' を Nutanix パスワードに置き換えます。<domain-or-ip> を Nutanix プラットフォームのドメイン名または IP アドレスに置き換えます。<port> を Nutanix サーバーのポートに置き換えます。ポートのデフォルトは 9440 です。<subnet_name> をクラスターのサブネットの名前に置き換えます。

13. 返された Nutanix サブネット UUID を設定ファイルの NTX_CLUSTER_UUID 環境変数に割り当てます。

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_SUBNET_UUID=<uuid>
    EOF

    <uuid> をクラスターサブネットの返された UUID に置き換えます。

14. Nutanix 環境変数が設定されていることを確認します。

    $ source ~/nutanix-cluster-env.sh

15. Nutanix ホストごとに仮想マシン設定ファイルを作成します。3 つのコントロールプレーン (マスター) 仮想マシンと少なくとも 2 つのワーカー仮想マシンを作成します。以下に例を示します。

    $ touch create-master-0.json

    $ cat << EOF > create-master-0.json
    {
       "spec": {
          "name": "<host_name>",
          "resources": {
             "power_state": "ON",
             "num_vcpus_per_socket": 1,
             "num_sockets": 16,
             "memory_size_mib": 32768,
             "disk_list": [
                {
                   "disk_size_mib": 122880,
                   "device_properties": {
                      "device_type": "DISK"
                   }
                },
                {
                   "device_properties": {
                      "device_type": "CDROM"
                   },
                   "data_source_reference": {
                     "kind": "image",
                     "uuid": "$NTX_IMAGE_UUID"
                  }
                }
             ],
             "nic_list": [
                {
                   "nic_type": "NORMAL_NIC",
                   "is_connected": true,
                   "ip_endpoint_list": [
                      {
                         "ip_type": "DHCP"
                      }
                   ],
                   "subnet_reference": {
                      "kind": "subnet",
                      "name": "$NTX_SUBNET_NAME",
                      "uuid": "$NTX_SUBNET_UUID"
                   }
                }
             ],
             "guest_tools": {
                "nutanix_guest_tools": {
                   "state": "ENABLED",
                   "iso_mount_state": "MOUNTED"
                }
             }
          },
          "cluster_reference": {
             "kind": "cluster",
             "name": "$NTX_CLUSTER_NAME",
             "uuid": "$NTX_CLUSTER_UUID"
          }
       },
       "api_version": "3.1.0",
       "metadata": {
          "kind": "vm"
       }
    }
    EOF

    <host_name> をホストの名前に置き換えます。

16. 各 Nutanix 仮想マシンを起動します。

    $ curl -k -u <user>:'<password>' -X 'POST' \
      'https://<domain-or-ip>:<port>/api/nutanix/v3/vms' \
      -H 'accept: application/json' \
      -H 'Content-Type: application/json' \
      -d @./<vm_config_file_name> | jq '.metadata.uuid'

    <user> を Nutanix ユーザー名に置き換えます。'<password>' を Nutanix パスワードに置き換えます。<domain-or-ip> を Nutanix プラットフォームのドメイン名または IP アドレスに置き換えます。<port> を Nutanix サーバーのポートに置き換えます。ポートのデフォルトは 9440 です。<vm_config_file_name> を仮想マシン設定ファイルの名前に置き換えます。

17. 返された仮想マシン UUID を設定ファイル内の一意の環境変数に割り当てます。

    $ cat << EOF >> ~/nutanix-cluster-env.sh
    export NTX_MASTER_0_UUID=<uuid>
    EOF

    <uuid> を仮想マシンの返された UUID に置き換えます。

    注記

    環境変数には、仮想マシンごとの一意の名前が必要です。

18. Assisted Installer が各仮想マシンを検出し、検証にパスするまで待ちます。

    $ curl -s -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID"
    --header "Content-Type: application/json"
    -H "Authorization: Bearer $API_TOKEN"
    | jq '.enabled_host_count'

19. クラスター定義を変更して、Nutanix との統合を有効にします。

    $ curl https://api.openshift.com/api/assisted-install/v2/clusters/${CLUSTER_ID} \
    -X PATCH \
    -H "Authorization: Bearer ${API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '
    {
        "platform_type":"nutanix"
    }
    ' | jq

20. インストール手順を続行します。

手順

1. Ignition ファイルを使用して起動する場合は、検出イメージを設定します。
2. Cluster details の Integrate with external partner platforms ドロップダウンリストから vSphere を選択します。Include custom manifest チェックボックスはオプションです。
3. Host discovery で、Add hosts ボタンをクリックし、プロビジョニングタイプを選択します。

4. core ユーザーとして vSphere 仮想マシンに接続できるように、SSH 公開鍵を追加します。クラスターホストにログインすると、インストール中にデバッグ情報を入手できます。

   1. ローカルマシンに既存の SSH キーペアがない場合は、クラスターノード SSH アクセス用のキーペアの生成 の手順に従います。
   2. SSH public key フィールドで Browse をクリックして、SSH 公開鍵を含む id_rsa.pub ファイルをアップロードします。または、ファイルマネージャーからフィールドにファイルをドラッグアンドドロップします。ファイルマネージャーでファイルを表示するには、メニューで 非表示ファイル を表示を選択します。

5. 目的の検出イメージ ISO を選択します。

   注記

   最小イメージファイル：仮想メディアのプロビジョニング は、起動に必要なデータを取得する小さなイメージをダウンロードします。

6. Networking で、Cluster-managed networking または User-managed networking を選択します。

   1. オプション: クラスターホストがプロキシーの使用を必要とするファイアウォールの内側にある場合は、Configure cluster-wide proxy settings を選択します。プロキシーサーバーの HTTP および HTTPS URL のユーザー名、パスワード、IP アドレス、およびポートを入力します。
   2. オプション: クラスターホストが再暗号化中間者 (MITM) プロキシーを使用するネットワーク内にある場合、またはクラスターがコンテナーイメージレジストリーなどの他の目的で証明書を信頼する必要がある場合は、Configure cluster-wide trusted certificates を選択し、追加の証明書を追加します。
   3. オプション: Ignition ファイルを使用して起動する場合は、検出イメージを設定します。詳しくは、検出イメージの設定 を参照してください。
7. Generate Discovery ISO をクリックします。
8. Discovery ISO URL をコピーします。

9. 検出 ISO をダウンロードします。

   $ wget - O vsphere-discovery-image.iso <discovery_url>

   &lt ;discovery_url&gt; を前の手順の Discovery ISO URL に置き換えます。

10. コマンドラインで、電源を落とし、既存の仮想マシンをすべて破棄します。

    $ for VM in $(/usr/local/bin/govc ls /<datacenter>/vm/<folder_name>)
    do
     	/usr/local/bin/govc vm.power -off $VM
     	/usr/local/bin/govc vm.destroy $VM
    done

    <datacenter> をデータセンターの名前に置き換えます。<folder_name> を仮想マシンのインベントリーフォルダーの名前に置き換えます。

11. 既存の ISO イメージがある場合は、データストアから削除します。

    $ govc datastore.rm -ds <iso_datastore> <image>

    <iso_datastore> をデータストアの名前に置き換えます。image を ISO イメージの名前に置き換えます。

12. Assisted Installer の検出 ISO をアップロードします。

    $ govc datastore.upload -ds <iso_datastore>  vsphere-discovery-image.iso

    <iso_datastore> をデータストアの名前に置き換えます。

    注記

    クラスター内のすべてのノードは、検出イメージから起動する必要があります。

13. 3 つのコントロールプレーン (マスター) ノードを起動します。

    $ govc vm.create -net.adapter <network_adapter_type> \
                     -disk.controller <disk_controller_type> \
                     -pool=<resource_pool> \
                     -c=16 \
                     -m=32768 \
                     -disk=120GB \
                     -disk-datastore=<datastore_file> \
                     -net.address="<nic_mac_address>" \
                     -iso-datastore=<iso_datastore> \
                     -iso="vsphere-discovery-image.iso" \
                     -folder="<inventory_folder>" \
                     <hostname>.<cluster_name>.example.com

    詳細は、vm.create を参照してください。

    注記

    前述の例は、コントロールプレーンノードに必要な最小限のリソースを示しています。

14. 少なくとも 2 つのワーカーノードを起動します。

    $ govc vm.create -net.adapter <network_adapter_type> \
                     -disk.controller <disk_controller_type> \
                     -pool=<resource_pool> \
                     -c=4 \
                     -m=8192 \
                     -disk=120GB \
                     -disk-datastore=<datastore_file> \
                     -net.address="<nic_mac_address>" \
                     -iso-datastore=<iso_datastore> \
                     -iso="vsphere-discovery-image.iso" \
                     -folder="<inventory_folder>" \
                     <hostname>.<cluster_name>.example.com

    詳細は、vm.create を参照してください。

    注記

    上記の例は、ワーカーノードに必要な最小限のリソースを示しています。

15. 仮想マシンが実行されていることを確認します。

    $  govc ls /<datacenter>/vm/<folder_name>

    <datacenter> をデータセンターの名前に置き換えます。<folder_name> を仮想マシンのインベントリーフォルダーの名前に置き換えます。

16. 2 分後、仮想マシンをシャットダウンします。

    $ for VM in $(govc ls /<datacenter>/vm/<folder_name>)
    do
         govc vm.power -s=true $VM
    done

    <datacenter> をデータセンターの名前に置き換えます。<folder_name> を仮想マシンのインベントリーフォルダーの名前に置き換えます。

17. disk.enableUUID 設定を TRUE に設定します。

    $ for VM in $(govc ls /<datacenter>/vm/<folder_name>)
    do
         govc vm.change -vm $VM -e disk.enableUUID=TRUE
    done

    <datacenter> をデータセンターの名前に置き換えます。<folder_name> を仮想マシンのインベントリーフォルダーの名前に置き換えます。

    注記

    vSphere で自動スケーリングを有効にするには、すべてのノードで disk.enableUUID を TRUE に設定する必要があります。

18. 仮想マシンを再起動します。

    $  for VM in $(govc ls /<datacenter>/vm/<folder_name>)
    do
         govc vm.power -on=true $VM
    done

    <datacenter> をデータセンターの名前に置き換えます。<folder_name> を仮想マシンのインベントリーフォルダーの名前に置き換えます。

19. Assisted Installer のユーザーインターフェイスに戻り、Assisted Installer がホストを検出し、それぞれが Ready ステータスになるまで待ちます。
20. 必要に応じてロールを選択します。
21. Networking で、Allocate IPs via DHCP server のチェックを外します。
22. API VIP アドレスを設定します。
23. Ingress VIP アドレスを設定します。
24. インストール手順を続行します。

手順

1. vCenter 用の base64 でエンコードされたユーザー名とパスワードを生成します。

   $ echo -n "<vcenter_username>" | base64 -w0

   <vcenter_username> を vCenter ユーザー名に置き換えます。

   $ echo -n "<vcenter_password>" | base64 -w0

   <vcenter_password> を vCenter パスワードに置き換えます。

2. vSphere 認証情報をバックアップします。

   $ oc get secret vsphere-creds -o yaml -n kube-system > creds_backup.yaml

3. vSphere 認証情報を編集します。

   $ cp creds_backup.yaml vsphere-creds.yaml

   $ vi vsphere-creds.yaml

   apiVersion: v1
   data:
     <vcenter_address>.username: <vcenter_username_encoded>
     <vcenter_address>.password: <vcenter_password_encoded>
   kind: Secret
   metadata:
     annotations:
       cloudcredential.openshift.io/mode: passthrough
     creationTimestamp: "2022-01-25T17:39:50Z"
     name: vsphere-creds
     namespace: kube-system
     resourceVersion: "2437"
     uid: 06971978-e3a5-4741-87f9-2ca3602f2658
   type: Opaque

   <vcenter_address> を vCenter アドレスに置き換えます。<vcenter_username_encoded> を base64 でエンコードされたバージョンの vSphere ユーザー名に置き換えます。<vcenter_password_encoded> を base64 でエンコードされたバージョンの vSphere パスワードに置き換えます。

4. vSphere 認証情報を置き換えます。

   $ oc replace -f vsphere-creds.yaml

5. kube-controller-manager Pod を再デプロイします。

   $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

6. vSphere クラウドプロバイダー設定をバックアップします。

   $ oc get cm cloud-provider-config -o yaml -n openshift-config > cloud-provider-config_backup.yaml

7. クラウドプロバイダーの設定を編集します。

   $ cloud-provider-config_backup.yaml cloud-provider-config.yaml

   $ vi cloud-provider-config.yaml

   apiVersion: v1
   data:
     config: |
       [Global]
       secret-name = "vsphere-creds"
       secret-namespace = "kube-system"
       insecure-flag = "1"
   
       [Workspace]
       server = "<vcenter_address>"
       datacenter = "<datacenter>"
       default-datastore = "<datastore>"
       folder = "/<datacenter>/vm/<folder>"
   
       [VirtualCenter "<vcenter_address>"]
       datacenters = "<datacenter>"
   kind: ConfigMap
   metadata:
     creationTimestamp: "2022-01-25T17:40:49Z"
     name: cloud-provider-config
     namespace: openshift-config
     resourceVersion: "2070"
     uid: 80bb8618-bf25-442b-b023-b31311918507

   <vcenter_address> を vCenter アドレスに置き換えます。<datacenter> をデータセンターの名前に置き換えます。<datastore> をデータストアの名前に置き換えます。<folder> をクラスターの仮想マシンを含むフォルダーに置き換えます。

8. クラウドプロバイダーの設定を適用します。

   $ oc apply -f cloud-provider-config.yaml

9. uninitialized テイントでノードをテイントします。

   重要

   OpenShift Container Platform 4.13 以降をインストールする場合は、ステップ 9 から 12 に従います。

   1. テイントするノードを特定します。

      $ oc get nodes

   2. ノードごとに以下のコマンドを実行します。

      $ oc adm taint node <node_name> node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

      <node_name> はノード名に置き換えてください。

   例

   $ oc get nodes
   NAME                STATUS   ROLES                  AGE   VERSION
   master-0   Ready    control-plane,master   45h   v1.26.3+379cd9f
   master-1   Ready    control-plane,master   45h   v1.26.3+379cd9f
   worker-0   Ready    worker                 45h   v1.26.3+379cd9f
   worker-1   Ready    worker                 45h   v1.26.3+379cd9f
   master-2   Ready    control-plane,master   45h   v1.26.3+379cd9f
   
   $ oc adm taint node master-0 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node master-1 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node master-2 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node worker-0 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
   $ oc adm taint node worker-1 node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

10. インフラストラクチャー設定をバックアップします。

    $ oc get infrastructures.config.openshift.io -o yaml > infrastructures.config.openshift.io.yaml.backup

11. インフラストラクチャー設定を編集します。

    $ cp infrastructures.config.openshift.io.yaml.backup infrastructures.config.openshift.io.yaml

    $ vi infrastructures.config.openshift.io.yaml

    apiVersion: v1
    items:
    - apiVersion: config.openshift.io/v1
      kind: Infrastructure
      metadata:
        creationTimestamp: "2022-05-07T10:19:55Z"
        generation: 1
        name: cluster
        resourceVersion: "536"
        uid: e8a5742c-6d15-44e6-8a9e-064b26ab347d
      spec:
        cloudConfig:
          key: config
          name: cloud-provider-config
        platformSpec:
          type: VSphere
          vsphere:
            failureDomains:
            - name: assisted-generated-failure-domain
              region: assisted-generated-region
              server: <vcenter_address>
              topology:
                computeCluster: /<data_center>/host/<vcenter_cluster>
                datacenter: <data_center>
                datastore: /<data_center>/datastore/<datastore>
                folder: "/<data_center>/path/to/folder"
                networks:
                - "VM Network"
                resourcePool: /<data_center>/host/<vcenter_cluster>/Resources
              zone: assisted-generated-zone
            nodeNetworking:
              external: {}
              internal: {}
            vcenters:
            - datacenters:
              - <data_center>
              server: <vcenter_address>
    
    kind: List
    metadata:
      resourceVersion: ""

    <vcenter_address> を vCenter アドレスに置き換えます。<datacenter> を vCenter データセンターの名前に置き換えます。<datastore> を vCenter データストアの名前に置き換えます。<folder> をクラスターの仮想マシンを含むフォルダーに置き換えます。<vcenter_cluster> を、OpenShift Container Platform がインストールされている vSphere vCenter クラスターに置き換えます。

12. インフラストラクチャー設定を適用します。

    $ oc apply -f infrastructures.config.openshift.io.yaml --overwrite=true

手順

1. Administrator パースペクティブで、Home → Overview に移動します。
2. Status で vSphere connection をクリックし、vSphere connection configuration ウィザードを開きます。
3. vCenter フィールドに、vSphere vCenter サーバーのネットワークアドレスを入力します。ドメイン名または IP アドレスのいずれかを入力できます。これは vSphere Web クライアント URL に表示されます (例: https://[your_vCenter_address]/ui)。

4. vCenter クラスター フィールドには、OpenShift Container Platform がインストールされている vSphere vCenter クラスターの名前を入力します。

   重要

   この手順は、OpenShift Container Platform 4.13 以降をインストールしている場合は必須となります。

5. Username フィールドに、vSphere vCenter のユーザー名を入力します。

6. Password フィールドに、vSphere vCenter のパスワードを入力します。

   警告

   システムは、クラスターの kube-system namespace の vsphere-creds シークレットにユーザー名とパスワードを保存します。vCenter のユーザー名またはパスワードが間違っていると、クラスターノードをスケジュールできなくなります。

7. Datacenter フィールドに、クラスターのホストに使用する仮想マシンが含まれる vSphere データセンターの名前を入力します (例: SDDC-Datacenter)。

8. Default data store フィールドに、永続データボリュームを保存する vSphere データストアを入力します (例: /SDDC-Datacenter/datastore/datastorename)。

   警告

   設定の保存後に vSphere データセンターまたはデフォルトのデータストアを更新すると、アクティブな vSphere PersistentVolumes がデタッチされます。

9. Virtual Machine Folder フィールドに、クラスターの仮想マシンが含まれるデータセンターフォルダーを入力します (例: /SDDC-Datacenter/vm/ci-ln-hjg4vg2-c61657-t2gzr)。正常に OpenShift Container Platform をインストールするには、クラスターを構成するすべての仮想マシンを単一のデータセンターフォルダーに配置する必要があります。
10. Save Configuration をクリックします。これにより、openshift-config namespace の cloud-provider-config ファイルが更新され、設定プロセスが開始されます。
11. vSphere connection configuration ウィザードを再度開き、Monitored operators パネルを展開します。Operator のステータスが Progressing または Healthy であることを確認します。

1. 設定プロセスが正常に完了したことを確認します。

   1. OpenShift Container Platform の Administrator パースペクティブで、Home → Overview に移動します。
   2. Status で Operators をクリックします。すべての Operator ステータスが Progressing から All succeeded に変わるまで待機します。Failed ステータスは、設定が失敗したことを示します。
   3. Status で Control Plane をクリックします。すべての Control Pane コンポーネントの応答レートが 100% に戻るまで待機します。Failed コントロールプレーンコンポーネントは、設定が失敗したことを示します。

   失敗は、少なくとも 1 つの接続設定が間違っていることを示します。vSphere connection configuration ウィザードで設定を変更し、その設定を再度保存します。

2. 以下の手順を実行して、PersistentVolumeClaims オブジェクトをバインドできることを確認します。

   1. 以下の YAML を使用して StorageClass オブジェクトを作成します。

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
       name: vsphere-sc
      provisioner: kubernetes.io/vsphere-volume
      parameters:
       datastore: YOURVCENTERDATASTORE
       diskformat: thin
      reclaimPolicy: Delete
      volumeBindingMode: Immediate

   2. 以下の YAML を使用して PersistentVolumeClaims オブジェクトを作成します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
       name: test-pvc
       namespace: openshift-config
       annotations:
         volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume
       finalizers:
         - kubernetes.io/pvc-protection
      spec:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
          storage: 10Gi
       storageClassName: vsphere-sc
       volumeMode: Filesystem

   手順については、OpenShift Container Platform ドキュメントの 動的プロビジョニング を参照してください。PersistentVolumeClaims オブジェクトのトラブルシューティングを行うには、OpenShift Container Platform UI の Administrator パースペクティブで、Storage → Persistent VolumeClaims に移動します。

手順

1. ホストマシンの電源が入っていることを確認します。
2. DHCP ネットワーク を選択した場合は、DHCP サーバーが有効になっていることを確認します。
3. 静的 IP、ブリッジ、および結合 ネットワーキングを選択した場合は、設定が正しいことを確認してください。

4. SSH、BMC などのコンソール、または仮想マシンコンソールを使用してホストマシンにアクセスできることを確認します。

   $ ssh core@<host_ip_address>

   デフォルトディレクトリーに格納されていない場合は、-i パラメーターを使用して秘密鍵ファイルを指定できます。

   $ ssh -i <ssh_private_key_file> core@<host_ip_address>

   ホストへの ssh に失敗した場合、ホストは起動中に失敗したか、ネットワークの設定に失敗しました。

   ログインすると、次のメッセージが表示されます。

   ログイン例

   このメッセージが表示されない場合は、ホストが assisted-installer ISO で起動されなかったことを意味します。起動順序を正しく設定したことを確認してください (ホストは live-ISO から 1 回起動する必要があります)。

5. エージェントサービスログを確認します。

   $ sudo journalctl -u agent.service

   次の例のエラーは、ネットワークに問題があることを示しています。

   エージェントサービスログの例 エージェントサービスログのスクリーンショット

   

   エージェントイメージのプルでエラーが発生した場合は、プロキシー設定を確認してください。ホストがネットワークに接続されていることを確認します。nmcli を使用して、ネットワーク設定に関する追加情報を取得できます。