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

控制平面性能：Pilot的CPU、内存消耗受网格的配置变化情况、工作负载变化情况、连接到Pilot的代理数量的影响。增加Pilot的实例数来可以减少配置分发处理的时间，提高性能。网格中包含1000服务、2000工作负载、1000QPS的情况下，单个Pilot实例消耗1个vCPU和1.5GB内存。

数据平面性能：

1. CPU，代理在1000QPS下大概消耗0.6个vCPU
2. 内存，代理的内存消耗取决于它需要处理的配置数量，大量的Listener、Cluster、Route会增加内存使用。此外，代理在1000QPS下需要消耗50MB内存
3. 延迟，请求需要同时经过客户端/服务器的sidecar，在1000QPS下P99大概是10ms级别。启用策略检查（Check）会额外增加延迟。L4过滤器的逻辑比较简单，因此TCP流量不会引入显著延迟

1. CRD从Istio的Chart中独立出来，放入istio-init这个Chart。这避免了升级Istio而丢失CR数据
2. 添加几个安装配置Profile，这些配置提供了常用的安装模式，简化了Istio的安装过程
3. 增强了多集群集成

1. 新的资源类型Sidecar。用于对工作负载的边车代理进行细粒度的控制，特别是可以限制边车能够向哪些服务发送流量。此资源可以减少需要计算和传输给边车代理的配置信息，提升启动速度，减少资源消耗，提升控制平面可扩容性。在大型集群中，建议为每个命名空间提供一个Sidecar资源
2. 支持限制服务（ServiceEntry、VirtualService）的可见范围。exportTo可用于限制哪些命名空间能够访问本服务。除了在Istio CR上指定exportTo以外，你还可以在K8S的Service上使用networking.istio.io/exportTo注解
3. Gateway引用VirtualService时，可能存在歧义，因为不同命名空间可能定义具有相同hostname的VirtualService。在1.1版本中，你可以用namespace/hostname-match的形式来来设置hosts字段，以避免歧义。类似的在Sidecar中你也可以为egress配置为这种形式
4. 支持设置ServiceEntry的Locality，以及关联的SAN（用于mTLS）。现在使用HTTPS端口的ServiceEntry不再需要配套的VirtualService来工作
5. 位置感知路由（Locality-Aware Routing），优先路由到位于当前地理位置（Locality）的服务端点
6. 简化了多集群模式的安装、支持额外的部署模式。现在可以用Ingress网关连接多个集群，而不需要Pod级别的VPN。为了HA可以在各集群中部署控制平面，这种部署方式下位置感知路由自动开启。可以将命名空间扩展到多个集群，以创建全局命名空间
7. Istio的Ingress组件被废弃
8. 性能和可扩容性得到提升
9. 默认关闭访问日志

1. 健康检查探针，当启用mTLS的情况下，支持Kubernetes的Readiness/Liveness探针。当启用mTLS后，进入Envoy的HTTP探针请求会被拒绝，1.1能够自动进行HTTP探针的重写，将探针请求转发给pilot-agent，并由后者直接转发给工作负载，绕开Envoy的TLS认证
2. 集群RBAC配置，将RbacConfig资源替换为ClusterRbacConfig资源
3. 基于SDS的身份配置（Identity Provisioning ），不需要重启Envoy即可实现动态证书轮换，实现on-node的密钥生成增强了安全性
4. 在HTTP/gRPC的基础上，支持TCP服务的授权
5. 支持基于终端用户组的授权
6. Ingress网关控制器支持外部证书管理，新的控制器用于支持动态的加载、轮换外部证书
7. 定制PKI集成，支持Vault PKI，基于Vault CA签发证书

1. 策略检查默认关闭，主要是出于性能方面的考虑
2. 性能的增强：
   1. 极大的减少了Envoy默认生成的统计信息的收集
   2. 为Mixer工作负载添加了负载限制的功能
   3. 改善了Mixer和Envoy之间的交互协议
