Istio的黑暗发射:特勤局

“危险是我的中间名,”国际知名的神秘人士奥斯汀·鲍尔斯(Austin Powers)说。但是,超级代理人和特殊服务人员高度重视的东西根本不适合计算机服务,因为在计算机服务中,无聊的事情比危险要好得多。



而且Istio与OpenShift和Kubernetes一起使微服务部署真正变得无聊且可预测-很棒。我们将在Istio系列的第四篇也是最后一篇文章中谈论这一点以及更多内容。

当无聊是对的


在我们的案例中,无聊只发生在最后阶段,而此时只有坐下来观察过程。但是为此,您需要预先配置所有内容,在这里您会发现很多有趣的东西。

部署软件的新版本时,应考虑所有选项以最大程度地降低风险。在并行模式下工作是一种非常强大且经过验证的测试方法,Istio允许您为此使用“秘密服务”(隐藏于微服务中的微服务版本),而不会干扰生产系统。甚至还有一个特殊的术语-“秘密启动”(暗启动),而反过来又被间谍软件名称最少的“流量镜像”功能激活。

注意,上一段的第一句话使用术语“部署”而不是“发布”。您确实应该能够随意部署并使用微服务。该服务应该能够接收和处理流量,产生结果以及写入日志和监视。但与此同时,此服务本身完全不必发布到生产中。软件部署和发布并非总是一回事。您可以随时执行部署,但是只有在完全准备好后才能发布。

组织无聊很有趣


查看以下Istio路由规则,该规则将所有HTTP请求路由到推荐v1微服务(所有示例均来自Istio教程GitHub repo),同时将它们镜像到推荐v2微服务:


请注意mirror:屏幕底部的标签-它是设置流量镜像的地方。是的,就是这么简单!

此规则的结果将是您的生产系统(v1)将继续处理传入的请求,但是请求本身将在v2上异步镜像,也就是说,它们的完整副本将转到该位置。因此,您可以在真实条件下-在真实数据和流量上测试v2的工作,而不会干扰生产系统的工作。这会使测试组织感到无聊吗?当然是。但这很有趣。

新增剧集


请注意,在v2代码中,有必要规定传入的请求可能导致数据更改的情况。查询本身可以轻松,透明地镜像,但是测试中处理方法的选择由您自己决定-这已经有些令人兴奋了。

重复重点


可以执行带有流量镜像的秘密启动(暗启动/请求镜像),而不会影响代码。

思考的食物


但是,如果镜像请求的地方是将其中一些请求发送到v1,而不是发送到v2,该怎么办?例如,所有请求的百分之一或仅来自特定用户组的请求。然后,已经了解了v2的工作原理,逐渐将所有请求转移到新版本。反之亦然,如果v2出现问题,则将所有内容返回v1。它似乎被称为Canary Deployment(“金丝雀部署”)(该术语可以追溯到采矿,如果它是俄罗斯血统,则可能包含对cats的引用),现在我们将对其进行更详细的研究。

Istio的Canary部署:简化调试


谨慎并逐步


Canary Deployment部署模型的本质非常简单:启动新版本的软件(在我们的示例中为微服务)时,首先需要将其访问权限授予一小群用户。如果一切顺利,则可以慢慢增加该组,直到新版本开始变废为宝;或者-如果没有发生,则最终将所有用户转移到该组。认真,逐步地将新版本投入使用,并以受控的方式将用户切换到新版本,您可以降低风险并最大化反馈。

当然,Istio通过为智能查询路由提供几个不错的选择来简化Canary部署。是的,所有这些都可以在不触及源代码的情况下完成。

筛选浏览器


最简单的路由标准之一是基于浏览器的重定向。假设您希望v2仅发送来自Safari浏览器的请求。方法如下:


我们应用此路由规则,然后使用该命令curl在一个循环中模拟对微服务的实际请求。如您在屏幕快照中所见,它们都转到了v1:


