往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第5课《Istio xDS协议解析》01月03日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26935182、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】 第5课：Istio-xDS.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第4课《Istio灰度发布与技术实现》12月27日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26933482、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】第4课：Istio灰度发布与技术实现.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第3课《Istio Gateway设计与技术》12月20日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26719112、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】 第3课：Istio-Gateway.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第2课《Istio Pilot与服务发现》12月13日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26489782、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】 第2课：Istio 服务发现和Pilot的架构机制.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第1课《Istio架构与技术》12月6日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26243452、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】Istio入门级实训 第1课：Istio架构与技术v1.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

上一篇我们了解了如何控制入口流量，本文主要介绍在使用Istio时如何访问集群外服务，即对出口流量的管理。默认安装的Istio是不能直接对集群外部服务进行访问的，如果需要将外部服务暴露给 Istio 集群中的客户端，目前有两种方案：1. 配置ServiceEntry2. 配置global.proxy.includeIPRanges配置serviceEntry访问外部服务ServiceEntry用于将额外的条目添加到Istio内部维护的服务注册表中，从而让网格中自动发现的服务能够访问和路由到这些手动加入的服务。ServiceEntry 描述了服务的属性（DNS 名称、VIP、端口、协议以及端点）。这类服务可能是网格外的 API，或者是处于网格内部但却不存在于平台的服务注册表中的条目（例如需要和 Kubernetes 服务沟通的一组虚拟机服务）。配置ServiceEntry 也很简单，允许从网格内部访问HTTP,HTTPS,Mongo,TCP等协议的外部服务。下面分别列举了对外部TCP服务和HTTP服务的访问配置。具体的ServiceEntry的配置参数定义可参考：https://istio.io/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry外部TCP服务访问配置示例：apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: mysqlspec:  hosts:  - 192.168.0.245  ports:  - number: 3306    name: tcp    protocol: TCP外部HTTP服务访问配置示例：apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: foo-extspec:  hosts:  - foo.com  ports:  - number: 80    name: http    protocol: HTTP虽然社区推荐的方式是设置ServiceEntry来访问外部服务，但如果集群外需要访问的服务很多，一个个配置起来就很麻烦，也不方便管理。配置global.proxy.includeIPRanges如果使用HELM安装Istio, 可以在 Helm 中设置 global.proxy.includeIPRanges 变量为集群clusterIP的范围，然后进行安装。如果要对已经安装好的Istio修改配置，需要修改名为 istio-sidecar-injector 的 Configmap的“-i”的取值为集群clusterIP，稍后重启所有服务的pod,重新注入sidecar。然后你会看到重启后pod中的initContainers的-i参数值已经变为集群clusterIP的范围。这种方式使得只有集群内的IP通过sidecar，对外部服务的调用越过了 Istio sidecar proxy，让服务可以直接访问到对应的外部地址。相比配置ServiceEntry,这种方式简单对 Istio 进行全局配置，就可以直接访问所有外部服务。但缺点是不能治理集群外服务的访问流量，比如不能对集群外中间件服务进行熔断限流；而且需要用户了解云供应商特定的知识和配置。目前社区还没有完美的解决方案，可参考讨论：https://groups.google.com/forum/#!searchin/istio-dev/serviceentry%7Csort:date/istio-dev/0RCt7Jqrcg8/7Ylrr4TABQAJ

在Istio的世界里，如果想把外部的请求流量引入网格，你需要认识并会学会配置Istio Ingress Gateway什么是Ingress Gateway由于Kubernetes  Ingress API只能支持最基本的HTTP路由，使用Kubernetes Ingress资源来配置外部流量的方式不能满足需求。因此Istio v1alpha3 routing API引入新的Istio Ingress Gateway取代Kubernetes  Ingress。Gateway为HTTP/TCP流量配置了一个负载均衡，用于承载网格边缘的进入和发出连接。在同一个网格中可以有多个不同的gateway存在。这一规范中描述了一系列开放端口，以及这些端口所使用的协议、负载均衡的 SNI 配置等内容。用户可以利用标准的Istio 路由规则控制HTTP和TCP请求进入网格。从下图可以看到Istio gateway在整个网格中的使用情况：如何配置Gateway控制Ingress流量如果你已经安装好了bookinfo的应用，为了能在外部访问bookinfo中的productpage服务，只需要配置Gateway和相关的VirtualService。用一个简单的gateway配置一个负载均衡使访问bookinfo.com的外部http流量能够进入网格：apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata:  name: bookinfo-gatewayspec:  selector:    istio: ingressgateway  servers:  - hosts:    - bookinfo.com    port:      number: 80      name: http      protocol: HTTP为了配置相应的路由，需要为相同的host定义一个VirtualService 并且用配置中gateways的字段绑定到刚才创建的Gateway：apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: bookinfospec:  hosts:  - bookinfo.com  gateways:  - bookinfo-gateway # <---- 绑定gateway  - mesh # <----对内部通信进行流量控制  http:  - match:    - uri:        exact: /productpage    route:    - destination:        host: productpage        port:          number: 9080这样就达到了在外网开放productpage服务的目的。如何用HTTPS加密Gateway？我们也可以为服务启用TLS保护，以HTTPS的形式对网格外提供服务。首先需要使用工具生成客户端和服务器端的证书和密钥。然后使用密钥和证书作为输入，创建一个Secret。$ kubectl create -n istio-system secret tls istio-ingressgateway-certs --key key.pem --cert cert.pem接下来修改Gateway对象，为Ingress gateway开放一个443端口，用于提供HTTPS服务：apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata:  name: bookinfo-gatewayspec:  selector:    istio: ingressgateway  servers:  - hosts:    - bookinfo.com    port:      number: 80      name: http      protocol: HTTP   - hosts:    - "*"    port:      number: 443      name: https      protocol: HTTPS    tls:      mode: SIMPLE      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt      privateKey: /etc/istio/ingressgateway-certs/tls.key这样简单的配置就可以通过HTTPS协议访问bookinfo.com了。

