Kubernetes 提出了很多网络概念,很多开源项目都有自己的实现。然而由于各个网络功能都是在不同的项目中实现,功能和性能也各有千秋,缺乏统一的解决方案,在使用过程中经常会陷入到底该用哪个的抉择中。同时 cni, dns, service 的实现又在不同的项目,一旦网络出现问题,排查也会在多个组件间游走,是一个十分痛苦的过程。
尽管 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 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 网络可能的增强方向。
现在的 k8s 网络模型很类似之前公有云上的经典网络,所有用户大二层打通,通过安全策略控制访问。我们现在也都知道公有云多租户不能这么做 vpc 肯定是标配。因此未来 k8s 网络可能也会向着多租户方向前进,在 vpc 的基础上有更多的路由控制,nat控制,带宽控制,浮动 IP 等等现在 IaaS 上很常见的功能。
现有的开源方案其实主要还是依赖原有的 linux 网络栈,没有针对性的优化。理论上容器的密度比传统虚拟化高,网络压力会更大。OVS 现在有 DPDK 等 kernel bypass 的 datapath,绕过 Linux 内核栈来实现低延迟和大吞吐网络。未来随着容器的密度越来越大,我认为会出现这种针对容器架构专门优化的网络方案,而不是依旧依赖 linux网络栈。
现有的网络问题排查十分困难,如果所有的数据平面都由一个项目完成,比如 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 暂时不支持的。