手順

1. Red Hat Hybrid Cloud コンソール にログインします。
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 には、デフォルトのプラットフォーム統合はありません。

    注記

    各外部パートナー統合の詳細は、関連情報 を参照してください。

    重要

    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. オプション: インストールに含めるカスタムマニフェストが少なくとも 1 つある場合は、Include custom manifests を選択します。カスタムマニフェストには、現在 Assisted Installer でサポートされていない追加の設定が含まれています。チェックボックスを選択すると、ウィザードに Custom manifests ページが追加され、そこでマニフェストをアップロードします。

    重要

    • OpenShift Container Platform を Oracle Cloud Infrastructure (OCI) サードパーティープラットフォームにインストールする場合は、Oracle が提供するカスタムマニフェストを追加することが必須です。
    • すでにカスタムマニフェストを追加している場合は、Include custom manifests チェックボックスをオフにすると、それらはすべて自動的に削除されます。削除を確定するように求められます。

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

    注記

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

16. オプション: インストールディスクの暗号化を有効にする場合は、インストールディスクの 暗号化を有効に するで、単一ノード 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. 次のオプションから 1 つ以上を選択します。

   • Install OpenShift Virtualization
   • Install multicluster engine
   • Install OpenShift Data Foundation
   • Install Logical Volume Manager
2. 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 を使用してホストを起動します。これは、z/VM ノードを使用する IBM Z で推奨される方法です。ISO ブートは、RHEL KVM インストールで推奨される方法です。

      注記

      • RHEL KVM にインストールする場合、KVM ホスト上の VM が初回起動時に再起動されず、手動での起動が必要になることがあります。
      • Oracle Cloud Infrastructure に OpenShift Container Platform をインストールする場合は、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 ファイルをアップロードします。あるいは、ファイルマネージャーからファイルをフィールドにドラッグアンドドロップします。ファイルマネージャーでファイルを表示するには、メニューで Show hidden files を選択します。
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. ウィザードの Storage ページに移動します。
2. ホストを拡張して、関連するストレージディスクを表示します。
3. Role リストから Installation disk を選択します。
4. すべてのストレージディスクが Ready ステータスに戻る場合は、次の手順に進みます。

手順

1. ウィザードの Storage ページに移動します。
2. ホストを拡張して、関連するストレージディスクを表示します。
3. ディスクの Format をクリアします。
4. すべてのストレージディスクが Ready ステータスに戻る場合は、次の手順に進みます。

手順

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) です。OpenShift Container Platform 4.15 以降のリリースでは、Software-Defined Networking (SDN) はサポートされません。

手順

1. ウィザードの Cluster details ページで、Include custom manifests チェックボックスを選択します。
2. Custom manifest ページの folder フィールドで、カスタムマニフェストファイルを保存する Assisted Installer フォルダーを選択します。オプションには openshift または manifest が含まれます。
3. ファイル名 フィールドに、拡張子を含むマニフェストファイルの名前を入力します。たとえば、manifest1.json または multiple1.yaml です。
4. Content で Upload アイコンまたは Browse ボタンをクリックしてファイルをアップロードします。または、ファイルをファイルシステムから Content フィールドにドラッグします。
5. 別のマニフェストをアップロードするには、Add another manifest をクリックし、プロセスを繰り返します。これにより、以前にアップロードしたマニフェストが保存されます。
6. Next をクリックしてすべてのマニフェストを保存し、Review and create ページに移動します。アップロードしたカスタムマニフェストは Custom manifests の下に一覧表示されます。

手順

1. フォルダーを変更するには、Folder リストからマニフェスト用の別のフォルダーを選択します。
2. ファイル名を変更するには、File name フィールドにマニフェストの新しい名前を入力します。
3. マニフェストを上書きするには、新しいマニフェストを同じファイル名で保存します。
4. マニフェストをファイルとしてファイルシステムに保存するには、Download アイコンをクリックします。
5. マニフェストをコピーするには、Copy to clipboard アイコンをクリックします。
6. 変更を適用するには、Add another manifest または Next をクリックします。

手順

1. Custom manifests ページに移動します。
2. マニフェスト名の上にマウスを置くと、Delete (マイナス) アイコンが表示されます。
3. アイコンをクリックし、ダイアログボックスの Delete をクリックします。

手順

1. ウィザードの Cluster details ページに移動します。
2. Include custom manifests チェックボックスをオフにします。
3. Remove custom manifests ダイアログボックスで、Remove をクリックします。

手順

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. メニューで Downloads をクリックします。
2. OpenShift Cluster Manager API Token の下の Tokens セクションで、View API Token をクリックします。

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

   重要

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

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

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

   $ export OFFLINE_TOKEN=<copied_token>

   ヒント

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

6. (オプション) OFFLINE_TOKEN 変数の定義を確認します。

   $ echo ${OFFLINE_TOKEN}

手順

1. コマンドラインターミナルで、OFFLINE_TOKEN を使用して API_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" \
   )

