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

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

概要

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

共有 VPC はゾーンクラスタとリージョン クラスタの両方で使用できます。共有 VPC を使用するクラスタはレガシー ネットワークを使用できません。そのため、エイリアス IP を有効にする必要があります。

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

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

サンプルについて

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

このガイドの例では、一般的な手順を説明するため、特定の名前とアドレス範囲を使用しています。名前やアドレス範囲は、必要に応じて変更できます。また、演習では us-central1 リージョンと us-central1-a ゾーンを使用します。リージョンとゾーンも、必要に応じて変更できます。

始める前に

共有 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 ツールまたは Google Cloud Console を使用します。

Console

  1. Google Cloud Console のホームページに移動します。

    ホームページに移動

  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

プロジェクト内で Google Kubernetes Engine API を有効にする

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

Google Kubernetes Engine API を有効にするには、Google Cloud Console または gcloud ツールを使用します。

Console

  1. Cloud Console の [API とサービス] ダッシュボードにアクセスします。
    API ダッシュボードに移動
  2. プロジェクト選択ツールで、ホスト プロジェクトとして使用するプロジェクトを選択します。
  3. API のリストに [Kubernetes Engine API] が含まれている場合、この API はすでに有効にされているので、操作は必要ありません。リストに含まれていない場合は、[API とサービスの有効化] をクリックします。Kubernetes Engine API を検索します。[Kubernetes Engine API] カードをクリックし、[有効にする] をクリックします。
  4. サービス プロジェクトとして使用するプロジェクトごとに、上記の手順を繰り返します。オペレーションごとに完了するまで時間がかかる場合があります。

gcloud

3 つのプロジェクトに対して Google Kubernetes Engine 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 つのセカンダリ アドレス範囲を作成します。