3. 适配器现在能够影响入站请求的头和路由
4. 进程外适配器，生产级可用，进程内适配器被废弃
5. 添加了默认的用于跟踪TCP连接的指标

在1.0版本Istio只提供了一种基于扁平网络的多集群方案：Istio控制平面部署在其中单个Kubernetes集群中。这种方案要求各集群的 Pod 地址范围不能重叠，且所有的 Kubernetes 控制平面API Server 互通。看上去就是物理上把多个Kubernetes并到一个Istio控制面下，在Istio看来是同一个网格。这种方案的网络要求苛刻，实际应用并不多。

1.1版本对多集群上做了非常多的增强，除了保留1.0扁平网络作为一种单控制面的方案外，还提出了另外两种方案供用户根据实际环境和需求灵活选择，这两种方案都不要求是扁平网络：

1. 多控制平面方案：在每个集群中安装完整的Istio控制平面，可以看成是一种松散的联邦，集群间服务在Gateway处联通即可。通过一个全局的DNS将跨集群的请求路由到另外一个集群里去。这种集群的访问是基于Istio的ServiceEntry和Gateway来实现的，配置较多且复杂，需用户自己维护
2. 一种集群感知（Split Horizon EDS）的单控制平面方案：Istio控制平面只在一个Kubernetes集群中安装，Istio控制平面仍然需要连接所有Kubernetes集群的K8S API Server。每个集群都有集群标识和网络标识。在服务间访问时，如果目标是本集群的负载，则类似单集群的方式直接转发；如果是其他集群的实例，则将流量转发到集群的入口网关上，再经过网关转发给实际负载

在1.1版本中添加了一个重要字段exportTo。用于控制VirtualService、DestinationRule和 ServiceEntry 跨Namespace的可见性。这样就可以控制一个Namespace下定义的资源是否可以被其他Namespace下的Envoy访问。

如果不设置exportTo则默认全局可见。目前exportTo仅仅支持两个取值：

"."，表示仅仅当前命名空间可以使用当前资源

"*"，表示任何命名空间都可以使用当前资源

Sidecar是具有命名空间的资源。每个Sidecar应用到命名空间的一个和多个工作负载，工作负载的选择通过workloadSelector进行，如果不指定workloadSelector（每个命名空间只能有一个这样的Sidecar）则Sidecar应用到命名空间的所有（没有被其它带有workloadSelector的Sidecar匹配的）工作负载。

如果命名空间包含多个没有workloadSelector的Sidecar，或者多个Sidecar的workloadSelector匹配同一工作负载，则网格的行为是未定义的。

配置示例一，允许prod-us1命名空间的Pod发起针对prod-us1, prod-apis, istio-system命名空间的公共服务的egress流量：

配置示例二：

配置示例三，如果工作负载没有启用基于Iptables的流量劫持，则Sidecar资源是唯一的配置工作负载边车端口的途径：

字段captureMode指定流向监听器的流量如何被捕获（劫持），仅仅当监听器绑定到IP地址的情况下此字段才有意义：

取值	说明
DEFAULT	由环境定义的默认捕获模式
IPTABLES	基于Iptables重定向进行捕获
NONE	不进行流量捕获，当用在： egress监听器中时，应用程序被期望明确的和监听的端口/UDS进行直接通信 ingress监听器中时，必须保证工作负载的其它进程不会占用目标监听端口

Istio支持使用三元组：Region、Zone、Sub-zone来描述网格的地理位置，地理位置通常精确到某个数据中心。Istio能够使用此地理位置信息来对负载均衡池进行优先级控制。

在1.1版本中，基于地理位置的负载均衡仍然是试验特性，且默认关闭。设置环境变量PILOT_ENABLE_LOCALITY_LOAD_BALANCING到所有Pilot实例以开启此特性。

服务发现平台负责自动产生地理位置信息，在K8S中，Pod的地理位置基于它所在Node的知名标签来获取。在云环境下，Node的这些标签会自动设置，否则你需要手工设置Node标签。这些标签包括：

failure-domain.beta.kubernetes.io/region

failure-domain.beta.kubernetes.io/zone

