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

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

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

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

Service的ExternalTrafficPolicy是Local

SVC nginx CLusterIP是192.168.2.115,ExternalIP是10.0.3.62。后端是10.0.1.104和10.0.3.58

image.png

cn-hongkong.10.0.1.82

对于SVC的ClusterIP,可以看到SVC的后端两个Pod都会被加到IPVS的转发规则。

image.png

对于SVC的ExternalIP,可以看到SVC的后端,只有该节点的后端Pod 10.0.1.104才会被加到IPVS的转发规则

image.png

在LoadBalancer的SVC模式下,如果ExternalTrafficPolicy为Local,对于ClusterIP来说,会把所有SVC后端Pod都会加到该节点的IPVS转发规则;对于ExternalIP,只会把该节点上的SVC后端Pod才会加到IPVS规则中。如果该节点没有SVC后端Pod,则该节点上的Pod访问SVC的ExternalIP将会是失败。


Service的ExternalTrafficPolicy是Cluster

SVC nginx1 CLusterIP是192.168.2.253,ExternalIP是10.0.3.63,后端是10.0.1.104和10.0.3.58

image.png

cn-hongkong.10.0.1.82

对于SVC的ClusterIP,可以看到SVC的后端两个Pod都会被加到IPVS的转发规则。

image.png 对于SVC的ExternalIP,可以看到SVC的后端两个Pod都会被加到IPVS的转发规则。

image.png

 

在LoadBalancer的SVC模式下,如果ExternalTrafficPolicy为Cluster,对于ClusterIP或ExternalIP来说,会把所有SVC后端Pod都会加到该节点的IPVS转发规则。

 

小结

可以访问到目

 

Conntrack表信息

Service nginx的ExternalTrafficPolicy是Local

SVC nginx CLusterIP是192.168.2.115,ExternalIP是10.0.3.62。后端是10.0.1.104和10.0.3.58

 

如果访问是SVCClusterIP,通过conntrack 信息,可以看到src是源端Pod 10.0.1.91dstSVC ClusterIP 192.168.2.115,dport是SVC中port并且期望是10.0.1.104 来回包给 10.0.1.91

image.png

如果访问是SVCExternalIP,通过conntrack 信息,可以看到src是源端Pod 10.0.1.91dstSVC ExternalIP 10.0.3.62。dport是SVC中port并且期望是10.0.1.104 来回包给 10.0.1.91

image.png

Service nginx1ExternalTrafficPolicy是Cluster

SVC nginx1 CLusterIP192.168.2.253ExternalIP是10.0.3.63后端是10.0.1.10410.0.3.58

如果访问是SVCClusterIP,通过conntrack 信息,可以看到src是源端Pod 10.0.1.91dstSVC ClusterIP 192.168.2.253dport是SVC中port并且期望是10.0.1.104 来回包给 10.0.1.91

image.png

如果访问是SVCExternalIP,通过conntrack 信息,可以看到src是源端Pod 10.0.1.91dstSVC ExternalIP 10.0.3.63dport是SVC中port并且期望是节点ECSIP 10.0.1.82 来回包给 10.0.1.91

image.png

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

 

数据链路转发示意图:

image.png

 

会经过calicao网卡,每个非hostnetworkpod会和calicao网卡形成veth pair,用于和其他pod或node进行通信

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

整个请求链路是ECS1 Pod1 eth0 ->Pod1 calixxxx ->Pod2 calixxxx ->ECS1 Pod2 eth0

访问SVC IPSVC 会在源端pod eth0和calixxx网卡捕捉到,在目端podeth0和calixxx时捕捉不到

在LoadBalancerSVC模式下,如果ExternalTrafficPolicy为Local,对于ClusterIP来说,会把所有SVC后端Pod都会加到该节点IPVS转发规则;对于ExternalIP,只会把该节点上SVC后端Pod才会加到IPVS规则中

在LoadBalancerSVC模式下,如果ExternalTrafficPolicy为Cluster,对于ClusterIP或ExternalIP来说,会把所有SVC后端Pod都会加到该节点IPVS转发规则,同时无法保留src地址

数据链路要经过三次内核协议栈,是Pod1协议栈、ECS1协议栈、Pod2协议

4) 场景三:访问PodIP,异节点pod间互访

环境

