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

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

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

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


Bootstrap

Envoy的初始化配置,与前文中的envoy-rev0.json是一致的。其中

drainDuration —— 热重启期间Envoy关闭连接的时间(以秒为单位),默认是45s

parentShutdownDuration —— 热重启期间,在完全关闭父进程之前,等到的最大时间,默认60s。此数值应该大于drainDuration

 

terminationDrainDuration —— 默认5s。proxy在关闭之前,允许连接关闭时间。通过前文,我们知道pod流量先过istio再被转发到业务容器。当应用发版时候,如果保证现有连接优雅关闭,保证istio-proxy容器在业务容器完全关闭现有连接后,再退出是发版更新时候需要考虑的问题,此值是实现业务平滑更新需要考虑的。

image.png

static_resources

config_dump中静态资源,是来自envoy-rev0.json,

里面包含了prometheus_stats、agent、sds-grpc、xds-grpc和zipkin等配置

image.png

dynamic_resources

动态资源,是通过xDS接口下发到每个istio-proxy容器生效的ASM Istio的配置。也是上述reviews dr,vs配置后通过ASM管控侧下发的。我们接下来关注动态资源配置

Listeners

Envoy采用的listener 来接受到达Envoy的流量请求。Listener和IP Sock、Unix Domain Socket绑定,也可以不绑定到具体的端口,而是接收从其他listener转发来的流量。ASM Istio就是利用了Envoy listener的这一特性来实现转发给不同的服务请求交给不同的Listeners来处理。

 

还是以productpage访问reviews来举例,productpage访问的是reviews的9080端口,根据上文我们知道productpage container访问 外部的9080端口会被先转发到15001 端口,所以我们先看下15001的端口listeners。


VirtualOutbound Listeners

Envoy在15001 端口创建了Listeners,所有被iptables转发的对外请求都会被转到envoy的15001 端口。可以从配置看到,envoy接受到了流量后,并不会做相关的业务动作,而是根据 "use_original_dst": true, 这个配置,依据请求的目的端口转发到相应的listeners 进行处理。

image.png 

那么肯定有个疑问了,如果请求端口并没有配置相关listeners设置,流量该如何进行处理呢?这个取决于outboundTrafficPolicy配置,详情请见
https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-Mode


Name

Description

REGISTRY_ONLY

只有被注册到服务网格集群内的serviceentry才可以被成功转发出去。如果访问的目的端未被注册到服务网格集群内,请求会被转发到BlackHoleCLuster,由于找不到匹配的upstream host,则会被丢弃。

ALLOW_ANY

无论外部请求是否注册,都可以发送到目的地址。如果目的地址未被listeners,则会将流量转发到PassthroughCluster的TCP proxy filter,请求将会被发送到原始目的地址。

 

Outbound Listeners

outbound 监听命名是0.0.0.0_9080,表明发向任何IP地址的9080端口都被此监听涵盖。"bind_to_port”: false此值表明监听没有绑定到tcp端口,流量是有virtualOutbound转发而来的。

 

那么首先我们需要区别这个监听是为了入方向还是出方向呢?对于入方向,流量会经过15006端口的virtualInbound的listeners,是不会进入0.0.0.0_9080的listeners。

image.png

 

从配置上可以看到filter中并没有特殊的志敏筛选条件,说明接受任何流量,其中config_source 为ads,表明这个是来自动态发现。

 

根据前文可以可看到revirews,ratings,details几个service都是9080端口,这些应用都被同一个服务网格注入,那么productpage访问的目的地址的9080,Envoy如何刚知道是哪个service?是如何判断如果目的端口未9080的地址不是网格内,该如何处理呢?通过上图"route_config_name": "9080" 可以看到存在一个‘9080’的路由规则,在这个路由规则中规定不同的请求目的地的不同的处理结果,下一小节我们将讨论。

Route

