VPC フローログの概要

VPC フローログの概要には、VM インスタンスによって送受信されたネットワーク フローのサンプルが記録されます。これには Google Kubernetes Engine ノードとして使用されるインスタンスも含まれます。これらのログは、ネットワーク モニタリング、フォレンジック、リアルタイム セキュリティ分析、およびコストの最適化に使用できます。

フローログは Cloud Logging で表示でき、Cloud Logging のエクスポート先としてサポートされている任意の宛先にエクスポートできます。

フローログは、Compute Engine VM からの接続ごとに集計され、リアルタイムでエクスポートされます。Pub/Sub に登録すると、リアルタイム ストリーミングの API を使用してフローログを分析できます。

基本特性

  • VPC フローログは、VPC ネットワークを強化するソフトウェアである Andromeda の一部です。VPC フローログが有効になると、遅延やパフォーマンスの低下は発生しません。
  • VPC フローログは、レガシー ネットワークではなく、VPC ネットワークで機能します。サブネットごとに VPC フローログを有効または無効にできます。サブネットに対して有効になっている場合、VPC フローログはそのサブネット内のすべての VM インスタンスからデータを収集します。
  • VPC フローログは、各 VM のインバウンドとアウトバウンドの TCP フローと UDP フローをサンプリングします。これらのフローは、VM と別の VM の間、オンプレミス データセンターのホスト、Google サービス、またはインターネット上のホストで行うことができます。フローがサンプリングによってキャプチャされると、VPC フローログがフロー用のログを生成します。各フローレコードには、レコードの形式セクションで説明されている情報が含まれます。
  • VPC フローログは、次の方法でファイアウォール ルールとやり取りします。
    • 下り(外向き)のパケットは、下り(外向き) ファイアウォール ルールの前にサンプリングされます。下り(外向き)ファイアウォール ルールによって送信パケットが拒否されていても、これらのパケットは VPC フローログでサンプリングできます。
    • 上り(内向き)パケットは、上り(内向き)ファイアウォールルールの後にサンプリングされます。上り(内向き)ファイアウォール ルールによって受信パケットが拒否された場合、それらのパケットは VPC フローログでサンプリングされません。
  • VPC フローログのフィルタを使用して、特定のログのみを生成できます。
  • VPC フローログは、複数のネットワーク インターフェースを持つ VM をサポートします。ネットワーク インターフェースを含む各 VPC のサブネットごとに VPC フローログを有効にする必要があります。
  • 同じ Google Kubernetes Engine(GKE)ノード上の Pod 間のフローをログに記録するには、クラスタのノード内の可視化を有効にする必要があります。

ユースケース

ネットワーク モニタリング

VPC フローログを使用すると、ネットワークのスループットとパフォーマンスをリアルタイムで把握できます。以下を実現できます。

  • VPC ネットワークをモニタリングする
  • ネットワーク診断を実行する
  • VM とアプリケーションによりフローログをフィルタ処理して、トラフィックの変化を理解する
  • トラフィックの増加を把握し、キャパシティの予測に役立てる

ネットワーク使用方法の理解とネットワーク トラフィック費用の最適化

VPC フローログを使用すると、ネットワーク使用量を分析できます。ネットワーク フローを分析して次のことを把握できます。

  • リージョンとゾーンの間のトラフィック
  • インターネットでの特定の国へのトラフィック
  • トラフィック使用量が特に多いプロセス

分析を基にして、ネットワーク トラフィックの費用を最適化できます。

ネットワーク フォレンジック

VPC フローログをネットワーク フォレンジックに利用できます。たとえば、インシデントが発生した場合、以下を調べることができます。

  • どの IP が、いつ、どの相手と情報をやり取りしたか
  • 不正使用された IP(すべての受信と送信のネットワーク フローを分析して調査)

リアルタイムのセキュリティ分析

リアルタイム ストリーミングの API を(Pub/Sub 経由で)利用し、SIEM(Security Information and Event Management)システムと統合できます。これにより、リアルタイムのモニタリング、イベントの相関、分析、およびセキュリティ アラートを提供できます。

ログの収集

フローログは、各 VM 接続ごとに特定の間隔で収集されます。特定の接続について特定の間隔で収集されたすべてのパケットは、一定期間(一定集計間隔で)単一のフローログ エントリに集計されます。このデータは Logging に送信されます。

