《Istio：service Mesh 快速入门与实践》
核心组件及功能
- 数据面 sidecar，通过输入的方式和业务容器共存于一个pod中，劫持业务应用容器的流量，并接受控制面组件的控制，输出日志、跟踪、监控数据
- 控制面 管理Istio的所用功能
Pilot
- Pilot是主要控制点，流量管理。
- 从k8s或其他平台的注册中心获取服务信息，完成服务发现过程。
- 读取Istio的各项控制配置，进行转换之后，将其发给数据面进行实施
pilot的配置内容会被转换为数据面能够理解的格式，下发给数据面的sidecar，sidecar根据pilot指令，将定义信息转换为本地配置，完成控制行为的落地。
1、用户通过kubectl、istioctl 在k8s上创建crd资源，对istio控制平面发出指令
2、pilot监听crd中的cofnig、rbac、networking、authentication资源，检测到资源对象的变更之后，针对涉及的服务，发出指令给对应服务的sidecar
3、sidecar根据这些指令更新自身配置，根据配置修正通信行为
Mixer
预检和汇报
1、用户将Mixer配置发送到k8s中
2、Mixer通过对k8s资源的监听，获知配置的变量
3、网格中的服务在妹子调用之前，都向Mixer发出预检请求，查看调用是否允许执行。每次调用之后，都发出报告信息，向Mixer汇报在调用过程中产生的监控跟踪数据
包含多个Adapter的组件，用来处理在Mixer中接受的预检和报告数据
Citadel
证书管理
Sidecar （Envoy）
Sidecar就是Istio中的数据面，负责控制对网格控制的实际执行
理论上只要支持Envoy的xDS协议，类似的反向代理软件就都可以代替Envoy
Istio 的默认实现中，利用istio-init初始化容器中的iptables指令，对所在pod的流量进行劫持，从而接管pod中应用的通信过程，如此获得通信的控制权，控制面的控制目的最终得以实现。
同一个pod内的多个容器之间，网格栈、数据卷是共享的
核心配置对象
CRD ：CustomResourceDefinition
Istio安装过程中会进行CRD的初始化，CRD在注册成功之后，会建立一些基础对象，完成istio的初始化设置
用户利用Istio控制微服务通信，是通过向k8s提交crd资源的方式完成的，
Istio中的资源分为：
- networking.istio.io
- config.istio.io
- authentication.istio.io
networking.istio.io
流量管理功能
virtual Service是一个控制中心：
定义一组条件，将符合该条件的流量按照在对象中配置的对应策略进行处理，最后将路由转到匹配的目标中。
Gateway
首先经过的设施都是Gateway，描述了边缘接入设备的概念，包含对开放端口、主机名及可能存在的TLS证书的定义。
网络边缘的Ingress流量，会通过对应的Istio Ingress Gateway Controller 进入
网格内部的服务互访则通过虚拟的mesh网关进行（mesh网关代表网格内部的所有Sidecar）
VirtualService
VirtualService组成：
- Host：主机名称，k8s集群中，可以是服务名
- Gateway：流量的来源网关，如果省略，则代表使用的网关名为“mesh”，也就是默认的网格内部服务互联所用的网关。
- 路由对象：网格中的流量，如果符合Host和Gateway的条件，就需要根据实际协议对流量的处理方式进行甄别。
TCP/TLS/HTTP Route
路由对象目前可以是HTTP、TCP或者TLS中的一个，分别针对不通的协议进行工作。每种路由对象都至少包含两部分：匹配条件和目的路由
例如：
HTTP Route包含：
- Http Match Request 对象数组，用于匹配
- Destination Weight ，描述目标服务
DestinationWeight
各协议路由的目标定义是一致的，由destinationWeight 对象数据来完成，可以按照权重进行流量分配
Destination
目标对象，由subset和port 两个元素组成
subset 就是指服务的一个子集，在k8s中代表使用标签选择器区分的不同pod
流量就是经过多个对象的逐级处理，成功达到了pod
config.istio.io
config.istio.io中的对象用于为Mixer 组件提供配置
Mixer提供了预检和报告这两个功能，和大量的适配器
处理过程：
- Rule：是Mixer的入口，其中包含一个match成员和一个逻辑表达式，符合表达式判断的数据才会被交给Action处理。逻辑表达式中的变量被称为attribute，其中的内容来自Envoy提交的数据
- Match
- Action：将符合入口标准的数据，在用什么方式加工之后，交给哪个适配器进行处理。
- Instance：使用template对接收到的数据进行处理
- Template
- Handler：代表一个适配器的实例，用于接收处理后的数据
- Adapter：只被定义为一个行为规范，一些必要的实例化数据是需要再次进行初始化的。
经过Handler实例化之后的Adapter ，就具备了工作功能，
Envoy 传出的数据将会通过这些具体运行的Adapter的处理，得到预检结果，或者输出各种监控、日志及跟踪数据。
Template
对接收到的数据进行再加工。
进入Mixer中的数据都来自SIdecar
authentication.istio.io
这一组API用于定义认证策略。
在网格级别、命名空间级别、服务级别都提供了认证策略的要求，
要求再内容中包含服务间的通信认证，以及终端认证
涉及到的对象
-
policay：用于指定服务一级的认证策略，由策略目标和认证方法组成
- 策略目标：包含服务名称以及服务端口号
- 认证方法：分别是用于设置服务间认证的peers子对象，以及用于设置终端认证的origins子对象
-
MeshPolicy
只能被命名为default，代表是所有网格内部应用的默认认证策略。
其余部分内容和policy一致
race.istio.io
在istio中实现了一个和k8s相似的RBAC 基于角色的访问控制系统，
主要对象为Service和ServiceRoleBinding
ServiceRole
由一系列规则rules组成
每条规则都对应一条权限，描述了权限所对应的服务、服务路径及方法。
还包含一组可以进行自定义的约束。
ServiceRoleBinding
该对象用于将用户主体和ServiceRole进行绑定