このページでは、VPC ネイティブ クラスタの一種である限定公開の Google Kubernetes Engine（GKE）クラスタを作成する方法について説明します。限定公開クラスタでは、ノードに内部 IP アドレスのみがあるため、ノードと Pod がデフォルトでインターネットから隔離されています。
ノードの内部 IP アドレスは、クラスタ用に選択したサブネットのプライマリ IP アドレス範囲から取得されます。Pod IP アドレスと Service IP アドレスは、同じサブネットの 2 つのサブネット セカンダリ IP アドレス範囲から取得できます。詳細については、VPC ネイティブ クラスタの IP 範囲をご覧ください。
GKE バージョン 1.14.2 以降では、プライベート範囲（RFC 1918 と他のプライベート範囲を含む）や非公開で使用されるパブリック IP アドレス範囲など、内部 IP アドレス範囲がサポートされています。有効な内部 IP アドレス範囲の一覧については、VPC のドキュメントをご覧ください。
限定公開クラスタの仕組みについて詳しくは、限定公開クラスタをご覧ください。
始める前に
次の手順に進む前に、要件、制約、制限をよく理解してください。
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API を有効にします。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。すでに gcloud CLI をインストールしている場合は、
gcloud components updateを実行して最新のバージョンを取得します。
クラスタを作成するための適切な権限があることを確認します。少なくとも、Kubernetes Engine Cluster 管理者である必要があります。
デフォルト インターネット ゲートウェイへのルートがあることを確認します。
パブリック エンドポイントへのクライアント アクセス権のない限定公開クラスタの作成
このセクションでは、次のリソースを作成します。
private-cluster-0という名前の限定公開クラスタ。このクラスタには限定公開ノードはありますが、パブリック エンドポイントへのクライアント アクセス権はありません。my-net-0という名前のネットワーク。my-subnet-0という名前のサブネット。
コンソール
ネットワークとサブネットを作成する
Google Cloud コンソールで [VPC ネットワーク] ページに移動します。
[add_box VPC ネットワークを作成] をクリックします。
[名前] に「
my-net-0」と入力します。[サブネット作成モード] で [カスタム] を選択します。
[新しいサブネット] セクションの [名前] に「
my-subnet-0」を入力します。[リージョン] リストで、目的のリージョンを選択します。
[IP アドレス範囲] に「
10.2.204.0/22」と入力します。[限定公開の Google アクセス] を [オン] に設定します。
[完了] をクリックします。
[作成] をクリックします。
限定公開クラスタを作成する
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[ 作成] をクリックし、[Standard] セクションまたは [Autopilot] セクションで [構成] をクリックします。
[名前] に
private-cluster-0を指定します。ナビゲーション パネルで [ネットワーキング] をクリックします。
[ネットワーク] リストで [my-net-0] を選択します。
[ノードのサブネット] リストで [my-subnet-0] を選択します。
[限定公開クラスタ] をオンにします。
[外部 IP アドレスを使用してコントロール プレーンにアクセス] チェックボックスをオフにします。
（Autopilot の場合は省略可）: [コントロール プレーンの IP 範囲] を
172.16.0.32/28に設定します。[作成] をクリックします。
gcloud
Autopilot クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create-auto private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-private-nodes \ --enable-private-endpoint
Standard クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --enable-private-endpoint \ --master-ipv4-cidr 172.16.0.32/28
ここで
--create-subnetwork name=my-subnet-0を指定すると、GKE によってmy-subnet-0という名前のサブネットが自動的に作成されます。--enable-master-authorized-networksを指定すると、パブリック エンドポイントへのアクセスが承認された IP アドレス範囲に制限されます。
--enable-ip-aliasは、クラスタを VPC ネイティブにします（Autopilot の場合は不要）。
--enable-private-nodesは、クラスタのノードに外部 IP アドレスがないことを示します。--enable-private-endpointは、クラスタがコントロール プレーン API エンドポイントの内部 IP アドレスを使用して管理されていることを示します。
--master-ipv4-cidr 172.16.0.32/28は、コントロール プレーンの内部 IP アドレス範囲を指定します（Autopilot の場合は任意）。この設定はこのクラスタでは永続的であり、VPC 内で一意であることが必要です。RFC 1918 以外の内部 IP アドレスの使用がサポートされています。
API
公開アクセス可能なコントロール プレーンなしでクラスタを作成するには、privateClusterConfig リソースの enablePrivateEndpoint: true フィールドを指定します。
この時点では、コントロール プレーンにアクセスできる唯一の IP アドレスです。
my-subnet-0のプライマリ範囲。- Pod に使用されるセカンダリ範囲。
たとえば、my-subnet-0 のプライマリ範囲に VM を作成したとします。その VM で、コントロール プレーンの内部 IP アドレスを使用するように kubectl を構成できます。
my-subnet-0 の外部からコントロール プレーンにアクセスする場合は、プライベート エンドポイントにアクセスするために少なくとも 1 つのアドレス範囲を承認する必要があります。
デフォルト ネットワーク内の VM が、クラスタと同じリージョンで my-subnet-0 とは別のサブネットにあるとします。
次に例を示します。
my-subnet-0:10.0.0.0/22- Pod のセカンダリ範囲:
10.52.0.0/14 - VM のアドレス:
10.128.0.3
VM にコントロール プレーンへのアクセスを承認するには、次のコマンドを使用します。
gcloud container clusters update private-cluster-0 \
--enable-master-authorized-networks \
--master-authorized-networks 10.128.0.3/32
パブリック エンドポイントへのアクセスが制限された限定公開クラスタの作成
この構成を使用して限定公開クラスタを作成すると、自動生成されたサブネットまたはカスタム サブネットを使用できます。
自動生成されたサブネットの使用
このセクションでは、private-cluster-1 という名前の限定公開クラスタを作成します。GKE は、このクラスタにクラスタノードのサブネットを自動的に生成します。サブネットでは、限定公開の Google アクセスが有効になっています。サブネット内で、GKE は Pod 用と Service 用の 2 つのセカンダリ範囲を自動的に作成します。
Google Cloud CLI または GKE API を使用できます。
gcloud
Autopilot クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create-auto private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-private-nodes
Standard クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.0/28
ここで
--create-subnetwork name=my-subnet-1を指定すると、GKE によってmy-subnet-1という名前のサブネットが自動的に作成されます。--enable-master-authorized-networksを指定すると、パブリック エンドポイントへのアクセスが承認された IP アドレス範囲に制限されます。
--enable-ip-aliasは、クラスタを VPC ネイティブにします（Autopilot の場合は不要）。
--enable-private-nodesは、クラスタのノードに外部 IP アドレスがないことを示します。
--master-ipv4-cidr 172.16.0.0/28は、コントロール プレーンの内部 IP アドレス範囲を指定します（Autopilot の場合は任意）。この設定はこのクラスタでは永続的であり、VPC 内で一意であることが必要です。RFC 1918 以外の内部 IP アドレスの使用がサポートされています。
API
Cluster API リソースの privateClusterConfig フィールドを指定します。
{
"name": "private-cluster-1",
...
"ipAllocationPolicy": {
"createSubnetwork": true,
},
...
"privateClusterConfig" {
"enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
"enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
"masterIpv4CidrBlock": string # CIDR block for the cluster control plane
"privateEndpoint": string # Output only
"publicEndpoint": string # Output only
}
}
この時点で、クラスタ コントロール プレーンにアクセスできる IP アドレスは次のものに限られます。
my-subnet-1のプライマリ範囲。- Pod に使用されるセカンダリ範囲。
VPC ネットワークの外に、203.0.113.0/29 の範囲のアドレスを持つマシンのグループがあるとします。これらのマシンのパブリック エンドポイントへのアクセスを承認するには、次のコマンドを入力します。
gcloud container clusters update private-cluster-1 \
--enable-master-authorized-networks \
--master-authorized-networks 203.0.113.0/29
コントロール プレーンにアクセスできる唯一の IP アドレスは次のとおりです。
my-subnet-1のプライマリ範囲。- Pod に使用されるセカンダリ範囲。
- 承認したアドレス範囲（
203.0.113.0/29など）。
カスタム サブネットの使用
このセクションでは、次のリソースを作成します。
private-cluster-2という名前の限定公開クラスタ。my-net-2という名前のネットワーク。- クラスタノード用の、プライマリ範囲が
192.168.0.0/20のmy-subnet-2という名前のサブネット。サブネットには、次のセカンダリ アドレス範囲があります。- Pod の IP アドレスには
my-podsを指定します。 - Service の IP アドレスには
my-servicesを指定します。
- Pod の IP アドレスには
コンソール
ネットワーク、サブネット、セカンダリ範囲の作成
Google Cloud コンソールで [VPC ネットワーク] ページに移動します。
[add_box VPC ネットワークを作成] をクリックします。
[名前] に「
my-net-2」と入力します。[サブネット作成モード] で [カスタム] を選択します。
[新しいサブネット] セクションの [名前] に「
my-subnet-2」を入力します。[リージョン] リストで、目的のリージョンを選択します。
[IP アドレス範囲] に「
192.168.0.0/20」と入力します。[セカンダリ IP 範囲を作成する] をクリックします。[サブネット範囲の名前] に「
my-services」と入力し、[セカンダリ IP の範囲] に「10.0.32.0/20」と入力します。[IP の範囲を追加] をクリックします。[サブネット範囲の名前] に「
my-pods」と入力し、[セカンダリ IP の範囲] に「10.4.0.0/14」と入力します。[限定公開の Google アクセス] を [オン] に設定します。
[完了] をクリックします。
[作成] をクリックします。
限定公開クラスタを作成する
サブネットを使用する限定公開クラスタを作成します。
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[ 作成] をクリックし、[Standard] セクションまたは [Autopilot] セクションで [構成] をクリックします。
[名前] に「
private-cluster-2」と入力します。ナビゲーション パネルで [ネットワーキング] をクリックします。
[限定公開クラスタ] をオンにします。
承認済みの外部 IP 範囲からアクセス可能なコントロール プレーンを作成するには、[外部 IP アドレスを使用してコントロール プレーンにアクセス] チェックボックスをオンのままにします。
（Autopilot の場合は省略可）[コントロール プレーンの IP 範囲] を
172.16.0.16/28に設定します。[ネットワーク] リストで、[my-net-2] を選択します。
[ノードのサブネット] リストで [my-subnet-2] を選択します。
[セカンダリ範囲を自動的に作成する] チェックボックスをオフにします。
[Pod のセカンダリ CIDR 範囲] リストで [my-pods] を選択します。
[サービスのセカンダリ CIDR 範囲] リストで [my-services] を選択します。
[コントロール プレーン承認済みネットワークを有効にする] チェックボックスをオンにします。
[作成] をクリックします。
gcloud
ネットワークの作成
まず、クラスタ用のネットワークを作成します。次のコマンドによって、ネットワーク my-net-2 が作成されます。
gcloud compute networks create my-net-2 \
--subnet-mode custom
サブネットとセカンダリ範囲の作成
次に、ポッドのセカンダリ範囲を my-pods、サービスのセカンダリ範囲を my-services に設定して、my-net-2 ネットワークに my-subnet-2 サブネットを作成します。
gcloud compute networks subnets create my-subnet-2 \
--network my-net-2 \
--range 192.168.0.0/20 \
--secondary-range my-pods=10.4.0.0/14,my-services=10.0.32.0/20 \
--enable-private-ip-google-access
限定公開クラスタを作成する
作成したネットワーク、サブネット、セカンダリ範囲を使用して、限定公開クラスタ private-cluster-2 を作成します。
Autopilot クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create-auto private-cluster-2 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes
Standard クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create private-cluster-2 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes \ --enable-ip-alias \ --master-ipv4-cidr 172.16.0.16/28 \ --no-enable-basic-auth \ --no-issue-client-certificate
この時点では、コントロール プレーンにアクセスできる唯一の IP アドレスです。
my-subnet-2のプライマリ範囲。- セカンダリ範囲
my-pods。
my-net-2 の外に、203.0.113.0/29 の範囲のアドレスを持つマシンのグループがあるとします。これらのマシンのパブリック エンドポイントへのアクセスを承認するには、次のコマンドを入力します。
gcloud container clusters update private-cluster-2 \
--enable-master-authorized-networks \
--master-authorized-networks 203.0.113.0/29
この時点では、コントロール プレーンにアクセスできる唯一の IP アドレスです。
my-subnet-2のプライマリ範囲。- セカンダリ範囲
my-pods。 - 承認したアドレス範囲（
203.0.113.0/29など）。
Cloud Shell を使用した限定公開クラスタへのアクセス
自動生成されたサブネットの使用セクションで作成した限定公開クラスタ、private-cluster-1 には、パブリック エンドポイントがあり、承認済みネットワークが有効になっています。Cloud Shell を使用してクラスタにアクセスする場合は、Cloud Shell の外部 IP アドレスをクラスタの承認済みネットワークのリストに追加する必要があります。
手順は次のとおりです。
Cloud Shell のコマンドライン ウィンドウで、
digを使用して Cloud Shell の外部 IP アドレスを検索します。dig +short myip.opendns.com @resolver1.opendns.comCloud Shell の外部アドレスをクラスタの承認済みネットワークのリストに追加します。
gcloud container clusters update private-cluster-1 \ --enable-master-authorized-networks \ --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32次のように置き換えます。
EXISTING_AUTH_NETS: 承認済みネットワークの既存のリストの IP アドレス。Console で、または次のコマンドを実行して、承認済みネットワークを確認できます。gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"SHELL_IP: Cloud Shell の外部 IP アドレス。
kubectlを使用してクラスタにアクセスできるように、認証情報を取得します。gcloud container clusters get-credentials private-cluster-1 \ --project=PROJECT_ID \ --internal-ipPROJECT_IDを実際のプロジェクト ID に置き換えます。Cloud Shell で
kubectlを使用して、限定公開クラスタにアクセスします。kubectl get nodes出力は次のようになります。
NAME STATUS ROLES AGE VERSION gke-private-cluster-1-default-pool-7d914212-18jv Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-3d9p Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-wgqf Ready <none> 104m v1.21.5-gke.1302
パブリック エンドポイントへ無制限にアクセス可能な限定公開クラスタの作成
このセクションでは、任意の IP アドレスでコントロール プレーンにアクセスできる限定公開クラスタを作成します。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[ 作成] をクリックし、[Standard] セクションまたは [Autopilot] セクションで [構成] をクリックします。
[名前] に「
private-cluster-3」と入力します。ナビゲーション パネルで [ネットワーキング] をクリックします。
[限定公開クラスタ] オプションを選択します。
[外部 IP アドレスを使用してコントロール プレーンにアクセス] チェックボックスをオンのままにします。
（Autopilot の場合は省略可）[コントロール プレーンの IP 範囲] を
172.16.0.32/28に設定します。[ネットワーク] と [ノードのサブネット] を
defaultに設定したままにします。これにより、GKE によってクラスタのサブネットが生成されます。[コントロール プレーン承認済みネットワークを有効にする] チェックボックスをオフにします。
[作成] をクリックします。
gcloud
Autopilot クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create-auto private-cluster-3 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-private-nodes
Standard クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create private-cluster-3 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.32/28
ここで
--create-subnetwork name=my-subnet-3を指定すると、GKE によってmy-subnet-3という名前のサブネットが自動的に作成されます。--no-enable-master-authorized-networksは、クラスタの承認済みネットワークを無効にします。
--enable-ip-aliasは、クラスタを VPC ネイティブにします（Autopilot の場合は不要）。
--enable-private-nodesは、クラスタのノードに外部 IP アドレスがないことを示します。
--master-ipv4-cidr 172.16.0.32/28は、コントロール プレーンの内部 IP アドレス範囲を指定します（Autopilot の場合は任意）。この設定はこのクラスタでは永続的であり、VPC 内で一意であることが必要です。RFC 1918 以外の内部 IP アドレスの使用がサポートされています。
その他の限定公開クラスタ構成
前述の構成に加えて、次の構成で限定公開クラスタを実行できます。
プライベート ノードにインターネットへのアウトバウンド アクセスを許可する
外部レジストリからイメージを pull するなど、プライベート ノードにインターネットへのアウトバウンド アクセスを提供する場合は、Cloud NAT を使用して Cloud Router を作成して構成します。Cloud NAT を使用すると、限定公開クラスタでは、インターネット経由でアウトバウンド接続を確立してパケットを送受信できます。
Cloud Router を使用すると、リージョン内のすべてのノードで、すべてのプライマリ IP 範囲とエイリアス IP 範囲に Cloud NAT を使用できます。また、NAT ゲートウェイに外部 IP アドレスが自動的に割り振られます。
Cloud Router の作成と構成の手順については、Cloud NAT のドキュメントの Cloud Router を使用して NAT 構成を作成するをご覧ください。
共有 VPC ネットワーク内での限定公開クラスタの作成
共有 VPC ネットワーク内で限定公開クラスタを作成する方法については、共有 VPC での限定公開クラスタの作成をご覧ください。
Windows Server コンテナ アプリケーションを限定公開クラスタにデプロイする
Windows Server コンテナ アプリケーションを限定公開クラスタにデプロイする方法については、Windows ノードプールのドキュメントをご覧ください。
コントロール プレーンのプライベート エンドポイントにグローバルにアクセスする
コントロール プレーンのプライベート エンドポイントは、コントロール プレーンの VPC ネットワーク内の内部パススルー ネットワーク ロードバランサによって実装されます。内部パススルー ネットワーク ロードバランサにアクセスできるのは、内部クライアント、または Cloud VPN トンネルと Cloud Interconnect VLAN アタッチメント経由で接続しているクライアントです。
デフォルトでは、これらのクライアントはロードバランサと同じリージョンに配置されている必要があります。
コントロール プレーンのグローバル アクセスを有効にすると、内部パススルー ネットワーク ロードバランサにグローバルにアクセスできるようになります。クライアント VM とオンプレミス システムは、承認済みネットワークの構成に従って、任意のリージョンからコントロール プレーンのプライベート エンドポイントに接続できます。
内部パススルー ネットワーク ロードバランサとグローバル アクセスの詳細については、内部ロードバランサと接続ネットワークをご覧ください。
コントロール プレーンのプライベート エンドポイント グローバル アクセスを有効にする
限定公開クラスタを作成するときに、デフォルトでは、コントロール プレーンのプライベート エンドポイントに対するグローバル アクセスが有効になっていません。コントロール プレーンのグローバル アクセスを有効にするには、クラスタのモードに基づいて次のツールを使用します。
- Standard クラスタの場合は、
Google Cloud CLIまたは Google Cloud コンソールを使用できます。
- Autopilot クラスタの場合は、
google_container_clusterTerraform リソースを使用できます。
コンソール
コントロール プレーンのグローバル アクセスを有効にした新しい限定公開クラスタを作成するには、次の手順を行います。
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[ 作成] をクリックし、[Standard] セクションまたは [Autopilot] セクションで [構成] をクリックします。
名前を入力します。
ナビゲーション パネルで [ネットワーキング] をクリックします。
[限定公開クラスタ] を選択します。
[コントロール プレーンのグローバル アクセスを有効にする] チェックボックスをオンにします。
必要に応じて他のフィールドを構成します。
[作成] をクリックします。
既存の限定公開クラスタでコントロール プレーンのグローバル アクセスを有効にするには、次の手順を行います。
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
編集するクラスタの横にあるmore_vert [アクション] をクリックし、[edit 編集] をクリックします。
[ネットワーキング] セクションで、[コントロール プレーン グローバル アクセス] の横にある [edit 編集] をクリックします。
[コントロール プレーン グローバル アクセスの編集] ダイアログで、[コントロール プレーン グローバル アクセスを有効にする] チェックボックスをオンにします。
[変更を保存] をクリックします。
gcloud
--enable-master-global-access フラグを追加して、コントロール プレーンのプライベート エンドポイントへのグローバル アクセスが有効な限定公開クラスタを作成します。
gcloud container clusters create CLUSTER_NAME \
--enable-private-nodes \
--enable-master-global-access
既存の限定公開クラスタのコントロール プレーンのプライベート エンドポイントへのグローバル アクセスを有効にすることもできます。
gcloud container clusters update CLUSTER_NAME \
--enable-master-global-access
コントロール プレーンのプライベート エンドポイント グローバル アクセスを確認する
コントロール プレーンのプライベート エンドポイントへのグローバル アクセスが有効になっているかどうか確認するには、次のコマンドを実行して出力を表示します。
gcloud container clusters describe CLUSTER_NAME
出力の privateClusterConfig セクションで masterGlobalAccessConfig のステータスを確認できます。
privateClusterConfig:
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.1.0/28
peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
privateEndpoint: 172.16.1.2
publicEndpoint: 34.68.128.12
masterGlobalAccessConfig:
enabled: true
他のネットワークからコントロール プレーンのプライベート エンドポイントにアクセスする
GKE 限定公開クラスタを作成し、コントロール プレーンのパブリック エンドポイントを無効にする場合、kubectl などのツールで、コントロール プレーンのプライベート エンドポイントを使用してクラスタを管理する必要があります。次のような別のネットワークから、クラスタのコントロール プレーンのプライベート エンドポイントにアクセスできます。
- Cloud VPN トンネルや Cloud Interconnect VLAN アタッチメントを使用してクラスタの VPC ネットワークに接続しているオンプレミス ネットワーク
- Cloud VPN トンネルを使用してクラスタの VPC ネットワークに接続された別の VPC ネットワーク
次の図は、オンプレミス ネットワークと GKE コントロール プレーン ノード間のルーティング パスを示しています。
別のネットワーク内のシステムがクラスタのコントロール プレーンのプライベート エンドポイントに接続できるようにするには、次の要件を満たす必要があります。
クラスタとそのコントロール プレーンのプライベート エンドポイントの関連するネットワーク情報を特定して記録します。
gcloud container clusters describe CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --format="yaml(network, privateClusterConfig)"次のように置き換えます。
CLUSTER_NAME: クラスタの名前。COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。
コマンドの出力から、次の手順で使用する次の情報を特定して記録します。
network: クラスタの VPC ネットワークの名前または URI。privateEndpoint: コントロール プレーンのプライベート エンドポイントの IPv4 アドレス、またはそれを含む IPv4 CIDR 範囲（masterIpv4CidrBlock）。peeringName: クラスタの VPC ネットワークをコントロール プレーンの VPC ネットワークに接続するために使用される VPC ネットワーク ピアリング接続の名前。
出力は次のようになります。
network: cluster-network privateClusterConfig: enablePrivateNodes: true masterGlobalAccessConfig: enabled: true masterIpv4CidrBlock: 172.16.1.0/28 peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer privateEndpoint: 172.16.1.2 publicEndpoint: 34.68.128.12コントロール プレーンのプライベート エンドポイント グローバル アクセスを有効にして、パケットがクラスタの VPC ネットワーク内の任意のリージョンから入るようにすることを検討してください。コントロール プレーンのプライベート エンドポイント グローバル アクセスを有効にすると、クラスタのリージョンだけでなく、任意のリージョンにある Cloud VPN トンネルや Cloud Interconnect VLAN アタッチメントを使用してプライベート エンドポイントに接続できます。
他のネットワークにある
privateEndpointIP アドレスまたはmasterIpv4CidrBlockIP アドレス範囲に向うルートを作成します。コントロール プレーンのプライベート エンドポイント IP アドレスは、常にmasterIpv4CidrBlockIPv4 アドレス範囲内にあるため、次のような場合、privateEndpointIP アドレスまたはそこを含む範囲のルートを作成すると、パケットが相手ネットワークからコントロール プレーンのプライベート エンドポイントに向かうパスが確立します。他のネットワークは、Cloud Interconnect VLAN アタッチメントか動的（BGP）ルートを使用する Cloud VPN トンネルを使用して、クラスタの VPC ネットワークに接続します。Cloud Router のカスタムルート アドバタイズを使用します。詳細については、Cloud Router のドキュメントのカスタム IP 範囲のアドバタイジングをご覧ください。
他のネットワークは、動的ルートを使用しない Classic VPN トンネルを使用してクラスタの VPC ネットワークに接続します。他のネットワークには静的ルートを構成する必要があります。
ピアリング関係のカスタムルートをコントロール プレーンの VPC ネットワークにエクスポートするように、クラスタの VPC ネットワークを構成します。Google Cloud は常に、クラスタの VPC ネットワークからカスタムルートをインポートするようにコントロール プレーンの VPC ネットワークを構成します。このステップでは、コントロール プレーンのプライベート エンドポイントから他のネットワークに戻るパケットのパスを確立します。
クラスタの VPC ネットワークからカスタムルートのエクスポートを有効にするには、次のコマンドを使用します。
gcloud compute networks peerings update PEERING_NAME \ --network=CLUSTER_VPC_NETWORK \ --export-custom-routes次のように置き換えます。
PEERING_NAME: クラスタの VPC ネットワークをコントロール プレーンの VPC ネットワークに接続するピアリングの名前CLUSTER_VPC_NETWORK: クラスタの VPC ネットワークの名前または URI
既存の VPC ネットワーク ピアリング接続のルート交換を更新する方法については、ピアリング接続を更新するをご覧ください。
クラスタの VPC ネットワーク内のカスタムルートには、オンプレミス ネットワークなど他のネットワークの IP アドレス範囲が宛先であるルートが含まれます。こうしたルートが、コントロール プレーンの VPC ネットワークでピアリング カスタムルートとして有効になるようにするには、他のネットワークからのサポートされている宛先をご覧ください。
他のネットワークからのサポートされている宛先
他のネットワークからクラスタの VPC ネットワーク内の Cloud Router に送信されるアドレス範囲は、次の条件を満たしている必要があります。
クラスタの VPC はデフォルト ルート（
0.0.0.0/0）を受け入れることができますが、コントロール プレーンの VPC ネットワークは、すでにローカルのデフォルト ルートがあるため、常にデフォルト ルートを拒否します。他のネットワークが VPC ネットワークにデフォルト ルートを送信する場合、相手側のネットワークもコントロール プレーンのプライベート エンドポイントに接続する必要があるシステムの特定の宛先を送信する必要があります。詳細については、ルーティング順序をご覧ください。コントロール プレーンの VPC ネットワークが、デフォルト ルートを効率的に置き換えるルートを受け入れる場合、そうしたルートは Google Cloud API とサービスへの接続を切断し、クラスタ コントロール プレーンを中断させます。代表的な例として、相手側ネットワークは、宛先が
0.0.0.0/1と128.0.0.0/1のルートをアドバタイズしてはいけません。別の方法については、前の説明をご覧ください。
Cloud Router の上限、特に学習したルートの一意の宛先の最大数をモニタリングします。
ノードに外部 IP アドレスがないことを確認する
限定公開クラスタの作成後は、クラスタのノードに外部 IP アドレスがないことを確認します。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
クラスタのリストで、クラスタ名をクリックします。
Autopilot クラスタの場合は、[クラスタの基本] セクションで [外部エンドポイント] フィールドを確認します。値は [無効] です。
Standard クラスタの場合は、次の操作を行います。
- [クラスタ] ページで、[ノード] タブをクリックします。
- [ノードプール] でノードプールの名前をクリックします。
- [ノードプールの詳細] ページの [インスタンス グループ] で、インスタンス グループの名前をクリックします。たとえば、gke-private-cluster-0-default-pool-5c5add1f-grp などです。
- インスタンスのリストで、インスタンスに外部 IP アドレスが指定されていないことを確認します。
gcloud
次のコマンドを実行します。
kubectl get nodes --output wide
出力の EXTERNAL-IP 列は空になります。
STATUS ... VERSION EXTERNAL-IP OS-IMAGE ...
Ready v.8.7-gke.1 Container-Optimized OS
Ready v1.8.7-gke.1 Container-Optimized OS
Ready v1.8.7-gke.1 Container-Optimized OS
クラスタのサブネットとセカンダリ アドレス範囲の表示
クラスタの作成後に、ユーザーまたは GKE によってクラスタに指定されたサブネットとセカンダリ アドレス範囲を表示できます。
コンソール
Google Cloud コンソールで [VPC ネットワーク] ページに移動します。
サブネットの名前をクリックします。例:
gke-private-cluster-0-subnet-163e3c97[IP アドレス範囲] で、サブネットのプライマリ アドレス範囲を確認できます。サブネットワークのプライマリ範囲。
[セカンダリ IP 範囲] で、Pod の IP アドレス範囲とサービスのアドレス範囲を確認できます。
gcloud
すべてのサブネットの一覧表示
クラスタのネットワークのサブネットを一覧表示するには、次のコマンドを実行します。
gcloud compute networks subnets list \
--network NETWORK_NAME
NETWORK_NAME を限定公開クラスタのネットワークに置き換えます。自動的に作成されたサブネットでクラスタを作成した場合は、default を使用します。
コマンド出力で、クラスタのサブネットの名前を見つけます。
クラスタのサブネットの表示
自動的に作成されたサブネットについての情報を取得します。
gcloud compute networks subnets describe SUBNET_NAME
SUBNET_NAME は、サブネットの名前に置き換えます。
出力には、ノード用のプライマリ アドレス範囲（最初の ipCidrRange フィールド）と Pod とサービス用のセカンダリ範囲（secondaryIpRanges の下）が表示されます。
...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
rangeName: gke-private-cluster-1-services-163e3c97
...
限定公開クラスタのエンドポイントの表示
限定公開クラスタのエンドポイントを表示するには、gcloud CLI または Google Cloud コンソールを使用します。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
クラスタリストで、クラスタ名をクリックします。
[詳細] タブの [クラスタの基本] で、[エンドポイント] フィールドを探します。
gcloud
次のコマンドを実行します。
gcloud container clusters describe CLUSTER_NAME
出力には、プライベート エンドポイントとパブリック エンドポイントの両方が表示されます。
...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67
イメージ レジストリからコンテナ イメージを pull する
限定公開クラスタでは、コンテナ ランタイムはコンテナ イメージを Artifact Registry から pull できますが、インターネット上の他のコンテナ イメージ レジストリからイメージを pull することはできません。これは、限定公開クラスタ内のノードには外部 IP アドレスがなく、デフォルトでは Google Cloud ネットワーク外のサービスと通信できないためです。
限定公開クラスタ内のノードが、限定公開の Google アクセスが有効になっているサブネット上にある場合、Artifact Registry などの Google Cloud サービスと通信できます。
次のコマンドは、Artifact Registry リポジトリからサンプル イメージを pull する Deployment を作成します。
kubectl run hello-deployment --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
特定のユースケースに対するファイアウォール ルールの追加
このセクションでは、限定公開クラスタにファイアウォール ルールを追加する方法について説明します。デフォルトでは、クラスタ コントロール プレーンはポート 443（HTTPS）および 10250（kubelet）上のみでノードおよび Pod への TCP 接続を開始するようにファイアウォール ルールによって制限されています。一部の Kubernetes 機能では、他のポート上でアクセスを許可するためにファイアウォール ルールを追加する必要があります。
追加のファイアウォール ルールを必要とする Kubernetes 機能は次のとおりです。
- アドミッション Webhook
- 集計 API サーバー
- Webhook 変換
- 動的監査の構成
- 通常、ServiceReference フィールドを持つ API では、追加のファイアウォール ルールが必要です。
ファイアウォール ルールを追加すると、クラスタ コントロール プレーンから次のポートへのトラフィックが許可されます。
- 各ノードの指定ポート（hostPort）。
- これらのノードで実行されている各 Pod の指定ポート。
- こうしたノードで実行されている各 Service の指定ポート。
ファイアウォール ルールの詳細は、Cloud Load Balancing ドキュメントのファイアウォール ルールをご覧ください。
ファイアウォール ルールを限定公開クラスタに追加するには、使用するクラスタ コントロール プレーンの CIDR ブロックとターゲットを記録する必要があります。記録したらルールを作成します。
手順 1. コントロール プレーンの CIDR ブロックの表示
ファイアウォール ルールを追加するには、クラスタ コントロール プレーンの CIDR ブロックが必要です。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
クラスタリストで、クラスタ名をクリックします。
[詳細] タブの [ネットワーキング] で、[コントロール プレーン アドレスの範囲] フィールドの値をメモしておきます。
gcloud
次のコマンドを実行します。
gcloud container clusters describe CLUSTER_NAME
CLUSTER_NAME は、使用する限定公開クラスタの名前に置き換えます。
コマンド出力で、masterIpv4CidrBlock フィールドの値をメモしておきます。
手順 2. 既存のファイアウォール ルールの表示
クラスタの既存のファイアウォール ルールが使用するターゲット（この場合は宛先ノード）を指定する必要があります。
コンソール
Google Cloud コンソールの [ファイアウォール ポリシー] ページに移動します。
[VPC ファイアウォール ルール] の [テーブルをフィルタリング] に「
gke-CLUSTER_NAME」と入力します。
結果として出力される [ターゲット] フィールドの値をメモしておきます。
gcloud
次のコマンドを実行します。
gcloud compute firewall-rules list \
--filter 'name~^gke-CLUSTER_NAME' \
--format 'table(
name,
network,
direction,
sourceRanges.list():label=SRC_RANGES,
allowed[].map().firewall_rule().list():label=ALLOW,
targetTags.list():label=TARGET_TAGS
)'
コマンド出力で、[ターゲット] フィールドの値をメモしておきます。
手順 3. ファイアウォール ルールを追加する
コンソール
Google Cloud コンソールの [ファイアウォール ポリシー] ページに移動します。
[add_box ファイアウォール ルールを作成] をクリックします。
[名前] に、ファイアウォール ルールの名前を入力します。
[ネットワーク] リストで、関連するネットワークを選択します。
[トラフィックの方向] で [上り（内向き）] をクリックします。
[一致したときのアクション] で [許可] をクリックします。
[ターゲット] リストで、[指定されたターゲットタグ] を選択します。
[ターゲットタグ] に、先ほどメモしたターゲット値を入力します。
[ソースフィルタ] リストで、[IPv4 範囲] を選択します。
[ソース IPv4 の範囲] に、クラスタ コントロール プレーンの CIDR ブロックを入力します。
[プロトコルとポート] で [指定したプロトコルとポート] をクリックし、関連するプロトコル（tcpまたはudp）のチェックボックスを選択して、プロトコル フィールドにポート番号を入力します。
[作成] をクリックします。
gcloud
次のコマンドを実行します。
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges CONTROL_PLANE_RANGE \
--rules PROTOCOL:PORT \
--target-tags TARGET
次のように置き換えます。
FIREWALL_RULE_NAME: ファイアウォール ルールに付ける名前。CONTROL_PLANE_RANGE: 前の手順で確認したクラスタ コントロール プレーンの IP アドレス範囲（masterIpv4CidrBlock）。PROTOCOL:PORT: ポートとそのプロトコル（tcpまたはudp）。TARGET: 以前に収集した目標（Targets）値。
VPC Service Controls による限定公開クラスタの保護
VPC Service Controls を使用して GKE 限定公開クラスタの保護を強化します。
VPC Service Controls は GKE 限定公開クラスタ向けの追加のセキュリティ機能を提供して、データ漏洩のリスクを低減します。VPC Service Controls の活用により、境界の外部から発生するリクエストからリソースとサービスを保護するサービス境界にプロジェクトを追加できます。
サービス境界の詳細については、サービス境界の詳細と構成をご覧ください。
VPC Service Controls サービス境界内の GKE 限定公開クラスタで Artifact Registry を使用する場合は、制限付きの仮想 IP へのルーティングを構成して、データの引き出しを防ぐ必要があります。
VPC ピアリングの再利用
2020 年 1 月 15 日以降に作成した限定公開クラスタは、VPC ネットワーク ピアリング接続を再利用します。
2020 年 1 月 15 日より前に作成した限定公開クラスタは、一意の VPC ネットワーク ピアリング接続を使用します。各 VPC ネットワークは最大 25 個の他の VPC ネットワークとピアリングできます。つまり、これらのクラスタはネットワーク当たりの限定公開クラスタ数が最大 25 個に制限されることになります（ピアリングが他の目的で使用されないことが前提）。
この機能は、以前のリリースには移植されていません。古い限定公開クラスタで VPC ネットワーク ピアリングを再利用できるようにするには、クラスタを削除して再作成する必要があります。クラスタをアップグレードしても、既存の VPC ネットワーク ピアリング接続は再利用されません。
各ロケーションは、限定公開クラスタの VPC ネットワーク ピアリング再利用が有効になっていれば、最大 75 個のクラスタをサポートできます。ゾーンとリージョンは別々のロケーションとして扱われます。
たとえば、最大 75 個の限定公開ゾーンクラスタを us-east1-a に作成し、さらに 75 個の限定公開リージョン クラスタを us-east1 に作成できます。これは、共有 VPC ネットワークで限定公開クラスタを使用している場合にも当てはまります。1 つの VPC ネットワークへの最大接続数は 25 です。つまり、作成できるのは固有のロケーションを 25 個使用した限定公開クラスタだけということになります。
VPC ネットワーク ピアリングの再利用は、同じロケーションのクラスタ（同じリージョン内のリージョン クラスタ、同じゾーン内のゾーンクラスタなど）にのみ適用されます。リージョン クラスタとゾーンクラスタの両方をそのリージョン内のすべてのゾーンに作成する場合は、リージョンごとに最大 4 つの VPC ネットワーク ピアリングを設定できます。
限定公開クラスタが VPC ネットワーク ピアリング接続を再利用するかどうかは、gcloud CLI または Google Cloud コンソールで確認できます。
コンソール
クラスタの詳細ページで「VPC ピアリング」行を調べます。クラスタが VPC ピアリング接続を再利用している場合、出力は gke-n で始まります。例: gke-n34a117b968dee3b2221-93c6-40af-peer
gcloud
gcloud container clusters describe CLUSTER_NAME \
--format="value(privateClusterConfig.peeringName)"
クラスタが VPC ピアリング接続を再利用している場合、出力は gke-n で始まります。例: gke-n34a117b968dee3b2221-93c6-40af-peer
クリーンアップ
このページのタスクを完了したら、アカウントで不要な請求が発生しないように、以下の手順でリソースを削除します。
クラスタを削除する
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
各クラスタを選択します。
[delete 削除] をクリックします。
gcloud
gcloud container clusters delete -q private-cluster-0 private-cluster-1 private-cluster-2 private-cluster-3
ネットワークを削除する
コンソール
Google Cloud コンソールで [VPC ネットワーク] ページに移動します。
ネットワークのリストで、
my-net-0をクリックします。[VPC ネットワークの詳細] ページで、delete [VPC ネットワークの削除] をクリックします。
[ネットワークの削除] ダイアログで [削除] をクリックします。
gcloud
gcloud compute networks delete my-net-0
要件、制約、制限
限定公開クラスタには次の要件があります。
- 限定公開クラスタは、VPC ネイティブ クラスタである必要があります。VPC ネイティブ クラスタは、レガシー ネットワークをサポートしていません。
限定公開クラスタには次の制約があります。
- 既存の非限定公開クラスタを限定公開クラスタに変換することはできません。
- コントロール プレーンの IP 範囲に
172.17.0.0/16を使用する場合、ノード、Pod、Service の IP アドレスにはこの範囲を使用できません。 - クラスタ コントロール プレーンとクラスタノード間の VPC ピアリングの削除、クラスタ コントロール プレーンからポート 10250 上のノードへの上り（内向き）トラフィックを許可するファイアウォール ルールの削除、デフォルトのインターネット ゲートウェイへのデフォルト ルートの削除を行うと、限定公開クラスタは機能しなくなります。デフォルト ルートを削除する場合は、必要な Google Cloud サービスへのトラフィックが転送されるようにする必要があります。詳細については、カスタム ルーティングをご覧ください。
- VPC でカスタムルートのエクスポートが有効になっている場合、Google Cloud IP の範囲と重複するルートを作成すると、クラスタが壊れる可能性があります。
- 1 つのプロジェクトに追加できる承認済みネットワーク（許可済み CIDR ブロック）は最大 50 個です。詳しくは、承認済みネットワークを既存のクラスタに追加するをご覧ください。
限定公開クラスタには次の制限があります。
- クラスタ コントロール プレーンの RFC 1918 ブロックのサイズは、
/28でなければなりません。 - GKE ではコントロール プレーンのアドレス ブロックとの重複を検出できますが、共有 VPC ネットワーク内の重複は検出できません。
- 限定公開クラスタ内のすべてのノードはパブリック IP なしで作成され、Google Cloud の API とサービスへのアクセスが制限されます。プライベート ノードにインターネットへのアウトバウンド アクセスを提供する場合は、Cloud NAT を使用できます。
- 共有 VPC を使用している場合を除き、限定公開クラスタを作成すると、限定公開の Google アクセスが自動的に有効になります。NAT を使用してインターネットにアクセスしている場合を除き、限定公開の Google アクセスを無効にしないでください。
- 2020 年 1 月 15 日より前に作成した限定公開クラスタは、ネットワークあたりの限定公開クラスタ数が最大 25 個に制限されます（ピアリングが他の目的で使用されないことが前提）。詳細は、VPC ピアリングの再利用をご覧ください。
- すべての限定公開クラスタには、VPC との間にピアリング ルートが必要ですが、一度に実行できるピアリング オペレーションは 1 つだけです。複数の限定公開クラスタを作成しようとすると、クラスタの作成がタイムアウトする場合があります。これを回避するには、後続の限定公開クラスタごとに既存の VPC ピアリング ルートが存在するように、限定公開クラスタを順次作成します。VPC で実行中のオペレーションがある場合、単一の限定公開クラスタを作成しようとしてもタイムアウトになることがあります。
- 追加のノードに対応するサブネットのプライマリ IP 範囲を拡張する場合は、拡張サブネットのプライマリ IP アドレス範囲を承認済みネットワークのリストに追加する必要があります。これを行わないと、コントロール プレーンに関連する上り（内向き）許可ファイアウォール ルールが更新されず、拡張 IP アドレス空間に作成される新しいノードがコントロール プレーンに登録できなくなります。そのため、新しいノードが継続的に削除され、置き換えられることで、停止に陥る可能性があります。このような停止は、ノードプールのアップグレードを行う場合や、livenessProbe の失敗によってノードが自動的に置き換えられる場合に発生することがあります。
- 自動的に作成されたファイアウォール ルールよりも高い優先度のファイアウォール ルールまたは階層型ファイアウォール ポリシー ルールを作成しないでください。
トラブルシューティング
以降のセクションでは、限定公開クラスタに関連する一般的な問題を解決する方法について説明します。
限定公開クラスタの VPC ネットワーク ピアリング接続が誤って削除される
- 現象
誤って VPC ネットワーク ピアリング接続を削除すると、クラスタは修復状態になり、すべてのノードに
UNKNOWNステータスが表示されます。コントロール プレーンへの到達性が切断されているため、クラスタに対してオペレーションは実行できません。コントロール プレーンを検査すると、ログに次のようなエラーが表示されます。error checking if node NODE_NAME is shutdown: unimplemented- 考えられる原因
VPC ネットワーク ピアリング接続を誤って削除してしまった。
- 解決策
以下の操作を行います。
新しい一時的な VPC ネットワーク ピアリング クラスタを作成します。クラスタを作成すると、VPC ネットワーク ピアリングが再作成され、古いクラスタは通常の稼働状況に復元されます。
古いクラスタが通常の動作に戻ったら、一時的に作成された VPC ネットワーク ピアリング クラスタを削除します。
クラスタがアクティブピアと重複している
- 現象
限定公開クラスタを作成しようとすると、次のようなエラーが返される。
Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network.- 考えられる原因
重複するコントロール プレーン CIDR を選択しています。
- 解決策
クラスタを削除して、別のコントロール プレーン CIDR を使用して再作成します。
限定公開クラスタのコントロール プレーンにアクセスできない
クラスタ エンドポイント アクセス構成を実装することで、クラスタ コントロール プレーンに到達できる可能性を高めます。詳細については、クラスタ エンドポイントへのアクセスをご覧ください。
- 現象
限定公開クラスタを作成した後、クラスタに
kubectlコマンドを実行しようとすると、次のいずれかのエラーが返される。Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out.Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.- 考えられる原因
kubectlがクラスタ コントロール プレーンと通信できません。- 解決策
クラスタの認証情報が kubeconfig に生成されているか、正しいコンテキストが有効になっていることを確認します。クラスタ認証情報の設定の詳細については、kubeconfig エントリを生成するをご覧ください。
外部 IP アドレスを使用したコントロール プレーンへのアクセスが許可されていることを確認します。クラスタ コントロール プレーンへの外部アクセスを無効にすると、クラスタがインターネットから分離されます。この構成は、クラスタの作成後は変更できません。この構成では、承認済みの内部ネットワークの CIDR 範囲または予約済みネットワークのみがコントロール プレーンにアクセスできます。
送信元 IP アドレスがコントロール プレーンへのアクセスが許可されていることを確認します。
gcloud container clusters describe CLUSTER_NAME \ --format="value(masterAuthorizedNetworksConfig)"\ --location=COMPUTE_LOCATION次のように置き換えます。
CLUSTER_NAME: クラスタの名前。COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。
送信元 IP アドレスが承認されていない場合、出力では空の結果（中かっこのみ）または送信元 IP アドレスを含まない CIDR 範囲が返されることがあります。
cidrBlocks: cidrBlock: 10.XXX.X.XX/32 displayName: jumphost cidrBlock: 35.XXX.XXX.XX/32 displayName: cloud shell enabled: trueコントロール プレーンにアクセスするために、承認済みネットワークを追加します。
オンプレミス環境またはクラスタのロケーションとは異なるリージョンから
kubectlコマンドを実行する場合は、コントロール プレーンのプライベート エンドポイント グローバル アクセスが有効になっているかを確認してください。詳細については、グローバルにコントロール プレーンのプライベート エンドポイントにアクセスするをご覧ください。制御アクセス構成のレスポンスを表示するようにクラスタを記述します。
gcloud container clusters describe CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --flatten "privateClusterConfig.masterGlobalAccessConfig"次のように置き換えます。
CLUSTER_NAME: クラスタの名前。COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。
正常な出力は次のようになります。
enabled: truenullが返された場合は、コントロール プレーンへのグローバル アクセスを有効にします。
IPv4 CIDR ブロックが重複しているためクラスタを作成できない
- 現象
gcloud container clusters createが次のようなエラーを返す。The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.- 考えられる原因
指定したコントロール プレーン CIDR ブロックが、VPC 内の既存のサブネットと重複しています。
- 解決策
既存のサブネットと重複しない
--master-ipv4-cidrの CIDR ブロックを指定します。
別のクラスタですでに使用されているサービス範囲があるため、クラスタを作成できない
- 現象
限定公開クラスタを作成しようとすると、次のようなエラーが返される。
Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork [SUBNET_NAME] is already used by another cluster.- 考えられる原因
次のいずれかになります。
- 別のクラスタで使用されているサービス範囲を選択しているか、クラスタが削除されていません。
- そのサービス範囲を使用するクラスタは削除されましたが、セカンダリ範囲メタデータが正しくクリーンアップされませんでした。GKE クラスタのセカンダリ範囲は Compute Engine のメタデータに保存されます。またクラスタを削除した際、セカンダリ範囲のメタデータも削除されます。しかし、クラスタが正常に削除された場合でも、セカンダリ範囲のメタデータが削除されないことがあります。
- 解決策
手順は次のとおりです。
- サービス範囲が既存のクラスタで使用されているかどうかを確認します。クラスタを検索するには、
filterフラグを指定してgcloud container clusters listコマンドを実行します。サービス範囲を使用する既存のクラスタがある場合は、そのクラスタを削除するか、新しいサービス範囲を作成する必要があります。 - サービス範囲が既存のクラスタで使用されていない場合は、使用するサービス範囲と一致するメタデータ エントリを手動で削除します。
- サービス範囲が既存のクラスタで使用されているかどうかを確認します。クラスタを検索するには、
サブネットを作成できない
- 現象
自動サブネットを使用して限定公開クラスタを作成するか、カスタム サブネットを作成すると、次のようなエラーが発生することがある。
An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.- 考えられる原因
指定したコントロール プレーンの CIDR 範囲が、クラスタ内の別の IP 範囲と重複しています。これは、限定公開クラスタを最近削除して、同じコントロール プレーン CIDR を使用して新しい限定公開クラスタを作成しようとする場合にも発生します。
- 解決策
別の CIDR 範囲を使用してみてください。
公開 Docker Hub からイメージを pull できない
- 現象
kubectl describeを実行すると、クラスタで実行中の Pod で警告が表示されることがある。Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)- 考えられる原因
限定公開クラスタ内のノードには外部 IP アドレスがないため、インターネット アクセスの要件を満たしていない。ただし、限定公開の Google アクセスが有効になっていて、ネットワーク要件を満たしている場合、ノードは Artifact Registry を含む Google Cloud APIs とサービスにアクセスできます。
- 解決策
次のいずれかの方法を使用します。
限定公開クラスタのイメージを Docker Hub から Artifact Registry にコピーします。詳細については、サードパーティ レジストリからのコンテナの移行をご覧ください。
そのまま GKE で、
mirror.gcr.ioに、よくアクセスされる Docker Hub イメージのキャッシュに保存されたコピーがあるかどうかを調べます。Docker Hub または別の公開リポジトリからイメージを pull する必要がある場合は、Cloud NAT または静的
0.0.0.0/0ルートのターゲットであるインスタンス ベースのプロキシを使用します。
アドミッション Webhook のタイムアウトをトリガーする API リクエスト
- 現象
targetPort 443 以外でサービスを使用するアドミッション Webhook をトリガーする API がタイムアウトし、リクエストが失敗する。
Error from server (Timeout): request did not complete within requested timeout 30s- 考えられる原因
デフォルトのファイアウォールでは、ポート 443（HTTPS）と 10250（kubelet）以外のノードへの TCP 接続は許可されません。トラフィックを許可するカスタム ファイアウォール ルールがない場合、443 以外のポートで Pod との通信を試みるアドミッション Webhook は失敗します。
- 解決策
特定のユースケースにファイアウォール ルールを追加します。
ヘルスチェックに失敗したためクラスタを作成できない
- 現象
限定公開クラスタを作成すると、ヘルスチェックのステップが停止し、次のいずれかのエラーが返される。
All cluster resources were brought up, but only 0 of 2 have registered.All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy- 考えられる原因
次のいずれか:
- クラスタノードが、Cloud Storage API（
storage.googleapis.com）から必要なバイナリをダウンロードできない。 - 下り（外向き）トラフィックを制限するファイアウォール ルール。
- 共有 VPC の IAM 権限が正しくない。
- 限定公開の Google アクセスでは
*.gcr.ioに DNS を構成する必要があります。
- クラスタノードが、Cloud Storage API（
- 解決策
次のいずれかの方法を使用します。
ノード ネットワークで
storage.googleapis.comへのサブネットとして限定公開の Google アクセスを有効にするか、Cloud NAT を有効にしてノードがstorage.googleapis.comエンドポイントと通信できるようにします。詳細については、GKE 限定公開クラスタの作成に関する問題のトラブルシューティングをご覧ください。storage.googleapis.comに対するノード読み取りアクセス権については、クラスタノードに割り当てられたサービス アカウントにストレージ読み取りアクセス権が付与されていることを確認します。すべての下り（外向き）トラフィックを許可する Google Cloud ファイアウォール ルールがあることを確認するか、クラスタ コントロール プレーンと
*.googleapis.comへのノードの下り（外向き）トラフィックを許可するファイアウォール ルールを構成します。*.gcr.ioに DNS 構成を作成します。デフォルト以外のファイアウォールまたはルートが設定されている場合は、限定公開の Google アクセスを構成します。
VPC Service Controls を使用する場合は、GKE 限定公開クラスタに Container Registry または Artifact Registry を設定します。
Ingress に自動的に作成されたファイアウォール ルールを削除または変更していないことを確認してください。
共有 VPC を使用している場合は、必要な IAM 権限が構成されていることを確認してください。
kubelet が Pod サンドボックスの作成に失敗した
- 現象
限定公開クラスタを作成すると、次のようなエラーが報告されます。
Warning FailedCreatePodSandBox 12s (x9 over 4m) kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized- 考えられる原因
calico-nodePod またはnetdPod が*.gcr.ioに到達できない。- 解決策
次のいずれかの方法を使用します。
- 必要な Container Registry または Artifact Registry の設定が完了していることを確認します。
作成された限定公開クラスタノードがクラスタに参加しない
多くの場合、限定公開クラスタで使用されている VPC でカスタム ルーティングとサードパーティ ネットワーク アプライアンスを使用すると、デフォルトのインターネット ゲートウェイではなく、アプライアンスにデフォルト ルート（0.0.0.0/0）がリダイレクトされます。コントロール プレーンの接続だけでなく、次の宛先に到達できるようにする必要があります。
- *.googleapis.com
- *.gcr.io
- gcr.io
3 つのドメインすべてに対して限定公開の Google アクセスを構成します。このベスト プラクティスでは、インターネットにバインドされたトラフィックを制限しながら、新しいノードが起動してクラスタに参加できるようになります。
限定公開 GKE クラスタのワークロードがインターネットにアクセスできない
限定公開 GKE クラスタ内の Pod はインターネットにアクセスできません。たとえば、Pod exec shell から apt update コマンドを実行すると、次のようなエラーが報告されます。
0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]
クラスタ内の Pod に使用されるサブネット セカンダリ IP アドレス範囲が Cloud NAT ゲートウェイに構成されていない場合、Cloud NAT ゲートウェイに外部 IP アドレスが構成されていないため、Pod はインターネットに接続できません。
クラスタが使用するサブネットに、少なくとも次のサブネット IP アドレス範囲が適用されるように Cloud NAT ゲートウェイを構成してください。
- サブネットのプライマリ IP アドレス範囲（ノードで使用）
- サブネット クラスタ内の Pod に使用されるセカンダリ IP アドレス範囲
- クラスタ内のサービスに使用されるサブネット セカンダリ IP アドレス範囲
詳細については、Pod に使用されるセカンダリ サブネット IP 範囲を追加する方法をご覧ください。