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

Google Distributed Cloud では、ユーザー クラスタからの特定の下り（外向き）トラフィックに予測可能な送信元 IP アドレスが割り当てられるように、ソース ネットワーク アドレス変換（SNAT）を構成できます。

このドキュメントでは、ユーザー クラスタの下り（外向き）NAT ゲートウェイを構成する方法について説明します。

注意: Anthos Network Gateway が有効になっているバージョン 1.8.x と 1.9.x のどのクラスタもそれ以降のバージョンにアップグレードすることはできません。たとえば、Anthos Network Gateway が有効になっているバージョン 1.9.0 のクラスタは、バージョン 1.9.x にアップグレードすることも、バージョン 1.10 にアップグレードすることもできません。Anthos Network Gateway が有効になっているクラスタでアップグレードできるのは、バージョン 1.10 以降で作成されたクラスタのみです。バージョン 1.8.x やバージョン 1.9.x のクラスタは、削除した後、このドキュメントの手順に沿って再作成できます。

はじめに

ユーザー クラスタで実行されている Pod が、クラスタ外部にある組織で実行中のコンポーネントにパケットを送信する必要がある場合があります。このような外部コンポーネントは、既知の送信元 IP アドレスのセットに従って受信ネットワーク トラフィックをフィルタリングするように設計できます。

次のようなシナリオが考えられます。

• データベースの前に、IP アドレスのみでアクセスを許可するファイアウォールがあります。また、データベース ファイアウォールを管理するチームは、ユーザー クラスタを管理するチームとは異なります。

• ユーザー クラスタ内のワークロードは、インターネット経由でサードパーティ API にアクセスする必要があります。セキュリティ上の理由から、API プロバイダは IP アドレスを ID として使用してトラフィックを認証および承認します。

下り（外向き）NAT ゲートウェイを使用すると、クラスタを離れるネットワーク トラフィックに使用される送信元 IP アドレスをきめ細かく制御できます。

料金

プレビュー期間中は、この機能の使用に料金はかかりません。

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

通常、Pod がクラスタからパケットを送信すると、パケットは Pod が実行されているノードの IP アドレスで SNAT 変換されます。

下り（外向き）NAT ゲートウェイを使用する場合は、特定のアウトバウンド パケットを最初に専用のゲートウェイ ノードに送信するように指定できます。ゲートウェイ ノードのネットワーク インターフェースには、プライマリ IP アドレスと下り（外向き）送信元 IP アドレスの 2 つの IP アドレスが構成されています。

下り（外向き）NAT ゲートウェイを使用するように選択されるパケットは、ゲートウェイ ノードからクラスタを離れ、ネットワーク インターフェースで構成された下り（外向き）の送信元 IP アドレスで SNAT 変換されます。

次の図は、パケットフローを示しています。

上の図は、Pod から送信されたパケットのフローを示しています。

1. IP アドレス 192.168.1.1 のノード上で、IP アドレス 10.10.10.1 の Pod がアウトバウンド パケットを生成します。

2. パケットは下り（外向き）ルールと一致するため、パケットはゲートウェイ ノードに転送されます。

3. ゲートウェイ ノードが送信元 IP アドレスを 192.168.1.100 に変更し、クラスタからパケットを送信します。

4. 戻りトラフィックは、宛先が 192.168.1.100 であるゲートウェイ ノードに戻ります。

5. ゲートウェイ ノードは、conntrack を使用して、宛先 IP アドレスを 10.10.10.1 に変更します。

6. パケットはクラスタ内トラフィックとして処理され、元のノードに転送され、元の Pod に返送されます。

ペルソナ

このトピックでは、次の 2 つのペルソナについて説明します。

• クラスタ管理者。このユーザーは、ユーザー クラスタを作成し、Anthos Network Gateway で使用するフローティング IP アドレスを指定します。

• デベロッパー。このユーザーは、ユーザー クラスタでワークロードを実行し、下り（外向き）ポリシーを作成します。

下り（外向き）NAT ゲートウェイを有効にする

このセクションは、クラスタ管理者を対象としています。

