このドキュメントでは、GDCV for Bare Metal の下り（外向き）NAT ゲートウェイを設定する方法について説明します。このゲートウェイは、クラスタからの下り（外向き）トラフィックに永続的で確定的な SNAT IP アドレスを提供します。クラスタのユーザー外部で下り（外向き）のユーザー トラフィックがあるワークロードを実行する場合、お客様は、いくつかの確定的な IP アドレスを使用してこのトラフィックを特定する必要があります。これにより、お客様は許可リスト ポリシーなどの IP ベースのセキュリティ対策を確立できます。
下り（外向き）NAT ゲートウェイは、2 つのカスタム リソースを使用して有効になります。特定の名前空間に対して、NetworkGatewayGroup カスタム リソースでは、ゲートウェイとして機能するように選択されたノードのネットワーク インターフェースに構成できるフローティング IP アドレスを指定します。EgressNatPolicy カスタム リソースでは、下り（外向き）ゲートウェイでトラフィックを制御する下り（外向き）ルーティング ポリシーを指定できます。
下り（外向き）NAT ゲートウェイを設定しない場合、または下り（外向き）トラフィックがトラフィック選択ルールに適合しない場合は、特定の Pod からクラスタ外部の宛先への下り（外向き）トラフィックは、Pod が実行されているノードの IP アドレスにマスカレードされます。このシナリオでは、特定の Pod からの下り（外向き）トラフィックがすべて同じ送信元 IP アドレスを持つ、または同じノード IP アドレスにマスカレードされることは保証されません。
下り（外向き）NAT ゲートウェイは、Dataplane V2 上に構築された高度なネットワーキング サービスです。
下り（外向き）NAT ゲートウェイの仕組み
下り（外向き）トラフィック選択ロジックは、名前空間セレクタ、Pod セレクタ、CIDR ブロック表記の宛先 IP アドレス範囲のセットに基づいています。下り（外向き）NAT ゲートウェイの仕組みを説明するために、Pod から外部コンシューマへのパケットフローと対応するレスポンスについて考えてみます。ノードのサブネットに 192.168.1.0/24 CIDR ブロックの IP アドレスがあるとします。
次の図は、ゲートウェイ ノードを経由する下り（外向き）トラフィックのネットワーク アーキテクチャを示しています。
下り（外向き）NAT ゲートウェイを通過するパケットフローは次のようになります。
下り（外向き）トラフィックは、IP アドレス
192.168.1.1のノードに存在する IP アドレス10.10.10.1の Pod から生成されます。トラフィックの宛先アドレスは、クラスタの外部に存在するエンドポイントです。
トラフィックが下り（外向き）ルールに一致する場合、eBPF プログラムは、ノードの IP アドレスにマスカレードする代わりに、下り（外向き）トラフィックをゲートウェイ ノードにルーティングします。
ゲートウェイ ノードは下り（外向き）トラフィックを受信します。
ゲートウェイ ノードは、
EgressNATPolicyカスタム リソースで指定された送信元の下り（外向き）IP アドレス192.168.1.100を使用して、送信元トラフィックの送信元 IP アドレス10.10.10.1をマスカレードします。戻りトラフィックは、宛先が
192.168.1.100であるゲートウェイ ノードに戻ります。ゲートウェイ ノードは、戻りトラフィックの conntrack と元の下り（外向き）トラフィックの conntrack を照合し、宛先 IP アドレスを
10.10.10.1として書き換えます。10.10.10.1はクラスタ内のトラフィックとして扱われ、元のノードにルーティングされ、元の Pod に配信されます。
ノード トラフィックに対するフローティング IP アドレスの構成
Network Gateway Group のカスタム リソースは、GKE on Bare Metal のバンドル コンポーネントです。このリソースは、クラスタ内のノードからの下り（外向き）トラフィックに使用する 1 つ以上のフローティング IP アドレスのリストを管理します。参加ノードは、指定された名前空間によって決定されます。Network Gateway Group は、フローティング IP アドレスをベスト エフォート方式でいつでも利用できるようにします。フローティング IP アドレスを使用するノードが停止した場合、高度なネットワーク オペレータが割り当てられた IP アドレスを次に使用可能なノードに移動します。この IP アドレスを使用するすべてのワークロードの下り（外向き）トラフィックも移行されます。
新しい 1.15.11 クラスタを作成するときに、クラスタ構成ファイルに Network Gateway Group の詳細情報（アノテーションと仕様）を含めます。
NetworkGatewayGroup カスタム リソースを作成する
次の例に示すように、クラスタを作成するときにクラスタ構成ファイルの spec.clusterNetwork.advancedNetworking フィールドを true に設定し、ネットワーク ゲートウェイ グループを有効にします。
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 をノードに割り当てます。
- ノードのサブネット: フローティング IP アドレスは、ノードのサブネットと一致する必要があります。
- ノードのロール（コントロール プレーン、ワーカー）: フローティング IP アドレスを割り当てると、ワーカーノードがコントロール プレーン ノードよりも優先されます。
- ノードにフローティング IP アドレスが割り当てられているかどうか: オペレータは、フローティング IP アドレスがまだ割り当てられていないノードへの割り当てを優先します。
アドレス / ノードのマッピングは、NetworkGatewayGroup オブジェクトの取得時に status セクションで確認できます。NetworkGatewayGroup オブジェクトは kube-system 名前空間にあることに注意してください。ゲートウェイ ノードが停止すると、高度なネットワーク オペレータは、次に使用可能なノードにフローティング 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 アドレスを割り当てます。CR を指定する際は、egress（少なくとも 1 つのルールを含む）、destinationCIDRs、egressSourceIP がすべて必要です。
kubectl apply を使用して EgressNATPolicy カスタム リソースを作成します。以下のセクションでは、仕様を定義するための詳細と例について説明します。
下り（外向き）ルーティング ルールを指定する
EgressNatPolicy カスタム リソースを使用すると、下り（外向き）トラフィックに対して次のルールを指定できます。
egressセクションには、1 つ以上の下り（外向き）トラフィック選択ルールを指定する必要があります。- 各ルールは、
podSelectorとnamespaceSelectorで構成されます。 - 選択は、名前空間ラベル
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/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-system名前空間にゲートウェイ オブジェクトを作成して、各フローティング 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
下り（外向き）トラフィックの選択ルールとネットワーク ポリシー
下り（外向き）NAT ゲートウェイは、ネットワーク ポリシー API と互換性があります。ネットワーク ポリシーが最初に評価され、下り（外向き）NAT ゲートウェイのトラフィック選択ルールよりも優先されます。たとえば、下り（外向き）トラフィックによってネットワーク ポリシーがトリガーされ、パケットがドロップされた場合、下り（外向き）ゲートウェイ ルールはパケットを確認しません。ネットワーク ポリシーでパケットの下り（外向き）が許可されている場合にのみ、下り（外向き）トラフィック選択ルールが評価され、下り（外向き）NAT ゲートウェイを使用するか、Pod が実行されているノードの IP アドレスで直接マスカレードして、トラフィックの処理方法が決定されます。
制限事項
下り（外向き）NAT ゲートウェイの現在の制限事項には、次のものがあります。
下り（外向き）NAT ゲートウェイは IPv4 モードでのみ有効になります。
下り（外向き）IP アドレスは、ノード IP アドレスと同じレイヤ 2 ドメイン内に存在する必要があります。
下り（外向き）NAT ゲートウェイのプレビューを使用するように構成されているクラスタでは、アップグレードはサポートされていません。GKE on Bare Metal のリリース 1.15.0 以降、下り（外向き）NAT ゲートウェイは Ubuntu 18.04 のプレビューのみです。プレビュー期間中は、この機能を料金なしで使用できます。