Istio学习笔记

术语服务网格（Service Mesh）用于描述微服务之间的网络，以及通过此网络进行的服务之间的交互。随着服务数量和复杂度的增加，服务网格将变的难以理解和管理。

对服务网格的需求包括：服务发现、负载均衡、故障恢复、指标和监控，以及A/B测试、金丝雀发布、限速、访问控制、端对端身份验证等。

使用云平台给DevOps团队带来了额外的约束，为了Portability开发人员通常需要使用微服务架构，运维人员则需要管理非常多数量的服务。Istio能够连接、保护、控制、观察这些微服务。

Istio是运行于分布式应用程序之上的透明（无代码入侵）服务网格，它同时也是一个平台，提供集成到其它日志、监控、策略系统的接口。

Istio的实现原理是，为每个微服务部署一个Sidecar，代理微服务之间的所有网络通信。在此基础上你可以通过Istio的控制平面实现：

1. 针对HTTP、gRPC、WebSocket、TCP流量的负载均衡
2. 细粒度的流量控制行为，包括路由、重试、故障转移、故障注入（fault injection）
3. 可拔插的策略层+配置API，实现访问控制、限速、配额
4. 自动收集指标、日志，跟踪集群内所有流量，包括Ingress/Egress
5. 基于强身份认证和授权来保护服务之间的通信

使用Istio你可以很容易的通过配置，对流量和API调用进行控制。服务级别的可配置属性包括断路器（circuit breakers）、超时、重试。

Istio支持基于流量百分比切分的A/B测试、金丝雀滚动发布、分阶段滚动发布。

可以提供安全信道，管理身份验证和授权，加密通信流量。

联用K8S的网络策略可以获得更多益处，例如保护Pod-to-Pod之间的通信。

Istio强壮的跟踪、监控、日志能力，让服务网格内部结构更容易观察 —— 一个服务的性能对上下游的影响可以直观的展现在仪表盘上。

Istio的Mixer组件——通用的策略和监控（Telemetry）中心（Hub）负责策略控制、指标收集。Mixer提供基础设施后端的隔离层，Istio的其它部分不需要关注后端细节。

Istio当前支持：

1. Kubernetes上的Service
2. 通过Consul注册的服务
3. 在独立虚拟机上运行的服务

从整体上看，Istio的服务网格由数据平面、控制平面两部分组成：

1. 数据平面由一系列作为Sidecar部署的智能代理（Envoy）构成。这些代理联合Mixer，中继、控制所有微服务之间的网络通信
2. 控制平面负责管理、配置智能代理，实现流量路由，配置Mixers来应用策略、收集指标

架构图：

Istio使用一个扩展过的Envoy版本。Envoy是基于C++开发的高性能代理，Istio使用它的以下特性：

1. 动态服务发现
2. 负载均衡
3. TLS termination —— 可将后端的HTTP服务包装为HTTPS
4. HTTP/2和gRPC代理
5. 断路器
6. 健康检查
7. 分阶段（基于流量百分比）发布
8. 故障注入
9. 丰富的监控指标

Envoy在和目标服务的相同Pod中，以Sidecar形式部署。

一个平台无关的组件：

1. 为服务网格Apply访问控制策略
2. 从Envoy和其它服务中收集指标
3. Envoy收集的请求级别的属性，被发送到Mixer进行分析

Mixer提供了一个灵活的插件模型，让Istio能够灵活的和多种宿主机环境、基础设施后端进行对接。

该组件是Istio的控制器，它会监控各种规则、策略的存储，一旦配置文件发生变化，就会提取、处理，并同步给Envoy。

1. 为Envoy提供服务发现
2. 为智能路由（AB测试、金丝雀部署……）提供流量管理能力
3. 提供弹性（Resiliency）——超时、重试、断路器等
4. 分发身份验证策略给Envoy

Pilot将高级别的路由规则转换为Envoy理解的配置信息，并在运行时将这些配置传播到Sidecars。

