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提供后端基础设施（例如K8S）的隔离层，Istio的其它部分不需要关注后端细节。

Istio当前支持：

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

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

1. 数据平面由一系列作为Sidecar部署的智能代理（Envoy）构成。这些代理联合Mixer，中继、控制所有微服务之间的网络通信。需要注意，还有一些Envoy是独立部署（而非Sidecar）的，用来实现K8S Ingress控制器、Istio的Ingress/Egress网关
2. 控制平面负责管理、配置智能代理，实现流量路由；配置Citadel实现TLS证书管理；配置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形式部署。少量的Istio组件的主进程就是Envoy，包括Ingress控制器、Ingress/Egress网关。

一个平台无关的组件：

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

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

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

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

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

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

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

部署服务网格带来了额外的性能损耗，下面是Istio组件的推荐资源配置：

1. 对于启用了访问日志（默认启用）的Sidecar，每1000请求/s可以配备1个vCPU，如果没有启用访问日志则配备0.5个vCPU
2. 节点上的Fluentd是资源消耗大户，它会捕获并上报日志，如果不关心可以排除Sidecar日志不上报
3. 在大部分情况下，Mixer Check有超过80%的缓存命中率，在此前提下，可以为Mixer的Pod每1000请求/s配备0.5个vCPU
4. 由于在通信两端都引入了Sidecar代理、并且需要上报Mixer，大概会引入10ms的延迟

任何控制平面组件都支持多实例部署，在K8S中可以考虑配置HPA。

考虑将Mixer的check、report功能分开部署。当前官方Chart已经分开，分别对应istio-policy、istio-telemetry两个Deployment。

术语	说明
Service	一个应用程序“行为单元”，它对应服务注册表（例如K8S的集群服务DNS）中的唯一的名称 服务具有0-N个网络端点（Endpoint），这些端点可以是Pod、容器、虚拟机
Service versions	也叫subsets，这是持续部署（CD）中的概念 在持续部署时，网格中可能运行着某个微服务的多种变体，这些变体的二进制代码不同，但是API版本不一定不同。这些变体代表了对某个服务的迭代性的改变，部署在不同的环境中
Source	访问当前服务的下游（downstream）客户端
Host	客户端连接到服务器时所使用的DNS名称
Destination	表示一个可寻址的服务，请求/连接在经过路由处理后，将发送到Destination

Istio的命令行配置工具，用于创建、查询、修改、删除Istio配置资源。

选项	说明
--context	使用的kubeconfig context，默认""
-i	Istio安装在的命名空间，默认istio-system
-c	使用的kubeconfig
--namespace	在哪个命名空间执行命令
--log_output_level	日志级别，格式为scope:level,scope:level...默认default:info scope取值：ads, default, model, rbac level取值：debug, info, warn, error, none

一组子命令，用于操控Istio的身份验证策略：

创建策略、规则：

获取策略、规则：

替换掉策略、规则：

删除策略、规则，命令格式：

示例：

注册一个服务实例（例如一个VM）到服务网格中：

注销虚拟服务实例，命令格式：

一组试验性命令，未来可能修改或删除。

子命令	说明
convert-ingress	尽最大努力的把Ingress资源转换为VirtualService，示例： Shell 1 2 kubectl -n devops get ingresses.extensions grafana --export -o yaml > /tmp/grafana.yaml istioctl experimental convert-ingress -f /tmp/grafana.yaml 输出的VirtualService总是以svc.cluster.local为集群DNS后缀，可能需要修改
metrics	打印一个或多个虚拟服务的统计指标，示例： Shell 1 2 3 4 5 6 7 # 列出所有虚拟服务 istioctl get virtualservice # 显示某个服务的指标 istioctl experimental metrics productpage #  工作负载名称  请求/秒       错误/秒     延迟百分比分布    WORKLOAD    TOTAL RPS    ERROR RPS  P50 LATENCY  P90 LATENCY  P99 LATENCY productpage        0.000        0.000           0s           0s           0s
rbac	检查是否有权限访问服务，格式： Shell 1 istioctl experimental rbac can METHOD SERVICE PATH [flags] 示例： Shell 1 2 3 4 # 用户alex是否有权访问rating服务的/v1/health路径 istioctl experimental rbac can -u alex GET rating /v1/health # 服务product-page是否有权以POST方法访问rating服务的dev版本的/data路径 istioctl experimental rbac can -s service=product-page POST rating /data -a version=dev

手工的将Envoy Sidecar注入到K8S的工作负载的定义文件中。定义文件中包含多种不支持注入的资源是安全的：

一组命令，用于Dump出Envoy代理的各方面的配置：

子命令	说明
bootstrap	获取Envoy实例的Boostrap信息： Shell 1 istioctl proxy-config bootstrap <pod-name> [flags]
cluster	获取Envoy实例的集群配置信息
listener	获取Envoy实例的listener配置信息
route	获取Envoy实例的路由配置信息

本节不做更细致的描述，具体参考运维-Dump出Envoy配置一节。

查询从Pilot最后一次发送到各Envoy的xDS同步的状态：

这是Istio的负载测试工具。

