OpenShift Container Platform の支援付きインストーラー

Assisted Installer for OpenShift Container Platform 2022

支援付きインストーラーユーザーガイド

Red Hat Customer Content Services

概要

支援付きインストーラーとその使用法に関する情報

第1章 アシステッドインストーラーを使用したオンプレミスクラスターのインストール

アシステッドインストーラーを使用して、OpenShift Container Platform をオンプレミスのハードウェアまたはオンプレミスの VM にインストールできます。支援付きインストーラーを使用した OpenShift Container Platform のインストールは、x86_64ppc64les390x、および arm64 の CPU アーキテクチャーに対応しています。

注記

現在、IBM zSystems (s390x) への OpenShift Container Platform のインストールは、RHEL KVM インストールでのみサポートされています。

1.1. アシステッドインストーラーの使用

OpenShift Container Platform の 支援付きインストーラー は、Red Hat Hybrid Cloud Console で提供されるユーザーフレンドリーなインストールソリューションです。支援付きインストーラーは、ベアメタルおよび vSphere インフラストラクチャーに焦点を当てたさまざまなデプロイメントプラットフォームをサポートします。

支援付きインストーラーは、インストール機能をサービスとして提供します。このサービスとしてのソフトウェア (SaaS) アプローチには、次の利点があります。

  • Web ユーザーインターフェイス: Web ユーザーインターフェイスは、ユーザーがインストール設定ファイルを手動で作成しなくても、クラスターのインストールを実行します。
  • ブートストラップノードなし: アシステッドインストーラーを使用してインストールする場合、ブートストラップノードは必要ありません。ブートストラッププロセスは、クラスター内のノードで実行されます。
  • ホスティング: アシステッドインストーラーは以下をホストします。

    • Ignition ファイル
    • インストール前の設定
    • 検出 ISO
    • インストーラー
  • 合理化されたインストールワークフロー: デプロイメントには、OpenShift Container Platform の詳細な知識は必要ありません。アシステッドインストーラーは適切なデフォルトを提供し、以下のようにインストーラーをサービスとして提供します。

    • OpenShift Container Platform インストーラーをローカルにインストールして実行する必要がなくなります。
    • 最新のテスト済み z-stream リリースまでの最新バージョンのインストーラーを保証します。必要に応じて、古いバージョンを引き続き利用できます。
    • OpenShift Container Platform インストーラーをローカルで実行する必要なく、API を使用したビルドの自動化を可能にします。
  • 高度なネットワーキング: アシステッドインストーラーは、SDN と OVN を使用する IPv4 ネットワーキング、OVN のみを使用する IPv6 とデュアルスタックネットワーキング、NMState ベースの静的 IP アドレス指定、および HTTP/S プロキシーをサポートします。OVN は、OpenShift Container Platform 4.12 以降のリリースにおいてデフォルトの Container Network Interface (CNI) ですが、SDN を使用するように切り替えることもできます。
  • インストール前の検証: アシステッドインストーラーは、インストール前に設定を検証して、高い確率で成功するようにします。検証には以下が含まれます。

    • ネットワーク接続の確保
    • 十分なネットワーク帯域幅の確保
    • レジストリーへの接続の確保
    • クラスターノード間の時刻同期の確保
    • クラスターノードが最小ハードウェア要件を満たしていることの確認
    • インストール設定パラメーターの検証
  • REST API: アシステッドインストーラーには REST API があり、自動化が可能となります。

アシステッドインストーラーは、オプションの HTTP/S プロキシーを含む、接続された環境でのオンプレミスの OpenShift Container Platform のインストールをサポートします。以下をインストールできます。

  • 高可用性 OpenShift Container Platform または Single Node OpenShift (SNO)
  • プラットフォームが完全に統合されたベアメタルまたは vSphere 上の OpenShift Container Platform、または統合されていない他の仮想化プラットフォーム
  • オプション: OpenShift Virtualization および OpenShift Data Foundation (以前の OpenShift Container Storage)

ユーザーインターフェイスは、自動化が存在しない、または必要とされない直感的なインタラクティブワークフローを提供します。ユーザーは、REST API を使用してインストールを自動化することもできます。

支援付きインストーラーを使用して OpenShift Container Platform クラスターを作成するには、Install OpenShift with the Assisted Installer を参照してください。

1.2. 支援付きインストーラーの API サポート

支援付きインストーラーの API サポートは、非推奨の発表から少なくとも 3 カ月は安定しています。

第2章 支援付きインストーラーを使用したインストールの準備

クラスターをインストールする前に、クラスターノードとネットワークが要件を満たしていることを確認する必要があります。

2.1. 前提条件

  • OpenShift Container Platform のインストールおよび更新プロセスの詳細を確認している。
  • クラスターインストール方法の選択およびそのユーザー向けの準備を確認している。
  • ファイアウォールを使用する場合は、支援付きインストーラーが機能するために必要なリソースにアクセスできるようにファイアウォールを設定する必要があります。

2.2. 支援付きインストーラーの前提条件

支援付きインストーラーは、以下の前提条件を検証して、インストールが正常に行われるようにします。

2.2.1. CPU アーキテクチャー

支援付きインストーラーは、次の CPU アーキテクチャーをサポートしています。

  • x86_64
  • arm64
  • ppc64le
  • s390x

2.2.2. ハードウェア

支援付きインストーラーには、少なくとも 8 つの CPU コア、16.00 GiB RAM、および 100 GB のディスクサイズを備えた 1 つのホストが必要です。

コントロールプレーンの場合、ホストには少なくとも次のリソースが必要です。

  • 4 CPU コア
  • 16.00 GiB RAM
  • 100 GB のストレージ
  • etcd wal_fsync_duration_seconds の書き込み速度は 10 ミリ秒以下

ワーカーの場合、各ホストには少なくとも次のリソースが必要です。

  • 2 CPU コア
  • 8.00 GiB RAM
  • 100 GB のストレージ

2.2.3. ネットワーク

ネットワークは次の要件を満たす必要があります。

  • 静的 IP アドレス指定を使用しない場合は、DHCP サーバー。
  • ベースドメイン名。次の要件が満たされていることを確認する必要があります。

    • *.<cluster_name>.<base_domain> などのワイルドカードがない場合、インストールは続行されません。
    • api.<cluster_name>.<base_domain> の DNS A/AAAA レコード。
    • *.apps.<cluster_name>.<base_domain> のワイルドカードを含む DNS A/AAAA レコード。
  • ファイアウォールの外側のユーザーが oc CLI ツールを介してクラスターにアクセスできるようにする場合は、API URL 用にポート 6443 が開かれます。
  • ファイアウォールの外側のユーザーがコンソールにアクセスできるようにする場合は、ポート 443 がコンソール用に開いています。
  • ユーザー管理ネットワークを使用する場合、クラスター内の各ノードの DNS A/AAAA レコードがないと、インストールは続行されません。インストールの完了後にクラスター管理ネットワークを使用してクラスターに接続する場合は、クラスター内の各ノードに DNS A/AAAA レコードが必要ですが、Cluster Managed Networking を使用する場合は、A/AAAA レコードがなくてもインストールを続行できます。
  • 静的 IP アドレス指定の使用時に事前設定されたホスト名で起動する場合は、クラスター内の各ノードの DNS PTR レコード。それ以外の場合、Assisted Installer には、ノードの名前をネットワークインターフェイスの MAC アドレスに変更する静的 IP アドレス指定を使用する場合のノードの自動名前変更機能があります。
重要

トップレベルドメインレジストラーでの DNS A/AAAA レコードの設定は、更新にかなりの時間がかかる場合があります。インストールの遅延を防ぐために、インストールの前に A/AAAA レコードの DNS 設定が機能していることを確認してください。

OpenShift Container Platform クラスターのネットワークは、以下の要件も満たしている必要があります。

  • すべてのクラスターノード間の接続
  • 各ノードのインターネットへの接続
  • クラスターノード間の時刻同期のための NTP サーバーへのアクセス

2.2.4. プリフライト検証

支援付きインストーラーは、インストール前にクラスターが前提条件を満たしていることを確認します。確認することで、インストール後の複雑なトラブルシューティングが不要になり、時間と労力が大幅に節約されます。ノードにソフトウェアをインストールする前に、支援付きインストーラーは次の検証を行います。

  • ネットワーク接続の確保
  • 十分なネットワーク帯域幅の確保
  • レジストリーへの接続の確保
  • クラスターノード間の時刻同期の確保
  • クラスターノードが最小ハードウェア要件を満たしていることの確認
  • インストール設定パラメーターの検証

支援付きインストーラーが前述の要件を正常に検証しない場合、インストールは続行されません。

第3章 支援付きインストーラー UI を使用したインストール

クラスターノードとネットワークの要件が満たされていることを確認したら、クラスターのインストールを開始できます。

3.1. インストール前の考慮事項

支援付きインストーラーを使用して OpenShift Container Platform をインストールする前に、以下の設定の選択を検討する必要があります。

  • 使用する基本ドメイン
  • インストールする OpenShift Container Platform の製品バージョン
  • フルクラスターまたは単一ノードの OpenShift をインストールするかどうか
  • DHCP サーバーまたは静的ネットワーク設定を使用するかどうか
  • IPv4 またはデュアルスタックネットワークを使用するかどうか
  • OpenShift Virtualization をインストールするかどうか
  • Red Hat OpenShift Data Foundation をインストールするかどうか
  • マルチクラスターエンジンをインストールするかどうか
  • vSphere または Nutanix にインストールするときにプラットフォームと統合するかどうか
重要

Operator のいずれかをインストールする場合は、オプション:Installing Operators の関連するハードウェアおよびストレージ要件を参照してください。

3.2. クラスターの詳細の設定

支援付きインストーラーWeb ユーザーインターフェイスを使用してクラスターを作成するには、次の手順を使用します。

手順

  1. RedHat Hybrid Cloud Console にログインします。
  2. メニューで OpenShift をクリックします。
  3. Create cluster をクリックします。
  4. Datacenter タブをクリックします。
  5. Assisted Installer セクションで、Create cluster を選択します。
  6. Cluster Name フィールドにクラスターの名前を入力します。
  7. Base domain フィールドに、クラスターのベースドメインを入力します。クラスターのすべてのサブドメインは、この基本ドメインを使用します。

    注記

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

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

    注記

    IBM Power および IBM zSystems プラットフォームの場合、OpenShift Container Platform バージョン 4.13 以降のみがサポートされます。

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

    注記

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

  10. オプション: 支援付きインストーラーには、アカウントに関連付けられたプルシークレットがすでにあります。別のプルシークレットを使用する場合は、Edit pull secret を選択します。
  11. オプション: 支援付きインストーラーは、デフォルトで x86_64 CPU アーキテクチャーを使用します。OpenShift Container Platform を別のアーキテクチャーにインストールする場合は、使用するそれぞれのアーキテクチャーを選択します。有効な値は、arm64ppc64le、および s390x です。一部の機能は、arm64ppc64le、および s390x CPU アーキテクチャーでは利用できないことに注意してください。
  12. オプション: 支援付きインストーラーはデフォルトで DHCP ネットワークに設定されます。DHCP 予約の代わりにクラスターノードに静的 IP 設定、ブリッジ、または結合を使用している場合は、静的 IP、ブリッジ、および結合 を 選択します。
  13. オプション: インストールディスクの暗号化を有効にする場合は、インストールディスクの 暗号化を有効に するで、単一ノード OpenShift の コントロールプレーンノード、ワーカー を選択できます。マルチノードクラスターの場合、コントロールプレーンノード を選択してコントロールプレーンノードのインストールディスクを暗号化し、ワーカー を選択してワーカーノードのインストールディスクを暗号化できます。
重要

インストールの開始後は、基本ドメイン、SNO チェックボックス、CPU アーキテクチャー、ホストのネットワーク設定、またはディスク暗号化を変更できません。

3.3. オプション: 静的ネットワークの設定