前文我们已经知道productpage 应用访问reviews的9080端口会被listeners outbound 0.0.0.0_9080 路由规则到 9080的路由。以下是‘9080’ 路由的全部信息。我们可以看到一共有5个virtual_hosts,分别是allow_any、details、productpage、ratings、和reviews。其中后面4个对应4个不同outbound的cluster,allow_any 对应的是PassthroughCluster,当出方向请求找到相应的Cluster规则时候,会采用默认直接通过。

 

可能有小伙伴很奇怪productpage不直接调用ratings服务,为什么productpage envoy配置会包含ratings的信息。

 

这是因为ASM Istio控制面是无法感知到数据面各个服务之间是如何调用的,因此会将所有的配置信息都下发到被注入的envoy里面,这样保证了网格配置的一致性,但是随着网格服务配置的增多,每个envoy接受和本envoy不相关的配置信息就会变多,这样对envoy资源使用会有一定影响,如果小伙伴有很好的envoy开发能力,并且对业务之间调用非常熟悉,想去除掉本pod中envoy无关的规则,可以通过sidecar规则自定义配置对egress和ingress进行调整,详情请见:

https://istio.io/latest/docs/reference/config/networking/sidecar/

{
 "version_info": "2023-01-30T06:25:21Z/19",
 "route_config": {
 "@type": "type.googleapis.com/envoy.config.route.v3.RouteConfiguration",
 "name": "9080",
 "virtual_hosts": [
 {
 "name": "allow_any",
 "domains": [
 "*"
 ],
 "routes": [
 {
 "match": {
 "prefix": "/"
 },
 "route": {
 "cluster": "PassthroughCluster",
 "timeout": "0s",
 "max_grpc_timeout": "0s"
 },
 "name": "allow_any"
 }
 ],
 "include_request_attempt_count": true
 },
 {
 "name": "details.istio-inject.svc.cluster.local:9080",
 "domains": [
 "details.istio-inject.svc.cluster.local",
 "details.istio-inject.svc.cluster.local:9080",
 "details",
 "details:9080",
 "details.istio-inject.svc",
 "details.istio-inject.svc:9080",
 "details.istio-inject",
 "details.istio-inject:9080",
 "192.168.1.125",
 "192.168.1.125:9080"
 ],
 "routes": [
 {
 "match": {
 "prefix": "/"
 },
 "route": {
 "cluster": "outbound|9080||details.istio-inject.svc.cluster.local",
 "timeout": "0s",
 "retry_policy": {
 "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
 "num_retries": 2,
 "retry_host_predicate": [
 {
 "name": "envoy.retry_host_predicates.previous_hosts",
 "typed_config": {
 "@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
 }
 }
 ],
 "host_selection_retry_max_attempts": "5",
 "retriable_status_codes": [
 503
 ]
 },
 "max_stream_duration": {
 "max_stream_duration": "0s",
 "grpc_timeout_header_max": "0s"
 }
 },
 "decorator": {
 "operation": "details.istio-inject.svc.cluster.local:9080/*"
 },
 "name": "default"
 }
 ],
 "include_request_attempt_count": true
 },
 {
 "name": "istio-ingressgateway.istio-system.svc.cluster.local:9080",
 "domains": [
 "istio-ingressgateway.istio-system.svc.cluster.local",
 "istio-ingressgateway.istio-system.svc.cluster.local:9080",
 "istio-ingressgateway.istio-system",
 "istio-ingressgateway.istio-system:9080",
 "istio-ingressgateway.istio-system.svc",
 "istio-ingressgateway.istio-system.svc:9080",
 "192.168.1.250",
 "192.168.1.250:9080"
 ],
 "routes": [
 {
 "match": {
 "prefix": "/"
 },
 "route": {
 "cluster": "outbound|9080||istio-ingressgateway.istio-system.svc.cluster.local",
 "timeout": "0s",
 "retry_policy": {
 "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
 "num_retries": 2,
 "retry_host_predicate": [
 {
 "name": "envoy.retry_host_predicates.previous_hosts",
 "typed_config": {
 "@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
 }
 }
 ],
 "host_selection_retry_max_attempts": "5",
 "retriable_status_codes": [
 503
 ]
 },
 "max_stream_duration": {
 "max_stream_duration": "0s",
 "grpc_timeout_header_max": "0s"
 }
 },
 "decorator": {
 "operation": "istio-ingressgateway.istio-system.svc.cluster.local:9080/*"
 "name": "default"
 }
 ],
 "include_request_attempt_count": true
 },
 }, 
 {
 "name": "productpage.istio-inject.svc.cluster.local:9080",
 "domains": [
 "productpage.istio-inject.svc.cluster.local",
 "productpage.istio-inject.svc.cluster.local:9080",
 "productpage",
 "productpage:9080",
 "productpage.istio-inject.svc",
 "productpage.istio-inject.svc:9080",
 "productpage.istio-inject",
 "productpage.istio-inject:9080",
 "192.168.6.226",
 "192.168.6.226:9080"
 ],
 "routes": [
 {
 "match": {
 "prefix": "/"
 },
 "route": {
 "cluster": "outbound|9080||productpage.istio-inject.svc.cluster.local",
 "timeout": "0s",
 "retry_policy": {
 "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
 "num_retries": 2,
 "retry_host_predicate": [
 {
 "name": "envoy.retry_host_predicates.previous_hosts",
 "typed_config": {
 "@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
 }
 }
 ],
 "host_selection_retry_max_attempts": "5",
 "retriable_status_codes": [
 503
 ]
 },
 "max_stream_duration": {
 "max_stream_duration": "0s",
 "grpc_timeout_header_max": "0s"
 }
 },
 "decorator": {
 "operation": "productpage.istio-inject.svc.cluster.local:9080/*"
 },
 "name": "default"
 }
 ],
 "include_request_attempt_count": true
 },
 {
 "name": "ratings.istio-inject.svc.cluster.local:9080",
 "domains": [
 "ratings.istio-inject.svc.cluster.local",
 "ratings.istio-inject.svc.cluster.local:9080",
 "ratings",
 "ratings:9080",
 "ratings.istio-inject.svc",
 "ratings.istio-inject.svc:9080",
 "ratings.istio-inject",
 "ratings.istio-inject:9080",
 "192.168.1.172",
 "192.168.1.172:9080"
 ],
 "routes": [
 {
 "match": {
 "prefix": "/"
 },
 "route": {
 "cluster": "outbound|9080||ratings.istio-inject.svc.cluster.local",
 "timeout": "0s",
 "retry_policy": {
 "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
 "num_retries": 2,
 "retry_host_predicate": [
 {
 "name": "envoy.retry_host_predicates.previous_hosts",
 "typed_config": {
 "@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
 }
 }
 ],
 "host_selection_retry_max_attempts": "5",
 "retriable_status_codes": [
 503
 ]
 },
 "max_stream_duration": {
 "max_stream_duration": "0s",
 "grpc_timeout_header_max": "0s"
 }
 },
 "decorator": {
 "operation": "ratings.istio-inject.svc.cluster.local:9080/*"
 },
 "name": "default"
 }
 ],
 "include_request_attempt_count": true
 },
 {
 "name": "reviews.istio-inject.svc.cluster.local:9080",
 "domains": [
 "reviews.istio-inject.svc.cluster.local",
 "reviews.istio-inject.svc.cluster.local:9080",
 "reviews",
 "reviews:9080",
 "reviews.istio-inject.svc",
 "reviews.istio-inject.svc:9080",
 "reviews.istio-inject",
 "reviews.istio-inject:9080",
 "192.168.4.113",
 "192.168.4.113:9080"
 ],
 "routes": [
 {
 "match": {
 "prefix": "/"
 },
 "route": {
 "weighted_clusters": {
 "clusters": [
 {
 "name": "outbound|9080|v1|reviews.istio-inject.svc.cluster.local",
 "weight": 10
 },
 {
 "name": "outbound|9080|v2|reviews.istio-inject.svc.cluster.local",
 "weight": 40
 },
 {
 "name": "outbound|9080|v3|reviews.istio-inject.svc.cluster.local",
 "weight": 50
 }
 ],
 "total_weight": 100
 },
 "timeout": "0s",
 "retry_policy": {
 "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
 "num_retries": 2,
 "retry_host_predicate": [
 {
 "name": "envoy.retry_host_predicates.previous_hosts",
 "typed_config": {
 "@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
 }
 }
 ],
 "host_selection_retry_max_attempts": "5",
 "retriable_status_codes": [
 503
 ]
 },
 "max_stream_duration": {
 "max_stream_duration": "0s",
 "grpc_timeout_header_max": "0s"
 }
 },
 "metadata": {
 "filter_metadata": {
 "istio": {
 "config": "/apis/networking.istio.io/v1alpha3/namespaces/istio-inject/virtual-service/reviews"
 }
 }
 },
 "decorator": {
 "operation": "reviews:9080/*"
 },
 "name": "route"
 }
 ],
 "include_request_attempt_count": true
 }
 ],
 "validate_clusters": false
 },
 "last_updated": "2023-01-30T06:25:21.804Z"
 },

 我们还是以productpage调用reviews来举例,Envoy 会根据 HTTP header 中的domains 来匹配 VirtualHost中domain,所以可以看到domains中列举了reviews的集群内的长短域名,和svc的地址。match “/” 会路由到三个Cluster "outbound|9080|v1|reviews.istio-inject.svc.cluster.local"、"outbound|9080|v2|reviews.istio-inject.svc.cluster.local"和"outbound|9080|v3|reviews.istio-inject.svc.cluster.local",权重分别为10,40,50,名称是‘route’,看到这里是不是有点熟悉?

 

