Istio从入门到精通—— Istio 的主要组件

Istio 的主要组件

https://github.com/istio/istio#introduction

    Istio 主要由控制面组件和数据面组件组成。

    Istio 当前最新版：(https://github.com/istio/istio/releases/download/1.20.0/istio-1.20.0-linux-amd64.tar.gz) 默认安装的组件如下：

Envoy

　　Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The proxies form a secure microservice mesh providing a rich set of functions like discovery, rich layer-7 routing, circuit breakers, policy enforcement and telemetry recording/reporting functions.

每个微服务都使用Sidecar代理来处理集群中服务之间以及从服务到外部服务的出入站流量。代理形成安全的微服务网格，提供丰富的功能，如发现、丰富的7层路由、断路器、策略执行和遥测记录/报告功能。

Istiod

　　The Istio control plane. It provides service discovery, configuration and certificate management. It consists of the following sub-components:

Istio 控制平面。它提供服务发现、配置和证书管理。它由以下子组件组成：

• • Pilot - Responsible for configuring the proxies at runtime.

    Pilot 英[ˈpaɪlət] 美[ˈpaɪlət] : 负责在运行时配置代理。

  • Citadel - Responsible for certificate issuance and rotation.

    Citadel 英[ˈsɪtədəl] 美[ˈsɪtədəl] : 负责证书的发放和置换。

  • Galley - Responsible for validating, ingesting, aggregating, transforming and distributing config within Istio.

    Galley 英[ˈɡæli] 美[ˈɡæli] : 负责在Istio中验证、摄取、聚合、转换和分发配置。

Operator

　　The component provides user friendly options to operate the Istio service mesh.

该组件提供用户友好的选项来操作 Istio 服务网格。

一、控制面的组件

  在 1.5 版本之前，Istio 一直使用微服务模式，在 Pilot，Gally、Citadel、Mixer 等组件之间具有明显的界限隔离。与单体模式相比，采用这种微服务的开发方式并没有明显的优势，反而增加了复杂性。

  因此，社区在单体应用 Istiod 的设计中提出了一系列的建设，从根本上降低了 Istio 对运维人员的经验要求，主要如下：

• • 简化安装配置：组件之间的依赖关系被封装和隐藏，通用的配置参数大大减少。
  • 简化配置复杂度：Istiod 消除了很大一部分控制面组件编排的配置，提供了对系统配置和可视化操作性进行其他简化的机会。
  • 简化控制面板维护：运维人员和安装人员较少感知内部组件依赖项的变化，以及在实际生产系统中对版本进行控制。
  • 问题定位：更少的组件和更少的跨组件通信使控制面问题更容易发现。
  • 提高效率及响应能力：组件之间的通信不会产生网络开销，并且可以安全地共享缓存，启动时间大大减少。

  下面介绍控制面功能时，还是会按照各个组件的功能分开介绍：   

1.1、Pilot 英[ˈpaɪlət] 美[ˈpaɪlət]

  Pilot 是 Istio 的控制中枢。如果把数据面的 Envoy 也看作一种 Agent，则 Pilot 类似传统 C/S 架构中的服务端 Master，下发指令控制客户端完成业务功能。在 Istio 中，Pilot 主要包含两部分工作：服务发现和配置管理。

  Pilot 直接从运行平台提取数据并将其构造和转换成 Istio 的服务模型，而且无须为了迁移到 Istio 进行额外的服务注册。这种抽象模型解耦了 Pilot 和底层平台，屏蔽了不同平台的服务差异，可支持 Kubernetes、虚拟机等平台。另外，在非 Kubernetes 环境下，Pilot 支持以 MCP 从其他服务端获取配置。MCP 是一种基于 xDS 的协议，主要通过使用 MCP 抽象来规范配置处理，并且避免 Istio 维护各种各样的注册中心适配代码，以及 Istio 核心功能分裂。

  除了服务发现，Pilot 更重要的一个功能是构造维护和向数据面下发规则，包括 VirtualService、DestinationRule、Gateway 等流量规则，也包括 RequestAuthentication、PeerAuthentication、AuthorizationPolicy 等安全规则。

  Pilot 负责将各种规则转换成 Envoy 可识别的格式，通过标准协议 xDS 协议发送给 Envoy，指导 Envoy 完成工作。

    在通信上，Envoy 通过 gRPC 流式订阅 Pilot 的配置资源。即作为 xDS 服务器，Pilot 内部启动了一个 gPRC 服务，用来承载数据面 Sidecar 的连接并处理 xDS 的订阅请求。

1.2、Citadel 英[ˈsɪtədəl] 美[ˈsɪtədəl]

  Citadel 是 Istio 的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书的功能。Citadel 为工作负载提供了两种形式的证书：

• • • 默认双向 TLS 所使用的证书，无须用户指定，Citadel 将根据工作负载的身份自动为其签发；
    • 用户指定的证书，主要用在服务网格入口网关上，用户为入口网关指定指定权威机构颁发的证书。

  控制面板组件 Citadel 提供服务网格的证书管理功能，数据面服务代理基于证书和密钥提供透明的服务间安全访问功能。

1.3、Galley 英[ˈɡæli] 美[ˈɡæli]

  Gally 服务网格控制面负责配置管理的组件。首先作为 Webhook Server，在配置创建过程中验证配置信息的格式和内容的正确性，即作为 Kubernetes 的准入控制器，在 Istio API 对象创建阶段对其他进行校验，拦截非法的配置。Galley 还负责监控（Watch）各种各样的 API 对象，包括 ServiceEntry、WorkloadEntry、Gateway、VirtualService 等，当资源对象发生变化时，通知 Pilot 根据最新的 API 对象生成 xDS 配置，并推送相关的数据面 Sidercar。目前 API 对象源支持 Kubernetes、MCP、文件系统。 

1.4、Sidecar-injector 英[ɪnˈdʒɛktə] 美[ɪnˈdʒɛktər]

  Sidecar-injector 负责自动注入的组件。Istio 只要开启了自动注入，在 Pod 创建时，Kubernetes 就会自动调用 Sidecar-inject 向 Pod 注入 Sidecar 容器。

  在 Kubernetes 环境下，根据自动注入配置模版，Kube-apiserver 在拦截到 Pod 创建的请求时，会调用 Sidecar-injector 生成 istio-init 和 istio-proxy 容器，并将其插入原 Pod 的定义中。这样，在创建的 Pod 中除了包括业务容器，还包括 Init 和 Sidecar 容器。容器的注入过程对用户完全透明，用户使用原方式创建工作负载。

二、数据面的组件

  一般来说，服务网格数据面组件特定指数据面代理 Istio-proxy。但考虑到当前服务网格在大规模多种形态应用下的不同实践，数据面也有很多种不同形态，都接收来自控制面的配置，统一执行相应的动作。

2.1、Istio-proxy

  Istio 的数据面的主要组件是 Istio-proxy，也称为 Envoy 代理。

  Istio-proxy（Envoy代理）是一个高性能的代理，用于调解和控制微服务之间所有的网络通信。它部署在每个微服务的旁边，作为一个“sidecar”代理，处理所有进出该微服务的流量。Istio-proxy 解决了在分布式或微服务体系结构中开发人员和运营商面临的挑战，例如服务发现、负载均衡、流量管理、安全性和可观察性等。通过 Istio-proxy，开发人员可以专注于解决业务领域问题，而将这些通用问题交给服务网格处理。

  Istio-proxy 和 Envoy 的关系是，Istio-proxy 基于 Envoy 代理构建（Istio-proxy 包括 Envoy 和 Pilot-agent的守护进程）。Envoy 是用 C++开发的非常有影响力的轻量级、高性能开源服务代理。作为服务网格的数据面，设计用于云原生应用，Envoy 体用了动态服务发现、负载均衡、TLS、HTTP/2 及 gRPC 代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。其大部分的治理能力最终都落实到 Envoy 的实现上。

  Pilot-agent 由原来独立的 Pilot-agent 及 Node-agent 合并而来，将 Envoy 的启动管理及 SDS 证书服务统一为单体，进一步简化了 Isito 在虚拟机及裸金属服务器上的安全和维护。

  Istio 在 2022 年 9 月推出了另一种共享代理的数据面模式 Ambient 英[ˈæmbiənt] 美[ˈæmbiənt]，在不使用传统 Sidecar 的情况下，保持零信任安全、流量管理和可观测性等核心功能。但相比 Sidecar 模式，其业务侵入性更低，升级管理更简单。

  Istio项目的愿景是以尽量透明的方式，解决微服务场景下，服务间的连接、安全以及可观测性问题。主要实现手段则是通过在应用旁部署一个Proxy，在Kubernetes场景下则为应用Pod注入Sidecar，拦截应用流量至Sidecar。Sidecar根据从Istio控制面获取的用户配置对应用流量进行处理，以一种对应用代码几乎无侵入的方式实现了服务治理。

  虽然以Sidecar模式部署Istio数据面似乎是一个理所应当，让人无法拒绝的选择，但是需要强调的是，Istio完整功能的实现并不与Sidecar模式强绑定，我们还有各种各样其他的选择。另外，随着对于Istio使用程度不断加深，落地规模不断扩大，可以发现以Sidecar模式部署Istio数据面诸多挑战：

1. 1. 侵入性：Istio基本实现了对应用代码的零侵入，但是由于Sidecar的注入需要更改Pod Spec并且对应用流量进行重定向，因此应用接入网格时需要重启Pod，而应用容器与Sidecar容器的启动顺序不确定造成的冲突也可能导致应用中断；
   2. 生命周期绑定：Sidecar本质上是基础设施，它和应用的生命周期往往不一致，因此升级Sidecar时也需要对应用Pod进行重启，同样可能导致应用中断，而对于Job类应用，Sidecar的存在则会导致Pod无法被及时清理；
   3. 资源利用率低：Sidecar为单个应用Pod独占，应用的流量存在波峰波谷，而一般情况下Sidecar的内存占用与集群规模（Service数目，Pod数目）强相关，因此需要按照极端情况预留资源，导致集群整体的资源利用率低。同时由于需要为每个Pod注入Sidecar，随着集群规模的不断扩大，Sidecar占用的资源总量也会线性上涨。

  针对Sidecar部署模式的缺陷，Google 和 http://Solo.io 联合推出了一种新的 Sidecar-less 部署模式---Ambient Mesh。让我们对比看 Ambient 代理模型如下，其包括两个组件：ztunnel 和 waypoint。

  ztunnel 以 Daemonset 的方式部署在每个节点上，为服务网格中的应用提供 mTLS、可观测性、身份认证和四层授权等功能，但不进行任何七层协议相关处理。

  waypoint 则专注完成七层治理的能力，包括 HTTP 的路由、负载均衡、熔断、重试等流量管理功能及丰富的七层授权。waypoint 通过单独的 Deployment 部署，可为其配置所需要的 CPU 和内存，设置相关的弹性伸缩策略。waypoint 不再与应用耦合，可以提供更加灵活的扩展性，并在一定程度上提供资源的利用率。

  Ambient Mesh 架构如上图所示，从设计的角度对比看，有两个特点：

• • Sidecar-less：为了避免上述 Sidecar 模式的种种缺陷，Ambient Mesh 不再为任何 Pod 注入 Sidecar，将网格功能的实现进一步下沉到 Istio 自有组件中。
  • L4/L7 处理分层：Ambient Mesh 引入了 ztunnel 和 waypoint 两个组件用于代替原来的 Sidecar 实现相关功能，与 Sidecar 既能处理 L4，又能处理 L7 流量的实现方式不同，Ambient Mesh 对两者进行了区分，ztunnel 只负责 L4 流量的处理，L7 的流量则按需交由 waypoint 处理。
  • 在控制面层面上，Ambient Mesh 架构与原先 Sidecar 架构并没有什么变化，数据面的组件构成以及各个组件作用如下；
    • istio-cni:必装组件，以DaemonSet的形式部署。其实istio-cni并不是Ambient Mesh的新增组件，在原先的Sidecar模式中就已经存在，当时主要用于替代istio-init这个Init Container配置流量拦截规则，同时规避istio-init引发的安全问题。Ambient Mesh对它进行了扩展，以必装组件的形式部署，负责配置流量转发规则，劫持本节点中已加入Ambient Mesh的Pods的应用流量，转发至本节点的ztunnel。
    • waypoint：按需配置，以 Deployment 的形式部署。waypoint 负责处理HTTP，故障注入等L7功能。以负载或者 Namespace 粒度进行部署，在 Kubernetes 中，即一个 Service Account 或者一个 Namespace 对应生成一个 waypoint 的 Deployment，用于处理发往对应负载的七层流量，同时 waypoint 实例数可以根据流量动态伸缩。

      

    • ztunnel：必装组件，以DaemonSet的形式部署。ztunnel对所在节点Pods的流量进行代理，主要负责L4流量的处理、L4的遥测以及服务间mTLS（双向认证）的管理。最初ztunnel基于Envoy实现，但是考虑到对ztunnel功能的有意约束以及对安全性、资源占用率的要求，社区已经用rust从零构建该组件。

    • 为 Istio 环境服务网格引入基于 Rust 的 Ztunnel，https://istio.io/latest/zh/blog/2023/rust-based-ztunnel/

2.2、Proxyless

  我们可以看到，服务网格数据面代理的 Proxy 模式和业务解耦带来极大的运维和开发便利，但也带来一定的资源和性能开销。

  为解决这个问题，在近些年来的服务网格实践中也出现了 Proxyless 的数据面，即业务直接对服务网格控制面，执行控制面的流量规则。

  gRPC 在 2021 年首先支持 xDS，革命性地提出 Proxyless 的概念，gRPC Prexyless 架构的工作原理如下图所示：

2.3、Ingress-gateway

https://istio.io/latest/zh/docs/tasks/traffic-management/ingress/ingress-control/

  Ingress-gateway 是部署在数据面接受服务网格入口流量的一个网关组件。

  虽然在通用的安装包中，这个网关组件和控制面组件都被部署在 istio-system 命名空间下，但在实际的生产应用中建议将其独立部署、升级和运维。

  Along with support for Kubernetes Ingress resources, Istio also allows you to configure ingress traffic using either an Istio Gateway or Kubernetes Gateway resource. A Gateway provides more extensive customization and flexibility than Ingress, and allows Istio features such as monitoring and route rules to be applied to traffic entering the cluster.

除了支持 Kubernetes Ingress 资源外，Istio 还允许您使用 Istio Gateway 或 Kubernetes Gateway 资源配置入口流量。与 Ingress 相比，Gateway 提供了更广泛的定制和灵活性，并允许将 Istio 功能（如监控和路由规则）应用于进入集群的流量。

这里不展开细说 ingress-gateway，需要的看的可以去 istio 官网 => Documentation => Tasks => Traffic Management => Ingress => Ingress Gateways

2.4、Egress-gateway

https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/

  和 Ingress-gateway 网关对应，为了处理服务网格访问外部服务的流量，在 Istio 数据面中规划了一个 Egress-gateway 组件。一般通过配置将外部访问的流量转发到这个对外网关上，再经过网关访问外部服务。

  The Accessing External Services task shows how to configure Istio to allow access to external HTTP and HTTPS services from applications inside the mesh. There, the external services are called directly from the client sidecar. This example also shows how to configure Istio to call external services, although this time indirectly via a dedicated egress gateway service.

“访问外部服务”任务展示了如何配置Istio，以允许网格内部的应用程序访问外部的HTTP和HTTPS服务。在那里，外部服务直接从客户端的sidecar被调用。本示例还展示了如何配置Istio来调用外部服务，尽管这次是通过专用的出口网关服务间接调用。

  Istio uses ingress and egress gateways to configure load balancers executing at the edge of a service mesh. An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through. Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.

Istio使用入口和出口网关来配置在服务网格边缘执行的负载均衡器。入口网关允许您定义网格的入口点，所有进入的流量都通过这些入口点进入。出口网关是一个对称的概念；它定义了从网格退出的出口点。出口网关允许您将Istio功能（例如监视和路由规则）应用于从网格退出的流量。