バージョン 1.8このバージョンは現在サポートされていません。詳細については、バージョンのサポートポリシーをご覧ください。バージョン 1.9 にアップグレードする方法については、1.9 ドキュメントのベアメタル版 Anthos のアップグレードをご覧ください。

利用可能なサポートされているバージョン: 1.13 | 1.12 | 1.11

外部通信用の下り（外向き）NAT ゲートウェイを構成する

このドキュメントでは、ベアメタル版 Anthos クラスタに下り（外向き）NAT ゲートウェイを設定する方法について説明します。このゲートウェイは、クラスタからの下り（外向き）トラフィックに対し永続的で確定的なルーティングを行います。下り（外向き）のユーザートラフィック（クラスタの外部）があるワークロードを実行する場合、お客様は、いくつかの確定的な IP アドレスを使用してこのトラフィックを特定する必要があります。これにより、お客様は IP ベースのセキュリティ対策（許可リストポリシーなど）を確立できます。プレビュー期間中、この機能には料金がかかりません。

下り（外向き）NAT ゲートウェイは、2 つのカスタムリソースを使用して有効になります。特定の名前空間に対して、AnthosNetworkGateway カスタムリソースでは、ゲートウェイとして機能するように選択されたノードのネットワークインターフェースに構成できるフローティング IP アドレスを指定します。EgressNatPolicy カスタムリソースでは、下り（外向き）ゲートウェイでトラフィックを制御する下り（外向き）ルーティングポリシーを指定できます。

下り（外向き）NAT ゲートウェイを設定しない場合、または下り（外向き）トラフィックがトラフィック選択ルールに適合しない場合は、特定の Pod からクラスタ外部の宛先への下り（外向き）トラフィックは、Pod が実行されているノードの IP アドレスにマスカレードされます。このシナリオでは、特定の Pod からの下り（外向き）トラフィックがすべて同じ送信元 IP アドレスを持つ、または同じノード IP アドレスにマスカレードされることは保証されません。

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

下り（外向き）トラフィック選択ロジックは、名前空間セレクタ、Pod セレクタ、CIDR ブロック表記の宛先 IP アドレス範囲のセットに基づいています。下り（外向き）NAT ゲートウェイの仕組みを説明するために、Pod から外部コンシューマへのパケットフローと対応するレスポンスについて考えてみます。ノードのサブネットに 192.168.1.0/24 CIDR ブロックの IP アドレスがあるとします。

次の図は、ゲートウェイノードを経由する下り（外向き）トラフィックのネットワークアーキテクチャを示しています。

ベアメタル版 Anthos クラスタの下り（外向き）NAT ゲートウェイの図

下り（外向き）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 アドレスの構成

Anthos Network Gateway コントローラは、ベアメタル版 Anthos クラスタにバンドルされているコンポーネントです。このコントローラは、クラスタにあるノードからの下り（外向き）トラフィックに使用する 1 つ以上のフローティング IP アドレスのリストを管理します。参加ノードは、指定された名前空間によって決定されます。Anthos Network Gateway は、フローティング IP アドレスをベストエフォート方式でいつでも利用できるようにします。フローティング IP アドレスを使用するノードが停止した場合は、Anthos Network Gateway が割り当てられた IP アドレスを次に使用可能なノードに移動します。この IP アドレスを使用するすべてのワークロードの下り（外向き）トラフィックも移行されます。

1.8.0 クラスタを新規作成する際に、クラスタ構成ファイルに Anthos ネットワークゲートウェイの詳細情報（アノテーションと仕様）を格納します。

`AnthosNetworkGateway` カスタムリソースの作成

Anthos Network Gateway は、クラスタを作成する際、クラスタ構成ファイルで baremetal.cluster.gke.io/enable-anthos-network-gateway アノテーションを使用して有効にします。そのアノテーションは、次の例に示すように、true に設定します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
  name: cluster1
  namespace: cluster-cluster1

AnthosNetworkGateway カスタムリソースを作成する際は、次の例に示すように、名前空間をクラスタ名前空間に設定し、フローティング IP アドレスのリストを指定します。

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

指定したフローティング IP アドレスの数は、クラスタの信頼性に影響を与えます。たとえば、下り（外向き） NAT ゲートウェイは、特定のフローティング IP アドレスでのみ動作しますが、ノードに障害が発生するとトラフィックが中断する可能性があります。フローティング IP アドレスを追加すると、AnthosNetworkGateway は、必要に応じてそのアドレスを割り当てて移動させます。フローティング IP アドレスは、クラスタで使用する L2 ドメインごとに少なくとも 2 つの指定することをおすすめします。

