10.6. GCP のインストール設定ファイルの作成
user-provisioned infrastructure を使用して OpenShift Container Platform を Google Cloud Platform (GCP) にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml
ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var
パーティションを設定するオプションもあります。
10.6.1. オプション: 別個の /var
パーティションの作成
OpenShift Container Platform のディスクパーティション設定はインストーラー側で行う必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。
OpenShift Container Platform は、ストレージを /var
パーティションまたは /var
のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
-
/var/lib/containers
: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。 -
/var/lib/etcd
: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。 -
/var
: 監査などの目的に合わせて分離させる必要のあるデータを保持します。
/var
ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
/var
は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install
の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var
パーティションを設定します。
この手順で個別の /var
パーティションを作成する手順を実行する場合、このセクションで後に説明されるように、Kubernetes マニフェストおよび Ignition 設定ファイルを再び作成する必要はありません。
手順
OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。
mkdir $HOME/clusterconfig
$ mkdir $HOME/clusterconfig
Copy to Clipboard Copied! openshift-install
を実行して、manifest
およびopenshift
のサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。openshift-install create manifests --dir $HOME/clusterconfig
$ openshift-install create manifests --dir $HOME/clusterconfig
Copy to Clipboard Copied! 出力例
? SSH Public Key ... INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshift
? SSH Public Key ... INFO Credentials loaded from the "myprofile" profile in file "/home/myuser/.aws/credentials" INFO Consuming Install Config from target directory INFO Manifests created in: $HOME/clusterconfig/manifests and $HOME/clusterconfig/openshift
Copy to Clipboard Copied! オプション: インストールプログラムで
clusterconfig/openshift
ディレクトリーにマニフェストが作成されたことを確認します。ls $HOME/clusterconfig/openshift/
$ ls $HOME/clusterconfig/openshift/
Copy to Clipboard Copied! 出力例
99_kubeadmin-password-secret.yaml 99_openshift-cluster-api_master-machines-0.yaml 99_openshift-cluster-api_master-machines-1.yaml 99_openshift-cluster-api_master-machines-2.yaml ...
99_kubeadmin-password-secret.yaml 99_openshift-cluster-api_master-machines-0.yaml 99_openshift-cluster-api_master-machines-1.yaml 99_openshift-cluster-api_master-machines-2.yaml ...
Copy to Clipboard Copied! 追加のパーティションを設定する Butane 設定を作成します。たとえば、
$HOME/clusterconfig/98-var-partition.bu
ファイルに名前を付け、ディスクのデバイス名をworker
システムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、/var
ディレクトリーを別のパーティションにマウントします。variant: openshift version: 4.16.0 metadata: labels: machineconfiguration.openshift.io/role: worker name: 98-var-partition storage: disks: - device: /dev/disk/by-id/<device_name> partitions: - label: var start_mib: <partition_start_offset> size_mib: <partition_size> number: 5 filesystems: - device: /dev/disk/by-partlabel/var path: /var format: xfs mount_options: [defaults, prjquota] with_mount_unit: true
variant: openshift version: 4.16.0 metadata: labels: machineconfiguration.openshift.io/role: worker name: 98-var-partition storage: disks: - device: /dev/disk/by-id/<device_name>
1 partitions: - label: var start_mib: <partition_start_offset>
2 size_mib: <partition_size>
3 number: 5 filesystems: - device: /dev/disk/by-partlabel/var path: /var format: xfs mount_options: [defaults, prjquota]
4 with_mount_unit: true
Copy to Clipboard Copied! - 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 MiB (メビバイト) の最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、
prjquota
マウントオプションを有効にする必要があります。
注記個別の
/var
パーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。Butane config からマニフェストを作成し、
clusterconfig/openshift
ディレクトリーに保存します。たとえば、以下のコマンドを実行します。butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
$ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml
Copy to Clipboard Copied! openshift-install
を再度実行し、manifest
およびopenshift
のサブディレクトリー内のファイルセットから、Ignition 設定を作成します。openshift-install create ignition-configs --dir $HOME/clusterconfig ls $HOME/clusterconfig/
$ openshift-install create ignition-configs --dir $HOME/clusterconfig $ ls $HOME/clusterconfig/ auth bootstrap.ign master.ign metadata.json worker.ign
Copy to Clipboard Copied!
Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールするためにインストール手順への入力として使用できます。
10.6.2. インストール設定ファイルの作成
Google Cloud Platform (GCP) にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- GCP アカウントを設定します。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 Copy to Clipboard Copied! - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして gcp を選択します。
- コンピューター上で GCP アカウント用のサービスアカウントキーを設定していない場合、GCP からこれを取得してファイルの内容を貼り付けるか、ファイルへの絶対パスを入力する必要があります。
- クラスターのプロビジョニングに使用するプロジェクト ID を選択します。デフォルト値は、設定したサービスアカウントによって指定されます。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成したパブリック DNS ゾーンに対応します。
- クラスターの記述名を入力します。
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。注記3 ノードクラスターをインストールする場合は、必ず
compute.replicas
パラメーターを0
に設定してください。これにより、クラスターのコントロールプレーンがスケジュール可能になります。詳細は、「GCP に 3 ノードクラスターをインストールする」を参照してください。install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
10.6.3. Shielded VM の有効化
クラスターをインストールする場合は、Shielded VM を使用できます。Shielded VM には、セキュアブート、ファームウェアと整合性の監視、ルートキット検出などの追加のセキュリティー機能があります。詳細は、Shielded VM に関する Google のドキュメントを参照してください。
Shielded VM は現在、64 ビット ARM インフラストラクチャーを備えたクラスターではサポートされていません。
手順
クラスターをデプロイする前に、テキストエディターを使用して、
install-config.yaml
ファイルを編集し、次のいずれかのスタンザを追加します。コントロールプレーンマシンのみに Shielded VM を使用するには:
controlPlane: platform: gcp: secureBoot: Enabled
controlPlane: platform: gcp: secureBoot: Enabled
Copy to Clipboard Copied! コンピューティングマシンのみに Shielded VM を使用するには:
compute: - platform: gcp: secureBoot: Enabled
compute: - platform: gcp: secureBoot: Enabled
Copy to Clipboard Copied! すべてのマシンに Shielded VM を使用するには:
platform: gcp: defaultMachinePlatform: secureBoot: Enabled
platform: gcp: defaultMachinePlatform: secureBoot: Enabled
Copy to Clipboard Copied!
10.6.4. Confidential 仮想マシンの有効化
クラスターをインストールする場合は、Confidential 仮想マシンを使用できます。Confidential 仮想マシンは処理中のデータを暗号化します。詳細は、Confidential Computing に関する Google のドキュメントを参照してください。Confidential 仮想マシンと Shielded VM を同時に有効にすることができますが、それらは互いに依存していません。
現在、Confidential 仮想マシンは 64 ビット ARM アーキテクチャーではサポートされていません。
手順
クラスターをデプロイする前に、テキストエディターを使用して、
install-config.yaml
ファイルを編集し、次のいずれかのスタンザを追加します。コントロールプレーンマシンのみに Confidential 仮想マシンを使用するには:
controlPlane: platform: gcp: confidentialCompute: Enabled type: n2d-standard-8 onHostMaintenance: Terminate
controlPlane: platform: gcp: confidentialCompute: Enabled
1 type: n2d-standard-8
2 onHostMaintenance: Terminate
3 Copy to Clipboard Copied! - 1
- Confidential 仮想マシンを有効にします。
- 2
- Confidential 仮想マシンをサポートするマシンタイプを指定します。Confidential 仮想マシンには、N2D または C2D シリーズのマシンタイプが必要です。サポートされているマシンタイプの詳細は、サポートされているオペレーティングシステムとマシンタイプ を参照してください。
- 3
- ハードウェアやソフトウェアの更新など、ホストのメンテナンスイベント中の VM の動作を指定します。Confidential 仮想マシンを使用するマシンの場合は、この値を
Terminate
に設定する必要があります。これにより、VM が停止します。Confidential 仮想マシンはライブ VM 移行をサポートしていません。
コンピューティングマシンのみに Confidential 仮想マシンを使用するには:
compute: - platform: gcp: confidentialCompute: Enabled type: n2d-standard-8 onHostMaintenance: Terminate
compute: - platform: gcp: confidentialCompute: Enabled type: n2d-standard-8 onHostMaintenance: Terminate
Copy to Clipboard Copied! すべてのマシンに Confidential 仮想マシンを使用するには:
platform: gcp: defaultMachinePlatform: confidentialCompute: Enabled type: n2d-standard-8 onHostMaintenance: Terminate
platform: gcp: defaultMachinePlatform: confidentialCompute: Enabled type: n2d-standard-8 onHostMaintenance: Terminate
Copy to Clipboard Copied!
10.6.5. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml
ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター 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> httpsProxy: https://<username>:<pswd>@<ip>:<port> noProxy: example.com additionalTrustBundle: | -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port>
1 httpsProxy: https://<username>:<pswd>@<ip>:<port>
2 noProxy: example.com
3 additionalTrustBundle: |
4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle>
5 Copy to Clipboard Copied! - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundle
という名前の設定マップをopenshift-config
namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle
設定マップを作成し、この設定マップはProxy
オブジェクトのtrustedCA
フィールドで参照されます。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション:
trustedCA
フィールドのuser-ca-bundle
設定マップを参照するProxy
オブジェクトの設定を決定するポリシー。許可される値はProxyonly
およびAlways
です。Proxyonly
を使用して、http/https
プロキシーが設定されている場合にのみuser-ca-bundle
設定マップを参照します。Always
を使用して、常にuser-ca-bundle
設定マップを参照します。デフォルト値はProxyonly
です。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-for
コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debug
Copy to Clipboard Copied! - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
10.6.6. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>
1 Copy to Clipboard Copied! - 1
<installation_directory>
には、作成したinstall-config.yaml
ファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_master-machines-*.yaml
Copy to Clipboard Copied! これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。
コントロールプレーンマシンセットを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml
$ rm -f <installation_directory>/openshift/99_openshift-machine-api_master-control-plane-machine-set.yaml
Copy to Clipboard Copied! オプション: クラスターでコンピュートマシンをプロビジョニングする必要がない場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除します。
rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
$ rm -f <installation_directory>/openshift/99_openshift-cluster-api_worker-machineset-*.yaml
Copy to Clipboard Copied! 重要user-provisioned infrastructure にクラスターをインストールするときに
MachineAPI
機能を無効にした場合は、ワーカーマシンを定義する Kubernetes マニフェストファイルを削除する必要があります。そうしないと、クラスターのインストールに失敗します。ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
警告3 ノードクラスターをインストールしている場合は、以下の手順を省略してコントロールプレーンノードをスケジュール対象にします。
重要コントロールプレーンノードをデフォルトのスケジュール不可からスケジュール可に設定するには、追加のサブスクリプションが必要です。これは、コントロールプレーンノードがコンピュートノードになるためです。
<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: id: mycluster-100419-private-zone publicZone: id: example.openshift.com status: {}
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: {}
Copy to Clipboard Copied! これを実行する場合、後のステップで Ingress DNS レコードを手動で追加する必要があります。
Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>
1 Copy to Clipboard Copied! - 1
<installation_directory>
には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-password
およびkubeconfig
ファイルが./<installation_directory>/auth
ディレクトリーに作成されます。. ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
. ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
Copy to Clipboard Copied!