2.Istio：介绍

Istio是什么？

云平台令使用它们的公司受益匪浅。但不可否认的是，上云会给 DevOps 团队带来压力。为了可移植性，开发人员必须使用微服务来构建应用，同时运维人员也正在管理着极端庞大的混合云和多云的部署环境。 Istio 允许您连接、保护、控制和观察服务。

从较高的层面来说，Istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用程序里。它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 多样化的特性使您能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。

通过负载均衡、服务间的身份验证、监控等方法，Istio 可以轻松地创建一个已经部署了服务的网络，而服务的代码只需很少更改甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理 Istio，这包括：

• 为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。
• 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
• 可插拔的策略层和配置 API，支持访问控制、速率限制和配额。
• 集群内（包括集群的入口和出口）所有流量的自动化度量、日志记录和追踪。
• 在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。

Istio 为可扩展性而设计，可以满足不同的部署需求。

1. Istio是一个用于服务治理的开放平台。

2. Istio是一个Service Mesh形态的用于服务治理的开放平台。

3. Istio是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台。

Istio能做什么

• 自动通过服务发现获取recommendation服务实例列表，并根据负载均衡策略选择一个服务实例；
• 对服务双方启用双向认证和通道加密；
• 如果某个服务实例连续访问出错，则可以将该实例隔离一段时间，以提高访问质量；
• 设置最大连接数、最大请求数、访问超时等对服务进行保护；
• 限流；
• 对请求进行重试；
• 修改请求中的内容；
• 将一定特征的服务重定向；
• 灰度发布；
• 自动记录服务访问信息；
• 记录调用链，进行分布式追踪；
• 根据访问数据形成完整的应用访问拓扑

所有这些功能，都不需要用户修改代码，用户只需在 Istio 的控制面做些配置即可，并且动态生效

Istio架构

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

• 数据平面 由一组智能代理（Envoy）组成，被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。它们还收集和报告所有网格流量的遥测数据。
• 控制平面 管理并配置代理来进行流量路由。

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

数据平面

Istio 数据平面核心是以边车（sidecar）模式运行的智能代理。边车模式将数据平面核心组件部署到单独的流程或容器中，以提供隔离和封装。边车应用与父应用程序共享相同的生命周期，与父应用程序一起创建和退出。边车应用附加到父应用程序，并为应用程序提供额外的特性支持。 如下图所示，数据平面的边车代理可以调节和控制微服务之间所有的网络通信，每个服务 Pod 启动时会伴随启动 istio 和 proxy 容器。其中 Istio-init 容器主要功能是初始化 Pod 网络和对 Pod 设置 iptable 规则，设置完成后自动结束。Proxy 容器会启动两个服务：istio-agent 以及网络代理组件。istio-agent 的作用是同步管理数据，启动并管理网络代理服务进程，上报遥测数据；网络代理组件则根据管理策略完成流量管控、生成遥测数据。数据平面真正触及到对网络数据包的相关操作，是上层控制平面策略的具体执行者。

数据平面（data plane）架构图：

现在常见的数据平面实现有：

• Envoy：Istio 默认使用的数据平面实现方案，使用C++开发，性能较高。
• MOSN：阿里巴巴公司开源，设计类似 Envoy，使用 Go 语言开发，优化过多协议支持。
• Linkerd：一个提供弹性云端原生应用服务网格的开源项目，也是面向微服务的开源 RPC 代理，使用 Scala 开发。它的核心是一个透明代理。因此也可作为典型的数据平面的实现。

Envoy

Istio 使用 Envoy 代理的扩展版本。Envoy 是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。

Envoy 代理被部署为服务的 Sidecar，在逻辑上为服务增加了 Envoy 的许多内置特性，例如：

• 动态服务发现
• 负载均衡
• TLS 终端
• HTTP/2 与 gRPC 代理
• 熔断器
• 健康检查
• 基于百分比流量分割的分阶段发布
• 故障注入
• 丰富的指标

这种 Sidecar 部署允许 Istio 可以执行策略决策，并提取丰富的遥测数据，接着将这些数据发送到监视系统以提供有关整个网格行为的信息。

Sidecar 代理模型还允许您向现有的部署添加 Istio 功能，而不需要重新设计架构或重写代码。

由 Envoy 代理启用的一些 Istio 的功能和任务包括：

• 流量控制功能：通过丰富的 HTTP、gRPC、WebSocket 和 TCP 流量路由规则来执行细粒度的流量控制。
• 网络弹性特性：重试设置、故障转移、熔断器和故障注入。
• 安全性和身份认证特性：执行安全性策略，并强制实行通过配置 API 定义的访问控制和速率限制。
• 基于 WebAssembly 的可插拔扩展模型，允许通过自定义策略执行和生成网格流量的遥测。

控制平面

Pilot

1. 控制面中负责流量管理的组件为Pilot

 Pilot 为 Envoy sidecar 提供服务发现功能，为智能路由（例如 A/B 测试、金丝雀部署等）和弹性（超时、重试、熔断器等）提供流量管理功能。它将控制流量行为的高级路由规则转换为特定于 Envoy 的配置，并在运行时将它们传播到 sidecar。

    Pilot 将平台特定的服务发现机制抽象化并将其合成为符合 Envoy 数据平面 API 的任何 sidecar 都可以使用的标准格式。这种松散耦合使得 Istio 能够在多种环境下运行（例如，Kubernetes、Consul、Nomad），同时保持用于流量管理的相同操作界面。

