istio学习：参考资料、总述、数据平面、控制平面、简单实践

参考资料

总述

Istio服务网格逻辑上分为数据平面和控制平面，架构图如下所示

它的架构目前来说有两种，一种是 Sidecar 模式，这也是 Istio 最传统的部署架构，另一种是 Proxyless 模式。

Sidecar模式

Proxyless模式

Proxyless 模式是 Istio 1.11 版本中支持的实验特性，Istio 官网中有篇博客介绍了这个特性。可以直接将 gRPC 服务添加到 Istio 中，不需要再向 Pod 中注入 Envoy 代理。这样做可以极大的提升应用性能，降低网络延迟。有人说这种做法又回到了原始的基于 SDK 的微服务模式，其实非也，它依然使用了 Envoy 的 xDS API. 但是因为不再需要向应用程序中注入 Sidecar 代理，因此可以减少应用程序性能的损耗。

数据平面

xDS-API

在Envoy中，xDS-API中的xDS是一类发现服务的统称，包括

SDS/EDS：Service/Endpoint Discovery Service
CDS：Cluster Discovery Service
RDS：Route Discovery Service
LDS：Listener Discovery Service

入口网关与出口网关

Istio提倡所有进入与离开服务网格的流量都经过一个特殊的网关。网关配置被用于运行在网格边界的独立 Envoy 代理，而不是服务工作负载的 sidecar 代理。

IngressGateway

istio-ingressgateway是Istio安装完成后就会启动的服务，其作用是作为整个服务网格的边缘网关。在边缘架设网关的作用不仅是做一层统一代理，更是对服务接口的统一管理。

IngressGateway在Istio中的具体实现仍然是Envoy。

Sidecar路由配置

默认情况下，Sidecar中并没有任何特别的配置，所有的流量都通过k8s域名走DNS解析走掉了。

当想对流量进行控制的时候，可以定义一个Virtual Service来动态指定流量的流向。

控制平面

Pilot结构及功能

Pilot是对各容器平台（或者VM）的逻辑抽象，通过适配器模式，形成统一的对接接口。

Pilot的基本工作就是为数据平台的Sidecar提供服务发现能力。但是Pilot本身并不做服务注册。它只是提供一个接口，对接已有的服务注册系统。除此之外，还负责为动态路由提供总控配置，并将这些配置分发给数据平面代理。

Mixer结构及功能

Mixer负责在服务调用之间实施控制策略，同时在调用间收集请求的遥测数据。

为了实现上述目的，每个请求在到达Sidecar的时候都需要向Mixer发起一次逻辑请求，以进行前置检查。在每次请求结束之后，还需要再次向Mixer做一次汇报。

这里其实有了问题，一次通信变成了三次。要解决这个问题，有两种方式：

把Mixer的部分请求处理逻辑放置在数据平面的网管Envoy上
将Mixer的数据二级缓存到Envoy上

请求属性(Attribute)

请求属性是控制平面的数据元。每个Sidecar在处理数据流动时均会向Mixer提供一种叫Attribute的key-value对，比如

1 2	request.path: xyz/abc request.size: 1234

操作配置(Operator Config)

操作配置是Mixer的规则定义，包含三个方面

数据实例配置，规定Mixer从请求属性中采集什么数据、在一些条件下应该采取什么样的行为（即如何生成一个数据实例）
处理器，实际处理数据实例的逻辑体
规则，将上面两个关联起来

安全控制

Istio的安全分成三层

最外层的企业防火墙是路由硬件层面上的安全防御，抵挡如DoS攻击
服务网格内部入口还有一层网关，主要提供服务接入鉴权及访问资源控制
内部实现多种机制，强化数据安全，如
- 身份标识
- 控制策略
- 传输加密
- 审计、认证、鉴权

Citadel结构及功能

Citadel是密钥与证书的管理系统。

搭建BookInfo系统

https://istio.io/latest/zh/docs/examples/bookinfo/