本文为 3 月 26 日灵雀云 Kubernetes 专家刘梦馨在 Dockone 社区的主题分享。他从 Kubernetes 网络的局限性、OVS 和 OVN 网络方案的能力、OVN 和 Kubernetes 的结合、Kubernetes 网络增强的未来方向等方面分享了他本人的思考，以及灵雀云在此方面的产品进展。灵雀云近期研发的基于 OVN 的 Kubernetes 网络将很快与大家见面。欢迎各位关注！

来源：我的观点（ID：oilbeater_opinion）

作者：灵雀云刘梦馨

Kubernetes 网络的局限性

尽管 k8s 提出了很多网络的概念，但是在真实应用中很多人会有这样的感觉：网络这块还是很薄弱，很多功能缺乏，方案也不够灵活。尤其是和搞传统基础设施网络的人沟通会发现，在他们眼里，k8s 的网络还很初级。我们熟悉的 k8s 网络是 cni，service，dns，ingress，network policy 这样的模式。而做 IaaS 的视角完全不同，他们每次提起是 vpc，subnet，vnic，floating ip，在此之上有 dhcp，路由控制，安全组，QoS，负载均衡，域名解析这样的基础网络功能。

从 IaaS 的视角来看，k8s 的网络功能确实比较单薄。经常碰到来自传统网络部门的挑战，诸如子网划分 vlan 隔离，集群内外网络打通，容器 NAT 设置，带宽动态调节等等。现有的开源网络方案很难完美支持，最简单的一个例子，比如提及容器的固定 IP 功能通常就要上升到意识形态斗争的层面去讨论。这本质上还是 k8s 的网络功能不足，模型也不够灵活导致的。从更高层面来说，k8s 中抽象类一层网络虚拟化的内容，然而网络虚拟化或者 SDN 并不是 k8s 带来的新东西，相关技术已经发展很久。尤其是在 IaaS 领域里已经有着比较成熟且完善的一整套网络方案。

传统网络部门的人都会问，为什么不用 OVS 来做网络方案，很多需求用只要容器网络接入 ovs 网络，剩下事情网络部门自己就知道怎么去做了，都不用我们实现太多额外的功能。也有很多人向我们推荐了 OVN ，用这个能很方便地实现这些功能。也正由此我们开始去关注 OVS/OVN 这种之前主要应用于 OpenStack 生态系统的网络工具。下面我就来介绍一下 OVS 和 OVN。

OVS 和 OVN 网络方案的能力

网络的概念比较晦涩一些，但是好在大家都对 Docker 和 k8s 比较熟悉，可以做个类比。如果说 Docker 是对单机计算资源的虚拟化，那么 OVS 就是对单机网络进行虚拟化的一个工具。它最基本的功能是实现了虚拟交换机，可以把虚拟网卡和虚拟交换机的端口连接，这样一个交换机下的多个网卡网络就打通了，类似 Linux Bridge 的功能。在此之上，OVS 很重要的一点就是支持 Openflow，这是一种可编程的流量控制语言，可以方便我们以编程的方式对流量进行控制，例如转发，拒绝，更改包信息，NAT，QoS 等等。此外 OVS 还支持多中网络流量监控的协议，方便我们可视化监控并跟踪整个虚拟网络的流量情况。

但是，OVS 只是一个单机软件，它并没有集群的信息，自己无法了解整个集群的虚拟网络状况，也就无法只通过自己来构建集群规模的虚拟网络。这就好比是单机的 Docker，而 OVN 就相当于是 OVS 的 k8s，它提供了一个集中式的 OVS 控制器。这样可以从集群角度对整个网络设施进行编排。同时 OVN 也是新版 OpenStack 中 Neutron 的后端实现，基本可以认为未来的 OpenStack 网络都是通过 OVN 来进行控制的。

上图是一个 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 控制内部和外部之间的集中式通信。

了解了这些，大家应该就能发现，k8s 目前的网络从功能层面其实只是 OVN 支持的一个子集，基本上所有 k8s 的网络需求都能在 OVN 中找到映射关系，我们简单来看下他们之间的映射。

OVN 和 Kubernetes 的结合

Switch/Router -> k8s 基本的东西向互通容器网络。这块 OVN 的能力其实是大大超出，毕竟 OVN 的这套模型是针对多租户进行设计的，而 k8s 现在只需要一个简单的二层网络。

Loadbalancer → ClusterIP 以及 Loadbalancer 类型的 Service，可以取代 kube-proxy 的功能，OVN 本身也可以实现云上 ELB 的功能。

ACL -> Networkpolicy 本质上更灵活因为可以从 L2 控制到 L4 并且 DSL 也支持更多的语法规则。

DNS -> 可以取代 kube-dns/coredns，同时由于 OVN 实现的是分布式 DNS，整体的健壮性会比现在的 k8s 方案要好。

可以看到 k8s 的 cni, kube-proxy, kube-dns, networkpolicy, service 等等概念 OVN 都有对应的方案，而且在功能或者稳定性上还有增强。更不要说还有 QoS, NAT, Gateway 等等现在 k8s 中没有的概念。可以看到如果能把 IaaS 领域的网络能力往 k8s 平移，我们还有很多的提升空间。

