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

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——4. Terway IPVLAN+EBPF 模式架构设计(下)

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

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


8) 场景七:集群内Pod访问的SVC ClusterIP,SVC后端Pod和客户端Pod不属于不同ECS

环境

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网卡。

 

通过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

 

内核路由

Pod访问SVC的Cluster IP,而SVC的后端Pod和Pod部署在不同ECS上,此架构类似 2.4 小节中的不同ECS节点上的Pod间互访情况,只不此场景是Pod访问SVC的ClusterIP,要注意此处是访问ClusterIP,如果是访问External IP,那么场景会进一步复杂了,本门的后面几个小节会详细说明。

 

对于 ClusterIP的ebpf转发进行描述,详细信息可以参考 2.5 小节。中的描述,和前面几个小节一样,在任何dev上都无法捕获到客户端访问的SVC的IP。

小结

数据链路转发示意图:

image.png

 

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

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

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

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

 

 

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

环境

此处环境和2.5小节 情况类似,不做过多描述,只是此小节是在terway 版本小于1.2.0 情况下,访问External IP 47.243.139.183

image.png

内核路由

请参考2.5 小节。

 

由于客户端Pod和被访问的SVC的后端Pod同属于同一个ENI,那么在terway 版本小于1.2.0的情况下,访问External IP,实际上数据链路会通过ENI出ECS到External IP的SLB,在被转发到同一个ENI上。四层SLB目前是不支持同一个EI同时作为客户端和服务端,所以会形成回环,详细信息可以参考下面连接:

https://help.aliyun.com/document_detail/97467.html#section-krj-kqf-14s

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

 

小结

数据链路转发示意图:

image.png

 

整个请求链路是ECS1 Pod1 ->ECS1 eth1 -> VPC -> SLB -> 中断

Terway版本小于1.2.0时,集群内访问external IP,会出ECS ENI到SLB,再由SLB转发到ECS ENI上,如果源pod所属ENI和被转发ENI为同一个,将访问不成功,原因是四层SLB会形成回环

解决方案(任何一个):

通过SVC annotation将SLB配置为7层监听

将Terway版本升级之1.2.0以及上,并开启集群内负载均衡Kube-Proxy会短路集群内访问ExternalIP、LoadBalancer流量,即集群内访问这些外部地址,实际流量不会到外部,而会被转为对应后端Endpoint直接访问在Terway IPvlan模式下,Pod访问这些地址流量由Cilium而不是kube-proxy进行处理在Terway v1.2.0之前版本并不支持这种链路短路在Terway v1.2.0版本发布后,新建集群将默认开启该功能,已创建集群不会开启(此处就2.5小节场景)

 

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

环境

此处环境和2.6小节 情况类似,不做过多描述,只是此小节是在terway 版本小于1.2.0 情况下,访问External IP 47.243.139.183

image.png

内核路由

请参考2.6和2.8 小节。

 

由于客户端Pod和被访问的SVC的后端Pod虽然同属于同一个ECS,但是不属于同一个ENI,那么在terway 版本小于1.2.0的情况下,访问External IP,实际上数据链路会通过客户端pod ENI出ECS到External IP的SLB,在被转发到另一个一个ENI上。虽然从外部感知上看 两个客户端Pod和SVC的后端Pod都是在同一个ECS,但是由于属于不同ENI,所以不会形成回环,可以访问成功,此处的结果和2.8 小节完全不同,需要注意

小结

数据链路转发示意图:

 image.png

 

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

Terway版本小于1.2.0时,集群内访问external IP,会出ECS ENI到SLB,再由SLB转发到ECS ENI上,如果源pod所属ENI和被转发ENI为同一个,将访问不成功,原因是四层SLB会形成回环

如果源pod所属ENI和被转发ENI为是同一个节点上不同ENI,可以访问成功

 

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

环境

此处环境和2.6小节 情况类似,不做过多描述,只是此小节是在terway 版本小于1.2.0 情况下,访问External IP 47.243.139.183

image.png

 

内核路由

请参考2.7和2.9 小节。

此处和2.7的架构场景相似,都是客户端Pod和SVC的后端Pod不属于不同的ECS节点,客户端去访问SVC的External IP。只有Terway的版本不同,2.7小节 Terway 版本是≥1.2.0,此小节是<1.2.0,仅仅是Terway 版本和eniconfig的不同,两者访问链路一个会经过SLB,一个则不会经过SLB这一点需要关注。置于不同的原因是因为1.2.0 Terway 版本之后开启集群内负载均衡,对于访问ExternalIP 会被负载到Service网段,具体信息请见 2.8 小节。

 

小结

数据链路转发示意图:

image.png

 

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

