このページは Cloud Translation API によって翻訳されました。

管理クラスタを作成する

このページでは、Google Distributed Cloud の管理クラスタを作成する方法について説明します。管理クラスタは、ワークロードを実行するユーザークラスタを管理します。トポロジドメインを使用する場合は、トポロジドメインで使用する管理クラスタを作成するをご覧ください。

このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーロールとタスクをご覧ください。

管理クラスタの詳細については、インストールの概要をご覧ください。

バージョン 1.33 以降では、新しいクラスタはすべて高度なクラスタとして作成されます。高度なクラスタを実行する場合の違いを確認してください。

始める前に

管理ワークステーションを作成するの説明に従って、管理ワークステーションを設定してログインできることを確認します。
サービスアカウントの JSON 鍵ファイルが管理ワークステーションにあることを確認します。
IP アドレス計画のドキュメントを確認します。3 つのコントロールプレーンノードとコントロールプレーンの VIP に十分な IP アドレスが利用できることを確認します。kubeception ユーザークラスタを作成する場合は、それらのユーザークラスタのコントロールプレーンノードに十分な数の IP アドレスが利用できる必要があります。
ロードバランシングの概要を参照して、使用するロードバランサの種類を再度確認します。手動のロードバランサについては、管理クラスタを作成する前にロードバランサを設定する必要があります。
gkectl を使用して管理クラスタを作成する場合は、Google Distributed Cloud コンポーネントに公開レジストリと非公開レジストリのどちらを使用するかを決定します。非公開 Docker レジストリの使用については、privateRegistry をご覧ください。Terraform と Google Cloud コンソールのどちらでも、システムコンポーネントに非公開 Docker レジストリを使用することはできません。
管理クラスタノードで実行するオペレーティングシステムのタイプを決定します。
組織でアウトバウンドトラフィックがプロキシサーバーを通過する必要がある場合は、必要な API と Artifact Registry のアドレスを許可リストに登録してください。
バージョン 1.29 以降では、サーバーサイドのプリフライトチェックはデフォルトで有効になっています。サーバーサイドのプリフライトチェックには、追加のファイアウォールルールが必要です。管理クラスタのファイアウォールルールで、[プリフライトチェック] を検索し、必要なファイアウォールルールがすべて構成されていることを確認します。サーバーサイドのプリフライトチェックは、管理ワークステーションでローカルではなく、ブートストラップクラスタで実行されます。

管理クラスタを任意のツールで作成する

このセクションでは、gkectl、Terraform、 Google Cloud コンソールを使用して管理クラスタを作成する手順について説明します。ツールの選択に役立つ情報と、一部のツールの制限事項については、クラスタのライフサイクルを管理するツールを選択するをご覧ください。

gkectl

手順の概要

管理クラスタの作成に関わる主な手順は次のとおりです。

構成ファイルに入力する

管理クラスタの構成ファイル、認証情報構成ファイル、（状況により）IP ブロックファイルを完成させて検証し、新しい管理クラスタの詳細を指定します。
OS イメージを vSphere にインポートし、該当する場合はコンテナイメージをプライベートレジストリに push します。

gkectl prepare を実行します。
管理クラスタを作成する。

gkectl を使用して、完成した構成ファイルで指定した新しい管理クラスタを作成します。Google Distributed Cloud で、管理クラスタを作成する際には、Docker の Kubernetes（kind）クラスタをデプロイして、管理クラスタの作成に必要な Kubernetes コントローラを一時的にホストします。この一時的なクラスタは、ブートストラップクラスタと呼ばれます。ユーザークラスタは、ブートストラップクラスタを使用せずに管理クラスタを管理することによって作成およびアップグレードされます。
管理クラスタが実行されていることを確認します。

kubectl を使用してクラスタノードを表示します。

この手順を完了すると、実行中の管理クラスタでユーザークラスタの作成と管理が可能になります。

VPC Service Controls を使用している場合、"Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services" などの一部の gkectl コマンドを実行するとエラーが表示される場合があります。これらのエラーを回避するには、コマンドに --skip-validation-gcp パラメータを追加します。

構成ファイルに入力する

管理ワークステーションに必要なバージョンの gkectl があることを確認します。通常、クラスタの作成時に使用されるバージョンと同じバージョンの gkectl を使用します。クラスタバージョンは、クラスタ構成ファイルの gkeOnPremVersion フィールドで指定します。クラスタの作成時に、次のバージョンルールが適用されます。
- gkectl マイナーバージョンは、クラスタのマイナーバージョンより低くすることはできません。たとえば、gkectl バージョン 1.29 を使用して 1.30 クラスタを作成することはできません。パッチバージョンは関係ありません。たとえば、gkectl バージョン 1.29.0-gke.1456 を使用している場合、パッチバージョンが 1.29.1000-gke.94 などのクラスタを作成できます。
- gkectl マイナーバージョンは、クラスタバージョンより 2 つ前のマイナーバージョンにすることはできません。たとえば、1.28 クラスタを作成する場合、gkectl のバージョンは 1.29 または 1.30 にできます。ただし、gkectl バージョン 1.31 はクラスタバージョンより 3 つ後のマイナーバージョンであるため、使用できません。
必要に応じて、gkectl をダウンロードするを参照して、サポートされているバージョンの gkectl を入手してください。

gkeadm を使用して管理ワークステーションを作成した場合、admin-cluster.yaml という名前の構成ファイルが生成されます。

管理ワークステーションの作成に gkeadm を使用しなかった場合は、管理ワークステーションで次のコマンドを実行して admin-cluster.yaml を生成します。

gkectl create-config admin

この構成ファイルは、管理クラスタの作成用です。

管理クラスタの構成ファイルのドキュメントを詳しく調べて、構成ファイルをよく理解します。このドキュメントは別のタブまたはウィンドウで開いたままにしておくことをおすすめします。次の手順を実行する際にこれを参照するためです。

`name`

管理クラスタの名前を指定する場合は、name フィールドに入力します。

`bundlePath`

バンドルは、クラスタコンポーネントを含む zip ファイルです。管理ワークステーションに含まれています。このフィールドはあらかじめ入力されています。

`vCenter`

このセクションのフィールドには、管理ワークステーションの作成時に指定した値がすでに入力されています。

`enableAdvancedCluster`

バージョン 1.31 で高度なクラスタ機能を有効にする場合は、enableAdvancedCluster を true に設定します。

バージョン間の違いは次のとおりです。

バージョン 1.31 では、高度なクラスタ機能はプレビュー版です。
- 高度なクラスタは、新しい 1.31 クラスタのクラスタ作成時にのみ有効にできます。
- 高度なクラスタを有効にすると、クラスタを 1.32 にアップグレードできなくなります。高度なクラスタはテスト環境でのみ有効にしてください。
バージョン 1.32 では、高度なクラスタ機能が一般提供されています。
- デフォルトでは、管理クラスタは高度なクラスタとして作成されます。高度なクラスタ以外のクラスタを作成する場合は、enableAdvancedCluster を false に明示的に設定する必要があります。
- 高度なクラスタ機能が有効になっているクラスタでは、クラスタのアップグレードがサポートされています。
バージョン 1.33 以降では、すべてのクラスタが高度なクラスタとして作成されます。enableAdvancedCluster を false に設定すると、クラスタの作成は失敗します。

