バージョン 1.4このバージョンは、Anthos バージョンサポートポリシーに記載のとおり、サポートを終了しています。Anthos clusters on VMware (GKE on-prem) に影響するセキュリティの脆弱性、露出、問題に対する最新のパッチとアップデートを適用するには、サポート対象のバージョンにアップグレードしてください。最新バージョンはこちらで確認できます。

利用可能なバージョン

静的 IP アドレスを使用したインストール

このページでは、静的 IP を使用して GKE On-Prem を VMware vSphere 6.5 または 6.7 Update 3 環境にインストールする方法について説明します。DHCP サーバーを使用してインストールすることもできます。

概要

このページでは、管理クラスタと、ノードが 3 つある 1 つのユーザークラスタを作成する方法について説明します。クラスタを作成したら、追加のユーザークラスタを作成して、ユーザークラスタ内のノードを追加または削除できます。

始める前に

次のトピックに記載されているとおりに環境を設定します。
vSphere で管理ワークステーションを作成します。
必要な場合は、手動負荷分散を有効にする方法をご覧ください。
管理ワークステーションに SSH 接続します。
```
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
```
プロキシ経由で使用する場合、すべての gkectl コマンドは、管理ワークステーションからのインターネットリクエスト用に config.yaml で設定されたものと同じプロキシを自動的に使用します。これは推奨される環境であり、管理ワークステーションとすべてのクラスタが同じプロキシを使用します。このユースケースでは、プロキシ環境変数を設定する必要はありません。

手動プロキシオプション: 管理ワークステーションが同じプロキシの背後にない場合は、手動で環境を構成してインターネットにアクセスできるようにする必要があります。gkectl コマンドを含むすべての HTTPS リクエストをプロキシするように HTTPS_PROXY 環境変数を設定できますが、プロキシから除外するすべてのリクエストに NO_PROXY 環境変数を構成する必要もあります。

gcloud コマンドと gsutil コマンドを個別に実行する必要がある場合は、常に特定のプロキシを使用するように Google Cloud CLI を構成できます。手順については、プロキシ / ファイアウォールの背後で gcloud CLI を使用する場合の構成をご覧ください。

次のオプションを使用して、gkectl コマンドのプロキシを手動で設定します。
- すべての gkectl コマンド:
  HTTPS_PROXY 環境変数と NO_PROXY 環境変数を使用して、すべての gkectl コマンドをプロキシする方法を手動で設定できます。
  - gkectl コマンドに別のプロキシを設定します。例:
```
HTTPS_PROXY="http://my.other.proxy"
NO_PROXY="10.0.1.0/24,private-registry.example,10.0.2.1"
```
  - gkectl コマンドをプロキシから除外します。例: HTTPS_PROXY=""
```
export HTTP_PROXY="http://[PROXY_ADDRESS]"
export HTTPS_PROXY="http://[PROXY_ADDRESS]"
export NO_PROXY="[NO_PROXY_ADDRESSES]"
```
  ここで
  - [PROXY_ADDRESS] は空（""）、プロキシ IP アドレス、またはプロキシのホスト名のいずれかです。
  - [NO_PROXY_ADDRESSES] は、プロキシから除外し、スペースやタブを使用できない URL、IP アドレス、ホスト名のカンマ区切りのリストになります。
- 単一の gkectl コマンド:
  また、個々の gkectl コマンドの前に環境変数を指定して、その呼び出しにのみ指定されたプロキシを使用することもできます。
  
  例:
  
  構成ファイル（config.yaml）で指定されているものとは異なるプロキシを経由して gkectl コマンドをプロキシするには、HTTPS_PROXY 環境変数を使用します。
  - http://my.other.proxy プロキシを使用するには:
    - ```
    HTTPS_PROXY="http://my.other.proxy" gkectl create cluster --config config.yaml
```
- ```
HTTPS_PROXY="http://my.other.proxy" gkectl prepare --config config.yaml
```
  - 空の値を使用してプロキシを除外します。
    - ```
    HTTPS_PROXY="" gkectl create cluster --config config.yaml
```
- ```
HTTPS_PROXY="" gkectl check-config --config config.yaml
```
Google Cloud ユーザーアカウントの認証情報を使用して Google Cloud にログインします。ユーザーアカウントには、少なくとも閲覧者の IAM ロールが必要です。
```
gcloud auth login
```
デフォルトのプロジェクトを設定します。デフォルトの Google Cloud を設定すると、すべての gcloud CLI コマンドはプロジェクトに対して実行されます。コマンドごとにプロジェクトを指定する必要はありません。
```
gcloud config set project [PROJECT_ID]
```
[PROJECT_ID] は実際のプロジェクト ID に置き換えます（プロジェクト ID は Google Cloud コンソールで確認できます。また、gcloud config get-value project を実行して確認することもできます）。

インストール用のコンテナイメージレジストリを選択する

インストールするには、コンテナ化されたクラスタコンポーネントを pull する場所を GKE On-Prem が認識している必要があります。次の 2 つのオプションがあります。

Container Registry

デフォルトでは、GKE On-Prem は、Container Registry がホストする既存の Google 所有のコンテナイメージレジストリを使用します。gcr.io からのトラフィックを許可するようにプロキシを設定する以外に、追加の設定は必要ありません。

非公開 Docker レジストリ

非公開 Docker レジストリをインストールに使用することもできます。GKE On-Prem は、クラスタコンポーネントをこの Docker レジストリに push します。非公開 Docker レジストリを指定するには、privateregistryconfig フィールドを設定します。

インストール用の非公開 Docker レジストリを構成する（省略可）

このセクションでは、GKE On-Prem をインストールするために既存の Docker レジストリを構成する方法について説明します。Docker レジストリの作成方法については、外部からアクセス可能なレジストリを実行するをご覧ください。レジストリを構成したら、GKE On-Prem 構成ファイルの privateregistryconfig フィールドに入力します。

非公開 Docker レジストリを使用してインストールする場合、管理ワークステーション VM は証明書に署名した CA を信頼する必要があります。GKE On-Prem は、セキュリティで保護されていない Docker レジストリをサポートしていません。Docker レジストリを起動する際、証明書と鍵を提供する必要があります。証明書は、パブリック認証局（CA）によって署名されることも、自己署名されることもあります。

この信頼を確立するには、管理ワークステーション VM から次の操作を行います。

証明書を保持するフォルダを作成します。
```
sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
```
[REGISTRY_SERVER] は、Docker レジストリを実行する VM の IP アドレスまたはホスト名です。
証明書ファイルを /etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt にコピーします。もともと別の名前であった場合でも、ファイル名を ca.crt にする必要があります。
Docker サービスを再起動します。
```
sudo service docker restart
```
Docker にログインできることを確認します。
```
docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]
```
[USERNAME] と [PASSWORD] は、Docker レジストリにログインするための認証情報です。