2. API_TOKEN 変数定義を確認します。

   $ echo ${API_TOKEN}

3. トークン生成方法の 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" \
   )

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

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

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

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

   $ source refresh-token

6. 次のコマンドを実行して、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 形式にフォーマットします。

6. PULL_SECRET 変数の定義を確認します。

   $ echo ${PULL_SECRET}

手順

1. ターミナルで、root ユーザーから SSH 公開鍵を取得します。

   $ cat /root/.ssh/id_rsa.pub

2. SSH 公開鍵を CLUSTER_SSHKEY 変数に設定します。

   $ CLUSTER_SSHKEY=<downloaded_ssh_key>

3. CLUSTER_SSHKEY 変数の定義を確認します。

   $ echo ${CLUSTER_SSHKEY}

手順

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 Container Platform クラスターを表すにはデフォルト値 Full を使用し、シングルノード OpenShift クラスターを表すには None を使用します。複数のマスターノード上に 高可用性 クラスターを すべて インストールし、インストールされたクラスターの可用性を保証します。none は、1 つのノードに完全なクラスターをインストールします。

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

      cat << EOF > cluster.json
      {
        "name": "testcluster",
        "openshift_version": "4.11",
        "high_availability_mode": "<cluster_type>", 1
        "base_dns_domain": "example.com",
        "network_type": "examplenetwork",
        "cluster_network_cidr":"11.111.1.0/14"
        "cluster_network_host_prefix": 11,
        "service_network_cidr": "111.11.1.0/16",
        "api_vips":[{"ip": ""}],
        "ingress_vips": [{"ip": ""}],
        "vip_dhcp_allocation": false,
        "additional_ntp_source": "clock.redhat.com,clock2.redhat.com",
        "ssh_public_key": "$CLUSTER_SSHKEY",
        "pull_secret": $PULL_SECRET
      }
      EOF

      注記

      1

      マルチノード OpenShift Container Platform クラスターを表すにはデフォルト値 Full を使用し、シングルノード OpenShift クラスターを表すには None を使用します。複数のマスターノード上に 高可用性 クラスターを すべて インストールし、インストールされたクラスターの可用性を保証します。none は、1 つのノードに完全なクラスターをインストールします。

      $ 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. クラスターを変更します。たとえば、SSH 鍵を変更します。

   $ 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",
       "pull_secret": $PULL_SECRET,
       "proxy": {
          "http_proxy": "",
          "https_proxy": "",
          "no_proxy": ""
        },
        "ssh_authorized_key": "$CLUSTER_SSHKEY",
        "image_type": "full-iso",
        "cluster_id": "${CLUSTER_ID}",
        "openshift_version": "4.11"
      }
      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. 必要に応じて検出イメージを設定します。詳細は、検出イメージの設定 を参照してください。

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

   出力例

   {
     "expires_at": "2024-02-07T20:20:23.000Z",
     "url": "https://api.openshift.com/api/assisted-images/bytoken/<TOKEN>/<OCP_VERSION>/<CPU_ARCHITECTURE>/<FULL_OR_MINIMAL_IMAGE>.iso"
   }

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. ホストを変更します。

   $ 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. カスタムマニフェストファイルを作成します。
2. ファイル形式に適した拡張子を使用して、カスタムマニフェストファイルを保存します。

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

   $ source refresh-token

4. 以下のコマンドを実行して、カスタムマニフェストをクラスターに追加します。

   $ curl -X POST "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/manifests" \
       -H "Authorization: Bearer $API_TOKEN" \
       -H "Content-Type: application/json" \
       -d '{
               "file_name":"manifest.json",
               "folder":"manifests",
               "content":"'"$(base64 -w 0 ~/manifest.json)"'"
       }' | jq

   manifest.json はマニフェストファイルの名前に置き換えます。manifest.json の 2 番目のインスタンスは、ファイルへのパスです。パスが正しいことを確認します。

   出力例

   {
     "file_name": "manifest.json",
     "folder": "manifests"
   }

   注記

   base64 -w 0 コマンドは、マニフェストを文字列として base64 エンコードし、キャリッジリターンを返します。キャリッジリターンを含むエンコーディングは例外を生成します。

5. Assisted Installer がマニフェストを追加したことを確認します。

   curl -X GET "https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/manifests/files?folder=manifests&file_name=manifest.json" -H "Authorization: Bearer $API_TOKEN"

   manifest.json はマニフェストファイルの名前に置き換えます。

