k8s和istio是什么关系？

哪位大神了解istio对gRPC的支持，是否可以做分流，熔断等。

尊敬的华为云客户：华为云计划于2019/07/11 00:00（北京时间）将华为云应用服务网格（Istio）正式转商用。商用后，服务将于2019/07/11 00:00（北京时间）正式开始收费。如需继续使用，请检查您目前单个集群下已纳入服务网格管理的服务实例个数，并确认商用后所属套餐类型。如属收费套餐（专业版、企业版）请确保您的账户余额充足，以免欠费造成资源释放，影响您的业务正常运行。您可根据以下规则评估您订购的应用服务网格产品是否收费：（收费指服务网格管理费用，业务运行的资源费用请参考CCE/ECS/ELB等产品介绍）套餐版本最大支持管理的容器实例数单个集群内已注入sidecar的容器实例数是否收费基础版10实例数<=10否专业版20010<实例数<=200是企业版1000200<实例数<=1000是上述套餐的开放功能也存在一定差异，具体套餐功能、定价资费介绍等问题，可随时通过工单或者服务热线（950808）与我们联系咨询。感谢您对华为云的支持！

尊敬的华为云客户：华为云计划于2019/07/11 00:00（北京时间）将华为云应用服务网格（Istio）正式转商用。商用后，服务将于2019/07/11 00:00（北京时间）正式开始收费。如需继续使用，请检查您目前单个集群下已纳入服务网格管理的服务实例个数，并确认商用后所属套餐类型。如属收费套餐（专业版、企业版）请确保您的账户余额充足，以免欠费造成资源释放，影响您的业务正常运行。您可根据以下规则评估您订购的应用服务网格产品是否收费：（收费指服务网格管理费用，业务运行的资源费用请参考CCE/ECS/ELB等产品介绍）套餐版本最大支持管理的容器实例数单个集群内已注入sidecar的容器实例数是否收费基础版10实例数<=10否专业版20010<实例数<=200是企业版1000200<实例数<=1000是上述套餐的开放功能也存在一定差异，具体套餐功能、定价资费介绍等问题，可随时通过工单或者服务热线（950808）与我们联系咨询。感谢您对华为云的支持！

《直播回看》栏目会将“华为云开发者者联盟”移动端课程平台的精品音视频直播课，定期进行展播，支持各位伙伴进行回看学习本期推荐： 容器-容器进阶之Istio流量治理与全景监控实践【主讲人介绍】主讲人：Aaron Chen华为云Istio服务工程师，对Istio本身具有深入研究，参与并推动多个Istio服务特性设计与研发。【课程大纲】课程围绕流量治理，及全景监控能力为中心进行讲解。介绍了负载均衡算法与会话保持的基础知识以及故障注入的应用场景和实现机制。对华为云istio服务流量治理中的故障注入，负载均衡配置等功能及应用性能监控，拓扑图，调用链等使用进行展示。学习完本课后，用户应当具备在华为云上独立动手进行流量治理功能的使用以及通过全景监控来验证配置生效的能力。【课程链接】可扫描下方二维码进入“华为云开发者联盟“移动端直播间收听课程

Istio，是一个由Google，Lyft，IBM联合开发的开源项目，是服务网格（Service Mesh）技术的一个标准化的开源实现，致力于解决应用的微服务化组件之间的连接控制与安全、流量管理与可观测性。Istio是云原生领域在Kubernetes之后最受关注的项目，帮助容器技术实践者从基础设施层的“容器编排“进阶到应用层的“服务治理”。Istio先天与Kubernetes无缝衔接，了解并使用Istio可以极大地提升研发和运维的工作效率。Cloud Native Lives之Istio入门实训课课程主题直播介绍观看回放资料下载Istio架构与技术点此了解点击观看下载Istio Pilot与服务发现点此了解点击观看下载Istio Gateway设计与技术点此了解点击观看下载Istio灰度发布与技术实现点此了解点击观看下载Istio xDS协议解析点此了解点击观看下载Istio Mixer架构设计与应用点此了解点击观看下载讲师介绍Idouba.Zhang华为云Istio服务架构师，Istio开源项目贡献者现负责华为云容器服务Istio产品化工作，参与华为PaaS平台产品设计研发，在Kubernetes容器服务、微服务架构、云服务目录、大数据、APM、DevOps工具等多个领域有深入研究与实践。Star.Zhang华为云Istio服务高级工程师，Istio开源项目贡献者现负责华为云容器服务Istio产品化的设计和开发工作。参与华为PaaS平台产品设计研发，在Kubernetes容器服务、微服务、PaaS平台的运维管理等多个领域有深入研究与实践。Fisher.XuIstio开源项目Approver，华为云高级工程师，华为云容器核心开发者，Istio 社区核心贡献者负责华为云容器服务的设计与核心组件开发，对Istio有深入理解。 HzxuzhongIstio开源项目Approver，华为云容器服务核心开发者Istio/Kubernetes社区核心贡献者, 主要负责Istio稳定性与可扩展性以及社区代码检视。对容器、微服务有深入认识。目前主要在istio社区从事性能优化及NetworkScope的实现以支持大规模可扩展性。

