istio sidecar 工作方式

istio 是什么

Istio 是一个开放源代码的服务网格，它为基于微服务的应用步伐提供了一种统一的方式来连接、保护、监控和管理服务。Istio 主要办理的是在微服务架构中的服务间通讯的复杂性标题，它通过提供服务间的负载平衡、服务到服务的认证、监控以及服务的弹性（比方重试、熔断等）来实现。
sidecar 是什么

sidecar 是一种计划模式，它将挂在业务容器旁边作为辅助，当业务接受流量和传出流量的时候，都先颠末 sidecar 然后在到达业务容器或者发出。sidecar 可以看作是一个署理，或者是一个专门为我一个服务而工作的 gateway。这样，服务的熔断、限流、监控、日志等功能都可以在 sidecar 中实现，而不需要在业务容器中实现。从而实现了业务容器的轻量化，只需要关注业务逻辑。
在 istio 中，sidecar 利用的是 envoy，envoy 是一个高性能的署理，它支持 http1.1, http2, grpc, tcp 等协议，支持负载平衡，熔断，限流，监控等功能。envoy 是一个 c++ 项目，它的性能非常好。通过 istiod 控制平面，利用 grpc stream 的方式更新 envoy 的设置，从而实现了动态设置。

如果在 pod test 中访问 test namespace 下的 nginx service，那么流量会颠末自己的 sidecar，然后到达 nginx 的 sidecar，最后到达 nginx 的容器。nginx 回复同样如此，先到达 sidecar，然后到达 test 的 sidecar，最后到达 test 的容器。
启动方式

在 kubernetes 中，当 namespace 存在 istio-injection=enabled label，那么在该 namespace 中的 pod 在启动的时候，istio 就会利用 mutating addmission webhook 的方式，自动修改 pod spec ，把 containers 中参加 sidecar 容器。当然，它也参加了一个 initcontainer，目标是做一些网络设置，能做到这个的缘故起因是，kubernetes 的 pod 的多个 container 是利用同一个 linux network namespace, 所以 initcontainer 修改的网络设置对所有的 container 都生效。
流量劫持方式

在 test 访问 nginx 的例子中，我们可以看到 nginx 的容器是启动在 80 端口上的，流量也是访问的 80, sidecar 是怎么劫持到的呢？而且，在 test pod 中，我们访问的是 nginx 的 service，流量又是怎么劫持到 sidecar 的呢？
刚刚说过，pod 除了被插入了一个 sidecar 容器，还被插入了一个 initcontainer，我们启动一个 nginx pod 和 service 看一下。

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: nginx
5.   namespace: test
6. spec:
7.   replicas: 1
8.   selector:
9.     matchLabels:
10.       app: nginx
11.   template:
12.     metadata:
13.       labels:
14.         app: nginx
15.     spec:
16.       containers:
17.       - name: nginx
18.         image: nginx:latest
19.         ports:
20.         - containerPort: 80
21. ---
22. apiVersion: v1
23. kind: Service
24. metadata:
25.   name: nginx
26.   namespace: test
27. spec:
28.   selector:
29.     app: nginx
30.   ports:
31.   - protocol: TCP
32.     port: 80
33.     targetPort: 80
34.   type: ClusterIP

复制代码

1. kubectl create ns test
2. kubectl label namespace test istio-injection=enabled # 开启 istio 注入
3. kubectl -n test apply -f nginx.yaml

复制代码

如今我们看一下 nginx pod 被插入的 sidecar 和 initcontainer

1. ## sidecar
2.   - args:
3.     - proxy
4.     - sidecar
5.     - --domain
6.     - $(POD_NAMESPACE).svc.cluster.local
7.     - --proxyLogLevel=warning
8.     - --proxyComponentLogLevel=misc:error
9.     - --log_output_level=default:info
10.     # ...
11. ## intcontainer
12.   - args:
13.     - istio-iptables
14.     - -p
15.     - "15001"
16.     - -z
17.     - "15006"
18.     - -u
19.     - "1337"
20.     - -m
21.     - REDIRECT
22.     - -i
23.     - '*'
24.     - -x
25.     - ""
26.     - -b
27.     - '*'
28.     - -d
29.     - 15090,15021,15020
30.     - --log_output_level=default:info

复制代码

可以看到，initcontainer 是自动执行了一系列的脚本，这个脚本我们并不知道是做啥的，但是从名字可以看出来是 iptables 的操作，那么我们看一下 iptables 的规则
这里我们容器内没有 iptables，所以我们在宿主机上查看 在nginx pod 地点的主机上查看，先确定 nginx 这个container 的 pid。

