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

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

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

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


5) 场景四:ExternalTrafficPolicy为Local时,Client来自于集群外

此场景包含下面几个子场景,数据链路可以归纳为一种:

A.访问SVC External IP,ExternalTrafficPolicy 为Local时, Client和服务端Pod部署于不同ECS,其中client为集群外。

环境

image.png

 

Deployment为nginx1,分别为三个pod nginx1-76c99b49df-4zsdj和nginx1-76c99b49df-7plsr 部署在 ap-southeast-1.10.0.1.206ECS上,最后一个pod nginx1-76c99b49df-s6z79 部署在其他节点ap-southeast-1.10.0.1.216 上

Service nginx1的ExternalTrafficPlicy 为Local。

image.png内核路由

Pod网络空间和ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述,此处不再果断篇幅描述。

SLB相关配置

从SLB控制台,可以看到SLB后端的虚拟服务器组中只有两个ECS节点ap-southeast-1.10.0.1.216和ap-southeast-1.10.0.1.206。集群内的其他节点,比如 ap-southeast-1.10.0.0.180 并未被加到SLB的后端虚拟服务器组中。虚拟服务器组的IP 为ECS的IP,端口为service里面的nodeport端口32580。

image.png

 

故ExternalTrafficPolicy为Local模式下,只有有Service后端pod所在的ECS节点才会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发,集群内的其他节点不参与SLB的转发。

SLB虚拟服务器组ECS的IPVS规则

从SLB的虚拟服务器组中的两个ECS可以看到,对于nodeip+nodeport的ipvs转发规则是不同。ExternalTrafficPolicy为Local模式下,只有该节点上的护短pod才会被加到该节点的ipvs转发规则中,其他节点上的后端pod不会加进来,这样保证了被SLB转发的链路,只会被转到该节点上的pod,不会转发到其他节点上。

 

node1: ap-southeast-1.10.0.1.206

image.png

 

node1: ap-southeast-1.10.0.1.216

image.png

 

小结

可以访问到目的端

数据链路转发示意图:

image.png

该图示意了只有后端pod所在ECS才会加到SLB后端中,从集群外部访问SVC的externalIP(SLB IP)的情况,可见数据链路只会被转发到虚拟服务器组中的ECS,不会再被转发到集群内其他节点上。

 

内核协议栈示意图:

image.png 

Conntack 表信息

 

Node:

src是集群外部客户端IP,dst是节点IP,dport是SVC中的nodeport。并且期望是由该ECS上的pod 172.23.96.82 来回包给源端。

 image.png

 

● 数据链路:client -> SLB->ECS eth0 +ECS nodeport -> cni0 -> vethxxxxx ->ECS1 Pod1 eth0;

● 数据链路要经过两次内核协议栈,分别是Pod1协议栈,ECS1 OS协议栈;

● ExternalTrafficPolicy为Local模式下,只有有Service后端pod所在的ECS节点才会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发,集群内的其他节点不参与SLB的转发;

 

6) 场景五:ExternalTrafficPolicy为Cluster时,Client来自于集群外

此场景包含下面几个子场景,数据链路可以归纳为一种:

访问SVCExternal IP,ExternalTrafficPolicy 为Cluster时, Client和服务端Pod部署于不同ECS,其中client为集群外。

环境

 image.png

 

Deployment为nginx1,分别为三个pod nginx1-76c99b49df-4zsdj和nginx1-76c99b49df-7plsr 部署在 ap-southeast-1.10.0.1.206ECS上,最后一个pod nginx1-76c99b49df-s6z79 部署在其他节点ap-southeast-1.10.0.1.216 上

Service nginx2的ExternalTrafficPlicy 为Cluster。

 image.png

内核路由

Pod网络空间和ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述,此处不再果断篇幅描述。

SLB相关配置

从SLB控制台,集群内所有节点ap-southeast-1.10.0.0.180、ap-southeast-1.10.0.1.216和ap-southeast-1.10.0.1.206都被加到SLB的虚拟服务器组中。其中虚拟服务器组的IP 为ECS的IP,端口为service里面的nodeport端口30875。

 image.png

 

故ExternalTrafficPolicy为CLuster模式下,集群内所有的ECS节点都会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发。

SLB虚拟服务器组ECS的IPVS规则

