全景剖析阿里云容器网络数据链路(六):ASM Istio

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
应用实时监控服务-可观测链路OpenTelemetry版,每月50GB免费额度
简介: 本篇文章主要聚焦在ASM Istio服务网格模式下,被注入pod的数据面流量转发链路情况。istio灵活注入实现了在Pod维度对流量的定制化配置和观测性,带来了业务链路角度实现的更多种的可能。

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


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


1.png

△ 服务网格示例


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

系列二:全景剖析阿里云容器网络数据链路(二):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创建时候会自动注入。


3.png

4.png

5.png


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


6.png


1.2 Pod流量转发


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


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.png9.png


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


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


根据上文的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


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


入方向流量免转发


13.png


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


出方向流量免转发


14.png


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


Istio-proxy


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


我们已经知道了服务网格会在每个注入的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


可以看到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


admin

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


19.png


dynamic_resources

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


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


tracing

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


22.png


访问日志分析


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


23.png


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


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


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


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


27.png

28.png

29.png

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


31.png


Bootstrap


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


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


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


32.png


static_resources


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


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


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


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


从配置上可以看到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

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

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


PassthroughCluster


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


42.png


Inbound Cluster


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


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

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


[2] 官方文档

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

相关文章
|
13天前
|
人工智能 云计算 网络架构
阿里云引领智算集群网络架构的新一轮变革
11月8日~10日在江苏张家港召开的CCF ChinaNet(即中国网络大会)上,众多院士、教授和业界技术领袖齐聚一堂,畅谈网络未来的发展方向,聚焦智算集群网络的创新变革。
阿里云引领智算集群网络架构的新一轮变革
|
6天前
|
云安全 人工智能 安全
阿里云稳居公共云网络安全即服务市占率第一
日前,全球领先的IT市场研究和咨询公司IDC发布了《中国公有云网络安全即服务市场份额,2023:规模稳步增长,技术创新引领市场格局》报告。报告显示,阿里云以27.0%的市场份额蝉联榜首。
|
12天前
|
人工智能 运维 网络架构
阿里云引领智算集群网络架构的新一轮变革
11月8日至10日,CCF ChinaNet(中国网络大会)在江苏张家港召开,众多院士、教授和技术领袖共聚一堂,探讨网络未来发展方向。阿里云研发副总裁蔡德忠发表主题演讲,展望智算技术发展趋势,提出智算网络架构变革的新思路,发布高通量以太网协议和ENode+超节点系统规划,引起广泛关注。阿里云HPN7.0引领智算以太网生态蓬勃发展,成为业界标杆。未来,X10规模的智算集群将面临新的挑战,Ethernet将成为主流方案,推动Scale up与Scale out的融合架构,提升整体系统性能。
|
11天前
|
人工智能 安全 Cloud Native
|
6天前
|
存储 SQL 安全
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
【10月更文挑战第39天】在数字化时代,网络安全和信息安全成为了我们生活中不可或缺的一部分。本文将介绍网络安全漏洞、加密技术和安全意识等方面的内容,帮助读者更好地了解网络安全的重要性,并提供一些实用的技巧和方法来保护自己的信息安全。
19 2
|
7天前
|
安全 网络安全 数据安全/隐私保护
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
【10月更文挑战第38天】本文将探讨网络安全与信息安全的重要性,包括网络安全漏洞、加密技术和安全意识等方面。我们将通过代码示例和实际操作来展示如何保护网络和信息安全。无论你是个人用户还是企业,都需要了解这些知识以保护自己的网络安全和信息安全。
|
6天前
|
存储 安全 网络安全
云计算与网络安全:探索云服务中的信息安全策略
【10月更文挑战第39天】随着云计算的飞速发展,越来越多的企业和个人将数据和服务迁移到云端。然而,随之而来的网络安全问题也日益突出。本文将从云计算的基本概念出发,深入探讨在云服务中如何实施有效的网络安全和信息安全措施。我们将分析云服务模型(IaaS, PaaS, SaaS)的安全特性,并讨论如何在这些平台上部署安全策略。文章还将涉及最新的网络安全技术和实践,旨在为读者提供一套全面的云计算安全解决方案。
|
6天前
|
存储 安全 网络安全
网络安全与信息安全:漏洞、加密技术与安全意识的交织
【10月更文挑战第39天】在数字化时代,网络安全与信息安全成为保护个人隐私和组织资产的重要屏障。本文将探讨网络安全中的常见漏洞、加密技术的应用以及提升安全意识的重要性。通过具体案例分析,我们将深入了解网络攻击的手段和防御策略,同时提供实用建议,以增强读者对网络安全的认识和防护能力。
|
6天前
|
安全 网络安全 数据安全/隐私保护
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
【10月更文挑战第39天】在数字化时代,网络安全和信息安全已成为我们生活中不可或缺的一部分。本文将探讨网络安全漏洞、加密技术以及安全意识等方面的内容,帮助读者更好地了解网络安全的重要性,并提供一些实用的技巧和建议来保护个人信息和设备安全。
|
9天前
|
SQL 安全 物联网
网络安全与信息安全:深入探讨网络漏洞、加密技术及安全意识###
网络安全与信息安全是当今数字化时代的重要议题。本文将详细探讨网络安全和信息安全的差异,重点介绍常见的网络漏洞、加密技术以及如何提升用户和组织的安全意识。通过具体案例和技术分析,帮助读者理解这些关键概念,并提供实用的建议以应对潜在的网络威胁。 ###

相关产品

  • 服务网格