Pilot将平台相关的服务发现机制抽象为标准的（Envoy data plane API）格式，这让Istio可以在K8S、Consul、Nomad等多种环境下运行。

提供服务-服务、终端用户的身份验证功能，可以加密服务网格中的流量。

然后把istio/bin目录加入PATH环境变量。

Istio可以自动为Pod注入Sidecar，它基于Webhook实现此功能。

你可以执行下面的命令，确认MutatingAdmissionWebhook、ValidatingAdmissionWebhook这两种Admission controllers是否默认启用：

如果没有启用，则需要修改API Server的命令行参数。

此外，你还需要检查admissionregistration API是否启用：

和手工注入不同，自动注入是发生在Pod级别的。在Deployment上看不到任何变化，你需要直接检查Pod才能看到注入的Envoy。 

Istio的Chart定义在install/kubernetes/helm/instio目录下 。默认情况下，Istio会以Sub chart的方式安装很多组件：

如需禁用，在values.yaml中修改对应配置项即可。

最小化安装时，仅仅安装pilot组件。 

Istio提供了一个示例应用程序Bookinfo，我可以部署该应用 ，并为其配置服务网格，以学习Istio。该应用程序能够显示书籍的基本信息，包括ISBN、页数，还能显示书籍的评论信息。

Bookinfo由4个独立的微服务组成：

1. productpage，调用details、reviews渲染页面
2. details，提供书籍基本信息
3. reviews，提供书评信息，调用ratings。该服务有v1、v2、v3三个版本
4. ratings，提供书籍的评级信息

下图显示了没有部署Istio之前，Bookinfo的端对端架构：

下图显示受到Istio服务网格管理的Bookinfo的架构：

如果启用了自动化的Sidecar注入，你需要在安装到的命名空间上打标签：

打上此标签后，default命名空间中创建的新Pod，自动会有一个名为stio-proxy的容器，它运行istio/proxyv2镜像。 

如果没有启用自动化的Sidecar注入，你需要执行：

 

Istio的流量管理模型，从根本上将流量（traffic flow）和基础设施扩容（infrastructure scaling）进行了解耦。通过Pilot，你可以通过更细致的规则来说明流量如何流动，而不是简单的指定哪个VM/Pod来接收流量。例如，你可以指定某个服务的5%的流量发往金丝雀版本（不管金丝雀的实例数量），或者指定根据请求内容来选择特定版本的服务：

将流量（traffic flow）和基础设施扩容解耦后，Istio可以在应用程序代码外部提供大量的流量管理特性，包括AB测试的请求路由、逐步发布、金丝雀发布，基于超时、重试、断路器的故障恢复，以及为了测试故障恢复策略而进行的故障注入（fault injection）。

流量管理的核心组件是Pilot，它管理、配置所有部署在服务网格中的Envoy代理实例，对Envoy的完整生命周期负责。Pilot除了可以配置路由规则、配置故障恢复特性之外，还维护网格中所有服务的规范（canonical）模型。Envoy就是基于此模型，通过自己的发现服务，找到网格中其它Envoy。

每个Envoy实例都基于从Pilot得到的信息、以及针对负载均衡池中的实例进行周期性的健康检查，来维护负载均衡信息。根据此负载均衡信息，Envoy能够在遵守路由规则的同时，智能的在目的实例之间分发请求。

规范模型是独立于底层平台的，和底层平台的对接由Pilot中的适配器负责，适配器调用底层平台的API（例如K8S适配器实现了必要的控制器来Watch API Server，获取Pod、Ingress等资源的变动），并产生适当的规范模型。

Pilot启用了服务发现，路由表，以及对负载均衡池的动态更新。

使用Pilot的规则配置（Rule Configuration），可以制定高级别的流量管理规则。这些规则会被转换为低级别的配置信息，并分发给Envoy实例。

