このページでは、共有 Virtual Private Cloud（VPC）を使用する 2 つの Google Kubernetes Engine クラスタを、それぞれ異なるプロジェクト内で作成する方法について説明します。GKE ネットワーキングに関する一般的な情報については、ネットワークの概要をご覧ください。
概要
共有 VPC を使用する場合は、1 つのプロジェクトをホスト プロジェクトとして指定します。ホスト プロジェクトには他のプロジェクト（サービス プロジェクト）を接続できます。ホスト プロジェクト内には、ネットワーク、サブネット、セカンダリ アドレス範囲、ファイアウォール ルールなどのネットワーク リソースを作成します。そして選択したサブネットを、セカンダリ アドレス範囲を含め、サービス プロジェクトと共有します。 サービス プロジェクト内で実行されるコンポーネントは、共有 VPC を使用して他のサービス プロジェクト内で実行中のコンポーネントと通信できます。
共有 VPC はゾーンクラスタとリージョン クラスタの両方で使用できます。共有 VPC を使用するクラスタはレガシー ネットワークを使用できません。そのため、エイリアス IP を有効にする必要があります。
共有 VPC クラスタは、新しいクラスタの作成時に構成できます。既存のクラスタについては、Google Kubernetes Engine では共有 VPC モデルへの変換をサポートしていません。
共有 VPC を使用する場合、特定の割り当てと制限が適用されます。たとえば、プロジェクトに含まれるネットワークの数に適用される割り当てや、ホスト プロジェクトに接続できるサービス プロジェクトの数に適用される制限があります。詳細については、割り当てと制限をご覧ください。
このトピックの例では、共有 VPC の概要で説明されている 2 層のウェブ アプリケーションを対象としたインフラストラクチャをセットアップします。
このページの例では、特定の名前とアドレス範囲を使用して、一般的な手順を説明します。名前やアドレス範囲は、必要に応じて変更できます。また、演習では us-central1 リージョンと us-central1-a ゾーンを使用します。リージョンとゾーンも、必要に応じて変更できます。
始める前に
このタスクを行うには、Google Cloud 組織が必要です。さらにその組織内には、3 つの Google Cloud プロジェクトがなければなりません。
共有 VPC で使用される各種 Cloud Identity and Access Management（Cloud IAM）役割を含む共有 VPC のコンセプトに精通している必要があります。このページの手順は、共有 VPC 管理者が実行する必要があります。
組織、フォルダ、プロジェクトに適用可能な組織ポリシーの制約を理解していることを確認してください。組織ポリシー管理者が、どのプロジェクトが共有 VPC ホストになれるのかを制限する制約、またはどのサブネットが共有できるのかを制限する制約を定義した可能性があります。詳細については、組織ポリシーの制約をご覧ください。
このトピックの演習を行う前に、ホスト プロジェクトにするプロジェクトを 1 つ選択し、サービス プロジェクトにするプロジェクトを 2 つ選択します。各プロジェクトには名前、ID、番号が付けられます。場合によっては、名前と ID が同じこともあります。このトピックでは、次のわかりやすい名前でプロジェクトを参照します。
- ホスト プロジェクト
- 1 番目のサービス プロジェクト
- 2 番目のサービス プロジェクト
このトピックでは、次のプレースホルダを使用してプロジェクト ID とプロジェクト番号を参照します。
- [HOST_PROJECT_ID] は、ホスト プロジェクトのプロジェクト ID です。
- [HOST_PROJECT_NUM] は、ホスト プロジェクトのプロジェクト番号です。
- [SERVICE_PROJECT_1_ID] は、1 番目のサービス プロジェクトのプロジェクト ID です。
- [SERVICE_PROJECT_1_NUM] は、1 番目のサービス プロジェクトのプロジェクト番号です。
- [SERVICE_PROJECT_2_ID] は、2 番目のサービス プロジェクトのプロジェクト ID です。
- [SERVICE_PROJECT_2_NUM] は、2 番目のサービス プロジェクトのプロジェクト番号です。
プロジェクト ID とプロジェクト番号を見つける
Console
- Google Cloud Console のホームページに移動します。
ホームページに移動 - プロジェクト選択ツールで、ホスト プロジェクトとして使用するプロジェクトを選択します。
- [プロジェクト情報] で、プロジェクトの名前、ID、番号を確認します。後で使用できるように、ID と番号をメモします。
- サービス プロジェクトとして使用するプロジェクトのそれぞれについて、上記の手順を繰り返します。
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 サービス アカウントが必要です。
Console
- Cloud Console の [API とサービス] ダッシュボードにアクセスします。
API ダッシュボードに移動 - プロジェクト選択ツールで、ホスト プロジェクトとして使用するプロジェクトを選択します。
- API のリストに [Kubernetes Engine API] が含まれている場合、この API はすでに有効にされているので、操作は必要ありません。リストに含まれていない場合は、[API とサービスの有効化] をクリックします。
Kubernetes Engine APIを検索します。[Kubernetes Engine API] カードをクリックし、[有効にする] をクリックします。 - サービス プロジェクトとして選択したプロジェクトごとに、上記の手順を繰り返します。
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 つのサブネットを作成する
ホスト プロジェクト内で、shared-net という名前のネットワークを作成します。次に、それぞれ tier-1、tier-2 という名前の 2 つのサブネットを作成します。サブネットごとに、サービス用とポッド用の 2 つのセカンダリ アドレス範囲を作成します。
Console
- Cloud Console の [VPC ネットワーク] ページに移動します。
[VPC ネットワーク] ページに移動 - プロジェクト選択ツールで、ホスト プロジェクトを選択します。
- [VPC ネットワークを作成] をクリックします。
- [名前] で「
shared-net」と入力します。 - [サブネット作成モード] で [カスタム] を選択します。
- [新しいサブネット] ボックスの [名前] に「
tier-1」を入力します。 - [リージョン] で、us-central1 を選択します。
- [IP アドレス範囲] に「
10.0.4.0/22」と入力します。 - [セカンダリ IP 範囲を作成する] をクリックします。[サブネット範囲の名前] に「
tier-1-services」と入力し、[セカンダリ IP の範囲] に「10.0.32.0/20」と入力します。 - [IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「
tier-1-pods」と入力し、[セカンダリ IP の範囲] に「10.4.0.0/14」と入力します。 - [サブネットを追加] をクリックします。
- [名前] に「
tier-2」と入力します。 - [リージョン] で、us-central1 を選択します。
- [IP アドレス範囲] に「
172.16.4.0/22」と入力します。 - [セカンダリ IP 範囲を作成する] をクリックします。[サブネット範囲の名前] に「
tier-2-services」と入力し、[セカンダリ IP の範囲] に「172.16.16.0/20」と入力します。 - [IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「
tier-2-pods」と入力し、[セカンダリ IP の範囲] に「172.20.0.0/14」と入力します。 - [作成] をクリックします。
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 サービス アカウントの名前は、次の形式になっています。
- service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com
- service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com
2 つのサービス プロジェクト内での Google API サービス アカウントの名前は、次の形式になっています。
- [SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com
- [SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com
共有 VPC を有効にして役割を付与する
ホスト プロジェクト内で共有 VPC を有効にし、2 つのサービス プロジェクトをホスト プロジェクトに接続します。次に、サービス プロジェクトに属するサービス アカウントに適切な役割を付与します。
Console
次の手順に従って共有 VPC を有効にし、サービス プロジェクトを作成して役割を付与します。
- Cloud Console の [共有 VPC] ページに移動します。
[共有 VPC] ページに移動 - プロジェクト選択ツールで、ホスト プロジェクトを選択します。
- [共有 VPC を設定] をクリックします。
[ホスト プロジェクトを有効にする] 画面が表示されます。 - [保存して続行] をクリックします。
[サブネットを選択する] ページが表示されます。 - [共有モード] で、[個々のサブネット] を選択します。
- [共有するサブネット] で、[tier-1] と [tier-2] をオンにします。その他すべてのチェックボックスをオフにします。
- [続行] をクリックします。
[権限を付与する] ページが表示されます。 - [サービス プロジェクトの接続] で、1 番目のサービス プロジェクトと 2 番目のサービス プロジェクトをオンにします。[サービス プロジェクトの接続] のその他すべてのチェックボックスをオフにします。
- [Kubernetes Engine へのアクセス] で、[有効] をオンにします。
- [保存] をクリックします。
新しいページが表示されます。 - [個々のサブネットに対する権限] で、[tier-1] をオンにします。
- 右ペインで、2 番目のサービス プロジェクトに属するサービス アカウントを削除します。つまり、[SERVICE_PROJECT_2_NUM] を含むサービス アカウントをすべて削除します。
- 右ペインで、1 番目のサービス プロジェクトに属する Kubernetes Engine サービス アカウントと Google API サービス アカウントの名前を見つけます。これらのサービス アカウントの名前が両方ともリストに含まれていることを確認します。いずれか一方がリストに含まれていない場合は、[メンバーを追加] でそのサービス アカウントの名前を入力し、[追加] をクリックします。
- 中央ペインの [個々のサブネットに対する権限] で、[tier-2] をオンにし、[tier-1] をオフにします。
- 右ペインで、1 番目のサービス プロジェクトに属するサービス アカウントを削除します。つまり、[SERVICE_PROJECT_1_NUM] を含むサービス アカウントをすべて削除します。
- 右ペインで、2 番目のサービス プロジェクトに属する Kubernetes Engine サービス アカウントと Google API サービス アカウントの名前を見つけます。これらのサービス アカウントの名前が両方ともリストに含まれていることを確認します。いずれか一方がリストに含まれていない場合は、[メンバーを追加] でそのサービス アカウントの名前を入力し、[追加] をクリックします。
gcloud
ホスト プロジェクト内で共有 VPC を有効にします。
gcloud compute shared-vpc enable [HOST_PROJECT_ID]
1 番目のサービス プロジェクトをホスト プロジェクトに接続します。
gcloud compute shared-vpc associated-projects add \
[SERVICE_PROJECT_1_ID] \
--host-project [HOST_PROJECT_ID]
2 番目のサービス プロジェクトをホスト プロジェクトに接続します。
gcloud compute shared-vpc associated-projects add \
[SERVICE_PROJECT_2_ID] \
--host-project [HOST_PROJECT_ID]
tier-1 サブネットの Cloud IAM ポリシーを取得します。
gcloud beta compute networks subnets get-iam-policy tier-1 \ --project [HOST_PROJECT_ID] \ --region us-central1
出力には etag フィールドが含まれます。etag の値をメモします。
このコンテンツを含むファイルを 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 の値です。
tier-1 サブネットの Cloud IAM ポリシーを設定します。
gcloud beta compute networks subnets set-iam-policy tier-1 \
tier-1-policy.yaml \
--project [HOST_PROJECT_ID] \
--region us-central1
次に、tier-2 サブネットの Cloud IAM ポリシーを取得します。
gcloud beta compute networks subnets get-iam-policy tier-2 \ --project [HOST_PROJECT_ID] \ --region us-central1
出力には etag フィールドが含まれます。etag の値をメモします。
このコンテンツを含むファイルを 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 の値です。
tier-2 サブネットの Cloud IAM ポリシーを設定します。
gcloud beta compute networks subnets set-iam-policy tier-2 \
tier-2-policy.yaml \
--project [HOST_PROJECT_ID] \
--region us-central1
上記の手順の目的は、4 つのサービス アカウントに適切な Cloud IAM 役割を付与することです。1 番目のサービス プロジェクト内の 2 つのサービス アカウントには、ホスト プロジェクトの tier-1 サブネットに対する Compute ネットワーク ユーザーの役割を付与します。2 番目のサービス プロジェクト内の 2 つのサービス アカウントには、ホスト プロジェクトの tier-2 サブネットに対する Compute ネットワーク ユーザーの役割を付与します。
サブネットに対して付与する役割の概要
service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com サービス アカウントには、tier-1 サブネットに対する Compute ネットワーク ユーザーの役割を付与します。
[SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com サービス アカウントには、tier-1 サブネットに対する Compute ネットワーク ユーザーの役割を付与します。
service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com サービス アカウントには、tier-2 サブネットに対する Compute ネットワーク ユーザーの役割を付与します。
[SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com サービス アカウントには、tier-2 サブネットに対する Compute ネットワーク ユーザーの役割を付与します。
Host サービス エージェント ユーザーの役割を付与する
各サービス プロジェクトで、GKE サービス アカウントに Host サービス エージェント ユーザーの役割を付与する必要があります。これにより、サービス プロジェクトの GKE サービス アカウントは、ホスト プロジェクトの GKE サービス アカウントを使用して共有ネットワーク リソースを構成できるようになります。
Host サービス エージェント ユーザーの役割は、サービス プロジェクトのサービス アカウントにのみ付与できます。ユーザーに付与することはできません。
Console
Cloud Console を使用している場合は、Host サービス エージェント ユーザー役割を明示的に付与する必要はありません。この役割は、Cloud Console を使用してサービス プロジェクトをホスト プロジェクトに接続したときに自動的に付与されています。
gcloud
1 番目のサービス プロジェクトの GKE サービス アカウントに Host サービス エージェント ユーザーの役割を付与します。この役割は、ホスト プロジェクトに対して付与されます。
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 番目のサービス プロジェクトの GKE サービス アカウントに Host サービス エージェント ユーザーの役割を付与します。この役割は、ホスト プロジェクトに対して付与されます。
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 範囲を確認する
クラスタを作成する際には、クラスタのポッドとサービスに使用するサブネットとセカンダリ IP 範囲を指定する必要があります。いくつかの理由で、IP 範囲が使用できない場合もあります。クラスタを作成する際に Cloud Console を使用するか gcloud コマンドライン ツールを使用するかに関係なく、使用可能な IP 範囲を指定する必要があります。
また、コマンドラインでは、プロジェクトの使用可能なサブネットとセカンダリ 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 │
└──────────────────────┴───────────────┴─────────────────────────────┘
新しいクラスタのサービスには、まだ使用されていない IP 範囲のみを使用できます。新しいクラスタのポッドには、まだ使用されていない IP 範囲か、他のクラスタのポッドと共有する IP 範囲のいずれかを指定できます。GKE によって作成および管理されている IP 範囲はクラスタでは使用できません。
1 番目のサービス プロジェクト内でクラスタを作成する
Console
Cloud Console で Google Kubernetes Engine のメニューに移動します。
プロジェクト選択ツールで、1 番目のサービス プロジェクトを選択します。
[クラスタを作成] をクリックします。
[クラスタ名] に「
tier-1-cluster」と入力します。[ロケーション タイプ] で [ゾーン] を選択します。
[ゾーン] で [us-central1-a] を選択します。
ページの下部にある [詳細オプション] をクリックします。
[VPC ネイティブ] セクションで、[VPC ネイティブを有効にする（エイリアス IP を使用）] を選択します。
[セカンダリ範囲を自動的に作成する] をオフにします。
[共有ネットワーク（共有元のホスト プロジェクト:）] を選択します。
[ノードのサブネット] で [tier-1] を選択します。
[ポッドのセカンダリ CIDR 範囲] で [tier-1-pods] を選択します。
[サービスのセカンダリ CIDR 範囲] で [tier-1-services] を選択します。
[作成] をクリックします。
作成が完了したら、クラスタのリストで [tier-1-cluster] をクリックします。
[ノードプール] で、インスタンス グループの名前をクリックします。たとえば、gke-tier-1-cluster-default-pool-5c5add1f-grp などです。
インスタンスのリストで、ノードの内部 IP アドレスが tier-1 サブネットのプライマリ範囲 10.0.4.0/22 に収まっていることを確認します。
gcloud
1 番目のサービス プロジェクト内でクラスタを作成します。
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
作成が完了したら、クラスタノードの内部 IP アドレスが 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 番目のサービス プロジェクト内でクラスタを作成する
Console
Cloud Console で Google Kubernetes Engine のメニューに移動します。
プロジェクト選択ツールで、2 番目のサービス プロジェクトを選択します。
[クラスタを作成] をクリックします。
[クラスタ名] に「
tier-2-cluster」と入力します。[ロケーション タイプ] で [ゾーン] を選択します。
[ゾーン] で [us-central1-a] を選択します。
ページの下部にある [詳細オプション] をクリックします。
[VPC ネイティブ] セクションで、[VPC ネイティブを有効にする（エイリアス IP を使用）] を選択します。
[セカンダリ範囲を自動的に作成する] をオフにします。
[共有ネットワーク（共有元のホスト プロジェクト:）] を選択します。
[ノードのサブネット] で [tier-2] を選択します。
[ポッドのセカンダリ CIDR 範囲] で [tier-2-pods] を選択します。
[サービスのセカンダリ CIDR 範囲] で [tier-2-services] を選択します。
[作成] をクリックします。
作成が完了したら、クラスタのリストで [tier-2-cluster] をクリックします。
[ノードプール] で、インスタンス グループの名前をクリックします。たとえば、gke-tier-2-cluster-default-pool-5c5add1f-grp などです。
インスタンスのリストで、ノードの内部 IP アドレスが tier-2 サブネットのプライマリ範囲 172.16.4.0/22 に収まっていることを確認します。
gcloud
2 番目のサービス プロジェクト内でクラスタを作成します。
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
作成が完了したら、クラスタノードの内部 IP アドレスが 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-... 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
ファイアウォール ルールの作成
ホスト プロジェクト内で shared-net ネットワークのファイアウォール ルールを作成します。トラフィックの受信を TCP ポート 22 で許可します。これにより、SSH を使用してクラスタノードに接続できるようになります。
Console
Cloud Console の [ファイアウォール] ページに移動します。
プロジェクト選択ツールで、ホスト プロジェクトを選択します。
VPC ネットワークのメニューで、[ファイアウォール ルールを作成] をクリックします。
[名前] に「
my-shared-net-rule」と入力します。[ネットワーク] で [shared-net] を選択します。
[トラフィックの方向] で [上り] をオンにします。
[一致したときのアクション] で [許可] をオンにします。
[ターゲット] で [ネットワーク上のすべてのインスタンス] を選択します。
[ソースフィルタ] で [IP 範囲] を選択します。
[ソース IP の範囲] に「
0.0.0.0/0」と入力します。[プロトコルとポート] で [指定したプロトコルとポート] をオンにします。ボックスに「
tcp:22」と入力します。[作成] をクリックします。
gcloud
共有ネットワークのファイアウォール ルールを作成します。
gcloud compute firewall-rules create my-shared-net-rule \
--project [HOST_PROJECT_ID] \
--network shared-net \
--direction INGRESS \
--allow tcp:22
SSH を使用してノードに接続する
Console
Cloud Console で Google Kubernetes Engine のメニューに移動します。
プロジェクト選択ツールで、1 番目のサービス プロジェクトを選択します。
[tier-1-cluster] をクリックします。
[ノードプール] で、インスタンス グループの名前をクリックします。たとえば、gke-tier-1-cluster-default-pool-faf87d48-grp などです。
ノードのリストに示されているノードの内部 IP アドレスをメモします。これらのアドレスは 10.0.4.0/22 の範囲内にあります。
いずれかのノードで [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 を実行する
SSH コマンドライン ウィンドウで、CoreOS toolbox を起動します。
/usr/bin/toolbox
ツールボックスのシェルで、同じクラスタに含まれる他のいずれかのノードに対して ping を実行します。例:
ping 10.0.4.4
どちらのノードも 10.0.4.0/22 の範囲内にあるため、ping コマンドは成功するはずです。
次に、他のサービス プロジェクト内のクラスタに含まれるノードのいずれかに ping を実行します。例:
ping 172.16.4.3
今回は ping コマンドが失敗します。ファイアウォール ルールでは、Internet Control Message Protocol（ICMP）トラフィックが許可されていないためです。
ツールボックスのシェルではなく通常のコマンド プロンプトで、ICMP を許可するようにファイアウォール ルールを更新します。
gcloud compute firewall-rules update my-shared-net-rule \
--project [HOST_PROJECT_ID] \
--allow tcp:22,icmp
ツールボックスのシェルで、ノードに対して再度 ping を実行します。例:
ping 172.16.4.3
今回は ping コマンドが成功します。
追加のファイアウォール ルールを作成する
クラスタ内のノード、ポッド、サービスの間での通信を許可する追加のファイアウォール ルールを作成できます。たとえば、以下のルールはすべての TCP ポートまたは UDP ポートに対し、tier-1-cluster 内のあらゆるノード、ポッド、サービスからのトラフィックの受信を許可します。
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 内のあらゆるノード、ポッド、サービスからのトラフィックの受信を許可します。
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 役割を付与します。または、サービス プロジェクトの GKE サービス アカウントに対する compute.firewalls.* および compute.networks.updatePolicy 権限を持つカスタム役割を付与することもできます。
Ingress ロードバランサの場合、権限が不十分なために Kubernetes でファイアウォール ルールを変更できない場合は、数分ごとに firewallXPNError イベントが発生します。GLBC 1.4 以降では、Ingress リソースに networking.gke.io/suppress-firewall-xpn-error: "true" アノテーションを追加することで firewallXPNError イベントをミュートできます。このアノテーションは、いつでも削除してミュートを解除できます。
共有 VPC 内に限定公開クラスタを作成する
限定公開クラスタでも共有 VPC を使用できます。特別な設定は必要ありません。ただし、マスター CIDR 範囲が、共有ネットワーク内で予約されている他の範囲と重複しないようにする必要があります。
VPC ネットワークあたりのプライベート GKE クラスタの最大数は、1 つの VPC ネットワークのピアリング接続数に制限されます。
このセクションでは、事前定義された共有 VPC ネットワーク内に private-cluster-vpc という VPC ネイティブ クラスタを作成します。
Console
Cloud Console で Google Kubernetes Engine のメニューに移動します。
[クラスタを作成] をクリックします。
[クラスタ名] に「
private-cluster-vpc」と入力します。メニューの下部にある [詳細オプション] をクリックします。
[VPC ネイティブ] で [VPC ネイティブを有効にする（エイリアス IP を使用）] チェックボックスをオンにします。
[ネットワーク] プルダウン メニューから、前に作成した VPC ネットワークを選択します。
[ノードのサブネット] プルダウン メニューから、前に作成した共有サブネットを選択します。
[ネットワーク セキュリティ] で [限定公開クラスタ] チェックボックスをオンにします。
[外部 IP アドレスを使用したマスターへのアクセス] チェックボックスがオンになっていることを確認します。
[マスター IP 範囲] を
172.16.0.16/28に設定します。必要に応じてクラスタを構成します。次に、[作成] をクリックします。
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/28IP アドレスの予約
共有 VPC クラスタ用に内部 IP アドレスと外部 IP アドレスを予約できます。IP アドレスがサービス プロジェクトに予約されていることを確認してください。
内部 IP アドレスの場合は、この IP アドレスが属するサブネットワークを指定する必要があります。複数のプロジェクトにまたがる IP アドレスを予約するには、サブネットワークを識別できるように完全なリソース URL を使用します。gcloud コマンドライン ツールで次のコマンドを使用して、内部 IP アドレスを予約します。
gcloud compute addresses create [RESERVED_IP_NAME] \
--region=[REGION] \
--subnet=projects/[HOST_PROJECT_ID]/regions/[REGION]/subnetworks/[SUBNETWORK_NAME] \
--addresses=[IP_ADDRESS] \
--project=[SERVICE_PROJECT_ID]
このコマンドを呼び出すには、サブネットワークに対する compute.subnetworks.use 権限が必要です。サブネットワークで発信者に compute.networkUser 役割を付与するか、プロジェクト レベルで compute.subnetworks.use 権限を持つカスタマイズされた役割を発信者に付与できます。
セカンダリ範囲に関する注意事項
所定のサブネット内に作成できるセカンダリ範囲の数は 30 個までです。クラスタごとに、ポッド用とサービス用の 2 つのセカンダリ範囲が必要となります。
既知の問題
ロードバランサ用のファイアウォール イベントの作成
Kubernetes サービス アカウントにファイアウォールの管理権限が付与されていない場合、Kubernetes サービス コントローラが必須のファイアウォール変更に対してイベントを作成しない可能性があります。これは、Kubernetes バージョン 1.9 以前での RBAC 権限の問題によるものです。サービス コントローラにはイベントを起動する機能がありません。
この問題を解決するには、こちらの YAML ファイルを適用してください。これらのファイルには、イベントの作成を許可する RBAC ポリシーが含まれています。
Kubernetes 1.10 以降をベースとしたクラスタには、これらの RBAC ポリシーがすでに適用されています。
クリーンアップ
このページの演習を完了したら、アカウントで不要な請求が発生しないように、以下の手順でリソースを削除します。
クラスタを削除する
Console
Cloud Console で Google Kubernetes Engine のメニューに移動します。
プロジェクト選択ツールで、1 番目のサービス プロジェクトを選択します。
[tier-1-cluster] をオンにしてから [削除] をクリックします。
プロジェクト選択ツールで、2 番目のサービス プロジェクトを選択します。
[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 を無効にする
Console
- Cloud Console の [共有 VPC] ページに移動します。
[共有 VPC] ページに移動 - プロジェクト選択ツールで、ホスト プロジェクトを選択します。
- [共有 VPC を無効にする] をクリックします。
- テキスト ボックスに [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
Cloud Console の [ファイアウォール] ページに移動します。
プロジェクト選択ツールで、ホスト プロジェクトを選択します。
ルールのリストで、[my-shared-net-rule]、[my-shared-net-rule-2]、[my-shared-net-rule-3] をオンにします。
[削除] をクリックします。
gcloud
ファイアウォール ルールを削除します。
gcloud compute firewall-rules delete \
my-shared-net-rule \
my-shared-net-rule-2 \
my-shared-net-rule-3 \
--project [HOST_PROJECT_ID]
shared-net ネットワークを削除する
Console
- Cloud Console の [VPC ネットワーク] ページに移動します。
[VPC ネットワーク] ページに移動 - プロジェクト選択ツールで、ホスト プロジェクトを選択します。
- ネットワークのリストで、[shared-net] をクリックします。
- [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 サービス エージェント ユーザーの役割を削除する
Console
- Cloud Console で Cloud IAM ページに移動します。
Cloud IAM ページに移動 - プロジェクト選択ツールで、ホスト プロジェクトを選択します。
- メンバーのリストで、service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com に Kubernetes Engine Host サービス エージェント ユーザーの役割が付与されていることを確認します。
- また、service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com に Kubernetes Engine Host サービス エージェント ユーザーの役割が付与されていることを確認します。
- [削除] をクリックします。
gcloud
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 番目のサービス プロジェクトの 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
