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

利用可能なバージョン

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

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

概要

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

クラスタを作成したら、追加のユーザークラスタを作成して、ユーザークラスタ内のノードを追加または削除できます。

始める前に

システム要件の説明に従い、オンプレミス環境を設定します。
インストールの準備の手順を完了します。
vSphere で管理ワークステーションを作成します。
必要な場合は、手動負荷分散を有効にする方法をご覧ください。
管理ワークステーションに SSH 接続します。
```
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
```
プロキシを使用している場合は、プロキシ用に Google Cloud CLI を構成して、gcloud コマンドと gsutil コマンドを実行できるようにする必要があります。手順については、プロキシ / ファイアウォールの背後で gcloud CLI を使用する場合の構成をご覧ください。
アカウントの認証情報を使用して Google Cloud にログインします。
```
gcloud auth login
```
gcloud を Docker 認証情報ヘルパーとして登録します（コマンドの詳細はこちらをご覧ください）。
```
gcloud auth configure-docker
```
デフォルトのプロジェクトを設定します。デフォルトの Google Cloud を設定すると、すべての gcloud CLI コマンドはプロジェクトに対して実行されます。コマンドごとにプロジェクトを指定する必要はありません。
```
gcloud config set project [PROJECT_ID]
```
[PROJECT_ID] は実際のプロジェクト ID に置き換えます（プロジェクト ID は Google Cloud コンソールで確認できます。また、gcloud config get-value project を実行して確認することもできます）。

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

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

Container Registry

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

非公開 Docker レジストリ

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

インストールする前に、レジストリを構成する必要があります。インストール中、GKE On-Prem 構成ファイルにレジストリに関する情報を入力する必要があります。

インストール用の非公開 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 の構成

インストール中に、GKE On-Prem 構成ファイルを生成します。その構成ファイルには、次に挙げる 2 つの ipblockfilepath フィールドが含まれています。

admincluster.ipblockfilepath
usercluster.ipblockfilepath

ipblockfilepath は、以下に説明するように、ホスト構成（または hostconfig）ファイルを含む YAML ファイルへのパスを受け入れます。

静的 IP を使用する場合は、管理ワークステーションに 2 つの YAML ファイルを作成する必要があります。1 つは hostconfig を含むもので管理クラスタで使用され、もう 1 つはユーザークラスタで使用されます。

管理クラスタ IP 構成には、N + 4 個以上の IP / ホスト名のペアが必要です。N は、作成するユーザークラスタの数です。

高可用性ユーザークラスタを作成することもできます。HA ユーザークラスタは 3 つのユーザーコントロールプレーンを使用します。ユーザーコントロールプレーンを実行する各 VM には、独自の静的 IP が必要です。ユーザーコントロールプレーンは管理クラスタによって管理されるため、これらの値は管理クラスタの hostconfig ファイルで指定する必要があります。

例

3 つのホストを持つ hostconfig ファイルの例を次に示します。環境により、ファイルの見た目が異なる場合があります。たとえば、ip / hostname のペアを増やして ips 配列を拡張するとします。

hostconfig:
  dns: 172.16.255.1
  tod: 192.138.210.214
  otherdns:
  - 8.8.8.8
  - 8.8.4.4
  othertod:
  - ntp.ubuntu.com
blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1
    ips:
    - ip: 10.116.232.23
      hostname: host1.enterprise.net  # will be trimmed to host1
    - ip: 10.116.232.65
      hostname: host2.enterprise.net  # will be trimmed to host2
    - ip: 10.116.232.66
      hostname: host3.enterprise.net  # will be trimmed to host3

YAML ファイルには、hostconfig と blocks という 2 つのセクションがあります。

`hostconfig`

hostconfig には、クラスタのすべてのノードに静的に適用されるネットワークパラメータが含まれます。hostconfig は、次の値を構成します。

dns: ノードに使用する DNS サーバーの IP アドレス。
tod: ノードに使用する時刻サーバーの IP アドレス。
otherdns: ノードに使用する代替 DNS サーバー。
othertod: ノードに使用する代替時刻サーバー。

`blocks`

blocks は、静的 IP アドレスブロックの配列を格納します。現在、GKE On-Prem では IP 割り振りの最初のブロックのみが考慮されます。各ブロックは、ネットワークとその中の IP アドレスを表します。

