VPC ネイティブ クラスタを作成する

このページでは、Google Kubernetes Engine で VPC ネイティブ クラスタを構成する方法について説明します。

概要

GKE では、ある Pod から別の Pod にトラフィックをルーティングする方法によってクラスタを区別できます。エイリアス IP 範囲を使用するクラスタは、VPC ネイティブ クラスタといいます。Google Cloud のルートを使用するクラスタは、ルートベース クラスタと呼ばれています。

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

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

  • Pod の IP アドレスは、クラスタの VPC ネットワーク内と、VPC ネットワーク ピアリングで接続された他の VPC ネットワーク内でネイティブにルーティングできます。
  • Pod IP は、クラスタで Pod が作成される前に VPC ネットワークで予約されます。これにより、VPC ネットワーク上のその他のリソースとの競合が回避され、IP アドレスの割り振りをより適切に計画できるようになります。
  • Pod の IP 範囲はカスタム静的ルートに依存しないため、システム生成ルートとカスタム静的ルートのリソース割り当てを消費しません。代わりに、自動生成されたサブネット ルートによって、VPC ネイティブ クラスタのルーティングが処理されます。
  • クラスタのノード上にあるすべての IP アドレスではなく、Pod の IP 範囲のみに適用されるファイアウォール ルールを作成できます。
  • VPC ネイティブ クラスタのノードでは、なりすまし対策が有効になっています。VPC ネットワーキングは、ノードが任意のソース IP アドレスを使用してパケットを送信できないようにするなりすまし対策チェックを実行します(ルートベース クラスタでは、なりすまし対策は無効になっています)。
  • 一般に、Pod の IP 範囲とサブネットのセカンダリ IP 範囲は、Cloud Router を使用して Cloud VPN または Cloud Interconnect と接続されているオンプレミス ネットワークと共有できます。
  • エイリアス IP 範囲を使用すると、Pod は NAT ゲートウェイを使用せずにホストされているサービスに直接アクセスできます。

制限

  • VPC ネイティブ クラスタをルートベース クラスタに変換することはできません。また、ルートベース クラスタを VPC ネイティブ クラスタに変換することもできません。

  • VPC ネイティブ クラスタには VPC ネットワークが必要です。レガシー ネットワークはサポートされていません。

  • GKE クラスタの場合と同様に、Service(ClusterIP)のアドレスはクラスタ内部にのみ公開されています。クラスタの内部ではないが、クラスタと同じ VPC ネットワークとリージョン内にある VM インスタンスから Kubernetes Service にアクセスする必要がある場合、内部 TCP / UDP ロードバランサを作成します。

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

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

内部 IP アドレス

VPC ネイティブ クラスタのサブネットには、有効な範囲の IP アドレスを使用する必要があります。有効な範囲には、プライベート IP アドレス(RFC 1918)、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 範囲を作成してから、それらの範囲を使用するクラスタを作成できます。セカンダリ範囲を手動で作成する場合は、ご自身で管理する必要があります。

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

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 アドレス範囲が必要です。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 によって使用されるサブネットのセカンダリ 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
可能な限り大きい Pod アドレス範囲
2,097,152 個のアドレス 8,192 個のノード 901,120 個の 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 範囲から提供することはできません。

次の表には、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

始める前に

作業を始める前に、次のことを確認してください。

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

  • gcloud init。デフォルトの設定全般を確認する場合に使用します。
  • gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

エラー One of [--zone, --region] must be supplied: Please specify location を受信した場合は、このセクションの内容を実施します。

  1. gcloud init を実行して、次の操作を行います。

    gcloud init

    リモート サーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。

    gcloud init --console-only
  2. 手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
  3. 新しい構成を作成するか、既存の構成を選択します。
  4. Google Cloud プロジェクトを選択します。
  5. デフォルトの Compute Engine ゾーンを選択します。

