Istio 入门

《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进行绑定