下り（外向き）NAT ゲートウェイを構成するには、ユーザー クラスタ構成ファイルの enableDataplaneV2 フィールドと advancedNetworking フィールドを使用して、1 つ以上の NetworkGatewayGroup オブジェクトを作成します。

クラスタ構成ファイルで、次のフィールドを true に設定します。

enableDataplaneV2: true
...
advancedNetworking: true

ユーザー クラスタを作成します。

フローティング IP アドレスを指定する

このセクションは、クラスタ管理者を対象としています。

下り（外向き）送信元アドレスとして使用する IP アドレスのセットを選択します。これらはフローティング IP アドレスと呼ばれ、必要に応じて Network Gateway Group によって、下り（外向き）ゲートウェイとして選択されたノードのネットワーク インターフェースに割り当てられます。

フローティング IP アドレスは、ノード IP アドレスと同じサブネット内に存在する必要があります。

フローティング IP アドレスのセットが、ノードに指定した IP アドレスのセットと重複しないようにする必要があります。

たとえば、サブネットのアドレス範囲が 192.168.1.0/24 であるとします。また、ノードに 192.168.1.1～192.168.1.99 を選択したとします。この場合、192.168.1.100 から 192.168.1.104 までをフローティング IP アドレスとして使用できます。

NetworkGatewayGroup オブジェクトを作成する

このセクションは、クラスタ管理者を対象としています。

NetworkGatewayGroup オブジェクトのマニフェストの例を次に示します。

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
  - 192.168.1.103
  - 192.168.1.104

floatingIPs 配列をフローティング IP アドレスに置き換え、マニフェストを my-ngg.yaml という名前のファイルに保存します。

NetworkGatewayGroup オブジェクトを作成します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ngg.yaml

下り（外向き）NAT ポリシーの例

このセクションはデベロッパーを対象としています。

EgressNatPolicy ポリシーのカスタム リソースの例を以下に示します。

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: alice-paul
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

前述のマニフェストで次のことを確認できます。

• 次の条件を満たす場合、Pod は下り（外向き）NAT の候補です。

  • Pod に role: frontend というラベルがあり、Pod は user: alice というラベルの Namespace にあります。

  • Pod に role: frontend というラベルがあり、Pod は user: paul というラベルの Namespace にあります。

• 候補 Pod から 8.8.8.0/24 の範囲のアドレスへのトラフィックが下り（外向き）NAT ゲートウェイに送信されます。

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

EgressNATPolicy オブジェクトを作成する

独自の EgressNATPolicy マニフェストを作成します。metadata.name を "my-policy" に設定します。マニフェストを my-policy.yaml という名前のファイルに保存します。

EgressNatPolicy オブジェクトを作成します。

kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml

下り（外向き）NAT ポリシーに関する情報を表示する

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --namespace kube-system --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy

オペレーションの順序

下り（外向き）NAT ポリシーにはネットワーク ポリシー API との互換性があります。ネットワーク ポリシーは、下り（外向き）NAT ポリシーよりも先に評価されます。ネットワーク ポリシーによってパケットが破棄された場合、下り（外向き）NAT ポリシーに関係なく、パケットは破棄されます。

複数の下り（外向き）ポリシー

前述のように、各 EgressNATPolicy は gatewayRef.name と gatewayRef.namespace に一致する NetworkGatewayGroup の floatingIPs リストの最初の IP アドレスを使用します。複数のポリシーを作成し、それぞれ異なる IP アドレスを使用する場合は、複数の NetworkGatewayGroup オブジェクトを作成して、それぞれを参照する必要があります。複数のポリシーを作成する場合、gatewayRef オブジェクトは、ポリシーごとに一意である必要があります。

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

注: Anthos ネットワーク ゲートウェイでは、既存のゲートウェイ オブジェクトですでに使用されている spec.floatingIPs に IP アドレスを含む新しいゲートウェイ オブジェクトを作成できません。このルールは、Google Distributed Cloud バージョン 1.15.0 以降の Webhook によって適用されます。

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

1. 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
   

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

   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy1
   spec:
     ...
     gatewayRef:
       name: gateway1
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy2
   spec:
     ...
     gatewayRef:
       name: gateway2
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy3
   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）品質が低下する可能性があります。