これで、インストール中に gkectl prepare を実行すると、インストールに必要なイメージが Docker レジストリに push されます。

レジストリ構成のトラブルシューティング

GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers): Docker レジストリを実行する VM の IP アドレスが正しいことを確認します。
login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized: ユーザー名とパスワードが正しいことを確認します。
GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority: 管理ワークステーション VM が証明書を信頼していません。

静的 IP アドレスを構成する

静的 IP アドレスを使用する場合は、2 つのホスト構成ファイルを作成する必要があります。1 つは管理クラスタ用、1 つはユーザークラスタ用です。ホスト構成ファイルは、クラスタノードに割り当てる IP アドレスとホスト名を GKE On-Prem に通知します。

管理クラスタの静的 IP アドレス

管理クラスタには、次のノードのアドレスが必要です。

管理クラスタコントロールプレーン用の 1 つのノード
管理クラスタでのアドオン用の 2 つのノード
管理クラスタのアップグレード中に必要な場合がある一時的なノード
関連付けられたユーザークラスタごとに 1 つまたは 3 つのノード

高可用性（HA）ユーザークラスタの場合、管理クラスタには、ユーザークラスタ用のコントロールプレーンコンポーネントを実行する 3 つのノードがあります。非 HA ユーザークラスタの場合、管理クラスタには、ユーザークラスタ用のコントロールプレーンコンポーネントを実行する 1 つのノードがあります。

作成する非 HA ユーザークラスタの数を N とし、作成する HA ユーザークラスタの数を H とします。この場合、管理クラスタのホスト構成ファイルで、少なくともこの数の IP アドレスを指定する必要があります。

4 + N + 3 x H

たとえば、管理クラスタと 1 つの HA ユーザークラスタを作成するとします。次に、管理クラスタ用に 7 個の IP アドレスを確保する必要があります。以下に、7 個の IP アドレスを指定する管理ホスト構成ファイルの例を示します。

hostconfig:
  dns: 172.16.255.1
  tod: 216.239.35.0
  otherdns:
  - 8.8.8.8
  - 8.8.4.4
  othertod:
  - ntp.ubuntu.com
blocks:
  - netmask: 255.255.252.0
    gateway: 172.16.23.254
    ips:
    - ip: 172.16.20.10
      hostname: admin-host1
    - ip: 172.16.20.11
      hostname: admin-host2
    - ip: 172.16.20.12
      hostname: admin-host3
    - ip: 172.16.20.13
      hostname: admin-host4
    - ip: 172.16.20.14
      hostname: admin-host5
     - ip: 172.16.20.15
      hostname: admin-host6
      - ip: 172.16.20.16
      hostname: admin-host7

上記の例からわかるように、ホスト構成ファイルには YAML データ構造が含まれています。

ips フィールドは、IP アドレスとホスト名の配列です。これらは、GKE On-Prem が管理クラスタノードに割り当てる IP アドレスとホスト名です。

ホスト構成ファイルでは、管理クラスタノードが使用する DNS サーバー、タイムサーバー、デフォルトゲートウェイのアドレスも指定します。

ユーザークラスタの静的 IP アドレス

ユーザークラスタには、ノードごとに IP アドレスが必要であり、ユーザークラスタのアップグレード中に一時的なノードに使用する 1 個の追加 IP アドレスも必要です。

たとえば、5 つのノードを持つユーザークラスタを作成するとします。この場合、ユーザークラスタ用に 6 個の IP アドレスを確保する必要があります。以下に、6 組の IP / ホスト名のペアを指定するユーザーホスト構成ファイルの例を示します。

hostconfig:
  dns: 172.16.255.1
  tod: 216.239.35.0
  otherdns:
  - 8.8.8.8
  - 8.8.4.4
  othertod:
  - ntp.ubuntu.com
blocks:
  - netmask: 255.255.252.0
    gateway: 172.16.23.254
    ips:
    - ip: 172.16.20.17
      hostname: user-host1
    - ip: 172.16.20.18
      hostname: user-host2
    - ip: 172.16.20.19
      hostname: user-host3
    - ip: 172.16.20.20
      hostname: user-host4
    - ip: 172.16.20.21
      hostname: user-host5
    - ip: 172.16.20.22
      hostname: user-host6

各 hostname は、ドメインのないローカルホスト名として解釈されます。完全修飾ドメイン名を指定すると、ドメインはトリミングされます。たとえば、host1.enterprise.net は host1 になります。hostname フィールドの値は小文字にする必要があります。

管理ワークステーションでサービスアカウントの秘密鍵を作成する

インストールの準備では、4 個のサービスアカウントを作成しました。ここで、これらのサービスアカウントごとに JSON 秘密鍵ファイルを作成する必要があります。この鍵はインストール時に指定します。

サービスアカウントのメールアドレスを一覧表示する

まず、Google Cloud プロジェクトのサービスアカウントを一覧表示します。

gcloud iam service-accounts list

my-gcp-project という名前の Google Cloud プロジェクトの場合、このコマンドの出力は次のようになります。

gcloud iam service-accounts list
... EMAIL
    allowlisted-service-account@my-gcp-project.iam.gserviceaccount.com
    connect-register-service-account@my-gcp-project.iam.gserviceaccount.com
    connect-agent-service-account@my-gcp-project.iam.gserviceaccount.com
    log-mon-service-account@my-gcp-project.iam.gserviceaccount.com

各アカウントのメールアドレスをメモしておきます。以下の各セクションで、関連するアカウントのメールアカウントを指定します。

許可リストに登録されたサービスアカウント

gcloud iam service-accounts
keys create whitelisted-key.json --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]

ここで、[ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] は許可リストに登録されたサービスアカウントのメールアドレスです。

登録サービスアカウント

gcloud iam service-accounts keys create register-key.json \
--iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]

[REGISTER_SERVICE_ACCOUNT_EMAIL] は、ホワイトリストに登録されたサービスアカウントのメールアドレスです。

接続サービスアカウント

gcloud iam service-accounts keys create connect-key.json \
--iam-account [CONNECT_SERVICE_ACCOUNT_EMAIL]

[CONNECT_SERVICE_ACCOUNT_EMAIL] は、接続サービスアカウントのメールアドレスです。

Cloud Monitoring サービスアカウント

gcloud iam service-accounts keys create stackdriver-key.json \
--iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]