子命令	说明
load	执行负载测试
server	启动GRPC ping/http服务
grpcping	启动GRPC客户端
report	启动用于查看报告的UI服务器
redirect	启动仅执行重定向的服务器
curl	简单的调试一个URL，显示响应的详细信息

选项	说明
-H value	添加额外的请求头
-abort-on int	如果遇到目标HTTP状态码，立即终止运行。例如503或-1，表示套接字错误
-allow-initial-errors	允许预热期间的错误，且不终止运行
-c int	连接/Goroutine/线程的并发数，默认4
-compression	启用HTTP压缩
-http1.0	使用HTTP 1.0而非1.1
-k	不校验服务器端证书
-keepalive	传输层连接重用，默认true
-qps float	目标QPS，如果为0则不做任何休眠，尽可能提高QPS，默认8
-n int	运行指定的次数
-t duration	运行指定的时间，默认5s，指定为0则一直运行
-p string	统计的百分比值（即耗时N%百分比的请求的最大耗时值），默认 50,75,90,99,99.9
-timeout duration	HTTP连接/读取超时，默认15s
-user string	HTTP基本认证的凭证信息，格式user:pswd
-loglevel lv	日志级别，可以取值Warning、Error等

Mixer的命令行客户端。

用于执行前置条件检查、配额（quota allocations）。Mixer期望以一组Attributes为输入，它基于自己的配置来判断调用哪个适配器、如何传递参数，进而进行策略检查、配额。

选项	说明
--attributes	自动感知的属性列表，形式name1=value1,name2=value2...
--bool_attributes	布尔值属性的列表
--bytes_attributes	字节值属性的列表
--double_attributes	浮点数属性的列表
--duration_attributes	时间长度属性的列表
--int64_attributes	整数属性的列表
--string_attributes	字符串属性的列表
--stringmap_attributes	string:string映射类型的属性列表，形式name1=k1:v1;k2:v2,name2=k3:v3...
--timestamp_attributes	时间戳属性的列表
--mixer	目标Mixer实例
--quotas	需要分配的配额的列表，形式name1=amount1,name2=amount2...
--repeat	连续发送指定次数的请求，默认1
--trace_jaeger_url	追踪相关
--trace_log_spans
--trace_zipkin_url

用于产生遥感（telemetry）数据。Mixer期望以一组Attributes为输入，它基于自己的配置来判断调用哪个适配器、如何传递参数，进而输出遥感数据。

选项和check子命令一样。

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

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

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

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

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

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

为了加入到服务网格，K8S中的相关Pod、Service必须满足如下条件：

1. 命名端口：服务（指K8S的服务，不是Pod）的端口必须被命名，为了使用Istio的路由特性，端口名必须是 <protocol>[-<suffix>]的形式。protocol可以是http, http2, grpc, mongo或者redis，suffix是可选的，如果指定suffix则必须在前面加上短横线。如果protocol不支持，或者端口没有命名，则针对该端口的流量作为普通TCP流量看待（除非通过Protocol: UDP明确指定为UDP）。示例：
   
   YAML

   1 2 3 4 5 6 7 8 9 10 11

   apiVersion: v1 kind: Service metadata:   name: details spec:   ports:   - port: 9080     # 命名服务端口     name: http   selector:     app: details

2. 服务关联：如果一个Pod属于多个Kubernetes Service，则这些Service不得将同一端口用作不同协议
3. app和version标签：建议为Pod添加app和version两个标签，分别表示应用程序的名称和版本。在分布式追踪（distributed tracing）中app标签用于提供上下文信息。在Metrics收集时app、version标签也提供上下文信息

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

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

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

如果你的Kubernetes集群不使用缺省的集群DNS后缀（即cluster.local），则很多组件的参数需要修改，可以参考chart-istio项目，搜索{{ .Values.global.domain }}找到需要修改的位置。

Istio暴露了几个Configmap，修改这些Configmap以影响Istio的行为。

可以跨越多个Kubernetes集群来部署Istio服务网格。

1. 两个或更多的运行1.9+版本的Kubernetes集群
2. 有权在其中一个集群上部署Istio控制平面
3. 使用RFC1918网络、VPN或更高级的网络技术将集群连接在一起，并且满足：
   1. 所有集群的Pod网络CIDR、Service网络CIDR不重叠
   2. 所有集群的Pod网络可以相互路由
   3. 所有集群的API Server可相互联通
4. Helm 2.7.2或更高版本

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注入，你需要执行：

然后，执行下面的命令安装所有组件：

等所有容器都运行起来了，检查一下当前命名空间，应该多出6个Pod、4个Service。

当所有Pod都进入Running状态后，你需要创建一个（入口）网关，这样浏览器才能访问到集群中的Bookinfo服务：

上述命令会创建一个Gateway，一个VirtualService：

我的本地环境，通过配置路由，允许集群外部访问ClusterIP：

因此直接使用上述地址10.109.97.20即可。如果你使用NodePort方式，则需要使用宿主机IP + 映射后的端口。

如果使用外部负载均衡器（LoadBalancer类的Service），则参考如下命令：

