ホーム
製品
OpenShift Container Platform
4.17
GCP へのインストール
11.7. GCP のインストール設定ファイルの作成

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

user-provisioned infrastructure を使用して OpenShift Container Platform を Google Cloud Platform (GCP) にインストールするには、インストールプログラムがクラスターをデプロイするために必要なファイルを生成し、クラスターが使用するマシンのみを作成するようにそれらのファイルを変更する必要があります。install-config.yaml ファイル、Kubernetes マニフェスト、および Ignition 設定ファイルを生成し、カスタマイズします。また、インストールの準備フェーズ時にまず別の var パーティションを設定するオプションもあります。

11.7.1. インストール設定ファイルの手動作成
リンクのコピー

クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。

前提条件

インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。

手順

必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
```
mkdir <installation_directory>
```
```
$ mkdir <installation_directory>
```
Copy to Clipboard Toggle word wrap
重要
このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
提供されているサンプルの install-config.yaml ファイルテンプレートをカスタマイズし、ファイルを <installation_directory> に保存します。
注記
この設定ファイルの名前を install-config.yaml と付ける必要があります。
多くのクラスターのインストールに使用できるように、install-config.yaml ファイルをバックアップします。
重要
インストールプロセスの次のステップで install-config.yaml ファイルを使用するため、今すぐこのファイルをバックアップしてください。

11.7.2. Shielded VM の有効化
リンクのコピー

クラスターをインストールする場合は、Shielded VM を使用できます。Shielded VM には、セキュアブート、ファームウェアと整合性の監視、ルートキット検出などの追加のセキュリティー機能があります。詳細は、Shielded VM に関する Google のドキュメントを参照してください。

注記

Shielded VM は現在、64 ビット ARM インフラストラクチャーを備えたクラスターではサポートされていません。

手順

クラスターをデプロイする前に、テキストエディターを使用して、install-config.yaml ファイルを編集し、次のいずれかのスタンザを追加します。
1. コントロールプレーンマシンのみに Shielded VM を使用するには:
  controlPlane: platform: gcp: secureBoot: Enabled
  Copy to Clipboard Toggle word wrap
2. コンピューティングマシンのみに Shielded VM を使用するには:
  compute: - platform: gcp: secureBoot: Enabled
  Copy to Clipboard Toggle word wrap
3. すべてのマシンに Shielded VM を使用するには:
  platform: gcp: defaultMachinePlatform: secureBoot: Enabled
  Copy to Clipboard Toggle word wrap

11.7.3. Confidential 仮想マシンの有効化
リンクのコピー

クラスターをインストールする場合は、Confidential 仮想マシンを使用できます。Confidential 仮想マシンは処理中のデータを暗号化します。詳細は、Confidential Computing に関する Google のドキュメントを参照してください。Confidential 仮想マシンと Shielded VM を同時に有効にすることができますが、それらは互いに依存していません。

注記

現在、Confidential 仮想マシンは 64 ビット ARM アーキテクチャーではサポートされていません。

手順

クラスターをデプロイする前に、テキストエディターを使用して、install-config.yaml ファイルを編集し、次のいずれかのスタンザを追加します。
1. コントロールプレーンマシンのみに Confidential 仮想マシンを使用するには:
  controlPlane: platform: gcp: confidentialCompute: Enabled
  1
  type: n2d-standard-8
  2
  onHostMaintenance: Terminate
  3
  Copy to Clipboard Toggle word wrap
  1
  Confidential 仮想マシンを有効にします。
  2
  Confidential 仮想マシンをサポートするマシンタイプを指定します。Confidential 仮想マシンには、N2D または C2D シリーズのマシンタイプが必要です。サポートされているマシンタイプの詳細は、サポートされているオペレーティングシステムとマシンタイプを参照してください。
  3
  ハードウェアやソフトウェアの更新など、ホストのメンテナンスイベント中の VM の動作を指定します。Confidential 仮想マシンを使用するマシンの場合は、この値を Terminate に設定する必要があります。これにより、VM が停止します。Confidential 仮想マシンはライブ VM 移行をサポートしていません。