注意，K8S没有sub-zone的概念。

基于地理位置的负载均衡，其默认模式是地理位置优先负载均衡（locality-prioritized load balancing ）。Istio会提示Envoy，尽可能将流量转发给和当前Enovy更近的目标工作负载实例。

另一种模式是地理位置权重负载均衡（Locality-weighted load balancing），直接指定不同地理位置负责提供服务的权重。

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	-a	自动感知的属性列表，形式name1=value1,name2=value2...
--bool_attributes	-b	布尔值属性的列表
--bytes_attributes		字节值属性的列表
--concurrency	-c	并行的调用Mixer的线程数
--double_attributes	-d	浮点数属性的列表
--duration_attributes		时间长度属性的列表
--int64_attributes	-i	整数属性的列表
--string_attributes	-s	字符串属性的列表
--stringmap_attributes		string:string映射类型的属性列表，形式name1=k1:v1;k2:v2,name2=k3:v3...
--timestamp_attributes	-t	时间戳属性的列表 时间戳必须以ISO8601格式指定，例如： Shell 1 2 3 4 5 6 7 8 # UTC时间 2019-03-27T11:42:57Z   # 北京时间 2019-03-27T11:42:57+08:00   # 带毫秒 2019-03-27T11:42:57.000+08:00
--mixer	-m	目标Mixer实例
--quotas	-q	需要分配的配额的列表，形式name1=amount1,name2=amount2...
--repeat	-r	连续发送指定次数的请求，默认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中修改对应配置项即可。

1.0.3版本：

1.1.4版本：

到Github下载Istio的压缩包，解压后在其根目录执行。

我的环境下，镜像拉取需要Secret：

对于Istio 1.1，需要首先安装独立的Chart istio-init，进行CRD的注册：

安装Istio组件：

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

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

注意：1.1版本的Chart这块已经处理好，修改values.yaml中的global.proxy.clusterDomain即可。

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请求的特定部分进行修改：

参考上文的例子。

这里是一个TCP路由的例子：

在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字段被忽略：

需要以下细节：

1. 上述虚拟服务和网关配对后，istio-ingressgateway的Pod立刻开始监听2181端口
2. 但是，istio-ingressgateway服务默认只配置了80、443端口

这意味着上述网关配置不可用，你还需要修改istio-ingressgateway服务的配置。

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

首先定义一个ServiceEntry：

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

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

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

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

从逻辑上说，每次：

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

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

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

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

而这些配置是基于：

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

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

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

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

Istio提供了很多内置适配器，每种适配器都对应一个CRD，这些CRD的实例就是适配器的实例，也即Handler。Adaptor CRD的实例，表示一种自定义的适配器。自定义适配器实例化时使用Handler类型的CR。

适配器的类型使用CRD来描述，执行下面的命令查看系统中可用的适配器类型：

执行下面的命令查看Prometheus适配器的实例：

本节后续内容讨论主要的内置适配器。

支持 metric 模板

此适配器暴露了HTTP访问端点，Prometheus可以来采集此端点，获取服务网格的各项指标

使用Istio官方提供的Chart时，默认会在当前命名空间安装一个Prometheus服务器，并自动配置以抓取以下端点：

1. istio-mixer.istio-system:42422，所有由Mixer的Prometheus适配器生成的网格指标。指标名以istio_开头
2. istio-mixer.istio-system:9093，用于监控Mixer自身的指标
3. istio-mixer.istio-system:9102，Envoy生成的原始统计信息。指标名以envoy_开头

注意：目前Envoy的http://0.0.0.0:15090/stats/prometheus也暴露了Prometheus指标

该适配器包含的配置参数如下：