`network`

network.controlPlaneIPBlock セクションと network.hostConfig セクションに入力します。また、adminMaster.replicas を 3 に設定します。

network.podCIDR フィールドと network.serviceCIDR フィールドには、値が事前に設定されています。この値は、ネットワークですでに使用されているアドレスと競合しない限り変更できません。Kubernetes では、これらの範囲を使用してクラスタ内の Pod と Service に IP アドレスを割り当てます。

必要に応じて、構成ファイルのネットワークセクションの残りのフィールドに入力します。

`loadBalancer`

管理クラスタの Kubernetes API サーバー用に VIP を確保します。loadBalancer.vips.controlPlaneVIP の値として VIP を指定します。

詳細については、管理クラスタサブネット内の VIP をご覧ください。

使用する負荷分散の種類を決めます。次のオプションがあります。

MetalLB バンドルの負荷分散。loadBalancer.kind を "MetalLB" に設定します。
手動ロードバランシング。loadBalancer.kind を "ManualLB" に設定し、manualLB セクションを削除します。

ロードバランシングのオプションの詳細については、ロードバランシングの概要をご覧ください。

`antiAffinityGroups`

必要に応じて、antiAffinityGroups.enabled を true または false に設定します。

このフィールドを使用して、Google Distributed Cloud に管理クラスタノード用の VMware Distributed Resource Scheduler（DRS）アンチアフィニティルールを作成するかどうかを指定すると、管理クラスタノードはデータセンター内の少なくとも 3 つの物理ホストに分散されます。

`adminMaster`

管理クラスタのコントロールプレーンノードの CPU とメモリを指定する場合は、adminMaster セクションの cpus と memoryMB フィールドに入力します。

管理クラスタには 3 つのコントロールプレーンノードが必要です。adminMaster セクションの replicas フィールドを 3 に設定します。

`proxy`

管理クラスタノードを持つネットワークがプロキシサーバーの背後にある場合は、proxy セクションに入力します。

`privateRegistry`

Google Distributed Cloud コンポーネントのコンテナイメージを保持する場所を決定します。次のオプションがあります。

Artifact Registry
独自の非公開 Docker レジストリ。

独自の非公開レジストリを使用する場合は、privateRegistry セクションに入力します。

非公開レジストリの使用方法（標準クラスタと高度なクラスタの違いなど）については、非公開コンテナレジストリを構成するをご覧ください。

`componentAccessServiceAccountKeyPath`

Google Distributed Cloud は、コンポーネントアクセスサービスアカウントを使用して、Artifact Registry からクラスタコンポーネントをダウンロードします。このフィールドには、コンポーネントアクセスサービスアカウントの JSON 鍵ファイルのパスが格納されます。

このフィールドはあらかじめ入力されています。

`gkeConnect`

gkeConnect セクションに入力して、 Google Cloud フリートに管理クラスタを登録します。構成ファイルに stackdriver セクションと cloudAuditLogging セクションを含める場合、gkeConnect.projectID の ID は stackdriver.projectID と cloudAuditLogging.projectID で設定した ID と同じである必要があります。プロジェクト ID が同じでない場合、クラスタの作成は失敗します。

1.28 以降では、必要に応じて、gkeConnect.location で Fleet と Connect サービスを実行するリージョンを指定できます。このフィールドを含めない場合、クラスタはこれらのサービスのグローバルインスタンスを使用します。

gkeConnect.location を含める場合、指定するリージョンは、cloudAuditLogging.clusterLocation、stackdriver.clusterLocation、gkeOnPremAPI.location で構成されたリージョンと同じである必要があります。リージョンが同じでない場合、クラスタの作成は失敗します。

`gkeOnPremAPI`

Google Cloud プロジェクトで GKE On-Prem API が有効になっている場合、プロジェクト内のすべてのクラスタが、stackdriver.clusterLocation で構成されたリージョンの GKE On-Prem API に登録（自動的に）されます。gkeOnPremAPI.location リージョンは、cloudAuditLogging.clusterLocation、gkeConnect.location、stackdriver.clusterLocation で指定されたリージョンと同じリージョンにする必要があります。リージョンが同じでない場合、クラスタの作成は失敗します。

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 フラグを含める必要があります。

次の要件に注意してください。

高度なクラスタを有効にする場合は、cloudAuditLogging.serviceAccountKeyPath と stackdriver.serviceAccountKeyPath に同じパスを指定する必要があります。
stackdriver.projectID の ID は、gkeConnect.projectID と cloudAuditLogging.projectID の ID と同じでなければなりません。
stackdriver.clusterLocation で設定された Google Cloud リージョンは、cloudAuditLogging.clusterLocation と gkeConnect.location で設定されたリージョンと同じである必要があります。さらに、gkeOnPremAPI.enabled が true の場合、gkeOnPremAPI.location に同じリージョンを設定する必要があります。

プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。

`cloudAuditLogging`

クラスタの Kubernetes API サーバーの監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging セクションに値を入力します。

次の要件に注意してください。

高度なクラスタを有効にする場合は、cloudAuditLogging.serviceAccountKeyPath と stackdriver.serviceAccountKeyPath に同じパスを指定する必要があります。
cloudAuditLogging.projectID の ID は、gkeConnect.projectID と stackdriver.projectID の ID と同じでなければなりません。
cloudAuditLogging.clusterLocation で設定された Google Cloud リージョンは、stackdriver.clusterLocation と gkeConnect.location で設定されたリージョンと同じである必要があります（フィールドが構成ファイルに含まれている場合）。さらに、gkeOnPremAPI.enabled が true の場合、gkeOnPremAPI.location に同じリージョンを設定する必要があります。

プロジェクト ID とリージョンが同じでない場合、クラスタの作成は失敗します。

`clusterBackup`

管理クラスタのバックアップを有効にする場合は、clusterBackup.datastore をクラスタのバックアップを保存する vSphere データストアに設定します。

高度なクラスタを有効にする場合は、このセクションを削除します。管理クラスタを vSphere データストアにバックアップすることはできません。

`autoRepair`

管理クラスタのノードの自動修復を有効にする場合は、autoRepair.enabled を true に設定します。

`secretsEncryption`

Secret の常時暗号化を有効にする場合は、secretsEncryption セクションに入力します。

高度なクラスタを有効にする場合は、secretsEncryption.enabled を false に設定します。常時オンの Secret 暗号化はサポートされていません。

`osImageType`

管理クラスタノードに使用する OS イメージのタイプを決定し、それに応じて osImageType セクションに入力します。

高度なクラスタを有効にする場合は、osImageType を ubuntu_cgroupv2 または ubuntu_containerd に設定します。

入力済みの構成ファイルの例

入力済みの管理クラスタ構成ファイルの例を以下に示します。この構成により、利用可能な機能のすべてではなく、一部が有効になります。

