Istio系列学习(二)----Istio架构

一、Istio的工作机制

Istio分为控制面和数据面.
控制面包含Pilot,Mixer,Citadel
数据面由伴随每个应用程序部署的代理程序Envoy组成.

1、自动注入
在创建应用程序时自动注入Sidecar代理.在K8s场景下创建pod时,kube-API server调用管理面组件的Sidecar-Injector服务,自动修改应用程序的描述信息并注入Sidecar.在真正创建pod时,在创建业务容器的同时在pod中创建sidecar容器.

2、流量拦截
在pod初始化时设置iptables规则,当有流量到来时,给予配置的iptables规则拦截业务容器的Inbound流量和outbound流量到sidecar上,应用程序感知不到sidecar的存在,还以原本的方式进行互相访问,

3、服务发现
服务发起方的Envoy调用管理面组件Pilot的服务发现接口获取目标服务的实例列表.

4、负载均衡
服务发起方的envoy根据pilot中配置的负载均衡策略选择服务实例。
上图中：数据面的各个envoy从pilot中获取forcecast服务的负载均衡配置，并执行负载均衡动作

5）流量治理
envoy从pilot中获取配置的流量规则，在拦截到inbound和outbound流量时执行治理逻辑。
上图中：fronted服务侧的envoy从pilot中获取流量治理规则，并根据流量治理规则将不同特征的流量分发到forecats的v1和v2版本。

6）访问安全
在服务间访问时通过双方的envoy进行双向认证和通道加密，并基于服务的身份进行授权管理
上图中：pilot下发安全相关配置，在fronted和forecast服务上的envoy上自动加载证书和秘钥来实现双向认证。证书和秘钥由citadel来维护。
7）服务遥测
服务间通信时，通信双方的envoy都会连接管理面组件mixer上报访问数据，并通过mixer将数据转发给对应的监控后端。
如上图：fronted服务队forecast服务的访问监控指标、日志和调用链都通过该方式手机到对应的监控后端。
8）策略执行
进行服务访问时，通过mixer连接后端服务来控制服务间的访问，判断对服务房型还是拒绝。
上图中：mixer可以对接一个限流服务对fronted服务到forecast服务的访问进行速率控制。
9）外部访问
网格的入口有一个envoy扮演入口网关的角色。
上图中:外部服务通过gateway访问入口服务fronted，对fronted服务的负载均衡、治理策略都在该gateway上执行。

每个过程都可以进行如下抽象：服务调用双方的envoy代理拦截流量，并根据管理面的相关配置执行对应的治理动作。

二、Istio的服务模型

1、Istio的服务
逻辑上：服务是istio主要管理的资源对象，包括域名和端口列表等属性；每个端口包含端口名称、端口号和端口的协议。不同协议有不同的内容，在istio中也有不同的治理规则。

物理层面：服务的存在形式就是k8s的service，只要满足了上述约束条件，就可以转换为istio的service并配置规则进行流量治理。

2、Service
k8s中：service通过一个域名或虚拟ip和port保证了服务地址是不变的，也无需暴露k8s中pod的端口和地址。

k8s的service的定义

apiVersion: v1
kind: Service
metadata:name: forecast
spec:ports:- port: 8081 #指定service的虚拟端口号targetPort: 8080 #对应到Pod容器的8080端口selector: app: forecast #对应到拥有label（app=webapp）的Pod

istio的service与k8s的区别在于：要满足istio的服务约束，如在端口名称上指定协议。如下(唯一区别是指定了协议为http)：

apiVersion: v1
kind: Service
metadata:name: forecast
spec:ports:- port: 8081 #指定service的虚拟端口号targetPort: 8080 #对应到Pod容器的8080端口name: httpselector: app: forecast #对应到拥有label（app=webapp）的Pod

在kubernetes中,一般先通过Deployment创建工作负载,在通过创建Service关联这些工作负载,从而暴露这些工作负载的接口,
在Istio中,Service是治理的对象,是Istio的核心管理实体,提供了对外访问能力的执行体，是istio服务的元数据。

三、Istio的服务版本

Istio可以进行灰度发布,将一个Service关联到多个Deployment,每个Deployment都对应服务的一个版本.

说明：
1）两个deployment都有相同的app:forecast标签，该标签和service的标签选择器一致，所以service能关联到这两个deployment对应的Pod。

2）两个deployment有不同的镜像版本，各自创建的Pod也不相同。version标签不同，分别是v1和v2

四、Istio的服务实例

istio的service对应k8s的service；
istio的服务实例对应k8s的endpoints
k8s的endpoints对象名称和service对应名称相同，是:列表。负责维护Service后端pod的变化.