Service Mesh：Istio1.0在Openshift3.10上的实践

1、实验环境

实验环境使用最新版本的Openshift：V3.10.

Istio使用最新V1.0版本

Istio已经以容器的方式，部署到Openshift的一个项目中：

查看项目中的pod：

查看mvn的版本：

浏览器登陆Openshift 3.10：

2、部署三个微服务

本实验中有三个微服务，它们按如下顺序连接在一块儿，具备以下的调用关系：

gateway（网关） -> partner（合做伙伴） -> catalog(目录服务)

部署目录服务版本1（v1）

Istio引入了服务版本的概念，这是一种经过版本（v1，v2）或环境（staging，prod）细分服务实例的更细粒度的方法。 这些变体不必定是不一样的API版本：它们能够是对同一服务的迭代更改，部署在不一样的环境（prod，staging，dev等）中。 使用它的常见方案包括A / B测试或金丝雀发布。 Istio的流量路由规则能够引用服务版本，以提供对服务之间流量的额外控制。

如今让咱们首先将目录服务部署到OpenShift,sidecar代理将自动注入。

首先经过maven编译一个jar，而后经过docker build的方式，将jar部署到docker image中：

为目录服务建立docker镜像。 此外，验证映像是否位于本地docker存储库中。

首先查看Dockerfile：

sudo docker build -t example/catalog:v1 . sudo docker images | grep example/catalog

部署目录服务并注入istio sidecar。

因为目录服务位于咱们的服务链（网关 - >合做伙伴 - >目录）的末尾，所以它不会暴露给外部世界。

部署合做伙伴服务：

为合做伙伴服务建立docker镜像。 此外，验证映像是否位于本地docker存储库中。

sudo docker build -t example/partner:v1 . sudo docker images | grep example/partner

部署合做伙伴服务并注入istio sidecar。

部署网关服务：

最后，咱们将网关服务部署到OpenShift。 这将完成咱们的服务列表：

部署网关服务并注入istio sidecar。

因为网关服务是咱们的用户将与之交互的服务，所以咱们添加一个公开该端点的OpenShift路由。

检索网关服务的URL

测试网关服务

gateway => partner => catalog v1 from '57bcbf87dc-cslxn': 1

3、带有Istio的动态路由测试

随着基于微服务的应用程序变得愈来愈流行，它们的交互的数量和复杂性都会增长。 到目前为止，管理这些复杂的微服务交互的大部分负担已经放在应用程序开发人员身上，根据语言和框架对微服务概念提供不一样或不存在的支持。

服务网格概念将此职责推向基础架构，具备流量管理，分布式跟踪和可观察性，策略实施和服务/身份安全性等功能，使开发人员可以专一于业务价值。 在本次实践课程中，您将学习如何将这些功能中的一些应用于使用Istio开发的基于OpenShift的简单多语言微服务应用程序，Istio是一个链接，管理和保护微服务的开放平台。

Istio是一个链接，管理和保护微服务的开放平台。 Istio提供了一种经过负载平衡，服务到服务身份验证，监控等建立已部署服务网络的简便方法，无需对应用程序代码进行任何更改。 OpenShift能够在您的环境中自动注入特殊的边车代理，以便为您的应用程序启用Istio管理。 此代理拦截您的微服务微服务之间的全部网络通讯，并使用Istio的控制平面功能进行配置和管理 - 而不是您的应用程序代码

本实验中有三个微服务，它们按如下顺序连接在一块儿：

网关 - >合做伙伴 - >目录

在本实验中，您将使用Istio动态更改服务之间的路由。

部署目录服务版本2（v2）

修改应用的源码：

mvn clean package 

sudo docker build -t example/catalog:v2 .

部署目录服务版本2

您可使用如下命令查看运行的两个版本的目录窗格：

默认状况下，Istio会将传入的请求循环到目录服务，以便v1和v2 pod都得到相同数量的流量。

将全部流量发送到目录：v2

路由规则控制请求在Istio服务网格中的路由方式。

能够根据源和目标，HTTP标头字段以及与各个服务版本关联的权重来路由请求。例如，路由规则能够将请求路由到不一样版本的服务。

除了常见的OpenShift对象类型（如BuildConfig，DeploymentConfig，Service和Route）以外，还有新的对象类型做为Istio的一部分安装，如RouteRule。将这些对象添加到正在运行的OpenShift集群是如何为Istio配置路由规则。

DestinationRule定义在路由发生后应用于服务的流量的策略。这些规则指定负载平衡的配置，来自sidecar的链接池大小，以及异常检测设置，以从负载平衡池中检测和驱逐不健康的主机。