vc-01-admin-cluster.yaml

apiVersion: v1
kind: AdminCluster
name: "gke-admin-01"
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.28.0-gke.1-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"
network:
  hostConfig:
    dnsServers:
    - "203.0.113.1"
    - "198.51.100.1"
    ntpServers:
    - "216.239.35.4"
  serviceCIDR: "10.96.232.0/24"
  podCIDR: "192.168.0.0/16"
  vCenter:
    networkName: "vc01-net-1"
  controlPlaneIPBlock:
    netmask: "255.255.248.0"
    gateway: "21.0.143.254"
    ips:
    - ip: "21.0.140.226"
      hostname: "admin-cp-vm-1"
    - ip: "21.0.141.48"
      hostname: "admin-cp-vm-2"
    - ip: "21.0.141.65"
      hostname: "admin-cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.59"
  kind: "MetalLB"
antiAffinityGroups:
  enabled: true
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3
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 コマンドについて詳しくは、プリフライトチェックの実行をご覧ください。

OS イメージを取得する

gkectl prepare を実行して、vSphere 環境を初期化します。

gkectl prepare --config ADMIN_CLUSTER_CONFIG

gkectl prepare コマンドによって、以下の準備タスクが実行されます。

OS イメージを vSphere にインポートして、VM テンプレートとしてマークします。
非公開 Docker レジストリを使用している場合は、コンテナイメージをレジストリに push します。
必要に応じて、コンテナイメージのビルド証明書を検証します。これにより、イメージが Google によって作成、署名されていることと、デプロイの準備ができていることを確認します。

管理クラスタを作成する

