执行如下命令配置 productpage-v1 服务。
打开浏览器，输入 $IP:10501/productpage，可以看到如下结果，也即bookinfo应用发布成功。刷新页面，可以看到review评分的变化。
为了测试数据平面可以动态更新配置，如下更新 bookinfo/reviews 服务的本地端口，并执行。
查看对应数据平面服务的日志，可以看到新的配置更新生效。但是这里的问题在于 productpage 实例本身仍然访问的是之前的 10504 端口，而 Sidecar 此时已无法实现该端口的转发，会导致服务本身的异常。所以总的来说，在 Kuma 的 Universal 模式下，一种比较好的实践是事先做好应用、服务、实例、端口等的规划，升级更新会导致服务的短暂中断。
总结
Kuma 的优势
轻量、轻量、轻量，重要的事情说三遍，几个可执行程序就能很方面的部署服务网格基础架构；
通过显而易见的方式支持多个Mesh，提供比较好的隔离性。
未解决的问题
不支持TrafficRoute、TrafficTracing等重要的功能，所以基本上Kuma还处于不可用状态。
双向认证只支持内建的自签名证书，且只能是在Mesh范围内进行配置。
由于不支持类似Istio中的Ingress、Egress等功能，当开启双向认证时，无法将服务对外发布出去，内部服务也无法访问外部的服务。
为了支持在Universal模式下同时启动多个Envoy，不支持Envoy的热重启。不过，由于xDS配置都是热更新，所以影响并不大。
在Universal模式下，不支持服务注册和发现，用户需要逐个为服务配置依赖应用的outbound入口，而且由于没有集成DNS，服务间访问需要指定到IP:Port，而不是像Istio一样指定Service Name即可。在Kubernetes模式下，则是依赖了Service的机制，可以将Hostname或Service Name解析为ClusterIP，随后发起的HTTP/TCP请求进入到Sidecar中以后再进行转发。
服务启动的过程中尽量不要访问依赖的服务，此时可能由于Sidecar及数据平面未配置好，导致服务启动失败。
查看Envoy的config_dump可以看到，当前都是以TCP连接的模式进行管理，完全没有发挥出Envoy的强大能力。
Universal模式下配置数据平面对象、启动Sidecar服务等方式都是需要管理员手工命令操作，更方便和人性化的包装也是必须的。
经过这次测试，我们可以看到 Kuma 当前还处于项目的初始阶段，但总的来说技术方向还是不错的。它不像 Istio 一下子就上一套大而全的功能，学习曲线来说比较平缓，可以让大家很好的理解服务网格技术能给大家带来的便利，以及其中存在的技术难点。
当前阻碍服务网格技术应用的原因之一是对历史遗留系统的支持。通常来说，我们需要对老的系统经过两次改造，第一次是容器化，使之能够运行在Kubernetes上，第二次则是对RPC框架的拆解或完全替换。
如果服务网格能够支持非容器场景，则至少工作还能减少一半。我们知道Istio在从v1.3版本开始，开始支持网格扩展，也即将虚拟机或裸金属主机集成到部署在Kubernetes中的Isito集群中。当前支持两种方式，一种是单网络方式，也即虚拟机或裸金属主机通过VPN或VPC连接至Kubernetes内部，另外一种是多网络下通过入口网关实现通讯集成。目前来看，由于Istio本身对Kubernetes的依赖比较重，再加上Istio本身的其它功能都已经相对比较完善，要想增加网格扩展的功能，工作量是比较大的，所以这两种方式都还处于开发状态。