image.png

 

cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp和10.0.1.91

cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-lwrfc和10.0.3.58

内核路由

centos-67756b6dc8-h5wnp IP地址10.0.1.104,该容器在宿主机表现的PID是2211426,该容器网络命名空间有指向容器eth0的默认路由。

用上述类似办法可以发现centos-67756b6dc8-h5wnp的veth pair的cali44ae9fbceeb,Pod网络空间只有默认路由。

image.png

image.png

 

在ECS OS内,有指向Pod IP,下一跳为calixxxx的路由,通过前文可以知道calixxx网卡是和每个pod内的veth1组成的pair,所以,pod内访问SVC的CIDR会有指向veth1的路由,不会走默认的eth0路由。故:calixx网卡在这里的主要作用是用于:1.节点访问Pod 2. 当节点或者Pod访问 SVC的CIDR时,会走ECS OS内核协议栈转换,走到calixxx和eth0访问pod,对于目的为外部地址,则走Pod所属的ENI 出ECS进入到了VPC。

image.png

 

小结

可以访问到目

数据链路转发示意图:

image.png

 

会经过calicao网卡,每个非hostnetworkpod会和calicao网卡形成veth pair,用于和其他pod或node进行通信;

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

出ECS后,根据要访问pod和该pod ENI所属vswitch,命中VPC路由规则或者直接VSW上二层转发;

整个请求链路是ECS1 Pod1 eth0->ECS1 Pod1 calixxxxx->ECS1 ethx -> vpc route rule(如有) ->ECS2 ethx ->ECS2 Pod2 calixxxxx->ECS2 Pod2 eth0;

数据链路要经过四次内核协议栈,Pod1协议栈、ECS1协议栈、Pod2协议栈、ECS2协议;

 

5) 场景四:群内非SVC后端pod所在节点访问SVC ClusterIP

环境

image.png

image.png

image.png cn-hongkong.10.0.3.49节点上存在 nginx-7d6877d777-h4jtf和10.0.3.58

cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp和10.0.1.91

Service1 是nginx,ClusterIP是192.168.2.115 ExternalIP是10.0.3.62。

Service2 是ngin1,ClusterIP是192.168.2.253 ExternalIP是10.0.3.63

内核路由

内核路由部分已经在2.2和2.3 小结中详细说明,这里不再进行过多阐述。

源端ECS上的IPVS规则

根据2.2 小结中的源端ECS上的IPVS规则,我们可以得到:无论在哪种SVC模式下,对于ClusterIP来说,会把所有SVC后端Pod都会加到该节点的IPVS转发规则

 

小结

可以访问到目

 

Conntrack表信息

Service nginxExternalTrafficPolicy是Local

SVC nginx CLusterIP是192.168.2.115,ExternalIP是10.0.3.62。后端是10.0.1.104和10.0.3.58

cn-hongkong.10.0.1.82

 image.png

源端ECS上src是源端Pod 10.0.1.91,dst是SVC ClusterIP 192.168.2.115,dport是SVC中的port。并且期望是10.0.3.58 来回包给 10.0.1.91。

 

cn-hongkong.10.0.3.49

image.png

 

目的端ECS上src是源端Pod 10.0.1.91,dst是Pod的IP 10.0.3.58,port是pod的port。并且期望此pod 来回包给 10.0.1.91。

 

Service nginx1ExternalTrafficPolicy是Cluster

SVC nginx1 CLusterIP是192.168.2.253,ExternalIP是10.0.3.63,后端是10.0.1.104和10.0.3.58

 

cn-hongkong.10.0.1.82  image.png 源端ECS上src是源端Pod 10.0.1.91,dstSVC ClusterIP 192.168.2.115,dport是SVC中的port。并且期望是10.0.3.58 来回包给 10.0.1.91。

 

cn-hongkong.10.0.3.49

image.png

 

目的端ECS上src是源端Pod 10.0.1.91,dst是Pod的IP 10.0.3.58,dport是pod的port。并且期望此pod 来回包给 10.0.1.91。

 

对于ClusterIP来说,源端ECS会把所有SVC后端Pod都会加到该节点IPVS转发规则,目端ECS是捕获不到任何SVC ClusterIP信息,只能捕获到源端PodIP,所以回包时候会回到源端Pod附属网卡上

 

