このガイドでは、共有 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 でクラスタを設定する前に、次のことを行います。
- 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
ツールまたは Google Cloud Console を使用します。
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 サービス アカウントが必要です。
Google Kubernetes Engine API を有効にするには、Google Cloud Console または gcloud
ツールを使用します。
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 つのサブネットを作成します。- サブネットごとに、Service 用と Pod 用の 2 つのセカンダリ アドレス範囲を作成します。
Console
- Cloud Console の [VPC ネットワーク] ページに移動します。
[VPC ネットワーク] ページに移動 - プロジェクト選択ツールで、ホスト プロジェクトを選択します。
- add_box [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 サービス アカウントと 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 管理者ロールが定義されている必要があります。
このセクションでは、次のタスクを行います。
- ホスト プロジェクトで共有 VPC を有効にします。
- 2 つのサービス プロジェクトをホスト プロジェクトに接続します。
- サービス プロジェクトに属するサービス アカウントに適切な IAM ロールを付与します。
- 最初のサービス プロジェクトで、ホスト プロジェクトの
tier-1
サブネットに対するCompute Network User
ロールを 2 つのサービス アカウントに付与します。 - 2 番目のサービス プロジェクトで、ホスト プロジェクトの
tier-2
サブネットに対するCompute Network User
ロールを 2 つのサービス プロジェクトに付与します。
- 最初のサービス プロジェクトで、ホスト プロジェクトの
Console
次の操作を行って共有 VPC を有効にし、サービス プロジェクトを接続してロールを付与します。
Cloud Console の [共有 VPC] ページに移動します。
プロジェクト選択ツールで、ホスト プロジェクトを選択します。
[共有 VPC を設定] をクリックします。[ホスト プロジェクトを有効にする] 画面が表示されます。
[保存して続行] をクリックします。[サブネットを選択する] ページが表示されます。
[共有モード] で、[個々のサブネット] を選択します。
[共有するサブネット] で、[tier-1] と [tier-2] をオンにします。その他すべてのチェックボックスをオフにします。
[続行] をクリックします。[権限を付与する] ページが表示されます。
[サービス プロジェクトの接続] で、1 番目のサービス プロジェクトと 2 番目のサービス プロジェクトをオンにします。[サービス プロジェクトの接続] のその他すべてのチェックボックスをオフにします。
[Kubernetes Engine へのアクセス] で、[有効] をオンにします。
[保存] をクリックします。新しいページが表示されます。
[個々のサブネットに対する権限] で、[tier-1] をオンにします。
右ペインで、2 番目のサービス プロジェクトに属するサービス アカウントを削除します。つまり、service-project2-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
サブネットの IAM ポリシーを取得します。gcloud 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
サブネットの IAM ポリシーを設定します。gcloud compute networks subnets set-iam-policy tier-1 \ tier-1-policy.yaml \ --project host-project-id \ --region us-central1
以下のとおり、
tier-2
サブネットの IAM ポリシーを取得します。gcloud 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
サブネットの IAM ポリシーを設定します。gcloud compute networks subnets set-iam-policy tier-2 \ tier-2-policy.yaml \ --project host-project-id \ --region us-central1
GKE クラスタでホスト プロジェクトのファイアウォール リソースを作成して管理するには、次のいずれかのタスクを実行します。
- ホスト プロジェクトで
Compute Security Admin
ロールを付与します。 compute.firewalls.*
権限とcompute.networks.updatePolicy
権限を含むカスタムロールをサービス プロジェクトの 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 | ネットワーク ユーザー | 特定のサブネットまたはホスト プロジェクト全体 |
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
最初のプロジェクトで、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 番目のプロジェクトで、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 範囲を指定する必要があります。
新しいクラスタのサービスには、まだ使用されていない IP 範囲のみを使用できます。新しいクラスタのポッドには、まだ使用されていない IP 範囲か、他のクラスタのポッドと共有する 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
Cloud Console で Google Kubernetes Engine のメニューに移動します。
プロジェクト選択ツールで、1 番目のサービス プロジェクトを選択します。
add_box [作成] をクリックします。
[名前] に「
tier-1-cluster
」と入力します。[ロケーション タイプ] で [ゾーン] を選択します。
[ゾーン] のプルダウン リストから、[us-central1-a] を選択します。
ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] チェックボックスをオンにします。
[セカンダリ範囲を自動的に作成する] チェックボックスをオフにします。
[共有ネットワーク(共有元のホスト プロジェクト)] を選択します。
[ネットワーク] で [shared-net] を選択します。
[ノードのサブネット] で [tier-1] を選択します。
[Pod のセカンダリ CIDR 範囲] で [tier-1-pods] を選択します。
[Service のセカンダリ 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 番目のサービス プロジェクト内で 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
作成が完了したら、クラスタノードの内部 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 番目のサービス プロジェクト内でクラスタを作成する
2 番目のサービス プロジェクトでクラスタを作成するには、gcloud
ツールまたは Google Cloud Console を使用して次の操作を行います。
Console
Cloud Console で Google Kubernetes Engine のメニューに移動します。
プロジェクト選択ツールで、2 番目のサービス プロジェクトを選択します。
add_box [作成] をクリックします。
[名前] に「
tier-2-cluster
」と入力します。[ロケーション タイプ] で [ゾーン] を選択します。
[ゾーン] のプルダウン リストから、[us-central1-a] を選択します。
ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] チェックボックスをオンにします。
[セカンダリ範囲を自動的に作成する] チェックボックスをオフにします。
[共有ネットワーク(共有元のホスト プロジェクト)] を選択します。
[ネットワーク] で [shared-net] を選択します。
[ノードのサブネット] で [tier-2] を選択します。
[Pod のセカンダリ CIDR 範囲] で [tier-2-pods] を選択します。
[Service のセカンダリ 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 番目のサービス プロジェクト内で 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
作成が完了したら、クラスタノードの内部 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
ファイアウォール ルールの作成
ネットワークへのトラフィックの送信とネットワーク内のクラスタ間でのトラフィックの送信を許可するには、ファイアウォール ルールを作成する必要があります。ここでは、ファイアウォール ルールの作成と更新の方法について説明します。
- ノードへの SSH 接続を許可するファイアウォール ルールを作成する: SSH を使用してクラスタの外部からのトラフィックを許可するファイアウォール ルールを作成します。
ノード間で ping を実行するようにファイアウォール ルールを更新する: クラスタ間で ICMP トラフィックを許可するようにファイアウォール ルールを更新します。
例として SSH と ICMP を使用していますが、アプリケーション固有のネットワーク要件を満たすようにファイアウォール ルールを作成する必要があります。
ノードへの SSH 接続を許可するファイアウォール ルールを作成する
ホスト プロジェクトで、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 を使用してノードに接続する
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
コマンドが成功します。
追加のファイアウォール ルールを作成する
クラスタ内のノード、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
Cloud Console で Google Kubernetes Engine のメニューに移動します。
add_box [作成] をクリックします。
[名前] に「
private-cluster-vpc
」と入力します。ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[限定公開クラスタ] を選択します。
[外部 IP アドレスを使用したマスターへのアクセス] チェックボックスがオンになっていることを確認します。
[マスター IP 範囲] を
172.16.0.16/28
に設定します。[ネットワーク] プルダウン リストで、以前に作成した VPC ネットワークを選択します。
[ノードのサブネット] プルダウン リストで、以前に作成した共有サブネットを選択します。
[VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] チェックボックスが選択されていることを確認します。
必要に応じてクラスタを構成します。
[作成] をクリックします。
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
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 を無効にする
ホスト プロジェクト内で共有 VPC を無効にします。
Console
Cloud Console の [共有 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
共有ネットワークを削除する
作成した共有ネットワークを削除します。
Console
Cloud Console の [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 サービス エージェント ユーザーのロールを削除する
2 つのサービス プロジェクトから Host サービス エージェント ユーザーのロールを削除します。
Console
Cloud Console で 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
トラブルシューティング
アクセスの拒否
症状:
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 サービス アカウントが存在しません。たとえば、削除された可能性があります。
ホスト プロジェクトの Google Kubernetes Engine サービス アカウントは、ホスト プロジェクトにおいて Kubernetes Engine サービス エージェント(
container.serviceAgent
)ロールを持ちません。バインディングが誤って削除された可能性があります。サービス プロジェクトの Kubernetes Engine サービス アカウントに、ホスト プロジェクトに対する Host サービス エージェント ユーザーのロールが付与されていません。
問題を解決するには: ホスト プロジェクトの Google Kubernetes Engine サービス アカウントが存在するかどうかを確認します。存在しない場合は、次の操作を行います。
ホスト プロジェクトで Kubernetes Engine API が有効になっていない場合は、有効にします。これにより、ホスト プロジェクトの Google Kubernetes Engine サービス アカウントが作成され、ホスト プロジェクトの Google Kubernetes Engine サービス アカウントに Kubernetes Engine サービス エージェント(
container.serviceAgent
)ロールが付与されます。つまり、ホスト プロジェクトで Kubernetes Engine API が有効になっている場合は、ホスト プロジェクトの Google Kubernetes Engine サービス アカウントが削除されたか、ホスト プロジェクトにおいて Kubernetes Engine サービス エージェント(
container.serviceAgent
)ロールを持ちません。Google Kubernetes Engine サービス アカウントまたはロールのバインディングを復元するには、Kubernetes Engine API を無効にしてから再度有効にする必要があります。詳細については、Google Kubernetes Engine のトラブルシューティングをご覧ください。