管理クラスタを作成します。

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` ファイルを管理する

このセクションは、非 HA 管理クラスタにのみ適用されます。checkpoint.yaml ファイルは HA 管理クラスタの作成には使用されません。

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 コマンドを実行すると、自動的に更新されます。

管理クラスタが実行されていることを確認する

管理クラスタが実行されていることを確認します。

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。

出力には、管理クラスタノードが表示されます。例:

admin-cp-vm-1   Ready    control-plane,master   ...
admin-cp-vm-2   Ready    control-plane,master   ...
admin-cp-vm-3   Ready    control-plane,master   ...

ファイルをバックアップする

管理クラスタの kubeconfig ファイルをバックアップすることをおすすめします。つまり、管理ワークステーションから別の場所に kubeconfig ファイルをコピーします。その後、管理ワークステーションにアクセスできなくなった場合、または管理ワークステーションの kubeconfig ファイルが誤って削除された場合でも、管理クラスタにアクセスできます。

管理クラスタの秘密 SSH 鍵のバックアップも作成することをおすすめします。その後、管理クラスタにアクセスできなくなった場合でも、SSH を使用して管理クラスタノードに接続できます。これにより、管理クラスタへの接続に関する問題のトラブルシューティングと調査が可能になります。

管理クラスタから SSH 鍵を抽出して admin-cluster-ssh-key という名前のファイルに保存します。

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 をバックアップできるようになりました。

RBAC ポリシー

管理クラスタ構成ファイルの gkeConnect セクションに入力すると、クラスタの作成時または更新時にフリートに登録されます。フリート機能を有効にするため、 Google Cloud は Connect エージェントをデプロイし、クラスタが登録されているプロジェクトを表す Google サービスアカウントを作成します。Connect エージェントは、クラスタの Kubernetes API サーバーへのリクエストを処理するためにサービスアカウントとの接続を確立します。これにより、 Google Cloudのクラスタとワークロード管理機能にアクセスできるようになります。これには、クラスタを操作できる Google Cloud コンソールへのアクセスも含まれます。

管理クラスタの Kubernetes API サーバーは、Connect エージェントからのリクエストを承認できる必要があります。このため、サービスアカウントには、次のロールベースアクセス制御（RBAC）ポリシーが構成されています。

権限借用ポリシー: Connect エージェントがサービスアカウントに代わって Kubernetes API サーバーにリクエストを送信することを承認します。
権限ポリシー: 他の Kubernetes リソースに対して許可されているオペレーションを指定します。

Google Cloud コンソールでユーザークラスタのライフサイクルを管理できるようにするために、サービスアカウントと RBAC ポリシーが必要です。

Terraform

手順の概要

管理クラスタを作成する前に、管理ワークステーションで gkectl register bootstrap コマンドを実行する必要があります。このコマンドにより、管理ワークステーションに Kubernetes in Docker（kind）クラスタがデプロイされます。このブートストラップクラスタは、管理クラスタの作成に必要な Kubernetes コントローラをホストします。管理クラスタを作成すると、ブートストラップクラスタのコントローラによりノードがプロビジョニングされ、プリフライトチェックが実行されて、管理クラスタがフリートに登録されます。管理クラスタが正常に作成されると、ブートストラップクラスタは自動的に削除されます。

Terraform を使用して管理クラスタを作成する大まかな手順は次のとおりです。

構成ファイルに入力します。

google_gkeonprem_vmware_admin_cluster リソースと次の例を使用して、main.tf 構成ファイルを作成します。
bootstrap クラスタを作成します。

gkectl register bootstrap を実行してブートストラップクラスタを作成します。コマンドでブートストラップクラスタの作成が完了すると、管理クラスタの構成を完了するよう求めるメッセージが出力に表示されます。このプロセスは、管理クラスタが作成されるまで継続します。
管理クラスタを作成します。

別のターミナルウィンドウまたは GKE On-Prem API にアクセスできる別のコンピュータで、terraform コマンドを実行して、完成した main.tf 構成ファイルで指定されているように新しい管理クラスタを作成します。

構成ファイルに入力する

次の例は、MetalLB を使用して 3 つのコントロールプレーンノードを持つ高可用性（HA）管理クラスタを作成する方法を示しています。1.28 以降では、新しい管理クラスタは高可用性である必要があります。この要件のため、control_plane_node.replicas を 3 に設定する必要があります。

詳細とその他の例については、google_gkeonprem_vmware_admin_cluster リファレンスドキュメントをご覧ください。システムイメージに非公開レジストリを使用する方法については、非公開コンテナレジストリを構成するをご覧ください。

次の例のプレースホルダ変数に値を入力し、main.tf にコピーして貼り付けます。gkeadm を使用して管理ワークステーションを作成した場合は、管理ワークステーションの構成ファイルを開き、vCenter セクションの値を対応するプレースホルダ変数にコピーします。

resource "google_gkeonprem_vmware_admin_cluster" "admin-cluster-metallb" {
  provider = google-beta
  name = "ADMIN_CLUSTER_NAME"
  project = "PROJECT_ID"
  location = "REGION"
  description = "DESCRIPTION"
  bootstrap_cluster_membership = "projects/PROJECT_ID/locations/REGION/memberships/bootstrap-ADMIN_CLUSTER_NAME"
  on_prem_version = "VERSION"
  image_type = "IMAGE_TYPE"
  vcenter {
    address = "VCENTER_ADDRESS"
    datacenter = "DATA_CENTER"
    cluster = "VCENTER_CLUSTER"
    resource_pool = "RESOURCE_POOL"
    datastore = "DATASTORE"
    ca_cert_data = "CA_CERT_DATA"
  }
  network_config {
    service_address_cidr_blocks = ["10.96.232.0/24"]
    pod_address_cidr_blocks = ["192.168.0.0/16"]
    vcenter_network = "NETWORK"
    dhcp_ip_config {
      enabled = true
    }
    host_config {
      dns_servers = ["DNS_SERVERS"]
      ntp_servers = ["NTP_SERVERS"]
    }
    ha_control_plane_config {
      control_plane_ip_block {
        gateway = "GATEWAY"
        netmask = "NETMASK"
        ips {
          hostname = "CONTROL_PLANE_HOST_1"
          ip       = "CONTROL_PLANE_NODE_IP_1"
        }
        ips {
          hostname = "CONTROL_PLANE_HOST_2"
          ip       = "CONTROL_PLANE_NODE_IP_2"
        }
        ips {
          hostname = "CONTROL_PLANE_HOST_3"
          ip       = "CONTROL_PLANE_NODE_IP_3"
        }
      }
    }
  }
  control_plane_node {
     cpus = NUM_CPUS
     memory = MEMORY
     replicas = 3
  }
  load_balancer {
    vip_config {
      control_plane_vip = "CONTROL_PLANE_VIP"
    }
    metal_lb_config {
      enabled = true
    }
  }
}

次のように置き換えます。

ADMIN_CLUSTER_NAME: 管理クラスタの名前。名前の最大文字数は 20 文字です。
PROJECT_ID: Google Cloud プロジェクト ID。
REGION: GKE On-Prem API（gkeonprem.googleapis.com）、フリートサービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。

location フィールドは、gkectl register bootstrap コマンドの --location フラグに対応します。
DESCRIPTION: 管理クラスタの説明。
VERSION: クラスタの Google Distributed Cloud のバージョン。Terraform を使用したクラスタの作成は、バージョン 1.28 以降でのみサポートされています。ここで指定するバージョンは、gkectl register bootstrap コマンドの --bundle-path フラグで指定するバンドルのバージョンと一致する必要があります。バージョンのリストについては、Google Distributed Cloud のバージョンをご覧ください。
IMAGE_TYPE: 管理クラスタノードで実行する OS イメージのタイプ。ubuntu_containerd、cos、ubuntu_cgv2、cos_cgv2 のいずれかを指定します。
VCENTER_ADDRESS: vCenter Server のアドレス。
- 管理ワークステーションの構成ファイル: vCenter.credentials.address フィールドの値を使用します。
- vcenter.address フィールドは、gkectl register bootstrap コマンドの --vcenter-address フラグに対応します。
DATA_CENTER: vCenter データセンターの名前。
- 管理ワークステーションの構成ファイル: vCenter.datacenter フィールドの値を使用します。
- vcenter.datacenter フィールドは、gkectl register bootstrap コマンドの --vcenter-datacenter フラグに対応します。
VCENTER_CLUSTER: vCenter クラスタの名前。
- 管理ワークステーションの構成ファイル: vCenter.cluster フィールドの値を使用します。
- vcenter.cluster フィールドは、gkectl register bootstrap コマンドの --vcenter-cluster フラグに対応します。
RESOURCE_POOL: vCenter リソースプールの名前またはパス。
- 管理ワークステーションの構成ファイル: vCenter.resourcePool フィールドの値を使用します。
- vcenter.resource_pool フィールドは、gkectl register bootstrap コマンドの --vcenter-resource-pool フラグに対応します。
DATASTORE: vCenter データストアの名前。指定する値は、パスではなく、名前にする必要があります。パスを入力する必要がある場合は、次のフィールドを追加します。folder = "FOLDER"
- 管理ワークステーションの構成ファイル: vCenter.datastore フィールドの値を使用します。
- vcenter.datastore フィールドは、gkectl register bootstrap コマンドの --vcenter-datastore フラグに対応します。
クラスタノードに VM ストレージポリシーを使用する場合は、vcenter.datastore フィールドを削除し、代わりに vcenter.storage_policy_name を追加します。さらに、gkectl register bootstrap コマンドに --vcenter-storage-policy フラグを追加します。vcenter.datastore または vcenter.storage_policy_name のいずれかの値を指定する必要があります。両方を指定することはできません。
FOLDER: クラスタ VM が配置される vCenter フォルダの名前。フォルダを使用していない場合は、このフィールドを削除します。
- 管理ワークステーションの構成ファイル: vCenter.folder フィールドの値を使用します。
- vcenter.folder フィールドは、gkectl register bootstrap コマンドの --vcenter-folder フラグに対応します。
CA_CERT_DATA: vCenter CA 証明書を PEM 形式で入力します。CA 証明書データを取得するには:
1. 次のコマンドを実行します。
```
cat CA_CERT_PATH_LOCAL |  tr '\n' '\\n'
```
  CA_CERT_PATH_LOCAL は、vCenter Server のルート CA 証明書のパスに置き換えます。gkeadm を使用して管理ワークステーションを作成した場合は、管理ワークステーション構成ファイルの caCertPath フィールドの値（ローカルコンピュータ上のパス）を使用できます。gkeadm が、CA 証明書ファイルを管理ワークステーションにコピーします。管理ワークステーションのパスは、gkectl register bootstrap コマンドの --vcenter-ca-cert-path フラグで指定する必要があります。
2. 前のコマンドから出力された証明書をコピーし、テキストエディタに貼り付けます。バックスラッシュ文字（\）をすべて改行文字（\n）に置き換えます。
3. 変更した証明書をコピーし、CA_CERT_DATA プレースホルダ変数に貼り付けます。
NETWORK: vCenter ネットワークの名前を入力します。
- 管理ワークステーションの構成ファイル: vCenter.network フィールドの値を使用します。
- network_config.vcenter_network フィールドは、gkectl register bootstrap コマンドの --vcenter-network フラグに対応します。
GATEWAY: コントロールプレーンクラスタノードがあるサブネットのデフォルトゲートウェイの IP アドレス。
NETMASK: コントロールプレーンクラスタノードがあるサブネットのネットマスク。
DNS_SERVERS: DNS サーバーの IP アドレス。
NTP_SERVERS: 時刻（NTP）サーバーの IP アドレス。
control_plane_ip_block.ips セクションに、3 つのコントロールプレーンノードの IP アドレスと、必要に応じてホスト名を入力します。ホスト名を入力しない場合は、構成から hostname フィールドを削除します。
NUM_CPUS: 管理クラスタの各コントロールプレーンノードの vCPU 数。4 以上の値にする必要があります。
MEMORY: 管理クラスタの各コントロールプレーンノードのメモリ容量（MiB）。8,192 以上にする必要があります。推奨値は 16,384 です。
CONTROL_PLANE_VIP: 管理クラスタの Kubernetes API サーバー用にロードバランサで構成するために選択した IP アドレス。

省略可: 限定公開レジストリを構成する

デフォルトでは、クラスタの作成またはアップグレード時に、Google Distributed Cloud はコンポーネントアクセスサービスアカウントを使用して gcr.io/gke-on-prem-release からシステムイメージを pull します。必要に応じて、独自の Container Registry サーバーを指定し、システムイメージが非公開レジストリサーバーから pull されるようにすることもできます。

限定公開レジストリを構成する手順は次のとおりです。

管理クラスタの構成ファイルに以下を追加します。
```
private_registry_config {
  address = "ADDRESS"
  ca_cert = "CA_CERT"
}
```
次のように置き換えます。
- ADDRESS: 非公開レジストリを実行するマシンの IP アドレスまたは FQDN（完全修飾ドメイン名）。
- CA_CERT: PEM 形式の非公開レジストリの公開鍵の CA 証明書データ。必要な形式で CA 証明書を取得する手順は次のとおりです。
1. 次のコマンドを実行します。
```
cat PUBLIC_KEY_PATH |  tr '\n' '\\n'
```
  PUBLIC_KEY_PATH は、公開鍵のパスに置き換えます。
2. 前のコマンドから出力された証明書をコピーし、テキストエディタに貼り付けます。バックスラッシュ文字（\）をすべて改行文字（\n）に置き換えます。
3. 変更した証明書をコピーし、CA_CERT プレースホルダ変数に貼り付けます。
ネットワークがプロキシサーバー経由である場合は、次を追加します。
```
proxy {
  url: "PROXY_SERVER_ADDRESS"
  no_proxy: "BYPASS_LIST"
}
```
次のように置き換えます。
- PROXY_SERVER_ADDRESS: プロキシサーバーの HTTP アドレス。スキームのデフォルトポートと同じ場合でも、ポート番号を含めます。
- BYPASS_LIST: プロキシサーバーを経由しない IP アドレス、IP アドレス範囲、ホスト名、ドメイン名のカンマ区切りのリスト。
例:
```
url: "http://my-proxy.example.local:80"
no_proxy: "192.0.2.0/24,my-host.example.local,198.51.100.0"
```
Google Distributed Cloud がこれらのアドレス、ホスト、ドメインのいずれかにリクエストを送信する場合、そのリクエストはプロキシサーバーをバイパスして宛先に直接送信されます。

非公開レジストリの使用方法（標準クラスタと高度なクラスタの違いなど）については、非公開コンテナレジストリを構成するをご覧ください。

構成ファイルとプランを確認する

main.tf が配置されているディレクトリで、次のコマンドを実行します。

Terraform を初期化します。
```
terraform init
```
Terraform によって、 Google Cloud プロバイダなどの必要なライブラリがインストールされます。必要に応じて maint.tf のエラーを修正します。
Terraform プランを作成します。
```
terraform plan -out tfplan
```
構成を確認し、必要に応じて変更を加えます。

プランを適用する前に、次のセクションで説明するように、まずブートストラップクラスタを作成する必要があります。

ブートストラップクラスタを作成する

gkectl register bootstrap コマンドを実行すると、vCenter アカウントのユーザー名とパスワードの入力を求めるメッセージが表示されます。使用可能な認証情報があることを確認します。gkeadm を使用して管理ワークステーションを作成した場合、ユーザー名とパスワードは credential.yaml ファイルにあります。

SSH を使用して管理ワークステーションにログインします。
Google Cloud CLI に対して認証を行います。
```
gcloud auth login
```
次のコマンドを実行して、ブートストラップクラスタを作成します。フラグの値の多くは、main.tf フィールドと同じです。ただし、このコマンドは追加の値を取ります。この値は、指定されたプレースホルダ変数で指定する必要があります。
```
gkectl register bootstrap \
    --target-cluster-name=ADMIN_CLUSTER_NAME \
    --project-id=PROJECT_ID \
    --location=REGION \
    --vcenter-address=VCENTER_ADDRESS \
    --vcenter-datacenter=DATA_CENTER \
    --vcenter-cluster=VCENTER_CLUSTER \
    --vcenter-resource-pool=RESOURCE_POOL \
    --vcenter-datastore=DATASTORE \
    --vcenter-network=NETWORK \
    --vcenter-ca-cert-path=CA_CERT_PATH \
    --bundle-path=BUNDLE_PATH \
    --component-access-service-account-key-path=COMPONENT_ACCESS_SA_PATH \
    --register-service-account-key-path=CONNECT_REGISTER_SA_PATH \
    --stackdriver-service-account-key-path=LOG_MON_SA_PATH \
    --cloud-audit-logging-service-account-key-path=CLOUD_AUDIT_SA_PATH
