在 Koyeb,我们的使命是提供在全球范围内部署应用程序的最快方式。我们正在构建一个平台,允许开发人员和企业轻松运行应用程序,一个您无需思考和处理的平台

服务器的弹性和可扩展性:无服务器平台。

具有讽刺意味的是,无服务器平台实际上充满了服务器。作为云服务提供商,我们为您运营基础架构并尽可能抽象

尽可能。

作为云服务提供商,您做出的初始技术选择至关重要。它们不仅决定了您可以开发的功能,还决定了整个平台的弹性和可扩展性。

我们决定构建自己的无服务器引擎,不受现有实现的限制。 Koyeb 的第一个版本建立在 Kubernetes 之上,使我们能够快速构建一个工作的云平台。在使用这个版本几个月后,我们决定将用户工作负载从 Kubernetes 转移到基于 Nomad、Firecracker 和 Kuma 的自定义堆栈。

我们写了这篇博文来解释为什么我们从 Kubernetes 迁移到自定义堆栈来支持我们用户的无服务器工作负载。这篇文章是从我们作为云服务提供商的角度编写的。

1.Koyeb 的要求:Fast, Global, Secure, Scalable

2.构建在右抽象层之上

3.Kubernetes 的限制

4.Koyeb Serverless Engine 背后的堆栈:Nomad、Firecracker、Kuma on BareMetal... 和 Kubernetes

Koyeb 的要求:快速、全球化、安全、可扩展

在深入研究技术之前,让我概述一下导致我们今天所处的位置的要求。

在 Koyeb,我们正在构建下一代无服务器平台,这应该是全球部署应用程序的最快方式。我们要实现四个核心支柱:

• Fast:我们希望平台在您部署应用程序和运行应用程序时都快。我们认为部署软件更新需要几分钟或几秒钟的时间。没有开发人员愿意在部署升级之前等待数十分钟,尤其是在开发或预生产环境中工作时。执行速度也应该很快,并且云中的工作负载不应该比笔记本电脑上的慢。

• 全球:对于企业而言,在 2021 年全球部署很少是可选的,而且这绝对不是我们的选择,因为我们在世界各地都有客户。无论您是运营全球 B2C 品牌还是 B2B 公司,如果您的用户遍布全球,您需要一种简单有效的方式在多个地区进行运营。合规性和性能是这里的两个驱动因素。

• 安全:作为云服务提供商,安全性至关重要,尤其是在我们运营多租户环境时。在主机和网络级别,客户之间的隔离应该是可靠的。从用户的角度来看,安全性应该是内置的,而不应该是一种选择。