对的,这和前文 [1.3 Envoy配置简读-背景] 中 reviews的VS中的设置,故我们在vs中的相关配置信息,最终envoy会转为route的配置加载后生效。

image.png

image.png

 

 

 通过前面我们还可以看到默认超时是0s,默认重试次数是2次,重试条件是"connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes"

 

Cluster

outbound cluster

 

根据上一下小节,productpage访问reviews,会被productpage中的istio-proxy匹配到‘9080’路由-> 依据vs配置的相关信息,进入三个cluster( "outbound|9080|v1|reviews.istio-inject.svc.cluster.local"、"outbound|9080|v2|reviews.istio-inject.svc.cluster.local"和"outbound|9080|v3|reviews.istio-inject.svc.cluster.local")中一个。

 

这里我们就以"outbound|9080|v1|reviews.istio-inject.svc.cluster.local"Cluster 为例

 image.png

image.png

outbound|9080|v1|reviews.istio-inject.svc.cluster.local cluster配置中可以看到,其类型为EDS,即表示该Cluster的endpoint来自于动态发现,动态发现中eds_config则表明是由ads下发的。同样可以看到与前文 [1.3 Envoy配置简读-背景] 中 reviews的dr中的设置熟悉的配置,比如connectionpool,outlierDetection等这些相关配置信息,最终envoy会转为cluster的配置加载后生效。

 