在云原生的Cloud 2.0时代，容器技术解决了应用快速部署、上线、升级与弹性伸缩等运维效率问题，但应用运行时的灰度发布、流量治理与健康管理等方面仍存在较多难点。Istio是云原生Cloud Native生态的重要一环，通过提供完整的非侵入式的微服务治理解决方案，能够很好的解决云原生应用的管理、网络连接以及安全管理等应用网络治理问题。华为云Istio服务网格产品与CCE容器引擎深度整合，提供非侵入、智能流量治理的应用全生命周期管理方案，增强了华为云容器服务全栈能力，并在易用性、可靠性、可视化等方面进行了一系列增强，为客户提供开箱即用的上手体验。更多信息请点击：https://www.huaweicloud.com/product/cce.html

本视频以流量权重的灰度策略为例，演示了对当前版本从创建灰度版本到配置灰度策略这一系列灰度发布任务的步骤。并且结合流量监控拓扑图，以及性能检测图来演示一键切换流量及下线版本功能。点此观看：https://bbs.huaweicloud.com/videos/e4927c347e4a41da82feb9c8c0bf6b30

本视频结合流量监控拓扑图展示了Istio流量治理中的会话保持功能，可以看出组件默认的负载均衡算法为轮询算法，每个pod中的请求数基本接近或相同，当我们更改成回话保持，并且以HTTP header 中的Cookie来计算哈希值时，所有cookie值相同的请求全部都分发至同一实例。点此观看：https://bbs.huaweicloud.com/videos/cac01ce071434fe8b471ff4c86cb3caa

