VPC ネイティブ クラスタ

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

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

概要

GKE では、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 クラスタのバージョンとクラスタの作成方法に対応する、デフォルトのクラスタ ネットワーク モードを示します。

GKE のバージョン クラスタの作成方法 クラスタ ネットワーク モード
すべてのバージョン Google Cloud コンソール VPC ネイティブ
1.21.0-gke.1500 以降 GKE API または Google Cloud CLI VPC ネイティブ

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

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

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

IPv4 アドレスの割り振り

VPC ネイティブ クラスタでは、次のようにノード、Pod、Service に IPv4 アドレスが割り振られます。

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

  • Pod の IPv4 アドレス: クラスタでは、すべての Pod の IPv4 アドレスに 1 つ以上のサブネット セカンダリ IPv4 アドレス範囲が使用されます。このページでは、単一のサブネット セカンダリ IPv4 アドレス範囲の使用に焦点を当てています。複数の範囲の使用については、Pod の IPv4 アドレス範囲の追加をご覧ください。

  • Service の IPv4 アドレス: 次の 2 つのオプションがあります。

    • 34.118.224.0/20 からの Service IPv4 アドレス: バージョン 1.27 以降を実行している GKE Autopilot クラスタと、バージョン 1.29 以降を実行している GKE Standard クラスタでは、Service に 34.118.224.0/20 IPv4 アドレス範囲を使用します。Google Cloud は、プライベートな目的で 34.118.224.0/20 アドレス範囲を使用し、この範囲に対してルートを公共のインターネットに公開しません。この範囲は、リソースの外部 IPv4 アドレスには使用できません。

    • サブネット セカンダリ IPv4 アドレス範囲の Service IPv4 アドレス: クラスタでは、すべての Service（ClusterIP）アドレスに、Pod で使用される範囲とは異なるサブネット セカンダリ IPv4 アドレス範囲を使用します。

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

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

  • Service IPv6 アドレス: GKE クラスタでは、Service に 2600:2D00:0:4::0:0/64 IPv6 アドレス範囲を使用します。 Google Cloudでは、プライベートな目的で 2600:2D00:0:4::0:0/64 アドレス範囲を使用し、この範囲に対してルートを公共のインターネットに公開しません。この範囲は、リソースの外部 IPv6 アドレスには使用できません。

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

範囲 説明 例
ノード

ノードの IP アドレスは、クラスタに関連付けられたサブネットのプライマリ IP アドレス範囲から割り当てられます。

ノードの IP アドレスと、Pod のサブネットのセカンダリ IP アドレス範囲のサイズにより、クラスタがサポートできるノードの数が制限されます。詳細については、ノード制限範囲の説明をご覧ください。

900 個のノードクラスタを作成する予定の場合、クラスタのサブネットのプライマリ IP アドレス範囲は少なくとも /22（2(32-22) = 210 = 1,024 個のアドレス）である必要があります。すべてのプライマリ IP アドレス範囲で 4 つの IP アドレスが予約されているため、これらの 1,024 個のアドレスのうち、使用可能なのは 1,020 個です。

詳細については、サブネットのプライマリ IP アドレス範囲と Pod 用のサブネット セカンダリ IP アドレス範囲をご覧ください。
Pod

Pod IP アドレスは、クラスタのサブネットで Pod に使用するセカンダリ IP アドレス範囲から取得します。ノードあたりの最大 Pod 数が別々に設定されない限り、GKE は実行されている Pod の各ノードに /24 エイリアス IP 範囲（256 個のアドレス）を割り当てます。各ノードで、これらの 256 個のエイリアス IP アドレスが使用され、最大で 110 個の Pod がサポートされます。

ノードあたり最大で 110 個の Pod をサポートする 900 個のノードクラスタの場合、Pod に 900 × 256 = 230,400 個の IP アドレスが必要です（各ノードは、ネットマスクのサイズが /24 であるエイリアス IP 範囲を割り当てられます）。このクラスタには、Pod 用のセカンダリ IP 範囲に /14 以下のサブネット マスクがあるサブネットが必要です。このセカンダリ IP 範囲は、2(32-14) = 218 = 262,144 個の IP アドレスを Pod に割り当てることができます。

詳細については、Pod 用のサブネット セカンダリ IP アドレス範囲をご覧ください。
サービス

Service（クラスタ IP）アドレスは、クラスタのサブネットで Service に使用するセカンダリ IP アドレス範囲から取得します。この範囲が、クラスタでホストするすべての Kubernetes Services にアドレスを提供するのに十分な大きさであることを確認する必要があります。