2. コンピューティングマシンのみに Confidential 仮想マシンを使用するには:
  compute: - platform: gcp: confidentialCompute: Enabled type: n2d-standard-8 onHostMaintenance: Terminate
  Copy to Clipboard Toggle word wrap
3. すべてのマシンに Confidential 仮想マシンを使用するには:
  platform: gcp: defaultMachinePlatform: confidentialCompute: Enabled type: n2d-standard-8 onHostMaintenance: Terminate
  Copy to Clipboard Toggle word wrap

11.7.4. GCP のカスタマイズされた install-config.yaml ファイルのサンプル
リンクのコピー

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

重要

このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml ファイルを取得し、これを変更する必要があります。

apiVersion: v1
baseDomain: example.com 
controlPlane: 
  hyperthreading: Enabled  
  name: master
  platform:
    gcp:
      type: n2-standard-4
      zones:
      - us-central1-a
      - us-central1-c
      tags: 
      - control-plane-tag1
      - control-plane-tag2
  replicas: 3
compute: 
- hyperthreading: Enabled 
  name: worker
  platform:
    gcp:
      type: n2-standard-4
      zones:
      - us-central1-a
      - us-central1-c
      tags: 
      - compute-tag1
      - compute-tag2
  replicas: 0
metadata:
  name: test-cluster
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes 
  serviceNetwork:
  - 172.30.0.0/16
platform:
  gcp:
    defaultMachinePlatform:
      tags: 
      - global-tag1
      - global-tag2
    projectID: openshift-production 
    region: us-central1 
pullSecret: '{"auths": ...}'
fips: false 
sshKey: ssh-ed25519 AAAA... 
publish: Internal

apiVersion: v1
baseDomain: example.com


controlPlane:


  hyperthreading: Enabled


  name: master
  platform:
    gcp:
      type: n2-standard-4
      zones:
      - us-central1-a
      - us-central1-c
      tags:


      - control-plane-tag1
      - control-plane-tag2
  replicas: 3
compute:


- hyperthreading: Enabled


  name: worker
  platform:
    gcp:
      type: n2-standard-4
      zones:
      - us-central1-a
      - us-central1-c
      tags:


      - compute-tag1
      - compute-tag2
  replicas: 0
metadata:
  name: test-cluster
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes


  serviceNetwork:
  - 172.30.0.0/16
platform:
  gcp:
    defaultMachinePlatform:
      tags:


      - global-tag1
      - global-tag2
    projectID: openshift-production


    region: us-central1


pullSecret: '{"auths": ...}'
fips: false


sshKey: ssh-ed25519 AAAA...


publish: Internal

Copy to Clipboard

Toggle word wrap

1: ホストプロジェクトでパブリック DNS を指定します。
2 6: これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
3 7: controlPlane セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute セクションの最初の行はハイフン - で始め、controlPlane セクションの最初の行はハイフンで始めることができません。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。
4: 同時マルチスレッドまたは hyperthreading を有効/無効にするかどうか。デフォルトでは、同時マルチスレッドはマシンのコアのパフォーマンスを上げるために有効化されます。パラメーター値を Disabled に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。
重要
同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して n1-standard-8 などの大規模なマシンタイプを使用します。
5 8 10: オプション: コントロールプレーンまたはコンピューティングマシンセットに適用するネットワークタグのセット。platform.gcp.defaultMachinePlatform.tags パラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。compute.platform.gcp.tags パラメーターまたは controlPlane.platform.gcp.tags パラメーターが設定されている場合は、platform.gcp.defaultMachinePlatform.tags パラメーターを上書きします。
9: インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の OVNKubernetes のみです。
11: 仮想マシンインスタンスが存在するメインのプロジェクトを指定します。
12: VPC ネットワークが置かれているリージョンを指定します。
13: FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。
重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替えを参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
14: クラスター内のマシンにアクセスするために使用する sshKey 値をオプションで指定できます。
注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、ssh-agent プロセスが使用する SSH キーを指定します。
15: クラスターのユーザーに表示されるエンドポイントをパブリッシュする方法。プライベートクラスターをデプロイするには、publish を Internal に設定します。これはインターネットからアクセスできません。デフォルト値は External です。独自にプロビジョニングするインフラストラクチャーを使用するクラスターで共有 VPC を使用するには、publish を Internal に設定する必要があります。インストールプログラムは、ホストプロジェクトのベースドメインのパブリック DNS ゾーンにアクセスできなくなります。

