VPC ネイティブ クラスタ

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

概要

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 に接続されているオンプレミス ネットワークからアクセスできます。

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

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

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

GKE のバージョン クラスタの作成方法 クラスタ ネットワーク モード
すべてのバージョン Google Cloud Console VPC ネイティブ
1.21.0-gke.1500 以降 Kubernetes Engine API または Cloud SDK VPC ネイティブ
1.21.0-gke.1500 より前 Kubernetes Engine API または Cloud SDK ルートベース

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

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

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

  • すべてのノードの IP アドレスに、サブネットのプライマリ IP アドレス範囲を使用します。
  • すべての Pod IP アドレスに、1 つのセカンダリ IP アドレス範囲を使用します。
  • すべての Service(クラスタ IP)アドレスに、別のセカンダリ IP アドレス範囲を使用します。

次の表に、ノード、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

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

最大で 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 アドレスが含まれます。有効なサブネット範囲の詳細については、Virtual Private Cloud のドキュメントで有効な範囲制限付きの範囲をご覧ください。

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

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

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

次の 2 つの方法のいずれかを使用して、Pod の IP アドレス範囲と Service(ClusterIP)のアドレス範囲を VPC ネイティブ クラスタに割り当てることができます。

GKE による管理(デフォルト)

GKE はサブネットのセカンダリ範囲を自動的に作成して、管理できます。クラスタを作成するときに、Pod と Service の両方について、完全な CIDR 範囲またはネットマスクのサイズのいずれかを指定します。たとえば、Pod に 10.1.0.0/16 を指定して、Service に 10.2.0.0/20 を指定できます。あるいは、Pod に /16 を指定して、Service に /20 を指定できます。

クラスタとサブネットを同時に作成する場合、Pod と Service の IP アドレス範囲は GKE によって管理されます。

ユーザー管理

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

作成できる IP アドレスの最小範囲は /28 です。ただし、少なくとも 1 つのノードを作成するのに十分な大きさの範囲を使用する必要があります。使用可能な最小範囲は、ノードあたりの Pod の最大数によって異なります。ノードあたりの Pod の最大値に応じて使用できる CIDR の最小範囲については、IP アドレス割り当ての最適化に記載されている表をご覧ください。

Pod の IP アドレス範囲が枯渇した場合は、より大きな Pod のアドレス範囲を持つ新しいクラスタを作成するか、ノードプールの --max-pods-per-node を減らしたうえでノードプールを再作成する必要があります。

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

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

共有 VPC に関する考慮事項

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

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

IP アドレス範囲の計画

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

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

すべてのサブネットにプライマリ IP アドレス範囲が必要です。Google Cloud リソースがサブネットを使用する場合でも、プライマリ IP アドレス範囲の拡張をいつでも行うことができます。ただし、サブネットが作成された後、そのサブネットのプライマリ IP アドレス スキームを縮小または変更することはできません。プライマリ IP アドレス範囲の最初の 2 つと最後の 2 つの IP アドレスは、Google Cloud によって予約されています。

次の表に、サブネットのプライマリ IP アドレス範囲のサイズを考慮して、サブネットを使用するすべてのクラスタで作成できるノードの最大数を示します。

サブネットのプライマリ IP 範囲 最大ノード数
/29
サブネットのプライマリ IP 範囲の最小サイズ
4 個のノード
/28 12 個のノード
/27 28 個のノード
/26 60 個のノード
/25 124 個のノード
/24 252 個のノード
/23 508 個のノード
/22 1,020 個のノード
/21 2,044 個のノード
/20
自動モード ネットワーク内のサブネットのプライマリ IP 範囲のデフォルト サイズ
4,092 個のノード
/19 8,188 個のノード
/8
サブネットのプライマリ IP 範囲の最大サイズ
16,777,212 個のノード

有用な数式

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

  • 指定したネットマスクでサポートできるノードの最大数 N を計算します。ネットマスクのサイズには S を使用します。この有効範囲は 8 から 29 までです(両端の値を含む)。

    N = 2(32 -S) - 4

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

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

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

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

Pod のセカンダリ IP アドレス範囲は慎重に計画してください。サブネットのセカンダリ IP アドレス範囲を置き換えることはできますが、クラスタが不安定な状態になる可能性があるため、そのような操作はサポートされていません。

