GKE の L4LB と L7LB のパケットフロー

GKE の L4 Load Balancer と L7 Load Balancer でパケットの流れをキャプチャして追ってみたので、どのように IP:Port が切り替わってパケットが流れていくか、メモがてら結果を残しておきます。尚記載されている IP:Port は自分が試した時のものなので環境によって変わります。

その他の設定値:

• 各 Service には externalTrafficPolicy: Local を設定して自分の Node にある Pod にしかルーティングされないようにしています。
• VPC-native Cluster ではなく従来の Routes-based Cluster で試しています。

L4 Load Balancer (Service type: LoadBalancer)

1. Client → L4LB → Node: GKE の L4LB は Network Load Balancer であり、パケットはプロキシはされずにバックエンドに単純にフォワーディングされる。そのため L4LB → Node においては dst MAC アドレスの変更はあるが、5-tuple は変わらず Node へと送られてくる。
2. Node → Pod: iptables によって dst IP:Port が 10.52.211:8080 に変更される (DNAT)。
3. Pod → Node: ここからは復路だが、Pod から出たパケットは Pod の netns のデフォルトゲートウェイを通って Node に戻ってくる。
4. Node → Client: un-DNAT された上で、復路は L4LB を経由せずに直接 Client へパケットが配送される (Direct Server Return)

L7 Load Balancer (Ingress)

1. Client → L7LB: Client と L7LB (HTTP Load Balancer)間の TCP コネクションはここで一度終端される。
2. L7LB → Node: L7LB の内部から Node に対してリクエストがプロキシされる。L7LB からすると Pod の存在は知らず、Node としかやり取りしていないと思っている。
3. Node → Pod: iptables によって dst IP:Port が 10.52.211:8080 に変更される (DNAT)。
4. Pod → Node: ここからは復路だが、Pod から出たレスポンスは Pod の netns のデフォルトゲートウェイを通って Node に到達する。
5. Node → L7LB: un-DNAT された上で L7LB の内部ネットワークにレスポンスが返る。
6. L7LB → Client: レスポンスがプロキシされて Client に返される。

Reference

• GKE Network Overview
• The ins and outs of networking in Google Container Engine and Kubernetes (Google Cloud Next ‘17)