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

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

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

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


4) Istio-proxy

image.png

 可以看到15001和15006 被envoy应用所监听,而envoy应用就是istio-proxy容器程序。Init 容器启动的时候根据所设置的参数中指定将出入站流量重定向到 Envoy的模式为“REDIRECT”或者“TPROXY”。

 

使用REDIRECT方式,一旦Pod注入了Sidecar代理之后,所有入站流量都是从Envoy重定向,Envoy将流量发送到绑定了本地地址(127.0.0.1)的应用程序,所以应用看不到真正的原始IP。

 

在服务网格环境下如何保持服务访问时的客户端源IP呢?可以使用TPROXY模式,目前ASM已经支持了 TPROXY模式,具体详情请见https://help.aliyun.com/document_detail/464794.html

在TPROXY模式下,Pod的网络命名空间的iptables会有mangle配置。

ADS聚合服务发现

image.png

我们已经知道了服务网格会在每个注入的Pod内注入两个容器:istio-init和istio-proxy。一旦在网格控制面进行相关配置的修改,会通过pilot下发到每个istio-proxy容器去生效。而istio是通过xDS服务接口去实现相关配置的动态下发的,其中xDS包含了LDS(Listener Discover Service)、CDS(Cluster Discover Service)、EDS(Endpoint Discovery Service)和RDS(Route Discover Service)。

 

一般情况下,在更新配置过程中应该先更新Cluster->之后CLuster的Endpoint 开始更新->开始更新Cluster和Endpoint相对应的Listener -> Route开始更新配置的Listener信息->最后删除不在使用 Cluster和Endpoint 以保证更新过程中流量无损。但是这些xDS接口是相互独立,所以在配置下发的时候,存在某些依赖关系的DS因配置生效前后关系造成了部分流量被丢弃,这在某些生产环境中是无法接受的。

 

为了保证数据面配置的一致性,服务网格利用gRPC流来进行ADS聚合发现服务,通过一个gRPC流来保证各个xDS接口的调用顺序,避免各个接口独立性造成数据配置的不匹配。详细信息可以参考:
https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol

envoy-rev.json

image.png

 可以看到istio-proxy 启动了pilot-agent 程序,pilot-agent 作为父进程启动了子进程/usr/local/bin/envoy。其中/etc/istio/proxy/envoy-rev.json 是envoy初始化的配置文件。

 

Node
包含了istio-proxy所在节点,当前Pod,istio版本、ACK集群ID、ASM版本、必要端口等相关信息。

image.png

 

admin

istio-proxy相关日志,管理端口等信息

image.png

 

dynamic_resources

ADS相关配置信息,比如api协议,版本,超时时间等

image.png

 

static_resources

包含了prometheus_stats、agent、sds-grpc、xds-grpc和zipkin五个cluster和一个在15090上监听的listener,xds-grpc cluster对应前面dynamic_resources中ADS配置。prometheus_stats cluster和15090用于对外提供prometheus采集端口。zipkin cluster是外部的zipkin服务器调用地址。

image.png

 

tracing

分布式链路跟踪,这里的collector_cluster是前面static_resources里面定义的zipkin cluster。

image.png

 

访问日志分析

通过前文,我们已经知道两个互相被注入的pod访问,流量会被各自的istio-proxy所劫持并处理,那么只要分析客户端和服务端的istio-proxy日志并进行加工,就可以对流量进行可观测性解读。

 

我们在这里还是以官方例子来举例访问 http:///productpage,productpage 应用会自动调用details服务,reviews服务。我们以productpage和details之间链路来进行举例分析。

 

productpage-v1-797d845774-dndmk IP 是10.0.1.130,details 应用的svc的名称是details,svc地址是192.168.1.125,svc端口是9080

 

请求发送方 productpage-v1-797d845774-dndmk的istio-proxy日志

{"upstream_host":"10.0.1.127:9080","downstream_remote_address":"10.0.1.130:49586","downstream_local_address":"192.168.1.125:9080","duration":6,"upstream_cluster":"outbound|9080||details.istio-inject.svc.cluster.local","path":"/details/0","protocol":"HTTP/1.1","upstream_local_address":"10.0.1.130:50026","method":"GET","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36","route_name":"default","request_id":"834147c2-435f-94a7-af11-8491df9ab4f8","start_time":"2023-01-31T14:23:20.603Z","upstream_transport_failure_reason":null,"upstream_service_time":"5","response_flags":"-","bytes_received":0,"authority_for":"details:9080","authority":"details:9080","requested_server_name":null,"istio_policy_status":null,"trace_id":"9712c9f3da936a8c927f227bfe536c16","response_code":200,"x_forwarded_for":null,"bytes_sent":178}

 