VirtualService定义了一组要在主机被寻址时应用的流量路由规则。每一个路由规则定义特定协议的流量的匹配标准。若是流量匹配，则将其发送到注册表中定义的命名目标服务（或其子集/版本）。流量来源也能够在路由规则中匹配。这容许为特定客户端上下文定制路由。

istiofiles/virtual-service-catalog-v2.yml

此定义容许您配置必定百分比的流量并将其定向到特定版本的目录服务。 在这种状况下，目录服务的100％流量（权重）将始终转到与标签版本匹配的pod：v2。 这里的pod的选择很是相似于基于标签的Kubernetes选择器模型。 所以，尝试与目录服务通讯的服务网格中的任何服务将始终路由到目录服务的v2。

使用配置文件将全部流量路由到v2：

oc create -f istiofiles/destination-rule-catalog-v1-v2.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin 

oc create -f istiofiles/virtual-service-catalog-v2.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

将全部流量发送到目录：v1

配置必定比率的访问：

4、断路器实验室

本实验介绍了如何注入错误并测试应用程序的弹性。 Istio提供了一组故障恢复功能，能够经过应用程序中的服务进行利用。 功能包括：

Pool Ejection出或异常值检测是一种弹性策略，只要咱们有一个实例/ pod池来为客户端请求提供服务，就会发生这种策略。 若是请求被转发到某个实例而且它失败（例如返回50x错误代码），那么Istio将从池中弹出该实例以得到某个sleep windows。 在咱们的示例中，睡眠窗口配置为15秒。 经过确保只有健康的pod参与实例池，这能够提升总体可用性。

首先，您须要确保有一个目标规则和虚拟服务，以便向服务发送流量。

oc create -f istiofiles/destination-rule-catalog-v1-v2.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin 

oc create -f istiofiles/virtual-service-catalog-v1_and_v2_50_50.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

测试行为没有失败的实例：

将一些请求发送到网关服务：

您应该看到两个不一样版本的目录服务之间的负载平衡50/50。

在v2版本中，您还会看到一些请求由一个pod处理，一些请求由另外一个pod处理。

一样是版本v2，全部请求都有三秒钟的延迟。 所以测试运行须要更长的时间。

测试具备失败实例且没有Pool Ejection的行为

如今咱们将链接到一个pod并在其上添加一些不稳定的行为。

使用如下命令链接到其中一个pod：

上面的操做，至关于触发应用中的源码变动，让这个pod被访问的时候，永远会报错：

测试具备失败实例和Pool Ejection的行为

若是请求被转发到某个实例而且它失败（例如返回50x错误代码），那么Istio将从池中弹出该实例以得到某个睡眠窗口。 在咱们的示例中，睡眠窗口配置为15秒。 经过确保只有健康的pod参与实例池，这能够提升总体可用性。

如今让咱们添加Pool Ejection行为：

oc replace -f istiofiles/destination-rule-catalog_cb_policy_pool_ejection.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

再次发起请求，咱们看到，出现一次报错后，被Pool Ejection，就再也不报错了：

在被Pool Ejection后，并睡眠窗口到期以前它再也不接收任何请求 - 这至少须要15秒。

等待15秒再次运行测试。 您偶尔会看到503错误，但在第一次尝试后它将在15秒窗口期间消失。

具备重试、断路器和池Pool Ejection的终极弹性解决方案

即便有Pool Ejection，你的应用程序看起来也不那么有弹性， 这多是由于咱们仍然让一些错误传播给咱们的客户。 但咱们能够改善这一点。 若是咱们有足够的实例和/或特定服务版本运行到咱们的系统中，咱们能够结合多个Istio功能来实现最终的后端弹性：

• 断路器以免对实例的多个并发请求

• Pool Ejection从响应实例池中删除失败的实例

• 重试将请求转发给另外一个实例，以防万一咱们获得开路断路器和/或池弹出;

经过简单地向咱们当前的虚拟服务添加剧试配置，咱们将可以彻底摆脱咱们的`503的请求。 这意味着每当咱们从弹出的实例收到失败的请求时，Istio会将请求转发给另外一个能够保持健康的实例。

添加剧试配置

oc replace -f istiofiles/virtual-service-catalog-v1_and_v2_retry.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

再次发起请求，咱们不会再收到503的了。 可是目录`v2的请求仍然须要更多时间才能获得回复。所以被Pool Ejection的pod的请求，将会被转发到好的pod实例。