```
次のパスを管理ワークステーションのパスに置き換えます。
- CA_CERT_PATH: vCenter Server のルート CA 証明書のパス。
- BUNDLE_PATH: バンドルファイルのパス。gkeadm を使用して管理ワークステーションを作成した場合、バンドルファイルは /var/lib/gke/bundles/ にあります。ファイル名は Google Distributed Cloud のバージョンによって異なります（例: gke-onprem-vsphere-1.31.0-gke.889-full.tgz）。
- COMPONENT_ACCESS_SA_PATH: コンポーネントアクセスサービスアカウントの鍵ファイルのパス。
- CONNECT_REGISTER_SA_PATH: connect-register サービスアカウントの鍵ファイルのパス。
- LOG_MON_SA_PATH: ロギングモニタリングサービスアカウントの鍵ファイルのパス。
- CLOUD_AUDIT_SA_PATH: 監査ロギングサービスアカウントのパス。監査ロギングサービスアカウントを作成していない場合は、logging-monitoring サービスアカウントの鍵ファイルのパスを指定します。
必要に応じて、次のフラグに合わせてコマンドを変更します。
- main.tf でフォルダを指定した場合は、--vcenter-folder=FOLDER フラグを追加します。
- main.tf で VM ストレージポリシーを指定した場合は、--vcenter-datastore を削除し、--vcenter-storage-policy-name=STORAGE_POLICY_NAME フラグを追加します。
- 管理ワークステーションがプロキシサーバーの背後にあるネットワーク上にある場合は、次のフラグを追加します。
  - --proxy-url=PROXY_URL
  - --no-proxy=NO_PROXY
  次のように置き換えます。
  - PROXY_URL: プロキシサーバーの URL。
  - NO_PROXY: プロキシ処理から除外するドメインと IP アドレスの値をカンマ区切りで指定します。
フラグを追加する場合は、コマンドライン継続文字のバックスラッシュ文字（\）を追加してください。
プロンプトが表示されたら、vCenter のユーザー名を入力します（またはコピーして貼り付けます）。ユーザー名は画面にエコーバックされません。
プロンプトが表示されたら、vCenter パスワードを入力します（またはコピーして貼り付けます）。パスワードは画面にエコーバックされません。

このコマンドは、多数の検証を実行します。gkectl がブートストラップクラスタの作成に成功すると、次のような出力が表示されます（読みやすさのために短くしています）。

Running workstation validations
- Validation Category: Workstation
    - [SUCCESS] Workstation OS
    - [SUCCESS] Workstation Hardware
    - [SUCCESS] Workstation Package
    - [SUCCESS] Workstation NTP
    - [SUCCESS] Workstation Docker
...
All validation results were SUCCESS.
Unpacking GKE on-prem bundle: /var/lib/gke/bundles/gke-onprem-vsphere-1.31.0-gke.889-full.tgz
...
Successfully created and registered the bootstrap cluster
...
Waiting for preflight checks to run or OnPremAdminCluster to be applied...... -

このプロセスは、管理クラスタが作成されるまで継続します。

管理クラスタが作成される前に gkectl register bootstrap コマンドを終了すると、管理クラスタの作成が失敗します。その場合、次のコマンドを使用してブートストラップクラスタを削除する必要があります。

gkectl delete bootstrap \
    --target-cluster-name=ADMIN_CLUSTER_NAME \
    --project-id=PROJECT_ID \
    --location=REGION \
     --register-service-account-key-path=CONNECT_REGISTER_SA_PATH

管理クラスタを作成する

Terraform プランを適用して、管理クラスタを作成します。

terraform apply "tfplan"

クラスタの作成には 15 分以上かかります。クラスタは、 Google Cloud コンソールの [GKE クラスタ] ページで確認できます。

コンソール

手順の概要

コンソールを使用して管理クラスタを作成するための大まかな手順は次のとおりです。

コンソールで、gkectl register bootstrap で要求される情報を入力します。コンソールに、入力した情報を含む gkectl register bootstrap コマンドが表示されます。表示されるコマンドには、コマンドを実行する前に指定する必要があるパスのフラグも含まれます。
管理ワークステーションで、gkectl register bootstrap を実行してブートストラップクラスタを作成します。コマンドでブートストラップクラスタの作成が完了すると、管理クラスタの構成を完了するよう求めるメッセージが出力に表示されます。このプロセスは、管理クラスタが作成されるまで継続します。
コンソールに戻り、クラスタの作成に必要な情報の入力を完了します。クラスタの作成中に、gkectl register bootstrap コマンドは進捗情報を出力し、管理ワークステーションにログを書き込みます。管理クラスタが作成されると、ブートストラップクラスタは自動的に削除されます。

クラスタの構成を開始する

コンソールで、[VMware 上のクラスタの作成] ページに移動します。

[VMware 上のクラスタの作成] に移動
クラスタを作成する Google Cloud プロジェクトを選択します。

次のセクションでブートストラップクラスタを作成すると、選択したプロジェクト ID が gkectl register bootstrap コマンドの --project-id フラグに表示されます。
[管理クラスタを作成する] がオンになっていることを確認します。
[次へ: ブートストラップ環境のインストール] をクリックします。

ブートストラップ環境のインストール

このセクションでは、gkectl register bootstrap コマンドで要求される情報を入力します。UI フィールドに値を入力すると、コンソールは、ページの下部にある [管理ワークステーションからの環境のブートストラップ] セクションに表示される gkectl register bootstrap コマンドの対応するフラグにその値をコピーします。

ブートストラップ環境の基本

管理クラスタの名前を入力します。コンソールでは、このクラスタ名が、ページの下部に表示される gkectl register bootstrap コマンドの --target-cluster-name フラグの値として使用されます。名前の最大文字数は 20 文字です。
[Google Cloud API のロケーション] フィールドで、リストから Google Cloudリージョンを選択します。この設定では、次の API とサービスが実行されるリージョンを指定します。
- GKE On-Prem API（gkeonprem.googleapis.com）
- Fleet サービス（gkehub.googleapis.com）
- Connect サービス（gkeconnect.googleapis.com）
この設定では、以下のものが保存されるリージョンも制御されます。
- GKE On-Prem API がクラスタのライフサイクルを管理するために必要とするクラスタメタデータ
- システムコンポーネントの Cloud Logging データと Cloud Monitoring データ
- Cloud Audit Logs によって作成された管理監査ログ
[Google Cloud API のロケーション] フィールドは、gkectl register bootstrap コマンドの --location フラグに対応します。
[Admin cluster version] フィールドに、クラスタの作成に使用するバージョンを入力します。ここで選択するバージョンは、gkectl register bootstrap コマンドの --bundle-path フラグで指定するバンドルのバージョンと一致する必要があります。

vCenter 構成

gkeadm を使用して管理ワークステーションを作成した場合は、管理ワークステーションの構成ファイルを開き、vCenter セクションの値をコンソールのフィールドにコピーします。生成された管理クラスタ構成ファイルにもこの情報が含まれています。

このセクションのほとんどのフィールドは変更できません。フィールドが変更可能か変更不可かを確認するには、管理クラスタ構成ファイルリファレンスの vCenter セクションをご覧ください。

[アドレス] フィールドに、vCenter Server のアドレスを入力します。
- 管理ワークステーションの構成ファイル: vCenter.credentials.address フィールドの値を使用します。
- [アドレス] フィールドは、gkectl register bootstrap コマンドの --vcenter-address フラグに対応します。
[データセンター] フィールドに、vCenter データセンターの名前を入力します。
- 管理ワークステーションの構成ファイル: vCenter.datacenter フィールドの値を使用します。
- [データセンター] フィールドは、gkectl register bootstrap コマンドの --vcenter-datacenter フラグに対応します。
[クラスタ名] フィールドに、vCenter クラスタの名前を入力します。
- 管理ワークステーションの構成ファイル: vCenter.cluster フィールドの値を使用します。
- [クラスタ名] フィールドは、gkectl register bootstrap コマンドの --vcenter-cluster フラグに対応します。
[リソースプール] フィールドに、vCenter リソースプールの名前またはパスを入力します。
- 管理ワークステーションの構成ファイル: vCenter.resourcePool フィールドの値を使用します。
- [リソースプール] フィールドは、gkectl register bootstrap コマンドの --vcenter-resource-pool フラグに対応します。
次のいずれかを入力して、ストレージオプションを構成します。
- [データストア] フィールド: vCenter データストアの名前を入力します。指定する値は、パスではなく、名前にする必要があります。パスを入力する必要がある場合は、[フォルダ] フィールドに入力します。
  - 管理ワークステーションの構成ファイル: vCenter.datastore フィールドの値を使用します。
  - [Datastore] フィールドは、gkectl register bootstrap コマンドの --vcenter-datastore フラグに対応します。
- [ストレージポリシー名] フィールド: クラスタノードの VM ストレージポリシーの名前を入力します。詳細については、ストレージポリシーを構成するをご覧ください。
  - 管理ワークステーションの構成ファイル: vCenter.storagePolicyName フィールドの値を使用します。
  - [ストレージポリシー名] フィールドは、gkectl register bootstrap コマンドの --vcenter-storage-policy フラグに対応します。
[Datastore] フィールドまたは [ストレージポリシー名] フィールドのいずれかに値を入力する必要があります。両方に値を入力することはできません。
必要に応じて、[フォルダ] フィールドに、クラスタ VM が配置される vCenter フォルダの名前を入力します。
- 管理ワークステーションの構成ファイル: vCenter.folder フィールドの値を使用します。
- [フォルダ] フィールドは、gkectl register bootstrap コマンドの --vcenter-folder フラグに対応します。
[ネットワーク] フィールドに、vCenter ネットワークの名前を入力します。
- 管理ワークステーションの構成ファイル: vCenter.network フィールドの値を使用します。
- [ネットワーク] フィールドは、gkectl register bootstrap コマンドの --vcenter-network フラグに対応します。
[CA 証明書のパス] フィールドに、vCenter Server のルート CA 証明書のパスを入力します。
- gkeadm を使用して管理ワークステーションを作成した場合は、ローカルに保存していた CA 証明書ファイルが gkeadm によって管理ワークステーションにコピーされています。
- [CA 証明書のパス] フィールドは、gkectl register bootstrap コマンドの --vcenter-ca-cert-path に対応します。

CA 証明書の取得

ブートストラップクラスタを作成したら、[クラスタの基本] ページの [CA 証明書データ] フィールドに PEM 形式の vCenter CA 証明書を指定する必要があります。次のコマンドを実行して、証明書を表示します。

cat CA_CERT_PATH

CA_CERT_PATH は、vCenter Server のルート CA 証明書のパスに置き換えます。このコマンドをローカルで実行する場合は、管理ワークステーションの構成ファイルの vCenter.caCertPath のパスを使用します。

証明書全体をテキストエディタにコピーします。こうすることで、ブートストラップクラスタが作成された後、[クラスタの基本] ページの [CA 証明書データ] フィールドに貼り付けられるようになります。

管理ワークステーションからの環境のブートストラップ

[管理ワークステーションからの環境のブートストラップ] セクションまでスクロールして、gkectl register bootstrap コマンドを表示します。

このページを開いたまま、管理ワークステーションに移動してブートストラップクラスタを作成します。
gkectl register bootstrap コマンドをコピーしてテキストエディタに貼り付け、次のフラグの値を指定します。
```
    ./gkectl register bootstrap \
      ...
      --bundle-path=BUNDLE_PATH \
      ...
      --component-access-service-account-key-path=COMPONENT_ACCESS_SA_PATH \
      --register-service-account-key-path=CONNECT_REGISTER_SA_PATH \
      --stackdriver-service-account-key-path=LOG_MON_SA_PATH \
      --cloud-audit-logging-service-account-key-path=CLOUD_AUDIT_SA_PATH