请求接受方 details-v1-6758dd9d8d-dtbdc的istio-proxy日志

{"x_forwarded_for":null,"start_time":"2023-01-31T14:23:20.608Z","method":"GET","response_flags":"-","route_name":"default","istio_policy_status":null,"requested_server_name":"outbound_.9080_._.details.istio-inject.svc.cluster.local","bytes_received":0,"request_id":"834147c2-435f-94a7-af11-8491df9ab4f8","response_code":200,"upstream_host":"10.0.1.127:9080","trace_id":"9712c9f3da936a8c927f227bfe536c16","downstream_remote_address":"10.0.1.130:50026","protocol":"HTTP/1.1","bytes_sent":178,"upstream_transport_failure_reason":null,"downstream_local_address":"10.0.1.127:9080","upstream_local_address":"127.0.0.6:46225","authority":"details:9080","authority_for":"details:9080","upstream_service_time":"0","upstream_cluster":"inbound|9080||","duration":1,"path":"/details/0","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"}

 日志内容解读

 

"upstream_host":"10.0.1.127:9080",————对于outbound,此是上游某个Endpoint地址和端口

downstream_remote_address":"10.0.1.130:49586"," ————对于outbound,此为本pod-ip:随机端口1

downstream_local_address":"192.168.1.125:9080","————对于outbound,此为目svc-ip:svc-port

duration":6," ———— 整个请求时间,单位ms

upstream_cluster":"outbound|9080||details.istio-inject.svc.cluster.local",———— cluster信息

"path":"/details/0"

"protocol":"HTTP/1.1"

"upstream_local_address":"10.0.1.130:50026", ————对于outbound,此为本pod-ip:随机端口2

"method":"GET"

"user_agent":"Mozilla/5.0(Windows NT 10.0; Win64; x64)

AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"

"route_name":"default",———— 路由名称

"request_id":"834147c2-435f-94a7-af11-8491df9ab4f8"

"start_time":"2023-01-31T14:23:20.603Z"

"upstream_transport_failure_reason":null

"upstream_service_time":"5",———— 上游返回请求时间,单位ms

"response_flags":"-",———— 返回标志,关于连接或返回详细信息

"bytes_received":0

"authority_for":"details:9080"

"authority":"details:9080"

"requested_server_name":null

"istio_policy_status":null

"trace_id":"9712c9f3da936a8c927f227bfe536c16",———— 此ID为唯一值,可以在上游istio-proxy对应

"response_code":200,———— 返回状态码

"x_forwarded_for":null

"bytes_sent":178

 

日志解读可以详细见官方连接:
https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage

 

 

UPSTREAM_HOST

上游主机的host,表示从 envoy 发出的请求的目的端

通常来说,对于 outbound cluster,此值是「上游pod-ip :Pod-port」,而对于 inbound cluster,此值是「本pod-ip :Pod-port」

 

UPSTREAM_LOCAL_ADDRESS

上游连接中,当前 envoy的本地地址

通常来说,对于 outbound cluster,此值是「本pod-ip : 随机端口2」,而对于 inbound cluster,此值是「127.0.0.6: 随机端口3」,此处的127.0.0.6 对应了 【1.2 Pod流量转发-Init Container】 中的iptables会将来自127.0.0.6的流量免于istio代理,因为这个流量是从sidecar本身发出的

 

DONSTREAM_LOCAL_ADDRESS

下游连接中,当前 envoy的本地地址。通常来说,对于 outbound cluster,此值是「目的service-ip : service-port 」,而对于 inbound cluster,此值是「当前pod-ip :Pod-port,此处和下游的upstream_host应该相对应。

 

DOWNSTREAM_REMOTE_ADDRESS

通常来说,对于 outbound cluster,此值是「当前pod-ip : 随机端口 」,而对于 inbound cluster,此值是「下游pod-ip : 随机端口2」,此处和下游的upstream_local_address相对应


5 Envoy配置简读(数据链路)

背景

image.png

还是用官方的示例,以productpage 访问 reviews 服务来举例。

image.png

image.png

image.png

image.png

通过Kubernets 集群资源,我们可一看到reviews有三个版本 分贝为v1,v2,v3,Pod数量各一个。SVC reviews 是ClusterIP模式,svc端口是9080,targetport是pod的9080端口,v1,v2,v3 都被加到了reviews SVC的endpointslice。

 

