installer-provisioned クラスターのベアメタルへのデプロイ
installer-provisioned OpenShift Container Platform クラスターをベアメタルにデプロイする
概要
第1章 概要 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルノードへの installer-provisioned installation は、OpenShift Container Platform クラスターが実行されるインフラストラクチャーをデプロイおよび設定します。このガイドでは、installer-provisioned ベアメタルのインストールを正常に行うための方法論を提供します。次の図は、デプロイメントのフェーズ 1 におけるインストール環境を示しています。
インストールの場合、前の図の主要な要素は次のとおりです。
- プロビジョナー: インストールプログラムを実行し、新しい OpenShift Container Platform クラスターのコントロールプレーンをデプロイするブートストラップ VM をホストする物理マシン。
- Bootstrap VM: OpenShift Container Platform クラスターのデプロイプロセスで使用される仮想マシン。
-
ネットワークブリッジ: ブートストラップ VM は、ネットワークブリッジ
eno1
およびeno2
を介して、ベアメタルネットワークとプロビジョニングネットワーク (存在する場合) に接続します。 -
API VIP: API 仮想 IP アドレス (VIP) は、コントロールプレーンノード全体で API サーバーのフェイルオーバーを提供するために使用されます。API VIP はまずブートストラップ仮想マシンにあります。スクリプトは、サービスを起動する前に
keepalived.conf
設定ファイルを生成します。VIP は、ブートストラッププロセスが完了し、ブートストラップ仮想マシンが停止すると、コントロールプレーンノードの 1 つに移動します。
デプロイメントのフェーズ 2 では、プロビジョナーがブートストラップ VM を自動的に破棄し、仮想 IP アドレス (VIP) を適切なノードに移動します。
keepalived.conf
ファイルは、コントロールプレーンマシンにブートストラップ VM よりも低い仮想ルーター冗長プロトコル (VRRP) の優先順位を設定します。これにより、API VIP がブートストラップ VM からコントロールプレーンに移動する前に、コントロールプレーンマシン上の API が完全に機能することが保証されます。API VIP がコントロールプレーンノードの 1 つに移動すると、外部クライアントから API VIP ルートに送信されたトラフィックが、そのコントロールプレーンノードで実行している haproxy
ロードバランサーに移動します。haproxy
のこのインスタンスは、コントロールプレーンノード全体で API VIP トラフィックを分散します。
Ingress VIP はワーカーノードに移動します。keepalived
インスタンスは Ingress VIP も管理します。
次の図は、デプロイメントのフェーズ 2 を示しています:
これ以降、プロビジョナーが使用するノードを削除または再利用できます。ここから、追加のプロビジョニングタスクはすべてコントロールプレーンによって実行されます。
プロビジョニングネットワークは任意ですが、PXE ブートには必要です。プロビジョニングネットワークなしでデプロイする場合は、redfish-virtualmedia
または idrac-virtualmedia
などの仮想メディアベースボード管理コントローラー (BMC) アドレス指定オプションを使用する必要があります。
第2章 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のインストーラーでプロビジョニングされるインストールには、以下が必要です。
- 1 つの Red Hat Enterprise Linux (RHEL) 8.x がインストールされているプロビジョナーノード。プロビジョナーは、インストール後に削除できます。
- 3 つのコントロールプレーンノード
- ベースボード管理コントローラー (BMC) の各ノードへのアクセス。
1 つ以上のネットワーク:
- 1 つの必須のルーティング可能なネットワーク
- 1 つのオプションのプロビジョニングネットワーク
- 1 つのオプションの管理ネットワーク
OpenShift Container Platform の installer-provisioned installation を開始する前に、ハードウェア環境が以下の要件を満たしていることを確認してください。
2.1. ノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
installer-provisioned installation には、ハードウェアノードの各種の要件があります。
-
CPU architecture: すべてのノードは
x86_64
またはaarch64
CPU アーキテクチャーを使用する必要があります。 - 同様のノード: Red Hat では、ノードにロールごとに同じ設定を指定することを推奨しています。つまり Red Hat では、同じ CPU、メモリー、ストレージ設定の同じブランドおよびモデルのノードを使用することを推奨しています。
-
ベースボード管理コントローラー:
provisioner
ノードは、各 OpenShift Container Platform クラスターノードのベースボード管理コントローラー (BMC) にアクセスできる必要があります。IPMI、Redfish、またはプロプライエタリープロトコルを使用できます。 -
最新の生成: ノードは最新の生成されたノードである必要があります。インストーラーでプロビジョニングされるインストールは、ノード間で互換性を確保する必要のある BMC プロトコルに依存します。また、RHEL 8 は RAID コントローラーの最新のドライバーが同梱されています。ノードは
provisioner
ノード用に RHEL 8 を、コントローラープレーンおよびワーカーノード用に RHCOS 8 をサポートするのに必要な新しいバージョンのノードであることを確認します。 - レジストリーノード: (オプション) 非接続のミラーリングされていないレジストリーを設定する場合、レジストリーは独自のノードに置くことが推奨されます。
-
プロビジョナーノード: installer-provisioned installation には 1 つの
provisioner
ノードが必要です。 - コントロールプレーン: installer-provisioned installation には、高可用性を実現するために 3 つのコントロールプレーンノードが必要です。3 つのコントロールプレーンノードのみで OpenShift Container Platform クラスターをデプロイして、コントロールプレーンノードをワーカーノードとしてスケジュール可能にすることができます。小規模なクラスターでは、開発、実稼働およびテスト時の管理者および開発者に対するリソース効率が高くなります。
ワーカーノード: 必須ではありませんが、一般的な実稼働クラスターには複数のワーカーノードがあります。
重要ワーカーノードが 1 つしかないクラスターは、パフォーマンスが低下した状態のルーターおよび Ingress トラフィックでデプロイされるので、デプロイしないでください。
-
ネットワークインターフェイス: 各ノードでは、ルーティング可能な
baremetal
ネットワークに 1 つ以上のネットワークインターフェイスが必要です。デプロイメントにprovisioning
ネットワークを使用する場合、各ノードにprovisioning
ネットワーク用に 1 つのネットワークインターフェイスが必要になります。provisioning
ネットワークの使用はデフォルト設定です。 Unified Extensible Firmware Interface (UEFI): インストーラーでプロビジョニングされるインストールでは、
provisioning
ネットワークで IPv6 アドレスを使用する場合に、すべての OpenShift Container Platform ノードで UEFI ブートが必要になります。さらに、UEFI Device PXE Settings (UEFI デバイス PXE 設定) はprovisioning
ネットワーク NIC で IPv6 プロトコルを使用するように設定する必要がありますが、provisioning
ネットワークを省略すると、この要件はなくなります。重要ISO イメージなどの仮想メディアからインストールを開始する場合は、古い UEFI ブートテーブルエントリーをすべて削除します。ブートテーブルに、ファームウェアによって提供される一般的なエントリーではないエントリーが含まれている場合、インストールは失敗する可能性があります。
Secure Boot: 多くの実稼働シナリオでは、UEFI ファームウェアドライバー、EFI アプリケーション、オペレーティングシステムなど、信頼できるソフトウェアのみを使用してノードが起動することを確認するために、Secure Boot が有効にされているノードが必要です。手動またはマネージドの Secure Boot を使用してデプロイすることができます。
- 手動: 手動で Secure Boot を使用して OpenShift Container Platform クラスターをデプロイするには、UEFI ブートモードおよび Secure Boot を各コントロールプレーンノードおよび各ワーカーノードで有効にする必要があります。Red Hat は、installer-provisioned installation で Redfish 仮想メディアを使用している場合にのみ、手動で有効にした UEFI および Secure Boot で、Secure Boot をサポートします。詳細は、「ノードの設定」セクションの「手動での Secure Boot のノードの設定」を参照してください。
マネージド: マネージド Secure Boot で OpenShift Container Platform クラスターをデプロイするには、
install-config.yaml
ファイルでbootMode
の値をUEFISecureBoot
に設定する必要があります。Red Hat は、第 10 世代 HPE ハードウェアおよび 13 世代 Dell ハードウェア (ファームウェアバージョン2.75.75.75
以上を実行) でマネージド Secure Boot を使用した installer-provisioned installation のみをサポートします。マネージド Secure Boot を使用したデプロイには、Redfish 仮想メディアは必要ありません。詳細は、「OpenShift インストールの環境のセットアップ」セクションの「マネージド Secure Boot の設定」を参照してください。注記Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。
2.2. OpenShift 仮想化のためのベアメタルクラスターの計画 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift 仮想化を使用する場合は、ベアメタルクラスターをインストールする前に、いくつかの要件を認識することが重要です。
ライブマイグレーション機能を使用する場合は、クラスターのインストール時に 複数のワーカーノードが必要です。これは、ライブマイグレーションではクラスターレベルの高可用性 (HA) フラグを true に設定する必要があるためです。HA フラグは、クラスターのインストール時に設定され、後で変更することはできません。クラスターのインストール時に定義されたワーカーノードが 2 つ未満の場合、クラスターの存続期間中、HA フラグは false に設定されます。
注記単一ノードのクラスターに OpenShift Virtualization をインストールできますが、単一ノードの OpenShift は高可用性をサポートしていません。
- ライブマイグレーションには共有ストレージが必要です。OpenShift Virtualization のストレージは、ReadWriteMany (RWX) アクセスモードをサポートし、使用する必要があります。
- Single Root I/O Virtualization (SR-IOV) を使用する予定の場合は、ネットワークインターフェイスコントローラー (NIC) が OpenShift Container Platform でサポートされていることを確認してください。
2.3. 仮想メディアを使用したインストールのファームウェア要件 リンクのコピーリンクがクリップボードにコピーされました!
installer-provisioned OpenShift Container Platform クラスターのインストールプログラムは、Redfish 仮想メディアとのハードウェアおよびファームウェアの互換性を検証します。ノードファームウェアに互換性がない場合、インストールプログラムはノードへのインストールを開始しません。以下の表は、Redfish 仮想メディアを使用してデプロイされる installer-provisioned OpenShift Container Platform クラスターで機能するようにテストおよび検証された最小ファームウェアバージョンの一覧です。
Red Hat は、ファームウェア、ハードウェア、またはその他のサードパーティーコンポーネントの組み合わせをすべてテストしません。サードパーティーサポートの詳細は、Red Hat サードパーティーサポートポリシー を参照してください。ファームウェアの更新は、ノードのハードウェアドキュメントを参照するか、ハードウェアベンダーにお問い合わせください。
モデル | 管理 | ファームウェアのバージョン |
---|---|---|
第 10 世代 | iLO5 | 2.63 以降 |
モデル | 管理 | ファームウェアのバージョン |
---|---|---|
第 15 世代 | iDRAC 9 | v6.10.30.00 |
第 14 世代 | iDRAC 9 | v6.10.30.00 |
第 13 世代 | iDRAC 8 | v2.75.75.75 以降 |
2.4. ネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の installer-provisioned installation には、複数のネットワーク要件があります。まず、installer-provisioned installation では、各ベアメタルノードにオペレーティングシステムをプロビジョニングするためのルーティング不可能な provisioning
ネットワークをオプションで使用します。次に、installer-provisioned installation では、ルーティング可能な baremetal
ネットワークを使用します。
2.4.1. 必須ポートが開いていることを確認する リンクのコピーリンクがクリップボードにコピーされました!
クラスター間で特定のノードが開いてなければ、installer-provisioned によるインストールは正常に完了しません。ファーエッジワーカーノードに別のサブネットを使用する場合などの特定の状況では、これらのサブネット内のノードが、次の必須ポートで他のサブネット内のノードと通信できることを確認する必要があります。
ポート | 説明 |
---|---|
|
プロビジョニングネットワークを使用する場合、クラスターノードは、ポート |
|
プロビジョニングネットワークを使用する場合、クラスターノードはプロビジョニングネットワークインターフェイスを使用してポート |
|
イメージキャッシュオプションを使用しない場合、または仮想メディアを使用する場合、プロビジョナーノードからクラスターノードに Red Hat Enterprise Linux CoreOS (RHCOS) イメージをストリーミングするには、プロビジョナーノードのポート |
|
クラスターノードは、 |
|
Ironic Inspector API は、コントロールプレーンノード上で実行され、ポート |
|
ポート |
|
仮想メディアを使用して TLS を使用せずにデプロイする場合、ワーカーノードのベースボード管理コントローラー (BMC) が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート |
|
仮想メディアを使用して TLS でデプロイする場合、ワーカーノードの BMC が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート |
|
Ironic API サーバーは、最初はブートストラップ仮想マシン上で実行され、その後はコントロールプレーンノード上で実行され、ポート |
|
ポート |
|
TLS なしでイメージキャッシュを使用する場合、ポート |
|
TLS ありでイメージキャッシュオプションを使用する場合、ポート |
|
デフォルトでは、Ironic Python Agent (IPA) は、ポート |
2.4.2. ネットワーク MTU の増加 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をデプロイする前に、ネットワークの最大伝送単位 (MTU) を 1500 以上に増やします。MTU が 1500 未満の場合、ノードの起動に使用される Ironic イメージが Ironic インスペクター Pod との通信に失敗し、検査が失敗する可能性があります。これが発生すると、インストールにノードを使用できないため、インストールが停止します。
2.4.3. NIC の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、2 つのネットワークを使用してデプロイします。
provisioning
:provisioning
ネットワークは、OpenShift Container Platform クラスターの一部である基礎となるオペレーティングシステムを各ノードにプロビジョニングするために使用されるオプションのルーティング不可能なネットワークです。各クラスターノードのprovisioning
ネットワークのネットワークインターフェイスには、BIOS または UEFI が PXE ブートに設定されている必要があります。provisioningNetworkInterface
設定は、コントロールプレーンノード上のprovisioning
ネットワークの NIC 名を指定します。これは、コントロールプレーンノードと同じでなければなりません。bootMACAddress
設定は、provisioning
ネットワーク用に各ノードで特定の NIC を指定する手段を提供します。provisioning
ネットワークは任意ですが、PXE ブートには必要です。provisioning
ネットワークなしでデプロイする場合、redfish-virtualmedia
やidrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。-
baremetal
:baremetal
ネットワークはルーティング可能なネットワークです。NIC がprovisioning
ネットワークを使用するように設定されていない場合には、baremetal
ネットワークとのインターフェイスには任意の NIC を使用することができます。
VLAN を使用する場合、それぞれの NIC は、適切なネットワークに対応する別個の VLAN 上にある必要があります。
2.4.4. DNS 要件 リンクのコピーリンクがクリップボードにコピーされました!
クライアントは、baremetal
ネットワークで OpenShift Container Platform クラスターにアクセスします。ネットワーク管理者は、正規名の拡張がクラスター名であるサブドメインまたはサブゾーンを設定する必要があります。
<cluster_name>.<base_domain>
<cluster_name>.<base_domain>
以下に例を示します。
test-cluster.example.com
test-cluster.example.com
OpenShift Container Platform には、クラスターメンバーシップ情報を使用して A/AAAA レコードを生成する機能が含まれます。これにより、ノード名が IP アドレスに解決されます。ノードが API に登録されると、クラスターは CoreDNS-mDNS を使用せずにこれらのノード情報を分散できます。これにより、マルチキャスト DNS に関連付けられたネットワークトラフィックがなくなります。
CoreDNS を正しく機能させるには、アップストリームの DNS サーバーへの TCP 接続と UDP 接続の両方が必要です。アップストリームの DNS サーバーが OpenShift Container Platform クラスターノードから TCP 接続と UDP 接続の両方を受信できることを確認します。
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード Ingress API
A/AAAA レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。Red Hat Enterprise Linux CoreOS (RHCOS) は、逆引きレコードまたは DHCP を使用して、すべてのノードのホスト名を設定します。
installer-provisioned installation には、クラスターメンバーシップ情報を使用して A/AAAA レコードを生成する機能が含まれています。これにより、ノード名が IP アドレスに解決されます。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、install-config.yaml
ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| A/AAAA レコードと PTR レコード。API ロードバランサーを識別します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
ルート |
| ワイルドカード A/AAAA レコードは、アプリケーションの Ingress ロードバランサーを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するノードをターゲットにします。Ingress Controller Pod は、デフォルトでワーカーノードで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
dig
コマンドを使用して、DNS 解決を確認できます。
2.4.5. Dynamic Host Configuration Protocol (DHCP) の要件 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、installer-provisioned installation は、provisioning
ネットワーク用に DHCP を有効にして ironic-dnsmasq
をデプロイします。provisioningNetwork
設定が、デフォルト値の managed
に設定されている場合、provisioning
ネットワーク上で他の DHCP サーバーを実行することはできません。provisioning
ネットワーク上で DHCP サーバーを実行している場合は、install-config.yaml
ファイルで provisioningNetwork
設定を unmanaged
に設定する必要があります。
ネットワーク管理者は、外部 DHCP サーバー上の baremetal
ネットワーク用に、OpenShift Container Platform クラスター内の各ノードの IP アドレスを予約する必要があります。
2.4.6. DHCP サーバーを使用するノードの IP アドレスの確保 リンクのコピーリンクがクリップボードにコピーされました!
baremetal
ネットワークの場合、ネットワーク管理者は、以下を含むいくつかの IP アドレスを予約する必要があります。
2 つの一意の仮想 IP アドレス。
- API エンドポイントの 1 つの仮想 IP アドレス。
- ワイルドカード Ingress エンドポイントの 1 つの仮想 IP アドレス
- プロビジョナーノードの 1 つの IP アドレス
- コントロールプレーンノードごとに 1 つの IP アドレス。
- 各ワーカーノードの 1 つの IP アドレス (適用可能な場合)
一部の管理者は、各ノードの IP アドレスが DHCP サーバーがない状態で一定になるように静的 IP アドレスの使用を選択します。NMState を使用して静的 IP アドレスを設定する場合は、「OpenShift インストールの環境のセットアップ」セクションの「ホストネットワークインターフェイスの設定 (オプション)」を参照してください。
外部の負荷分散サービスとコントロールプレーンノードは同じ L2 ネットワークで実行する必要があります。また、VLAN を使用して負荷分散サービスとコントロールプレーンノード間のトラフィックをルーティングする際に同じ VLAN で実行する必要があります。
ストレージインターフェイスには、DHCP 予約または静的 IP が必要です。
以下の表は、完全修飾ドメイン名の具体例を示しています。API およびネームサーバーのアドレスは、正規名の拡張で始まります。コントロールプレーンおよびワーカーノードのホスト名は例であるため、任意のホストの命名規則を使用することができます。
使用法 | ホスト名 | IP |
---|---|---|
API |
|
|
Ingress LB (アプリケーション) |
|
|
プロビジョナーノード |
|
|
Control-plane-0 |
|
|
Control-plane-1 |
|
|
Control-plane-2 |
|
|
Worker-0 |
|
|
Worker-1 |
|
|
Worker-n |
|
|
DHCP 予約を作成しない場合、Kubernetes API ノード、プロビジョナーノード、コントロールプレーンノード、およびワーカーノードのホスト名を設定するために、インストールプログラムで逆引き DNS 解決が必要になります。
2.4.7. プロビジョナーノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
インストール設定でプロビジョナーノードの MAC アドレスを指定する必要があります。通常、bootMacAddress
仕様は PXE ネットワークブートに関連付けられています。ただし、Ironic プロビジョニングサービスでは、クラスターの検査中またはクラスター内のノードの再デプロイ中にノードを識別するために、bootMacAddress
仕様も必要です。
プロビジョナーノードには、ネットワークの起動、DHCP と DNS の解決、およびローカルネットワーク通信のためのレイヤー 2 接続が必要です。プロビジョナーノードには、仮想メディアの起動にレイヤー 3 接続が必要です。
2.4.8. ネットワークタイムプロトコル (NTP) リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の各 OpenShift Container Platform ノードは NTP サーバーにアクセスできる必要があります。OpenShift Container Platform ノードは NTP を使用してクロックを同期します。たとえば、クラスターノードは検証を必要とする SSL/TLS 証明書を使用しますが、ノード間の日付と時刻が同期していないと、検証が失敗する可能性があります。
各クラスターノードの BIOS 設定で一貫性のあるクロックの日付と時刻の形式を定義してください。そうしないと、インストールが失敗する可能性があります。
切断されたクラスター上で NTP サーバーとして機能するようにコントロールプレーンノードを再設定し、コントロールプレーンノードから時間を取得するようにワーカーノードを再設定することができます。
2.4.9. 帯域外管理 IP アドレスのポートアクセス リンクのコピーリンクがクリップボードにコピーされました!
帯域外管理 IP アドレスは、ノードとは別のネットワーク上にあります。インストール中に帯域外管理がプロビジョナーノードと確実に通信できるようにするには、帯域外管理 IP アドレスに、プロビジョナーノードおよび OpenShift Container Platform コントロールプレーンノード上のポート 6180
へのアクセスを許可する必要があります。TLS ポート 6183
は、たとえば Redfish などを使用する仮想メディアのインストールに必要です。
2.5. ノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
provisioning
ネットワークを使用する場合のノードの設定
クラスター内の各ノードには、適切なインストールを行うために以下の設定が必要です。
ノード間で一致していないと、インストールに失敗します。
クラスターノードには 3 つ以上の NIC を追加できますが、インストールプロセスでは最初の 2 つの NIC のみに焦点が当てられます。以下の表では、NIC1 は OpenShift Container Platform クラスターのインストールにのみ使用されるルーティング不可能なネットワーク (provisioning
) です。
NIC | ネットワーク | VLAN |
---|---|---|
NIC1 |
|
|
NIC2 |
|
|
プロビジョナーノードでの Red Hat Enterprise Linux (RHEL) 8.x インストールプロセスは異なる可能性があります。ローカルの Satellite サーバー、PXE サーバー、PXE 対応の NIC2 を使用して Red Hat Enterprise Linux (RHEL) 8.x をインストールするには、以下のようになります。
PXE | ブート順序 |
---|---|
NIC1 PXE 対応の | 1 |
NIC2 | 2 |
他のすべての NIC で PXE が無効になっていることを確認します。
コントロールプレーンおよびワーカーノードを以下のように設定します。
PXE | ブート順序 |
---|---|
NIC1 PXE 対応 (プロビジョニングネットワーク) | 1 |
provisioning
ネットワークを使用しないノードの設定
インストールプロセスには、1 つの NIC が必要です。
NIC | ネットワーク | VLAN |
---|---|---|
NICx |
|
|
NICx は、OpenShift Container Platform クラスターのインストールに使用されるルーティング可能なネットワーク (baremetal
) であり、インターネットにルーティング可能です。
provisioning
ネットワークは任意ですが、PXE ブートには必要です。provisioning
ネットワークなしでデプロイする場合、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。
手動での Secure Boot のノードの設定
Secure Boot は、ノードが UEFI ファームウェアドライバー、EFI アプリケーション、オペレーティングシステムなどの信頼できるソフトウェアのみを使用していることを確認できない場合は、ノードの起動を阻止します。
Red Hat は、Redfish 仮想メディアを使用してデプロイする場合にのみ、手動で設定された Secure Boot をサポートします。
Secure Boot を手動で有効にするには、ノードのハードウェアガイドを参照し、以下を実行してください。
手順
- ノードを起動し、BIOS メニューを入力します。
-
ノードのブートモードを
UEFI Enabled
に設定します。 - Secure Boot を有効にします。
Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。
2.6. アウトオブバンド管理 リンクのコピーリンクがクリップボードにコピーされました!
ノードには通常、ベースボード管理コントローラー (BMC) が使用する追加の NIC があります。この BMC はプロビジョナーノードからアクセスできる必要があります。
各ノードは、アウトオブバンド管理を介してアクセスできる必要があります。アウトオブバンド管理ネットワークを使用する場合、OpenShift Container Platform のインストールを正常に行うには、プロビジョナーノードがアウトオブバンド管理ネットワークにアクセスできる必要があります。
アウトオブバンド管理の設定は、このドキュメントの範囲外です。アウトオブバンド管理用に別の管理ネットワークを使用すると、パフォーマンスが向上し、セキュリティーが強化されます。ただし、provisioning ネットワークまたはベアメタルネットワークの使用は有効なオプションになります。
ブートストラップ仮想マシンには、最大 2 つのネットワークインターフェイスがあります。帯域外管理用に別の管理ネットワークを設定し、プロビジョニングネットワークを使用している場合、ブートストラップ仮想マシンでは、いずれかのネットワークインターフェイスを介して管理ネットワークへのルーティングアクセスが必要になります。このシナリオでは、ブートストラップ仮想マシンは 3 つのネットワークにアクセスできます。
- ベアメタルネットワーク
- プロビジョニングネットワーク
- 管理インターフェイスの 1 つを介してルーティングされる管理ネットワーク
2.7. インストールに必要なデータ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのインストール前に、すべてのクラスターノードから以下の情報を収集します。
アウトオブバンド管理 IP
例
- Dell (iDRAC) IP
- HP (iLO) IP
- Fujitsu (iRMC) IP
provisioning
ネットワークを使用する場合
-
NIC (
provisioning
) MAC アドレス -
NIC (
baremetal
) MAC アドレス
provisioning
ネットワークを省略する場合
-
NIC (
baremetal
) MAC アドレス
2.8. ノードの検証チェックリスト リンクのコピーリンクがクリップボードにコピーされました!
provisioning
ネットワークを使用する場合
-
❏ NIC1 VLAN が
provisioning
ネットワーに設定されている。 -
❏
provisioning
ネットワークの NIC1 は、プロビジョナー、コントロールプレーン、およびワーカーノードで PXE 対応として使用できる。 -
❏ NIC2 VLAN が
baremetal
ネットワークに設定されている。 - ❏ PXE が他のすべての NIC で無効にされている。
- ❏ DNS は API および Ingress エンドポイントで設定されている。
- ❏ コントロールプレーンおよびワーカーノードが設定されている。
- ❏ すべてのノードがアウトオブバンド管理でアクセス可能である。
- ❏ (オプション) 別個の管理ネットワークが作成されている。
- ❏ インストールに必要なデータ。
provisioning
ネットワークを省略する場合
-
❏ NIC1 VLAN が
baremetal
ネットワークに設定されている。 - ❏ DNS は API および Ingress エンドポイントで設定されている。
- ❏ コントロールプレーンおよびワーカーノードが設定されている。
- ❏ すべてのノードがアウトオブバンド管理でアクセス可能である。
- ❏ (オプション) 別個の管理ネットワークが作成されている。
- ❏ インストールに必要なデータ。
第3章 OpenShift インストールの環境のセットアップ リンクのコピーリンクがクリップボードにコピーされました!
3.1. RHEL のプロビジョナーノードへのインストール リンクのコピーリンクがクリップボードにコピーされました!
前提条件の設定が完了したら、次のステップは RHEL 8.x をプロビジョナーノードにインストールすることです。インストーラーは、OpenShift Container Platform クラスターをインストールする間にプロビジョナーノードをオーケレーターとして使用します。このドキュメントの目的上、RHEL のプロビジョナーノードへのインストールは対象外です。ただし、オプションには、RHEL Satellite サーバー、PXE、またはインストールメディアの使用も含まれますが、これらに限定されません。
3.2. OpenShift Container Platform インストールのプロビジョナーノードの準備 リンクのコピーリンクがクリップボードにコピーされました!
環境を準備するには、以下の手順を実行します。
手順
-
ssh
でプロビジョナーノードにログインします。 root 以外のユーザー (
kni
) を作成し、そのユーザーにsudo
権限を付与します。useradd kni
# useradd kni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow passwd kni
# passwd kni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo "kni ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/kni
# echo "kni ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/kni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 0440 /etc/sudoers.d/kni
# chmod 0440 /etc/sudoers.d/kni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規ユーザーの
ssh
キーを作成します。su - kni -c "ssh-keygen -t ed25519 -f /home/kni/.ssh/id_rsa -N ''"
# su - kni -c "ssh-keygen -t ed25519 -f /home/kni/.ssh/id_rsa -N ''"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョナーノードで新規ユーザーとしてログインします。
su - kni
# su - kni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Subscription Manager を使用してプロビジョナーノードを登録します。
sudo subscription-manager register --username=<user> --password=<pass> --auto-attach sudo subscription-manager repos --enable=rhel-8-for-<architecture>-appstream-rpms --enable=rhel-8-for-<architecture>-baseos-rpms
$ sudo subscription-manager register --username=<user> --password=<pass> --auto-attach $ sudo subscription-manager repos --enable=rhel-8-for-<architecture>-appstream-rpms --enable=rhel-8-for-<architecture>-baseos-rpms
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Red Hat Subscription Manager の詳細は、Using and Configuring Red Hat Subscription Manager を参照してください。
以下のパッケージをインストールします。
sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool
$ sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザーを変更して、新たに作成したユーザーに
libvirt
グループを追加します。sudo usermod --append --groups libvirt <user>
$ sudo usermod --append --groups libvirt <user>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow firewalld
を再起動して、http
サービスを有効にします。sudo systemctl start firewalld
$ sudo systemctl start firewalld
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo firewall-cmd --zone=public --add-service=http --permanent
$ sudo firewall-cmd --zone=public --add-service=http --permanent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo firewall-cmd --reload
$ sudo firewall-cmd --reload
Copy to Clipboard Copied! Toggle word wrap Toggle overflow libvirtd
サービスを開始して、これを有効にします。sudo systemctl enable libvirtd --now
$ sudo systemctl enable libvirtd --now
Copy to Clipboard Copied! Toggle word wrap Toggle overflow default
ストレージプールを作成して、これを起動します。sudo virsh pool-define-as --name default --type dir --target /var/lib/libvirt/images
$ sudo virsh pool-define-as --name default --type dir --target /var/lib/libvirt/images
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo virsh pool-start default
$ sudo virsh pool-start default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo virsh pool-autostart default
$ sudo virsh pool-autostart default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pull-secret.txt
ファイルを作成します。vim pull-secret.txt
$ vim pull-secret.txt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web ブラウザーで、Install OpenShift on Bare Metal with installer-provisioned infrastructure に移動します。Copy pull secret をクリックします。
pull-secret.txt
ファイルにコンテンツを貼り付け、そのコンテンツをkni
ユーザーのホームディレクトリーに保存します。
3.3. NTP サーバーの同期を確認する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform インストールプログラムは、chrony
Network Time Protocol (NTP) サービスをクラスターノードにインストールします。インストールを完了するには、各ノードが NTP タイムサーバーにアクセスできる必要があります。chrony
サービスを使用して、NTP サーバーの同期を確認できます。
切断されたクラスターの場合は、コントロールプレーンノード上で NTP サーバーを設定する必要があります。詳細は、関連情報 セクションを参照してください。
前提条件
-
ターゲットノードに
chrony
パッケージがインストールされました。
手順
-
ssh
コマンドを使用してノードにログインします。 次のコマンドを実行して、ノードで利用可能な NTP サーバーを表示します。
chronyc sources
$ chronyc sources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ping
コマンドを使用して、ノードが NTP サーバーにアクセスできることを確認します。次に例を示します。ping time.cloudflare.com
$ ping time.cloudflare.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
PING time.cloudflare.com (162.159.200.123) 56(84) bytes of data. 64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=1 ttl=54 time=32.3 ms 64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=2 ttl=54 time=30.9 ms 64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=3 ttl=54 time=36.7 ms ...
PING time.cloudflare.com (162.159.200.123) 56(84) bytes of data. 64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=1 ttl=54 time=32.3 ms 64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=2 ttl=54 time=30.9 ms 64 bytes from time.cloudflare.com (162.159.200.123): icmp_seq=3 ttl=54 time=36.7 ms ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
インストールの前に、プロビジョナーノードでネットワークを設定する必要があります。installer-provisioned クラスターは、ベアメタルブリッジとネットワーク、およびオプションのプロビジョニングブリッジとネットワークを使用してデプロイされます。
Web コンソールからネットワークを設定することもできます。
手順
次のコマンドを実行して、ベアメタルネットワーク NIC 名をエクスポートします。
export PUB_CONN=<baremetal_nic_name>
$ export PUB_CONN=<baremetal_nic_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ベアメタルネットワークを設定します。
注記これらの手順を実行した後、SSH 接続が切断される場合があります。
DHCP を使用するネットワークの場合は、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<con_name>
を接続名に置き換えます。
静的 IP アドレスを使用し、DHCP ネットワークを使用しないネットワークの場合は、次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<con_name>
を接続名に置き換えます。x.x.x.x/yy
をネットワークの IP アドレスと CIDR に置き換えます。a.a.a.a
をネットワークゲートウェイに置き換えます。b.b.b.b
を DNS サーバーの IP アドレスに置き換えます。
オプション: プロビジョニングネットワークを使用してデプロイする場合は、次のコマンドを実行してプロビジョニングネットワークの NIC 名をエクスポートします。
export PROV_CONN=<prov_nic_name>
$ export PROV_CONN=<prov_nic_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: プロビジョニングネットワークを使用してデプロイする場合は、次のコマンドを実行してプロビジョニングネットワークを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記これらの手順を実行した後、SSH 接続が切断される場合があります。
IPv6 アドレスは、ベアメタルネットワーク経由でルーティングできない任意のアドレスにすることができます。
IPv6 アドレスを使用する場合に UEFI PXE 設定が有効にされており、UEFI PXE 設定が IPv6 プロトコルに設定されていることを確認します。
オプション: プロビジョニングネットワークを使用してデプロイする場合は、次のコマンドを実行して、プロビジョニングネットワーク接続で IPv4 アドレスを設定します。
nmcli connection modify provisioning ipv4.addresses 172.22.0.254/24 ipv4.method manual
$ nmcli connection modify provisioning ipv4.addresses 172.22.0.254/24 ipv4.method manual
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
provisioner
ノードに SSH で戻ります (必要な場合)。ssh kni@provisioner.<cluster-name>.<domain>
# ssh kni@provisioner.<cluster-name>.<domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、接続ブリッジが適切に作成されたことを確認します。
sudo nmcli con show
$ sudo nmcli con show
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. サブネット間の通信を確立する リンクのコピーリンクがクリップボードにコピーされました!
一般的な OpenShift Container Platform クラスター設定では、コントロールプレーンとワーカーノードを含むすべてのノードが同じネットワーク内に存在します。ただし、エッジコンピューティングのシナリオでは、ワーカーノードをエッジの近くに配置することが有益な場合があります。その場合、コントロールプレーンやローカルワーカーノードが使用するサブネットとは異なるネットワークセグメントまたはサブネットをリモートワーカーノードに使用されることもよくあります。このようなセットアップにより、エッジのレイテンシーが減少し、拡張性が向上します。
OpenShift Container Platform をインストールする前に、リモートノードを含むエッジサブネットがコントロールプレーンノードを含むサブネットに到達し、コントロールプレーンからのトラフィックも受信できるように、ネットワークを適切に設定する必要があります。
クラスターのインストール中に、install-config.yaml
設定ファイルのネットワーク設定でノードに永続的な IP アドレスを割り当てます。これを行わないと、ノードに一時的な IP アドレスが割り当てられ、トラフィックがノードに到達する方法に影響する可能性があります。たとえば、ノードに一時的な IP アドレスが割り当てられていて、ノードに対して結合されたインターフェイスを設定した場合、結合されたインターフェイスは別の IP アドレスを受け取る可能性があります。
この手順では、2 番目のサブネットにあるリモートワーカーノードが 1 番目のサブネットにあるコントロールプレーンノードと効果的に通信できるようにし、1 番目のサブネットにあるコントロールプレーンノードが 2 番目のサブネットにあるリモートワーカーノードと効果的に通信できるようにするために必要なネットワーク設定について詳しく説明します。
この手順では、クラスターは 2 つのサブネットにまたがります。
-
1 番目のサブネット (
10.0.0.0
) には、コントロールプレーンとローカルワーカーノードが含まれています。 -
2 番目のサブネット (
192.168.0.0
) にはエッジワーカーノードが含まれています。
すべてのコントロールプレーンノードは同じサブネット内で実行する必要があります。複数のサブネットを使用する場合、マニフェストを使用して、コントロールプレーンノード上で実行されるように Ingress VIP を設定することもできます。詳細は、「コントロールプレーンで実行するネットワークコンポーネントの設定」を参照してください。
複数のサブネットを持つクラスターをデプロイメントするには、仮想メディアを使用する必要があります。
手順
1 番目のサブネットが 2 番目のサブネットと通信するように設定します。
次のコマンドを実行して、コントロールプレーンノードに
root
としてログインします。sudo su -
$ sudo su -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスの名前を取得します。
nmcli dev status
# nmcli dev status
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ゲートウェイ経由で 2 番目のサブネット (
192.168.0.0
) にルートを追加します: s+
nmcli connection modify <interface_name> +ipv4.routes "192.168.0.0/24 via <gateway>"
# nmcli connection modify <interface_name> +ipv4.routes "192.168.0.0/24 via <gateway>"
+ <interface_name>
をインターフェイス名に置き換えます。<gateway>
を実際のゲートウェイの IP アドレスに置き換えます。
+ .例
+
nmcli connection modify eth0 +ipv4.routes "192.168.0.0/24 via 192.168.0.1"
# nmcli connection modify eth0 +ipv4.routes "192.168.0.0/24 via 192.168.0.1"
変更を適用します。
nmcli connection up <interface_name>
# nmcli connection up <interface_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <interface_name>
をインターフェイス名に置き換えます。ルーティングテーブルを検証して、ルートが正常に追加されたことを確認します。
ip route
# ip route
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 1 番目のサブネットの各コントロールプレーンノードに対して前の手順を繰り返します。
注記コマンドは、実際のインターフェイス名とゲートウェイに合わせて調整してください。
- 1 番目のサブネットと通信するように 2 番目のサブネットを設定します。
root
としてリモートワーカーノードにログインします。sudo su -
$ sudo su -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスの名前を取得します。
nmcli dev status
# nmcli dev status
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ゲートウェイ経由で 1 番目のサブネット (
10.0.0.0
) にルートを追加します。nmcli connection modify <interface_name> +ipv4.routes "10.0.0.0/24 via <gateway>"
# nmcli connection modify <interface_name> +ipv4.routes "10.0.0.0/24 via <gateway>"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <interface_name>
をインターフェイス名に置き換えます。<gateway>
を実際のゲートウェイの IP アドレスに置き換えます。例
nmcli connection modify eth0 +ipv4.routes "10.0.0.0/24 via 10.0.0.1"
# nmcli connection modify eth0 +ipv4.routes "10.0.0.0/24 via 10.0.0.1"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を適用します。
nmcli connection up <interface_name>
# nmcli connection up <interface_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <interface_name>
をインターフェイス名に置き換えます。ルーティングテーブルを検証して、ルートが正常に追加されたことを確認します。
ip route
# ip route
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 2 番目のサブネット内の各ワーカーノードに対して前の手順を繰り返します。
注記実際のインターフェイス名とゲートウェイに一致するようにコマンドを調整します。
- ネットワークを設定したら、接続をテストして、リモートワーカーノードがコントロールプレーンノードに到達できること、およびコントロールプレーンノードがリモートワーカーノードに到達できることを確認します。
1 番目のサブネットのコントロールプレーンノードから、2 番目のサブネットのリモートワーカーノードに ping を送信します。
ping <remote_worker_node_ip_address>
$ ping <remote_worker_node_ip_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ping が成功した場合は、1 番目のサブネットのコントロールプレーンノードが 2 番目のサブネットのリモートワーカーノードに到達できることを意味します。応答を受信しない場合は、ネットワーク設定を確認し、ノードに対して手順を繰り返します。
2 番目のサブネットのリモートワーカーノードから、1 番目のサブネットのコントロールプレーンノードに ping を送信します。
ping <control_plane_node_ip_address>
$ ping <control_plane_node_ip_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ping が成功した場合は、2 番目のサブネットのリモートワーカーノードが 1 番目のサブネットのコントロールプレーンに到達できることを意味します。応答を受信しない場合は、ネットワーク設定を確認し、ノードに対して手順を繰り返します。
3.6. OpenShift Container Platform インストーラーの取得 リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムの stable-4.x
バージョンと選択したアーキテクチャーを使用して、OpenShift Container Platform の一般公開の安定バージョンをデプロイします。
export VERSION=stable-4.12
$ export VERSION=stable-4.12
export RELEASE_ARCH=<architecture>
$ export RELEASE_ARCH=<architecture>
export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/$RELEASE_ARCH/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}')
$ export RELEASE_IMAGE=$(curl -s https://mirror.openshift.com/pub/openshift-v4/$RELEASE_ARCH/clients/ocp/$VERSION/release.txt | grep 'Pull From: quay.io' | awk -F ' ' '{print $3}')
3.7. OpenShift Container Platform インストールのデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
インストーラーを取得したら、インストーラーを展開します。
手順
環境変数を設定します。
export cmd=openshift-baremetal-install
$ export cmd=openshift-baremetal-install
Copy to Clipboard Copied! Toggle word wrap Toggle overflow export pullsecret_file=~/pull-secret.txt
$ export pullsecret_file=~/pull-secret.txt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow export extract_dir=$(pwd)
$ export extract_dir=$(pwd)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを取得します。curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc
$ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux.tar.gz | tar zxvf - oc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストーラーを実行します。
sudo cp oc /usr/local/bin
$ sudo cp oc /usr/local/bin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm release extract --registry-config "${pullsecret_file}" --command=$cmd --to "${extract_dir}" ${RELEASE_IMAGE}
$ oc adm release extract --registry-config "${pullsecret_file}" --command=$cmd --to "${extract_dir}" ${RELEASE_IMAGE}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo cp openshift-baremetal-install /usr/local/bin
$ sudo cp openshift-baremetal-install /usr/local/bin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.8. オプション: RHCOS イメージキャッシュの作成 リンクのコピーリンクがクリップボードにコピーされました!
イメージキャッシングを使用するには、ブートストラップ VM がクラスターノードをプロビジョニングするために使用する Red Hat Enterprise Linux CoreOS(RHCOS) イメージをダウンロードする必要があります。イメージのキャッシュはオプションですが、帯域幅が制限されているネットワークでインストールプログラムを実行する場合に特に便利です。
正しいイメージがリリースペイロードにあるため、インストールプログラムは、clusterOSImage
RHCOS イメージを必要としなくなりました。
帯域幅が制限されたネットワークでインストールプログラムを実行していて、RHCOS イメージのダウンロードに 15〜20 分以上かかる場合、インストールプログラムはタイムアウトになります。このような場合、Web サーバーでイメージをキャッシュすることができます。
HTTPD サーバーに対して TLS を有効にする場合、ルート証明書がクライアントによって信頼された機関によって署名されていることを確認し、OpenShift Container Platform ハブおよびスポーククラスターと HTTPD サーバー間の信頼された証明書チェーンを検証する必要があります。信頼されていない証明書で設定されたサーバーを使用すると、イメージがイメージ作成サービスにダウンロードされなくなります。信頼されていない HTTPS サーバーの使用はサポートされていません。
イメージを含むコンテナーをインストールします。
手順
podman
をインストールします。sudo dnf install -y podman
$ sudo dnf install -y podman
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージのキャッシュに使用されるファイアウォールのポート
8080
を開きます。sudo firewall-cmd --add-port=8080/tcp --zone=public --permanent
$ sudo firewall-cmd --add-port=8080/tcp --zone=public --permanent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo firewall-cmd --reload
$ sudo firewall-cmd --reload
Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootstraposimage
を保存するディレクトリーを作成します。mkdir /home/kni/rhcos_image_cache
$ mkdir /home/kni/rhcos_image_cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規に作成されたディレクトリーに適切な SELinux コンテキストを設定します。
sudo semanage fcontext -a -t httpd_sys_content_t "/home/kni/rhcos_image_cache(/.*)?"
$ sudo semanage fcontext -a -t httpd_sys_content_t "/home/kni/rhcos_image_cache(/.*)?"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo restorecon -Rv /home/kni/rhcos_image_cache/
$ sudo restorecon -Rv /home/kni/rhcos_image_cache/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストールプログラムがブートストラップ VM にデプロイする RHCOS イメージの URI を取得します。
export RHCOS_QEMU_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk.location')
$ export RHCOS_QEMU_URI=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk.location')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストールプログラムがブートストラップ VM にデプロイするイメージの名前を取得します。
export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
$ export RHCOS_QEMU_NAME=${RHCOS_QEMU_URI##*/}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ仮想マシンにデプロイされる RHCOS イメージの SHA ハッシュを取得します。
export RHCOS_QEMU_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk["uncompressed-sha256"]')
$ export RHCOS_QEMU_UNCOMPRESSED_SHA256=$(/usr/local/bin/openshift-baremetal-install coreos print-stream-json | jq -r --arg ARCH "$(arch)" '.architectures[$ARCH].artifacts.qemu.formats["qcow2.gz"].disk["uncompressed-sha256"]')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージをダウンロードして、
/home/kni/rhcos_image_cache
ディレクトリーに配置します。curl -L ${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_NAME}
$ curl -L ${RHCOS_QEMU_URI} -o /home/kni/rhcos_image_cache/${RHCOS_QEMU_NAME}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいファイルの SELinux タイプが
httpd_sys_content_t
であることを確認します。ls -Z /home/kni/rhcos_image_cache
$ ls -Z /home/kni/rhcos_image_cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod を作成します。
podman run -d --name rhcos_image_cache \ -v /home/kni/rhcos_image_cache:/var/www/html \ -p 8080:8080/tcp \ registry.access.redhat.com/ubi9/httpd-24
$ podman run -d --name rhcos_image_cache \
1 -v /home/kni/rhcos_image_cache:/var/www/html \ -p 8080:8080/tcp \ registry.access.redhat.com/ubi9/httpd-24
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
rhcos_image_cache
という名前のキャッシング Web サーバーを作成します。この Pod は、デプロイメント用にinstall-config.yaml
ファイルのbootstrapOSImage
イメージを提供します。
bootstrapOSImage
設定を生成します。export BAREMETAL_IP=$(ip addr show dev baremetal | awk '/inet /{print $2}' | cut -d"/" -f1)
$ export BAREMETAL_IP=$(ip addr show dev baremetal | awk '/inet /{print $2}' | cut -d"/" -f1)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow export BOOTSTRAP_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_QEMU_NAME}?sha256=${RHCOS_QEMU_UNCOMPRESSED_SHA256}"
$ export BOOTSTRAP_OS_IMAGE="http://${BAREMETAL_IP}:8080/${RHCOS_QEMU_NAME}?sha256=${RHCOS_QEMU_UNCOMPRESSED_SHA256}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo " bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}"
$ echo " bootstrapOSImage=${BOOTSTRAP_OS_IMAGE}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow platform.baremetal
下のinstall-config.yaml
ファイルに必要な設定を追加します。platform: baremetal: bootstrapOSImage: <bootstrap_os_image>
platform: baremetal: bootstrapOSImage: <bootstrap_os_image>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<bootstrap_os_image>
を$BOOTSTRAP_OS_IMAGE
の値に置き換えます。
詳細は、Configuring the install-config.yaml file セクションを参照してください。
3.9. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、NetworkManager
がホスト名を設定します。デフォルトでは、DHCP が NetworkManager
にホスト名を提供します。これが推奨される方法です。NetworkManager
は、次の場合に逆 DNS ルックアップを通じてホスト名を取得します。
- DHCP がホスト名を提供しない場合
- カーネル引数を使用してホスト名を設定する場合
- 別の方法でホスト名を設定する場合
逆 DNS ルックアップは、ノード上でネットワークが初期化された後に実行し、NetworkManager
がホスト名を設定するのにかかる時間が長くなる可能性があります。NetworkManager
がホスト名を設定する前に他のシステムサービスが起動することがあり、その場合は、それらのサービスが localhost
などのデフォルトのホスト名を使用する可能性があります。
DHCP を使用して各クラスターノードにホスト名を提供することで、ホスト名の設定の遅延を回避できます。また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
3.10. install-config.yaml ファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
3.10.1. install-config.yaml ファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルには、追加の詳細情報が必要です。ほとんどの情報は、インストールプログラムと結果として作成されるクラスターに、完全に管理できる使用可能なハードウェアを十分に説明しています。
正しいイメージがリリースペイロードにあるため、インストールプログラムは、clusterOSImage
RHCOS イメージを必要としなくなりました。
install-config.yaml
を設定します。pullSecret
、sshKey
など、環境に合わせて適切な変数を変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OpenShift Container Platform クラスターの一部であるワーカーノードの数に基づいてワーカーマシンをスケーリングします。
replicas
値の有効なオプションは0
で、2
以上の整数です。3 ノードクラスターのみが含まれる 3 ノードクラスターをデプロイするには、レプリカ数を0
に設定します。3 ノードクラスターは、テスト、開発、本番に使用できる、より小さく、よりリソース効率の良いクラスターです。ワーカーを 1 つだけにしてクラスターをインストールすることはできません。 - 2
- 静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、
bootstrapExternalStaticIP
設定を設定して、ブートストラップ VM の静的 IP アドレスを指定する必要があります。 - 3
- 静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、
bootstrapExternalStaticGateway
設定を設定して、ブートストラップ VM のゲートウェイ IP アドレスを指定する必要があります。 - 4
- その他のオプションについては、BMC アドレス指定のセクションを参照してください。
- 5
- インストールディスクドライブへのパスを設定するには、ディスクのカーネル名を入力します。たとえば、
/dev/sda
です。重要ディスクの検出順序は保証されていないため、複数のディスクを備えたマシンの起動オプションによってディスクのカーネル名が変わる可能性があります。たとえば、
/dev/sda
は/dev/sdb
になり、その逆も同様です。この問題を回避するには、ディスクの World Wide Name (WWN) などの永続ディスク属性を使用する必要があります。ディスク WWN を使用するには、deviceName
パラメーターをwwnWithExtension
パラメーターに置き換えます。使用するパラメーターに応じて、/dev/sda
などのディスク名、または"0x64cd98f04fde100024684cf3034da5c2"
などのディスク WWN を入力します。ディスク WWN 値が 16 進数値ではなく文字列値として使用されるように、ディスク WWN 値を引用符で囲んで入力してください。これらの
rootDeviceHints
パラメーター要件を満たさない場合、次のエラーが発生する可能性があります。ironic-inspector inspection failed: No disks satisfied root device hints
ironic-inspector inspection failed: No disks satisfied root device hints
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
注記OpenShift Container Platform 4.12 より前では、クラスターインストールプログラムが、
apiVIP
およびingressVIP
設定の IPv4 アドレスまたは IPv6 アドレスのみを受け入れていました。OpenShift Container Platform 4.12 以降では、これらの設定は非推奨です。代わりに、apiVIPs
およびingressVIPs
設定でリスト形式を使用して、IPv4 アドレス、IPv6 アドレス、または両方の IP アドレス形式を指定してください。クラスター設定を保存するディレクトリーを作成します。
mkdir ~/clusterconfigs
$ mkdir ~/clusterconfigs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow install-config.yaml
ファイルを新しいディレクトリーにコピーします。cp install-config.yaml ~/clusterconfigs
$ cp install-config.yaml ~/clusterconfigs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform クラスターをインストールする前に、すべてのベアメタルノードの電源がオフになっていることを確認します。
ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
$ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以前に試行したデプロイメントにより古いブートストラップリソースが残っている場合は、これを削除します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.10.2. 追加の install-config パラメーター リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルに必要なパラメーター hosts
パラメーターおよび bmc
パラメーターは、以下の表を参照してください。
パラメーター | デフォルト | 説明 |
---|---|---|
|
クラスターのドメイン名。たとえば、 | |
|
|
ノードのブートモード。オプションは、 |
| ブートストラップ VM の静的 IP アドレス。ベアメタルネットワークに DHCP サーバーがない場合に、静的 IP アドレスを使用してクラスターをデプロイする場合は、この値を設定する必要があります。 | |
| ブートストラップ VM のゲートウェイの静的 IP アドレス。ベアメタルネットワークに DHCP サーバーがない場合に、静的 IP アドレスを使用してクラスターをデプロイする場合は、この値を設定する必要があります。 | |
|
| |
|
| |
metadata: name:
|
OpenShift Container Platform クラスターに指定される名前。たとえば、 | |
networking: machineNetwork: - cidr:
|
外部ネットワークの公開 CIDR (Classless Inter-Domain Routing)。例: | |
compute: - name: worker
| OpenShift Container Platform クラスターでは、ノードがゼロであってもワーカー (またはコンピュート) ノードの名前を指定する必要があります。 | |
compute: replicas: 2
| レプリカは、OpenShift Container Platform クラスターのワーカー (またはコンピュート) ノードの数を設定します。 | |
controlPlane: name: master
| OpenShift Container Platform クラスターには、コントロールプレーン (マスター) ノードの名前が必要です。 | |
controlPlane: replicas: 3
| レプリカは、OpenShift Container Platform クラスターの一部として含まれるコントロールプレーン (マスター) ノードの数を設定します。 | |
|
ベアメタルネットワークに接続されたノード上のネットワークインターフェイス名。OpenShift Container Platform 4.9 以降のリリースのために、NIC の名前を識別するために | |
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
| (オプション) Kubernetes API 通信の仮想 IP アドレス。
この設定は、MachineNetwork からの予約済み IP として 注記
OpenShift Container Platform 4.12 より前では、クラスターのインストールプログラムは | |
|
|
|
| (オプション) Ingress トラフィックの仮想 IP アドレス。
この設定は、MachineNetwork からの予約済み IP として 注記
OpenShift Container Platform 4.12 より前では、クラスターのインストールプログラムは |
パラメーター | デフォルト | 説明 |
---|---|---|
|
| プロビジョニングネットワークでノードの IP 範囲を定義します。 |
|
| プロビジョニングに使用するネットワークの CIDR。このオプションは、プロビジョニングネットワークでデフォルトのアドレス範囲を使用しない場合に必要です。 |
|
|
プロビジョニングサービスが実行されるクラスター内の IP アドレス。デフォルトは、プロビジョニングサブネットの 3 番目の IP アドレスに設定されます。たとえば、 |
|
|
インストーラーがコントロールプレーン (マスター) ノードをデプロイしている間にプロビジョニングサービスが実行されるブートストラップ仮想マシンの IP アドレス。デフォルトは、プロビジョニングサブネットの 2 番目の IP アドレスに設定されます。たとえば、 |
|
| ベアメタルネットワークに接続されたハイパーバイザーのベアメタルブリッジの名前。 |
|
|
プロビジョニングネットワークに接続されている |
|
クラスターのホストアーキテクチャーを定義します。有効な値は | |
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
|
ブートストラップノードのデフォルトのオペレーティングシステムイメージを上書きするための URL。URL にはイメージの SHA-256 ハッシュが含まれている必要があります。たとえば、 | |
|
| |
| このパラメーターを、環境内で使用する適切な HTTP プロキシーに設定します。 | |
| このパラメーターを、環境内で使用する適切な HTTPS プロキシーに設定します。 | |
| このパラメーターを、環境内のプロキシーの使用に対する例外のリストに設定します。 |
ホスト
hosts
パラメーターは、クラスターのビルドに使用される個別のベアメタルアセットのリストです。
名前 | デフォルト | 説明 |
---|---|---|
|
詳細情報に関連付ける | |
|
ベアメタルノードのロール。 | |
| ベースボード管理コントローラーの接続詳細。詳細は、BMC アドレス指定のセクションを参照してください。 | |
|
ホストがプロビジョニングネットワークに使用する NIC の MAC アドレス。Ironic は、 注記 プロビジョニングネットワークを無効にした場合は、ホストから有効な MAC アドレスを提供する必要があります。 | |
| このオプションのパラメーターを設定して、ホストのネットワークインターフェイスを設定します。詳細は、「(オプション) ホストネットワークインターフェイスの設定」を参照してください。 |
3.10.3. BMC アドレス指定 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどのベンダーは、Intelligent Platform Management Interface(IPMI) でベースボード管理コントローラー (BMC) アドレスに対応しています。IPMI は通信を暗号化しません。これは、セキュリティーが保護された管理ネットワークまたは専用の管理ネットワークを介したデータセンター内での使用に適しています。ベンダーを確認して、Redfish ネットワークブートをサポートしているかどうかを確認します。Redfish は、コンバージド、ハイブリッド IT および Software Defined Data Center (SDDC) 向けのシンプルでセキュアな管理を行います。Redfish は人による判読が可能、かつ機械対応が可能であり、インターネットや Web サービスの標準を活用して、最新のツールチェーンに情報を直接公開します。ハードウェアが Redfish ネットワークブートに対応していない場合には、IPMI を使用します。
IPMI
IPMI を使用するホストは ipmi://<out-of-band-ip>:<port>
アドレス形式を使用します。これは、指定がない場合はポート 623
にデフォルトで設定されます。以下の例は、install-config.yaml
ファイル内の IPMI 設定を示しています。
BMC アドレス指定に IPMI を使用して PXE ブートする場合は、provisioning
ネットワークが必要です。provisioning
ネットワークなしでは、PXE ブートホストを行うことはできません。provisioning
ネットワークなしでデプロイする場合、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。詳細は、「HPE iLO の BMC アドレス指定」セクションの「HPE iLO の Redfish 仮想メディア」、または「Dell iDRAC の BMC アドレス指定」セクションの「Dell iDRAC の Redfish 仮想メディア」を参照してください。
Redfish ネットワークブート
Redfish を有効にするには、redfish://
または redfish+http://
を使用して TLS を無効にします。インストーラーには、ホスト名または IP アドレスとシステム ID へのパスの両方が必要です。以下の例は、install-config.yaml
ファイル内の Redfish 設定を示しています。
アウトバウンド管理のアドレスに認証局の証明書を使用することが推奨されますが、自己署名証明書を使用する場合には、bmc
設定に disableCertificateVerification: True
を含める必要があります。以下の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用する RedFish 設定を示しています。
Redfish API
ベアメタルインストーラーでプロビジョニングされたインフラストラクチャーを使用する場合、いくつかの redfish API エンドポイントが BCM で呼び出されます。
インストールの前に、BMC がすべての redfish API をサポートしていることを確認する必要があります。
- redfish API のリスト
電源を入れる
curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "On"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "On"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 電源を切る
curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "ForceOff"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "ForceOff"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pxe
を使用した一時的な起動curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Legacy
またはUEFI
を使用して BIOS ブートモードを設定するcurl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- redfish-virtualmedia API のリスト
CD
またはdvd
を使用して一時的な起動デバイスを設定するcurl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想メディアのマウント
curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: *" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: *" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
redfish API の PowerOn
および PowerOff
コマンドは、redfish-virtualmedia API と同じです。
TransferProtocolTypes
でサポートされているパラメータータイプは、HTTPS
と HTTP
のみです。
3.10.4. Dell iDRAC の BMC アドレス指定 リンクのコピーリンクがクリップボードにコピーされました!
各 bmc
エントリーの アドレス
設定は、OpenShift Container Platform クラスターノードに接続するための URL です。これには、URL スキームのコントローラーのタイプやネットワーク上のその場所が含まれます。各 bmc
エントリーの username
設定は、管理者
権限を持つユーザーを指定する必要があります。
Dell ハードウェアの場合、Red Hat は統合 Dell Remote Access Controller (iDRAC) 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。
Dell iDRAC の BMC アドレス形式
プロトコル | アドレスのフォーマット |
---|---|
iDRAC 仮想メディア |
|
Redfish ネットワークブート |
|
IPMI |
|
idrac-virtualmedia
を Redfish 仮想メディアのプロトコルとして使用します。redfish-virtualmedia
は Dell ハードウェアでは機能しません。Dell の idrac-virtualmedia
は、Dell の OEM 拡張機能が含まれる Redfish 標準を使用します。
詳細は、以下のセクションを参照してください。
Dell iDRAC の Redfish 仮想メディア
Dell サーバーの Redfish 仮想メディアについては、address
設定で idrac-virtualmedia://
を使用します。redfish-virtualmedia://
を使用しても機能しません。
idrac-virtualmedia://
を Redfish 仮想メディアのプロトコルとして使用します。redfish-virtualmedia://
の使用は、idrac-virtualmedia://
プロトコルが idrac
ハードウェアタイプおよび Ironic の Redfish プロトコルに対応しているため、Dell ハードウェアでは機能しません。Dell の idrac-virtualmedia://
プロトコルは、Dell の OEM 拡張機能が含まれる Redfish 標準を使用します。Ironic は、WSMAN プロトコルのある idrac
タイプもサポートします。したがって、Dell ハードウェア上の仮想メディアで Redfish を使用する際に予期しない動作を回避するために、idrac-virtualmedia://
を指定する必要があります。
以下の例は、install-config.yaml
ファイル内で iDRAC 仮想メディアを使用する方法を示しています。
アウトバウンド管理のアドレスに認証局の証明書を使用することが推奨されますが、自己署名証明書を使用する場合には、bmc
設定に disableCertificateVerification: True
を含める必要があります。
OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは Configuration → Virtual Media → Attach Mode → AutoAttach です。
以下の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用する Redfish 設定を示しています。
iDRAC の Redfish ネットワークブート
Redfish を有効にするには、redfish://
または redfish+http://
を使用してトランスポート層セキュリティー (TLS) を無効にします。インストールプログラムには、ホスト名または IP アドレス、およびシステム ID へのパスの両方が必要です。以下の例は、install-config.yaml
ファイル内の Redfish 設定を示しています。
帯域外管理アドレスの認証局の証明書を用意することが推奨されますが、自己署名証明書を使用する場合は、bmc
設定に disableCertificateVerification: True
を含める必要があります。以下の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用する Redfish 設定を示しています。
ファームウェアバージョン 04.40.00.00
を使用する Dell iDRAC 9 と、ベアメタルデプロイメントで installer-provisioned installation 用の 5.xx
シリーズを含むすべてのリリースには既知の問題があります。Virtual Console プラグインは、HTML5 の拡張バージョンである eHTML5 にデフォルト設定されているため、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、HTML5 を使用するようにプラグインを設定します。メニューパスは以下の通りです。Configuration → Virtual console → Plug-in Type → HTML5
OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration → Virtual Media → Attach Mode → AutoAttach
3.10.5. HPE iLO の BMC アドレス指定 リンクのコピーリンクがクリップボードにコピーされました!
それぞれの bmc
エントリーの address
フィールドは、URL スキーム内のコントローラーのタイプやネットワーク上のその場所を含む、OpenShift Container Platform クラスターノードに接続する URL です。
- 1
address
設定はプロトコルを指定します。
HPE integrated Lights Out (iLO) の場合、Red Hat は Redfish 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。
プロトコル | アドレスのフォーマット |
---|---|
Redfish 仮想メディア |
|
Redfish ネットワークブート |
|
IPMI |
|
詳細は、以下のセクションを参照してください。
HPE iLO の Redfish 仮想メディア
HPE サーバーの Redfish 仮想メディアを有効にするには、address
設定で redfish-virtualmedia://
を使用します。以下の例は、install-config.yaml
ファイル内で Redfish 仮想メディアを使用する方法を示しています。
アウトバウンド管理のアドレスに認証局の証明書を使用することが推奨されますが、自己署名証明書を使用する場合には、bmc
設定に disableCertificateVerification: True
を含める必要があります。以下の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用する Redfish 設定を示しています。
Ironic は、仮想メディアで iLO4 をサポートしないので、Redfish 仮想メディアは、iLO4 を実行する第 9 世代のシステムではサポートされません。
HPE iLO の Redfish ネットワークブート
Redfish を有効にするには、redfish://
または redfish+http://
を使用して TLS を無効にします。インストーラーには、ホスト名または IP アドレスとシステム ID へのパスの両方が必要です。以下の例は、install-config.yaml
ファイル内の Redfish 設定を示しています。
アウトバウンド管理のアドレスに認証局の証明書を使用することが推奨されますが、自己署名証明書を使用する場合には、bmc
設定に disableCertificateVerification: True
を含める必要があります。以下の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用する Redfish 設定を示しています。
3.10.6. Fujitsu iRMC の BMC アドレス指定 リンクのコピーリンクがクリップボードにコピーされました!
それぞれの bmc
エントリーの address
フィールドは、URL スキーム内のコントローラーのタイプやネットワーク上のその場所を含む、OpenShift Container Platform クラスターノードに接続する URL です。
- 1
address
設定はプロトコルを指定します。
Fujitsu ハードウェアの場合、Red Hat は、統合 Remote Management Controller (iRMC) および IPMI をサポートします。
プロトコル | アドレスのフォーマット |
---|---|
iRMC |
|
IPMI |
|
iRMC
Fujitsu ノードは irmc://<out-of-band-ip>
を使用し、デフォルトではポート 443
に設定されます。以下の例は、install-config.yaml
ファイル内の iRMC 設定を示しています。
現在 Fujitsu は、ベアメタルへの installer-provisioned installation 用に iRMC S5 ファームウェアバージョン 3.05P 以降をサポートしています。
3.10.7. ルートデバイスのヒント リンクのコピーリンクがクリップボードにコピーされました!
rootDeviceHints
パラメーターは、インストーラーが Red Hat Enterprise Linux CoreOS (RHCOS) イメージを特定のデバイスにプロビジョニングできるようにします。インストーラーは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。インストーラーは、ヒント値に一致する最初に検出されたデバイスを使用します。この設定は複数のヒントを組み合わせることができますが、デバイスは、インストーラーがこれを選択できるようにすべてのヒントに一致する必要があります。
サブフィールド | 説明 |
---|---|
|
|
|
|
| ベンダー固有のデバイス識別子を含む文字列。ヒントは、実際の値のサブ文字列になります。 |
| デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。 |
| デバイスのシリアル番号を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| デバイスの最小サイズ (ギガバイト単位) を表す整数。 |
| 一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| ベンダー拡張が追加された一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| 一意のベンダーストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| デバイスがローテーションするディスクである (true) か、そうでないか (false) を示すブール値。 |
使用例
3.10.8. オプション: プロキシー設定の設定 リンクのコピーリンクがクリップボードにコピーされました!
プロキシーを使用して OpenShift Container Platform クラスターをデプロイするには、install-config.yaml
ファイルに以下の変更を加えます。
以下は、値を含む noProxy
の例です。
noProxy: .example.com,172.22.0.0/24,10.10.0.0/24
noProxy: .example.com,172.22.0.0/24,10.10.0.0/24
プロキシーを有効な状態にして、対応するキー/値のペアでプロキシーの適切な値を設定します。
主な留意事項:
-
プロキシーに HTTPS プロキシーがない場合、
httpsProxy
の値をhttps://
からhttp://
に変更します。 -
provisioning ネットワークを使用する場合、これを
noProxy
設定に含めます。そうしない場合、インストーラーは失敗します。 -
プロビジョナーノード内の環境変数としてすべてのプロキシー設定を設定します。たとえば、
HTTP_PROXY
、HTTPS_PROXY
、およびNO_PROXY
が含まれます。
IPv6 でプロビジョニングする場合、noProxy
設定で CIDR アドレスブロックを定義することはできません。各アドレスを個別に定義する必要があります。
3.10.9. オプション: プロビジョニングネットワークを使用しないデプロイ リンクのコピーリンクがクリップボードにコピーされました!
provisioning
ネットワークなしに OpenShift Container Platform をデプロイするには、install-config.yaml
ファイルに以下の変更を加えます。
- 1
provisioningNetwork
設定を追加して、必要な場合はこれをDisabled
に設定します。
PXE ブートには provisioning
ネットワークが必要です。provisioning
ネットワークなしでデプロイする場合、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。詳細は、「HPE iLO の BMC アドレス指定」セクションの「HPE iLO の Redfish 仮想メディア」、または「Dell iDRAC の BMC アドレス指定」セクションの「Dell iDRAC の Redfish 仮想メディア」を参照してください。
3.10.10. デュアルスタックネットワークを使用した IP アドレス指定のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ブートストラップ仮想マシン(VM)のデュアルスタックネットワークを使用した IP アドレス指定をデプロイする場合、ブートストラップ仮想マシンは 1 つの IP バージョンで機能します。
以下は DHCP 用です。DHCP ベースのデュアルスタッククラスターは、毎日 1 日に 1 つの IPv4 および 1 つの IPv6 仮想 IP アドレス(VIP)を使用してデプロイできます。
静的 IP アドレスを使用してクラスターをデプロイするには、ブートストラップ VM、API、および Ingress VIP の IP アドレスを設定する必要があります。install-config
で静的 IP セットを使用してデュアルスタックを設定するには、API と Ingress 用にそれぞれ 1 つの VIP が必要です。デプロイ後にセカンダリー VIP を追加します。
OpenShift Container Platform クラスターのデュアルスタックネットワークでは、クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定できます。クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定するには、install-config.yaml
ファイルで machineNetwork
、clusterNetwork
、および serviceNetwork
設定を編集します。それぞれの設定には、それぞれ 2 つの CIDR エントリーが必要です。プライマリーアドレスファミリーとして IPv4 ファミリーを持つクラスターの場合は、最初に IPv4 設定を指定します。プライマリーアドレスファミリーとして IPv6 ファミリーを持つクラスターの場合は、最初に IPv6 設定を指定します。
クラスターノードの IPv4 および IPv6 アドレスエンドポイントを含む NMState YAML 設定ファイルの例
ベアメタルプラットフォームで、install-config.yaml
ファイルの networkConfig
セクションで NMState 設定を指定した場合は、クラスターをデュアルスタックネットワークにデプロイできない問題を解決するために、interfaces.wait-ip: ipv4+ipv6
を NMState YAML ファイルに追加し、あし。
wait-ip
パラメーターを含む NMState YAML 設定ファイルの例
IPv4 および IPv6 アドレスを使用するアプリケーションのクラスターへのインターフェイスを提供するには、Ingress VIP および API VIP サービスの IPv4 および IPv6 仮想 IP (VIP) アドレスエンドポイントを設定します。IPv4 および IPv6 アドレスエンドポイントを設定するには、install-config.yaml
ファイルで apiVIPs
および ingressVIPs
設定を編集します。apiVIPs
および ingressVIPs
設定では、リスト形式を使用します。リストの順序は、各サービスのプライマリーおよびセカンダリー VIP アドレスを示しています。
デュアルスタックネットワーク設定のクラスターの場合、IPv4 アドレスと IPv6 アドレスの両方を同じインターフェイスに割り当てる必要があります。
3.10.11. オプション: ホストネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
インストールの前に、install-config.yaml
ファイルで networkConfig
設定を設定し、NMState を使用してホストネットワークインターフェイスを設定できます。
この機能の最も一般的な使用例は、ベアメタルネットワークで静的 IP アドレスを指定することですが、ストレージネットワークなどの他のネットワークを設定することもできます。この機能は、VLAN、VXLAN、ブリッジ、ボンド、ルート、MTU、DNS リゾルバー設定など、他の NMState 機能をサポートします。
前提条件
-
静的 IP アドレスを持つ各ノードの有効なホスト名で
PTR
DNS レコードを設定する。 -
NMState CLI (
nmstate
) をインストールする。
手順
オプション: インストールプログラムは NMState YAML 構文をチェックしないため、
install-config.yaml
ファイルに NMState 構文を含める前に、nmstatectl gc
を使用して NMState 構文をテストすることを検討してください。注記YAML 構文にエラーがあると、ネットワーク設定の適用に失敗する可能性があります。YAML 構文を検証して管理することは、デプロイ後に Kubernetes NMState を使用して変更を適用するときや、クラスターを拡張するときに役立ちます。
NMState YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nic1_name>
、<ip_address>
、<dns_ip_address>
、<next_hop_ip_address>
、および<next_hop_nic1_name>
を適切な値に置き換えます。
次のコマンドを実行して、設定ファイルをテストします。
nmstatectl gc <nmstate_yaml_file>
$ nmstatectl gc <nmstate_yaml_file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <nmstate_yaml_file>
を設定ファイル名に置き換えます。
install-config.yaml
ファイル内のホストに NMState 設定を追加して、networkConfig
設定を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要クラスターをデプロイした後、
install-config.yaml
ファイルのnetworkConfig
設定を変更して、ホストネットワークインターフェイスを変更することはできません。Kubernetes NMState Operator を使用して、デプロイ後にホストネットワークインターフェイスに変更を加えます。
3.10.12. サブネット用のホストネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
エッジコンピューティングのシナリオでは、コンピュートノードをエッジの近くに配置することが有益な場合があります。サブネット内のリモートノードを見つけるために、コントロールプレーンサブネットやローカルコンピュートノードに使用したものとは異なるネットワークセグメントまたはサブネットをリモートノードに使用できます。エッジコンピューティングシナリオ用にサブネットを設定することで、エッジのレイテンシーが短縮され、拡張性が向上します。
デフォルトのロードバランサー OpenShiftManagedDefault
を使用してリモートノードを OpenShift Container Platform クラスターに追加する場合は、すべてのコントロールプレーンノードが同じサブネット内で実行されている必要があります。複数のサブネットを使用する場合、マニフェストを使用して、コントロールプレーンノード上で実行されるように Ingress VIP を設定することもできます。詳細は、「コントロールプレーンで実行するネットワークコンポーネントの設定」を参照してください。
「サブネット間の通信を確立する」セクションの説明どおりにリモートノードに異なるネットワークセグメントまたはサブネットを確立した場合、ワーカーが静的 IP アドレス、ボンディング、またはその他の高度なネットワークを使用している場合は、machineNetwork
設定でサブネットを指定する必要があります。各リモートノードの networkConfig
パラメーターでノード IP アドレスを設定する場合、静的 IP アドレスを使用する際に、コントロールプレーンノードを含むサブネットのゲートウェイと DNS サーバーも指定する必要があります。これにより、リモートノードがコントロールプレーンを含むサブネットに到達し、コントロールプレーンからネットワークトラフィックを受信できるようになります。
複数のサブネットを持つクラスターをデプロイするには、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディアを使用する必要があります。リモートノードがローカルプロビジョニングネットワークにアクセスできないためです。
手順
静的 IP アドレスを使用する場合は、
install-config.yaml
ファイルのmachineNetwork
にサブネットを追加します。networking: machineNetwork: - cidr: 10.0.0.0/24 - cidr: 192.168.0.0/24 networkType: OVNKubernetes
networking: machineNetwork: - cidr: 10.0.0.0/24 - cidr: 192.168.0.0/24 networkType: OVNKubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的 IP アドレスまたはボンディングなどの高度なネットワークを使用する場合は、NMState 構文を使用して、各エッジコンピュートノードの
networkConfig
パラメーターにゲートウェイと DNS 設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.10.13. オプション: デュアルスタックネットワーク内の SLAAC のアドレス生成モードを設定する リンクのコピーリンクがクリップボードにコピーされました!
Stateless Address AutoConfiguration (SLAAC) を使用するデュアルスタッククラスターの場合は、ipv6.addr-gen-mode
ネットワーク設定のグローバル値を指定する必要があります。NMState を使用してこの値を設定し、ramdisk とクラスター設定ファイルを設定できます。これらの場所で一貫した ipv6.addr-gen-mode
を設定しない場合、クラスター内の CSR リソースと BareMetalHost
リソースの間で IPv6 アドレスの不一致が発生する可能性があります。
前提条件
-
NMState CLI (
nmstate
) をインストールする。
手順
オプション: インストールプログラムは NMState YAML 構文をチェックしないため、
install-config.yaml
ファイルに含める前にnmstatectl gc
コマンドを使用して NMState YAML 構文をテストすることを検討してください。NMState YAML ファイルを作成します。
interfaces: - name: eth0 ipv6: addr-gen-mode: <address_mode>
interfaces: - name: eth0 ipv6: addr-gen-mode: <address_mode>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<address_mode>
を、クラスター内の IPv6 アドレスに必要なアドレス生成モードのタイプに置き換えます。有効な値は、eui64
、stable-privacy
、またはrandom
です。
次のコマンドを実行して、設定ファイルをテストします。
nmstatectl gc <nmstate_yaml_file>
$ nmstatectl gc <nmstate_yaml_file>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nmstate_yaml_file>
を、テスト設定ファイルの名前に置き換えます。
NMState 設定を、install-config.yaml ファイル内の
hosts.networkConfig
セクションに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<address_mode>
を、クラスター内の IPv6 アドレスに必要なアドレス生成モードのタイプに置き換えます。有効な値は、eui64
、stable-privacy
、またはrandom
です。
3.10.14. 複数のクラスターノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
同じ設定で OpenShift Container Platform クラスターノードを同時に設定できます。複数のクラスターノードを設定すると、各ノードの冗長な情報が install-config.yaml
ファイルに追加されることを回避できます。このファイルには、クラスター内の複数のノードに同一の設定を適用するための特定のパラメーターが含まれています。
コンピュートノードは、コントローラーノードとは別に設定されます。ただし、両方のノードタイプの設定では、install-config.yaml
ファイルで強調表示されているパラメーターを使用して、マルチノード設定を有効にします。次の例に示すように、networkConfig
パラメーターを BOND
に設定します。
複数のクラスターノードの設定は、installer-provisioned infrastructure での初期デプロイメントでのみ使用できます。
3.10.15. オプション: マネージドセキュアブートの設定 リンクのコピーリンクがクリップボードにコピーされました!
redfish
、redfish-virtualmedia
、idrac-virtualmedia
などの Redfish BMC アドレス指定を使用して、installer-provisioned クラスターをデプロイする際に管理対象 Secure Boot を有効にすることができます。マネージド Secure Boot を有効にするには、bootMode
設定を各ノードに追加します。
例
ノードがマネージド Secure Boot をサポートできるようにするには、「前提条件」の「ノードの設定」を参照してください。ノードがマネージド Secure Boot に対応していない場合には、「ノードの設定」セクションの「手動での Secure Boot のノードの設定」を参照してください。Secure Boot を手動で設定するには、Redfish 仮想メディアが必要です。
IPMI は Secure Boot 管理機能を提供しないため、Red Hat では IPMI による Secure Boot のサポートはありません。
3.11. マニフェスト設定ファイル リンクのコピーリンクがクリップボードにコピーされました!
3.11.1. OpenShift Container Platform マニフェストの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform マニフェストを作成します。
./openshift-baremetal-install --dir ~/clusterconfigs create manifests
$ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow INFO Consuming Install Config from target directory WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings WARNING Discarding the OpenShift Manifest that was provided in the target directory because its dependencies are dirty and it needs to be regenerated
INFO Consuming Install Config from target directory WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings WARNING Discarding the OpenShift Manifest that was provided in the target directory because its dependencies are dirty and it needs to be regenerated
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.11.2. オプション: 非接続クラスターの NTP 設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスターノードに chrony
Network Time Protocol (NTP) サービスをインストールします。
OpenShift Container Platform ノードは、正しく実行するために日時について合意する必要があります。ワーカーノードがコントロールプレーンノードの NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続されていないクラスターのインストールおよび操作が有効になるため、上位の stratum の NTP サーバーにアクセスできなくなります。
手順
コントロールプレーンノードの
chrony.conf
ファイルのコンテンツを含む Butane 設定 (99-master-chrony-conf-override.bu
) を作成します。注記Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
Butane 設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<cluster-name>
はクラスターの名前に置き換え、<domain>
は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、コントロールプレーンノードに配信される設定が含まれる
MachineConfig
オブジェクトファイル (99-master-chrony-conf-override.yaml
) を生成します。butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
$ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンノードの NTP サーバーを参照するワーカーノードの
chrony.conf
ファイルのコンテンツを含む Butane 設定 (99-worker-chrony-conf-override.bu
) を作成します。Butane 設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<cluster-name>
はクラスターの名前に置き換え、<domain>
は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、ワーカーノードに配信される設定が含まれる
MachineConfig
オブジェクトファイル (99-worker-chrony-conf-override.yaml
) を生成します。butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
$ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.11.3. コントロールプレーンで実行されるネットワークコンポーネントの設定 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークコンポーネントは、コントロールプレーンノードでのみ実行するように設定できます。デフォルトで、OpenShift Container Platform はマシン設定プールの任意のノードが ingressVIP
仮想 IP アドレスをホストできるようにします。ただし、環境によっては、ワーカーノードをコントロールプレーンノードとは別のサブネットにデプロイするため、コントロールプレーンノードで実行する ingressVIP
仮想 IP アドレスを設定する必要があります。
リモートワーカーを別々のサブネットにデプロイする場合は、コントロールプレーンノード専用に ingressVIP
仮想 IP アドレスを配置する必要があります。
手順
install-config.yaml
ファイルを保存するディレクトリーに移動します。cd ~/clusterconfigs
$ cd ~/clusterconfigs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow manifests
サブディレクトリーに切り替えます。cd manifests
$ cd manifests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-network-avoid-workers-99-config.yaml
という名前のファイルを作成します。touch cluster-network-avoid-workers-99-config.yaml
$ touch cluster-network-avoid-workers-99-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エディターで
cluster-network-avoid-workers-99-config.yaml
ファイルを開き、Operator 設定を記述するカスタムリソース (CR) を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このマニフェストは、
ingressVIP
仮想 IP アドレスをコントロールプレーンノードに配置します。また、このマニフェストは、コントロールプレーンノードにのみ以下のプロセスをデプロイします。-
openshift-ingress-operator
-
keepalived
-
-
cluster-network-avoid-workers-99-config.yaml
ファイルを保存します。 manifests/cluster-ingress-default-ingresscontroller.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
manifests
ディレクトリーのバックアップの作成を検討してください。インストーラーは、クラスターの作成時にmanifests/
ディレクトリーを削除します。 cluster-scheduler-02-config.yml
マニフェストを変更し、mastersSchedulable
フィールドをtrue
に設定して、コントロールプレーンノードをスケジュール対象にします。デフォルトでは、コントロールプレーンノードはスケジュール対象ではありません。以下に例を示します。sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml
$ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この手順の完了後にコントロールプレーンノードをスケジュールできない場合には、クラスターのデプロイに失敗します。
3.11.4. オプション: ワーカーノードへのルーターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
インストール時に、インストーラーはルーター Pod をワーカーノードにデプロイします。デフォルトで、インストーラーは 2 つのルーター Pod をインストールします。デプロイされたクラスターが、OpenShift Container Platform クラスター内のサービスに対して予定される外部トラフィック負荷を処理するために追加のルーターを必要とする場合、yaml
ファイルを作成して適切なルーターレプリカ数を設定できます。
ワーカーノードが 1 つだけのクラスターのデプロイはサポートされていません。ルーターのレプリカを変更することで、1 つのワーカーでデプロイする場合の degraded
状態の問題は対処されますが、クラスターは Ingress API の高可用性を失うため、これは実稼働環境には適しません。
デフォルトで、インストーラーは 2 つのルーターをデプロイします。クラスターにワーカーノードがない場合、インストーラーはデフォルトで 2 つのルーターをコントロールプレーンノードにデプロイします。
手順
router-replicas.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記<num-of-router-pods>
を適切な値に置き換えます。1 つのワーカーノードのみを使用している場合、replicas:
を1
に設定します。4 つ以上のワーカーノードを使用している場合、replicas:
のデフォルトの値2
を随時増やすことができます。router-replicas.yaml
ファイルを保存し、これをclusterconfigs/openshift
ディレクトリーにコピーします。cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml
$ cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.11.5. オプション: BIOS の設定 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、インストールプロセス中に BIOS を設定します。
手順
- マニフェストを作成します。
ノードに対応する
BareMetalHost
リソースファイルを変更します。vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
$ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BIOS 設定を
BareMetalHost
リソースのspec
セクションに追加します。spec: firmware: simultaneousMultithreadingEnabled: true sriovEnabled: true virtualizationEnabled: true
spec: firmware: simultaneousMultithreadingEnabled: true sriovEnabled: true virtualizationEnabled: true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Red Hat は 3 つの BIOS 設定をサポートしています。BMC タイプ
irmc
のサーバーのみがサポートされます。他のタイプのサーバーは現在サポートされていません。- クラスターを作成します。
3.11.6. 必要に応じて RAID の設定 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、インストールプロセス中に RAID (Redundant Array of Independent Disks) を設定します。
- OpenShift Container Platform は、iRMC プロトコルのみを使用してベースボード管理コントローラー (BMC) のハードウェア RAID をサポートします。OpenShift Container Platform 4.12 は、ソフトウェア RAID をサポートしていません。
- ノードにハードウェア RAID を設定する場合は、ノードに RAID コントローラーがあることを確認します。
手順
- マニフェストを作成します。
ノードに対応する
BareMetalHost
リソースを変更します。vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
$ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform 4.12 はソフトウェア RAID をサポートしていないため、以下の例ではハードウェア RAID 設定を使用します。
特定の RAID 設定を
spec
セクションに追加した場合、これが原因でノードはpreparing
フェーズで元の RAID 設定を削除し、RAID で指定された設定を実行します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
level
は必須フィールドであり、その他はオプションのフィールドです。
spec
セクションに空の RAID 設定を追加した場合、空の設定が原因で、ノードはpreparing
フェーズで元の RAID 設定を削除しますが、新しい設定は実行しません。以下に例を示します。spec: raid: hardwareRAIDVolumes: []
spec: raid: hardwareRAIDVolumes: []
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
spec
セクションにraid
フィールドを追加しない場合、元の RAID 設定は削除されず、新しい設定は実行されません。
- クラスターを作成します。
3.12. 非接続レジストリーの作成 リンクのコピーリンクがクリップボードにコピーされました!
インストールレジストリーのローカルコピーを使用して OpenShift Container Platform クラスターをインストールする必要がある場合があります。これにより、クラスターノードがインターネットにアクセスできないネットワーク上にあるため、ネットワークの効率が高まる可能性があります。
レジストリーのローカルまたはミラーリングされたコピーには、以下が必要です。
- レジストリーの証明書。これには、自己署名証明書を使用できます。
- システム上のコンテナーが提供する Web サーバー。
- 証明書およびローカルリポジトリーの情報が含まれる更新されたプルシークレット。
レジストリーノードでの非接続レジストリーの作成はオプションです。レジストリーノードで切断されたレジストリーを作成する必要がある場合は、次のサブセクションをすべて完了する必要があります。
前提条件
3.12.1. ミラーリングされたレジストリーをホストするためのレジストリーノードの準備 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルでミラー化されたレジストリーをホストする前に、次の手順を完了する必要があります。
手順
レジストリーノードでファイアウォールポートを開きます。
sudo firewall-cmd --add-port=5000/tcp --zone=libvirt --permanent
$ sudo firewall-cmd --add-port=5000/tcp --zone=libvirt --permanent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo firewall-cmd --add-port=5000/tcp --zone=public --permanent
$ sudo firewall-cmd --add-port=5000/tcp --zone=public --permanent
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo firewall-cmd --reload
$ sudo firewall-cmd --reload
Copy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーノードに必要なパッケージをインストールします。
sudo yum -y install python3 podman httpd httpd-tools jq
$ sudo yum -y install python3 podman httpd httpd-tools jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リポジトリー情報が保持されるディレクトリー構造を作成します。
sudo mkdir -p /opt/registry/{auth,certs,data}
$ sudo mkdir -p /opt/registry/{auth,certs,data}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.12.2. 切断されたレジストリーの OpenShift Container Platform イメージリポジトリーのミラーリング リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を実行して、切断されたレジストリーの OpenShift Container Platform イメージリポジトリーをミラーリングします。
前提条件
- ミラーホストがインターネットにアクセスできる。
- ネットワークが制限された環境で使用するミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできる。
- Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を含めるようにこれを変更している。
手順
- OpenShift Container Platform ダウンロード ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、Repository Tags ページで対応するタグを判別します。
必要な環境変数を設定します。
リリースバージョンをエクスポートします。
OCP_RELEASE=<release_version>
$ OCP_RELEASE=<release_version>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <release_version>
について、インストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例:4.5.4
)。ローカルレジストリー名とホストポートをエクスポートします。
LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
$ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <local_registry_host_name>
には、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port>
には、コンテンツの送信に使用するポートを指定します。ローカルリポジトリー名をエクスポートします。
LOCAL_REPOSITORY='<local_repository_name>'
$ LOCAL_REPOSITORY='<local_repository_name>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <local_repository_name>
には、ocp4/openshift4
などのレジストリーに作成するリポジトリーの名前を指定します。ミラーリングするリポジトリーの名前をエクスポートします。
PRODUCT_REPO='openshift-release-dev'
$ PRODUCT_REPO='openshift-release-dev'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実稼働環境のリリースの場合には、
openshift-release-dev
を指定する必要があります。パスをレジストリープルシークレットにエクスポートします。
LOCAL_SECRET_JSON='<path_to_pull_secret>'
$ LOCAL_SECRET_JSON='<path_to_pull_secret>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <path_to_pull_secret>
には、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。リリースミラーをエクスポートします。
RELEASE_NAME="ocp-release"
$ RELEASE_NAME="ocp-release"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 実稼働環境のリリースについては、
ocp-release
を指定する必要があります。サーバーのアーキテクチャーのタイプをエクスポートします (例:
x86_64
)。ARCHITECTURE=<server_architecture>
$ ARCHITECTURE=<server_architecture>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。
REMOVABLE_MEDIA_PATH=<path>
$ REMOVABLE_MEDIA_PATH=<path>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 最初のスラッシュ (/) 文字を含む完全パスを指定します。
バージョンイメージをミラーレジストリーにミラーリングします。
ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。
- リムーバブルメディアをインターネットに接続しているシステムに接続します。
ミラーリングするイメージおよび設定マニフェストを確認します。
oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。 イメージをリムーバブルメディア上のディレクトリーにミラーリングします。
oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。
oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
$ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
REMOVABLE_MEDIA_PATH
の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。
ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。
以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。
oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} \ --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \ --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \ --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な
imageContentSources
データが含まれます。直前のコマンドの出力の
imageContentSources
セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時にimageContentSources
セクションをinstall-config.yaml
ファイルに追加する必要があります。注記ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。
ミラーリングしたコンテンツに基づくインストールプログラムを作成するために、インストールプログラムを展開してリリースに固定します。
ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。
oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下のコマンドを実行します。
oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
$ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要選択した OpenShift Container Platform のバージョンに適したイメージを確実に使用するために、ミラーリングしたコンテンツからインストールプログラムを展開する必要があります。
インターネット接続のあるマシンで、このステップを実行する必要があります。
非接続環境を使用している場合には、must-gather の一部として
--image
フラグを使用し、ペイロードイメージを参照します。
installer-provisioned infrastructure を使用するクラスターの場合は、以下のコマンドを実行します。
openshift-baremetal-install
$ openshift-baremetal-install
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.12.3. 非接続レジストリーを使用するように install-config.yaml ファイルを変更する リンクのコピーリンクがクリップボードにコピーされました!
プロビジョナーノードでは、install-config.yaml
ファイルは pull-secret-update.txt
ファイルから新たに作成された pull-secret を使用する必要があります。install-config.yaml
ファイルには、非接続レジストリーノードの証明書およびレジストリー情報も含まれる必要があります。
手順
非接続レジストリーノードの証明書を
install-config.yaml
ファイルに追加します。echo "additionalTrustBundle: |" >> install-config.yaml
$ echo "additionalTrustBundle: |" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書は
"additionalTrustBundle: |"
行に従い、通常は 2 つのスペースで適切にインデントされる必要があります。sed -e 's/^/ /' /opt/registry/certs/domain.crt >> install-config.yaml
$ sed -e 's/^/ /' /opt/registry/certs/domain.crt >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーのミラー情報を
install-config.yaml
ファイルに追加します。echo "imageContentSources:" >> install-config.yaml
$ echo "imageContentSources:" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo "- mirrors:" >> install-config.yaml
$ echo "- mirrors:" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo " - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
$ echo " - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry.example.com
をレジストリーの完全修飾ドメイン名に置き換えます。echo " source: quay.io/openshift-release-dev/ocp-release" >> install-config.yaml
$ echo " source: quay.io/openshift-release-dev/ocp-release" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo "- mirrors:" >> install-config.yaml
$ echo "- mirrors:" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo " - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
$ echo " - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry.example.com
をレジストリーの完全修飾ドメイン名に置き換えます。echo " source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml
$ echo " source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.13. ブートストラップ VM への静的 IP アドレスの割り当て リンクのコピーリンクがクリップボードにコピーされました!
baremetal
ネットワークに DHCP サーバーを使用せずに OpenShift Container Platform をデプロイする場合は、Ignition を使用してブートストラップ VM の静的 IP アドレスを設定する必要があります。
手順
Ignition 設定ファイルを作成します。
./openshift-baremetal-install --dir <cluster_configs> create ignition-configs
$ ./openshift-baremetal-install --dir <cluster_configs> create ignition-configs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <cluster_configs>
をクラスター設定ファイルへのパスに置き換えます。bootstrap_config.sh
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <ip_address>
と<cidr>
をアドレス範囲の IP アドレスと CIDR に置き換えます。<gateway_ip_address>
を、baremetal
ネットワークのゲートウェイの IP アドレスに置き換えます。<dns_ip_address>
をbaremetal
ネットワーク上の DNS サーバーの IP アドレスに置き換えます。<cluster_configs>
をクラスター設定ファイルへのパスに置き換えます。bootstrap_config.sh
ファイルを実行可能にします。chmod 755 bootstrap_config.sh
$ chmod 755 bootstrap_config.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootstrap_config.sh
スクリプトを実行して、bootstrap_network_config.ign
ファイルを作成します。./bootstrap_config.sh
$ ./bootstrap_config.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.14. インストールの検証チェックリスト リンクのコピーリンクがクリップボードにコピーされました!
- ❏ OpenShift Container Platform インストーラーが取得されている。
- ❏ OpenShift Container Platform インストーラーがデプロイメントされている。
-
❏
install-config.yaml
の必須パラメーターが設定されている。 -
❏
install-config.yaml
のhosts
パラメーターが設定されている。 -
❏
install-config.yaml
のbmc
パラメーターが設定されている。 -
❏
bmc
address
フィールドで設定されている値の変換が適用されている。 - ❏ OpenShift Container Platform マニフェストが作成されている。
- ❏ (オプション) ルーターをワーカーノードにデプロイしている。
- ❏ (オプション) 切断されたレジストリーを作成している。
- ❏ (オプション) 非接続レジストリー設定が使用されている場合にこれを検証する。
第4章 クラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
4.1. OpenShift Container Platform インストーラーを使用したクラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform インストーラーを実行します。
./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster
$ ./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster
4.2. インストールの進行状況を追跡 リンクのコピーリンクがクリップボードにコピーされました!
デプロイメントプロセスで、tail
コマンドを install ディレクトリーフォルダーの .openshift_install.log
ログファイルに対して実行して、インストールの全体のステータスを確認できます。
tail -f /path/to/install-dir/.openshift_install.log
$ tail -f /path/to/install-dir/.openshift_install.log
4.3. 静的 IP アドレス設定の検証 リンクのコピーリンクがクリップボードにコピーされました!
クラスターノードの DHCP 予約で無限リースが指定されている場合、インストーラーがノードを正常にプロビジョニングした後に、dispatcher スクリプトはノードのネットワーク設定をチェックします。ネットワーク設定に無限 DHCP リースが含まれているとスクリプトが判断すると、DHCP リースの IP アドレスを静的 IP アドレスとして使用して新規接続を作成します。
dispatcher スクリプトは、クラスター内の他のノードのプロビジョニングの進行中に、正常にプロビジョニングされたノードで実行される場合があります。
ネットワーク設定が正しく機能していることを確認します。
手順
- ノードのネットワークインターフェイス設定を確認してください。
- DHCP サーバーをオフにし、OpenShift Container Platform ノードを再起動して、ネットワーク設定が適切に機能していることを確認します。
4.4. ベアメタルにクラスターを再インストールする準備 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルにクラスターを再インストールする前に、クリーンアップ操作を実行する必要があります。
手順
- ブートストラップ、コントロールプレーンノード、およびワーカーノードのディスクを削除または再フォーマットします。ハイパーバイザー環境で作業している場合は、削除したディスクを追加する必要があります。
以前のインストールで生成されたアーティファクトを削除します。
cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \ .openshift_install.log .openshift_install_state.json
$ cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \ .openshift_install.log .openshift_install_state.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 新しいマニフェストと Ignition 設定ファイルを生成します。詳細は、「Kubernetes マニフェストおよび Ignition 設定ファイルの作成」を参照してください。
- インストールプログラムが作成した新規ブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これにより、以前の Ignition ファイルが上書きされます。
第5章 installer-provisioned のインストール後の設定 リンクのコピーリンクがクリップボードにコピーされました!
installer-provisioned クラスターを正常にデプロイしたら、以下のインストール後の手順を考慮してください。
5.1. オプション: 非接続クラスターの NTP 設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスターノードに chrony
Network Time Protocol (NTP) サービスをインストールします。以下の手順を使用して、コントロールプレーンノードで NTP サーバーを設定し、デプロイメントが正常に完了した後にコントロールプレーンノードの NTP クライアントとしてワーカーノードを設定します。
OpenShift Container Platform ノードは、正しく実行するために日時について合意する必要があります。ワーカーノードがコントロールプレーンノードの NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続されていないクラスターのインストールおよび操作が有効になるため、上位の stratum の NTP サーバーにアクセスできなくなります。
手順
コントロールプレーンノードの
chrony.conf
ファイルのコンテンツを含む Butane 設定 (99-master-chrony-conf-override.bu
) を作成します。注記Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
Butane 設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<cluster-name>
はクラスターの名前に置き換え、<domain>
は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、コントロールプレーンノードに配信される設定が含まれる
MachineConfig
オブジェクトファイル (99-master-chrony-conf-override.yaml
) を生成します。butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
$ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンノードの NTP サーバーを参照するワーカーノードの
chrony.conf
ファイルのコンテンツを含む Butane 設定 (99-worker-chrony-conf-override.bu
) を作成します。Butane 設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<cluster-name>
はクラスターの名前に置き換え、<domain>
は完全修飾ドメイン名に置き換える必要があります。
Butane を使用して、ワーカーノードに配信される設定が含まれる
MachineConfig
オブジェクトファイル (99-worker-chrony-conf-override.yaml
) を生成します。butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
$ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 99-master-chrony-conf-override.yaml
ポリシーをコントロールプレーンノードに適用します。oc apply -f 99-master-chrony-conf-override.yaml
$ oc apply -f 99-master-chrony-conf-override.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
machineconfig.machineconfiguration.openshift.io/99-master-chrony-conf-override created
machineconfig.machineconfiguration.openshift.io/99-master-chrony-conf-override created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 99-worker-chrony-conf-override.yaml
ポリシーをワーカーノードに適用します。oc apply -f 99-worker-chrony-conf-override.yaml
$ oc apply -f 99-worker-chrony-conf-override.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
machineconfig.machineconfiguration.openshift.io/99-worker-chrony-conf-override created
machineconfig.machineconfiguration.openshift.io/99-worker-chrony-conf-override created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 適用された NTP 設定のステータスを確認します。
oc describe machineconfigpool
$ oc describe machineconfigpool
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. インストール後のプロビジョニングネットワークの有効化 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスター用の Assisted Installer および installer-provisioned installation は、provisioning
ネットワークなしでクラスターをデプロイする機能を提供します。この機能は、概念実証クラスターや、各ノードのベースボード管理コントローラーが baremetal
ネットワークを介してルーティング可能な場合に Redfish 仮想メディアのみを使用してデプロイするなどのシナリオ向けです。
Cluster Baremetal Operator (CBO) を使用してインストール後に provisioning
ネットワークを有効にすることができます。
前提条件
- すべてのワーカーノードおよびコントロールプレーンノードに接続されている専用の物理ネットワークが存在する必要があります。
- ネイティブのタグなしの物理ネットワークを分離する必要があります。
-
provisioningNetwork
設定がManaged
に設定されている場合、ネットワークには DHCP サーバーを含めることはできません。 -
OpenShift Container Platform 4.10 の
provisioningInterface
設定を省略して、bootMACAddress
設定を使用できます。
手順
-
provisioningInterface
設定を設定する場合、まずクラスターノードのプロビジョニングインターフェイス名を特定します。たとえば、eth0
またはeno1
などです。 -
クラスターノードの
provisioning
ネットワークインターフェイスで Preboot eXecution Environment (PXE) を有効にします。 provisioning
ネットワークの現在の状態を取得して、これをプロビジョニングカスタムリソース (CR) ファイルに保存します。oc get provisioning -o yaml > enable-provisioning-nw.yaml
$ oc get provisioning -o yaml > enable-provisioning-nw.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョニング CR ファイルを変更します。
vim ~/enable-provisioning-nw.yaml
$ vim ~/enable-provisioning-nw.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow provisioningNetwork
設定までスクロールダウンして、これをDisabled
からManaged
に変更します。次に、provisioningNetwork
設定の後に、provisioningIP
、provisioningNetworkCIDR
、provisioningDHCPRange
、provisioningInterface
、およびwatchAllNameSpaces
設定を追加します。各設定に適切な値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
provisioningNetwork
は、Managed
、Unmanaged
、またはDisabled
のいずれかになります。Managed
に設定すると、Metal3 はプロビジョニングネットワークを管理し、CBO は設定済みの DHCP サーバーで Metal3 Pod をデプロイします。Unmanaged
に設定すると、システム管理者は DHCP サーバーを手動で設定します。- 2
provisioningIP
は、DHCP サーバーおよび ironic がネットワークのプロビジョニングために使用する静的 IP アドレスです。この静的 IP アドレスは、DHCP 範囲外のprovisioning
内でなければなりません。この設定を設定する場合は、provisioning
ネットワークがDisabled
の場合でも、有効な IP アドレスが必要です。静的 IP アドレスは metal3 Pod にバインドされます。metal3 Pod が失敗し、別のサーバーに移動する場合、静的 IP アドレスも新しいサーバーに移動します。- 3
- Classless Inter-Domain Routing (CIDR) アドレス。この設定を設定する場合は、
provisioning
ネットワークがDisabled
の場合でも、有効な CIDR アドレスが必要です。例:192.168.0.1/24
- 4
- DHCP の範囲。この設定は、
Managed
プロビジョニングネットワークにのみ適用されます。provisioning
ネットワークがDisabled
の場合は、この設定を省略します。例:192.168.0.64, 192.168.0.253
- 5
- クラスターノードの
provisioning
インターフェイス用の NIC 名。provisioningInterface
設定は、Managed
およびUnmanaged
プロビジョニングネットワークにのみ適用されます。provisioning
ネットワークがDisabled
の場合に、provisioningInterface
設定が省略されます。代わりにbootMACAddress
設定を使用するようにprovisioningInterface
設定を省略します。 - 6
- metal3 がデフォルトの
openshift-machine-api
namespace 以外の namespace を監視するようにするには、この設定をtrue
に設定します。デフォルト値はfalse
です。
- 変更をプロビジョニング CR ファイルに保存します。
プロビジョニング CR ファイルをクラスターに適用します。
oc apply -f enable-provisioning-nw.yaml
$ oc apply -f enable-provisioning-nw.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. 外部ロードバランサー用のサービス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、外部ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
外部ロードバランサーに対して、これらのサービスの 1 つまたはすべてを設定するように選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図5.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図5.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図5.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例
外部ロードバランサーでは、次の設定オプションがサポートされています。
- ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。
サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。
/27
や/28
などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。ヒントマシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。
OpenShift Container Platform クラスターの外部ロードバランサーを設定する前に、以下の情報を考慮してください。
- フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能については、ベンダーのドキュメントを確認してください。
バックエンド IP アドレスの場合、OpenShift Container Platform コントロールプレーンノードの IP アドレスが、外部ロードバランサーの存続期間中に変更されないようにください。次のいずれかのアクションを実行すると、これを実現できます。
- 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
- ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
- Ingress Controller バックエンドサービスの外部ロードバランサーで、Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。
5.3.1. 外部ロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーを設定する前に、「外部ロードバランサー用のサービス」セクションを必ず確認してください。
外部ロードバランサー用に設定するサービスに適用される次の前提条件を確認してください。
クラスター上で動作する MetalLB は、外部ロードバランサーとして機能します。
OpenShift API の前提条件
- フロントエンド IP アドレスを定義している。
TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。
- ポート 6443 が OpenShift API サービスにアクセスできる。
- ポート 22623 が Ignition 起動設定をノードに提供できる。
- フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
- フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
- ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。
Ingress Controller の前提条件
- フロントエンド IP アドレスを定義している。
- TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
- フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
- フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
- ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。
ヘルスチェック URL 仕様の前提条件
ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できます。OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。
次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。
Kubernetes API ヘルスチェック仕様の例
Path: HTTPS:6443/readyz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Machine Config API ヘルスチェック仕様の例
Path: HTTPS:22623/healthz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Ingress Controller のヘルスチェック仕様の例
Path: HTTP:1936/healthz/ready Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
手順
HAProxy Ingress Controller を設定して、ポート 6443、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。
HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow curl
CLI コマンドを使用して、外部ロードバランサーとそのリソースが動作していることを確認します。次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。
curl https://<loadbalancer_ip_address>:6443/version --insecure
$ curl https://<loadbalancer_ip_address>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
外部ロードバランサーのフロントエンド IP アドレスをターゲットにするように、クラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。
変更された DNS レコードの例
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。
curl
CLI コマンドを使用して、外部ロードバランサーと DNS レコード設定が動作していることを確認します。次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。
curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。
curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。
curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 クラスターの拡張 リンクのコピーリンクがクリップボードにコピーされました!
installer-provisioned OpenShift Container Platform クラスターのデプロイ後に、以下の手順を使用してワーカーノードの数を拡張することができます。それぞれの候補となるワーカーノードが前提条件を満たしていることを確認します。
RedFish Virtual Media を使用してクラスターを拡張するには、最低限のファームウェア要件を満たす必要があります。RedFish Virtual Media を使用したクラスターの拡張時の詳細は、前提条件 セクションの 仮想メディアを使用したインストールのファームウェア要件 を参照してください。
6.1. ベアメタルノードの準備 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを拡張するには、ノードに関連する IP アドレスを提供する必要があります。これは、静的設定または DHCP (動的ホスト設定プロトコル) サーバーを使用して行うことができます。DHCP サーバーを使用してクラスターを拡張する場合、各ノードには DHCP 予約が必要です。
一部の管理者は、各ノードの IP アドレスが DHCP サーバーがない状態で一定になるように静的 IP アドレスの使用を選択します。NMState で静的 IP アドレスを設定するには、「OpenShift インストールの環境のセットアップ」セクションの「オプション: install-config.yaml
でのホストネットワークインターフェイスの設定」で追加の詳細を参照してください。
ベアメタルノードを準備するには、プロビジョナーノードから以下の手順を実行する必要があります。
手順
oc
バイナリーを取得します。curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux-$VERSION.tar.gz | tar zxvf - oc
$ curl -s https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux-$VERSION.tar.gz | tar zxvf - oc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo cp oc /usr/local/bin
$ sudo cp oc /usr/local/bin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ベースボード管理コントローラー (BMC) を使用してベアメタルノードの電源を切り、オフになっていることを確認します。
ベアメタルノードのベースボード管理コントローラーのユーザー名およびパスワードを取得します。次に、ユーザー名とパスワードから
base64
文字列を作成します。echo -ne "root" | base64
$ echo -ne "root" | base64
Copy to Clipboard Copied! Toggle word wrap Toggle overflow echo -ne "password" | base64
$ echo -ne "password" | base64
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ベアメタルノードの設定ファイルを作成します。静的設定または DHCP サーバーのどちらを使用しているかに応じて、次の例の
bmh.yaml
ファイルのいずれかを使用し、環境に合わせて YAML の値を置き換えます。vim bmh.yaml
$ vim bmh.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的設定
bmh.yaml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しく作成されたノードのネットワークインターフェイスを設定するには、ネットワーク設定を含むシークレットの名前を指定します。
nmstate
構文に従って、ノードのネットワーク設定を定義します。NMState 構文の設定に関する詳細は、「オプション: install-config.yaml ファイルでのホストネットワークインターフェイスの設定」を参照してください。 - 2 10 13 16
name
、credentialsName
、およびpreprovisioningNetworkDataName
フィールドの<num>
は、ベアメタルノードのワーカー番号に置き換えます。- 3
- NMState YAML 構文を追加して、ホストインターフェイスを設定します。
- 4
- オプション:
nmstate
を使用してネットワークインターフェイスを設定しており、インターフェイスを無効にする場合は、次のように IP アドレスをenabled: false
に設定してstate: up
を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 5 6 7 8 9
<nic1_name>
、<ip_address>
、<dns_ip_address>
、<next_hop_ip_address>
、および<next_hop_nic1_name>
を適切な値に置き換えます。- 11 12
<base64_of_uid>
と<base64_of_pwd>
は、ユーザー名とパスワードの base64 文字列に置き換えます。- 14
<nic1_mac_address>
を、ベアメタルノードの最初の NIC の MAC アドレスに置き換えます。追加の BMC 設定オプションは、「BMC アドレス指定」のセクションを参照してください。- 15
<protocol>
は、IPMI、RedFish などの BMC プロトコルに置き換えます。<bmc_url>
を、ベアメタルノードのベースボード管理コントローラーの URL に置き換えます。- 17
- 証明書の検証をスキップするには、
disableCertificateVerification
を true に設定します。 - 18 19
<bmc_username>
と<bmc_password>
を BMC ユーザー名とパスワードの文字列に置き換えます。- 20
- オプション: root デバイスヒントを指定する場合は、
<root_device_hint>
をデバイスパスに置き換えます。 - 21
- オプション: 新しく作成されたノードのネットワークインターフェイスを設定した場合は、BareMetalHost CR の
preprovisioningNetworkDataName
にネットワーク設定のシークレット名を指定します。
DHCP 設定
bmh.yaml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 4 7
name
、credentialsName
、およびpreprovisioningNetworkDataName
フィールドの<num>
は、ベアメタルノードのワーカー番号に置き換えます。- 2 3
<base64_of_uid>
と<base64_of_pwd>
は、ユーザー名とパスワードの base64 文字列に置き換えます。- 5
<nic1_mac_address>
を、ベアメタルノードの最初の NIC の MAC アドレスに置き換えます。追加の BMC 設定オプションは、「BMC アドレス指定」のセクションを参照してください。- 6
<protocol>
は、IPMI、RedFish などの BMC プロトコルに置き換えます。<bmc_url>
を、ベアメタルノードのベースボード管理コントローラーの URL に置き換えます。- 8
- 証明書の検証をスキップするには、
disableCertificateVerification
を true に設定します。 - 9 10
<bmc_username>
と<bmc_password>
を BMC ユーザー名とパスワードの文字列に置き換えます。- 11
- オプション: root デバイスヒントを指定する場合は、
<root_device_hint>
をデバイスパスに置き換えます。 - 12
- オプション: 新しく作成されたノードのネットワークインターフェイスを設定した場合は、BareMetalHost CR の
preprovisioningNetworkDataName
にネットワーク設定のシークレット名を指定します。
注記既存のベアメタルノードの MAC アドレスが、プロビジョニングしようとしているベアメタルホストの MAC アドレスと一致する場合、Ironic インストールは失敗します。ホストの登録、検査、クリーニング、または他の Ironic 手順が失敗する場合、ベアメタル Operator はインストールを継続的に再試行します。詳細は、「ホストの重複した MAC アドレスの診断」を参照してください。
ベアメタルノードを作成します。
oc -n openshift-machine-api create -f bmh.yaml
$ oc -n openshift-machine-api create -f bmh.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
secret/openshift-worker-<num>-network-config-secret created secret/openshift-worker-<num>-bmc-secret created baremetalhost.metal3.io/openshift-worker-<num> created
secret/openshift-worker-<num>-network-config-secret created secret/openshift-worker-<num>-bmc-secret created baremetalhost.metal3.io/openshift-worker-<num> created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <num>
はワーカー番号です。ベアメタルノードの電源をオンにし、これを検査します。
oc -n openshift-machine-api get bmh openshift-worker-<num>
$ oc -n openshift-machine-api get bmh openshift-worker-<num>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <num>
はワーカーノード番号です。出力例
NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> available true
NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> available true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ワーカーノードがクラスターに参加できるようにするには、
machineset
オブジェクトをBareMetalHost
オブジェクトの数にスケーリングします。ノードは手動または自動でスケーリングできます。ノードを自動的にスケーリングするには、machineset
にmetal3.io/autoscale-to-hosts
アノテーションを使用します。
6.2. ベアメタルコントロールプレーンノードの交換 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、installer-provisioned OpenShift Container Platform コントロールプレーンノードを置き換えます。
既存のコントロールプレーンホストから BareMetalHost
オブジェクト定義を再利用する場合は、externallyProvisioned
フィールドを true
に設定したままにしないでください。
既存のコントロールプレーン BareMetalHost
オブジェクトが、OpenShift Container Platform インストールプログラムによってプロビジョニングされた場合には、externallyProvisioned
フラグが true
に設定されている可能性があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 etcd のバックアップを取得している。
重要問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd のバックアップを作成してください。etcd バックアップの作成に関する詳細は、関連情報 セクションを参照してください。
手順
Bare Metal Operator が使用可能であることを確認します。
oc get clusteroperator baremetal
$ oc get clusteroperator baremetal
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE baremetal 4.12.0 True False False 3d15h
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE baremetal 4.12.0 True False False 3d15h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 古い
BareMetalHost
オブジェクトおよびMachine
オブジェクトを削除します。oc delete bmh -n openshift-machine-api <host_name> oc delete machine -n openshift-machine-api <machine_name>
$ oc delete bmh -n openshift-machine-api <host_name> $ oc delete machine -n openshift-machine-api <machine_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <host_name>
をホストの名前に、<machine_name>
をマシンの名前に置き換えます。マシン名はCONSUMER
フィールドの下に表示されます。BareMetalHost
オブジェクトとMachine
オブジェクトを削除すると、マシンコントローラーはNode
オブジェクトを自動的に削除します。新しい
BareMetalHost
オブジェクトとシークレットを作成して BMC 認証情報を保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 4 6
name
およびcredentialsName
フィールドの<num>
は、ベアメタルノードのコントロールプレーン番号に置き換えます。- 2
<base64_of_uid>
を、ユーザー名のbase64
文字列に置き換えます。- 3
<base64_of_pwd>>
を、パスワードのbase64
文字列に置き換えます。- 5
<protocol>
をredfish
、redfish-virtualmedia
、idrac-virtualmedia
などの BMC プロトコルに置き換えます。<bmc_ip>
は、ベアメタルノードのベースボード管理コントローラーの IP アドレスに置き換えます。その他の BMC 設定オプションについては、関連情報 セクションの「BMC アドレス指定」を参照してください。- 7
<NIC1_mac_address>
は、ベアメタルノードの最初の NIC の MAC アドレスに置き換えます。
検査が完了すると、
BareMetalHost
オブジェクトが作成され、プロビジョニングできるようになります。利用可能な
BareMetalHost
オブジェクトを表示します。oc get bmh -n openshift-machine-api
$ oc get bmh -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンノード用の
MachineSet
オブジェクトがないため、代わりにMachine
オブジェクトを作成する必要があります。別のコントロールプレーンMachine
オブジェクトからproviderSpec
をコピーできます。Machine
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow BareMetalHost
オブジェクトを表示するには、次のコマンドを実行します。oc get bmh -A
$ oc get bmh -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS のインストール後、
BareMetalHost
がクラスターに追加されていることを確認します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記新しいコントロールプレーンノードの交換後、新しいノードで実行されている etcd Pod は
crashloopback
ステータスになります。詳細は、関連情報 セクションの「正常でない etcd メンバーの置き換え」を参照してください。
6.3. ベアメタルネットワークに仮想メディアを使用してデプロイメントする準備 リンクのコピーリンクがクリップボードにコピーされました!
provisioning
ネットワークが有効で、baremetal
ネットワークで Virtual Media を使用してクラスターを拡張する場合は、以下の手順を使用します。
前提条件
-
baremetal
ネットワークおよびprovisioning
ネットワークを使用する既存のクラスターがあります。
手順
provisioning
カスタムリソース (CR) を編集して、baremetal
ネットワーク上の仮想メディアを使用したデプロイを有効にします。oc edit provisioning
oc edit provisioning
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
virtualMediaViaExternalNetwork: true
をprovisioning
CR に追加します。
イメージ URL が存在する場合は、
machineset
を編集して API VIP アドレスを使用します。この手順は、バージョン 4.9 以前でインストールされたクラスターにのみ適用されます。oc edit machineset
oc edit machineset
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4. クラスター内の新しいホストをプロビジョニングする際の重複する MAC アドレスの診断 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の既存のベアメタルノードの MAC アドレスが、クラスターに追加しようとしているベアメタルホストの MAC アドレスと一致する場合、ベアメタル Operator はホストを既存のノードに関連付けます。ホストの登録、検査、クリーニング、または他の Ironic 手順が失敗する場合、ベアメタル Operator はインストールを継続的に再試行します。障害が発生したベアメタルホストの登録エラーが表示されます。
openshift-machine-api
namespace で実行されているベアメタルホストを調べることで、重複する MAC アドレスを診断できます。
前提条件
- ベアメタルに OpenShift Container Platform クラスターをインストールする。
-
OpenShift Container Platform CLI (
oc
) をインストールする。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
プロビジョニングに失敗したベアメタルホストが既存のノードと同じ MAC アドレスを持つかどうかを判断するには、以下を実行します。
openshift-machine-api
namespace で実行されているベアメタルホストを取得します。oc get bmh -n openshift-machine-api
$ oc get bmh -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 障害が発生したホストのステータスに関する詳細情報を表示するには、
<bare_metal_host_name>
をホストの名前に置き換えて、以下のコマンドを実行します。oc get -n openshift-machine-api bmh <bare_metal_host_name> -o yaml
$ oc get -n openshift-machine-api bmh <bare_metal_host_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5. ベアメタルノードのプロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルノードをプロビジョニングするには、プロビジョナーノードから以下の手順を実行する必要があります。
手順
ベアメタルノードをプロビジョニングする前に、
STATE
がavailable
であることを確認してください。oc -n openshift-machine-api get bmh openshift-worker-<num>
$ oc -n openshift-machine-api get bmh openshift-worker-<num>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <num>
はワーカーノード番号です。NAME STATE ONLINE ERROR AGE openshift-worker available true 34h
NAME STATE ONLINE ERROR AGE openshift-worker available true 34h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノードの数を取得します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートマシンセットを取得します。
oc get machinesets -n openshift-machine-api
$ oc get machinesets -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME DESIRED CURRENT READY AVAILABLE AGE ... openshift-worker-0.example.com 1 1 1 1 55m openshift-worker-1.example.com 1 1 1 1 55m
NAME DESIRED CURRENT READY AVAILABLE AGE ... openshift-worker-0.example.com 1 1 1 1 55m openshift-worker-1.example.com 1 1 1 1 55m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノードの数を 1 つ増やします。
oc scale --replicas=<num> machineset <machineset> -n openshift-machine-api
$ oc scale --replicas=<num> machineset <machineset> -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <num>
は、新しいワーカーノード数に置き換えます。<machineset>
は、前のステップで設定したコンピュートマシンの名前に置き換えます。ベアメタルノードのステータスを確認します。
oc -n openshift-machine-api get bmh openshift-worker-<num>
$ oc -n openshift-machine-api get bmh openshift-worker-<num>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <num>
はワーカーノード番号です。STATE がready
からprovisioning
に変わります。NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> provisioning openshift-worker-<num>-65tjz true
NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> provisioning openshift-worker-<num>-65tjz true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow provisioning
ステータスは、OpenShift Container Platform クラスターがノードをプロビジョニングするまでそのままになります。この場合、30 分以上の時間がかかる場合があります。ノードがプロビジョニングされると、状態はprovisioned
に変わります。NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> provisioned openshift-worker-<num>-65tjz true
NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> provisioned openshift-worker-<num>-65tjz true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョニングが完了したら、ベアメタルノードが準備状態であることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubelet を確認することもできます。
ssh openshift-worker-<num>
$ ssh openshift-worker-<num>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow [kni@openshift-worker-<num>]$ journalctl -fu kubelet
[kni@openshift-worker-<num>]$ journalctl -fu kubelet
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 トラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
7.1. インストーラーワークフローのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
インストール環境のトラブルシューティングを行う前に、ベアメタルへのインストーラーでプロビジョニングされるインストールの全体的なフローを理解することは重要です。以下の図は、環境におけるステップごとのトラブルシューティングフローを示しています。
ワークフロー 1/4 は、install-config.yaml
ファイルにエラーがある場合や Red Hat Enterprise Linux CoreOS (RHCOS) イメージにアクセスできない場合のトラブルシューティングのワークフローを説明しています。トラブルシューティングに関する提案は、Troubleshooting install-config.yaml
を参照してください。
ワークフロー 2/4 は、ブートストラップ仮想マシンの問題、クラスターノードを起動できないブートストラップ仮想マシン、および ログの検査 に関するトラブルシューティングのワークフローを説明しています。provisioning
ネットワークなしに OpenShift Container Platform クラスターをインストールする場合は、このワークフローは適用されません。
ワークフロー 3/4 は、PXE ブートしないクラスターノード のトラブルシューティングのワークフローを説明しています。RedFish 仮想メディアを使用してインストールする場合、各ノードは、インストーラーがノードをデプロイするために必要な最小ファームウェア要件を満たしている必要があります。詳細は、前提条件セクションの仮想メディアを使用したインストールのファームウェア要件を参照してください。
ワークフロー 4/4 は、アクセスできない API から 検証済みのインストール までのトラブルシューティングのワークフローを説明します。
7.2. install-config.yaml のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
設定ファイルは、OpenShift Container Platform クラスターの一部であるすべてのノードを表します。このファイルには、apiVersion
、baseDomain
、imageContentSources
、および仮想 IP アドレスのみで構成されるがこれらに制限されない必要なオプションが含まれます。OpenShift Container Platform クラスターのデプロイメントの初期段階でエラーが発生した場合、エラーは install-config.yaml
設定ファイルにある可能性があります。
手順
- YAML-tips のガイドラインを使用します。
- syntax-check を使用して YAML 構文が正しいことを確認します。
Red Hat Enterprise Linux CoreOS (RHCOS) QEMU イメージが適切に定義され、
install-config.yaml
で提供される URL 経由でアクセスできることを確認します。以下に例を示します。curl -s -o /dev/null -I -w "%{http_code}\n" http://webserver.example.com:8080/rhcos-44.81.202004250133-0-qemu.<architecture>.qcow2.gz?sha256=7d884b46ee54fe87bbc3893bf2aa99af3b2d31f2e19ab5529c60636fbd0f1ce7
$ curl -s -o /dev/null -I -w "%{http_code}\n" http://webserver.example.com:8080/rhcos-44.81.202004250133-0-qemu.<architecture>.qcow2.gz?sha256=7d884b46ee54fe87bbc3893bf2aa99af3b2d31f2e19ab5529c60636fbd0f1ce7
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力が
200
の場合、ブートストラップ仮想マシンイメージを保存する Web サーバーからの有効な応答があります。
7.3. ブートストラップ仮想マシンの問題 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform インストールプログラムは、OpenShift Container Platform クラスターノードのプロビジョニングを処理するブートストラップノードの仮想マシンを起動します。
手順
インストールプログラムをトリガー後の約 10 分から 15 分後に、
virsh
コマンドを使用してブートストラップ仮想マシンが機能していることを確認します。sudo virsh list
$ sudo virsh list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
Id Name State -------------------------------------------- 12 openshift-xf6fq-bootstrap running
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ブートストラップ仮想マシンの名前は常にクラスター名で始まり、その後にランダムな文字セットが続き、bootstrap という単語で終わります。
ブートストラップ仮想マシンが 10 - 15 分後に実行されていない場合は、実行されない理由についてトラブルシューティングします。発生する可能性のある問題には以下が含まれます。
libvirtd
がシステムで実行されていることを確認します。systemctl status libvirtd
$ systemctl status libvirtd
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ仮想マシンが動作している場合は、これにログインします。
virsh console
コマンドを使用して、ブートストラップ仮想マシンの IP アドレスを見つけます。sudo virsh console example.com
$ sudo virsh console example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要provisioning
ネットワークなしで OpenShift Container Platform クラスターをデプロイする場合、172.22.0.2
などのプライベート IP アドレスではなく、パブリック IP アドレスを使用する必要があります。IP アドレスを取得したら、
ssh
コマンドを使用してブートストラップ仮想マシンにログインします。注記直前の手順のコンソール出力では、
ens3
で提供される IPv6 IP アドレスまたはens4
で提供される IPv4 IP を使用できます。ssh core@172.22.0.2
$ ssh core@172.22.0.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ブートストラップ仮想マシンへのログインに成功しない場合は、以下いずれかのシナリオが発生した可能性があります。
-
172.22.0.0/24
ネットワークにアクセスできない。プロビジョナーとprovisioning
ネットワークブリッジ間のネットワーク接続を確認します。この問題は、provisioning
ネットワークを使用している場合に発生することがあります。 -
パブリックネットワーク経由でブートストラップ仮想マシンにアクセスできない。
baremetal
ネットワークで SSH を試行する際に、provisioner
ホストの、とくにbaremetal
ネットワークブリッジについて接続を確認します。 -
Permission denied (publickey,password,keyboard-interactive)
が出される。ブートストラップ仮想マシンへのアクセスを試行すると、Permission denied
エラーが発生する可能性があります。仮想マシンへのログインを試行するユーザーの SSH キーがinstall-config.yaml
ファイル内で設定されていることを確認します。
7.3.1. ブートストラップ仮想マシンがクラスターノードを起動できない リンクのコピーリンクがクリップボードにコピーされました!
デプロイメント時に、ブートストラップ仮想マシンがクラスターノードの起動に失敗する可能性があり、これにより、仮想マシンがノードに RHCOS イメージをプロビジョニングできなくなります。このシナリオは、以下の原因で発生する可能性があります。
-
install-config.yaml
ファイルに関連する問題。 - ベアメタルネットワークを使用してアウトオブバンド (out-of-band) ネットワークアクセスに関する問題
この問題を確認するには、ironic
に関連する 3 つのコンテナーを使用できます。
-
ironic
-
ironic-inspector
手順
ブートストラップ仮想マシンにログインします。
ssh core@172.22.0.2
$ ssh core@172.22.0.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナーログを確認するには、以下を実行します。
sudo podman logs -f <container_name>
[core@localhost ~]$ sudo podman logs -f <container_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <container_name>
をironic
またはironic-inspector
のいずれかに置き換えます。コントロールプレーンノードが PXE から起動しないという問題が発生した場合は、ironic
Pod を確認してください。ironic
Pod は、IPMI 経由でノードにログインしようとするため、クラスターノードを起動しようとする試みに関する情報を含んでいます。
考えられる理由
クラスターノードは、デプロイメントの開始時に ON
状態にある可能性があります。
解決策
IPMI でのインストールを開始する前に、OpenShift Container Platform クラスターノードの電源をオフにします。
ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off
$ ipmitool -I lanplus -U root -P <password> -H <out_of_band_ip> power off
7.3.2. ログの検査 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS イメージのダウンロードまたはアクセスに問題が発生した場合には、最初に install-config.yaml
設定ファイルで URL が正しいことを確認します。
RHCOS イメージをホストする内部 Web サーバーの例
bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0
bootstrapOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-qemu.<architecture>.qcow2.gz?sha256=9d999f55ff1d44f7ed7c106508e5deecd04dc3c06095d34d36bf1cd127837e0c
clusterOSImage: http://<ip:port>/rhcos-43.81.202001142154.0-openstack.<architecture>.qcow2.gz?sha256=a1bda656fa0892f7b936fdc6b6a6086bddaed5dafacedcd7a1e811abb78fe3b0
coreos-downloader
コンテナーは、Web サーバーまたは外部の quay.io レジストリー (install-config.yaml
設定ファイルで指定されている方) からリソースをダウンロードします。coreos-downloader
コンテナーが稼働していることを確認し、必要に応じて、そのログを調べます。
手順
ブートストラップ仮想マシンにログインします。
ssh core@172.22.0.2
$ ssh core@172.22.0.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ブートストラップ VM 内の
coreos-downloader
コンテナーのステータスを確認します。sudo podman logs -f coreos-downloader
[core@localhost ~]$ sudo podman logs -f coreos-downloader
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ仮想マシンがイメージへの URL にアクセスできない場合、
curl
コマンドを使用して、仮想マシンがイメージにアクセスできることを確認します。すべてのコンテナーがデプロイメントフェーズで起動されているかどうかを示す
bootkube
ログを検査するには、以下を実行します。journalctl -xe
[core@localhost ~]$ journalctl -xe
Copy to Clipboard Copied! Toggle word wrap Toggle overflow journalctl -b -f -u bootkube.service
[core@localhost ~]$ journalctl -b -f -u bootkube.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dnsmasq
、mariadb
、httpd
、およびironic
を含むすべての Pod が実行中であることを確認します。sudo podman ps
[core@localhost ~]$ sudo podman ps
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod に問題がある場合には、問題のあるコンテナーのログを確認します。
ironic
サービスのログを確認するには、次のコマンドを実行します。sudo podman logs ironic
[core@localhost ~]$ sudo podman logs ironic
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. クラスターノードが PXE ブートしない リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターノードが PXE ブートしない場合、PXE ブートしないクラスターノードで以下のチェックを実行します。この手順は、provisioning
ネットワークなしで OpenShift Container Platform クラスターをインストールする場合には適用されません。
手順
-
provisioning
ネットワークへのネットワークの接続を確認します。 -
PXE が
provisioning
ネットワークの NIC で有効にされており、PXE がその他のすべての NIC について無効にされていることを確認します。 install-config.yaml
設定ファイルに、provisioning
ネットワークに接続されている NIC のrootDeviceHints
パラメーターとブート MAC アドレスが含まれていることを確認します。以下に例を示します。コントロールプレーンノードの設定
bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノード設定
bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
bootMACAddress: 24:6E:96:1B:96:90 # MAC of bootable provisioning NIC
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5. BMC を使用して、新しいベアメタルホストを検出できない リンクのコピーリンクがクリップボードにコピーされました!
場合によっては、リモート仮想メディア共有をマウントできないため、インストールプログラムが新しいベアメタルホストを検出できず、エラーが発生することがあります。
以下に例を示します。
この状況で、認証局が不明な仮想メディアを使用している場合は、不明な認証局を信頼するように、ベースボード管理コントローラー (BMC) のリモートファイル共有設定を行って、このエラーを回避できます。
この解決策は、Dell iDRAC 9 およびファームウェアバージョン 5.10.50 を搭載した OpenShift Container Platform 4.11 でテストされました。
7.6. API にアクセスできない リンクのコピーリンクがクリップボードにコピーされました!
クラスターが実行されており、クライアントが API にアクセスできない場合、ドメイン名の解決の問題により API へのアクセスが妨げられる可能性があります。
手順
Hostname Resolution: クラスターノードに
localhost.localdomain
だけでなく、完全修飾ドメイン名があることを確認します。以下に例を示します。hostname
$ hostname
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホスト名が設定されていない場合、正しいホスト名を設定します。以下に例を示します。
hostnamectl set-hostname <hostname>
$ hostnamectl set-hostname <hostname>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 正しくない名前の解決: 各ノードに
dig
およびnslookup
を使用して DNS サーバーに正しい名前の解決があることを確認します。以下に例を示します。dig api.<cluster_name>.example.com
$ dig api.<cluster_name>.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前述の例の出力は、
api.<cluster_name>.example.com
VIP の適切な IP アドレスが10.19.13.86
であることを示しています。この IP アドレスはbaremetal
上にある必要があります。
7.7. クラスターに参加できないワーカーノードのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
installer-provisioned クラスターは、api-int.<cluster_name>.<base_domain>
URL の DNS エントリーが含まれる DNS サーバーと共にデプロイされます。クラスター内のノードが外部またはアップストリーム DNS サーバーを使用して api-int.<cluster_name>.<base_domain>
URL を解決し、そのようなエントリーがない場合、ワーカーノードはクラスターに参加できない可能性があります。クラスター内のすべてのノードがドメイン名を解決できることを確認します。
手順
DNS A/AAAA または CNAME レコードを追加して、API ロードバランサーを内部的に識別します。たとえば、dnsmasq を使用する場合は、
dnsmasq.conf
設定ファイルを変更します。sudo nano /etc/dnsmasq.conf
$ sudo nano /etc/dnsmasq.conf
Copy to Clipboard Copied! Toggle word wrap Toggle overflow address=/api-int.<cluster_name>.<base_domain>/<IP_address> address=/api-int.mycluster.example.com/192.168.1.10 address=/api-int.mycluster.example.com/2001:0db8:85a3:0000:0000:8a2e:0370:7334
address=/api-int.<cluster_name>.<base_domain>/<IP_address> address=/api-int.mycluster.example.com/192.168.1.10 address=/api-int.mycluster.example.com/2001:0db8:85a3:0000:0000:8a2e:0370:7334
Copy to Clipboard Copied! Toggle word wrap Toggle overflow DNS PTR レコードを追加して、API ロードバランサーを内部的に識別します。たとえば、dnsmasq を使用する場合は、
dnsmasq.conf
設定ファイルを変更します。sudo nano /etc/dnsmasq.conf
$ sudo nano /etc/dnsmasq.conf
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ptr-record=<IP_address>.in-addr.arpa,api-int.<cluster_name>.<base_domain> ptr-record=10.1.168.192.in-addr.arpa,api-int.mycluster.example.com
ptr-record=<IP_address>.in-addr.arpa,api-int.<cluster_name>.<base_domain> ptr-record=10.1.168.192.in-addr.arpa,api-int.mycluster.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow DNS サーバーを再起動します。たとえば、dnsmasq を使用する場合は、以下のコマンドを実行します。
sudo systemctl restart dnsmasq
$ sudo systemctl restart dnsmasq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。
7.8. 以前のインストールのクリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
以前のデプロイメントに失敗した場合、OpenShift Container Platform のデプロイを再試行する前に、失敗した試行からアーティファクトを削除します。
手順
OpenShift Container Platform クラスターをインストールする前に、すべてのベアメタルノードの電源をオフにします。
ipmitool -I lanplus -U <user> -P <password> -H <management_server_ip> power off
$ ipmitool -I lanplus -U <user> -P <password> -H <management_server_ip> power off
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以前に試行したデプロイメントにより古いブートストラップリソースが残っている場合は、これらをすべて削除します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下を
clusterconfigs
ディレクトリーから削除し、Terraform が失敗することを防ぎます。rm -rf ~/clusterconfigs/auth ~/clusterconfigs/terraform* ~/clusterconfigs/tls ~/clusterconfigs/metadata.json
$ rm -rf ~/clusterconfigs/auth ~/clusterconfigs/terraform* ~/clusterconfigs/tls ~/clusterconfigs/metadata.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.9. レジストリーの作成に関する問題 リンクのコピーリンクがクリップボードにコピーされました!
非接続レジストリーの作成時に、レジストリーのミラーリングを試行する際に "User Not Authorized" エラーが発生する場合があります。このエラーは、新規の認証を既存の pull-secret.txt
ファイルに追加できない場合に生じる可能性があります。
手順
認証が正常に行われていることを確認します。
/usr/local/bin/oc adm release mirror \ -a pull-secret-update.json
$ /usr/local/bin/oc adm release mirror \ -a pull-secret-update.json --from=$UPSTREAM_REPO \ --to-release-image=$LOCAL_REG/$LOCAL_REPO:${VERSION} \ --to=$LOCAL_REG/$LOCAL_REPO
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記インストールイメージのミラーリングに使用される変数の出力例:
UPSTREAM_REPO=${RELEASE_IMAGE} LOCAL_REG=<registry_FQDN>:<registry_port> LOCAL_REPO='ocp4/openshift4'
UPSTREAM_REPO=${RELEASE_IMAGE} LOCAL_REG=<registry_FQDN>:<registry_port> LOCAL_REPO='ocp4/openshift4'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RELEASE_IMAGE
およびVERSION
の値は、OpenShift インストールの環境のセットアップセクションの OpenShift Installer の取得 の手順で設定されています。レジストリーのミラーリング後に、非接続環境でこれにアクセスできることを確認します。
curl -k -u <user>:<password> https://registry.example.com:<registry_port>/v2/_catalog
$ curl -k -u <user>:<password> https://registry.example.com:<registry_port>/v2/_catalog {"repositories":["<Repo_Name>"]}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10. その他の問題点 リンクのコピーリンクがクリップボードにコピーされました!
7.10.1. runtime network not ready エラーへの対応 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのデプロイメント後に、以下のエラーが発生する可能性があります。
`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`
`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`
Cluster Network Operator は、インストーラーによって作成される特別なオブジェクトに対応してネットワークコンポーネントをデプロイします。これは、コントロールプレーン (マスター) ノードが起動した後、ブートストラップコントロールプレーンが停止する前にインストールプロセスの初期段階で実行されます。これは、コントロールプレーン (マスター) ノードの起動の長い遅延や apiserver
通信の問題などの、より判別しづらいインストーラーの問題を示すことができます。
手順
openshift-network-operator
namespace の Pod を検査します。oc get all -n openshift-network-operator
$ oc get all -n openshift-network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME READY STATUS RESTARTS AGE pod/network-operator-69dfd7b577-bg89v 0/1 ContainerCreating 0 149m
NAME READY STATUS RESTARTS AGE pod/network-operator-69dfd7b577-bg89v 0/1 ContainerCreating 0 149m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow provisioner
ノードで、ネットワーク設定が存在することを判別します。kubectl get network.config.openshift.io cluster -oyaml
$ kubectl get network.config.openshift.io cluster -oyaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 存在しない場合には、インストーラーはこれを作成していません。インストーラーがこれを作成しなかった理由を判別するには、以下のコマンドを実行します。
openshift-install create manifests
$ openshift-install create manifests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow network-operator
が実行されていることを確認します。kubectl -n openshift-network-operator get pods
$ kubectl -n openshift-network-operator get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ログを取得します。
kubectl -n openshift-network-operator logs -l "name=network-operator"
$ kubectl -n openshift-network-operator logs -l "name=network-operator"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 3 つ以上のコントロールプレーン (マスター) ノードを持つ高可用性クラスターの場合、Operator はリーダーの選択を実行し、他の Operator はすべてスリープ状態になります。詳細は、Troubleshooting を参照してください。
7.10.2. "No disk found with matching rootDeviceHints" エラーメッセージへの対処 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをデプロイした後、次のエラーメッセージが表示される場合があります。
No disk found with matching rootDeviceHints
No disk found with matching rootDeviceHints
No disk found with matching rootDeviceHints
エラーメッセージに対処するための一時的な回避策は、rootDeviceHints
を minSizeGigabytes: 300
に変更することです。
rootDeviceHints
設定を変更した後、CoreOS を起動し、次のコマンドを使用してディスク情報を確認します。
udevadm info /dev/sda
$ udevadm info /dev/sda
DL360 Gen 10 サーバーを使用している場合は、/dev/sda
デバイス名が割り当てられている SD カードスロットがあることに注意してください。サーバーに SD カードが存在しない場合は、競合が発生する可能性があります。サーバーの BIOS 設定で SD カードスロットが無効になっていることを確認してください。
minSizeGigabytes
の回避策が要件を満たしていない場合は、rootDeviceHints
を /dev/sda
に戻さないといけない場合があります。この変更により、Ironic イメージが正常に起動できるようになります。
この問題を解決する別の方法は、ディスクのシリアル ID を使用することです。ただし、シリアル ID を見つけるのは困難な場合があり、設定ファイルが読みにくくなる可能性があることに注意してください。このパスを選択する場合は、前に説明したコマンドを使用してシリアル ID を収集し、それを設定に組み込んでください。
7.10.3. クラスターノードが DHCP 経由で正しい IPv6 アドレスを取得しない リンクのコピーリンクがクリップボードにコピーされました!
クラスターノードが DHCP 経由で正しい IPv6 アドレスを取得しない場合は、以下の点を確認してください。
- 予約された IPv6 アドレスが DHCP 範囲外にあることを確認します。
DHCP サーバーの IP アドレス予約では、予約で正しい DUID (DHCP 固有識別子) が指定されていることを確認します。以下に例を示します。
This is a dnsmasq dhcp reservation, 'id:00:03:00:01' is the client id and '18:db:f2:8c:d5:9f' is the MAC Address for the NIC
# This is a dnsmasq dhcp reservation, 'id:00:03:00:01' is the client id and '18:db:f2:8c:d5:9f' is the MAC Address for the NIC id:00:03:00:01:18:db:f2:8c:d5:9f,openshift-master-1,[2620:52:0:1302::6]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Route Announcement が機能していることを確認します。
- DHCP サーバーが、IP アドレス範囲を提供する必要なインターフェイスでリッスンしていることを確認します。
7.10.4. クラスターノードが DHCP 経由で正しいホスト名を取得しない リンクのコピーリンクがクリップボードにコピーされました!
IPv6 のデプロイメント時に、クラスターノードは DHCP でホスト名を取得する必要があります。NetworkManager
はホスト名をすぐに割り当てない場合があります。コントロールプレーン (マスター) ノードは、以下のようなエラーを報告する可能性があります。
Failed Units: 2 NetworkManager-wait-online.service nodeip-configuration.service
Failed Units: 2
NetworkManager-wait-online.service
nodeip-configuration.service
このエラーは、最初に DHCP サーバーからホスト名を受信せずにクラスターノードが起動する可能性があることを示しています。これにより、kubelet
が localhost.localdomain
ホスト名で起動します。エラーに対処するには、ノードによるホスト名の更新を強制します。
手順
hostname
を取得します。hostname
[core@master-X ~]$ hostname
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホスト名が
localhost
の場合は、以下の手順に進みます。注記X
はコントロールプレーンノード番号です。クラスターノードによる DHCP リースの更新を強制します。
sudo nmcli con up "<bare_metal_nic>"
[core@master-X ~]$ sudo nmcli con up "<bare_metal_nic>"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <bare_metal_nic>
を、baremetal
ネットワークに対応する有線接続に置き換えます。hostname
を再度確認します。hostname
[core@master-X ~]$ hostname
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホスト名が
localhost.localdomain
の場合は、NetworkManager
を再起動します。sudo systemctl restart NetworkManager
[core@master-X ~]$ sudo systemctl restart NetworkManager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ホスト名がまだ
localhost.localdomain
の場合は、数分待機してから再度確認します。ホスト名がlocalhost.localdomain
のままの場合は、直前の手順を繰り返します。 nodeip-configuration
サービスを再起動します。sudo systemctl restart nodeip-configuration.service
[core@master-X ~]$ sudo systemctl restart nodeip-configuration.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このサービスは、正しいホスト名の参照で
kubelet
サービスを再設定します。kubelet が直前の手順で変更された後にユニットファイル定義を再読み込みします。
sudo systemctl daemon-reload
[core@master-X ~]$ sudo systemctl daemon-reload
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubelet
サービスを再起動します。sudo systemctl restart kubelet.service
[core@master-X ~]$ sudo systemctl restart kubelet.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubelet
が正しいホスト名で起動されていることを確認します。sudo journalctl -fu kubelet.service
[core@master-X ~]$ sudo journalctl -fu kubelet.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
再起動時など、クラスターの稼働後にクラスターノードが正しいホスト名を取得しない場合、クラスターの csr
は保留中になります。csr
は承認 しません。承認すると、他の問題が生じる可能性があります。
csr
の対応
クラスターで CSR を取得します。
oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 保留中の
csr
にSubject Name: localhost.localdomain
が含まれているかどうかを確認します。oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text
$ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Subject Name: localhost.localdomain
が含まれるcsr
を削除します。oc delete csr <wrong_csr>
$ oc delete csr <wrong_csr>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10.5. ルートがエンドポイントに到達しない リンクのコピーリンクがクリップボードにコピーされました!
インストールプロセス時に、VRRP (Virtual Router Redundancy Protocol) の競合が発生する可能性があります。この競合は、特定のクラスター名を使用してクラスターデプロイメントの一部であった、以前に使用された OpenShift Container Platform ノードが依然として実行中であるものの、同じクラスター名を使用した現在の OpenShift Container Platform クラスターデプロイメントの一部ではない場合に発生する可能性があります。たとえば、クラスターはクラスター名 openshift
を使用してデプロイされ、3 つのコントロールプレーン (マスター) ノードと 3 つのワーカーノードをデプロイします。後に、別のインストールで同じクラスター名 openshift
が使用されますが、この再デプロイメントは 3 つのコントロールプレーン (マスター) ノードのみをインストールし、以前のデプロイメントの 3 つのワーカーノードを ON
状態のままにします。これにより、VRID (Virtual Router Identifier) の競合が発生し、VRRP が競合する可能性があります。
ルートを取得します。
oc get route oauth-openshift
$ oc get route oauth-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスエンドポイントを確認します。
oc get svc oauth-openshift
$ oc get svc oauth-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE oauth-openshift ClusterIP 172.30.19.162 <none> 443/TCP 59m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE oauth-openshift ClusterIP 172.30.19.162 <none> 443/TCP 59m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーン (マスター) ノードからサービスへのアクセスを試行します。
curl -k https://172.30.19.162
[core@master0 ~]$ curl -k https://172.30.19.162
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow provisioner
ノードからのauthentication-operator
エラーを特定します。oc logs deployment/authentication-operator -n openshift-authentication-operator
$ oc logs deployment/authentication-operator -n openshift-authentication-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-authentication-operator", Name:"authentication-operator", UID:"225c5bd5-b368-439b-9155-5fd3c0459d98", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'OperatorStatusChanged' Status for clusteroperator/authentication changed: Degraded message changed from "IngressStateEndpointsDegraded: All 2 endpoints for oauth-server are reporting"
Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-authentication-operator", Name:"authentication-operator", UID:"225c5bd5-b368-439b-9155-5fd3c0459d98", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'OperatorStatusChanged' Status for clusteroperator/authentication changed: Degraded message changed from "IngressStateEndpointsDegraded: All 2 endpoints for oauth-server are reporting"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
解決策
- すべてのデプロイメントのクラスター名が一意であり、競合が発生しないことを確認します。
- 同じクラスター名を使用するクラスターデプロイメントの一部ではない不正なノードをすべてオフにします。そうしないと、OpenShift Container Platform クラスターの認証 Pod が正常に起動されなくなる可能性があります。
7.10.6. 初回起動時の Ignition の失敗 リンクのコピーリンクがクリップボードにコピーされました!
初回起動時に、Ignition 設定が失敗する可能性があります。
手順
Ignition 設定が失敗したノードに接続します。
Failed Units: 1 machine-config-daemon-firstboot.service
Failed Units: 1 machine-config-daemon-firstboot.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow machine-config-daemon-firstboot
サービスを再起動します。sudo systemctl restart machine-config-daemon-firstboot.service
[core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10.7. NTP が同期しない リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのデプロイメントは、クラスターノード間の NTP の同期クロックによって異なります。同期クロックがない場合、時間の差が 2 秒を超えるとクロックのドリフトによりデプロイメントが失敗する可能性があります。
手順
クラスターノードの
AGE
の差異の有無を確認します。以下に例を示します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME STATUS ROLES AGE VERSION master-0.cloud.example.com Ready master 145m v1.25.0 master-1.cloud.example.com Ready master 135m v1.25.0 master-2.cloud.example.com Ready master 145m v1.25.0 worker-2.cloud.example.com Ready worker 100m v1.25.0
NAME STATUS ROLES AGE VERSION master-0.cloud.example.com Ready master 145m v1.25.0 master-1.cloud.example.com Ready master 135m v1.25.0 master-2.cloud.example.com Ready master 145m v1.25.0 worker-2.cloud.example.com Ready worker 100m v1.25.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クロックのドリフトによる一貫性のないタイミングの遅延について確認します。以下に例を示します。
oc get bmh -n openshift-machine-api
$ oc get bmh -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow master-1 error registering master-1 ipmi://<out_of_band_ip>
master-1 error registering master-1 ipmi://<out_of_band_ip>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo timedatectl
$ sudo timedatectl
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
既存のクラスターでのクロックドリフトへの対応
ノードに配信される
chrony.conf
ファイルの内容を含む Butane 設定ファイルを作成します。以下の例で、99-master-chrony.bu
を作成して、ファイルをコントロールプレーンノードに追加します。ワーカーノードのファイルを変更するか、ワーカーロールに対してこの手順を繰り返すことができます。注記Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<NTP_server>
を NTP サーバーの IP アドレスに置き換えます。
Butane を使用して、ノードに配信される設定を含む
MachineConfig
オブジェクトファイル (99-master-chrony.yaml
) を生成します。butane 99-master-chrony.bu -o 99-master-chrony.yaml
$ butane 99-master-chrony.bu -o 99-master-chrony.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfig
オブジェクトファイルを適用します。oc apply -f 99-master-chrony.yaml
$ oc apply -f 99-master-chrony.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow System clock synchronized
の値が yes であることを確認します。sudo timedatectl
$ sudo timedatectl
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントの前にクロック同期を設定するには、マニフェストファイルを生成し、このファイルを
openshift
ディレクトリーに追加します。以下に例を示します。cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml
$ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの作成を継続します。
7.11. インストールの確認 リンクのコピーリンクがクリップボードにコピーされました!
インストール後に、インストーラーがノードおよび Pod を正常にデプロイしていることを確認します。
手順
OpenShift Container Platform クラスターノードが適切にインストールされると、以下の
Ready
状態がSTATUS
列に表示されます。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME STATUS ROLES AGE VERSION master-0.example.com Ready master,worker 4h v1.25.0 master-1.example.com Ready master,worker 4h v1.25.0 master-2.example.com Ready master,worker 4h v1.25.0
NAME STATUS ROLES AGE VERSION master-0.example.com Ready master,worker 4h v1.25.0 master-1.example.com Ready master,worker 4h v1.25.0 master-2.example.com Ready master,worker 4h v1.25.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストーラーによりすべての Pod が正常にデプロイされたことを確認します。以下のコマンドは、実行中の Pod、または出力の一部として完了した Pod を削除します。
oc get pods --all-namespaces | grep -iv running | grep -iv complete
$ oc get pods --all-namespaces | grep -iv running | grep -iv complete
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.