gcloud config の使用

  • デフォルトのプロジェクト ID を設定します。
    gcloud config set project project-id
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone compute-zone
  • リージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region compute-region
  • gcloud を最新バージョンに更新します。
    gcloud components update

手順

次の手順に従って、VPC ネイティブ クラスタを作成し、構成された Pod と Service の IP 範囲を確認します。

既存のサブネットにクラスタを作成する

セカンダリ範囲割り当て方式を選択して、既存のサブネットで VPC ネイティブ GKE クラスタを作成する方法を次の手順で示します。

gcloud

  • GKE によって管理されているセカンダリ範囲割り当て方式を使用するには、次のようにします。

    gcloud container clusters create cluster-name \
      --region=region \
      --enable-ip-alias \
      --subnetwork=subnet-name \
      --cluster-ipv4-cidr=pod-ip-range \
      --services-ipv4-cidr=services-ip-range
    
  • ユーザーによって管理されているセカンダリ範囲割り当て方式を使用するには、次のようにします。

    gcloud container clusters create cluster-name \
      --region=region \
      --enable-ip-alias \
      --subnetwork=subnet-name \
      --cluster-secondary-range-name=secondary-range-pods \
      --services-secondary-range-name=secondary-range-services
    

プレースホルダを有効な値に置き換えます。

  • cluster-name は GKE クラスタの名前です。
  • region は、クラスタを作成するリージョンです。ゾーンクラスタを作成するには、このフラグを --zone=zone に置き換えます。zone は Google Cloud ゾーンです。
  • subnet-name は、既存のサブネットの名前です。ノードにはサブネットのプライマリ IP 範囲が使用されます。サブネットは、クラスタによって使用されるリージョンと同じリージョンに存在する必要があります。省略した場合、GKE はクラスタのリージョンにある default VPC ネットワーク内のサブネットの使用を試みます。
  • セカンダリ範囲の割り当て方式が GKE によって管理されている場合:
    • pod-ip-range は、CIDR 表記の IP アドレス範囲(10.0.0.0/14 など)、または CIDR ブロックのサブネット マスクのサイズ(/14 など)です。これは、Pod 用のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。
    • 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 は、指定された subnet-name 内の既存のセカンダリ IP アドレス範囲の名前です。GKE は、クラスタの Service にすべてのサブネット セカンダリ IP 範囲を使用します。

Console

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. [クラスタを作成] ボタンをクリックします。

  3. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  4. [ネットワーク] プルダウン リストで、任意の VPC を選択します。

  5. [ノードのサブネット] プルダウン リストで、クラスタのサブネットを選択します。

  6. [VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] チェックボックスが選択されていることを確認します。

  7. セカンダリ範囲割り当て方式を GKE によって管理する場合は、[セカンダリ範囲を自動的に作成する] チェックボックスを選択します。選択したサブネットのセカンダリ範囲をすでに作成していて、セカンダリ範囲割り当て方式をユーザーによって管理する場合は、このチェックボックスをオフにします。

  8. [ポッドのアドレス範囲] フィールドに、Pod の範囲(10.0.0.0/14 など)を入力します。

  9. [サービス アドレスの範囲] フィールドに、Service の範囲(10.4.0.0/19 など)を入力します。

  10. 必要に応じてクラスタを構成します。

  11. [作成] をクリックします。

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 表記の IP / サイズ(10.0.0.0/14 など)や / サイズ(/14 など)にすることができます。指定されたサイズの空きスペースが、VPC 内の使用可能なスペースから選ばれます。空白にしておくと、有効な範囲が検出され、デフォルトのサイズで作成されます。
  • "servicesIpv4CidrBlock" は、Service の CIDR 範囲のサイズ / 場所です。"clusterIpv4CidrBlock" の説明をご覧ください。
  • "clusterSecondaryRangeName" は、Pod のセカンダリ範囲の名前です。セカンダリ範囲はすでに存在しており、クラスタに関連付けられたサブネットワークに属している必要があります(--subnetwork フラグで指定されたサブネットワークなど)。
  • "serviceSecondaryRangeName" は、Service のセカンダリ範囲の名前です。セカンダリ範囲はすでに存在しており、クラスタに関連付けられたサブネットワークに属している必要があります(--subnetwork フラグで指定されたサブネットワークなど)。

