术语表

Ambient 模式指的是一种数据面模式， 由每个节点以及可选的按命名空间的组件构成。 在 Ambient 模式下安装 Istio 时创建的网格可以称为 Ambient 网格。 Ambient 模式是基于 Sidecar 部署的替代方案。

注解（Annotation）指的是附加到 Pod 等某个资源的 Kubernetes 注解。 有关 Istio 专用的有效注解列表，请参见 Resource Annotations。

属性控制着网格中服务运行时的行为，是一堆有名字的、有类型的元数据， 它们描述了 Ingress 和 Egress 流量，以及这些流量所在的环境。 Istio 属性包含了一段特定的信息，例如 API 请求的错误代码、 API 请求的延迟或 TCP 请求的原始 IP 地址。例如：

request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: 192.168.0.1
destination.workload.name: example

这些属性由 Istio 的策略和遥测功能来使用。

集群是运行容器化应用程序的一组计算节点。 通常，组成集群的计算节点彼此可以直接连接。 集群通过规则或策略限制外部访问。

容器网络接口（CNI） 是 Kubernetes 用于配置集群网络的标准。 它是使用插件实现的，有两种类型的插件：

• interface 插件，创建网络接口，由集群运营商提供
• chained 插件，可以配置创建的接口，可以由集群上安装的软件提供

Istio 可以在 Sidecar 和 Ambient 模式下与所有遵循 CNI 标准的 CNI 实现配合使用。

为了配置网格流量重定向，Istio 包含一个 CNI 节点代理。 此代理会安装一个链式 CNI 插件，该插件在所有已配置的 CNI 接口插件之后运行。

CNI 节点代理对于 sidecar 模式是可选的， 而对于 ambient 模式是必需的。

控制平面是一组系统服务，这些服务配置网格或者网格的子网来管理工作负载实例之间的通信。 单个网格中控制平面的所有实例共享相同的配置资源。

自定义资源定义 (CRD) 是默认的 Kubernetes API 扩展。即使是在非 Kubernetes 环境下部署的 Istio，也会使用 Kubernetes CRD API 来配置。

数据平面是网格中直接处理并路由工作负载实例之间流量的那一部分。

在 sidecar 模式下，Istio 的数据平面使用部署为 Sidecar 的 Envoy 代理来调解和控制网格服务的所有收发流量。

在 ambient 模式下，Istio 的数据平面使用以 DaemonSet 部署的节点级 ztunnel 代理来调解和控制网格服务的所有收发流量。

数据平面模式是指数据平面使用的是哪种部署模式。 Istio 当前支持三种模式：Sidecar 模式、 Ambient 模式 和 无代理模式。

目标服务 (Destination) 是 Envoy 代表一个源服务工作负载与之打交道的远程上游服务。 这些上游服务可以有多个服务版本，Envoy 根据路由选择对应的版本。

eBPF 是一种可以在特权上下文（例如操作系统内核）中运行程序的技术。 它用于在运行时安全高效地扩展内核的功能，而无需更改内核源代码或加载内核模块。

Envoy 是在 Istio 里使用的高性能代理， 用于为所有服务网格里的服务调度进出的流量。 了解更多关于 Envoy。

外部控制平面（External Control Plane）是从外部管理运行在自己的集群 或者其他基础设施中的网格工作负载的控制平面。 控制平面可以部署在一个集群中，尽管不能部署在它所控制的网格的一部分集群中。 但它的目的是将控制平面与网格的数据平面完全分离开来。

故障域是计算环境中物理或者逻辑的一部分，当关键设备或服务遇到问题时，它也会受到负面影响。

对于 Istio 部署而言，故障域可能包含平台中的多个可用区。

网关是部署在网格边缘的独立 Istio 代理。 网关用于将流量路由进或者路由出网格。

Istio Gateway CR 用于配置网关部署的公开端口。

Kubernetes Gateway API 是用于 Kubernetes 中流量路由的配置 API。它代表了下一代 Kubernetes 入口、 负载均衡和服务网格 API，其设计借鉴了 Istio 的传统 API。

HBONE（HTTP-Based Overlay Network Environment，即基于 HTTP 的上层网络环境） 是在 Istio 组件之间使用的安全隧道化协议。 了解有关 HBONE 的更多信息。

身份是基本的安全基础结构概念。Istio 的身份模型是基于第一阶级的工作负载身份。 在服务之间的通信开始时，双方使用身份信息交换证书来实现相互认证的目的。

客户端根据其安全的命名信息检查服务器的身份，以便确定服务器是否被授权运行服务。

服务器检查客户端的身份，以确定客户端可以访问的信息。服务器基于客户端的身份，来确定配置的策略。

通过使用身份，服务器可以审核访问信息的时间和特定客户端访问的信息内容。 还可以根据客户使用的服务向他们收费，并拒绝任何未付款的客户访问服务。