v2上的流量在哪里?由于在我们的示例中,所有请求仅来自我们自己的命令行,因此它根本不存在。但是请注意上面截图中的底线:这是对以下事实的反应:我们从Safari浏览器执行了请求,而Safari浏览器又发出了以下请求:


无限动力


我们已经写过,正则表达式为路由查询提供了非常强大的功能。请看以下示例(我们认为您自己会明白它的作用):


现在您可能已经知道正则表达式具有什么功能。

明智行事


智能路由,特别是使用正则表达式处理数据包头,使您能够以所需的方式来驱动流量。这极大地简化了新代码的调试-很简单,它不需要更改代码本身,并且在必要时可以快速返回所有内容。

有兴趣?


您是否想在计算机上尝试使用Istio,Kubernetes和OpenShift?红帽开发团队已准备一个优秀的教程关于这个主题和共享所有相关的文件。因此,继续前进,不要否认自己。

Istio Egress:通过礼品店退出


将Istio与Red Hat OpenShift和Kubernetes结合使用可以极大地简化微服务的生活。 Istio实用程序网格隐藏在Kubernetes容器内部,并且您的代码(大多数)是独立执行的。性能,易于更改,追踪等-所有这些都可以通过使用Sidecar容器来轻松精确地使用。但是,如果您的微服务需要与OpenShift-Kubernetes系统外部的其他服务通信,该怎么办?

这就是Istio Egress进行救援的地方。简而言之,它仅允许您访问Kubernetes pod系统中未包含的资源(阅读:“服务”)。如果不执行其他配置,则在Istio Egress环境中,流量仅基于内部IP表在Pod群集内以及此类群集之间路由。在您需要从外部访问服务之前,这种清理非常有效。

出口允许您基于出口规则或一系列IP地址绕过上述IP表。

假设我们有一个Java程序执行对httpbin.org/headers的GET请求。

(httpbin.org只是用于测试传出服务请求的便捷资源。)

如果在命令提示符下键入curl http://httpbin.org/headers我们将看到以下内容:


或者,您可以在浏览器中打开相同的地址:


如您所见,位于此处的服务仅返回传递给它的标头。

额头上的进口替代


现在,让我们将此服务的Java代码带到系统外部,并在Istio所在的位置在家中运行它。(您可以通过参考我们的Istio教程自行完成此操作。)构建相应的映像并在OpenShift平台上运行它curl egresshttpbin-istioegress.$(minishift ip).nip.io之后,我们将使用命令调用此服务,然后在屏幕上看到以下内容:


糟糕,发生了什么事?尽管如此,它仍然有效。未找到是什么意思?我们只是为他做的curl

将IP表扩展到整个Internet


为此怪(或感谢)伊斯蒂奥。毕竟,Istio只是负责检测和路由的Sidecar容器(当然,还有我们前面提到的许多其他事情)。因此,IP表仅知道群集系统内部的内容。并且httpbin.org位于外部,因此不可用。Istio Egress可以为您提供帮助-源代码中无需做任何改动。

下面的Egress规则使Istio(如果需要,然后在整个Internet上)搜索所需的服务,在本例中为httpbin.org。从该文件(egress_httpbin.yml)中可以看到,这里的功能非常简单:


仍然仅适用此规则:

istioctl create -f egress_httpbin.yml -n istioegress

您可以使用以下命令查看出口规则istioctl get egressrules


最后,再次运行curl命令-看到一切正常:


我们公开思考


如您所见,Istio允许您组织与外界的互动。换句话说,您仍然可以创建OpenShift服务并通过Kubernetes引导它们,将所有内容保存在Pod中,并根据需要扩展和缩小。同时,您可以安全地访问环境外部的服务。是的,我们再重复一次,无需触摸您的代码就可以完成所有这些操作。

这是Istio系列的最后一篇文章。和我们在一起-未来还有很多有趣的事情!

Source: https://habr.com/ru/post/undefined/


All Articles