Google Cloud へのインストール
Google Cloud Platform への OpenShift Container Platform のインストール
概要
第1章 {gcp-short} へのインストールの準備 リンクのコピーリンクがクリップボードにコピーされました!
1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
1.2. OpenShift Container Platform on Google Cloud をインストールするための要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を Google Cloud にインストールする前に、サービスアカウントを作成し、Google Cloud プロジェクトを設定する必要があります。プロジェクトの作成、API サービスの有効化、DNS の設定、Google Cloud アカウント制限、およびサポートされる Google Cloud リージョンの詳細については、Google Cloud プロジェクトの設定 を参照してください。
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを kube-system namespace に保存することを望まない場合は、他のオプションについて、Google Cloud の IAM の手動作成 を参照してください。
1.3. Google Cloud に OpenShift Container Platform をインストールする方法の選択 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を installer-provisioned infrastructure または user-provisioned infrastructure にインストールできます。デフォルトのインストールタイプは、installer-provisioned infrastructure を使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform は、ユーザーがプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。
インストーラーおよびユーザーによってプロビジョニングされる インストールプロセス の詳細は、インストールプロセス を参照してください。
1.3.1. installer-provisioned infrastructure へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の方法のいずれかを使用して、OpenShift Container Platform インストールプログラムによってプロビジョニングされた Google Cloud インフラストラクチャーに、クラスターをインストールできます。
- クラスターの Google Cloud へのクイックインストール: OpenShift Container Platform インストールプログラムでプロビジョニングされる Google Cloud インフラストラクチャーに OpenShift Container Platform をインストールできます。デフォルトの設定オプションを使用して、クラスターを迅速にインストールできます。
- カスタマイズされたクラスターの Google Cloud へ のインストール:インストールプログラムがプロビジョニングする Google Cloud インフラストラクチャーにカスタマイズされたクラスターをインストールできます。インストールプログラムは、インストールの段階で一部のカスタマイズを適用できるようにします。その他の数多くのカスタマイズオプションは、インストール後 に利用できます。
- ネットワークをカスタマイズして Google Cloud にクラスターをインストール する:インストール中に OpenShift Container Platform ネットワーク設定をカスタマイズして、クラスターが既存の IP アドレス割り当てと共存し、ネットワーク要件に準拠することができます。
- ネットワークが制限された環境での Google Cloud へのクラスター のインストール:インストールリリースコンテンツの内部ミラーを使用して、インストーラーでプロビジョニングされるインフラストラクチャーに OpenShift Container Platform を Google Cloud にインストールできます。この方法を使用して、ソフトウェアコンポーネントを取得するためにアクティブなインターネット接続を必要としないクラスターをインストールできます。ミラーリングされたコンテンツを使用して OpenShift Container Platform をインストールすることは可能ですが、クラスターが Google Cloud API を使用するにはインターネットへのアクセスが必要です。
- クラスターの既存の Virtual Private Cloud へ のインストール:OpenShift Container Platform を既存の Google Cloud Virtual Private Cloud (VPC)にインストールできます。このインストール方法は、新規アカウントまたはインフラストラクチャーを作成する際の制限など、会社のガイドラインによる制約がある場合に使用できます。
- プライベートクラスターの既存の VPC へ のインストール:プライベートクラスターを既存の Google Cloud VPC にインストールできます。この方法を使用して、インターネット上に表示されない内部ネットワークに OpenShift Container Platform をデプロイすることができます。
1.3.2. user-provisioned infrastructure へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
以下の方法のいずれかを使用して、プロビジョニングした Google Cloud インフラストラクチャーにクラスターをインストールできます。
- ユーザーによってプロビジョニングされるインフラストラクチャーを使用した Google Cloud へのクラスター のインストール:独自に提供する Google Cloud インフラストラクチャーに OpenShift Container Platform をインストールできます。提供される Deployment Manager テンプレートを使用して、インストールを支援できます。
- Google Cloud でのユーザーによってプロビジョニングされるインフラストラクチャーへの共有 VPC を使用したクラスターのインストール: 提供される Deployment Manager テンプレートを使用して、共有 VPC インフラストラクチャーに Google Cloud リソースを作成できます。
- ネットワークが制限された環境でのユーザーによってプロビジョニングされるインフラストラクチャーでの Google Cloud へのクラスターのインストール:ユーザー によってプロビジョニングされるインフラストラクチャーを使用して、ネットワークが制限された環境で OpenShift Container Platform を Google Cloud にインストールできます。インストールリリースコンテンツの内部ミラーを作成することにより、ソフトウェアコンポーネントを取得するためのアクティブなインターネット接続を必要としないクラスターをインストールできます。また、このインストール方法を使用して、クラスターが外部コンテンツに対する組織の制御の条件を満たすコンテナーイメージのみを使用するようにすることもできます。
1.4. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
第2章 Google Cloud プロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud プロジェクトを設定する必要があります。
2.1. Google Cloud プロジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。Google Cloud ドキュメントの Creating and Managing Projects を参照してください。
重要インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合は、Google Cloud プロジェクトは Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
2.2. Google Cloud での API サービスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。インストールに不要なオプションの API サービスを有効にすることもできます。Google Cloud ドキュメント の サービスの有効化 を 参照してください。
Expand 表2.1 必要な API サービス API サービス コンソールサービス名 Compute Engine API
compute.googleapis.comCloud Resource Manager API
cloudresourcemanager.googleapis.comGoogle DNS API
dns.googleapis.comIAM Service Account Credentials API
iamcredentials.googleapis.comIdentity and Access Management (IAM) API
iam.googleapis.comService Usage API
serviceusage.googleapis.comExpand 表2.2 オプションの API サービス API サービス コンソールサービス名 Google Cloud API
cloudapis.googleapis.comService Management API
servicemanagement.googleapis.comGoogle Cloud Storage JSON API
storage-api.googleapis.comCloud Storage
storage-component.googleapis.com
2.3. Google Cloud の DNS の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、使用する Google Cloud アカウントに、OpenShift Container Platform クラスターをホストする同じプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、Google Cloud または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法の詳細は、Google ドメイン を参照してください。
Google Cloud プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。Google Cloud ドキュメントの Creating public zones を参照してください。
openshiftcorp.comなどのルートドメインや、clusters.openshiftcorp.comなどのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。Google Cloud ドキュメント の Cloud DNS ネームサーバーの検索 を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。Google Cloud のドキュメントの Migrating to Cloud DNS を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
2.4. Google Cloud アカウントの制限 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは多くの Google Cloud コンポーネントを使用しますが、デフォルトの Quotas はデフォルトの OpenShift Container Platform クラスターをインストールする機能には影響しません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
| サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
|---|---|---|---|---|
| サービスアカウント | IAM | グローバル | 6 | 1 |
| ファイアウォールのルール | Compute | グローバル | 11 | 1 |
| 転送ルール | Compute | グローバル | 2 | 0 |
| 使用中のグローバル IP アドレス | Compute | グローバル | 4 | 1 |
| ヘルスチェック | Compute | グローバル | 3 | 0 |
| イメージ | Compute | グローバル | 1 | 0 |
| ネットワーク | Compute | グローバル | 2 | 0 |
| 静的 IP アドレス | Compute | リージョン | 4 | 1 |
| ルーター | Compute | グローバル | 1 | 0 |
| ルート | Compute | グローバル | 2 | 0 |
| サブネットワーク | Compute | グローバル | 2 | 0 |
| ターゲットプール | Compute | グローバル | 3 | 0 |
| CPU | Compute | リージョン | 28 | 4 |
| 永続ディスク SSD (GB) | Compute | リージョン | 896 | 128 |
インストール時にクォータが十分ではない場合、インストールプログラムは超過したクォータとリージョンの両方を示すエラーを表示します。
実際のクラスターサイズ、計画されるクラスターの拡張、およびアカウントに関連付けられた他のクラスターからの使用法を考慮してください。CPU、静的 IP アドレス、および永続ディスク SSD(ストレージ) のクォータは、ほとんどの場合に不十分になる可能性のあるものです。
以下のリージョンのいずれかにクラスターをデプロイする予定の場合、ストレージクォータの最大値を超え、CPU クォータ制限を超える可能性が高くなります。
-
asia-east2 -
asia-northeast2 -
asia-south1 -
australia-southeast1 -
europe-north1 -
europe-west2 -
europe-west3 -
europe-west6 -
northamerica-northeast1 -
southamerica-east1 -
us-west2
Google Cloud コンソール からリソースクォータを増やすことはできますが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
2.5. Google Cloud でのサービスアカウントの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には、Google API のデータにアクセスするために認証および承認を提供する Google Cloud サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。Google Cloud ドキュメント の サービスアカウントの作成 を参照してください。
サービスアカウントに適切な権限を付与します。以下の個別の権限を付与するか、
Ownerロールを割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることは、必要な権限を得る最も簡単な方法ですが、その場合、サービスアカウントはプロジェクトに対して完全な管理権限を持つことになります。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
サービスアカウントキーを JSON 形式で作成するか、サービスアカウントを Google Cloud 仮想マシンにアタッチできます。Google Cloud のドキュメント の サービスアカウントキー の作成 および インスタンスのサービスアカウントの作成および有効化 を参照してください。
クラスターを作成するには、サービスアカウントキーまたはサービスアカウントがアタッチされた仮想マシンが必要です。
注記サービスアカウントがアタッチされた仮想マシンを使用してクラスターを作成する場合は、インストール前に
install-config.yamlファイルでcredentialsMode: Manualを設定する必要があります。
2.5.1. 必須 Google Cloud ロール リンクのコピーリンクがクリップボードにコピーされました!
作成したサービスアカウントに Owner ロールを割り当てると、OpenShift Container Platform のインストールに必要な権限を含め、すべての権限がそのサービスアカウントに付与されます。組織のセキュリティーポリシーでより制限的なアクセス許可セットが必要な場合は、次のアクセス許可を持つサービスアカウントを作成できます。
Cloud Credential Operator を passthrough モードで動作するように設定する場合、粒度の細かいパーミッションではなくロールを使用する必要があります。
クラスターを既存の Virtual Private Cloud (VPC) にデプロイする場合、次のリストに記載されているネットワーク権限は、サービスアカウントに必要ありません。
インストールプログラムに必要なロール
- Compute 管理者
- IAM セキュリティー管理者
- サービスアカウント管理者
- Service Account Key Admin
- Service Account User
- Storage Admin
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
パススルー認証情報モードの使用に必要なロール
- ロードバランサー計算の管理者
- IAM ロールビューアー
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
| アカウント | ロール |
|---|---|
| コントロールプレーン |
|
|
| |
|
| |
|
| |
|
| |
| Compute |
|
|
|
2.5.2. インストーラーでプロビジョニングされるインフラストラクチャーに必要な Google Cloud 権限 リンクのコピーリンクがクリップボードにコピーされました!
作成したサービスアカウントに Owner ロールを割り当てると、OpenShift Container Platform のインストールに必要な権限を含め、すべての権限がそのサービスアカウントに付与されます。
組織のセキュリティーポリシーでより制限的なアクセス許可セットが必要な場合は、必要なアクセス許可を持つ カスタムロール を作成できます。OpenShift Container Platform クラスターを作成および削除するために、installer-provisioned infrastructure には、以下のパーミッションが必要です。
Cloud Credential Operator を passthrough モードで動作するように設定する場合、粒度の細かいパーミッションではなくロールを使用する必要があります。詳細は、「必須の GCP ロール」セクションの「パススルー認証情報モードを使用するための必要なロール」を参照してください。
例2.1 ネットワークリソースの作成に必要な権限
-
compute.addresses.create -
compute.addresses.createInternal -
compute.addresses.delete -
compute.addresses.get -
compute.addresses.list -
compute.addresses.use -
compute.addresses.useInternal -
compute.firewalls.create -
compute.firewalls.delete -
compute.firewalls.get -
compute.firewalls.list -
compute.forwardingRules.create -
compute.forwardingRules.get -
compute.forwardingRules.list -
compute.forwardingRules.setLabels -
compute.networks.create -
compute.networks.get -
compute.networks.list -
compute.networks.updatePolicy -
compute.routers.create -
compute.routers.get -
compute.routers.list -
compute.routers.update -
compute.routes.list -
compute.subnetworks.create -
compute.subnetworks.get -
compute.subnetworks.list -
compute.subnetworks.use -
compute.subnetworks.useExternalIp
例2.2 ロードバランサーリソースの作成に必要な権限
-
compute.regionBackendServices.create -
compute.regionBackendServices.get -
compute.regionBackendServices.list -
compute.regionBackendServices.update -
compute.regionBackendServices.use -
compute.targetPools.addInstance -
compute.targetPools.create -
compute.targetPools.get -
compute.targetPools.list -
compute.targetPools.removeInstance -
compute.targetPools.use
例2.3 DNS リソースの作成に必要な権限
-
dns.changes.create -
dns.changes.get -
dns.managedZones.create -
dns.managedZones.get -
dns.managedZones.list -
dns.networks.bindPrivateDNSZone -
dns.resourceRecordSets.create -
dns.resourceRecordSets.list
例2.4 サービスアカウントリソースの作成に必要な権限
-
iam.serviceAccountKeys.create -
iam.serviceAccountKeys.delete -
iam.serviceAccountKeys.get -
iam.serviceAccountKeys.list -
iam.serviceAccounts.actAs -
iam.serviceAccounts.create -
iam.serviceAccounts.delete -
iam.serviceAccounts.get -
iam.serviceAccounts.list -
resourcemanager.projects.get -
resourcemanager.projects.getIamPolicy -
resourcemanager.projects.setIamPolicy
例2.5 コンピューティングリソースの作成に必要な権限
-
compute.disks.create -
compute.disks.get -
compute.disks.list -
compute.instanceGroups.create -
compute.instanceGroups.delete -
compute.instanceGroups.get -
compute.instanceGroups.list -
compute.instanceGroups.update -
compute.instanceGroups.use -
compute.instances.create -
compute.instances.delete -
compute.instances.get -
compute.instances.list -
compute.instances.setLabels -
compute.instances.setMetadata -
compute.instances.setServiceAccount -
compute.instances.setTags -
compute.instances.use -
compute.machineTypes.get -
compute.machineTypes.list
例2.6 ストレージリソースの作成に必要
-
storage.buckets.create -
storage.buckets.delete -
storage.buckets.get -
storage.buckets.list -
storage.objects.create -
storage.objects.delete -
storage.objects.get -
storage.objects.list
例2.7 ヘルスチェックリソースを作成するために必要な権限
-
compute.healthChecks.create -
compute.healthChecks.get -
compute.healthChecks.list -
compute.healthChecks.useReadOnly -
compute.httpHealthChecks.create -
compute.httpHealthChecks.get -
compute.httpHealthChecks.list -
compute.httpHealthChecks.useReadOnly
例2.8 Google Cloud ゾーンとリージョン関連情報を取得するために必要な権限
-
compute.globalOperations.get -
compute.regionOperations.get -
compute.regions.list -
compute.zoneOperations.get -
compute.zones.get -
compute.zones.list
例2.9 サービスとクォータを確認するために必要な権限
-
monitoring.timeSeries.list -
serviceusage.quotas.get -
serviceusage.services.list
例2.10 インストールに必要な IAM パーミッション
-
iam.roles.get
例2.11 サービスアカウントキーなしで認証する場合に必要な権限
-
iam.serviceAccounts.signBlob
例2.12 インストールのためのオプションのイメージ権限
-
compute.images.list
例2.13 収集ブートストラップを実行するためのオプションの権限
-
compute.instances.getSerialPortOutput
例2.14 ネットワークリソースを削除するために必要な権限
-
compute.addresses.delete -
compute.addresses.deleteInternal -
compute.addresses.list -
compute.firewalls.delete -
compute.firewalls.list -
compute.forwardingRules.delete -
compute.forwardingRules.list -
compute.networks.delete -
compute.networks.list -
compute.networks.updatePolicy -
compute.routers.delete -
compute.routers.list -
compute.routes.list -
compute.subnetworks.delete -
compute.subnetworks.list
例2.15 ロードバランサーリソースを削除するために必要な権限
-
compute.regionBackendServices.delete -
compute.regionBackendServices.list -
compute.targetPools.delete -
compute.targetPools.list
例2.16 DNS リソースを削除するために必要な権限
-
dns.changes.create -
dns.managedZones.delete -
dns.managedZones.get -
dns.managedZones.list -
dns.resourceRecordSets.delete -
dns.resourceRecordSets.list
例2.17 サービスアカウントリソースを削除するために必要な権限
-
iam.serviceAccounts.delete -
iam.serviceAccounts.get -
iam.serviceAccounts.list -
resourcemanager.projects.getIamPolicy -
resourcemanager.projects.setIamPolicy
例2.18 コンピューティングリソースを削除するために必要な権限
-
compute.disks.delete -
compute.disks.list -
compute.instanceGroups.delete -
compute.instanceGroups.list -
compute.instances.delete -
compute.instances.list -
compute.instances.stop -
compute.machineTypes.list
例2.19 ストレージリソースの削除に必要
-
storage.buckets.delete -
storage.buckets.getIamPolicy -
storage.buckets.list -
storage.objects.delete -
storage.objects.list
例2.20 ヘルスチェックリソースを削除するために必要な権限
-
compute.healthChecks.delete -
compute.healthChecks.list -
compute.httpHealthChecks.delete -
compute.httpHealthChecks.list
例2.21 削除に必要なイメージ権限
-
compute.images.list
2.6. サポートされている Google Cloud リージョン リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを以下の Google Cloud リージョンにデプロイできます。
-
asia-east1(Changhua County, Taiwan) -
asia-east2(Hong Kong) -
asia-northeast1(Tokyo, Japan) -
asia-northeast2(Osaka, Japan) -
asia-northeast3(Seoul, South Korea) -
asia-south1(Mumbai, India) -
asia-south2(Delhi, India) -
asia-southeast1(Jurong West, Singapore) -
asia-southeast2(Jakarta, Indonesia) -
australia-southeast1(Sydney, Australia) -
australia-southeast2(Melbourne, Australia) -
europe-central2(Warsaw, Poland) -
europe-north1(Hamina, Finland) -
europe-southwest1(Madrid, Spain) -
europe-west1(St. Ghislain, Belgium) -
europe-west2(London, England, UK) -
europe-west3(Frankfurt, Germany) -
europe-west4(Eemshaven, Netherlands) -
europe-west6(Zürich, Switzerland) -
europe-west8(Milan, Italy) -
europe-west9(Paris, France) -
europe-west12(Turin, Italy) -
me-central1(ドーハ、カタール、中東) -
me-west1(Tel Aviv, Israel) -
northamerica-northeast1(Montréal, Québec, Canada) -
northamerica-northeast2(Toronto, Ontario, Canada) -
southamerica-east1(São Paulo, Brazil) -
southamerica-west1(Santiago, Chile) -
us-central1(Council Bluffs, Iowa, USA) -
us-east1(Moncks Corner, South Carolina, USA) -
us-east4(Ashburn, Northern Virginia, USA) -
us-east5(Columbus, Ohio) -
us-south1(Dallas, Texas) -
us-west1(The Dalles, Oregon, USA) -
us-west2(Los Angeles, California, USA) -
us-west3(Salt Lake City, Utah, USA) -
us-west4(Las Vegas, Nevada, USA)
リージョンおよびゾーンごとにどのマシンタイプのインスタンスが使用できるかを確認するには、Google の ドキュメント を参照してください。
2.7. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform クラスターを Google Cloud にインストールします。カスタマイズされたクラスターのインストール、またはデフォルトのオプションで クラスターのクイックインストール を実行できます。
第3章 GCP の IAM の手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境や、管理者がクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存する選択をしない場合に、クラスターのインストール前に Cloud Credential Operator (CCO) を手動モードにすることができます。
3.1. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法 リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。credentialsMode パラメーターの異なる値を install-config.yaml ファイルに設定し、組織のセキュリティー要件に応じて CCO を設定できます。
管理者レベルの認証情報シークレットをクラスターの kube-system プロジェクトに保存する選択をしない場合、OpenShift Container Platform をインストールする際に以下のいずれかのオプションを選択できます。
GCP ワークロード ID で手動モードを使用する:
CCO ユーティリティー (
ccoctl) を使用して、GCP ワークロード ID で手動モードを使用するようにクラスターを設定できます。CCO ユーティリティーを使用して GCP Workload Identity のクラスターを設定すると、コンポーネントに短期間の限定された特権のセキュリティークレデンシャルを提供するサービスアカウントトークンに署名します。注記このクレデンシャルストラテジーは、新しい OpenShift Container Platform クラスターでのみサポートされており、インストール中に設定する必要があります。この機能を使用するために、既存のクラスターが別のクレデンシャルストラテジーを使用するように再設定することはできません。
クラウド認証情報を手動で管理 します。
CCO の
credentialsModeパラメーターをManualに設定し、クラウド認証情報を手動で管理できます。手動モードを使用すると、クラスターに管理者レベルの認証情報を保存する必要なく、各クラスターコンポーネントに必要なパーミッションのみを指定できます。お使いの環境でクラウドプロバイダーのパブリック IAM エンドポイントへの接続がない場合も、このモードを使用できます。ただし、各アップグレードについて、パーミッションを新規リリースイメージを使用して手動で調整する必要があります。また、それらを要求するすべてのコンポーネントについて認証情報を手動で指定する必要があります。OpenShift Container Platform を mint モードでインストールした後に、管理者レベルの認証情報シークレットを削除 します。
credentialsModeパラメーターがMintに設定された状態で CCO を使用している場合、OpenShift Container Platform のインストール後に管理者レベルの認証情報を削除したり、ローテーションしたりできます。Mint モードは、CCO のデフォルト設定です。このオプションには、インストール時に管理者レベルの認証情報が必要になります。管理者レベルの認証情報はインストール時に、付与された一部のパーミッションと共に他の認証情報を生成するために使用されます。元の認証情報シークレットはクラスターに永続的に保存されません。
z-stream 以外のアップグレードの前に、認証情報のシークレットを管理者レベルの認証情報と共に元に戻す必要があります。認証情報が存在しない場合は、アップグレードがブロックされる可能性があります。
利用可能なすべての CCO 認証情報モードとそれらのサポートされるプラットフォームの詳細については、Cloud Credential Operator について を 参照してください。
3.2. IAM の手動作成 リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行して
install-config.yamlファイルを作成します。openshift-install create install-config --dir <installation_directory>
$ openshift-install create install-config --dir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<installation_directory>は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。install-config.yaml設定ファイルを編集し、credentialsModeパラメーターがManualに設定されるようにします。サンプル
install-config.yaml設定ファイルCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この行は、
credentialsModeパラメーターをManualに設定するために追加されます。
インストールプログラムが含まれているディレクトリーから次のコマンドを実行して、マニフェストを生成します。
openshift-install create manifests --dir <installation_directory>
$ openshift-install create manifests --dir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<installation_directory>は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。インストールプログラムが含まれるディレクトリーから、以下のコマンドを実行して、
openshift-installバイナリーがビルドされている OpenShift Container Platform リリースイメージの詳細を取得します。openshift-install version
$ openshift-install versionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64
release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、デプロイするクラウドをターゲットとするリリースイメージですべての
CredentialsRequestオブジェクトを見つけます。oc adm release extract quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 \ --credentials-requests \ --cloud=gcp
$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 \ --credentials-requests \ --cloud=gcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、それぞれの
CredentialsRequestオブジェクトに YAML ファイルが作成されます。サンプル
CredentialsRequestオブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以前に生成した
openshift-installマニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれのCredentialsRequestオブジェクトについてspec.secretRefに定義される namespace およびシークレット名を使用して保存する必要があります。シークレットを含む
CredentialsRequestオブジェクトのサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル
SecretオブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要リリースイメージには、
TechPreviewNoUpgrade機能セットによって有効になるテクノロジープレビュー機能のCredentialsRequestオブジェクトが含まれています。これらのオブジェクトは、release.openshift.io/feature-set: TechPreviewNoUpgradeアノテーションを使用して識別できます。- これらの機能を使用していない場合は、これらのオブジェクトのシークレットを作成しないでください。使用していないテクノロジープレビュー機能のシークレットを作成すると、インストールが失敗する可能性があります。
- これらの機能のいずれかを使用している場合は、対応するオブジェクトのシークレットを作成する必要があります。
TechPreviewNoUpgradeアノテーションを持つCredentialsRequestオブジェクトを見つけるには、次のコマンドを実行します。grep "release.openshift.io/feature-set" *
$ grep "release.openshift.io/feature-set" *Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
0000_30_capi-operator_00_credentials-request.yaml: release.openshift.io/feature-set: TechPreviewNoUpgrade
0000_30_capi-operator_00_credentials-request.yaml: release.openshift.io/feature-set: TechPreviewNoUpgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
インストールプログラムが含まれるディレクトリーから、クラスターの作成に進みます。
openshift-install create cluster --dir <installation_directory>
$ openshift-install create cluster --dir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
3.3. mint モード リンクのコピーリンクがクリップボードにコピーされました!
mint モードは、OpenShift Container Platform をサポートするプラットフォーム上の OpenShift Container Platform のデフォルトの Cloud Credential Operator (CCO) クレデンシャルモードです。このモードでは、CCO は提供される管理者レベルのクラウド認証情報を使用してクラスターを実行します。Mint モードは AWS と GCP でサポートされています。
mint モードでは、admin 認証情報は kube-system namespace に保存され、次に CCO によってクラスターの CredentialsRequest オブジェクトを処理し、特定のパーミッションでそれぞれのユーザーを作成するために使用されます。
mint モードには以下の利点があります。
- 各クラスターコンポーネントにはそれぞれが必要なパーミッションのみがあります。
- クラウド認証情報の自動の継続的な調整が行われます。これには、アップグレードに必要になる可能性のある追加の認証情報またはパーミッションが含まれます。
1 つの不利な点として、mint モードでは、admin 認証情報がクラスターの kube-system シークレットに保存される必要があります。
3.4. 管理者レベルの認証情報の削除またはローテーション機能を持つ mint モード リンクのコピーリンクがクリップボードにコピーされました!
現時点で、このモードは AWS および GCP でのみサポートされます。
このモードでは、ユーザーは通常の mint モードと同様に管理者レベルの認証情報を使用して OpenShift Container Platform をインストールします。ただし、このプロセスはクラスターのインストール後の管理者レベルの認証情報シークレットを削除します。
管理者は、Cloud Credential Operator に読み取り専用の認証情報について独自の要求を行わせることができます。これにより、すべての CredentialsRequest オブジェクトに必要なパーミッションがあることの確認が可能になります。そのため、いずれかの変更が必要にならない限り、管理者レベルの認証情報は必要になりません。関連付けられた認証情報が削除された後に、必要な場合は、これは基礎となるクラウドで破棄するか、非アクティブにできます。
z-stream 以外のアップグレードの前に、認証情報のシークレットを管理者レベルの認証情報と共に元に戻す必要があります。認証情報が存在しない場合は、アップグレードがブロックされる可能性があります。
管理者レベルの認証情報はクラスターに永続的に保存されません。
これらの手順を実行するには、短い期間にクラスターでの管理者レベルの認証情報が必要になります。また、アップグレードごとに管理者レベルの認証情報を使用してシークレットを手動で再インストールする必要があります。
3.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをインストールします。
第4章 Google Cloud へのクラスターの迅速なインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、デフォルトの設定オプションを使用するクラスターを Google Cloud にインストールできます。
4.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターをホストするための Google Cloud プロジェクトを設定 した。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。
4.2. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.3. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。
鍵がノードに渡されたら、鍵ペアを使用して、core ユーザーとして RHCOS ノードに SSH 接続できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519など) を指定します。既存のキーペアがある場合は、公開鍵が~/.sshディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64、ppc64le、およびs390xアーキテクチャーにインストールする予定の場合は、ed25519アルゴリズムを使用するキーは作成しないでください。代わりに、rsaアルゴリズムまたはecdsaアルゴリズムを使用するキーを作成します。SSH 公開鍵を表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gatherコマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsaおよび~/.ssh/id_dsaなどのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agentプロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agentに追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.4. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.5. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
クラスターに設定した Google Cloud アカウントのサービスアカウントキーを使用せず、以下の場所に保存されている既存の Google Cloud 認証情報を削除します。
-
GOOGLE_CREDENTIALS、GOOGLE_CLOUD_KEYFILE_JSON、またはGCLOUD_KEYFILE_JSON環境変数 -
~/.gcp/osServiceAccount.jsonファイル -
gcloud cliデフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info$ ./openshift-install create cluster --dir <installation_directory> \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
-
ディレクトリーに
プロンプト時に値を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- ホストで Google Cloud アカウント用のサービスアカウントキーを設定していない場合は、Google Cloud からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。7 文字以上の名前を指定すると、クラスター名から生成されるインフラストラクチャー ID で最初の 6 文字のみが使用されます。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Ownerロールをサービスアカウントに割り当てている場合、そのロールを削除し、これをViewerロールに置き換えることができます。 -
Service Account Key Adminロールが含まれている場合は、これを削除することができます。
-
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.6. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
4.9. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポート にすることができます。
第5章 カスタマイズを使用した Google Cloud へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、インストールプログラムが Google Cloud でプロビジョニングするインフラストラクチャーにカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。
5.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターをホストするための Google Cloud プロジェクトを設定 した。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。
5.2. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
5.3. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。
鍵がノードに渡されたら、鍵ペアを使用して、core ユーザーとして RHCOS ノードに SSH 接続できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519など) を指定します。既存のキーペアがある場合は、公開鍵が~/.sshディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64、ppc64le、およびs390xアーキテクチャーにインストールする予定の場合は、ed25519アルゴリズムを使用するキーは作成しないでください。代わりに、rsaアルゴリズムまたはecdsaアルゴリズムを使用するキーを作成します。SSH 公開鍵を表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gatherコマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsaおよび~/.ssh/id_dsaなどのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agentプロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agentに追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
5.4. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
5.5. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yamlファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- お使いのコンピューター上で Google Cloud アカウント用のサービスアカウントキーを設定していない場合は、Google Cloud からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yamlファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
5.5.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。
5.5.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
| 文字列 |
|
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
|
Kubernetes リソース | オブジェクト |
|
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
|
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
5.5.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
|
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
|
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
5.5.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
|
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
|
オプションの機能のセットを、 | 文字列配列 |
|
| コンピュートノードを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
|
|
Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。Google Cloud で共有 Virtual Private Cloud (VPC)にインストールする場合は、 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
|
| 文字列 |
|
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
|
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
|
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
5.5.1.4. 追加の Google Cloud 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の Google Cloud 設定パラメーターは以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
クラスターをデプロイする既存 Virtual Private Cloud (VPC) の名前。クラスターを共有 VPC にデプロイする場合は、共有 VPC を含む Google Cloud プロジェクトの名前で | 文字列。 |
|
| オプション:クラスターをデプロイする共有 VPC を含む Google Cloud プロジェクトの名前。 | 文字列。 |
|
| インストールプログラムがクラスターをインストールする Google Cloud プロジェクトの名前。 | 文字列。 |
|
| クラスターをホストする Google Cloud リージョンの名前。 |
有効なリージョン名 (例: |
|
| コントロールプレーンマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
| コンピュートマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
|
オプション:ネットワークタグを使用してファイアウォールルールを作成および管理する場合は、この値を |
|
|
|
オプション:パブリック DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、指定されたプロジェクトでの | パブリック DNS ゾーンを含むプロジェクトの名前。 |
|
|
オプション:既存パブリック DNS ゾーンの ID または名前。パブリック DNS ゾーンのドメインは、 | パブリック DNS ゾーンの名前。 |
|
|
オプション:プライベート DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、ホストプロジェクトでの | プライベート DNS ゾーンを含むプロジェクトの名前。 |
|
| オプション:既存プライベート DNS ゾーンの ID または名前。この値を設定しない場合、インストールプログラムはサービスプロジェクトにプライベート DNS ゾーンを作成します。 | プライベート DNS ゾーンの名前。 |
|
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストールプログラムは使用する前にソースイメージをコピーする必要があります。 |
|
| インストールプログラムがマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
|
|
デフォルトの | |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用される RHCOS イメージをダウンロードしてインストールします。両方のタイプのマシンで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンとコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
| オプション:コントロールプレーンおよびコンピュートマシンに追加する別のネットワークタグ。 |
|
|
| コントロールプレーンおよびコンピュートマシンの Google Cloud マシンタイプ。 |
Google Cloud マシンタイプ(例: |
|
| マシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| KMS キーが属する Key Management Service (KMS) キーリングの名前。 | KMS キーリング名。 |
|
| KMS キーリングが存在する Google Cloud の場所。 | Google Cloud のロケーション。 |
|
|
KMS キーリングが存在するプロジェクトの ID。この値は、設定されていない場合、デフォルトで | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンおよびコンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| コントロールプレーンマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コントロールプレーンマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コントロールプレーンマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コントロールプレーンマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコントロールプレーンマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コントロールプレーンマシンの Google Cloud ディスクタイプ。 |
コントロールプレーンマシンは、デフォルトの |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。コントロールプレーンマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コントロールプレーンマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コントロールプレーンマシンの |
|
|
|
コントロールプレーン マシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコントロールプレーンマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| コントロールマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コンピュートマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コンピュートマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コンピュートマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。この値が設定されていない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコンピュートマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コンピュートマシンの Google Cloud ディスクタイプ。 |
デフォルトの |
|
| オプション: デフォルトで、インストールプログラムはコンピュートマシンの起動に使用する RHCOS イメージをダウンロードしてインストールします。コンピュートマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コンピュートマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コンピュートマシンの |
|
|
|
コンピュートマシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコンピュートマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
5.5.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
5.5.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例5.1 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
5.5.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
インストールプロセスの一環として、カスタムマシンタイプを install-config.yaml ファイルで指定します。
カスタムマシンタイプのサンプル install-config.yaml ファイル
5.5.5. Google Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。
- 1 14 16 17 20
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 8
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 9
controlPlaneセクションは単一マッピングですが、computeセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、computeセクションの最初の行はハイフン-で始め、controlPlaneセクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 10
- 同時マルチスレッドまたは
hyperthreadingを有効/無効にするかどうか。デフォルトでは、同時マルチスレッドはマシンのコアのパフォーマンスを上げるために有効化されます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8などの大規模なマシンタイプを使用します。 - 5 11
- オプション: 仮想マシンと永続ボリュームの両方を暗号化するカスタム暗号化キーセクション。デフォルトのコンピュートサービスアカウントには、KMS キーを使用するためのパーミッションが付与され、適切な IAM ロールが割り当てられている必要があります。デフォルトのサービスアカウント名は、
service-<project_number>@compute-system.iam.gserviceaccount.comパターンをベースにしています。サービスアカウントの適切なパーミッションを付与する方法についての詳細は、マシン管理 → コンピュートマシンセットの作成 → Google Cloud でのコンピュートマシンセットの作成を参照してください。 - 6 12 18
- オプション: コントロールプレーンまたはコンピューティングマシンセットに適用するネットワークタグのセット。
platform.gcp.defaultMachinePlatform.tagsパラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。compute.platform.gcp.tagsパラメーターまたはcontrolPlane.platform.gcp.tagsパラメーターが設定されている場合は、platform.gcp.defaultMachinePlatform.tagsパラメーターを上書きします。 - 7 13 19
- オプション: インストールプログラムがコントロールプレーンマシンとコンピュートマシンの起動に使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。
platform.gcp.defaultMachinePlatform.osImageの下のprojectおよびnameパラメーターは、コントロールプレーンマシンとコンピュートマシンの両方に適用されます。controlPlane.platform.gcp.osImageまたはcompute.platform.gcp.osImageの下のprojectおよびnameパラメーターが設定されている場合、それらはplatform.gcp.defaultMachinePlatform.osImageパラメーターをオーバーライドします。 - 15
- インストールするクラスターネットワークプラグイン。サポートされている値は
OVNKubernetesとOpenShiftSDNです。デフォルトの値はOVNkubernetesです。 - 21
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64、ppc64le、およびs390xアーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 22
- クラスター内のマシンにアクセスするために使用する
sshKey値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。
5.5.6. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
5.6. Google Cloud Marketplace オファリングの使用 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud Marketplace オファリングを使用すると、Google Cloud を介して従量課金制(時間単位)で請求される OpenShift Container Platform クラスターをデプロイできますが、これは Red Hat によって直接サポートされます。
デフォルトで、インストールプログラムはコンピュートマシンのデプロイに使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。Google Cloud Marketplace の RHCOS イメージを使用して OpenShift Container Platform クラスターをデプロイするには、Google Cloud Marketplace オファーの場所を参照するように install-config.yaml ファイルを変更して、デフォルトの動作を上書きします。
Google Cloud Marketplace イメージを使用するには、コンピュートマシンの RHCOS イメージのみを変更する必要があります。コントロールプレーンマシンおよびインフラストラクチャーノードは、OpenShift Container Platform サブスクリプションを必要としないため、デフォルトでパブリック RHCOS デフォルトイメージを使用します。これにより、Google Cloud 請求にサブスクリプションコストが発生することはありません。したがって、クラスターのデフォルトのブートイメージやコントロールプレーンのブートイメージは変更しないでください。Google Cloud Marketplace イメージをそれらに適用すると、復元できない追加のライセンスコストが発生します。
前提条件
-
既存の
install-config.yamlファイルがある。
手順
compute.platform.gcp.osImageパラメーターを編集して、Google Cloud Marketplace イメージの場所を指定します。-
projectパラメーターをredhat-marketplace-publicに設定します。 nameパラメーターを、次のいずれかに設定します。- OpenShift Container Platform
-
redhat-coreos-ocp-48-x86-64-202210040145 - OpenShift Platform Plus
-
redhat-coreos-opp-48-x86-64-202206140145 - OpenShift Kubernetes Engine
-
redhat-coreos-oke-48-x86-64-202206140145
-
- ファイルを保存し、クラスターをデプロイする際に参照します。
コンピュートマシン用の Google Cloud Marketplace イメージを指定するサンプル install-config.yaml ファイル
5.7. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
クラスターに設定した Google Cloud アカウントのサービスアカウントキーを使用せず、以下の場所に保存されている既存の Google Cloud 認証情報を削除します。
-
GOOGLE_CREDENTIALS、GOOGLE_CLOUD_KEYFILE_JSON、またはGCLOUD_KEYFILE_JSON環境変数 -
~/.gcp/osServiceAccount.jsonファイル -
gcloud cliデフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info$ ./openshift-install create cluster --dir <installation_directory> \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Ownerロールをサービスアカウントに割り当てている場合、そのロールを削除し、これをViewerロールに置き換えることができます。 -
Service Account Key Adminロールが含まれている場合は、これを削除することができます。
-
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
5.8. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.10. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
5.11. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポート にすることができます。
第6章 ネットワークをカスタマイズして Google Cloud にクラスターをインストールする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、インストールプログラムが Google Cloud でプロビジョニングするインフラストラクチャーに、カスタマイズされたネットワーク設定でクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。
大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。
6.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターをホストするための Google Cloud プロジェクトを設定 した。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。
6.2. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
6.3. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。
鍵がノードに渡されたら、鍵ペアを使用して、core ユーザーとして RHCOS ノードに SSH 接続できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519など) を指定します。既存のキーペアがある場合は、公開鍵が~/.sshディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64、ppc64le、およびs390xアーキテクチャーにインストールする予定の場合は、ed25519アルゴリズムを使用するキーは作成しないでください。代わりに、rsaアルゴリズムまたはecdsaアルゴリズムを使用するキーを作成します。SSH 公開鍵を表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gatherコマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsaおよび~/.ssh/id_dsaなどのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agentプロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agentに追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
6.4. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
6.5. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yamlファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- お使いのコンピューター上で Google Cloud アカウント用のサービスアカウントキーを設定していない場合は、Google Cloud からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yamlファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
6.5.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。
6.5.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
| 文字列 |
|
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
|
Kubernetes リソース | オブジェクト |
|
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
|
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
6.5.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
|
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
|
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
6.5.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
|
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
|
オプションの機能のセットを、 | 文字列配列 |
|
| コンピュートノードを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
|
|
Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。Google Cloud で共有 Virtual Private Cloud (VPC)にインストールする場合は、 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
|
| 文字列 |
|
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
|
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
|
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
6.5.1.4. 追加の Google Cloud 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の Google Cloud 設定パラメーターは以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
クラスターをデプロイする既存 Virtual Private Cloud (VPC) の名前。クラスターを共有 VPC にデプロイする場合は、共有 VPC を含む Google Cloud プロジェクトの名前で | 文字列。 |
|
| オプション:クラスターをデプロイする共有 VPC を含む Google Cloud プロジェクトの名前。 | 文字列。 |
|
| インストールプログラムがクラスターをインストールする Google Cloud プロジェクトの名前。 | 文字列。 |
|
| クラスターをホストする Google Cloud リージョンの名前。 |
有効なリージョン名 (例: |
|
| コントロールプレーンマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
| コンピュートマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
|
オプション:ネットワークタグを使用してファイアウォールルールを作成および管理する場合は、この値を |
|
|
|
オプション:パブリック DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、指定されたプロジェクトでの | パブリック DNS ゾーンを含むプロジェクトの名前。 |
|
|
オプション:既存パブリック DNS ゾーンの ID または名前。パブリック DNS ゾーンのドメインは、 | パブリック DNS ゾーンの名前。 |
|
|
オプション:プライベート DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、ホストプロジェクトでの | プライベート DNS ゾーンを含むプロジェクトの名前。 |
|
| オプション:既存プライベート DNS ゾーンの ID または名前。この値を設定しない場合、インストールプログラムはサービスプロジェクトにプライベート DNS ゾーンを作成します。 | プライベート DNS ゾーンの名前。 |
|
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストールプログラムは使用する前にソースイメージをコピーする必要があります。 |
|
| インストールプログラムがマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
|
|
デフォルトの | |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用される RHCOS イメージをダウンロードしてインストールします。両方のタイプのマシンで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンとコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
| オプション:コントロールプレーンおよびコンピュートマシンに追加する別のネットワークタグ。 |
|
|
| コントロールプレーンおよびコンピュートマシンの Google Cloud マシンタイプ。 |
Google Cloud マシンタイプ(例: |
|
| マシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| KMS キーが属する Key Management Service (KMS) キーリングの名前。 | KMS キーリング名。 |
|
| KMS キーリングが存在する Google Cloud の場所。 | Google Cloud のロケーション。 |
|
|
KMS キーリングが存在するプロジェクトの ID。この値は、設定されていない場合、デフォルトで | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンおよびコンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| コントロールプレーンマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コントロールプレーンマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コントロールプレーンマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コントロールプレーンマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコントロールプレーンマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コントロールプレーンマシンの Google Cloud ディスクタイプ。 |
コントロールプレーンマシンは、デフォルトの |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。コントロールプレーンマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コントロールプレーンマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コントロールプレーンマシンの |
|
|
|
コントロールプレーン マシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコントロールプレーンマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| コントロールマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コンピュートマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コンピュートマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コンピュートマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。この値が設定されていない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコンピュートマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コンピュートマシンの Google Cloud ディスクタイプ。 |
デフォルトの |
|
| オプション: デフォルトで、インストールプログラムはコンピュートマシンの起動に使用する RHCOS イメージをダウンロードしてインストールします。コンピュートマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コンピュートマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コンピュートマシンの |
|
|
|
コンピュートマシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコンピュートマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
6.5.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
6.5.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例6.1 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
6.5.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
インストールプロセスの一環として、カスタムマシンタイプを install-config.yaml ファイルで指定します。
カスタムマシンタイプのサンプル install-config.yaml ファイル
6.5.5. Google Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。
- 1 14 17 18 21
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 8 15
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 9
controlPlaneセクションは単一マッピングですが、computeセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、computeセクションの最初の行はハイフン-で始め、controlPlaneセクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 10
- 同時マルチスレッドまたは
hyperthreadingを有効/無効にするかどうか。デフォルトでは、同時マルチスレッドはマシンのコアのパフォーマンスを上げるために有効化されます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8などの大規模なマシンタイプを使用します。 - 5 11
- オプション: 仮想マシンと永続ボリュームの両方を暗号化するカスタム暗号化キーセクション。デフォルトのコンピュートサービスアカウントには、KMS キーを使用するためのパーミッションが付与され、適切な IAM ロールが割り当てられている必要があります。デフォルトのサービスアカウント名は、
service-<project_number>@compute-system.iam.gserviceaccount.comパターンをベースにしています。サービスアカウントの適切なパーミッションを付与する方法についての詳細は、マシン管理 → コンピュートマシンセットの作成 → Google Cloud でのコンピュートマシンセットの作成を参照してください。 - 6 12 19
- オプション: コントロールプレーンまたはコンピューティングマシンセットに適用するネットワークタグのセット。
platform.gcp.defaultMachinePlatform.tagsパラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。compute.platform.gcp.tagsパラメーターまたはcontrolPlane.platform.gcp.tagsパラメーターが設定されている場合は、platform.gcp.defaultMachinePlatform.tagsパラメーターを上書きします。 - 7 13 20
- オプション: インストールプログラムがコントロールプレーンマシンとコンピュートマシンの起動に使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。
platform.gcp.defaultMachinePlatform.osImageの下のprojectおよびnameパラメーターは、コントロールプレーンマシンとコンピュートマシンの両方に適用されます。controlPlane.platform.gcp.osImageまたはcompute.platform.gcp.osImageの下のprojectおよびnameパラメーターが設定されている場合、それらはplatform.gcp.defaultMachinePlatform.osImageパラメーターをオーバーライドします。 - 16
- インストールするクラスターネットワークプラグイン。サポートされている値は
OVNKubernetesとOpenShiftSDNです。デフォルトの値はOVNkubernetesです。 - 22
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64、ppc64le、およびs390xアーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 23
- クラスター内のマシンにアクセスするために使用する
sshKey値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。
6.5.6. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
6.6. ネットワーク設定フェーズ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。
- フェーズ 1
マニフェストファイルを作成する前に、
install-config.yamlファイルで以下のネットワーク関連のフィールドをカスタマイズできます。-
networking.networkType -
networking.clusterNetwork -
networking.serviceNetwork networking.machineNetworkこれらのフィールドの詳細は、インストール設定パラメーター を参照してください。
注記優先される NIC が置かれている CIDR に一致する
networking.machineNetworkを設定します。重要CIDR 範囲
172.17.0.0/16は libVirt によって予約されています。この範囲、またはこの範囲と重複する範囲をクラスター内のネットワークに使用することはできません。
-
- フェーズ 2
-
openshift-install create manifestsを実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。
フェーズ 2 で、install-config.yaml ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 でネットワークプラグインをさらにカスタマイズできます。
6.7. 高度なネットワーク設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。
前提条件
-
install-config.yamlファイルを作成し、これに対する変更を完了している。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>は、クラスターのinstall-config.yamlファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.ymlという名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/ディレクトリーに作成します。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように、
cluster-network-03-config.ymlファイルで、クラスターの高度なネットワーク設定を指定します。OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション:
manifests/cluster-network-03-config.ymlファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/ディレクトリーを使用します。
6.8. 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- OpenShift SDN や OVN-Kubernetes などのクラスターネットワークプラグイン。
defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
6.8.1. Cluster Network Operator 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNO オブジェクトの名前。この名前は常に |
|
|
| Pod IP アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。
マニフェストを作成する前に、このフィールドを |
|
|
| サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14
マニフェストを作成する前に、このフィールドを |
|
|
| クラスターネットワークのネットワークプラグインを設定します。 |
|
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 |
複数のネットワークにオブジェクトをデプロイする必要があるクラスターの場合は、install-config.yaml ファイルで定義されている各ネットワークタイプの clusterNetwork.hostPrefix パラメーターに、必ず同じ値を指定してください。clusterNetwork.hostPrefix パラメーターにそれぞれ異なる値を設定すると、OVN-Kubernetes ネットワークプラグインに影響が及び、異なるノード間のオブジェクトトラフィックをプラグインが効果的にルーティングできなくなる可能性があります。
defaultNetwork オブジェクト設定
defaultNetwork オブジェクトの値は、以下の表で定義されます。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。 |
|
|
| このオブジェクトは、OpenShift SDN ネットワークプラグインに対してのみ有効です。 |
|
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OpenShift SDN ネットワークプラグインの設定
以下の表では、OpenShift SDN ネットワークプラグインの設定フィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は
|
|
|
| VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも クラスターインストール時またはインストール後のタスクとして値を設定できます。詳細は、OpenShift Container Platform Networking ドキュメントの "Changing the MTU for the cluster network" を参照してください。 |
|
|
|
すべての VXLAN パケットに使用するポート。デフォルト値は 別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。
Amazon Web Services (AWS) では、VXLAN にポート |
OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
|
| IPsec 暗号化を有効にするために空のオブジェクトを指定します。 |
|
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
|
| オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
|
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
|
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
| フィールド | 型 | 説明 |
|---|---|---|
|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
|
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
|
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
|
| string |
RFC5424 で定義される |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを 注記
OpenShift Container Platform 4.12 では、egress IP はプライマリーインターフェイスのみに割り当てられます。そのため、
インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
IPsec が有効な OVN-Kubernetes 設定の例
kubeProxyConfig オブジェクト設定
kubeProxyConfig オブジェクトの値は以下の表で定義されます。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
|
kubeProxyConfig:
proxyArguments:
iptables-min-sync-period:
- 0s
|
6.9. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
クラスターに設定した Google Cloud アカウントのサービスアカウントキーを使用せず、以下の場所に保存されている既存の Google Cloud 認証情報を削除します。
-
GOOGLE_CREDENTIALS、GOOGLE_CLOUD_KEYFILE_JSON、またはGCLOUD_KEYFILE_JSON環境変数 -
~/.gcp/osServiceAccount.jsonファイル -
gcloud cliデフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info$ ./openshift-install create cluster --dir <installation_directory> \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Ownerロールをサービスアカウントに割り当てている場合、そのロールを削除し、これをViewerロールに置き換えることができます。 -
Service Account Key Adminロールが含まれている場合は、これを削除することができます。
-
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
6.10. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.11. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.12. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
6.13. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポート にすることができます。
第7章 ネットワークが制限された環境での Google Cloud へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、既存の Google Virtual Private Cloud (VPC)にインストールリリースコンテンツの内部ミラーを作成することで、制限されたネットワークの Google Cloud にクラスターをインストールできます。
ミラーリングされたインストールリリースのコンテンツを使用して OpenShift Container Platform クラスターをインストールすることは可能ですが、クラスターが GCP API を使用するにはインターネットアクセスが必要になります。
7.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターをホストするための Google Cloud プロジェクトを設定 した。
非接続インストールのイメージをミラーリング し、お使いの OpenShift Container Platform のバージョンの
imageContentSourcesデータを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
Google Cloud に既存の VPC がある。installer-provisioned infrastructure を使用するネットワークが制限された環境にクラスターをインストールする場合は、installer-provisioned VPC を使用することはできません。以下の要件のいずれかを満たす user-provisioned VPC を使用する必要があります。
- ミラーレジストリーが含まれる。
- 別の場所でホストされるミラーレジストリーにアクセスするためのファイアウォールルールまたはピアリング接続がある。
-
ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。他のサイトへのアクセスを付与する必要がある場合もありますが、
*.googleapis.comおよびaccounts.google.comへのアクセスを付与する必要があります。 -
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。
7.2. ネットワークが制限された環境でのインストールについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
7.2.1. その他の制限 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersionステータスにはUnable to retrieve available updatesエラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
7.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
7.4. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。
鍵がノードに渡されたら、鍵ペアを使用して、core ユーザーとして RHCOS ノードに SSH 接続できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519など) を指定します。既存のキーペアがある場合は、公開鍵が~/.sshディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64、ppc64le、およびs390xアーキテクチャーにインストールする予定の場合は、ed25519アルゴリズムを使用するキーは作成しないでください。代わりに、rsaアルゴリズムまたはecdsaアルゴリズムを使用するキーを作成します。SSH 公開鍵を表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gatherコマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsaおよび~/.ssh/id_dsaなどのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agentプロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agentに追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
7.5. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
ミラーレジストリーの作成時に生成された
imageContentSources値を使用します。 - ミラーレジストリーの証明書の内容を取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yamlファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- お使いのコンピューター上で Google Cloud アカウント用のサービスアカウントキーを設定していない場合は、Google Cloud からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
install-config.yamlファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecretの値を更新して、レジストリーの認証情報を追加します。pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow <mirror_host_name>の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundleパラメーターおよび値を追加します。additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----Copy to Clipboard Copied! Toggle word wrap Toggle overflow この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
VPC のネットワークおよびサブネットを定義して、親の
platform.gcpフィールドの下にクラスターをインストールします。network: <existing_vpc> controlPlaneSubnet: <control_plane_subnet> computeSubnet: <compute_subnet>
network: <existing_vpc> controlPlaneSubnet: <control_plane_subnet> computeSubnet: <compute_subnet>Copy to Clipboard Copied! Toggle word wrap Toggle overflow platform.gcp.networkには、既存の Google VPC の名前を指定します。platform.gcp.controlPlaneSubnetおよびplatform.gcp.computeSubnetの場合には、コントロールプレーンマシンとコンピュートマシンをそれぞれデプロイするために既存のサブネットを指定します。次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの値には、ミラーレジストリーの作成時に記録された
imageContentSourcesを使用します。
-
必要な
install-config.yamlファイルに他の変更を加えます。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。 install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
7.5.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。
7.5.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
| 文字列 |
|
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
|
Kubernetes リソース | オブジェクト |
|
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
|
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
7.5.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
|
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
|
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
7.5.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
|
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
|
オプションの機能のセットを、 | 文字列配列 |
|
| コンピュートノードを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
|
|
Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。Google Cloud で共有 Virtual Private Cloud (VPC)にインストールする場合は、 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
|
| 文字列 |
|
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
|
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
|
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
7.5.1.4. 追加の Google Cloud 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の Google Cloud 設定パラメーターは以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
クラスターをデプロイする既存 Virtual Private Cloud (VPC) の名前。クラスターを共有 VPC にデプロイする場合は、共有 VPC を含む Google Cloud プロジェクトの名前で | 文字列。 |
|
| オプション:クラスターをデプロイする共有 VPC を含む Google Cloud プロジェクトの名前。 | 文字列。 |
|
| インストールプログラムがクラスターをインストールする Google Cloud プロジェクトの名前。 | 文字列。 |
|
| クラスターをホストする Google Cloud リージョンの名前。 |
有効なリージョン名 (例: |
|
| コントロールプレーンマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
| コンピュートマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
|
オプション:ネットワークタグを使用してファイアウォールルールを作成および管理する場合は、この値を |
|
|
|
オプション:パブリック DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、指定されたプロジェクトでの | パブリック DNS ゾーンを含むプロジェクトの名前。 |
|
|
オプション:既存パブリック DNS ゾーンの ID または名前。パブリック DNS ゾーンのドメインは、 | パブリック DNS ゾーンの名前。 |
|
|
オプション:プライベート DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、ホストプロジェクトでの | プライベート DNS ゾーンを含むプロジェクトの名前。 |
|
| オプション:既存プライベート DNS ゾーンの ID または名前。この値を設定しない場合、インストールプログラムはサービスプロジェクトにプライベート DNS ゾーンを作成します。 | プライベート DNS ゾーンの名前。 |
|
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストールプログラムは使用する前にソースイメージをコピーする必要があります。 |
|
| インストールプログラムがマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
|
|
デフォルトの | |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用される RHCOS イメージをダウンロードしてインストールします。両方のタイプのマシンで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンとコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
| オプション:コントロールプレーンおよびコンピュートマシンに追加する別のネットワークタグ。 |
|
|
| コントロールプレーンおよびコンピュートマシンの Google Cloud マシンタイプ。 |
Google Cloud マシンタイプ(例: |
|
| マシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| KMS キーが属する Key Management Service (KMS) キーリングの名前。 | KMS キーリング名。 |
|
| KMS キーリングが存在する Google Cloud の場所。 | Google Cloud のロケーション。 |
|
|
KMS キーリングが存在するプロジェクトの ID。この値は、設定されていない場合、デフォルトで | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンおよびコンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| コントロールプレーンマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コントロールプレーンマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コントロールプレーンマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コントロールプレーンマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコントロールプレーンマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コントロールプレーンマシンの Google Cloud ディスクタイプ。 |
コントロールプレーンマシンは、デフォルトの |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。コントロールプレーンマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コントロールプレーンマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コントロールプレーンマシンの |
|
|
|
コントロールプレーン マシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコントロールプレーンマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| コントロールマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コンピュートマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コンピュートマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コンピュートマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。この値が設定されていない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコンピュートマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コンピュートマシンの Google Cloud ディスクタイプ。 |
デフォルトの |
|
| オプション: デフォルトで、インストールプログラムはコンピュートマシンの起動に使用する RHCOS イメージをダウンロードしてインストールします。コンピュートマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コンピュートマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コンピュートマシンの |
|
|
|
コンピュートマシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコンピュートマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
7.5.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
7.5.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例7.1 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
7.5.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
インストールプロセスの一環として、カスタムマシンタイプを install-config.yaml ファイルで指定します。
カスタムマシンタイプのサンプル install-config.yaml ファイル
7.5.5. Google Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。
- 1 14 16 17
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 8
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 9
controlPlaneセクションは単一マッピングですが、computeセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、computeセクションの最初の行はハイフン-で始め、controlPlaneセクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 10
- 同時マルチスレッドまたは
hyperthreadingを有効/無効にするかどうか。デフォルトでは、同時マルチスレッドはマシンのコアのパフォーマンスを上げるために有効化されます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8などの大規模なマシンタイプを使用します。 - 5 11
- オプション: 仮想マシンと永続ボリュームの両方を暗号化するカスタム暗号化キーセクション。デフォルトのコンピュートサービスアカウントには、KMS キーを使用するためのパーミッションが付与され、適切な IAM ロールが割り当てられている必要があります。デフォルトのサービスアカウント名は、
service-<project_number>@compute-system.iam.gserviceaccount.comパターンをベースにしています。サービスアカウントの適切なパーミッションを付与する方法についての詳細は、マシン管理 → コンピュートマシンセットの作成 → Google Cloud でのコンピュートマシンセットの作成を参照してください。 - 6 12 18
- オプション: コントロールプレーンまたはコンピューティングマシンセットに適用するネットワークタグのセット。
platform.gcp.defaultMachinePlatform.tagsパラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。compute.platform.gcp.tagsパラメーターまたはcontrolPlane.platform.gcp.tagsパラメーターが設定されている場合は、platform.gcp.defaultMachinePlatform.tagsパラメーターを上書きします。 - 7 13 19
- オプション: インストールプログラムがコントロールプレーンマシンとコンピュートマシンの起動に使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。
platform.gcp.defaultMachinePlatform.osImageの下のprojectおよびnameパラメーターは、コントロールプレーンマシンとコンピュートマシンの両方に適用されます。controlPlane.platform.gcp.osImageまたはcompute.platform.gcp.osImageの下のprojectおよびnameパラメーターが設定されている場合、それらはplatform.gcp.defaultMachinePlatform.osImageパラメーターをオーバーライドします。 - 15
- インストールするクラスターネットワークプラグイン。サポートされている値は
OVNKubernetesとOpenShiftSDNです。デフォルトの値はOVNkubernetesです。 - 20
- 既存 VPC の名前を指定します。
- 21
- コントロールプレーンマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 22
- コンピュートマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 23
<local_registry>には、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.comまたはregistry.example.com:5000<credentials>について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 24
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64、ppc64le、およびs390xアーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 25
- クラスター内のマシンにアクセスするために使用する
sshKey値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。 - 26
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 27
- リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSourcesセクションを指定します。
7.5.6. Google Cloud でのグローバルアクセスが設定された Ingress コントローラーの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud クラスターへのグローバルアクセスのある Ingress コントローラーを作成できます。グローバルアクセスは、内部ロードバランサーを使用する Ingress コントローラーでのみ利用できます。
前提条件
-
install-config.yamlを作成し、これに対する変更を完了している。
手順
新しい Google Cloud クラスターでのグローバルアクセスのある Ingress コントローラーの作成
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストファイルを作成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、クラスターのinstall-config.yamlファイルが含まれるディレクトリーの名前を指定します。
cluster-ingress-default-ingresscontroller.yamlという名前のファイルを<installation_directory>/manifests/ディレクトリーに作成します。touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、クラスターのmanifests/ディレクトリーが含まれるディレクトリー名を指定します。
ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが
manifests/ディレクトリーに置かれます。ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
cluster-ingress-default-ingresscontroller.yaml
cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow エディターで
cluster-ingress-default-ingresscontroller.yamlファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。サンプル
clientAccess設定をGlobalに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5.7. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
7.6. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
クラスターに設定した Google Cloud アカウントのサービスアカウントキーを使用せず、以下の場所に保存されている既存の Google Cloud 認証情報を削除します。
-
GOOGLE_CREDENTIALS、GOOGLE_CLOUD_KEYFILE_JSON、またはGCLOUD_KEYFILE_JSON環境変数 -
~/.gcp/osServiceAccount.jsonファイル -
gcloud cliデフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info$ ./openshift-install create cluster --dir <installation_directory> \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Ownerロールをサービスアカウントに割り当てている場合、そのロールを削除し、これをViewerロールに置き換えることができます。 -
Service Account Key Adminロールが含まれている場合は、これを削除することができます。
-
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
7.7. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.8. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.9. デフォルトの OperatorHub カタログソースの無効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: trueをOperatorHubオブジェクトに追加して、デフォルトカタログのソースを無効にします。oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
7.10. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
7.11. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- インストールの検証
- クラスターをカスタマイズします。
-
Cluster Samples Operator および
must-gatherツールの イメージストリームを設定し ます。 - ネットワークが制限された環境で Operator Lifecycle Manager (OLM)を使用する 方法を説明します。
- クラスターのインストールに使用したミラーレジストリーに信頼される CA がある場合、トラストストアを設定してこれをクラスターに追加 します。
- 必要に応じて、リモートヘルスレポート にすることができます。
- 必要に応じて、非接続クラスターの登録 を参照してください。
第8章 Google Cloud 上のクラスターの既存 VPC へのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、Google Cloud 上の既存の Virtual Private Cloud (VPC)にクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。
8.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターをホストするための Google Cloud プロジェクトを設定 した。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。
8.2. カスタム VPC の使用について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、Google Cloud の既存の Virtual Private Cloud (VPC)内の既存のサブネットにクラスターをデプロイできます。OpenShift Container Platform を既存の Google Cloud VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより簡単に守ったりできる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。サブネットのネットワークを設定する必要があります。
8.2.1. VPC を使用するための要件 リンクのコピーリンクがクリップボードにコピーされました!
VPC CIDR ブロックとマシンネットワーク CIDR の組み合わせは、空であってはなりません。サブネットはマシンネットワーク内にある必要があります。
インストールプログラムでは、次のコンポーネントは作成されません。
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC ネットワーク
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
8.2.2. VPC 検証 リンクのコピーリンクがクリップボードにコピーされました!
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- コントロールプレーンマシン用に 1 つのサブネットを提供し、コンピューティングマシン用に 1 つのサブネットを提供します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
8.2.3. パーミッションの区分 リンクのコピーリンクがクリップボードにコピーされました!
一部の個人は、クラウド内に他のリソースとは異なるリソースを作成できます。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
8.2.4. クラスター間の分離 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体で許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
8.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
8.4. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。
鍵がノードに渡されたら、鍵ペアを使用して、core ユーザーとして RHCOS ノードに SSH 接続できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519など) を指定します。既存のキーペアがある場合は、公開鍵が~/.sshディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64、ppc64le、およびs390xアーキテクチャーにインストールする予定の場合は、ed25519アルゴリズムを使用するキーは作成しないでください。代わりに、rsaアルゴリズムまたはecdsaアルゴリズムを使用するキーを作成します。SSH 公開鍵を表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gatherコマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsaおよび~/.ssh/id_dsaなどのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agentプロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agentに追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
8.5. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
8.6. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yamlファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- お使いのコンピューター上で Google Cloud アカウント用のサービスアカウントキーを設定していない場合は、Google Cloud からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yamlファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
8.6.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。
8.6.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
| 文字列 |
|
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
|
Kubernetes リソース | オブジェクト |
|
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
|
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
8.6.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
|
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
|
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
8.6.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
|
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
|
オプションの機能のセットを、 | 文字列配列 |
|
| コンピュートノードを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
|
|
Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。Google Cloud で共有 Virtual Private Cloud (VPC)にインストールする場合は、 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
|
| 文字列 |
|
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
|
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
|
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
8.6.1.4. 追加の Google Cloud 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の Google Cloud 設定パラメーターは以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
クラスターをデプロイする既存 Virtual Private Cloud (VPC) の名前。クラスターを共有 VPC にデプロイする場合は、共有 VPC を含む Google Cloud プロジェクトの名前で | 文字列。 |
|
| オプション:クラスターをデプロイする共有 VPC を含む Google Cloud プロジェクトの名前。 | 文字列。 |
|
| インストールプログラムがクラスターをインストールする Google Cloud プロジェクトの名前。 | 文字列。 |
|
| クラスターをホストする Google Cloud リージョンの名前。 |
有効なリージョン名 (例: |
|
| コントロールプレーンマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
| コンピュートマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
|
オプション:ネットワークタグを使用してファイアウォールルールを作成および管理する場合は、この値を |
|
|
|
オプション:パブリック DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、指定されたプロジェクトでの | パブリック DNS ゾーンを含むプロジェクトの名前。 |
|
|
オプション:既存パブリック DNS ゾーンの ID または名前。パブリック DNS ゾーンのドメインは、 | パブリック DNS ゾーンの名前。 |
|
|
オプション:プライベート DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、ホストプロジェクトでの | プライベート DNS ゾーンを含むプロジェクトの名前。 |
|
| オプション:既存プライベート DNS ゾーンの ID または名前。この値を設定しない場合、インストールプログラムはサービスプロジェクトにプライベート DNS ゾーンを作成します。 | プライベート DNS ゾーンの名前。 |
|
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストールプログラムは使用する前にソースイメージをコピーする必要があります。 |
|
| インストールプログラムがマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
|
|
デフォルトの | |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用される RHCOS イメージをダウンロードしてインストールします。両方のタイプのマシンで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンとコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
| オプション:コントロールプレーンおよびコンピュートマシンに追加する別のネットワークタグ。 |
|
|
| コントロールプレーンおよびコンピュートマシンの Google Cloud マシンタイプ。 |
Google Cloud マシンタイプ(例: |
|
| マシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| KMS キーが属する Key Management Service (KMS) キーリングの名前。 | KMS キーリング名。 |
|
| KMS キーリングが存在する Google Cloud の場所。 | Google Cloud のロケーション。 |
|
|
KMS キーリングが存在するプロジェクトの ID。この値は、設定されていない場合、デフォルトで | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンおよびコンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| コントロールプレーンマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コントロールプレーンマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コントロールプレーンマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コントロールプレーンマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコントロールプレーンマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コントロールプレーンマシンの Google Cloud ディスクタイプ。 |
コントロールプレーンマシンは、デフォルトの |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。コントロールプレーンマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コントロールプレーンマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コントロールプレーンマシンの |
|
|
|
コントロールプレーン マシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコントロールプレーンマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| コントロールマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コンピュートマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コンピュートマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コンピュートマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。この値が設定されていない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコンピュートマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コンピュートマシンの Google Cloud ディスクタイプ。 |
デフォルトの |
|
| オプション: デフォルトで、インストールプログラムはコンピュートマシンの起動に使用する RHCOS イメージをダウンロードしてインストールします。コンピュートマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コンピュートマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コンピュートマシンの |
|
|
|
コンピュートマシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコンピュートマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
8.6.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
8.6.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例8.1 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
8.6.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
インストールプロセスの一環として、カスタムマシンタイプを install-config.yaml ファイルで指定します。
カスタムマシンタイプのサンプル install-config.yaml ファイル
8.6.5. Google Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。
- 1 14 16 17 23
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 8
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 9
controlPlaneセクションは単一マッピングですが、computeセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、computeセクションの最初の行はハイフン-で始め、controlPlaneセクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 10
- 同時マルチスレッドまたは
hyperthreadingを有効/無効にするかどうか。デフォルトでは、同時マルチスレッドはマシンのコアのパフォーマンスを上げるために有効化されます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8などの大規模なマシンタイプを使用します。 - 5 11
- オプション: 仮想マシンと永続ボリュームの両方を暗号化するカスタム暗号化キーセクション。デフォルトのコンピュートサービスアカウントには、KMS キーを使用するためのパーミッションが付与され、適切な IAM ロールが割り当てられている必要があります。デフォルトのサービスアカウント名は、
service-<project_number>@compute-system.iam.gserviceaccount.comパターンをベースにしています。サービスアカウントの適切なパーミッションを付与する方法についての詳細は、マシン管理 → コンピュートマシンセットの作成 → Google Cloud でのコンピュートマシンセットの作成を参照してください。 - 6 12 18
- オプション: コントロールプレーンまたはコンピューティングマシンセットに適用するネットワークタグのセット。
platform.gcp.defaultMachinePlatform.tagsパラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。compute.platform.gcp.tagsパラメーターまたはcontrolPlane.platform.gcp.tagsパラメーターが設定されている場合は、platform.gcp.defaultMachinePlatform.tagsパラメーターを上書きします。 - 7 13 19
- オプション: インストールプログラムがコントロールプレーンマシンとコンピュートマシンの起動に使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。
platform.gcp.defaultMachinePlatform.osImageの下のprojectおよびnameパラメーターは、コントロールプレーンマシンとコンピュートマシンの両方に適用されます。controlPlane.platform.gcp.osImageまたはcompute.platform.gcp.osImageの下のprojectおよびnameパラメーターが設定されている場合、それらはplatform.gcp.defaultMachinePlatform.osImageパラメーターをオーバーライドします。 - 15
- インストールするクラスターネットワークプラグイン。サポートされている値は
OVNKubernetesとOpenShiftSDNです。デフォルトの値はOVNkubernetesです。 - 20
- 既存 VPC の名前を指定します。
- 21
- コントロールプレーンマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 22
- コンピュートマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 24
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64、ppc64le、およびs390xアーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 25
- クラスター内のマシンにアクセスするために使用する
sshKey値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。
8.6.6. Google Cloud でのグローバルアクセスが設定された Ingress コントローラーの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud クラスターへのグローバルアクセスのある Ingress コントローラーを作成できます。グローバルアクセスは、内部ロードバランサーを使用する Ingress コントローラーでのみ利用できます。
前提条件
-
install-config.yamlを作成し、これに対する変更を完了している。
手順
新しい Google Cloud クラスターでのグローバルアクセスのある Ingress コントローラーの作成
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストファイルを作成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、クラスターのinstall-config.yamlファイルが含まれるディレクトリーの名前を指定します。
cluster-ingress-default-ingresscontroller.yamlという名前のファイルを<installation_directory>/manifests/ディレクトリーに作成します。touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、クラスターのmanifests/ディレクトリーが含まれるディレクトリー名を指定します。
ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが
manifests/ディレクトリーに置かれます。ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
cluster-ingress-default-ingresscontroller.yaml
cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow エディターで
cluster-ingress-default-ingresscontroller.yamlファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。サンプル
clientAccess設定をGlobalに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6.7. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
8.7. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
クラスターに設定した Google Cloud アカウントのサービスアカウントキーを使用せず、以下の場所に保存されている既存の Google Cloud 認証情報を削除します。
-
GOOGLE_CREDENTIALS、GOOGLE_CLOUD_KEYFILE_JSON、またはGCLOUD_KEYFILE_JSON環境変数 -
~/.gcp/osServiceAccount.jsonファイル -
gcloud cliデフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info$ ./openshift-install create cluster --dir <installation_directory> \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Ownerロールをサービスアカウントに割り当てている場合、そのロールを削除し、これをViewerロールに置き換えることができます。 -
Service Account Key Adminロールが含まれている場合は、これを削除することができます。
-
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
8.8. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.9. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.10. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
8.11. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポート にすることができます。
第10章 プライベートクラスターの Google Cloud へのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、Google Cloud 上の既存の VPC にプライベートクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml ファイルでパラメーターを変更します。
10.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターをホストするための Google Cloud プロジェクトを設定 した。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
-
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。
10.2. プライベートクラスター リンクのコピーリンクがクリップボードにコピーされました!
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
クラスターにパブリックサブネットがある場合、管理者により作成されたロードバランサーサービスはパブリックにアクセスできる可能性があります。クラスターのセキュリティーを確保するには、これらのサービスに明示的にプライベートアノテーションが付けられていることを確認してください。
プライベートクラスターをデプロイするには、以下を行う必要があります。
- 要件を満たす既存のネットワークを使用します。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
以下にアクセスできるマシンからデプロイ。
- プロビジョニングするクラウドの API サービス。
- プロビジョニングするネットワーク上のホスト。
- インストールメディアを取得するインターネット。
これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
10.2.1. Google Cloud のプライベートクラスター リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud でプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC とサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、内部トラフィック用としてのみ Ingress Operator および API サーバーを設定します。
クラスターには、Google Cloud API にアクセスするためにインターネットへのアクセスが依然として必要です。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックネットワークロードバランサー
-
クラスターの
baseDomainに一致するパブリック DNS ゾーン
インストールプログラムは、プライベート DNS ゾーンおよびクラスターに必要なレコードを作成するために指定する baseDomain を使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
ソースタグに基づいて外部ロードバランサーへのアクセスを制限できないため、プライベートクラスターは内部ロードバランサーのみを使用して内部インスタンスへのアクセスを許可します。
内部ロードバランサーは、ネットワークロードバランサーが使用するターゲットプールではなく、インスタンスグループに依存します。インストールプログラムは、グループにインスタンスがない場合でも、各ゾーンのインスタンスグループを作成します。
- クラスター IP アドレスは内部のみで使用されます。
- 1 つの転送ルールが Kubernetes API およびマシン設定サーバーポートの両方を管理します。
- バックエンドサービスは、各ゾーンのインスタンスグループと、存在する場合はブートストラップインスタンスグループで構成されます。
- ファイアウォールは、内部のソース範囲のみに基づく単一ルールを使用します。
10.2.1.1. 制限事項 リンクのコピーリンクがクリップボードにコピーされました!
ロードバランサーの機能の違いにより、マシン設定サーバー /healthz のヘルスチェックは実行されません。2 つの内部ロードバランサーが 1 つの IP アドレスを共有できませんが、2 つのネットワークロードバランサーは 1 つの外部 IP アドレスを共有できます。インスタンスが健全であるかどうかは、ポート 6443 の /readyz チェックで完全に判別されます。
10.3. カスタム VPC の使用について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターを Google Cloud の既存の VPC にデプロイできます。これを実行する場合、VPC 内の既存のサブネットおよびルーティングルールも使用する必要があります。
OpenShift Container Platform を既存の Google Cloud VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより簡単に守ったりできる場合があります。VPC の作成に必要なインフラストラクチャーの作成パーミッションを取得できない場合には、このオプションを使用できます。
10.3.1. VPC を使用するための要件 リンクのコピーリンクがクリップボードにコピーされました!
インストールプログラムは、以下のコンポーネントを作成しなくなります。
- VPC
- サブネット
- Cloud Router
- Cloud NAT
- NAT IP アドレス
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。インストールプログラムは、使用するクラスターのネットワーク範囲を細分化できず、サブネットのルートテーブルを設定するか、DHCP などの VPC オプションを設定します。これは、クラスターのインストール前に設定する必要があります。
VPC およびサブネットは以下の要件を満たす必要があります。
- VPC は、OpenShift Container Platform クラスターをデプロイするのと同じ Google Cloud プロジェクトに存在する必要があります。
- コントロールプレーンおよびコンピュートマシンからインターネットにアクセスできるようにするには、サブネットで Cloud NAT を設定してこれに対する Egress を許可する必要があります。これらのマシンにパブリックアドレスがありません。インターネットへのアクセスが必要ない場合でも、インストールプログラムおよびイメージを取得できるように VPC ネットワークに対して Egress を許可する必要があります。複数の Cloud NAT を共有サブネットで設定できないため、インストールプログラムはこれを設定できません。
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定するすべてのサブネットが存在し、指定した VPC に属します。
- サブネットの CIDR はマシン CIDR に属します。
- クラスターのコントロールプレーンおよびコンピュートマシンをデプロイするためにサブネットを指定する必要があります。両方のマシンタイプに同じサブネットを使用できます。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。
10.3.2. パーミッションの区分 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.3 以降では、インストールプログラムによってプロビジョニングされたインフラストラクチャークラスターがクラスターをデプロイする場合に必要だったすべての権限を持つ必要はありません。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する Google Cloud の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ロードバランサー、セキュリティーグループ、ストレージおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
10.3.3. クラスター間の分離 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を既存ネットワークにデプロイする場合、クラスターサービスの分離は、クラスターのインフラストラクチャー ID によるクラスター内のマシンを参照するファイアウォールルールによって保持されます。クラスター内のトラフィックのみが許可されます。
複数のクラスターを同じ VPC にデプロイする場合、以下のコンポーネントはクラスター間のアクセスを共有する可能性があります。
- API: 外部公開ストラテジーでグローバルに利用可能か、内部公開ストラテジーのネットワーク全体で利用できる。
- デバッグツール: SSH および ICMP アクセス用にマシン CIDR に対して開かれている仮想マシンインスタンス上のポートなど。
10.4. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
10.5. クラスターノードの SSH アクセス用のキーペアの生成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core ユーザーの ~/.ssh/authorized_keys リストに追加され、パスワードなしの認証が可能になります。
鍵がノードに渡されたら、鍵ペアを使用して、core ユーザーとして RHCOS ノードに SSH 接続できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。./openshift-install gather コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519など) を指定します。既存のキーペアがある場合は、公開鍵が~/.sshディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64、ppc64le、およびs390xアーキテクチャーにインストールする予定の場合は、ed25519アルゴリズムを使用するキーは作成しないでください。代わりに、rsaアルゴリズムまたはecdsaアルゴリズムを使用するキーを作成します。SSH 公開鍵を表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gatherコマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsaおよび~/.ssh/id_dsaなどのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agentプロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agentに追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
10.6. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
10.7. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
mkdir <installation_directory>
$ mkdir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの
install-config.yamlファイルテンプレートをカスタマイズし、ファイルを<installation_directory>に保存します。注記この設定ファイルの名前を
install-config.yamlと付ける必要があります。多くのクラスターのインストールに使用できるように、
install-config.yamlファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yamlファイルを使用するため、今すぐこのファイルをバックアップしてください。
10.7.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml ファイルで変更することはできません。
10.7.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
| 文字列 |
|
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
|
Kubernetes リソース | オブジェクト |
|
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
|
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
10.7.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
|
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
|
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
10.7.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
|
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
|
オプションの機能のセットを、 | 文字列配列 |
|
| コンピュートノードを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
|
|
Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。Google Cloud で共有 Virtual Private Cloud (VPC)にインストールする場合は、 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
|
| 文字列 |
|
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
|
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
|
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
10.7.1.4. 追加の Google Cloud 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の Google Cloud 設定パラメーターは以下の表で説明されています。
| パラメーター | 説明 | 値 |
|---|---|---|
|
|
クラスターをデプロイする既存 Virtual Private Cloud (VPC) の名前。クラスターを共有 VPC にデプロイする場合は、共有 VPC を含む Google Cloud プロジェクトの名前で | 文字列。 |
|
| オプション:クラスターをデプロイする共有 VPC を含む Google Cloud プロジェクトの名前。 | 文字列。 |
|
| インストールプログラムがクラスターをインストールする Google Cloud プロジェクトの名前。 | 文字列。 |
|
| クラスターをホストする Google Cloud リージョンの名前。 |
有効なリージョン名 (例: |
|
| コントロールプレーンマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
| コンピュートマシンをデプロイする既存サブネットの名前。 | サブネット名。 |
|
|
オプション:ネットワークタグを使用してファイアウォールルールを作成および管理する場合は、この値を |
|
|
|
オプション:パブリック DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、指定されたプロジェクトでの | パブリック DNS ゾーンを含むプロジェクトの名前。 |
|
|
オプション:既存パブリック DNS ゾーンの ID または名前。パブリック DNS ゾーンのドメインは、 | パブリック DNS ゾーンの名前。 |
|
|
オプション:プライベート DNS ゾーンを含むプロジェクトの名前。この値を設定する場合、サービスアカウントには、ホストプロジェクトでの | プライベート DNS ゾーンを含むプロジェクトの名前。 |
|
| オプション:既存プライベート DNS ゾーンの ID または名前。この値を設定しない場合、インストールプログラムはサービスプロジェクトにプライベート DNS ゾーンを作成します。 | プライベート DNS ゾーンの名前。 |
|
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストールプログラムは使用する前にソースイメージをコピーする必要があります。 |
|
| インストールプログラムがマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
|
|
デフォルトの | |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用される RHCOS イメージをダウンロードしてインストールします。両方のタイプのマシンで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンとコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
| オプション:コントロールプレーンおよびコンピュートマシンに追加する別のネットワークタグ。 |
|
|
| コントロールプレーンおよびコンピュートマシンの Google Cloud マシンタイプ。 |
Google Cloud マシンタイプ(例: |
|
| マシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| KMS キーが属する Key Management Service (KMS) キーリングの名前。 | KMS キーリング名。 |
|
| KMS キーリングが存在する Google Cloud の場所。 | Google Cloud のロケーション。 |
|
|
KMS キーリングが存在するプロジェクトの ID。この値は、設定されていない場合、デフォルトで | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンおよびコンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| コントロールプレーンマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コントロールプレーンマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コントロールプレーンマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コントロールプレーンマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コントロールプレーンマシンの暗号化要求に使用される Google Cloud サービスアカウント。存在しない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコントロールプレーンマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コントロールプレーンマシンの Google Cloud ディスクタイプ。 |
コントロールプレーンマシンは、デフォルトの |
|
| オプション: デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。コントロールプレーンマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコントロールプレーンマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コントロールプレーンマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コントロールプレーンマシンの |
|
|
|
コントロールプレーン マシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコントロールプレーンマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
|
| コントロールマシンのディスク暗号化に使用されるお客様が管理する暗号化キーの名前。 | 暗号化キー名。 |
|
| コンピュートマシンの場合、KMS キーが属する KMS キーリングの名前。 | KMS キーリング名。 |
|
| コンピュートマシンの場合、キーリングが存在する Google Cloud の場所。KMS の場所の詳細は、Google のドキュメント Cloud KMS locations を参照してください。 | キーリングの Google Cloud の場所。 |
|
| コンピュートマシンの場合、KMS キーリングが存在するプロジェクトの ID。設定されていない場合、この値は VM プロジェクト ID にデフォルト設定されます。 | Google Cloud プロジェクト ID。 |
|
| コンピュートマシンの暗号化要求に使用される Google Cloud サービスアカウント。この値が設定されていない場合には、Compute Engine のデフォルトのサービスアカウントが使用されます。Google Cloud サービスアカウントの詳細は、Google の サービスアカウント に関するドキュメントを参照して ください。 |
Google Cloud サービスアカウントのメール(例:< |
|
| ディスクのサイズ (GB 単位)。この値はコンピュートマシンに適用されます。 | 16 から 65536 までの整数。 |
|
| コンピュートマシンの Google Cloud ディスクタイプ。 |
デフォルトの |
|
| オプション: デフォルトで、インストールプログラムはコンピュートマシンの起動に使用する RHCOS イメージをダウンロードしてインストールします。コンピュートマシンのみで使用するインストールプログラムのカスタム RHCOS イメージの場所を指定することで、デフォルトの動作をオーバーライドできます。 | 文字列。イメージが置かれている Google Cloud プロジェクトの名前。 |
|
|
インストールプログラムがコンピュートマシンの起動に使用するカスタム RHCOS イメージの名前。 | 文字列。RHCOS イメージの名前。 |
|
|
オプション:コンピュートマシンに追加する別のネットワークタグ。このパラメーターを設定すると、コンピュートマシンの |
|
|
|
コンピュートマシンの Google Cloud マシンタイプ。設定されている場合、このパラメーターは |
Google Cloud マシンタイプ(例: |
|
| インストールプログラムがコンピュートマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
10.7.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
10.7.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例10.1 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
10.7.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
インストールプロセスの一環として、カスタムマシンタイプを install-config.yaml ファイルで指定します。
カスタムマシンタイプのサンプル install-config.yaml ファイル
10.7.5. Google Cloud 用にカスタマイズされた install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。
- 1 14 16 17 23
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 8
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 9
controlPlaneセクションは単一マッピングですが、computeセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、computeセクションの最初の行はハイフン-で始め、controlPlaneセクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 10
- 同時マルチスレッドまたは
hyperthreadingを有効/無効にするかどうか。デフォルトでは、同時マルチスレッドはマシンのコアのパフォーマンスを上げるために有効化されます。パラメーター値をDisabledに設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8などの大規模なマシンタイプを使用します。 - 5 11
- オプション: 仮想マシンと永続ボリュームの両方を暗号化するカスタム暗号化キーセクション。デフォルトのコンピュートサービスアカウントには、KMS キーを使用するためのパーミッションが付与され、適切な IAM ロールが割り当てられている必要があります。デフォルトのサービスアカウント名は、
service-<project_number>@compute-system.iam.gserviceaccount.comパターンをベースにしています。サービスアカウントの適切なパーミッションを付与する方法についての詳細は、マシン管理 → コンピュートマシンセットの作成 → Google Cloud でのコンピュートマシンセットの作成を参照してください。 - 6 12 18
- オプション: コントロールプレーンまたはコンピューティングマシンセットに適用するネットワークタグのセット。
platform.gcp.defaultMachinePlatform.tagsパラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。compute.platform.gcp.tagsパラメーターまたはcontrolPlane.platform.gcp.tagsパラメーターが設定されている場合は、platform.gcp.defaultMachinePlatform.tagsパラメーターを上書きします。 - 7 13 19
- オプション: インストールプログラムがコントロールプレーンマシンとコンピュートマシンの起動に使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。
platform.gcp.defaultMachinePlatform.osImageの下のprojectおよびnameパラメーターは、コントロールプレーンマシンとコンピュートマシンの両方に適用されます。controlPlane.platform.gcp.osImageまたはcompute.platform.gcp.osImageの下のprojectおよびnameパラメーターが設定されている場合、それらはplatform.gcp.defaultMachinePlatform.osImageパラメーターをオーバーライドします。 - 15
- インストールするクラスターネットワークプラグイン。サポートされている値は
OVNKubernetesとOpenShiftSDNです。デフォルトの値はOVNkubernetesです。 - 20
- 既存 VPC の名前を指定します。
- 21
- コントロールプレーンマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 22
- コンピュートマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 24
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64、ppc64le、およびs390xアーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 25
- クラスター内のマシンにアクセスするために使用する
sshKey値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。 - 26
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publishをInternalに設定します。これはインターネットからアクセスできません。デフォルト値はExternalです。
10.7.6. Google Cloud でのグローバルアクセスが設定された Ingress コントローラーの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud クラスターへのグローバルアクセスのある Ingress コントローラーを作成できます。グローバルアクセスは、内部ロードバランサーを使用する Ingress コントローラーでのみ利用できます。
前提条件
-
install-config.yamlを作成し、これに対する変更を完了している。
手順
新しい Google Cloud クラスターでのグローバルアクセスのある Ingress コントローラーの作成
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストファイルを作成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、クラスターのinstall-config.yamlファイルが含まれるディレクトリーの名前を指定します。
cluster-ingress-default-ingresscontroller.yamlという名前のファイルを<installation_directory>/manifests/ディレクトリーに作成します。touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、クラスターのmanifests/ディレクトリーが含まれるディレクトリー名を指定します。
ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが
manifests/ディレクトリーに置かれます。ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
cluster-ingress-default-ingresscontroller.yaml
cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow エディターで
cluster-ingress-default-ingresscontroller.yamlファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。サンプル
clientAccess設定をGlobalに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.7.7. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
10.8. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
クラスターに設定した Google Cloud アカウントのサービスアカウントキーを使用せず、以下の場所に保存されている既存の Google Cloud 認証情報を削除します。
-
GOOGLE_CREDENTIALS、GOOGLE_CLOUD_KEYFILE_JSON、またはGCLOUD_KEYFILE_JSON環境変数 -
~/.gcp/osServiceAccount.jsonファイル -
gcloud cliデフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info$ ./openshift-install create cluster --dir <installation_directory> \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Ownerロールをサービスアカウントに割り当てている場合、そのロールを削除し、これをViewerロールに置き換えることができます。 -
Service Account Key Adminロールが含まれている場合は、これを削除することができます。
-
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadminユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.logにも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
10.9. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.10. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.11. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
10.12. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポート にすることができます。
第11章 Deployment Manager テンプレートの使用による Google Cloud のユーザーによってプロビジョニングされるインフラストラクチャーへのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、独自に提供するインフラストラクチャーを使用するクラスターを Google Cloud にインストールできます。
以下に、ユーザーによって提供されるインフラストラクチャーのインストールを実行する手順を要約します。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。
user-provisioned infrastructure のインストール手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。
11.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターがアクセスする必要のある サイトを許可するようにファイアウォールを設定 している(ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。注記プロキシーを設定する場合は、このサイトリストも確認してください。
11.2. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求されるサービング証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
11.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
11.4. Google Cloud プロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud プロジェクトを設定する必要があります。
11.4.1. Google Cloud プロジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。Google Cloud ドキュメントの Creating and Managing Projects を参照してください。
重要インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合は、Google Cloud プロジェクトは Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
11.4.2. Google Cloud での API サービスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。インストールに不要なオプションの API サービスを有効にすることもできます。Google Cloud ドキュメント の サービスの有効化 を 参照してください。
Expand 表11.1 必要な API サービス API サービス コンソールサービス名 Compute Engine API
compute.googleapis.comCloud Resource Manager API
cloudresourcemanager.googleapis.comGoogle DNS API
dns.googleapis.comIAM Service Account Credentials API
iamcredentials.googleapis.comIdentity and Access Management (IAM) API
iam.googleapis.comService Usage API
serviceusage.googleapis.comExpand 表11.2 オプションの API サービス API サービス コンソールサービス名 Cloud Deployment Manager V2 API
deploymentmanager.googleapis.comGoogle Cloud API
cloudapis.googleapis.comService Management API
servicemanagement.googleapis.comGoogle Cloud Storage JSON API
storage-api.googleapis.comCloud Storage
storage-component.googleapis.com
11.4.3. Google Cloud の DNS の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、使用する Google Cloud アカウントに、OpenShift Container Platform クラスターをホストする同じプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、Google Cloud または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法の詳細は、Google ドメイン を参照してください。
Google Cloud プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。Google Cloud ドキュメントの Creating public zones を参照してください。
openshiftcorp.comなどのルートドメインや、clusters.openshiftcorp.comなどのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。Google Cloud ドキュメント の Cloud DNS ネームサーバーの検索 を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。Google Cloud のドキュメントの Migrating to Cloud DNS を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
11.4.4. Google Cloud アカウントの制限 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは多くの Google Cloud コンポーネントを使用しますが、デフォルトの Quotas はデフォルトの OpenShift Container Platform クラスターをインストールする機能には影響しません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
| サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
|---|---|---|---|---|
| サービスアカウント | IAM | グローバル | 6 | 1 |
| ファイアウォールのルール | ネットワーク | グローバル | 11 | 1 |
| 転送ルール | Compute | グローバル | 2 | 0 |
| ヘルスチェック | Compute | グローバル | 2 | 0 |
| イメージ | Compute | グローバル | 1 | 0 |
| ネットワーク | ネットワーク | グローバル | 1 | 0 |
| ルーター | ネットワーク | グローバル | 1 | 0 |
| ルート | ネットワーク | グローバル | 2 | 0 |
| サブネットワーク | Compute | グローバル | 2 | 0 |
| ターゲットプール | ネットワーク | グローバル | 2 | 0 |
インストール時にクォータが十分ではない場合、インストールプログラムは超過したクォータとリージョンの両方を示すエラーを表示します。
実際のクラスターサイズ、計画されるクラスターの拡張、およびアカウントに関連付けられた他のクラスターからの使用法を考慮してください。CPU、静的 IP アドレス、および永続ディスク SSD(ストレージ) のクォータは、ほとんどの場合に不十分になる可能性のあるものです。
以下のリージョンのいずれかにクラスターをデプロイする予定の場合、ストレージクォータの最大値を超え、CPU クォータ制限を超える可能性が高くなります。
-
asia-east2 -
asia-northeast2 -
asia-south1 -
australia-southeast1 -
europe-north1 -
europe-west2 -
europe-west3 -
europe-west6 -
northamerica-northeast1 -
southamerica-east1 -
us-west2
Google Cloud コンソール からリソースクォータを増やすことはできますが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
11.4.5. Google Cloud でのサービスアカウントの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には、Google API のデータにアクセスするために認証および承認を提供する Google Cloud サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。Google Cloud ドキュメント の サービスアカウントの作成 を参照してください。
サービスアカウントに適切な権限を付与します。以下の個別の権限を付与するか、
Ownerロールを割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることは、必要な権限を得る最も簡単な方法ですが、その場合、サービスアカウントはプロジェクトに対して完全な管理権限を持つことになります。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
サービスアカウントキーを JSON 形式で作成するか、サービスアカウントを Google Cloud 仮想マシンにアタッチできます。Google Cloud のドキュメント の サービスアカウントキー の作成 および インスタンスのサービスアカウントの作成および有効化 を参照してください。
クラスターを作成するには、サービスアカウントキーまたはサービスアカウントがアタッチされた仮想マシンが必要です。
注記サービスアカウントがアタッチされた仮想マシンを使用してクラスターを作成する場合は、インストール前に
install-config.yamlファイルでcredentialsMode: Manualを設定する必要があります。
11.4.6. 必須 Google Cloud ロール リンクのコピーリンクがクリップボードにコピーされました!
作成したサービスアカウントに Owner ロールを割り当てると、OpenShift Container Platform のインストールに必要な権限を含め、すべての権限がそのサービスアカウントに付与されます。組織のセキュリティーポリシーでより制限的なアクセス許可セットが必要な場合は、次のアクセス許可を持つサービスアカウントを作成できます。
Cloud Credential Operator を passthrough モードで動作するように設定する場合、粒度の細かいパーミッションではなくロールを使用する必要があります。
クラスターを既存の Virtual Private Cloud (VPC) にデプロイする場合、次のリストに記載されているネットワーク権限は、サービスアカウントに必要ありません。
インストールプログラムに必要なロール
- Compute 管理者
- IAM セキュリティー管理者
- サービスアカウント管理者
- Service Account Key Admin
- Service Account User
- Storage Admin
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
パススルー認証情報モードの使用に必要なロール
- ロードバランサー計算の管理者
- IAM ロールビューアー
ユーザーによってプロビジョニングされる Google Cloud インフラストラクチャーに必要なロール
- Deployment Manager Editor
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
| アカウント | ロール |
|---|---|
| コントロールプレーン |
|
|
| |
|
| |
|
| |
|
| |
| Compute |
|
|
|
11.4.7. ユーザーによってプロビジョニングされるインフラストラクチャーに必要な Google Cloud 権限 リンクのコピーリンクがクリップボードにコピーされました!
作成したサービスアカウントに Owner ロールを割り当てると、OpenShift Container Platform のインストールに必要な権限を含め、すべての権限がそのサービスアカウントに付与されます。
組織のセキュリティーポリシーでより制限的なアクセス許可セットが必要な場合は、必要なアクセス許可を持つ カスタムロール を作成できます。OpenShift Container Platform クラスターを作成および削除するには、user-provisioned infrastructure に以下のパーミッションが必要です。
Cloud Credential Operator を passthrough モードで動作するように設定する場合、粒度の細かいパーミッションではなくロールを使用する必要があります。詳細は、「必須の GCP ロール」セクションの「パススルー認証情報モードを使用するための必要なロール」を参照してください。
例11.1 ネットワークリソースの作成に必要な権限
-
compute.addresses.create -
compute.addresses.createInternal -
compute.addresses.delete -
compute.addresses.get -
compute.addresses.list -
compute.addresses.use -
compute.addresses.useInternal -
compute.firewalls.create -
compute.firewalls.delete -
compute.firewalls.get -
compute.firewalls.list -
compute.forwardingRules.create -
compute.forwardingRules.get -
compute.forwardingRules.list -
compute.forwardingRules.setLabels -
compute.networks.create -
compute.networks.get -
compute.networks.list -
compute.networks.updatePolicy -
compute.routers.create -
compute.routers.get -
compute.routers.list -
compute.routers.update -
compute.routes.list -
compute.subnetworks.create -
compute.subnetworks.get -
compute.subnetworks.list -
compute.subnetworks.use -
compute.subnetworks.useExternalIp
例11.2 ロードバランサーリソースの作成に必要な権限
-
compute.regionBackendServices.create -
compute.regionBackendServices.get -
compute.regionBackendServices.list -
compute.regionBackendServices.update -
compute.regionBackendServices.use -
compute.targetPools.addInstance -
compute.targetPools.create -
compute.targetPools.get -
compute.targetPools.list -
compute.targetPools.removeInstance -
compute.targetPools.use
例11.3 DNS リソースの作成に必要な権限
-
dns.changes.create -
dns.changes.get -
dns.managedZones.create -
dns.managedZones.get -
dns.managedZones.list -
dns.networks.bindPrivateDNSZone -
dns.resourceRecordSets.create -
dns.resourceRecordSets.list -
dns.resourceRecordSets.update
例11.4 サービスアカウントリソースの作成に必要な権限
-
iam.serviceAccountKeys.create -
iam.serviceAccountKeys.delete -
iam.serviceAccountKeys.get -
iam.serviceAccountKeys.list -
iam.serviceAccounts.actAs -
iam.serviceAccounts.create -
iam.serviceAccounts.delete -
iam.serviceAccounts.get -
iam.serviceAccounts.list -
resourcemanager.projects.get -
resourcemanager.projects.getIamPolicy -
resourcemanager.projects.setIamPolicy
例11.5 コンピューティングリソースの作成に必要な権限
-
compute.disks.create -
compute.disks.get -
compute.disks.list -
compute.instanceGroups.create -
compute.instanceGroups.delete -
compute.instanceGroups.get -
compute.instanceGroups.list -
compute.instanceGroups.update -
compute.instanceGroups.use -
compute.instances.create -
compute.instances.delete -
compute.instances.get -
compute.instances.list -
compute.instances.setLabels -
compute.instances.setMetadata -
compute.instances.setServiceAccount -
compute.instances.setTags -
compute.instances.use -
compute.machineTypes.get -
compute.machineTypes.list
例11.6 ストレージリソースの作成に必要
-
storage.buckets.create -
storage.buckets.delete -
storage.buckets.get -
storage.buckets.list -
storage.objects.create -
storage.objects.delete -
storage.objects.get -
storage.objects.list
例11.7 ヘルスチェックリソースを作成するために必要な権限
-
compute.healthChecks.create -
compute.healthChecks.get -
compute.healthChecks.list -
compute.healthChecks.useReadOnly -
compute.httpHealthChecks.create -
compute.httpHealthChecks.get -
compute.httpHealthChecks.list -
compute.httpHealthChecks.useReadOnly
例11.8 Google Cloud ゾーンとリージョン関連情報を取得するために必要な権限
-
compute.globalOperations.get -
compute.regionOperations.get -
compute.regions.list -
compute.zoneOperations.get -
compute.zones.get -
compute.zones.list
例11.9 サービスとクォータを確認するために必要な権限
-
monitoring.timeSeries.list -
serviceusage.quotas.get -
serviceusage.services.list
例11.10 インストールに必要な IAM パーミッション
-
iam.roles.get
例11.11 インストールに必要なイメージ権限
-
compute.images.create -
compute.images.delete -
compute.images.get -
compute.images.list
例11.12 収集ブートストラップを実行するためのオプションの権限
-
compute.instances.getSerialPortOutput
例11.13 ネットワークリソースを削除するために必要な権限
-
compute.addresses.delete -
compute.addresses.deleteInternal -
compute.addresses.list -
compute.firewalls.delete -
compute.firewalls.list -
compute.forwardingRules.delete -
compute.forwardingRules.list -
compute.networks.delete -
compute.networks.list -
compute.networks.updatePolicy -
compute.routers.delete -
compute.routers.list -
compute.routes.list -
compute.subnetworks.delete -
compute.subnetworks.list
例11.14 ロードバランサーリソースを削除するために必要な権限
-
compute.regionBackendServices.delete -
compute.regionBackendServices.list -
compute.targetPools.delete -
compute.targetPools.list
例11.15 DNS リソースを削除するために必要な権限
-
dns.changes.create -
dns.managedZones.delete -
dns.managedZones.get -
dns.managedZones.list -
dns.resourceRecordSets.delete -
dns.resourceRecordSets.list
例11.16 サービスアカウントリソースを削除するために必要な権限
-
iam.serviceAccounts.delete -
iam.serviceAccounts.get -
iam.serviceAccounts.list -
resourcemanager.projects.getIamPolicy -
resourcemanager.projects.setIamPolicy
例11.17 コンピューティングリソースを削除するために必要な権限
-
compute.disks.delete -
compute.disks.list -
compute.instanceGroups.delete -
compute.instanceGroups.list -
compute.instances.delete -
compute.instances.list -
compute.instances.stop -
compute.machineTypes.list
例11.18 ストレージリソースの削除に必要
-
storage.buckets.delete -
storage.buckets.getIamPolicy -
storage.buckets.list -
storage.objects.delete -
storage.objects.list
例11.19 ヘルスチェックリソースを削除するために必要な権限
-
compute.healthChecks.delete -
compute.healthChecks.list -
compute.httpHealthChecks.delete -
compute.httpHealthChecks.list
例11.20 削除に必要なイメージ権限
-
compute.images.delete -
compute.images.list
例11.21 リージョン関連の情報を取得するために必要な権限
-
compute.regions.get
例11.22 必要な Deployment Manager 権限
-
deploymentmanager.deployments.create -
deploymentmanager.deployments.delete -
deploymentmanager.deployments.get -
deploymentmanager.deployments.list -
deploymentmanager.manifests.get -
deploymentmanager.operations.get -
deploymentmanager.resources.list
11.4.8. サポートされている Google Cloud リージョン リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを以下の Google Cloud リージョンにデプロイできます。
-
asia-east1(Changhua County, Taiwan) -
asia-east2(Hong Kong) -
asia-northeast1(Tokyo, Japan) -
asia-northeast2(Osaka, Japan) -
asia-northeast3(Seoul, South Korea) -
asia-south1(Mumbai, India) -
asia-south2(Delhi, India) -
asia-southeast1(Jurong West, Singapore) -
asia-southeast2(Jakarta, Indonesia) -
australia-southeast1(Sydney, Australia) -
australia-southeast2(Melbourne, Australia) -
europe-central2(Warsaw, Poland) -
europe-north1(Hamina, Finland) -
europe-southwest1(Madrid, Spain) -
europe-west1(St. Ghislain, Belgium) -
europe-west2(London, England, UK) -
europe-west3(Frankfurt, Germany) -
europe-west4(Eemshaven, Netherlands) -
europe-west6(Zürich, Switzerland) -
europe-west8(Milan, Italy) -
europe-west9(Paris, France) -
europe-west12(Turin, Italy) -
me-central1(ドーハ、カタール、中東) -
me-west1(Tel Aviv, Israel) -
northamerica-northeast1(Montréal, Québec, Canada) -
northamerica-northeast2(Toronto, Ontario, Canada) -
southamerica-east1(São Paulo, Brazil) -
southamerica-west1(Santiago, Chile) -
us-central1(Council Bluffs, Iowa, USA) -
us-east1(Moncks Corner, South Carolina, USA) -
us-east4(Ashburn, Northern Virginia, USA) -
us-east5(Columbus, Ohio) -
us-south1(Dallas, Texas) -
us-west1(The Dalles, Oregon, USA) -
us-west2(Los Angeles, California, USA) -
us-west3(Salt Lake City, Utah, USA) -
us-west4(Las Vegas, Nevada, USA)
リージョンおよびゾーンごとにどのマシンタイプのインスタンスが使用できるかを確認するには、Google の ドキュメント を参照してください。
11.4.9. Google Cloud の CLI ツールのインストールと設定 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Google Cloud に OpenShift Container Platform をインストールするには、Google Cloud の CLI ツールをインストールし、設定する必要があります。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
- サービスアカウントを作成し、これに必要なパーミッションを付与しています。
手順
$PATHで以下のバイナリーをインストールします。-
gcloud -
gsutil
Google Cloud のドキュメントの Install the latest Cloud SDK version を参照してください。
-
設定したサービスアカウントで、
gcloudツールを使用して認証します。Google Cloud ドキュメント で、サービスアカウントでの認証 を参照してください。
11.5. user-provisioned infrastructure を使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
11.5.1. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
| ホスト | 説明 |
|---|---|
| 1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
| 3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
| 少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 以降から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
11.5.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
11.5.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例11.23 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
11.5.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
11.6. Google Cloud のインストールファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して OpenShift Container Platform を Google Cloud にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var パーティションを設定するオプションもあります。
11.6.1. オプション: 別個の /var パーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のディスクパーティション設定はインストーラー側で行う必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。
OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
-
/var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。 -
/var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。 -
/var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。
/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。
この手順で個別の /var パーティションを作成する手順を実行する場合、このセクションで後に説明されるように、Kubernetes マニフェストおよび Ignition 設定ファイルを再び作成する必要はありません。
手順
OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。
mkdir $HOME/clusterconfig
$ mkdir $HOME/clusterconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-installを実行して、manifestおよびopenshiftのサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。openshift-install create manifests --dir $HOME/clusterconfig
$ openshift-install create manifests --dir $HOME/clusterconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
? SSH Public Key ... INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshift
? SSH Public Key ... INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: インストールプログラムで
clusterconfig/openshiftディレクトリーにマニフェストが作成されたことを確認します。ls $HOME/clusterconfig/openshift/
$ ls $HOME/clusterconfig/openshift/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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 ...
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 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加のパーティションを設定する Butane 設定を作成します。たとえば、
$HOME/clusterconfig/98-var-partition.buファイルに名前を付け、ディスクのデバイス名をworkerシステムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/varディレクトリーを別のパーティションにマウントします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 MiB (メビバイト) の最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、
prjquotaマウントオプションを有効にする必要があります。
注記個別の
/varパーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。Butane config からマニフェストを作成し、
clusterconfig/openshiftディレクトリーに保存します。たとえば、以下のコマンドを実行します。butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-installを再度実行し、manifestおよびopenshiftのサブディレクトリー内のファイルセットから、Ignition 設定を作成します。openshift-install create ignition-configs --dir $HOME/clusterconfig ls $HOME/clusterconfig/
$ openshift-install create ignition-configs --dir $HOME/clusterconfig $ ls $HOME/clusterconfig/ auth bootstrap.ign master.ign metadata.json worker.ignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールするためにインストール手順への入力として使用できます。
11.6.2. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yamlファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- お使いのコンピューター上で Google Cloud アカウント用のサービスアカウントキーを設定していない場合は、Google Cloud からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション: クラスターでコンピュートマシンをプロビジョニングするよう設定する必要がない場合は、
install-config.yamlファイルでcomputeプールのreplicasを0に設定してコンピュートプールを空にします。compute: - hyperthreading: Enabled name: worker platform: {} replicas: 0compute: - hyperthreading: Enabled name: worker platform: {} replicas: 01 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
0に設定します。
-
install-config.yamlファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
11.6.3. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
11.6.4. Kubernetes マニフェストおよび Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yamlインストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、作成したinstall-config.yamlファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。
オプション: クラスターでコンピュートマシンをプロビジョニングする必要がない場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
<installation_directory>/manifests/cluster-scheduler-02-config.ymlKubernetes マニフェストファイルのmastersSchedulableパラメーターがfalseに設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.ymlファイルを開きます。 -
mastersSchedulableパラメーターを見つけ、これがfalseに設定されていることを確認します。 - ファイルを保存し、終了します。
-
オプション: Ingress Operator を DNS レコードを作成するよう設定する必要がない場合は、
<installation_directory>/manifests/cluster-dns-02-config.ymlDNS 設定ファイルからprivateZoneおよびpublicZoneセクションを削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-passwordおよびkubeconfigファイルが./<installation_directory>/authディレクトリーに作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.7. 共通変数のエクスポート リンクのコピーリンクがクリップボードにコピーされました!
11.7.1. インフラストラクチャー名の抽出 リンクのコピーリンクがクリップボードにコピーされました!
Ignition 設定ファイルには、Google Cloud でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な Google Cloud リソースを見つけるためにも使用されます。提供される Deployment Manager テンプレートにはこのインフラストラクチャー名への参照が含まれるため、これを抽出する必要があります。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
- クラスターの Ignition 設定ファイルを生成している。
-
jqパッケージをインストールしている。
手順
Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。
jq -r .infraID <installation_directory>/metadata.json
$ jq -r .infraID <installation_directory>/metadata.json1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
出力例
openshift-vw9j6
openshift-vw9j61 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このコマンドの出力はクラスター名とランダムな文字列です。
11.7.2. Deployment Manager テンプレートの共通変数のエクスポート リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによって提供されるインフラストラクチャーのインストールを Google Cloud で実行するのに役立つ指定の Deployment Manager テンプレートで使用される一般的な変数のセットをエクスポートする必要があります。
特定の Deployment Manager テンプレートには、追加のエクスポートされる変数が必要になる場合があります。これについては、関連する手順で詳しく説明されています。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- クラスターの Ignition 設定ファイルを生成します。
-
jqパッケージをインストールします。
手順
提供される Deployment Manager テンプレートで使用される以下の一般的な変数をエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
11.8. Google Cloud での VPC の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用する VPC を Google Cloud で作成する必要があります。各種の要件を満たすよう VPC をカスタマイズできます。VPC を作成する 1 つの方法として、提供されている Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して Google Cloud インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
手順
-
このトピックの VPC の Deployment Manager テンプレート セクションを確認し、これを
01_vpc.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。 01_vpc.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.8.1. VPC の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例11.24 01_vpc.py Deployment Manager テンプレート
11.9. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
11.9.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
11.9.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
インターネットに接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Red Hat にテレメトリーデータを提供するために、すべてのノードがインターネットにアクセスできる必要があります。
| プロトコル | ポート | 説明 |
|---|---|---|
| ICMP | 該当なし | ネットワーク到達性のテスト |
| TCP |
| メトリクス |
|
|
ホストレベルのサービス。ポート | |
|
| Kubernetes が予約するデフォルトポート | |
|
| openshift-sdn | |
| UDP |
| VXLAN |
|
| Geneve | |
|
|
ポート | |
|
| IPsec IKE パケット | |
|
| IPsec NAT-T パケット | |
|
|
UDP ポート
外部 NTP タイムサーバーが設定されている場合は、UDP ポート | |
| TCP/UDP |
| Kubernetes ノードポート |
| ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| Kubernetes API |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| etcd サーバーおよびピアポート |
11.10. Google Cloud でのロードバランサーの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するロードバランサーを Google Cloud で設定する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して Google Cloud インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの 内部ロードバランサーの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
02_lb_int.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な内部負荷分散オブジェクトを記述しています。 -
また、外部クラスターには、このトピックの 外部ロードバランサーの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
02_lb_ext.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な外部負荷分散オブジェクトを記述しています。 デプロイメントテンプレートが使用する変数をエクスポートします。
クラスターネットワークの場所をエクスポートします。
export CLUSTER_NETWORK=(`gcloud compute networks describe ${INFRA_ID}-network --format json | jq -r .selfLink`)$ export CLUSTER_NETWORK=(`gcloud compute networks describe ${INFRA_ID}-network --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンのサブネットの場所をエクスポートします。
export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)$ export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが使用する 3 つのゾーンをエクスポートします。
export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)$ export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)$ export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)$ export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
02_infra.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター IP アドレスをエクスポートします。
export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)$ export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、クラスターのパブリック IP アドレスもエクスポートします。
export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)$ export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.10.1. 外部ロードバランサーの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な外部ロードバランサーをデプロイすることができます。
例11.25 02_lb_ext.py Deployment Manager テンプレート
11.10.2. 内部ロードバランサーの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な内部ロードバランサーをデプロイすることができます。
例11.26 02_lb_int.py Deployment Manager テンプレート
外部クラスターの作成時に、02_lb_ext.py テンプレートに加えてこのテンプレートが必要になります。
11.11. Google Cloud でのプライベート DNS ゾーンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するプライベート DNS ゾーンを Google Cloud で設定する必要があります。このコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの プライベート DNS の Deployment Manager テンプレート セクションのテンプレートをコピーし、これを
02_dns.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なプライベート DNS オブジェクトを記述しています。 02_dns.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このテンプレートは Deployment Manager の制限により DNS エントリーを作成しないので、手動で作成する必要があります。
内部 DNS エントリーを追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、外部 DNS エントリーも追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.11.1. プライベート DNS の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なプライベート DNS をデプロイすることができます。
例11.27 02_dns.py Deployment Manager テンプレート
11.12. Google Cloud でのファイアウォールルールの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するファイアウォールルールを Google Cloud で作成する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの ファイアウォールの Deployment Manager テンプレート セクションのテンプレートをコピーし、これを
03_firewall.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なセキュリティーグループを記述しています。 03_firewall.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.12.1. ファイアウォールルール用の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なファイアウォールルールをデプロイすることができます。
例11.28 03_firewall.py Deployment Manager テンプレート
11.14. Google Cloud インフラストラクチャーの RHCOS クラスターイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ノードに Google Cloud 用の有効な Red Hat Enterprise Linux CoreOS (RHCOS)イメージを使用する必要があります。
手順
RHCOS イメージミラー ページから RHCOS イメージを取得します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。
ファイル名には、
rhcos-<version>-<arch>-gcp.<arch>.tar.gz形式の OpenShift Container Platform のバージョン番号が含まれます。Google ストレージバケットを作成します。
gsutil mb gs://<bucket_name>
$ gsutil mb gs://<bucket_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージを Google ストレージバケットにアップロードします。
gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>
$ gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow アップロードした RHCOS イメージの場所を変数としてエクスポートします。
export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz
$ export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターイメージを作成します。
gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"$ gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.15. Google Cloud でのブートストラップマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターの初期化中に使用するブートストラップマシンを Google Cloud で作成する必要があります。このマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供されている Deployment Manager テンプレートを使用してブートストラップマシンを作成しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- pyOpenSSL がインストールされていることを確認します。
手順
-
このトピックの ブートストラップマシンの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
04_bootstrap.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なブートストラップマシンを記述しています。 インストールプログラムで必要な Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所をエクスポートします。
export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)$ export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow バケットを作成し、
bootstrap.ignファイルをアップロードします。gsutil mb gs://${INFRA_ID}-bootstrap-ignition$ gsutil mb gs://${INFRA_ID}-bootstrap-ignitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/$ gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignition 設定にアクセスするために使用するブートストラップインスタンスの署名付き URL を作成します。出力から URL を変数としてエクスポートします。
export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`$ export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 04_bootstrap.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 2
regionはクラスターをデプロイするリージョンです (例:us-central1)。- 3
zoneはブートストラップインスタンスをデプロイするゾーンです (例:us-central1-b)。- 4
cluster_networkはクラスターネットワークのselfLinkURL です。- 5
control_subnetは、コントロールサブセットのselfLinkURL です。- 6
imageは RHCOS イメージのselfLinkURL です。- 7
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 8
root_volume_sizeはブートストラップマシンのブートディスクサイズです。- 9
bootstrap_ignは署名付き URL の作成時の URL 出力です。
gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deployment Manager の制限によりテンプレートではロードバランサーのメンバーシップを管理しないため、ブートストラップマシンは手動で追加する必要があります。
ブートストラップインスタンスを内部ロードバランサーのインスタンスグループに追加します。
gcloud compute instance-groups unmanaged add-instances \ ${INFRA_ID}-bootstrap-ig --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrap$ gcloud compute instance-groups unmanaged add-instances \ ${INFRA_ID}-bootstrap-ig --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrapCopy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップインスタンスグループを内部ロードバランサーのバックエンドサービスに追加します。
gcloud compute backend-services add-backend \ ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services add-backend \ ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.15.1. ブートストラップマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイすることができます。
例11.30 04_bootstrap.py Deployment Manager テンプレート
11.16. Google Cloud でのコントロールプレーンマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで使用するコントロールプレーンマシンを Google Cloud で作成する必要があります。これらのマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用してコントロールプレーンマシンを使用しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
手順
-
このトピックの コントロールプレーンマシンの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
05_control_plane.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンを記述しています。 リソース定義で必要な以下の変数をエクスポートします。
export MASTER_IGNITION=`cat <installation_directory>/master.ign`
$ export MASTER_IGNITION=`cat <installation_directory>/master.ign`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 05_control_plane.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 2
zonesは、コントロールプレーンインスタンスをデプロイするゾーンです (例:us-central1-a、us-central1-b、およびus-central1-c)。- 3
control_subnetは、コントロールサブセットのselfLinkURL です。- 4
imageは RHCOS イメージのselfLinkURL です。- 5
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 6
service_account_emailは作成したマスターサービスアカウントのメールアドレスです。- 7
ignitionはmaster.ignファイルの内容です。
gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deployment Manager の制限により、テンプレートではロードバランサーのメンバーシップを管理しないため、コントロールプレーンマシンを手動で追加する必要があります。
以下のコマンドを実行してコントロールプレーンマシンを適切なインスタンスグループに追加します。
gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-ig --zone=${ZONE_0} --instances=${INFRA_ID}-master-0$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-ig --zone=${ZONE_0} --instances=${INFRA_ID}-master-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-ig --zone=${ZONE_1} --instances=${INFRA_ID}-master-1$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-ig --zone=${ZONE_1} --instances=${INFRA_ID}-master-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-ig --zone=${ZONE_2} --instances=${INFRA_ID}-master-2$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-ig --zone=${ZONE_2} --instances=${INFRA_ID}-master-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、以下のコマンドを実行してコントロールプレーンマシンをターゲットプールに追加する必要もあります。
gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.16.1. コントロールプレーンマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。
例11.31 05_control_plane.py Deployment Manager テンプレート
11.17. Google Cloud でのブートストラップリソースの削除 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud で必要なインフラストラクチャーをすべて作成したら、Ignition 設定ファイルを使用してプロビジョニングしたマシンでブートストラッププロセスが完了するまで待機します。この Ignition 設定ファイルは、インストールプログラムによって作成されたものです。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンが作成されている。
手順
インストールプログラムが含まれているディレクトリーに移動し、次のコマンドを実行します。
./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ --log-level info$ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \1 --log-level info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドが
FATAL警告を出さずに終了する場合、実稼働用のコントロールプレーンは初期化されています。バックエンドサービスのバックエンドからブートストラップインスタンスグループを削除するには、次のコマンドを実行します。
gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ingress_backendservice=$(gcloud compute backend-services list --filter="backends.group~${INFRA_ID}" --format='value(name)' | grep -v "${INFRA_ID}")$ ingress_backendservice=$(gcloud compute backend-services list --filter="backends.group~${INFRA_ID}" --format='value(name)' | grep -v "${INFRA_ID}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow ingress_backendserviceが空でない場合は、ブートストラップグループに対して次のdescribeコマンドを実行します。gcloud compute backend-services describe ${ingress_backendservice} --region=${REGION}$ gcloud compute backend-services describe ${ingress_backendservice} --region=${REGION}Copy to Clipboard Copied! Toggle word wrap Toggle overflow describeコマンドで、ブートストラップグループがバックエンドの 1 つであることが表示された場合は、次のremove-backendコマンドを実行して、バックエンドからブートストラップグループを削除します。gcloud compute backend-services remove-backend ${ingress_backendservice} --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services remove-backend ${ingress_backendservice} --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow バケットとデプロイメントを削除するには、次のコマンドを実行します。
gsutil rb gs://${INFRA_ID}-bootstrap-ignition$ gsutil rb gs://${INFRA_ID}-bootstrap-ignitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrap$ gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrapCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.18. Google Cloud での追加のワーカーマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud でクラスターが使用するワーカーマシンを作成するには、それぞれのインスタンスを個別に起動するか、自動スケーリンググループなどのクラスター外にある自動プロセスを実行します。OpenShift Container Platform の組み込まれたクラスタースケーリングメカニズムやマシン API を利用できます。
この例では、Deployment Manager テンプレートを使用して 1 つのインスタンスを手動で起動します。追加のインスタンスは、ファイル内に 06_worker.py というタイプのリソースを追加して起動することができます。
ワーカーマシンを使用するために提供される Deployment Manager テンプレートを使用しない場合は、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンが作成されている。
手順
-
このトピックの ワーカーマシンの Deployment Manager テンプレート からテンプレートをコピーし、これを
06_worker.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なワーカーマシンを記述しています。 リソース定義が使用する変数をエクスポートします。
コンピュートマシンをホストするサブネットをエクスポートします。
export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)$ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントのメールアドレスをエクスポートします。
export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)$ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートマシンの Ignition 設定ファイルの場所をエクスポートします。
export WORKER_IGNITION=`cat <installation_directory>/worker.ign`
$ export WORKER_IGNITION=`cat <installation_directory>/worker.ign`Copy to Clipboard Copied! Toggle word wrap Toggle overflow
06_worker.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
nameはワーカーマシンの名前です (例:worker-0)。- 2 9
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 3 10
zoneはワーカーマシンをデプロイするゾーンです (例:us-central1-a)。- 4 11
compute_subnetはコンピュートサブネットのselfLinkURL です。- 5 12
imageは RHCOS イメージのselfLinkURL です。1- 6 13
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 7 14
service_account_emailは作成したワーカーサービスアカウントのメールアドレスです。- 8 15
ignitionはworker.ignファイルの内容です。
-
オプション: 追加のインスタンスを起動する必要がある場合には、
06_worker.pyタイプの追加のリソースを06_worker.yamlリソース定義ファイルに組み込みます。 gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Google Cloud Marketplace イメージを使用するには、使用するオファーを指定します。
-
OpenShift Container Platform:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145 -
OpenShift Platform Plus:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145 -
OpenShift Kubernetes Engine:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145
-
OpenShift Container Platform:
11.18.1. ワーカーマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。
例11.32 06_worker.py Deployment Manager テンプレート
11.19. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.20. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.21. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
PendingまたはApprovedステータスが表示されていることを確認します。oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pendingステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approverによって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec、oc rsh、およびoc logsコマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:nodeまたはsystem:adminグループのnode-bootstrapperサービスアカウントによって提出されていることを確認し、ノードの ID を確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りの CSR が承認されず、それらが
Pendingステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Readyになります。以下のコマンドを実行して、これを確認します。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記サーバー CSR の承認後にマシンが
Readyステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
11.22. オプション: Ingress DNS レコードの追加 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除した場合、Ingress ロードバランサーをポイントする DNS レコードを手動で作成する必要があります。ワイルドカード *.apps.{baseDomain}. または特定のレコードのいずれかを作成できます。要件に基づいて A、CNAME その他のレコードを使用できます。
前提条件
- GCP アカウントを設定します。
- Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
- ワーカーマシンを作成します。
手順
Ingress ルーターがロードバランサーを作成し、
EXTERNAL-IPフィールドにデータを設定するのを待機します。oc -n openshift-ingress get service router-default
$ oc -n openshift-ingress get service router-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.30.18.154 35.233.157.184 80:32288/TCP,443:31215/TCP 98
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.30.18.154 35.233.157.184 80:32288/TCP,443:31215/TCP 98Copy to Clipboard Copied! Toggle word wrap Toggle overflow A レコードをゾーンに追加します。
A レコードを使用するには、以下を実行します。
ルーター IP アドレスの変数をエクスポートします。
export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`$ export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow A レコードをプライベートゾーンに追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow また、外部クラスターの場合は、A レコードをパブリックゾーンに追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ワイルドカードを使用する代わりに明示的なドメインを追加するには、クラスターのそれぞれの現行ルートのエントリーを作成します。
oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes$ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
oauth-openshift.apps.your.cluster.domain.example.com console-openshift-console.apps.your.cluster.domain.example.com downloads-openshift-console.apps.your.cluster.domain.example.com alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.com
oauth-openshift.apps.your.cluster.domain.example.com console-openshift-console.apps.your.cluster.domain.example.com downloads-openshift-console.apps.your.cluster.domain.example.com alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.23. ユーザーによってプロビジョニングされるインフラストラクチャーでの Google Cloud インストールの実行 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud のユーザーによってプロビジョニングされるインフラストラクチャーで OpenShift Container Platform のインストールを開始した後は、クラスターが準備状態になるまでクラスターのイベントをモニターできます。
前提条件
- OpenShift Container Platform クラスターのブートストラップマシンを、user-provisioned GCP インフラストラクチャーにデプロイします。
-
ocCLI をインストールし、ログインします。
手順
クラスターのインストールを完了します。
./openshift-install --dir <installation_directory> wait-for install-complete
$ ./openshift-install --dir <installation_directory> wait-for install-complete1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Waiting up to 30m0s for the cluster to initialize...
INFO Waiting up to 30m0s for the cluster to initialize...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
クラスターの稼働状態を確認します。
以下のコマンドを実行し、現在のクラスターバージョンとステータスを表示します。
oc get clusterversion
$ oc get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% complete
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% completeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行し、Cluster Version Operator (CVO) を使用してコントロールプレーンで管理される Operator を表示します。
oc get clusteroperators
$ oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、クラスター Pod を表示します。
oc get pods --all-namespaces
$ oc get pods --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
現在のクラスターバージョンが
AVAILABLEの場合、インストールが完了します。
11.24. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
11.25. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
第12章 Deployment Manager テンプレートを使用した Google Cloud の共有 VPC へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、独自に提供するインフラストラクチャーを使用する Google Cloud 上の共有 Virtual Private Cloud (VPC)にクラスターをインストールできます。この場合、共有 VPC にインストールされたクラスターは、クラスターがデプロイされる場所とは異なるプロジェクトから VPC を使用するように設定されるクラスターです。
共有 VPC により、組織は複数のプロジェクトから共通の VPC ネットワークにリソースを接続できるようになります。対象のネットワークの内部 IP を使用して、組織内の通信をセキュアかつ効率的に実行できます。共有 VPC の詳細は、Google Cloud ドキュメントの 共有 VPC の概要 を参照してください。
以下に、ユーザーによって提供されるインフラストラクチャーの共有 VPC へのインストールを実行する手順を要約します。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。
user-provisioned infrastructure のインストール手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。
12.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- クラスターがアクセスする必要のある サイトを許可するようにファイアウォールを設定 している(ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。注記プロキシーを設定する場合は、このサイトリストも確認してください。
12.2. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager は kubelet クライアント CSR のみを承認します。machine-approver は、kubelet 認証情報を使用して要求されるサービング証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
12.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
12.4. クラスターをホストする Google Cloud プロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud Platform (Google Cloud)プロジェクトを設定する必要があります。
12.4.1. Google Cloud プロジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。Google Cloud ドキュメントの Creating and Managing Projects を参照してください。
重要インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合は、Google Cloud プロジェクトは Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
12.4.2. Google Cloud での API サービスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。インストールに不要なオプションの API サービスを有効にすることもできます。Google Cloud ドキュメント の サービスの有効化 を 参照してください。
Expand 表12.1 必要な API サービス API サービス コンソールサービス名 Compute Engine API
compute.googleapis.comCloud Resource Manager API
cloudresourcemanager.googleapis.comGoogle DNS API
dns.googleapis.comIAM Service Account Credentials API
iamcredentials.googleapis.comIdentity and Access Management (IAM) API
iam.googleapis.comService Usage API
serviceusage.googleapis.comExpand 表12.2 オプションの API サービス API サービス コンソールサービス名 Cloud Deployment Manager V2 API
deploymentmanager.googleapis.comGoogle Cloud API
cloudapis.googleapis.comService Management API
servicemanagement.googleapis.comGoogle Cloud Storage JSON API
storage-api.googleapis.comCloud Storage
storage-component.googleapis.com
12.4.3. Google Cloud アカウントの制限 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは多くの Google Cloud コンポーネントを使用しますが、デフォルトの Quotas はデフォルトの OpenShift Container Platform クラスターをインストールする機能には影響しません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
| サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
|---|---|---|---|---|
| サービスアカウント | IAM | グローバル | 6 | 1 |
| ファイアウォールのルール | ネットワーク | グローバル | 11 | 1 |
| 転送ルール | Compute | グローバル | 2 | 0 |
| ヘルスチェック | Compute | グローバル | 2 | 0 |
| イメージ | Compute | グローバル | 1 | 0 |
| ネットワーク | ネットワーク | グローバル | 1 | 0 |
| ルーター | ネットワーク | グローバル | 1 | 0 |
| ルート | ネットワーク | グローバル | 2 | 0 |
| サブネットワーク | Compute | グローバル | 2 | 0 |
| ターゲットプール | ネットワーク | グローバル | 2 | 0 |
インストール時にクォータが十分ではない場合、インストールプログラムは超過したクォータとリージョンの両方を示すエラーを表示します。
実際のクラスターサイズ、計画されるクラスターの拡張、およびアカウントに関連付けられた他のクラスターからの使用法を考慮してください。CPU、静的 IP アドレス、および永続ディスク SSD(ストレージ) のクォータは、ほとんどの場合に不十分になる可能性のあるものです。
以下のリージョンのいずれかにクラスターをデプロイする予定の場合、ストレージクォータの最大値を超え、CPU クォータ制限を超える可能性が高くなります。
-
asia-east2 -
asia-northeast2 -
asia-south1 -
australia-southeast1 -
europe-north1 -
europe-west2 -
europe-west3 -
europe-west6 -
northamerica-northeast1 -
southamerica-east1 -
us-west2
Google Cloud コンソール からリソースクォータを増やすことはできますが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
12.4.4. Google Cloud でのサービスアカウントの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には、Google API のデータにアクセスするために認証および承認を提供する Google Cloud サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。Google Cloud ドキュメント の サービスアカウントの作成 を参照してください。
サービスアカウントに適切な権限を付与します。以下の個別の権限を付与するか、
Ownerロールを割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることは、必要な権限を得る最も簡単な方法ですが、その場合、サービスアカウントはプロジェクトに対して完全な管理権限を持つことになります。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
サービスアカウントキーを JSON 形式で作成するか、サービスアカウントを Google Cloud 仮想マシンにアタッチできます。Google Cloud のドキュメント の サービスアカウントキー の作成 および インスタンスのサービスアカウントの作成および有効化 を参照してください。
クラスターを作成するには、サービスアカウントキーまたはサービスアカウントがアタッチされた仮想マシンが必要です。
注記サービスアカウントがアタッチされた仮想マシンを使用してクラスターを作成する場合は、インストール前に
install-config.yamlファイルでcredentialsMode: Manualを設定する必要があります。
12.4.4.1. 必須 Google Cloud ロール リンクのコピーリンクがクリップボードにコピーされました!
作成したサービスアカウントに Owner ロールを割り当てると、OpenShift Container Platform のインストールに必要な権限を含め、すべての権限がそのサービスアカウントに付与されます。組織のセキュリティーポリシーでより制限的なアクセス許可セットが必要な場合は、次のアクセス許可を持つサービスアカウントを作成できます。
Cloud Credential Operator を passthrough モードで動作するように設定する場合、粒度の細かいパーミッションではなくロールを使用する必要があります。
クラスターを既存の Virtual Private Cloud (VPC) にデプロイする場合、次のリストに記載されているネットワーク権限は、サービスアカウントに必要ありません。
インストールプログラムに必要なロール
- Compute 管理者
- IAM セキュリティー管理者
- サービスアカウント管理者
- Service Account Key Admin
- Service Account User
- Storage Admin
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
パススルー認証情報モードの使用に必要なロール
- ロードバランサー計算の管理者
- IAM ロールビューアー
ユーザーによってプロビジョニングされる Google Cloud インフラストラクチャーに必要なロール
- Deployment Manager Editor
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
| アカウント | ロール |
|---|---|
| コントロールプレーン |
|
|
| |
|
| |
|
| |
|
| |
| Compute |
|
|
|
12.4.5. サポートされている Google Cloud リージョン リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを以下の Google Cloud リージョンにデプロイできます。
-
asia-east1(Changhua County, Taiwan) -
asia-east2(Hong Kong) -
asia-northeast1(Tokyo, Japan) -
asia-northeast2(Osaka, Japan) -
asia-northeast3(Seoul, South Korea) -
asia-south1(Mumbai, India) -
asia-south2(Delhi, India) -
asia-southeast1(Jurong West, Singapore) -
asia-southeast2(Jakarta, Indonesia) -
australia-southeast1(Sydney, Australia) -
australia-southeast2(Melbourne, Australia) -
europe-central2(Warsaw, Poland) -
europe-north1(Hamina, Finland) -
europe-southwest1(Madrid, Spain) -
europe-west1(St. Ghislain, Belgium) -
europe-west2(London, England, UK) -
europe-west3(Frankfurt, Germany) -
europe-west4(Eemshaven, Netherlands) -
europe-west6(Zürich, Switzerland) -
europe-west8(Milan, Italy) -
europe-west9(Paris, France) -
europe-west12(Turin, Italy) -
me-central1(ドーハ、カタール、中東) -
me-west1(Tel Aviv, Israel) -
northamerica-northeast1(Montréal, Québec, Canada) -
northamerica-northeast2(Toronto, Ontario, Canada) -
southamerica-east1(São Paulo, Brazil) -
southamerica-west1(Santiago, Chile) -
us-central1(Council Bluffs, Iowa, USA) -
us-east1(Moncks Corner, South Carolina, USA) -
us-east4(Ashburn, Northern Virginia, USA) -
us-east5(Columbus, Ohio) -
us-south1(Dallas, Texas) -
us-west1(The Dalles, Oregon, USA) -
us-west2(Los Angeles, California, USA) -
us-west3(Salt Lake City, Utah, USA) -
us-west4(Las Vegas, Nevada, USA)
リージョンおよびゾーンごとにどのマシンタイプのインスタンスが使用できるかを確認するには、Google の ドキュメント を参照してください。
12.4.6. Google Cloud の CLI ツールのインストールと設定 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Google Cloud に OpenShift Container Platform をインストールするには、Google Cloud の CLI ツールをインストールし、設定する必要があります。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
- サービスアカウントを作成し、これに必要なパーミッションを付与しています。
手順
$PATHで以下のバイナリーをインストールします。-
gcloud -
gsutil
Google Cloud のドキュメントの Install the latest Cloud SDK version を参照してください。
-
設定したサービスアカウントで、
gcloudツールを使用して認証します。Google Cloud ドキュメント で、サービスアカウントでの認証 を参照してください。
12.5. user-provisioned infrastructure を使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
12.5.1. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
| ホスト | 説明 |
|---|---|
| 1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
| 3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
| 少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 以降から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
12.5.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
12.5.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例12.1 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
12.5.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
12.6. 共有 VPC ネットワークをホストする Google Cloud プロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
共有 Virtual Private Cloud (VPC)を使用して Google Cloud で OpenShift Container Platform クラスターをホストする場合、それをホストするプロジェクトを設定する必要があります。
共有 VPC ネットワークをホストするプロジェクトがすでにある場合は、このセクションを参照して、プロジェクトが OpenShift Container Platform クラスターのインストールに必要なすべての要件を満たすことを確認します。
手順
- OpenShift Container Platform クラスターの共有 VPC をホストするプロジェクトを作成します。Google Cloud ドキュメントの Creating and Managing Projects を参照してください。
- 共有 VPC をホストするプロジェクトでサービスアカウントを作成します。Google Cloud ドキュメント の サービスアカウントの作成 を参照してください。
サービスアカウントに適切な権限を付与します。以下の個別の権限を付与するか、
Ownerロールを割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることは、必要な権限を得る最も簡単な方法ですが、その場合、サービスアカウントはプロジェクトに対して完全な管理権限を持つことになります。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
共有 VPC ネットワークをホストするプロジェクトのサービスアカウントには以下のロールが必要です。
- コンピュートネットワークユーザー
- コンピュートセキュリティー管理者
- Deployment Manager Editor
- DNS Administrator
- Security Admin
- ネットワーク管理者
12.6.1. Google Cloud の DNS の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、使用する Google Cloud アカウントに、クラスターをインストールする共有 VPC をホストするプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、Google Cloud または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法の詳細は、Google ドメイン を参照してください。
Google Cloud プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。Google Cloud ドキュメントの Creating public zones を参照してください。
openshiftcorp.comなどのルートドメインや、clusters.openshiftcorp.comなどのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。Google Cloud ドキュメント の Cloud DNS ネームサーバーの検索 を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。Google Cloud のドキュメントの Migrating to Cloud DNS を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
12.6.2. Google Cloud での VPC の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用する VPC を Google Cloud で作成する必要があります。各種の要件を満たすよう VPC をカスタマイズできます。VPC を作成する 1 つの方法として、提供されている Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して Google Cloud インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
手順
-
このトピックの VPC の Deployment Manager テンプレート セクションを確認し、これを
01_vpc.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。 リソース定義で必要な以下の変数をエクスポートします。
コントロールプレーンの CIDR をエクスポートします。
export MASTER_SUBNET_CIDR='10.0.0.0/17'
$ export MASTER_SUBNET_CIDR='10.0.0.0/17'Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュート CIDR をエクスポートします。
export WORKER_SUBNET_CIDR='10.0.128.0/17'
$ export WORKER_SUBNET_CIDR='10.0.128.0/17'Copy to Clipboard Copied! Toggle word wrap Toggle overflow VPC ネットワークおよびクラスターをデプロイするリージョンを以下にエクスポートします。
export REGION='<region>'
$ export REGION='<region>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
共有 VPC をホストするプロジェクトの ID の変数をエクスポートします。
export HOST_PROJECT=<host_project>
$ export HOST_PROJECT=<host_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストプロジェクトに属するサービスアカウントのメールの変数をエクスポートします。
export HOST_PROJECT_ACCOUNT=<host_service_account_email>
$ export HOST_PROJECT_ACCOUNT=<host_service_account_email>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 01_vpc.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create <vpc_deployment_name> --config 01_vpc.yaml --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}$ gcloud deployment-manager deployments create <vpc_deployment_name> --config 01_vpc.yaml --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<vpc_deployment_name>には、デプロイする VPC の名前を指定します。
他のコンポーネントが必要とする VPC 変数をエクスポートします。
ホストプロジェクトネットワークの名前をエクスポートします。
export HOST_PROJECT_NETWORK=<vpc_network>
$ export HOST_PROJECT_NETWORK=<vpc_network>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストプロジェクトのコントロールプレーンのサブネットの名前をエクスポートします。
export HOST_PROJECT_CONTROL_SUBNET=<control_plane_subnet>
$ export HOST_PROJECT_CONTROL_SUBNET=<control_plane_subnet>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストプロジェクトのコンピュートサブネットの名前をエクスポートします。
export HOST_PROJECT_COMPUTE_SUBNET=<compute_subnet>
$ export HOST_PROJECT_COMPUTE_SUBNET=<compute_subnet>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 共有 VPC を設定します。Google Cloud ドキュメント の 共有 VPC の設定 を参照してください。
12.6.2.1. VPC の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例12.2 01_vpc.py Deployment Manager テンプレート
12.7. Google Cloud のインストールファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して OpenShift Container Platform を Google Cloud にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var パーティションを設定するオプションもあります。
12.7.1. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
mkdir <installation_directory>
$ mkdir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの
install-config.yamlファイルテンプレートをカスタマイズし、ファイルを<installation_directory>に保存します。注記この設定ファイルの名前を
install-config.yamlと付ける必要があります。多くのクラスターのインストールに使用できるように、
install-config.yamlファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yamlファイルを使用するため、今すぐこのファイルをバックアップしてください。
12.7.3. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
12.7.4. Kubernetes マニフェストおよび Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yamlインストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、作成したinstall-config.yamlファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。
ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
<installation_directory>/manifests/cluster-scheduler-02-config.ymlKubernetes マニフェストファイルのmastersSchedulableパラメーターがfalseに設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.ymlファイルを開きます。 -
mastersSchedulableパラメーターを見つけ、これがfalseに設定されていることを確認します。 - ファイルを保存し、終了します。
-
<installation_directory>/manifests/cluster-dns-02-config.ymlDNS 設定ファイルからprivateZoneセクションを削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このセクションを完全に削除します。
VPC のクラウドプロバイダーを設定します。
-
<installation_directory>/manifests/cloud-provider-config.yamlファイルを開きます。 -
network-project-idパラメーターを追加し、その値を共有 VPC ネットワークをホストするプロジェクトの ID に設定します。 -
network-nameパラメーターを追加し、その値を OpenShift Container Platform クラスターをホストする共有 VPC ネットワークの名前に設定します。 -
subnetwork-nameパラメーターの値を、コンピュートマシンをホストする共有 VPC サブネットの値に置き換えます。
<installation_directory>/manifests/cloud-provider-config.yamlの内容は以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
プライベートネットワーク上にないクラスターをデプロイする場合は、
<installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yamlファイルを開き、scopeパラメーターの値をExternalに置き換えます。ファイルの内容は以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-passwordおよびkubeconfigファイルが./<installation_directory>/authディレクトリーに作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8. 共通変数のエクスポート リンクのコピーリンクがクリップボードにコピーされました!
12.8.1. インフラストラクチャー名の抽出 リンクのコピーリンクがクリップボードにコピーされました!
Ignition 設定ファイルには、Google Cloud でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な Google Cloud リソースを見つけるためにも使用されます。提供される Deployment Manager テンプレートにはこのインフラストラクチャー名への参照が含まれるため、これを抽出する必要があります。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
- クラスターの Ignition 設定ファイルを生成している。
-
jqパッケージをインストールしている。
手順
Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。
jq -r .infraID <installation_directory>/metadata.json
$ jq -r .infraID <installation_directory>/metadata.json1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
出力例
openshift-vw9j6
openshift-vw9j61 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このコマンドの出力はクラスター名とランダムな文字列です。
12.8.2. Deployment Manager テンプレートの共通変数のエクスポート リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによって提供されるインフラストラクチャーのインストールを Google Cloud で実行するのに役立つ指定の Deployment Manager テンプレートで使用される一般的な変数のセットをエクスポートする必要があります。
特定の Deployment Manager テンプレートには、追加のエクスポートされる変数が必要になる場合があります。これについては、関連する手順で詳しく説明されています。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- クラスターの Ignition 設定ファイルを生成します。
-
jqパッケージをインストールします。
手順
- 提供される Deployment Manager テンプレートで使用される以下の一般的な変数をエクスポートします。
12.9. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
12.9.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
12.9.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
インターネットに接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Red Hat にテレメトリーデータを提供するために、すべてのノードがインターネットにアクセスできる必要があります。
| プロトコル | ポート | 説明 |
|---|---|---|
| ICMP | 該当なし | ネットワーク到達性のテスト |
| TCP |
| メトリクス |
|
|
ホストレベルのサービス。ポート | |
|
| Kubernetes が予約するデフォルトポート | |
|
| openshift-sdn | |
| UDP |
| VXLAN |
|
| Geneve | |
|
|
ポート | |
|
| IPsec IKE パケット | |
|
| IPsec NAT-T パケット | |
|
|
UDP ポート
外部 NTP タイムサーバーが設定されている場合は、UDP ポート | |
| TCP/UDP |
| Kubernetes ノードポート |
| ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| Kubernetes API |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| etcd サーバーおよびピアポート |
12.10. Google Cloud でのロードバランサーの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するロードバランサーを Google Cloud で設定する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して Google Cloud インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの 内部ロードバランサーの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
02_lb_int.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な内部負荷分散オブジェクトを記述しています。 -
また、外部クラスターには、このトピックの 外部ロードバランサーの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
02_lb_ext.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な外部負荷分散オブジェクトを記述しています。 デプロイメントテンプレートが使用する変数をエクスポートします。
クラスターネットワークの場所をエクスポートします。
export CLUSTER_NETWORK=(`gcloud compute networks describe ${HOST_PROJECT_NETWORK} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} --format json | jq -r .selfLink`)$ export CLUSTER_NETWORK=(`gcloud compute networks describe ${HOST_PROJECT_NETWORK} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンのサブネットの場所をエクスポートします。
export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${HOST_PROJECT_CONTROL_SUBNET} --region=${REGION} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} --format json | jq -r .selfLink`)$ export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${HOST_PROJECT_CONTROL_SUBNET} --region=${REGION} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが使用する 3 つのゾーンをエクスポートします。
export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)$ export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)$ export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)$ export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
02_infra.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター IP アドレスをエクスポートします。
export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)$ export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、クラスターのパブリック IP アドレスもエクスポートします。
export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)$ export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.10.1. 外部ロードバランサーの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な外部ロードバランサーをデプロイすることができます。
例12.3 02_lb_ext.py Deployment Manager テンプレート
12.10.2. 内部ロードバランサーの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な内部ロードバランサーをデプロイすることができます。
例12.4 02_lb_int.py Deployment Manager テンプレート
外部クラスターの作成時に、02_lb_ext.py テンプレートに加えてこのテンプレートが必要になります。
12.11. Google Cloud でのプライベート DNS ゾーンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するプライベート DNS ゾーンを Google Cloud で設定する必要があります。このコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの プライベート DNS の Deployment Manager テンプレート セクションのテンプレートをコピーし、これを
02_dns.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なプライベート DNS オブジェクトを記述しています。 02_dns.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}$ gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}Copy to Clipboard Copied! Toggle word wrap Toggle overflow このテンプレートは Deployment Manager の制限により DNS エントリーを作成しないので、手動で作成する必要があります。
内部 DNS エントリーを追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、外部 DNS エントリーも追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud --account=${HOST_PROJECT_ACCOUNT} --project=${HOST_PROJECT} dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} gcloud --account=${HOST_PROJECT_ACCOUNT} --project=${HOST_PROJECT} dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME} gcloud --account=${HOST_PROJECT_ACCOUNT} --project=${HOST_PROJECT} dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud --account=${HOST_PROJECT_ACCOUNT} --project=${HOST_PROJECT} dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud --account=${HOST_PROJECT_ACCOUNT} --project=${HOST_PROJECT} dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud --account=${HOST_PROJECT_ACCOUNT} --project=${HOST_PROJECT} dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.11.1. プライベート DNS の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なプライベート DNS をデプロイすることができます。
例12.5 02_dns.py Deployment Manager テンプレート
12.12. Google Cloud でのファイアウォールルールの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するファイアウォールルールを Google Cloud で作成する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの ファイアウォールの Deployment Manager テンプレート セクションのテンプレートをコピーし、これを
03_firewall.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なセキュリティーグループを記述しています。 03_firewall.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}$ gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.12.1. ファイアウォールルール用の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なファイアウォールルールをデプロイすることができます。
例12.6 03_firewall.py Deployment Manager テンプレート
12.14. Google Cloud インフラストラクチャーの RHCOS クラスターイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ノードに Google Cloud 用の有効な Red Hat Enterprise Linux CoreOS (RHCOS)イメージを使用する必要があります。
手順
RHCOS イメージミラー ページから RHCOS イメージを取得します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。
ファイル名には、
rhcos-<version>-<arch>-gcp.<arch>.tar.gz形式の OpenShift Container Platform のバージョン番号が含まれます。Google ストレージバケットを作成します。
gsutil mb gs://<bucket_name>
$ gsutil mb gs://<bucket_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージを Google ストレージバケットにアップロードします。
gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>
$ gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow アップロードした RHCOS イメージの場所を変数としてエクスポートします。
export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz
$ export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターイメージを作成します。
gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"$ gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.15. Google Cloud でのブートストラップマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターの初期化中に使用するブートストラップマシンを Google Cloud で作成する必要があります。このマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供されている Deployment Manager テンプレートを使用してブートストラップマシンを作成しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- pyOpenSSL がインストールされていることを確認します。
手順
-
このトピックの ブートストラップマシンの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
04_bootstrap.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なブートストラップマシンを記述しています。 インストールプログラムで必要な Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所をエクスポートします。
export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)$ export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow バケットを作成し、
bootstrap.ignファイルをアップロードします。gsutil mb gs://${INFRA_ID}-bootstrap-ignition$ gsutil mb gs://${INFRA_ID}-bootstrap-ignitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/$ gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignition 設定にアクセスするために使用するブートストラップインスタンスの署名付き URL を作成します。出力から URL を変数としてエクスポートします。
export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`$ export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 04_bootstrap.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 2
regionはクラスターをデプロイするリージョンです (例:us-central1)。- 3
zoneはブートストラップインスタンスをデプロイするゾーンです (例:us-central1-b)。- 4
cluster_networkはクラスターネットワークのselfLinkURL です。- 5
control_subnetは、コントロールサブセットのselfLinkURL です。- 6
imageは RHCOS イメージのselfLinkURL です。- 7
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 8
root_volume_sizeはブートストラップマシンのブートディスクサイズです。- 9
bootstrap_ignは署名付き URL の作成時の URL 出力です。
gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップインスタンスを内部ロードバランサーのインスタンスグループに追加します。
gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-bootstrap-ig --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrap$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-bootstrap-ig --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrapCopy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップインスタンスグループを内部ロードバランサーのバックエンドサービスに追加します。
gcloud compute backend-services add-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services add-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.15.1. ブートストラップマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイすることができます。
例12.8 04_bootstrap.py Deployment Manager テンプレート
12.16. Google Cloud でのコントロールプレーンマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで使用するコントロールプレーンマシンを Google Cloud で作成する必要があります。これらのマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用してコントロールプレーンマシンを使用しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
手順
-
このトピックの コントロールプレーンマシンの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
05_control_plane.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンを記述しています。 リソース定義で必要な以下の変数をエクスポートします。
export MASTER_IGNITION=`cat <installation_directory>/master.ign`
$ export MASTER_IGNITION=`cat <installation_directory>/master.ign`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 05_control_plane.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 2
zonesは、コントロールプレーンインスタンスをデプロイするゾーンです (例:us-central1-a、us-central1-b、およびus-central1-c)。- 3
control_subnetは、コントロールサブセットのselfLinkURL です。- 4
imageは RHCOS イメージのselfLinkURL です。- 5
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 6
service_account_emailは作成したマスターサービスアカウントのメールアドレスです。- 7
ignitionはmaster.ignファイルの内容です。
gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deployment Manager の制限により、テンプレートではロードバランサーのメンバーシップを管理しないため、コントロールプレーンマシンを手動で追加する必要があります。
以下のコマンドを実行してコントロールプレーンマシンを適切なインスタンスグループに追加します。
gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-ig --zone=${ZONE_0} --instances=${INFRA_ID}-master-0$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-ig --zone=${ZONE_0} --instances=${INFRA_ID}-master-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-ig --zone=${ZONE_1} --instances=${INFRA_ID}-master-1$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-ig --zone=${ZONE_1} --instances=${INFRA_ID}-master-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-ig --zone=${ZONE_2} --instances=${INFRA_ID}-master-2$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-ig --zone=${ZONE_2} --instances=${INFRA_ID}-master-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、以下のコマンドを実行してコントロールプレーンマシンをターゲットプールに追加する必要もあります。
gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.16.1. コントロールプレーンマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。
例12.9 05_control_plane.py Deployment Manager テンプレート
12.17. Google Cloud でのブートストラップリソースの削除 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud で必要なインフラストラクチャーをすべて作成したら、Ignition 設定ファイルを使用してプロビジョニングしたマシンでブートストラッププロセスが完了するまで待機します。この Ignition 設定ファイルは、インストールプログラムによって作成されたものです。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンが作成されている。
手順
インストールプログラムが含まれているディレクトリーに移動し、次のコマンドを実行します。
./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ --log-level info$ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \1 --log-level info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドが
FATAL警告を出さずに終了する場合、実稼働用のコントロールプレーンは初期化されています。バックエンドサービスのバックエンドからブートストラップインスタンスグループを削除するには、次のコマンドを実行します。
gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ingress_backendservice=$(gcloud compute backend-services list --filter="backends.group~${INFRA_ID}" --format='value(name)' | grep -v "${INFRA_ID}")$ ingress_backendservice=$(gcloud compute backend-services list --filter="backends.group~${INFRA_ID}" --format='value(name)' | grep -v "${INFRA_ID}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow ingress_backendserviceが空でない場合は、ブートストラップグループに対して次のdescribeコマンドを実行します。gcloud compute backend-services describe ${ingress_backendservice} --region=${REGION}$ gcloud compute backend-services describe ${ingress_backendservice} --region=${REGION}Copy to Clipboard Copied! Toggle word wrap Toggle overflow describeコマンドで、ブートストラップグループがバックエンドの 1 つであることが表示された場合は、次のremove-backendコマンドを実行して、バックエンドからブートストラップグループを削除します。gcloud compute backend-services remove-backend ${ingress_backendservice} --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services remove-backend ${ingress_backendservice} --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow バケットとデプロイメントを削除するには、次のコマンドを実行します。
gsutil rb gs://${INFRA_ID}-bootstrap-ignition$ gsutil rb gs://${INFRA_ID}-bootstrap-ignitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrap$ gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrapCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.18. Google Cloud での追加のワーカーマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud でクラスターが使用するワーカーマシンを作成するには、それぞれのインスタンスを個別に起動するか、自動スケーリンググループなどのクラスター外にある自動プロセスを実行します。OpenShift Container Platform の組み込まれたクラスタースケーリングメカニズムやマシン API を利用できます。
この例では、Deployment Manager テンプレートを使用して 1 つのインスタンスを手動で起動します。追加のインスタンスは、ファイル内に 06_worker.py というタイプのリソースを追加して起動することができます。
ワーカーマシンを使用するために提供される Deployment Manager テンプレートを使用しない場合は、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンが作成されている。
手順
-
このトピックの ワーカーマシンの Deployment Manager テンプレート からテンプレートをコピーし、これを
06_worker.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なワーカーマシンを記述しています。 リソース定義が使用する変数をエクスポートします。
コンピュートマシンをホストするサブネットをエクスポートします。
export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${HOST_PROJECT_COMPUTE_SUBNET} --region=${REGION} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} --format json | jq -r .selfLink`)$ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${HOST_PROJECT_COMPUTE_SUBNET} --region=${REGION} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントのメールアドレスをエクスポートします。
export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)$ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートマシンの Ignition 設定ファイルの場所をエクスポートします。
export WORKER_IGNITION=`cat <installation_directory>/worker.ign`
$ export WORKER_IGNITION=`cat <installation_directory>/worker.ign`Copy to Clipboard Copied! Toggle word wrap Toggle overflow
06_worker.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
nameはワーカーマシンの名前です (例:worker-0)。- 2 9
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 3 10
zoneはワーカーマシンをデプロイするゾーンです (例:us-central1-a)。- 4 11
compute_subnetはコンピュートサブネットのselfLinkURL です。- 5 12
imageは RHCOS イメージのselfLinkURL です。1- 6 13
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 7 14
service_account_emailは作成したワーカーサービスアカウントのメールアドレスです。- 8 15
ignitionはworker.ignファイルの内容です。
-
オプション: 追加のインスタンスを起動する必要がある場合には、
06_worker.pyタイプの追加のリソースを06_worker.yamlリソース定義ファイルに組み込みます。 gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Google Cloud Marketplace イメージを使用するには、使用するオファーを指定します。
-
OpenShift Container Platform:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145 -
OpenShift Platform Plus:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145 -
OpenShift Kubernetes Engine:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145
-
OpenShift Container Platform:
12.18.1. ワーカーマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。
例12.10 06_worker.py Deployment Manager テンプレート
12.19. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ocバイナリーを、PATHにあるディレクトリーに配置します。PATHを確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
ocバイナリーを、PATHにあるディレクトリーに移動します。PATHを確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> pathCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
C:\> oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
ocバイナリーをパスにあるディレクトリーに移動します。PATHを確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
ocコマンドを使用して利用できます。oc <command>
$ oc <command>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.20. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.21. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
PendingまたはApprovedステータスが表示されていることを確認します。oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pendingステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approverによって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec、oc rsh、およびoc logsコマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:nodeまたはsystem:adminグループのnode-bootstrapperサービスアカウントによって提出されていることを確認し、ノードの ID を確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りの CSR が承認されず、それらが
Pendingステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Readyになります。以下のコマンドを実行して、これを確認します。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記サーバー CSR の承認後にマシンが
Readyステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
12.22. Ingress DNS レコードの追加 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定が削除されます。Ingress ロードバランサーを参照する DNS レコードを手動で作成する必要があります。ワイルドカード *.apps.{baseDomain}. または特定のレコードのいずれかを作成できます。要件に基づいて A、CNAME その他のレコードを使用できます。
前提条件
- GCP アカウントを設定します。
- Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
- ワーカーマシンを作成します。
手順
Ingress ルーターがロードバランサーを作成し、
EXTERNAL-IPフィールドにデータを設定するのを待機します。oc -n openshift-ingress get service router-default
$ oc -n openshift-ingress get service router-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.30.18.154 35.233.157.184 80:32288/TCP,443:31215/TCP 98
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.30.18.154 35.233.157.184 80:32288/TCP,443:31215/TCP 98Copy to Clipboard Copied! Toggle word wrap Toggle overflow A レコードをゾーンに追加します。
A レコードを使用するには、以下を実行します。
ルーター IP アドレスの変数をエクスポートします。
export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`$ export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow A レコードをプライベートゾーンに追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}Copy to Clipboard Copied! Toggle word wrap Toggle overflow また、外部クラスターの場合は、A レコードをパブリックゾーンに追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME} --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ワイルドカードを使用する代わりに明示的なドメインを追加するには、クラスターのそれぞれの現行ルートのエントリーを作成します。
oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes$ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
oauth-openshift.apps.your.cluster.domain.example.com console-openshift-console.apps.your.cluster.domain.example.com downloads-openshift-console.apps.your.cluster.domain.example.com alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.com
oauth-openshift.apps.your.cluster.domain.example.com console-openshift-console.apps.your.cluster.domain.example.com downloads-openshift-console.apps.your.cluster.domain.example.com alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.23. Ingress ファイアウォールルールの追加 リンクのコピーリンクがクリップボードにコピーされました!
クラスターには複数のファイアウォールルールが必要です。共有 VPC を使用しない場合、これらのルールは Google Cloud クラウドプロバイダーを介して Ingress コントローラーによって作成されます。共有 VPC を使用する場合は、現在すべてのサービスのクラスター全体のファイアウォールルールを作成するか、クラスターがアクセスを要求する際にイベントに基づいて各ルールを作成できます。クラスターがアクセスを要求する際に各ルールを作成すると、どのファイアウォールルールが必要であるかを正確に把握できます。クラスター全体のファイアウォールルールを作成する場合、同じルールセットを複数のクラスターに適用できます。
イベントに基づいて各ルールを作成する選択をする場合、クラスターをプロビジョニングした後、またはクラスターの有効期間中にコンソールがルールが見つからないことを通知する場合にファイアウォールルールを作成する必要があります。以下のイベントと同様のイベントが表示され、必要なファイアウォールルールを追加する必要があります。
oc get events -n openshift-ingress --field-selector="reason=LoadBalancerManualChange"
$ oc get events -n openshift-ingress --field-selector="reason=LoadBalancerManualChange"
出力例
Firewall change required by security admin: `gcloud compute firewall-rules create k8s-fw-a26e631036a3f46cba28f8df67266d55 --network example-network --description "{\"kubernetes.io/service-name\":\"openshift-ingress/router-default\", \"kubernetes.io/service-ip\":\"35.237.236.234\"}\" --allow tcp:443,tcp:80 --source-ranges 0.0.0.0/0 --target-tags exampl-fqzq7-master,exampl-fqzq7-worker --project example-project`
Firewall change required by security admin: `gcloud compute firewall-rules create k8s-fw-a26e631036a3f46cba28f8df67266d55 --network example-network --description "{\"kubernetes.io/service-name\":\"openshift-ingress/router-default\", \"kubernetes.io/service-ip\":\"35.237.236.234\"}\" --allow tcp:443,tcp:80 --source-ranges 0.0.0.0/0 --target-tags exampl-fqzq7-master,exampl-fqzq7-worker --project example-project`
これらのルールベースのイベントの作成時に問題が発生した場合には、クラスターの実行中にクラスター全体のファイアウォールルールを設定できます。
12.24. ユーザーによってプロビジョニングされるインフラストラクチャーでの Google Cloud インストールの実行 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud のユーザーによってプロビジョニングされるインフラストラクチャーで OpenShift Container Platform のインストールを開始した後は、クラスターが準備状態になるまでクラスターのイベントをモニターできます。
前提条件
- OpenShift Container Platform クラスターのブートストラップマシンを、user-provisioned GCP インフラストラクチャーにデプロイします。
-
ocCLI をインストールし、ログインします。
手順
クラスターのインストールを完了します。
./openshift-install --dir <installation_directory> wait-for install-complete
$ ./openshift-install --dir <installation_directory> wait-for install-complete1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Waiting up to 30m0s for the cluster to initialize...
INFO Waiting up to 30m0s for the cluster to initialize...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
クラスターの稼働状態を確認します。
以下のコマンドを実行し、現在のクラスターバージョンとステータスを表示します。
oc get clusterversion
$ oc get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% complete
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% completeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行し、Cluster Version Operator (CVO) を使用してコントロールプレーンで管理される Operator を表示します。
oc get clusteroperators
$ oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、クラスター Pod を表示します。
oc get pods --all-namespaces
$ oc get pods --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
現在のクラスターバージョンが
AVAILABLEの場合、インストールが完了します。
12.25. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
12.26. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポート にすることができます。
第13章 ユーザーによってプロビジョニングされるインフラストラクチャーのネットワークが制限された環境での Google Cloud へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、独自に提供するインフラストラクチャーとインストールリリースコンテンツの内部ミラーを使用するクラスターを Google Cloud にインストールできます。
ミラーリングされたインストールリリースのコンテンツを使用して OpenShift Container Platform クラスターをインストールすることは可能ですが、クラスターが GCP API を使用するにはインターネットへのアクセスが必要になります。
以下に、ユーザーによって提供されるインフラストラクチャーのインストールを実行する手順を要約します。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。
user-provisioned infrastructure のインストール手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。
13.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
ミラーホストでレジストリーを作成 し ており、使用しているバージョンの OpenShift Container Platform の
imageContentSourcesデータを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
-
ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。他のサイトへのアクセスを付与する必要がある場合もありますが、
*.googleapis.comおよびaccounts.google.comへのアクセスを付与する必要があります。 -
お使いの環境でクラウドアイデンティティーおよびアクセス管理(IAM) API にアクセスできない場合や、管理者レベルの認証情報シークレットを
kube-systemnamespace に保存することを望まない場合は、IAM 認証情報を手動で作成および維持 する ことができます。
13.2. ネットワークが制限された環境でのインストールについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
user-provisioned installation の設定は複雑であるため、user-provisioned infrastructure を使用してネットワークが制限されたインストールを試行する前に、標準的な user-provisioned infrastructure を実行することを検討してください。このテストが完了すると、ネットワークが制限されたインストール時に発生する可能性のある問題の切り分けやトラブルシューティングがより容易になります。
13.2.1. その他の制限 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersionステータスにはUnable to retrieve available updatesエラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
13.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
13.4. Google Cloud プロジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud プロジェクトを設定する必要があります。
13.4.1. Google Cloud プロジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。Google Cloud ドキュメントの Creating and Managing Projects を参照してください。
重要インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合は、Google Cloud プロジェクトは Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
13.4.2. Google Cloud での API サービスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。インストールに不要なオプションの API サービスを有効にすることもできます。Google Cloud ドキュメント の サービスの有効化 を 参照してください。
Expand 表13.1 必要な API サービス API サービス コンソールサービス名 Compute Engine API
compute.googleapis.comCloud Resource Manager API
cloudresourcemanager.googleapis.comGoogle DNS API
dns.googleapis.comIAM Service Account Credentials API
iamcredentials.googleapis.comIdentity and Access Management (IAM) API
iam.googleapis.comService Usage API
serviceusage.googleapis.comExpand 表13.2 オプションの API サービス API サービス コンソールサービス名 Google Cloud API
cloudapis.googleapis.comService Management API
servicemanagement.googleapis.comGoogle Cloud Storage JSON API
storage-api.googleapis.comCloud Storage
storage-component.googleapis.com
13.4.3. Google Cloud の DNS の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールするには、使用する Google Cloud アカウントに、OpenShift Container Platform クラスターをホストする同じプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、Google Cloud または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法の詳細は、Google ドメイン を参照してください。
Google Cloud プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。Google Cloud ドキュメントの Creating public zones を参照してください。
openshiftcorp.comなどのルートドメインや、clusters.openshiftcorp.comなどのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。Google Cloud ドキュメント の Cloud DNS ネームサーバーの検索 を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。Google Cloud のドキュメントの Migrating to Cloud DNS を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
13.4.4. Google Cloud アカウントの制限 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは多くの Google Cloud コンポーネントを使用しますが、デフォルトの Quotas はデフォルトの OpenShift Container Platform クラスターをインストールする機能には影響しません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
| サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
|---|---|---|---|---|
| サービスアカウント | IAM | グローバル | 6 | 1 |
| ファイアウォールのルール | ネットワーク | グローバル | 11 | 1 |
| 転送ルール | Compute | グローバル | 2 | 0 |
| ヘルスチェック | Compute | グローバル | 2 | 0 |
| イメージ | Compute | グローバル | 1 | 0 |
| ネットワーク | ネットワーク | グローバル | 1 | 0 |
| ルーター | ネットワーク | グローバル | 1 | 0 |
| ルート | ネットワーク | グローバル | 2 | 0 |
| サブネットワーク | Compute | グローバル | 2 | 0 |
| ターゲットプール | ネットワーク | グローバル | 2 | 0 |
インストール時にクォータが十分ではない場合、インストールプログラムは超過したクォータとリージョンの両方を示すエラーを表示します。
実際のクラスターサイズ、計画されるクラスターの拡張、およびアカウントに関連付けられた他のクラスターからの使用法を考慮してください。CPU、静的 IP アドレス、および永続ディスク SSD(ストレージ) のクォータは、ほとんどの場合に不十分になる可能性のあるものです。
以下のリージョンのいずれかにクラスターをデプロイする予定の場合、ストレージクォータの最大値を超え、CPU クォータ制限を超える可能性が高くなります。
-
asia-east2 -
asia-northeast2 -
asia-south1 -
australia-southeast1 -
europe-north1 -
europe-west2 -
europe-west3 -
europe-west6 -
northamerica-northeast1 -
southamerica-east1 -
us-west2
Google Cloud コンソール からリソースクォータを増やすことはできますが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
13.4.5. Google Cloud でのサービスアカウントの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform には、Google API のデータにアクセスするために認証および承認を提供する Google Cloud サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。Google Cloud ドキュメント の サービスアカウントの作成 を参照してください。
サービスアカウントに適切な権限を付与します。以下の個別の権限を付与するか、
Ownerロールを割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることは、必要な権限を得る最も簡単な方法ですが、その場合、サービスアカウントはプロジェクトに対して完全な管理権限を持つことになります。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
サービスアカウントキーを JSON 形式で作成するか、サービスアカウントを Google Cloud 仮想マシンにアタッチできます。Google Cloud のドキュメント の サービスアカウントキー の作成 および インスタンスのサービスアカウントの作成および有効化 を参照してください。
クラスターを作成するには、サービスアカウントキーまたはサービスアカウントがアタッチされた仮想マシンが必要です。
注記サービスアカウントがアタッチされた仮想マシンを使用してクラスターを作成する場合は、インストール前に
install-config.yamlファイルでcredentialsMode: Manualを設定する必要があります。
13.4.6. 必須 Google Cloud ロール リンクのコピーリンクがクリップボードにコピーされました!
作成したサービスアカウントに Owner ロールを割り当てると、OpenShift Container Platform のインストールに必要な権限を含め、すべての権限がそのサービスアカウントに付与されます。組織のセキュリティーポリシーでより制限的なアクセス許可セットが必要な場合は、次のアクセス許可を持つサービスアカウントを作成できます。
Cloud Credential Operator を passthrough モードで動作するように設定する場合、粒度の細かいパーミッションではなくロールを使用する必要があります。
クラスターを既存の Virtual Private Cloud (VPC) にデプロイする場合、次のリストに記載されているネットワーク権限は、サービスアカウントに必要ありません。
インストールプログラムに必要なロール
- Compute 管理者
- IAM セキュリティー管理者
- サービスアカウント管理者
- Service Account Key Admin
- Service Account User
- Storage Admin
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
パススルー認証情報モードの使用に必要なロール
- ロードバランサー計算の管理者
- IAM ロールビューアー
ユーザーによってプロビジョニングされる Google Cloud インフラストラクチャーに必要なロール
- Deployment Manager Editor
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
| アカウント | ロール |
|---|---|
| コントロールプレーン |
|
|
| |
|
| |
|
| |
|
| |
| Compute |
|
|
|
13.4.7. ユーザーによってプロビジョニングされるインフラストラクチャーに必要な Google Cloud 権限 リンクのコピーリンクがクリップボードにコピーされました!
作成したサービスアカウントに Owner ロールを割り当てると、OpenShift Container Platform のインストールに必要な権限を含め、すべての権限がそのサービスアカウントに付与されます。
組織のセキュリティーポリシーでより制限的なアクセス許可セットが必要な場合は、必要なアクセス許可を持つ カスタムロール を作成できます。OpenShift Container Platform クラスターを作成および削除するには、user-provisioned infrastructure に以下のパーミッションが必要です。
Cloud Credential Operator を passthrough モードで動作するように設定する場合、粒度の細かいパーミッションではなくロールを使用する必要があります。詳細は、「必須の GCP ロール」セクションの「パススルー認証情報モードを使用するための必要なロール」を参照してください。
例13.1 ネットワークリソースの作成に必要な権限
-
compute.addresses.create -
compute.addresses.createInternal -
compute.addresses.delete -
compute.addresses.get -
compute.addresses.list -
compute.addresses.use -
compute.addresses.useInternal -
compute.firewalls.create -
compute.firewalls.delete -
compute.firewalls.get -
compute.firewalls.list -
compute.forwardingRules.create -
compute.forwardingRules.get -
compute.forwardingRules.list -
compute.forwardingRules.setLabels -
compute.networks.create -
compute.networks.get -
compute.networks.list -
compute.networks.updatePolicy -
compute.routers.create -
compute.routers.get -
compute.routers.list -
compute.routers.update -
compute.routes.list -
compute.subnetworks.create -
compute.subnetworks.get -
compute.subnetworks.list -
compute.subnetworks.use -
compute.subnetworks.useExternalIp
例13.2 ロードバランサーリソースの作成に必要な権限
-
compute.regionBackendServices.create -
compute.regionBackendServices.get -
compute.regionBackendServices.list -
compute.regionBackendServices.update -
compute.regionBackendServices.use -
compute.targetPools.addInstance -
compute.targetPools.create -
compute.targetPools.get -
compute.targetPools.list -
compute.targetPools.removeInstance -
compute.targetPools.use
例13.3 DNS リソースの作成に必要な権限
-
dns.changes.create -
dns.changes.get -
dns.managedZones.create -
dns.managedZones.get -
dns.managedZones.list -
dns.networks.bindPrivateDNSZone -
dns.resourceRecordSets.create -
dns.resourceRecordSets.list -
dns.resourceRecordSets.update
例13.4 サービスアカウントリソースの作成に必要な権限
-
iam.serviceAccountKeys.create -
iam.serviceAccountKeys.delete -
iam.serviceAccountKeys.get -
iam.serviceAccountKeys.list -
iam.serviceAccounts.actAs -
iam.serviceAccounts.create -
iam.serviceAccounts.delete -
iam.serviceAccounts.get -
iam.serviceAccounts.list -
resourcemanager.projects.get -
resourcemanager.projects.getIamPolicy -
resourcemanager.projects.setIamPolicy
例13.5 コンピューティングリソースの作成に必要な権限
-
compute.disks.create -
compute.disks.get -
compute.disks.list -
compute.instanceGroups.create -
compute.instanceGroups.delete -
compute.instanceGroups.get -
compute.instanceGroups.list -
compute.instanceGroups.update -
compute.instanceGroups.use -
compute.instances.create -
compute.instances.delete -
compute.instances.get -
compute.instances.list -
compute.instances.setLabels -
compute.instances.setMetadata -
compute.instances.setServiceAccount -
compute.instances.setTags -
compute.instances.use -
compute.machineTypes.get -
compute.machineTypes.list
例13.6 ストレージリソースの作成に必要
-
storage.buckets.create -
storage.buckets.delete -
storage.buckets.get -
storage.buckets.list -
storage.objects.create -
storage.objects.delete -
storage.objects.get -
storage.objects.list
例13.7 ヘルスチェックリソースを作成するために必要な権限
-
compute.healthChecks.create -
compute.healthChecks.get -
compute.healthChecks.list -
compute.healthChecks.useReadOnly -
compute.httpHealthChecks.create -
compute.httpHealthChecks.get -
compute.httpHealthChecks.list -
compute.httpHealthChecks.useReadOnly
例13.8 Google Cloud ゾーンとリージョン関連情報を取得するために必要な権限
-
compute.globalOperations.get -
compute.regionOperations.get -
compute.regions.list -
compute.zoneOperations.get -
compute.zones.get -
compute.zones.list
例13.9 サービスとクォータを確認するために必要な権限
-
monitoring.timeSeries.list -
serviceusage.quotas.get -
serviceusage.services.list
例13.10 インストールに必要な IAM パーミッション
-
iam.roles.get
例13.11 インストールに必要なイメージ権限
-
compute.images.create -
compute.images.delete -
compute.images.get -
compute.images.list
例13.12 収集ブートストラップを実行するためのオプションの権限
-
compute.instances.getSerialPortOutput
例13.13 ネットワークリソースを削除するために必要な権限
-
compute.addresses.delete -
compute.addresses.deleteInternal -
compute.addresses.list -
compute.firewalls.delete -
compute.firewalls.list -
compute.forwardingRules.delete -
compute.forwardingRules.list -
compute.networks.delete -
compute.networks.list -
compute.networks.updatePolicy -
compute.routers.delete -
compute.routers.list -
compute.routes.list -
compute.subnetworks.delete -
compute.subnetworks.list
例13.14 ロードバランサーリソースを削除するために必要な権限
-
compute.regionBackendServices.delete -
compute.regionBackendServices.list -
compute.targetPools.delete -
compute.targetPools.list
例13.15 DNS リソースを削除するために必要な権限
-
dns.changes.create -
dns.managedZones.delete -
dns.managedZones.get -
dns.managedZones.list -
dns.resourceRecordSets.delete -
dns.resourceRecordSets.list
例13.16 サービスアカウントリソースを削除するために必要な権限
-
iam.serviceAccounts.delete -
iam.serviceAccounts.get -
iam.serviceAccounts.list -
resourcemanager.projects.getIamPolicy -
resourcemanager.projects.setIamPolicy
例13.17 コンピューティングリソースを削除するために必要な権限
-
compute.disks.delete -
compute.disks.list -
compute.instanceGroups.delete -
compute.instanceGroups.list -
compute.instances.delete -
compute.instances.list -
compute.instances.stop -
compute.machineTypes.list
例13.18 ストレージリソースの削除に必要
-
storage.buckets.delete -
storage.buckets.getIamPolicy -
storage.buckets.list -
storage.objects.delete -
storage.objects.list
例13.19 ヘルスチェックリソースを削除するために必要な権限
-
compute.healthChecks.delete -
compute.healthChecks.list -
compute.httpHealthChecks.delete -
compute.httpHealthChecks.list
例13.20 削除に必要なイメージ権限
-
compute.images.delete -
compute.images.list
例13.21 リージョン関連の情報を取得するために必要な権限
-
compute.regions.get
例13.22 必要な Deployment Manager 権限
-
deploymentmanager.deployments.create -
deploymentmanager.deployments.delete -
deploymentmanager.deployments.get -
deploymentmanager.deployments.list -
deploymentmanager.manifests.get -
deploymentmanager.operations.get -
deploymentmanager.resources.list
13.4.8. サポートされている Google Cloud リージョン リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを以下の Google Cloud リージョンにデプロイできます。
-
asia-east1(Changhua County, Taiwan) -
asia-east2(Hong Kong) -
asia-northeast1(Tokyo, Japan) -
asia-northeast2(Osaka, Japan) -
asia-northeast3(Seoul, South Korea) -
asia-south1(Mumbai, India) -
asia-south2(Delhi, India) -
asia-southeast1(Jurong West, Singapore) -
asia-southeast2(Jakarta, Indonesia) -
australia-southeast1(Sydney, Australia) -
australia-southeast2(Melbourne, Australia) -
europe-central2(Warsaw, Poland) -
europe-north1(Hamina, Finland) -
europe-southwest1(Madrid, Spain) -
europe-west1(St. Ghislain, Belgium) -
europe-west2(London, England, UK) -
europe-west3(Frankfurt, Germany) -
europe-west4(Eemshaven, Netherlands) -
europe-west6(Zürich, Switzerland) -
europe-west8(Milan, Italy) -
europe-west9(Paris, France) -
europe-west12(Turin, Italy) -
me-central1(ドーハ、カタール、中東) -
me-west1(Tel Aviv, Israel) -
northamerica-northeast1(Montréal, Québec, Canada) -
northamerica-northeast2(Toronto, Ontario, Canada) -
southamerica-east1(São Paulo, Brazil) -
southamerica-west1(Santiago, Chile) -
us-central1(Council Bluffs, Iowa, USA) -
us-east1(Moncks Corner, South Carolina, USA) -
us-east4(Ashburn, Northern Virginia, USA) -
us-east5(Columbus, Ohio) -
us-south1(Dallas, Texas) -
us-west1(The Dalles, Oregon, USA) -
us-west2(Los Angeles, California, USA) -
us-west3(Salt Lake City, Utah, USA) -
us-west4(Las Vegas, Nevada, USA)
リージョンおよびゾーンごとにどのマシンタイプのインスタンスが使用できるかを確認するには、Google の ドキュメント を参照してください。
13.4.9. Google Cloud の CLI ツールのインストールと設定 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Google Cloud に OpenShift Container Platform をインストールするには、Google Cloud の CLI ツールをインストールし、設定する必要があります。
前提条件
- クラスターをホストするためのプロジェクトを作成した。
- サービスアカウントを作成し、これに必要なパーミッションを付与しています。
手順
$PATHで以下のバイナリーをインストールします。-
gcloud -
gsutil
Google Cloud のドキュメントの Install the latest Cloud SDK version を参照してください。
-
設定したサービスアカウントで、
gcloudツールを使用して認証します。Google Cloud ドキュメント で、サービスアカウントでの認証 を参照してください。
13.5. user-provisioned infrastructure を使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
13.5.1. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
| ホスト | 説明 |
|---|---|
| 1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
| 3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
| 少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 以降から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
13.5.2. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
| マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
|---|---|---|---|---|---|
| ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
| コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
| Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
13.5.3. Google Cloud のテスト済みインスタンスタイプ リンクのコピーリンクがクリップボードにコピーされました!
以下の Google Cloud インスタンスタイプは OpenShift Container Platform でテストされています。
例13.23 マシンのシリーズ
-
A2 -
A3 -
C2 -
C2D -
C3 -
C3D -
C4 -
E2 -
M1 -
N1 -
N2 -
N2D -
N4 -
Tau T2D
13.5.4. カスタムマシンタイプの使用 リンクのコピーリンクがクリップボードにコピーされました!
カスタムマシンタイプを使用した OpenShift Container Platform クラスターのインストールがサポートされます。
カスタムマシンタイプを使用する場合は、以下を考慮してください。
- 事前定義されたインスタンスタイプと同様に、カスタムマシンタイプは、コントロールプレーンとコンピューティングマシンの最小リソース要件を満たす必要があります。詳細は、「クラスターインストールの最小リソース要件」を参照してください。
カスタムマシンタイプの名前は、次の構文に従う必要があります。
custom-<number_of_cpus>-<amount_of_memory_in_mb>たとえば、
custom-6-20480です。
13.6. Google Cloud のインストールファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して OpenShift Container Platform を Google Cloud にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var パーティションを設定するオプションもあります。
13.6.1. オプション: 別個の /var パーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のディスクパーティション設定はインストーラー側で行う必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。
OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
-
/var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。 -
/var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。 -
/var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。
/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。
この手順で個別の /var パーティションを作成する手順を実行する場合、このセクションで後に説明されるように、Kubernetes マニフェストおよび Ignition 設定ファイルを再び作成する必要はありません。
手順
OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。
mkdir $HOME/clusterconfig
$ mkdir $HOME/clusterconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-installを実行して、manifestおよびopenshiftのサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。openshift-install create manifests --dir $HOME/clusterconfig
$ openshift-install create manifests --dir $HOME/clusterconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
? SSH Public Key ... INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshift
? SSH Public Key ... INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: インストールプログラムで
clusterconfig/openshiftディレクトリーにマニフェストが作成されたことを確認します。ls $HOME/clusterconfig/openshift/
$ ls $HOME/clusterconfig/openshift/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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 ...
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 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加のパーティションを設定する Butane 設定を作成します。たとえば、
$HOME/clusterconfig/98-var-partition.buファイルに名前を付け、ディスクのデバイス名をworkerシステムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/varディレクトリーを別のパーティションにマウントします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 MiB (メビバイト) の最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、
prjquotaマウントオプションを有効にする必要があります。
注記個別の
/varパーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。Butane config からマニフェストを作成し、
clusterconfig/openshiftディレクトリーに保存します。たとえば、以下のコマンドを実行します。butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-installを再度実行し、manifestおよびopenshiftのサブディレクトリー内のファイルセットから、Ignition 設定を作成します。openshift-install create ignition-configs --dir $HOME/clusterconfig ls $HOME/clusterconfig/
$ openshift-install create ignition-configs --dir $HOME/clusterconfig $ ls $HOME/clusterconfig/ auth bootstrap.ign master.ign metadata.json worker.ignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールするためにインストール手順への入力として使用できます。
13.6.2. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
ミラーレジストリーの作成時に生成された
imageContentSources値を使用します。 - ミラーレジストリーの証明書の内容を取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yamlファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agentプロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- お使いのコンピューター上で Google Cloud アカウント用のサービスアカウントキーを設定していない場合は、Google Cloud からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
install-config.yamlファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecretの値を更新して、レジストリーの認証情報を追加します。pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow <mirror_host_name>の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundleパラメーターおよび値を追加します。additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----Copy to Clipboard Copied! Toggle word wrap Toggle overflow この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
VPC のネットワークおよびサブネットを定義して、親の
platform.gcpフィールドの下にクラスターをインストールします。network: <existing_vpc> controlPlaneSubnet: <control_plane_subnet> computeSubnet: <compute_subnet>
network: <existing_vpc> controlPlaneSubnet: <control_plane_subnet> computeSubnet: <compute_subnet>Copy to Clipboard Copied! Toggle word wrap Toggle overflow platform.gcp.networkには、既存の Google VPC の名前を指定します。platform.gcp.controlPlaneSubnetおよびplatform.gcp.computeSubnetの場合には、コントロールプレーンマシンとコンピュートマシンをそれぞれデプロイするために既存のサブネットを指定します。次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの値には、ミラーレジストリーの作成時に記録された
imageContentSourcesを使用します。
-
必要な
install-config.yamlファイルに他の変更を加えます。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。 install-config.yamlファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yamlファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
13.6.3. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
-
既存の
install-config.yamlファイルがある。 クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP)へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント(169.254.169.254)も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
13.6.4. Kubernetes マニフェストおよび Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
install-config.yamlインストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、作成したinstall-config.yamlファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。
オプション: クラスターでコンピュートマシンをプロビジョニングする必要がない場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
<installation_directory>/manifests/cluster-scheduler-02-config.ymlKubernetes マニフェストファイルのmastersSchedulableパラメーターがfalseに設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.ymlファイルを開きます。 -
mastersSchedulableパラメーターを見つけ、これがfalseに設定されていることを確認します。 - ファイルを保存し、終了します。
-
オプション: Ingress Operator を DNS レコードを作成するよう設定する必要がない場合は、
<installation_directory>/manifests/cluster-dns-02-config.ymlDNS 設定ファイルからprivateZoneおよびpublicZoneセクションを削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-passwordおよびkubeconfigファイルが./<installation_directory>/authディレクトリーに作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.7. 共通変数のエクスポート リンクのコピーリンクがクリップボードにコピーされました!
13.7.1. インフラストラクチャー名の抽出 リンクのコピーリンクがクリップボードにコピーされました!
Ignition 設定ファイルには、Google Cloud でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な Google Cloud リソースを見つけるためにも使用されます。提供される Deployment Manager テンプレートにはこのインフラストラクチャー名への参照が含まれるため、これを抽出する必要があります。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
- クラスターの Ignition 設定ファイルを生成している。
-
jqパッケージをインストールしている。
手順
Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。
jq -r .infraID <installation_directory>/metadata.json
$ jq -r .infraID <installation_directory>/metadata.json1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
出力例
openshift-vw9j6
openshift-vw9j61 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このコマンドの出力はクラスター名とランダムな文字列です。
13.7.2. Deployment Manager テンプレートの共通変数のエクスポート リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによって提供されるインフラストラクチャーのインストールを Google Cloud で実行するのに役立つ指定の Deployment Manager テンプレートで使用される一般的な変数のセットをエクスポートする必要があります。
特定の Deployment Manager テンプレートには、追加のエクスポートされる変数が必要になる場合があります。これについては、関連する手順で詳しく説明されています。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- クラスターの Ignition 設定ファイルを生成します。
-
jqパッケージをインストールします。
手順
提供される Deployment Manager テンプレートで使用される以下の一般的な変数をエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
13.8. Google Cloud での VPC の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用する VPC を Google Cloud で作成する必要があります。各種の要件を満たすよう VPC をカスタマイズできます。VPC を作成する 1 つの方法として、提供されている Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して Google Cloud インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
手順
-
このトピックの VPC の Deployment Manager テンプレート セクションを確認し、これを
01_vpc.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な VPC を記述しています。 01_vpc.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.8.1. VPC の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例13.24 01_vpc.py Deployment Manager テンプレート
13.9. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
13.9.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
13.9.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
| プロトコル | ポート | 説明 |
|---|---|---|
| ICMP | 該当なし | ネットワーク到達性のテスト |
| TCP |
| メトリクス |
|
|
ホストレベルのサービス。ポート | |
|
| Kubernetes が予約するデフォルトポート | |
|
| openshift-sdn | |
| UDP |
| VXLAN |
|
| Geneve | |
|
|
ポート | |
|
| IPsec IKE パケット | |
|
| IPsec NAT-T パケット | |
|
|
UDP ポート
外部 NTP タイムサーバーが設定されている場合は、UDP ポート | |
| TCP/UDP |
| Kubernetes ノードポート |
| ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| Kubernetes API |
| プロトコル | ポート | 説明 |
|---|---|---|
| TCP |
| etcd サーバーおよびピアポート |
13.10. Google Cloud でのロードバランサーの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するロードバランサーを Google Cloud で設定する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して Google Cloud インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの 内部ロードバランサーの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
02_lb_int.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な内部負荷分散オブジェクトを記述しています。 -
また、外部クラスターには、このトピックの 外部ロードバランサーの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
02_lb_ext.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要な外部負荷分散オブジェクトを記述しています。 デプロイメントテンプレートが使用する変数をエクスポートします。
クラスターネットワークの場所をエクスポートします。
export CLUSTER_NETWORK=(`gcloud compute networks describe ${INFRA_ID}-network --format json | jq -r .selfLink`)$ export CLUSTER_NETWORK=(`gcloud compute networks describe ${INFRA_ID}-network --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンのサブネットの場所をエクスポートします。
export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)$ export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが使用する 3 つのゾーンをエクスポートします。
export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)$ export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)$ export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)$ export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
02_infra.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター IP アドレスをエクスポートします。
export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)$ export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、クラスターのパブリック IP アドレスもエクスポートします。
export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)$ export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.10.1. 外部ロードバランサーの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な外部ロードバランサーをデプロイすることができます。
例13.25 02_lb_ext.py Deployment Manager テンプレート
13.10.2. 内部ロードバランサーの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な内部ロードバランサーをデプロイすることができます。
例13.26 02_lb_int.py Deployment Manager テンプレート
外部クラスターの作成時に、02_lb_ext.py テンプレートに加えてこのテンプレートが必要になります。
13.11. Google Cloud でのプライベート DNS ゾーンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するプライベート DNS ゾーンを Google Cloud で設定する必要があります。このコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの プライベート DNS の Deployment Manager テンプレート セクションのテンプレートをコピーし、これを
02_dns.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なプライベート DNS オブジェクトを記述しています。 02_dns.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow このテンプレートは Deployment Manager の制限により DNS エントリーを作成しないので、手動で作成する必要があります。
内部 DNS エントリーを追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、外部 DNS エントリーも追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.11.1. プライベート DNS の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なプライベート DNS をデプロイすることができます。
例13.27 02_dns.py Deployment Manager テンプレート
13.12. Google Cloud でのファイアウォールルールの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで使用するファイアウォールルールを Google Cloud で作成する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
手順
-
このトピックの ファイアウォールの Deployment Manager テンプレート セクションのテンプレートをコピーし、これを
03_firewall.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なセキュリティーグループを記述しています。 03_firewall.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.12.1. ファイアウォールルール用の Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なファイアウォールルールをデプロイすることができます。
例13.28 03_firewall.py Deployment Manager テンプレート
13.14. Google Cloud インフラストラクチャーの RHCOS クラスターイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ノードに Google Cloud 用の有効な Red Hat Enterprise Linux CoreOS (RHCOS)イメージを使用する必要があります。
手順
RHCOS イメージミラー ページから RHCOS イメージを取得します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。
ファイル名には、
rhcos-<version>-<arch>-gcp.<arch>.tar.gz形式の OpenShift Container Platform のバージョン番号が含まれます。Google ストレージバケットを作成します。
gsutil mb gs://<bucket_name>
$ gsutil mb gs://<bucket_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS イメージを Google ストレージバケットにアップロードします。
gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>
$ gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow アップロードした RHCOS イメージの場所を変数としてエクスポートします。
export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz
$ export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターイメージを作成します。
gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"$ gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.15. Google Cloud でのブートストラップマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターの初期化中に使用するブートストラップマシンを Google Cloud で作成する必要があります。このマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供されている Deployment Manager テンプレートを使用してブートストラップマシンを作成しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- pyOpenSSL がインストールされていることを確認します。
手順
-
このトピックの ブートストラップマシンの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
04_bootstrap.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なブートストラップマシンを記述しています。 インストールプログラムで必要な Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所をエクスポートします。
export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)$ export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow バケットを作成し、
bootstrap.ignファイルをアップロードします。gsutil mb gs://${INFRA_ID}-bootstrap-ignition$ gsutil mb gs://${INFRA_ID}-bootstrap-ignitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/$ gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ignition 設定にアクセスするために使用するブートストラップインスタンスの署名付き URL を作成します。出力から URL を変数としてエクスポートします。
export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`$ export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 04_bootstrap.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 2
regionはクラスターをデプロイするリージョンです (例:us-central1)。- 3
zoneはブートストラップインスタンスをデプロイするゾーンです (例:us-central1-b)。- 4
cluster_networkはクラスターネットワークのselfLinkURL です。- 5
control_subnetは、コントロールサブセットのselfLinkURL です。- 6
imageは RHCOS イメージのselfLinkURL です。- 7
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 8
root_volume_sizeはブートストラップマシンのブートディスクサイズです。- 9
bootstrap_ignは署名付き URL の作成時の URL 出力です。
gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deployment Manager の制限によりテンプレートではロードバランサーのメンバーシップを管理しないため、ブートストラップマシンは手動で追加する必要があります。
ブートストラップインスタンスを内部ロードバランサーのインスタンスグループに追加します。
gcloud compute instance-groups unmanaged add-instances \ ${INFRA_ID}-bootstrap-ig --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrap$ gcloud compute instance-groups unmanaged add-instances \ ${INFRA_ID}-bootstrap-ig --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrapCopy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップインスタンスグループを内部ロードバランサーのバックエンドサービスに追加します。
gcloud compute backend-services add-backend \ ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services add-backend \ ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.15.1. ブートストラップマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイすることができます。
例13.30 04_bootstrap.py Deployment Manager テンプレート
13.16. Google Cloud でのコントロールプレーンマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで使用するコントロールプレーンマシンを Google Cloud で作成する必要があります。これらのマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用してコントロールプレーンマシンを使用しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
手順
-
このトピックの コントロールプレーンマシンの Deployment Manager テンプレート セクションからテンプレートをコピーし、これを
05_control_plane.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンを記述しています。 リソース定義で必要な以下の変数をエクスポートします。
export MASTER_IGNITION=`cat <installation_directory>/master.ign`
$ export MASTER_IGNITION=`cat <installation_directory>/master.ign`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 05_control_plane.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 2
zonesは、コントロールプレーンインスタンスをデプロイするゾーンです (例:us-central1-a、us-central1-b、およびus-central1-c)。- 3
control_subnetは、コントロールサブセットのselfLinkURL です。- 4
imageは RHCOS イメージのselfLinkURL です。- 5
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 6
service_account_emailは作成したマスターサービスアカウントのメールアドレスです。- 7
ignitionはmaster.ignファイルの内容です。
gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deployment Manager の制限により、テンプレートではロードバランサーのメンバーシップを管理しないため、コントロールプレーンマシンを手動で追加する必要があります。
以下のコマンドを実行してコントロールプレーンマシンを適切なインスタンスグループに追加します。
gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-ig --zone=${ZONE_0} --instances=${INFRA_ID}-master-0$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-ig --zone=${ZONE_0} --instances=${INFRA_ID}-master-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-ig --zone=${ZONE_1} --instances=${INFRA_ID}-master-1$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-ig --zone=${ZONE_1} --instances=${INFRA_ID}-master-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-ig --zone=${ZONE_2} --instances=${INFRA_ID}-master-2$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-ig --zone=${ZONE_2} --instances=${INFRA_ID}-master-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 外部クラスターの場合、以下のコマンドを実行してコントロールプレーンマシンをターゲットプールに追加する必要もあります。
gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2$ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.16.1. コントロールプレーンマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。
例13.31 05_control_plane.py Deployment Manager テンプレート
13.17. Google Cloud でのブートストラップリソースの削除 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud で必要なインフラストラクチャーをすべて作成したら、Ignition 設定ファイルを使用してプロビジョニングしたマシンでブートストラッププロセスが完了するまで待機します。この Ignition 設定ファイルは、インストールプログラムによって作成されたものです。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンが作成されている。
手順
インストールプログラムが含まれているディレクトリーに移動し、次のコマンドを実行します。
./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ --log-level info$ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \1 --log-level info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドが
FATAL警告を出さずに終了する場合、実稼働用のコントロールプレーンは初期化されています。バックエンドサービスのバックエンドからブートストラップインスタンスグループを削除するには、次のコマンドを実行します。
gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ingress_backendservice=$(gcloud compute backend-services list --filter="backends.group~${INFRA_ID}" --format='value(name)' | grep -v "${INFRA_ID}")$ ingress_backendservice=$(gcloud compute backend-services list --filter="backends.group~${INFRA_ID}" --format='value(name)' | grep -v "${INFRA_ID}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow ingress_backendserviceが空でない場合は、ブートストラップグループに対して次のdescribeコマンドを実行します。gcloud compute backend-services describe ${ingress_backendservice} --region=${REGION}$ gcloud compute backend-services describe ${ingress_backendservice} --region=${REGION}Copy to Clipboard Copied! Toggle word wrap Toggle overflow describeコマンドで、ブートストラップグループがバックエンドの 1 つであることが表示された場合は、次のremove-backendコマンドを実行して、バックエンドからブートストラップグループを削除します。gcloud compute backend-services remove-backend ${ingress_backendservice} --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}$ gcloud compute backend-services remove-backend ${ingress_backendservice} --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-ig --instance-group-zone=${ZONE_0}Copy to Clipboard Copied! Toggle word wrap Toggle overflow バケットとデプロイメントを削除するには、次のコマンドを実行します。
gsutil rb gs://${INFRA_ID}-bootstrap-ignition$ gsutil rb gs://${INFRA_ID}-bootstrap-ignitionCopy to Clipboard Copied! Toggle word wrap Toggle overflow gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrap$ gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrapCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.18. Google Cloud での追加のワーカーマシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud でクラスターが使用するワーカーマシンを作成するには、それぞれのインスタンスを個別に起動するか、自動スケーリンググループなどのクラスター外にある自動プロセスを実行します。OpenShift Container Platform の組み込まれたクラスタースケーリングメカニズムやマシン API を利用できます。
この例では、Deployment Manager テンプレートを使用して 1 つのインスタンスを手動で起動します。追加のインスタンスは、ファイル内に 06_worker.py というタイプのリソースを追加して起動することができます。
ワーカーマシンを使用するために提供される Deployment Manager テンプレートを使用しない場合は、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- Google Cloud アカウントを設定する。
- クラスターの Ignition 設定ファイルを生成します。
- Google Cloud で VPC および関連するサブネットを作成し、設定します。
- Google Cloud でネットワークおよびロードバランサーを作成および設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンが作成されている。
手順
-
このトピックの ワーカーマシンの Deployment Manager テンプレート からテンプレートをコピーし、これを
06_worker.pyとしてコンピューターに保存します。このテンプレートは、クラスターに必要なワーカーマシンを記述しています。 リソース定義が使用する変数をエクスポートします。
コンピュートマシンをホストするサブネットをエクスポートします。
export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)$ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントのメールアドレスをエクスポートします。
export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)$ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートマシンの Ignition 設定ファイルの場所をエクスポートします。
export WORKER_IGNITION=`cat <installation_directory>/worker.ign`
$ export WORKER_IGNITION=`cat <installation_directory>/worker.ign`Copy to Clipboard Copied! Toggle word wrap Toggle overflow
06_worker.yamlリソース定義ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
nameはワーカーマシンの名前です (例:worker-0)。- 2 9
infra_idは抽出手順で得られるINFRA_IDインフラストラクチャー名です。- 3 10
zoneはワーカーマシンをデプロイするゾーンです (例:us-central1-a)。- 4 11
compute_subnetはコンピュートサブネットのselfLinkURL です。- 5 12
imageは RHCOS イメージのselfLinkURL です。1- 6 13
machine_typeはインスタンスのマシンタイプです (例:n1-standard-4)。- 7 14
service_account_emailは作成したワーカーサービスアカウントのメールアドレスです。- 8 15
ignitionはworker.ignファイルの内容です。
-
オプション: 追加のインスタンスを起動する必要がある場合には、
06_worker.pyタイプの追加のリソースを06_worker.yamlリソース定義ファイルに組み込みます。 gcloudCLI を使用してデプロイメントを作成します。gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yaml$ gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Google Cloud Marketplace イメージを使用するには、使用するオファーを指定します。
-
OpenShift Container Platform:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145 -
OpenShift Platform Plus:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145 -
OpenShift Kubernetes Engine:
https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145
-
OpenShift Container Platform:
13.18.1. ワーカーマシンの Deployment Manager テンプレート リンクのコピーリンクがクリップボードにコピーされました!
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。
例13.32 06_worker.py Deployment Manager テンプレート
13.19. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
ocCLI がインストールされている。
手順
kubeadmin認証情報をエクスポートします。export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
ocコマンドを正常に実行できることを確認します。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.20. デフォルトの OperatorHub カタログソースの無効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: trueをOperatorHubオブジェクトに追加して、デフォルトカタログのソースを無効にします。oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
13.21. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には作成したすべてのマシンがリスト表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
PendingまたはApprovedステータスが表示されていることを確認します。oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pendingステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approverによって自動的に承認されます。注記ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec、oc rsh、およびoc logsコマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:nodeまたはsystem:adminグループのnode-bootstrapperサービスアカウントによって提出されていることを確認し、ノードの ID を確認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りの CSR が承認されず、それらが
Pendingステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<csr_name>は、現行の CSR のリストからの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Readyになります。以下のコマンドを実行して、これを確認します。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記サーバー CSR の承認後にマシンが
Readyステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
13.22. オプション: Ingress DNS レコードの追加 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除した場合、Ingress ロードバランサーをポイントする DNS レコードを手動で作成する必要があります。ワイルドカード *.apps.{baseDomain}. または特定のレコードのいずれかを作成できます。要件に基づいて A、CNAME その他のレコードを使用できます。
前提条件
- GCP アカウントを設定します。
- Kubernetes マニフェストの作成および Ignition 設定の生成時に DNS ゾーン設定を削除します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
- ワーカーマシンを作成します。
手順
Ingress ルーターがロードバランサーを作成し、
EXTERNAL-IPフィールドにデータを設定するのを待機します。oc -n openshift-ingress get service router-default
$ oc -n openshift-ingress get service router-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.30.18.154 35.233.157.184 80:32288/TCP,443:31215/TCP 98
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-default LoadBalancer 172.30.18.154 35.233.157.184 80:32288/TCP,443:31215/TCP 98Copy to Clipboard Copied! Toggle word wrap Toggle overflow A レコードをゾーンに追加します。
A レコードを使用するには、以下を実行します。
ルーター IP アドレスの変数をエクスポートします。
export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`$ export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow A レコードをプライベートゾーンに追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow また、外部クラスターの場合は、A レコードをパブリックゾーンに追加します。
if [ -f transaction.yaml ]; then rm transaction.yaml; fi gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME} gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}$ if [ -f transaction.yaml ]; then rm transaction.yaml; fi $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME} $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ワイルドカードを使用する代わりに明示的なドメインを追加するには、クラスターのそれぞれの現行ルートのエントリーを作成します。
oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes$ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
oauth-openshift.apps.your.cluster.domain.example.com console-openshift-console.apps.your.cluster.domain.example.com downloads-openshift-console.apps.your.cluster.domain.example.com alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.com
oauth-openshift.apps.your.cluster.domain.example.com console-openshift-console.apps.your.cluster.domain.example.com downloads-openshift-console.apps.your.cluster.domain.example.com alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.23. ユーザーによってプロビジョニングされるインフラストラクチャーでの Google Cloud インストールの実行 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud のユーザーによってプロビジョニングされるインフラストラクチャーで OpenShift Container Platform のインストールを開始した後は、クラスターが準備状態になるまでクラスターのイベントをモニターできます。
前提条件
- OpenShift Container Platform クラスターのブートストラップマシンを、user-provisioned GCP インフラストラクチャーにデプロイします。
-
ocCLI をインストールし、ログインします。
手順
クラスターのインストールを完了します。
./openshift-install --dir <installation_directory> wait-for install-complete
$ ./openshift-install --dir <installation_directory> wait-for install-complete1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
INFO Waiting up to 30m0s for the cluster to initialize...
INFO Waiting up to 30m0s for the cluster to initialize...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
クラスターの稼働状態を確認します。
以下のコマンドを実行し、現在のクラスターバージョンとステータスを表示します。
oc get clusterversion
$ oc get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% complete
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% completeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行し、Cluster Version Operator (CVO) を使用してコントロールプレーンで管理される Operator を表示します。
oc get clusteroperators
$ oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、クラスター Pod を表示します。
oc get pods --all-namespaces
$ oc get pods --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
現在のクラスターバージョンが
AVAILABLEの場合、インストールが完了します。
13.24. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
13.25. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
-
Cluster Samples Operator および
must-gatherツールの イメージストリームを設定し ます。 - ネットワークが制限された環境で Operator Lifecycle Manager (OLM)を使用する 方法を説明します。
- クラスターのインストールに使用したミラーレジストリーに信頼される CA がある場合、トラストストアを設定してこれをクラスターに追加 します。
- 必要に応じて、リモートヘルスレポート にすることができます。
- 必要に応じて、非接続クラスターの登録 を参照してください。
第14章 Google Cloud でのクラスターのアンインストール リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud にデプロイしたクラスターを削除できます。
14.1. installer-provisioned infrastructure を使用するクラスターの削除 リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターは、クラウドから削除できます。
アンインストール後に、とくにユーザーによってプロビジョニングされるインフラストラクチャー (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストールプログラムが作成しなかったリソース、またはインストールプログラムがアクセスできないリソースが存在する可能性があります。たとえば、一部の Google Cloud リソースには共有 VPC ホストプロジェクトで IAM パーミッション が必要になるか、削除する必要のあるヘルスチェック が使用されていない可能性があります。
前提条件
- クラスターをデプロイするために使用したインストールプログラムのコピーがある。
- クラスター作成時にインストールプログラムが生成したファイルがあります。
手順
クラスターのインストールに使用したコンピューターで、インストールプログラムを含むディレクトリーに移動し、次のコマンドを実行します。
./openshift-install destroy cluster \ --dir <installation_directory> --log-level info
$ ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info1 2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある
metadata.jsonファイルが必要になります。-
オプション:
<installation_directory>ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。
14.2. Cloud Credential Operator ユーティリティーを使用した Google Cloud リソースの削除 リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud Workload Identity を使用して手動モードで Cloud Credential Operator (CCO)を使用して OpenShift Container Platform クラスターをアンインストールした後にリソースをクリーンアップするには、CCO ユーティリティー(ccoctl)を使用して、インストール時に ccoctl が作成した Google Cloud リソースを削除します。
前提条件
-
ccoctlバイナリーをデプロイメントして準備します。 - Google Cloud Workload Identity を使用して手動モードで CCO を使用して OpenShift Container Platform クラスターをインストールします。
手順
以下のコマンドを実行して、OpenShift Container Platform リリースイメージを取得します。
RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequestカスタムリソース (CR) のリストを抽出します。oc adm release extract --credentials-requests \ --cloud=gcp \ --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \ $RELEASE_IMAGE
$ oc adm release extract --credentials-requests \ --cloud=gcp \ --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \1 $RELEASE_IMAGECopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
credrequestsは、CredentialsRequestオブジェクトのリストが格納されるディレクトリーです。ディレクトリーが存在しない場合、このコマンドはディレクトリーを作成します。
ccoctlが作成した Google Cloud リソースを削除します。ccoctl gcp delete \ --name=<name> \ --project=<gcp_project_id> \ --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests
$ ccoctl gcp delete \ --name=<name> \1 --project=<gcp_project_id> \2 --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- リソースが削除されたことを確認するには、Google Cloud にクエリーを実行します。詳細については、Google Cloud のドキュメントを参照してください。
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.