ログはデフォルトで 30 日間 Logging に保存されます。それより長く保持するには、サポートされている宛先にエクスポートする必要があります。

ログのサンプリングと処理

Google Cloud は、VM で送受信されたパケットをサンプリングして、フローログを生成します。すべてのパケットが独自のログレコードに収集されるとは限りません。10 パケットごとに約 1 パケットがキャプチャされますが、このサンプリング レートは VM の負荷に応じて低くなることもあります。このレートは調整できません。

Google Cloud で生成されたフローログは、次の手順で処理されます。

  1. フィルタリング: 指定した条件に一致するログのみを生成するように指定できます。たとえば、特定の VM のログのみ、または特定のメタデータ値を持つログのみが生成され、残りは破棄されるようにフィルタリングできます。
  2. 集計: サンプリングされたパケットの情報が、ユーザーが構成可能な集計間隔で集計され、フローログ エントリが生成されます。
  3. フローログのサンプリング: これは 2 番目のサンプリング処理です。ユーザーが構成可能なサンプルレートのパラメータに従って、フローログのエントリがさらにサンプリングされます。
  4. メタデータ: 無効にすると、すべてのメタデータ アノテーションが破棄されます。メタデータを保持する場合は、デフォルトのフィールドのセットまたは指定したフィールドのセットを保持するように指定できます。詳細については、メタデータ フィールドのカスタマイズをご覧ください。
  5. Logging への書き込み: 最終的なログエントリが Cloud Logging に書き込まれます。

VPC フローログはすべてのパケットをキャプチャするわけではないため、キャプチャされたパケットから補完することで、欠落したパケットを補います。これは、初期構成とユーザーが構成可能なサンプリング設定が原因でパケットが欠落している場合に起こります。

Google Cloud ではすべてのパケットをキャプチャしませんが、ログレコードのキャプチャは非常に大きくなる可能性があります。ログ収集の以下の設定を調整すると、トラフィックの可視性と必要なストレージ費用のバランスをとることができます。

  • 集計間隔: 一定の時間間隔でサンプリングされたパケットは、単一のログエントリに集計されます。この時間間隔は、5 秒(デフォルト)、30 秒、1 分、5 分、10 分、15 分から選択できます。
  • サンプルレート: Logging に書き込まれる前に、ログの数をサンプリングして数を減らすことができます。デフォルトでは、ログエントリのボリュームが 0.5(50%)に縮小されます。つまり、エントリの半分が保持されます。このサンプルレートは 1.0(100%、すべてのログエントリを保持)から 0.0(0%、ログを保持しない)の範囲で設定できます。
  • メタデータ アノテーション: デフォルトでは、フローログ エントリには、送信元と宛先の VM の名前や、外部の送信元と宛先の地理的リージョンなどのメタデータ情報でアノテーションが付きます。メタデータ アノテーションをオフにすることも、特定のアノテーションのみを指定して保存容量を節約することもできます。
  • フィルタリング: デフォルトでは、ログはサブネット内のすべてのフローに対して生成されます。特定の条件に一致するログのみを生成するように、フィルタを設定できます。

メタデータ フィールドのカスタマイズ

各ログを使用すると、関連するすべてのメタデータを抽出できます。指定した特定のメタデータを抽出することも、メタデータの抽出を行わないこともできます。メタデータ フィールドは、src_vpc.project_id などのフルネームで指定することも、src_vpc.project_idsrc_vpc.vpc_namesrc_vpc.subnetwork_name を含む src_vpc などの親フィールドで指定することもできます。

Metadata タイプのフィールドのみを省略できます。Base タイプのフィールドは省略できません。基本フィールドは常に含まれます。省略できません。レコード形式セクションには、どのフィールドがメタデータでどのフィールドが Base なのかが示されています。

新しいメタデータ アノテーションが VPC フローログ レコード形式に追加された場合、それらのアノテーションは「すべてを含む」構成のフィールド リストに追加されません。次のフィールドのみが「すべて一致」に含まれます。

  • src_instance
  • dest_instance
  • src_vpc
  • dest_vpc
  • src_location
  • dest_location

GKE アノテーションを含む新しいアノテーションは、カスタム構成を使用して手動で追加した場合にのみログに表示されます。

