Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

下り（外向き）NAT ゲートウェイを構成する

このドキュメントでは、Google Distributed Cloud の下り（外向き）NAT ゲートウェイを設定する方法について説明します。このゲートウェイは、クラスタからの下り（外向き）トラフィックに永続的で確定的な SNAT IP アドレスを提供します。クラスタのユーザー外部で下り（外向き）のユーザートラフィックがあるワークロードを実行する場合、お客様は、いくつかの確定的な IP アドレスを使用してこのトラフィックを特定する必要があります。これにより、お客様は許可リストポリシーなどの IP ベースのセキュリティ対策を確立できます。

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

下り（外向き）NAT ゲートウェイは、2 つのカスタムリソースを使用することで有効になります。特定の Namespace に対して、NetworkGatewayGroup カスタムリソースでは、ゲートウェイとして機能するように選択された Node のネットワークインターフェース上に構成できるフローティング IP アドレスを指定します。EgressNatPolicy カスタムリソースでは、下り（外向き）ゲートウェイでトラフィックを制御する下り（外向き）ルーティングポリシーを指定できます。

下り（外向き）NAT ゲートウェイを設定しない場合、または下り（外向き）トラフィックがトラフィック選択ルールに適合しない場合は、特定の Pod からクラスタ外部の宛先への下り（外向き）トラフィックは、Pod が実行されているノードの IP アドレスにマスカレードされます。このシナリオでは、特定の Pod からの下り（外向き）トラフィックがすべて同じ送信元 IP アドレスを持つ、または同じノード IP アドレスにマスカレードされることは保証されません。

下り（外向き）NAT ゲートウェイは、Dataplane V2 上に構築された高度なネットワーキングサービスです。

下り（外向き）NAT ゲートウェイの仕組み

下り（外向き）トラフィック選択ロジックは、Namespace セレクタ、Pod セレクタ、CIDR ブロック表記の宛先 IP アドレス範囲のセットに基づいています。下り（外向き）NAT ゲートウェイの仕組みを説明するために、Pod から外部コンシューマへのパケットフローと対応するレスポンスについて考えてみます。Node のサブネットに 192.168.1.0/24 CIDR ブロックの IP アドレスがあるとします。

次の図は、ゲートウェイノードを経由する下り（外向き）トラフィックのネットワークアーキテクチャを示しています。

Google Distributed Cloud の下り（外向き）NAT ゲートウェイの図

下り（外向き）NAT ゲートウェイを通過するパケットフローは次のようになります。

下り（外向き）トラフィックは、IP アドレス 192.168.1.1 の Node に存在する IP アドレス 10.10.10.1 の Pod から生成されます。

トラフィックの宛先アドレスは、クラスタの外部に存在するエンドポイントです。
トラフィックが下り（外向き）ルールに一致する場合、eBPF プログラムは、Node の IP アドレスにマスカレードする代わりに、下り（外向き）トラフィックをゲートウェイ Node にルーティングします。
ゲートウェイ Node は下り（外向き）トラフィックを受信します。
ゲートウェイノードは、EgressNATPolicy カスタムリソースで指定された送信元の下り（外向き）IP アドレス 192.168.1.100 を使用して、送信元トラフィックの送信元 IP アドレス 10.10.10.1 をマスカレードします。
戻りトラフィックは、宛先が 192.168.1.100 であるゲートウェイ Node に戻ります。
ゲートウェイノードは、戻りトラフィックの conntrack と元の下り（外向き）トラフィックの conntrack を照合し、宛先 IP アドレスを 10.10.10.1 として書き換えます。
10.10.10.1 はクラスタ内のトラフィックとして扱われ、元の Node にルーティングされ、元の Pod に配信されます。

ノードトラフィックに対するフローティング IP アドレスの構成

Network Gateway Group のカスタムリソースは、Google Distributed Cloud のバンドルコンポーネントです。このリソースは、クラスタ内のノードからの下り（外向き）トラフィックに使用する 1 つ以上のフローティング IP アドレスのリストを管理します。参加ノードは、指定された名前空間によって決定されます。Network Gateway Group は、フローティング IP アドレスをベストエフォート方式でいつでも利用できるようにします。フローティング IP アドレスを使用する Node が停止した場合、高度なネットワークオペレーターが割り当てられた IP アドレスを次に使用可能な Node に移動します。この IP アドレスを使用するすべてのワークロードの下り（外向き）トラフィックも移行されます。

