1月12日，Kube-OVN 1.9.0 版本正式发布，感谢社区小伙伴们在这段时间来的贡献和支持！

新版本持续对 VPC 的网络能力进行了增强，并且支持基于优先级的 QoS;支持集成 Cilium 策略，监控和 Service 优化;支持 Webhook 校验子网和固定 IP。并且增加了组播性能，非 Service 性能，内存使用等方面优化。全面提升了 Kube-OVN 的稳定性和安全性。欢迎大家安装使用！

VPC能力进一步增强

l  用户自定义 VPC 下策略路由的支持

l  用户自定义 VPC 下四层负载均衡器的支持

l  用户自定义 VPC 下 Vlan 网络的支持

l  支持使用 nodeselector 调度 vpc-nat-gateway pod

l  支持默认 VPC 使用 vpc-nat-gateway

支持 Qos 优先级

在新版本中支持通过 HTB 类型的 QoS 来支持流量的优先级，可以保证优先服务重要业务的流量，这种基于优先级的 QoS 对在线离线混合部署的场景和电信的使用场景会有更好的支持。

支持集成 Cilium 策略,监控和 Service 优化

我们一直希望能够将 ebpf 的一些能力来引入到客户端里面, Kube-OVN 比较擅长上层编排，像 vpc，子网，underlay，还有 QoS，路由这些功能，控制层面的功能比较丰富。经过调研，Cilium 通过 ebpf 来做 policy，service 的实现，它在 datapath 层面上做的监控、安全方面比较好。 

所以我们把这两者的优势结合起来，Kube-OVN 来做控制层面上高级网络概念的抽象，复用 Cilium 通过 ebpf 的安全和监控的能力，两者结合起来组成一个集成方案，这样可以同时享受 Kube-OVN 带来的编排能力和 Cilium 的底层能力。

支持 Webhook 校验子网和固定 IP

新版本重新添加了subnet 校验和固定 IP 的校验，这样可以保证在创建 subnet 或给Pod 加固定 IP 的时候，如果出现冲突或非法格式，会第一时间返回错误请求。相当于在资源创建之初就进行拦截和报错，不会影响对于后期 Pod 的创建，修改起来也比较容易。并且我们计划后期把所有资源都加上校验，这样可能会极大的提升大家的使用体验。

支持 STT tunnel

经过我们调研 OVS，它的内核模块其实是有一个 STT 的类型，隧道模式就是它伪造了一个 TCP 的结构，可以理解为模拟了 TCP 的 header 来进行封包，好处就是外层 TCP 的 header 和内层的 TCP 的 header 都进行有效 offload，就可以把 CPU 的资源节省下来。 如果是在虚拟化的环境或 CPU 比较差的情况下，比较推荐大家用 STT 这种隧道的封装模式，对于 TCP 的吞吐量会有比较明显的提升。 

然后我们针对了几种不同的场景对流表进行了针对性的优化。

组播流量优化

新版本把 OVN 的流表进行优化，比如识别出原地址或目的地址是一个组播的话，那么把中间这些不必要的流表处理掉，就可以保证组播的流量是通过最短的路径到达目的地，从目的地回来的时候，也是保证最短的路径能收到，这样组播的整体性就会有比较大的提升。

这块的优化已经合到 OVN 了，即使不使用 Kube-OVN，大家也可以在 OVN 的新版中体验到。

非 Service 流量优化

还有一个类似的优化是我们对非 service 流量的优化，相当于针对 k8s 做了定制优化。如果知道 K8s 里面 service 的 IP 范围的话，就可以根据目的地址进行判断，如果目的地址是一个非 service 地址段，那么就绕过 lb 的处理，不需要经过其他操作直接送出去就好了。 

但是回来的方向由于没有办法判断究竟是从一个 service 回来的，还是直接回来的流量，所以回程这段路径上的 lb 的操作目前还去除不掉。但只去除这样一段操作，已经会有大概 17%~18% 的延迟的优化。

其他功能改善

l  Pod 支持 VIP

l  Pod 内多网卡可以同属一个子网

l  Underlay 网络支持接入逻辑网关

l  其他 CNI 可作为主网络

l  Networkpolicy 支持附属网卡

l  VM 端口的热迁移 

l  使用jemalloc 优化内存分配

l  开启数据库内存压缩

what's the next？

l  Windows 操作系统支持

l  一个 Namespace 可以绑定多个子网

l  快速上手的内核编译优化方案

l  更多的逻辑流表优化

l  500~1000节点规模支持

问答讨论

问：Qos 的优先是通过 tc 实现的吗？

答：对，其实 Qos 最终是通过 Linux 的 tc 来实现的，但是因为 OVS 有对应的一些接口，所以提了这个。其实不止实现了优先级，我们还实现类似于混沌测试的那种错误注入，还有延迟注入。

问：ebpf 没有对 IPv6 的支持，如果用 Cilium Service ip 怎么支持 IPv6？

答：在我们的方案里如果 Cilium 不支持 IPv6 的 svc 可以退回到使用 OVN 的 lb 或者kube-proxy 来实现 svc

问：和 Cilium 集成的时候，Cilium 管理的网卡是在 br-provider 上还是物理网口上？

答：Cilium 其实不直接管理，我们只使用了 Cilium一部分功能，在我们的集成方案里面它只是做策略和监控的插入，我们还是用 veth 监听流量然后做一些处理。

上一篇：基于Kube-OVN打通OpenStack和K8s网络

下一篇：Kube-OVN:容器网络性能的自我救赎