メタデータ フィールドをカスタマイズする手順については、サブネット作成時の VPC フローロギングの有効化をご覧ください。

GKE アノテーション

GKE クラスタにエンドポイントがあるフローには、そのエンドポイントのクラスタ、Pod、Service の詳細を含む GKE アノテーションを付けることができます。GKE アノテーションは、メタデータ フィールドのカスタム構成でのみ使用できます。

GKE Service アノテーション

ClusterIP、NodePort、LoadBalancer に送信されたトラフィックは、Service アノテーションを取得できます。NodePort または LoadBalancer に送信された場合、フローは接続の両方のホップで Service アノテーションを受け取ります。

Pod の Service ポートに直接送信されたトラフィックには、宛先エンドポイントの Service アノテーションでアノテーションが付けられます。

Pod が同じ Service ポートで複数の Service をサポートしている場合、Pod のサービスポートに送信されるトラフィックには、宛先エンドポイントで複数の Service がアノテーションされます。これは 2 つの Service に限定されます。それ以上ある場合は、エンドポイントに特別な MANY_SERVICES マーカーが付けられます。

インターネット トラフィックでの Pod アノテーション

Pod とインターネット間のトラフィックは、デフォルトでは Pod アノテーションを受信しません。インターネットへのパケットの場合、マスカレード エージェントが Pod の IP アドレスをノード IP アドレスに変換してから VPC フローログがパケットを認識します。このため、VPC フローログは Pod に関する情報がないため Pod アノテーションを追加できません。

マスカレードのため、リンク先がデフォルトの非マスカレードの宛先またはカスタム nonMasqueradeCIDRs リスト内にある場合にのみ、Pod アノテーションが表示されます。インターネットの宛先をカスタム nonMasqueradeCIDRs リストに含める場合は、インターネットに到達する前に内部 Pod IP アドレスが変換されるようにする必要があります。Cloud NAT は限定公開クラスタと非プライベート クラスタの両方で使用できます。詳細については、GKE の操作をご覧ください。

レコードの形式

ログレコードには、各ログレコードのコアフィールドであるベース フィールドと、詳細情報を追加するメタデータ フィールドが含まれています。メタデータ フィールドは、ストレージ費用を節約するために省略できます。

一部のログフィールドはマルチ フィールド形式であり、所定のフィールドに複数のデータが含まれます。たとえば、connection フィールドは IpConnection 形式で、送信元と宛先の IP アドレスとポート、およびプロトコルが 1 つのフィールドに格納されます。これらのマルチ フィールドのフィールドについては、レコードの形式に関する表を示した後で説明します。

フィールド フィールドの形式 フィールド タイプ: 基本またはオプションのメタデータ
connection IpConnection
この接続に関する説明を含む 5 つのタプル。
基本
start_time string
集計対象である時間間隔で最初に観測されるパケットのタイムスタンプ(RFC 3339 の日付文字列形式)
基本
end_time string
集計対象である時間間隔で最後に観測されるパケットのタイムスタンプ(RFC 3339 の日付文字列形式)
基本
bytes_sent int64
送信元から宛先に送信されるバイト数
基本
packets_sent int64
送信元から宛先に送信されるパケット数
基本
rtt_msec int64
時間間隔中に測定されたレイテンシ。TCP フローに対してのみ測定されます。測定されたレイテンシは、SEQ を送信してから対応する ACK を受信するまでの経過時間です。レイテンシの結果は、ネットワーク RTT とアプリケーションが消費した時間の合計です。
基本
reporter string
フローを報告した側。SRC または DEST のいずれかになります。
基本
src_instance InstanceDetails
接続の送信元が同じ VPC 上の VM である場合、このフィールドには VM インスタンスの詳細が入力されます。共有 VPC 構成の場合、project_id はインスタンスを所有するプロジェクト(通常はサービス プロジェクト)に対応します。
メタデータ
dest_instance InstanceDetails
接続の宛先が同じ VPC 上の VM である場合、このフィールドには VM インスタンスの詳細が入力されます。共有 VPC 構成の場合、project_id はインスタンスを所有するプロジェクト(通常はサービス プロジェクト)に対応します。
メタデータ
src_vpc VpcDetails
接続の参照元が同じ VPC 上の VM である場合、このフィールドには VPC ネットワークの詳細が入力されます。共有 VPC 構成の場合、project_id はホスト プロジェクトの詳細に対応します。
メタデータ
dest_vpc VpcDetails
接続の宛先が同じ VPC 上の VM である場合、このフィールドには VPC ネットワークの詳細が入力されます。共有 VPC 構成の場合、project_id はホスト プロジェクトの詳細に対応します。
メタデータ
src_location GeographicDetails
接続の参照元が Google VPC の外部にある場合、このフィールドには使用可能な場所のメタデータが入力されます。
メタデータ
dest_location GeographicDetails
接続の宛先が Google VPC の外部にある場合、このフィールドには使用可能な場所のメタデータが入力されます。
メタデータ
src_gke_details GkeDetails
送信元のエンドポイントの GKE メタデータ。エンドポイントが GKE の場合にのみ使用できます。メタデータ フィールドのカスタム構成でのみ使用できます。
メタデータ
dest_gke_details GkeDetails
宛先エンドポイントの GKE メタデータ。エンドポイントが GKE の場合にのみ使用できます。メタデータ フィールドのカスタム構成でのみ使用できます。
メタデータ

