Istio架构剖析 | 文末有福利

Istio是一个开源的服务网格，可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台，开发者必须使用微服务设计架构以实现可移植性，而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio采用一种一致的方式来保护、连接和监控微服务，降低了管理微服务部署的复杂性。

从架构设计上来看，Istio服务网格在逻辑上分为控制平面和数据平面两部分。其中，控制平面Pilot负责管理和配置代理来路由流量，并配置Mixer以实施策略和收集遥测数据；数据平面由一组以Sidecar方式部署的智能代理（Envoy）组成，这些代理可以调节和控制微服务及Mixer之间所有的网络通信。

Istio架构

作为代理，Envoy非常适合服务网格的场景，但要发挥Envoy的最大价值，就需要使它很好地与底层基础设施或组件紧密配合。Envoy构成了服务网格的数据平面，Istio提供的支撑组件则是创建了控制平面。

Pilot与Envoy数据平面

一方面，我们在Envoy中看到，可以使用静态配置文件或使用一组发现服务来配置一组服务代理，以便在运行时发现监听器、端点和集群。Istio在Pilot中实现了这些Envoy代理的xDS API。

另一方面，Envoy的服务发现依赖于某种服务注册表来发现服务端点。Istio Pilot实现了这个API，但也将Envoy从任何特定的服务注册实现中抽象出来。当Istio部署在Kubernetes上时，Kubernetes的服务注册表是Istio用于服务发现的。其他注册表也可以像HashiCorp的Consul那样使用。Envoy数据平面完全不受这些实施细节的影响。

Mixer架构

此外，Envoy代理可以发出很多指标和遥测数据，这些遥测数据发送到何处，取决于Envoy的配置。Istio提供遥测接收器Mixer作为其控制平面的一部分，Envoy代理可以将这些数据发送到Mixer。Envoy还将分布式跟踪数据发送到开放式跟踪引擎（遵循Open Tracing API）。Istio可以支持兼容的开放式跟踪引擎并配置Envoy将其跟踪数据发送到该位置。

剖析Istio控制平面

Istio的控制平面和Envoy的数据平面共同构成了一个引人注目的服务网格实现。两者都拥有蓬勃发展和充满活力的社区，并且面向下一代服务架构。Istio是独立于平台的，可运行于各种环境中，包括跨云、内部部署、Kubernetes、Mesos等。你可以在Kubernetes 上部署Istio或在具有Consul的Nomad上部署。Istio目前支持在Kubernetes上部署的服务、使用Consul注册的服务以及在虚拟机上部署的服务。

其中，控制平面部分包括了Pilot、Mixer、Citadel和Galley四个组件。

Pilot

Istio的Pilot组件用于管理流量，可以控制服务之间的流量流动和API调用，通过Pilot可以更好地了解流量，以便在问题出现之前发现问题。这使得调用更加可靠、网络更加强健，即使遇到不利条件也能让应用稳如磐石。借助Istio的Pilot，你能够配置熔断器、超时和重试等服务级属性，并设置常见的连续部署任务，如金丝雀发布、A/B测试和基于百分比拆分流量的分阶段发布。Pilot为Envoy代理提供服务发现功能，为智能路由和弹性能力（如超时、重试、熔断器等）提供流量管理功能。Pilot将控制流量行为的高级路由规则转换为特定于Envoy代理的配置，并在运行时将它们传播到Envoy。此外，Istio提供了强大的开箱即用故障恢复功能，包括超时、支持超时预算和变量抖动的重试机制、发往上游服务的并发连接和请求数限制、对负载均衡池中的每个成员进行的定期主动运行状况检查，以及被动运行状况检查。

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

Mixer

Istio的Mixer组件提供策略控制和遥测收集功能，将Istio的其余部分与各个后端基础设施后端的实现细节隔离开来。Mixer是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。代理提取请求级属性，发送到Mixer进行评估。