Pilot实现：

Pilot-Agent：负责的主要工作如下：

• 生成 sidecar 的配置

• Sidecar的启动与监控

pilot-discovery 扮演服务注册中心、Istio控制平面到 sidecar 之间的桥梁作用。pilot-discovery 的主要功能如下：

• 监控服务注册中心（如 Kubernetes）的服务注册情况。在 Kubernetes 环境下，会监控 service、endpoint、pod、node 等资源信息。
• 监控 Istio 控制面信息变化，在 Kubernetes 环境下，会监控包括 RouteRule、 VirtualService、Gateway、EgressRule、ServiceEntry 等以 Kubernetes CRD 形式存在的 Istio 控制面配置信息。
• 将上述两类信息合并组合为 sidecar 可以理解的（遵循 Envoy data plane api 的）配置信息，并将这些信息以 gRPC 协议提供给 sidecar。

Citadel

Citadel 通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持基于角色的访问控制，以控制谁可以访问您的服务。Istio1.5之后的版本取消了其独立进程，将其作为一个模块整合在istiod中。

Citadel主要包括一下内容：

• 证书签发机构（CA）负责密钥和证书管理
• API服务器将安全配置分发给数据平面。
• 客户端、服务端通过代理进行安全通信。
• Envoy代理管理遥测和审计

Galley

Galley原来仅负责配置验证，在Istio1.1版本后升级为整个控制平面的配置管理中心，除了继续提供配置验证功能，还负责配置的管理和分发。Galley可以使用网格配置协议（Mesh Configuration Protocol）和其他组件进行配置的交互。

Istio与K8S

从微服务的工具集观点来看，Kubernetes本身是支持微服务的架构（但也支持其他类型的架构），在Pod中部署微服务很合适，也已经解决了微服务的互访互通问题，但对服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在Kubernetes的能力范围内。

Kubernetes的Service基于每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息，并将对 Service 的请求经过负载均衡转发到对应的 Endpoint 上。但Kubernetes只提供了4层负载均衡能力，无法基于应用层的信息进行负载均衡，更不会提供应用层的流量管理，在服务运行管理上也只提供了基本的探针机制，并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。

Istio复用了Kubernetes Service的定义，在实现上进行了更细粒度的控制。

• Istio的服务发现就是从 Kube-apiserver中获取 Service和 Endpoint，然后将其转换成 Istio服务模型的 Service 和 ServiceInstance

• 其数据面组件不再是 Kube-proxy，而是在每个 Pod 里部署的 Sidecar，也可以将其看作每个服务实例的 Proxy。这样，Proxy 的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理

• 通过拦截Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种应用层协议，Istio可以提供真正的应用层治理、监控和安全等能力。

Istio最大化地利用了Kubernetes这个基础设施，与之叠加在一起形成了一个更强大的用于进行服务运行和治理的基础设施，并提供了更透明的用户体验。

Istio的服务

k8s的Service：

创建了一个名称为 forecast 的 Service，通过一个 ClusterIP 的地址就可以访问这个Service，指向有“app：forecast”标签的Pods。Kubernetes自动创建一个和Service同名的Endpoints对象，Service的selector会持续关注属于Service的Pod，结果会被更新到相应的Endpoints对象。

Istio的Service：

Istio的Service比较简单，可以看到差别就是要满足Istio服务的约束，并在端口名称上指定协议。例如，在以下示例中指定了forecast服务的端口是HTTP，对这个服务的访问就可以应用HTTP的诸多治3002理规则。

Istio虽然依赖于了Kubernetes的Service定义，但是除了一些约束，在定位上还有些差别。在 Kubernetes中，一般先通过 Deploymnent创建工作负载，再通过创建 Service关联这些工作负载，从而暴露工作负载的接口。因而看上去主体是工作负载，Service只是一种访问方式，某些后台执行的负载若不需要被访问，就不用定义Service。

在Istio中，Service是治理的对象，是Istio中的核心管理实体，所以在Istio中，Service是一个提供了对外访问能力的执行体，可以将其理解为一个定义了服务的工作负载，没有访问方式的工作负载不是Istio的管理对象，Kubernetes的Service定义就是Istio服务的元数据。

在Istio的应用场景中，灰度发布是一个重要的场景，即要求一个Service有多个不同版本的实现。而 Kubernetes在语法上不支持在一个 Deployment上定义多个版本，在 Istio中多个版本的定义是将一个Service关联到多个Deployment，每个Deployment都对应服务的一个版本

Istio为什么构建了一套自己特有的服务模型?

Istio的设计原则是努力地、兼容地运行在任何一种云、或者云原生平台上，那么它就自己构建了一个自己特有的服务模型，这样无论何时何地，用户面对的都是统一的服务模型，而底层通过平台适配器将不同平台的服务模型转换成统一的抽象模型。使得Istio成为统一的、标准化的服务治理平台成为现实。