大家都知道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

使用Prometheus进行监控是Istio提供的监控能力之一。Istio提供丰富的监控能力，为网格中的服务收集遥测数据。Mixer是负责提供策略控制和遥测收集的Istio组件。Istio通过Mixer实现流量监控的基本流程如下图：每个pod内有一个service和proxy，Envoy容器实现proxy功能，对流入和流出pod的流量进行管理、认证和控制。Mixer则主要负责访问控制和遥测信息收集。当某个服务被请求时，首先会请求istio-policy服务，来判定是否具备访问资格，若具备资格则放行，反之则请求不会被下发到服务。这一切的访问信息，都会被记录在Envoy中，之后会上报给Mixer作为原始数据，并生成具体的监测指标。Figure 1 mixer拓扑Mixer配合一系列后端基础设施，为运维提供丰富而深入的控制和监测，并且不额外增加服务开发人员负担。后端提供用于构建服务的支持功能，访问控制系统，遥测捕获系统，配额执行系统，计费系统等。Mixer开放了Istio服务与不同的基础设施后端的交互能力，隔离用户程序和各个基础设施后端的实现细节。Istio通过丰富组件的边界交互，减少系统复杂性，消除服务代码中的策略逻辑并将控制权交给运维。Mixer处理不同基础设施后端的是通过使用通用插件模型实现的。每个插件都被称为 Adapter，Mixer通过它们可对接到不同的基础设施后端，这些后端可提供日志、监控、配额、ACL检查等核心运维功能。这些功能灵活可控，你既可以定制新的基础设施后端，也可以完全禁用这些功能。Figure 2 mixer 及其适配器Prometheus是一款开源的监控和告警系统，将所有信息存储为时间序列数据，实现监控方式，实时分析系统运行的状态、执行时间、调用次数等，以找到系统的热点，为性能优化提供依据。Prometheus系统自2016年加入CNCF，以其灵活的检索语言，高效的数据存储方式以及多维度的数据模型被越来越多的人使用。Istio自0.8版本开始默认将Prometheus包含在内，Mixer支持对接到Prometheus监控设施的Adapter。用户可以通过查询service或pod看到Prometheus的运行状态和地址。也可以通过简洁明了的Prometheus的UI界面查看监测数据。接下来通过实践说明如何使用Prometheus查询Istio指标，使用基于网页的界面进行指标查询。1.验证Prometheus是否在集群中运行（默认情况下Prometheus的设置包含在istio.yaml和istio-demo-auth.yaml中）。在安装istio的Kubernetes环境中，执行如下命令：2.通过浏览器访问http://localhost:9090/graph，在网页顶部的“Expression”输入框中，输入要查询的命令，Prometheus能够根据输入自动提示可输入的命令，然后单击 Execute 按钮。1) 查询所有服务的请求总数：istio_request_bytes_count2) 查询指定服务的请求总数：（如查询对 productpage 服务的所有请求的总数）istio_request_bytes_count{destination_service="productpage.default.svc.cluster.local"}3) 查询指定时间范围内对指定服务的请求总数：（如查询过去5分钟内对所有 productpage 服务的请求率） istio_request_bytes_count {destination_service=~"productpage.*", response_code="200"}[5m])如下图，Prometheus在图形界面中也提供了直观的显示。将鼠标放到图中的折线可以看到请求的详细信息，详细信息中的每一项都可以作为选定参考指标的特性。 同时Istio支持和允许用户自己定义新的遥测数据，用户可以自定义需要的监控指标进而再使用Prometheus查看监控数据结果。Istio通过mixer组件无缝对接Prometheus监控服务，满足用户对路由网关、应用服务、资源使用以及自定义指标等实时监控，帮助用户在使用istio的过程中，快速实现对关键业务的运维需求。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