```
次のパスを管理ワークステーションのパスに置き換えます。
- BUNDLE_PATH: バンドルファイルのパス。gkeadm を使用して管理ワークステーションを作成した場合、バンドルファイルは /var/lib/gke/bundles/ にあります。ファイル名は Google Distributed Cloud のバージョンによって異なります（例: gke-onprem-vsphere-1.31.0-gke.889-full.tgz）。
- COMPONENT_ACCESS_SA_PATH: コンポーネントアクセスサービスアカウントの鍵ファイルのパス。
- CONNECT_REGISTER_SA_PATH: connect-register サービスアカウントの鍵ファイルのパス。
- LOG_MON_SA_PATH: ロギングモニタリングサービスアカウントの鍵ファイルのパス。
- CLOUD_AUDIT_SA_PATH: 監査ロギングサービスアカウントのパス。監査ロギングサービスアカウントを作成していない場合は、logging-monitoring サービスアカウントの鍵ファイルのパスを指定します。
また、gkeadm を使用して管理ワークステーションを作成した場合、gkectl は /usr/bin/ ディレクトリにダウンロードされています。この場合、gkectl は現在の作業ディレクトリにないため、コマンドの先頭から ./ を削除します。
SSH を使用して管理ワークステーションに接続します。
コマンドをコピーして、管理者ワークステーションのターミナルウィンドウに貼り付けます。
プロンプトが表示されたら、vCenter のユーザー名を入力します（またはコピーして貼り付けます）。ユーザー名は画面にエコーバックされません。
プロンプトが表示されたら、vCenter パスワードを入力します（またはコピーして貼り付けます）。パスワードは画面にエコーバックされません。

Running workstation validations
- Validation Category: Workstation
    - [SUCCESS] Workstation OS
    - [SUCCESS] Workstation Hardware
    - [SUCCESS] Workstation Package
    - [SUCCESS] Workstation NTP
    - [SUCCESS] Workstation Docker
...
All validation results were SUCCESS.
Unpacking GKE on-prem bundle: /var/lib/gke/bundles/gke-onprem-vsphere-1.31.0-gke.889-full.tgz
...
Successfully created and registered the bootstrap cluster
...
Waiting for preflight checks to run or OnPremAdminCluster to be applied...... -

このプロセスは、管理クラスタが作成されるまで継続します。

管理クラスタが作成される前に gkectl register bootstrap コマンドを終了すると、管理クラスタの作成に失敗します。次のコマンドを使用してブートストラップクラスタを削除する必要があります。

gkectl delete bootstrap \
    --target-cluster-name=ADMIN_CLUSTER_NAME \
    --project-id=PROJECT_ID \
    --location=REGION \
     --register-service-account-key-path=CONNECT_REGISTER_SA_PATH

管理クラスタの構成を完了する

コンソールに戻り、次の手順を実行します。

[ブートストラップ環境のインストール] ページで、[接続を確認] をクリックします。

成功すると、コンソールに [ 接続が確立されました] と表示されます。

続行する前に、ブートストラップクラスタへの接続が確立されている必要があります。接続が確立されていない場合は、gkectl register bootstrap コマンドに指定した引数を確認します。
- --target-cluster-name の値が、ブートストラップ環境の基本セクションに表示されている管理クラスタ名と一致していることを確認します。
- --project-id の値がコンソールで選択したプロジェクトの ID と一致していることを確認します。
ブートストラップクラスタ名、プロジェクト ID、またはその他のフラグ値を変更する必要がある場合は、次の手順を実行します。
1. Ctrl-C キーを押して gkectl register bootstrap を終了します。
2. ブートストラップクラスタを削除します。
```
gkectl delete bootstrap \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=PROJECT_ID \
  --location=REGION \
  --register-service-account-key-path=CONNECT_REGISTER_SA_PATH
