このページでは、Pod のマルチネットワーク サポートを使用して、Google Kubernetes Engine（GKE）クラスタ内のノードと Pod で複数のインターフェースを有効にする方法について説明します。
このページを読む前に、一般的なネットワーキングのコンセプト、この機能に固有の用語とコンセプト、Pod のマルチネットワーク サポートに関する要件と制限事項について理解しておいてください。
詳細については、Pod のマルチネットワーク サポートについてをご覧ください。
要件と制限事項
Pod のマルチネットワーク サポートには、以下の要件と制限があります。
要件
- GKE Standard バージョン 1.28 以降。
- GKE Autopilot バージョン 1.29.5-gke.1091000 以降、またはバージョン 1.30.1-gke.1280000 以降。
- Pod のマルチネットワーク サポートでは、Compute Engine のマルチ NIC と同じ VM レベルの仕様が使用されます。
- Pod のマルチネットワーク サポートには、GKE Dataplane V2 が必要です。
- Pod のマルチネットワーク サポートは、バージョン m101 以降を実行している Container-Optimized OS ノードでのみ使用できます。
一般的な制限事項
- Pod のマルチネットワーク サポートは、デュアルスタック ネットワーキングが有効になったクラスタでは機能しません。
- 共有 VPC は、GKE バージョン 1.28 以降でのみサポートされます。
- マルチ Pod CIDR は、GKE バージョン 1.29 以降で、デフォルトの Pod ネットワークでのみサポートされます。
- 1 つの GKE クラスタ内のどの Pod ネットワークも、重複する CIDR 範囲は設定できません。
- Pod のマルチネットワーク サポートを有効にすると、ノードプールの作成後にノード ネットワーク インターフェースや Pod ネットワークを追加や削除できません。これらの設定を変更するには、ノードプールを再作成する必要があります。
- デフォルトでは、Pod 内の Pod ネットワークの追加のインターフェースで、インターネット アクセスを使用できません。ただし、Cloud NAT を使用して手動で有効にできます。
- 複数のインターフェースを持つ Pod 内部のデフォルト ゲートウェイを API で変更することはできません。デフォルト ゲートウェイは、デフォルトの Pod ネットワークに接続する必要があります。
- 追加の Pod ネットワークまたはインターフェースを作成した場合でも、デフォルトの Pod ネットワークは、常に Pod に含まれている必要があります。
- Managed Hubble が構成されている場合、マルチネットワーク機能を構成することはできません。
- 共有 VPC を使用するには、GKE クラスタでバージョン 1.28.4 以降を実行していることを確認します。
- 共有 VPC デプロイの場合、ノードに接続されているすべてのネットワーク インターフェース（NIC）は、ホスト プロジェクトと同じプロジェクトに属している必要があります。
- デバイスタイプのネットワーク オブジェクトの名前は 41 文字以内にする必要があります。各 UNIX ドメイン ソケットの完全パス（対応するネットワーク名を含む）が構成されます。Linux では、ソケットパスの長さに制限があります（107 バイト以下）。ディレクトリ、ファイル名の接頭辞、
.sock拡張子を考慮すると、ネットワーク名の上限は 41 文字になります。
デバイスとデータプレーン開発キット（DPDK）の制限事項
Deviceタイプの NIC として Pod に渡された VM NIC は、同じノードにある他の Pod では使用できません。- VFIO デバイスにアクセスするには、DPDK モードを使用する Pod が特権モードで実行される必要があります。
- Autopilot モードは DPDK をサポートしていません。
- DPDK モードでは、デバイスはノードリソースとして扱われ、Pod 内の最初のコンテナ（init 以外）にのみ接続されます。複数の DPDK デバイスを同じ Pod 内のコンテナ間で分割する場合は、それらのコンテナを別々の Pod で実行する必要があります。
スケーリングの制限事項
GKE は、クラスタをスケールできる柔軟なネットワーク アーキテクチャを提供します。ノード ネットワークと Pod ネットワークをクラスタに追加できます。クラスタは、次のようにスケールできます。
- 各 GKE ノードプールに最大 7 つのノード ネットワークを追加できます。これは、Compute Engine VM と同じスケール上限です。
- 各 Pod にアタッチできる追加のネットワークは 7 つ未満です。
- 1 つのノードプール内の 8 つのノード ネットワーク全体で最大 35 の Pod ネットワークを構成できます。たとえば、次のようないくつかの組み合わせに分けることができます。
- それぞれに 5 つの Pod ネットワークがある 7 つのノード ネットワーク。
- それぞれに 7 つの Pod ネットワークがある 5 つのノード ネットワーク。
- 30 の Pod ネットワークがある 1 つのノード ネットワーク。サブネットあたりのセカンダリ範囲の上限は 30 です。
- 1 クラスタあたり最大 50 の Pod ネットワークを構成できます。
- 1 ノードあたり最大 32 のマルチネットワーク Pod を構成できます。
- 複数のインターフェースを持つノードは最大 5,000 ノード構成できます。
- すべての Pod 合わせて最大 100,000 のインターフェースを構成できます。
マルチネットワーク Pod をデプロイする
マルチネットワーク Pod をデプロイする手順は次のとおりです。
- 追加の VPC、サブネット（ノード ネットワーク）、セカンダリ範囲（Pod ネットワーク）を準備します。
- Google Cloud CLI コマンドを使用して、マルチネットワーク対応の GKE クラスタを作成します。
- Google Cloud CLI コマンドを使用して、追加のノード ネットワークと Pod ネットワークに接続されている新しい GKE ノードプールを作成します。
- Kubernetes API を使用して、Pod ネットワークを作成し、マルチネットワーク オブジェクトで正しい VPC、サブネット、セカンダリ範囲を参照します。
- ワークロード構成で、Kubernetes API を使用して、準備した Network Kubernetes オブジェクトを参照します。
始める前に
始める前に、次の作業が完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateを実行して最新のバージョンを取得する。
- 要件と制限事項を確認します。
追加の VPC を準備する
Google Cloud は、クラスタの作成時にデフォルトの Pod ネットワークを作成し、GKE クラスタの最初の作成時に使用された GKE ノードプールに関連付けます。デフォルトの Pod ネットワークは、すべてのクラスタノードと Pod で使用できます。ノードプール内のマルチネットワーク機能を促進するには、Layer 3 タイプと Device タイプのネットワークをサポートする既存または新しい VPC を準備する必要があります。
追加の VPC を準備するには、次の要件を考慮してください。
Layer 3タイプおよびNetdeviceタイプのネットワーク:- セカンダリ範囲は、
Layer 3タイプのネットワークを使用している場合に作成します。 - セカンダリ範囲の CIDR サイズが、ノードプール内のノード数と配置しようとしているノードあたりの Pod 数を満たせるだけの大きさであることを確認します。
- デフォルトの Pod ネットワークと同様、他の Pod ネットワークは IP アドレスのオーバープロビジョニングを使用します。セカンダリ IP アドレス範囲には、ノードあたりの Pod 数の 2 倍の数の IP アドレスが必要です。
- セカンダリ範囲は、
Deviceタイプのネットワークの要件: VPC に通常のサブネットを作成します。セカンダリ サブネットは必要ありません。
ノードプールでマルチネットワーク機能を有効にするには、追加の接続を確立する VPC を準備する必要があります。既存の VPC を使用できます。または、ノードプール専用の新しい VPC を作成することもできます。
Layer 3 タイプのデバイスをサポートする VPC ネットワークを作成する
Layer 3 タイプのデバイスをサポートする VPC ネットワークを作成する手順は次のとおりです。
- セカンダリ範囲の CIDR サイズが、ノードプール内のノード数と配置しようとしているノードあたりの Pod 数を満たせるだけの大きさであることを確認します。
デフォルトの Pod ネットワークと同様、他の Pod ネットワークは IP アドレスのオーバープロビジョニングを使用します。セカンダリ IP アドレス範囲には、ノードあたりの Pod 数の 2 倍の数の IP アドレスが必要です。
gcloud
gcloud compute networks subnets create SUBNET_NAME \
--project=PROJECT_ID \
--range=SUBNET_RANGE \
--network=NETWORK_NAME \
--region=REGION \
--secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>
次のように置き換えます。
SUBNET_NAME: サブネットの名前。PROJECT_ID: サブネットが作成される VPC ネットワークを含むプロジェクトの ID。SUBNET_RANGE: 新しいサブネットのプライマリ IPv4 アドレス範囲（CIDR 表記）。NETWORK_NAME: 新しいサブネットを含む VPC ネットワークの名前。REGION: 新しいサブネットが作成される Google Cloud リージョン。SECONDARY_RANGE_NAME: セカンダリ範囲の名前。SECONDARY_IP_RANGE: セカンダリ IPv4 アドレス範囲（CIDR 表記）。
コンソール
Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] フィールドに、ネットワークの名前を入力します。例:
l3-vpc[最大伝送単位（MTU）] プルダウンから、適切な MTU 値を選択します。
[サブネット作成モード] で [カスタム] を選択します。
[サブネットを追加] をクリックします。
[新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
名前を入力します。例:
l3-subnetリージョンを選択します。
IP アドレス範囲を入力します。これはサブネットのプライマリ IPv4 範囲です。
RFC 1918 アドレス以外の範囲を選択した場合は、その範囲が既存の構成と競合していないことを確認します。詳細については、IPv4 サブネットの範囲をご覧ください。
サブネットのセカンダリ範囲を定義するには、[セカンダリ IP アドレス範囲を作成する] をクリックします。
RFC 1918 アドレス以外の範囲を選択した場合は、その範囲が既存の構成と競合していないことを確認します。詳細については、IPv4 サブネットの範囲をご覧ください。
限定公開の Google アクセス: 作成時にサブネットの限定公開の Google アクセスを有効にできます。後で編集して有効にすることもできます。
フローログ: 作成時にサブネットに対して VPC Flow Logs を有効にできます。後で編集して有効にすることもできます。
[Done] をクリックします。
[ファイアウォール ルール] セクションの [IPv4 ファイアウォール ルール] で、事前定義された 0 個以上のファイアウォール ルールを選択します。
このルールは、インスタンスへの接続の一般的なユースケースに対応します。ネットワークを作成した後で、独自のファイアウォール ルールを作成できます。事前定義ルールのそれぞれの名前は、作成する VPC ネットワークの名前で始まります。
[IPv4 ファイアウォール ルール] で
allow-customという名前の事前定義された上り（内向き）ファイアウォール ルールを編集するには、[編集] をクリックします。サブネットの編集、IPv4 範囲の追加、プロトコルとポートの指定を行うことができます。
後でサブネットを追加しても、
allow-customファイアウォール ルールは自動更新されません。新しいサブネット用のファイアウォール ルールが必要な場合、ルールを追加するには、ファイアウォール構成を更新する必要があります。VPC ネットワーク用の [動的ルーティング モード] セクションで操作します。詳細については、動的ルーティング モードをご覧ください。動的ルーティング モードは後で変更できます。
[作成] をクリックします。
Netdevice タイプまたは DPDK タイプのデバイスをサポートする VPC ネットワークを作成する
gcloud
gcloud compute networks subnets create SUBNET_NAME \
--project=PROJECT_ID \
--range=SUBNET_RANGE \
--network=NETWORK_NAME \
--region=REGION \
--secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>
次のように置き換えます。
SUBNET_NAME: サブネットの名前。PROJECT_ID: サブネットが作成される VPC ネットワークを含むプロジェクトの ID。SUBNET_RANGE: 新しいサブネットのプライマリ IPv4 アドレス範囲（CIDR 表記）。NETWORK_NAME: 新しいサブネットを含む VPC ネットワークの名前。REGION: 新しいサブネットが作成される Google Cloud リージョン。SECONDARY_RANGE_NAME: セカンダリ範囲の名前。SECONDARY_IP_RANGE: セカンダリ IPv4 アドレス範囲（CIDR 表記）。
コンソール
Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] フィールドに、ネットワークの名前を入力します。たとえば、
netdevice-vpcやdpdk-vpcです。[最大伝送単位（MTU）] プルダウンから、適切な MTU 値を選択します。
[サブネット作成モード] で [カスタム] を選択します。
[新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
名前を入力します。たとえば、
netdevice-subnetやdpdk-vpcです。リージョンを選択します。
IP アドレス範囲を入力します。これはサブネットのプライマリ IPv4 範囲です。
RFC 1918 アドレス以外の範囲を選択した場合は、その範囲が既存の構成と競合していないことを確認します。詳細については、IPv4 サブネットの範囲をご覧ください。
限定公開の Google アクセス: サブネットの限定公開の Google アクセスを、作成時に有効にするか、後で編集して有効にするかを選択します。
フローログ: 作成時にサブネットに対して VPC Flow Logs を有効にできます。後で編集して有効にすることもできます。
[Done] をクリックします。
[ファイアウォール ルール] セクションの [IPv4 ファイアウォール ルール] で、事前定義された 0 個以上のファイアウォール ルールを選択します。
このルールは、インスタンスへの接続の一般的なユースケースに対応します。ネットワークを作成した後で、独自のファイアウォール ルールを作成できます。事前定義ルールのそれぞれの名前は、作成する VPC ネットワークの名前で始まります。
[IPv4 ファイアウォール ルール] で
allow-customという名前の事前定義された上り（内向き）ファイアウォール ルールを編集するには、[編集] をクリックします。サブネットの編集、IPv4 範囲の追加、プロトコルとポートの指定を行うことができます。
後でサブネットを追加しても、
allow-customファイアウォール ルールは自動更新されません。新しいサブネット用のファイアウォール ルールが必要な場合、ルールを追加するには、ファイアウォール構成を更新する必要があります。VPC ネットワーク用の [動的ルーティング モード] セクションで操作します。詳細については、動的ルーティング モードをご覧ください。動的ルーティング モードは後で変更できます。
[作成] をクリックします。
マルチネットワーク機能を備えた GKE クラスタを作成する
クラスタでマルチネットワーキングを有効にすると、そのクラスタの API サーバーに必要な CustomResourceDefinition（CRD）が追加されます。また、マルチネットワーク オブジェクトの調整と管理を行う Network-controller-manager もデプロイされます。作成後にクラスタ構成を変更することはできません。
マルチネットワーク機能を備えた GKE Autopilot クラスタを作成する
マルチネットワーク機能を備えた GKE Autopilot クラスタを作成します。
gcloud container clusters create-auto CLUSTER_NAME \
--cluster-version=CLUSTER_VERSION \
--enable-multi-networking
次のように置き換えます。
CLUSTER_NAME: クラスタの名前。CLUSTER_VERSION: クラスタのバージョン。
--enable-multi-networking フラグは、このクラスタの API サーバーでマルチ ネットワーキング カスタム リソース定義（CRD）を有効にし、network-controller-manager をデプロイします。この中には、マルチネットワーク オブジェクトの調整とライフサイクルの管理が含まれます。
マルチネットワーク機能を備えた GKE Standard クラスタを作成する
gcloud
マルチネットワーク機能を備えた GKE Standard クラスタを作成します。
gcloud container clusters create CLUSTER_NAME \
--cluster-version=CLUSTER_VERSION \
--enable-dataplane-v2 \
--enable-ip-alias \
--enable-multi-networking
次のように置き換えます。
CLUSTER_NAME: クラスタの名前。CLUSTER_VERSION: クラスタのバージョン。
このコマンドには、次のフラグが含まれています。
--enable-multi-networking:は、このクラスタの API サーバーでマルチ ネットワーキング カスタム リソース定義（CRD）を有効にし、network-controller-manager をデプロイします。この中には、マルチネットワーク オブジェクトの調整とライフサイクルの管理が含まれます。--enable-dataplane-v2:は、GKE Dataplane V2 を有効にします。このフラグは、マルチネットワークを有効にするために必要です。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[add_box 作成] をクリックします。
Standard クラスタを構成します。詳細については、ゾーンクラスタを作成するまたはリージョン クラスタを作成するをご覧ください。クラスタの作成時に、ネットワークとノードの適切なサブネットを選択します。
ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。
[Dataplane V2 を有効にする] チェックボックスをオンにします。
[マルチネットワークを有効にする] を選択します。
[作成] をクリックします。
追加の VPC に接続する GKE Standard ノードプールを作成する
Pod ネットワークを作成するで作成したノード ネットワーク（VPC とサブネット）と Pod ネットワーク（セカンダリ範囲）に接続されているノードを含むノードプールを作成します。
新しいノードプールを作成し、GKE クラスタ内の追加のネットワークに関連付けるには:
gcloud
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--additional-node-network network=NETWORK_NAME,subnetwork=SUBNET_NAME \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=POD_IP_RANGE,max-pods-per-node=NUMBER_OF_PODS \
--additional-node-network network=highperformance,subnetwork=subnet-highperf
次のように置き換えます。
POOL_NAMEは、新しいノードプールの名前に置き換えます。CLUSTER_NAMEは、ノードプールを追加する既存のクラスタの名前に置き換えます。NETWORK_NAMEは、ノードプールのノードを接続するネットワークの名前に置き換えます。SUBNET_NAMEは、ノードに使用するネットワーク内のサブネットの名前に置き換えます。POD_IP_RANGEはサブネット内の Pod IP アドレス範囲です。NUMBER_OF_PODSはノードあたりの Pod の最大数です。
このコマンドには次のフラグが含まれています。
--additional-node-network: 追加のネットワーク インターフェース、ネットワーク、サブネットワークの詳細を定義します。これは、ノードプール ノードに接続するためのノード ネットワークを指定するために使用されます。別の VPC に接続する場合は、このパラメータを指定します。このパラメータを指定しない場合は、クラスタに関連付けられたデフォルトの VPC が使用されます。Layer 3タイプのネットワークの場合、Pod ネットワークを定義するadditional-pod-networkフラグを指定します。これは、GKE クラスタ内にNetworkオブジェクトとして公開されます。--additional-node-networkフラグを使用する場合は、必須パラメータとしてネットワークとサブネットワークを指定する必要があります。ネットワークとサブネットワークの値はカンマで区切り、スペースは使用しないでください。--additional-pod-network: Pod ネットワークに使用されるセカンダリ範囲の詳細を指定します。Deviceタイプのネットワークを使用している場合、このパラメータは必要ありません。この引数には、キー値（subnetwork、pod-ipv4-range、max-pods-per-node）を指定します。--additional-pod-networkを使用するときは、pod-ipv4-rangeとmax-pods-per-nodeの値をカンマで区切り、スペースを入れずに指定する必要があります。subnetwork: node-network を Pod ネットワークにリンクします。このサブネットワークは省略できます。指定しない場合、追加の Pod ネットワークは、クラスタの作成時に指定されたデフォルトのサブネットワークに関連付けられます。--max-pods-per-node:max-pods-per-nodeを、2 の累乗で指定する必要があります。最小値は 4 です。max-pods-per-nodeは、ノードプールのmax-pods-per-node値以下にする必要があります。
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
ナビゲーション パネルで [クラスタ] をクリックします。
[Kubernetes クラスタ] セクションで、作成したクラスタをクリックします。
ノードプールを作成するために、ページの上部にある add_box [ノードプールを追加] をクリックします。
[ノードプールの詳細] セクションで、次の操作を行います。
- [名前] に、ノードプールの名前を入力します。
- ノードプール内に作成するノードの数を入力します。
ナビゲーション パネルで、[ノードプール] の下の [ノード] をクリックします。
[イメージの種類] プルダウン リストから、[containerd（cos_containerd）が含まれている Container-Optimized OS] ノードイメージを選択します。
VM を作成するときに、その VM に使用可能なリソースを決定するマシン ファミリーからマシンタイプを選択します。たとえば、
e2-standard-4のようなマシンタイプには 4 つの vCPU が含まれているため、合計で最大 4 つの VPC をサポートできます。選択できる複数のマシン ファミリーがあり、各マシン ファミリーは、マシンシリーズおよび各シリーズ内の事前定義されたマシンタイプまたはカスタム マシンタイプにさらに編成されます。マシンタイプごとに課金方法は異なります。詳細については、マシンタイプの価格表をご覧ください。ナビゲーション パネルで [ネットワーキング] を選択します。
[ノード ネットワーキング] セクションで、ノードあたりの最大 Pod 数を指定します。[ノード ネットワーク] セクションには、クラスタの作成に使用された VPC ネットワークが表示されます。以前に確立した VPC ネットワークとデバイスタイプに対応する追加のノード ネットワークを指定する必要があります。
ノードプールの関連付けを作成します。
Layer 3タイプのデバイスの場合:- [ノード ネットワーク] セクションで、[ノード ネットワークを追加] をクリックします。
- ネットワーク プルダウン リストから、レイヤ 3 タイプのデバイスをサポートする VPC を選択します。
Layer 3VPC 用に作成されたサブネットを選択します。- [エイリアス Pod の IP アドレス範囲] セクションで、[Pod の IP アドレス範囲を追加] をクリックします。
- [セカンダリ サブネット] を選択し、[ノードあたりの Pod の最大数] を指定します。
- [完了] を選択します。
NetdeviceタイプとDPDKタイプのデバイスの場合:- [ノード ネットワーク] セクションで、[ノード ネットワークを追加] をクリックします。
- ネットワーク プルダウン リストから、
NetdeviceタイプまたはDPDKタイプのデバイスをサポートする VPC を選択します。 NetdeviceVPC またはDPDKVPC 用に作成されたサブネットを選択します。- [完了] を選択します。
[作成] をクリックします。
メモ:
- 同じノード ネットワーク内で追加の Pod ネットワークを複数指定する場合は、同じサブネット内に存在する必要があります。
- あるサブネットの同じセカンダリ範囲を複数回参照することはできません。
例 次の例では、pool-multi-net という名前のノードプールを作成し、ノードに datapalane（Layer 3 タイプのネットワーク）と highperformance（netdevice タイプのネットワーク）の 2 つの追加ネットワークを接続します。この例では、cluster-1 という名前の GKE クラスタがすでに作成されていることを前提としています。
gcloud container node-pools create pool-multi-net \
--project my-project \
--cluster cluster-1 \
--zone us-central1-c \
--additional-node-network network=dataplane,subnetwork=subnet-dp \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
--additional-node-network network=highperformance,subnetwork=subnet-highperf
追加のノード ネットワークと Pod ネットワーク インターフェースを指定するには、次の例に示すように --additional-node-network パラメータと --additional-pod-network パラメータを複数回定義します。
--additional-node-network network=dataplane,subnetwork=subnet-dp \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-green,max-pods-per-node=8 \
--additional-node-network network=managementdataplane,subnetwork=subnet-mp \
--additional-pod-network subnetwork=subnet-mp,pod-ipv4-range=sec-range-red,max-pods-per-node=4
次の例に示すように、ノードプールのプライマリ VPC インターフェースで追加の Pod ネットワークを直接指定します。
--additional-pod-network subnetwork=subnet-def,pod-ipv4-range=sec-range-multinet,max-pods-per-node=8
Pod ネットワークを作成
Kubernetes オブジェクトを定義し、対応する Compute Engine リソース（VPC、サブネット、セカンダリ範囲など）にリンクすることで、Pod がアクセスする Pod ネットワークを定義します。
Pod ネットワークを作成するには、クラスタ内にネットワーク CRD オブジェクトを定義する必要があります。
Layer 3 VPC ネットワークを構成する
YAML
Layer 3 VPC に対しては、Network オブジェクトと GKENetworkParamSet オブジェクトを作成します。
次のサンプル マニフェストを
blue-network.yamlとして保存します。apiVersion: networking.gke.io/v1 kind: Network metadata: name: blue-network spec: type: "L3" parametersRef: group: networking.gke.io kind: GKENetworkParamSet name: "l3-vpc"このマニフェストでは、タイプが
Layer 3で名前がblue-networkのNetworkリソースを定義しています。Networkオブジェクトは、ネットワークを Compute Engine リソースに関連付けるl3-vpcという名前のGKENetworkParamSetオブジェクトを参照しています。マニフェストをクラスタに適用します。
kubectl apply -f blue-network.yaml次のマニフェストを
dataplane.yamlとして保存します。apiVersion: networking.gke.io/v1 kind: GKENetworkParamSet metadata: name: "l3-vpc" spec: vpc: "l3-vpc" vpcSubnet: "subnet-dp" podIPv4Ranges: rangeNames: - "sec-range-blue"このマニフェストでは、名前が
dataplaneのGKENetworkParamSetオブジェクトを定義し、VPC 名をdataplane、サブネット名をsubnet-dp、Pod のセカンダリ IPv4 アドレス範囲（sec-range-blue）を設定しています。マニフェストをクラスタに適用します。
kubectl apply -f dataplane.yaml
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
ナビゲーション パネルで [Network Function Optimizer] をクリックします。
ページの上部にある add_box [作成] をクリックして、Pod ネットワークを作成します。
始める前にのセクションで詳細を確認します。
[次へ: Pod ネットワークのロケーション] をクリックします。
[Pod ネットワークのロケーション] セクションの [クラスタ] プルダウンから、マルチネットワーキングと GKE Dataplane V2 が有効になっている GKE クラスタを選択します。
[次へ: VPC ネットワーク リファレンス] をクリックします。
[VPC ネットワークのリファレンス] セクションの [VPC ネットワークのリファレンス] プルダウンから、
Layer 3マルチ NIC Pod に使用する VPC ネットワークを選択します。[次: Pod ネットワークの種類] をクリックします。
[Pod ネットワークの種類] セクションで [L3] を選択し、Pod ネットワーク名を入力します。
[次へ: Pod ネットワークのセカンダリ範囲] をクリックします。
[Pod ネットワークのセカンダリ範囲] セクションで、セカンダリ範囲を入力します。
[次: Pod ネットワークのルート] をクリックします。
[Pod ネットワークのルート] セクションで、カスタムルートを定義するために [ルートを追加] を選択します。
[Pod ネットワークを作成] をクリックします。
DPDK ネットワークを構成する
YAML
DPDK VPC に対しては、Network オブジェクトと GKENetworkParamSet オブジェクトを作成します。
次のサンプル マニフェストを
dpdk-network.yamlとして保存します。apiVersion: networking.gke.io/v1 kind: Network metadata: name: dpdk-network spec: type: "Device" parametersRef: group: networking.gke.io kind: GKENetworkParamSet name: "dpdk"このマニフェストでは、タイプが
Deviceで名前がdpdk-networkのNetworkリソースを定義しています。Networkリソースは、その構成のdpdkというGKENetworkParamSetオブジェクトを参照しています。マニフェストをクラスタに適用します。
kubectl apply -f dpdk-network.yamlGKENetworkParamSetオブジェクトについては、次のマニフェストをdpdk.yamlとして保存します。apiVersion: networking.gke.io/v1 kind: GKENetworkParamSet metadata: name: "dpdk" spec: vpc: "dpdk" vpcSubnet: "subnet-dpdk" deviceMode: "DPDK-VFIO"このマニフェストでは、
dpdkという名前のGKENetworkParamSetオブジェクトを定義し、VPC 名をdpdk、サブネット名をsubnet-dpdk、deviceMode 名をDPDK-VFIOに設定しています。マニフェストをクラスタに適用します。
kubectl apply -f dpdk-network.yaml
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
ナビゲーション パネルで [Network Function Optimizer] をクリックします。
ページの上部にある add_box [作成] をクリックして、Pod ネットワークを作成します。
始める前にのセクションで詳細を確認します。
[次へ: Pod ネットワークのロケーション] をクリックします。
[Pod ネットワークのロケーション] セクションの [クラスタ] プルダウンから、マルチネットワーキングと GKE Dataplane V2 が有効になっている GKE クラスタを選択します。
[次へ: VPC ネットワーク リファレンス] をクリックします。
[VPC ネットワークのリファレンス] セクションの [VPC ネットワークのリファレンス] プルダウンから、dpdk マルチ NIC Pod に使用する VPC ネットワークを選択します。
[次: Pod ネットワークの種類] をクリックします。
[Pod ネットワークの種類] セクションで、[DPDK-VFIO（デバイス）] を選択し、Pod ネットワーク名を入力します。
[次へ: Pod ネットワークのセカンダリ範囲] をクリックします。Pod ネットワークのセカンダリ範囲セクションは使用できません
[次: Pod ネットワークのルート] をクリックします。[Pod ネットワークのルート] セクションで、[ルートを追加] を選択してカスタムルートを定義します。
[Pod ネットワークを作成] をクリックします。
netdevice ネットワークを構成する
netdevice VPC に対しては、Network オブジェクトと GKENetworkParamSet オブジェクトを作成します。
YAML
次のサンプル マニフェストを
netdevice-network.yamlとして保存します。apiVersion: networking.gke.io/v1 kind: Network metadata: name: netdevice-network spec: type: "Device" parametersRef: group: networking.gke.io kind: GKENetworkParamSet name: "netdevice"このマニフェストでは、タイプが
Deviceで名前がnetdevice-networkのNetworkリソースを定義しています。netdeviceという名前のGKENetworkParamSetオブジェクトを参照しています。マニフェストをクラスタに適用します。
kubectl apply -f netdevice-network.yaml次のマニフェストを
netdevice.yamlとして保存します。apiVersion: networking.gke.io/v1 kind: GKENetworkParamSet metadata: name: netdevice spec: vpc: netdevice vpcSubnet: subnet-netdevice deviceMode: NetDeviceこのマニフェストでは、名前が
netdeviceのGKENetworkParamSetリソースを定義し、VPC 名をnetdevice、サブネット名をsubnet-netdeviceに設定して、デバイスモードにNetDeviceを指定しています。マニフェストをクラスタに適用します。
kubectl apply -f netdevice.yaml
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
ナビゲーション パネルで [Network Function Optimizer] をクリックします。
ページの上部にある add_box [作成] をクリックして、Pod ネットワークを作成します。
始める前にのセクションで詳細を確認します。
[次へ: Pod ネットワークのロケーション] をクリックします。
[Pod ネットワークのロケーション] セクションの [クラスタ] プルダウンから、マルチネットワーキングと GKE Dataplane V2 が有効になっている GKE クラスタを選択します。
[次へ: VPC ネットワーク リファレンス] をクリックします。
[VPC ネットワークのリファレンス] セクションの [VPC ネットワークのリファレンス] プルダウンから、netdevice マルチ NIC Pod に使用する VPC ネットワークを選択します。
[次: Pod ネットワークの種類] をクリックします。
[Pod ネットワークの種類] セクションで、[NetDevice（デバイス）] を選択し、Pod ネットワーク名を入力します。
[次へ: Pod ネットワークのセカンダリ範囲] をクリックします。Pod ネットワークのセカンダリ範囲セクションは使用できません
[次: Pod ネットワークのルート] をクリックします。[Pod ネットワークのルート] セクションで、カスタムルートを定義するために [ルートを追加] を選択します。
[Pod ネットワークを作成] をクリックします。
ネットワーク ルートの構成
ネットワーク ルートを構成すると、Pod 上に設定される特定のネットワークにカスタムルートを定義して、Pod 内の対応するインターフェースにトラフィックを直接転送できます。
YAML
次のマニフェストを
red-network.yamlとして保存します。apiVersion: networking.gke.io/v1 kind: Network metadata: name: red-network spec: type: "L3" parametersRef: group: networking.gke.io kind: GKENetworkParamSet name: "management" routes: - to: "10.0.2.0/28"このマニフェストでは、タイプが
Layer 3で名前がred-networkのネットワーク リソースとそのネットワーク インターフェースを介したカスタムルート「10.0.2.0/28」を定義しています。マニフェストをクラスタに適用します。
kubectl apply -f red-network.yaml
コンソール
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
[add_box 作成] をクリックします。
ナビゲーション パネルで [Network Function Optimizer] をクリックします。
[Kubernetes クラスタ] セクションで、作成したクラスタをクリックします。
ページの上部にある add_box [作成] をクリックして、Pod ネットワークを作成します。
[Pod ネットワークのルート] セクションで、[カスタムルート] を定義します。
[Pod ネットワークを作成] をクリックします。
準備した Network を参照する
ワークロード構成で、Kubernetes API を使用して、準備した Network Kubernetes オブジェクトを参照します。
Pod を特定のネットワークに接続する
指定されたネットワークに Pod を接続するには、Pod 構成内のアノテーションとして Network オブジェクトの名前を含める必要があります。接続を確立するために、default Network と選択した追加ネットワークの両方をアノテーションに含めるようにしてください。
次のサンプル マニフェストを
sample-l3-pod.yamlとして保存します。apiVersion: v1 kind: Pod metadata: name: sample-l3-pod annotations: networking.gke.io/default-interface: 'eth0' networking.gke.io/interfaces: | [ {"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"} ] spec: containers: - name: sample-l3-pod image: busybox command: ["sleep", "10m"] ports: - containerPort: 80 restartPolicy: Alwaysこのマニフェストは、
defaultおよびblue-networkネットワークに関連付けられた 2 つのネットワーク インターフェース（eth0とeth1）を持つsample-l3-podという名前の Pod を作成します。マニフェストをクラスタに適用します。
kubectl apply -f sample-l3-pod.yaml
Pod を複数のネットワークに接続する
次のサンプル マニフェストを
sample-l3-netdevice-pod.yamlとして保存します。apiVersion: v1 kind: Pod metadata: name: sample-l3-netdevice-pod annotations: networking.gke.io/default-interface: 'eth0' networking.gke.io/interfaces: | [ {"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}, {"interfaceName":"eth2","network":"netdevice-network"} ] spec: containers: - name: sample-l3-netdevice-pod image: busybox command: ["sleep", "10m"] ports: - containerPort: 80 restartPolicy: Alwaysこのマニフェストは、それぞれ
default、blue-network、netdeviceのネットワークに関連付けられた 3 つのネットワーク インターフェース（eth0、eth1、eth2）を持つsample-l3-netdevice-podという名前の Pod を作成します。マニフェストをクラスタに適用します。
kubectl apply -f sample-l3-netdevice-pod.yaml
テンプレートのアノテーション セクションでは、ReplicaSet（Deployment または DaemonSet）で同じアノテーションを使用できます。
複数のインターフェースを持つ Pod の構成例:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default
link/ether 2a:92:4a:e5:da:35 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.60.45.4/24 brd 10.60.45.255 scope global eth0
valid_lft forever preferred_lft forever
10: eth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
link/ether ba:f0:4d:eb:e8:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.16.1.2/32 scope global eth1
valid_lft forever preferred_lft forever
検証
--enable-dataplane-v2が有効になっている場合にのみ、--enable-multi-networkingを使用してクラスタを作成します。- クラスタとノードプールの作成時に、クラスタ内のすべてのノードプールが Container-Optimized OS イメージを実行していることを確認します。
- クラスタでマルチネットワーキングが有効になっている場合にのみ、
--additional-node-networkまたは--additional-pod-networkを使用してノードプールが作成されたことを確認します。 - 同じサブネットが、ノードプールに対する
--additional-node-network引数として 2 回指定されていないことを確認します。 - ノードプールに対する
--additional-pod-network引数として同じセカンダリ範囲が指定されていないことを確認します。 - ネットワーク オブジェクトに対して指定されたスケール上限に従い、ノード、Pod、IP アドレスの最大数を考慮します。
- 特定のサブネットとセカンダリ範囲を参照する
GKENetworkParamSetオブジェクトが 1 つだけ存在することを確認します。 - 各ネットワーク オブジェクトがそれぞれ異なる
GKENetworkParamSetオブジェクトを参照していることを確認します。 - ネットワーク オブジェクトが
Deviceネットワークの特定のサブネットで作成されている場合、セカンダリ範囲を持つ別のネットワークと同じノードで使用されていないことを確認します。これはランタイム時にのみ検証できます。 - ノードプールに割り当てられたさまざまなセカンダリ範囲で、IP アドレスが重複していないことを確認します。
GKE のマルチネットワーキング パラメータのトラブルシューティング
クラスタとノードプールを作成すると、Google Cloud は特定のチェックを実装して、有効なマルチネットワーキング パラメータのみが許可されるようにします。これにより、クラスタに対してネットワークが正しく設定されます。
マルチネットワーク ワークロードの作成に失敗した場合は、Pod のステータスとイベントで詳細を確認できます。
kubectl describe pods samplepod
出力は次のようになります。
Name: samplepod
Namespace: default
Status: Running
IP: 192.168.6.130
IPs:
IP: 192.168.6.130
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal NotTriggerScaleUp 9s cluster-autoscaler pod didn't trigger scale-up:
Warning FailedScheduling 8s (x2 over 9s) default-scheduler 0/1 nodes are available: 1 Insufficient networking.gke.io.networks/my-net.IP. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod
Pod の作成が失敗する一般的な理由は次のとおりです。
- マルチネットワーキング リソースの要件が満たされないため、Pod をスケジュールできなかった
- 指定したネットワークを特定できなかった
Kubernetes ネットワークの作成に関するトラブルシューティング
ネットワークが正常に作成されると、構成済みのネットワークにアクセスできるノードにネットワーク ステータス アノテーションが付けられます。
アノテーションをモニタリングするには、次のコマンドを実行します。
kubectl describe node NODE_NAME
NODE_NAME は、ノードの名前に置き換えます。
出力は次のようになります。
networking.gke.io/network-status: [{"name":"default"},{"name":"dp-network"}]
出力には、ノードで使用可能な各ネットワークが一覧表示されます。想定したネットワーク ステータスがノードに表示されない場合は、次の手順で操作します。
ノードがネットワークにアクセスできるかどうかを確認する
ネットワークがノードのネットワーク ステータス アノテーションに表示されない場合:
- ノードが、マルチネットワーキング用に構成されたプールの一部であることを確認します。
- ノードのインターフェースに、構成しているネットワーク用のインターフェースがあるかどうかを確認します。
- ノードにネットワーク ステータスがなく、ネットワーク インターフェースが 1 つしかない場合でも、マルチ ネットワーキングを有効にしてノードプールを作成する必要があります。
- 構成しているネットワークのインターフェースはノードに含まれるが、ネットワーク ステータス アノテーションにない場合は、
NetworkリソースとGKENetworkParamSet（GNP）リソースを確認してください。
Network と GKENetworkParamSet のリソースを確認する
Network と GKENetworkParamSet（GNP）リソースのステータスの両方に、構成エラーを報告するための conditions フィールドが含まれています。GNP は別のリソースが有効かどうかに依存しないため、最初に確認することをおすすめします。
[条件] フィールドを調べるには、次のコマンドを実行します。
kubectl get gkenetworkparamsets GNP_NAME -o yaml
GNP_NAME は、GKENetworkParamSet リソースの名前に置き換えます。
Ready 条件が true の場合、構成は有効であり、出力は次のようになります。
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
podIPv4Ranges:
rangeNames:
- sec-range-blue
vpc: dataplane
vpcSubnet: subnet-dp
status:
conditions:
- lastTransitionTime: "2023-06-26T17:38:04Z"
message: ""
reason: GNPReady
status: "True"
type: Ready
networkName: dp-network
podCIDRs:
cidrBlocks:
- 172.16.1.0/24
Ready 条件が false の場合、出力には理由が表示され、次のようになります。
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
podIPv4Ranges:
rangeNames:
- sec-range-blue
vpc: dataplane
vpcSubnet: subnet-nonexist
status:
conditions:
- lastTransitionTime: "2023-06-26T17:37:57Z"
message: 'subnet: subnet-nonexist not found in VPC: dataplane'
reason: SubnetNotFound
status: "False"
type: Ready
networkName: ""
同様のメッセージが表示された場合は、GNP が正しく構成されていることを確認してください。正しい場合は、Google Cloud ネットワークの構成が正しいことを確認してください。Google Cloud ネットワークの構成を更新した後、再同期を手動でトリガーするため、GNP リソースの再作成が必要になることがあります。こうすることで、Google Cloud API の無限ポーリングが回避されます。
GNP の準備ができたら、Network リソースを確認します。
kubectl get networks NETWORK_NAME -o yaml
NETWORK_NAME は、Network リソースの名前に置き換えます。
有効な構成の出力は、次のようになります。
apiVersion: networking.gke.io/v1
kind: Network
...
spec:
parametersRef:
group: networking.gke.io
kind: GKENetworkParamSet
name: dp-gnp
type: L3
status:
conditions:
- lastTransitionTime: "2023-06-07T19:31:42Z"
message: ""
reason: GNPParamsReady
status: "True"
type: ParamsReady
- lastTransitionTime: "2023-06-07T19:31:51Z"
message: ""
reason: NetworkReady
status: "True"
type: Ready
reason: NetworkReadyは、ネットワーク リソースが正しく構成されていることを示します。reason: NetworkReadyは、ネットワーク リソースが必ずしも特定のノード上で使用可能であること、またはアクティブに使用されていることを意味するものではありません。- 構成ミスやエラーがある場合は、条件の
reasonフィールドで、問題の正確な理由が示されます。その場合は、それに応じて構成を調整してください。 - parametersRef フィールドがクラスタ内に存在する
GKENetworkParamSetリソースに設定されている場合、GKE は ParamsReady フィールドに値を設定します。GKENetworkParamSet型の parametersRef を指定しても条件が表示されない場合は、名前、種類、グループがクラスタ内に存在する GNP リソースと一致していることを確認してください。