vSphere へのインストール


OpenShift Container Platform 4.16

vSphere への OpenShift Container Platform のインストール

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、vSphere に OpenShift Container Platform をインストールする方法を説明します。

第1章 インストール方法

さまざまなインストール方法を使用して、OpenShift Container Platform クラスターを vSphere にインストールできます。それぞれの方法は、その特質上、適しているユースケース (非接続環境にクラスターをインストールする場合や、最小限の設定とプロビジョニングでクラスターをインストールする場合など) が異なります。

1.1. Assisted Installer

Assisted Installer を使用して、OpenShift Container Platform をインストールできます。この方法はインストーラーのセットアップが不要で、vSphere などの接続環境に最適です。Assisted Installer を使用してインストールすると、vSphere との統合も提供され、自動スケーリングが可能になります。詳細は、自動インストーラーを使用したオンプレミスクラスターのインストール を参照してください。

1.2. Agent-based Installer

Agent-based Installer を使用して、OpenShift Container Platform クラスターを vSphere にインストールできます。Agent-based Installer を使用すると、起動可能なイメージを使用して、非接続環境でオンプレミスサーバーを起動できます。Agent-based Installer を使用すると、ユーザーはインフラストラクチャーのプロビジョニング、ネットワーク設定のカスタマイズ、非接続環境内でのインストールのカスタマイズを柔軟に行うことができます。詳細は、Agent-based Installer を使用したインストールの準備 を参照してください。

1.3. installer-provisioned infrastructure によるインストール

installer-provisioned infrastructure を使用して、OpenShift Container Platform を vSphere にインストールできます。installer-provisioned infrastructure により、インストールプログラムは OpenShift Container Platform で必要なリソースのプロビジョニングを事前に設定し、自動化することができます。installer-provisioned infrastructure は、ネットワーク非接続環境にインストールする場合に役立ちます。このような環境では、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。

1.4. user-provisioned infrastructure によるインストール

user-provisioned infrastructure を使用して、OpenShift Container Platform を vSphere にインストールできます。user-provisioned infrastructure では、ユーザーは OpenShift Container Platform に必要なすべてのリソースをプロビジョニングする必要があります。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、vSphere プラットフォームおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。user-provisioned infrastructure のインストール手順をガイドとして使用します。他の方法で必要なリソースを作成することもできます。

1.5. 関連情報

第2章 installer-provisioned infrastructure

2.1. vSphere のインストール要件

installer-provisioned infrastructure を使用してインストールを開始する前に、vSphere 環境が次のインストール要件を満たしていることを確認してください。

2.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.16 ではデフォルトで有効になっています。

VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。

表2.1 vSphere 仮想環境のバージョン要件
仮想環境製品必須バージョン

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

表2.2 VMware コンポーネントのサポートされる vSphere の最小バージョン
コンポーネントサポートされる最小バージョン説明

ハイパーバイザー

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 Customer Portal の ハードウェア を参照してください。

オプション: 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 4.13 以降では、マイクロアーキテクチャーの要件が x86-64-v2 に発生する RHEL 9.2 ホストオペレーティングシステムをベースにしています。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 ドキュメント) を参照してください。

2.1.2. ネットワーク接続の要件

OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。

必要なネットワークポートに関する次の詳細を確認してください。

表2.3 すべてのマシンからすべてのマシンへの通信に使用されるポート
プロトコルポート説明

VRRP

該当なし

keepalived に必要

ICMP

該当なし

ネットワーク到達性のテスト

TCP

1936

メトリック

9000-9999

ホストレベルのサービス。 ポート 9100-9101 のノードエクスポーター、ポート 9099 の Cluster Version Operator が含まれます。

10250-10259

Kubernetes が予約するデフォルトポート

10256

openshift-sdn

UDP

4789

仮想拡張可能 LAN (VXLAN)

6081

Geneve

9000-9999

ポート 9100-9101 のノードエクスポーターを含む、ホストレベルのサービス。

500

IPsec IKE パケット

4500

IPsec NAT-T パケット

TCP/UDP

30000-32767

Kubernetes ノードポート

ESP

該当なし

IPsec Encapsulating Security Payload (ESP)

表2.4 すべてのマシンからコントロールプレーンへの通信に使用されるポート
プロトコルポート説明

TCP

6443

Kubernetes API

表2.5 コントロールプレーンマシンからコントロールプレーンマシンへの通信に使用されるポート
プロトコルポート説明

TCP

2379-2380

etcd サーバーおよびピアポート

2.1.3. 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 アカウントの特権」セクションで説明されているすべての特権のリストに対してテストされています。このすべての特権のリストに準拠することで、制限された特権セットを持つカスタムロールの作成時に予期しない動作やサポートされていない動作が発生する可能性を抑制できます。

関連情報

2.1.4. vCenter の要件

インストーラーでプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。

必要な vCenter アカウントの権限

OpenShift Container Platform クラスターを vCenter にインストールするには、インストールプログラムには、必要なリソースの読み取りおよび作成権限を持つアカウントへのアクセスが必要になります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。

グローバル管理者権限を持つアカウントを使用できない場合、OpenShift Container Platform クラスターのインストールに必要な権限を付与するためのロールを作成する必要があります。ほとんどの特権は常に必要になりますが、デフォルト動作であるインストールプログラムでの vCenter インスタンスへの OpenShift Container Platform クラスターが含まれるフォルダーのプロビジョニングを実行する場合にのみ必要となる特権もあります。必要な特権を付与するには、指定されたオブジェクトに vSphere ロールを作成するか、これを修正する必要があります。

インストールプログラムが vSphere 仮想マシンフォルダーを作成するために使用される場合には、追加のロールが必要です。

例2.1 vSphere API でのインストールに必要なロールと権限

ロールの vSphere オブジェクト必要になる場合vSphere API で必要な権限

vSphere vCenter

常時

Cns.Searchable
InventoryService.Tagging.AttachTag
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.DeleteCategory
InventoryService.Tagging.DeleteTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
Sessions.ValidateSession
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

仮想マシンがクラスタールートに作成される場合

Host.Config.Storage
Resource.AssignVMToPool
VApp.AssignResourcePool
VApp.Import
VirtualMachine.Config.AddNewDisk

vSphere vCenter リソースプール

既存のリソースプールが提供されている場合

Resource.AssignVMToPool
VApp.AssignResourcePool
VApp.Import
VirtualMachine.Config.AddNewDisk

vSphere データストア

常時

Datastore.AllocateSpace
Datastore.Browse
Datastore.FileManagement
InventoryService.Tagging.ObjectAttachable

vSphere ポートグループ

常時

Network.Assign

仮想マシンフォルダー

常時

InventoryService.Tagging.ObjectAttachable
Resource.AssignVMToPool
VApp.Import
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddNewDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.DiskLease
VirtualMachine.Config.EditDevice
VirtualMachine.Config.Memory
VirtualMachine.Config.RemoveDisk
VirtualMachine.Config.Rename
Host.Config.Storage
VirtualMachine.Config.ResetGuestInfo
VirtualMachine.Config.Resource
VirtualMachine.Config.Settings
VirtualMachine.Config.UpgradeVirtualHardware
VirtualMachine.Interact.GuestControl
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Inventory.Create
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.MarkAsTemplate
VirtualMachine.Provisioning.DeployTemplate

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。「Machine API の最小権限」の表を参照してください。

InventoryService.Tagging.ObjectAttachable
Resource.AssignVMToPool
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddNewDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.DiskLease
VirtualMachine.Config.EditDevice
VirtualMachine.Config.Memory
VirtualMachine.Config.RemoveDisk
VirtualMachine.Config.Rename
VirtualMachine.Config.ResetGuestInfo
VirtualMachine.Config.Resource
VirtualMachine.Config.Settings
VirtualMachine.Config.UpgradeVirtualHardware
VirtualMachine.Interact.GuestControl
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Inventory.Create
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.DeployTemplate
VirtualMachine.Provisioning.MarkAsTemplate
Folder.Create
Folder.Delete

例2.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限

ロールの vSphere オブジェクト必要になる場合vCenter GUI で必要な権限

vSphere vCenter

常時

Cns.Searchable
"vSphere Tagging"."Assign or Unassign vSphere Tag"
"vSphere Tagging"."Create vSphere Tag Category"
"vSphere Tagging"."Create vSphere Tag"
vSphere Tagging"."Delete vSphere Tag Category"
"vSphere Tagging"."Delete vSphere Tag"
"vSphere Tagging"."Edit vSphere Tag Category"
"vSphere Tagging"."Edit vSphere Tag"
Sessions."Validate session"
"Profile-driven storage"."Profile-driven storage update"
"Profile-driven storage"."Profile-driven storage view"

vSphere vCenter Cluster

仮想マシンがクラスタールートに作成される場合

Host.Configuration."Storage partition configuration"
Resource."Assign virtual machine to resource pool"
VApp."Assign resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add new disk"

vSphere vCenter リソースプール

既存のリソースプールが提供されている場合

Host.Configuration."Storage partition configuration"
Resource."Assign virtual machine to resource pool"
VApp."Assign resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add new disk"

vSphere データストア

常時

Datastore."Allocate space"
Datastore."Browse datastore"
Datastore."Low level file operations"
"vSphere Tagging"."Assign or Unassign vSphere Tag on Object"

vSphere ポートグループ

常時

Network."Assign network"

仮想マシンフォルダー

常時

"vSphere Tagging"."Assign or Unassign vSphere Tag on Object"
Resource."Assign virtual machine to resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add existing disk"
"Virtual machine"."Change Configuration"."Add new disk"
"Virtual machine"."Change Configuration"."Add or remove device"
"Virtual machine"."Change Configuration"."Advanced configuration"
"Virtual machine"."Change Configuration"."Set annotation"
"Virtual machine"."Change Configuration"."Change CPU count"
"Virtual machine"."Change Configuration"."Extend virtual disk"
"Virtual machine"."Change Configuration"."Acquire disk lease"
"Virtual machine"."Change Configuration"."Modify device settings"
"Virtual machine"."Change Configuration"."Change Memory"
"Virtual machine"."Change Configuration"."Remove disk"
"Virtual machine"."Change Configuration".Rename
"Virtual machine"."Change Configuration"."Reset guest information"
"Virtual machine"."Change Configuration"."Change resource"
"Virtual machine"."Change Configuration"."Change Settings"
"Virtual machine"."Change Configuration"."Upgrade virtual machine compatibility"
"Virtual machine".Interaction."Guest operating system management by VIX API"
"Virtual machine".Interaction."Power off"
"Virtual machine".Interaction."Power on"
"Virtual machine".Interaction.Reset
"Virtual machine"."Edit Inventory"."Create new"
"Virtual machine"."Edit Inventory"."Create from existing"
"Virtual machine"."Edit Inventory"."Remove"
"Virtual machine".Provisioning."Clone virtual machine"
"Virtual machine".Provisioning."Mark as template"
"Virtual machine".Provisioning."Deploy template"

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。

"vSphere Tagging"."Assign or Unassign vSphere Tag on Object"
Resource."Assign virtual machine to resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add existing disk"
"Virtual machine"."Change Configuration"."Add new disk"
"Virtual machine"."Change Configuration"."Add or remove device"
"Virtual machine"."Change Configuration"."Advanced configuration"
"Virtual machine"."Change Configuration"."Set annotation"
"Virtual machine"."Change Configuration"."Change CPU count"
"Virtual machine"."Change Configuration"."Extend virtual disk"
"Virtual machine"."Change Configuration"."Acquire disk lease"
"Virtual machine"."Change Configuration"."Modify device settings"
"Virtual machine"."Change Configuration"."Change Memory"
"Virtual machine"."Change Configuration"."Remove disk"
"Virtual machine"."Change Configuration".Rename
"Virtual machine"."Change Configuration"."Reset guest information"
"Virtual machine"."Change Configuration"."Change resource"
"Virtual machine"."Change Configuration"."Change Settings"
"Virtual machine"."Change Configuration"."Upgrade virtual machine compatibility"
"Virtual machine".Interaction."Guest operating system management by VIX API"
"Virtual machine".Interaction."Power off"
"Virtual machine".Interaction."Power on"
"Virtual machine".Interaction.Reset
"Virtual machine"."Edit Inventory"."Create new"
"Virtual machine"."Edit Inventory"."Create from existing"
"Virtual machine"."Edit Inventory"."Remove"
"Virtual machine".Provisioning."Clone virtual machine"
"Virtual machine".Provisioning."Deploy template"
"Virtual machine".Provisioning."Mark as template"
Folder."Create folder"
Folder."Delete folder"

また、ユーザーには一部の ReadOnly パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。

例2.3 必要なパーミッションおよび伝播の設定

vSphere オブジェクト必要になる場合子への伝播パーミッションが必要

vSphere vCenter

常時

False

リスト表示された必要な特権

vSphere vCenter data center

既存のフォルダー

False

ReadOnly パーミッション

インストールプログラムがフォルダーを作成する

True

リスト表示された必要な特権

vSphere vCenter Cluster

既存のリソースプール

False

ReadOnly パーミッション

クラスタールートの仮想マシン

True

リスト表示された必要な特権

vSphere vCenter datastore

常時

False

リスト表示された必要な特権

vSphere Switch

常時

False

ReadOnly パーミッション

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 ロールの特権を継承するだけで済むことに注意してください。

グローバル管理者の特権を持つアカウントがニーズに合わない場合は、カスタムロールの作成を検討してください。

重要

必要な特権が設定されていないアカウントはサポートされません。vCenter への OpenShift Container Platform クラスターのインストールは、「必要な vCenter アカウントの特権」セクションで説明されているすべての特権のリストに対してテストされています。このすべての権限のリストに準拠することで、制限された特権セットを持つカスタムロールの作成時に予期しない動作が発生する可能性を抑制できます。

以下の表に、特定の OpenShift Container Platform アーキテクチャーと対話する vSphere オブジェクトの最小権限のリストを示します。

例2.4 installer-provisioned infrastructure の最小権限

ロールの vSphere オブジェクト必要になる場合必要な特権

vSphere vCenter

常時

Cns.Searchable
InventoryService.Tagging.AttachTag
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.DeleteCategory
InventoryService.Tagging.DeleteTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
Sessions.ValidateSession
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

クラスタールートに仮想マシンを作成する場合

Host.Config.Storage
Resource.AssignVMToPool
VApp.AssignResourcePool
VApp.Import
VirtualMachine.Config.AddNewDisk

vSphere vCenter リソースプール

install-config.yaml ファイルに既存のリソースプールを指定する場合