从SLB的虚拟服务器组中的可以看到,对于nodeip+nodeport的ipvs转发规则是一致的。ExternalTrafficPolicy为CLuster模式下,所有的service后端pod都会被加到所有节点的ipvs的转发规则中,即使是该节点有后端pod,流量也不一定会被转发到该节点上pod,可能会被转发到其他节点上的后端pod。

 

node1: ap-southeast-1.10.0.1.206 (该节点有后端pod)

image.png

 

node1: ap-southeast-1.10.0.1.216 (该节点有后端pod)

image.png

 

node3: ap-southeast-1.10.0.0.180 (该节无后端pod)

image.png


小结

可以访问到目的端

数据链路转发示意图:

 image.png

 

该图示意了集群内所有ECS都会被加到SLB后端中,从集群外部访问SVC的externalIP(SLB IP)的情况,数据流量可能会被转发到其他节点上。

 

内核协议栈示意图: 

内核协议栈示意图已经在 2.4 场景一中已经做了详细描述,此处不再过多篇幅描述。

 

Conntack 表信息

 

链路1:

ap-southeast-1.10.0.0.180:

此时数据链路对应示意图中的链路1,可以看到数据链路被转到ap-southeast-1.10.0.0.180节点,该节点上并没有service的后端pod,通过conntrack 信息,可以看到:

src是集群外部客户端IP,dst是节点IP,dport是SVC中的nodeport。并且期望是172.23.96.163 来回包给 10.0.0.180。通过前述信息,可以得知172.23.96.163 是nginx1-76c99b49df-7plsrPod,部署在ap-southeast-1.10.0.1.206。

image.png

 

ap-southeast-1.10.0.1.206:

通过此节点conntrack 表,可以看到src是node ap-southeast-1.10.0.0.180,dst是172.23.96.163的80 端口,回包也是直接回给 node ap-southeast-1.10.0.0.180。

image.png 

综上可以看到src变换了多次,故在Cluster 模式下,会存在丢失真实客户端IP的情况。

 

链路2:

src是集群外部客户端IP,dst是节点IP,dport是SVC中的nodeport。并且期望是由该ECS上的pod 172.23.96.82 来回包给172.23.96.65,此地址是SLB集群中的一个地址。

image.png 

数据链路:

● 情景一:client -> SLB->ECS eth0 +ECS nodeport -> cni0 -> vethxxxxx ->ECS1 Pod1 eth0;

● 情景二:client -> SLB->ECS1 eth0 +ECS1 nodeport-> VPC Routing ->ECS2 eth0 +Pod port -> cni0 -> vethxxxxx ->ECS2 Pod1 eth0;

● 数据链路要经过三次内核协议栈,分别是ECS1 OS、ECS2 OS协议栈和Pod协议栈;

● ExternalTrafficPolicy为CLuster模式下,kubernetes所有ECS节点都会被加入到SLB的后端虚拟服务器组中,参与SLB的流量转发,此时会存在数据路在集群内被多个ECS转发的场景,该情况下会丢失真实客户端IP的情况;

 

7) 小结

本节主要聚焦ACK 在Flannel模式下,不同SOP场景下的数据链路转发路径。随着微服务化和云原生化,网络场景日趋复杂,作为kubernetes原生的网络模型——Flannel,不同的访问环境,一共可以分为10个SOP场景。通过深入简出的剖析,可以归纳为5个场景,并对这五个场景的转发链路,技术实现原理,云产品配置等一一梳理并总结,这对我们遇到Flannel架构下的链路抖动、最优化配置,链路原理等提供了初步指引方向。