支援付きインストーラーは、SDN と OVN を使用した IPv4 ネットワークをサポートし、OVN のみを使用した IPv6 とデュアルスタックネットワークをサポートします。支援付きインストーラーは、IP アドレス/MAC アドレスマッピングを使用した静的ネットワークインターフェイスを使用したネットワークの設定をサポートしています。支援付きインストーラーは、ホスト用の宣言型ネットワークマネージャー API である NMState ライブラリーを使用したホストネットワークインターフェイスの設定もサポートしています。NMState を使用して、静的 IP アドレス指定、ボンディング、VLAN、およびその他の高度なネットワーク機能を備えたホストをデプロイできます。まず、ネットワーク全体の設定を設定する必要があります。次に、ホストごとにホスト固有の設定を作成する必要があります。

手順

  1. インターネットプロトコルのバージョンを選択します。有効なオプションは IPv4Dual 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 アドレスとインターフェイス名を追加します。

関連情報

3.4. Operator の設定

支援付きインストーラーは、特定の Operator を設定してインストールできます。Operator には以下が含まれます。

  • OpenShift Virtualization
  • Kubernetes のマルチクラスターエンジン(MCE)
  • OpenShift Data Foundation
  • 論理ボリュームマネージャー(LVM)ストレージ
重要

各 Operator の詳細な説明と、ハードウェア要件、ストレージに関する考慮事項、相互依存関係、および追加のインストール手順は、関連情報 を参照して ください

この手順はオプションです。Operator を選択せずにインストールを完了できます。

手順

  1. OpenShift Virtualization をインストールするには、Install OpenShift Virtualization を選択します。
  2. Multicluster Engine (MCE)をインストールするには、Install multicluster engine を選択します。
  3. OpenShift Data Foundation をインストールするには、Install OpenShift Data Foundation を選択します。
  4. Logical Volume Manager をインストールするには、Install Logical Volume Manager を選択します。
  5. Next をクリックして次のステップに進みます。

3.5. クラスターへのホストの追加

1 つ以上のホストをクラスターに追加する必要があります。クラスターにホストを追加するには、検出 ISO を生成する必要があります。検出 ISO は、エージェントを使用して Red Hat Enterprise Linux CoreOS (RHCOS) インメモリーを実行します。

クラスター上の各ホストに対して次の手順を実行します。

手順

  1. Add hosts ボタンをクリックし、インストールメディアを選択します。

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

      注記

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

  2. オプション: クラスターホストがプロキシーの使用を必要とするファイアウォールの内側にある場合は、Configure cluster-wide proxy settings を選択します。プロキシーサーバーの HTTP および HTTPS URL のユーザー名、パスワード、IP アドレス、およびポートを入力します。
  3. core ユーザーとしてクラスターノードに接続できるように、SSH 公開キーを追加します。クラスターノードにログインすると、インストール中にデバッグ情報を入手できます。
  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 スクリプトを使用してホストを起動します。

関連情報

3.6. ホストの設定

検出 ISO を使用してホストを起動すると、ページの下部にあるテーブルにホストが表示されます。オプションで各ホストのホスト名およびロールを設定できます。必要に応じてホストを削除することもできます。

手順

  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 列で、メニューをクリックしてホストのロールを変更できます。

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

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

すべてのクラスターホストが Ready のステータスで表示されたら、次の手順に進みます。

3.7. ストレージディスクの設定

クラスターホストの検出および設定後に、オプションで各ホストのストレージディスクを設定できます。

ここで指定できるホスト設定は、ホストの設定セクションで説明します。リンクは、以下の関連情報を参照してください。

手順

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

すべてのディスクドライブのステータスが Ready と表示されたら、次の手順に進みます。

関連情報

3.8. ネットワークの設定

OpenShift Container Platform をインストールする前に、クラスターネットワークを設定する必要があります。

手順

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

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

      注記

      現在、クラスター管理ネットワークは、OpenShift Container Platform バージョン 4.13 の IBM zSystems および IBM Power ではサポートされていません。

    • 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 IPIngress 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) です。

3.9. インストール前の検証

支援付きインストーラーは、インストール前にクラスターが前提条件を満たしていることを確認します。確認することで、インストール後の複雑なトラブルシューティングが不要になり、時間と労力が大幅に節約されます。クラスターをインストールする前に、クラスターと各ホストがインストール前の検証にパスしていることを確認してください。

3.10. クラスターのインストール

設定が完了し、すべてのノードが Ready になったら、インストールを開始できます。インストールプロセスにはかなりの時間がかかりますが、支援付きインストーラーWeb コンソールからインストールを監視できます。ノードはインストール中に再起動し、インストール後に初期化されます。

手順

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

3.11. インストールの完了

クラスターがインストールされて初期化されると、支援付きインストーラーはインストールが完了したことを示します。支援付きインストーラーは、コンソール URL、kubeadmin のユーザー名とパスワード、および kubeconfig ファイルを提供します。さらに、支援付きインストーラーは、OpenShift Container Platform バージョン、ベースドメイン、CPU アーキテクチャー、API および Ingress IP アドレス、クラスターおよびサービスネットワーク IP アドレスを含むクラスターの詳細を提供します。

前提条件

  • oc CLI ツールがインストールされている。

手順

  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. インストール後のプラットフォーム統合手順を完了します。

第4章 支援付きインストーラー API を使用したインストール

クラスターノードとネットワークの要件が満たされていることを確認したら、支援付きインストーラー API を使用してクラスターのインストールを開始できます。API を使用するには、次の手順を実行する必要があります。

  • API 認証を設定します。
  • プルシークレットを設定します。
  • 新しいクラスター定義を登録します。
  • クラスターのインフラストラクチャー環境を作成します。

これらの手順を実行すると、クラスター定義の変更、検出 ISO の作成、クラスターへのホストの追加、およびクラスターのインストールが可能になります。このドキュメントは 支援付きインストーラー API のすべてのエンドポイントをカバーしているわけではありませんが、API ビューアー または swagger.yaml ファイルですべてのエンドポイントを確認できます。

4.1. オプション: OpenShift Cluster Manager CLI のインストール

OpenShift Cluster Manager (ocm) CLI ツールを使用すると、コマンドラインから OpenShift Cluster Manager を操作できます。REST GET、POST、PATCH、および DELETE 操作を実行し、API トークンを生成し、他の機能の中でクラスターを一覧表示できます。

重要

OpenShift Cluster Manager CLI は、開発者プレビュー機能のみです。開発者プレビュー機能は、Red Hat では一切サポートされておらず、機能的に完全ではなく、本番環境に対応していません。本番環境またはビジネスクリティカルなワークロードには、開発者プレビュー機能を使用しないでください。開発者プレビュー機能は、Red Hat 製品オファリングに含まれる可能性がある前に、今後の製品機能への早期アクセスを提供し、お客様が機能をテストし、開発プロセス中にフィードバックを提供できるようにします。これらの機能にはドキュメントがない可能性があり、いつでも変更または削除される可能性があり、テストは制限されています。Red Hat は、関連する SLA なしで、開発者プレビュー機能に関するフィードバックを送信する方法を提供する場合があります。

前提条件

  • jq をインストールする。
  • クラスター作成権限を持つユーザーとして OpenShift Cluster Manager にログインする。

手順

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

    重要

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

  5. Your API token セクションで、オフライントークンをコピーします。
  6. 端末で、オフライントークンを OFFLINE_TOKEN 変数に設定します。

    $ export OFFLINE_TOKEN=<copied_api_token>
    ヒント

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

  7. ocm CLI のダウンロード をクリックします。
  8. ダウンロードしたファイルをパスにコピーします。たとえば、ファイルを /usr/bin または ~/.local/bin にコピーして、ocm シンボリックリンクを作成します。
  9. 認証コマンドを端末にコピーアンドペーストし、Enter キー を押してログインします。

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

4.2. REST API を使用した認証

API 呼び出しには、API トークンによる認証が必要です。変数名として API_TOKEN を使用すると仮定すると、API 呼び出しに -H "Authorization: Bearer ${API_TOKEN}" を追加して、REST API で認証します。

注記

API トークンは 15 分後に期限切れになります。

前提条件

  • (オプション) OpenShift Cluster Manager (ocm) CLI ツールがインストールされている。

手順

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

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

      $ export API_TOKEN=$( \
        curl \
        --silent \
        --header "Accept: application/json" \
        --header "Content-Type: application/x-www-form-urlencoded" \
        --data-urlencode "grant_type=refresh_token" \
        --data-urlencode "client_id=cloud-services" \
        --data-urlencode "refresh_token=${OFFLINE_TOKEN}" \
        "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \
        | jq --raw-output ".access_token" \
      )
    2. (オプション) コマンドライン端末で、ocm クライアントにログインします。

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

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

      $ export API_TOKEN=$(ocm token)
  1. トークン生成方法の 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" \
    )

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

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

    $ chmod +x ~/.local/bin/refresh-token
  3. API トークンを更新します。

    $ source refresh-token
  4. 次のコマンドを実行して、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"
      }
    }

4.3. プルシークレットの設定

Assisted Installer API 呼び出しの多くは、プルシークレットを必要とします。プルシークレットをファイルにダウンロードして、API 呼び出しで参照できるようにします。プルシークレットは、リクエストの JSON オブジェクト内の値として含まれる JSON オブジェクトです。プルシークレットの JSON は、引用符をエスケープするようにフォーマットする必要があります。以下に例を示します。