如果一切正常，应该打印200到控制台。 如果通过浏览器查看，界面右侧的Reviews面板会随机出现无星、黑星、红星，这种随机是K8S的Service负载均衡机制导致的。

下面的DestinationRule声明了productpage、reviews、ratings、details等微服务的不同版本。版本通过Pod的version标签来区分。

一个简单的HTTP测试服务，用于试验Istio的各种特性：

Fortio是Istio的负载测试工具，提供CLI和Web UI。

Fortio能够按照指定的QPS来执行HTTP请求，录制执行耗时、百分比分布（percentiles，例如p99表示99%的请求耗时小于的数值）直方图。

这是一个基于Ubuntu的容器，它启动后只是简单的休眠。你可以通过kubectl连接到此容器并执行curl命令：

下面的例子创建了几个“虚拟服务“，这些虚拟服务将请求流量全部路由给各微服务的v1版本：

虚拟服务的会被转换为Envoy配置信息，在若干秒内传递到所有Pod的Sidecar，达到最终一致性。

虚拟服务可以遮蔽掉K8S的同名Service，启用了Envoy Sidecar的Pod（包括入口网关）访问productpage、reviews、ratings、details这几个微服务（各自对应了一个K8S Service、一个虚拟服务、以及一个DNS名称）时，会自动经由上面定义的几个虚拟服务处理，其效果就是全部访问v1版本的微服务。虚拟服务的路由逻辑在请求方的Sidecar中实现。

现在再打开浏览器访问/productpage，你会发现，不管刷新多少次，Reviews面板总是显示为无星。

从本章开始处的架构图可以知道，productpage会访问reviews服务，我们看一下前者Sidecar日志，可以发现类似下面的内容：

在看看后者v1版本的Sidecar日志，可以发现相呼应的内容：

你可以修改虚拟服务reviews，将v1替换为v2、v3，看看有何效果：

虚拟服务支持根据请求信息路由，下面的例子依据请求头end-user的值决定使用什么版本的reviews服务：

现在，刷新/productpage可以发现是无星，以alex登陆（密码随意）后则显示为黑星。 

故障注入（Fault Injection）属于破坏性测试，用于考验应用的韧性（resiliency）。

下面的例子，专为alex用户在reviews:v2和ratings之间引入7s的延迟：

以alex访问/productpage，页面会在挂起6秒后提示reviews不可用。这是由于productpage到reviews的超时被硬编码为6秒，而reviews到ratings的超时被硬编码为10秒，我们的故障注入导致productpage访问reviews出现超时错误。

除了timeout之外，你还可以注入abort形式的故障，即立刻访问一个HTTP错误码。

Istio支持逐步的将流量从一个版本迁移到另一个，通常是从老版本迁移到新版本。

定义虚拟服务时，你可以设置不同destination的权重，并逐步调整，直到完全切换到另一个版本。下面的例子会让你由50%的概率看到无星或红星：

你可以为虚拟服务中的路由规则设置超时，默认的HTTP调用超时为15秒。

下面的例子把reviews服务的timeout设置为1ms，这意味着访问该服务的客户端都会基本都会收到超时错误：

此时再访问/productpage，会提示product reviews are currently unavailable。

istio-ingressgateway负责处理Gateway资源，就像K8S中Ingress Controller负责处理Ingress资源那样。

istio-ingressgateway默认已经同时支持HTTP/HTTPS，并在80/443端口上监听。

下面的例子创建一个HTTPS网关：

你总是需要一个VirtualService来配合Gateway：

注意SSL Termination在网关，后端服务不需要启用HTTPS。

完成上述步骤后，访问https://httpbin.k8s.gmem.cc/status/418可以看到如下输出：

和上一节的单向认证类似，但双向（mutual TLS ）认证需要额外为入口网关控制器提供一个CA证书，用于校验客户端的数字证书。

使用官方Istio的Chart安装时，它默认从保密字典istio-ingressgateway-ca-certs加载CA证书，且挂载到/etc/istio/ingressgateway-ca-certs。

参考下面的代码修改Gateway的定义：

然后，通过CA为客户端签发证书，并在访问服务器时指定自己的密钥和此证书：

要从服务网格内访问外部URL，需要配置绕过代理的IP范围，或者配置出口网关，否则无法访问仅仅能得到404：

下面是通过出口网关访问gmem.cc的例子：

现在再尝试上面的kubectl exec命令，会发现能正常获得响应。 

当访问外部HTTPS服务（TLS协议）时，可能需要同时创建ServiceEntry + VirtualService。此外如同访问网格内部服务一样，你可以通过VirtualService对外部服务进行流量管理。

下面的例子，允许网格内部访问mynewproddb.idc2提供的MySQL服务：

断路器是创建韧性微服务应用所常用的一种模式，可以让应用程序免受上游（Upstream，即调用链中更加远离根的节点）服务失败、延迟峰值（latency spikes）或其它网络异常的侵害。

下面的示例配置了一个断路器，它在客户端访问httpbin服务时生效：

登陆到fortio来访问受断路器控制的httpbin服务： 

