跳到主要内容

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框架。后续文章我们将详细讲解如何制作插件,尽请关注。