外部エンドポイントへの GKE Pod の接続を構成する

このドキュメントでは、GKE の Pod から外部エンドポイント（オンプレミス ネットワークのリソースや公共のインターネット サービスなど）への接続を構成する方法について説明します。GKE Pod トラフィックの送信元 IP アドレスを制御するには、ip-masq-agent（ノードレベルの変換）と Cloud NAT（VPC レベルの下り）の両方を使用できます。

概要

VPC ネイティブ GKE クラスタの Pod がクラスタ外の宛先にパケットを送信すると、ノードレベルの IP マスカレード エージェント（ip-masq-agent）と Cloud NAT の構成方法に応じて、パケットの送信元 IP アドレスが変更されます。

  1. ノードレベルの変換（ip-masq-agent）: 構成された nonMasqueradeCIDRs リストに基づいて、パケットの送信元 IP アドレスを Pod IP アドレス（セカンダリ サブネット範囲）から内部 ノード IP アドレス（プライマリ サブネット範囲）に変換します。
  2. VPC レベルのゲートウェイ（Cloud NAT）: 内部 VPC IP アドレス（ノード IP アドレスまたは Pod IP アドレス）を静的パブリック IP アドレスに変換して、アウトバウンドのインターネット アクセスを許可します。

宛先がノードによってマスカレードされるかどうかに応じて、パケットはノードの IP アドレスまたは Pod の IP アドレスのいずれかでノードから送信されます。この送信元 IP アドレスによって、Cloud Router またはオンプレミス ルーターの構成方法が決まります。

IP マスカレードと Cloud NAT の連携の仕組み

インターネットに接続するトラフィックの場合、Pod からのパケットはノード ネットワーク スタックと Cloud NAT ゲートウェイの両方を通過します。

宛先 IP アドレスが nonMasqueradeCIDRs リストのどの範囲とも一致しない場合:

  • ip-masq-agent は、GKE ノードで送信元 NAT（SNAT）を実行します。送信元 IP アドレスは、Pod IP アドレスからノード IP アドレスに書き換えられます。
  • パケットは、送信元としてノード IP アドレスを使用して VPC ネットワークに入ります。
  • Cloud NAT ゲートウェイがパケットをインターセプトします。
  • Cloud NAT は、ノード IP アドレスをパブリック IP アドレスに変換して、インターネットに転送します。

シナリオ B: Pod IP アドレスを保持する（マスカレードなし）

宛先 IP アドレスが nonMasqueradeCIDRs リストの範囲と一致する場合（またはデフォルトの SNAT が無効になっている場合）:

  • ip-masq-agent はパケットを変更しません。送信元 IP アドレスは Pod IP アドレスのままです。
  • パケットは、Pod IP アドレスを送信元として VPC ネットワークに入ります。
  • Cloud NAT ゲートウェイがパケットをインターセプトします。
  • Cloud NAT は、GKE Pod に使用されるサブネットのセカンダリ IP アドレス範囲を変換するように Cloud NAT が明示的に構成されている場合にのみ、Pod IP アドレスをパブリック IP アドレスに変換します。

IP マスカレード チェッカー

このチェッカーを使用して、ip-masq-agent 構成に基づいて宛先 IP アドレスがマスカレードされるかどうかを確認します。

トラフィック フローの例

変換パスを理解するために、次の構成例について考えてみましょう。

  • Pod IP アドレス範囲: 10.4.0.0/14（Pod IP アドレス: 10.4.0.5）
  • ノード IP アドレス範囲: 10.128.0.0/20（ノード IP アドレス: 10.128.0.10）
  • 宛先 IP アドレス: 8.8.8.8（パブリック DNS サーバー、nonMasqueradeCIDRs リストにない）

Pod がパケットを送信すると、次の処理が行われます。

  1. パケットが Pod から開始: パケットは、宛先 IP アドレスが 8.8.8.8 の Pod のネットワーク インターフェース（IP アドレス: 10.4.0.5）から発信されます。
  2. ノードレベルのマスカレード: 8.8.8.8 宛先 IP アドレスが nonMasqueradeCIDRs リストにないため、ホストノードの ip-masq-agent はパケットが送信されるときにパケットをインターセプトし、SNAT を実行します。送信元 IP アドレスは、10.4.0.5 Pod IP アドレスからホストノード IP アドレス（10.128.0.10）に書き換えられます。
  3. VPC 下り（外向き）: パケットは、送信元 IP アドレスとして 10.128.0.10 ホストノード IP アドレスを使用して VPC ネットワークに到達します。
  4. Cloud NAT ゲートウェイ: 宛先がパブリック インターネットであるため、Cloud NAT はパケットを処理し、送信元 IP アドレスを 10.128.0.10 からパブリック NAT IP アドレス（203.0.113.1 など）に変換して、インターネットに転送します。
  5. レスポンス処理: レスポンスはパブリック Cloud NAT IP アドレスに戻り、Cloud NAT は 10.128.0.10 ホストノード IP アドレスに逆変換します。次に、ノードはホストノードの IP アドレスを Pod の IP アドレス（10.4.0.5）に逆変換し、Pod コンテナに配信します。

Cloud Cloud Service Mesh（CSM）によるトラフィック フロー