接下来我们稍微探讨下其他几个特殊的cluster。

BlackHoleCluster

Envoy对于找不到后端处理请求的会默认丢弃,所以会有统一的一个blackholecluster,没有任何指明的后端svc。任何无匹配后端的流量会被转发到这个cluster。

image.png


PassthroughCluster

和BlackHoleCluter正好相反,发向PassthroughCluster的请求会被直接发送到器请求连接中的原始目地的,type类型是"type": "ORIGINAL_DST",表明其发到原始的目的地址:端口

 image.png


Inbound Cluster

inbound Cluster是为了pod上的入方向的请求,对于reviews来说,其对应的Inbound Cluster只有一个inbound|9080。

 image.png


Endpoint

从endpoint文件内容可以看到,

reviews Cluster “outbound|9080|v1|reviews.istio-inject.svc.cluster.local”只有1 个endpoint地址,是reviews-v1-74fb8fdbd8-qwsjqpod ip 10.0.3.29

 image.png

image.png

 

至此,我们大概梳理完毕服务网格内两个服务之间访问,istio-proxy日志解读和配置对应关系。

 

6) Tips

前文的config_dump文件太长,解读起来其实比较费力,服务网格提供了asmctl工具可以很方便的去解读listeners,route,cluster,endpoint等,详细信息请见
https://help.aliyun.com/document_detail/313187.html