Kubernetes 网络未来增强的方向

最后来说说我认为的未来 k8s 网络可能的增强方向。

1. k8s 网络功能和 IaaS 网络功能打平

现在的 k8s 网络模型很类似之前公有云上的经典网络，所有用户大二层打通，通过安全策略控制访问。我们现在也都知道公有云多租户不能这么做 vpc 肯定是标配。因此未来 k8s 网络可能也会向着多租户方向前进，在 vpc 的基础上有更多的路由控制，nat 控制，带宽控制，浮动 IP 等等现在 IaaS 上很常见的功能。

2. 性能

现有的开源方案其实主要还是依赖原有的 linux 网络栈，没有针对性的优化。理论上容器的密度比传统虚拟化高，网络压力会更大。OVS 现在有 DPDK 等 kernel bypass 的 datapath，绕过 Linux 内核栈来实现低延迟和大吞吐网络。未来随着容器的密度越来越大，我认为会出现这种针对容器架构专门优化的网络方案，而不是依旧依赖 linux 网络栈。

3. 监控和问题排查

现有的网络问题排查十分困难，如果所有的数据平面都由一个项目完成，比如 OVN，那么学习成本和排障都会容易一些。此外 OVS 社区已经有了很多成熟的监控，追踪，排障方案，随着容器的使用场景变多，我认为外围的工具也需要能够很好的支撑这种模式的网络运维问题。

今天我要分享的内容基本就结束了，我们灵雀云内部目前使用的基于 ovn 的 kubernetes 网络，四月份会开源出来，感兴趣的同学到时候可以关注一下。

Q&A

Q1：OVS 方案与基于三层交换机方案对比，各有什么优缺点？

A1：OVS 最大的优点在于可编程，灵活性比较好。虚拟网络不用手动插网线，而且有 openflow 加持，可以实现一些普通交换机无法实现的流量控制。物理交换机的主要有点就是性能好，而且比较稳定，不容易出问题。

Q2：OVN 不支持 ecmp，貌似现在还是 active-standby 机制，你们怎么解决 gateway 瓶颈问题？

A2：有几种方式：1. gateway 用 dpdk 这样的高速 datapath；2. 多 gateway，用策略路不同的 ip 段走不同 gateway，可以分担流量；3. 不使用 ovn 概念的 gateway，自己做一些手脚从每台宿主机直接出去，也是分担流量降低单点的风险。

Q3：ovn-k8s 好像只支持每个部署节点一个虚拟网络网段。如何避免 ip 池浪费和不均衡？

A3：这个其实是这个项目实现的网络模型的一个局限性。在我们的实现里是以 namespace 为粒度划分子网，可以对每个 namespace 进行控制，情况会好很多.

Q4：ovn 如果有不同的 chassis，但是相同 ip 就会造成网络异常（比如物理机，vm 装上 ovn，注册到远端后，被重建，后面又注册到远端，但是 chassis 已经改变），会导致大量节点 geneve 网络异常。你们怎么解决这个问题？

A4：暂时没碰到这个问题，但是我们在实现的一个原则就是尽可能保证所有的操作都是幂等的。向这种可能需要在重连前做一个检查，判断是否有过期的数据需要清理，再连接，或者复用旧的连接信息去连接。

Q5：如何 debug ovn 逻辑拓扑是否配置有问题？

A5：目前 debug 确实很多情况只能靠眼看，也可以使用 ovn-trace 这个工具可以打印数据包在逻辑流里的链路来排查.

Q6：ovs 跟 calico 等有啥区别？

A6: calico 主要依赖 linux 的路由功能做网络打通，ovs 是在软件交换机层面实现网络打通，并提供了更丰富的网络功能。

Q7：ovn 的封包支持有 stt 和 geneve，你们选用哪种，为什么？

A7：其实还支持 vxlan，我们选的 geneve。原因比较简单，geneve 是第一个 ovn 支持的封包协议，而且看了一些评测，据说在搞内核开启 udp checksum 的情况下性能会比 vxlan 要好一些。

Q8：ovs 如何实现固定容器 ip？

A8：这个其实 ovs 有对应的设置可以给每个端口设定 ip 和 mac，这样网卡启动时配置相同的信息就可以了，难点其实是如何控制 ovn 来分配 ip，感觉这个话题可以再开一场分享来讨论了。

Q9：可以简单介绍下你们准备开源的网络功能吗？

A9：每个 namespace 和一个 logical_switch 绑定，支持子网分配，支持固定 ip，支持 qos，支持 networkpolicy，内置的 lb，内置的 dns，大致就是把 ovn 的概念映射到 kuberentes。

Q10：想了解一下，如果采用 OVN，是不是意味着使用 Openstack 平台和 k8s 网络可以直接互通？完成业务在虚拟机和 POD 之间的全新负载方式？

A10：是这样的，如果涉及的合理可以做到容器和 vm 使用同一个底层网络基础设施，vm 和容器之间可以 ip 直达，所有的 acl，lb，都是打通的。

