Istio服务网格概述

An open platform to connect, secure, control and observe services.

介绍istio之前，要先讲一下Sidecar和Service Mesh

Sidecar这个词直译为边车，也有一个土味名字叫边三轮，它的作用就是在客户端和服务端之间加了一层代理，就像一个边三轮（在原来的基础上加了一个座位）。

它与容器一起使用，物理隔离，与语言无关，可以访问主APP的资源，与主APP的延迟不明显，便于用于扩展主APP的功能。

了解了Sidecar的概念，Service Mesh也就不难理解了，SideCar多了组成的网格就是Service Mesh，Service Mesh 是一个基础设施层，其独立运行在应用服务之外，提供应用服务之间安全、可靠、高效的通信，并为服务通信实现了微服务运行所需的基本组件功能，包括服务注册发现、负载均衡、故障恢复、监控、权限控制等

ServiceMesh的特点

应用程序间通讯的中间层

轻量级网络代理

应用程序无感知

解耦应用程序的重试/超时、监控、追踪和发现

那么什么是Istio呢，Istio是连接、管理、保护微服务的开放平台

Istio分为数据平面和控制平面，数据平面由一组SideCar智能代理和它掌控的网络通信的微服务实例组成，也就是下图中的上半部分，控制平面由Pilot、Mixer、Citadel组成，负责管理和配置代理的路由流量以及运行时服务治理策略的执行

了解了Istio的架构，我们具体来讲一讲各个组件

Istio通过对ServiceMesh中的每个pod注入SideCar，来实现无入侵式的服务治理能力，SideCar支持两种注入方式，一种是利用k8s的webhook能力开启自动注入，二是通过istioctl工具(类似kubectl的CLI)对yaml文件手动注入，具体操作我们会在下期展示。Istio的SideCar是集成的Envoy，每个应用部署的时候会自动向里面注入一个proxy容器，这些proxy构成了Istio的Service Mesh。

Envoy中有两个进程Pilot和envoy，Envoy由Pilot-agent进程启动，启动后，Envoy读取Pilot-agent为它生成配置文件，该配置文件可以理解为Envoy的静态配置，只是用来初始化Envoy，Envoy根据该文件的配置获取到Pilot的地址，通过数据面标准API的XDS接口从Pilot拉取动态配置信息，包括路由（route），监听器（listen），服务集群（cluster）和服务端点（endpoint）。Envoy初始化完成后，就根据这些配置信息对微服务间的通信进行寻址和路由,这些可以理解成Envoy的动态配置

Envoy定义了如下四个数据面接口来实现动态服务发现、负载均衡、TLS终止、gRPC代理、熔断器、健康检查、故障注入等功能

Listener，监听端口

Endpoint：目标ip和端口，这个Proxy最终将请求转发的地方

Cluster：一个Cluster是具有相同行为的多个Endpoint，例如一个服务有三个容器运行，对应三个endpoint，他们组成一个Cluster，从Cluster到endpoint的过程就是负载均衡

Route：有时候多个Cluster具有类似的功能，但是不同的版本号，可以通过Route规则，选择请求路由到某一个版本号，也就是某个Cluster

Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置，并在运行时将它们传播到 SideCar。

Istio本身不提供服务注册的能力，而是提供了一个平台适配器，可以对接不同的平台获取服务注册信息。Pilot定义了统一的服务模型，这个标准模型独立于各种底层平台，配合不同平台的适配器，让Istio可以将从不同平台得到的服务信息转换成Pilot的标准模型，标准的数据面API让控制面和数据面充分解耦，为多种数据面的SideCar实现提供了可能性。如Pilot中的Kubernetes适配器通过Kubernetes API服务器得到Kubernetes中service和pod的相关信息，然后翻译为标准模型提供给Pilot使用，生成Envoy能够理解的动态配置下发到数据面的Proxy中。通过适配器模式，Pilot还可以从Mesos, Cloud Foundry, Consul等平台中获取服务信息，还可以开发适配器将其他提供服务发现的组件集成到Pilot中。除Istio目前集成的Envoy外，还可以和Linkerd, Nginmesh等第三方通信代理进行集成，也可以基于该API自己编写Sidecar实现。

Pilot还定义了一套DSL语言，它是采用Kubernetes API Server中的CRD实现的，都可以用Kubectl进行创建。通过运用不同的流量规则，可以对网格中微服务进行精细化的流量控制，如按版本分流，断路器，故障注入，灰度发布等。

主要CRD如下：

Virtualservice：用于定义路由规则，如根据来源或 Header 制定规则，或在不同服务版本之间分拆流量。

DestinationRule：定义目的服务的配置策略以及可路由子集。策略包括断路器、负载均衡以及 TLS 等。

ServiceEntry：用 ServiceEntry 可以向Istio中加入附加的服务条目，以使网格内可以向istio 服务网格之外的服务发出请求。

Gateway：为网格配置网关，以允许一个服务可以被网格外部访问。

EnvoyFilter：可以为Envoy配置过滤器。由于Envoy已经支持Lua过滤器，因此可以通过EnvoyFilter启用Lua过滤器，动态改变Envoy的过滤链行为

Mixer 是负责提供策略控制和遥测收集的 Istio 组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级属性，发送到 Mixer 进行评估。

某一服务外部请求被envoy拦截，envoy根据请求生成指定的attributes，attributes作为参数之一向Mixer发起Check rpc请求。Mixer 进行前置条件检查和配额检查，调用相应的adapter做处理，并返回相应结果。Envoy分析结果，决定是否执行请求或拒绝请求。若可以执行请求则执行请求。请求完成后再向Mixer gRPC服务发起Report rpc请求，上报遥测数据。Mixer后端的adapter基于遥测数据做进一步处理。

上面的可能比较难理解，Mixer本质是一个属性处理机。每个经过Enovy SideCar的请求都会调用Mixer，为Mixer提供一组描述请求和请求周围环境的属性。基于Enovy sidecar的配置和给定的特定属性集，Mixer会调用各种基础设施后端

这里面会涉及几个概念

Instance：基于属性和常量。 配置实例，将请求的属性映射成为配置的输入。生成指标

Handler：就是配置完成的Adapter,提供一个访问后端Adapter的IP地址

Rule：定义match-action映射，匹配条件满足时，执行对应的action，action中是可调用的Instance和Handler

所以业务或sidecar调用mixer时，首先根据Rule匹配规则，匹配成功后调用Instane生成调用数据，然后调用Handler。（篇幅有限，具体实例会在下期演示）

Citadel 通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持基于角色的访问控制，以控制谁可以访问您的服务

Citadel 监视 Kubernetes apiserver，为每个现有和新的服务帐户创建证书和密钥对。Citadel 将证书和密钥对存储为 Kubernetes secret，创建 pod 时，Kubernetes 会根据其服务帐户通过 Kubernetes secret volume 将证书和密钥对挂载到 pod，Citadel 监视每个证书的生命周期，并通过重写 Kubernetes secret自动轮换证书，Pilot 生成安全命名信息，该信息定义了哪些 Service Account 可以运行哪些服务。Pilot 然后将安全命名信息传递给 envoy sidecar

今天主要简单介绍了下Istio的架构和组件，在网上看到一句对Istio组件的描述的很贴切，就用这句话收尾吧

Pilot不仅负责流量规则和策略的分发，还负责安全相关策略的下发，有点像皇上的贴身太监，负责宣读圣旨；Proxy有点像各州属的州官，负责奉天承运；Citadel有点像玉玺和虎符，负责鉴真去假；Mixer有点像三省六部，负责授权审计。那么皇帝是谁呢？