`netmask` と `gateway`

netmask と gateway は、ノードに使用するネットワークマスクとデフォルトゲートウェイを表します。

blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1

`ips`

ips 配列には、割り振った IP が入ります。配列内の各オブジェクトには、IPv4 アドレスとそのホスト名が含まれます。

blocks:
...
  ips:
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
...

GKE On-Prem は、このブロック内の空き IP アドレスと割り当てられた IP アドレスを追跡し、1 つの使用可能な IP アドレスをクラスタ内の各ノードに割り振ります。配列内の IP アドレスの数がクラスタ内のノードの数よりも厳密に多く、各 IP アドレスが環境のネットワークに固有であることを確認してください。

hostname、ドメインのないローカルホスト名として解釈されます。完全修飾ドメイン名（FQDN）を指定した場合、ドメイン名は削除されます。たとえば、host1.enterprise.net は host1 になります。hostname の値は小文字であることが必要です。

`hostconfig` ファイルを作成する

3 つのノードがあるユーザークラスタの hostconfig ファイルの例を次に示します。

次のテンプレートを YAML ファイルにコピーします。

hostconfig:
  dns:
  tod:
blocks:
  - netmask:
    gateway:
    ips:
    - ip:
      hostname:
    - ip:
      hostname:
    - ip:
      hostname:

ファイルを別の名前（admin-cluster-hostconfig.yaml、user-cluster-hostconfig.yaml など）で保存します。
インストール中、構成ファイルの admincluster.ipblockfilepath フィールドと usercluster.ipblockfilepath フィールドを適切なファイルで変更します。

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

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

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

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

gcloud iam service-accounts list

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

gcloud iam service-accounts list
NAME                                    EMAIL
                                        access-service-account@my-gcp-project.iam.gserviceaccount.com
                                        register-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-service-account@my-gcp-project.iam.gserviceaccount.com
                                        stackdriver-service-account@my-gcp-project.iam.gserviceaccount.com

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

アクセスサービスアカウント

gcloud iam service-accounts keys create access-key.json \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