IpConnection フィールドの形式

フィールド 説明
src_ip string 送信元 IP アドレス
src_port int32 送信元ポート
dest_ip string 宛先 IP アドレス
dest_port int32 宛先ポート
protocol int32 IANA プロトコル番号

InstanceDetails フィールドの形式

フィールド 説明
project_id string VM を含むプロジェクトの ID
vm_name string VM のインスタンス名
region string VM のリージョン
zone string VM のゾーン

VpcDetails フィールドの形式

フィールド 説明
project_id string VPC を含むプロジェクトの ID
vpc_name string VM が動作している VPC
subnetwork_name string VM が動作しているサブネットワーク

GeographicDetails フィールドの形式

フィールド 説明
continent string 外部エンドポイントの大陸
country string 外部エンドポイントの国で、ISO 3166-1 Alpha-3 の国コードにより表されます。
region string 外部エンドポイントのリージョン
city string 外部エンドポイントの都市
asn int32 このエンドポイントが属する外部ネットワークの自律システム番号(ASN)

GkeDetails フィールドの形式

フィールド 説明
Cluster ClusterDetails GKE クラスタ メタデータ。
Pod PodDetails トラフィックの送信元または宛先が Pod である場合に入力される GKE Pod のメタデータ。
Service ServiceDetails Service エンドポイントにのみ入力される GKE Service メタデータ。レコードには最大 2 つの Service が含まれます。関連する Service が 3 つ以上ある場合、このフィールドには特別な MANY_SERVICES マーカーを持つ 1 つの Service が含まれます。

ClusterDetails フィールドの形式

フィールド 説明
cluster_name string GKE クラスタ名。
cluster_location string クラスタのロケーション。ゾーンクラスタかリージョン クラスタかに応じて、ゾーンまたはリージョンになります。

PodDetails フィールドの形式

フィールド 説明
pod_name string Pod の名前。
pod_namespace string Pod の Namespace。

ServiceDetails フィールドの形式

フィールド 説明
service_name string Service の名前。関連する Service が 2 つ以上ある場合、フィールドは特別な MANY_SERVICES マーカーに設定されます。
service_namespace string Service の Namespace。

例:

2 つのサービスがある場合、[Service] フィールドは次のようになります。

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

3 つ以上のサービスがある場合、[Service] フィールドは次のようになります。

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

ログのフィルタリング

VPC フローログを有効にすると、フィルタに一致するログのみを保持する基本フィールドとメタデータ フィールドの両方に基づいてフィルタを設定できます。他のすべてのログは Logging に書き込まれる前に破棄されるため、コストが節約され、必要な情報の検索にかかる時間が短縮されます。

[レコード形式] のフィールドのサブセットでフィルタリングできます。

VPC フローログ フィルタリングでは、属性ベースの論理式に埋め込み式の表現言語である CEL が使用されます。詳しくは、サポートされている CEL 論理演算子をご覧ください。

CEL の詳細については、CEL の概要言語の定義をご覧ください。生成フィルタ機能では、CEL 構文の特定のサブセットのみがサポートされます。