参数	说明
metrics	类型 Params.MetricInfo[]，需要插入到Prometheus的指标的列表。如果指标在Istio中定义了，但是没有在这里进行适当配置，则不会推送到Prometheus： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 metrics:   # 作为指标名前缀的命名空间。如果指标名为requests_total，该字段设置为istio，则最终完整的、   # 提供给Prometheus的指标名是istio_requests_total。默认istio - namespace: string   # 注册到Prometheus的指标的名称，如果不指定从instanceName自动生成   name: string   # 必须，此MetricInfo处理的Istio Metric实例的全限定名称   instanceName: string   # 易读的描述   description: string   # 该指标的类别   # Params.MetricInfo.Kind   kind： UNSPECIFIED | GAUGE | COUNTER | DISTRIBUTION   # 对于DISTRIBUTION类型的metric，该配置指定了聚合后数据所存放的桶   # 对于非DISTRIBUTION类型的metric该字段无意义   # Params.MetricInfo.BucketsDefinition   buckets:     # 三选一：     # 线性桶，每个桶的大小（区间一致）     linearBuckets：       # 桶数量为： N = num_finite_buckets + 2       numFiniteBuckets: int32       # 桶的宽度       width: double       # 第一个桶的下限       offset: double     # 指数桶     exponentialBuckets：       # 桶数量为： N = num_finite_buckets + 2，两个额外的桶用作下溢、上溢桶       # 对于桶i，它的左右边界为：       # [scale * (growth_factor ^ (i - 1)), scale * (growth_factor ^ i) ]       growthFactor: double       scale: double       numFiniteBuckets: int32     # 明确定义的桶     explicitBuckets：       bounds: [ double,... ]   # 指标的标签名的数组，这些标签必须和metric实例的dimension匹配   labelNames：   - dimension1   - dimension2 示例： YAML 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 apiVersion: config.istio.io/v1alpha2 kind: prometheus metadata:   name: handler spec:   metrics:   # 从那个metric类型的instance上读取生成该指标所需的信息   - instance_name: requestcount.metric.istio-system     # 生成Prometheus的Counter     kind: COUNTER     # 将instance上的以下维度作为标签     label_names:     - reporter     - source_app     - source_principal     - source_workload     - source_workload_namespace     - source_version     - destination_app     - destination_principal     - destination_workload     - destination_workload_namespace     - destination_version     - destination_service     - destination_service_name     - destination_service_namespace     - request_protocol     - response_code     - connection_security_policy     name: requests_total   - buckets:       # 明确定义的桶，桶数量是下面数组的长度+2       explicit_buckets:         bounds:         - 0.005         - 0.01         - 0.025         - 0.05         - 0.1         - 0.25         - 0.5         - 1         - 2.5         - 5         - 10     instance_name: requestduration.metric.istio-system     # 生成Prometheus的Histogram     kind: DISTRIBUTION     label_names:     - reporter     - source_app     - source_principal     - source_workload     - source_workload_namespace     - source_version     - destination_app     - destination_principal     - destination_workload     - destination_workload_namespace     - destination_version     - destination_service     - destination_service_name     - destination_service_namespace     - request_protocol     - response_code     - connection_security_policy     name: request_duration_seconds
metricsExpirationPolicy	可选参数，指定此Prometheus适配器生成的指标的过期策略 示例： YAML 1 2 3 4 5 metricsExpirationPolicy:   # 删除超过10分钟没有接收到更新的指标   metricsExpiryDuration: "10m"   # 每分钟进行一次是否过期的检查   expiryCheckIntervalDuration: "1m"

支持 metric 模板

将指标数据递送给StatsD后端

支持 checknothing、listentry、quota模板

用于Check，总是让检查失败

支持logentry模板

将Istio日志条目递送给Fluentd守护程序

支持kubernetes模板

从Kubernetes环境抽取信息，转换为Attributes，供下游适配器使用

支持listentry模板

用于Check，实现简单的黑、白名单

支持listentry模板

用于支持Istio的配额管理系统，用于开发环境下

支持quota模板

用于支持Istio的配额管理系统，用于生产环境下

支持 logentry、metric 模板

让Istio将日志、指标输出到标准输出、错误流，或者任何本地文件

支持tracespan模板 

将追踪数据递送给Zipkin和兼容的Tracer

