Istio

1、Istio 概念

服务网格是一个独立的基础设施层，用来处理服务之间的通信。

2、Istio 基本介绍

Istio 在 Kubernetes 的基础上，以非侵入的方式为运行在集群中的微服务提供流量管理、安全加固、服务监控和策略管理等功能。

2.1 Istio核心组件和功能

Istio 以 Envoy（网络代理）为 数据平面，通过 Sidecar 的方式让 Envoy 同业务容器一起运行，并劫持其通信 ， 接受控制平面的统一管理，在此基础上为服务之间的通信提供丰富的连接 、 控制 、 观察 、安全等特性 。
分为两部分控制面板和数据面。

2.1.1 数据面

数据面被称为sidecar。Sidecar通过注入的方式和业务容器共存于一个Pod中，会劫持业务容器的流量，并且接受控制面板组件的控制，同时会向控制面板输出日志、跟踪及监控数据。

2.1.2 控制面板

控制面板是Istio的核心，管理Istio的所有功能。

2.1.3 Pilot

Pilot管理Istio的流量（具体由Sidecar来完成）。

1. 从Kubernetes或者其他平台的注册中心获取服务信息，完成服务发现过程；
2. 读取Istio的各项控制配置，在进行转换之后，将其发给数据面进行实施。

2.1.4 Mixer

预检和汇报。

1. 用户将Mixer 配置发送到 Kubernetes 中。
2. Mixer 通过对 Kubernetes 资源的监听，获知配置的变化。
3. 网格中的服务在每次调用之前，都向 Mixer 发出预检请求，查看调用是否允许执行。在每次调用之后，都发出报告信息，向 Mixer 汇报在调用过程中产生的监控跟踪数据。

2.1.5 Citadel

Ciatdel 是用于证书管理的。在集群中启用了服务之间的加密之后， Citadel负责为集群中的各个服务在统一CA的条件下生成证书，下发给各个服务中的Sidecar ，服务之间的TLS 就依赖这些证书完成校验过程。

2.1.6 Sidecar

Sidecar就是lstio中的数据面，负责控制面对网格控制的实际执行。
lstio利用istio-init初始化容器中的iptables指令，对所在Pod 的流量进行劫持，从而接管Pod 中应用的通信过程，如此一来，就获得了通信的控制权，控制面的控制目的最终得以实现。

通信方式变化： Sidecar在加入之后，原有的源容器→目的容器的直接通信方式，变成了 源容器→ Sidecar→ Sidecar→目的容器的模式 。

2.2 服务流量控制

1. Gateway：外部流量和内部服务通信的入口。Istio通过Gateway将网格内的服务发布成外部可访问的服务，还可以通过Gateway配置外部访问的端口、协议及与内部服务的映射关系。
2. Virtual Service：定义了匹配到的内部服务怎么进行流转，将满足条件的流量都转发到对应的服务后端。

3、故障处理

Istio提供了很多开箱即用的提升服务弹性的功能，包括负载均衡、连接池、健康监测、熔断、超时、重试、限流。

3.1 负载均衡

当服务有多个实例的时候，通过负载均衡器来分发请求。负载均衡器一般提供轮询，随机，最小连接数、哈希算法。
Istio提供了两种常用的负载均衡策略：简单负载均衡和一致性哈希负载均衡。

3.1.1 简单负载均衡

简单负载均衡提供以下4种负载均衡算法：

1. 轮询：把请求依次转发给后端的健康实例，这是默认算法。
2. 最小连接数：：把请求转发给活跃请求最少的后端健康实例。
3. 随机：把请求随即转发到后端健康实例。
4. 直连：将连接转发到调用方请求的原始IP地址

3.1.2 一致性哈希负载均衡

只适用于使用HTTP类协议（HTTP1.1/HTTPS/HTTP2）的请求，可以基于请求头、Cookie或者来源IP做会话保持，让同一用户的请求一直转发到后端同一实例，当实例出现故障时会选择新的实例。当添加删除实例时，会有部分用户的会话保持失败。

3.2 连接池

当服务调用上游服务时，可以提前创建好到上游服务的连接，当请求到来时，通过已经创建好的连接直接发送请求给上游服务，减少连接创建的时间，从而降低请求的整体耗时，这些提前创建好的连接集合被称为连接池。

Istio提供了两类常用协议的连接池配置：TCP连接池和HTTP连接池。

3.3 健康检查

当上游服务部分实例出现故障时，健康监测机制能自动检测到上游服务的不可用实例，从而避免把请求发送给上游不可用的实例。

3.4 限流

当请求数过多时，直接丢掉过多的流量，防止服务被压垮，保证服务稳定。

Istio提供两种限流的实现：基于内存的限流和基于 Redis 的限流。

• 基于内存的方式会在 Mixer 重启后会丢失数据。
• 基于 Redis 方式不会丢失数据。

3.5 超时

设置服务调用的超时时间，当服务没有在规定的时间内返回数据，就直接取消此次请求，这样可以防止服务提供方拖垮服务调用方，防止请求的总耗时时间过长。

3.6 重试

在服务提供方的服务偶发瞬时故障，重新调用服务，可能就会请求成功，从而避免出现服务调用不可用，影响整体稳定性和可用性。

3.7 熔断

当服务出现大量调用失败时，应该停止调用后端服务，防止大量请求将服务器压垮。在短暂时间之后，尝试让部分请求调用后端服务，如果调用成功则让更多请求调用服务。否则继续停止调用服务。

Istio通过结合连接池和实例健康监测机制实现熔断功能。当后端服务出现实例不可用时，就将该服务实例移除负载均衡池，当负载均衡池中无可用实例时，服务请求会立即得到服务不可用的响应码，此时服务就处于熔断状态。当移除负载均衡池时间结束后，该实例会再次被放到负载均衡池，等待下一轮的服务健康检查。