使用 Istio 可以很方便地实现速率限制。本文介绍了速率限制的使用场景，使用 memquota\redisquota adapter 实现速率限制的方法，通过配置 rule 实现有条件的速率限制，以及速率限制的原理。1使用场景在许多场景下都需要对服务进行速率限制。一种常见的场景是防止来自外部服务的过度调用（如爬虫）。另一种常见的场景是调用某些收费的外部服务，但是提供了免费配额，可以使用速率限制确保只使用免费的配额。2环境准备在 Kubernetes 集群上部署 Istio部署 Bookinfo 示例应用配置 Bookinfo 应用各个微服务的 destinationrule 和 virtualservice3使用 Istio 实现速率限制1. 创建 memquota 或 redisquota 类型的 handler一个请求到达某个服务时，一般会发生两次对 Mixer 的调用，一次是前置检查，一次是遥测报告。每一次调用，Mixer 都需要调用一个或多个适配器。因此需要定义处理速率限制的 handler，可以在 memquota 和 redisquota 这两种类型的 handler 中选择一种：上面的 memquota handler 定义了三种不同的速率限制模式：如果没有 override 能够匹配，默认每秒限制 500 次请求；如果请求的 destination 是 reviews，每 5 秒限制 1 次请求；如果请求的 destination 是 productpage，每 5 秒限制 1 次请求。然后创建 memquota handler：上面使用的是 memquota handler，memquota handler 绑定在 Mixer 进程上，没有持久化，无 HA 能力，因此并不适合生产使用。可以用 redisquota handler 替代 memquota handler 实现持久化：上面定义了一个 redisquota handler，定义的三种速率限制模式和上文的 memquota handler相同。其中 rateLimitAlgorithm 字段可以选择 ROLLING_WINDOW 或者 FIXED_WINDOW，两种算法的介绍见下文“速率限制的原理”一节。然后创建该 redisquota handler： 2. 创建 quota template 的 instance不同的适配器需要不同的数据块作为输入来进行处理。例如日志适配器需要日志输入，指标适配器需要指标输入，认证适配器需要凭据输入。适配器在请求时消费的数据是由 Mixer 的 template 来描述的，通过 quota template 可以定义 memquota\redisquota handler 需要的 dimension 数据。编辑 quota_instance.yaml 内容如下：上面的 quota template 定义了四种可以被 memquota\redisquota 使用的 dimension，可以 override 匹配到某些属性的请求。比如 destination 会被置为 destination.labels["app"], destination.service.host 和 "unknown" 中第一个不为空的值。然后执行如下命令创建 quota template 的 instance：3. 创建 quota ruleRule 负责通知 Mixer，哪个 instance 应该在什么时候发送给哪个 handler。编辑 quota_rule.yaml 内容如下：上面这条 rule 告诉 Mixer 使用上面创建的 handler.memquota\handler.redisquota handler，并将上面创建的 requestcount.quota instance 构建的对象传递给该 handler。然后执行如下命令创建上述 rule：4. 创建 QuotaSpecQuotaSpec 对象用于定义每次请求消费的 quota instance 的数量。编辑 quota_spec.yaml 内容如下：在上面的 QuotaSpec 中，我们定义每次请求消费 1 个 quota instance。然后执行如下命令创建上述 QuotaSpec：5. 创建 QuotaSpecBindingQuotaSpecBinding 对象用于将上面创建的 QuotaSpec 绑定到需要应用限流的服务上。通过给不同的服务绑定不同的 QuotaSpec，可以实现对于调用代价较高的服务，每个请求消费较多的 quota instance。编辑 quota_spec_binding.yaml 内容如下：上面的 QuotaSpecBinding 将 productpage 绑定到名为 request-count 的 QuotaSpec 上。需要注意的是，如果服务的 namespace 和 QuotaSpecBinding 不同，需要指定 namespace。然后执行如下命令创建上述 QuotaSpec：6. 在浏览器中刷新 productpage 页面因为限制了 productpage 只允许每 5 秒 2 个请求，所以如果持续刷新页面，会看到如下的 RESOURCE_EXHAUSTED:Quota is exhausted for: requestcount。4有条件的速率限制上面只使用了 dimensions 来定义速率限制的条件，还可以在 rule 中使用任意属性来定义规则。例如，在某些场景下，我们不需要对已经登录的用户进行速率限制。在 bookinfo 示例中，我们通过设置 cookie user=<username> 来识别已经登录的用户。修改 quota_rule.yaml 内容如下：然后执行如下命令修改 rule：修改后的 rule 使得当且仅当 user=<username> cookie 为空时才应用 memquota 或者 redisquota 适配器，从而保证了已登录的用户免受速率限制。以“kokokobe”用户登录，并持续刷新页面，每次都可以刷出下图所示页面。登出之后持续刷新页面，会再一次看到下图所示的 RESOURCE_EXHAUSTED:Quota is exhausted for: requestcount。5速率限制的原理速率限制有 Token Bucket、Fixed Window、Rolling Window 等常见的算法实现。Token Bucket 算法每经过固定的时间间隔会产生一个 token，如果此时 bucket 没有满，则产生的 token 可以被放入 bucket 中。当请求到来时，如果此时 bucket 中有足够多的 token，则可以同时取走多个；如果此时 bucket 中 token 不够，则拒绝服务。Fixed Window 算法每个时间间隔对应一个计数器，每当有请求到来，如果此时计数器未达到配额的限定值，则计数器加 1，否则拒绝服务。当进入下一个时间间隔时，计数器失效被重置。该算法的缺点在于不能保证在任意的时间间隔内，速率都被限制在配额以下。即如果请求集中在计数器失效的时间点附近，则在该时间点附近的时间间隔内，速率最大能达到配额的两倍。Rolling Window 算法通过对上一个时间间隔请求数和当前时间间隔已处理的请求数进行加权，实现了对任意时间间隔的速率的估算。图片来自https://blog.cloudflare.com/counting-things-a-lot-of-different-things/如上图所示，在上一分钟内处理了 42 个请求，当前这一分钟已经过去了 15 秒，处理了 18 个请求，则当前这一分钟的速率可以估算为：rate = 42 * ((60-15)/60) + 18 = 42 * 0.75 + 18 = 49.5如果使用 memquota adapter，默认使用亚秒级分辨率的 rolling window 实现速率限制。如果使用 redisquota adapter，可以配置使用 Rolling Window 算法或者 Fixed Window 算法。如果在该时间间隔内的请求数超过了 maxAmount，Mixer 会返回 RESOURCE_EXHAUSTED 信息给 Envoy，Envoy 再返回 HTTP 429 StatusTooManyRequests 给调用者。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

大家都知道istio可以帮助我们实现灰度发布、流量监控、流量治理等一些功能。每一个功能都帮助我们在不同场景中实现不同的业务。那么其中比如流量监控这种复杂的功能Istio是如何让我们在不同的应用中实现呢？因篇幅所限，我们今天重点介绍Istio里面实现这些功能的关键技术--调用链跟踪。虽然 Istio 代理能够自动发送 Span 信息，但还是需要一些辅助手段来把整个跟踪过程统一起来。应用程序应该自行传播跟踪相关的 HTTP Header，这样在代理发送 Span 信息的时候，才能正确的把同一个跟踪过程统一起来。在Istio中的Sidecar里面已经实现了埋点的逻辑，业务代码不用调用以上这些埋点方式来创建trace，维护span等这些复杂逻辑，但是为了能真正形成一个完整的链路，业务代码在某些场景下还是需要做适当修改。1服务调用关系为了便于大家理解，我们以Istio最经典的Bookinfo为例来说明。Bookinfo的4个微服务的调用关系如下图所示，在这里我们不就具体阐述了。然后我们要弄明白几个问题：什么是调用链跟踪？为什么要用调用链跟踪？调用链跟踪顾名思义就是服务与服务之间相互调用的时候，来记录下调用的关系。比如用户发起请求访问Ingress，这是入口。然后Ingress——>Productpage——>Reviews——>Ratings这是一个完整的调用链，而这个过程中的谁调用谁的关系就是调用链跟踪。当我们获得了服务之间调用的关系，就可以对流量状况进行一个微观监控。比如当我们发现流量异常时，通过调用链跟踪我就可以清晰的知道流量异常出现在哪一块服务调用中，又或是提取调用中的响应时延等等。2如何实现在上文中，我们说Istio要实现调用链跟踪需要去修改用户的代码，其实就是采用一种被称为埋点的方法。在Istio中对于经过sidecar流出的流量，如例子中ingress调用productpage，或者productpage调用details和reviews的请求。如果经过sidecar时header中没有任何跟踪相关的信息，则会创建根span，并将该根span相关上下文信息放在请求头中传递给下一个调用的服务，当然调用前会被目标服务的sidecar拦截掉执行上面流入的逻辑；当存在trace信息时，sidecar从header中提取span相关信息，并基于这个span创建子span，并将新的span信息加在请求头中传递。如下所示就是需要在请求头中传递的字段信息，包括traceid、spanid等。被调用的服务接收trace相关的header并在请求时发送出去，这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子span并和原span进行关联，进而形成一个完整的调用链。否则，如果在应用容器未处理Header中的trace，则Sidecar在处理outbound的请求时会创建根span，最终会形成若干个割裂的span，并不能被关联到一个trace上。这就是为何需要部分的修改应用代码。x-request-idx-b3-traceidx-b3-spanidx-b3-parentspanidx-b3-sampledx-b3-flagsx-ot-span-context3业务场景最后让我们看一下实现了调用链跟踪的一些具体场景，如下图所示：从上图中可以看到在某种场景下的所有应用、实例名称、状态以及总调用耗时、traceID等信息，这些信息给我们提供了最直观的调用数据，点击查看调用关系，将会看到更加详细的调用链信息。如下图：从这张图中，我们可以监测到不同服务间更加详细的调用数据。如该调用链包含三个应用，最大调用深度为2，不同应用直接调用的耗时以及应用状态等，这些都是在实际场景中非常具有价值的信息。设想在一个大规模高并发以及巨大访问量的业务中，如果我们可以对业务的监测可以细化到这种程度，那么我们的业务将会处于更加安全的保护中。通过以上场景以及扩展信息我们就可以清晰的看到服务之间调用的具体信息，例如请求状态、响应时延等等，而这些信息都是通过调用链跟踪获取的。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