Datastore.Browse
Datastore.FileManagement
Host.Config.Storage
InventoryService.Tagging.ObjectAttachable
Resource.AssignVMToPool
VApp.AssignResourcePool
VApp.Import`minimum

vSphere ポートグループ

常時

Network.Assign

仮想マシンフォルダー

常時

InventoryService.Tagging.ObjectAttachable
Resource.AssignVMToPool
VApp.Import
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddNewDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.DiskLease
VirtualMachine.Config.EditDevice
VirtualMachine.Config.Memory
VirtualMachine.Config.RemoveDisk
VirtualMachine.Config.Rename
VirtualMachine.Config.ResetGuestInfo
VirtualMachine.Config.Resource
VirtualMachine.Config.Settings
VirtualMachine.Config.UpgradeVirtualHardware
VirtualMachine.Interact.GuestControl
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Inventory.Create
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.MarkAsTemplate
VirtualMachine.Provisioning.DeployTemplate

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。クラスターで Machine API を使用しており、API の最小権限セットを設定する必要がある場合は、「Machine API の最小権限」の表を参照してください。

Folder.Create
Folder.Delete
InventoryService.Tagging.ObjectAttachable
Resource.AssignVMToPool
VApp.Import
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddNewDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.DiskLease
VirtualMachine.Config.EditDevice
VirtualMachine.Config.Memory
VirtualMachine.Config.RemoveDisk
VirtualMachine.Config.Rename
VirtualMachine.Config.ResetGuestInfo
VirtualMachine.Config.Resource
VirtualMachine.Config.Settings
VirtualMachine.Config.UpgradeVirtualHardware
VirtualMachine.Interact.GuestControl
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Inventory.Create
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.DeployTemplate
VirtualMachine.Provisioning.MarkAsTemplate

例2.5 コンポーネントのインストール後の管理のための最小権限

ロールの vSphere オブジェクト必要になる場合必要な特権

vSphere vCenter

常時

Cns.Searchable
InventoryService.Tagging.AttachTag
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.DeleteCategory
InventoryService.Tagging.DeleteTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
Sessions.ValidateSession
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

クラスタールートに仮想マシンを作成する場合

Host.Config.Storage
Resource.AssignVMToPool

vSphere vCenter リソースプール

install-config.yaml ファイルに既存のリソースプールを指定する場合

Host.Config.Storage

vSphere データストア

常時

Datastore.AllocateSpace
Datastore.Browse
Datastore.FileManagement
InventoryService.Tagging.ObjectAttachable

vSphere ポートグループ

常時

Network.Assign

仮想マシンフォルダー

常時

VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.Memory
VirtualMachine.Config.Settings
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.DeployTemplate

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。クラスターで Machine API を使用しており、API の最小権限セットを設定する必要がある場合は、「Machine API の最小権限」の表を参照してください。

Resource.AssignVMToPool
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Provisioning.DeployTemplate

例2.6 ストレージコンポーネントの最小権限

ロールの vSphere オブジェクト必要になる場合必要な特権

vSphere vCenter

常時

Cns.Searchable
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

クラスタールートに仮想マシンを作成する場合

Host.Config.Storage

vSphere vCenter リソースプール

install-config.yaml ファイルに既存のリソースプールを指定する場合

Host.Config.Storage

vSphere データストア

常時

Datastore.Browse
Datastore.FileManagement
InventoryService.Tagging.ObjectAttachable

vSphere ポートグループ

常時

Read-Only

仮想マシンフォルダー

常時

VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。クラスターで Machine API を使用しており、API の最小権限セットを設定する必要がある場合は、「Machine API の最小権限」の表を参照してください。

VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice

例2.7 Machine API の最小権限

ロールの vSphere オブジェクト必要になる場合必要な特権

vSphere vCenter

常時

InventoryService.Tagging.AttachTag
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.DeleteCategory
InventoryService.Tagging.DeleteTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
Sessions.ValidateSession
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

クラスタールートに仮想マシンを作成する場合

Resource.AssignVMToPool

vSphere vCenter リソースプール

install-config.yaml ファイルに既存のリソースプールを指定する場合

Read-Only

vSphere データストア

常時

Datastore.AllocateSpace
Datastore.Browse

vSphere ポートグループ

常時

Network.Assign

仮想マシンフォルダー

常時

VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.Memory
VirtualMachine.Config.Settings
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.DeployTemplate

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。

Resource.AssignVMToPool
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Provisioning.DeployTemplate

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 は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。

    重要

    データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion を使用する Storage Distributed Resource Scheduler (SDRS) がデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage DRS を無効にする必要があります。

    複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

クラスターリソース

installer-provisioned infrastructure を使用する OpenShift Container Platform クラスターをデプロイする場合、インストールプログラムは vCenter インスタンスに複数のリソースを作成できる必要があります。

標準的な 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 を使用する必要はありません。

制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。

注記

クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。

さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作成する必要があります。

必要な IP アドレス

DHCP を使用するネットワークの場合、installer-provisioned vSphere インストールには 2 つの静的 IP アドレスが必要です。

  • API アドレスは、クラスター API にアクセスするために使用されます。
  • Ingress アドレスは、クラスターの Ingress トラフィックに使用されます。

OpenShift Container Platform クラスターのインストール時にこれらの IP アドレスをインストールプログラムに指定する必要があります。

DNS レコード

OpenShift Container Platform クラスターをホストする vCenter インスタンスに 2 つの静的 IP アドレスの DNS レコードを適切な DNS サーバーに作成する必要があります。各レコードで、<cluster_name> はクラスター名で、<base_domain> は、クラスターのインストール時に指定するクラスターのベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。

表2.6 必要な DNS レコード
コンポーネントレコード説明

API VIP

api.<cluster_name>.<base_domain>.

この DNS A/AAAA または CNAME (Canonical Name) レコードは、コントロールプレーンマシンのロードバランサーを参照する必要があります。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

Ingress VIP

*.apps.<cluster_name>.<base_domain>.

Ingress ルーター Pod を実行するマシンをターゲットにするロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

vSphere ノードの静的 IP アドレス

動的ホスト設定プロトコル (DHCP) が存在しない環境では、ブートストラップ、コントロールプレーン、およびコンピュートノードを静的 IP アドレスで設定するようにプロビジョニングできます。この環境を設定するには、install-config.yaml ファイルの platform.vsphere.hosts.role パラメーターに値を指定する必要があります。

デフォルトでは、インストールプログラムはネットワークに DHCP を使用するように設定されていますが、このネットワークの設定可能な機能は限られています。

install-config.yaml ファイルで 1 つ以上のマシンプールを定義した後、ネットワーク上のノードにネットワーク定義を定義できます。ネットワーク定義の数が、クラスターに設定したマシンプールの数と一致していることを確認してください。

異なるロールを指定するネットワーク設定の例

# ...
platform:
  vsphere:
    hosts:
    - role: bootstrap 1
      networkDevice:
        ipAddrs:
        - 192.168.204.10/24 2
        gateway: 192.168.204.1 3
        nameservers: 4
        - 192.168.204.1
    - role: control-plane
      networkDevice:
        ipAddrs:
        - 192.168.204.11/24
        gateway: 192.168.204.1
        nameservers:
        - 192.168.204.1
    - role: control-plane
      networkDevice:
        ipAddrs:
        - 192.168.204.12/24
        gateway: 192.168.204.1
        nameservers:
        - 192.168.204.1
    - role: control-plane
      networkDevice:
        ipAddrs:
        - 192.168.204.13/24
        gateway: 192.168.204.1
        nameservers:
        - 192.168.204.1
    - role: compute
      networkDevice:
        ipAddrs:
        - 192.168.204.14/24
        gateway: 192.168.204.1
        nameservers:
        - 192.168.204.1
# ...

1
有効なネットワーク定義値には、bootstrapcontrol-plane、および compute が含まれます。install-config.yaml 設定ファイルに少なくとも 1 つの bootstrap ネットワーク定義をリストする必要があります。
2
インストールプログラムがネットワークインターフェイスに渡す IPv4、IPv6、またはその両方の IP アドレスをリストします。マシン API コントローラーは、設定されているすべての IP アドレスをデフォルトのネットワークインターフェイスに割り当てます。
3
ネットワークインターフェイスのデフォルトゲートウェイ。
4
最大 3 つの DNS ネームサーバーをリストします。

静的 IP アドレスを持つノードを実行するようにクラスターをデプロイした後、これらの静的 IP アドレスのいずれかを使用するようにマシンをスケーリングできます。さらに、マシンセットを使用して、設定済みの静的 IP アドレスの 1 つを使用するようにマシンを設定できます。

2.2. installer-provisioned infrastructure を使用したクラスターのインストールの準備

以下の手順を実行して、vSphere に OpenShift Container Platform クラスターをインストールする準備をします。

  • インストールプログラムをダウンロードします。

    注記

    非接続環境にインストールする場合は、ミラーリングしたコンテンツからインストールプログラムを抽出します。詳細は、非接続インストール用のイメージのミラーリング を参照してください。

  • OpenShift CLI (oc) をインストールします。

    注記

    非接続環境にインストールする場合は、ミラーホストに oc をインストールします。

  • SSH キーペアを生成します。OpenShift Container Platform クラスターのデプロイ後にこのキーペアを使用して、クラスターのノードに対する認証を行うことができます。
  • vCenter の信頼されたルート CA 証明書をシステム信頼に追加します。

2.2.1. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • Red Hat Enterprise Linux (RHEL) 8 などの Linux を実行し、少なくとも 1.2 GB のローカルディスク領域を備えたマシンがある。

    重要

    macOS 上でインストールプログラムを実行しようとすると、golang コンパイラーに関連する既知の問題により、OpenShift Container Platform クラスターのインストールに失敗します。この問題の詳細は、OpenShift Container Platform 4.16 リリースノート ドキュメントの「既知の問題」セクションを参照してください。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

    重要
    • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
    • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
  5. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  6. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
ヒント

Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。

2.2.2. OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.16 のすべてのコマンドを実行することはできません。新しいバージョンの oc をダウンロードしてインストールしてください。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.16 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.16 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

2.2.3. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。

2.2.4. vCenter ルート CA 証明書のシステム信頼への追加

インストールプログラムは vCenter の API へのアクセスが必要であるため、OpenShift Container Platform クラスターをインストールする前に vCenter の信頼されたルート CA 証明書をシステム信頼に追加する必要があります。

手順

  1. vCenter ホームページから、vCenter のルート CA 証明書をダウンロードします。vSphere Web Services SDK セクションで、Download trusted root CA certificates をクリックします。<vCenter>/certs/download.zip ファイルがダウンロードされます。
  2. vCenter ルート CA 証明書が含まれる圧縮ファイルを展開します。圧縮ファイルの内容は、以下のファイル構造のようになります。

    certs
    ├── lin
    │   ├── 108f4d17.0
    │   ├── 108f4d17.r1
    │   ├── 7e757f6a.0
    │   ├── 8e4f8471.0
    │   └── 8e4f8471.r0
    ├── mac
    │   ├── 108f4d17.0
    │   ├── 108f4d17.r1
    │   ├── 7e757f6a.0
    │   ├── 8e4f8471.0
    │   └── 8e4f8471.r0
    └── win
        ├── 108f4d17.0.crt
        ├── 108f4d17.r1.crl
        ├── 7e757f6a.0.crt
        ├── 8e4f8471.0.crt
        └── 8e4f8471.r0.crl
    
    3 directories, 15 files
  3. オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。

    # cp certs/lin/* /etc/pki/ca-trust/source/anchors
  4. システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。

    # update-ca-trust extract

2.3. クラスターの vSphere へのインストール

OpenShift Container Platform バージョン 4.16 では、installer-provisioned infrastructure を使用して、VMware vSphere インスタンスにクラスターをインストールできます。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

2.3.1. 前提条件

2.3.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

2.3.3. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
  • オプション: クラスターを作成する前に、デフォルトのロードバランサーの代わりに外部ロードバランサーを設定します。

    重要

    インストールプログラムに API および Ingress 静的アドレスを指定する必要はありません。この設定を選択した場合は、追加のアクションを実行して、参照される各 vSphere サブネットから IP アドレスを受け入れるネットワークターゲットを定義する必要があります。「ユーザー管理ロードバランサーの設定」セクションを参照してください。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    ディレクトリーを指定する場合:

    • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
    • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
  2. プロンプト時に値を指定します。

    1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

      注記

      インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

    2. ターゲットに設定するプラットフォームとして vsphere を選択します。
    3. vCenter インスタンスの名前を指定します。
    4. クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。

      インストールプログラムは vCenter インスタンスに接続します。

      重要

      Active Directory (AD) が統合された一部の VMware vCenter Single Sign-On (SSO) 環境では、主に <domain>\ 構造を必要とする従来のログイン方法を使用する必要がある可能性があります。

      vCenter アカウントの権限チェックが必ず適切に完了するようにするには、<username>@<full_qualified_domainname> などのユーザープリンシパル名 (UPN) ログイン方法の使用を検討してください。

    5. 接続する vCenter インスタンスのデータセンターを選択します。
    6. 使用するデフォルトの vCenter データストアを選択します。

      注記

      データストアとクラスター名は 60 文字を超えることができません。そのため、組み合わせた文字列の長さが 60 文字の制限を超えないようにしてください。

    7. OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
    8. 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
    9. コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
    10. クラスター Ingress に設定した仮想 IP アドレスを入力します。
    11. ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
    12. クラスターの記述名を入力します。クラスター名は、設定した DNS レコードで使用したものと同じである必要があります。

      注記

      データストアとクラスター名は 60 文字を超えることができません。そのため、組み合わせた文字列の長さが 60 文字の制限を超えないようにしてください。

    13. Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

2.3.4. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

2.3.5. レジストリーストレージの作成

クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。

2.3.5.1. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、Image Registry Operator 設定を編集して managementStateRemoved から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。

2.3.5.2. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

2.3.5.2.1. VMware vSphere のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • VMware vSphere 上のクラスター。
  • Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • "100Gi" の容量が必要です。
重要

テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリックストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim: 1

    1
    image-registry-storage 永続ボリューム要求 (PVC) の自動作成を許可するには、claim フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION                              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.7                                  True        False         False      6h50m

2.3.5.2.2. VMware vSphere のブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. 次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して Recreate ロールアウトストラテジーを使用し、1 つのレプリカのみで実行されるようにします。

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。

    1. 以下の内容で pvc.yaml ファイルを作成して VMware vSphere PersistentVolumeClaim オブジェクトを定義します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 1
        namespace: openshift-image-registry 2
      spec:
        accessModes:
        - ReadWriteOnce 3
        resources:
          requests:
            storage: 100Gi 4
      1
      PersistentVolumeClaim オブジェクトを表す一意の名前。
      2
      PersistentVolumeClaim オブジェクトの namespace (openshift-image-registry)。
      3
      永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
      4
      永続ボリューム要求のサイズ。
    2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

      $ oc create -f pvc.yaml -n openshift-image-registry
  3. 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。

    $ oc edit config.imageregistry.operator.openshift.io -o yaml

    出力例

    storage:
      pvc:
        claim: 1

    1
    カスタム PVC を作成することにより、image-registry-storage PVC のデフォルトの自動作成の claim フィールドを空のままにできます。

正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。

2.3.6. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

2.3.7. 次のステップ

2.4. カスタマイズによる vSphere へのクラスターのインストール

OpenShift Container Platform バージョン 4.16 では、installer-provisioned infrastructure を使用して、VMware vSphere インスタンスにクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

2.4.1. 前提条件

2.4.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

2.4.3. VMware vSphere のリージョンとゾーンの有効化

OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

重要

VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。

デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。

次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。

  • 障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
  • リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。
  • ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。
注記

install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。

リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。

次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。

データセンター (リージョン)クラスター (ゾーン)タグ

米国東部

us-east-1

us-east-1a

us-east-1b

us-east-2

us-east-2a

us-east-2b

us-west

us-west-1

us-west-1a

us-west-1b

us-west-2

us-west-2a

us-west-2b

2.4.4. インストール設定ファイルの作成

VMware vSphere にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして vsphere を選択します。
      3. vCenter インスタンスの名前を指定します。
      4. クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。

        インストールプログラムは vCenter インスタンスに接続します。

      5. 接続する vCenter インスタンスのデータセンターを選択します。

        注記

        インストール設定ファイルを作成した後、そのファイルを変更して複数の vSphere データセンター環境を作成できます。これは、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできることを意味します。この環境の作成の詳細は、VMware vSphere のリージョンとゾーンの有効化 を参照してください。

      6. 使用するデフォルトの vCenter データストアを選択します。

        警告

        データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion を使用する Storage Distributed Resource Scheduler (SDRS) がデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage DRS を無効にする必要があります。

        複数のデータストアパスを指定することはできません。複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

      7. OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
      8. 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
      9. コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
      10. クラスター Ingress に設定した仮想 IP アドレスを入力します。
      11. ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
      12. クラスターの記述名を入力します。

        入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。

  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。

    注記

    3 ノードクラスターをインストールする場合は、必ず compute.replicas パラメーターを 0 に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「vSphere への 3 ノードクラスターのインストール」を参照してください。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

2.4.4.1. installer-provisioned VMware vSphere クラスターの install-config.yaml ファイルのサンプル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name:  <worker_node>
  platform: {}
  replicas: 3
controlPlane: 3
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: test 4
platform:
  vsphere: 5
    apiVIPs:
      - 10.0.0.1
    failureDomains: 6
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<data_center>/host/<cluster>"
        datacenter: <data_center>
        datastore: "/<data_center>/datastore/<datastore>" 7
        networks:
        - <VM_Network_name>
        resourcePool: "/<data_center>/host/<cluster>/Resources/<resourcePool>" 8
        folder: "/<data_center_name>/vm/<folder_name>/<subfolder_name>"
        tagIDs: 9
        - <tag_id>  10
      zone: <default_zone_name>
    ingressVIPs:
    - 10.0.0.2
    vcenters:
    - datacenters:
      - <data_center>
      password: <password>
      port: 443
      server: <fully_qualified_domain_name>
      user: administrator@vsphere.local
    diskType: thin 11
fips: false
pullSecret: '{"auths": ...}'
sshKey: 'ssh-ed25519 AAAA...'
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 3
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
4
DNS レコードに指定したクラスター名。
5
オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
6
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
7
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。

複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

8
オプション: マシン作成用の既存のリソースプールを提供します。値を指定しない場合、インストールプログラムは vSphere クラスターのルートリソースプールを使用します。
9
オプション: OpenShift Container Platform によって作成された各仮想マシンには、クラスターに固有の一意のタグが割り当てられます。割り当てられたタグにより、クラスターの使用停止時に、関連付けられた仮想マシンをインストールプログラムが識別して削除できるようになります。インストールプログラムによってプロビジョニングされた仮想マシンに割り当てる追加のタグ ID を最大 10 個までリストできます。
10
インストールプログラムによって関連付けられるタグの ID。たとえば、urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL です。タグ ID の決定の詳細は、vSphere Tags and Attributes ドキュメントを参照してください。
11
vSphere ディスクのプロビジョニング方法。
注記

OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。

2.4.4.2. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは 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
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

2.4.4.3. VMware vCenter のリージョンとゾーンの設定

デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。

OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。

重要

この例では、govc コマンドを使用します。govc コマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは govc コマンドを保守していません。govc のダウンロードとインストールの手順は、VMware ドキュメント Web サイトを参照してください。

前提条件

  • 既存の install-config.yaml インストール設定ファイルがあります。

    重要

    VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

手順

  1. 次の govc コマンドラインツールコマンドを入力して、openshift-region および openshift-zone vCenter タグカテゴリーを作成します。

    重要

    openshift-region および openshift-zone vCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。

    $ govc tags.category.create -d "OpenShift region" openshift-region
    $ govc tags.category.create -d "OpenShift zone" openshift-zone
  2. クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。

    $ govc tags.create -c <region_tag_category> <region_tag>
  3. クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。

    $ govc tags.create -c <zone_tag_category> <zone_tag>
  4. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにリージョンタグをアタッチします。

    $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>
  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
  6. インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。

vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル

---
compute:
---
  vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
controlPlane:
---
vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
platform:
  vsphere:
    vcenters:
---
    datacenters:
      - <data_center_1_name>
      - <data_center_2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_1>
        computeCluster: "/<data_center_1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<data_center_1>/datastore/<datastore1>"
        resourcePool: "/<data_center_1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<data_center_1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_2>
        computeCluster: "/<data_center_2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<data_center_2>/datastore/<datastore2>"
        resourcePool: "/<data_center_2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<data_center_2>/vm/<folder2>"
---

2.4.5. ユーザー管理ロードバランサーのサービス

デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。

重要

ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。

このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。

Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。

図2.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。

図2.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。

図2.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例

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 が未定義のノードに移動すると、接続が停止する可能性があります。
2.4.5.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 を指定して設定できまうs.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

Machine Config API ヘルスチェック仕様の例

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

手順

  1. HAProxy Ingress Controller を設定して、ポート 6443、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。

    1 つのサブネットをリストした HAProxy 設定の例

    # ...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
        bind 192.168.1.100:443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
       bind 192.168.1.100:80
       mode tcp
       balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...

    複数のサブネットをリストした HAProxy 設定の例

    # ...
    listen api-server-6443
        bind *:6443
        mode tcp
          server master-00 192.168.83.89:6443 check inter 1s
          server master-01 192.168.84.90:6443 check inter 1s
          server master-02 192.168.85.99:6443 check inter 1s
          server bootstrap 192.168.80.89:6443 check inter 1s
    
    listen machine-config-server-22623
        bind *:22623
        mode tcp
          server master-00 192.168.83.89:22623 check inter 1s
          server master-01 192.168.84.90:22623 check inter 1s
          server master-02 192.168.85.99:22623 check inter 1s
          server bootstrap 192.168.80.89:22623 check inter 1s
    
    listen ingress-router-80
        bind *:80
        mode tcp
        balance source
          server worker-00 192.168.83.100:80 check inter 1s
          server worker-01 192.168.83.101:80 check inter 1s
    
    listen ingress-router-443
        bind *:443
        mode tcp
        balance source
          server worker-00 192.168.83.100:443 check inter 1s
          server worker-01 192.168.83.101:443 check inter 1s
    
    listen ironic-api-6385
        bind *:6385
        mode tcp
        balance source
          server master-00 192.168.83.89:6385 check inter 1s
          server master-01 192.168.84.90:6385 check inter 1s
          server master-02 192.168.85.99:6385 check inter 1s
          server bootstrap 192.168.80.89:6385 check inter 1s
    
    listen inspector-api-5050
        bind *:5050
        mode tcp
        balance source
          server master-00 192.168.83.89:5050 check inter 1s
          server master-01 192.168.84.90:5050 check inter 1s
          server master-02 192.168.85.99:5050 check inter 1s
          server bootstrap 192.168.80.89:5050 check inter 1s
    # ...

  2. curl CLI コマンドを使用して、ユーザー管理ロードバランサーとそのリソースが動作していることを確認します。

    1. 次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
    4. 次のコマンドを実行して出力を確認し、コントローラーがポート 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>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
  3. ユーザー管理ロードバランサーのフロントエンド 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 apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    重要

    DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。

  4. OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの install-config.yaml ファイルで次の設定を指定する必要があります。

    # ...
    platform:
      vsphere:
        loadBalancer:
          type: UserManaged 1
          apiVIPs:
          - <api_ip> 2
          ingressVIPs:
          - <ingress_ip> 3
    # ...
    1
    クラスターのユーザー管理ロードバランサーを指定するには、type パラメーターに UserManaged を設定します。パラメーターのデフォルトは OpenShiftManagedDefault で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra namespace で定義されたサービスの場合、ユーザー管理ロードバランサーは coredns サービスをクラスター内の Pod にデプロイできますが、keepalived および haproxy サービスは無視します。
    2
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
    3
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。

検証

  1. curl CLI コマンドを使用して、ユーザー管理ロードバランサーと DNS レコード設定が動作していることを確認します。

    1. 次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
    4. 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

2.4.6. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
  • オプション: クラスターを作成する前に、デフォルトのロードバランサーの代わりに外部ロードバランサーを設定します。

    重要

    インストールプログラムに API および Ingress 静的アドレスを指定する必要はありません。この設定を選択した場合は、追加のアクションを実行して、参照される各 vSphere サブネットから IP アドレスを受け入れるネットワークターゲットを定義する必要があります。「ユーザー管理ロードバランサーの設定」セクションを参照してください。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

2.4.7. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

2.4.8. レジストリーストレージの作成

クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。

2.4.8.1. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、Image Registry Operator 設定を編集して managementStateRemoved から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。

2.4.8.2. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

2.4.8.2.1. VMware vSphere のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • VMware vSphere 上のクラスター。
  • Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • "100Gi" の容量が必要です。
重要

テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリックストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim: 1

    1
    image-registry-storage 永続ボリューム要求 (PVC) の自動作成を許可するには、claim フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION                              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.7                                  True        False         False      6h50m

2.4.8.2.2. VMware vSphere のブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. 次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して Recreate ロールアウトストラテジーを使用し、1 つのレプリカのみで実行されるようにします。

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。

    1. 以下の内容で pvc.yaml ファイルを作成して VMware vSphere PersistentVolumeClaim オブジェクトを定義します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 1
        namespace: openshift-image-registry 2
      spec:
        accessModes:
        - ReadWriteOnce 3
        resources:
          requests:
            storage: 100Gi 4
      1
      PersistentVolumeClaim オブジェクトを表す一意の名前。
      2
      PersistentVolumeClaim オブジェクトの namespace (openshift-image-registry)。
      3
      永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
      4
      永続ボリューム要求のサイズ。
    2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

      $ oc create -f pvc.yaml -n openshift-image-registry
  3. 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。

    $ oc edit config.imageregistry.operator.openshift.io -o yaml

    出力例

    storage:
      pvc:
        claim: 1

    1
    カスタム PVC を作成することにより、image-registry-storage PVC のデフォルトの自動作成の claim フィールドを空のままにできます。

正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。

2.4.9. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

2.4.10. 次のステップ

2.5. ネットワークのカスタマイズによる vSphere へのクラスターのインストール

OpenShift Container Platform バージョン 4.16 では、installer-provisioned infrastructure とカスタマイズした設定オプションを使用して、VMware vSphere インスタンスにクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。

大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

2.5.1. 前提条件

2.5.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

2.5.3. VMware vSphere のリージョンとゾーンの有効化

OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

重要

VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。

デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。

次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。

  • 障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
  • リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。
  • ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。
注記

install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。

リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。

次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。

データセンター (リージョン)クラスター (ゾーン)タグ

米国東部

us-east-1

us-east-1a

us-east-1b

us-east-2

us-east-2a

us-east-2b

us-west

us-west-1

us-west-1a

us-west-1b

us-west-2

us-west-2a

us-west-2b

2.5.4. インストール設定ファイルの作成

VMware vSphere にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして vsphere を選択します。
      3. vCenter インスタンスの名前を指定します。
      4. クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。

        インストールプログラムは vCenter インスタンスに接続します。

      5. 接続する vCenter インスタンスのデータセンターを選択します。

        注記

        インストール設定ファイルを作成した後、そのファイルを変更して複数の vSphere データセンター環境を作成できます。これは、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできることを意味します。この環境の作成の詳細は、VMware vSphere のリージョンとゾーンの有効化 を参照してください。

      6. 使用するデフォルトの vCenter データストアを選択します。

        警告

        データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion を使用する Storage Distributed Resource Scheduler (SDRS) がデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage DRS を無効にする必要があります。

        複数のデータストアパスを指定することはできません。複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

      7. OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
      8. 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
      9. コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
      10. クラスター Ingress に設定した仮想 IP アドレスを入力します。
      11. ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
      12. クラスターの記述名を入力します。

        入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。

  2. install-config.yaml ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

2.5.4.1. installer-provisioned VMware vSphere クラスターの install-config.yaml ファイルのサンプル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name:  <worker_node>
  platform: {}
  replicas: 3
controlPlane: 3
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: test 4
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 5
  serviceNetwork:
  - 172.30.0.0/16
platform:
  vsphere: 6
    apiVIPs:
      - 10.0.0.1
    failureDomains: 7
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<data_center>/host/<cluster>"
        datacenter: <data_center>
        datastore: "/<data_center>/datastore/<datastore>" 8
        networks:
        - <VM_Network_name>
        resourcePool: "/<data_center>/host/<cluster>/Resources/<resourcePool>" 9
        folder: "/<data_center_name>/vm/<folder_name>/<subfolder_name>"
        tagIDs: 10
        - <tag_id>  11
      zone: <default_zone_name>
    ingressVIPs:
    - 10.0.0.2
    vcenters:
    - datacenters:
      - <data_center>
      password: <password>
      port: 443
      server: <fully_qualified_domain_name>
      user: administrator@vsphere.local
    diskType: thin 12
fips: false
pullSecret: '{"auths": ...}'
sshKey: 'ssh-ed25519 AAAA...'
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 3
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
4
DNS レコードに指定したクラスター名。
6
オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
7
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
8
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。

複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

9
オプション: マシン作成用の既存のリソースプールを提供します。値を指定しない場合、インストールプログラムは vSphere クラスターのルートリソースプールを使用します。
10
オプション: OpenShift Container Platform によって作成された各仮想マシンには、クラスターに固有の一意のタグが割り当てられます。割り当てられたタグにより、クラスターの使用停止時に、関連付けられた仮想マシンをインストールプログラムが識別して削除できるようになります。インストールプログラムによってプロビジョニングされた仮想マシンに割り当てる追加のタグ ID を最大 10 個までリストできます。
11
インストールプログラムによって関連付けられるタグの ID。たとえば、urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL です。タグ ID の決定の詳細は、vSphere Tags and Attributes ドキュメントを参照してください。
12
vSphere ディスクのプロビジョニング方法。
5
インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
注記

OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。

2.5.4.2. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは 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
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

2.5.4.3. オプション: デュアルスタックネットワークを使用したデプロイ

OpenShift Container Platform クラスターのデュアルスタックネットワークでは、クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定できます。クラスターノードの IPv4 および IPv6 アドレスエンドポイントを設定するには、install-config.yaml ファイルで machineNetworkclusterNetwork、および serviceNetwork 設定を編集します。それぞれの設定には、それぞれ 2 つの CIDR エントリーが必要です。プライマリーアドレスファミリーとして IPv4 ファミリーを持つクラスターの場合は、最初に IPv4 設定を指定します。プライマリーアドレスファミリーとして IPv6 ファミリーを持つクラスターの場合は、最初に IPv6 設定を指定します。

machineNetwork:
- cidr: {{ extcidrnet }}
- cidr: {{ extcidrnet6 }}
clusterNetwork:
- cidr: 10.128.0.0/14
  hostPrefix: 23
- cidr: fd02::/48
  hostPrefix: 64
serviceNetwork:
- 172.30.0.0/16
- fd03::/112

IPv4 および IPv6 アドレスを使用するアプリケーションのクラスターへのインターフェイスを提供するには、Ingress VIP および API VIP サービスの IPv4 および IPv6 仮想 IP (VIP) アドレスエンドポイントを設定します。IPv4 および IPv6 アドレスエンドポイントを設定するには、install-config.yaml ファイルで apiVIPs および ingressVIPs 設定を編集します。apiVIPs および ingressVIPs 設定では、リスト形式を使用します。リストの順序は、各サービスのプライマリーおよびセカンダリー VIP アドレスを示しています。

platform:
  vsphere:
    apiVIPs:
      - <api_ipv4>
      - <api_ipv6>
    ingressVIPs:
      - <wildcard_ipv4>
      - <wildcard_ipv6>
注記

デュアルスタックネットワーク設定のクラスターの場合、IPv4 アドレスと IPv6 アドレスの両方を同じインターフェイスに割り当てる必要があります。

2.5.4.4. VMware vCenter のリージョンとゾーンの設定

デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。

OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。

重要

この例では、govc コマンドを使用します。govc コマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは govc コマンドを保守していません。govc のダウンロードとインストールの手順は、VMware ドキュメント Web サイトを参照してください。

前提条件

  • 既存の install-config.yaml インストール設定ファイルがあります。

    重要

    VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

手順

  1. 次の govc コマンドラインツールコマンドを入力して、openshift-region および openshift-zone vCenter タグカテゴリーを作成します。

    重要

    openshift-region および openshift-zone vCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。

    $ govc tags.category.create -d "OpenShift region" openshift-region
    $ govc tags.category.create -d "OpenShift zone" openshift-zone
  2. クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。

    $ govc tags.create -c <region_tag_category> <region_tag>
  3. クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。

    $ govc tags.create -c <zone_tag_category> <zone_tag>
  4. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにリージョンタグをアタッチします。

    $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>
  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
  6. インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。

vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル

---
compute:
---
  vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
controlPlane:
---
vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
platform:
  vsphere:
    vcenters:
---
    datacenters:
      - <data_center_1_name>
      - <data_center_2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_1>
        computeCluster: "/<data_center_1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<data_center_1>/datastore/<datastore1>"
        resourcePool: "/<data_center_1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<data_center_1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_2>
        computeCluster: "/<data_center_2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<data_center_2>/datastore/<datastore2>"
        resourcePool: "/<data_center_2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<data_center_2>/vm/<folder2>"
---

2.5.5. ネットワーク設定フェーズ

OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。

フェーズ 1

マニフェストファイルを作成する前に、install-config.yaml ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork

    詳細は、「インストール設定パラメーター」を参照してください。

    注記

    優先されるサブネットが配置されている Classless Inter-Domain Routing (CIDR) と一致するように networking.machineNetwork を設定します。

    重要

    CIDR 範囲 172.17.0.0/16libVirt によって予約されています。クラスター内のネットワークに 172.17.0.0/16 CIDR 範囲と重複する他の CIDR 範囲を使用することはできません。

フェーズ 2
openshift-install create manifests を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。

フェーズ 2 では、install-config.yaml ファイルのフェーズ 1 で指定した値をオーバーライドすることはできません。ただし、フェーズ 2 でネットワークプラグインをカスタマイズできます。

2.5.6. 高度なネットワーク設定の指定

ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。

高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 次の例のように、cluster-network-03-config.yml ファイルでクラスターの高度なネットワーク設定を指定します。

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig:
            mode: Full

  4. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時に manifests/ ディレクトリーを使用します。
  5. コントロールプレーンマシンおよび compute machineSets を定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

    これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

    • MachineSet ファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
2.5.6.1. ネットワークに複数のサブネットを指定する

OpenShift Container Platform クラスターを vSphere ホストにインストールする前に、ネットワーク実装に複数のサブネットを指定して、vSphere Cloud Controller Manager (CCM) が特定のネットワーク状況に適したサブネットを選択できるようにします。vSphere は、クラスター上の Pod およびサービスを管理するサブネットを使用できます。

この設定では、vSphere CCM 設定で内部および外部の Classless Inter-Domain Routing (CIDR) 実装を指定する必要があります。各 CIDR 実装は、内部および外部ネットワークからのトラフィックと対話するサブネットを決定するために CCM が使用する IP アドレス範囲をリスト表示します。

重要

vSphere CCM 設定で内部および外部の CIDR 実装の設定に失敗すると、vSphere CCM が誤ったサブネットを選択する可能性があります。この状況では、以下のエラーが発生します。

ERROR Bootstrap failed to complete: timed out waiting for the condition
ERROR Failed to wait for bootstrapping to complete. This error usually happens when there is a problem with control plane hosts that prevents the control plane operators from creating the control plane.

この設定により、新規の各ノードが node.cloudprovider.kubernetes.io/uninitialized taint を受け取ると、単一のサブネットの MachineSet オブジェクトに関連付けられた新規ノードが使用できなくなる可能性があります。このような状況では、Kubernetes API サーバーとの通信で問題が発生し、これが原因でクラスターのインストールが失敗する可能性があります。

前提条件

  • OpenShift Container Platform クラスターの Kubernetes マニフェストファイルを作成している。

手順

  1. OpenShift Container Platform クラスターマニフェストファイルを保存するディレクトリーから、manifests/cluster-infrastructure-02-config.yml マニフェストファイルを開きます。
  2. nodeNetworking オブジェクトをファイルに追加し、オブジェクトの内部および外部ネットワークサブネット CIDR 実装を指定します。

    ヒント

    ほとんどのネットワークの場合、標準のマルチサブネット構成の設定を検討してください。この構成では、nodeNetworking.internal.networkSubnetCidr および nodeNetworking.external.networkSubnetCidr パラメーターに同じ IP アドレス範囲を設定する必要があります。

    設定された cluster-infrastructure-02-config.yml マニフェストファイルの例

    apiVersion: config.openshift.io/v1
    kind: Infrastructure
    metadata:
      name: cluster
    spec:
      cloudConfig:
        key: config
        name: cloud-provider-config
      platformSpec:
        type: VSphere
        vsphere:
          failureDomains:
          - name: generated-failure-domain
          ...
           nodeNetworking:
             external:
               networkSubnetCidr:
               - <machine_network_cidr_ipv4>
               - <machine_network_cidr_ipv6>
             internal:
               networkSubnetCidr:
               - <machine_network_cidr_ipv4>
               - <machine_network_cidr_ipv6>
    # ...

2.5.7. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、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.5.7.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表2.7 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表2.8 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

表2.9 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 設定をカスタマイズするための設定オブジェクトを指定します。

ipv4

object

IPv4 設定の設定オブジェクトを指定します。

ipv6

object

IPv6 設定の設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

表2.10 ovnKubernetesConfig.ipv4 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが 100.88.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は 100.88.0.0/16 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

デフォルト値は 100.64.0.0/16 です。

表2.11 ovnKubernetesConfig.ipv6 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが fd97::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は fd97::/64 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが fd98::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

デフォルト値は fd98::/64 です。

表2.12 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表2.13 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドをtrueに設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

ipv4

object

オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

ipv6

object

オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

表2.14 gatewayConfig.ipv4 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 169.254.169.0/29 です。

表2.15 gatewayConfig.ipv6 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は fd69::/125 です。

表2.16 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

IPsec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

重要

OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。

kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表2.17 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

2.5.8. ユーザー管理ロードバランサーのサービス

デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。

重要

ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。

このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。

Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。

図2.4 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。

図2.5 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。

図2.6 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例

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 が未定義のノードに移動すると、接続が停止する可能性があります。
2.5.8.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 を指定して設定できまうs.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

Machine Config API ヘルスチェック仕様の例

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

手順

  1. HAProxy Ingress Controller を設定して、ポート 6443、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。

    1 つのサブネットをリストした HAProxy 設定の例

    # ...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
        bind 192.168.1.100:443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
       bind 192.168.1.100:80
       mode tcp
       balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...

    複数のサブネットをリストした HAProxy 設定の例

    # ...
    listen api-server-6443
        bind *:6443
        mode tcp
          server master-00 192.168.83.89:6443 check inter 1s
          server master-01 192.168.84.90:6443 check inter 1s
          server master-02 192.168.85.99:6443 check inter 1s
          server bootstrap 192.168.80.89:6443 check inter 1s
    
    listen machine-config-server-22623
        bind *:22623
        mode tcp
          server master-00 192.168.83.89:22623 check inter 1s
          server master-01 192.168.84.90:22623 check inter 1s
          server master-02 192.168.85.99:22623 check inter 1s
          server bootstrap 192.168.80.89:22623 check inter 1s
    
    listen ingress-router-80
        bind *:80
        mode tcp
        balance source
          server worker-00 192.168.83.100:80 check inter 1s
          server worker-01 192.168.83.101:80 check inter 1s
    
    listen ingress-router-443
        bind *:443
        mode tcp
        balance source
          server worker-00 192.168.83.100:443 check inter 1s
          server worker-01 192.168.83.101:443 check inter 1s
    
    listen ironic-api-6385
        bind *:6385
        mode tcp
        balance source
          server master-00 192.168.83.89:6385 check inter 1s
          server master-01 192.168.84.90:6385 check inter 1s
          server master-02 192.168.85.99:6385 check inter 1s
          server bootstrap 192.168.80.89:6385 check inter 1s
    
    listen inspector-api-5050
        bind *:5050
        mode tcp
        balance source
          server master-00 192.168.83.89:5050 check inter 1s
          server master-01 192.168.84.90:5050 check inter 1s
          server master-02 192.168.85.99:5050 check inter 1s
          server bootstrap 192.168.80.89:5050 check inter 1s
    # ...

  2. curl CLI コマンドを使用して、ユーザー管理ロードバランサーとそのリソースが動作していることを確認します。

    1. 次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
    4. 次のコマンドを実行して出力を確認し、コントローラーがポート 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>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
  3. ユーザー管理ロードバランサーのフロントエンド 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 apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    重要

    DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。

  4. OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの install-config.yaml ファイルで次の設定を指定する必要があります。

    # ...
    platform:
      vsphere:
        loadBalancer:
          type: UserManaged 1
          apiVIPs:
          - <api_ip> 2
          ingressVIPs:
          - <ingress_ip> 3
    # ...
    1
    クラスターのユーザー管理ロードバランサーを指定するには、type パラメーターに UserManaged を設定します。パラメーターのデフォルトは OpenShiftManagedDefault で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra namespace で定義されたサービスの場合、ユーザー管理ロードバランサーは coredns サービスをクラスター内の Pod にデプロイできますが、keepalived および haproxy サービスは無視します。
    2
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
    3
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。

検証

  1. curl CLI コマンドを使用して、ユーザー管理ロードバランサーと DNS レコード設定が動作していることを確認します。

    1. 次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
    4. 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

2.5.9. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
  • オプション: クラスターを作成する前に、デフォルトのロードバランサーの代わりに外部ロードバランサーを設定します。

    重要

    インストールプログラムに API および Ingress 静的アドレスを指定する必要はありません。この設定を選択した場合は、追加のアクションを実行して、参照される各 vSphere サブネットから IP アドレスを受け入れるネットワークターゲットを定義する必要があります。「ユーザー管理ロードバランサーの設定」セクションを参照してください。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

2.5.10. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

2.5.11. レジストリーストレージの作成

クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。

2.5.11.1. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、Image Registry Operator 設定を編集して managementStateRemoved から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。

2.5.11.2. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

2.5.11.2.1. VMware vSphere のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • VMware vSphere 上のクラスター。
  • Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • "100Gi" の容量が必要です。
重要

テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリックストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim: 1

    1
    image-registry-storage 永続ボリューム要求 (PVC) の自動作成を許可するには、claim フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION                              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.7                                  True        False         False      6h50m

2.5.11.2.2. VMware vSphere のブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. 次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して Recreate ロールアウトストラテジーを使用し、1 つのレプリカのみで実行されるようにします。

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。

    1. 以下の内容で pvc.yaml ファイルを作成して VMware vSphere PersistentVolumeClaim オブジェクトを定義します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 1
        namespace: openshift-image-registry 2
      spec:
        accessModes:
        - ReadWriteOnce 3
        resources:
          requests:
            storage: 100Gi 4
      1
      PersistentVolumeClaim オブジェクトを表す一意の名前。
      2
      PersistentVolumeClaim オブジェクトの namespace (openshift-image-registry)。
      3
      永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
      4
      永続ボリューム要求のサイズ。
    2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

      $ oc create -f pvc.yaml -n openshift-image-registry
  3. 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。

    $ oc edit config.imageregistry.operator.openshift.io -o yaml

    出力例

    storage:
      pvc:
        claim: 1

    1
    カスタム PVC を作成することにより、image-registry-storage PVC のデフォルトの自動作成の claim フィールドを空のままにできます。

正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。

2.5.12. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

2.5.13. コントロールプレーンで実行されるネットワークコンポーネントの設定

ネットワークコンポーネントは、コントロールプレーンノードでのみ実行するように設定できます。デフォルトで、OpenShift Container Platform はマシン設定プールの任意のノードが ingressVIP 仮想 IP アドレスをホストできるようにします。ただし、環境によっては、コントロールプレーンノードとは別のサブネットにコンピュートノードがデプロイされるため、コントロールプレーンノードで実行するために ingressVIP 仮想 IP アドレスを設定する必要があります。

注記

別のサブネットにコンピュートマシンセットを作成することで、リモートノードをスケーリングできます。

重要

リモートノードを別々のサブネットにデプロイする場合は、コントロールプレーンノード専用に ingressVIP 仮想 IP アドレスを配置する必要があります。

installer-provisioned ネットワーク

手順

  1. install-config.yaml ファイルを保存するディレクトリーに移動します。

    $ cd ~/clusterconfigs
  2. manifests サブディレクトリーに切り替えます。

    $ cd manifests
  3. cluster-network-avoid-workers-99-config.yaml という名前のファイルを作成します。

    $ touch cluster-network-avoid-workers-99-config.yaml
  4. エディターで cluster-network-avoid-workers-99-config.yaml ファイルを開き、Operator 設定を記述するカスタムリソース (CR) を入力します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: 50-worker-fix-ipi-rwn
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/kubernetes/manifests/keepalived.yaml
              mode: 0644
              contents:
                source: data:,

    このマニフェストは、ingressVIP 仮想 IP アドレスをコントロールプレーンノードに配置します。また、このマニフェストは、コントロールプレーンノードにのみ以下のプロセスをデプロイします。

    • openshift-ingress-operator
    • keepalived
  5. cluster-network-avoid-workers-99-config.yaml ファイルを保存します。
  6. manifests/cluster-ingress-default-ingresscontroller.yaml ファイルを作成します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      nodePlacement:
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/master: ""
  7. manifests ディレクトリーのバックアップの作成を検討してください。インストーラーは、クラスターの作成時に manifests/ ディレクトリーを削除します。
  8. cluster-scheduler-02-config.yml マニフェストを変更し、mastersSchedulable フィールドを true に設定して、コントロールプレーンノードをスケジュール対象にします。デフォルトでは、コントロールプレーンノードはスケジュール対象ではありません。以下に例を示します。

    $ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml
    注記

    この手順の完了後にコントロールプレーンノードをスケジュールできない場合には、クラスターのデプロイに失敗します。

2.5.14. 次のステップ

2.6. ネットワークが制限された環境での vSphere へのクラスターのインストール

OpenShift Container Platform 4.16 では、インストールリリースコンテンツの内部ミラーを作成して、制限されたネットワーク内の VMware vSphere インフラストラクチャーにクラスターをインストールできます。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

2.6.1. 前提条件

  • installer-provisioned infrastructure を使用したクラスターのインストールの準備 のタスクを完了した。
  • VMware プラットフォームのライセンスを確認した。Red Hat は VMware ライセンスに制限を設けていませんが、一部の VMware インフラストラクチャーコンポーネントにはライセンスが必要です。
  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
  • クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
  • ミラーホストでレジストリーを作成 しており、使用しているバージョンの OpenShift Container Platform の imageContentSources データを取得している。

    重要

    インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。

  • クラスターの 永続ストレージ をプロビジョニングした。プライベートイメージレジストリーをデプロイするには、ストレージで ReadWriteMany アクセスモードを指定する必要があります。
  • OpenShift Container Platform インストーラーは、vCenter および ESXi ホストのポート 443 にアクセスできる必要があります。ポート 443 にアクセスできることを確認している。
  • ファイアウォールを使用する場合は、ポート 443 にアクセスできることを管理者に確認している。インストールを成功させるには、コントロールプレーンノードがポート 443 で vCenter および ESXi ホストに到達できる必要があります。
  • クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。

    注記

    プロキシーを設定する場合は、このサイトリストも確認してください。

2.6.2. ネットワークが制限された環境でのインストールについて

OpenShift Container Platform 4.16 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、installer-provisioned infrastructure または user-provisioned infrastructure を使用して実行できます。

クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。

ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。

2.6.2.1. その他の制限

ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。

  • ClusterVersion ステータスには Unable to retrieve available updates エラーが含まれます。
  • デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。

2.6.3. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。

2.6.4. ネットワークが制限されたインストール用の RHCOS イメージの作成

Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードし、OpenShift Container Platform をネットワークが制限された VMware vSphere 環境にインストールします。

前提条件

  • OpenShift Container Platform インストールプログラムを取得します。ネットワークが制限されたインストールでは、プログラムはミラーレジストリースト上に置かれます。

手順

  1. Red Hat カスタマーポータルの 製品ダウンロードページ にログインします。
  2. Version で、RHEL 8 用の OpenShift Container Platform 4.16 の最新リリースを選択します。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

  3. Red Hat Enterprise Linux CoreOS (RHCOS) - vSphere イメージをダウンロードします。
  4. ダウンロードしたイメージを、bastion サーバーからアクセス可能な場所にアップロードします。

これで、イメージが制限されたインストールで利用可能になります。OpenShift Container Platform デプロイメントで使用するイメージの名前または場所をメモします。

2.6.5. VMware vSphere のリージョンとゾーンの有効化

OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

重要

VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。

デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。

次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。

  • 障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
  • リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。
  • ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。
注記

install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。

リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。

次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。

データセンター (リージョン)クラスター (ゾーン)タグ

米国東部

us-east-1

us-east-1a

us-east-1b

us-east-2

us-east-2a

us-east-2b

us-west

us-west-1

us-west-1a

us-west-1b

us-west-2

us-west-2a

us-west-2b

2.6.6. インストール設定ファイルの作成

VMware vSphere にインストールする OpenShift Container Platform クラスターをカスタマイズできます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
  • ミラーレジストリーの作成時に生成された imageContentSources 値がある。
  • ミラーレジストリーの証明書の内容を取得している。
  • Red Hat Enterprise Linux CoreOS (RHCOS) イメージを取得し、アクセス可能な場所にアップロードしました。

手順

  1. install-config.yaml ファイルを作成します。

    1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

      $ ./openshift-install create install-config --dir <installation_directory> 1
      1
      <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。

      ディレクトリーを指定する場合:

      • ディレクトリーに execute 権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。
      • 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
    2. プロンプト時に、クラウドの設定の詳細情報を指定します。

      1. オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。

        注記

        インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

      2. ターゲットに設定するプラットフォームとして vsphere を選択します。
      3. vCenter インスタンスの名前を指定します。
      4. クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。

        インストールプログラムは vCenter インスタンスに接続します。

      5. 接続する vCenter インスタンスのデータセンターを選択します。

        注記

        インストール設定ファイルを作成した後、そのファイルを変更して複数の vSphere データセンター環境を作成できます。これは、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできることを意味します。この環境の作成の詳細は、VMware vSphere のリージョンとゾーンの有効化 を参照してください。

      6. 使用するデフォルトの vCenter データストアを選択します。

        警告

        データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion を使用する Storage Distributed Resource Scheduler (SDRS) がデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage DRS を無効にする必要があります。

        複数のデータストアパスを指定することはできません。複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

      7. OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
      8. 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
      9. コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
      10. クラスター Ingress に設定した仮想 IP アドレスを入力します。
      11. ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
      12. クラスターの記述名を入力します。

        入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。

  2. install-config.yaml ファイルで platform.vsphere.clusterOSImage の値をイメージの場所または名前に設定します。以下に例を示します。

    platform:
      vsphere:
          clusterOSImage: http://mirror.example.com/images/rhcos-43.81.201912131630.0-vmware.x86_64.ova?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d
  3. install-config.yaml ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。

    1. pullSecret の値を更新して、レジストリーの認証情報を追加します。

      pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'

      <mirror_host_name> の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials> の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

    2. additionalTrustBundle パラメーターおよび値を追加します。

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
        -----END CERTIFICATE-----

      この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。

    3. 次の YAML の抜粋のようなイメージコンテンツリソースを追加します。

      imageContentSources:
      - mirrors:
        - <mirror_host_name>:5000/<repo_name>/release
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - <mirror_host_name>:5000/<repo_name>/release
        source: registry.redhat.io/ocp/release

      これらの値には、ミラーレジストリーの作成時に記録された imageContentSources を使用します。

    4. オプション: パブリッシュストラテジーを Internal に設定します。

      publish: Internal

      このオプションを設定すると、内部 Ingress コントローラーおよびプライベートロードバランサーを作成します。

  4. 必要な install-config.yaml ファイルに他の変更を加えます。

    パラメーターの詳細は、「インストール設定パラメーター」を参照してください。

  5. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。

2.6.6.1. installer-provisioned VMware vSphere クラスターの install-config.yaml ファイルのサンプル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name:  <worker_node>
  platform: {}
  replicas: 3
controlPlane: 3
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3
metadata:
  creationTimestamp: null
  name: test 4
platform:
  vsphere: 5
    apiVIPs:
      - 10.0.0.1
    failureDomains: 6
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<data_center>/host/<cluster>"
        datacenter: <data_center>
        datastore: "/<data_center>/datastore/<datastore>" 7
        networks:
        - <VM_Network_name>
        resourcePool: "/<data_center>/host/<cluster>/Resources/<resourcePool>" 8
        folder: "/<data_center_name>/vm/<folder_name>/<subfolder_name>"
        tagIDs: 9
        - <tag_id>  10
      zone: <default_zone_name>
    ingressVIPs:
    - 10.0.0.2
    vcenters:
    - datacenters:
      - <data_center>
      password: <password>
      port: 443
      server: <fully_qualified_domain_name>
      user: administrator@vsphere.local
    diskType: thin 11
    clusterOSImage: http://mirror.example.com/images/rhcos-47.83.202103221318-0-vmware.x86_64.ova 12
fips: false
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 13
sshKey: 'ssh-ed25519 AAAA...'
additionalTrustBundle: | 14
  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources: 15
- mirrors:
  - <mirror_host_name>:<mirror_port>/<repo_name>/release
  source: <source_image_1>
- mirrors:
  - <mirror_host_name>:<mirror_port>/<repo_name>/release-images
  source: <source_image_2>
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 3
controlPlane セクションは単一マッピングですが、compute セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。
4
DNS レコードに指定したクラスター名。
5
オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
6
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
7
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。

複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

8
オプション: マシン作成用の既存のリソースプールを提供します。値を指定しない場合、インストールプログラムは vSphere クラスターのルートリソースプールを使用します。
9
オプション: OpenShift Container Platform によって作成された各仮想マシンには、クラスターに固有の一意のタグが割り当てられます。割り当てられたタグにより、クラスターの使用停止時に、関連付けられた仮想マシンをインストールプログラムが識別して削除できるようになります。インストールプログラムによってプロビジョニングされた仮想マシンに割り当てる追加のタグ ID を最大 10 個までリストできます。
10
インストールプログラムによって関連付けられるタグの ID。たとえば、urn:vmomi:InventoryServiceTag:208e713c-cae3-4b7f-918e-4051ca7d1f97:GLOBAL です。タグ ID の決定の詳細は、vSphere Tags and Attributes ドキュメントを参照してください。
11
vSphere ディスクのプロビジョニング方法。
12
bastion サーバーからアクセス可能な Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所。
13
<local_registry> には、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000<credentials> に、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。
14
ミラーレジストリーに使用した証明書ファイルの内容を指定します。
15
リポジトリーのミラーリングに使用するコマンドの出力の imageContentSources セクションを指定します。
注記

OpenShift Container Platform 4.12 以降では、apiVIP および ingressVIP 設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs および ingressVIPs 設定に値を入力します。

2.6.6.2. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは 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
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

2.6.6.3. VMware vCenter のリージョンとゾーンの設定

デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。

OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。

重要

この例では、govc コマンドを使用します。govc コマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは govc コマンドを保守していません。govc のダウンロードとインストールの手順は、VMware ドキュメント Web サイトを参照してください。

前提条件

  • 既存の install-config.yaml インストール設定ファイルがあります。

    重要

    VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

手順

  1. 次の govc コマンドラインツールコマンドを入力して、openshift-region および openshift-zone vCenter タグカテゴリーを作成します。

    重要

    openshift-region および openshift-zone vCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。

    $ govc tags.category.create -d "OpenShift region" openshift-region
    $ govc tags.category.create -d "OpenShift zone" openshift-zone
  2. クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。

    $ govc tags.create -c <region_tag_category> <region_tag>
  3. クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。

    $ govc tags.create -c <zone_tag_category> <zone_tag>
  4. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにリージョンタグをアタッチします。

    $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>
  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
  6. インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。

vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル

---
compute:
---
  vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
controlPlane:
---
vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
platform:
  vsphere:
    vcenters:
---
    datacenters:
      - <data_center_1_name>
      - <data_center_2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_1>
        computeCluster: "/<data_center_1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<data_center_1>/datastore/<datastore1>"
        resourcePool: "/<data_center_1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<data_center_1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_2>
        computeCluster: "/<data_center_2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<data_center_2>/datastore/<datastore2>"
        resourcePool: "/<data_center_2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<data_center_2>/vm/<folder2>"
---

2.6.7. ユーザー管理ロードバランサーのサービス

デフォルトのロードバランサーの代わりに、ユーザーが管理するロードバランサーを使用するように OpenShift Container Platform クラスターを設定できます。

重要

ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。

このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。

Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。

  • Ingress Controller
  • OpenShift API
  • OpenShift MachineConfig API

ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。

図2.7 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する Ingress Controller のネットワークワークフローの例を示すイメージ。

図2.8 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例

OpenShift Container Platform 環境で動作する OpenShift API のネットワークワークフローの例を示すイメージ。

図2.9 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例

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 が未定義のノードに移動すると、接続が停止する可能性があります。
2.6.7.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 を指定して設定できまうs.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

Machine Config API ヘルスチェック仕様の例

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

手順

  1. HAProxy Ingress Controller を設定して、ポート 6443、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。

    1 つのサブネットをリストした HAProxy 設定の例

    # ...
    listen my-cluster-api-6443
        bind 192.168.1.100:6443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /readyz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
    
    listen my-cluster-machine-config-api-22623
        bind 192.168.1.100:22623
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz
      http-check expect status 200
        server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
        server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
    
    listen my-cluster-apps-443
        bind 192.168.1.100:443
        mode tcp
        balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
    
    listen my-cluster-apps-80
       bind 192.168.1.100:80
       mode tcp
       balance roundrobin
      option httpchk
      http-check connect
      http-check send meth GET uri /healthz/ready
      http-check expect status 200
        server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
        server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
    # ...

    複数のサブネットをリストした HAProxy 設定の例

    # ...
    listen api-server-6443
        bind *:6443
        mode tcp
          server master-00 192.168.83.89:6443 check inter 1s
          server master-01 192.168.84.90:6443 check inter 1s
          server master-02 192.168.85.99:6443 check inter 1s
          server bootstrap 192.168.80.89:6443 check inter 1s
    
    listen machine-config-server-22623
        bind *:22623
        mode tcp
          server master-00 192.168.83.89:22623 check inter 1s
          server master-01 192.168.84.90:22623 check inter 1s
          server master-02 192.168.85.99:22623 check inter 1s
          server bootstrap 192.168.80.89:22623 check inter 1s
    
    listen ingress-router-80
        bind *:80
        mode tcp
        balance source
          server worker-00 192.168.83.100:80 check inter 1s
          server worker-01 192.168.83.101:80 check inter 1s
    
    listen ingress-router-443
        bind *:443
        mode tcp
        balance source
          server worker-00 192.168.83.100:443 check inter 1s
          server worker-01 192.168.83.101:443 check inter 1s
    
    listen ironic-api-6385
        bind *:6385
        mode tcp
        balance source
          server master-00 192.168.83.89:6385 check inter 1s
          server master-01 192.168.84.90:6385 check inter 1s
          server master-02 192.168.85.99:6385 check inter 1s
          server bootstrap 192.168.80.89:6385 check inter 1s
    
    listen inspector-api-5050
        bind *:5050
        mode tcp
        balance source
          server master-00 192.168.83.89:5050 check inter 1s
          server master-01 192.168.84.90:5050 check inter 1s
          server master-02 192.168.85.99:5050 check inter 1s
          server bootstrap 192.168.80.89:5050 check inter 1s
    # ...

  2. curl CLI コマンドを使用して、ユーザー管理ロードバランサーとそのリソースが動作していることを確認します。

    1. 次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache
    4. 次のコマンドを実行して出力を確認し、コントローラーがポート 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>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
  3. ユーザー管理ロードバランサーのフロントエンド 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 apps.<cluster_name>.<base_domain>
    A record pointing to Load Balancer Front End
    重要

    DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。

  4. OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの install-config.yaml ファイルで次の設定を指定する必要があります。

    # ...
    platform:
      vsphere:
        loadBalancer:
          type: UserManaged 1
          apiVIPs:
          - <api_ip> 2
          ingressVIPs:
          - <ingress_ip> 3
    # ...
    1
    クラスターのユーザー管理ロードバランサーを指定するには、type パラメーターに UserManaged を設定します。パラメーターのデフォルトは OpenShiftManagedDefault で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra namespace で定義されたサービスの場合、ユーザー管理ロードバランサーは coredns サービスをクラスター内の Pod にデプロイできますが、keepalived および haproxy サービスは無視します。
    2
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
    3
    ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。

検証

  1. curl CLI コマンドを使用して、ユーザー管理ロードバランサーと DNS レコード設定が動作していることを確認します。

    1. 次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }
    2. 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0
    3. 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private
    4. 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

2.6.8. クラスターのデプロイ

互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。

重要

インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。

前提条件

  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
  • ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることが確認されました。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
  • オプション: クラスターを作成する前に、デフォルトのロードバランサーの代わりに外部ロードバランサーを設定します。

    重要

    インストールプログラムに API および Ingress 静的アドレスを指定する必要はありません。この設定を選択した場合は、追加のアクションを実行して、参照される各 vSphere サブネットから IP アドレスを受け入れるネットワークターゲットを定義する必要があります。「ユーザー管理ロードバランサーの設定」セクションを参照してください。

手順

  • インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。

    $ ./openshift-install create cluster --dir <installation_directory> \ 1
        --log-level=info 2
    1
    <installation_directory> に、カスタマイズした ./install-config.yaml ファイルの場所を指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

検証

クラスターのデプロイが正常に完了すると、次のようになります。

  • ターミナルには、Web コンソールへのリンクや kubeadmin ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。
  • 認証情報は <installation_directory>/.openshift_install.log にも出力されます。
重要

インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。

出力例

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

重要
  • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
  • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

2.6.9. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

2.6.10. デフォルトの OperatorHub カタログソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。

手順

  • disableAllDefaultSources: trueOperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。AdministrationCluster SettingsConfigurationOperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。

2.6.11. レジストリーストレージの作成

クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。

2.6.11.1. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、Image Registry Operator 設定を編集して managementStateRemoved から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。

2.6.11.2. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

2.6.11.2.1. VMware vSphere のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • VMware vSphere 上のクラスター。
  • Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • "100Gi" の容量が必要です。
重要

テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリックストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim: 1

    1
    image-registry-storage 永続ボリューム要求 (PVC) の自動作成を許可するには、claim フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION                              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.7                                  True        False         False      6h50m

2.6.12. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

2.6.13. 次のステップ

第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.16 ではデフォルトで有効になっています。

VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。

表3.1 vSphere 仮想環境のバージョン要件
仮想環境製品必須バージョン

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

表3.2 VMware コンポーネントのサポートされる vSphere の最小バージョン
コンポーネントサポートされる最小バージョン説明

ハイパーバイザー

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 Customer Portal の ハードウェア を参照してください。

オプション: 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 4.13 以降では、マイクロアーキテクチャーの要件が x86-64-v2 に発生する RHEL 9.2 ホストオペレーティングシステムをベースにしています。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

常時

Cns.Searchable
InventoryService.Tagging.AttachTag
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.DeleteCategory
InventoryService.Tagging.DeleteTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
Sessions.ValidateSession
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

仮想マシンがクラスタールートに作成される場合

Host.Config.Storage
Resource.AssignVMToPool
VApp.AssignResourcePool
VApp.Import
VirtualMachine.Config.AddNewDisk

vSphere vCenter リソースプール

既存のリソースプールが提供されている場合

Resource.AssignVMToPool
VApp.AssignResourcePool
VApp.Import
VirtualMachine.Config.AddNewDisk

vSphere データストア

常時

Datastore.AllocateSpace
Datastore.Browse
Datastore.FileManagement
InventoryService.Tagging.ObjectAttachable

vSphere ポートグループ

常時

Network.Assign

仮想マシンフォルダー

常時

InventoryService.Tagging.ObjectAttachable
Resource.AssignVMToPool
VApp.Import
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddNewDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.DiskLease
VirtualMachine.Config.EditDevice
VirtualMachine.Config.Memory
VirtualMachine.Config.RemoveDisk
VirtualMachine.Config.Rename
Host.Config.Storage
VirtualMachine.Config.ResetGuestInfo
VirtualMachine.Config.Resource
VirtualMachine.Config.Settings
VirtualMachine.Config.UpgradeVirtualHardware
VirtualMachine.Interact.GuestControl
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Inventory.Create
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.MarkAsTemplate
VirtualMachine.Provisioning.DeployTemplate

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。「Machine API の最小権限」の表を参照してください。

InventoryService.Tagging.ObjectAttachable
Resource.AssignVMToPool
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddNewDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.DiskLease
VirtualMachine.Config.EditDevice
VirtualMachine.Config.Memory
VirtualMachine.Config.RemoveDisk
VirtualMachine.Config.Rename
VirtualMachine.Config.ResetGuestInfo
VirtualMachine.Config.Resource
VirtualMachine.Config.Settings
VirtualMachine.Config.UpgradeVirtualHardware
VirtualMachine.Interact.GuestControl
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Inventory.Create
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.DeployTemplate
VirtualMachine.Provisioning.MarkAsTemplate
Folder.Create
Folder.Delete

例3.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限

ロールの vSphere オブジェクト必要になる場合vCenter GUI で必要な権限

vSphere vCenter

常時

Cns.Searchable
"vSphere Tagging"."Assign or Unassign vSphere Tag"
"vSphere Tagging"."Create vSphere Tag Category"
"vSphere Tagging"."Create vSphere Tag"
vSphere Tagging"."Delete vSphere Tag Category"
"vSphere Tagging"."Delete vSphere Tag"
"vSphere Tagging"."Edit vSphere Tag Category"
"vSphere Tagging"."Edit vSphere Tag"
Sessions."Validate session"
"Profile-driven storage"."Profile-driven storage update"
"Profile-driven storage"."Profile-driven storage view"

vSphere vCenter Cluster

仮想マシンがクラスタールートに作成される場合

Host.Configuration."Storage partition configuration"
Resource."Assign virtual machine to resource pool"
VApp."Assign resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add new disk"

vSphere vCenter リソースプール

既存のリソースプールが提供されている場合

Host.Configuration."Storage partition configuration"
Resource."Assign virtual machine to resource pool"
VApp."Assign resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add new disk"

vSphere データストア

常時

Datastore."Allocate space"
Datastore."Browse datastore"
Datastore."Low level file operations"
"vSphere Tagging"."Assign or Unassign vSphere Tag on Object"

vSphere ポートグループ

常時

Network."Assign network"

仮想マシンフォルダー

常時

"vSphere Tagging"."Assign or Unassign vSphere Tag on Object"
Resource."Assign virtual machine to resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add existing disk"
"Virtual machine"."Change Configuration"."Add new disk"
"Virtual machine"."Change Configuration"."Add or remove device"
"Virtual machine"."Change Configuration"."Advanced configuration"
"Virtual machine"."Change Configuration"."Set annotation"
"Virtual machine"."Change Configuration"."Change CPU count"
"Virtual machine"."Change Configuration"."Extend virtual disk"
"Virtual machine"."Change Configuration"."Acquire disk lease"
"Virtual machine"."Change Configuration"."Modify device settings"
"Virtual machine"."Change Configuration"."Change Memory"
"Virtual machine"."Change Configuration"."Remove disk"
"Virtual machine"."Change Configuration".Rename
"Virtual machine"."Change Configuration"."Reset guest information"
"Virtual machine"."Change Configuration"."Change resource"
"Virtual machine"."Change Configuration"."Change Settings"
"Virtual machine"."Change Configuration"."Upgrade virtual machine compatibility"
"Virtual machine".Interaction."Guest operating system management by VIX API"
"Virtual machine".Interaction."Power off"
"Virtual machine".Interaction."Power on"
"Virtual machine".Interaction.Reset
"Virtual machine"."Edit Inventory"."Create new"
"Virtual machine"."Edit Inventory"."Create from existing"
"Virtual machine"."Edit Inventory"."Remove"
"Virtual machine".Provisioning."Clone virtual machine"
"Virtual machine".Provisioning."Mark as template"
"Virtual machine".Provisioning."Deploy template"

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。

"vSphere Tagging"."Assign or Unassign vSphere Tag on Object"
Resource."Assign virtual machine to resource pool"
VApp.Import
"Virtual machine"."Change Configuration"."Add existing disk"
"Virtual machine"."Change Configuration"."Add new disk"
"Virtual machine"."Change Configuration"."Add or remove device"
"Virtual machine"."Change Configuration"."Advanced configuration"
"Virtual machine"."Change Configuration"."Set annotation"
"Virtual machine"."Change Configuration"."Change CPU count"
"Virtual machine"."Change Configuration"."Extend virtual disk"
"Virtual machine"."Change Configuration"."Acquire disk lease"
"Virtual machine"."Change Configuration"."Modify device settings"
"Virtual machine"."Change Configuration"."Change Memory"
"Virtual machine"."Change Configuration"."Remove disk"
"Virtual machine"."Change Configuration".Rename
"Virtual machine"."Change Configuration"."Reset guest information"
"Virtual machine"."Change Configuration"."Change resource"
"Virtual machine"."Change Configuration"."Change Settings"
"Virtual machine"."Change Configuration"."Upgrade virtual machine compatibility"
"Virtual machine".Interaction."Guest operating system management by VIX API"
"Virtual machine".Interaction."Power off"
"Virtual machine".Interaction."Power on"
"Virtual machine".Interaction.Reset
"Virtual machine"."Edit Inventory"."Create new"
"Virtual machine"."Edit Inventory"."Create from existing"
"Virtual machine"."Edit Inventory"."Remove"
"Virtual machine".Provisioning."Clone virtual machine"
"Virtual machine".Provisioning."Deploy template"
"Virtual machine".Provisioning."Mark as template"
Folder."Create folder"
Folder."Delete folder"

また、ユーザーには一部の ReadOnly パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。

例3.3 必要なパーミッションおよび伝播の設定

vSphere オブジェクト必要になる場合子への伝播パーミッションが必要

vSphere vCenter

常時

False

リスト表示された必要な特権

vSphere vCenter data center

既存のフォルダー

False

ReadOnly パーミッション

インストールプログラムがフォルダーを作成する

True

リスト表示された必要な特権

vSphere vCenter Cluster

既存のリソースプール

False

ReadOnly パーミッション

クラスタールートの仮想マシン

True

リスト表示された必要な特権

vSphere vCenter datastore

常時

False

リスト表示された必要な特権

vSphere Switch

常時

False

ReadOnly パーミッション

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 ロールの特権を継承するだけで済むことに注意してください。

グローバル管理者の特権を持つアカウントがニーズに合わない場合は、カスタムロールの作成を検討してください。

重要

必要な特権が設定されていないアカウントはサポートされません。vCenter への OpenShift Container Platform クラスターのインストールは、「必要な vCenter アカウントの特権」セクションで説明されているすべての特権のリストに対してテストされています。このすべての権限のリストに準拠することで、制限された特権セットを持つカスタムロールの作成時に予期しない動作が発生する可能性を抑制できます。

以下の表に、特定の OpenShift Container Platform アーキテクチャーと対話する vSphere オブジェクトの最小権限のリストを示します。

例3.4 コンポーネントのインストール後の管理のための最小権限

ロールの vSphere オブジェクト必要になる場合必要な特権

vSphere vCenter

常時

Cns.Searchable
InventoryService.Tagging.AttachTag
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.DeleteCategory
InventoryService.Tagging.DeleteTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
Sessions.ValidateSession
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

クラスタールートに仮想マシンを作成する場合

Host.Config.Storage
Resource.AssignVMToPool

vSphere vCenter リソースプール

install-config.yaml ファイルに既存のリソースプールを指定する場合

Host.Config.Storage

vSphere データストア

常時

Datastore.AllocateSpace
Datastore.Browse
Datastore.FileManagement
InventoryService.Tagging.ObjectAttachable

vSphere ポートグループ

常時

Network.Assign

仮想マシンフォルダー

常時

VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.Memory
VirtualMachine.Config.Settings
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.DeployTemplate

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。クラスターで Machine API を使用しており、API の最小権限セットを設定する必要がある場合は、「Machine API の最小権限」の表を参照してください。

Resource.AssignVMToPool
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Provisioning.DeployTemplate

例3.5 ストレージコンポーネントの最小権限

ロールの vSphere オブジェクト必要になる場合必要な特権

vSphere vCenter

常時

Cns.Searchable
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

クラスタールートに仮想マシンを作成する場合

Host.Config.Storage

vSphere vCenter リソースプール

install-config.yaml ファイルに既存のリソースプールを指定する場合

Host.Config.Storage

vSphere データストア

常時

Datastore.Browse
Datastore.FileManagement
InventoryService.Tagging.ObjectAttachable

vSphere ポートグループ

常時

Read-Only

仮想マシンフォルダー

常時

VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。クラスターで Machine API を使用しており、API の最小権限セットを設定する必要がある場合は、「Machine API の最小権限」の表を参照してください。

VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddRemoveDevice

例3.6 Machine API の最小権限

ロールの vSphere オブジェクト必要になる場合必要な特権

vSphere vCenter

常時

InventoryService.Tagging.AttachTag
InventoryService.Tagging.CreateCategory
InventoryService.Tagging.CreateTag
InventoryService.Tagging.DeleteCategory
InventoryService.Tagging.DeleteTag
InventoryService.Tagging.EditCategory
InventoryService.Tagging.EditTag
Sessions.ValidateSession
StorageProfile.Update
StorageProfile.View

vSphere vCenter Cluster

クラスタールートに仮想マシンを作成する場合

Resource.AssignVMToPool

vSphere vCenter リソースプール

install-config.yaml ファイルに既存のリソースプールを指定する場合

Read-Only

vSphere データストア

常時

Datastore.AllocateSpace
Datastore.Browse

vSphere ポートグループ

常時

Network.Assign

仮想マシンフォルダー

常時

VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.AdvancedConfig
VirtualMachine.Config.Annotation
VirtualMachine.Config.CPUCount
VirtualMachine.Config.DiskExtend
VirtualMachine.Config.Memory
VirtualMachine.Config.Settings
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Inventory.CreateFromExisting
VirtualMachine.Inventory.Delete
VirtualMachine.Provisioning.Clone
VirtualMachine.Provisioning.DeployTemplate

vSphere vCenter data center

インストールプログラムが仮想マシンフォルダーを作成する場合。user-provisioned infrastructure の場合、クラスターで Machine API を使用しないのであれば、VirtualMachine.Inventory.Create 権限と VirtualMachine.Inventory.Delete 権限は任意です。

Resource.AssignVMToPool
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Provisioning.DeployTemplate

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 は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。

    重要

    データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion を使用する Storage Distributed Resource Scheduler (SDRS) がデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage DRS を無効にする必要があります。

    複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「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>. の形式を取ります。

表3.3 必要な DNS レコード
コンポーネントレコード説明

API VIP

api.<cluster_name>.<base_domain>.

この DNS A/AAAA または CNAME (Canonical Name) レコードは、コントロールプレーンマシンのロードバランサーを参照する必要があります。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

Ingress VIP

*.apps.<cluster_name>.<base_domain>.

Ingress ルーター Pod を実行するマシンをターゲットにするロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

3.1.3.2. クラスターのインストールに必要なマシン

最小の OpenShift Container Platform クラスターでは以下のホストが必要です。

表3.4 最低限必要なホスト
ホスト説明

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. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表3.5 最小リソース要件
マシンオペレーティングシステム仮想 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

  1. OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
  2. すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (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.16 をインストールする前に、仮想マシンを暗号化できます。

  • vSphere で標準キープロバイダーを設定しました。詳細は、vCenter Server への KMS の追加 を参照してください。

    重要

    vCenter のネイティブキープロバイダーはサポートされていません。詳細は、vSphere Native Key Provider の概要 を参照してください。

  • クラスターをホスティングしているすべての ESXi ホストでホスト暗号化モードを有効にしました。詳細は、ホスト暗号化モードの有効化 を参照してください。
  • すべての暗号化権限が有効になっている vSphere アカウントがあります。詳細は、暗号化操作の権限 を参照してください。

「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 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。

表3.6 すべてのマシンからすべてのマシンへの通信に使用されるポート
プロトコルポート説明

ICMP

該当なし

ネットワーク到達性のテスト

TCP

1936

メトリック

9000-9999

ホストレベルのサービス。 ポート 9100-9101 のノードエクスポーター、ポート 9099 の Cluster Version Operator が含まれます。

10250-10259

Kubernetes が予約するデフォルトポート

UDP

4789

VXLAN

6081

Geneve

9000-9999

ポート 9100-9101 のノードエクスポーターを含む、ホストレベルのサービス。

500

IPsec IKE パケット

4500

IPsec NAT-T パケット

123

UDP ポート 123 のネットワークタイムプロトコル (NTP)

外部 NTP タイムサーバーが設定されている場合は、UDP ポート 123 を開く必要があります。

TCP/UDP

30000-32767

Kubernetes ノードポート

ESP

該当なし

IPsec Encapsulating Security Payload (ESP)

表3.7 すべてのマシンからコントロールプレーンへの通信に使用されるポート
プロトコルポート説明

TCP

6443

Kubernetes API

表3.8 コントロールプレーンマシンからコントロールプレーンマシンへの通信に使用されるポート
プロトコルポート説明

TCP

2379-2380

etcd サーバーおよびピアポート

Ethernet アダプターのハードウェアアドレス要件

クラスターの仮想マシンをプロビジョニングする場合、各仮想マシンに設定されたイーサネットインターフェイスは VMware Organizationally Unique Identifier (OUI) 割り当て範囲から MAC アドレスを使用する必要があります。

  • 00:05:69:00:00:00 - 00:05:69:FF:FF:FF
  • 00:0c:29:00:00:00 - 00:0c:29:FF:FF:FF
  • 00:1c:14:00:00:00 - 00:1c:14:FF:FF:FF
  • 00:50:56:00:00:00 to 00:50:56:3F:FF:FF

VMware OUI 外の MAC アドレスが使用される場合、クラスターのインストールは成功しません。

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>. の形式を取ります。

表3.9 必要な DNS レコード
コンポーネントレコード説明

Kubernetes API

api.<cluster_name>.<base_domain>.

API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

api-int.<cluster_name>.<base_domain>.

API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。

重要

API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。

ルート

*.apps.<cluster_name>.<base_domain>.

アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

たとえば、console-openshift-console.apps.<cluster_name>.<base_domain> は、OpenShift Container Platform コンソールへのワイルドカードルートとして使用されます。

ブートストラップマシン

bootstrap.<cluster_name>.<base_domain>.

ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。

コントロールプレーンマシン

<control_plane><n>.<cluster_name>.<base_domain>.

ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコードこれらのレコードは、クラスター内のノードで解決できる必要があります。

コンピュートマシン

<compute><n>.<cluster_name>.<base_domain>.

ワーカーノードの各マシンを特定するための 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 ゾーンデータベースのサンプル

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 1
api-int.ocp4.example.com.	IN	A	192.168.1.5 2
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 3
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 4
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 5
control-plane1.ocp4.example.com.	IN	A	192.168.1.98 6
control-plane2.ocp4.example.com.	IN	A	192.168.1.99 7
;
compute0.ocp4.example.com.	IN	A	192.168.1.11 8
compute1.ocp4.example.com.	IN	A	192.168.1.7 9
;
;EOF
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 ゾーンデータベースの例

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. 1
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 2
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. 3
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. 4
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com. 5
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 6
;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 7
7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 8
;
;EOF
1
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照します。
2
Kubernetes API の逆引き DNS 解決を提供します。PTR レコードは、API ロードバランサーのレコード名を参照し、内部クラスター通信に使用されます。
3
ブートストラップマシンの逆引き DNS 解決を提供します。
4 5 6
コントロールプレーンマシンの逆引き DNS 解決を提供します。
7 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 およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。

負荷分散インフラストラクチャーは以下の要件を満たす必要があります。

  1. API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
    • ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
    重要

    API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表3.10 API ロードバランサー
    ポートバックエンドマシン (プールメンバー)内部外部説明

    6443

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの /readyz エンドポイントを設定する必要があります。

    X

    X

    Kubernetes API サーバー

    22623

    ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。

    X

     

    マシン設定サーバー

    注記

    ロードバランサーは、API サーバーが /readyz エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。

  2. Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。

    以下の条件を設定します。

    • Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
    • 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
    ヒント

    クライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。

    ロードバランサーのフロントとバックの両方で以下のポートを設定します。

    表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 ロードバランサーの設定例

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443 1
  bind *:6443
  mode tcp
  option  httpchk GET /readyz HTTP/1.0
  option  log-health-checks
  balance roundrobin
  server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup 2
  server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
  server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623 3
  bind *:22623
  mode tcp
  server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 4
  server master0 master0.ocp4.example.com:22623 check inter 1s
  server master1 master1.ocp4.example.com:22623 check inter 1s
  server master2 master2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 5
  bind *:443
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:443 check inter 1s
  server compute1 compute1.ocp4.example.com:443 check inter 1s
listen ingress-router-80 6
  bind *:80
  mode tcp
  balance source
  server compute0 compute0.ocp4.example.com:80 check inter 1s
  server compute1 compute1.ocp4.example.com:80 check inter 1s
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 を実行して、ポート 644322623443、および 80haproxy プロセスがリッスンしていることを確認することができます。

3.2. user-provisioned infrastructure を使用したクラスターのインストールの準備

以下の手順を実行して、vSphere に OpenShift Container Platform クラスターをインストールする準備をします。

  • インストールプログラムをダウンロードします。

    注記

    非接続環境にインストールする場合は、ミラーリングしたコンテンツからインストールプログラムを抽出します。詳細は、非接続インストール用のイメージのミラーリング を参照してください。

  • OpenShift CLI (oc) をインストールします。

    注記

    非接続環境にインストールする場合は、ミラーホストに oc をインストールします。

  • SSH キーペアを生成します。OpenShift Container Platform クラスターのデプロイ後にこのキーペアを使用して、クラスターのノードに対する認証を行うことができます。
  • user-provisioned infrastructure を準備します。
  • DNS 解決を検証します。

3.2.1. インストールプログラムの取得

OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。

前提条件

  • Linux または macOS を実行し、少なくとも 1.2 GB のローカルディスク容量を備えたコンピューターがある。

手順

  1. Red Hat Hybrid Cloud Console の Cluster Type ページに移動します。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
  2. ページの Run it yourself セクションからインフラストラクチャープロバイダーを選択します。
  3. OpenShift Installer のドロップダウンメニューからホストオペレーティングシステムとアーキテクチャーを選択し、Download Installer をクリックします。
  4. ダウンロードしたファイルを、インストール設定ファイルを保存するディレクトリーに配置します。

    重要
    • インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。クラスターを削除するには、両方のファイルが必要です。
    • インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
  5. インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar -xvf openshift-install-linux.tar.gz
  6. Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
ヒント

Red Hat カスタマーポータル からインストールプログラムを取得することもできます。このページでは、ダウンロードするインストールプログラムのバージョンを指定できます。ただし、このページにアクセスするには、有効なサブスクリプションが必要です。

3.2.2. OpenShift CLI のインストール

コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために OpenShift CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.16 のすべてのコマンドを実行することはできません。新しいバージョンの oc をダウンロードしてインストールしてください。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
  3. バージョン ドロップダウンリストから適切なバージョンを選択します。
  4. OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  5. アーカイブを展開します。

    $ tar xvf <file>
  6. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    $ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.16 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを展開します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

検証

  • OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

    C:\> oc <command>
macOS への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. バージョン ドロップダウンリストから適切なバージョンを選択します。
  3. OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

    注記

    macOS arm64 の場合は、OpenShift v4.16 macOS arm64 Client エントリーを選択します。

  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

検証

  • oc コマンドを使用してインストールを確認します。

    $ oc <command>

3.2.3. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。

重要

障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。

注記

AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。

手順

  1. クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
    1
    新しい SSH キーのパスとファイル名 (~/.ssh/id_ed25519 など) を指定します。既存のキーペアがある場合は、公開鍵が ~/.ssh ディレクトリーにあることを確認します。
    注記

    x86_64ppc64le、および s390x アーキテクチャーのみで FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用する OpenShift Container Platform クラスターをインストールする予定がある場合は、ed25519 アルゴリズムを使用するキーを作成しないでください。代わりに、rsa アルゴリズムまたは ecdsa アルゴリズムを使用するキーを作成します。

  2. 公開 SSH キーを表示します。

    $ cat <path>/<file_name>.pub

    たとえば、次のコマンドを実行して ~/.ssh/id_ed25519.pub 公開鍵を表示します。

    $ cat ~/.ssh/id_ed25519.pub
  3. ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または ./openshift-install gather コマンドを使用する場合は必要になります。

    注記

    一部のディストリビューションでは、~/.ssh/id_rsa および ~/.ssh/id_dsa などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。

    1. ssh-agent プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。

      $ eval "$(ssh-agent -s)"

      出力例

      Agent pid 31874

      注記

      クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。

  4. SSH プライベートキーを ssh-agent に追加します。

    $ ssh-add <path>/<file_name> 1
    1
    ~/.ssh/id_ed25519 などの、SSH プライベートキーのパスおよびファイル名を指定します。

    出力例

    Identity added: /home/<you>/<path>/<file_name> (<computer_name>)

次のステップ

  • OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。クラスターを独自にプロビジョニングするインフラストラクチャーにインストールする場合は、キーをインストールプログラムに指定する必要があります。

3.2.4. user-provisioned infrastructure の準備

user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。

このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。

準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。

前提条件

手順

  1. DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。

    1. ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。
    2. DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。

      注記

      DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。

    3. DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項は、DHCP を使用したクラスターノードのホスト名の設定 参照してください。

      注記

      DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。

  2. ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
  3. OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。

    重要

    デフォルトで、ポート 1936 は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。

    Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。

  4. クラスターに必要な DNS インフラストラクチャーを設定します。

    1. Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
    2. Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。

      OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。

  5. DNS 設定を検証します。

    1. インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
    2. インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。

      DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。

  6. 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
注記

一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。

3.2.5. user-provisioned infrastructure の DNS 解決の検証

OpenShift Container Platform を user-provisioned infrastructure にインストールする前に、DNS 設定を検証できます。

重要

このセクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。

前提条件

  • user-provisioned infrastructure に必要な DNS レコードを設定している。

手順

  1. インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。

    1. Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain> 1
      1
      <nameserver_ip> をネームサーバーの IP アドレスに、<cluster_name> をクラスター名に、<base_domain> をベースドメイン名に置き換えます。

      出力例

      api.ocp4.example.com.		604800	IN	A	192.168.1.5

    2. Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>

      出力例

      api-int.ocp4.example.com.		604800	IN	A	192.168.1.5

    3. *.apps.<cluster_name>.<base_domain> DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。

      $ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>

      出力例

      random.apps.ocp4.example.com.		604800	IN	A	192.168.1.5

      注記

      出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。

      random は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。

      $ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>

      出力例

      console-openshift-console.apps.ocp4.example.com. 604800 IN	A 192.168.1.5

    4. ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。

      $ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>

      出力例

      bootstrap.ocp4.example.com.		604800	IN	A	192.168.1.96

    5. この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
  2. インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。

    1. API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.5

      出力例

      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

      1
      Kubernetes 内部 API のレコード名を指定します。
      2
      Kubernetes API のレコード名を指定します。
      注記

      PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。

    2. ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。

      $ dig +noall +answer @<nameserver_ip> -x 192.168.1.96

      出力例

      96.1.168.192.in-addr.arpa. 604800	IN	PTR	bootstrap.ocp4.example.com.

    3. この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。

3.3. user-provisioned infrastructure を使用した vSphere へのクラスターのインストール

OpenShift Container Platform バージョン 4.16 では、独自にプロビジョニングする VMware vSphere インフラストラクチャーに、クラスターをインストールできます。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、vSphere プラットフォームおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。user-provisioned infrastructure のインストール手順をガイドとして使用します。他の方法で必要なリソースを作成することもできます。

3.3.1. 前提条件

  • user-provisioned infrastructure を使用したクラスターのインストールの準備 のタスクを完了した。
  • VMware プラットフォームのライセンスを確認した。Red Hat は VMware ライセンスに制限を設けていませんが、一部の VMware インフラストラクチャーコンポーネントにはライセンスが必要です。
  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
  • クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
  • クラスターの 永続ストレージ をプロビジョニングした。プライベートイメージレジストリーをデプロイするには、ストレージで ReadWriteMany アクセスモードを指定する必要があります。
  • インストールを完了するには、vSphere ホストに Red Hat Enterprise Linux CoreOS(RHCOS) OVA をアップロードする必要があります。このプロセスを完了するマシンには、vCenter および ESXi ホストのポート 443 にアクセスできる必要があります。ポート 443 にアクセスできることを確認している。
  • ファイアウォールを使用する場合は、ポート 443 にアクセスできることを管理者に確認している。インストールを成功させるには、コントロールプレーンノードがポート 443 で vCenter および ESXi ホストに到達できる必要があります。
  • ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。

    注記

    プロキシーを設定する場合は、このサイトリストも確認してください。

3.3.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

3.3.3. VMware vSphere のリージョンとゾーンの有効化

OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

重要

VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。

デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。

次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。

  • 障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
  • リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。
  • ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。
注記

install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。

リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。

次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。

データセンター (リージョン)クラスター (ゾーン)タグ

米国東部

us-east-1

us-east-1a

us-east-1b

us-east-2

us-east-2a

us-east-2b

us-west

us-west-1

us-west-1a

us-west-1b

us-west-2

us-west-2a

us-west-2b

3.3.4. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

  3. 3 ノードクラスターをインストールする場合は、compute.replicas パラメーターを 0 に設定して、install-config.yaml ファイルを変更します。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「vSphere への 3 ノードクラスターのインストール」を参照してください。
  4. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

3.3.4.1. VMware vSphere のサンプル install-config.yaml ファイル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

additionalTrustBundlePolicy: Proxyonly
apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name: <worker_node>
  platform: {}
  replicas: 0 3
controlPlane: 4
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3 5
metadata:
  creationTimestamp: null
  name: test 6
networking:
---
platform:
  vsphere:
    failureDomains: 7
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<data_center>/host/<cluster>"
        datacenter: <data_center> 8
        datastore: "/<data_center>/datastore/<datastore>" 9
        networks:
        - <VM_Network_name>
        resourcePool: "/<data_center>/host/<cluster>/Resources/<resourcePool>" 10
        folder: "/<data_center_name>/vm/<folder_name>/<subfolder_name>" 11
      zone: <default_zone_name>
    vcenters:
    - datacenters:
      - <data_center>
      password: <password> 12
      port: 443
      server: <fully_qualified_domain_name> 13
      user: administrator@vsphere.local
    diskType: thin 14
fips: false 15
pullSecret: '{"auths": ...}' 16
sshKey: 'ssh-ed25519 AAAA...' 17
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 4
controlPlane セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。両方のセクションで単一のマシンプールが定義されるため、使用されるコントロールプレーンは 1 つだけです。OpenShift Container Platform は、複数のコンピューティングプールの定義をサポートしていません。
3
replicas パラメーターの値を 0 に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
5
クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
6
DNS レコードに指定したクラスター名。
7
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
8
vSphere データセンター。
9
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。

複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

10
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス (例: /<data_center_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>)。値を指定しない場合、リソースはクラスターのルート /example_data_center/host/example_cluster/Resources にインストールされます。
11
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例: /<data_center_name>/vm/<folder_name>/<subfolder_name>)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin という名前のデフォルトの StorageClass オブジェクトを使用したくない場合は、install-config.yaml ファイルから folder パラメーターを省略できます。
12
vSphere ユーザーに関連付けられたパスワード。
13
vCenter サーバーの完全修飾ホスト名または IP アドレス。
重要

Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。

14
vSphere ディスクのプロビジョニング方法。
15
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 暗号化ライブラリーを使用します。

16
OpenShift Cluster Manager から取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
17
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーのデフォルト SSH キーの公開部分。
3.3.4.2. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは 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
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

3.3.4.3. VMware vCenter のリージョンとゾーンの設定

デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。

OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。

重要

この例では、govc コマンドを使用します。govc コマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは govc コマンドを保守していません。govc のダウンロードとインストールの手順は、VMware ドキュメント Web サイトを参照してください。

前提条件

  • 既存の install-config.yaml インストール設定ファイルがあります。

    重要

    VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

手順

  1. 次の govc コマンドラインツールコマンドを入力して、openshift-region および openshift-zone vCenter タグカテゴリーを作成します。

    重要

    openshift-region および openshift-zone vCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。

    $ govc tags.category.create -d "OpenShift region" openshift-region
    $ govc tags.category.create -d "OpenShift zone" openshift-zone
  2. クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。

    $ govc tags.create -c <region_tag_category> <region_tag>
  3. クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。

    $ govc tags.create -c <zone_tag_category> <zone_tag>
  4. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにリージョンタグをアタッチします。

    $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>
  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
  6. インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。

vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル

---
compute:
---
  vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
controlPlane:
---
vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
platform:
  vsphere:
    vcenters:
---
    datacenters:
      - <data_center_1_name>
      - <data_center_2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_1>
        computeCluster: "/<data_center_1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<data_center_1>/datastore/<datastore1>"
        resourcePool: "/<data_center_1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<data_center_1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_2>
        computeCluster: "/<data_center_2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<data_center_2>/datastore/<datastore2>"
        resourcePool: "/<data_center_2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<data_center_2>/vm/<folder2>"
---

3.3.5. 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 インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> には、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。
  2. コントロールプレーンマシン、コンピュートマシンセット、およびコントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml

    これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

    • コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。

      警告

      3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。

      重要

      コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。

  3. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。
  4. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。

    $ ./openshift-install create ignition-configs --dir <installation_directory> 1
    1
    <installation_directory> には、同じインストールディレクトリーを指定します。

    Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign

3.3.6. インフラストラクチャー名の抽出

Ignition 設定ファイルには、VMware vSphere でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。クラスター ID を仮想マシンフォルダーの名前として使用する予定がある場合、これを抽出する必要があります。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • クラスターの Ignition 設定ファイルを生成している。
  • jq パッケージをインストールしている。

手順

  • Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。

    $ jq -r .infraID <installation_directory>/metadata.json 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    openshift-vw9j6 1

    1
    このコマンドの出力はクラスター名とランダムな文字列です。

3.3.7. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始

OpenShift Container Platform を VMware vSphere の user-provisioned infrastructure にインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を vSphere ホストにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。

前提条件

  • クラスターの Ignition 設定ファイルを取得している。
  • お使いのコンピューターからアクセスでき、作成するマシンがアクセスできる HTTP サーバーへのアクセス権がある。
  • vSphere クラスター を作成している。

手順

  1. <installation_directory>/bootstrap.ign という名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。
  2. ブートストラップノードの以下の二次的な Ignition 設定ファイルを、<installation_directory>/merge-bootstrap.ign としてコンピューターに保存します。

    {
      "ignition": {
        "config": {
          "merge": [
            {
              "source": "<bootstrap_ignition_config_url>", 1
              "verification": {}
            }
          ]
        },
        "timeouts": {},
        "version": "3.2.0"
      },
      "networkd": {},
      "passwd": {},
      "storage": {},
      "systemd": {}
    }
    1
    ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

    ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。

  3. インストールプログラムにより作成された次の Ignition 設定ファイルを見つけます。

    • <installation_directory>/master.ign
    • <installation_directory>/worker.ign
    • <installation_directory>/merge-bootstrap.ign
  4. Ignition 設定ファイルを Base64 エンコーディングに変換します。この手順の後半で、これらのファイルを VM の追加の設定パラメーター guestinfo.ignition.config.data に追加する必要があります。

    たとえば、Linux オペレーティングシステムを使用する場合、base64 コマンドを使用してファイルをエンコードできます。

    $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64
    $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64
    $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64
    重要

    インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

  5. RHCOS OVA イメージを取得します。イメージは、RHCOS イメージミラー ページから入手できます。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

    ファイル名には、rhcos-vmware.<architecture>.ova 形式の OpenShift Container Platform のバージョン番号が含まれます。

  6. vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。

    1. VMs and Templates ビューをクリックします。
    2. データセンターの名前を右クリックします。
    3. New FolderNew VM and Template Folder をクリックします。
    4. 表示されるウィンドウで、フォルダー名を入力します。install-config.yaml ファイルに既存のフォルダーを指定していない場合には、インフラストラクチャー ID と同じ名前を持つフォルダーを作成します。このフォルダー名を使用すると、vCenter はその Workspace 設定に適した場所にあるストレージを動的にプロビジョニングします。
  7. vSphere クライアントで、OVA イメージのテンプレートを作成してから、必要に応じてテンプレートのクローンを作成します。

    注記

    以下の手順では、テンプレートを作成してから、すべてのクラスターマシンのテンプレートのクローンを作成します。次に、仮想マシンのプロビジョニング時にクローン作成されたマシンタイプの Ignition 設定ファイルの場所を指定します。

    1. Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template を選択します。
    2. Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
    3. Select a name and folder タブで、Template-RHCOS などの Virtual machine name をテンプレートに設定します。vSphere クラスターの名前をクリックし、直前の手順で作成したフォルダーを選択します。
    4. Select a compute resource タブで、vSphere クラスターの名前をクリックします。
    5. Select storage タブで、仮想マシンのストレージオプションを設定します。

      • ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
      • install-config.yaml ファイルで指定したデータストアを選択します。
      • 仮想マシンを暗号化する場合は、Encrypt this virtual machine を選択します。詳細は、「仮想マシンを暗号化するための要件」セクションを参照してください。
    6. Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。
    7. OVF テンプレートの作成時には、Customize template タブで値を指定したり、テンプレートに追加の設定をしないようにしてください。

      重要

      元の仮想マシンテンプレートは開始しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規 RHCOS マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。

  8. 必要に応じて、仮想マシンテンプレートで設定された仮想ハードウェアバージョンを更新します。詳細は、VMware ドキュメントの Upgrading a virtual machine to the latest hardware version を参照してください。

    重要

    必要に応じて、仮想マシンを作成する前に、仮想マシンテンプレートのハードウェアバージョンをバージョン 15 に更新することが推奨されます。vSphere で実行しているクラスターノード用にハードウェアバージョン 13 を使用することは非推奨となりました。インポートしたテンプレートがハードウェアバージョン 13 にデフォルト設定されている場合は、仮想マシンテンプレートをハードウェアバージョン 15 にアップグレードする前に、ESXi ホストが 6.7U3 以降を使用していることを確認する必要があります。vSphere のバージョンが 6.7U3 未満の場合は、このアップグレード手順を省略できます。ただし、OpenShift Container Platform の今後のバージョンでは、ハードウェアバージョン 13 および vSphere バージョンのサポートが 6.7U3 未満になる予定です。

  9. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

    1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
    2. Select a name and folder タブで、仮想マシンの名前を指定します。control-plane-0 または compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

      注記

      vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

    3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
    4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
    5. Select clone options で、Customize this virtual machine's hardware を選択します。
    6. Customize hardware タブで、Advanced Parameters をクリックします。

      重要

      次の設定の提案は、例としてのみ使用されます。クラスター管理者は、クラスターに課せられるリソース需要に従ってリソースを設定する必要があります。クラスターリソースを最適に管理するには、クラスターのルートリソースプールからリソースプールを作成することを検討してください。

      • オプション: vSphere でデフォルトの DHCP ネットワークを上書きします。静的 IP ネットワークを有効にするには、以下を実行します。

        • 静的 IP 設定を行います。

          コマンドの例

          $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"

          コマンドの例

          $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"

        • vSphere で OVA から仮想マシンを起動する前に、guestinfo.afterburn.initrd.network-kargs プロパティーを設定します。

          コマンドの例

          $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"

      • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

        • guestinfo.ignition.config.data: この手順で先程作成した、base-64 でエンコードされたファイルを見つけて、このマシンタイプに関する base-64 でエンコードされた Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
        • stealclock.enable: このパラメーターが定義されていない場合は、追加して TRUE を指定します。
        • クラスターの root リソースプールから子リソースプールを作成します。この子リソースプールでリソースの割り当てを実行します。
    7. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
    8. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
    9. Virtual Machines タブで仮想マシンを右クリックし、PowerPower On を選択します。
    10. コンソール出力をチェックして、Ignition が実行されたことを確認します。

      コマンドの例

      Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
      Ignition: user-provided config was applied

次のステップ

  • 各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。

    重要

    この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。

3.3.8. vSphere でのコンピュートマシンのクラスターへの追加

コンピュートマシンを VMware vSphere の user-provisioned OpenShift Container Platform クラスターに追加することができます。

vSphere テンプレートを OpenShift Container Platform クラスターにデプロイした後に、そのクラスター内のマシンの仮想マシン (VM) をデプロイできます。

注記

3 ノードクラスターをインストールする場合は、この手順をスキップしてください。3 ノードクラスターは、コンピュートマシンとしても機能する 3 つのコントロールプレーンマシンで構成されます。

前提条件

  • コンピュートマシンの base64 でエンコードされた Ignition ファイルを取得します。
  • クラスター用に作成した vSphere テンプレートにアクセスできる必要があります。

手順

  1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
  2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

    注記

    vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

  3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
  4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
  5. Select storage タブで、設定ファイルとディスクファイル用のストレージを選択します。
  6. Select clone options で、Customize this virtual machine's hardware を選択します。
  7. Customize hardware タブで、Advanced Parameters をクリックします。

    • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

      • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
      • guestinfo.ignition.config.data.encoding: base64 を指定します。
      • disk.EnableUUID: TRUE を指定します。
  8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。多くのネットワークが存在する場合は、Add New Device > Network Adapter を選択し、New Network メニュー項目に表示されるフィールドにネットワーク情報を入力します。
  9. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
  10. Virtual Machines タブで仮想マシンを右クリックし、PowerPower On を選択します。

次のステップ

  • 継続してクラスター用の追加のコンピュートマシンを作成します。

3.3.9. ディスクパーティション設定

ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、RHCOS をインストールして作成されます。この場合、OpenShift Container Platform インストーラーでは、ディスクパーティションの設定が許可されます。

ただし、以下は、OpenShift Container Platform ノードのインストール時に、デフォルトのパーティション設定を上書きするために介入が必要と思われる 2 つのケースになります。

  • 別個のパーティションの作成: 空のディスクへのグリーンフィールドインストールの場合は、別のストレージをパーティションに追加する必要がある場合があります。これは、/var または /var/lib/etcd などの /var のサブディレクトリー (両方ではない) を個別のパーティションとして作成する場合にのみ正式にサポートされます。

    重要

    ディスクサイズが 100 GB を超える場合、特にディスクサイズが 1 TB を超える場合は、別の /var パーティションを作成します。詳細は、「個別の /var パーティションの作成」およびこちらの Red Hat ナレッジベースの記事 を参照してください。

    重要

    Kubernetes は 2 つのファイルシステムパーティションのみをサポートします。元の設定に複数のパーティションを追加すると、Kubernetes はそれらをすべて監視できません。

  • 既存のパーティションの保持: ブラウンフィールドインストールで、既存のノードに OpenShift Container Platform を再インストールし、以前のオペレーティングシステムからのデータパーティションを維持する必要がある場合、既存のデータパーティションを保持できる coreos-installer へのブート引数とオプションの両方があります。
個別の /var パーティションの作成

一般的に、OpenShift Container Platform のディスクパーティション設定は、インストーラーに任せる必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。

OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。

  • /var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。
  • /var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。
  • /var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。

    重要

    ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の /var パーティションを作成します。

/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。

/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。

手順

  1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

    $ mkdir $HOME/clusterconfig
  2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

    $ openshift-install create manifests --dir $HOME/clusterconfig
    ? SSH Public Key ...
    $ ls $HOME/clusterconfig/openshift/
    99_kubeadmin-password-secret.yaml
    99_openshift-cluster-api_master-machines-0.yaml
    99_openshift-cluster-api_master-machines-1.yaml
    99_openshift-cluster-api_master-machines-2.yaml
    ...
  3. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

    variant: openshift
    version: 4.16.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 1
        partitions:
        - label: var
          start_mib: <partition_start_offset> 2
          size_mib: <partition_size> 3
          number: 5
      filesystems:
        - device: /dev/disk/by-partlabel/var
          path: /var
          format: xfs
          mount_options: [defaults, prjquota] 4
          with_mount_unit: true
    1
    パーティションを設定する必要のあるディスクのストレージデバイス名。
    2
    データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
    3
    データパーティションのサイズ (メビバイト単位)。
    4
    コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。
    注記

    個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

  4. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
  5. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

    $ openshift-install create ignition-configs --dir $HOME/clusterconfig
    $ ls $HOME/clusterconfig/
    auth  bootstrap.ign  master.ign  metadata.json  worker.ign

Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールために vSphere インストール手順への入力として使用できます。

3.3.10. ブートストラッププロセスの完了まで待機する

OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。

前提条件

  • クラスターの Ignition 設定ファイルを作成している。
  • 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
  • インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
  • RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
  • お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。

手順

  1. ブートストラッププロセスをモニターします。

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 1
        --log-level=info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    出力例

    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
    INFO API v1.29.4 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

    重要

    この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。

3.3.11. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

3.3.12. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.29.4
    master-1  Ready     master  63m  v1.29.4
    master-2  Ready     master  64m  v1.29.4

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr

    出力例

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

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      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
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    $ oc get csr

    出力例

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

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      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
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.29.4
    master-1  Ready     master  73m  v1.29.4
    master-2  Ready     master  74m  v1.29.4
    worker-0  Ready     worker  11m  v1.29.4
    worker-1  Ready     worker  11m  v1.29.4

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

3.3.13. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.16.0    True        False         False      19m
    baremetal                                  4.16.0    True        False         False      37m
    cloud-credential                           4.16.0    True        False         False      40m
    cluster-autoscaler                         4.16.0    True        False         False      37m
    config-operator                            4.16.0    True        False         False      38m
    console                                    4.16.0    True        False         False      26m
    csi-snapshot-controller                    4.16.0    True        False         False      37m
    dns                                        4.16.0    True        False         False      37m
    etcd                                       4.16.0    True        False         False      36m
    image-registry                             4.16.0    True        False         False      31m
    ingress                                    4.16.0    True        False         False      30m
    insights                                   4.16.0    True        False         False      31m
    kube-apiserver                             4.16.0    True        False         False      26m
    kube-controller-manager                    4.16.0    True        False         False      36m
    kube-scheduler                             4.16.0    True        False         False      36m
    kube-storage-version-migrator              4.16.0    True        False         False      37m
    machine-api                                4.16.0    True        False         False      29m
    machine-approver                           4.16.0    True        False         False      37m
    machine-config                             4.16.0    True        False         False      36m
    marketplace                                4.16.0    True        False         False      37m
    monitoring                                 4.16.0    True        False         False      29m
    network                                    4.16.0    True        False         False      38m
    node-tuning                                4.16.0    True        False         False      37m
    openshift-apiserver                        4.16.0    True        False         False      32m
    openshift-controller-manager               4.16.0    True        False         False      30m
    openshift-samples                          4.16.0    True        False         False      32m
    operator-lifecycle-manager                 4.16.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
    service-ca                                 4.16.0    True        False         False      38m
    storage                                    4.16.0    True        False         False      37m

  2. 利用不可の Operator を設定します。
3.3.13.1. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、Image Registry Operator 設定を編集して managementStateRemoved から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。

3.3.13.2. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

3.3.13.2.1. VMware vSphere のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • VMware vSphere 上のクラスター。
  • Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • "100Gi" の容量が必要です。
重要

テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリックストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim: 1

    1
    image-registry-storage 永続ボリューム要求 (PVC) の自動作成を許可するには、claim フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION                              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.7                                  True        False         False      6h50m

3.3.13.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

3.3.13.2.3. VMware vSphere のブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. 次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して Recreate ロールアウトストラテジーを使用し、1 つのレプリカのみで実行されるようにします。

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。

    1. 以下の内容で pvc.yaml ファイルを作成して VMware vSphere PersistentVolumeClaim オブジェクトを定義します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 1
        namespace: openshift-image-registry 2
      spec:
        accessModes:
        - ReadWriteOnce 3
        resources:
          requests:
            storage: 100Gi 4
      1
      PersistentVolumeClaim オブジェクトを表す一意の名前。
      2
      PersistentVolumeClaim オブジェクトの namespace (openshift-image-registry)。
      3
      永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
      4
      永続ボリューム要求のサイズ。
    2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

      $ oc create -f pvc.yaml -n openshift-image-registry
  3. 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。

    $ oc edit config.imageregistry.operator.openshift.io -o yaml

    出力例

    storage:
      pvc:
        claim: 1

    1
    カスタム PVC を作成することにより、image-registry-storage PVC のデフォルトの自動作成の claim フィールドを空のままにできます。

正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。

3.3.14. user-provisioned infrastructure でのインストールの完了

Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。

前提条件

  • コントロールプレーンが初期化されています。
  • Operator の初期設定を完了済みです。

手順

  1. 以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.16.0    True        False         False      19m
    baremetal                                  4.16.0    True        False         False      37m
    cloud-credential                           4.16.0    True        False         False      40m
    cluster-autoscaler                         4.16.0    True        False         False      37m
    config-operator                            4.16.0    True        False         False      38m
    console                                    4.16.0    True        False         False      26m
    csi-snapshot-controller                    4.16.0    True        False         False      37m
    dns                                        4.16.0    True        False         False      37m
    etcd                                       4.16.0    True        False         False      36m
    image-registry                             4.16.0    True        False         False      31m
    ingress                                    4.16.0    True        False         False      30m
    insights                                   4.16.0    True        False         False      31m
    kube-apiserver                             4.16.0    True        False         False      26m
    kube-controller-manager                    4.16.0    True        False         False      36m
    kube-scheduler                             4.16.0    True        False         False      36m
    kube-storage-version-migrator              4.16.0    True        False         False      37m
    machine-api                                4.16.0    True        False         False      29m
    machine-approver                           4.16.0    True        False         False      37m
    machine-config                             4.16.0    True        False         False      36m
    marketplace                                4.16.0    True        False         False      37m
    monitoring                                 4.16.0    True        False         False      29m
    network                                    4.16.0    True        False         False      38m
    node-tuning                                4.16.0    True        False         False      37m
    openshift-apiserver                        4.16.0    True        False         False      32m
    openshift-controller-manager               4.16.0    True        False         False      30m
    openshift-samples                          4.16.0    True        False         False      32m
    operator-lifecycle-manager                 4.16.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
    service-ca                                 4.16.0    True        False         False      38m
    storage                                    4.16.0    True        False         False      37m

    あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 30m0s for the cluster to initialize...

    Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
  2. Kubernetes API サーバーが Pod と通信していることを確認します。

    1. すべての Pod のリストを表示するには、以下のコマンドを使用します。

      $ oc get pods --all-namespaces

      出力例

      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

    2. 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。

      $ oc logs <pod_name> -n <namespace> 1
      1
      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

  3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

    詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。

クラスターのインストールが完了したら、コンピュートマシンの vSphere への追加 に従って、コンピュートマシンをさらに追加できます。

3.3.15. コントロールプレーンノードの vSphere DRS 非アフィニティールールの設定

vSphere Distributed Resource Scheduler (DRS) 非アフィニティールールを設定して、OpenShift Container Platform コントロールプレーンノードでより高い可用性をサポートできます。非アフィニティールールにより、OpenShift Container Platform コントロールプレーンノードの vSphere 仮想マシンが同じ vSphere ノードにスケジュールされないようにします。

重要
  • 以下の情報はコンピュート DRS にのみ適用され、ストレージ DRS には適用されません。
  • govc コマンドは、VMware で利用可能なオープンソースのコマンドであり、Red Hat からは利用できません。govc コマンドは、Red Hat サポートではサポートされません。
  • govc のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイトを参照してください。

以下のコマンドを実行して anti-affinity ルールを作成します。

コマンドの例

$ govc cluster.rule.create \
  -name openshift4-control-plane-group \
  -dc MyDatacenter -cluster MyCluster \
  -enable \
  -anti-affinity master-0 master-1 master-2

ルールを作成すると、コントロールプレーンノードは vSphere によって自動的に移行されるため、同じホストで実行されることはありません。vSphere が新しいルールを調整するまで、しばらく時間がかかる場合があります。コマンドを正しく補完する方法は、以下の手順に示します。

注記

移行は自動的に行われ、移行が完了するまで短い OpenShift API 停止またはレイテンシーが発生する可能性があります。

vSphere DRS の非アフィニティールールは、コントロールプレーンの仮想マシン名が変更された場合や、新しい vSphere クラスターへの移行時に手動で更新する必要があります。

手順

  1. 以下のコマンドを実行して、既存の DRS 非アフィニティールールを削除します。

    $ govc cluster.rule.remove \
      -name openshift4-control-plane-group \
      -dc MyDatacenter -cluster MyCluster

    出力例

    [13-10-22 09:33:24] Reconfigure /MyDatacenter/host/MyCluster...OK

  2. 以下のコマンドを実行して、更新された名前でルールを再度作成します。

    $ govc cluster.rule.create \
      -name openshift4-control-plane-group \
      -dc MyDatacenter -cluster MyOtherCluster \
      -enable \
      -anti-affinity master-0 master-1 master-2

3.3.16. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

3.3.17. 次のステップ

3.4. ネットワークのカスタマイズによる vSphere へのクラスターのインストール

OpenShift Container Platform バージョン 4.16 では、カスタマイズしたネットワーク設定オプションを使用して、独自にプロビジョニングする VMware vSphere インフラストラクチャーにクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、vSphere プラットフォームおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。user-provisioned infrastructure のインストール手順をガイドとして使用します。他の方法で必要なリソースを作成することもできます。

3.4.1. 前提条件

3.4.2. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターをインストールするためにインターネットアクセスが必要になります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。
重要

クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。

3.4.3. VMware vSphere のリージョンとゾーンの有効化

OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

重要

VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。

デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。

次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。

  • 障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
  • リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。
  • ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。
注記

install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。

リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。

次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。

データセンター (リージョン)クラスター (ゾーン)タグ

米国東部

us-east-1

us-east-1a

us-east-1b

us-east-2

us-east-2a

us-east-2b

us-west

us-west-1

us-west-1a

us-west-1b

us-west-2

us-west-2a

us-west-2b

3.4.4. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

重要

Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、これを <installation_directory> に保存します。

    注記

    この設定ファイルの名前を install-config.yaml と付ける必要があります。

  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

3.4.4.1. VMware vSphere のサンプル install-config.yaml ファイル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

additionalTrustBundlePolicy: Proxyonly
apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name: <worker_node>
  platform: {}
  replicas: 0 3
controlPlane: 4
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3 5
metadata:
  creationTimestamp: null
  name: test 6
networking:
---
platform:
  vsphere:
    failureDomains: 7
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<data_center>/host/<cluster>"
        datacenter: <data_center> 8
        datastore: "/<data_center>/datastore/<datastore>" 9
        networks:
        - <VM_Network_name>
        resourcePool: "/<data_center>/host/<cluster>/Resources/<resourcePool>" 10
        folder: "/<data_center_name>/vm/<folder_name>/<subfolder_name>" 11
      zone: <default_zone_name>
    vcenters:
    - datacenters:
      - <data_center>
      password: <password> 12
      port: 443
      server: <fully_qualified_domain_name> 13
      user: administrator@vsphere.local
    diskType: thin 14
fips: false 15
pullSecret: '{"auths": ...}' 16
sshKey: 'ssh-ed25519 AAAA...' 17
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 4
controlPlane セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。両方のセクションで単一のマシンプールが定義されるため、使用されるコントロールプレーンは 1 つだけです。OpenShift Container Platform は、複数のコンピューティングプールの定義をサポートしていません。
3
replicas パラメーターの値を 0 に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
5
クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
6
DNS レコードに指定したクラスター名。
7
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
8
vSphere データセンター。
9
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。

複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

10
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス (例: /<data_center_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>)。値を指定しない場合、リソースはクラスターのルート /example_data_center/host/example_cluster/Resources にインストールされます。
11
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例: /<data_center_name>/vm/<folder_name>/<subfolder_name>)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin という名前のデフォルトの StorageClass オブジェクトを使用したくない場合は、install-config.yaml ファイルから folder パラメーターを省略できます。
12
vSphere ユーザーに関連付けられたパスワード。
13
vCenter サーバーの完全修飾ホスト名または IP アドレス。
重要

Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。

14
vSphere ディスクのプロビジョニング方法。
15
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 暗号化ライブラリーを使用します。

16
OpenShift Cluster Manager から取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
17
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーのデフォルト SSH キーの公開部分。
3.4.4.2. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは 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
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

3.4.4.3. VMware vCenter のリージョンとゾーンの設定

デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。

OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。

重要

この例では、govc コマンドを使用します。govc コマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは govc コマンドを保守していません。govc のダウンロードとインストールの手順は、VMware ドキュメント Web サイトを参照してください。

前提条件

  • 既存の install-config.yaml インストール設定ファイルがあります。

    重要

    VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

手順

  1. 次の govc コマンドラインツールコマンドを入力して、openshift-region および openshift-zone vCenter タグカテゴリーを作成します。

    重要

    openshift-region および openshift-zone vCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。

    $ govc tags.category.create -d "OpenShift region" openshift-region
    $ govc tags.category.create -d "OpenShift zone" openshift-zone
  2. クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。

    $ govc tags.create -c <region_tag_category> <region_tag>
  3. クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。

    $ govc tags.create -c <zone_tag_category> <zone_tag>
  4. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにリージョンタグをアタッチします。

    $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>
  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
  6. インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。

vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル

---
compute:
---
  vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
controlPlane:
---
vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
platform:
  vsphere:
    vcenters:
---
    datacenters:
      - <data_center_1_name>
      - <data_center_2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_1>
        computeCluster: "/<data_center_1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<data_center_1>/datastore/<datastore1>"
        resourcePool: "/<data_center_1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<data_center_1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_2>
        computeCluster: "/<data_center_2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<data_center_2>/datastore/<datastore2>"
        resourcePool: "/<data_center_2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<data_center_2>/vm/<folder2>"
---

3.4.5. ネットワーク設定フェーズ

OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。

フェーズ 1

マニフェストファイルを作成する前に、install-config.yaml ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。

  • networking.networkType
  • networking.clusterNetwork
  • networking.serviceNetwork
  • networking.machineNetwork

    詳細は、「インストール設定パラメーター」を参照してください。

    注記

    優先されるサブネットが配置されている Classless Inter-Domain Routing (CIDR) と一致するように networking.machineNetwork を設定します。

    重要

    CIDR 範囲 172.17.0.0/16libVirt によって予約されています。クラスター内のネットワークに 172.17.0.0/16 CIDR 範囲と重複する他の CIDR 範囲を使用することはできません。

フェーズ 2
openshift-install create manifests を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。

フェーズ 2 では、install-config.yaml ファイルのフェーズ 1 で指定した値をオーバーライドすることはできません。ただし、フェーズ 2 でネットワークプラグインをカスタマイズできます。

3.4.6. 高度なネットワーク設定の指定

ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。

高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。

重要

インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。

前提条件

  • install-config.yaml ファイルを作成し、これに対する変更を完了している。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> は、クラスターの install-config.yaml ファイルが含まれるディレクトリーの名前を指定します。
  2. cluster-network-03-config.yml という名前の、高度なネットワーク設定用のスタブマニフェストファイルを <installation_directory>/manifests/ ディレクトリーに作成します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
  3. 次の例のように、cluster-network-03-config.yml ファイルでクラスターの高度なネットワーク設定を指定します。

    OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          ipsecConfig:
            mode: Full

  4. オプション: manifests/cluster-network-03-config.yml ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時に manifests/ ディレクトリーを使用します。
  5. コントロールプレーンマシンおよび compute machineSets を定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

    これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

    • MachineSet ファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
3.4.6.1. ネットワークに複数のサブネットを指定する

OpenShift Container Platform クラスターを vSphere ホストにインストールする前に、ネットワーク実装に複数のサブネットを指定して、vSphere Cloud Controller Manager (CCM) が特定のネットワーク状況に適したサブネットを選択できるようにします。vSphere は、クラスター上の Pod およびサービスを管理するサブネットを使用できます。

この設定では、vSphere CCM 設定で内部および外部の Classless Inter-Domain Routing (CIDR) 実装を指定する必要があります。各 CIDR 実装は、内部および外部ネットワークからのトラフィックと対話するサブネットを決定するために CCM が使用する IP アドレス範囲をリスト表示します。

重要

vSphere CCM 設定で内部および外部の CIDR 実装の設定に失敗すると、vSphere CCM が誤ったサブネットを選択する可能性があります。この状況では、以下のエラーが発生します。

ERROR Bootstrap failed to complete: timed out waiting for the condition
ERROR Failed to wait for bootstrapping to complete. This error usually happens when there is a problem with control plane hosts that prevents the control plane operators from creating the control plane.

この設定により、新規の各ノードが node.cloudprovider.kubernetes.io/uninitialized taint を受け取ると、単一のサブネットの MachineSet オブジェクトに関連付けられた新規ノードが使用できなくなる可能性があります。このような状況では、Kubernetes API サーバーとの通信で問題が発生し、これが原因でクラスターのインストールが失敗する可能性があります。

前提条件

  • OpenShift Container Platform クラスターの Kubernetes マニフェストファイルを作成している。

手順

  1. OpenShift Container Platform クラスターマニフェストファイルを保存するディレクトリーから、manifests/cluster-infrastructure-02-config.yml マニフェストファイルを開きます。
  2. nodeNetworking オブジェクトをファイルに追加し、オブジェクトの内部および外部ネットワークサブネット CIDR 実装を指定します。

    ヒント

    ほとんどのネットワークの場合、標準のマルチサブネット構成の設定を検討してください。この構成では、nodeNetworking.internal.networkSubnetCidr および nodeNetworking.external.networkSubnetCidr パラメーターに同じ IP アドレス範囲を設定する必要があります。

    設定された cluster-infrastructure-02-config.yml マニフェストファイルの例

    apiVersion: config.openshift.io/v1
    kind: Infrastructure
    metadata:
      name: cluster
    spec:
      cloudConfig:
        key: config
        name: cloud-provider-config
      platformSpec:
        type: VSphere
        vsphere:
          failureDomains:
          - name: generated-failure-domain
          ...
           nodeNetworking:
             external:
               networkSubnetCidr:
               - <machine_network_cidr_ipv4>
               - <machine_network_cidr_ipv6>
             internal:
               networkSubnetCidr:
               - <machine_network_cidr_ipv4>
               - <machine_network_cidr_ipv6>
    # ...

3.4.7. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、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 オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。

3.4.7.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

表3.12 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14

マニフェストを作成する前に、このフィールドを install-config.yaml ファイルでのみカスタマイズすることができます。この値は、マニフェストファイルでは読み取り専用です。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

表3.13 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

表3.14 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。

クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも 100 小さく設定する必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

genevePort

integer

すべての Geneve パケットに使用するポート。デフォルト値は 6081 です。この値は、クラスターのインストール後は変更できません。

ipsecConfig

object

IPsec 設定をカスタマイズするための設定オブジェクトを指定します。

ipv4

object

IPv4 設定の設定オブジェクトを指定します。

ipv6

object

IPv6 設定の設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

表3.15 ovnKubernetesConfig.ipv4 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが 100.88.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は 100.88.0.0/16 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

デフォルト値は 100.64.0.0/16 です。

表3.16 ovnKubernetesConfig.ipv6 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが fd97::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は fd97::/64 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが fd98::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

デフォルト値は fd98::/64 です。

表3.17 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

比較先

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

表3.18 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドをtrueに設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

ipv4

object

オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

ipv6

object

オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

表3.19 gatewayConfig.ipv4 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 169.254.169.0/29 です。

表3.20 gatewayConfig.ipv6 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は fd69::/125 です。

表3.21 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

IPsec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
      ipsecConfig:
        mode: Full

重要

OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。

kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)

kubeProxyConfig オブジェクトの値は以下の表で定義されます。

表3.22 kubeProxyConfig オブジェクト
フィールド説明

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ ドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効な接尾辞には、sm、および h などが含まれ、これらについては、Go time パッケージ で説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

3.4.8. 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> 1
    1
    <installation_directory> の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
    重要

    install-config.yaml ファイルを作成している場合、それが含まれるディレクトリーを指定します。または、空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

    以下のファイルはディレクトリーに生成されます。

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign

3.4.9. インフラストラクチャー名の抽出

Ignition 設定ファイルには、VMware vSphere でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。クラスター ID を仮想マシンフォルダーの名前として使用する予定がある場合、これを抽出する必要があります。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • クラスターの Ignition 設定ファイルを生成している。
  • jq パッケージをインストールしている。

手順

  • Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。

    $ jq -r .infraID <installation_directory>/metadata.json 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    openshift-vw9j6 1

    1
    このコマンドの出力はクラスター名とランダムな文字列です。

3.4.10. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始

OpenShift Container Platform を VMware vSphere の user-provisioned infrastructure にインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を vSphere ホストにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。

前提条件

  • クラスターの Ignition 設定ファイルを取得している。
  • お使いのコンピューターからアクセスでき、作成するマシンがアクセスできる HTTP サーバーへのアクセス権がある。
  • vSphere クラスター を作成している。

手順

  1. <installation_directory>/bootstrap.ign という名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。
  2. ブートストラップノードの以下の二次的な Ignition 設定ファイルを、<installation_directory>/merge-bootstrap.ign としてコンピューターに保存します。

    {
      "ignition": {
        "config": {
          "merge": [
            {
              "source": "<bootstrap_ignition_config_url>", 1
              "verification": {}
            }
          ]
        },
        "timeouts": {},
        "version": "3.2.0"
      },
      "networkd": {},
      "passwd": {},
      "storage": {},
      "systemd": {}
    }
    1
    ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

    ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。

  3. インストールプログラムにより作成された次の Ignition 設定ファイルを見つけます。

    • <installation_directory>/master.ign
    • <installation_directory>/worker.ign
    • <installation_directory>/merge-bootstrap.ign
  4. Ignition 設定ファイルを Base64 エンコーディングに変換します。この手順の後半で、これらのファイルを VM の追加の設定パラメーター guestinfo.ignition.config.data に追加する必要があります。

    たとえば、Linux オペレーティングシステムを使用する場合、base64 コマンドを使用してファイルをエンコードできます。

    $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64
    $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64
    $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64
    重要

    インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

  5. RHCOS OVA イメージを取得します。イメージは、RHCOS イメージミラー ページから入手できます。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

    ファイル名には、rhcos-vmware.<architecture>.ova 形式の OpenShift Container Platform のバージョン番号が含まれます。

  6. vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。

    1. VMs and Templates ビューをクリックします。
    2. データセンターの名前を右クリックします。
    3. New FolderNew VM and Template Folder をクリックします。
    4. 表示されるウィンドウで、フォルダー名を入力します。install-config.yaml ファイルに既存のフォルダーを指定していない場合には、インフラストラクチャー ID と同じ名前を持つフォルダーを作成します。このフォルダー名を使用すると、vCenter はその Workspace 設定に適した場所にあるストレージを動的にプロビジョニングします。
  7. vSphere クライアントで、OVA イメージのテンプレートを作成してから、必要に応じてテンプレートのクローンを作成します。

    注記

    以下の手順では、テンプレートを作成してから、すべてのクラスターマシンのテンプレートのクローンを作成します。次に、仮想マシンのプロビジョニング時にクローン作成されたマシンタイプの Ignition 設定ファイルの場所を指定します。

    1. Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template を選択します。
    2. Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
    3. Select a name and folder タブで、Template-RHCOS などの Virtual machine name をテンプレートに設定します。vSphere クラスターの名前をクリックし、直前の手順で作成したフォルダーを選択します。
    4. Select a compute resource タブで、vSphere クラスターの名前をクリックします。
    5. Select storage タブで、仮想マシンのストレージオプションを設定します。

      • ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
      • install-config.yaml ファイルで指定したデータストアを選択します。
      • 仮想マシンを暗号化する場合は、Encrypt this virtual machine を選択します。詳細は、「仮想マシンを暗号化するための要件」セクションを参照してください。
    6. Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。
    7. OVF テンプレートの作成時には、Customize template タブで値を指定したり、テンプレートに追加の設定をしないようにしてください。

      重要

      元の仮想マシンテンプレートは開始しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規 RHCOS マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。

  8. 必要に応じて、仮想マシンテンプレートで設定された仮想ハードウェアバージョンを更新します。詳細は、VMware ドキュメントの Upgrading a virtual machine to the latest hardware version を参照してください。

    重要

    必要に応じて、仮想マシンを作成する前に、仮想マシンテンプレートのハードウェアバージョンをバージョン 15 に更新することが推奨されます。vSphere で実行しているクラスターノード用にハードウェアバージョン 13 を使用することは非推奨となりました。インポートしたテンプレートがハードウェアバージョン 13 にデフォルト設定されている場合は、仮想マシンテンプレートをハードウェアバージョン 15 にアップグレードする前に、ESXi ホストが 6.7U3 以降を使用していることを確認する必要があります。vSphere のバージョンが 6.7U3 未満の場合は、このアップグレード手順を省略できます。ただし、OpenShift Container Platform の今後のバージョンでは、ハードウェアバージョン 13 および vSphere バージョンのサポートが 6.7U3 未満になる予定です。

  9. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

    1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
    2. Select a name and folder タブで、仮想マシンの名前を指定します。control-plane-0 または compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

      注記

      vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

    3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
    4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
    5. Select clone options で、Customize this virtual machine's hardware を選択します。
    6. Customize hardware タブで、Advanced Parameters をクリックします。

      重要

      次の設定の提案は、例としてのみ使用されます。クラスター管理者は、クラスターに課せられるリソース需要に従ってリソースを設定する必要があります。クラスターリソースを最適に管理するには、クラスターのルートリソースプールからリソースプールを作成することを検討してください。

      • オプション: vSphere でデフォルトの DHCP ネットワークを上書きします。静的 IP ネットワークを有効にするには、以下を実行します。

        • 静的 IP 設定を行います。

          コマンドの例

          $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"

          コマンドの例

          $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"

        • vSphere で OVA から仮想マシンを起動する前に、guestinfo.afterburn.initrd.network-kargs プロパティーを設定します。

          コマンドの例

          $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"

      • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

        • guestinfo.ignition.config.data: この手順で先程作成した、base-64 でエンコードされたファイルを見つけて、このマシンタイプに関する base-64 でエンコードされた Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
        • stealclock.enable: このパラメーターが定義されていない場合は、追加して TRUE を指定します。
        • クラスターの root リソースプールから子リソースプールを作成します。この子リソースプールでリソースの割り当てを実行します。
    7. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
    8. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
    9. Virtual Machines タブで仮想マシンを右クリックし、PowerPower On を選択します。
    10. コンソール出力をチェックして、Ignition が実行されたことを確認します。

      コマンドの例

      Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
      Ignition: user-provided config was applied

次のステップ

  • 各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。

    重要

    この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。

3.4.11. vSphere でのコンピュートマシンのクラスターへの追加

コンピュートマシンを VMware vSphere の user-provisioned OpenShift Container Platform クラスターに追加することができます。

vSphere テンプレートを OpenShift Container Platform クラスターにデプロイした後に、そのクラスター内のマシンの仮想マシン (VM) をデプロイできます。

前提条件

  • コンピュートマシンの base64 でエンコードされた Ignition ファイルを取得します。
  • クラスター用に作成した vSphere テンプレートにアクセスできる必要があります。

手順

  1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
  2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

    注記

    vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

  3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
  4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
  5. Select storage タブで、設定ファイルとディスクファイル用のストレージを選択します。
  6. Select clone options で、Customize this virtual machine's hardware を選択します。
  7. Customize hardware タブで、Advanced Parameters をクリックします。

    • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

      • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
      • guestinfo.ignition.config.data.encoding: base64 を指定します。
      • disk.EnableUUID: TRUE を指定します。
  8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。多くのネットワークが存在する場合は、Add New Device > Network Adapter を選択し、New Network メニュー項目に表示されるフィールドにネットワーク情報を入力します。
  9. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
  10. Virtual Machines タブで仮想マシンを右クリックし、PowerPower On を選択します。

次のステップ

  • 継続してクラスター用の追加のコンピュートマシンを作成します。

3.4.12. ディスクパーティション設定

ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、RHCOS をインストールして作成されます。この場合、OpenShift Container Platform インストーラーでは、ディスクパーティションの設定が許可されます。

ただし、以下は、OpenShift Container Platform ノードのインストール時に、デフォルトのパーティション設定を上書きするために介入が必要と思われる 2 つのケースになります。

  • 別個のパーティションの作成: 空のディスクへのグリーンフィールドインストールの場合は、別のストレージをパーティションに追加する必要がある場合があります。これは、/var または /var/lib/etcd などの /var のサブディレクトリー (両方ではない) を個別のパーティションとして作成する場合にのみ正式にサポートされます。

    重要

    ディスクサイズが 100 GB を超える場合、特にディスクサイズが 1 TB を超える場合は、別の /var パーティションを作成します。詳細は、「個別の /var パーティションの作成」およびこちらの Red Hat ナレッジベースの記事 を参照してください。

    重要

    Kubernetes は 2 つのファイルシステムパーティションのみをサポートします。元の設定に複数のパーティションを追加すると、Kubernetes はそれらをすべて監視できません。

  • 既存のパーティションの保持: ブラウンフィールドインストールで、既存のノードに OpenShift Container Platform を再インストールし、以前のオペレーティングシステムからのデータパーティションを維持する必要がある場合、既存のデータパーティションを保持できる coreos-installer へのブート引数とオプションの両方があります。
個別の /var パーティションの作成

一般的に、OpenShift Container Platform のディスクパーティション設定は、インストーラーに任せる必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。

OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。

  • /var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。
  • /var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。
  • /var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。

    重要

    ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の /var パーティションを作成します。

/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。

/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。

手順

  1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

    $ mkdir $HOME/clusterconfig
  2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

    $ openshift-install create manifests --dir $HOME/clusterconfig
    ? SSH Public Key ...
    $ ls $HOME/clusterconfig/openshift/
    99_kubeadmin-password-secret.yaml
    99_openshift-cluster-api_master-machines-0.yaml
    99_openshift-cluster-api_master-machines-1.yaml
    99_openshift-cluster-api_master-machines-2.yaml
    ...
  3. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

    variant: openshift
    version: 4.16.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 1
        partitions:
        - label: var
          start_mib: <partition_start_offset> 2
          size_mib: <partition_size> 3
          number: 5
      filesystems:
        - device: /dev/disk/by-partlabel/var
          path: /var
          format: xfs
          mount_options: [defaults, prjquota] 4
          with_mount_unit: true
    1
    パーティションを設定する必要のあるディスクのストレージデバイス名。
    2
    データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
    3
    データパーティションのサイズ (メビバイト単位)。
    4
    コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。
    注記

    個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

  4. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
  5. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

    $ openshift-install create ignition-configs --dir $HOME/clusterconfig
    $ ls $HOME/clusterconfig/
    auth  bootstrap.ign  master.ign  metadata.json  worker.ign

Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールために vSphere インストール手順への入力として使用できます。

3.4.13. ブートストラッププロセスの完了まで待機する

OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。

前提条件

  • クラスターの Ignition 設定ファイルを作成している。
  • 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
  • インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
  • RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
  • お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。

手順

  1. ブートストラッププロセスをモニターします。

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 1
        --log-level=info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    出力例

    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
    INFO API v1.29.4 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

    重要

    この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。

3.4.14. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

3.4.15. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.29.4
    master-1  Ready     master  63m  v1.29.4
    master-2  Ready     master  64m  v1.29.4

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr

    出力例

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

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      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
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    $ oc get csr

    出力例

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

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      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
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.29.4
    master-1  Ready     master  73m  v1.29.4
    master-2  Ready     master  74m  v1.29.4
    worker-0  Ready     worker  11m  v1.29.4
    worker-1  Ready     worker  11m  v1.29.4

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

3.4.15.1. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.16.0    True        False         False      19m
    baremetal                                  4.16.0    True        False         False      37m
    cloud-credential                           4.16.0    True        False         False      40m
    cluster-autoscaler                         4.16.0    True        False         False      37m
    config-operator                            4.16.0    True        False         False      38m
    console                                    4.16.0    True        False         False      26m
    csi-snapshot-controller                    4.16.0    True        False         False      37m
    dns                                        4.16.0    True        False         False      37m
    etcd                                       4.16.0    True        False         False      36m
    image-registry                             4.16.0    True        False         False      31m
    ingress                                    4.16.0    True        False         False      30m
    insights                                   4.16.0    True        False         False      31m
    kube-apiserver                             4.16.0    True        False         False      26m
    kube-controller-manager                    4.16.0    True        False         False      36m
    kube-scheduler                             4.16.0    True        False         False      36m
    kube-storage-version-migrator              4.16.0    True        False         False      37m
    machine-api                                4.16.0    True        False         False      29m
    machine-approver                           4.16.0    True        False         False      37m
    machine-config                             4.16.0    True        False         False      36m
    marketplace                                4.16.0    True        False         False      37m
    monitoring                                 4.16.0    True        False         False      29m
    network                                    4.16.0    True        False         False      38m
    node-tuning                                4.16.0    True        False         False      37m
    openshift-apiserver                        4.16.0    True        False         False      32m
    openshift-controller-manager               4.16.0    True        False         False      30m
    openshift-samples                          4.16.0    True        False         False      32m
    operator-lifecycle-manager                 4.16.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
    service-ca                                 4.16.0    True        False         False      38m
    storage                                    4.16.0    True        False         False      37m

  2. 利用不可の Operator を設定します。
3.4.15.2. インストール時に削除されたイメージレジストリー

共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。

インストール後に、Image Registry Operator 設定を編集して managementStateRemoved から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。

3.4.15.3. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

3.4.15.3.1. VMware vSphere のブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. 次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して Recreate ロールアウトストラテジーを使用し、1 つのレプリカのみで実行されるようにします。

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。

    1. 以下の内容で pvc.yaml ファイルを作成して VMware vSphere PersistentVolumeClaim オブジェクトを定義します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 1
        namespace: openshift-image-registry 2
      spec:
        accessModes:
        - ReadWriteOnce 3
        resources:
          requests:
            storage: 100Gi 4
      1
      PersistentVolumeClaim オブジェクトを表す一意の名前。
      2
      PersistentVolumeClaim オブジェクトの namespace (openshift-image-registry)。
      3
      永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
      4
      永続ボリューム要求のサイズ。
    2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

      $ oc create -f pvc.yaml -n openshift-image-registry
  3. 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。

    $ oc edit config.imageregistry.operator.openshift.io -o yaml

    出力例

    storage:
      pvc:
        claim: 1

    1
    カスタム PVC を作成することにより、image-registry-storage PVC のデフォルトの自動作成の claim フィールドを空のままにできます。

正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。

3.4.16. user-provisioned infrastructure でのインストールの完了

Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。

前提条件

  • コントロールプレーンが初期化されています。
  • Operator の初期設定を完了済みです。

手順

  1. 以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.16.0    True        False         False      19m
    baremetal                                  4.16.0    True        False         False      37m
    cloud-credential                           4.16.0    True        False         False      40m
    cluster-autoscaler                         4.16.0    True        False         False      37m
    config-operator                            4.16.0    True        False         False      38m
    console                                    4.16.0    True        False         False      26m
    csi-snapshot-controller                    4.16.0    True        False         False      37m
    dns                                        4.16.0    True        False         False      37m
    etcd                                       4.16.0    True        False         False      36m
    image-registry                             4.16.0    True        False         False      31m
    ingress                                    4.16.0    True        False         False      30m
    insights                                   4.16.0    True        False         False      31m
    kube-apiserver                             4.16.0    True        False         False      26m
    kube-controller-manager                    4.16.0    True        False         False      36m
    kube-scheduler                             4.16.0    True        False         False      36m
    kube-storage-version-migrator              4.16.0    True        False         False      37m
    machine-api                                4.16.0    True        False         False      29m
    machine-approver                           4.16.0    True        False         False      37m
    machine-config                             4.16.0    True        False         False      36m
    marketplace                                4.16.0    True        False         False      37m
    monitoring                                 4.16.0    True        False         False      29m
    network                                    4.16.0    True        False         False      38m
    node-tuning                                4.16.0    True        False         False      37m
    openshift-apiserver                        4.16.0    True        False         False      32m
    openshift-controller-manager               4.16.0    True        False         False      30m
    openshift-samples                          4.16.0    True        False         False      32m
    operator-lifecycle-manager                 4.16.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
    service-ca                                 4.16.0    True        False         False      38m
    storage                                    4.16.0    True        False         False      37m

    あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 30m0s for the cluster to initialize...

    Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
  2. Kubernetes API サーバーが Pod と通信していることを確認します。

    1. すべての Pod のリストを表示するには、以下のコマンドを使用します。

      $ oc get pods --all-namespaces

      出力例

      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

    2. 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。

      $ oc logs <pod_name> -n <namespace> 1
      1
      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

  3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

    詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。

クラスターのインストールが完了したら、コンピュートマシンの vSphere への追加 に従って、コンピュートマシンをさらに追加できます。

3.4.17. コントロールプレーンノードの vSphere DRS 非アフィニティールールの設定

vSphere Distributed Resource Scheduler (DRS) 非アフィニティールールを設定して、OpenShift Container Platform コントロールプレーンノードでより高い可用性をサポートできます。非アフィニティールールにより、OpenShift Container Platform コントロールプレーンノードの vSphere 仮想マシンが同じ vSphere ノードにスケジュールされないようにします。

重要
  • 以下の情報はコンピュート DRS にのみ適用され、ストレージ DRS には適用されません。
  • govc コマンドは、VMware で利用可能なオープンソースのコマンドであり、Red Hat からは利用できません。govc コマンドは、Red Hat サポートではサポートされません。
  • govc のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイトを参照してください。

以下のコマンドを実行して anti-affinity ルールを作成します。

コマンドの例

$ govc cluster.rule.create \
  -name openshift4-control-plane-group \
  -dc MyDatacenter -cluster MyCluster \
  -enable \
  -anti-affinity master-0 master-1 master-2

ルールを作成すると、コントロールプレーンノードは vSphere によって自動的に移行されるため、同じホストで実行されることはありません。vSphere が新しいルールを調整するまで、しばらく時間がかかる場合があります。コマンドを正しく補完する方法は、以下の手順に示します。

注記

移行は自動的に行われ、移行が完了するまで短い OpenShift API 停止またはレイテンシーが発生する可能性があります。

vSphere DRS の非アフィニティールールは、コントロールプレーンの仮想マシン名が変更された場合や、新しい vSphere クラスターへの移行時に手動で更新する必要があります。

手順

  1. 以下のコマンドを実行して、既存の DRS 非アフィニティールールを削除します。

    $ govc cluster.rule.remove \
      -name openshift4-control-plane-group \
      -dc MyDatacenter -cluster MyCluster

    出力例

    [13-10-22 09:33:24] Reconfigure /MyDatacenter/host/MyCluster...OK

  2. 以下のコマンドを実行して、更新された名前でルールを再度作成します。

    $ govc cluster.rule.create \
      -name openshift4-control-plane-group \
      -dc MyDatacenter -cluster MyOtherCluster \
      -enable \
      -anti-affinity master-0 master-1 master-2

3.4.18. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

3.4.19. 次のステップ

3.5. user-provisioned infrastructure のネットワークが制限された環境での vSphere へのクラスターのインストール

OpenShift Container Platform バージョン 4.16 では、制限されたネットワーク内で、独自にプロビジョニングする VMware vSphere インフラストラクチャーにクラスターをインストールできます。

注記

OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。

重要

user-provisioned infrastructure のインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、vSphere プラットフォームおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。user-provisioned infrastructure のインストール手順をガイドとして使用します。他の方法で必要なリソースを作成することもできます。

3.5.1. 前提条件

  • user-provisioned infrastructure を使用したクラスターのインストールの準備 のタスクを完了した。
  • VMware プラットフォームのライセンスを確認した。Red Hat は VMware ライセンスに制限を設けていませんが、一部の VMware インフラストラクチャーコンポーネントにはライセンスが必要です。
  • OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
  • クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
  • ミラーホストでレジストリーを作成 しており、使用しているバージョンの OpenShift Container Platform の imageContentSources データを取得している。

    重要

    インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。

  • クラスターの 永続ストレージ をプロビジョニングした。プライベートイメージレジストリーをデプロイするには、ストレージで ReadWriteMany アクセスモードを指定する必要があります。
  • インストールを完了するには、vSphere ホストに Red Hat Enterprise Linux CoreOS(RHCOS) OVA をアップロードする必要があります。このプロセスを完了するマシンには、vCenter および ESXi ホストのポート 443 にアクセスできる必要があります。ポート 443 にアクセスできることを確認している。
  • ファイアウォールを使用する場合は、ポート 443 にアクセスできることを管理者に確認している。インストールを成功させるには、コントロールプレーンノードがポート 443 で vCenter および ESXi ホストに到達できる必要があります。
  • クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。

    注記

    プロキシーを設定する場合は、このサイトリストも確認してください。

3.5.2. ネットワークが制限された環境でのインストールについて

OpenShift Container Platform 4.16 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、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 を実行することを検討してください。このテストが完了すると、ネットワークが制限されたインストール時に発生する可能性のある問題の切り分けやトラブルシューティングがより容易になります。

3.5.2.1. その他の制限

ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。

  • ClusterVersion ステータスには Unable to retrieve available updates エラーが含まれます。
  • デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。

3.5.3. OpenShift Container Platform のインターネットアクセス

OpenShift Container Platform 4.16 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。

インターネットへのアクセスは以下を実行するために必要です。

  • OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
  • クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
  • クラスターの更新を実行するために必要なパッケージを取得します。

3.5.4. VMware vSphere のリージョンとゾーンの有効化

OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

重要

VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。

デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。

次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。

  • 障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
  • リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。
  • ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。
注記

install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。

リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。

次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。

データセンター (リージョン)クラスター (ゾーン)タグ

米国東部

us-east-1

us-east-1a

us-east-1b

us-east-2

us-east-2a

us-east-2b

us-west

us-west-1

us-west-1a

us-west-1b

us-west-2

us-west-2a

us-west-2b

3.5.5. インストール設定ファイルの手動作成

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

重要

Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。

前提条件

  • ローカルマシンには、インストールプログラムに提供する SSH 公開鍵があります。このキーは、デバッグおよび障害復旧のためにクラスターノードへの SSH 認証に使用されます。
  • OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットを取得しています。
  • リポジトリーのミラーリングに使用するコマンドの出力で imageContentSources セクションを取得します。
  • ミラーレジストリーの証明書の内容を取得する。

手順

  1. 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。

    $ mkdir <installation_directory>
    重要

    ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。

  2. 提供されるサンプルの 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 ファイルが確実に作成されます。
  3. install-config.yaml ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。

    重要

    install-config.yaml ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。

3.5.5.1. VMware vSphere のサンプル install-config.yaml ファイル

install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。

additionalTrustBundlePolicy: Proxyonly
apiVersion: v1
baseDomain: example.com 1
compute: 2
- architecture: amd64
  name: <worker_node>
  platform: {}
  replicas: 0 3
controlPlane: 4
  architecture: amd64
  name: <parent_node>
  platform: {}
  replicas: 3 5
metadata:
  creationTimestamp: null
  name: test 6
networking:
---
platform:
  vsphere:
    failureDomains: 7
    - name: <failure_domain_name>
      region: <default_region_name>
      server: <fully_qualified_domain_name>
      topology:
        computeCluster: "/<data_center>/host/<cluster>"
        datacenter: <data_center> 8
        datastore: "/<data_center>/datastore/<datastore>" 9
        networks:
        - <VM_Network_name>
        resourcePool: "/<data_center>/host/<cluster>/Resources/<resourcePool>" 10
        folder: "/<data_center_name>/vm/<folder_name>/<subfolder_name>" 11
      zone: <default_zone_name>
    vcenters:
    - datacenters:
      - <data_center>
      password: <password> 12
      port: 443
      server: <fully_qualified_domain_name> 13
      user: administrator@vsphere.local
    diskType: thin 14
fips: false 15
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 16
sshKey: 'ssh-ed25519 AAAA...' 17
additionalTrustBundle: | 18
  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources: 19
- mirrors:
  - <mirror_host_name>:<mirror_port>/<repo_name>/release
  source: <source_image_1>
- mirrors:
  - <mirror_host_name>:<mirror_port>/<repo_name>/release-images
  source: <source_image_2>
1
クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
2 4
controlPlane セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。両方のセクションで単一のマシンプールが定義されるため、使用されるコントロールプレーンは 1 つだけです。OpenShift Container Platform は、複数のコンピューティングプールの定義をサポートしていません。
3
replicas パラメーターの値を 0 に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
5
クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
6
DNS レコードに指定したクラスター名。
7
リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
8
vSphere データセンター。
9
仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。
重要

データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。

複数のデータストアにわたって仮想マシンを指定する必要がある場合は、datastore オブジェクトを使用して、クラスターの install-config.yaml 設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

10
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス (例: /<data_center_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>)。値を指定しない場合、リソースはクラスターのルート /example_data_center/host/example_cluster/Resources にインストールされます。
11
オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例: /<data_center_name>/vm/<folder_name>/<subfolder_name>)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin という名前のデフォルトの StorageClass オブジェクトを使用したくない場合は、install-config.yaml ファイルから folder パラメーターを省略できます。
12
vSphere ユーザーに関連付けられたパスワード。
13
vCenter サーバーの完全修飾ホスト名または IP アドレス。
重要

Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。

14
vSphere ディスクのプロビジョニング方法。
15
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 暗号化ライブラリーを使用します。

16
<local_registry> には、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000<credentials> に、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。
17
Red Hat Enterprise Linux CoreOS (RHCOS) の core ユーザーのデフォルト SSH キーの公開部分。
注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

18
ミラーレジストリーに使用した証明書ファイルの内容を指定します。
19
リポジトリーのミラーリングに使用するコマンドの出力の imageContentSources セクションを指定します。
3.5.5.2. インストール時のクラスター全体のプロキシーの設定

実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。

前提条件

  • 既存の install-config.yaml ファイルがある。
  • クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを Proxy オブジェクトの spec.noProxy フィールドに追加している。

    注記

    Proxy オブジェクトの status.noProxy フィールドには、インストール設定の networking.machineNetwork[].cidrnetworking.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) も設定されます。

手順

  1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 1
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 2
      noProxy: example.com 3
    additionalTrustBundle: | 4
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
    1
    クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。
    2
    クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
    3
    プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
    4
    指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは 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
  2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。

注記

cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。

3.5.5.3. VMware vCenter のリージョンとゾーンの設定

デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。

OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。

重要

この例では、govc コマンドを使用します。govc コマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは govc コマンドを保守していません。govc のダウンロードとインストールの手順は、VMware ドキュメント Web サイトを参照してください。

前提条件

  • 既存の install-config.yaml インストール設定ファイルがあります。

    重要

    VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。

手順

  1. 次の govc コマンドラインツールコマンドを入力して、openshift-region および openshift-zone vCenter タグカテゴリーを作成します。

    重要

    openshift-region および openshift-zone vCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。

    $ govc tags.category.create -d "OpenShift region" openshift-region
    $ govc tags.category.create -d "OpenShift zone" openshift-zone
  2. クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。

    $ govc tags.create -c <region_tag_category> <region_tag>
  3. クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。

    $ govc tags.create -c <zone_tag_category> <zone_tag>
  4. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにリージョンタグをアタッチします。

    $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>
  5. 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。

    $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/vcs-mdcnc-workload-1
  6. インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。

vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル

---
compute:
---
  vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
controlPlane:
---
vsphere:
      zones:
        - "<machine_pool_zone_1>"
        - "<machine_pool_zone_2>"
---
platform:
  vsphere:
    vcenters:
---
    datacenters:
      - <data_center_1_name>
      - <data_center_2_name>
    failureDomains:
    - name: <machine_pool_zone_1>
      region: <region_tag_1>
      zone: <zone_tag_1>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_1>
        computeCluster: "/<data_center_1>/host/<cluster1>"
        networks:
        - <VM_Network1_name>
        datastore: "/<data_center_1>/datastore/<datastore1>"
        resourcePool: "/<data_center_1>/host/<cluster1>/Resources/<resourcePool1>"
        folder: "/<data_center_1>/vm/<folder1>"
    - name: <machine_pool_zone_2>
      region: <region_tag_2>
      zone: <zone_tag_2>
      server: <fully_qualified_domain_name>
      topology:
        datacenter: <data_center_2>
        computeCluster: "/<data_center_2>/host/<cluster2>"
        networks:
        - <VM_Network2_name>
        datastore: "/<data_center_2>/datastore/<datastore2>"
        resourcePool: "/<data_center_2>/host/<cluster2>/Resources/<resourcePool2>"
        folder: "/<data_center_2>/vm/<folder2>"
---

3.5.6. 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 インストール設定ファイルを作成していること。

手順

  1. OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    <installation_directory> には、作成した install-config.yaml ファイルが含まれるインストールディレクトリーを指定します。
  2. コントロールプレーンマシン、コンピュートマシンセット、およびコントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml

    これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。

    • コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
  3. <installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

    1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
    2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
    3. ファイルを保存し、終了します。
  4. Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。

    $ ./openshift-install create ignition-configs --dir <installation_directory> 1
    1
    <installation_directory> には、同じインストールディレクトリーを指定します。

    Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。kubeadmin-password および kubeconfig ファイルが ./<installation_directory>/auth ディレクトリーに作成されます。

    .
    ├── auth
    │   ├── kubeadmin-password
    │   └── kubeconfig
    ├── bootstrap.ign
    ├── master.ign
    ├── metadata.json
    └── worker.ign

3.5.7. chrony タイムサービスの設定

chrony タイムサービス (chronyd) で使用されるタイムサーバーおよび関連する設定は、chrony.conf ファイルのコンテンツを変更し、それらのコンテンツをマシン設定としてノードに渡して設定する必要があります。

手順

  1. chrony.conf ファイルのコンテンツを含む Butane 設定を作成します。たとえば、ワーカーノードで chrony を設定するには、99-worker-chrony.bu ファイルを作成します。

    注記

    Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

    variant: openshift
    version: 4.16.0
    metadata:
      name: 99-worker-chrony 1
      labels:
        machineconfiguration.openshift.io/role: worker 2
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644 3
        overwrite: true
        contents:
          inline: |
            pool 0.rhel.pool.ntp.org iburst 4
            driftfile /var/lib/chrony/drift
            makestep 1.0 3
            rtcsync
            logdir /var/log/chrony
    1 2
    コントロールプレーンノードでは、これらの両方の場所で worker の代わりに master を使用します。
    3
    マシン設定ファイルの mode フィールドに 8 進数の値でモードを指定します。ファイルを作成し、変更を適用すると、mode は 10 進数の値に変換されます。oc get mc <mc-name> -o yaml コマンドで YAML ファイルを確認できます。
    4
    DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。
  2. Butane を使用して、ノードに配信される設定を含む MachineConfig オブジェクトファイル (99-worker-chrony.yaml) を生成します。

    $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
  3. 以下の 2 つの方法のいずれかで設定を適用します。

    • クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、MachineConfig オブジェクトファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を続行します。
    • クラスターがすでに実行中の場合は、ファイルを適用します。

      $ oc apply -f ./99-worker-chrony.yaml

3.5.8. インフラストラクチャー名の抽出

Ignition 設定ファイルには、VMware vSphere でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。クラスター ID を仮想マシンフォルダーの名前として使用する予定がある場合、これを抽出する必要があります。

前提条件

  • OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
  • クラスターの Ignition 設定ファイルを生成している。
  • jq パッケージをインストールしている。

手順

  • Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。

    $ jq -r .infraID <installation_directory>/metadata.json 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    openshift-vw9j6 1

    1
    このコマンドの出力はクラスター名とランダムな文字列です。

3.5.9. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始

OpenShift Container Platform を VMware vSphere の user-provisioned infrastructure にインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を vSphere ホストにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。

前提条件

  • クラスターの Ignition 設定ファイルを取得している。
  • お使いのコンピューターからアクセスでき、作成するマシンがアクセスできる HTTP サーバーへのアクセス権がある。
  • vSphere クラスター を作成している。

手順

  1. <installation_directory>/bootstrap.ign という名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。
  2. ブートストラップノードの以下の二次的な Ignition 設定ファイルを、<installation_directory>/merge-bootstrap.ign としてコンピューターに保存します。

    {
      "ignition": {
        "config": {
          "merge": [
            {
              "source": "<bootstrap_ignition_config_url>", 1
              "verification": {}
            }
          ]
        },
        "timeouts": {},
        "version": "3.2.0"
      },
      "networkd": {},
      "passwd": {},
      "storage": {},
      "systemd": {}
    }
    1
    ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。

    ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。

  3. インストールプログラムにより作成された次の Ignition 設定ファイルを見つけます。

    • <installation_directory>/master.ign
    • <installation_directory>/worker.ign
    • <installation_directory>/merge-bootstrap.ign
  4. Ignition 設定ファイルを Base64 エンコーディングに変換します。この手順の後半で、これらのファイルを VM の追加の設定パラメーター guestinfo.ignition.config.data に追加する必要があります。

    たとえば、Linux オペレーティングシステムを使用する場合、base64 コマンドを使用してファイルをエンコードできます。

    $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64
    $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64
    $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64
    重要

    インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。

  5. RHCOS OVA イメージを取得します。イメージは、RHCOS イメージミラー ページから入手できます。

    重要

    RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

    ファイル名には、rhcos-vmware.<architecture>.ova 形式の OpenShift Container Platform のバージョン番号が含まれます。

  6. vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。

    1. VMs and Templates ビューをクリックします。
    2. データセンターの名前を右クリックします。
    3. New FolderNew VM and Template Folder をクリックします。
    4. 表示されるウィンドウで、フォルダー名を入力します。install-config.yaml ファイルに既存のフォルダーを指定していない場合には、インフラストラクチャー ID と同じ名前を持つフォルダーを作成します。このフォルダー名を使用すると、vCenter はその Workspace 設定に適した場所にあるストレージを動的にプロビジョニングします。
  7. vSphere クライアントで、OVA イメージのテンプレートを作成してから、必要に応じてテンプレートのクローンを作成します。

    注記

    以下の手順では、テンプレートを作成してから、すべてのクラスターマシンのテンプレートのクローンを作成します。次に、仮想マシンのプロビジョニング時にクローン作成されたマシンタイプの Ignition 設定ファイルの場所を指定します。

    1. Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template を選択します。
    2. Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
    3. Select a name and folder タブで、Template-RHCOS などの Virtual machine name をテンプレートに設定します。vSphere クラスターの名前をクリックし、直前の手順で作成したフォルダーを選択します。
    4. Select a compute resource タブで、vSphere クラスターの名前をクリックします。
    5. Select storage タブで、仮想マシンのストレージオプションを設定します。

      • ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
      • install-config.yaml ファイルで指定したデータストアを選択します。
      • 仮想マシンを暗号化する場合は、Encrypt this virtual machine を選択します。詳細は、「仮想マシンを暗号化するための要件」セクションを参照してください。
    6. Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。
    7. OVF テンプレートの作成時には、Customize template タブで値を指定したり、テンプレートに追加の設定をしないようにしてください。

      重要

      元の仮想マシンテンプレートは開始しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規 RHCOS マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。

  8. 必要に応じて、仮想マシンテンプレートで設定された仮想ハードウェアバージョンを更新します。詳細は、VMware ドキュメントの Upgrading a virtual machine to the latest hardware version を参照してください。

    重要

    必要に応じて、仮想マシンを作成する前に、仮想マシンテンプレートのハードウェアバージョンをバージョン 15 に更新することが推奨されます。vSphere で実行しているクラスターノード用にハードウェアバージョン 13 を使用することは非推奨となりました。インポートしたテンプレートがハードウェアバージョン 13 にデフォルト設定されている場合は、仮想マシンテンプレートをハードウェアバージョン 15 にアップグレードする前に、ESXi ホストが 6.7U3 以降を使用していることを確認する必要があります。vSphere のバージョンが 6.7U3 未満の場合は、このアップグレード手順を省略できます。ただし、OpenShift Container Platform の今後のバージョンでは、ハードウェアバージョン 13 および vSphere バージョンのサポートが 6.7U3 未満になる予定です。

  9. テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。

    1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
    2. Select a name and folder タブで、仮想マシンの名前を指定します。control-plane-0 または compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

      注記

      vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

    3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
    4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
    5. Select clone options で、Customize this virtual machine's hardware を選択します。
    6. Customize hardware タブで、Advanced Parameters をクリックします。

      重要

      次の設定の提案は、例としてのみ使用されます。クラスター管理者は、クラスターに課せられるリソース需要に従ってリソースを設定する必要があります。クラスターリソースを最適に管理するには、クラスターのルートリソースプールからリソースプールを作成することを検討してください。

      • オプション: vSphere でデフォルトの DHCP ネットワークを上書きします。静的 IP ネットワークを有効にするには、以下を実行します。

        • 静的 IP 設定を行います。

          コマンドの例

          $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"

          コマンドの例

          $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"

        • vSphere で OVA から仮想マシンを起動する前に、guestinfo.afterburn.initrd.network-kargs プロパティーを設定します。

          コマンドの例

          $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"

      • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

        • guestinfo.ignition.config.data: この手順で先程作成した、base-64 でエンコードされたファイルを見つけて、このマシンタイプに関する base-64 でエンコードされた Ignition 設定ファイルの内容を貼り付けます。
        • guestinfo.ignition.config.data.encoding: base64 を指定します。
        • disk.EnableUUID: TRUE を指定します。
        • stealclock.enable: このパラメーターが定義されていない場合は、追加して TRUE を指定します。
        • クラスターの root リソースプールから子リソースプールを作成します。この子リソースプールでリソースの割り当てを実行します。
    7. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
    8. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
    9. Virtual Machines タブで仮想マシンを右クリックし、PowerPower On を選択します。
    10. コンソール出力をチェックして、Ignition が実行されたことを確認します。

      コマンドの例

      Ignition: ran on 2022/03/14 14:48:33 UTC (this boot)
      Ignition: user-provided config was applied

次のステップ

  • 各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。

    重要

    この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。

3.5.10. vSphere でのコンピュートマシンのクラスターへの追加

コンピュートマシンを VMware vSphere の user-provisioned OpenShift Container Platform クラスターに追加することができます。

vSphere テンプレートを OpenShift Container Platform クラスターにデプロイした後に、そのクラスター内のマシンの仮想マシン (VM) をデプロイできます。

前提条件

  • コンピュートマシンの base64 でエンコードされた Ignition ファイルを取得します。
  • クラスター用に作成した vSphere テンプレートにアクセスできる必要があります。

手順

  1. テンプレートの名前を右クリックし、CloneClone to Virtual Machine をクリックします。
  2. Select a name and folder タブで、仮想マシンの名前を指定します。compute-1 などのように、マシンタイプを名前に含めることができるかもしれません。

    注記

    vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。

  3. Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
  4. Select a compute resource タブで、データセンター内のホストの名前を選択します。
  5. Select storage タブで、設定ファイルとディスクファイル用のストレージを選択します。
  6. Select clone options で、Customize this virtual machine's hardware を選択します。
  7. Customize hardware タブで、Advanced Parameters をクリックします。

    • Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。

      • guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
      • guestinfo.ignition.config.data.encoding: base64 を指定します。
      • disk.EnableUUID: TRUE を指定します。
  8. Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。多くのネットワークが存在する場合は、Add New Device > Network Adapter を選択し、New Network メニュー項目に表示されるフィールドにネットワーク情報を入力します。
  9. 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
  10. Virtual Machines タブで仮想マシンを右クリックし、PowerPower On を選択します。

次のステップ

  • 継続してクラスター用の追加のコンピュートマシンを作成します。

3.5.11. ディスクパーティション設定

ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、RHCOS をインストールして作成されます。この場合、OpenShift Container Platform インストーラーでは、ディスクパーティションの設定が許可されます。

ただし、以下は、OpenShift Container Platform ノードのインストール時に、デフォルトのパーティション設定を上書きするために介入が必要と思われる 2 つのケースになります。

  • 別個のパーティションの作成: 空のディスクへのグリーンフィールドインストールの場合は、別のストレージをパーティションに追加する必要がある場合があります。これは、/var または /var/lib/etcd などの /var のサブディレクトリー (両方ではない) を個別のパーティションとして作成する場合にのみ正式にサポートされます。

    重要

    ディスクサイズが 100 GB を超える場合、特にディスクサイズが 1 TB を超える場合は、別の /var パーティションを作成します。詳細は、「個別の /var パーティションの作成」およびこちらの Red Hat ナレッジベースの記事 を参照してください。

    重要

    Kubernetes は 2 つのファイルシステムパーティションのみをサポートします。元の設定に複数のパーティションを追加すると、Kubernetes はそれらをすべて監視できません。

  • 既存のパーティションの保持: ブラウンフィールドインストールで、既存のノードに OpenShift Container Platform を再インストールし、以前のオペレーティングシステムからのデータパーティションを維持する必要がある場合、既存のデータパーティションを保持できる coreos-installer へのブート引数とオプションの両方があります。
個別の /var パーティションの作成

一般的に、OpenShift Container Platform のディスクパーティション設定は、インストーラーに任せる必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。

OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。

  • /var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。
  • /var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。
  • /var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。

    重要

    ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の /var パーティションを作成します。

/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。

/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。

手順

  1. OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。

    $ mkdir $HOME/clusterconfig
  2. openshift-install を実行して、manifest および openshift のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。

    $ openshift-install create manifests --dir $HOME/clusterconfig
    ? SSH Public Key ...
    $ ls $HOME/clusterconfig/openshift/
    99_kubeadmin-password-secret.yaml
    99_openshift-cluster-api_master-machines-0.yaml
    99_openshift-cluster-api_master-machines-1.yaml
    99_openshift-cluster-api_master-machines-2.yaml
    ...
  3. 追加のパーティションを設定する Butane 設定を作成します。たとえば、$HOME/clusterconfig/98-var-partition.bu ファイルに名前を付け、ディスクのデバイス名を worker システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var ディレクトリーを別のパーティションにマウントします。

    variant: openshift
    version: 4.16.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-var-partition
    storage:
      disks:
      - device: /dev/disk/by-id/<device_name> 1
        partitions:
        - label: var
          start_mib: <partition_start_offset> 2
          size_mib: <partition_size> 3
          number: 5
      filesystems:
        - device: /dev/disk/by-partlabel/var
          path: /var
          format: xfs
          mount_options: [defaults, prjquota] 4
          with_mount_unit: true
    1
    パーティションを設定する必要のあるディスクのストレージデバイス名。
    2
    データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
    3
    データパーティションのサイズ (メビバイト単位)。
    4
    コンテナーストレージに使用されるファイルシステムでは、prjquota マウントオプションを有効にする必要があります。
    注記

    個別の /var パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。

  4. Butane config からマニフェストを作成し、clusterconfig/openshift ディレクトリーに保存します。たとえば、以下のコマンドを実行します。

    $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
  5. openshift-install を再度実行し、manifest および openshift のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。

    $ openshift-install create ignition-configs --dir $HOME/clusterconfig
    $ ls $HOME/clusterconfig/
    auth  bootstrap.ign  master.ign  metadata.json  worker.ign

Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールために vSphere インストール手順への入力として使用できます。

3.5.12. ブートストラッププロセスの完了まで待機する

OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。

前提条件

  • クラスターの Ignition 設定ファイルを作成している。
  • 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
  • インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
  • RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。

手順

  1. ブートストラッププロセスをモニターします。

    $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ 1
        --log-level=info 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なるインストールの詳細情報を表示するには、info ではなく、warndebug、または error を指定します。

    出力例

    INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
    INFO API v1.29.4 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    INFO It is now safe to remove the bootstrap resources

    Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。

  2. ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。

    重要

    この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。

3.5.13. CLI の使用によるクラスターへのログイン

クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc CLI をインストールしていること。

手順

  1. kubeadmin 認証情報をエクスポートします。

    $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
  2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

    $ oc whoami

    出力例

    system:admin

3.5.14. マシンの証明書署名要求の承認

マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。

前提条件

  • マシンがクラスターに追加されています。

手順

  1. クラスターがマシンを認識していることを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  63m  v1.29.4
    master-1  Ready     master  63m  v1.29.4
    master-2  Ready     master  64m  v1.29.4

    出力には作成したすべてのマシンがリスト表示されます。

    注記

    上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

  2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

    $ oc get csr

    出力例

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

    この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。

  3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

    注記

    CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

    注記

    ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc execoc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      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
      注記

      一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

  4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

    $ oc get csr

    出力例

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

  5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

    • それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。

      $ oc adm certificate approve <csr_name> 1
      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
  6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

    $ oc get nodes

    出力例

    NAME      STATUS    ROLES   AGE  VERSION
    master-0  Ready     master  73m  v1.29.4
    master-1  Ready     master  73m  v1.29.4
    master-2  Ready     master  74m  v1.29.4
    worker-0  Ready     worker  11m  v1.29.4
    worker-1  Ready     worker  11m  v1.29.4

    注記

    サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

関連情報

3.5.15. Operator の初期設定

コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。

前提条件

  • コントロールプレーンが初期化されています。

手順

  1. クラスターコンポーネントがオンラインになることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.16.0    True        False         False      19m
    baremetal                                  4.16.0    True        False         False      37m
    cloud-credential                           4.16.0    True        False         False      40m
    cluster-autoscaler                         4.16.0    True        False         False      37m
    config-operator                            4.16.0    True        False         False      38m
    console                                    4.16.0    True        False         False      26m
    csi-snapshot-controller                    4.16.0    True        False         False      37m
    dns                                        4.16.0    True        False         False      37m
    etcd                                       4.16.0    True        False         False      36m
    image-registry                             4.16.0    True        False         False      31m
    ingress                                    4.16.0    True        False         False      30m
    insights                                   4.16.0    True        False         False      31m
    kube-apiserver                             4.16.0    True        False         False      26m
    kube-controller-manager                    4.16.0    True        False         False      36m
    kube-scheduler                             4.16.0    True        False         False      36m
    kube-storage-version-migrator              4.16.0    True        False         False      37m
    machine-api                                4.16.0    True        False         False      29m
    machine-approver                           4.16.0    True        False         False      37m
    machine-config                             4.16.0    True        False         False      36m
    marketplace                                4.16.0    True        False         False      37m
    monitoring                                 4.16.0    True        False         False      29m
    network                                    4.16.0    True        False         False      38m
    node-tuning                                4.16.0    True        False         False      37m
    openshift-apiserver                        4.16.0    True        False         False      32m
    openshift-controller-manager               4.16.0    True        False         False      30m
    openshift-samples                          4.16.0    True        False         False      32m
    operator-lifecycle-manager                 4.16.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
    service-ca                                 4.16.0    True        False         False      38m
    storage                                    4.16.0    True        False         False      37m

  2. 利用不可の Operator を設定します。
3.5.15.1. デフォルトの OperatorHub カタログソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。

手順

  • disableAllDefaultSources: trueOperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。AdministrationCluster SettingsConfigurationOperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。

3.5.15.2. イメージレジストリーストレージの設定

Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。

実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。

アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。

3.5.15.2.1. VMware vSphere のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • VMware vSphere 上のクラスター。
  • Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。ReadWriteOnce アクセスでは、レジストリーが Recreate ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • "100Gi" の容量が必要です。
重要

テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリックストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry -l docker-registry=default

    出力例

    No resourses found in openshift-image-registry namespace

    注記

    出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim: 1

    1
    image-registry-storage 永続ボリューム要求 (PVC) の自動作成を許可するには、claim フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry

    出力例

    NAME             VERSION                              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    image-registry   4.7                                  True        False         False      6h50m

3.5.15.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定

Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。

手順

  • イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
    警告

    実稼働用以外のクラスターにのみこのオプションを設定します。

    Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、oc patch コマンドは以下のエラーを出して失敗します。

    Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found

    数分待機した後に、このコマンドを再び実行します。

3.5.15.2.3. VMware vSphere のブロックレジストリーストレージの設定

イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate ロールアウトストラテジーを使用できます。

重要

ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。

手順

  1. 次のコマンドを入力してイメージレジストリーストレージをブロックストレージタイプとして設定し、レジストリーにパッチを適用して Recreate ロールアウトストラテジーを使用し、1 つのレプリカのみで実行されるようにします。

    $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
  2. ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。

    1. 以下の内容で pvc.yaml ファイルを作成して VMware vSphere PersistentVolumeClaim オブジェクトを定義します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: image-registry-storage 1
        namespace: openshift-image-registry 2
      spec:
        accessModes:
        - ReadWriteOnce 3
        resources:
          requests:
            storage: 100Gi 4
      1
      PersistentVolumeClaim オブジェクトを表す一意の名前。
      2
      PersistentVolumeClaim オブジェクトの namespace (openshift-image-registry)。
      3
      永続ボリューム要求のアクセスモード。ReadWriteOnce では、ボリュームは単一ノードによって読み取り/書き込みパーミッションでマウントできます。
      4
      永続ボリューム要求のサイズ。
    2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

      $ oc create -f pvc.yaml -n openshift-image-registry
  3. 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。

    $ oc edit config.imageregistry.operator.openshift.io -o yaml

    出力例

    storage:
      pvc:
        claim: 1

    1
    カスタム PVC を作成することにより、image-registry-storage PVC のデフォルトの自動作成の claim フィールドを空のままにできます。

正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。

3.5.16. user-provisioned infrastructure でのインストールの完了

Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。

前提条件

  • コントロールプレーンが初期化されています。
  • Operator の初期設定を完了済みです。

手順

  1. 以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。

    $ watch -n5 oc get clusteroperators

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    authentication                             4.16.0    True        False         False      19m
    baremetal                                  4.16.0    True        False         False      37m
    cloud-credential                           4.16.0    True        False         False      40m
    cluster-autoscaler                         4.16.0    True        False         False      37m
    config-operator                            4.16.0    True        False         False      38m
    console                                    4.16.0    True        False         False      26m
    csi-snapshot-controller                    4.16.0    True        False         False      37m
    dns                                        4.16.0    True        False         False      37m
    etcd                                       4.16.0    True        False         False      36m
    image-registry                             4.16.0    True        False         False      31m
    ingress                                    4.16.0    True        False         False      30m
    insights                                   4.16.0    True        False         False      31m
    kube-apiserver                             4.16.0    True        False         False      26m
    kube-controller-manager                    4.16.0    True        False         False      36m
    kube-scheduler                             4.16.0    True        False         False      36m
    kube-storage-version-migrator              4.16.0    True        False         False      37m
    machine-api                                4.16.0    True        False         False      29m
    machine-approver                           4.16.0    True        False         False      37m
    machine-config                             4.16.0    True        False         False      36m
    marketplace                                4.16.0    True        False         False      37m
    monitoring                                 4.16.0    True        False         False      29m
    network                                    4.16.0    True        False         False      38m
    node-tuning                                4.16.0    True        False         False      37m
    openshift-apiserver                        4.16.0    True        False         False      32m
    openshift-controller-manager               4.16.0    True        False         False      30m
    openshift-samples                          4.16.0    True        False         False      32m
    operator-lifecycle-manager                 4.16.0    True        False         False      37m
    operator-lifecycle-manager-catalog         4.16.0    True        False         False      37m
    operator-lifecycle-manager-packageserver   4.16.0    True        False         False      32m
    service-ca                                 4.16.0    True        False         False      38m
    storage                                    4.16.0    True        False         False      37m

    あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。

    $ ./openshift-install --dir <installation_directory> wait-for install-complete 1
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

    出力例

    INFO Waiting up to 30m0s for the cluster to initialize...

    Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。

    重要
    • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
    • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
  2. Kubernetes API サーバーが Pod と通信していることを確認します。

    1. すべての Pod のリストを表示するには、以下のコマンドを使用します。

      $ oc get pods --all-namespaces

      出力例

      NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
      openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
      openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
      openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
      openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
      openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
      ...

    2. 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。

      $ oc logs <pod_name> -n <namespace> 1
      1
      直前のコマンドの出力にあるように、Pod 名および namespace を指定します。

      Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。

  3. FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。

    詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。

  4. Cluster registration ページでクラスターを登録します。

クラスターのインストールが完了したら、コンピュートマシンの vSphere への追加 に従って、コンピュートマシンをさらに追加できます。

3.5.17. コントロールプレーンノードの vSphere DRS 非アフィニティールールの設定

vSphere Distributed Resource Scheduler (DRS) 非アフィニティールールを設定して、OpenShift Container Platform コントロールプレーンノードでより高い可用性をサポートできます。非アフィニティールールにより、OpenShift Container Platform コントロールプレーンノードの vSphere 仮想マシンが同じ vSphere ノードにスケジュールされないようにします。

重要
  • 以下の情報はコンピュート DRS にのみ適用され、ストレージ DRS には適用されません。
  • govc コマンドは、VMware で利用可能なオープンソースのコマンドであり、Red Hat からは利用できません。govc コマンドは、Red Hat サポートではサポートされません。
  • govc のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイトを参照してください。

以下のコマンドを実行して anti-affinity ルールを作成します。

コマンドの例

$ govc cluster.rule.create \
  -name openshift4-control-plane-group \
  -dc MyDatacenter -cluster MyCluster \
  -enable \
  -anti-affinity master-0 master-1 master-2

ルールを作成すると、コントロールプレーンノードは vSphere によって自動的に移行されるため、同じホストで実行されることはありません。vSphere が新しいルールを調整するまで、しばらく時間がかかる場合があります。コマンドを正しく補完する方法は、以下の手順に示します。

注記

移行は自動的に行われ、移行が完了するまで短い OpenShift API 停止またはレイテンシーが発生する可能性があります。

vSphere DRS の非アフィニティールールは、コントロールプレーンの仮想マシン名が変更された場合や、新しい vSphere クラスターへの移行時に手動で更新する必要があります。

手順

  1. 以下のコマンドを実行して、既存の DRS 非アフィニティールールを削除します。

    $ govc cluster.rule.remove \
      -name openshift4-control-plane-group \
      -dc MyDatacenter -cluster MyCluster

    出力例

    [13-10-22 09:33:24] Reconfigure /MyDatacenter/host/MyCluster...OK

  2. 以下のコマンドを実行して、更新された名前でルールを再度作成します。

    $ govc cluster.rule.create \
      -name openshift4-control-plane-group \
      -dc MyDatacenter -cluster MyOtherCluster \
      -enable \
      -anti-affinity master-0 master-1 master-2

3.5.18. OpenShift Container Platform の Telemetry アクセス

OpenShift Container Platform 4.16 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。

OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。

関連情報

3.5.19. 次のステップ

第4章 Assisted Installer を使用して vSphere にクラスターをインストールする

Assisted Installer を使用して、OpenShift Container Platform をオンプレミスのハードウェアまたはオンプレミスの VM にインストールできます。Assisted Installer を使用して OpenShift Container Platform をインストールすると、x86_64AArch64ppc64le、および s390x アーキテクチャーがサポートされます。

Assisted Installer は、Red Hat Hybrid Cloud Console で提供されるユーザーフレンドリーなインストールソリューションです。

4.1. 関連情報

第5章 Agent-based Installer を使用して vSphere にクラスターをインストールする

エージェントベースのインストール方法では、選択した任意の方法でオンプレミスサーバーを柔軟に起動できます。Assisted Installation サービスの使いやすさと、エアギャップ環境を含むオフラインでの実行機能を兼ね備えています。

エージェントベースのインストールは、OpenShift Container Platform インストーラーのサブコマンドです。利用可能なリリースイメージを使用して、OpenShift Container Platform クラスターのデプロイに必要なすべての情報を含む起動可能な ISO イメージを生成します。

5.1. 関連情報

第6章 vSphere への 3 ノードクラスターのインストール

OpenShift Container Platform バージョン 4.16 では、VMware vSphere に 3 ノードクラスターをインストールできます。3 ノードクラスターは、コンピュートマシンとしても機能する 3 つのコントロールプレーンマシンで構成されます。このタイプのクラスターは、クラスター管理者および開発者がテスト、開発、および実稼働に使用するためのより小さくリソース効率の高いクラスターを提供します。

installer-provisioned infrastructure または user-provisioned infrastructure のいずれかを使用して、3 ノードクラスターをインストールできます。

6.1. 3 ノードクラスターの設定

クラスターをデプロイする前に、install-config.yaml ファイルでワーカーノードの数を 0 に設定して、3 ノードクラスターを設定します。ワーカーノードの数を 0 に設定すると、コントロールプレーンマシンがスケジュール可能になります。これにより、アプリケーションワークロードをコントロールプレーンノードから実行するようにスケジュールできます。

注記

アプリケーションワークロードはコントロールプレーンノードから実行され、コントロールプレーンノードはコンピュートノードと見なされるため、追加のサブスクリプションが必要です。

前提条件

  • 既存の install-config.yaml ファイルがある。

手順

  1. 次の compute スタンザに示すように、install-config.yaml ファイルでコンピューティングレプリカの数を 0 に設定します。

    3 ノードクラスターの install-config.yaml ファイルの例

    apiVersion: v1
    baseDomain: example.com
    compute:
    - name: worker
      platform: {}
      replicas: 0
    # ...

  2. user-provisioned infrastructure を使用して、クラスターをデプロイする場合:

    • HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするように、アプリケーションのイングレスロードバランサーを設定します。3 ノードクラスターでは、イングレスコントローラー Pod はコントロールプレーンノードで実行されます。詳細は、「user-provisioned infrastructure の負荷分散要件」を参照してください。
    • Kubernetes マニフェストファイルを作成したら、cluster-scheduler-02-config.yml ファイルで spec.mastersSchedulable パラメーターが true に設定されていることを確認します。このファイルは、<installation_directory>/manifests にあります。詳細は、「user-provisioned infrastructure を使用した vSphere へのクラスターのインストール」の「Kubernetes マニフェストと Ignition 設定ファイルの作成」を参照してください。
    • 追加のワーカーノードを作成しないでください。

3 ノードクラスターの cluster-scheduler-02-config.yml ファイルの例

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: null
  name: cluster
spec:
  mastersSchedulable: true
  policy:
    name: ""
status: {}

6.2. 次のステップ

第7章 installer-provisioned infrastructure を使用した vSphere へのクラスターのインストール

installer-provisioned infrastructure を使用して、VMware vSphere インスタンスにデプロイしたクラスターを削除できます。

注記

openshift-install destroy cluster コマンドを実行して OpenShift Container Platform をアンインストールしても、vSphere ボリュームは自動的に削除されません。クラスター管理者は、vSphere ボリュームを手動で検索し、それらを削除する必要があります。

7.1. installer-provisioned infrastructure を使用するクラスターの削除

installer-provisioned infrastructure を使用するクラスターは、クラウドから削除できます。

注記

アンインストール後に、とくに user-provisioned infrastructure (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストーラーが作成されなかったり、インストーラーがアクセスできない場合には、リソースがある可能性があります。

前提条件

  • クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
  • クラスター作成時にインストールプログラムが生成したファイルがあります。

手順

  1. クラスターをインストールするために使用したコンピューターのインストールプログラムが含まれるディレクトリーから、以下のコマンドを実行します。

    $ ./openshift-install destroy cluster \
    --dir <installation_directory> --log-level info 1 2
    1
    <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。
    2
    異なる詳細情報を表示するには、info ではなく、warndebug、または error を指定します。
    注記

    クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある metadata.json ファイルが必要になります。

  2. オプション: <installation_directory> ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。

第8章 vSphere Problem Detector Operator の使用

8.1. vSphere Problem Detector Operator について

vSphere Problem Detector Operator は、一般的なインストールおよびストレージに関連する正しくない設定の問題について vSphere にデプロイされたクラスターをチェックします。

Operator は openshift-cluster-storage-operator namespace で実行され、Cluster Storage Operator がクラスターが vSphere にデプロイされたことを検知すると Cluster Storage Operator によって起動します。vSphere Problem Detector Operator は vSphere vCenter Server と通信して、クラスター内の仮想マシン、デフォルトのデータストア、および vSphere vCenter Server 設定に関する他の情報を判別します。Operator は Cloud Credential Operator からの認証情報を使用して vSphere に接続します。

Operator は以下のスケジュールに基づいてチェックを実行します。

  • チェックは 1 時間ごとに実行されます。
  • チェックに失敗すると、Operator は 1 分、2 分、4 分、8 分などの間隔でチェックを再び実行します。Operator は、8 時間を最大の間隔とし、その範囲内で間隔を 2 倍にします。
  • すべてのチェックに合格すると、スケジュールは 1 時間間隔に戻ります。

Operator は、障害の発生後にチェックの頻度を増加させ、Operator が障害状態が修復された直後に正常な状態を報告できるようにします。Operator を手動で実行し、トラブルシューティングに関する情報をすぐに確認できます。

8.2. vSphere Problem Detector Operator チェックの実行

vSphere Problem Detector Operator のチェックを実行するスケジュールを上書きし、チェックを即時に実行できます。

vSphere Problem Detector Operator は 1 時間ごとにチェックを自動的に実行します。ただし、Operator が起動すると、チェックがすぐに実行されます。Operator は、Cluster Storage Operator の起動時に Cluster Storage Operator によって起動し、クラスターが vSphere で実行されているかどうかを判別します。チェックをすぐに実行するには、vSphere Problem Detector Operator を 0 にスケーリングしてから、1 に戻し、vSphere Problem Detector Operator が再起動できるようにします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. Operator を 0 にスケーリングします。

    $ oc scale deployment/vsphere-problem-detector-operator --replicas=0 \
        -n openshift-cluster-storage-operator

    デプロイメントがすぐにゼロにスケーリングされない場合、以下のコマンドを実行して Pod の終了を待機します。

    $ oc wait pods -l name=vsphere-problem-detector-operator \
        --for=delete --timeout=5m -n openshift-cluster-storage-operator
  2. Operator を 1 にスケーリングします。

    $ oc scale deployment/vsphere-problem-detector-operator --replicas=1 \
        -n openshift-cluster-storage-operator
  3. 古いリーダーロックを削除し、Cluster Storage Operator の新規リーダー選択を加速します。

    $ oc delete -n openshift-cluster-storage-operator \
        cm vsphere-problem-detector-lock

検証

  • vSphere Problem Detector Operator によって生成されるイベントまたはログを表示します。イベントまたはログに最新のタイムスタンプがあることを確認します。

8.3. vSphere Problem Detector Operator からのイベントの表示

vSphere Problem Detector Operator が設定チェックを実行した後に、コマンドラインまたは OpenShift Container Platform Web コンソールから表示できるイベントを作成します。

手順

  • コマンドラインを使用してイベントを表示するには、以下のコマンドを実行します。

    $ oc get event -n openshift-cluster-storage-operator \
        --sort-by={.metadata.creationTimestamp}

    出力例

    16m     Normal    Started             pod/vsphere-problem-detector-operator-xxxxx         Started container vsphere-problem-detector
    16m     Normal    Created             pod/vsphere-problem-detector-operator-xxxxx         Created container vsphere-problem-detector
    16m     Normal    LeaderElection      configmap/vsphere-problem-detector-lock    vsphere-problem-detector-operator-xxxxx became leader

  • OpenShift Container Platform Web コンソールを使用してイベントを表示するには、HomeEvents に移動し、Project メニューから openshift-cluster-storage-operator を選択します。

8.4. vSphere Problem Detector Operator からのログの表示

vSphere Problem Detector Operator が設定チェックを実行した後に、コマンドラインまたは OpenShift Container Platform Web コンソールから表示できるログレコードを作成します。

手順

  • コマンドラインを使用してログを表示するには、以下のコマンドを実行します。

    $ oc logs deployment/vsphere-problem-detector-operator \
        -n openshift-cluster-storage-operator

    出力例

    I0108 08:32:28.445696       1 operator.go:209] ClusterInfo passed
    I0108 08:32:28.451029       1 datastore.go:57] CheckStorageClasses checked 1 storage classes, 0 problems found
    I0108 08:32:28.451047       1 operator.go:209] CheckStorageClasses passed
    I0108 08:32:28.452160       1 operator.go:209] CheckDefaultDatastore passed
    I0108 08:32:28.480648       1 operator.go:271] CheckNodeDiskUUID:<host_name> passed
    I0108 08:32:28.480685       1 operator.go:271] CheckNodeProviderID:<host_name> passed

  • OpenShift Container Platform Web コンソールで Operator ログを表示するには、以下の手順を実行します。

    1. WorkloadsPods に移動します。
    2. Projects メニューから openshift-cluster-storage-operator を選択します。from the
    3. vsphere-problem-detector-operator Pod のリンクをクリックします。
    4. Pod details ページの Logs タブをクリックしてログを表示します。

8.5. vSphere Problem Detector Operator によって実行される設定チェック

以下の表は、vSphere Problem Detector Operator が実行する設定チェックを特定します。一部のチェックでは、クラスターの設定を確認します。他のチェックは、クラスター内の各ノードの設定を確認します。

表8.1 クラスター設定チェック
名前説明

CheckDefaultDatastore

vSphere 設定のデフォルトのデータストア名が動的プロビジョニングで使用できる程度の短い名前であることを確認します。

このチェックに失敗した場合は、以下が予想されます。

  • systemd は、Failed to set up mount unit: Invalid argument などのエラーのログをジャーナルに記録します。
  • systemd は、仮想マシンがシャットダウンされていないか、ノードからすべての Pod をドレイン (解放) せずに再起動されている場合はボリュームをアンマウントしません。

このチェックに失敗した場合は、デフォルトのデータストアのより短い名前で vSphere を再設定します。

CheckFolderPermissions

デフォルトのデータストアでボリュームをリスト表示するパーミッションを検証します。このパーミッションは、ボリュームの作成に必要です。Operator は、/ および /kubevols ディレクトリーをリスト表示してパーミッションを検証します。ルートディレクトリーが存在する必要があります。これは、チェックの実行時に /kubevols ディレクトリー が存在しない場合に許可されます。/kubevols ディレクトリーは、このディレクトリーが存在しない場合に、データストアが動的プロビジョニングで使用される際に作成されます。

このチェックに失敗した場合は、OpenShift Container Platform のインストール時に指定された vCenter アカウントに必要なパーミッションを確認します。

CheckStorageClasses

以下を確認してください。

  • このストレージクラスによってプロビジョニングされる各永続ボリュームへの完全修飾パスは 255 文字未満です。
  • ストレージクラスがストレージポリシーを使用する場合、ストレージクラスは 1 つのポリシーのみを使用し、そのポリシーを定義する必要があります。

CheckTaskPermissions

最新のタスクおよびデータストアをリスト表示するパーミッションを検証します。

ClusterInfo

vSphere vCenter からクラスターバージョンおよび UUID を収集します。

表8.2 ノード設定チェック
名前説明

CheckNodeDiskUUID

すべての vSphere 仮想マシンが disk.enableUUID=TRUE で設定されていることを確認します。

このチェックに失敗した場合は、Red Hat ナレッジベースソリューションの How to check 'disk.EnableUUID' parameter from VM in vSphere を参照してください。

CheckNodeProviderID

すべてのノードが vSphere vCenter の ProviderID で設定されていることを確認します。以下のコマンドからの出力に各ノードのプロバイダー ID が含まれていない場合に、このチェックに失敗します。

$ oc get nodes -o custom-columns=NAME:.metadata.name,PROVIDER_ID:.spec.providerID,UUID:.status.nodeInfo.systemUUID

このチェックに失敗した場合は、クラスター内の各ノードのプロバイダー ID の設定方法について、vSphere の製品ドキュメントを参照してください。

CollectNodeESXiVersion

ノードを実行する ESXi ホストのバージョンを報告します。

CollectNodeHWVersion

ノードの仮想マシンのハードウェアバージョンを報告します。

8.6. ストレージクラス設定チェックについて

vSphere ストレージを使用する永続ボリュームの名前は、データストア名とクラスター ID に関連します。

永続ボリュームが作成されると、systemd は永続ボリュームのマウントユニットを作成します。systemd プロセスには、永続ボリュームに使用される VDMK ファイルへの完全修飾パスの長さについて 255 文字の制限があります。

完全修飾パスは、systemd および vSphere の命名規則に基づいています。命名規則では、以下のパターンを使用します。

/var/lib/kubelet/plugins/kubernetes.io/vsphere-volume/mounts/[<datastore>] 00000000-0000-0000-0000-000000000000/<cluster_id>-dynamic-pvc-00000000-0000-0000-0000-000000000000.vmdk
  • 命名規則では、255 文字制限の内の 205 文字が必要です。
  • データストア名とクラスター ID はデプロイメントで判別されます。
  • データストア名とクラスター ID は前述のパターンに代入されます。次に、パスは特殊文字をエスケープできるように systemd-escape コマンドで処理されます。たとえば、ハイフン文字ではエスケープ後に 4 文字を使用します。エスケープされた値は \x2d になります。
  • systemd-escape で処理した後に、systemd が VDMK ファイルへの完全修飾パスにアクセスできるようにするには、パスの長さが 255 文字未満である必要があります。

8.7. vSphere Problem Detector Operator のメトリック

vSphere Problem Detector Operator は、OpenShift Container Platform モニタリングスタックで使用される以下のメトリクスを公開します。

表8.3 vSphere Problem Detector Operator によって公開されるメトリック
名前説明

vsphere_cluster_check_total

vSphere Problem Detector Operator が実行したクラスターレベルのチェックの累積数です。この数には、成功と失敗の両方が含まれます。

vsphere_cluster_check_errors

vSphere Problem Detector Operator が実行したクラスターレベルのチェックの失敗したチェック数です。たとえば、値 1 は 1 つのクラスターレベルのチェックが失敗したことを示します。

vsphere_esxi_version_total

特定のバージョンを持つ ESXi ホストの数ホストが複数のノードを実行する場合は、ホストが 1 回のみカウントされることに注意してください。

vsphere_node_check_total

vSphere Problem Detector Operator が実行したノードレベルのチェックの累積数です。この数には、成功と失敗の両方が含まれます。

vsphere_node_check_errors

vSphere Problem Detector Operator が実行したノードレベルのチェックの失敗したチェック数です。たとえば、値 1 は 1 つのノードレベルのチェックが失敗したことを示します。

vsphere_node_hw_version_total

特定のハードウェアバージョンを持つ vSphere ノードの数。

vsphere_vcenter_info

vSphere vCenter サーバーに関する情報

8.8. 関連情報

第9章 vSphere のインストール設定パラメーター

OpenShift Container Platform クラスターを vSphere にデプロイする前に、クラスターとそれをホストするプラットフォームをカスタマイズするためのパラメーターを指定します。install-config.yaml ファイルを作成するときは、コマンドラインを使用して必要なパラメーターの値を指定します。その後、install-config.yaml ファイルを変更して、クラスターをさらにカスタマイズできます。

9.1. vSphere で使用可能なインストール設定パラメーター

次の表に、インストールプロセスの一部として設定できる必須、オプション、および vSphere 固有のインストール設定パラメーターを示します。

注記

インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。

9.1.1. 必須設定パラメーター

必須のインストール設定パラメーターは、以下の表で説明されています。

表9.1 必須パラメーター
パラメーター説明
apiVersion:

install-config.yaml コンテンツの API バージョン。現在のバージョンは v1 です。インストールプログラムは、古い API バージョンもサポートしている場合があります。

文字列

baseDomain:

クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、baseDomain<metadata.name>.<baseDomain> 形式を使用する metadata.name パラメーターの値の組み合わせです。

example.com などの完全修飾ドメインまたはサブドメイン名。

metadata:

Kubernetes リソース ObjectMeta。ここからは name パラメーターのみが消費されます。

オブジェクト

metadata:
  name:

クラスターの名前。クラスターの DNS レコードはすべて {{.metadata.name}}.{{.baseDomain}} のサブドメインです。

小文字いちぶハイフン (-) の文字列 (dev など)。

platform:

インストールを実行する特定のプラットフォームの設定: awsbaremetalazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}platform.<platform> パラメーターに関する追加情報は、以下の表で特定のプラットフォームを参照してください。

オブジェクト

pullSecret:

Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

9.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 クラスターをインストールしないでください。
注記

VMware vSphere では、デュアルスタックネットワークで IPv4 または IPv6 をプライマリーアドレスファミリーとして指定できます。

両方の IP アドレスファミリーを使用するようにクラスターを設定する場合は、次の要件を確認してください。

  • どちらの IP ファミリーも、デフォルトゲートウェイに同じネットワークインターフェイスを使用する必要があります。
  • 両方の IP ファミリーにデフォルトゲートウェイが必要です。
  • すべてのネットワーク設定パラメーターに対して、IPv4 アドレスと IPv6 アドレスを同じ順序で指定する必要があります。たとえば、以下の設定では、IPv4 アドレスは IPv6 アドレスの前に記載されます。

    networking:
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      - cidr: fd00:10:128::/56
        hostPrefix: 64
      serviceNetwork:
      - 172.30.0.0/16
      - fd00:172:16::/112
表9.2 ネットワークパラメーター
パラメーター説明
networking:

クラスターのネットワークの設定。

オブジェクト

注記

インストール後に networking オブジェクトで指定したパラメーターを変更することはできません。

networking:
  networkType:

インストールする Red Hat OpenShift Networking ネットワークプラグイン。

OVNKubernetesOVNKubernetes は、Linux ネットワークと、Linux サーバーと Windows サーバーの両方を含む Linux ネットワークおよびハイブリッドネットワーク用の CNI プラグインです。デフォルトの値は OVNKubernetes です。

networking:
  clusterNetwork:

Pod の IP アドレスブロック。

デフォルト値は 10.128.0.0/14 で、ホストの接頭辞は /23 です。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

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

networking.clusterNetwork を使用する場合に必須です。IP アドレスブロック。

IPv4 ネットワーク

CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は 0 から 32 の間になります。

networking:
  clusterNetwork:
    hostPrefix:

それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、hostPrefix23 に設定される場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。hostPrefix 値の 23 は、510 (2^(32 - 23) - 2) Pod IP アドレスを提供します。

サブネット接頭辞。

デフォルト値は 23 です。

networking:
  serviceNetwork:

サービスの IP アドレスブロック。デフォルト値は 172.30.0.0/16 です。

OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。

CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。

networking:
  serviceNetwork:
   - 172.30.0.0/16
networking:
  machineNetwork:

マシンの IP アドレスブロック。

複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。

オブジェクトの配列。以下に例を示します。

networking:
  machineNetwork:
  - cidr: 10.0.0.0/16
networking:
  machineNetwork:
    cidr:

networking.machineNetwork を使用する場合に必須です。IP アドレスブロック。libvirt と IBM Power® Virtual Server を除くすべてのプラットフォームのデフォルト値は 10.0.0.0/16 です。libvirt の場合、デフォルト値は 192.168.126.0/24 です。IBM Power® Virtual Server の場合、デフォルト値は 192.168.0.0/24 です。

CIDR 表記の IP ネットワークブロック。

例: 10.0.0.0/16

注記

優先される NIC が置かれている CIDR に一致する networking.machineNetwork を設定します。

9.1.3. オプションの設定パラメーター

オプションのインストール設定パラメーターは、以下の表で説明されています。

表9.3 オプションのパラメーター
パラメーター説明
additionalTrustBundle:

ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。

文字列

capabilities:

オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。

文字列配列

capabilities:
  baselineCapabilitySet:

有効にするオプション機能の初期セットを選択します。有効な値は Nonev4.11v4.12vCurrent です。デフォルト値は vCurrent です。

文字列

capabilities:
  additionalEnabledCapabilities:

オプションの機能のセットを、baselineCapabilitySet で指定したものを超えて拡張します。このパラメーターで複数の機能を指定できます。

文字列配列

cpuPartitioningMode:

ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。ワークロードパーティショニングはインストール中にのみ有効にすることができ、インストール後に無効にすることはできません。このフィールドはワークロードのパーティショニングを有効にしますが、特定の CPU を使用するようにワークロードを設定するわけではありません。詳細は、スケーラビリティとパフォーマンス セクションの ワークロードパーティショニング ページを参照してください。

None または AllNodes。デフォルト値は None です。

compute:

コンピュートノードを構成するマシンの設定。

MachinePool オブジェクトの配列。

compute:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

compute:
  name:

compute を使用する場合に必須です。マシンプールの名前。

worker

compute:
  platform:

compute を使用する場合に必須です。このパラメーターを使用して、ワーカーマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は controlPlane.platform パラメーターの値に一致する必要があります。

awsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

compute:
  replicas:

プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。

2 以上の正の整数。デフォルト値は 3 です。

featureSet:

機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。

文字列。TechPreviewNoUpgrade など、有効にする機能セットの名前。

controlPlane:

コントロールプレーンを構成するマシンの設定。

MachinePool オブジェクトの配列。

controlPlane:
  architecture:

プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は amd64 (デフォルト) です。

文字列

controlPlane:
  name:

controlPlane を使用する場合に必須です。マシンプールの名前。

master

controlPlane:
  platform:

controlPlane を使用する場合に必須です。このパラメーターを使用して、コントロールプレーンマシンをホストするクラウドプロバイダーを指定します。このパラメーターの値は compute.platform パラメーターの値に一致する必要があります。

awsazuregcpibmcloudnutanixopenstackpowervsvsphere、または {}

controlPlane:
  replicas:

プロビジョニングするコントロールプレーンマシンの数。

サポートされる値は 3、シングルノード OpenShift をデプロイする場合は 1 です。

credentialsMode:

Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。

注記

すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、認証と認可 コンテンツの「クラウドプロバイダーの認証情報の管理」を参照してください。

MintPassthroughManual、または空の文字列 ("")。

fips:

FIPS モードを有効または無効にします。デフォルトは false (無効) です。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 暗号化ライブラリーを使用します。

注記

Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。

false または true

imageContentSources:

release-image コンテンツのソースおよびリポジトリー。

オブジェクトの配列。この表の以下の行で説明されているように、source およびオプションで mirrors が含まれます。

imageContentSources:
  source:

imageContentSources を使用する場合に必須です。ユーザーが参照するリポジトリーを指定します (例: イメージプル仕様)。

文字列

imageContentSources:
  mirrors:

同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。

文字列の配列。

publish:

Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。

Internal または External。デフォルト値は External です。

このパラメーターを Internal に設定することは、クラウド以外のプラットフォームではサポートされません。

重要

フィールドの値が Internal に設定されている場合、クラスターは機能しなくなります。詳細は、BZ#1953035 を参照してください。

sshKey:

クラスターマシンへのアクセスを認証するための SSH キー。

注記

インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。

たとえば、sshKey: ssh-ed25519 AAAA.. です。

9.1.4. 追加の VMware vSphere 設定パラメーター

追加の VMware vSphere 設定パラメーターは以下の表で説明されています。

表9.4 追加の VMware vSphere クラスターパラメーター
パラメーター説明
platform:
  vsphere:

クラスターをホストするクラウドプラットフォーム上のアカウントを説明します。パラメーターを使用してプラットフォームをカスタマイズできます。マシンプール内のコンピュートマシンとコントロールプレーンマシンに追加の設定を指定する場合、このパラメーターは必要ありません。OpenShift Container Platform クラスターに指定できる vCenter サーバーは 1 つだけです。

vSphere 設定オブジェクトのディクショナリー

platform:
  vsphere:
    apiVIPs:

コントロールプレーン API アクセス用に設定した仮想 IP (VIP) アドレス。

注記

このパラメーターは、外部ロードバランサーが設定されていない installer-provisioned infrastructure にのみ適用されます。user-provisioned infrastructure ではこのパラメーターを指定しないでください。

複数の IP アドレス

platform:
  vsphere:
    diskType:

オプション: ディスクのプロビジョニング方法。この値が設定されていない場合、デフォルトで vSphere のデフォルトのストレージポリシーに設定されます。

有効な値は、thinthick、または eagerZeroedThick です。

platform:
  vsphere:
    failureDomains:

リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。

障害ドメイン設定オブジェクトの配列。

platform:
  vsphere:
    failureDomains:
      name:

障害ドメインの名前。

文字列

platform:
  vsphere:
    failureDomains:
      region:

クラスターに複数の障害ドメインを定義する場合は、タグを各 vCenter データセンターにアタッチする必要があります。リージョンを定義するには、openshift-region タグカテゴリーのタグを使用します。単一の vSphere データセンター環境の場合、タグをアタッチする必要はありませんが、パラメーターに英数字の値 (例: datacenter) を入力する必要があります。

文字列

platform:
  vsphere:
    failureDomains:
      server:

クライアントが障害ドメインリソースにアクセスできるように、VMware vCenter Server の完全修飾ホスト名または IP アドレスを指定します。server ロールを vSphere vCenter サーバーの場所に適用する必要があります。

文字列

platform:
  vsphere:
    failureDomains:
      zone:

クラスターに複数の障害ドメインを定義する場合は、各 vCenter クラスターにタグをアタッチする必要があります。ゾーンを定義するには、openshift-zone タグカテゴリーのタグを使用します。単一の vSphere データセンター環境の場合、タグをアタッチする必要はありませんが、パラメーターに英数字の値 (例: cluster) を入力する必要があります。

文字列

platform:
  vsphere:
    failureDomains:
      topology:
        computeCluster:

vSphere コンピュートクラスターへのパス。

文字列

platform:
  vsphere:
    failureDomains:
      topology:
        datacenter:

OpenShift Container Platform 仮想マシン (VM) が動作するデータセンターをリストして定義します。データセンターのリストは、vcenters フィールドで指定したデータセンターのリストと一致する必要があります。

文字列

platform:
  vsphere:
    failureDomains:
      topology:
        datastore:

障害ドメインの仮想マシンファイルを保存する vSphere データストアへのパスを指定します。datastore ロールを vSphere vCenter データストアの場所に適用する必要があります。

文字列

platform:
  vsphere:
    failureDomains:
      topology:
        folder:

オプション: ユーザーが仮想マシンを作成する既存のフォルダーの絶対パス (例: /<data_center_name>/vm/<folder_name>/<subfolder_name>)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin という名前のデフォルトの StorageClass オブジェクトを使用したくない場合は、install-config.yaml ファイルから folder パラメーターを省略できます。

文字列

platform:
  vsphere:
    failureDomains:
      topology:
        networks:

設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリスト表示します。

文字列

platform:
  vsphere:
    failureDomains:
      topology:
        resourcePool:

オプション: このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例: /<data_center_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>)。値を指定しない場合、インストールプログラムは /<data_center_name>/host/<cluster_name>/Resources の下のクラスターのルートにリソースをインストールします。

文字列

platform:
  vsphere:
    failureDomains:
      topology
        template:

既存の Red Hat Enterprise Linux CoreOS (RHCOS) イメージテンプレートまたは仮想マシンへの絶対パスを指定します。その後、インストールプログラムはイメージテンプレートまたは仮想マシンを使用して、vSphere ホストに RHCOS を迅速にインストールできます。RHCOS イメージを vSphere ホストにアップロードする代わりに、このパラメーターを使用することを検討してください。このパラメーターは、installer-provisioned infrastructure でのみ使用できます。

文字列

platform:
  vsphere:
    ingressVIPs:

クラスター Ingress 用に設定した仮想 IP (VIP) アドレス。

注記

このパラメーターは、外部ロードバランサーが設定されていない installer-provisioned infrastructure にのみ適用されます。user-provisioned infrastructure ではこのパラメーターを指定しないでください。

複数の IP アドレス

platform:
  vsphere:
    vcenters:

サービスが vCenter サーバーと通信できるように接続の詳細を設定します。現在、単一の vCenter サーバーのみサポートされます。

vCenter 設定オブジェクトの配列。

platform:
  vsphere:
    vcenters:
      datacenters:

OpenShift Container Platform 仮想マシン (VM) が動作するデータセンターをリストして定義します。データセンターのリストは、failureDomains フィールドで指定されたデータセンターのリストと一致する必要があります。

文字列

platform:
  vsphere:
    vcenters:
      password:

vSphere ユーザーに関連付けられたパスワード。

文字列

platform:
  vsphere:
    vcenters:
      port:

vCenter サーバーとの通信に使用するポート番号。

整数

platform:
  vsphere:
    vcenters:
      server:

vCenter サーバーの完全修飾ホスト名 (FQHN) または IP アドレス。

文字列

platform:
  vsphere:
    vcenters:
      user:

vSphere ユーザーに関連付けられたユーザー名。

文字列

9.1.5. 非推奨の VMware vSphere 設定パラメーター

OpenShift Container Platform 4.13 では、次の vSphere 設定パラメーターが非推奨になりました。これらのパラメーターは引き続き使用できますが、インストールプログラムはこれらのパラメーターを install-config.yaml ファイルに自動的に指定しません。

次の表に、非推奨になった各 vSphere 設定パラメーターを示します。

表9.5 非推奨の VMware vSphere クラスターパラメーター
パラメーター説明
platform:
  vsphere:
    apiVIP:

コントロールプレーン API のアクセス用に設定した仮想 IP (VIP) アドレス。

注記

OpenShift Container Platform 4.12 以降では、apiVIP 設定は非推奨です。代わりに、List 形式を使用して、apiVIPs 設定に値を入力します。

IP アドレス (例: 128.0.0.1)。

platform:
  vsphere:
    cluster:

OpenShift Container Platform クラスターをインストールする vCenter クラスター。

文字列

platform:
  vsphere:
    datacenter:

OpenShift Container Platform 仮想マシン (VM) が動作するデータセンターを定義します。

文字列

platform:
  vsphere:
    defaultDatastore:

ボリュームのプロビジョニングに使用するデフォルトデータストアの名前。

文字列

platform:
  vsphere:
    folder:

オプション: インストールプログラムが仮想マシンを作成する既存のフォルダーの絶対パス。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられたフォルダーを作成します。

文字列 (例: /<data_center_name>/vm/<folder_name>/<subfolder_name>)

platform:
  vsphere:
    ingressVIP:

クラスター Ingress 用に設定した仮想 IP (VIP) アドレス。

注記

OpenShift Container Platform 4.12 以降では、ingressVIP 設定は非推奨です。代わりに、List 形式を使用して、ingressVIPs 設定に値を入力します。

IP アドレス (例: 128.0.0.1)。

platform:
  vsphere:
    network:

設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワーク。

文字列

platform:
  vsphere:
    password:

vCenter ユーザー名のパスワード。

文字列

platform:
  vsphere:
    resourcePool:

オプション: インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス。値を指定しない場合、インストールプログラムは /<data_center_name>/host/<cluster_name>/Resources の下のクラスターのルートにリソースをインストールします。

文字列 (例: /<data_center_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>)

platform:
  vsphere:
    username:

vCenter インスタンスに接続するために使用するユーザー名。このユーザーには、少なくとも vSphere の 静的または動的な永続ボリュームのプロビジョニング に必要なロールおよび権限がなければなりません。

文字列

platform:
  vsphere:
    vCenter:

vCenter サーバーの完全修飾ホスト名または IP アドレス。

文字列

9.1.6. オプションの VMware vSphere マシンプール設定パラメーター

オプションの VMware vSphere マシンプール設定パラメーターは、以下の表で説明されています。

表9.6 オプションの VMware vSphere マシンプールパラメーター
パラメーター説明
platform:
  vsphere:
    clusterOSImage:

インストールプログラムが Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードする場所。このパラメーターのパス値を設定する前に、OpenShift Container Platform リリースのデフォルトの RHCOS ブートイメージが RHCOS イメージテンプレートまたは仮想マシンのバージョンと一致していることを確認してください。そうしないと、クラスターのインストールが失敗する可能性があります。

HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。例: https://mirror.openshift.com/images/rhcos-<version>-vmware.<architecture>.ova

platform:
  vsphere:
    osDisk:
      diskSizeGB:

ディスクのサイズ (ギガバイト単位)。

整数

platform:
  vsphere:
    cpus:

仮想マシンを割り当てる仮想プロセッサーコアの合計数platform.vsphere.cpus の値は、platform.vsphere.coresPerSocket 値の倍数である必要があります。

整数

platform:
  vsphere:
    coresPerSocket:

仮想マシンのソケットあたりのコア数。仮想マシンの仮想ソケットの数は platform.vsphere.cpus/platform.vsphere.coresPerSocket になります。コントロールプレーンノードとワーカーノードのデフォルト値は、それぞれ 42 です。

整数

platform:
  vsphere:
    memoryMB:

仮想マシンのメモリーのサイズ (メガバイト単位)。

整数

第10章 VMware vSphere 上のクラスターの複数のリージョンとゾーンの設定

管理者は、VMware vSphere インスタンス上で実行される OpenShift Container Platform クラスターに複数のリージョンとゾーンを指定できます。この設定により、ハードウェアの障害やネットワークの停止によってクラスターに障害が発生するリスクが軽減されます。

障害ドメイン設定には、トポロジーを作成するパラメーターがリストされます。次のリストは、これらのパラメーターの一部を示しています。

  • computeCluster
  • datacenter
  • datastore
  • networks
  • resourcePool

OpenShift Container Platform クラスターに複数のリージョンとゾーンを定義した後、ノードを作成したり、別の障害ドメインにノードを移行したりできます。

重要

既存の OpenShift Container Platform クラスターコンピュートノードを障害ドメインに移行する場合は、コンピュートノード用に新しいコンピューティングマシンセットを定義する必要があります。この新しいマシンセットは、障害ドメインのトポロジーに応じてコンピュートノードをスケールアップし、既存のコンピュートノードをスケールダウンできます。

クラウドプロバイダーは、マシンセットリソースによってプロビジョニングされたコンピュートノードに、topology.kubernetes.io/zone ラベルと topology.kubernetes.io/region ラベルを追加します。

詳細は、コンピュートマシンセットの作成 を参照してください。

10.1. vSphere 上のクラスターに複数のリージョンとゾーンを指定する

infrastructures.config.openshift.io 設定リソースを設定して、VMware vSphere インスタンス上で実行される OpenShift Container Platform クラスターに複数のリージョンとゾーンを指定できます。

クラウドコントローラーマネージャーおよび vSphere Container Storage Interface (CSI) Operator Driver のトポロジー認識機能には、OpenShift Container Platform クラスターをホストする vSphere トポロジーに関する情報が必要です。このトポロジー情報は、infrastructures.config.openshift.io 設定リソースに存在します。

クラスターのリージョンとゾーンを指定する前に、クラウドプロバイダーがノードにラベルを追加できるように、すべてのデータセンターとコンピューティングクラスターにタグが含まれていることを確認する必要があります。たとえば、data-center-1region-a を表し、compute-cluster-1zone-1 を表す場合、クラウドプロバイダーは、region-a の値を持つ openshift-region カテゴリーラベルを data-center-1 に追加します。さらに、クラウドプロバイダーは、zone-1 の値を持つ openshift-zone カテゴリータグを compute-cluster-1 に追加します。

注記

vMotion 機能を備えたコントロールプレーンノードを障害ドメインに移行できます。これらのノードを障害ドメインに追加すると、クラウドプロバイダーはこれらのノードに topology.kubernetes.io/zone ラベルと topology.kubernetes.io/region ラベルを追加します。

前提条件

  • vCenter サーバー上に openshift-region タグカテゴリーと openshift-zone タグカテゴリーを作成しました。
  • 各データセンターとコンピューティングクラスターに、関連付けられたリージョンまたはゾーン、あるいはその両方の名前を表すタグが含まれていることを確認しました。
  • オプション: API および Ingress 静的 IP アドレスをインストールプログラムに定義した場合は、すべてのリージョンとゾーンが共通のレイヤー 2 ネットワークを共有していることを確認する必要があります。この設定により、API および Ingress Virtual IP (VIP) アドレスがクラスターと対話できるようになります。
重要

ノードを作成するかノードを移行する前に、すべてのデータセンターとコンピューティングクラスターにタグを提供しない場合、クラウドプロバイダーは、topology.kubernetes.io/zone ラベルと topology.kubernetes.io/region ラベルをノードに追加できません。これは、サービスがトラフィックをノードにルーティングできないことを意味します。

手順

  1. 次のコマンドを実行して、クラスターの infrastructures.config.openshift.io カスタムリソース定義 (CRD) を編集して、リソースの failureDomains セクションに複数のリージョンとゾーンを指定します。

    $ oc edit infrastructures.config.openshift.io cluster

    複数のリージョンおよびゾーンが設定で定義された cluster という名前のインスタンスの infrastructures.config.openshift.io CRD の例

    spec:
      cloudConfig:
        key: config
        name: cloud-provider-config
      platformSpec:
        type: vSphere
        vsphere:
          vcenters:
            - datacenters:
                - <region_a_data_center>
                - <region_b_data_center>
              port: 443
              server: <your_vcenter_server>
          failureDomains:
            - name: <failure_domain_1>
              region: <region_a>
              zone: <zone_a>
              server: <your_vcenter_server>
              topology:
                datacenter: <region_a_dc>
                computeCluster: "</region_a_dc/host/zone_a_cluster>"
                resourcePool: "</region_a_dc/host/zone_a_cluster/Resources/resource_pool>"
                datastore: "</region_a_dc/datastore/datastore_a>"
                networks:
                - port-group
            - name: <failure_domain_2>
              region: <region_a>
              zone: <zone_b>
              server: <your_vcenter_server>
              topology:
                computeCluster: </region_a_dc/host/zone_b_cluster>
                datacenter: <region_a_dc>
                datastore: </region_a_dc/datastore/datastore_a>
                networks:
                - port-group
            - name: <failure_domain_3>
              region: <region_b>
              zone: <zone_a>
              server: <your_vcenter_server>
              topology:
                computeCluster: </region_b_dc/host/zone_a_cluster>
                datacenter: <region_b_dc>
                datastore: </region_b_dc/datastore/datastore_b>
                networks:
                - port-group
          nodeNetworking:
            external: {}
            internal: {}

    重要

    障害ドメインを作成し、それを VMware vSphere クラスターの CRD で定義した後は、障害ドメインを変更または削除しないでください。この設定でこれらのアクションのいずれかを実行すると、コントロールプレーンマシンの可用性とフォールトトレランスに影響を与える可能性があります。

  2. リソースファイルを保存して変更を適用します。

10.2. クラスターで複数のレイヤー 2 ネットワークを有効にする

ノード間のデータ転送が複数のネットワークにまたがるように、複数のレイヤー 2 ネットワーク設定を使用するようにクラスターを設定できます。

前提条件

  • クラスターコンポーネントが相互に通信できるように、マシン間のネットワーク接続を設定しました。

手順

  • installer-provisioned infrastructure を使用してクラスターをインストールした場合は、すべてのコントロールプレーンノードが共通のレイヤー 2 ネットワークを共有していることを確認する必要があります。さらに、Ingress Pod スケジューリング用に設定されたコンピュートノードが共通のレイヤー 2 ネットワークを共有していることを確認します。

    • 複数のレイヤー 2 ネットワークにまたがるコンピュートノードが必要な場合は、Ingress Pod をホストできるインフラストラクチャーノードを作成できます。
    • 追加のレイヤー 2 ネットワークにわたってワークロードをプロビジョニングする必要がある場合は、vSphere 上にコンピューティングマシンセットを作成し、これらのワークロードをターゲットのレイヤー 2 ネットワークに移動できます。
  • ユーザーが提供したインフラストラクチャー (user-provisioned infrastructure として定義) にクラスターをインストールした場合は、ニーズを満たすために次のアクションを実行します。

    • ロードバランサーがコントロールプレーンノード上の API およびマシン設定サーバーにアクセスできるように、API ロードバランサーとネットワークを設定します。
    • ロードバランサーがコンピュートノードまたはインフラストラクチャーノード上の Ingress Pod に到達できるように、Ingress ロードバランサーとネットワークを設定します。

10.3. クラスター全体のインフラストラクチャー CRD のパラメーター

VMware vSphere インスタンス上で実行される OpenShift Container Platform クラスターの複数のリージョンとゾーンを定義するには、クラスター全体のインフラストラクチャー、infrastructures.config.openshift.io、カスタムリソース定義 (CRD) の特定のパラメーターの値を設定する必要があります。

次の表に、OpenShift Container Platform クラスターの複数のリージョンとゾーンを定義するための必須パラメーターを示します。

パラメーター説明

vcenters

OpenShift Container Platform クラスターの vCenter サーバー。クラスターに指定できる vCenter は 1 つだけです。

datacenters

OpenShift Container Platform クラスターに関連付けられた VM が作成されるか、現在存在する vCenter データセンター。

ポート

vCenter サーバーの TCP ポート。

server

vCenter サーバーの完全修飾ドメイン名 (FQDN)。

failureDomains

障害が発生したドメインのリスト。

name

障害ドメインの名前。

region

障害障害ドメインのトポロジーに割り当てられた openshift-region タグの値。

zone

障害障害ドメインのトポロジーに割り当てられた openshift-zone タグの値。

topology

障害ドメインに関連付けられた vCenter リソース。

datacenter

障害ドメインに関連付けられているデータセンター。

computeCluster

障害ドメインに関連付けられたコンピューティングクラスターのフルパス。

resourcePool

障害ドメインに関連付けられたリソースプールのフルパス。

datastore

障害ドメインに関連付けられたデータストアのフルパス。

networks

障害ドメインに関連付けられたポートグループのリスト。定義できる portgroup は 1 つだけです。

第11章 vSphere クラスターでの暗号化の有効化

vSphere に OpenShift Container Platform 4.16 をインストールした後、ノードを 1 つずつドレインしてシャットダウンすることにより、仮想マシンを暗号化できます。各仮想マシンがシャットダウンしている間、vCenter Web インターフェイスで暗号化を有効にすることができます。

11.1. 仮想マシンの暗号化

次のプロセスで仮想マシンを暗号化できます。vCenter インターフェイスを使用して、仮想マシンをドレインし、電源を切り、暗号化することができます。最後に、暗号化されたストレージを使用するストレージクラスを作成できます。

前提条件

  • vSphere で標準キープロバイダーを設定しました。詳細は、vCenter Server への KMS の追加 を参照してください。

    重要

    vCenter のネイティブキープロバイダーはサポートされていません。詳細は、vSphere Native Key Provider の概要 を参照してください。

  • クラスターをホスティングしているすべての ESXi ホストでホスト暗号化モードを有効にしました。詳細は、ホスト暗号化モードの有効化 を参照してください。
  • すべての暗号化権限が有効になっている vSphere アカウントがあります。詳細は、暗号化操作の権限 を参照してください。

手順

  1. ノードの 1 つをドレインして閉鎖します。ノード管理の詳細な手順は、「ノードの操作」を参照してください。
  2. vCenter インターフェイスでそのノードに関連付けられている仮想マシンをシャットダウンします。
  3. vCenter インターフェイスで仮想マシンを右クリックし、VM PoliciesEdit VM Storage Policies を選択します。
  4. 暗号化されたストレージポリシーを選択し、OK を選択します。
  5. vCenter インターフェイスで暗号化された仮想マシンを起動します。
  6. 暗号化するすべてのノードに対して、手順 1 ~ 5 を繰り返します。
  7. 暗号化されたストレージポリシーを使用するストレージクラスを設定します。暗号化されたストレージクラスの設定の詳細は、"VMware vSphere CSI Driver Operator" を参照してください。

11.2. 関連情報

第12章 インストール後の vSphere 接続設定

インストール方法によっては、プラットフォーム統合機能を有効にして OpenShift Container Platform クラスターを vSphere にインストールした後に、vSphere 接続設定を手動で更新する必要があります。

アシステッドインストーラーを使用したインストールの場合は、接続設定を更新する必要があります。これは、インストール時にアシステッドインストーラーが、デフォルトの接続設定をプレースホルダーとして vSphere connection configuration ウィザードに追加するためです。

インストーラーまたはユーザーによってプロビジョニングされるインフラストラクチャーをインストールする場合は、インストール時に有効な接続設定を入力する必要があります。vSphere connection configuration ウィザードは任意のタイミングで使用して接続設定を検証または変更できますが、これはインストールの完了に必須の操作ではありません。

12.1. vSphere 接続設定

必要に応じて、以下の vSphere 設定を変更します。

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

前提条件

  • アシステッドインストーラーによってクラスターが正常にインストールされている。
  • クラスターが https://console.redhat.com に接続されている。

手順

  1. Administrator パースペクティブで、Home → Overview に移動します。
  2. StatusvSphere connection をクリックし、vSphere connection configuration ウィザードを開きます。
  3. vCenter フィールドに、vSphere vCenter サーバーのネットワークアドレスを入力します。ドメイン名または IP アドレスのいずれかを入力できます。これは vSphere Web クライアント URL に表示されます (例: https://[your_vCenter_address]/ui)。
  4. vCenter クラスター フィールドには、OpenShift Container Platform がインストールされている vSphere vCenter クラスターの名前を入力します。

    重要

    この手順は、OpenShift Container Platform 4.13 以降をインストールしている場合は必須となります。

  5. Username フィールドに、vSphere vCenter のユーザー名を入力します。
  6. Password フィールドに、vSphere vCenter のパスワードを入力します。

    警告

    システムは、クラスターの kube-system namespace の vsphere-creds シークレットにユーザー名とパスワードを保存します。vCenter のユーザー名またはパスワードが間違っていると、クラスターノードをスケジュールできなくなります。

  7. Datacenter フィールドに、クラスターのホストに使用する仮想マシンが含まれる vSphere データセンターの名前を入力します (例: SDDC-Datacenter)。
  8. Default data store フィールドに、永続データボリュームを保存する vSphere データストアのパスおよび名前を入力します (例: /SDDC-Datacenter/datastore/datastorename)。

    警告

    設定の保存後に vSphere データセンターまたはデフォルトのデータストアを更新すると、アクティブな vSphere PersistentVolumes がデタッチされます。

  9. Virtual Machine Folder フィールドに、クラスターの仮想マシンが含まれるデータセンターフォルダーを入力します (例: /SDDC-Datacenter/vm/ci-ln-hjg4vg2-c61657-t2gzr)。正常に OpenShift Container Platform をインストールするには、クラスターを構成するすべての仮想マシンを単一のデータセンターフォルダーに配置する必要があります。
  10. Save Configuration をクリックします。これにより、openshift-config namespace の cloud-provider-config ConfigMap リソースが更新され、設定プロセスが開始されます。
  11. vSphere connection configuration ウィザードを再度開き、Monitored operators パネルを展開します。Operator のステータスが Progressing または Healthy であることを確認します。

12.2. 設定の確認

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

前提条件

  • vSphere connection configuration 設定ウィザードで設定を保存している。

手順

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

    1. OpenShift Container Platform の Administrator パースペクティブで、Home → Overview に移動します。
    2. StatusOperators をクリックします。すべての Operator ステータスが Progressing から All succeeded に変わるまで待機します。Failed ステータスは、設定が失敗したことを示します。
    3. StatusControl Plane をクリックします。すべての Control Pane コンポーネントの応答レートが 100% に戻るまで待機します。Failed コントロールプレーンコンポーネントは、設定が失敗したことを示します。

    失敗は、少なくとも 1 つの接続設定が間違っていることを示します。vSphere connection configuration ウィザードで設定を変更し、その設定を再度保存します。

  2. 以下の手順を実行して、PersistentVolumeClaims オブジェクトをバインドできることを確認します。

    1. 以下の YAML を使用して StorageClass オブジェクトを作成します。

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
       name: vsphere-sc
      provisioner: kubernetes.io/vsphere-volume
      parameters:
       datastore: YOURVCENTERDATASTORE
       diskformat: thin
      reclaimPolicy: Delete
      volumeBindingMode: Immediate
    2. 以下の YAML を使用して PersistentVolumeClaims オブジェクトを作成します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
       name: test-pvc
       namespace: openshift-config
       annotations:
         volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume
       finalizers:
         - kubernetes.io/pvc-protection
      spec:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
          storage: 10Gi
       storageClassName: vsphere-sc
       volumeMode: Filesystem

      PersistentVolumeClaims オブジェクトを作成できない場合、OpenShift Container Platform Web コンソールの Administrator パースペクティブで StoragePersistentVolumeClaims に移動してトラブルシューティングできます。

ストレージオブジェクトの作成手順は、動的プロビジョニング を参照してください。

Legal Notice

Copyright © 2024 Red Hat, Inc.

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.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.