基于OVN的Kubernetes网络架构解析

 刘梦馨 分布式实验室 

Kubernetes经过了几年的发展，存在着很多的网络方案。然而网络虚拟化在Kubernetes出现前就一直在发展，其中基于OpenVswitch的方案在OpenStack中已经有了很成熟的方案。其中OVN作为OVS的控制器提供了构建分布式虚拟网络的完整控制平面，并已经成为了最新的OpenStack网络标准。我们将OVN的网络架构和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。

网络的概念比较晦涩一些，但是好在大家都对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社区已经有了很多成熟的监控，追踪，排障方案，随着容器的使用场景变多，我认为外围的工具也需要能够很好的支撑这种模式的网络运维问题。

标签：OVS,功能,架构,Kubernetes,网络,DNS,OVN
来源： https://blog.51cto.com/u_15127630/2777464