理解OpenShift（3）：网络之SDN

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发出。

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 veth0612e07f443: 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 Iface0.0.0.0         172.22.122.1    0.0.0.0         UG    100    0        0 eth010.128.0.0      0.0.0.0         255.252.0.0     U     0      0        0 tun0169.254.169.254 172.22.122.1    255.255.255.255 UGH   100    0        0 eth0172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0172.22.122.0    0.0.0.0         255.255.255.0   U     100    0        0 eth0172.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 除外）。这就保证了项目之间的网络流量是互相隔离的。

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 eth0172.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 记录这次修改；在现在回复包返回的时候，会自动地做相反SNAT操作（类似DNAT），将包的目的IP地址（tun0的IP地址）修改为原来的源IP地址即源pod地址。根据路由表，它又会回到 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