1. # 从 pod 的 status 中的容器的 uid
2. kubectl get pod -n test nginx-7c79c4bf97-7985c -o jsonpath='{.status.containerStatuses[0].container
3. ID}'
4. docker://b0d6c9060661e0912a35d33ff220e67a628c9fc5300ca3c67dc30f9e40c9e0ce%
5. # 我这里是用 docker 作为 container runtime 的
6. # 如果你是 containerd 的话 需要执行 ctr -n k8s.io info [container_id] |grep -i pod
7. docker inspect b0d6c9060661e0912a35d33ff220e67a628c9fc5300ca3c67dc30f9e40c9e0ce | grep -i pid # 在 nginx 所在的主机上执行
8. "Pid": 4652
9. # 在主机上使用 nseneter 进入容器的 network namespace 查看 iptables 规则
10. nsenter -t 4652 -n -- iptables-save
11. # Warning: iptables-legacy tables present, use iptables-legacy-save to see them
12. # 说明这个容器使用的是 iptables-legacy 我们按提示执行
13. nsenter -t 4652 -n -- iptables-legacy-save

复制代码

1. # Generated by iptables-save v1.8.7 on Sun May 12 05:53:29 2024
2. *nat
3. :PREROUTING ACCEPT [54:3240]
4. :INPUT ACCEPT [54:3240]
5. :OUTPUT ACCEPT [49:4198]
6. :POSTROUTING ACCEPT [49:4198]
7. :ISTIO_INBOUND - [0:0]
8. :ISTIO_IN_REDIRECT - [0:0]
9. :ISTIO_OUTPUT - [0:0]
10. :ISTIO_REDIRECT - [0:0]
11. # 所有入栈流量都走 ISTIO_INBOUND 链
12. -A PREROUTING -p tcp -j ISTIO_INBOUND
13. # 所有出栈流量都走 ISTIO_OUTPUT 链
14. -A OUTPUT -p tcp -j ISTIO_OUTPUT
15. # 忽略（也就是不劫持）目标端口是 15008 15090 15021 15020 的流量
16. # 15008:隧道端口 15090:prometheus 端口 15021:健康检查 15020:管理端口
17. # 官方文档端口介绍 https://istio.io/latest/docs/ops/deployment/requirements/#ports-used-by-istio
18. -A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
19. -A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
20. -A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
21. -A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
22. # 如果是 tcp 协议就走 ISTIO_IN_REDIRECT 链
23. -A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
24. # 如果是 tcp 就使用 dnat 把流量转发到15006端口（也就是修改tcp的目标端口）也就是交给envoy处理
25. -A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
26. # 回环地址 不处理
27. -A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
28. # 从 lo（回环） 口出来的 目标不是本机 owner是 envoy（--uid-owner 1337） 目标端口是 15008 的 转到 ISTIO_IN_REDIRECT 链处理
29. -A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -p tcp -m tcp ! --dport 15008 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
30. # 从 lo 口出来的 owner 不是 envoy（不是 envoy 发出的） 不处理
31. -A ISTIO_OUTPUT -o lo -m owner ! --uid-owner 1337 -j RETURN
32. # owner 是 envoy 的不处理 （不能劫持自己发出去的流量）
33. -A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
34. # 从 lo（回环） 口出来的 目标不是本机 owner是 envoy（--gid-owner 1337） 目标端口是 15008 的 转到 ISTIO_IN_REDIRECT 链处理
35. -A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -p tcp -m tcp ! --dport 15008 -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
36. #  从 lo（回环） 口出来的 owner 不是 envoy 不处理
37. -A ISTIO_OUTPUT -o lo -m owner ! --gid-owner 1337 -j RETURN
38. # owner 是 envoy 不处理
39. -A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
40. # 目标地址是 127.0.0.1 不处理
41. -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
42. # 剩下转到 ISTIO_REDIRECT 链
43. -A ISTIO_OUTPUT -j ISTIO_REDIRECT
44. # 如果是 tcp 就使用 dnat 把流量转发到 15001 端口（也就是修改tcp的目标端口）也就是交给envoy处理
45. -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
46. COMMIT
47. # Completed on Sun May 12 05:53:29 2024

复制代码

为什么 --uid-owner 1337 和 --gid-owner 1337 就代表 owner 是 envoy 呢？
由于 envot (istio proxy) 是以 uid 和 gid 起来的。