在未被istio注入的情况下,集群内productpagePod访问 reviews.istio-inject 服务,会被netfilter以round-robin的方式平均转发到v1,v2,v3三个pod上,每个pod应该承受1/3的流量。在传统的k8s集群中,是无法通过k8s的resource控制不同版本的流量分配。但是实际的生产环境,我们是有这方面的需求的。

 

比如v1版本是线上业务版本,承载了主要业务流量,v2版本是开发完毕预上线版本,本质上是不希望影响线上流量的,可能需要引流线上流量的5%到预发版本进行一段时间观察,来判断新版本是否有问题,之后再进一步扩大引流比例直至100%之后,v1版本才进行下线,从而实现从业务角度的平滑迁移。

 

或者比如v3是测试版本,我们希望观察流量在网络波动超时情况下,业务的自我容灾和恢复情况的行为是否符合预期,以前这种需求需要通过在业务代码中写好熔断代码,不同熔断环境都需要重新发版。那么像这种流量控制在ASM Istio就可以很容易的实现。

 

下面就是一个ASM Istio中的vs和dr的配置。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 creationTimestamp: '2023-01-30T06:25:21Z'
 generation: 1
 name: reviews
 namespace: istio-inject
 resourceVersion: '651722274'
 uid: 63f715c9-b253-4fbb-8351-5313371df14e
spec:
 hosts:
 - reviews.istio-inject.svc.cluster.local
 http:
 - name: route
 route:
 - destination:
 host: reviews
 subset: v1
 weight: 10
 - destination:
 host: reviews
 subset: v2
 weight: 40
 - destination:
 host: reviews
 subset: v3
 weight: 50

 其中在reviews vs的定义了集群内访问reviews.istio-inject.svc.cluster.local 是的http协议的规则。其中指明了v1版本权重10%,v2版本权重40%,v3版本权重 50%

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
 creationTimestamp: '2023-01-30T06:28:46Z'
 generation: 2
 name: reviews
 namespace: istio-inject
 resourceVersion: '654863578'
 uid: fdbdfcea-1fcd-453e-96fb-ce41c91ded9b
spec:
 host: reviews
 subsets:
 - labels:
 version: v1
 name: v1
 - labels:
 version: v2
 name: v2
 - labels:
 version: v3
 name: v3
 trafficPolicy:
 connectionPool:
 http:
 http2MaxRequests: 1000
 maxRequestsPerConnection: 10
 tcp:
 maxConnections: 100
 outlierDetection:
 baseEjectionTime: 15m
 consecutive5xxErrors: 7
 interval: 5m

 reviews dr的定义了集群内reviews的几个版本,并定义了相关流量策略。其中http2MaxRequests 表明http最大的请求数。maxRequestsPerConnection 表明每个连接最大的请求数。tcp最大连接数是100。在熔断配置中,每隔5min中检测一次,连续7次5xx,把后端移除endpoint 15min。

 

通过前文我们知道pilot通过xDS接口将服务网格的配置下发到每个被注入的pod中的istio-proxy中。那么对于每个pod中的istio-proxy,我们是否有办法去查看相关的加载的配置信息呢?istio-proxy通过15000端口对外暴露管理端口,我们可以通过如图所示的命令获取到相关的配置信息。

 

其中可以通过curl 127.0.0.1:15000/config_dump 可以获取到完整的配置信息,由于此配置信息超过1万多行,我们就不在这里做全部的展示

 

感兴趣的同学可以自行研究下,下文会针对此config_dump信息中的cluster,Listener,endpoint,route等关键信息做个相关展示和简要说明,同时也和前文的xDS做个呼应。

kubectl exec -n istio-inject productpage-v1-797d845774-dndmk -c istio-proxy -it -- curl 127.0.0.1:15000/config_dump

image.png

 

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

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

