流量治理
- Istio的流量路由规则使运维人员可以轻松控制服务之间的流量和API调用
- Istio简化了诸如断路器，超时和重试之类的服务级别属性的配置，并使其易于设置重要任务（A/B测试，canary部署和基于百分比的流量拆分的分段部署）
- 它还提供了开箱即用的故障恢复功能，有助于使应用程序更强大，以防止相关服务或网络的故障
- 使用Istio进行流量管理从本质上是将流量与底层基础架构的伸缩机制相解耦，从而让运维工程师能够通过Pilot指定它们希望流量自身需要遵循那些规则，而非仅仅只能定义由那些特定的pod/vm接收流量，并在这些pod/vm之间以受限于数量比例的方式分配流量；
- Pilot和Envoy proxy负责实现流量规则中定义的流量传输机制
- 例如，可以通过pilot指定到希望特定服务的5%流量到canary版本，而与canary部署的大小无关，或者根据请求的内容将流量发送到特定版本
- Istio的所有路由规则和控制策略都基于kubernetes CRD实现，这包括网络功能相关的VirtualService、DestinationRule、Gateway、ServiceEntry和EnvoyFilter等；
Istio流量治理的关键配置
- Istio通过Ingress Gateway为网格引入外部流量；
- Gateway中运行的主程序为Envoy，它同样从控制平面接收配置，并负责完成相关的流量传输；
- 换言之，Gateway资源对象用于将外部访问映射到内部服务，它自身值负责通信子网的相关功能，例如套接字，而七层路由功能则由VirtualService实现；
- Istio基于ServiceEntry资源对象将外部服务注册到网格内，从而将外部服务以类同内部服务一样的方式进行访问治理；
- 对于外部服务，网格内Sidecar方式运行的Envoy即能执行治理；
- 若需要将外出流量收束于特定几个节点时则需要使用专用的Egress Gateway完成，并基于此Egress Gateway执行相应的流量治理；
- VirtualService和DestinationRules是Istio流量路由功能的核心组件
- VirtualService用于将分类流量并将其路由到指定的目的地（Destination），而Destination Rules则用于配置那个指定Destination如何处理流量
- VirtualService
- 用于在Istio及其底层平台（例如kubernetes）的基础上配置如何将请求路由到网格的各Service之上
- 通常由一组路由规则（routing rules）组成，这些路由规则按顺序进行评估，从而使Istio能够将那些对VirtualService的每个给定请求匹配到网格内特定的目标之上
- 事实上，其定义的是分发给网格内个Envoy的VirtualService和Route的相关配置
- Destination Rules
- 定义流量在目标内部的各端点之间的分发机制，例如将各端点进行分组，分组内端点间的流量均衡机制，异常探测等；
- 事实上，其定义的是分发给网络内各Envoy的Cluste的相关配置
- VirtualService定义虚拟主机及相关的路由规则，包括路由至哪个目标（集群或子集）
- DestinationRule定义集群或子集内部的流量分发机制
VirtualService和DestinationRule
配置Istio流量治理
- 流量治理基础
- 集群外部的入站流量会经由Ingress Gateway到达集群内部
- 需要经由Gateway定义Ingress Gateway上的“虚拟主机”
- 包括目标流量访问的“host”，以及虚拟主机监听的端口等
- 集群内部的流量仅会在Sidecar之间流动
- VirtualService为Sidecar Envoy定义Listener（主要定义流量路由机制等）
- DestinationRule为Sidecar Envoy定义Cluster（包括发现端点等）
网格流量治理和服务发现
- 网格内服务发送和接收的所有流量（Data Plan流量——都要经由Envoy代理进行
- 绑定到服务的所有流量都会通过Sidecar Envoy自动进行重新路由
- Istio借助于服务注册中心完成服务发现
- Istio自身并不进行服务发现功能，它需要借助于服务注册中心发现所有的Service及相应的各Endpoint
- Istio还假设服务的新实例会自动注册到服务注册表，并且会自动删除不健康的实例
- kubernetes、Mesos等平台能够为基于容器的应用程序提供服务发现功能，另外也存在大量针对基于VM的应用程序的解决方案
- kubernetes系统上，Istio会将网格中的每个Service的端口创建为Listener，而其匹配到的Endpoint将组合成为一个Cluster
- 这些Endpoint和Cluster将配置在网格内的每个sidecar Envoy之上
- 对于某个特定Sidecar Envoy来说，仅其自身所属的Service生成的Listener为Inbound Listener，而所有Service生成Listener都将配置为其上的Outbound Listener
- Inbound Listener：接收其所属Service的部分或全部流量
- Outbound Listener：代理本地应用访问集群内的其它服务
- 进出应用的所有流量都将被Sidecar Envoy拦截并基于重定向的方式进行处理
Istio网格中的默认配置
- 应用程序自身监听的端口相关的入站访问流量，将被网络名称空间中的iptables规则实施拦截后，并统一转发给Envoy Sidecar的15006/TCP端口，该端口也是Envoy上的Listener之一
- 应用程序作为客户端发送的出站访问流量，将被网络名称空间中的iptables规则实施拦截后，并统一转发给Envoy Sidecar的15001/TCP端口，该端口也是Envoy上的Listener之一
- 对于网格应用所属名称空间中的每一个Service对象
- 其用于提供服务的每个端口，都将作为一个Egress Listener配置在网格中的Envoy实例之上，从而确保每个应用可访问到该Service；
- 其selector匹配到的端点，将组合成一个Cluster，配置在风格中的各Envoy实例之上；
- 生成默认路由，将发往该Service生成的Listeners的流量，将被路由至同一Service生成Cluster之上；
- 获取命令
- istioctl proxy-config <clusters|listeners|routes|endpoints|bootstrap|log|secret> <pod-name[.namespace]>
参考文档
流量管理：https://istio.io/latest/docs/reference/config/networking/