GKE On-Prem API クライアントを使用してクラスタを作成する

このページでは、Google Cloud コンソール、Google Cloud CLI（gcloud CLI）、または Terraform を使用してユーザー クラスタを作成する方法について説明します。

GKE On-Prem API とは

GKE On-Prem API は、Google Cloud がホストする API で、Terraform や標準の Google Cloud アプリケーションを使用して、オンプレミス クラスタのライフサイクルを管理できます。GKE On-Prem API は、Google Cloud のインフラストラクチャで動作します。Terraform、コンソール、gcloud CLI はこの API のクライアントであり、この API を使用してデータセンターにクラスタを作成します。

クラスタのライフサイクルを管理するには、GKE On-Prem API がクラスタの作成時に指定した Google Cloud リージョンを使用して、クラスタの状態に関するメタデータを Google Cloud に保存する必要があります。このメタデータにより、API はクラスタのライフサイクルを管理できますが、メタデータにワークロード固有のデータは含まれません。

GKE On-Prem API クライアントを使用してクラスタを作成する場合は、Google Cloud プロジェクトを指定します。クラスタが作成されると、指定したプロジェクトのフリートに自動的に登録されます。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。フリートホスト プロジェクトは、クラスタの作成後は変更できません。

必要に応じて、gkectl を使用したユーザー クラスタの作成で説明されているように、ユーザー クラスタ構成ファイルを作成し gkectl を使用してユーザー クラスタを作成できます。

gkectl を使用して作成されたクラスタのライフサイクルを管理するために Terraform、コンソール、または gcloud CLI を使用する場合は、GKE On-Prem API で管理されるユーザー クラスタを構成するをご覧ください。

準備

このセクションでは、GKE On-Prem API クライアントを使用してユーザー クラスタを作成するための要件について説明します。

IAM 権限を付与

プロジェクト オーナーでない場合は、roles/gkeonprem.admin が付与されている必要があります。

コンソールで GKE Enterprise と Google Kubernetes Engine のページにアクセスするには、次のロールも付与されている必要があります。

クラスター作成後、プロジェクト オーナーでなく、Connect ゲートウェイを使用してコマンドラインでユーザー クラスターに接続する場合は、以下のロールが必要です。

  • roles/gkehub.gatewayAdmin: このロールを使用すると、Connect Gateway API にアクセスできます。クラスタへの読み取り専用権限のみが必要な場合は、roles/gkehub.gatewayReader で十分です。

  • roles/gkehub.viewer: このロールでは、クラスタの認証情報を取得できます。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

管理クラスタを登録する

GKE On-Prem API クライアントを使用してユーザー クラスタを作成するにあたり、管理クラスタがフリートに登録されている必要があります。

  • 管理クラスタをまだ作成していない場合は、管理クラスタ構成ファイルの gkeConnect セクションを記述します。

  • 管理クラスタはあるが、まだ登録していない場合は、管理クラスタの登録をご覧ください。

管理クラスタの管理アクティビティ監査ログを有効にする

Cloud Audit Logs への管理アクティビティ ロギングは、管理クラスタで有効にする必要があります。

管理クラスタのシステムレベルのロギングとモニタリングを有効にする

Cloud Logging と Cloud Monitoring は、管理クラスタで有効にする必要があります。

必要な Google API

フリートホスト プロジェクトで、必要な Google API がすべて有効化されていることを確認してください。

また、GKE On-Prem API を有効にする必要があります。

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

コマンドライン アクセス

クラスタを作成した後、Connect ゲートウェイを使用してコマンドラインでユーザー クラスタに接続する場合は、次の操作を行います。

次のコマンドライン ツールがインストールされていることを確認します。

  • 最新バージョンの gcloud CLI。
  • Kubernetes クラスタに対してコマンドを実行するために使用する kubectl。kubectl をインストールする必要がある場合は、以下の手順に沿ってください。

Google Cloud を操作するシェル環境として Cloud Shell を使用する場合は、これらのツールがインストールされます。

新規インストールに使用可能なバージョン

ユーザー クラスタを作成する場合は、通常、管理クラスタに一致するバージョンの GKE on VMware をインストールします。ただし、それ以降のパッチ バージョンまたは 1 つ以降のマイナー バージョンをインストールできます。たとえば、バグ修正を適用するために、ユーザー クラスタの作成時に最新のパッチリリースをインストールできます。リリースされた GKE on VMware のバージョンが GKE On-Prem API で利用可能になるまでに、約 7～10 日かかります。

管理クラスタよりも新しいバージョンのユーザー クラスタを作成する場合は、まず管理クラスタがそのバージョンのユーザー クラスタを管理するために必要なバージョン固有のコンポーネント バンドルをダウンロードしてから、そのコンポーネントをデプロイします。詳細については、管理クラスタのバージョンよりも新しいバージョンをインストールするをご覧ください。

クラスタを作成するためのツールを選択する

Terraform、Google Cloud コンソール、または Google Cloud CLI（gcloud CLI）を使用して、GKE On-Prem API で管理されるクラスタを作成できます。GKE on VMware を初めてインストールする場合は、コンソールが最も使いやすいツールになるでしょう。

クラスタを作成する際に入力する必要がある情報に慣れてきたら、複数のクラスタを作成する場合は、Terraform または gcloud CLI の方が便利になるかもしれません。Terraform は、業界標準の Infrastructure as Code（IAC）ツールです。組織ですでに Terraform を使用している場合は、クラスタの作成およびクラスタ ライフサイクルの管理に Terraform を使用するでしょう。

gcloud CLI を使用すると、コマンドを引数とともにテキスト ファイルに保存し、必要に応じて追加のクラスタを作成できます。Cloud Build などの CI / CD ツールを使用している場合は、gcloud コマンドを使用してクラスタとノードプールを作成し、--impersonate-service-account フラグを指定して作成を自動化できます。

ユーザー クラスタの作成

コンソール

Google Cloud コンソールのほとんどのフィールドは、ユーザー クラスタ構成ファイルのフィールドに対応しています。

  1. Google Cloud コンソールで、[GKE on VMware クラスタを作成する] ページに移動します。

    [GKE on VMware クラスタを作成する] に移動する

  2. クラスタを作成する Google Cloud プロジェクトを選択します。選択したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。

次のセクションでは、ユーザー クラスタの構成について説明します。

クラスタの基本

クラスタの基本情報を入力します。

  1. ユーザー クラスタの名前を入力します。

  2. [管理クラスタ] で、リストから管理クラスタを選択します。管理クラスタの作成時にその名前を指定しなかった場合、名前は gke-admin-[HASH] の形式で生成されます。管理クラスタ名が確認できない場合は、管理ワークステーションで次のコマンドを実行します。

    KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'

    使用する管理クラスタが表示されない場合は、トラブルシューティングのセクション管理クラスタがクラスタの基本プルダウン リストに表示されないをご覧ください。

  3. [GCP API ロケーション] フィールドで、リストから Google Cloud リージョンを選択します。この設定では、GKE On-Prem API が実行されるリージョンと、以下のデータが保存されるリージョンを指定します。

    • クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

    クラスタ名、プロジェクト、ロケーションにより、Google Cloud が一意に識別されます。

  4. ユーザー クラスタの GKE on VMware のバージョンを選択します。

  5. クラスタ作成者には、クラスタに対するクラスタ管理者権限が付与されます。必要に応じて、[承認] セクションの [クラスタ管理者ユーザー] フィールドに、クラスタを管理する別のユーザーのメールアドレスを入力します。

    クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベース アクセス制御（RBAC）ポリシーがクラスタに適用され、クラスタの作成者と他の管理ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  6. [次へ] をクリックして [コントロール プレーン] セクションに移動します。

コントロール プレーン

