Google Cloud コンソールでユーザー クラスタを作成する

Version 1.12 

• 最新バージョン
• バージョン 1.16
• 以前のバージョン（サポート対象外）

このページでは、Google Cloud コンソールを使用して Anthos clusters on VMware（GKE On-Prem）ユーザー クラスタを作成する方法について説明します。ユーザー クラスタを作成すると、クラスタの作成用に選択した Google Cloud プロジェクトで Anthos On-Prem API が自動的に有効になります。Anthos On-Prem API は Google Cloud のインフラストラクチャで動作し、コンソールはこの API を使用して vSphere データセンターにクラスタを作成します。クラスタを管理するため、Anthos On-Prem API は、クラスタの作成時に指定した Google Cloud リージョンに、クラスタの状態に関するメタデータを保存する必要があります。このメタデータにより、Anthos On-Prem API は、ユーザー クラスタのライフサイクルを管理できますが、ワークロード固有のデータは含まれません。

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

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

始める前に

このセクションでは、Google Cloud コンソールでユーザー クラスタを作成するための要件について説明します。

IAM 権限を付与する

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

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

• roles/container.viewer
• roles/gkehub.viewer

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

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

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

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

管理クラスタを登録する

Google Cloud コンソールでユーザー クラスタを作成するにあたり、管理クラスタがフリートに登録されている必要があります。

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

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

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

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

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

• 既存の管理クラスタを更新するには、管理クラスタの Cloud Audit Logs へのロギングを有効または無効にするをご覧ください。

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

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

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

• 既存の管理クラスタを更新するには、管理クラスタのロギングとモニタリングを有効または無効にするをご覧ください。

必要な Google API

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

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

gcloud services enable --project=FLEET_HOST_PROJECT_ID  \
    connectgateway.googleapis.com

コマンドライン アクセス

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

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

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

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

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

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

1. Google Cloud コンソールで、Anthos の [クラスタ] ページに移動します。

   [Anthos クラスタ] ページに移動

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

3. [クラスタを作成] をクリックします。

4. ダイアログ ボックスで、[オンプレミス] をクリックします。

5. [VMware vSphere] の横にある [構成] をクリックします。

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

前提条件

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 リージョンを選択します。Anthos On-Prem API が実行されるリージョンを制御するだけでなく、この設定では次の保存先リージョンを制御します。

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

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

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

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

   注: プロジェクト オーナー以外のユーザーには、Kubernetes RBAC ポリシーに加え、いくつかの Identity and Access Management（IAM）ロールを付与する必要があります。IAM ロールを付与する方法について詳しくは、必要なロールを付与するをご覧ください。

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 アドレスを入力する場合は、必要に応じてホスト名を入力できます。ホスト名を入力しないと、Anthos clusters 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 モード] を選択した場合は、[ホスト構成] セクションで次の情報を指定します。

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

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

ロードバランサ

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

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

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 のインストールと構成は、Anthos clusters on VMware と統合する前に行います。詳細については、F5 BIG-IP ADC インストール ガイドをご覧ください。

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

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

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

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

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

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

5. [次へ] をクリックします。

手動ロードバランサ

手動ロード バランシングを構成します。Anthos clusters 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. [コントロール プレーンのノード vCPU] フィールドに、ユーザー クラスタのコントロール プレーンとして機能する各管理クラスタノードの vCPU の数（4 以上）を入力します。
2. コントロール プレーン ノード メモリフィールドに、ユーザー クラスタのコントロール プレーンとして機能する各管理クラスタノードのメモリサイズ（MiB で最小 8192、4 の倍数）を入力します。

3. [コントロール プレーン ノード] で、ユーザー クラスタのコントロール プレーン ノードの数を選択します。たとえば、開発環境用に 1 つのコントロール プレーン ノード、高可用性（HA）環境と本番環境用に 3 つのコントロール プレーン ノードを選択できます。ユーザー コントロール プレーンは管理クラスタノードに存在するため、各コントロール プレーン ノードに十分な IP アドレスを確保します。詳細については、管理クラスタに必要な IP アドレス数をご覧ください。

4. [続行] をクリックして [機能] セクションに移動します。

機能

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

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

• システム サービスの Cloud Logging
• システム サービスの Cloud Monitoring
• 管理アクティビティ監査ログ

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

• vSphere CSI ドライバを有効にする: vSphere Container Storage プラグインとも呼ばれます。Container Storage Interface（CSI）ドライバは、vSphere にデプロイされたネイティブの Kubernetes クラスタで実行されて、vSphere ストレージに永続ボリュームをプロビジョニングします。詳細については、vSphere Container Storage Interface ドライバの使用をご覧ください。

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

  注: 最小限のインフラストラクチャを設定するに準拠している場合、ESXi ホストは 1 つのみであるため、反アフィニティ グループを有効にするをオフにしてください。

ノードプール

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

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

   1. [ノードプール名] を入力するか、名前として「default-pool」を使用します。
   2. プール内の各ノードの vCPU の数（ユーザー クラスタ ワーカーあたりの最小値は 4）を入力します。
   3. プール内の各ノードのメモリサイズをメガバイト（MiB）単位で入力します（ユーザー クラスタのワーカーノードあたり最小 8192 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 の [キー]、[値]、[効果] を入力します。以上の手順を必要なだけ繰り返してください。

確認して完了する

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

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

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

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

コンソールでユーザー クラスタを作成すると、クラスタは Kubernetes のロールベースのアクセス制御（RBAC）ポリシーで構成され、Google Cloud ID を使用してクラスタにログインできます。他のオペレーターが Google Cloud ID を使用してログインできるようにクラスタとプロジェクトを構成するには、Connect ゲートウェイの設定をご覧ください。

すべてのクラスタには正規のエンドポイントがあります。 このエンドポイントは、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 FLEET_HOST_PROJECT_ID
   gcloud components update
   

2. Connect ゲートウェイとのやり取りに使用するクラスタ認証情報を取得します。次のコマンドでは、MEMBERSHIP_NAME をクラスタの名前に置き換えます。Anthos clusters 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

次のステップ

• アプリケーションをデプロイする
• Cloud コンソールでユーザー クラスタを作成する際の問題のトラブルシューティング