{"auths":{"cloud.openshift.com": ...

After

{\"auths\":{\"cloud.openshift.com\": ...

手順

  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 形式にフォーマットします。

4.4. 新しいクラスターの登録

API を使用して新しいクラスター定義を登録するには、/v2/clusters エンドポイントを使用します。新しいクラスターを登録するには、次の設定が必要です。

  • name
  • openshift-version
  • pull_secret
  • cpu_architecture

新しいクラスターを登録するときに設定できるフィールドの詳細については、API ビューアーcluster-create-params モデルを参照してください。クラスター定義を作成したら、クラスター定義を変更し、追加設定の値を指定できます。

前提条件

  • 有効な API_TOKEN を生成した。トークンは 15 分ごとに期限切れになる。
  • プルシークレットをダウンロードした。
  • オプション: プルシークレットを $PULL_SECRET 変数に割り当てた。

手順

  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、arm64ppc64les390x multi のいずれかの値を使用します。
      2
      マルチノードの OpenShift クラスターを表す場合はデフォルト値 full を使用し、単一ノードの OpenShift クラスターを表す場合は none を使用します。
    2. オプション: 設定を JSON ファイルに書き込み、それをリクエストで参照することにより、新しいクラスターを登録できます。

      cat << EOF > cluster.json
      {
        "name": "testcluster",
        "openshift_version": "4.11",
        "high_availability_mode": "<cluster_type>",
        "base_dns_domain": "example.com",
        "pull_secret": $PULL_SECRET
      }
      EOF
      $ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/clusters" \
        -d @./cluster.json \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $API_TOKEN" \
        | jq '.id'
  3. 返された cluster_idCLUSTER_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

新しいクラスター定義を登録したら、クラスターのインフラ環境を作成します。

注記

インフラストラクチャー環境を作成するまで、支援付きインストーラーユーザーインターフェイスにクラスター設定設定を表示することはできません。

4.5. クラスターの変更

API を使用してクラスター定義を変更するには、/v2/clusters/{cluster_id} エンドポイントを使用します。クラスターリソースの変更は、ネットワークの種類の変更やユーザー管理ネットワークの有効化などの設定を追加するための一般的な操作です。クラスター定義を変更するときに設定できるフィールドの詳細については、API ビューアーv2-cluster-update-params モデルを参照してください。

前提条件

  • 新しいクラスターリソースを作成した。

手順

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

    $ source refresh-token
  2. クラスターを変更します。以下に例を示します。

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

4.6. 新しいインフラ環境の登録

支援付きインストーラー API を使用して新しいクラスター定義を登録したら、v2/infra-envs エンドポイントを使用してインフラストラクチャー環境を作成します。新しいインフラストラクチャー環境を登録するには、次の設定が必要です。

  • name
  • pull_secret
  • cpu_architecture

新しいインフラストラクチャー環境を登録するときに設定できるフィールドの詳細は、API ビューアーinfra-env-create-params モデルを参照してください。インフラストラクチャー環境は、作成後に変更できます。ベストプラクティスとして、新しいインフラストラクチャー環境を作成するときに cluster_id を含めることを検討してください。cluster_id は、インフラストラクチャー環境をクラスター定義に関連付けます。新しいインフラストラクチャー環境を作成するとき、支援付きインストーラーは検出 ISO も生成します。

前提条件

  • 有効な API_TOKEN を生成した。トークンは 15 分ごとに期限切れになる。
  • プルシークレットをダウンロードした。
  • オプション: 新しいクラスター定義を登録し、cluster_id をエクスポートした。

手順

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

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

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

      $ curl https://api.openshift.com/api/assisted-install/v2/infra-envs \
      -H "Authorization: Bearer ${API_TOKEN}" \
      -H "Content-Type: application/json" \
      -d "$(jq --null-input \
        --slurpfile pull_secret ~/Downloads/pull-secret.txt \
        --arg cluster_id ${CLUSTER_ID} '
          {
            "name": "testcluster-infra-env",
            "image_type":"full-iso",
            "cluster_id": $cluster_id,
            "cpu_architecture" : "<architecture_name>" 1
            "pull_secret": $pull_secret[0] | tojson
          }
      ')" | jq '.id'
      注記
      1
      有効な値を指定してください。x86_64、arm64、ppc64le、s390x、multi が有効です。
    2. オプション: 設定を JSON ファイルに書き込み、それを要求で参照することにより、新しいインフラストラクチャー環境を登録できます。

      $ cat << EOF > infra-envs.json
      {
       "name": "testcluster-infra-env",
       "image_type": "full-iso",
       "cluster_id": "$CLUSTER_ID",
       "pull_secret": $PULL_SECRET
      }
      EOF
      $ curl -s -X POST "https://api.openshift.com/api/assisted-install/v2/infra-envs" \
       -d @./infra-envs.json \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer $API_TOKEN" \
       | jq '.id'
  3. 返された IDINFRA_ENV_ID 変数に割り当て、エクスポートします。

    $ export INFRA_ENV_ID=<id>
注記

インフラストラクチャー環境を作成し、cluster_id を介してクラスター定義に関連付けると、支援付きインストーラー Web ユーザーインターフェイスでクラスター設定を確認できます。ターミナルセッションを閉じる場合は、新しいターミナルセッションで ID を再エクスポートする必要があります。

4.7. インフラストラクチャー環境の変更

/v2/infra-envs/{infra_env_id} エンドポイントを使用してインフラストラクチャー環境を変更できます。インフラストラクチャー環境の変更は、ネットワーク、SSH キー、イグニッション設定のオーバーライドなどの設定を追加するための一般的な操作です。

インフラストラクチャー環境を変更するときに設定できるフィールドの詳細については、API ビューアーinfra-env-update-params モデルを参照してください。新しいインフラストラクチャー環境を変更する場合、支援付きインストーラーは検出 ISO も再生成します。

前提条件

  • 新しいインフラストラクチャー環境が作成された。

手順

  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

4.8. ホストの追加

クラスターリソースとインフラストラクチャー環境を設定したら、検出 ISO イメージをダウンロードします。次の 2 つのイメージから選択できます。

  • 完全な ISO イメージ: ブートを自己完結型にする必要がある場合は、完全な ISO イメージを使用します。このイメージには、支援付きインストーラーエージェントを起動して開始するために必要なすべてが含まれています。ISO イメージのサイズは約 1GB です。
  • 最小限の ISO イメージ: 仮想メディア接続の帯域幅が制限されている場合は、最小限の ISO イメージを使用します。これはデフォルト設定です。このイメージには、ネットワークを使用してホストを起動するために必要なものだけが含まれています。コンテンツの大部分は、起動時にダウンロードされます。ISO イメージのサイズは約 100MB です。

どちらのイメージも同じインストール手順になります。イメージタイプを変更するには、この手順を実行する前に、インフラストラクチャー環境で image_type 設定を変更します。

前提条件

  • クラスターが作成済みである。
  • インフラストラクチャー環境を作成した。
  • 設定が完了した。
  • クラスターホストがプロキシーの使用を必要とするファイアウォールの背後にある場合、プロキシーサーバーの HTTP および HTTPS URL のユーザー名、パスワード、IP アドレス、およびポートを設定済みである。
  • イメージタイプを選択したか、デフォルトの minimum-iso を使用します。

手順

  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
  4. 検出イメージをダウンロードします。

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

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

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

4.9. ホストの変更

ホストを追加したら、必要に応じてホストを変更します。最も一般的な変更は、host_name および host_role パラメーターに対するものです。

/v2/infra-envs/{infra_env_id}/hosts/{host_id} エンドポイントを使用してホストを変更できます。ホストの変更時に設定できるフィールドの詳細は、API ビューアーhost-update-params モデルを参照してください。

ホストは、次の 2 つのロールのいずれかになります。

  • master: マスター ロールを持つホストは、コントロールプレーンホストとして動作します。
  • worker: worker ロールを持つホストは、ワーカーホストとして動作します。

デフォルトでは、支援付きインストーラーはホストを auto-assign に設定します。これは、ホストが master ロールか worker ロールかをインストーラが自動的に判断することを意味します。この手順を使用して、ホストのロールを設定します。

前提条件

  • ホストをクラスターに追加した。

手順

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

    $ 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 に置き換えます。

4.10. インストール前の検証

支援付きインストーラーは、インストール前にクラスターが前提条件を満たしていることを確認します。確認することで、インストール後の複雑なトラブルシューティングが不要になり、時間と労力が大幅に節約されます。クラスターをインストールする前に、クラスターと各ホストがインストール前の検証にパスしていることを確認してください。

4.11. クラスターのインストール

クラスターホストの検証が完了したら、クラスターをインストールできます。

前提条件

  • クラスターとインフラストラクチャー環境を作成しました。
  • インフラストラクチャー環境にホストを追加しました。
  • ホストはバリデーションにパスしました。

手順

  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. インストール後のプラットフォーム統合手順を完了します。

第5章 オプション: ディスク暗号化の有効化

TPM v2 または Tang 暗号化モードを使用して、インストールディスクの暗号化を有効にすることができます。

注記

状況によっては、ベアメタルホストのファームウェアで TPM ディスク暗号化を有効にし、支援付きインストーラーで生成した ISO から起動すると、クラスターのデプロイメントが停止することがあります。これは、ホスト上の以前のインストールからの TPM 暗号化キーが残っている場合に発生する可能性があります。詳細は、BZ#2011634 を参照してください。この問題が発生した場合は、Red Hat サポートに連絡してください。

5.1. TPM v2 暗号化の有効化

前提条件

  • 各ホストの BIOS で TPM v2 暗号化が有効になっているかどうかを確認します。ほとんどの Dell システムでこれが必要です。コンピューターのマニュアルを確認してください。支援付きインストーラーは、ファームウェアで TPM が有効になっていることも検証します。詳細については、支援付きインストーラー APIディスク暗号 化モデルを参照してください。
重要

TPM v2 暗号化チップが各ノードにインストールされ、ファームウェアで有効になっていることを確認します。

手順

  1. オプション: UI を使用して、ユーザーインターフェイスウィザードの クラスターの詳細 ステップで、コントロールプレーンノード、ワーカー、またはその両方で TPM v2 暗号化を有効にすることを選択します。
  2. オプション: API を使用して、ホストの変更手順に従います。disk_encryption.enable_on 設定を allmasters、または 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 の有効な設定は、allmasterworker、または none です。

5.2. Tang 暗号化を有効にする

前提条件

  • Tang 交換キーのサムプリントの生成に使用できる Red Hat Enterprise Linux (RHEL) 8 マシンにアクセスできる。

手順

  1. Tang サーバーを設定するか、既存のサーバーにアクセスします。手順については、NBDE (Network-Bound Disk Encryption) を参照してください。複数の Tang サーバーを設定できますが、支援付きインストーラーはインストール中にすべてのサーバーに接続できる必要があります。
  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 設定を allmasters、または 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 の有効な設定は、allmasterworker、または none です。tang_servers 値内で、オブジェクト内の引用符をコメントアウトします。

5.3. 関連情報

第6章 オプション: Operator のインストール

支援付きインストーラーは、デフォルト設定で一部の Operator をインストールできます。高度なオプションが必要な場合は、クラスターのインストール後に必要な Operator をインストールします。

支援付きインストーラーは、選択された Operator のインストールをクラスターインストールの一部として監視し、それらのステータスを報告します。インストール時に 1 つ以上の Operator でエラーが発生した場合、支援付きインストーラーはクラスターのインストールが完了したことをレポートし、1 つ以上の Operator がインストールに失敗したことを警告します。

新規クラスターの登録時に Operator を追加する方法についての詳細は、以下の特定のセクションを参照してください。クラスターが以前のインストール手順の一部としてすでに登録されている場合に Operator を追加および削除する方法は、クラスターの変更 を 参照してください。Assisted Installer API または UI を使用した完全なインストール手順は、支援付きインストーラー API を使用 したインストール または 支援付きインストーラー API を使用 したインストール を参照してください。

6.1. OpenShift virtualization のインストール

クラスターを設定するときに、OpenShift Virtualization を有効にすることができます。

注記

現在、OpenShift Virtualization は IBM zSystems および IBM Power ではサポートされていません。

有効な場合、支援付きインストーラーは次のことを行います。

  1. 環境が以下に概説する前提条件を満たしていることを検証します。
  2. 仮想マシンストレージを次のように設定します。

    1. 単一ノードの OpenShift クラスターバージョン 4.10 以降の場合、自動インストーラーは hostpath provisioner を設定します。
    2. 以前のバージョンの単一ノード OpenShift クラスターの場合、支援付きインストーラーは Local Storage Operator を設定します。
    3. マルチノードクラスターの場合、支援付きインストーラーは OpenShift Data Foundation を設定します。

前提条件

  • Red Hat Enterprise Linux (RHEL) 8 でサポート
  • Intel 64 または AMD64 CPU 拡張機能のサポート
  • Intel Virtualization Technology または AMD-V ハードウェア仮想化拡張機能が有効
  • NX (実行なし) フラグが有効

手順

  • ウィザードの Operator のステップで、Install OpenShift Virtualization チェックボックスを有効にします。

関連情報

  • OpenShift Virtualization 用にクラスターを準備する方法の詳細については、OpenShift ドキュメント を参照してください。

6.2. マルチクラスターエンジン(MCE)のインストール

クラスターの設定時に、Multicluster Engine (MCE) Operator を有効にできます。Multicluster Engine (MCE) Operator を使用すると、現在インストールしているクラスターから追加のクラスターをインストールできます。

前提条件

  • OpenShift バージョン 4.10 以降
  • マルチノードの OpenShift クラスター用に、追加の 4 CPU コアおよび 16GB の RAM。
  • 単一ノードの OpenShift クラスター用に追加の 8 CPU コアと 32GB RAM。

ストレージに関する考慮事項

インストールの前に、マルチクラスターエンジンからクラスターを管理するために必要なストレージを考慮する必要があります。ストレージの自動化には、以下のいずれかのシナリオを選択できます。

  • マルチノードクラスターに OpenShift Data Foundation (ODF)をインストールします。ODF はクラスターに推奨されるストレージですが、追加のサブスクリプションが必要です。詳細は、この章の Installing OpenShift Data Foundation を参照してください。
  • 単一ノード OpenShift (SNO)クラスターに論理ボリューム管理ストレージ(LVMS)をインストールします。
  • ストレージを設定せずにマルチノードクラスターにマルチクラスターエンジンをインストールします。次に、選択したストレージを設定し、インストール後に Central Infrastructure Management (CIM)サービスを有効にします。詳細は、この章 の追加リソース を参照してください。

手順

  1. Assisted Installer UI を使用している場合は、以下を実行します。

    • ウィザードの Operator ステップで、Install multicluster engine チェックボックスを有効にします。
  2. Assisted Installer API を使用している場合:

    • 新規クラスターを登録する場合は、olm_operators: [{"name": "mce"}] ステートメントを使用します。以下に例を示します。

      $ 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" : "x86_64"
          "high_availability_mode": "None",
          "base_dns_domain": "example.com",
          "olm_operators: [{"name": "mce"}]",
          "pull_secret": $pull_secret[0] | tojson
      }
      ')" | jq '.id'

インストール後の手順

  • Multicluster Engine で支援付きインストーラーテクノロジーを使用するには、Central Infrastructure Management サービスを有効にします。詳細は、Central Infrastructure Management サービスの有効化 を 参照してください。
  • ホストされたコントロールプレーンを使用して OpenShift Container Platform クラスターをデプロイするには、ホステッドコントロールプレーンを設定します。詳細は、Hosted Control Planes を参照してください。

関連情報

6.3. OpenShift Data Foundation のインストール

クラスターを設定するときに、OpenShift Data Foundation を有効にすることができます。有効な場合、自動インストーラー:環境が以下に概説する前提条件を満たしていることを検証します (確認する必要がある空のデバイスを除く)。使用可能なすべてのディスクを使用するようにストレージを設定します。

前提条件

  • クラスターが 3 ノードの OpenShift クラスターであるか、少なくとも 3 つのワーカーノードがある。
  • 各ホストには、少なくとも 25 GB の非インストールディスクが少なくとも 1 つあります。
  • 使用するデバイスは空である必要があります。ディスクには物理ボリューム (PV)、ボリュームグループ (VG)、または論理ボリューム (LV) を含めないでください。
  • 各ホストには、他の CPU 要件に加えて、3 ノード OpenShift の場合は 6 つの CPU コア、または標準クラスターの場合は 8 つの CPU コアがあります。
  • 各ホストには、他の RAM 要件に加えて、19 GiB RAM があります。
  • 各ホストには、他の CPU と RAM の要件に加えて、ストレージディスクごとに 2 つの CPU コアと 5GiB RAM があります。
  • 各ホストにコントロールプレーンまたはワーカーのロールを割り当てました (自動割り当てではありません)。

手順

  • ウィザードの operators ステップで、Install OpenShift Data Foundation チェックボックスを有効にします。

関連情報

第7章 検出イメージの設定

支援付きインストーラーは初期イメージを使用して、OpenShift Container Platform のインストールを試行する前にハードウェアおよびネットワークの検証を実行するエージェントを実行します。Ignition を使用して、検出イメージをカスタマイズできます。

注記

検出イメージへの変更は、システムに保持されません。

7.1. Ignition 設定ファイルの作成

Ignition は低レベルのシステム設定ユーティリティーであり、一時的な初期ルートファイルシステムである initramfs の一部です。最初の起動時に Ignition が実行されると、Ignition 設定ファイルで設定データが検出され、switch_root が呼び出されてホストのルートファイルシステムにピボットされる前に、それがホストに適用されます。

Ignition は、JSON 設定仕様 ファイルを使用して、最初の起動時に発生する一連の変更を表します。

重要

3.2 より新しいバージョンの Ignition はサポートされておらず、エラーが発生します。

手順

  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

7.2. Ignition を使用した検出イメージの変更

Ignition 設定ファイルを作成したら、支援付きインストーラー API を使用してインフラストラクチャー環境にパッチを適用することにより、検出イメージを変更できます。

前提条件

  • UI を使用してクラスターを作成した場合は、API 認証が設定されています。
  • インフラストラクチャー環境があり、インフラストラクチャー環境 IDINFRA_ENV_ID 変数にエクスポートしました。
  • 有効な Ignition ファイルがあり、ファイル名を $IGNITION_FILE としてエクスポートしました。

手順

  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. 更新された検出イメージをダウンロードします。

第8章 検出イメージを使用したホストの起動

支援付きインストーラーは初期イメージを使用して、OpenShift Container Platform のインストールを試行する前にハードウェアおよびネットワークの検証を実行するエージェントを実行します。次の 3 つの方法を使用して、検出イメージでホストを起動できます。

  • USB ドライブ
  • Redfish 仮想メディア
  • iPXE

8.1. USB ドライブに ISO イメージを作成する

検出 ISO イメージを含む USB ドライブを使用して、支援付きインストーラーエージェントをインストールできます。USB ドライブを使用してホストを起動すると、ソフトウェアをインストールするためのホストの準備が整います。

手順

  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 ドライブを使用してクラスターホストに 支援付きインストーラーエージェントをインストールできます。

8.2. USB ドライブでの起動

起動可能な USB ドライブを使用して 支援付きインストーラーにノードを登録するには、次の手順を使用します。

手順

  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"
      ]

8.3. Redfish API を使用した HTTP ホスト ISO イメージからの起動

Redfish Baseboard Management Controller (BMC) API を使用してインストールした ISO を使用して、ネットワーク内のホストをプロビジョニングできます。

前提条件

  • インストール Red Hat Enterprise Linux CoreOS (RHCOS) ISO をダウンロードしている。

手順

  1. ネットワークでアクセス可能な HTTP サーバーに ISO ファイルをコピーします。
  2. ホストされている ISO ファイルからホストを起動します。以下に例を示します。

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

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

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

      <bmc_username>:<bmc_password>
      ターゲットホスト BMC のユーザー名とパスワードです。
      <hosted_iso_file>
      ホストされたインストール ISO の URL です (例: http://webserver.example.com/rhcos-live-minimal.iso)。ISO は、ターゲットホストマシンからアクセスできる必要があります。
      <host_bmc_address>
      ターゲットホストマシンの BMC IP アドレスです。
    2. 次のコマンドを実行して、VirtualMedia デバイスから起動するようにホストを設定します。

      $ curl -k -u <bmc_username>:<bmc_password> \
      -X PATCH -H 'Content-Type: application/json' \
      -d '{"Boot": {"BootSourceOverrideTarget": "Cd", "BootSourceOverrideMode": "UEFI", "BootSourceOverrideEnabled": "Once"}}' \
      <host_bmc_address>/redfish/v1/Systems/System.Embedded.1
    3. ホストを再起動します。

      $ curl -k -u <bmc_username>:<bmc_password> \
      -d '{"ResetType": "ForceRestart"}' \
      -H 'Content-type: application/json' \
      -X POST <host_bmc_address>/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset
    4. オプション: ホストの電源がオフになっている場合は、{"ResetType": "On"} スイッチを使用して起動できます。以下のコマンドを実行します。

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

8.4. iPXE を使用したホストの起動

支援付きインストーラーは、インフラストラクチャー環境の検出イメージを起動するために必要なすべての成果物を含む iPXE スクリプトを提供します。現在の iPXE の HTTPS 実装には制限があるため、HTTP サーバーで必要なアーティファクトをダウンロードして公開することをお勧めします。現在、iPXE が HTTPS プロトコルをサポートしていても、サポートされているアルゴリズムは古く、推奨されていません。

サポートされている暗号の完全なリストは https://ipxe.org/crypto にあります。

前提条件

  • API を使用してインフラストラクチャー環境を作成したか、UI を使用してクラスターを作成しました。
  • インフラストラクチャー環境 ID がシェルに $INFRA_ENV_ID としてエクスポートされている。
  • API にアクセスするときに使用する認証情報があり、シェルで $API_TOKEN としてトークンをエクスポートしました。
  • イメージをホストする HTTP サーバーがあります。
注記

UI で設定する場合、$INFRA_ENV_ID および $API_TOKEN 変数はすでに指定されています。

注記

IBM Power は PXE のみをサポートします。また、IBM Power では、/var/lib/tftpboot に grub2 をインストール し、PXE 用の DHCP および TFTP をインストールする必要もあります。

手順

  1. UI から直接 iPXE スクリプトをダウンロードするか、支援付きインストーラーから 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

第9章 ホストへのロールの割り当て

検出されたホストにロールを割り当てることができます。これらのロールはクラスター内のホストの機能を定義します。ロールは、標準の Kubernetes タイプのいずれかにすることができます: control plane (master) または worker

ホストは、選択したロールの最小要件を満たしている必要があります。このドキュメントの前提条件セクションを参照するか、プリフライト要件 API を使用して、ハードウェア要件を見つけることができます。

ロールを選択しない場合は、システムが自動的に選択します。インストールの開始前であれば、いつでもロールを変更できます。

9.1. UI を使用してロールを選択する

ホストが検出を終了した後、ロールを選択できます。

手順

  1. Host Discovery タブに移動し、Host Inventory テーブルまで下にスクロールします。
  2. 必要なホストの Auto-assign ドロップダウンを選択します。

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

9.2. API を使用してロールを選択する

/v2/infra-envs/{infra_env_id}/hosts/{host_id} エンドポイントを使用して、ホストのロールを選択できます。ホストは、次の 2 つのロールのいずれかになります。

  • master: マスター ロールを持つホストは、コントロールプレーンホストとして動作します。
  • worker: worker ロールを持つホストは、ワーカーホストとして動作します。

デフォルトでは、支援付きインストーラーはホストを auto-assign に設定します。これは、ホストが master ロールか worker ロールかをインストーラが自動的に判断することを意味します。この手順を使用して、ホストのロールを設定します。

前提条件

  • ホストをクラスターに追加した。

手順

  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 に置き換えます。

9.3. ロールの自動割り当て

自分でロールを割り当てない場合、支援付きインストーラーはホストのロールを自動的に選択します。ロールの選択メカニズムでは、ホストのメモリー、CPU、およびディスク容量が考慮されます。これは、コントロールプレーンノードの最小要件を満たす最も弱い 3 つのホストにコントロールプレーンのロールを割り当てることを目的としています。他のすべてのホストは、デフォルトでワーカーノードになります。目標は、コントロールプレーンを実行するのに十分なリソースを提供し、実際のワークロードを実行するために容量集約型のホストを予約することです。

自動割り当ての決定は、インストール前にいつでも上書きできます。

検証により、自動選択が有効なものであることが確認されます。

9.4. 関連情報

前提条件

第10章 インストール前の検証

10.1. インストール前の検証の定義

支援付きインストーラーは、クラスターのインストールを可能な限り単純かつ効率的でエラーのないものにすることを目的としています。支援付きインストーラーは、インストールを開始する前に、設定と収集されたテレメトリーに対してバリデーションチェックを実行します。

支援付きインストーラーは、コントロールプレーントポロジー、ネットワーク設定、ホスト名など、インストール前に提供された情報を使用します。また、インストールしようとしているホストからのリアルタイムテレメトリーも使用します。

ホストが検出 ISO を起動すると、ホスト上でエージェントが開始されます。エージェントは、ホストの状態に関する情報を 支援付きインストーラーに送信します。

支援付きインストーラーは、このすべての情報を使用して、インストール前のリアルタイムの検証を計算します。すべての検証は、インストールに対してブロッキングまたは非ブロッキングのいずれかです。

10.2. ブロッキングおよび非ブロッキングの検証

ブロッキング検証により、インストールの進行が妨げられます。つまり、続行するには、問題を解決してブロッキング検証に合格する必要があります。

非ブロッキングバリデーションは警告であり、問題の原因となる可能性があることを通知します。

10.3. バリデーションの種類

支援付きインストーラーは、次の 2 種類のバリデーションを実行します。

ホスト

ホストのバリデーションにより、特定のホストの設定がインストールに対して有効であることを確認します。

クラスター

クラスターのバリデーションにより、クラスター全体の設定がインストールに対して有効であることを確認します。

10.4. ホストのバリデーション

10.4.1. REST API を使用してホストバリデーションを取得する

注記

Web ベースの UI を使用する場合、これらのバリデーションの多くは名前で表示されません。ラベルと一致する検証のリストを取得するには、次の手順を使用します。

前提条件

  • jq ユーティリティーをインストールした。
  • API を使用してインフラストラクチャー環境を作成したか、UI を使用してクラスターを作成した。
  • ホストが検出 ISO で起動されている
  • シェルでクラスター ID を CLUSTER_ID としてエクスポートした。
  • API にアクセスするときに使用する認証情報があり、トークンをシェルで API_TOKEN としてエクスポートした。

手順

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

    $ source refresh-token
  2. すべてのホストのすべてのバリデーションを取得します。

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \
      | jq -r .[].validations_info \
      | jq 'map(.[])'
  3. すべてのホストのパスしていないバリデーションを取得します。

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID/hosts \
      | jq -r .[].validations_info \
      | jq 'map(.[]) | map(select(.status=="failure" or .status=="pending")) | select(length>0)'

10.4.2. ホストバリデーションの詳細

パラメーターバリデーションタイプ説明

connected

非ブロッキング

ホストが最近支援付きインストーラーと通信したことを確認します。

has-inventory

非ブロッキング

支援付きインストーラーがホストからインベントリーを受信したことを確認します。

has-min-cpu-cores

非ブロッキング

CPU コアの数が最小要件を満たしていることを確認します。

has-min-memory

非ブロッキング

メモリーの量が最小要件を満たしていることを確認します。

has-min-valid-disks

非ブロッキング

少なくとも 1 つの使用可能なディスクが適格基準を満たしていることを確認します。

has-cpu-cores-for-role

ブロッキング

コアの数がホストのロールの最小要件を満たしていることを確認します。

has-memory-for-role

ブロッキング

メモリーの量がホストのロールの最小要件を満たしていることを確認します。

ignition-downloadable

ブロッキング

Day 2 ホストの場合、ホストが Day 1 クラスターからイグニッション設定をダウンロードできることを確認します。

belongs-to-majority-group

ブロッキング

マジョリティグループは、クラスター上で最大のフルメッシュ接続グループであり、すべてのメンバーが他のすべてのメンバーと通信できます。この検証では、マルチノードの Day 1 クラスター内のホストが過半数グループに属していることを確認します。

valid-platform-network-settings

ブロッキング

プラットフォームがネットワーク設定に対して有効であることを確認します。

ntp-synced

非ブロッキング

ホストで時刻を同期するために NTP サーバーが正常に使用されたかどうかを確認します。

container-images-available

非ブロッキング

コンテナーイメージがイメージレジストリーから正常にプルされたかどうかを確認します。

sufficient-installation-disk-speed

ブロッキング

以前のインストールのディスク速度メトリックが要件を満たしていることを確認します (存在する場合)。

sufficient-network-latency-requirement-for-role

ブロッキング

クラスター内のホスト間の平均ネットワーク遅延が要件を満たしていることを確認します。

sufficient-packet-loss-requirement-for-role

ブロッキング

クラスター内のホスト間のネットワークパケット損失が要件を満たしていることを確認します。

has-default-route

ブロッキング

ホストにデフォルトルートが設定されていることを確認します。

api-domain-name-resolved-correctly

ブロッキング

ユーザー管理ネットワークを使用するマルチノードクラスターの場合。ホストがクラスターの API ドメイン名を解決できることを確認します。

api-int-domain-name-resolved-correctly

ブロッキング

ユーザー管理ネットワークを使用するマルチノードクラスターの場合。ホストがクラスターの内部 API ドメイン名を解決できることを確認します。

apps-domain-name-resolved-correctly

ブロッキング

ユーザー管理ネットワークを使用するマルチノードクラスターの場合。ホストがクラスターの内部アプリドメイン名を解決できることを確認します。

compatible-with-cluster-platform

非ブロッキング

ホストがクラスタープラットフォームと互換性があることを確認します

dns-wildcard-not-configured

ブロッキング

OpenShift で既知の問題が発生するため、ワイルドカード DNS *.<cluster_name>.<base_domain> が設定されていないことを確認します。

disk-encryption-requirements-satisfied

非ブロッキング

設定されているホストとディスクの暗号化のタイプが要件を満たしていることを確認します。

non-overlapping-subnets

ブロッキング

このホストに重複するサブネットがないことを確認します。

hostname-unique

ブロッキング

ホスト名がクラスター内で一意であることを確認します。

hostname-valid

ブロッキング

ホスト名の有効性をチェックします。つまり、ホスト名の一般的な形式と一致し、禁止されていないことを意味します。

belongs-to-machine-cidr

ブロッキング

ホスト IP がマシン CIDR のアドレス範囲内にあることを確認します。

lso-requirements-satisfied

ブロッキング

クラスターがローカルストレージ Operator の要件を満たしていることを検証します。

odf-requirements-satisfied

ブロッキング

クラスターが Openshift Data Foundation Operator の要件を満たしていることを検証します。

  • クラスターには最低 3 つのホストがあります。
  • クラスターには 3 つのマスターのみ、または少なくとも 3 つのワーカーがあります。
  • クラスターには 3 つの適格なディスクがあり、各ホストには適格なディスクが必要です。
  • 3 つ以上のホストを持つクラスターでは、ホストのロールを自動割り当てにしないでください。

cnv-requirements-satisfied

ブロッキング

クラスターがコンテナーネイティブ仮想化の要件を満たしていることを検証します。

  • ホストの BIOS で CPU 仮想化が有効になっている必要があります。
  • ホストには、コンテナーネイティブ仮想化に使用できる十分な CPU コアと RAM が必要です。
  • 必要に応じてホストパスプロビジョナーを検証します。

lvm-requirements-satisfied

ブロッキング

クラスターが論理ボリュームマネージャー Operator の要件を満たしていることを検証します。

  • ホストには、パーティション化もフォーマットもされていない、少なくとも 1 つの追加の空のディスクがあります。

vsphere-disk-uuid-enabled

非ブロッキング

有効な各ディスクで disk.EnableUUIDtrue に設定されていることを確認します。vSphere では、これにより各ディスクに UUID が割り当てられます。

compatible-agent

ブロッキング

検出エージェントのバージョンがエージェントの Docker イメージのバージョンと互換性があることを確認します。

no-skip-installation-disk

ブロッキング

インストールディスクがディスクフォーマットをスキップしていないことを確認します。

no-skip-missing-disk

ブロッキング

フォーマットをスキップするようにマークされたすべてのディスクがインベントリーにあることを確認します。ディスク ID は再起動時に変更される可能性があり、このバリデーションにより、それによって引き起こされる問題が防止されます。

media-connected

ブロッキング

ホストへのインストールメディアの接続を確認します。

machine-cidr-defined

非ブロッキング

クラスターのマシンネットワーク定義が存在することを確認します。

id-platform-network-settings

ブロッキング

プラットフォームがネットワーク設定と互換性があることを確認します。一部のプラットフォームは、Single Node Openshift をインストールする場合、またはユーザー管理ネットワークを使用する場合にのみ許可されます。

10.5. クラスターのバリデーション

10.5.1. REST API を使用してクラスターバリデーションを取得する

注記: Web ベースの UI を使用する場合、これらのバリデーションの多くは名前で表示されません。ラベルと一致するバリデーションのリストを取得するには、次の手順を使用します。

前提条件

  • jq ユーティリティーをインストールした。
  • API を使用してインフラストラクチャー環境を作成したか、UI を使用してクラスターを作成した。
  • シェルでクラスター ID を CLUSTER_ID としてエクスポートした。
  • API にアクセスするときに使用する認証情報があり、トークンをシェルで API_TOKEN としてエクスポートした。

手順

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

    $ source refresh-token
  2. すべてのクラスターバリデーションを取得します。

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \
      | jq -r .validations_info \
      | jq 'map(.[])'
  3. パスしなかったクラスターバリデーションを取得します。

    $ curl \
      --silent \
      --header "Authorization: Bearer $API_TOKEN" \
      https://api.openshift.com/api/assisted-install/v2/clusters/$CLUSTER_ID \
      | jq -r .validations_info \
      | jq '. | map(.[] | select(.status=="failure" or .status=="pending")) | select(length>0)'

10.5.2. クラスターバリデーションの詳細

パラメーターバリデーションタイプ説明

machine-cidr-defined

非ブロッキング

クラスターのマシンネットワーク定義が存在することを確認します。

cluster-cidr-defined

非ブロッキング

クラスターのクラスターネットワーク定義が存在することを確認します。

service-cidr-defined

非ブロッキング

クラスターのサービスネットワーク定義が存在することを確認します。

cidrs の重複なし

ブロッキング

定義されたネットワークが重複していないことを確認します。

networks-same-address-families

ブロッキング

定義されたネットワークが同じアドレスファミリーを共有していることを確認します (有効なアドレスファミリーは IPv4、IPv6 です)。

network-prefix-valid

ブロッキング

クラスターネットワーク 接頭辞をチェックして、それが有効であり、すべてのホストに十分なアドレス空間を許可していることを確認します。

machine-cidr-equals-to-calculated-cidr

ブロッキング

非ユーザー管理のネットワーククラスターの場合。apiVIP または ingressVIP が存在する場合、それらがマシン CIDR のメンバーであることを確認します。

api-vips-defined

非ブロッキング

非ユーザー管理のネットワーククラスターの場合。apiVIP が存在することを確認します。

api-vips-valid

ブロッキング

非ユーザー管理のネットワーククラスターの場合。apiVIPs がマシン CIDR に属しており、使用されていないかどうかを確認します。

ingress-vips-defined

ブロッキング

非ユーザー管理のネットワーククラスターの場合。ingressVIP が存在することを確認します。

ingress-vips-valid

非ブロッキング

非ユーザー管理のネットワーククラスターの場合。ingressVIP がマシンの CIDR に属しており、使用されていないかどうかを確認します。

all-hosts-are-ready-to-install

ブロッキング

クラスター内のすべてのホストがインストール準備完了ステータスにあることを確認します。

sufficient-masters-count

ブロッキング

この検証は、マルチノードクラスターにのみ適用されます。

  • クラスターには正確に 3 つのマスターが必要です。
  • クラスターにワーカーノードがある場合は、少なくとも 2 つのワーカーノードが存在する必要があります。

dns-domain-defined

非ブロッキング

クラスターのベース DNS ドメインが存在することを確認します。

pull-secret-set

非ブロッキング

プルシークレットが存在することを確認します。プルシークレットが有効または承認されていることを確認しません。

ntp-server-configured

ブロッキング

各ホストクロックの同期が 4 分以内であることを確認します。

lso-requirements-satisfied

ブロッキング

クラスターがローカルストレージ Operator の要件を満たしていることを検証します。

odf-requirements-satisfied

ブロッキング

クラスターが Openshift Data Foundation Operator の要件を満たしていることを検証します。

  • クラスターには最低 3 つのホストがあります。
  • クラスターには 3 つのマスターのみ、または少なくとも 3 つのワーカーがあります。
  • クラスターには 3 つの適格なディスクがあり、各ホストには適格なディスクが必要です。

cnv-requirements-satisfied

ブロッキング

クラスターがコンテナーネイティブ仮想化の要件を満たしていることを検証します。

  • クラスターの CPU アーキテクチャーは x86 です

lvm-requirements-satisfied

ブロッキング

クラスターが論理ボリュームマネージャー Operator の要件を満たしていることを検証します。

  • クラスターは単一ノードである必要があります。
  • クラスターは Openshift >= 4.11.0 を実行している必要があります。

network-type-valid

ブロッキング

ネットワークタイプが存在する場合、その有効性をチェックします。

  • ネットワークタイプは OpenshiftSDN または OVNKubernetes である必要があります。
  • OpenshiftSDN は、IPv6 または単一ノードの Openshift をサポートしていません。
  • OVNKubernetes は VIP DHCP 割り当てをサポートしていません。

第11章 ネットワーク設定

このセクションでは、支援付きインストーラーを使用したネットワーク設定の基本について説明します。

11.1. クラスターネットワーク

OpenShift で使用されるさまざまなネットワークタイプとアドレスがあり、以下の表に一覧表示されています。

DNS説明

clusterNetwork

 

Pod IP アドレスの割り当てに使用する IP アドレスプール。

serviceNetwork

 

サービスの IP アドレスプール。

machineNetwork

 

クラスターを形成するマシンの IP アドレスブロック。

apiVIP

api.<clustername.clusterdomain>

API 通信に使用する VIP。この設定は、デフォルト名が正しく解決されるように DNS で指定するか、事前に設定する必要があります。デュアルスタックネットワークを使用してデプロイする場合、これは IPv4 アドレスである必要があります。

apiVIPs

api.<clustername.clusterdomain>

API 通信に使用する VIP。この設定は、デフォルト名が正しく解決されるように DNS で指定するか、事前に設定する必要があります。デュアルスタックネットワークを使用する場合、最初のアドレスは IPv4 アドレスで、2 番目のアドレスは IPv6 アドレスである必要があります。apiVIP 設定も行う必要があります。

ingressVIP

*.apps.<clustername.clusterdomain>

Ingress トラフィックに使用する VIP。デュアルスタックネットワークを使用してデプロイする場合、これは IPv4 アドレスである必要があります。

ingressVIPs

*.apps.<clustername.clusterdomain>

Ingress トラフィックに使用する VIP。デュアルスタックネットワークを使用してデプロイする場合、最初のアドレスは IPv4 アドレスで、2 番目のアドレスは IPv6 アドレスである必要があります。ingressVIP 設定も行う必要があります。

注記

OpenShift Container Platform 4.12 では、デュアルスタックネットワークで複数の IP アドレスを受け入れる新しい apiVIPs および ingressVIPs 設定が導入されています。デュアルスタックネットワークを使用する場合、最初の IP アドレスは IPv4 アドレスで、2 番目の IP アドレスは IPv6 アドレスである必要があります。apiVIPIngressVIP は新しい設定に置き換えられますが、API を使用して設定を変更する場合は、新しい設定と古い設定の両方を設定する必要があります。

目的のネットワークスタックに応じて、さまざまなネットワークコントローラーを選択できます。現在、Assisted Service は、以下の設定のいずれかを使用して OpenShift Container Platform クラスターをデプロイできます。

  • IPv4
  • IPv6
  • Dual-stack (IPv4 + IPv6)

サポートされるネットワークコントローラーは、選択したスタックによって異なります。以下の表にまとめられています。詳細な Container Network Interface (CNI) ネットワークプロバイダー機能の比較は、OCP Networking のドキュメント を参照してください。

StackSDNOVN

IPv4

はい

はい

IPv6

いいえ

はい

デュアルスタック

いいえ

はい

注記

OVN は、OpenShift Container Platform 4.12 以降のリリースにおいてデフォルトの Container Network Interface (CNI) です。

11.1.1. 制限

11.1.1.1. SDN

  • Single Node OpenShift (SNO) では、SDN コントローラーはサポートされていません。
  • SDN コントローラーは IPv6 をサポートしていません。

11.1.1.2. OVN-Kubernetes

OCP ドキュメントの OVN-Kubernetes の制限に関するセクションを 参照してください。

11.1.2. クラスターネットワーク

クラスターネットワークは、クラスターにデプロイされたすべての Pod が IP アドレスを取得するネットワークです。ワークロードがクラスターを形成する多くのノードにまたがって存在する可能性があることを考えると、ネットワークプロバイダーが Pod の IP アドレスに基づいて個々のノードを簡単に見つけられることが重要です。これを行うために、clusterNetwork.cidr は、clusterNetwork.hostPrefix で定義されたサイズのサブネットにさらに分割されます。

ホスト 接頭辞は、クラスター内の個々のノードに割り当てられるサブネットの長さを指定します。クラスターがマルチノードクラスターにアドレスを割り当てる方法の例:

---
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
---

上記のスニペットを使用して 3 ノードクラスターを作成すると、次のネットワークトポロジーが作成される場合があります。

  • ノード #1 でスケジュールされた Pod は 10.128.0.0/23 から IP を取得します
  • ノード #2 でスケジュールされた Pod は 10.128.2.0/23 から IP を取得します
  • ノード #3 でスケジュールされた Pod は、10.128.4.0/23 から IP を取得します

OVN-K8 内部の説明はこのドキュメントの範囲外ですが、上記のパターンは、Pod とそれに対応するノード間のマッピングの大きなリストを保持することなく、異なるノード間で Pod-to-Pod トラフィックをルーティングする方法を提供します。

11.1.3. マシンネットワーク

マシンネットワークは、クラスターを設定するすべてのホストが相互に通信するために使用するネットワークです。これは、API と Ingress VIP を含める必要があるサブネットでもあります。

11.1.4. マルチノードクラスターと比較した SNO

単一ノードの OpenShift をデプロイするか、マルチノードクラスターをデプロイするかによって、異なる値が必須になります。以下の表で、これについて詳しく説明します。

パラメーターSNODHCP モードのマルチノードクラスターDHCP モードを使用しないマルチノードクラスター

clusterNetwork

必須

必須

必須

serviceNetwork

必須

必須

必須

machineNetwork

自動割り当て可能 (*)

自動割り当て可能 (*)

自動割り当て可能 (*)

apiVIP

禁止されている

禁止されている

必須

apiVIPs

禁止されている

禁止されている

4.12 以降のリリースで必須

ingressVIP

禁止されている

禁止されている

必須

ingressVIPs

禁止されている

禁止されている

4.12 以降のリリースで必須

(*) マシンネットワーク CIDR の自動割り当ては、ホストネットワークが 1 つしかない場合に発生します。それ以外の場合は、明示的に指定する必要があります。

11.1.5. エアギャップ環境

インターネットアクセスなしでクラスターをデプロイメントするためのワークフローには、このドキュメントの範囲外の前提条件がいくつかあります。いくつかの洞察については、Zero Touch Provisioning the hard way Git リポジトリー を参照してください。

11.2. DHCP VIP 割り当て

VIP DHCP 割り当ては、DHCP サーバーからこれらの IP アドレスを自動的に割り当てるサービスの機能を活用することで、ユーザーが API および Ingress 用の仮想 IP を手動で提供する要件をスキップできるようにする機能です。

この機能を有効にすると、クラスター設定から api_vipingress_vip を使用する代わりに、サービスはリース割り当てリクエストを送信し、応答に基づいて VIP を適宜使用します。サービスは、マシンネットワークから IP アドレスを割り当てます。

これは OpenShift Container Platform の機能ではなく、設定を容易にするために Assisted Service に実装されていることに注意してください。

11.2.1. 自動割り当てを有効にするペイロードの例

---
{
  "vip_dhcp_allocation": true,
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    }
  ],
  "service_networks": [
    {
      "cidr": "172.30.0.0/16"
    }
  ],
  "machine_networks": [
    {
      "cidr": "192.168.127.0/24"
    }
  ]
}
---