前言本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式。并基于Istio中埋点的原理解释来说明：为了输出一个质量良好的调用链，业务程序需根据自身特点做适当的修改，即并非官方一直在说的完全无侵入的做各种治理。另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式。Istio一直强调其无侵入的服务治理，服务运行可观察性。即用户完全无需修改代码，就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集。原文是这样描述的：Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality。调用链的埋点是一个比起来记录日志，报个metric或者告警要复杂的多，根本原因是要能将在多个点上收集的关于一次调用的多个中间请求过程关联起来形成一个链。Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制，还是挺复杂的。也有很多实现，用的比较多的如zipkin，和已经在CNCF基金会的用的越来越多的Jaeger，满足Opentracing语义标准的就有这么多。在Istio中大段的埋点逻辑在Sidecar中已经提供，业务代码不用调用以上这些埋点方式来创建trace，维护span等这些复杂逻辑，但是为了能真正连接成一个完整的链路，业务代码还是需要做适当修改。我们来分析下细节为什么号称不用修改代码就能搞定治理、监控等高级功能的Sidecar为什么在调用链埋点的时候需要改应用代码。调用详细服务调用关系简单期间，我们以Istio最经典的Bookinfo为例来说明。Bookinfo的4个为服务的调用关系是这样：调用链输出从前端入口gateway那个envoy上进行一次调用，到四个不同语言开发的服务间完成调用，一次调用输出的调用链是这样：简单看下bookinfo 中的代码，能看到并没有任何创建维护span这种埋点的逻辑，想也是，对于python、java、ruby、nodejs四种不同的语言采用不同的埋点的库在来实现类似的埋点逻辑也是非常头痛的一件事情。那我们看到这个调用链信息是怎么输出的？答案当然是应用边上的sidecar Envoy，Envoy对于调用链相关设计参照这里。sidecar拦截应用程序所有的进和出的网络流量，跟踪到所有的网络请求，像Service mesh的设计理念中其他的路由策略、负载均衡等治理一样，只要拦截到流量Sidecar也可以实现埋点的逻辑。埋点逻辑对于经过sidecar流入应用程序的流量，如例子中流入roductpage， details、reviews和ratings的流量，如果经过Sidecar时header中没有任何跟踪相关的信息，则会在创建一个span，Traceid就是这个spanId，然后在将请求传递给通pod的业务服务；如果请求中包含trace相关的信息，则sidecar从走回归提取trace的上下文信息并发给应用程序。对于经过sidecar流出的流量，如例子中gateway调用productpage，或者productpage调用链details和reviews的请求。如果经过sidecar时header中没有任何跟踪相关的信息，则会创建根span，并将该跟span相关上下文信息放在请求头中传递给下一个调用的服务，当然调用前会被目标服务的sidecar拦截掉执行上面流入的逻辑；当存在trace信息时，sidecar从header中提取span相关信息，并基于这个span创建子span，并将新的span信息加在请求头中传递。以上是bookinfo一个实际的调用中在proxy上生成的span主要信息。可以看到，对于每个app访问都经过Sidecar代理，inbound的流量和outbound的流量都通过Sidecar。图上为了清楚表达每个将对Sidecar的每个处理都分开表示，如productpage，接收外部请求是一个处理，给details发出请求是一个处理，给reviews发出请求是另外一个处理，因此围绕Productpage这个app有三个黑色的处理块，其实是一个Sidecar。为了不使的图上太凌乱，最终的Response都没有表示。其实图上每个请求的箭头都有一个反方向的response，在服务发起方的Sidecar会收到response时，会记录一个CR(client received)表示收到响应的时间并计算整个span的持续时间。解析下具体数据，结合实际调用中生成的数据来看下前面proxy埋点的逻辑会更清楚些。1.从gateway开始，gateway作为一个独立部署在一个pod中的envoy进程，当有请求过来时，它会将请求转给入口的微服务productpage。Gateway这个Envoy在发出请求时里面没有trace信息，会生成一个根span：spanid和traceid都是f79a31352fe7cae9，parentid为空，并记录CS时间，即Client Send；2.请求从入口gateway这个envoy进入productpage前先讲过productpage pod内的envoy，envoy处理请求头中带着trace信息，则记录SR,Server received，并将请求发送给Productpage业务容器处理，productpage在处理请求的业务方法中需要接收这些header中的trace信息,然后再调用Details和Reviews的微服务。Python写的 productpage在服务端处理请求时，先从request中提取接收到的header。然后再调用details获取details服务时，将header转发出去。可以看到就是提取几个trace相关的header kv其实就是重新构造一个请求发出去，可以看到请求中包含收到的header。3.从ProductPage出的请求去请求Reviews服务前，又一次通过同Pod的envoy，envoy埋点逻辑检查header中包含了trace相关信息，在将请求发出前会做客户端的调用链埋点，即以当前span为parent span，生成一个子span：即traceid：保持一致9a31352fe7cae9， spanid重新生成cb4c86fb667f3114，parentid就是上个span： f79a31352fe7cae9。4.请求在到达Review业务容器前，先经过Review的Envoy，从Header中解析出trace信息存在，则发送Trace信息给Reviews。Reviews处理请求的服务端代码中需要解析出这些包含trace的Header信息。reviews服务中java的rest代码如下：即在服务端接收请求的时候也同样会提取header。调用Ratings服务时再传递下去。其他的productpage调用Details，Reviews调用Ratings逻辑类似。不再复述。以一实际调用的例子了解以上调用过程的细节，可以看到Envoy在处理inbound和outbound时的埋点逻辑，更重要的是看到了在这个过程中应用程序需要配合做的事情。即需要接收trace相关的header并在请求时发送出去，这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子span并和原span进行关联，进而形成一个完整的调用链。否则，如果在应用容器未处理Header中的trace，则Sidecar在处理outbound的请求时会创建根span，最终会形成若干个割裂的span，并不能被关联到一个trace上。即虽然Istio一直是讲服务治理和服务的可观察性对业务代码0侵入。但是要获得一个质量良好的调用链，应用程序还是要配合做些事情。在官方的distributed-tracing 中这部分有描述：“尽管proxy可以自动生成span，但是应用程序需要在类似HTTP Header的地方传递这些span的信息，这样这些span才能被正确的链接成一个trace。因此要求应用程序必须要收集和传递这些trace相关的header并传递出去”• x-request-id• x-b3-traceid• x-b3-spanid• x-b3-parentspanid• x-b3-sampled• x-b3-flags• x-ot-span-context调用链阶段span解析：前端gateway访问productpage的proxy的这个span大致是这样：gateway上报了个cs，cr, productpage的那个proxy上报了个ss，sr。分别表示gateway作为client什么时候发出请求，什么时候最终受到请求，productpage的proxy什么时候收到了客户端的请求，什么时候发出了response。Reviews的span如下：  Details的span如下：可以看到productpage这个微服务和detail和reviews这两个服务的调用。一个细节就是traceid就是第一个productpage span的id，所以第一个span也称为根span，而后面两个review和details的span的parentid是前一个productpage的span的id。Ratings 服务的span信息如下：可以看到traceid保持一样，parentid就是reviews的spanid。当然在Jaeger里上报会是这个样子：根据一个实际的例子理解原理后会发现，应用程序要修改代码根本原因就是调用发起方，在Isito里其实就是Sidecar在处理outbound的时生成span的逻辑，而这个埋点的代码和业务代码不在一个进程里，没法使用进程内的一些类似ThreadLocal的方式（threadlocal在golang中也已经不支持了，推荐显式的通过Context传递），只能显式的在进程间传递这些信息。这也能理解为什么Istio的官方文档中告诉我们为了能把每个阶段的调用，即span，串成一个串，即完整的调用链，你需要修你的代码来传递点东西。当然实例中只是对代码侵入最少的方式，就是只在协议头上机械的forward这几个trace相关的header，如果需要更多的控制，如在在span上加特定的tag，或者在应用代码中代码中根据需要构造一个span，可以使用opentracing的StartSpanFromContext 或者SetTag等方法。调用链数据上报Envoy上报一个完整的埋点过程，除了inject、extract这种处理span信息，创建span外，还要将span report到一个调用链的服务端，进行存储并支持检索。在Isito中这些都是在Envoy这个sidecar中处理，业务程序不用关心。在proxy自动注入到业务pod时，会自动刷这个后端地址。如： 即envoy会连接zipkin的服务端上报调用链数据，这些业务容器完全不用关心。当然这个调用链收集的后端地址配置成jaeger也是ok的，因为Jaeger在接收数据是兼容zipkin格式的。Mixers上报除了直接从Envoy上报调用链到zipkin后端外，和其他的Metric等遥测数据一样通过Mixer这个统一面板来收集也是可行的。即如tracespan中描述，创建一个tracespan的模板，来描述从mixer的一次访问中提取哪些数据，可以看到trace相关的几个ID从请求的header中提取，而访问的很多元数据有些从访问中提取，有些根据需要从pod中提取（背后去访问了kubeapiserver的pod资源）最后在这个文章发出前，一直在和社区沟通，督促在更明晰的位置告诉大家用Istio的调用链需要修改些代码，而不是只在一个旮旯的位置一小段描述。得到回应是1.1中社区首页第一页what-is-istio/已经修改了这部分说明，不再是1.0中说without any changes in service code，而是改为with few or no code changes in service code。提示大家在使用Isito进行调用链埋点时，应用程序需要进行适当的修改。当然了解了其中原理，做起来也不会太麻烦。参照https://thenewstack.io/distributed-tracing-istio-and-your-applications/ https://github.com/istio/old_mixer_repo/issues/797 http://www.idouba.net/opentracing-serverside-tracing/ 