[STACKDRIVER_SERVICE_ACCOUNT_EMAIL] は、Cloud Monitoring サービスアカウントのメールアドレスです。

構成ファイルの生成

インストールを開始するには、gkectl create-config を実行して構成ファイルを生成します。環境の仕様と必要なクラスタ仕様を使用してファイルを変更します。

ファイルを生成するには、次のコマンドを実行します。ここで、--config [PATH] はオプションで、構成ファイルのパスと名前を受け入れます。--config を省略すると、現在の作業ディレクトリに config.yaml が作成されます。

gkectl create-config [--config [PATH]]

構成ファイルの変更

構成ファイルが生成されましたが、環境に適合するように、またクラスタの想定に合わせて、このファイルに変更を加える必要があります。以降のセクションでは、各フィールド、想定される値、情報の場所について説明します。一部のフィールドはデフォルトでコメントアウトされます。これらのフィールドのいずれかがインストールに関連する場合は、コメント化を解除して値を指定します。

このセクションでは、管理クラスタと 1 つのユーザークラスタを単一のコマンドで作成する方法について説明します。バージョン 1.2 以降では、管理クラスタとユーザークラスタを個別に作成できます。

bundlepath

GKE On-Prem のバンドルファイルには、GKE On-Prem の特定のリリースのすべてのコンポーネントが含まれています。管理ワークステーションを作成すると、フルバンドルが /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz に追加されます。このバンドルのバージョンは、管理ワークステーションを作成するためにインポートした OVA のバージョンと一致します。

bundlepath の値を管理ワークステーションのバンドルファイルのパスに設定します。すなわち、bundlepath を以下に設定します。

/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz

[VERSION] は、インストールする GKE On-Prem のバージョンです。最新バージョンは 1.4.3-gke.3 です。

バンドルファイルは別の場所に保存できます。また、別の名前を付けることもできます。構成ファイルで、bundlepath の値がバンドルファイルへのパスであることを確認してください。

vCenter の仕様

vcenter 仕様には、vCenter Server インスタンスに関する情報が含まれます。GKE On-Prem は、vCenter Server と通信する際にこの情報を必要とします。

vcenter.credentials.address

vcenter.credentials.address フィールドには、vCenter Server の IP アドレスまたはホスト名が格納されます。

vsphere.credentials.address field を入力する前に、vCenter Server のサービス証明書をダウンロードして検査します。次のコマンドを入力して証明書をダウンロードし、vcenter.pem という名前のファイルに保存します。

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

証明書ファイルを開き、サブジェクトの共通名とサブジェクトの代替名を表示します。

openssl x509 -in vcenter.pem -text -noout

出力に Subject 共通名（CN）が表示されます。これが IP アドレスである場合も、ホスト名である場合もあります。次に例を示します。

Subject: ... CN = 203.0.113.100

Subject: ... CN = my-host.my-domain.example

出力では、Subject Alternative Name に 1 つ以上の DNS 名を含めることもできます。

X509v3 Subject Alternative Name:
    DNS:vcenter.my-domain.example

Subject 共通名または Subject Alternative Name のいずれか 1 つの DNS 名を選択して、構成ファイルの vcenter.credentials.address の値として使用します。次に例を示します。

vcenter:
  credentials:
    address: "203.0.113.1"
    ...

vcenter:
  credentials:
    address: "my-host.my-domain.example"
    ...

証明書に含まれる値は選択する必要があります。たとえば、IP アドレスが証明書に含まれていない場合は、vcenter.credentials.address には使用できません。

vcenter.credentials

GKE On-Prem では、vCenter Server のユーザー名とパスワードの情報が必要です。この情報を指定するには、vcenter.credentials で username 値と password 値を設定します。次に例を示します。

vcenter:
  credentials:
    ...
    username: "my-name"
    password: "my-password"

vcenter.datacenter、.datastore、.cluster、.network

GKE On-Prem には、vSphere 環境の構造に関する情報が必要です。vcenter で値を設定して、この情報を指定します。次に例を示します。

vcenter:
  ...
  datacenter: "MY-DATACENTER"
  datastore: "MY-DATASTORE"
  cluster: "MY-VSPHERE-CLUSTER"
  network: "MY-VIRTUAL-NETWORK"

vcenter.resourcepool

vSphere リソースプールは、vSphere クラスタ内の vSphere VM の論理グループです。デフォルト以外のリソースプールを使用している場合は、その名前を vcenter.resourcepool に指定します。次に例を示します。

vcenter:
  ...
  resourcepool: "my-pool"

GKE On-Prem でそのノードを vSphere クラスタのデフォルトリソースプールにデプロイするには、空の文字列を vcenter.resourcepool に指定します。次に例を示します。

vcenter:
  ...
  resourcepool: ""

vcenter.datadisk

GKE On-Prem は、管理クラスタの Kubernetes オブジェクトデータを保持する仮想マシンディスク（VMDK）を作成します。インストーラによって VMDK が作成されますが、vcenter.datadisk フィールドに VMDK の名前を指定する必要があります。次に例を示します。

vcenter:
  ...
  datadisk: "my-disk.vmdk"

vSAN データストア: VMDK 用フォルダの作成

vSAN データストアを使用する場合は、VMDK をフォルダに格納する必要があります。フォルダは、事前に手動で作成する必要があります。govc を使用してフォルダを作成することで、これを行えます。

govc datastore.mkdir -namespace=true my-gke-on-prem-folder

次に、vcenter.datadisk を VMDK のパス（フォルダを含む）に設定します。次に例を示します。

vcenter:
...
datadisk: "my-gke-on-prem-folder/my-disk.vmdk"

バージョン 1.1.1 以前では、既知の問題により、フォルダのファイルパスではなく、Universally Unique Identifier（UUID）のパスを vcenter.datadisk に指定する必要があります。上記の govc コマンドの出力からコピーします。

次に、vcenter.datadisk フィールドにフォルダの UUID を入力します。UUID の前にスラッシュを付けないでください。次に例を示します。

vcenter:
...
datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"

この問題は、バージョン 1.1.2 以降で修正されています。

vcenter.cacertpath

GKE On-Prem などのクライアントが vCenter Server にリクエストを送信する場合、サーバーはクライアントに証明書または証明書バンドルを提示して ID を証明する必要があります。証明書またはバンドルを確認するには、GKE On-Prem に信頼チェーン内のルート証明書が必要です。

vcenter.cacertpath をルート証明書のパスに設定します。次に例を示します。

vcenter:
  ...
  cacertpath: "/my-cert-folder/the-root.crt"

ご使用の VMware インストレーションには、vCenter サーバーに証明書を発行する認証局（CA）があります。信頼チェーンのルート証明書は、VMware が作成した自己署名証明書です。

