Kube-OVN: 一个非著名K8s CNI 网络插件 | 灵雀云AceCon演讲实录

灵雀云

发布于 2021-11-09 10:57:41

1.2K0

发布于 2021-11-09 10:57:41

近日，由 VMware 联合Intel、PingCAP、EMQ、灵雀云等合作伙伴联合主办的大型开源活动——2021智能云边开源峰会（2021 Open Source AceCon）成功落下帷幕。作为开源技术生态的年度盛会，大会邀请了多位来自开源领域的技术领导者及重要贡献者，分享“云原生、边缘计算、人工智能”三大热门技术趋势及洞察。

灵雀云工程师，Kube-OVN maintainer 刘韬在边缘计算分论坛分享了《Kube-OVN: 一个非著名 K8s CNI 网络插件》主题演讲，下面是演讲视频及实录。

视频回顾

演讲实录

大家好，很荣幸今天给大家介绍Kube-OVN，一个业内非著名但功能很强大的 K8s CNI 组件。今天的演讲主要分为三个部分：1、为何要有Kube-OVN？2、什么是Kube-OVN？3、用户怎么使用Kube-OVN？

为何要有Kube-OVN？

传统的 Kubernetes 网络是一个很乌托邦的结构，Node、Pod、Servers、整个所有组件都是全通的，没有任何阻碍。但在实际使用中无法做到如此互通，用户会有更多的需求，比如Kubernetes网络需要和传统的 Infrastructure 底层连接互联，传统应用比如银行或高保密的应用对于Servers微服务需要固定IP，对于用户来说可能需要多个 VPC 或多网卡，需要多个网络平面来进行划分，最后还可能会有Kubernetes Federation, 多集群网络的互通，还有一些跨云容器的网络的需求。基于以上这些需求开发出的 Kube-OVN，能满足传统 Kubernetes 对于用户无法满足的需求。

什么是 Kube-OVN ？

面向企业场景的容器网络

Kube-OVN 是为了连接 Kubernetes 网络，基于 OVS 来建设的网络组件。因为OVS已经出来十多年了，最早用在 OpenStack 的网络底层，是很成熟的底座。Kube-OVN 用到 Kubernetes 本身的 Operator 的框架来实现控制器，再结合灵雀云企业端多年的商业实践来满足用户需求，同时还利用一些 OVS 社区的生态来保证对 OVS 的性能、功能的要求。大家可以把 Kube-OVN 理解为所有的 Pod 都经过 OVS 来体现互联，OVS 作为每个 Node 上的网络中介可以满足用户的各种需求，像之前说的 VPC、固定IP、还有些 NetworkPolicy，ACL 等需求都可以满足，这都借助了成熟的 OVS 强大的功能来实现。

组件架构

Kube-OVN 的主要组件在上图里是蓝色部分来实现的。Kube-OVN 这个 CNI 是我们跑/opt/cni/，即K8s目录下的一个组件，然后kube-ovn-cniserver 和kube-ovn-controller 是以 deploy 和 daemonset 模式跑在集群中的 Operator ，所有的配置和功能都是通过监听 K8s API Server 的一些 CRD 变化来把我们需要的一些 ip，mac 或 subnet、gw 信息通过 Annotation 注册到对应的 deploy， Node、Pod 上，最后通过 CNI server 把这些组件的 Annotation 写到数据库里，完成整个网络连接。所有的网络组件都是由 Prometheus exporter 来透出各种各样的统计数据，最后通过 Grafana 来展示到前方，当然 Grafana 可以根据用户需求进行调整，这是 Kube-OVN 的组件架构。

Overlay 网络

Kube-OVN 的 Overlay 网络是基于 Geneve 封装的，可以添加各种各样的功能，VPC，ACL，etc，并和现有的物理网络保持独立。从上图可以看到绿色的 Pod 属于单独的一个子网或者是一个VPC，蓝色的 Pod 属于另外一个子网，在这里的 Nod 也单独有一个自己的子网构成，这个子网 Cluster Router 来把它们进行互联。用户可以选择子网之间的连接关系，它的 ACL 和一些需求。对于一个 Pod 来说，它的 IP 地址可以基于整个集群的漂移，可以在任何一个 Node 上进行漂移，那么 Subnet 每个子网可以和 Namespace 绑定，用户可以很方便的通过 Subnet 和 Namespace 的对应关系来管理自己的地址空间，以及 Subnet 与项目的关系。

Kube-OVN 从 Pod 到外网的出网关系大概有两种，一种是分布式的，是从每一个 Node 上自己分单独出去，或者是集中式的我们找一个或者几个Node，专门做一个对外的网关，后一种比较适合现在 EIP 的方式来做，这些方式都可以依托于 OVS 的强大的功能来做一些独立的每个Subnet 自己的网络控制来进行用户自己想做的自定义的策略。这种实现方式都依托于 K8s NetworkPolicy ，都是通用的 API 方式来做的。

Underlay网络

Kube-OVN的Pod可以直接和底层其他的 Infrastructure 物理机、虚拟机来直连，这时候我们和外部的网络是打通的，但是它得提供底层的高性能网络，基本的 VPC 原则依然存在通过颜色来划分 VPC 。在这个例子里示意图 Pod 出来的时候进行 Vlan tag 打标，实际该标签是 OVS 做的，每个 Pod 出来都会进行 Vlan tag 打标，然后通过一个 trunk 接口进入到外部的网络，这个外部网络通过用户自己的网络设备来进行用户自定义的一个网络传输、网络控制的情况，在这个 Underlay 的场景中，一样可以提供固定 IP 和固定 Mac 能力。Kube-OVN 还能提供 Overlay 和 Underlay 共存能力，也就是说前面 Overlay 网络同时也可以产存在 Underlay，Pod 可以选择封装或者不封装来进入外部的用户网络。

