GKE On-Prem のインストール

このページでは、vSphere に GKE On-Prem をインストールする方法について説明します。このページの手順では、管理クラスタと 1 つのユーザー クラスタを作成する方法について説明します。管理クラスタと初期ユーザー クラスタを作成したら、追加のユーザー クラスタを作成できます。

始める前に

  1. システム要件の説明に従い、オンプレミス環境を設定します。

  2. 開始の手順を完了します。

  3. vSphere で管理ワークステーションを作成します。

  4. 必要な場合は、非公開 Docker レジストリを作成します。

  5. 必要な場合は、手動負荷分散を有効にする方法をご覧ください。

  6. 必要な場合は、静的 IP を構成します。

  7. 管理ワークステーションに SSH で接続します。

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

  8. gcloud を承認して Google Cloud にアクセスします。

    gcloud auth login

  9. gcloud を Docker 認証ヘルパーとして登録します（コマンドの詳細はこちらをご覧ください）。

    gcloud auth configure-docker

  10. デフォルトのプロジェクトを設定します。デフォルトの Google Cloud を設定すると、すべての gcloud CLI コマンドはプロジェクトに対して実行されます。コマンドごとにプロジェクトを指定する必要はありません。

    gcloud config set project [PROJECT_ID]

    [PROJECT_ID] は実際のプロジェクト ID に置き換えます（プロジェクト ID は Google Cloud コンソールで確認できます。また、gcloud config get-value project を実行して確認することもできます）。

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

スタートガイドでは、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-file \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

[ACCESS_SERVICE_ACCOUNT_EMAIL] は、アクセス サービス アカウントのメールアドレスです。

登録サービス アカウント

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

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

接続サービス アカウント

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

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

Cloud Monitoring サービス アカウント

gcloud iam service-accounts keys create stackdriver-key \
--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 のバンドルは YAML ファイルのセットです。YAML ファイルには、GKE On-Prem の特定のリリースに含まれるすべてのコンポーネントがまとめて記述されています。

管理ワークステーションを作成すると、/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz にバンドルが追加されます。

bundlepath の値をバンドル ファイルのパスに設定します。すなわち、bundlepath を以下に設定します。

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

[VERSION] は、インストールする GKE On-Prem のバージョンです。

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

gkeplatformversion

gkeplatformversion フィールドには、インストールする GKE On-Prem リリースの Kubernetes バージョンが保持されます。形式は次のとおりです。

[KUBERNETES_VERSION]-[GKE_PATCH]

Kubernetes バージョンの例は、1.12.7-gke.19 です。

gkectl create-config を実行すると、このフィールドに値が入力されます。

bundlepath と gkeplatformversion のバージョニング スキームは異なります。ただし、特定のバンドル バージョンには、対応する GKE プラットフォーム バージョンがあります。たとえば、バンドル バージョンが 1.0.10 の場合、GKE プラットフォームのバージョンは 1.12.7-gke.19 である必要があります。

バンドル バージョンと GKE プラットフォーム バージョン間の対応については、バンドル ファイルを抽出して YAML ファイルをご覧ください。特に、gke-onprem-vsphere-[VERSION]-images.yaml を開き、osImages フィールドを確認します。GKE プラットフォームのバージョンは、OS イメージ ファイルの名前で確認できます。たとえば、次の OS イメージでは、GKE プラットフォームのバージョンが 1.12.7-gke.19 であることがわかります。

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

vcenter

このフィールドを使用して、vCenter Server の全般設定を宣言します。GKE On-Prem では、vCenter Server インスタンスの IP アドレス、ユーザー名、パスワードの情報が必要です。vcenter で値を設定して、この情報を指定します。例:

vcenter:
  credentials:
    address: "203.0.113.1"
    username: "my-name"
    password: "my-password"

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

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

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

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

GKE On-Prem で VMDK をディレクトリに配置する場合は、事前にディレクトリを手動で作成しておく必要があります。たとえば、govc を使用してディレクトリを作成できます。

govc datastore.mkdir my-gke-on-prem-directory

このディレクトリを vcenter.datadisk フィールドに含めることができます。

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

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

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

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

CA 証明書のダウンロードについては、vCenter Server のルート証明書をダウンロードしてインストールする方法をご覧ください。

vCenter Server で自己署名証明書を使用している場合は、管理ワークステーションから openssl で vCenter に接続して証明書を抽出できます。

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

