このドキュメントでは、Google Distributed Cloud の下り（外向き）NAT ゲートウェイを設定する方法について説明します。このゲートウェイは、クラスタからの下り（外向き）トラフィックに対して永続的で決定論的な SNAT IP アドレスを提供します。クラスタのユーザー外部で下り（外向き）のユーザー トラフィックがあるワークロードを実行する場合、お客様は、いくつかの決定論的 IP アドレスを使用してこのトラフィックを特定する必要があります。これにより、お客様は許可リストポリシーなどの IP ベースのセキュリティ対策を確立できます。
このページは、組織のネットワークを設計し、ネットワーク機器の設置、構成、サポートを行うネットワーク スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
下り（外向き）NAT ゲートウェイは、2 つのカスタム リソースを使用することで有効になります。特定の Namespace に対して、NetworkGatewayGroup カスタム リソースでは、ゲートウェイとして機能するように選択された Node のネットワーク インターフェース上に構成できるフローティング IP アドレスを指定します。EgressNatPolicy カスタム リソースでは、下り（外向き）ゲートウェイでトラフィックを制御する下り（外向き）ルーティング ポリシーを指定できます。
下り（外向き）NAT ゲートウェイを設定しない場合、または下り（外向き）トラフィックがトラフィック選択ルールに適合しない場合は、特定の Pod からクラスタ外部の宛先への下り（外向き）トラフィックは、Pod が実行されているノードの IP アドレスにマスカレードされます。このシナリオでは、特定の Pod からの下り（外向き）トラフィックがすべて同じ送信元 IP アドレスを持つ、または同じ Node IP アドレスにマスカレードされる保証はありません。
下り（外向き）NAT ゲートウェイは、Dataplane V2 上に構築された高度なネットワーキング サービスです。
下り（外向き）NAT ゲートウェイの仕組み
下り（外向き）トラフィック選択ロジックは、Namespace セレクタ、Pod セレクタ、CIDR ブロック表記の宛先 IP アドレス範囲のセットに基づいています。下り（外向き）NAT ゲートウェイの仕組みを説明するために、Pod から外部コンシューマーへのパケットフローと対応するレスポンスについて考えてみます。Node のサブネットに 192.168.1.0/24 CIDR ブロックの IP アドレスがあるとします。
次の図は、ゲートウェイ ノードを経由する下り（外向き）トラフィックのネットワーク アーキテクチャを示しています。
下り（外向き）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 に配信されます。
Node トラフィックに対するフローティング IP アドレスの構成
Network Gateway Group のカスタム リソースは、Google Distributed Cloud のバンドル コンポーネントです。このリソースは、クラスタ内の Node からの下り（外向き）トラフィックに使用する 1 つ以上のフローティング IP アドレスのリストを管理します。参加 Node は、指定された Namespace によって決定されます。Network Gateway Group は、フローティング IP アドレスをベスト エフォート方式でいつでも利用できるようにします。フローティング IP アドレスを使用する Node が停止した場合、高度なネットワーク オペレーターが割り当てられた IP アドレスを次に使用可能な Node に移動します。また、この IP アドレスを使用するすべてのワークロードの下り（外向き）トラフィックも移行されます。
1.30.100-gke.96 クラスタを新規作成する際に、クラスタ構成ファイルに 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 カスタム リソースを作成する際は、次の例に示すように、Namespace をクラスタ Namespace に設定し、フローティング 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 に割り当てます。
- Node のサブネット: フローティング IP アドレスは、Node のサブネットと一致する必要があります。
- Node のロール（コントロール プレーン、ワーカー）: フローティング IP アドレスを割り当てると、ワーカー Node がコントロール プレーン Node よりも優先されます。
- Node にフローティング IP アドレスが割り当てられているかどうか: オペレーターは、フローティング IP アドレスがまだ割り当てられていない Node への割り当てを優先します。
アドレス / ノードのマッピングは、NetworkGatewayGroup オブジェクトの取得時に [status] セクションで確認できます。NetworkGatewayGroup オブジェクトは kube-system Namespace にあることに注意してください。ゲートウェイ ノードが停止すると、高度なネットワーク オペレーターは、次に使用可能な Node にフローティング IP アドレスを割り当てます。
ゲートウェイの構成を確認する
ゲートウェイ構成の変更を適用した後は、kubectl を使用してゲートウェイのステータスを確認し、ゲートウェイ用に指定されたフローティング IP アドレスを取得できます。
次のコマンドを使用して、
NetworkGatewayGroupのステータスを確認し、フローティング IP アドレスがどのように割り振られているかを把握します。kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml2 つのノード（
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のラベルが付加された Namespace にある。 - Pod が
8.8.8.0/24CIDR ブロックの 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-systemNamespace にゲートウェイ オブジェクトを作成して、各フローティング 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 ゲートウェイは、ネットワーク ポリシー API と互換性があります。ネットワーク ポリシーが最初に評価され、下り（外向き）NAT ゲートウェイのトラフィック選択ルールよりも優先されます。たとえば、下り（外向き）トラフィックによってネットワーク ポリシーがトリガーされ、パケットがドロップされた場合、下り（外向き）ゲートウェイ ルールはパケットを確認しません。ネットワーク ポリシーでパケットの下り（外向き）が許可されている場合にのみ、下り（外向き）トラフィック選択ルールが評価され、トラフィックの処理方法（下り（外向き）NAT ゲートウェイを使用するか、Pod が実行されている Node の IP アドレスで直接マスカレードするか）が決定されます。
制限事項
下り（外向き）NAT ゲートウェイの現在の制限事項には、次のものがあります。
下り（外向き）NAT ゲートウェイは IPv4 モードでのみ有効になります。
下り（外向き）IP アドレスは、ノード IP アドレスと同じレイヤ 2 ドメイン内に存在する必要があります。
下り（外向き）NAT ゲートウェイのプレビューを使用するように構成されているクラスタでは、アップグレードはサポートされていません。Google Distributed Cloud のリリース 1.30.0 以降では、下り（外向き）NAT ゲートウェイは Ubuntu 18.04 のプレビュー版のみです。プレビュー期間中は、この機能を料金なしで使用できます。