1.36.100-gke.144 クラスタを新規作成する際に、クラスタ構成ファイルに Network Gateway Group の詳細情報（アノテーションと仕様）を含めます。

`NetworkGatewayGroup` カスタムリソースを作成する

次の例に示すように、クラスタを作成するときにクラスタ構成ファイルの spec.clusterNetwork.advancedNetworking フィールドを true に設定し、Network Gateway Group を有効にします。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

NetworkGatewayGroup カスタムリソースを作成する際は、次の例に示すように、名前空間をクラスタ名前空間に設定し、フローティング IP アドレスのリストを指定します。

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

高度なネットワークオペレータは、次の基準に基づいてフローティング IP をノードに割り当てます。

Node のサブネット: フローティング IP アドレスは、Node のサブネットと一致する必要があります。
Node のロール（コントロールプレーン、ワーカー）: フローティング IP アドレスを割り当てると、ワーカー Node がコントロールプレーン Node よりも優先されます。
ノードにフローティング IP アドレスが割り当てられているかどうか: オペレータは、フローティング IP アドレスがまだ割り当てられていないノードへの割り当てを優先します。

アドレスとノードのマッピングは、NetworkGatewayGroup オブジェクトの取得時に status セクションで確認できます。NetworkGatewayGroup オブジェクトは kube-system Namespace にあることに注意してください。ゲートウェイノードが停止すると、高度なネットワークオペレーターは、次に使用可能な Node にフローティング IP アドレスを割り当てます。

ゲートウェイの構成を確認する

ゲートウェイ構成の変更を適用した後は、kubectl を使用してゲートウェイのステータスを確認し、ゲートウェイ用に指定されたフローティング IP アドレスを取得できます。

次のコマンドを使用して、NetworkGatewayGroup のステータスを確認し、フローティング IP アドレスがどのように割り振られているかを把握します。

kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

2 つのノード（worker1 と worker2）が配置されたクラスタに対するレスポンスは、次のようになります。

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
status:
  nodes:
    worker1: Up
    worker2: Up // Or Down
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

トラフィック選択ルールを設定する

EgressNATPolicy カスタムリソースでは、トラフィック選択ルールを指定し、クラスタから出る下り（外向き）トラフィックに決定的な IP アドレスを割り当てます。カスタムリソースを指定する際は、egress（少なくとも 1 つのルールを含む）、destinationCIDRs、egressSourceIP がすべて必要です。

kubectl apply を使用して EgressNATPolicy カスタムリソースを作成します。以下のセクションでは、仕様を定義するための詳細と例について説明します。

下り（外向き）ルーティングルールを指定する

EgressNatPolicy カスタムリソースを使用すると、下り（外向き）トラフィックに対して次のルールを指定できます。

egress セクションには、1 つ以上の下り（外向き）トラフィック選択ルールを指定する必要があります。
- 各ルールは、podSelector と namespaceSelector で構成されます。
- 選択は、Namespace ラベル namespaceSelector.matchLabels.user と Pod ラベル podSelector.matchLabels.role に基づいて行われます。
- Pod がいずれかのルールに一致する場合（照合では OR 関係を使用）は、下り（外向き）トラフィックに対して Pod が選択されます。
destinationCIDRs セクションで許可する宛先アドレスを指定します。
- destinationCIDRs は、CIDR ブロックのリストを取得します。
- Pod からの送信トラフィックに、指定したいずれかの CIDR ブロックの範囲に該当する宛先 IP アドレスが割り振られている場合は、下り（外向き）トラフィックとして選択されます。

以下の例では、次の条件を満たす場合に、Pod からの下り（外向き）トラフィックが許可されます。

Pod に role: frontend というラベルが付加されている。
Pod が user: alice または user: paul のラベルが付加された名前空間にある。
Pod が 8.8.8.0/24 CIDR ブロックの IP アドレスと通信している。

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
spec:
  sources:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  action: SNAT
  destinations:
    - cidr: 8.8.8.0/24
  gatewayRef:
    name: default
    namespace: kube-system

ラベルの使用の詳細については、Kubernetes ドキュメントのラベルとセレクタをご覧ください。

下り（外向き）トラフィックの送信元 IP アドレスを取得する