相关文章
|
1天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在企业转型中的关键角色
【5月更文挑战第21天】 随着数字化转型的浪潮席卷全球,企业正面临前所未有的挑战与机遇。本文深入探讨了云原生架构如何成为推动企业敏捷性、可扩展性和创新能力的核心动力。通过分析云原生技术的基本原理及其在各行各业中的应用案例,揭示了该技术如何助力企业实现资源优化、加快产品上市时间以及提高服务质量。文章旨在为企业决策者和技术实践者提供洞见,以便更好地理解和应用云原生架构,从而在竞争激烈的市场中保持领先地位。
|
1天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与实践
【5月更文挑战第21天】 随着数字化转型的加速,企业对于敏捷性、可扩展性和成本效益的需求日益增长。云原生技术以其独特的优势应运而生,成为推动企业IT架构现代化的重要力量。本文将深入探讨云原生架构的核心概念、关键技术以及如何在企业中实施云原生解决方案,以实现真正的弹性、自动化和持续交付。
|
1天前
|
Cloud Native 持续交付 API
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第21天】 随着企业加速其数字化进程,云原生架构已成为推动创新和灵活性的核心驱动力。本文探讨了云原生技术如何助力企业构建高度可靠、可扩展的系统,并确保业务连续性。通过深入分析微服务、容器化、持续集成和自动化管理等关键概念,揭示云原生实践如何优化资源利用,降低运营成本,同时提升服务质量。文章旨在为决策者提供策略洞见,帮助他们在动态市场环境中保持竞争力。
|
1天前
|
Cloud Native 持续交付 云计算
构建未来:云原生架构在企业数字化转型中的关键角色
【5月更文挑战第21天】 随着企业加速其数字化转型步伐,云原生架构凭借其灵活性、可扩展性和敏捷性成为支撑创新的关键。该文深入探讨了云原生技术如何助力企业实现从传统IT向现代应用开发和运维模式的转变,以及这一转变如何推动业务增长和竞争力提升。文中不仅阐述了云原生的核心组件如容器化、微服务和持续集成/持续部署(CI/CD)等,还讨论了企业在采纳这些技术时面临的挑战及克服策略。通过具体案例分析,本文揭示了云原生实践在不同行业中的适用性和效益,为决策者提供了实施云原生路线图的洞见。
|
1天前
|
运维 Cloud Native Devops
构建未来:云原生架构在现代应用开发中的角色
【5月更文挑战第21天】 随着数字化转型的加速,企业对软件交付速度和运维效率的要求日益提高。云原生架构以其独特的设计理念和技术栈,成为推动这一进程的关键因素。本文将探讨云原生的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及DevOps文化,并分析它们如何共同作用以实现敏捷性、可扩展性和可靠性。此外,文章还将讨论云原生架构面临的挑战与克服这些挑战的策略。
|
1天前
|
运维 监控 JavaScript
【阿里云云原生专栏】Serverless架构下的应用部署与运维:阿里云Function Compute深度探索
【5月更文挑战第21天】阿里云Function Compute是事件驱动的无服务器计算服务,让用户无需关注基础设施,专注业务逻辑。本文详述了在FC上部署应用的步骤,包括创建函数、编写代码和部署,并介绍了运维功能:监控告警、日志管理、版本管理和授权管理,提供高效低成本的计算服务。
126 6
|
1天前
|
Kubernetes Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第21天】 随着企业加速其数字化战略,云原生技术已不仅仅是一种趋势,而是推动业务敏捷性、可扩展性和创新的关键因素。本文将深入探讨云原生架构的核心组件,包括容器化、微服务和持续集成/持续部署(CI/CD),以及如何利用这些技术来优化资源使用、提高开发速度并确保系统的弹性。通过分析多个行业案例,我们将阐明云原生实践如何使组织能够快速响应市场变化,降低运营成本,并在高度竞争的环境中保持领先地位。
|
2天前
|
架构师 数据挖掘 Python
最全pandas库(Python),2024年最新阿里云架构师面试
最全pandas库(Python),2024年最新阿里云架构师面试
最全pandas库(Python),2024年最新阿里云架构师面试
|
2天前
|
Cloud Native 安全 持续交付
构建未来应用:云原生架构的演进与实践
【5月更文挑战第20天】 在数字化转型的浪潮中,云原生技术以其独特的弹性、可扩展性和敏捷性成为推动企业IT架构现代化的关键力量。本文将深入探讨云原生的核心概念、关键技术以及如何在企业环境中实施云原生架构。我们将从容器化技术的基本原理出发,解析微服务架构的设计原则,并讨论如何通过持续集成和持续部署(CI/CD)实现快速迭代。此外,文章还将涉及如何利用云平台的资源和服务优化云原生应用的性能和安全性。通过对云原生生态的深度剖析,本文旨在为开发者和企业提供一条明晰的路径,以构建和维护在不断变化的市场环境中能够持续创新的应用程序。
|
2天前
|
运维 Cloud Native Devops
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第20天】 随着企业加速其数字化转型的步伐,云原生架构已经成为支持复杂、可伸缩和敏捷应用程序的基石。本文深入探讨了云原生技术如何助力企业在竞争激烈的市场中快速创新并实现业务连续性。通过剖析微服务、容器化以及持续集成和持续部署(CI/CD)等核心概念,揭示了它们如何共同塑造出一个灵活且高效的开发环境。文章还将展望云原生生态系统的发展趋势,包括无服务器计算、服务网格和自动化运维等前沿技术,为企业提供适应未来挑战的策略建议。