Istio 身份模型非常灵活，粒度足以代表单个用户、单个服务或者一组服务。 在没有第一阶级服务身份的平台，Istio 可以使用其他的身份为服务实例进行分组，例如服务名称。

Istio 在不同的平台上支持以下服务身份：

• Kubernetes：Kubernetes 服务账户
• GKE/GCE：GCP 服务账户
• GCP：GCP 服务账户
• AWS：AWS IAM 用户/角色 账户
• 本地（非 Kubernetes）：用户账户、自定义服务账户、服务名称、Istio 服务账户或者 GCP 服务账户。 自定义服务账户指现有的服务账户，就像客户身份目录中管理的身份。

注入或 Sidecar 注入是指在创建时使用动态 Webhook 来修改 Pod 规约。注入可用于为网格服务添加 Envoy Sidecar 配置或配置网关 的 Envoy 代理。

有关更多信息，请参阅安装 Sidecar。

请参阅 Istio Operator Custom Resource。

请参阅 Istio Operator Custom Resource。

Istio Operator Custom Resource 通常使用缩写 IOP 或 IO 来表示， 指的是在使用 istioctl install 命令或集群内 Operator 进行安装时用于配置 Istio 安装的自定义资源。

Istiod 组件是单体 Control Plane 二进制的组合体，封装了 Pilot、Galley、Citadel 和 Sidecar 注入器的功能。

更多关于 Istiod。

托管控制平面是一个为客户提供管理的控制平面。 托管控制平面降低了用户部署的复杂性，并通常保证一定水平的性能和可用性。

网格联邦是在网格之间公开服务的一种行为，并且能跨越网格边界进行通信。 每一个网格或许会公开其一部分的服务，使一个或多个其他网格使用此公开的服务。 您可以使用网格联邦来启用网格之间的通信， 可参阅多个网格部署。

Micro-segmentation 是一种安全技术，可在云部署中创建安全区域， 使组织能够将工作负载彼此隔离，并分别保证这些工作负载的安全。

Multi-mesh 是由两个或多个服务网格组成的部署模型。 每个网格都有独立的命名管理和身份管理， 但是您可以通过网格联邦来暴露网格之间的服务， 最终构成一个多网格部署。

Multicluster 是一种部署模型， 由具有多个集群的网格组成。

双向 TLS 通过内置身份和凭证管理，提供强大的服务到服务身份验证。 了解更多关于双向 TLS 身份验证。

在多集群网格中，适用命名空间相同规则， 即所有具有相同给定名称的命名空间都被认为是同一个命名空间。 如果多个集群包含具有相同命名空间名称的 Service，那这些 Service 将被识别为单个组合服务。 默认情况下，对于给定的服务，流量是跨网格中的所有集群进行负载均衡的。

与端口号匹配的端口也必须具有相同的端口名称，才会被视为组合的 service port。

Istio 使用基于一般连接性的网络简化定义。 如果工作负载实例在没有网关的情况下能够直接通信， 那么它们就会在同一个网络上。

Operator 是打包、部署和管理 Kubernetes 应用程序的一种方法。 有关更多信息，请参见 Operator 模式。

Pilot 是 Istio 里的一个组件，它控制 Envoy 代理，负责服务发现、负载均衡和路由分发。

Pod 中包含了一个或多个共享存储和网络的容器（例如 Docker 容器）， 以及如何运行容器的规范。 Pod 是 Istio 的 Kubernetes 部署中的一个 工作负载实例。

主集群是具有控制平面 的集群。 一个网格可以有一个以上的主集群，以用于 HA 或需要低延迟的场景。 主集群可以充当从集群的控制平面。

Proxyless（无代理）是指一种不使用代理运行的数据平面模式， 这种模式直接将网格功能移植到应用程序中。 目前，Istio 支持 Proxyless gRPC 模式， 可以在 gRPC 框架中启用网格功能。

从集群是一个连接到集群外部 控制平面 的集群。 从集群可以连接到 主集群 的控制平面，或连接到一个 外部控制平面。

您在虚拟服务中配置的路由规则， 遵循服务网格定义了请求的路径。使用路由规则，您可以定义将寻址到虚拟服务主机的流量路由到指定目标的工作负载。 路由规则使您可以控制流量，以实现如 A/B 测试、金丝雀发布以及按百分比分配流量的分阶段发布等任务。

术语“安全覆盖”或“安全 L4 覆盖”用于统称通过 ztunnel 代理在 Ambient 网格中实现的一组 L4 网络功能。 在传输层，这是通过基于 HTTP CONNECT 的流量隧道协议（称为 HBONE）实现的。

Secure Naming 提供一个 service name 到 workload instance principals 的映射，这个工作负载实例被授权运行一个 workload instances，实现一个 service。

使用服务名称标识一组具有关联行为的服务服务网格，并使用这些名称应用 Istio 策略（例如负载均衡和路由）。 服务通常由一个或多个服务 Endpoint 实现，并且或许包含多个服务版本。

服务消费者是使用 service 的代理。