EgressNATPolicy カスタムリソース（ポリシー）は、gatewayRef.name の値と gatewayRef.namespace の値を使用して NetworkGatewayGroup オブジェクト（ゲートウェイ）を検索します。このポリシーでは、下り（外向き）トラフィックの送信元 IP アドレスとして、ゲートウェイのフローティング IP アドレスの一つを使用します。一致するゲートウェイに複数のフローティング IP アドレスがある場合、ポリシーは floatingIPs リストの最初の IP アドレスを使用し、他の IP アドレスは無視されます。ゲートウェイの例では、floatingIPs リストの最初のアドレスは 192.168.1.100 です。gatewayRef セクションに無効なフィールドまたは値が含まれていると、ポリシーオブジェクトが適用されません。

複数の下り（外向き）ポリシーと複数のゲートウェイオブジェクト

前のセクションで説明したように、各 egressNATPolicy オブジェクト（ポリシー）は gatewayRef.name と gatewayRef.namespace に一致するゲートウェイオブジェクトの floatingIPs リストの最初の IP アドレスを使用します。複数のポリシーを作成できます。異なる IP アドレスを使用する場合は、複数の NetworkGatewayGroup オブジェクトを作成して、それぞれを参照する必要があります。

各 NetworkGatewayGroup リソースには、一意のフローティング IP アドレスを含める必要があります。同じ IP アドレスを使用するように複数の EgressNATPolicy オブジェクトを構成するには、同じ gatewayRef.name と gatewayRef.namespace を両方に使用します。

複数の下り（外向き）ポリシーと複数のゲートウェイオブジェクトを設定するには、次を実行します。

kube-system Namespace にゲートウェイオブジェクトを作成して、各フローティング IP アドレスを管理します。通常、正しい IP アドレスが割り振られるように、各下り（外向き）ポリシーには対応するゲートウェイオブジェクトが必要です。

次に、kubectl で各ゲートウェイオブジェクトを確認し、フローティング IP アドレスの割り振りステータスを取得します。

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway1
spec:
  floatingIPs:
  - 192.168.1.100
status:
  ...
  floatingIPs:
    192.168.1.100: worker1
---
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway2
spec:
  floatingIPs:
  - 192.168.1.101
status:
  ...
  floatingIPs:
    192.168.1.101: worker2
---
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: gateway3
spec:
  floatingIPs:
  - 192.168.1.102
status:
  ...
  floatingIPs:
    192.168.1.102: worker1

ゲートウェイオブジェクトを参照する複数のポリシー（前のステップで作成した gateway1 など）を作成します。

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress1
spec:
  ...
  gatewayRef:
    name: gateway1
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress2
spec:
  ...
  gatewayRef:
    name: gateway2
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress3
spec:
  ...
  gatewayRef:
    name: gateway3
    namespace: kube-system

（省略可）フローティング IP アドレスを配置するノードを指定する

NetworkGatewayGroup リソースはノードセレクタをサポートしています。フローティング IP アドレスのホストとみなされるノードのサブセットを指定するには、次のサンプルに示すように、ノードセレクタを NetworkGatewayGroup オブジェクトに追加します。

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  nodeSelector:
    node-type: "egressNat"

ノードセレクタは、指定されたラベルを持つノードと一致し、これらのノードのみがフローティング IP アドレスのホストとして考慮されます。複数のセレクタを指定した場合、そのロジックは追加的であるため、フローティング IP アドレスのホストと見なされるには、ノードがすべてのラベルと一致する必要があります。一致するラベルを持つノードが少ない場合、ノードセレクタにより、フローティング IP アドレスの配置の高可用性（HA）品質が低下する可能性があります。

高可用性下り（外向き）NAT ゲートウェイの高速フェイルオーバー

バージョン 1.34 以降のクラスタでは、高速フェイルオーバーで下り（外向き）NAT ゲートウェイを構成できます。複数のフローティング IP アドレスがあり、高速フェイルオーバーを構成すると、高可用性の下り（外向き）が提供されます。この機能により、下り（外向き）トラフィックの負荷分散が改善され、フェイルオーバーが高速化されてダウンタイムが最小限に抑えられます。クラスタは、一度に 1 つのゲートウェイノード（アクティブ / スタンバイ）に依存するのではなく、複数のゲートウェイノードと NetworkGatewayGroup リソースで構成されたすべてのフローティング IP アドレスにアウトバウンドトラフィックを分散します。

このアクティブ / アクティブモデルには、次のような主なメリットがあります。

