“危险是我的中间名，”国际神秘人物奥斯汀·鲍尔斯曾经说过。 但超级特工和情报部门所推崇的东西根本不适合计算机服务，因为在计算机服务中，无聊比危险要好得多。
Istio 与 OpenShift 和 Kubernetes 一起，使部署微服务变得真正无聊且可预测 - 这很棒。 我们将在 Istio 系列的第四篇也是最后一篇文章中讨论这一点以及更多内容。
当无聊是正确的时候
在我们的例子中，无聊只发生在最后阶段，此时剩下的就是坐下来观看整个过程。 但为此，您需要先配置所有内容，这里有很多有趣的事情等着您。
部署新版本的软件时，值得考虑最小化风险的所有选项。 并行运行是一种非常强大且经过验证的测试方法，Istio 允许您使用“秘密服务”（微服务的隐藏版本）来执行此操作，而不会干扰生产系统。 甚至还有一个专门的术语来形容这一点——“暗启动”，它又是由一个同样间谍名称“流量镜像”的功能激活的。
请注意，上一段的第一句使用术语“部署”而不是“发布”。 您确实应该能够根据需要经常部署（当然，也可以使用）您的微服务。 该服务必须能够接收和处理流量、生成结果以及写入日志和监控。 但同时，这项服务本身并不一定需要发布到生产环境中。 部署和发布软件并不总是同一件事。 您可以随时部署，但只有在准备好时才发布。
整理无聊很有趣
看一下下面的 Istio 路由规则，它将所有 HTTP 请求路由到微服务推荐 v1（所有示例均取自 ），同时将它们镜像到推荐 v2 微服务：
注意标签 mirror: 屏幕底部 - 正是它设置流量镜像。 是的，就是这么简单！
此规则的结果将是您的生产系统 (v1) 将继续处理传入请求，但请求本身将异步镜像到 v2，也就是说，它们的完整副本将转到那里。 这样，您就可以在真实条件下（基于真实数据和流量）测试 v2，而不会以任何方式干扰生产系统的运行。 这会让组织测试变得无聊吗？ 当然是。 但它是以一种有趣的方式完成的。
让我们添加戏剧
请注意，在 v2 代码中，有必要提供传入请求可能导致数据更改的情况。 请求本身很容易、透明地被镜像，但是测试中处理方法的选择取决于你——这有点令人担忧。
让我们重复一个重要的观点
可以通过流量镜像（暗启动/请求镜像）进行秘密启动，而不会以任何方式影响代码。
思考的食物
如果镜像请求的地方将其中一些请求发送到 v1，而不是 v2，该怎么办？ 例如，所有请求的百分之一或仅来自特定用户组的请求。 然后，已经了解了 v2 的工作原理，逐渐将所有请求转移到新版本。 反之亦然，如果 v1 出现问题，则将所有内容返回给 v2。 我认为这称为金丝雀部署。 ，如果它源自俄罗斯，它可能会包含对 ），现在我们将更详细地讨论这一点。
Istio 中的金丝雀部署：简化调试
小心翼翼、循序渐进
Canary Deployment 部署模型的本质非常简单：当您启动软件的新版本（在我们的例子中是微服务）时，您首先向一小群用户授予对其的访问权限。 如果一切顺利，您可以慢慢增加该组，直到新版本开始运行，或者 - 如果没有 - 最终将所有用户迁移到该组。 通过深思熟虑、逐步引入新版本并以受控方式将用户切换到新版本，您可以降低风险并最大化反馈。
当然，Istio 通过提供几个不错的智能请求路由选项来简化 Canary 部署。 是的，所有这一切都可以在不以任何方式接触源代码的情况下完成。
过滤浏览器
最简单的路由标准之一是基于浏览器的重定向。 假设您只希望来自 Safari 浏览器的请求转到 v2。 其操作方法如下：
让我们应用这个路由规则，然后使用命令 curl 我们将在循环中模拟对微服务的真实请求。 正如您在屏幕截图中看到的，它们都转到 v1：
v2 的流量在哪里？ 由于在我们的示例中，所有请求仅来自我们自己的命令行，因此它根本不存在。 但请注意上面屏幕中的底线：这是对我们执行来自 Safari 浏览器的请求这一事实的反应，而 Safari 浏览器又产生了以下内容：
无限动力
我们已经写过，正则表达式为路由请求提供了非常强大的功能。 看一下下面的示例（我们认为您会理解它的作用）：
现在您可能已经了解正则表达式可以做什么。
聪明行事
智能路由，特别是使用正则表达式处理数据包标头，使您可以按照您想要的方式引导流量。 这极大地简化了新代码的实现——很简单，不需要更改代码本身，并且如果需要，一切都可以快速返回原样。
感兴趣吗？
您是否渴望在计算机上尝试 Istio、Kubernetes 和 OpenShift？ 团队 准备了一个优秀的 并公开了所有随附文件。 所以继续吧，不要否认自己任何事情。
Istio Egress：通过纪念品商店出口
通过将 Istio 与 Red Hat OpenShift 和 Kubernetes 结合使用，您可以使微服务的使用变得更加轻松。 Istio 的服务网格隐藏在 Kubernetes Pod 内，您的代码（大部分）独立运行。 性能、易于更改、跟踪等——由于使用了 sidecar 容器，所有这些都易于使用。 但是，如果您的微服务需要与 OpenShift-Kubernetes 系统外部的其他服务通信怎么办？
这就是 Istio Egress 发挥作用的地方。 简而言之，它只是允许您访问不属于 Kubernetes Pod 系统的资源（即“服务”）。 如果您不执行其他配置，则在 Istio Egress 环境中，流量仅在 Pod 集群内以及基于内部 IP 表的集群之间进行路由。 只要您不需要从外部访问服务，这种化蛹就很有效。
出口允许您根据出口规则或 IP 地址范围绕过上述 IP 表。
假设我们有一个 Java 程序，它向 httpbin.org/headers 发出 GET 请求。
（httpbin.org 只是一个用于测试传出服务请求的便捷资源。）
如果你在命令行输入 curl http://httpbin.org/headers，我们将看到以下内容：
或者你可以在浏览器中打开相同的地址：
如您所见，位于此处的服务仅返回传递给它的标头。
我们正在正面替代进口
现在，让我们在我们的系统外部获取该服务的 Java 代码，并在我们自己的位置（回想一下，安装了 Istio 的地方）运行它。 （您可以通过联系自己来完成此操作 .) 构建了适当的映像并在 OpenShift 平台上启动它后，我们将使用以下命令调用此服务 curl egresshttpbin-istioegress.$(minishift ip).nip.io，之后我们将在屏幕上看到：
哎呀，发生什么事了？ 一切都正常了。 未找到是什么意思？ 我们只是为他做的 curl.
将 IP 表扩展到整个互联网
Istio 应该为此受到指责（或感谢）。 毕竟，Istio 只是负责检测和路由（以及我们之前讨论过的许多其他事情）的 sidecar 容器。 因此，IP 表只知道集群系统内部的内容。 而且 httpbin.org 位于外部，因此无法访问。 这就是 Istio Egress 发挥作用的地方 - 无需对源代码进行丝毫更改。
下面的出口规则强制 Istio 搜索（如有必要，则在整个互联网中）搜索所需的服务，在本例中为 httpbin.org。 正如您从这个文件（egress_httpbin.yml）中看到的，这里的功能非常简单：
剩下的就是应用这个规则：
istioctl create -f egress_httpbin.yml -n istioegress
您可以使用以下命令查看出口规则 istioctl get egressrules:
最后，我们再次运行命令 卷曲 – 我们看到一切正常：
我们开放地思考
正如您所看到的，Istio 允许您组织与外部世界的交互。 换句话说，您仍然可以创建 OpenShift 服务并通过 Kubernetes 管理它们，将所有内容保留在可根据需要扩展和缩小的 Pod 中。 同时，您可以安全地访问环境外部的服务。 是的，我们再次重申，所有这一切都可以在不以任何方式接触您的代码的情况下完成。
这是 Istio 系列的最后一篇文章。 请继续关注 - 前面有很多有趣的事情！
来源： habr.com