理解OpenShift（3）：網絡之 SDN

時間 2019-11-10

標籤理解 openshift 網絡 sdn 欄目系統網絡简体版

原文原文鏈接

理解OpenShift（1）：網絡之 Router 和 Routehtml

理解OpenShift（2）：網絡之 DNS（域名服務）node

理解OpenShift（3）：網絡之 SDNlinux

理解OpenShift（4）：用戶及權限管理git

理解OpenShift（5）：從 Docker Volume 到 OpenShift Persistent Volumegithub

** 本文基於 OpenShift 3.11，Kubernetes 1.11 進行測試 ***web

1. 概況

爲了OpenShift 集羣中 pod 之間的網絡通訊，OpenShift 以插件形式提供了三種符合Kubernetes CNI 要求的 SDN實現：docker

ovs-subnet：ovs-subnet 實現的是一種扁平網絡，未實現租戶之間的網絡隔離，這意味着全部租戶之間的pod 均可以互訪，這使得該實現沒法用於絕大多數的生產環境。
ovs-multitenant：基於 OVS 和 VxLAN 等技術實現了項目（project）之間的網絡隔離。
ovs-networkpolicy：介於ovs-subnet 和 ovs-multitenant 之間的一種實現。考慮到 ovs-multitenant 只是實現了項目級別的網絡隔離，這種隔離粒度在一些場景中有些過大，用戶無法作更精細的控制，這種需求致使了ovs-networkpolicy的出現。默認地，它和ovs-subnet 同樣，全部租戶之間都沒有網絡隔離。可是，管理員能夠經過定義 NetworkPolicy 對象來精細地進行網絡控制。能夠粗略地將它類比爲OpenStack neutron 中的neutron 網絡防火牆和Nova安全組。具體請查閱有關文檔。

當使用 ansible 部署 OpenShift 時，默認會啓用ovs-subnet，可是能夠在部署完成後修改成其它兩種實現。本文中的說明都是針對 ovs-multitenant。後端

1.1 OpenShift 集羣的網絡設計

要部署一個OpenShift 生產環境，主要的網絡規劃和設計以下圖所示：api

節點角色類型：安全

Master 節點：只承擔 Master 角色，可不也能夠承擔Node 角色。主要運行 API 服務、controller manager 服務、etcd 服務、web console 服務等。
Infra 節點：做爲 Node 角色，經過設置並應用節點標籤，只用於部署系統基礎服務，包括Registry、Router、Prometheus 以及 EFK 等。
Node 節點：做爲 Node 角色，用於運行用戶業務系統的Pod。

網絡類型：

外部網絡：這是一個外部網絡，用於從外部訪問集羣。和該網絡鏈接的服務器或組件須要被分配公網IP地址才能被從外部訪問。從內部訪問外網中的服務時，好比DNS或者鏡像倉庫，能夠經過NAT實現，而無需公網IP地址。
管理網絡：這是一個內部網絡，用於集羣內部 API 訪問。
IPMI網絡：這是一個內部網絡，用於管理物理服務器。
SDN網絡：這是一個內部網絡，用於集羣內部Pod 之間的通訊，承載 VxLAN Overlay 流量。
存儲網絡：這是一個內部網絡，用於各節點訪問基於網絡的存儲。

在PoC 或開發測試環境中，管理/SDN/存儲網絡能夠合併爲一個網絡。

1.2 Node節點中的網絡

節點上的主要網絡設備：

br0：OpenShift 建立和管理的 Open vSwitch 網橋, 它會使用 OpenFlow 規則來實現網絡隔離和轉發。
vethXXXXX：veth 對，它負責將 pod 的網絡命名空間鏈接到 br0 網橋。
tun0 ：一OVS 內部端口，它會被分配本機的 pod 子網的網關IP 地址，用於OpenShift pod 以及Docker 容器與集羣外部的通訊。iptables 的 NAT 規則會做用於tun0。
docker0：Docker 管理和使用的 linux bridge 網橋，經過 veth 對將不受 OpenShift 管理的Docker 容器的網絡地址空間鏈接到 docker0 上。
vovsbr/vlinuxbr：將 docker0 和 br0 鏈接起來的 veth 對，使得Docker 容器能和 OpenShift pod 通訊，以及經過 tun0 訪問外部網絡
vxlan0：一OVS VXLAN 隧道端點，用於集羣內部 pod 之間的網絡通訊。

2. 實現

2.1 pod 網絡整體設置流程