前言在公有云方面，华为云已经率先将 Istio 作为产品投入到公有云中进行商业应用中，保持和开源istio高度兼容，做了商业化的运维管理界面，同时进行了性能优化。这里我们做一次验证测试。Bookinfo 应用这里我们部署一个demo，由四个单独的微服务构成**（注意这里的四个微服务是由不同的语言编写的）**，用来演示多种 Istio 特性。这个应用模仿在线书店的一个分类，显示一本书的信息。页面上会显示一本书的描述，书籍的细节（ISBN、页数等），以及关于这本书的一些评论。Bookinfo 应用分为四个单独的微服务：productpage：productpage微服务会调用details和reviews两个微服务，用来生成页面。details：这个微服务包含了书籍的信息。reviews：这个微服务包含了书籍相关的评论。它还会调用 ratings 微服务。ratings：ratings 微服务中包含了由书籍评价组成的评级信息。这里主要使用reviews来演示 Istio 特性，reviews微服务有 3 个版本：v1 版本不会调用ratings服务。v2 版本会调用ratings服务，并使用 1 到 5 个黑色星形图标来显示评分信息。v3 版本会调用ratings服务，并使用 1 到 5 个红色星形图标来显示评分信息。下图展示了这个应用的端到端架构。 Istio 注入之前的 Bookinfo 应用Bookinfo 是一个异构应用，几个微服务是由不同的语言编写的。这些服务对 Istio 并无依赖，但是构成了一个有代表性的服务网格的例子：它由多个服务、多个语言构成，并且 reviews 服务具有多个版本。部署应用这里 Istio 的安装部署就不在赘述了。值得注意的是：如果使用的是开源K8s服务安装的 Istio ，要配置负载均衡。在 Istio 中运行这一应用，无需对应用自身做出任何改变。我们只要简单的在 Istio 环境中对服务进行配置和运行，具体一点说就是把 Envoy sidecar 注入到每个服务之中。这个过程所需的具体命令和配置方法由运行时环境决定，而部署结果较为一致，如下图所示：Bookinfo 应用所有的微服务都和 **idecar 集成在一起，被集成服务所有的出入流量都被 sidecar 所劫持，这样就为外部控制准备了所需的 Hook，然后就可以利用 Istio 控制平面为应用提供服务路由、遥测数据收集以及策略实施等功能。下载安装到 GitHub 中 istio 的 release 中下载相应版本的 istio包，下载后将 bin目录配置到环境变量 PATH中 export PATH="/istio/bin:$PATH"，这里我们使用的是 istio 1.0.5版本Bookinfo 这个应用就在samples/目录下 在华为云（CCE）上运行华为云率先将 Istio 作为产品投入到公有云中进行商业应用，开通方式十分简单，只要在华为云CCE上创建集群，然后申请 Istio 公测即可。为了方便测试Bookinfo 应用在华为云上提供了一键体验应用，点击即可省去刚刚那一系列的kubectl操作       一键创建体验应用       点击灰度发布即可       创建金丝雀发布       选择灰度发布的组件       填写版本号       选择镜像版本       版本创建完成后配置灰度策略       选择相应策略，策略下发即可总的来说，华为云的Istio 确实已经是商业化应用，这里只是展示了部分灰度发布的功能。其他比如流量治理，流量监控等功能还没展示，这些功能做的十分细致，值得尝试。参考基于ISTIO服务网格的灰度发布https://support.huaweicloud.com/bestpractice-cce/cce_bestpractice_0012.html

1性能增强虽然Istio1.0的目标是生产可用，但从去年7月份发布以来，在性能和稳定性上并不能让用户满意。社区的Performance and Scalability工作组在Istio v1.1中做了大量的努力以提高控制面和数据面的性能，其中最明显的性能增强包括：Sidecar API，减少发给proxy的配置数量以及pilot负载。网络配置规则（Destinationrule,Virtualservie, ServiceEntry）中增加的 exportTo字段限制配置的可见范围。Envoy默认收集的统计数据大量减少。给mixer增加load-shedding功能，防止overload。提升envoy和mixer之间的交互协议。可配置并发线程数，提高吞吐量。可配置filter来约束mixer遥测数据。从对Istio 1.1的测试数据来看，这部分工作取得了显著的效果。1.1控制面性能表现Pilot的CPU和内存使用受网格内的配置和系统状态的影响，例如负载变化速率，配置变化速率，连接到Pilot的proxy的数量等。可以通过增加Pilot的实例数来减少配置分发处理的时间，提高性能。在网格内有1000个服务，2000 个sidecars，每秒1000请求下的表现：单Pilot 实例使用 1 vCPU 和1.5 GB 的内存。istio-telemetry服务使用0.6 vCPU。1.2数据面性能表现CPU：proxy在每秒1000个请求下大约消耗0.6 vCPU 。内存：proxy的内存消耗主要取决于它需要处理的配置数量，大量的listeners, clusters, and routes配置会增加内存使用。proxy每秒1000个请求下大约消耗50MB的内存。时延：数据在传输时会通过客户端和服务端的sidecar，传输路径上的这两个proxy在1000 rps情况下，99%的请求时延是10 ms（TP99），单独server端的proxy增加6ms的时延。如果启用策略会进一步增加时延。2多集群方案在1.0中只提供了一种基于扁平网络的多集群方案：Istio控制面部署在一个Kubernetes集群中。这种方案要求各集群的 Pod 地址不能重叠，且所有的 Kubernetes 控制平面API Server 互通。看上去就是物理上把多个Kubernetes并到一个Istio控制面下，在Istio看来是同一个网格。这种方案的网络要求苛刻，实际应用并不多。在新发布的1.1版本上，多集群上做了非常多的增强，除了保留1.0扁平网络作为一种单控制面的方案外，还提出了另外两种方案供用户根据实际环境和需求灵活选择，这两种方案都不要求是扁平网络：多控制面方案：在每个集群中安装完整的Istio控制面，可以看成是一种松散的联邦，集群间服务在Gateway处联通即可。通过一个全局的DNS将跨集群的请求路由到另外一个集群里去。这种集群的访问是基于Istio的ServiceEntry和Gateway来实现的，配置较多且复杂，需用户自己维护。一种集群感知（Split Horizon EDS）的单控制面方案：Istio控制面板只在一个Kubernetes集群中安装，Istio控制面仍然需要连接所有Kubernetes集群的Kube API Server。每个集群都有集群标识和网络标识。在服务间访问时，如果目标是本集群的负载，则类似单集群的方式直接转发；如果是其他集群的实例，则将流量转发到集群的入口网关上，再经过网关转发给实际对端。3安全3.1HTTP Readiness Liveness Probe自动重写mTLS模式下，进入Envoy的HTTP请求会在TLS握手阶段被拒绝。1.1新增加了HTTP Probe的自动重写，通过将HTTP Probe请求发送到pilot-agent由其转发HTTP探测到应用，进而绕开Envoy的TLS认证。默认自动重写是关闭状态，用户需要根据实际需要打开。3.2集群级别的RBAC设置ClusterRbacConfigRbacConfig被标记为废弃，用户升级1.1后，必须迁移到使用ClusterRbacConfig。因为RbacConfig有bug，在一些情况下，其作用范围会被缩小到命名空间。3.3SDSSDS（SecretDiscovery Service）通过节点密钥生成提供更强的安全性以及动态的证书回滚。可以取代目前使用secret卷挂载的方式提供证书。1.1中目前为alpha，不建议生产环境使用，但是随着Istio发展值得期待。3.4授权新增对TCP类型服务的RBAC授权以及基于用户组的授权。3.5Vault集成允许用户集成开源Vault，使用Vault CA签发证书。4网络4.1新的sidecar API资源在1.1中引入Sidecar这资源对象可以更精细的控制Envoy转发和接收的端口、协议。在指定命名空间中使用sidecar资源时，支持定义可访问的服务范围。这样可以降低发给proxy的配置的数量。在大规模的集群中，我们推荐给每个namespace增加sidecar的对象。 这个功能主要是为了提升性能，减轻pilot计算的负担。对proxy的影响是：1. 内存占用少，2. 降低网络带宽占用。  4.2exportTo在Istio1.1版本中添加了一个重要字段exportTo。用于控制VirtualService、DestinationRule和 ServiceEntry 跨Namespace的可见性。这样就可以控制一个Namespace下定义的资源对象是否可以被其他Namespace下的Envoy执行了。如果未赋值，则默认全局可见。当前版本中只支持“.”和“*”两种配置。 “.”表示仅应用到当前Namespace。“*”表示应用到所有Namespace。4.3Locality based loadbalancerIstio 1.1 引入了负载均衡新特性：基于位置的负载均衡。这也是华为主导的新特性。目前是alpha特性，只支持服务网格全局的位置感知的负载均衡设置：基于位置权重的负载均衡设置（Locality-weighted load balancing）：Locality-weighted load balancing允许管理员基于流量来源及终止的位置信息控制流量的分发。例如可以设置从源位置{region}/{zone}/{sub-zone}的工作负载发出的流量转发到目的位置的endpoints负载均衡权重：用户可以为相同区域的工作负载访问设置较高的权重，为不同区域的工作负载设置较小的权重，减少网络延迟。基于位置的故障转移设置：类似于Envoy的“Zone aware routing”负载均衡策略，基于位置的故障转移特性，通过为不同的位置的endpoints设置不同的优先级，控制流量的转发策略。默认设置如下，同一位置{region}/{zone}/{sub-zone}的endpoints优先级最高，同一{region}/{zone}的endpoints优先级次之，同一region的endpoints第三，最后故障转移设置区域以及其他区域的endpoints依次。endpoints全部健康的情况下，流量只会在同一{region}/{zone}/{sub-zone}转发。当endpoint变得不健康时，会进行相应的降级处理，选择低优先级的endpoints转发。4.4pilot配置资源发现Istio1.1将galley作为默认的 配置规则发现中心，pilot通过MCP协议与galley进行配置订阅，取代1.0以前直接从Kubernetes以CR的方式watch配置资源。5策略和遥测默认关闭策略检查功能 为了提高多数客户场景下的性能，安装时默认关闭策略检查， 后期可按需开启此功能。弃用ServiceGraph，推荐使用 Kiali：提供了更丰富的可视化体验。多方面降低开销 ，提升性能和可扩展性：o 减少Envoy生成的统计数据的默认收集o Mixer的工作负载增加load-shedding功能o 改进Envoy和Mixer的通信协议控制请求头和路由 增加选项使适配器可以修改请求头和路由进程外适配器 进程外适配器功能生产可用，下个release弃用进程内适配器。多方面增强Tracing的能力： o Trace id支持128bit的范围o 支持向LightStep发送追踪数据o 增加选项完全禁用Mixer支持的服务的追踪功能o 增加策略的decision-aware 追踪默认的TCP指标 为追踪TCP连接增加默认指标降低Addon对Load Balancer的依赖 不再通过独立的load balancers对外暴露addons，而是通过Istio gateway来暴露插件服务。安全的Addon证书 改变插件的证书存储方式。Grafana, Kiali, and Jaeger的用户名和密码存放在kubernetes的secrets中以提高安全性和合规性。去除内置的statsd collector。Istio目前支持用户自己的statsd，以提高现有Kubernetes部署的灵活性。另外，Istio运维管理的复杂度也不能被部分用户接受（比如：众多的crd资源），因此社区专门成立了User Experience工作组致力于提高Istio的易用性，进一步降低其使用门槛。经过大家的共同努力，Istio1.1版本几经推迟终于发布了！我们有理由对其充满期待和信心，共同催熟以Istio为代表的云原生服务网格技术，为我们的用户提供高品质的云服务体验。欢迎试用华为云应用服务网格Istio。相关服务请访问： https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019

