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 プロジェクトを指定します。クラスタが作成されると、指定したプロジェクトのフリートに自動的に登録されます。このプロジェクトはフリート ホスト プロジェクトと呼ばれます。クラスタの作成後にフリート ホスト プロジェクトを変更することはできません。

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

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

始める前に

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

IAM 権限を付与する

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

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

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

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

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

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

必要な Google API

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

gcloud CLI を使用してクラスタを作成する場合は、GKE On-Prem API を有効にする必要があります。コンソールを使用してクラスタを作成すると、GKE On-Prem API は自動で有効になります。

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

管理クラスタの前提条件

ユーザー クラスタを作成するには、動作中の管理クラスタが必要です。管理クラスタは次の要件を満たしている必要があります。

  • ユーザー クラスタの作成後に、ユーザー クラスタ上の Kubernetes API サーバーにアクセスできること。

  • ユーザー クラスタの作成後に、ユーザー クラスタ上のすべてのノードに接続できること。

  • フリートに登録していること。管理クラスタの gkeConnect.projectID フィールドで構成されているプロジェクト ID（フリートホスト プロジェクトと呼ばれます）は、ユーザー クラスタを作成するプロジェクトと同じである必要があります。

クラスタノード マシンの前提条件

クラスタノード マシンの前提条件を確認し、ユーザー クラスタを実行するマシンが前提条件を満たしていることを確認します。

コマンドライン アクセス

クラスタを作成した後、Connect Gateway を使用して管理ワークステーション以外のコンピュータ上のユーザー クラスタに対して kubectl を実行する場合は、使用するコンピュータに次のコマンドライン ツールをインストールします。

  • 最新バージョンの gcloud CLI。
  • kubectl。Kubernetes クラスタにコマンドを実行するために使用します。kubectl をインストールする必要がある場合は、こちらの説明に従ってインストールしてください。

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

Terraform、 Google Cloud コンソール、または Google Cloud CLI（gcloud CLI）を使用して、GKE On-Prem API で管理されるクラスタを作成できます。Google Distributed Cloud を初めてインストールする場合は、コンソールが使用しやすくておすすめです。

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

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

コンソール

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

  1. コンソールで、[Create a bare metal cluster] ページに移動します。

    [Create a bare metal cluster] に移動

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

  3. [次へ] をクリックしてクラスタの構成を開始します。

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

