Red Hat Summit第3章 user-provisioned infrastructure
3.1. user-provisioned infrastructure の vSphere インストール要件
プロビジョニングしたインフラストラクチャーへのインストールを開始する前に、vSphere 環境が次のインストール要件を満たしていることを確認してください。
3.1.1. VMware vSphere インフラストラクチャーの要件
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
これらのリリースは、どちらも Container Storage Interface (CSI) の移行をサポートしています。CSI の移行は、OpenShift Container Platform 4.19 ではデフォルトで有効になっています。
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
| 仮想環境製品 | 必須バージョン |
|---|---|
| VMware 仮想ハードウェア | 15 以降 |
| vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
| vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
| コンポーネント | サポートされる最小バージョン | 説明 |
|---|---|---|
| ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat カスタマーポータルの ハードウェア を参照してください。 |
| オプション: Networking(NSX-T) | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 | NSX および OpenShift Container Platform の互換性の詳細は、VMware の NSX コンテナープラグインドキュメント のリリースノートセクションを参照してください。 |
| CPU マイクロアーキテクチャー | x86-64-v2 以降 | OpenShift Container Platform version 4.13 以降では、RHEL 9.2 ホストオペレーティングシステムをベースとしており、マイクロアーキテクチャーの要件が x86-64-v2 に引き上げられました。RHEL ドキュメントの アーキテクチャー を参照してください。 |
Oracle® Cloud Infrastructure (OCI) および Oracle® Cloud VMware Solution (OCVS) サービス上で動作するクラスターワークロードの最適なパフォーマンス条件を確保するには、ブロックボリュームのボリュームパフォーマンスユニット (VPU) がワークロードに合わせてサイズ設定されていることを確認してください。
次のリストを参考に、特定のパフォーマンスニーズに応じて必要な VPU を選択してください。
- テストまたは概念実証環境: 100 GB、20 - 30 VPU。
- 基本実稼働環境: 500 GB、60 VPU。
- 頻繁に使用される実稼働環境: 500 GB 以上、100 以上の VPU。
更新とスケーリングアクティビティーに十分な容量を提供するために、追加の VPU を割り当てることを検討してください。Block Volume Performance Levels (Oracle ドキュメント) を参照してください。
3.1.2. VMware vSphere CSI Driver Operator の要件
vSphere Container Storage Interface (CSI) Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere でデプロイされたクラスターでのみサポートされます。
Container Storage Interface (CSI) ドライバー、vSphere CSI Driver Operator、および vSphere Problem Detector Operator のカスタムロールを作成できます。カスタムロールには、各 vSphere オブジェクトに最小限の権限セットを割り当てる特権セットを含めることができます。つまり、CSI ドライバー、vSphere CSI Driver Operator、および vSphere Problem Detector Operator はこれらのオブジェクトとの基本的な対話を確立できます。
vCenter への OpenShift Container Platform クラスターのインストールは、「必要な vCenter アカウントの特権」セクションで説明されているすべての特権のリストに対してテストされています。このすべての特権のリストに準拠することで、制限された特権セットを持つカスタムロールの作成時に予期しない動作やサポートされていない動作が発生する可能性を抑制できます。
3.1.3. user-provisioned infrastructure を使用したクラスターの要件
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
3.1.3.1. vCenter の要件
指定のインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの特権
OpenShift Container Platform クラスターを vCenter にインストールするには、必要なリソースの読み取りと作成のための特権が vSphere アカウントに含まれている必要があります。グローバル管理者特権を持つアカウントを使用するのが、必要なすべての権限にアクセスする最も簡単な方法です。
例3.1 vSphere API でのインストールに必要なロールと特権
| ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な特権 |
|---|---|---|
| vSphere vCenter | 常時 |
|
| vSphere vCenter Cluster | クラスタールートに仮想マシンを作成する必要がある場合 |
|
| vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
| vSphere Datastore | 常時 |
|
| vSphere ポートグループ | 常時 |
|
| 仮想マシンフォルダー | 常時 |
|
| vSphere vCenter data center |
クラスターが Machine API を使用しない場合、 |
|
例3.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと特権
| ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な特権 |
|---|---|---|
| vSphere vCenter | 常時 |
|
| vSphere vCenter Cluster | クラスタールートに仮想マシンを作成する場合 |
|
| vSphere vCenter リソースプール | 既存のリソースプールを提供する場合 |
|
| vSphere Datastore | 常時 |
|
| vSphere ポートグループ | 常時 |
|
| 仮想マシンフォルダー | 常時 |
|
| vSphere vCenter data center |
クラスターが Machine API を使用しない場合、 |
|
また、ユーザーには一部の ReadOnly パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例3.3 必要な権限と伝播設定
| vSphere オブジェクト | 必要になる場合 | 子への伝播 | 必要な権限 |
|---|---|---|---|
| vSphere vCenter | 常時 | False | 上記の必要な特権 |
| vSphere vCenter data center | 既存のフォルダー | False |
|
| vSphere vCenter Cluster | 既存のリソースプール | False |
|
| クラスタールートの仮想マシン | True | 必要な特権がリスト表示 | |
| vSphere vCenter Datastore | 常時 | False | 上記の必要な特権 |
| vSphere Switch | 常時 | False |
|
| vSphere ポートグループ | 常時 | False | 上記の必要な特権 |
| vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | 上記の必要な特権 |
| vSphere vCenter リソースプール | 既存のリソースプール | True | 上記の必要な特権 |
必要な特権のみを持つアカウントを作成する方法の詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
最低限必要な vCenter アカウントの特権
カスタムロールを作成し、そのロールに特権を割り当てたら、特定の vSphere オブジェクトを選択して権限を作成できます。その後、各オブジェクトのユーザーまたはグループにカスタムロールを割り当てることができます。
vSphere オブジェクトの権限を作成する前、または権限の作成を要求する前に、vSphere オブジェクトに適用する最小限の権限を決定してください。このタスクを実行すると、vSphere オブジェクトと OpenShift Container Platform アーキテクチャーの間の基本的な対話を確立できます。
カスタムロールを作成し、そのロールに特権を割り当てなかった場合、vSphere Server はデフォルトで Read Only ロールをそのカスタムロールに割り当てます。クラウドプロバイダー API の場合、カスタムロールは Read Only ロールの特権を継承するだけで済むことに注意してください。
グローバル管理者の特権を持つアカウントがニーズに合わない場合は、カスタムロールの作成を検討してください。
Red Hat は、必要な特権を含めずにアカウントを設定することをサポートしていません。vCenter への OpenShift Container Platform クラスターのインストールは、「必要な vCenter アカウントの特権」セクションで説明されているすべての特権のリストに対してテストされています。このすべての特権のリストに準拠することで、制限された特権セットを持つカスタムロールの作成時に予期しない動作が発生する可能性を抑制できます。
以下の表は、このドキュメントで前述した必須の vCenter アカウント特権が、OpenShift Container Platform アーキテクチャーのさまざまな側面にどのように関連しているかを示しています。
例3.4 インストール後のコンポーネント管理に必要な最小権限
| ロールの vSphere オブジェクト | 必要になる場合 | 必要な特権 |
|---|---|---|
| vSphere vCenter | 常時 |
|
| vSphere vCenter Cluster | クラスタールートに仮想マシンを作成する場合 |
|
| vSphere vCenter リソースプール |
|
|
| vSphere Datastore | 常時 |
|
| vSphere ポートグループ | 常時 |
|
| 仮想マシンフォルダー | 常時 |
|
| vSphere vCenter data center |
クラスターが Machine API を使用しない場合、 |
|
例3.5 ストレージコンポーネントの最小権限
| ロールの vSphere オブジェクト | 必要になる場合 | 必要な特権 |
|---|---|---|
| vSphere vCenter | 常時 |
|
| vSphere vCenter Cluster | クラスタールートに仮想マシンを作成する場合 |
|
| vSphere vCenter リソースプール |
|
|
| vSphere Datastore | 常時 |
|
| vSphere ポートグループ | 常時 |
|
| 仮想マシンフォルダー | 常時 |
|
| vSphere vCenter data center |
クラスターが Machine API を使用しない場合、 |
|
例3.6 Machine API の最小権限
| ロールの vSphere オブジェクト | 必要になる場合 | 必要な特権 |
|---|---|---|
| vSphere vCenter | 常時 |
|
| vSphere vCenter Cluster | クラスタールートに仮想マシンを作成する場合 |
|
| vSphere vCenter リソースプール |
|
|
| vSphere Datastore | 常時 |
|
| vSphere ポートグループ | 常時 |
|
| 仮想マシンフォルダー | 常時 |
|
| vSphere vCenter data center |
クラスターが Machine API を使用しない場合、 |
|
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。
VMware コンピュート vMotion を使用して OpenShift Container Platform コンピュートマシンとコントロールプレーンマシンの両方のワークロードを移行することは通常サポートされていますが、これは 通常、vMotion に関するすべての VMware ベストプラクティスを満たしていることを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Pod で VMware vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
OpenShift Container Platform は、データストア間での仮想マシンディスク (VMDK) の選択的な移行、仮想マシンのプロビジョニングまたは PV の動的または静的プロビジョニングにデータストアクラスターを使用すること、PV の動的または静的プロビジョニングにデータストアクラスターの一部であるデータストアを使用することをサポートしていません。
重要データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion を使用する Storage Distributed Resource Scheduler (SDRS) がデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていません。そのため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、SDRS を無効にする必要があります。
多数のデータストアにわたって仮想マシンを指定する必要がある場合は、クラスターの
install-config.yaml設定ファイルで、datastoreオブジェクトを使用して障害ドメインを指定してください。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。
クラスターリソース
提供したインフラストラクチャーを使用する OpenShift Container Platform クラスターをデプロイする場合は、vCenter インスタンスに以下のリソースを作成する必要があります。
- 1 フォルダー
- 1 タグカテゴリー
- 1 タグ
仮想マシン:
- 1 テンプレート
- 1 一時的ブートストラップノード
- 3 コントロールプレーンノード
- 3 コンピュートマシン
これらのリソースは 856 GB のストレージを使用しますが、ブートストラップノードはクラスターのインストールプロセス中に削除されます。標準的なクラスターでは、最低でも 800 GB のストレージが必要です。
追加のコンピュートマシンをデプロイする場合、OpenShift Container Platform クラスターは追加のストレージを使用します。
クラスターの制限
利用可能なリソースはクラスターによって異なります。vCenter 内に作成可能なクラスターの数には上限があります。その主な要因は、使用可能なストレージ容量と、必要なリソース数に関する制限です。クラスターが作成する vCenter リソースと、IP アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
user-provisioned infrastructure にインストールするクラスターに対して、別々の VLAN 上のノードまたはノードのグループを指定する場合、クラスター内のマシンが、user-provisioned infrastructure のネットワーク要件 ドキュメントの「ネットワーク接続の要件」セクションに記載されている要件を満たしていることを確認する必要があります。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作成する必要があります。
DNS レコード
OpenShift Container Platform クラスターをホストする vCenter インスタンスに 2 つの静的 IP アドレスの DNS レコードを適切な DNS サーバーに作成する必要があります。各レコードで、<cluster_name> はクラスター名で、<base_domain> は、クラスターのインストール時に指定するクラスターのベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。
| コンポーネント | レコード | 説明 |
|---|---|---|
| API VIP |
| この DNS A/AAAA または CNAME (Canonical Name) レコードは、コントロールプレーンマシンのロードバランサーを参照する必要があります。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| Ingress VIP |
| Ingress ルーター Pod を実行するマシンをターゲットにするロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
3.1.3.2. クラスターのインストールに必要なマシン
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
| ホスト | 説明 |
|---|---|
| 1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
| 3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
| 少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、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 テクノロジーの機能と制限 を参照してください。
3.1.3.3. クラスターインストールの最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | 仮想 CPU | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [1] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [2] | 2 | 8 GB | 100 GB | 300 |
- 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 で使用することがサポートされます。
OpenShift Container Platform クラスターではメモリーバルーニングを使用しないでください。メモリーバルーニングを使用すると、クラスター全体の不安定性、サービスの低下、またはその他の未定義動作が発生する可能性があります。
- コントロールプレーンマシンには、公開されているクラスターインストールの最小リソース要件以上のコミット済みメモリーが必要です。
- コンピュートマシンには、公開されているクラスターインストールの最小リソース要件以上の最小予約量が必要です。
これらの最小 CPU およびメモリー要件には、ユーザーのワークロードに必要なリソースは考慮されていません。
詳細は、Red Hat ナレッジベースの記事 Memory Ballooning and OpenShift を参照してください。
3.1.3.4. 仮想マシンを暗号化するための要件
以下の要件を満たすと、OpenShift Container Platform 4.19 をインストールする前に、仮想マシンを暗号化できます。
vSphere で標準キープロバイダーを設定した。詳細は、vCenter Server への KMS の追加 を参照してください。
重要vCenter のネイティブキープロバイダーはサポートされていません。詳細は、vSphere Native Key Provider の概要 を参照してください。
- クラスターをホストしているすべての ESXi ホストでホスト暗号化モードが有効になっている。詳細は、ホスト暗号化モードの有効化 を参照してください。
- すべての暗号化特権が有効になっている vSphere アカウントがある。詳細は、Cryptographic Operations Privileges を参照してください。
「RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始」セクションで OVF テンプレートをデプロイする場合は、OVF テンプレートのストレージを選択する際、"Encrypt this virtual machine" オプションを選択します。クラスターのインストールが完了したら、仮想マシンの暗号化に使用した暗号化ストレージポリシーを使用するストレージクラスを作成します。
3.1.3.5. 証明書署名要求の管理
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求されるサービング証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
3.1.3.6. 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 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
3.1.3.6.1. DHCP を使用したクラスターノードのホスト名の設定
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
3.1.3.6.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 サーバーおよびピアポート |
user-provisioned infrastructure の NTP 設定
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
3.1.3.7. 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 解決の検証 のセクションを参照してください。
3.1.3.7.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 レコードの例を示しています。
例3.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 レコードの例を示しています。
例3.8 逆引きレコードの DNS ゾーンデータベースの例
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
3.1.3.8. 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 表3.10 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 表3.11 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
3.1.3.8.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 ポートにバインドできることを確認する必要があります。
例3.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 プロセスがリッスンしていることを確認することができます。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}