上面的fortio命令并发度为2，而断路器仅仅允许1个并发请求，因此会有几率出现错误：

如果将并发度设置为20，连续发送1000次，则错误率飙高到90%：

查询客户端Proxy的统计信息，可以看到更多细节：

下面的虚拟服务，将所有请求发送给v1，同时镜像一份给v2：

发送给镜像服务的请求，其Host/Authority请求头被自动加上-shadow后缀。 

利用Mixer和Sidercar，可以获得服务网格的各种统计指标（Metrics）、日志，或者跨越不同的服务进行分布式的调用链追踪。

通过配置，Istio可以自动收集网格中某个服务的统计指标，或者为每次请求产生日志。

下面的例子，为每个请求生成一个Prometheus指标值：

下面的例子，为每个请求产生一条日志：

 将上述两端配置文件保存为yaml文件，并通过kubectl apply命令安装到K8S，然后进行下一步试验。 

打开Istio内置Prometheus服务的Web界面， 输入istio_double_request_count进行查询，可以看到每个微服务的请求次数都被client、server方分别报送，并预先聚合了。

实际上Istio官方提供的Chart中，以及提供了HTTP/TCP请求的次数、持续时间、请求长度、应答长度，以及访问日志的instance/handler/rule配置，可以直接安装使用。

打开Istio内置Grafana服务的Web界面，可以看到Istio目录下预定义好了7个仪表盘页面。该服务使用grafana/grafana:5.0.4版本的镜像。

参考配置请求限速一节。

你可以使用Mixer中可见的任何请求属性来控制对服务的访问。下面的例子禁用了对ratings:v3的访问：

Istio也支持基于请求属性的黑白名单，下面的例子和上面的denier是等价的：

以--set tracing.enabled=true选项安装Istio Chart，即可使用。由于默认设置的采样率较低，你需要反复访问多次/productpage才能捕获到Trace。

打开Istio内置Jaeger服务的Web界面，点击顶部按钮切换到Search页签，在Find Traces面板中Service选取productpage，点击Find Traces，看到如下的Trace列表：

点击其中一个Trace，可以查看其调用链信息：

可以看到，这个由单次/productpage请求产生的调用链由6个Span构成，每个Span对应一个彩色条带。每个Span消耗的时间都标注在界面上了。

打开Istio内置Jaeger服务的Web界面，点击顶部按钮切换到Dependencies页签，可以看到Jaeger依据Traces计算出的服务依赖关系图（DAG，有向无环图）：

 

尽管Istio的Sidecar能够自动发送Span给Jaeger，要将这些Span合并为完整的Trace还需要额外的信息，应用程序必须提供必要的HTTP请求头。

每个微服务都需要收集调用它的HTTP请求的x-request-id、x-b3-traceid、x-b3-spanid、x-b3-parentspanid、x-b3-sampled、x-b3-flags、x-ot-span-context头，并在它调用任何上游（Upstream，上图的ratings是reviews的Upstream）微服务时，带上这些头。

Bookinfo中，productpage服务基于Python编写，收集请求头的代码如下：

reviews服务则基于Java编写， 收集请求头的代码如下：

Istio默认会追踪任何请求， 对于开发、测试环境这是可以的，线上环境通常需要降低采样率，否则压力太大。调整采样率有两种方式：

1. 使用官方Chart安装时，调整pilot.traceSampling，当前使用的Chart版本已经将其设置为1.0，即百分之一的采样率
2. 修改Deployment istio-pilot的环境变量PILOT_TRACE_SAMPLING

采样率的精度是0.01

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假设基础设置提供一个服务注册表（service registry，例如K8S的Service），此表跟踪某个服务的VM/Pod集。此服务注册表应当负责新实例的加入、不健康实例的移除。

Istio从服务注册表中读取服务的信息，并生成平台无关的服务发现接口。Envoy执行服务发现（基于xDS和Pilot交互），并动态的更新其本地负载均衡池。

网格中的服务，利用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连接错误的方式

流量镜像（Traffic mirroring）也叫shadowing，允许开发团队在最小风险的前提下改变产品的功能。其做法是将线上环境的流量复制到一个“镜像服务“中，镜像服务和主请求处理链是隔离的。

VirtualService支持为route配置mirror，实现流量镜像。

网关是运行在服务网格边缘的负载均衡器，它处理入站或出站的TCP/HTTP连接。

Istio提供入口网关，出口网关，对应：

1. 的CRD为Gateway、Gateway+ServiceEntry
2. 的Controller为istio-ingressgateway、istio-egressgateway

当提起术语“网关”时，基于上下文可能指Gateway这种资源，也可能指出口/入口网关的Service/Pod。

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

而使用Istio时，Ingress资源的地位可以由Gateway + VirtualServices代替。在集群内部组件相互交互时，不需要配置Gateway资源。需要注意，Istio也可以作为Ingress控制器，处理K8S原生的Ingress资源。

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

1. 客户端发起针对负载均衡器的请求
2. 负载均衡器将请求转发给集群的istio-ingressgateway服务，该服务可以部署为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的微服务无法访问集群外部的URL， 这是因为Envoy修改了Pod所在网络命名空间的Iptables，透明的将所有出口流量都重定向到Sidecar，而不经任何配置Sidecar只会处理网格内部的Destination。