[コントロール プレーン] セクションのすべてのフィールドでデフォルト値が設定されています。デフォルト値を確認し、必要に応じて変更します。

  1. [コントロール プレーン ノードの vCPU] フィールドに、ユーザー クラスタの各コントロール プレーン ノードの vCPU の数（最小値は 4）を入力します。
  2. [コントロール プレーン ノードのメモリ] フィールドに、ユーザー クラスタの各コントロール プレーンのメモリサイズを MiB 単位（最小 8192、4 の倍数）で入力します。
  3. [コントロール プレーン ノード] で、ユーザー クラスタのコントロール プレーン ノードの数を選択します。たとえば、開発環境用に 1 つのコントロール プレーン ノード、高可用性（HA）環境と本番環境用に 3 つのコントロール プレーン ノードを選択できます。
  4. 必要に応じて、[ノードの自動サイズ変更] を選択します。サイズ変更とは、ノードに割り当てられる vCPU リソースとメモリリソースが自動的に調整することを意味します。有効にすると、ユーザー クラスタのコントロール プレーン ノードは、ユーザー クラスタ内のワーカーノード数に従ってサイズ変更されます。そのため、ユーザー クラスタにワーカーノードを追加すると、コントロール プレーン ノードのサイズが増加します。

  5. 必要に応じて、[コントロール プレーン v2 を有効にする] を選択します。コントロール プレーン V2 を有効にすると、ユーザー クラスタのコントロール プレーンは管理クラスタ（kubeception モデルと呼ばれます）ではなく、ユーザー クラスタ自体の 1 つ以上のノードで実行されます。

    [コントロール プレーン v2 を有効にする] を選択すると、[コントロール プレーン ノードの IP] セクションが表示されます。ゲートウェイの IP アドレス、サブネット マスク、コントロール プレーンノードの IP アドレスを入力します。

    コントロール プレーン V2 が有効になっている場合、vCPU およびメモリ フィールドはユーザー クラスタ内のコントロール プレーン ノードに適用されます。ノードの数は、入力した IP アドレスの数によって決まります。コントロール プレーン V2 が有効になっていない場合、vCPU、メモリ、コントロール プレーン ノード数のフィールドは管理クラスタ内のノードに適用されます。管理クラスタに十分な IP アドレスを確保するようにしてください。

  6. [次へ] をクリックして [ネットワーキング] セクションに移動します。

ネットワーキング

このセクションでは、クラスタのノード、Pod、Service の IP アドレスを指定します。ユーザー クラスタには、ノードごとに 1 つの IP アドレスと、クラスタのアップグレード、更新、自動修復に必要な一時的なノードに別の IP アドレスが必要です。詳細については、ユーザー クラスタに必要な IP アドレス数をご覧ください。

  1. [ノード IP] セクションで、ユーザー クラスタの [IP モード] を選択します。次のいずれかを選択します。

    • DHCP: クラスタノードが、IP アドレスを DHCP サーバーから取得するようにするには、[DHCP] を選択します。

    • 静的: クラスタノードに静的 IP アドレスを用意する場合や、手動ロード バランシングを設定する場合は、[静的] を選択します。

  2. [DHCP] を選択した場合は、次の手順にスキップして Service と Pod の CIDR を指定します。[静的 IP モード] で、次の情報を入力します。

    1. ユーザー クラスタ用ゲートウェイの IP アドレスを入力します。

    2. ユーザー クラスタ ノードのサブネット マスクを入力します。

    3. [IP アドレス] セクションで、IP アドレスと、必要に応じてユーザー クラスタ内のノードのホスト名を入力します。個別の IP v4 アドレス（192.0.2.1 など）か IPv4 アドレスの CIDR ブロック（192.0.2.0/24 など）を入力できます。

      • CIDR ブロックを入力する場合、ホスト名は入力しないでください。
      • 個々の IP アドレスを入力する場合は、必要に応じてホスト名を入力できます。ホスト名を入力しない場合、GKE on VMware はホスト名として vSphere の VM 名を使用します。

    4. 必要に応じて [+ IP アドレスを追加] をクリックし、さらに IP アドレスを追加します。

  3. Service と Pod CIDR セクションには、Kubernetes Service と Pod の次のアドレス範囲がコンソールにより指定されます。

    • サービス CIDR: 10.96.0.0/20
    • Pod CIDR: 192.168.0.0/16

    独自のアドレス範囲を入力する場合は、Pod と Service 向け IP アドレスのベスト プラクティスをご覧ください。

  4. [静的 IP モード] または [コントロール プレーン v2 を有効にする] を選択した場合は、[ホスト設定] セクションで次の情報を指定します。

    1. DNS サーバーの IP アドレスを入力します。
    2. NTP サーバーの IP アドレスを入力します。
    3. 必要に応じて、DNS 検索ドメインを入力します。

  5. [次へ] をクリックして [ロードバランサ] セクションに移動します。

ロードバランサ

クラスタに対して設定するロードバランサを選択します。詳しくは、ロードバランサの概要をご覧ください。

リストから [ロードバランサの種類] を選択します。

MetalLB にバンドル済み

MetalLB を使用してバンドルされたロード バランシングを構成します。管理クラスタが SeeSaw または MetalLB を使用している場合にのみ、ユーザー クラスタに MetalLB を使用できます。このオプションでは、最小限の構成が求められます。MetalLB は、直接クラスタノードで動作し、追加の VM は不要です。MetalLB を使用するメリットと他のロード バランシング オプションとの比較については、MetalLB によるバンドルされたロード バランシングをご覧ください。

  1. [アドレスプール] セクションで、次のようにアドレスプールを少なくとも 1 つ構成します。

    1. アドレスプールの名前を入力します。

    2. 上り（内向き）VIP を含む IP アドレス範囲を CIDR 表記（例: 192.0.2.0/26）または範囲表記（例: 192.0.2.64-192.0.2.72）で入力します。プール内の IP アドレスを 1 つ指定するには、CIDR 表記で /32 を使用します（例: 192.0.2.1/32）。

    3. LoadBalancer タイプの Service の IP アドレスが上り（内向き）VIP と同じ IP アドレス範囲でない場合は、[+ IP アドレス範囲を追加] をクリックして別のアドレスを入力します。

      各プール内での IP アドレスは重複してはならず、かつクラスタノードと同じサブネット内に存在する必要があります。

    4. [IP アドレスの割り当て] で、次のいずれかを選択します。

      • 自動: MetalLB コントローラでアドレスプールから IP アドレスを LoadBalancer タイプのサービスに自動的に割り振るには、このオプションを選択します。
      • 手動: プールのアドレスを使用して LoadBalancer タイプの Service のアドレスを手動で指定する場合は、このオプションを選択します。

    5. 末尾が .0 または .255 のプールのアドレスを MetalLB コントローラで使用しないようにするには、[バグのある IP アドレスを避ける] をクリックします。これにより、バグの多いコンシューマ デバイスが、これらの特別な IP アドレスに送信されたトラフィックを誤って破棄するという問題を回避できます。

    6. 設定を終えたら、[完了] をクリックします。

  2. 必要に応じて、[アドレスプールを追加する] をクリックします。

  3. [仮想 IP] セクションで、以下を入力します。

    • コントロール プレーン VIP: ユーザー クラスタの Kubernetes API サーバーに送信されるトラフィックに使用する宛先 IP アドレス。ユーザー クラスタの Kubernetes API サーバーは、管理クラスタ内のノードで動作します。この IP アドレスは、管理クラスタノードと同じ L2 ドメイン内になければなりません。このアドレスを [アドレスプール] セクションには追加しないでください。

    • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。これは、[アドレスプール] セクションにあるアドレスプールに追加する必要があります。

  4. [続行] をクリックします。

F5 Big-IP ロードバランサ

管理クラスタが F5 を使用している場合のみ、ユーザー クラスタに F5 を使用できます。F5 BIG-IP ADC のインストールと構成は、GKE on VMware と統合する前に行います。

  1. [仮想 IP] セクションで、以下を入力します。

    • コントロール プレーン VIP: Kubernetes API サーバーに送信するトラフィックに使用される宛先 IP アドレス。

    • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。

  2. [アドレス] フィールドに、F5 BIG-IP ロードバランサのアドレスを入力します。

  3. [パーティション] フィールドに、ユーザー クラスタ用に作成した BIG-IP パーティションの名前を入力します。

  4. 該当する場合は、[SNAT プール名] フィールドに SNAT プールの名前を入力します。

  5. [続行] をクリックします。

