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

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

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bcb9d53df16f46afa59deb3af07ad33e~tplv-k3u1fbpfcp-zoom-1.image "1.png")

△ 服务网格示例

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b3970c41d89b442ca141eedd5f99ae21~tplv-k3u1fbpfcp-zoom-1.image "2.png")

△ Istio数据面示意图

Kubernetes的横空出现打破了底层服务器、底层网络等计算资源的界限，给业务的灵活部署、快速恢复、弹性伸缩、资源效率最大化带来了无限可能。但是业务场景的‘贪婪’是无限的，随着微服务趋势大肆发展，业务上对于同一个service，不同版本和流量控制有着更精细化的颗粒度的需求，最好能实现Pod维度的流量控制，可观测性等等。这些在Kubernetes上是无法实现的：

1. 从流量角度，K8s最小的控制维度是service，其他比如金丝雀等发布，借助各种ingress controller或者其他组件实现，并且这些也无法实现Pod之间的流量和连接状态的可观测性。

2. K8s给服务微型化，小型化创造了条件，如果前后端服务存在调用关心，他们如果使用共享通信库，则会在开发阶段就要求所有微服务使用相同的逻辑语言和堆栈，这从某种程度上又大大限制微服务的独立化，无法实现完全的‘漠不关心’

3. 将原来集成在同一个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](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247548965&idx=2&sn=5aa3136e0284c711a6d248b962451425&chksm=fae60beacd9182fc5a68155828b0bfeea5b5e6a11d37498135518b57eeea52a2af48518647d9&scene=21#wechat_redirect)

系列二：[全景剖析阿里云容器网络数据链路（二）：Terway ENI](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247549033&idx=2&sn=200568b3a96d7a7a1472ca6e10ba5430&chksm=fae60ba6cd9182b06398c7bc0b077b03de51565c8f0328963e75edf8110a8057e7d4698a7fd9&scene=21#wechat_redirect)

系列三：[全景剖析阿里云容器网络数据链路（三）：Terway ENIIP](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247549103&idx=1&sn=eca4c835eed6d29802080701ef04c1db&chksm=fae60b60cd918276eeb55e80b36bb2da6ef1a9cffb88f0c69421cfc502b13a6cce52546490ab&scene=21#wechat_redirect)

系列四：[全景剖析阿里云容器网络数据链路（四）：Terway IPVLAN+EBPF](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247549599&idx=1&sn=d2c0909ecfa52c7ce38eba902d157ead&chksm=fae60950cd9180467b2116eb47def41c1a68c216c8034ac22262724e668604f95b08ddd88e0b&scene=21#wechat_redirect)

系列五：[全景剖析阿里云容器网络数据链路（五）：Terway ENI-Trunking](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247549961&idx=2&sn=f98f7f9a6b1432705fe6d582ab859e6b&chksm=fae60fc6cd9186d02553770c026e820ac5000524c848a78d3b6fae4166bb3c4f2a1720bbde7e&scene=21#wechat_redirect)

## ASM Istio 流量代理

### 1.1 Pod注入

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

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a1199d206ed493f806a61d685e662e2~tplv-k3u1fbpfcp-zoom-1.image "3.png")

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/72adb6efc6674fcd971963b4d072a058~tplv-k3u1fbpfcp-zoom-1.image "4.png")

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aad454c8267e4ffda33bdf698c048606~tplv-k3u1fbpfcp-zoom-1.image "5.png")

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

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8920b6d3bb8648c7bb0516f08b5b54ea~tplv-k3u1fbpfcp-zoom-1.image "6.png")

### 1.2 Pod流量转发

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

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/88dcbca28a19499486cb8e3b97966660~tplv-k3u1fbpfcp-zoom-1.image "7.png")

#### Init Container

Init container 利用的是K8s的特性，一种具有特权的特殊容器，在Pod内的应用容器启动之前运行。Init容器可以包括一些应用镜像中不存在的实用工具和安装脚本。每个Pod中可以包含多个容器和多个Init容器。他与普通容器很像，但是有自己独特点：

1. 多个init容器是串行运行的。也就是说多个init容器会依序运行，等上一个init容器运行完毕结束后，才会开始运行下一个容器。

2. 只有等到所有的init容器全部运行结束退出后，业务容器才开始启动，在这之前，pod不会处于ready。