ワークロードで Cloud Service Mesh を使用している場合、トラフィック ルーティングは次のように動作します。

  • サイドカー プロキシまたはサイドカーレス CNI リダイレクト: アプリケーション コンテナからのアウトバウンド パケットは、ノードのネットワーク Namespace に到達する前に、メッシュによってインターセプトされます（Envoy などのサイドカー プロキシを使用するか、ebpf ベースまたは CNI リダイレクトを使用します）。
  • ポリシーの適用: メッシュは、認可ポリシーと下り（外向き）ポリシーに基づいて接続が許可されているかどうかを判断します。
  • 下り（外向き）ルーティング:
    • Cloud Service Mesh 下り（外向き）ゲートウェイを使用してトラフィックが転送される場合、ノードから送信されるパケットの送信元 IP アドレスは、元の Pod ではなく、下り（外向き）ゲートウェイのノードまたは Pod の IP アドレスに対応します。
    • トラフィックが外部エンドポイントに直接ルーティングされる場合、パケットはプロキシを終了し、標準のホストノード ネットワーク スタックを介してルーティングされます。この場合、このドキュメントで前述した ip-masq-agent ポリシーと Cloud NAT 構成は、下り（外向き）トラフィックに引き続き適用されます。
  • Cloud Service Mesh でのルーティング、ゲートウェイの構成、外部トラフィックの管理の詳細については、Cloud Service Mesh のドキュメントをご覧ください。

接続に関する問題のトラブルシューティングと切り分け

Pod が外部エンドポイントに接続できず、サービス メッシュを使用している場合は、問題がサービス メッシュ構成にあるのか、基盤となる GKE ルーティングにあるのかを特定する必要があります。問題を特定するには、次の方法を使用します。

  1. サービス メッシュをバイパスする: サイドカー インジェクションが無効になっている Namespace に一時的なクライアント Pod をデプロイするか、Pod 仕様で sidecar.istio.io/inject: "false" アノテーションを使用してテスト ワークロードのインジェクションを防ぎます。
  2. 接続をテストする: メッシュ以外の Pod から外部宛先への接続を試みます（curl、ping、nc などを使用）。
  3. 結果を分析する:
    • 接続が成功した場合: 基盤となる GKE ネットワーク ルーティング、ip-masq-agent ルール、Cloud NAT ゲートウェイが正しく構成されています。接続ブロックは、Cloud Service Mesh ポリシー、下り（外向き）ルールの欠落、mTLS ルールが原因で発生します。トラブルシューティングの詳細については、Cloud Service Mesh ドキュメントの Envoy を使用するデプロイのトラブルシューティングをご覧ください。
    • 接続に失敗した場合: 問題は基盤となるネットワーク インフラストラクチャ（IP マスカレード、Cloud Router、Cloud NAT、VPC ファイアウォール ルール、オンプレミス ファイアウォールなど）にあります。このページの手順に沿って、ルーティング構成を確認します。

チェッカーを使用して送信元 IP アドレス範囲を特定する

ルーターまたはファイアウォールを構成する前に、このドキュメントの IP マスカレード チェッカーを使用して、次の操作を行います。

  1. ip-masq-agent ConfigMap の YAML コンテンツを構成フィールドに貼り付けます。
  2. ターゲット エンドポイント（オンプレミス データベースや外部インターネット サービスなど）の宛先 IP アドレスを入力します。
  3. [Check Masquerading] をクリックします。
  4. 次の出力に注意してください。
    • マスカレード: パケットは、送信元としてノードの IP アドレス範囲を使用します。
    • マスカレードなし: パケットは送信元として Pod IP アドレス範囲を使用します。

エンドポイントへの接続を構成する

IP マスカレード チェッカーの結果に基づいて、宛先のタイプに応じてネットワーキング パスとゲートウェイを構成します。

オンプレミス エンドポイント（VPN または相互接続）

Cloud NAT はオンプレミス接続には使用されませんが、IP マスカレード チェッカーで特定した送信元 IP アドレス範囲に基づいてルーターとファイアウォールを構成する必要があります。

トラフィックがマスカレードされている場合（送信元がノード IP アドレスの場合）:

  1. Cloud Router: Cloud Router のアドバタイズに GKE クラスタ サブネットのプライマリ IP アドレス範囲が含まれていることを確認します。
  2. オンプレミス ルーターまたはファイアウォール: GKE ノード IP アドレス範囲からの受信トラフィックを許可して処理するように、オンプレミス ルーターとファイアウォールを構成します。

トラフィックがマスカレードされていない場合（送信元が Pod の IP アドレスの場合）:

  1. Cloud Router: Cloud Router でカスタム ルート アドバタイズを構成して、GKE Pod のセカンダリ IP アドレス範囲をオンプレミス ネットワークにアドバタイズします。
  2. オンプレミス ルーターまたはファイアウォール: GKE Pod IP アドレス範囲から発信されたトラフィックを許可するようにオンプレミス ルーティング テーブルとファイアウォールを構成し、戻りルートが VPC にアドバタイズされるようにします。

インターネット エンドポイント（Cloud NAT）

公共のインターネット エンドポイントにトラフィックをルーティングする場合は、VPC 内に Cloud NAT ゲートウェイを構成する必要があります。

  1. Cloud de Confiance コンソールで、[Cloud NAT] ページに移動します。
  2. Cloud NAT ゲートウェイを選択または作成します。
  3. [Cloud NAT ソース] で、ゲートウェイが GKE サブネット範囲を処理する方法を選択します。
    • トラフィックがマスカレードされている場合（送信元がノード IP アドレスの場合）: サブネットのプライマリ IP アドレス範囲を選択します。通常、商用 GKE デプロイはデフォルトでこの設定になります。
    • トラフィックがマスカレードされていない場合（送信元が Pod の IP アドレスの場合）: [プライマリ IP アドレス範囲とセカンダリ IP アドレス範囲] を選択する必要があります（または、GKE Pod のセカンダリ範囲を明示的に指定します）。プライマリ範囲のみを選択すると、GKE Pod のインターネット トラフィックがブロックされます。