ただし、連続していないマルチ Pod CIDR を使用すると、追加の Pod IP アドレス範囲を作成できます。

次の表に、Pod によって使用されるサブネットのセカンダリ IP アドレス範囲を考慮して、サブネットを使用するすべてのクラスタで作成できるノードと Pod の最大数を示します。この表では、ノードあたりの Pod の最大数110(可能な限り最も大きい Pod 密度でデフォルトで設定されている)であると想定されています。

Pod 用のサブネット セカンダリ IP 範囲 最大 Pod IP アドレス数 最大ノード数 最大 Pod 数
/24
セカンダリ範囲の割り当て方法がユーザーによって管理される場合に許容される最小の Pod IP 範囲
256 個のアドレス 1 個のノード 110 個の Pod
/23
セカンダリ範囲の割り当て方法がユーザーによって管理される場合にのみ可能
512 個のアドレス 2 個のノード 220 個の Pod
/22
セカンダリ範囲の割り当て方法がユーザーによって管理される場合にのみ可能
1,024 個のアドレス 4 個のノード 440 個の Pod
/21
セカンダリ範囲の割り当て方法が GKE によって管理されている場合に許容される最小の Pod IP 範囲
2,048 個のアドレス 8 個のノード 880 個の Pod
/20 4,096 個のアドレス 16 個のノード 1,760 個の Pod
/19 8,192 個のアドレス 32 個のノード 3,520 個の Pod
/18 16,384 個のアドレス 64 個のノード 7,040 個の Pod
/17 32,768 個のアドレス 128 個のノード 14,080 個の Pod
/16 65,536 個のアドレス 256 個のノード 28,160 個の Pod
/15 131,072 個のアドレス 512 個のノード 56,320 個の Pod
/14
セカンダリ範囲の割り当て方法が GKE によって管理される場合の Pod のサブネット セカンダリ IP 範囲のデフォルト サイズ
262,144 個のアドレス 1,024 個のノード 112,640 個の Pod
/13 524,288 個のアドレス 2,048 個のノード 225,280 個の Pod
/12 1,048,576 個のアドレス 4,096 個のノード 450,560 個の Pod
/11
2,097,152 個のアドレス 8,192 個のノード 901,120 個の Pod
/10
4,194,304 個のアドレス 16,384 個のノード 1,802,240 個の Pod
/9
許容される最大の Pod アドレス範囲
8,388,608 個のアドレス 32,768 個のノード 3,604,480 個の Pod

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

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

    • Q は、ノードあたりの Pod の数です。
    • ⌈⌉ は、天井(最小の整数)関数であり、次の整数に切り上げます。
  2. Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできるノードの最大数 N を計算します。
    N = 2(M - S) ここで

    • M は、最初のステップで計算された Pod の各ノードのエイリアス IP アドレス範囲のネットマスクのサイズです。
    • S は、サブネットのセカンダリ IP アドレス範囲のサブネット マスクのサイズです。
  3. Pod 用のサブネット セカンダリ IP アドレス範囲がサポートできる Pod の最大数 P を計算します。
    P = N × Q ここで

    • N は、前のステップで計算されたノードの最大数です。
    • Q は、ノードあたりの Pod の数です。

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

Service のセカンダリ IP アドレス範囲は慎重に計画してください。これはサブネット セカンダリ IP アドレス範囲でもあるため、それを使用する Google Cloud リソースがない場合にのみ、置き換えることができます。この範囲は、クラスタが Service にその範囲を使用している場合は(クラスタの IP アドレスとして使用)、変更できません。

ノードと Pod の IP アドレス範囲とは異なり、各クラスタには Service 用の一意のサブネット セカンダリ IP アドレス範囲が必要です。共有のプライマリまたはセカンダリ IP 範囲から提供することはできません。

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

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

Service のセカンダリ IP 範囲 Service の最大数
/27
可能な限り最も小さい 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 クラスタの Pod と Service の最大数は、クラスタのセカンダリ範囲のサイズによって制限されます。クラスタの最大ノード数は、クラスタのサブネットのプライマリ IP アドレス範囲とクラスタの Pod アドレス範囲のサイズによって制限されます。

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

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

次のステップ