match HTTPMatchRequest[]: 单个 HTTPMatchRequest 中的条件是 AND 语义，多个 HTTPMatchRequest 之间是 OR 语义
name: 与路由的名字拼接后记录到 access log 中uri StringMatch: 匹配 URI，支持三种匹配规则：exact: 精确匹配
prefix：前缀匹配
regex：正则匹配
ignoreUriCase: 不区分大小写匹配 URI
scheme StringMatch: 匹配 URI Scheme
method StringMatch: 匹配 HTTP method
authority StringMatch: 匹配 HTTP Authority
headers map<string, StringMatch>: 必须小写，并且采取连字符作为分隔符，例如 x-request-id。如果值为空，则判断要求头是否存在。把稳 key 如果为 uri、scheme、method、authority 将被忽略
port: 端口
sourceLabels: 限定部分 Sidecar 运用此匹配规则，gateways 必须包含 mesh 值
gateways: 覆盖顶层的 gateways
queryParams map<string, StringMatch>: 匹配查询参数，不支持前缀匹配
withoutHeaders map<string, StringMatch>: 与 headers 参数相反的含义
sourceNamespace: 限定运用此匹配规则的命名空间，gateways 必须包含 mesh 值
route HTTPRouteDestination[]: 流量被转发到哪个做事上destination Destination:
host: 必须存在于 service registry（Kubernetes services）中，或来自 ServiceEntry 中定义的 hosts
subset: DestinationRule 中定义的 subset 名字
port: 转发的端口
weight: 权重
headers Headers: 对要求头或相应头进行修正
redirect: 配置重定向delegate: route 和 redirect 为空时才可以设置，用于指定把流量转交给其他 VirtualService 处理rewrite: 转发要求之前对 uri 和 Authority/Host 要求头进行重写timeout: 要求超时retries: 重试策略fault: 故障注入mirror Destination: 流量镜像mirrorPercentage: 流量镜像百分比，默认 100%corsPolicy：CORS 策略headers Headers：对要求头或相应头进行修正tls: 匹配 HTTPS 流量的有序路由规则列表。tcp: 匹配 TCP 流量的有序路由规则列表。exportTo string[]: 掌握 VirtualService 能否被其他命名空间的 Gateway 和 Sidecar 利用，如果不设置值，默认导出到所有命名空间.表示当前命名空间
表示所有命名空间
Destination Rule掌握流量转发给做事的哪些 Workload。
host: 必须存在于 service registry（Kubernetes services）中，或来自 ServiceEntry 中定义的 hoststrafficPolicy TrafficPolicy:loadBalancer LoadBalancerSettings
simple
ROUND_ROBIN: 默认
LEAST_CONN: 最少要求
RANDOM: 随机
PASSTHROUGH: 透传
consistentHash: 根据要求信息做哈希localityLbSetting LocalityLoadBalancerSetting: 用于掌握地域上的就近访问connectionPool ConnectionPoolSettings: 关于上游的连接池设置tcp TCPSettings:
maxConnections: 最大连接数，默认 2^32-1
connectTimeout: TCP 连接超时时间，默认 10s
tcpKeepalive probes: 最大发送多少个探测包，没有收到相应，则认为连接已关闭，默认利用操作系统的配置（Linux 默认为 9）
time: 探测包发送之前的空闲韶光，默认利用操作系统的设置（Linux 默认为 7200s） interval：探测包的发送间隔，默认利用操作系统的设置（Linux 默认为 75s）
http HTTPSettings:http1MaxPendingRequests：upstream cluster 最大等待要求数（没有空闲链接可以处理的要求会排队），默认 2^32-1
http2MaxRequests：upstream cluster 最大许可并行的要求数，默认 2^32-1并非只用于 http2，http1 同样受限定
maxRequestsPerConnection：一个连接上最多可以发送多少个要求，默认 0，无限制如果配置了 2，那么一个连接在处理完 2 个要求后就会被关闭
maxRetries：upstream cluster 最大许可并行的重试要求数，默认 2^32-1
idleTimeout：默认 1h，连接最长空闲韶光，到期关闭，运用于 HTTP1.1 和 HTTP2 的连接
h2UpgradePolicy：指定 HTTP1.1 连接是否升级到 HTTP2
useClientProtocol bool: 是否利用客户真个协议，如果为 true，那么 h2UpgradePolicy 将无效
outlierDetection OutlierDetection: 对付上游 HTTP/TCP 做事中的每个端点的熔断配置。对付 HTTP 做事，如果端点连续返回 5xx 缺点，将会从连接池移除一段韶光。对付 TCP 做事，如果端点涌现连续的连接超时或连接失落败，也会从连接池移除一段韶光。consecutiveGatewayErrors: 连续缺点阈值，HTTP 502、503、504 和 TCP 连接超时、连接缺点/失落败都会认为是 gateway error，默认 0。
consecutive5xxErrors: 连续缺点阈值，HTTP 5xx 和 TCP 连接超时、连接缺点/失落败都会认为是 5xx error，默认 5。
interval: 驱逐剖析间隔，默认 10s
baseEjectionTime: 最小驱逐韶光基数，实际驱逐韶光会根据驱逐次数不断增大，默认 30s
maxEjectionPercent: 上游端点最大驱逐百分比，默认 10%
minHealthPercent: outlierDetection 启用的最低康健度。如果连接池中的康健端点百分比低于该值，outlierDetection 将会禁用，并且要求会负载均衡到所有端点，默认 0%。
tls ClientTLSSettings: 配置与上游连接的 SSL/TLSmode:DISABLE: 不启用 TLS 连接SIMPLE: 建立仅做事端认证的 TLS 连接MUTUAL: 通过指定客户端证书建立 mTLS 连接ISTIO_MUTUAL: 利用 Istio 自动天生的客户端证书建立 mTLS 连接，ClientTLSSettings 其他字段值需为空clientCertificate
privateKey
caCertificates
credentialName
subjectAltNames
sni
portLevelSettings PortTrafficPolicy[]: 为单独的端口配置流控，覆盖顶层配置port: 指定端口号
loadBalancer LoadBalancerSettings
connectionPool ConnectionPoolSettings
outlierDetection OutlierDetection
tls ClientTLSSettings
subsets: 做事端点的子集name: 子集的名字，会用于 VirtualService 的路由中
labels: 根据标签过滤出子集
trafficPolicy TrafficPolicy: 可以覆盖顶层的设置
exportTo string[]: 掌握 VirtualService 能否被其他命名空间的 Gateway 和 Sidecar 利用，如果不设置值，默认导出到所有命名空间.表示当前命名空间
表示所有命名空间
Gateway网格边缘的负载均衡，卖力吸收和发送流量。
servers Server[]:port Port: 监听的端口hosts string[]: 在 port 上暴露的做事tls ServerTLSSettings: 掌握是否所有的 http 要求都重定向为 https 和 TLS 模式name: 做事的名称selector: 运用到哪些 gateway 实例上Service Entry将网格外的做事添加进来。
hosts: 用于匹配 VirtualService 和 DestinationRule。对付 HTTP 流量，Host/Authority 要求头会用来与 hosts 匹配对付 HTTPs/TLS 流量，SNI 会用来与 hosts 匹配当 resolution=DNS 时，并且 endpoints 为空，那么 hosts 字段会被作为端点的 DNS 进行路由addresses: 做事的虚拟 IP，可以是 CIDR。ports Port[]: 做事的端口location Location: 做事是否该当被认为是网格内的，还是网格外的resolution Resolution:NONE: 到来的连接已经解析过了STATIC: 利用 endpoints 中指定的静态 IP 地址作为做事的端点DNS: 如果 endpoints 为空，则利用不带通配符的 hosts 解析出端点地址；如果 endpoints 不为空，DNS 类型的地址会用于解析出做事的端点endpoints WorkloadEntry[]:address: IP 或 DNSports: 端口映射labels: 标签network: Istio mesh 超过多个集群时利用localityweightserviceAccountworkloadSelector WorkloadSelector: 与 endpoints 互斥，location 必须为 MESH_INTERNALexportTo string[]subjectAltNames: 如果指定，sidecar 会校验做事器证书的 SAN 是否匹配一个指定的值流量管理协议选择1、自动协议选择
Istio 能自动检测 HTTP 和 HTTP/2 的流量，其他流量会被当作 TCP 的字节流。
2、显式协议选择
有两种配置办法：
Kubernetes service 端口的名字： <protocol>[-<suffix>]在 Kubernetes 1.18+，通过 Service 字段 appProtocol:支持如下协议：
httphttp2httpstcptlsgrpcgrpc-webmongomysqlredisudp (UDP will not be proxied, but the port can be explicitly declared as UDP)带 的协议默认是不启用的，如果须要，可通过 Pilot 的环境变量配置。
局部负载均衡理解 TLS 配置External inbound traffic: 来自外部客户端被 sidecar 拦截的入流量。mTLS 模式默认为 PERMISSIVE，即 sidecar 同时吸收 mTLS 和 non-mTLS 的流量。如果设置为 STRICT 模式，则 sidecar 只吸收 mTLS 的流量；如果设置为 DISABLE 模式，则 sidecar 只吸收 non-mTLS 的流量。Local inbound traffic: sidecar 转发给运用的流量Local outbound traffic: 运用发出的被 sidecar 拦截的流量External outbound traffic: 来自运用的流量可能被直接透传，也可能通过 TLS 连接传输，由 DestinationRule 中的 trafficPolicy 掌握关键点:
PeerAuthentication: 配置什么类型的 mTLS 流量被 sidecar 吸收DestinationRule: 配置什么类型的 TLS 流量被 sidecar 发送Port names 或 automatic protocol selection 决定 sidecar 会把流量解析为何种协议自动 mTLS: 如果 DestinationRule 没有 TLS 干系的配置，sidecar 会自动判断是否发送 ISTIO_MUTUAL。
Istio 资源与 Envoy 配置对应关系bootstrap 配置通过命令 istioctl proxy-config bootstrap ${POD_NAME} 可查看 envoy 的启动时的配置，即 istio-proxy 容器中 envoy 启动时利用的配置文件 /etc/istio/proxy/envoy-rev0.json，详细配置参考 envoy Bootstrap 文档 。
node: 节点信息admin: 本地管理 HTTP 做事信息layeredRuntime: 运行时动态配置干系statsConfig: 内部统计配置tracing: 外部跟踪做事配置staticResources: 静态配置的资源clustersprometheus_stats: 端口 15000agent: 端口 15020sds-grpc: 管道 /etc/istio/proxy/SDSxds-grpc: istiod.istio-system.svc:15012zipkin: zipkin.istio-system.svc:9411listenersprometheus 数据采集端口：15090路径：/stats/prometheuscluster: prometheus_stats康健检讨端口：15021路径：/healthz/readycluster: agentdynamicResources: 动态资源配置adsConfig: xds-grpc 将 CDS、EDS、RDS 合并在单一的流中下发，避免分布式同步问题cdsConfig: adsldsConfig: adslistener 配置通过命令 istioctl proxy-config listener proxy-c6c5cdf6b-ftznk 可查看 envoy 当前监听的端口，除了 15001（拦截出口流量）和 15006（拦截入口流量），其他端口的监听都是来自 bootstrap 静态配置的 listener 和 kubernetes service。
如下 Kubernetes service：
apiVersion: v1kind: Servicemetadata: name: proxy namespace: defaultspec: clusterIP: 10.200.1.132 externalTrafficPolicy: Cluster ports: - name: web nodePort: 30007 port: 80 protocol: TCP targetPort: 3030 selector: app: proxy sessionAffinity: None type: LoadBalancer
查看 sidecar envoy 在 80 端口上都有哪些 listener， istioctl proxy-config listener --port 80 webserverv1-84596579c6-wqmx4 ：
ADDRESS: 监听的地址PORT: 监听的端口MATCH: 匹配条件ALL 是兜底的规则，会直接走 envoy.filters.network.tcp_proxyApp: HTTP 表示匹配运用层的 http/1.0、http/1.1、h2c 协议DESTINATION: 表示匹配后下一阶段处理Route: 80 跟名称为 80 的路由规则进行匹配PassthroughCluster: 直接将要求转发给所要求的目的地址，即不会经由 envoy 进行负载均衡Cluster: outbound|80||proxy.default.svc.cluster.local 表示将要求转发给 outbound|80||proxy.default.svc.cluster.local 的后端ADDRESS PORT MATCH DESTINATION0.0.0.0 80 App: HTTP Route: 800.0.0.0 80 ALL PassthroughCluster10.200.1.132 80 App: HTTP Route: proxy.default.svc.cluster.local:8010.200.1.132 80 ALL Cluster: outbound|80||proxy.default.svc.cluster.localroute 配置
查看 sidecar envoy 的路由， istioctl proxy-config route webserverv1-84596579c6-xxvhd ：
NAME: 路由名称DOMAINS: 路由匹配的域名，如果域名是 Kubernetes service，则都是缩写的形式 {SVC_NAME}-{NS}MATCH: 匹配条件VIRTUAL SERVICE: 来自哪个命名空间下的 VirtualServiceNAME DOMAINS MATCH VIRTUAL SERVICEistio-ingressgateway.istio-system.svc.cluster.local:15021 istio-ingressgateway.istio-system /15010 istiod.istio-system /15014 istiod.istio-system /kube-dns.kube-system.svc.cluster.local:9153 kube-dns.kube-system /proxy.default.svc.cluster.local:80 proxy /istiod.istio-system.svc.cluster.local:853 istiod.istio-system /80 istio-egressgateway.istio-system /80 istio-ingressgateway.istio-system /80 proxy /80 webserver regex google_re2:{max_program_size:{value:1024}} regex:"." webserver.default80 webserverv1 /80 webserverv2 /inbound|80|http-web|webserver.default.svc.cluster.local /InboundPassthroughClusterIpv4 /InboundPassthroughClusterIpv4 / /healthz/readyinbound|80|http-web|webserver.default.svc.cluster.local / /stats/prometheuscluster 配置
查看 sidecar envoy 的 cluster， istioctl proxy-config cluster webserverv1-84596579c6-xxvhd ：
SERVICE FQDN: 做事端点凑集名称PORT: 做事监听的端口SUBSET: 所属的子集DIRECTION: 流量方向outbound: 出流量inbound: 入流量TYPE: 类型STATIC: 来自 bootstrap 中的配置ORIGINAL_DST: 直接把流量转发给所要求的地址EDS: 通过做事创造获取做事端点，选择一个做事端点转发流量STRICT_DNS: 通过持续异步地解析域名，获取做事端点DESTINATION RULE: 来自哪个命名空间下的 DestinationRuleSERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULEBlackHoleCluster - - - STATICInboundPassthroughClusterIpv4 - - - ORIGINAL_DSTPassthroughCluster - - - ORIGINAL_DSTagent - - - STATICistio-egressgateway.istio-system.svc.cluster.local 80 - outbound EDSistio-egressgateway.istio-system.svc.cluster.local 443 - outbound EDSistio-egressgateway.istio-system.svc.cluster.local 15443 - outbound EDSistio-ingressgateway.istio-system.svc.cluster.local 80 - outbound EDSistio-ingressgateway.istio-system.svc.cluster.local 443 - outbound EDSistio-ingressgateway.istio-system.svc.cluster.local 15021 - outbound EDSistio-ingressgateway.istio-system.svc.cluster.local 15443 - outbound EDSistio-ingressgateway.istio-system.svc.cluster.local 31400 - outbound EDSistiod.istio-system.svc.cluster.local 443 - outbound EDSistiod.istio-system.svc.cluster.local 853 - outbound EDSistiod.istio-system.svc.cluster.local 15010 - outbound EDSistiod.istio-system.svc.cluster.local 15012 - outbound EDSistiod.istio-system.svc.cluster.local 15014 - outbound EDSkube-dns.kube-system.svc.cluster.local 53 - outbound EDSkube-dns.kube-system.svc.cluster.local 9153 - outbound EDSkubernetes.default.svc.cluster.local 443 - outbound EDSprometheus_stats - - - STATICproxy.default.svc.cluster.local 80 - outbound EDSraw.githubusercontent.com 443 - outbound STRICT_DNS github.defaultsds-grpc - - - STATICwebserver.default.svc.cluster.local 80 - outbound EDS webserver.defaultwebserver.default.svc.cluster.local 80 http-web inbound STATICwebserver.default.svc.cluster.local 80 v1 outbound EDS webserver.defaultwebserver.default.svc.cluster.local 80 v2 outbound EDS webserver.defaultwebserverv1.default.svc.cluster.local 80 - outbound EDSwebserverv1.default.svc.cluster.local 80 http-web inbound STATICwebserverv2.default.svc.cluster.local 80 - outbound EDSxds-grpc - - - STRICT_DNSzipkin - - - STRICT_DNSendpoint 配置
查看 sidecar envoy 的 endpoint， istioctl proxy-config endpoint webserverv1-84596579c6-xxvhd ：
ENDPOINT: Pod 的 IP 地址和监听的端口STATUS: 康健状态OUTLIER CHECK: 被动康健检讨，在 cluster 中配置，但须要一些过滤器（http router, tcp proxy, redis proxy）支持CLUSTER: 所属的端点凑集ENDPOINT STATUS OUTLIER CHECK CLUSTER10.200.0.135:3030 HEALTHY OK outbound|80|v1|webserver.default.svc.cluster.local10.200.0.135:3030 HEALTHY OK outbound|80||webserver.default.svc.cluster.local10.200.0.135:3030 HEALTHY OK outbound|80||webserverv1.default.svc.cluster.local10.200.0.137:15010 HEALTHY OK outbound|15010||istiod.istio-system.svc.cluster.local10.200.0.137:15012 HEALTHY OK outbound|15012||istiod.istio-system.svc.cluster.local10.200.0.137:15014 HEALTHY OK outbound|15014||istiod.istio-system.svc.cluster.local10.200.0.137:15017 HEALTHY OK outbound|443||istiod.istio-system.svc.cluster.local10.200.0.137:15053 HEALTHY OK outbound|853||istiod.istio-system.svc.cluster.local10.200.0.139:53 HEALTHY OK outbound|53||kube-dns.kube-system.svc.cluster.local10.200.0.139:9153 HEALTHY OK outbound|9153||kube-dns.kube-system.svc.cluster.local10.200.0.141:8080 HEALTHY OK outbound|80||istio-egressgateway.istio-system.svc.cluster.local10.200.0.141:8443 HEALTHY OK outbound|443||istio-egressgateway.istio-system.svc.cluster.local10.200.0.141:15443 HEALTHY OK outbound|15443||istio-egressgateway.istio-system.svc.cluster.local10.200.0.146:8080 HEALTHY OK outbound|80||istio-ingressgateway.istio-system.svc.cluster.local10.200.0.146:8443 HEALTHY OK outbound|443||istio-ingressgateway.istio-system.svc.cluster.local10.200.0.146:15021 HEALTHY OK outbound|15021||istio-ingressgateway.istio-system.svc.cluster.local10.200.0.146:15443 HEALTHY OK outbound|15443||istio-ingressgateway.istio-system.svc.cluster.local10.200.0.146:31400 HEALTHY OK outbound|31400||istio-ingressgateway.istio-system.svc.cluster.local10.200.0.148:3030 HEALTHY OK outbound|80|v2|webserver.default.svc.cluster.local10.200.0.148:3030 HEALTHY OK outbound|80||webserver.default.svc.cluster.local10.200.0.148:3030 HEALTHY OK outbound|80||webserverv2.default.svc.cluster.local10.200.0.158:3030 HEALTHY OK outbound|80||proxy.default.svc.cluster.local10.200.1.62:15012 HEALTHY OK xds-grpc127.0.0.1:3030 HEALTHY OK inbound|80|http-web|webserver.default.svc.cluster.local127.0.0.1:3030 HEALTHY OK inbound|80|http-web|webserverv1.default.svc.cluster.local127.0.0.1:15000 HEALTHY OK prometheus_stats127.0.0.1:15020 HEALTHY OK agent151.101.228.133:443 HEALTHY OK outbound|443||raw.githubusercontent.com9.134.236.162:6443 HEALTHY OK outbound|443||kubernetes.default.svc.cluster.localunix://./etc/istio/proxy/SDS HEALTHY OK sds-grpcsidecar 对流量的挟制
由 Pod 的 initContainers istio-init 启动命令为： istio-iptables -p "15001" -z "15006" -u "1337" -m REDIRECT -i '' -x "" -b '' -d 15090,15021,15020 设置 Pod 的容器网络 iptables 规则：
-p “15001”: 将所有出站流量重定向到 15001-z “15006”: 将所有入站流量重定向到 15006 端口-u “1337”: 利用 istio-proxy 用户身份运行-m REDIRECT: 将入流量转发给 Envoy 的模式，可以为 REDIRECT 或 TPROXYREDIRECT 模式下，借助 conntrack 模块进行连接跟踪，Envoy 会通过 getsockopt(SO_ORIGINAL_DST) 获取原始的目的端口TPROXY 模式下，方便运用程序获取源 IP 地址，不会实行连接跟踪-i ‘’: 将所有 IP 地址的出站流量进行重定向-x “”: 哪些 IP 地址的出站流量不进行重定向-b ‘’: 将所有 IP 地址的入站流量进行重定向-d 15090,15021,15020: 这 3 个端口的入站流量不进行重定向查看 Pod 的容器网络 iptables 规则：
docker ps|grep "k8s_POD_webserverv1" | cut -d " " -f1
Chain PREROUTING (policy ACCEPT 81387 packets, 4883K bytes) pkts bytes target prot opt in out source destination81387 4883K ISTIO_INBOUND tcp -- any any anywhere anywhereChain INPUT (policy ACCEPT 81387 packets, 4883K bytes) pkts bytes target prot opt in out source destinationChain OUTPUT (policy ACCEPT 76333 packets, 7134K bytes) pkts bytes target prot opt in out source destination 186 11160 ISTIO_OUTPUT tcp -- any any anywhere anywhereChain POSTROUTING (policy ACCEPT 76333 packets, 7134K bytes) pkts bytes target prot opt in out source destinationChain ISTIO_INBOUND (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:15008 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:ssh 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:1509081387 4883K RETURN tcp -- any any anywhere anywhere tcp dpt:15021 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:15020 0 0 ISTIO_IN_REDIRECT tcp -- any any anywhere anywhereChain ISTIO_IN_REDIRECT (3 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- any any anywhere anywhere redir ports 15006Chain ISTIO_OUTPUT (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- any lo 127.0.0.6 anywhere 0 0 ISTIO_IN_REDIRECT all -- any lo anywhere !127.0.0.1 owner UID match 1337 0 0 RETURN all -- any lo anywhere anywhere ! owner UID match 1337 186 11160 RETURN all -- any any anywhere anywhere owner UID match 1337 0 0 ISTIO_IN_REDIRECT all -- any lo anywhere !127.0.0.1 owner GID match 1337 0 0 RETURN all -- any lo anywhere anywhere ! owner GID match 1337 0 0 RETURN all -- any any anywhere anywhere owner GID match 1337 0 0 RETURN all -- any any anywhere 127.0.0.1 0 0 ISTIO_REDIRECT all -- any any anywhere anywhereChain ISTIO_REDIRECT (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- any any anywhere anywhere redir ports 15001入站流量剖析
流量经由 nat 表链的顺序： PREROUTING -> INPUT -> 用户程序 。
先看 PREROUTING 链的规则：所有的 TCP 流量都实行 ISTIO_INBOUND 动作。
Chain PREROUTING (policy ACCEPT 81387 packets, 4883K bytes) pkts bytes target prot opt in out source destination81387 4883K ISTIO_INBOUND tcp -- any any anywhere anywhere
查看 ISTIO_INBOUND 链的规则：
对付 TCP 流量目的端口为 15008、ssh、15090、15021、15020 的流量实行 RETURN 动作，即进入 INPUT 链。其他的 TCP 流量实行 ISTIO_IN_REDIRECT 动作。Chain ISTIO_INBOUND (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:15008 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:ssh 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:1509081387 4883K RETURN tcp -- any any anywhere anywhere tcp dpt:15021 0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:15020 0 0 ISTIO_IN_REDIRECT tcp -- any any anywhere anywhere
查看 ISTIO_IN_REDIRECT 链的规则：所有 TCP 流量都转发到 15006 端口。
Chain ISTIO_IN_REDIRECT (3 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- any any anywhere anywhere redir ports 15006出站流量剖析
流量经由 nat 表链的顺序： OUTPUT -> POSTROUTING -> 网卡 。
OUTPUT 链的规则：所有的 TCP 流量都实行 ISTIO_OUTPUT 动作。
Chain OUTPUT (policy ACCEPT 76333 packets, 7134K bytes) pkts bytes target prot opt in out source destination 186 11160 ISTIO_OUTPUT tcp -- any any anywhere anywhere
查看 ISTIO_OUTPUT 链的规则：
规则一，来自 127.0.0.6 的流量，通过 lo 网卡发出的报文实行 RETURN 动作https://github.com/istio/istio/issues/29603访问 k8s svc 未声明的 容器端口（targetPort），流量被 sidecar 挟制后，会以 127.0.0.6 的源 IP 转发给监听未声明的端口的进程容器中（宿主机也一样），进程发往其他进程监听的地址和端口的数据包都是只走虚拟设备 loopback device规则二，通过 lo 网卡发出的报文，且目的地址不是 127.0.0.1，数据包来自用户 1337，实行 ISTIO_IN_REDIRECT 动作暂不清楚什么样的场景会有这类流量规则三，通过 lo 网卡发出的报文，数据包不是来自用户 1337，实行 RETURN 动作本地进程间的网络通信流量规则四，数据包来自用户 1337 实行 RETURN 动作sidecar 发送的流量规则五、六、七，跟二、三、四重复了规则八，目的地址是 127.0.0.1，实行 RETURN 动作规则九，对所有流量，实行 ISTIO_REDIRECT 动作Chain ISTIO_OUTPUT (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- any lo 127.0.0.6 anywhere 0 0 ISTIO_IN_REDIRECT all -- any lo anywhere !127.0.0.1 owner UID match 1337 0 0 RETURN all -- any lo anywhere anywhere ! owner UID match 1337 186 11160 RETURN all -- any any anywhere anywhere owner UID match 1337 0 0 ISTIO_IN_REDIRECT all -- any lo anywhere !127.0.0.1 owner GID match 1337 0 0 RETURN all -- any lo anywhere anywhere ! owner GID match 1337 0 0 RETURN all -- any any anywhere anywhere owner GID match 1337 0 0 RETURN all -- any any anywhere 127.0.0.1 0 0 ISTIO_REDIRECT all -- any any anywhere anywhere
查看 ISTIO_REDIRECT 链的规则：所有流量都重定向到 15001 端口
Chain ISTIO_REDIRECT (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- any any anywhere anywhere redir ports 15001流量流向关系图解
流程：Pod A 作为客户端向 Pod B 发送要求，Pod B 吸收到来自 Pod A 的要求后，须要调用 Pod C 之后，才相应 Pod A。
1、Pod A 发送要求给 Pod B
Pod A 与 Pod B 建立 TCP 连接：10.200.0.190:38568 <-> 10.200.0.188.80Pod B 中的 iptables 规则拦截了 Pod A 发过来的数据包，转发到 sidecar 监听的 15006 端口sidecar 与 APP 建立 TCP 连接：127.0.0.1.60180 <-> 127.0.0.1.80，将 Pod A 的要求转发给 APP
由于 tcpdump 抓包的实现事理是通过读取网络设备上的数据链路层的帧。
上面的 1、3 步骤就可以被 tcpdump 抓包看到，而 2 步骤是 netfilter 处理的，tcpdump 抓包是看不到的
2、Pod B 调用 Pod C
Pod B 通过 Pod C 的 k8s svc IP 调用，发出的要求会被 iptables 规则拦截，转发到 sidecar 监听的 15001 端口APP 会认为自己与 k8s svc IP 建立了一条 TCP 连接：10.200.0.188:38783 <-> 10.200.1.246:80，通过 netstat 命令可不雅观察到sidecar 会在 k8s svc 关联的 endpoint 中，选择 Pod C 建立连接：10.200.0.188:58649 <-> 10.200.0.189:3030，然后将 Pod B 的要求转发给 Pod CPod C 在收到 Pod B 的要求后，处理完成，相应 Pod B来自 Pod C 的相应会被 iptables 规则拦截，转发到 sidecar 监听的 15006 端口sidecar 再将 Pod C 的相应转发给 APP
1 步骤中可以通过 tcpdump 在 lo 上不雅观察到要求被转发到 15001，由于是在 netfilter 中先做了 REDIRECT 后，数据包才涌如今 lo 上，才被 tcpdump 不雅观察到2、3 步骤 tcpdump 在 eth0 上可以管擦到5 步骤通过 tcpdump 在 lo 上可以不雅观察到
3、Pod B 相应 Pod A
APP 相应 sidecarsidecar 将 APP 的相应转发给 Pod Aistio-proxy 的访问日志
即 Envoy 的访问日志，字段阐明可查看文档： Access logs 。
访问日志分为两类：
inbound: 入流量的访问日志outbound: 出流量的访问日志ingress gateway 没有 inbound 的 访问日志
出流量的访问日志例子：
{ "upstream_local_address": "10.200.0.131:42288", // envoy 向做事端发起的 TCP 连接的源地址和端口 "duration": "1", // 对付 HTTP 要求，表示要求开始到相应的末了一个字节发送出去的韶光，单位毫秒 "upstream_transport_failure_reason": "-", // 对付 HTTP 要求，连接建立失落败的缘故原由 "route_name": "default", // 匹配的路由名称 "downstream_local_address": "10.200.1.246:80", // envoy 挟制客户端发起连接的目的端点 "user_agent": "Go-http-client/1.1", "response_code": "200", // HTTP 相应状态码 "response_flags": "-", "start_time": "2021-02-18T07:08:50.031Z", // 对付 HTTP 要求，要求开始的韶光，单位毫秒 "method": "GET", "request_id": "967f8e1a-dbc0-4cce-ad53-ce6a27d5e54c", "upstream_host": "10.200.0.189:3030", // 被 envoy 选中作为做事真个端点 "x_forwarded_for": "-", "requested_server_name": "-", // SSL 连接的 SNI "bytes_received": "0", // 对付 HTTP 要求，客户端发送的要求 body 字节数 "istio_policy_status": "-", "bytes_sent": "75", // 对付 HTTP 要求，做事端相应的 body 字节数 "upstream_cluster": "outbound|80||webserverv1.default.svc.cluster.local", // 做事端凑集 "downstream_remote_address": "10.200.0.131:44728", // 客户端端点 "authority": "webserverv1.default.svc", "path": "/", "protocol": "HTTP/1.1", "upstream_service_time": "0"}
对 downstream 和 upstream 的图解：