• 可扩展:为了在市场上具有竞争力,我们需要为最终用户提供可扩展的平台,并且我们需要构建一个能够支持您的增长和我们自身增长的平台。我们已经经历了前世](https://blog.scaleway.com/scaleway-is-growing-too-fast-out-of-stock/)与成长[挣扎的痛苦。为了更好地支持我们在世界各地的客户,我们希望能够根据位置在不同的云服务提供商上运行并尊重主权要求。

现在我们有了一个需求列表,让我们转到技术选项。

在右抽象层之上构建

选项

我们考虑构建所有级别的抽象

一个功能齐全的平台,能够支持我们的使命和要求。我们有大约 4 个选项,下面是从最高抽象级别排序的列表

直接处理硬件的一种:

1. 云提供商原语:建立在云提供商的顶级高级功能和容器原语之上

2. Kubernetes:使用 Kubernetes 为我们的用户工作负载提供动力

3. VM 或 BareMetal:在虚拟机或 BareMetal 服务器之上构建专门构建的解决方案

4. 货架:运营我们自己的物理基础设施和网络(又名货架 BareMetal 机器)

我们自己的用户在部署和操作他们的生产应用程序时面临同样的选择。他们中的大多数人会排除选项 3 和 4 因为这些与

现在大多数企业。

我们认为,任何不从事基础设施业务的人都应该尝试在 Koyeb 等高级提供商的基础上构建,也就是选项 1。

我们的首选:Kubernetes 来拯救

我们很快排除了机架服务器(选项 4)。我们一直从事架设甚至构建 BareMetal 服务器的业务

在之前,但现在有足够的选项可供选择,至少满足我们当前的需求。 2021 年,构建软件通常需要依赖云服务提供商。我们也不例外,因为我们在其他云服务提供商之上构建云服务提供商。

我们还排除了在云服务提供商的高级抽象之上构建(选项 1),因为它不能提供我们需要的控制。这个选项可能会让我们更快地开发功能,但我们的平台也会受到同样的影响产品限制作为这些抽象。由于我们的目标是消除这些限制以改善用户的部署体验,因此这种选择会适得其反。

考虑到这一点,我们开始在 Kubernetes 之上构建,相信这将是快速构建满足我们要求的可靠平台的正确抽象层。剧透警报,几个月后,我们决定构建一个专门构建的解决方案......

Kubernetes 的极限

在 Koyeb,我们已经运营 Kubernetes 集群两年了,一旦我们开始支持自定义用户功能和容器,我们就开始看到限制。

以下是我们开始达到的限制的广泛概述:

• 复杂性: 让我们从您可能听到的最常见的抱怨开始:它很复杂。在我们的例子中,我们需要能够扩展核心。即使运营云平台是您的业务,了解 Kubernetes 的工作原理以及为什么以这种方式实施也很困难。

• 安全性: Kubernetes 提供了一些选项来隔离多租户无服务器工作负载。我们首先使用gVisor,但性能令人失望。我们决定使用Firecracker进行探索,但在 Kubernetes 上运行 Firecracker 是实验性的。

• 全球和多区域部署: Koyeb 上的用户工作负载需要能够在多个区域中运行。 Kubernetes 不支持开箱即用的多区域。使用 Kubernetes 实现多区域需要为每个区域部署一个完整的集群,并为每个数据中心配备一个专用的控制平面。

• 可扩展性: 众所周知,Kubernetes 在集群中的节点数量方面存在限制,这意味着在大规模运行时需要非常快速地实现多集群支持。

• 可升级性: 发布周期非常短,这很好,但在生产中难以管理。必须每两个月升级一次,这意味着测试和验证升级不会很快破坏生产,这将成为一项全职工作。

• 开销: Kubernetes 集群往往有相当大的开销。在每个管理程序上,Kubelet 使用 10% 到 25% 的 RAM,这是一个不可忽略的成本。剧透警告:我们的新架构大约有 100MB。

Kubernetes:一个多面手的编排平台

早在 2010 年代初期,由于 Docker 甚至不存在,炒作的程度更多的是OpenStack,但 Kubernetes 是同一种项目:一个通用的编排平台。

根据我们作为云服务提供商的经验,当您处理大型通用软件项目时,您倾向于

遇到同样的问题:

• 一旦你开始扩展或尝试在这样的平台上开发高级功能,你需要完全了解内部结构

• 您花费大量精力尝试进行可能与您无关的升级,破坏您的集成,并且您因无法控制的决定而受苦

不要误会,Kubernetes 确实帮助我们快速开发了第一代 Koyeb 引擎。部署预先编写的 Helm 图表的能力是部署现有软件的强大工具。

作为云服务提供商,我们知道我们最终会达到极限,要么需要深入研究 Kubernetes 并在其核心内部做出贡献,要么以不同的方式设计 Koyeb 平台......

Koyeb 背后的堆栈:Nomad、Firecracker、Kuma on BareMetal... 和 Kubernetes

考虑到所有这些限制,我们开始重新设计平台以支持我们的目标。

经过一些测试,我们决定使用强大的技术组合来构建我们的无服务器平台。在 BareMetal 和 Kubernetes 上输入 Nomad、Firecracker 和 Kuma。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--BvaLylcg--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// www.koyeb.com/static/images/blog/koyeb-achitecture-core-components.png)

整体架构

要了解我们为什么要结合这些技术,让我们退后一步。

在 Koyeb 平台上,有两个关键部分:

• Koyeb Control Plane 由app.koyeb.com和相关数据库背后的 Go API 组成。它接收 API 调用并处理所有逻辑,以在 Koyeb 数据平面上有效地部署应用程序。它需要 24x7x365 运行,其要求与 Koyeb 上用户的要求非常相似。

• Koyeb 数据平面 托管已部署用户的应用程序。它是平台的核心,需要支持在数千个虚拟机管理程序中运行数百万个容器。这是平台中要求最高的部分。

在数据平面的每个管理程序上,有 4 个主要元素:

• 容器运行时和虚拟化技术,Firecracker,有效执行应用程序,确保多租户工作负载以高性能方式隔离和保护

• 网络技术,由 Kuma 和 Envoy 组成,提供服务网格和发现引擎,实现服务之间的无缝私有网络

• 编排引擎,Nomad,在部署发生或扩展事件发生时执行所有配置操作

• 操作系统和服务器,高端 BareMetal 服务器上的 CoreOS,应用程序以尽可能低的开销运行

[](https://res.cloudinary.com/practicaldev/image/fetch/s--4JECcMHY--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://www .koyeb.com/static/images/blog/koyeb-achitecture-stack-ultra-simplified.png)

控制平面运行在......Kubernetes。由于我们无法在 Koyeb 上运行 Koyeb 控制平面以避免循环依赖,因此我们在 Kubernetes 之上运行 API。

潜入 Nomad、Firecracker 和 Nomad

Nomad 用于容器编排

Nomad是一个工作负载编排引擎,可用于跨云管理容器和非容器化应用程序。

Nomad 让我们可以部署和管理在平台上运行的容器化应用程序。它提供 Firecracker microVM 并与 containerd 通信以管理和运行容器。

我们选择 Nomad 进行编排,因为与 Kubernetes 相比,它是:

• 易于扩展。运行时可以轻松自定义,并且使用自定义游牧驱动程序与 Firecracker 无缝集成。

• 使用更简单。该项目的范围要小得多,它并没有涵盖从运行时到网络的所有内容,而这正是我们所需要的。

• 开箱即用的多区域,简化了我们使无服务器工作负载全球化的方式。

• 易于实现区域级别的控制平面,减少了每个区域 Kubernetes 集群的开销。

• 占用空间更小,易于扩展。

Firecracker 用于虚拟化

Firecracker是一种轻量级虚拟化技术,旨在安全高效地运行多租户无服务器工作负载。我们需要一种虚拟化技术

将保持我们客户的工作负载安全和隔离,并在不影响性能的情况下为新实例提供快速启动时间。这正是 Firecracker 所做的。

如果您想深入了解,我们已经在之前的博客文章中写了大约Firecracker MicroVM。

主要好处是:

• 多租户安全和隔离,

• 由于低开销,裸机机器上的高密度,

• 自动扩展微服务和功能的快速启动时间

在我们的帖子我们喜欢 Firecracker MicroVM 的 10 个原因中,我们详细介绍了其他一些好处。

Kuma 用于服务网格控制平面

Kuma是一个基于Envoy的开源服务网格。它是一个控制平面,连接在 Kubernetes 和 VM 上运行的分布式服务。

我们构建 Koyeb 来托管分布式和微服务架构。分布式架构需要一种方法来连接其中运行的服务。服务网格是专用的基础设施层,负责在容器化和微服务应用程序中的服务之间进行安全、快速和可靠的通信。

有关服务网格的更多信息,请查看我们关于服务网格和微服务的帖子。

Kuma 是一种罕见的服务网格,它与其工作负载调度程序没有紧密耦合。这将其与仅适用于 Kubernetes 的其他服务网格(如 Linkerd 和 Istio)区分开来。此外,Kuma 开箱即用地支持多区域和与云无关。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--3DBOPjfO--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:/ /www.koyeb.com/static/images/blog/koyeb-achitecture-stack-ultra-simplified-mesh.png)

Kuma 控制平面使我们能够保护、观察和管理微服务网络。 Koyeb 上的每个服务实例旁边都有一个 Envoy 代理。这些代理构成了连接到 Kuma 控制平面的数据平面。

代理是从控制平面配置的,这意味着您的实例应该知道的 DNS 主机名、它们的重试策略等都从控制平面与代理通信。

Kuma 和 Envoy 为我们提供了私有网络的绝佳选择,尤其是因为它们:

• 与平台无关,

• 支持多区域多云部署,

得益于原生 TLS 加密和 mTLS 身份验证,* 可以在零信任网络环境中运行,

• 提供服务之间的本机安全通信。

Koyeb 无服务器平台是专门构建的

我们将 Koyeb 构建为一个安全且功能强大且对开发人员友好的无服务器平台。提供这种无服务器体验需要以安全且资源高效的方式在裸机服务器上运行多租户工作负载。

从 Kubernetes 迁移到 Nomad、Firecracker 和 Kuma 的定制堆栈使我们能够提供我们为无服务器未来设想的无服务器体验。

您可以使用 Koyeb 托管 Web 应用程序和服务、Docker 容器、API、事件驱动函数、cron 作业等。目前,平台已内置Docker容器部署,git驱动部署正在路上!

发现无服务器体验并通过立即注册。此外,请随时加入我们的Slack。

如果您想帮助构建无服务器云服务提供商并深入研究这些技术,我们正在招聘!