```
3. gkectl register bootstrap コマンドを再実行します。
[次へ: クラスタの基本] をクリックして、管理クラスタの構成を開始します。

クラスタの基本

前の CA 証明書の取得セクションで説明したように、[CA 証明書データ] フィールドに、PEM 形式の vCenter CA 証明書全体をコピーして貼り付けます。
[認可] セクションに、読み取り専用の Kubernetes clusterrole/view ロールを付与するユーザーのメールアドレスを入力します。あなたのメールアドレスは自動的に追加されます。適用されるロールベースアクセス制御（RBAC）ポリシーにより、ユーザーは Connect Gateway を介して読み取り専用コマンドを実行できます。
[次へ: コントロールプレーン] をクリックします。

コントロールプレーン

[コントロールプレーン] セクションのデフォルト設定を確認し、必要に応じて変更します。
[コントロールプレーンノードの IP] セクションで、次のフィールドに IP アドレスを入力します。
- ゲートウェイ: クラスタノードがあるサブネットのデフォルトゲートウェイの IP アドレス。
- ネットマスク: クラスタノードがあるサブネットのネットマスク。
- IP アドレス: IP アドレスと、必要に応じて 3 つのコントロールプレーンノードのホスト名を入力します。
[次へ: ネットワーキング] をクリックします。

ネットワーキング

このセクションでは、管理クラスタの作成に必要なネットワーキング情報を指定します。

[Service CIDR と Pod CIDR] セクションで、Kubernetes Service と Pod の IP アドレス範囲のデフォルト値を受け入れるか、別の CIDR アドレス範囲を入力します。
- Service CIDR: 可能な最小範囲は /24、可能な最大範囲は /12 です。
- Pod CIDR: 可能な最小範囲は /18、可能な最大範囲は /8 です。
[ホスト構成] セクションで、クラスタノードである VM が使用する NTP サーバー、DNS サーバー、および必要に応じて DNS 検索ドメインを指定します。クラスタの作成後、これらの値を変更することはできません。
[次へ: ロードバランサ] をクリックします。

ロードバランサ

このセクションでは、使用するロードバランサのタイプを選択します。詳細については、ロードバランシングの概要をご覧ください。

[ロードバランサのタイプ] リストで、ロードバランサを選択します。
- MetalLB にバンドル済み: MetalLB ロードバランサがバンドルされており、手動ロードバランシングよりも必要な構成が少なく済みます。MetalLB コンポーネントはクラスタノード上で実行されるため、ロードバランサ用に個別の VM を作成する必要はありません。
- 手動: クラスタを作成する前に設定したロードバランサであれば、任意のものを使用できます。ロードバランサを手動で設定した場合は、仮想 IP（VIP）、ノードアドレス、nodePort 値の間のマッピングを構成する必要があります。
[コントロールプレーン VIP] フィールドに、Kubernetes API サーバーに送信されるトラフィックに使用する VIP を入力します。
[確認して作成] をクリックします。

コンソールで設定を確認し、データセンターにクラスタを作成するときに、ステータスメッセージが表示されます。

構成に問題がある場合は、エラーメッセージがコンソールに表示されます。このエラーメッセージは、構成の問題を修正してクラスタの作成を再試行できるように十分明確なものでなければなりません。

クラスタ作成プロセスの詳細は、管理ワークステーションに出力されます。プリフライトチェックに合格すると、次のように表示されます。

[2023-03-22 23:12:47+0000] Waiting for cluster kubeconfig to become ready OK
[2023-03-22 23:15:47+0000] Writing kubeconfig file
[2023-03-22 23:15:47+0000] kubeconfig of cluster being created is present at gkectl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig
[2023-03-22 23:15:47+0000] Please restrict access to this file as it contains authentication credentials of your cluster.
[2023-03-22 23:15:47+0000] Waiting for cluster to become ready OK
[2023-03-22 23:20:17+0000] Please run
[2023-03-22 23:20:17+0000] kubectl --kubeconfig gkectl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig get nodes
[2023-03-22 23:20:17+0000] to get cluster nodes status.
[2023-03-22 23:20:17+0000] Waiting for node pools to become ready OK
[2023-03-22 23:20:37+0000] Waiting for metrics to become ready in GCP OK
[2023-03-22 23:25:38+0000] Waiting for cluster API provider to install in the created admin cluster OK
[2023-03-22 23:25:48+0000] Moving admin cluster resources to the created admin cluster
[2023-03-22 23:25:51+0000] Waiting for node update jobs to finish OK
[2023-03-22 23:27:41+0000] Flushing logs... OK
[2023-03-22 23:27:41+0000] Deleting membership... OK
[2023-03-22 23:27:42+0000] Deleting bootstrap cluster.

管理クラスタに接続する

gkectl register bootstrap コマンドにより、管理ワークステーションに管理クラスタの kubeconfig ファイルが作成されます。kubeconfig が配置されているディレクトリとファイル名は、次のように管理クラスタ名に基づいています。

gkectl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

この kubeconfig にはクラスタの認証情報が含まれているため、アクセスを制限する必要があります。

また、Connect Gateway を介して読み取り専用の kubectl コマンドを実行することもできます。

gcloud CLI がインストールされている PC で次のコマンドを実行して、Connect Gateway 経由でクラスタにアクセスできる kubeconfig エントリを取得します。

gcloud container fleet memberships get-credentials ADMIN_CLUSTER_NAME \
    --project=PROJECT_ID

出力は次のようになります。

Starting to build Gateway kubeconfig...
Current project_id: PROJECT_ID
A new kubeconfig entry "connectgateway_PROJECT_ID_global_ADMIN_CLUSTER_NAME" has been generated and set as the current context.

これで、Connect Gateway を介して読み取り専用の kubectl コマンドを実行できるようになりました。
```
kubectl get pods -A
```
管理クラスタに対する完全な管理者権限が必要な場合は、Connect Gateway を設定するをご覧ください。

トラブルシューティング

クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。

次のステップ

ユーザークラスタを作成する

管理クラスタを作成する

始める前に

管理クラスタを任意のツールで作成する

gkectl

手順の概要

構成ファイルに入力する

name

bundlePath

vCenter

enableAdvancedCluster

network

loadBalancer

antiAffinityGroups

adminMaster

proxy

privateRegistry

componentAccessServiceAccountKeyPath

gkeConnect

gkeOnPremAPI

stackdriver

cloudAuditLogging

clusterBackup

autoRepair

secretsEncryption

osImageType

入力済みの構成ファイルの例

vc-01-admin-cluster.yaml

構成ファイルを検証する

OS イメージを取得する

管理クラスタを作成する

障害発生後に管理クラスタの作成を再開する

管理クラスタの kubeconfig ファイルを見つける

checkpoint.yaml ファイルを管理する

管理クラスタが実行されていることを確認する

ファイルをバックアップする

RBAC ポリシー

Terraform

手順の概要

構成ファイルに入力する

省略可: 限定公開レジストリを構成する

構成ファイルとプランを確認する

ブートストラップ クラスタを作成する

管理クラスタを作成する

コンソール

手順の概要

クラスタの構成を開始する

ブートストラップ環境のインストール

ブートストラップ環境の基本

vCenter 構成

CA 証明書の取得

管理ワークステーションからの環境のブートストラップ

管理クラスタの構成を完了する

クラスタの基本

コントロール プレーン

ネットワーキング

ロードバランサ

管理クラスタに接続する

トラブルシューティング

次のステップ

`name`

`bundlePath`

`vCenter`

`enableAdvancedCluster`

`network`

`loadBalancer`

`antiAffinityGroups`

`adminMaster`

`proxy`

`privateRegistry`

`componentAccessServiceAccountKeyPath`

`gkeConnect`

`gkeOnPremAPI`

`stackdriver`

`cloudAuditLogging`

`clusterBackup`

`autoRepair`

`secretsEncryption`

`osImageType`

`checkpoint.yaml` ファイルを管理する

ブートストラップクラスタを作成する

コントロールプレーン