デフォルトの VMWare CA を使用しない場合は、別の認証局を使用するように VMware を構成できます。

vCenter サーバーでデフォルトの VMware CA が発行した証明書を使用している場合は、いくつかの方法でルート証明書を取得できます。

curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip

[SERVER_ADDRESS] は vCenter サーバーのアドレスです。

ブラウザで、vCenter サーバーのアドレスを入力します。右側の灰色のボックスで、[信頼されたルート CA 証明書をダウンロード] をクリックします。
提供中の証明書を取得するには、次のコマンドを入力します。
```
true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts
```
出力で、https://[SERVER_ADDRESS]/afd/vecs/ca のような URL を見つけます。ブラウザで URL を入力します。これにより、ルート証明書がダウンロードされます。

ダウンロードしたファイルの名前は downloads.zip です。

ZIP ファイルを解凍します。

unzip downloads.zip

1 回の unzip コマンドで解凍できない場合は、再度コマンドを入力します。

certs/lin で証明書ファイルを見つけます。

プロキシの仕様

ネットワークがプロキシサーバーの背後にある場合は、HTTPS プロキシとプロキシから除外するアドレスを proxy フィールドに入力します。次に例を示します。

proxy:
  url: "https://username:password@domain"
  noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"

proxy.url は HTTPS プロキシの URL です。

proxy.noproxy には、プロキシされるべきではない CIDR 範囲、IP アドレス、ドメイン、ホスト名が含まれています。たとえば、クラスタノードの IP アドレスへの呼び出しはプロキシされるべきではありません。したがって、クラスタノードのみを含むサブネットがある場合は、サブネットの CIDR 範囲を noproxy フィールドに記入します。privateregistryconfig を指定すると、そのアドレスが自動的に追加され、非公開レジストリへの呼び出しが防止されます。

管理クラスタの仕様

admincluster 仕様には、管理クラスタを作成するために GKE On-Prem で必要な情報が含まれています。

admincluster.vcenter.network

admincluster.vcenter.network では、管理クラスタノード用の vCenter ネットワークを指定できます。これは、vcenter で指定したグローバル設定よりも優先されます。次に例を示します。

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

admincluster.ipblockfilepath

静的 IP アドレスを使用しているため、静的 IP の構成で説明されているホスト構成ファイルが必要です。ホスト構成ファイルへのパスを admincluster.ipblockfilepath フィールドに入力します。例:

admincluster:
  ipblockfilepath: "/my-config-folder/my-admin-hostconfig.yaml"

admincluster.manuallbspec（手動負荷分散モード）

管理クラスタの Kubernetes API サーバーは、NodePort 型の Service として実装されます。手動負荷分散を使用する場合は、この Service で nodePort 値を選択する必要があります。controlplanenodeport で nodePort 値を指定します。次に例を示します。

admincluster:
  ...
  manuallbspec:
    ...
    controlplanenodeport: 30968

管理クラスタ内のアドオンサーバーは、NodePort 型の Service として実装されます。手動負荷分散を使用する場合は、この Service で nodePort 値を選択する必要があります。controlplanenodeport で nodePort 値を指定します。次に例を示します。

admincluster:
  manuallbspec:
    ...
    addonsnodeport: 30562

admincluster.bigip.credentials（統合負荷分散モード）

統合負荷分散モードを使用しない場合は、admincluster.bigip をコメントアウトしたままにします。

統合負荷分散モードを使用している場合、GKE On-Prem は F5 BIG-IP ロードバランサの IP アドレスまたはホスト名、ユーザー名、パスワードを知る必要があります。admincluster.bigip で値を設定して、この情報を指定します。次に例を示します。

admincluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.2"
      username: "my-admin-f5-name"
      password: "rJDlm^%7aOzw"

admincluster.bigip.partition（統合負荷分散モード）

統合負荷分散モードを使用している場合は、管理クラスタの BIG-IP パーティションを作成する必要があります。admincluster.bigip.partition をパーティションの名前に設定します。次に例を示します。

admincluster:
  ...
  bigip:
    partition: "my-admin-f5-partition"

admincluster.vips

管理クラスタに統合負荷分散と手動負荷分散のどちらを使用するかによらず、admincluster.vips フィールドに値を入力する必要があります。

admincluster.vips.controlplanevip の値を、管理クラスタの Kubernetes API サーバー用のロードバランサに構成するよう選択した IP アドレスに設定します。ingressvip の値を、管理クラスタの Ingress コントローラのロードバランサに構成するよう選択した IP アドレスに設定します。次に例を示します。

admincluster:
  ...
  vips:
    controlplanevip: 203.0.113.3
    ingressvip: 203.0.113.4

admincluster.serviceiprange と admincluster.podiprange

管理クラスタには、Service に使用する IP アドレスの範囲と Pod に使用する IP アドレスの範囲が必要です。これらの範囲は、admincluster.serviceiprange フィールドと admincluster.podiprange フィールドで指定します。gkectl create-config を実行すると、これらのフィールドに入力されます。入力した値は、必要に応じて任意の値に変更できます。

Service と Pod の範囲は重複しないようにします。また、Service と Pod の範囲が、クラスタ内のノードで使用する IP アドレスと重複しないようにしてください。

例:

admincluster:
  ...
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

ユーザークラスタの仕様

ユーザークラスタの仕様 usercluster には、初期ユーザークラスタを作成するために GKE On-Prem で必要な情報が含まれています。

VMware DRS の反アフィニティルールの無効化（省略可）

GKE On-Prem はユーザークラスタのノードに対して VMware Distributed Resource Scheduler（DRS）の反アフィニティルールを自動的に作成し、データセンター内の少なくとも 3 つの物理ホストにそれを分散させます。

この機能を使用するには、vSphere 環境が次の条件を満たしている必要があります。

VMware DRS が有効になっていること。VMware DRS には、vSphere Enterprise Plus ライセンスエディションが必要です。DRS を有効にする方法については、クラスタ内の VMware DRS の有効化をご覧ください。
vcenter フィールドで指定された vSphere ユーザーアカウントに Host.Inventory.EditCluster 権限があること。
利用可能な物理ホストが 3 台以上あること。

前述のとおり、vSphere スタンダードライセンスがある場合、VMware DRS を有効にすることはできません。

DRS が有効になっていない場合、または vSphere VM をスケジュール設定できるホストが 3 つ以上ない場合は、usercluster.antiaffinitygroups.enabled: false を構成ファイルに追加します。次に例を示します。

usercluster:
  ...
  antiaffinitygroups:
    enabled: false