要将外部服务暴露给启用了Sidecar的网格内部Pod/VM（它们是外部服务的客户端），必须：

1. 定义ServiceEntry，这种自定义资源允许针对指定的外部IP/DNS名称的流量通过Sidecar。ServiceEntry支持通配符匹配主机，可以降低配置工作量
2. 或者，配置一个IP范围，让针对此IP范围的出站请求经过/绕过Envoy代理。你可以设置Chart变量，
   
   Shell

   1 2	# 仅仅10.5.0.0/16走Envoy代理，其它直连。你可以将此Pod网络、K8S服务网络的CIDR配置到该字段中。这样，所有针对网格外部的访问都开放了 --global.proxy.includeIPRanges="10.5.0.0/16"

   则当从网格内部访问10.5网段时直接绕过代理。
   注意：此特性已经弃用，可以使用配置字典istio-sidecar-injector中的的includeOutboundIpRanges，或者Pod注解traffic.sidecar.istio.io/includeOutboundIPRanges代替

强调一下，访问集群内部域名、IP地址不受限制，即使不配置VirtualService也可以访问，而且Kiali直接可以识别出这种流量。

ServiceEntry还可以配合Gateway+VirtualService，将出口流量导向特殊的服务 —— istio-egressgateway，这种配置方式的适用场景是：

1. 离开网格的所有流量必须流经一组专用节点，这一组节点有特殊的监控和审查
2. 集群中的一般性节点不能联通网格外部

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

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

Istio的配置模型映射为K8S的资源，包括VirtualService、DestinationRule、ServiceEntry、Gateway四种。在K8S中你可以用kubectl来配置这些资源，它们都是CR。

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

下面的示例，将针对review服务的请求，3/4发给v1版本，1/4发给v2版本：

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

也可以在请求级别覆盖超时、重试配置，只需要提供Envoy规定的特殊请求头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路径、HTTP方法、HTTP Scheme、HTTP Authority值： 

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

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

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

Istio支持为虚拟服务配置跨源资源共享策略：

虚拟服务可以直接返回301重定向给调用者：

虚拟服务可以在转发请求给Dest之前，对HTTP请求的特定部分进行修改：

参考上文的例子。

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

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

可以针对所有子集配置：

也可以针对特定子集：

基于一致性哈希的负载均衡可以实现基于HTTP请求头、Cookie或其它属性的软的会话绑定（Session affinity）：

可以限制某个服务/子集的并发度：

可以为某个服务/子集配置断路器：

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

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

ServiceEntry可以和VirtualService一起工作，作为VirtualService的host。这是因为从概念上来说，来自底层基础设施注册表的服务、ServiceEntry定义的服务，都是Istio的概念性的Service。

下面的例子以主机名来静态的指定外部服务端点：

下面的例子以IP来指定外部服务端点：

关于hosts、addresses，以及服务的“唯一性标识”，Istio官方API文档有如下说明：

1. hosts字段：
   1. 对于非HTTP服务（包括不透明HTTPS）来说，此字段中指定的DNS名称被忽略
   2. 对于非HTTP服务，如果此字段指定的是DNS名称，则ports，或/和addresses中的IP地址用于唯一性的标识目的地
2. addresses字段： 表示关联到此服务的虚拟IP地址，可以是CIDR前缀：
   1. 对于HTTP服务来说，此字段被忽略，目的地根据HTTP头Host/Authority确定
   2. 对于非HTTP服务，hosts头被忽略。如果指定了addresses，则入站请求的IP地址和addresses指定的CIDR进行匹配，如果匹配成功，则认为请求的是当前服务。如果不指定addresses，则入站流量仅仅根据ports来识别，这种情况下，服务的访问端口不能被网格内部任何其它服务共享

这段描述让人费解，也不符合实际试验结果。下面的两个ServiceEntry，都是非HTTP服务，都使用443端口，都没有指定addresses字段，但是没有任何冲突出现：

生成的Envoy配置如下（可以看到集群、端点信息都是正常有效的）：

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

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

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

必须把上述网关绑定到VirtualService，它才能工作，精确的说，是网关产生的物理监听器才拥有了路由表：

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

ServiceEntry可以配合Gateway+VirtualService，将出口流量导向一组特殊的Pod —— istio-egressgateway。本节给出一个样例。

首先定义一个ServiceEntry：

有了这个配置以后，就可以从网格内部访问k8s.gmem.cc了，但是流量直接从Sidecar发往k8s.gmem.cc。

现在，我们要让流量通过istio-egressgateway的Pod转发。首先，定义一个Gateway：

然后，定义一个虚拟服务：

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

从逻辑上说，每次：

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

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

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

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

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