Istio 1.0版本发布到现在，已经过去8个月。Istio1.1的候选版本也到了rc5，预计近期会正式发布1.1。此版本包含了许多错误修复，在流量管理，安全，策略和遥测，多集群等领域添加了新的功能。对1.0的用户来说，感受最强烈的是： 默认关闭了策略执行功能默认开启了Mesh外的访问，再也不用担心未配置ServiceEntry对外的访问突然不通了。多集群不再只是1.0那种扁平网络的简单方案，提供了单控制面、多控制面几种方案，可以根据自己的场景需求选择。安全上SDS也终于来了提供更灵活的安全基础能力。性能上做了多点优化，总体表现值得期待。另外1.1提供了很多新的能力，在配置使用上也会有所不同，虽然不至于像0.8到1.0引入V1alph3导致接口大变样那么夸张，但API的使用确实值得我们去注意。最直观的感受将是，原来的结构上字段突然多了很多。Istio社区对1.1发布的初步文档已经在istio.io上提供，今天我们就率先为容器魔方粉丝献上中文版的功能预告流量管理新的sidecar：资源：在指定命名空间中使用sidecar资源时，支持定义可访问的服务范围，这样可以降低发给proxy的配置数量。在大规模的集群中，我们推荐给每个namespace增加sidecar对象。 这个功能主要是为了提升性能，减轻proxy计算的负担。限制网络资源的生效范围：为所有的网络资源增加了exportTo的字段，用来表示此网络资源在哪些namespace中生效。这个字段目前只有两个值：. 表示此网络资源只在自己定义的namespace生效；*表示此网络资源在所有的namespace生效。更新了serviceEntry的资源：指定服务的位置以及使用双向TLS关联的SAN。带HTTPS端口的service entry不再需要额外的virtualservice来开启基于SNI的路由。细粒度的多集群路由：简化了多集群的安装，并支持额外部署模式，能够利用ingress gateways连接多个集群，而不使用pod级别的VPN。在每个集群中都部署控制面以提供高可用，跨集群创建全局的命名空间。在高可用控制面方案中，默认开启AZ/Region的区域感知能力，降低跨区请求造成的性能损耗。弃用Istio Ingress：删除了以前弃用的Istio ingress。安全Readiness and Liveness 探针：在双向TLS启用的场景下支持Kubernetes HTTP readiness和liveness探针。集群RBAC配置：使用ClusterRbacConfig资源对象替代原来的RbacConfig。ClusterRbacConfig支持集群范围的配置。基于SDS的身份设置：On-node秘钥生成和动态证书替换不用重启Envoy。TCP授权管理：除了HTTP和gRPC外，支持对TCP服务的授权管理。最终用户组授权管理：支持JWT中组声明或者列表类型的声明。每路径最终用户认证：可以启用和禁用基于访问路径的JWT认证。Gateway上外部证书管理：支持动态加载和替换外部证书。集成Vault PKI：提供Vault保护的秘钥签名并与现有Vault PKI集成。自定义的可信域：在身份标识中支持特定org或cluster的安全域。多集群不可路由的L3网络：在不可路由的L3网络多集群环境中使用一个Istio 控制面。多控制平面：在多集群环境中，支持安装多个Istio控制平面。策略和遥测默认关闭策略检查功能：为了提高多数客户场景下的性能，安装时默认关闭策略检查， 后期可按需开启此功能。Kiali：弃用ServiceGraph，推荐使用 Kiali：提供了更丰富的可视化体验。多方面降低开销 ，提升性能和可扩展性：减少Envoy生成的统计数据的默认收集为Mixer的工作负载增加load-shedding功能改进Envoy和Mixer的通信协议控制请求头和路由：增加选项使适配器可以修改请求头和路由。进程外适配器：进程外适配器功能生产可用，下个release弃用进程内适配器。多方面增强Tracing的能力： Trace id支持128bit的范围支持向LightStep发送追踪数据增加选项完全禁用Mixer支持的服务的追踪功能增加策略的decision-aware 追踪默认的TCP指标：为追踪TCP连接增加默认指标。配置管理Galley：Galley在Istio中提供主要的配置管理和分发机制。它提供了一个健全的模型来验证，转换和分发配置状态到Istio各组件，使Istio组件与Kubernetes的细节隔离。Galley使用Mesh Configuration Protocol（MCP）和组件交互。监控端口：Galley的默认监控端口从9093改为15014。istioctl和kubectl校验命令：为 Istio Kubernetes 的资源增加离线校验命令—— istioctl validate。验证安装命令：在使用指定的YAML文件安装Istio前，可以用istioctl experimental verify-install 来预先检验Istio的安装状态。弃用的命令：弃用 istioctl create，istioctl replace， istioctl get 和 istioctl delete，使用 kubectl 代替；弃用 istioctl gen-deploy，使用helm template代替。下个版本（1.2）将删除这些命令。命令的缩写： 用kubectl操作Istio网络资源时可以使用缩写，例如: gateways简写为gw，virtualservice简写为vs等等。升级Istio Helm 配置的更改：默认关闭Egressgateway默认关闭Mixer policy默认允许所有出口流量（不用配置service entry），出口流量策略设置为ALLOW_ANY