例 1: ログの収集を my-vm という名前の特定の VM に制限する。この場合、トラフィックの送信元から報告された src_instance フィールドが my-vm であるか、トラフィックの宛先から報告された dst_instance フィールドが my-vm であるログのみが記録されます。

gcloud compute networks subnets update my-subnet \
--logging-filter-expr = "(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

例 2: ログの収集を送信元 IP アドレスが 10.0.0.0/8 サブネットのパケットに限定する。

gcloud compute networks subnets update my-subnet \
--logging-filter-expr = "inIpRange(connection.src_ip, '10.0.0.0/8')"

サポートされている CEL 論理演算子


Expression

Supported Types

Description
true、false ブール値 ブール定数
x == y x != y ブール値、整数、文字列 比較演算子の例: connection.protocol == 6
x && y x || y ブール値 ブール論理演算子の例: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x ブール値 否定
1, 2.0, 0, ... 整数 定数の数値リテラル
x + y 文字列 文字列の連結
"foo", 'foo', ... 文字列 定数の文字列リテラル
x.lower() 文字列 文字列の小文字の値を返します。
x.upper() 文字列 文字列の大文字の値を返します。
x.contains(y) 文字列 文字列に指定された部分文字列が含まれている場合は true を返します。
x.startsWith(y) 文字列 文字列が、指定された部分文字列で始まる場合に true を返します。
x.endsWith(y) 文字列 文字列が、指定された部分文字列で終わる場合に true を返します。
inIpRange(X, Y) 文字列 X が IP で Y が X を含む IP 範囲である場合、true を返します。
例: inIpRange("1.2.3.1", "1.2.3.0/24")
x.containsFieldValue(y) x: list
y: map(string, string)
指定された Key-Value ペアと一致するフィールドを含むオブジェクトがリストに含まれている場合、true が返されます。
例: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})

トラフィック パターンの例

このセクションでは、次のユースケースでの VPC フローログの動作を示します。

同一 VPC 内での VM から VM へのフロー

VPC 内での VM のフロー(クリックで拡大)
VPC 内での VM のフロー(クリックで拡大)

同じ VPC 内の VM から VM へのフローでは、VPC フローログが有効になっているサブネットに両方の VM がある場合、フローログはリクエストとレスポンスの両方の VM から報告されます。この例では、VM 10.10.0.2 が 1,224 バイトのリクエストを、同様にロギングが有効になっているサブネット内にある VM 10.50.0.2 に送信します。次に、10.50.0.2 はリクエストに対して、5,342 バイトを含む応答を返します。リクエストと応答の両方が、要求側 VM と応答側 VM の両方から記録されます。

要求側 VM(10.10.0.2)による報告
リクエスト / 応答 connection.src_ip connection.dest_ip bytes_sent VPC アノテーション
リクエスト 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
応答 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
応答側 VM(10.50.0.2)による報告
リクエスト / 応答 connection.src_ip connection.dest_ip bytes VPC アノテーション
リクエスト 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
応答 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*

VM から外部へのフロー

VM から外部へのフロー(クリックで拡大)
VM から外部へのフロー(クリックで拡大)

VM と外部エンティティ間のフローの場合、フローログは VM からのみ報告されます。

  • 下りフローの場合、ログはトラフィックの送信元である VM から報告されます。
  • 上りフローの場合、ログはトラフィックの宛先である VM から報告されます。

これは次のトラフィックに適用されます。

  • Cloud VPN または Cloud Interconnect を経由する、VPC ネットワークとオンプレミス ネットワーク間のトラフィック。
  • VM とインターネット上のロケーションの間のトラフィック

次の例では、VM 10.10.0.2 とオンプレミス エンドポイント 10.30.0.2 は、VPN ゲートウェイまたは Cloud Interconnect を介して接続されています。10.10.0.2 から 10.30.0.2 に送信された 1,224 バイトの発信トラフィックは、送信元 VM 10.10.0.2 から報告されます。10.30.0.2 から 10.10.0.2 に送信された 5,342 バイトの受信トラフィックは、トラフィックの宛先である VM 10.10.0.2 から報告されます。

リクエスト / 応答 connection.src_ip connection.dest_ip bytes_sent VPC アノテーション
リクエスト 10.10.0.2 10.30.0.2 1224 src_instance.*
src_vpc.*
dest_location.*
応答 10.30.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*
src_location.*