詳細については、バージョン 1.1.0-gke.6 のリリースノートをご覧ください。

4 つ以上のノードを実行するクラスタの場合: vSphere vMotion でノードを別のホストに移動した場合は、ワークロードを再起動してからホスト間で再度分散します。

`usercluster.vcenter.network`

usercluster.vcenter.network では、ユーザークラスタノード用の vCenter ネットワークを指定できます。これは、vcenter で指定したグローバル設定よりも優先されます。例:

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

`usercluster.ipblockfilepath`

静的 IP アドレスを使用しているため、静的 IP の構成で説明されているホスト構成ファイルが必要です。ホスト構成ファイルへのパスを usercluster.ipblockfilepath フィールドに入力します。例:

usercluster:
  ipblockfilepath: "/my-config-folder/my-user-hostconfig.yaml"

`usercluster.manuallbspec`（手動負荷分散モード）

ユーザークラスタの Ingress コントローラは、NodePort 型の Service として実装されます。Service には、HTTP 用の ServicePort が 1 つ、HTTPS 用の別の ServicePort が 1 つあります。手動負荷分散モードを使用する場合は、これらの ServicePort で nodePort 値を選択する必要があります。ingresshttpnodeport と ingresshttpsnodeport に nodePort 値を指定します。次に例を示します。

usercluster:
  manuallbspec:
    ingresshttpnodeport: 30243
    ingresshttpsnodeport: 30879

ユーザークラスタの Kubernetes API サーバーは、NodePort 型の Service として実装されます。手動負荷分散を使用する場合は、この Service で nodePort 値を選択する必要があります。controlplanenodeport に nodePort 値を指定します。次に例を示します。

usercluster:
  ...
  manuallbspec:
    ...
    controlplanenodeport: 30562

`usercluster.bigip.credentials`（統合負荷分散モード）

統合負荷分散モードを使用している場合、GKE On-Prem はユーザークラスタに使用する F5 BIG-IP ロードバランサの IP アドレスまたはホスト名、ユーザー名、パスワードを知る必要があります。usercluster.bigip で値を設定して、この情報を指定します。次に例を示します。

usercluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.5"
      username: "my-user-f5-name"
      password: "8%jfQATKO$#z"
  ...

`usercluster.bigip.partition`（統合負荷分散モード）

統合負荷分散モードを使用している場合は、ユーザークラスタの BIG-IP パーティションを作成する必要があります。usercluster.bigip.partition をパーティションの名前に設定します。次に例を示します。

usercluster:
  ...
  bigip:
    partition: "my-user-f5-partition"
  ...

`usercluster.vips`

ユーザークラスタに統合負荷分散と手動負荷分散のどちらを使用するかによらず、usercluster.vips フィールドに値を入力する必要があります。

usercluster.vips.controlplanevip の値を、ユーザークラスタの Kubernetes API サーバー用のロードバランサに構成するよう選択した IP アドレスに設定します。ingressvip の値を、ユーザークラスタの Ingress コントローラのロードバランサに構成するよう選択した IP アドレスに設定します。次に例を示します。

usercluster:
  ...
  vips:
    controlplanevip: 203.0.113.6
    ingressvip: 203.0.113.7

`usercluster.serviceiprange` と `usercluster.podiprange`。

ユーザークラスタには、Service に使用する IP アドレスの範囲と Pod に使用する IP アドレスの範囲が必要です。これらの範囲は、usercluster.serviceiprange フィールドと usercluster.podiprange フィールドで指定します。gkectl create-config を実行すると、これらのフィールドに入力されます。入力した値は、必要に応じて任意の値に変更できます。

例:

usercluster:
  ...
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

`usercluster.clustername`

usercluster.clustername の値を任意の名前に設定します。名前は 40 文字以下にしてください。次に例を示します。

usercluster:
  ...
  clustername: "my-user-cluster-1"

`usercluster.masternode.replicas`

usercluster.masternode.replicas フィールドには、ユーザークラスタに割り当てるコントロールプレーンノードの数を指定します。ユーザークラスタのコントロールプレーンノードは、ユーザーコントロールプレーン（Kubernetes コントロールプレーンコンポーネント）を実行します。この値は 1 または 3 にする必要があります。

1 つのユーザーコントロールプレーンを実行する場合は、このフィールドを 1 に設定します。
ユーザーコントロールプレーンを実行する 3 つのコントロールプレーンノードから高可用性（HA）ユーザーコントロールプレーンを構成する場合は、このフィールドを 3 に設定します。

`usercluster.masternode.cpus` と `usercluster.masternode.memorymb`

usercluster.masternode.cpus フィールドと usercluster.masternode.memorymb フィールドは、ユーザークラスタの各コントロールプレーンノードに割り当てられる CPU 数とメモリ量をメガバイト単位で指定します。次に例を示します。

usercluster:
  ...
  masternode:
    cpus: 4
    memorymb: 8192

`usercluster.workernode.replicas`

usercluster.workernode.replicas フィールドには、ユーザークラスタに割り当てるワーカーノードの数を指定します。ワーカーノードは、クラスタワークロードを実行します。

`usercluster.workernode.cpus` と `usercluster.workernode.memorymb`

usercluster.masternode.cpus フィールドと usercluster.masternode.memorymb フィールドは、ユーザークラスタの各ワーカーノードに割り当てられる CPU 数とメモリ量をメガバイト単位で指定します。次に例を示します。

usercluster:
  ...
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3

usercluster.oidc

ユーザークラスタのクライアントで OIDC 認証を使用する場合は、usercluster.oidc にあるフィールドに値を設定します。OIDC の構成は任意です。

OIDC の構成方法については、OIDC による認証をご覧ください。

バージョン 1.0.2-gke.3 のインストールの概要

バージョン 1.0.2-gke.3 では、次の OIDC フィールド（usercluster.oidc）が導入されています。こうしたフィールドで、Google Cloud コンソールからクラスタにログインできるようになります。

usercluster.oidc.kubectlredirecturl
usercluster.oidc.clientsecret
usercluster.oidc.usehttpproxy

バージョン 1.0.2-gke.3 では、OIDC を使用する場合でも、Google Cloud コンソールからクラスタにログインしない場合でも、clientsecret フィールドは必須です。その場合、以下のように clientsecret にプレースホルダの値を指定できます。

oidc:
clientsecret: "secret"

usercluster.sni

Server Name Indication（SNI）は、Transport Layer Security（TLS）の拡張機能です。クライアントが指定したホスト名に応じて、単一の IP アドレスと TCP ポートで複数の証明書を提示できます。