Terraform

Terraform モジュールを使用すると、Terraform を介して VPC ネイティブ クラスタを簡単に作成できます。

たとえば、このブロックを Terraform 構成に追加できます。

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 9.1"

  project_id        = "project-id"
  name              = "cluster-name"
  region            = "region"
  network           = "network-name"
  subnetwork        = "subnet-name"
  ip_range_pods     = "secondary-range-pods"
  ip_range_services = "secondary-range-services"
}

以下を置き換えます。

  • project-id は、クラスタを作成するプロジェクト ID です。
  • cluster-name は GKE クラスタの名前です。
  • region は、クラスタを作成するリージョンです。
  • network-name は、既存のネットワークの名前です。
  • subnet-name は、既存のサブネットの名前です。ノードにはサブネットのプライマリ IP 範囲が使用されます。サブネットは、クラスタによって使用されるリージョンと同じリージョンに存在する必要があります。
  • secondary-range-pods は、指定された subnet-name 内の既存のセカンダリ IP アドレス範囲の名前です。GKE は、クラスタの Pod にすべてのサブネット セカンダリ IP 範囲を使用します。
  • secondary-range-services は、指定された subnet-name 内の既存のセカンダリ IP アドレス範囲の名前です。GKE は、クラスタの Service にすべてのサブネット セカンダリ IP 範囲を使用します。

クラスタとサブネットを同時に作成する

VPC ネイティブ GKE クラスタとサブネットを同時に作成する方法を次に示します。1 つのコマンドでこれらの 2 つのステップを実行すると、セカンダリ範囲割り当て方式は GKE によって管理されます。

gcloud

VPC ネイティブ クラスタとサブネットを同時に作成するには、次のようにします。

gcloud container clusters create cluster-name \
    --region=region \
    --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 クラスタの名前です。
  • region は、クラスタを作成するリージョンです。ゾーンクラスタを作成するには、このフラグを --zone=zone に置き換えます。zone は GKE ゾーンです。
  • 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 はデフォルトの Pod IP 範囲のサイズである /14 を使用します。
  • services-ip-range は、CIDR 表記の IP アドレス範囲(10.4.0.0/19 など)、または CIDR ブロックのサブネット マスクのサイズ(/19 など)です。これは、Service 用のサブネット セカンダリ IP アドレス範囲を作成するために使用されます。省略した場合、GKE はデフォルトの Service IP 範囲のサイズである /20 を使用します。

Console

Cloud Console を使用して、クラスタとサブネットを同時に作成することはできません。代わりに、最初にサブネットを作成し、次に既存のサブネットにクラスタを作成します。

API

VPC ネイティブ クラスタを作成するには、クラスタ リソースに IPAllocationPolicy オブジェクトを定義します。

{
  "name": cluster-name,
  "description": description,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": subnet-name
  },
  ...
}

createSubnetwork フィールドによって、クラスタのサブネットワークが自動的に作成され、プロビジョニングされます。subnetworkName フィールドはオプションです。空のままにすると、サブネットワークの名前が自動的に選択されます。

RFC 1918 以外の予約済み IP アドレス範囲を有効にする

RFC 1918 以外の予約済み IP アドレス範囲は、1.14.2-gke.1 以降で作成された GKE クラスタで使用できます。このアドレスは、限定公開クラスタと通常のクラスタの内部アドレスの両方で使用できます。

RFC 1918 以外のアドレスは、ノードと内部 TCP/UDP ロードバランサプライマリ範囲Pod のセカンダリ サブネットサービスのセカンダリ サブネットで使用できます。

