このページでは、Google Kubernetes Engine(GKE)で VPC ネイティブ クラスタを構成する方法について説明します。
VPC ネイティブ クラスタの利点と要件の詳細については、VPC ネイティブ クラスタの概要をご覧ください。
始める前に
始める前に、次の作業が完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components update
を実行して最新のバージョンを取得する。
制限事項
- VPC ネイティブ クラスタをルートベース クラスタに変換することはできません。また、ルートベース クラスタを VPC ネイティブ クラスタに変換することもできません。
- VPC ネイティブ クラスタには VPC ネットワークが必要です。レガシー ネットワークはサポートされていません。
- GKE クラスタの場合と同様に、Service(ClusterIP)のアドレスはクラスタ内部にのみ公開されています。クラスタの内部ではないが、クラスタと同じ VPC ネットワークとリージョン内にある VM インスタンスから Kubernetes Service にアクセスする必要がある場合、内部パススルー ネットワーク ロードバランサを作成します。
- サブネット内のすべての Pod IP アドレスを使用する場合、クラスタを不安定な状態にすることなくサブネットのセカンダリ IP アドレス範囲を置き換えることはできません。ただし、連続していないマルチ Pod CIDR を使用すると、追加の Pod IP アドレス範囲を作成できます。
既存のサブネットにクラスタを作成する
セカンダリ範囲割り当て方式を選択して、既存のサブネットで VPC ネイティブ GKE クラスタを作成する方法を次の手順で示します。
gcloud
GKE によって管理されているセカンダリ範囲割り当て方式を使用するには:
gcloud container clusters create CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --enable-ip-alias \ --subnetwork=SUBNET_NAME \ --cluster-ipv4-cidr=POD_IP_RANGE \ --services-ipv4-cidr=SERVICES_IP_RANGE
ユーザーによって管理されているセカンダリ範囲割り当て方式を使用するには:
gcloud container clusters create CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --enable-ip-alias \ --subnetwork=SUBNET_NAME \ --cluster-secondary-range-name=SECONDARY_RANGE_PODS \ --services-secondary-range-name=SECONDARY_RANGE_SERVICES
次のように置き換えます。
CLUSTER_NAME
: GKE クラスタの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。SUBNET_NAME
: 既存のサブネットの名前。ノードにはサブネットのプライマリ IP アドレス範囲が使用されます。サブネットは、クラスタによって使用されるリージョンと同じリージョンに存在する必要があります。省略した場合、GKE はクラスタのリージョンにあるdefault
VPC ネットワーク内のサブネットの使用を試みます。- セカンダリ範囲の割り当て方式が GKE によって管理されている場合:
POD_IP_RANGE
: CIDR 表記の IP アドレス範囲(10.0.0.0/14
など)、または CIDR ブロックのサブネット マスクのサイズ(/14
など)。これは、Pod 用のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。--cluster-ipv4-cidr
オプションを省略すると、GKE は自動的に/14
範囲(218 のアドレス)を選択します。自動選択範囲が10.0.0.0/8
(範囲 224 のアドレス)からランダムに選択されます。この範囲には、VM、既存のルート、他のクラスタに割り振られた IP アドレス範囲は含まれません。自動選択範囲は、予約済み IP アドレス、動的ルート、またはこのクラスタとピアリングする VPC 内のルートと競合する可能性があります。これらの範囲を使用する場合は、競合を避けるため--cluster-ipv4-cidr
を指定する必要があります。SERVICES_IP_RANGE
は、CIDR 表記の IP アドレス範囲(10.4.0.0/19
など)、または CIDR ブロックのサブネット マスクのサイズ(/19
など)です。これは、Service 用のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。
- セカンダリ範囲の割り当て方式がユーザーによって管理されている場合:
SECONDARY_RANGE_PODS
: 指定されたSUBNET_NAME
内の既存のセカンダリ IP アドレス範囲の名前。GKE は、クラスタの Pod にサブネット セカンダリ IP アドレス範囲全体を使用します。SECONDARY_RANGE_SERVICES
: 指定された既存のセカンダリ IP アドレス範囲の名前。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[作成] をクリックし、[Standard] セクションまたは [Autopilot] セクションで [構成] をクリックします。
ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[ネットワーク] プルダウン リストで、任意の VPC を選択します。
[ノードのサブネット] プルダウン リストで、クラスタのサブネットを選択します。
[VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] チェックボックスが選択されていることを確認します。
セカンダリ範囲割り当て方式を GKE によって管理する場合は、[セカンダリ範囲を自動的に作成する] チェックボックスを選択します。選択したサブネットのセカンダリ範囲をすでに作成していて、セカンダリ範囲割り当て方式をユーザーによって管理する場合は、このチェックボックスをオフにします。
[Pod のアドレス範囲] フィールドに、
10.0.0.0/14
などの Pod 範囲を入力します。[サービス アドレスの範囲] フィールドに、サービスの範囲(
10.4.0.0/19
など)を入力します。クラスタを構成します。
[作成] をクリックします。
Terraform
Terraform モジュールを使用すると、Terraform を介して VPC ネイティブ クラスタを作成できます。
たとえば、Terraform 構成に次のブロックを追加できます。
module "gke" {
source = "terraform-google-modules/kubernetes-engine/google"
version = "~> 12.0"
project_id = "PROJECT_ID"
name = "CLUSTER_NAME"
region = "COMPUTE_LOCATION"
network = "NETWORK_NAME"
subnetwork = "SUBNET_NAME"
ip_range_pods = "SECONDARY_RANGE_PODS"
ip_range_services = "SECONDARY_RANGE_SERVICES"
}
次のように置き換えます。
PROJECT_ID
: プロジェクト ID。CLUSTER_NAME
: GKE クラスタの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。Terraform の場合は、Compute Engine のリージョン。NETWORK_NAME
: 既存のネットワークの名前。SUBNET_NAME
: 既存のサブネットの名前。ノードにはサブネットのプライマリ IP アドレス範囲が使用されます。サブネットは、クラスタによって使用されるリージョンと同じリージョンに存在する必要があります。SECONDARY_RANGE_PODS
: 指定された既存のセカンダリ IP アドレス範囲の名前。SECONDARY_RANGE_SERVICES
: 指定された既存のセカンダリ IP アドレス範囲の名前。
API
VPC ネイティブ クラスタを作成する場合、IPAllocationPolicy オブジェクトを定義します。既存のサブネット セカンダリ IP アドレス範囲を参照することも、CIDR ブロックを指定することもできます。既存のサブネット セカンダリ IP アドレス範囲を参照して、セカンダリ範囲の割り当てがユーザーによって管理されるクラスタを作成します。この範囲の割り当てを GKE によって管理する場合は、CIDR ブロックを指定します。
{
"name": CLUSTER_NAME,
"description": DESCRIPTION,
...
"ipAllocationPolicy": {
"useIpAliases": true,
"clusterIpv4CidrBlock" : string,
"servicesIpv4CidrBlock" : string,
"clusterSecondaryRangeName" : string,
"servicesSecondaryRangeName": string,
},
...
}
このコマンドには次の値が含まれます。
"clusterIpv4CidrBlock"
: Pod の CIDR 範囲。これにより、Pod のセカンダリ範囲のサイズが決まります。これは CIDR 表記(10.0.0.0/14
など)で指定できます。指定されたサイズの空きスペースが、VPC 内の使用可能なスペースから選択されます。空白にしておくと、有効な範囲が検出され、デフォルトのサイズで作成されます。"servicesIpv4CidrBlock"
: Service の CIDR 範囲。"clusterIpv4CidrBlock"
の説明をご覧ください。"clusterSecondaryRangeName"
: Pod のセカンダリ範囲の名前。セカンダリ範囲がすでに存在し、クラスタに関連付けられたサブネットワークに属している必要があります。"serviceSecondaryRangeName"
: Service のセカンダリ範囲の名前。セカンダリ範囲がすでに存在し、クラスタに関連付けられたサブネットワークに属している必要があります。
クラスタを作成してコントロール プレーンの IP アドレス範囲を選択する
デフォルトでは、Private Service Connect を使用するクラスタは、プライマリ サブネット範囲を使用して、コントロール プレーン エンドポイントに割り当てられた内部 IP アドレスをプロビジョニングします。このデフォルト設定をオーバーライドするには、クラスタの作成時に別のサブネット範囲を選択します。以降のセクションでは、Private Service Connect を使用してクラスタを作成し、サブネット範囲をオーバーライドする方法について説明します。
gcloud
Private Service Connect が一般公開として定義されたクラスタを作成する
gcloud container clusters create CLUSTER_NAME \
--private-endpoint-subnetwork=SUBNET_NAME \
--location=COMPUTE_LOCATION
--enable-private-nodes
フラグを追加して、Private Service Connect クラスタを限定公開として作成します。
次のように置き換えます。
CLUSTER_NAME
: GKE クラスタの名前。SUBNET_NAME
: 既存のサブネットの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。
GKE は、Private Service Connect を使用するクラスタを作成します。
限定公開として定義されたクラスタを作成する:
GKE バージョン 1.29 以降では、Private Service Connect を使用してクラスタを作成できます。
gcloud container clusters create CLUSTER_NAME --enable-ip-alias \
--enable-private-nodes \
--private-endpoint-subnetwork=SUBNET_NAME \
--region=COMPUTE_REGION
次のように置き換えます。
CLUSTER_NAME
: GKE クラスタの名前。SUBNET_NAME
: 既存のサブネットの名前。private-endpoint-subnetwork
フラグの値を指定せず、master-ipv4-cidr
を使用すると、GKE はmaster-ipv4-cidr
に定義された値を使用する新しいサブネットを作成します。GKE は、新しいサブネットを使用してコントロール プレーンの内部 IP アドレスをプロビジョニングします。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。
コンソール
一般公開として定義されたクラスタを作成する:
新しいクラスタのコントロール プレーンにサブネットを割り当てるには、まずサブネットを追加する必要があります。その後、次の手順を完了します。
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[add_box 作成] をクリックします。
[Standard] セクションまたは [Autopilot] セクションで、[構成] をクリックします。
[名前] にクラスタ名を入力します。
Standard クラスタの場合は、ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[IPv4 ネットワーク アクセス] セクションで、次の操作を行います。
- GKE クラスタを一般公開クラスタとして作成するには、[一般公開クラスタ] を選択します。
- GKE クラスタを限定公開として作成するには、[限定公開クラスタ] を選択します。
いずれの場合も、クラスタ構成を編集するときにクラスタ分離モードを変更できます。
[高度なネットワーキングのオプション] セクションで、[コントロール プレーンのデフォルトのプライベート エンドポイント サブネットをオーバーライドする] チェックボックスをオンにします。
[プライベート エンドポイント サブネット] リストで、作成したサブネットを選択します。
[完了] をクリックします。必要に応じて、承認済みネットワークを追加します。
クラスタとサブネットを同時に作成する
VPC ネイティブ GKE クラスタとサブネットを同時に作成する方法を次に示します。1 つのコマンドでこれらの 2 つのステップを実行すると、セカンダリ範囲割り当て方式は GKE によって管理されます。
gcloud
VPC ネイティブ クラスタとサブネットを同時に作成するには:
gcloud container clusters create CLUSTER_NAME \
--location=COMPUTE_LOCATION \
--enable-ip-alias \
--create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
--cluster-ipv4-cidr=POD_IP_RANGE \
--services-ipv4-cidr=SERVICES_IP_RANGE
次のように置き換えます。
CLUSTER_NAME
: GKE クラスタの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。SUBNET_NAME
: 作成するサブネットの名前。サブネットのリージョンは、クラスタと同じリージョンです(つまり、ゾーンクラスタが含まれているリージョン)。GKE によって自動的に名前を生成する場合は、空のストリング(name=""
)を使用します。NODE_IP_RANGE
: CIDR 表記の IP アドレス範囲(10.5.0.0/20
など)、または CIDR ブロックのサブネット マスクのサイズ(/20
など)。これは、ノードのサブネットのプライマリ IP アドレス範囲を作成するために使用されます。省略した場合、GKE は/20
のサイズで VPC 内で使用可能な IP 範囲を選択します。POD_IP_RANGE
: CIDR 表記の IP アドレス範囲(10.0.0.0/14
など)、または CIDR ブロックのサブネット マスクのサイズ(/14
など)。これは、Pod 用のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。省略した場合、GKE は 218 のアドレスを含むランダムに選択された/14
範囲を使用します。自動選択範囲が10.0.0.0/8
(範囲 224 のアドレス)からランダムに選択されます。この範囲には、VM、既存のルート、他のクラスタに割り振られた IP アドレス範囲は含まれません。自動選択範囲は、予約済み IP アドレス、動的ルート、またはこのクラスタとピアリングする VPC 内のルートと競合する可能性があります。これらの範囲を使用する場合は、競合を避けるため--cluster-ipv4-cidr
を指定する必要があります。SERVICES_IP_RANGE
: CIDR 表記の IP アドレス範囲(10.4.0.0/19
など)、または CIDR ブロックのサブネット マスクのサイズ(/19
など)。これは、Service 用のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。省略した場合、GKE はデフォルトの Service IP アドレス範囲のサイズである/20
を使用します。
コンソール
Google Cloud コンソールを使用して、クラスタとサブネットを同時に作成することはできません。最初にサブネットを作成して、次に既存のサブネットにクラスタを作成します。
API
VPC ネイティブ クラスタを作成するには、クラスタ リソースに IPAllocationPolicy オブジェクトを定義します。
{
"name": CLUSTER_NAME,
"description": DESCRIPTION,
...
"ipAllocationPolicy": {
"useIpAliases": true,
"createSubnetwork": true,
"subnetworkName": SUBNET_NAME
},
...
}
createSubnetwork
フィールドを使用すると、クラスタのサブネットワークが自動的に作成され、プロビジョニングされます。subnetworkName
フィールドはオプションです。空のままにすると、サブネットワークの名前が自動的に選択されます。
RFC 1918 以外の IP アドレス範囲を使用する
GKE クラスタでは、ノード、Pod、Service に RFC 1918 以外の IP アドレス範囲を使用できます。サブネット範囲の内部 IP アドレスとして使用できる RFC 1918 以外のプライベート範囲については、VPC ネットワークのドキュメントで有効範囲をご覧ください。
RFC 1918 以外の IP アドレス範囲は、限定公開クラスタと非限定公開クラスタの両方に対応しています。
RFC 1918 以外のプライベート範囲はサブネット範囲です。この範囲のみを使用するか、RFC 1918 サブネット範囲と組み合わせて使用できます。VPC ネイティブ クラスタの IP 範囲で説明しているように、ノード、Pod、Service は引き続きサブネット範囲を使用します。RFC 1918 以外の範囲を使用する場合、次の点に注意してください。
サブネット範囲(RFC 1918 以外の範囲を使用するサブネット範囲を含む)は、クラスタのノードを作成する前に手動で割り当てるか、GKE によって割り当てる必要があります。クラスタを置き換えない限り、RFC 1918 以外のサブネット範囲の使用に切り替えることも、使用を停止することもできません。
内部パススルー ネットワーク ロードバランサは、サブネットのプライマリ IP アドレス範囲の IP アドレスのみを使用します。RFC 1918 以外のアドレスを持つ内部パススルー ネットワーク ロードバランサを作成するには、サブネットのプライマリ IP アドレス範囲を RFC 1918 以外のアドレスにする必要があります。
クラスタ外の宛先で、RFC 1918 以外のプライベート範囲からのトラフィックを受信できない可能性があります。たとえば、RFC 1112(クラス E)のプライベート範囲は通常、マルチキャスト アドレスとして使用されます。クラスタ外の宛先で、送信元が RFC 1918 以外のプライベート IP アドレスのパケットを処理できない場合、次を実行できます。
- サブネットのプライマリ IP アドレス範囲に RFC 1918 範囲を使用します。これにより、クラスタ内のノードは RFC 1918 アドレスを使用します。
- クラスタで IP マスカレード エージェントが実行され、宛先が
nonMasqueradeCIDRs
リストに含まれていないことを確認します。これにより、Pod から送信したパケットの送信元が SNAT によりノードアドレス(RFC 1918)に変換されます。
プライベートで使用された外部 IP アドレス範囲を有効にする
GKE クラスタは、特定の外部 IP アドレス範囲を内部のサブネット IP アドレス範囲としてプライベートに使用できます。外部 IP アドレスは、VPC ネットワークのドキュメントに記載されている特定の制限付きの範囲を除いてすべてプライベートに使用できます。
プライベートで使用される外部 IP アドレス範囲を利用するには、クラスタが VPC ネイティブ クラスタである必要があります。ルートベース クラスタはサポートされていません。
プライベートで使用される外部範囲はサブネット範囲です。これらを排他的に使用することも、プライベート アドレスを使用する他のサブネット範囲と組み合わせて使用することもできます。VPC ネイティブ クラスタの IP 範囲で説明しているように、ノード、Pod、Service は引き続きサブネット範囲を使用します。外部 IP アドレスをプライベートで再利用するときは、次の点に注意してください。
外部 IP アドレス範囲をサブネット範囲として使用すると、クラスタはその外部範囲を使用するインターネット上のシステムと通信できなくなります。範囲は、クラスタの VPC ネットワークの内部 IP アドレス範囲になります。
サブネット範囲(外部 IP アドレス範囲をプライベートで使用する範囲も含む)は、クラスタのノードを作成する前に、手動で割り当てるか、GKE によって割り当てる必要があります。クラスタを置き換えない限り、プライベートで使用された外部 IP 範囲の使用への切り替えや使用の停止はできません。
GKE のデフォルトでは、ノードに外部 IP の宛先への SNAT が実装されます。外部 IP アドレスを使用するように Pod CIDR を構成している場合、SNAT ルールは Pod 間トラフィックに適用されます。これを回避するには、2 つの方法があります。
--disable-default-snat
フラグを使用してクラスタを作成します。このフラグの詳細については、GKE での IP マスカレードをご覧ください。- 少なくとも Pod CIDR、Service CIDR、ノードのサブネットの
nonMasqueradeCIDRs
リストに configMapip-masq-agent
を構成します。
IPv4 / IPv6 デュアルスタック ネットワークを使用してデュアルスタック クラスタを作成する
新規または既存のデュアルスタック サブネットに IPv4 / IPv6 デュアルスタック ネットワークを使用するクラスタを作成できます。
このセクションでは、次のタスクを行う方法を説明します。
- デュアルスタック サブネットを作成します(Autopilot クラスタ バージョン 1.25 以降と Standard クラスタ バージョン 1.24 以降で使用可能)。
- 既存のサブネットをデュアルスタックのサブネットに更新します(Autopilot クラスタ バージョン 1.25 以降と Standard クラスタ バージョン 1.24 以降で利用可能)。
- デュアルスタック ネットワーキングを使用したクラスタを作成します(Autopilot クラスタ バージョン 1.25 以降と Standard クラスタ バージョン 1.24 以降で利用可能)。デュアルスタックのサブネットを使用する場合、GKE Autopilot クラスタはデフォルトでデュアルスタック クラスタになります。クラスタの作成後、Autopilot クラスタを IPv4 のみにアップデートできます。
- デュアルスタック クラスタとデュアル スタック サブネットを同時に作成します(Autopilot クラスタ バージョン 1.25 以降と Standard クラスタ バージョン 1.24 以降で使用可能)。
デュアルスタック ネットワーキングの全体像を持つ GKE クラスタの利点と要件の詳細については、VPC ネイティブ クラスタのドキュメントをご覧ください。
デュアルスタックのサブネットを作成する
デュアルスタック サブネットを作成するには、次のコマンドを実行します。
gcloud compute networks subnets create SUBNET_NAME \
--stack-type=ipv4-ipv6 \
--ipv6-access-type=ACCESS_TYPE \
--network=NETWORK_NAME \
--range=PRIMARY_RANGE \
--region=COMPUTE_REGION
次のように置き換えます。
SUBNET_NAME
: 選択したサブネットの名前。ACCESS_TYPE
: 公共のインターネットへのルーティングの可否。限定公開クラスタの場合はINTERNAL
、一般公開クラスタの場合はEXTERNAL
を使用します。--ipv6-access-type
が指定されていない場合、デフォルトのアクセスタイプはEXTERNAL
です。NETWORK_NAME
: 新しいサブネットが追加されるネットワークの名前。このネットワークは、次の条件を満たしている必要があります。- カスタムモードの VPC ネットワークであること。詳細については、VPC ネットワークを自動モードからカスタムモードに切り替える方法をご覧ください。
ACCESS_TYPE
をINTERNAL
に置き換える場合は、ネットワークが一意のローカル IPv6 ユニキャスト アドレス(ULA)を使用していること。
PRIMARY_RANGE
: 新しいサブネットのプライマリ IPv4 IP アドレス範囲(CIDR 表記)。詳細については、サブネットの範囲をご覧ください。COMPUTE_REGION
: クラスタの Compute Engine のリージョン。
既存のサブネットをデュアルスタック サブネットに更新する
既存のサブネットをデュアルスタックのサブネットに更新するには、次のコマンドを実行します。サブネットを更新しても、サブネット内の既存の IPv4 クラスタには影響しません。
gcloud compute networks subnets update SUBNET_NAME \
--stack-type=ipv4-ipv6 \
--ipv6-access-type=ACCESS_TYPE \
--region=COMPUTE_REGION
次のように置き換えます。
SUBNET_NAME
: サブネットの名前。ACCESS_TYPE
: 公共のインターネットへのルーティングの可否。限定公開クラスタの場合はINTERNAL
、一般公開クラスタの場合はEXTERNAL
を使用します。--ipv6-access-type
が指定されていない場合、デフォルトのアクセスタイプはEXTERNAL
です。COMPUTE_REGION
: クラスタの Compute Engine のリージョン。
デュアルスタック ネットワーキングを使用するクラスタを作成する
既存のデュアルスタック サブネットを持つクラスタを作成するには、gcloud CLI
または Google Cloud コンソールを使用します。
gcloud
Autopilot クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create-auto CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --network=NETWORK_NAME \ --subnetwork=SUBNET_NAME
次のように置き換えます。
CLUSTER_NAME
: 新しい Autopilot クラスタの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。NETWORK_NAME
: サブネットを含む VPC ネットワークの名前。この VPC ネットワークは、カスタムモードの VPC ネットワークである必要があります。詳細については、VPC ネットワークを自動モードからカスタムモードに切り替える方法をご覧ください。SUBNET_NAME
: デュアルスタック サブネットの名前。詳細については、デュアルスタック サブネットを作成するをご覧ください。デュアルスタックのサブネットを使用する場合、GKE Autopilot クラスタはデフォルトでデュアルスタック クラスタになります。クラスタの作成後、Autopilot クラスタを IPv4 のみにアップデートできます。
Standard クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create CLUSTER_NAME \ --enable-ip-alias \ --enable-dataplane-v2 \ --stack-type=ipv4-ipv6 \ --network=NETWORK_NAME \ --subnetwork=SUBNET_NAME \ --location=COMPUTE_LOCATION
次のように置き換えます。
CLUSTER_NAME
: 新しいクラスタの名前。NETWORK_NAME
: サブネットを含む VPC ネットワークの名前。この VPC ネットワークは、一意のローカル IPv6 ユニキャスト アドレス(ULA)を使用するカスタムモードの VPC ネットワークである必要があります。詳細については、VPC ネットワークを自動モードからカスタムモードに切り替える方法をご覧ください。SUBNET_NAME
: サブネットの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[add_box 作成] をクリックします。
[Standard] セクションまたは [Autopilot] セクションで、[構成] をクリックします。
必要に応じてクラスタを構成します。
ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[ネットワーク] リストで、ネットワークの名前を選択します。
[ノードのサブネット] リストで、デュアルスタック サブネットの名前を選択します。
Standard クラスタの場合は、[IPv4 と IPv6(デュアル スタック)] ラジオボタンを選択します。このオプションは、デュアルスタック サブネットを選択した場合にのみ使用できます。
デュアルスタックのサブネットを使用する場合、Autopilot クラスタはデフォルトでデュアルスタック クラスタになります。
[作成] をクリックします。
デュアルスタック クラスタとサブネットを同時に作成する
サブネットとデュアル スタック クラスタは同時に作成できます。GKE は IPv6 サブネットを作成し、そのサブネットに外部 IPv6 プライマリ範囲を割り当てます。
Autopilot クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create-auto CLUSTER_NAME \ --location=COMPUTE_LOCATION \ --network=NETWORK_NAME \ --create-subnetwork name=SUBNET_NAME
次のように置き換えます。
CLUSTER_NAME
: 新しい Autopilot クラスタの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。NETWORK_NAME
: サブネットを含む VPC ネットワークの名前。この VPC ネットワークは、一意のローカル IPv6 ユニキャスト アドレス(ULA)を使用するカスタムモードの VPC ネットワークである必要があります。詳細については、VPC ネットワークを自動モードからカスタムモードに切り替える方法をご覧ください。SUBNET_NAME
: 新しいサブネットの名前。GKE は、組織のポリシーに基づいてサブネットを作成できます。- 組織のポリシーでデュアルスタックが許可され、ネットワークがカスタムモードの場合、GKE はデュアルスタック サブネットを作成し、そのサブネットに外部 IPv6 プライマリ範囲を割り当てます。
- 組織のポリシーでデュアルスタックが許可されていないか、ネットワークが自動モードの場合、GKE はシングルスタック(IPv4)サブネットを作成します。
Standard クラスタの場合は、次のコマンドを実行します。
gcloud container clusters create CLUSTER_NAME \ --enable-ip-alias \ --stack-type=ipv4-ipv6 \ --ipv6-access-type=ACCESS_TYPE \ --network=NETWORK_NAME \ --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \ --location=COMPUTE_LOCATION
次のように置き換えます。
CLUSTER_NAME
: 選択した新しいクラスタの名前。ACCESS_TYPE
: 公共のインターネットへのルーティングの可否。限定公開クラスタの場合はINTERNAL
、一般公開クラスタの場合はEXTERNAL
を使用します。--ipv6-access-type
が指定されていない場合、デフォルトのアクセスタイプはEXTERNAL
です。NETWORK_NAME
: 新しいサブネットが追加されるネットワークの名前。このネットワークは、次の条件を満たしている必要があります。- カスタムモードの VPC ネットワークであること。詳細については、VPC ネットワークを自動モードからカスタムモードに切り替える方法をご覧ください。
ACCESS_TYPE
をINTERNAL
に置き換える場合は、ネットワークが一意のローカル IPv6 ユニキャスト アドレス(ULA)を使用していること。
SUBNET_NAME
: 選択した新しいサブネットの名前。PRIMARY_RANGE
: 新しいサブネットのプライマリ IPv4 アドレス範囲(CIDR 表記)。詳細については、サブネットの範囲をご覧ください。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。
既存のクラスタのスタックタイプを更新する
既存のクラスタのスタックタイプを変更できます。既存のクラスタのスタックタイプを変更する前に、次の制限事項を考慮してください。
スタックタイプの変更は、バージョン 1.25 以降を実行している新しい GKE クラスタでサポートされています。バージョン 1.24 からバージョン 1.25 または 1.26 にアップグレードされた GKE クラスタでは、デュアルスタック ネットワークを有効にすると検証エラーが発生することがあります。 エラーが発生した場合は、Google Cloud のサポートチームにお問い合わせください。
GKE はコントロール プレーンとノードの両方でコンポーネントを再起動させるため、スタックタイプの変更は中断を伴うオペレーションとなります。
GKE は、ノードを再作成するときに、構成済みのメンテナンスの時間枠を考慮します。つまり、次のメンテナンスの時間枠になるまで、クラスタ スタックタイプはクラスタで動作しません。この待機を回避するには、すでにコントロール プレーンが動作している GKE バージョンを
--cluster-version
フラグに設定して、ノードプールを手動でアップグレードします。この回避策を行う場合は、gcloud CLI を使用する必要があります。詳細については、メンテナンス時間枠の注意点をご覧ください。スタックタイプを変更しても、既存の Service の IP ファミリーは自動的に変更されません。次の条件が適用されます。
- シングル スタックをデュアルスタックに変更しても、既存の Service はシングル スタックのままです。
- デュアルスタックをシングル スタックに変更すると、IPv6 アドレスを持つ既存の Service がエラー状態になります。この Service を削除し、正しい
ipFamilies
を持つ Service を作成します。詳細については、Deployment の設定方法の例をご覧ください。
既存の VPC ネイティブ クラスタを更新するには、gcloud CLI または Google Cloud コンソールを使用します。
gcloud
次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \
--stack-type=STACK_TYPE \
--location=COMPUTE_LOCATION
次のように置き換えます。
CLUSTER_NAME
: 更新するクラスタの名前。STACK_TYPE
: スタックタイプ。次のいずれかの値に置き換えます。ipv4
: デュアルスタック クラスタを IPv4 のみのクラスタに更新します。GKE は、クラスタのサブネットのプライマリ IPv4 アドレス範囲を使用します。ipv4-ipv6
: 既存の IPv4 クラスタをデュアルスタックに更新します。クラスタをデュアル スタックに変更できるのは、基盤となるサブネットがデュアル スタックをサポートしている場合のみです。詳細については、既存のサブネットをデュアルスタックのサブネットに更新するをご覧ください。
COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
編集するクラスタの横にあるmore_vert [アクション] をクリックし、[edit 編集] をクリックします。
[ネットワーキング] セクションで、[スタックタイプ] の横にある [編集] をクリックします。edit
[スタックタイプの編集] ダイアログで、必要なクラスタ スタックタイプのチェックボックスを選択します。
[変更内容を保存] をクリックします。
IPv4 / IPv6 デュアルスタック Service を作成する
ClusterIP
または NodePort
タイプの IPv4 / IPv6 デュアルスタック Service を作成できます。バージョン 1.29 以降を実行している新しい GKE クラスタは、LoadBalancer
タイプのデュアルスタック Service をサポートしています。詳細については、IPv4 / IPv6 デュアルスタック LoadBalancer Service をご覧ください。
これらの Service タイプごとに、ipFamilies
フィールドと ipFamilyPolicy
フィールドを IPv4、IPv6、デュアルスタックとして定義できます。詳細については、IPv4 / IPv6 デュアルスタック Service をご覧ください。
スタックタイプ、Pod、Service の IP アドレス範囲を確認する
VPC ネイティブ クラスタを作成すると、その Pod と Service の範囲を確認できます。
gcloud
クラスタを確認するには、次のコマンドを実行します。
gcloud container clusters describe CLUSTER_NAME
出力には ipAllocationPolicy
ブロックが含まれます。stackType
フィールドは、ネットワーク定義のタイプを表します。タイプごとに、次のネットワーク情報を確認できます。
IPv4 ネットワーク情報:
clusterIpv4Cidr
が、Pod のセカンダリ範囲です。servicesIpv4Cidr
が、Service のセカンダリ範囲です。
IPv6 ネットワーク情報(クラスタにデュアルスタック ネットワーキングがある場合):
ipv6AccessType
: 公共のインターネットへのルーティングの可否。プライベート IPv6 アドレスの場合はINTERNAL
、パブリック IPv6 アドレスの場合はEXTERNAL
。subnetIpv6CidrBlock
: 新しいサブネットのセカンダリ IPv6 アドレス範囲です。servicesIpv6CidrBlock
: デュアルスタック クラスタの IPv6 Service に割り当てられたアドレス範囲。
コンソール
クラスタを確認するには、次の手順で操作します。
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
クラスタリストで、検査するクラスタの名前をクリックします。
セカンダリ範囲は [ネットワーキング] セクションに表示されます。
- [Pod のアドレス範囲] は、Pod のセカンダリ範囲です。
- [Service のアドレスの範囲] は、Service のセカンダリ範囲です。
トラブルシューティング
このセクションでは、VPC ネイティブ クラスタに関連する問題を解決するためのガイダンスを示します。GKE IP アドレスの使用率の分析情報を表示することもできます。デフォルトのネットワーク リソースの準備ができていない
- 現象
次のようなエラー メッセージが表示されます。
projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
- 考えられる原因
同じサブネット上に並列オペレーションがあります。たとえば、別の VPC ネイティブ クラスタが作成されている、サブネット上でセカンダリ範囲の追加または削除が行われている、などです。
- 解決策
コマンドを再試行します。
IPCidrRange
が無効な値である
- 現象
次のようなエラー メッセージが表示されます。
resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
- 考えられる原因
別の VPC ネイティブ クラスタが同時に作成されていて、同じ VPC ネットワークの同じ範囲を割り振ろうとしています。
同じセカンダリ範囲が同じ VPC ネットワークのサブネットワークに追加されようとしています。
- 解決策
セカンダリ範囲がまだ指定されていない状態でクラスタ作成コマンドを実行して、このエラーが返された場合は、しばらくしてからクラスタの作成コマンドを再試行してください。
Pod 用の空き IP アドレス空間が不足している
- 現象
クラスタが長い時間プロビジョニング状態で停止しています。
クラスタの作成時にマネージド インスタンス グループ(MIG)エラーが返されます。
1 つ以上のノードをクラスタに追加すると、次のエラーが表示されます。
[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME-SECONDARY_RANGE_NAME' is exhausted.
- 考えられる原因
ノードの IP アドレスの枯渇: クラスタに割り当てられたサブネットのプライマリ IP アドレス範囲で使用可能な IP アドレスが不足しています。これは通常、ノードプールのスケーリング時や大規模なクラスタの作成時に発生します。
Pod IP アドレスの枯渇: クラスタに割り当てられた Pod CIDR 範囲がいっぱいです。これは、Pod の数が Pod CIDR の容量を超えた場合に発生します。特に、ノードあたりの Pod 密度が高い場合や、大規模なデプロイの場合に発生します。
サブネットの特定の命名規則: エラー メッセージ内のサブネットの命名方法は、問題がノード IP アドレス範囲(ノード自体が IP アドレスを取得する場所)に関するものであるか、Pod IP アドレス範囲(Pod 内のコンテナが IP アドレスを取得する場所)に関するものであるかを確認するのに役立ちます。
セカンダリ範囲の枯渇(Autopilot): Autopilot クラスタでは、Pod IP アドレスに割り当てられたセカンダリ範囲が、スケーリングまたは高密度の Pod が原因で枯渇します。
- 解決策
クラスタの名前、コントロール プレーンのバージョン、オペレーション モード、関連付けられた VPC 名、サブネット名、CIDR などの情報を収集します。また、デフォルトおよび追加のクラスタ Pod の IPv4 範囲(名前と CIDR を含む)、VPC ネイティブ トラフィック ルーティングが有効になっているかどうか、クラスタレベルとノードプール レベルの両方で設定されているノードあたりの Pod の最大数(該当する場合)を確認します。影響を受けるノードプールと、それらの特定の IPv4 Pod の IP アドレス範囲とノードあたりの Pod の最大構成(クラスタ全体の設定と異なる場合)を確認します。また、ノードプール構成で、ノードあたりの最大 Pod 数のデフォルト構成とカスタム構成(存在する場合)を記録します。
IP アドレスの枯渇に関する問題を確認する
Network Intelligence Center: GKE クラスタの Network Intelligence Center で Pod の IP アドレス範囲の IP アドレス割り振り率が高いかどうかを確認します。
Network Intelligence Center 内の Pod 範囲で IP アドレスの割り振り率が高い場合は、Pod の IP アドレス範囲が枯渇しています。
Pod の IP アドレス範囲に通常の割り振り率が表示されているにもかかわらず、IP アドレスの枯渇が引き続き発生している場合は、ノードの IP アドレス範囲が枯渇している可能性があります。
監査ログ:
IP_SPACE_EXHAUSTED
エントリのresourceName
フィールドを調べて、サブネット名またはセカンダリ Pod の IP アドレス範囲名と比較します。枯渇した IP アドレス範囲がノードの IP アドレス範囲か Pod の IP アドレス範囲かを確認します。
枯渇した IP アドレス範囲がノードの IP アドレス範囲か Pod の IP アドレス範囲かを確認するには、
IP_SPACE_EXHAUSTED
ログエントリのipSpaceExhausted
部分にあるresourceName
の値が、影響を受ける GKE クラスタで使用されている Pod のサブネット名またはセカンダリ IPv4 アドレス範囲の名前と関連付けられているかどうかを確認します。resourceName
の値が「[Subnet_name]」形式の場合、ノードの IP アドレス範囲が枯渇しています。resourceName の値が「[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]」形式の場合、Pod の IP アドレス範囲が枯渇しています。
Pod の IP アドレスの枯渇を解決します。
- 既存の Pod CIDR のサイズを変更する: 現在の Pod の IP アドレス範囲のサイズを増やします。連続していないマルチ Pod CIDR を使用して、Pod IP 範囲をクラスタに追加できます。
- 追加のサブネットを作成する: 専用の Pod CIDR を持つサブネットをクラスタに追加します。
IP アドレスを解放するために、ノードあたりの Pod 数を減らします。
- ノードあたりの Pod 最大数が少ない新しいノードプールを作成します。
- ワークロードをそのノードプールに移行してから、以前のノードプールを削除してください。ノードあたりの Pod 最大数を減らすと、Pod の固定されたセカンダリ IP アドレス範囲でより多くのノードをサポートできるようになります。関連する計算の詳細については、Pod 用のサブネット セカンダリ IP アドレス範囲とノード制限範囲をご覧ください。
ノードの IP アドレスの枯渇を解決します。
- IP アドレスの計画を確認する: ノードの IP アドレス範囲がスケーリング要件と一致していることを確認します。
- 新しいクラスタを作成する(必要な場合): ノードの IP アドレス範囲が厳しく制約されている場合は、適切な IP アドレス範囲のサイズを持つ代替クラスタを作成します。VPC ネイティブ クラスタの IP 範囲と IP 範囲の計画をご覧ください。
gcpdiag
を使用して IP アドレスの枯渇に関する問題をデバッグする
gcpdiag
はオープンソース ツールです。正式にサポートされている Google Cloud プロダクトではありません。gcpdiag
ツールを使用すると、Google Cloud プロジェクトの問題を特定して修正できます。詳細については、GitHub の gcpdiag プロジェクトをご覧ください。
- クラスタのステータス: IP アドレスの枯渇が報告された場合、クラスタのステータスを確認します。
- ネットワーク アナライザ: ネットワーク アナライザのログに対して Stackdriver ログにクエリを実行し、Pod またはノードの IP アドレスが枯渇していないかどうかを確認します。
- クラスタタイプ: クラスタタイプを確認し、クラスタタイプに基づいて関連する推奨事項を提供します。
Google Cloud コンソール
- 次のコマンドを入力してコピーします。
- Google Cloud コンソールを開き、Cloud Shell をアクティブにします。 Cloud コンソールを開く
- コピーしたコマンドを貼り付けます。
gcpdiag
コマンドを実行します。gcpdiag
Docker イメージがダウンロードされ、診断チェックが実行されます。必要に応じて、出力の指示に沿って、失敗したチェックを修正します。
gcpdiag runbook gke/ip-exhaustion --project=PROJECT_ID \
--parameter name=CLUSTER_NAME \
--parameter location=ZONE|REGION \
--parameter start_time=yyyy-mm-ddThh:mm:ssZ \
--parameter end_time=yyyy-mm-ddThh:mm:ssZ \
Docker
Docker コンテナで gcpdiag
を起動するラッパーを使用して gcpdiag
を実行できます。Docker または Podman がインストールされている必要があります。
- ローカル ワークステーションで次のコマンドをコピーして実行します。
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
-
gcpdiag
コマンドを実行します。./gcpdiag runbook gke/ip-exhaustion --project=PROJECT_ID \ --parameter name=CLUSTER_NAME \ --parameter location=ZONE|REGION \ --parameter start_time=yyyy-mm-ddThh:mm:ssZ \ --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
このランブックで使用可能なパラメータを表示します。
次のように置き換えます。
- PROJECT_ID: リソースを含むプロジェクトの ID。
- CLUSTER_NAME: プロジェクト内のターゲット GKE クラスタの名前。
- LOCATION: クラスタが配置されているゾーンまたはリージョン。
- start_time: 問題が発生した時刻。
- end_time: 問題が終了した時刻。問題が継続している場合は、現在の時刻を設定します。
有用なフラグ:
--project
: PROJECT_ID--universe-domain
: 該当する場合、リソースをホストする信頼できるパートナーのソブリン クラウド ドメイン--parameter
または-p
: ランブック パラメータ
gcpdiag
ツールのフラグの一覧と説明については、gcpdiag
の使用手順をご覧ください。
デフォルトの SNAT が無効になっているかどうか確認する
デフォルトの SNAT のステータスを確認するには、次のコマンドを使用します。
gcloud container clusters describe CLUSTER_NAME
CLUSTER_NAME
は、使用するクラスタの名前に置き換えます。
出力は次のようになります。
networkConfig:
disableDefaultSnat: true
network: ...
--enable-ip-alias
なしで --disable-default-snat
は使用できない
このエラー メッセージと must disable default sNAT (--disable-default-snat)
before using public IP address privately in the cluster
が表示された場合、限定公開クラスタでパブリック IP アドレスが使用されているため、クラスタの作成時に --disable-default-snat
フラグを明示的に設定する必要があります。
cannot disable default sNAT ...
などのエラー メッセージが表示された場合、クラスタでデフォルトの SNAT を無効にすることはできません。この問題を解決するには、クラスタの構成を確認します。
デフォルトの SNAT を無効にして Cloud NAT をデバッグする
--disable-default-snat
フラグを使用して限定公開クラスタを作成し、インターネット アクセスに Cloud NAT を設定しているときに、Pod からインターフェースに向かうトラフィックが表示されない場合は、Cloud NAT 構成に Pod の範囲が含まれていることを確認します。
Pod 間の通信に問題がある場合は、ノードの iptables ルールを調べて、Pod 範囲が iptables ルールによってマスカレードされていないことを確認します。
詳細については、GKE IP マスカレードのドキュメントをご覧ください。クラスタに IP マスカレード エージェントが構成されていない場合、GKE は Pod 間の通信が自動的にマスカレードされないようにします。IP マスカレード エージェントが構成されている場合は、デフォルトの IP マスカレード ルールがオーバーライドされます。Pod 範囲のマスカレードを無視するように、IP マスカレード エージェントで追加のルールが構成されていることを確認します。
デュアルスタック クラスタのネットワーク通信が想定どおりに機能していない
- 考えられる原因
- GKE クラスタによって作成されたファイアウォール ルールに、割り振られた IPv6 アドレスが含まれていません。
- 解決策
- 次の手順でファイアウォール ルールを検証できます。
ファイアウォール ルールの内容を確認します。
gcloud compute firewall-rules describe FIREWALL_RULE_NAME
FIREWALL_RULE_NAME
の部分は、ファイアウォール ルールの名前に置き換えます。各デュアルスタック クラスタは、ノードと Pod が相互に通信できるようにするファイアウォール ルールを作成します。ファイアウォール ルールの内容は、次のようになります。
allowed: - IPProtocol: esp - IPProtocol: ah - IPProtocol: sctp - IPProtocol: tcp - IPProtocol: udp - IPProtocol: '58' creationTimestamp: '2021-08-16T22:20:14.747-07:00' description: '' direction: INGRESS disabled: false enableLogging: false id: '7326842601032055265' kind: compute#firewall logConfig: enable: false name: gke-ipv6-4-3d8e9c78-ipv6-all network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet priority: 1000 selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265 sourceRanges: - 2600:1900:4120:fabf::/64 targetTags: - gke-ipv6-4-3d8e9c78-node
sourceRanges
値はsubnetIpv6CidrBlock
と同じである必要があります。targetTags
値は GKE ノードのタグと同じである必要があります。この問題を解決するには、クラスタのipAllocationPolicy
ブロックの情報を使用して、ファイアウォール ルールを更新します。
クラスタの削除中に Private Service Connect エンドポイントが漏洩する可能性がある
- 現象
Private Service Connect ベースのクラスタの Private Service Connect に接続されたエンドポイントが表示されない。
Private Service Connect エンドポイントが割り当てられているサブネットまたは VPC ネットワークは削除できません。次のようなエラー メッセージが表示されます。
projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
- 考えられる原因
Private Service Connect を使用する GKE クラスタでは、コントロール プレーンのネットワークでクラスタのコントロール プレーンにアクセスするために内部 IP アドレスを割り振る転送ルールを使用して、Private Service Connect エンドポイントをデプロイします。Private Service Connect を使用してコントロール プレーンとノードの間の通信を保護するため、GKE はエンドポイントを非表示にします。Google Cloud コンソールまたは gcloud CLI でエンドポイントは表示されません。
- 解決策
クラスタの削除前に Private Service Connect エンドポイントが漏洩しないようにするには、次の操作を行います。
Kubernetes Engine Service Agent role
を GKE サービス アカウントに割り当てます。compute.forwardingRules.*
権限とcompute.addresses.*
権限が GKE サービス アカウントから明示的に拒否されていないことを確認します。
Private Service Connect エンドポイントが漏洩している場合は、サポートにお問い合わせください。