开源服务网格框架 Kuma 可应用于任何平台

与其他控制平面不同的是，Kuma 天生就可以在任何平台上运行。它既适用于现有的棕地应用程序（即如今已经在提供商业价值的应用程序），也适用于新的现代化绿地应用程序。Kuma 很容易使用，任何人都可以通过三个简单的步骤实施 Kuma。

Kuma 是什么？

Kuma 是一个面向服务网格和微服务的通用开源控制平面。它天生就可以在 Kubernetes 和 VM 环境中运行和操作，组织中的每个团队都可以轻松地采用它。

Kuma 以Envoy为基础构建，可以用于管理任何 L4/L7 流量，保护、观察、路由及增强任何服务或数据库之间的连接。它可以通过 CRD 在 Kubernetes 本地使用，也可以通过 RESTful API 在其他环境中使用，而且不需要更改应用程序的代码。

Kuma 在大多数情况中使用起来都很容易，同时，它还提供了以更细粒度的方式配置底层 Envoy 数据平面的策略。这既满足了初次使用服务网格的用户，也满足了经验最丰富的用户。

Kong 根据 150 多个在生产环境中运行服务网格的企业组织的反馈构建了 Kuma。Kuma 实现了一种与第一代控制平面迥异的实用方法：

• 跨组织运行的操作开销低

• 支持所有平台

• 它基于 Envoy 提供的可靠的网络基础，而且易于使用

为什么是 Kuma？

在构建任何软件架构时，我们都会不可避免地引入通过在网络上发出请求来实现彼此通信的服务。

例如，考虑任何与数据库通信以存储或检索数据的应用程序，或者考虑一个更复杂的面向微服务的应用程序，它们为了执行操作都要向不同的服务发出许多请求：

每当我们的服务通过网络请求互连时，我们都将最终用户的体验置于风险之中。我们都知道，不同服务之间的连接可能很慢，而且无法预测。它可能不安全，难以跟踪，并会引发许多其他的问题（例如路由、版本控制、金丝雀部署）。

针对这种情况，开发人员通常采取以下一种措施：

• 编写更多代码：开发人员构建一个智能客户端，每个服务都必须以库的形式使用该客户端。通常，这种方法会带来以下几个新问题：

• 导致了更多技术债务

• 通常特定于具体的语言，妨碍了创新

• 库有多种实现，长远来看会导致碎片化

• 挎斗（Sidecar）代理：服务将所有连接性和可观察性关注点委托给进程外运行时，后者位于每个请求的执行路径上。它将代理所有发出的连接并接受所有传入的连接。使用这种方法，开发人员就不需要关心连接性，而只需要关注业务价值交付。

挎斗代理：它之所以被称为挎斗代理，是因为它是同一主机上与我们的服务进程并行运行的另一个进程，就像摩托车跨斗一样。服务的每个运行实例都将有一个挎斗代理实例，由于所有传入和传出的请求——以及它们的数据——总是通过挎斗代理，所以它也被称为数据平面（DP）。

挎斗代理模型需要一个控制平面，使团队可以配置数据平面的行为并跟踪其服务的状态。采用挎斗代理模型的团队要么从头开始构建一个控制平面，要么使用市场上现有的通用控制平面，比如 Kuma。

与数据平面（DP）不同，控制平面（CP）并不位于服务交互请求的执行路径上，它用于配置数据平面并从中检索数据（如可观察性信息）。

服务网格：一种由数据平面（DP：和服务平行部署的挎斗代理）和控制 DP 的控制平面（CP）组成的架构。通常，服务网格出现在 Kubernetes 上下文中，但是任何人都可以在任何平台上构建服务网格（包括 VM 和裸机）。

使用 Kuma，我们的主要目标是减少构建可靠的架构所必须编写和维护的代码。因此，Kuma 采用了挎斗代理模型，利用 Envoy 作为其挎斗数据平面技术。

通过将所有的连接性、安全性和路由问题外包给挎斗代理，我们可以获得以下好处：

• 加速应用程序构建

• 专注于服务的核心功能，推动更多业务

• 通过减少碎片化构建更安全的标准化架构

通过减少团队需要编写和维护的代码，我们可以一点一点地实现应用程序的现代化，而不需要花费太多精力。

要进一步了解如何在现有的架构中通过 Kuma 实现应用程序的现代化，请点击这里。

比较 Kuma 与其他 CP

当服务网格在 2017 年前后第一次成为主流时，为了支持这个新的架构模式的首次实现，一些大大小小的组织发布了一些控制平面。

虽然人们在早期对这些控制平面投入了大量的热情，但它们都缺乏实用性，无法在现有组织中开启一段可行的服务网格采用之旅。这些第一代解决方案有如下特点：

• 仅限于绿地应用：专注于新开发的应用程序，无法提供在 VM 和裸机平台上（当前业务除 Kubernetes 之外的运行之地）运行的现有工作负载的现代化之旅。

• 使用复杂：服务网格并不一定非常复杂，但是早期的实现确实很难使用；它们的文档很差，也没有明确的升级路径来减轻破坏性的更改。

• 难以部署：有许多活动部件需要同时实现最佳运行状态，较高的操作成本所带来的副作用使得运行和扩展服务网格变得更加困难。

• 适用于爱好者而不是组织：缺乏对当今企业组织面临的挑战的理解，支撑力不够而且实现模型也很差。

Kuma 今天的存在就是为整个组织和每个团队提供一个实用的服务网格实现之旅：既面向运行在现代 Kubernetes 环境中的应用程序，也面向运行在更传统平台（如虚拟机和裸机）上的应用程序。

• 通用、Kubernetes-Native：平台无关，可以在任何平台上运行和操作

• 易于使用：提供自动化功能，服务网格策略学习曲线平缓

• 易于部署：一步部署，可以跨 Kubernetes 和其他平台

• 企业就绪：已经是一个可以为企业交付价值的实用平台

实时支持：Kuma 社区提供了实时沟通和支持的渠道，您可以在我们的社区页面中找到。它还提供由Kong提供的专门的企业支持。

赋能现代化

到目前为止，服务网格一直被认为是架构现代化的最后一步，而在此之前，架构已经转换到容器或 Kubernetes。这种方法完全向后兼容。这使得服务网格的采用和业务价值只有在实现了其他大规模转换之后才能实现，而与此同时，这些转换可能会出错。

实际上，我们希望服务网格在实现其他转换之前已经可用，这样我们就可以在这个过程中保证网络的安全和可观察性。使用 Kuma，服务网格实际上是迈向现代化的第一步。

与其他控制平面不同的是，Kuma 天生就可以在任何平台上运行，没有范围限制（如仅限 Kubernetes）。Kuma 既适用于现有的棕地应用程序（即如今已经在提供商业价值的应用程序），也适用于新的现代化绿地应用程序，这是我们未来的前进方向。

与其他控制平面不同，Kuma 很容易使用。任何人（来自任何团队）都可以通过三个简单的步骤跨传统的单体应用程序和现代化的微服务实施 Kuma。

最后，通过开箱即用的策略和 Kuma 强大的标签选择器，我们可以在各种拓扑中实现各种行为，类似于多云和多区域架构。

原文链接：

https://kuma.io/docs/0.1.0/#what-is-kuma