适配器	说明
prometheus	此适配器暴露了HTTP访问端点，Prometheus可以来采集此端点，获取服务网格的各项指标 使用Istio官方提供的Chart时，默认会在当前命名空间安装一个Prometheus服务器，并自动配置以抓取以下端点： istio-mixer.istio-system:42422，所有由Mixer生成的网格指标 istio-mixer.istio-system:9093，用于监控Mixer自身的指标 istio-mixer.istio-system:9102，Envoy生成的原始统计信息，从Statsd转换为Prometheus格式 注意：目前Envoy的http://0.0.0.0:15090/stats/prometheus也暴露了Prometheus指标

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

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

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

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

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

属性的字段，可能由请求的客户端Sidecar报告，也可能由请求的服务端Sidecar报告。

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

属性	说明
source.uid	平台相关的源工作负载实例的唯一标识，例如： kubernetes://redis-master-0.default
source.ip	ip_address，源工作负载实例的IP地址
source.labels	map[string, string]，源工作负载实例的标签集，例如： version => v1
source.name	源工作负载实例的名称，例如：redis-master-0
source.namespace	源工作负载实例所在的命名空间，例如default
source.principal	源工作负载实例的身份认证主体，例如service-account-redis
source.owner	源工作负载实例的所有者资源的唯一标识，Pod常常由Deployment所有，例如：kubernetes://apis/extensions/v1beta1/namespaces/istio-system/deployments/istio-policy
source.workload.uid	源工作负载（非实例，也就是服务）的信息
source.workload.name
source.workload.namespace
destination.uid	目标工作负载实例的信息
destination.ip
destination.port
destination.labels
destination.name
destination.namespace
destination.principal
destination.owner
destination.workload.uid	目标工作负载的信息
destination.workload.name
destination.workload.namespace
destination.container.name	目标工作负载实例的容器名，例如runtime
destination.container.image	目标工作负载实例的容器镜像
destination.service.host	目标工作负载的主机名，例如grafana.default.svc.k8s.gmem.cc
destination.service.uid	目标工作负载的唯一标识
destination.service.name	目标工作负载的名称，也就是K8S服务短名
destination.service.namespace	目标工作负载所在命名空间
request.headers	map[string, string]，HTTP请求头，对于gRPC，其元数据存放在此
request.id	低碰撞风险的请求唯一标识
request.path	请求的URL查询路径部分
request.host	请求的URL主机部分
request.method	请求的HTTP方法
request.reason	用于审计系统的请求原因
request.referer	HTTP referer头
request.scheme	请求URL的Schema部分
request.size	请求字节数，对于HTTP来说等于Content-Length
request.total_size	请求总大小，包括请求头、请求体、请求尾
request.time	timestamp，目标接收到请求的时间
request.useragent	HTTP User-Agent头
response.headers	HTTP响应头
response.size	HTTP响应大小
response.total_size
response.time	timestamp，目标返回响应的时间
response.duration	duration，目标处理请求所消耗的时间
response.code	int64，HTTP状态码
response.grpc_status	gRPC状态码
response.grpc_message	gRPC状态消息
connection.id	低碰撞风险的TCP连接的唯一标识
connection.event	TCP连接的状态，open/continue/close之一
connection.received.bytes	针对连接的最后一次Report()调用之后，接收到的字节数
connection.received.bytes_total	接收到的总字节数
connection.sent.bytes	针对连接的最后一次Report()调用之后，发送的字节数
connection.sent.bytes_total	发送的总字节数
connection.duration	TCP连接已经打开的时间
connection.mtls	boolean，是否启用mTLS
connection.requested_server_name	连接所请求的服务器名称（SNI）
context.protocol	请求或被代理连接使用的协议，例如tcp
context.time	Mixer操作的时间戳
context.reporter.kind	如果当前请求属性是从客户端报告，则为outbound 如果当前请求属性是从服务端报告，则为inbound
context.reporter.uid	请求报告者的UID
api.service	gRPC公共服务名，不是网格内部的服务标识，而是暴露给客户端的服务的名称
api.version	gRPC接口版本
api.operation	gRPC操作名称，例如getPetsById
api.protocol	暴露给客户端的协议，可以是http, https, grpc
request.auth.principal	源身份验证相关
request.auth.audiences
request.auth.presenter
request.auth.claims
request.api_key
check.error_code	Mixer Check调用的错误码
check.error_message	Mixer Check调用的错误消息
check.cache_hit	Mixer Check调用是否命中本地缓存
quota.cache_hit	Mixer Quota调用是否命中本地缓存

在你配置Instance的时候，往往需要对Attributes进行各种计算，才能得到Instance的字段。Attributes表达式是Go expressions的子集。

操作符	说明
==	逻辑等于，示例： request.size == 200
!=	逻辑不等，示例： request.auth.principal != "admin"
||	逻辑或，示例： (request.size == 200) || (request.auth.principal == "admin")
&&	逻辑与
[ ]	用于访问映射，示例： request.headers["x-id"]
+	算术加或字符串拼接，示例： request.host + request.path
|	如果左操作数为空，则表达式值为右操作数，示例： source.labels["app"] | source.labels["svc"] | "unknown"

