共有 VPC を使用したクラスタの設定

このガイドでは、共有 VPC を使用する 2 つの Google Kubernetes Engine（GKE）クラスタを別々のプロジェクトに作成する方法を説明します。GKE ネットワーキングに関する一般的な情報については、ネットワークの概要をご覧ください。

概要

共有 VPC を使用する場合は、1 つのプロジェクトをホスト プロジェクトとして指定します。ホスト プロジェクトには他のプロジェクト（サービス プロジェクト）を接続できます。ホスト プロジェクト内には、ネットワーク、サブネット、セカンダリ アドレス範囲、ファイアウォール ルールなどのネットワーク リソースを作成します。そして選択したサブネットを、セカンダリ アドレス範囲を含め、サービス プロジェクトと共有します。サービス プロジェクト内で実行されるコンポーネントは、共有 VPC を使用して他のサービス プロジェクト内で実行中のコンポーネントと通信できます。

共有 VPC は、Autopilot クラスタ、ゾーンおよびリージョンの Standard クラスタで使用できます。

共有 VPC を使用する標準クラスタでは、レガシー ネットワークを使用できません。また、VPC ネイティブのトラフィック ルーティングを有効にする必要があります。Autopilot クラスタでは、常に VPC ネイティブのトラフィック ルーティングが有効になります。

共有 VPC クラスタは、新しいクラスタの作成時に構成できます。GKE では、既存クラスタの共有 VPC モデルへの変換はサポートされていません。

共有 VPC を使用する場合、特定の割り当てと制限が適用されます。たとえば、プロジェクトに含まれるネットワークの数に適用される割り当てや、ホスト プロジェクトに接続できるサービス プロジェクトの数に適用される制限があります。詳細については、割り当てと上限をご覧ください。

サンプルについて

このガイドの例では、共有 VPC の概要で説明されている 2 層のウェブ アプリケーションを対象としたインフラストラクチャをセットアップします。

始める前に

共有 VPC でクラスタを設定する前に、次のことを行います。

  • Google Cloud の組織を用意します。
  • 組織に 3 つの Google Cloud プロジェクトを作成します。
  • 共有 VPC で使用される各種 Identity and Access Management（IAM）ロールを含む共有 VPC のコンセプトを理解しておく必要があります。このガイドで説明するタスクは、共有 VPC 管理者が実行する必要があります。
  • 組織、フォルダ、プロジェクトに適用可能な組織ポリシーの制約を理解しておいてください。組織ポリシー管理者が、どのプロジェクトが共有 VPC ホストになれるのかを制限する制約、またはどのサブネットが共有できるのかを制限する制約を定義した可能性があります。詳細については、組織のポリシーの制約をご覧ください。

このガイドの演習を行う前に、次の作業を行います。

  • ホスト プロジェクトにするプロジェクトを 1 つ選択します。
  • サービス プロジェクトにするプロジェクトを 2 つ選択します。

各プロジェクトには名前、ID、番号が付けられます。場合によっては、名前と ID が同じこともあります。このガイドでは、プロジェクトを表すときに、わかりやすい名前とプレースホルダを使用しています。

わかりやすい名前 プロジェクト ID
プレースホルダ		 プロジェクト番号
プレースホルダ
ホスト プロジェクト HOST_PROJECT_ID HOST_PROJECT_NUM
1 番目のサービス プロジェクト SERVICE_PROJECT_1_ID SERVICE_PROJECT_1_NUM
2 番目のサービス プロジェクト SERVICE_PROJECT_2_ID SERVICE_PROJECT_2_NUM

プロジェクト ID とプロジェクト番号を見つける

プロジェクト ID とプロジェクト番号を見つけるには、gcloud CLI または Google Cloud コンソールを使用します。

コンソール

  1. Google Cloud コンソールのホームページに移動します。

    ホームページに移動

  2. プロジェクト選択ツールで、ホスト プロジェクトとして使用するプロジェクトを選択します。

  3. [プロジェクト情報] で、プロジェクトの名前、ID、番号を確認します。後で使用できるように、ID と番号をメモします。

  4. サービス プロジェクトとして使用するプロジェクトのそれぞれについて、上記の手順を繰り返します。

gcloud

次のコマンドを実行して、プロジェクトの一覧を取得します。

gcloud projects list

出力に、プロジェクトの名前、ID、番号が示されます。後で使用できるように、ID と番号をメモします。

PROJECT_ID        NAME        PROJECT_NUMBER
host-123          host        1027xxxxxxxx
srv-1-456         srv-1       4964xxxxxxxx
srv-2-789         srv-2       4559xxxxxxxx

プロジェクトで GKE API を有効にする

このガイドの演習を続ける前に、3 つのプロジェクトすべてで GKE API が有効になっていることを確認してください。プロジェクト内でこの API を有効にすると、プロジェクトの GKE サービス アカウントが作成されます。このガイドの残りのタスクを行うには、各プロジェクトに GKE サービス アカウントが必要です。

GKE API を有効にするには、Google Cloud コンソールまたは Google Cloud CLI を使用します。

