このページでは、既存の動的ホスト構成プロトコル(DHCP)サーバーを使用して GKE On-Prem を VMware vSphere 6.5 環境にインストールし、IP アドレスをクラスタノードに割り振る方法について説明します。静的 IP を使用してインストールすることもできます。
概要
このページでは、管理クラスタと、ノードが 3 つある 1 つのユーザー クラスタを作成する方法について説明します。各ノードは vSphere クラスタ内の仮想マシン(VM)上で運用され、各ノードには環境内の DHCP サーバーによって割り振られた IP アドレスがあります。
クラスタを作成したら、追加のユーザー クラスタを作成して、ユーザー クラスタ内のノードを追加または削除できます。
始める前に
システム要件の説明に従い、オンプレミス環境を設定します。
インストールの準備の手順を完了します。
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
を実行して確認することもできます)。
クラスタノードへの DHCP 予約の使用
Kubernetes では、ノードの IP アドレスを変更しないことが重要です。ノードの IP アドレスが変更されるか、使用不能になると、クラスタが破損する可能性があります。これを防ぐには、管理者とユーザーのクラスタ内でパーマネント アドレスノードを割り当てるために DHCP 予約を使用することを検討してください。DHCP 予約を使用すると、再起動やリース更新の後に各ノードに同じ IP アドレスが必ず割り振られます。
インストール用のコンテナ イメージ レジストリを選択する
インストールするには、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 が証明書を信頼していません。
管理ワークステーションでサービス アカウントの秘密鍵を作成する
インストールの準備では、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 のバンドルは YAML ファイルのセットです。YAML ファイルには、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 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.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 アドレスです。
プロキシの仕様
proxy
フィールドには、ユーザー提供の HTTPS プロキシ情報と、プロキシから除外するアドレスが保持されます。例:
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 アドレスの割り振りに 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.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 を有効にする方法については、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 アドレスの割り振りに 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.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
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 キーファイルのパスに設定します。
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 にインポートし、テンプレートとしてマークします。
必要に応じて、コンテナ イメージのビルド証明書を検証します。これにより、イメージが 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 オブジェクトを使用できるようになりました。
制限事項
制限 | 説明 |
---|---|
クラスタとノードの上限と下限 | 割り当てと上限をご覧ください。環境のパフォーマンスがこれらの上限に影響することがあります。 |
ユーザー クラスタ名の一意性 | 同じ 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]