istio

什么是istio呢，这里就要引入服务网格的概念(service mesh),istio就是服务网格概念的一种落地和实现。服务网格就是传统代理的升级版（可以理解为分布式的微服务代理），变为了每个pod常驻一个代理。负责流量的相关工作，这样所有的流量被代理接管，用户的业务和控制面板彻底解耦。而控制中心就是负责汇聚整个集群的信息，管理员可通过控制面板的api来对集群做管理。

但是其集成kubernetes方便的同时也可能会存在一些问题：

例如：

1、作为插件强依赖容器(若有一天容器淘汰了?)

2、做为go语言开发的组件若要按业务需求进行扩展需要门槛

3、istio作为一pod多容器(envoy)注入模式，若服务pod数量过多后可能存在性能问题(官方方案：只能加缓存)

istio的其他替代方案：可通过spring cloud gateway集成sentinel、skywalking等组件扩展自研。

                              入口流量可通过gateway+sentinel控制，出口流量(服务间调用)可通过封装sdk强制转发路由到gateway。

                             （springcloud gateway3.0.1开始支持grpc,参考：spring.io/blog/2021/12/08/spring-cloud-gateway-and-grpc;

                                springcloud提供了异构sidecar）

当服务1访问服务2时：

服务1必须通过两次sidecar拦截，而服务1和服务2不会进行直接通信，而是需要各自的sidecar。

istio能做什么？

1.自动通过服务发现获取server服务实例的列表，并根据负载均衡策略选择一个服务实例。

2.对服务双方启用双向认证和通道加密。

3.如果某个服务实例连续访问出错，则可以自动将该实例隔离一段时间，以提高访问质量。

4.设置最大连接数、最大请求数、访问超时等对服务进行保护。

5.限流。

6.对请求进行重试。

7.修改请求中的内容。

8.将一定特征的服务重定向。

9.灰度发布

10.自动记录服务访问信息。

11记录调用链，进行分布式追踪。

根据访问数据形成完整的应用访问拓扑。

istio弥补了k8s所欠缺的那部分(动态路由，链路追踪，熔断限流等)大大降低了微服务运维的复杂性。istio又包含了连接、服务保护、控制和观察服务几大特性，为微服务减轻了很多的负担，开发者不用关心服务调用的超时、重试的实现，服务之间的安全，授权也得到了保证。

连接：控制调用流量、灰度升级、ab测试、蓝绿部署等。

安全：为服务间调用提供认证、授权和加密

观察：查看服务运行期间的各种数据，比如（日志、监控和tracing，了解服务的运行情况）。

大致分为数据面和控制面两部分：

数据平面

由一组代理组成，接收并实施mixer的策略。

proxy(sidecar代理)

负责高效转发和策略实现（envoy 类型nginx）

envoy部署在每一个需要管理k8s的pod中，会拦截所有的流量，经过规则校验

会经过本Pod的Enovy代理，Enovy完成规则校验、数据采集、日志等操作后，再转发出去；值得注意的是，请求方Enovy转发出去的流量会发送给接收方的Enovy，之后才有可能到达真正的接收方data-product容器。当然这些操作是Istio的活，我们要做的仅仅是通过配置的形式告诉Istio我们要对哪些流量做什么动作。

Istio sidecar 的工作原理是捕获入站流量和出站流量，并通过 sidecar 代理引导它们。
然而，并不是所有的流量都被捕获：
•重定向只处理基于TCP的流量。任何 UDP 或 ICMP 数据包都不会被捕获或修改。
•Sidecar 使用的许多端口[27]以及 22 号端口的入站捕获被禁用。这个列表可以通过 traffic.sidecar.istio.io/excludeInboundPorts等选项来扩展。
•出站捕获同样可以通过traffic.sidecar.istio.io/excludeOutboundPorts 等设置或其他方式减少。
一般来说，应用程序和其sidecar 代理之间的安全边界最小。对 sidecar 的配置是以每个模块为基础的，并且两者都在同一个网络/进程命名空间中运行。
因此，应用程序可能有能力删除重定向规则，并删除、改变、终止或替换 sidecar 代理。这允许一个 pod 故意绕过它的 sidecar 
的出站流量或故意让入站流量绕过它的sidecar。
因此，依靠Istio无条件地捕获所有流量是不安全的。相反，安全边界是客户端不能绕过另一个pod的sidecar。

控制平面

mixer(上报数据)

是控制面的核心，主要职责是获取注册中心的用户配置信息，在根据用户配置信息来处理envoy端的请求

适配组件，数据平面和控制平面通信，是通过Mixer来完成的，为proxy提供策略和数据上报

telemertry组件：

policy组件：

机制流程和telemetry类似，数据面在转发服务的请求前调用policy的check接口，检查是否允许访问，Mixer会根据配置将请求转发到Adapter做对应检查，给代理返回是否允许访问。

pilot(服务发现、配置下发、流量管理)

      配置策略组件，为Proxy提供服务发现，智能路由，错误处理等，主要是做流量管理操作，类似于C/S架构中的master服务。

而且还有一个向数据面下发规则的功能，如VirtualService、DestinationRule、Gateway、ServiceEntry等流量治理规则、安全规则等，pilot负责将各种规则转换为Envoy可识别的格式，通过标准的xDs协议发送给Envoy，指导Envoy完成动作。在通信上，Envoy通过gRPC流式订阅pilot的配置资源，Envoy根据该路由规则进行流量转发。

citadel(证书、密钥校验)

      核心安全组件，提供加密通信，撤销秘钥和证书等功能，Citadel一直监听Kube-apiservicr，以serect的形式为每个服务都生成证书和秘钥，并在pod在创建时挂载在pod上，代理容器使用这些文件进行服务认证，进而代理两端服务实现双向TLS认证，通道加密、访问授权等安全功能。这样就省去了用户在代码里维护证书秘钥。

galley(配置管理)

      配置管理，验证，分发，负责配置管理的组件，验证配置信息的格式和内容的正确性

gateway(入口，网格外访问网格内的唯一入口)

Istio有4个配置资源，落地所有流量管理需求。

VirtualService：实现服务请求路由规则的功能

DestinationRule：实现目标服务的负载均衡、服务发现、故障处理和故障注入等功能

Gateway：让服务网格内的服务可以被全世界看到

ServiceEntry：让服务网格内的服务可以看到外边的世界

参考：www.jianshu.com/p/5a31bfc142d5