istio架构及概念

istio功能特性

流量管理

Istio 简单的规则配置和流量路由允许您控制服务之间的流量和 API 调用过程。Istio 简化了服务级属性（如熔断器、超时和重试）的配置，并且让它轻而易举的执行重要的任务（如 A/B 测试、金丝雀发布和灰度发布）。

安全

istio 的安全特性解放了开发人员，使其只需要专注于应用程序级别的安全。Istio 提供了底层的安全通信通道，并为大规模的服务通信管理认证、授权和加密。有了 Istio，服务通信在默认情况下就是受保护的，可以让您在跨不同协议和运行时的情况下实施一致的策略——而所有这些都只需要很少甚至不需要修改应用程序。

Istio 是独立于平台的，可以与 Kubernetes（或基础设施）的网络策略一起使用。但它更强大，能够在网络和应用层面保护pod到 pod 或者服务到服务之间的通信。

可观察性

Istio 健壮的追踪、监控和日志特性让您能够深入的了解服务网格部署。通过 Istio 的监控能力，可以真正的了解到服务的性能是如何影响上游和下游的；而它的定制 Dashboard 提供了对所有服务性能的可视化能力，并让您看到它如何影响其他进程。

扩展性

WebAssembly 是一种沙盒技术，可以用于扩展 Istio 代理（Envoy）的能力。Proxy-Wasm 沙盒 API 取代了 Mixer 作为 Istio 主要的扩展机制。在 Istio 1.6 中将会为 Proxy-Wasm 插件提供一种统一的配置 API。

istio架构

istio 服务网格从逻辑上分为数据平面和控制平面。

• 数据平面 由一组智能代理（Envoy）组成，被部署为 sidecar。这些代理负责协调和控制微服务之间的所有网络通信。他们还收集和报告所有网格流量的遥测数据。
• 控制平面 管理并配置代理来进行流量路由。
  
  Istio 中的流量分为数据平面流量和控制平面流量。数据平面流量是指工作负载的业务逻辑发送和接收的消息。控制平面流量是指在 Istio 组件之间发送的配置和控制消息用来编排网格的行为。Istio 中的流量管理特指数据平面流量。

istio只是实现了servicemesh控制面，整合了Envoy作为数据面的sidecar，一起对流量进行控制

主要组件

• Envoy
  Istio 使用 Envoy 代理的扩展版本。Envoy 是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。
  Envoy 代理被部署为服务的 sidecar，在逻辑上为服务增加了 Envoy 的许多内置特性，例如：动态服务发现、负载均衡、TLS 、HTTP/2 与 gRPC 代理、熔断器、健康检查、基于百分比流量分割的分阶段发布、故障注入、丰富的指标

• Istiod
  从 Istio 1.5 开始，更改了 Istio 的打包方式，将控制平面功能（Pilot，Galley，Citadel 和 sidecar 注入器）合并为一个被称为 istiod 的二进制文件(原来是微服务架构)。为什么要吃自己的狗粮？参见https://preliminary.istio.io/latest/zh/blog/2020/istiod/

• Mixer
  用于扩展istio的功能，该组件新版本已废弃，现在可以使用 Wasm 扩展 Envoy，详见https://preliminary.istio.io/latest/zh/blog/2020/wasm-announce/

• Pilot
  Pilot 为 Envoy sidecar 提供服务发现、用于智能路由的流量管理功能（例如，A/B 测试、金丝雀发布等）以及弹性功能（超时、重试、熔断器等）。
  Pilot 将控制流量行为的高级路由规则转换为特定于环境的配置，并在运行时将它们传播到 sidecar。Pilot 将特定于平台的服务发现机制抽象出来，并将它们合成为任何符合 Envoy API 的 sidecar 都可以使用的标准格式。
  

• Citadel
  Citadel 通过内置的身份和证书管理，可以支持强大的服务到服务以及最终用户的身份验证。您可以使用 Citadel 来升级服务网格中的未加密流量。

• Galley
  Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节隔离开来。 它不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley 作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给控制面的Pilot服务使用，这样其他控制面组件只用和Galley 打交道，从而与底层平台解耦。

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

流量管理相关概念

服务发现确保了服务间的可访问性，但是对于服务网格来说，更重要的是需要能够对服务间的访问进行控制，本质上就是需要定义服务间的访问规则。用户仅需利用Istio提供的抽象的资源对象定义服务间的访问关系，而无须关心底层复杂的流量转发过程，就能轻松实现A/B测试、金丝雀发布、熔断、故障注入等一系列复杂的流量管理操作。
Istio中与流量管理相关的资源对象（k8s CRD）主要有：