11.2.2. 自動割り当てを無効にするペイロードの例

---
{
  "api_vip": "192.168.127.100",
  "api_vips": [
    {
        "ip": "192.168.127.100"
    }
  ],
  "ingress_vip": "192.168.127.101",
  "ingress_vips": [
    {
        "ip": "192.168.127.101"
    }
  ],
  "vip_dhcp_allocation": false,
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    }
  ],
  "service_networks": [
    {
      "cidr": "172.30.0.0/16"
    }
  ]
}
---
注記

OpenShift Container Platform 4.12 では、従来の api_vip および ingress_vip 設定と、新しい api_vips および ingress_vips 設定の両方を設定する必要があります。

11.3. 関連情報

11.4. ユーザー管理ネットワークとクラスター管理ネットワークの違いについて

ユーザー管理ネットワーキングは、非標準のネットワークトポロジーを使用する顧客が OpenShift Container Platform クラスターをデプロイできるようにする、支援付きインストーラーの機能です。以下のようになります。

  • VIP アドレスの処理に keepalived と VRRP を使用したくない外部ロードバランサーをお持ちのお客様。
  • 多くの異なる L2 ネットワークセグメントに分散されたクラスターノードを使用したデプロイメント。

11.4.1. 検証

支援付きインストーラーでは、インストールの開始を許可する前に、さまざまなネットワーク検証が行われます。ユーザー管理ネットワークを有効にすると、次の検証が変更されます。

  • L2 チェック (ARP) の代わりに L3 接続チェック (ICMP) が実行されます。

