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

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

Anthos On-Prem API とは

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

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

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

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

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

準備

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

IAM 権限を付与する

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

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

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

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

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

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

必要な Google API

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

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

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

管理クラスタの前提条件

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

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

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

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

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

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

コマンドライン アクセス

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

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

ユーザー クラスタの作成

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

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

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

コンソール

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

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

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

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

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

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

  5. [ベアメタル] の横にある [構成] をクリックします。

  6. 前提条件とサンプル アーキテクチャを確認します。準備ができたら、[次へ] をクリックしてクラスタの構成を開始します。

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

クラスタの基本

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

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

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

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

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

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

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

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

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

  6. [ノード構成] セクションで、以下を指定します。

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

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

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

ネットワーキング

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

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

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

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

    MetalLB にバンドル済み

    バンドル型 MetalLB ロードバランサを使用してロード バランシングを構成します。このオプションにより、Anthos clusters on bare metal は、ワーカーノードの専用プールまたはコントロール プレーンと同じノードで実行されるレイヤ 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）。

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

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

ストレージ

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

  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 beta container bare-metal clusters create

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

gcloud beta container bare-metal node-pools create

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

準備

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

    gcloud auth login

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

    gcloud components update

例

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

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

MetalLB

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

gcloud beta container bare-metal 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 \
  --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: ユーザー クラスタを管理する管理クラスタの名前。管理クラスタ名は、Google Cloud でクラスタを一意に識別する完全指定のクラスタ名の最後のセグメントです: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • REGION: Anthos On-Prem API が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクルを管理する際に Anthos On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

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

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

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

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 を作成し、プールからアドレスのいずれか 1 つを手動で指定します。指定しない場合、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 を追加します。各 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: サブディレクトリを作成できるホストマシンのパスです。サブディレクトリごとにローカル PersistentVolume（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 beta container bare-metal 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 \
  --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: ユーザー クラスタを管理する管理クラスタの名前。管理クラスタ名は、Google Cloud でクラスタを一意に識別する完全指定のクラスタ名の最後のセグメントです: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • REGION: Anthos On-Prem API が実行される Google Cloud リージョン。us-west1 または別のサポートされているリージョンを指定します。リージョンはクラスタの作成後は変更できません。この設定では、以下のデータが保存されるリージョンを指定します。
    • クラスタのライフサイクルを管理する際に Anthos On-Prem API が必要とするユーザー クラスタ メタデータ
    • システム コンポーネントの Cloud Logging データと Cloud Monitoring データ
    • Cloud Audit Logs によって作成された管理監査ログ

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

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

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

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

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

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

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

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

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

ノードプールを作成

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

gcloud beta 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 beta 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

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

  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
    anthos-onprem-terraform/abm_user_cluster_metallb/terraform.tfvars.sample 
    
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"] }
]

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

    変数は次のとおりです。

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

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

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

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

    • 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: MetalLB ロードバランサで使用するアドレスプールを定義するマップのリスト。Ingress VIP をプールの 1 つに含める必要があります。

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

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

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

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

    terraform init

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

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

    terraform plan

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

    terraform apply

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

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

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

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

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

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

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

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

Connect ゲートウェイ

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

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

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

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

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

必要な認証情報を取得したら、通常の 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 は、ファイルが作成された日時を示します。

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

次のステップ