跳到主要内容

Istio在Rainbond Service Mesh体系下的落地实践

· 阅读需 12 分钟

两年前Service Mesh（服务网格）一出来就受到追捧，很多人认为它是微服务架构的最终形态，因为它可以让业务代码和微服务架构解耦，也就是说业务代码不需要修改就能实现微服务架构，但解耦还不够彻底，使用还是不方便，虽然架构解耦了，但部署还没有解耦。

  • 无法根据不同环境或客户需要选择合适的Service Mesh框架。
  • 无法做到在开发环境不用学习和使用Service Mesh，生产环境按需开启。

插件式 Service Mesh架构实现思路​

目前成熟的ServiceMesh框架也有许多，但是对于用户而言。并不存在万能的ServiceMesh框架，可以解决各种场景的问题。因此我们希望对于用户而言，他只需要关心自己的业务代码。而应用的治理能力，则可以通过不同的ServiceMesh框架进行拓展。用户的业务代码与ServiceMesh框架完全解耦。如下图所示。用户可以随时替换某个应用所使用的ServiceMesh架构。选择与业务最匹配的解决方案。

image-20211211180131913

基于以上思路，我们可以将istio、linkerd、dapr等微服务架构做成插件，开发过程中完全不需要知道Service Mesh框架的存在，只需要处理好业务的依赖关系，当交付到生产环境或客户环境，有些需要性能高、有些需要功能全、有些客户已经指定等各种差异化需求，根据环境和客户需要按需开启不同类型的插件即可，当Service Mesh框架有问题，随时切换。这样Service Mesh框架就变成赋能的工具，老的业务系统重新部署马上就能开启服务治理能力。

Rainbond就是基于上述思路实现的，当前版本已经实现了三个服务治理插件。

  • kubernetes 原生Service 模式
  • 基于envoy的Service Mesh模式
  • Istio服务治理模式

后面我们详细讲解Istio服务治理模式的使用过程。

使用Istio治理模式的实践​

有了以上概念，我们可以来看看Rainbond如何与Istio结合。在Rainbond中，用户可以对不同的应用设置不同的治理模式，即用户可以通过切换应用的治理模式，来按需治理应用。这样带来的好处便是用户可以不被某一个ServiceMesh框架所绑定，且可以快速试错，能快速找到最适合当前业务的ServiceMesh框架。

安装Istio 控制面（control plane）​

首先在切换到Istio治理模式时，如果未安装Istio的控制面，则会提示需要安装对应的控制面。因此我们需要安装Istio的控制面，控制面在一个集群中只需安装一次，它提供了统一的管理入口，用来管理工作在Istio治理模式下的服务。完成配置下发等功能。结合Rainbond现有的helm安装方式，我们可以便捷的安装好对应的组件。

1. 创建团队​

在5.5.0版本中，我们支持了用户在创建团队时指定命名空间。由于默认helm安装的命名空间为 istio-system ，所以为了减少用户配置。我们首先需要创建出对应的团队。如下图所示。团队英文名对应的则是该团队在集群中的命名空间。此处填写 istio-system 。

image-20211212203716453

2. 对接商店​

Rainbond支持基于helm直接部署应用，所以接下来对接Rainbond官方helm仓库，后续基于Helm商店部署Istio即可， 在应用市场页面，点击添加商店，选择helm商店，输入相关信息即可完成对接。

商店地址：https://openchart.goodrain.com/goodrain/rainbond

image-20211212203208140

3. 安装 Istio 控制面​

商店创建完成后，即可看到对应的 helm 应用，目前Rainbond提供了 istio 1.11.4 版本的helm包，根据 Istio官方文档，该版本对Kubernetes集群的版本支持为 1.19, 1.20, 1.21, 1.22。

  • 安装 base 应用

    选择helm商店中的base应用进行部署，团队选择之前创建的命名空间为 istio-system 的团队。该应用包主要部署了Istio相关的集群资源和 CRD 资源。

    image-20211212204419466

  • 安装 istio-discovery 应用**

    同上述base应用一样，选择正确的团队。安装 istio-discovery 应用。有了这两个应用，就可以拥有 Istio 基础的治理能力了。