バージョン 1.27 以降を実行している GKE Autopilot クラスタと、バージョン 1.29 以降を実行している GKE Standard クラスタの場合、GKE は GKE が管理する範囲（デフォルトでは 34.118.224.0/20）から GKE Service の IP アドレスを割り振ります。これにより、Service に独自の IP アドレス範囲を指定する必要がなくなります。詳細については、Service 用のサブネット セカンダリ IP アドレス範囲をご覧ください。

最大で 3,000 個の Service を実行するクラスタの場合、3,000 個のクラスタ IP アドレスが必要になります。サイズが /20 以上のセカンダリ範囲が必要です。/20 範囲の IP アドレスの場合、2(32-20) = 212 = 4,096 個の IP アドレスになります。

詳細については、Service 用のサブネット セカンダリ IP アドレス範囲をご覧ください。

内部 IPv4 アドレス

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

RFC 1918 以外のアドレスであるプライベート アドレスの使用に関する重要な情報については、RFC 1918 以外のプライベート IPv4 アドレス範囲の使用をご覧ください。

プライベートで使用されたパブリック IPv4 アドレス範囲の使用に関する重要な情報については、プライベートで使用されたパブリック IP アドレス範囲を有効にするをご覧ください。

サブネットのセカンダリ IPv4 範囲の割り当て方法

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 の最小範囲については、Standard クラスタの Pod の CIDR の範囲の表をご覧ください。

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 アドレス範囲のサイズを計算してください。

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

クラスタのサブネットのプライマリ IPv4 アドレス範囲を計画する際は、次の点を考慮してください。

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

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

  • シナリオ 1: デフォルトのサブネットを使用するクラスタ内の最大ノード数。
  • シナリオ 2: private-endpoint-subnetwork フラグを使用しない Private Service Connect クラスタ内の最大ノード数。
サブネットのプライマリ IP アドレス範囲 シナリオ 1 シナリオ 2
/29
サブネットのプライマリ IP アドレス範囲の最小サイズ		 4 個のノード 3 個のノード
/28 12 個のノード 11 個のノード
/27 28 個のノード 27 個のノード
/26 60 個のノード 59 個のノード
/25 124 個のノード 123 個のノード
/24 252 個のノード 251 個のノード
/23 508 個のノード 507 個のノード
/22 1,020 個のノード 1,019 個のノード
/21 2,044 個のノード 2,043 個のノード
/20
自動モード ネットワーク内のサブネットのプライマリ IP アドレス範囲のデフォルト サイズ		 4,092 個のノード 4,091 個のノード
/19 8,188 個のノード 8,187 個のノード
/8
サブネットのプライマリ IP アドレス範囲の最大サイズ		 16,777,212 個のノード 16,777,211 個のノード

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

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

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

  • サブネット内の IP アドレス範囲は重複してはいけません。
  • GKE は、プライマリ IP アドレス範囲を使用して、内部ロードバランサとノードに IP アドレスを割り振ります。
  • クラスタで承認済みネットワークを使用している場合は、拡張されたプライマリ IP アドレス範囲を承認済みネットワークのリストに追加する必要があります。

有用な数式

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

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

    N = 2(32 -S) - 4

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

    S = 32 - ⌈log2(N + 4)⌉

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

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

Pod のセカンダリ IP アドレス範囲に関するクラスタのサイズ設定の考慮事項

クラスタがサポートできる Pod の最大数を計算するには、Pod サブネットのサイズとノードあたりの最大 Pod 数を考慮します。Pod の最大数は、サブネット マスクとノードあたりの Pod の最大数によって異なります。また、一部の IP アドレスはプライマリ範囲で予約されていることに注意してください。

キー変数

  • Q: ノードあたりの Pod の最大数。
  • DS: Pod サブネット用に選択された CIDR ブロックのサイズ（/17 など）。
  • M: 各ノードの Pod 範囲のネットマスク サイズ。
  • HM: ノードの Pod 範囲ネットマスクのホストビット数。
  • HD: Pod サブネットの CIDR ブロックのホストビット数。
  • MN: サポートできるノードの最大数。
  • MP: サポートできる Pod の最大数。
  • S: サブネットのプライマリ IP アドレス範囲の接頭辞長。
  • N: サブネットのプライマリ IP アドレス範囲で使用可能な IP アドレスの数。