11.5. 静的ネットワーク設定

検出 ISO を生成または更新するときに、静的ネットワーク設定を使用できます。

11.5.1. 前提条件

  • あなたは NMState に精通しています。

11.5.2. NMState 設定

YAML 形式の NMState ファイルは、ホストに必要なネットワーク設定を指定します。これには、検出時にインターフェイスの実際の名前に置き換えられるインターフェイスの論理名があります。

11.5.2.1. NMState 設定の例

---
dns-resolver:
  config:
    server:
    - 192.168.126.1
interfaces:
- ipv4:
    address:
    - ip: 192.168.126.30
      prefix-length: 24
    dhcp: false
    enabled: true
  name: eth0
  state: up
  type: ethernet
- ipv4:
    address:
    - ip: 192.168.141.30
      prefix-length: 24
    dhcp: false
    enabled: true
  name: eth1
  state: up
  type: ethernet
routes:
  config:
  - destination: 0.0.0.0/0
    next-hop-address: 192.168.126.1
    next-hop-interface: eth0
    table-id: 254
---

11.5.3. MAC インターフェイスのマッピング

MAC インターフェイスマップは、NMState 設定で定義された論理インターフェイスを、ホスト上に存在する実際のインターフェイスにマップする属性です。

マッピングでは、ホストに存在する物理インターフェイスを常に使用する必要があります。たとえば、NMState 設定がボンドまたは VLAN を定義する場合、マッピングには親インターフェイスのエントリーのみを含める必要があります。

