Kong 开源的服务网格Kuma爬过了K8S这座大山

做者:Dan Meyergit

译者:罗广明github

审校:马若飞api

英文原文地址: https://www.sdxcentral.com/articles/news/kongs-kuma-service-mesh-climbs-the-kubernetes-wall/2019/09/安全

转载自:https://www.servicemesher.com/blog/kong-open-sources-kuma-the-universal-service-mesh/网络

编者按

2019年9月10日,Kong正式宣布开源一款Service Mesh:Kuma。此消息一出,当即在云原生社区引发反响,各大媒体争相报道。让咱们跟随SDxCentral的总编辑,一块儿来看看Kong的CTO如何介绍Kuma这款Service Mesh产品以及对于SMI的见解。关于Kuma的具体功能介绍能够阅读官网博客以及Githubless

翻译一下其Github关于Kuma功能特性的简介以下,方便读者了解:运维

  • 通用的控制平面: 易于使用,分布式,能够在任何平台运行。
  • 轻量的数据平面: 基于Envoy,可处理任意类型流量。
  • 自动化: 在K8s平台上部署无需任何代码改动,也可在虚拟机上灵活部署。
  • 多租户: 可在一个集群与同一个控制平面上部署多套服务网格。
  • 网络安全: 自动mTLS加密。
  • 流量分割: 灵活的ACL规则。
  • 流量追踪: 与Zipkin和Jaeger自动集成。
  • 流量指标: 与Prometheus/Splunk/ELK自动集成。
  • 代理配置模版: 方便进阶(收费)用户配置Envoy。
  • 标签选择器: 可应用不一样地域的、特定于云的和面向团队的策略。
  • 平台中立: 支持K8s, 虚拟机和裸机。
  • 强大的APIM Ingress: 与Kong网关集成。

kuma-architecture

简介

Kong正在将其服务网格平台Kuma打形成一个日益复杂的生态系统,在过去几个月里,许多新加入者和选择涌现出来。分布式

该公司声称Kuma是“一个通用的服务网格”。Kong CTO和联合创始人Marco Palladino解释说,这意味着Kuma不一样于市场上的大多数服务网格项目,它的设计初衷是在Kubernetes生态系统内部和外部都能工做,这包括虚拟机(VMs)、容器、legacy环境以及Kubernetes。微服务

Kuma包括一个基于Envoy服务代理的通用控制平面。它结合了数据平面和进阶的控制平面,容许用户使用本地自定义资源定义(CRDs)或RESTful API设置权限、获取指标和设置路由规则。Palladino解释说,早期第一代的服务网格产品大多缺少成熟的控制平面,须要大量的二次开发或手工定制。性能

他解释说:“咱们但愿90%的用例都易于使用,而且可以快速升级。对于另外10%用例的用户,咱们有一个容许用户深刻使用的策略,”他补充说,尽管Kuma的设计是为了方便使用,“但Kuma是为企业设计的,而不是业余爱好者。”

Kuma的特性包括software-defined security,它支持全部四层通讯流的mTLS身份验证;可以实现追踪(trace)和日志(log)记录,从而更好地分析指标;提供流量控制能力,如断路器和健康检查,以加强四层路由。

Palladino说,Kuma保护底层网络的能力提供了可靠性和更深层次的可观察性,而且无需修改任何代码。

Palladino说:“咱们努力为Kuma构建一个很是平滑渐进的学习曲线。它的复杂度不会在早期压垮开发人员,而且也不会阻止开发人员走得更远。咱们确实为高级用户提供了一个策略来配置底层代理数据平面。”

Kuma还利用了Kong同名的开源API网关。该网关管理组织与部署现代微服务的各类方法之间的信息流。

Kuma加入服务网格竞争行列

Kuma加入了服务网格竞争行列,这个群体与日俱增,声称能够更容易地支持微服务的部署。

Palladino说:“每一个人都告诉咱们,他们想要使用服务网格,但实际上没有一种服务网格易于使用,并且真正适用企业生产环境。许多企业专一于Kubernetes,但对他们来讲,这成为了云原生探索之旅的终点。咱们提供了一个产品,容许他们拥有一个能够更早实现并支持他们迁移的服务网格。”

一个已经引发普遍注意的服务网格平台是Istio。它定位于网络层,使用底层进行微服务开发和维护。这容许将管理运维与应用程序开发分离开来。

Palladino说,Istio帮助照亮了这片天空,但它仍然“很是复杂,有不少活跃的部件”。它在Kubernetes上运行得很好,但并非全部人都在运行Kubernetes。”

他说,这种关注还会影响Linkerd和Containous等其余服务网格的选择,好比最近推出的Maesh平台

“Maesh、Linkerd和其它控制平面网格都高度关注Kubernetes,”Palladino解释说。“只有当企业采用Kubernetes时,它们才会被采用。咱们经过在这一过程的早期创建安全和可观察性,实现了向Kubernetes的过渡。”

还须要努力协调服务网格平台之间的互操做性。其中之一由微软牵头,它在今年早些时候率先推出了服务网格接口SMI规范。它的目标是为开发人员提供运行在Kubernetes上的不一样服务网格技术的互操做性。

Palladino将这种努力淡化为边缘化服务网格功能。

“咱们根本不相信SMI,”他说。“这是将接口标准化的另外一种尝试,让它变得平庸而不优秀。它采用整个社区全部服务网格的公分母,从而下降了它们对最终用户的价值。它界限很宽,但并不深刻。”

Palladino认为Kuma才真正实现了能够在全部平台进行互操做。

Kong以Mashape的名字成立于2009年。2015年,它将Kong平台发布到开源社区,并于去年对旗下全部业务产品正式启用了该平台的名称。该公司已经过5轮融资筹集了6,910万美圆资金,最近一次是在3月份的C轮融资,总额4,300万美圆。

编者后记

当Istio因其性能表现疲软之际,会涌现一个又一个的新玩家,给市场带来竞争与多样性,这也是用户喜闻乐见的。Kong涉足服务网格并不算太意外,咱们能够了解到除了市面上的传统云厂商打造的和开源的各项服务网格产品,Consul Service Mesh的出现也让人眼前一亮。Consul Service Mesh与Kuma背后的厂商均有其成熟的开源产品作强力支撑:Consul的服务发现与注册产品,Kong的网关产品。他们各自在开源社区拥有一片天下,此时推出服务网格产品天然会有一大批“拥趸”。

Kuma的性能较之Istio以及其它服务网格产品的优劣还没有可知,可是其平台中立的思想仍是值得借鉴。当前市场上,K8s并未彻底普及,不少公司的产品都是部署在虚机甚至裸机上,若是此时又想尝试下服务网格技术,Kuma的出现不失为一种惊喜。


ServiceMesher 社区是由一群拥有相同价值观和理念的志愿者们共同发起,于 2018 年 4 月正式成立。

社区关注领域有:容器、微服务、Service Mesh、Serverless,拥抱开源和云原生,致力于推进 Service Mesh 在中国的蓬勃发展。

社区官网:https://www.servicemesher.com

相关文章
相关标签/搜索