共有 VPC での VM から VM へのフロー

共有 VPC でのフロー(クリックで拡大)
共有 VPC でのフロー(クリックで拡大)

共有 VPC での VM から VM へのフローの場合は、ホスト プロジェクトでサブネットに対して VPC フローログを有効にできます。たとえば、サブネット 10.10.0.0/20 が、ホスト プロジェクトで定義されている共有 VPC ネットワークに属しているとします。このサブネットに属する VM のフローログを確認できます(サービス プロジェクトによって作成されたものを含みます)。この例では、サービス プロジェクトは "webserver"、"recommendation"、"database" と呼ばれます。

VM から VM へのフローの場合に、両方の VM が同じプロジェクト内にある場合、または共有ネットワーク内にある場合、同じホスト プロジェクトや、プロジェクト ID のアノテーションなどが接続のもう一方のエンドポイントで提供されます。他の VM が別のプロジェクトにある場合、その他の VM のアノテーションは提供されません。

次の表には、10.10.0.10 または 10.10.0.20 で報告されるフローが示されています。

  • src_vpc.project_iddest_vpc.project_id は VPC サブネットがホスト プロジェクトに属しているため、ホスト プロジェクト用のものです。
  • src_instance.project_iddest_instance.project_id はインスタンスがサービス プロジェクトに属しているため、サービス プロジェクト用のものです。
connection
.src_ip
src_instance
.project_id
src_vpc
.project_id
connection
.dest_ip
dest_instance
.project_id
dest_vpc
.project_id
10.10.0.10 webserver host_project 10.10.0.20 recommendation host_project

サービス プロジェクトは独自の共有 VPC ネットワークを所有していないため、共有 VPC ネットワークのフローログにアクセスできません。

VPC ネットワーク ピアリングでの VM から VM へのフロー

VPC ネットワーク ピアリングでのフロー(クリックして拡大)
VPC ネットワーク ピアリングでのフロー(クリックして拡大)

両方の VM が同じ Google Cloud プロジェクトにない場合、ピアリングされた VPC の VM から VM へのフローは外部エンドポイントの場合と同じ方法で報告されます。他の VM に関するプロジェクトとその他のアノテーション情報は提供されません。両方の VM が同じプロジェクトにある場合、異なるネットワーク上にある場合でも、プロジェクトとその他のアノテーション情報は他の VM についても提供されます。

次の例では、プロジェクト analytics-prod の VM 10.10.0.2 およびプロジェクト webserver-test の VM 10.50.0.2 のサブネットが VPC ネットワーク ピアリングで接続されています。VPC フローログがプロジェクト analytics-prod で有効になると、10.10.0.2 から 10.50.0.2 に送信されるトラフィック(1,224 バイト)が、フローの送信元である VM 10.10.0.2 から報告されます。10.50.0.2 から 10.10.0.2 に送信されるトラフィック(5,342 バイト)も、フローの宛先である VM 10.10.0.2 から報告されます。

この例では、VPC フローログはプロジェクト webserver-test で有効になっていないため、VM 10.50.0.2 でログは記録されません。

reporter connection.src_ip connection.dest_ip bytes_sent VPC アノテーション
送信元 10.10.0.2 10.50.0.2 1224 src_instance.*
src_vpc.*
宛先 10.50.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*

内部 TCP / UDP 負荷分散での VM から VM へのフロー

内部 TCP / UDP 負荷分散でのフロー(クリックして拡大)
内部 TCP / UDP 負荷分散でのフロー(クリックして拡大)

内部 TCP / UDP ロードバランサのバックエンド サービスに VM を追加すると、Linux または Windows のゲスト環境で VM のローカル ルーティング テーブルにロードバランサの IP アドレスが追加されます。これにより、宛先がロードバランサの IP アドレスに設定されたリクエスト パケットを VM が受け入れられるようになります。VM が応答すると、そのレスポンスが直接送信されます。ただし、レスポンス パケットの送信元 IP アドレスは、負荷分散される VM ではなく、ロードバランサの IP アドレスに設定されます。