前言在前面的文章中，大家都已经熟悉了Istio的故障注入和流量迁移。这两个方面的功能都是Istio流量治理的一部分。今天将继续带大家了解Istio的另一项功能，关于请求超时的管理。首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理。看过idou老师前面文章的老司机应该都已经对Bookinfo这个实例驾轻就熟了，当然还存在部分被idou老师的文采刚吸引过来的新同学。下面先简单的介绍一下Bookinfo这个样例应用整体架构，以便我们更好地理解Istio是如何实现请求超时，对于老司机可以直接跳过这部分。Bookinfo应用由四个单独的微服务构成，用来演示多种 Istio 特性。这个应用模仿在线书店的一个分类，显示一本书的信息。页面上会显示一本书的描述，书籍的细节，以及关于这本书的一些评论。讲道理，Bookinfo这个实例确实比较轻量级，但是麻雀虽小五脏俱全。了解完样例应用以后，我们就可以动手实践了。当前的实验环境是基于已经提前安装好Kubernetes和Istio。请求超时的管理我们主要可以用来对一些特殊场景进行测试，比如故障注入等。第一步：首先我们到reviews组件中定义一个VirtualService的路由，如下第二步：在对ratings服务的调用中加入四秒钟的延迟，如下第三步：我们需要给productpage配置一个对外访问方式，然后用浏览器打开productpage对应的访问方式即可在页面看到Bookinfo的样例。这时应该能看到 Bookinfo 应用在正常运行（显示了评级的星形符号）。很多同学可能会好奇为什么我们明明设置了四秒钟的延时却没有出现跟自己设想的情况出现，别急让我们再接着往下走。第四步：我们重新再给ratings服务的调用中修改成2秒延时，如下第五步：这个时候我们再重新刷新Bookinfo的应用页面，将会看到出现的情况正如我们预想的那样，页面右侧显示评级的星形符号将会在整个页面异步延时大约2s的时间刷新出来，很多同学可能会思考是不是Istio的延时管理出了bug？莫慌，在本文的最后将会给您揭晓答案。第六步：我们继续尝试在reviews服务的请求加入一秒钟的请求超时，如下第七步：我们继续去刷新Bookinfo的web页面看看即将会发生什么？这时候应该就会看到reviews去调用ratings一秒钟就会返回，而不是之前的两秒钟，但是reviews的显示消失了。通过上面的实践，我们使用Istio为调用reviews的微服务的请求中加入了一秒钟的超时控制，覆盖了本身默认的15秒钟设置。页面刷新时，reviews 服务后面会调用 ratings 服务，使用 Istio 在对 ratings 的调用中注入了两秒钟的延迟，这样就让 reviews 服务要花费超过一秒钟的时间来调用 ratings 服务，从而触发了我们加入的超时控制。这样就会看到 Bookinfo 中由reviews生产的页面上没有出现 reviews 服务的显示内容，并且出现一串异常信息，出现这一信息的原因就是因为来自 reviews 服务的超时错误，如下：到这里，今天的请求超时管理是不是就结束了？当然没有，idou老师还记得第三步中的问题还没有给大家解答。这是因为Istio内部的服务中设置了更为严格的超时要求，如果有同学看了之前的文章测试了故障注入，就会发现 productpage 微服务在调用 reviews 微服务时，还有自己的应用级超时设置（三秒钟）。而我们这里用路由规则设置了一秒钟的超时。如果把超时设置为超过三秒钟（例如四秒钟）会毫无效果（正如我们第三步中设置了四秒）。

概要流量迁移是流量管理的一个重要功能。istio提供的流量管理功能将流量从基础设施扩展中解耦，支持动态请求路由，故障注入、超时重试、熔断和流量迁移等。流量迁移的主要目的是将流量从微服务的某一版本的逐步迁移至另一个版本，如在新旧版本之间进行流量切换。本文通过一个简单的用例介绍如何使用istio进行流量迁移。Figure 1 bookinfo示意图本文使用一个bookinfo的典型例子。通过istio的命令配置规则，将流量从reviews的版本v1逐步迁移到版本v3。在下面的例子中，应用基于权重路由配置，将百分百路由在reviews:v1版本的流量，逐步全部迁移到reviews:v3版本 。在操作前，需确保在当前环境下已经部署好正常运行的bookinfo，并提供对外访问地址。流量迁移的具体操作如下：1.将所有流量路由到reviews:V1版本。2.在浏览器中输入外部访问地址，访问bookinfo应用此时刷新页面，页面右侧的评论部分始终不会显示评级星号。这是因为 Istio 被配置为将 reviews 服务的所有流量都路由到了 reviews：v1 版本， 而该版本的服务不会访问带星级的 ratings 服务。3.把50%的流量从 reviews:v1 转移到 reviews:v3: 等待几秒钟确保新的规则生效，查看yaml文件，v1和v3的权重各为50%:4.刷新浏览器中的页面，能够看到约为50%的几率页面中出现带红色星级的评价内容。这是因为 v3 版本的 reviews 访问了带红色星级评级的 ratings 服务，但v1版本却没有。在istio目前的实现中，这种概率基于大量访问。增强访问规则中v3的权重，可以将更多的流量路由到v3版本，从而更多次看到带红色星级的评价。5.当v3版本可以稳定的提供服务时，用户可以选择将所有流量路由到V3版本上。等待几秒钟确保新的规则生效，查看yaml文件，所有流量走向V3版本：此时刷新浏览器界面，只会看到红色星级评价的页面。6.如不再使用当前路由规则，执行删除命令，删除路由规则：流量迁移是流量管理的一个重要功能，具有广泛的应用场景。在上述实践中，使用istio基于权重的路由方式将流量从reviews 服务的旧版本逐步迁移到新版本。使用istio进行流量迁移，两个版本的reviews服务可以分别扩容和缩容，有助于微服务的独立管理，不会影响版本之间的流量分发。而使用容器编排平台的部署功能进行版本迁移，实际是使用了实例扩容来对流量进行管理，两者原理并不相同。欢迎关注微信公众号【容器魔方】，如果您想加入容器交流技术群，添加管理员monicka，申请入群，容器圈的人看过来～

