Underlay 网络支持
默认情况下 OVN 使用 Geneve 对跨主机流量进行封装，在基础设施之上抽象出一层虚拟的 overlay 网络。对于希望容器网络直接使用物理网络地址段情况，可以将 Kube-OVN 工作在 Underlay 模式，可以直接给容器分配物理网络中的地址资源，达到更好的性能以及和物理网络的连通性。
该模式下 Kube-OVN 网络表现和 Macvlan 类似，但相比 Macvlan 提供了地址管理，固定IP，服务发现，网络策略和 QoS 等功能。但由于该模式下容器网络直接使用物理网络资源进行包转发，Geneve 模式下的 SNAT/EIP， 分布式网关/集中式网关等 L3 功能无法使用。
Kube-OVN 的 Underlay 模式和 Macvlan 工作模式十分类似，在功能和性能上主要有以下几个区别：
- 由于 Macvlan 的内核路径更短，并且不需要 OVS 对数据包进行处理，Macvlan 在吞吐量和延迟性能指标上表现会更好。
- Kube-OVN 通过流表提供了 arp-proxy 功能，可以缓解大规模网络下的 arp 广播风暴风险
- 由于 Macvlan 工作在内核底层，会绕过宿主机的 netfilter，Service 和 NetworkPolicy 功能需要额外开发。Kube-OVN 通过 OVS 流表提供了 Service 和 NetworkPolicy 的能力
在 Underlay 模式下， OVS 将会桥接一块物理网卡到 OVS 内，并将数据包直接通过该物理网卡对外发送，L2/L3 层面的转发能力需要依赖底层网络设备。需要预先在底层网络设备配置对应的网关、Vlan 和安全策略等配置。
- 对于 OpenStack 的 VM 环境，需要将对应网络端口的
PortSecurity关闭 - 对于 VMware 的 vswtich 网络，需要将
MAC Address Changes,Forged Transmits和Promiscuous Mode Operation设置为allow - 共有云，例如 AWS、GCE、阿里云等由于不支持用户自定义 Mac 无法支持 Underlay 模式网络
- Kube-OVN 启动容器时会通过 icmp 协议检查网关的连通性，底层网关需要能够响应 icmp 请求
- 对于 Service 访问流量，Pod 会将数据包首先发送至网关，网关需要有能将数据包转发会本网段的能力
对于管理网和容器网使用同一个网卡的情况下，Kube-OVN 会将网卡的 Mac 地址、IP 地址、路由以及 MTU 将转移或复制至对应的 OVS Bridge，以支持单网卡部署 Underlay 网络。OVS Bridge 名称格式为 br-PROVIDER_NAME，PROVIDER_NAME 为 Provider 网络名称（默认为 provider）。
在 1.7.0 及之前支持 Underlay 的版本中，使用 Underlay 网络需要在部署时指定网络模式为 vlan 或 hybrid，并配置其它相关参数。
从 1.7.1 版本开始，Kube-OVN 内置混合模式支持，支持在同一个集群中动态创建/删除 Overlay 和 Underlay 网络。部署时指定的网络模式及相关参数只在默认子网中生效，网络模式不再支持 hybrid 选项。
- 下载安装脚本
wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.8/dist/images/install.sh- 修改脚本中相应配置
NETWORK_TYPE 设置为 vlan
VLAN_INTERFACE_NAME 设置为宿主机上承担容器流量的网卡，例如 eth1
VLAN_ID 设置为 0
POD_CIDR 设置为物理网络 CIDR， 例如 192.168.1.0/24
POD_GATEWAY 设置为物理网络网关，例如192.168.1.1
EXCLUDE_IPS 排除范围，避免容器网段和物理网络已用 IP 冲突，例如 192.168.1.1..192.168.1.100- 运行安装脚本
bash install.sh创建如下 ProviderNetwork 并应用:
apiVersion: kubeovn.io/v1
kind: ProviderNetwork
metadata:
name: net1
spec:
defaultInterface: eth1
customInterfaces:
- interface: eth2
nodes:
- node1
excludeNodes:
- node2注意：ProviderNetwork 资源名称的长度不得超过 12。
defaultInterface 为默认使用的物理网卡名称；customInterfaces 为可选项，可针对特定节点指定需要桥接的物理网卡；excludeNodes 也是可选项，用于指定不桥接物理网卡的节点。
ProviderNetwork 创建成功后，各节点（除 excludeNodes 外）中会创建名为 br-net1（格式为 br-NAME）的 OVS 网桥，并将指定的物理网卡桥接至此网桥。
excludeNodes 中的节点会被添加 net1.provider-network.ovn.kubernetes.io/exclude=true 标签，其它节点会被添加如下标签：
| Key | Value | 描述 |
|---|---|---|
| net1.provider-network.ovn.kubernetes.io/ready | true | 节点中的桥接工作已完成，ProviderNetwork 在节点中可用 |
| net1.provider-network.ovn.kubernetes.io/interface | eth1 | 节点中被桥接的物理网卡的名称 |
| net1.provider-network.ovn.kubernetes.io/mtu | 1500 | 节点中被桥接的物理网卡的 MTU |
如果物理网卡上已经配置了 IP，则 IP 地址和网卡上的路由会被转移至 OVS 网桥。
创建如下 VLAN 并应用：
apiVersion: kubeovn.io/v1
kind: Vlan
metadata:
name: vlan1
spec:
id: 0
provider: net1id 为 VLAN ID/Tag，provider 为需要使用的 ProviderNetwork 的名称。多个 VLAN 可以引用同一个 ProviderNetwork。
示例如下：
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
name: subnet1
spec:
cidrBlock: 172.17.0.0/16
gateway: 172.17.0.1
vlan: vlan1将 vlan 的值指定为需要使用的 VLAN 名称即可。多个 Subnet 可以引用同一个 VLAN。
可按正常容器创建方式进行创建，查看容器 IP 是否在规定范围内，以及容器是否可以和物理网络互通。
如有固定 IP 需求，可参考 Pod 固定IP 和 Mac
内部逻辑交换机直接交换数据包，不进入外部物理网络。
数据包经由物理网卡进入外部物理交换机，由物理交换机进行交换。
数据包经由物理网卡进入外部物理网络，由物理交换机及路由器进行交换和路由转发。
数据包经由物理网卡进入外部物理网络，由物理交换机及路由器进行交换和路由转发。
数据包经由物理网卡进入外部物理网络，由物理交换机及路由器进行交换和路由转发。
Kube-OVN 为每个 Kubernetes Service 在每个子网的逻辑交换机上配置了负载均衡。当 Pod 通过访问 Service IP 访问其它 Pod 时，会构造一个目的地址为 Service IP、目的 MAC 地址为网关 MAC 地址的网络包。网络包进入逻辑交换机后，负载均衡会对网络包进行拦截和 DNAT 处理，将目的 IP 和端口修改为 Service 对应的某个 Endpoint 的 IP 和端口。由于逻辑交换机并未修改网络包的二层目的 MAC 地址，网络包在进入物理交换机后仍然会送到物理网关，此时需要物理网关对网络包进行转发。
