VPC ネイティブ クラスタ

このページでは、Google Kubernetes Engine（GKE）の VPC ネイティブ クラスタの概要について説明します。

このページは、組織のネットワークを設計するクラウド アーキテクトとネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

概要

GKE では、ある Pod から別の Pod にトラフィックをルーティングする方法によってクラスタを区別できます。

エイリアス IP アドレス範囲を使用するクラスタは、VPC ネイティブ クラスタと呼ばれます。

VPC ネットワーク内でカスタム静的ルートを使用するクラスタは、ルートベース クラスタと呼ばれます。

VPC ネイティブ クラスタのメリット

VPC ネイティブ クラスタには次のようなメリットがあります。

• Pod の IP アドレスは、クラスタの VPC ネットワーク内と、VPC ネットワーク ピアリングで接続された他の VPC ネットワーク内でネイティブにルーティングできます。

• Pod の IP アドレスは、クラスタ内で Pod が作成される前に VPC ネットワークで予約されます。これにより、VPC ネットワーク上のその他のリソースとの競合が回避され、IP アドレスの割り振りをより適切に計画できるようになります。

• Pod の IP アドレス範囲はカスタム静的ルートに依存しません。システム生成ルートとカスタム静的ルートのリソース割り当てを消費しません。代わりに、自動生成されたサブネット ルートによって、VPC ネイティブ クラスタのルーティングが処理されます。

• クラスタのノード上にある IP アドレスではなく、Pod IP アドレスの範囲のみに適用されるファイアウォール ルールを作成できます。

• 一般に、Pod の IP アドレス範囲とサブネット セカンダリ IP アドレス範囲には、Cloud Router を使用して、Cloud VPN または Cloud Interconnect に接続されているオンプレミス ネットワークからアクセスできます。

• ネットワーク エンドポイント グループ（NEG）などの一部の機能は、VPC ネイティブ クラスタでのみ動作します。

デフォルトのクラスタ ネットワーク モード

VPC ネイティブは、GKE バージョン 1.21.0-gke.1500 以降のすべてのクラスタで、デフォルトのネットワーク モードです。以前のバージョンでは、デフォルトのクラスタ ネットワーク モードは、クラスタの作成方法によって異なります。

次の表に、GKE クラスタのバージョンとクラスタの作成方法に対応する、デフォルトのクラスタ ネットワーク モードを示します。

クラスタの作成時に --no-enable-ip-alias フラグを指定して、ルートベース クラスタを作成することもできます。

VPC ネイティブ クラスタの IP アドレス範囲

VPC ネイティブ クラスタを作成するときは、VPC ネットワーク内のサブネットを指定します。クラスタでは、次のサブネット IP アドレス範囲が使用されます。

IPv4 アドレスの割り振り

VPC ネイティブ クラスタでは、次のように指定されたサブネット内の個別の範囲を使用して、ノード、Pod、Service に IPv4 アドレスが割り振られます。

• ノードの IP アドレス: クラスタでは、サブネットのプライマリ IPv4 アドレス範囲を使用して、すべてのノードに IP アドレスが割り当てられます。

• Pod の IP アドレス: クラスタでは、クラスタ内のすべての Pod IPv4 アドレスにサブネット内のセカンダリ IPv4 アドレス範囲が使用されます。柔軟性を高めるために、不連続マルチ Pod CIDR を構成することで、追加のサブネット セカンダリ IPv4 アドレス範囲を使用できます。

• Service の IP アドレス: クラスタは、すべての Service（クラスタの IP）アドレスに個別のセカンダリ IP アドレス範囲が使用されます。複数のクラスタで同じ Service IPv4 範囲を共有する方法については、GKE クラスタ間で IP アドレス範囲を共有するをご覧ください。

IPv6 アドレスの割り振り（デュアルスタック ネットワーキング）

• ノードと Pod の IPv6 アドレス: デュアルスタック ネットワーキングが有効になっているクラスタでは、ノードの IPv6 アドレスとすべての Pod の IPv6 アドレスは、ノードに指定された /96 IPv6 アドレス範囲から割り振られます。ノードの IP アドレス自体が、この範囲内の最初の /128（単一の IPv6 アドレス）になります。詳細については、デュアルスタック ネットワーキングをご覧ください。

次の表に、ノード、Pod、Service の IP アドレス範囲の概要を示します。

内部 IP アドレス