内部 TCP / UDP ロードバランサを経由して送信される VM から VM へのフローは、送信元と宛先の両方から報告されます。HTTP リクエスト / レスポンスのペアの例について、監視されたフローログのエントリに使用されるフィールドを以下の表で説明します。これを示すために、以下のネットワーク構成を想定します。

  • ブラウザ インスタンス(192.168.1.2)
  • 内部 TCP / UDP ロードバランサ(10.240.0.200)
  • ウェブサーバー インスタンス(10.240.0.3)
トラフィックの方向 reporter connection.src_ip connection.dest_ip connection.src_instance connection.dest_instance
リクエスト SRC 192.168.1.2 10.240.0.200 ブラウザ インスタンス
リクエスト DEST 192.168.1.2 10.240.0.200 ブラウザ インスタンス ウェブサーバー インスタンス
レスポンス SRC 10.240.0.3 192.168.1.2 ウェブサーバー インスタンス ブラウザ インスタンス
レスポンス DEST 10.240.0.200 192.168.1.2 ブラウザ インスタンス

要求側 VM は、どの VM がリクエストに応答するのかを認識しません。また、相手側 VM は送信元アドレスとして内部ロードバランサの IP を使用してレスポンスを送信するため、どの VM が応答したかも認識しません。このため、要求側 VM は dest_instance 情報をレポートに追加できず、src_instance 情報のみを追加できます。レスポンス側 VM はリクエスト側 VM の IP アドレスを認識しているため、src_instancedest_instance の両方の情報を提供できます。

Pod から ClusterIP へのフロー

Pod からクラスタ IP へのフロー(クリックして拡大)
Pod からクラスタ IP へのフロー(クリックして拡大)

この例では、トラフィックはクライアント Pod(10.4.0.2)から cluster-service10.0.32.2:80)に送信されます。宛先は、ターゲット ポート(8080)で選択したサーバー Pod IP アドレス(10.4.0.3)に解決されます。

ノードエッジでは、変換された IP アドレスとポートを使用してフローが 2 回サンプリングされます。どちらのサンプリング ポイントでも、宛先 Pod がポート 8080 でサービス cluster-service をバックアップしていることを特定し、Service の詳細と Pod の詳細を記録します。トラフィックが同じノード上の Pod にルーティングされた場合、トラフィックはノードから離れず、サンプリングは行われません。

次のレコードが見つかります。GKE フィールドはカスタム メタデータ構成でのみ使用できます。

reporter connection.src_ip connection.dst_ip bytes_sent VPC アノテーション
SRC 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

GKE 外部 LoadBalancer のフロー

外部ロードバランサのフロー(クリックして拡大)
外部ロードバランサのフロー(クリックして拡大)

外部 IP アドレスから GKE サービス(35.35.35.35)へのトラフィックは、クラスタ内のノード(この例では 10.0.12.2)にルーティングされます。デフォルトでは、ネットワーク ロードバランサは、ノードが関連する Pod を実行していない場合でも、クラスタ内のすべてのノード間でトラフィックを分散します。トラフィックは、関連する Pod に到達するまでに追加のホップが必要になる場合があります。詳細については、クラスタ外のネットワークをご覧ください。

その後、トラフィックはノード(10.0.12.2)から選択したサーバー Pod(10.4.0.2)にルーティングされます。すべてのノードエッジがサンプリングされるため、両方のホップがログに記録されます。トラフィックが同じノード(この例では 10.4.0.3)上の Pod にルーティングされた場合、2 番目のホップはノードから離れないため、ログに記録されません。2 番目のホップは両方のノードのサンプリング ポイントによって記録されます。2 番目のホップは両方のノードのサンプリング ポイントによって記録されます。最初のホップでは、ロードバランサの IP とサービスポート(80)に基づいてサービスを識別します。2 番目のホップでは、宛先 Pod がターゲット ポート(8080)で Service をバックアップしています。

この例では、次のレコードが確認できます。GKE フィールドはカスタム メタデータ構成でのみ使用できます。

reporter connection.src_ip connection.dst_ip bytes_sent VPC アノテーション
DEST 203.0.113.1 35.35.35.35 1224 src_location.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

GKE Ingress フロー

Ingress フロー(クリックして拡大)
Ingress フロー(クリックして拡大)

