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

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

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

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


5) 场景四:不同节点间Pod之间互访

环境

image.png cn-hongkong.10.0.3.15节点上存在 nginx-7d6877d777-j7dqz,IP分为10.0.3.38。

cn-hongkong.10.0.3.93节点上存在 centos-6c48766848-dz8hz,IP分为10.0.3.127

image.png

 通过此节点的terwayPod,我们可以利用 terway-cli show factory的命令看到 nginx-7d6877d777-j7dqz IP 10.0.3.5 属于cn-hongkong.10.0.3.15 上的MAC地址为00:16:3e:04:08:3a的ENI网卡。

image.png

 通过此节点的terwayPod,我们可以利用 terway-cli show factory的命令看到 centos-6c48766848-dz8hz IP  10.0.3.127 属于cn-hongkong.10.0.3.93 上的MAC地址为00:16:3e:02:20:f5的ENI网卡。

内核路由

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

image.png

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

image.pngimage.png

ECS OS 内是通过ipvlan隧道的方式和ECS的附属ENI eth1建立的隧道,通过mac地址一样可以看到两个pod 分配的ENI地址centos-6c48766848-dz8hzimage.png

nginx-7d6877d777-j7dqz

image.png

 

小结

可以访问到目

 

此处不再对抓包进行展示,从客户端角度,数据流可以在centos-6c48766848-dz8hz的网络命名空间 eth0,以及 此pod所部署的ECS 对应的ENI eth1上可以被捕获到;从服务端角度,数据流可以在nginx-7d6877d777-j7dqz的网络命名空间 eth0,以及 此pod所部署的ECS对应的ENI eth1上可以被捕获到。

 

数据链路转发示意图:

 image.png

 

不会经过任何宿主机ECS网络空间中间节点

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

整个请求链路是ECS1 Pod1 ->ECS1 ethx -> VPC ->ECS2 ethy ->ECS2 Pod2

 

6) 场景五:集群内Pod访问的SVC ClusterIP(含Terway版本≥1.2.0,访问ExternalIP),SVC后端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 网卡。

 

通过describe svc 可以看到 nginxPod 被加入到了 svc nginx的后端。SVC的CLusterIP是192.168.27.242。如果是集群内访问External IP,对于 Terway 版本≥ 1.20 来说,集群内访问SVC的ClusterIP或External IP,整个链路架构是一致的,此小节不在针对External IP单独说明,统一用ClusterIP作为示例(Terway版本< 1.20 情况下,访问External IP,会在后续小节说明)。

image.png

内核路由

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

 在ACK中,是利用cilium去调用ebpf的能力,可以通过下面的命令可以看到 nginx-7d6877d777-j7dqz和centos-6c48766848-znkl8 identity ID 分别是634和1592

image.png

 通过centos-6c48766848-znkl8Pod,可以找到此pod所在的ECS的TerwayPod为terway-eniip-6cfv9,在TerwayPod 中运行下面的cilium bpf lb list | grep -A5 192.168.27.242命令可以看到 ebpf中对于CLusterIP 192.168.27.242:80记录的后端是10.0.3.38:80。这上述的一切都是通过EBPF记录到了源端Pod centos-6c48766848-znkl8Pod的tc中。

 image.png

image.png

 

通过以上,可以理论推断出,如果集群内pod访问 SVCCLusterIP or External IP地址(Terway ≥ 1.20)数据流会在pod的网络命名空间内就被转化为相应SVC后端Pod IP后,再被从Pod网络命名空间eth0 发出pod,进入到pod所在ECS,然后通过IPVLAN隧道,转发到同ECS或通过相应ENI出ECS也就是说,我们如果抓包,不管在pod内抓包还是在ECS抓包,都无法捕获到SVCIP,只能捕获到Pod IP

 

EBPF技术让集群内访问避开了ECS OS内部内核协议栈和减少了部分pod内核协议栈,大大提高了网络性能和Pod密度,带来了不弱于单独ENI网络性能,但是此方式会对我们观测带来巨大改变和影响

 