CA が信頼できる CA としてユーザークラスタ外のクライアントにすでに配布されており、このチェーンを利用して信頼できるクラスタを特定する場合は、ロードバランサ IP アドレスの外部クライアントに提示される追加の証明書で Kubernetes API サーバーを構成できます。

ユーザークラスタで SNI を使用するには、独自の CA と公開鍵基盤（PKI）が必要です。個別のサービス証明書を各ユーザークラスタにプロビジョニングし、GKE On-Prem は追加のサービス証明書をそれぞれのユーザークラスタに追加します。

ユーザークラスタの Kubernetes API サーバーの SNI を構成するには、usercluster.sni.certpath（外部証明書へのパス）と usercluster.sni.keypath（外部証明書の秘密鍵ファイルへのパス）の値を指定します。次に例を示します。

usercluster:
  ...
  sni:
    certpath: "/my-cert-folder/example.com.crt"
    keypath: "/my-cert-folder/example.com.key"

`lbmode`

統合負荷分散または手動負荷分散を使用できます。選択した負荷分散モードは、管理クラスタと初期ユーザークラスタに適用されます。また、今後作成するユーザークラスタにも適用されます。

lbmode の値を Integrated または Manual に設定して、負荷分散の選択を指定します。次に例を示します。

lbmode: Integrated

`gkeconnect`

gkeconnect 仕様には、GKE On-Prem で Google Cloud Console からオンプレミスクラスタの管理を設定するために必要な情報が含まれています。

gkeconnect.projectid を、オンプレミスクラスタを管理する Google Cloud プロジェクトのプロジェクト ID に設定します。

gkeconnect.registerserviceaccountkeypath の値を、登録サービスアカウントの JSON キーファイルのパスに設定します。gkeconnect.agentserviceaccountkeypath の値を、接続サービスアカウントの JSON キーファイルのパスに設定します。

例:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-folder/register-key.json"
  agentserviceaccountkeypath: "/my-key-folder/connect-key.json"

`stackdriver`

stackdriver 仕様には、オンプレミスクラスタで生成されたログエントリの保存のために GKE On-Prem で必要な情報が含まれています。

stackdriver.projectid を、オンプレミスクラスタに関連する Stackdriver のログを表示させる Google Cloud プロジェクトのプロジェクト ID に設定します。

stackdriver.clusterlocation を、Stackdriver ログを保存する Google Cloud リージョンに設定します。お使いのオンプレミスデータセンターの近くのリージョンを選択することをおすすめします。

クラスタのネットワークが VPC によって制御されている場合は、stackdriver.enablevpc を true に設定します。これにより、すべてのテレメトリーが Google の制限された IP アドレスを通過するようになります。

stackdriver.serviceaccountkeypath の値を、Stackdriver Logging サービスアカウントの JSON キーファイルのパスに設定します。

例:

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  enablevpc: false
  serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"

`privateregistryconfig`

非公開 Docker レジストリがある場合、privateregistryconfig フィールドには、GKE On-Prem がイメージを非公開レジストリに push するために使用する情報が保持されます。非公開レジストリを指定しない場合、gkectl は、インストール中に GKE On-Prem のコンテナイメージを Container Registry リポジトリ（gcr.io/gke-on-prem-release）から pull します。

privatedockerregistry.credentials で、address を、非公開 Docker レジストリを実行するマシンの IP アドレスに設定します。username と password を、非公開 Docker レジストリのユーザー名とパスワードに設定します。address に設定した値は自動的に proxy.noproxy に追加されます。

Docker が非公開レジストリからイメージを pull する場合、レジストリは証明書を提示して自身の ID を証明する必要があります。レジストリの証明書は、認証局（CA）によって署名されます。Docker は、CA 証明書を使用してレジストリの証明書を検証します。

privateregistryconfig.cacertpath を CA 証明書のパスに設定します。例:

privateregistryconfig
  ...
  cacertpath: /my-cert-folder/registry-ca.crt

`gcrkeypath`

gcrkeypath の値を、許可リストに登録されたサービスアカウント用の JSON キーファイルのパスに設定します。

例:

gcrkeypath: "/my-key-folder/whitelisted-key.json"

`cloudauditlogging`

Kubernetes 監査ログを Google Cloud プロジェクトに送信する場合は、cloudauditlogging 仕様を入力します。次に例を示します。

cloudauditlogging:
  projectid: "my-project"
  # A Google Cloud region where you would like to store audit logs for this cluster.
  clusterlocation: "us-west1"
  # The absolute or relative path to the key file for a Google Cloud service account used to
  # send audit logs from the cluster
  serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"

監査ロギングの使用方法の詳細をご確認ください。

構成ファイルの検証

この手順を管理ワークステーションで完了します。

構成ファイルを変更したら、gkectl check-config を実行して、ファイルが有効でインストールに使用できることを確認します。

gkectl check-config --config [PATH_TO_CONFIG] --fast

コマンドが FAILURE メッセージを返した場合は、問題を修正してファイルを再度検証します。--fast フラグを使用して、テスト VM を作成するチェックをスキップします。これは、gkectl prepare によって管理ワークステーションから vCenter にアップロードされるノードの OS イメージによって異なります。

検証のスキップ

次の gkectl コマンドは、構成ファイルに対して自動的に検証を実行します。

gkectl prepare
gkectl create cluster
gkectl upgrade

コマンドの検証をスキップするには、--skip-validation-all を渡します。たとえば、gkectl prepare の検証をすべてスキップする手順は次のとおりです。

gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all

特定の検証をスキップするために使用可能なフラグをすべて表示するには:

gkectl check-config --help

`gkectl prepare` の実行

インストールする前に、管理ワークステーションで gkectl prepare を実行して、vSphere 環境を初期化する必要があります。gkectl prepare は次のタスクを行います。

ノードの OS イメージを vSphere にインポートし、テンプレートとしてマークします。
非公開 Docker レジストリを使用している場合は、GKE On-Prem イメージをレジストリに push します。
必要に応じて、コンテナイメージのビルド証明書を検証します。これにより、イメージが Google によって作成、署名されていることと、デプロイの準備ができていることを確認します。

GKE On-Prem 構成ファイルを使用して gkectl prepare を実行します。--validate-attestations はオプションです。

gkectl prepare --config [CONFIG_FILE] --validate-attestations

--validate-attestations からの正の出力は Image [IMAGE_NAME] validated です。

構成ファイルの再検証

gkectl prepare を実行してノード OS イメージをアップロードした後、--fast フラグなしで gkectl check-config を実行すると、テスト VM を作成する追加のチェックが実行できるようになります。

gkectl check-config --config [PATH_TO_CONFIG]

