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

Version 1.9 

• Version 1.28 (latest)
• Version 1.16
• Version 1.15
• Earlier versions (unsupported)

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

Anthos clusters on VMware（GKE On-Prem）では、ユーザー クラスタからの特定の下り（外向き）トラフィックに予測可能な送信元 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 アドレスを指定します。

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

Anthos ネットワーク ゲートウェイを有効にする

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

Anthos ネットワーク ゲートウェイを有効にして新しいユーザー クラスタを作成します。

ユーザー クラスタの構成ファイルで、enableDataplaneV2 と enableAnthosNetworkGateway を true に設定します。

enableDataplaneV2: true
...
enableAnthosNetworkGateway: true

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

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

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

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

フローティング 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 アドレスとして使用できます。

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

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

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

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
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-ang.yaml という名前のファイルに保存します。

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

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

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

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

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

kind: EgressNATPolicy
metadata:
  name: alice-paul
spec:
  egress:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  destinationCIDRs:
  - 8.8.8.0/24
  egressSourceIP: 192.168.1.100

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

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

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

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

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

注: EgressNATPolicy オブジェクトで指定する egressSourceIP は、AnthosNetworkGateway オブジェクトに一覧表示され、ノードに割り当てられている必要があります。そうでない場合、EgressNATPolicy オブジェクトの Kubernetes イベントで UnknownEgressIP エラーが発生します。

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 anthosnetworkgateway --namespace kube-system --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy

オペレーションの順序

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

既知の問題

egressSourceIP アドレスの重複

EgressNATGateway オブジェクトを作成する際に、別の EgressNATPolicy オブジェクトですでに使用されている egressSourceIP アドレスを指定できます。これにより、下り（外向き）トラフィック ルーティングの競合が発生する可能性があります。開発チームと連携して、egressSourceIP アドレスを指定する前に使用可能なフローティング IP アドレスを特定します。

カスタム リソースを変更する

EgresNATPolicy カスタム リソースへの変更は、Cilium カスタム リソースには入力されません。