Istio技术与实践05：如何用istio实现流量管理1      Istio是什么？Istio 1.0版本于8月1号凌晨准点发布，核心特性已支持上生产环境，各大微信公众号、博客纷纷发文转载。那么Istio到底是什么？能解决问题什么？ 1、 Istio是Google继Kubernetes之后的又一开源力作，主要参与的公司包括Google，IBM，Lyft等，它提供了完整的非侵入式的微服务治理解决方案，解决微服务的管理、网络连接以及安全管理等应用网络治理问题2、 它无需修改任何代码就能够实现微服务的负载均衡，服务与服务之间的认证授权以及流量监控和治理。从整个基础设施角度上看，可以将它理解为PaaS平台上的一个面向微服务管理平台的补充。 2      Istio与KubernetesKubernetes提供了部署、升级和有限的运行流量管理能力；利用service的机制来做服务注册和发现，转发，通过kubeproxy有一定的转发和负载均衡能力。但并不具备上层如熔断、限流降级、调用链治理等能力. Istio则很好的补齐了k8s在微服务治理上的这部分能力，同时是基于k8s构建的，但不是像SpringCloud Netflix等完全重新做一套。Istio是谷歌微服务治理上的非常关键的一环。3      Istio流量管理能力介绍Istio，用于连接、保护、控制和观测服务。今天，我们就来谈谈Istio第一主打功能——连接服务。那么，便引出3个问题：Istio如何实现服务之间的连接？连接后具备哪些流量管理能力？如何告诉Istio发挥这些能力？ 3.1         Istio如何实现服务的连接？如上图所示的Istio架构图，让我们关注控制面的Pilot，它是Istio实现流量管理的核心组件。而在数据面，每个Service，都会被注入1个Proxy。Istio通过Pilot下发配置信息给数据面每1个Service的Proxy，从而通过这些Proxy，间接地控制每1个Service之间以及和外部的连接。Proxy通常采用另一个知名的开源项目Envoy来实现。1个Pilot和(N+N)个(Service+Proxy)组合，便形成了Service Mesh，即服务网格。有了这一套服务网格系统，对服务之间的流量进行管理，便不在话下。3.2      连接后具备哪些流量管理能力？从服务间的流量管理角度而言，Istio可以实现这4项功能：请求路由、服务发现和负载均衡、故障处理和故障注入。 3.2.1        请求路由如上图所示，Istio引入了服务版本的概念，可以通过(Current Version，Canary Version)2个版本对服务进行进一步的细分。基于这种划分，通过Pilot，你可以下发配置到Service A的Proxy，使得其95%的流量路由至Service B的Current版本，5%的流量路由至Service B的Canary版本。当然你也可以选择雨露均沾，各分50%流量，或者霸道总裁，让Canary版本占有100%的流量。 如上图所示，除了按照百分比在不同版本之间分发流量，你还可以按照请求内容，将请求路由至不同的版本。例如，你可以发布一个Canary版本，只让用着Macbook笔记本，且安装了windows操作系统，还使用着360浏览器的用户能够访问到。 这一切改变，都只需要你改动一个叫VirtualService的配置文件（详见下章），眨个眼的功夫，Istio就已经通过Pilot帮你把新的配置下发下去了。 3.2.2        服务发现和负载均衡如上图所示，服务网格存在3个生命周期的动态循环：服务注册、服务发现、负载均衡。通常kubernetes，mesos等容器管理平台已经提供了服务注册表，以跟踪服务的负载实例，所以Pilot能轻而易举地获知服务网格内的所有服务注册信息，并将这些信息告知所有服务里的Proxy，Proxy根据这些信息执行服务发现，并相应地动态更新其负载均衡池。一个服务通常有多个负载实例，Service A请求Service B时，可以配置不同的负载均衡模式：轮询、随机和带权重的最少请求。假设此时Service B的某个负载实例出现故障，因为Service A中的Proxy会定期地执行服务发现，从而能及时将故障实例从其负载均衡池里排出。 3.2.3        故障处理Envoy 提供了一套开箱即用，可选的故障处理功能，对应用中的服务大有裨益。这些功能包括：1.         超时2.         具备超时预算，并进行有限重试，重试之间的时长可抖动3.         并发连接数和上游服务请求数限制4.         对负载均衡池中的每个成员进行主动（定期）运行健康检查5.         细粒度熔断器（被动健康检查）- 适用于负载均衡池中的每个实例以Service A请求调用Service B为例。对于功能1。若Service B明确地知道10s以后的超时，必定会带来失败，那将超时时长缩短，使得Service A可以更快得知结果并作出应对，不失为一个明智之举。对于功能2。对超载的Service B来说，重试之间的抖动极大的降低了重试造成的影响，而超时预算确保Service A在可预测的时间范围内获得响应（成功/失败）。对于功能3。限制Service A或其他服务对Service B的连接数和请求数，可以使得Service B免于遭遇DDOS攻击，或承受过重的流量负担而崩溃。对于功能4和5。主动和被动健康检查的组合最大限度地减少了在负载平衡池中访问不健康实例的机会。当与平台级健康检查（例如由 Kubernetes 或 Mesos 支持的检查）相结合时，应用程序可以确保将不健康的负载实例快速地从服务网格中去除，从而最小化请求失败和延迟产生影响。总之，这些功能使得服务网格能够耐受故障节点，并防止本地故障导致的其他节点的稳定性下降。 3.2.4        故障注入虽然Proxy为在Istio上运行的服务提供了上节所言的大量故障处理机制，但测试整个服务网格所组成应用的端到端的故障恢复能力依然是必须的。错误配置的故障恢复策略（例如，跨服务调用的不兼容/限制性超时）可能导致应用程序中的关键服务持续不可用，从而破坏用户体验。Istio 能在不杀死负载实例的情况下，将协议特定的故障注入到网络中，在 TCP 层制造数据包的延迟或损坏。我们的理由是，无论网络级别的故障如何，应用层观察到的故障都是一样的，并且可以在应用层注入更有意义的故障（例如，HTTP经典的4xx和5xx错误代码），以检验和改善应用的韧性。运维人员可以为符合特定条件的请求配置故障，还可以进一步限制遭受故障的请求的百分比。可以注入两种类型的故障：延迟和中断。延迟是计时故障，模拟网络延迟上升或上游服务超载的情况。中断是模拟上游服务的崩溃故障。中断通常以 HTTP 错误代码或 TCP 连接失败的形式表现。依旧以Service A请求调用Service B为例。若给Service B设定了10s的延时或503中断，则Service A将至少10s后才能得到请求的响应或请求的响应为503错误，通过多种场景覆盖测试，可以得到Service A面对这些场景时的综合表现情况，从而做出针对性的改良，增加其韧性。3.3         如何告诉Istio发挥这些能力？Istio有4个配置文件，帮我们全方位地定制以上所有流量管理需求: VirtualService, DestinationRule, ServiceEntry和 Gateway:1.         通过配置VirtualService，可以实现请求路由的功能；2.         通过配置DestinationRule，可以实现服务发现和负载均衡、故障处理和故障注入的功能；3.         通过配置ServiceEntry，让服务网格内的服务，可以看到外面的世界；4.         通过配置Gateway，让服务网格的服务，可以被全世界看到；有了以上4**宝，我们对服务网格进行流量管理的所有需求，都可以被满足了。限于篇幅，让我们举3个简单的栗子：假设我们的服务网格存在1个服务explorer，只有1个v1版本；存在另1个服务helloworld，有v1,v2两个版本。①若要使得explorer发起的所有请求，以75%的概率走向helloworld的v1版本，以25%走向v2版本，只要配置如下两个文件VirtualService和DestinationRule，便可实现：apiVersion: networking.Istio.io/v1alpha3kind: VirtualServicemetadata:  name: helloworldspec:  hosts:    - helloworld  http:  - route:    - destination:        host: helloworld        subset: v1      weight: 75    - destination:        host: helloworld        subset: v2      weight: 25---apiVersion: networking.Istio.io/v1alpha3kind: DestinationRulemetadata:  name: helloworldspec:  host: helloworld  subsets:  - name: v1    labels:      version: v1  - name: v2    labels:      version: v2  ②如果helloworld内部需要通过访问www.google.com来获取一些信息，才能告诉explorer这个世界是怎么样的，需要配置如下2个文件ServiceEntry和DestinationRule：apiVersion: networking.Istio.io/v1alpha3kind: ServiceEntrymetadata:  name: googleapisspec:  hosts:  - "*.google.com"  ports:  - number: 443    name: https    protocol: http--- apiVersion: networking.Istio.io/v1alpha3kind: DestinationRulemetadata:  name: googleapisspec:  host: "*.google.com" ③如果helloworld需要被服务网格外，而不仅仅是explorer服务访问到，则需要配置如下2个文件Gateway和VirtualService：apiVersion: networking.Istio.io/v1alpha3kind: Gatewaymetadata:  name: helloworld-gatewayspec:    selector:      Istio: ingressgateway  servers:  - port:      number: 80      name: http      protocol: HTTP    hosts:    - 'helloworld.com'---apiVersion: networking.Istio.io/v1alpha3kind: VirtualServicemetadata:  name: bookinfospec:  hosts:    - 'helloworld.com'  gateways:  - helloworld-gateway  http:  - route:    - destination:        host: helloworld        port:          number: 9080  至此，我们做一个简单的总结：Istio提供的Pilot和Proxy，将成百上千个服务组成了一个服务网格，基于此，我们可以实现请求路由、服务发现和负载均衡、故障处理以及故障注入等流量管理能力，这一切，我们只需要通过对VirtualService, DestinationRule, ServiceEntry和 Gateway这4个资源做简单的配置，即可实现。 时冯七夕，正所谓，金风玉露一相逢，便胜却人间无数。K8S和Istio的碰撞，又会在Cloud Native的世界里，勾出怎样的天雷和地火呢？拭目以待。 