Pod 網絡整體設置流程以下（來源：OpenShift源碼簡析之pod網絡配置(上））：

簡單說明：

OpenShift 使用運行在每一個節點上的 kubelet 來負責pod 的建立和管理，其中就包括網絡配置部分。
當 kubelet 接受到 pod 建立請求時，會首先調用docker client 來建立容器，而後再調用 docker api接口啓動上一步中建立成功的容器。kubelet 在建立 pod 時是先建立一個 infra 容器，配置好該容器的網絡，而後建立真正用於業務的應用容器，最後再把業務容器的網絡加到infra容器的網絡命名空間中，至關於業務容器共享infra容器的網絡命名空間。業務應用容器和infra容器共同組成一個pod。
kubelet 使用 CNI 來建立和管理Pod網絡（openshift在啓動kubelet時傳遞的參數是--netowrk-plugin=cni）。OpenShift 實現了 CNI 插件（由 /etc/cni/net.d/80-openshift-network.conf 文件指定），其二進制文件是 /opt/cni/bin/openshift-sdn 。所以，kubelet 經過 CNI 接口來調用 openshift sdn 插件，而後具體作兩部分事情：一是經過 IPAM 獲取 IP 地址，二是設置 OVS（其中，一是經過調用 ovs-vsctl 將 infra 容器的主機端虛擬網卡加入 br0，二是調用 ovs-ofctl 命令來設置規則）。

2.2 OVS 網橋 br0 中的規則

本部份內容主要引用自 OVS 在雲項目中的使用：

流量規則表：

table 0: 根據輸入端口（in_port）作入口分流，來自VXLAN隧道的流量轉到表10並將其VXLAN VNI 保存到 OVS 中供後續使用，從tun0過阿里的（來自本節點或進本節點來作轉發的）流量分流到表30，將剩下的即本節點的容器（來自veth***）發出的流量轉到表20；
table 10: 作入口合法性檢查，若是隧道的遠端IP（tun_src）是某集羣節點的IP，就認爲是合法，繼續轉到table 30去處理;
table 20: 作入口合法性檢查，若是數據包的源IP（nw_src）與來源端口（in_port）相符，就認爲是合法的，設置源項目標記，繼續轉到table 30去處理；若是不一致，便可能存在ARP/IP欺詐，則認爲這樣的的數據包是非法的;
table 30: 數據包的目的（目的IP或ARP請求的IP）作轉發分流，分別轉到table 40~70 去處理;
table 40: 本地ARP的轉發處理，根據ARP請求的IP地址，從對應的端口（veth）發出;
table 50: 遠端ARP的轉發處理，根據ARP請求的IP地址，設置VXLAN隧道遠端IP，並從隧道發出;
table 60: Service的轉發處理，根據目標Service，設置目標項目標記和轉發出口標記，轉發到table 80去處理;
table 70: 對訪問本地容器的包，作本地IP的轉發處理，根據目標IP，設置目標項目標記和轉發出口標記，轉發到table 80去處理;
table 80: 作本地的IP包轉出合法性檢查，檢查源項目標記和目標項目標記是否匹配，或者目標項目是不是公開的，若是知足則轉發;（這裏實現了 OpenShift 網絡層面的多租戶隔離機制，其實是根據項目/project 進行隔離，由於每一個項目都會被分配一個 VXLAN VNI，table 80 只有在網絡包的VNI和端口的VNI tag 相同纔會對網絡包進行轉發）
table 90: 對訪問遠端容器的包，作遠端IP包轉發「尋址」，根據目標IP，設置VXLAN隧道遠端IP，並從隧道發出;
table 100: 作出外網的轉出處理，將數據包從tun0發出。

備註一些經常使用的操做命令：

查詢OVS 流表： ovs-ofctl -O OpenFlow13 dump-flows br0
查詢OVS設備： ovs-vsctl show
查看OVS網橋： ovs-ofctl -O OpenFlow13 show br0
查看路由表：route -n
在容器中運行命令：nsenter -t <容器的PiD> -n ip a
查詢 iptables NAT 表：iptables -t nat -S

3. 流程

3.1 同一個節點上的兩個pod 之間的互訪

訪問：pod 1 （ip：10.131.1.150）訪問 pod2（10.131.1.152）

網絡路徑：：pod1的eth0 → veth12 → br0 → veth34 → pod2的eth0。

OVS 流表：

table=0, n_packets=14631632, n_bytes=1604917617, priority=100,ip actions=goto_table:20
table=20, n_packets=166585, n_bytes=12366463, priority=100,ip,in_port=96,nw_src=10.131.1.152 actions=load:0xbe3127->NXM_NX_REG0[],goto_table:21
table=21, n_packets=14671413, n_bytes=1606835395, priority=0 actions=goto_table:30
table=30, n_packets=8585493, n_bytes=898571869, priority=200,ip,nw_dst=10.131.0.0/23 actions=goto_table:70
table=70, n_packets=249967, n_bytes=16177300, priority=100,ip,nw_dst=10.131.1.152 actions=load:0xbe3127->NXM_NX_REG1[],load:0x60->NXM_NX_REG2[],goto_table:80
table=80, n_packets=0, n_bytes=0, priority=100,reg0=0xbe3127,reg1=0xbe3127 actions=output:NXM_NX_REG2[]
table=80, n_packets=0, n_bytes=0, priority=0 actions=drop #不合法的包會被丟棄

表 20 會判斷包類型（IP）、源地址（nw_src）、進來端口的ID（96），將其對應的 VNI ID（這裏是 0xbe3127，十進制是12464423）保存在 REG0 中。這意味着全部經過OVS 端口進入OVS br0 網橋的來自pod 的網絡包都會被打上對口對應的VNID 標籤。集羣中全部項目對應的 VNID 可使用 oc get netnamespaces 命令查到：

[root@master1 cloud-user]# oc get netnamespaces
NAME                                NETID      EGRESS IPS
cicd                                16604171   []
default                             0          []
demoproject2                        16577323   []
demoprojectone                      1839630    []
dev 12464423   []

表 70 會根據目的地址，也就是目的 pod 的地址，將網絡包的目的出口標記（這裏爲 0x60，十進制爲96）保存到REG2，同時設置其項目的 VNI ID 到 REG1（這裏是0xbe3127）.

根據端口的ID 96 找到veth網絡設備：

96(veth0612e07f): addr:66:d0:c3:e3:be:cf
     config:     0
     state:      0
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max

查找其對應的容器中的網卡。

[root@node1 cloud-user]# ip link  | grep veth0612e07f
443: veth0612e07f@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue master ovs-system state UP mode DEFAULT

這與pod2容器中的 eth0 正好吻合：

3: eth0@if443: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP 
    link/ether 0a:58:0a:83:01:98 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.131.1.152/23 brd 10.131.1.255 scope global eth0
       valid_lft forever preferred_lft forever

表80 會檢查報的來源 VNI ID （REG0）和目的端口的 VNI ID （REG1），將相符的合法的包轉發到表70 設置的出口，以完成轉發。

3.2 不一樣節點上的同一個網絡的兩個pod 之間的互訪

網絡路徑：節點1上的Pod1的eth0→veth1→br0→vxlan0→ 節點1的eth0網卡→ 節點2的eth0網卡→vxlan0→br0→veth1→ Pod3的eth0流表：

發送端（node1）的OVS 流表：

table=0, n_packets=14703186, n_bytes=1612904326, priority=100,ip actions=goto_table:20
table=20, n_packets=167428, n_bytes=12428845, priority=100,ip,in_port=96,nw_src=10.131.1.152 actions=load:0xbe3127->NXM_NX_REG0[],goto_table:21
table=21, n_packets=14736461, n_bytes=1613954556, priority=0 actions=goto_table:30
table=30, n_packets=1143761, n_bytes=1424533777, priority=100,ip,nw_dst=10.128.0.0/14 actions=goto_table:90
table=90, n_packets=0, n_bytes=0, priority=100,ip,nw_dst=10.128.2.0/23 actions=move:NXM_NX_REG0[]->NXM_NX_TUN_ID[0..31],set_field:172.22.122.9->tun_dst,output:1

表21 一樣是將源pod 的 VNI ID 保存在 REG0 中。
表30 會判斷目的地址是否是集羣的大的 pod 的 IP CIDR。
表90 會設置 VNI ID 爲以前保存在 REG0 中的值，而後根據目的地址的網段（這裏是 10.128.2.0/23），計算出其所在的節點的IP 地址（這裏是 172.22.122.9）並設置爲tun_dst，而後發到 vxlan0，它會負責根據提供的信息來作VXLAN UDP 包封裝。

接收端（node2）的OVS 流表：

table=0, n_packets=1980863, n_bytes=1369174876, priority=200,ip,in_port=1,nw_src=10.128.0.0/14 actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_REG0[],goto_table:10
table=10, n_packets=0, n_bytes=0, priority=100,tun_src=172.22.122.8 actions=goto_table:30
table=30, n_packets=16055284, n_bytes=1616511267, priority=200,ip,nw_dst=10.128.2.0/23 actions=goto_table:70
table=70, n_packets=248860, n_bytes=16158751, priority=100,ip,nw_dst=10.128.2.128 actions=load:0xbe3127->NXM_NX_REG1[],load:0x32->NXM_NX_REG2[],goto_table:80
table=80, n_packets=0, n_bytes=0, priority=100,reg0=0xbe3127,reg1=0xbe3127 actions=output:NXM_NX_REG2[]

表0 會將發送到保存在 NXM_NX_TUN_ID[0..31] 中的源 VNI ID 取出來保存到 REG0.
表10 會檢查包的來源節點的地址。
表30 會檢查包的目的地址是否是本機上 pod 的網段。
表70 會根據目的地址，將目的 VNI ID 保存到 REG1，將目的端口 ID 保存到 REG2
表80 會檢查目的 VNI ID 和源 VNI ID，若是相符的話，則將包轉發到保存在 REG2 中的目的端口ID 指定的端口。而後包就會經過 veth 管道進入目的 pod。

3.3 pod 內訪問外網

網絡路徑：PodA的eth0 → vethA → br0 → tun0 → 經過iptables實現SNAT → 物理節點的 eth0 → 互聯網

NAT：將容器發出的IP包的源IP地址修改成宿主機的 eth0 網卡的IP 地址。

OVS 流表：

table=0, n_packets=14618128, n_bytes=1603472372, priority=100,ip actions=goto_table:20
table=20, n_packets=0, n_bytes=0, priority=100,ip,in_port=17,nw_src=10.131.1.73 actions=load:0xfa9a3->NXM_NX_REG0[],goto_table:21
table=21, n_packets=14656675, n_bytes=1605262241, priority=0 actions=goto_table:30
table=30, n_packets=73508, n_bytes=6820206, priority=0,ip actions=goto_table:100
table=100, n_packets=44056, n_bytes=3938540, priority=0 actions=goto_table:101
table=101, n_packets=44056, n_bytes=3938540, priority=0 actions=output:2

表20 會檢查 IP 包的來源端口和IP 地址，並將源項目的 VNI ID 保存到 REG0.

表101 會將包發送到端口2 即 tun0. 而後被 iptables 作 NAT 而後發送到 eth0.

3.4 外網訪問 pod

由於 Infra 節點上的 HAproxy 容器採用了 host-network 模式，所以它是直接使用宿主機的 eth0 網卡的。

下面是宿主機的路由表：

[root@infra-node1 /]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.22.122.1    0.0.0.0         UG    100    0        0 eth0
10.128.0.0      0.0.0.0         255.252.0.0     U     0      0        0 tun0
169.254.169.254 172.22.122.1    255.255.255.255 UGH   100    0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.22.122.0    0.0.0.0         255.255.255.0   U     100    0        0 eth0
172.30.0.0      0.0.0.0         255.255.0.0     U     0      0        0 tun0

從 HAProxy 容器內出來目的地址爲業務pod（ip：10.128.2.128）的網絡包，根據上面的路由表，其下一跳是 tun0，也就是說它又進入了 OVS 網橋 br0. 對應的 OVS 流表規則爲：

ip,in_port=2 actions=goto_table:30
ip,nw_dst=10.128.0.0/14 actions=goto_table:90
ip,nw_dst=10.128.2.0/23 actions=move:NXM_NX_REG0[]->NXM_NX_TUN_ID[0..31],set_field:172.22.122.9->tun_dst,output:1

可見它最終又被髮到了端口1 即 vxlan0，它會負責作 vxlan 封包，並經過 eth0 網卡發出去。

3.5 彙總

整體來講，OVS 中的OpenFlow流表根據網絡包的目的地址將其分爲四類來處理：

到本地pod的，直接在 br0 中轉發。
到本集羣pod 的，通過 br0 後發到 vxlan0，封裝爲 vxlan udp 包經物理網卡發到對方節點。
到本地不受OpenShift SDN管理的docker容器的，還未具體研究。
到集羣外的，通過 br0 後發到 tun0，通過 iptables 作SNAT，而後經物理網卡發出。

3.6. 項目（project）級別的網絡隔離

3.6.1 原理

OpenShift 中的網絡隔離是在項目（project）級別實現的。OpenShfit 默認的項目『default』的 VNID （Virtual Network ID）爲0，代表它是一個特權項目，由於它能夠髮網絡包到其它全部項目，也能接受其它全部項目的pod發來的網絡包。這從 table 80 的規則上能夠看出來，若是來源項目的 VNID （reg0）或目標項目的 VNID（reg1）爲0，都會容許包轉發到pod 的端口：

table=80, n_packets=8244506, n_bytes=870316191, priority=200,reg0=0 actions=output:NXM_NX_REG2[]
table=80, n_packets=13576848, n_bytes=1164951315, priority=200,reg1=0 actions=output:NXM_NX_REG2[]

其它全部項目都會有一個非0的 VNID。在 OpenShift ovs-multitenant 實現中，非0 VNID 的項目之間的網絡是不通的。

從一個本地 pod 發出的全部網絡流量，在它進入 OVS 網橋時，都會被打上它所經過的 OVS 端口ID相對應的 VNID。port:VNID 映射會在pod 建立時經過查詢master 上的 etcd 來肯定。從其它節點經過 VXLAN發過來的網絡包都會帶有發出它的pod 所在項目的 VNID。

根據上面的分析，OVS 網橋中的 OpenFlow 規則會阻止帶有與目標端口上的 VNID 不一樣的網絡包的投遞（VNID 0 除外）。這就保證了項目之間的網絡流量是互相隔離的。

可使用下面的命令查看namespace 的 NETID 也就是 VNID：

在個人環境裏面，default 項目默認就是 global的，我還把 cicd 項目設置爲 gloabl 的了，由於它也須要訪問其它項目。

3.6.2 實驗

下圖顯示了兩個項目之間的三種網絡狀態：

左圖顯示的是默認狀態：SIT 項目和 Dev 項目之間的 pod 沒法訪問。根據前面對 OVS 流表的分析，表80 會檢查IP 包的來源Pod的項目 VNI ID 和目標Pod的項目 VNI ID。若是二者不符合，這些IP網絡包就會被丟棄。
中間圖顯示的是打通這兩個項目的網絡：經過運行 oc adm pod-network join-projects 命令，將兩個項目鏈接在一塊兒，結果就是 DEV 項目的 VNI ID 變成了 SIT 項目的 VNI ID。這時候兩個項目中的 pod 網絡就通了。
右圖顯示的是分離這兩個項目的網絡：經過運行 oc adm pod-network isolate-projects 命令，將兩個項目分離，其結果是 DEV 項目被分配了新的 VNI ID。此時兩個項目中的pod 又不能互通了。

3.7 CluserIP 類型的 Service

OpenShift Serivce 有多種類型，默認的和最經常使用的是 ClusterIP 類型。每一個這種類型的Service，建立時都會被從一個子網中分配一個IP地址，在集羣內部可使用該IP地址來訪問該服務，進而訪問到它後端的pod。所以，Service 其實是用於OpenShift 集羣內部的四層負載均衡器，它是基於 iptables 實現的。

接下來我以 mybank 服務爲例進行說明，它的 ClusterIP 是 172.30.162.172，服務端口是8080；它有3個後端 10.128.2.128:8080,10.131.1.159:8080,10.131.1.160:8080。

宿主機上的路由表：

[root@node1 cloud-user]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.22.122.1    0.0.0.0         UG    100    0        0 eth0
10.128.0.0      0.0.0.0         255.252.0.0     U     0      0        0 tun0   #3.7.1 中會用到
169.254.169.254 172.22.122.1    255.255.255.255 UGH   100    0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.22.122.0    0.0.0.0         255.255.255.0   U     100    0        0 eth0   #3.7.1 中會用到
172.30.0.0      0.0.0.0         255.255.0.0     U     0      0        0 tun0   #3.7.2 中會用到

3.7.1 從宿主機上訪問服務

每當建立一個 service 後，OpenShift 會在集羣的每一個節點上的 iptables 中添加如下記錄：

-A KUBE-SERVICES -d 172.30.162.172/32 -p tcp -m comment --comment "dev/mybank:8080-tcp cluster IP" -m tcp --dport 8080 -j KUBE-SVC-3QLA52JX7QFEEEC5

-A KUBE-SVC-3QLA52JX7QFEEEC5 -m comment --comment "dev/mybank:8080-tcp" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-AWPSVWBUXH7A2CLB
-A KUBE-SVC-3QLA52JX7QFEEEC5 -m comment --comment "dev/mybank:8080-tcp" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ESYZLBFGDE6MOHX2
-A KUBE-SVC-3QLA52JX7QFEEEC5 -m comment --comment "dev/mybank:8080-tcp" -j KUBE-SEP-ENPHHSSNP6FR7JJI

-A KUBE-SEP-AWPSVWBUXH7A2CLB -p tcp -m comment --comment "dev/mybank:8080-tcp" -m tcp -j DNAT --to-destination 10.128.2.128:8080

-A KUBE-SVC-3QLA52JX7QFEEEC5 -m comment --comment "dev/mybank:8080-tcp" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ESYZLBFGDE6MOHX2

-A KUBE-SEP-ENPHHSSNP6FR7JJI -p tcp -m comment --comment "dev/mybank:8080-tcp" -m tcp -j DNAT --to-destination 10.131.1.160:8080

第1條：檢查目的IP地址以及端口，添加comment
第2到5條：以隨機分配（random）方式將流量平均地轉發到三條規則上
第6條：第一條轉發規則經過DNAT 將目的IP地址和端口修改成第一個endpoint 的IP 和地址，第7和8條相同

DNAT 後，根據路由表，下一跳將是 tun0，也就是說它會進入 OVS 網橋 br0。在進入網橋以前，若是是從pod 中發出的網絡包，還會進行SNAT，將其源IP地址修改成 tun0 的IP 地址。其目的是使得返回包能回到tun0，而後能經過反SNAT 操做，將目的IP地址由 tun0 的IP 修改成原來的源IP。具體見下文的分析。

-A OPENSHIFT-MASQUERADE -s 10.128.0.0/14 -m comment --comment "masquerade pod-to-service and pod-to-external traffic" -j MASQUERADE

而後，進入網橋。在網橋中，會檢查目的地址。若是是本地 pod 網段內的，那麼將直接轉發給對應的pod；若是是遠端pod的，那麼轉發到 vxlan0 再經過 VXLAN 網絡發到對方節點。這過程跟上面說明的過程就差很少了，再也不贅述。

3.7.2 從 pod 中訪問 service

從某個 pod 中訪問同一個 service。IP 包從 br0 的某個端口進入 OVS，而後執行如下流表規則：

table=30, n_packets=14212117, n_bytes=1219709382, priority=100,ip,nw_dst=172.30.0.0/16 actions=goto_table:60
table=60, n_packets=0, n_bytes=0, priority=100,ip,nw_dst=172.30.162.172,nw_frag=later actions=load:0xbe3127->NXM_NX_REG1[],load:0x2->NXM_NX_REG2[],goto_table:80
table=60, n_packets=0, n_bytes=0, priority=100,tcp,nw_dst=172.30.162.172,tp_dst=8080 actions=load:0xbe3127->NXM_NX_REG1[],load:0x2->NXM_NX_REG2[],goto_table:80
table=80, n_packets=0, n_bytes=0, priority=100,reg0=0xbe3127,reg1=0xbe3127 actions=output:NXM_NX_REG2[]

從 table60 能夠看出，OVS 流表給該網絡包設置的出口端口爲2，即 tun0，由於要去作NAT。出去後，即開始 iptables NAT 過程，也就是 3.7.1 中的過程。最後仍是要回到 OVS br0，再走到 vxlan0，經過 VXLAN 隧道發到目標pod 所在的宿主機。該過程示意圖以下：

對於返回的網絡包，其目的地址是源pod 宿主機上的 tun0，即左圖中的 10.131.0.1/23. 數據包到達左圖中的 br0 後，首先要出 tun0，由於要去作NAT：

table=30, n_packets=1214735, n_bytes=1135728626, priority=300,ip,nw_dst=10.131.0.1 actions=output:2

根據這篇文章（https://superuser.com/questions/1269859/linux-netfilter-how-does-connection-tracking-track-connections-changed-by-nat），發送階段 iptables 在作 SNAT 時會利用 conntrack 記錄此次修改（在/proc/net/nf_conntrack 中）；在如今回覆包返回的時候，會自動地作相反SNAT操做（相似DNAT），將包的目的IP地址（tun0的IP地址）修改成原來的源IP地址即源pod地址。

/proc/net/nf_conntrack 文件的有關記錄：

ipv4     2 tcp      6 70 TIME_WAIT src=10.131.0.1 dst=10.131.1.72 sport=56862 dport=8080 src=10.131.1.72 dst=10.131.0.1 sport=8080 dport=56862 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=0 use=2