手順

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. 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 です (例: https://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 ドロップダウンを選択します。
3. Control plane node を選択して、このホストにコントロールプレーンロールを割り当てます。
4. Worker を選択して、このホストにワーカーロールを割り当てます。
5. バリデーションステータスを確認します。

手順

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 をインストールする手順を開始します。詳細は、関連情報 セクションの Assisted Installer API を使用したインストール を参照してください。

2. インストールの "Registering a new cluster" のステップに到達したら、クラスターを multi-architecture クラスターとして登録します。

   $ 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 Container Platform のバージョン番号には 複数の オプションを使用します (例: "4.12-multi")。

   2

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

   3

   full の値を使用して、マルチノードの OpenShift Container Platform を指定します。

3. インストールの "Registering a new infrastructure environment" ステップに到達したら、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. インストールの "Adding hosts" ステップに到達したら、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. インストールの "Registering a new infrastructure environment" 手順を繰り返します。今回は、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. インストールの "Adding hosts" 手順を繰り返します。今回は、host_role を worker に設定します。

   注記

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

   $ 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. 保留中の 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 を承認する必要があります。

3. プライマリーノードが 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) が必要です。

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

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

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

   $ oc get clusteroperator etcd

   出力例

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

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

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

   $ 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

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

10. ClusterVersion を確認します。

    $ oc get ClusterVersion

    出力例

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

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

    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

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

13. 物理マシンを削除して、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. ホストの検出で、ホストの追加ボタンをクリックします。

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

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

4. 目的のプロビジョニングタイプを選択します。

   注記

   Minimal image file: Provision with virtual media では、起動に必要なデータをフェッチする小さなイメージがダウンロードされます。

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 ファイルをアップロードします。あるいは、ファイルマネージャーからファイルをフィールドにドラッグアンドドロップします。ファイルマネージャーでファイルを表示するには、メニューで Show hidden files を選択します。

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

   注記

   Minimal image file: Provision with virtual media では、起動に必要なデータをフェッチする小さなイメージがダウンロードされます。

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>

   <discovery_url> は、前の手順の 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. Red Hat Hybrid Cloud コンソール にログインします。
2. Create cluster をクリックします。
3. Cluster type ページで Datacenter タブをクリックします。
4. Assisted Installer セクションで、Create cluster をクリックします。

5. Cluster Details ページで、次のフィールドに入力します。

   1. Cluster name フィールドに、クラスターの名前 (ocidemo など) を指定します。
   2. ベースドメイン フィールドに、クラスターのベースドメイン (splat-oci.devcluster.openshift.com など) を指定します。コンパートメントとゾーンを作成した後、OCI からベースドメインを取得します。
   3. OpenShift version フィールドに、OpenShift 4.15 以降のバージョンを指定します。
   4. [CPU アーキテクチャー] フィールドで、x86_64 または Arm64 を指定します。
   5. Integrate with external partner platforms リストから、Oracle Cloud Infrastructure を選択します。Include custom manifests チェックボックスが自動的に選択されます。
6. Next をクリックします。
7. Operators ページで、Next をクリックします。

8. Host Discovery ページで、以下の操作を実行します。

   1. Add host をクリックしてダイアログボックスを表示します。
   2. SSH public key フィールドには、ローカルシステムから SSH 公開鍵をアップロードします。ssh-keygen を使用して、SSH 鍵ペアを生成できます。
   3. Generate Discovery ISO をクリックして、検出イメージの ISO ファイルを生成します。
   4. ローカルシステムにファイルをダウンロードします。次に、ファイルを Oracle Cloud Infrastructure のバケットにオブジェクトとしてアップロードします。

手順

1. Red Hat Hybrid Cloud Console から、Host discovery ページに移動します。
2. Role 列で、ターゲットのホスト名ごとにノードロール (Control plane node or Worker) を割り当てます。Next をクリックします。
3. Storage ページおよび Networking ページのデフォルト設定を受け入れます。
4. Next をクリックして Custom manifests ページに移動します。
5. Folder フィールドで manifests を選択します。
6. File name フィールドに、oci-ccm.yml などの値を入力します。
7. Content セクションで、Browse をクリックします。custom_ manifest/manifests/oci-ccm.yml にある CCM マニフェストを選択します。

8. Add another manifest をクリックします。Oracle が提供する次のマニフェストに対して同じ手順を繰り返します。

   • CSI ドライバーマニフェスト: custom_manifest/manifests/oci-csi.yml。
   • CCM マシン設定: custom_manifest/openshift/machineconfig-ccm.yml。
   • CSI ドライバーのマシン設定: custom_manifest/openshift/machineconfig-csi.yml。
9. レビューと作成 ステップを完了して、OCI 上に OpenShift Container Platform クラスターを作成します。
10. Install cluster をクリックして、クラスターインストールを終了します。

手順

1. クラスターの IP アドレスとドメイン名を確認します。

   1. set the IP or domain used to reach the cluster のハイパーリンクをクリックします。
   2. Update cluster hostname ウィンドウで、クラスターの正しい IP アドレスまたはドメイン名を入力します。
2. DNS 設定をチェックして、DNS が指定したドメインを解決できることを確認します。
3. すべてのファイアウォールでポート 22624 が開いていることを確認します。

4. ホストのエージェントログをチェックして、エージェントが SSH 経由で Assisted Service にアクセスできることを確認します。

   $ sudo journalctl TAG=agent

   注記

   詳細は、エージェントが Assisted Service にアクセスできることを確認する を参照してください。