1. 功能概述Envoy启动时，会启动一个进程，并在这个进程中启动很多线程，这样，可以启动很多worker线程，一般worker线程数与核心数相同，每个worker线程处理所有已配置的listener上的请求，管理连接并处理filterchain，非阻塞；同时，在这个进程中会启动一个主线程，它负责启动和停止envoy，也是通过API提供配置管理的线程，同时它收集不同的指标，管理其它线程，也是非阻塞的。2. 重要数据结构定义2.1 Filter过滤器，包括listener filter、network filter和http filter。Listener filter可以用于操作连接元数据，在新接收的套接字上进行操作，例如获取原始目的地址，重定向连接等；network filter主要负责数据读写；http filter主要负责数据处理。2.2 Listener监听器，envoy中支持在每个线程中配置任意数量的监听器，每个监听器独立配置一定数量的network filter，也可以选择性的配置listener filter，listener filter在连接建立之前处理，network filter在连接建立之后处理。2.3 Worker一个worker对应一个envoy的执行线程，将listener绑定在worker上，worker负责监听、过滤和转发，每个连接的生命周期会绑定在一个单独的worker上，通常情况下，envoy实现了100%的非阻塞。3. 代码流程3.1 流程概述Envoy启动时，首先启动主线程，在主线程中对listener和filter进行初始化操作，然后将listener绑定到worker上，并由主线程拉起worker线程，由worker线程负责监听新连接。3.2 初始化3.2.1 main入口main函数是envoy启动的总入口，首先生成main_common，用于后面的初始化。3.2.2 初始化main_common在main_common里面会生成maincommonbase，它会做server instance的初始化，一个instance是一个服务的实例.3.2.3 Instance初始化在maincommonbase里调用InstanceImpl函数后，首先对启动携带的配置信息进行注册，然后执行instance的初始化。Instance的初始化包括两部分：① 将当前instance注册到ListenerManager，来管理更新；② 创建并初始化MainImpl，MainImpl用来初始化监听listener；MainImpl根据配置文件获取静态监听listener列表，将它们实例化并注册到ListenerManager。3.2.4 初始化listener对于每个静态listener，根据配置文件为它创建ListenerFilterFactoryList，并根据配置为它添加ListenerFilterFactory。listener filter有三个：original dst filter，proxy protocol filter, TLS inspector filter，一一按照配置判断是否加入ListenerFilterFactoryList。配置ListenerFilterFactoryList的同时，也会根据配置为这个listener创建NetworkerFilterFactoryList，供后续建立在这个listener上的连接使用。3.3 启动3.3.1 启动入口在main_common初始化正常完成后，执行main_common→run()启动，从而后续执行instance的run()方法，在instance的run()方法，会执行网络级别上的listener初始化。3.3.2 启动worker，将listener绑定到worker上此处，会将从配置文件读取的所有listener绑定到所有的worker上，worker是服务的并发线程，数目一般和核心数相同，将listener绑定到worker上后会通过connectionhandler模块将其初始化。3.3.3 Listener初始化Listener的初始化过程首先生成ActiveListener，通过ActiveListener调用network包内的创建函数来对listener进行网络级别的初始化。3.3.5 启动worker线程，进入监听Listener绑定在worker上，当listener初始化完成后，需要启动worker服务才能真正进入监听流程。此处，为每个worker启动新线程，并调用libevent的event_base_loop进入监听，等待连接事件到达触发后，回调onAccept进入处理流程。4. 总结本文从程序入口main函数开始，分析了envoy如何启动，以及如何对listener、worker这些核心数据结构进行初始化，并详细阐述了从envoy主线程启动到worker线程进入监听行为的全过程。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