11.7.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 Toggle word wrap
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
Copy to Clipboard Toggle word wrap
ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

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

注記

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

11.7.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 Toggle word wrap
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 Toggle word wrap
これらのファイルを削除することで、クラスターがコントロールプレーンマシンを自動的に生成するのを防ぐことができます。

コントロールプレーンマシンセットを定義する 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

Toggle word wrap

ワーカーマシンを定義する 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 Toggle word wrap
ワーカーマシンは独自に作成し、管理するため、これらのマシンを初期化する必要はありません。
<installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェストファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。
1. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。
2. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。
3. ファイルを保存し、終了します。

<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: 
    id: mycluster-100419-private-zone
status: {}

apiVersion: config.openshift.io/v1
kind: DNS
metadata:
  creationTimestamp: null
  name: cluster
spec:
  baseDomain: example.openshift.com
  privateZone:


    id: mycluster-100419-private-zone
status: {}

Copy to Clipboard

Toggle word wrap

1: このセクションを完全に削除します。

VPC のクラウドプロバイダーを設定します。
1. <installation_directory>/manifests/cloud-provider-config.yaml ファイルを開きます。
2. network-project-id パラメーターを追加し、その値を共有 VPC ネットワークをホストするプロジェクトの ID に設定します。
3. network-name パラメーターを追加し、その値を OpenShift Container Platform クラスターをホストする共有 VPC ネットワークの名前に設定します。
4. 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
```
```
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
```
Copy to Clipboard Toggle word wrap

プライベートネットワーク上にないクラスターをデプロイする場合は、<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: ''

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: ''

Copy to Clipboard

Toggle word wrap

Ignition 設定ファイルを作成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
```
./openshift-install create ignition-configs --dir <installation_directory>
```
```
$ ./openshift-install create ignition-configs --dir <installation_directory> 
```
1
Copy to Clipboard Toggle word wrap
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 Toggle word wrap

トップに戻る

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

11.7.1. インストール設定ファイルの手動作成
リンクのコピー

11.7.2. Shielded VM の有効化
リンクのコピー

11.7.3. Confidential 仮想マシンの有効化
リンクのコピー

11.7.4. GCP のカスタマイズされた install-config.yaml ファイルのサンプル
リンクのコピー

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

11.7.6. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

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

11.7.1. インストール設定ファイルの手動作成リンクのコピーリンクがクリップボードにコピーされました!

11.7.2. Shielded VM の有効化リンクのコピーリンクがクリップボードにコピーされました!

11.7.3. Confidential 仮想マシンの有効化リンクのコピーリンクがクリップボードにコピーされました!

11.7.4. GCP のカスタマイズされた install-config.yaml ファイルのサンプルリンクのコピーリンクがクリップボードにコピーされました!

11.7.5. インストール時のクラスター全体のプロキシーの設定リンクのコピーリンクがクリップボードにコピーされました!

11.7.6. Kubernetes マニフェストおよび Ignition 設定ファイルの作成リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

11.7.1. インストール設定ファイルの手動作成
リンクのコピー

11.7.2. Shielded VM の有効化
リンクのコピー

11.7.3. Confidential 仮想マシンの有効化
リンクのコピー

11.7.4. GCP のカスタマイズされた install-config.yaml ファイルのサンプル
リンクのコピー

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

11.7.6. Kubernetes マニフェストおよび Ignition 設定ファイルの作成
リンクのコピー