手動ロードバランサ

手動ロード バランシングを構成します。管理クラスタが手動ロードバランサを使用している場合にのみ、ユーザー クラスタに手動ロードバランサを使用できます。GKE on VMware では、Kubernetes API サーバー、Ingress プロキシ、ログ集計用のアドオン サービスはそれぞれ LoadBalancer タイプの Kubernetes Service によって公開されます。これらの Service 用に、30000～32767 の範囲で独自の nodePort 値を選択します。Ingress プロキシには、HTTP と HTTPS 両方のトラフィックに nodePort 値を選択します。詳細については、手動ロード バランシング モードの有効化をご覧ください。

  1. [仮想 IP] セクションで、以下を入力します。

    • コントロール プレーン VIP: Kubernetes API サーバーに送信するトラフィックに使用される宛先 IP アドレス。

    • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。

  2. [コントロール プレーン ノードポート] フィールドに、Kubernetes API サーバーの nodePort 値を入力します。ユーザー クラスタの Kubernetes API サーバーは管理クラスタで実行されます。

  3. [内向き HTTP ノードポート] フィールドに、内向きプロキシへの HTTP トラフィックの nodePort 値を入力します。

  4. [内向き HTTPS ノードポート] フィールドに、内向きプロキシへの HTTPS トラフィックの nodePort 値を入力します。

  5. [Konnectivity サーバー ノードポート] フィールドに、Knnectivity サーバーの nodePort 値を入力します。ノード

  6. [続行] をクリックします。

機能

このセクションには、クラスタで有効になっている機能と操作が表示されます。

以下は自動で有効になり、無効にすることはできません。

  1. 以下はデフォルトで有効になっていますが、無効にもできます。

    • vSphere CSI ドライバの有効化: vSphere Container Storage Plug-in とも呼ばれます。Container Storage Interface（CSI）ドライバは、vSphere にデプロイされたネイティブの Kubernetes クラスタで実行されて、vSphere ストレージに永続ボリュームをプロビジョニングします。詳細については、vSphere Container Storage Interface ドライバの使用をご覧ください。
    • 反アフィニティ グループを有効にする: VMware Distributed Resource Scheduler（DRS）の反アフィニティ ルールは、ユーザー クラスタのノードに対して自動的に作成され、データセンター内の少なくとも 3 つの物理ホストに分散されます。vSphere 環境が、要件を満たしていることを確認します。

  2. [次へ] をクリックしてノードプールを構成します。

ノードプール