1. kubectl get pod -n test nginx-7c79c4bf97-7985c -o jsonpath='{.spec.containers[1].name}'
2. istio-proxy
3. kubectl get pod -n test nginx-7c79c4bf97-7985c -o jsonpath='{.spec.containers[1].securityContext.ru
4. nAsGroup}'
5. 1337
6. kubectl get pod -n test nginx-7c79c4bf97-7985c -o jsonpath='{.spec.containers[1].securityContext.runAsUser}'
7. 1337

复制代码

每个 pod 中的 iptables 都是一样的，这样我们就知道了 test pod 是怎么劫持的，比如如今在 test pod container 中 curl nginx.test 首先查询 dns nginx.test 对应的 ip 是 10.102.168.134, 访问也就是向 http://10.102.168.134:80 发请求。

• test pod 是发出去的包 所以 iptables 走 OUTPUT 链 http 是 tcp 协议的 所以走 ISTIO_OUTPUT 链
  
• 这个流量不是 lo 口的，目标地址不是 127.0.0.1, owner 也不是 envoy ，所以给 ISTIO_REDIRECT 链处理
  
• ISTIO_REDIRECT 中 我们是 tcp 所以 dnat 到端口 15001 （也就是 envoy）做处理
  
• test envoy gateway 会转发到 http://10.244.0.73:80(pod ip) （具体是怎么转发的后续会介绍到）
  
• 流量是进入到 nginx pod 中 所以 iptables 的 PREROUTING 链 http 是 tcp 协议的，所以走 ISTIO_INBOUND 链
  
• 目标端口是 80 不是15008 15090 15021 15020 所以走 ISTIO_IN_REDIRECT 链
  
• ISTIO_IN_REDIRECT 会 dnat 到端口 15006 也就是 envoy 做处理
  
• envoy 会转发到自己的 nginx container 容器中  （具体是怎么转发的后续会介绍到）
  

所以可以看到，流量从 test pod 的 test container 出来之后，会被自己的 envoy(istio-proxy sidecar) 劫持，然后7层转发到 10.244.0.73 (nigix pod IP地址)。然后 nginx pod 中的 envoy container 会劫持这个流量交给自己，然后7层署理到 nginx container。流量回复归去是一个道理。
xDS

在上方的流程中 test envoy 劫持到 http://10.102.168.134:80 会转发到 http://10.244.0.73:80，那么他是怎么知道要转发到这里去的呢？如果是 nginx 我们会设置 upstream，然后执行 nginx -s reload，这是 nginx 不支持动态加载方式。envoy 是支持动态加载的，对外提供 API，我们调用 API 就可以动态的修改设置。这个 API 就是 xDS API。它包括了以下API：

• CDS(Cluster Discovery Service): 用于发现集群信息，比如集群的名字，集群的地址等。
  
• EDS(Endpoint Discovery Service): 用于发现集群中的 endpoint 信息，比如集群中的服务的地址，端口等。
  
• LDS(Listener Discovery Service): 用于发现监听器信息，比如监听器的名字，监听器的地址等。
  
• RDS(Route Discovery Service): 用于发现路由信息，比如路由的名字，路由的规则等。
  
• SDS(Secret Discovery Service): 用于发现证书信息，比如证书的名字，证书的内容等。
  
• HDS(Health Discovery Service): 用于发现健康查抄信息，比如健康查抄的名字，健康查抄的规则等。
  
• ADS(Aggregated Discovery Service): 用于聚合以上所有的服务，提供一个统一的服务。
  

listener + route 是用来表达监听哪个端口和哪些路由的，是 envoy 进入流量的入口。cluster + endpoint 是用来表达集群和集群中的服务的，是 envoy 转发流量的目标地。
数据泉源

那这些 xDS 的设置来自哪呢？
这些 envoy 设置都来自于 istiod，istiod 是 istio 的控制平面，它会利用 grpc stream 的方式，动态的更新 envoy 的设置。istiod 会监听 kubernetes 的资源变化，比如 service, endpoint 和 istio 自己 CRD 等，组合成一个设置，然后定时的推送给 envoy。这样就实现了动态设置。
比如我们这个 service 的设置，查看 service 和 endpoints 就知道 service clusterIp 对应的 pod ip。

1. kubectl -n test get svc nginx
2. NAME    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
3. nginx   ClusterIP   10.102.168.134   <none>        80/TCP    112m
4. kubectl -n test get endpoints nginx
5. NAME    ENDPOINTS        AGE
6. nginx   10.244.0.73:80   112m