istio的授权功能，也称为基于角色的访问控制（RBAC），它为istio服务网格中的服务提供命名空间级别、服务级别和方法级别的访问控制。基于角色的访问控制具有简单易用、灵活和高性能等特性。本文介绍如何在服务网格中为服务进行授权控制。   ·前置条件·•安装istio的k8s集群，启用认证功能、双向TLS认证•部署bookinfo示例应用下面基于bookinfo应用实例具体介绍如何启用授权并配置访问控制策略：1. 创建service accout，启用访问控制我们在service account的基础上启用访问控制，为了给不同的微服务授予不同的访问权限，需要建立不同的service account，在本例中：创建Service account: bookinfo-productpage，并用它部署 productpage；创建 Service account：bookinfo-reviews，并用它部署 reviews（其中包含 reviews-v2 和 reviews-v3 两个版本）。清理所有现存RBAC规则：此时，用浏览器打开bookinfo的productpage页面，会看到：2. 启用Istio授权使用 RbacConfig 对象启用 Istio Authorization：此时，bookinfo的productpage页面，会看到：3. 设置命名空间级的访问控制这一策略创建service-viewer 的 ServiceRole，通过constraints指定了允许访问的服务范围:创建 ServiceRoleBinding 对象，用来把 service-viewer 角色指派给所有 istio-system 和 default 命名空间的服务:用浏览器打开bookinfo的productpage页面，会看到完整的页面：4. 配置服务级的访问控制清除命名空间级的访问控制下面在bookinfo中逐步为服务加入访问：1） 允许到productpage服务的访问这条策略中创建了名称为 productpage-viewer的ServiceRole，它允许到 productpage 服务的读取访问，并创建命名为 productpage-viewer的 ServiceRole，将 productpage-viewer 角色赋予给所有用户和服务此时，用浏览器打开bookinfo的productpage页面，会显示 Error fetching product details 和 Error fetching product reviews 的错误信息：出现上述现象是因为我们还没有给productpage授权访问details 和 reviews 服务，下面两步修复这个问题。2） 允许对details和reviews服务的访问details-reviews-viewer：允许对 details 和 reviews 服务进行只读访问bind-details-review: 把 details-reviews-viewer 角色授予给productpage 服务的 Service account3） 允许对ratings服务的访问ratings-viewer: 允许对ratings服务的访问rind-ratings: 将ratings-viewer角色指派给bookinfo-reviews这个Service account此时，用浏览器打开bookinfo的productpage页面，会看到完整的页面。总结：通过上述步骤，我们可以快捷的启用授权功能，并灵活定制访问控制策略来满足不同的安全访问需求。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

根据Istio官方报告，Observe（可观察性）为其重要特性。Istio提供非侵入式的自动监控，记录应用内所有的服务。我们知道在Istio的架构中，Mixer是管理和收集遥测信息的组件。每一次当请求到达的时候，Envoy会调用Mixer进行预检查，在请求处理完毕后也会将过程上报给Mixer。今天我们会结合开源监控插件（Jaeger）与嵌入Istio服务的应用性能管理服务来为大家展示部分Istio的全景监控能力。1JaegerIstio结合Jaeger使用可以解决端到端的分布式追踪问题。2017年Jaeger成为了CNCF（Cloud Native Computing Foundation）的一员。Jaeger主要可以使用在微服务的架构上，来完成分布式的上下文广播，事物监控，根因分析，服务依赖关系的分析等功能。Jaeger界面简洁，颜色柔和，无过多复杂得元素在内。清晰地在左侧配置项栏中列出了用户需要设置的配置，用户需要选择想观察的服务，观察的时间段以及一些附加功能配置。点击find trace按钮后，所有符合预设条件的Trace都会被展示出来。单机某个Trace则会进入他的调用详情中。比如从上图中的这个调用，我们就可以看出来当请求抵达productPage时，会产生两个子访问，一个去调用了details组件，另一个则去调用了reviews组件。每个Span则是体现了调用父子关系和调用持续时间，简明扼要的提供了用户关心的信息。对于收集此类监控信息，设定合适的采样频率是十分有必要的，这样一来避免了过度监控造成的数据冗余和性能影响，另一方面也避免了监控样本过少，不能足够支撑分析的情况。调整采样率可以通过Helm模板中的values.yaml对其中的traceSampling进行修改，再进行服务网格的创建。对于运行中的服务网格，则可以对deployment istio-pilot进行修改。Kubectl edit deployment istio-pilot 搜索并修改PILOT_TRACE_SAMPLING这个属性。2APM（应用性能管理）华为云Istio服务为了方便用户了解自己应用和集群的工作状态，也在服务界面添加了监控的功能。与其他监控插件相同的是，用户依然不需要对自己代码进行任何改动和重构，直接可以使用监控服务。首先在监控概览页面可以看到应用状态，异常相应统计，时延统计以及应用拓扑图。应用概览展示的是应用的就绪状况，是否有应用未就绪或异常状态可以直观反映，异常相应和超长请求时延则展示租户下所有组件中异常数较大和时延较高的几个组件。拓扑图则展示的是应用中的访问，调用关系，以及相应的平均时延。除此之外，每个组件可以展开，看到组件中实例的工作状态。对于因延时影响或者是中断相应会有相应的连线表达方式。点击拓扑图上任意一个组件亦或是点击异常相应与超长请求时间上的任何一个组件都可以进入流量概况页。流量概况页主要是以数字的形式展示流量情况。针对该组件的请求总数，错误技术，平均时延和最大时延都会以数据的形式直接传递给使用者。流量监控中也包含了调用链信息。相比Jaeger，这里的调用链多了持久化的一层，可以查阅时间段更宽的数据。随着微服务趋势的发展，越来越多的应用在架构阶段就已经解耦成多个组件，越是对于组件多的应用，监控信息就显得越发重要。精准，正确的监控信息不仅能够第一时间帮助运维人员发现并定位应用中的问题，而且还能够通过既往的数据来支持运维人员进行资源的合理分配与调度。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

一、负载均衡算法原理与实战负载均衡算法（load balancing algorithm）,定义了几种基本的流量分发方式，在Istio中一共有4种标准负载均衡算法。•Round_Robin： 轮询算法，顾名思义请求将会依次发给每一个实例，来共同分担所有的请求。•Random： 随机算法，将所有的请求随机分发给健康的实例•Least_Conn: 最小连接数，在所有健康的实例中任选两个，将请求发给连接数较小的那一个实例。接下来，我们将根据以上几个算法结合APM（应用性能管理）的监控拓扑图来实战下。·实战环境·华为云开启了Istio服务网格的CCE集群 官方最佳时间Bookinfo应用，并且给Reviews配置了五个实例开通APM测试服务（免费）我们知道如果用户不进行任何配置，负载均衡算法默认是轮询算法，所以我们现将负载均衡算法设为随机（Random）。步骤 1在云容器引擎界面点击应用管理，选择流量治理。步骤 2右侧出现拓扑图，在上面的选项栏中选择集群，命名空间，应用。然后点击我们想配置的组件，这里是 reviews，右侧则会出现流量治理的界面。步骤 3在负载均衡算法中，由Round_Robin 改为random。步骤 4在左侧导航栏中选择流量治理下面的流量监控，再选择相应的集群，命名空间，应用。多访问几次，或者后台写脚本一直curl productpage，可以从拓扑图中观察数据。步骤 5当有流量时，鼠标右键点击reviews组件，选择展开选项这时我们可以看到所有实例的被分发情况。实例编号12345访问次数6238394252其余负载均衡算法基本一样，我们在步骤上不做赘述，直接展示结果。轮询算法：实例编号12345访问次数4747484647二、会话保持原理与实战会话保持（Session Affinity）是通过设定的某个指标来计算，将哈希值相同的请求分发至某个固定的实例来处理。现在支持基于HTTP头部设定指标和Cookie键值设定指标。我们当前还在轮询算法中，所以所有请求会均匀的分配给所有实例，设置会话保持基于HTTP请求头部，并且设为Cookie。我们后台curl的请求cookie设为了一个固定值，理论上来讲所有的请求都会分发至同一个pod。我们依然采用流量监控，展开reviews组件来观察分发情况。根据图中不难看出，所有的请求都分发至了第二个实例，因为cookie一致所以保持了这个会话链接。三、故障注入原理与实战故障注入（Fault Injection）为开发和测试人员主动向系统中引入故障，来观察系统在非正常状态下的行为，是一种可靠性，稳定性的验证手段。Istio也支持了非侵入式的注入故障，分为时延故障和中断故障。故障注入的步骤大致相同在流量治理页面的下方，选择时延故障，并且输入触发百分比和延时时间。然后再打开productpage 手动刷新几次，能明显感觉到延迟有了变化，当然也可以打开F12调试界面，观察网络请求状况，不难发现productpage请求耗时都在2秒上下。这时候我们打开流量监控界面观察下发现productpage与reviews受到了明显的影响。红色表示请求状态极差，虚线表示是由时延造成的。接下来我们来测试并且使用中断故障，我们对details配置中断故障，中断返回码设为501。配置完后，我们再去手动访问几次productpage来观察下结果。发现现在的右侧details已经报了error我们回到流量监控图，可以看到组件之间的访问情况。在给ratings配置了中断故障后，原本调用ratings组件的reviews组件，已经无法和ratings通信了。本文以华为云istio服务结合APM服务为大家演示了流量治理中的主要功能。希望大家在今后的开发和测试中可以利用istio灵活的非侵入的治理功能提高开发和测试的效率。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

Istio为用户提供基于微服务的流量治理能力。Istio允许用户按照标准制定一套流量分发规则，并且无侵入的下发到实例中，平滑稳定的实现灰度发布功能。基于华为云的Istio服务网格技术，使得灰度发布全流程自动化管理：• 灰度版本一键部署，流量切换一键生效• 配置式灰度策略，支持流量比例、请求内容（Cookie、OS、浏览器等）、源IP• 一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化Istio服务网格为应用治理提供的灰度发布功能，稳定高效地推动企业应用的迭代升级。用户无需使用繁琐的命令行配置，而是通过清晰友好的图形界面，轻松直观地完成灰度发布整个过程(如图1)。灰度发布内置金丝雀、蓝绿、A/B Testing等典型灰度发布功能，下面以金丝雀发布为例介绍如何使用Istio服务进行一次灰度发布。Figure 1 灰度版本发布流程假设，用户已经拥有了一个稳定运行的应用，以Bookinfo程序为例，用户通过【应用管理】下的【应用部署】功能已经部署了Bookinfo程序(如图2)。Figure 2 Bookinfo示例程序1. 创建金丝雀发布任务点击【应用管理】下的【灰度发布】栏，可以查看进行中的发布任务、历史发布任务和创建新的发布任务(如图3)。点击“金丝雀发布”卡片上的“创建”按钮，跳转至“创建发布任务”界面，选择灰度发布组件reviews，填写发布任务名称、版本号和版本描述，并点击“创建”按钮。Figure 3 灰度发布任务卡片Figure 4 创建灰度发布任务2. 部署灰度版本灰度版本会继承当前线上版本的所有配置，如资源限制、环境变量等，并默认会选择一个最新的镜像版本。用户只需最少量的输入即可，如编辑待部署的灰度版本的实例数量和实例的镜像配置(包括镜像版本和镜像高级设置)，点击“部署灰度版本”按钮，一键式部署版本(如图5)。Figure 5 部署灰度版本3. 查看灰度版本状态当用户配置好灰度策略后，可以通过界面实时监控灰度版本的状态，具体包括实例的健康监控信息、性能监控信息和启动日志。待版本启动进度达到100%时，“配置灰度策略”按钮被激活，可点击跳转至下一步。Figure 6 查看灰度版本状态4. 配置灰度策略金丝雀发布支持两种策略：“基于流量比例发布”和“基于请求内容发布”。“基于流量比例发布”，用户可以为两个版本更改实例数和流量配比，可根据需求将灰度版本的流量配比逐步增大并进行“策略下发”(如图7)。Figure 7 基于流量比例发布“基于请求内容发布”目前支持基于Cookie内容，自定义Header，操作系统和浏览器的规则约束，只有满足规则约束的访问流量才可访问到灰度版本(如图8)。Figure 8 基于请求内容发布策略下发后，多次访问Bookinfo应用，可以看到灰度版本与默认版本的访问界面交替出现(如图9和图10)。Figure 9 Bookinfo默认版本访问界面 Figure 10 Bookinfo灰度版本访问界面5. 监测灰度运行状态点击进入“监测灰度运行状态”，通过查看原版本和灰度版本的实时流量监控(请求每秒访问次数、请求时延)和健康监控状态(POD状态、CPU使用率和物理内存使用率)来确定灰度策略的执行情况(如图11)。Figure 11 监测灰度运行状态如果用户认为灰度版本可以上线使用，可以在灰度版本卡片内点击“接管所有流量”按钮。用户确保灰度版本可以稳定运行并决定替换原版本，则点击原版本卡片的“版本下线”按钮，结束灰度发布，完成版本升级(如图12)。此后如果再次访问Bookinfo应用，则只会访问到灰度版本(如图10)。Figure 12 在历史记录中查看已完成的发布任务华为Istio服务的灰度发布功能，使您的灰度发布过程更加轻松易行。这个一站式的发布平台，通过内置的灰度发布流程引导用户非常方便地完成一个灰度发布的过程，使得原本繁琐又略带危险性的操作变得非常容易。更多内容，欢迎体验华为云Istio服务。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

众所周知，HTTPS是用来解决 HTTP 明文协议的缺陷，在 HTTP 的基础上加入 SSL/TLS 协议，依靠 SSL 证书来验证服务器的身份，为客户端和服务器端之间建立“SSL”通道，确保数据运输安全。而Istio的双向TLS也用来保证数据传输安全。那么，Istio的双向TLS是如何与HTTPS服务一起工作的呢？下面通过实例演示Istio的双向TLS是如何与HTTPS服务一起工作的，包括三个部分：•在没有 Istio sidecar 的情况下部署 HTTPS 服务•关闭 Istio 双向 TLS 认证情况下部署 HTTPS 服务•部署一个启动双向 TLS 的 HTTPS 服务。对于每个部署，请求连接到此服务并验证其是否有效。环境准备•未启用双向TLS的安装了Istio的k8s集群•安装openssl，生成证书和configmap通过openssl生成key和证书：从给定的公私钥对创建TLS secret：使用kubectl创建Configmap：1.没有部署sidecar创建一个不部署sidecar的基于nginx的HTTPS服务，并创建一个部署sidecar的sleep应用来调度nginx检查上述pod是否正常运行在pod正常运行时，从sleep应用的istio-proxy容器内访问HTTPS服务：可以看到，nginx能正常访问。2. 部署sidecar并禁用双向TLS删除上一步创建的未部署sidecar的HTTPS服务，并用sidecar部署它查看pod是否正常启动： 在pod正常运行时，从istio-proxy容器运行，可以看到，nginx能正常访问：3. 部署sidecar，并启用双向TLS通过配置网格级别的认证策略启用全局双向TLS，首先配置网格认证策略：配置目的地规则：此时，网格中的所有服务已经开启了双向TLS功能，从sleep容器中访问nginx是正常的：从sleep容器中访问时，工作流为“sleep→sleep-proxy→nginx-proxy→nginx” ，此时，整个过程是7层流量，在sleep-proxy到nginx-proxy之间有一个L4双向TLS加密。而在istio-proxy中运行时，它无法工作：此时，工作流为“sleep-proxy→nginx-proxy→nginx”，nginx-proxy会从sleep-proxy中获得双向TLS流量，但是sleep-proxy无法提供客户端证书，因此，它不起作用。总结：通过上述演示，可以了解到，当istio sidecar使用HTTPS服务部署时，无论是否启用双向TLS功能，代理自动从L7降到L4，所以，它不会终止原来的HTTPS通信。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

使用 Istio 可以很方便地实现微服务间的访问控制。本文演示了使用 Denier 适配器实现拒绝访问，和 Listchecker 适配器实现黑白名单两种方法。使用场景有时需要对微服务间的相互访问进行控制，比如使满足某些条件（比如版本）的微服务能够（或不能）调用特定的微服务。访问控制属于策略范畴，在 Istio 中由 Mixer 组件实现。Mixer拓扑图，来源官方文档如上图所示，服务的外部请求会被 Envoy 拦截，每个经过 Envoy 的请求都会调用 Mixer，为 Mixer 提供一组描述请求和请求周围环境的属性。Mixer 进行前置条件检查和配额检查，调用相应的 adapter 做处理，并返回相应结果。Envoy分析结果，决定是否执行请求或拒绝请求。从而实现了策略控制。环境准备在 Kubernetes 集群上部署 Istio部署 Bookinfo 示例应用配置 Bookinfo 应用各个微服务的 destinationrule 和 virtualservice。其中 reviews 服务的 destinationrule 和 virtualservice 配置如下：按上图配置后，对于 reviews 服务的请求，来自用户 “kokokobe” 的请求会被路由到v2 版本，其他用户的请求会被路由到 v3 版本。使用 Denier 适配器实现简单的访问控制使用 Istio 对微服务进行访问控制时，可以使用 Mixer 中的任何属性。这是一种简单的访问控制，实现基础是通过 Mixer 选择器拒绝某些条件下的请求。比如，上文所述的 Bookinfo 应用中的 ratings 服务会被多个版本的 reviews 服务访问。下面的示例中我们将会切断来自 v3 版本的 reviews 服务对 ratings 服务的调用。1. 用浏览器打开 Bookinfo 的 productpage（http://$GATEWAY_URL/productpage）如上图所示，如果用 “kokokobe” 的用户登录，能看到每条 review 下面的黑色星星，说明此时 ratings 服务被 v2 版本的 reviews 服务调用。从上面两张图可以看出，如果使用其他用户登录（或未登录），能看到每条 review 下面的红色星星，说明此时 ratings 服务被 v3 版本的 reviews 服务调用。 2. 创建 denier 适配器，拒绝来自 v3 版本的 reviews 服务对 ratings 服务的调用编辑 mixer-rule-deny-label.yaml 内容如下：这也是Mixer的adapter的标准配置格式，一般需要配置三种类型的资源：1. 配置一组 handler。Handler是配置好的 adapter 的实例，adapter 封装了 Mixer 和特定基础设施后端之间的接口。2. 基于 template 配置一组 instance。Instance 定义了如何将 Envoy 提供的请求属性映射到 adapter 的输入。3. 配置一组规则。这些规则描述了何时调用特定的 handler 及 instance。在这里其中定义了一条名为 denyreviewsv3 的规则，一个 denier 类型的 handler，一个checknothing 类型的模板的实例。在 denyreviewsv3 规则中，方框内的条件表达式匹配的条件是：来自 reviews 服务，version 为 v3 ，目标为 ratings 服务的请求。这条规则使用 denier 适配器拒绝来自 v3 版本的 reviews 服务的请求。这个 denier 适配器会拒绝符合上述规则的请求。可以预先指定 denier 适配器的状态码和消息，如方框中所示。然后执行如下命令创建上述规则的 denier 适配器：3. 在浏览器中刷新 productpage 页面如果已经登出或者使用不是 “kokokobe” 的用户身份登录，不再看到红色星星，因为v3版本的 reviews 服务对 ratings 服务的访问已经被拒绝了。相反，如果使用 “kokokobe” 用户登录，仍然能够看到黑色星星。因为该用户使用的是 v2 版本的 reviews 服务，不符合拒绝的条件。通过listchecker适配器实现黑白名单Istio 也支持基于属性的黑名单和白名单。下面的白名单配置和上一节的 denier 配置是等价的，拒绝来自 v3 版本的 reviews 服务的请求。 1. 删除上一节配置的 denier 规则2. 在登出状态下浏览 Bookinfo 的 productpage（http://$GATEWAY_URL/productpage）此时能看到红星图标。在完成下述步骤之后，只有在使用 “kokokobe” 的身份登录之后才能看到星形图标。3. 创建包含 v2 版本白名单的 listchecker 适配器编辑 whitelist-handler.yaml 内容如下：通常会在外部维护黑白名单的列表，然后指定 providerUrl 参数进行异步获取。在这个例子中，我们使用 overrides 字段提供一个静态的黑白名单列表。然后运行如下命令创建 listchecker 适配器：4. 创建一个 listentry 模板的实例Listentry 模板可以用来判别一个字符串是否存在于一个列表中，本例中我们使用它来判别版本标签是否存在于白名单中。编辑 appversion-instance.yaml 内容如下：然后运行如下命令：5. 为 ratings 服务启用 whitelist 检查功能编辑 checkversion-rule.yaml 内容如下：然后运行如下命令：6. 在浏览器中刷新 productpage 页面如果已经登出或者使用不是 “kokokobe” 的用户身份登录，看不到星形图标；如果使用 “kokokobe” 用户登录，仍然能够看到黑色星星。总结通过上述示例，可以发现使用 Istio 实现微服务间的访问控制非常方便。既可以使用denier 适配器实现简单的访问控制，也可以通过listchecker 适配器实现较复杂的黑白名单。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

在Istio中，双向TLS是传输身份验证的完整堆栈解决方案，它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信，以及提供密钥管理系统。本文阐述如何在不中断通信的情况下，把现存Istio服务的流量从明文升级为双向TLS。使用场景在部署了Istio的集群中，使用人员刚开始可能更关注功能性，服务之间的通信配置的都是明文传输，当功能逐渐完善，开始关注安全性，部署有sidecar的服务需要使用双向TLS进行安全传输，但服务不能中断，这时，一个可取的方式就是进行双向TLS的迁移。下面通过实例演示如何进行双向TLS的迁移。环境准备• 已经部署好Istio的集群，没有启用双向TLS• 创建三个命名空间，分别是 foo、bar 以及 legacy• 在 foo、bar 中分别部署注入 Istio sidecar 的 httpbin 以及 sleep 应用，在legacy中部署未注入sidecar的sleep应用检查部署情况可以看到，从任意一个命名空间选一个sleep应用，发送http请求到httpbin.foo，都能请求成功。这个时候，使用的是明文传输。检查系统中的认证策略和目标规则：可以看到，系统中在foo、bar 以及 legacy命名空间下没有认证策略和目标规则。下面开始通过配置服务端和客户端来升级传输过程：1. 配置服务器向服务端注入以下策略：上图策略中，模式为PERMISSIVE，这个模式让服务器能够同时接收明文和双向TLS流量，具体使用哪种方式由实际配置决定。再次验证网络通信，可以看到所有请求都成功，目前使用的还是明文的方式。2. 配置客户端通过设置下图所示DestinationRule，为服务端添加目的地规则：这些规则生效后，客户端sleep.foo 和 sleep.bar 就会开始使用双向 TLS 和 httpbin.foo 进行通信了，而sleep.legacy因为没有注入sidecar，因此不受DestinationRule 配置影响，还是使用明文来和httpbin.foo通信。通过发送请求验证上述分析，可以看到三个应用都访问成功：3. 锁定使用双向TLS（可选）通过上述方式，可以把不同的客户端和服务端之间流量都迁移到双向TLS。当系统中的流量都迁移完毕，并且希望所有应用之间都通过双向TLS进行安全传输，我们可以将应用间的传输锁定为双向TLS。具体操作方式如下：将配置的认证策略mtls的模式修改为STRICT，这样，服务端就只运行使用双向TLS这一种方式接收流量。锁定之后，再发送请求验证通信，可以看到，sleep.legacy 的请求失败，这是因为sleep.legacy没有注入sidecar，无法进行双向TLS传输。总结：通过上述演示，可以了解到，将服务通信从明文流量传输迁移到双向TLS传输的过程是十分方便的，可以根据服务的实际需求按需配置，不会对服务的正常通信产生任何影响。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

Istio利用k8s的探针对service进行流量健康检查，有两种探针可供选择，分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁，这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。当所有容器都ready时被视为pod此时ready。比如说用这种信号来控制一个后端服务，当pod没有到ready状态时，服务会从负载均衡被移除。使用场景：liveness探针被用来移除异常的pod，不重启pod就无法恢复的应用常使用liveness探针。比如前文提到的死锁，进程会一直处于活跃状态，k8s会认为正常并继续发送流量。但使用liveness探针之后会发现应用已经不再处理请求，继而重启异常pod。readiness探针被用来控制流量进入pod。比如应用程序需要加载一个大的文件或者需要启动后进行一些配置。但默认只要容器进程启动完成就会有流量发送过来。使用readiness探针会一直等待直到完成所有加载或配置再让流量进入。两种探针的配置相似，区别在于使用livenessProbe还是readinessProbe字段探针配置参数：探针有以下几个参数：initialDelaySeconds：容器启动之后到启动探针之间的时延periodSeconds：探针的循环执行时间，最小单位为1秒timeoutSeconds：探针超时时间，默认值1秒successThreshold: 成功阈值数，失败之后最小的连续成功信号数，liveness必须是1failureThreshold：失败阈值数，当探针失败之后，在放弃之前k8s尝试重新执行探针次数,如果是liveness探针放弃意味着重启容器，readiness探针意味着pod标记为unready，默认值为3次。HTTP探针还有以下额外的参数：host: 所连接主机名，默认值是pod IPscheme: HTTP或者HTTPSpath： 访问HTTP 服务器的路径httpHeaders: 访问HTTP的报头port:访问容器的端口探针可以进行三种操作：命令行：在容器中执命令行操作，exit 0为成功状态HTTP请求：向容器发送HTTP GET请求，如果返回值为200-400之间为成功状态TCP 请求：向指定端口发送TCP请求，如果该端口开放监听，则为成功下面我们来演示以下健康检查的操作：命令行操作首先准备busybox镜像，设置如下的yaml配置文件：在配置文件中我们设置了一个liveness探针，在容器启动之后的5s,每隔5s去执行一下访问/tmp/healthy这个文件的操作，如果操作成功返回0，则为容器健康，如果返回值不为0， 会重启容器。当容器启动之后会执行：touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600前30s会建立/tmp/healthy文件，30s之后删除，此时访问会返回错误.使用kubectl create -f ./your-exec-liveness.yaml建立pod在30s之内通过kubectl describe pod liveness-exec来查看pod状态，为健康：在30s之后查看pod的状态，发现无法访问文件，返回不健康：之后查看pod的状态，pod的重启次数为1，此时通过liveness探针检测到不健康状态已经重启pod。如果使用readiness探针，需要修改上文your-exec-liveness.yaml的红框字段：通过与上文相同的方法，在30s之前查看pod的状态，为ready:在30s之后查看pod状态，readiness探针将应用容器置为unready, ready的容器是istio-proxy：可以看到readiness探针并不会重启容器。HTTP请求另一种使用liveness探针的方法是HTTP GET请求，可以用来监测网页的运行状态，我们用google liveness镜像来进行演示：这里我们让HTTP的服务器/healthz路径前10s返回200 的OK状态，10s之后返回状态500。设置如下的配置文件：liveness探针会向容器的8080端口发送请求访问/healthz， 在容器启动3s之后每隔3s发送一次。我们建立pod并查看pod的运行状态kubectl describe pod liveness-http：会发现10s之后 liveness探针监测到了返回值是500，状态标记为不健康。TCP请求两种探针还可以共同使用，下面以TCP请求为例，TCP和HTTP连接类似。使用google的goproxy镜像，该镜像会在8080端口开放TCP socket连接，使用如下的配置文件：我们用探针去访问8000端口查看pod状态；此时理论上应该无法连接：可以看到readiness探针会每隔10s监测，无法访问时会将pod置于unready状态，liveness探针20s监测，无法成功则重启pod。 通过以上演示我们了解了如何配置两种探针和执行三种操作。通过合理的探针配置，可以实时监控Istio各个pod的运行状态，提供方便的应用治理手段。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

前言微服务架构提供了更好的灵活性、可伸缩性以及服务复用的能力，但，微服务也有特殊的安全需求，Istio Security尝试提供全面的安全解决方案。为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略。Istio 提供两种类型的身份验证：传输身份验证和来源身份验证。通过配置不同级别的认证策略，可以快速控制不同的安全访问粒度。典型的使用场景：1.在未启用双向TLS的安装好 Istio 的 Kubernetes 集群中，需要快速启用全网格双向TLS；2.网格内某些服务之间需要使用双向TLS，可以将这些服务放入同一命名空间并在命名空间启用双向TLS；3.当单个服务需要启用TLS时，可以在配置策略中通过spec字段指定；认证策略是对服务收到的请求生效的，要在双向 TLS 中指定客户端认证策略，需要在DetinationRule 中设置 TLSSettings，每个认证策略需要和目的地规则共同生效。下面通过实例来演示在不同存储范围内配置传输身份认证策略的过程，来源身份验证通过spec中的origins字段指定。环境准备：装好istio的集群，禁用全局双向TLS；Httpbin应用镜像和sleep应用镜像1.创建命名空间、部署应用创建3个命名空间：foo、bar、legacy，foo和bar中部署带sidecar的httpbin应用和sleep应用，legacy中部署不带sidecar的httpbin应用和sleep应用。将sleep作为客户端，httpbin作为服务端，验证客户端服务端可达性2.验证系统中目前不存在认证策略可以看到在foo、bar和legacy命名空间中没有任何策略和规则3.为网格中的所有服务启用双向TLS认证配置网格认证策略：配置目的地规则：需要注意的是，网格范围内的认证策略名称必须是default，其它名称的策略都会被拒绝和忽视，它的策略类型是MeshPolicy，不同于其它级别的策略类型这些认证策略和目的地规则有效地配置了所有的sidecars，使服务在双向TLS模式下收发请求。但是对不带sidecar的服务并不适用。可以看到上面有两种连接不适用：从带有 sidecar 的客户端到不带 sidecar 的服务端的连接以及从不带 sidecar 的客户端到带有 sidecar 的服务端的连接。① 为了修复从带有 sidecar 的客户端到不带 sidecar 的服务端的连接，可以专门为这些服务端添加目的地规则来覆盖 TLS 设置：重新测试连接当启用全局双向 TLS 认证时，这种方法也可以用来配置 Kubernetes 的 API 服务器。② 从不带 sidecar 的客户端到带有 sidecar 的服务端(工作在双向 TLS 模式)的连接，唯一的选择是从双向 TLS 模式切换到 PERMISSIVE 模式，该模式允许服务端接收 HTTP 或（双向） TLS 流量从 sleep.legacy 到 httpbin.foo 的请求应当是成功的，但是到 httpbin.bar 的请求依然会失败。4. 为一个命名空间中的所有服务启用双向TLS可以配置策略为每一个命名空间单独启用双向 TLS 而不必启用全局双向 TLS：注意：命名空间范围内的策略必须命名为 default，并且不限定任何特定的服务（没有 targets 设置域）添加相应的目的地规则：测试连接：由于当前配置的策略和目的地规则只对命名空间foo有效，可以看到，只有从不带 sidecar 的客户端 (sleep.legacy) 到 httpbin.foo 的请求会失败。5.为单个服务启用双向TLS你也可以为某个特定的服务设置认证策略和目的地规则。执行以下命令只为 httpbin.bar 服务新增一项策略。配置目的地规则： 6. 同时启用命名空间层级和服务层级假设我们已经为命名空间 foo 中所有的服务添加了启用双向 TLS 的命名空间层级的策略并且观察到从 sleep.legacy 到 httpbin.foo 的请求都失败了（见上文）。现在专门为 httpbin 服务添加额外的策略来禁用双向 TLS （peers 域留空）：可以看到服务层级的策略覆盖了命名空间层级的策略，连接成功。   通过以上步骤，我们知道如何在不同层级配置认证策略和目的地规则。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

微服务为我们带来了快速开发部署的优秀特性，而如何降低开发和变更的风险成为了一个问题。Istio的流量镜像，也称为影子流量，是将生产流量镜像拷贝到测试集群或者新的版本中，在引导实时流量之前进行测试，可以有效地降低版本变更风险。流量镜像有以下优点：1.当流量镜像到不同的服务时，会发生在请求的关键路径之外，这样流量镜像产生的任何问题都不会影响到生产；2.忽略对任何镜像流量的响应; 流量被视为“即发即忘”，这样就不会干扰到正常的生产流量的响应；3.当流量被镜像时，请求将通过其主机/授权报头发送到镜像服务附上 –shadow，用以区分流量从何处被镜像到何处；4.利用实时生产用例和流量可以有更真实的测试服务环境，有效降低了部署的风险；下面介绍几种典型的使用场景可以发挥流量镜像的优势：1.用于测试：测试集群的测试可以使用生产实例真实流量，不会影响正常生产的关键路径。2.用于新版本校验：可以实时对比生产流量和镜像流量的输出结果。3.用于协作服务版本回退:当用到镜像流量的服务需要修改协作服务时，因为镜像模式添加了-shadow标记, 所以可以正常处理镜像请求，并在提交之前回滚。不会让镜像版本的更改影响生产版本。4.隔离测试数据库：与数据处理相关的业务，可以使用空的数据存储并加载测试数据，针对该数据进行镜像流量操作，实现测试数据的隔离。下面通过实例来演示一下，先让所有流量都到v1版本，然后使用规则将流量镜像到v2版本：环境准备：需要httpbin和tutum/curl两个应用镜像步骤一(配置并启动服务)：首先部署两个版本的httpbin服务：httpbin-v1:httpbin-v2:部署sleep服务，为curl来提供负载：当完成以上的配置文件后，就可以用kubectl create –f ./yourconfig.yaml来启动服务，用kubectl get pod 来查看服务的运行状态：启动httpbin service:先通过kubectl get svc 查看是否有httpbin service。如果已创建service, 需要用kubectl delete service httpbin 删除，并通过下图所示yaml 新建service：步骤二（创建路由策略）：1.使用kubectl delete virtualservice httpbin，kubectl delete destinationrule httpbin删除已有httpbin策略，并通过下图yaml来创建新的路由策略，将全部的流量导入到v1版本：通过kubectl create –f ./yourrules.yaml生效：2.现在服务已经搭建好了，我们向服务发送一些流量：3.分别查看httpbin的v1,v2的pod中的日志：我们可以发现v1 pod中有刚才流量访问的记录，而v2的pod中日志为空，说明流量并没有进入到v2的pod中，这与我们全部流量导入到v1中的策略相匹配。步骤三（镜像流量）：1. 修改路由规则将流量镜像到v2服务：删除之前部署的virtualservice规则，将上图的yaml用kubectl create –f 部署，其中mirror字段将流量镜像指定到v2服务。2.发送流量：通过指令kubectl exec -it $SLEEP_POD -c sleep -- sh -c 'curl  http://httpbin:8080/headers' | python -m json.tool 发送流量：3.查看v1和v2的访问日志:通过对比记录的时间戳我们可以发现在更改策略后，v1的流量被镜像到了v2。日志中的v2报文比v1大是流量被标记为影子流量所致。步骤四（清除）：1.清除路由规则：kubectl delete virtualservice httpbinkubectl delete destinationrule httpbin2.关闭httpbin/sleep服务：kubectl delete deploy httpbin-v1 httpbin-v2 sleepkubectl delete svc httpbin通过以上步骤我们知道了如何设置路由规则来引入流量镜像。相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

在之前的最佳实践中，已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天，将向大家介绍如何用Istio实现流量熔断。熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意攻击等场景。在接下来的任务中，idou老师将通过配置一个熔断器来详细介绍如何在Istio中实现熔断，以及背后的原理。首先，我们需要添加一个应用程序来模拟访问网络中的通信。接着我们按照前面Istio实践中所要求的将Sidecar注入进应用中，然后启动应用。步骤一为了演示Istio的熔断功能，我们需要创建熔断器，并在熔断器中设置一个目标规则，如下所示：在本步骤中，我们可以理解为Istio的熔断功能主要是通过在链接池中加入上述三个参数：MaxConnections定义了到目标主机的 HTTP1/TCP 最大连接数；http1MaxPendingRequests定义了针对一个目标的 HTTP 请求的最大排队数量；maxRequestsPerConnection定义了对某一后端的请求中，一个连接内能够发出的最大请求数量。如果将这一参数设置为 1 则会禁止 keep alive 特性。在上述yaml文件中，我们为了方便进行实践，所以都设置成了1，当然大家也可以根据自己的需求自己设定阈值。步骤二对于网络通信熟悉的小伙伴应该都知道，模拟网络通信的环境需要一个服务端接收请求，一个请求端发送请求。刚刚我们已经创建完成一个服务端，并给服务端配置了熔断的条件，现在我们继续创建一个请求端来发送请求触发熔断机制。我们用了官网上的一个例子fortio来进行测试。这个客户端可以控制连接数量、并发数、以及发送HTTP请求的延迟，当然我们也必须将Sidecar注入其中。步骤三我们可以通过命令kubectl exec -it $FORTIO_POD  -c fortio /usr/local/bin/fortio -- load -curl  http://httpbin:8000/get来登入客户端Pod，并使用刚刚创建的客户端来调用httpbin。将会看到如下所示：这表明我们创建的客户端已经成功与服务端进行了一次通信。步骤四开始进入今天的主题，在上面的熔断设置中指定了 maxConnections=1 以及 http1MaxPendingRequests=1。这意味着如果超过了一个连接同时发起请求，Istio 就会熔断，阻止后续的请求或连接。我们不妨尝试通过并发2个连接发送20个请求数来看一下结果。通过上图不难看出，基本上所有的请求都发送成功了。明明我们设置的最大连接数是1，而我们模拟了两个并发连接，理论上应该只有一半的请求能成功才对，难道熔断没有成功？这里别忘了我们还设置了http1MaxPendingRequests=1，正如在前文中介绍的，这个参数的功能类似于为最大连接数提供了一级缓存，所以虽然我们的最大连接数是1，但是因为这个参数也为1，所以两个并发连接的请求都可以发送成功。步骤五接下来我们再修改一下参数与步骤四做个对比，模拟并发连接数数改为3请求数依然是20，我们将会看到如下图所示的结果：正如我们在第三步中说的那样，只有2/3的请求成功，还有1/3的请求数被熔断。如果你觉得还不放心，那么我们不妨再把http1MaxPendingRequests置为2。这时候缓存区的请求相当于最大允许连接数的2倍，是不是并发数为3的模拟连接发送的请求都可以成功呢？从上图我们可以看到，确实如此，基本上所有的请求都成功了。通过今天的实践我们就可以知道，如何通过修改Istio的目标规则来对请求数启动熔断机制。