VPC ネイティブ クラスタのサブネットには、有効なサブネット範囲の IP アドレスを使用する必要があります。有効な範囲には、プライベート IP アドレス（RFC 1918 など）と、プライベートで使用されたパブリック IP アドレスが含まれます。有効なサブネット範囲の詳細については、VPC のドキュメントで有効な範囲と制限付きの範囲をご覧ください。

これらの範囲を有効にする手順については、RFC 1918 以外のプライベート IP アドレス範囲を使用するをご覧ください。

これらの範囲を使用する手順については、パブリック IP アドレス範囲のプライベートでの利用を有効にするをご覧ください。

セカンダリ範囲の割り当て方法

Pod の IP アドレス範囲と Service（ClusterIP）のアドレス範囲を VPC ネイティブ クラスタに割り当てることができます。これらの IP アドレス範囲は、GKE で管理することも、ユーザーが管理することもできます。

セカンダリ範囲の割り当て方法を理解するには、次の主な用語を理解しておく必要があります。

割り当て: IP アドレス範囲の割り当ては、特定のサブネット範囲を VPC ネイティブ クラスタに割り振るプロセスを指します。これにより、Pod や Service など、コンポーネントがクラスタ内で使用できる IP アドレスのプールが確立されます。

管理: IP アドレス範囲の管理とは、VPC ネイティブ クラスタ内の割り当てられたサブネット範囲とリソースの割り当てに関連する、クラスタ、ノードプール、または Pod レベルで実行中の CRUD オペレーション（作成、更新、削除、読み取り）を指します。

GKE が管理するセカンダリ範囲（デフォルト）

バージョン 1.27 以降を実行している GKE Autopilot クラスタと、バージョン 1.29 以降を実行している GKE Standard クラスタの場合、GKE は GKE が管理する範囲（デフォルトでは 34.118.224.0/20）から Service の IP アドレスを割り当てます。これにより、Service に独自の IP アドレス範囲を指定する必要がなくなります。次のことに注意してください。

• 必要に応じて、--services-ipv4-cidr フラグを使用して Service のカスタム範囲を指定できます。
• --services-ipv4-cidr フラグを使用して範囲のサイズのみを指定しても（たとえば /22）、GKE は引き続き GKE が管理する範囲を使用してアドレスのサブ範囲を取得します。
• GKE が管理する範囲が使用されている場合、GKE は Service 用に別のセカンダリ IP アドレス範囲を作成しません。

ユーザー管理

IP アドレスの割り振りを完全に制御するには、VPC ネイティブ クラスタのサブネットを手動で管理します。

サブネットのセカンダリ IP アドレス範囲を作成し、その範囲を使用するクラスタを作成できます。クラスタの作成時に、Pod と Service のサブネット範囲名を指定します。セカンダリ範囲を手動で作成する場合は、ご自身で管理する必要があります。

不連続マルチ Pod CIDR を使用せずに作成できる最小の IP アドレス範囲は /28 ですが、その範囲では Pod 数最大 8 個のノードが 1 つしか作成できません。必要な最大ノード数に応じて、十分な大きさの範囲を使用する必要があります。

使用可能な最小範囲は、ノードあたりの Pod の最大数によっても異なります。

ノードあたりの Pod の最大数に応じて使用できる CIDR の最小範囲については、IP アドレス割り振りの最適化に記載されている表をご覧ください。

Pod の IP アドレス範囲が不足している場合は、次のいずれかを行う必要があります。

• より大きな Pod アドレス範囲を持つクラスタを再作成する。
• ノードプールの --max-pods-per-node を減らしてから、ノードプールを再作成する。
• 不連続マルチ Pod CIDR を使用して、セカンダリ Pod IP アドレス範囲を拡張する。

ルートベース クラスタとの違い

Pod と Service（ClusterIP）のアドレスの割り振り方式は、ルートベース クラスタによって使用される方式とは異なります。Pod と Service に対して単一の CIDR を一緒に指定するのではなく、1 つは Pod 用、もう 1 つは Service 用として、クラスタのサブネットで 2 つのセカンダリ IP アドレス範囲を選択または作成する必要があります。

共有 VPC に関する考慮事項

VPC ネイティブ クラスタを共有 VPC 環境に作成する場合、共有 VPC ホスト プロジェクトでネットワーク管理者ロールを持つプロジェクト オーナー、編集者、または Identity and Access Management（IAM）プリンシパルが、クラスタのサブネットとセカンダリ IP アドレス範囲を手動で作成する必要があります。クラスタを作成するサービス プロジェクト管理者は少なくとも、共有 VPC ネットワークのホスト プロジェクト内にあるサブネットに対するサブネット レベルの権限を持っている必要があります。

