このページでは、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 クラスタのバージョンとクラスタの作成方法に対応する、デフォルトのクラスタ ネットワーク モードを示します。
| GKE のバージョン | クラスタの作成方法 | クラスタ ネットワーク モード |
|---|---|---|
| すべてのバージョン | Google Cloud コンソール | VPC ネイティブ |
| 1.21.0-gke.1500 以降 | Kubernetes Engine API または Google Cloud CLI | VPC ネイティブ |
クラスタの作成時に --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 アドレスは、ノードに指定された
/96IPv6 アドレス範囲から割り振られます。ノードの IP アドレス自体が、この範囲内の最初の/128（単一の IPv6 アドレス）になります。詳細については、デュアルスタック ネットワーキングをご覧ください。
次の表に、ノード、Pod、Service の IP アドレス範囲の概要を示します。
| 範囲 | 説明 | 例 |
|---|---|---|
| ノード |
ノードの IP アドレスは、クラスタに関連付けられたサブネットのプライマリ IP アドレス範囲から割り当てられます。 ノードの IP アドレスと、Pod のサブネットのセカンダリ IP アドレス範囲のサイズにより、クラスタがサポートできるノードの数が制限されます。詳細については、ノード制限範囲の説明をご覧ください。 |
900 個のノードクラスタを作成する予定の場合、クラスタのサブネットのプライマリ IP アドレス範囲は少なくとも 詳細については、サブネットのプライマリ IP アドレス範囲と Pod 用のサブネット セカンダリ IP アドレス範囲をご覧ください。 |
| Pod |
Pod IP アドレスは、クラスタのサブネットで Pod に使用するセカンダリ IP アドレス範囲から取得します。ノードあたりの最大 Pod 数が別々に設定されない限り、GKE は実行されている 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 |
Service（クラスタ IP）アドレスは、クラスタのサブネットで Service に使用するセカンダリ IP アドレス範囲から取得します。この範囲が、クラスタでホストするすべての Kubernetes Services にアドレスを提供するのに十分な大きさであることを確認する必要があります。 バージョン 1.27 以降を実行している GKE Autopilot クラスタと、バージョン 1.29 以降を実行している GKE Standard クラスタの場合、GKE は GKE が管理する範囲（デフォルトでは |
最大で 3,000 個の Service を実行するクラスタの場合、3,000 個のクラスタ IP アドレスが必要になります。サイズが /20 以上のセカンダリ範囲が必要です。/20 範囲の IP アドレスの場合、2(32-20) = 212 = 4,096 個の IP アドレスになります。 詳細については、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 範囲 | シナリオ 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 アドレスを割り振ります。
有用な数式
次の数式をお使いください。
デフォルトのサブネットを使用するクラスタで、指定したネットマスクがサポートできるノードの最大数（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 のセカンダリ IP アドレス範囲は慎重に計画してください。
次の表に、Pod によって使用されるサブネットのセカンダリ IP アドレス範囲を考慮して、サブネットを使用するすべてのクラスタで作成できるノードと Pod の最大数を示します。
この表では、ノードあたりの Pod の最大数はデフォルトの Pod 密度である 110 であると想定されています。
| Pod 用のサブネット セカンダリ IP 範囲 | 最大 Pod IP アドレス数 | 最大ノード数 | 最大 Pod 数 |
|---|---|---|---|
| /24 セカンダリ範囲の割り当て方法がユーザーによって管理される場合に許容される最小の Pod IP 範囲 |
256 個のアドレス | 1 個のノード |
Autopilot: 32 個の Pod Standard: 110 個の Pod |
| /23 セカンダリ範囲の割り当て方法がユーザーによって管理される場合にのみ可能 |
512 個のアドレス | 2 個のノード |
Autopilot: 64 個の Pod Standard: 220 個の Pod |
| /22 セカンダリ範囲の割り当て方法がユーザーによって管理される場合にのみ可能 |
1,024 個のアドレス | 4 個のノード |
Autopilot: 128 個の Pod Standard: 440 個の Pod |
| /21 セカンダリ範囲の割り当て方法が GKE によって管理されている場合に許容される最小の Pod IP 範囲 |
2,048 個のアドレス | 8 個のノード |
Autopilot: 256 個の Pod Standard: 880 個の Pod |
| /20 | 4,096 個のアドレス | 16 個のノード |
Autopilot: 512 個の Pod Standard: 1,760 個の Pod |
| /19 | 8,192 個のアドレス | 32 個のノード |
Autopilot: 1,024 個の Pod Standard: 3,520 個の Pod |
| /18 | 16,384 個のアドレス | 64 個のノード |
Autopilot: 2,048 個の Pod Standard: 7,040 個の |
| /17 | 32,768 個のアドレス | 128 個のノード |
Autopilot: 4,096 個の Pod Standard: 14,080 個の Pod |
| /16 | 65,536 個のアドレス | 256 個のノード |
Autopilot: 8,192 個の Pod Standard: 28,160 個の Pod |
| /15 | 131,072 個のアドレス | 512 個のノード |
Autopilot: 16,384 個の Pod Standard: 56,320 個の Pod |
| /14 セカンダリ範囲の割り当て方法が GKE によって管理される場合の Pod のサブネット セカンダリ IP アドレス範囲のデフォルト サイズ |
262,144 個のアドレス | 1,024 個のノード |
Autopilot: 32,768 個の Pod Standard: 112,640 個の Pod |
| /13 | 524,288 個のアドレス | 2,048 個のノード |
Autopilot: 65,536 個の Pod Standard: 225,280 個の Pod |
| /12 | 1,048,576 個のアドレス | 4,096 個のノード |
Autopilot: 131,072 個の Pod Standard: 450,560 個の Pod |
| /11 | 2,097,152 個のアドレス | 8,192 個のノード |
Autopilot: 262,144 個の Pod Standard: 901,120 個の Pod |
| /10 | 4,194,304 個のアドレス | 16,384 個のノード |
Autopilot: 524,288 個の Pod Standard: 1,802,240 個の Pod |
| /9 許容される最大の Pod アドレス範囲 |
8,388,608 個のアドレス | 32,768 個のノード |
Autopilot: 1,048,576 個の Pod Standard: 3,604,480 個の Pod |
ノードあたりの Pod の最大数を変更した場合、次の数式を使用して、Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできるノードと Pod の最大数を計算できます。
各ノードの Pod 範囲のネットマスクのサイズ M を計算します。
M = 31 - ⌈log2(Q)⌉- Q は、ノードあたりの Pod の数です。
⌈⌉は、天井（最小の整数）関数であり、次の整数に切り上げます。- たとえば、Q が 110 の場合、
M = 24になります。
Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできるノードの最大数 N を計算します。
N = 2(M - S)- M は、最初のステップで計算された Pod の各ノードのエイリアス IP アドレス範囲のネットマスクのサイズです。
- S は、サブネットのセカンダリ IP アドレス範囲のサブネット マスクのサイズです。
- たとえば、M が 24、S が 20 の場合、
N = 16になります。
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 の最大数が示されています。
| 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、LoadBalancerService でサポートされています。
- IPv6 は Windows ノードではサポートされていません。
デュアルスタック ネットワーキングを使用してクラスタを作成する前に、上記の制限事項を考慮してください。詳細については、デュアルスタック ネットワーキングを使用して VPC ネイティブ クラスタを作成する方法をご覧ください。
パブリック IPv6 アドレスとプライベート IPv6 アドレスの割り当て
次の表に、デュアルスタック ネットワーキングの動作と構成があるパブリック IPv6 アドレスとプライベート IPv6 アドレスの概要を示します。
ipv6-access-type フラグ |
IP アドレスの割り当て | サブネット範囲 |
|---|---|---|
EXTERNAL |
GKE では、インターネットにルーティング可能な外部 IPv6 アドレスが割り当てられます。 |
2600:1900/28～ |
INTERNAL |
GKE では、インターネットにルーティングできない内部 IPv6 アドレスが割り当てられます。 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 アドレスがどのように割り振られるかを示しています。
この図では、VPC サブネットのプライマリ範囲は 2600:1900:0:1::/64 で、GKE Service 用の予約済み範囲は 2600:2D00:0:4::0:0/64 です。クラスタ内の各ノードには、プライマリ ノードの IP アドレス範囲用に /96 範囲があり、Pod の IP アドレス範囲用に /112 範囲があります。クラスタには Service のセカンダリ IP アドレス範囲用に /112 範囲もあります。
Service
ClusterIP または NodePort タイプの IPv4 / IPv6 デュアルスタック Service を作成できます。バージョン 1.29 以降を実行している新しい GKE クラスタは、LoadBalancer タイプのデュアルスタック Service をサポートしています。
ClusterIP、NodePort、LoadBalancer タイプの Service を使用して Deployment を公開できます。これらの Service タイプごとに、IPv4、IPv6、デュアルスタックのいずれかの Service として、ipFamilies フィールドと ipFamilyPolicy フィールドを定義できます。詳細については、Deployment の設定方法の例をご覧ください。