共计 6000 个字符，预计需要花费 15 分钟才能阅读完成。
【编者的话】Kubernetes 经过了几年的发展，存在着很多的网络方案。然而网络虚拟化在 Kubernetes 出现前就一直在发展，其中基于 OpenVswitch 的方案在 OpenStack 中已经有了很成熟的方案。其中 OVN 作为 OVS 的控制器提供了构建分布式虚拟网络的完整控制平面，并已经成为了最新的 OpenStack 网络标准。我们将 OVN 的网络架构和 Kubernetes 的容器平台进行结合，将业界成熟的网络架构引入 Kubernetes 大幅增强现有容器网络的能力。Kubernetes 网络的局限性 Kubernetes 提出了很多网络概念，很多开源项目都有自己的实现。然而由于各个网络功能都是在不同的项目中实现，功能和性能也各有千秋，缺乏统一的解决方案，在使用过程中经常会陷入到底该用哪个的抉择中。同时 CNI、DNS、Service 的实现又在不同的项目，一旦网络出现问题，排查也会在多个组件间游走，是一个十分痛苦的过程。
尽管 Kubernetes 提出了很多网络的概念，但是在真实应用中很多人会有这样的感觉：网络这块还是很薄弱，很多功能缺乏，方案也不够灵活。尤其是和搞传统基础设施网络的人沟通会发现，在他们眼里，Kubernetes 的网络还很初级。我们熟悉的 Kubernetes 网络是 CNI、Service、DNS、Ingress、Network Policy 这样的模式。而做 IaaS 的视角完全不同，他们每次提起是 VPC、Subnet、VNIC、Floating IP，在此之上有 DHCP，路由控制，安全组，QoS，负载均衡，域名解析这样的基础网络功能。
从 IaaS 的视角来看，Kubernetes 的网络功能确实比较单薄。经常碰到来自传统网络部门的挑战，诸如子网划分 VLAN 隔离，集群内外网络打通，容器 NAT 设置，带宽动态调节等等。现有的开源网络方案很难完美支持，最简单的一个例子，比如提及容器的固定 IP 功能通常就要上升到意识形态斗争的层面去讨论。这本质上还是 Kubernetes 的网络功能不足，模型也不够灵活导致的。从更高层面来说，Kubernetes 中抽象类一层网络虚拟化的内容，然而网络虚拟化或者 SDN 并不是 Kubernetes 带来的新东西，相关技术已经发展很久。尤其是在 IaaS 领域里已经有着比较成熟且完善的一整套网络方案。
传统网络部门的人都会问，为什么不用 OVS 来做网络方案，很多需求用只要容器网络接入 OVS 网络，剩下事情网络部门自己就知道怎么去做了，都不用我们实现太多额外的功能。也有很多人向我们推荐了 OVN，用这个能很方便地实现这些功能。也正由此我们开始去关注 OVS/OVN 这种之前主要应用于 OpenStack 生态系统的网络工具。下面我就来介绍一下 OVS 和 OVN。OVS 和 OVN 网络方案的能力网络的概念比较晦涩一些，但是好在大家都对 Docker 和 Kubernetes 比较熟悉，可以做个类比。如果说 Docker 是对单机计算资源的虚拟化，那么 OVS 就是对单机网络进行虚拟化的一个工具。它最基本的功能是实现了虚拟交换机，可以把虚拟网卡和虚拟交换机的端口连接，这样一个交换机下的多个网卡网络就打通了，类似 Linux Bridge 的功能。在此之上，OVS 很重要的一点就是支持 OpenFlow，这是一种可编程的流量控制语言，可以方便我们以编程的方式对流量进行控制，例如转发，拒绝，更改包信息，NAT，QoS 等等。此外 OVS 还支持多中网络流量监控的协议，方便我们可视化监控并跟踪整个虚拟网络的流量情况。
但是，OVS 只是一个单机软件，它并没有集群的信息，自己无法了解整个集群的虚拟网络状况，也就无法只通过自己来构建集群规模的虚拟网络。这就好比是单机的 Docker，而 OVN 就相当于是 OVS 的 Kubernetes，它提供了一个集中式的 OVS 控制器。这样可以从集群角度对整个网络设施进行编排。同时 OVN 也是新版 OpenStack 中 Neutron 的后端实现，基本可以认为未来的 OpenStack 网络都是通过 OVN 来进行控制的。01.jpeg
上图是一个 OVN 的架构，从下往上看：
ovs-vswitchd 和 ovsdb-server 可以理解为单机的 Docker 负责单机虚拟网络的真实操作。
ovn-controller 类似于 kubelet，负责和中心控制节点通信获取整个集群的网络信息，并更新本机的流量规则。
Southbound DB 类似于 etcd（不太准确），存储集群视角下的逻辑规则。
Northbound DB 类似 apiserver，提供了一组高层次的网络抽象，这样在真正创建网络资源时无需关心负责的逻辑规则，只需要通过 Northoboud DB 的接口创建对应实体即可。
CMS 可以理解为 OpenStacke 或者 Kubernetes 这样的云平台，而 CMS Plugin 是云平台和 OVN 对接的部分。
下面我们具体介绍一下 OVN 提供的网络抽象，这样大家就会有比较清晰的认知了。
Logical_Switch 最基础的分布式虚拟交换机，这样可以将多台机器上的容器组织在一个二层网络下，看上去就好像所有容器接在一台交换机上。之后可以在上面增加诸如 ACL、LB、QoS、DNS、VLAN 等等二层功能。
Logical_Router 虚拟路由器，提供了交换机之间的路由，虚拟网络和外部网络连接，之后可以在路由器层面增加 DHCP、NAT、Gateway 等路由相关的功能。
Loadbalancer，L2 和 L3 的 Loadbalancer，可以类比公有云上的内部 LB 和外部 LB 的功能。
ACL 基于 L2 到 L4 的所有控制信息进行管控的一组 DSL，可以十分灵活，例如：outport ==“port1”&& ip4 && tcp && tcp.src >= 10000 && tcp.dst <= 1000。
QoS，可以基于和 ACL 同样的 DSL 进行带宽的控制。
NAT，同时提供 DNAT 和 SNAT 的控制方便内外网络通信。
DNS，内置的分布式 DNS，可以在本机直接返回内部 DNS 的请求。
Gateway 控制内部和外部之间的集中式通信。
了解了这些，大家应该就能发现，Kubernetes 目前的网络从功能层面其实只是 OVN 支持的一个子集，基本上所有 Kubernetes 的网络需求都能在 OVN 中找到映射关系，我们简单来看下他们之间的映射。OVN 和 Kubernetes 的结合 Switch/Router -> Kubernetes 基本的东西向互通容器网络。这块 OVN 的能力其实是大大超出，毕竟 OVN 的这套模型是针对多租户进行设计的，而 Kubernetes 现在只需要一个简单的二层网络。
Loadbalancer → ClusterIP 以及 Loadbalancer 类型的 Service，可以取代 kube-proxy 的功能，OVN 本身也可以实现云上 ELB 的功能。
ACL -> Networkpolicy 本质上更灵活因为可以从 L2 控制到 L4 并且 DSL 也支持更多的语法规则。
DNS -> 可以取代 Kube-DNS/CoreDNS，同时由于 OVN 实现的是分布式 DNS，整体的健壮性会比现在的 Kubernetes 方案要好。
可以看到 Kubernetes 的 CNI、kube-proxy、Kube-DNS、NetworkPolicy、Service 等等概念 OVN 都有对应的方案，而且在功能或者稳定性上还有增强。更不要说还有 QoS、NAT、Gateway 等等现在 Kubernetes 中没有的概念。可以看到如果能把 IaaS 领域的网络能力往 Kubernetes 平移，我们还有很多的提升空间。Kubernetes 网络未来增强的方向最后来说说我认为的未来 Kubernetes 网络可能的增强方向。Kubernetes 网络功能和 IaaS 网络功能打平现在的 Kubernetes 网络模型很类似之前公有云上的经典网络，所有用户大二层打通，通过安全策略控制访问。我们现在也都知道公有云多租户不能这么做 VPC 肯定是标配。因此未来 Kubernetes 网络可能也会向着多租户方向前进，在 VPC 的基础上有更多的路由控制、NAT 控制、带宽控制、浮动 IP 等等现在 IaaS 上很常见的功能。性能现有的开源方案其实主要还是依赖原有的 Linux 网络栈，没有针对性的优化。理论上容器的密度比传统虚拟化高，网络压力会更大。OVS 现在有 DPDK 等 Kernel bypass 的 DataPath，绕过 Linux 内核栈来实现低延迟和大吞吐网络。未来随着容器的密度越来越大，我认为会出现这种针对容器架构专门优化的网络方案，而不是依旧依赖 Linux 网络栈。监控和问题排查现有的网络问题排查十分困难，如果所有的数据平面都由一个项目完成，比如 OVN，那么学习成本和排障都会容易一些。此外 OVS 社区已经有了很多成熟的监控，追踪，排障方案，随着容器的使用场景变多，我认为外围的工具也需要能够很好的支撑这种模式的网络运维问题。Q&AQ：OVS 方案与基于三层交换机方案对比，各有什么优缺点？A：OVS 最大的优点在于可编程，灵活性比较好。虚拟网络不用手动插网线，而且有 OpenFlow 加持，可以实现一些普通交换机无法实现的流量控制。物理交换机的主要有点就是性能好，而且比较稳定，不容易出问题。Q：OVN 不支持 ECMP，貌似现在还是 active-standby 机制，你们怎么解决 Gateway 瓶颈问题？A：有几种方式：1. Gateway 用 DPDK 这样的高速 DataPath；2. 多 Gateway，用策略路不同的 IP 段走不同 Gateway，可以分担流量；3. 不使用 OVN 概念的 Gateway，自己做一些手脚从每台宿主机直接出去，也是分担流量降低单点的风险。Q：OVN-Kubernetes 好像只支持每个部署节点一个虚拟网络网段。如何避免 IP 池浪费和不均衡？A：这个其实是这个项目实现的网络模型的一个局限性。在我们的实现里是以 namespace 为粒度划分子网，可以对每个 namespace 进行控制，情况会好很多。Q：OVN 如果有不同的 Chassis，但是相同 IP 就会造成网络异常（比如物理机，VM 装上 OVN，注册到远端后，被重建，后面又注册到远端，但是 Chassis 已经改变），会导致大量节点 Geneve 网络异常。你们怎么解决这个问题？A：暂时没碰到这个问题，但是我们在实现的一个原则就是尽可能保证所有的操作都是幂等的。向这种可能需要在重连前做一个检查，判断是否有过期的数据需要清理，再连接，或者复用旧的连接信息去连接。Q：如何 debug OVN 逻辑拓扑是否配置有问题？A：目前 debug 确实很多情况只能靠眼看，也可以使用 ovn-trace 这个工具可以打印数据包在逻辑流里的链路来排查。Q：OVS 跟 Calico 等有啥区别？A：Calico 主要依赖 Linux 的路由功能做网络打通，OVS 是在软件交换机层面实现网络打通，并提供了更丰富的网络功能。Q：OVS 的封包支持有 STT 和 Geneve，你们选用哪种，为什么？A：其实还支持 VXLAN，我们选的 Geneve。原因比较简单，Geneve 是第一个 OVN 支持的封包协议，而且看了一些评测，据说在搞内核开启 UDP Checksum 的情况下性能会比 VXLAN 要好一些。Q：OVS 如何实现固定容器 IP？A：这个其实 OVS 有对应的设置可以给每个端口设定 IP 和 MACE，这样网卡启动时配置相同的信息就可以了，难点其实是如何控制 OVN 来分配 IP，感觉这个话题可以再开一场分享来讨论了。Q：可以简单介绍下你们准备开源的网络功能吗？A：每个 namespace 和一个 logical_switch 绑定，支持子网分配，支持固定 IP，支持 QoS，支持 NetworkPolicy，内置的 LB，内置的 DNS，大致就是把 OVN 的概念映射到 Kubernetes。Q：想了解一下，如果采用 OVN，是不是意味着使用 OpenStack 平台和 Kubernetes 网络可以直接互通？完成业务在虚拟机和 Pod 之间的全新负载方式？A：是这样的，如果涉及的合理可以做到容器和 VM 使用同一个底层网络基础设施，VM 和容器之间可以 IP 直达，所有的 ACL、LB 都是打通的。Q：直接把 OpenShift OVS 抽出来做 Kubernetes 的网络插件和灵雀云做的这个区别在哪？A：功能上有很多是相同的，因为底层都是 OVS。如果关注 Roadmap 会发现 OpenShift 之后也会采用 OVS 的模式。从架构的角度来看，现在 openshift-multitenant 的实现很类似 Neutron 之前那一套，各种 Agent，之后会统一到 OVN。另一方面 OpenShift 的网络插件绑定的太死了，所以我们决定还是自己抽出来，顺便能实现我们的一些特殊功能，比如固定 IP，子网共享，以及一些网关控制层面的功能。Q：请问 Geneve 和 VXLAN 的区别有哪些？A：Geneve 可以理解为下一代 VXLAN，VXLAN 相对 VLAN 来说头部更长可以支持更多的 VLAN，但是由于是固定长度的封装头，不能任意加控制信息。Geneve 采用变长的封装头，可以加很多自定义的控制信息，方便之后做更复杂的网络管控。Q：Docker CNM 也支持固定 IP，和你说的固定 IP 是一回事吗？另外，基于 OVS 建立的网络是 CNI 还是 CNM 的呢？A：基于 CNI，因为我们依赖 Kubernetes 的模型。不过话说回来我很喜欢 Docker CNM 那套模型，比 CNI 要实用很多。固定 IP 其实只是个功能，各种模型下都可以实现，效果就是可以给 Pod 指定 IP 启动，Workload 下的多个 Pod 实用的是一组固定的地址。Q：目前你们对企业的解决方案里会默认采用这种网络模式么？A：这个方案是我们这几年需求和碰到坑的一个积累吧，现在还不会直接给企业用，我们还需要一些功能的开发和测试，但是之后 Overlay 的场景这个肯定是主推了，主要是取代原来的 Flannel VXLAN 网络。Q：你了解 Contiv 网络方案吗，和贵公司的实现有哪些区别？A：Contiv 是思科做的，也是 OVS 实现的，不过它的实现比较早，自己手动实现了整个控制平面，可以认为自己写了个跟 OVN 类似的东西来控制 OVS。不过看它最近已经很少更新了。用 OVN 能用很少的代码就实现基本相同的功能。Contiv 有个比较独特的功能就是支持 BGP 的网络间通信，这个是 OVN 暂时不支持的。以上内容根据 2019 年 3 月 26 日晚微信群分享内容整理。分享人刘梦馨，灵雀云高级工程师。2014 年加入灵雀云容器团队，长期参与容器调度平台和容器网络架构的产品研发和技术架构演进，参与自研容器网络和容器应用网关。目前主要专注于容器网络功能的拓展和架构优化。DockOne 每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesd，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
