GCP へのインストール
OpenShift Container Platform GCP クラスターのインストール
概要
第1章 GCP へのインストール
1.1. GCP プロジェクトの設定
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud Platform (GCP) プロジェクトを設定する必要があります。
1.1.1. GCP プロジェクトの作成
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud Platform (GCP) アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。GCP ドキュメントの プロジェクトの作成と管理 を参照してください。
重要GCP プロジェクトは、インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合には、Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>
の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
1.1.2. GCP での API サービスの有効化
Google Cloud Platform (GCP) プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。GCP ドキュメントの サービスの有効化 を参照してください。
表1.1 必要な API サービス
API サービス コンソールサービス名 Compute Engine API
compute.googleapis.com
Google Cloud API
cloudapis.googleapis.com
Cloud Resource Manager API
cloudresourcemanager.googleapis.com
Google DNS API
dns.googleapis.com
IAM Service Account Credentials API
iamcredentials.googleapis.com
Identity and Access Management (IAM) API
iam.googleapis.com
Service Management API
servicemanagement.googleapis.com
Service Usage API
serviceusage.googleapis.com
Google Cloud Storage JSON API
storage-api.googleapis.com
Cloud Storage
storage-component.googleapis.com
1.1.3. GCP の DNS の設定
OpenShift Container Platform をインストールするには、使用する Google Cloud Platform (GCP) アカウントに、OpenShift Container Platform クラスターをホストする同じプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、GCP または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法についての詳細は、 Google ドメイン を参照してください。
GCP プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。GCP ドキュメントの ゾーンの管理 を参照してください。
openshiftcorp.com
などのルートドメインや、clusters.openshiftcorp.com
などのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。GCP ドキュメントの Cloud DNS ネームサーバーを検索する を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。GCP ドキュメントの Cloud DNS への移行 を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
1.1.4. GCP アカウントの制限
OpenShift Container Platform クラスターは多くの Google Cloud Platform (GCP) コンポーネントを使用しますが、デフォルトの 割り当て (Quota) はデフォルトの OpenShift Container Platform クラスターをインストールする機能に影響を与えません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
表1.2 デフォルトのクラスターで使用される GCP リソース
サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
---|---|---|---|---|
サービスアカウント | IAM | グローバル | 5 | 0 |
ファイアウォールのルール | コンピュート | グローバル | 11 | 1 |
転送ルール | コンピュート | グローバル | 2 | 0 |
使用中のグローバル IP アドレス | コンピュート | グローバル | 4 | 1 |
ヘルスチェック | コンピュート | グローバル | 3 | 0 |
イメージ | コンピュート | グローバル | 1 | 0 |
ネットワーク | コンピュート | グローバル | 2 | 0 |
静的 IP アドレス | コンピュート | リージョン | 4 | 1 |
ルーター | コンピュート | グローバル | 1 | 0 |
ルート | コンピュート | グローバル | 2 | 0 |
サブネットワーク | コンピュート | グローバル | 2 | 0 |
ターゲットプール | コンピュート | グローバル | 3 | 0 |
CPU | コンピュート | リージョン | 28 | 4 |
永続ディスク SSD (GB) | コンピュート | リージョン | 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
GCP コンソール からリソースクォータを増やすことは可能ですが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
1.1.5. GCP でのサービスアカウントの作成
OpenShift Container Platform には、Google API でデータにアクセスするための認証および承認を提供する Google Cloud Platform (GCP) サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。GCP ドキュメントで サービスアカウントの作成 を参照してください。
サービスアカウントに適切なパーミッションを付与します。付随する個別のパーミッションを付与したり、
オーナー
ロールをこれに割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることが必要なパーミッションを取得する最も簡単な方法になります。 つまりこれは、サービスアカウントはプロジェクトを完全に制御できることを意味します。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
JSON 形式でサービスアカウントキーを作成します。GCP ドキュメントの サービスアカウントキーの作成 を参照してください。
クラスターを作成するには、サービスアカウントキーが必要になります。
1.1.5.1. 必要な GCP パーミッション
作成するサービスアカウントに オーナー
ロールを割り当てると、OpenShift Container Platform のインストールに必要なパーミッションも含め、そのサービスアカウントにすべてのパーミッションが付与されます。OpenShift Container Platform クラスターをデプロイするには、サービスアカウントに以下のパーミッションが必要です。クラスターを既存の VPC にデプロイする場合、サービスアカウントでは一部のネットワークのパーミッションを必要としません。これについては、以下の一覧に記載されています。
インストールプログラムに必要なロール
- Compute 管理者
- セキュリティー管理者
- サービスアカウント管理者
- サービスアカウントユーザー
- ストレージ管理者
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
オプションのロール
クラスターで Operator の制限された認証情報を新たに作成できるようにするには、以下のロールを追加します。
- サービスアカウントキー管理者
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
表1.3 GCP サービスアカウントのパーミッション
アカウント | ロール |
---|---|
コントロールプレーン |
|
| |
| |
| |
| |
コンピュート |
|
|
1.1.6. サポートされている GCP リージョン
OpenShift Container Platform クラスターを以下の Google Cloud Platform (GCP) リージョンにデプロイできます。
-
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-southeast1
(Jurong West, Singapore) -
asia-southeast2
(Jakarta, Indonesia) -
australia-southeast1
(Sydney, Australia) -
europe-north1
(Hamina, Finland) -
europe-west1
(St. Ghislain, Belgium) -
europe-west2
(London, England, UK) -
europe-west3
(Frankfurt, Germany) -
europe-west4
(Eemshaven, Netherlands) -
europe-west6
(Zürich, Switzerland) -
northamerica-northeast1
(Montréal, Québec, Canada) -
southamerica-east1
(São Paulo, Brazil) -
us-central1
(Council Bluffs, Iowa, USA) -
us-east1
(Moncks Corner, South Carolina, USA) -
us-east4
(Ashburn, Northern Virginia, USA) -
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)
1.1.7. 次のステップ
- GCP に OpenShift Container Platform クラスターをインストールします。カスタマイズされたクラスターのインストール、またはデフォルトのオプションで クラスターのクイックインストール を実行できます。
1.2. GCP の IAM の手動作成
クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境や、管理者がクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存する選択をしない場合に、クラスターのインストール前に Cloud Credential Operator (CCO) を手動モードにすることができます。
1.2.1. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。credentialsMode
パラメーターの異なる値を install-config.yaml
ファイルに設定し、組織のセキュリティー要件に応じて CCO を設定できます。
管理者レベルの認証情報シークレットをクラスターの kube-system
プロジェクトに保存する選択をしない場合、OpenShift Container Platform をインストールし、クラウド認証情報を手動で管理する際に CCO の credentialsMode
パラメーターを Manual
に設定できます。
手動モードを使用すると、クラスターに管理者レベルの認証情報を保存する必要なく、各クラスターコンポーネントに必要なパーミッションのみを指定できます。お使いの環境でクラウドプロバイダーのパブリック IAM エンドポイントへの接続がない場合も、このモードを使用できます。ただし、各アップグレードについて、パーミッションを新規リリースイメージを使用して手動で調整する必要があります。また、それらを要求するすべてのコンポーネントについて認証情報を手動で指定する必要があります。
利用可能なすべての CCO 認証情報モードとそれらのサポートされるプラットフォームの詳細については、Cloud Credential Operator について参照してください。
1.2.2. IAM の手動作成
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
マニフェストを生成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
$ openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
Cloud Credential Operator が手動モードになるように、設定マップを manifests ディレクトリーに挿入します。
$ cat <<EOF > mycluster/manifests/cco-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: cloud-credential-operator-config namespace: openshift-cloud-credential-operator annotations: release.openshift.io/create-only: "true" data: disabled: "true" EOF
ローカルクラウドの認証情報を使用して作成された
admin
認証情報シークレットを削除します。この削除により、admin
認証情報がクラスターに保存されなくなります。$ rm mycluster/openshift/99_cloud-creds-secret.yaml
インストールプログラムが含まれるディレクトリーから、
openshift-install
バイナリーがビルドされる OpenShift Container Platform リリースイメージの詳細を取得します。$ openshift-install version
出力例
release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64
このリリースイメージ内で、デプロイするクラウドをターゲットとする
CredentialsRequest
オブジェクトをすべて特定します。$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 --credentials-requests --cloud=gcp
これにより、それぞれの要求の詳細が表示されます。
サンプル
CredentialsRequest
オブジェクトapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: labels: controller-tools.k8s.io: "1.0" name: openshift-image-registry-gcs namespace: openshift-cloud-credential-operator spec: secretRef: name: installer-cloud-credentials namespace: openshift-image-registry providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: GCPProviderSpec predefinedRoles: - roles/storage.admin - roles/iam.serviceAccountUser skipServiceCheck: true
-
以前に生成した
openshift-install
マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、各credentialsRequest
のspec.secretRef
に定義される namespace およびシークレット名を使用して保存する必要があります。シークレットデータの形式は、クラウドプロバイダーごとに異なります。 インストールプログラムが含まれるディレクトリーから、クラスターの作成に進みます。
$ openshift-install create cluster --dir <installation_directory>
重要手動でメンテナーンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。詳細は、クラウドプロバイダーのインストールコンテンツの 手動でメンテナーンスされる認証情報を使用したクラスターのアップグレードについてのセクションを参照してください。
1.2.3. 管理者の認証情報のルートシークレット形式
各クラウドプロバイダーは、kube-system
namespace の認証情報ルートシークレットを使用します。これは、すべての認証情報要求を満たし、それぞれのシークレットを作成するために使用されます。これは、mint モード で新規の認証情報を作成するか、または passthrough モード で認証情報ルートシークレットをコピーして実行します。
シークレットの形式はクラウドごとに異なり、それぞれの CredentialsRequest
シークレットにも使用されます。
Google Cloud Platform (GCP) シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: gcp-credentials stringData: service_account.json: <ServiceAccount>
1.2.4. 手動でメンテナーンスされた認証情報を使用したクラスターのアップグレード
認証情報が今後のリリースで追加される場合、手動でメンテナーンスされる認証情報をを含むクラスターの Cloud Credential Operator (CCO) の upgradable
ステータスが false
に変更されます。4.5 から 4.6 などのマイナーリリースの場合、このステータスは、更新されたパーミッションが処理されるまでアップグレードを防ぎます。4.5.10 から 4.5.11{b> <b}などの z-stream リリースの場合、アップグレードはブロックされませんが、認証情報は新規リリースに対して依然として更新される必要があります。
Web コンソールの Administrator パースペクティブを使用して、CCO がアップグレード可能であるかどうかを判別します。
- Administration → Cluster Settings に移動します。
- CCO ステータスの詳細を表示するには、Cluster Operators 一覧で cloud-credential をクリックします。
-
Conditions セクションの Upgradeable ステータスが False の場合、新規リリースの
credentialsRequests
を検査し、アップグレード前にクラスターで手動でメンテナーンスされる認証情報を一致するように更新します。
アップグレードするリリースイメージに新規の認証情報を作成するほかに、既存の認証情報に必要なパーミッションを確認し、新規リリースの既存コンポーネントに対する新しいパーミッション要件に対応する必要があります。CCO はこれらの不一致を検出できず、この場合、 upgradable
を false
に設定しません。
クラウドプロバイダーのインストールコンテンツの IAM の手動作成 についてのセクションでは、クラウドに必要な認証情報を取得し、使用する方法について説明します。
1.2.5. mint モード
mint モードは、OpenShift Container Platform のデフォルトおよび推奨される Cloud Credential Operator (CCO) の認証情報モードです。このモードでは、CCO は提供される管理者レベルのクラウド認証情報を使用してクラスターを実行します。mint モードは AWS、GCP および Azure でサポートされます。
mint モードでは、admin
認証情報は kube-system
namespace に保存され、次に CCO によってクラスターの CredentialsRequest
オブジェクトを処理し、特定のパーミッションでそれぞれのユーザーを作成するために使用されます。
mint モードには以下の利点があります。
- 各クラスターコンポーネントにはそれぞれが必要なパーミッションのみがあります。
- クラウド認証情報の自動の継続的な調整が行われます。これには、アップグレードに必要になる可能性のある追加の認証情報またはパーミッションが含まれます。
1 つの不利な点として、mint モードでは、admin
認証情報がクラスターの kube-system
シークレットに保存される必要があります。
1.2.6. 管理者認証情報の削除またはローテーション機能を持つ mint モード
現時点で、このモードは AWS でのみサポートされます。
このモードでは、ユーザーは通常の mint モードと同様に admin
認証情報を使用して OpenShift Container Platform をインストールします。ただし、このモードはクラスターのインストール後に admin
認証情報シークレットを削除します。
管理者は、Cloud Credential Operator に読み取り専用の認証情報について独自の要求を行わせることができます。これにより、すべての CredentialsRequest
オブジェクトに必要なパーミッションがあることの確認が可能になります。そのため、いずれかの変更が必要にならない限り admin
認証情報は必要になりません。関連付けられた認証情報が削除された後に、必要な場合は、これは基礎となるクラウドで破棄できます。
アップグレードの前に、admin
の認証情報を復元する必要があります。今後は、認証情報が存在しない場合に、アップグレードがブロックされる可能性があります。
admin
認証情報はクラスターに永続的に保存されません。
このモードでは、短い期間にクラスターでの admin
認証情報が必要になります。また、アップグレードごとに admin
認証情報を使用してシークレットを手動で再インストールする必要があります。
1.2.7. 次のステップ
OpenShift Container Platform クラスターをインストールします。
- インストーラーでプロビジョニングされるインフラストラクチャーのデフォルトオプションを使用した クラスターの GCP へのクイックインストール
- インストーラーでプロビジョニングされるインフラストラクチャーへのクラウドのカスタマイズを使用したクラスターのインストール
- インストーラーでプロビジョニングされるインフラストラクチャーへのネットワークのカスタマイズを使用したクラスターのインストール
1.3. GCP へのクラスターのクイックインストール
OpenShift Container Platform バージョン 4.6 では、デフォルトの設定オプションを使用してクラスターを Google Cloud Platform (GCP) にインストールできます。
1.3.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
- GCP アカウントを設定 してクラスターをホストします。
- ファイアウォールを使用する場合、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要があります。
- システムが IAM(アイデンティティーおよびアクセス管理) を管理できない場合、クラスター管理者は IAM 認証情報を手動で作成し、維持 できます。手動モードは、クラウド IAM API に到達できない環境でも使用できます。
1.3.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.3.3. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent
とインストールプログラムの両方に SSH キーを指定する必要があります。このキーを使用してパブリッククラスターのブートストラップマシンにアクセスし、インストールの問題をトラブルシューティングできます。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core
としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core
ユーザーの ~/.ssh/authorized_keys
一覧に追加されます。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' \ -f <path>/<file_name> 1
- 1
~/.ssh/id_rsa
などの、新規 SSH キーのパスおよびファイル名を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。ssh-agent
プロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
- 1
~/.ssh/id_rsa
などの、SSH プライベートキーのパスおよびファイル名を指定します。
GOOGLE_APPLICATION_CREDENTIALS
環境変数をサービスアカウントのプライベートキーファイルへのフルパスに設定します。$ export GOOGLE_APPLICATION_CREDENTIALS="<your_service_account_file>"
認証情報が適用されていることを確認します。
$ gcloud auth list
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
1.3.4. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.3.5. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
クラスターに設定した GCP アカウントのサービスアカウントキーを使用しない既存の GCP 認証情報で、以下の場所に保存されているものを削除します。
-
GOOGLE_CREDENTIALS
、GOOGLE_CLOUD_KEYFILE_JSON
、またはGCLOUD_KEYFILE_JSON
環境変数 -
~/.gcp/osServiceAccount.json
ファイル -
gcloud cli
デフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に値を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- コンピューター上で GCP アカウント用のサービスアカウントキーを設定していない場合、GCP からこれを取得してファイルの内容を貼り付けるか、またはファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。7 文字以上の名前を指定すると、クラスター名から生成されるインフラストラクチャー ID で最初の 6 文字のみが使用されます。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "4vYBz-Ee6gm-ymBZj-Wt5AL" INFO Time elapsed: 36m22s
注記クラスターアクセスおよび認証情報の情報は、インストールが正常に実行される際に
<installation_directory>/.openshift_install.log
に出力されます。重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Owner
ロールをサービスアカウントに割り当てている場合、 そのロールを削除し、これをViewer
ロールに置き換えることができます。 -
Service Account Key Admin
ロールが含まれている場合は、これを削除することができます。
-
1.3.6. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.6 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
1.3.6.1. Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.3.6.2. Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
1.3.6.3. macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.3.7. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
関連情報
- OpenShift Container Platform へのアクセスおよびその詳細は、Web コンソールへのアクセス について参照してください。
1.3.8. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.6 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
1.3.9. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
1.4. カスタマイズによる GCP へのクラスターのインストール
OpenShift Container Platform バージョン 4.6 では、インストールプログラムが Google Cloud Platform (GCP) にプロビジョニングするインフラストラクチャーにカスタマイズされたクラスターをインストールできます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
1.4.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
- GCP アカウントを設定 してクラスターをホストします。
- ファイアウォールを使用する場合、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要があります。
- システムが IAM(アイデンティティーおよびアクセス管理) を管理できない場合、クラスター管理者は IAM 認証情報を手動で作成し、維持 できます。手動モードは、クラウド IAM API に到達できない環境でも使用できます。
1.4.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.4.3. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent
とインストールプログラムの両方に SSH キーを指定する必要があります。このキーを使用してパブリッククラスターのブートストラップマシンにアクセスし、インストールの問題をトラブルシューティングできます。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core
としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core
ユーザーの ~/.ssh/authorized_keys
一覧に追加されます。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' \ -f <path>/<file_name> 1
- 1
~/.ssh/id_rsa
などの、新規 SSH キーのパスおよびファイル名を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。ssh-agent
プロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
- 1
~/.ssh/id_rsa
などの、SSH プライベートキーのパスおよびファイル名を指定します。
GOOGLE_APPLICATION_CREDENTIALS
環境変数をサービスアカウントのプライベートキーファイルへのフルパスに設定します。$ export GOOGLE_APPLICATION_CREDENTIALS="<your_service_account_file>"
認証情報が適用されていることを確認します。
$ gcloud auth list
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
1.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
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.4.5. インストール設定ファイルの作成
Google Cloud Platform (GCP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- コンピューター上で GCP アカウント用のサービスアカウントキーを設定していない場合、GCP からこれを取得してファイルの内容を貼り付けるか、またはファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
1.4.5.1. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
openshift-install
コマンドは、パラメーターのフィールド名を検証しません。正しくない名前を指定すると、関連するファイルまたはオブジェクトは作成されず、エラーが報告されません。指定されたパラメーターのフィールド名が正しいことを確認します。
1.4.5.1.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
表1.4 必須パラメーター
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
インストールの実行に使用する特定プラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } } |
1.4.5.1.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
表1.5 ネットワークパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) プラグイン。 |
|
| 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 に一致する |
1.4.5.1.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
表1.6 オプションのパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| コンピュートノードを設定するマシンの設定。 | machine-pool オブジェクトの配列。詳細は、以下の Machine-pool の表を参照してください。 |
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Red Hat Operatorのクラウド認証情報 Operatorを参照してください。 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
| クラスターマシンへのアクセスを認証するための単一または複数の SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 | 1 つ以上のキー。以下に例を示します。 sshKey: <key1> <key2> <key3> |
1.4.5.1.4. 追加の Google Cloud Platform (GCP) 設定パラメーター
追加の GCP 設定パラメーターは以下の表で説明されています。
表1.7 追加の GCP パラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターをデプロイする既存 VPC の名前。 | 文字列。 |
| クラスターをホストする GCP リージョンの名前。 |
有効なリージョン名 (例: |
| GCP マシンタイプ。 | |
| インストールプログラムが指定される MachinePool のマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
| コントロールプレーンマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピュートマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストーラーは使用前にソースイメージをコピーする必要があります。 |
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
| ディスクのタイプ。 |
デフォルトの |
1.4.5.2. GCP のカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、または必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 controlPlane: 2 3 hyperthreading: Enabled 4 name: master platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-ssd diskSizeGB: 1024 replicas: 3 compute: 5 6 - hyperthreading: Enabled 7 name: worker platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-standard diskSizeGB: 128 replicas: 3 metadata: name: test-cluster 8 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: gcp: projectID: openshift-production 9 region: us-central1 10 pullSecret: '{"auths": ...}' 11 fips: false 12 sshKey: ssh-ed25519 AAAA... 13
- 1 8 9 10 11
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 5
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 6
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 7
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8
などの大規模なマシンタイプを使用します。 - 12
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、
x86_64
アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。 - 13
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
1.4.5.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 Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
1.4.6. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
クラスターに設定した GCP アカウントのサービスアカウントキーを使用しない既存の GCP 認証情報で、以下の場所に保存されているものを削除します。
-
GOOGLE_CREDENTIALS
、GOOGLE_CLOUD_KEYFILE_JSON
、またはGCLOUD_KEYFILE_JSON
環境変数 -
~/.gcp/osServiceAccount.json
ファイル -
gcloud cli
デフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "4vYBz-Ee6gm-ymBZj-Wt5AL" INFO Time elapsed: 36m22s
注記クラスターアクセスおよび認証情報の情報は、インストールが正常に実行される際に
<installation_directory>/.openshift_install.log
に出力されます。重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Owner
ロールをサービスアカウントに割り当てている場合、 そのロールを削除し、これをViewer
ロールに置き換えることができます。 -
Service Account Key Admin
ロールが含まれている場合は、これを削除することができます。
-
1.4.7. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.6 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
1.4.7.1. Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.4.7.2. Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
1.4.7.3. macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.4.8. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
関連情報
- OpenShift Container Platform へのアクセスおよびその詳細は、Web コンソールへのアクセス について参照してください。
1.4.9. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.6 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
1.4.10. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
1.5. ネットワークのカスタマイズによる GCP へのクラスターのインストール
OpenShift Container Platform バージョン 4.6 では、インストールプログラムが Google Cloud Platform (GCP) にプロビジョニングするインフラストラクチャーにカスタマイズされたネットワーク設定でクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy
設定パラメーターのみになります。
1.5.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
- GCP アカウントを設定 してクラスターをホストします。
- ファイアウォールを使用する場合、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要があります。
- システムが IAM(アイデンティティーおよびアクセス管理) を管理できない場合、クラスター管理者は IAM 認証情報を手動で作成し、維持 できます。手動モードは、クラウド IAM API に到達できない環境でも使用できます。
1.5.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.5.3. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent
とインストールプログラムの両方に SSH キーを指定する必要があります。このキーを使用してパブリッククラスターのブートストラップマシンにアクセスし、インストールの問題をトラブルシューティングできます。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core
としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core
ユーザーの ~/.ssh/authorized_keys
一覧に追加されます。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' \ -f <path>/<file_name> 1
- 1
~/.ssh/id_rsa
などの、新規 SSH キーのパスおよびファイル名を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。ssh-agent
プロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
- 1
~/.ssh/id_rsa
などの、SSH プライベートキーのパスおよびファイル名を指定します。
GOOGLE_APPLICATION_CREDENTIALS
環境変数をサービスアカウントのプライベートキーファイルへのフルパスに設定します。$ export GOOGLE_APPLICATION_CREDENTIALS="<your_service_account_file>"
認証情報が適用されていることを確認します。
$ gcloud auth list
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
1.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
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.5.5. インストール設定ファイルの作成
Google Cloud Platform (GCP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- コンピューター上で GCP アカウント用のサービスアカウントキーを設定していない場合、GCP からこれを取得してファイルの内容を貼り付けるか、またはファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
1.5.5.1. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
openshift-install
コマンドは、パラメーターのフィールド名を検証しません。正しくない名前を指定すると、関連するファイルまたはオブジェクトは作成されず、エラーが報告されません。指定されたパラメーターのフィールド名が正しいことを確認します。
1.5.5.1.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
表1.8 必須パラメーター
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
インストールの実行に使用する特定プラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } } |
1.5.5.1.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
表1.9 ネットワークパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) プラグイン。 |
|
| 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 に一致する |
1.5.5.1.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
表1.10 オプションのパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| コンピュートノードを設定するマシンの設定。 | machine-pool オブジェクトの配列。詳細は、以下の Machine-pool の表を参照してください。 |
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Red Hat Operatorのクラウド認証情報 Operatorを参照してください。 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
| クラスターマシンへのアクセスを認証するための単一または複数の SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 | 1 つ以上のキー。以下に例を示します。 sshKey: <key1> <key2> <key3> |
1.5.5.1.4. 追加の Google Cloud Platform (GCP) 設定パラメーター
追加の GCP 設定パラメーターは以下の表で説明されています。
表1.11 追加の GCP パラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターをデプロイする既存 VPC の名前。 | 文字列。 |
| クラスターをホストする GCP リージョンの名前。 |
有効なリージョン名 (例: |
| GCP マシンタイプ。 | |
| インストールプログラムが指定される MachinePool のマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
| コントロールプレーンマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピュートマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストーラーは使用前にソースイメージをコピーする必要があります。 |
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
| ディスクのタイプ。 |
デフォルトの |
1.5.5.2. GCP のカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、または必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 controlPlane: 2 3 hyperthreading: Enabled 4 name: master platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-ssd diskSizeGB: 1024 replicas: 3 compute: 5 6 - hyperthreading: Enabled 7 name: worker platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-standard diskSizeGB: 128 replicas: 3 metadata: name: test-cluster 8 networking: 9 clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: gcp: projectID: openshift-production 10 region: us-central1 11 pullSecret: '{"auths": ...}' 12 fips: false 13 sshKey: ssh-ed25519 AAAA... 14
- 1 8 10 11 12
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 5 9
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 6
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 7
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8
などの大規模なマシンタイプを使用します。 - 13
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、
x86_64
アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。 - 14
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
1.5.5.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 Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
1.5.6. ネットワーク設定フェーズ
インストール前にクラスター設定を指定する場合、ネットワーク設定を変更する際に、インストール手順にはいくつかのフェーズがあります。
- フェーズ 1
openshift-install create install-config
コマンドを入力した後に、以下のことを実行します。install-config.yaml
ファイルで、以下のネットワーク関連のフィールドをカスタマイズできます。-
networking.networkType
-
networking.clusterNetwork
-
networking.serviceNetwork
networking.machineNetwork
これらのフィールドの詳細は、インストール設定パラメーターを参照してください。
注記優先される NIC が置かれている CIDR に一致する
networking.machineNetwork
を設定します。
-
- フェーズ 2
-
openshift-install create manifests
コマンドを入力した後に、以下のことを実行します。高度なネットワーク設定を指定する必要がある場合、このフェーズで、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。
フェーズ 2 で、install-config.yaml
ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 ではクラスターネットワークプロバイダーをさらにカスタマイズできます。
1.5.7. 高度なネットワーク設定の指定
高度な設定のカスタマイズを使用し、クラスターネットワークプロバイダーの追加設定を指定して、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルの変更はサポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。
前提条件
-
install-config.yaml
ファイルを作成し、これに対する変更を完了します。
手順
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
$ ./openshift-install create manifests --dir <installation_directory>
ここでは、以下のようになります。
<installation_directory>
-
クラスターの
install-config.yaml
ファイルが含まれるディレクトリーの名前を指定します。
cluster-network-03-config.yml
という名前の、高度なネットワーク設定用のスタブマニフェストファイルを<installation_directory>/manifests/
ディレクトリーに作成します。$ cat <<EOF > <installation_directory>/manifests/cluster-network-03-config.yml apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: EOF
ここでは、以下のようになります。
<installation_directory>
-
クラスターの
manifests/
ディレクトリーが含まれるディレクトリー名を指定します。
エディターで
cluster-network-03-config.yml
ファイルを開き、以下の例のようにクラスターの高度なネットワーク設定を指定します。OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: defaultNetwork: openshiftSDNConfig: vxlanPort: 4800
-
cluster-network-03-config.yml
ファイルを保存し、テキストエディターを終了します。 -
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、クラスターの作成時にmanifests/
ディレクトリーを削除します。
1.5.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 オブジェクトに設定することにより、クラスターのクラスターネットワークプロバイダー設定を指定できます。
1.5.8.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
表1.12 Cluster Network Operator 設定オブジェクト
フィールド | タイプ | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定する一覧です。以下に例を示します。 spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23
この値は読み取り専用であり、 |
|
| サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14
この値は読み取り専用であり、 |
|
| クラスターネットワークの Container Network Interface (CNI) ネットワークプロバイダーを設定します。 |
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、kube-proxy 設定は機能しません。 |
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
表1.13 defaultNetwork
オブジェクト
フィールド | タイプ | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform はデフォルトで、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーを使用します。 |
|
| このオブジェクトは OpenShift SDN クラスターネットワークプロバイダーにのみ有効です。 |
|
| このオブジェクトは OVN-Kubernetes クラスターネットワークプロバイダーにのみ有効です。 |
OpenShift SDN CNI クラスターネットワークプロバイダーの設定
以下の表は、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーの設定フィールドについて説明しています。
表1.14 openshiftSDNConfig
オブジェクト
フィールド | タイプ | 説明 |
---|---|---|
|
|
OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は
|
|
| VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも この値は、クラスターのインストール後は変更できません。 |
|
|
すべての VXLAN パケットに使用するポート。デフォルト値は 別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。
Amazon Web Services (AWS) では、VXLAN にポート |
OpenShift SDN 設定の例
defaultNetwork: type: OpenShiftSDN openshiftSDNConfig: mode: NetworkPolicy mtu: 1450 vxlanPort: 4789
OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定
以下の表は OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定フィールドについて説明しています。
表1.15 ovnKubernetesConfig
object
フィールド | タイプ | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも この値は、クラスターのインストール後は変更できません。 |
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
OVN-Kubernetes 設定の例
defaultNetwork: type: OVNKubernetes ovnKubernetesConfig: mtu: 1400 genevePort: 6081
kubeProxyConfig オブジェクト設定
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
表1.16 kubeProxyConfig
オブジェクト
フィールド | タイプ | 説明 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s |
1.5.9. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "4vYBz-Ee6gm-ymBZj-Wt5AL" INFO Time elapsed: 36m22s
注記クラスターアクセスおよび認証情報の情報は、インストールが正常に実行される際に
<installation_directory>/.openshift_install.log
に出力されます。重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
1.5.10. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.6 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
1.5.10.1. Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.5.10.2. Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
1.5.10.3. macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.5.11. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
関連情報
- OpenShift Container Platform へのアクセスおよびその詳細は、Web コンソールへのアクセス について参照してください。
1.5.12. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.6 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
1.5.13. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
1.6. GCP のクラスターの既存 VPC へのインストール
OpenShift Container Platform バージョン 4.6 では、クラスターを Google Cloud Platform (GCP) の既存の Virtual Private Cloud (VPC) にインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
1.6.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
- GCP アカウントを設定 してクラスターをホストします。
- ファイアウォールを使用する場合、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要があります。
- システムが IAM(アイデンティティーおよびアクセス管理) を管理できない場合、クラスター管理者は IAM 認証情報を手動で作成し、維持 できます。手動モードは、クラウド IAM API に到達できない環境でも使用できます。
1.6.2. カスタム VPC の使用について
OpenShift Container Platform 4.6 では、クラスターを Google Cloud Platform (GCP) の既存の Virtual Private Cloud (VPC) の既存のサブネットにデプロイできます。OpenShift Container Platform を既存の GCP VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC を作成するために必要なインフラストラクチャーの作成パーミッションを取得できない場合は、このインストールオプションを使用します。サブネットのネットワークを設定する必要があります。
1.6.2.1. VPC を使用するための要件
VPC CIDR ブロックとマシンネットワーク CIDR の組み合わせは、空であってはなりません。サブネットはマシンネットワーク内にある必要があります。
インストールプログラムでは、次のコンポーネントは作成されません。
- NAT ゲートウェイ
- サブネット
- ルートテーブル
- VPC ネットワーク
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
1.6.2.2. VPC 検証
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定したサブネットすべてが存在します。
- コントロールプレーンマシン用に 1 つのサブネットを提供し、コンピューティングマシン用に 1 つのサブネットを提供します。
- サブネットの CIDR は指定されたマシン CIDR に属します。
1.6.2.3. パーミッションの区分
一部の個人は、クラウド内に他のリソースとは異なるリソースを作成できます。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
1.6.2.4. クラスター間の分離
OpenShift Container Platform を既存のネットワークにデプロイする場合、クラスターサービスの分離の規模は以下の方法で縮小されます。
- 複数の OpenShift Container Platform クラスターを同じ VPC にインストールできます。
- ICMP Ingress はネットワーク全体で許可されます。
- TCP 22 Ingress (SSH) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 6443 Ingress (Kubernetes API) はネットワーク全体に対して許可されます。
- コントロールプレーンの TCP 22623 Ingress (MCS) はネットワーク全体に対して許可されます。
1.6.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.6.4. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent
とインストールプログラムの両方に SSH キーを指定する必要があります。このキーを使用してパブリッククラスターのブートストラップマシンにアクセスし、インストールの問題をトラブルシューティングできます。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core
としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core
ユーザーの ~/.ssh/authorized_keys
一覧に追加されます。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' \ -f <path>/<file_name> 1
- 1
~/.ssh/id_rsa
などの、新規 SSH キーのパスおよびファイル名を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。ssh-agent
プロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
- 1
~/.ssh/id_rsa
などの、SSH プライベートキーのパスおよびファイル名を指定します。
GOOGLE_APPLICATION_CREDENTIALS
環境変数をサービスアカウントのプライベートキーファイルへのフルパスに設定します。$ export GOOGLE_APPLICATION_CREDENTIALS="<your_service_account_file>"
認証情報が適用されていることを確認します。
$ gcloud auth list
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
1.6.5. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.6.6. インストール設定ファイルの作成
Google Cloud Platform (GCP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- コンピューター上で GCP アカウント用のサービスアカウントキーを設定していない場合、GCP からこれを取得してファイルの内容を貼り付けるか、またはファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
1.6.6.1. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
openshift-install
コマンドは、パラメーターのフィールド名を検証しません。正しくない名前を指定すると、関連するファイルまたはオブジェクトは作成されず、エラーが報告されません。指定されたパラメーターのフィールド名が正しいことを確認します。
1.6.6.1.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
表1.17 必須パラメーター
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
インストールの実行に使用する特定プラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } } |
1.6.6.1.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
表1.18 ネットワークパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) プラグイン。 |
|
| 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 に一致する |
1.6.6.1.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
表1.19 オプションのパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| コンピュートノードを設定するマシンの設定。 | machine-pool オブジェクトの配列。詳細は、以下の Machine-pool の表を参照してください。 |
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Red Hat Operatorのクラウド認証情報 Operatorを参照してください。 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
| クラスターマシンへのアクセスを認証するための単一または複数の SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 | 1 つ以上のキー。以下に例を示します。 sshKey: <key1> <key2> <key3> |
1.6.6.1.4. 追加の Google Cloud Platform (GCP) 設定パラメーター
追加の GCP 設定パラメーターは以下の表で説明されています。
表1.20 追加の GCP パラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターをデプロイする既存 VPC の名前。 | 文字列。 |
| クラスターをホストする GCP リージョンの名前。 |
有効なリージョン名 (例: |
| GCP マシンタイプ。 | |
| インストールプログラムが指定される MachinePool のマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
| コントロールプレーンマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピュートマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストーラーは使用前にソースイメージをコピーする必要があります。 |
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
| ディスクのタイプ。 |
デフォルトの |
1.6.6.2. GCP のカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、または必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 controlPlane: 2 3 hyperthreading: Enabled 4 name: master platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-ssd diskSizeGB: 1024 replicas: 3 compute: 5 6 - hyperthreading: Enabled 7 name: worker platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-standard diskSizeGB: 128 replicas: 3 metadata: name: test-cluster 8 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: gcp: projectID: openshift-production 9 region: us-central1 10 network: existing_vpc 11 controlPlaneSubnet: control_plane_subnet 12 computeSubnet: compute_subnet 13 pullSecret: '{"auths": ...}' 14 fips: false 15 sshKey: ssh-ed25519 AAAA... 16
- 1 8 9 10 14
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 5
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 6
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 7
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8
などの大規模なマシンタイプを使用します。 - 11
- 既存 VPC の名前を指定します。
- 12
- コントロールプレーンマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 13
- コンピュートマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 15
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、
x86_64
アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。 - 16
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
1.6.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 Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
1.6.7. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
クラスターに設定した GCP アカウントのサービスアカウントキーを使用しない既存の GCP 認証情報で、以下の場所に保存されているものを削除します。
-
GOOGLE_CREDENTIALS
、GOOGLE_CLOUD_KEYFILE_JSON
、またはGCLOUD_KEYFILE_JSON
環境変数 -
~/.gcp/osServiceAccount.json
ファイル -
gcloud cli
デフォルト認証情報
-
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "4vYBz-Ee6gm-ymBZj-Wt5AL" INFO Time elapsed: 36m22s
注記クラスターアクセスおよび認証情報の情報は、インストールが正常に実行される際に
<installation_directory>/.openshift_install.log
に出力されます。重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
オプション: クラスターをインストールするために使用したサービスアカウントのパーミッションの数を減らすことができます。
-
Owner
ロールをサービスアカウントに割り当てている場合、 そのロールを削除し、これをViewer
ロールに置き換えることができます。 -
Service Account Key Admin
ロールが含まれている場合は、これを削除することができます。
-
1.6.8. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.6 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
1.6.8.1. Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.6.8.2. Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
1.6.8.3. macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.6.9. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
関連情報
- OpenShift Container Platform へのアクセスおよびその詳細は、Web コンソールへのアクセス について参照してください。
1.6.10. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.6 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
1.6.11. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
1.7. GCP へのプライベートクラスターのインストール
OpenShift Container Platform バージョン 4.6 では、プライベートクラスターを Google Cloud Platform (GCP) の既存の VPC にインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
1.7.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
- GCP アカウントを設定 してクラスターをホストします。
- ファイアウォールを使用する場合、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要があります。
- システムが IAM(アイデンティティーおよびアクセス管理) を管理できない場合、クラスター管理者は IAM 認証情報を手動で作成し、維持 できます。手動モードは、クラウド IAM API に到達できない環境でも使用できます。
1.7.2. プライベートクラスター
外部エンドポイントを公開しないプライベート OpenShift Container Platform クラスターをデプロイすることができます。プライベートクラスターは内部ネットワークからのみアクセス可能で、インターネット上では表示されません。
デフォルトで、OpenShift Container Platform はパブリックにアクセス可能な DNS およびエンドポイントを使用できるようにプロビジョニングされます。プライベートクラスターは、クラスターのデプロイ時に DNS、Ingress コントローラー、および API サーバーを private に設定します。つまり、クラスターリソースは内部ネットワークからのみアクセスでき、インターネット上では表示されません。
プライベートクラスターをデプロイするには、要件を満たす既存のネットワークを使用する必要があります。クラスターリソースはネットワーク上の他のクラスター間で共有される可能性があります。
さらに、プロビジョニングするクラウドの API サービスにアクセスできるマシンから、プロビジョニングするネットワーク上のホストおよびインストールメディアを取得するために使用するインターネットにプライベートクラスターをデプロイする必要があります。これらのアクセス要件を満たし、所属する会社のガイドラインに準拠したすべてのマシンを使用することができます。たとえば、このマシンには、クラウドネットワーク上の bastion ホスト、または VPN 経由でネットワークにアクセスできるマシンを使用できます。
1.7.2.1. GCP のプライベートクラスター
Google Cloud Platform (GCP) にプライベートクラスターを作成するには、クラスターをホストするために既存のプライベート VPC およびサブネットを指定する必要があります。インストールプログラムは、クラスターが必要とする DNS レコードを解決できる必要もあります。インストールプログラムは、内部トラフィック用としてのみ Ingress Operator および API サーバーを設定します。
クラスターには、GCP API にアクセスするためにインターネットへのアクセスが依然として必要になります。
以下のアイテムは、プライベートクラスターのインストール時に必要ではなく、作成されません。
- パブリックサブネット
- パブリック Ingress をサポートするパブリックネットワークロードバランサー
-
クラスターの
baseDomain
に一致するパブリック DNS ゾーン
インストールプログラムは、プライベート DNS ゾーンおよびクラスターに必要なレコードを作成するために指定する baseDomain
を使用します。クラスターは、Operator がクラスターのパブリックレコードを作成せず、すべてのクラスターマシンが指定するプライベートサブネットに配置されるように設定されます。
ソースタグに基づいて外部ロードバランサーへのアクセスを制限できないため、プライベートクラスターは内部ロードバランサーのみを使用して内部インスタンスへのアクセスを許可します。
内部ロードバランサーは、ネットワークロードバランサーが使用するターゲットプールではなく、インスタンスグループに依存します。インストールプログラムは、グループにインスタンスがない場合でも、各ゾーンのインスタンスグループを作成します。
- クラスター IP アドレスは内部のみで使用されます。
- 1 つの転送ルールが Kubernetes API およびマシン設定サーバーポートの両方を管理します。
- バックエンドサービスは各ゾーンのインスタンスグループ、および存在する場合はブートストラップインスタンスグループで設定されます。
- ファイアウォールは、内部のソース範囲のみに基づく単一ルールを使用します。
1.7.2.1.1. 制限事項
ロードバランサーの機能の違いにより、マシン設定サーバー /healthz
のヘルスチェックは実行されません。2 つの内部ロードバランサーが 1 つの IP アドレスを共有できませんが、2 つのネットワークロードバランサーは 1 つの外部 IP アドレスを共有できます。インスタンスが健全であるかどうかについては、ポート 6443 の /readyz
チェックで完全に判別されます。
1.7.3. カスタム VPC の使用について
OpenShift Container Platform 4.6 では、クラスターを Google Cloud Platform (GCP) の既存の VPC にデプロイできます。これを実行する場合、VPC 内の既存のサブネットおよびルーティングルールも使用する必要があります。
OpenShift Container Platform を既存の GCP VPC にデプロイすると、新規アカウントの制限を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VPC の作成に必要なインフラストラクチャーの作成パーミッションを取得できない場合には、このオプションを使用できます。
1.7.3.1. VPC を使用するための要件
インストールプログラムは、以下のコンポーネントを作成しなくなります。
- VPC
- サブネット
- Cloud Router
- Cloud NAT
- NAT IP アドレス
カスタム VPC を使用する場合は、そのカスタム VPC と使用するインストールプログラムおよびクラスターのサブネットを適切に設定する必要があります。インストールプログラムは、使用するクラスターのネットワーク範囲を細分化できず、サブネットのルートテーブルを設定するか、または DHCP などの VPC オプションを設定します。これは、クラスターのインストール前に設定する必要があります。
VPC およびサブネットは以下の要件を満たす必要があります。
- VPC は、OpenShift Container Platform クラスターをデプロイする同じ GCP プロジェクトに存在する必要があります。
- コントロールプレーンおよびコンピュートマシンからインターネットにアクセスできるようにするには、サブネットで Cloud NAT を設定してこれに対する egress を許可する必要があります。これらのマシンにパブリックアドレスがありません。インターネットへのアクセスが必要ない場合でも、インストールプログラムおよびイメージを取得できるように VPC ネットワークに対して egress を許可する必要があります。複数の Cloud NAT を共有サブネットで設定できないため、インストールプログラムはこれを設定できません。
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定するすべてのサブネットが存在し、指定した VPC に属します。
- サブネットの CIDR はマシン CIDR に属します。
- クラスターのコントロールプレーンおよびコンピュートマシンをデプロイするためにサブネットを指定する必要があります。両方のマシンタイプに同じサブネットを使用できます。
既存の VPC を使用するクラスターを破棄しても、VPC は削除されません。
1.7.3.2. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、バケット、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VPC、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する GCP の認証情報には、VPC、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VPC 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ロードバランサー、セキュリティーグループ、ストレージおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
1.7.3.3. クラスター間の分離
OpenShift Container Platform を既存ネットワークにデプロイする場合、クラスターサービスの分離は、クラスターのインフラストラクチャー ID によるクラスター内のマシンを参照するファイアウォールルールによって保持されます。クラスター内のトラフィックのみが許可されます。
複数のクラスターを同じ VPC にデプロイする場合、以下のコンポーネントはクラスター間のアクセスを共有する可能性があります。
- API: 外部公開ストラテジーでグローバルに利用可能か、または内部公開ストラテジーのネットワーク全体で利用できる。
- デバッグツール: SSH および ICMP アクセス用にマシン CIDR に対して開かれている仮想マシンインスタンス上のポートなど。
1.7.4. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.7.5. SSH プライベートキーの生成およびエージェントへの追加
クラスターでインストールのデバッグまたは障害復旧を実行する必要がある場合、ssh-agent
とインストールプログラムの両方に SSH キーを指定する必要があります。このキーを使用してパブリッククラスターのブートストラップマシンにアクセスし、インストールの問題をトラブルシューティングできます。
実稼働環境では、障害復旧およびデバッグが必要です。
このキーを使用して、ユーザー core
としてマスターノードに対して SSH を実行できます。クラスターをデプロイする際に、キーは core
ユーザーの ~/.ssh/authorized_keys
一覧に追加されます。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
パスワードなしの認証に設定されている SSH キーがコンピューター上にない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' \ -f <path>/<file_name> 1
- 1
~/.ssh/id_rsa
などの、新規 SSH キーのパスおよびファイル名を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
このコマンドを実行すると、指定した場所にパスワードを必要としない SSH キーが生成されます。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。ssh-agent
プロセスをバックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
- 1
~/.ssh/id_rsa
などの、SSH プライベートキーのパスおよびファイル名を指定します。
GOOGLE_APPLICATION_CREDENTIALS
環境変数をサービスアカウントのプライベートキーファイルへのフルパスに設定します。$ export GOOGLE_APPLICATION_CREDENTIALS="<your_service_account_file>"
認証情報が適用されていることを確認します。
$ gcloud auth list
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
1.7.6. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをローカルコンピューターにダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
1.7.7. インストール設定ファイルの手動作成
内部ネットワークからのみアクセスでき、インターネット上に表示されないプライベート OpenShift Container Platform クラスターのインストールの場合、インストール設定ファイルを手動で生成する必要があります。
前提条件
- OpenShift Container Platform インストーラープログラムおよびクラスターのアクセストークンを取得します。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
以下の
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイル
install-config.yaml
に名前を付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
1.7.7.1. インストール設定パラメーター
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
openshift-install
コマンドは、パラメーターのフィールド名を検証しません。正しくない名前を指定すると、関連するファイルまたはオブジェクトは作成されず、エラーが報告されません。指定されたパラメーターのフィールド名が正しいことを確認します。
1.7.7.1.1. 必須設定パラメーター
必須のインストール設定パラメーターは、以下の表で説明されています。
表1.21 必須パラメーター
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
|
|
インストールの実行に使用する特定プラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
{ "auths":{ "cloud.openshift.com":{ "auth":"b3Blb=", "email":"you@example.com" }, "quay.io":{ "auth":"b3Blb=", "email":"you@example.com" } } } |
1.7.7.1.2. ネットワーク設定パラメーター
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
表1.22 ネットワークパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールするクラスターネットワークプロバイダー Container Network Interface (CNI) プラグイン。 |
|
| 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 に一致する |
1.7.7.1.3. オプションの設定パラメーター
オプションのインストール設定パラメーターは、以下の表で説明されています。
表1.23 オプションのパラメーター
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| コンピュートノードを設定するマシンの設定。 | machine-pool オブジェクトの配列。詳細は、以下の Machine-pool の表を参照してください。 |
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現時点で異種クラスターはサポートされていないため、すべてのプールが同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Red Hat Operatorのクラウド認証情報 Operatorを参照してください。 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
|
| クラスターマシンへのアクセスを認証するための単一または複数の SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 | 1 つ以上のキー。以下に例を示します。 sshKey: <key1> <key2> <key3> |
1.7.7.1.4. 追加の Google Cloud Platform (GCP) 設定パラメーター
追加の GCP 設定パラメーターは以下の表で説明されています。
表1.24 追加の GCP パラメーター
パラメーター | 説明 | 値 |
---|---|---|
| クラスターをデプロイする既存 VPC の名前。 | 文字列。 |
| クラスターをホストする GCP リージョンの名前。 |
有効なリージョン名 (例: |
| GCP マシンタイプ。 | |
| インストールプログラムが指定される MachinePool のマシンを作成するアベイラビリティーゾーン。 |
YAML シーケンス の |
| コントロールプレーンマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピュートマシンをデプロイする VPC の既存サブネットの名前。 | サブネット名。 |
| コンピューティングイメージに適用する必要があるライセンス URL のリスト。 重要
| ネストされた仮想化 を有効にするライセンスなど、ライセンス API で使用可能なすべてのライセンス。このパラメーターは、ビルド済みのイメージを生成するメカニズムでは使用できません。ライセンス URL を使用すると、インストーラーは使用前にソースイメージをコピーする必要があります。 |
| ディスクのサイズ (GB 単位)。 | 16 GB から 65536 GB の間のサイズ |
| ディスクのタイプ。 |
デフォルトの |
1.7.7.2. GCP のカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、または必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 controlPlane: 2 3 hyperthreading: Enabled 4 name: master platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-ssd diskSizeGB: 1024 replicas: 3 compute: 5 6 - hyperthreading: Enabled 7 name: worker platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c osDisk: diskType: pd-standard diskSizeGB: 128 replicas: 3 metadata: name: test-cluster 8 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: gcp: projectID: openshift-production 9 region: us-central1 10 network: existing_vpc 11 controlPlaneSubnet: control_plane_subnet 12 computeSubnet: compute_subnet 13 pullSecret: '{"auths": ...}' 14 fips: false 15 sshKey: ssh-ed25519 AAAA... 16 publish: Internal 17
- 1 8 9 10 14
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 5
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 6
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 7
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8
などの大規模なマシンタイプを使用します。 - 11
- 既存 VPC の名前を指定します。
- 12
- コントロールプレーンマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 13
- コンピュートマシンをデプロイする既存サブネットの名前を指定します。サブネットは、指定した VPC に属している必要があります。
- 15
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、
x86_64
アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。 - 16
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 17
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publish
をInternal
に設定します。これはインターネットからアクセスできません。デフォルト値はExternal
です。
1.7.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 Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
1.7.8. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "4vYBz-Ee6gm-ymBZj-Wt5AL" INFO Time elapsed: 36m22s
注記クラスターアクセスおよび認証情報の情報は、インストールが正常に実行される際に
<installation_directory>/.openshift_install.log
に出力されます。重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
1.7.9. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.6 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
1.7.9.1. Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.7.9.2. Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
1.7.9.3. macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.7.10. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
関連情報
- OpenShift Container Platform へのアクセスおよびその詳細は、Web コンソールへのアクセス について参照してください。
1.7.11. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.6 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
1.7.12. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
1.8. Deployment Manager テンプレートの使用による GCP でのユーザーによってプロビジョニングされるインフラストラクチャーへのクラスターのインストール
OpenShift Container Platform バージョン 4.6 では、プロビジョニングするインフラストラクチャーを使用するクラスターを Google Cloud Platform (GCP) にインストールできます。
以下に、ユーザーによって提供されるインフラストラクチャーのインストールを実行する手順を要約します。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。
ユーザーによってプロビジョニングされるインフラストラクチャーのインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスについて理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。
1.8.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
- ファイアウォールを使用し、Telemetry を使用する予定がある場合は、クラスターがアクセスする必要のある サイトを許可するようにファイアウォールを設定 する必要があります。
システムが IAM(アイデンティティーおよびアクセス管理) を管理できない場合、クラスター管理者は IAM 認証情報を手動で作成し、維持 できます。手動モードは、クラウド IAM API に到達できない環境でも使用できます。
注記プロキシーを設定する場合は、このサイト一覧も確認してください。
1.8.2. 証明書署名要求の管理
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
1.8.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.8.4. GCP プロジェクトの設定
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud Platform (GCP) プロジェクトを設定する必要があります。
1.8.4.1. GCP プロジェクトの作成
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud Platform (GCP) アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。GCP ドキュメントの プロジェクトの作成と管理 を参照してください。
重要GCP プロジェクトは、インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合には、Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>
の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
1.8.4.2. GCP での API サービスの有効化
Google Cloud Platform (GCP) プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。GCP ドキュメントの サービスの有効化 を参照してください。
表1.25 必要な API サービス
API サービス コンソールサービス名 Cloud Deployment Manager V2 API
deploymentmanager.googleapis.com
Compute Engine API
compute.googleapis.com
Google Cloud API
cloudapis.googleapis.com
Cloud Resource Manager API
cloudresourcemanager.googleapis.com
Google DNS API
dns.googleapis.com
IAM Service Account Credentials API
iamcredentials.googleapis.com
Identity and Access Management (IAM) API
iam.googleapis.com
Service Management API
servicemanagement.googleapis.com
Service Usage API
serviceusage.googleapis.com
Google Cloud Storage JSON API
storage-api.googleapis.com
Cloud Storage
storage-component.googleapis.com
1.8.4.3. GCP の DNS の設定
OpenShift Container Platform をインストールするには、使用する Google Cloud Platform (GCP) アカウントに、OpenShift Container Platform クラスターをホストする同じプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、GCP または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法についての詳細は、 Google ドメイン を参照してください。
GCP プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。GCP ドキュメントの ゾーンの管理 を参照してください。
openshiftcorp.com
などのルートドメインや、clusters.openshiftcorp.com
などのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。GCP ドキュメントの Cloud DNS ネームサーバーを検索する を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。GCP ドキュメントの Cloud DNS への移行 を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
1.8.4.4. GCP アカウントの制限
OpenShift Container Platform クラスターは多くの Google Cloud Platform (GCP) コンポーネントを使用しますが、デフォルトの 割り当て (Quota) はデフォルトの OpenShift Container Platform クラスターをインストールする機能に影響を与えません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
表1.26 デフォルトのクラスターで使用される GCP リソース
サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
---|---|---|---|---|
サービスアカウント | IAM | グローバル | 5 | 0 |
ファイアウォールのルール | ネットワーク | グローバル | 11 | 1 |
転送ルール | コンピュート | グローバル | 2 | 0 |
ヘルスチェック | コンピュート | グローバル | 2 | 0 |
イメージ | コンピュート | グローバル | 1 | 0 |
ネットワーク | ネットワーク | グローバル | 1 | 0 |
ルーター | ネットワーク | グローバル | 1 | 0 |
ルート | ネットワーク | グローバル | 2 | 0 |
サブネットワーク | コンピュート | グローバル | 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
GCP コンソール からリソースクォータを増やすことは可能ですが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
1.8.4.5. GCP でのサービスアカウントの作成
OpenShift Container Platform には、Google API でデータにアクセスするための認証および承認を提供する Google Cloud Platform (GCP) サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。GCP ドキュメントで サービスアカウントの作成 を参照してください。
サービスアカウントに適切なパーミッションを付与します。付随する個別のパーミッションを付与したり、
オーナー
ロールをこれに割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることが必要なパーミッションを取得する最も簡単な方法になります。 つまりこれは、サービスアカウントはプロジェクトを完全に制御できることを意味します。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
JSON 形式でサービスアカウントキーを作成します。GCP ドキュメントの サービスアカウントキーの作成 を参照してください。
クラスターを作成するには、サービスアカウントキーが必要になります。
1.8.4.5.1. 必要な GCP パーミッション
作成するサービスアカウントに オーナー
ロールを割り当てると、OpenShift Container Platform のインストールに必要なパーミッションも含め、そのサービスアカウントにすべてのパーミッションが付与されます。OpenShift Container Platform クラスターをデプロイするには、サービスアカウントに以下のパーミッションが必要です。クラスターを既存の VPC にデプロイする場合、サービスアカウントでは一部のネットワークのパーミッションを必要としません。これについては、以下の一覧に記載されています。
インストールプログラムに必要なロール
- Compute 管理者
- セキュリティー管理者
- サービスアカウント管理者
- サービスアカウントユーザー
- ストレージ管理者
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
ユーザーによってプロビジョニングされる GCP インフラストラクチャーに必要なロール
- Deployment Manager Editor
- サービスアカウントキー管理者
オプションのロール
クラスターで Operator の制限された認証情報を新たに作成できるようにするには、以下のロールを追加します。
- サービスアカウントキー管理者
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
表1.27 GCP サービスアカウントのパーミッション
アカウント | ロール |
---|---|
コントロールプレーン |
|
| |
| |
| |
| |
コンピュート |
|
|
1.8.4.6. サポートされている GCP リージョン
OpenShift Container Platform クラスターを以下の Google Cloud Platform (GCP) リージョンにデプロイできます。
-
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-southeast1
(Jurong West, Singapore) -
asia-southeast2
(Jakarta, Indonesia) -
australia-southeast1
(Sydney, Australia) -
europe-north1
(Hamina, Finland) -
europe-west1
(St. Ghislain, Belgium) -
europe-west2
(London, England, UK) -
europe-west3
(Frankfurt, Germany) -
europe-west4
(Eemshaven, Netherlands) -
europe-west6
(Zürich, Switzerland) -
northamerica-northeast1
(Montréal, Québec, Canada) -
southamerica-east1
(São Paulo, Brazil) -
us-central1
(Council Bluffs, Iowa, USA) -
us-east1
(Moncks Corner, South Carolina, USA) -
us-east4
(Ashburn, Northern Virginia, USA) -
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)
1.8.4.7. GCP の CLI ツールのインストールおよび設定
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Google Cloud Platform (GCP) に OpenShift Container Platform をインストールするには、GCP の CLI ツールをインストールし、設定する必要があります。
前提条件
- クラスターをホストするプロジェクトを作成しています。
- サービスアカウントを作成し、これに必要なパーミッションを付与しています。
手順
$PATH
で以下のバイナリーをインストールします。-
gcloud
-
gsutil
GCP ドキュメントの Google Cloud SDK のドキュメント を参照してください。
-
設定したサービスアカウントで、
gcloud
ツールを使用して認証します。GCP ドキュメントで、サービスアカウントでの認証 について参照してください。
1.8.5. GCP のインストール設定ファイルの作成
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して OpenShift Container Platform を Google Cloud Platform (GCP) にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml
ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var
パーティションを設定するオプションもあります。
1.8.5.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
openshift-install
を実行して、manifest
およびopenshift
のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。$ openshift-install create manifests --dir $HOME/clusterconfig
出力例
? 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
オプション: インストールプログラムで
clusterconfig/openshift
ディレクトリーにマニフェストが作成されたことを確認します。$ ls $HOME/clusterconfig/openshift/
出力例
99_kubeadmin-password-secret.yaml 99_openshift-cluster-api_master-machines-0.yaml 99_openshift-cluster-api_master-machines-1.yaml 99_openshift-cluster-api_master-machines-2.yaml ...
MachineConfig
オブジェクトを作成し、これをopenshift
ディレクトリーのファイルに追加します。たとえば、98-var-partition.yaml
ファイルに名前を付け、ディスクのデバイス名をworker
システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var
ディレクトリーを別のパーティションにマウントします。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 98-var-partition spec: config: ignition: version: 3.1.0 storage: disks: - device: /dev/<device_name> 1 partitions: - label: var startMiB: <partition_start_offset> 2 sizeMiB: <partition_size> 3 filesystems: - device: /dev/disk/by-partlabel/var path: /var format: xfs systemd: units: - name: var.mount 4 enabled: true contents: | [Unit] Before=local-fs.target [Mount] What=/dev/disk/by-partlabel/var Where=/var Options=defaults,prjquota 5 [Install] WantedBy=local-fs.target
- 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 MiB (メビバイト) の最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- マウントユニットの名前は、
Where=
ディレクティブで指定されたディレクトリーと一致する必要があります。たとえば、/var/lib/containers
にマウントされているファイルシステムの場合、ユニットの名前はvar-lib-containers.mount
にする必要があります。 - 5
- コンテナーストレージに使用されるファイルシステムでは、
prjquota
マウントオプションを有効にする必要があります。
注記個別の
/var
パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。openshift-install
を再度実行し、manifest
およびopenshift
のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。$ openshift-install create ignition-configs --dir $HOME/clusterconfig $ ls $HOME/clusterconfig/ auth bootstrap.ign master.ign metadata.json worker.ign
Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールするためにインストール手順への入力として使用できます。
1.8.5.2. インストール設定ファイルの作成
Google Cloud Platform (GCP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- コンピューター上で GCP アカウント用のサービスアカウントキーを設定していない場合、GCP からこれを取得してファイルの内容を貼り付けるか、またはファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
オプション: クラスターでコンピュートマシンをプロビジョニングするよう設定する必要がない場合は、
install-config.yaml
ファイルでcompute
プールのreplicas
を0
に設定してコンピュートプールを空にします。compute: - hyperthreading: Enabled name: worker platform: {} replicas: 0 1
- 1
0
に設定します。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
1.8.5.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 Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
1.8.5.4. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを作成するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターを作成するために後に使用されます。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
については、作成したinstall-config.yaml
ファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。
オプション: クラスターでコンピュートマシンをプロビジョニングする必要がない場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
オプション: Ingress Operator を DNS レコードを作成するよう設定する必要がない場合は、
<installation_directory>/manifests/cluster-dns-02-config.yml
DNS 設定ファイルからprivateZone
およびpublicZone
セクションを削除します。apiVersion: config.openshift.io/v1 kind: DNS metadata: creationTimestamp: null name: cluster spec: baseDomain: example.openshift.com privateZone: 1 id: mycluster-100419-private-zone publicZone: 2 id: example.openshift.com status: {}
これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
$ ./openshift-install create ignition-configs --dir <installation_directory> 1
- 1
<installation_directory>
については、同じインストールディレクトリーを指定します。
以下のファイルはディレクトリーに生成されます。
. ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
1.8.6. 一般的な変数のエクスポート
1.8.6.1. インフラストラクチャー名の抽出
Ignition 設定ファイルには、Google Cloud Platform (GCP) でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な GCP リソースを見つけるためにも使用されます。提供される Deployment Manager テンプレートにはこのインフラストラクチャー名への参照が含まれるため、これを抽出する必要があります。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
- クラスターの Ignition 設定ファイルを生成している。
-
jq
パッケージをインストールしている。
1.8.6.2. Deployment Manager テンプレートの一般的な変数のエクスポート
ユーザーによって提供されるインフラストラクチャーのインストールを Google Cloud Platform (GCP) で実行するのに役立つ指定の Deployment Manager テンプレートで使用される一般的な変数のセットをエクスポートする必要があります。
特定の Deployment Manager テンプレートには、追加のエクスポートされる変数が必要になる場合があります。これについては、関連する手順で詳しく説明されています。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
- クラスターの Ignition 設定ファイルを生成します。
-
jq
パッケージをインストールします。
手順
提供される Deployment Manager テンプレートで使用される以下の一般的な変数をエクスポートします。
$ export BASE_DOMAIN='<base_domain>' $ export BASE_DOMAIN_ZONE_NAME='<base_domain_zone_name>' $ export NETWORK_CIDR='10.0.0.0/16' $ export MASTER_SUBNET_CIDR='10.0.0.0/19' $ export WORKER_SUBNET_CIDR='10.0.32.0/19' $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1 $ export CLUSTER_NAME=`jq -r .clusterName <installation_directory>/metadata.json` $ export INFRA_ID=`jq -r .infraID <installation_directory>/metadata.json` $ export PROJECT_NAME=`jq -r .gcp.projectID <installation_directory>/metadata.json` $ export REGION=`jq -r .gcp.region <installation_directory>/metadata.json`
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
1.8.7. GCP での VPC の作成
OpenShift Container Platform クラスターで使用する VPC を Google Cloud Platform (GCP) で作成する必要があります。各種の要件を満たすよう VPC をカスタマイズできます。VPC を作成する 1 つの方法として、提供されている Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
手順
-
本トピックの VPC の Deployment Manager テンプレートセクションを確認し、これを
01_vpc.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。 01_xvdb.yaml
リソース定義ファイルを作成します。$ cat <<EOF >01_vpc.yaml imports: - path: 01_vpc.py resources: - name: cluster-vpc type: 01_vpc.py properties: infra_id: '${INFRA_ID}' 1 region: '${REGION}' 2 master_subnet_cidr: '${MASTER_SUBNET_CIDR}' 3 worker_subnet_cidr: '${WORKER_SUBNET_CIDR}' 4 EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yaml
1.8.7.1. VPC の Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例1.1 01_vpc.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-network', 'type': 'compute.v1.network', 'properties': { 'region': context.properties['region'], 'autoCreateSubnetworks': False } }, { 'name': context.properties['infra_id'] + '-master-subnet', 'type': 'compute.v1.subnetwork', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'ipCidrRange': context.properties['master_subnet_cidr'] } }, { 'name': context.properties['infra_id'] + '-worker-subnet', 'type': 'compute.v1.subnetwork', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'ipCidrRange': context.properties['worker_subnet_cidr'] } }, { 'name': context.properties['infra_id'] + '-router', 'type': 'compute.v1.router', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'nats': [{ 'name': context.properties['infra_id'] + '-nat-master', 'natIpAllocateOption': 'AUTO_ONLY', 'minPortsPerVm': 7168, 'sourceSubnetworkIpRangesToNat': 'LIST_OF_SUBNETWORKS', 'subnetworks': [{ 'name': '$(ref.' + context.properties['infra_id'] + '-master-subnet.selfLink)', 'sourceIpRangesToNat': ['ALL_IP_RANGES'] }] }, { 'name': context.properties['infra_id'] + '-nat-worker', 'natIpAllocateOption': 'AUTO_ONLY', 'minPortsPerVm': 512, 'sourceSubnetworkIpRangesToNat': 'LIST_OF_SUBNETWORKS', 'subnetworks': [{ 'name': '$(ref.' + context.properties['infra_id'] + '-worker-subnet.selfLink)', 'sourceIpRangesToNat': ['ALL_IP_RANGES'] }] }] } }] return {'resources': resources}
1.8.8. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
のネットワークがマシン設定サーバーから Ignition 設定をフェッチする必要があります。
マシン間のネットワーク接続を、クラスターのコンポーネントが通信できるように設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
表1.28 すべてのマシンに対応するすべてのマシン
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN および Geneve |
| VXLAN および Geneve | |
|
ポート | |
TCP/UDP |
| Kubernetes ノードポート |
表1.29 コントロールプレーンへのすべてのマシン
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
表1.30 コントロールプレーンマシンへのコントロールプレーンマシン
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
ネットワークトポロジー要件
クラスター用にプロビジョニングするインフラストラクチャーは、ネットワークトポロジーの以下の要件を満たす必要があります。
OpenShift Container Platform では、すべてのノードが、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するためにインターネットへの直接のアクセスが必要です。
ロードバランサー
OpenShift Container Platform をインストールする前に、以下の要件を満たす 2 つのロードバランサーをプロビジョニングする必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、API ルートの Server Name Indication (SNI) を有効にする必要があります。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表1.31 API ロードバランサー
ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、Ingress ルートの Server Name Indication (SNI) を有効にする必要があります。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表1.32 アプリケーション Ingress ロードバランサー
ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress ルーター Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress ルーター Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
クライアントの実際の IP アドレスがロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。コントロールプレーンの初期化後に Ingress ルーターを設定する必要があります。
1.8.9. GCP でのロードバランサーの作成
OpenShift Container Platform クラスターで使用するロードバランシングを Google Cloud Platform (GCP) で設定する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して 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 CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)
クラスターが使用する 3 つのゾーンをエクスポートします。
$ export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)
$ export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)
$ export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)
02_infra.yaml
リソース定義ファイルを作成します。$ cat <<EOF >02_infra.yaml imports: - path: 02_lb_ext.py - path: 02_lb_int.py 1 resources: - name: cluster-lb-ext 2 type: 02_lb_ext.py properties: infra_id: '${INFRA_ID}' 3 region: '${REGION}' 4 - name: cluster-lb-int type: 02_lb_int.py properties: cluster_network: '${CLUSTER_NETWORK}' control_subnet: '${CONTROL_SUBNET}' 5 infra_id: '${INFRA_ID}' region: '${REGION}' zones: 6 - '${ZONE_0}' - '${ZONE_1}' - '${ZONE_2}' EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yaml
クラスター IP アドレスをエクスポートします。
$ export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)
外部クラスターの場合、クラスターのパブリック IP アドレスもエクスポートします。
$ export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)
1.8.9.1. 外部ロードバランサーの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な外部ロードバランサーをデプロイすることができます。
例1.2 02_lb_ext.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-cluster-public-ip', 'type': 'compute.v1.address', 'properties': { 'region': context.properties['region'] } }, { # Refer to docs/dev/kube-apiserver-health-check.md on how to correctly setup health check probe for kube-apiserver 'name': context.properties['infra_id'] + '-api-http-health-check', 'type': 'compute.v1.httpHealthCheck', 'properties': { 'port': 6080, 'requestPath': '/readyz' } }, { 'name': context.properties['infra_id'] + '-api-target-pool', 'type': 'compute.v1.targetPool', 'properties': { 'region': context.properties['region'], 'healthChecks': ['$(ref.' + context.properties['infra_id'] + '-api-http-health-check.selfLink)'], 'instances': [] } }, { 'name': context.properties['infra_id'] + '-api-forwarding-rule', 'type': 'compute.v1.forwardingRule', 'properties': { 'region': context.properties['region'], 'IPAddress': '$(ref.' + context.properties['infra_id'] + '-cluster-public-ip.selfLink)', 'target': '$(ref.' + context.properties['infra_id'] + '-api-target-pool.selfLink)', 'portRange': '6443' } }] return {'resources': resources}
1.8.9.2. 内部ロードバランサーの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な内部ロードバランサーをデプロイすることができます。
例1.3 02_lb_int.py
Deployment Manager テンプレート
def GenerateConfig(context): backends = [] for zone in context.properties['zones']: backends.append({ 'group': '$(ref.' + context.properties['infra_id'] + '-master-' + zone + '-instance-group' + '.selfLink)' }) resources = [{ 'name': context.properties['infra_id'] + '-cluster-ip', 'type': 'compute.v1.address', 'properties': { 'addressType': 'INTERNAL', 'region': context.properties['region'], 'subnetwork': context.properties['control_subnet'] } }, { # Refer to docs/dev/kube-apiserver-health-check.md on how to correctly setup health check probe for kube-apiserver 'name': context.properties['infra_id'] + '-api-internal-health-check', 'type': 'compute.v1.healthCheck', 'properties': { 'httpsHealthCheck': { 'port': 6443, 'requestPath': '/readyz' }, 'type': "HTTPS" } }, { 'name': context.properties['infra_id'] + '-api-internal-backend-service', 'type': 'compute.v1.regionBackendService', 'properties': { 'backends': backends, 'healthChecks': ['$(ref.' + context.properties['infra_id'] + '-api-internal-health-check.selfLink)'], 'loadBalancingScheme': 'INTERNAL', 'region': context.properties['region'], 'protocol': 'TCP', 'timeoutSec': 120 } }, { 'name': context.properties['infra_id'] + '-api-internal-forwarding-rule', 'type': 'compute.v1.forwardingRule', 'properties': { 'backendService': '$(ref.' + context.properties['infra_id'] + '-api-internal-backend-service.selfLink)', 'IPAddress': '$(ref.' + context.properties['infra_id'] + '-cluster-ip.selfLink)', 'loadBalancingScheme': 'INTERNAL', 'ports': ['6443','22623'], 'region': context.properties['region'], 'subnetwork': context.properties['control_subnet'] } }] for zone in context.properties['zones']: resources.append({ 'name': context.properties['infra_id'] + '-master-' + zone + '-instance-group', 'type': 'compute.v1.instanceGroup', 'properties': { 'namedPorts': [ { 'name': 'ignition', 'port': 22623 }, { 'name': 'https', 'port': 6443 } ], 'network': context.properties['cluster_network'], 'zone': zone } }) return {'resources': resources}
外部クラスターの作成時に、02_lb_ext.py
テンプレートに加えてこのテンプレートが必要になります。
1.8.10. GCP でのプライベート DNS ゾーンの作成
OpenShift Container Platform クラスターで使用するプライベート DNS ゾーンを Google Cloud Platform (GCP) で設定する必要があります。このコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
本トピックのプライベート DNS の Deployment Manager テンプレートセクションのテンプレートをコピーし、これを
02_dns.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なプライベート DNS オブジェクトについて記述しています。 02_dns.yaml
リソース定義ファイルを作成します。$ cat <<EOF >02_dns.yaml imports: - path: 02_dns.py resources: - name: cluster-dns type: 02_dns.py properties: infra_id: '${INFRA_ID}' 1 cluster_domain: '${CLUSTER_NAME}.${BASE_DOMAIN}' 2 cluster_network: '${CLUSTER_NETWORK}' 3 EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml
このテンプレートは 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
外部クラスターの場合、外部 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}
1.8.10.1. プライベート DNS の Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なプライベート DNS をデプロイすることができます。
例1.4 02_dns.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-private-zone', 'type': 'dns.v1.managedZone', 'properties': { 'description': '', 'dnsName': context.properties['cluster_domain'] + '.', 'visibility': 'private', 'privateVisibilityConfig': { 'networks': [{ 'networkUrl': context.properties['cluster_network'] }] } } }] return {'resources': resources}
1.8.11. GCP でのファイアウォールルールの作成
OpenShift Container Platform クラスターで使用するファイアウォールルールを Google Cloud Platform (GCP) で作成する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
本トピックのファイアウォールの Deployment Manager テンプレートセクションのテンプレートをコピーし、これを
03_firewall.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なセキュリティーグループについて記述しています。 03_firewall.yaml
リソース定義ファイルを作成します。$ cat <<EOF >03_firewall.yaml imports: - path: 03_firewall.py resources: - name: cluster-firewall type: 03_firewall.py properties: allowed_external_cidr: '0.0.0.0/0' 1 infra_id: '${INFRA_ID}' 2 cluster_network: '${CLUSTER_NETWORK}' 3 network_cidr: '${NETWORK_CIDR}' 4 EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml
1.8.11.1. ファイアウォールルール用の Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なファイアウォールルールをデプロイすることができます。
例1.5 03_firewall.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-bootstrap-in-ssh', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['22'] }], 'sourceRanges': [context.properties['allowed_external_cidr']], 'targetTags': [context.properties['infra_id'] + '-bootstrap'] } }, { 'name': context.properties['infra_id'] + '-api', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['6443'] }], 'sourceRanges': [context.properties['allowed_external_cidr']], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-health-checks', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['6080', '6443', '22624'] }], 'sourceRanges': ['35.191.0.0/16', '130.211.0.0/22', '209.85.152.0/22', '209.85.204.0/22'], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-etcd', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['2379-2380'] }], 'sourceTags': [context.properties['infra_id'] + '-master'], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-control-plane', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'tcp', 'ports': ['10257'] },{ 'IPProtocol': 'tcp', 'ports': ['10259'] },{ 'IPProtocol': 'tcp', 'ports': ['22623'] }], 'sourceTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ], 'targetTags': [context.properties['infra_id'] + '-master'] } }, { 'name': context.properties['infra_id'] + '-internal-network', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'icmp' },{ 'IPProtocol': 'tcp', 'ports': ['22'] }], 'sourceRanges': [context.properties['network_cidr']], 'targetTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ] } }, { 'name': context.properties['infra_id'] + '-internal-cluster', 'type': 'compute.v1.firewall', 'properties': { 'network': context.properties['cluster_network'], 'allowed': [{ 'IPProtocol': 'udp', 'ports': ['4789', '6081'] },{ 'IPProtocol': 'tcp', 'ports': ['9000-9999'] },{ 'IPProtocol': 'udp', 'ports': ['9000-9999'] },{ 'IPProtocol': 'tcp', 'ports': ['10250'] },{ 'IPProtocol': 'tcp', 'ports': ['30000-32767'] },{ 'IPProtocol': 'udp', 'ports': ['30000-32767'] }], 'sourceTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ], 'targetTags': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-worker' ] } }] return {'resources': resources}
1.8.12. GCP での IAM ロールの作成
OpenShift Container Platform クラスターで使用する IAM ロールを Google Cloud Platform (GCP) で作成する必要があります。これらのコンポーネントを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
手順
-
本トピックのIAM ロールの Deployment Manager テンプレートセクションのテンプレートをコピーし、これを
03_iam.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要な IAM ロールについて記述しています。 03_iam.yaml
リソース定義ファイルを作成します。$ cat <<EOF >03_iam.yaml imports: - path: 03_iam.py resources: - name: cluster-iam type: 03_iam.py properties: infra_id: '${INFRA_ID}' 1 EOF
- 1
infra_id
は抽出手順で得られるINFRA_ID
インフラストラクチャー名です。
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-iam --config 03_iam.yaml
マスターサービスアカウントの変数をエクスポートします。
$ export MASTER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-m@${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'`)
コンピュートマシンをホストするサブネットの変数をエクスポートします。
$ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)
このテンプレートは Deployment Manager の制限によりポリシーバインディングを作成しないため、これらを手動で作成する必要があります。
$ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.instanceAdmin" $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.networkAdmin" $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.securityAdmin" $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/iam.serviceAccountUser" $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/storage.admin" $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${WORKER_SERVICE_ACCOUNT}" --role "roles/compute.viewer" $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${WORKER_SERVICE_ACCOUNT}" --role "roles/storage.admin"
サービスアカウントキーを作成し、後で使用できるようにこれをローカルに保存します。
$ gcloud iam service-accounts keys create service-account-key.json --iam-account=${MASTER_SERVICE_ACCOUNT}
1.8.12.1. IAM ロールの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な IAM ロールをデプロイすることができます。
例1.6 03_iam.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-master-node-sa', 'type': 'iam.v1.serviceAccount', 'properties': { 'accountId': context.properties['infra_id'] + '-m', 'displayName': context.properties['infra_id'] + '-master-node' } }, { 'name': context.properties['infra_id'] + '-worker-node-sa', 'type': 'iam.v1.serviceAccount', 'properties': { 'accountId': context.properties['infra_id'] + '-w', 'displayName': context.properties['infra_id'] + '-worker-node' } }] return {'resources': resources}
1.8.13. GCP インフラストラクチャー用の RHCOS クラスターイメージの作成
OpenShift Container Platform ノードに Google Cloud Platform (GCP) 用の有効な 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>
RHCOS イメージを Google ストレージバケットにアップロードします。
$ gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz gs://<bucket_name>
アップロードした RHCOS イメージの場所を変数としてエクスポートします。
$ export IMAGE_SOURCE=`gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz`
クラスターイメージを作成します。
$ gcloud compute images create "${INFRA_ID}-rhcos-image" \ --source-uri="${IMAGE_SOURCE}"
1.8.14. GCP でのブートストラップマシンの作成
OpenShift Container Platform クラスターの初期化を実行する際に使用するブートストラップマシンを Google Cloud Platform (GCP) で作成する必要があります。このマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供されている Deployment Manager テンプレートを使用してブートストラップマシンを作成しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- 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`)
バケットを作成し、
bootstrap.ign
ファイルをアップロードします。$ gsutil mb gs://${INFRA_ID}-bootstrap-ignition $ gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/
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}'`
04_bootstrap.yaml
リソース定義ファイルを作成します。$ cat <<EOF >04_bootstrap.yaml imports: - path: 04_bootstrap.py resources: - name: cluster-bootstrap type: 04_bootstrap.py properties: infra_id: '${INFRA_ID}' 1 region: '${REGION}' 2 zone: '${ZONE_0}' 3 cluster_network: '${CLUSTER_NETWORK}' 4 control_subnet: '${CONTROL_SUBNET}' 5 image: '${CLUSTER_IMAGE}' 6 machine_type: 'n1-standard-4' 7 root_volume_size: '128' 8 bootstrap_ign: '${BOOTSTRAP_IGN}' 9 EOF
- 1
infra_id
は抽出手順で得られるINFRA_ID
インフラストラクチャー名です。- 2
region
はクラスターをデプロイするリージョンです (例:us-central1
)。- 3
zone
はブートストラップインスタンスをデプロイするゾーンです (例:us-central1-b
)。- 4
cluster_network
はクラスターネットワークのselfLink
URL です。- 5
control_subnet
は、コントロールサブセットのselfLink
URL です。- 6
image
は RHCOS イメージのselfLink
URL です。- 7
machine_type
はインスタンスのマシンタイプです (例:n1-standard-4
)。- 8
root_volume_size
はブートストラップマシンのブートディスクサイズです。- 9
bootstrap_ign
は署名付き URL の作成時の URL 出力です。
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yaml
Deployment Manager の制限によりテンプレートではロードバランサーのメンバーシップを管理しないため、ブートストラップマシンは手動で追加する必要があります。
ブートストラップインスタンスを内部ロードバランサーのインスタンスグループに追加します。
$ gcloud compute instance-groups unmanaged add-instances \ ${INFRA_ID}-bootstrap-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrap
ブートストラップインスタンスグループを内部ロードバランサーのバックエンドサービスに追加します。
$ gcloud compute backend-services add-backend \ ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0}
1.8.14.1. ブートストラップマシンの Deployment Manager テンプレート
以下の Deployment Mananger テンプレートを使用し、OpenShift Container Platform クラスターに必要なブートストラップマシンをデプロイすることができます。
例1.7 04_bootstrap.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-bootstrap-public-ip', 'type': 'compute.v1.address', 'properties': { 'region': context.properties['region'] } }, { 'name': context.properties['infra_id'] + '-bootstrap', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zone'] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': '{"ignition":{"config":{"replace":{"source":"' + context.properties['bootstrap_ign'] + '"}},"version":"3.1.0"}}', }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'], 'accessConfigs': [{ 'natIP': '$(ref.' + context.properties['infra_id'] + '-bootstrap-public-ip.address)' }] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', context.properties['infra_id'] + '-bootstrap' ] }, 'zone': context.properties['zone'] } }, { 'name': context.properties['infra_id'] + '-bootstrap-instance-group', 'type': 'compute.v1.instanceGroup', 'properties': { 'namedPorts': [ { 'name': 'ignition', 'port': 22623 }, { 'name': 'https', 'port': 6443 } ], 'network': context.properties['cluster_network'], 'zone': context.properties['zone'] } }] return {'resources': resources}
1.8.15. GCP でのコントロールプレーンマシンの作成
クラスターで使用するコントロールプレーンマシンを Google Cloud Platform (GCP) で作成する必要があります。これらのマシンを作成する方法として、提供される Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用してコントロールプレーンマシンを使用しない場合、指定される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
手順
-
本トピックのコントロールプレーンマシンの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを
05_control_plane.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンについて記述しています。 リソース定義で必要な以下の変数をエクスポートします。
$ export MASTER_IGNITION=`cat <installation_directory>/master.ign`
05_control_plane.yaml
リソース定義ファイルを作成します。$ cat <<EOF >05_control_plane.yaml imports: - path: 05_control_plane.py resources: - name: cluster-control-plane type: 05_control_plane.py properties: infra_id: '${INFRA_ID}' 1 zones: 2 - '${ZONE_0}' - '${ZONE_1}' - '${ZONE_2}' control_subnet: '${CONTROL_SUBNET}' 3 image: '${CLUSTER_IMAGE}' 4 machine_type: 'n1-standard-4' 5 root_volume_size: '128' service_account_email: '${MASTER_SERVICE_ACCOUNT}' 6 ignition: '${MASTER_IGNITION}' 7 EOF
- 1
infra_id
は抽出手順で得られるINFRA_ID
インフラストラクチャー名です。- 2
zones
は、コントロールプレーンインスタンスをデプロイするゾーンです (例:us-central1-a
、us-central1-b
、およびus-central1-c
)。- 3
control_subnet
は、コントロールサブセットのselfLink
URL です。- 4
image
は RHCOS イメージのselfLink
URL です。- 5
machine_type
はインスタンスのマシンタイプです (例:n1-standard-4
)。- 6
service_account_email
は作成したマスターサービスアカウントのメールアドレスです。- 7
ignition
はmaster.ign
ファイルの内容です。
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yaml
Deployment Manager の制限により、テンプレートではロードバランサーのメンバーシップを管理しないため、コントロールプレーンマシンを手動で追加する必要があります。
以下のコマンドを実行してコントロールプレーンマシンを適切なインスタンスグループに追加します。
$ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-master-0 $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-instance-group --zone=${ZONE_1} --instances=${INFRA_ID}-master-1 $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-instance-group --zone=${ZONE_2} --instances=${INFRA_ID}-master-2
外部クラスターの場合、以下のコマンドを実行してコントロールプレーンマシンをターゲットプールに追加する必要もあります。
$ 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_1}" --instances=${INFRA_ID}-master-1 $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2
1.8.15.1. コントロールプレーンマシンの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要なコントロールプレーンマシンをデプロイすることができます。
例1.8 05_control_plane.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-master-0', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'diskType': 'zones/' + context.properties['zones'][0] + '/diskTypes/pd-ssd', 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zones'][0] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', ] }, 'zone': context.properties['zones'][0] } }, { 'name': context.properties['infra_id'] + '-master-1', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'diskType': 'zones/' + context.properties['zones'][1] + '/diskTypes/pd-ssd', 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zones'][1] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', ] }, 'zone': context.properties['zones'][1] } }, { 'name': context.properties['infra_id'] + '-master-2', 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'diskType': 'zones/' + context.properties['zones'][2] + '/diskTypes/pd-ssd', 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zones'][2] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['control_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-master', ] }, 'zone': context.properties['zones'][2] } }] return {'resources': resources}
1.8.16. ブートストラップの完了を待機し、GCP のブートストラップリソースを削除する
Google Cloud Platform (GCP) ですべての必要なインフラストラクチャーを作成した後に、ブートストラッププロセスが、インストールプログラムで生成した Ignition 設定ファイルを使用してプロビジョニングしたマシンで完了するのを待機します。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
手順
インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ 1 --log-level info 2
コマンドが
FATAL
警告を出さずに終了する場合、実稼働用のコントロールプレーンは初期化されています。ブートストラップリソースを削除します。
$ gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0} $ gsutil rm gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign $ gsutil rb gs://${INFRA_ID}-bootstrap-ignition $ gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrap
1.8.17. GCP での追加のワーカーマシンの作成
Google Cloud Platform (GCP) でクラスターが使用するワーカーマシンを作成するには、それぞれのインスタンスを個別に起動するか、または自動スケーリンググループなどのクラスター外にある自動プロセスを実行します。OpenShift Container Platform の組み込まれたクラスタースケーリングメカニズムやマシン API を利用できます。
この例では、Deployment Manager テンプレートを使用して 1 つのインスタンスを手動で起動します。追加のインスタンスは、ファイル内に 06_worker.py
というタイプのリソースを追加して起動することができます。
ワーカーマシンを使用するために提供される Deployment Manager テンプレートを使用しない場合は、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
- クラスターの Ignition 設定ファイルを生成します。
- GCP で VPC および関連するサブネットを作成し、設定します。
- GCP でネットワークおよびロードバランサーを作成し、設定します。
- コントロールプレーンおよびコンピュートロールを作成します。
- ブートストラップマシンを作成します。
- コントロールプレーンマシンを作成します。
手順
-
本トピックのワーカーマシンの 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 WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)
コンピュートマシンの Ignition 設定ファイルの場所をエクスポートします。
$ export WORKER_IGNITION=`cat <installation_directory>/worker.ign`
06_worker.yaml
リソース定義ファイルを作成します。$ cat <<EOF >06_worker.yaml imports: - path: 06_worker.py resources: - name: 'worker-0' 1 type: 06_worker.py properties: infra_id: '${INFRA_ID}' 2 zone: '${ZONE_0}' 3 compute_subnet: '${COMPUTE_SUBNET}' 4 image: '${CLUSTER_IMAGE}' 5 machine_type: 'n1-standard-4' 6 root_volume_size: '128' service_account_email: '${WORKER_SERVICE_ACCOUNT}' 7 ignition: '${WORKER_IGNITION}' 8 - name: 'worker-1' type: 06_worker.py properties: infra_id: '${INFRA_ID}' 9 zone: '${ZONE_1}' 10 compute_subnet: '${COMPUTE_SUBNET}' 11 image: '${CLUSTER_IMAGE}' 12 machine_type: 'n1-standard-4' 13 root_volume_size: '128' service_account_email: '${WORKER_SERVICE_ACCOUNT}' 14 ignition: '${WORKER_IGNITION}' 15 EOF
- 1
name
はワーカーマシンの名前です (例:worker-0
)。- 2 9
infra_id
は抽出手順で得られるINFRA_ID
インフラストラクチャー名です。- 3 10
zone
はワーカーマシンをデプロイするゾーンです (例:us-central1-a
)。- 4 11
compute_subnet
はコンピュートサブネットのselfLink
URL です。- 5 12
image
は RHCOS イメージのselfLink
URL です。- 6 13
machine_type
はインスタンスのマシンタイプです (例:n1-standard-4
)。- 7 14
service_account_email
は作成したワーカーサービスアカウントのメールアドレスです。- 8 15
Ignition
はworker.ign
ファイルの内容です。
-
オプション: 追加のインスタンスを起動する必要がある場合には、
06_worker.py
タイプの追加のリソースを06_worker.yaml
リソース定義ファイルに組み込みます。 gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yaml
1.8.17.1. ワーカーマシンの Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用し、OpenShift Container Platform クラスターに必要なワーカーマシンをデプロイすることができます。
例1.9 06_worker.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-' + context.env['name'], 'type': 'compute.v1.instance', 'properties': { 'disks': [{ 'autoDelete': True, 'boot': True, 'initializeParams': { 'diskSizeGb': context.properties['root_volume_size'], 'sourceImage': context.properties['image'] } }], 'machineType': 'zones/' + context.properties['zone'] + '/machineTypes/' + context.properties['machine_type'], 'metadata': { 'items': [{ 'key': 'user-data', 'value': context.properties['ignition'] }] }, 'networkInterfaces': [{ 'subnetwork': context.properties['compute_subnet'] }], 'serviceAccounts': [{ 'email': context.properties['service_account_email'], 'scopes': ['https://www.googleapis.com/auth/cloud-platform'] }], 'tags': { 'items': [ context.properties['infra_id'] + '-worker', ] }, 'zone': context.properties['zone'] } }] return {'resources': resources}
1.8.18. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.6 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
1.8.18.1. Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.8.18.2. Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
1.8.18.3. macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.6 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
1.8.19. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
1.8.20. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、または必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
クラスターがマシンを認識していることを確認します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.19.0 master-1 Ready master 63m v1.19.0 master-2 Ready master 64m v1.19.0
出力には作成したすべてのマシンが一覧表示されます。
注記上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。
保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に
Pending
またはApproved
ステータスが表示されていることを確認します。$ oc get csr
出力例
NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。
追加したマシンの保留中の CSR すべてが
Pending
ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認されたら、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要です。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に
machine-approver
によって自動的に承認されます。注記ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、
oc exec
、oc rsh
、およびoc logs
コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR がsystem:node
またはsystem:admin
グループのnode-bootstrapper
サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR の一覧からの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
注記一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。
クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。
$ oc get csr
出力例
NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...
残りの CSR が承認されず、それらが
Pending
ステータスにある場合、クラスターマシンの CSR を承認します。それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。
$ oc adm certificate approve <csr_name> 1
- 1
<csr_name>
は、現行の CSR の一覧からの CSR の名前です。
すべての保留中の CSR を承認するには、以下のコマンドを実行します。
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが
Ready
になります。以下のコマンドを実行して、これを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION master-0 Ready master 73m v1.20.0 master-1 Ready master 73m v1.20.0 master-2 Ready master 74m v1.20.0 worker-0 Ready worker 11m v1.20.0 worker-1 Ready worker 11m v1.20.0
注記サーバー CSR の承認後にマシンが
Ready
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
1.8.21. オプション: 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
出力例
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
A レコードをゾーンに追加します。
A レコードを使用するには、以下を実行します。
ルーター IP アドレスの変数をエクスポートします。
$ export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`
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
また、外部クラスターの場合は、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}
ワイルドカードを使用する代わりに明示的なドメインを追加するには、クラスターのそれぞれの現行ルートのエントリーを作成します。
$ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes
出力例
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 grafana-openshift-monitoring.apps.your.cluster.domain.example.com prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.com
1.8.22. ユーザーによってプロビジョニングされるインフラストラクチャーでの GCP インストールの完了
Google Cloud Platform (GCP) のユーザーによってプロビジョニングされるインフラストラクチャーで OpenShift Container Platform のインストールを開始した後は、クラスターが準備状態になるまでクラスターのイベントをモニターできます。
前提条件
- OpenShift Container Platform クラスターのブートストラップマシンを、ユーザーによってプロビジョニングされる GCP インフラストラクチャーにデプロイします。
-
oc
CLI をインストールし、ログインします。
手順
クラスターのインストールを完了します。
$ ./openshift-install --dir <installation_directory> wait-for install-complete 1
出力例
INFO Waiting up to 30m0s for the cluster to initialize...
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
クラスターの稼働状態を確認します。
以下のコマンドを実行し、現在のクラスターバージョンとステータスを表示します。
$ oc get clusterversion
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version False True 24m Working towards 4.5.4: 99% complete
以下のコマンドを実行し、 Cluster Version Operator (CVO) を使用してコントロールプレーンで管理される Operator を表示します。
$ oc get clusteroperators
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.5.4 True False False 7m56s cloud-credential 4.5.4 True False False 31m cluster-autoscaler 4.5.4 True False False 16m console 4.5.4 True False False 10m csi-snapshot-controller 4.5.4 True False False 16m dns 4.5.4 True False False 22m etcd 4.5.4 False False False 25s image-registry 4.5.4 True False False 16m ingress 4.5.4 True False False 16m insights 4.5.4 True False False 17m kube-apiserver 4.5.4 True False False 19m kube-controller-manager 4.5.4 True False False 20m kube-scheduler 4.5.4 True False False 20m kube-storage-version-migrator 4.5.4 True False False 16m machine-api 4.5.4 True False False 22m machine-config 4.5.4 True False False 22m marketplace 4.5.4 True False False 16m monitoring 4.5.4 True False False 10m network 4.5.4 True False False 23m node-tuning 4.5.4 True False False 23m openshift-apiserver 4.5.4 True False False 17m openshift-controller-manager 4.5.4 True False False 15m openshift-samples 4.5.4 True False False 16m operator-lifecycle-manager 4.5.4 True False False 22m operator-lifecycle-manager-catalog 4.5.4 True False False 22m operator-lifecycle-manager-packageserver 4.5.4 True False False 18m service-ca 4.5.4 True False False 23m service-catalog-apiserver 4.5.4 True False False 23m service-catalog-controller-manager 4.5.4 True False False 23m storage 4.5.4 True False False 17m
以下のコマンドを実行して、クラスター Pod を表示します。
$ oc get pods --all-namespaces
出力例
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system etcd-member-ip-10-0-3-111.us-east-2.compute.internal 1/1 Running 0 35m kube-system etcd-member-ip-10-0-3-239.us-east-2.compute.internal 1/1 Running 0 37m kube-system etcd-member-ip-10-0-3-24.us-east-2.compute.internal 1/1 Running 0 35m openshift-apiserver-operator openshift-apiserver-operator-6d6674f4f4-h7t2t 1/1 Running 1 37m openshift-apiserver apiserver-fm48r 1/1 Running 0 30m openshift-apiserver apiserver-fxkvv 1/1 Running 0 29m openshift-apiserver apiserver-q85nm 1/1 Running 0 29m ... openshift-service-ca-operator openshift-service-ca-operator-66ff6dc6cd-9r257 1/1 Running 0 37m openshift-service-ca apiservice-cabundle-injector-695b6bcbc-cl5hm 1/1 Running 0 35m openshift-service-ca configmap-cabundle-injector-8498544d7-25qn6 1/1 Running 0 35m openshift-service-ca service-serving-cert-signer-6445fc9c6-wqdqn 1/1 Running 0 35m openshift-service-catalog-apiserver-operator openshift-service-catalog-apiserver-operator-549f44668b-b5q2w 1/1 Running 0 32m openshift-service-catalog-controller-manager-operator openshift-service-catalog-controller-manager-operator-b78cr2lnm 1/1 Running 0 31m
現在のクラスターバージョンが
AVAILABLE
の場合、インストールが完了します。
1.8.23. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.6 では、クラスターのヘルスと更新の成功に関するメトリクスを提供するためにデフォルトで実行される Telemetry サービスには、インターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリング について参照してください。
1.8.24. 次のステップ
- クラスターをカスタマイズ します。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
1.9. Deployment Manager テンプレートを使用した GCP の共有 VPC へのクラスターのインストール
OpenShift Container Platform バージョン 4.6 では、プロビジョニングするインフラストラクチャーを使用するクラスターを Google Cloud Platform (GCP) の共有 VPC (Virtual Private Clous) にインストールできます。この場合、共有 VPC にインストールされたクラスターは、クラスターがデプロイされる場所とは異なるプロジェクトから VPC を使用するように設定されるクラスターです。
共有 VPC により、組織は複数のプロジェクトから共通の VPC ネットワークにリソースを接続できるようになります。対象のネットワークの内部 IP を使用して、組織内の通信を安全かつ効率的に実行できます。共有 VPC の詳細は、GCP ドキュメントの Shared VPC overview を参照してください。
以下に、ユーザーによって提供されるインフラストラクチャーの共有 VPC へのインストールを実行する手順を要約します。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。
ユーザーによってプロビジョニングされるインフラストラクチャーのインストールする手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、クラウドプロバイダーおよび OpenShift Container Platform のインストールプロセスについて理解している必要があります。これらの手順を実行するか、独自の手順を作成するのに役立つ複数の Deployment Manager テンプレートが提供されます。他の方法を使用して必要なリソースを作成することもできます。これらのテンプレートはサンプルとしてのみ提供されます。
1.9.1. 前提条件
- OpenShift Container Platform のインストールおよび更新 プロセスについての詳細を確認します。
- ファイアウォールを使用し、Telemetry を使用する予定がある場合は、クラスターがアクセスする必要のある サイトを許可するようにファイアウォールを設定 する必要があります。
システムが IAM(アイデンティティーおよびアクセス管理) を管理できない場合、クラスター管理者は IAM 認証情報を手動で作成し、維持 できます。手動モードは、クラウド IAM API に到達できない環境でも使用できます。
注記プロキシーを設定する場合は、このサイト一覧も確認してください。
1.9.2. 証明書署名要求の管理
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
1.9.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.6 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
1.9.4. クラスターをホストする GCP プロジェクトの設定
OpenShift Container Platform をインストールする前に、これをホストするように Google Cloud Platform (GCP) プロジェクトを設定する必要があります。
1.9.4.1. GCP プロジェクトの作成
OpenShift Container Platform をインストールするには、クラスターをホストするために Google Cloud Platform (GCP) アカウントでプロジェクトを作成する必要があります。
手順
OpenShift Container Platform クラスターをホストするプロジェクトを作成します。GCP ドキュメントの プロジェクトの作成と管理 を参照してください。
重要GCP プロジェクトは、インストーラーでプロビジョニングされるインフラストラクチャーを使用している場合には、Premium Network Service 階層を使用する必要があります。インストールプログラムを使用してインストールしたクラスターでは、Standard Network Service 階層はサポートされません。インストールプログラムは、
api-int.<cluster_name>.<base_domain>
の内部負荷分散を設定します。内部負荷分散には Premium Tier が必要です。
1.9.4.2. GCP での API サービスの有効化
Google Cloud Platform (GCP) プロジェクトでは、OpenShift Container Platform インストールを完了するために複数の API サービスへのアクセスが必要です。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
クラスターをホストするプロジェクトで以下の必要な API サービスを有効にします。GCP ドキュメントの サービスの有効化 を参照してください。
表1.33 必要な API サービス
API サービス コンソールサービス名 Cloud Deployment Manager V2 API
deploymentmanager.googleapis.com
Compute Engine API
compute.googleapis.com
Google Cloud API
cloudapis.googleapis.com
Cloud Resource Manager API
cloudresourcemanager.googleapis.com
Google DNS API
dns.googleapis.com
IAM Service Account Credentials API
iamcredentials.googleapis.com
Identity and Access Management (IAM) API
iam.googleapis.com
Service Management API
servicemanagement.googleapis.com
Service Usage API
serviceusage.googleapis.com
Google Cloud Storage JSON API
storage-api.googleapis.com
Cloud Storage
storage-component.googleapis.com
1.9.4.3. GCP アカウントの制限
OpenShift Container Platform クラスターは多くの Google Cloud Platform (GCP) コンポーネントを使用しますが、デフォルトの 割り当て (Quota) はデフォルトの OpenShift Container Platform クラスターをインストールする機能に影響を与えません。
3 つのコンピュートマシンおよび 3 つのコントロールプレーンマシンが含まれるデフォルトクラスターは以下のリソースを使用します。一部のリソースはブートストラッププロセス時にのみ必要となり、クラスターのデプロイ後に削除されることに注意してください。
表1.34 デフォルトのクラスターで使用される GCP リソース
サービス | コンポーネント | 場所 | 必要なリソースの合計 | ブートストラップ後に削除されるリソース |
---|---|---|---|---|
サービスアカウント | IAM | グローバル | 5 | 0 |
ファイアウォールのルール | ネットワーク | グローバル | 11 | 1 |
転送ルール | コンピュート | グローバル | 2 | 0 |
ヘルスチェック | コンピュート | グローバル | 2 | 0 |
イメージ | コンピュート | グローバル | 1 | 0 |
ネットワーク | ネットワーク | グローバル | 1 | 0 |
ルーター | ネットワーク | グローバル | 1 | 0 |
ルート | ネットワーク | グローバル | 2 | 0 |
サブネットワーク | コンピュート | グローバル | 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
GCP コンソール からリソースクォータを増やすことは可能ですが、サポートチケットを作成する必要がある場合があります。OpenShift Container Platform クラスターをインストールする前にサポートチケットを解決できるように、クラスターのサイズを早期に計画してください。
1.9.4.4. GCP でのサービスアカウントの作成
OpenShift Container Platform には、Google API でデータにアクセスするための認証および承認を提供する Google Cloud Platform (GCP) サービスアカウントが必要です。プロジェクトに必要なロールが含まれる既存の IAM サービスアカウントがない場合は、これを作成する必要があります。
前提条件
- クラスターをホストするプロジェクトを作成しています。
手順
- OpenShift Container Platform クラスターをホストするために使用するプロジェクトでサービスアカウントを作成します。GCP ドキュメントで サービスアカウントの作成 を参照してください。
サービスアカウントに適切なパーミッションを付与します。付随する個別のパーミッションを付与したり、
オーナー
ロールをこれに割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることが必要なパーミッションを取得する最も簡単な方法になります。 つまりこれは、サービスアカウントはプロジェクトを完全に制御できることを意味します。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
JSON 形式でサービスアカウントキーを作成します。GCP ドキュメントの サービスアカウントキーの作成 を参照してください。
クラスターを作成するには、サービスアカウントキーが必要になります。
1.9.4.4.1. 必要な GCP パーミッション
作成するサービスアカウントに オーナー
ロールを割り当てると、OpenShift Container Platform のインストールに必要なパーミッションも含め、そのサービスアカウントにすべてのパーミッションが付与されます。OpenShift Container Platform クラスターをデプロイするには、サービスアカウントに以下のパーミッションが必要です。クラスターを既存の VPC にデプロイする場合、サービスアカウントでは一部のネットワークのパーミッションを必要としません。これについては、以下の一覧に記載されています。
インストールプログラムに必要なロール
- Compute 管理者
- セキュリティー管理者
- サービスアカウント管理者
- サービスアカウントユーザー
- ストレージ管理者
インストール時のネットワークリソースの作成に必要なロール
- DNS 管理者
ユーザーによってプロビジョニングされる GCP インフラストラクチャーに必要なロール
- Deployment Manager Editor
- サービスアカウントキー管理者
オプションのロール
クラスターで Operator の制限された認証情報を新たに作成できるようにするには、以下のロールを追加します。
- サービスアカウントキー管理者
ロールは、コントロールプレーンおよびコンピュートマシンが使用するサービスアカウントに適用されます。
表1.35 GCP サービスアカウントのパーミッション
アカウント | ロール |
---|---|
コントロールプレーン |
|
| |
| |
| |
| |
コンピュート |
|
|
1.9.4.5. サポートされている GCP リージョン
OpenShift Container Platform クラスターを以下の Google Cloud Platform (GCP) リージョンにデプロイできます。
-
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-southeast1
(Jurong West, Singapore) -
asia-southeast2
(Jakarta, Indonesia) -
australia-southeast1
(Sydney, Australia) -
europe-north1
(Hamina, Finland) -
europe-west1
(St. Ghislain, Belgium) -
europe-west2
(London, England, UK) -
europe-west3
(Frankfurt, Germany) -
europe-west4
(Eemshaven, Netherlands) -
europe-west6
(Zürich, Switzerland) -
northamerica-northeast1
(Montréal, Québec, Canada) -
southamerica-east1
(São Paulo, Brazil) -
us-central1
(Council Bluffs, Iowa, USA) -
us-east1
(Moncks Corner, South Carolina, USA) -
us-east4
(Ashburn, Northern Virginia, USA) -
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)
1.9.4.6. GCP の CLI ツールのインストールおよび設定
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Google Cloud Platform (GCP) に OpenShift Container Platform をインストールするには、GCP の CLI ツールをインストールし、設定する必要があります。
前提条件
- クラスターをホストするプロジェクトを作成しています。
- サービスアカウントを作成し、これに必要なパーミッションを付与しています。
手順
$PATH
で以下のバイナリーをインストールします。-
gcloud
-
gsutil
GCP ドキュメントの Google Cloud SDK のドキュメント を参照してください。
-
設定したサービスアカウントで、
gcloud
ツールを使用して認証します。GCP ドキュメントで、サービスアカウントでの認証 について参照してください。
1.9.5. 共有 VPC ネットワークをホストする GCP プロジェクトの設定
共有 VPC (Virtual Private Cloud) を使用して Google Cloud Platform (GCP) で OpenShift Container Platform クラスターをホストする場合、これをホストするプロジェクトを設定する必要があります。
共有 VPC ネットワークをホストするプロジェクトがすでにある場合は、本セクションを参照して、プロジェクトが OpenShift Container Platform クラスターのインストールに必要なすべての要件を満たすことを確認します。
手順
- OpenShift Container Platform クラスターの共有 VPC をホストするプロジェクトを作成します。GCP ドキュメントの プロジェクトの作成と管理 を参照してください。
- 共有 VPC をホストするプロジェクトでサービスアカウントを作成します。GCP ドキュメントで サービスアカウントの作成 を参照してください。
サービスアカウントに適切なパーミッションを付与します。付随する個別のパーミッションを付与したり、
オーナー
ロールをこれに割り当てることができます。特定のリソースのサービスアカウントへのロールの付与 を参照してください。注記サービスアカウントをプロジェクトの所有者にすることが必要なパーミッションを取得する最も簡単な方法になります。 つまりこれは、サービスアカウントはプロジェクトを完全に制御できることを意味します。この権限を提供することに伴うリスクが受け入れ可能であるかどうかを判別する必要があります。
共有 VPC ネットワークをホストするプロジェクトのサービスアカウントには以下のロールが必要です。
- コンピュートネットワークユーザー
- コンピュートセキュリティー管理者
- Deployment Manager Editor
- DNS 管理者
- セキュリティー管理者
- ネットワーク管理者
1.9.5.1. GCP の DNS の設定
OpenShift Container Platform をインストールするには、使用する Google Cloud Platform (GCP) アカウントに、クラスターをインストールする共有 VPC をホストするプロジェクトに専用のパブリックホストゾーンがなければなりません。このゾーンはドメインに対する権威を持っている必要があります。DNS サービスは、クラスターへの外部接続のためのクラスターの DNS 解決および名前検索を提供します。
手順
ドメイン、またはサブドメイン、およびレジストラーを特定します。既存のドメインおよびレジストラーを移行するか、GCP または他のソースから新規のものを取得できます。
注記新規ドメインを購入する場合、関連する DNS の変更が伝播するのに時間がかかる場合があります。Google 経由でドメインを購入する方法についての詳細は、 Google ドメイン を参照してください。
GCP プロジェクトにドメインまたはサブドメインのパブリックホストゾーンを作成します。GCP ドキュメントの ゾーンの管理 を参照してください。
openshiftcorp.com
などのルートドメインや、clusters.openshiftcorp.com
などのサブドメインを使用します。ホストゾーンレコードから新規の権威ネームサーバーを抽出します。GCP ドキュメントの Cloud DNS ネームサーバーを検索する を参照してください。
通常は、4 つのネームサーバーがあります。
- ドメインが使用するネームサーバーのレジストラーレコードを更新します。たとえば、ドメインを Google ドメインに登録している場合は、Google Domains Help で How to switch to custom name servers のトピックを参照してください。
- ルートドメインを Google Cloud DNS に移行している場合は、DNS レコードを移行します。GCP ドキュメントの Cloud DNS への移行 を参照してください。
- サブドメインを使用する場合は、所属する会社の手順に従ってその委任レコードを親ドメインに追加します。このプロセスには、所属企業の IT 部門や、会社のルートドメインと DNS サービスを制御する部門へのリクエストが含まれる場合があります。
1.9.5.2. GCP での VPC の作成
OpenShift Container Platform クラスターで使用する VPC を Google Cloud Platform (GCP) で作成する必要があります。各種の要件を満たすよう VPC をカスタマイズできます。VPC を作成する 1 つの方法として、提供されている Deployment Manager テンプレートを変更することができます。
提供される Deployment Manager テンプレートを使用して GCP インフラストラクチャーを使用しない場合、提供される情報を確認し、インフラストラクチャーを手動で作成する必要があります。クラスターが適切に初期化されない場合、インストールログを用意して Red Hat サポートに問い合わせする必要がある可能性があります。
前提条件
- GCP アカウントを設定します。
手順
-
本トピックの VPC の Deployment Manager テンプレートセクションを確認し、これを
01_vpc.py
としてコンピューターに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。 リソース定義で必要な以下の変数をエクスポートします。
コントロールプレーンの CIDR をエクスポートします。
$ export MASTER_SUBNET_CIDR='10.0.0.0/19'
コンピュート CIDR をエクスポートします。
$ export WORKER_SUBNET_CIDR='10.0.32.0/19'
VPC ネットワークおよびクラスターをデプロイするリージョンを以下にエクスポートします。
$ export REGION='<region>'
共有 VPC をホストするプロジェクトの ID の変数をエクスポートします。
$ export HOST_PROJECT=<host_project>
ホストプロジェクトに属するサービスアカウントのメールの変数をエクスポートします。
$ export HOST_PROJECT_ACCOUNT=<host_service_account_email>
01_xvdb.yaml
リソース定義ファイルを作成します。$ cat <<EOF >01_vpc.yaml imports: - path: 01_vpc.py resources: - name: cluster-vpc type: 01_vpc.py properties: infra_id: '<prefix>' 1 region: '${REGION}' 2 master_subnet_cidr: '${MASTER_SUBNET_CIDR}' 3 worker_subnet_cidr: '${WORKER_SUBNET_CIDR}' 4 EOF
gcloud
CLI を使用してデプロイメントを作成します。$ gcloud deployment-manager deployments create <vpc_deployment_name> --config 01_vpc.yaml --project ${HOST_PROJECT} --account ${HOST_PROJECT_ACCOUNT} 1
- 1
<vpc_deployment_name>
には、デプロイする VPC の名前を指定します。
他のコンポーネントが必要とする VPC 変数をエクスポートします。
ホストプロジェクトネットワークの名前をエクスポートします。
$ export HOST_PROJECT_NETWORK=<vpc_network>
ホストプロジェクトのコントロールプレーンのサブネットの名前をエクスポートします。
$ export HOST_PROJECT_CONTROL_SUBNET=<control_plane_subnet>
ホストプロジェクトのコンピュートサブネットの名前をエクスポートします。
$ export HOST_PROJECT_COMPUTE_SUBNET=<compute_subnet>
- 共有 VPC を設定します。GCP ドキュメントの 共有 VPC の設定 を参照してください。
1.9.5.2.1. VPC の Deployment Manager テンプレート
以下の Deployment Manager テンプレートを使用して、OpenShift Container Platform クラスターに必要な VPC をデプロイすることができます。
例1.10 01_vpc.py
Deployment Manager テンプレート
def GenerateConfig(context): resources = [{ 'name': context.properties['infra_id'] + '-network', 'type': 'compute.v1.network', 'properties': { 'region': context.properties['region'], 'autoCreateSubnetworks': False } }, { 'name': context.properties['infra_id'] + '-master-subnet', 'type': 'compute.v1.subnetwork', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'ipCidrRange': context.properties['master_subnet_cidr'] } }, { 'name': context.properties['infra_id'] + '-worker-subnet', 'type': 'compute.v1.subnetwork', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'ipCidrRange': context.properties['worker_subnet_cidr'] } }, { 'name': context.properties['infra_id'] + '-router', 'type': 'compute.v1.router', 'properties': { 'region': context.properties['region'], 'network': '$(ref.' + context.properties['infra_id'] + '-network.selfLink)', 'nats': [{ 'name': context.properties['infra_id'] + '-nat-master', 'natIpAllocateOption': 'AUTO_ONLY', 'minPortsPerVm': 7168, 'sourceSubnetworkIpRangesToNat': 'LIST_OF_SUBNETWORKS', 'subnetworks': [{ 'name': '$(ref.' + context.properties['infra_id'] + '-master-subnet.selfLink)', 'sourceIpRangesToNat': ['ALL_IP_RANGES'] }] }, { 'name': context.properties['infra_id'] + '-nat-worker', 'natIpAllocateOption': 'AUTO_ONLY', 'minPortsPerVm': 512, 'sourceSubnetworkIpRangesToNat': 'LIST_OF_SUBNETWORKS', 'subnetworks': [{ 'name': '$(ref.' + context.properties['infra_id'] + '-worker-subnet.selfLink)', 'sourceIpRangesToNat': ['ALL_IP_RANGES'] }] }] } }] return {'resources': resources}
1.9.6. GCP のインストール設定ファイルの作成
ユーザーによってプロビジョニングされるインフラストラクチャーを使用して OpenShift Container Platform を Google Cloud Platform (GCP) にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml
ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var
パーティションを設定するオプションもあります。
1.9.6.1. インストール設定ファイルの手動作成
ユーザーによってプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform のインストールでは、インストール設定ファイルを手動で生成します。
前提条件
- OpenShift Container Platform インストーラープログラムおよびクラスターのアクセストークンを取得します。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
$ mkdir <installation_directory>
重要ディレクトリーを作成する必要があります。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
以下の
install-config.yaml
ファイルテンプレートをカスタマイズし、これを<installation_directory>
に保存します。注記この設定ファイル
install-config.yaml
に名前を付ける必要があります。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルは、インストールプロセスの次の手順で使用されます。この時点でこれをバックアップする必要があります。
1.9.6.2. GCP のカスタマイズされた install-config.yaml
ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、または必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 controlPlane: 2 hyperthreading: Enabled 3 4 name: master platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c replicas: 3 compute: 5 - hyperthreading: Enabled 6 name: worker platform: gcp: type: n2-standard-4 zones: - us-central1-a - us-central1-c replicas: 0 metadata: name: test-cluster networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: gcp: projectID: openshift-production 7 region: us-central1 8 pullSecret: '{"auths": ...}' fips: false 9 sshKey: ssh-ed25519 AAAA... 10 publish: Internal 11
- 1
- ホストプロジェクトでパブリック DNS を指定します。
- 2 5
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 6
controlPlane
セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。- 4
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
n1-standard-8
などの大規模なマシンタイプを使用します。 - 7
- 仮想マシンインスタンスが存在するメインのプロジェクトを指定します。
- 8
- VPC ネットワークが置かれているリージョンを指定します。
- 9
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、
x86_64
アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。 - 10
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 11
- クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、
publish
をInternal
に設定します。これはインターネットからアクセスできません。デフォルト値はExternal
です。独自にプロビジョニングするインフラストラクチャーを使用するクラスターで共有 VPC を使用するには、publish
をInternal
に設定する必要があります。インストールプログラムは、ホストプロジェクトのベースドメインのパブリック DNS ゾーンにアクセスできなくなります。
1.9.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 Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxy
オブジェクトのstatus.noProxy
フィールドには、インスタンスメタデータのエンドポイント (169.254.169.254
) も設定されます。
手順
install-config.yaml
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
1.9.6.4. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを作成するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターを作成するために後に使用されます。
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
$ ./openshift-install create manifests --dir <installation_directory> 1
- 1
<installation_directory>
については、作成したinstall-config.yaml
ファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。
ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
<installation_directory>/manifests/cluster-dns-02-config.yml
DNS 設定ファイルからprivateZone
セクションを削除します。apiVersion: config.openshift.io/v1 kind: DNS metadata: creationTimestamp: null name: cluster spec: baseDomain: example.openshift.com privateZone: 1 id: mycluster-100419-private-zone status: {}
- 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
の内容は以下の例のようになります。config: |+ [global] project-id = example-project regional = true multizone = true node-tags = opensh-ptzzx-master node-tags = opensh-ptzzx-worker node-instance-prefix = opensh-ptzzx external-instance-groups-prefix = opensh-ptzzx network-project-id = example-shared-vpc network-name = example-network subnetwork-name = example-worker-subnet
-
プライベートネットワーク上にないクラスターをデプロイする場合は、
<installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
ファイルを開き、scope
パラメーターの値をExternal
に置き換えます。ファイルの内容は以下の例のようになります。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: creationTimestamp: null name: default namespace: openshift-ingress-operator spec: endpointPublishingStrategy: loadBalancer: scope: External type: LoadBalancerService status: availableReplicas: 0 domain: '' selector: ''
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
$ ./openshift-install create ignition-configs --dir <installation_directory> 1
- 1
<installation_directory>
については、同じインストールディレクトリーを指定します。
以下のファイルはディレクトリーに生成されます。
. ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
1.9.7. 一般的な変数のエクスポート
1.9.7.1. インフラストラクチャー名の抽出
Ignition 設定ファイルには、Google Cloud Platform (GCP) でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。インフラストラクチャー名は、OpenShift Container Platform のインストール時に適切な GCP リソースを見つけるためにも使用されます。提供される Deployment Manager テンプレートにはこのインフラストラクチャー名への参照が含まれるため、これを抽出する必要があります。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
- クラスターの Ignition 設定ファイルを生成している。
-
jq
パッケージをインストールしている。
1.9.7.2. Deployment Manager テンプレートの一般的な変数のエクスポート
ユーザーによって提供されるインフラストラクチャーのインストールを Google Cloud Platform (GCP) で実行するのに役立つ指定の Deployment Manager テンプレートで使用される一般的な変数のセットをエクスポートする必要があります。
特定の Deployment Manager テンプレートには、追加のエクスポートされる変数が必要になる場合があります。これについては、関連する手順で詳しく説明されています。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得します。
- クラスターの Ignition 設定ファイルを生成します。
-
jq
パッケージをインストールします。
手順
- 提供される Deployment Manager テンプレートで使用される以下の一般的な変数をエクスポートします。
$ export BASE_DOMAIN='<base_domain>' 1 $ export BASE_DOMAIN_ZONE_NAME='<base_domain_zone_name>' 2 $ export NETWORK_CIDR='10.0.0.0/16' $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 3 $ export CLUSTER_NAME=`jq -r .clusterName <installation_directory>/metadata.json` $ export INFRA_ID=`jq -r .infraID <installation_directory>/metadata.json` $ export PROJECT_NAME=`jq -r .gcp.projectID <installation_directory>/metadata.json`
1.9.8. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
のネットワークがマシン設定サーバーから Ignition 設定をフェッチする必要があります。
マシン間のネットワーク接続を、クラスターのコンポーネントが通信できるように設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
表1.36 すべてのマシンに対応するすべてのマシン
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN および Geneve |
| VXLAN および Geneve | |
|
ポート | |
TCP/UDP |
| Kubernetes ノードポート |
表1.37 コントロールプレーンへのすべてのマシン
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
表1.38 コントロールプレーンマシンへのコントロールプレーンマシン