Mixer中包括一个灵活的插件模型，使其能够接入到各种主机环境和后端基础设施，从这些细节中抽象出Envoy代理和Istio管理的服务。利用Mixer，你可以精细控制网格和后端基础设施后端之间的所有交互。

与必须节省内存的Sidecar代理不同，Mixer独立运行，因此它可以使用相当大的缓存和输出缓冲区，充当Sidecar的高度可伸缩且高度可用的二级缓存。

Mixer旨在为每个实例提供高可用性。它的本地缓存和缓冲区可以减少延迟时间，还有助于屏蔽后端基础设施后端故障，即使后端没有响应也是如此。

Citadel

Istio Citadel安全功能提供强大的身份验证功能、强大的策略、透明的TLS加密以及用于保护服务和数据的身份验证、授权和审计（AAA）工具，Envoy可以终止或向网格中的服务发起TLS流量。为此，Citadel需要支持创建、签署和轮换证书。Istio Citadel提供特定于应用程序的证书，可用于建立双向TLS以保护服务之间的流量。

Istio Citadel架构

借助Istio Citadel，确保只能从经过严格身份验证和授权的客户端访问包含敏感数据的服务。Citadel通过内置身份和凭证管理提供了强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。Istio的配置策略在服务器端配置平台身份验证，但不在客户端强制实施该策略，同时允许你指定服务的身份验证要求。Istio的密钥管理系统可自动生成、分发、轮换与撤销密钥和证书。

Istio RBAC为Istio网格中的服务提供命名空间级别、服务级别和方法级别的访问权限控制，包括易于使用的基于角色的语义、服务到服务和最终用户到服务的授权，并在角色和角色绑定方面提供灵活的自定义属性支持。

Istio可以增强微服务及其通信（包括服务到服务和最终用户到服务的通信）的安全性，且不需要更改服务代码。它为每个服务提供基于角色的强大身份机制，以实现跨集群、跨云端的交互操作。

Galley

Galley用于验证用户编写的Istio API配置。随着时间的推移，Galley将接管Istio获取配置、处理和分配组件的顶级责任。它负责将其他的Istio组件与从底层平台（例如Kubernetes）获取用户配置的细节中隔离开来。

总而言之，通过Pilot，Istio可在部署规模逐步扩大的过程中帮助你简化流量管理。通过Mixer，借助强健且易于使用的监控功能，能够快速有效地检测和修复问题。通过Citadel，减轻安全负担，让开发者可以专注于其他关键任务。

Istio的架构设计中有几个关键目标，这些目标对于系统应对大规模流量和高性能的服务处理至关重要。

• 最大化透明度：要采用Istio，应该让运维和开发人员只需付出很少的代价就可以从中获得实际价值。为此，Istio将自身自动注入到服务间所有的网络路径中。Istio使用Envoy代理来捕获流量，并且在可能的情况下自动对网络层进行编程，以便通过这些代理路由流量，而无需对已部署的应用程序代码进行太多的更改，甚至不需要任何更改。在Kubernetes中，Envoy代理被注入到pod中，通过iptables规则来捕获流量。一旦注入Envoy代理到pod中并且修改路由规则，Istio就能够调节所有流量。这个原则也适用于性能。当将Istio用于部署时，运维人员可以发现，为提供这些功能而增加的资源开销是很小的。所有组件和API在设计时都必须考虑性能和规模。

• 可扩展性：随着运维人员和开发人员越来越依赖Istio提供的功能，系统必然和他们的需求一起成长。在我们继续添加新功能的同时，最需要的是能够扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外，它允许扩展词汇表，以允许基于网格生成的新信号来强制执行策略。

• 可移植性：使用Istio的生态系统在很多方面都有所不同。Istio必须能够以最少的代价运行在任何云或本地环境中。将基于Istio的服务移植到新环境应该是轻而易举的，而使用Istio将一个服务同时部署到多个环境中也是可行的，例如可以在混合云上部署以实现冗余灾备。