コマンドが FAILURE メッセージを返した場合は、問題を修正してファイルを再度検証します。

GKE On-Prem のインストール

環境の外観とクラスタの外観を指定する構成ファイルを作成し、そのファイルを検証しました。gkectl prepare を実行して、GKE On-Prem ソフトウェアで環境を初期化しました。これで、GKE On-Prem の新規インストールを開始する準備ができました。

GKE On-Prem をインストールするには、管理クラスタとユーザークラスタを作成します。次の手順では、同じプロセスで管理クラスタとユーザークラスタの両方を作成します。各クラスタを個別に作成する場合は、管理クラスタとユーザークラスタを個別に作成するをご覧ください。

管理クラスタとユーザークラスタを作成するには:

gkectl create cluster コマンドを実行して、管理クラスタとユーザークラスタを作成します。
```
gkectl create cluster --config [CONFIG_FILE]
```
ここで、[CONFIG_FILE] は以前に作成した構成ファイルです。

gkectl create cluster コマンドは、現在のディレクトリに [CLUSTER_NAME]-kubeconfig という名前の kubeconfig ファイルを作成します。ここで、[CLUSTER_NAME] は cluster に設定した名前です。例: MY-VSPHERE-CLUSTER-kubeconfig

GKE On-Prem のドキュメントでは、次のプレースホルダを使用して、これらの kubeconfig ファイルを参照します。
- 管理クラスタ: [ADMIN_CLUSTER_KUBECONFIG]
- ユーザークラスタ: [USER_CLUSTER_KUBECONFIG]
クラスタが作成され、運用中であることを確認します。
1. 管理クラスタを確認するには、次のコマンドを実行します。
```
kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
```
  出力には、管理クラスタノードが表示されます。
2. ユーザークラスタを確認するには、次のコマンドを実行します。
```
kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]
```
  出力には、ユーザークラスタノードが表示されます。次に例を示します。
```
NAME                        STATUS   ROLES    AGE   VERSION
xxxxxx-1234-ipam-15008527   Ready    <none>   12m   v1.14.7-gke.24
xxxxxx-1234-ipam-1500852a   Ready    <none>   12m   v1.14.7-gke.24
xxxxxx-1234-ipam-15008536   Ready    <none>   12m   v1.14.7-gke.24
```

構成ファイルを再利用して追加のユーザークラスタを作成する方法を確認します。

インストールの再開

管理クラスタの作成後にインストールが中断された場合、次の手順でインストールを再開できます。

構成ファイルから admincluster 仕様を削除します。
--kubeconfig フラグと --skip-validation-all フラグの両方を指定して gkectl create cluster を実行し、管理クラスタの kubeconfig ファイルを渡して、プリフライトチェックをスキップします。
```
gkectl create cluster \
--config [CONFIG_FILE] \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--skip-validation-all
```
[ADMIN_CLUSTER_NAME] は、インストールを開始したときに作業ディレクトリに作成された管理クラスタの kubeconfig です。

クラスタを Google に接続する

gkeconnect 仕様を入力すると、ユーザークラスタが自動的に Google Cloud コンソールに登録されます。Google Cloud コンソールの [Kubernetes クラスタ] メニューで、登録済みの GKE On-Prem クラスタを表示できます。ここから、クラスタにログインしてワークロードを表示できます。
クラスタを作成してから 1 時間以内に Google Cloud コンソールに表示されない場合は、接続に関するトラブルシューティングをご覧ください。

Ingress の有効化

ユーザークラスタを実行した後、ゲートウェイオブジェクトを作成して Ingress を有効にする必要があります。ゲートウェイマニフェストの最初の部分は常に次のようになります。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system

マニフェストの残りの部分は、必要に応じて調整できます。たとえば、このマニフェストでは、クライアントは HTTP/2 プロトコルと任意のホスト名を使用して、ポート 80 でリクエストを送信できます。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"

HTTPS リクエストを受け入れる場合は、Ingress コントローラがクライアントに提示できる証明書を 1 つ以上指定する必要があります。

証明書を提供するには:

証明書と鍵を保持する Secret を作成します。
Secret を参照するゲートウェイオブジェクトを作成するか、Secret を参照するように既存のゲートウェイオブジェクトを変更します。ゲートウェイオブジェクトの名前は istio-autogenerated-k8s-ingress にする必要があります。

たとえば、すでに証明書ファイル ingress-wildcard.crt と鍵ファイル ingress-wildcard.key を作成しているとします。

ingressgateway-wildcard-certs という名前の Secret を作成します。

kubectl create secret tls \
    --namespace gke-system \
    ingressgateway-wildcard-certs \
    --cert ./ingress-wildcard.crt \
    --key ./ingress-wildcard.key

Secret を参照するゲートウェイのマニフェストは次のとおりです。クライアントは、HTTPS プロトコルと *.example.com に一致する任意のホスト名を使用して、ポート 443 で呼び出すことができます。証明書のホスト名は、マニフェストのホスト名と一致する必要があります（この例では *.example.com）。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"
  - hosts:
    - "*.example.com"
    port:
      name: https-demo-wildcard
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: ingressgateway-wildcard-certs

ゲートウェイマニフェストを変更することで、ホストごとに複数の TLS 証明書を作成できます。

マニフェストを my-gateway.yaml という名前のファイルに保存して、ゲートウェイを作成します。

kubectl apply -f my-gateway.yaml

これで、標準の方法で Kubernetes Ingress オブジェクトを使用できるようになりました。

管理クラスタとユーザークラスタを個別に作成する

GKE On-Prem バージョン 1.2 以降では、管理クラスタとユーザークラスタを個別に作成できます。つまり、まず管理クラスタのみを作成して開始できます。その後、必要に応じて、1 つ以上のユーザークラスタを作成できます。

バージョン 1.2 より前:

最初のユーザークラスタは、常に管理クラスタのデータストアを使用しました。その後に作成されたユーザークラスタは、管理クラスタのデータストアとは別のデータストアを使用できました。
ユーザークラスタに別のデータストアを指定した場合、そのユーザークラスタのワーカーノードとワーカーノードの PersistentVolume（PV）は別のデータストアを使用しました。ただし、ユーザーコントロールプレーンの VM とそれに関連する PV は、管理クラスタのデータストアを使用しました。

バージョン 1.2 以降:

どのユーザークラスタも（最初のユーザークラスタでも）、管理クラスタのデータストアとは別のデータストアを使用できます。
ユーザークラスタに別のデータストアを指定する場合、ユーザークラスタワーカーノード、ユーザークラスタワーカーノードの PV、ユーザーコントロールプレーン VM、ユーザーコントロールプレーン VM の PV はすべて、個別のデータストアを使用します。

