《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——4. Terway IPVLAN+EBPF 模式架构设计(上)

本文涉及的产品
云服务器 ECS,每月免费额度200元 3个月
云服务器ECS,u1 2核4GB 1个月
简介: 《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——4. Terway IPVLAN+EBPF 模式架构设计(上)

弹性网卡(ENI)支持配置多个辅助IP的功能,单个弹性网卡(ENI)根据实例规格可以分配6-20个辅助IP,ENI多IP模式就是利用了这个辅助IP分配给容器,从而大幅提高了Pod部署的规模和密度。在网络联通的方式上,Terway支持选择Veth pair策略路由和ipvlan l两种方案,Linux在4.2以上的内核中支持了ipvlan的虚拟网络,可以实现单个网卡虚拟出来多个子网卡用不同的IP地址,而Terway便利用了这种虚拟网络类型,将弹性网卡的辅助IP绑定到IPVlan的子网卡上来打通网络,使用这种模式使ENI多IP的网络结构足够简单,性能也相对veth策略路由较好。

 image.png

 

Pod 所使用的CIDR网段和节点的CIDR是同一个网段 

image.png

 

Pod内部可以看到是有一张网卡的,一个是eth0,其中eth0的IP就是Pod的IP,此网卡的MAC地址和控制台上的ENI的MAC地址不一致,同时ECS上有多张 ethx的网卡,说明ENI附属网卡并不是直接挂在到了Pod的网络命名空间。

image.png

image.png

 

Pod内有只有指向eth0的默认路由,说明Pod访问任何地址段都是从eth0为统一的出入口。

image.png

那么Pod是如何ECS OS进行通信呢?在OS层面,我们一看到ipvl_x的网卡,可以看到是附属于eth1的,说明在OS层面会给每个附属网卡创建一个ipvl_x的网卡,用于建立OS和Pod内的连接隧道。

image.png

ECS OS内对于数据流量是怎么判断去哪个容器呢? 通过OS Linux Routing我们可以看到,所有目的是Pod IP的流量都会被转发到Pod对应的ipvl_x虚拟往卡上,到这里为止,ECS OS和Pod的网络命名空间已经建立好完整的出入链路配置了。到目前为止介绍了IPVLAN在网络架构上实现了。image.png

对于eni多IP的实现,这个类似于《Terway ENIIP模式架构原理,TerwayPod是通过daemonset的方式部署在每个节点上的,通过下面命令可以看到每个节点上的TerwayPod。通过terway-cli show factory 命令可以看到节点上的附属ENI数量、MAC地址以及每个ENI上的IP

image.png

 那么对于SVC来说,是如何实现的呢?

 

看过前面 四个系列的朋友,应该知道对于Pod访问SVC,容器是利用各种办法将请求转发到Pod所在的ECS层面,由ECS内的netfilter模块来实现SVC IP的解析,这固然是个好办法,但是由于数据链路需要从Pod的网络命名空间切换到ECS的OS的网络命名空间,中间经过了2次内核协议栈,必然会产生性能损失,如果对高并发和高性能有机制追求,可能并不完全满足客户的需求。那么对于高并发和延迟敏感业务,该如何实现呢?有没有办法让Pod访问SVC直接在Pod的网络命名空间中就实现了后端解析,这样结合IPVLAN这样至实现了一次内核协议栈。

 

在4.19版本内核中,ebpf的出现,很好的实现了这个需求,这里不对ebpf做过多说明,感兴趣的可以访问官方链接,小伙伴们只需要知道ebpf是一种可以安全在内核层面运行的安全沙盒,当触发内核的指定行为,ebpf设定程序会被执行。利用这个特性,我们可以实现在tc层面对访问SVC IP的数据包进行修改。

image.png

例如,同上图,可以看到集群内有一个名为nginx的svc,clusterIP是192.168.27.242,后端pod IP是10.0.3.38. 通过cilium bpf lb list 可以看到在ebpf程序中对于clusterIP 192.168.27.242的访问会被转到10.0.3.38 这个IP上,而Pod内只有一个默认路由。此处说明,IPVLAN+EBPF模式下,如果Pod访问SVC IP,SVCIP在Pod的网络命名空间内就会被ebpf转为某个SVC 后端pod的IP,之后数据链路被发出Pod。也就是说SVCIP只会在Pod内被捕获,在源端ECS,目的端Pod和目的端的Pod所在ECS都无法被捕获到。

 