如上文所述，网格中服务的规范模型由Pilot维护。Istio还引入了服务版本的概念，用于对服务实例进行细粒度区分。服务版本既可以指服务API的版本（v1,v2），也可以指服务运行环境（stg,pdt）或任何其它属性。

在上图中，服务的客户端对服务的不同版本毫无感知。客户端仍然使用服务的IP或主机名来访问，只是Envoy在客户端-服务器之间拦截并转发了请求和响应。

Envoy根据你通过Pilot指定的路由规则，决定实际使用的服务版本。这让应用程序代码和被依赖服务之间实现解耦，可分别独立演化。在路由规则中，你可以指定让Envoy依据源/目标的消息头、Tag来判定服务版本。

Istio假设服务网格的所有出入流量都经由Envoy代理转发。通过这种前置代理可以实现面向用户的服务，包括AB测试、金丝雀部署。在访问外部服务时，Envoy可以实现必要的故障恢复特性，包括超时、重试，并获取外部服务的性能指标。

Istio能够在网格中服务实例之间进行负载均衡。 

Istio假设基础设置提供一个服务注册表，此表跟踪某个服务的VM/Pod集。此服务注册表应当负责新实例的加入、不健康实例的移除。

Istio从服务注册表（service registry）中读取服务的信息，并生成平台无关的服务发现接口。Envoy执行服务发现，并动态的更新其负载均衡池。

网格中的服务，利用DNS名称来相互访问。所有针对某个服务的流量，都会在出站前经由Envoy进行重新路由。负载均衡池是决定路由到哪个节点的关键因素。Envoy支持多种负载均衡算法，但是Istio目前仅仅允许：轮询、随机、带权重的最少请求。

Envoy还会周期性的检查负载均衡池中实例的健康情况，这种检查从外部（准确的说是服务消费者）发出的，而不是像K8S Pod健康检查那样，在Pod本地执行。

判断实例是否健康时，Envoy遵循一种断路器模式（circuit breaker pattern），此模式下调用实例API的故障率决定了实例是否健康。当健康检查连续失败指定的次数后，实例被移除负载均衡池；当被移除的实例连续成功指定次数后，它又回到负载均衡池。

如果实例以503代码响应健康检查请求，则它会立即被调用者移出负载均衡池。

Envoy提供了一系列开箱即用的错误恢复机制：

1. 超时
2. 有限次数的重试，支持可变的重试延迟（jitter）
3. 限制针对上游服务的并发连接数、并发请求数
4. 主动健康检查——针对负载均衡池中所有成员进行健康检查，并移除不健康实例，移回健康实例
5. 可精细控制的断路器（被动健康检查） ，同样针对负载均衡池中的每个实例

所有这些特性，都可以在运行时，利用Istio的流量管理规则动态配置。

联用主动、被动健康检查，可以更大程度上降低访问不健康实例的几率。联用底层基础设施的健康检查机制，不健康实例可以很快的被剔除。 

流量管理规则可以为每个服务/版本来配置默认的故障恢复特性。

用于辅助测试端对端的故障恢复能力。

Istio支持多种具体的协议，并向其注入错误信息。而不是粗暴的杀死Pod，或者在TCP层延迟/污染网络包。你可以在应用层注入更加有意义的错误，例如HTTP的状态码。

Istio支持对特定请求进行错误注入，或者指定多少百分比的请求被错误注入。

可以注入的错误有两类：

1. 延迟：模拟网络延迟和上游服务过载
2. 中止：模拟上游服务错误，通常使用HTTP错误码、TCP连接错误的方式

在典型的Kubernetes环境下，Ingress控制器读取Ingress资源，提供外部访问K8S集群的入口。

而使用Istio时，Ingress资源的地位由Gateway + VirtualServices取代。在集群内部组件相互交互时，不需要配置Gateway资源。

使用Istio Gateway时的客户端访问时序如下：

