このドキュメントでは、GKE on VMware の管理クラスタを作成する方法について説明します。管理クラスタでは、管理クラスタ自体と関連するユーザー クラスタに対して Kubernetes コントロール プレーンが実行されます。ユーザー クラスタを作成してワークロードを実行する前に、管理クラスタを作成する必要があります。
管理クラスタの詳細については、インストールの概要をご覧ください。
手順の概要
管理クラスタの作成に関わる主な手順は次のとおりです。
- 管理ワークステーションを準備する。
- このマシンには、新しいクラスタの作成に必要なツールが備わっています。
- 構成ファイルの入力
- 管理クラスタの構成ファイル、認証情報構成ファイル、（状況により）IP ブロック ファイルを完成させて検証し、新しい管理クラスタの詳細を指定します。
- OS イメージを vSphere にインポートし、該当する場合はコンテナ イメージをプライベート レジストリに push します。
gkectl prepareを実行します。
- （省略可）Seesaw ロードバランサを作成する。
- Seesaw ロードバランサを使用することを決定した場合は、
gkectl create loadbalancerを実行します。
- 管理クラスタを作成する。
gkectlを使用して、完成した構成ファイルで指定した新しい管理クラスタを作成します。一時的なブートストラップ クラスタ内のonprem-admin-cluster-controllerが、管理クラスタの作成を管理します。
- 管理クラスタが実行されていることを確認します。
kubectlを使用してクラスタノードを表示します。
この手順を完了すると、実行中の管理クラスタでユーザー クラスタの作成と管理が可能になります。
準備
IP アドレス計画のドキュメントを確認します。使用可能な IP アドレスが十分にあることを確認し、クラスタノードが DHCP または静的 IP アドレスを取得する方法を再確認します。静的 IP アドレスを使用する場合は、選択したアドレスを含む IP ブロック ファイルに入力する必要があります。
ロード バランシングの概要を確認し、使用するロードバランサの種類に関する決定を再確認してください。特定のロードバランサについては、管理クラスタを作成する前にロードバランサを設定する必要があります。
privateRegistryセクションを確認し、GKE on VMware コンポーネントにパブリック レジストリとプライベート レジストリのどちらを使用するかを決定します。osImageType フィールドで今後のことを考えて、管理クラスタノードで実行するオペレーティング システムの種類を決定する。
1. 管理ワークステーションを準備する
管理ワークステーションを作成するの説明に従って、管理ワークステーションを設定してログインできることを確認します。管理ワークステーションには、管理クラスタの作成に必要なツールが備わっています。
このトピックの残りの手順はすべて管理ワークステーションで行います。
2. 構成ファイルに入力する
gkeadm が管理用ワークステーションを作成した際に、admin-cluster.yaml という名前の構成ファイルが生成されました。この構成ファイルは、管理クラスタの作成用です。
管理クラスタの構成ファイルのドキュメントを詳しく調べて、構成ファイルをよく理解します。このドキュメントは別のタブまたはウィンドウで開いたままにしておくことをおすすめします。次の手順を実行する際にこれを参照するためです。
name
管理クラスタの名前を指定する場合は、name フィールドに入力します。
bundlePath
バンドルは、クラスタ コンポーネントを含む ZIP ファイルです。これは管理ワークステーションに含まれています。このフィールドはあらかじめ入力されています。
vCenter
このセクションのほとんどのフィールドには、管理ワークステーションの作成時に指定した値がすでに入力されています。dataDisk フィールドは例外で、ここで値を入力する必要があります。
network
クラスタノードから IP アドレスを取得する方法を決めます。次のオプションがあります。
前もって設定した DHCP サーバーから。
network.ipMode.typeを"dhcp"に設定します。指定した静的 IP アドレスのリストから。
network.ipMode.typeを"static"に設定し、静的 IP アドレスを提供する IP ブロック ファイルを作成します。IP ブロック ファイルの例については、入力済みの構成ファイルの例をご覧ください。
必要に応じて、構成ファイルのネットワーク セクションの残りのフィールドに入力します。
クラスタノードに静的 IP アドレスを使用する場合は、
network.ipMode.ipBlockFilePathフィールドとnetwork.hostconfigセクションは必須です。network.hostconfigセクションには、クラスタノードで使用される NTP サーバー、DNS サーバー、DNS 検索ドメインに関する情報を掲載しています。HA 管理クラスタを使用している場合、または Seesaw ロードバランサを使用している場合は、クラスタノードに DHCP または静的 IP を使用するかどうかにかかわらず、
network.hostconfigセクションが必要です。network.podCIDR フィールドと network.serviceCIDR フィールドには、値が事前に設定されています。この値は、ネットワークですでに使用されているアドレスと競合しない限り変更できません。Kubernetes では、これらの範囲を使用してクラスタ内の Pod と Service に IP アドレスを割り当てます。
DHCP サーバーを使用するか、静的 IP アドレスのリストを指定するかにかかわらず、管理クラスタノードに十分な数の IP アドレスが必要です。これには、関連するユーザー クラスタのコントロール プレーンを実行する管理クラスタ内のノードが含まれます。必要な IP アドレスの数については、IP アドレスを計画するをご覧ください。
高可用性管理クラスタ
高可用性（HA）管理クラスタを作成する場合は、network.controlPlaneIPBlock セクションと network.hostConfig セクションに入力します。また、adminMaster.replicas を 3 に設定します。
高可用性管理クラスタには、コントロール プレーン コンポーネントを実行する 3 つのノードがあります。
HA 管理クラスタには、次の要件と制限があります。
HA 管理クラスタによって管理されるユーザー クラスタは、コントロール プレーン V2 を有効にする必要があります。
HA 管理クラスタでは、Seesaw ロードバランサを使用できません。また、HA 管理クラスタで管理されているユーザー クラスタに Seesaw ロードバランサは使用できません。
loadBalancer
管理クラスタの Kubernetes API サーバー用に VIP を確保します。アドオン サーバーに別の VIP を設定します。loadBalancer.vips.controlPlaneVIP と loadBalancer.vips.addonsVIP の値として VIP を指定します。
詳細については、管理クラスタ サブネット内の VIP をご覧ください。
使用する負荷分散の種類を決めます。次のオプションがあります。
MetalLB バンドルの負荷分散。
loadBalancer.kindを"MetalLB"に設定します。Seesaw によるバンドルされた負荷分散。
loadBalancer.kindを"Seesaw"に設定し、loadBalancer.seesawセクションに入力します。F5 BIG-IP による統合負荷分散。
loadBalancer.kindを"F5BigIP"に設定し、f5BigIPセクションに入力します。手動負荷分散。
loadBalancer.kindを"ManualLB"に設定し、manualLBセクションに入力します。
負荷分散のオプションの詳細については、負荷分散の概要をご覧ください。
antiAffinityGroups
必要に応じて、antiAffinityGroups.enabled を true または false に設定します。
このフィールドを使用して、GKE on VMware に管理クラスタノード用の VMware Distributed Resource Scheduler（DRS）アンチアフィニティ ルールを作成するかどうかを指定すると、管理クラスタノードはデータセンター内の少なくとも 3 つの物理ホストに分散されます。
adminMaster
管理クラスタのコントロール プレーン ノードの CPU とメモリを指定する場合は、adminMaster セクションの cpus と memoryMB フィールドに入力します。
プレビュー: 高可用性管理クラスタを作成する場合は、adminMaster セクションの replicas フィールドを 3 に設定します。それ以外の場合は、1 に設定します。
addonNode
必要に応じて、addonNode.autoResize.enabled を true または false に設定します。
proxy
管理クラスタノードを持つネットワークがプロキシ サーバーの背後にある場合は、proxy セクションに入力します。
privateRegistry
GKE on VMware コンポーネントのコンテナ イメージを保持する場所を決めます。次のオプションがあります。
Container Registry
独自の非公開 Docker レジストリ。
独自の非公開レジストリを使用する場合は、privateRegistry セクションに入力します。
componentAccessServiceAccountKeyPath
GKE on VMware は、コンポーネント アクセス サービス アカウントを使用して、Container Registry からクラスタ コンポーネントをダウンロードします。このフィールドには、コンポーネント アクセス サービス アカウントの JSON キーファイルのパスが格納されます。
このフィールドはあらかじめ入力されています。
gkeConnect
gkeConnect セクションに入力して Google Cloud フリートに管理クラスタを登録します。
構成ファイルに stackdriver セクションと cloudAuditLogging セクションを含める場合、gkeConnect.projectID の ID は stackdriver.projectID と cloudAuditLogging.projectID で設定した ID と同じである必要があります。プロジェクト ID が同じでない場合、クラスタの作成は失敗します。
gkeOnPremAPI
1.16 以降では、Google Cloud プロジェクトで GKE On-Prem API が有効になっている場合、プロジェクト内のすべてのクラスタが、stackdriver.clusterLocation で構成されたリージョンの GKE On-Prem API に登録（自動的に）されます。
GKE On-Prem API のプロジェクトにすべてのクラスタを登録する場合は、始める前にの手順に沿って、プロジェクト内の GKE On-Prem API を有効にしてから使用します。
GKE On-Prem API にクラスタを登録しない場合は、このセクションを追加して、
gkeOnPremAPI.enabledをfalseに設定します。プロジェクトにクラスタを登録しない場合は、プロジェクトでgkeonprem.googleapis.com（GKE On-Prem API のサービス名）を無効にします。手順については、サービスの無効化をご覧ください。
stackdriver
クラスタに対して Cloud Logging と Cloud Monitoring を有効にする場合は、stackdriver セクションに入力します。
デフォルトでは、このセクションは必須です。つまり、このセクションに入力しない場合、gkectl create admin を実行する際に --skip-validation-stackdriver フラグを含める必要があります。
新しいクラスタの要件は次のとおりです。
stackdriver.projectIDの ID は、gkeConnect.projectIDとcloudAuditLogging.projectIDの ID と同じである必要があります。stackdriver.clusterLocationで設定された Google Cloud リージョンは、cloudAuditLogging.clusterLocationで設定されたリージョンと同じである必要があります。また、gkeOnPremAPI.enabledがtrueの場合、同じリージョンをgkeOnPremAPI.locationに設定する必要があります。
プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。
cloudAuditLogging
クラスタの Kubernetes API サーバーの監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging セクションに値を入力します。
新しいクラスタの要件は次のとおりです。
cloudAuditLogging.projectIDの ID は、gkeConnect.projectIDとstackdriver.projectIDの ID と同じである必要があります。cloudAuditLogging.clusterLocationで設定された Google Cloud リージョンは、stackdriver.clusterLocationで設定されたリージョンと同じである必要があります。また、gkeOnPremAPI.enabledがtrueの場合、同じリージョンをgkeOnPremAPI.locationに設定する必要があります。
プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。
clusterBackup
管理クラスタのバックアップを有効にする場合は、clusterBackup.datastore をクラスタのバックアップを保存する vSphere データストアに設定します。
autoRepair
管理クラスタのノードの自動修復を有効にする場合は、autoRepair.enabled を true に設定します。
secretsEncryption
Secret の常時暗号化を有効にする場合は、secretsEncryption セクションに入力します。
osImageType
管理クラスタノードに使用する OS イメージのタイプを決定し、それに応じて osImageType セクションに入力します。
入力済みの構成ファイルの例
入力済みの IP ブロック ファイルと、入力済みの管理者クラスタ構成ファイルの例を以下に示します。この構成により、利用可能な機能のすべてではなく、一部が有効になります。
vc-01-ipblock.yaml
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
- ip: 172.16.20.17
hostname: admin-host8
vc-01-admin-cluster.yaml
apiVersion: v1
kind: AdminCluster
name: "gke-admin-01"
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.11.0-gke.543-full.tgz"
vCenter:
address: "vc01.example"
datacenter: "vc-01"
cluster: "vc01-workloads-1"
resourcePool: "vc-01-pool-1"
datastore: "vc01-datastore-1"
caCertPath: "/usr/local/google/home/me/certs/vc01-cert.pem""
credentials:
fileRef:
path: "credential.yaml"
entry: "vCenter"
dataDisk: "vc01-admin-disk.vmdk"
network:
hostConfig:
dnsServers:
- "203.0.113.1"
- "198.51.100.1"
ntpServers:
- "216.239.35.4"
ipMode:
type: "static"
ipBlockFilePath: "vc-01-ipblock.yaml"
serviceCIDR: "10.96.232.0/24"
podCIDR: "192.168.0.0/16"
vCenter:
networkName: "vc01-net-1"
loadBalancer:
vips:
controlPlaneVIP: "172.16.20.59"
addonsVIP: "172.16.20.60"
kind: "MetalLB"
antiAffinityGroups:
enabled: true
componentAccessServiceAccountKeyPath: "sa-key.json"
gkeConnect:
projectID: "my-project-123"
registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
projectID: "my-project-123"
clusterLocation: "us-central1"
enableVPC: false
serviceAccountKeyPath: "log-mon-sa-2203040617.json"
disableVsphereResourceMetrics: false
clusterBackup:
datastore: "vc-01-datastore-bu"
autoRepair:
enabled: true
osImageType: "ubuntu_containerd"
構成ファイルを検証する
管理クラスタの構成ファイルに入力したら、gkectl check-config を実行してファイルが有効であることを検証します。
gkectl check-config --config ADMIN_CLUSTER_CONFIG
ADMIN_CLUSTER_CONFIG は、管理クラスタ構成ファイルのパスで置き換えます。
コマンドがエラー メッセージを返した場合は、問題を修正してファイルを再度検証します。
時間のかかる検証をスキップする場合は、--fast フラグを渡します。個別の検証をスキップするには、--skip-validation-xxx フラグを使用します。check-config コマンドについて詳しくは、プリフライト チェックの実行をご覧ください。
3. OS イメージを取得する
gkectl prepare を実行して、vSphere 環境を初期化します。
gkectl prepare --config ADMIN_CLUSTER_CONFIG
gkectl prepare コマンドによって、以下の準備タスクが実行されます。
OS イメージを vSphere にインポートして、VM テンプレートとしてマークします。
非公開 Docker レジストリを使用している場合は、コンテナ イメージをレジストリに push します。
必要に応じて、コンテナ イメージのビルド証明書を検証します。これにより、イメージが Google によって作成、署名されていることと、デプロイの準備ができていることを確認します。
4. （省略可）Seesaw ロードバランサを作成する
管理クラスタには、MetaLB、Seesaw、F5 BIG-IP、手動といった複数の負荷分散オプションがあります。
Seesaw ロードバランサを使用する場合は、このセクションの手順を行います。それ以外の場合は、このセクションをスキップできます。
Seesaw ロードバランサの VM を作成して構成します。
gkectl create loadbalancer --config ADMIN_CLUSTER_CONFIG
5. 管理クラスタを作成する
管理クラスタを作成します。
gkectl create admin --config ADMIN_CLUSTER_CONFIG
障害発生後に管理クラスタの作成を再開する
管理クラスタの作成が失敗またはキャンセルされた場合は、create コマンドを再度実行してください。
gkectl create admin --config ADMIN_CLUSTER_CONFIG
管理クラスタの kubeconfig ファイルを見つける
gkectl create admin コマンドで、現在のディレクトリに kubeconfig という名前の kubeconfig ファイルが作成されます。この kubeconfig ファイルは後で管理クラスタとやり取りする際に必要になります。
kubeconfig ファイルには、管理クラスタの名前が含まれています。クラスタ名を表示するには、次のコマンドを実行します。
kubectl config get-clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
出力に、クラスタの名前が表示されます。次に例を示します。
NAME gke-admin-tqk8x
kubeconfig ファイルの名前と場所は、必要に応じて変更できます。
checkpoint.yaml ファイルを管理する
gkectl create admin コマンドを実行して管理クラスタを作成した場合、管理クラスタのデータディスクと同じデータストア フォルダにチェックポイント ファイルが作成されています。デフォルトでは、このファイルの名前は DATA_DISK_NAME‑checkpoint.yaml です。DATA_DISK_NAME の長さが 245 文字以上の場合、ファイル名の長さに対する vSphere の上限により、名前は DATA_DISK_NAME.yaml になります。
このファイルには管理クラスタの状態と認証情報が含まれ、今後のアップグレードに使用されます。管理クラスタの削除プロセスを行っている場合以外は、このファイルを削除しないでください。
vCenter Server のインスタンスで VM の暗号化が有効になっている場合は、管理クラスタを作成またはアップグレードする前に、暗号オペレーション ダイレクト アクセスの権限が付与される必要があります。権限がない場合は、チェックポイントはアップロードされません。この権限を取得できない場合は、関連するコマンドを実行するときに、隠しフラグ --disable-checkpoint を使用してチェックポイント ファイルのアップロードを無効にできます。
checkpoint.yaml ファイルは、gkectl upgrade admin コマンドを実行するか、管理クラスタに影響を与える gkectl update コマンドを実行すると、自動的に更新されます。
6. 管理クラスタが実行されていることを確認する
管理クラスタが実行されていることを確認します。
kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。
出力には、管理クラスタノードが表示されます。次に例を示します。
gke-admin-master-hdn4z Ready control-plane,master ... gke-admin-node-7f46cc8c47-g7w2c Ready ... gke-admin-node-7f46cc8c47-kwlrs Ready ...
7. ファイルをバックアップする
管理クラスタの kubeconfig ファイルをバックアップすることをおすすめします。つまり、管理ワークステーションから別の場所に kubeconfig ファイルをコピーします。その後、管理ワークステーションにアクセスできなくなった場合、または管理ワークステーションの kubeconfig ファイルが誤って削除された場合でも、管理クラスタにアクセスできます。
また、管理クラスタの秘密 SSH 認証鍵をバックアップすることをおすすめします。その後、管理クラスタにアクセスできなくなった場合でも、SSH を使用して管理クラスタノードに接続できます。これにより、管理クラスタへの接続に関する問題のトラブルシューティングと調査を行うことができます。
管理クラスタから admin-cluster-ssh-key という名前のファイルに SSH 認証鍵を抽出します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n kube-system sshkeys \
-o jsonpath='{.data.vsphere_tmp}' | base64 -d > admin-cluster-ssh-key
これで、選択した別の場所に admin-cluster-ssh-key をバックアップできるようになりました。
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。