ベアメタルへのインストール
ベアメタルへの OpenShift Container Platform のインストール
概要
第1章 ベアメタルクラスターのインストールの準備 リンクのコピーリンクがクリップボードにコピーされました!
1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
1.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 でサポートされていることを確認してください。
1.3. SR-IOV デバイスの NIC パーティショニング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、デュアルポートのネットワークインターフェイスカード (NIC) を搭載したサーバーにデプロイできます。1 つの高速デュアルポート NIC を複数の仮想機能 (VF) に分割し、SR-IOV を有効にすることができます。
この機能は、Link Aggregation Control Protocol (LACP) による高可用性のための結合の使用をサポートします。
物理 NIC で宣言できる LACP は 1 つだけです。
OpenShift Container Platform クラスターは、以下の方法を使用して、2 つの物理機能 (PF) に 2 つの VF を持つ結合インターフェイスにデプロイできます。
Agent-based Installer
注記nmstate
の最低限必要なバージョンは次のとおりです。-
RHEL 8 バージョンの
1.4.2-4
-
RHEL 9 バージョンの
2.2.7
-
RHEL 8 バージョンの
- installer-provisioned infrastructure によるインストール
- user-provisioned infrastructure によるインストール
1.4. ベアメタルに OpenShift Container Platform をインストールする方法の選択 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform インストールプログラムは、クラスターをデプロイするための 4 つの方法を提供します。
- インタラクティブ: Web ベースの Assisted Installer を使用してクラスターをデプロイできます。これは、ネットワークがインターネットに接続されているクラスターに推奨されるアプローチです。Assisted Installer は、OpenShift Container Platform をインストールする最も簡単な方法であり、スマートなデフォルトを提供し、クラスターをインストールする前に事前検証を実行します。また、自動化および高度な設定シナリオのための RESTful API も提供します。
- ローカルエージェントベース: エアギャップネットワークまたはネットワークが制限された環境用の Agent-based Installer を使用して、クラスターをローカルにデプロイできます。この方法では、Assisted Installer の多くの利点を得られますが、最初に Agent-based Installer をダウンロードして設定する必要があります。設定はコマンドラインインターフェイスで行います。このアプローチは、エアギャップまたは制限されたネットワークに最適です。
- 自動化: installer-provisioned infrastructure とそれが維持するクラスターにクラスターをデプロイできます。インストーラーは、各クラスターホストのベースボード管理コントローラー (BMC) をプロビジョニングに使用します。接続されたネットワーク、エアギャップされたネットワーク、または制限されたネットワークの両方でクラスターをデプロイできます。
- 完全な制御: お客様が準備および保守するインフラストラクチャー にクラスターをデプロイメントできます。これにより、最大限のカスタマイズ性が提供されます。接続されたネットワーク、エアギャップされたネットワーク、または制限されたネットワークの両方でクラスターをデプロイできます。
クラスターには次の特徴があります。
- 単一障害点のない高可用性インフラストラクチャーがデフォルトで利用可能である。
- 管理者は適用される更新内容および更新タイミングを制御できる。
installer-provisioned installation および user-provisioned installation のプロセスの詳細は、インストールプロセス を参照してください。
1.4.1. installer-provisioned infrastructure へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の方法を使用して、OpenShift Container Platform インストールプログラムでプロビジョニングされるベアメタルインフラストラクチャーに、クラスターをインストールできます。
- インストーラーによってプロビジョニングされるクラスターのベアメタルへのインストール
- インストーラーによるプロビジョニングを使用して、OpenShift Container Platform をベアメタルにインストールできます。
1.4.2. user-provisioned infrastructure へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の方法のいずれかを使用して、独自にプロビジョニングするベアメタルインフラストラクチャーに、クラスターをインストールできます。
- ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール
- OpenShift Container Platform はユーザーがプロビジョニングするインフラストラクチャーにインストールできます。user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
- ネットワークをカスタマイズしたユーザープロビジョニング型ベアメタルクラスターのインストール
- ネットワークをカスタマイズして、user-provisioned infrastructure にベアメタルクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。ネットワークのカスタマイズのほとんどは、インストールステージで適用する必要があります。
- ネットワークが制限された環境でのユーザープロビジョニング型ベアメタルクラスターのインストール
- ミラーレジストリーを使用して、制限されたネットワークまたは非接続のネットワークに、ユーザーがプロビジョニングするベアメタルクラスターをインストールできます。また、このインストール方法を使用して、クラスターが外部コンテンツに対する組織の制御の条件を満たすコンテナーイメージのみを使用するようにすることもできます。
第2章 user-provisioned infrastructure リンクのコピーリンクがクリップボードにコピーされました!
2.1. ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、独自にプロビジョニングするベアメタルインフラストラクチャーにクラスターをインストールできます。
以下の手順に従って仮想化環境またはクラウド環境にクラスターをデプロイすることができますが、ベアメタルプラットフォーム以外の場合は追加の考慮事項に注意してください。このような環境に OpenShift Container Platform クラスターをインストールする前に、guidelines for deploying OpenShift Container Platform on non-tested platforms の情報を確認してください。
2.1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
ファイアウォールを使用する場合は、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
2.1.2. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、クラスターをインストールするためにインターネットアクセスが必要です。
次のアクションを実行するには、インターネットにアクセスできる必要があります。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターがインターネットにアクセスでき、Telemetry を無効にしていない場合、そのサービスによってクラスターのサブスクリプションが自動的に有効化されます。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
2.1.3. user-provisioned infrastructure を使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
2.1.3.1. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
ホスト | 説明 |
---|---|
1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
例外として、ゼロ (0) コンピュートマシンを 3 つのコントロールプレーンマシンのみで構成されるベアメタルクラスターで実行できます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。1 つのコンピュートマシンの実行はサポートされていません。
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 以降から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 9.2 をベースとしており、そのハードウェア認定および要件がすべて継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
2.1.3.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | CPU [1] | RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
---|---|---|---|---|---|
ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 つの CPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、(コアごとのスレッド x コア数) x ソケット数 = CPU という数式を使用して対応する比率を計算します。
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピュートマシンの使用は非推奨となり、OpenShift Container Platform 4.10 以降で削除されています。
OpenShift Container Platform バージョン 4.19 の場合、RHCOS は RHEL バージョン 9.6 に基づいています。これは、マイクロアーキテクチャー要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、アーキテクチャー (RHEL ドキュメント) を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
2.1.3.3. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求されるサービング証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
2.1.3.4. vSphere 上のベアメタルクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のすべての仮想マシンで、disk.EnableUUID
パラメーターを必ず有効にしてください。
2.1.3.5. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルを取得する必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
- クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
- DHCP サービスが user-provisioned infrastructure で利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
2.1.3.5.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
2.1.3.5.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
インターネットに接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Red Hat にテレメトリーデータを提供するために、すべてのノードがインターネットにアクセスできる必要があります。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。ポート | |
| Kubernetes が予約するデフォルトポート | |
| このポートは、マシン設定サーバーからのトラフィックを処理し、トラフィックをコントロールプレーンマシンに送信します。 | |
UDP |
| VXLAN |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
|
UDP ポート | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
2.1.3.5.3. user-provisioned infrastructure の NTP 設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
2.1.3.6. user-provisioned DNS 要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード
- ブートストラップ、コントロールプレーンおよびコンピュートマシン
また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。
DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。
各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。詳細は、user-provisioned infrastructure に関する DHCP の推奨事項 のセクションを参照してください。
以下の DNS レコードは、user-provisioned OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、install-config.yaml
ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
ルート |
| アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
ブートストラップマシン |
| ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コントロールプレーンマシン |
| コントロールプレーンノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コンピュートマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。
dig
コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
2.1.3.6.1. user-provisioned クラスターの DNS 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4
で、ベースドメインは example.com
です。
user-provisioned クラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、user-provisioned クラスターの名前解決の A レコードの例を示しています。
例2.1 DNS ゾーンデータベースのサンプル
- 1
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
- 2
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
- 3
- ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
- 4
- ブートストラップマシンの名前解決を提供します。
- 5 6 7
- コントロールプレーンマシンの名前解決を提供します。
- 8 9
- コンピュートマシンの名前解決を提供します。
user-provisioned クラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、user-provisioned クラスターの逆引き名前解決の PTR レコードの例を示しています。
例2.2 逆引きレコードの DNS ゾーンデータベースの例
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
2.1.3.7. user-provisioned infrastructure の負荷分散要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーション Ingress ロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表2.7 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとのプロービングで、2 回連続成功すると正常、3 回連続失敗すると異常と判断する設定は、十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。
以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表2.8 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
2.1.3.7.1. user-provisioned クラスターのロードバランサーの設定例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned クラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg
設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing
に設定されている場合は、setsebool -P haproxy_connect_any=1
を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
例2.3 API およびアプリケーション Ingress ロードバランサーの設定例
- 1
- ポート
6443
は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 2 4
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 3
- ポート
22623
はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 5
- ポート
443
は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 6
- ポート
80
は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe
を実行して、ポート 6443
、22623
、443
、および 80
で haproxy
プロセスがリッスンしていることを確認することができます。
2.1.4. カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
configure-ovs.sh
シェルスクリプトを使用してベアメタルプラットフォームで br-ex
ブリッジを設定する代わりに、NMState 設定ファイルを含む MachineConfig
オブジェクトを作成できます。ホスト nmstate-configuration.service
および nmstate.service
により、クラスター内で実行される各ノードに NMState 設定ファイルが適用されます。
カスタマイズされた br-ex
ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。
-
Open vSwitch (OVS) または OVN-Kubernetes
br-ex
ブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.sh
シェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。 - ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
-
configure-ovs.sh
シェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。
単一のネットワークインターフェイスコントローラー (NIC) とデフォルトのネットワーク設定を備えた環境が必要な場合は、configure-ovs.sh
シェルスクリプトを使用します。
Red Hat Enterprise Linux CoreOS (RHCOS) をインストールしてシステムを再起動すると、Machine Config Operator がクラスター内の各ノードに Ignition 設定ファイルを注入し、各ノードが br-ex
ブリッジネットワーク設定を受け取るようになります。設定の競合を防ぐために、configure-ovs.sh
シェルスクリプトは、br-ex
ブリッジを設定しない信号を受け取ります。
次のインターフェイス名は予約されており、NMstate 設定では使用できません。
-
br-ext
-
br-int
-
br-local
-
br-nexthop
-
br0
-
ext-vxlan
-
ext
-
genev_sys_*
-
int
-
k8s-*
-
ovn-k8s-*
-
patch-br-*
-
tun0
-
vxlan_sys_*
前提条件
-
オプション: NMState 設定を検証できるように、
nmstate
API をインストールしました。
手順
カスタマイズされた
br-ex
ブリッジネットワークの base64 情報をデコードした NMState 設定ファイルを作成します。カスタマイズされた
br-ex
ブリッジネットワークの NMState 設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat
コマンドを使用して、NMState 設定の内容を base64 でエンコードします。cat <nmstate_configuration>.yaml | base64
$ cat <nmstate_configuration>.yaml | base64
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nmstate_configuration>
を NMState リソース YAML ファイルの名前に置き換えます。
MachineConfig
マニフェストファイルを作成し、次の例に類似したカスタマイズされたbr-ex
ブリッジネットワーク設定を定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のすべてのノードに適用する単一のグローバル設定が
/etc/nmstate/openshift/cluster.yml
設定ファイルで指定されている場合は、各ノードの短いホスト名パス (例:/etc/nmstate/openshift/<node_hostname>.yml
) を指定する必要はありません。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
-
コンピュートノードをスケーリングして、クラスター内に存在する各コンピュートノードに、カスタマイズされた
br-ex
ブリッジを含むマニフェストオブジェクトを適用します。詳細は、関連情報 セクションの「クラスターの拡張」を参照してください。
2.1.4.1. 各マシンセットをコンピュートノードにスケーリング リンクのコピーリンクがクリップボードにコピーされました!
カスタマイズされた br-ex
ブリッジ設定を OpenShift Container Platform クラスター内のすべてのコンピュートノードに適用するには、MachineConfig
カスタムリソース (CR) を編集し、そのロールを変更する必要があります。さらに、ホスト名、認証情報など、ベアメタルマシンの情報を定義する BareMetalHost
CR を作成する必要があります。
これらのリソースを設定した後、マシンセットをスケーリングして、マシンセットが各コンピュートノードにリソース設定を適用し、ノードを再起動できるようにする必要があります。
前提条件
-
カスタマイズされた
br-ex
ブリッジ設定を含むMachineConfig
マニフェストオブジェクトを作成しました。
手順
次のコマンドを入力して
MachineConfig
CR を編集します。oc edit mc <machineconfig_custom_resource_name>
$ oc edit mc <machineconfig_custom_resource_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 各コンピュートノード設定を CR に追加して、CR がクラスター内の定義済みコンピュートノードごとにロールを管理できるようにします。
-
最小限の静的 IP 設定を持つ
extraworker-secret
という名前のSecret
オブジェクトを作成します。 次のコマンドを入力して、クラスター内の各ノードに
extraworker-secret
シークレットを適用します。このステップでは、各コンピュートノードに Ignition 設定ファイルへのアクセスを提供します。oc apply -f ./extraworker-secret.yaml
$ oc apply -f ./extraworker-secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BareMetalHost
リソースを作成し、preprovisioningNetworkDataName
パラメーターでネットワークシークレットを指定します。ネットワークシークレットが添付された
BareMetalHost
リソースの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの
openshift-machine-api
namespace 内でBareMetalHost
オブジェクトを管理するために、次のコマンドを入力して namespace に変更します。oc project openshift-machine-api
$ oc project openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシンセットを取得します。
oc get machinesets
$ oc get machinesets
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各マシンセットをスケールします。このコマンドはマシンセットごとに実行する必要があります。
oc scale machineset <machineset_name> --replicas=<n>
$ oc scale machineset <machineset_name> --replicas=<n>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<machineset_name>
はマシンセットの名前です。<n>
はコンピュートノードの数です。
2.1.5. クラスターで OVS balance-slb モードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上の物理インターフェイスがネットワークトラフィックを共有できるように、Open vSwitch (OVS) の balance-slb
モードを有効にできます。balance-slb
モードのインターフェイスは、ネットワークスイッチとのソースロードバランシングを必要とせずに、仮想化ワークロードを実行するクラスターにソース負荷分散 (SLB) 機能を提供できます。
現在、ソースロードバランシングはボンディングインターフェイスで実行されます。このインターフェイスは br-phy
などの補助ブリッジに接続します。ソースロードバランシングは、Media Access Control (MAC) アドレスと仮想ローカルエリアネットワーク (VLAN) の組み合わせが複数存在する場合にのみ、負荷分散を行います。OVN-Kubernetes Pod のトラフィックはすべて同じ MAC アドレスと VLAN を使用するため、このトラフィックを多数の物理インターフェイス間で負荷分散することはできないことに注意してください。
次の図は、単純なクラスターインフラストラクチャーレイアウトでの balance-slb
モードを示しています。仮想マシン (VM) は、特定の localnet NetworkAttachmentDefinition
(NAD) カスタムリソース定義 (CRD)、NAD 0
または NAD 1
に接続します。各 NAD は、仮想マシンに基盤となる物理ネットワークへのアクセスを提供し、タグ付きまたはタグなしの VLAN トラフィックをサポートしています。br-ex
OVS ブリッジは仮想マシンからのトラフィックを受信し、そのトラフィックを次の OVS ブリッジである br-phy
に渡します。br-phy
ブリッジは SLB ボンディングのコントローラーとして機能します。SLB ボンディングは、eno0
や eno1
などの物理インターフェイスリンクを介して、異なる仮想マシンポートからのトラフィックを分散します。さらに、どちらの物理インターフェイスからの Ingress トラフィックも、OVS ブリッジのセットを通過して仮想マシンに到達できます。
図2.1 2 つの NAD を持つローカルネット上で動作する OVS balance-slb
モード
OVS ボンディングを使用して、balance-slb
モードインターフェイスをプライマリーまたはセカンダリーネットワークタイプに統合できます。OVS ボンディングでは、次の点に注意してください。
- OVN-Kubernetes CNI プラグインをサポートし、プラグインと簡単に統合できます。
-
ネイティブで
balance-slb
モードをサポートします。
前提条件
-
プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを
MachineConfig
ファイルで定義した。 -
マニフェストオブジェクトを作成し、カスタマイズした
br-ex
ブリッジをオブジェクト設定ファイルで定義した。 - プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを NAD CRD ファイルで定義した。
手順
クラスター内に存在するベアメタルホストごとに、クラスターの
install-config.yaml
ファイルで、次の例のようにnetworkConfig
セクションを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow NMState 設定ファイルで各ネットワークインターフェイスを定義します。
多数のネットワークインターフェイスを定義する NMState 設定ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ボンディングポートの
br-ex
MTU を手動で設定します。
base64
コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。base64 -w0 <nmstate_configuration>.yml
$ base64 -w0 <nmstate_configuration>.yml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
-w0
オプションは、base64 エンコード操作中に行の折り返しを防止します。
master
ロールとworker
ロールのMachineConfig
マニフェストファイルを作成します。前のコマンドからの base64 エンコード文字列を各MachineConfig
マニフェストファイルに必ず埋め込んでください。次のマニフェストファイルの例では、クラスター内に存在するすべてのノードに対してmaster
ロールを設定します。ノード固有のmaster
ロールとworker
ロールのマニフェストファイルを作成することもできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各
MachineConfig
マニフェストファイルを./<installation_directory>/manifests
ディレクトリーに保存します。<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーです。Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。
2.1.6. user-provisioned infrastructure の準備 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。
このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。
準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。
前提条件
- OpenShift Container Platform 4.x のテスト済みインテグレーション を確認している。
- user-provisioned infrastructure を使用したクラスターの要件 で説明されているインフラストラクチャーの要件を確認している。
手順
DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。
- ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。
DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。
注記DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項の詳細は、DHCP を使用したクラスターノードのホスト名の設定 セクションを参照してください。
注記DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。
- ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
重要デフォルトで、ポート
1936
は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。
クラスターに必要な DNS インフラストラクチャーを設定します。
- Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。
OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。
DNS 設定を検証します。
- インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。
DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
- 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。
2.1.7. user-provisioned infrastructure の DNS 解決の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を user-provisioned infrastructure にインストールする前に、DNS 設定を検証できます。
このセクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。
前提条件
- user-provisioned infrastructure に必要な DNS レコードを設定している。
手順
インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。
Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nameserver_ip>
をネームサーバーの IP アドレスに、<cluster_name>
をクラスター名に、<base_domain>
をベースドメイン名に置き換えます。
出力例
api.ocp4.example.com. 604800 IN A 192.168.1.5
api.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow *.apps.<cluster_name>.<base_domain>
DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
random
は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。
API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.5
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com. 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com.
1 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。
ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.96
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。
2.1.8. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core
ユーザーの ~/.ssh/authorized_keys
リストに追加され、パスワードなしの認証が可能になります。
キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core
として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather
コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
プラットフォーム固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記x86_64
、ppc64le
、およびs390x
アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519
アルゴリズムを使用するキーを作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。クラスターを独自にプロビジョニングするインフラストラクチャーにインストールする場合は、キーをインストールプログラムに指定する必要があります。
2.1.9. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
ヒント- ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
- OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。
重要- インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
- インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。
2.1.10. OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールした場合、それを使用して OpenShift Container Platform のすべてのコマンドを実行することはできません。
新しいバージョンの oc
をダウンロードしてインストールしてください。
2.1.10.1. Linux への OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの Download OpenShift Container Platform ページに移動します。
- Product Variant リストからアーキテクチャーを選択します。
- Version リストから適切なバージョンを選択します。
- OpenShift v4.19 Linux Clients エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.10.2. Windows への OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの Download OpenShift Container Platform ページに移動します。
- Version リストから適切なバージョンを選択します。
- OpenShift v4.19 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.10.3. macOS への OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの Download OpenShift Container Platform ページに移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.19 macOS Clients エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.19 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
oc
コマンドを使用してインストールを確認します。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.11. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
mkdir <installation_directory>
$ mkdir <installation_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、ファイルを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。多くのクラスターのインストールに使用できるように、
install-config.yaml
ファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yaml
ファイルを使用するため、今すぐこのファイルをバックアップしてください。
2.1.11.1. ベアメタルのサンプル install-config.yaml ファイル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 5
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 3 6
- 同時マルチスレッド (SMT) またはハイパースレッディングを有効/無効にするかどうかを指定します。デフォルトでは、SMT はマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を
Disabled
に設定するとこれを無効にすることができます。SMT を無効にする場合、これをすべてのクラスターマシンで無効にする必要があります。これにはコントロールプレーンとコンピュートマシンの両方が含まれます。注記同時マルチスレッド (SMT) はデフォルトで有効になっています。SMT が BIOS 設定で有効になっていない場合は、
hyperthreading
パラメーターは効果がありません。重要BIOS または
install-config.yaml
ファイルであるかに関係なくhyperthreading
を無効にする場合、容量計画においてマシンのパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 - 4
- OpenShift Container Platform を user-provisioned infrastructure にインストールする場合は、この値を
0
に設定する必要があります。installer-provisioned installation では、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。user-provisioned installation では、クラスターのインストールの終了前にコンピュートマシンを手動でデプロイする必要があります。注記3 ノードクラスターをインストールする場合は、Red Hat Enterprise Linux CoreOS (RHCOS) マシンをインストールする際にコンピュートマシンをデプロイしないでください。
- 7
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 8
- DNS レコードに指定したクラスター名。
- 9
- Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。注記
クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。
- 10
- それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、
hostPrefix
が23
に設定されている場合、各ノードに指定のcidr
から/23
サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。 - 11
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 12
- サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
- 13
- プラットフォームを
none
に設定する必要があります。プラットフォーム用に追加のプラットフォーム設定変数を指定することはできません。重要プラットフォームタイプ
none
でインストールされたクラスターは、Machine API を使用したコンピュートマシンの管理など、一部の機能を使用できません。この制限は、クラスターに接続されている計算マシンが、通常はこの機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。 - 14
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 15
- Red Hat OpenShift Cluster Manager からのプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
- 16
- Red Hat Enterprise Linux CoreOS (RHCOS) の
core
ユーザーの SSH 公開鍵。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
2.1.11.2. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml
ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
ベアメタルインストールでは、install-config.yaml
ファイルの networking.machineNetwork[].cidr
フィールドで指定される範囲にあるノード IP アドレスを割り当てない場合、それらを proxy.noProxy
フィールドに含める必要があります。
前提条件
-
既存の
install-config.yaml
ファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxy
オブジェクトのspec.noProxy
フィールドに追加している。注記Proxy
オブジェクトのstatus.noProxy
フィールドには、インストール設定のnetworking.machineNetwork[].cidr
、networking.clusterNetwork[].cidr
、およびnetworking.serviceNetwork[]
フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundle
という名前の設定マップをopenshift-config
namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle
config map を作成し、この config map はProxy
オブジェクトのtrustedCA
フィールドで参照されます。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション:
trustedCA
フィールドのuser-ca-bundle
設定マップを参照するProxy
オブジェクトの設定を決定するポリシー。許可される値はProxyonly
およびAlways
です。Proxyonly
を使用して、http/https
プロキシーが設定されている場合にのみuser-ca-bundle
設定マップを参照します。Always
を使用して、常にuser-ca-bundle
設定マップを参照します。デフォルト値はProxyonly
です。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-for
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
2.1.11.3. 3 ノードクラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
オプションで、3 台のコントロールプレーンマシンのみで構成されるベアメタルクラスターに、ゼロコンピュートマシンをデプロイできます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。
3 ノードの OpenShift Container Platform 環境では、3 つのコントロールプレーンマシンがスケジュール対象となります。つまり、アプリケーションのワークロードがそれらで実行されるようにスケジュールされます。
前提条件
-
既存の
install-config.yaml
ファイルがある。
手順
以下の
compute
スタンザに示されるように、コンピュートレプリカの数がinstall-config.yaml
ファイルで0
に設定されることを確認します。compute: - name: worker platform: {} replicas: 0
compute: - name: worker platform: {} replicas: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デプロイするコンピュートマシンの数にかかわらず、OpenShift Container Platform を user-provisioned infrastructure にインストールする際に、コンピュートマシンの
replicas
パラメーターの値を0
に設定する必要があります。installer-provisioned installation では、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。これは、コンピュートマシンが手動でデプロイされる、user-provisioned installation には適用されません。
3 ノードのクラスターのインストールで、以下の手順を実行します。
- ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
-
以下の手順で Kubernetes マニフェストファイルを作成する際に、
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルのmastersSchedulable
パラメーターがtrue
に設定されていることを確認します。これにより、アプリケーションのワークロードがコントロールプレーンノードで実行できます。 - Red Hat Enterprise Linux CoreOS (RHCOS) マシンを作成する際は、コンピュートノードをデプロイしないでください。
2.1.12. Kubernetes マニフェストおよび Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、作成したinstall-config.yaml
ファイルが含まれるインストールディレクトリーを指定します。
警告3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。
重要コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-password
およびkubeconfig
ファイルが./<installation_directory>/auth
ディレクトリーに作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.13. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を独自にプロビジョニングするベアメタルインフラストラクチャーにインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) をマシンにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。
RHCOS をマシンにインストールするには、ISO イメージまたはネットワーク PXE ブートを使用する手順のいずれかを実行します。
このインストールガイドに含まれるコンピュートノードのデプロイメント手順は、RHCOS 固有のものです。代わりに RHEL ベースのコンピュートノードのデプロイを選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL8 コンピュートマシンのみがサポートされています。
以下の方法を使用して、ISO および PXE のインストール時に RHCOS を設定できます。
-
カーネル引数: カーネル引数を使用してインストール固有の情報を提供できます。たとえば、HTTP サーバーにアップロードした RHCOS インストールファイルの場所と、インストールするノードタイプの Ignition 設定ファイルの場所を指定できます。PXE インストールの場合、
APPEND
パラメーターを使用して、ライブインストーラーのカーネルに引数を渡すことができます。ISO インストールの場合は、ライブインストール起動プロセスを中断してカーネル引数を追加できます。いずれのインストールの場合でも、特殊なcoreos.inst.*
引数を使用してライブインストーラーに指示を与えたり、標準のカーネルサービスをオンまたはオフにするために標準のインストールブート引数を使用したりできます。 -
Ignition 設定: OpenShift Container Platform Ignition 設定ファイル (
*.ign
) は、インストールするノードのタイプに固有のものです。RHCOS のインストール時にブートストラップ、コントロールプレーン、またはコンピュートノードの Ignition 設定ファイルの場所を渡して、初回起動時に有効にされるようにします。特別なケースでは、ライブシステムに渡すために個別の制限付き Ignition 設定を作成できます。この Ignition 設定は、インストールが正常に完了したことをプロビジョニングシステムに報告するなどの一連のタスクを実行する可能性があります。この特別な Ignition 設定は、インストール済みシステムの初回ブート時に適用されるcoreos-installer
によって使用されます。標準のコントロールプレーンおよびコンピュートノードの Ignition 設定をライブ ISO に直接指定しないでください。 coreos-installer
: ライブ ISO インストーラーをシェルプロンプトで起動できます。これにより、初回のブート前にさまざまな方法で永続的なシステムの準備を行うことができます。特に、coreos-installer
コマンドを実行すると、追加するさまざまなアーティファクトを特定し、ディスクパーティションを使用し、ネットワークを設定できます。場合によっては、ライブシステムで機能を設定し、それらをインストールされたシステムにコピーできます。注記バージョン
0.17.0-3
以降、coreos-installer
プログラムを実行するには RHEL 9 以降が必要です。古いバージョンのcoreos-installer
を使用して、新しい OpenShift Container Platform リリースの RHCOS アーティファクトをカスタマイズし、メタルイメージをディスクにインストールすることもできます。coreos-installer
バイナリーの古いバージョンは、coreos-installer
image mirror ページからダウンロードできます。
ISO または PXE インストールを使用するかどうかは、状況によって異なります。PXE インストールには、利用可能な DHCP サービスとさらなる準備が必要ですが、インストールプロセスはさらに自動化することが可能です。ISO インストールは主に手動によるプロセスで、複数のマシンを設定する場合には使用しにくい可能性があります。
2.1.13.1. ISO イメージを使用した RHCOS のインストール リンクのコピーリンクがクリップボードにコピーされました!
ISO イメージを使用してマシンに RHCOS をインストールできます。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS、および負荷分散インフラストラクチャーを設定している。
- お使いのコンピューターからアクセスでき、作成するマシンからもアクセスできる HTTP サーバーがある。
- ネットワークやディスクパーティションなどのさまざまな機能の設定方法について、高度な RHCOS インストール設定 のセクションを確認している。
手順
それぞれの Ignition 設定ファイルの SHA512 ダイジェストを取得します。たとえば、Linux を実行しているシステムで以下を使用して、
bootstrap.ign
Ignition 設定ファイルの SHA512 ダイジェストを取得できます。sha512sum <installation_directory>/bootstrap.ign
$ sha512sum <installation_directory>/bootstrap.ign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ダイジェストは、クラスターノードの Ignition 設定ファイルの信頼性を検証するために、後の手順で
coreos-installer
に提供されます。インストールプログラムが作成したブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
インストールホストから、Ignition 設定ファイルが URL で利用可能であることを確認します。以下の例では、ブートストラップノードの Ignition 設定ファイルを取得します。
curl -k http://<HTTP_server>/bootstrap.ign
$ curl -k http://<HTTP_server>/bootstrap.ign
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドで
bootstrap.ign
をmaster.ign
またはworker.ign
に置き換え、コントロールプレーンおよびコンピュートノードの Ignition 設定ファイルも利用可能であることを検証します。RHCOS イメージのミラー ページから、オペレーティングシステムインスタンスをインストールするための推奨される方法に必要な RHCOS イメージを取得することは可能ですが、RHCOS イメージの正しいバージョンを取得するための推奨される方法は、
openshift-install
コマンドの出力から取得することです。openshift-install coreos print-stream-json | grep '\.iso[^.]'
$ openshift-install coreos print-stream-json | grep '\.iso[^.]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso", "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso", "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso", "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
"location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso", "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso", "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso", "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。この手順には ISO イメージのみを使用します。RHCOS qcow2 イメージは、このインストールではサポートされません。
ISO ファイルの名前は以下の例のようになります。
rhcos-<version>-live.<architecture>.iso
ISO を使用し、RHCOS インストールを開始します。以下のインストールオプションのいずれかを使用します。
- ディスクに ISO イメージを書き込み、これを直接起動します。
- Lights Out Management (LOM) インターフェイスを使用して ISO リダイレクトを使用します。
オプションを指定したり、ライブ起動シーケンスを中断したりせずに、RHCOS ISO イメージを起動します。インストーラーが RHCOS ライブ環境でシェルプロンプトを起動するのを待ちます。
注記RHCOS インストール起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに、以下の手順で説明しているように
coreos-installer
コマンドを使用する必要があります。coreos-installer
コマンドを実行し、インストール要件を満たすオプションを指定します。少なくとも、ノードタイプの Ignition 設定ファイルを参照する URL と、インストール先のデバイスを指定する必要があります。sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ --ignition-hash=sha512-<digest>
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \
1 --ignition-hash=sha512-<digest>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記TLS を使用する HTTPS サーバーを使用して Ignition 設定ファイルを提供する場合は、
coreos-installer
を実行する前に、内部認証局 (CA) をシステムのトラストストアに追加できます。以下の例では、
/dev/sda
デバイスへのブートストラップノードのインストールを初期化します。ブートストラップノードの Ignition 設定ファイルは、IP アドレス 192.168.1.2 で HTTP Web サーバーから取得されます。sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \ --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \ --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシンのコンソールで RHCOS インストールの進捗を監視します。
重要OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
- RHCOS のインストール後、システムを再起動する必要があります。システムの再起動後、指定した Ignition 設定ファイルを適用します。
コンソール出力をチェックして、Ignition が実行されたことを確認します。
コマンドの例
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 継続してクラスターの他のマシンを作成します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、OpenShift Container Platform のインストール前に少なくとも 2 つのコンピュートマシンも作成します。
必要なネットワーク、DNS、およびロードバランサーインフラストラクチャーが配置されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS ノードの再起動後に自動的に起動します。
注記RHCOS ノードには、
core
ユーザーのデフォルトのパスワードは含まれません。ノードには、ssh core@<node>.<cluster_name>.<base_domain>
を、install_config.yaml
ファイルで指定したパブリックキーとペアになる SSH プライベートキーへのアクセスのあるユーザーとして実行してアクセスできます。RHCOS を実行する OpenShift Container Platform 4 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、インストールの問題を調査する際に、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、デバッグまたは障害復旧に SSH アクセスが必要になることがあります。
2.1.13.2. PXE または iPXE ブートを使用した RHCOS のインストール リンクのコピーリンクがクリップボードにコピーされました!
PXE または iPXE ブートを使用してマシンに RHCOS をインストールできます。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- 適切な PXE または iPXE インフラストラクチャーを設定していること。
- お使いのコンピューターからアクセスでき、作成するマシンからもアクセスできる HTTP サーバーがある。
- ネットワークやディスクパーティションなどのさまざまな機能の設定方法について、高度な RHCOS インストール設定 のセクションを確認している。
手順
インストールプログラムが作成したブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
インストールホストから、Ignition 設定ファイルが URL で利用可能であることを確認します。以下の例では、ブートストラップノードの Ignition 設定ファイルを取得します。
curl -k http://<HTTP_server>/bootstrap.ign
$ curl -k http://<HTTP_server>/bootstrap.ign
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドで
bootstrap.ign
をmaster.ign
またはworker.ign
に置き換え、コントロールプレーンおよびコンピュートノードの Ignition 設定ファイルも利用可能であることを検証します。RHCOS イメージミラー ページからオペレーティングシステムインスタンスをインストールするための推奨される方法に必要な RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得することは可能ですが、RHCOS ファイルの正しいバージョンを取得するための推奨される方法は、openshift-install
コマンドの出力から取得することです。openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'
$ openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要RHCOS アーティファクトは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な
kernel
、initramfs
、およびrootfs
アーティファクトのみを使用します。RHCOS QCOW2 イメージは、このインストールタイプではサポートされません。ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。
-
kernel
:rhcos-<version>-live-kernel-<architecture>
-
initramfs
:rhcos-<version>-live-initramfs.<architecture>.img
-
rootfs
:rhcos-<version>-live-rootfs.<architecture>.img
-
rootfs
、kernel
、およびinitramfs
ファイルを HTTP サーバーにアップロードします。重要インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
- RHCOS のインストール後にマシンがローカルディスクから起動されるようにネットワークブートインフラストラクチャーを設定します。
RHCOS イメージの PXE または iPXE インストールを設定し、インストールを開始します。
ご使用の環境に関する以下の例で示されるメニューエントリーのいずれかを変更し、イメージおよび Ignition ファイルが適切にアクセスできることを確認します。
PXE(
x86_64
) の場合:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 1
- HTTP サーバーにアップロードしたライブ
kernel
ファイルの場所を指定します。URL は HTTP、TFTP、または FTP である必要があります。HTTPS および NFS はサポートされません。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
initrd
パラメーター値はinitramfs
ファイルの場所であり、coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所、またcoreos.inst.ignition_url
パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。APPEND
行にカーネル引数を追加して、ネットワークやその他の起動オプションを設定することもできます。
注記この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、
APPEND
行に 1 つ以上のconsole=
引数を追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。iPXE (
x86_64
+aarch64
) の場合:kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img boot
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
1 2 initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img
3 boot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値はkernel
ファイルの場所であり、initrd=main
引数は UEFI システムでの起動に必要であり、coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- HTTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
注記この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、
kernel
行にconsole=
引数を 1 つ以上追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。注記aarch64
アーキテクチャーで CoreOSkernel
をネットワークブートするには、IMAGE_GZIP
オプションが有効になっているバージョンの iPXE ビルドを使用する必要があります。iPXE のIMAGE_GZIP
オプション を参照してください。aarch64
上の PXE (第 2 段階として UEFI と Grub を使用) の場合:menuentry 'Install CoreOS' { linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign initrd rhcos-<version>-live-initramfs.<architecture>.img }
menuentry 'Install CoreOS' { linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
1 2 initrd rhcos-<version>-live-initramfs.<architecture>.img
3 }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- HTTP/TFTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値は、TFTP サーバー上のkernel
ファイルの場所になります。coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値は HTTP サーバー上のブートストラップ Ignition 設定ファイルの場所になります。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- TFTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
マシンのコンソールで RHCOS インストールの進捗を監視します。
重要OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
- RHCOS のインストール後に、システムは再起動します。再起動中、システムは指定した Ignition 設定ファイルを適用します。
コンソール出力をチェックして、Ignition が実行されたことを確認します。
コマンドの例
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのマシンの作成を続行します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、クラスターのインストール前に少なくとも 2 つのコンピュートマシンを作成します。
必要なネットワーク、DNS、およびロードバランサーインフラストラクチャーが配置されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS ノードの再起動後に自動的に起動します。
注記RHCOS ノードには、
core
ユーザーのデフォルトのパスワードは含まれません。ノードには、ssh core@<node>.<cluster_name>.<base_domain>
を、install_config.yaml
ファイルで指定したパブリックキーとペアになる SSH プライベートキーへのアクセスのあるユーザーとして実行してアクセスできます。RHCOS を実行する OpenShift Container Platform 4 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、インストールの問題を調査する際に、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、デバッグまたは障害復旧に SSH アクセスが必要になることがあります。
2.1.13.3. 高度な RHCOS インストール設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 用の Red Hat Enterprise Linux CoreOS (RHCOS) ノードを手動でプロビジョニングする主な利点は、デフォルトの OpenShift Container Platform インストール方法では利用できない設定を実行できることです。このセクションでは、以下のような手法で実行できるいくつかの設定を説明します。
- カーネル引数をライブインストーラーに渡す
-
ライブシステムからの
coreos-installer
の手動による実行 - ライブ ISO または PXE ブートイメージのカスタマイズ
このセクションで説明されている手動の Red Hat Enterprise Linux CoreOS (RHCOS) インストールの高度な設定トピックは、ディスクパーティション設定、ネットワーク、および複数の異なる方法での Ignition 設定の使用に関連しています。
2.1.13.3.1. PXE および ISO インストールの高度なネットワーキングオプションの使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ノードのネットワークはデフォルトで DHCP を使用して、必要な設定をすべて収集します。静的 IP アドレスを設定したり、ボンディングなどの特別な設定を行う場合は、以下のいずれかの方法で実行できます。
- ライブインストーラーの起動時に、特別なカーネルパラメーターを渡します。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
- ライブインストーラーのシェルプロンプトからネットワークを設定し、それらの設定をインストール済みシステムにコピーして、インストール済みシステムの初回起動時に有効になるようにします。
PXE または iPXE インストールを設定するには、以下のオプションのいずれかを使用します。
- 「詳細な RHCOS インストールリファレンスの表」を参照してください。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
ISO インストールを設定するには、以下の手順に従います。
手順
- ISO インストーラーを起動します。
-
ライブシステムシェルプロンプトから、
nmcli
またはnmtui
などの利用可能な RHEL ツールを使用して、ライブシステムのネットワークを設定します。 coreos-installer
コマンドを実行してシステムをインストールし、--copy-network
オプションを追加してネットワーク設定をコピーします。以下に例を示します。sudo coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
$ sudo coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要--copy-network
オプションは、/etc/NetworkManager/system-connections
にあるネットワーク設定のみをコピーします。特に、システムのホスト名はコピーされません。- インストール済みのシステムで再起動します。
2.1.13.3.2. ディスクパーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
ディスクパーティションは、Red Hat Enterprise Linux CoreOS (RHCOS) のインストール時に OpenShift Container Platform クラスターノードに作成されます。デフォルトのパーティション設定をオーバーライドしない限り、特定のアーキテクチャーの各 RHCOS ノードで同じパーティションレイアウトが使用されます。RHCOS のインストール時に、ルートファイルシステムのサイズが拡大し、ターゲットデバイスの残りの使用可能なスペースが使用されます。
ノードでカスタムパーティションスキームを使用すると、OpenShift Container Platform が一部のノードパーティションでモニタリングやアラートを行わなくなる可能性があります。デフォルトのパーティション設定をオーバーライドする場合は、OpenShift Container Platform がホストファイルシステムを監視する方法の詳細について Understanding OpenShift File System Monitoring (eviction conditions) を参照してください。
OpenShift Container Platform は、次の 2 つのファイルシステム識別子を監視します。
-
nodefs
:/var/lib/kubelet
を含むファイルシステム -
imagefs
:/var/lib/containers
を含むファイルシステム
デフォルトのパーティションスキームの場合、nodefs
と imagefs
は同じルートファイルシステム (/
) を監視します。
RHCOS を OpenShift Container Platform クラスターノードにインストールするときにデフォルトのパーティション設定をオーバーライドするには、別のパーティションを作成する必要があります。コンテナーとコンテナーイメージ用に別のストレージパーティションを追加する状況を考えてみましょう。たとえば、/var/lib/containers
を別のパーティションにマウントすると、kubelet が /var/lib/containers
を imagefs
ディレクトリーとして、ルートファイルシステムを nodefs
ディレクトリーとして個別に監視します。
より大きなファイルシステムをホストするためにディスクサイズを変更した場合は、別の /var/lib/containers
パーティションを作成することを検討してください。多数の割り当てグループによって発生する CPU 時間の問題を軽減するには、xfs
形式のディスクのサイズを変更することを検討してください。
2.1.13.3.2.1. 個別の /var パーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
通常は、RHCOS のインストール時に作成されるデフォルトのディスクパーティションを使用する必要があります。ただし、拡張するディレクトリーの個別のパーティションの作成が必要となる場合もあります。
OpenShift Container Platform は、ストレージを /var
ディレクトリーまたは /var
のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
-
/var/lib/containers
: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。 -
/var/lib/etcd
: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。 /var
: 監査などの目的に合わせて分離させる必要のあるデータを保持します。重要ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の
/var
パーティションを作成します。
/var
ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
/var
ディレクトリーまたは /var
のサブディレクトリーの個別のパーティションを使用すると、パーティション設定されたディレクトリーでのデータの増加によりルートファイルシステムが一杯になることを避けることもできます。
以下の手順では、インストールの準備フェーズでノードタイプの Ignition 設定ファイルにラップされるマシン設定マニフェストを追加して、別の /var
パーティションを設定します。
手順
インストールホストで、OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加のパーティションを設定する Butane 設定を作成します。たとえば、
$HOME/clusterconfig/98-var-partition.bu
ファイルに名前を付け、ディスクのデバイス名をworker
システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var
ディレクトリーを別のパーティションにマウントします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小のオフセット値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。オフセット値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、
prjquota
マウントオプションを有効にする必要があります。
注記個別の
/var
パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、コンピュートノードに異なるインスタンスタイプを使用することはできません。Butane config からマニフェストを作成し、
clusterconfig/openshift
ディレクトリーに保存します。たとえば、以下のコマンドを実行します。butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignition 設定ファイルを作成します。
openshift-install create ignition-configs --dir <installation_directory>
$ openshift-install create ignition-configs --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <installation_directory>/manifest
ディレクトリーおよび<installation_directory>/openshift
ディレクトリーのファイルは、98-var-partition
カスタムMachineConfig
オブジェクトが含まれるファイルを含む Ignition 設定ファイルにラップされます。
次のステップ
- RHCOS のインストール時に Ignition 設定ファイルを参照して、カスタムディスクのパーティション設定を適用することができます。
2.1.13.3.2.2. 既存パーティションの保持 リンクのコピーリンクがクリップボードにコピーされました!
ISO インストールの場合は、インストーラーに 1 つ以上の既存パーティションを維持させる coreos-installer
コマンドにオプションを追加することができます。PXE インストールの場合、coreos.inst.*
オプションを APPEND
パラメーターに追加して、パーティションを保持できます。
保存したパーティションは、既存の OpenShift Container Platform システムからのデータパーティションである可能性があります。パーティションラベルまたは番号のいずれかで保持する必要のあるディスクパーティションを特定できます。
既存のパーティションを保存し、それらのパーティションが RHCOS の十分な領域を残さない場合、インストールは失敗します。この場合、保存したパーティションが破損することはありません。
ISO インストール時の既存パーティションの保持
この例では、パーティションラベルが data
(data*
) で始まるパーティションを保持します。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partlabel 'data*' \ /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partlabel 'data*' \
/dev/disk/by-id/scsi-<serial_number>
以下の例では、ディスク上の 6 番目のパーティションを保持する方法で coreos-installer
を実行する方法を説明しています。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partindex 6 /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 6 /dev/disk/by-id/scsi-<serial_number>
この例では、パーティション 5 以上を保持します。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
パーティションの保存が使用された以前の例では、coreos-installer
はパーティションをすぐに再作成します。
PXE インストール時の既存パーティションの保持
この APPEND
オプションは、パーティションラベルが 'data' ('data*') で始まるパーティションを保持します。
coreos.inst.save_partlabel=data*
coreos.inst.save_partlabel=data*
この APPEND
オプションは、パーティション 5 以上を保持します。
coreos.inst.save_partindex=5-
coreos.inst.save_partindex=5-
この APPEND
オプションは、パーティション 6 を保持します。
coreos.inst.save_partindex=6
coreos.inst.save_partindex=6
2.1.13.3.3. Ignition 設定の特定 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS の手動インストールを実行する場合、提供できる Ignition 設定には 2 つのタイプがあり、それぞれを提供する理由もそれぞれ異なります。
Permanent install Ignition config: すべての手動の RHCOS インストールは、
bootstrap.ign
、master.ign
、およびworker.ign
などのopenshift-installer
が生成した Ignition 設定ファイルのいずれかを渡し、インストールを実行する必要があります。重要これらの Ignition 設定ファイルを直接変更することは推奨されません。前述のセクションの例で説明されているように、Ignition 設定ファイルにラップされるマニフェストファイルを更新できます。
PXE インストールの場合、
coreos.inst.ignition_url=
オプションを使用して、APPEND
行に Ignition 設定を渡します。ISO インストールの場合、シェルプロンプトで ISO を起動した後に、--ignition-url=
オプションを指定したcoreos-installer
コマンドラインで Ignition 設定を特定します。いずれの場合も、HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。Live install Ignition config: このタイプは、
coreos-installer
customize
サブコマンドとそのさまざまなオプションを使用して作成できます。この方法では、Ignition 設定はライブインストールメディアに渡され、起動直後に実行され、RHCOS システムがディスクにインストールされる前または後にセットアップタスクを実行します。この方法は、マシン設定を使用して実行できない高度なパーティション設定など、一度の適用後に再度適用する必要のないタスクの実行にのみ使用する必要があります。PXE または ISO ブートの場合、Ignition 設定を作成し、
ignition.config.url=
オプションに対してAPPEND
を実行し、Ignition 設定の場所を特定できます。また、ignition.firstboot ignition.platform.id=metal
も追加する必要があります。追加しない場合は、ignition.config.url
が無視されます。
2.1.13.3.4. デフォルトのコンソール設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 ブートイメージからインストールされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードは、ほとんどの仮想化セットアップおよびベアメタルセットアップに対応するためのデフォルトコンソールを使用します。クラウドおよび仮想化プラットフォームが異なれば、選択したアーキテクチャーに応じて、異なるデフォルト設定が使用される場合があります。ベアメタルインストールではカーネルのデフォルト設定が使用されます。これは通常、グラフィカルコンソールがプライマリーコンソールで、シリアルコンソールが無効になっていることを意味します。
デフォルトのコンソールが特定のハードウェア設定と一致しない場合や、デフォルトのコンソールを調整する必要がある特定のニーズがある場合があります。以下に例を示します。
- デバッグ目的で、コンソールの緊急シェルにアクセスしたいと考えています。
- クラウドプラットフォームは、グラフィカルコンソールへの対話型アクセスを提供しませんが、シリアルコンソールを提供します。
- 複数のコンソールを有効にしたい。
コンソール設定は、ブートイメージから継承されます。これは、既存のクラスター内の新しいノードが、デフォルトのコンソールへの変更の影響を受けないことを意味します。
次の方法で、ベアメタルインストール用にコンソールを設定できます。
-
コマンドラインで手動で
coreos-installer
を使用する。 -
--dest-console
オプションを指定したcoreos-installer iso customize
またはcoreos-installer pxe customize
サブコマンドを使用して、プロセスを自動化するカスタムイメージを作成します。
高度なカスタマイズを行うには、カーネル引数ではなく、coreos-installer iso
または coreos-installer pxe
サブコマンドを使用してコンソール設定を実行します。
2.1.13.3.5. PXE および ISO インストール用のシリアルコンソールの有効化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat Enterprise Linux CoreOS (RHCOS) シリアルコンソールは無効になっており、すべての出力はグラフィカルコンソールに書き込まれます。ISO インストール用にシリアルコンソールを有効にし、シリアルコンソールとグラフィカルコンソールの両方に出力が送信されるようにブートローダーを再設定できます。
手順
- ISO インストーラーを起動します。
coreos-installer
コマンドを実行してシステムをインストールし、--console
オプションを 1 回追加してグラフィカルコンソールを指定し、2 回目にシリアルコンソールを指定します。coreos-installer install \ --console=tty0 \ --console=ttyS0,<options> \ --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer install \ --console=tty0 \
1 --console=ttyS0,<options> \
2 --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 2
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。
インストール済みのシステムで再起動します。
注記coreos-installer install --append-karg
オプションを使用し、console=
でコンソールを指定すると、同様の結果が得られます。ただし、これはカーネルのコンソールのみを設定し、ブートローダーは設定しません。
PXE インストールを設定するには、coreos.inst.install_dev
カーネルコマンドラインオプションが省略されていることを確認し、シェルプロンプトを使用して、上記の ISO インストール手順を使用して手動で coreos-installer
を実行します。
2.1.13.3.6. ライブ RHCOS ISO または PXE インストールのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
ライブ ISO イメージまたは PXE 環境を使用して、Ignition 設定ファイルをイメージに直接挿入することで RHCOS をインストールできます。これにより、システムのプロビジョニングに使用できるカスタマイズされたイメージが作成されます。
ISO イメージの場合、これを行うメカニズムは coreos-installer iso customize
サブコマンドです。これは設定に合わせて .iso
ファイルを変更します。同様に、PXE 環境のメカニズムは、カスタマイズを含む新しい initramfs
ファイルを作成する coreos-installer pxe customize
サブコマンドです。
customize
サブコマンドは、他のタイプのカスタマイズも埋め込むことができる汎用ツールです。次のタスクは、より一般的なカスタマイズの例です。
- 企業のセキュリティーポリシーで使う必要がある場合に備えて、カスタム CA 証明書を挿入します。
- カーネル引数を必要とせずにネットワーク設定を設定します。
- 任意のプレインストールおよびポストインストールスクリプトまたはバイナリーを埋め込みます。
2.1.13.3.7. ライブ RHCOS ISO イメージのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
coreos-installer iso customize
サブコマンドを使用して、ライブ RHCOS ISO イメージを直接カスタマイズできます。ISO イメージを起動すると、カスタマイズが自動的に適用されます。
この機能を使用して、RHCOS を自動的にインストールするように ISO イメージを設定できます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページと Ignition 設定ファイルから RHCOS ISO イメージを取得し、次のコマンドを実行して、Ignition 設定を ISO イメージに直接挿入します。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition bootstrap.ign \ --dest-device /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition bootstrap.ign \
1 --dest-device /dev/disk/by-id/scsi-<serial_number>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ISO イメージのカスタマイズを削除し、イメージを元の状態に戻すには、次のコマンドを実行します。
coreos-installer iso reset rhcos-<version>-live.x86_64.iso
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、ライブ ISO イメージを再カスタマイズしたり、元の状態で使用したりできます。
カスタマイズを適用すると、それ以降のすべての RHCOS 起動に影響します。
2.1.13.3.7.1. ライブインストール ISO イメージを変更して、シリアルコンソールを有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 以降でインストールされたクラスターでは、シリアルコンソールはデフォルトで無効になり、すべての出力がグラフィカルコンソールに書き込まれます。次の手順でシリアルコンソールを有効にできます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して ISO イメージをカスタマイズし、シリアルコンソールが出力を受信できるようにします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition <path> \ --dest-console tty0 \ --dest-console ttyS0,<options> \ --dest-device /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition <path> \
1 --dest-console tty0 \
2 --dest-console ttyS0,<options> \
3 --dest-device /dev/disk/by-id/scsi-<serial_number>
4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールする Ignition 設定の場所。
- 2
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 3
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。 - 4
- インストール先として指定されたディスク。このオプションを省略すると、ISO イメージはインストールプログラムを自動的に実行しますが、
coreos.inst.install_dev
カーネル引数も指定しない限り失敗します。
注記--dest-console
オプションは、ライブ ISO システムではなく、インストールされたシステムに影響します。ライブ ISO システムのコンソールを変更するには、--live-karg-append
オプションを使用し、console=
でコンソールを指定します。カスタマイズが適用され、ISO イメージの後続のすべての起動に影響します。
オプション: ISO イメージのカスタマイズを削除してイメージを元の状態に戻すには、次のコマンドを実行します。
coreos-installer iso reset rhcos-<version>-live.x86_64.iso
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ライブ ISO イメージを再カスタマイズするか、元の状態で使用できるようになりました。
2.1.13.3.7.2. カスタム認証局を使用するようにライブインストール ISO イメージを変更する リンクのコピーリンクがクリップボードにコピーされました!
customize
サブコマンドの --ignition-ca
フラグを使用して、認証局 (CA) 証明書を Ignition に提供できます。CA 証明書は、インストールの起動時とインストール済みシステムのプロビジョニング時の両方で使用できます。
カスタム CA 証明書は、Ignition がリモートリソースをフェッチする方法に影響しますが、システムにインストールされている証明書には影響しません。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して、カスタム CA で使用する ISO イメージをカスタマイズします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
coreos.inst.ignition_url
カーネルパラメーターは、--ignition-ca
フラグでは機能しません。クラスターごとにカスタマイズされたイメージを作成するには、--dest-ignition
フラグを使用する必要があります。
カスタム CA 証明書を適用すると、それ以降のすべての RHCOS 起動に影響します。
2.1.13.3.7.3. カスタマイズされたネットワーク設定を使用したライブインストール ISO イメージの変更 リンクのコピーリンクがクリップボードにコピーされました!
NetworkManager キーファイルをライブ ISO イメージに埋め込み、customize
サブコマンドの --network-keyfile
フラグを使用してインストール済みシステムに渡すことができます。
接続プロファイルを作成する際は、接続プロファイルのファイル名に .nmconnection
ファイル名拡張子を使用する必要があります。.nmconnection
ファイル名拡張子を使用しない場合、クラスターは接続プロファイルをライブ環境に適用しますが、クラスターが初めてノードを起動するときに設定が適用されないため、セットアップが機能しなくなります。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 ボンディングされたインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em1.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em2.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して、設定されたネットワークで ISO イメージをカスタマイズします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク設定はライブシステムに適用され、宛先システムに引き継がれます。
2.1.13.3.7.4. iSCSI ブートデバイス用のライブインストール ISO イメージをカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次の情報を使用して ISO イメージをカスタマイズするために、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- 宛先システムの場所。ターゲットポータルの IP アドレス、関連付けられたポート番号、IQN 形式のターゲット iSCSI ノード、および iSCSI 論理ユニット番号 (LUN) を指定する必要があります。
- 4
- 宛先システムの Ignition 設定。
- 5
- IQN 形式の iSCSI イニシエーター、クライアントの名前。イニシエーターは iSCSI ターゲットに接続するセッションを形成します。
- 6
- IQN 形式の iSCSI ターゲットまたはサーバーの名前。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.1.13.3.7.5. iBFT を使用して iSCSI ブートデバイス用のライブインストール ISO イメージをカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次の情報を使用して ISO イメージをカスタマイズするために、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- デバイスへのパス。マルチパスを使用している場合は、マルチパスデバイス (
/dev/mapper/mpatha
) を使用します。複数のマルチパスデバイスが接続されている場合、または明示する場合、/dev/disk/by-path
で使用可能な World Wide Name (WWN) シンボリックリンクを使用できます。 - 4
- 宛先システムの Ignition 設定。
- 5
- iSCSI パラメーターは、BIOS ファームウェアから読み取られます。
- 6
- オプション: マルチパス構成を有効にする場合は、このパラメーターを含めます。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.1.13.3.8. ライブ RHCOS PXE 環境のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
coreos-installer pxe customize
サブコマンドを使用して、ライブ RHCOS PXE 環境を直接カスタマイズできます。PXE 環境を起動すると、カスタマイズが自動的に適用されます。
この機能を使用して、RHCOS を自動的にインストールするように PXE 環境を設定できます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページと Ignition 設定ファイルから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、Ignition 設定からのカスタマイズを含む新しいinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --dest-ignition bootstrap.ign \ --dest-device /dev/disk/by-id/scsi-<serial_number> \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --dest-ignition bootstrap.ign \
1 --dest-device /dev/disk/by-id/scsi-<serial_number> \
2 -o rhcos-<version>-custom-initramfs.x86_64.img
3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
カスタマイズを適用すると、それ以降のすべての RHCOS 起動に影響します。
2.1.13.3.8.1. ライブインストール PXE 環境を変更して、シリアルコンソールを有効化。 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 以降でインストールされたクラスターでは、シリアルコンソールはデフォルトで無効になり、すべての出力がグラフィカルコンソールに書き込まれます。次の手順でシリアルコンソールを有効にできます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページおよび Ignition 設定ファイルから RHCOS
kernel
、initramfs
およびrootfs
ファイルを取得します。次のコマンドを実行して、シリアルコンソールが出力を受信できるようにする新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールする Ignition 設定の場所。
- 2
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 3
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。 - 4
- インストール先として指定されたディスク。このオプションを省略すると、PXE 環境は自動的にインストーラーを実行しますが、
coreos.inst.install_dev
カーネル引数も指定しない限り失敗します。 - 5
- PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。
カスタマイズが適用され、PXE 環境の後続のすべての起動に影響します。
2.1.13.3.8.2. カスタム認証局を使用するようにライブインストール PXE 環境を変更する リンクのコピーリンクがクリップボードにコピーされました!
customize
サブコマンドの --ignition-ca
フラグを使用して、認証局 (CA) 証明書を Ignition に提供できます。CA 証明書は、インストールの起動時とインストール済みシステムのプロビジョニング時の両方で使用できます。
カスタム CA 証明書は、Ignition がリモートリソースをフェッチする方法に影響しますが、システムにインストールされている証明書には影響しません。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、カスタム CA で使用するための新しいカスタマイズされたinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --ignition-ca cert.pem \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --ignition-ca cert.pem \ -o rhcos-<version>-custom-initramfs.x86_64.img
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。
coreos.inst.ignition_url
カーネルパラメーターは、--ignition-ca
フラグでは機能しません。クラスターごとにカスタマイズされたイメージを作成するには、--dest-ignition
フラグを使用する必要があります。
カスタム CA 証明書を適用すると、それ以降のすべての RHCOS 起動に影響します。
2.1.13.3.8.3. カスタマイズされたネットワーク設定を使用したライブインストール PXE 環境の変更 リンクのコピーリンクがクリップボードにコピーされました!
NetworkManager キーファイルをライブ PXE 環境に埋め込み、customize
サブコマンドの --network-keyfile
フラグを使用して、インストール済みシステムに渡すことができます。
接続プロファイルを作成する際は、接続プロファイルのファイル名に .nmconnection
ファイル名拡張子を使用する必要があります。.nmconnection
ファイル名拡張子を使用しない場合、クラスターは接続プロファイルをライブ環境に適用しますが、クラスターが初めてノードを起動するときに設定が適用されないため、セットアップが機能しなくなります。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 ボンディングされたインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em1.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em2.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、設定済みのネットワークを含む新しいカスタマイズされたinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection \ -o rhcos-<version>-custom-initramfs.x86_64.img
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。ネットワーク設定はライブシステムに適用され、宛先システムに引き継がれます。
2.1.13.3.8.4. iSCSI ブートデバイス用のライブインストール PXE 環境をカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、次の情報を含む新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- 宛先システムの場所。ターゲットポータルの IP アドレス、関連付けられたポート番号、IQN 形式のターゲット iSCSI ノード、および iSCSI 論理ユニット番号 (LUN) を指定する必要があります。
- 4
- 宛先システムの Ignition 設定。
- 5
- IQN 形式の iSCSI イニシエーター、クライアントの名前。イニシエーターは iSCSI ターゲットに接続するセッションを形成します。
- 6
- IQN 形式の iSCSI ターゲットまたはサーバーの名前。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.1.13.3.8.5. iBFT を使用して iSCSI ブートデバイス用のライブインストール PXE 環境をカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、次の情報を含む新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- デバイスへのパス。マルチパスを使用している場合は、マルチパスデバイス (
/dev/mapper/mpatha
) を使用します。複数のマルチパスデバイスが接続されている場合、または明示する場合、/dev/disk/by-path
で使用可能な World Wide Name (WWN) シンボリックリンクを使用できます。 - 4
- 宛先システムの Ignition 設定。
- 5
- iSCSI パラメーターは、BIOS ファームウェアから読み取られます。
- 6
- オプション: マルチパス構成を有効にする場合は、このパラメーターを含めます。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.1.13.3.9. 詳細の RHCOS インストールリファレンス リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat Enterprise Linux CoreOS (RHCOS) の手動インストールプロセスを変更できるようにするネットワーク設定および他の高度なオプションを説明します。以下の表では、RHCOS ライブインストーラーおよび coreos-installer
コマンドで使用できるカーネル引数およびコマンドラインのオプションを説明します。
2.1.13.3.9.1. ISO インストールのネットワークおよびボンディングのオプション リンクのコピーリンクがクリップボードにコピーされました!
ISO イメージから RHCOS をインストールする場合、そのイメージを起動してノードのネットワークを設定する際に手動でカーネル引数を追加できます。ネットワークの引数が指定されていない場合、RHCOS が Ignition 設定ファイルを取得するためにネットワークが必要であることを検知する際に、DHCP が initramfs でアクティベートされます。
ネットワーク引数を手動で追加する場合は、rd.neednet=1
カーネル引数を追加して、ネットワークを initramfs で有効にする必要があります。
以下の情報は、ISO インストール用に RHCOS ノードでネットワークおよびボンディングを設定する例を示しています。この例では、ip=
、nameserver=
、および bond=
カーネル引数の使用方法を説明しています。
順序は、カーネル引数の ip=
、nameserver=
、および bond=
を追加する場合に重要です。
ネットワークオプションは、システムの起動時に dracut
ツールに渡されます。dracut
でサポートされるネットワークオプションの詳細は、dracut.cmdline
man ページ を参照してください。
次の例は、ISO インストールのネットワークオプションです。
2.1.13.3.9.1.1. DHCP または静的 IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
IP アドレスを設定するには、DHCP (ip=dhcp
) を使用するか、個別の静的 IP アドレス (ip=<host_ip>
) を設定します。静的 IP を設定する場合、各ノードで DNS サーバー IP アドレス (nameserver=<dns_ip>
) を特定する必要があります。次の例では、以下を設定します。
-
ノードの IP アドレス:
10.10.10.2
-
ゲートウェイアドレス:
10.10.10.254
-
ネットワーク:
255.255.255.0
-
ホスト名:
core0.example.com
-
DNS サーバーアドレス:
4.4.4.41
-
auto-configuration の値を
none
に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none nameserver=4.4.4.41
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41
DHCP を使用して RHCOS マシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP ベースのデプロイメントの場合、DHCP サーバー設定を使用して RHCOS ノードが使用する DNS サーバーアドレスを定義できます。
2.1.13.3.9.1.2. 静的ホスト名を使用しない IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
静的ホスト名を割り当てずに IP アドレスを設定できます。静的ホスト名がユーザーによって設定されていない場合は、逆引き DNS ルックアップによって取得され、自動的に設定されます。静的ホスト名なしで IP アドレスを設定するには、次の例を参照してください。
-
ノードの IP アドレス:
10.10.10.2
-
ゲートウェイアドレス:
10.10.10.254
-
ネットワーク:
255.255.255.0
-
DNS サーバーアドレス:
4.4.4.41
-
auto-configuration の値を
none
に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none nameserver=4.4.4.41
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41
2.1.13.3.9.1.3. 複数のネットワークインターフェイスの指定 リンクのコピーリンクがクリップボードにコピーされました!
複数の ip=
エントリーを設定することで、複数のネットワークインターフェイスを指定できます。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
2.1.13.3.9.1.4. デフォルトゲートウェイとルートの設定 リンクのコピーリンクがクリップボードにコピーされました!
オプション: rd.route=
value を設定して、追加のネットワークへのルートを設定できます。
1 つまたは複数のネットワークを設定する場合、1 つのデフォルトゲートウェイが必要です。追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。
次のコマンドを実行して、デフォルトゲートウェイを設定します。
ip=::10.10.10.254::::
ip=::10.10.10.254::::
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、追加ネットワークのルートを設定します。
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.13.3.9.1.5. 単一インターフェイスでの DHCP の無効化 リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上のネットワークインターフェイスがあり、1 つのインターフェイスのみが使用される場合などに、1 つのインターフェイスで DHCP を無効にします。この例では、enp1s0
インターフェイスには静的ネットワーク設定があり、使用されていない enp2s0
では DHCP が無効になっています。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none ip=::::core0.example.com:enp2s0:none
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none
2.1.13.3.9.1.6. DHCP と静的 IP 設定の組み合わせ リンクのコピーリンクがクリップボードにコピーされました!
以下のように、複数のネットワークインターフェイスを持つシステムで、DHCP および静的 IP 設定を組み合わせることができます。
ip=enp1s0:dhcp ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
2.1.13.3.9.1.7. 個々のインターフェイスでの VLAN の設定 リンクのコピーリンクがクリップボードにコピーされました!
オプション: vlan=
パラメーターを使用して、個別のインターフェイスに VLAN を設定できます。
ネットワークインターフェイスで VLAN を設定し、静的 IP アドレスを使用するには、次のコマンドを実行します。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none vlan=enp2s0.100:enp2s0
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none vlan=enp2s0.100:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスで VLAN を設定し、DHCP を使用するには、次のコマンドを実行します。
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.13.3.9.1.8. 複数の DNS サーバーの指定 リンクのコピーリンクがクリップボードにコピーされました!
以下のように、各サーバーに nameserver=
エントリーを追加して、複数の DNS サーバーを指定できます。
nameserver=1.1.1.1 nameserver=8.8.8.8
nameserver=1.1.1.1
nameserver=8.8.8.8
2.1.13.3.9.1.9. 複数のネットワークインターフェイスの単一インターフェイスへのボンディング リンクのコピーリンクがクリップボードにコピーされました!
オプション: bond=
オプションを使用して、複数のネットワークインターフェイスを単一のインターフェイスにボンディングできます。次の例を参照してください。
ボンディングされたインターフェイスを設定するための構文は、
bond=<name>[:<network_interfaces>][:options]
です。<name>
はボンディングデバイス名 (bond0
)、<network_interfaces>
は物理 (イーサネット) インターフェイスのコンマ区切りのリスト (em1,em2
) を表し、options はボンディングオプションのコンマ区切りのリストです。modinfo bonding
を入力して、利用可能なオプションを表示します。bond=
を使用してボンディングされたインターフェイスを作成する場合は、ボンディングされたインターフェイスの IP アドレスの割り当て方法やその他の情報を指定する必要があります。DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを
dhcp
に設定します。以下に例を示します。bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:em1,em2:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
bond=bond0:em1,em2:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.13.3.9.1.10. 複数の SR-IOV ネットワークインターフェイスをデュアルポート NIC インターフェイスに結合する リンクのコピーリンクがクリップボードにコピーされました!
オプション: bond=
オプションを使用して、複数の SR-IOV ネットワークインターフェイスをデュアルポート NIC インターフェイスに結合できます。
各ノードで、次のタスクを実行する必要があります。
- SR-IOV デバイスの管理 のガイダンスに従って、SR-IOV 仮想機能 (VF) を作成します。「仮想マシンへの SR-IOV ネットワークデバイスの接続」セクションの手順に従います。
- ボンドを作成し、目的の VF をボンドに接続し、ネットワークボンディングの設定 のガイダンスに従って、ボンドリンクの状態を設定します。説明されている手順のいずれかに従って、結合を作成します。
次の例は、使用する必要がある構文を示しています。
結合インターフェイスを設定するための構文は、
bond=<name>[:<network_interfaces>][:options]
です。<name>
はボンディングデバイス名 (bond0
)、<network_interfaces>
は仮想機能 (VF) をカーネル内の既知の名前で表し、ip link
コマンド (eno1f0
、eno2f0
) の出力に表示されます。options は結合オプションのコンマ区切りリストです。modinfo bonding
を入力して、利用可能なオプションを表示します。bond=
を使用してボンディングされたインターフェイスを作成する場合は、ボンディングされたインターフェイスの IP アドレスの割り当て方法やその他の情報を指定する必要があります。DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを
dhcp
に設定します。以下に例を示します。bond=bond0:eno1f0,eno2f0:mode=active-backup ip=bond0:dhcp
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=bond0:dhcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.13.3.9.1.11. ネットワークチーミングの使用 リンクのコピーリンクがクリップボードにコピーされました!
任意: team=
パラメーターを指定して、ボンディングの代わりにネットワークチーミングを使用できます。
チームインターフェイス設定の構文は
team=name[:network_interfaces]
です。name はチームデバイス名 (
team0
)、network_interfaces は物理 (イーサネット) インターフェイス (em1, em2
) のコンマ区切りリストを表します。
RHCOS が次のバージョンの RHEL に切り替わると、チーミングは非推奨になる予定です。詳細は、こちらの Red Hat ナレッジベース記事 を参照してください。
次の例を使用して、ネットワークチームを設定します。
team=team0:em1,em2 ip=team0:dhcp
team=team0:em1,em2
ip=team0:dhcp
2.1.13.3.9.2. ISO および PXE インストール用の coreos-installer オプション リンクのコピーリンクがクリップボードにコピーされました!
RHCOS は、ISO イメージから RHCOS ライブ環境に起動した後に、コマンドプロンプトで coreos-installer install <options> <device>
を実行してインストールできます。
以下の表は、coreos-installer
コマンドに渡すことのできるサブコマンド、オプションおよび引数を示しています。
coreos-installer install サブコマンド | |
サブコマンド | 説明 |
| Ignition 設定を ISO イメージに埋め込みます。 |
coreos-installer install サブコマンドオプション | |
オプション | 説明 |
| イメージの URL を手動で指定します。 |
| ローカルイメージファイルを手動で指定します。デバッグに使用されます。 |
| ファイルから Ignition 設定を埋め込みます。 |
| URL から Ignition 設定を埋め込みます。 |
|
Ignition 設定の |
| インストール済みシステムの Ignition プラットフォーム ID を上書きします。 |
|
インストールされたシステムのカーネルとブートローダーコンソールを設定します。 |
| インストール済みシステムにデフォルトのカーネル引数を追加します。 |
| インストール済みシステムからデフォルトのカーネル引数を削除します。 |
| インストール環境からネットワーク設定をコピーします。 重要
|
|
|
| このラベル glob でパーティションを保存します。 |
| この数または範囲でパーティションを保存します。 |
| RHCOS イメージ署名の検証を省略します。 |
| HTTPS またはハッシュなしで Ignition URL を許可します。 |
|
ターゲット CPU アーキテクチャー。有効な値は |
| エラー時のパーティションテーブルは消去しないでください。 |
| ヘルプ情報を表示します。 |
coreos-installer インストールサブコマンド引数 | |
引数 | 説明 |
| 宛先デバイス。 |
coreos-installer ISO サブコマンド | |
サブコマンド | 説明 |
| RHCOS ライブ ISO イメージをカスタマイズします。 |
| RHCOS ライブ ISO イメージをデフォルト設定に復元します。 |
| ISO イメージから埋め込まれた Ignition 設定を削除します。 |
coreos-installer ISO カスタマイズサブコマンドオプション | |
オプション | 説明 |
| 指定された Ignition 設定ファイルを宛先システムの新しい設定フラグメントにマージします。 |
| 宛先システムのカーネルとブートローダーコンソールを指定します。 |
| 指定した宛先デバイスをインストールして上書きします。 |
| 宛先システムの各起動にカーネル引数を追加します。 |
| 宛先システムの各起動からカーネル引数を削除します。 |
| ライブシステムと宛先システムに指定された NetworkManager キーファイルを使用してネットワークを設定します。 |
| Ignition によって信頼される追加の TLS 認証局を指定します。 |
| インストールする前に、指定されたスクリプトを実行します。 |
| インストール後に指定されたスクリプトを実行します。 |
| 指定されたインストーラー設定ファイルを適用します。 |
| 指定された Ignition 設定ファイルをライブ環境の新しい設定フラグメントにマージします。 |
| ライブ環境の各ブートにカーネル引数を追加します。 |
| ライブ環境の各ブートからカーネル引数を削除します。 |
|
ライブ環境の各起動で、 |
| 既存の Ignition 設定を上書きします。 |
| 新しい出力ファイルに ISO を書き込みます。 |
| ヘルプ情報を表示します。 |
coreos-installer PXE サブコマンド | |
サブコマンド | 説明 |
これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。 | |
| RHCOS ライブ PXE ブート設定をカスタマイズします。 |
| イメージに Ignition 設定をラップします。 |
| イメージでラップされた Ignition 設定を表示します。 |
coreos-installer PXE はサブコマンドオプションをカスタマイズします | |
オプション | 説明 |
これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。 | |
| 指定された Ignition 設定ファイルを宛先システムの新しい設定フラグメントにマージします。 |
| 宛先システムのカーネルとブートローダーコンソールを指定します。 |
| 指定した宛先デバイスをインストールして上書きします。 |
| ライブシステムと宛先システムに指定された NetworkManager キーファイルを使用してネットワークを設定します。 |
| Ignition によって信頼される追加の TLS 認証局を指定します。 |
| インストールする前に、指定されたスクリプトを実行します。 |
| インストール後に指定されたスクリプトを実行します。 |
| 指定されたインストーラー設定ファイルを適用します。 |
| 指定された Ignition 設定ファイルをライブ環境の新しい設定フラグメントにマージします。 |
| initramfs を新しい出力ファイルに書き込みます。 注記 このオプションは、PXE 環境に必要です。 |
| ヘルプ情報を表示します。 |
2.1.13.3.9.3. ISO または PXE インストールの coreos.inst ブートオプション リンクのコピーリンクがクリップボードにコピーされました!
coreos.inst
ブートパラメーターを RHCOS ライブインストーラーに渡して、ブート時に coreos-installer
オプションを自動的に起動できます。これらは、標準のブート引数の追加として提供されます。
-
ISO インストールの場合、ブートローダーメニューで自動ブートを中断して
coreos.inst
オプションを追加できます。RHEL CoreOS (Live) メニューオプションが強調表示されている状態でTAB
を押すと、自動ブートを中断できます。 -
PXE または iPXE インストールの場合、RHCOS ライブインストーラーのブート前に
coreos.inst
オプションをAPPEND
行に追加する必要があります。
以下の表は、ISO および PXE インストールの RHCOS ライブインストーラーの coreos.inst
ブートオプションを示しています。
引数 | 説明 |
---|---|
| 必須。インストール先のシステムのブロックデバイス。 注記
|
| オプション: インストール済みシステムに埋め込む Ignition 設定の URL。URL が指定されていない場合、Ignition 設定は埋め込まれません。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 |
| オプション: インストール時に保存するパーティションのコンマ区切りのラベル。glob 形式のワイルドカードが許可されます。指定したパーティションは存在する必要はありません。 |
|
オプション: インストール時に保存するパーティションのコンマ区切りのインデックス。範囲 |
|
オプション: |
| オプション: 指定した RHCOS イメージをダウンロードし、インストールします。
|
| オプション: システムはインストール後に再起動しません。インストールが完了するとプロンプトが表示され、インストール時に生じる内容を検査できます。この引数は実稼働環境では使用できず、デバッグの目的でのみ使用することが意図されています。 |
|
オプション: RHCOS イメージがインストールされるプラットフォームの Ignition プラットフォーム ID。デフォルトは |
|
オプション: ライブ起動の Ignition 設定の URL。たとえば、これは |
2.1.13.4. RHCOS のカーネル引数でのマルチパスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS はプライマリーディスクでのマルチパスをサポートするようになり、ハードウェア障害に対する対障害性が強化され、ホストの可用性を強化できるようになりました。
OpenShift Container Platform 4.8 以降でプロビジョニングされたノードのマルチパスを有効にできます。インストール後のサポートは、マシン設定を使用してマルチパスをアクティベートすることで利用できますが、インストール中にマルチパスを有効にすることが推奨されます。
非最適化パスに対して I/O があると、I/O システムエラーが発生するように設定するには、インストール時にマルチパスを有効にする必要があります。
IBM Z® および IBM® LinuxONE では、インストール時にクラスターを設定した場合のみマルチパスを有効にできます。詳細は、IBM Z® および IBM® LinuxONE への z/VM を使用したクラスターのインストール の RHCOS の「インストールおよび OpenShift Container Platform ブートストラッププロセスの開始」を参照してください。
以下の手順では、インストール時にマルチパスを有効にし、coreos-installer install
コマンドにカーネル引数を追加して、インストール済みシステム自体が初回起動からマルチパスを使用できるようにします。
OpenShift Container Platform は、4.6 以前からアップグレードされたノードでの day-2 アクティビティーとしてのマルチパスの有効化をサポートしません。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 を確認した。
手順
マルチパスを有効にして
multipathd
デーモンを起動するには、インストールホストで次のコマンドを実行します。mpathconf --enable && systemctl start multipathd.service
$ mpathconf --enable && systemctl start multipathd.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
必要に応じて、PXE または ISO を起動する場合は、カーネルコマンドラインから
rd.multipath=default
を追加することで、マルチパスを有効にできます。
-
必要に応じて、PXE または ISO を起動する場合は、カーネルコマンドラインから
coreos-installer
プログラムを呼び出してカーネル引数を追加します。マシンに接続されているマルチパスデバイスが 1 つしかない場合は、このデバイスは
/dev/mapper/mpatha
のパスで利用できます。以下に例を示します。coreos-installer install /dev/mapper/mpatha \ --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
$ coreos-installer install /dev/mapper/mpatha \
1 --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 1 つのマルチパスデバイスのパスを指定します。
複数のマルチパスデバイスがマシンに接続している場合には、より明示的に
/dev/mapper/mpatha
を使用する代わりに、/dev/disk/by-id
で利用可能な World Wide Name (WWN) シンボリックリンクを使用することが推奨されます。以下に例を示します。coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \ --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
$ coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \
1 --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マルチパス化されたデバイスの WWN ID を指定します。例:
0xx194e957fcedb4841
特別な
coreos.inst.*
引数を使用してライブインストーラーを指定する場合に、このシンボリックリンクをcoreos.inst.install_dev
カーネル引数として使用することもできます。詳細は、「RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始」を参照してください。
- インストール済みのシステムで再起動します。
ワーカーノードのいずれかに移動し、(ホストの
/proc/cmdline
内の) カーネルコマンドライン引数をリスト表示して、カーネル引数が機能していることを確認します。oc debug node/ip-10-0-141-105.ec2.internal
$ oc debug node/ip-10-0-141-105.ec2.internal
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加したカーネル引数が表示されるはずです。
2.1.13.4.1. セカンダリーディスクでのマルチパス構成の有効化 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS はセカンダリーディスク上のマルチパス構成もサポートします。カーネル引数の代わりに、Ignition を使用してインストール時にセカンダリーディスクのマルチパス構成を有効にします。
前提条件
- ディスクのパーティション設定 セクションを読了した。
- RHCOS のカーネル引数でのマルチパスの有効化 を読了した。
- Butane ユーティリティーをインストールした。
手順
次のような情報を含む Butane 設定を作成します。
multipath-config.bu
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Ignition 設定を作成します。
butane --pretty --strict multipath-config.bu > multipath-config.ign
$ butane --pretty --strict multipath-config.bu > multipath-config.ign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 初回起動時の RHCOS インストールプロセスの残りを続行します。
重要プライマリーディスクもマルチパス化されていない限り、インストール中にコマンドラインに
rd.multipath
またはroot
カーネル引数を追加しないでください。
2.1.13.5. iSCSI ブートデバイスに RHCOS を手動でインストールする リンクのコピーリンクがクリップボードにコピーされました!
iSCSI ターゲットに、手動で RHCOS をインストールできます。
前提条件
- RHCOS ライブ環境にいる。
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
次のコマンドを実行して、ライブ環境から iSCSI ターゲットをマウントします。
iscsiadm \ --mode discovery \ --type sendtargets
$ iscsiadm \ --mode discovery \ --type sendtargets --portal <IP_address> \
1 --login
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ターゲットポータルの IP アドレス。
次のコマンドを実行し、必要なカーネル引数を使用して、RHCOS を iSCSI ターゲットにインストールします。以下はその例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。次のコマンドを実行して iSCSI ディスクをアンマウントします。
iscsiadm --mode node --logoutall=all
$ iscsiadm --mode node --logoutall=all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順は、coreos-installer iso customize
または coreos-installer pxe customize
サブコマンドを使用して実行することもできます。
2.1.13.6. iBFT を使用して iSCSI ブートデバイスに RHCOS をインストールする リンクのコピーリンクがクリップボードにコピーされました!
完全にディスクレスなマシンでは、iSCSI ターゲットとイニシエーターの値を iBFT 経由で渡すことができます。iSCSI マルチパス構成もサポートされています。
前提条件
- RHCOS ライブ環境にいる。
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
次のコマンドを実行して、ライブ環境から iSCSI ターゲットをマウントします。
iscsiadm \ --mode discovery \ --type sendtargets
$ iscsiadm \ --mode discovery \ --type sendtargets --portal <IP_address> \
1 --login
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ターゲットポータルの IP アドレス。
オプション: マルチパス構成を有効にし、次のコマンドでデーモンを起動します。
mpathconf --enable && systemctl start multipathd.service
$ mpathconf --enable && systemctl start multipathd.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、必要なカーネル引数を使用して、RHCOS を iSCSI ターゲットにインストールします。以下はその例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。iSCSI ディスクをアンマウントします。
iscsiadm --mode node --logout=all
$ iscsiadm --mode node --logout=all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順は、coreos-installer iso customize
または coreos-installer pxe customize
サブコマンドを使用して実行することもできます。
2.1.14. ブートストラッププロセスの完了まで待機する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
- RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
- お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。
手順
ブートストラッププロセスをモニターします。
./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ --log-level=info
$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \
1 --log-level=info
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.32.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.32.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。
2.1.15. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、
kubeadmin
認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
次のコマンドを実行し、エクスポートされた設定を使用して
oc
コマンドを正常に実行できることを確認します。oc whoami
$ oc whoami
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.16. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.32.3 master-1 Ready master 63m v1.32.3 master-2 Ready master 64m v1.32.3
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.32.3 master-1 Ready master 63m v1.32.3 master-2 Ready master 64m v1.32.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
Pending
またはApproved
ステータスが表示されていることを確認します。oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りの CSR が承認されず、それらが
Pending
ステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
2.1.17. Operator の初期設定 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。
前提条件
- コントロールプレーンが初期化されています。
手順
クラスターコンポーネントがオンラインになることを確認します。
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 利用不可の Operator を設定します。
2.1.17.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
2.1.17.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
2.1.17.2.1. ベアメタルおよび他の手動インストールの場合のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - ベアメタルなどの、手動でプロビジョニングされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードを使用するクラスターがある。
Red Hat OpenShift Data Foundation などのクラスターのプロビジョニングされた永続ストレージがある。
重要OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの
ReadWriteOnce
アクセスをサポートします。ReadWriteOnce
アクセスでは、レジストリーがRecreate
ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany
アクセスが必要です。- 100 Gi の容量がある。
手順
レジストリーをストレージを使用できるように設定するには、
configs.imageregistry/cluster
リソースのspec.storage.pvc
を変更します。注記共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。
レジストリー Pod がないことを確認します。
oc get pod -n openshift-image-registry -l docker-registry=default
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resources found in openshift-image-registry namespace
No resources found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
storage: pvc: claim:
storage: pvc: claim:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow claim
フィールドを空のままにし、image-registry-storage
PVC の自動作成を可能にします。clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.19 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.19 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。
以下を実行します。
oc edit configs.imageregistry/cluster
$ oc edit configs.imageregistry/cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、行を変更します。
managementState: Removed
managementState: Removed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のように変更してください。
managementState: Managed
managementState: Managed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.17.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。
手順
イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。
oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告実稼働用以外のクラスターにのみこのオプションを設定します。
Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、
oc patch
コマンドは以下のエラーを出して失敗します。Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 数分待機した後に、このコマンドを再び実行します。
2.1.17.2.3. ベアメタルの場合のブロックレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
イメージレジストリーがクラスター管理者によるアップグレード時にブロックストレージタイプを使用できるようにするには、Recreate
ロールアウトストラテジーを使用できます。
ブロックストレージボリューム (または永続ボリューム) はサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。
イメージレジストリーでブロックストレージボリュームを使用することを選択した場合は、ファイルシステムの persistent volume claim (PVC) を使用する必要があります。
手順
次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して
Recreate
ロールアウトストラテジーを使用し、1 つの (1
) レプリカのみで実行されるようにします。oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。
以下の内容で
pvc.yaml
ファイルを作成して VMware vSpherePersistentVolumeClaim
オブジェクトを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ファイルから
PersistentVolumeClaim
オブジェクトを作成します。oc create -f pvc.yaml -n openshift-image-registry
$ oc create -f pvc.yaml -n openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。
oc edit config.imageregistry.operator.openshift.io -o yaml
$ oc edit config.imageregistry.operator.openshift.io -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
storage: pvc: claim:
storage: pvc: claim:
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- カスタム PVC を作成することにより、
image-registry-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
2.1.18. user-provisioned infrastructure でのインストールの完了 リンクのコピーリンクがクリップボードにコピーされました!
Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。
前提条件
- コントロールプレーンが初期化されています。
- Operator の初期設定を完了済みです。
手順
以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。
./openshift-install --dir <installation_directory> wait-for install-complete
$ ./openshift-install --dir <installation_directory> wait-for install-complete
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
出力例
INFO Waiting up to 30m0s for the cluster to initialize...
INFO Waiting up to 30m0s for the cluster to initialize...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
Kubernetes API サーバーが Pod と通信していることを確認します。
すべての Pod のリストを表示するには、以下のコマンドを使用します。
oc get pods --all-namespaces
$ oc get pods --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。
oc logs <pod_name> -n <namespace>
$ oc logs <pod_name> -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前のコマンドの出力にあるように、Pod 名および namespace を指定します。
Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。
FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。
詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。
2.1.19. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
2.1.20. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- インストールの検証
- クラスターのカスタマイズ
- 必要に応じて、リモートヘルスレポート を作成できます。
- レジストリーをセットアップし、レジストリーストレージを設定 します。
2.2. ネットワークをカスタマイズしたユーザープロビジョニング型ベアメタルクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、カスタマイズしたネットワーク設定オプションを使用して、独自にプロビジョニングするベアメタルインフラストラクチャーにクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。
OpenShift Container Platform ネットワークをカスタマイズする場合、インストール時にほとんどのネットワーク設定パラメーターを設定する必要があります。実行中のクラスターで変更できるのは kubeProxy
ネットワーク設定パラメーターのみです。
2.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 した (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
2.2.2. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、クラスターをインストールするためにインターネットアクセスが必要です。
次のアクションを実行するには、インターネットにアクセスできる必要があります。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターがインターネットにアクセスでき、Telemetry を無効にしていない場合、そのサービスによってクラスターのサブスクリプションが自動的に有効化されます。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
2.2.3. user-provisioned infrastructure を使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
2.2.3.1. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
ホスト | 説明 |
---|---|
1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
例外として、ゼロ (0) コンピュートマシンを 3 つのコントロールプレーンマシンのみで構成されるベアメタルクラスターで実行できます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。1 つのコンピュートマシンの実行はサポートされていません。
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 以降から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 9.2 をベースとしており、そのハードウェア認定および要件がすべて継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
2.2.3.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | CPU [1] | RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
---|---|---|---|---|---|
ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 つの CPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、(コアごとのスレッド x コア数) x ソケット数 = CPU という数式を使用して対応する比率を計算します。
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピュートマシンの使用は非推奨となり、OpenShift Container Platform 4.10 以降で削除されています。
OpenShift Container Platform バージョン 4.19 の場合、RHCOS は RHEL バージョン 9.6 に基づいています。これは、マイクロアーキテクチャー要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、アーキテクチャー (RHEL ドキュメント) を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
2.2.3.3. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求されるサービング証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
2.2.3.4. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルを取得する必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
- クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
- DHCP サービスが user-provisioned infrastructure で利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
2.2.3.4.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
2.2.3.4.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
インターネットに接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Red Hat にテレメトリーデータを提供するために、すべてのノードがインターネットにアクセスできる必要があります。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。ポート | |
| Kubernetes が予約するデフォルトポート | |
| このポートは、マシン設定サーバーからのトラフィックを処理し、トラフィックをコントロールプレーンマシンに送信します。 | |
UDP |
| VXLAN |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
|
UDP ポート | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
2.2.3.4.3. user-provisioned infrastructure の NTP 設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
2.2.3.5. user-provisioned DNS 要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード
- ブートストラップ、コントロールプレーンおよびコンピュートマシン
また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。
DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。
各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。詳細は、user-provisioned infrastructure に関する DHCP の推奨事項 のセクションを参照してください。
以下の DNS レコードは、user-provisioned OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、install-config.yaml
ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
ルート |
| アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
ブートストラップマシン |
| ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コントロールプレーンマシン |
| コントロールプレーンノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コンピュートマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。
dig
コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
2.2.3.5.1. user-provisioned クラスターの DNS 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4
で、ベースドメインは example.com
です。
user-provisioned クラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、user-provisioned クラスターの名前解決の A レコードの例を示しています。
例2.4 DNS ゾーンデータベースのサンプル
- 1
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
- 2
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
- 3
- ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
- 4
- ブートストラップマシンの名前解決を提供します。
- 5 6 7
- コントロールプレーンマシンの名前解決を提供します。
- 8 9
- コンピュートマシンの名前解決を提供します。
user-provisioned クラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、user-provisioned クラスターの逆引き名前解決の PTR レコードの例を示しています。
例2.5 逆引きレコードの DNS ゾーンデータベースの例
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
2.2.3.6. user-provisioned infrastructure の負荷分散要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーション Ingress ロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表2.17 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとのプロービングで、2 回連続成功すると正常、3 回連続失敗すると異常と判断する設定は、十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。
以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表2.18 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
2.2.3.6.1. user-provisioned クラスターのロードバランサーの設定例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned クラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg
設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing
に設定されている場合は、setsebool -P haproxy_connect_any=1
を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
例2.6 API およびアプリケーション Ingress ロードバランサーの設定例
- 1
- ポート
6443
は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 2 4
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 3
- ポート
22623
はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 5
- ポート
443
は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 6
- ポート
80
は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe
を実行して、ポート 6443
、22623
、443
、および 80
で haproxy
プロセスがリッスンしていることを確認することができます。
2.2.4. カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
configure-ovs.sh
シェルスクリプトを使用してベアメタルプラットフォームで br-ex
ブリッジを設定する代わりに、NMState 設定ファイルを含む MachineConfig
オブジェクトを作成できます。ホスト nmstate-configuration.service
および nmstate.service
により、クラスター内で実行される各ノードに NMState 設定ファイルが適用されます。
カスタマイズされた br-ex
ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。
-
Open vSwitch (OVS) または OVN-Kubernetes
br-ex
ブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.sh
シェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。 - ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
-
configure-ovs.sh
シェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。
単一のネットワークインターフェイスコントローラー (NIC) とデフォルトのネットワーク設定を備えた環境が必要な場合は、configure-ovs.sh
シェルスクリプトを使用します。
Red Hat Enterprise Linux CoreOS (RHCOS) をインストールしてシステムを再起動すると、Machine Config Operator がクラスター内の各ノードに Ignition 設定ファイルを注入し、各ノードが br-ex
ブリッジネットワーク設定を受け取るようになります。設定の競合を防ぐために、configure-ovs.sh
シェルスクリプトは、br-ex
ブリッジを設定しない信号を受け取ります。
次のインターフェイス名は予約されており、NMstate 設定では使用できません。
-
br-ext
-
br-int
-
br-local
-
br-nexthop
-
br0
-
ext-vxlan
-
ext
-
genev_sys_*
-
int
-
k8s-*
-
ovn-k8s-*
-
patch-br-*
-
tun0
-
vxlan_sys_*
前提条件
-
オプション: NMState 設定を検証できるように、
nmstate
API をインストールしました。
手順
カスタマイズされた
br-ex
ブリッジネットワークの base64 情報をデコードした NMState 設定ファイルを作成します。カスタマイズされた
br-ex
ブリッジネットワークの NMState 設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat
コマンドを使用して、NMState 設定の内容を base64 でエンコードします。cat <nmstate_configuration>.yaml | base64
$ cat <nmstate_configuration>.yaml | base64
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nmstate_configuration>
を NMState リソース YAML ファイルの名前に置き換えます。
MachineConfig
マニフェストファイルを作成し、次の例に類似したカスタマイズされたbr-ex
ブリッジネットワーク設定を定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のすべてのノードに適用する単一のグローバル設定が
/etc/nmstate/openshift/cluster.yml
設定ファイルで指定されている場合は、各ノードの短いホスト名パス (例:/etc/nmstate/openshift/<node_hostname>.yml
) を指定する必要はありません。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
-
コンピュートノードをスケーリングして、クラスター内に存在する各コンピュートノードに、カスタマイズされた
br-ex
ブリッジを含むマニフェストオブジェクトを適用します。詳細は、関連情報 セクションの「クラスターの拡張」を参照してください。
2.2.4.1. 各マシンセットをコンピュートノードにスケーリング リンクのコピーリンクがクリップボードにコピーされました!
カスタマイズされた br-ex
ブリッジ設定を OpenShift Container Platform クラスター内のすべてのコンピュートノードに適用するには、MachineConfig
カスタムリソース (CR) を編集し、そのロールを変更する必要があります。さらに、ホスト名、認証情報など、ベアメタルマシンの情報を定義する BareMetalHost
CR を作成する必要があります。
これらのリソースを設定した後、マシンセットをスケーリングして、マシンセットが各コンピュートノードにリソース設定を適用し、ノードを再起動できるようにする必要があります。
前提条件
-
カスタマイズされた
br-ex
ブリッジ設定を含むMachineConfig
マニフェストオブジェクトを作成しました。
手順
次のコマンドを入力して
MachineConfig
CR を編集します。oc edit mc <machineconfig_custom_resource_name>
$ oc edit mc <machineconfig_custom_resource_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 各コンピュートノード設定を CR に追加して、CR がクラスター内の定義済みコンピュートノードごとにロールを管理できるようにします。
-
最小限の静的 IP 設定を持つ
extraworker-secret
という名前のSecret
オブジェクトを作成します。 次のコマンドを入力して、クラスター内の各ノードに
extraworker-secret
シークレットを適用します。このステップでは、各コンピュートノードに Ignition 設定ファイルへのアクセスを提供します。oc apply -f ./extraworker-secret.yaml
$ oc apply -f ./extraworker-secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BareMetalHost
リソースを作成し、preprovisioningNetworkDataName
パラメーターでネットワークシークレットを指定します。ネットワークシークレットが添付された
BareMetalHost
リソースの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの
openshift-machine-api
namespace 内でBareMetalHost
オブジェクトを管理するために、次のコマンドを入力して namespace に変更します。oc project openshift-machine-api
$ oc project openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシンセットを取得します。
oc get machinesets
$ oc get machinesets
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各マシンセットをスケールします。このコマンドはマシンセットごとに実行する必要があります。
oc scale machineset <machineset_name> --replicas=<n>
$ oc scale machineset <machineset_name> --replicas=<n>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<machineset_name>
はマシンセットの名前です。<n>
はコンピュートノードの数です。
2.2.5. クラスターで OVS balance-slb モードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上の物理インターフェイスがネットワークトラフィックを共有できるように、Open vSwitch (OVS) の balance-slb
モードを有効にできます。balance-slb
モードのインターフェイスは、ネットワークスイッチとのソースロードバランシングを必要とせずに、仮想化ワークロードを実行するクラスターにソース負荷分散 (SLB) 機能を提供できます。
現在、ソースロードバランシングはボンディングインターフェイスで実行されます。このインターフェイスは br-phy
などの補助ブリッジに接続します。ソースロードバランシングは、Media Access Control (MAC) アドレスと仮想ローカルエリアネットワーク (VLAN) の組み合わせが複数存在する場合にのみ、負荷分散を行います。OVN-Kubernetes Pod のトラフィックはすべて同じ MAC アドレスと VLAN を使用するため、このトラフィックを多数の物理インターフェイス間で負荷分散することはできないことに注意してください。
次の図は、単純なクラスターインフラストラクチャーレイアウトでの balance-slb
モードを示しています。仮想マシン (VM) は、特定の localnet NetworkAttachmentDefinition
(NAD) カスタムリソース定義 (CRD)、NAD 0
または NAD 1
に接続します。各 NAD は、仮想マシンに基盤となる物理ネットワークへのアクセスを提供し、タグ付きまたはタグなしの VLAN トラフィックをサポートしています。br-ex
OVS ブリッジは仮想マシンからのトラフィックを受信し、そのトラフィックを次の OVS ブリッジである br-phy
に渡します。br-phy
ブリッジは SLB ボンディングのコントローラーとして機能します。SLB ボンディングは、eno0
や eno1
などの物理インターフェイスリンクを介して、異なる仮想マシンポートからのトラフィックを分散します。さらに、どちらの物理インターフェイスからの Ingress トラフィックも、OVS ブリッジのセットを通過して仮想マシンに到達できます。
図2.2 2 つの NAD を持つローカルネット上で動作する OVS balance-slb
モード
OVS ボンディングを使用して、balance-slb
モードインターフェイスをプライマリーまたはセカンダリーネットワークタイプに統合できます。OVS ボンディングでは、次の点に注意してください。
- OVN-Kubernetes CNI プラグインをサポートし、プラグインと簡単に統合できます。
-
ネイティブで
balance-slb
モードをサポートします。
前提条件
-
プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを
MachineConfig
ファイルで定義した。 -
マニフェストオブジェクトを作成し、カスタマイズした
br-ex
ブリッジをオブジェクト設定ファイルで定義した。 - プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを NAD CRD ファイルで定義した。
手順
クラスター内に存在するベアメタルホストごとに、クラスターの
install-config.yaml
ファイルで、次の例のようにnetworkConfig
セクションを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow NMState 設定ファイルで各ネットワークインターフェイスを定義します。
多数のネットワークインターフェイスを定義する NMState 設定ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ボンディングポートの
br-ex
MTU を手動で設定します。
base64
コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。base64 -w0 <nmstate_configuration>.yml
$ base64 -w0 <nmstate_configuration>.yml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
-w0
オプションは、base64 エンコード操作中に行の折り返しを防止します。
master
ロールとworker
ロールのMachineConfig
マニフェストファイルを作成します。前のコマンドからの base64 エンコード文字列を各MachineConfig
マニフェストファイルに必ず埋め込んでください。次のマニフェストファイルの例では、クラスター内に存在するすべてのノードに対してmaster
ロールを設定します。ノード固有のmaster
ロールとworker
ロールのマニフェストファイルを作成することもできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各
MachineConfig
マニフェストファイルを./<installation_directory>/manifests
ディレクトリーに保存します。<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーです。Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。
2.2.6. user-provisioned infrastructure の準備 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。
このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。
準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。
前提条件
- OpenShift Container Platform 4.x のテスト済みインテグレーション を確認している。
- user-provisioned infrastructure を使用したクラスターの要件 で説明されているインフラストラクチャーの要件を確認している。
手順
DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。
- ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。
DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。
注記DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項の詳細は、DHCP を使用したクラスターノードのホスト名の設定 セクションを参照してください。
注記DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。
- ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
重要デフォルトで、ポート
1936
は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。
クラスターに必要な DNS インフラストラクチャーを設定します。
- Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。
OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。
DNS 設定を検証します。
- インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。
DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
- 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。
2.2.7. user-provisioned infrastructure の DNS 解決の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を user-provisioned infrastructure にインストールする前に、DNS 設定を検証できます。
このセクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。
前提条件
- user-provisioned infrastructure に必要な DNS レコードを設定している。
手順
インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。
Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nameserver_ip>
をネームサーバーの IP アドレスに、<cluster_name>
をクラスター名に、<base_domain>
をベースドメイン名に置き換えます。
出力例
api.ocp4.example.com. 604800 IN A 192.168.1.5
api.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow *.apps.<cluster_name>.<base_domain>
DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
random
は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。
API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.5
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com. 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com.
1 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。
ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.96
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。
2.2.8. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core
ユーザーの ~/.ssh/authorized_keys
リストに追加され、パスワードなしの認証が可能になります。
キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core
として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather
コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
プラットフォーム固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記x86_64
、ppc64le
、およびs390x
アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519
アルゴリズムを使用するキーを作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
2.2.9. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
ヒント- ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
- OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。
重要- インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
- インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。
2.2.10. OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールした場合、それを使用して OpenShift Container Platform のすべてのコマンドを実行することはできません。
新しいバージョンの oc
をダウンロードしてインストールしてください。
2.2.10.1. Linux への OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの Download OpenShift Container Platform ページに移動します。
- Product Variant リストからアーキテクチャーを選択します。
- Version リストから適切なバージョンを選択します。
- OpenShift v4.19 Linux Clients エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.10.2. Windows への OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの Download OpenShift Container Platform ページに移動します。
- Version リストから適切なバージョンを選択します。
- OpenShift v4.19 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを展開します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.10.3. macOS への OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの Download OpenShift Container Platform ページに移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.19 macOS Clients エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.19 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
oc
コマンドを使用してインストールを確認します。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.11. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
mkdir <installation_directory>
$ mkdir <installation_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、ファイルを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。多くのクラスターのインストールに使用できるように、
install-config.yaml
ファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yaml
ファイルを使用するため、今すぐこのファイルをバックアップしてください。
2.2.11.1. ベアメタルのサンプル install-config.yaml ファイル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 5
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 3 6
- 同時マルチスレッド (SMT) またはハイパースレッディングを有効/無効にするかどうかを指定します。デフォルトでは、SMT はマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を
Disabled
に設定するとこれを無効にすることができます。SMT を無効にする場合、これをすべてのクラスターマシンで無効にする必要があります。これにはコントロールプレーンとコンピュートマシンの両方が含まれます。注記同時マルチスレッド (SMT) はデフォルトで有効になっています。SMT が BIOS 設定で有効になっていない場合は、
hyperthreading
パラメーターは効果がありません。重要BIOS または
install-config.yaml
ファイルであるかに関係なくhyperthreading
を無効にする場合、容量計画においてマシンのパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 - 4
- OpenShift Container Platform を user-provisioned infrastructure にインストールする場合は、この値を
0
に設定する必要があります。installer-provisioned installation では、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。user-provisioned installation では、クラスターのインストールの終了前にコンピュートマシンを手動でデプロイする必要があります。注記3 ノードクラスターをインストールする場合は、Red Hat Enterprise Linux CoreOS (RHCOS) マシンをインストールする際にコンピュートマシンをデプロイしないでください。
- 7
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 8
- DNS レコードに指定したクラスター名。
- 9
- Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。注記
クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。
- 10
- それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、
hostPrefix
が23
に設定されている場合、各ノードに指定のcidr
から/23
サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。 - 11
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 12
- サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
- 13
- プラットフォームを
none
に設定する必要があります。プラットフォーム用に追加のプラットフォーム設定変数を指定することはできません。重要プラットフォームタイプ
none
でインストールされたクラスターは、Machine API を使用したコンピュートマシンの管理など、一部の機能を使用できません。この制限は、クラスターに接続されている計算マシンが、通常はこの機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。 - 14
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 15
- Red Hat OpenShift Cluster Manager からのプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
- 16
- Red Hat Enterprise Linux CoreOS (RHCOS) の
core
ユーザーの SSH 公開鍵。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
2.2.12. ネットワーク設定フェーズ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。
- フェーズ 1
マニフェストファイルを作成する前に、
install-config.yaml
ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。-
networking.networkType
-
networking.clusterNetwork
-
networking.serviceNetwork
-
networking.machineNetwork
nodeNetworking
詳細は、「インストール設定パラメーター」を参照してください。
注記優先されるサブネットが配置されている Classless Inter-Domain Routing (CIDR) と一致するように
networking.machineNetwork
を設定します。重要CIDR 範囲
172.17.0.0/16
はlibVirt
によって予約されています。クラスター内のネットワークに172.17.0.0/16
CIDR 範囲と重複する他の CIDR 範囲を使用することはできません。
-
- フェーズ 2
-
openshift-install create manifests
を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。
フェーズ 2 では、install-config.yaml
ファイルのフェーズ 1 で指定した値をオーバーライドすることはできません。ただし、フェーズ 2 でネットワークプラグインをカスタマイズできます。
2.2.13. 高度なネットワーク設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。
高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。
前提条件
-
install-config.yaml
ファイルを作成し、これに対する変更を完了している。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
は、クラスターのinstall-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/
ディレクトリーに作成します。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、
cluster-network-03-config.yml
ファイルでクラスターの高度なネットワーク設定を指定します。OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/
ディレクトリーを使用します。 コントロールプレーンマシンおよびコンピュート
MachineSets
を定義する Kubernetes マニフェストファイルを削除します。rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml
$ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。
-
MachineSet
ファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
-
2.2.14. Cluster Network Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster
という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io
API グループの Network
API のフィールドを指定します。
CNO 設定は、Network.config.openshift.io
API グループの Network
API からクラスターのインストール時に以下のフィールドを継承します。
clusterNetwork
- Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
- サービスの IP アドレスプール。
defaultNetwork.type
-
クラスターネットワークプラグイン。
OVNKubernetes
は、インストール時にサポートされる唯一のプラグインです。
defaultNetwork
オブジェクトのフィールドを cluster
という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
2.2.14.1. Cluster Network Operator 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
フィールド | タイプ | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod IP アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 |
|
| サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14
マニフェストを作成する前に、このフィールドを |
|
| クラスターネットワークのネットワークプラグインを設定します。 |
|
|
この設定により、動的ルーティングプロバイダーが有効になります。ルートアドバタイズ機能には、FRR ルーティング機能プロバイダーが必要です。サポートされている値は
spec: additionalRoutingCapabilities: providers: - FRR
|
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 |
複数のネットワークにオブジェクトをデプロイする必要があるクラスターの場合は、install-config.yaml
ファイルで定義されている各ネットワークタイプの clusterNetwork.hostPrefix
パラメーターに、必ず同じ値を指定してください。clusterNetwork.hostPrefix
パラメーターにそれぞれ異なる値を設定すると、OVN-Kubernetes ネットワークプラグインに影響が及び、異なるノード間のオブジェクトトラフィックをプラグインが効果的にルーティングできなくなる可能性があります。
2.2.14.1.1. defaultNetwork オブジェクト設定 リンクのコピーリンクがクリップボードにコピーされました!
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
フィールド | タイプ | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。 |
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
2.2.14.1.1.1. OVN-Kubernetes ネットワークプラグインの設定 リンクのコピーリンクがクリップボードにコピーされました!
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
フィールド | タイプ | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
| IPsec 設定をカスタマイズするための設定オブジェクトを指定します。 |
|
| IPv4 設定の設定オブジェクトを指定します。 |
|
| IPv6 設定の設定オブジェクトを指定します。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
|
クラスターネットワークルートをアドバタイズするかどうかを指定します。デフォルト値は、
|
|
|
オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。有効な値は 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
フィールド | タイプ | 説明 |
---|---|---|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
フィールド | タイプ | 説明 |
---|---|---|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
フィールド | タイプ | 説明 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| integer | 保持されるログファイルの最大数。 |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
フィールド | タイプ | 説明 |
---|---|---|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
|
|
注記
デフォルト値の |
|
| オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
|
| オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
フィールド | タイプ | 説明 |
---|---|---|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 重要
OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして |
フィールド | タイプ | 説明 |
---|---|---|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 重要
OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして |
フィールド | タイプ | 説明 |
---|---|---|
|
| IPsec 実装の動作を指定します。次の値のいずれかである必要があります。
|
IPSec が有効な OVN-Kubernetes 設定の例
2.2.15. Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターマシンは手動で起動する必要があるため、クラスターがマシンを作成するために必要な Ignition 設定ファイルを生成する必要があります。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
手順
Ignition 設定ファイルを取得します。
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要install-config.yaml
ファイルを作成している場合、それが含まれるディレクトリーを指定します。または、空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。以下のファイルはディレクトリーに生成されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.16. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を独自にプロビジョニングするベアメタルインフラストラクチャーにインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) をマシンにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。
RHCOS をマシンにインストールするには、ISO イメージまたはネットワーク PXE ブートを使用する手順のいずれかを実行します。
このインストールガイドに含まれるコンピュートノードのデプロイメント手順は、RHCOS 固有のものです。代わりに RHEL ベースのコンピュートノードのデプロイを選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL8 コンピュートマシンのみがサポートされています。
以下の方法を使用して、ISO および PXE のインストール時に RHCOS を設定できます。
-
カーネル引数: カーネル引数を使用してインストール固有の情報を提供できます。たとえば、HTTP サーバーにアップロードした RHCOS インストールファイルの場所と、インストールするノードタイプの Ignition 設定ファイルの場所を指定できます。PXE インストールの場合、
APPEND
パラメーターを使用して、ライブインストーラーのカーネルに引数を渡すことができます。ISO インストールの場合は、ライブインストール起動プロセスを中断してカーネル引数を追加できます。いずれのインストールの場合でも、特殊なcoreos.inst.*
引数を使用してライブインストーラーに指示を与えたり、標準のカーネルサービスをオンまたはオフにするために標準のインストールブート引数を使用したりできます。 -
Ignition 設定: OpenShift Container Platform Ignition 設定ファイル (
*.ign
) は、インストールするノードのタイプに固有のものです。RHCOS のインストール時にブートストラップ、コントロールプレーン、またはコンピュートノードの Ignition 設定ファイルの場所を渡して、初回起動時に有効にされるようにします。特別なケースでは、ライブシステムに渡すために個別の制限付き Ignition 設定を作成できます。この Ignition 設定は、インストールが正常に完了したことをプロビジョニングシステムに報告するなどの一連のタスクを実行する可能性があります。この特別な Ignition 設定は、インストール済みシステムの初回ブート時に適用されるcoreos-installer
によって使用されます。標準のコントロールプレーンおよびコンピュートノードの Ignition 設定をライブ ISO に直接指定しないでください。 coreos-installer
: ライブ ISO インストーラーをシェルプロンプトで起動できます。これにより、初回のブート前にさまざまな方法で永続的なシステムの準備を行うことができます。特に、coreos-installer
コマンドを実行すると、追加するさまざまなアーティファクトを特定し、ディスクパーティションを使用し、ネットワークを設定できます。場合によっては、ライブシステムで機能を設定し、それらをインストールされたシステムにコピーできます。注記バージョン
0.17.0-3
以降、coreos-installer
プログラムを実行するには RHEL 9 以降が必要です。古いバージョンのcoreos-installer
を使用して、新しい OpenShift Container Platform リリースの RHCOS アーティファクトをカスタマイズし、メタルイメージをディスクにインストールすることもできます。coreos-installer
バイナリーの古いバージョンは、coreos-installer
image mirror ページからダウンロードできます。
ISO または PXE インストールを使用するかどうかは、状況によって異なります。PXE インストールには、利用可能な DHCP サービスとさらなる準備が必要ですが、インストールプロセスはさらに自動化することが可能です。ISO インストールは主に手動によるプロセスで、複数のマシンを設定する場合には使用しにくい可能性があります。
2.2.16.1. ISO イメージを使用した RHCOS のインストール リンクのコピーリンクがクリップボードにコピーされました!
ISO イメージを使用してマシンに RHCOS をインストールできます。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS、および負荷分散インフラストラクチャーを設定している。
- お使いのコンピューターからアクセスでき、作成するマシンからもアクセスできる HTTP サーバーがある。
- ネットワークやディスクパーティションなどのさまざまな機能の設定方法について、高度な RHCOS インストール設定 のセクションを確認している。
手順
それぞれの Ignition 設定ファイルの SHA512 ダイジェストを取得します。たとえば、Linux を実行しているシステムで以下を使用して、
bootstrap.ign
Ignition 設定ファイルの SHA512 ダイジェストを取得できます。sha512sum <installation_directory>/bootstrap.ign
$ sha512sum <installation_directory>/bootstrap.ign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ダイジェストは、クラスターノードの Ignition 設定ファイルの信頼性を検証するために、後の手順で
coreos-installer
に提供されます。インストールプログラムが作成したブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
インストールホストから、Ignition 設定ファイルが URL で利用可能であることを確認します。以下の例では、ブートストラップノードの Ignition 設定ファイルを取得します。
curl -k http://<HTTP_server>/bootstrap.ign
$ curl -k http://<HTTP_server>/bootstrap.ign
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドで
bootstrap.ign
をmaster.ign
またはworker.ign
に置き換え、コントロールプレーンおよびコンピュートノードの Ignition 設定ファイルも利用可能であることを検証します。RHCOS イメージのミラー ページから、オペレーティングシステムインスタンスをインストールするための推奨される方法に必要な RHCOS イメージを取得することは可能ですが、RHCOS イメージの正しいバージョンを取得するための推奨される方法は、
openshift-install
コマンドの出力から取得することです。openshift-install coreos print-stream-json | grep '\.iso[^.]'
$ openshift-install coreos print-stream-json | grep '\.iso[^.]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso", "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso", "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso", "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
"location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso", "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso", "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso", "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。この手順には ISO イメージのみを使用します。RHCOS qcow2 イメージは、このインストールではサポートされません。
ISO ファイルの名前は以下の例のようになります。
rhcos-<version>-live.<architecture>.iso
ISO を使用し、RHCOS インストールを開始します。以下のインストールオプションのいずれかを使用します。
- ディスクに ISO イメージを書き込み、これを直接起動します。
- Lights Out Management (LOM) インターフェイスを使用して ISO リダイレクトを使用します。
オプションを指定したり、ライブ起動シーケンスを中断したりせずに、RHCOS ISO イメージを起動します。インストーラーが RHCOS ライブ環境でシェルプロンプトを起動するのを待ちます。
注記RHCOS インストール起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに、以下の手順で説明しているように
coreos-installer
コマンドを使用する必要があります。coreos-installer
コマンドを実行し、インストール要件を満たすオプションを指定します。少なくとも、ノードタイプの Ignition 設定ファイルを参照する URL と、インストール先のデバイスを指定する必要があります。sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ --ignition-hash=sha512-<digest>
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \
1 --ignition-hash=sha512-<digest>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記TLS を使用する HTTPS サーバーを使用して Ignition 設定ファイルを提供する場合は、
coreos-installer
を実行する前に、内部認証局 (CA) をシステムのトラストストアに追加できます。以下の例では、
/dev/sda
デバイスへのブートストラップノードのインストールを初期化します。ブートストラップノードの Ignition 設定ファイルは、IP アドレス 192.168.1.2 で HTTP Web サーバーから取得されます。sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \ --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \ --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシンのコンソールで RHCOS インストールの進捗を監視します。
重要OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
- RHCOS のインストール後、システムを再起動する必要があります。システムの再起動後、指定した Ignition 設定ファイルを適用します。
コンソール出力をチェックして、Ignition が実行されたことを確認します。
コマンドの例
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 継続してクラスターの他のマシンを作成します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、OpenShift Container Platform のインストール前に少なくとも 2 つのコンピュートマシンも作成します。
必要なネットワーク、DNS、およびロードバランサーインフラストラクチャーが配置されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS ノードの再起動後に自動的に起動します。
注記RHCOS ノードには、
core
ユーザーのデフォルトのパスワードは含まれません。ノードには、ssh core@<node>.<cluster_name>.<base_domain>
を、install_config.yaml
ファイルで指定したパブリックキーとペアになる SSH プライベートキーへのアクセスのあるユーザーとして実行してアクセスできます。RHCOS を実行する OpenShift Container Platform 4 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、インストールの問題を調査する際に、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、デバッグまたは障害復旧に SSH アクセスが必要になることがあります。
2.2.16.2. PXE または iPXE ブートを使用した RHCOS のインストール リンクのコピーリンクがクリップボードにコピーされました!
PXE または iPXE ブートを使用してマシンに RHCOS をインストールできます。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- 適切な PXE または iPXE インフラストラクチャーを設定していること。
- お使いのコンピューターからアクセスでき、作成するマシンからもアクセスできる HTTP サーバーがある。
- ネットワークやディスクパーティションなどのさまざまな機能の設定方法について、高度な RHCOS インストール設定 のセクションを確認している。
手順
インストールプログラムが作成したブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
インストールホストから、Ignition 設定ファイルが URL で利用可能であることを確認します。以下の例では、ブートストラップノードの Ignition 設定ファイルを取得します。
curl -k http://<HTTP_server>/bootstrap.ign
$ curl -k http://<HTTP_server>/bootstrap.ign
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドで
bootstrap.ign
をmaster.ign
またはworker.ign
に置き換え、コントロールプレーンおよびコンピュートノードの Ignition 設定ファイルも利用可能であることを検証します。RHCOS イメージミラー ページからオペレーティングシステムインスタンスをインストールするための推奨される方法に必要な RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得することは可能ですが、RHCOS ファイルの正しいバージョンを取得するための推奨される方法は、openshift-install
コマンドの出力から取得することです。openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'
$ openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要RHCOS アーティファクトは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な
kernel
、initramfs
、およびrootfs
アーティファクトのみを使用します。RHCOS QCOW2 イメージは、このインストールタイプではサポートされません。ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。
-
kernel
:rhcos-<version>-live-kernel-<architecture>
-
initramfs
:rhcos-<version>-live-initramfs.<architecture>.img
-
rootfs
:rhcos-<version>-live-rootfs.<architecture>.img
-
rootfs
、kernel
、およびinitramfs
ファイルを HTTP サーバーにアップロードします。重要インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
- RHCOS のインストール後にマシンがローカルディスクから起動されるようにネットワークブートインフラストラクチャーを設定します。
RHCOS イメージの PXE または iPXE インストールを設定し、インストールを開始します。
ご使用の環境に関する以下の例で示されるメニューエントリーのいずれかを変更し、イメージおよび Ignition ファイルが適切にアクセスできることを確認します。
PXE(
x86_64
) の場合:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 1
- HTTP サーバーにアップロードしたライブ
kernel
ファイルの場所を指定します。URL は HTTP、TFTP、または FTP である必要があります。HTTPS および NFS はサポートされません。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
initrd
パラメーター値はinitramfs
ファイルの場所であり、coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所、またcoreos.inst.ignition_url
パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。APPEND
行にカーネル引数を追加して、ネットワークやその他の起動オプションを設定することもできます。
注記この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、
APPEND
行に 1 つ以上のconsole=
引数を追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。iPXE (
x86_64
+aarch64
) の場合:kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img boot
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
1 2 initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img
3 boot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値はkernel
ファイルの場所であり、initrd=main
引数は UEFI システムでの起動に必要であり、coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- HTTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
注記この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、
kernel
行にconsole=
引数を 1 つ以上追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。注記aarch64
アーキテクチャーで CoreOSkernel
をネットワークブートするには、IMAGE_GZIP
オプションが有効になっているバージョンの iPXE ビルドを使用する必要があります。iPXE のIMAGE_GZIP
オプション を参照してください。aarch64
上の PXE (第 2 段階として UEFI と Grub を使用) の場合:menuentry 'Install CoreOS' { linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign initrd rhcos-<version>-live-initramfs.<architecture>.img }
menuentry 'Install CoreOS' { linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
1 2 initrd rhcos-<version>-live-initramfs.<architecture>.img
3 }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- HTTP/TFTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値は、TFTP サーバー上のkernel
ファイルの場所になります。coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値は HTTP サーバー上のブートストラップ Ignition 設定ファイルの場所になります。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- TFTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
マシンのコンソールで RHCOS インストールの進捗を監視します。
重要OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
- RHCOS のインストール後に、システムは再起動します。再起動中、システムは指定した Ignition 設定ファイルを適用します。
コンソール出力をチェックして、Ignition が実行されたことを確認します。
コマンドの例
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのマシンの作成を続行します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、クラスターのインストール前に少なくとも 2 つのコンピュートマシンを作成します。
必要なネットワーク、DNS、およびロードバランサーインフラストラクチャーが配置されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS ノードの再起動後に自動的に起動します。
注記RHCOS ノードには、
core
ユーザーのデフォルトのパスワードは含まれません。ノードには、ssh core@<node>.<cluster_name>.<base_domain>
を、install_config.yaml
ファイルで指定したパブリックキーとペアになる SSH プライベートキーへのアクセスのあるユーザーとして実行してアクセスできます。RHCOS を実行する OpenShift Container Platform 4 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、インストールの問題を調査する際に、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、デバッグまたは障害復旧に SSH アクセスが必要になることがあります。
2.2.16.3. 高度な RHCOS インストール設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 用の Red Hat Enterprise Linux CoreOS (RHCOS) ノードを手動でプロビジョニングする主な利点は、デフォルトの OpenShift Container Platform インストール方法では利用できない設定を実行できることです。このセクションでは、以下のような手法で実行できるいくつかの設定を説明します。
- カーネル引数をライブインストーラーに渡す
-
ライブシステムからの
coreos-installer
の手動による実行 - ライブ ISO または PXE ブートイメージのカスタマイズ
このセクションで説明されている手動の Red Hat Enterprise Linux CoreOS (RHCOS) インストールの高度な設定トピックは、ディスクパーティション設定、ネットワーク、および複数の異なる方法での Ignition 設定の使用に関連しています。
2.2.16.3.1. PXE および ISO インストールの高度なネットワーキングオプションの使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ノードのネットワークはデフォルトで DHCP を使用して、必要な設定をすべて収集します。静的 IP アドレスを設定したり、ボンディングなどの特別な設定を行う場合は、以下のいずれかの方法で実行できます。
- ライブインストーラーの起動時に、特別なカーネルパラメーターを渡します。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
- ライブインストーラーのシェルプロンプトからネットワークを設定し、それらの設定をインストール済みシステムにコピーして、インストール済みシステムの初回起動時に有効になるようにします。
PXE または iPXE インストールを設定するには、以下のオプションのいずれかを使用します。
- 「詳細な RHCOS インストールリファレンスの表」を参照してください。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
ISO インストールを設定するには、以下の手順に従います。
手順
- ISO インストーラーを起動します。
-
ライブシステムシェルプロンプトから、
nmcli
またはnmtui
などの利用可能な RHEL ツールを使用して、ライブシステムのネットワークを設定します。 coreos-installer
コマンドを実行してシステムをインストールし、--copy-network
オプションを追加してネットワーク設定をコピーします。以下に例を示します。sudo coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
$ sudo coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要--copy-network
オプションは、/etc/NetworkManager/system-connections
にあるネットワーク設定のみをコピーします。特に、システムのホスト名はコピーされません。- インストール済みのシステムで再起動します。
2.2.16.3.2. ディスクパーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
ディスクパーティションは、Red Hat Enterprise Linux CoreOS (RHCOS) のインストール時に OpenShift Container Platform クラスターノードに作成されます。デフォルトのパーティション設定をオーバーライドしない限り、特定のアーキテクチャーの各 RHCOS ノードで同じパーティションレイアウトが使用されます。RHCOS のインストール時に、ルートファイルシステムのサイズが拡大し、ターゲットデバイスの残りの使用可能なスペースが使用されます。
ノードでカスタムパーティションスキームを使用すると、OpenShift Container Platform が一部のノードパーティションでモニタリングやアラートを行わなくなる可能性があります。デフォルトのパーティション設定をオーバーライドする場合は、OpenShift Container Platform がホストファイルシステムを監視する方法の詳細について Understanding OpenShift File System Monitoring (eviction conditions) を参照してください。
OpenShift Container Platform は、次の 2 つのファイルシステム識別子を監視します。
-
nodefs
:/var/lib/kubelet
を含むファイルシステム -
imagefs
:/var/lib/containers
を含むファイルシステム
デフォルトのパーティションスキームの場合、nodefs
と imagefs
は同じルートファイルシステム (/
) を監視します。
RHCOS を OpenShift Container Platform クラスターノードにインストールするときにデフォルトのパーティション設定をオーバーライドするには、別のパーティションを作成する必要があります。コンテナーとコンテナーイメージ用に別のストレージパーティションを追加する状況を考えてみましょう。たとえば、/var/lib/containers
を別のパーティションにマウントすると、kubelet が /var/lib/containers
を imagefs
ディレクトリーとして、ルートファイルシステムを nodefs
ディレクトリーとして個別に監視します。
より大きなファイルシステムをホストするためにディスクサイズを変更した場合は、別の /var/lib/containers
パーティションを作成することを検討してください。多数の割り当てグループによって発生する CPU 時間の問題を軽減するには、xfs
形式のディスクのサイズを変更することを検討してください。
2.2.16.3.2.1. 個別の /var パーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
通常は、RHCOS のインストール時に作成されるデフォルトのディスクパーティションを使用する必要があります。ただし、拡張するディレクトリーの個別のパーティションの作成が必要となる場合もあります。
OpenShift Container Platform は、ストレージを /var
ディレクトリーまたは /var
のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
-
/var/lib/containers
: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。 -
/var/lib/etcd
: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。 /var
: 監査などの目的に合わせて分離させる必要のあるデータを保持します。重要ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の
/var
パーティションを作成します。
/var
ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
/var
ディレクトリーまたは /var
のサブディレクトリーの個別のパーティションを使用すると、パーティション設定されたディレクトリーでのデータの増加によりルートファイルシステムが一杯になることを避けることもできます。
以下の手順では、インストールの準備フェーズでノードタイプの Ignition 設定ファイルにラップされるマシン設定マニフェストを追加して、別の /var
パーティションを設定します。
手順
インストールホストで、OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加のパーティションを設定する Butane 設定を作成します。たとえば、
$HOME/clusterconfig/98-var-partition.bu
ファイルに名前を付け、ディスクのデバイス名をworker
システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var
ディレクトリーを別のパーティションにマウントします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小のオフセット値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。オフセット値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、
prjquota
マウントオプションを有効にする必要があります。
注記個別の
/var
パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、コンピュートノードに異なるインスタンスタイプを使用することはできません。Butane config からマニフェストを作成し、
clusterconfig/openshift
ディレクトリーに保存します。たとえば、以下のコマンドを実行します。butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignition 設定ファイルを作成します。
openshift-install create ignition-configs --dir <installation_directory>
$ openshift-install create ignition-configs --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <installation_directory>/manifest
ディレクトリーおよび<installation_directory>/openshift
ディレクトリーのファイルは、98-var-partition
カスタムMachineConfig
オブジェクトが含まれるファイルを含む Ignition 設定ファイルにラップされます。
次のステップ
- RHCOS のインストール時に Ignition 設定ファイルを参照して、カスタムディスクのパーティション設定を適用することができます。
2.2.16.3.2.2. 既存パーティションの保持 リンクのコピーリンクがクリップボードにコピーされました!
ISO インストールの場合は、インストーラーに 1 つ以上の既存パーティションを維持させる coreos-installer
コマンドにオプションを追加することができます。PXE インストールの場合、coreos.inst.*
オプションを APPEND
パラメーターに追加して、パーティションを保持できます。
保存したパーティションは、既存の OpenShift Container Platform システムからのデータパーティションである可能性があります。パーティションラベルまたは番号のいずれかで保持する必要のあるディスクパーティションを特定できます。
既存のパーティションを保存し、それらのパーティションが RHCOS の十分な領域を残さない場合、インストールは失敗します。この場合、保存したパーティションが破損することはありません。
ISO インストール時の既存パーティションの保持
この例では、パーティションラベルが data
(data*
) で始まるパーティションを保持します。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partlabel 'data*' \ /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partlabel 'data*' \
/dev/disk/by-id/scsi-<serial_number>
以下の例では、ディスク上の 6 番目のパーティションを保持する方法で coreos-installer
を実行する方法を説明しています。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partindex 6 /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 6 /dev/disk/by-id/scsi-<serial_number>
この例では、パーティション 5 以上を保持します。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
パーティションの保存が使用された以前の例では、coreos-installer
はパーティションをすぐに再作成します。
PXE インストール時の既存パーティションの保持
この APPEND
オプションは、パーティションラベルが 'data' ('data*') で始まるパーティションを保持します。
coreos.inst.save_partlabel=data*
coreos.inst.save_partlabel=data*
この APPEND
オプションは、パーティション 5 以上を保持します。
coreos.inst.save_partindex=5-
coreos.inst.save_partindex=5-
この APPEND
オプションは、パーティション 6 を保持します。
coreos.inst.save_partindex=6
coreos.inst.save_partindex=6
2.2.16.3.3. Ignition 設定の特定 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS の手動インストールを実行する場合、提供できる Ignition 設定には 2 つのタイプがあり、それぞれを提供する理由もそれぞれ異なります。
Permanent install Ignition config: すべての手動の RHCOS インストールは、
bootstrap.ign
、master.ign
、およびworker.ign
などのopenshift-installer
が生成した Ignition 設定ファイルのいずれかを渡し、インストールを実行する必要があります。重要これらの Ignition 設定ファイルを直接変更することは推奨されません。前述のセクションの例で説明されているように、Ignition 設定ファイルにラップされるマニフェストファイルを更新できます。
PXE インストールの場合、
coreos.inst.ignition_url=
オプションを使用して、APPEND
行に Ignition 設定を渡します。ISO インストールの場合、シェルプロンプトで ISO を起動した後に、--ignition-url=
オプションを指定したcoreos-installer
コマンドラインで Ignition 設定を特定します。いずれの場合も、HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。Live install Ignition config: このタイプは、
coreos-installer
customize
サブコマンドとそのさまざまなオプションを使用して作成できます。この方法では、Ignition 設定はライブインストールメディアに渡され、起動直後に実行され、RHCOS システムがディスクにインストールされる前または後にセットアップタスクを実行します。この方法は、マシン設定を使用して実行できない高度なパーティション設定など、一度の適用後に再度適用する必要のないタスクの実行にのみ使用する必要があります。PXE または ISO ブートの場合、Ignition 設定を作成し、
ignition.config.url=
オプションに対してAPPEND
を実行し、Ignition 設定の場所を特定できます。また、ignition.firstboot ignition.platform.id=metal
も追加する必要があります。追加しない場合は、ignition.config.url
が無視されます。
2.2.16.3.4. デフォルトのコンソール設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 ブートイメージからインストールされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードは、ほとんどの仮想化セットアップおよびベアメタルセットアップに対応するためのデフォルトコンソールを使用します。クラウドおよび仮想化プラットフォームが異なれば、選択したアーキテクチャーに応じて、異なるデフォルト設定が使用される場合があります。ベアメタルインストールではカーネルのデフォルト設定が使用されます。これは通常、グラフィカルコンソールがプライマリーコンソールで、シリアルコンソールが無効になっていることを意味します。
デフォルトのコンソールが特定のハードウェア設定と一致しない場合や、デフォルトのコンソールを調整する必要がある特定のニーズがある場合があります。以下に例を示します。
- デバッグ目的で、コンソールの緊急シェルにアクセスしたいと考えています。
- クラウドプラットフォームは、グラフィカルコンソールへの対話型アクセスを提供しませんが、シリアルコンソールを提供します。
- 複数のコンソールを有効にしたい。
コンソール設定は、ブートイメージから継承されます。これは、既存のクラスター内の新しいノードが、デフォルトのコンソールへの変更の影響を受けないことを意味します。
次の方法で、ベアメタルインストール用にコンソールを設定できます。
-
コマンドラインで手動で
coreos-installer
を使用する。 -
--dest-console
オプションを指定したcoreos-installer iso customize
またはcoreos-installer pxe customize
サブコマンドを使用して、プロセスを自動化するカスタムイメージを作成します。
高度なカスタマイズを行うには、カーネル引数ではなく、coreos-installer iso
または coreos-installer pxe
サブコマンドを使用してコンソール設定を実行します。
2.2.16.3.5. PXE および ISO インストール用のシリアルコンソールの有効化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat Enterprise Linux CoreOS (RHCOS) シリアルコンソールは無効になっており、すべての出力はグラフィカルコンソールに書き込まれます。ISO インストール用にシリアルコンソールを有効にし、シリアルコンソールとグラフィカルコンソールの両方に出力が送信されるようにブートローダーを再設定できます。
手順
- ISO インストーラーを起動します。
coreos-installer
コマンドを実行してシステムをインストールし、--console
オプションを 1 回追加してグラフィカルコンソールを指定し、2 回目にシリアルコンソールを指定します。coreos-installer install \ --console=tty0 \ --console=ttyS0,<options> \ --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer install \ --console=tty0 \
1 --console=ttyS0,<options> \
2 --ignition-url=http://host/worker.ign /dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 2
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。
インストール済みのシステムで再起動します。
注記coreos-installer install --append-karg
オプションを使用し、console=
でコンソールを指定すると、同様の結果が得られます。ただし、これはカーネルのコンソールのみを設定し、ブートローダーは設定しません。
PXE インストールを設定するには、coreos.inst.install_dev
カーネルコマンドラインオプションが省略されていることを確認し、シェルプロンプトを使用して、上記の ISO インストール手順を使用して手動で coreos-installer
を実行します。
2.2.16.3.6. ライブ RHCOS ISO または PXE インストールのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
ライブ ISO イメージまたは PXE 環境を使用して、Ignition 設定ファイルをイメージに直接挿入することで RHCOS をインストールできます。これにより、システムのプロビジョニングに使用できるカスタマイズされたイメージが作成されます。
ISO イメージの場合、これを行うメカニズムは coreos-installer iso customize
サブコマンドです。これは設定に合わせて .iso
ファイルを変更します。同様に、PXE 環境のメカニズムは、カスタマイズを含む新しい initramfs
ファイルを作成する coreos-installer pxe customize
サブコマンドです。
customize
サブコマンドは、他のタイプのカスタマイズも埋め込むことができる汎用ツールです。次のタスクは、より一般的なカスタマイズの例です。
- 企業のセキュリティーポリシーで使う必要がある場合に備えて、カスタム CA 証明書を挿入します。
- カーネル引数を必要とせずにネットワーク設定を設定します。
- 任意のプレインストールおよびポストインストールスクリプトまたはバイナリーを埋め込みます。
2.2.16.3.7. ライブ RHCOS ISO イメージのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
coreos-installer iso customize
サブコマンドを使用して、ライブ RHCOS ISO イメージを直接カスタマイズできます。ISO イメージを起動すると、カスタマイズが自動的に適用されます。
この機能を使用して、RHCOS を自動的にインストールするように ISO イメージを設定できます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページと Ignition 設定ファイルから RHCOS ISO イメージを取得し、次のコマンドを実行して、Ignition 設定を ISO イメージに直接挿入します。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition bootstrap.ign \ --dest-device /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition bootstrap.ign \
1 --dest-device /dev/disk/by-id/scsi-<serial_number>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ISO イメージのカスタマイズを削除し、イメージを元の状態に戻すには、次のコマンドを実行します。
coreos-installer iso reset rhcos-<version>-live.x86_64.iso
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、ライブ ISO イメージを再カスタマイズしたり、元の状態で使用したりできます。
カスタマイズを適用すると、それ以降のすべての RHCOS 起動に影響します。
2.2.16.3.7.1. ライブインストール ISO イメージを変更して、シリアルコンソールを有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 以降でインストールされたクラスターでは、シリアルコンソールはデフォルトで無効になり、すべての出力がグラフィカルコンソールに書き込まれます。次の手順でシリアルコンソールを有効にできます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して ISO イメージをカスタマイズし、シリアルコンソールが出力を受信できるようにします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition <path> \ --dest-console tty0 \ --dest-console ttyS0,<options> \ --dest-device /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition <path> \
1 --dest-console tty0 \
2 --dest-console ttyS0,<options> \
3 --dest-device /dev/disk/by-id/scsi-<serial_number>
4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールする Ignition 設定の場所。
- 2
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 3
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。 - 4
- インストール先として指定されたディスク。このオプションを省略すると、ISO イメージはインストールプログラムを自動的に実行しますが、
coreos.inst.install_dev
カーネル引数も指定しない限り失敗します。
注記--dest-console
オプションは、ライブ ISO システムではなく、インストールされたシステムに影響します。ライブ ISO システムのコンソールを変更するには、--live-karg-append
オプションを使用し、console=
でコンソールを指定します。カスタマイズが適用され、ISO イメージの後続のすべての起動に影響します。
オプション: ISO イメージのカスタマイズを削除してイメージを元の状態に戻すには、次のコマンドを実行します。
coreos-installer iso reset rhcos-<version>-live.x86_64.iso
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ライブ ISO イメージを再カスタマイズするか、元の状態で使用できるようになりました。
2.2.16.3.7.2. カスタム認証局を使用するようにライブインストール ISO イメージを変更する リンクのコピーリンクがクリップボードにコピーされました!
customize
サブコマンドの --ignition-ca
フラグを使用して、認証局 (CA) 証明書を Ignition に提供できます。CA 証明書は、インストールの起動時とインストール済みシステムのプロビジョニング時の両方で使用できます。
カスタム CA 証明書は、Ignition がリモートリソースをフェッチする方法に影響しますが、システムにインストールされている証明書には影響しません。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して、カスタム CA で使用する ISO イメージをカスタマイズします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
coreos.inst.ignition_url
カーネルパラメーターは、--ignition-ca
フラグでは機能しません。クラスターごとにカスタマイズされたイメージを作成するには、--dest-ignition
フラグを使用する必要があります。
カスタム CA 証明書を適用すると、それ以降のすべての RHCOS 起動に影響します。
2.2.16.3.7.3. カスタマイズされたネットワーク設定を使用したライブインストール ISO イメージの変更 リンクのコピーリンクがクリップボードにコピーされました!
NetworkManager キーファイルをライブ ISO イメージに埋め込み、customize
サブコマンドの --network-keyfile
フラグを使用してインストール済みシステムに渡すことができます。
接続プロファイルを作成する際は、接続プロファイルのファイル名に .nmconnection
ファイル名拡張子を使用する必要があります。.nmconnection
ファイル名拡張子を使用しない場合、クラスターは接続プロファイルをライブ環境に適用しますが、クラスターが初めてノードを起動するときに設定が適用されないため、セットアップが機能しなくなります。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 ボンディングされたインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em1.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em2.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して、設定されたネットワークで ISO イメージをカスタマイズします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク設定はライブシステムに適用され、宛先システムに引き継がれます。
2.2.16.3.7.4. iSCSI ブートデバイス用のライブインストール ISO イメージをカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次の情報を使用して ISO イメージをカスタマイズするために、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- 宛先システムの場所。ターゲットポータルの IP アドレス、関連付けられたポート番号、IQN 形式のターゲット iSCSI ノード、および iSCSI 論理ユニット番号 (LUN) を指定する必要があります。
- 4
- 宛先システムの Ignition 設定。
- 5
- IQN 形式の iSCSI イニシエーター、クライアントの名前。イニシエーターは iSCSI ターゲットに接続するセッションを形成します。
- 6
- IQN 形式の iSCSI ターゲットまたはサーバーの名前。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.2.16.3.7.5. iBFT を使用して iSCSI ブートデバイス用のライブインストール ISO イメージをカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次の情報を使用して ISO イメージをカスタマイズするために、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- デバイスへのパス。マルチパスを使用している場合は、マルチパスデバイス (
/dev/mapper/mpatha
) を使用します。複数のマルチパスデバイスが接続されている場合、または明示する場合、/dev/disk/by-path
で使用可能な World Wide Name (WWN) シンボリックリンクを使用できます。 - 4
- 宛先システムの Ignition 設定。
- 5
- iSCSI パラメーターは、BIOS ファームウェアから読み取られます。
- 6
- オプション: マルチパス構成を有効にする場合は、このパラメーターを含めます。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.2.16.3.8. ライブ RHCOS PXE 環境のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
coreos-installer pxe customize
サブコマンドを使用して、ライブ RHCOS PXE 環境を直接カスタマイズできます。PXE 環境を起動すると、カスタマイズが自動的に適用されます。
この機能を使用して、RHCOS を自動的にインストールするように PXE 環境を設定できます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページと Ignition 設定ファイルから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、Ignition 設定からのカスタマイズを含む新しいinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --dest-ignition bootstrap.ign \ --dest-device /dev/disk/by-id/scsi-<serial_number> \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --dest-ignition bootstrap.ign \
1 --dest-device /dev/disk/by-id/scsi-<serial_number> \
2 -o rhcos-<version>-custom-initramfs.x86_64.img
3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
カスタマイズを適用すると、それ以降のすべての RHCOS 起動に影響します。
2.2.16.3.8.1. ライブインストール PXE 環境を変更して、シリアルコンソールを有効化。 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 以降でインストールされたクラスターでは、シリアルコンソールはデフォルトで無効になり、すべての出力がグラフィカルコンソールに書き込まれます。次の手順でシリアルコンソールを有効にできます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページおよび Ignition 設定ファイルから RHCOS
kernel
、initramfs
およびrootfs
ファイルを取得します。次のコマンドを実行して、シリアルコンソールが出力を受信できるようにする新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールする Ignition 設定の場所。
- 2
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 3
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。 - 4
- インストール先として指定されたディスク。このオプションを省略すると、PXE 環境は自動的にインストーラーを実行しますが、
coreos.inst.install_dev
カーネル引数も指定しない限り失敗します。 - 5
- PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。
カスタマイズが適用され、PXE 環境の後続のすべての起動に影響します。
2.2.16.3.8.2. カスタム認証局を使用するようにライブインストール PXE 環境を変更する リンクのコピーリンクがクリップボードにコピーされました!
customize
サブコマンドの --ignition-ca
フラグを使用して、認証局 (CA) 証明書を Ignition に提供できます。CA 証明書は、インストールの起動時とインストール済みシステムのプロビジョニング時の両方で使用できます。
カスタム CA 証明書は、Ignition がリモートリソースをフェッチする方法に影響しますが、システムにインストールされている証明書には影響しません。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、カスタム CA で使用するための新しいカスタマイズされたinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --ignition-ca cert.pem \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --ignition-ca cert.pem \ -o rhcos-<version>-custom-initramfs.x86_64.img
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。
coreos.inst.ignition_url
カーネルパラメーターは、--ignition-ca
フラグでは機能しません。クラスターごとにカスタマイズされたイメージを作成するには、--dest-ignition
フラグを使用する必要があります。
カスタム CA 証明書を適用すると、それ以降のすべての RHCOS 起動に影響します。
2.2.16.3.8.3. カスタマイズされたネットワーク設定を使用したライブインストール PXE 環境の変更 リンクのコピーリンクがクリップボードにコピーされました!
NetworkManager キーファイルをライブ PXE 環境に埋め込み、customize
サブコマンドの --network-keyfile
フラグを使用して、インストール済みシステムに渡すことができます。
接続プロファイルを作成する際は、接続プロファイルのファイル名に .nmconnection
ファイル名拡張子を使用する必要があります。.nmconnection
ファイル名拡張子を使用しない場合、クラスターは接続プロファイルをライブ環境に適用しますが、クラスターが初めてノードを起動するときに設定が適用されないため、セットアップが機能しなくなります。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 ボンディングされたインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em1.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em2.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、設定済みのネットワークを含む新しいカスタマイズされたinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection \ -o rhcos-<version>-custom-initramfs.x86_64.img
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。ネットワーク設定はライブシステムに適用され、宛先システムに引き継がれます。
2.2.16.3.8.4. iSCSI ブートデバイス用のライブインストール PXE 環境をカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、次の情報を含む新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- 宛先システムの場所。ターゲットポータルの IP アドレス、関連付けられたポート番号、IQN 形式のターゲット iSCSI ノード、および iSCSI 論理ユニット番号 (LUN) を指定する必要があります。
- 4
- 宛先システムの Ignition 設定。
- 5
- IQN 形式の iSCSI イニシエーター、クライアントの名前。イニシエーターは iSCSI ターゲットに接続するセッションを形成します。
- 6
- IQN 形式の iSCSI ターゲットまたはサーバーの名前。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.2.16.3.8.5. iBFT を使用して iSCSI ブートデバイス用のライブインストール PXE 環境をカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、次の情報を含む新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- デバイスへのパス。マルチパスを使用している場合は、マルチパスデバイス (
/dev/mapper/mpatha
) を使用します。複数のマルチパスデバイスが接続されている場合、または明示する場合、/dev/disk/by-path
で使用可能な World Wide Name (WWN) シンボリックリンクを使用できます。 - 4
- 宛先システムの Ignition 設定。
- 5
- iSCSI パラメーターは、BIOS ファームウェアから読み取られます。
- 6
- オプション: マルチパス構成を有効にする場合は、このパラメーターを含めます。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.2.16.3.9. 詳細の RHCOS インストールリファレンス リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat Enterprise Linux CoreOS (RHCOS) の手動インストールプロセスを変更できるようにするネットワーク設定および他の高度なオプションを説明します。以下の表では、RHCOS ライブインストーラーおよび coreos-installer
コマンドで使用できるカーネル引数およびコマンドラインのオプションを説明します。
2.2.16.3.9.1. ISO インストールのネットワークおよびボンディングのオプション リンクのコピーリンクがクリップボードにコピーされました!
ISO イメージから RHCOS をインストールする場合、そのイメージを起動してノードのネットワークを設定する際に手動でカーネル引数を追加できます。ネットワークの引数が指定されていない場合、RHCOS が Ignition 設定ファイルを取得するためにネットワークが必要であることを検知する際に、DHCP が initramfs でアクティベートされます。
ネットワーク引数を手動で追加する場合は、rd.neednet=1
カーネル引数を追加して、ネットワークを initramfs で有効にする必要があります。
以下の情報は、ISO インストール用に RHCOS ノードでネットワークおよびボンディングを設定する例を示しています。この例では、ip=
、nameserver=
、および bond=
カーネル引数の使用方法を説明しています。
順序は、カーネル引数の ip=
、nameserver=
、および bond=
を追加する場合に重要です。
ネットワークオプションは、システムの起動時に dracut
ツールに渡されます。dracut
でサポートされるネットワークオプションの詳細は、dracut.cmdline
man ページ を参照してください。
次の例は、ISO インストールのネットワークオプションです。
2.2.16.3.9.1.1. DHCP または静的 IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
IP アドレスを設定するには、DHCP (ip=dhcp
) を使用するか、個別の静的 IP アドレス (ip=<host_ip>
) を設定します。静的 IP を設定する場合、各ノードで DNS サーバー IP アドレス (nameserver=<dns_ip>
) を特定する必要があります。次の例では、以下を設定します。
-
ノードの IP アドレス:
10.10.10.2
-
ゲートウェイアドレス:
10.10.10.254
-
ネットワーク:
255.255.255.0
-
ホスト名:
core0.example.com
-
DNS サーバーアドレス:
4.4.4.41
-
auto-configuration の値を
none
に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none nameserver=4.4.4.41
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41
DHCP を使用して RHCOS マシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP ベースのデプロイメントの場合、DHCP サーバー設定を使用して RHCOS ノードが使用する DNS サーバーアドレスを定義できます。
2.2.16.3.9.1.2. 静的ホスト名を使用しない IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
静的ホスト名を割り当てずに IP アドレスを設定できます。静的ホスト名がユーザーによって設定されていない場合は、逆引き DNS ルックアップによって取得され、自動的に設定されます。静的ホスト名なしで IP アドレスを設定するには、次の例を参照してください。
-
ノードの IP アドレス:
10.10.10.2
-
ゲートウェイアドレス:
10.10.10.254
-
ネットワーク:
255.255.255.0
-
DNS サーバーアドレス:
4.4.4.41
-
auto-configuration の値を
none
に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none nameserver=4.4.4.41
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41
2.2.16.3.9.1.3. 複数のネットワークインターフェイスの指定 リンクのコピーリンクがクリップボードにコピーされました!
複数の ip=
エントリーを設定することで、複数のネットワークインターフェイスを指定できます。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
2.2.16.3.9.1.4. デフォルトゲートウェイとルートの設定 リンクのコピーリンクがクリップボードにコピーされました!
オプション: rd.route=
value を設定して、追加のネットワークへのルートを設定できます。
1 つまたは複数のネットワークを設定する場合、1 つのデフォルトゲートウェイが必要です。追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。
次のコマンドを実行して、デフォルトゲートウェイを設定します。
ip=::10.10.10.254::::
ip=::10.10.10.254::::
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、追加ネットワークのルートを設定します。
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.16.3.9.1.5. 単一インターフェイスでの DHCP の無効化 リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上のネットワークインターフェイスがあり、1 つのインターフェイスのみが使用される場合などに、1 つのインターフェイスで DHCP を無効にします。この例では、enp1s0
インターフェイスには静的ネットワーク設定があり、使用されていない enp2s0
では DHCP が無効になっています。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none ip=::::core0.example.com:enp2s0:none
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none
2.2.16.3.9.1.6. DHCP と静的 IP 設定の組み合わせ リンクのコピーリンクがクリップボードにコピーされました!
以下のように、複数のネットワークインターフェイスを持つシステムで、DHCP および静的 IP 設定を組み合わせることができます。
ip=enp1s0:dhcp ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
2.2.16.3.9.1.7. 個々のインターフェイスでの VLAN の設定 リンクのコピーリンクがクリップボードにコピーされました!
オプション: vlan=
パラメーターを使用して、個別のインターフェイスに VLAN を設定できます。
ネットワークインターフェイスで VLAN を設定し、静的 IP アドレスを使用するには、次のコマンドを実行します。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none vlan=enp2s0.100:enp2s0
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none vlan=enp2s0.100:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスで VLAN を設定し、DHCP を使用するには、次のコマンドを実行します。
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.16.3.9.1.8. 複数の DNS サーバーの指定 リンクのコピーリンクがクリップボードにコピーされました!
以下のように、各サーバーに nameserver=
エントリーを追加して、複数の DNS サーバーを指定できます。
nameserver=1.1.1.1 nameserver=8.8.8.8
nameserver=1.1.1.1
nameserver=8.8.8.8
2.2.16.3.9.1.9. 複数のネットワークインターフェイスの単一インターフェイスへのボンディング リンクのコピーリンクがクリップボードにコピーされました!
オプション: bond=
オプションを使用して、複数のネットワークインターフェイスを単一のインターフェイスにボンディングできます。次の例を参照してください。
ボンディングされたインターフェイスを設定するための構文は、
bond=<name>[:<network_interfaces>][:options]
です。<name>
はボンディングデバイス名 (bond0
)、<network_interfaces>
は物理 (イーサネット) インターフェイスのコンマ区切りのリスト (em1,em2
) を表し、options はボンディングオプションのコンマ区切りのリストです。modinfo bonding
を入力して、利用可能なオプションを表示します。bond=
を使用してボンディングされたインターフェイスを作成する場合は、ボンディングされたインターフェイスの IP アドレスの割り当て方法やその他の情報を指定する必要があります。DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを
dhcp
に設定します。以下に例を示します。bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:em1,em2:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
bond=bond0:em1,em2:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.16.3.9.1.10. 複数の SR-IOV ネットワークインターフェイスをデュアルポート NIC インターフェイスに結合する リンクのコピーリンクがクリップボードにコピーされました!
オプション: bond=
オプションを使用して、複数の SR-IOV ネットワークインターフェイスをデュアルポート NIC インターフェイスに結合できます。
各ノードで、次のタスクを実行する必要があります。
- SR-IOV デバイスの管理 のガイダンスに従って、SR-IOV 仮想機能 (VF) を作成します。「仮想マシンへの SR-IOV ネットワークデバイスの接続」セクションの手順に従います。
- ボンドを作成し、目的の VF をボンドに接続し、ネットワークボンディングの設定 のガイダンスに従って、ボンドリンクの状態を設定します。説明されている手順のいずれかに従って、結合を作成します。
次の例は、使用する必要がある構文を示しています。
結合インターフェイスを設定するための構文は、
bond=<name>[:<network_interfaces>][:options]
です。<name>
はボンディングデバイス名 (bond0
)、<network_interfaces>
は仮想機能 (VF) をカーネル内の既知の名前で表し、ip link
コマンド (eno1f0
、eno2f0
) の出力に表示されます。options は結合オプションのコンマ区切りリストです。modinfo bonding
を入力して、利用可能なオプションを表示します。bond=
を使用してボンディングされたインターフェイスを作成する場合は、ボンディングされたインターフェイスの IP アドレスの割り当て方法やその他の情報を指定する必要があります。DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを
dhcp
に設定します。以下に例を示します。bond=bond0:eno1f0,eno2f0:mode=active-backup ip=bond0:dhcp
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=bond0:dhcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.16.3.9.1.11. ネットワークチーミングの使用 リンクのコピーリンクがクリップボードにコピーされました!
任意: team=
パラメーターを指定して、ボンディングの代わりにネットワークチーミングを使用できます。
チームインターフェイス設定の構文は
team=name[:network_interfaces]
です。name はチームデバイス名 (
team0
)、network_interfaces は物理 (イーサネット) インターフェイス (em1, em2
) のコンマ区切りリストを表します。
RHCOS が次のバージョンの RHEL に切り替わると、チーミングは非推奨になる予定です。詳細は、こちらの Red Hat ナレッジベース記事 を参照してください。
次の例を使用して、ネットワークチームを設定します。
team=team0:em1,em2 ip=team0:dhcp
team=team0:em1,em2
ip=team0:dhcp
2.2.16.3.9.2. ISO および PXE インストール用の coreos-installer オプション リンクのコピーリンクがクリップボードにコピーされました!
RHCOS は、ISO イメージから RHCOS ライブ環境に起動した後に、コマンドプロンプトで coreos-installer install <options> <device>
を実行してインストールできます。
以下の表は、coreos-installer
コマンドに渡すことのできるサブコマンド、オプションおよび引数を示しています。
coreos-installer install サブコマンド | |
サブコマンド | 説明 |
| Ignition 設定を ISO イメージに埋め込みます。 |
coreos-installer install サブコマンドオプション | |
オプション | 説明 |
| イメージの URL を手動で指定します。 |
| ローカルイメージファイルを手動で指定します。デバッグに使用されます。 |
| ファイルから Ignition 設定を埋め込みます。 |
| URL から Ignition 設定を埋め込みます。 |
|
Ignition 設定の |
| インストール済みシステムの Ignition プラットフォーム ID を上書きします。 |
|
インストールされたシステムのカーネルとブートローダーコンソールを設定します。 |
| インストール済みシステムにデフォルトのカーネル引数を追加します。 |
| インストール済みシステムからデフォルトのカーネル引数を削除します。 |
| インストール環境からネットワーク設定をコピーします。 重要
|
|
|
| このラベル glob でパーティションを保存します。 |
| この数または範囲でパーティションを保存します。 |
| RHCOS イメージ署名の検証を省略します。 |
| HTTPS またはハッシュなしで Ignition URL を許可します。 |
|
ターゲット CPU アーキテクチャー。有効な値は |
| エラー時のパーティションテーブルは消去しないでください。 |
| ヘルプ情報を表示します。 |
coreos-installer インストールサブコマンド引数 | |
引数 | 説明 |
| 宛先デバイス。 |
coreos-installer ISO サブコマンド | |
サブコマンド | 説明 |
| RHCOS ライブ ISO イメージをカスタマイズします。 |
| RHCOS ライブ ISO イメージをデフォルト設定に復元します。 |
| ISO イメージから埋め込まれた Ignition 設定を削除します。 |
coreos-installer ISO カスタマイズサブコマンドオプション | |
オプション | 説明 |
| 指定された Ignition 設定ファイルを宛先システムの新しい設定フラグメントにマージします。 |
| 宛先システムのカーネルとブートローダーコンソールを指定します。 |
| 指定した宛先デバイスをインストールして上書きします。 |
| 宛先システムの各起動にカーネル引数を追加します。 |
| 宛先システムの各起動からカーネル引数を削除します。 |
| ライブシステムと宛先システムに指定された NetworkManager キーファイルを使用してネットワークを設定します。 |
| Ignition によって信頼される追加の TLS 認証局を指定します。 |
| インストールする前に、指定されたスクリプトを実行します。 |
| インストール後に指定されたスクリプトを実行します。 |
| 指定されたインストーラー設定ファイルを適用します。 |
| 指定された Ignition 設定ファイルをライブ環境の新しい設定フラグメントにマージします。 |
| ライブ環境の各ブートにカーネル引数を追加します。 |
| ライブ環境の各ブートからカーネル引数を削除します。 |
|
ライブ環境の各起動で、 |
| 既存の Ignition 設定を上書きします。 |
| 新しい出力ファイルに ISO を書き込みます。 |
| ヘルプ情報を表示します。 |
coreos-installer PXE サブコマンド | |
サブコマンド | 説明 |
これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。 | |
| RHCOS ライブ PXE ブート設定をカスタマイズします。 |
| イメージに Ignition 設定をラップします。 |
| イメージでラップされた Ignition 設定を表示します。 |
coreos-installer PXE はサブコマンドオプションをカスタマイズします | |
オプション | 説明 |
これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。 | |
| 指定された Ignition 設定ファイルを宛先システムの新しい設定フラグメントにマージします。 |
| 宛先システムのカーネルとブートローダーコンソールを指定します。 |
| 指定した宛先デバイスをインストールして上書きします。 |
| ライブシステムと宛先システムに指定された NetworkManager キーファイルを使用してネットワークを設定します。 |
| Ignition によって信頼される追加の TLS 認証局を指定します。 |
| インストールする前に、指定されたスクリプトを実行します。 |
| インストール後に指定されたスクリプトを実行します。 |
| 指定されたインストーラー設定ファイルを適用します。 |
| 指定された Ignition 設定ファイルをライブ環境の新しい設定フラグメントにマージします。 |
| initramfs を新しい出力ファイルに書き込みます。 注記 このオプションは、PXE 環境に必要です。 |
| ヘルプ情報を表示します。 |
2.2.16.3.9.3. ISO または PXE インストールの coreos.inst ブートオプション リンクのコピーリンクがクリップボードにコピーされました!
coreos.inst
ブートパラメーターを RHCOS ライブインストーラーに渡して、ブート時に coreos-installer
オプションを自動的に起動できます。これらは、標準のブート引数の追加として提供されます。
-
ISO インストールの場合、ブートローダーメニューで自動ブートを中断して
coreos.inst
オプションを追加できます。RHEL CoreOS (Live) メニューオプションが強調表示されている状態でTAB
を押すと、自動ブートを中断できます。 -
PXE または iPXE インストールの場合、RHCOS ライブインストーラーのブート前に
coreos.inst
オプションをAPPEND
行に追加する必要があります。
以下の表は、ISO および PXE インストールの RHCOS ライブインストーラーの coreos.inst
ブートオプションを示しています。
引数 | 説明 |
---|---|
| 必須。インストール先のシステムのブロックデバイス。 注記
|
| オプション: インストール済みシステムに埋め込む Ignition 設定の URL。URL が指定されていない場合、Ignition 設定は埋め込まれません。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 |
| オプション: インストール時に保存するパーティションのコンマ区切りのラベル。glob 形式のワイルドカードが許可されます。指定したパーティションは存在する必要はありません。 |
|
オプション: インストール時に保存するパーティションのコンマ区切りのインデックス。範囲 |
|
オプション: |
| オプション: 指定した RHCOS イメージをダウンロードし、インストールします。
|
| オプション: システムはインストール後に再起動しません。インストールが完了するとプロンプトが表示され、インストール時に生じる内容を検査できます。この引数は実稼働環境では使用できず、デバッグの目的でのみ使用することが意図されています。 |
|
オプション: RHCOS イメージがインストールされるプラットフォームの Ignition プラットフォーム ID。デフォルトは |
|
オプション: ライブ起動の Ignition 設定の URL。たとえば、これは |
2.2.16.4. RHCOS のカーネル引数でのマルチパスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS はプライマリーディスクでのマルチパスをサポートするようになり、ハードウェア障害に対する対障害性が強化され、ホストの可用性を強化できるようになりました。
OpenShift Container Platform 4.8 以降でプロビジョニングされたノードのマルチパスを有効にできます。インストール後のサポートは、マシン設定を使用してマルチパスをアクティベートすることで利用できますが、インストール中にマルチパスを有効にすることが推奨されます。
非最適化パスに対して I/O があると、I/O システムエラーが発生するように設定するには、インストール時にマルチパスを有効にする必要があります。
IBM Z® および IBM® LinuxONE では、インストール時にクラスターを設定した場合のみマルチパスを有効にできます。詳細は、IBM Z® および IBM® LinuxONE への z/VM を使用したクラスターのインストール の RHCOS の「インストールおよび OpenShift Container Platform ブートストラッププロセスの開始」を参照してください。
以下の手順では、インストール時にマルチパスを有効にし、coreos-installer install
コマンドにカーネル引数を追加して、インストール済みシステム自体が初回起動からマルチパスを使用できるようにします。
OpenShift Container Platform は、4.6 以前からアップグレードされたノードでの day-2 アクティビティーとしてのマルチパスの有効化をサポートしません。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 を確認した。
手順
マルチパスを有効にして
multipathd
デーモンを起動するには、インストールホストで次のコマンドを実行します。mpathconf --enable && systemctl start multipathd.service
$ mpathconf --enable && systemctl start multipathd.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
必要に応じて、PXE または ISO を起動する場合は、カーネルコマンドラインから
rd.multipath=default
を追加することで、マルチパスを有効にできます。
-
必要に応じて、PXE または ISO を起動する場合は、カーネルコマンドラインから
coreos-installer
プログラムを呼び出してカーネル引数を追加します。マシンに接続されているマルチパスデバイスが 1 つしかない場合は、このデバイスは
/dev/mapper/mpatha
のパスで利用できます。以下に例を示します。coreos-installer install /dev/mapper/mpatha \ --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
$ coreos-installer install /dev/mapper/mpatha \
1 --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 1 つのマルチパスデバイスのパスを指定します。
複数のマルチパスデバイスがマシンに接続している場合には、より明示的に
/dev/mapper/mpatha
を使用する代わりに、/dev/disk/by-id
で利用可能な World Wide Name (WWN) シンボリックリンクを使用することが推奨されます。以下に例を示します。coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \ --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
$ coreos-installer install /dev/disk/by-id/wwn-<wwn_ID> \
1 --ignition-url=http://host/worker.ign \ --append-karg rd.multipath=default \ --append-karg root=/dev/disk/by-label/dm-mpath-root \ --append-karg rw
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マルチパス化されたデバイスの WWN ID を指定します。例:
0xx194e957fcedb4841
特別な
coreos.inst.*
引数を使用してライブインストーラーを指定する場合に、このシンボリックリンクをcoreos.inst.install_dev
カーネル引数として使用することもできます。詳細は、「RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始」を参照してください。
- インストール済みのシステムで再起動します。
ワーカーノードのいずれかに移動し、(ホストの
/proc/cmdline
内の) カーネルコマンドライン引数をリスト表示して、カーネル引数が機能していることを確認します。oc debug node/ip-10-0-141-105.ec2.internal
$ oc debug node/ip-10-0-141-105.ec2.internal
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加したカーネル引数が表示されるはずです。
2.2.16.4.1. セカンダリーディスクでのマルチパス構成の有効化 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS はセカンダリーディスク上のマルチパス構成もサポートします。カーネル引数の代わりに、Ignition を使用してインストール時にセカンダリーディスクのマルチパス構成を有効にします。
前提条件
- ディスクのパーティション設定 セクションを読了した。
- RHCOS のカーネル引数でのマルチパスの有効化 を読了した。
- Butane ユーティリティーをインストールした。
手順
次のような情報を含む Butane 設定を作成します。
multipath-config.bu
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Ignition 設定を作成します。
butane --pretty --strict multipath-config.bu > multipath-config.ign
$ butane --pretty --strict multipath-config.bu > multipath-config.ign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 初回起動時の RHCOS インストールプロセスの残りを続行します。
重要プライマリーディスクもマルチパス化されていない限り、インストール中にコマンドラインに
rd.multipath
またはroot
カーネル引数を追加しないでください。
2.2.16.5. iSCSI ブートデバイスに RHCOS を手動でインストールする リンクのコピーリンクがクリップボードにコピーされました!
iSCSI ターゲットに、手動で RHCOS をインストールできます。
前提条件
- RHCOS ライブ環境にいる。
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
次のコマンドを実行して、ライブ環境から iSCSI ターゲットをマウントします。
iscsiadm \ --mode discovery \ --type sendtargets
$ iscsiadm \ --mode discovery \ --type sendtargets --portal <IP_address> \
1 --login
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ターゲットポータルの IP アドレス。
次のコマンドを実行し、必要なカーネル引数を使用して、RHCOS を iSCSI ターゲットにインストールします。以下はその例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。次のコマンドを実行して iSCSI ディスクをアンマウントします。
iscsiadm --mode node --logoutall=all
$ iscsiadm --mode node --logoutall=all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順は、coreos-installer iso customize
または coreos-installer pxe customize
サブコマンドを使用して実行することもできます。
2.2.16.6. iBFT を使用して iSCSI ブートデバイスに RHCOS をインストールする リンクのコピーリンクがクリップボードにコピーされました!
完全にディスクレスなマシンでは、iSCSI ターゲットとイニシエーターの値を iBFT 経由で渡すことができます。iSCSI マルチパス構成もサポートされています。
前提条件
- RHCOS ライブ環境にいる。
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
次のコマンドを実行して、ライブ環境から iSCSI ターゲットをマウントします。
iscsiadm \ --mode discovery \ --type sendtargets
$ iscsiadm \ --mode discovery \ --type sendtargets --portal <IP_address> \
1 --login
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ターゲットポータルの IP アドレス。
オプション: マルチパス構成を有効にし、次のコマンドでデーモンを起動します。
mpathconf --enable && systemctl start multipathd.service
$ mpathconf --enable && systemctl start multipathd.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、必要なカーネル引数を使用して、RHCOS を iSCSI ターゲットにインストールします。以下はその例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。iSCSI ディスクをアンマウントします。
iscsiadm --mode node --logout=all
$ iscsiadm --mode node --logout=all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順は、coreos-installer iso customize
または coreos-installer pxe customize
サブコマンドを使用して実行することもできます。
2.2.17. ブートストラッププロセスの完了まで待機する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
- RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
- お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。
手順
ブートストラッププロセスをモニターします。
./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ --log-level=info
$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \
1 --log-level=info
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.32.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.32.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。
2.2.18. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、
kubeadmin
認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
次のコマンドを実行し、エクスポートされた設定を使用して
oc
コマンドを正常に実行できることを確認します。oc whoami
$ oc whoami
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.19. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.32.3 master-1 Ready master 63m v1.32.3 master-2 Ready master 64m v1.32.3
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.32.3 master-1 Ready master 63m v1.32.3 master-2 Ready master 64m v1.32.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
Pending
またはApproved
ステータスが表示されていることを確認します。oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りの CSR が承認されず、それらが
Pending
ステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
2.2.20. Operator の初期設定 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。
前提条件
- コントロールプレーンが初期化されています。
手順
クラスターコンポーネントがオンラインになることを確認します。
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 利用不可の Operator を設定します。
2.2.20.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
2.2.20.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
2.2.20.3. ベアメタルの場合のブロックレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
イメージレジストリーがクラスター管理者によるアップグレード時にブロックストレージタイプを使用できるようにするには、Recreate
ロールアウトストラテジーを使用できます。
ブロックストレージボリューム (または永続ボリューム) はサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。
イメージレジストリーでブロックストレージボリュームを使用することを選択した場合は、ファイルシステムの persistent volume claim (PVC) を使用する必要があります。
手順
次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して
Recreate
ロールアウトストラテジーを使用し、1 つの (1
) レプリカのみで実行されるようにします。oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。
以下の内容で
pvc.yaml
ファイルを作成して VMware vSpherePersistentVolumeClaim
オブジェクトを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ファイルから
PersistentVolumeClaim
オブジェクトを作成します。oc create -f pvc.yaml -n openshift-image-registry
$ oc create -f pvc.yaml -n openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。
oc edit config.imageregistry.operator.openshift.io -o yaml
$ oc edit config.imageregistry.operator.openshift.io -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
storage: pvc: claim:
storage: pvc: claim:
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- カスタム PVC を作成することにより、
image-registry-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
2.2.21. user-provisioned infrastructure でのインストールの完了 リンクのコピーリンクがクリップボードにコピーされました!
Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。
前提条件
- コントロールプレーンが初期化されています。
- Operator の初期設定を完了済みです。
手順
以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。
./openshift-install --dir <installation_directory> wait-for install-complete
$ ./openshift-install --dir <installation_directory> wait-for install-complete
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
出力例
INFO Waiting up to 30m0s for the cluster to initialize...
INFO Waiting up to 30m0s for the cluster to initialize...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
Kubernetes API サーバーが Pod と通信していることを確認します。
すべての Pod のリストを表示するには、以下のコマンドを使用します。
oc get pods --all-namespaces
$ oc get pods --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。
oc logs <pod_name> -n <namespace>
$ oc logs <pod_name> -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前のコマンドの出力にあるように、Pod 名および namespace を指定します。
Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。
FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。
詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。
2.2.22. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
2.2.23. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- インストールの検証
- クラスターのカスタマイズ
- 必要に応じて、リモートヘルスレポート を作成できます。
- レジストリーをセットアップし、レジストリーストレージを設定 します。
2.3. 非接続環境でのユーザープロビジョニング型ベアメタルクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、制限されたネットワーク内で独自にプロビジョニングするベアメタルインフラストラクチャーに、クラスターをインストールできます。
以下の手順に従って仮想化環境またはクラウド環境にクラスターをデプロイすることができますが、ベアメタルプラットフォーム以外の場合は追加の考慮事項に注意してください。このような環境に OpenShift Container Platform クラスターをインストールする前に、guidelines for deploying OpenShift Container Platform on non-tested platforms の情報を確認してください。
2.3.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
ミラーホストにレジストリーを作成 し、使用しているバージョンの OpenShift Container Platform の
imageContentSources
データを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
- クラスターの 永続ストレージ をプロビジョニングしている。プライベートイメージレジストリーをデプロイするには、ストレージで ReadWriteMany アクセスモードを指定する必要があります。
クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 した (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
2.3.2. ネットワークが制限された環境でのインストールについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、installer-provisioned infrastructure または user-provisioned infrastructure を使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
user-provisioned installation の設定は複雑であるため、user-provisioned infrastructure を使用してネットワークが制限されたインストールを試行する前に、標準的な user-provisioned infrastructure を実行することを検討してください。このテストが完了すると、ネットワークが制限されたインストール時に発生する可能性のある問題の切り分けやトラブルシューティングがより容易になります。
2.3.2.1. その他の制限 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersion
ステータスにはUnable to retrieve available updates
エラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
2.3.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。
次のアクションを実行するには、インターネットにアクセスできる必要があります。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターがインターネットにアクセスでき、Telemetry を無効にしていない場合、そのサービスによってクラスターのサブスクリプションが自動的に有効化されます。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
2.3.4. user-provisioned infrastructure を使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
2.3.4.1. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
ホスト | 説明 |
---|---|
1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
例外として、ゼロ (0) コンピュートマシンを 3 つのコントロールプレーンマシンのみで構成されるベアメタルクラスターで実行できます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。1 つのコンピュートマシンの実行はサポートされていません。
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 以降から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 9.2 をベースとしており、そのハードウェア認定および要件がすべて継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
2.3.4.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | CPU [1] | RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
---|---|---|---|---|---|
ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 つの CPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、(コアごとのスレッド x コア数) x ソケット数 = CPU という数式を使用して対応する比率を計算します。
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピュートマシンの使用は非推奨となり、OpenShift Container Platform 4.10 以降で削除されています。
OpenShift Container Platform バージョン 4.19 の場合、RHCOS は RHEL バージョン 9.6 に基づいています。これは、マイクロアーキテクチャー要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、アーキテクチャー (RHEL ドキュメント) を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
2.3.4.3. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求されるサービング証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
2.3.4.4. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルを取得する必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
- クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
- DHCP サービスが user-provisioned infrastructure で利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
2.3.4.4.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
2.3.4.4.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。ポート | |
| Kubernetes が予約するデフォルトポート | |
| このポートは、マシン設定サーバーからのトラフィックを処理し、トラフィックをコントロールプレーンマシンに送信します。 | |
UDP |
| VXLAN |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
|
UDP ポート | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
2.3.4.4.3. user-provisioned infrastructure の NTP 設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
2.3.4.5. user-provisioned DNS 要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード
- ブートストラップ、コントロールプレーンおよびコンピュートマシン
また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。
DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。
各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。詳細は、user-provisioned infrastructure に関する DHCP の推奨事項 のセクションを参照してください。
以下の DNS レコードは、user-provisioned OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、install-config.yaml
ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
ルート |
| アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
ブートストラップマシン |
| ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コントロールプレーンマシン |
| コントロールプレーンノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コンピュートマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。
dig
コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
2.3.4.5.1. user-provisioned クラスターの DNS 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4
で、ベースドメインは example.com
です。
user-provisioned クラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、user-provisioned クラスターの名前解決の A レコードの例を示しています。
例2.7 DNS ゾーンデータベースのサンプル
- 1
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
- 2
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
- 3
- ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
- 4
- ブートストラップマシンの名前解決を提供します。
- 5 6 7
- コントロールプレーンマシンの名前解決を提供します。
- 8 9
- コンピュートマシンの名前解決を提供します。
user-provisioned クラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、user-provisioned クラスターの逆引き名前解決の PTR レコードの例を示しています。
例2.8 逆引きレコードの DNS ゾーンデータベースの例
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
2.3.4.6. user-provisioned infrastructure の負荷分散要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーション Ingress ロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表2.37 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとのプロービングで、2 回連続成功すると正常、3 回連続失敗すると異常と判断する設定は、十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。
以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表2.38 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
2.3.4.6.1. user-provisioned クラスターのロードバランサーの設定例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned クラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg
設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing
に設定されている場合は、setsebool -P haproxy_connect_any=1
を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
例2.9 API およびアプリケーション Ingress ロードバランサーの設定例
- 1
- ポート
6443
は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 2 4
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 3
- ポート
22623
はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 5
- ポート
443
は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 6
- ポート
80
は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe
を実行して、ポート 6443
、22623
、443
、および 80
で haproxy
プロセスがリッスンしていることを確認することができます。
2.3.5. カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
configure-ovs.sh
シェルスクリプトを使用してベアメタルプラットフォームで br-ex
ブリッジを設定する代わりに、NMState 設定ファイルを含む MachineConfig
オブジェクトを作成できます。ホスト nmstate-configuration.service
および nmstate.service
により、クラスター内で実行される各ノードに NMState 設定ファイルが適用されます。
カスタマイズされた br-ex
ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。
-
Open vSwitch (OVS) または OVN-Kubernetes
br-ex
ブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.sh
シェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。 - ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
-
configure-ovs.sh
シェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。
単一のネットワークインターフェイスコントローラー (NIC) とデフォルトのネットワーク設定を備えた環境が必要な場合は、configure-ovs.sh
シェルスクリプトを使用します。
Red Hat Enterprise Linux CoreOS (RHCOS) をインストールしてシステムを再起動すると、Machine Config Operator がクラスター内の各ノードに Ignition 設定ファイルを注入し、各ノードが br-ex
ブリッジネットワーク設定を受け取るようになります。設定の競合を防ぐために、configure-ovs.sh
シェルスクリプトは、br-ex
ブリッジを設定しない信号を受け取ります。
次のインターフェイス名は予約されており、NMstate 設定では使用できません。
-
br-ext
-
br-int
-
br-local
-
br-nexthop
-
br0
-
ext-vxlan
-
ext
-
genev_sys_*
-
int
-
k8s-*
-
ovn-k8s-*
-
patch-br-*
-
tun0
-
vxlan_sys_*
前提条件
-
オプション: NMState 設定を検証できるように、
nmstate
API をインストールしました。
手順
カスタマイズされた
br-ex
ブリッジネットワークの base64 情報をデコードした NMState 設定ファイルを作成します。カスタマイズされた
br-ex
ブリッジネットワークの NMState 設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat
コマンドを使用して、NMState 設定の内容を base64 でエンコードします。cat <nmstate_configuration>.yaml | base64
$ cat <nmstate_configuration>.yaml | base64
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nmstate_configuration>
を NMState リソース YAML ファイルの名前に置き換えます。
MachineConfig
マニフェストファイルを作成し、次の例に類似したカスタマイズされたbr-ex
ブリッジネットワーク設定を定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のすべてのノードに適用する単一のグローバル設定が
/etc/nmstate/openshift/cluster.yml
設定ファイルで指定されている場合は、各ノードの短いホスト名パス (例:/etc/nmstate/openshift/<node_hostname>.yml
) を指定する必要はありません。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
-
コンピュートノードをスケーリングして、クラスター内に存在する各コンピュートノードに、カスタマイズされた
br-ex
ブリッジを含むマニフェストオブジェクトを適用します。詳細は、関連情報 セクションの「クラスターの拡張」を参照してください。
2.3.5.1. 各マシンセットをコンピュートノードにスケーリング リンクのコピーリンクがクリップボードにコピーされました!
カスタマイズされた br-ex
ブリッジ設定を OpenShift Container Platform クラスター内のすべてのコンピュートノードに適用するには、MachineConfig
カスタムリソース (CR) を編集し、そのロールを変更する必要があります。さらに、ホスト名、認証情報など、ベアメタルマシンの情報を定義する BareMetalHost
CR を作成する必要があります。
これらのリソースを設定した後、マシンセットをスケーリングして、マシンセットが各コンピュートノードにリソース設定を適用し、ノードを再起動できるようにする必要があります。
前提条件
-
カスタマイズされた
br-ex
ブリッジ設定を含むMachineConfig
マニフェストオブジェクトを作成しました。
手順
次のコマンドを入力して
MachineConfig
CR を編集します。oc edit mc <machineconfig_custom_resource_name>
$ oc edit mc <machineconfig_custom_resource_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 各コンピュートノード設定を CR に追加して、CR がクラスター内の定義済みコンピュートノードごとにロールを管理できるようにします。
-
最小限の静的 IP 設定を持つ
extraworker-secret
という名前のSecret
オブジェクトを作成します。 次のコマンドを入力して、クラスター内の各ノードに
extraworker-secret
シークレットを適用します。このステップでは、各コンピュートノードに Ignition 設定ファイルへのアクセスを提供します。oc apply -f ./extraworker-secret.yaml
$ oc apply -f ./extraworker-secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BareMetalHost
リソースを作成し、preprovisioningNetworkDataName
パラメーターでネットワークシークレットを指定します。ネットワークシークレットが添付された
BareMetalHost
リソースの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの
openshift-machine-api
namespace 内でBareMetalHost
オブジェクトを管理するために、次のコマンドを入力して namespace に変更します。oc project openshift-machine-api
$ oc project openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシンセットを取得します。
oc get machinesets
$ oc get machinesets
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各マシンセットをスケールします。このコマンドはマシンセットごとに実行する必要があります。
oc scale machineset <machineset_name> --replicas=<n>
$ oc scale machineset <machineset_name> --replicas=<n>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<machineset_name>
はマシンセットの名前です。<n>
はコンピュートノードの数です。
2.3.6. クラスターで OVS balance-slb モードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上の物理インターフェイスがネットワークトラフィックを共有できるように、Open vSwitch (OVS) の balance-slb
モードを有効にできます。balance-slb
モードのインターフェイスは、ネットワークスイッチとのソースロードバランシングを必要とせずに、仮想化ワークロードを実行するクラスターにソース負荷分散 (SLB) 機能を提供できます。
現在、ソースロードバランシングはボンディングインターフェイスで実行されます。このインターフェイスは br-phy
などの補助ブリッジに接続します。ソースロードバランシングは、Media Access Control (MAC) アドレスと仮想ローカルエリアネットワーク (VLAN) の組み合わせが複数存在する場合にのみ、負荷分散を行います。OVN-Kubernetes Pod のトラフィックはすべて同じ MAC アドレスと VLAN を使用するため、このトラフィックを多数の物理インターフェイス間で負荷分散することはできないことに注意してください。
次の図は、単純なクラスターインフラストラクチャーレイアウトでの balance-slb
モードを示しています。仮想マシン (VM) は、特定の localnet NetworkAttachmentDefinition
(NAD) カスタムリソース定義 (CRD)、NAD 0
または NAD 1
に接続します。各 NAD は、仮想マシンに基盤となる物理ネットワークへのアクセスを提供し、タグ付きまたはタグなしの VLAN トラフィックをサポートしています。br-ex
OVS ブリッジは仮想マシンからのトラフィックを受信し、そのトラフィックを次の OVS ブリッジである br-phy
に渡します。br-phy
ブリッジは SLB ボンディングのコントローラーとして機能します。SLB ボンディングは、eno0
や eno1
などの物理インターフェイスリンクを介して、異なる仮想マシンポートからのトラフィックを分散します。さらに、どちらの物理インターフェイスからの Ingress トラフィックも、OVS ブリッジのセットを通過して仮想マシンに到達できます。
図2.3 2 つの NAD を持つローカルネット上で動作する OVS balance-slb
モード
OVS ボンディングを使用して、balance-slb
モードインターフェイスをプライマリーまたはセカンダリーネットワークタイプに統合できます。OVS ボンディングでは、次の点に注意してください。
- OVN-Kubernetes CNI プラグインをサポートし、プラグインと簡単に統合できます。
-
ネイティブで
balance-slb
モードをサポートします。
前提条件
-
プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを
MachineConfig
ファイルで定義した。 -
マニフェストオブジェクトを作成し、カスタマイズした
br-ex
ブリッジをオブジェクト設定ファイルで定義した。 - プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを NAD CRD ファイルで定義した。
手順
クラスター内に存在するベアメタルホストごとに、クラスターの
install-config.yaml
ファイルで、次の例のようにnetworkConfig
セクションを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow NMState 設定ファイルで各ネットワークインターフェイスを定義します。
多数のネットワークインターフェイスを定義する NMState 設定ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ボンディングポートの
br-ex
MTU を手動で設定します。
base64
コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。base64 -w0 <nmstate_configuration>.yml
$ base64 -w0 <nmstate_configuration>.yml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
-w0
オプションは、base64 エンコード操作中に行の折り返しを防止します。
master
ロールとworker
ロールのMachineConfig
マニフェストファイルを作成します。前のコマンドからの base64 エンコード文字列を各MachineConfig
マニフェストファイルに必ず埋め込んでください。次のマニフェストファイルの例では、クラスター内に存在するすべてのノードに対してmaster
ロールを設定します。ノード固有のmaster
ロールとworker
ロールのマニフェストファイルを作成することもできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各
MachineConfig
マニフェストファイルを./<installation_directory>/manifests
ディレクトリーに保存します。<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーです。Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。
2.3.7. user-provisioned infrastructure の準備 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。
このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。
準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。
前提条件
- OpenShift Container Platform 4.x のテスト済みインテグレーション を確認している。
- user-provisioned infrastructure を使用したクラスターの要件 で説明されているインフラストラクチャーの要件を確認している。
手順
DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。
- ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。
DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。
注記DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項の詳細は、DHCP を使用したクラスターノードのホスト名の設定 セクションを参照してください。
注記DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。
- ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
重要デフォルトで、ポート
1936
は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。
クラスターに必要な DNS インフラストラクチャーを設定します。
- Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。
OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。
DNS 設定を検証します。
- インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。
DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
- 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。
2.3.8. user-provisioned infrastructure の DNS 解決の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を user-provisioned infrastructure にインストールする前に、DNS 設定を検証できます。
このセクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。
前提条件
- user-provisioned infrastructure に必要な DNS レコードを設定している。
手順
インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。
Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nameserver_ip>
をネームサーバーの IP アドレスに、<cluster_name>
をクラスター名に、<base_domain>
をベースドメイン名に置き換えます。
出力例
api.ocp4.example.com. 604800 IN A 192.168.1.5
api.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow *.apps.<cluster_name>.<base_domain>
DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
random
は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。
API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.5
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com. 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com.
1 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。
ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.96
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。
2.3.9. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core
ユーザーの ~/.ssh/authorized_keys
リストに追加され、パスワードなしの認証が可能になります。
キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core
として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather
コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
プラットフォーム固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記x86_64
、ppc64le
、およびs390x
アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519
アルゴリズムを使用するキーを作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。クラスターを独自にプロビジョニングするインフラストラクチャーにインストールする場合は、キーをインストールプログラムに指定する必要があります。
2.3.10. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
-
リポジトリーのミラーリングに使用するコマンドの出力で
imageContentSources
セクションを取得します。 - ミラーレジストリーの証明書の内容を取得する。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
mkdir <installation_directory>
$ mkdir <installation_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの
install-config.yaml
ファイルテンプレートをカスタマイズし、ファイルを<installation_directory>
に保存します。注記この設定ファイルの名前を
install-config.yaml
と付ける必要があります。-
docker.io
などの、RHCOS がデフォルトで信頼するレジストリーを使用しない限り、additionalTrustBundle
セクションにミラーリポジトリーの証明書の内容を指定する必要があります。ほとんどの場合、ミラーの証明書を指定する必要があります。 -
リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを組み込む必要があります。
重要-
ImageContentSourcePolicy
ファイルは、ミラーリングプロセスの終了後にoc mirror
の出力として生成されます。 -
oc mirror
コマンドは、ImageContentSourcePolicy
の定義に必要な YAML を含むImageContentSourcePolicy
ファイルを生成します。このファイルからテキストをコピーし、install-config.yaml
ファイルに貼り付けます。 -
'oc mirror' コマンドを 2 回実行する必要があります。初めて
oc mirror
コマンドを実行すると、完全なImageContentSourcePolicy
ファイルが取得されます。oc mirror
コマンドを 2 回目に実行すると、1 回目と 2 回目の実行の差のみが得られます。この動作のため、これらのファイルを 1 つの完全なImageContentSourcePolicy
ファイルにマージする必要がある場合に備えて、常にこれらのファイルのバックアップを保持する必要があります。これら 2 つの出力ファイルのバックアップを保持すると、完全なImageContentSourcePolicy
ファイルが確実に作成されます。
-
多くのクラスターのインストールに使用できるように、
install-config.yaml
ファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yaml
ファイルを使用するため、今すぐこのファイルをバックアップしてください。
2.3.10.1. ベアメタルのサンプル install-config.yaml ファイル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 5
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 3 6
- 同時マルチスレッド (SMT) またはハイパースレッディングを有効/無効にするかどうかを指定します。デフォルトでは、SMT はマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を
Disabled
に設定するとこれを無効にすることができます。SMT を無効にする場合、これをすべてのクラスターマシンで無効にする必要があります。これにはコントロールプレーンとコンピュートマシンの両方が含まれます。注記同時マルチスレッド (SMT) はデフォルトで有効になっています。SMT が BIOS 設定で有効になっていない場合は、
hyperthreading
パラメーターは効果がありません。重要BIOS または
install-config.yaml
ファイルであるかに関係なくhyperthreading
を無効にする場合、容量計画においてマシンのパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 - 4
- OpenShift Container Platform を user-provisioned infrastructure にインストールする場合は、この値を
0
に設定する必要があります。installer-provisioned installation では、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。user-provisioned installation では、クラスターのインストールの終了前にコンピュートマシンを手動でデプロイする必要があります。注記3 ノードクラスターをインストールする場合は、Red Hat Enterprise Linux CoreOS (RHCOS) マシンをインストールする際にコンピュートマシンをデプロイしないでください。
- 7
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 8
- DNS レコードに指定したクラスター名。
- 9
- Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。注記
クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。
- 10
- それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、
hostPrefix
が23
に設定されている場合、各ノードに指定のcidr
から/23
サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。 - 11
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 12
- サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
- 13
- プラットフォームを
none
に設定する必要があります。プラットフォーム用に追加のプラットフォーム設定変数を指定することはできません。重要プラットフォームタイプ
none
でインストールされたクラスターは、Machine API を使用したコンピュートマシンの管理など、一部の機能を使用できません。この制限は、クラスターに接続されている計算マシンが、通常はこの機能をサポートするプラットフォームにインストールされている場合でも適用されます。このパラメーターは、インストール後に変更することはできません。 - 14
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 15
<local_registry>
には、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
に、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 16
- Red Hat Enterprise Linux CoreOS (RHCOS) の
core
ユーザーの SSH 公開鍵。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 17
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 18
- リポジトリーのミラーリングに使用したコマンドの出力に従って、
imageContentSources
セクションを指定します。重要-
oc adm release mirror
コマンドを使用する場合は、imageContentSources
セクションの出力を使用します。 -
oc mirror
コマンドを使用する場合は、コマンドの実行によって生成されるImageContentSourcePolicy
ファイルのrepositoryDigestMirrors
セクションを使用します。 -
ImageContentSourcePolicy
は非推奨になりました。詳細は、イメージレジストリーリポジトリーミラーリングの設定 を参照してください。
-
2.3.10.2. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml
ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
ベアメタルインストールでは、install-config.yaml
ファイルの networking.machineNetwork[].cidr
フィールドで指定される範囲にあるノード IP アドレスを割り当てない場合、それらを proxy.noProxy
フィールドに含める必要があります。
前提条件
-
既存の
install-config.yaml
ファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxy
オブジェクトのspec.noProxy
フィールドに追加している。注記Proxy
オブジェクトのstatus.noProxy
フィールドには、インストール設定のnetworking.machineNetwork[].cidr
、networking.clusterNetwork[].cidr
、およびnetworking.serviceNetwork[]
フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundle
という名前の設定マップをopenshift-config
namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle
config map を作成し、この config map はProxy
オブジェクトのtrustedCA
フィールドで参照されます。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション:
trustedCA
フィールドのuser-ca-bundle
設定マップを参照するProxy
オブジェクトの設定を決定するポリシー。許可される値はProxyonly
およびAlways
です。Proxyonly
を使用して、http/https
プロキシーが設定されている場合にのみuser-ca-bundle
設定マップを参照します。Always
を使用して、常にuser-ca-bundle
設定マップを参照します。デフォルト値はProxyonly
です。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-for
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
2.3.10.3. 3 ノードクラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
オプションで、3 台のコントロールプレーンマシンのみで構成されるベアメタルクラスターに、ゼロコンピュートマシンをデプロイできます。これにより、テスト、開発、および実稼働に使用するための小規模なリソース効率の高いクラスターが、クラスター管理者および開発者に提供されます。
3 ノードの OpenShift Container Platform 環境では、3 つのコントロールプレーンマシンがスケジュール対象となります。つまり、アプリケーションのワークロードがそれらで実行されるようにスケジュールされます。
前提条件
-
既存の
install-config.yaml
ファイルがある。
手順
以下の
compute
スタンザに示されるように、コンピュートレプリカの数がinstall-config.yaml
ファイルで0
に設定されることを確認します。compute: - name: worker platform: {} replicas: 0
compute: - name: worker platform: {} replicas: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デプロイするコンピュートマシンの数にかかわらず、OpenShift Container Platform を user-provisioned infrastructure にインストールする際に、コンピュートマシンの
replicas
パラメーターの値を0
に設定する必要があります。installer-provisioned installation では、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。これは、コンピュートマシンが手動でデプロイされる、user-provisioned installation には適用されません。
3 ノードのクラスターのインストールで、以下の手順を実行します。
- ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
-
以下の手順で Kubernetes マニフェストファイルを作成する際に、
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルのmastersSchedulable
パラメーターがtrue
に設定されていることを確認します。これにより、アプリケーションのワークロードがコントロールプレーンノードで実行できます。 - Red Hat Enterprise Linux CoreOS (RHCOS) マシンを作成する際は、コンピュートノードをデプロイしないでください。
2.3.11. Kubernetes マニフェストおよび Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、作成したinstall-config.yaml
ファイルが含まれるインストールディレクトリーを指定します。
警告3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。
重要コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-password
およびkubeconfig
ファイルが./<installation_directory>/auth
ディレクトリーに作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.12. chrony タイムサービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
chrony タイムサービス (chronyd
) で使用されるタイムサーバーおよび関連する設定は、chrony.conf
ファイルのコンテンツを変更し、それらのコンテンツをマシン設定としてノードに渡して設定する必要があります。
手順
chrony.conf
ファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.bu
ファイルを作成します。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0
です。たとえば、4.19.0
などです。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記全マシン間の通信の場合、UDP 上の Network Time Protocol (NTP) はポート
123
です。外部 NTP タイムサーバーが設定されている場合は、UDP ポート123
を開く必要があります。Butane を使用して、ノードに配信される設定を含む
MachineConfig
オブジェクトファイル (99-worker-chrony.yaml
) を生成します。butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
$ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の 2 つの方法のいずれかで設定を適用します。
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、
MachineConfig
オブジェクトファイルを<installation_directory>/openshift
ディレクトリーに追加してから、クラスターの作成を続行します。 クラスターがすでに実行中の場合は、ファイルを適用します。
oc apply -f ./99-worker-chrony.yaml
$ oc apply -f ./99-worker-chrony.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、
2.3.13. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を独自にプロビジョニングするベアメタルインフラストラクチャーにインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) をマシンにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。
RHCOS をマシンにインストールするには、ISO イメージまたはネットワーク PXE ブートを使用する手順のいずれかを実行します。
このインストールガイドに含まれるコンピュートノードのデプロイメント手順は、RHCOS 固有のものです。代わりに RHEL ベースのコンピュートノードのデプロイを選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL8 コンピュートマシンのみがサポートされています。
以下の方法を使用して、ISO および PXE のインストール時に RHCOS を設定できます。
-
カーネル引数: カーネル引数を使用してインストール固有の情報を提供できます。たとえば、HTTP サーバーにアップロードした RHCOS インストールファイルの場所と、インストールするノードタイプの Ignition 設定ファイルの場所を指定できます。PXE インストールの場合、
APPEND
パラメーターを使用して、ライブインストーラーのカーネルに引数を渡すことができます。ISO インストールの場合は、ライブインストール起動プロセスを中断してカーネル引数を追加できます。いずれのインストールの場合でも、特殊なcoreos.inst.*
引数を使用してライブインストーラーに指示を与えたり、標準のカーネルサービスをオンまたはオフにするために標準のインストールブート引数を使用したりできます。 -
Ignition 設定: OpenShift Container Platform Ignition 設定ファイル (
*.ign
) は、インストールするノードのタイプに固有のものです。RHCOS のインストール時にブートストラップ、コントロールプレーン、またはコンピュートノードの Ignition 設定ファイルの場所を渡して、初回起動時に有効にされるようにします。特別なケースでは、ライブシステムに渡すために個別の制限付き Ignition 設定を作成できます。この Ignition 設定は、インストールが正常に完了したことをプロビジョニングシステムに報告するなどの一連のタスクを実行する可能性があります。この特別な Ignition 設定は、インストール済みシステムの初回ブート時に適用されるcoreos-installer
によって使用されます。標準のコントロールプレーンおよびコンピュートノードの Ignition 設定をライブ ISO に直接指定しないでください。 coreos-installer
: ライブ ISO インストーラーをシェルプロンプトで起動できます。これにより、初回のブート前にさまざまな方法で永続的なシステムの準備を行うことができます。特に、coreos-installer
コマンドを実行すると、追加するさまざまなアーティファクトを特定し、ディスクパーティションを使用し、ネットワークを設定できます。場合によっては、ライブシステムで機能を設定し、それらをインストールされたシステムにコピーできます。注記バージョン
0.17.0-3
以降、coreos-installer
プログラムを実行するには RHEL 9 以降が必要です。古いバージョンのcoreos-installer
を使用して、新しい OpenShift Container Platform リリースの RHCOS アーティファクトをカスタマイズし、メタルイメージをディスクにインストールすることもできます。coreos-installer
バイナリーの古いバージョンは、coreos-installer
image mirror ページからダウンロードできます。
ISO または PXE インストールを使用するかどうかは、状況によって異なります。PXE インストールには、利用可能な DHCP サービスとさらなる準備が必要ですが、インストールプロセスはさらに自動化することが可能です。ISO インストールは主に手動によるプロセスで、複数のマシンを設定する場合には使用しにくい可能性があります。
2.3.13.1. ISO イメージを使用した RHCOS のインストール リンクのコピーリンクがクリップボードにコピーされました!
ISO イメージを使用してマシンに RHCOS をインストールできます。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS、および負荷分散インフラストラクチャーを設定している。
- お使いのコンピューターからアクセスでき、作成するマシンからもアクセスできる HTTP サーバーがある。
- ネットワークやディスクパーティションなどのさまざまな機能の設定方法について、高度な RHCOS インストール設定 のセクションを確認している。
手順
それぞれの Ignition 設定ファイルの SHA512 ダイジェストを取得します。たとえば、Linux を実行しているシステムで以下を使用して、
bootstrap.ign
Ignition 設定ファイルの SHA512 ダイジェストを取得できます。sha512sum <installation_directory>/bootstrap.ign
$ sha512sum <installation_directory>/bootstrap.ign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ダイジェストは、クラスターノードの Ignition 設定ファイルの信頼性を検証するために、後の手順で
coreos-installer
に提供されます。インストールプログラムが作成したブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
インストールホストから、Ignition 設定ファイルが URL で利用可能であることを確認します。以下の例では、ブートストラップノードの Ignition 設定ファイルを取得します。
curl -k http://<HTTP_server>/bootstrap.ign
$ curl -k http://<HTTP_server>/bootstrap.ign
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドで
bootstrap.ign
をmaster.ign
またはworker.ign
に置き換え、コントロールプレーンおよびコンピュートノードの Ignition 設定ファイルも利用可能であることを検証します。RHCOS イメージのミラー ページから、オペレーティングシステムインスタンスをインストールするための推奨される方法に必要な RHCOS イメージを取得することは可能ですが、RHCOS イメージの正しいバージョンを取得するための推奨される方法は、
openshift-install
コマンドの出力から取得することです。openshift-install coreos print-stream-json | grep '\.iso[^.]'
$ openshift-install coreos print-stream-json | grep '\.iso[^.]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso", "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso", "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso", "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
"location": "<url>/art/storage/releases/rhcos-4.19-aarch64/<release>/aarch64/rhcos-<release>-live.aarch64.iso", "location": "<url>/art/storage/releases/rhcos-4.19-ppc64le/<release>/ppc64le/rhcos-<release>-live.ppc64le.iso", "location": "<url>/art/storage/releases/rhcos-4.19-s390x/<release>/s390x/rhcos-<release>-live.s390x.iso", "location": "<url>/art/storage/releases/rhcos-4.19/<release>/x86_64/rhcos-<release>-live.x86_64.iso",
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。この手順には ISO イメージのみを使用します。RHCOS qcow2 イメージは、このインストールではサポートされません。
ISO ファイルの名前は以下の例のようになります。
rhcos-<version>-live.<architecture>.iso
ISO を使用し、RHCOS インストールを開始します。以下のインストールオプションのいずれかを使用します。
- ディスクに ISO イメージを書き込み、これを直接起動します。
- Lights Out Management (LOM) インターフェイスを使用して ISO リダイレクトを使用します。
オプションを指定したり、ライブ起動シーケンスを中断したりせずに、RHCOS ISO イメージを起動します。インストーラーが RHCOS ライブ環境でシェルプロンプトを起動するのを待ちます。
注記RHCOS インストール起動プロセスを中断して、カーネル引数を追加できます。ただし、この ISO 手順では、カーネル引数を追加する代わりに、以下の手順で説明しているように
coreos-installer
コマンドを使用する必要があります。coreos-installer
コマンドを実行し、インストール要件を満たすオプションを指定します。少なくとも、ノードタイプの Ignition 設定ファイルを参照する URL と、インストール先のデバイスを指定する必要があります。sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \ --ignition-hash=sha512-<digest> --offline
$ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> \
1 --ignition-hash=sha512-<digest> --offline
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記TLS を使用する HTTPS サーバーを使用して Ignition 設定ファイルを提供する場合は、
coreos-installer
を実行する前に、内部認証局 (CA) をシステムのトラストストアに追加できます。以下の例では、
/dev/sda
デバイスへのブートストラップノードのインストールを初期化します。ブートストラップノードの Ignition 設定ファイルは、IP アドレス 192.168.1.2 で HTTP Web サーバーから取得されます。sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \ --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b \ --offline
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \ --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b \ --offline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシンのコンソールで RHCOS インストールの進捗を監視します。
重要OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
- RHCOS のインストール後、システムを再起動する必要があります。システムの再起動後、指定した Ignition 設定ファイルを適用します。
コンソール出力をチェックして、Ignition が実行されたことを確認します。
コマンドの例
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 継続してクラスターの他のマシンを作成します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、OpenShift Container Platform のインストール前に少なくとも 2 つのコンピュートマシンも作成します。
必要なネットワーク、DNS、およびロードバランサーインフラストラクチャーが配置されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS ノードの再起動後に自動的に起動します。
注記RHCOS ノードには、
core
ユーザーのデフォルトのパスワードは含まれません。ノードには、ssh core@<node>.<cluster_name>.<base_domain>
を、install_config.yaml
ファイルで指定したパブリックキーとペアになる SSH プライベートキーへのアクセスのあるユーザーとして実行してアクセスできます。RHCOS を実行する OpenShift Container Platform 4 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、インストールの問題を調査する際に、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、デバッグまたは障害復旧に SSH アクセスが必要になることがあります。
2.3.13.2. PXE または iPXE ブートを使用した RHCOS のインストール リンクのコピーリンクがクリップボードにコピーされました!
PXE または iPXE ブートを使用してマシンに RHCOS をインストールできます。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- 適切な PXE または iPXE インフラストラクチャーを設定していること。
- お使いのコンピューターからアクセスでき、作成するマシンからもアクセスできる HTTP サーバーがある。
- ネットワークやディスクパーティションなどのさまざまな機能の設定方法について、高度な RHCOS インストール設定 のセクションを確認している。
手順
インストールプログラムが作成したブートストラップ、コントロールプレーン、およびコンピュートノード Ignition 設定ファイルを HTTP サーバーにアップロードします。これらのファイルの URL をメモします。
重要HTTP サーバーに保存する前に、Ignition 設定で設定内容を追加したり、変更したりできます。インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
インストールホストから、Ignition 設定ファイルが URL で利用可能であることを確認します。以下の例では、ブートストラップノードの Ignition 設定ファイルを取得します。
curl -k http://<HTTP_server>/bootstrap.ign
$ curl -k http://<HTTP_server>/bootstrap.ign
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0{"ignition":{"version":"3.2.0"},"passwd":{"users":[{"name":"core","sshAuthorizedKeys":["ssh-rsa...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドで
bootstrap.ign
をmaster.ign
またはworker.ign
に置き換え、コントロールプレーンおよびコンピュートノードの Ignition 設定ファイルも利用可能であることを検証します。RHCOS イメージミラー ページからオペレーティングシステムインスタンスをインストールするための推奨される方法に必要な RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得することは可能ですが、RHCOS ファイルの正しいバージョンを取得するための推奨される方法は、openshift-install
コマンドの出力から取得することです。openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'
$ openshift-install coreos print-stream-json | grep -Eo '"https.*(kernel-|initramfs.|rootfs.)\w+(\.img)?"'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要RHCOS アーティファクトは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。この手順で説明されている適切な
kernel
、initramfs
、およびrootfs
アーティファクトのみを使用します。RHCOS QCOW2 イメージは、このインストールタイプではサポートされません。ファイル名には、OpenShift Container Platform のバージョン番号が含まれます。以下の例のようになります。
-
kernel
:rhcos-<version>-live-kernel-<architecture>
-
initramfs
:rhcos-<version>-live-initramfs.<architecture>.img
-
rootfs
:rhcos-<version>-live-rootfs.<architecture>.img
-
rootfs
、kernel
、およびinitramfs
ファイルを HTTP サーバーにアップロードします。重要インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。
- RHCOS のインストール後にマシンがローカルディスクから起動されるようにネットワークブートインフラストラクチャーを設定します。
RHCOS イメージの PXE または iPXE インストールを設定し、インストールを開始します。
ご使用の環境に関する以下の例で示されるメニューエントリーのいずれかを変更し、イメージおよび Ignition ファイルが適切にアクセスできることを確認します。
PXE(
x86_64
) の場合:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 1
- HTTP サーバーにアップロードしたライブ
kernel
ファイルの場所を指定します。URL は HTTP、TFTP、または FTP である必要があります。HTTPS および NFS はサポートされません。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
initrd
パラメーター値はinitramfs
ファイルの場所であり、coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所、またcoreos.inst.ignition_url
パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。APPEND
行にカーネル引数を追加して、ネットワークやその他の起動オプションを設定することもできます。
注記この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、
APPEND
行に 1 つ以上のconsole=
引数を追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。iPXE (
x86_64
+aarch64
) の場合:kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img boot
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
1 2 initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img
3 boot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- HTTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値はkernel
ファイルの場所であり、initrd=main
引数は UEFI システムでの起動に必要であり、coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値はブートストラップ Ignition 設定ファイルの場所になります。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- HTTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
注記この設定では、グラフィカルコンソールを使用するマシンでシリアルコンソールアクセスを有効にしません。別のコンソールを設定するには、
kernel
行にconsole=
引数を 1 つ以上追加します。たとえば、console=tty0 console=ttyS0
を追加して、最初の PC シリアルポートをプライマリーコンソールとして、グラフィカルコンソールをセカンダリーコンソールとして設定します。詳細は、How does one set up a serial terminal and/or console in Red Hat Enterprise Linux? と、「高度な RHCOS インストール設定」セクションの「PXE および ISO インストール用シリアルコンソールの有効化」を参照してください。注記aarch64
アーキテクチャーで CoreOSkernel
をネットワークブートするには、IMAGE_GZIP
オプションが有効になっているバージョンの iPXE ビルドを使用する必要があります。iPXE のIMAGE_GZIP
オプション を参照してください。aarch64
上の PXE (第 2 段階として UEFI と Grub を使用) の場合:menuentry 'Install CoreOS' { linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign initrd rhcos-<version>-live-initramfs.<architecture>.img }
menuentry 'Install CoreOS' { linux rhcos-<version>-live-kernel-<architecture> coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/bootstrap.ign
1 2 initrd rhcos-<version>-live-initramfs.<architecture>.img
3 }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- HTTP/TFTP サーバーにアップロードした RHCOS ファイルの場所を指定します。
kernel
パラメーター値は、TFTP サーバー上のkernel
ファイルの場所になります。coreos.live.rootfs_url
パラメーター値はrootfs
ファイルの場所であり、coreos.inst.ignition_url
パラメーター値は HTTP サーバー上のブートストラップ Ignition 設定ファイルの場所になります。 - 2
- 複数の NIC を使用する場合、
ip
オプションに単一インターフェイスを指定します。たとえば、eno1
という名前の NIC で DHCP を使用するには、ip=eno1:dhcp
を設定します。 - 3
- TFTP サーバーにアップロードした
initramfs
ファイルの場所を指定します。
マシンのコンソールで RHCOS インストールの進捗を監視します。
重要OpenShift Container Platform のインストールを開始する前に、各ノードでインストールが成功していることを確認します。インストールプロセスを監視すると、発生する可能性のある RHCOS インストールの問題の原因を特定する上でも役立ちます。
- RHCOS のインストール後に、システムは再起動します。再起動中、システムは指定した Ignition 設定ファイルを適用します。
コンソール出力をチェックして、Ignition が実行されたことを確認します。
コマンドの例
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのマシンの作成を続行します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。コントロールプレーンマシンがデフォルトのスケジュール対象にされていない場合、クラスターのインストール前に少なくとも 2 つのコンピュートマシンを作成します。
必要なネットワーク、DNS、およびロードバランサーインフラストラクチャーが配置されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS ノードの再起動後に自動的に起動します。
注記RHCOS ノードには、
core
ユーザーのデフォルトのパスワードは含まれません。ノードには、ssh core@<node>.<cluster_name>.<base_domain>
を、install_config.yaml
ファイルで指定したパブリックキーとペアになる SSH プライベートキーへのアクセスのあるユーザーとして実行してアクセスできます。RHCOS を実行する OpenShift Container Platform 4 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、インストールの問題を調査する際に、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、デバッグまたは障害復旧に SSH アクセスが必要になることがあります。
2.3.13.3. 高度な RHCOS インストール設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 用の Red Hat Enterprise Linux CoreOS (RHCOS) ノードを手動でプロビジョニングする主な利点は、デフォルトの OpenShift Container Platform インストール方法では利用できない設定を実行できることです。このセクションでは、以下のような手法で実行できるいくつかの設定を説明します。
- カーネル引数をライブインストーラーに渡す
-
ライブシステムからの
coreos-installer
の手動による実行 - ライブ ISO または PXE ブートイメージのカスタマイズ
このセクションで説明されている手動の Red Hat Enterprise Linux CoreOS (RHCOS) インストールの高度な設定トピックは、ディスクパーティション設定、ネットワーク、および複数の異なる方法での Ignition 設定の使用に関連しています。
2.3.13.3.1. PXE および ISO インストールの高度なネットワーキングオプションの使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ノードのネットワークはデフォルトで DHCP を使用して、必要な設定をすべて収集します。静的 IP アドレスを設定したり、ボンディングなどの特別な設定を行う場合は、以下のいずれかの方法で実行できます。
- ライブインストーラーの起動時に、特別なカーネルパラメーターを渡します。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
- ライブインストーラーのシェルプロンプトからネットワークを設定し、それらの設定をインストール済みシステムにコピーして、インストール済みシステムの初回起動時に有効になるようにします。
PXE または iPXE インストールを設定するには、以下のオプションのいずれかを使用します。
- 「詳細な RHCOS インストールリファレンスの表」を参照してください。
- マシン設定を使用してネットワークファイルをインストール済みシステムにコピーします。
ISO インストールを設定するには、以下の手順に従います。
手順
- ISO インストーラーを起動します。
-
ライブシステムシェルプロンプトから、
nmcli
またはnmtui
などの利用可能な RHEL ツールを使用して、ライブシステムのネットワークを設定します。 coreos-installer
コマンドを実行してシステムをインストールし、--copy-network
オプションを追加してネットワーク設定をコピーします。以下に例を示します。sudo coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign \ --offline \ /dev/disk/by-id/scsi-<serial_number>
$ sudo coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign \ --offline \ /dev/disk/by-id/scsi-<serial_number>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要--copy-network
オプションは、/etc/NetworkManager/system-connections
にあるネットワーク設定のみをコピーします。特に、システムのホスト名はコピーされません。- インストール済みのシステムで再起動します。
2.3.13.3.2. ディスクパーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
ディスクパーティションは、Red Hat Enterprise Linux CoreOS (RHCOS) のインストール時に OpenShift Container Platform クラスターノードに作成されます。デフォルトのパーティション設定をオーバーライドしない限り、特定のアーキテクチャーの各 RHCOS ノードで同じパーティションレイアウトが使用されます。RHCOS のインストール時に、ルートファイルシステムのサイズが拡大し、ターゲットデバイスの残りの使用可能なスペースが使用されます。
ノードでカスタムパーティションスキームを使用すると、OpenShift Container Platform が一部のノードパーティションでモニタリングやアラートを行わなくなる可能性があります。デフォルトのパーティション設定をオーバーライドする場合は、OpenShift Container Platform がホストファイルシステムを監視する方法の詳細について Understanding OpenShift File System Monitoring (eviction conditions) を参照してください。
OpenShift Container Platform は、次の 2 つのファイルシステム識別子を監視します。
-
nodefs
:/var/lib/kubelet
を含むファイルシステム -
imagefs
:/var/lib/containers
を含むファイルシステム
デフォルトのパーティションスキームの場合、nodefs
と imagefs
は同じルートファイルシステム (/
) を監視します。
RHCOS を OpenShift Container Platform クラスターノードにインストールするときにデフォルトのパーティション設定をオーバーライドするには、別のパーティションを作成する必要があります。コンテナーとコンテナーイメージ用に別のストレージパーティションを追加する状況を考えてみましょう。たとえば、/var/lib/containers
を別のパーティションにマウントすると、kubelet が /var/lib/containers
を imagefs
ディレクトリーとして、ルートファイルシステムを nodefs
ディレクトリーとして個別に監視します。
より大きなファイルシステムをホストするためにディスクサイズを変更した場合は、別の /var/lib/containers
パーティションを作成することを検討してください。多数の割り当てグループによって発生する CPU 時間の問題を軽減するには、xfs
形式のディスクのサイズを変更することを検討してください。
2.3.13.3.2.1. 個別の /var パーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
通常は、RHCOS のインストール時に作成されるデフォルトのディスクパーティションを使用する必要があります。ただし、拡張するディレクトリーの個別のパーティションの作成が必要となる場合もあります。
OpenShift Container Platform は、ストレージを /var
ディレクトリーまたは /var
のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
-
/var/lib/containers
: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。 -
/var/lib/etcd
: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。 /var
: 監査などの目的に合わせて分離させる必要のあるデータを保持します。重要ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の
/var
パーティションを作成します。
/var
ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
/var
ディレクトリーまたは /var
のサブディレクトリーの個別のパーティションを使用すると、パーティション設定されたディレクトリーでのデータの増加によりルートファイルシステムが一杯になることを避けることもできます。
以下の手順では、インストールの準備フェーズでノードタイプの Ignition 設定ファイルにラップされるマシン設定マニフェストを追加して、別の /var
パーティションを設定します。
手順
インストールホストで、OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加のパーティションを設定する Butane 設定を作成します。たとえば、
$HOME/clusterconfig/98-var-partition.bu
ファイルに名前を付け、ディスクのデバイス名をworker
システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var
ディレクトリーを別のパーティションにマウントします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小のオフセット値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。オフセット値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、
prjquota
マウントオプションを有効にする必要があります。
注記個別の
/var
パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、コンピュートノードに異なるインスタンスタイプを使用することはできません。Butane config からマニフェストを作成し、
clusterconfig/openshift
ディレクトリーに保存します。たとえば、以下のコマンドを実行します。butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignition 設定ファイルを作成します。
openshift-install create ignition-configs --dir <installation_directory>
$ openshift-install create ignition-configs --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <installation_directory>/manifest
ディレクトリーおよび<installation_directory>/openshift
ディレクトリーのファイルは、98-var-partition
カスタムMachineConfig
オブジェクトが含まれるファイルを含む Ignition 設定ファイルにラップされます。
次のステップ
- RHCOS のインストール時に Ignition 設定ファイルを参照して、カスタムディスクのパーティション設定を適用することができます。
2.3.13.3.2.2. 既存パーティションの保持 リンクのコピーリンクがクリップボードにコピーされました!
ISO インストールの場合は、インストーラーに 1 つ以上の既存パーティションを維持させる coreos-installer
コマンドにオプションを追加することができます。PXE インストールの場合、coreos.inst.*
オプションを APPEND
パラメーターに追加して、パーティションを保持できます。
保存したパーティションは、既存の OpenShift Container Platform システムからのデータパーティションである可能性があります。パーティションラベルまたは番号のいずれかで保持する必要のあるディスクパーティションを特定できます。
既存のパーティションを保存し、それらのパーティションが RHCOS の十分な領域を残さない場合、インストールは失敗します。この場合、保存したパーティションが破損することはありません。
ISO インストール時の既存パーティションの保持
この例では、パーティションラベルが data
(data*
) で始まるパーティションを保持します。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partlabel 'data*' \ --offline \ /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partlabel 'data*' \
--offline \
/dev/disk/by-id/scsi-<serial_number>
以下の例では、ディスク上の 6 番目のパーティションを保持する方法で coreos-installer
を実行する方法を説明しています。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partindex 6 \ --offline \ /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 6 \
--offline \
/dev/disk/by-id/scsi-<serial_number>
この例では、パーティション 5 以上を保持します。
coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ --save-partindex 5- \ --offline \ /dev/disk/by-id/scsi-<serial_number>
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- \
--offline \
/dev/disk/by-id/scsi-<serial_number>
パーティションの保存が使用された以前の例では、coreos-installer
はパーティションをすぐに再作成します。
PXE インストール時の既存パーティションの保持
この APPEND
オプションは、パーティションラベルが 'data' ('data*') で始まるパーティションを保持します。
coreos.inst.save_partlabel=data*
coreos.inst.save_partlabel=data*
この APPEND
オプションは、パーティション 5 以上を保持します。
coreos.inst.save_partindex=5-
coreos.inst.save_partindex=5-
この APPEND
オプションは、パーティション 6 を保持します。
coreos.inst.save_partindex=6
coreos.inst.save_partindex=6
2.3.13.3.3. Ignition 設定の特定 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS の手動インストールを実行する場合、提供できる Ignition 設定には 2 つのタイプがあり、それぞれを提供する理由もそれぞれ異なります。
Permanent install Ignition config: すべての手動の RHCOS インストールは、
bootstrap.ign
、master.ign
、およびworker.ign
などのopenshift-installer
が生成した Ignition 設定ファイルのいずれかを渡し、インストールを実行する必要があります。重要これらの Ignition 設定ファイルを直接変更することは推奨されません。前述のセクションの例で説明されているように、Ignition 設定ファイルにラップされるマニフェストファイルを更新できます。
PXE インストールの場合、
coreos.inst.ignition_url=
オプションを使用して、APPEND
行に Ignition 設定を渡します。ISO インストールの場合、シェルプロンプトで ISO を起動した後に、--ignition-url=
オプションを指定したcoreos-installer
コマンドラインで Ignition 設定を特定します。いずれの場合も、HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。Live install Ignition config: このタイプは、
coreos-installer
customize
サブコマンドとそのさまざまなオプションを使用して作成できます。この方法では、Ignition 設定はライブインストールメディアに渡され、起動直後に実行され、RHCOS システムがディスクにインストールされる前または後にセットアップタスクを実行します。この方法は、マシン設定を使用して実行できない高度なパーティション設定など、一度の適用後に再度適用する必要のないタスクの実行にのみ使用する必要があります。PXE または ISO ブートの場合、Ignition 設定を作成し、
ignition.config.url=
オプションに対してAPPEND
を実行し、Ignition 設定の場所を特定できます。また、ignition.firstboot ignition.platform.id=metal
も追加する必要があります。追加しない場合は、ignition.config.url
が無視されます。
2.3.13.3.4. デフォルトのコンソール設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 ブートイメージからインストールされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードは、ほとんどの仮想化セットアップおよびベアメタルセットアップに対応するためのデフォルトコンソールを使用します。クラウドおよび仮想化プラットフォームが異なれば、選択したアーキテクチャーに応じて、異なるデフォルト設定が使用される場合があります。ベアメタルインストールではカーネルのデフォルト設定が使用されます。これは通常、グラフィカルコンソールがプライマリーコンソールで、シリアルコンソールが無効になっていることを意味します。
デフォルトのコンソールが特定のハードウェア設定と一致しない場合や、デフォルトのコンソールを調整する必要がある特定のニーズがある場合があります。以下に例を示します。
- デバッグ目的で、コンソールの緊急シェルにアクセスしたいと考えています。
- クラウドプラットフォームは、グラフィカルコンソールへの対話型アクセスを提供しませんが、シリアルコンソールを提供します。
- 複数のコンソールを有効にしたい。
コンソール設定は、ブートイメージから継承されます。これは、既存のクラスター内の新しいノードが、デフォルトのコンソールへの変更の影響を受けないことを意味します。
次の方法で、ベアメタルインストール用にコンソールを設定できます。
-
コマンドラインで手動で
coreos-installer
を使用する。 -
--dest-console
オプションを指定したcoreos-installer iso customize
またはcoreos-installer pxe customize
サブコマンドを使用して、プロセスを自動化するカスタムイメージを作成します。
高度なカスタマイズを行うには、カーネル引数ではなく、coreos-installer iso
または coreos-installer pxe
サブコマンドを使用してコンソール設定を実行します。
2.3.13.3.5. PXE および ISO インストール用のシリアルコンソールの有効化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Red Hat Enterprise Linux CoreOS (RHCOS) シリアルコンソールは無効になっており、すべての出力はグラフィカルコンソールに書き込まれます。ISO インストール用にシリアルコンソールを有効にし、シリアルコンソールとグラフィカルコンソールの両方に出力が送信されるようにブートローダーを再設定できます。
手順
- ISO インストーラーを起動します。
coreos-installer
コマンドを実行してシステムをインストールし、--console
オプションを 1 回追加してグラフィカルコンソールを指定し、2 回目にシリアルコンソールを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 2
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。
インストール済みのシステムで再起動します。
注記coreos-installer install --append-karg
オプションを使用し、console=
でコンソールを指定すると、同様の結果が得られます。ただし、これはカーネルのコンソールのみを設定し、ブートローダーは設定しません。
PXE インストールを設定するには、coreos.inst.install_dev
カーネルコマンドラインオプションが省略されていることを確認し、シェルプロンプトを使用して、上記の ISO インストール手順を使用して手動で coreos-installer
を実行します。
2.3.13.3.6. ライブ RHCOS ISO または PXE インストールのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
ライブ ISO イメージまたは PXE 環境を使用して、Ignition 設定ファイルをイメージに直接挿入することで RHCOS をインストールできます。これにより、システムのプロビジョニングに使用できるカスタマイズされたイメージが作成されます。
ISO イメージの場合、これを行うメカニズムは coreos-installer iso customize
サブコマンドです。これは設定に合わせて .iso
ファイルを変更します。同様に、PXE 環境のメカニズムは、カスタマイズを含む新しい initramfs
ファイルを作成する coreos-installer pxe customize
サブコマンドです。
customize
サブコマンドは、他のタイプのカスタマイズも埋め込むことができる汎用ツールです。次のタスクは、より一般的なカスタマイズの例です。
- 企業のセキュリティーポリシーで使う必要がある場合に備えて、カスタム CA 証明書を挿入します。
- カーネル引数を必要とせずにネットワーク設定を設定します。
- 任意のプレインストールおよびポストインストールスクリプトまたはバイナリーを埋め込みます。
2.3.13.3.7. ライブ RHCOS ISO イメージのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
coreos-installer iso customize
サブコマンドを使用して、ライブ RHCOS ISO イメージを直接カスタマイズできます。ISO イメージを起動すると、カスタマイズが自動的に適用されます。
この機能を使用して、RHCOS を自動的にインストールするように ISO イメージを設定できます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページと Ignition 設定ファイルから RHCOS ISO イメージを取得し、次のコマンドを実行して、Ignition 設定を ISO イメージに直接挿入します。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition bootstrap.ign \ --dest-device /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition bootstrap.ign \
1 --dest-device /dev/disk/by-id/scsi-<serial_number>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ISO イメージのカスタマイズを削除し、イメージを元の状態に戻すには、次のコマンドを実行します。
coreos-installer iso reset rhcos-<version>-live.x86_64.iso
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、ライブ ISO イメージを再カスタマイズしたり、元の状態で使用したりできます。
カスタマイズを適用すると、それ以降のすべての RHCOS 起動に影響します。
2.3.13.3.7.1. ライブインストール ISO イメージを変更して、シリアルコンソールを有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 以降でインストールされたクラスターでは、シリアルコンソールはデフォルトで無効になり、すべての出力がグラフィカルコンソールに書き込まれます。次の手順でシリアルコンソールを有効にできます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して ISO イメージをカスタマイズし、シリアルコンソールが出力を受信できるようにします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition <path> \ --dest-console tty0 \ --dest-console ttyS0,<options> \ --dest-device /dev/disk/by-id/scsi-<serial_number>
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --dest-ignition <path> \
1 --dest-console tty0 \
2 --dest-console ttyS0,<options> \
3 --dest-device /dev/disk/by-id/scsi-<serial_number>
4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールする Ignition 設定の場所。
- 2
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 3
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。 - 4
- インストール先として指定されたディスク。このオプションを省略すると、ISO イメージはインストールプログラムを自動的に実行しますが、
coreos.inst.install_dev
カーネル引数も指定しない限り失敗します。
注記--dest-console
オプションは、ライブ ISO システムではなく、インストールされたシステムに影響します。ライブ ISO システムのコンソールを変更するには、--live-karg-append
オプションを使用し、console=
でコンソールを指定します。カスタマイズが適用され、ISO イメージの後続のすべての起動に影響します。
オプション: ISO イメージのカスタマイズを削除してイメージを元の状態に戻すには、次のコマンドを実行します。
coreos-installer iso reset rhcos-<version>-live.x86_64.iso
$ coreos-installer iso reset rhcos-<version>-live.x86_64.iso
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ライブ ISO イメージを再カスタマイズするか、元の状態で使用できるようになりました。
2.3.13.3.7.2. カスタム認証局を使用するようにライブインストール ISO イメージを変更する リンクのコピーリンクがクリップボードにコピーされました!
customize
サブコマンドの --ignition-ca
フラグを使用して、認証局 (CA) 証明書を Ignition に提供できます。CA 証明書は、インストールの起動時とインストール済みシステムのプロビジョニング時の両方で使用できます。
カスタム CA 証明書は、Ignition がリモートリソースをフェッチする方法に影響しますが、システムにインストールされている証明書には影響しません。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して、カスタム CA で使用する ISO イメージをカスタマイズします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso --ignition-ca cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
coreos.inst.ignition_url
カーネルパラメーターは、--ignition-ca
フラグでは機能しません。クラスターごとにカスタマイズされたイメージを作成するには、--dest-ignition
フラグを使用する必要があります。
カスタム CA 証明書を適用すると、それ以降のすべての RHCOS 起動に影響します。
2.3.13.3.7.3. カスタマイズされたネットワーク設定を使用したライブインストール ISO イメージの変更 リンクのコピーリンクがクリップボードにコピーされました!
NetworkManager キーファイルをライブ ISO イメージに埋め込み、customize
サブコマンドの --network-keyfile
フラグを使用してインストール済みシステムに渡すことができます。
接続プロファイルを作成する際は、接続プロファイルのファイル名に .nmconnection
ファイル名拡張子を使用する必要があります。.nmconnection
ファイル名拡張子を使用しない場合、クラスターは接続プロファイルをライブ環境に適用しますが、クラスターが初めてノードを起動するときに設定が適用されないため、セットアップが機能しなくなります。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 ボンディングされたインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em1.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em2.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次のコマンドを実行して、設定されたネットワークで ISO イメージをカスタマイズします。
coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection
$ coreos-installer iso customize rhcos-<version>-live.x86_64.iso \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク設定はライブシステムに適用され、宛先システムに引き継がれます。
2.3.13.3.7.4. iSCSI ブートデバイス用のライブインストール ISO イメージをカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次の情報を使用して ISO イメージをカスタマイズするために、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- 宛先システムの場所。ターゲットポータルの IP アドレス、関連付けられたポート番号、IQN 形式のターゲット iSCSI ノード、および iSCSI 論理ユニット番号 (LUN) を指定する必要があります。
- 4
- 宛先システムの Ignition 設定。
- 5
- IQN 形式の iSCSI イニシエーター、クライアントの名前。イニシエーターは iSCSI ターゲットに接続するセッションを形成します。
- 6
- IQN 形式の iSCSI ターゲットまたはサーバーの名前。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.3.13.3.7.5. iBFT を使用して iSCSI ブートデバイス用のライブインストール ISO イメージをカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから RHCOS ISO イメージを取得し、次の情報を使用して ISO イメージをカスタマイズするために、以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- デバイスへのパス。マルチパスを使用している場合は、マルチパスデバイス (
/dev/mapper/mpatha
) を使用します。複数のマルチパスデバイスが接続されている場合、または明示する場合、/dev/disk/by-path
で使用可能な World Wide Name (WWN) シンボリックリンクを使用できます。 - 4
- 宛先システムの Ignition 設定。
- 5
- iSCSI パラメーターは、BIOS ファームウェアから読み取られます。
- 6
- オプション: マルチパス構成を有効にする場合は、このパラメーターを含めます。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.3.13.3.8. ライブ RHCOS PXE 環境のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
coreos-installer pxe customize
サブコマンドを使用して、ライブ RHCOS PXE 環境を直接カスタマイズできます。PXE 環境を起動すると、カスタマイズが自動的に適用されます。
この機能を使用して、RHCOS を自動的にインストールするように PXE 環境を設定できます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページと Ignition 設定ファイルから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、Ignition 設定からのカスタマイズを含む新しいinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --dest-ignition bootstrap.ign \ --dest-device /dev/disk/by-id/scsi-<serial_number> \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --dest-ignition bootstrap.ign \
1 --dest-device /dev/disk/by-id/scsi-<serial_number> \
2 -o rhcos-<version>-custom-initramfs.x86_64.img
3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
カスタマイズを適用すると、それ以降のすべての RHCOS 起動に影響します。
2.3.13.3.8.1. ライブインストール PXE 環境を変更して、シリアルコンソールを有効化。 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 以降でインストールされたクラスターでは、シリアルコンソールはデフォルトで無効になり、すべての出力がグラフィカルコンソールに書き込まれます。次の手順でシリアルコンソールを有効にできます。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページおよび Ignition 設定ファイルから RHCOS
kernel
、initramfs
およびrootfs
ファイルを取得します。次のコマンドを実行して、シリアルコンソールが出力を受信できるようにする新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールする Ignition 設定の場所。
- 2
- 望ましい 2 番目のコンソール。この場合は、グラフィカルコンソールです。このオプションを省略すると、グラフィカルコンソールが無効になります。
- 3
- 望ましいひとつ目のコンソール。この場合、シリアルコンソールです。
options
フィールドは、ボーレートとその他の設定を定義します。このフィールドの一般的な値は115200n8
です。オプションが指定されていない場合、デフォルトのカーネル値である9600n8
が使用されます。このオプションの形式の詳細は、Linux カーネルシリアルコンソール のドキュメントを参照してください。 - 4
- インストール先として指定されたディスク。このオプションを省略すると、PXE 環境は自動的にインストーラーを実行しますが、
coreos.inst.install_dev
カーネル引数も指定しない限り失敗します。 - 5
- PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。
カスタマイズが適用され、PXE 環境の後続のすべての起動に影響します。
2.3.13.3.8.2. カスタム認証局を使用するようにライブインストール PXE 環境を変更する リンクのコピーリンクがクリップボードにコピーされました!
customize
サブコマンドの --ignition-ca
フラグを使用して、認証局 (CA) 証明書を Ignition に提供できます。CA 証明書は、インストールの起動時とインストール済みシステムのプロビジョニング時の両方で使用できます。
カスタム CA 証明書は、Ignition がリモートリソースをフェッチする方法に影響しますが、システムにインストールされている証明書には影響しません。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、カスタム CA で使用するための新しいカスタマイズされたinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --ignition-ca cert.pem \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --ignition-ca cert.pem \ -o rhcos-<version>-custom-initramfs.x86_64.img
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。
coreos.inst.ignition_url
カーネルパラメーターは、--ignition-ca
フラグでは機能しません。クラスターごとにカスタマイズされたイメージを作成するには、--dest-ignition
フラグを使用する必要があります。
カスタム CA 証明書を適用すると、それ以降のすべての RHCOS 起動に影響します。
2.3.13.3.8.3. カスタマイズされたネットワーク設定を使用したライブインストール PXE 環境の変更 リンクのコピーリンクがクリップボードにコピーされました!
NetworkManager キーファイルをライブ PXE 環境に埋め込み、customize
サブコマンドの --network-keyfile
フラグを使用して、インストール済みシステムに渡すことができます。
接続プロファイルを作成する際は、接続プロファイルのファイル名に .nmconnection
ファイル名拡張子を使用する必要があります。.nmconnection
ファイル名拡張子を使用しない場合、クラスターは接続プロファイルをライブ環境に適用しますが、クラスターが初めてノードを起動するときに設定が適用されないため、セットアップが機能しなくなります。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 ボンディングされたインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em1.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ボンディングに追加するセカンダリーインターフェイスの接続プロファイルを作成します。たとえば、ローカルディレクトリーに次の内容の
bond0-proxy-em2.nmconnection
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、設定済みのネットワークを含む新しいカスタマイズされたinitramfs
ファイルを作成します。coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection \ -o rhcos-<version>-custom-initramfs.x86_64.img
$ coreos-installer pxe customize rhcos-<version>-live-initramfs.x86_64.img \ --network-keyfile bond0.nmconnection \ --network-keyfile bond0-proxy-em1.nmconnection \ --network-keyfile bond0-proxy-em2.nmconnection \ -o rhcos-<version>-custom-initramfs.x86_64.img
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PXE 設定でカスタマイズされた
initramfs
ファイルを使用します。ignition.firstboot
およびignition.platform.id=metal
カーネル引数が存在しない場合は追加します。ネットワーク設定はライブシステムに適用され、宛先システムに引き継がれます。
2.3.13.3.8.4. iSCSI ブートデバイス用のライブインストール PXE 環境をカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、次の情報を含む新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドと、マルチパス構成を有効にするコマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- 宛先システムの場所。ターゲットポータルの IP アドレス、関連付けられたポート番号、IQN 形式のターゲット iSCSI ノード、および iSCSI 論理ユニット番号 (LUN) を指定する必要があります。
- 4
- 宛先システムの Ignition 設定。
- 5
- IQN 形式の iSCSI イニシエーター、クライアントの名前。イニシエーターは iSCSI ターゲットに接続するセッションを形成します。
- 6
- IQN 形式の iSCSI ターゲットまたはサーバーの名前。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.3.13.3.8.5. iBFT を使用して iSCSI ブートデバイス用のライブインストール PXE 環境をカスタマイズする リンクのコピーリンクがクリップボードにコピーされました!
ライブ RHCOS イメージのカスタマイズされたバージョンを使用して、自動マウント、起動、および設定用の iSCSI ターゲットとイニシエーターの値を設定できます。
前提条件
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
-
coreos-installer
イメージミラー ページから、coreos-installer
バイナリーをダウンロードします。 RHCOS イメージミラー ページから、RHCOS
kernel
、initramfs
、およびrootfs
ファイルを取得し、次のコマンドを実行して、次の情報を含む新しいカスタマイズされたinitramfs
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストール前に実行されるスクリプト。iSCSI ターゲットをマウントするための
iscsiadm
コマンドが含まれている必要があります。 - 2
- インストール後に実行されるスクリプト。
iscsiadm --mode node --logout=all
コマンドが含まれている必要があります。 - 3
- デバイスへのパス。マルチパスを使用している場合は、マルチパスデバイス (
/dev/mapper/mpatha
) を使用します。複数のマルチパスデバイスが接続されている場合、または明示する場合、/dev/disk/by-path
で使用可能な World Wide Name (WWN) シンボリックリンクを使用できます。 - 4
- 宛先システムの Ignition 設定。
- 5
- iSCSI パラメーターは、BIOS ファームウェアから読み取られます。
- 6
- オプション: マルチパス構成を有効にする場合は、このパラメーターを含めます。
dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。
2.3.13.3.9. 詳細の RHCOS インストールリファレンス リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、Red Hat Enterprise Linux CoreOS (RHCOS) の手動インストールプロセスを変更できるようにするネットワーク設定および他の高度なオプションを説明します。以下の表では、RHCOS ライブインストーラーおよび coreos-installer
コマンドで使用できるカーネル引数およびコマンドラインのオプションを説明します。
2.3.13.3.9.1. ISO インストールのネットワークおよびボンディングのオプション リンクのコピーリンクがクリップボードにコピーされました!
ISO イメージから RHCOS をインストールする場合、そのイメージを起動してノードのネットワークを設定する際に手動でカーネル引数を追加できます。ネットワークの引数が指定されていない場合、RHCOS が Ignition 設定ファイルを取得するためにネットワークが必要であることを検知する際に、DHCP が initramfs でアクティベートされます。
ネットワーク引数を手動で追加する場合は、rd.neednet=1
カーネル引数を追加して、ネットワークを initramfs で有効にする必要があります。
以下の情報は、ISO インストール用に RHCOS ノードでネットワークおよびボンディングを設定する例を示しています。この例では、ip=
、nameserver=
、および bond=
カーネル引数の使用方法を説明しています。
順序は、カーネル引数の ip=
、nameserver=
、および bond=
を追加する場合に重要です。
ネットワークオプションは、システムの起動時に dracut
ツールに渡されます。dracut
でサポートされるネットワークオプションの詳細は、dracut.cmdline
man ページ を参照してください。
次の例は、ISO インストールのネットワークオプションです。
2.3.13.3.9.1.1. DHCP または静的 IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
IP アドレスを設定するには、DHCP (ip=dhcp
) を使用するか、個別の静的 IP アドレス (ip=<host_ip>
) を設定します。静的 IP を設定する場合、各ノードで DNS サーバー IP アドレス (nameserver=<dns_ip>
) を特定する必要があります。次の例では、以下を設定します。
-
ノードの IP アドレス:
10.10.10.2
-
ゲートウェイアドレス:
10.10.10.254
-
ネットワーク:
255.255.255.0
-
ホスト名:
core0.example.com
-
DNS サーバーアドレス:
4.4.4.41
-
auto-configuration の値を
none
に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none nameserver=4.4.4.41
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41
DHCP を使用して RHCOS マシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP ベースのデプロイメントの場合、DHCP サーバー設定を使用して RHCOS ノードが使用する DNS サーバーアドレスを定義できます。
2.3.13.3.9.1.2. 静的ホスト名を使用しない IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
静的ホスト名を割り当てずに IP アドレスを設定できます。静的ホスト名がユーザーによって設定されていない場合は、逆引き DNS ルックアップによって取得され、自動的に設定されます。静的ホスト名なしで IP アドレスを設定するには、次の例を参照してください。
-
ノードの IP アドレス:
10.10.10.2
-
ゲートウェイアドレス:
10.10.10.254
-
ネットワーク:
255.255.255.0
-
DNS サーバーアドレス:
4.4.4.41
-
auto-configuration の値を
none
に設定します。IP ネットワークが静的に設定されている場合には、自動設定は必要ありません。
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none nameserver=4.4.4.41
ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41
2.3.13.3.9.1.3. 複数のネットワークインターフェイスの指定 リンクのコピーリンクがクリップボードにコピーされました!
複数の ip=
エントリーを設定することで、複数のネットワークインターフェイスを指定できます。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
2.3.13.3.9.1.4. デフォルトゲートウェイとルートの設定 リンクのコピーリンクがクリップボードにコピーされました!
オプション: rd.route=
value を設定して、追加のネットワークへのルートを設定できます。
1 つまたは複数のネットワークを設定する場合、1 つのデフォルトゲートウェイが必要です。追加のネットワークゲートウェイがプライマリーネットワークゲートウェイと異なる場合、デフォルトゲートウェイはプライマリーネットワークゲートウェイである必要があります。
次のコマンドを実行して、デフォルトゲートウェイを設定します。
ip=::10.10.10.254::::
ip=::10.10.10.254::::
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、追加ネットワークのルートを設定します。
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.13.3.9.1.5. 単一インターフェイスでの DHCP の無効化 リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上のネットワークインターフェイスがあり、1 つのインターフェイスのみが使用される場合などに、1 つのインターフェイスで DHCP を無効にします。この例では、enp1s0
インターフェイスには静的ネットワーク設定があり、使用されていない enp2s0
では DHCP が無効になっています。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none ip=::::core0.example.com:enp2s0:none
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none
2.3.13.3.9.1.6. DHCP と静的 IP 設定の組み合わせ リンクのコピーリンクがクリップボードにコピーされました!
以下のように、複数のネットワークインターフェイスを持つシステムで、DHCP および静的 IP 設定を組み合わせることができます。
ip=enp1s0:dhcp ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none
2.3.13.3.9.1.7. 個々のインターフェイスでの VLAN の設定 リンクのコピーリンクがクリップボードにコピーされました!
オプション: vlan=
パラメーターを使用して、個別のインターフェイスに VLAN を設定できます。
ネットワークインターフェイスで VLAN を設定し、静的 IP アドレスを使用するには、次のコマンドを実行します。
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none vlan=enp2s0.100:enp2s0
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none vlan=enp2s0.100:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスで VLAN を設定し、DHCP を使用するには、次のコマンドを実行します。
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.13.3.9.1.8. 複数の DNS サーバーの指定 リンクのコピーリンクがクリップボードにコピーされました!
以下のように、各サーバーに nameserver=
エントリーを追加して、複数の DNS サーバーを指定できます。
nameserver=1.1.1.1 nameserver=8.8.8.8
nameserver=1.1.1.1
nameserver=8.8.8.8
2.3.13.3.9.1.9. 複数のネットワークインターフェイスの単一インターフェイスへのボンディング リンクのコピーリンクがクリップボードにコピーされました!
オプション: bond=
オプションを使用して、複数のネットワークインターフェイスを単一のインターフェイスにボンディングできます。次の例を参照してください。
ボンディングされたインターフェイスを設定するための構文は、
bond=<name>[:<network_interfaces>][:options]
です。<name>
はボンディングデバイス名 (bond0
)、<network_interfaces>
は物理 (イーサネット) インターフェイスのコンマ区切りのリスト (em1,em2
) を表し、options はボンディングオプションのコンマ区切りのリストです。modinfo bonding
を入力して、利用可能なオプションを表示します。bond=
を使用してボンディングされたインターフェイスを作成する場合は、ボンディングされたインターフェイスの IP アドレスの割り当て方法やその他の情報を指定する必要があります。DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを
dhcp
に設定します。以下に例を示します。bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:em1,em2:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
bond=bond0:em1,em2:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.13.3.9.1.10. 複数の SR-IOV ネットワークインターフェイスをデュアルポート NIC インターフェイスに結合する リンクのコピーリンクがクリップボードにコピーされました!
オプション: bond=
オプションを使用して、複数の SR-IOV ネットワークインターフェイスをデュアルポート NIC インターフェイスに結合できます。
各ノードで、次のタスクを実行する必要があります。
- SR-IOV デバイスの管理 のガイダンスに従って、SR-IOV 仮想機能 (VF) を作成します。「仮想マシンへの SR-IOV ネットワークデバイスの接続」セクションの手順に従います。
- ボンドを作成し、目的の VF をボンドに接続し、ネットワークボンディングの設定 のガイダンスに従って、ボンドリンクの状態を設定します。説明されている手順のいずれかに従って、結合を作成します。
次の例は、使用する必要がある構文を示しています。
結合インターフェイスを設定するための構文は、
bond=<name>[:<network_interfaces>][:options]
です。<name>
はボンディングデバイス名 (bond0
)、<network_interfaces>
は仮想機能 (VF) をカーネル内の既知の名前で表し、ip link
コマンド (eno1f0
、eno2f0
) の出力に表示されます。options は結合オプションのコンマ区切りリストです。modinfo bonding
を入力して、利用可能なオプションを表示します。bond=
を使用してボンディングされたインターフェイスを作成する場合は、ボンディングされたインターフェイスの IP アドレスの割り当て方法やその他の情報を指定する必要があります。DHCP を使用するようにボンディングされたインターフェイスを設定するには、ボンドの IP アドレスを
dhcp
に設定します。以下に例を示します。bond=bond0:eno1f0,eno2f0:mode=active-backup ip=bond0:dhcp
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=bond0:dhcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 静的 IP アドレスを使用するようにボンディングされたインターフェイスを設定するには、必要な特定の IP アドレスと関連情報を入力します。以下に例を示します。
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
bond=bond0:eno1f0,eno2f0:mode=active-backup ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.13.3.9.1.11. ネットワークチーミングの使用 リンクのコピーリンクがクリップボードにコピーされました!
任意: team=
パラメーターを指定して、ボンディングの代わりにネットワークチーミングを使用できます。
チームインターフェイス設定の構文は
team=name[:network_interfaces]
です。name はチームデバイス名 (
team0
)、network_interfaces は物理 (イーサネット) インターフェイス (em1, em2
) のコンマ区切りリストを表します。
RHCOS が次のバージョンの RHEL に切り替わると、チーミングは非推奨になる予定です。詳細は、こちらの Red Hat ナレッジベース記事 を参照してください。
次の例を使用して、ネットワークチームを設定します。
team=team0:em1,em2 ip=team0:dhcp
team=team0:em1,em2
ip=team0:dhcp
2.3.13.3.9.2. ISO および PXE インストール用の coreos-installer オプション リンクのコピーリンクがクリップボードにコピーされました!
RHCOS は、ISO イメージから RHCOS ライブ環境に起動した後に、コマンドプロンプトで coreos-installer install <options> <device>
を実行してインストールできます。
以下の表は、coreos-installer
コマンドに渡すことのできるサブコマンド、オプションおよび引数を示しています。
coreos-installer install サブコマンド | |
サブコマンド | 説明 |
| Ignition 設定を ISO イメージに埋め込みます。 |
coreos-installer install サブコマンドオプション | |
オプション | 説明 |
| イメージの URL を手動で指定します。 |
| ローカルイメージファイルを手動で指定します。デバッグに使用されます。 |
| ファイルから Ignition 設定を埋め込みます。 |
| URL から Ignition 設定を埋め込みます。 |
|
Ignition 設定の |
| インストール済みシステムの Ignition プラットフォーム ID を上書きします。 |
|
インストールされたシステムのカーネルとブートローダーコンソールを設定します。 |
| インストール済みシステムにデフォルトのカーネル引数を追加します。 |
| インストール済みシステムからデフォルトのカーネル引数を削除します。 |
| インストール環境からネットワーク設定をコピーします。 重要
|
|
|
| このラベル glob でパーティションを保存します。 |
| この数または範囲でパーティションを保存します。 |
| RHCOS イメージ署名の検証を省略します。 |
| HTTPS またはハッシュなしで Ignition URL を許可します。 |
|
ターゲット CPU アーキテクチャー。有効な値は |
| エラー時のパーティションテーブルは消去しないでください。 |
| ヘルプ情報を表示します。 |
coreos-installer インストールサブコマンド引数 | |
引数 | 説明 |
| 宛先デバイス。 |
coreos-installer ISO サブコマンド | |
サブコマンド | 説明 |
| RHCOS ライブ ISO イメージをカスタマイズします。 |
| RHCOS ライブ ISO イメージをデフォルト設定に復元します。 |
| ISO イメージから埋め込まれた Ignition 設定を削除します。 |
coreos-installer ISO カスタマイズサブコマンドオプション | |
オプション | 説明 |
| 指定された Ignition 設定ファイルを宛先システムの新しい設定フラグメントにマージします。 |
| 宛先システムのカーネルとブートローダーコンソールを指定します。 |
| 指定した宛先デバイスをインストールして上書きします。 |
| 宛先システムの各起動にカーネル引数を追加します。 |
| 宛先システムの各起動からカーネル引数を削除します。 |
| ライブシステムと宛先システムに指定された NetworkManager キーファイルを使用してネットワークを設定します。 |
| Ignition によって信頼される追加の TLS 認証局を指定します。 |
| インストールする前に、指定されたスクリプトを実行します。 |
| インストール後に指定されたスクリプトを実行します。 |
| 指定されたインストーラー設定ファイルを適用します。 |
| 指定された Ignition 設定ファイルをライブ環境の新しい設定フラグメントにマージします。 |
| ライブ環境の各ブートにカーネル引数を追加します。 |
| ライブ環境の各ブートからカーネル引数を削除します。 |
|
ライブ環境の各起動で、 |
| 既存の Ignition 設定を上書きします。 |
| 新しい出力ファイルに ISO を書き込みます。 |
| ヘルプ情報を表示します。 |
coreos-installer PXE サブコマンド | |
サブコマンド | 説明 |
これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。 | |
| RHCOS ライブ PXE ブート設定をカスタマイズします。 |
| イメージに Ignition 設定をラップします。 |
| イメージでラップされた Ignition 設定を表示します。 |
coreos-installer PXE はサブコマンドオプションをカスタマイズします | |
オプション | 説明 |
これらのオプションすべてがすべてのサブコマンドで使用できる訳ではないことに注意してください。 | |
| 指定された Ignition 設定ファイルを宛先システムの新しい設定フラグメントにマージします。 |
| 宛先システムのカーネルとブートローダーコンソールを指定します。 |
| 指定した宛先デバイスをインストールして上書きします。 |
| ライブシステムと宛先システムに指定された NetworkManager キーファイルを使用してネットワークを設定します。 |
| Ignition によって信頼される追加の TLS 認証局を指定します。 |
| インストールする前に、指定されたスクリプトを実行します。 |
| インストール後に指定されたスクリプトを実行します。 |
| 指定されたインストーラー設定ファイルを適用します。 |
| 指定された Ignition 設定ファイルをライブ環境の新しい設定フラグメントにマージします。 |
| initramfs を新しい出力ファイルに書き込みます。 注記 このオプションは、PXE 環境に必要です。 |
| ヘルプ情報を表示します。 |
2.3.13.3.9.3. ISO または PXE インストールの coreos.inst ブートオプション リンクのコピーリンクがクリップボードにコピーされました!
coreos.inst
ブートパラメーターを RHCOS ライブインストーラーに渡して、ブート時に coreos-installer
オプションを自動的に起動できます。これらは、標準のブート引数の追加として提供されます。
-
ISO インストールの場合、ブートローダーメニューで自動ブートを中断して
coreos.inst
オプションを追加できます。RHEL CoreOS (Live) メニューオプションが強調表示されている状態でTAB
を押すと、自動ブートを中断できます。 -
PXE または iPXE インストールの場合、RHCOS ライブインストーラーのブート前に
coreos.inst
オプションをAPPEND
行に追加する必要があります。
以下の表は、ISO および PXE インストールの RHCOS ライブインストーラーの coreos.inst
ブートオプションを示しています。
引数 | 説明 |
---|---|
| 必須。インストール先のシステムのブロックデバイス。 注記
|
| オプション: インストール済みシステムに埋め込む Ignition 設定の URL。URL が指定されていない場合、Ignition 設定は埋め込まれません。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。 |
| オプション: インストール時に保存するパーティションのコンマ区切りのラベル。glob 形式のワイルドカードが許可されます。指定したパーティションは存在する必要はありません。 |
|
オプション: インストール時に保存するパーティションのコンマ区切りのインデックス。範囲 |
|
オプション: |
| オプション: 指定した RHCOS イメージをダウンロードし、インストールします。
|
| オプション: システムはインストール後に再起動しません。インストールが完了するとプロンプトが表示され、インストール時に生じる内容を検査できます。この引数は実稼働環境では使用できず、デバッグの目的でのみ使用することが意図されています。 |
|
オプション: RHCOS イメージがインストールされるプラットフォームの Ignition プラットフォーム ID。デフォルトは |
|
オプション: ライブ起動の Ignition 設定の URL。たとえば、これは |
2.3.13.4. RHCOS のカーネル引数でのマルチパスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS はプライマリーディスクでのマルチパスをサポートするようになり、ハードウェア障害に対する対障害性が強化され、ホストの可用性を強化できるようになりました。
OpenShift Container Platform 4.8 以降でプロビジョニングされたノードのマルチパスを有効にできます。インストール後のサポートは、マシン設定を使用してマルチパスをアクティベートすることで利用できますが、インストール中にマルチパスを有効にすることが推奨されます。
非最適化パスに対して I/O があると、I/O システムエラーが発生するように設定するには、インストール時にマルチパスを有効にする必要があります。
IBM Z® および IBM® LinuxONE では、インストール時にクラスターを設定した場合のみマルチパスを有効にできます。詳細は、IBM Z® および IBM® LinuxONE への z/VM を使用したクラスターのインストール の RHCOS の「インストールおよび OpenShift Container Platform ブートストラッププロセスの開始」を参照してください。
以下の手順では、インストール時にマルチパスを有効にし、coreos-installer install
コマンドにカーネル引数を追加して、インストール済みシステム自体が初回起動からマルチパスを使用できるようにします。
OpenShift Container Platform は、4.6 以前からアップグレードされたノードでの day-2 アクティビティーとしてのマルチパスの有効化をサポートしません。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 を確認した。
手順
マルチパスを有効にして
multipathd
デーモンを起動するには、インストールホストで次のコマンドを実行します。mpathconf --enable && systemctl start multipathd.service
$ mpathconf --enable && systemctl start multipathd.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
必要に応じて、PXE または ISO を起動する場合は、カーネルコマンドラインから
rd.multipath=default
を追加することで、マルチパスを有効にできます。
-
必要に応じて、PXE または ISO を起動する場合は、カーネルコマンドラインから
coreos-installer
プログラムを呼び出してカーネル引数を追加します。マシンに接続されているマルチパスデバイスが 1 つしかない場合は、このデバイスは
/dev/mapper/mpatha
のパスで利用できます。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 1 つのマルチパスデバイスのパスを指定します。
複数のマルチパスデバイスがマシンに接続している場合には、より明示的に
/dev/mapper/mpatha
を使用する代わりに、/dev/disk/by-id
で利用可能な World Wide Name (WWN) シンボリックリンクを使用することが推奨されます。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マルチパス化されたデバイスの WWN ID を指定します。例:
0xx194e957fcedb4841
特別な
coreos.inst.*
引数を使用してライブインストーラーを指定する場合に、このシンボリックリンクをcoreos.inst.install_dev
カーネル引数として使用することもできます。詳細は、「RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始」を参照してください。
- インストール済みのシステムで再起動します。
ワーカーノードのいずれかに移動し、(ホストの
/proc/cmdline
内の) カーネルコマンドライン引数をリスト表示して、カーネル引数が機能していることを確認します。oc debug node/ip-10-0-141-105.ec2.internal
$ oc debug node/ip-10-0-141-105.ec2.internal
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加したカーネル引数が表示されるはずです。
2.3.13.4.1. セカンダリーディスクでのマルチパス構成の有効化 リンクのコピーリンクがクリップボードにコピーされました!
RHCOS はセカンダリーディスク上のマルチパス構成もサポートします。カーネル引数の代わりに、Ignition を使用してインストール時にセカンダリーディスクのマルチパス構成を有効にします。
前提条件
- ディスクのパーティション設定 セクションを読了した。
- RHCOS のカーネル引数でのマルチパスの有効化 を読了した。
- Butane ユーティリティーをインストールした。
手順
次のような情報を含む Butane 設定を作成します。
multipath-config.bu
の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Ignition 設定を作成します。
butane --pretty --strict multipath-config.bu > multipath-config.ign
$ butane --pretty --strict multipath-config.bu > multipath-config.ign
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 初回起動時の RHCOS インストールプロセスの残りを続行します。
重要プライマリーディスクもマルチパス化されていない限り、インストール中にコマンドラインに
rd.multipath
またはroot
カーネル引数を追加しないでください。
2.3.13.5. iSCSI ブートデバイスに RHCOS を手動でインストールする リンクのコピーリンクがクリップボードにコピーされました!
iSCSI ターゲットに、手動で RHCOS をインストールできます。
前提条件
- RHCOS ライブ環境にいる。
- RHCOS のインストール先となる iSCSI ターゲットがある。
手順
次のコマンドを実行して、ライブ環境から iSCSI ターゲットをマウントします。
iscsiadm \ --mode discovery \ --type sendtargets
$ iscsiadm \ --mode discovery \ --type sendtargets --portal <IP_address> \
1 --login
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ターゲットポータルの IP アドレス。
次のコマンドを実行し、必要なカーネル引数を使用して、RHCOS を iSCSI ターゲットにインストールします。以下はその例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。次のコマンドを実行して iSCSI ディスクをアンマウントします。
iscsiadm --mode node --logoutall=all
$ iscsiadm --mode node --logoutall=all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順は、coreos-installer iso customize
または coreos-installer pxe customize
サブコマンドを使用して実行することもできます。
2.3.13.6. iBFT を使用して iSCSI ブートデバイスに RHCOS をインストールする リンクのコピーリンクがクリップボードにコピーされました!
完全にディスクレスなマシンでは、iSCSI ターゲットとイニシエーターの値を iBFT 経由で渡すことができます。iSCSI マルチパス構成もサポートされています。
前提条件
- RHCOS ライブ環境にいる。
- RHCOS のインストール先となる iSCSI ターゲットがある。
- オプション: iSCSI ターゲットをマルチパス化した。
手順
次のコマンドを実行して、ライブ環境から iSCSI ターゲットをマウントします。
iscsiadm \ --mode discovery \ --type sendtargets
$ iscsiadm \ --mode discovery \ --type sendtargets --portal <IP_address> \
1 --login
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ターゲットポータルの IP アドレス。
オプション: マルチパス構成を有効にし、次のコマンドでデーモンを起動します。
mpathconf --enable && systemctl start multipathd.service
$ mpathconf --enable && systemctl start multipathd.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、必要なカーネル引数を使用して、RHCOS を iSCSI ターゲットにインストールします。以下はその例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dracut
でサポートされる iSCSI オプションの詳細は、dracut.cmdline
man ページ を参照してください。iSCSI ディスクをアンマウントします。
iscsiadm --mode node --logout=all
$ iscsiadm --mode node --logout=all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この手順は、coreos-installer iso customize
または coreos-installer pxe customize
サブコマンドを使用して実行することもできます。
2.3.14. ブートストラッププロセスの完了まで待機する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
- RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
手順
ブートストラッププロセスをモニターします。
./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ --log-level=info
$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \
1 --log-level=info
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.32.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.32.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。
2.3.15. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、
kubeadmin
認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
次のコマンドを実行し、エクスポートされた設定を使用して
oc
コマンドを正常に実行できることを確認します。oc whoami
$ oc whoami
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.16. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.32.3 master-1 Ready master 63m v1.32.3 master-2 Ready master 64m v1.32.3
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.32.3 master-1 Ready master 63m v1.32.3 master-2 Ready master 64m v1.32.3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
Pending
またはApproved
ステータスが表示されていることを確認します。oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードの ID を確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りの CSR が承認されず、それらが
Pending
ステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>
は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
2.3.17. Operator の初期設定 リンクのコピーリンクがクリップボードにコピーされました!
コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。
前提条件
- コントロールプレーンが初期化されています。
手順
クラスターコンポーネントがオンラインになることを確認します。
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 利用不可の Operator を設定します。
2.3.17.1. デフォルトの OperatorHub カタログソースの無効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
2.3.17.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
2.3.17.2.1. イメージレジストリーの管理状態の変更 リンクのコピーリンクがクリップボードにコピーされました!
イメージレジストリーを起動するには、Image Registry Operator 設定の managementState
を Removed
から Managed
に変更する必要があります。
手順
managementState
Image Registry Operator 設定をRemoved
からManaged
に変更します。以下に例を示します。oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.17.2.2. ベアメタルおよび他の手動インストールの場合のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - ベアメタルなどの、手動でプロビジョニングされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードを使用するクラスターがある。
Red Hat OpenShift Data Foundation などのクラスターのプロビジョニングされた永続ストレージがある。
重要OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの
ReadWriteOnce
アクセスをサポートします。ReadWriteOnce
アクセスでは、レジストリーがRecreate
ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany
アクセスが必要です。- 100 Gi の容量がある。
手順
レジストリーをストレージを使用できるように設定するには、
configs.imageregistry/cluster
リソースのspec.storage.pvc
を変更します。注記共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。
レジストリー Pod がないことを確認します。
oc get pod -n openshift-image-registry -l docker-registry=default
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resources found in openshift-image-registry namespace
No resources found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
storage: pvc: claim:
storage: pvc: claim:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow claim
フィールドを空のままにし、image-registry-storage
PVC の自動作成を可能にします。clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.19 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.19 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。
以下を実行します。
oc edit configs.imageregistry/cluster
$ oc edit configs.imageregistry/cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、行を変更します。
managementState: Removed
managementState: Removed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のように変更してください。
managementState: Managed
managementState: Managed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.17.2.3. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。
手順
イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。
oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告実稼働用以外のクラスターにのみこのオプションを設定します。
Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、
oc patch
コマンドは以下のエラーを出して失敗します。Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 数分待機した後に、このコマンドを再び実行します。
2.3.17.2.4. ベアメタルの場合のブロックレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
イメージレジストリーがクラスター管理者によるアップグレード時にブロックストレージタイプを使用できるようにするには、Recreate
ロールアウトストラテジーを使用できます。
ブロックストレージボリューム (または永続ボリューム) はサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。
イメージレジストリーでブロックストレージボリュームを使用することを選択した場合は、ファイルシステムの persistent volume claim (PVC) を使用する必要があります。
手順
次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して
Recreate
ロールアウトストラテジーを使用し、1 つの (1
) レプリカのみで実行されるようにします。oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。
以下の内容で
pvc.yaml
ファイルを作成して VMware vSpherePersistentVolumeClaim
オブジェクトを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ファイルから
PersistentVolumeClaim
オブジェクトを作成します。oc create -f pvc.yaml -n openshift-image-registry
$ oc create -f pvc.yaml -n openshift-image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。
oc edit config.imageregistry.operator.openshift.io -o yaml
$ oc edit config.imageregistry.operator.openshift.io -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
storage: pvc: claim:
storage: pvc: claim:
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- カスタム PVC を作成することにより、
image-registry-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
2.3.18. user-provisioned infrastructure でのインストールの完了 リンクのコピーリンクがクリップボードにコピーされました!
Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。
前提条件
- コントロールプレーンが初期化されています。
- Operator の初期設定を完了済みです。
手順
以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。
./openshift-install --dir <installation_directory> wait-for install-complete
$ ./openshift-install --dir <installation_directory> wait-for install-complete
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
出力例
INFO Waiting up to 30m0s for the cluster to initialize...
INFO Waiting up to 30m0s for the cluster to initialize...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
Kubernetes API サーバーが Pod と通信していることを確認します。
すべての Pod のリストを表示するには、以下のコマンドを使用します。
oc get pods --all-namespaces
$ oc get pods --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。
oc logs <pod_name> -n <namespace>
$ oc logs <pod_name> -n <namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前のコマンドの出力にあるように、Pod 名および namespace を指定します。
Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。
FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。
詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。
- Cluster registration ページでクラスターを登録します。
2.3.19. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
2.3.20. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- インストールの検証
- クラスターのカスタマイズ
-
Cluster Samples Operator および
must-gather
ツールの イメージストリームを設定 します。 - 非接続環境で Operator Lifecycle Manager を使用 する方法を確認します。
- クラスターのインストールに使用したミラーレジストリーに信頼された CA がある場合は、追加のトラストストアを設定 してクラスターに追加します。
- 必要に応じて、リモートヘルスレポート を作成できます。
- 必要に応じて、非接続クラスターの登録 を参照してください。
2.4. Bare Metal Operator を使用したユーザープロビジョニングクラスターのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure クラスターをデプロイした後、Bare Metal Operator (BMO) およびその他の metal3 コンポーネントを使用して、クラスター内のベアメタルホストをスケーリングできます。このアプローチは、ユーザーがプロビジョニングしたクラスターをより自動化された方法でスケーリングするために役立ちます。
2.4.1. Bare Metal Operator を使用したユーザープロビジョニングクラスターのスケーリングについて リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal Operator (BMO) およびその他の metal3 コンポーネントを使用して、user-provisioned infrastructure クラスターをスケーリングできます。user-provisioned infrastructure のインストールには、Machine API Operator が含まれていません。通常は Machine API Operator がクラスター内のベアメタルノードのライフサイクルを管理します。しかし、Machine API Operator がなくても、BMO およびその他の metal3 コンポーネントを使用して、ユーザーがプロビジョニングしたクラスター内のノードをスケーリングすることは可能です。
2.4.1.1. ユーザーがプロビジョニングしたクラスターをスケーリングするための前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- user-provisioned infrastructure クラスターをベアメタルにインストールしました。
- ホストへのベースボード管理コントローラー (BMC) アクセス権限がある。
2.4.1.2. ユーザーがプロビジョニングしたクラスターのスケーリングに関する制限事項 リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal Operator (BMO) では、プロビジョニングネットワークを使用して、user-provisioned infrastructure クラスターをスケーリングすることはできません。
-
したがって、仮想メディアネットワークの起動をサポートするベアメタルホストドライバー (
redfish-virtualmedia
やidrac-virtualmedia
など) のみを使用できます。
-
したがって、仮想メディアネットワークの起動をサポートするベアメタルホストドライバー (
-
BMO を使用して、user-provisioned infrastructure クラスター内の
MachineSet
オブジェクトをスケーリングすることはできません。
2.4.2. ユーザーがプロビジョニングしたクラスターをスケーリングするためのプロビジョニングリソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
Provisioning
カスタムリソース (CR) を作成して、user-provisioned infrastructure クラスターで Metal プラットフォームコンポーネントを有効にします。
前提条件
- user-provisioned infrastructure クラスターをベアメタルにインストールしました。
手順
Provisioning
CR を作成します。次の YAML を
provisioning.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform 4.19 では、Bare Metal Operator を使用してユーザーがプロビジョニングしたクラスターをスケーリングする場合、プロビジョニングネットワークの有効化がサポートされません。
次のコマンドを実行して、
Provisioning
CR を作成します。oc create -f provisioning.yaml
$ oc create -f provisioning.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
provisioning.metal3.io/provisioning-configuration created
provisioning.metal3.io/provisioning-configuration created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、プロビジョニングサービスが実行されていることを確認します。
oc get pods -n openshift-machine-api
$ oc get pods -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.3. BMO を使用して、ユーザーがプロビジョニングしたクラスターで新しいホストをプロビジョニングする リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal Operator (BMO) を使用して、BareMetalHost
カスタムリソース (CR) を作成すると、ユーザーがプロビジョニングしたクラスターにベアメタルホストをプロビジョニングできます。
BMO を使用してベアメタルホストをクラスターにプロビジョニングすると、BareMetalHost
カスタムリソースの spec.externallyProvisioned
仕様がデフォルトで false
に設定されます。spec.externallyProvisioned
仕様を true
に設定しないでください。この設定により予期しない動作が発生するためです。
前提条件
- ユーザーがプロビジョニングしたベアメタルクラスターを作成しました。
- ホストへのベースボード管理コントローラー (BMC) アクセス権限がある。
-
Provisioning
CR を作成して、クラスターにプロビジョニングサービスをデプロイしました。
手順
ベアメタルノードの設定ファイルを作成します。静的設定を使用するか、DHCP サーバーを使用するかに応じて、次のサンプル
bmh.yaml
ファイルのいずれかを選択します。YAML 内の値を環境に合わせて置き換えて、ニーズに合わせて設定します。静的設定でデプロイする場合は、次の
bmh.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
name
、credentialsName
、およびpreprovisioningNetworkDataName
フィールドのすべての<num>
を、ベアメタルノードの一意のコンピュートノード番号に置き換えます。- 2
- NMState YAML 構文を追加して、ホストインターフェイスを設定します。新しく作成されたノードのネットワークインターフェイスを設定するには、ネットワーク設定が含まれるシークレットの名前を指定します。
nmstate
構文に従って、ノードのネットワーク設定を定義します。NMState 構文の設定の詳細は、「ベアメタルノードの準備」を参照してください。 - 3
- オプション:
nmstate
を使用してネットワークインターフェイスを設定しており、インターフェイスを無効にする場合は、IP アドレスをenabled: false
に設定してstate: up
を設定します。 - 4
<nic1_name>
は、ベアメタルノードの最初のネットワークインターフェイスコントローラー (NIC) の名前に置き換えます。- 5
<ip_address>
は、ベアメタルノードの NIC の IP アドレスに置き換えます。- 6
<dns_ip_address>
は、ベアメタルノードの DNS リゾルバーの IP アドレスに置き換えます。- 7
<next_hop_ip_address>
は、ベアメタルノードの外部ゲートウェイの IP アドレスに置き換えます。- 8
<next_hop_nic1_name>
は、ベアメタルノードの外部ゲートウェイの名前に置き換えます。- 9
<base64_of_uid>
と<base64_of_pwd>
は、ユーザー名とパスワードの base64 文字列に置き換えます。- 10
<nic1_mac_address>
は、ベアメタルノードの最初の NIC の MAC アドレスに置き換えます。追加の BMC 設定オプションは、「BMC アドレス指定」のセクションを参照してください。- 11
<protocol>
は、IPMI、Redfish などの BMC プロトコルに置き換えます。<bmc_url>
は、ベアメタルノードのベースボード管理コントローラーの URL に置き換えます。- 12
- オプション: ルートデバイスのヒントを指定する場合は、
<root_device_hint>
をデバイスパスに置き換えます。詳細は、「ルートデバイスのヒント」を参照してください。
nmstate
を使用して静的設定でネットワークインターフェイスを設定する場合は、IP アドレスをenabled: false
に設定してstate: up
を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow DHCP 設定でデプロイする場合は、次の
bmh.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
name
およびcredentialsName
フィールドの<num>
は、ベアメタルノードの一意のコンピュートノード番号に置き換えます。- 2
<base64_of_uid>
と<base64_of_pwd>
は、ユーザー名とパスワードの base64 文字列に置き換えます。- 3
<nic1_mac_address>
は、ベアメタルノードの最初の NIC の MAC アドレスに置き換えます。追加の BMC 設定オプションは、「BMC アドレス指定」のセクションを参照してください。- 4
<protocol>
は、IPMI、Redfish などの BMC プロトコルに置き換えます。<bmc_url>
は、ベアメタルノードのベースボード管理コントローラーの URL に置き換えます。- 5
- オプション: ルートデバイスのヒントを指定する場合は、
<root_device_hint>
をデバイスパスに置き換えます。詳細は、「ルートデバイスのヒント」を参照してください。
重要既存のベアメタルノードの MAC アドレスが、プロビジョニングしようとしているベアメタルホストの MAC アドレスと一致する場合、インストールが失敗します。ホストの登録、検査、クリーニング、またはその他の手順が失敗した場合、Bare Metal Operator がインストールを継続的に再試行します。詳細は、「クラスター内の新しいホストをプロビジョニングする際の重複する MAC アドレスの診断」を参照してください。
次のコマンドを実行してベアメタルノードを作成します。
oc create -f bmh.yaml
$ oc 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 次のコマンドを実行してベアメタルノードを検査します。
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> provisioned true
NAME STATE CONSUMER ONLINE ERROR openshift-worker-<num> provisioned true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべての証明書署名要求 (CSR) を承認します。
次のコマンドを実行して、保留中の CSR のリストを取得します。
oc get csr
$ oc get csr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION csr-gfm9f 33s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-o perator:node-bootstrapper <none> Pending
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION csr-gfm9f 33s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-o perator:node-bootstrapper <none> Pending
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、CSR を承認します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
certificatesigningrequest.certificates.k8s.io/<csr_name> approved
certificatesigningrequest.certificates.k8s.io/<csr_name> approved
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、ノードの準備ができていることを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION app1 Ready worker 47s v1.24.0+dc5a2fd controller1 Ready master,worker 2d22h v1.24.0+dc5a2fd
NAME STATUS ROLES AGE VERSION app1 Ready worker 47s v1.24.0+dc5a2fd controller1 Ready master,worker 2d22h v1.24.0+dc5a2fd
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.4. オプション: BMO を使用して、ユーザーがプロビジョニングしたクラスターで既存のホストを管理する リンクのコピーリンクがクリップボードにコピーされました!
オプションで、Bare Metal Operator (BMO) を使用して、既存のホストの BareMetalHost
オブジェクトを作成すると、ユーザーがプロビジョニングしたクラスターで既存のベアメタルコントローラーホストを管理できます。ユーザーがプロビジョニングした既存のホストを管理する必要はありません。ただし、それらをインベントリー目的で外部プロビジョニングされたホストとして登録することはできます。
BMO を使用して、既存のホストを管理するには、BareMetalHost
カスタムリソースの spec.externallyProvisioned
仕様を true
に設定して、BMO がホストを再プロビジョニングしないようにする必要があります。
前提条件
- ユーザーがプロビジョニングしたベアメタルクラスターを作成しました。
- ホストへのベースボード管理コントローラー (BMC) アクセス権限がある。
-
Provisioning
CR を作成して、クラスターにプロビジョニングサービスをデプロイしました。
手順
Secret
CR とBareMetalHost
CR を作成します。次のコマンドを実行して、ベアメタルホストオブジェクトを作成します。
oc create -f controller.yaml
$ oc create -f controller.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
secret/controller1-bmc created baremetalhost.metal3.io/controller1 created
secret/controller1-bmc created baremetalhost.metal3.io/controller1 created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、BMO がベアメタルホストオブジェクトを作成したことを確認します。
oc get bmh -A
$ oc get bmh -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE openshift-machine-api controller1 externally provisioned true 13s
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE openshift-machine-api controller1 externally provisioned true 13s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.5. BMO を使用して、ユーザーがプロビジョニングしたクラスターからホストを削除する リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal Operator (BMO) を使用して、ユーザーがプロビジョニングしたクラスターからベアメタルホストを削除できます。
前提条件
- ユーザーがプロビジョニングしたベアメタルクラスターを作成しました。
- ホストへのベースボード管理コントローラー (BMC) アクセス権限がある。
-
Provisioning
CR を作成して、クラスターにプロビジョニングサービスをデプロイしました。
手順
次のコマンドを実行して、ノードをスケジューリング対象から外してドレインします。
oc adm drain app1 --force --ignore-daemonsets=true
$ oc adm drain app1 --force --ignore-daemonsets=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BareMetalHost
CR からcustomDeploy
仕様を削除します。次のコマンドを実行して、ホストの
BareMetalHost
CR を編集します。oc edit bmh -n openshift-machine-api <host_name>
$ oc edit bmh -n openshift-machine-api <host_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.customDeploy
およびspec.customDeploy.method
の行を削除します。... customDeploy: method: install_coreos
... customDeploy: method: install_coreos
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ホストのプロビジョニング状態が
deprovisioning
に変わることを確認します。oc get bmh -A
$ oc get bmh -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE openshift-machine-api controller1 externally provisioned true 58m openshift-machine-api worker1 deprovisioning true 57m
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE openshift-machine-api controller1 externally provisioned true 58m openshift-machine-api worker1 deprovisioning true 57m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
BareMetalHost
の状態がavailable
に変わったら、次のコマンドを実行してホストを削除します。oc delete bmh -n openshift-machine-api <bmh_name>
$ oc delete bmh -n openshift-machine-api <bmh_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このステップは、
BareMetalHost
CR を編集しなくても実行できます。BareMetalHost
の状態がdeprovisioning
からavailable
に変わるまでに、しばらく時間がかかる場合があります。次のコマンドを実行して、ノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、ノードが削除されたことを確認します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION controller1 Ready master,worker 2d23h v1.24.0+dc5a2fd
NAME STATUS ROLES AGE VERSION controller1 Ready master,worker 2d23h v1.24.0+dc5a2fd
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. ベアメタルのインストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、環境の詳細を記述するカスタマイズされた install-config.yaml
インストール設定ファイルを指定します。
2.5.1. ベアメタルで利用可能なインストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下の表に、インストールプロセスの一部として設定できる必須、オプション、およびベアメタル固有のインストール設定パラメーターを示します。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
2.5.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 |
---|---|
apiVersion:
|
値: 文字列 |
baseDomain:
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、
値: |
metadata:
|
Kubernetes リソース 値: オブジェクト |
metadata: name:
|
クラスターの名前。クラスターの DNS レコードはすべて
値: 小文字とハイフン ( |
platform:
|
インストールを実行する特定のプラットフォームの設定: 値: オブジェクト |
pullSecret:
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 値: |
2.5.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張したり、デフォルトとは異なる IP アドレスブロックを設定したりすることができます。
クラスターのネットワークパラメーターを設定する前に、次の情報を考慮してください。
- Red Hat OpenShift Networking OVN-Kubernetes ネットワークプラグインを使用する場合、IPv4 と IPv6 の両方のアドレスファミリーがサポートされます。
IPv4 アドレスと非リンクローカル IPv6 アドレスの両方をサポートするネットワークを持つ OpenShift Container Platform クラスターにノードをデプロイした場合は、デュアルスタックネットワークを使用するようにクラスターを設定します。
- デュアルスタックネットワークに設定されたクラスターでは、IPv4 と IPv6 の両方のトラフィックがデフォルトゲートウェイとして同じネットワークインターフェイスを使用する必要があります。これにより、複数のネットワークインターフェイスコントローラー (NIC) 環境で、使用可能なネットワークインターフェイスに基づいて、使用する NIC をクラスターが検出できるようになります。詳細は、OVN-Kubernetes ネットワークプラグインについて の「OVN-Kubernetes IPv6 とデュアルスタックの制限」を参照してください。
- ネットワーク接続の問題を防ぐために、デュアルスタックネットワークをサポートするホストにシングルスタック IPv4 クラスターをインストールしないでください。
両方の IP アドレスファミリーを使用するようにクラスターを設定する場合は、次の要件を確認してください。
- どちらの IP ファミリーも、デフォルトゲートウェイに同じネットワークインターフェイスを使用する必要があります。
- 両方の IP ファミリーにデフォルトゲートウェイが必要です。
すべてのネットワーク設定パラメーターに対して、IPv4 アドレスと IPv6 アドレスを同じ順序で指定する必要があります。たとえば、次の設定では、IPv4 アドレスが IPv6 アドレスの前に記載されています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
パラメーター | 説明 |
---|---|
networking:
| クラスターのネットワークの設定。 値: オブジェクト 注記
インストール後に |
networking: networkType:
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。
値: |
networking: clusterNetwork:
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 値: オブジェクトの配列。以下に例を示します。 |
networking: clusterNetwork: cidr:
|
OVN-Kubernetes ネットワークプラグインを使用する場合は、IPv4 および IPv6 ネットワークを指定できます。
値: Classless Inter-Domain Routing (CIDR) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
networking: clusterNetwork: hostPrefix:
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 値: サブネット接頭辞。
IPv4 ネットワークの場合、デフォルト値は |
networking: serviceNetwork:
|
サービスの IP アドレスブロック。デフォルト値は OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。 OVN-Kubernetes ネットワークプラグインを使用する場合、IPv4 および IPv6 アドレスファミリーの両方に IP アドレスブロックを指定できます。 値: CIDR 形式の IP アドレスブロックを含む配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16 - fd02::/112
|
networking: machineNetwork:
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 値: オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
networking: machineNetwork: cidr:
|
値: CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
networking: ovnKubernetesConfig: ipv4: internalJoinSubnet:
|
値: CIDR 表記の IP ネットワークブロック。デフォルト値は |
2.5.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 |
---|---|
additionalTrustBundle:
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。このトラストバンドルは、プロキシーが設定されている場合にも使用される可能性があります。 値: 文字列 |
capabilities:
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 値: 文字列の配列 |
capabilities: baselineCapabilitySet:
|
有効にするオプション機能の初期セットを選択します。有効な値は 値: 文字列 |
capabilities: additionalEnabledCapabilities:
|
オプションの機能のセットを、 値: 文字列の配列 |
cpuPartitioningMode:
| ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングを有効にできるのはインストール時のみです。インストール後は無効にできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。
値: |
compute:
| コンピュートノードを構成するマシンの設定。
値: |
compute: architecture:
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は、 値: 文字列 |
compute: hyperthreading:
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。
値: |
compute: name:
|
値: |
compute: platform:
|
値: |
compute: replicas:
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。
値: |
featureSet:
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。
値: 文字列。 |
controlPlane:
| コントロールプレーンを構成するマシンの設定。
値: |
controlPlane: architecture:
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は、 値: 文字列 |
controlPlane: hyperthreading:
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。
値: |
controlPlane: name:
|
値: |
controlPlane: platform:
|
値: |
controlPlane: replicas:
| プロビジョニングするコントロールプレーンマシンの数。
値: サポートされる値は |
credentialsMode:
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、認証と認可 コンテンツの「クラウドプロバイダーの認証情報の管理」を参照してください。
値: |
fips:
|
FIPS モードを有効または無効にします。デフォルトは 重要 クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。 FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。 重要 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。
値: |
imageContentSources:
| release-image コンテンツのソースおよびリポジトリー。
値: オブジェクトの配列。この表の以下の行で説明されているように、 |
imageContentSources: source:
|
値: 文字列 |
imageContentSources: mirrors:
| 同じイメージが含まれている可能性があるリポジトリーを 1 つ以上指定します。 値: 文字列の配列 |
publish:
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。
値:
このパラメーターを 重要
フィールドの値が |
sshKey:
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
値: たとえば、 |
第3章 installer-provisioned infrastructure リンクのコピーリンクがクリップボードにコピーされました!
3.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 仮想 IP はコンピュートノードに移動します。keepalived
インスタンスは Ingress VIP も管理します。
次の図は、デプロイメントのフェーズ 2 を示しています:
これ以降、プロビジョナーが使用するノードを削除または再利用できます。ここから、追加のプロビジョニングタスクはすべてコントロールプレーンによって実行されます。
installer-provisioned infrastructure によるインストールの場合、ポート 53 が CoreDNS によってノードレベルで公開され、他のルーティング可能なネットワークからアクセスできるようになります。
プロビジョニングネットワークは任意ですが、PXE ブートには必要です。プロビジョニングネットワークなしでデプロイする場合は、redfish-virtualmedia
または idrac-virtualmedia
などの仮想メディアベースボード管理コントローラー (BMC) アドレス指定オプションを使用する必要があります。
3.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の installer-provisioned installation には、以下が必要です。
- 1 つの Red Hat Enterprise Linux (RHEL) 9.x がインストールされているプロビジョナーノード。プロビジョナーは、インストール後に削除できます。
- 3 つのコントロールプレーンノード
- ベースボード管理コントローラー (BMC) の各ノードへのアクセス。
1 つ以上のネットワーク:
- 1 つの必須のルーティング可能なネットワーク
- 1 つのオプションのプロビジョニングネットワーク
- 1 つのオプションの管理ネットワーク
OpenShift Container Platform の installer-provisioned installation を開始する前に、ハードウェア環境が以下の要件を満たしていることを確認してください。
3.2.1. ノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
installer-provisioned installation には、ハードウェアノードの各種の要件があります。
-
CPU architecture: すべてのノードは
x86_64
またはaarch64
CPU アーキテクチャーを使用する必要があります。 - 同様のノード: Red Hat では、ノードにロールごとに同じ設定を指定することを推奨しています。つまり Red Hat では、同じ CPU、メモリー、ストレージ設定の同じブランドおよびモデルのノードを使用することを推奨しています。
-
ベースボード管理コントローラー:
provisioner
ノードは、各 OpenShift Container Platform クラスターノードのベースボード管理コントローラー (BMC) にアクセスできる必要があります。IPMI、Redfish、またはプロプライエタリープロトコルを使用できます。 -
最新の生成: ノードは最新の生成されたノードである必要があります。installer-provisioned installation は、ノード間で互換性を確保する必要のある BMC プロトコルに依存します。また、RHEL 9 には RAID コントローラーの最新のドライバーが同梱されています。ノードが、
provisioner
ノードの RHEL 9.x と、コントロールプレーンおよびワーカーノードの RHCOS 9.x をサポートするために必要な新しいバージョンのノードでであることを確認します。 - レジストリーノード: (オプション) 非接続のミラーリングされていないレジストリーを設定する場合、レジストリーは独自のノードに置くことが推奨されます。
-
プロビジョナーノード: installer-provisioned installation には 1 つの
provisioner
ノードが必要です。 - コントロールプレーン: installer-provisioned installation には、高可用性を実現するために 3 つのコントロールプレーンノードが必要です。3 つのコントロールプレーンノードのみで OpenShift Container Platform クラスターをデプロイして、コントロールプレーンノードをワーカーノードとしてスケジュール可能にすることができます。小規模なクラスターでは、開発、実稼働およびテスト時の管理者および開発者に対するリソース効率が高くなります。
ワーカーノード: 必須ではありませんが、一般的な実稼働クラスターには複数のワーカーノードがあります。
重要ワーカーノードが 1 つしかないクラスターは、パフォーマンスが低下した状態のルーターおよび Ingress トラフィックでデプロイされるので、デプロイしないでください。
ネットワークインターフェイス: 各ノードでは、ルーティング可能な
baremetal
ネットワークに 1 つ以上のネットワークインターフェイスが必要です。デプロイメントにprovisioning
ネットワークを使用する場合、各ノードにprovisioning
ネットワーク用に 1 つのネットワークインターフェイスが必要になります。provisioning
ネットワークの使用はデフォルト設定です。注記同じサブネット上の 1 つのネットワークカード (NIC) のみが、ゲートウェイ経由でトラフィックをルーティングできます。デフォルトでは、アドレス解決プロトコル (ARP) は番号が最も小さい NIC を使用します。ネットワーク負荷分散が期待どおりに機能するようにするには、同じサブネット内の各ノードに 1 つの NIC を使用します。同じサブネット内のノードに複数の NIC を使用する場合は、単一のボンディングまたはチームインターフェイスを使用します。次に、エイリアス IP アドレスの形式で他の IP アドレスをそのインターフェイスに追加します。ネットワークインターフェイスレベルでフォールトトレランスまたは負荷分散が必要な場合は、ボンディングまたはチームインターフェイスでエイリアス IP アドレスを使用します。または、同じサブネットでセカンダリー NIC を無効にするか、IP アドレスがないことを確認できます。
Unified Extensible Firmware Interface (UEFI): installer-provisioned installation では、
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 は、セキュアブートの自己生成キーまたは他のキーの管理をサポートしていません。
3.2.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | CPU [1] | RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
---|---|---|---|---|---|
ブートストラップ | RHEL | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
Compute | RHCOS | 2 | 8 GB | 100 GB | 300 |
- 1 つの CPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、(コアごとのスレッド x コア数) x ソケット数 = CPU という数式を使用して対応する比率を計算します。
- OpenShift Container Platform と Kubernetes は、ディスクのパフォーマンスの影響を受けるため、特にコントロールプレーンノードの etcd には、より高速なストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
OpenShift Container Platform バージョン 4.19 の場合、RHCOS は RHEL バージョン 9.6 に基づいています。これは、マイクロアーキテクチャー要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、アーキテクチャー (RHEL ドキュメント) を参照してください。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
3.2.3. 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 でサポートされていることを確認してください。
3.2.4. 仮想メディアを使用したインストールのファームウェア要件 リンクのコピーリンクがクリップボードにコピーされました!
installer-provisioned OpenShift Container Platform クラスターのインストールプログラムは、Redfish 仮想メディアとのハードウェアおよびファームウェアの互換性を検証します。ノードファームウェアに互換性がない場合、インストールプログラムはノードへのインストールを開始しません。以下の表は、Redfish 仮想メディアを使用してデプロイされる installer-provisioned OpenShift Container Platform クラスターで機能するようにテストおよび検証された最小ファームウェアバージョンの一覧です。
Red Hat は、ファームウェア、ハードウェア、またはその他のサードパーティーコンポーネントの組み合わせをすべてテストしません。サードパーティーサポートの詳細は、Red Hat サードパーティーサポートポリシー を参照してください。ファームウェアの更新は、ノードのハードウェアドキュメントを参照するか、ハードウェアベンダーにお問い合わせください。
モデル | 管理 | ファームウェアのバージョン |
---|---|---|
第 11 世代 | iLO6 | 1.57 以降 |
第 10 世代 | iLO5 | 2.63 以降 |
モデル | 管理 | ファームウェアのバージョン |
---|---|---|
第 16 世代 | iDRAC 9 | v7.10.70.00 |
第 15 世代 | iDRAC 9 | v6.10.30.00、v7.10.50.00、v7.10.70.00 |
第 14 世代 | iDRAC 9 | v6.10.30.00 |
モデル | 管理 | ファームウェアのバージョン |
---|---|---|
UCS X シリーズサーバー | Intersight Managed Mode | 5.2(2) 以降 |
FI 接続 UCS C シリーズサーバー | Intersight Managed Mode | 4.3 以降 |
スタンドアロン UCS C シリーズサーバー | スタンドアロン/Intersight | 4.3 以降 |
UCSHCL で、サーバーが Red Hat Enterprise Linux CoreOS (RHCOS) をサポートしていることを必ず確認してください。
3.2.5. ベアメタル向け NC-SI ハードウェア要件 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタル上に Network Controller Sideband Interface (NC-SI) を備えた OpenShift Container Platform 4.19 以降をデプロイするには、NC-SI をサポートするベースボード管理コントローラー (BMC) とネットワークインターフェイスカード (NIC) を備えたハードウェアを使用する必要があります。NC-SI により、BMC はシステム NIC をホストと共有できるようになり、電源オフ時に BMC 接続が失われないように DisablePowerOff
機能が必要になります。
ベンター | モデル | 生成 | 管理 |
---|---|---|---|
Dell | PowerEdge | 第 14 世代以降 | iDRAC 9 以降 (Redfish、IPMI、racadm、WS-MAN) |
HPE | ProLiant | 第 10 世代以降 | iLO 5 以降 (Redfish、IPMI、iLO RESTful API) |
Lenovo | ThinkSystem SR | 第 1 世代以降 | XClarity Controller (Redfish、IPMI、プロプライエタリー API) |
Supermicro | SuperServer | X11 シリーズ以降 | Supermicro BMC (Redfish、IPMI、プロプライエタリー Web/CLI) |
Intel | Server Systems | S2600BP 以降 | Intel BMC (Redfish、IPMI、プロプライエタリー API) |
Fujitsu | PRIMERGY | M4 シリーズ以降 | iRMC S5 以降 (Redfish、IPMI、プロプライエタリー Web/CLI) |
Cisco | UCS C シリーズ | M5 シリーズ以降 | Cisco IMC (Redfish、IPMI、プロプライエタリー XML API) |
ベンター | モデル | Specifications |
---|---|---|
Broadcom | NetXtreme BCM5720、BCM57416、BCM57504 | ギガビットおよび 10/25/100GbE、RMII サイドバンド、Redfish、IPMI、ベンダープロトコルをサポートします。 |
Intel | I210、X710、XXV710、E810 | ギガビットから 100GbE、RMII および SMBus サイドバンド、Redfish、IPMI、ベンダープロトコルをサポートします。 |
NVIDIA | ConnectX-5、ConnectX-6、ConnectX-7 | 25/50/100/200/400GbE、RMII サイドバンド、Redfish、IPMI、NVIDIA BMC API をサポートします。 |
NVIDIA | BlueField-2 以降 | 200/400GbE、Redfish、IPMI、NVIDIA BMC API をサポートします。 |
Marvell/Cavium | ThunderX CN88xx、FastLinQ QL41000 | 10/25/50GbE、RMII サイドバンド、Redfish、IPMI、ベンダープロトコルをサポートします。 |
Mellanox (NVIDIA) | MCX4121A-ACAT、MCX512A-ACAT | 10/25/50GbE、RMII サイドバンド、Redfish、IPMI、Mellanox API をサポートします。 |
互換性は BMC、NIC、およびファームウェアの設定に依存するため、ベンダーのドキュメントで NC-SI のサポートを確認してください。NC-SI NIC では、共有 NIC 機能を有効にするために互換性のある BMC が必要です。
3.2.6. ネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の installer-provisioned installation には、複数のネットワーク要件があります。まず、installer-provisioned installation では、各ベアメタルノードにオペレーティングシステムをプロビジョニングするためのルーティング不可能な provisioning
ネットワークをオプションで使用します。次に、installer-provisioned installation では、ルーティング可能な baremetal
ネットワークを使用します。
3.2.6.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) は、ポート |
3.2.6.2. ネットワーク MTU の増加 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をデプロイする前に、ネットワークの最大伝送単位 (MTU) を 1500 以上に増やします。MTU が 1500 未満の場合、ノードの起動に使用される Ironic イメージが Ironic インスペクター Pod との通信に失敗し、検査が失敗する可能性があります。これが発生すると、インストールにノードを使用できないため、インストールが停止します。
3.2.6.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 上にある必要があります。
3.2.6.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 解決を確認できます。
3.2.6.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 アドレスを予約する必要があります。
3.2.6.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 解決が必要になります。
3.2.6.7. プロビジョナーノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
インストール設定でプロビジョナーノードの MAC アドレスを指定する必要があります。通常、bootMacAddress
仕様は PXE ネットワークブートに関連付けられています。ただし、Ironic プロビジョニングサービスでは、クラスターの検査中またはクラスター内のノードの再デプロイ中にノードを識別するために、bootMacAddress
仕様も必要です。
プロビジョナーノードには、ネットワークの起動、DHCP と DNS の解決、およびローカルネットワーク通信のためのレイヤー 2 接続が必要です。プロビジョナーノードには、仮想メディアの起動にレイヤー 3 接続が必要です。
3.2.6.8. ネットワークタイムプロトコル (NTP) リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の各 OpenShift Container Platform ノードは NTP サーバーにアクセスできる必要があります。OpenShift Container Platform ノードは NTP を使用してクロックを同期します。たとえば、クラスターノードは検証を必要とする SSL/TLS 証明書を使用しますが、ノード間の日付と時刻が同期していないと、検証が失敗する可能性があります。
各クラスターノードの BIOS 設定で一貫性のあるクロックの日付と時刻の形式を定義してください。そうしないと、インストールが失敗する可能性があります。
切断されたクラスター上で NTP サーバーとして機能するようにコントロールプレーンノードを再設定し、コントロールプレーンノードから時間を取得するようにワーカーノードを再設定することができます。
3.2.6.9. 帯域外管理 IP アドレスのポートアクセス リンクのコピーリンクがクリップボードにコピーされました!
帯域外管理 IP アドレスは、ノードとは別のネットワーク上にあります。インストール中に帯域外管理がプロビジョナーノードと確実に通信できるようにするには、帯域外管理 IP アドレスに、プロビジョナーノードおよび OpenShift Container Platform コントロールプレーンノード上のポート 6180
へのアクセスを許可する必要があります。TLS ポート 6183
は、たとえば Redfish などを使用する仮想メディアのインストールに必要です。
3.2.7. ノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
3.2.7.1. provisioning ネットワークを使用する場合のノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の各ノードには、適切なインストールを行うために以下の設定が必要です。
ノード間で一致していないと、インストールに失敗します。
クラスターノードには 3 つ以上の NIC を追加できますが、インストールプロセスでは最初の 2 つの NIC のみに焦点が当てられます。以下の表では、NIC1 は OpenShift Container Platform クラスターのインストールにのみ使用されるルーティング不可能なネットワーク (provisioning
) です。
NIC | ネットワーク | VLAN |
---|---|---|
NIC1 |
|
|
NIC2 |
|
|
プロビジョナーノードでの Red Hat Enterprise Linux (RHEL) 9.x インストールプロセスは異なる可能性があります。ローカルの Satellite サーバー、PXE サーバー、PXE 対応の NIC2 を使用して Red Hat Enterprise Linux (RHEL) 9.x をインストールする場合は、以下のようになります。
PXE | ブート順序 |
---|---|
NIC1 PXE 対応の | 1 |
NIC2 | 2 |
他のすべての NIC で PXE が無効になっていることを確認します。
コントロールプレーンおよびワーカーノードを以下のように設定します。
PXE | ブート順序 |
---|---|
NIC1 PXE 対応 (プロビジョニングネットワーク) | 1 |
3.2.7.2. provisioning ネットワークを使用しないノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
インストールプロセスには、1 つの NIC が必要です。
NIC | ネットワーク | VLAN |
---|---|---|
NICx |
|
|
NICx は、OpenShift Container Platform クラスターのインストールに使用されるルーティング可能なネットワーク (baremetal
) であり、インターネットにルーティング可能です。
provisioning
ネットワークは任意ですが、PXE ブートには必要です。provisioning
ネットワークなしでデプロイする場合、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。
3.2.7.3. 手動での Secure Boot のノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
Secure Boot は、ノードが UEFI ファームウェアドライバー、EFI アプリケーション、オペレーティングシステムなどの信頼できるソフトウェアのみを使用していることを確認できない場合は、ノードの起動を阻止します。
Red Hat は、Redfish 仮想メディアを使用してデプロイする場合にのみ、手動で設定された Secure Boot をサポートします。
Secure Boot を手動で有効にするには、ノードのハードウェアガイドを参照し、以下を実行してください。
手順
- ノードを起動し、BIOS メニューを入力します。
-
ノードのブートモードを
UEFI Enabled
に設定します。 - Secure Boot を有効にします。
Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。
3.2.8. アウトオブバンド管理 リンクのコピーリンクがクリップボードにコピーされました!
ノードには通常、ベースボード管理コントローラー (BMC) が使用する追加の NIC があります。この BMC はプロビジョナーノードからアクセスできる必要があります。
各ノードは、アウトオブバンド管理を介してアクセスできる必要があります。アウトオブバンド管理ネットワークを使用する場合、OpenShift Container Platform のインストールを正常に行うには、プロビジョナーノードがアウトオブバンド管理ネットワークにアクセスできる必要があります。
アウトオブバンド管理の設定は、このドキュメントの範囲外です。アウトオブバンド管理用に別の管理ネットワークを使用すると、パフォーマンスが向上し、セキュリティーが強化されます。ただし、provisioning ネットワークまたはベアメタルネットワークの使用は有効なオプションになります。
ブートストラップ仮想マシンには、最大 2 つのネットワークインターフェイスがあります。帯域外管理用に別の管理ネットワークを設定し、プロビジョニングネットワークを使用している場合、ブートストラップ仮想マシンでは、いずれかのネットワークインターフェイスを介して管理ネットワークへのルーティングアクセスが必要になります。このシナリオでは、ブートストラップ仮想マシンは 3 つのネットワークにアクセスできます。
- ベアメタルネットワーク
- プロビジョニングネットワーク
- 管理インターフェイスの 1 つを介してルーティングされる管理ネットワーク
3.2.9. インストールに必要なデータ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのインストール前に、すべてのクラスターノードから以下の情報を収集します。
アウトオブバンド管理 IP
例
- Dell (iDRAC) IP
- HP (iLO) IP
- Fujitsu (iRMC) IP
provisioning
ネットワークを使用する場合
-
NIC (
provisioning
) MAC アドレス -
NIC (
baremetal
) MAC アドレス
provisioning
ネットワークを省略する場合
-
NIC (
baremetal
) MAC アドレス
3.2.10. ノードの検証チェックリスト リンクのコピーリンクがクリップボードにコピーされました!
provisioning
ネットワークを使用する場合
-
❏ NIC1 VLAN が
provisioning
ネットワーに設定されている。 -
❏
provisioning
ネットワークの NIC1 は、プロビジョナー、コントロールプレーン、およびワーカーノードで PXE 対応として使用できる。 -
❏ NIC2 VLAN が
baremetal
ネットワークに設定されている。 - ❏ PXE が他のすべての NIC で無効にされている。
- ❏ DNS は API および Ingress エンドポイントで設定されている。
- ❏ コントロールプレーンおよびワーカーノードが設定されている。
- ❏ すべてのノードがアウトオブバンド管理でアクセス可能である。
- ❏ (オプション) 別個の管理ネットワークが作成されている。
- ❏ インストールに必要なデータ。
provisioning
ネットワークを省略する場合
-
❏ NIC1 VLAN が
baremetal
ネットワークに設定されている。 - ❏ DNS は API および Ingress エンドポイントで設定されている。
- ❏ コントロールプレーンおよびワーカーノードが設定されている。
- ❏ すべてのノードがアウトオブバンド管理でアクセス可能である。
- ❏ (オプション) 別個の管理ネットワークが作成されている。
- ❏ インストールに必要なデータ。
3.2.11. インストールの概要 リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムは対話型モードをサポートしています。ただし、すべてのベアメタルホストのプロビジョニングの詳細と関連するクラスターの詳細を含む install-config.yaml
ファイルを事前に準備することができます。
インストールプログラムは install-config.yaml
ファイルを読み込み、管理者はマニフェストを生成し、すべての前提条件を確認します。
インストールプログラムは次のタスクを実行します。
- クラスター内のすべてのノードを登録する
- ブートストラップ仮想マシン (VM) を起動する
次のコンテナーを持つ、metal プラットフォームコンポーネントを
systemd
サービスとして起動する- Ironic-dnsmasq: プロビジョニングネットワーク上のさまざまなノードのプロビジョニングインターフェイスに IP アドレスを引き渡す役割を担う DHCP サーバー。Ironic-dnsmasq は、プロビジョニングネットワークを使用して OpenShift Container Platform クラスターをデプロイする場合にのみ有効になります。
- Ironic-httpd: イメージをノードに送信するために使用される HTTP サーバー。
- Image-customization
- Ironic
- Ironic-inspector (OpenShift Container Platform 4.16 以前で利用可能)
- Ironic-ramdisk-logs
- Extract-machine-os
- Provisioning-interface
- Metal3-baremetal-operator
ノードは検証フェーズに入り、Ironic がベースボード管理コントローラー (BMC) にアクセスするための認証情報を検証した後、各ノードは 管理可能 な状態に移行します。
ノードが管理可能な状態になると、検査 フェーズが開始されます。検査フェーズでは、ハードウェアが OpenShift Container Platform の正常なデプロイメントに必要な最小要件を満たしていることを確認します。
install-config.yaml
ファイルには、プロビジョニングネットワークの詳細が記述されています。ブートストラップ仮想マシンでは、インストールプログラムは Pre-Boot Execution Environment (PXE) を使用して、Ironic Python Agent (IPA) がロードされているすべてのノードにライブイメージをプッシュします。仮想メディアを使用する場合、各ノードの BMC に直接接続してイメージを仮想的にアタッチします。
PXE ブートを使用する場合、プロセスを開始するためにすべてのノードが再起動します。
-
ブートストラップ仮想マシン上で実行されている
ironic-dnsmasq
サービスは、ノードと TFTP ブートサーバーの IP アドレスを提供します。 - 最初のブートソフトウェアは、HTTP 経由でルートファイルシステムをロードします。
-
ブートストラップ仮想マシン上の
ironic
サービスは、各ノードからハードウェア情報を受信します。
ノードはクリーニング状態になり、各ノードは設定を続行する前にすべてのディスクをクリーニングする必要があります。
クリーニング状態が終了すると、ノードは使用可能な状態になり、インストールプログラムはノードをデプロイ状態に移動します。
IPA は coreos-installer
コマンドを実行して、install-config.yaml
ファイルの rootDeviceHints
パラメーターで定義されたディスクに Red Hat Enterprise Linux CoreOS (RHCOS) イメージをインストールします。ノードは RHCOS を使用して起動します。
インストールプログラムは、コントロールプレーンノードを設定した後、ブートストラップ仮想マシンからコントロールプレーンノードに制御を移動し、ブートストラップ仮想マシンを削除します。
ベアメタル Operator は、ワーカー、ストレージ、およびインフラノードのデプロイメントを継続します。
インストールが完了すると、ノードはアクティブ状態に移行します。その後、インストール後の設定やその他の Day 2 タスクに進むことができます。
3.3. OpenShift インストールの環境のセットアップ リンクのコピーリンクがクリップボードにコピーされました!
3.3.1. RHEL のプロビジョナーノードへのインストール リンクのコピーリンクがクリップボードにコピーされました!
前提条件の設定が完了したら、次のステップとして RHEL 9.x をプロビジョナーノードにインストールします。インストーラーは、OpenShift Container Platform クラスターをインストールする間にプロビジョナーノードをオーケレーターとして使用します。このドキュメントの目的上、RHEL のプロビジョナーノードへのインストールは対象外です。ただし、オプションには、RHEL Satellite サーバー、PXE、またはインストールメディアの使用も含まれますが、これらに限定されません。
3.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 register --username=<user> --password=<pass> --auto-attach
Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo subscription-manager repos --enable=rhel-9-for-<architecture>-appstream-rpms --enable=rhel-9-for-<architecture>-baseos-rpms
$ sudo subscription-manager repos --enable=rhel-9-for-<architecture>-appstream-rpms --enable=rhel-9-for-<architecture>-baseos-rpms
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Red Hat Subscription Manager の詳細は、コマンドラインツールを使用した RHEL システムの登録 を参照してください。
以下のパッケージをインストールします。
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 モジュラー
libvirt
デーモンのソケットを起動します。for drv in qemu interface network nodedev nwfilter secret storage; do sudo systemctl start virt${drv}d{,-ro,-admin}.socket; done
$ for drv in qemu interface network nodedev nwfilter secret storage; do sudo systemctl start virt${drv}d{,-ro,-admin}.socket; done
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.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.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.3.5. カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
configure-ovs.sh
シェルスクリプトを使用してベアメタルプラットフォームで br-ex
ブリッジを設定する代わりに、NMState 設定ファイルを含む MachineConfig
オブジェクトを作成できます。ホスト nmstate-configuration.service
および nmstate.service
により、クラスター内で実行される各ノードに NMState 設定ファイルが適用されます。
カスタマイズされた br-ex
ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。
-
Open vSwitch (OVS) または OVN-Kubernetes
br-ex
ブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.sh
シェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。 - ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
-
configure-ovs.sh
シェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。
単一のネットワークインターフェイスコントローラー (NIC) とデフォルトのネットワーク設定を備えた環境が必要な場合は、configure-ovs.sh
シェルスクリプトを使用します。
Red Hat Enterprise Linux CoreOS (RHCOS) をインストールしてシステムを再起動すると、Machine Config Operator がクラスター内の各ノードに Ignition 設定ファイルを注入し、各ノードが br-ex
ブリッジネットワーク設定を受け取るようになります。設定の競合を防ぐために、configure-ovs.sh
シェルスクリプトは、br-ex
ブリッジを設定しない信号を受け取ります。
次のインターフェイス名は予約されており、NMstate 設定では使用できません。
-
br-ext
-
br-int
-
br-local
-
br-nexthop
-
br0
-
ext-vxlan
-
ext
-
genev_sys_*
-
int
-
k8s-*
-
ovn-k8s-*
-
patch-br-*
-
tun0
-
vxlan_sys_*
前提条件
-
オプション: NMState 設定を検証できるように、
nmstate
API をインストールしました。
手順
カスタマイズされた
br-ex
ブリッジネットワークの base64 情報をデコードした NMState 設定ファイルを作成します。カスタマイズされた
br-ex
ブリッジネットワークの NMState 設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat
コマンドを使用して、NMState 設定の内容を base64 でエンコードします。cat <nmstate_configuration>.yaml | base64
$ cat <nmstate_configuration>.yaml | base64
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nmstate_configuration>
を NMState リソース YAML ファイルの名前に置き換えます。
MachineConfig
マニフェストファイルを作成し、次の例に類似したカスタマイズされたbr-ex
ブリッジネットワーク設定を定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のすべてのノードに適用する単一のグローバル設定が
/etc/nmstate/openshift/cluster.yml
設定ファイルで指定されている場合は、各ノードの短いホスト名パス (例:/etc/nmstate/openshift/<node_hostname>.yml
) を指定する必要はありません。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
-
コンピュートノードをスケーリングして、クラスター内に存在する各コンピュートノードに、カスタマイズされた
br-ex
ブリッジを含むマニフェストオブジェクトを適用します。詳細は、関連情報 セクションの「クラスターの拡張」を参照してください。
3.3.5.1. 各マシンセットをコンピュートノードにスケーリング リンクのコピーリンクがクリップボードにコピーされました!
カスタマイズされた br-ex
ブリッジ設定を OpenShift Container Platform クラスター内のすべてのコンピュートノードに適用するには、MachineConfig
カスタムリソース (CR) を編集し、そのロールを変更する必要があります。さらに、ホスト名、認証情報など、ベアメタルマシンの情報を定義する BareMetalHost
CR を作成する必要があります。
これらのリソースを設定した後、マシンセットをスケーリングして、マシンセットが各コンピュートノードにリソース設定を適用し、ノードを再起動できるようにする必要があります。
前提条件
-
カスタマイズされた
br-ex
ブリッジ設定を含むMachineConfig
マニフェストオブジェクトを作成しました。
手順
次のコマンドを入力して
MachineConfig
CR を編集します。oc edit mc <machineconfig_custom_resource_name>
$ oc edit mc <machineconfig_custom_resource_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 各コンピュートノード設定を CR に追加して、CR がクラスター内の定義済みコンピュートノードごとにロールを管理できるようにします。
-
最小限の静的 IP 設定を持つ
extraworker-secret
という名前のSecret
オブジェクトを作成します。 次のコマンドを入力して、クラスター内の各ノードに
extraworker-secret
シークレットを適用します。このステップでは、各コンピュートノードに Ignition 設定ファイルへのアクセスを提供します。oc apply -f ./extraworker-secret.yaml
$ oc apply -f ./extraworker-secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BareMetalHost
リソースを作成し、preprovisioningNetworkDataName
パラメーターでネットワークシークレットを指定します。ネットワークシークレットが添付された
BareMetalHost
リソースの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの
openshift-machine-api
namespace 内でBareMetalHost
オブジェクトを管理するために、次のコマンドを入力して namespace に変更します。oc project openshift-machine-api
$ oc project openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシンセットを取得します。
oc get machinesets
$ oc get machinesets
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各マシンセットをスケールします。このコマンドはマシンセットごとに実行する必要があります。
oc scale machineset <machineset_name> --replicas=<n>
$ oc scale machineset <machineset_name> --replicas=<n>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<machineset_name>
はマシンセットの名前です。<n>
はコンピュートノードの数です。
3.3.6. クラスターで OVS balance-slb モードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上の物理インターフェイスがネットワークトラフィックを共有できるように、Open vSwitch (OVS) の balance-slb
モードを有効にできます。balance-slb
モードのインターフェイスは、ネットワークスイッチとのソースロードバランシングを必要とせずに、仮想化ワークロードを実行するクラスターにソース負荷分散 (SLB) 機能を提供できます。
現在、ソースロードバランシングはボンディングインターフェイスで実行されます。このインターフェイスは br-phy
などの補助ブリッジに接続します。ソースロードバランシングは、Media Access Control (MAC) アドレスと仮想ローカルエリアネットワーク (VLAN) の組み合わせが複数存在する場合にのみ、負荷分散を行います。OVN-Kubernetes Pod のトラフィックはすべて同じ MAC アドレスと VLAN を使用するため、このトラフィックを多数の物理インターフェイス間で負荷分散することはできないことに注意してください。
次の図は、単純なクラスターインフラストラクチャーレイアウトでの balance-slb
モードを示しています。仮想マシン (VM) は、特定の localnet NetworkAttachmentDefinition
(NAD) カスタムリソース定義 (CRD)、NAD 0
または NAD 1
に接続します。各 NAD は、仮想マシンに基盤となる物理ネットワークへのアクセスを提供し、タグ付きまたはタグなしの VLAN トラフィックをサポートしています。br-ex
OVS ブリッジは仮想マシンからのトラフィックを受信し、そのトラフィックを次の OVS ブリッジである br-phy
に渡します。br-phy
ブリッジは SLB ボンディングのコントローラーとして機能します。SLB ボンディングは、eno0
や eno1
などの物理インターフェイスリンクを介して、異なる仮想マシンポートからのトラフィックを分散します。さらに、どちらの物理インターフェイスからの Ingress トラフィックも、OVS ブリッジのセットを通過して仮想マシンに到達できます。
図3.1 2 つの NAD を持つローカルネット上で動作する OVS balance-slb
モード
OVS ボンディングを使用して、balance-slb
モードインターフェイスをプライマリーまたはセカンダリーネットワークタイプに統合できます。OVS ボンディングでは、次の点に注意してください。
- OVN-Kubernetes CNI プラグインをサポートし、プラグインと簡単に統合できます。
-
ネイティブで
balance-slb
モードをサポートします。
前提条件
-
プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを
MachineConfig
ファイルで定義した。 -
マニフェストオブジェクトを作成し、カスタマイズした
br-ex
ブリッジをオブジェクト設定ファイルで定義した。 - プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを NAD CRD ファイルで定義した。
手順
クラスター内に存在するベアメタルホストごとに、クラスターの
install-config.yaml
ファイルで、次の例のようにnetworkConfig
セクションを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow NMState 設定ファイルで各ネットワークインターフェイスを定義します。
多数のネットワークインターフェイスを定義する NMState 設定ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ボンディングポートの
br-ex
MTU を手動で設定します。
base64
コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。base64 -w0 <nmstate_configuration>.yml
$ base64 -w0 <nmstate_configuration>.yml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
-w0
オプションは、base64 エンコード操作中に行の折り返しを防止します。
master
ロールとworker
ロールのMachineConfig
マニフェストファイルを作成します。前のコマンドからの base64 エンコード文字列を各MachineConfig
マニフェストファイルに必ず埋め込んでください。次のマニフェストファイルの例では、クラスター内に存在するすべてのノードに対してmaster
ロールを設定します。ノード固有のmaster
ロールとworker
ロールのマニフェストファイルを作成することもできます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各
MachineConfig
マニフェストファイルを./<installation_directory>/manifests
ディレクトリーに保存します。<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーです。Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。
3.3.7. サブネット間の通信を確立する リンクのコピーリンクがクリップボードにコピーされました!
一般的な OpenShift Container Platform クラスターのセットアップでは、コントロールプレーンとコンピュートノードを含むすべてのノードが同じネットワーク内に存在します。ただし、エッジコンピューティングのシナリオでは、コンピュートノードをエッジの近くに配置することが有益な場合があります。その場合、コントロールプレーンやローカルコンピュートノードが使用するサブネットとは異なるネットワークセグメントまたはサブネットをリモートノードに使用することもよくあります。このようなセットアップにより、エッジのレイテンシーが減少し、拡張性が向上します。
OpenShift Container Platform をインストールする前に、リモートノードを含むエッジサブネットがコントロールプレーンノードを含むサブネットに到達し、コントロールプレーンからのトラフィックも受信できるように、ネットワークを適切に設定する必要があります。
クラスターのインストール中に、install-config.yaml
設定ファイルのネットワーク設定でノードに永続的な IP アドレスを割り当てます。これを行わないと、ノードに一時的な IP アドレスが割り当てられ、トラフィックがノードに到達する方法に影響する可能性があります。たとえば、ノードに一時的な IP アドレスが割り当てられていて、ノードに対して結合されたインターフェイスを設定した場合、結合されたインターフェイスは別の IP アドレスを受け取る可能性があります。
デフォルトのロードバランサーの代わりにユーザー管理のロードバランサーを設定することで、同じサブネットまたは複数のサブネットでコントロールプレーンノードを実行できます。複数のサブネット環境を使用すると、ハードウェア障害やネットワーク停止によって OpenShift Container Platform クラスターが失敗するリスクを軽減できます。詳細は、「ユーザー管理ロードバランサーのサービス」および「ユーザー管理ロードバランサーの設定」を参照してください。
複数のサブネット環境でコントロールプレーンノードを実行するには、次の主要なタスクを完了する必要があります。
-
install-config.yaml
ファイルのloadBalancer.type
パラメーターでUserManaged
を指定して、デフォルトのロードバランサーの代わりにユーザー管理のロードバランサーを設定します。 -
install-config.yaml
ファイルのingressVIPs
およびapiVIPs
パラメーターでユーザー管理のロードバランサーのアドレスを設定します。 -
複数のサブネットの Classless Inter-Domain Routing (CIDR) とユーザー管理のロードバランサーの IP アドレスを、
install-config.yaml
ファイルのnetworking.machineNetworks
パラメーターに追加します。
複数のサブネットを持つクラスターをデプロイするには、redfish-virtualmedia
や idrac-virtualmedia
などの仮想メディアを使用する必要があります。
この手順では、2 番目のサブネットにあるリモートコンピュートノードが 1 番目のサブネットにあるコントロールプレーンノードと効果的に通信できるようにするために必要なネットワーク設定と、1 番目のサブネットにあるコントロールプレーンノードが 2 番目のサブネットにあるリモートコンピュートノードと効果的に通信できるようにするために必要なネットワーク設定を詳しく説明します。
この手順では、クラスターは 2 つのサブネットにまたがります。
-
1 番目のサブネット (
10.0.0.0
) には、コントロールプレーンとローカルコンピュートノードが含まれています。 -
2 番目のサブネット (
192.168.0.0
) には、エッジコンピュートノードが含まれています。
手順
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
) へのルートを追加します。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>"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <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"
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 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 次のコマンドを実行して、ゲートウェイを経由する最初のサブネット (
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_node_ip_address>
$ ping <remote_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.3.8. OpenShift Container Platform インストーラーの取得 リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムの stable-4.x
バージョンと選択したアーキテクチャーを使用して、OpenShift Container Platform の一般公開の安定バージョンをデプロイします。
export VERSION=stable-4.19
$ export VERSION=stable-4.19
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.3.9. 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.3.10. 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
の値に置き換えます。
詳細は、「install-config.yaml ファイルの設定」セクションを参照してください。
3.3.11. ユーザー管理ロードバランサーのサービス リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。
ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図3.2 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図3.3 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図3.4 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 が未定義のノードに移動すると、接続が停止する可能性があります。
3.3.11.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、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。
1 つのサブネットをリストした HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 複数のサブネットをリストした 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 レコードが伝播されることを確認してください。
OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの
install-config.yaml
ファイルで次の設定を指定する必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスターのユーザー管理ロードバランサーを指定するには、
type
パラメーターにUserManaged
を設定します。パラメーターのデフォルトはOpenShiftManagedDefault
で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra
namespace で定義されたサービスの場合、ユーザー管理ロードバランサーはcoredns
サービスをクラスター内の Pod にデプロイできますが、keepalived
およびhaproxy
サービスは無視します。 - 2
- ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
- 3
- ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。
検証
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
3.3.12. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、NetworkManager
がホスト名を設定します。デフォルトでは、DHCP が NetworkManager
にホスト名を提供します。これが推奨される方法です。NetworkManager
は、次の場合に逆 DNS ルックアップを通じてホスト名を取得します。
- DHCP がホスト名を提供しない場合
- カーネル引数を使用してホスト名を設定する場合
- 別の方法でホスト名を設定する場合
逆 DNS ルックアップは、ノード上でネットワークが初期化された後に実行し、NetworkManager
がホスト名を設定するのにかかる時間が長くなる可能性があります。NetworkManager
がホスト名を設定する前に他のシステムサービスが起動することがあり、その場合は、それらのサービスが localhost
などのデフォルトのホスト名を使用する可能性があります。
DHCP を使用して各クラスターノードにホスト名を提供することで、ホスト名の設定の遅延を回避できます。また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
3.3.13. ローカルアービターノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインフラストラクチャーコストを削減しながら高可用性 (HA) を維持するために、2 つのコントロールプレーンノードと 1 つのローカルアービターノードを使用して、OpenShift Container Platform クラスターを設定できます。この設定はベアメタルインストールでのみサポートされます。
ローカルアービターノードの設定は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ローカルアービターノードは、コントロールプレーンのクォーラム決定に参加する低コストの共存マシンです。標準のコントロールプレーンノードとは異なり、アービターノードはコントロールプレーンサービスの完全なセットを実行しません。この設定を使用すると、3 つのコントロールプレーンノードではなく 2 つの完全にプロビジョニングされたコントロールプレーンノードのみを使用して、クラスター内の HA を維持できます。
ローカルアービタノードのみを設定できます。リモートアービタノードはサポートされていません。
2 つのコントロールプレーンノードと 1 つのローカルアービターノードを含むクラスターをデプロイするには、install-config.yaml
ファイルで次のノードを定義する必要があります。
- 2 つのコントロールプレーンノード
- 1 つのアービターノード
アービターノード機能を有効にするには、FeatureGate
カスタムリソース (CR) で TechPreviewNoUpgrade
機能セットを有効にする必要があります。フィーチャーゲートの詳細は、「フィーチャーゲートについて」を参照してください。
アービタノードは、次の最小システム要件を満たしている必要があります。
- 2 つのスレッド
- 8 GB の RAM
- 120 GB の SSD または同等のストレージ
アービタノードは、ディスク I/O を含むエンドツーエンドのレイテンシーが 500 ミリ秒未満のネットワーク環境に配置する必要があります。レイテンシーの高い環境では、etcd
のスロープロファイルを適用する必要がある場合があります。
コントロールプレーンノードは、次の最小システム要件を満たしている必要があります。
- 4 つのスレッド
- 16 GB のメモリー
- 120 GB の SSD または同等のストレージ
さらに、コントロールプレーンノードにもワークロードに対応できる十分なストレージが必要です。
前提条件
-
OpenShift CLI (
oc
) とインストールプログラムをダウンロードしている。 -
OpenShift CLI (
oc
) にログインしている。
手順
install-config.yaml
ファイルを編集して、コントロールプレーンノードとともにアービターノードを定義します。アービターノードをデプロイするための
install-config.yaml
設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
変更した
install-config.yaml
ファイルを保存します。
次のステップ
3.3.14. install-config.yaml ファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
3.3.14.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
- クラスターホストのクロックが同期していない場合に各ホスト設定に追加する追加 NTP サーバーのドメイン名または IP アドレスのリスト (任意)。
- 3
- 静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、
bootstrapExternalStaticIP
設定を設定して、ブートストラップ仮想マシンの静的 IP アドレスを指定する必要があります。 - 4
- 静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、
bootstrapExternalStaticGateway
設定を設定して、ブートストラップ仮想マシンのゲートウェイ IP アドレスを指定する必要があります。 - 5
- 静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、
bootstrapExternalStaticDNS
設定を設定して、ブートストラップ仮想マシンの DNS アドレスを指定する必要があります。 - 6
- その他のオプションは、BMC アドレス指定のセクションを参照してください。
- 7
- インストールディスクドライブへのパスを設定するには、ディスクのカーネル名を入力します。たとえば、
/dev/sda
です。重要ディスクの検出順序は保証されていないため、複数のディスクを持つマシンでは、起動オプションによってディスクのカーネル名が変わる可能性があります。たとえば、
/dev/sda
は/dev/sdb
になり、その逆も同様です。この問題を回避するには、ディスクの World Wide Name (WWN) や/dev/disk/by-path/
などの永続的なディスク属性を使用する必要があります。ストレージの場所への/dev/disk/by-path/<device_path>
リンクを使用することを推奨します。ディスク WWN を使用するには、deviceName
パラメーターをwwnWithExtension
パラメーターに置き換えます。使用するパラメーターに応じて、次のいずれかの値を入力します。-
ディスク名。たとえば、
/dev/sda
、または/dev/disk/by-path/
です。 -
ディスクの WWN。たとえば、
"0x64cd98f04fde100024684cf3034da5c2"
です。ディスク 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.3.14.2. 追加の install-config パラメーター リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルに必要なパラメーター hosts
パラメーターおよび bmc
パラメーターは、以下の表を参照してください。
パラメーター | デフォルト | 説明 |
---|---|---|
|
クラスターのドメイン名。たとえば、 | |
|
|
ノードのブートモード。オプションは、 |
platform: baremetal: bootstrapExternalStaticDNS
|
ブートストラップノードの静的ネットワーク DNS。ベアメタルネットワークに Dynamic Host Configuration Protocol (DHCP) サーバーがない場合に、静的 IP アドレスを使用してクラスターをデプロイする場合は、この値を設定する必要があります。この値を設定しないと、インストールプログラムが | |
platform: baremetal: bootstrapExternalStaticIP
| ブートストラップ VM の静的 IP アドレス。ベアメタルネットワークに DHCP サーバーがない場合に、静的 IP アドレスを使用してクラスターをデプロイする場合は、この値を設定する必要があります。 | |
platform: baremetal: bootstrapExternalStaticGateway
| ブートストラップ 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
| replicas は、OpenShift Container Platform クラスターのコンピュートノードの数を設定します。 | |
controlPlane: name: master
| OpenShift Container Platform クラスターでは、コントロールプレーンノードに名前が必要です。 | |
controlPlane: replicas: 3
| replicas は、OpenShift Container Platform クラスターの一部として含まれるコントロールプレーンノードの数を設定します。 | |
arbiter: name: arbiter
| OpenShift Container Platform クラスターでは、アービターノードの名前が必要です。 | |
arbiter: replicas: 1
|
| |
|
ベアメタルネットワークに接続されたノード上のネットワークインターフェイス名。OpenShift Container Platform 4.9 以降のリリースのために、NIC の名前を識別するために | |
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
| (オプション) Kubernetes API 通信の仮想 IP アドレス。
この設定は、 注記
OpenShift Container Platform 4.12 より前では、クラスターのインストールプログラムは | |
|
|
|
| (オプション) Ingress トラフィックの仮想 IP アドレス。
この設定は、 注記
OpenShift Container Platform 4.12 より前では、クラスターのインストールプログラムは |
パラメーター | デフォルト | 説明 |
---|---|---|
platform: baremetal: additionalNTPServers: - <ip_address_or_domain_name>
| 各ホストに追加する追加 NTP サーバーのリスト (任意)。IP アドレスまたはドメイン名を使用して各 NTP サーバーを指定できます。追加 NTP サーバーは、クラスターホストのクロックが同期されていない場合にインストール前のクロック同期を有効にするユーザー定義の NTP サーバーです。 | |
|
| プロビジョニングネットワークでノードの IP 範囲を定義します。 |
|
| プロビジョニングに使用するネットワークの CIDR。このオプションは、プロビジョニングネットワークのデフォルトのアドレス範囲を使用しない場合に、インストールプログラムに必要です。 |
|
|
プロビジョニングサービスが実行されるクラスター内の IP アドレス。デフォルトは、プロビジョニングサブネットの 3 番目の IP アドレスに設定されます。たとえば、 |
|
|
インストールプログラムがコントロールプレーン (マスター) ノードをデプロイしている間にプロビジョニングサービスが実行されるブートストラップ仮想マシンの IP アドレス。デフォルトは、プロビジョニングサブネットの 2 番目の IP アドレスに設定されます。たとえば、 |
|
| ベアメタルネットワークに接続されたハイパーバイザーのベアメタルブリッジの名前。 |
|
|
プロビジョニングネットワークに接続されている |
|
クラスターのホストアーキテクチャーを定義します。有効な値は | |
| プラットフォーム設定なしでマシンプールに使用されるデフォルト設定。 | |
|
ブートストラップノードのデフォルトのオペレーティングシステムイメージを上書きするための URL。URL にはイメージの SHA-256 ハッシュが含まれている必要があります。たとえば、 | |
|
| |
| このパラメーターを、環境内で使用する適切な HTTP プロキシーに設定します。 | |
| このパラメーターを、環境内で使用する適切な HTTPS プロキシーに設定します。 | |
| このパラメーターを、環境内のプロキシーの使用に対する例外のリストに設定します。 |
3.3.14.2.1. ホスト リンクのコピーリンクがクリップボードにコピーされました!
hosts
パラメーターは、クラスターのビルドに使用される個別のベアメタルアセットのリストです。
名前 | デフォルト | 説明 |
---|---|---|
|
詳細情報に関連付ける | |
|
ベアメタルノードのロール。 | |
| ベースボード管理コントローラーの接続詳細。詳細は、BMC アドレス指定のセクションを参照してください。 | |
|
ホストがプロビジョニングネットワークに使用する NIC の MAC アドレス。Ironic は、 注記 プロビジョニングネットワークを無効にした場合は、ホストから有効な MAC アドレスを提供する必要があります。 | |
| このオプションのパラメーターを設定して、ホストのネットワークインターフェイスを設定します。詳細は、「(オプション) ホストネットワークインターフェイスの設定」を参照してください。 |
3.3.14.3. BMC アドレス指定 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどのベンダーは、Intelligent Platform Management Interface(IPMI) でベースボード管理コントローラー (BMC) アドレスに対応しています。IPMI は通信を暗号化しません。これは、セキュリティーが保護された管理ネットワークまたは専用の管理ネットワークを介したデータセンター内での使用に適しています。ベンダーを確認して、Redfish ネットワークブートをサポートしているかどうかを確認します。Redfish は、コンバージド、ハイブリッド IT および Software Defined Data Center (SDDC) 向けのシンプルでセキュアな管理を行います。Redfish は人による判読が可能、かつ機械対応が可能であり、インターネットや Web サービスの標準を活用して、最新のツールチェーンに情報を直接公開します。ハードウェアが Redfish ネットワークブートに対応していない場合には、IPMI を使用します。
ノードが Registering
状態にある間、インストール中に BMC アドレスを変更できます。ノードの Registering
状態が終了した後に BMC アドレスを変更する必要がある場合は、ノードを Ironic から切断し、BareMetalHost
リソースを編集して、ノードを Ironic に再接続する必要があります。詳細は、BareMetalHost リソースの編集 セクションを参照してください。
3.3.14.3.1. 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 仮想メディア」を参照してください。
3.3.14.3.2. Redfish ネットワークブート リンクのコピーリンクがクリップボードにコピーされました!
Redfish を有効にするには、redfish://
または redfish+http://
を使用して TLS を無効にします。インストーラーには、ホスト名または IP アドレスとシステム ID へのパスの両方が必要です。以下の例は、install-config.yaml
ファイル内の Redfish 設定を示しています。
アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、bmc
設定に disableCertificateVerification: True
を含める必要があります。以下の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用する Redfish 設定を示しています。
3.3.14.4. Redfish API のサポートの確認 リンクのコピーリンクがクリップボードにコピーされました!
Redfish API を使用してインストールする場合、ベアメタル上で installer-provisioned infrastructure を使用する際に、インストールプログラムはベースボード管理コントローラー (BMC) 上の複数の Redfish エンドポイントを呼び出します。Redfish を使用する場合は、インストール前に BMC がすべての Redfish API をサポートしていることを確認してください。
手順
次のコマンドを実行して、BMC の IP アドレスまたはホスト名を設定します。
export SERVER=<ip_address>
$ export SERVER=<ip_address>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<ip_address>
を、BMC の IP アドレスまたはホスト名に置き換えます。
次のコマンドを実行して、システムの ID を設定します。
export SystemID=<system_id>
$ export SystemID=<system_id>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<system_id>
をシステム ID に置き換えます。たとえば、System.Embedded.1
または1
です。詳細は、以下のベンダー固有 BMC セクションを参照してください。
Redfish API のリスト
次のコマンドを実行して、
power on
のサポートを確認します。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 次のコマンドを実行して、
power off
のサポートを確認します。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" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Legacy
またはUEFI
を使用するファームウェアブートモードの設定ステータスを確認します。curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Redfish 仮想メディア API のリスト
次のコマンドを実行して、
cd
またはdvd
を使用する一時ブートデバイスを設定できるか確認します。curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
$ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 仮想メディアは、ハードウェアに応じて
POST
またはPATCH
を使用する場合があります。次のいずれかのコマンドを実行して、仮想メディアをマウントできるかどうかを確認します。curl -u $USER:$PASS -X POST -H "Content-Type: application/json" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'
$ curl -u $USER:$PASS -X POST -H "Content-Type: application/json" 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 curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: <ETAG>" 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: <ETAG>" 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 仮想メディア API と同じです。一部のハードウェアでは、VirtualMedia
リソースが Managers/$ManagerID
ではなく Systems/$SystemID
にのみ存在する場合があります。VirtualMedia
リソースの場合、UserName
と Password
のフィールドはオプションです。
TransferProtocolTypes
でサポートされているパラメータータイプは、HTTPS
と HTTP
のみです。
3.3.14.5. Dell iDRAC の BMC アドレス指定 リンクのコピーリンクがクリップボードにコピーされました!
各 bmc
エントリーの address
設定は、URL スキーム内のコントローラーのタイプとネットワーク上の場所を含む、OpenShift Container Platform クラスターノードに接続するための URL です。各 bmc
エントリーの username
設定では、Administrator
権限を持つユーザーを指定する必要があります。
Dell ハードウェアの場合、Red Hat は統合 Dell Remote Access Controller (iDRAC) 仮想メディア、Redfish ネットワークブート、および IPMI をサポートします。
3.3.14.5.1. Dell iDRAC の BMC アドレス形式 リンクのコピーリンクがクリップボードにコピーされました!
プロトコル | アドレスのフォーマット |
---|---|
iDRAC 仮想メディア |
|
Redfish ネットワークブート |
|
IPMI |
|
idrac-virtualmedia
を Redfish 仮想メディアのプロトコルとして使用します。redfish-virtualmedia
は Dell ハードウェアでは機能しません。Dell の idrac-virtualmedia
は、Dell の OEM 拡張機能が含まれる Redfish 標準を使用します。
詳細は、以下のセクションを参照してください。
3.3.14.5.2. 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 設定を示しています。
3.3.14.5.3. 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.3.14.6. 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 |
|
詳細は、以下のセクションを参照してください。
3.3.14.6.1. 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 世代のシステムではサポートされません。
3.3.14.6.2. HPE iLO の Redfish ネットワークブート リンクのコピーリンクがクリップボードにコピーされました!
Redfish を有効にするには、redfish://
または redfish+http://
を使用して TLS を無効にします。インストーラーには、ホスト名または IP アドレスとシステム ID へのパスの両方が必要です。以下の例は、install-config.yaml
ファイル内の Redfish 設定を示しています。
アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、bmc
設定に disableCertificateVerification: True
を含める必要があります。以下の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用する Redfish 設定を示しています。
3.3.14.7. 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.3.14.8. Cisco CIMC の BMC アドレス指定 リンクのコピーリンクがクリップボードにコピーされました!
それぞれの bmc
エントリーの address
フィールドは、URL スキーム内のコントローラーのタイプやネットワーク上のその場所を含む、OpenShift Container Platform クラスターノードに接続する URL です。
- 1
address
設定ではプロトコルを指定します。
Cisco UCS C シリーズおよび X シリーズサーバーの場合、Red Hat は Cisco Integrated Management Controller (CIMC) をサポートしています。
プロトコル | アドレスのフォーマット |
---|---|
Redfish 仮想メディア |
|
Cisco UCS C シリーズおよび X シリーズサーバーで Redfish 仮想メディアを有効にするには、address
設定で redfish-virtualmedia://
を使用します。以下の例は、install-config.yaml
ファイル内で Redfish 仮想メディアを使用する方法を示しています。
アウトオブバンド管理のアドレスには認証局証明書を用意することを推奨します。ただし、自己署名証明書を使用する場合は、bmc
設定に disableCertificateVerification: True
を含める必要があります。次の例は、install-config.yaml
ファイル内の disableCertificateVerification: True
設定パラメーターを使用した Redfish 設定を示しています。
3.3.14.9. ルートデバイスのヒント リンクのコピーリンクがクリップボードにコピーされました!
rootDeviceHints
パラメーターは、インストーラーが Red Hat Enterprise Linux CoreOS (RHCOS) イメージを特定のデバイスにプロビジョニングできるようにします。インストーラーは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。インストーラーは、ヒント値に一致する最初に検出されたデバイスを使用します。この設定は複数のヒントを組み合わせることができますが、デバイスは、インストーラーがこれを選択できるようにすべてのヒントに一致する必要があります。
サブフィールド | 説明 |
---|---|
|
注記
ストレージの場所への ヒントは、実際の値と完全に一致する必要があります。 |
|
|
| ベンダー固有のデバイス識別子を含む文字列。ヒントは、実際の値のサブ文字列になります。 |
| デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。 |
| デバイスのシリアル番号を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| デバイスの最小サイズ (ギガバイト単位) を表す整数。 |
| 一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| ベンダー拡張が追加された一意のストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| 一意のベンダーストレージ ID を含む文字列。ヒントは、実際の値と完全に一致する必要があります。 |
| デバイスがローテーションするディスクである (true) か、そうでないか (false) を示すブール値。 |
使用例
3.3.14.10. プロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
プロキシーを使用して OpenShift Container Platform クラスターをデプロイするには、install-config.yaml
ファイルに以下の変更を加えます。
手順
proxy
キーマッピングの下にプロキシー値を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下は、値を含む
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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーを有効な状態にして、対応するキー/値のペアでプロキシーの適切な値を設定します。
主な留意事項:
-
プロキシーに HTTPS プロキシーがない場合、
httpsProxy
の値をhttps://
からhttp://
に変更します。 -
クラスターがプロビジョニングネットワークを使用する場合は、それを
noProxy
設定に含めます。そうしないと、インストールプログラムは失敗します。 -
プロビジョナーノード内の環境変数としてすべてのプロキシー設定を設定します。たとえば、
HTTP_PROXY
、HTTPS_PROXY
、およびNO_PROXY
が含まれます。
-
プロキシーに HTTPS プロキシーがない場合、
3.3.14.11. プロビジョニングネットワークを使用しないデプロイ リンクのコピーリンクがクリップボードにコピーされました!
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.3.14.12. デュアルスタックネットワークを使用したデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのデュアルスタックネットワークでは、クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定できます。クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定するには、install-config.yaml
ファイルで machineNetwork
、clusterNetwork
、および serviceNetwork
設定を編集します。それぞれの設定には、それぞれ 2 つの CIDR エントリーが必要です。プライマリーアドレスファミリーとして IPv4 ファミリーを持つクラスターの場合は、最初に IPv4 設定を指定します。プライマリーアドレスファミリーとして IPv6 ファミリーを持つクラスターの場合は、最初に IPv6 設定を指定します。
ベアメタルプラットフォームで、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.3.14.13. ホストネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
インストールの前に、install-config.yaml
ファイルで networkConfig
設定を設定し、NMState を使用してホストネットワークインターフェイスを設定できます。
この機能の最も一般的な使用例は、ベアメタルネットワークで静的 IP アドレスを指定することですが、ストレージネットワークなどの他のネットワークを設定することもできます。この機能は、VLAN、VXLAN、ブリッジ、ボンド、ルート、MTU、DNS リゾルバー設定など、他の NMState 機能をサポートします。
クラスターの DNS リゾルバー設定で、サポートされていない rotate
オプションを設定しないでください。このオプションは、内部 API の DNS 解決機能を妨害します。
前提条件
-
静的 IP アドレスを持つ各ノードの有効なホスト名で
PTR
DNS レコードを設定する。 -
NMState CLI (
nmstate
) をインストールする。
プロビジョニングネットワークを使用する場合は、Ironic の dnsmasq
ツールを使用して設定してください。完全に静的なデプロイメントを行うには、仮想メディアを使用する必要があります。
手順
オプション: インストールプログラムは 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.3.14.14. サブネット用のホストネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
エッジコンピューティングのシナリオでは、コンピュートノードをエッジの近くに配置することが有益な場合があります。サブネット内のリモートノードを見つけるために、コントロールプレーンサブネットやローカルコンピュートノードに使用したものとは異なるネットワークセグメントまたはサブネットをリモートノードに使用できます。エッジコンピューティングシナリオ用にサブネットを設定することで、エッジのレイテンシーが短縮され、拡張性が向上します。
デフォルトのロードバランサー 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.3.14.15. デュアルスタックネットワーク内における SLAAC のアドレス生成モードの設定 リンクのコピーリンクがクリップボードにコピーされました!
Stateless Address AutoConfiguration (SLAAC) を使用するデュアルスタッククラスターの場合は、ipv6.addr-gen-mode
ネットワーク設定のグローバル値を指定する必要があります。NMState を使用してこの値を設定し、RAM ディスクとクラスター設定ファイルを設定できます。これらの場所で一貫した 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.3.14.16. デュアルポート NIC 用のホストネットワークインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
インストール前に、install-config.yaml
ファイルで networkConfig
を設定し、NMState を使用してデュアルポートネットワークインターフェイスコントローラー (NIC) をサポートすることで、ホストネットワークインターフェイスを設定できます。
OpenShift Virtualization は以下のボンドモードのみをサポートします。
-
mode=1 active-backup
-
mode=2 balance-xor
-
mode=4 802.3ad
前提条件
-
静的 IP アドレスを持つ各ノードの有効なホスト名で
PTR
DNS レコードを設定する。 -
NMState CLI (
nmstate
) をインストールする。
YAML 構文にエラーがあると、ネットワーク設定の適用に失敗する可能性があります。YAML 構文を検証して管理することは、デプロイ後に Kubernetes NMState を使用して変更を適用するときや、クラスターを拡張するときに役立ちます。
手順
install-config.yaml
ファイル内のホストのnetworkConfig
フィールドに NMState 設定を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
networkConfig
フィールドには、ホストのネットワーク設定に関する情報を含めます。interfaces
、dns-resolver
、routes
などのサブフィールドがあります。- 2
interfaces
フィールドは、ホスト用に定義されたネットワークインターフェイスの配列です。- 3
- インターフェイスの名前。
- 4
- インターフェイスのタイプ。この例では、イーサネットインターフェイスを作成します。
- 5
- 厳密に必要ではない場合、物理機能 (PF) の DHCP を無効にするには、これを false に設定します。
- 6
- インスタンス化する SR-IOV 仮想機能 (VF) の数に設定します。
- 7
- これを
up
に設定します。 - 8
- ボンドに接続された VF の IPv4 アドレス指定を無効にするには、これを
false
に設定します。 - 9
- VF の最小伝送速度 (Mbps) を設定します。このサンプル値は、100 Mbps のレートを設定します。
- この値は、最大伝送レート以下である必要があります。
-
Intel NIC は
min-tx-rate
パラメーターをサポートしていません。詳細は、BZ#1772847 を参照してください。
- 10
- VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。
- 11
- 必要なボンディングモードを設定します。
- 12
- ボンディングインターフェイスの優先ポートを設定します。ボンディングは、プライマリーデバイスをボンディングインターフェイスの最初のデバイスとして使用します。ボンディングは、障害が発生しない限り、プライマリーデバイスインターフェイスを放棄しません。この設定が特に役立つのは、ボンディングインターフェイスの NIC の 1 つが高速なため、大規模な負荷に対応できる場合です。この設定は、ボンディングインターフェイスが active-backup モード (モード 1) の場合にのみ有効です。
- 13
- ボンドインターフェイスの静的 IP アドレスを設定します。これはノードの IP アドレスです。
- 14
- デフォルトルートのゲートウェイとして
bond0
を設定します。重要クラスターをデプロイした後は、
install-config.yaml
ファイルのnetworkConfig
設定を変更してホストネットワークインターフェイスを変更することはできません。Kubernetes NMState Operator を使用して、デプロイ後にホストネットワークインターフェイスに変更を加えます。
3.3.14.17. 複数のクラスターノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
同じ設定で OpenShift Container Platform クラスターノードを同時に設定できます。複数のクラスターノードを設定すると、各ノードの冗長な情報が install-config.yaml
ファイルに追加されることを回避できます。このファイルには、クラスター内の複数のノードに同一の設定を適用するための特定のパラメーターが含まれています。
コンピュートノードは、コントローラーノードとは別に設定されます。ただし、両方のノードタイプの設定では、install-config.yaml
ファイルで強調表示されているパラメーターを使用して、マルチノード設定を有効にします。次の例に示すように、networkConfig
パラメーターを BOND
に設定します。
複数のクラスターノードの設定は、installer-provisioned infrastructure での初期デプロイメントでのみ使用できます。
3.3.14.18. マネージドセキュアブートの設定 リンクのコピーリンクがクリップボードにコピーされました!
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.3.15. マニフェスト設定ファイル リンクのコピーリンクがクリップボードにコピーされました!
3.3.15.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.3.15.2. 非接続クラスター向けの NTP 設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスターノードに chrony
Network Time Protocol (NTP) サービスをインストールします。
OpenShift Container Platform のノードは、適切に実行するために日付と時刻が一致している必要があります。コンピュートノードがコントロールプレーンノード上の NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続していないために上位層の NTP サーバーにアクセスできないクラスターのインストールと操作が可能になります。
手順
次のコマンドを使用して、インストールホストに Butane をインストールします。
sudo dnf -y install butane
$ sudo dnf -y install butane
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンノードの
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.3.15.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.3.15.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
に設定します。3 つ以上のコンピュートノードを使用する場合は、必要に応じて、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.3.15.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.3.15.6. RAID の設定 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、インストールプロセス中にベースボード管理コントローラー (BMC) を使用して Redundant Array of Independent Disks (RAID) を構成します。
ノードにハードウェア RAID を設定する場合は、ノードにサポートされている RAID コントローラーがあることを確認してください。OpenShift Container Platform 4.19 は、ソフトウェア RAID をサポートしていません。
ベンター | BMC とプロトコル | ファームウェアのバージョン | RAID レベル |
---|---|---|---|
Fujitsu | iRMC | 該当なし | 0、1、5、6、10 |
Dell | iDRAC と Redfish | バージョン 6.10.30.20 以降 | 0、1、5 |
手順
- マニフェストを作成します。
ノードに対応する
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.19 はソフトウェア 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.3.15.7. ノード上のストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Machine Config Operator (MCO) によって管理される MachineConfig
オブジェクトを作成することにより、OpenShift Container Platform ノード上のオペレーティングシステムに変更を加えることができます。
MachineConfig
仕様には、最初の起動時にマシンを設定するための点火設定が含まれています。この設定オブジェクトを使用して、OpenShift Container Platform マシン上で実行されているファイル、systemd サービス、およびその他のオペレーティングシステム機能を変更できます。
手順
ignition config を使用して、ノード上のストレージを設定します。次の MachineSet
マニフェストの例は、プライマリーノード上のデバイスにパーティションを追加する方法を示しています。この例では、インストール前にマニフェストを適用して、プライマリーノードでサイズが 16 GiB の recovery
という名前のパーティションを設定します。
custom-partitions.yaml
ファイルを作成し、パーティションレイアウトを含むMachineConfig
オブジェクトを含めます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow custom-partitions.yaml
ファイルを保存して、clusterconfigs/openshift
ディレクトリーにコピーします。cp ~/<MachineConfig_manifest> ~/clusterconfigs/openshift
$ cp ~/<MachineConfig_manifest> ~/clusterconfigs/openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.16. 非接続レジストリーの作成 リンクのコピーリンクがクリップボードにコピーされました!
インストールレジストリーのローカルコピーを使用して OpenShift Container Platform クラスターをインストールする必要がある場合があります。これにより、クラスターノードがインターネットにアクセスできないネットワーク上にあるため、ネットワークの効率が高まる可能性があります。
レジストリーのローカルまたはミラーリングされたコピーには、以下が必要です。
- レジストリーの証明書。これには、自己署名証明書を使用できます。
- システム上のコンテナーが提供する Web サーバー。
- 証明書およびローカルリポジトリーの情報が含まれる更新されたプルシークレット。
レジストリーノードでの非接続レジストリーの作成はオプションです。レジストリーノードで切断されたレジストリーを作成する必要がある場合は、次のサブセクションをすべて完了する必要があります。
3.3.16.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 非接続インストールのイメージのミラーリング 用にミラーレジストリーをすでに準備している場合は、非接続レジストリーを使用するように install-config.yaml ファイルを変更する へそのままスキップできます。
3.3.16.2. ミラーリングされたレジストリーをホストするためのレジストリーノードの準備 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルでミラー化されたレジストリーをホストする前に、次の手順を完了する必要があります。
手順
レジストリーノードでファイアウォールポートを開きます。
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.3.16.3. 切断されたレジストリーの OpenShift Container Platform イメージリポジトリーのミラーリング リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を実行して、切断されたレジストリーの OpenShift Container Platform イメージリポジトリーをミラーリングします。
前提条件
- ミラーホストがインターネットにアクセスできる。
- ネットワークが制限された環境で使用するミラーレジストリーを設定し、設定した証明書および認証情報にアクセスできる。
- Red Hat OpenShift Cluster Manager からプルシークレット をダウンロードし、ミラーリポジトリーへの認証を組み込むように変更している。
手順
- Download 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
を指定する必要があります。クラスターのアーキテクチャーのタイプをエクスポートします。
ARCHITECTURE=<cluster_architecture>
$ ARCHITECTURE=<cluster_architecture>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
x86_64
、aarch64
、s390x
、またはppc64le
など、クラスターのアーキテクチャーを指定します。
ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。
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.3.16.4. 非接続レジストリーを使用するように 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.3.17. インストールの検証チェックリスト リンクのコピーリンクがクリップボードにコピーされました!
- ❏ OpenShift Container Platform インストーラーが取得されている。
- ❏ OpenShift Container Platform インストーラーが展開されている。
-
❏
install-config.yaml
の必須パラメーターが設定されている。 -
❏
install-config.yaml
のhosts
パラメーターが設定されている。 -
❏
install-config.yaml
のbmc
パラメーターが設定されている。 -
❏
bmc
address
フィールドで設定されている値の変換が適用されている。 - ❏ OpenShift Container Platform マニフェストが作成されている。
- ❏ (オプション) コンピュートノードにルーターがデプロイされている。
- ❏ (オプション) 切断されたレジストリーを作成している。
- ❏ (オプション) 非接続レジストリー設定が使用されている場合にこれを検証する。
3.4. クラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
3.4.1. 以前のインストールのクリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
以前にデプロイが失敗した場合は、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 次のコマンドを使用して、以前のインストールにより生成されたアーティファクトを削除します。
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 次のコマンドを使用して、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
3.4.2. 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
3.4.3. インストールの進行状況を追跡 リンクのコピーリンクがクリップボードにコピーされました!
デプロイメントプロセスで、tail
コマンドを install ディレクトリーフォルダーの .openshift_install.log
ログファイルに対して実行して、インストールの全体のステータスを確認できます。
tail -f /path/to/install-dir/.openshift_install.log
$ tail -f /path/to/install-dir/.openshift_install.log
3.4.4. 静的 IP アドレス設定の検証 リンクのコピーリンクがクリップボードにコピーされました!
クラスターノードの DHCP 予約で無限リースが指定されている場合、インストーラーがノードを正常にプロビジョニングした後に、dispatcher スクリプトはノードのネットワーク設定をチェックします。ネットワーク設定に無限 DHCP リースが含まれているとスクリプトが判断すると、DHCP リースの IP アドレスを静的 IP アドレスとして使用して新規接続を作成します。
dispatcher スクリプトは、クラスター内の他のノードのプロビジョニングの進行中に、正常にプロビジョニングされたノードで実行される場合があります。
ネットワーク設定が正しく機能していることを確認します。
手順
- ノードのネットワークインターフェイス設定を確認してください。
- DHCP サーバーをオフにし、OpenShift Container Platform ノードを再起動して、ネットワーク設定が適切に機能していることを確認します。
3.5. インストールのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
3.5.1. インストールプログラムワークフローのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
インストール環境のトラブルシューティングを行う前に、ベアメタルへの installer-provisioned installation の全体的なフローを理解することが重要です。次の図は、環境のトラブルシューティングフローをステップごとに示したものです。
ワークフロー 1/4 は、install-config.yaml
ファイルにエラーがある場合や Red Hat Enterprise Linux CoreOS (RHCOS) イメージにアクセスできない場合のトラブルシューティングのワークフローを説明しています。トラブルシューティングに関する提案は、install-config.yaml
のトラブルシューティング を参照してください。
ワークフロー 2/4 は、ブートストラップ仮想マシンの問題、クラスターノードを起動できないブートストラップ仮想マシン、および ログの検査 に関するトラブルシューティングのワークフローを説明しています。provisioning
ネットワークなしに OpenShift Container Platform クラスターをインストールする場合は、このワークフローは適用されません。
ワークフロー 3/4 は、PXE ブートしないクラスターノード のトラブルシューティングワークフローを示しています。Redfish 仮想メディアを使用してインストールする場合、インストールプログラムによるノードのデプロイに必要な最小ファームウェア要件を各ノードが満たしている必要があります。詳細は、前提条件 セクションの 仮想メディアを使用したインストールのファームウェア要件 を参照してください。
ワークフロー 4/4 は、アクセスできない API から 検証済みのインストール までのトラブルシューティングワークフローを示しています。
3.5.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 サーバーからの有効な応答があります。
3.5.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
ファイル内で設定されていることを確認します。
3.5.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
3.5.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
3.5.5. クラスターの初期化失敗のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムは、Cluster Version Operator を使用して、OpenShift Container Platform クラスターのすべてのコンポーネントを作成します。インストールプログラムがクラスターの初期化に失敗した場合は、ClusterVersion
オブジェクトと ClusterOperator
オブジェクトから最も重要な情報を取得できます。
手順
次のコマンドを実行して
ClusterVersion
オブジェクトを検査します。oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion -o yaml
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して状態を表示します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion version \ -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusterversion version \ -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最も重要な状態は、
Failing
、Available
、Progressing
です。出力例
Available True Done applying 4.1.1 Failing False Progressing False Cluster version is 4.0.0-0.alpha-2019-02-26-194020 RetrievedUpdates False Unable to retrieve available updates: unknown version 4.1.1
Available True Done applying 4.1.1 Failing False Progressing False Cluster version is 4.0.0-0.alpha-2019-02-26-194020 RetrievedUpdates False Unable to retrieve available updates: unknown version 4.1.1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して
ClusterOperator
オブジェクトを検査します。oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、クラスター Operators のステータスを返します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、個々のクラスター Operator を検査します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> -oyaml
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> -oyaml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<operator>
は、クラスター Operator の名前に置き換えます。このコマンドは、クラスター Operator のステータスがAvailable
にならない理由、またはFailed
になる理由を特定するために使用できます。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター Operator のステータス条件を取得するには、次のコマンドを実行します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> \ -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator <operator> \ -o=jsonpath='{range .status.conditions[*]}{.type}{" "}{.status}{" "}{.message}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <operator>
は、上記のいずれかの Operator の名前に置き換えます。出力例
Available True Successfully rolled out the stack Progressing False Failing False
Available True Successfully rolled out the stack Progressing False Failing False
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター Operator が所有するオブジェクトのリストを取得するには、次のコマンドを実行します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator kube-apiserver \ -o=jsonpath='{.status.relatedObjects}'
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator kube-apiserver \ -o=jsonpath='{.status.relatedObjects}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[map[resource:kubeapiservers group:operator.openshift.io name:cluster] map[group: name:openshift-config resource:namespaces] map[group: name:openshift-config-managed resource:namespaces] map[group: name:openshift-kube-apiserver-operator resource:namespaces] map[group: name:openshift-kube-apiserver resource:namespaces]]
[map[resource:kubeapiservers group:operator.openshift.io name:cluster] map[group: name:openshift-config resource:namespaces] map[group: name:openshift-config-managed resource:namespaces] map[group: name:openshift-kube-apiserver-operator resource:namespaces] map[group: name:openshift-kube-apiserver resource:namespaces]]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.6. コンソール URL の取得に失敗した場合のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムは、openshift-console
namespace 内の [route][route-object]
を使用して、OpenShift Container Platform コンソールの URL を取得します。インストールプログラムがコンソールの URL の取得に失敗した場合は、次の手順に従います。
手順
次のコマンドを実行して、コンソールルーターが
Available
状態かFailing
状態かを確認します。oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator console -oyaml
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get clusteroperator console -oyaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、コンソール URL を手動で取得します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get route console -n openshift-console \ -o=jsonpath='{.spec.host}' console-openshift-console.apps.adahiya-1.devcluster.openshift.com
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get route console -n openshift-console \ -o=jsonpath='{.spec.host}' console-openshift-console.apps.adahiya-1.devcluster.openshift.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.7. kubeconfig に Ingress 証明書を追加できない場合のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムは、${INSTALL_DIR}/auth/kubeconfig
内の信頼できるクライアント認証局のリストにデフォルトの Ingress 証明書を追加します。インストールプログラムが Ingress 証明書を kubeconfig
ファイルに追加できない場合は、クラスターから証明書を取得して追加できます。
手順
次のコマンドを使用して、クラスターから証明書を取得します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get configmaps default-ingress-cert \ -n openshift-config-managed -o=jsonpath='{.data.ca-bundle\.crt}'
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig get configmaps default-ingress-cert \ -n openshift-config-managed -o=jsonpath='{.data.ca-bundle\.crt}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
${INSTALL_DIR}/auth/kubeconfig
ファイルのclient-certificate-authority-data
フィールドに証明書を追加します。
3.5.8. クラスターノードへの SSH アクセスのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
セキュリティーを強化するために、デフォルトではクラスターの外部からクラスターに SSH 接続することは禁止されています。ただし、プロビジョナーノードからコントロールプレーンノードとワーカーノードにアクセスすることはできます。プロビジョナーノードからクラスターノードに SSH 接続できない場合、クラスターノードがブートストラップ仮想マシンを待機している可能性があります。コントロールプレーンノードはブートストラップ仮想マシンからブート設定を取得します。コントロールプレーンノードはブート設定を取得しないと、正常に起動できません。
手順
- ノードに物理的にアクセスできる場合は、コンソールの出力をチェックして、正常に起動したかどうかを確認します。ノードがまだブート設定を取得中の場合は、ブートストラップ仮想マシンに問題がある可能性があります。
-
install-config.yaml
ファイルでsshKey: '<ssh_pub_key>'
が設定されていることを確認します。<ssh_pub_key>
は、プロビジョナーノード上のkni
ユーザーの公開鍵です。
3.5.9. クラスターノードが 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
3.5.10. インストールしてもワーカーノードが作成されない リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムはワーカーノードを直接プロビジョニングしません。代わりに、Machine API Operator が、サポートされているプラットフォーム上でノードをスケールアップおよびスケールダウンします。クラスターのインターネット接続の速度によって異なりますが、15 - 20 分経ってもワーカーノードが作成されない場合は、Machine API Operator を調査してください。
手順
次のコマンドを実行して、Machine API Operator を確認します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \ --namespace=openshift-machine-api get deployments
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \ --namespace=openshift-machine-api get deployments
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ご使用の環境で
${INSTALL_DIR}
が設定されていない場合は、値をインストールディレクトリーの名前に置き換えます。出力例
NAME READY UP-TO-DATE AVAILABLE AGE cluster-autoscaler-operator 1/1 1 1 86m cluster-baremetal-operator 1/1 1 1 86m machine-api-controllers 1/1 1 1 85m machine-api-operator 1/1 1 1 86m
NAME READY UP-TO-DATE AVAILABLE AGE cluster-autoscaler-operator 1/1 1 1 86m cluster-baremetal-operator 1/1 1 1 86m machine-api-controllers 1/1 1 1 85m machine-api-operator 1/1 1 1 86m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マシンコントローラーのログを確認します。
oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \ --namespace=openshift-machine-api logs deployments/machine-api-controllers \ --container=machine-controller
$ oc --kubeconfig=${INSTALL_DIR}/auth/kubeconfig \ --namespace=openshift-machine-api logs deployments/machine-api-controllers \ --container=machine-controller
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.11. Cluster Network Operator のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator は、ネットワークコンポーネントのデプロイを担当します。この Operator は、コントロールプレーンノードが起動した後、インストールプログラムがブートストラップコントロールプレーンを削除する前に、インストールプロセスの初期段階で実行されます。この Operator に問題がある場合、インストールプログラムに問題がある可能性があります。
手順
次のコマンドを実行して、ネットワーク設定が存在することを確認します。
oc get network -o yaml cluster
$ oc get network -o yaml cluster
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 マニフェストを確認して、インストールプログラムがネットワーク設定を作成しなかった理由を特定します。
次のコマンドを入力して、ネットワークが実行中であることを確認します。
oc get po -n openshift-network-operator
$ oc get po -n openshift-network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.12. BMC を使用して、新しいベアメタルホストを検出できない リンクのコピーリンクがクリップボードにコピーされました!
場合によっては、リモート仮想メディア共有をマウントできないため、インストールプログラムが新しいベアメタルホストを検出できず、エラーが発生することがあります。
以下に例を示します。
この状況で、認証局が不明な仮想メディアを使用している場合は、不明な認証局を信頼するように、ベースボード管理コントローラー (BMC) のリモートファイル共有設定を行って、このエラーを回避できます。
この解決策は、Dell iDRAC 9 およびファームウェアバージョン 5.10.50 を搭載した OpenShift Container Platform 4.11 でテストされました。
3.5.13. クラスターに参加できないワーカーノードのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
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
これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。
3.5.14. 以前のインストールのクリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
以前にデプロイが失敗した場合は、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 次のコマンドを使用して、以前のインストールにより生成されたアーティファクトを削除します。
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 次のコマンドを使用して、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
3.5.15. レジストリーの作成に関する問題 リンクのコピーリンクがクリップボードにコピーされました!
非接続レジストリーの作成時に、レジストリーのミラーリングを試行する際に "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
3.5.16. その他の問題点 リンクのコピーリンクがクリップボードにコピーされました!
3.5.16.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 を参照してください。
3.5.16.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 を収集し、それを設定に組み込んでください。
3.5.16.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 アドレス範囲を提供する必要なインターフェイスでリッスンしていることを確認します。
3.5.16.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
3.5.16.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 が正常に起動されなくなる可能性があります。
3.5.16.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
3.5.16.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.32.3 master-1.cloud.example.com Ready master 135m v1.32.3 master-2.cloud.example.com Ready master 145m v1.32.3 worker-2.cloud.example.com Ready worker 100m v1.32.3
NAME STATUS ROLES AGE VERSION master-0.cloud.example.com Ready master 145m v1.32.3 master-1.cloud.example.com Ready master 135m v1.32.3 master-2.cloud.example.com Ready master 145m v1.32.3 worker-2.cloud.example.com Ready worker 100m v1.32.3
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 クラスターの作成を継続します。
3.5.17. インストールの確認 リンクのコピーリンクがクリップボードにコピーされました!
インストール後、インストールプログラムによってノードと 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.32.3 master-1.example.com Ready master,worker 4h v1.32.3 master-2.example.com Ready master,worker 4h v1.32.3
NAME STATUS ROLES AGE VERSION master-0.example.com Ready master,worker 4h v1.32.3 master-1.example.com Ready master,worker 4h v1.32.3 master-2.example.com Ready master,worker 4h v1.32.3
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
第4章 インストール後の設定 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスターを正常にデプロイした後、次のインストール後の手順を検討してください。
4.1. Cluster API について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.19 以降のリリースでは、Cluster API を使用してマシンを管理できます。
Cluster API を使用したマシン管理は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
クラスターのインストールが完了したら、Cluster API を使用してコンピュートノードプロビジョニング管理アクションを実行できます。Cluster API を使用すると、コンピュートノードマシンセットとマシンを動的に管理できます。ただし、コントロールプレーンマシンはサポートされていません。
4.2. 非接続クラスター向けの NTP 設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスターノードに chrony
Network Time Protocol (NTP) サービスをインストールします。次の手順を使用して、コントロールプレーンノードに NTP サーバーを設定し、デプロイが成功した後にコンピュートノードをコントロールプレーンノードの NTP クライアントとして設定します。
OpenShift Container Platform のノードは、適切に実行するために日付と時刻が一致している必要があります。コンピュートノードがコントロールプレーンノード上の NTP サーバーから日付と時刻を取得すると、ルーティング可能なネットワークに接続していないために上位層の NTP サーバーにアクセスできないクラスターのインストールと操作が可能になります。
手順
次のコマンドを使用して、インストールホストに Butane をインストールします。
sudo dnf -y install butane
$ sudo dnf -y install butane
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンノードの
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
4.3. インストール後のプロビジョニングネットワークの有効化 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスター用の 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
4.4. カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
configure-ovs.sh
シェルスクリプトを使用してベアメタルプラットフォームで br-ex
ブリッジを設定する代わりに、NMState 設定ファイルを含む NodeNetworkConfigurationPolicy
(NNCP) カスタムリソース (CR) を作成することもできます。Kubernetes NMState Operator がその NMState 設定ファイルを使用して、カスタマイズされた br-ex
ブリッジネットワーク設定をクラスター内の各ノードに作成します。
NodeNetworkConfigurationPolicy
CR を作成したら、クラスターのインストール中に作成された NMState 設定ファイルの内容を NNCP CR にコピーしてください。NNCP CR のファイルが不完全な場合、ファイルに記述されているネットワークポリシーをクラスター内のノードに適用できません。
この機能は、次のタスクをサポートします。
- クラスターの最大転送単位 (MTU) を変更します。
- MIImon (Media Independent Interface Monitor)、ボンディングモード、Quality of Service (QoS) などのさまざまなボンディングインターフェイスの属性を変更します。
- DNS 値を更新しています。
カスタマイズされた br-ex
ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。
-
Open vSwitch (OVS) または OVN-Kubernetes
br-ex
ブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.sh
シェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。 - ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
-
configure-ovs.sh
シェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。
次のインターフェイス名は予約されており、NMstate 設定では使用できません。
-
br-ext
-
br-int
-
br-local
-
br-nexthop
-
br0
-
ext-vxlan
-
ext
-
genev_sys_*
-
int
-
k8s-*
-
ovn-k8s-*
-
patch-br-*
-
tun0
-
vxlan_sys_*
前提条件
-
configure-ovs
の代替方法を使用して、カスタマイズされたbr-ex
を設定している。 - Kubernetes NMState Operator がインストールされている。
手順
NodeNetworkConfigurationPolicy
(NNCP) CR を作成し、カスタマイズされたbr-ex
ブリッジネットワーク設定を定義します。必要に応じて、ipv4.address.ip
、ipv6.address.ip
、またはその両方のパラメーターにマスカレード IP を設定するようにしてください。NNCP CR には常にマスカレード IP アドレスを含めてください。このアドレスは使用中の IP アドレスブロックと一致する必要があります。重要インストール後のタスクとして、既存の NNCP CR で定義したカスタマイズされた
br-ex
ブリッジのほとんどのパラメーター (カスタマイズされたbr-ex
ブリッジのプライマリー IP アドレスを除く) を設定できます。シングルスタッククラスターネットワークをデュアルスタッククラスターネットワークに変換する場合、NNCP CR でセカンダリー IPv6 アドレスは追加または変更できますが、既存のプライマリー IP アドレスは変更できません。
IPv6 および IPv4 マスカレード IP アドレスを設定する NNCP CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
-
コンピュートノードをスケーリングして、クラスター内に存在する各コンピュートノードに、カスタマイズされた
br-ex
ブリッジを含むマニフェストオブジェクトを適用します。詳細は、関連情報 セクションの「クラスターの拡張」を参照してください。
4.5. カスタマイズした br-ex ブリッジに中断を伴う変更を加える リンクのコピーリンクがクリップボードにコピーされました!
状況によっては、計画的なメンテナンスやネットワーク設定の更新のために、中断を伴う変更を br-ex
ブリッジに加える必要があります。br-ex
ブリッジは、ワークロードから発信されるすべての外部ネットワークトラフィックのゲートウェイです。そのため、このブリッジに変更を加えると、Pod と仮想マシン (VM) が外部ネットワークから一時的に切断される可能性があります。
次の手順では、実行中のクラスターワークロードへの影響を最小限に抑えながら、中断を伴う変更を br-ex
ブリッジに加える例を示します。
クラスター内のすべてのノードに br-ex
ブリッジの変更を反映するには、クラスターを再起動する必要があります。既存の MachineConfig
オブジェクトを編集しても再起動操作は強制されません。そのため、クラスターの再起動操作を強制するには、追加の MachineConfig
オブジェクトを作成する必要があります。
Red Hat は、インストール後のタスクとしてノードの IP アドレスを変更することをサポートしていません。
前提条件
-
br-ex
ブリッジを含むマニフェストオブジェクトを作成した。 -
br-ex
ブリッジが設定されたクラスターをデプロイした。
手順
br-ex
ブリッジネットワークインターフェイスをカスタマイズするために、クラスターのインストール時に作成した NMState 設定ファイルに変更を加えます。重要MachineConfig
オブジェクトを保存する前に、変更したパラメーター値を確認してください。間違った値を入力してファイルを保存すると、ファイルを元の状態に復元できなくなり、クラスターのネットワーク機能に影響が生じます。次のコマンドを入力して、
base64
コマンドを使用して NMState 設定の内容を再エンコードします。base64 -w0 <nmstate_configuration>.yml
$ base64 -w0 <nmstate_configuration>.yml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nmstate_configuration>
を NMState リソース YAML ファイルの名前に置き換えます。
-
クラスターのインストール時に作成した
MachineConfig
マニフェストファイルを更新し、カスタマイズしたbr-ex
ブリッジネットワークインターフェイスを再定義します。 次のコマンドを入力して、
MachineConfig
オブジェクトの更新をクラスターに適用します。oc apply -f <machine_config>.yml
$ oc apply -f <machine_config>.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最小限の
MachineConfig
オブジェクトを作成します。ファイルの設定は変更しないでください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、最小限の
MachineConfig
オブジェクト設定をクラスターに適用し、再起動操作を開始します。oc apply -f <bare_machine_config>.yml
$ oc apply -f <bare_machine_config>.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、クラスター内の各ノードが再起動が完了したことを示す
Ready
ステータスになっていることを確認します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、最小限の
MachineConfig
オブジェクトを削除します。oc delete machineconfig <machine_config_name>
$ oc delete machineconfig <machine_config_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
nmstatectl
ツールを使用して次のコマンドを実行し、br-ex
ブリッジインターフェイスの設定を確認します。このツールは、MachineConfig
オブジェクトをデプロイした場所ではなく、br-ex
ブリッジインターフェイスを実行するノードを確認します。sudo nmstatectl show br-ex
$ sudo nmstatectl show br-ex
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6. ユーザー管理ロードバランサーのサービス リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。
ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図4.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図4.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図4.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 が未定義のノードに移動すると、接続が停止する可能性があります。
4.6.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、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。
1 つのサブネットをリストした HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 複数のサブネットをリストした 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 レコードが伝播されることを確認してください。
OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの
install-config.yaml
ファイルで次の設定を指定する必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスターのユーザー管理ロードバランサーを指定するには、
type
パラメーターにUserManaged
を設定します。パラメーターのデフォルトはOpenShiftManagedDefault
で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra
namespace で定義されたサービスの場合、ユーザー管理ロードバランサーはcoredns
サービスをクラスター内の Pod にデプロイできますが、keepalived
およびhaproxy
サービスは無視します。 - 2
- ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
- 3
- ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。
検証
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
4.7. Bare Metal Operator を使用した設定 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルホストに OpenShift Container Platform をデプロイする場合、プロビジョニングの前後にホストに変更を加える必要がある場合があります。これには、ホストのハードウェア、ファームウェア、ファームウェアの詳細の検証が含まれます。また、ディスクのフォーマットや、変更可能なファームウェア設定の変更も含まれます。
Bare Metal Operator (BMO) を使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査できます。BMO は次の操作を完了できます。
- 特定のイメージを使用したクラスターへのベアメタルホストのプロビジョニング
- ホストをオンまたはオフにします。
- ホストのハードウェアの詳細を検査し、ベアメタルホストへ報告する
- ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードする
- ファームウェアを検査し、BIOS を設定します。
- ホストをプロビジョニングする前または後に、ホストのディスクの内容をクリーンアップします。
BMO はこれらのタスクを完了するために次のリソースを使用します。
-
BareMetalHost
-
HostFirmwareSettings
-
FirmwareSchema
-
HostFirmwareComponents
-
HostUpdatePolicy
BMO は、各ベアメタルホストを BareMetalHost
カスタムリソース定義のインスタンスにマッピングすることにより、クラスター内の物理ホストのインベントリーを維持します。各 BareMetalHost
リソースには、ハードウェア、ソフトウェア、およびファームウェアの詳細が含まれています。BMO は、クラスター内のベアメタルホストを継続的に検査して、各 BareMetalHost
リソースが対応するホストのコンポーネントを正確に詳述していることを確認します。
BMO は、HostFirmwareSettings
リソース、FirmwareSchema
リソース、および HostFirmwareComponents
リソースを使用して、ファームウェア仕様の詳細を指定し、ベアメタルホストのファームウェアをアップグレードまたはダウングレードします。
BMO は、Ironic API サービスを使用してクラスター内のベアメタルホストと接続します。Ironic サービスは、ホスト上のベースボード管理コントローラー (BMC) を使用して、マシンと接続します。
BMO の HostUpdatePolicy
を使用すると、ホストのプロビジョニング後に、ベアメタルホストのファームウェア設定、BMC 設定、または BIOS 設定へのライブ更新を有効または無効にできます。デフォルトでは、BMO はライブ更新を無効にします。
4.7.1. Bare Metal Operator のアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal Operator (BMO) は、次のリソースを使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査します。次の図は、これらのリソースのアーキテクチャーを示しています。
BareMetalHost
BareMetalHost
リソースは、物理ホストとそのプロパティーを定義します。ベアメタルホストをクラスターにプロビジョニングするときは、そのホストの BareMetalHost
リソースを定義する必要があります。ホストの継続的な管理のために、BareMetalHost
リソースの情報を確認したり、この情報を更新したりできます。
BareMetalHost
リソースには、次のようなプロビジョニング情報が含まれます。
- オペレーティングシステムのブートイメージやカスタム RAM ディスクなどのデプロイメント仕様
- プロビジョニング状態
- ベースボード管理コントローラー (BMC) アドレス
- 目的の電源状態
BareMetalHost
リソースには、次のようなハードウェア情報が含まれます。
- CPU 数
- NIC の MAC アドレス
- ホストのストレージデバイスのサイズ
- 現在の電源状態
HostFirmwareSettings
HostFirmwareSettings
リソースを使用して、ホストのファームウェア設定を取得および管理できます。ホストが Available
状態に移行すると、Ironic サービスはホストのファームウェア設定を読み取り、HostFirmwareSettings
リソースを作成します。BareMetalHost
リソースと HostFirmwareSettings
リソースの間には 1 対 1 のマッピングがあります。
HostFirmwareSettings
リソースを使用して、ホストのファームウェア仕様を調べたり、ホストのファームウェア仕様を更新したりできます。
HostFirmwareSettings
リソースの spec
フィールドを編集するときは、ベンダーファームウェアに固有のスキーマに従う必要があります。このスキーマは、読み取り専用の FirmwareSchema
リソースで定義されます。
FirmwareSchema
ファームウェア設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema
リソースは、各ホストモデル上の各ファームウェア設定のタイプおよび制限が含まれる読み取り専用リソースです。データは、Ironic サービスを使用して BMC から直接取得されます。FirmwareSchema
リソースを使用すると、HostFirmwareSettings
リソースの spec
フィールドに指定できる有効な値を特定できます。
スキーマが同じであれば、FirmwareSchema
リソースは多くの BareMetalHost
リソースに適用できます。
HostFirmwareComponents
Metal3 は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents
リソースを提供します。HostFirmwareComponents
リソースの spec
フィールドを編集することで、ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードできます。これは、特定のファームウェアバージョンに対してテストされた検証済みパターンを使用してデプロイする場合に便利です。
HostUpdatePolicy
HostUpdatePolicy
リソースを使用すると、ベアメタルホストのファームウェア設定、BMC 設定、または BIOS 設定のライブ更新を有効または無効にできます。デフォルトでは、各ベアメタルホストの HostUpdatePolicy
リソースにより、ホストへの更新がプロビジョニング中だけに制限されます。ホストをプロビジョニングした後、ファームウェア設定、BMC 設定、または BIOS 設定を更新する場合は、ホストの HostUpdatePolicy
リソースを変更する必要があります。
4.7.2. BareMetalHost リソースについて リンクのコピーリンクがクリップボードにコピーされました!
Metal3 で、物理ホストとそのプロパティーを定義する BareMetalHost
リソースの概念が導入されました。BareMetalHost
リソースには、2 つのセクションが含まれます。
-
BareMetalHost
spec -
BareMetalHost
status
4.7.2.1. BareMetalHost spec リンクのコピーリンクがクリップボードにコピーされました!
BareMetalHost
リソースの spec
セクションは、ホストの必要な状態を定義します。
パラメーター | 説明 |
---|---|
|
プロビジョニングおよびプロビジョニング解除時の自動クリーニングを有効または無効にするインターフェイス。 |
bmc: address: credentialsName: disableCertificateVerification:
|
|
| ホストのプロビジョニングに使用する NIC の MAC アドレス。 |
|
ホストのブートモード。デフォルトは |
|
ホストを使用している別のリソースへの参照。別のリソースが現在ホストを使用していない場合は、空になることがあります。たとえば、 |
| ホストの特定に役立つ、人間が提供した文字列。 |
| ホストのプロビジョニングとプロビジョニング解除が外部で管理されるかどうかを示すブール値。設定される場合:
|
|
ベアメタルホストの BIOS 設定に関する情報が含まれます。現在、
|
image: url: checksum: checksumType: format:
|
|
| ネットワーク設定データおよびその namespace が含まれるシークレットへの参照。したがって、ホストが起動してネットワークをセットアップする前にホストに接続することができます。 |
|
ホストの電源を入れる ( |
raid: hardwareRAIDVolumes: softwareRAIDVolumes:
| (オプション) ベアメタルホストの RAID 設定に関する情報が含まれます。指定しない場合は、現在の設定を保持します。 注記 OpenShift Container Platform 4.19 は、BMC のインストールドライブ上で以下のハードウェア RAID をサポートします。
OpenShift Container Platform 4.19 は、インストールドライブ上のソフトウェア RAID をサポートしていません。 次の構成設定を参照してください。
spec: raid: hardwareRAIDVolume: []
ドライバーが RAID に対応していないことを示すエラーメッセージが表示された場合は、 |
|
|
4.7.2.2. BareMetalHost status リンクのコピーリンクがクリップボードにコピーされました!
BareMetalHost
status は、ホストの現在の状態を表し、テスト済みの認証情報、現在のハードウェアの詳細などの情報が含まれます。
パラメーター | 説明 |
---|---|
| シークレットおよびその namespace の参照で、システムが動作中と検証できるベースボード管理コントローラー (BMC) 認証情報のセットが保持されています。 |
| プロビジョニングバックエンドが報告する最後のエラーの詳細 (ある場合)。 |
| ホストがエラー状態になった原因となった問題のクラスを示します。エラータイプは以下のとおりです。
|
|
|
hardware: firmware:
| BIOS ファームウェア情報が含まれます。たとえば、ハードウェアベンダーおよびバージョンなどです。 |
|
|
hardware: ramMebibytes:
| ホストのメモリー容量 (MiB 単位)。 |
|
|
hardware: systemVendor: manufacturer: productName: serialNumber:
|
ホストの |
| ホストのステータスの最終更新時のタイムスタンプ。 |
| サーバーのステータス。ステータスは以下のいずれかになります。
|
| ホストの電源が入っているかどうかを示すブール値。 |
|
|
| プロビジョニングバックエンドに送信された BMC 認証情報の最後のセットを保持するシークレットおよびその namespace への参照。 |
4.7.3. BareMetalHost リソースの取得 リンクのコピーリンクがクリップボードにコピーされました!
BareMetalHost
リソースには、物理ホストのプロパティーが含まれます。物理ホストのプロパティーをチェックするには、その BareMetalHost
リソースを取得する必要があります。
手順
BareMetalHost
リソースの一覧を取得します。oc get bmh -n openshift-machine-api -o yaml
$ oc get bmh -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記oc get
コマンドで、bmh
の長い形式として、baremetalhost
を使用できます。ホストのリストを取得します。
oc get bmh -n openshift-machine-api
$ oc get bmh -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のホストの
BareMetalHost
リソースを取得します。oc get bmh <host_name> -n openshift-machine-api -o yaml
$ oc get bmh <host_name> -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<host_name>
はホストの名前です。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.4. BareMetalHost リソースの編集 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをベアメタルにデプロイした後、ノードの BareMetalHost
リソースを編集する必要がある場合があります。たとえば、次のような例が考えられます。
- Assisted Installer を使用してクラスターをデプロイし、ベースボード管理コントローラー (BMC) のホスト名または IP アドレスを追加または編集する必要がある。
- ノードをプロビジョニング解除せずに、あるクラスターから別のクラスターに移動する必要がある。
前提条件
-
ノードが
Provisioned
、ExternallyProvisioned
、またはAvailable
状態であることを確認する。
手順
ノードのリストを取得します。
oc get bmh -n openshift-machine-api
$ oc get bmh -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードの
BareMetalHost
リソースを編集する前に、次のコマンドを実行してノードを Ironic からデタッチします。oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true'
$ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true'
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>
はノード名に置き換えてください。
次のコマンドを実行して、
BareMetalHost
リソースを編集します。oc edit bmh <node_name> -n openshift-machine-api
$ oc edit bmh <node_name> -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ノードを Ironic に再アタッチします。
oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-
$ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.5. BareMetalHost リソースを削除する際の遅延のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal Operator (BMO) が BareMetalHost
リソースを削除すると、Ironic はクリーニングと呼ばれるプロセスでベアメタルホストのプロビジョニングを解除します。クリーニングが失敗すると、Ironic はクリーニングプロセスを 3 回再試行します。これが遅延の原因となります。クリーニングプロセスが成功せず、ベアメタルホストのプロビジョニングステータスが deleting 状態のまま無期限に残る原因となります。このような場合は、次の手順に従ってクリーニングプロセスを無効にしてください。
BareMetalHost
リソースからファイナライザーを削除しないでください。
手順
- クリーニングプロセスが失敗して再開された場合は、完了するまで待機します。これには約 5 分かかる場合があります。
-
プロビジョニングステータスが deleting 状態のままの場合は、
BareMetalHost
リソースを変更し、automatedCleaningMode
フィールドをdisabled
に設定して、クリーニングプロセスを無効にします。
詳細は、「BareMetalHost リソースの編集」を参照してください。
4.7.6. ブータブルでない ISO をベアメタルノードにアタッチする リンクのコピーリンクがクリップボードにコピーされました!
DataImage
リソースを使用すると、ブータブルでない汎用の ISO 仮想メディアイメージを、プロビジョニングされたノードにアタッチできます。リソースを適用すると、起動後にオペレーティングシステムから ISO イメージにアクセスできるようになります。これは、オペレーティングシステムをプロビジョニングした後、ノードが初めて起動する前にノードを設定する場合に便利です。
前提条件
- この機能をサポートするために、ノードが Redfish またはそれから派生したドライバーを使用している。
-
ノードが
Provisioned
またはExternallyProvisioned
状態である。 -
name
が、BareMetalHost
リソースで定義されているノードの名前と同じである。 -
ISO イメージへの有効な
url
がある。
手順
DataImage
リソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
DataImage
リソースをファイルに保存します。vim <node_name>-dataimage.yaml
$ vim <node_name>-dataimage.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
DataImage
リソースを適用します。oc apply -f <node_name>-dataimage.yaml -n <node_namespace>
$ oc apply -f <node_name>-dataimage.yaml -n <node_namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- namespace が
BareMetalHost
リソースの namespace と一致するように<node_namespace>
を置き換えます。たとえば、openshift-machine-api
です。
ノードを再起動します。
注記ノードを再起動するには、
reboot.metal3.io
アノテーションを割り当てるか、BareMetalHost
リソースでonline
ステータスをリセットします。ベアメタルノードを強制的に再起動すると、ノードの状態がしばらくの間NotReady
に変わります。具体的には、5 分以上変わります。次のコマンドを実行して、
DataImage
リソースを表示します。oc get dataimage <node_name> -n openshift-machine-api -o yaml
$ oc get dataimage <node_name> -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.7. 共有 NIC の NC-SI と DisablePowerOff の設定 リンクのコピーリンクがクリップボードにコピーされました!
Network Controller Sideband Interface (NC-SI) により、ベースボード管理コントローラー (BMC) は、Redfish、IPMI、ベンダー固有のインターフェイスなどのプロトコルを使用して、管理トラフィック用のシステムネットワークインターフェイスカード (NIC) をホストと共有できるようになります。DisablePowerOff
機能は、ハードな電源オフを防ぎ、ソフトリブートを行うことで BMC との接続を維持します。
前提条件
- NC-SI 対応のハードウェアと NIC。
- IP アドレスとネットワーク接続が設定された BMC。
- BMC への管理アクセス。
-
cluster-admin
特権で OpenShift クラスターにアクセスする。
手順
- 共有 NIC に対して NC-SI を有効にするように BMC を設定します。
次のいずれかのコマンドを実行し、Redfish または IPMI を使用して BMC の接続を確認します。
curl -k https://<bmc_ip>/redfish/v1/Systems/1
$ curl -k https://<bmc_ip>/redfish/v1/Systems/1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ipmitool -I lanplus -H <bmc_ip> -U <user> -P <pass> power status
$ ipmitool -I lanplus -H <bmc_ip> -U <user> -P <pass> power status
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-machine-api
namespace のBareMetalHost
リソースを編集して、DisablePowerOff
機能を有効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サポートされているプロトコルと BMC アドレス形式の詳細は、「BMC アドレス指定」セクションを参照してください。
次のコマンドを実行して変更を適用します。
oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、
BareMetalHost
のステータスを確認します。oc get baremetalhost example-host -n openshift-machine-api -o yaml
$ oc get baremetalhost example-host -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec
セクションにdisablePowerOff: true
があることを確認します。- ノード Pod を再起動してリブートをテストし、BMC 接続がアクティブなままであることを確認します。
-
BareMetalHost.spec.online=false
の設定を試みます。電源オフが無効であることを示すエラーが表示されて失敗するはずです。
4.7.8. HostFirmwareSettings リソースについて リンクのコピーリンクがクリップボードにコピーされました!
HostFirmwareSettings
リソースを使用して、ホストの BIOS 設定を取得および管理できます。ホストが Available
状態に移行すると、Ironic はホストの BIOS 設定を読み取り、HostFirmwareSettings
リソースを作成します。リソースには、ベースボード管理コントローラー (BMC) から返される完全な BIOS 設定が含まれます。BareMetalHost
リソースの firmware
フィールドは、ベンダーに依存しない 3 つのフィールドを返しますが、HostFirmwareSettings
リソースは、通常ホストごとにベンダー固有のフィールドの多数の BIOS 設定で構成されます。
HostFirmwareSettings
リソースには、以下の 2 つのセクションが含まれます。
-
HostFirmwareSettings
spec -
HostFirmwareSettings
status
ファームウェア設定の読み取りと変更は、ベンダーに依存しない Redfish プロトコル、Fujitsu iRMC、または HP iLO ベースのドライバーでのみサポートされます。
4.7.8.1. HostFirmwareSettings spec リンクのコピーリンクがクリップボードにコピーされました!
HostFirmwareSettings
リソースの spec
セクションは、ホストの BIOS の必要な状態を定義し、デフォルトでは空です。Ironic は spec.settings
セクションの設定を使用して、ホストが Preparing
状態の場合、ベースボード管理コントローラー (BMC) を更新します。FirmwareSchema
リソースを使用して、無効な名前と値のペアをホストに送信しないようにします。詳細は、「FirmwareSchema リソースについて」を参照してください。
例
spec: settings: ProcTurboMode: Disabled
spec:
settings:
ProcTurboMode: Disabled
- 1
- 前述の例では、
spec.settings
セクションには、ProcTurboMode
BIOS 設定をDisabled
に設定する名前/値のペアが含まれます。
status
セクションに一覧表示される整数パラメーターは文字列として表示されます。たとえば、"1"
と表示されます。spec.settings
セクションで整数を設定する場合、値は引用符なしの整数として設定する必要があります。たとえば、1
と設定します。
4.7.8.2. HostFirmwareSettings status リンクのコピーリンクがクリップボードにコピーされました!
status
は、ホストの BIOS の現在の状態を表します。
パラメーター | 説明 |
---|---|
|
|
status: schema: name: namespace: lastUpdated:
|
ファームウェア設定の
|
status: settings:
|
|
4.7.9. HostFirmwareSettings リソースの取得 リンクのコピーリンクがクリップボードにコピーされました!
HostFirmwareSettings
リソースには、物理ホストのベンダー固有の BIOS プロパティーが含まれます。物理ホストの BIOS プロパティーをチェックするには、その HostFirmwareSettings
リソースを取得する必要があります。
手順
次のコマンドを実行して、
HostFirmwareSettings
リソースの詳細なリストを取得します。oc get hfs -n openshift-machine-api -o yaml
$ oc get hfs -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記oc get
コマンドで、hfs
の長い形式としてhostfirmwaresettings
を使用できます。次のコマンドを実行して、
HostFirmwareSettings
リソースのリストを取得します。oc get hfs -n openshift-machine-api
$ oc get hfs -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、特定のホストの
HostFirmwareSettings
リソースを取得します。oc get hfs <host_name> -n openshift-machine-api -o yaml
$ oc get hfs <host_name> -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<host_name>
はホストの名前です。
4.7.10. プロビジョニング済みホストの HostFirmwareSettings リソースの編集 リンクのコピーリンクがクリップボードにコピーされました!
プロビジョニング済みホストの HostFirmwareSettings
仕様を変更するには、次の操作を実行します。
-
ホストの
HostFirmwareSettings
リソースを編集します。 - マシンセットからホストを削除します。
- マシンセットをスケールダウンします。
- マシンセットをスケールアップして変更を反映させます。
ホストが provisioned
状態にある場合にのみ、ホストを編集できます (読み取り専用の値を除く)。externally provisioned
状態のホストは編集できません。
手順
次のコマンドを実行して、
HostFirmwareSettings
リソースのリストを取得します。oc get hfs -n openshift-machine-api
$ oc get hfs -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ホストの
HostFirmwareSettings
リソースを編集します。oc edit hfs <hostname> -n openshift-machine-api
$ oc edit hfs <hostname> -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>
はプロビジョニングされたホストの名前です。HostFirmwareSettings
リソースは、ターミナルのデフォルトエディターで開きます。次のコマンドを実行して、
spec.settings
セクションに名前と値のペアを追加します。例
spec: settings: name: value
spec: settings: name: value
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
FirmwareSchema
リソースを使用して、ホストで利用可能な設定を特定します。読み取り専用の値は設定できません。
- 変更を保存し、エディターを終了します。
次のコマンドを実行して、ホストのマシン名を取得します。
oc get bmh <hostname> -n openshift-machine name
$ oc get bmh <hostname> -n openshift-machine name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>
はホストの名前です。ターミナルのCONSUMER
フィールドの下にマシン名が表示されます。次のコマンドを実行して、マシンにアノテーションを付けてマシンセットから削除します。
oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
$ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<machine_name>
は削除するマシンの名前です。次のコマンドを実行して、ノードのリストを取得し、ワーカーノードの数をカウントします。
oc get nodes
$ oc get nodes
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 次のコマンドを実行して、マシンセットをスケールします。
oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <machineset_name>
はマシンセットの名前です。<n-1>
は減少させたワーカーノードの数です。ホストが
Available
状態になったら、次のコマンドを実行してマシンセットをスケールアップし、HostFirmwareSettings
リソースの変更を反映します。oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <machineset_name>
はマシンセットの名前です。<n>
はワーカーノードの数です。
4.7.11. HostFirmwareSettings リソースへのライブ更新の実行 リンクのコピーリンクがクリップボードにコピーされました!
ワークロードの実行を開始した後、HostFirmareSettings
リソースに対してライブ更新を実行できます。ライブ更新では、ホストのプロビジョニング解除と再プロビジョニングはトリガーされません。
ホストのライブ更新はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
-
HostUpdatePolicy
リソースのfirmwareSettings
パラメーターがonReboot
に設定されている。
手順
次のコマンドを実行して、
HostFirmwareSettings
リソースを更新します。oc patch hostfirmwaresettings <hostname> --type merge -p \ '{"spec": {"settings": {"<name>": "<value>"}}}'
$ oc patch hostfirmwaresettings <hostname> --type merge -p \
1 '{"spec": {"settings": {"<name>": "<value>"}}}'
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ハードウェアがサポートする設定と、更新できる設定および値を確認するには、
FirmwareSchema
リソースを取得します。読み取り専用の値を更新することはできません。また、FirmwareSchema
リソースを更新することもできません。oc edit <hostname> hostfirmwaresettings -n openshift-machine-api
コマンドを使用してHostFirmwareSettings
リソースを更新することもできます。次のコマンドを実行して、ノードをスケジューリング対象から外してドレインします。
oc drain <node_name> --force
$ oc drain <node_name> --force
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>
はノード名に置き換えてください。
次のコマンドを実行して、ホストの電源を 5 分間オフにします。
oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このステップにより、デーモンセットまたはコントローラーが、ホスト上で実行されている可能性のあるインフラストラクチャー Pod をオフラインとしてマークし、残りのホストが受信リクエストを処理するようになります。
5 分後、次のコマンドを実行してホストの電源をオンにします。
oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービス操作が開始し、Bare Metal Operator (BMO) が
BareMetalHost
のoperationalStatus
パラメーターをservicing
に設定します。BMO は、リソースを更新した後、operationalStatus
パラメーターをOK
に更新します。エラーが発生した場合、BMO はoperationalStatus
パラメーターをerror
に更新し、操作を再試行します。Ironic が更新を完了し、ホストが起動したら、次のコマンドを実行してノードをスケジューリング対象に戻します。
oc uncordon <node_name>
$ oc uncordon <node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.12. HostFirmware Settings リソースが有効であることの確認 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが spec.settings
セクションを編集して HostFirmwareSetting
(HFS) リソースに変更を加えると、Bare Metal Operator (BMO) は読み取り専用リソースである FimwareSchema
リソースに対して変更を検証します。この設定が無効な場合、BMO は status.Condition
設定の Type
の値を False
に設定し、イベントを生成して HFS リソースに保存します。以下の手順を使用して、リソースが有効であることを確認します。
手順
HostFirmwareSetting
リソースの一覧を取得します。oc get hfs -n openshift-machine-api
$ oc get hfs -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のホストの
HostFirmwareSettings
リソースが有効であることを確認します。oc describe hfs <host_name> -n openshift-machine-api
$ oc describe hfs <host_name> -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<host_name>
はホストの名前です。出力例
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ValidationFailed 2m49s metal3-hostfirmwaresettings-controller Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ValidationFailed 2m49s metal3-hostfirmwaresettings-controller Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要応答が
ValidationFailed
を返す場合、リソース設定にエラーがあり、FirmwareSchema
リソースに準拠するよう値を更新する必要があります。
4.7.13. FirmwareSchema リソースについて リンクのコピーリンクがクリップボードにコピーされました!
BIOS 設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema
リソースは、各ホストモデル上の各 BIOS 設定のタイプおよび制限が含まれる読み取り専用リソースです。データは BMC から Ironic に直接取得されます。FirmwareSchema
を使用すると、HostFirmwareSettings
リソースの spec
フィールドに指定できる有効な値を特定できます。FirmwareSchema
リソースには、その設定および制限から派生する一意の識別子があります。同じホストモデルは同じ FirmwareSchema
識別子を使用します。HostFirmwareSettings
の複数のインスタンスが同じ FirmwareSchema
を使用する可能性が高いです。
パラメーター | 説明 |
---|---|
|
|
4.7.14. FirmwareSchema リソースの取得 リンクのコピーリンクがクリップボードにコピーされました!
各ベンダーの各ホストモデルの BIOS 設定は、それぞれ異なります。HostFirmwareSettings
リソースの spec
セクションを編集する際に、設定する名前/値のペアはそのホストのファームウェアスキーマに準拠している必要があります。有効な名前と値のペアを設定するには、ホストの FirmwareSchema
を取得して確認します。
手順
次のコマンドを実行して、
FirmwareSchema
リソースインスタンスのリストを取得します。oc get firmwareschema -n openshift-machine-api
$ oc get firmwareschema -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、特定の
FirmwareSchema
インスタンスを取得します。oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
$ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<instance_name>
は、HostFirmwareSettings
リソース (表 3 を参照) に記載されているスキーマインスタンスの名前です。
4.7.15. HostFirmwareComponents リソースについて リンクのコピーリンクがクリップボードにコピーされました!
Metal3 は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents
リソースを提供します。HostFirmwareComponents
リソースには 2 つのセクションが含まれています。
-
HostFirmwareComponents
spec -
HostFirmwareComponents
status
4.7.15.1. HostFirmwareComponents spec リンクのコピーリンクがクリップボードにコピーされました!
HostFirmwareComponents
リソースの spec
セクションでは、ホストの BIOS および BMC バージョンの目的の状態を定義します。
パラメーター | 説明 |
---|---|
updates: component: url:
|
|
4.7.15.2. HostFirmwareComponents status リンクのコピーリンクがクリップボードにコピーされました!
HostFirmwareComponents
リソースの status
セクションは、ホストの BIOS および BMC バージョンの現在のステータスを返します。
パラメーター | 説明 |
---|---|
|
|
updates: component: url:
|
|
4.7.16. HostFirmwareComponents リソースの取得 リンクのコピーリンクがクリップボードにコピーされました!
HostFirmwareComponents
リソースには、物理ホストの BIOS およびベースボード管理コントローラー (BMC) の特定のファームウェアバージョンが含まれています。ファームウェアのバージョンとステータスを確認するには、物理ホストの HostFirmwareComponents
リソースを取得する必要があります。
手順
次のコマンドを実行して、
HostFirmwareComponents
リソースの詳細なリストを取得します。oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
$ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
HostFirmwareComponents
リソースのリストを取得します。oc get hostfirmwarecomponents -n openshift-machine-api
$ oc get hostfirmwarecomponents -n openshift-machine-api
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、特定のホストの
HostFirmwareComponents
リソースを取得します。oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml
$ oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<host_name>
はホストの名前です。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.17. プロビジョニング済みホストの HostFirmwareComponents リソースの編集 リンクのコピーリンクがクリップボードにコピーされました!
プロビジョニング済みホストの HostFirmwareComponents
リソースを編集できます。
手順
次のコマンドを実行して、
HostFirmwareComponents
リソースの詳細なリストを取得します。oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
$ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
HostFirmwareComponents
リソースを編集します。oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api
$ oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<hostname>
はホストの名前です。HostFirmwareComponents
リソースが、ターミナルのデフォルトのエディターで開きます。
適切な編集を行います。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存し、エディターを終了します。
次のコマンドを実行して、ホストのマシン名を取得します。
oc get bmh <host_name> -n openshift-machine name
$ oc get bmh <host_name> -n openshift-machine name
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ここで、
<host_name>
はホストの名前です。ターミナルのCONSUMER
フィールドの下にマシン名が表示されます。
次のコマンドを実行して、マシンにアノテーションを付けてマシンセットから削除します。
oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
$ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ここで、
<machine_name>
は削除するマシンの名前です。
次のコマンドを実行して、ノードのリストを取得し、ワーカーノードの数をカウントします。
oc get nodes
$ oc get nodes
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 次のコマンドを実行して、マシンセットをスケールダウンします。
oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<machineset_name>
はマシンセットの名前です。<n-1>
は減少させたワーカーノードの数です。
ホストが
Available
状態になったら、次のコマンドを実行してマシンセットをスケールアップし、HostFirmwareComponents
リソースの変更を反映します。oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<machineset_name>
はマシンセットの名前です。<n>
はワーカーノードの数です。
4.7.18. HostFirmwareComponents リソースへのライブ更新の実行 リンクのコピーリンクがクリップボードにコピーされました!
すでにプロビジョニングされているホスト上の HostFirmwareComponents
リソースに対してライブ更新を実行できます。ライブ更新では、ホストのプロビジョニング解除と再プロビジョニングはトリガーされません。
ホストのライブ更新はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
実稼働ホストではライブ更新を実行しないでください。BIOS のライブ更新はテスト目的で実行できます。特に以前の世代のハードウェアでは、テスト目的で OpenShift Container Platform 4.19 上の BMC にライブ更新を実行することは推奨しません。
前提条件
-
HostUpdatePolicy
リソースのfirmwareUpdates
パラメーターがonReboot
に設定されている。
手順
次のコマンドを実行して、
HostFirmwareComponents
リソースを更新します。oc patch hostfirmwarecomponents <hostname> --type merge -p \ '{"spec": {"updates": [{"component": "<type>", \ "url": "<url>"}]}}'
$ oc patch hostfirmwarecomponents <hostname> --type merge -p \
1 '{"spec": {"updates": [{"component": "<type>", \
2 "url": "<url>"}]}}'
3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api
コマンドを使用してリソースを更新することもできます。次のコマンドを実行して、ノードをスケジューリング対象から外してドレインします。
oc drain <node_name> --force
$ oc drain <node_name> --force
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>
はノード名に置き換えてください。
次のコマンドを実行して、ホストの電源を 5 分間オフにします。
oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このステップにより、デーモンセットまたはコントローラーが、ノード上で実行されている可能性のあるインフラストラクチャー Pod をオフラインとしてマークし、残りのノードが受信リクエストを処理するようになります。
5 分後、次のコマンドを実行してホストの電源をオンにします。
oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービス操作が開始し、Bare Metal Operator (BMO) が
BareMetalHost
のoperationalStatus
パラメーターをservicing
に設定します。BMO は、リソースを更新した後、operationalStatus
パラメーターをOK
に更新します。エラーが発生した場合、BMO はoperationalStatus
パラメーターをerror
に更新し、操作を再試行します。次のコマンドを実行してノードをスケジューリング対象に戻します。
oc uncordon <node_name>
$ oc uncordon <node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.19. HostUpdatePolicy リソースについて リンクのコピーリンクがクリップボードにコピーされました!
HostUpdatePolicy
リソースを使用すると、各ベアメタルホストのファームウェア設定、BMC 設定、またはファームウェア設定へのライブ更新の適用を有効または無効にできます。デフォルトでは、すでにプロビジョニングされたベアメタルホストへのライブ更新は、Operator によって無効にされます。
HostUpdatePolicy
仕様
HostUpdatePolicy
リソースの spec
セクションには、次の 2 つの設定があります。
firmwareSettings
-
この設定は、
HostFirmwareSettings
リソースに対応するものです。 firmwareUpdates
-
この設定は、
HostFirmwareComponents
リソースに対応するものです。
値を onPreparing
に設定すると、ホストを更新できるのがプロビジョニング中だけになります。これがデフォルト設定です。値を onReboot
に設定すると、リソースを適用してベアメタルホストを再起動することで、プロビジョニング済みホストを更新できます。その後、HostFirmwareSettings
または HostFirmwareComponents
リソースを編集する手順に従います。
HostUpdatePolicy
リソースの例
4.7.20. HostUpdatePolicy リソースの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、HostUpdatePolicy
はライブ更新を無効にします。ライブ更新を有効にするには、次の手順に従います。
HostUpdatePolicy
リソースの設定はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
次のコマンドを実行して、
HostUpdatePolicy
リソースを作成します。vim hup.yaml
$ vim hup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 任意のテキストエディターを使用できます。
HostUpdatePolicy リソースの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<hostname>
はホスト名に置き換えます。
-
hup.yaml
ファイルへの変更を保存します。 以下のコマンドを実行してポリシーを適用します。
oc apply -f hup.yaml
$ oc apply -f hup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第5章 クラスターの拡張 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスターをデプロイした後、次の手順に従ってワーカーノードの数を増やすことができます。それぞれの候補となるワーカーノードが前提条件を満たしていることを確認します。
RedFish Virtual Media を使用してクラスターを拡張するには、最低限のファームウェア要件を満たす必要があります。RedFish Virtual Media を使用したクラスターの拡張時の詳細は、前提条件 セクションの 仮想メディアを使用したインストールのファームウェア要件 を参照してください。
5.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
アノテーションを使用します。
5.2. ベアメタルコントロールプレーンノードの交換 リンクのコピーリンクがクリップボードにコピーされました!
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.19 True False False 3d15h
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE baremetal 4.19 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 <num>
は、annotations
、labels
、name
フィールドのベアメタルノードのコントロールプレーン番号に置き換えます。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 メンバーの置き換え」を参照してください。
5.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
5.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
5.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
第6章 Bare Metal as a Service の使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の Bare Metal as a Service (BMaaS) 機能を使用すると、Metal 3 API と Bare Metal Operator (BMO) を使用して、ベアメタルホストをプロビジョニングおよび管理できます。OpenShift Container Platform クラスターの外部にあるこれらのホストは、コンテナー化や仮想化に適さない可能性のあるワークロードを実行する可能性があります。たとえば、ハードウェアへの直接アクセスを必要とするアプリケーション、高性能コンピューティングタスクを実行するアプリケーション、レガシーアプリケーションなどのワークロードです。BMaaS には以下の機能が含まれます。
- 初期設定を含むベアメタルホストのプロビジョニング。
- BMO を使用した電源管理、ファームウェアの更新、廃止などのライフサイクル管理。
これらのホストはスタンドアロンシステムとして、OpenShift Container Platform クラスターから独立して動作し、ベアメタルリソースをコンテナー化および仮想化されたアプリケーションと統合することで、さまざまなワークロードをサポートします。BMaaS は他のオペレーティングシステムも実行できますが、テストされたのは Red Hat Enterprise Linux (RHEL) と CentOS Stream 9 のみです。
BMaaS はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
6.1. BMaaS を使用するための前提条件 リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal as a Service (BMaaS) テクノロジープレビューを使用するには、次の前提条件を満たしてください。
- BareMetalHost の設定
-
すべてのベアメタルホストは、Redfish プロトコルと仮想メディア (
redfish-virtualmedia
) ドライバーで設定されたベースボード管理コントローラー (BMC) を使用する必要があります。各ベアメタルホストには、IP アドレスリースを受信するように設定された MAC アドレスを持つブートインターフェイスが必要です。 - ネットワーク要件
- OpenShift Container Platform および Metal 3 インフラストラクチャーとは別の DHCP サーバーが、ベアメタルホストと同じレイヤー 2 ネットワーク上で動作している必要があります。DHCP サーバーは、ベアメタルホスト上のブートインターフェイスの MAC アドレスと一致するように設定する必要があります。これにより、Metal 3 コンポーネントとの通信に IP アドレスが割り当てられます。
- クラスター特権
-
BMaaS 設定タスクを実行するには、OpenShift Container Platform クラスター上に
cluster-admin
特権が必要です。 - イメージ付き Web サーバー
BMaaS は、ハードウェアにデプロイメントするためのイメージを提供しません。使用するイメージとチェックサムを使用して Web サーバーを設定する必要があります。
BareMetalHost
仕様のimage
フィールドは、デプロイメント中にこれらのイメージを参照します。ベアメタルホストが Web サーバー URL にアクセスできることを確認します。以下は、含める可能性のあるイメージとチェックサムの例です。
これらの前提条件により、BMaaS はベアメタルホストを効果的にプロビジョニングおよび管理できるようになります。
6.2. Bare Metal Operator を使用して、すべての namespace にわたるリソースを管理する リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal Operator (BMO) が OpenShift Container Platform クラスター内のすべての namespace にわたって BareMetalHost
リソースを管理するには、すべての namespace を監視するように Operator を設定する必要があります。この設定は、OpenShift Container Platform 以外のワークロードが同じ namespace 内の他のコンポーネントと混在することを避けるために重要です。
前提条件
- user-provisioned installation を使用しており、Provisioning CR が存在しない場合は、手動で作成する必要があります。手順は、ユーザーがプロビジョニングしたクラスターをスケーリングするためのプロビジョニングリソースの設定 を参照してください。installer-provisioned installation の場合、インストールプログラムによって Provisioning カスタムリソース (CR) が自動的に作成されます。
手順
次のコマンドを実行して、プロビジョニング設定にパッチを適用し、すべての namespace の監視を有効にします。
oc patch provisioning/provisioning-configuration \ --type merge -p '{"spec": {"watchAllNamespaces": true}}'
$ oc patch provisioning/provisioning-configuration \ --type merge -p '{"spec": {"watchAllNamespaces": true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BMO はこの変更を自動的に適用します。
6.3. 専用の namespace の設定 リンクのコピーリンクがクリップボードにコピーされました!
Bare Metal as a Service (BMaaS) ワークロードと OpenShift Container Platform インフラストラクチャー間の偶発的な干渉を防ぐには、専用の namespace をセットアップします。すべての BMaaS プロジェクトに対してこの手順を繰り返します。
前提条件
- ID プロバイダーを設定 している。
手順
アイデンティティープロバイダーで BMaaS
bmadmin
ユーザーを設定し、OpenShift にシークレットを作成します。アイデンティティープロバイダーに
bmadmin
ユーザーを作成します。たとえば、htpasswd
アイデンティティープロバイダーを使用する場合は、次のコマンドを実行します。htpasswd -c -B -b ./users_htpasswd <username> <password>
$ htpasswd -c -B -b ./users_htpasswd <username> <password>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <username>
-
アイデンティティープロバイダーのユーザー名。
<username>
は、希望のユーザー名に置き換えます。この例ではbmadmin
を使用します。 - <password>
-
ユーザーのパスワード。
<password>
は、安全なパスワードに置き換えます。
次のコマンドを実行して、アイデンティティープロバイダー設定を保存するためのシークレットを
openshift-config
namespace に作成します。oc create secret generic <identity_provider_arguments> -n openshift-config
$ oc create secret generic <identity_provider_arguments> -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
htpasswd
アイデンティティープロバイダーを使用する場合は、次のコマンドを実行します。oc create secret generic htpass-secret --from-file=htpasswd=users_htpasswd -n openshift-config
$ oc create secret generic htpass-secret --from-file=htpasswd=users_htpasswd -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <identity_provider_arguments>
-
アイデンティティープロバイダーシークレットに固有の引数。
<identity_provider_arguments>
は、ID プロバイダーの適切な引数に置き換えます。
アイデンティティープロバイダーを使用するように OAuth を設定します。
次のコマンドを実行して OAuth リソースを編集します。
oc edit oauth cluster
$ oc edit oauth cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エディターが開き、Oauth リソースが表示されます。
アイデンティティープロバイダーの設定を
spec.identityProviders
リストに追加します。Expand 表6.1 アイデンティティープロバイダーの設定例 型 例 htpasswd
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LDAP
Copy to Clipboard Copied! Toggle word wrap Toggle overflow GitHub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アイデンティティープロバイダーの詳細は、認証と認可 を参照してください。
- エディターを保存し、終了します。
次のコマンドを実行して、BMaaS
bmadmin
ユーザーを作成します。oc create user <username>
$ oc create user <username>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <username>
-
ユーザー名。
<username>
は、ユーザー名に置き換えます。次の例では、ユーザー名としてbmadmin
を使用します。
次のコマンドを実行して、BMaaS ホスト専用の
bmaas
namespace を作成します。oc new-project <namespace>
$ oc new-project <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <namespace>
-
<namespace> は、使用する namespace 名に置き換えます。この例では
bmaas
を使用します。
次のコマンドを実行して、
bmaas
namespace の BMaaSbmadmin
ユーザーにedit
ロールを割り当てます。oc adm policy add-role-to-user edit <username> -n bmaas
$ oc adm policy add-role-to-user edit <username> -n bmaas
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
baremetal-operator
リポジトリーをクローンし、ロールベースアクセス制御 (RBAC) のロール定義を取得します。git clone -b release-4.19 https://github.com/openshift/baremetal-operator.git
$ git clone -b release-4.19 https://github.com/openshift/baremetal-operator.git
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加するロールごとに、次のコマンドを実行して、リポジトリーから適切な RBAC ロール YAML ファイルを適用します。
oc apply -f baremetal-operator/config/base/rbac/<role_filename>.yaml
$ oc apply -f baremetal-operator/config/base/rbac/<role_filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
bmaas
namespace 内の BMaaSbmadmin
ユーザーにカスタム RBAC ロールを割り当てます。oc adm policy add-role-to-user <role_name> bmadmin -n bmaas
$ oc adm policy add-role-to-user <role_name> bmadmin -n bmaas
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
bmadmin
ユーザーとしてログインします。oc login <api_server_url>:6443
$ oc login <api_server_url>:6443
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <api_server_url>
- Kubernetes API への URL。
6.4. BMC シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルホストをデプロイするには、ベースボード管理コントローラー (BMC) にアクセスするためのシークレットを作成する必要があります。
手順
次のコマンドを実行して BMC シークレットファイルを作成します。
vim bmaas-<name>-bmc-secret.yaml
$ vim bmaas-<name>-bmc-secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <name>
は、ベアメタルホストの名前に置き換えます。シークレットを編集します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <base64_of_uid>
-
<base64_of_uid>
は、Base64 でエンコードされた文字列の BMC ユーザー名に置き換えます。 - <base64_of_pwd>
-
<base64_of_pwd>
は、Base64 でエンコードされた文字列の BMC パスワードに置き換えます。
次のコマンドを実行して BMC シークレットを適用します。
oc apply -f bmaas-<name>-bmc-secret.yaml
$ oc apply -f bmaas-<name>-bmc-secret.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5. ベアメタルホストリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルホストをデプロイするには、BareMetalHost
リソースを作成する必要があります。
手順
次のコマンドを実行して、
BareMetalHost
カスタムリソース (CR) ファイルを作成します。vim bmaas-<name>-bmh.yaml
$ vim bmaas-<name>-bmh.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <name>
-
<name>
は、ベアメタルホストの名前に置き換えます。
CR を編集します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <mac_addr>
-
<mac_addr>
は、ベアメタルホスト上の最初の NIC の MAC アドレスに置き換えます。 - <address>
-
<address>
は、ホストの IP アドレスまたは FQDN に置き換えます。
以下のコマンドを実行して CR を適用します。
oc apply -f bmaas-<name>-bmh.yaml
$ oc apply -f bmaas-<name>-bmh.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、
BareMetalHost
の状態を確認します。oc get baremetalhost -n bmaas
$ oc get baremetalhost -n bmaas
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 状態は、registering、inspecting、そして最終的に available へと進みます。
6.6. BMaaS ホストのユーザーの設定 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルホストユーザーを設定し、Kubernetes シークレットに追加します。次に、シークレットを作成して適用し、ホストをカスタマイズします。
手順
次の内容を含む
<hostname>-user-data.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>
- ベアメタルホストの名前。
<name>
- ユーザー名。
<sudo_config>
- ユーザーの sudo 設定。
<key_type>
- SSH キーの種類。
<key>
-
<name>
ユーザーとしてこのホストにアクセスするときに使用する公開 SSH キー。 <shell_path>
- ホストにアクセスするときに使用するシェル。
<groups>
- ユーザーが所属するグループ。
lock_passwd
ユーザーパスワードがロックされているかどうか。
true
の場合、ユーザーはパスワードを使用してログインすることはできませんが、SSH は引き続き使用できます。ユーザーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、
<hostname>-user-data.yaml
ファイルからシークレットを作成します。oc create secret generic <hostname>-user-data \ --from-file=userData=<hostname>-user-data.yaml -n bmaas
$ oc create secret generic <hostname>-user-data \ --from-file=userData=<hostname>-user-data.yaml -n bmaas
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>
- ベアメタルホストの名前。
次のコマンドを実行して、
BareMetalHost
が<hostname>-user-data.yaml
ファイルを使用するように設定します。oc patch baremetalhost <hostname> -n bmaas \ --type merge -p '{"spec":{"userData":{"name":"<hostname>-user-data"}}}'
$ oc patch baremetalhost <hostname> -n bmaas \ --type merge -p '{"spec":{"userData":{"name":"<hostname>-user-data"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>
- ベアメタルホストの名前。
6.7. BareMetalHost リソースの networkData パラメーターの設定 リンクのコピーリンクがクリップボードにコピーされました!
BareMetalHost
カスタムリソース (CR) の networkData
フィールドを使用すると、作成時にベアメタルホストのネットワーク設定を制御できます。ほとんどのオペレーティングシステムでは、これは Kubernetes シークレットにカプセル化された設定ファイルを使用して実現されます。次に、cloud-init
サービスはそれを使用してサービスをカスタマイズします。
手順
次の内容を含む
network-data.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <interface_id>
-
ネットワークインターフェイスの ID (例:
enp2s0
)。 <mac_address>
- ネットワークインターフェイスの MAC アドレス。
<dns_server>
- DNS サーバーの IP アドレス。
次のコマンドを実行して、
networkData
ファイルからシークレットを作成します。oc create secret generic <hostname>-network-data \ --from-file=networkData=network-data.yaml -n bmaas
$ oc create secret generic <hostname>-network-data \ --from-file=networkData=network-data.yaml -n bmaas
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>
- ベアメタルホストのホスト名。
次のコマンドを実行して、
BareMetalHost
がnetworkData
ファイルを使用するように設定します。oc patch baremetalhost <hostname> -n bmaas \ --type merge -p '{"spec":{"networkData":{"name":"<hostname>-network-data"}}}'
$ oc patch baremetalhost <hostname> -n bmaas \ --type merge -p '{"spec":{"networkData":{"name":"<hostname>-network-data"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8. ベアメタルホストへのイメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
イメージをホストにデプロイするには、BareMetalHost
リソースの spec
セクションにある image
フィールドを更新します。image
フィールドを更新すると、プロビジョニングがすぐに開始されます。
手順
次のコマンドを実行して、
BareMetalHost
CR のimage
フィールドを更新します。oc patch baremetalhost <hostname> \ --type merge -p '{"spec": {"image": {"url": "<image_url>", "checksum": "<checksum_url>", "checksumType": "auto"}}}'
$ oc patch baremetalhost <hostname> \ --type merge -p '{"spec": {"image": {"url": "<image_url>", "checksum": "<checksum_url>", "checksumType": "auto"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>
-
BareMetalHost
リソースの名前。 <image_url>
- デプロイするイメージの URL。
<checksum_url>
- イメージのチェックサムファイルの URL。
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.