最近, 开源 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 的优势
轻量, 轻量, 轻量, 重要的事情说三遍, 几个可执行程序就能很方面的部署服务网格基础架构;
通过显而易见的方式支持多个 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 本身的其它功能都已经相对比较完善, 要想增加网格扩展的功能, 工作量是比较大的, 所以这两种方式都还处于开发状态.
相对来说, Kuma 则提供了一种在虚拟机或裸金属主机场景下使用服务网格的新思路, 虽然当前功能完成度相对太低, 不过还是值得大家持续关注.
来源: http://www.tuicool.com/articles/iY3Afaf