- overlay pod 到 overlay pod
- overlay pod 到 cluster ip
- overlay pod 到 node
以上功能基于 分布式网关端口、基于策略的路由策略和 1对1 NAT 实现：
1. ovn 支持PBR
ovn 支持软路由ingress方向上配置基于路由的策略，该表在IP路由表之后生效，因此能够覆盖路由策略，从而提供一个不同的吓一跳。基于该方式，可以将拓扑中的node上的pod的流量·导向到·node本地的svc。
2. ovn 支持一对一NAT
可以给一个logical port 配置一个一对一 NAT （比如FIP），那么这个port的所有包从·本地拓扑·（hv）出去之后，都会被SNAT为这个外部（独占的）IP （external_ip）。 由于这个external_ip 专门用于这个 logical_port, 那么这个 "NAT操作" 就可以直接在这个 （ovs）logical 所绑定的 chassis（hv|node） 上进行。 每个节点（chssis|hv）都支持该特性。
3. 分布式网关端口的包处理
distributed gateway port 缩写为 DGP。 distributed router 缩写为 DR。
如何在一个 DR 上创建一个 DGP？
- 添加一个逻辑路由器端口（lrp）
- 把这个lrp连接到一个（带有localnet port）的逻辑交换机
这个过程也叫 ·pathway to underlay·
对于 DGP， 我们也需要把这个DGP 绑定到 一个 chassis（node）上。
那么之后，经过DGP的包有两种处理位置：
- 在 DGP 绑定到的 chassis（node）上处理
- 在 local chassis 上处理（也即是logical port 所在的node）（pod 所在的 node）
由于上面这个原因，那么 DGP 就有两种类型：
- chassis-redirect-DGP （cr-DGP）： 集中式，包会经过 geneve 隧道 到 DGP 绑定到的 gw chassis
- DGP：分布式
需要集中式处理的流：
- 如果包来自于逻辑交换机（有连接到逻辑路由器），并且（该包对应的内部ip）没有配置点到点的NAT映射，那么这种包需要重定向到 cr-DGP.
- 下一跳物理网关的 ARP 解析在绑定到的 chassis 通过 local net port完成。
可以本地处理的流：
-
如果有一个匹配的一对一NAT规则的出向网络流量（比如公网），那么它将被发送到本地chassis（本地存在）的DGP。
4. OVN 基于 DGP 实现的逻辑的拓扑
The following diagram captures the new logical topology with the distributed gateway port created on the distributed router, ovn_cluster_router
下面是一个逻辑拓扑，包括： 分布式路由器（ovn_cluster_router）上的分布式网关端口（DGP）
东西向流量所有 node 上的 pod 都是基于 ovn_cluster_router, 这个基本不会有其它的选择，注意南北向的从本地节点到公网的路径。
pod --> (pod) logical-switch --> ovn_cluster_router --> (node) logical-switch --> gw_router --> (external) logical-switch--> eth0
pod 到 本地 svc 从本地分布式网关走。
pod--> (pod) logical-switch --> ovn_cluster_router --> DGP_ls (localnet) --> br-int --> br-local
由于拓扑中都是分布式的， 因此，我们不需要为 DGP 处理 HA，也不需要在所有 chassis 和 HA 网关 chassis 之间运行 BFD 。
下面是一张所有三种场景网络流量的访问路径
下面是该拓扑对应的静态路由，路由策略，分布式路由上的NAT
$ ovn-nbctl lr-route-list ovn_cluster_router
IPv4 Routes
192.168.1.0/24 100.64.1.1 src-ip
192.168.2.0/24 100.64.0.1 src-ip
$ ovn-nbctl lr-policy-list ovn_cluster_router
Routing Policies
1005 ip4.src == 192.168.1.2 && ip4.dst == 10.8.51.51 reroute 169.254.0.1
1005 ip4.src == 192.168.2.2 && ip4.dst == 10.8.51.53 reroute 169.254.0.1
1004 inport == "rtos-k8s-node1" && ip4.dst == 10.8.51.51 reroute 192.168.1.2
1004 inport == "rtos-k8s-node2" && ip4.dst == 10.8.51.53 reroute 192.168.2.2
$ ovn-nbctl lr-nat-list ovn_cluster_router
TYPE EXTERNAL_IP LOGICAL_IP EXTERNAL_MAC LOGICAL_PORT
dnat_and_snat 169.254.0.3 192.168.1.2 c6:c6:d9:06:9f:a1 k8s-k8s-node1
dnat_and_snat 169.254.0.4 192.168.2.2 6e:52:2d:6e:91:16 k8s-k8s-node2
# 192.168.1.2 c6:c6:d9:06:9f:a1
# 192.168.2.2 6e:52:2d:6e:91:16
# 这两个FIP 都对应到 ovn-k8s-mp0 网卡，每个node上都有，这个网卡都配置了一个fip，公网ip属于 DGP_ls
# 出去的流量都会走到br-local上的 ovn-k8s-gw0，每个node上都有
5. ovn-k8s-mp0 和 ovn-k8s-gw0的设计
5.1 ovn-k8s-mp0 用于提供·出口ip可达性（Egress IP reachability）·
为了允许主机对Kubernetes服务进行访问，来自主机的数据包必须进入OVN才能命中负载平衡器和路由到适当的目的地。通常在访问由OVN 后端pod支持的服务时，可以使用单个接口(ovn-k8s-mp0)，以便进入本地node 交换机，命中负载平衡器，并到达pod endpoint。但是，当服务由 host network pod支持时，就会变得 更加复杂。例如，如果主机访问服务，其中后台endpoint是主机本身，则数据包负载平衡后必须hairpin回主机。还有一些额外的复杂性需要考虑，比如何时host netowrk 点正在使用网卡上的辅助IP。能够满足svc的所有用例 OpenFlow利用OVN-Kubernetse编程流来引导服务流量。
小结： ovn-k8s-mp0 是用来满足ovn网络中所有访问svc的场景的。
- overlay pod 作为svc的后端
- host netowrk pod 作为svc的后端
- 甚至node网卡子接口提供的服务作为svc的后端
