使用Bookinfo应用测试Kuma服务网格

最近,开源API管理平台Kong服务供应商近日放出了新的开源项目Kuma。本文尝试将 bookinfo 应用部署在 Kuma 网格中,以便帮助大家更好的理解 Kuma 项目。

 

 Kuma是能用于管理服务网络(Service Mesh)的通用控制平台,通过无缝管理4-7层的网络流量、微服务与API,来解决第一代服务网络的技术限制。

 

Kuma 强调其易用性,能确保底层网络的安全性与可观察性,而且即便其提供高级简单的控制界面,但是使用者仍然可以进行更高级的配置。Kuma 集合了快速数据平台与进阶控制平台,让使用者可用简单的指令,就能设置权限、公开指标以及配置路由规则。

 

 

另外,Kuma 采用软件定义安全性,为所有4层流量启用 mTLS,并提供高精细度的流量控制功能,强化4层路由功能,而 Kuma 也能够快速实现追踪与日志记录功能,让用户分析指标进行错误排查。Kuma 可在任意的平台上执行,包括 Kubernetes、虚拟机器、容器、裸机和传统环境,使整个企业组织都能实践原生云端应用。

 

Kuma 利用开源项目 Envoy 开发而成,而 Envoy 则是为原生云端应用程序设计的代理,官方提到,Envoy 目前已经是边缘代理的标准,与服务网络一起,成为原生云端系统的重要实现方法,因为对于越大规模的微服务应用来说,监控、安全性和可靠性就更显得重要。

 

  • 本文中使用的代码可以在 Github 找到(https://github.com/waret/kuma-tutorial)。

 

 

 

 

首先使用如下命令配置控制平面,这里是在控制平面中创建了一个新的名为 bookinfo的Mesh。

 

Xnip2019-09-20_11-39-09.jpg

下图为 Bookinfo 应用的架构图,其中包含 productpage、reviews、details、ratings 等4个服务,另外 reviews 服务提供了三个版本。在这次测试中,我们为每个版本部署一个实例。

 

 

 

在数据平面,为了能在一个服务器中部署所有6个实例,这里为了避免冲突,需要考虑为各个实例合理分配 inbound 和 outbound 的端口,如下所示。

4.jpg

 

需要注意的一点,kuma-v0.1.2 版本中不支持在同一宿主机上部署多个 Sidecar,但是最新的 master 分支上已经做了修改,因此本文后面使用的 kuma 相关命令行程序都是从 master 分支全新编译出来的。

 

执行如下命令配置 ratings-v1 服务。

5.jpg

 

执行如下命令配置 details-v1 服务。

Xnip2019-09-20_10-39-24.jpg

 

这里对 Istio 项目中的 bookinfo 代码进行了修改,以支持配置 RATINGS_PORT 参数,包括下面的 productpage 服务。执行如下命令配置 reviews-v1 服务。

Xnip2019-09-20_10-39-37.jpg

 

执行如下命令配置 reviews-v2 服务。

8.jpg

 

执行如下命令配置 reviews-v3 服务。

Xnip2019-09-20_10-40-04.jpg

 

执行如下命令配置 productpage-v1 服务。

10.jpg

 

打开浏览器,输入 http://$IP:10501/productpage,可以看到如下结果,也即bookinfo应用发布成功。刷新页面,可以看到review评分的变化。

 

为了测试数据平面可以动态更新配置,如下更新 bookinfo/reviews 服务的本地端口,并执行。

Xnip2019-09-20_10-40-49.jpg

 

查看对应数据平面服务的日志,可以看到新的配置更新生效。但是这里的问题在于 productpage 实例本身仍然访问的是之前的 10504 端口,而 Sidecar 此时已无法实现该端口的转发,会导致服务本身的异常。所以总的来说,在 Kuma 的 Universal 模式下,一种比较好的实践是事先做好应用、服务、实例、端口等的规划,升级更新会导致服务的短暂中断。

13.jpg

 

 

总结

 

Kuma 的优势

  1. 轻量、轻量、轻量,重要的事情说三遍,几个可执行程序就能很方面的部署服务网格基础架构;

  2. 通过显而易见的方式支持多个Mesh,提供比较好的隔离性。

 

未解决的问题

 

  1. 不支持TrafficRoute、TrafficTracing等重要的功能,所以基本上Kuma还处于不可用状态。

     

  2. 双向认证只支持内建的自签名证书,且只能是在Mesh范围内进行配置。

     

  3. 由于不支持类似Istio中的Ingress、Egress等功能,当开启双向认证时,无法将服务对外发布出去,内部服务也无法访问外部的服务。

     

  4. 为了支持在Universal模式下同时启动多个Envoy,不支持Envoy的热重启。不过,由于xDS配置都是热更新,所以影响并不大。

     

  5. 在Universal模式下,不支持服务注册和发现,用户需要逐个为服务配置依赖应用的outbound入口,而且由于没有集成DNS,服务间访问需要指定到IP:Port,而不是像Istio一样指定Service Name即可。在Kubernetes模式下,则是依赖了Service的机制,可以将Hostname或Service Name解析为ClusterIP,随后发起的HTTP/TCP请求进入到Sidecar中以后再进行转发。

     

  6. 服务启动的过程中尽量不要访问依赖的服务,此时可能由于Sidecar及数据平面未配置好,导致服务启动失败。

     

  7. 查看Envoy的config_dump可以看到,当前都是以TCP连接的模式进行管理,完全没有发挥出Envoy的强大能力。

     

  8. Universal模式下配置数据平面对象、启动Sidecar服务等方式都是需要管理员手工命令操作,更方便和人性化的包装也是必须的。

 

经过这次测试,我们可以看到 Kuma 当前还处于项目的初始阶段,但总的来说技术方向还是不错的。它不像 Istio 一下子就上一套大而全的功能,学习曲线来说比较平缓,可以让大家很好的理解服务网格技术能给大家带来的便利,以及其中存在的技术难点。

 

当前阻碍服务网格技术应用的原因之一是对历史遗留系统的支持。通常来说,我们需要对老的系统经过两次改造,第一次是容器化,使之能够运行在Kubernetes上,第二次则是对RPC框架的拆解或完全替换。

 

如果服务网格能够支持非容器场景,则至少工作还能减少一半。我们知道Istio在从v1.3版本开始,开始支持网格扩展,也即将虚拟机或裸金属主机集成到部署在Kubernetes中的Isito集群中。当前支持两种方式,一种是单网络方式,也即虚拟机或裸金属主机通过VPN或VPC连接至Kubernetes内部,另外一种是多网络下通过入口网关实现通讯集成。目前来看,由于Istio本身对Kubernetes的依赖比较重,再加上Istio本身的其它功能都已经相对比较完善,要想增加网格扩展的功能,工作量是比较大的,所以这两种方式都还处于开发状态。

 

相对来说,Kuma则提供了一种在虚拟机或裸金属主机场景下使用服务网格的新思路,虽然当前功能完成度相对太低,不过还是值得大家持续关注。

 

posted @ 2019-09-20 15:29 博云技术社区 阅读(...) 评论(...) 编辑 收藏