下り(外向き)NAT ゲートウェイの構成

10

Anthos clusters on VMware(GKE On-Prem)では、ユーザー クラスタからの特定の下り(外向き)トラフィックに予測可能な送信元 IP アドレスが割り当てられるように、ソース ネットワーク アドレス変換(SNAT)を構成できます。

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

はじめに

ユーザー クラスタで実行されている 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 というラベルの名前空間にあります。

    • Pod に role: frontend というラベルが付けられ、Pod が user: paul というラベルの名前空間にあります。

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

  • gatewayRef セクションは、下り(外向き)送信元 IP アドレスを決定します。EgressNATPolicy カスタム リソースは、gatewayRef.namegatewayRef.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.namegatewayRef.namespace に一致する NetworkGatewayGroup の floatingIPs リストの最初の IP アドレスを使用します。複数のポリシーを作成し、それぞれ異なる IP アドレスを使用する場合は、複数の NetworkGatewayGroup オブジェクトを作成して、それぞれを参照する必要があります。複数のポリシーを作成する場合、gatewayRef オブジェクトは、ポリシーごとに一意である必要があります。

このリリースの VMware 上の Anthos クラスタに関する制限は、kube-system 名前空間に default の名前を持つ NetworkGatewayGroup のみがフローティング IP 割り当てに対して調整されることです。また、デフォルトの NetworkGatewayGroup のみが、すべてのフローティング IP アドレスの割り当てステータスを報告します。

そのため、複数の NetworkGatewayGroup オブジェクトを作成する場合は、デフォルト以外のオブジェクトの IP アドレスがデフォルトの NetworkGatewayGroup マニフェストでも指定されるようにする必要があります。そうしないと、フローティング IP として割り当てられることはないため、EgressNATPolicies オブジェクトでは使用できません。

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

  1. デフォルトの NetworkGatewayGroup オブジェクト(name: default)を kubectl で検証して、フローティング IP アドレスの割り当てステータスを取得します。

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --name default --output yaml
    

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

    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:
      ...
      floatingIPs:
        192.168.1.100: worker1
        192.168.1.101: worker2
        192.168.1.102: worker1
    
  2. デフォルトの NetworkGatewayGroup のステータスを確認したら、各フローティング IP を「追跡」するために kube-system 名前空間に追加の NetworkGatewayGroup オブジェクトを作成します。

    これらの新しいオブジェクトは、default NetworkGatewayGroup にある割り当てステータスを報告しません。

    kind: NetworkGatewayGroup
    apiVersion: networking.gke.io/v1
    metadata:
      namespace: kube-system
      name: gateway1
    spec:
      floatingIPs:
      — 192.168.1.100
    ---
    kind: NetworkGatewayGroup
    apiVersion: networking.gke.io/v1
    metadata:
      namespace: kube-system
      name: gateway2
    spec:
      floatingIPs:
      — 192.168.1.101
    ---
    kind: NetworkGatewayGroup
    apiVersion: networking.gke.io/v1
    metadata:
      namespace: kube-system
      name: gateway3
    spec:
      floatingIPs:
      — 192.168.1.102
    
  3. 前のステップで作成した gateway1 など、「セカンダリ」NetworkGatewayGroup オブジェクトを参照する複数のポリシーを作成します。

    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