Idou老师教你学Istio：如何为服务提供安全防护能力之前，已为大家介绍过Istio第一主打功能---连接服务。凡是产生连接关系，就必定带来安全问题，人类社会如此，服务网格世界，亦是如此。今天，我们就来谈谈Istio第二主打功能---保护服务。那么，便引出3个问题：l  Istio凭什么保护服务？l  Istio具体如何保护服务？l  如何告诉Istio发挥保护能力？1      Istio凭什么保护服务？将单体应用程序分解为一个个服务，为大型软件系统的开发和维护带来了诸多好处，比如更好的灵活性、可伸缩性和可复用性。但这也带来了一些安全问题：l  为了抵御中间人攻击，需要对流量进行加密l  为了提供灵活的服务访问控制，需要 mTLS（双向的安全传输层协议）和细粒度的访问策略l  要审计谁在什么时候做了什么，需要审计工具Istio 尝试提供全面的安全解决方案来解决这3个问题。如上图所示，Istio 安全的三大目标是：l  默认安全（Security by default）：应用程序代码和基础结构，无需更改。l  深度防御（Defense in depth）：与现有安全系统集成，提供多层防御。l  零信任网络（Zero-trust network）：在不受信任的网络上，构建安全解决方案。为了实现这3个目标，Istio 安全功能提供了4大守护系统：l  强大的身份（Identity）系统l  健壮的策略（Policy）系统l  认证，授权和审计（AAA：Authentication，Authorization，Accounting）系统，用于保护服务和数据l  透明的 TLS 加密（Encryption）系统。就保护对象而言，Istio 安全系统可以抵御来自内部或外部的威胁，这些威胁主要针对服务网格内的端点（Endpoints），通信（Communication），平台（Platform）和数据（Data）。2      Istio具体如何保护服务？在安全方面，Istio具备3个远大的目标，配备了4大守护系统，那么它到底是通过怎样的架构实现这个目标的呢，又通过什么样的安全基础设施，和kubernetes配合呢？2.1      Istio安全架构如上图，与Istio的4大守护系统相对应，Istio 中涉及安全的组件有：l  Pilot ：将授权策略和安全命名信息分发给代理l  Proxy ：实现客户端和服务端之间的安全通信l  Citadel ：用于密钥和证书管理l  Mixer ：管理授权和审计由此可见，Pilot不仅负责流量规则和策略的分发，还负责安全相关策略的下发，有点像皇上的贴身太监，负责宣读圣旨；Proxy有点像各州属的州官，负责奉天承运；Citadel有点像玉玺和虎符，负责鉴真去假；Mixer有点像三省六部，负责授权审计。2.2      两个安全基本概念2.2.1        Identity身份（Identity）是几乎所有安全基础架构的基本概念。在服务和服务的通信开始前，双方必须用其身份信息交换凭证，以达到相互认证的目的。在客户端，根据安全命名（secure naming）信息，检查服务端的标识，以查看它是否是该服务的授权运行程序；在服务端，服务端可以根据授权策略（authorization policies）信息，确定客户端可以访问哪些数据，审计其在什么时间访问了什么，拒绝未授权客户端的访问。在 Istio 身份模型中，Istio 使用一流的服务标识来确定服务的身份。这为表示人类用户，单个服务或一组服务提供了极大的灵活性和粒度。在没有此类身份的平台上，Istio 可以使用可以对服务实例进行分组的其他身份，例如服务名称。不同平台上的 Istio 服务标识：l  Kubernetes: Kubernetes 服务帐户l  GKE/GCE: 可以使用 GCP 服务帐户l  AWS: AWS IAM 用户/角色 帐户l  On-premises (non-Kubernetes): 用户帐户，自定义服务帐户，服务名称，istio 服务帐户或 GCP 服务帐户。做个类比，京东和天猫都有自己的一套非常成熟的服务账户系统，淘宝只需要复用天猫的账户系统即可，无需重新开发一套，这样我们就可以用天猫的账号，直接登录淘宝。而Istio也更倾向于复用业界一流的服务账户系统，如Kubernetes和AWS的，但也可以自定义服务账户，并按需复用Kubernetes的账户系统。2.2.2  PKI Istio PKI（Public Key Infrastructure）建立在 Istio Citadel 之上，可为每个工作负载提供安全且强大的工作负载标识。Istio 使用 X.509 证书来携带 SPIFFE 格式的身份信息。PKI 还可以大规模自动化地进行密钥和证书轮换。Istio 支持在 Kubernetes pod 和本地计算机上运行的服务。目前，Istio为每个方案使用不同的证书密钥配置机制，下面试举例Kubernetes方案的配置过程：1.         Citadel 监视 Kubernetes apiserver，为每个现有和新的服务帐户创建 SPIFFE 证书和密钥对。 Citadel 将证书和密钥对存储为 Kubernetes secrets。2.         创建 pod 时，Kubernetes 会根据其服务帐户通过 Kubernetes secret volume 将证书和密钥对挂载到 pod。3.         Citadel 监视每个证书的生命周期，并通过重写 Kubernetes secret 自动轮换证书。4.         Pilot 生成安全命名信息，该信息定义了哪些服务帐户可以运行某个服务。接着Pilot 将安全命名信息传递给 Envoy。3      如何告诉Istio发挥保护能力？如上一章节所言，Istio基于控制面组件，引入了一流的服务账户系统，结合强大的PKI，实现了对服务网格的安全守护。同时，Istio也开放了接口，让我们可以进行精细化的配置，全方位满足我们对服务的安全需求。服务安全，总是离不开两个具体过程：认证（Authentication）和鉴权（Authorization）。Istio通过Policy和MeshPolicy文件，实现对认证相关功能的定义；通过RbacConfig、ServiceRole和ServiceRoleBinding文件，实现对鉴权相关功能的启用和定义。让我们举个几个通俗的例子来区分认证和鉴权：进火车站需要**和火车票，身份证可以证明你就是你，这是认证；火车票可以证明你有权上那趟火车，这是授权。又例如，你要访问自己淘宝的购物车，需要先登录，这是认证。你要访问朋友的购物车，就需要他的允许，这是授权。再例如，有经验的朋友能发现浏览器经常会面对两个错误码：401和403。通常而言，401就是未登录的意思，需要认证；403就是禁止访问的意思，需要授权。3.1      认证Istio 提供两种类型的身份认证：l  传输身份认证，也称为服务到服务身份认证：对直连客户端进行验证。Istio 提供双向TLS作为传输身份认证的全栈解决方案。我们可以轻松启用此功能，而无需更改服务代码。这个解决方案：l  为每个服务提供强大的身份认定，以实现跨群集和跨云的互操作性。l  保护服务到服务通信和最终用户到服务通信。l  提供密钥管理系统，以自动执行密钥和证书生成，分发和轮换。l  来源身份认证，也称为终端用户身份认证：对来自终端用户或设备的原始客户端请求进行验证。Istio 通过 JSON Web Token（JWT）、Auth0、Firebase Auth、Google Auth 和自定义身份认证来简化开发者的工作，使之轻松实现请求级别的身份认证。在这两种情况下，Istio 都通过自定义 Kubernetes API 将身份认证策略存储在 Istio 配置存储（Istio config store）中。Pilot会在适当的时候进行同步，为每个Proxy更新其最新状态以及密钥。此外，Istio 支持在许可模式下进行身份认证，以帮助我们理解策略变更前后，服务的安全状态是如何变化的。3.1.1        认证架构我们可以使用身份认证策略，为 Istio 网格中接收请求的服务指定身份认证要求。我们使用 .yaml 文件来配置策略，策略将保存在 Istio 配置存储中。在任何策略变更后，Pilot 会将新策略转换为适当的配置，下发给Envoy，告知其如何执行所需的身份认证机制。Pilot 可以获取公钥并将其附加到 JWT 进行配置验证。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们安装到负载 Pod 中，以进行双向 TLS。本文多次提到双向TLS认证，让我们理解一下其在Istio里的实现。Istio 通过客户端和服务端各自配备的Envoy进行通信，也就是说，客户端和服务端的流量，是被各自的Envoy接管了的。对于客户端调用服务端，遵循的步骤是：1.         Istio 将出站流量从客户端重新路由到客户端的本地 Envoy。2.         客户端 Envoy 与服务端 Envoy 开始双向 TLS 握手。在握手期间，客户端 Envoy 还执行安全命名检查，以验证服务证书中提供的服务帐户是否有权运行目标服务。3.         客户端 Envoy 和服务端 Envoy 建立了一个双向的 TLS 连接，Istio 将流量从客户端 Envoy 转发到服务端 Envoy。4.         授权后，服务端 Envoy 通过本地 TCP 连接将流量转发到服务端的服务。3.1.2        认证策略配置和其他的 Istio 配置一样，可以用 .yaml 文件的形式来编写认证策略，然后使用 Istioctl 二进制工具进行部署。如下图的配置，通过配置Policy文件，对reviews服务进行了传输身份认证的配置，要求其必须使用双向TLS做认证。apiVersion: "authentication.Istio.io/v1alpha1"kind: "Policy"metadata:  name: "reviews"spec:  targets:  - name: reviews    peers:  - mtls: {}3.2      授权Istio 的授权功能，也称为基于角色的访问控制（RBAC），为 Istio 服务网格中的服务提供命名空间级别，服务级别和方法级别的访问控制。它的特点是：l  基于角色的语义，简单易用。l  包含服务到服务和终端用户到服务两种授权模式。l  通过自定义属性灵活定制授权策略，例如条件，角色和角色绑定。l  高性能，因为 Istio 授权功能是在 Envoy 里执行的。3.2.1        授权架构上图显示了基本的 Istio 授权架构。和认证的生效过程一样，运维人员使用.yaml文件指定 Istio 授权策略。部署后，Istio 将策略保存在Istio Config Store中。Pilot 会一直监视 Istio 授权策略的变更，如果发现任何更改，它将获取更新的授权策略，并将 Istio 授权策略分发给与服务实例位于同一 pod 内的 Envoy 代理。每个 Envoy 代理都运行一个授权引擎，该引擎在运行时授权请求。当请求到达代理时，授权引擎根据当前授权策略评估请求上下文，并返回授权结果ALLOW或DENY。3.2.2        授权策略配置我们可以使用 RbacConfig 启用授权策略，并使用ServiceRole和ServiceRoleBinding配置授权策略。RbacConfig是一个网格维度的单例，其固定名称值为default，也就是说我们只能在网格中配置一个RbacConfig实例。与其他 Istio 配置对象一样，RbacConfig被定义为Kubernetes CustomResourceDefinition (CRD)对象。在RbacConfig中，运算符可以指定mode值，它可以是：l  OFF：禁用 Istio 授权。l  ON：为网格中的所有服务启用了 Istio 授权。l  ON_WITH_INCLUSION：仅对包含字段中指定的服务和命名空间启用 Istio 授权。l  ON_WITH_EXCLUSION：除了排除字段中指定的服务和命名空间外，网格中的所有服务都启用 Istio 授权。在以下示例中，为default命名空间启用了 Istio 授权，。apiVersion: "rbac.Istio.io/v1alpha1"kind: RbacConfigmetadata:  name: default  namespace: Istio-systemspec:  mode: 'ON_WITH_INCLUSION'  inclusion:    namespaces: ["default"]针对服务和命名空间启用授权后，我们还需要配置具体的授权策略，这通过配置ServiceRole和ServiceRoleBinding实现。与其他 Istio 配置对象一样，它们同样被定义为CRD对象。ServiceRole定义了一组访问服务的权限。ServiceRoleBinding向特定对象授予 ServiceRole，例如用户，组或服务。ServiceRole 和 ServiceRoleBinding 组合规定了： 允许谁在哪些条件下做什么，具体而言：l  谁指的是 ServiceRoleBinding 中的 subject 部分。l  做什么指的是 ServiceRole 中的 rule 部分。l  哪些条件指的是我们可以在 ServiceRole 或 ServiceRoleBinding 中使用Istio Attributes指定的 condition 部分。让我们再举一个简单的例子，如下图，ServiceRole和 ServiceRoleBinding的配置规定：将所有用户（user=“*”）绑定为（products-viewer）角色，这个角色可以对products这个服务发起GET或HEAD请求，但是其限制条件是请求头必须包含version，且值为v1或v2。apiVersion: "rbac.Istio.io/v1alpha1"kind: ServiceRolemetadata:  name: products-viewer  namespace: defaultspec:  rules:  - services: ["products"]methods: ["GET", "HEAD"]    constraints:    - key: request.headers[version]      values: ["v1", "v2"]---apiVersion: "rbac.Istio.io/v1alpha1"kind: ServiceRoleBindingmetadata:  name: binding-products-allusers  namespace: defaultspec:  subjects:  - user: "*"  roleRef:    kind: ServiceRole    name: "products-viewer" 至此，我们做个简单的总结：单体应用程序拆分成成千上百个服务后，带来了安全问题，Istio尝试在由服务组成的服务网格里，加入了一套全栈解决方案。这套方案里，Istio默默处理了大部分安全基础设施，但也暴露了认证和授权两个功能让用户进行自定义配置。我们通过Policy、MeshPolicy以及RbacConfig、ServiceRole、ServiceRoleBinding就可以完成对认证和授权环节所有功能的配置，而不需要侵入地改动任何服务的代码。