使用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。

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

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

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

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

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

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

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

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

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

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

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

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

总结

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集群中。当前支持两种方式，一种是单网络方式，也即虚拟机或裸金属主机通过***或VPC连接至Kubernetes内部，另外一种是多网络下通过入口网关实现通讯集成。目前来看，由于Istio本身对Kubernetes的依赖比较重，再加上Istio本身的其它功能都已经相对比较完善，要想增加网格扩展的功能，工作量是比较大的，所以这两种方式都还处于开发状态。

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