Q11：ovs/OVN 是如何集成到 k8s 平台的？是直接以网络插件的方式?类似 calico 或者 OpenShiftSDN 那种？

A11：网络插件的形式，两个 yaml 就可以部署出来。

Q12:直接把 openshift ovs 抽出来做 k8s 的网络插件和灵雀云做的这个区别在哪？

A12：功能上有很多是相同的，因为底层都是 ovs。如果关注 roadmap 会发现 openshift 之后也会采用 ovn 的模式。从架构的角度来看，现在 openshift-multitenant 的实现很类似 neutron 之前那一套，各种 agent，之后会统一到 ovn。另一方面 openshift 的网络插件绑定的太死了，所以我们决定还是自己抽出来，顺便能实现我们的一些特殊功能，比如固定 IP，子网共享，以及一些网关控制层面的功能。

Q13：你们的 ovn 使用版本是多少，集群规模如何？

A13：我们目前是 2.10.1，我们现在规模还比较小，几十台这个规模，主要是内部的一些环境在使用。

Q14:前面说支持 vxlan，貌似 vxlan 携带信息很少，ovn 如何解决 vxlan 携带 metadata 信息少的问题？

A14:这个没有具体关注是如何携带这些信息的，如果使用的是 geneve 支持变长的头部，可以多加很多控制信息。

Q15:请问 geneve 和 vxlan 的区别有哪些？

A15: geneve 可以理解为下一代 vxlan，vxlan 相对 vlan 来说头部更长可以支持更多的 vlan，但是由于是固定长度的封装头，不能任意加控制信息。geneve 采用变长的封装头，可以加很多自定义的控制信息，方便之后做更复杂的网络管控。

Q16:openstack 有个 kuryr-kubernetes 项目，它的目的是通过 neutron 来纳管 pod 网络，可以实现 namespace 对应 network，service 对应 lb，pod 对应 port 等，这个貌似支持的也很好，但不支持多租户，和你们做的 ovn 的方案有类似和不同吧？！如果你们开源了很想试一试！

A16: 之前没有细看这个项目，看描述的话我觉得是很可能用到是相同的方案。多租户这块其实有很多的问题，有的是 k8s 本身设计层面的问题，可能还是一个很长期的事情。开源了我会第一时间通知大家的。

Q17:如果你们开源的话，会以什么形式呈现呢，是在 github 上开源，还是如何？我们如何能获取到你们开源的信息？？

A17: 会在 github 上。欢迎大家关注灵雀云的公众号会有官方通知。

Q18:openstack 现在有个 mangrum 项目，基本上就是让 openstack 跟 k8s 做一些融合，不知道这个跟您讲得这个融合之间有没有类似的地方，以及异同？

A18: 早期关注过这个项目，最近关注的不多了，如果是做融合我觉得大家的方案可能都是大同小异的，可能我们会增加一些我们比较特色的功能（固定 IP，网关控制等等。

Q19: 用 genve 的网络方案有哪些能举几个例子吗？

A19: 我了解的就是 ovs，还有一些特殊的交换机也支持，不过相对来说还是个比较新的协议。

Q20:现在很多公司要么是做 k8s 应用层开发，要么是做 IaaS 层的云平台，不知道你们公司是具体做什么的，为什么会在这么重的两个地方同时发力？

A20：这我得给你问问老板去，我感觉还是需求驱动吧，就比如网络这块，碰到客户成熟了，要求上来了，就不得不从根本的地方去提升我们的能力。

Q21：docker CNM 也支持固定 ip，和你说的固定 ip 是一回事嘛？另外，基于 OVS 建立的网络是 CNI 还是 CNM 的呢？

A21:基于 CNI，因为我们依赖 k8s 的模型。不过话说回来我很喜欢 docker cnm 那套模型，比 cni 要实用很多。固定 IP 其实只是个功能，各种模型下都可以实现，效果就是可以给 pod 指定 ip 启动，workload 下的多个 pod 实用的是一组固定的地址。

Q22: 目前你们对企业的解决方案里会默认采用这种网络模式么？

A22：这个方案是我们这几年需求和碰到坑的一个积累吧，现在还不会直接给企业用，我们还需要一些功能的开发和测试，但是之后 overlay 的场景这个肯定是主推了，主要是取代原来的 flannel vxlan 网络。

Q23:您了解 contiv 网络方案吗，和贵公司的实现有哪些区别？

A23：contiv 是思科做的，也是 ovs 实现的，不过它的实现比较早，自己手动实现了整个控制平面，可以认为自己写了个跟 ovn 类似的东西来控制 ovs。不过看他最近已经很少更新了。用 ovn 能用很少的代码就实现基本相同的功能。contiv 有个比较独特的功能就是支持 bgp 的网络间通信，这个是 ovn 暂时不支持的。

Q24:贵公司招人不，办公地在哪？

A24: 一直在招，研发在北京，深圳，南京都有。欢迎跨领域能给我们带来更多启发的小伙伴。