Service Endpoint 是一个 Service 的网络可达表现形式。 Service Endpoint 由工作负载实例暴露，但并不是所有的服务都有 Service Endpoint。

服务网格 （简称 网格 ）是一个可管理、可观测以及支持工作负载实例之间进行安全通信的基础设施层。

在一个网格中，服务名称与命名空间组合具有唯一性。例如，在一个多集群的网格中， cluster-1 集群的 foo 命名空间中的 bar 服务和 cluster-2 集群的 foo 命名空间中的 bar 服务被认为是同一个服务。

由于服务网格会共享这种标识， 因此同一服务网格内的工作负载实例可以相互认证通信。

Service Name 是 Service 唯一的名字， 是 Service 在服务网格里的唯一标识。 一个服务不应该被重命名，或者维护它的标识，每一个服务名都是唯一的。 一个服务有多个版本，但是服务名是与版本独立的。

Service Operator 是在服务网格里管理 Service 的代理，它们通过操纵配置状态并通过各种仪表板监视服务的运行状况来管理这些服务。

创建服务的 pilot-agent。

Istio 维护了一个内部服务注册表 (service registry)，它包含在服务网格中运行的一组服务及其相应的服务 endpoints。 Istio 使用服务注册表生成 Envoy 配置。

Istio 不提供服务发现， 尽管大多数服务都是通过 Pilot adapter 自动加入到服务注册表里的， 而且这反映了底层平台（Kubernetes、Consul、plain DNS）的已发现的服务。还有就是，可以使用 ServiceEntry 配置进行手动注册。

区分一系列服务，通常通过工作负载二进制文件的不同版本来帮助确定。在一些场景多服务版本是需要的，比如 A/B 测试和金丝雀发布。

Sidecar 通常是与主应用程序一起运行以提供附加功能的容器。 在 Istio 中，Sidecar 模式是一个数据面模式，它同时运行一个 Envoy 代理 Pod。

Source 是 Envoy 代理的下游客户端。 在服务网格里， Source 通常是一个工作负载， 但是入口流量的 Source 有可能包含其他客户端，例如浏览器或移动应用。

每个人的安全生产身份框架（SPIFFE）项目定义了一个框架和一套标准，用于识别和保护基于 Web 服务之间的通信。

更多关于 SPIFFE。

TLS 源（TLS Origination）发生于一个被配置为接收内部未加密 HTTP 连接的 Istio 代理（Sidecar 或 Egress Gateway）加密请求并使用简单或双向 TLS 将其转发至安全的 HTTPS 服务器时。 这与 TLS 终止相反，后者发生于一个接受 TLS 连接的 Ingress 代理解密 TLS 并将未加密的请求传递到网格内部的服务时。

信任域对应于系统的信任根，并且是工作负载标识的一部分。

Istio 使用信任域在网格中创建所有身份。每个网格都有一个专用的信任域。

例如在 spiffe://mytrustdomain.com/ns/default/sa/myname 中标示网格的子字符串是：mytrustdomain.com。此子字符串是此网格的信任域。

更改 Istio 网格的信任域的过程。

Waypoint 是在 Ambient 模式中的七层代理组件。 Waypoint 通常基于每个命名空间运行并处理进入该命名空间的所有流量。

operators 部署的二进制文件，用于提供服务网格应用的一些功能。 工作负载有自己的名称、命名空间和唯一的 ID。 这些属性可以通过下面的属性被策略配置和遥测配置使用：

• source.workload.name, source.workload.namespace, source.workload.uid
• destination.workload.name, destination.workload.namespace, destination.workload.uid

在 Kubernetes 环境中，一个工作负载通常对应一个 Kubernetes Deployment， 并且一个工作负载实例对应一个独立的被 Deployment 管理的 Pod。

工作负载实例是工作负载的一个二进制实例化对象。 一个工作负载实例可以开放零个或多个服务 Endpoint， 也可以消费零个或多个服务。

工作负载实例具有许多属性：

• 名称和命名空间
• 唯一的 ID
• IP 地址
• 标签
• 主体

通过访问 source.* 和 destination.* 下面的属性，在 Istio 的策略和遥测配置功能中，可以用到这些属性。

工作负载实例主体是工作负载实例的可验证权限。 Istio 的服务到服务身份验证用于生成工作负载实例主体。默认情况下，工作负载实例主体与 SPIFFE ID 格式兼容。

在 policy 和 telemetry 配置中用到了工作负载实例主体，对应的属性是 source.principal 和 destination.principal。

Ztunnel 指的是 Ambient 数据平面模式中的节点代理组件。 Ztunnel 在每个节点上运行，使用 HBONE 协议安全地传输流量。

更多细节请参阅 Ambient 数据平面文档。

自动 mTLS 是 Istio 的一个特性， 用以发送双向 TLS 流量， 其中客户端和服务器都能够处理双向 TLS 流量。 当客户端或服务器无法处理此类流量时，Istio 会将其降级为纯文本。