函数	说明
match	Glob匹配，示例： match(destination.service, "*.default.svc.k8s.gmem.cc")
email	将文本转换为EMAIL_ADDRESS类型，示例： email("alex@gmem.cc")
dnsName	将文本转换为DNS_NAME类型，示例： dnsName("www.gmem.cc")
ip	将文本转换为IP_ADDRESS类型，示例： source.ip == ip("10.11.12.13")
timestamp	将RFC 3339文本转换为TIMESTAMP类型，示例： timestamp("2015-01-02T15:04:35Z")
uri	将文本转换为URI类型，示例： uri("http://istio.io")
.matches	正则式匹配，示例： "svc.*".matches(destination.service)
.startsWith	判断是否字符串以目标子串开头/结尾，示例： Go 1 2 destination.service.startsWith("acme") destination.service.endsWith("acme")
.endsWith
emptyStringMap	创建一个空的map[string][string]，示例： Go 1 request.headers | emptyStringMap()
conditional	模拟三元表达式： Go 1 2              // 如果为true                                      则        否则 conditional((context.reporter.kind | "inbound") == "outbound", "client", "server")

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

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

而这些配置是基于：

1. Adapters：封装Mixer和特定的基础设施后端的交互逻辑
2. Templates：定义将请求属性映射为适配器输入的Schema。一个适配器可以支持多个模板

列出Mixer可用的CRD：

对本地运行的Mixer服务进行liveness/readiness探测。

启动一个Mixer服务器。选项：

选项	说明
--adapterWorkerPoolSize	适配器工作线程池最多包含的Goroutine数量，默认1024
--address	Mixer的gRPC API的地址，例如tcp://127.0.0.1:9092或unix:///path/to/file
--port	如果不指定--address，Mixer的gRPC API的端口，默认9091
--apiWorkerPoolSize	API工作线程池最多包含的Goroutine数量，默认1024
--configDefaultNamespac	网格范围的配置信息存放在什么命名空间，默认istio-system
--configStoreURL	配置存储的URL，例如k8s://path_to_kubeconfig或fs://，对于k8s://（path_to_kubeconfig为空）则使用in-cluster的kubeconfig
--ctrlz_address	ControlZ自省机制的监听地址，默认127.0.0.1
--ctrlz_port	ControlZ自省机制的监听端口，默认9876
--livenessProbeInterval	liveness探针文件的更新间隔，默认0s
--livenessProbePath	liveness探针文件的存储位置
--readinessProbeInterval	readiness探针文件的更新间隔，默认0s
--readinessProbePath	readiness探针文件的存储位置
--log_as_json	日志输出为console还是json格式
--log_caller	需要包含调用者信息的日志Scope列表，Scope可用：adapters, api, attributes, default, grpcAdapter
--log_output_level	日志输出级别，格式为scope:level,scope:level...，级别可用：debug, info, warn, error, none
--log_target	日志输出目标，默认stdout
--maxConcurrentStreams	每个TCP链接上开启的出站GRPC流最大数量，默认1024
--maxMessageSize	每个GRPC消息的最大长度，默认1048576
--monitoringPort	暴露Mixer自我监控信息的端口，默认9093
--numCheckCacheEntries	（策略）检查（Check）缓存条目的最大数量，默认1500000
--profile	启用基于Web接口http://host:port/debug/pprof的性能剖析
--singleThreaded	如果为true，则所有针对Mixer的请求都会在单个Goroutine中处理，用于调试
--trace_jaeger_url	Jaeger的地址，例如http://jaeger:14268/api/traces?format=jaeger.thrift
--trace_log_spans	是否打印追踪Span的日志
--trace_zipkin_url	Zipkin的地址，例如http://zipkin:9411/api/v1/spans

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

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

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

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

适配器memquota可以用于实现流量配额，也就是限制请求速率。在生产环境下常常使用redisquota代替之。

要实现速率限制，需要在Client、Mixer两个地方进行配置：

1. Client：
   1. QuotaSpec，指定配额的名称，客户端需要请求的量
   2. QuotaSpecBinding，条件性的将QuotaSpec关联到一个或多个服务
2. Mixer：
   1. quota instance：从请求总抽取配额使用信息
   2. memquota handler：处理instance的适配器
   3. quota rule：规定何时将instance发送给handler

每个Quota实例都维护了一组计数器的集合，集合的大小即为dimensions的笛卡尔积。

当一个新请求到来时，如果Mixer发现超过在validDuration时间内超过maxAmount限制，则它发送RESOURCE_EXHAUSTED消息给请求方的Envoy，Envoy则返回429响应码给调用者。

memquota的时间区间使用滑动窗口的方式，分辨率为亚秒级。redisquota则既支持滚动窗口、也支持固定窗口算法。

适配器配置如下：

对于每个请求，从上往下寻找匹配的overrides，如果发现匹配则不再继续寻找，如果找不到匹配使用默认模式。

该Instance从请求中抽取memquota所需的输入：

配额规格，可以指定单次请求会消耗哪些配额，消耗的量是多大：

将配额规格关联到需要启用限速功能的服务：

如果要将配额绑定到所有服务，限制它们作为客户端时的访问速率，则：

上述几个CR可以通过下面的命令创建：