复制代码

这样我们就知道了 nginx service 对应的 clusterIp 是 10.102.168.134, 而对应的 pod ip 是 10.244.0.73。然后 istiod 把这个设置推送给所有 sidecar，这样 test pod 中的 envoy 就知道了要把流量转发到 10.244.0.73 了。
流量流程图

在 test pod 的 test 容器中 执行 curl http://nginx.test 流量的流程图如下

设置查看

我们可以通过调用 pod 中的 envoy 的 admin api 来查看设置

1. kubectl port-forward pod/nginx-7c79c4bf97-7985c 15000:15000
2. curl http://localhost:15000/config_dump

复制代码

打印出的 json 格式的设置文件，它而很大看起来很不方便，幸好 istio 给我们提供了一个工具 istioctl，我们可以利用 istioctl 来查看设置。
由于我们流量是从 test pod 到 nginx pod，所以所限我们查看 test pod 中的 envoy 的设置。
1.首先我们看下 listerner 15001 的设置 由于从 iptables 我们知道 出去的流量会被劫持到 15001

1. istioctl -n test proxy-config listener test-f5b5d48b5-qdzft --port 15001
2. ADDRESSES PORT  MATCH         DESTINATION
3. 0.0.0.0   15001 ALL           PassthroughCluster
4. 0.0.0.0   15001 Addr: *:15001 Non-HTTP/Non-TCP

复制代码

首先会监听 15001 端口，这个是真是监听的端口。它会转发到虚拟端口（Virtual Port），虚拟端口不会真是监听操作体系端口，它只是envoy的逻辑端口。那我们怎么知道流量转发到哪个虚拟端口了？请求的端口是什么，就转发到哪个了。比如我们请求的是 nginx 80 端口，就会转发到 80 虚拟端口
2.查看 listener 的虚拟端口，nginx service ip 10.102.168.134 prot 80

1. istioctl -n test proxy-config listener test-f5b5d48b5-qdzft --port 80 --address 10.102.168.134
2. ADDRESSES      PORT MATCH                                DESTINATION
3. 10.102.168.134 80   Trans: raw_buffer; App: http/1.1,h2c Route: nginx.test.svc.cluster.local:80
4. 10.102.168.134 80   ALL                                  Cluster: outbound|80||nginx.test.svc.cluster.local

复制代码

第一条是明文而且是 http/1.1 或者 h2c 无加密的 http/2）协议的流量会被转发到 nginx.test.svc.cluster.local:80
3.查看 route 设置