共有 VPC 環境では、GKE でセカンダリ IP アドレス範囲を管理することはできません。共有 VPC ホスト プロジェクトのネットワーク管理者は、クラスタを作成する前にサブネットとセカンダリ IP アドレス範囲を作成する必要があります。たとえば、共有 VPC ネットワークで VPC ネイティブ クラスタをセットアップする方法を確認するには、共有 VPC を使用したクラスタの設定をご覧ください。

IP アドレス範囲の計画

以下のセクションの情報を使用して、クラスタによって使用されるサブネットのプライマリ IP アドレス範囲とセカンダリ IP アドレス範囲のサイズを計算してください。

サブネットのプライマリ IP アドレス範囲

プライマリ ノードの IP アドレス範囲を計画する際は、次の条件を考慮してください。

• すべてのサブネットにプライマリ IP アドレス範囲が必要です。これは、GKE が内部ロードバランサとノードに IP アドレスを割り振るために使用する IP アドレス範囲です。
• サブネットの作成後に、サブネットのプライマリ IP アドレス範囲を縮小または変更することはできません。
• プライマリ IP アドレス範囲の最初の 2 つと最後の 2 つの IP アドレスは、Google Cloud によって予約されています。
• Private Service Connect を使用するクラスタは、プライマリ サブネット範囲を使用して、コントロール プレーン エンドポイントに割り当てられた内部 IP アドレスをプロビジョニングします。ただし、private-endpoint-subnetwork フラグを使用して、この IP アドレスのプロビジョニングをオーバーライドできます。詳細については、クラスタを作成してコントロール プレーンの IP アドレス範囲を選択するをご覧ください。

次の表に、サブネットのプライマリ IP アドレス範囲のサイズとクラスタ構成を考慮して、作成可能なノードの最大数を示します。

• シナリオ 1: デフォルトのサブネットを使用するクラスタ内の最大ノード数。
• シナリオ 2: private-endpoint-subnetwork フラグを使用しない Private Service Connect クラスタ内の最大ノード数。

プライマリ IP アドレス範囲を拡張する

プライマリ IP アドレス範囲の IP アドレスが不足した場合、ロードバランサやネットワーク エンドポイント グループなどの Google Cloud リソースがサブネットを使用していても、プライマリ IP アドレス範囲を拡張できます。

プライマリ IP アドレス範囲を拡張する前に、次の点を考慮してください。

• サブネット内の IP アドレス範囲は重複してはいけません。
• GKE は、プライマリ IP アドレス範囲を使用して、内部ロードバランサとノードに IP アドレスを割り振ります。

有用な数式

次の数式をお使いください。

• デフォルトのサブネットを使用するクラスタで、指定したネットマスクがサポートできるノードの最大数（N）を計算します。ネットマスクのサイズには S を使用します。この有効範囲は 8 から 29 までです（両端の値を含む）。

  N = 2^{(32 -S)} - 4

• 最大数 N のノードをサポートするために必要なネットマスクのサイズ S を計算します。

  S = 32 - ⌈log₂(N + 4)⌉

  ⌈⌉ は天井（最小の整数）関数であり、次の整数に切り上げます。ネットマスクのサイズ S の有効な範囲は、8 から 29 までです（両端の値を含む）。

private-endpoint-subnetwork フラグを使用しない Private Service Connect クラスタでは、上記の式を使用できますが、N の値を 1 減らします。

Pod 用のサブネットのセカンダリ IP アドレス範囲

Pod のセカンダリ IP アドレス範囲は慎重に計画してください。

次の表に、Pod によって使用されるサブネットのセカンダリ IP アドレス範囲を考慮して、サブネットを使用するすべてのクラスタで作成できるノードと Pod の最大数を示します。

この表では、ノードあたりの Pod の最大数はデフォルトの Pod 密度である 110 であると想定されています。

ノードあたりの Pod の最大数を変更した場合、次の数式を使用して、Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできるノードと Pod の最大数を計算できます。

1. 各ノードの Pod 範囲のネットマスクのサイズ M を計算します。
   M = 31 - ⌈log2(Q)⌉ ここで

   • Q は、ノードあたりの Pod の数です。
   • ⌈⌉ は、天井（最小の整数）関数であり、次の整数に切り上げます。
   • たとえば、Q が 110 の場合、 M = 24 になります。

2. Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできるノードの最大数 N を計算します。
   N = 2(M - S) ここで

   • M は、最初のステップで計算された Pod の各ノードのエイリアス IP アドレス範囲のネットマスクのサイズです。
   • S は、サブネットのセカンダリ IP アドレス範囲のサブネット マスクのサイズです。
   • たとえば、M が 24、S が 20 の場合、 N = 16 になります。

3. Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできる Pod の最大数 P を計算します。
   P = N × Q ここで

   • N は、前のステップで計算されたノードの最大数です。
   • Q は、ノードあたりの Pod の数です。
   • たとえば、N が 16 で、Q が 110 の場合、 P = 1760 になります。

不連続マルチ Pod CIDR を使用すると、Pod に IP アドレスを追加できます。

Service 用のサブネット セカンダリ IP アドレス範囲

Service のセカンダリ IP アドレス範囲は慎重に計画してください。これはサブネット セカンダリ IP アドレス範囲でもあるため、クラスタの作成後にこの範囲を変更することはできません。

マルチクラスタ サービスを使用する場合、ServiceImport オブジェクトは Service のセカンダリ IP アドレス範囲の IP アドレスを使用します。

バージョン 1.27 以降を実行している GKE Autopilot クラスタと、バージョン 1.29 以降を実行している GKE Standard クラスタの場合、GKE は GKE が管理する範囲（デフォルトでは 34.118.224.0/20）から Service の IP アドレスを割り当てます。これにより、Service に独自の IP アドレス範囲を指定する必要がなくなります。次のことに注意してください。

• 必要に応じて、--services-ipv4-cidr フラグや --services-secondary-range-name フラグを使用して、Service のカスタム範囲を指定できます。
• --services-ipv4-cidr フラグを使用して範囲のサイズのみを指定しても（たとえば /22）、GKE は引き続き GKE が管理する範囲を使用してアドレスのサブ範囲を取得します。
• Google が管理する範囲が使用されている場合、GKE は Service 用に別のセカンダリ IP アドレス範囲を作成しません。GKE が管理する範囲では、サブネットのセカンダリ IP アドレス範囲の割り当てが使用されません。

次の表には、Service 用のサブネット セカンダリ IP アドレス範囲のサイズを考慮して、サブネットを使用する単一のクラスタで作成できる Service の最大数が示されています。

GKE クラスタ間で IP アドレス範囲を共有する

同じサブネットワーク内のクラスタ間で、プライマリ範囲、Pod のセカンダリ IP アドレス範囲、Service のセカンダリ IP アドレス範囲を共有できます。

この動作は、Standard クラスタと Autopilot クラスタの両方で使用できます。

クラスタのインフラストラクチャを一元管理するチームがある場合は、IP アドレス範囲を共有することをおすすめします。特に共有 VPC モデルでは、Pod、Service、ノードの 3 つの範囲を作成し、それらを再利用または共有することでオーバーヘッドを削減できます。また、ネットワーク管理者がクラスタごとに特定のサブネットを作成する必要がないため、IP アドレスの管理が容易になります。

コントロール プレーンのカスタマイズされたサブネット範囲を共有する

デフォルトでは、GKE はプライマリ サブネット範囲を使用してコントロール プレーンの内部エンドポイントをプロビジョニングします。ただし、Private Service Connect を使用するクラスタでは、作成した別のサブネットから内部エンドポイントをプロビジョニングするように GKE を構成できます。このサブネットは、他のクラスタ間で共有できます。共有 VPC を使用している場合は、プロジェクト間で共有することもできます。

ノードのプライマリ IP アドレス範囲を共有する

サブネットに複数のクラスタを作成すると、ノードのプライマリ IP アドレス範囲はデフォルトで共有されます。

ノードのプライマリ IP アドレスの共有には次の制限があります。

• ノードのプライマリ IP アドレス範囲を 2 つ以上の VPC ネイティブ クラスタと共有すると、1 つのクラスタが共有された IP アドレス範囲の大部分を使ってしまい、他のクラスタが拡張するのに十分な IP アドレスを使用できなくなる可能性があります。

Pod のセカンダリ IP アドレス範囲を共有する

Pod のセカンダリ範囲を共有すると、各 Pod に一意の IP アドレスが割り当てられます。

Pod のセカンダリ IP アドレス範囲の共有には次の制限があります。

• Pod のセカンダリ IP アドレス範囲を 2 つ以上の VPC ネイティブ クラスタと共有すると、1 つのクラスタが共有された IP アドレス範囲の大部分を使ってしまい、他のクラスタが拡張するのに十分な IP アドレスを使用できなくなる可能性があります。

