バージョン 1.6

DHCP を使用したインストール

このページでは、既存の動的ホスト構成プロトコル(DHCP)サーバーを使用して GKE On-Prem を VMware vSphere 6.5 または 6.7 Update 3 環境にインストールし、IP アドレスをクラスタノードに割り当てる方法について説明します。静的 IP を使用してインストールすることもできます。

概要

このページでは、管理クラスタと 3 つのノードを持つ 1 つのユーザー クラスタを作成する方法を説明します。各ノードは vSphere クラスタ内の仮想マシン(VM)上で運用され、各ノードには環境内の DHCP サーバーによって割り振られた IP アドレスがあります。

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

始める前に

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

  2. インストールの準備の手順を完了します。

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

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

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
  5. プロキシ経由で使用する場合、すべての gkectl コマンドは、管理ワークステーションからのインターネット リクエスト用に config.yaml で設定されたものと同じプロキシを自動的に使用します。これは推奨される環境であり、管理ワークステーションとすべてのクラスタが同じプロキシを使用します。このユースケースでは、プロキシ環境変数を設定する必要はありません。

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

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

    次のオプションを使用して、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
  6. Google Cloud ユーザー アカウントの認証情報を使用して Google Cloud にログインします。ユーザー アカウントには、少なくとも閲覧者の IAM ロールが必要です。

    gcloud auth login
  7. プロキシを使用している場合は、gcloud コマンドと gsutil コマンドがそのプロキシを使用するように Cloud SDK を構成する必要があります。手順については、プロキシ / ファイアウォールの背後で Cloud SDK を使用する場合の構成をご覧ください。

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

    gcloud config set project [PROJECT_ID]
    

    [PROJECT_ID] は、実際のプロジェクト ID に置き換えます。(プロジェクト ID は Cloud Console で確認できます。また、gcloud config get-value project を実行して確認することもできます)。

クラスタノードへの DHCP 予約の使用

Kubernetes では、ノードの IP アドレスを変更しないことが重要です。ノードの IP アドレスが変更されるか、使用不能になると、クラスタが破損する可能性があります。これを防ぐには、管理者とユーザーのクラスタ内でパーマネント アドレスノードを割り当てるために DHCP 予約を使用することを検討してください。DHCP 予約を使用すると、再起動やリース更新の後に各ノードに同じ IP アドレスが必ず割り当てられます。

管理クラスタとユーザー クラスタに必要な IP アドレス

DHCP サーバーは、管理者ノードとユーザー クラスタノードに十分な IP アドレスを提供できる必要があります。

管理クラスタに必要な IP アドレス

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

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

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

作成する非 HA ユーザー クラスタの数を N とし、作成する HA ユーザー クラスタの数を H とします。すると、DHCP サーバーは、少なくともこの数の IP アドレスを管理クラスタノードに提供できる必要があります。

4 + N + 3 x H

たとえば、管理クラスタと 1 つの HA ユーザー クラスタを作成するとします。すると、DHCP サーバーは、7 個の IP アドレスを管理クラスタに提供する必要があります。

ユーザー クラスタに必要な IP アドレス

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

たとえば、5 つのノードを持つユーザー クラスタを作成するとします。すると、DHCP サーバーはユーザー クラスタに 6 個の IP アドレスを提供する必要があります。

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

インストールするには、コンテナ化されたクラスタ コンポーネントを 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 から次の操作を行います。

  1. 証明書を保持するフォルダを作成します。

    sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
    

    [REGISTRY_SERVER] は、Docker レジストリを実行する VM の IP アドレスまたはホスト名です。

  2. 証明書ファイルを /etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt にコピーします。もともと別の名前であった場合でも、ファイル名を ca.crt にする必要があります。

  3. Docker サービスを再起動します。

    sudo service docker restart
  4. 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 が証明書を信頼していません。

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

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

gcloud iam service-accounts list
... EMAIL
    component-accesss-sa@my-gcp-project.iam.gserviceaccount.com
    connect-register-sa@my-gcp-project.iam.gserviceaccount.com
    connect-agent-sa@my-gcp-project.iam.gserviceaccount.com
    log-mon-sa@my-gcp-project.iam.gserviceaccount.com

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

コンポーネント アクセス サービス アカウント

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

ここで、[COMPOONENT_ACCESS_SERVICE_ACCOUNT_EMAIL] は、コンポーネント アクセス サービス アカウントのメールアドレスです。

Connect-register サービス アカウント

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

ここで、[CONECT_REGISTER_SERVICE_ACCOUNT_EMAIL] は、connect-register サービス アカウントのメールアドレスです。

Connect-agent サービス アカウント

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

