《使用Bookinfo应用测试Kuma服务网格》由会员分享,可在线阅读,更多相关《使用Bookinfo应用测试Kuma服务网格(14页珍藏版)》请在金锄头文库上搜索。
1、 使用Bookinfo应用测试Kuma服务网格 Kuma是能用于管理服务网络(Service Mesh)的通用控制平台,通过无缝管理4-7层的网络流量、微服务与API,来解决第一代服务网络的技术限制。Kuma 强调其易用性,能确保底层网络的安全性与可观察性,而且即便其提供高级简单的控制界面,但是使用者仍然可以进行更高级的配置。Kuma 集合了快速数据平台与进阶控制平台,让使用者可用简单的指令,就能设置权限、公开指标以及配置路由规则。另外,Kuma 采用软件定义安全性,为所有4层流量启用 mTLS,并提供高精细度的流量控制功能,强化4层路由功能,而 Kuma 也能够快速实现追踪与日志记录功能,让
2、用户分析指标进行错误排查。Kuma 可在任意的平台上执行,包括 Kubernetes、虚拟机器、容器、裸机和传统环境,使整个企业组织都能实践原生云端应用。Kuma 利用开源项目 Envoy 开发而成,而 Envoy 则是为原生云端应用程序设计的代理,官方提到,Envoy 目前已经是边缘代理的标准,与服务网络一起,成为原生云端系统的重要实现方法,因为对于越大规模的微服务应用来说,监控、安全性和可靠性就更显得重要。 本文中使用的代码可以在 Github 找到(首先使用如下命令配置控制平面,这里是在控制平面中创建了一个新的名为 bookinfo的Mesh。 下图为 Bookinfo 应用的架构图,其
3、中包含 productpage、reviews、details、ratings 等4个服务,另外 reviews 服务提供了三个版本 。在这次测试中,我们为每个版本部署一个实例。在数据平面,为了能在一个服务器中部署所有6个实例,这里为了避免冲突,需要考虑为各个实例合理分配 inbound 和 outbound 的端口,如下所示。需要注意的一点,kuma-v0.1.2 版本中不支持在同一宿主机上部署多个 Sidecar,但是最新的 master 分支上已经做了修改,因此本文后面使用的 kuma 相关命令行程序都是从 master 分支全新编译出来的。执行如下命令配置 ratings-v1 服务。
4、执行如下命令配置 details-v1 服务。这里对 Istio 项目中的 bookinfo 代码进行了修改,以支持配置 RATINGS_PORT 参数,包括下面的 productpage 服务。执行如下命令配置 reviews-v1 服务。执行如下命令配置 reviews-v2 服务。执行如下命令配置 reviews-v3 服务。执行如下命令配置 productpage-v1 服务。打开浏览器,输入 http:/$IP:10501/productpage,可以看到如下结果,也即bookinfo应用发布成功。刷新页面,可以看到review评分的变化。为了测试数据平面可以动态更新配置,如下更新
5、bookinfo/reviews 服务的本地端口,并执行。查看对应数据平面服务的日志,可以看到新的配置更新生效。但是这里的问题在于 productpage 实例本身仍然访问的是之前的 10504 端口,而 Sidecar 此时已无法实现该端口的转发,会导致服务本身的异常。所以总的来说,在 Kuma 的 Universal 模式下,一种比较好的实践是事先做好应用、服务、实例、端口等的规划,升级更新会导致服务的短暂中断。总结Kuma 的优势1. 轻量、轻量、轻量,重要的事情说三遍,几个可执行程序就能很方面的部署服务网格基础架构;2. 通过显而易见的方式支持多个Mesh,提供比较好的隔离性。未解决的
6、问题1. 不支持TrafficRoute、TrafficTracing等重要的功能,所以基本上Kuma还处于不可用状态。2. 双向认证只支持内建的自签名证书,且只能是在Mesh范围内进行配置。3. 由于不支持类似Istio中的Ingress、Egress等功能,当开启双向认证时,无法将服务对外发布出去,内部服务也无法访问外部的服务。4. 为了支持在Universal模式下同时启动多个Envoy,不支持Envoy的热重启。不过,由于xDS配置都是热更新,所以影响并不大。5. 在Universal模式下,不支持服务注册和发现,用户需要逐个为服务配置依赖应用的outbound入口,而且由于没有集成D
7、NS,服务间访问需要指定到IP:Port,而不是像Istio一样指定Service Name即可。在Kubernetes模式下,则是依赖了Service的机制,可以将Hostname或Service Name解析为ClusterIP,随后发起的HTTP/TCP请求进入到Sidecar中以后再进行转发。6. 服务启动的过程中尽量不要访问依赖的服务,此时可能由于Sidecar及数据平面未配置好,导致服务启动失败。7. 查看Envoy的config_dump可以看到,当前都是以TCP连接的模式进行管理,完全没有发挥出Envoy的强大能力。8. Universal模式下配置数据平面对象、启动Sidec
8、ar服务等方式都是需要管理员手工命令操作,更方便和人性化的包装也是必须的。经过这次测试,我们可以看到 Kuma 当前还处于项目的初始阶段,但总的来说技术方向还是不错的。它不像 Istio 一下子就上一套大而全的功能,学习曲线来说比较平缓,可以让大家很好的理解服务网格技术能给大家带来的便利,以及其中存在的技术难点。当前阻碍服务网格技术应用的原因之一是对历史遗留系统的支持。通常来说,我们需要对老的系统经过两次改造,第一次是容器化,使之能够运行在Kubernetes上,第二次则是对RPC框架的拆解或完全替换。如果服务网格能够支持非容器场景,则至少工作还能减少一半。我们知道Istio在从v1.3版本开始,开始支持网格扩展,也即将虚拟机或裸金属主机集成到部署在Kubernetes中的Isito集群中。当前支持两种方式,一种是单网络方式,也即虚拟机或裸金属主机通过VPN或VPC连接至Kubernetes内部,另外一种是多网络下通过入口网关实现通讯集成。目前来看,由于Istio本身对Kubernetes的依赖比较重,再加上Istio本身的其它功能都已经相对比较完善,要想增加网格扩展的功能,工作量是比较大的,所以这两种方式都还处于开发状态。相对来说,Kuma则提供了一种 在虚拟机或裸金属主机场景下使用服务网格 的新思路,虽然当前功能完成度相对太低,不过还是值得大家持续关注。 -全文完-