示例应用开启Istio治理模式​

1. 切换治理模式​

我们以SpringBoot后台管理系统 若依 为例，如下图所示，用户可以先从开源应用商店安装一个 若依SpringBoot 应用，版本选择3.6.0，点击治理模式切换，选择Istio治理模式。

image-20211212205811460

在点击切换为Istio治理模式后，会需要用户手动设置内部域名，此处的内部域名将会是该组件在Kubernetes集群中的service名称，在同一个团队下唯一。这里我们修改为可读性较高的内部域名。

image-20211212210008895

2. 修改配置文件​

在这一步完成后，我们还需要进入 ruoyi-ui 挂载一个新的配置文件。这主要是因为默认情况下，ruoyi-ui 的配置文件 web.conf 中后端服务地址为 127.0.0.1，在之前使用 Rainbond 内置 ServiceMesh 模式时，由于 Rainbond 会获取到后端服务的地址，注入到 ruoyi-ui 内部, 赋予 ruoyi-ui 一个本地访问地址（127.0.0.1）访问后端服务。所以无需修改就能使用。

但使用 Istio 治理模式时，组件间通过内部域名进行通信，因此需要通过挂载配置文件的方式修改对应的代理地址，ruoyi-ui 的配置文件可以通过右上方的 Web终端 访问到容器中，复制 /app/nginx/conf.d/web.conf 这个文件的内容。修改代理地址后保存，如下图所示。之前我们设置了控制台的内部域名为 ruoyi-admin，所以这里替换为 ruoyi-admin。

image-20211212211158509

3. 重启应用​

在完成以上两步后，我们需要重启整个应用。在启动应用后，进入组件页面查看，应该可以看到每个组件都有一个类似的 Sidecar 容器，这就是Istio的数据面 (data plane)，在应用切换为Istio治理模式以后，该应用下的所有组件都会自动注入对应的 Sidecar 容器，不需要用户额外设置。

至此，该应用已纳入Istio治理范围。用户如果需要对该应用有更多的配置，则可以参考 Istio官方文档 进行扩展。

image

通过Kiali监控和管理Istio​

在之前的步骤中，我们使用 Istio 治理模式纳管了 若依 。接下来则带大家一起看看如何使用 Kiali 观测应用间的通信链路。在这一步中，用户需要有 kubectl 命令。

1. 安装 prometheus​

在Istio中，各个组件通过暴露HTTP接口的方式让Prometheus定时抓取数据（采用了Exporters的方式）。所以Istio控制平面安装完成后，需要在istio-system的命名空间中部署Prometheus，将Istio组件的各相关指标的数据源默认配置在Prometheus中。

同上述base应用一样，选择正确的团队，安装 Prometheus应用。

image-20211214112547510

2. 安装kiali​

kiali提供可视化界面监控和管理Istio，能够展示服务拓扑关系，进行服务配置。

安装 kiali-operator 应用，同上述base应用一样，选择正确的团队。

安装过程将自动创建Service，通过Rainbond平台第三方组件的形式可将 kiali 的访问端口暴露出来。如下图所示：

image-20211212212924071

在端口界面添加访问端口，添加以后打开对外服务使用生成的网关策略即可进行访问。

image

kiali登录时需要身份认证token，使用以下命令获取token：

kubectl describe secret $(kubectl get secret -n istio-system | grep istiod-token |awk '{print $1}') -n istio-system

访问到kiali以后，在Applications一栏，选中应用所在的命名空间，就可以看到我们刚刚创建的应用。点击进入，可以看到如下的流量路线。

image-20211212213849724

在 Graph 一栏，也可以看到对应的应用内的流量请求。更多的配置及相关功能参考 Kiali官方文档image-20211212214035677

总结​

本文简单介绍了在Rainbond中使用Istio治理模式的操作。以及Rainbond与Istio治理模式的结合。Rainbond为用户提供了一个可选的插件体系，使用户可以根据自己的需求选择不同的Service Mesh框架。在与Istio的结合上，我们主要为用户完成了指定应用数据平面的注入。用户也可以通过该机制扩展自己所需的ServiceMesh框架。后续文章我们将详细讲解如何制作插件，尽请关注。