1. 客户端发起针对负载均衡器的请求
2. 负载均衡器将请求转发给集群的IngressGateway Service，该服务可以部署为NodePort，它的后端是一个Deployment
3. IngressGateway根据Gateway资源、VirtualService资源的配置信息，将请求路由给K8S的Service
   1. Gateway提供端口、协议、数字证书信息
   2. VirtualService到K8S Service的路由信息
4. K8S Service将请求路由给Pod

该时序如下图所示，注意IngressGateway的Sidecar负责转发客户端请求：

 

每当你创建/修改Gateway、VirtualService资源，Pilot会监测到并将其转换为Envoy配置，然后发送给相关的Sidecar，包括运行在IngressGateway Pod中的Envoy。

 

Istio使用一个简单的配置模型来描述API调用/TCP流量如果在服务网格中流动。使用此配置模型，你可以：

1. 配置服务级别的属性，例如断路器、超时、重试
2. 配置通用的持续交付（CD）任务，例如金丝雀发布（Canary rollout）、A/B测试、阶段性部署（Staged rollout）——基于百分比的流量分配 

配置模型映射为K8S的资源，包括VirtualService、DestinationRule、ServiceEntry、Gateway四种。

在K8S中你可以用kubectl来配置这些资源，它们都是CR。

定义服务的请求如何在服务网格中路由。虚拟服务能够将请求路由给服务的不同版本，甚至是完全不同的服务。

下面的示例，将针对review服务的所有请求都发送给v1版本：

默认情况下HTTP请求的超时为15秒，你可以覆盖此默认值。重试也类似：

请求也可以覆盖超时、重试配置，只需要提供特殊的请求头x-envoy-upstream-rq-timeout-ms、x-envoy-max-retries即可。 

你可以为http进行故障注入，要么是delay，要么是abort。

下面的例子，为ratings服务的v1版本10%的请求引入5秒的延迟：

下面的例子，则为10%的请求引发400错误：

delay和abort是可以联合使用的：

规则可以仅仅针对满足特定条件的请求。

可以限定请求者的标签，在K8S环境下即Pod的Label：

也可以限定HTTP请求头： 

还可以限定请求URL路径： 

多个条件可以进行逻辑与/或。在单个match元素中声明多个条件，则为AND：

在多个match元素中分别声明，则为OR：

如果对于相同的目标（host + subset），配置了两个或更多的规则（http子元素），那么第一个（配置文件最前面）匹配的规则优先级最高。 

在VirtualService定义了路由发生后，DestinationRule进一步应用一系列的策略到请求上。这类规则可能声明断路器、负载均衡器的属性，执行TLS配置，最基本的是定义可寻址的服务子集。DestinationRule针对某个特定的真实服务（host）。

下面的示例，声明了服务子集：

可以针对所有子集配置：

也可以针对特定子集：

可以根据一系列条件进行断路，例如根据并发连接数： 

用于访问位于服务网格外部的服务，将其作为服务条目添加到Istio内部管理的服务注册表（service registry）中。

下面的例子，允许Envoy代理针对gmem.cc的HTTP请求：

ServiceEntry可以和VirtualService一起工作，作为VirtualService的host。

配置在网格的边缘，用于外部访问服务网格（Ingress），为TCP/HTTP流量提供负载均衡。 

和Kubernetes的Ingress不同，Istio网关仅仅在L4-L6上配置，而不使用L7。 你可以把Gateway绑定到VirtualService，进而使用Istio标准的方式来管理HTTP请求和TCP流量。

下面的例子，允许网格外部发送针对gmem.cc的HTTPS请求：

必须把上述网关绑定到VirtualService，它才能工作：

为集群内的TCP服务建立入口Gateway时，hosts字段被忽略，你可以设置为通配符以匹配任何VirtualService：

 

Istio提供了一个灵活的模型，用以收集网格中服务的各种指标（telemetry）。指标收集工作主要由Mixer负责。

从逻辑上说，每次：

1. 请求发起前，消费者的Envoy都会调用Mixer，执行前提条件检查
2. 每次请求处理完成后，都会调用Mixer，发送监控指标

