Istio 整体架构

Istio 从逻辑上分为数据平面(Data Plane)和控制平面(Control Plane)。

  • 数据平面:由整个网格内的 Sidecar 代理组成,这些代理以 Sidecar 的形式和应用服务一起部署。这些代理负责协调和控制应用服务之间的所有网络通信。每一个 Sidecar会接管进入和离开服务的流量,并配合控制平面完成流量控制等方面的功能。
  • 控制平面:控制和管理数据平面中的 Sidecar 代理,完成配置分发、服务发现、流量路由、授权鉴权等功能,以达到对数据平面的统一管理。在 Istio 1.5 版本中,控制平面由原来分散的、独立部署的几个组件整合为一个独立的 istiod,变成了一个单进程、多模块的组织形态。同时,在 Istio 1.5 版本中,基于性能、部署方便考虑,废弃了Mixer,转而将这些功能放到了 Sidecar 中。

下图展示了组成每个平面的不同组件:

Istio架构图
图 4.1.1:Istio架构图

1、核心组件

下面将简单的介绍一下 Istio 架构中几个核心组件的主要功能。

1.1 Proxy

Proxy 位于数据平面,即:常说的 Sidecar 代理,与应用服务以 Sidecar 方式部署在同一个 Pod 中。Proxy 实际上包括 istio-proxy 和 pilot-agent 两部分,它们以两个不同的进程部署在同一个容器 istio-proxy 中。

istio-proxy

Istio 的数据平面默认使用 Envoy 的扩展版本作为 Sidecar 代理(即:istio-proxy),istio-proxy 是基于 Envoy 新增了一些扩展,其代码仓库位于 istio/proxy

注:理论上,Istio 是支持多种 Sidecar 代理,其中 Envoy 作为默认提供的数据平面,如无特殊说明在 Istio 中通常所说的 Envoy 就是 istio-proxy。

Envoy 是用 C++ 开发的高性能代理,用于协调服务网格中所有服务的入站和出站流量,是唯一与数据平面流量交互的组件。主要包括三部分能力:

  • 动态服务发现、负载均衡、路由、流量转移。
  • 弹性能力:如超时重试、熔断等。
  • 调试功能:如故障注入、流量镜像等。

polit-agent

pilot-agent,负责管理 istio-proxy 的整个生命周期,具体包括 istio-proxy 准备启动参数和配置文件,负责管理 istio-proxy 的启动过程、运行状态监控以及重启等。其代码仓库位于 istio/istio/pilot/cmd/pilot-agent

部署上,isito-proxy 不是单独构建镜像,而是和 polit-agent 一起打包构建成一个镜像 istio/proxyv2,poilt-agent 将会以子进程的方式启动 istio-proxy,并监控 istio-proxy 的运行状态。

1.2 Istiod

自 Istio 1.5 版本开始,控制平面由原来分散、独立部署的三个组件(Pilot、Citadel、Galley)整合为一个独立的 istiod,变成了一个单进程、多模块的组织形态,极大的降低了原来部署的复杂度。

Pilot

负责 Istio 数据平面的 xDS 配置管理,具体包括:

  • 服务发现、配置规则发现:为 Sidecar 提供服务发现、用于智能路由的流量管理功能(例如,A/B 测试、金丝雀发布等)以及弹性功能(超时、重试、熔断器等)。通过提供通用的流量管理模型和服务发现适配器(Service Discovery Adapter),来对接不同平台的适配层。
  • xDS 配置下发:提供统一的 xDS API,供 Sidecar 调用。将路由规则等配置信息转换为 Sidecar 可以识别的信息,并下发给数据平面。

注:这里实际上是指 pilot-discovery,代码仓库位于 istio/istio/pilot/cmd/pilot-discovery

Citadel

负责安全证书的管理和发放,可以实现授权和认证等操作。

Citadel 并不是唯一的证书管理方式,Istio 当前支持 Citadel、Vault 和 Google 等多种证书管理方式,Citadel 是当前默认的证书管理方式。

Galley

Galley 是 Istio 1.1 版本中新引入的配置管理组件,主要负责配置的验证、提取和处理等功能。其目的是将 Istio 和底层平台(如 Kubernetes)进行解耦。

在引入 Galley 之前,Istio 控制平面的各个组件需要分别对 Kubernetes 资源进行管理,包括资源的配置验证,监控资源配置变化,并针对配置变更采取相应的处理等。

2、设计目标

几个关键的设计目标形成了 Istio 的架构,这些目标对于使系统能够大规模和高性能地处理服务是至关重要的。

  • 对应用透明性:从本质上说,对应用透明是 Service Mesh 的特性,一个合格的 Service Mesh 产品都应该具有这一特性,否则也就失去了网格产品的核心竞争力。为此,Istio 自动将自己注入到服务之间的所有网络路径中,做到对应用的透明性。Istio 使用 Sidecar 代理来捕获流量,并在不更改已部署应用程序代码的情况下,自动对网络层进行配置,以实现通过这些代理来路由流量。
  • 可扩展性:Istio 认为,运维和开发人员随着深入使用 Istio 提供的功能,会逐渐涌现更多的需求,主要集中在策略方面。因此,为策略系统提供足够的扩展性,成为了 Istio 的一个主要的设计目标。
  • 可移植性:考虑到现有云生态的多样性,Istio 被设计为可以支持不同的底层平台,也支持本地、虚拟机、云平台等不同的部署环境。不过从目前的情况来看,Istio 和 Kubernetes 还是有着较为紧密的依赖关系,平台无关性、可移植性将是 Istio 最终实现目标。
  • 策略一致性:Istio 使用自己的 API 将策略系统独立出来,而不是集成到 Sidecar 中,从而允许服务根据需要直接与之集成。同时,Istio 在配置方面也注重统一和用户体验的一致性。一个典型的例子是路由规则都统一由虚拟服务来配置,可在网格内、外以及边界的流量控制中复用。

3、Istio 架构演进

从 2017 年 5 月发布以来,Istio 经历了四个重要的版本和由此划分的三个发展阶段。在不到三年的产品迭代过程中,出现了两次重大的架构变动。

  • 0.1 版本:2017 年 5 月发布。作为第二代 Service Mesh 的开创者,宣告了 Istio 的诞生,也燃起了网格市场的硝烟与战火。
  • 1.0 版本:发布于 2018 年 7 月,对外宣传生产环境可用。从 0.1 到 1.0 版本,开发时间经历了一年多,但持续的发布了多个 0.x 版本,这一阶段处于快速迭代期。
  • 1.1 版本:发布于 2019 年 3 月,号称企业级可用的版本。一个小的版本号变化居然耗费了半年之久,其主要原因是出现了第一次架构重构,这一阶段算是调整期。
  • 1.5 版本:发布于 2020 年 3 月,再次进行架构的重建,将多组件整合为单体形态的 istiod。从 1.1 到 1.5 版本的一年中,Istio 开始遵循季节性发布,进入了产品的稳定发展期。
Istio架构演进
图 4.1.2:Istio架构演进

接下来,我们将会针对 Istio 数据平面和控制平面展开具体说明。

Copyright © xcbeyond.cn 2021 all right reserved,powered by Gitbook Updated at 2021-09-30 17:35:45

results matching ""

    No results matching ""