3. 如果Pod的Init容器失败，kubelet根据pod设置的restartPolicy进行相应的action。

既然现在了解了Init container的作用，那我们来看一下istio-init在启动的过程中做了哪些事情，可以通过下面的命令：

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

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1920ab22ad6f4159bb57a46dac56ce2b~tplv-k3u1fbpfcp-zoom-1.image "8.png")

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c18feae64b3f4e66a41f8b497e50c2a4~tplv-k3u1fbpfcp-zoom-1.image "9.png")

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

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fbc960ddbab9473fa5f0dcae7a41133d~tplv-k3u1fbpfcp-zoom-1.image "10.png")

-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

##### 入方向流量转发

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6ec4bdbb8d874498abdef624401d0fbd~tplv-k3u1fbpfcp-zoom-1.image "11.png")

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

##### 出方向流量转发

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9410935c4aed49ecab4ee094a1f917f0~tplv-k3u1fbpfcp-zoom-1.image "12.png")

根据上文的iptables规则，我们可以归纳出被入方向代理转发的端口，比如80等，在Pod的网络命名空间netfilter模块经过流程是APP > OUTPUT -> ISTIO_OUTPUT -> ISTIO_REDIRECT -> Envoy 15001（Outbound）-> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> DST。这样就实现了出方向流量先被转发到sidecar容器后，在转发到目的监听端口。其中在步骤d和e之间，流量会按照设置好的istio规则进行处理。

##### 入方向流量免转发

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a801e32eb6cb402a819d5b200dc4133e~tplv-k3u1fbpfcp-zoom-1.image "13.png")

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

##### 出方向流量免转发

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e3516ff5a1864fb4b0499992a6c22e4e~tplv-k3u1fbpfcp-zoom-1.image "14.png")

对于出方向的某些端口或者自定义端口，我们不需要它经过sidecar容器，iptables规则会设置将符合条件的入方向流量避免转发到15001端口，直接离开Pod的网络命名空间 APP -> OUTPUT -> ISTIO_OUTPUT -> POSTROUTING -> DST。

#### Istio-proxy

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f8e9361e19d7425db898ba4320bd1ac3~tplv-k3u1fbpfcp-zoom-1.image "15.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聚合服务发现

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f141065311e1446f9789e961d535e8f0~tplv-k3u1fbpfcp-zoom-1.image "16.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

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/616daac40b5c4b92ba8f487cf0e57dac~tplv-k3u1fbpfcp-zoom-1.image "17.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版本、必要端口等相关信息。

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/db2200b6b634416e8fad908c758758f6~tplv-k3u1fbpfcp-zoom-1.image "18.png")

admin

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

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4260260dc072493586f36ef9fb3a7f5a~tplv-k3u1fbpfcp-zoom-1.image "19.png")

dynamic_resources

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

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c333606b022846c1b851765b7a140ca2~tplv-k3u1fbpfcp-zoom-1.image "20.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服务器调用地址。

![21.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e951dc44490344cc90a337ecb6d5f0d3~tplv-k3u1fbpfcp-zoom-1.image "21.png")

tracing

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

![22.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0546fb5a1022438f83bfe4b3aafee90d~tplv-k3u1fbpfcp-zoom-1.image "22.png")

##### 访问日志分析

通过前文，我们已经知道两个互相被注入的pod访问，流量会被各自的istio-proxy所劫持并处理，那么只要分析客户端和服务端的istio-proxy日志并进行加工，就可以对流量进行可观测性解读。我们在这里还是以官方例子来举例。访问http://<gatewayIP>/productpage ， productpage应用会自动调用details服务，reviews服务。我们以productpage和details之间链路来进行举例分析。

![23.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6d19ddde5198423193ec11abd930feb2~tplv-k3u1fbpfcp-zoom-1.image "23.png")

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

![24.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c8763028aa5741efb1055a178fa436d4~tplv-k3u1fbpfcp-zoom-1.image "24.png")

请求发送方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>*

![25.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dee4d1cca04f402caf43245f7a9bd47f~tplv-k3u1fbpfcp-zoom-1.image "25.png")

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配置简读（数据链路）

#### 背景

![26.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8a0a7e54f17d4607b3b1740a0f81389a~tplv-k3u1fbpfcp-zoom-1.image "26.png")

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

![27.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f085e822269946e68a85fa91ba88e0fd~tplv-k3u1fbpfcp-zoom-1.image "27.png")

![28.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/541fea75b348455fa271d31977824922~tplv-k3u1fbpfcp-zoom-1.image "28.png")

![29.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/802488ef248f47ee916884736b9af0e6~tplv-k3u1fbpfcp-zoom-1.image "29.png")

![30.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e23deaad42874d429f36643f66f55ffa~tplv-k3u1fbpfcp-zoom-1.image "30.png")

通过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/v1beta1

kind: VirtualService

metadata:

creationTimestamp: '2023-01-30T06:25:21Z'

generation: 1

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

namespace: istio-inject

resourceVersion: '654863578'

uid: fdbdfcea-1fcd-453e-96fb-ce41c91ded9b

spec:

host: reviews

subsets:

- labels:

version: v1

- labels:

version: v2

- labels:

version: 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

```

![31.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bf2cdd2c78744ba483e7e78fdce275aa~tplv-k3u1fbpfcp-zoom-1.image "31.png")

#### Bootstrap

Envoy的初始化配置，与前文中的envoy-rev0.json是一致的。其中drainDuration —— 热重启期间Envoy关闭连接的时间(以秒为单位)，默认是45s。

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

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

![32.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/75912bc617f946888a304533acfc0713~tplv-k3u1fbpfcp-zoom-1.image "32.png")

#### static_resources

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

![33.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/079ae15f73bf472880e35956219717c0~tplv-k3u1fbpfcp-zoom-1.image "33.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

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

![34.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b0ac5dbb2f2440e1aaca869441e2fd15~tplv-k3u1fbpfcp-zoom-1.image "34.png")

那么肯定有个疑问了，如果请求的目的端口并没有配置相关的listeners设置，流量该如何进行处理呢？这个取决于outboundTrafficPolicy的配置，详情请见：

*<https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-Mode>*

![35.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f6eb31f4a887470abc9f45a2dd7c26d5~tplv-k3u1fbpfcp-zoom-1.image "35.png")

##### Outbound

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

![36.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52709638d1964e0bae5f26a073cb4057~tplv-k3u1fbpfcp-zoom-1.image "36.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的配置加载后生效。

![37.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d6b8d0567e024178939c25ec776ba2e2~tplv-k3u1fbpfcp-zoom-1.image "37.png")

![38.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/84661d163b8f4090943b425196302cf1~tplv-k3u1fbpfcp-zoom-1.image "38.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 为例

![39.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0db4158f50a74b2a87300741bc9721d0~tplv-k3u1fbpfcp-zoom-1.image "39.png")

![40.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/877c0a949fbf4375b6d3d948ca41023f~tplv-k3u1fbpfcp-zoom-1.image "40.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。

![41.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d447e5d7ea48467e9432868c634507cd~tplv-k3u1fbpfcp-zoom-1.image "41.png")

##### PassthroughCluster

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

![42.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/37249860ae864852ac0feab80d75aa64~tplv-k3u1fbpfcp-zoom-1.image "42.png")

##### Inbound Cluster

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

![43.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e83cdc47c04942b29372f899a2eb74f5~tplv-k3u1fbpfcp-zoom-1.image "43.png")

#### 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。

![44.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2739d394caa44e2ba18bcd77d31dc9c5~tplv-k3u1fbpfcp-zoom-1.image "44.png")

![45.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2c1c92b02d494ee7b9a014831468c6e1~tplv-k3u1fbpfcp-zoom-1.image "45.png")

至此，我们大概梳理完毕服务网格内两个服务之间访问，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 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

```

## 企业拥抱容器化总结

本篇文章主要聚焦在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/sidecar/>*

*<https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage>*

[1] 多种方式灵活开启自动注入

*[https://help.aliyun.com/document_detail/186136.html](https://help.aliyun.com/document_detail/186136.html?spm=a2c6h.13046898.0.0.2ba16ffaONX4U0)*

[2] 官方文档

*[https://help.aliyun.com/product/147365.html](https://help.aliyun.com/product/147365.html?spm=a2c6h.13046898.0.0.2ba16ffaONX4U0)*

ITPub博客

全景剖析阿里云容器网络数据链路（六）：ASM Istio

最新文章