Sidecar在本地具有缓存，大部分前提条件检查都在本地完成。此外监控指标也具有本地缓冲，不会频繁的发送给Mixer。

Mixer是高度模块化的、可扩展的组件。通过适配器，它支持多种日志记录、配额、授权、监控后端，并将这些策略、监控后端和Istio的其它部分解耦。

适配器封装了Mixer和外部基础设施后端（例如Prometheus）交互的逻辑，每个适配器都需要特定的配置参数才能工作，例如logging适配器需要知道后端服务的IP和端口。

具体使用哪些适配器，也就是启用哪些后端，通过配置文件来指定。

Mixer是非常高可用的组件，并且，它能在整体上提供服务网格的可用性、降低延迟：

1. 无状态，Mixer没有任何持久化状态
2. 高度健壮，每个实例都具有99.999%的可用性
3. 缓存和缓冲，Mixer可以在本地累积大量的临时数据

在每个Pod上都要部署的Sidecar，必须尽可能占用少的内存。这意味着Sidecar的本地缓存、缓冲不能太大。Mixer可以作为Sidercar的高可用二级缓存使用。此外，Mixer的缓冲可以在后端基础设施（例如Prometheus）失败的情况下，继续运行（接受Envoy发来的指标），因而提高了可用性。

Mixer的缓存/缓冲也减少了对后端基础设施的访问频率，甚至减少访问数据量，因为它可以在本地进行数据聚合。

属性（Attributes）是Istio策略/监控功能的关键概念。属性是一小块数据，描述某个请求的自身的特征（property）或请求所处的环境，例如一个属性可能表示请求的长度、响应的状态码、请求来自的IP地址。每个属性都具有名称和取值。

Mixer本质上就是属性处理程序。Envoy为每个请求调用Mixer，并且发送请求的属性。Mixer依据请求属性，以及Mixer自己的配置，对若干基础设施后端发起调用：

Istio的策略和监控特性基于一个公共的模型来配置，你需要配置三类资源：

1. Handlers：决定使用哪些适配器，这些适配器如何运作
2. Instances：定义如何把请求属性映射为适配器的输入。Instance代表一个或多个适配器需要处理的数据块
3. Rules：决定何时调用适配器，传递什么instance给它

每种适配器都有自己的CRD，下面的例子是listchecker。该适配器检查输入参数是否在列表中，如果是，适配器返回true：

下面的例子是prometheus，该适配器消费指标并且进行预聚合：

每种Instance都有自己的CRD，用于将请求属性映射为适配器的输入。下面的例子为prometheus适配器提供输入：

指定在何时调用handler，传递什么instance给它。下面的规则表示，如果被访问的服务是service1，且请求头x-user为user1，则将名为requestduration的metric传递给Prometheus：

将单体应用分解为微服务可以获得很多好处，例如更灵活、更容易扩容、更容易重用。但是，微服务也引入额外的安全需求：

1. 为了防止中间人攻击，需要进行流量加密。安全内网环境下可以忽略
2. 为了提供灵活的访问控制，需要双向TLS认证，以及细粒度的访问控制策略
3. 为了审计谁在什么时候访问了什么，需要审计工具 

Istio的安全特性能够满足以上需求。Istio安全支持：

1. 强身份验证（strong identity）
2. 强大的策略配置
3. 透明的TLS传输
4. AAA —— 认证、授权、审计

和Istio安全有关的组件包括：

1. Citadel，负责密钥、证书管理
2. Sidecar和周边代理（perimeter proxies，运行在Ingress/Egress的代理 ），实现客户端 - 服务之间的安全通信
3. Pilot，分发身份验证策略、安全命名信息给代理
4. Mixer，管理授权和审计

身份标识（Identity）是任何安全基础设施的基础。两个服务开始交互前，需要相互交换自己身份的凭证信息，以进行双向身份验证：