假如一个SVC后后段有100+Pod,因为ebpf存在,Pod外无法捕获到SVCIP,所在一旦出现网络抖动,对于抓包该抓那个后端IP或该在哪个后端Pod出抓包呢?想一想,是不是一个非常头疼又无解的场景?  目前容器服务和AES共创了ACK Net-Exporter容器网络可观测性工具,可以针对此场景进行持续化的观测和问题判断。

 

故Terway IPVLAN+EBPF 模式总体可以归纳为:

4.2以上内核中支持了ipvlan虚拟网络,可以实现单个网卡虚拟出来多个子网卡用不同IP地址,而Terway便利用了这种虚拟网络类型,将弹性网卡辅助IP绑定到IPVlan子网卡上来打通网络,使用这种模式使ENI多IP网络结构足够简单,性能也相对veth策略路由较好

节点访问pod 需要经过host协议栈,pod和pod 间访问不经过host的协议

IPVLAN+EBPF模式下,如果Pod访问SVC IP,SVCIP在Pod网络命名空间内就会被ebpf转为某个SVC 后端podIP,之后数据链路被发出Pod也就是说SVCIP只会在Pod内被捕获,在源端ECS,目端PodPod所在ECS都无法被捕获到

 

1) Terway IPVLAN+EBPF 模式容器网络数据链路剖析

针对容器网络特点,我们可以将Terway IPVLAN+EBPF模式下的网络链路大体分为以Pod IP对外提供服务和以SVC对外提供服务两个大的SOP场景,进一步细分,可以归纳为12个不同的小的SOP场景。

 image.png

 对这15个场景的数据链路梳理合并,这些场景可以归纳为下面11类典型的场景:

TerwayENI架构下,不同的数据链路访问情况下,可以总结归纳为11类:

 

访问Pod IP同节点访问Pod

访问Pod IP,同节点pod间互访(pod属于同ENI)

访问Pod IP,同节点pod间互访(pod属于不同ENI)

不同节点间Pod之间互访

集群内Pod访问SVC ClusterIP(含Terway版本≥1.2.0,访问ExternalIP),SVC后端Pod和客户端Pod配属同一个ENI

集群内Pod访问SVC ClusterIP(含Terway版本≥1.2.0,访问ExternalIP),SVC后端Pod和客户端Pod配属不同ENI(同ECS)

集群内Pod访问SVC ClusterIP(含Terway版本≥1.2.0,访问ExternalIP),SVC后端Pod和客户端Pod不属于不同ECS

集群内Pod访问SVC ExternalIP(Terway版本≤1.2.0),SVC后端Pod和客户端Pod配属同一个ENI

集群内Pod访问SVC ExternalIP(Terway版本≤1.2.0),SVC后端Pod和客户端Pod配属不同ENI(同ECS)

集群内Pod访问SVC ExternalIP(Terway版本≤1.2.0),SVC后端Pod和客户端Pod部署于不同ECS

集群外访问SVC ExternalIP

 

2) 场景一:访问Pod IP,同节点访问pod

环境

image.png

 

cn-hongkong.10.0.3.15节点上存在 nginx-7d6877d777-j7dqz和10.0.3.38。

内核路由

nginx-7d6877d777-j7dqz IP地址10.0.3.38。该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由。

image.png

image.png

 该容器eth0在ECS OS 内是通过ipvlan隧道的方式和ECS的附属ENI eth1建立的隧道,同时附属ENI eth1还有个虚拟的ipvl_8@eth1 网卡

image.png

 通过OS Linux Routing我们可以看到,所有目的是Pod IP的流量都会被转发到Pod对应的ipvl_x虚拟往卡上,这样就建立完毕ECS和Pod之间的连接隧道了。

image.png

 

小结

可以访问到目

nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包。

image.png

ECS的ipvl_8 可以抓到数据包。

image.png

数据链路转发示意图:

 image.png

不会经过分配给pod附属网卡

整个链路是通过查找路由表进入ipvl_xxx不需要经过ENI

整个请求链路是node -> ipvl_xxx ->ECS1 Pod1

 

3) 场景二:访问Pod IP,同节点pod间互访(pod属于同ENI)

环境

image.png

 cn-hongkong.10.0.3.15节点上存在 nginx-7d6877d777-j7dqz和

centos-6c48766848-znkl8 两个pod,IP分别为10.0.3.38和10.0.3.5

image.png

 通过此节点的terwayPod,我们可以利用 terway-cli show factory的命令看到 这两个IP (10.0.3.5和10.0.3.38)都属于同一个MAC地址00:16:3e:04:08:3a,说明这两个IP属于同一个ENI,进而可以推断出nginx-7d6877d777-j7dqz和centos-6c48766848-znkl8 属于同一个ENI 网卡。