クラスタの基本

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

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

  2. [管理クラスタ] で、リストから管理クラスタを選択します。

  3. [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でクラスタが一意に識別されます。

  4. ユーザー クラスタのバージョンを選択します。ユーザー クラスタは、管理クラスタと同じマイナー バージョンか、管理クラスタより 1 つ低いマイナー バージョンである必要があります。

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

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

  6. [ノード構成] セクションで、次のように指定します。

    • ノードあたりの最大 Pod 数: 単一ノードで実行できる Pod の最大数を入力します。使用できる値は、32～250 です。Kubernetes は、各 Pod に一意の IP アドレスが指定されるように、クラスレス ドメイン間ルーティング（CIDR）ブロックを各ノードに割り当てます。CIDR ブロックのサイズは、ノードあたりの最大 Pod 数に対応します。ノードあたりの最大 Pod 数の設定の詳細については、Pod ネットワーキングをご覧ください。

    • コンテナ ランタイム: クラスタで使用できるコンテナ ランタイムは containerd のみです。

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

ネットワーキング

このセクションでは、クラスタのノード、Pod、Service の IP アドレスを指定します。Metal LB によるバンドルされたロード バランシングを使用している場合は、それも構成します。

  1. [コントロール プレーン] ノード セクションで、各コントロール プレーン ノードの IPv4 アドレスを入力します。コントロール プレーン ノードはシステム ワークロードを実行します。通常は、マシン 1 台（最小デプロイメントを使用している場合）とマシン 3 台（高可用性デプロイメントを使用している場合）のいずれかです。HA 用に過半数のクォーラムが確保できるように、ノード数を奇数で指定します。このフィールドは、クラスタを更新またはアップグレードするたびに変更できます。

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

  2. [ロードバランサ] セクションで、[モード] リストからロードバランサを選択して、クラスタに設定します。詳細については、ロードバランサの概要をご覧ください。

    MetalLB にバンドル済み

    バンドル型 MetalLB ロードバランサを使用してロード バランシングを構成します。このオプションにより、Google Distributed Cloud は、ワーカーノードの専用プールまたはコントロール プレーンと同じノードで実行されるレイヤ 4 ロードバランサをデプロイします。

    1. [ロードバランサ ノードプール] セクションで、次のいずれかを選択します。

      • コントロール プレーン ノードを使用する: このオプションを選択すると、コントロール プレーンと同じノードでロードバランサを実行できます。

      • ロードバランサ ノードプールを作成する: ワーカーノードの専用プールでロードバランサを実行する必要がある場合は、この詳細オプションを選択します。ロードバランサ ノードプール内のすべてのノードは、ロードバランサのアドレスプール セクションに構成するロードバランサの仮想 IP（VIP）と同じレイヤ 2 サブネット内に存在する必要があります。

        1. [ロードバランサ ノードプールの IP 1] フィールドに、ロードバランサ ノードプール内のノード用の IPv4 アドレスを入力します。

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

    2. [ロードバランサのアドレスプール] セクションで、選択肢とする MetaLB コントローラ用の 1 つ以上のアドレスプールを追加して、LoadBalancer タイプの Service に割り当てます。仮想 IP セクションで指定する Ingress VIP は、これらのプールのいずれかに存在する必要があります。

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

      2. 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. Ingress VIP がアドレス範囲にない場合は、[+ IP アドレス範囲を追加] を選択し、Ingress VIP を含む別のアドレス範囲を入力します。

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

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

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

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

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

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

    手動ロードバランサ

    手動ロード バランシングでは、コントロール プレーンとデータプレーンのトラフィックを対象とした独自のロード バランシング ソリューションを構成します。クラスタを作成する前に、外部ロードバランサでコントロール プレーン VIP を構成する必要があります。コントロール プレーンの外部ロードバランサはデータプレーンのトラフィックにも使用できます。また、データプレーン用に別のロードバランサを設定することもできます。詳細については、手動のロード バランシングを構成するをご覧ください。

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

    • コントロール プレーン VIP: ユーザー クラスタの Kubernetes API サーバーに送信されるトラフィックに使用する宛先 IP アドレス。コントロール プレーンの VIP は、ロードバランサ ノードと同じサブネット内に存在する必要があり、ロードバランサのアドレスプールに使用されるアドレス範囲に含めることはできません。

    • ポート: Kubernetes API サーバーに送信されるトラフィックに使用される宛先ポート。デフォルトは 443 です。

    • Ingress VIP: Ingress プロキシ用のロードバランサに構成する IP アドレス。ロードバランサのアドレスプールのいずれかに由来するアドレスを入力します。

  4. [Service と Pod CIDR] セクションで、Kubernetes Service と Pod の IP アドレス範囲を CIDR 表記で指定します。これらを互いに重複させたり、クラスタ内部からアクセスするクラスタ外のアドレスと重複させたりすることはできません。RFC 1918 で定義されているプライベート IP アドレス範囲を使用することをおすすめします。コンソールにはデフォルトのアドレス範囲が用意されていますが、変更できます。

    • サービス CIDR: 10.96.0.0/20デフォルトをそのまま使用しない場合は、/24 から /12 までの CIDR の範囲を入力します（/12 の場合に IP アドレスが最多になります）。

    • Pod CIDR: 192.168.0.0/16: デフォルトをそのまま使用しない場合は、/18 から /8 までの CIDR の範囲を入力します（/8 の場合に IP アドレスが最多になります）。

  5. [詳細属性] セクションで、必要に応じて次のように指定します。

    • プロキシの URL: プロキシ サーバーの HTTP アドレス。スキームのデフォルト ポートと同じ場合でも、ポート番号を含めます。例: http://my-proxy.example.local:80

    • URL: プロキシ サーバーを経由しない IP アドレス、IP アドレス範囲、ホスト名、ドメイン名のカンマ区切りのリスト。Google Distributed Cloud がこれらのアドレス、ホスト、ドメインのいずれかにリクエストを送信する場合、そのリクエストは直接送信されます。

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

ストレージ

Google Distributed Cloud（ソフトウェアのみ）には、ブロック ストレージとファイル ストレージのインターフェースが用意されています。デフォルトのオプションがありますが、構成をカスタマイズすることもできます。詳細については、ローカル ストレージを構成するをご覧ください。

  1. 必要に応じて、次のものを構成できます。

    • ローカル ボリューム プロビジョナーのノードマウント: マウントされたディスクを基盤とするローカル PersistentVolumes（PV）の構成を指定します。これらのディスクは、クラスタの作成前または作成後にフォーマットしてマウントする必要があります。

    • ローカル ボリューム プロビジョナーの共有: 共有ファイル システムのサブディレクトリで使用するローカル PersistentVolumes の構成を指定します。これらのサブディレクトリは、クラスタの作成時に自動的に作成されます。

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

機能

クラスタのモニタリング、トラブルシューティング、運用に役立つよう、以下は自動的に有効になり、無効にすることはできません。

コンソールでノードプールを作成する

クラスタには、ワーカーノード用のノードプールが少なくとも 1 つ必要です。ノードプールは、このクラスタで作成されるワーカーノードのグループのテンプレートです。

コンソールで、少なくとも 1 つのノードプールを構成するか（またはデフォルト値をそのまま使用）、クラスタを作成します。クラスタの作成後に、ノードプールを追加できます。gcloud CLI では、まずクラスタを作成してから、新しく作成したクラスタに 1 つ以上のノードプールを追加します。

  1. 左側のナビゲーション バーで [デフォルト プール] をクリックします。

  2. [ノードプールのデフォルト] セクションで、ノードプール名を入力するか、「default-pool」を名前としてそのまま使用します。

  3. [ワーカーノード] セクションで、クラスタが実行されるマシンの IP アドレスを入力します。

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

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

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

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

gcloud CLI

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

gcloud container bare-metal clusters create

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

gcloud container bare-metal node-pools create

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

始める前に

ユーザー クラスタの作成時に選択するバージョンは、管理クラスタがサポートしているバージョンである必要があります。さらに、最新のマイナー バージョンまたはパッチ バージョンは、リリースから 7～14 日後まで GKE On-Prem API では使用できません。gcloud コマンドを実行して、インストール可能なサポート対象のクラスタ バージョンのリストを取得できます。

  1. コンポーネントを更新していることを確認します。

    gcloud components update

  2. 管理クラスタの名前とフリート メンバーシップのロケーションを確認します。

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    FLEET_HOST_PROJECT_ID は、管理クラスタが登録されているプロジェクトの ID に置き換えます。

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

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    LOCATION には、フリート サービスと接続サービスが実行されるロケーションが表示されます。1.28 より前で作成された管理クラスタは、グローバルの Fleet サービスと Connect サービスによって管理されます。1.28 以降では、管理クラスタの作成時に global または Google Cloud リージョンのいずれかを指定できます。次の例のコマンドでは、--admin-cluster-membership-location フラグにリージョンを指定します。

  3. ユーザー クラスタにインストールする利用可能なバージョンのリストを取得します。

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

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

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

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

    • ADMIN_CLUSTER_REGION: 管理クラスタのフリート メンバーシップのリージョン。これは、global または Google Cloudリージョンのいずれかです。gcloud container fleet memberships list の出力にある管理クラスタのロケーションを使用します。

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

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

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

最新のバグの修正と改善点を適用するため、サポートされている最も高いバージョンを使用することをおすすめします。

例

このセクションでは、MetalLB ロードバランサを使用してクラスタを作成するコマンドの例と、手動ロードバランサを使用する例を示します。指定する情報は、使用するロードバランサのタイプによって異なります。詳細については、ロードバランサの概要をご覧ください。

これらの例では、ノードプールのないクラスタを作成します。クラスタの稼働後、ワークロードをデプロイする前にノードプールを追加する必要があります。

MetalLB

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

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

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

  • 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）、Fleet サービス（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: ユーザー クラスタの Google Distributed Cloud のバージョン。
  • 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 ロールが付与されます。このロールにより、すべての Namespace で、クラスタのすべてのリソースに対する完全アクセス権が付与されます。

MetalLB アドレスプール

  • --metal-lb-address-pools: MetalLB ロードバランサで使用するアドレスプールの構成を指定します。フラグの値の形式は次のとおりです。
'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 を作成し、プールからアドレスのいずれかを手動で指定します。指定しない場合、manual-assign は False に設定されます。

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

以下の構文ルールに注意してください。

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

次の例に示すように、複数のフラグのインスタンスを指定できます。

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

MetalLB ノード

  • 省略可: --metal-lb-load-balancer-node-configs: ロードバランサはデフォルトで、コントロール プレーンと同じノードで実行されます。ワーカーノードの専用プールでロードバランサを実行する必要がある場合は、ノードごとにこのフラグを指定します。ロードバランサ ノードプール内のすべてのノードは、ロードバランサの仮想 IP（VIP）と同じレイヤ 2 サブネット内に存在する必要があります。

    フラグの値の形式は次のとおりです。

    'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \

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

    • node-ip: ロードバランサ ノードプール内のノードの IP アドレス。フラグごとに 1 つの node-ip しか指定できません。複数のノードを指定する必要がある場合は、ノードごとにフラグを指定し直してください。

    • labels: ノードに付加される 1 つ以上の Key-Value ペア。

    以下の構文ルールに注意してください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は使用できません。
    • labels セグメントの各 Key-Value ペアをセミコロンで区切ります。

    --metal-lb-load-balancer-node-configs を指定する場合、必要に応じて次のフラグを含めるできます。

    • --metal-lb-load-balancer-node-labels: このフラグを使用して、ロードバランサ ノードプール内のすべてのノードにラベルを追加します。Key-Value ペアのリストをカンマで区切ります。

      --metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

    • --metal-lb-load-balancer-node-taints: このフラグを使用して、ロードバランサ ノードプール内のすべてのノードにタグを追加します。各 taint は、効果に関連付けられた Key-Value ペアです。PreferNoSchedule、NoSchedule、NoExecute のいずれかにする必要があります。

      --metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2

    次の例では、ロードバランサ ノードプールに 3 つのノードを追加します。すべてのノードに lb-pool-key=lb-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。

    --metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \

コントロール プレーン ノード

  • --control-plane-node-configs: コントロール プレーン ノードの IPv4 アドレス。コントロール プレーン ノードはシステム ワークロードを実行します。コントロール プレーン ノードごとにこのフラグを指定します。通常は、マシン 1 台（最小デプロイメントを使用する場合）とマシン 3 台（高可用性（HA）デプロイメントを使用する場合）のいずれかです。HA 用に過半数のクォーラムが確保できるように、ノード数を奇数で指定します。これらのアドレスは、クラスタを更新またはアップグレードするたびに変更できます。

    フラグの値の形式は次のとおりです。

      'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

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

  • node-ip:　コントロール プレーン ノードの IP アドレス。フラグごとに 1 つの node-ip しか指定できません。複数のノードを指定する必要がある場合は、ノードごとにフラグを指定し直してください。
  • labels: ノードに付加される 1 つ以上の Key-Value ペア。

    以下の構文ルールに注意してください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は使用できません。
    • labels セグメントの各 Key-Value ペアをセミコロンで区切ります。

    必要に応じて、次のフラグを含めます。

  • --control-plane-node-labels: このフラグを使用して、すべてのコントロール プレーン ノードにラベルを追加します。Key-Value ペアのリストをカンマで区切ります。
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: このフラグを使用して、すべてのコントロール プレーン ノードに taints を追加します。各 taint は、効果に関連付けられた Key-Value ペアです。PreferNoSchedule、NoSchedule、NoExecute のいずれかにする必要があります。

    次の例では、3 つのノードをコントロール プレーン ノードに追加します。すべてのノードに cp-node-pool-key=cp-node-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。

      --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

仮想 IP

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

    例: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: ロードバランサが Kubernetes API サーバーに対応するポート。

    例: -control-plane-load-balancer-port=443

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

    例: --ingress-vip=10.251.134.80

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

Service CIDR と Pod CIDR

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。CIDR の範囲は /24～/12 にする必要があります（/12 の場合に IP アドレスが最多になります）。

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

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。CIDR の範囲は /18～/8 にする必要があります（/8 の場合に IP アドレスが最多になります）

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

ストレージ

  1. --lvp-share-path: サブディレクトリを作成できるホストマシンのパスです。サブディレクトリごとにローカル PV が作成されます。
  2. --lvp-share-storage-class: 永続ボリュームの作成に使用する StorageClass。StorageClass はクラスタの作成時に作成されます。
  3. --lvp-node-mounts-config-path: マウントされたディスクを検出できるホストマシンのパス。それぞれのマウントに対してローカル PersistentVolume（PV）が作成されます。
  4. --lvp-node-mounts-config-storage: クラスタの作成時に PV が作成されるストレージ クラス。

ストレージの詳細については、ローカル ストレージを構成するをご覧ください。

手動

手動ロード バランシングでは、コントロール プレーンとデータプレーンのトラフィックを対象とした独自のロード バランシング ソリューションを構成します。クラスタを作成する前に、外部ロードバランサでコントロール プレーン VIP を構成する必要があります。コントロール プレーンの外部ロードバランサはデータプレーンのトラフィックにも使用できます。また、データプレーン用に別のロードバランサを設定することもできます。詳細については、手動のロード バランシングを構成するをご覧ください。

--admin-cluster-membership フラグの ADMIN_CLUSTER_NAME プレースホルダを入力する必要がある場合は、必ずスクロールしてください。

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

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

  • 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）、Fleet サービス（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: ユーザー クラスタの Google Distributed Cloud のバージョン。
  • 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 ロールが付与されます。このロールにより、すべての Namespace で、クラスタのすべてのリソースに対する完全アクセス権が付与されます。

コントロール プレーン ノード

  • --control-plane-node-configs: コントロール プレーン ノードの IPv4 アドレス。コントロール プレーン ノードはシステム ワークロードを実行します。コントロール プレーン ノードごとにこのフラグを指定します。通常は、マシン 1 台（最小デプロイメントを使用する場合）とマシン 3 台（高可用性（HA）デプロイメントを使用する場合）のいずれかです。HA 用に過半数のクォーラムが確保できるように、ノード数を奇数で指定します。これらのアドレスは、クラスタを更新またはアップグレードするたびに変更できます。

    フラグの値の形式は次のとおりです。

      'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

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

  • node-ip:　コントロール プレーン ノードの IP アドレス。フラグごとに 1 つの node-ip しか指定できません。複数のノードを指定する必要がある場合は、ノードごとにフラグを指定し直してください。
  • labels: ノードに付加される 1 つ以上の Key-Value ペア。

    以下の構文ルールに注意してください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は使用できません。
    • labels セグメントの各 Key-Value ペアをセミコロンで区切ります。

    必要に応じて、次のフラグを含めます。

  • --control-plane-node-labels: このフラグを使用して、すべてのコントロール プレーン ノードにラベルを追加します。Key-Value ペアのリストをカンマで区切ります。
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: このフラグを使用して、すべてのコントロール プレーン ノードに taints を追加します。各 taint は、効果に関連付けられた Key-Value ペアです。PreferNoSchedule、NoSchedule、NoExecute のいずれかにする必要があります。

    次の例では、3 つのノードをコントロール プレーン ノードに追加します。すべてのノードに cp-node-pool-key=cp-node-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。

      --control-plane-node-configs='node-ip=192.0.2.1' \
  --control-plane-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
  --control-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

仮想 IP

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

    例: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: ロードバランサが Kubernetes API サーバーに対応するポート。

    例: -control-plane-load-balancer-port=443

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

    例: --ingress-vip=10.251.134.80

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

Service CIDR と Pod CIDR

  • SERVICE_CIDR_BLOCK: クラスタ内の Service に使用される IP アドレスの範囲（CIDR 形式）。CIDR の範囲は /24～/12 にする必要があります（/12 の場合に IP アドレスが最多になります）。

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

  • POD_CIDR_BLOCK: クラスタ内の Pod に使用される IP アドレスの範囲（CIDR 形式）。CIDR の範囲は /18～/8 にする必要があります（/8 の場合に IP アドレスが最多になります）

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

ストレージ

  1. --lvp-share-path: サブディレクトリを作成できるホストマシンのパスです。サブディレクトリごとにローカル PV が作成されます。
  2. --lvp-share-storage-class: 永続ボリュームの作成に使用する StorageClass。StorageClass はクラスタの作成時に作成されます。
  3. --lvp-node-mounts-config-path: マウントされたディスクを検出できるホストマシンのパス。それぞれのマウントに対してローカル PersistentVolume（PV）が作成されます。
  4. --lvp-node-mounts-config-storage: クラスタの作成時に PV が作成されるストレージ クラス。

ストレージの詳細については、ローカル ストレージを構成するをご覧ください。

--validate-only を使用すると、gcloud コマンドを実行してクラスタを作成する前に、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 bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

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

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

ノードプールを作成する

クラスタを作成したら、ワークロードをデプロイする前に少なくとも 1 つのノードプールを作成する必要があります。ノードプールは、このクラスタで作成されるワーカーノードのグループのテンプレートです。gcloud CLI では、まずクラスタを作成してから、新しく作成したクラスタに 1 つ以上のノードプールを追加します。

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

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

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

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

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

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

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

  • --node-configs: ワーカーノード マシンの IPv4 アドレス。ノードごとにこのフラグを指定します。フラグの値の形式は次のとおりです。

    'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \

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

    • node-ip: ワーカーノードの IP アドレス。フラグごとに 1 つの node-ip しか指定できません。ノードプールの各ノードに対して、このフラグを再度追加します。

    • labels: ノードに付加される 1 つ以上の Key-Value ペア。

    以下の構文ルールに注意してください。

    • 値全体を単一引用符で囲みます。
    • 空白文字は使用できません。
    • labels セグメントの各 Key-Value ペアをセミコロンで区切ります。

    必要に応じて、次を指定できます。

    • --node-labels=KEY=VALUE,...: プール内の各ノードに適用される Kubernetes ラベル（key=value ペア）のカンマ区切りのリスト。

    • --node-taints=KEY=VALUE:EFFECT,... プール内の各ノードに適用される Kubernetes taint のカンマ区切りのリスト。taint は、1 つの効果に関連付けられた key=value ペアです。taint は、Pod のスケジューリングの toleration で使用されます。EFFECT には、次の NoSchedule、PreferNoSchedule、NoExecute のいずれかを指定します。

次の例では、user-cluster- に default-pool というノードプールを作成し、そのノードプールに 2 つのノードを追加しています。両方のノードに node-pool-key=node-pool-value というラベルが付けられ、taint dedicated=experimental:PreferNoSchedule が設定されています。

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

詳細については、gcloud CLI リファレンスをご覧ください。

Terraform

始める前に

ユーザー クラスタの作成時に選択するベアメタル上の Google Distributed Cloud（ソフトウェアのみ）のバージョンは、管理クラスタがサポートしているバージョンである必要があります。さらに、最新のマイナー バージョンまたはパッチ バージョンは、リリースから 7～14 日後まで GKE On-Prem API では使用できません。gcloud コマンドを実行して、ユーザー クラスタのインストールに使用できるサポート対象バージョンのリストを取得できます。

  1. コンポーネントを更新していることを確認します。

    gcloud components update

  2. 管理クラスタの名前とフリート メンバーシップのロケーションを確認します。

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    FLEET_HOST_PROJECT_ID は、管理クラスタが登録されているプロジェクトの ID に置き換えます。

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

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    LOCATION には、フリート サービスと接続サービスが実行されるロケーションが表示されます。1.28 より前で作成された管理クラスタは、グローバルの Fleet サービスと Connect サービスによって管理されます。1.28 以降では、管理クラスタの作成時に global または Google Cloud リージョンのいずれかを指定できます。次の例のコマンドでは、--admin-cluster-membership-location フラグにリージョンを指定します。

  3. ユーザー クラスタにインストールする利用可能なバージョンのリストを取得します。

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

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

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

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

    • ADMIN_CLUSTER_REGION: 管理クラスタのフリート メンバーシップのリージョン。これは、global または Google Cloudリージョンのいずれかです。gcloud container fleet memberships list の出力にある管理クラスタのロケーションを使用します。

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

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

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

最新のバグの修正と改善点を適用するため、サポートされている最も高いバージョンを使用することをおすすめします。

例

バンドルされた MetalLB ロードバランサを使用してユーザー クラスタを作成するには、次の基本的な構成サンプルを使用できます。詳細については、google_gkeonprem_bare_metal_cluster リファレンス ドキュメントをご覧ください。

変数を terraform.tfvars に設定する

このサンプルでは、main.tf に渡す変数ファイルの例により、バンドルされた MetalLB ロードバランサを構成する方法を示します。

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

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

    このサンプルには、main.tf に渡すサンプル変数が用意されています。

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

    cp terraform.tfvars.sample terraform.tfvars

  3. terraform.tfvars のパラメータ値を変更し、ファイルを保存します。

    
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
lb_address_pools    = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

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

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

    • region: GKE On-Prem API（gkeonprem.googleapis.com）、Fleet サービス（gkehub.googleapis.com）、Connect サービス（gkeconnect.googleapis.com）が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。

    • admin_cluster_name: ユーザー クラスタを管理する管理クラスタの名前。この例では、管理クラスタがリージョンとして global を使用することを前提としています。リージョン管理クラスタがある場合:

      1. テキスト エディタで main.tf を開きます。

      2. 次のように admin_cluster_membership を検索します。

        admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

      3. global を管理クラスタが使用するリージョンに変更して、ファイルを保存します。

    • bare_metal_version: ユーザー クラスタの Google Distributed Cloud のバージョン。管理クラスタと同じバージョン、または管理クラスタより 1 つ低いマイナー バージョン以下のバージョンを指定します。

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

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

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

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

    • control_plane_ips: コントロール プレーン ノードの 1 つ以上の IPv4 アドレスのリスト。コントロール プレーン ノードはシステム ワークロードを実行します。通常は、マシン 1 台（最小デプロイメントを使用する場合）とマシン 3 台（高可用性（HA）デプロイメントを使用する場合）のいずれかです。HA 用に過半数のクォーラムが確保できるように、ノード数を奇数で指定します。これらのアドレスは、クラスタを更新またはアップグレードするたびに変更できます。

    • worker_node_ips: ワーカーノード マシンの 1 つ以上の IPv4 アドレスのリスト。

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

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

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

  4. 変更を terraform.tfvars に保存します。

  5. Terraform プランを初期化して作成します。

    terraform init

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

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

    terraform plan

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

    terraform apply

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

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

コンソールでユーザー クラスタを作成すると、クラスタに Kubernetes のロールベース アクセス制御（RBAC）ポリシーが構成されます。そのため、 Google Cloud ID を使用してクラスタにログインできます。gcloud CLI を使用してユーザー クラスタを作成する場合、--admin-users フラグを含めないと、デフォルトでこれらの RBAC ポリシーが付与されます。--admin-users を使用して別のユーザーを管理者として指定する場合は、デフォルトをオーバーライドし、自分のメールアドレスと他の管理者のメールアドレスの両方を指定する必要があります。必要な IAM ポリシーと RBAC ポリシーの詳細については、Google の ID 認証を設定するをご覧ください。

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

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

  • Connect Gateway を使用して、Google Cloud CLI がインストールされているコンピュータからクラスタにアクセスします。この場合、kubectl は、Connect Gateway の kubeconfig を使用して、ユーザーの代わりにプライベート エンドポイントにトラフィックを安全に転送します。

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

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

Connect Gateway

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

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Connect Gateway の操作に使用するクラスタの認証情報を取得します。次のコマンドで、MEMBERSHIP_NAME はクラスタの名前に置き換えます。ベアメタル上の Google Distributed Cloud（ソフトウェアのみ）の場合、メンバーシップ名はクラスタ名と同じです。

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

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

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

kubectl get namespaces

管理ワークステーション

bmctl get credentials コマンドを使用して、新しく作成されたユーザー クラスタの kubeconfig ファイルを取得します。

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

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

  • CLUSTER_NAME: 対象とするユーザー クラスタの名前。

  • ADMIN_KUBECONFIG_PATH: 管理クラスタの kubeconfig ファイルのパス。

ユーザー クラスタの認証情報を含む kubeconfig がファイル bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig に書き込まれます。ファイル名の TIMESTAMP は、ファイルが作成された日時を示します。

このファイルにはクラスタの認証情報が含まれているため、アクセスが制限された安全な場所に保存する必要があります。

次のステップ