试想一下,如果您集群内存在互相调用情况,这个调用IP 是SVCIP,加入此SVC后端所引用Pod有几十上百个源端pod调用时候出现问题,一般情况下报错‘connect to  failed’ 等类似信息,传统抓包手段是在源端Pod内,目Pod,ECS上等进行抓包,筛选 SVC IP 来串起来不同包之间同一个数据流,可是ebpf情况下由于上述技术实现,造成无法捕获SVC IP,是不是对偶发抖动情况下观测带来了巨大挑战呢?

 

小结

可以访问到目

 

从客户端Pod centos-6c48766848-znkl8 访问SVC,我们可以看到访问成功

image.png

客户端的centos-6c48766848-znkl8 网络命名空间内eth0 抓包,抓包地址是目的SVC的IP和SVC的后端POD IP。可以看到只能抓到SVC 后端Pod IP,无法捕获到SVC IP

image.png

 目的端SVC的后端POD nginx-7d6877d777-zp5jg 网络命名空间 eth0 抓包,抓包地址是目的SVC的IP和Pod IP。可以看到只能抓到客户端Pod IP

image.png

 

cilium 提供了一个monitor的功能,我们使用cilium monitor --related-to ,可以看到,源端POD IP 访问SVCIP 192.168.27.242,之后被解析到SVC的后端POD IP 10.0.3.38。说明SVC IP直接在tc层做了转发,这也解释了为什么抓包无法抓到SVC IP,因为抓包是在netdev上抓的,此时已经过了协议栈和tc。

image.png

 

后续小节如果涉及SVC IP的访问,如有类似,不再做详细的抓包展示。

数据链路转发示意图:

image.png

 

不会经过任何宿主机ECS网络空间中间节点

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

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

ECS1 Pod1eth0网卡无法捕捉到 SVC IP,SVC IP 在Pod网络命名空间内已经通过ebpf转换成了SVC后端PodIP

 

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

环境

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.22和10.0.3.38)都属于同一个MAC地址00:16:3e:01:b7:bd和00:16:3e:04:08:3a,说明这两个IP属于不同ENI,进而可以推断出nginx-7d6877d777-j7dqz和busybox-d55494495-8t677 属于不同ENI 网卡。通过describe svc 可以看到 nginxPod 被加入到了 svc nginx的后端。

 

SVC的CLusterIP是192.168.27.242如果是集群内访问External IP,对于 Terway 版本≥ 1.20 来说,集群内访问SVC的ClusterIP或External IP,整个链路架构是一致的,此小节不在针对External IP单独说明,统一用ClusterIP作为示例(Terway版本< 1.20 情况下,访问External IP,会在后续小节说明)。

image.png 

内核路由

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

image.png

image.png

image.png

image.png

image.png

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

image.png

 在ACK中,是利用cilium去调用ebpf的能力,可以通过下面的命令可以看到 nginx-7d6877d777-j7dqz和busybox-d55494495-8t677 identity ID 分别是634和3681

image.png

 通过busybox-d55494495-8t677Pod,可以找到此pod所在的ECS的TerwayPod为terway-eniip-6cfv9,在TerwayPod 中运行下面的cilium bpf lb list | grep -A5 192.168.27.242 命令可以看到 ebpf中对于CLusterIP 192.168.27.242:80 记录的后端是10.0.3.38:80。这上述的一切都是通过EBPF 记录到了源端Pod centos-6c48766848-znkl8Pod的tc中。

image.png

image.png 

这里不再过多对于svc ClusterIP的ebpf转发进行描述,详细信息可以参考 2.5 小节。中的描述,从上述描述情况,可以得知被访问的SVC的IP 在 客户端 busybox的网络命名空间中已经被ebpf转为svc的后端pod的IP,在任何dev上都无法捕获到客户端访问的SVC的IP。故此场景和2.3 小节的网络架构非常类似,只是在客户端内会由cilium ebpf转发的动作

 

小结

数据链路转发示意图:

image.png

 

不会经过任何宿主机ECS网络空间中间节点

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

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

在客户端/服务端Pod内或者ECSENI网卡无法捕捉到 SVC IP,SVC IP 在 客户端Pod网络命名空间内已经通过ebpf转换成了SVC后端PodIP

 

https://help.aliyun.com/document_detail/197320.htm

