このページでは、静的 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
を実行すると、これらのフィールドに入力されます。入力した値は、必要に応じて任意の値に変更できます。
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.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]
クラスタが作成され、運用中であることを確認します。
管理クラスタを確認するには、次のコマンドを実行します。
kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
出力には、管理クラスタノードが表示されます。
ユーザー クラスタを確認するには、次のコマンドを実行します。
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]