阿里云基于Cilium的高性能云原生网络

小提示：您能找到这篇{阿里云基于Cilium的高性能云原生网络}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的阿里云基于Cilium的高性能云原生网络内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">Cilium创始人兼CTO Thomas Graf近日撰文《How Ali新闻怎样公布baba Clouduses Cilium for High-Performance Cloud-Native Computing?》，本文翻译自作者的英文博客。感谢Thomas Graf以及其他更多的客户，阿里云容器服务团队随时欢迎听到更多客户反馈。

< ">

< font-size: 16px;">近期，阿里云团队在SIG Cloud-Provider-Alibaba的会议上介绍了阿里云容器服务的新的高性能容器网络方案并且发布了一篇博客介绍。你知道吗，这个方案基于Cilium&eBPF来实现。在此之前，Google的GKE和Anthos也宣布基于Cilium+eBPF实现了新的容器网络数据面V2方案。但阿里云的方案会有所不同，阿里云采用Terway IPVLAN+Cilium的eBPF结合的方式，文章下面我们会详细分析Terway CNI(阿里云的CNI插件)的细节实现以及在博客中的测试数据。

< font-size: 16px;">和其他云厂商一样，阿里云也提供了ENI(弹性网卡)的产品来暴露底层IAAS层的SDN(软件定义网络)的能力。对于K8S的Pod来说，基于它可以实现云原生的虚拟化网络，而不需要再对容器网络再做一层虚拟化来降低性能的损耗以及减少网络复杂度。

< font-size: 16px;">云厂商的IAAS层网络已经具备虚拟化和SDN的能力，如果底层虚拟化网络的能力直接给Pods去使用，将能显著降低性能的损耗。

< font-size: 16px;">对于阿里云，容器网络模型如下图所示：

< font-size: 16px;">

< font-size: 16px;">(源自:https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590)

< font-size: 16px;">为了实现这个模型，CNI层面直接与阿里云的API交互来申请Pod所需的底层ENI网络资源。阿里云自研了Terway的CNI插件来实现这样的模型。在阿里云官方的博客中有详细的内部实现的介绍和遇到的挑战。这里我们重点关注在他们如何使用IPVLAN和eBPF来提升Kubernetes的Service和NetworkPolicy的性能和扩展性。

< font-size: 16px;">使用IPVLAN来实现更好的网络可扩展性和性能

< font-size: 16px;">单个ENI可以给Pod独占或者给多个Pod去共享。当ENI被多个Pod共享时，就需要对包做一些路由决策来确保Pod的流量路由到其对应的ENI上面。使用共享ENI的方式，一个ENI可以虚拟化出10-20个IP，从而可以大大增加节点上的Pod的部署密度，但是缺点是需要引入bridge或者策略路由带来额外的性能开销。后面的性能对比中就能看到具体的开销。

< font-size: 16px;">为了提升共享ENI的性能，IPVLAN就是一个很好的选择，IPVLAN可以将ENI很轻量的虚拟化出多个子接口来连接多个Pod到单个ENI上面。Terway的CNI通过IPVLAN来降低共享ENI的开销，并且结合Cilium在IPVLAN的网络模式下提供了高效的NetworkPolicy和Service的实现。并且将实现向Cilium官方提了pull request.

< font-size: 16px;">

< font-size: 16px;">(源自:https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590)

< font-size: 16px;">下面是不同模式的性能对比，其中还包含了基于云原生的ENI网络与基于overlay的Flannel的性能优势。

< font-size: 16px;">

< font-size: 16px;">(源自:https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590)

< font-size: 16px;">你不一定要选择其中一个模型，可以根据需要对高性能的选择调度到独占ENI，对于其他的Pod使用共享ENI的模式。

< font-size: 16px;">**使用eBPF来解决Kubernetes Service和NetworkPolicy的扩展性问题**很长一段时间，Kubernetes的标准的kube-proxy的实现是采用iptables模式宣传海报多少钱，由于iptables的顺序匹配，导致这种解决方案的扩展性非常受限。

< font-size: 16px;">

< font-size: 16px;">(源自:https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590)

< font-size: 16px;">可以看到当服务数量增加到一定阈值后，延迟就会大幅增加。更严重的是，由于服务表项在iptables规则链中匹配的顺序不同，会导致服务访问的首包的延迟会随机的变差。

< font-size: 16px;">基于这些原因，所以阿里云才会基于eBPF来优化Kubernetes的可扩展性。

< font-size: 16px;">效果怎么样呢？下面是阿里云团队测试的性能对比。基于eBPF的方案的网络的性能和可扩展性优于kube-proxy的iptables和IPVS模式：

< font-size: 16px;">

< font-size: 16px;">(源自:https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590)

< font-size: 16px;">通过eBPF简化链路，性能显著提升，相对iptables模式提升了32%，相对IPVS模式提升62%。

< font-size: 16px;">与Kubernetes Server类似，基于eBPF同样可以优化Kubernetes的NetworkPolicy。

< font-size: 16px;">

< font-size: 16px;">(源自:https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590)

< font-size: 16px;">框框中的"BPF-agent"就是独立于Terway CNI之外运行的Cilium的agent，用于提供Kubernetes的Service和NetworkPolicy实现：

< font-size: 16px;">我们使用Cilium作为节点上的BPF-agent去配置容器网卡的BPF规则，已贡献Terway相关适配：https://github.com/cilium/cilium/pull/10251

< font-size: 16px;">(源自:https://www.alibabacloud.com/blog/how-does-alibaba-cloud-build-high-performance-cloud-native-pod-networks-in-production-environments_596590)

< font-size: 16px;">遗憾的是，在这一篇文章中阿里云没有提供最终的优化的对比。Cilium团队早期做过C实行精准营销ilium在IPVLAN和veth模式的对比博客，可以作为粗略的参考。总结我们非常高兴和欢迎阿里云加入和贡献到Cilium社区，如果需要了解更多可以参考如下内容：Cilium Overview Cilium GitHub How Does Alibaba Cloud Build High-Performance Cloud-Native Pod Networks in Production Environments?What is eBPF?

< font-size: 16px;">作者：Thomas Graf Cilium的联合创始人和CTO以及Isovalent(Cilium背后的公司)的联合创始人。在此之前，他在Red Hat和思科从事Linux内核和中断开源项目的研发工作。