1. istioctl -n test proxy-config route test-f5b5d48b5-qdzft |grep nginx.test.svc.cluster.local
2. nginx.test.svc.cluster.local:80                               nginx.test.svc.cluster.local:80                               *                                                    /*
3. 80                                                            nginx.test.svc.cluster.local:80                               nginx, nginx.test + 1 more...                        /*

复制代码

这里我们没有指定 host 所以走第一条

1. #  istioctl -n test proxy-config route test-f5b5d48b5-qdzft --name nginx.test.svc.cluster.local:80 -oyaml
2. - ignorePortInHostMatching: true
3.   maxDirectResponseBodySizeBytes: 1048576
4.   name: nginx.test.svc.cluster.local:80
5.   validateClusters: false
6.   virtualHosts:
7.   - domains:
8.     - '*'
9.     includeRequestAttemptCount: true
10.     name: nginx.test.svc.cluster.local:80
11.     routes:
12.     - decorator:
13.         operation: nginx.test.svc.cluster.local:80/*
14.       match:
15.         prefix: /
16.       name: default
17.       route:
18.         cluster: outbound|80||nginx.test.svc.cluster.local
19.         maxGrpcTimeout: 0s
20.         retryPolicy:
21.           hostSelectionRetryMaxAttempts: "5"
22.           numRetries: 2
23.           retriableStatusCodes:
24.           - 503
25.           retryHostPredicate:
26.           - name: envoy.retry_host_predicates.previous_hosts
27.             typedConfig:
28.               '@type': type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate
29.           retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes
30.         timeout: 0s

复制代码

可以看到，match 的路由是 prefix 是 /，也就是所有的请求都会走这个路由，这个路由会把流量转发到 outbound|80||nginx.test.svc.cluster.local 这个 cluster 中。
4.我们查看 cluster

1. # istioctl -n test proxy-config cluster test-f5b5d48b5-qdzft --fqdn "outbound|80||nginx.test.svc.cluster.local" -oyaml
2. - circuitBreakers:
3.     thresholds:
4.     - maxConnections: 4294967295
5.       maxPendingRequests: 4294967295
6.       maxRequests: 4294967295
7.       maxRetries: 4294967295
8.       trackRemaining: true
9.   commonLbConfig:
10.     localityWeightedLbConfig: {}
11.   connectTimeout: 10s
12.   edsClusterConfig:
13.     edsConfig:
14.       ads: {}
15.       initialFetchTimeout: 0s
16.       resourceApiVersion: V3
17.     serviceName: outbound|80||nginx.test.svc.cluster.local
18.   filters:
19.   - name: istio.metadata_exchange
20.     typedConfig:
21.       '@type': type.googleapis.com/udpa.type.v1.TypedStruct
22.       typeUrl: type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange
23.       value:
24.         enable_discovery: true
25.         protocol: istio-peer-exchange
26.   lbPolicy: LEAST_REQUEST
27.   metadata:
28.     filterMetadata:
29.       istio:
30.         services:
31.         - host: nginx.test.svc.cluster.local
32.           name: nginx
33.           namespace: test
34.   name: outbound|80||nginx.test.svc.cluster.local
35.   transportSocketMatches:
36.   - match:
37.       tlsMode: istio
38.     name: tlsMode-istio
39.     transportSocket:
40.       name: envoy.transport_sockets.tls
41.       typedConfig:
42.         '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
43.         commonTlsContext:
44.           alpnProtocols:
45.           - istio-peer-exchange
46.           - istio
47.           combinedValidationContext:
48.             defaultValidationContext:
49.               matchSubjectAltNames:
50.               - exact: spiffe://cluster.local/ns/test/sa/default
51.             validationContextSdsSecretConfig:
52.               name: ROOTCA
53.               sdsConfig:
54.                 apiConfigSource:
55.                   apiType: GRPC
56.                   grpcServices:
57.                   - envoyGrpc:
58.                       clusterName: sds-grpc
59.                   setNodeOnFirstMessageOnly: true
60.                   transportApiVersion: V3
61.                 initialFetchTimeout: 0s
62.                 resourceApiVersion: V3
63.           tlsCertificateSdsSecretConfigs:
64.           - name: default
65.             sdsConfig:
66.               apiConfigSource:
67.                 apiType: GRPC
68.                 grpcServices:
69.                 - envoyGrpc:
70.                     clusterName: sds-grpc
71.                 setNodeOnFirstMessageOnly: true
72.                 transportApiVersion: V3
73.               initialFetchTimeout: 0s
74.               resourceApiVersion: V3
75.           tlsParams:
76.             tlsMaximumProtocolVersion: TLSv1_3
77.             tlsMinimumProtocolVersion: TLSv1_2
78.         sni: outbound_.80_._.nginx.test.svc.cluster.local
79.   - match: {}
80.     name: tlsMode-disabled
81.     transportSocket:
82.       name: envoy.transport_sockets.raw_buffer
83.       typedConfig:
84.         '@type': type.googleapis.com/envoy.extensions.transport_sockets.raw_buffer.v3.RawBuffer
85.   type: EDS
86.   typedExtensionProtocolOptions:
87.     envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
88.       '@type': type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
89.       useDownstreamProtocolConfig:
90.         http2ProtocolOptions: {}
91.         httpProtocolOptions: {}

复制代码

可以看到，这个 cluster 是一个 EDS 类型的 cluster，它会从 edsConfig 中获取设置。
5.查看 endpoint

1. # istioctl -n test proxy-config endpoint test-f5b5d48b5-qdzft --cluster  "outbound|80||nginx.test.svc.cluster.local" -oyaml
2. - addedViaApi: true
3.   circuitBreakers:
4.     thresholds:
5.     - maxConnections: 4294967295
6.       maxPendingRequests: 4294967295
7.       maxRequests: 4294967295
8.       maxRetries: 4294967295
9.     - maxConnections: 1024
10.       maxPendingRequests: 1024
11.       maxRequests: 1024
12.       maxRetries: 3
13.       priority: HIGH
14.   edsServiceName: outbound|80||nginx.test.svc.cluster.local
15.   hostStatuses:
16.   - address:
17.       socketAddress:
18.         address: 10.244.0.73
19.         portValue: 80
20.     healthStatus:
21.       edsHealthStatus: HEALTHY
22.     locality: {}
23.     stats:
24.     - name: cx_connect_fail
25.     - name: cx_total
26.     - name: rq_error
27.     - name: rq_success
28.     - name: rq_timeout
29.     - name: rq_total
30.     - name: cx_active
31.       type: GAUGE
32.     - name: rq_active
33.       type: GAUGE
34.     weight: 1
35.   name: outbound|80||nginx.test.svc.cluster.local
36.   observabilityName: outbound|80||nginx.test.svc.cluster.local

复制代码

从 endpoint 中我们可以看到，流量会转发到 10.244.0.73:80 这个地址。由于我们这个 service 只有一个 pod，如果多个 pod 的话，会有多个 address。
envoy 会向访问 http://10.244.0.73:80，那么接下来就是 nginx pod 中的 envoy 会把流量转发到 nginx container 中。
6.server 劫持到15006

1. istioctl -n test proxy-config listener nginx-7c79c4bf97-7985c --port 15006
2. ADDRESSES PORT  MATCH                                                                    DESTINATION
3. 0.0.0.0   15006 Addr: *:15006                                                            Non-HTTP/Non-TCP
4. 0.0.0.0   15006 Trans: tls; App: istio-http/1.0,istio-http/1.1,istio-h2; Addr: 0.0.0.0/0 InboundPassthroughClusterIpv4
5. 0.0.0.0   15006 Trans: raw_buffer; App: http/1.1,h2c; Addr: 0.0.0.0/0                    InboundPassthroughClusterIpv4
6. 0.0.0.0   15006 Trans: tls; App: TCP TLS; Addr: 0.0.0.0/0                                InboundPassthroughClusterIpv4
7. 0.0.0.0   15006 Trans: raw_buffer; Addr: 0.0.0.0/0                                       InboundPassthroughClusterIpv4
8. 0.0.0.0   15006 Trans: tls; Addr: 0.0.0.0/0                                              InboundPassthroughClusterIpv4
9. 0.0.0.0   15006 Trans: tls; App: istio-http/1.0,istio-http/1.1,istio-h2; Addr: *:80      Cluster: inbound|80||
10. 0.0.0.0   15006 Trans: raw_buffer; App: http/1.1,h2c; Addr: *:80                         Cluster: inbound|80||
11. 0.0.0.0   15006 Trans: tls; App: TCP TLS; Addr: *:80                                     Cluster: inbound|80||
12. 0.0.0.0   15006 Trans: raw_buffer; Addr: *:80                                            Cluster: inbound|80||
13. 0.0.0.0   15006 Trans: tls; Addr: *:80                                                   Cluster: inbound|80||

复制代码

listener 的虚拟端口

1. istioctl -n test proxy-config listener nginx-7c79c4bf97-7985c --port 80 --address 0.0.0.0
2. ADDRESSES PORT MATCH                                DESTINATION
3. 0.0.0.0   80   Trans: raw_buffer; App: http/1.1,h2c Route: 80
4. 0.0.0.0   80   ALL                                  PassthroughCluster

复制代码

所以 DESTINATION 是 Route: 80 ,所以 route 会匹配 inbound|80||
7.查看 server route

1. # istioctl -n test proxy-config route nginx-7c79c4bf97-7985c  --name "inbound|80||" -oyaml
2. - name: inbound|80||
3.   validateClusters: false
4.   virtualHosts:
5.   - domains:
6.     - '*'
7.     name: inbound|http|80
8.     routes:
9.     - decorator:
10.         operation: nginx.test.svc.cluster.local:80/*
11.       match:
12.         prefix: /
13.       name: default
14.       route:
15.         cluster: inbound|80||
16.         maxStreamDuration:
17.           grpcTimeoutHeaderMax: 0s
18.           maxStreamDuration: 0s
19.         timeout: 0s
20. - name: inbound|80||
21.   validateClusters: false
22.   virtualHosts:
23.   - domains:
24.     - '*'
25.     name: inbound|http|80
26.     routes:
27.     - decorator:
28.         operation: nginx.test.svc.cluster.local:80/*
29.       match:
30.         prefix: /
31.       name: default
32.       route:
33.         cluster: inbound|80||
34.         maxStreamDuration:
35.           grpcTimeoutHeaderMax: 0s
36.           maxStreamDuration: 0s
37.         timeout: 0s

复制代码

会匹配到 cluster inbound|80||，它是 inbound 类型的 route, 所以它会直接把流量转发到 80 端口。也就是 pod 中 nginx container 中的 nigix 进程。
7.回复
当 nginx 把静态资源回复给 test 的时候，流量的方式和请求的时候是一样的，只是方向相反。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。