1. 客户端利用安全命名（secure naming information）信息检查服务器的身份，以确保它是服务的授权提供者（Runner）
2. 在服务器端：
   1. 利用授权策略（authorization policies）来决定是否接受客户访问
   2. 记录审计日志 —— 谁在何时访问了什么
   3. 根据其使用的服务，对客户端计费
   4. 拒绝没付费的客户端的访问请求

在不同平台上，Istio使用不同方式来实现服务身份（Service identities）：

1. 在K8S上使用ServiceAccount
2. 在GKE/GCE上使用GCP服务账号
3. 在AWS上使用AWS IAM用户/角色账号
4. 裸机器，可以使用用户账号、自定义服务账号、服务名称、Istio服务账号，等等

Istio的PKI建立在Citadel之上，能够安全的为任何工作负载提供代表身份的数字证书（X.509，SPIFFE格式），并且支持密钥和证书的自动轮换（更新）。

在K8S场景下：

1. Citadel会监控API Server，为所有Service Account创建SPIFFE格式的密钥对，并且存储为K8S的Sercret
2. 当创建Pod后，Pod使用的Service Account的密钥对会挂载为卷
3. Citadel会监控证书的生命周期，并自动轮换，然后自动更新Secret，从而让Pod自动获得更新
4. Pilot会创建安全命名信息，此信息定义了什么Service Account能够运行什么服务。安全命名信息被传播给Envoy

Istio提供两种类型的身份验证：

1. 传输身份验证：即服务-服务身份验证。 认证直接的请求发起者的身份，Istio支持双向身份验证
2. 源（Origin）身份验证：即终端用户身份验证。验证最初发起请求的用户或者设备。Istio支持基于JSON Web Token（JWK）的请求级身份验证

通过配置服务的身份验证策略（authentication policies），可以为其启用身份验证功能。

通过服务消费者、提供者的Envoy代理，Istio实现了服务-服务通信的安全隧道。请求的处理步骤如下：

1. 将消费者的请求重新路由到本地的Sidecar —— Envoy
2. 消费者Envoy向提供者的Envoy发起双向认证的TLS握手。在握手期间，消费者Envoy也会对提供者进行安全命名检查，看看它的Service Account是否有权提供目标服务
3. 两个Envoy建立TLS连接，流量通过此连接转发
4. 提供者确认消费者有权限访问后，将流量转发给本地的主容器

安全命名信息是一个多对多映射，从编码在数字证书中的服务的身份标识（K8S中为Service Account），到（被发现服务或DNS引用的）服务名称。从A到B的映射，其含义是A有资格运行B服务。

Pilot会监控K8S的API Server，取得Service Account + Pod等信息，生成安全命名信息，并安全的分发给Envoy。

Istio使用基于角色的权限控制（RBAC），允许命名空间级别、服务级别、HTTP方法级别的访问控制。Istio支持：

1. 基于角色的授权，简单易用
2. 服务-服务、终端用户-服务，两种访问控制
3. 高性能，授权直接在Envoy上发生

架构图如下：

这里的策略是针对针对服务提供者的：

使用mutual TLS时，要在客户端指定身份验证规则，需要在DestinationRule中配置TLSSettings。

你可以为整个服务网格设置默认的身份验证策略（不指定targets）：

或者为某个命名空间设置默认的身份验证策略：

身份验证策略所针对的服务，在targets字段中配置：

peers字段定义了服务-服务的身份验策略。0.7版本的Istio仅支持mTLS：

配置mode为PERMISSIVE，则mTLS是可选的，允许基于明文发起请求：

origins字段定义了终端用户的设法验证策略。目前仅仅支持JWT认证。

要启用访问控制，你需要配置CRD —— RbacConfig。这是一个全局的单例对象，名字必须为default：

定义一个角色，并声明该角色对哪些服务具有哪些访问权限。

ServiceRole包含一系列rules，也就是许可（permissions）：

除了限定命名空间 + 服务 + 动词 + 路径以外，你还可以提供额外的约束，例如限定请求头：

为用户、组、服务授予ServiceRole。示例：