【从小白到专家】Istio系列之二：核心组件介绍

Istio，被称作Kubernetes的最佳云原生拍档。我们推出“Istio技术实践”系列专题，在本专题中，将通过技术文章+视频授课的方式，为大家详细阐述Istio微服务治理，及在企业级云平台中的解决方案和实践。同时，您还可以申请试用灵雀云基于原生Istio和Kubernetes的微服务产品ASM！

上一篇文章中，我们讲到Istio的基本概念、架构基础。Istio 作为 Service Mesh 领域的集大成者,提供了流控、安全、遥测等模型，其功能复杂，模块众多，本篇文章会对Istio 1.3.5 的各组件进行分析，帮助大家了解Istio各组件的职责、以及相互的协作关系。

Istio架构回顾

• 数据平面：

数据平面由一组 sidecar 的代理（Envoy）组成。这些代理调解和控制微服务之间的所有网络通信，并且与控制平面的 pilot通讯，接受调度策略。

• 控制平面：

控制平面通过管理和配置 Envoy 来管理流量。此外，控制平面pilot下发xds规则来实施路由策略，mixer收集检测到的监控数据。

虽然Istio 支持多个平台, 但将其与 Kubernetes 结合使用，其优势会更大, Istio 对Kubernetes 平台支持也是最完善的, 本文将基于Istio + Kubernetes 进行展开。

下面就来介绍Istio 架构中每个组件的功能及工作方式。

Istio核心组件

• Sidecar ( 在 Istio 中，默认的 Sidecar 是 Envoy )

Envoy 是使用 C++ 开发的高性能代理，用于调解服务网格中所有服务的入站和出站流量。在 Istio 中，Envoy 被用于 Sidecar ，和对应的应用服务部署在同一个 Kubernetes 的 Pod 中。

Envoy 调解所有出入应用服务的流量。所有经过 Envoy 的流量行为都会调用 Mixer（只是report功能，check功能可以通过配置关闭），为Mixer 提供一组描述请求和请求周围环境的 Attribute 。根据 Envoy 的配置和 Attribute，Mixer 会调用各种后台的基础设施资源。而这些 Attribute 又可以在 Mixer 中用于决策使用何种策略，并发送给监控系统，以提供整个网格行为的信息。

• Pilot

Pilot 为 Sidecar 提供“服务发现”功能，并管理高级路由( 如 A/B 测试和金丝雀部署 )和故障处理( 超时、重试、熔断器等 )的流量。Pilot 将这些“高级”的流量行为转换为详尽的 Sidecar (即 Envoy) 配置项，并在运行时将它们配置到 Sidecar 中。

Pilot 将服务发现机制提炼为供数据面使用的 API ，即任何 Sidecar 都可以使用的标准格式。这种松耦合的设计模式使 Istio 能在多种环境( Kubernetes、Consul 和 Nomad )下运行，同时保持用于流量管理操作的相同。

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

• Mixer

Mixer 是一个独立于平台的组件，通过从 Sidecar 和一些其他服务处收集数据，进而在整个 Service Mesh 上控制访问和执行策略。Sidecar 请求级别的 Attribute 被发送到 Mixer 进行评估。

Mixer 中还包括一个灵活的插件，使其能接入各种主机环境和基础设施的后段，并得到 Sidecar 代理和 Istio 所管理的服务。

Mixer 的设计具有以下特点：

• 无状态：Mixer 本身是无状态的，它没有持久化存储的管理功能。
• 高可用：Mixer 被设计成高度可用的组件，任何单独的 Mixer 实例实现 > 99.999% 的正常运行时间。
• 缓存和缓冲：Mixer 能够积累大量短暂的瞬间状态。

Mixer 是Istio 独有的一种设计,不同于Pilot ，在其他平台上总能找到类似功能的服务组件。从调用时机上来说，Pilot 管理的是配置数据，在配置改变时和数据面交互即可；然而，对于Mixer 来说，在服务间交互时Envoy 都会对Mixer 进行一次调用，因此这是一种实时管理。当然，在实现上通过在Mixer 和Proxy 上使用缓存机制，可保证不用每次进行数据面请求时都和Mixer 交互。

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

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

• Citadel

Citadel 通过内置身份和凭证管理提供“服务间”和“最终用户”身份验证。Citadel 可用于升级服务网格中未加密的流量，并能够为运维人员提供基于服务标识( 如 Kubernetes 中 Pod 的标签或版本号 )而不是网络层的强制执行策略。

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-injector 是负责向动注入的组件，只要开启了自动注入，在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 来配置对外的协议、端口等。