更多精彩内容，欢迎观看：
《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——6. ASM Istio 模式架构设计（上）：https://developer.aliyun.com/article/1221374?groupCode=supportservice
4) 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_protocol
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:///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配置简读（数据链路）
背景
还是用官方的示例，以productpage 访问 reviews 服务来举例。
通过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
更多精彩内容，欢迎观看：
《云原生网络数据面可观测性最佳实践》——二、全景剖析阿里云容器网络数据链路——6. ASM Istio 模式架构设计（下）：https://developer.aliyun.com/article/1221371?groupCode=supportservice