コンソール

  1. Google Cloud コンソールの [API とサービス] ページに移動します。

    [API とサービス] に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトとして使用するプロジェクトを選択します。

  3. API のリストに [Kubernetes Engine API] が含まれている場合、この API はすでに有効にされているので、操作は必要ありません。リストに含まれていない場合は、[API とサービスの有効化] をクリックします。Kubernetes Engine API を検索します。[Kubernetes Engine API] カードをクリックし、[有効にする] をクリックします。

  4. サービス プロジェクトとして選択したプロジェクトごとに、上記の手順を繰り返します。オペレーションごとに完了するまで時間がかかる場合があります。

gcloud

3 つのプロジェクトで GKE API を有効にします。オペレーションごとに完了するまで時間がかかる場合があります。

gcloud services enable container.googleapis.com --project HOST_PROJECT_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_1_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_2_ID

ネットワークと 2 つのサブネットを作成する

このセクションでは、次のタスクを行います。

  1. ホスト プロジェクト内で、shared-net という名前のネットワークを作成します。
  2. tier-1 と tier-2 という名前で 2 つのサブネットを作成します。
  3. サブネットごとに、Service 用と Pod 用の 2 つのセカンダリ アドレス範囲を作成します。

コンソール

  1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。

  3. [VPC ネットワークを作成] をクリックします。

  4. [名前] に「shared-net」と入力します。

  5. [サブネット作成モード] で [カスタム] を選択します。

  6. [新しいサブネット] ボックスの [名前] に「tier-1」を入力します。

  7. [リージョン] でリージョンを選択します。

  8. [IP スタックタイプ] で [IPv4（シングルスタック）] を選択します。

  9. [IPv4 範囲] に「10.0.4.0/22」と入力します。

  10. [セカンダリ IPv4 範囲を作成する] をクリックします。[サブネット範囲の名前] に「tier-1-services」と入力し、[セカンダリ IPv4 範囲] に「10.0.32.0/20」と入力します。

  11. [IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「tier-1-pods」と入力し、[セカンダリ IPv4 範囲] に「10.4.0.0/14」と入力します。

  12. [サブネットを追加] をクリックします。

  13. [名前] に「tier-2」と入力します。

  14. [リージョン] で、前のサブネットに選択したのと同じリージョンを選択します。

  15. [IPv4 範囲] に「172.16.4.0/22」と入力します。

  16. [セカンダリ IPv4 範囲を作成する] をクリックします。[サブネット範囲の名前] に「tier-2-services」と入力し、[セカンダリ IPv4 範囲] に「172.16.16.0/20」と入力します。

  17. [IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「tier-2-pods」と入力し、[セカンダリ IPv4 範囲] に「172.20.0.0/14」と入力します。

  18. [作成] をクリックします。

gcloud

ホスト プロジェクト内で、shared-net という名前のネットワークを作成します。

gcloud compute networks create shared-net \
    --subnet-mode custom \
    --project HOST_PROJECT_ID

新しいネットワークで、tier-1 という名前のサブネットを作成します。

gcloud compute networks subnets create tier-1 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 10.0.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-1-services=10.0.32.0/20,tier-1-pods=10.4.0.0/14

tier-2 という名前で別のサブネットを作成します。

gcloud compute networks subnets create tier-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 172.16.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

COMPUTE_REGION は、Compute Engine のリージョンに置き換えます。

サービス プロジェクト内でのサービス アカウントの名前を確認する

サービス プロジェクトは 2 つあり、それぞれに複数のサービス アカウントがあります。このセクションでは、GKE サービス アカウントと Google API サービス アカウントについて説明します。これらのサービス アカウントの名前は、次のセクションで必要になります。

次の表に、2 つのサービス プロジェクトの GKE サービス アカウントと Google API サービス アカウントの名前を示します。

サービス アカウントの種類 サービス アカウント名
GKE service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com
Google API SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com

共有 VPC を有効にしてロールを付与する

このセクションのタスクを行うには、組織で共有 VPC 管理者ロールが定義されている必要があります。

このセクションでは、次のタスクを行います。

  1. ホスト プロジェクトで共有 VPC を有効にします。
  2. 2 つのサービス プロジェクトをホスト プロジェクトに接続します。
  3. サービス プロジェクトに属するサービス アカウントに適切な IAM ロールを付与します。
    • 最初のサービス プロジェクトで、ホスト プロジェクトの tier-1 サブネットに対する Compute Network User ロールを 2 つのサービス アカウントに付与します。
    • 2 番目のサービス プロジェクトで、ホスト プロジェクトの tier-2 サブネットに対する Compute Network User ロールを 2 つのサービス プロジェクトに付与します。

Console

次の操作を行って共有 VPC を有効にし、サービス プロジェクトを接続してロールを付与します。

  1. Google Cloud コンソールで [共有 VPC] ページに移動します。

    共有 VPC に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。

  3. [共有 VPC を設定] をクリックします。[ホスト プロジェクトを有効にする] 画面が表示されます。

  4. [保存して続行] をクリックします。[サブネットを選択する] ページが表示されます。

  5. [共有モード] で、[個々のサブネット] を選択します。

  6. [共有するサブネット] で、[tier-1] と [tier-2] をオンにします。その他すべてのチェックボックスをオフにします。

  7. [続行] をクリックします。[権限を付与する] ページが表示されます。

  8. [サービス プロジェクトの接続] で、1 番目のサービス プロジェクトと 2 番目のサービス プロジェクトをオンにします。[サービス プロジェクトの接続] のその他すべてのチェックボックスをオフにします。

  9. [Kubernetes Engine へのアクセス] で、[有効] をオンにします。

  10. [保存] をクリックします。新しいページが表示されます。

  11. [個々のサブネットに対する権限] で、[tier-1] をオンにします。

  12. 右ペインで、2 番目のサービス プロジェクトに属するサービス アカウントを削除します。つまり、SERVICE_PROJECT_2_NUM を含むサービス アカウントをすべて削除します。

  13. 右ペインで、1 番目のサービス プロジェクトに属する Kubernetes Engine サービス アカウントと Google API サービス アカウントの名前を見つけます。これらのサービス アカウントの名前が両方ともリストに含まれていることを確認します。いずれか一方がリストに含まれていない場合は、[メンバーを追加] でそのサービス アカウントの名前を入力し、[追加] をクリックします。

  14. 中央ペインの [個々のサブネットに対する権限] で、[tier-2] をオンにし、[tier-1] をオフにします。

  15. 右ペインで、1 番目のサービス プロジェクトに属するサービス アカウントを削除します。つまり、SERVICE_PROJECT_1_NUM を含むサービス アカウントをすべて削除します。

  16. 右ペインで、2 番目のサービス プロジェクトに属する Kubernetes Engine サービス アカウントと Google API サービス アカウントの名前を見つけます。これらのサービス アカウントの名前が両方ともリストに含まれていることを確認します。いずれか一方がリストに含まれていない場合は、[メンバーを追加] でそのサービス アカウントの名前を入力し、[追加] をクリックします。

gcloud

  1. ホスト プロジェクト内で共有 VPC を有効にします。使用するコマンドは、使用している必要な管理者ロールによって異なります。

    組織レベルで共有 VPC 管理者ロールを持っている場合

    gcloud compute shared-vpc enable HOST_PROJECT_ID

    フォルダレベルで共有 VPC 管理者のロールを持っている場合

    gcloud beta compute shared-vpc enable HOST_PROJECT_ID

  2. 1 番目のサービス プロジェクトをホスト プロジェクトに接続します。

    gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

  3. 2 番目のサービス プロジェクトをホスト プロジェクトに接続します。

    gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

  4. 以下のとおり、tier-1 サブネットの IAM ポリシーを取得します。

    gcloud compute networks subnets get-iam-policy tier-1 \
   --project HOST_PROJECT_ID \
   --region COMPUTE_REGION

    出力には etag フィールドが含まれます。etag の値をメモします。

  5. 次のコンテンツを含むファイルを tier-1-policy.yaml という名前で作成します。

    bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

    ETAG_STRING は、以前にメモした etag の値に置き換えます。

  6. 以下のとおり、tier-1 サブネットの IAM ポリシーを設定します。

    gcloud compute networks subnets set-iam-policy tier-1 \
    tier-1-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

  7. 以下のとおり、tier-2 サブネットの IAM ポリシーを取得します。

    gcloud compute networks subnets get-iam-policy tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

    出力には etag フィールドが含まれます。etag の値をメモします。

  8. 次のコンテンツを含むファイルを tier-2-policy.yaml という名前で作成します。

    bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

    ETAG_STRING は、以前にメモした etag の値に置き換えます。

  9. 以下のとおり、tier-2 サブネットの IAM ポリシーを設定します。

    gcloud compute networks subnets set-iam-policy tier-2 \
    tier-2-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

ファイアウォール リソースの管理

サービス プロジェクトの GKE クラスタで、ホスト プロジェクトのファイアウォール リソースを作成して管理するには、次のいずれかの方法で、サービス プロジェクトの GKE サービス アカウントに適切な IAM 権限を付与する必要があります。

  • サービス プロジェクトの GKE サービス アカウントに、ホスト プロジェクトに対する Compute Security Admin ロールを付与します。

コンソール

  1. Google Cloud コンソールの [IAM] ページに移動します。

    [IAM] に移動

  2. ホスト プロジェクトを選択します。

  3. [ アクセスを許可] をクリックして、サービス プロジェクトの GKE サービス アカウント プリンシパル service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com を入力します。

  4. プルダウン リストから Compute Security Admin ロールを選択します。

  5. [保存] をクリックします。

gcloud

サービス プロジェクトの GKE サービス アカウントに、ホスト プロジェクトに対する Compute Security Admin ロールを付与します。

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/compute.securityAdmin

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

  • HOST_PROJECT_ID: 共有 VPC ホスト プロジェクト ID
  • SERVICE_PROJECT_NUM: GKE サービス アカウントを含むサービス プロジェクトの ID

  • より細かく設定する場合は、カスタム IAM ロールを作成し、compute.networks.updatePolicy、compute.firewalls.list、compute.firewalls.get、compute.firewalls.create、compute.firewalls.update、compute.firewalls.delete 権限のみを含めます。サービス プロジェクトの GKE サービス アカウントに、ホスト プロジェクトに対するこのカスタムロールを付与します。

Console

ホスト プロジェクトで、上記の IAM 権限を含むカスタムロールを作成します。

  1. Google Cloud コンソールで、[ロール] ページに移動します。

    [ロール] ページに移動

  2. ページの上部にあるプルダウン リストからホスト プロジェクトを選択します。

  3. [ロールを作成] をクリックします。

  4. ロールのタイトル、説明、ID、ロールのリリース段階を入力します。ロールの作成後にロール名を変更することはできません。

  5. [権限を追加] をクリックします。

  6. compute.networks でフィルタし、前述の IAM 権限を選択します。

  7. 必要な権限をすべて選択したら、[追加] をクリックします。

  8. [作成] をクリックします。

ホスト プロジェクト内で新しく作成されたカスタムロールをサービス プロジェクトの GKE サービス アカウントに付与します。

  1. Google Cloud コンソールの [IAM] ページに移動します。

    [IAM] に移動

  2. ホスト プロジェクトを選択します。

  3. [ アクセスを許可] をクリックして、サービス プロジェクトの GKE サービス アカウント プリンシパル service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com を入力します。

  4. 新しく作成したカスタムロールのタイトルをフィルタして選択します。

  5. [保存] をクリックします。

gcloud

  1. ホスト プロジェクトで、上記の IAM 権限を含むカスタムロールを作成します。

    gcloud iam roles create ROLE_ID \
    --title="ROLE_TITLE" \
    --description="ROLE_DESCRIPTION" \
    --stage=LAUNCH_STAGE \
    --permissions=compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete \
    --project=HOST_PROJECT_ID

  2. ホスト プロジェクト内で新しく作成されたカスタムロールをサービス プロジェクトの GKE サービス アカウントに付与します。

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role=projects/HOST_PROJECT_ID/roles/ROLE_ID

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

    • ROLE_ID: ロールの名前（gkeFirewallAdminなど）。
    • ROLE_TITLE: ロールのわかりやすいタイトル（GKE Firewall Admin など）
    • ROLE_DESCRIPTION: ロールに関する簡単な説明（GKE service account FW permissions など）。
    • LAUNCH_STAGE: ライフサイクルにおけるロールのリリース段階（ALPHA、BETA、GA など）
    • HOST_PROJECT_ID: 共有 VPC ホスト プロジェクト ID
    • SERVICE_PROJECT_NUM: GKE サービス アカウントを含むサービス プロジェクトの ID

複数のサービス プロジェクトにクラスタがある場合は、いずれかの方法を選択して、サービス プロジェクトの GKE サービス アカウントごとに繰り返す必要があります。

サブネットに対して付与するロールの概要

サブネットに付与されるロールの概要は次のとおりです。

サービス アカウント ロール サブネット
service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com Compute ネットワーク ユーザー tier-1
SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com Compute ネットワーク ユーザー tier-1
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com Compute ネットワーク ユーザー tier-2
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com Compute ネットワーク ユーザー tier-2

Kubernetes Engine へのアクセス

サービス プロジェクトを接続するときに Kubernetes Engine へのアクセスを有効にすると、ホスト プロジェクトでネットワーク管理オペレーションを実行する権限がサービス プロジェクトの GKE サービス アカウントに付与されます。

Kubernetes Engine へのアクセスを有効にせずにサービス プロジェクトを接続した場合、ホスト プロジェクトとサービス プロジェクトの両方で Kubernetes Engine API が有効になっていれば、次の IAM ロール バインディングをホスト プロジェクトに追加することで、サービス プロジェクトの GKE サービス アカウントに手動で権限を割り当てることができます。

メンバー ロール リソース
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com Compute ネットワーク ユーザー 特定のサブネットまたはホスト プロジェクト全体
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com Host サービス エージェント ユーザー ホスト プロジェクトの GKE サービス アカウント

Host サービス エージェント ユーザーのロールを付与する

各サービス プロジェクトの GKE サービス アカウントには、ホスト プロジェクトの Host サービス エージェント ユーザーのロールを割り当てる必要があります。GKE サービス アカウントの形式は次のとおりです。

service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com

SERVICE_PROJECT_NUM は、サービス プロジェクトのプロジェクト番号です。

このバインディングにより、サービス プロジェクトの GKE サービス アカウントは、ホスト プロジェクトの GKE サービス アカウントと同様に、ホスト プロジェクトでネットワーク管理オペレーションを実行できます。このロールは、サービス プロジェクトの GKE サービス アカウントにのみ付与できます。

コンソール

Google Cloud コンソールを使用している場合は、Host サービス エージェント ユーザーロールを明示的に付与する必要はありません。このロールは、Google Cloud コンソールを使用してサービス プロジェクトをホスト プロジェクトに接続したときに自動的に付与されています。

gcloud

  1. 最初のプロジェクトで、Host サービス エージェント ユーザーのロールをプロジェクトの GKE サービス アカウントに付与します。このロールは、ホスト プロジェクトに対して付与されます。

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

  2. 2 番目のプロジェクトで、Host サービス エージェント ユーザーのロールをプロジェクトの GKE サービス アカウントに付与します。このロールは、ホスト プロジェクトに対して付与されます。

    gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

使用可能なサブネットとセカンダリ IP アドレス範囲を確認する

クラスタを作成する際には、クラスタの Pod と Service に使用するサブネットとセカンダリ IP アドレス範囲を指定する必要があります。いくつかの理由で、IP アドレス範囲が使用できない場合もあります。クラスタを作成する際に Google Cloud コンソールを使用するか gcloud CLI を使用するかに関係なく、使用可能な IP アドレス範囲を指定する必要があります。

新しいクラスタの Service には、まだ使用されていない IP アドレス範囲のみを使用できます。新しいクラスタの Pod には、まだ使用されていない IP アドレス範囲か、他のクラスタの Pod と共有する IP アドレス範囲のいずれかを指定できます。GKE によって作成および管理されている IP アドレス範囲はクラスタでは使用できません。

gcloud CLI を使用すると、プロジェクトで使用可能なサブネットとセカンダリ IP アドレス範囲を一覧表示できます。

gcloud

gcloud container subnets list-usable \
    --project SERVICE_PROJECT_ID \
    --network-project HOST_PROJECT_ID

SERVICE_PROJECT_ID は、サービス プロジェクトのプロジェクト ID に置き換えます。

gcloud CLI コマンドで --project または --network-project オプションを省略した場合は、アクティブな構成のデフォルト プロジェクトが使用されます。ホスト プロジェクトとネットワーク プロジェクトは異なるものであるため、--project と --network-project の一方または両方を必ず指定する必要があります。

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

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-2
RANGE: 172.16.4.0/22

SECONDARY_RANGE_NAME: tier-2-services
IP_CIDR_RANGE: 172.20.0.0/14
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-2-pods
IP_CIDR_RANGE: 172.16.16.0/20
STATUS: usable for pods or services

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-1
RANGE: 10.0.4.0/22

SECONDARY_RANGE_NAME: tier-1-services
IP_CIDR_RANGE: 10.0.32.0/20
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-1-pods
IP_CIDR_RANGE: 10.4.0.0/14
STATUS: usable for pods or services

次の場合、list-usable コマンドは空のリストを返します。

  • サービス プロジェクトの Kubernetes Engine サービス アカウントに、ホスト プロジェクトに対する Host サービス エージェント ユーザーのロールがない。
  • ホスト プロジェクトの Kubernetes Engine サービス アカウントが存在しない（たとえば、アカウントを誤って削除した場合など）。
  • Kubernetes Engine API がホスト プロジェクトで有効になっていない（ホスト プロジェクトの Kubernetes Engine サービス アカウントが存在しないことを意味します）。

詳細については、トラブルシューティングをご覧ください。

セカンダリ範囲に関する注意事項

所定のサブネット内に作成できるセカンダリ範囲の数は 30 個までです。クラスタごとに、Pod 用と Service 用の 2 つのセカンダリ範囲が必要となります。

1 番目のサービス プロジェクト内でクラスタを作成する

最初のサービス プロジェクトでクラスタを作成するには、gcloud CLI または Google Cloud コンソールを使用して次の操作を行います。

コンソール

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. プロジェクト選択ツールで、1 番目のサービス プロジェクトを選択します。

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

  4. [Autopilot] または [Standard] セクションで、[構成] をクリックします。

  5. [名前] に「tier-1-cluster」と入力します。

  6. [リージョン] プルダウン リストで、サブネットに使用したのと同じリージョンを選択します。

  7. ナビゲーション パネルで [ネットワーキング] をクリックします。

  8. [共有ネットワーク（共有元のホスト プロジェクト）] を選択します。

  9. [ネットワーク] で [shared-net] を選択します。

  10. [ノードのサブネット] で [tier-1] を選択します。

  11. [Pod のセカンダリ CIDR 範囲] で [tier-1-pods] を選択します。

  12. [Service のセカンダリ CIDR 範囲] で [tier-1-services] を選択します。

  13. [作成] をクリックします。

  14. 作成が完了したら、クラスタのリストで [tier-1-cluster] をクリックします。

  15. [クラスタの詳細] ページで [ノード] タブをクリックします。

  16. [ノードプール] で、検査するノードプールの名前をクリックします。

  17. [インスタンス グループ] で、検査するインスタンス グループの名前をクリックします。グループの名前の例は、gke-tier-1-cluster-default-pool-5c5add1f-grp です。

  18. インスタンスのリストで、ノードの内部 IP アドレスが tier-1 サブネットのプライマリ範囲 10.0.4.0/22 に収まっていることを確認します。

gcloud

1 番目のサービス プロジェクト内で tier-1-cluster という名前のクラスタを作成します。

gcloud container clusters create-auto tier-1-cluster \
    --project=SERVICE_PROJECT_1_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-1 \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services

作成が完了したら、クラスタノードが tier-1 サブネットのプライマリ範囲 10.0.4.0/22 内にあることを確認します。

gcloud compute instances list --project SERVICE_PROJECT_1_ID

出力に、ノードの内部 IP アドレスが示されます。

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.2
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.3
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.4

2 番目のサービス プロジェクト内でクラスタを作成する

2 番目のサービス プロジェクトでクラスタを作成するには、gcloud CLI または Google Cloud コンソールを使用して次の操作を行います。

コンソール

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. プロジェクト選択ツールで、2 番目のサービス プロジェクトを選択します。

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

  4. [Standard] セクションまたは [Autopilot] セクションで、[構成] をクリックします。

  5. [名前] に「tier-2-cluster」と入力します。

  6. [リージョン] プルダウン リストで、サブネットに使用したのと同じリージョンを選択します。

  7. ナビゲーション パネルで [ネットワーキング] をクリックします。

  8. [ネットワーク] で [shared-net] を選択します。

  9. [ノードのサブネット] で [tier-2] を選択します。

  10. [Pod のセカンダリ CIDR 範囲] で [tier-2-pods] を選択します。

  11. [Service のセカンダリ CIDR 範囲] で [tier-2-services] を選択します。

  12. [作成] をクリックします。

  13. 作成が完了したら、クラスタのリストで [tier-2-cluster] をクリックします。

  14. [クラスタの詳細] ページで [ノード] タブをクリックします。

  15. [ノードプール] で、検査するノードプールの名前をクリックします。

  16. [インスタンス グループ] で、検査するインスタンス グループの名前をクリックします。例: gke-tier-2-cluster-default-pool-5c5add1f-grp

  17. インスタンスのリストで、ノードの内部 IP アドレスが tier-2 サブネットのプライマリ範囲 172.16.4.0/22 に収まっていることを確認します。

gcloud

2 番目のサービス プロジェクト内で tier-2-cluster という名前のクラスタを作成します。

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-2 \
    --cluster-secondary-range-name=tier-2-pods \
    --services-secondary-range-name=tier-2-services

作成が完了したら、クラスタノードが tier-2 サブネットのプライマリ範囲 172.16.4.0/22 内にあることを確認します。

gcloud compute instances list --project SERVICE_PROJECT_2_ID

出力に、ノードの内部 IP アドレスが示されます。

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.2
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.3
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.4

ファイアウォール ルールの作成

ネットワークへのトラフィックの送信とネットワーク内のクラスタ間でのトラフィックの送信を許可するには、ファイアウォールを作成する必要があります。ここでは、ファイアウォール ルールの作成と更新の方法について説明します。

ノードへの SSH 接続を許可するファイアウォール ルールを作成する

ホスト プロジェクトで、shared-net ネットワークのファイアウォール ルールを作成します。TCP ポート 22 へのトラフィックの送信を許可します。これにより、SSH を使用してクラスタノードに接続できるようになります。

コンソール

  1. Google Cloud コンソールの [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。

  3. VPC ネットワークのメニューで、[ファイアウォール ルールを作成] をクリックします。

  4. [名前] に「my-shared-net-rule」と入力します。

  5. [ネットワーク] で [shared-net] を選択します。

  6. [トラフィックの方向] で [上り] をオンにします。

  7. [一致したときのアクション] で [許可] をオンにします。

  8. [ターゲット] で [ネットワーク上のすべてのインスタンス] を選択します。

  9. [ソースフィルタ] で [IP 範囲] を選択します。

  10. [ソース IP の範囲] に「0.0.0.0/0」と入力します。

  11. [プロトコルとポート] で [指定したプロトコルとポート] をオンにします。ボックスに「tcp:22」と入力します。

  12. [作成] をクリックします。

gcloud

共有ネットワークのファイアウォール ルールを作成します。

gcloud compute firewall-rules create my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --direction INGRESS \
    --allow tcp:22

SSH を使用してノードに接続する

TCP ポート 22 で上り（内向き）トラフィックを許可するファイアウォール ルールを作成したら、SSH を使用してノードに接続します。

コンソール

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. プロジェクト選択ツールで、1 番目のサービス プロジェクトを選択します。

  3. [tier-1-cluster] をクリックします。

  4. [クラスタの詳細] ページで [ノード] タブをクリックします。

  5. [ノードプール] でノードプールの名前をクリックします。

  6. [インスタンス グループ] で、インスタンス グループの名前をクリックします。たとえば、gke-tier-1-cluster-default-pool-faf87d48-grp などです。

  7. インスタンスのリストで、ノードの内部 IP アドレスをメモしておきます。これらのアドレスは 10.0.4.0/22 の範囲内にあります。

  8. いずれかのノードで [SSH] をクリックします。SSH で使用する TCP ポート 22 はファイアウォール ルールで許可されているため、SSH で接続できます。

gcloud

1 番目のサービス プロジェクト内でノードを一覧表示します。

gcloud compute instances list --project SERVICE_PROJECT_1_ID

出力に、クラスタに含まれるノードの名前が示されます。

NAME                                           ...
gke-tier-1-cluster-default-pool-faf87d48-3mf8  ...
gke-tier-1-cluster-default-pool-faf87d48-q17k  ...
gke-tier-1-cluster-default-pool-faf87d48-x9rk  ...

SSH を使用していずれかのノードに接続します。

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

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

  • NODE_NAME: いずれかのノードの名前。
  • COMPUTE_ZONE: リージョン内の Compute Engine ゾーンの名前。

ノード間で ping を実行するようにファイアウォール ルールを更新する

  1. SSH コマンドライン ウィンドウで、CoreOS toolbox を起動します。

    /usr/bin/toolbox

  2. ツールボックスのシェルで、同じクラスタに含まれる他のいずれかのノードに対して ping を実行します。次に例を示します。

    ping 10.0.4.4

    どちらのノードも 10.0.4.0/22 の範囲内にあるため、ping コマンドは成功するはずです。

  3. 次に、他のサービス プロジェクト内のクラスタに含まれるノードのいずれかに ping を実行します。例:

    ping 172.16.4.3

    今回は ping コマンドが失敗します。ファイアウォール ルールでは、Internet Control Message Protocol（ICMP）トラフィックが許可されていないためです。

  4. ツールボックスのシェルではなく通常のコマンド プロンプトで、ICMP を許可するようにファイアウォール ルールを更新します。

    gcloud compute firewall-rules update my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --allow tcp:22,icmp

  5. ツールボックスのシェルで、ノードに対して再度 ping を実行します。例:

    ping 172.16.4.3

    今回は ping コマンドが成功します。

追加のファイアウォール ルールを作成する

クラスタ内のノード、Pod、Service の間での通信を許可する追加のファイアウォール ルールを作成できます。

たとえば、以下のルールはすべての TCP ポートまたは UDP ポートに対し、tier-1-cluster 内のあらゆるノード、Pod、Service からのトラフィックの受信を許可します。

gcloud compute firewall-rules create my-shared-net-rule-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

以下のルールは、すべての TCP ポートまたは UDP ポートに対し、tier-2-cluster 内のあらゆるノード、Pod、Service からのトラフィックの受信を許可します。

gcloud compute firewall-rules create my-shared-net-rule-3 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 172.16.4.0/22,172.20.0.0/14,172.16.16.0/20

Kubernetes では、ロードバランサ サービスを作成するときなどに、必要に応じてファイアウォール リソースの作成と管理も試みます。権限の問題が原因で Kubernetes 自体ではファイアウォール ルールを変更できない場合は、Kubernetes イベントが発生し、変更方法が指示されます。

ファイアウォール ルールを変更する権限を Kubernetes に付与する場合は、ファイアウォール リソースの管理をご覧ください。

Ingress ロードバランサの場合、権限が不十分なために Kubernetes でファイアウォール ルールを変更できない場合は、数分ごとに firewallXPNError イベントが発生します。GLBC 1.4 以降では、Ingress リソースに networking.gke.io/suppress-firewall-xpn-error: "true" アノテーションを追加することで firewallXPNError イベントをミュートできます。いつでもこのアノテーションを削除してミュートを解除できます。

共有 VPC 内に限定公開クラスタを作成する

限定公開クラスタでも共有 VPC を使用できます。

そのためには、クラスタの作成に使用するユーザー アカウントまたはサービス アカウントに対して、ホスト プロジェクトの次の権限を付与する必要があります。

  • compute.networks.get

  • compute.networks.updatePeering

また、コントロール プレーンの IP アドレス範囲が、共有ネットワーク内で予約されている他の範囲と重複しないようにする必要もあります。

2020 年 1 月 15 日より前に作成された限定公開クラスタの場合、VPC ネットワークあたりの限定公開 GKE クラスタの最大数は、1 つの VPC ネットワークからのピアリング接続の数に制限されています。新しい限定公開クラスタは VPC ネットワークのピアリング接続を再利用するため、この制限は適用されません。古い限定公開クラスタで VPC ネットワーク ピアリングを再利用できるようにするには、クラスタを削除して再作成する必要があります。クラスタをアップグレードしても、既存の VPC ネットワーク ピアリング接続は再利用されません。

ここでは、定義済みの共有 VPC ネットワークに private-cluster-vpc という名前の VPC ネイティブ クラスタを作成します。

コンソール

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. [作成] をクリックします。

  3. [Autopilot] または [Standard] セクションで、[構成] をクリックします。

  4. [名前] に「private-cluster-vpc」と入力します。

  5. ナビゲーション パネルで [ネットワーキング] をクリックします。

  6. [限定公開クラスタ] を選択します。

  7. （Autopilot の場合は省略可）: [コントロール プレーンの IP 範囲] を 172.16.0.16/28 に設定します。

  8. [ネットワーク] プルダウン リストで、以前に作成した VPC ネットワークを選択します。

  9. [ノードのサブネット] プルダウン リストで、以前に作成した共有サブネットを選択します。

  10. 必要に応じてクラスタを構成します。

  11. [作成] をクリックします。

gcloud

次のコマンドを実行して、事前定義の共有 VPC に private-cluster-vpc という名前のクラスタを作成します。

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork=SHARED_SUBNETWORK \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28

IP アドレスの予約

共有 VPC クラスタ用に内部 IP アドレスと外部 IP アドレスを予約できます。IP アドレスがサービス プロジェクトに予約されていることを確認してください。

内部 IP アドレスの場合は、IP アドレスが属するサブネットワークを指定する必要があります。複数のプロジェクトにまたがる IP アドレスを予約するには、サブネットワークを識別できるように完全なリソース URL を使用します。

Google Cloud CLI で次のコマンドを使用して、内部 IP アドレスを予約できます。

gcloud compute addresses create RESERVED_IP_NAME \
    --region=COMPUTE_REGION \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNETWORK_NAME \
    --addresses=IP_ADDRESS \
    --project=SERVICE_PROJECT_ID

このコマンドを呼び出すには、サブネットワークに compute.subnetworks.use 権限が追加されている必要があります。サブネットワークで発信者に compute.networkUser ロールを付与するか、プロジェクト レベルで compute.subnetworks.use 権限を持つカスタマイズされたロールを発信者に付与できます。

クリーンアップ

このガイドの演習を終えたら、自身のアカウントで不要な請求が発生するのを防ぐため、次の手順でリソースを削除します。

クラスタを削除する

作成した 2 つのクラスタを削除します。

コンソール

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. プロジェクト選択ツールで、1 番目のサービス プロジェクトを選択します。

  3. tier-1-cluster を選択し、[削除] をクリックします。

  4. プロジェクト選択ツールで、2 番目のサービス プロジェクトを選択します。

  5. tier-2-cluster を選択して、[削除] をクリックします。

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --zone COMPUTE_ZONE

共有 VPC を無効にする

ホスト プロジェクト内で共有 VPC を無効にします。

コンソール

  1. Google Cloud コンソールで [共有 VPC] ページに移動します。

    共有 VPC に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。

  3. [共有 VPC を無効にする] をクリックします。

  4. フィールドに「HOST_PROJECT_ID」と入力し、[無効にする] をクリックします。

gcloud

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc disable HOST_PROJECT_ID

ファイアウォール ルールを削除する

作成したファイアウォール ルールを削除します。

コンソール

  1. Google Cloud コンソールの [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。

  3. ルールのリストで、my-shared-net-rule、my-shared-net-rule-2、my-shared-net-rule-3 を選択します。

  4. [削除] をクリックします。

gcloud

ファイアウォール ルールを削除します。

gcloud compute firewall-rules delete \
    my-shared-net-rule \
    my-shared-net-rule-2 \
    my-shared-net-rule-3 \
    --project HOST_PROJECT_ID

共有ネットワークを削除する

作成した共有ネットワークを削除します。

コンソール

  1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。

  3. ネットワークのリストで shared-net を選択します。

  4. [VPC ネットワークを削除] をクリックします。

gcloud

gcloud compute networks subnets delete tier-1 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks subnets delete tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

Host サービス エージェント ユーザーのロールを削除する

2 つのサービス プロジェクトから Host サービス エージェント ユーザーのロールを削除します。

コンソール

  1. Google Cloud コンソールで [IAM] ページに移動します。

    [IAM] に移動

  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。

  3. メンバーのリストから、service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com に Kubernetes Engine Host サービス エージェント ユーザーのロールが付与されていることを示す行を選択します。

  4. service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com に Kubernetes Engine Host サービス エージェント ユーザーのロールが付与されていることを示す行を選択します。

  5. [アクセス権を削除] をクリックします。

gcloud

  1. 1 番目のサービス プロジェクトの GKE サービス アカウントから Host サービス エージェント ユーザーのロールを削除します。

    gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

  2. 2 番目のサービス プロジェクトの GKE サービス アカウントから Host サービス エージェント ユーザーのロールを削除します。

    gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

トラブルシューティング

権限の拒否

症状: 

Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google
Compute Engine: Required 'compute.projects.get' permission for
'projects/HOST_PROJECT_ID
考えられる原因:

  • ホスト プロジェクトで Kubernetes Engine API が有効になっていません。

  • ホスト プロジェクトの GKE サービス アカウントが存在しません。たとえば、削除された可能性があります。

  • ホスト プロジェクトの GKE サービス アカウントに、ホスト プロジェクトにおける Kubernetes Engine サービス エージェント（container.serviceAgent）のロールが付与されていません。バインディングが誤って削除された可能性があります。

  • サービス プロジェクトの GKE サービス アカウントに、ホスト プロジェクトにおけるホスト サービス エージェント ユーザーのロールが付与されていません。

問題を解決するには: ホスト プロジェクトの GKE サービス アカウントが存在するかどうかを確認します。存在しない場合は、次の操作を行います。

  • ホスト プロジェクトで Kubernetes Engine API が有効になっていない場合は、有効にします。これにより、ホスト プロジェクトの GKE サービス アカウントが作成され、ホスト プロジェクトの GKE サービス アカウントに Kubernetes Engine サービス エージェント（container.serviceAgent）ロールが付与されます。

  • つまり、ホスト プロジェクトで Kubernetes Engine API が有効になっている場合は、ホスト プロジェクトの GKE サービス アカウントが削除されたか、ホスト プロジェクトにおいて Kubernetes Engine サービス エージェント（container.serviceAgent）ロールを付与されていません。GKE サービス アカウントまたはロールのバインディングを復元するには、Kubernetes Engine API を無効にしてから再度有効にする必要があります。詳細については、Google Kubernetes Engine のトラブルシューティングをご覧ください。

次のステップ