[ACCESS_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 サービスアカウントのメールアドレスです。

Google Cloud CLI のアクセスサービスアカウントの有効化

gcloud CLI のアクセスサービスアカウントを有効にすると、gcloud と gsutil のコマンドすべてが、そのサービスアカウントとして実行されます。アクセスサービスアカウントは GKE On-Prem バイナリへのアクセスを許可されているため、gcloud CLI でアカウントを有効にすると、Cloud Storage から GKE On-Prem のバイナリをダウンロードする権限が付与されます。

アクセスサービスアカウントを有効にするには、次のコマンドを実行します。アカウントの鍵ファイルへのパスを指定してください（現在の作業ディレクトリにない場合）。

gcloud auth activate-service-account --key-file=access-key.json

構成ファイルの生成

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

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

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

構成ファイルの変更

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

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.1.2-gke.0 です。

バンドルファイルは別の場所に保存できます。また、別の名前を付けることもできます。構成ファイルで、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 my-gke-on-prem-folder

現在、報告されている問題により、フォルダのファイルパスではなく、Universally Unique Identifier（UUID）のパスを vcenter.datadisk に指定する必要があります。フォルダの UUID を確認するには、vCenter Client を開き、データストアを選択し、フォルダを選択します。フォルダの UUID をコピーします。次のコマンドを実行することもできます。ここで、[ADMIN_CONTROL_PLANE_VM] は管理コントロールプレーンを実行する vSphere VM です。

govc vm.info -json ./vm/[ADMIN_CONTROL_PLANE_VM] | jq '.VirtualMachines[0].Config.Hardware.Device[] | select(.Backing | has("FileName")) | .Backing.FileName'

次に、vcenter.datadisk フィールドにフォルダの UUID を入力します。例:

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

vcenter.cacertpath

GKE On-Prem などのクライアントが vCenter Server にリクエストを送信する場合、サーバーは証明書を提示してクライアントに自身の ID を証明する必要があります。証明書は認証局（CA）によって署名されます。クライアントは、CA 証明書を使用してサーバーの証明書を検証します。

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

vcenter:
  ...
  cacertpath: "/my-cert-folder/altostrat.crt"

vCenter Server で自己署名証明書を使用する場合も、公開 CA が署名する証明書を使用する場合も、管理ワークステーションで次のコマンドを実行して CA 証明書を取得できます。

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

ここで、[VCENTER_IP] は vCenter Server の IP アドレスです。

プロキシの仕様

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

proxy:
  url: "https://password:username@domain"
  noproxy: "100.151.222.0/24,corp.domain,100.151.2.1"

proxy.url は HTTPS プロキシの URL です。
proxy.noproxy には、プロキシを使用しない CIDR、ドメイン、IP アドレスが含まれます。非公開 Docker レジストリを使用している場合、これには通常、vSphere サブネットと非公開レジストリのアドレスが含まれます。

管理クラスタの仕様

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（手動負荷分散モード）

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

admincluster:
  ...
  manuallbspec:
    ingresshttpnodeport: 32527
    ingresshttpsnodeport: 30139

管理クラスタの 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 の反アフィニティルールの無効化（省略可）

バージョン 1.1.0-gke.6 以降、GKE On-Prem はユーザークラスタのノードに対して VMware Distributed Resource Scheduler（DRS）の反アフィニティルールを自動的に作成し、データセンター内の少なくとも 3 つの物理ホストにそれらを分散させます。バージョン 1.1.0-gke.6 以降、この機能は新しいクラスタと既存のクラスタで自動的に有効になります。

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

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

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

usercluster:
  ...
  antiaffinitygroups:
    enabled: false

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 キーファイルのパスに設定します。

Connect エージェントがプロキシを使用して Google Cloud と通信できるようにするには、gkeconnect.proxy の値をプロキシの URL に設定します。形式 http(s)://[PROXY_ADDRESS] を使用します。

例:

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

`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 レジストリのユーザー名とパスワードに設定します。

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

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

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

`gcrkeypath`

gcrkeypath の値を、アクセスサービスアカウントの JSON キーファイルのパスに設定します。例:

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

`cloudauditlogging`

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

cloudauditlogging:
  projectid: "my-project"
  # A GCP 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 GCP 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]

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

検証のスキップ

次の 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 です。

GKE On-Prem のインストール

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

GKE On-Prem をインストールするには、次のコマンドを実行します。

gkectl create cluster --config [CONFIG_FILE]

[CONFIG_FILE] は、生成して変更した構成ファイルです。

構成ファイルを再利用して追加のユーザークラスタを作成できます。

インストールの再開

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

構成ファイルから admincluster 仕様を削除します。
gkectl create cluster を再度実行し、管理クラスタの kubeconfig ファイルを渡します。

gkectl create cluster --config [CONFIG_FILE] \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

[ADMIN_CLUSTER_NAME] は、インストールを開始したときに作業ディレクトリに作成された管理クラスタの kubeconfig です。

既知の問題

現在、HA ユーザークラスタを作成する際、インストールを再開することはできません。この問題は、今後のリリースで修正される予定です。

クラスタを 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 の制限事項

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

トラブルシューティング

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

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

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

デフォルトのロギング動作

gkectl と gkeadm では、デフォルトのロギング設定を使用するだけで十分です。

デフォルトでは、ログエントリは次のように保存されます。
- gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカルディレクトリの logs/gkectl-$(date).log ファイルにシンボリックリンクされます。
- gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカルディレクトリの logs/gkeadm-$(date).log です。
すべてのログエントリは、ターミナルに出力されていない場合（--alsologtostderr が false の場合）でもログファイルに保存されます。
-v5 詳細レベル（デフォルト）は、サポートチームが必要とするログエントリすべてを対象としています。
ログファイルには、実行されたコマンドと失敗メッセージも含まれます。

サポートが必要な場合は、サポートチームにログファイルを送信することをおすすめします。

ログファイルにデフォルト以外の場所を指定する

gkectl ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。指定したログファイルは、ローカルディレクトリにシンボリックリンクされません。

gkeadm ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。

管理クラスタで 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 の構成

例

hostconfig

blocks

netmask と gateway

ips

hostconfig ファイルを作成する

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

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

アクセス サービス アカウント

登録サービス アカウント

接続サービス アカウント

Cloud Monitoring サービス アカウント

Google Cloud CLI のアクセス サービス アカウントの有効化