Pod の最大数を計算する手順

  1. ノードあたりの最大 Pod 数（Q）を決定します。

    • Autopilot クラスタの場合、Q の値は 32 に固定されています。
    • Standard クラスタの場合は、Q を構成できます。

  2. Pod サブネットの CIDR ブロックのサイズ（DS）を定義します。

    • Pod サブネット用に選択した CIDR ブロックサイズ（/17 など）を決定します。

  3. ネットマスクのサイズ（M）を計算します。

    M = 31 - ⌈log₂(Q)⌉

    Q は、ノードあたりの最大 Pod 数に置き換えます。天井関数（⌈ ⌉）を使用して、最も近い整数に切り上げます。

  4. Pod 範囲のホストビット（HM）を計算します。

    HM = 32 - M

  5. 選択した CIDR ブロック（HD）のホストビットを計算します。

    HD = 32 - DS

  6. ノードの最大数（MN）を計算します。

    MN = 2<sup>(HD - HM)</sup>

    この計算の結果は、選択した Pod サブネットがサポートできるノードの最大数です。

  7. Pod の最大数（MP）を計算します。

    MP = MN * Q

    この計算の結果は、クラスタがサポートできる Pod の最大数です。

  8. プライマリ範囲（N）で使用可能な IP アドレスの数を計算します。 none N = 2<sup>(32-S)</sup> - 4 ここで、S はサブネットのプライマリ CIDR 範囲のプレフィックス長です。

注意事項

  • セカンダリ範囲内のすべての IP アドレスを Pod に使用できます。
  • これらの計算は、理論上の最大値を求めます。実際のパフォーマンスは他の要因の影響を受ける可能性があります。

例

次のように GKE Autopilot クラスタを作成するとします。

  • Pod サブネットの CIDR ブロック /17（DS = 17）。
  • ノードあたりの Pod の最大数（Q = 32）。

Pod の最大数を計算します。

  1. M = 31 - ⌈log₂(32)⌉ = 26
  2. HM = 32 - 26 = 6
  3. HD = 32 - 17 = 15
  4. MN = 2(15 - 6) = 512
  5. MP = 512 * 32 = 16,384

このクラスタは、最大 512 個のノードと 16,384 個の Pod をサポートできます。

Pod の IPv4 アドレスを追加するには、Pod の IPv4 アドレス範囲を追加するか、クラスタにサブネットを追加することで行います。

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 の最大数が示されています。

Service のセカンダリ IP 範囲 Service の最大数
/28
セカンダリ範囲割り当て方式がユーザーによって管理される場合の可能な限り最も小さい Service のアドレス範囲		 16 個の Service
/27
セカンダリ範囲割り当て方式が GKE によって管理される場合の可能な限り最も小さい Service のアドレス範囲		 32 個の Service
/26 64 個の Service
/25 128 個の Service
/24 256 個の Service
/23 512 個の Service
/22 1,024 個の Service
/21 2,048 個の Service
/20
セカンダリ範囲の割り当て方法が GKE によって管理される場合の Service のサブネット セカンダリ IP 範囲のデフォルト サイズ		 4,096 個の Service
/19 8,192 個の Service
/18 16,384 個の Service
/17 32,768 個の Service
/16
可能な限り最も大きい Service アドレス範囲		 65,536 個の 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 アドレス範囲の大部分を使ってしまい、もう 1 つのクラスタが拡張するのに十分な IP アドレスを使用できなくなる可能性があります。

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

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

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

  • Pod のセカンダリ IP アドレス範囲を 2 つ以上の VPC ネイティブ クラスタと共有すると、1 つのクラスタが共有された IP アドレス範囲の大部分を使ってしまい、もう 1 つのクラスタが拡張するのに十分な 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 アドレスが Service の 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 アドレスとプライベート IPv6 アドレスの概要を示します。

ipv6-access-type フラグ IP アドレスの割り当て サブネット範囲
EXTERNAL

GKE では、インターネットにルーティング可能な外部 IPv6 アドレスが割り当てられます。

 2600:1900/28～
INTERNAL

GKE では、インターネットにルーティングできない内部 IPv6 アドレスが割り当てられます。

IPv6 アクセスタイプが INTERNAL のクラスタは、IPv6 アドレス経由でインターネットにアクセスできません。Cloud NAT は IPv6 アドレスをサポートしていません。

 fd20::/20 から（ULA 範囲全体のサブセット: fc00::/7）。

詳細については、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 アドレスがどのように割り振られるかを示しています。

GKE での IPv6 アドレスの割り振り。 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 タイプごとに、ipFamilies フィールドと ipFamilyPolicy フィールドを IPv4、IPv6、デュアルスタックとして定義できます。詳細については、Deployment の設定方法の例をご覧ください。

次のステップ