• 策略一致性：策略应用于服务之间的API调用，可以很好地控制网格行为。但对于无需在API级别表达的资源来说，对资源应用策略也同样重要。例如，将配额应用到机器学习训练任务消耗的CPU数量上，比将配额应用到启动这个工作的调用上更为有用。因此，Istio将策略系统维护为具有自己的API的独特服务，而不是将其放到代理中，这允许服务根据需要直接与其集成。

剖析Istio数据平面

当介绍服务网格的概念时，提到了服务代理的概念以及如何使用代理构建一个服务网格，以调节和控制微服务之间的所有网络通信。Istio使用Envoy代理作为默认的开箱即用服务代理，这些Envoy代理与参与服务网格的所有应用程序实例一起运行，但不在同一个容器进程中，形成了服务网格的数据平面。只要应用程序想要与其他服务通信，就会通过服务代理Envoy进行。由此可见，Envoy代理是数据平面和整个服务网格架构中的关键组成部分。

Envoy代理

Envoy最初是由Lyft开发的，用于解决构建分布式系统时出现的一些复杂的网络问题。它于2016年9月作为开源项目提供，一年后加入了云原生计算基金会（CNCF）。Envoy是用C++语言实现的，具有很高的性能，更重要的是，它在高负载运行时也非常稳定和可靠。网络对应用程序来说应该是透明的，当网络和应用程序出现问题时，应该很容易确定问题的根源。正是基于这样的一种设计理念，将Envoy设计为一个面向服务架构的七层代理和通信总线。

为了更好地理解Envoy，我们需要先搞清楚相关的几个基本术语：

• 进程外（Out of Process）架构：Envoy是一个独立进程，Envoy之间形成一个透明的通信网格，每个应用程序发送消息到本地主机或从本地主机接收消息，但无需关心网络拓扑。

• 单进程多线程模型：Envoy使用了单进程多线程的架构模型。一个主线程管理各种琐碎的任务，而一些工作子线程则负责执行监听、过滤和转发功能。

• 下游（Downstream）：连接到Envoy并发送请求、接收响应的主机叫下游主机，也就是说下游主机代表的是发送请求的主机。

• 上游（Upstream）：与下游相对，接收请求的主机叫上游主机。

• 监听器（Listener）：监听器是命名网络地址，包括端口、unix domain socket等，可以被下游主机连接。Envoy暴露一个或者多个监听器给下游主机连接。每个监听器都独立配置一些网络级别（即三层或四层）的过滤器。当监听器接收到新连接时，配置好的本地过滤器将被实例化，并开始处理后续事件。一般来说监听器架构用于执行绝大多数不同的代理任务，例如限速、TLS客户端认证、HTTP连接管理、MongoDB sniff?ing、原始TCP代理等。

• 集群（Cluster）：集群是指Envoy连接的一组逻辑相同的上游主机。

• xDS协议：在Envoy中xDS协议代表的是多个发现服务协议，包括集群发现服务（CDS，Cluster Discovery Service）、监听器发现服务（LDS，Listener Discovery Service）、路由发现服务（RDS，Route Discovery Service）、端点发现服务（EDS，Endpoint Discovery Service），以及密钥发现服务（SDS，Secret Discovery Service）。

Envoy代理

Envoy代理有许多功能可用于服务间通信，例如，暴露一个或者多个监听器给下游主机连接，通过端口暴露给外部的应用程序；通过定义路由规则处理监听器中传输的流量，并将该流量定向到目标集群，等等。后续章节会进一步分析这几个发现服务在Istio中的角色和作用。

在了解了Envoy的术语之后，你可能想尽快知道Envoy到底起到了什么作用？