内核路由

centos-6c48766848-znkl8 IP地址10.0.3.5,该容器在宿主机表现的PID是2747933,该容器网络命名空间有指向容器eth0的默认路由。有且只有一条,说明pod访问所有地址都需要通过该默认路由。

image.png

image.png

 nginx-7d6877d777-j7dqz IP地址10.0.3.38。该容器在宿主机表现的PID是329470,该容器网络命名空间有指向容器eth0的默认路由。

image.png

image.png

该容器eth0在ECS OS 内是通过ipvlan隧道的方式和ECS的附属ENI eth1建立的隧道,同时附属ENI eth1还有个虚拟的ipvl_8@eth1 网卡。

image.png

 

小结

可以访问到目

centos-6c48766848-znkl8 netns eth0 可以抓到数据包。

image.png

nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包。

image.png

ipvl_8 网卡并没有捕获到相关的数据流量包。

image.png 数据链路转发示意图:

 image.png

不会经过分配给pod附属网卡。不会经过任何宿主机ECS网络空间中间节点

整个链路不会和请求不会经过pod所分配ENI,直接在OSns中命中Ip rule 被转发到对端pod

整个请求链路是ECS1 Pod1 ->ECS1 Pod2(发生在ECS内部),和IPVS相比,避免了calico网卡设备两次转发,性能是更好


4) 场景三:访问Pod IP,同节点pod间互访(pod属于不同ENI)

环境

image.png cn-hongkong.10.0.3.15节点上存在 nginx-7d6877d777-j7dqz和busybox-d55494495-8t677 两个pod,IP分别为10.0.3.38和10.0.3.22。

image.png

 通过此节点terwayPod我们可以利用 terway-cli show factory命令看到 这两个IP (10.0.3.2210.0.3.38)都属于同一个MAC地址00:16:3e:01:b7:bd00:16:3e:04:08:3a说明这两个IP属于不同ENI,进而可以推断出nginx-7d6877d777-j7dqzbusybox-d55494495-8t677 属于不同ENI 网卡。

内核路由

busybox-d55494495-8t677 IP地10.0.3.22该容器在宿主机表现PID是2956974,该容器网络命名空间有指向容器eth0的默认路由。有且只有一条,说明pod访问所有地址都需要通过该默认路由。

image.png

image.png

nginx-7d6877d777-j7dqz IP地址10.0.3.38。该容器在宿主机表现PID是329470,该容器网络命名空间有指向容器eth0的默认路由。

image.png

image.png

该容器eth0在ECS OS 内是通过ipvlan隧道方式和ECS附属ENI eth1建立隧道,通过mac地址一样可以看到,

nginx-7d6877d777-j7dqzbusybox-d55494495-8t677 分别被分配eth1和eth2。

image.png

小结

可以访问到目

busybox-d55494495-8t677 netns eth0 可以抓到数据包。image.png

 nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包。

image.png 数据链路转发示意图:

image.png

 

不会经过分配给pod附属网卡。不会经过任何宿主机ECS网络空间中间节点

整个链路是需要从客户端pod所属ENI网卡出ECS再从目POD所属ENI网卡进入ECS

整个请求链路是ECS1 Pod1 ->ECS1 eth1 -> VPC ->ECS1 eth2 ->ECS1 Pod2

 

更多精彩内容,欢迎观看:

《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——4. Terway IPVLAN+EBPF 模式架构设计(中):https://developer.aliyun.com/article/1221414?spm=a2c6h.13148508.setting.30.15f94f0euQBp6L