模板是Instance如何生成的依据。通常情况下都是直接定义Instance，并使用kind字段引用实例的模板类型。

内置模板不需要在配置存储中定义Template类型的CR。每种内置模板都对应独立的CRD，这些CRD的实例就是模板的实例，也即Instance。Template CRD的实例，表示一种自定义的模板。自定义模板实例化时使用Instance类型的CR。

本节描述的是内置模板的实例配置方式。要了解如何使用自定义模板，参考扩展Istio一文。

该模板用于描述需要分发给特定监控后端的运行时指标，配置示例：

模板规格如下：

字段	说明
value	stio.policy.v1beta1.Value，此指标报告的值
dimensions	map<string, istio.policy.v1beta1.Value>，用以唯一的识别此指标的维度名值映射
monitoredResourceType	如果后端基础设施支持监控资源（monitored resource），这两个字段有用
monitoredResourceDimensions

注意：当编写配置时，字段的值可以是字面值或Go表达式。如果字段的类型不是istio.policy.v1beta1.Value，则Go表达式的推断类型必须和字段的类型匹配。

该模板用于从请求中抽取单个值，并和listchecker适配器联用，实现值检查。配置示例：

从请求中抽取单条日志。配置示例：

声明用于进行限额的各个维度的取值。配置示例：

表示分布式跟踪中一个单独的Span。配置示例：

如果满足选择器，则执行一组intentions —— 将instance发送给handler处理。示例：

每个Rule可以包含多个Action，表示选择器匹配时应该将哪些Instance发送给某个handler：

Handler就是适配器的实例。配置项说明：

下面的例子，定义了一个基于外置适配器的Prometheus类型的处理器：

Instance就是模板的实例，或者说，Instance是依据模板创建出来的。 配置项说明：

下面的例子创建了一个可以由Action直接引用的Instance：

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

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

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

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

描述一组属性，这些属性由Istio的某个组件产生。配置示例：

属性（Attributes）是Istio策略/监控功能的关键概念。属性是一小块数据，描述某个请求的自身的特征（property）或请求所处的环境，例如一个属性可能表示请求的长度、响应的状态码、请求来自的IP地址。每个属性都具有名称和取值。这里的请求不一定是HTTP请求，它可以是任意的网络活动，例如TCP连接，TCP连接的原始客户端IP就是一个属性。

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

为了简化系统、改善开发者体验，Istio使用共享的属性定义 —— 所由组件都使用这套定义。

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

此对象用于描述一个属性的Schema —— 定义属性的元数据：属性值的类型、属性的意义的描述。

任何Istio属性都必须对应某个AttributeManifest中的一个AttributeInfo。每个属性的名字必须是全局唯一的，在所由属性清单中，它只能出现一次。

属性的运行时形式没有做规定，不管使用JSON、XML还是Protocol Buffer来传递属性，其语义不会变化。

属性	说明
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")

表达式	说明
request.size | 200	返回int，返回请求的尺寸或者200
request.headers["x-forwarded-host"] == "myhost"	返回boolean，判断请求头的值
(request.headers["x-user-group"] == "admin") || (request.auth.principal == "admin")	返回boolean，逻辑或
(request.auth.principal | "nobody" ) == "user1"	返回boolean，如果request.auth.principal缺失不会导致错误
source.labels["app"]=="reviews" && source.labels["version"]=="v3"	返回boolean，逻辑与

使用Istio默认Chart安装时，它自动提供某些指标：

Mixer客户端库被静态编译到Envoy代理中。你可以通过Istio提供的CRD和其它对象，对Mixer客户端进行配置。

istio.mixer.v1.Attributes表示一组强类型的名称/值对。很多Mixer的API可能产生或消费属性。

Istio使用属性来控制网格中服务的运行时行为。属性可以描述：

1. Ingress流量的信息
2. Egress流量的信息
3. 流量所在的环境的信息

你部署的Istio具有一个固定的、它能够理解的属性表（vocabulary）。尽管某些特殊的Mixer适配器、服务能产生属性，但是属性主要由Envoy产生。

配置示例：