コントローラは次の基準に基づいて、フローティング IP をノードに割り当てます。

ノードのサブネット - フローティング IP アドレスは、ノードのサブネットと一致する必要があります。
ノードのロール（マスター、ワーカー） - フローティング IP アドレスを割り当てる際は、ワーカーノードがマスターノードよりも優先されます。
ノードにフローティング IP アドレスが割り当てられているかどうか - コントローラは、フローティング IP アドレスがまだ割り当てられていないノードへの割り当てを優先します。

アドレス / ノードのマッピングは、AnthosNetworkGateway オブジェクトの取得時に status セクションで確認できます。なお、AnthosNetworkGateway オブジェクトは kube-system Namespace にあります。ゲートウェイノードが停止すると、AnthosNetworkGateway のコントローラは、次に使用可能なノードにフローティング IP アドレスを割り当てます。

ゲートウェイの構成の確認

ゲートウェイ構成の変更を適用した後は、kubectl を使用してゲートウェイのステータスを確認し、ゲートウェイ用に指定されたフローティング IP アドレスを取得できます。

次のコマンドを使用して、AnthosNetworkGateway のステータスを確認し、フローティング IP アドレスがどのように割り振られているかを確認します。

kubectl -n kube-system get anthosnetworkgateway.networking.gke.io default -oyaml

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

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
status:
  nodes:
    worker1: Up
    worker2: Up // Or Down
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

特定のノードの AnthosNetworkGateway ステータスとアドレスの割り振りを取得するには、次のコマンドを使用します。
```
kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyaml
```
NODE_NAME を、検査する特定のノードまたはマシンの名前に置き換えます。

トラフィック選択ルールの設定

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/24 範囲内の IP アドレスと通信している。

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: egress
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

ラベルの使用の詳細については、Kubernetes ドキュメントのラベルとセレクタをご覧ください。

下り（外向き）トラフィックの送信元 IP アドレスの指定

使用する送信元 IP アドレスは、egressSourceIP フィールドに指定します。そのアドレスは、AnthosNetworkGateway カスタムリソースで指定されたフローティング IP アドレスのいずれかと一致する必要があります。

前のセクションの EgressNATPolicy の例では、Pod の選択と宛先 IP アドレスの基準が満たされている場合に、Pod からの下り（外向き）トラフィックが SNAT を使用して 192.168.1.100 に変換されます。

ルートが受け入れられるには、egressSourceIP アドレスがゲートウェイのノード IP と同じサブネット内に存在する必要があります。ゲートウェイノードに対して egressSourceIP アドレスが不明（未割り当て）の場合は、ルートリクエストを処理できません。この場合は、Kubernetes イベントで UnknownEgressIP エラーが発生します。

次の kubectl コマンドを使用して、EgressNATPolicy オブジェクトのイベントを出力します。

kubectl describe EgressNATPolicy egress

複数の EgressNATPolicy CR が存在する場合は、それぞれに異なる egressSourceIP アドレスが必要です。競合を回避するには、開発チームと調整してください。

下り（外向き）トラフィックの選択ルールとネットワークポリシー

下り（外向き）NAT ゲートウェイは、ネットワークポリシー API と互換性があります。ネットワークポリシーが最初に評価され、下り（外向き）NAT ゲートウェイのトラフィック選択ルールよりも優先されます。たとえば、下り（外向き）トラフィックによってネットワークポリシーがトリガーされ、パケットがドロップされた場合、下り（外向き）ゲートウェイルールはパケットを確認しません。ネットワークポリシーでパケットの下り（外向き）が許可されている場合にのみ、下り（外向き）トラフィック選択ルールが評価され、下り（外向き）NAT ゲートウェイを使用するか、Pod が実行されているノードの IP アドレスで直接マスカレードして、トラフィックの処理方法が決定されます。

制限事項

下り（外向き）NAT ゲートウェイの現在の制限事項には、次のものがあります。

下り（外向き）NAT ゲートウェイは IPv4 モードでのみ有効になります。
このプレビューでは、下り（外向き）IP アドレスは、ノード IP アドレスと同じ L2 ドメイン内にあることが必要です。
下り（外向き）NAT ゲートウェイのプレビューを使用するように構成されているクラスタでは、アップグレードはサポートされていません。