クラスタで実行されている Pod が RFC 1918 以外のアドレスを使用できない場合、または RFC 1918 以外のアドレスを使用してアクセスできないクラスタ外サービスに連絡する必要がある場合は、サービスに連絡できるよう、ノードのプライマリ範囲に RFC 1918 のアドレスを使用し、IP マスカレード エージェントを設定することをおすすめします。

一般公開クラスタまたは限定公開クラスタで RFC 1918 以外の予約済み IP を使用するには、GKE バージョン 1.14.2-gke.1 以降でクラスタを作成します。RFC 1918 以外の予約済み IP は、新しいクラスタの作成時にのみ有効にできます。既存のクラスタでは有効にできません。

パブリック IP アドレスのプライベート使用を有効にする

クラスタ リソースに割り当て可能な IP アドレスの数を増やすには、特定のパブリック アドレス範囲をプライベート IP アドレスのように使用します。たとえば、クラス E の範囲には、公共のインターネットで使用できない予約済み IP アドレスが 228 個あります。これらのアドレスを限定公開クラスタで再利用すると、使用可能な IP アドレスを増やすことができます。VPC ネットワーキングで使用可能な IP 範囲については、有効な範囲をご覧ください。

パブリック IP をプライベートとして再利用できるのは、VPC ネイティブの限定公開クラスタだけです。

新しいクラスタでパブリック IP アドレスのプライベート使用を有効にする方法については、以降のセクションをご覧ください。

新しいクラスタを作成する

パブリック IP アドレスのプライベート使用をサポートするには、次の設定でクラスタを作成する必要があります。

  • --disable-default-snat: トラフィック送信元の Pod にレスポンスをルーティングするには、SNAT を無効にする必要があります。

    インターネットに送信されるトラフィックにはデフォルトの SNAT ルールが適用されません。Pod がインターネットにトラフィックを送信している場合は、Pod のサブネット範囲を Cloud NAT に追加します。

  • --enable-ip-alias: パブリック IP のプライベート使用に必要な VPC ネイティブ クラスタを作成します。

  • --enable-private-nodes: パブリック IP をプライベートに使用できるのは限定公開クラスタだけです。

次のコマンドでクラスタを作成します。

gcloud beta container clusters create cluster-name \
  --enable-ip-alias --enable-private-nodes --zone=zone \
  --disable-default-snat  --cluster-ipv4-cidr=5.0.0.0/16 \
  --services-ipv4-cidr=5.1.0.0/16 --master-ipv4-cidr=master-CIDR

現在、Google Cloud Console インターフェースでソース NAT ルールを無効にすることはできません。

既存のクラスタでデフォルトの SNAT を無効にする

既存のクラスタでデフォルトの SNAT ルールを無効にするには、--disable-default-snat オプションを使用します。

gcloud beta container clusters update cluster-name \
  --zone=zone --disable-default-snat

現在、Google Cloud Console インターフェースでソース NAT ルールを無効にすることはできません。

既存のクラスタでデフォルトの SNAT を有効にする

既存の限定公開クラスタでデフォルトの SNAT ルールを有効にするには、次のコマンドを使用します。

gcloud beta container clusters update cluster-name \
  --zone=zone --no-disable-default-snat

現在、Google Cloud Console インターフェースでソース NAT ルールを再度有効にすることはできません。

Pod と Service の範囲を確認する

VPC ネイティブ クラスタを作成すると、その Pod と Service の範囲を確認できます。

gcloud

クラスタを確認するには、次のコマンドを実行します。

gcloud container clusters describe cluster-name

コマンド出力で、ipAllocationPolicy フィールドの下を確認します。

  • clusterIpv4Cidr が、Pod のセカンダリ範囲です。
  • servicesIpv4Cidr が、Service のセカンダリ範囲です。

Console