パブリック IP アドレスから Ingress 宛先への接続は、ロードバランサ サービスで終了します。接続は URL に従って NodePort Service にマッピングされます。リクエストを処理するために、ロードバランサ(130.211.0.1)はクラスタノード(10.0.12.2)のいずれかに接続し、Service の NodePort を使用してルーティングを行います。デフォルトでは、Ingress を作成すると、GKE Ingress コントローラにより HTTP(S) ロードバランサが構成されます。このロードバランサは、関連する Pod を実行していない場合でも、クラスタ内のすべてのノードにトラフィックを分散します。トラフィックは、関連する Pod に到達するまでに追加のホップが必要になる場合があります。詳細については、ネットワークの概要をご覧ください。その後、トラフィックはノード(10.0.12.2)から選択したサーバー Pod(10.4.0.2)にルーティングされます。

すべてのノードエッジがサンプリングされるため、両方のホップがログに記録されます。最初のホップでは、Service の NodePort(60000)に基づいて Service を識別します。2 番目のホップでは、宛先 Pod がターゲット ポート(8080)で Service をサポートしていることを特定します。2 番目のホップは、両方のノードのサンプリング ポイントによって記録されます。ただし、トラフィックが同じノード(10.4.0.3)の Pod にルーティングされた場合、トラフィックがノードから離れていないため、2 番目のホップはログに記録されません。

この例では、次のレコードが確認できます。GKE フィールドはカスタム メタデータ構成でのみ使用できます。

reporter connection.src_ip connection.dst_ip bytes_sent VPC アノテーション
DEST 130.211.0.1 10.0.12.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

コンテナ ネイティブの負荷分散を使用した GKE Ingress フロー

コンテナ ネイティブの負荷分散を使用した Ingress フロー(クリックして拡大)
コンテナ ネイティブの負荷分散を使用した Ingress フロー(クリックして拡大)

パブリック IP アドレスから コンテナ ネイティブの負荷分散を使用している Ingress へのリクエストは、ロードバランサで終了します。このタイプの Ingress では、Pod は負荷分散のコア オブジェクトです。次に、ロードバランサ(130.211.0.1)から選択した Pod(10.4.0.2)に直接リクエストが送信されます。宛先 Pod がターゲット ポート(8080)でサービスをバックアップすることを識別します。

次のレコードがあります。GKE フィールドはカスタム メタデータ構成でのみ使用できます。

reporter connection.src_ip connection.dst_ip bytes_sent VPC アノテーション
DEST 130.211.0.1 10.4.0.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Pod から外部へのフロー

Pod から外部へのフロー(クリックして拡大)
Pod から外部へのフロー(クリックして拡大)

Pod(10.4.0.3)から外部 IP(203.0.113.1)へのトラフィックは、Pod IP ではなくノード IP(10.0.12.2)から送信されるように IP マスカレードによって変更されます。GKE クラスタは、デフォルトで外部の宛先にトラフィックをマスカレードするように構成されます。詳細については、IP マスカレード エージェントをご覧ください。

このトラフィックの Pod アノテーションを表示するには、Pod IP をマスカレードしないようにマスカレード エージェントを構成します。このような場合、インターネットへのトラフィックを許可するために、Pod IP アドレスを処理する Cloud NAT を構成できます。Cloud NAT と GKE の詳細については、GKE の操作をご覧ください。

この例では、次のレコードがあります。GKE フィールドはカスタム メタデータ構成でのみ使用できます。

reporter connection.src_ip connection.dst_ip bytes_sent VPC アノテーション
SRC 10.0.12.2 203.0.113.1 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_location.*

料金

Logging、BigQuery、または Pub/Sub の標準料金が適用されます。VPC フローログの料金については、ネットワーク テレメトリーの料金をご覧ください。

よくある質問

  • VPC フローログには、ファイアウォール ルールに基づいて許可されるトラフィックと拒否されるトラフィックの両方が含まれていますか?

    • VPC フローログでは、VM の観点からトラフィックがカバーされます。VM からのすべての下り(発信)トラフィックは、ファイアウォールの下り拒否ルールによってブロックされていても記録されます。上り(着信)トラフィックは、ファイアウォールの上り許可ルールによって許可されている場合に記録されます。ファイアウォールの上り(内向き)拒否ルールによってブロックされた上りトラフィックは記録されません。
  • VPC フローログは、インターフェースが複数ある VM インスタンスで動作しますか?

  • VPC フローログはレガシー ネットワークで動作しますか?

次のステップ