基于OVN的Kubernetes网络架构解析

【编者的话】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来进行控制的。


上图是一个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&A

Q: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,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

你可能感兴趣的:(基于OVN的Kubernetes网络架构解析)