gcrkeypath

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

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

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-directory/register-key.json"
  agentserviceaccountkeypath: "/my-key-directory/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 リージョンに設定します。お使いのオンプレミス データセンターの近くのリージョンを選択することをおすすめします。

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

例:

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  proxyconfigsecretname: ""
  enablevpc: false
  serviceaccountkeypath: "/my-key-directory/logging-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-directory/registry-ca.crt

admincluster

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

vCenter ネットワーク - 管理クラスタ

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

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

DHCP または静的 IP アドレス - 管理クラスタ

動的ホスト構成プロトコル（DHCP）を使用して、管理クラスタノードに IP アドレスを割り振るかどうかを決定します。別の方法として、クラスタノードに静的 IP アドレスを使用することもできます。手動負荷分散モードを選択した場合は、クラスタノードに静的 IP アドレスを使用する必要があるため注意してください。

DHCP を使用する場合は、admincluster.ipblockfilepath フィールドをコメントアウトしたままにします。

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

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

統合負荷分散 - 管理クラスタ

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

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

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

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

手動負荷分散 - 管理クラスタ

手動負荷分散モードを使用する場合は、クラスタノードに静的 IP アドレスを使用する必要があります。admincluster.ipblockfilepath に値が設定されていることを確認します。次に例を示します。

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

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

vips - 管理クラスタ

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

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

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

serviceiprange と podiprange - 管理クラスタ

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

Service と Pod の範囲は重複しないようにします。また、管理クラスタに選択した Service と Pod の範囲は、ユーザー クラスタに選択した Service と Pod の範囲と重複しないようにする必要があります。

例:

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

usercluster

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

vCenter ネットワーク - 管理クラスタ

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

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

DHCP または静的 IP アドレス - ユーザー クラスタ

DHCP を使用して IP アドレスをユーザー クラスタノードに割り当てるかどうかを決定します。別の方法として、クラスタノードに静的 IP アドレスを使用することもできます。手動負荷分散モードを選択した場合は、クラスタノードに静的 IP アドレスを使用する必要があるため注意してください。

DHCP を使用する場合は、usercluster.ipblockfilepath フィールドをコメントアウトしたままにします。

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

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

統合負荷分散 - ユーザー クラスタ

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

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

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

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

手動負荷分散 - ユーザー クラスタ

手動負荷分散モードを使用する場合は、クラスタノードに静的 IP アドレスを使用する必要があります。usercluster.ipblockfilepath に値が設定されていることを確認します。次に例を示します。

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

ユーザー クラスタの 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

vips - ユーザー クラスタ

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

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

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

serviceiprange と podiprange - ユーザー クラスタ

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

Service と Pod の範囲は重複しないようにします。また、ユーザー クラスタに選択した Service と Pod の範囲は、管理クラスタに選択した Service と Pod の範囲と重複しないようにする必要があります。

例:

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

clustername

usercluster.clustername の値を任意の名前に設定します。例:

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

masternode

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

  • 1 つのユーザー コントロール プレーンを実行する場合は、このフィールドを 1 に設定します。
  • 高可用性ユーザー コントロール プレーンを使用する場合は、このフィールドを 3 に設定します。3 つのコントロール ユーザー コントロール プレーンが作成されます。

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

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

oidc

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

バージョン 1.0.2-gke.3 で、次の必須フィールドが追加されました。これらのフィールドにより、Google Cloud コンソールからクラスタにログインできます。

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

Google Cloud コンソールからクラスタにログインせずに、OIDC を使用する必要がある場合は、これらのフィールドのプレースホルダの値を渡すことができます。

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

詳細については、OIDC による認証をご覧ください。

sni

ユーザー クラスタの Kubernetes API サーバーに追加のサービス証明書を提供する場合は、usercluster.sni.certpath と usercluster.sni.keypath の値を指定します。例:

usercluster:
  ...
  sni:
    certpath: "/my-cert-directory/my-second-cert.crt"
    keypath: "/my-cert-directory/my-second-cert.key"

workernode

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

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

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

構成ファイルの検証

構成ファイルを変更したら、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] は、生成して変更した構成ファイルです。

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

クラスタを Google に接続する

  • ユーザー クラスタを作成すると、自動的に 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 つ以上指定する必要があります。

証明書を提供するには:

  1. 証明書と鍵を保持する Secret を作成します。
  2. 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 オブジェクトを使用できるようになりました。

トラブルシューティング

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

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 コントローラのログを調べてデバッグを試すことができます。

  1. kube-system Namespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. 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]

次のステップ