istio

Google,IBM,Lyft发起的开源项目。2017年推出，2018年7月发布1.0

基于sidecar模式，分为数据层和控制层

云原生时代，Istio使您可以连接，保护，控制和观察服务。当整体应用程序向分布式微服务架构过渡时，Istio解决了开发人员和运营商面临的挑战。

istio出现的根本原因是微服务大行其道，却遇到很多问题，例如，istio就是为了解决这些问题而诞生的。服务发现，负载均衡，路由，流量控制，服务间通信的可靠性，监控。

服务网格(Service Mesh)

需要指出的是istio是service mesh概念下的一款产品。linkerd也是服务网格概念下优秀的产品。

Service Mesh 提供了一种透明的、与编程语言无关的方式，使网络配置、安全配置以及遥测等操作能够灵活而简便地实现自动化。从本质上说，Service Mesh 解耦了服务的开发与运维工作。如果你是一名开发者，那么在部署新服务，或是修改现有服务的时候，就无需担心这些操作会对你的分布式系统带来哪些运维层面的影响。与此同时，运维人员可以放心地对服务之间的运维控制进行变更，无需重新部署服务或是修改服务的源代码。而处于服务与底层网络之间的这一层基础设施，就是 Service Mesh。

服务网格用于描述组成此类应用程序的微服务网络及其之间的交互。

随着服务网格的大小和复杂性的增长，它变得越来越难以理解和管理。它的要求可以包括发现，负载平衡，故障恢复，指标和监视。

服务网格通常还具有更复杂的操作要求，例如A / B测试，金丝雀推出，速率限制，访问控制和端到端身份验证。

istio架构

istio-proxy（envoy)

istio 的sidecar（istio-proxy）是开源项目envoy的扩展版，Envoy是用C＋＋开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，是istio架构中唯一的数据面组件， Envoy 提供了动态服务发现、负载均衡、TLS , HTTP/2 及gRPC 代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。在istio-proxy容器中除了有Envoy ，还有一个pilot-agent的守护进程。

pilot

服务列表中的istio-pilot是istio的控制中枢Pilot服务。如果把数据面的envoy 也看作一种agent，则Pilot 类似传统C /S 架构中的服务端Master，下发指令控制客户端完成业务功能。和传统的微服务架构对比， Pilot 至少涵盖服务注册中心和Config Server等管理组件的功能。
如下图所示：pilot直接从运行平台(kubernetes,consul)提取数据并将其构造和转换成istio的服务发现模型，因此pilot只有服务发现功能，无须进行服务注册。这种抽象模型解耦Pilot 和底层平台的不同实现，可支持kubernetes，consul等平台

除了服务发现， Pilot 更重要的一个功能是向数据面下发规则，包括VirtualService 、DestinationRule 、Gateway 、ServiceEntry 等流量治理规则，也包括认证授权等安全规则。Pilot 负责将各种规则转换成Envoy 可识别的格式，通过标准的XDS 协议发送给Envoy,指导Envoy 完成功作。在通信上， Envoy 通过gRPC 流式订阅Pilot 的配置资源。如下图所示， Pilot 将VirtualService 表达的路由规则分发到Evnoy 上， Envoy 根据该路由规则进行流量转发。

mixer

Istio 控制面部署了两个Mixer 组件： istio-telemetry 和istio-policy ，分别处理遥测数据的收集和策略的执行。查看两个组件的Pod 镜像会发现，容器的镜像是相同的，都是"/istio/mixer"
Mixer 是Istio 独有的一种设计,不同于Pilot ，在其他平台上总能找到类似功能的服务组件。从调用时机上来说,Pilot 管理的是配置数据，在配置改变时和数据面交互即可；然而，对于Mixer 来说，在服务间交互时Envoy 都会对Mixer 进行一次调用，因此这是一种实时管理。当然，在实现上通过在Mixer 和Proxy 上使用缓存机制，可保证不用每次进行数据面请求时都和Mixer 交互。

1.istio-telemetry
istio-telemetry是专门用于收集遥测数据的Mixer服务组件;如下图所示所示，当网格中的两个服务间有调用发生时，服务的代理Envoy 就会上报遥测数据给istio-telemetry服务组件，istio-telemetry 服务组件则根据配置将生成访问Metric等数据分发给后端的遥测服务。数据面代理通过Report 接口上报数据时访问数据会被批
量上报。

2.istio-policy
istio-policy 是另外一个Mixer 服务，和istio-telemetry 基本上是完全相同的机制和流程。
如图下图所示，数据面在转发服务的请求前调用istio-policy 的Check接口检查是否允许访问， Mixer 根据配置将请求转发到对应的Adapter 做对应检查，给代理返回允许访问还是拒绝。可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制。

istio-citadel

服务列表中的istio-citadel 是Istio 的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citadel 一直监听Kube-apiserver ，以Secret 的形式为每个服务都生成证书密钥，并在Pod 创建时挂载到Pod 上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、访问授权等安全功能，这样用户就不用在代码里面维护证书密钥了。如下图所示，frontend 服务对forecast 服务的访问用到了HTTP 方式，通过配置即可对服务增加认证功能，双方的Envoy 会建立双向认证的TLS 通道，从而在服务间启用双向认证的HTTPS 。

istio-galley

istio-galley 并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley 作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的Pilot和Mixer服务使用，这样其他管理面组件只用和Galley 打交道，从而与底层平台解耦。在新的版本中Galley的作用越来越核心。

istio-sidecar-injector

istio-sidecar-inj ector 是负责向动注入的组件，只要开启了自动注入，在Pod 创建时就会自动调用istio-sidecar-injector 向Pod 中注入Sidecar 容器。
在Kubernetes环境下，根据自动注入配置， Kube-apiserver 在拦截到Pod 创建的请求时，会调用自动注入服务istio-sidecar-injector生成Sidecar 容器的描述并将其插入原Pod的定义中，这样，在创建的Pod 内除了包括业务容器，还包括Sidecar 容器。这个注入过程对用户透明，用户使用原方式创建工作负载。

istio-ingressgateway

istio-ingressgateway 就是入口处的Gateway ，从网格外访问网格内的服务就是通过这个Gateway 进行的。istio-ingressgateway 比较特别，是一个Loadbalancer 类型的Service,不同于其他服务组件只有一两个端口,istio-ingressgateway 开放了一组端口，这些就是网格内服务的外部访问端口.如下图所示，网格入口网关istio-ingressgateway 的负载和网格内的Sidecar 是同样的执行体，也和网格内的其他Sidecar 一样从Pilot处接收流量规则并执行。。Istio 通过一个特有的资源对象Gateway 来配置对外的协议、端口等。