クラスタを確認するには、次の手順を行います。

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

    Google Kubernetes Engine のメニューに移動

  2. 目的のクラスタを選択します。

セカンダリ範囲は、[詳細] タブの下の [クラスタ] セクションに表示されます。

  • [コンテナ アドレスの範囲] は、ポッドのセカンダリ範囲です。
  • [サービス アドレスの範囲] が、Service のセカンダリ範囲です。

トラブルシューティング

このセクションでは、VPC ネイティブ クラスタに関連する問題を解決するためのガイダンスを示します。

The resource 'projects/[PROJECT_NAME]/regions/XXX/subnetworks/default' is not ready

考えられる原因
同じサブネット上で操作が平行して行われています。たとえば、別の VPC ネイティブ クラスタが作成されている、サブネット上でセカンダリ範囲の追加または削除が行われている、などです。
解決策
コマンドを再試行してください。

Invalid value for field 'resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'."

考えられる原因

別の VPC ネイティブ クラスタが同時に作成されていて、同じ VPC ネットワークの同じ範囲を割り当てようとしています。

同じセカンダリ範囲が同じ VPC ネットワークのサブネットワークに追加されようとしています。

解決策

セカンダリ範囲がまだ指定されていない状態でクラスタ作成コマンドを実行して、このエラーが返された場合は、しばらくしてからクラスタの作成コマンドを再試行してください。

Pod 用の空き IP スペースが不足している

現象

クラスタが長い時間プロビジョニング状態で停止している

クラスタの作成時にマネージド インスタンス グループ(MIG)エラーが返される

新しいノードを既存のクラスタに追加できない

考えられる原因

Pod IP 範囲内の未割り当てスペースが、クラスタ内でリクエストされたノードに対して十分な大きさではありません。たとえば、クラスタの Pod IP 範囲にサイズが /23(512 個のアドレス)のネットマスクがあり、ノードあたりの Pod 最大数が 110 である場合、2 個より多くのノードを作成することはできません(各ノードには、サイズが /24 のネットマスクを持つエイリアス IP 範囲が割り当てられます)。

解決策

適切にサイズ調整されたプライマリとセカンダリの IP 範囲を確認して計画した後、代替クラスタを作成します。VPC ネイティブ クラスタの IP 範囲IP 範囲の計画をご覧ください。

クラスタを置き換えることができない場合、ノードあたりの Pod 最大数をより少なく設定して新しいノードプールを作成することで、問題を回避できる可能性があります。可能であれば、ワークロードをそのノードプールに移行してから、以前のノードプールを削除してください。ノードあたりの Pod 最大数を減らすと、Pod の固定されたセカンダリ IP 範囲でより多くのノードをサポートできるようになります。関連する計算の詳細については、Pod 用のサブネット セカンダリ IP アドレス範囲ノード制限範囲をご覧ください。

デフォルトの SNAT が無効になっているかどうか確認する

デフォルトの SNAT のステータスを確認するには、次のコマンドを使用します。

gcloud beta container clusters describe cluster-name

cluster-name は、使用するクラスタの名前に置き換えます。

次のように、出力に disableDefaultSnat フィールドが含まれます。

networkConfig:
  disableDefaultSnat: true
  network: ...

--enable-ip-alias なしで --disable-default-snat は使用できない

このエラー メッセージと must disable default sNAT (--disable-default-snat) before using public IP 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 ルールによってマスカレードされていないことを確認します。IP マスカレードの iptables の出力例で、iptables ルールとデフォルト ルールのリストを確認してください。クラスタに IP マスカレード エージェントが構成されていない場合、GKE は Pod 間の通信が自動的にマスカレードされないようにします。IP マスカレード エージェントが構成されている場合は、デフォルトの IP マスカレード ルールがオーバーライドされます。Pod 範囲のマスカレードを無視するように、IP マスカレード エージェントで追加のルールが構成されていることを確認します。

次のステップ