关于阿里云:全景剖析阿里云容器网络数据链路六ASM-Istio

本系列文章由余凯执笔创作，联结作者：阿里云容器服务谢石对本文亦有奉献

近几年，企业基础设施云原生化的趋势越来越显著，从最开始的IaaS化到当初的微服务化，客户的颗粒度精细化和可观测性的需要也更加强烈。容器网络为了满足客户更高性能和更高密度的需要，也始终在高速的倒退和演进中，这必然给客户对云原生网络的可观测性带来了极高的门槛和挑战。为了进步云原生网络的可观测性，同时便于客户和前后线同学减少对业务链路的可读性，ACK产研和AES联结共建，合作开发了ack net-exporter和云原生网络数据面可观测性系列，帮忙客户和前后线同学理解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学解决疑难问题的体验，进步云原生网络的链路的稳定性。

△ 服务网格示例

△ Istio数据面示意图

Kubernetes的横空呈现突破了底层服务器、底层网络等计算资源的界线，给业务的灵便部署、疾速复原、弹性伸缩、资源效率最大化带来了有限可能。然而业务场景的‘贪心’是有限的，随着微服务趋势大肆倒退，业务上对于同一个service，不同版本和流量管制有着更精细化的颗粒度的需要，最好能实现Pod维度的流量管制，可观测性等等。这些在Kubernetes上是无奈实现的：

从流量角度，K8s最小的管制维度是service，其余比方金丝雀等公布，借助各种ingress controller或者其余组件实现，并且这些也无奈实现Pod之间的流量和连贯状态的可观测性。
K8s给服务微型化，小型化发明了条件，如果前后端服务存在调用关怀，他们如果应用共享通信库，则会在开发阶段就要求所有微服务应用雷同的逻辑语言和堆栈，这从某种程度上又大大限度微服务的独立化，无奈实现齐全的‘不闻不问’
将原来集成在同一个ECS上的服务拆分成不同的模块，这些模块之间调用波及跨ECS等，那么必然须要在代码开发阶段须要思考超时，重试，连贯失败等逻辑机制，而这些与微服务最外围的服务利用其实没有太大关系，然而开发工作往往消耗大量的经验在逻辑设计上。

那么，有没有方法实现上述和微服务的业务齐全隔离呢？Istio的呈现给这个带来了绝对完满的解决方案，让利用这和开发者更加关注业务自身的开发迭代。Istio利用了K8s的Pod概念，会依据使用者的配置，在每个被注入的Pod部署时，主动注入istio-proxy 容器和initial 容器。initial容器的目标是通过批改Pod独自网络命名空间的iptables规定，让须要代理的流量进入到istio-proxy 监听的端口， istio-proxy监听出入两个端口，依据网格配置，来实现对出入流量的代理实现和干涉。而被同一个istio注入的载体，都被视为同一个服务网格之内，他们之间的调用曾经脱离了service的层面，会命中相干的istio cluster配置的endpoint，这样咱们就能够实现Pod维度的流量治理、观测性、安全性等配置。

本文是[全景分析容器网络数据链路]第六局部，次要介绍ASM Istio模式下，数据面链路的转发链路，一是通过理解不同场景下的数据面转发链路，从而探知客户在不同的场景下拜访后果体现的起因，帮忙客户进一步优化业务架构；另一方面，通过深刻理解转发链路，在遇到容器网络抖动时候，客户运维以及阿里云同学能够晓得在哪些链路点进行部署观测手动，从而进一步定界问题方向和起因。

系列一：全景分析阿里云容器网络数据链路（一）：Flannel

系列二：全景分析阿里云容器网络数据链路（二）：Terway ENI

系列三：全景分析阿里云容器网络数据链路（三）：Terway ENIIP

系列四：全景分析阿里云容器网络数据链路（四）：Terway IPVLAN+EBPF

系列五：全景分析阿里云容器网络数据链路（五）：Terway ENI-Trunking

ASM Istio 流量代理

1.1 Pod注入

ASM默认提供了一个Webhook控制器，能够将Sidecar代理主动增加到可用的Pod中。通过上面的命令能够看到ASM注入的集群有个istio-sidecar-injector-1-15-3的mutatingwebhookconfiguration，查看webhook内容，能够看到其中一条就是有 istio-inject：enabled 标签的namespace里的pod创立时候会主动注入。

除了命名空间维度，还有Pod维度，其余注解形式等多种维度实现K8s集群是否被退出到Istio服务网格中。为了充分利用服务网格的所有个性，服务网格中ACK集群的利用Pod必须蕴含一个Sidecar代理。除了手动注入形式外，通常倡议启用主动注入的形式来简化部署，ASM曾经实现了注入配置的可视化操作，具体请见多种形式灵便开启主动注入 [ 1] 。

1.2 Pod流量转发

通过describe被注入的Pod，能够发现Pod中除了设置好的业务container，还多出两个容器：istio-proxy和init container：istio-init。这两个容器的镜像是一样的，只是运行的命令的不一样，这样的益处是只须要拉取一份镜像，节俭了拉取镜像的工夫。

Init Container

Init container 利用的是K8s的个性，一种具备特权的非凡容器，在Pod内的利用容器启动之前运行。Init容器能够包含一些利用镜像中不存在的实用工具和装置脚本。每个Pod中能够蕴含多个容器和多个Init容器。他与一般容器很像，然而有本人独特点：

多个init容器是串行运行的。也就是说多个init容器会依序运行，等上一个init容器运行结束完结后，才会开始运行下一个容器。
只有等到所有的init容器全副运行完结退出后，业务容器才开始启动，在这之前，pod不会处于ready。
如果Pod的Init容器失败，kubelet依据pod设置的restartPolicy进行相应的action。

既然当初理解了Init container的作用，那咱们来看一下istio-init在启动的过程中做了哪些事件，能够通过上面的命令：

kubectl logs -n istio-inject productpage-v1-797d845774-dndmk -c istio-init

能够看到istio-init在启动过程中进行了一连串的iptables规定的生成和配置，比方出方向转发到15001端口；入方向转发到15006端口；拜访15008端口，间接return不进行流量劫持等等。那有什么方法能够自定义配置么？查看pod的信息能够看到相干配置的启动参数，也就通过相干规定实现了出入流量重定向到设置的端口。

-p: 所有出方向的流量被iptables重定向到15001端口

-z: 所有入方向的流量被iptables重定向到15006端口

-u: 用于排除用户ID为1337，能够视为envoy利用自身应用UID 1337

-m: 流量重定向模式，“REDIRECT” 或 “TPROXY”

-i: 重定向出方向的地址范畴， “*” 示意重定向所有出站流量。

-x: 指将从重定向出方向中排除的 IP 地址范畴

-b: 重定向入站端口列表

-d: 重定向入站端口中排除的端口列表

咱们从Pod的视角去察看，将Pod视为一个整体，外面有istio-proxy容器和业务容器APP container

入方向流量转发

依据上文的iptables规定，咱们能够演绎出被入方向代理转发的端口，比方80等，在Pod的网络命名空间netfilter模块通过流程是Client -> RREROUTING -> ISTIO_INBOUND -> ISTIO_IN_REDIRECT -> INPUT -> Envoy 15006（Inbound）-> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> APP 。这样就实现了入方向流量先被转发到sidecar容器后，在转发到业务容器的监听端口。其中在步骤5和6之间，流量会依照设置好的istio规定进行解决。

出方向流量转发

依据上文的iptables规定，咱们能够演绎出被入方向代理转发的端口，比方80等，在Pod的网络命名空间netfilter模块通过流程是APP > OUTPUT -> ISTIO_OUTPUT -> ISTIO_REDIRECT -> Envoy 15001（Outbound）-> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> DST。这样就实现了出方向流量先被转发到sidecar容器后，在转发到目标监听端口。其中在步骤d和e之间，流量会依照设置好的istio规定进行解决。

入方向流量免转发

对于入方向的某些端口或者自定义端口，咱们不须要它通过sidecar容器，iptables规定会设置将符合条件的入方向流量防止转发到15006端口，间接转发到业务容器监听端口 RREROUTING -> ISTIO_INBOUND -> INPUT -> APP。

出方向流量免转发

对于出方向的某些端口或者自定义端口，咱们不须要它通过sidecar容器，iptables规定会设置将符合条件的入方向流量防止转发到15001端口，间接来到Pod的网络命名空间 APP -> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> DST。

Istio-proxy

能够看到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聚合服务发现

咱们曾经晓得了服务网格会在每个注入的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_prot...

envoy-rev.json

能够看到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版本、必要端口等相干信息。

admin

istio-proxy相干日志，治理端口等信息

dynamic_resources

ADS相干配置信息，比方api协定，版本，超时工夫等

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服务器调用地址。

tracing

分布式链路跟踪，这里的collector_cluster是后面static_resources外面定义的zipkin cluster。

拜访日志剖析

通过前文，咱们曾经晓得两个相互被注入的pod拜访，流量会被各自的istio-proxy所劫持并解决，那么只有剖析客户端和服务端的istio-proxy日志并进行加工，就能够对流量进行可观测性解读。咱们在这里还是以官网例子来举例。拜访http://<gatewayIP>/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/obs...

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绝对应

1.3 Envoy配置简读（数据链路）

背景

还是用官网的示例，以productpage拜访reviews服务来举例。

通过Kubernetes集群资源，咱们可一看到reviews有三个版本别离为v1，v2，v3， pod数量各一个。SVC reviews是ClusterIP模式，svc端口是9080， targetport是pod的9080端口，v1，v2，v3 都被加到了reviews SVC的endpointslice。在未被istio注入的状况下，集群内productpage pod拜访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/v1beta1kind: VirtualServicemetadata:  creationTimestamp: '2023-01-30T06:25:21Z'  generation: 1  name: reviews  namespace: istio-inject  resourceVersion: '651722274'  uid: 63f715c9-b253-4fbb-8351-5313371df14espec:  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/v1beta1kind: DestinationRulemetadata:  creationTimestamp: '2023-01-30T06:28:46Z'  generation: 2  name: reviews  namespace: istio-inject  resourceVersion: '654863578'  uid: fdbdfcea-1fcd-453e-96fb-ce41c91ded9bspec:  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