[root@shycmain ~]# asmctl --asmconfig asmconfig pc listeners productpage-v1-797d845774-dndmk.istio-inject --port 9080
ADDRESS PORT MATCH DESTINATION
0.0.0.0 9080 Trans: raw_buffer; App: HTTP Route: 9080
0.0.0.0 9080 ALL PassthroughCluster
[root@shycmain ~]# asmctl --asmconfig asmconfig pc routes productpage-v1-797d845774-dndmk.istio-inject --name 9080
NOTE: This output only contains routes loaded via RDS.
NAME DOMAINS MATCH VIRTUAL SERVICE
9080 details /*
9080 istio-ingressgateway.istio-system /*
9080 productpage /*
9080 ratings /*
9080 reviews /* reviews.istio-inject
[root@shycmain ~]# asmctl --asmconfig asmconfig pc Cluster productpage-v1-797d845774-dndmk.istio-inject --fqdn reviews.istio-inject.svc.cluster.local
SERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULE
reviews.istio-inject.svc.cluster.local 9080 - outbound EDS reviews.istio-inject
reviews.istio-inject.svc.cluster.local 9080 v1 outbound EDS reviews.istio-inject
reviews.istio-inject.svc.cluster.local 9080 v2 outbound EDS reviews.istio-inject
reviews.istio-inject.svc.cluster.local 9080 v3 outbound EDS reviews.istio-inject
[root@shycmain ~]# asmctl --asmconfig asmconfig pc endpoint productpage-v1-797d845774-dndmk.istio-inject --Cluster "outbound|9080|v1|reviews.istio-inject.svc.cluster.local"
ENDPOINT STATUS OUTLIER CHECK CLUSTER
10.0.3.29:9080 HEALTHY OK outbound|9080|v1|reviews.istio-inject.svc.cluster.local

 7) 小结

本篇文章主要聚焦ASM Istio服务网格模式下,被注入pod的数据面流量转发链路情况。istio灵活注入实现了在Pod维度对流量的定制化配置和观测性,带来了业务链路角度实现的更多种的可能。在服务网格中配置gateway,virtualservice,destinationrule等规则在通过xDS下发到envoy后,会通过listeners,route、cluster、endpoint多个环节最终体现在流量转发规则上

 

那么在运用ASM遇到不符合预期情况时,这些环节都是需要考虑的方向。ASM 除了流量管理,还有安全,鉴权,可观测方面的便捷运用,这些方面的配置,最终也会体现在相关的网格服务资源配置上,感兴趣的小伙伴可以参考ASM官方文档

相关文章
|
6天前
|
Cloud Native Linux 网络虚拟化
深入理解Linux veth虚拟网络设备:原理、应用与在容器化架构中的重要性
在Linux网络虚拟化领域,虚拟以太网设备(veth)扮演着至关重要的角色🌐。veth是一种特殊类型的网络设备,它在Linux内核中以成对的形式存在,允许两个网络命名空间之间的通信🔗。这篇文章将从多个维度深入分析veth的概念、作用、重要性,以及在容器和云原生环境中的应用📚。
深入理解Linux veth虚拟网络设备:原理、应用与在容器化架构中的重要性
|
6天前
|
弹性计算 数据库 Docker
学习阿里云架构设计知识2-wp搭建及配置
VPC分区清晰架构,VSW网络分隔,CEN连通VPC,按量付费小规格,均衡策略,ESS/ACK内置SNAT,ECS用NAT上网。建DMZ需VPC、VSW、NAT、EIP。主系统多VPC/VSW配ECS和Redis,CEN全连接。CEN设路由表,外网访问设DMZ、CEN、EIP,加堡垒机。Web系统ACR部署WordPress,配数据库。验证WordPress、弹性伸缩,测外访、发文、负载。含架构图。
36 1
学习阿里云架构设计知识2-wp搭建及配置
|
6天前
|
运维 Kubernetes Cloud Native
构建高效云原生运维体系:Kubernetes最佳实践
【5月更文挑战第9天】 在动态和快速演变的云计算环境中,高效的运维是确保应用稳定性与性能的关键。本文将深入探讨在Kubernetes环境下,如何通过一系列最佳实践来构建一个高效且响应灵敏的云原生运维体系。文章不仅涵盖了容器化技术的选择与优化、自动化部署、持续集成/持续交付(CI/CD)流程的整合,还讨论了监控、日志管理以及灾难恢复策略的重要性。这些实践旨在帮助运维团队有效应对微服务架构下的复杂性,确保系统可靠性及业务的连续性。
|
1天前
|
存储 弹性计算 Cloud Native
AutoMQ:如何基于阿里云计算与存储产品实现云原生架构升级
AutoMQ:如何基于阿里云计算与存储产品实现云原生架构升级
|
1天前
|
监控 负载均衡 Java
【阿里云云原生专栏】微服务架构在阿里云云原生平台上的应用实例与优化策略
【5月更文挑战第20天】本文介绍了在阿里云云原生平台实现微服务架构的步骤,包括基于Spring Cloud的Docker化部署、使用ACK部署微服务,以及优化策略:服务发现与负载均衡(借助Istio)和监控日志管理。通过这种方式,企业能提升应用的可扩展性、可维护性和敏捷性。
169 5
|
5天前
|
监控 Java 网络性能优化
容器内存可观测性新视角:WorkingSet 与 PageCache 监控
本文介绍了 Kubernetes 中的容器工作内存(WorkingSet)概念,它用于表示容器内存的实时使用量,尤其是活跃内存。
325 12
容器内存可观测性新视角:WorkingSet 与 PageCache 监控
|
6天前
|
Kubernetes Cloud Native 持续交付
构建高效稳定的云原生应用:容器编排与微服务治理实践
【5月更文挑战第14天】 随着企业数字化转型的深入,云原生技术以其弹性、敏捷和可扩展的特性成为现代应用开发的首选模式。本文将探讨如何通过容器编排工具如Kubernetes以及微服务架构的有效治理,构建和维护高效且稳定的云原生应用。我们将分析容器化技术的优势,并结合案例讨论在多云环境下实现持续集成、持续部署(CI/CD)的最佳实践,同时解决微服务带来的分布式复杂性问题。通过本文的阐述,读者将获得一套提升系统可靠性和业务连续性的策略框架。
8 0
|
6天前
|
弹性计算 负载均衡 容灾
应用阿里云弹性计算:打造高可用性云服务器ECS架构
阿里云弹性计算助力构建高可用云服务器ECS架构,通过实例分布、负载均衡、弹性IP、数据备份及多可用区部署,确保业务连续稳定。自动容错和迁移功能进一步增强容灾能力,提供全方位高可用保障。
175 0
|
6天前
|
运维 安全 Linux
深入理解Docker自定义网络:构建高效的容器网络环境
深入理解Docker自定义网络:构建高效的容器网络环境
|
6天前
|
存储 Cloud Native 对象存储
AutoMQ:如何基于阿里云计算与存储产品实现云原生架构升级
AutoMQ[1] 是新一代基于共享存储架构实现的云原生 Kafka。得益于其存算分离的共享存储架构,通过和阿里云合作,深度使用阿里云可靠、先进的云服务如对象存储OSS、块存储 ESSD、弹性伸缩ESS以及抢占式实例实现了相比 Apache Kafka 10倍的成本优势并且提供了自动弹性的能力。
83456 5
AutoMQ:如何基于阿里云计算与存储产品实现云原生架构升级