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