https://help.aliyun.com/document_detail/113090.html#p-lim-520-w07

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

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

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
20天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
68 2
|
18天前
|
运维 Cloud Native 虚拟化
一文吃透云原生 Docker 容器,建议收藏!
本文深入解析云原生Docker容器技术,涵盖容器与Docker的概念、优势、架构设计及应用场景等,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
一文吃透云原生 Docker 容器,建议收藏!
|
20天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
25天前
|
人工智能 云计算 网络架构
阿里云引领智算集群网络架构的新一轮变革
11月8日~10日在江苏张家港召开的CCF ChinaNet(即中国网络大会)上,众多院士、教授和业界技术领袖齐聚一堂,畅谈网络未来的发展方向,聚焦智算集群网络的创新变革。
阿里云引领智算集群网络架构的新一轮变革
|
14天前
|
运维 Cloud Native 云计算
云原生之旅:Docker容器化实战
本文将带你走进云原生的世界,深入理解Docker技术如何改变应用部署与运维。我们将通过实际案例,展示如何利用Docker简化开发流程,提升应用的可移植性和伸缩性。文章不仅介绍基础概念,还提供操作指南和最佳实践,帮助你快速上手Docker,开启云原生的第一步。
|
18天前
|
Cloud Native API 持续交付
云原生之旅:从容器到微服务的演进之路
【10月更文挑战第39天】在这篇文章中,我们将一起探索云原生技术的奥秘。通过浅显易懂的语言和生动的比喻,我们将了解云原生技术如何改变软件开发的世界。文章将带领读者从容器的基本概念出发,逐步深入到微服务架构的实践,揭示这些技术如何助力现代应用的快速迭代与可靠部署。准备好,让我们启程进入云原生的精彩世界吧!
|
22天前
|
Kubernetes Cloud Native Ubuntu
庆祝 .NET 9 正式版发布与 Dapr 从 CNCF 毕业:构建高效云原生应用的最佳实践
2024年11月13日,.NET 9 正式版发布,Dapr 从 CNCF 毕业,标志着云原生技术的成熟。本文介绍如何使用 .NET 9 Aspire、Dapr 1.14.4、Kubernetes 1.31.0/Containerd 1.7.14、Ubuntu Server 24.04 LTS 和 Podman 5.3.0-rc3 构建高效、可靠的云原生应用。涵盖环境准备、应用开发、Dapr 集成、容器化和 Kubernetes 部署等内容。
46 5
|
24天前
|
人工智能 运维 网络架构
阿里云引领智算集群网络架构的新一轮变革
11月8日至10日,CCF ChinaNet(中国网络大会)在江苏张家港召开,众多院士、教授和技术领袖共聚一堂,探讨网络未来发展方向。阿里云研发副总裁蔡德忠发表主题演讲,展望智算技术发展趋势,提出智算网络架构变革的新思路,发布高通量以太网协议和ENode+超节点系统规划,引起广泛关注。阿里云HPN7.0引领智算以太网生态蓬勃发展,成为业界标杆。未来,X10规模的智算集群将面临新的挑战,Ethernet将成为主流方案,推动Scale up与Scale out的融合架构,提升整体系统性能。
|
21天前
|
Kubernetes Cloud Native Docker
云原生技术探索:容器化与微服务的实践之道
【10月更文挑战第36天】在云计算的浪潮中,云原生技术以其高效、灵活和可靠的特性成为企业数字化转型的重要推手。本文将深入探讨云原生的两大核心概念——容器化与微服务架构,并通过实际代码示例,揭示如何通过Docker和Kubernetes实现服务的快速部署和管理。我们将从基础概念入手,逐步引导读者理解并实践云原生技术,最终掌握如何构建和维护一个高效、可扩展的云原生应用。
|
28天前
|
Kubernetes Cloud Native 微服务
云原生之旅:从容器到微服务
【10月更文挑战第29天】在这篇文章中,我们将一起探索云原生的奥秘。云原生不仅仅是一种技术,更是一种文化和方法论。我们将从容器技术开始,逐步深入到微服务架构,最后探讨如何在云平台上实现高效的服务部署和管理。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的见解和实用的技能。让我们一起踏上这段激动人心的云原生之旅吧!

热门文章

最新文章