功能概述istio-proxy主要的功能是连接istio的控制面组件和envoy之间的交互，其中check的功能是将envoy收集的attributes信息上报给mixer，在istio中有几十种attributes（官方文档中有Attribute Vocabulary的具体介绍）, mixer根据自身的adapter给envoy 反馈。为了避免每次对mixer都进行远程调用，保证运行时的性能，在istio-proxy这里配置了本地缓存。具体实现在proxy这里配置了两层缓存，分别是referenced map和LRUcache，定义在check_cache.h中:Referenced map是用来存储envoy check之后mixer的返回的属性，也就是mixer的adapter所使用到的所有属性。LRUCache是用来储存每次对mixer请求之后所得到的check的结果。步骤简析缓存检查     cache->Check(attributes, result);     if (result->IsCacheHit()) return result->Status();未命中缓存，发起远程连接并且接受mixer回复.     result->SetReponse(status, response);     return result->Status();代码解读：1.缓存命中检查的入口在request_handler_impl.cc中，首先检查enable_mixer_check开关是否打开：返回的值是SendCheck:SendCheck的定义在client_context_base.cc中，这里通过check跳转到client_impl.cc中在client_impl.cc中，首先先初始化，重置新的检查选项，将检查的计数都归为0这些选项的options定义在options.h中，这里是设置了缓存的大小num_entries和network_fail_open这个开关。前文提到的Check的实现是CancelFunc MixerClientImpl::Check()这个函数。这里主要是调用了checkcache::check这个函数来进行检查。在没有超时的情况下，如果匹配到了map的签名（signature），并且在cache中命中。那么这一条cache的elem的status会返回result.status。在client_impl.cc中，判断缓存命中，完成check。CheckResponseInfo在check_response.h中定义，保存了check的结果回复。其中is_check_cache_hit是来判断这个response是否是在缓存中的，当命中时应该为true。2. 缓存没有命中如果在之前的check本地缓存的状态中返回的是Status(Code::NOT_FOUND, "")，就需要向mixer发起请求：这里是先将属性进行compress，并且将这些属性进行复制，给raw_check_result一个指针。向mixer发起异步的transport check请求，这个transport的定义在environment.h中。将从mixer得到的response传入到SetResponse中,得到result。缓存mixer的返回值：在前文中提到的check NOT_FOUND时候，会像mixer发起请求，这里的network_fail_open开关如果是true的话，那么对mixer请求不成功也会返回OK,如果返回状态为ok()时，证明已经得到了mixer的response,利用CacheResponse进行缓存（check_cache.cc）：需要先进行前置检查，确认response的合法性。然后检查response得到的的map和cache中是否有重复，如果没有重复，则**新的map和缓存元素cache_elem，返回cache_elem的状态。3. 签名计算在referenced.h定义了2种key, 一种是exact_key，是请求时实际存在的key;一种是absence key，是mixer 的adapter用到envoy却没有request的key,也就是缺省的key:计算签名的实现在referenced.cc中，这里首先在attributes map里检查absentkeys和exactkeys;是否都存在。用函数CalculateSignature计算签名，只对实际请求使用到的exactkeys的属性进行签名。计算得到的哈希值就可以用于的查找reference map。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

异常检测异常检测和踢出异常主机是一个动态检查上游主机是否正常工作，对不健康主机进行移除的过程。异常检测是一种被动健康检查，根据返回状态码来判断是否满足移除条件，最后将主机移除，首先我们来了解下驱逐算法。从上图中，可以看出来主机异常时首先会检查是不是有主机已经被移除了，如果没有被移除，那么直接移除这个不健康的主机，如果有主机被移除，则会率先检测是否超过移除阈值（maxEjectionPercent），如果超过这个阈值，则不会有任何行为发生，如果没超过这个阈值，那么则会将该主机移除一段时间，这段时间后则会将主机放入负载均衡池中供下游主机选择并分发请求。什么是Panic_Threshold？在负载均衡的过程中，Envoy只会考虑健康的上游主机。然而，如果健康主机的比例过低，Envoy将会无视健康状态分发所有的请求，这就是所谓的Panic Threshold，这个阈值默认为50%。这个设计的目的是防止大规模主机崩溃导致整个集群负载过高。Panic阈值需要和优先级一起配合工作。如果在某个优先级下健康主机数少了，Envoy将会将一些流量转移到低优先级的主机。如果在低优先级主机中，Envoy发现足够数量的的健康主机。Envoy将会无视Panic阈值。如果各个优先级健康程度都是100%。Envoy将忽略panic阈值而根据既定负载均衡算法路由流量。如果整体健康程度低100%，envoy认定没有足够数量健康的宿主机，但是他仍会给所有优先级的主机分发流量。但是如果给定优先级的健康宿主机比例低于了Panic阈值，这时候对于这部分优先级的宿主机，所有流量将会分发给这部分宿主机而不考虑他们的健康状态。我们定位到代码中来看下Panic Threshold是如何配置和工作的。如图，我们可以看出healthy_panic_threshold被默认设定为50%。在判断流程当中，Envoy先会拿到实时的panic_threshold值，然后通过计算健康的hosts数量与总hosts的数量比值来比较。在Envoy种有一个hostSourceToUse的方法，这个方法则是作为负载均衡的一部分，来将可用的hosts作为对象返回给调用方。其中包含很多种情况，我们在此只列举处在panic状态下的情况。如下图，若isGlobalPanic方法返回True也就是说集群内处在Panic模式，首先统计数据上会记录一次相应的数据，再次可用hosts列表将会包含所有存在的hosts而无视他们的健康状态。熔断的触发与实现Istio现在本身支持的四个参数是：连续错误个数，检测周期，主机移除比例以及基本移除时间。这四个参数看上去可以大致归类一下，连续错误个数和检测周期有点像是触发条件，但实际上真正的触发条件只有一个连续错误个数也就是consecutive_5xx。主机移除比例和基本移除时间，更像是熔断结果。我们接下来将这四个参数逐一分析下作用和实现。Consecutive_5xx:设置的是5xx以上错误的个数。Envoy中的putHttpResponseCode方法根据请求结果的http状态码来进行统计。如果返回状态码不高于500则会设定envoy统计数据中consecutive_5xx为0并且结束方法，若返回码高于500则需要进行两次判断。首先判断状态码是否是502，503以及504，如果是则会首先将gateway failure 统计数据自增1，而后判断是否触发了gateway failure的熔断，这部分和istio设定的参数关系不大，我们暂不展开。同样即便是Gateway failure或者返回值为500,501，consecutive_5xx这个统计数据也会自增1然后和设定的熔断条件进行比较（consecutive_errors）。如过consecutive_5xx和配置中的比较相等，则会触发相应的onConsecutive5xx方法，这个方法则是通知主线程，这个主机发生了触发了5xx错误熔断。有趣的是我们没展开的gateway failure达到触发条件也是会触发这个通知主线程函数，只不过参数上传入的是gateway failure这个参数。这个通知方法内会触发onConsecutiveErrorWorker，正是这个方法最重隔离主机。我们在分析隔离主机之前先来分析另一个参数MaxEjectionPercent，这个参数是最大主机隔离比例。在ejectHost这个方法中，首先会获得已配置的max_ejection_percent这个参数的值，若果没有配置则会引用默认的10%。在截图中，我们可以看出如果ejected_percent如果小于max_ejection_percent，就会对主机进行移除操作。此时我们分析下，如果我们设定为1%，即便移除后ejected_percent比例高于max_ejection_percent也会执行移除行为，类似向上取整。例如，10个主机，设定移除比例为11%，则最多会移除2个主机而不是1个。如果我们将max_ejection_percent设成0又会发生什么呢？是否像我们想象的那样一个都不移除因为毕竟0<0这个条件是不成立的。我在Istio中对应的destinationrule中将max_ejection_percent设置为0，但是发现还是会熔断1个。进而去查询istio-proxy的配置，发现max_ejection_percent并未配置下去，也就是说这个值采用的默认10%。在查询Istio中的代码applyOutlierDetection方法中找到。只有在maxEjectionPercent大于0的时候才会采用这个值，否则不会采用该值，也就是说如果我们配了0下去，这个数值不会转配到Envoy上，这也就解释了为什么Envoy中的configure_dump中并没有找到maxEjectionPercent所配置的0，并且还解释了为什么我们认为配置了0，还是会有上游主机熔断这个情况发生，因为使用了Envoy默认的10%。IntervalInterval限定的是检测周期，即多久会检测一次上游主机返回的Http code来断定是否需要对齐采取熔断策略。其实检测的这种行为都是由Detector来执行的，interval就是赋予detector的一个定时基准。 首先在armIntervalTimer方法中，启用定时器，定时器时间会读取配置的interval，如果没有这个配置则会启用默认的10s，如下图：当detector initialize的时候会直接启动这个定时器，也就是每过预设的一段时间detector会检查所有的主机的状态。若这个主机没有处在eject状态则不会做任何行为，如果这个主机处于被隔离的状态，则会检测他移除时间和现在时间相比，是否满足召回条件。上图中的checkHostForUneject就是专门检查主机状态和判断是否要召回的方法。介绍这个方法就要提到熔断的最后一个参数baseEjectionTime这个参数意味最小隔离时间，实际隔离时间为最小隔离时间与隔离次数的乘积。在checkHostForUneject这个方法中，如果主机的健康检查为健康则会直接return不作任何行为，如果主机的健康检查并不健康，则会读取baseEjectionTime而后通过计算与隔离次数的乘积得出应当被隔离的时间。当前时刻的时间会以参数的形式传递进来，now和主机最后一次移除相减得出实际隔离的时间。如果应当被隔离的时间小于等于实际被隔离的时间则会将主机召回并且重置统计参数，反之则不会有任何行为。异常点检查仍有许多istio未开放的参数，例如GatewayFailure、SuccessRate、最小健康实例数等。其实现上和负载均衡，健康检查等特性有较强的关联，许多细节仍需分析和实验。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