11.5.3.1. MAC インターフェイスマッピングの例

---
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
    }
]
---

11.5.4. 追加の NMState 設定の例

以下の例は、部分的な設定を示すことのみを目的としています。そのまま使用することを意図したものではなく、使用する環境に合わせて常に調整する必要があります。誤って使用すると、マシンがネットワークに接続できなくなる可能性があります。

11.5.4.1. タグ VLAN

---
    interfaces:
    - ipv4:
        address:
        - ip: 192.168.143.15
          prefix-length: 24
        dhcp: false
        enabled: true
      ipv6:
        enabled: false
      name: eth0.404
      state: up
      type: vlan
      vlan:
        base-iface: eth0
        id: 404
---

11.5.4.2. ネットワークボンド

---
    interfaces:
    - ipv4:
        address:
        - ip: 192.168.138.15
          prefix-length: 24
        dhcp: false
        enabled: true
      ipv6:
        enabled: false
      link-aggregation:
        mode: active-backup
        options:
          all_slaves_active: delivered
          miimon: "140"
        slaves:
        - eth0
        - eth1
      name: bond0
      state: up
      type: bond
---

11.6. API を使用した静的ネットワーク設定の適用

支援付きインストーラーAPI を使用して静的ネットワーク設定を適用できます。

前提条件

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

11.7. 関連情報

11.8. デュアルスタックネットワークへの変換

デュアルスタック IPv4/IPv6 設定により、Pod が IPv4 と IPv6 の両方のサブネットに存在するクラスターのデプロイが可能になります。

11.8.1. 前提条件

11.8.2. 単一ノード OpenShift のペイロードの例

---
{
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    },
    {
      "cidr": "fd01::/48",
      "host_prefix": 64
    }
  ],
  "service_networks": [
    {"cidr": "172.30.0.0/16"}, {"cidr": "fd02::/112"}
  ],
  "machine_networks": [
    {"cidr": "192.168.127.0/24"},{"cidr": "1001:db8::/120"}
  ]
}
---

11.8.3. 多くのノードで設定される OpenShift Container Platform クラスターのペイロードの例

---
{
  "vip_dhcp_allocation": false,
  "network_type": "OVNKubernetes",
  "user_managed_networking": false,
  "api_vip": "192.168.127.100",
  "api_vips": [
     {
        "ip": "192.168.127.100"
     },
     {
        "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
     }
  ],
  "ingress_vip": "192.168.127.101",
  "ingress_vips": [
     {
        "ip": "192.168.127.101"
     },
     {
        "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7335"
     }
  ],
  "cluster_networks": [
    {
      "cidr": "10.128.0.0/14",
      "host_prefix": 23
    },
    {
      "cidr": "fd01::/48",
      "host_prefix": 64
    }
  ],
  "service_networks": [
    {"cidr": "172.30.0.0/16"}, {"cidr": "fd02::/112"}
  ],
  "machine_networks": [
    {"cidr": "192.168.127.0/24"},{"cidr": "1001:db8::/120"}
  ]
}
---

11.8.4. 制限

デュアルスタックネットワークを使用する場合、api_vip IP アドレスと ingress_vip IP アドレスの設定は、プライマリー IP アドレスファミリーである必要があり、IPv4 アドレスである必要があります。現在、Red Hat は、IPv6 をプライマリー IP アドレスファミリーとして使用するデュアルスタック VIP またはデュアルスタックネットワークをサポートしていません。Red Hat は、IPv4 をプライマリー IP アドレスファミリーとして、IPv6 をセカンダリー IP アドレスファミリーとして使用するデュアルスタックネットワークをサポートしています。したがって、IP アドレス値を入力するときは、IPv6 エントリーの前に IPv4 エントリーを配置する必要があります。

