前面我们创建了一个 Gateway 和 VirtualService 对象，用来对外暴露应用，然后我们就可以通过 ingressgateway 来访问 Bookinfo 应用了。那么这两个资源对象是如何实现的呢？
Gateway 资源是用来配置允许外部流量进入 Istio 服务网格的流量入口，用于接收传入的 HTTP/TCP 连接。它会配置暴露的端口、协议等，但与 Kubernetes Ingress 资源不同，不会包括任何流量路由配置，真正的路由规则是通过 VirtualService 来配置的。
我们再查看一下前面创建的 Gateway 对象的定义：
代码语言：javascript复制# samples/bookinfo/networking/bookinfo-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway
spec:
selector: # 如果使用的是 Helm 方式安装，则默认应该是 istio=ingress 标签
istio: ingressgateway # 匹配 ingress gateway pod 的标签（kubectl get pods -l istio=ingressgateway -n istio-system）
servers:
- port:
number: 8080
name: http
protocol: HTTP
hosts:
- "*"
这里定义的 Gateway 对象中有一个 selector 标签选择器，它会匹配 istio=ingressgateway 标签的 Pod，其实就是 istio-ingressgateway 这个组件。
其实本质上 istio-ingressgateway 也是一个 Envoy 代理，用来作为 Istio 的统一入口网关，它会接收外部流量，然后根据 VirtualService 中定义的路由规则来进行流量的转发。
我们可以查看下 istio-ingressgateway 的 Envoy 配置来验证下：
# 进入 ingressgateway 组件所在的 Pod 中
$ kubectl exec -it istio-ingressgateway-9c8b9b586-s6s48 -n istio-system -- /bin/bash
istio-proxy@istio-ingressgateway-9c8b9b586-s6s48:/$ ll /etc/istio/proxy
total 20
drwxrwsrwx 2 root istio-proxy 66 Nov 3 02:16 ./
drwxr-xr-x 7 root root 103 Nov 3 02:16 ../
srw-rw-rw- 1 istio-proxy istio-proxy 0 Nov 3 02:16 XDS=
-rw-r--r-- 1 istio-proxy istio-proxy 14130 Nov 3 02:16 envoy-rev.json
-rw-r--r-- 1 istio-proxy istio-proxy 2699 Nov 3 02:16 grpc-bootstrap.json
istio-proxy@istio-ingressgateway-9c8b9b586-s6s48:/$
在 istio-ingressgateway 组件的 Pod 目录中有一个配置文件 envoy-rev.json，这个文件就是 Envoy 的配置文件，该文件通过 istio 为 sidecar 注入的参数在启动的时候修改或生成，由于这里采用的是 xDS 动态配置的方式，所以直接看不到前面我们添加的 Gateway 相关信息的，但是我们可以利用 Envoy 的 Admin 提供的 config_dump 来查看下配置文件：
kubectl exec istio-ingressgateway-9c8b9b586-s6s48 -c istio-proxy -n istio-system -- curl 'localhost:15000/config_dump' > ingressgateway_envoy_conf.json
istio envoy 默认配置为 json 格式，导出来的配置文件非常长（有 10000 行），我们可以先只看上层内容：
istio envoy 配置
我们可以看到这个配置文件中其实就一个 configs 数组，每个元素都是一项配置，每个配置都指定了一个独特的 @type 字段，来指定该配置是是干嘛的。接下来我们就来看下这个配置文件中的每个配置项都是干嘛的。
BootStrapConfigDump
用于在 Envoy 启动时加载的一些静态配置，包括类似 Sidecar 的环境变量等信息。我们也可以使用 istioctl proxy-config bootstrap 命令来查看这部分配置：
$ istioctl proxy-config bootstrap istio-ingressgateway-9c8b9b586-s6s48 -n istio-system -o yaml
bootstrap:
admin:
address:
socketAddress:
address: 127.0.0.1
portValue: 15000
profilePath: /var/lib/istio/data/envoy.prof
dynamicResources: # 动态配置发现服务信息
adsConfig:
apiType: GRPC
grpcServices:
- envoyGrpc:
clusterName: xds-grpc
setNodeOnFirstMessageOnly: true
transportApiVersion: V3
cdsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
ldsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
node: # 节点信息
cluster: istio-ingressgateway.istio-system
id: router~10.244.2.52~istio-ingressgateway-9c8b9b586-s6s48.istio-system~istio-system.svc.cluster.local
# ......
staticResources:
clusters:
- connectTimeout: 0.250s # prometheus cluster
loadAssignment:
clusterName: prometheus_stats
endpoints:
- lbEndpoints:
- endpoint:
address:
socketAddress:
address: 127.0.0.1
portValue: 15000
name: prometheus_stats
type: STATIC
- connectTimeout: 0.250s # agent cluster
loadAssignment:
clusterName: agent
endpoints:
- lbEndpoints:
- endpoint:
address:
socketAddress:
address: 127.0.0.1
portValue: 15020
name: agent
type: STATIC
- connectTimeout: 1s
loadAssignment:
clusterName: sds-grpc
endpoints:
- lbEndpoints:
- endpoint:
address:
pipe:
path: ./var/run/secrets/workload-spiffe-uds/socket
name: sds-grpc
type: STATIC
typedExtensionProtocolOptions:
envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
'@type': type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
explicitHttpConfig:
http2ProtocolOptions: {}
- circuitBreakers:
thresholds:
- maxConnections: 100000
maxPendingRequests: 100000
maxRequests: 100000
- maxConnections: 100000
maxPendingRequests: 100000
maxRequests: 100000
priority: HIGH
connectTimeout: 1s
loadAssignment: # xds-grpc cluster
clusterName: xds-grpc
endpoints:
- lbEndpoints:
- endpoint:
address:
pipe:
path: ./etc/istio/proxy/XDS
maxRequestsPerConnection: 1
name: xds-grpc
type: STATIC
typedExtensionProtocolOptions:
envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
'@type': type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
explicitHttpConfig:
http2ProtocolOptions: {}
upstreamConnectionOptions:
tcpKeepalive:
keepaliveTime: 300
- connectTimeout: 1s
dnsLookupFamily: V4_ONLY
dnsRefreshRate: 30s
loadAssignment: # zipkin cluster
clusterName: zipkin
endpoints:
- lbEndpoints:
- endpoint:
address:
socketAddress:
address: zipkin.istio-system
portValue: 9411
name: zipkin
respectDnsTtl: true
type: STRICT_DNS
listeners:
- address:
socketAddress:
address: 0.0.0.0
portValue: 15090 # prometheus listener
filterChains:
- filters:
- name: envoy.filters.network.http_connection_manager
typedConfig:
'@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
httpFilters:
- name: envoy.filters.http.router
typedConfig:
'@type': type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
routeConfig:
virtualHosts:
- domains:
- '*'
name: backend
routes:
- match:
prefix: /stats/prometheus
route:
cluster: prometheus_stats
statPrefix: stats
- address:
socketAddress:
address: 0.0.0.0
portValue: 15021 # agent listener（健康检查）
filterChains:
- filters:
- name: envoy.filters.network.http_connection_manager
typedConfig:
'@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
httpFilters:
- name: envoy.filters.http.router
typedConfig:
'@type': type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
routeConfig:
virtualHosts:
- domains:
- '*'
name: backend
routes:
- match:
prefix: /healthz/ready
route:
cluster: agent
statPrefix: agent
statsConfig:
# ......
tracing: # 链路追踪
http:
name: envoy.tracers.zipkin
typedConfig:
'@type': type.googleapis.com/envoy.config.trace.v3.ZipkinConfig
collectorCluster: zipkin
collectorEndpoint: /api/v2/spans
collectorEndpointVersion: HTTP_JSON
sharedSpanContext: false
traceId128bit: true
上面的配置和之前我们介绍的 Envoy 配置基本一致，在上面配置中定义了一个 Prometheus 监听器，用来暴露 Prometheus 监控指标，还定义了一个 Agent 监听器，用来暴露健康检查接口，另外还定义了一个 zipkin 集群，用来定义链路追踪的配置。另外通过 dynamicResources 定义了动态配置发现服务信息，xds-grpc 就是用来定义 Envoy 与 Pilot 之间的 xDS 通信的。
ListenersConfigDump
这里存储着 Envoy 的 listeners 配置，也就是 Envoy 的监听器。Envoy 在拦截到请求后，会根据请求的地址与端口，将请求交给匹配的 listener 处理。
我们看到这个 ListenersConfigDump 中的 listener 配置分成了 static_listners 和 dynamic_listeners，分别对应 Envoy 的静态配置和动态配置，静态配置，是 Envoy 配置文件中直接指定的，而 dynamic_listeners的 listener 则是 istiod 通过 xDS 协议为 Envoy 下发的。
同样我们也可以使用 istioctl proxy-config listener 命令来查看这部分配置：
istioctl proxy-config listener istio-ingressgateway-9c8b9b586-s6s48 -n istio-system -o yaml
对应的配置文件如下所示：
代码语言：javascript复制- accessLog:
- filter:
responseFlagFilter:
flags:
- NR
name: envoy.access_loggers.file
typedConfig:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
logFormat:
textFormatSource:
inlineString: |
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% "%UPSTREAM_TRANSPORT_FAILURE_REASON%" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%
path: /dev/stdout
address:
socketAddress:
address: 0.0.0.0
portValue: 8080
continueOnListenerFiltersTimeout: true
filterChains:
- filters:
- name: istio_authn
typedConfig:
"@type": type.googleapis.com/udpa.type.v1.TypedStruct
typeUrl: type.googleapis.com/io.istio.network.authn.Config
- name: envoy.filters.network.http_connection_manager
typedConfig:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
accessLog:
- name: envoy.access_loggers.file
typedConfig:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
logFormat:
textFormatSource:
inlineString: |
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% "%UPSTREAM_TRANSPORT_FAILURE_REASON%" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%
path: /dev/stdout
forwardClientCertDetails: SANITIZE_SET
httpFilters:
- name: istio.metadata_exchange
typedConfig:
"@type": type.googleapis.com/udpa.type.v1.TypedStruct
typeUrl: type.googleapis.com/io.istio.http.peer_metadata.Config
value:
upstream_discovery:
- istio_headers: {}
- workload_discovery: {}
upstream_propagation:
- istio_headers: {}
- name: envoy.filters.http.grpc_stats
typedConfig:
"@type": type.googleapis.com/envoy.extensions.filters.http.grpc_stats.v3.FilterConfig
emitFilterState: true
statsForAllMethods: false
- name: istio.alpn
typedConfig:
"@type": type.googleapis.com/istio.envoy.config.filter.http.alpn.v2alpha1.FilterConfig
alpnOverride:
- alpnOverride:
- istio-http/1.0
- istio
- http/1.0
- alpnOverride:
- istio-http/1.1
- istio
- http/1.1
upstreamProtocol: HTTP11
- alpnOverride:
- istio-h2
- istio
- h2
upstreamProtocol: HTTP2
- name: envoy.filters.http.fault
typedConfig:
"@type": type.googleapis.com/envoy.extensions.filters.http.fault.v3.HTTPFault
- name: envoy.filters.http.cors
typedConfig:
"@type": type.googleapis.com/envoy.extensions.filters.http.cors.v3.Cors
- name: istio.stats
typedConfig:
"@type": type.googleapis.com/stats.PluginConfig
disableHostHeaderFallback: true
- name: envoy.filters.http.router
typedConfig:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
httpProtocolOptions: {}
normalizePath: true
pathWithEscapedSlashesAction: KEEP_UNCHANGED
rds:
configSource:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
routeConfigName: http.8080
requestIdExtension:k
typedConfig:
"@type": type.googleapis.com/envoy.extensions.request_id.uuid.v3.UuidRequestIdConfig
useRequestIdForTraceSampling: true
serverName: istio-envoy
setCurrentClientCertDetails:
cert: true
dns: true
subject: true
uri: true
statPrefix: outbound_0.0.0.0_8080
streamIdleTimeout: 0s
tracing:
# ......
upgradeConfigs:
- upgradeType: websocket
useRemoteAddress: true
name: 0.0.0.0_8080
trafficDirection: OUTBOUND
- address:
socketAddress:
address: 0.0.0.0
portValue: 15090
# ......
- address:
socketAddress:
address: 0.0.0.0
portValue: 15021
# ......
虽然上面看到的 listener 配置还是很长，但是我们应该也还是非常熟悉的，本质就是 Envoy 的配置文件中的 listener 配置。我们这里重点看下动态配置对应的配置，静态的就是前面指定 prometheus 和 agent 对应的监听器配置。
我们可以看到上面的动态配置对应的监听器名称为 0.0.0.0_8080，对应的监听地址为 0.0.0.0:8080，也就是说在 Envoy 中监听了 8080 端口：
address:
socketAddress:
address: 0.0.0.0
portValue: 8080
而前面我们是不是创建了一个 Gateway 资源对象，并指定了 8080 端口，其实这个端口就是我们前面创建的 Gateway 对象中定义的端口，这个监听器的配置就是通过 istiod 通过 xDS 协议下发的。
那么请求是如何到达这个监听器的呢？我们可以查看下 istio-ingressgateway 组建的 Service 数据：
$ kubectl get svc istio-ingressgateway -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.103.227.57 <pending> 15021:32459/TCP,80:31896/TCP,443:30808/TCP,31400:31535/TCP,15443:30761/TCP 46h
我们可以看到 istio-ingressgateway 组件的 Service 中定义了 5 个端口，还记得前面我们去访问 Productpage 的时候是如何访问的吗？是不是通过 http://$GATEWAY_URL/productpage 访问的，而我们这里没有 LoadBalancer，所以直接使用 NodePort 形式访问就行，最终我们是通过 http://NodeIP:31896/productpage 来访问应用的，而这个 31896 端口对应 istio-ingressgateway 组件的 Service 中定义的 80 端口，也就是说我们的请求是通过 80 端口到达 istio-ingressgateway 组件的，那么这个 80 端口是如何到达 istio-ingressgateway 组件的呢？
$ kubectl describe svc istio-ingressgateway -n istio-system
Name: istio-ingressgateway
Namespace: istio-system
# ......
Port: http2 80/TCP
TargetPort: 8080/TCP
NodePort: http2 31896/TCP
Endpoints: 10.244.2.52:8080
我们查看 Service 的定义就明白了，实际上 istio-ingressgateway 这个 Service 定义的 80 端口对应的是 istio-ingressgateway 组件 Pod 的 8080 端口，也就是说我们的请求是通过 80 端口到达 istio-ingressgateway 组件的 8080 端口的，而这个 8080 端口就是我们前面在 Envoy 配置中看到的监听器的端口了，所以当我们访问 http://$GATEWAY_URL/productpage 的时候请求到达了 istio-ingressgateway 这个组件的 8080 端口了。
当请求到达 istio-ingressgateway 组件时，就会被这个监听器所匹配，然后将请求交给 http_connection_manager 这个 filter 来处理，当然后面就是用各种具体的 filter 来处理请求了，比如 envoy.filters.http.fault 这个 filter 就是用来处理故障注入的，envoy.filters.http.router 则是用来处理路由转发的、envoy.filters.http.cors 则是用来处理跨域请求的等等。
但是我们的请求进到 Envoy 后是又该如何路由呢？我应该将请求转发到哪里去呢？这个是不是就是 Envoy 中的路由配置来决定的了，对于静态配置我们清楚直接在 Envoy 配置文件中就可以看到，比如：
代码语言：javascript复制routeConfig:
virtualHosts:
- domains:
- "*"
name: backend
routes:
- match:
prefix: /healthz/ready
route:
cluster: agent
但是我们这里的路由配置是动态配置的，我们看到对应的配置中有一个 rds 字段，这个字段就是用来指定动态路由配置的，其中的 routeConfigName 字段就是用来指定对应的路由配置名称的：
rds:
configSource:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
routeConfigName: http.8080
RoutesConfigDump
这里面保存着 Envoy 的路由配置，和 listeners 一样，RoutesConfigDump 也分为 static_route_configs 和 dynamic_route_configs，分别对应着静态的路由配置和动态下发的路由配置。
同样我们也可以使用 istioctl proxy-config route 命令来查看这部分配置：
istioctl proxy-config route istio-ingressgateway-9c8b9b586-s6s48 -n istio-system -o yaml
对应的配置如下所示：
代码语言：javascript复制- ignorePortInHostMatching: true
maxDirectResponseBodySizeBytes: 1048576
name: http.8080
validateClusters: false
virtualHosts:
- domains:
- "*"
includeRequestAttemptCount: true
name: "*:8080"
routes:
- decorator:
operation: productpage.default.svc.cluster.local:9080/productpage
match:
caseSensitive: true
path: /productpage
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/bookinfo
route:
cluster: outbound|9080||productpage.default.svc.cluster.local
maxGrpcTimeout: 0s
retryPolicy:
hostSelectionRetryMaxAttempts: "5"
numRetries: 2
retriableStatusCodes:
- 503
retryHostPredicate:
- name: envoy.retry_host_predicates.previous_hosts
typedConfig:
"@type": type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
timeout: 0s
- decorator:
operation: productpage.default.svc.cluster.local:9080/static*
match:
caseSensitive: true
prefix: /static
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/bookinfo
route:
cluster: outbound|9080||productpage.default.svc.cluster.local
maxGrpcTimeout: 0s
retryPolicy:
hostSelectionRetryMaxAttempts: "5"
numRetries: 2
retriableStatusCodes:
- 503
retryHostPredicate:
- name: envoy.retry_host_predicates.previous_hosts
typedConfig:
"@type": type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
timeout: 0s
- decorator:
operation: productpage.default.svc.cluster.local:9080/login
match:
caseSensitive: true
path: /login
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/bookinfo
route:
cluster: outbound|9080||productpage.default.svc.cluster.local
maxGrpcTimeout: 0s
retryPolicy:
hostSelectionRetryMaxAttempts: "5"
numRetries: 2
retriableStatusCodes:
- 503
retryHostPredicate:
- name: envoy.retry_host_predicates.previous_hosts
typedConfig:
"@type": type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
timeout: 0s
- decorator:
operation: productpage.default.svc.cluster.local:9080/logout
match:
caseSensitive: true
path: /logout
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/bookinfo
route:
cluster: outbound|9080||productpage.default.svc.cluster.local
maxGrpcTimeout: 0s
retryPolicy:
hostSelectionRetryMaxAttempts: "5"
numRetries: 2
retriableStatusCodes:
- 503
retryHostPredicate:
- name: envoy.retry_host_predicates.previous_hosts
typedConfig:
"@type": type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
timeout: 0s
- decorator:
operation: productpage.default.svc.cluster.local:9080/api/v1/products*
match:
caseSensitive: true
prefix: /api/v1/products
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/bookinfo
route:
cluster: outbound|9080||productpage.default.svc.cluster.local
maxGrpcTimeout: 0s
retryPolicy:
hostSelectionRetryMaxAttempts: "5"
numRetries: 2
retriableStatusCodes:
- 503
retryHostPredicate:
- name: envoy.retry_host_predicates.previous_hosts
typedConfig:
"@type": type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
timeout: 0s
- virtualHosts:
- domains:
- "*"
name: backend
routes:
- match:
prefix: /stats/prometheus
route:
cluster: prometheus_stats
- virtualHosts:
- domains:
- "*"
name: backend
routes:
- match:
prefix: /healthz/ready
route:
cluster: agent
后面的两个 virtualHosts 就是我们的静态路由配置，第一个是动态的路由配置，我们可以看到该配置的名称就是 http.8080，是不是和前面的 routeConfigName 是一致的。那么这个配置又是什么地方定义的呢？
其实仔细看这里面的配置和前面我们创建的 VirtualService 这个资源对象是不是很像，我们再看下前面创建的 VirtualService 对象的定义：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo
spec:
hosts:
- "*"
gateways:
- bookinfo-gateway
http:
- match:
- uri:
exact: /productpage
- uri:
prefix: /static
- uri:
exact: /login
- uri:
exact: /logout
- uri:
prefix: /api/v1/products
route:
- destination:
host: productpage
port:
number: 9080
我们可以看到在 VirtualService 对象中定义了 5 个路由规则，而这里的 RoutesConfigDump 中也定义了 5 个路由规则，VirtualService 中定义的 5 个路由分别为 /productpage、/static、/login、/logout、/api/v1/products，而 RoutesConfigDump 中定义的 5 个路由分别为 /productpage、/static、/login、/logout、/api/v1/products，是不是一一对应的。最终匹配这些路由规则的请求是被转发到 productpage 这个服务的 9080 端口的。
比如 /productpage 这个路由规则对应的 Envoy 配置如下所示：
- domains:
- "*"
includeRequestAttemptCount: true
name: "*:8080"
routes:
- decorator:
operation: productpage.default.svc.cluster.local:9080/productpage
match:
caseSensitive: true
path: /productpage
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/bookinfo
route:
cluster: outbound|9080||productpage.default.svc.cluster.local
maxGrpcTimeout: 0s
retryPolicy:
hostSelectionRetryMaxAttempts: "5"
numRetries: 2
retriableStatusCodes:
- 503
retryHostPredicate:
- name: envoy.retry_host_predicates.previous_hosts
typedConfig:
"@type": type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
timeout: 0s
这个配置就是我们熟悉的 Envoy 的关于虚拟主机部分的配置，比如当我们请求的路径为 /productpage 时，就会被这个路由规则匹配到，然后就用通过 route 字段来描述我们的路由目标了，针对这个目录，可以看到有一些类似于 retry_policy、timeout等字段来配置这个目标的超时、重试策略等，不过最重要的还是 cluster 这个字段，它指定了这个路由目标对应着哪个上游集群，Envoy 最终将请求发送到这个 Cluster，比如我们这里的集群名称为 outbound|9080||productpage.default.svc.cluster.local，关于其具体配置我们就要去查看 ClustersConfigDump 中的配置了。
ClustersConfigDump
该部分是用来存储 Envoy 的集群配置的，同样也分为 static_clusters 和 dynamic_active_clusters，分别对应着静态配置和动态下发的配置。这里的 Cluster 集群是 Envoy 内部的概念，它是指 Envoy 连接的一组逻辑相同的上游主机，并不是说 K8s 集群，只是大多数情况下我们可以把这个集群理解为 K8s 集群中的一个 Service，一个 Service 通常对应着一组 Pod，由这组 Pod 响应请求并提供同一种服务，而 Envoy 的这个集群实际可以理解成这种Pod 集合。不过 Envoy 的一个集群也不一定就对应着一个 Service，因为集群是一组逻辑相同的上游主机，所以也有可能是别的符合定义的东西，比如说是服务的一个特定版本（如只是 v2 版本的 reviews 服务）。istio 的版本灰度能力就是基于这个做的，因为两个版本的同一服务实际上可以分成两个集群。
同样我们可以使用 istioctl proxy-config cluster 命令来查看这部分配置：
istioctl proxy-config cluster istio-ingressgateway-9c8b9b586-s6s48 -n istio-system -o yaml
该配置文件会非常长，它会将 K8s 集群中的 Service 都转换成 Envoy 的 Cluster，这里我们只看下 productpage 这个服务对应的 Cluster 配置，如下所示：
- circuitBreakers: #
thresholds:
- maxConnections: 4294967295
maxPendingRequests: 4294967295
maxRequests: 4294967295
maxRetries: 4294967295
trackRemaining: true
commonLbConfig:
localityWeightedLbConfig: {}
connectTimeout: 10s
edsClusterConfig:
edsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
serviceName: outbound|9080||productpage.default.svc.cluster.local
filters:
- name: istio.metadata_exchange
typedConfig:
"@type": type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange
protocol: istio-peer-exchange
lbPolicy: LEAST_REQUEST
metadata:
filterMetadata:
istio:
services:
- host: productpage.default.svc.cluster.local
name: productpage
namespace: default
name: outbound|9080||productpage.default.svc.cluster.local
transportSocketMatches:
- match:
tlsMode: istio
name: tlsMode-istio
transportSocket:
name: envoy.transport_sockets.tls
typedConfig:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
commonTlsContext:
alpnProtocols:
- istio-peer-exchange
- istio
combinedValidationContext:
defaultValidationContext:
matchSubjectAltNames:
- exact: spiffe://cluster.local/ns/default/sa/bookinfo-productpage
validationContextSdsSecretConfig:
name: ROOTCA
sdsConfig:
apiConfigSource:
apiType: GRPC
grpcServices:
- envoyGrpc:
clusterName: sds-grpc
setNodeOnFirstMessageOnly: true
transportApiVersion: V3
initialFetchTimeout: 0s
resourceApiVersion: V3
tlsCertificateSdsSecretConfigs:
- name: default
sdsConfig:
apiConfigSource:
apiType: GRPC
grpcServices:
- envoyGrpc:
clusterName: sds-grpc
setNodeOnFirstMessageOnly: true
transportApiVersion: V3
initialFetchTimeout: 0s
resourceApiVersion: V3
tlsParams:
tlsMaximumProtocolVersion: TLSv1_3
tlsMinimumProtocolVersion: TLSv1_2
sni: outbound_.9080_._.productpage.default.svc.cluster.local
- match: {}
name: tlsMode-disabled
transportSocket:
name: envoy.transport_sockets.raw_buffer
typedConfig:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.raw_buffer.v3.RawBuffer
type: EDS
我们可以看到这个 Envoy Cluster 的名称为 outbound|9080||productpage.default.svc.cluster.local，和前面的路由配置中的 cluster 字段是一致的，名称大多数会由 | 分成四个部分，分别是 inbound 或 outbound 代表入向流量或出向流量、端口号、subcluster 名称（就是对应着 destination rule 里的 subset）、Service FQDN，由 istio 的服务发现进行配置，通过这个 name 我们很容易就能看出来这个集群对应的是 K8s 集群的哪个服务。
然后配置的负载均衡策略是 LEAST_REQUEST，另外比较重要的这里的配置的类型为 type: EDS，也就是会通过 EDS 来发现上游的主机服务，这个 EDS 的配置如下所示：
edsClusterConfig:
edsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
serviceName: outbound|9080||productpage.default.svc.cluster.local
基于 EDS 去动态发现上游主机的配置，其实在前面的 Envoy 章节我们已经介绍过了，和这里是不是几乎是一致的，serviceName 其实就对应着 K8s 集群中的 productpage 这个 Service 对象的 9080 端口，而这个 Service 对象对应着一组 Pod，这组 Pod 就是我们的上游主机了。当然这是通过 xDS 协议下发的，我们可以通过 istioctl proxy-config endpoint 命令来查看这部分配置：
istioctl proxy-config endpoint istio-ingressgateway-9c8b9b586-s6s48 -n istio-system -o yaml
该部分数据非常多，下面只截取 productpage 相关的数据，如下所示：
- addedViaApi: true
circuitBreakers:
thresholds:
- maxConnections: 4294967295
maxPendingRequests: 4294967295
maxRequests: 4294967295
maxRetries: 4294967295
- maxConnections: 1024
maxPendingRequests: 1024
maxRequests: 1024
maxRetries: 3
priority: HIGH
edsServiceName: outbound|9080||productpage.default.svc.cluster.local
hostStatuses:
- address:
socketAddress:
address: 10.244.2.62
portValue: 9080
healthStatus:
edsHealthStatus: HEALTHY
locality: {}
stats:
- name: cx_connect_fail
- name: cx_total
value: "1"
- name: rq_error
- name: rq_success
value: "4"
- name: rq_timeout
- name: rq_total
value: "4"
- name: cx_active
type: GAUGE
- name: rq_active
type: GAUGE
weight: 1
name: outbound|9080||productpage.default.svc.cluster.local
observabilityName: outbound|9080||productpage.default.svc.cluster.local
可以看到上面的配置中就包含一个真正的后端服务地址：
代码语言：javascript复制address:
socketAddress:
address: 10.244.2.62
portValue: 9080
这个地址其实就是 productpage 这个 K8s Service 关联的 Pod 的地址。这样一个请求从进入到 Envoy 到最终转发到后端服务的过程就清楚了。
SecretsConfigDump
由于网格中的 Envoy 之间互相通信会使用 mTLS 模式，因此每个 Envoy 通信时都需要提供本工作负载的证书，同时为了签发证书还需要 istio ca 的根证书，这些证书的信息保存在该配置项之下。
总结
到这里我们就把 Envoy 的整个配置文件都理解了一遍，它们分别是 Bootstrap、Listeners、Routes、Clusters、Secrets 几个配置，其中又涉及到 VirtualHost 等细分概念。
整体上一个请求在 Envoy 内部的处理与转发过程中，listener、route、cluster 这几个配置是紧密相连的，它们通过配置的 name 一层又一层地向下引用（listener 内的 filter 引用 route、route 内的 virtual_host 引用 cluster），形成了一条引用链，最终将请求从 listener 递交到具体的 cluster。
我们可以使用 envoyui.solo.io 这个在线的 Envoy 配置可视化工具来查看 Envoy 的配置，只需要将我们的 Envoy 配置 dump 出来上传上来即可：
Envoy config dump
经过上面的分析我们也明白了其实 Istio 并没有实现很多复杂的逻辑，服务治理相关的功能比如负载均衡、故障注入、权重路由等都是 Envoy 本身就有的能力，Istio 只是将这些能力抽象成了一个个资源对象，然后通过 Envoy 的 xDS 协议下发到 Envoy 中，这样就能够实现对 Envoy 的流量治理了。所以重点还是需要我们先理解 Envoy 的配置，然后再去理解 Istio 的配置，这样才能更好的理解 Istio，不然你就不清楚 Gateway、VirtualService 等这些资源对象到底是干什么的，它们是如何影响 Envoy 的配置的。
当然我们这里还只是分析的 Istio Ingress Gateway 的配置，而对于 Sidecar 模式的 Envoy 代理又是如何去配置的呢？它又是如何将 Pod 的流量进行拦截的呢？这些我们后面会继续分析。