首先，Envoy是一种代理，在网络体系架构中扮演着中介的角色，可以为网络中的流量管理添加额外的功能，包括提供安全性、隐私保护或策略等。在服务间调用的场景中，代理可以为客户端隐藏服务后端的拓扑细节，简化交互的复杂性，并保护后端服务不会过载。例如，后端服务实际上是运行的一组相同实例，每个实例能够处理一定量的负载。

其次，Envoy中的集群（Cluster）本质上是指Envoy连接到的逻辑上相同的一组上游主机。那么客户端如何知道在与后端服务交互时要使用哪个实例或IP地址？Envoy作为代理起到了路由选择的作用，通过服务发现（SDS，Service Discovery Service），Envoy代理发现集群中的所有成员，然后通过主动健康检查来确定集群成员的健康状态，并根据健康状态，通过负载均衡策略决定将请求路由到哪个集群成员。而在Envoy代理处理跨服务实例的负载均衡过程中，客户端不需要知道实际部署的任何细节。

Envoy的启动配置

Envoy目前提供了两个版本的API，即v1和v2，从Envoy 1.5.0起就有v2 API了，为了能够让用户顺利地向v2版本API迁移，Envoy启动的时候设置了一个参数--v2-conf?ig-only。通过这个参数，可以明确指定Envoy使用v2 API的协议。幸运的是，v2 API是v1的一个超集，兼容v1的API。在当前的Istio 1.0之后的版本中，明确指定了其支持v2的API。通过查看使用Envoy作为Sidecar代理的容器启动命令，可以看到如下类似的启动参数，其中指定了参数--v2-conf?ig-only：

$ /usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster ratings --service-node sidecar~172.33.14.2~ratings-v1-8558d4458d-ld8x9.default~default.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only

其中，参数-c表示的是基于版本v2的引导配置文件的路径，格式为JSON，也支持其他格式，如YAML、Proto3等。它会首先作为版本v2的引导配置文件进行解析，若解析失败，会根据[--v2-conf?ig-only]选项决定是否作为版本v1的JSON配置文件进行解析。其他参数解释如下，以便读者及时理解Envoy代理启动时的配置信息：

• restart-epoch表示热重启周期，对于第一次启动默认为0，每次热重启后都应该增加它。

• service-cluster定义Envoy运行的本地服务集群名称。

• service-node定义Envoy运行的本地服务节点名称。

• drain-time-s表示热重启期间Envoy将耗尽连接的时间（秒），默认为600秒（10分钟）。通常耗尽时间应小于通过--parent-shutdown-time-s选项设置的父进程关闭时间。

• parent-shutdown-time-s表示Envoy在热重启时关闭父进程之前等待的时间（秒）。

• max-obj-name-len描述的是集群cluster、路由配置route_conf?ig以及监听器listener中名称字段的最大长度，以字节为单位。此选项通常用于自动生成集群名称的场景，通常会超过60个字符的内部限制。默认为60。

Envoy的启动配置文件分为两种方式：静态配置和动态配置。具体表现为：

• 静态配置是将所有信息都放在配置文件中，启动的时候直接加载。

• 动态配置需要提供一个Envoy的服务端，用于动态生成Envoy需要的服务发现接口，也就是通常说的xDS，通过发现服务来动态调整配置信息，Istio实现了v2的xDS API。

Envoy静态与动态配置

Envoy是由JSON或YAML格式的配置文件驱动的智能代理，对于已经熟悉Envoy或Envoy配置的用户来说，相信应该已经知道了Envoy的配置也有不同的版本。初始版本v1是Envoy启动时配置Envoy的原始方式。此版本已被弃用，以支持Envoy配置的v2版本。Envoy的参考文档（https://www.envoyproxy.io/docs）还提供了明确区分v1和v2的文档。本书中将只关注v2配置，因为它是最新的版本，也是Istio使用的版本。

Envoy版本v2的配置API建立在gRPC之上，v2 API的一个重要特性是可以在调用API时利用流功能来减少Envoy代理汇聚配置所需的时间。实际上，这也消除了轮询API的弊端，允许服务器将更新推送到Envoy代理，而不是定期轮询代理。

