Istio的请求链路
今天我们来讲一下istio的请求链路。我发现非常多的开发人会搞不清istio中和k8s中出现的各种重复名词之间的关系。并且在istio中的请求链路和k8s是不完全一致的。
我发现身边许多做istio的开发者，其实都不清楚istio内部实际的请求链路，网上也没有非常好的总结。这里的k8s指的是我们一般情况下使用k8s的方式。毕竟istio也是以k8s为基座的。
入口
为了简单起见我们只讲解单kubernetes集群的请求链路
在用户发起一个请求时，（我们将用户打到我们服务器的请求称为南北流量。内部调用则称之为东西流量。）
首先进入的是k8s的入口，一般在入口处是kubernetes集群的slb服务，这是这个请求还没有进入ingress。这里的SLB是一个高可用的集群入口。再实际上可以是通过VIP+keepalived或者硬件级别负载均衡器，做的高可用入口。我们通常会将公网ip绑定到slb入口侧。
ingress
Ingress | Kubernetes.
接下来是ingress，但是其实目前kubernetes中的ingress已经停止了更新，新的功能也继承到了getway aip中
而目前istio也推荐使用网关来做而不是使用ingress来作为服务的入口，他主要提供了服务外部到服务内部的路由
路由
k8s
接下来这里是istio和原生的kubernetes出入比较大的地方了
https://istio.io/latest/zh/blog/
这里要先介绍一下kubeproxy，他是k8s工作节点上的一个网络代理组件，运行在每个node上，他实现了kubernetes Service概念的一部分。它的作用是使发往service的流量通过clusterIp和端口，负载到正确的后端pod。
kubernetes默认情况下，流量下一步将会打到service，
istio
云原生和ServiceMesh主要组件--理解K8s/Istio/Envoy_envoy istio区别-CSDN博客
在istio中就不需要这么做，istio中在每个pod中注入有一个代理，诶这就是我们小学二年级就学过的sidecar了。istio通过透明代理，在k8s中解耦了流量管理。
这样可以更好的做应用指标的检测，请求状态耗时的记录，以及更细粒度的流量转发和控制能力。
东西请求
K8s
Service 与 Pod 的 DNS | Kubernetes
那么接下来就是东西流量的访问流程了。在裸k8s中，我们一般以service为单位进行访问。然后用kube-proxy自带的服务发现进行正确的路由。
Kubernetes 为 Service 和 Pod 创建 DNS 记录。 你可以使用一致的 DNS 名称而非 IP 地址访问 Service。kubelet中可以配置DNS，以便运行中的容器可以通过名称而不是IP查找服务。集群中的Service被赋予DNS名称（如果不指定命名空间会在当前命名空间下进行查询）
kubernetes(8)——service实现服务发现和负载均衡_clusterip会变吗-CSDN博客
具体有三种情况，（Userspace，iptables，ipvs)这里主要讲解iptables，也是目前用的最多的情况。
kube-proxy会监视Kubernetes master对象和Endpoinnts对象的添加和移除。对每个Service，它会安装iptables规则，从而捕获到达该Service的clusterIP（虚拟IP）和端口的请求，进而将请求重定向到Service的一组backend中的某个上面。
istio
这里不讨论istio直接代理DNS解析的情况。
当向一个域名发送请求时，客户端会进行 DNS 解析，将其解析为一个 IP 地址。 不管 Istio 如何设置，这都会发生，因为 Istio 只是拦截网络流量； 它不能改变应用程序的行为或决定是否发送 DNS 请求。
接下来，该请求将被 Istio 拦截。这时，Istio 将看到主机名（来自 Host: example.com 头）和目标地址（192.0.2.0:80）。Istio 使用这些信息来确定预定目的地。一共有三种模式。
- 使用客户端的原始 IP 地址（上例中为
192.0.2.0）。 这种情况适用于resolution: NONE类型的ServiceEntry和无头服务。 - 在一组静态 IP 地址上进行负载均衡。这种情况适用于
resolution: STATIC类型的ServiceEntry，这将使用spec.endpoints中的所有地址， 或者对于标准Services将使用其所有Endpoints地址。 - 使用 DNS 定期解析地址，并在所有结果中进行负载均衡。这种情况适用于
resolution: DNS类型的ServiceEntry。
比较多的是第三种，注意客户端进行了 DNS 解析， 代理也可能忽略已解析的 IP 地址，而使用自己的地址。