クラスタは、少なくとも 1 つのノードプールを含めて作成されます。ノードプールは、このクラスタで作成されたノードのグループのテンプレートです。詳細については、ノードプールの作成と管理をご覧ください。

  1. [ノードプールのデフォルト] セクションで、次の操作を行います。

    1. [ノードプール名] を入力するか、名前として「default-pool」を使用します。
    2. プール内の各ノードの vCPU の数（ユーザー クラスタ ワーカーあたりの最小値は 4）を入力します。
    3. プール内の各ノードのメモリサイズをメガバイト（MiB）単位で入力します（ユーザー クラスタのワーカーノードあたり最小 8,192 MiB、4 の倍数でなければなりません）。
    4. [ノード] フィールドにプール内のノードの数（3 以上）を入力します。[ネットワーキング] セクションで [ノード IP] に静的 IP アドレスを入力した場合は、これらのユーザー クラスタノードに対応できる十分な IP アドレスが入力されていることを確認します。
    5. [OS イメージタイプ] （[Ubuntu]、[Ubuntu Containerd]、[COS]）を選択します。
    6. [ブートディスク サイズ] をギガバイト（GiB）（最小 40 GiB）で入力します。
    7. MetalLB をロードバランサとして使用する場合は、少なくとも 1 つのノードプールで MetalLB を有効にする必要があります。[このノードプールを MetalLB のロード バランシングに使用する] を選択したままにするか、MetalLB に使用する別のノードプールを追加します。

  2. [ノードプールのメタデータ（省略可） セクションで、Kubernetes ラベルおよび taint を追加する場合、次の操作を行います。

    1. [+ Add Kubernetes Labels] をクリックします。ラベルの [キー] と [値] を入力します。以上の手順を必要なだけ繰り返してください。
    2. [+ taint を追加] をクリックします。taint の [キー]、[値]、[効果] を入力します。以上の手順を必要なだけ繰り返してください。

  3. [Verify and Complete] をクリックしてユーザー クラスタを作成します。ユーザー クラスタの作成には 15 分以上かかります。コンソールで設定を確認し、データセンターにクラスタを作成するときに、ステータス メッセージが表示されます。

    設定の確認中にエラーが発生した場合は、コンソールにエラー メッセージが表示されます。これにより、構成の問題を修正してクラスタを再度作成することが簡単に行えます。

    発生する可能性のあるエラーと修正方法の詳細については、Google Cloud コンソールでのユーザー クラスタの作成に関するトラブルシューティングをご覧ください。

gcloud CLI

次のコマンドを使用して、ユーザー クラスタを作成します。

gcloud container vmware clusters create

クラスタを作成したら、次のコマンドを使用して少なくとも 1 つのノードプールを作成する必要があります。

gcloud container vmware node-pools create

クラスタとノードプールを作成するフラグのほとんどは、ユーザー クラスタ構成ファイルのフィールドに対応しています。すぐに始められるように、例セクションで完全なコマンドをテストできます。

準備

  1. 自分の Google アカウントでログインします。

    gcloud auth login

  2. コンポーネントを必ず更新します。

    gcloud components update

  3. 使用可能なバージョンのリストを取得します。

    gcloud container vmware clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --location=REGION

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

    • ADMIN_CLUSTER_NAME: 管理クラスタの名前。

    • FLEET_HOST_PROJECT_ID: 管理クラスタが登録されているプロジェクトの ID。

    • REGION: GKE On-Prem API でクラスタを登録したときに指定した Google Cloud リージョン。

    コマンドの出力は、次のようになります。

    versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581

ユーザー クラスタの作成に使用できるバージョンには、isInstalled=true というアノテーションが付いています。つまり、管理クラスタには、そのバージョンのユーザー クラスタを管理するために必要なバージョン特有のコンポーネントがあります。別の利用可能なバージョンでユーザー クラスタを作成する場合は、管理クラスタのバージョンよりも新しいバージョンをインストールするをご覧ください。

例

次の例は、さまざまなロードバランサでユーザー クラスタを作成する方法を示しています。使用可能なロード バランシング オプションの詳細については、ロードバランサの概要をご覧ください。

これらの例ではデフォルト値を使用して、コントロール プレーン ノードを構成しています。デフォルトを変更する場合は、コントロール プレーンのフラグセクションで説明されているフラグを指定します。必要に応じて、vSphere 設定の一部を変更することもできます。

クラスタの稼働後、ノードプールの作成セクションで説明されているように、ワークロードをデプロイする前にノードプールを追加する必要があります。

MetalLB と DHCP

この例では、バンドル型 MetalLB ロードバランサを使用してユーザー クラスタを作成し、DHCP サーバーを使用してクラスタノードの IP アドレスを取得する方法を示します。

管理クラスタが SeeSaw または MetalLB を使用している場合にのみ、ユーザー クラスタに MetalLB を使用できます。このロード バランシング オプションでは、最小限の構成が求められます。MetalLB は、直接クラスタノードで動作し、追加の VM は不要です。MetalLB を使用するメリットと他のロード バランシング オプションとの比較については、MetalLB によるバンドルされたロード バランシングをご覧ください。

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。この例では、完全指定の管理クラスタ名を使用しているため、--admin-cluster-membership-location と --admin-cluster-membership-project を指定する必要はありません。

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp
  • USER_CLUSTER_NAME: ユーザー クラスタの任意の名前。この名前はクラスタの作成後は変更できません。 名前は次の条件を満たしている必要があります。
    • 最大文字数は 40 文字とする
    • 小文字の英数字またはハイフン（-）のみを使用している
    • 先頭が英字である
    • 末尾が英数字である
  • FLEET_HOST_PROJECT_ID: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリート ホスト プロジェクトは、クラスタの作成後は変更できません。
  • ADMIN_CLUSTER_NAME: ユーザー クラスタを管理する管理クラスタの名前。--admin-cluster-membership フラグには、次の形式での完全指定のクラスタ名を使用できます。 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    あるいは、コマンドの例のように、--admin-cluster-membership を管理クラスタの名前に設定できます。管理クラスタの名前のみを使用する場合は、管理クラスタのプロジェクト ID を --admin-cluster-membership-project で設定し、ロケーションを --admin-cluster-membership-location で設定します。管理クラスタのロケーションは、global または Google Cloud リージョンのいずれかです。リージョンを確認する必要がある場合は、gcloud container fleet memberships list を実行します。

  • REGION: GKE On-Prem API（gkeonprem.googleapis.com）、フリート サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

    クラスタ名、プロジェクト、ロケーションの組み合わせにより、Google Cloud でクラスタが一意に識別されます。

  • VERSION: ユーザー クラスタの GKE on VMware のバージョン。
  • YOUR_EMAIL_ADDRESS、ANOTHER_EMAIL_ADDRESS: --admin-users フラグを指定しない場合、クラスタ作成者として、デフォルトではクラスタ管理者権限が付与されます。しかし、--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。たとえば、2 人の管理者を追加するには、次のようにします。
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベース アクセス制御（RBAC）ポリシーがクラスタに適用され、クラスタの作成者と他の管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲を指定してください。

    例: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲を指定してください。

    例: --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: MetalLB ロードバランサで使用するアドレスプールの構成を指定するには、このフラグを含めます。フラグの値の形式は次のとおりです。 
    --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

    この値には、pool、avoid-buggy-ip、manual-assign、addresses というキーワードで始まるセグメントがあります。各セグメントはカンマで区切ります。

    • pool: ノードプールに付ける名前。
    • avoid-buggy-ips: これを True に設定すると、MetalLB コントローラは .0 または .255 で終わる IP アドレスを Service に割り当てません。これにより、バグの多いコンシューマ デバイスが、これらの特別な IP アドレスに送信されたトラフィックを誤って破棄するという問題を回避できます。指定しない場合、デフォルトで False になります。
    • manual-assign: MetalLB コントローラがこのプールから Service に IP アドレスを自動的に割り当てないようにする場合は、これを True に設定します。次に、デベロッパーは、LoadBalancer タイプの Service を作成し、プールからアドレスのいずれか 1 つを手動で指定します。指定しない場合、manual-assign は False に設定されます。
    • addresses のリスト内: 各アドレスは CIDR 表記またはハイフン付き範囲形式のいずれかの範囲である必要があります。プール内の単一の IP アドレス（Ingress VIP など）を指定するには、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

    次の点にご注意ください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は使用できません。
    • 各 IP アドレス範囲をセミコロンで区切ります。

    例:

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: ユーザー クラスタの Kubernetes API サーバー用にロードバランサ上に構成することを選択した IP アドレス。

    例: --control-plane-vip=203.0.113.3

  • INGRESS_VIP: Ingress プロキシのロードバランサを構成するために選択した IP アドレス。

    例: --ingress-vip=10.251.134.80

    Ingress VIP の IP アドレスが MetalLB アドレスプールのいずれかにある必要があります。

  • --enable-dhcp: 指定した DHCP サーバーからクラスタノードが IP アドレスを取得するようにするには、--enable-dhcp を指定します。クラスタノードに静的 IP アドレスを設定する場合や、手動ロード バランシングを設定する場合は、このフラグを指定しないでください。

MetalLB と静的 IP

この例では、バンドル型 MetalLB ロードバランサを使用してユーザー クラスタを作成し、クラスタノードに静的 IP アドレスを割り当てる方法を示します。

管理クラスタが SeeSaw または MetalLB を使用している場合にのみ、ユーザー クラスタに MetalLB を使用できます。このロード バランシング オプションでは、最小限の構成が求められます。MetalLB は、直接クラスタノードで動作し、追加の VM は不要です。MetalLB を使用するメリットと他のロード バランシング オプションとの比較については、MetalLB によるバンドルされたロード バランシングをご覧ください。

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。この例では、完全指定の管理クラスタ名を使用しているため、--admin-cluster-membership-location と --admin-cluster-membership-project を指定する必要はありません。

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
  --dns-servers=DNS_SERVER,... \
  --dns-search-domains=DNS_SEARCH_DOMAIN,... \
  --ntp-servers=NTP_SERVER,...

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

  • USER_CLUSTER_NAME: ユーザー クラスタの任意の名前。この名前はクラスタの作成後は変更できません。 名前は次の条件を満たしている必要があります。
    • 最大文字数は 40 文字とする
    • 小文字の英数字またはハイフン（-）のみを使用している
    • 先頭が英字である
    • 末尾が英数字である
  • FLEET_HOST_PROJECT_ID: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリート ホスト プロジェクトは、クラスタの作成後は変更できません。
  • ADMIN_CLUSTER_NAME: ユーザー クラスタを管理する管理クラスタの名前。--admin-cluster-membership フラグには、次の形式での完全指定のクラスタ名を使用できます。 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    あるいは、コマンドの例のように、--admin-cluster-membership を管理クラスタの名前に設定できます。管理クラスタの名前のみを使用する場合は、管理クラスタのプロジェクト ID を --admin-cluster-membership-project で設定し、ロケーションを --admin-cluster-membership-location で設定します。管理クラスタのロケーションは、global または Google Cloud リージョンのいずれかです。リージョンを確認する必要がある場合は、gcloud container fleet memberships list を実行します。

  • REGION: GKE On-Prem API（gkeonprem.googleapis.com）、フリート サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

    クラスタ名、プロジェクト、ロケーションの組み合わせにより、Google Cloud でクラスタが一意に識別されます。

  • VERSION: ユーザー クラスタの GKE on VMware のバージョン。
  • YOUR_EMAIL_ADDRESS、ANOTHER_EMAIL_ADDRESS: --admin-users フラグを指定しない場合、クラスタ作成者として、デフォルトではクラスタ管理者権限が付与されます。しかし、--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。たとえば、2 人の管理者を追加するには、次のようにします。
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベース アクセス制御（RBAC）ポリシーがクラスタに適用され、クラスタの作成者と他の管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲を指定してください。

    例: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲を指定してください。

    例: --pod-address-cidr-blocks=192.168.0.0/16

  • --metal-lb-config-address-pools: MetalLB ロードバランサで使用するアドレスプールの構成を指定するには、このフラグを含めます。フラグの値の形式は次のとおりです。 
    --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

    この値には、pool、avoid-buggy-ip、manual-assign、addresses というキーワードで始まるセグメントがあります。各セグメントはカンマで区切ります。

    • pool: ノードプールに付ける名前。
    • avoid-buggy-ips: これを True に設定すると、MetalLB コントローラは .0 または .255 で終わる IP アドレスを Service に割り当てません。これにより、バグの多いコンシューマ デバイスが、これらの特別な IP アドレスに送信されたトラフィックを誤って破棄するという問題を回避できます。指定しない場合、デフォルトで False になります。
    • manual-assign: MetalLB コントローラがこのプールから Service に IP アドレスを自動的に割り当てないようにする場合は、これを True に設定します。次に、デベロッパーは、LoadBalancer タイプの Service を作成し、プールからアドレスのいずれか 1 つを手動で指定します。指定しない場合、manual-assign は False に設定されます。
    • addresses のリスト内: 各アドレスは CIDR 表記またはハイフン付き範囲形式のいずれかの範囲である必要があります。プール内の単一の IP アドレス（Ingress VIP など）を指定するには、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

    次の点にご注意ください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は使用できません。
    • 各 IP アドレス範囲をセミコロンで区切ります。

    例:

    --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'
  • CONTROL_PLANE_VIP: ユーザー クラスタの Kubernetes API サーバー用にロードバランサ上に構成することを選択した IP アドレス。

    例: --control-plane-vip=203.0.113.3

  • INGRESS_VIP: Ingress プロキシのロードバランサを構成するために選択した IP アドレス。

    例: --ingress-vip=10.251.134.80

    Ingress VIP の IP アドレスが MetalLB アドレスプールのいずれかにある必要があります。

  • --static-ip-config-ip-blocks: ユーザー クラスタ内のワーカーノードのデフォルト ゲートウェイ、サブネット マスク、静的 IP アドレスのリストを指定します。フラグの値の形式は次のとおりです。 
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

    この値には、gateway、netmask、ips というキーワードで始まるセグメントがあります。セグメントはカンマで区切ります。

    次の点にご注意ください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は、IP アドレスとホスト名の間を除き、使用できません。

    IP アドレスのリスト内:

    • 個々の IP アドレスまたは IP アドレスの CIDR ブロックを指定できます。
    • 各 IP アドレスまたは CIDR ブロックはセミコロンで区切ります。
    • 個々の IP アドレスについては、必要に応じて、IP アドレスの後にホスト名を指定できます。IP アドレスとホスト名はスペースで区切ります。ホスト名を指定しない場合、GKE on VMware はホスト名として vSphere の VM 名を使用します。
    • CIDR ブロックを指定する場合は、ホスト名の値を指定しないでください。

    例:

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: VM の DNS サーバーの IP アドレスのカンマ区切りのリスト。
  • DNS_SEARCH_DOMAIN: ホストが使用する DNS 検索ドメインのカンマ区切りのリスト。これらのドメインは、ドメイン検索リストの一部として使用されます。

    例:

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: VM が使用する時刻サーバーの IP アドレスのカンマ区切りのリスト。

F5 BIG-IP と DHCP

この例では、F5 BIG-IP ロードバランサを使用してユーザー クラスタを作成し、DHCP サーバーを使用してクラスタノードの IP アドレスを取得する方法を示します。

管理クラスタが F5 を使用している場合のみ、ユーザー クラスタに F5 を使用できます。F5 BIG-IP ADC のインストールと構成は、GKE on VMware と統合する前に行います。詳細については、F5 BIG-IP ADC インストール ガイドをご覧ください。F5 のユーザー名とパスワードは管理クラスタから継承されます。

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。この例では、完全指定の管理クラスタ名を使用しているため、--admin-cluster-membership-location と --admin-cluster-membership-project を指定する必要はありません。

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --f5-config-address=F5_CONFIG_ADDRESS \
  --f5-config-partition=F5_CONFIG_PARTITION \
  --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
  --control-plane-vipCONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp
  • USER_CLUSTER_NAME: ユーザー クラスタの任意の名前。この名前はクラスタの作成後は変更できません。 名前は次の条件を満たしている必要があります。
    • 最大文字数は 40 文字とする
    • 小文字の英数字またはハイフン（-）のみを使用している
    • 先頭が英字である
    • 末尾が英数字である
  • FLEET_HOST_PROJECT_ID: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリート ホスト プロジェクトは、クラスタの作成後は変更できません。
  • ADMIN_CLUSTER_NAME: ユーザー クラスタを管理する管理クラスタの名前。--admin-cluster-membership フラグには、次の形式での完全指定のクラスタ名を使用できます。 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    あるいは、コマンドの例のように、--admin-cluster-membership を管理クラスタの名前に設定できます。管理クラスタの名前のみを使用する場合は、管理クラスタのプロジェクト ID を --admin-cluster-membership-project で設定し、ロケーションを --admin-cluster-membership-location で設定します。管理クラスタのロケーションは、global または Google Cloud リージョンのいずれかです。リージョンを確認する必要がある場合は、gcloud container fleet memberships list を実行します。

  • REGION: GKE On-Prem API（gkeonprem.googleapis.com）、フリート サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

    クラスタ名、プロジェクト、ロケーションの組み合わせにより、Google Cloud でクラスタが一意に識別されます。

  • VERSION: ユーザー クラスタの GKE on VMware のバージョン。
  • YOUR_EMAIL_ADDRESS、ANOTHER_EMAIL_ADDRESS: --admin-users フラグを指定しない場合、クラスタ作成者として、デフォルトではクラスタ管理者権限が付与されます。しかし、--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。たとえば、2 人の管理者を追加するには、次のようにします。
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベース アクセス制御（RBAC）ポリシーがクラスタに適用され、クラスタの作成者と他の管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲を指定してください。

    例: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲を指定してください。

    例: --pod-address-cidr-blocks=192.168.0.0/16

  • F5_CONFIG_ADDRESS: F5 BIG-IP ロードバランサのアドレス。

  • F5_CONFIG_PARTITION: ユーザー クラスタ用に作成した BIG-IP パーティションの名前。

  • F5_CONFIG_SNAT_POOL: SNAT プールの名前（該当する場合）。

  • CONTROL_PLANE_VIP: ユーザー クラスタの Kubernetes API サーバー用にロードバランサ上に構成することを選択した IP アドレス。

    例: --control-plane-vip=203.0.113.3

  • INGRESS_VIP: Ingress プロキシのロードバランサを構成するために選択した IP アドレス。

    例: --ingress-vip=10.251.134.80

    Ingress VIP の IP アドレスが MetalLB アドレスプールのいずれかにある必要があります。

  • --enable-dhcp: 指定した DHCP サーバーからクラスタノードが IP アドレスを取得するようにするには、--enable-dhcp を指定します。クラスタノードに静的 IP アドレスを設定する場合や、手動ロード バランシングを設定する場合は、このフラグを指定しないでください。

手動 LB と静的 IP

この例では、手動ロードバランサを使用してユーザー クラスタを作成し、クラスタノードに静的 IP アドレスを割り当てる方法を示します。

管理クラスタが手動ロードバランサを使用している場合にのみ、ユーザー クラスタに手動ロードバランサを使用できます。GKE on VMware では、Kubernetes API サーバー、Ingress プロキシ、ログ集計用のアドオン サービスはそれぞれ LoadBalancer タイプの Kubernetes Service によって公開されます。これらの Service 用に、30000～32767 の範囲で独自の nodePort 値を選択します。Ingress プロキシには、HTTP と HTTPS 両方のトラフィックに nodePort 値を選択します。詳細については、手動ロード バランシング モードの有効化をご覧ください。

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。この例では、完全指定の管理クラスタ名を使用しているため、--admin-cluster-membership-location と --admin-cluster-membership-project を指定する必要はありません。

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
  --ingress-vip=INGRESS_VIP \
  --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
  --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
  --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

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

  • USER_CLUSTER_NAME: ユーザー クラスタの任意の名前。この名前はクラスタの作成後は変更できません。 名前は次の条件を満たしている必要があります。
    • 最大文字数は 40 文字とする
    • 小文字の英数字またはハイフン（-）のみを使用している
    • 先頭が英字である
    • 末尾が英数字である
  • FLEET_HOST_PROJECT_ID: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリート ホスト プロジェクトは、クラスタの作成後は変更できません。
  • ADMIN_CLUSTER_NAME: ユーザー クラスタを管理する管理クラスタの名前。--admin-cluster-membership フラグには、次の形式での完全指定のクラスタ名を使用できます。 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    あるいは、コマンドの例のように、--admin-cluster-membership を管理クラスタの名前に設定できます。管理クラスタの名前のみを使用する場合は、管理クラスタのプロジェクト ID を --admin-cluster-membership-project で設定し、ロケーションを --admin-cluster-membership-location で設定します。管理クラスタのロケーションは、global または Google Cloud リージョンのいずれかです。リージョンを確認する必要がある場合は、gcloud container fleet memberships list を実行します。

  • REGION: GKE On-Prem API（gkeonprem.googleapis.com）、フリート サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクルを管理する際に GKE On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

    クラスタ名、プロジェクト、ロケーションの組み合わせにより、Google Cloud でクラスタが一意に識別されます。

  • VERSION: ユーザー クラスタの GKE on VMware のバージョン。
  • YOUR_EMAIL_ADDRESS、ANOTHER_EMAIL_ADDRESS: --admin-users フラグを指定しない場合、クラスタ作成者として、デフォルトではクラスタ管理者権限が付与されます。しかし、--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。たとえば、2 人の管理者を追加するには、次のようにします。
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベース アクセス制御（RBAC）ポリシーがクラスタに適用され、クラスタの作成者と他の管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールは、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権を付与します。

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲を指定してください。

    例: --service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲を指定してください。

    例: --pod-address-cidr-blocks=192.168.0.0/16

  • CONTROL_PLANE_VIP: ユーザー クラスタの Kubernetes API サーバー用ロードバランサに構成するよう選択した IP アドレス。

    例: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_NODE_PORT: Kubernetes API サーバーの nodePort 値。

  • INGRESS_VIP: Ingress プロキシのロードバランサに構成するよう選択した IP アドレス。

    例: --ingress-vip=203.0.113.4

  • INGRESS_HTTP_NODE_PORT: 内向きプロキシへの HTTP トラフィックの nodePort 値。

  • INGRESS_HTTPS_NODE_PORT: Ingress プロキシへの HTTPS トラフィックの nodePort 値

  • KONNECTIVITY_SERVER_NODE_PORT: Konnectivity サーバーの nodePort 値。

  • --static-ip-config-ip-blocks: ユーザー クラスタ内のワーカーノードのデフォルト ゲートウェイ、サブネット マスク、静的 IP アドレスのリストを指定します。フラグの値の形式は次のとおりです。 
    --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

    この値には、gateway、netmask、ips というキーワードで始まるセグメントがあります。セグメントはカンマで区切ります。

    次の点にご注意ください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は、IP アドレスとホスト名の間を除き、使用できません。

    IP アドレスのリスト内:

    • 個々の IP アドレスまたは IP アドレスの CIDR ブロックを指定できます。
    • 各 IP アドレスまたは CIDR ブロックはセミコロンで区切ります。
    • 個々の IP アドレスについては、必要に応じて、IP アドレスの後にホスト名を指定できます。IP アドレスとホスト名はスペースで区切ります。ホスト名を指定しない場合、GKE on VMware はホスト名として vSphere の VM 名を使用します。
    • CIDR ブロックを指定する場合は、ホスト名の値を指定しないでください。

    例:

    --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'
  • DNS_SERVER: VM の DNS サーバーの IP アドレスのカンマ区切りのリスト。
  • DNS_SEARCH_DOMAIN: ホストが使用する DNS 検索ドメインのカンマ区切りのリスト。これらのドメインは、ドメイン検索リストの一部として使用されます。

    例:

    --dns-search-domains example.com,examplepetstore.com
  • NTP_SERVER: VM が使用する時刻サーバーの IP アドレスのカンマ区切りのリスト。

フラグとその説明の完全なリストについては、gcloud CLI リファレンスをご覧ください。

コントロール プレーンのフラグ

コントロール プレーンの構成にデフォルト以外の値を使用する場合は、次のフラグを 1 つ以上指定します。

  • --cpus=vCPUS: ユーザー クラスタの各コントロール プレーン ノードの vCPU の数（最小値は 4）。指定しない場合、デフォルトは 4 個の vCPU です。

  • --memory=MEMORY: ユーザー クラスタの各コントロール プレーンのメモリサイズ（メビバイト（MiB）単位）。最小値は 8192 で、4 の倍数でなければなりません。指定しない場合、デフォルトは 8192 です。

  • --replicas=NODES: ユーザー クラスタのコントロール プレーン ノードの数。たとえば、開発環境用に 1 つのコントロール プレーン ノード、高可用性（HA）環境と本番環境用に 3 つのコントロール プレーン ノードを選択できます。

  • --enable-auto-resize: ユーザー クラスタのコントロール プレーン ノードの自動サイズ変更を有効にする場合は、--enable-auto-resize を指定します。サイズ変更とは、ノードに割り当てられる vCPU とメモリリソースが自動的に調整されることを意味します。有効にすると、ユーザー クラスタのコントロール プレーン ノードは、ユーザー クラスタ内のワーカーノード数に従ってサイズ変更されます。そのため、ユーザー クラスタにワーカーノードを追加すると、コントロール プレーン ノードのサイズが増加します。

  • --enable-control-plane-v2: コントロール プレーン V2 を有効にする場合は、--enable-control-plane-v2 を指定します。コントロール プレーン V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンは、ユーザー クラスタ自体の 1 つ以上のノードで実行されます。デフォルトでは、ユーザー クラスタのコントロール プレーンは、管理クラスタの 1 つ以上のノードで実行されます（kubeception モデルと呼ばれます）。コントロール プレーン V2 が有効になっている場合、--cpus と --memory の値はユーザー クラスタ内のコントロール プレーン ノードに適用されます。ノード数は、--control-plane-ip-block に入力する IP アドレスの数によって決まります。コントロール プレーン V2 が有効になっていない場合、--cpus、--memory、--replicas の値は管理クラスタ内のコントロール プレーン ノードに適用されます。管理クラスタに十分な IP アドレスを確保するようにしてください。

    コントロール プレーン V2 を有効にする場合は、次のフラグも指定する必要があります。

    • --dns-servers=DNS_SERVER_1,...: VM の DNS サーバーの IP アドレスのカンマ区切りのリスト。

    • --ntp-servers=NTP_SERVER_1,...: VM が使用する時刻サーバーの IP アドレスのカンマ区切りのリスト。

    • --control-plane-ip-block の形式は次のとおりです。

      --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'

      この値には、gateway、netmask、ips というキーワードで始まるセグメントがあります。セグメントはカンマで区切ります。

      次の点にご注意ください。

      • 値全体を単一引用符で囲みます。
      • 空白文字は、IP アドレスとホスト名の間を除き、使用できません。

      IP アドレスのリスト内:

      • 個々の IP アドレスまたは IP アドレスの CIDR ブロックを指定できます。

      • 各 IP アドレスまたは CIDR ブロックはセミコロンで区切ります。

      • 個々の IP アドレスについては、必要に応じて、IP アドレスの後にホスト名を指定できます。IP アドレスとホスト名はスペースで区切ります。

      • CIDR ブロックを指定する場合は、ホスト名の値を指定しないでください。

      例:

      --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`

    • 省略可: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: ホストが使用する DNS 検索ドメインのカンマ区切りのリスト。これらのドメインは、ドメイン検索リストの一部として使用されます。

      例:

      --dns-search-domains example.com,examplepetstore.com

フラグとその説明の完全なリストについては、gcloud CLI リファレンスをご覧ください。

vSphere のフラグ

必要に応じて、次のオプション フラグを指定します。

  • --disable-aag-config: このフラグを指定しない場合、VMware Distributed Resource Scheduler（DRS）の反アフィニティ ルールがユーザー クラスタのノードに対して自動的に作成され、ノードはデータセンター内の少なくとも 3 つの物理ホストに分散されます。vSphere 環境が、要件を満たしていることを確認します。クラスタが要件を満たしていない場合は、このフラグを指定します。

  • --disable-vsphere-csi: このフラグを指定しない場合、vSphere Container Storage Interface（CSI）コンポーネントがユーザー クラスタにデプロイされます。CSI ドライバは、vSphere にデプロイされたネイティブの Kubernetes クラスタで実行されて、vSphere ストレージに永続ボリュームをプロビジョニングします。詳細については、vSphere Container Storage Interface ドライバの使用をご覧ください。CSI コンポーネントをデプロイしない場合は、このフラグを指定します。

フラグとその説明の完全なリストについては、gcloud CLI リファレンスをご覧ください。

gcloud コマンドを実行してクラスタを作成する前に、--validate-only を含めることで gcloud コマンドのフラグで指定された構成を検証できます。クラスタを作成する準備ができたら、このフラグを削除してコマンドを実行します。

このコマンドからの出力は、次のようになります。

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

この出力例では、operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 という文字列は長時間実行オペレーションの OPERATION_ID です。オペレーションのステータスは、次のコマンドで確認できます。

gcloud container vmware operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

詳細については、gcloud container vmware operations をご覧ください。

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

ノードプールを作成

クラスタを作成したら、ワークロードをデプロイする前に、少なくとも 1 つのノードプールを作成する必要があります。

gcloud container vmware node-pools create NODE_POOL_NAME \
--cluster=USER_CLUSTER_NAME  \
--project=FLEET_HOST_PROJECT_ID \
--location=REGION \
--image-type=IMAGE_TYPE  \
--boot-disk-size=BOOT_DISK_SIZE \
--cpus=vCPUS \
--memory=MEMORY \
--replicas=NODES \
--enable-load-balancer

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

  • NODE_POOL_NAME: ノードプールに付ける名前。名前は次の条件を満たしている必要があります。

    • 最大文字数は 40 文字とする
    • 小文字の英数字またはハイフン（-）のみを使用している
    • 先頭が英字である
    • 末尾が英数字である

  • USER_CLUSTER_NAME: 新しく作成されるユーザー クラスタの名前。

  • FLEET_HOST_PROJECT_ID: クラスタが登録されているプロジェクトの ID。

  • REGION: クラスタの作成時に指定した Google Cloud のロケーション。

  • IMAGE_TYPE: ノードプール内の VM で実行する OS イメージのタイプ。ubuntu_containerd または cos のいずれかに設定します。

  • BOOT_DISK_SIZE: プール内の各ノードのブートディスクのサイズ（ギビバイト（GiB）単位）。最小値は 40 GiB です。

  • vCPUs: ノードプール内の各ノードの vCPU 数。最小値は 4 です。

  • MEMORY: プール内の各ノードのメモリサイズ（メビバイト（MiB）単位）。最小値は、ユーザー クラスタ ワーカーノードあたり 8,192 MiB で、値は 4 の倍数でなければなりません。

  • NODES: ノードプール内のノード数。最小値は 3 です。

  • MetalLB をロードバランサとして使用している場合、プール内のノードで MetalLB スピーカーを実行できるようにする場合は、必要に応じて --enable-load-balancer を指定します。MetalLB は少なくとも 1 つのノードプールで有効にする必要があります。このフラグを指定しない場合は、MetalLB に使用する別のノードプールを作成する必要があります。

オプションのフラグについては、ノードプールの追加と gcloud CLI リファレンスをご覧ください。

Terraform

次の基本的な構成サンプルを使用して、バンドル型 MetalLB ロードバランサと 1 つのノードプールでユーザー クラスタを作成できます。

詳細とその他の例については、google_gkeonprem_vmware_cluster リファレンス ドキュメントをご覧ください。

  1. anthos-samples リポジトリのクローンを作成し、Terraform サンプルがあるディレクトリに変更します。

    git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/avmw_user_cluster_metallb

変数を terraform.tfvars に設定する

このサンプルは、main.tf に渡される変数ファイルの例を与えます。バンドル型 MetalLB ロードバランサを構成して、指定した DHCP サーバーから、クラスタノードが IP アドレスを取得できるようにする方法が示されます。

  1. terraform.tfvars.sample ファイルのコピーを作成します。

    cp terraform.tfvars.sample terraform.tfvars

  2. terraform.tfvars でパラメータ値を変更します。

    project_id                  = "FLEET_HOST_PROJECT_ID"
region                      = "REGION"
admin_cluster_name          = "ADMIN_CLUSTER_NAME"
on_prem_version             = "VERSION"
admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name                = "avmw-user-cluster-metallb"
control_plane_node_cpus     = 4
control_plane_node_memory   = 8192
control_plane_node_replicas = 3
control_plane_vip           = "CONTROL_PLANE_VIP"
ingress_vip                 = "INGRESS_VIP"
lb_address_pools            = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

    変数は次のリストのとおりです。

    • project_id: クラスタを作成するプロジェクトの ID。指定したプロジェクトは、フリート ホスト プロジェクトとしても使用されます。これは、管理クラスタが登録されているプロジェクトと同じでなければなりません。ユーザー クラスタを作成すると、選択したプロジェクトのフリートに自動的に登録されます。フリートホスト プロジェクトは、クラスタの作成後は変更できません。

    • region: GKE On-Prem API が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。

    • admin_cluster_name: ユーザー クラスタを管理する管理クラスタの名前。

    • on_prem_version: ユーザー クラスタの GKE on VMware のバージョン。通常は、管理クラスタと同じバージョンを指定します。より新しいバージョンを指定するには、管理クラスタのバージョンよりも新しいバージョンをインストールします。管理クラスタのバージョンがわからない場合は、gcloud container vmware clusters query-version-config を実行します。これは [管理クラスタのバージョンよりも新しいバージョンをインストールする] の最初のステップです。

    • admin_user_emails: クラスタに対する管理者権限を付与するユーザーのメールアドレスのリスト。自分でクラスタを管理する場合は、必ず自分のメールアドレスを追加してください。

      クラスタが作成されると、GKE On-Prem API によって Kubernetes のロールベース アクセス制御（RBAC）ポリシーがクラスタに適用され、管理者ユーザーに Kubernetes の clusterrole/cluster-admin ロールが付与されます。このロールにより、すべての名前空間で、クラスタのすべてのリソースに対する完全アクセス権が付与されます。また、ユーザーは Google の ID を使用してコンソールにログインできます。

    • cluster_name: ユーザー クラスタの任意の名前。この名前はクラスタの作成後は変更できません。名前は次の条件を満たしている必要があります。

      • 最大文字数は 40 文字とする
      • 小文字の英数字またはハイフン（-）のみを使用している
      • 先頭が英字である
      • 末尾が英数字である

    • control_plane_node_cpus: ユーザー クラスタの各コントロール プレーンノードの vCPU 数。最小値は 4 vCPU です。

    • control_plane_node_memory: ユーザー クラスタの各コントロール プレーンのメモリサイズ（メビバイト（MiB）単位）。最小値は 8192 で、4 の倍数でなければなりません。

    • control_plane_node_replicas: ユーザー クラスタのコントロール プレーン ノードの数。たとえば、開発環境用に 1 つのコントロール プレーン ノード、高可用性（HA）環境と本番環境用に 3 つのコントロール プレーン ノードを入力できます。

    • control_plane_vip: ユーザー クラスタの Kubernetes API サーバー用ロードバランサに構成するよう選択した仮想 IP アドレス（VIP）。

    • ingress_vip: Ingress プロキシ用のロードバランサ上に構成するために選択した IP アドレス。

    • lb_address_pools: MetalLB ロードバランサで使用するアドレスプールを定義するマップのリスト。Ingress VIP をプールの 1 つに含める必要があります。以下を指定します。

      • name: プールの名前。
      • addresses: CIDR 表記またはハイフン付き範囲形式のアドレス範囲。プール内の単一の IP アドレス（Ingress VIP など）を指定するには、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

      サンプルの IP アドレスを実際の値に置き換え、必要に応じて追加のアドレスプールを追加します。

  3. 変更を terraform.tfvars に保存します。main.tf にオプションの変更を加えない場合は、その次のクラスタと 1 つのノードプールを作成するセクションに進みます。

省略可: main.tf でクラスタ設定を構成する

このセクションでは、main.tf で可能なオプションの構成変更について説明します。変更を行う前に、main.tf のバックアップを作成します。

cp main.tf main.tf.bak

ワーカーノードの IP アドレスモード

デフォルトでは、main.tf はクラスタの構成で、ワーカーノードへの IP アドレスの割り当てに指定した DHCP サーバーを使用するように構成されます。DHCP の構成を行うには、network_config ブロック内に dhcp_config マップを含めます。ワーカーノードに静的 IP アドレスを提供する場合は、main.tf を次のように変更します。

  1. network_config ブロックを置き換え、static_ip_config ブロックを含めます。例:

    network_config {
  service_address_cidr_blocks = ["10.96.0.0/12"]
  pod_address_cidr_blocks = ["192.168.0.0/16"]
  host_config {
    dns_servers = ["10.254.41.1"]
    ntp_servers = ["216.239.35.8"]
  }
  static_ip_config {
    ip_blocks {
      netmask = "255.255.252.0"
      gateway = "10.251.31.254"
      ips {
        ip = "10.251.30.153"
        hostname = "vm-1"
      }
      ips {
        ip = "10.251.31.206"
        hostname = "vm-2"
      }
      ips {
        ip = "10.251.31.193"
        hostname = "vm-3"
      }
      ips {
        ip = "10.251.30.230"
        hostname = "vm-4"
      }
    }
  }
}

  2. 以下を実際の値に置き換えます。

    • service_address_cidr_blocks: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。/24 以上の範囲を指定してください。

    • pod_address_cidr_blocks: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。/18 以上の範囲を指定してください。

    • dns_servers: VM の DNS サーバーの IP アドレスのリスト。

    • ntp_servers: VM が使用する時刻サーバーの IP アドレスのリスト。

    • static_ip_config ブロックで、netmask と gateway の値をネットワークのアドレスに置き換えます。ip と hostname をワーカーノードの IP アドレスとホスト名に置き換えます。

コントロール プレーン V2 を構成する

デフォルトでは、main.tf は、管理クラスタの 1 つ以上のノードで実行されるようにユーザー クラスタのコントロール プレーンを構成します（kubeception モデルと呼ばれます）。必要に応じて、コントロール プレーン V2 を有効にできます。コントロール プレーン V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンは、ユーザー クラスタ自体の 1 つ以上のノードで実行されます。コントロール プレーン V2 を構成するには、main.tf に次の変更を加えます。

  1. admin_cluster_membership の行の後に、次の行を追加します。

    enable_control_plane_v2 = "true"

  2. network_config ブロックに control_plane_v2_config マップを追加します。次に例を示します。

    control_plane_v2_config {
  control_plane_ip_block {
    netmask = "255.255.252.0"
    gateway = "10.250.71.254"
    ips {
      ip = "10.250.68.54"
      hostname = "cpv2-vm1"
    }
    ips {
      ip = "10.250.68.128"
      hostname = "cpv2-vm2"
    }
    ips {
      ip = "10.250.71.50"
      hostname = "cpv2-vm3"
    }
  }
}

  3. netmask と gateway の値をネットワークの IP アドレスに置き換えます。ip と hostname をコントロール プレーン ノードの IP アドレスに置き換えます。

クラスタと 1 つのノードプールを作成する

  1. Terraform を初期化し、Terraform プランを作成します。

    terraform init

    Terraform によって、Google Cloud プロバイダなどの必要なライブラリがインストールされます。

  2. 構成を確認し、必要に応じて変更を加えます。

    terraform plan

  3. Terraform プランを適用して、ユーザー クラスタを作成します。

    terraform apply

    ユーザー クラスタの作成には約 15 分以上かかり、ノードプールの作成にさらに 15 分かかります。クラスタは、Google Cloud コンソールの Anthos clusters ページで確認できます。

ユーザー クラスタに接続する

GKE On-Prem API クライアントを使用してユーザー クラスタを作成する場合、Google Cloud アカウントのメールアドレスを指定して、自分自身と他のユーザーをクラスタ管理者として追加するオプションがあります。

  • コンソールで [クラスタの基本] ページの [承認] セクションに自分のメールアドレスが自動的に追加され、他のクラスタ管理者ユーザーを追加するオプションもあります。

  • gcloud CLI で、--admin-users フラグを自分のメールアドレスに設定します。このフラグではリストは許可されません。各クラスタ管理者ユーザー用に --admin-users フラグを追加します。

  • Terraform のサンプルでは、terraform.tvars.sample ファイルの admin_user_emails 変数で自分自身と他の管理者ユーザーを指定できます。

クラスタは Kubernetes ロールベース アクセス制御（RBAC）ポリシーで構成されており、管理者ユーザーは cluster-admin ロールを付与され、Google Cloud ID を使用してコンソールからクラスタにログインできます。詳細については、Google ID 認証の設定をご覧ください。

すべてのクラスタには正規のエンドポイントがあります。このエンドポイントは、kubectl や他のサービスと TCP ポート 443 経由でクラスタ コントロール プレーンと通信するために使用する Kubernetes API サーバーを公開します。このエンドポイントには、公共のインターネットからはアクセスできません。VPC を介してクラスタのプライベート エンドポイントにアクセスできる場合は、プライベート エンドポイントに直接接続して kubeconfig ファイルを直接生成できます。そうでない場合は、Connect ゲートウェイを使用できます。この場合、kubectl により、Connect はコネクトを使用し、ユーザーの代わりに、トラフィックをプライベート エンドポイントに安全に転送します。

コマンドラインからユーザー クラスタにアクセスするには、kubeconfig ファイルが必要です。kubeconfig ファイルを取得するには、2 つの方法があります。

  • Connect ゲートウェイを使用して、Google Cloud CLI がインストールされているコンピュータからクラスタにアクセスします。Connect ゲートウェイを使用すると、クラスタを簡単かつ安全に管理できます。詳細については、Connect Gateway を使用して登録済みクラスタに接続するをご覧ください。

  • プライベート エンドポイントに直接アクセスするために、管理ワークステーションで kubeconfig ファイルを作成し、管理ワークステーションからクラスタを管理します。

コンソールにユーザー クラスタのステータスが正常と表示されるまで待ちます。

Connect ゲートウェイ

  1. フリートホスト プロジェクトで使用する gcloud CLI を初期化するか、次のコマンドを実行して Google アカウントでログインし、フリートホスト プロジェクトをデフォルトに設定して、コンポーネントを更新します。

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Connect ゲートウェイとのやり取りに使用するクラスタ認証情報を取得します。次のコマンドでは、MEMBERSHIP_NAME をクラスタの名前に置き換えます。GKE on VMware では、メンバーシップ名はクラスタ名と同じです。

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    このコマンドは、特別なConnect ゲートウェイ特有の kubeconfig を返します。これにより、ゲートウェイを介してクラスタに接続できます。

    必要な認証情報を取得したら、通常の Kubernetes クラスタの場合と同様に kubectl を使用してコマンドを実行できます。kubeconfig ファイルの名前を指定する必要はありません。次に例を示します。

    kubectl get namespaces

管理ワークステーション

管理ワークステーションでユーザー クラスタの kubeconfig ファイルを作成するには、次のコマンドを実行して、ユーザー クラスタ用の新しい kubeconfig ファイルをローカルに保存します。次のように置き換えます。

  • CLUSTER_NAME: 新しく作成したユーザー クラスタの名前
  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
  • USER_CLUSTER_KUBECONFIG: コマンドが出力するユーザー クラスタ kubeconfig ファイルの名前。
kubectl get secret admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  -n CLUSTER_NAME \
  -o=jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG

ファイルを保存したら、管理ワークステーションで kubectl を使用してユーザー クラスタへのアクセスを開始できます。次に例を示します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get namespaces

管理クラスタのバージョンより新しいバージョンをインストールする

管理クラスタは、異なるバージョンのユーザー クラスタを管理できます。管理クラスタよりも新しいバージョンのユーザー クラスタを作成する場合は、次のように、管理クラスタがそのバージョンのユーザー クラスタを管理するために必要なコンポーネントをダウンロードしてデプロイする必要があります。

  1. 利用可能なバージョンのリストを取得します。

    gcloud container vmware clusters query-version-config \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --location=REGION

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

    • ADMIN_CLUSTER_NAME: 管理クラスタの名前。

    • FLEET_HOST_PROJECT_ID: 管理クラスタが登録されているプロジェクトの ID。

    • REGION: GKE On-Prem API が実行される Google Cloud リージョン。これは、ユーザー クラスタを作成するときに指定するリージョンです。us-west1 または別のサポートされているリージョンを指定します。

    コマンドの出力は、次のようになります。

    versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581

    管理クラスタにインストールされているバージョンには、isInstalled=true というアノテーションが付けられます。

  2. まだ行っていない場合は、GKE On-Prem API に管理クラスタを登録します。クラスタが GKE On-Prem API に登録された後は、この手順を繰り返す必要はありません。

  3. 新しいバージョンのコンポーネントをダウンロードして、管理クラスタにデプロイします。

    gcloud beta vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

    このコマンドは、--required-platform-version で指定したバージョンのコンポーネントを管理クラスタにダウンロードし、そのコンポーネントをデプロイします。これで、指定したバージョンでユーザー クラスタを作成できるようになりました。

次のステップ