• 異なるタイプのセカンダリ範囲のうち、GKE によって管理される範囲と追加の Pod 範囲の両方をクラスタ間で共有することはできません。

• セカンダリ IP アドレス範囲を共有するには、--cluster-secondary-range を使用してコマンドラインでその範囲を渡します。UI でクラスタを作成するときに、共有セカンダリ範囲を使用することはできません。

Service のセカンダリ IP アドレス範囲を共有する

ユーザーが管理するセカンダリ範囲を使用する場合、2 つ以上のクラスタで、Service に同じサブネット セカンダリ IPv4 アドレス範囲を同時に使用できます。

Service の共通のサブネット セカンダリ IPv4 アドレス範囲を共有するように 2 つ以上のクラスタを構成するには、各クラスタの作成時に同じサブネット セカンダリ IPv4 アドレス範囲を使用します。Service の共通の IPv4 アドレス範囲を共有するために、個別の構成フラグは必要ありません。

Service の共通の IPv4 アドレス範囲を共有すると、各クラスタが Service のサブネット セカンダリ IPv4 アドレス範囲全体を内部で使用します。Service の IP アドレスは各クラスタのノード内でプログラムされますが、どのノードのネットワーク インターフェースにも割り当てられません。Service の IP アドレスは、クラスタの VPC ネットワーク内でルーティングできません。Service の IP アドレスは、Service と同じクラスタ内のクライアント Pod でのみ使用できます。

Pod が Service の IP アドレスにパケットを送信すると、ノードの iptables または eBPF 構成により宛先ネットワーク アドレス変換（NAT）が実行され、パケットの宛先 IP アドレスがサービス IP アドレスからサービス Pod IP アドレスに変更されます。パケットは、宛先 Pod IP アドレスに基づいてルーティングされます。

Service のセカンダリ IP アドレス範囲を共有すると、次のような利点があります。

• サブネット上に作成された Service の一意のセカンダリ IP アドレス範囲の数を減らすことができる
• 使用する IP アドレスを減らすことができる

Service のセカンダリ IP アドレス範囲の共有には次の制限があります。

• VPC スコープの GKE 向け Cloud DNS では、Service のセカンダリ IP アドレス範囲を共有できません。

• 次の正規表現に一致する範囲は共有できません。

  ^gke-.*-services-[abcdef0-9]{8}
  

• Service のセカンダリ IP アドレス範囲を共有するには、--cluster-secondary-range を使用してコマンドラインでその範囲を渡します。UI でクラスタを作成するときに、Service の共有セカンダリ範囲を使用することはできません。

ノード制限範囲

特定の GKE クラスタの Pod と Service の最大数は、クラスタのセカンダリ範囲のサイズによって制限されます。クラスタの最大ノード数は、クラスタのサブネットのプライマリ IP アドレス範囲とクラスタの Pod アドレス範囲のサイズによって制限されます。

次のエラー メッセージは、サブネットのプライマリ IP アドレス範囲、またはクラスタの Pod IP アドレス範囲（Pod 用のサブネット セカンダリ IP 範囲）が使い果たされたことを示します。

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

ノードの IP アドレスを追加するには、プライマリ サブネットを拡張するか、不連続マルチ Pod CIDR を使用して新しい IP アドレスを Pod に追加します。詳細については、Pod 用の空き IP アドレス空間が不足しているをご覧ください。

IPv4 / IPv6 デュアルスタック ネットワーキング

IPv4 / IPv6 デュアルスタック ネットワーキングでは、GKE が次のオブジェクトに IP アドレス（ipFamilies）を割り振る方法を定義できます。

• Pod とノードに対して、GKE は IPv4 アドレスと IPv6 アドレスの両方を割り振ります。
• Service に対して、GKE はシングルスタック（IPv4 のみ、または IPv6 のみ）またはデュアルスタックのアドレスを割り振ります。

GKE バージョン 1.24 以降では、スタンドアロンおよび共有 VPC ネットワークにある新しい GKE クラスタに対してデュアルスタック ネットワーキングを有効にできます。デュアルスタック ネットワーキングを有効にしてネットワーク ポリシーを適用することもできます。 バージョン 1.24 からバージョン 1.25 または 1.26 にアップグレードされた GKE クラスタでデュアルスタック ネットワーキングを有効にするときに検証エラーが表示される場合は、Google Cloud サポートチームまでお問い合わせください。