ここで、[CONNECT_AGENT_SERVICE_ACCOUNT_EMAIL] は、connect-agent サービス アカウントのメールアドレスです。

Logging-monitoring サービス アカウント

gcloud iam service-accounts keys create logging-monitoring-key.json \
--iam-account [LOGGING_MONITORING_SERVICE_ACCOUNT_EMAIL]

ここで、[LOGGING_MONITORINGH_SERVICE_ACCOUNT_EMAIL] は、logging-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.5.2-gke.3 です。

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

vCenter の仕様

vCenter Server の仕様 vcenter には、環境にインストールするために 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.credentialsusername 値と 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"

管理クラスタの仕様

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

admincluster.vcenter.network

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

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

admincluster.ipblockfilepath

このフィールドは、静的 IP を使用している場合に使用されます。IP アドレスの割り振りに DHCP サーバーを使用しているため、admincluster.ipblockfilepath フィールドはコメントアウトしたままにします。

admincluster.bigip.credentials(統合負荷分散モード)

統合負荷分散モードを使用している場合、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.credentials(統合負荷分散モード)

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

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

admincluster.vips

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

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

admincluster.serviceiprangeadmincluster.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 アドレスの割り振りに DHCP サーバーを使用しているため、usercluster.ipblockfilepath フィールドはコメントアウトしたままにします。

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

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

usercluster.serviceiprangeusercluster.podiprange

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

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

例:

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.cpususercluster.masternode.memorymb

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

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

usercluster.workernode.replicas

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

usercluster.workernode.cpususercluster.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)が導入されています。こうしたフィールドで、Cloud Console からクラスタにログインできるようになります。

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

バージョン 1.0.2-gke.3 では、OIDC を使用する場合でも、Cloud Console からクラスタにログインしない場合でも、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

DHCP で統合負荷分散を使用できます。統合負荷分散モードは、管理クラスタと初期ユーザー クラスタに適用されます。また、今後作成するユーザー クラスタにも適用されます。統合負荷分散モードは、ロードバランサとしての F5 BIG-IP の使用をサポートします。

lbmode の値を Integrated に設定します。例:

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.enablevpctrue に設定します。これにより、すべてのテレメトリーが 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 アドレスに設定します。usernamepassword を、非公開 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/component-access-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 config.yaml

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

時間のかかる検証をスキップする場合は、--fast フラグを渡します。個別の検証をスキップするには、--skip-validation-xxx フラグを使用します。check-config コマンドについて詳しくは、プリフライト チェックの実行をご覧ください。

gkectl prepare を実行する

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

  • ノードの OS イメージを vSphere にインポートし、テンプレートとしてマークします。

  • 必要に応じて、コンテナ イメージのビルド証明書を検証します。これにより、イメージが 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 をインストールするには、管理クラスタとユーザー クラスタを作成します。次の手順では、同じプロセスで管理クラスタとユーザー クラスタの両方を作成します。各クラスタを個別に作成する場合は、管理クラスタとユーザー クラスタを個別に作成するをご覧ください。

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

  1. 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]
  2. クラスタが作成され、運用中であることを確認します。

    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
      

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

インストールの再開

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

  1. 構成ファイルから admincluster 仕様を削除します。
  2. --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 に接続する

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 オブジェクトを使用できるようになりました。

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

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] は、ユーザー クラスタの構成ファイルです。

制限事項

制限 説明
クラスタとノードの上限と下限

割り当てと上限をご覧ください。環境のパフォーマンスがこれらの上限に影響することがあります。

ユーザー クラスタ名の一意性

同じ Google Cloud プロジェクトに登録されているすべてのユーザー クラスタに一意の名前を付ける必要があります。

複数の vCenter / vSphere データセンターにはデプロイできない

現時点では、管理クラスタと関連するユーザー クラスタのセットは、1 つの vCenter / vSphere データセンターにのみデプロイできます。同じ管理クラスタとユーザー クラスタを、複数の vCenter / vSphere データセンターにはデプロイできません。

作成後にクラスタ構成を宣言型の方法で変更できない 追加のクラスタの作成既存のクラスタのサイズ変更はできますが、既存のクラスタを構成ファイルで変更することはできません。

トラブルシューティング

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

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

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

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

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

  • デフォルトでは、ログエントリは次のように保存されます。

    • gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカル ディレクトリの logs/gkectl-$(date).log ファイルにシンボリック リンクされます。
    • gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカル ディレクトリの logs/gkeadm-$(date).log です。
  • すべてのログエントリは、ターミナルに出力されていない場合(--alsologtostderrfalse の場合)でもログファイルに保存されます。
  • -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]

次のステップ