• Virtualservice：用于定义路由规则，如根据来源或 Header 制定规则，或在不同服务版本之间分拆流量。
• DestinationRule：定义目的服务的配置策略以及可路由子集。策略包括断路器、负载均衡以及 TLS 等。
• ServiceEntry：可以使用ServiceEntry向Istio中加入附加的服务条目，以使网格内可以向istio 服务网格之外的服务发出请求。
• Gateway：为网格配置网关，以允许一个服务可以被网格外部访问。
• Workload：能够描述单个非Kubernetes工作负载的属性，例如VM或裸机服务器，这些工作负载已装入网格中。WorkloadEntry 必须附带一个Istio ServiceEntry，该Istio通过适当的标签选择工作负载并提供服务的服务定义MESH_INTERNAL（主机名，端口属性等）。一个 ServiceEntry对象可以根据服务条目中指定的标签选择器来选择多个工作负载条目以及Kubernetes Pod。
• WorkloadGroup：描述工作负载实例的集合。它提供了一个规范，工作负载实例可用于引导其代理，包括元数据和身份。旨在与非k8s工作负载（例如虚拟机）一起使用，并且模仿现有的用于Kubernetes工作负载的Sidecar注入和部署规范模型，以引导Istio代理。
• SideCar：缺省情况下，Pilot将会把和Envoy Sidecar所在namespace的所有services的相关配置，包括inbound和outbound listenter, cluster, route等，都下发给Enovy。使用Sidecar可以对Pilot向Envoy Sidcar下发的配置进行更细粒度的调整，例如只向其下发该Sidecar 所在服务需要访问的那些外部服务的相关outbound配置。
• EnvoyFilter：EnvoyFilter提供了一种自定义Istio Pilot生成的Envoy配置的机制。

数据面相关概念

• Host：能够进行网络通信的实体（如移动设备、服务器上的应用程序）。在此文档中，主机是逻辑网络应用程序。一块物理硬件上可能运行有多个主机，只要它们是可以独立寻址的。在EDS接口中，也使用“Endpoint”来表示一个应用实例，对应一个IP+Port的组合。
• Downstream：下游主机连接到 Envoy，发送请求并接收响应。
• Upstream：上游主机接收来自 Envoy 的连接和请求，并返回响应。
• Listener：监听器是命名网地址（例如，端口、unix domain socket等)，可以被下游客户端连接。Envoy 暴露一个或者多个监听器给下游主机连接。在Envoy中,Listener可以绑定到端口上直接对外服务，也可以不绑定到端口上，而是接收其他listener转发的请求。
• Cluster：集群是指 Envoy 连接的一组上游主机，集群中的主机是对等的，对外提供相同的服务，组成了一个可以提供负载均衡和高可用的服务集群。Envoy 通过服务发现来发现集群的成员。可以选择通过主动健康检查来确定集群成员的健康状态。Envoy 通过负载均衡策略决定将请求路由到哪个集群成员。可以理解为一个微服务有多个实例组成，这多个实例就是一个Cluster。

pilot子组件

• pilot-discovery
  服务发现组件。从Service provider（如kubernetes或者consul）中获取服务信息，从K8S API Server中获取流量规则(K8S CRD Resource)，将服务信息和流量规则转化为数据面可以理解的格式，通过标准的数据面API下发到网格中的各个sidecar中。
• pilot-agent
  agent组件。根据K8S API Server中的配置信息生成Envoy的配置文件，并负责启动Envoy进程。注意Envoy的大部分配置信息都是通过xDS接口从Pilot中动态获取的，因此Agent生成的只是用于初始化Envoy的少量静态配置。

xDS

Istio数据面API定义了xDS服务接口，Pilot通过该接口向数据面sidecar下发动态配置信息，以对Mesh中的数据流量进行控制。xDS中的DS表示discovery service，即发现服务，表示xDS接口使用动态发现的方式提供数据面所需的配置数据。而x则是一个代词，表示有多种discover service。Envoy通过xDS API可以动态获取Listener（监听器），Route（路由）， Cluster（集群）， Endpoint（集群成员）以及Secret（证书）配置。

• LDS(Listener Discovery Service)
  LDS是Listener发现服务。Listener监听器控制Envoy启动端口监听（目前只支持TCP协议），并配L3/L4层过滤器，当网络连接达到后，配置好的网络过滤器堆栈开始处理后续事件。这种通过监听器体系结构用于执行大多数不同的代理任务(限流，客户端认证，HTTP连接管理，TCP代理等)。

• RDS(Route Discovery Service)
  Route发现服务，用于HTTP连接管理过滤器动态获取路由配置路由配置包含HTTP头部修改（增加、删除HTTP头部键值），virtual hosts （虚拟机），以及virtual hosts定义的各个路由条目。

• CDS(Cluster Discovery Service)
  Cluster发现服务，用于动态获取Cluster信息。Envoy cluster管理器管理着所有的上游cluster。鉴于上游Cluster或者主机可用于任何代理转发任务，所有上游Cluster一般从Listener或者Route中抽象出来。

• EDS(Endpoint Discovery Service)
  Endpoint发现服务。Endpoint就是ip+port组成。在Envoy 术语中，Cluster成员就叫Endpoint，对于每个CLuster，Envoy通过EDS API动态获取Endpoint。EDS作为首选服务发现的原因有两点：
  与通过DNS解析的负载均衡器进行路由相比，Envoy能明确的知道每个上游主机的信息，因而可以做出更加智能的负载均策略。
  Endpoint配置包含负载均衡权重、可用域等附加主机属性，这些属性可用于服务网格负载均衡，统计收集等过程中。

• SDS(Secret Discovery Service)
  Secret发现服务，用于运行时动态获取TLS证书。若没有SDS特性，在k8s环境中必须创建包含证书的Secret，代理启动前Secret必须挂载到sidecar容器中，如果证书过期，则需要重新部署。使用SDS，集中式的SDS服务器将证书分发给所有的Envoy实例，如果证书过期，服务器会将新证书分发，Envoy接收到新的证书后重新加载儿不用重新部署。

引用参考

https://istio.io/latest/zh/docs/ops/deployment/architecture/
https://zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro