idou老师教你学Istio12 : Istio 实现流量镜像

微服务为我们带来了快速开发部署的优秀特性,而如何降低开发和变更的风险成为了一个问题。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 httpbin

kubectl delete destinationrule httpbin

2.关闭httpbin/sleep服务:

kubectl delete deploy httpbin-v1 httpbin-v2 sleep

kubectl delete svc httpbin

通过以上步骤我们知道了如何设置路由规则来引入流量镜像。

相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

原文地址:http://blog.51cto.com/14051317/2347488

时间: 2024-07-31 07:02:04

idou老师教你学Istio12 : Istio 实现流量镜像的相关文章

idou老师教你学Istio 07: 如何用istio实现请求超时管理

前言 在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移.这两个方面的功能都是Istio流量治理的一部分.今天将继续带大家了解Istio的另一项功能,关于请求超时的管理. 首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理.看过idou老师前面文章的老司机应该都已经对Bookinfo这个实例驾轻就熟了,当然还存在部分被idou老师的文采刚吸引过来的新同学. 下面先简单的介绍一下Bookinfo这个样例应用整体架构,以便我们更好地

idou老师教你学Istio11 : 如何用Istio实现流量熔断

在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力.今天,将向大家介绍如何用Istio实现流量熔断. 熔断机制是创建弹性微服务应用程序的重要模式.熔断可以帮助您自由控制故障影响的范围.网络延迟的峰值以及抵御其他一些来自外部的恶意攻击等场景. 在接下来的任务中,idou老师将通过配置一个熔断器来详细介绍如何在Istio中实现熔断,以及背后的原理. 首先,我们需要添加一个应用程序来模拟访问网络中的通信.接着我们按照前面Istio实践中所要求的将Sidecar注入进应用中,然

idou老师教你学Istio06: 如何用istio实现流量迁移

概要 流量迁移是流量管理的一个重要功能.istio提供的流量管理功能将流量从基础设施扩展中解耦,支持动态请求路由,故障注入.超时重试.熔断和流量迁移等.流量迁移的主要目的是将流量从微服务的某一版本的逐步迁移至另一个版本,如在新旧版本之间进行流量切换.本文通过一个简单的用例介绍如何使用istio进行流量迁移. 本文使用一个bookinfo的典型例子.通过istio的命令配置规则,将流量从reviews的版本v1逐步迁移到版本v3.在下面的例子中,应用基于权重路由配置,将百分百路由在reviews:

idou老师教你学istio1:如何为服务提供安全防护能力

今天,我们就来谈谈Istio主打功能---保护服务. 那么,便引出3个问题: Istio 凭什么保护服务? Istio 具体如何保护服务? 如何告诉 Istio 发挥保护能力? Istio凭什么保护服务? 将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性.可伸缩性和可复用性.但这也带来了一些安全问题: 为了抵御中间***,需要对流量进行加密 为了提供灵活的服务访问控制,需要 mTLS(双向的安全传输层协议)和细粒度的访问策略 要审计谁在什么时候做了什么,

idou老师教你学istio:监控能力介绍

经过了一年多的开发和测试,Istio于北京时间7月31日发布了1.0版本,并且宣布1.0版本已经可以成熟的应用于生产环境.对于istio的各项主要功能,之前的文章已经介绍的非常详细,并且还会有更多的文章来分析原理和实践功能.今天我们主要介绍的服务是istio流量监控能力.我们知道每个pod内都会有一个Envoy容器,其具备对流入和流出pod的流量进行管理,认证,控制的能力.Mixer则主要负责访问控制和遥测信息收集.如拓扑图所示,当某个服务被请求时,首先会请求istio-policy服务,来判定

idou老师教你学Istio 04:Istio性能及扩展性介绍

Istio的性能问题一直是国内外相关厂商关注的重点,Istio对于数据面应用请求时延的影响更是备受关注,而以现在Istio官方与相关厂商的性能测试结果来看,四位数的qps显然远远不能满足应用于生产的要求.从发布以来,Istio官方也在不断的对其性能进行优化增强.同时,Istio控制面的可靠性是Istio用于生产的另一项重要考量标准,自动伸缩扩容,自然是可靠性保证的重要手段.下面我们先从性能测试的角度入手,了解下Istio官方提供的性能测试方法与基准,主要分为以下四个方面展开. 一.函数级别测试

idou老师教你学Istio 08: 调用链埋点是否真的“零修改”?

本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式.并基于Istio中埋点的原理解释来说明:为了输出一个质量良好的调用链,业务程序需根据自身特点做适当的修改,即并非官方一直在说的完全无侵入的做各种治理.另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式. Istio一直强调其无侵入的服务治理,服务运行可观察性.即用户完全无需修改代码,就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集.原文是这样描述的: Istio

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness: liveness探针用来侦测什么时候需要重启容器.比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用. readiness探针用来使容器准备好接收流量.当所有容器都ready时被视为pod此时ready.比如说用这种信号来控制一个后端服务,当pod没有到ready状态时,服务会从负载均衡被移除. 使用场景: liveness

idou老师教你学Istio 15:Istio实现双向TLS的迁移

在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份.保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统.本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS. 使用场景 在部署了Istio的集群中,使用人员刚开始可能更关注功能性,服务之间的通信配置的都是明文传输,当功能逐渐完善,开始关注安全性,部署有sidecar的服务需要使用双向TLS进行安全传输,但服务不能中断,这时,一个可取的方式就是进行双向TLS的迁移.