管理クラスタのみを作成するには、クラスタ構成ファイルから usercluster セクション全体を削除します。次に、gkectl create コマンドを入力します。

gkectl create --config [ADMIN_CONFIG_FILE]

[ADMIN_CONFIG_FILE] は、usercluster セクションが削除された構成ファイルのパスです。

次に、admincluster セクション全体が削除された構成ファイルを作成します。このファイルでは、管理クラスタのデータストアとは異なる vSphere データストアを指定できます。データストアを指定するには、vcenter.credentials.datastore の値を入力します。次に例を示します。

vcenter:
  credentials:
    ...
  ...
  datastore: "my-user-cluster-datastore"

ユーザークラスタを作成するには、このコマンドを入力します。

gkectl create --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]

ここで

[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルです。
[USER_CLUSTER_CONFIG] は、ユーザークラスタの構成ファイルです。

GKE On-Prem の制限事項

制限	説明
クラスタとノードの上限と下限	割り当てと上限をご覧ください。環境のパフォーマンスがこれらの上限に影響することがあります。
ユーザークラスタ名の一意性	同じ Google Cloud プロジェクトに登録されているすべてのユーザークラスタに一意の名前を付ける必要があります。
複数の vCenter / vSphere データセンターにはデプロイできない	現時点では、管理クラスタと関連するユーザークラスタのセットは、1 つの vCenter / vSphere データセンターにのみデプロイできます。同じ管理クラスタとユーザークラスタを、複数の vCenter / vSphere データセンターにはデプロイできません。
作成後にクラスタ構成を宣言型の方法で変更できない	追加のクラスタの作成と既存のクラスタのサイズ変更はできますが、既存のクラスタを構成ファイルで変更することはできません。

トラブルシューティング

詳しくは、トラブルシューティングをご覧ください。

`gkectl` を使用してクラスタの問題を診断する

クラスタの問題を特定し、クラスタの情報を Google と共有するために、gkectl diagnose コマンドを使用します。クラスタの問題を診断するをご覧ください。

`gkectl` コマンドを冗長モードで実行する

-v5

`stderr` に対する `gkectl` エラーのロギング

--alsologtostderr

管理ワークステーションで `gkectl` ログを見つける

デバッグフラグを渡さない場合でも、次の管理ワークステーションディレクトリで gkectl ログを表示できます。

/home/ubuntu/.config/gke-on-prem/logs

管理クラスタで Cluster API ログを見つける

管理コントロールプレーンの起動後に VM が起動しない場合は、管理クラスタの Cluster API コントローラのログを調べてデバッグを試すことができます。

kube-system Namespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、grep または同様のツールを使用してエラーを検索します。
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```

管理クラスタのコントロールプレーンノードの kubeconfig を使用した F5 BIG-IP の問題のデバッグ

GKE On-Prem をインストールすると、管理ワークステーションのホームディレクトリに kubeconfig ファイルが生成されます（internal-cluster-kubeconfig-debug という名前）。この kubeconfig ファイルは、管理コントロールプレーンが実行される管理クラスタのコントロールプレーンノードを直接参照することを除いて、管理クラスタの kubeconfig と同じです。この internal-cluster-kubeconfig-debug ファイルを使用して、F5 BIG-IP の問題をデバッグできます。

`gkectl check-config` 検証が失敗: F5 BIG-IP パーティションが見つからない

現象: F5 BIG-IP パーティションが存在している場合でも見つからず、検証で不合格になります。
考えられる原因: F5 BIG-IP API に問題があると、検証が失敗することがあります。
解決策: もう一度 gkectl check-config を実行してみてください。

`gkectl prepare --validate-attestations` が失敗: ビルド証明書を検証できない

現象

オプションの --validate-attestations フラグを指定して gkectl prepare を実行すると、次のエラーが返されます。

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY

考えられる原因

影響を受けるイメージの証明書が存在しない可能性があります。

解決策

管理ワークステーションの作成の説明に従って、管理ワークステーションの OVA をもう一度ダウンロードしてデプロイしてみてください。問題が解決しない場合は、Google にお問い合わせください。

ブートストラップクラスタのログを使用したデバッグ

インストール時、GKE On-Prem により一時的なブートストラップクラスタが作成されます。インストールが正常に完了した後、GKE On-Prem によってブートストラップクラスタが削除され、管理クラスタとユーザークラスタが残されます。通常、このクラスタを操作する理由はありません。

インストール中に問題が発生し、gkectl create cluster に --cleanup-external-cluster=false が渡された場合は、ブートストラップクラスタのログを使用してデバッグすると便利です。Pod を見つけてログを取得できます。

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

静的 IP アドレスを使用したインストール

概要

始める前に

インストール用のコンテナ イメージ レジストリを選択する

Container Registry

非公開 Docker レジストリ

インストール用の非公開 Docker レジストリを構成する（省略可）

レジストリ構成のトラブルシューティング

静的 IP アドレスを構成する

管理クラスタの静的 IP アドレス

ユーザー クラスタの静的 IP アドレス

管理ワークステーションでサービス アカウントの秘密鍵を作成する

サービス アカウントのメールアドレスを一覧表示する

許可リストに登録されたサービス アカウント

登録サービス アカウント

接続サービス アカウント

Cloud Monitoring サービス アカウント

構成ファイルの生成

構成ファイルの変更

bundlepath

vCenter の仕様

vcenter.credentials.address

vcenter.credentials

vcenter.datacenter、.datastore、.cluster、.network

vcenter.resourcepool

vcenter.datadisk

vcenter.cacertpath

プロキシの仕様

管理クラスタの仕様

admincluster.vcenter.network

admincluster.ipblockfilepath

admincluster.manuallbspec（手動負荷分散モード）

admincluster.bigip.credentials（統合負荷分散モード）

admincluster.bigip.partition（統合負荷分散モード）

admincluster.vips

admincluster.serviceiprange と admincluster.podiprange

ユーザー クラスタの仕様

VMware DRS の反アフィニティ ルールの無効化（省略可）

usercluster.vcenter.network

usercluster.ipblockfilepath

usercluster.manuallbspec（手動負荷分散モード）

usercluster.bigip.credentials（統合負荷分散モード）

usercluster.bigip.partition（統合負荷分散モード）

usercluster.vips

usercluster.serviceiprange と usercluster.podiprange。

usercluster.clustername

usercluster.masternode.replicas

usercluster.masternode.cpus と usercluster.masternode.memorymb

usercluster.workernode.replicas

usercluster.workernode.cpus と usercluster.workernode.memorymb