相关实践学习
通义万相文本绘图与人像美化
本解决方案展示了如何利用自研的通义万相AIGC技术在Web服务中实现先进的图像生成。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
11月前
|
Kubernetes Cloud Native 区块链
Arista cEOS 4.35.0F 发布 - 针对云原生环境设计的容器化网络操作系统
Arista cEOS 4.35.0F 发布 - 针对云原生环境设计的容器化网络操作系统
373 0
|
Cloud Native 安全 网络安全
云计算与网络安全:技术融合与挑战云原生技术在现代软件开发中的应用
【8月更文挑战第28天】在数字时代的浪潮中,云计算和网络安全成为信息技术领域的两大支柱。本文将探讨云计算服务的分类、特点及其面临的安全威胁,分析网络安全的基本概念、重要性以及信息安全的关键要素。同时,文章将深入讨论云计算环境下的网络安全问题,包括数据保护、访问控制和合规性挑战,并提出相应的解决策略和技术措施。最后,通过一个代码示例,展示如何在云计算环境中实现基本的数据加密,以增强信息的安全性。 【8月更文挑战第28天】 随着云计算技术的飞速发展,云原生技术已成为推动软件行业创新的关键力量。本文将深入探讨云原生的核心概念、优势以及如何在现代软件开发中有效利用云原生技术。我们将通过具体案例,展示
|
人工智能 运维 监控
阿里云携手神州灵云打造云内网络性能监测标杆 斩获中国信通院高质量数字化转型十大案例——金保信“云内网络可观测”方案树立云原生运维新范式
2025年,金保信社保卡有限公司联合阿里云与神州灵云申报的《云内网络性能可观测解决方案》入选高质量数字化转型典型案例。该方案基于阿里云飞天企业版,融合云原生引流技术和流量“染色”专利,解决云内运维难题,实现主动预警和精准观测,将故障排查时间从数小时缩短至15分钟,助力企业降本增效,形成可跨行业复制的数字化转型方法论。
903 6
|
Kubernetes Cloud Native 区块链
Arista cEOS 4.30.10M - 针对云原生环境设计的容器化网络操作系统
Arista cEOS 4.30.10M - 针对云原生环境设计的容器化网络操作系统
533 0
|
负载均衡 容灾 Cloud Native
云原生应用网关进阶:阿里云网络ALB Ingress 全面增强
云原生应用网关进阶:阿里云网络ALB Ingress 全面增强
561 6
|
负载均衡 容灾 Cloud Native
云原生应用网关进阶:阿里云网络ALB Ingress 全能增强
在过去半年,ALB Ingress Controller推出了多项高级特性,包括支持AScript自定义脚本、慢启动、连接优雅中断等功能,增强了产品的灵活性和用户体验。此外,还推出了ingress2Albconfig工具,方便用户从Nginx Ingress迁移到ALB Ingress,以及通过Webhook服务实现更智能的配置校验,减少错误配置带来的影响。在容灾部署方面,支持了多集群网关,提高了系统的高可用性和容灾能力。这些改进旨在为用户提供更强大、更安全的云原生网关解决方案。
1718 25
|
Kubernetes Cloud Native 开发者
阿里云网络发布 alibaba-load-balancer-controller v1.2.0:开启云原生网关开源新篇章!敬请探索!
**阿里云发布开源版ALB控制器v1.2.0,对齐商业版ALB Ingress Controller v2.10.0。新版本增强了功能特性,提升了用户体验,并提供了最佳实践。功能更新包括自定义标签、QUIC协议支持、转发规则和安全策略等。此外,还引入了ReadinessGate实现滚动升级时的平滑上线和Prestop钩子确保平滑下线。用户可从GitHub获取开源代码,通过Docker Hub拉取镜像,开始使用alibaba-load-balancer-controller v1.2.0。**
1139 3
阿里云网络发布 alibaba-load-balancer-controller v1.2.0:开启云原生网关开源新篇章!敬请探索!
|
安全 网络安全 数据安全/隐私保护
云原生技术探索:容器化与微服务架构的实践之路网络安全与信息安全:保护数据的关键策略
【8月更文挑战第28天】本文将深入探讨云原生技术的核心概念,包括容器化和微服务架构。我们将通过实际案例和代码示例,展示如何在云平台上实现高效的应用部署和管理。文章不仅提供理论知识,还包含实操指南,帮助开发者理解并应用这些前沿技术。 【8月更文挑战第28天】在数字化时代,网络安全和信息安全是保护个人和企业数据的前线防御。本文将探讨网络安全漏洞的成因、加密技术的应用以及提升安全意识的重要性。文章旨在通过分析网络安全的薄弱环节,介绍如何利用加密技术和提高用户警觉性来构建更为坚固的数据保护屏障。
|
人工智能 运维 Cloud Native
|
Kubernetes Cloud Native 开发者
阿里云网络发布云原生网关 alibaba-load-balancer-controller v1.2.0,持续拥抱开源生态
alibaba-load-balancer-controller开源版本正式推出v1.2.0,能力对齐ALB Ingress Controller商业版v2.10.0。

热门文章

最新文章