容器多网卡管理

在混部情况下，肯定需要多网卡管理。新版本也支持多网卡管理，用户可以选择他们的 Pod 是否可以借用 Overlay 网络或者 Underlay 网络，Pod 可以进入多网卡，我们是利用 Multus Attachment Subnet 来做的。会给 Pod 的 Annotantions 里写入它的网卡需求，然后 Kube-OVN 的 CNI 和 OVN-IPAM 会去监控 Annotations，再去具体配置 Pod 多个网卡，进而让一个 Pod 可以连入集群的多个网络。这种情况也是用户的需求，他们的特殊业务需要多个网络，然后垂直网关或者VNF，还有一些用连数据库的应用会这么做。在这个集群里可以通过 K8s 的Annotations，通过 Kube-OVN 提供的接口来统一管理主网络和附属网络。

容器网络和外部网络打通

有两种方式打通容器网络和外部网络，一种是可在 Node 里通过一个 OVS 的 SNAT 或者直接转入外部的网络，另一种是通过一个单独的 Pod 网关把所有的数据包都转发到该网关上，然后再进行对应的直连或者 NAT 之后再出去。这种场景一般来说适合类似公网那种，在 EIP 有限的情况下，所有的集群数据都通过这几个 EIP 来访问外部的网络。对于 Underlay 方案来说，这样其实更简单，直接通过 Vlan Tag 通过 Trunk 接口，然后外部的物理机进行网络连接。Kube-OVN 还支持和 OpenStack 集群共享同一个 OVN 网络，在这种情况下可以把一个 Pod和一个 KVM 虚拟机连入同一个 VPC ，这种情况下可以把 Pod 和虚拟机的组网能力进一步的提高，对于同时利用容器和虚拟机的用户来说更有价值。

怎么用Kube-OVN？

简单的使用方法

Kube-OVN使用起来很简单，直接把 IP 和 MAC 写入一个 Pod Annotation，这种情况下Pod IP 就会固定，这是一个例子。对于 deploy 来说，可以去Annotation写齐 depolyment 下面对应 Pod 的 IP，然后生成的Pod 会在这个IP 池里去选择一个作为 IP。这个 IP 地址可以在整个集群里漂移，拥有这个 IP 的 Pod 可以启动在任何一个用户自定义的 Node 上。

容器网络安全

对于容器网络安全方面来说，Kube-OVN支持标准的 Kubernetes NetworkPolicy 写法，并且支持每个子网或者每个 Pod 的 ACL 控制都可以做，然后也可以把数据流镜像到另外一个网卡上，抽出来进行安全审计和流量分析，也能通过 OVS 来做动态的 QoS控制来限制双向带宽，保证Pod之间流量优先级的差异化。

容器网络性能

在容器网络性能方面，目前的 OVN 可以做到非常稳定可靠支持 200 节点的 load 数量级，大概 1万左右的Pod。目前为了避免 Iptables 的性能损耗，可以通过流表来做 DNAT，就是 Kube-proxy的功能，还可以通过已有的 DPDK offload 方案，把所有流表的性能损耗卸载到智能网卡或是 DPDK 上来做更高更快的性能加速。

完善的监控体系

Kube-OVN 可以向用户提供比较完善的监控体系，可以在集群里面随时随地监控 OVN 和 OVS的情况，里面有一个基于DaemonSet的 Pod ，随时随地对于每个 Pod 上到其它的 Pod，其它的 Node，其它的 Service，其它的 DNS 都有连通性的监控，还可以从 Prometheus可以看到，一旦出问题，理论上监控系统会比用户先发现这个问题。然后可以把 Trace 和 Tcpdump 集成到一个 kubectl 的一个补丁里面，用户可以随时在 master界面用户界面做简单的 Trace 和 Tcpdump，我们还提供一套性能测试工具用户可以很简单的自动化的去测试他们自己的网络性能、时延、带宽，在测试同时本身的一些火焰图和 CPU 的性能统计。同时我们也提供一个容器网络流量完整镜像，就像刚刚说的 OVS mirror 可以做这种事情，上面说的监控可以集成到 Grafana，用户可以随时看到。下面是一个对应的ovs-monitor的文档的一个例子。

https://github.com/alauda/kube-ovn/blob/master/docs/ovn-ovs-monitor.md

这个例子左边是一个 Trace，可以看到一个数据包从某个端口进来后，它的入口，某一端的出口、然后下一个入口到下一个出口，实际上是多个 Egress 和 Ingress 最后有一个出口，到某一个端口出去或者到某一个网卡出去。右边是Tcpdump 的例子，我们可以在 Node 上，MasterNode 上，直接通过 ko 这个 kubectl 的 plugin 对应某个端口或某个 Pod 来执行 Tcpdump 的包，这是一个比较简单的应用处理方式，用户交互比较轻松。当然这些在 Kubernetes 都可以嵌入进去，用户可以进行直接使用。

社区情况

Kube-OVN 是通过 Apache 2.0 开源的，商业版和社区版功能完全一致。很多社区成员、用户提供了很多很好的 idea 和代码，也欢迎大家加入我们一起打造更好的 Kube-OVN。