OpenShift Container Platform 4.12 では、VIP アドレスでデュアルスタックネットワーキングを使用する場合は、従来の api_vip および ingress_vip 設定と、新しい api_vips および ingress_vips 設定の両方を設定する必要があります。従来の api_vip および ingress_vip 設定はそれぞれ 1 つの値しか受け入れないため、IPv4 アドレスである必要があります。

11.9. 関連情報

第12章 クラスターの拡張

ユーザーインターフェイスまたは API を使用してホストを追加して、支援付きインストーラーでインストールしたクラスターを拡張できます。

12.1. 前提条件

  • Assisted Installer クラスターにアクセスできる必要があります。
  • OpenShift CLI (oc) をインストールしておく。
  • ワーカーノードの追加先のクラスターに必要なすべての DNS レコードが存在する。
  • 複数の CPU アーキテクチャーを備えたクラスターにワーカーノードを追加する場合は、アーキテクチャーが multi に設定されていることを確認する必要があります。

12.2. 複数のアーキテクチャーの確認

複数のアーキテクチャーを持つクラスターにノードを追加する場合は、architecture 設定が multi に設定されていることを確認してください。

手順

  1. CLI を使用してクラスターにログインします。
  2. architecture 設定を確認します。

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

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

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

12.3. UI を使用したホストの追加

Assisted Installer を使用して作成されたクラスターにホストを追加できます。

重要

支援付きインストーラークラスターへのホストの追加は、OpenShift Container Platform バージョン 4.11 以降を実行しているクラスターでのみサポートされます。

手順

  1. OpenShift Cluster Manager にログインし、拡張するクラスターをクリックします。
  2. Add hosts をクリックし、新規ホストの検出 ISO をダウンロードし、必要に応じて SSH 公開鍵を追加し、クラスター全体のプロキシーを設定します。
  3. オプション: 必要に応じて、Ignition ファイルを変更します。
  4. 検出 ISO を使用してターゲットホストを起動し、ホストがコンソールで検出されるまで待ちます。
  5. ホストロールを選択します。worker または control plane ホストのいずれかになります。
  6. インストールを開始します。
  7. インストールが進行すると、ホストに対して保留中の証明書署名要求 (CSR) が生成されます。プロンプトが表示されたら、保留中の CSR を承認してインストールを完了します。

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

重要

新しいホストは、元のクラスターと同じ方法を使用して暗号化されます。

12.4. API を使用したホストの追加

支援付きインストーラーの REST API を使用して、ホストをクラスターに追加できます。

前提条件

  • OpenShift Cluster Manager CLI (ocm) をインストールしている。
  • クラスター作成権限を持つユーザーで OpenShift Cluster Manager にログインする。
  • jq をインストールする。
  • 拡張するクラスターに必要なすべての DNS レコードが存在することを確認する。

手順

  1. 支援付きインストーラーの 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 を承認してインストールを完了します。

検証

  • 新規ホストが Ready のステータスでクラスターに正常に追加されたことを確認します。

    $ oc get nodes

    出力例

    NAME                           STATUS   ROLES           AGE   VERSION
    control-plane-1.example.com    Ready    master,worker   56m   v1.25.0
    compute-1.example.com          Ready    worker          11m   v1.25.0

12.5. 正常なクラスターへのプライマリーコントロールプレーンノードのインストール

この手順では、プライマリーコントロールプレーンノードを正常な OpenShift Container Platform クラスターにインストールする方法について説明します。

クラスターが正常でない場合、管理する前に追加の操作が必要になります。詳細は、正常なクラスターへのプライマリーコントロールプレーンノードのインストール を参照してください。

前提条件

  • 正しい etcd-operator バージョンを備えた OpenShift Container Platform 4.11 以降を使用している。
  • 少なくとも 3 つのノードを含む正常なクラスターを インストール している。
  • 単一ノードに role: master割り当て ている。

手順

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

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

      $ oc get csr | grep Pending

      出力例

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

    2. 保留中の 全 CSR を承認します。

      $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
      重要

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

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

    $ oc get nodes

    出力例

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

    注記

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

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

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

      apiVersion: metal3.io/v1alpha1
      kind: BareMetalHost
      metadata:
        name: custom-master3
        namespace: openshift-machine-api
        annotations:
      spec:
        automatedCleaningMode: metadata
        bootMACAddress: 00:00:00:00:00:02
        bootMode: UEFI
        customDeploy:
          method: install_coreos
        externallyProvisioned: true
        online: true
        userData:
          name: master-user-data-managed
          namespace: openshift-machine-api
      $ oc create -f <filename>
    2. BareMetalHost CR を適用します。

      $ oc apply -f <filename>
    3. 一意の .machine.name 値を使用して Machine CR を作成します。

      apiVersion: machine.openshift.io/v1beta1
      kind: Machine
      metadata:
        annotations:
          machine.openshift.io/instance-state: externally provisioned
          metal3.io/BareMetalHost: openshift-machine-api/custom-master3
        finalizers:
        - machine.machine.openshift.io
        generation: 3
        labels:
          machine.openshift.io/cluster-api-cluster: test-day2-1-6qv96
          machine.openshift.io/cluster-api-machine-role: master
          machine.openshift.io/cluster-api-machine-type: master
        name: custom-master3
        namespace: openshift-machine-api
      spec:
        metadata: {}
        providerSpec:
          value:
            apiVersion: baremetal.cluster.k8s.io/v1alpha1
            customDeploy:
              method: install_coreos
            hostSelector: {}
            image:
              checksum: ""
              url: ""
            kind: BareMetalMachineProviderSpec
            metadata:
              creationTimestamp: null
            userData:
              name: master-user-data-managed
      $ oc create -f <filename>
    4. Machine CR を適用します。

      $ oc apply -f <filename>
    5. link-machine-and-node.sh スクリプトを使用して、BareMetalHostMachine、および Node をリンクします。

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

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

    出力例

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

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

    $ oc get clusteroperator etcd

    出力例

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

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

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

    出力例

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

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

    $ oc get Nodes

    出力例

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

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

    $ oc get ClusterOperators

    出力例

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

  9. ClusterVersion を確認します。

    $ oc get ClusterVersion

    出力例

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

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

    1. BareMetalHost CR を削除します。

      $ oc delete bmh -n openshift-machine-api custom-master3
    2. Machine が正常でないことを確認します。

      $ oc get machine -A

      出力例

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

    3. Machine CR を削除します。

      $ oc delete machine -n openshift-machine-api   test-day2-1-6qv96-master-0
      machine.machine.openshift.io "test-day2-1-6qv96-master-0" deleted
    4. Node CR の削除を確認します。

      $ oc get nodes

      出力例

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

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

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

    出力例

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

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

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

    出力例

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

12.6. 正常でないクラスターへのプライマリーコントロールプレーンノードのインストール

この手順では、正常でない OpenShift Container Platform クラスターにプライマリーコントロールプレーンノードをインストールする方法について説明します。

前提条件

  • 正しい etcd-operator バージョンを備えた OpenShift Container Platform 4.11 以降を使用している。
  • 少なくとも 2 つのノードを含む正常なクラスターを インストール している。
  • Day 2 コントロールプレーンを作成している。
  • 単一ノードに role: master割り当て ている。

手順

  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. MachineNode、および BareMetalHost カスタムリソースを検証します。

    機能する Machine API を使用してクラスターを実行する場合、etcd-operatorMachine 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 スクリプトを実行して、BareMetalHostMachine、および 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

12.7. 関連情報

第13章 オプション: Nutanix へのインストール

OpenShift Container Platform を Nutanix にインストールする場合、支援付きインストーラーは OpenShift Container Platform クラスターを Nutanix プラットフォームと統合できます。これにより、Machine API が Nutanix に公開され、Nutanix Container Storage Interface (CSI) を使用したストレージコンテナーの自動スケーリングと動的プロビジョニングが可能になります。

13.1. UI を使用した Nutanix へのホストの追加

ユーザーインターフェイス (UI) を使用して Nutanix にホストを追加するには、支援付きインストーラーから検出イメージ ISO を生成します。最小限の検出イメージ ISO を使用します。これはデフォルト設定です。このイメージには、ネットワークを使用してホストを起動するために必要なものだけが含まれています。コンテンツの大部分は、起動時にダウンロードされます。ISO イメージのサイズは約 100MB です。

これが完了したら、Nutanix プラットフォームのイメージを作成し、Nutanix 仮想マシンを作成する必要があります。

前提条件

  • 支援付きインストーラーの UI でクラスタープロファイルを作成している。
  • Nutanix クラスター環境をセットアップし、クラスター名とサブネット名を書き留めた。

手順

  1. Host discovery で、Add hosts ボタンをクリックし、インストールメディアを選択します。
  2. Minimal image file: Provision with virtual media を選択して、起動に必要なデータを取得する小さなイメージをダウンロードします。
  3. core ユーザーとして Nutanix 仮想マシンに接続できるように、SSH 公開鍵を追加します。クラスターホストにログインすると、インストール中にデバッグ情報を入手できます。
  4. オプション: クラスターホストがプロキシーの使用を必要とするファイアウォールの内側にある場合は、Configure cluster-wide proxy settings を選択します。プロキシーサーバーの HTTP および HTTPS URL のユーザー名、パスワード、IP アドレス、およびポートを入力します。
  5. オプション: Ignition ファイルを使用して起動する場合は、検出イメージを設定します。詳しくは、検出イメージの設定 を参照してください。
  6. Generate Discovery ISO をクリックします。
  7. Discovery ISO URL をコピーします。
  8. Nutanix Prism UI で、指示に従って 支援付きインストーラーから検出イメージをアップロード します。
  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. 支援付きインストーラーのユーザーインターフェイスに戻り、支援付きインストーラーがホストを検出し、それぞれが Ready ステータスになるまで待ちます。
  12. Integrate with your virtualization platform スライダーを動かして、Nutanix との統合を有効にします。
  13. インストール手順を続行します。

13.2. API を使用した Nutanix へのホストの追加

API を使用して Nutanix にホストを追加するには、支援付きインストーラーから検出イメージ ISO を生成します。最小限の検出イメージ ISO を使用します。これはデフォルト設定です。このイメージには、ネットワークを使用してホストを起動するために必要なものだけが含まれています。コンテンツの大部分は、起動時にダウンロードされます。ISO イメージのサイズは約 100MB です。

これが完了したら、Nutanix プラットフォームのイメージを作成し、Nutanix 仮想マシンを作成する必要があります。

前提条件

  • 支援付きインストーラー API の認証を設定している。
  • 支援付きインストーラーのクラスタープロファイルを作成している。
  • 支援付きインストーラーのインフラストラクチャー環境を作成している。
  • インフラストラクチャー環境 ID がシェルに $INFRA_ENV_ID としてエクスポートされている。
  • 支援付きインストーラーのクラスター設定を完了している。
  • Nutanix クラスター環境をセットアップし、クラスター名とサブネット名を書き留めた。

手順

  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. 支援付きインストーラーが各仮想マシンを検出し、検証にパスするまで待ちます。

    $ 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. インストール手順を続行します。

13.3. Nutanix のインストール後の設定

プラットフォーム統合を有効にして OpenShift Container Platform を Nutanix プラットフォームにインストールした後、以下の Nutanix 設定を手動で更新する必要があります。

  • <prismcentral_address>: Nutanix Prism Central の IP アドレス。
  • <prismcentral_port>: Nutanix Prism Central のポート。
  • <prismelement_address>: Nutanix Prism Element の IP アドレス。
  • <prismelement_port>: Nutanix Prism Element のポート。
  • <prismelement_clustername>: Nutanix Prism Element のクラスター名。
  • <nutanix_username>: Nutanix Prism Element のログイン。
  • <nutanix_password>: Nutanix Prism Element のパスワード。

前提条件

  • 支援付きインストーラーによってクラスターが正常にインストールされている。
  • クラスターが console.redhat.com に接続されている。