相关实践学习
一小时快速掌握 SQL 语法
本实验带您学习SQL的基础语法,快速入门SQL。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第31天】 随着数字化转型的加速,云原生技术已经成为推动企业IT架构现代化的关键力量。本文深入探讨了云原生架构的核心组件、实施策略以及面临的主要挑战。通过分析容器化、微服务、DevOps和持续集成/持续部署(CI/CD)等关键技术,揭示了如何利用这些技术实现敏捷性、可扩展性和弹性。同时,文章还讨论了企业在采纳云原生实践中可能遇到的安全性、复杂性和文化适应性问题,并提供了解决这些问题的策略和建议。
|
1月前
|
运维 Cloud Native 持续交付
云原生架构的未来演进:打造灵活、高效的企业IT基础
随着数字化转型的不断深入,企业的IT基础设施正经历着从传统架构向云原生架构的根本转变。本文将探讨云原生技术的最新发展趋势,分析其在提高业务敏捷性、降低运维成本以及促进技术创新方面的关键作用。我们将重点讨论如何借助容器化、微服务、DevOps和持续交付等核心技术,构建一个能够适应快速变化市场需求的云原生生态系统。通过实际案例分析,揭示企业在迁移到云原生架构过程中面临的挑战与解决策略,为读者呈现一幅云原生技术赋能企业未来的蓝图。
|
1月前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
随着企业加速其数字化进程,云计算已成为支撑创新和灵活性的基石。本文深入探讨了云原生架构如何为企业提供敏捷性、可扩展性和成本效益,以及它如何成为支持现代应用程序开发和服务交付的核心。我们将分析云原生的关键组件,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps文化,并讨论这些技术如何协同工作以提高企业运营效率和响应市场变化的能力。此外,我们还将审视采用云原生架构的潜在挑战和克服这些挑战的策略。
|
1月前
|
Cloud Native 安全 持续交付
构建未来:云原生架构的演进与实践
【2月更文挑战第30天】 随着数字化转型的深入,企业对于信息技术的需求日益复杂化和动态化。传统的IT架构已难以满足快速迭代、灵活扩展及成本效率的双重要求。云原生技术作为解决这一矛盾的关键途径,通过容器化、微服务、持续集成/持续部署(CI/CD)等手段,实现了应用的快速开发、部署及运维。本文将探讨云原生架构的最新发展,分析其如何助力企业构建更加灵活、高效的业务系统,并结合实际案例,展示云原生转型过程中的最佳实践和面临的挑战。
|
1月前
|
监控 Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【2月更文挑战第30天】 随着企业加速其数字化转型步伐,云原生架构已不仅仅是一种趋势,而是一种必然。本文将探讨云原生技术如何为企业提供必要的敏捷性、可扩展性和弹性,以支持不断变化的市场需求。通过深入分析容器化、微服务和持续集成/持续部署(CI/CD)等关键概念,我们将揭示这些技术如何协同工作,帮助企业实现快速迭代和高效运营。
|
1月前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【2月更文挑战第30天】 随着企业加速其数字化转型步伐,云原生架构作为支撑现代应用开发、部署及运维的先进模式,已成为推动创新与实现敏捷性的关键技术。本文将探讨云原生技术的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)和动态编排,并分析这些技术如何共同作用以支持企业的敏捷运营。通过深入剖析云原生架构的优势及其在不同行业中的应用案例,文章旨在为决策者提供实施云原生解决方案的洞见,以加速其业务增长并优化用户体验。
|
1天前
|
Cloud Native Devops 持续交付
探索云原生架构:为企业数字化转型插上翅膀
【4月更文挑战第26天】 随着企业对敏捷性、可扩展性和成本效率的不断追求,云原生技术正成为推动数字化转型的关键力量。本文深入剖析了云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps实践,探讨它们如何协同工作以支持动态环境。通过分析多个行业案例,我们揭示了云原生实施的最佳实践,并讨论了在采纳云原生过程中面临的挑战及其解决方案。文章旨在为决策者提供一个清晰的云原生技术蓝图,帮助他们构建更加灵活和高效的业务模型。
13 4
|
3天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第24天】 随着企业加速其数字化转型之旅,云原生架构已成为实现敏捷性、可扩展性和持续创新的关键推动力。本文将探讨云原生技术如何助力企业构建灵活的IT环境,支持快速部署新服务,并提高整体业务效率。通过分析微服务、容器化、DevOps和持续集成/持续部署(CI/CD)等关键技术的实践应用,我们将揭示这些元素如何共同塑造出一个响应迅速且高效的企业架构模型。
|
3天前
|
Cloud Native 持续交付 云计算
构筑未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第24天】 随着企业加速其数字化进程,云原生技术已逐渐成为推动创新与维持竞争力的驱动力。本文将探讨云原生架构的核心概念、实施策略以及它如何助力企业在不断变化的市场环境中实现敏捷性和弹性。我们将深入剖析容器化、微服务、持续集成与持续部署(CI/CD)等关键技术,并讨论它们如何共同作用于构建高度可靠、可扩展的系统结构。通过具体案例分析,文章旨在为读者提供如何在组织中采用和优化云原生实践的洞见。
|
6天前
|
Cloud Native API 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第21天】 随着企业加速其数字化转型的步伐,云原生技术已迅速成为推动创新和实现敏捷性的基石。本文深入探讨了云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及声明式API。通过分析这些技术的协同效应,揭示了它们如何共同促进系统的可伸缩性、弹性和维护性,进而支持企业在不断变化的市场环境中保持竞争力。
10 1