Terway版本小于1.2.0时,集群内访问external IP,会出ECS ENI到SLB,再由SLB转发到ECS ENI上,如果源pod所属ENI和被转发ENI为同一个,将访问不成功,原因是四层SLB会形成回环

 

12 场景十一:集群外访问SVC ExternalIP

环境image.png

 cn-hongkong.10.0.3.15节点上存在 nginx-7d6877d777-j7dqz,IP分为10.0.3.34

通过describe svc 可以看到 nginxPod 被加入到了 svc nginx的后端。SVC的CLusterIP是192.168.27.242。

image.png

 

内核路由

在SLB控制台,可以看到 lb-j6cj07oi6uc705nsc1q4m 虚拟服务器组的后端服务器组是两个后端nginxPod的ENI eni-j6cgs979ky3evp81j3n8image.png

 

从集群外部角度看,SLB的后端虚拟服务器组是SVC的后端Pod所属的ENI网卡,内网的IP 地址就是Pod的地址。

 

小结

数据链路转发示意图:

image.png

 

ExternalTrafficPolicy 为Local或Cluster模式下,SLB只会将Pod分配ENI挂在到SLB虚拟服务器组

数据链路:client -> SLB->Pod ENI +Pod Port ->ECS1 Pod1 eth0

 

13) 小结

本篇文章主要聚焦ACK 在Terway IPVLAN+EBPF模式下,不同SOP场景下的数据链路转发路径。伴随着客户对性能的极致追求的需求,在Terway IPVLAN+EBPF相比Terway ENI,有更高的Pod密度;相比Terway ENIIP,有更高的性能,但因此也带了网络链路的复杂性和可观测性带来了调整,此场景可以分为11个SOP场景,并对这11个场景的转发链路,技术实现原理,云产品配置等一一梳理并总结,这对我们遇到Terway IPVLAN架构下的链路抖动、最优化配置,链路原理等提供了初步指引方向。

 

在Terway IPVLAN模式下,利用EBPF和IPVLAN隧道,避免了数据链路在ECS OS内核协议栈的转发,这必然带来了更高的性能,同时也有ENIIP模式一样的多IP共享ENI的方式来保证Pod密度。但是随着业务场景越来越趋于复杂,业务的ACL管控也更加趋于Pod维度去管理,比如需要针对Pod维度进行安全ACL规则设置的需求等。下一系列我们将进入到Terway ENI-Trunking模式的全景解析。

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
24天前
|
人工智能 弹性计算 运维
ACK Edge与IDC:高效容器网络通信新突破
本文介绍如何基于ACK Edge以及高效的容器网络插件管理IDC进行容器化。
|
20天前
|
NoSQL 关系型数据库 MySQL
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
134 56
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
|
1月前
|
安全 Docker 容器
docker的默认网络模式有哪些
Docker 默认网络模式包括:1) bridge:默认模式,各容器分配独立IP,可通过名称或IP通信;2) host:容器与宿主机共享网络命名空间,性能最优但有安全风险;3) none:容器隔离无网络配置,适用于仅需本地通信的场景。
39 6
|
2月前
|
安全 网络安全 数据安全/隐私保护
利用Docker的网络安全功能来保护容器化应用
通过综合运用这些 Docker 网络安全功能和策略,可以有效地保护容器化应用,降低安全风险,确保应用在安全的环境中运行。同时,随着安全威胁的不断变化,还需要持续关注和研究新的网络安全技术和方法,不断完善和强化网络安全保护措施,以适应日益复杂的安全挑战。
50 5
|
2月前
|
Docker 容器
【赵渝强老师】Docker的None网络模式
Docker容器在网络方面实现了逻辑隔离,提供了四种网络模式:bridge、container、host和none。其中,none模式下容器具有独立的网络命名空间,但不包含任何网络配置,仅能通过Local Loopback网卡(localhost或127.0.0.1)进行通信。适用于不希望容器接收任何网络流量或运行无需网络连接的特殊服务。
|
1月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
1月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
2月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
50 3
|
2月前
|
Cloud Native 持续交付 云计算
云原生架构的演进与挑战
随着云计算技术的不断发展,云原生架构已成为企业数字化转型的重要支撑。本文深入探讨了云原生架构的概念、发展历程、核心技术以及面临的挑战,旨在为读者提供一个全面了解云原生架构的视角。通过分析Kubernetes、Docker等关键技术的应用,以及微服务、持续集成/持续部署(CI/CD)等实践案例,本文揭示了云原生架构在提高应用开发效率、降低运维成本、增强系统可扩展性等方面的显著优势。同时,也指出了云原生架构在安全性、复杂性管理等方面所面临的挑战,并提出了相应的解决策略。
|
30天前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####

热门文章

最新文章