負荷分散: Pod などのさまざまな送信元エンドポイントからのアウトバウンドトラフィックは、使用可能なすべてのゲートウェイノードに分散されます。これにより、単一ノードの負荷が軽減され、使用可能な下り（外向き）帯域幅の合計が増加します。
高速フェイルオーバー: 上り（内向き）ゲートウェイノードに障害が発生した場合、トラフィックは残りの正常なノードに自動的にリダイレクトされます。目標は、トラフィックを迅速にフェイルオーバーすることです。障害が発生したノードの既存の接続は切断されますが、新しい接続は他のゲートウェイを介してすぐに確立されるため、ダウンタイムを最小限に抑えることができます。

主な違い

高速フェイルオーバー用に下り（外向き）NAT ゲートウェイを構成すると、下り（外向き）NAT ゲートウェイの動作が次のように変わります。

能力	アクティブ / スタンバイ（デフォルト）	アクティブ / アクティブ（高速フェイルオーバー）
フローティング IP の使用状況	`EgressNATPolicy` は、`NetworkGatewayGroup` の最初のフローティング IP アドレスのみを使用します。	`NetworkGatewayGroup` にリストされているすべてのフローティング IP アドレスは、下り（外向き）トラフィックをアクティブに分散します。
フェイルオーバー	ゲートウェイノードに障害が発生すると、同じフローティング IP アドレスが別のノードに移動し、トラフィックが中断される可能性があります。	ゲートウェイノードが失敗すると、トラフィックは別のノードの別の正常な IP アドレスにリダイレクトされます。新しい接続は正常なゲートウェイを介してすぐにルーティングされますが、失敗したノードの既存のステートフル接続は終了します。
トラフィック	特定のポリシーのすべてのトラフィックは、単一のゲートウェイノードを通過します。	トラフィックは、Pod などの送信元エンドポイントのコンシステントハッシュ法に基づいて、複数のゲートウェイノードに分散されます。

高速フェイルオーバーを構成する

この機能を構成するには、次の 2 つの主な手順を行います。

複数のフローティング IP アドレスを指定します。

高可用性とロードバランシングのメリットを実現するには、少なくとも 2 つのフローティング IP アドレスのプールを使用して NetworkGatewayGroup を構成します。フローティング IP アドレスを増やすと、下り（外向き）の信頼性とスループットが向上します。

構成の例を次に示します。
```
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: egress-gateways
  namespace: cluster-admin
spec:
  nodeSelector:
    # Selects nodes that are designated as egress gateways
    node-role.kubernetes.io/egress: ""
  floatingIPs:
  - "192.168.1.100"
  - "192.168.1.101"
  - "192.168.1.102"
```
高速フェイルオーバーを有効にするには、EgressNATPolicy カスタムリソースに networking.gke.io/egressnat-ha: "enable" アノテーションを追加します。
```
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
  annotations:
    networking.gke.io/egressnat-ha: "enable"
spec:
  ...
```

下り（外向き）トラフィックの選択ルールとネットワークポリシー

下り（外向き）NAT ゲートウェイは、ネットワークポリシー API と互換性があります。ネットワークポリシーが最初に評価され、下り（外向き）NAT ゲートウェイのトラフィック選択ルールよりも優先されます。たとえば、下り（外向き）トラフィックによってネットワークポリシーがトリガーされ、パケットがドロップされた場合、下り（外向き）ゲートウェイルールはパケットを確認しません。ネットワークポリシーでパケットの下り（外向き）が許可されている場合にのみ、下り（外向き）トラフィック選択ルールが評価され、トラフィックの処理方法（下り（外向き）NAT ゲートウェイを使用するか、Pod が実行されている Node の IP アドレスで直接マスカレードするか）が決定されます。

制限事項

下り（外向き）NAT ゲートウェイの現在の制限事項には、次のものがあります。

下り（外向き）NAT ゲートウェイは IPv4 モードでのみ有効になります。
下り（外向き）IP アドレスは、ノード IP アドレスと同じレイヤ 2 ドメイン内に存在する必要があります。
下り（外向き）NAT とともに標準の BGP ロードバランシングを構成し、GKE On-Prem API を使用してクラスタを管理する場合（Terraform、 Google Cloud コンソール、gcloud CLI を使用）、BGP ピアセレクタはサポートされません。このサポートの欠如により、BGP セッションでピアリングに誤ったローカル IP がランダムに使用され、BGP ピアリングの失敗につながる可能性があります。回避策については、BGP を使用してバンドルされたロードバランサを構成する: BGP セレクタの制限事項をご覧ください。