1、概述Mixer是Istio的核心组件，提供了遥测数据收集的功能，能够实时采集服务的请求状态等信息，以达到监控服务状态目的。1.1 核心功能•前置检查（Check）：某服务接收并响应外部请求前，先通过Envoy向Mixer（Policy组件）发送Check请求，做一些access检查，同时确认adaptor所需cache字段，供之后Report接口使用；•配额管理（Quota）：通过配额管理机制，处理多请求时发生的资源竞争；•遥测数据上报（Report）：该服务请求处理结束后，将请求相关的日志，监控等数据，通过Envoy上报给Mixer（telemetry）1.2 示例图2、代码分析2.1 Report代码分析本节主要介绍Report的详细流程（基于Istio release1.0.0版本，commit id为3a136c90）。Report是mixer server的一个接口，供Envoy通过grpc调用。首先，我们从mixer server的启动入口main函数看起：func main() {    rootCmd := cmd.GetRootCmd(os.Args[1:], supportedTemplates(), supportedAdapters(), shared.Printf, shared.Fatalf)    if err := rootCmd.Execute(); err != nil {       os.Exit(-1)    } }在rootCmd中，mixs通过server命令启动了mixer server，从而触发了runserver函数，在runserver中初始化（New）了一个server，我们一起看下newServer的函数，在这个函数中，与我们本节相关的内容就是Mixer初始化了一个grpc服务器NewGRPCServer。rootCmd.AddCommand(serverCmd(info, adapters, printf, fatalf)) func serverCmd(info map[string]template.Info, adapters []adapter.InfoFn, printf, fatalf shared.FormatFn) *cobra.Command {    sa := server.DefaultArgs()    sa.Templates = info    sa.Adapters = adapters    serverCmd := &cobra.Command{       Use:   "server",       Short: "Starts Mixer as a server",       Run: func(cmd *cobra.Command, args []string) {          runServer(sa, printf, fatalf)       },    }… … } func newServer(a *Args, p *patchTable) (*Server, error) {    grpc.EnableTracing = a.EnableGRPCTracing    s.server = grpc.NewServer(grpcOptions...)    mixerpb.RegisterMixerServer(s.server, api.NewGRPCServer(s.dispatcher, s.gp, s.checkCache)) }rootC在这个grpc的服务端中，定义了一个Report接口，这就是我们这节课主要关注的内容（可以看到Check接口也在此定义，我们下节再讲）func (s *grpcServer) Report(ctx context.Context, req *mixerpb.ReportRequest) (*mixerpb.ReportResponse, error) {    lg.Debugf("Report (Count: %d)", len(req.Attributes))    // 校验attribute是否为空，空则直接return    if len(req.Attributes) == 0 {       return reportResp, nil    }    // 若属性word为空，赋为默认值    for i := 0; i < len(req.Attributes); i++ {       iflen(req.Attributes[i].Words) == 0 {          req.Attributes[i].Words = req.DefaultWords       }    }    // 根据第一条attribute，生成proto包，proto包能跟踪一组attributes    protoBag := attribute.NewProtoBag(&req.Attributes[0], s.globalDict, s.globalWordList)    // 初始化，开始跟踪attributes各个条目中属性    accumBag := attribute.GetMutableBag(protoBag)    // 保存accumBag的增量状态    reportBag := attribute.GetMutableBag(accumBag)    reportSpan, reportCtx := opentracing.StartSpanFromContext(ctx, "Report")    reporter := s.dispatcher.GetReporter(reportCtx)    var errors *multierror.Error    for i := 0; i < len(req.Attributes); i++ {       span, newctx := opentracing.StartSpanFromContext(reportCtx, fmt.Sprintf("attribute bag %d", i))       // 第一个属性已经在创建proto包时创建，在此追踪所有attributes       if i > 0 {          if err := accumBag.UpdateBagFromProto(&req.Attributes[i], s.globalWordList); err != nil {             err = fmt.Errorf("request could not be processed due to invalid attributes: %v", err)             span.LogFields(otlog.String("error", err.Error()))             span.Finish()             errors = multierror.Append(errors, err)             break          }       }       lg.Debug("Dispatching Preprocess")       // 真正开始分发，预处理阶段       if err := s.dispatcher.Preprocess(newctx, accumBag, reportBag); err != nil {          err = fmt.Errorf("preprocessing attributes failed: %v", err)          span.LogFields(otlog.String("error", err.Error()))          span.Finish()          errors = multierror.Append(errors, err)          continue       }       lg.Debug("Dispatching to main adapters after running preprocessors")       lg.Debuga("Attribute Bag: \n", reportBag)       lg.Debugf("Dispatching Report %d out of %d", i+1, len(req.Attributes))       // 真正开始分发，将数据逐步加入到缓存中       if err := reporter.Report(reportBag); err != nil {          span.LogFields(otlog.String("error", err.Error()))          span.Finish()          errors = multierror.Append(errors, err)          continue       }       span.Finish()       // purge the effect of the Preprocess call so that the next time through everything is clean       reportBag.Reset()    }    reportBag.Done()    accumBag.Done()    protoBag.Done()    // 真正的发送函数，从缓存中取出并发送到adaptor    if err := reporter.Flush(); err != nil {       errors = multierror.Append(errors, err)    }    reporter.Done()    if errors != nil {       reportSpan.LogFields(otlog.String("error", errors.Error()))    }    reportSpan.Finish()    if errors != nil {       lg.Errora("Report failed:", errors.Error())       return nil, grpc.Errorf(codes.Unknown, errors.Error())    }    // 过程结束    return reportResp, nil }通过上述代码解读，我们了解了Report接口的工作流程，但此时我们还并不知道一个请求的状态是如何报给adaptor的，下面我们通过简要的函数串接，把这部分流程串起来：上述的预处理阶段Preprocess与上报阶段Report，最终都会调用到dispatch函数，仅通过不同的type来区分要做的事情；func (d *Impl) Preprocess(ctx context.Context, bag attribute.Bag, responseBag *attribute.MutableBag) error {    s := d.getSession(ctx, tpb.TEMPLATE_VARIETY_ATTRIBUTE_GENERATOR, bag)    s.responseBag = responseBag    err := s.dispatch()    if err == nil {       err = s.err    }    … … } func (r *reporter) Report(bag attribute.Bag) error {    s := r.impl.getSession(r.ctx, tpb.TEMPLATE_VARIETY_REPORT, bag)    s.reportStates = r.states    err := s.dispatch()    if err == nil {       err = s.err    }    … … }而dispatch函数中做了真正的分发动作，包括：1.遍历所有adaptor，调用adaptor中的函数，针对不同的adaptor生成不同的instance，并将instance缓存放入reportstatesvar instance interface{} if instance, err = input.Builder(s.bag); err != nil {    log.Errorf("error creating instance: destination='%v', error='%v'", destination.FriendlyName, err)    s.err = multierror.Append(s.err, err)    continue } type NamedBuilder struct {    InstanceShortName string    Builder           template.InstanceBuilderFn } InstanceBuilderFn func(attrs attribute.Bag) (interface{}, error) CreateInstanceBuilder: func(instanceName string, param proto.Message, expb *compiled.ExpressionBuilder) (template.InstanceBuilderFn, error) builder.build(attr) // For report templates, accumulate instances as much as possible before commencing dispatch. if s.variety == tpb.TEMPLATE_VARIETY_REPORT {    state.instances = append(state.instances, instance)    continue }2.将instance分发到所有adaptor，最终调用并分发到adaptor的HandleMetric函数中func (r *reporter) Flush() error {    s := r.impl.getSession(r.ctx, tpb.TEMPLATE_VARIETY_REPORT, nil)    s.reportStates = r.states    s.dispatchBufferedReports()    err := s.err    … … } func (s *session) dispatchBufferedReports() {    // Ensure that we can run dispatches to all destinations in parallel.    s.ensureParallelism(len(s.reportStates))    // dispatch the buffered dispatchStates we've got    for k, v := range s.reportStates {       s.dispatchToHandler(v)       delete(s.reportStates, k)    }    s.waitForDispatched() } func (s *session) dispatchToHandler(ds *dispatchState) {    s.activeDispatches++    ds.session = s    s.impl.gp.ScheduleWork(ds.invokeHandler, nil) } case tpb.TEMPLATE_VARIETY_REPORT:    ds.err = ds.destination.Template.DispatchReport(       ctx, ds.destination.Handler, ds.instances) type TemplateInfo struct {    Name             string    Variety          tpb.TemplateVariety    DispatchReport   template.DispatchReportFn    DispatchCheck    template.DispatchCheckFn    DispatchQuota    template.DispatchQuotaFn    DispatchGenAttrs template.DispatchGenerateAttributesFn } DispatchReport: func(ctx context.Context, handler adapter.Handler, inst []interface{}) error {    // Convert the instances from the generic []interface{}, to their specialized type.    instances := make([]*metric.Instance, len(inst))    for i, instance := range inst {       instances[i] = instance.(*metric.Instance)    }    // Invoke the handler.    if err := handler.(metric.Handler).HandleMetric(ctx, instances); err != nil {       return fmt.Errorf("failed to report all values: %v", err)    }    return nil }2.2 相关结构体定义Report接口请求体定义// Used to report telemetry after performing one or more actions. type ReportRequest struct {    // 代表一个请求中的属性    // 每个attribute代表一个请求动作，多个动作可汇总在一条message中以提高效率    //虽然每个“属性”消息在语义上被视为与消息中的其他属性无关的独立独立实体，但此消息格式利用属性消息之间的增量编码，以便大幅减少请求大小并改进端到端 效率。 每组单独的属性用于修改前一组。 这消除了在单个请求中多次冗余地发送相同属性的需要。    // 如果客户端上报时不想使用增量编码，可全量的发送所有属性.    Attributes []CompressedAttributes `protobuf:"bytes,1,rep,name=attributes" json:"attributes"`    // 所有属性的默认消息级字典.    // 这使得可以为该请求中的所有属性共享相同的字典，这可以大大减少整体请求大小    DefaultWords []string `protobuf:"bytes,2,rep,name=default_words,json=defaultWords" json:"default_words,omitempty"`    // 全局字典的词条数，可检测客户端与服务端之间的全局字典是否同步    GlobalWordCount uint32 `protobuf:"varint,3,opt,name=global_word_count,json=globalWordCount,proto3" json:"global_word_count,omitempty"` }3、总结Mixer中涉及很多缓存命中等用于优化性能的设计，本文仅介绍了Mixer中Report接口发送到adaptor的过程，一些性能优化设计，如protobag，dispatch缓存等内容，将会在后续文章中解析。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

使用Grafana插件进行监控是Istio提供的监控能力之一。Istio提供丰富的监控能力，Grafana插件在Istio对Prometheus支持的基础上，为用户提供基于网页仪表面板的可视化监控效果，使用户更加直观地查看到实时通信状况。在前面“如何使用Prometheus监控”的文章中，我们已经介绍istio如何通过它的核心组件Mixer收集用户的访问数据，配合一系列后端基础设施，转换为Prometheus后端接收的形式，提供日志、监控、配额、检查等核心运维功能。Istio基本安装支持Grafana插件，并默认结合Prometheus数据源和Istio Dashboard。Grafana配合Prometheus实现强大的监控功能，它将Prometheus得到的指标数据转换到可视化仪表界面上，从而帮助用户进行监控，并根据用户设置的机制支持报警服务。因此，Istio将Prometheus中存储的数据，通过Grafana直观清晰地展现出来。Grafana是一个开源的度量分析与可视化插件，可用作时间序列数据和应用程序分析，具有强大UI能力。它自称为适用于所有指标的分析平台，允许用户查询，可视化，提醒和理解应用指标，并基于数据驱动创建，探索和共享仪表板，提供一个更易于使用的可视化度量工具。Grafana的特点有：1. 形象化：拥有折线图和直方图等大量可视化选项，帮助用户精确地理解数据。2. 警报功能：支持用户自定义警报，直观地定义阈值，并通过Slack，PagerDuty等获得通知。3. 统一性：原生支持数十个数据库，在同一个仪表板中将它们整合在一起。4. 开源：完全开源，由社区支持，使用Hosted Grafana可轻松安装在任何平台上。5. 可拓展：在官方库中提供数百个仪表板和插件，并持续更新。基于Grafana提供的功能，Istio仪表板由三个主要部分组成：全局摘要视图、网格摘要视图和单个服务视图。接下来通过实践说明如何使用Grafana查看Istio的监控数据。前提：•集群中已安装Istio并部署应用程序•已安装Prometheus附加组件。1.安装Grafana插件通过Grafana.yaml文件安装，在Kubernetes环境中，执行如下命令： 2.验证Grafana插件是否已经在环境中运行3.通过Grafana的UI界面打开Istio Dashboard。在浏览器中访问http://localhost:3000/dashboard/db/istio-mesh-dashboard，可以实时看到当前集群中service的整体访问情况：包括service请求量、成功率、时延等。右上角可以选择统计时间和刷新频率。点击service的名称，可以查看当前service的实时访问数据，包括客户端和服务器的每秒请求量、通信成功率、时延、TCP带宽、请求数据大小等。用户也可以根据需求添加新的指标，来满足不同场景的监控需求。Istio通过结合Prometheus和Grafana的功能，满足用户对数据的实时监控。Grafana提供清晰美化的仪表面板，将Prometheus统计的实时数据进行合适的处理，使得监控具有实时性和过程化，帮助用户直观地对关键业务进行运维。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

大家都知道istio可以帮助我们实现灰度发布、流量监控、流量治理等功能。每一个功能都帮助我们在不同场景中实现不同的业务。那Istio是如何帮助我们实现监控和日志采集的呢？这里我们依然以Bookinfo应用程序作为贯穿此任务的示例程序。首先在集群中安装并部署Istio。1收集遥测数据创建一个新的YAML文件，用来保存Istio将自动生成和收集的新度量标准和日志流的配置。如下图所示：通过命令$ kubectl apply -f new_telemetry.yaml推送刚刚配置的YAML文件。然后去请求应用程序来生成流量，例如在本用例中就可以访问Bookinfo完成访问。接下来我们就可以验证是否采集到了刚刚的请求数据。在Kubernetes环境中，通过执行以下命令为Prometheus设置端口转发：$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &通过Prometheus UI查看新指标的值。执行对istio_double_request_count度量值的查询。Console选项卡中显示的表 包含类似于以下内容的条目：验证是否已创建日志流并正在为请求填充日志流。在Kubernetes环境中，搜索istio-telemetry pod的日志，如下所示：从打印的信息中，我们可以清楚的看到日志级别、生成时间、实例名称、访问组件名称等等信息。2遥测配置在上面的实践中，我们已经完成了Istio收集数据并打印日志的一个过程。那么Istio是如何做到的呢？其实我们已经给Istio做了配置，指示Mixer自动生成并上报服务网格中采集的metric信息和日志流。在这个配置中我们主要设置了mixer的三个功能：从Istio的属性中生成实例信息，比如在我们上面的实践中打印的metric和日志信息。创建出adapter适配器，可以帮助我们处理生成的实例。根据定义的规则向adapter发送实例信息。3metrics配置配置metrics是为了指示Mixer将metric发送到Prometheus。它使用三个模块来进行配置：实例配置、处理程序配置和规则配置。metric配置的模块定义了用于生成metric。此实例配置根据Envoy报告的属性（由Mixer自身生成）告诉Mixer 如何为任何给定请求生成metric。dimensions为每个实例指定一组维度。提供了根据查询的不同需求和方向对metric据进行分片，聚合和分析的方法。例如，可能需要在对应用程序行为进行故障排除时仅考虑对特定目标服务的请求。4日志配置日志配置指示Mixer将日志条目发送到stdout。它同样使用三个模块来进行配置：实例配置，处理程序 配置和规则配置。logentry配置的部分定义了用于生成日志条目实例。此实例配置告诉Mixer 如何 根据Envoy报告的属性为请求生成日志条目。severity参数用于指示任何生成的日志级别 logentry。在此示例中，使用了参数值"warning"。此值将由logentry 处理程序映射到支持的日志记录级别。Timestamp参数提供所有日志条目的时间信息。在此示例中，时间request.time由Envoy 提供的属性值提供。variables参数允许操作员配置每个值中应包含的值logentry。一组表达式控制从Istio属性和文字值到构成a的值的映射logentry。在此示例中，每个logentry实例都有一个名为latency使用属性值填充的字段response.duration。如果没有已知值response.duration，则该latency字段将设置为持续时间 0ms。stdio配置定义了处理程序命名newhandler。处理程序spec配置stdio适配器代码处理接收 logentry实例的方式。该severity_levels参数控制字段的logentry 值如何severity映射到支持的日志记录级别。这里，值"warning"被映射到WARNING日志级别。该 outputAsJson参数指示适配器生成JSON格式的日志行。rule配置定义一个新的规则命名newlogstdio。该规则指示Mixer将所有newlog.logentry实例发送到 newhandler.stdio处理程序。由于match参数设置为true，因此将对网格中的所有请求执行规则。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019