利点

デュアルスタック ネットワーキングには次のような利点があります。

• エンドツーエンドの IPv6 通信が可能です。
• ネットワーク アドレス変換（NAT）や IP トンネリングに比べてパフォーマンスが向上します。これは、IPv6 から IPv4 への変換がないためです。

対象

GKE によるデュアルスタック ネットワーキングには次の制限があります。

• デュアルスタック ネットワーキングは、GKE Dataplane V2 が有効になっている VPC ネイティブ クラスタのクラスタでのみ使用できます。
• デュアルスタック ネットワーキングは、カスタムモード VPC のサブネットでのみサポートされます。詳細については、Google Cloud の VPC ネットワークの種類をご覧ください。
• Pod またはノードのシングル スタック IPv6 アドレスはサポートされていません。
• デュアルスタック クラスタは、IPv4 のみのクラスタと比較して、IPv4 と IPv6 の両方をサポートするため、ノードごとに追加のメモリを消費します。大規模なクラスタを設定する場合は、この特性を考慮してください。
• デュアルスタック クラスタは、IPv6 を介した限定公開の Google アクセスをサポートしていません。
• GKE バージョン 1.26.0-gke.2200 以降では、クラスタ内部オペレーションと外部 DNS クエリ用に Cloud DNS で IPv6（AAAA レコード）をサポートしています。
• デュアルスタック サービスは、ClusterIP、NodePort、LoadBalancer Service でサポートされています。

• IPv6 は Windows ノードではサポートされていません。

デュアルスタック ネットワーキングを使用してクラスタを作成する前に、上記の制限事項を考慮してください。詳細については、デュアルスタック ネットワーキングを使用して VPC ネイティブ クラスタを作成する方法をご覧ください。

パブリック IPv6 アドレスとプライベート IPv6 アドレスの割り当て

次の表に、デュアルスタック ネットワークの動作と構成があるパブリックおよびプライベート IPv6 クラスタの概要を示します。

詳細については、VPC ネイティブ クラスタでデュアルスタック ネットワークを使用する方法をご覧ください。

アーキテクチャ

IPv4 / IPv6 デュアルスタック ネットワーキングを使用するクラスタには、次の範囲が割り振られています。

• プライマリ範囲として、各サブネットに /64 範囲。
• プライマリ範囲からノードあたり /96 範囲。プライマリ ノード IP アドレス範囲として使用。

• プライマリ ノードの IP アドレス範囲からノードあたり /112 範囲。そのノードの Pod IP アドレス範囲として使用。デュアルスタック ネットワーキングでは、Pod は Pod の IP アドレス範囲全体（ノードと同様）から IPv6 アドレスを取得します。IPv4 アドレスに予約された Pod のセカンダリ範囲からは取得しません。

  Pod の IP アドレス範囲全体は、プライマリ ノードの IP 範囲から重複しない範囲で構成されます。そのため、この Pod IP 範囲は連続していません。

• Service に使用する /112 範囲。この範囲は、GKE のセカンダリ Service IP アドレス範囲用に予約された Google プライベート アドレス範囲からの /64 範囲です。

次の図は、Google Cloud と GKE で IPv6 アドレスがどのように割り振られるかを示しています。

この図では、VPC サブネットのプライマリ範囲は 2600:1900:0:1::/64 で、GKE Service 用の予約済み範囲は 2600:2D00:0:4::0:0/64 です。クラスタ内の各ノードには、プライマリ ノードの IP アドレス範囲用に /96 範囲があり、Pod の IP アドレス範囲用に /112 範囲があります。クラスタには Service のセカンダリ IP アドレス範囲用に /112 範囲もあります。

サービス

ClusterIP または NodePort タイプの IPv4 / IPv6 デュアルスタック Service を作成できます。バージョン 1.29 以降を実行している新しい GKE クラスタは、LoadBalancer タイプのデュアルスタック Service をサポートしています。

ClusterIP、NodePort、LoadBalancer タイプの Service を使用して Deployment を公開できます。これらの Service タイプごとに、IPv4、IPv6、デュアルスタックのいずれかの Service として、ipFamilies フィールドと ipFamilyPolicy フィールドを定義できます。詳細については、Deployment の設定方法の例をご覧ください。

次のステップ

• VPC ネットワーク ピアリングの詳細を確認する。
• VPC ネイティブ クラスタの作成方法について学ぶ。

• GKE IP アドレスの使用率の分析情報を確認する。