理解OpenShift（1）：網絡之 Router 和 Route
理解OpenShift（5）：從 Docker Volume 到 OpenShift Persistent Volume
** 本文基於 OpenShift 3.11，Kubernetes 1.11 進行測試 ***
1. 概況
為了OpenShift 集群中 pod 之間的網絡通信，OpenShift 以插件形式提供了三種符合Kubernetes CNI 要求的 SDN實現：
- 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 生產環境，主要的網絡規划和設計如下圖所示：
節點角色類型：
- 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
做完De-SNAT后，根據路由表，它又會回到 tun0， OVS 根據流表，會根據目的pod IP 地址對它進行轉發，使得它回到原來的出發pod。
參考文檔：
- http://www.openvswitch.org/support/dist-docs-2.5/ovs-ofctl.8.html
- OVS 在雲項目中的使用 （https://medoc.readthedocs.io/en/latest/docs/ovs/sharing/cloud_usage.html）
- 解析 | OpenShift源碼簡析之pod網絡配置
- Troubeshooting OpenShift SDN （https://docs.openshift.com/container-platform/3.11/admin_guide/sdn_troubleshooting.html）
- https://blog.openshift.com/openshift-container-platform-reference-architecture-implementation-guides/
- https://github.com/openshift/openshift-sdn/blob/master/ISOLATION.md
- https://blog.avinetworks.com/kubernetes-and-openshift-networking-primer
感謝您的閱讀，歡迎關注我的微信公眾號：