数据链路转发示意图:

 image.png

 

会经过calicao网卡,每个非hostnetworkpod会和calicao网卡形成veth pair,用于和其他pod或node进行通信

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

出ECS后,根据要访问pod和该pod ENI所属vswitch,命中VPC路由规则或者直接VSW上二层转发;

整个请求链路是

去方向:

ECS1 Pod1 eth0 ->ECS1 Pod1 calixxxxxx ->ECS1 主网卡eth0 -> vpc route rule(如有) ->ECS2 附属网卡ethx ->ECS2 Pod2 calixxxxx ->ECS2 Pod2 eth0

回方向:

ECS2 Pod2 eth0 ->ECS2 Pod2 calixxxxx ->ECS2 附属网卡ethx -> vpc route rule(如有) ->ECS1 附属网卡eth1 ->ECS1 Pod1 calixxxxxx ->ECS1 Pod1 eth0

 

对于ClusterIP来说,源端ECS会把所有SVC后端Pod都会加到该节点IPVS转发规则,目端ECS是捕获不到任何SVC ClusterIP信息,只能捕获到源端PodIP,所以回包时候会回到源端Pod附属网卡上

数据链路要经过四次内核协议栈,Pod1协议栈、ECS1协议栈、Pod2协议栈、ECS2协议

 


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

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

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
13天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
54 2
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
14天前
|
消息中间件 存储 Cloud Native
云原生架构下的数据一致性挑战与应对策略####
本文探讨了在云原生环境中,面对微服务架构的广泛应用,数据一致性问题成为系统设计的核心挑战之一。通过分析云原生环境的特点,阐述了数据不一致性的常见场景及其对业务的影响,并深入讨论了解决这些问题的策略,包括采用分布式事务、事件驱动架构、补偿机制以及利用云平台提供的托管服务等。文章旨在为开发者提供一套系统性的解决方案框架,以应对在动态、分布式的云原生应用中保持数据一致性的复杂性。 ####
|
5天前
|
Kubernetes Cloud Native Docker
云原生之旅:从传统架构到容器化服务的演变
随着技术的快速发展,云计算已经从简单的虚拟化服务演进到了更加灵活和高效的云原生时代。本文将带你了解云原生的概念、优势以及如何通过容器化技术实现应用的快速部署和扩展。我们将以一个简单的Python Web应用为例,展示如何利用Docker容器进行打包和部署,进而探索Kubernetes如何管理这些容器,确保服务的高可用性和弹性伸缩。
|
10天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
35 5
|
12天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
29 5
|
12天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
12天前
|
消息中间件 缓存 Cloud Native
云原生架构下的性能优化实践与挑战####
随着企业数字化转型的加速,云原生架构以其高度解耦、弹性伸缩和快速迭代的特性,成为现代软件开发的首选模式。本文深入探讨了云原生环境下性能优化的关键策略与面临的主要挑战,通过案例分析,揭示了如何有效利用容器化、微服务、动态调度等技术手段提升应用性能,同时指出了在复杂云环境中确保系统稳定性和高效性的难题,为开发者和架构师提供了实战指南。 ####
26 3
|
12天前
|
运维 Kubernetes Cloud Native
深入理解云原生架构:从理论到实践
【10月更文挑战第38天】本文将引导读者深入探索云原生技术的核心概念,以及如何将这些概念应用于实际的软件开发和运维中。我们将从云原生的基本定义出发,逐步展开其背后的设计哲学、关键技术组件,并以一个具体的代码示例来演示云原生应用的构建过程。无论你是云原生技术的初学者,还是希望深化理解的开发者,这篇文章都将为你提供有价值的见解和实操指南。
|
12天前
|
Kubernetes Cloud Native 持续交付
云原生技术在现代应用架构中的实践与思考
【10月更文挑战第38天】随着云计算的不断成熟和演进,云原生(Cloud-Native)已成为推动企业数字化转型的重要力量。本文从云原生的基本概念出发,深入探讨了其在现代应用架构中的实际应用,并结合代码示例,展示了云原生技术如何优化资源管理、提升系统弹性和加速开发流程。通过分析云原生的优势与面临的挑战,本文旨在为读者提供一份云原生转型的指南和启示。
26 3
下一篇
无影云桌面