Console

  1. Cloud Console の [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. プロジェクト選択ツールで、ホスト プロジェクトを選択します。
  3. [VPC ネットワークを作成] をクリックします。
  4. [名前] で「shared-net」と入力します。
  5. [サブネット作成モード] で [カスタム] を選択します。
  6. [新しいサブネット] ボックスの [名前] に「tier-1」を入力します。
  7. [リージョン] で、us-central1 を選択します。
  8. [IP アドレス範囲] に「10.0.4.0/22」と入力します。
  9. [セカンダリ IP 範囲を作成する] をクリックします。[サブネット範囲の名前] に「tier-1-services」と入力し、[セカンダリ IP の範囲] に「10.0.32.0/20」と入力します。
  10. [IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「tier-1-pods」と入力し、[セカンダリ IP の範囲] に「10.4.0.0/14」と入力します。
  11. [サブネットを追加] をクリックします。
  12. [名前] に「tier-2」と入力します。
  13. [リージョン] で、us-central1 を選択します。
  14. [IP アドレス範囲] に「172.16.4.0/22」と入力します。
  15. [セカンダリ IP 範囲を作成する] をクリックします。[サブネット範囲の名前] に「tier-2-services」と入力し、[セカンダリ IP の範囲] に「172.16.16.0/20」と入力します。
  16. [IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「tier-2-pods」と入力し、[セカンダリ IP の範囲] に「172.20.0.0/14」と入力します。
  17. [作成] をクリックします。

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 us-central1 \
        --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 us-central1 \
        --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

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

サービス プロジェクトは 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. サービス プロジェクトに属するサービス アカウントに適切な Cloud IAM ロールを付与します。
    • 最初のサービス プロジェクトで、ホスト プロジェクトの tier-1 サブネットに対する Compute Network User ロールを 2 つのサービス アカウントに付与します。
    • 2 番目のサービス プロジェクトで、ホスト プロジェクトの tier-2 サブネットに対する Compute Network User ロールを 2 つのサービス プロジェクトに付与します。

Console

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

  1. Cloud Console の [共有 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-project2-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 を有効にします。

    gcloud 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 サブネットの Cloud IAM ポリシーを取得します。

    gcloud compute networks subnets get-iam-policy tier-1 \
       --project host-project-id \
       --region us-central1

    出力には 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 サブネットに Cloud IAM ポリシーを設定します。

    gcloud compute networks subnets set-iam-policy tier-1 \
        tier-1-policy.yaml \
        --project host-project-id \
        --region us-central1

  7. tier-2 サブネットの Cloud IAM ポリシーを取得します。

    gcloud compute networks subnets get-iam-policy tier-2 \
        --project host-project-id \
        --region us-central1

    出力には 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 サブネットに Cloud IAM ポリシーを設定します。

    gcloud compute networks subnets set-iam-policy tier-2 \
        tier-2-policy.yaml \
        --project host-project-id \
        --region us-central1

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

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

サービス アカウント ロール サブネット
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 ネットワーク ユーザー 特定のサブネットまたはホスト プロジェクト全体
service-service-project-num@container-engine-robot.iam.gserviceaccount.com Host サービス エージェント ユーザー ホスト プロジェクトの GKE サービス アカウント

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

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

service-service-project-num@container-engine-robot.iam.gserviceaccount.com

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

Console

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

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 範囲が使用できない場合もあります。クラスタを作成する際に Cloud Console を使用するか gcloud コマンドライン ツールを使用するかに関係なく、使用可能な IP 範囲を指定する必要があります。

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

gcloud コマンドライン ツールを使用すると、プロジェクトで使用可能なサブネットとセカンダリ IP 範囲を確認できます。

gcloud

    gcloud container subnets list-usable \
        --project service-project-id \
        --network-project host-project-id

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

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

    PROJECT   REGION       NETWORK      SUBNET          RANGE
    xpn-host  us-central1  empty-vpc    empty-subnet    10.0.0.0/21
    xpn-host  us-east1     some-vpc     some-subnet     10.0.0.0/19
        ┌──────────────────────┬───────────────┬─────────────────────────────┐
        │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
        ├──────────────────────┼───────────────┼─────────────────────────────┤
        │ pods-range           │ 10.2.0.0/21   │ usable for pods or services │
        │ svc-range            │ 10.1.0.0/21   │ usable for pods or services │
        └──────────────────────┴───────────────┴─────────────────────────────┘
    xpn-host  us-central1  shared-net   tier-2          172.16.4.0/22
        ┌──────────────────────┬────────────────┬─────────────────────────────┐
        │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE  │            STATUS           │
        ├──────────────────────┼────────────────┼─────────────────────────────┤
        │ tier-2-services      │ 172.16.16.0/20 │ usable for pods or services │
        │ tier-2-pods          │ 172.20.0.0/14  │ usable for pods or services │
        └──────────────────────┴────────────────┴─────────────────────────────┘
    xpn-host  us-central1  shared-net   tier-1          10.0.4.0/22
        ┌──────────────────────┬───────────────┬─────────────────────────────┐
        │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
        ├──────────────────────┼───────────────┼─────────────────────────────┤
        │ tier-1-services      │ 10.0.32.0/20  │ unusable                    │
        │ tier-1-pods          │ 10.4.0.0/14   │ usable for pods             │
        │ tier-1-extra         │ 10.8.0.0/14   │ usable for pods or services │
        └──────────────────────┴───────────────┴─────────────────────────────┘

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

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

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

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

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

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

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

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

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

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

  4. [クラスタ名] に「tier-1-cluster」と入力します。

  5. [ロケーション タイプ] で [ゾーン] を選択します。

  6. [ゾーン] のプルダウン リストから、[us-central1-a] を選択します。

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

  8. [VPC ネイティブのトラフィック ルーティングを有効にする（エイリアス IP を使用）] を選択します。

  9. [セカンダリ範囲を自動的に作成する] をオフにします。

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

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

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

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

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

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

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

  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 tier-1-cluster \
        --project service-project-1-id \
        --zone=us-central1-a \
        --enable-ip-alias \
        --network projects/host-project-id/global/networks/shared-net \
        --subnetwork projects/host-project-id/regions/us-central1/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-...  us-central1-a  ... 10.0.4.2
    gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.3
    gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.4

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

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

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

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

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

  4. [クラスタ名] に「tier-2-cluster」と入力します。

  5. [ロケーション タイプ] で [ゾーン] を選択します。

  6. [ゾーン] のプルダウン リストから、[us-central1-a] を選択します。

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

  8. [VPC ネイティブのトラフィック ルーティングを有効にする（エイリアス IP を使用）] を選択します。

  9. [セカンダリ範囲を自動的に作成する] をオフにします。

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

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

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

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

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

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

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

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

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

gcloud

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

    gcloud container clusters create tier-2-cluster \
        --project service-project-2-id \
        --zone=us-central1-a \
        --enable-ip-alias \
        --network projects/host-project-id/global/networks/shared-net \
        --subnetwork projects/host-project-id/regions/us-central1/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 serviceproject-2-id

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

    NAME                    ZONE           ... INTERNAL_IP
    gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.2
    gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.3
    gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.4

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

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

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

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

Console

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

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

  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 を使用してノードに接続します。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

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

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

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

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

  5. ノードのリストに示されているノードの内部 IP アドレスをメモします。これらのアドレスは 10.0.4.0/22 の範囲内にあります。

  6. いずれかのノードで [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 us-central1-a \

node-name は、いずれかのノードの名前です。

ノード間で 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 に付与する場合は、次のいずれかを行います。

  • ホスト プロジェクトで Compute Security Admin ロールを付与します。
  • compute.firewalls.* 権限と compute.networks.updatePolicy 権限を含むカスタムロールをサービス プロジェクトの GKE サービス アカウントに付与します。

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

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

限定公開クラスタでも共有 VPC を使用できます。特別な設定は必要ありません。ただし、マスター CIDR 範囲が、共有ネットワーク内で予約されている他の範囲と重複しないようにする必要があります。

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

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

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

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

  3. [クラスタ名] に「private-cluster-vpc」と入力します。

  4. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  5. [限定公開クラスタ] をクリックします。

  6. [外部 IP アドレスを使用したマスターへのアクセス] チェックボックスがオンになっていることを確認します。

  7. [マスター IP 範囲] を 172.16.0.16/28 に設定します。

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

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

  10. [VPC ネイティブのトラフィック ルーティングを有効にする（エイリアス IP を使用）] チェックボックスが選択されていることを確認します。

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

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

gcloud

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

gcloud container clusters create private-cluster-vpc \
        --project project-id \
        --enable-ip-alias \
        --network projects/host-project/global/networks/shared-net \
        --subnetwork shared-subnetwork \
        --cluster-secondary-range-name c0-pods \
        --services-secondary-range-name c0-services \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.0/28

IP アドレスの予約

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

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

gcloud コマンドライン ツールで次のコマンドを使用して、内部 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 つのクラスタを削除します。

Console

  1. Cloud Console で 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 us-central1-a

    gcloud container clusters delete tier-2-cluster \
        --project service-project-2-id \
        --zone us-central1-a

共有 VPC を無効にする

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

Console

  1. Cloud Console の [共有 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

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

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

Console

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

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

  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

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

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

Console

  1. Cloud Console の [VPC ネットワーク] ページに移動します。

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

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

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

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

gcloud

    gcloud compute networks subnets delete tier-1 \
        --project host-project-id \
        --region us-central1

    gcloud compute networks subnets delete tier-2 \
        --project host-project-id \
        --region us-central1

    gcloud compute networks delete shared-net --project host-project-id

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

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

Console

  1. Cloud Console で Cloud IAM ページに移動します。

    Cloud 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

既知の問題

ロードバランサ用のファイアウォール イベントの作成

Kubernetes サービス アカウントにファイアウォールの管理権限が付与されていない場合、Kubernetes Service コントローラが必須のファイアウォール変更に対してイベントを作成しない可能性があります。これは、Kubernetes バージョン 1.9 以前での RBAC 権限の問題によるものです。サービス コントローラにはイベントを起動する機能がありません。

この問題を解決するには、こちらの YAML ファイルを適用してください。これらのファイルには、イベントの作成を許可する RBAC ポリシーが含まれています。

Kubernetes 1.10 以降をベースとしたクラスタには、これらの RBAC ポリシーがすでに適用されています。

トラブルシューティング

アクセスの拒否

症状:

    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 が有効になっていません。

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

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

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

  • ホスト プロジェクトで Kubernetes Engine API が有効になっていない場合は、有効にします。これにより、ホスト プロジェクトに Google Kubernetes Engine サービス アカウントが作成されます。

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

次のステップ