Envoy的架构使得使用不同类型的配置管理方法成为可能。部署中采用的方法将取决于实现者的需求。简单部署可以通过全静态配置来实现，更复杂的部署可以递增地添加更复杂的动态配置。主要分为以下几种情况：

• 全静态：在全静态配置中，实现者提供一组监听器和过滤器链、集群和可选的HTTP路由配置。动态主机发现仅能通过基于DNS的服务发现。配置重载必须通过内置的热重启机制进行。

• 仅SDS/EDS：在静态配置之上，Envoy可以通过该机制发现上游集群中的成员。

• SDS/EDS和CDS：Envoy可以通过该机制发现使用的上游集群。

• SDS/EDS、CDS和RDS：RDS可以在运行时发现用于HTTP连接管理器过滤器的整个路由配置。

• SDS/EDS、CDS、RDS和LDS：LDS可以在运行时发现整个监听器。这包括所有的过滤器堆栈，包括带有内嵌到RDS的应用的HTTP过滤器。

静态配置

我们可以使用Envoy的配置文件指定监听器、路由规则和集群。如下示例提供了一个非常简单的Envoy配置：

static_resources:
  listeners:
  - name: httpbin-demo
    address:
      socket_address: { address: 0.0.0.0, port_value: 15001 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: egress_http
          route_config:
            name: httpbin_local_route
            virtual_hosts:
            - name: httpbin_local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route:
                  auto_host_rewrite: true
                  cluster: httpbin_service
          http_filters:
          - name: envoy.router
  clusters:
    - name: httpbin_service
      connect_timeout: 5s
      type: LOGICAL_DNS
      # Comment out the following line to test on v6 networks
      dns_lookup_family: V4_ONLY
      lb_policy: ROUND_ROBIN
      hosts: [{ socket_address: { address: httpbin, port_value: 8000 }}]

在这个简单的Envoy配置文件中，我们声明了一个监听器，它在端口15001上打开一个套接字并为其附加一个过滤器链。过滤器http_connection_manager在Envoy配置中使用路由指令（在此示例中看到的简单路由指令是匹配所有虚拟主机的通配符），并将所有流量路由到httpbin_service集群。配置的最后一部分定义了httpbin_service集群的连接属性。在此示例中，我们指定端点服务发现的类型为LOGICAL_DNS、与上游httpbin服务通信时的负载均衡算法为ROUND_ROBIN。

这是一个简单的配置文件，用于创建监听器传入的流量，并将所有流量路由到httpbin集群。它还指定要使用的负载均衡算法的设置以及要使用的连接超时配置。

你会注意到很多配置是明确指定的，例如指定了哪些监听器，路由规则是什么，我们可以路由到哪些集群等。这是完全静态配置文件的示例。

有关这些参数更多信息的解释，请参阅Envoy的文档（http://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns）。

在前面的部分中，我们指出Envoy能够动态配置其各种设置。下面将介绍Envoy的动态配置以及Envoy如何使用xDS API进行动态配置。

动态配置

Envoy可以利用一组API进行配置更新，而无需任何停机或重启。Envoy只需要一个简单的引导配置文件，该配置文件将配置指向正确的发现服务API，其余动态配置。Envoy进行动态配置的API通常统称为xDS服务，具体包括如下：

• 监听器发现服务（LDS）：一种允许Envoy查询整个监听器的机制，通过调用该API可以动态添加、修改或删除已知监听器；每个监听器都必须具有唯一的名称。如果未提供名称，Envoy将创建一个UUID。

• 路由发现服务（RDS）：Envoy动态获取路由配置的机制，路由配置包括HTTP标头修改、虚拟主机以及每个虚拟主机中包含的单个路由规则。每个HTTP连接管理器都可以通过API独立地获取自身的路由配置。RDS配置隶属于监听器发现服务LDS的一部分，是LDS的一个子集，用于指定何时应使用静态和动态配置，以及指定使用哪个路由。

• 集群发现服务（CDS）：一个可选的API，Envoy将调用该API来动态获取集群管理成员。Envoy还将根据API响应协调集群管理，根据需要添加、修改或删除已知的集群。在Envoy配置中静态定义的任何集群都不能通过CDS API进行修改或删除。

• 端点发现服务（EDS）：一种允许Envoy获取集群成员的机制，基于gRPC或RESTJSON的API，它是CDS的一个子集；集群成员在Envoy术语中称为端点（Endpoint）。对于每个集群，Envoy从发现服务获取端点。EDS是首选的服务发现机制。

• 密钥发现服务（SDS）：用于分发证书的API；SDS最重要的好处是简化证书管理。如果没有此功能，在Kubernetes部署中，必须将证书创建为密钥并挂载到Envoy代理容器中。如果证书过期，则需要更新密钥并且需要重新部署代理容器。使用密钥发现服务SDS，那么SDS服务器会将证书推送到所有Envoy实例。如果证书过期，服务器只需将新证书推送到Envoy实例，Envoy将立即使用新证书而无需重新部署。

• 聚合发现服务（ADS）：上述其他API的所有更改的序列化流；你可以使用此单个API按顺序获取所有更改；ADS并不是一个实际意义上的xDS，它提供了一个汇聚的功能，在需要多个同步xDS访问的时候，ADS可以在一个流中完成。

配置可以使用上述服务中的一个或其中几个的组合，不必全部使用它们。需要注意的一点是，Envoy的xDS API是建立在最终一致性的前提下，正确的配置最终会收敛。例如，Envoy最终可能会使用新路由获取RDS的更新，该路由将流量路由到尚未在CDS中更新的集群。这意味着，路由可能会引入路由错误，直到更新CDS。Envoy引入了聚合发现服务ADS来解决这种问题，而Istio实现了聚合发现服务ADS，并使用ADS进行代理配置的更改。

例如，Envoy代理要动态发现监听器，可以使用如下配置：

dynamic_resources:
  lds_config:
    api_config_source:
      api_type: GRPC
      grpc_services:
        - envoy_grpc:
            cluster_name: xds_cluster
clusters:
- name: xds_cluster
  connect_timeout: 0.25s
  type: STATIC
  lb_policy: ROUND_ROBIN
  http2_protocol_options: {}
  hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

通过上面的配置，我们不需要在配置文件中显式配置每个监听器。我们告诉Envoy使用LDS API在运行时发现正确的监听器配置值。但是，我们需要明确配置一个集群，这个集群就是LDS API所在的位置，也就是该示例中定义的集群xds_cluster。

在静态配置的基础上，比较直观地表示出各个发现服务所提供的信息。

xDS服务信息

在静态配置的基础上，比较直观地表示出各个发现服务所提供的信息。

福利时间

本文摘自于《Istio服务网格技术解析与实践》，该书由阿里云高级技术专家王夕宁撰写，详细介绍Istio的基本原理与开发实战，包含大量精选案例和参考代码可以下载，可快速入门Istio开发，适合所有对微服务和云原生感兴趣的读者，推荐大家对本书进行深入的阅读。本次联合机械工业出版社华章公司为大家带来10本书作为福利。在文末留言中写下对Istio的认识，截止4月21日12点前，评论点赞数前10名的读者将获以下任意图书1本。没中奖的读者也可以点击下面链接购买，目前京东有活动，满100减50。

基于Kubernetes的DevOps实战培训

基于Kubernetes的DevOps实战培训将于2020年5月15日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：容器特性、镜像、网络；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的数据库、运行时、网络、插件已经落地经验；微服务架构、组件、监控方案等，点击下方图片或者阅读原文链接查看详情。