我们将开始发布一系列文章，展示 Istio 服务网格与红帽 OpenShift 和 Kubernetes 结合使用时的众多功能。
第一部分，今天：
- 让我们解释一下 Kubernetes sidecar 容器的概念，并阐述本系列文章的主题： “您不需要更改代码中的任何内容”.
- 我们来介绍一下 Istio 的基本东西——路由规则。 所有其他 Istio 功能都是基于它们构建的，因为它是允许您使用服务代码外部的 YAML 文件将流量引导到微服务的规则。 我们也在考虑Canary Deployment部署方案。 新年奖励 – 10 节 Istio 互动课程
即将推出的第二部分将告诉您：
- Istio 如何与 Circuit Breaker 结合实现池弹出，并将演示 Istio 如何允许您从平衡电路中删除死掉或性能不佳的 pod。
- 我们还将查看第一篇文章中的断路器主题，了解如何在此处使用 Istio。 我们将向您展示如何使用 YAML 配置文件和终端命令路由流量并处理网络错误，而无需对服务代码进行丝毫更改。
第三部分：
- 一个关于跟踪和监控的故事，它们已经内置或可以轻松添加到 Istio 中。 我们将向您展示如何使用 Prometheus、Jaeger 和 Grafana 等工具结合 OpenShift 扩展来轻松管理微服务架构。
- 我们从监视和处理错误转向有意将错误引入系统。 换句话说，我们学习如何在不更改源代码的情况下进行故障注入，这从测试的角度来看非常重要 - 因为如果为此更改代码本身，则存在引入其他错误的风险。
最后，在 Istio Service Mesh 的最后一篇文章中：
- 让我们去黑暗面吧。 更准确地说，我们将学习使用Dark Launch方案，当代码直接在生产数据上部署和测试时，但不会以任何方式影响系统的运行。 这就是 Istio 流量拆分能力派上用场的地方。 而在不以任何方式影响作战系统运行的情况下对实时生产数据进行测试的能力是最有说服力的验证方法。
- 在 Dark Launch 的基础上，我们将向您展示如何使用金丝雀部署模型来降低风险并更轻松地将新代码投入生产。 Canary Deployment 本身并不是什么新鲜事，但 Istio 允许您仅使用简单的 YAML 文件来实现此方案。
- 最后，我们将向您展示如何使用 Istio Egress 为集群外部的人员提供对服务的访问权限，以便在使用 Internet 时使用 Istio 的功能。
那么，我们开始吧...
Istio 监控和管理工具 - 在服务网格中编排微服务所需的一切 .
什么是 Istio 服务网格
服务网格为一组服务实现流量监控、访问控制、发现、安全、容错和其他有用的功能。 Istio 允许您完成所有这一切，而无需对服务本身的代码进行丝毫更改。 魔法的秘密是什么？ Istio 以 sidecar 容器的形式将自己的代理附加到每个服务上（sidecar 是摩托车边车），此后该服务的所有流量都经过该代理，该代理在指定策略的指导下决定该流量的方式、时间和是否应该完全达到服务。 Istio 还使得实现先进的 DevOps 技术成为可能，例如金丝雀部署、断路器、故障注入等。
Istio 如何与容器和 Kubernetes 配合使用
Istio 服务网格是创建和管理微服务所需的一切的边车实现：监控、跟踪、断路器、路由、负载平衡、故障注入、重试、超时、镜像、访问控制、速率限制等等。 尽管现在有大量的库可以直接在代码中实现这些功能，但使用 Istio，您无需更改代码中的任何内容即可获得所有相同的功能。
根据 sidecar 模型，Istio 运行在一个 Linux 容器中，该容器位于一个 -pod 具有受控服务，并根据给定的配置注入和提取功能和信息。 我们强调这是您自己的配置，它位于您的代码之外。 因此，代码变得更加简单和简短。
同样重要的是，微服务的操作组件与代码本身没有任何关系，这意味着它们的操作可以安全地转移给 IT 专家。 确实，为什么开发人员要负责断路器和故障注入？ 反应，是的，但是处理它们并创建它们？ 如果从代码中删除所有这些，程序员将能够完全专注于应用程序功能。 并且代码本身将变得更短、更简单。
服务网格
Istio 实现了在代码之外管理微服务的功能，这是服务网格的概念。 换句话说，它是一个或多个二进制文件的协调组，形成网络功能网格。
Istio 如何与微服务配合使用
这就是 sidecar 容器的工作原理 и 鸟瞰图：启动 Minishift 实例，为 Istio 创建一个项目（我们称之为“istio-system”），安装并运行所有 Istio 相关组件。 然后，当您创建项目和 pod 时，您可以将配置信息添加到您的部署中，并且您的 pod 开始使用 Istio。 简化图如下所示：
现在您可以按顺序更改 Istio 设置，例如，组织故障注入、支持 或其他 Istio 功能 - 所有这些都无需触及应用程序本身的代码。 假设您希望将最大客户（Foo Corporation）的用户的所有网络流量重定向到该网站的新版本。 为此，只需创建一个 Istio 路由规则，该规则将在用户 ID 中查找 @foocorporation.com 并进行相应的重定向。 对于所有其他用户来说，什么都不会改变。 在此期间，您将冷静地测试网站的新版本。 请注意，您根本不需要让开发人员参与其中。
你是否需要为此付出高昂的代价？
一点也不。 Istio 速度相当快，并且是用以下语言编写的 并且产生的开销非常小。 此外，在线生产力可能的损失可以通过开发人员生产力的提高来抵消。 至少在理论上：不要忘记开发人员的时间是宝贵的。 至于软件成本，Istio 是开源软件，因此您可以免费获取和使用它。
自己掌握吧
红帽开发者体验团队开发了深入的实践 由 Istio（英文）编写。 它可以在 Linux、MacOS 和 Windows 上运行，代码可在 Java 和 Node.js 中使用。
10 个关于 Istio 的互动课程
第 1 部分 - 适合初学者
Istio 简介
30分钟
让我们熟悉 Service Mesh，了解如何在 OpenShift Kubernetes 集群中安装 Istio。
在 Istio 中部署微服务
30分钟
我们使用 Istio 通过 Spring Boot 和 Vert.x 部署三个微服务。
第 2 块 – 中级
Istio 中的监控和跟踪
60分钟
我们将通过 Prometheus 和 Grafana 探索 Istio 的内置监控工具、自定义指标以及 OpenTracing。
Istio 中的简单路由
60分钟
了解如何使用简单的规则在 Istio 中管理路由。
高级路由规则
60分钟
我们来看看Istio的智能路由、访问控制、负载均衡和速率限制。
第 3 块 – 高级用户
Istio 中的故障注入
60分钟
我们研究分布式应用程序中的故障处理场景，创建 HTTP 错误和网络延迟，并学习使用混沌工程来恢复环境。
Istio 中的断路器
30分钟
我们为压力测试站点安装 Siege，并学习如何使用重放、断路器和池弹出来确保后端容错。
出口和 Istio
10分钟
我们使用出口路由来创建内部服务与外部 API 和服务交互的规则。
Istio 和 Kiali
15分钟
学习使用 Kiali 来概述服务网格并探索请求和数据流。
Istio 中的相互 TLS
15分钟
我们创建 Istio Gateway 和 VirtualService，然后详细研究双向 TLS (mTLS) 及其设置。
块 3.1 - 深入探讨：微服务的 Istio 服务网格
这本书讲什么的：
- 什么是服务网格？
- Istio 系统及其在微服务架构中的作用。
- 使用Istio可以解决以下问题：
- 容错；
- 路由;
- 混沌测试；
- 安全;
- 使用跟踪、指标和 Grafana 进行遥测收集。
有关服务网格和 Istio 的系列文章
亲自尝试一下
本系列文章的目的并不是要深入了解 Istio 的世界。 我们只是想向您介绍这个概念，并可能激励您亲自尝试 Istio。 它完全免费，红帽提供了您开始使用 OpenShift、Kubernetes、Linux 容器和 Istio 所需的所有工具，包括： , 以及我们的其他资源 。 事不宜迟，从今天开始吧！
Istio 路由规则：将服务请求定向到需要去的地方
и 出色地解决问题 路由到所需的 Pod。 这就是 Kubernetes 存在的原因之一——路由和负载均衡。 但是，如果您需要更微妙和复杂的路由怎么办？ 例如，同时使用微服务的两个版本。 Istio 路由规则在这里有何帮助？
路由规则是实际决定路由选择的规则。 无论系统复杂程度如何，这些规则的一般操作原理仍然很简单：根据某些参数和 HTTP 标头值路由请求。
让我们看一下例子：
Kubernetes 默认值：简单的“50/50”
在我们的示例中，我们将展示如何在 OpenShift 中同时使用微服务的两个版本，我们将它们称为 v1 和 v2。 每个版本都在自己的 Kubernetes Pod 中运行，默认情况下它运行均匀平衡的循环路由。 每个 Pod 根据其微服务实例（即副本）的数量接收其请求份额。 Istio 允许您手动更改此平衡。
假设我们在 OpenShift 上部署了两个版本的推荐服务：recommendation-v1 和recommendation-v2。
在图中。 图 1 显示，当每个服务在一个实例中表示时，请求在它们之间均匀交替：1-2-1-2-...这就是 Kubernetes 路由默认的工作方式：
版本之间的加权分布
在图中。 图 2 显示了如果将 v2 服务副本的数量从 2 个增加到 2 个（这是通过 oc scale —replicas=1 deployment/recommendation-v2 命令完成的）会发生什么情况。 如您所见，v1 和 v2 之间的请求现在按一比三的比例划分：2-1-2-2-XNUMX-XNUMX-…：
使用 Istio 忽略版本
Istio 可以轻松地按照我们需要的方式更改请求的分布。 例如，使用以下 Istio yaml 文件仅将所有流量发送到recommendation-v1：
这里需要注意的是：pod是根据标签来选择的。 我们的示例使用标签 v1。 “weight: 100”参数表示 100% 的流量将路由到所有具有 v1 标签的服务 Pod。
版本之间的指令分发（金丝雀部署）
接下来，使用权重参数，您可以将流量定向到两个 Pod，忽略每个 Pod 中运行的微服务实例的数量。 例如，这里我们将 90% 的流量定向到 v1，将 10% 定向到 v2：
为移动用户提供单独的路由
总之，我们将展示如何强制移动用户流量路由到服务 v2，并将其他用户流量路由到 v1。 为此，我们使用正则表达式来分析请求标头中的用户代理值：
现在轮到你
用于解析标头的正则表达式示例应该会激励您找到自己对 Istio 路由规则的使用。 此外，这里的可能性非常广泛，因为标头值可以在应用程序源代码中形成。
请记住，是运维，而不是开发
我们在上面的示例中展示的所有内容都是在没有对源代码进行丝毫更改的情况下完成的，除了需要生成特殊请求标头的情况之外。 Istio 对于开发人员（例如，可以在测试阶段使用它）和 IT 系统操作专家（对于他们来说，它将在生产中提供极大帮助）都很有用。
让我们重复一下这一系列文章的主题： 您不需要更改代码中的任何内容。 无需构建新映像或启动新容器。 所有这些都是在代码之外实现的。
动用你的想象力
想象一下使用正则表达式进行标头分析的可能性。 想要将您最大的客户重定向到您的特殊版本 ？ 容易地！ 需要 Chrome 浏览器的单独版本吗？ 没问题！ 您可以根据几乎任何特征来路由流量。
亲自尝试一下
阅读 Istio、Kubernetes 和 OpenShift 是一回事，但为什么不亲自接触所有内容呢？ 团队 我们准备了详细的指南（英文），帮助您尽快掌握这些技术。 该手册也是 100% 开源的，因此它发布在公共领域。 该文件适用于 macOS、Linux 和 Windows，源代码有 Java 和 Node.js 版本（其他语言版本即将推出）。 只需在浏览器中打开对应的git仓库即可 .
在下一篇文章中：我们完美地解决了问题
今天您了解了 Istio 路由规则的功能。 现在想象同样的事情，但仅与错误处理有关。 这正是我们将在下一篇文章中讨论的内容。
来源： habr.com