Bootstrap

Envoy的初始化配置，与前文中的envoy-rev0.json是统一的。其中drainDuration —— 热重启期间Envoy敞开连贯的工夫(以秒为单位)，默认是45s。

parentShutdownDuration —— 热重启期间，在齐全敞开父过程之前，等到的最大工夫，默认60s。此数值应该大于drainDuration。

terminationDrainDuration —— 默认5s。proxy在敞开之前，容许连贯敞开工夫。通过前文，咱们晓得pod流量先过istio再被转发到业务容器。当利用发版时候，如果保障现有连贯优雅敞开，保障istio-proxy容器在业务容器齐全敞开现有连贯后，再退出是发版更新时候须要思考的问题，此值是实现业务平滑更新须要思考的。

static_resources

config_dump中动态资源，是来自envoy-rev0.json，外面蕴含了prometheus_stats、agent、sds-grpc、xds-grpc和zipkin等配置

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

Envoy在15001端口创立了Listeners，所有被iptables转发的对外申请都会被转到envoy的15001端口。能够从配置看到，envoy承受到了流量后，并不会做相干的业务动作，而是依据 "use_original_dst": true, 这个配置，根据申请的目标端口转发到相应的listeners 进行解决。

那么必定有个疑难了，如果申请的目标端口并没有配置相干的listeners设置，流量该如何进行解决呢？这个取决于outboundTrafficPolicy的配置，详情请见：
https://istio.io/latest/docs/reference/config/istio.mesh.v1al...

Outbound

outbound监听命名是0.0.0.0_9080，表明发向任何IP地址的9080端口都被此监听涵盖。"bind_to_port”: false此值表明监听没有绑定到tcp端口，流量是有virtualOutbound转发而来的。那么首先咱们须要区别这个监听是为了入方向还是出方向呢？对于入方向，流量会通过15006端口的virtualInbound 的listeners，是不会进入0.0.0.0_9080的listeners。

从配置上能够看到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/side...

    {     "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的配置加载后失效。

通过后面咱们还能够看到默认超时是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 为例

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。

PassthroughCluster

和BlackHoleCluter正好相同，发向PassthroughCluster的申请会被间接发送到器申请连贯中的原始目地的，type类型是"type": "ORIGINAL_DST"，表明其发到原始的目标地址：端口

Inbound Cluster

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

Endpoint

从endpoint文件内容能够看到，reviews cluster “outbound|9080|v1|reviews.istio-inject.svc.cluster.local”只有1个endpoint地址，是reviews-v1-74fb8fdbd8-qwsjq的pod ip 10.0.3.29。

至此，咱们大略梳理结束服务网格内两个服务之间拜访，istio-proxy日志解读和配置对应关系。

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 9080ADDRESS PORT MATCH                        DESTINATION0.0.0.0 9080 Trans: raw_buffer; App: HTTP Route: 90800.0.0.0 9080 ALL                          PassthroughCluster[root@shycmain ~]# asmctl --asmconfig asmconfig pc  routes  productpage-v1-797d845774-dndmk.istio-inject  --name 9080NOTE: This output only contains routes loaded via RDS.NAME     DOMAINS                               MATCH     VIRTUAL SERVICE9080     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.localSERVICE FQDN                               PORT     SUBSET     DIRECTION     TYPE     DESTINATION RULEreviews.istio-inject.svc.cluster.local     9080     -          outbound      EDS      reviews.istio-injectreviews.istio-inject.svc.cluster.local     9080     v1         outbound      EDS      reviews.istio-injectreviews.istio-inject.svc.cluster.local     9080     v2         outbound      EDS      reviews.istio-injectreviews.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     CLUSTER10.0.3.29:9080     HEALTHY     OK                outbound|9080|v1|reviews.istio-inject.svc.cluster.local

企业拥抱容器化总结

本篇文章次要聚焦在ASM Istio服务网格模式下，被注入pod的数据面流量转发链路状况。istio灵便注入实现了在Pod维度对流量的定制化配置和观测性，带来了业务链路角度实现的更多种的可能。在服务网格中配置gateway，virtualservice，destinationrule等规定在通过xDS下发到envoy后，会通过listeners， route、cluster、endpoint等一个环节一个环节最终体现在流量转发规定上。那么在使用ASM遇到不合乎预期状况时，这些环节都是须要思考的方向。ASM除了流量治理，还有平安，鉴权，可观测方面的便捷使用，这些方面的配置，最终也会体现在相干的网格服务资源配置上，感兴趣的小伙伴能够参考ASM官网文档 [ 2] 。

参考链接

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

https://www.envoyproxy.io/docs/envoy/latest/configuration/obs...

[1] 多种形式灵便开启主动注入

https://help.aliyun.com/document_detail/186136.html

[2] 官网文档

https://help.aliyun.com/product/147365.html