然后，反复刷新/productpage， 你会接收到错误提示：RESOURCE_EXHAUSTED:Quota is exhausted for: requestcount。这个信息是被调用服务的Envoy的响应体，它同时提供了429状态码。

查看productpage的日志，可以看到：

再查看调用者即入口网关的日志，可以看到： 

被限速的情况下，入口网关根本没有访问到productpage，直接被后者的Sidecar给拦截了。

本例中大部分资源都在istio-system中创建，如果你希望仅仅影响单个命名空间而非整个服务网格，则可以把它们都创建到指定的其它命名空间。

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

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上发生

架构图如下：

默认情况下Citadel会自己生成密钥对并自签名，作为CA证书。你也可以提供现有的CA证书，只需要创建对应的保密字典即可：

Citadel会使用该CA证书为工作负载的数字证书进行签名。 

这里的策略都是针对服务端（服务提供者）的：

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

上述配置应用后，所有被网格管理的服务仅仅接受基于TLS加密的请求。

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

使用mutual TLS时，客户端必须在DestinationRule中配置TLSSettings。

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

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

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

有了上面的、针对服务端的配置后，如果客户端不经任何配置，所有请求都会遭遇503错误。

要解决此问题，你必须为客户端配置DestinationRule，声明使用mtls：

不要忘记，DestinationRule也用于流量管理的配置。因此，如果某个具体服务需要独立的DestinationRule配置，一定要加上tls配置，因为上述DestinationRule被覆盖，而不是合并。

Istio会自动把客户端证书注入到所有Sidecar的/etc/certs目录下：

本节介绍当启用mTLS后，服务网格内外进行通信的可能性。

对于来自网格外部（包括没有Sidecar的集群内部组件）的请求，由于无法初始化mTLS连接，一定会失败。curl会得到退出码56，表示接收网络数据失败。

这个问题目前无解，除非降低目标服务的身份验证需求。

同样会失败，因为客户端会发起mTLS连接，而没有Sidecar的外部服务无法处理这种连接。

解决办法是为目标服务配置DestinationRule，并禁用TLS：

Kubernetes的API Server也没有Sidecar，如果网格内部服务需要访问K8S API Server，则也需要DestinationRule配置：

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

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

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

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

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

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

要定制Sidecar的行为，可以修改istio-sidecar-injector这个Configmap，或者给Pod添加对应的注解。

istio-sidecar-injector声明了需要给目标Pod注入的两个容器 —— istio-init、istio-proxy —— 的全部配置信息。这两个容器会自动读取Pod上的注解，覆盖对应的默认配置。

默认配置在安装时，通过Helm Chart的Values传入。

此容器运行脚本/usr/local/bin/istio-iptables.sh，命令行选项如下：

	默认值	说明
-p	15001	通过Iptables将所有TCP流量重定向到什么端口，Envoy必须在此端口上监听
-u	1337	对于什么用户的流量，不进行重定向，通常是代理容器的UID，此UID默认值为$ENVOY_USER=1337
-g		对于什么用户组的流量，不进行重定向
-m	REDIRECT	重定向入站流量到Envoy的方式。REDIRECT或TPROXY
-i	*	逗号分隔的CIRD形式的IP范围列表，匹配此CIRD的出站流量将被重定向给Envoy。设置为*则所有出站流量都被重定向给Envoy 如果没有配置适当的Istio资源，例如ServiceEntry，Envoy默认情况下可能返回404，这导致默认情况下你无法访问网格外部的服务
-x	""	当上一个参数设置为*时，用来指明哪些出站流量不重定向给Envoy，形式与上一参数相同 不重定向给Envoy，则流量的行为和没有部署服务网格时一致
-b	""	逗号分隔的端口列表，来自这些端口的入站流量将重定向给Envoy。设置为*则所有入站流量都重定向给Envoy，设置为空则禁用入站流量重定向 默认情况下，已经在匹配当前Pod的K8S Service声明的端口，重定向给Envoy，也就是说，虽然容器监听了8086端口，但是没有配置相应的K8S Service，就不走Envoy，因而不能进行策略、安全检查
-d	15020	当上一个参数设置为*时，用来指定哪些入站流量不重定向给Envoy，形式与上一参数相同 默认情况下，Pilot代理状态端口15020不重定向给Envoy

常用的注解如下：

注解	对应选项
sidecar.istio.io/interceptionMode	-m
traffic.sidecar.istio.io/includeOutboundIPRanges	-i
traffic.sidecar.istio.io/excludeOutboundIPRanges	-x
traffic.sidecar.istio.io/includeInboundPorts	-b
traffic.sidecar.istio.io/excludeInboundPorts	-d

traffic.sidecar.istio.io/*会导致Iptables规则的变更。例如：

istio-init会把上述规则打印到标准输出。

可以修改istio-sidecar-injector中istio-proxy容器的命令行参数，从而间接的影响Envoy的行为。

此代理的入口点是pilot-agent，该进程会创建envoy进程，执行下面的命令可以了解可传递给Envoy的参数列表：

下面的配置，可以让位于网格内部的容器访问10.0.0.0/8网段，而不需要定义ServiceEntry即可访问该网络的任意IP（或者DNS名称）的任意端口：