手順

  1. Nutanix 設定を更新します。

    $ oc patch infrastructure/cluster --type=merge --patch-file=/dev/stdin <<-EOF
    {
      "spec": {
        "platformSpec": {
          "nutanix": {
            "prismCentral": {
              "address": "<prismcentral_address>", 1
              "port": <prismcentral_port> 2
            },
            "prismElements": [
              {
                "endpoint": {
                  "address": "<prismelement_address>", 3
                  "port": <prismelement_port> 4
                },
                "name": "<prismelement_clustername>" 5
              }
            ]
          },
          "type": "Nutanix"
        }
      }
    }
    EOF
    1
    <prismcentral_address> を Nutanix Prism Central の IP アドレスに置き換えます。
    2
    <prismcentral_port> を Nutanix Prism Central のポートに置き換えます。
    3
    <prismelement_address> を Nutanix Prism Element の IP アドレスに置き換えます。
    4
    <prismelement_port> を Nutanix Prism Element のポートに置き換えます。
    5
    <prismelement_clustername> を Nutanix Prism Element のクラスター名に置き換えます。

    詳細は、Nutanix でマシンセットを作成する を参照してください。

  2. シークレットを更新します。

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Secret
    metadata:
       name: nutanix-credentials
       namespace: openshift-machine-api
    type: Opaque
    stringData:
      credentials: |
        [{"type":"basic_auth","data":{"prismCentral":{"username":"<nutanix_username>","password":"<nutanix_password>"},"prismElements":null}}]
    EOF

    <nutanix_username> を Nutanix Prism Element のログインに置き換えます。<nutanix_password> を Nutanix Prism Element のパスワードに置き換えます。

    詳細は、デフォルトのストレージコンテナーの設定 を参照してください。

第14章 オプション: vSphere へのインストール

OpenShift Container Platform を vSphere にインストールする場合、支援付きインストーラーは OpenShift Container Platform クラスターを vSphere プラットフォームと統合できます。これにより、Machine API が vSphere に公開され、自動スケーリングが有効になります。

14.1. vSphere へのホストの追加

オンラインの vSphere クライアントまたは govc vSphere CLI ツールを使用して、支援付きインストーラークラスターにホストを追加できます。次の手順は、govc CLI ツールを使用してホストを追加する方法を示しています。オンラインの vSphere Client を使用するには、vSphere のドキュメントを参照してください。

vSphere govc CLI を使用して vSphere にホストを追加するには、支援付きインストーラーから検出イメージ ISO を生成します。最小限の検出イメージ ISO がデフォルト設定です。このイメージには、ネットワークを使用してホストを起動するために必要なものだけが含まれています。コンテンツの大部分は、起動時にダウンロードされます。ISO イメージのサイズは約 100MB です。

これが完了したら、vSphere プラットフォームのイメージを作成し、vSphere 仮想マシンを作成する必要があります。

前提条件

  • vSphere 7.0.2 以降を使用している。
  • vSphere govc CLI ツールがインストールされ、設定されている。
  • vSphere で、clusterSet disk.enableUUIDtrue に設定している。
  • 支援付きインストーラーの UI でクラスターを作成している。または
  • 以下を行った。

    • API を使用して、支援付きインストーラーのクラスタープロファイルとインフラストラクチャー環境を作成している。
    • シェルのインフラストラクチャー環境 ID が $INFRA_ENV_ID としてエクスポートされている。
    • 設定が完了している。

手順

  1. Ignition ファイルを使用して起動する場合は、検出イメージを設定します。
  2. 支援付きインストーラーの UI から ISO を生成してダウンロードします。

    1. Host discovery で、Add hosts ボタンをクリックし、インストールメディアを選択します。
    2. Minimal image file: Provision with virtual media を選択して、起動に必要なデータを取得する小さなイメージをダウンロードします。
    3. core ユーザーとして vSphere 仮想マシンに接続できるように、SSH 公開鍵を追加します。クラスターホストにログインすると、インストール中にデバッグ情報を入手できます。
    4. オプション: クラスターホストがプロキシーの使用を必要とするファイアウォールの内側にある場合は、Configure cluster-wide proxy settings を選択します。プロキシーサーバーの HTTP および HTTPS URL のユーザー名、パスワード、IP アドレス、およびポートを入力します。
    5. オプション: クラスターホストが再暗号化中間者 (MITM) プロキシーを使用するネットワーク内にある場合、またはクラスターがコンテナーイメージレジストリーなどの他の目的で証明書を信頼する必要がある場合は、Configure cluster-wide trusted certificates を選択し、追加の証明書を追加します。
    6. オプション: Ignition ファイルを使用して起動する場合は、検出イメージを設定します。詳しくは、検出イメージの設定 を参照してください。
    7. Generate Discovery ISO をクリックします。
    8. Discovery ISO URL をコピーします。
    9. 検出 ISO をダウンロードします。

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

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

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

    $ 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> を仮想マシンのインベントリーフォルダーの名前に置き換えます。

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

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

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

  5. 支援付きインストーラーの検出 ISO をアップロードします。

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

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

    注記

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

  6. 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 を参照してください。

    注記

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

  7. 少なくとも 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 を参照してください。

    注記

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

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

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

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

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

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

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

  10. 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.enableUUIDTRUE に設定する必要があります。

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

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

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

  12. 支援付きインストーラーのユーザーインターフェイスに戻り、支援付きインストーラーがホストを検出し、それぞれが Ready ステータスになるまで待ちます。
  13. Integrate with your virtualization platform スライダーを動かして、vSphere との統合を有効にします。
  14. 必要に応じてロールを選択します。
  15. Networking で、Allocate IPs via DHCP server のチェックを外します。
  16. API VIP アドレスを設定します。
  17. Ingress VIP アドレスを設定します。
  18. インストール手順を続行します。

14.2. CLI を使用した vSphere のインストール後の設定

プラットフォーム統合機能を有効にして、vSphere で支援付きインストーラーを使用して OpenShift Container Platform クラスターをインストールした後、以下の vSphere 設定を手動で更新する必要があります。

  • vCenter ユーザー名
  • vCenter パスワード
  • vCenter アドレス
  • vCenter クラスター
  • datacenter
  • datastore
  • folder

前提条件

  • 支援付きインストーラーによってクラスターが正常にインストールされている。
  • クラスターが console.redhat.com に接続されている。

手順

  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: "2023-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

14.3. UI を使用した vSphere のインストール後の設定

プラットフォーム統合機能を有効にして、vSphere で支援付きインストーラーを使用して OpenShift Container Platform クラスターをインストールした後、以下の vSphere 設定を手動で更新する必要があります。

  • vCenter アドレス
  • vCenter クラスター
  • vCenter ユーザー名
  • vCenter パスワード
  • データセンター
  • デフォルトのデータストア
  • 仮想マシンフォルダー

前提条件

  • 支援付きインストーラーによってクラスターが正常にインストールされている。
  • クラスターが console.redhat.com に接続されている。

手順

  1. Administrator パースペクティブで、Home → Overview に移動します。
  2. StatusvSphere 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 であることを確認します。

検証

接続設定プロセスは、Operator ステータスとコントロールプレーンノードを更新します。完了するまでに約 1 時間かかります。設定プロセスの中でノードが再起動します。これまでは、バインドされた PersistentVolumeClaims オブジェクトの接続が切断される可能性がありました。

設定プロセスを監視するには、以下の手順に従ってください。

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

    1. OpenShift Container Platform の Administrator パースペクティブで、Home → Overview に移動します。
    2. StatusOperators をクリックします。すべての Operator ステータスが Progressing から All succeeded に変わるまで待機します。Failed ステータスは、設定が失敗したことを示します。
    3. StatusControl 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 パースペクティブで、StoragePersistent VolumeClaims に移動します。

第15章 トラブルシューティング

支援付きインストーラーがインストールを開始できない場合や、クラスターが正しくインストールされない場合があります。これらのイベントでは、可能性のある障害モードと、障害のトラブルシューティング方法を理解しておくと役に立ちます。

15.1. 前提条件

  • API を使用してインフラストラクチャー環境を作成したか、UI を使用してクラスターを作成している。

15.2. 検出 ISO の問題のトラブルシューティング

支援付きインストーラーは、ISO イメージを使用して、ホストをクラスターに登録し、OpenShift のインストールを試行する前にハードウェアとネットワークの検証を実行するエージェントを実行します。以下の手順に従って、ホスト検出に関連する問題をトラブルシューティングできます。

検出 ISO イメージを使用してホストを起動すると、支援付きインストーラーがホストを検出し、Assisted Service UI に表示します。

詳しくは、検出イメージの設定 を参照してください。

15.3. 最小限の ISO イメージ

仮想メディア接続の帯域幅が制限されている場合は、最小限の ISO イメージを使用する必要があります。これには、ネットワークを使用してホストを起動するために必要なものだけが含まれています。コンテンツの大部分は、起動時にダウンロードされます。結果の ISO イメージのサイズは、フル ISO イメージの 1GB と比較して約 100MB です。

15.3.1. 最小限の ISO 起動エラーのトラブルシューティング

お使いの環境で支援付きインストーラーサービスにアクセスするために静的ネットワーク設定が必要な場合、その設定に問題があると、最小限の ISO が適切に起動しない可能性があります。ホストがルートファイルシステムイメージのダウンロードに失敗したことが起動画面に表示された場合は、追加のネットワーク設定が正しいことを確認します。フル ISO イメージに切り替えると、デバッグも容易になります。

rootfs ダウンロードの失敗例

screenshot of failing root file system image download

15.4. 検出エージェントが実行されていることを確認する

前提条件

  • API を使用してインフラストラクチャー環境を作成したか、UI を使用してクラスターを作成した。
  • インフラストラクチャー環境の検出 ISO を使用してホストを起動しましたが、ホストは登録に失敗した。
  • ホストに ssh アクセスできる。
  • パスワードなしでマシンに SSH 接続できるように、Discovery ISO を生成する前にホストの追加 ダイアログで SSH 公開キーを指定した。

手順

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

    $ ssh core@<host_ip_address>

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

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

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

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

    ログイン例

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

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

    $ sudo journalctl -u agent.service

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

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

    screenshot of agent service log

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

15.5. エージェントが支援サービスにアクセスできることを確認する

前提条件

  • API を使用してインフラストラクチャー環境を作成したか、UI を使用してクラスターを作成した。
  • インフラストラクチャー環境の検出 ISO を使用してホストを起動しましたが、ホストは登録に失敗した。
  • 検出エージェントが実行されていることを確認した。

手順

  • エージェントログをチェックして、エージェントがアシストサービスにアクセスできることを確認します。

    $ sudo journalctl TAG=agent

    次の例のエラーは、エージェントが Assisted Service へのアクセスに失敗したことを示しています。

    エージェントログの例

    screenshot of the agent log failing to access the Assisted Service

    クラスター用に設定したプロキシー設定を確認します。設定されている場合、プロキシーは Assisted Service URL へのアクセスを許可する必要があります。

15.6. ホストの起動順序の修正

Discovery Image の一部として実行されるインストールが完了すると、支援付きインストーラーがホストを再起動します。  クラスターの形成を続行するには、ホストをインストールディスクから起動する必要があります。  ホストの起動順序を正しく設定していない場合、代わりに別のディスクから起動し、インストールが中断されます。

ホストが検出イメージを再度起動すると、支援付きインストーラーはこのイベントをすぐに検出し、ホストのステータスを Installing Pending User Action に設定します。  または、ホストが割り当てられた時間内に正しいディスクを起動したことを 支援付きインストーラーが検出しない場合、このホストステータスも設定されます。

手順

  • ホストを再起動し、その起動順序をインストールディスクから起動するように設定します。インストールディスクを選択しなかった場合は、支援付きインストーラーがディスクを選択します。選択したインストールディスクを表示するには、ホストインベントリーでホストの情報をクリックしてデプロイメントし、どのディスクにインストールディスクのロールがあるかを確認します。

15.7. 部分的に成功したインストールの修正

エラーが発生したにもかかわらず、支援付きインストーラーがインストールの成功を宣言する場合があります。

  • OLM Operator のインストールを要求し、1 つ以上のインストールに失敗した場合は、クラスターのコンソールにログインして問題を修復します。
  • 3 つ以上のワーカーノードのインストールをリクエストし、少なくとも 1 つがインストールに失敗したが、少なくとも 2 つが成功した場合は、インストールされたクラスターに失敗したワーカーを追加します。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.