发布网友
发布时间:2022-11-21 02:29
共1个回答
热心网友
时间:2024-09-03 05:55
上篇:
Ingress 基本概念:
部署 httpbin 服务,同样,官方demo已经提供了该配置文件,执行如下命令应用即可:
为 httpbin 服务配置 Ingress 网关,定义 Ingress gateway,如下所示:
然后定义 Virtual Service 配置路由规则并关联该 Gateway:
使用如下命令获取 istio-ingressgateway 服务的实际请求地址和端口号(但服务的 EXTERNAL-IP 为 pending 或 none 时采用此方式,详见: 官方文档 ):
接下来使用 curl 命令测试一下 httpbin 的接口能否正常访问:
访问没有被暴露的接口,此时返回404:
有进入网格的流量也就有从网格出去的流量,这种入口流量与出口流量也就是我们常说的南北流量,在Istio中我们可以对网格的入口和出口流量进行管控。
Istio中访问外部服务的方法:
Egress 概念:
在本小节,我们将实践创建一个 Egress 网关,让内部服务(sleep)通过它访问外部服务(httpbin.org),这两个服务在前面的章节示例中都已经演示过了:
查看 istio-egressgateway 组件是否存在:
确认 sleep 服务已处于正常运行状态:
为 httpbin.org 这个外部服务定义 ServiceEntry:
确认创建成功:
定义 Egress gateway:
定义路由,将流量引导到 istio-egressgateway:
测试访问 httpbin.org 服务的接口:
查看日志验证出口流量是否经过了Egress网关,输出了如下日志信息代表Egress网关配置成功,出口流量经过了该Egress网关:
此时 sleep 服务访问外部服务的流程如下图:
对于一个分布式系统来说,出现网络故障是在所难免的,因此如何提升系统弹性,提升系统在面对故障时的处理能力是分布式架构非常重要的一个主题。其中,超时和重试是非常重要且常用的,用于提升系统弹性的机制。
基本概念
接下来我们还是通过Bookinfo这个应用来作为演示,对其中的一些服务添加超时策略和重试策略。我们会将请求指向 reviews 服务的 v2 版本,并在 ratings 服务中添加延迟设置,模拟一个故障出现的情况,以此来验证我们设置的超时和重试策略是否生效:
首先,创建一个Virtual Service将请求路由到 reviews 服务的 v2 版本:
给 ratings 服务注入延迟,模拟故障:
给 reviews 服务添加超时策略:
此时刷新应用页面,可以看到返回了错误信息:
将 reviews 服务的超时策略取消掉,然后给 ratings 服务添加重试策略:
查看 ratings 服务的 Sidecar 日志,然后刷新应用页面,正常情况下从日志输出可以看到重试了两次请求:
配置选项 :
什么是 断路器(Circuit Breaking)?
本小节我们实践一下为 httpbin 服务 添加断路器配置 ,然后通过负载测试工具来触发熔断。断路器相关配置是在服务的 DestinationRule 中里进行配置的,如下所示:
安装fortio,使用该负载测试工具来触发熔断:
先尝试发送单个请求,确认该工具能够正常工作:
没问题后,通过如下命令进行并发压测,并发数是3,执行30次:
如果希望查看具体指标可以使用如下命令:
配置选项 :
了解 故障注入(Fault injection) :
在配置好网络(包括故障恢复策略)后,我们可以使用Istio的故障注入机制来测试应用程序的整体故障恢复能力。故障注入是一种将错误引入系统以确保系统能够承受并从错误条件中恢复的测试方法。
所以故障注入机制特别有用,可以提前暴露一些故障恢复策略不兼容或*性太强,从而可能导致的关键服务不可用的问题。故障注入在业界的发展和应用例子:
其实我们在之前的小节中早已演示过了Istio的故障注入配置,在超时与重试的小节中,我们就为 ratings 服务注入过一个延迟故障:
使用如下命令将Bookinfo应用各个服务的路由信息设置到各自的 v1 版本:
然后将 reviews 服务的流量指向它的 v2 版本,因为只有 v2 和 v3 版本才会调用 ratings 服务:
给 ratings 服务注入延迟故障:
virtual-service-ratings-test-delay.yaml 文件的内容:
配置选项 :
相信很多开发人员都遇到过这样的问题,就是在开发/测试环境中运行良好的功能,一上线就出问题。即便做足了单元测试、集成测试,测试覆盖率也很高,也依然会有这种问题存在,并且这类问题在开发/测试环境难以复现。
出现这种问题的一个主要原因,是因为线上环境,特别是数据环境,比如说数据量、请求的并发量以及用户使用数据的方式都与开发/测试环境非常的不一样。由于这种不一致性导致我们很难在开发/测试环境中发现线上的问题。
那么一个非常好的解决办法,就是使用流量镜像机制,将线上流量复刻一份到开发/测试环境中进行测试。
了解 流量镜像(Traffic Mirroring) :
流量镜像(Traffic mirroring,也称为Shadowing)是一个强大的概念,它允许开发团队以尽可能小的风险为生产环境带来更改。流量镜像机制可以将实时流量的副本发送到一个镜像服务。对流量的镜像发生在主服务的关键请求路径之外。
接下来我们实践一下如何配置Istio中的流量镜像机制,需求是将发送到 v1 版本的流量镜像到 v2 版本。因此,我们首先部署 httpbin 服务的 v1 和 v2 版本。v1 版本的配置如下:
部署 httpbin 服务的 v2 版本:
为 httpbin 创建一个 Service 资源,让 Pod 能够通过服务的方式暴露出来:
为 httpbin 服务创建默认的虚拟服务与目标规则:
测试一下能否正常访问到 httpbin 服务的接口:
完成以上的准备工作后,我们就可以在虚拟服务中为 httpbin 服务的 v2 版本配置对 v1 版本的流量镜像:
尝试请求 httpbin 服务的接口,由于我们配置了路由规则,该请求一定是被路由到 v1 版本上的:
此时观察 v2 版本的日志,从日志输出中可以发现 v2 版本也接收到了相同的请求,代表我们的流量镜像配置生效了:
配置选项 :