这将对在Kubernetes上运行的所有无服务器框架进行比较。

术语“无服务器”已经成为AWS Lambda的同义词。与AWS解耦有两个好处;它避免了锁定，提高了灵活性。

所谓的无服务器，是一组技术和完全抽象底层硬件的技术。显然，这些函数仍然运行在某个“服务器”上，但重点是我们并不关心。开发人员只需要将代码作为函数提供。然后通过API使用或使用函数，通常是REST，但也通过消息总线技术(Kafka, Kinesis, Nats, SQS等)。

这为Kubernetes平台提供了一个无服务器框架的比较和建议。

编辑:

• v1 02/09/18
• v2 02/09/18: OpenFaas信息的主要编辑感谢@alexellisuk, Richard Gee， @kenfdev。由于@sebgoa，从比较表中删除了Serverless。
• v3 10/09/18:编辑关于Fn项目，感谢@delabassee。

比较表

下面的表格提供了k8s的不同无服务器框架的高级比较。它们被分为流行度、稳定性、工具、技术和可用性。

像受欢迎程度这样的观点的问题在于它很难量化。我们不得不求助于代理人。例如，我很感兴趣的是每天有多少人在使用这个框架。但是很难找到这些数字，所以我们使用Github星数或谷歌搜索等代理度量。它们表示为。有关项目受欢迎程度的更多信息，请参阅此处。

因此，请注意，这些指标中的许多都是粗略估计。单个框架的表现可能比实际情况好，也可能比实际情况差。阅读时要对所有的证据和特征有一个整体的看法。

• 来自VMWare的开发团队全职工作在OpenFaas上。
• 包括无服务器，因为建议使用SDK。
• 用于IBM的云功能产品中

Serverless框架建议

用这个表做比较，我可以推荐:

• 使用无服务器框架作为软件开发工具包(SDK)
• 使用OpenFaas或OpenWhisk作为k8s上函数的编排器。
• OpenFaas是成熟的、易于使用和可扩展的，但是与OpenWhisk相比，核心项目上的活动开发人员更少(根据我对活动开发人员的定义)，也更不受欢迎(根据我对流行度指标的选择)。
• OpenWhisk是成熟的，有许多活跃的开发人员支持，很流行，但是很复杂，用Scala编写，由IBM/Apache支持(可能是好事也可能是坏事，取决于你的看法)

最终的技术堆栈看起来如下:

无服务器框架的附加建议允许开发人员选择是要部署到lambda还是部署到k8s上的无服务器平台。如果lambda上已经有函数，这有助于迁移。

框架的笔记

OpenWhisk

OpenWhisk是一个成熟的无服务器框架，由Apache基金会和IBM支持。OpenWhisk构成了IBM云功能服务的基础。主要的提交者是IBM员工。

有许多底层组件，这增加了复杂性。它利用了CouchDB, Kafka, Nginx, Redis和Zookeeper。好的一面是开发人员明确地关注于可伸缩性和弹性。缺点是开发人员和操作人员需要这些工具的工作知识。另一个缺点是，它们复制了Kubernetes等编曲中存在的特性(例如自动缩放)。函数最终被绑定到与框架一起运行的Docker容器中。

OpenWhisk可以使用Helm图表安装，但不幸的是需要一些手动干预。可以使用CLI或无服务器框架部署应用程序。普罗米修斯度量标准被导出。

OpenFaas

OpenFaas是一个流行的(根据我对流行程度的估计，不像OpenWhisk那么流行)，易于使用的无服务器框架。它不像OpenWhisk那么流行，并且提交是基于个人的。VMWare雇佣了一个团队来全职从事OpenFaas的工作，此外还有个人贡献者在业余时间完成的伟大工作。一家名为OpenFaas Ltd.的公司已经在英国注册成立，尽管尚不清楚该公司与该项目有何关联。

OpenFaas的架构相对简单。API网关可以通过Kafka、SNS、CloudEvents、CRON和其他触发器同步或异步调用。异步调用由NATS流处理。自动caling是执行使用普罗米修斯和普罗米修斯Alertmanager;但谢天谢地，这似乎可以用Kubernetes的HorizontalPodAutoscaler替换出来。

完全支持的Kubernetes安装程序可通过Helm或kubectl，包括一个操作员允许使用的CRDs，即kubectl得到功能。也有一个Kubernetes操作员是WIP，但我发现这工作得很好。

可以使用CLI或无服务器框架(WIP)部署应用程序。还提供了一个“函数库”，一个用于OpenFaas的函数列表。普罗米修斯度量被导出出盒子。

OpenFaaS®是英国的注册商标

Kubeless

我对Kubeless非常感兴趣，它是Kubernetes的函数本机框架。它通过在Kubernetes中添加作为自定义资源定义(CRD)的“函数”的思想来工作。加上一些巧妙的代码，这意味着它将Kubernetes变成了一个函数机，而不像其他框架那样添加消息总线这样的复杂性。

我喜欢管理像标准Kubernetes对象这样的功能，这意味着所有常见的Kubernetes产品都可以开箱即用(Helm, Ark等)。

交互是通过标准的kubectl进行的，所以没有额外的工具，并且内置了无服务器支持。

听起来完美!

但不幸的是，它还不够成熟，不能用于生产中。社区不够大，文档不够完善(必须依赖于博客文章)，无服务器支持存在bug，这意味着它不能在ek上工作。

考虑到这些积极的基础，我确信在未来6个月内这将成为事实上的Kubernetes无服务器框架。

Fission

裂变很有趣，因为它位于Kubeless和OpenWhisk之间。它严重依赖于Kubernetes的特性，但并没有完全集成。这种方法的好处是，它可以利用Kubernetes擅长的东西，比如自动伸缩，但在需要时做了一些不同的事情来获得更好的性能。例如，它有一个相当复杂的冷启动池机制。

它由Platform9支持，可以通过Helm安装。它使用fluxdb来处理状态，并提供FluentD用于登出。它使用Nats作为消息总线，Redis用于缓存。如您所见，其他框架不提供缓存和登出功能，尽管添加它相当简单。

裂变有一个很好的额外的叫做裂变工作流。这是一个允许开发人员组合函数的工具。函数式编程。这是一个非常有趣的方向，我很想知道可以用它来做些什么。

然而，很少有用户(只有两个堆栈溢出问题——这意味着它很容易使用吗?)和很少有真正的贡献者——只有6个人提交超过10个。有一些烦恼，但这主要是由于缺乏用户和开发人员。而且文档组织得很糟糕。这使得我们很难弄清楚框架是如何工作的。我也不喜欢代码如何负责模板和启动豆荚本身;这很可能在将来造成破损。最后，我对裂变建造者非常困惑。我不知道它们是什么，为什么需要它们。

而且，这个名字也很难搜索。

Fn

另一个争夺这个愚蠢名字桂冠的竞争者是Fn。它是开源的，但主要贡献者是为Oracle工作的。主要工作流程使用Fn CLI，但在底层函数使用Docker容器。在这篇博文中有一些信息，文档在这里。并且可以使用Helm部署框架组件。还有一个新添加的称为Fn Flow的功能，它编排了多个类似于OpenWhisk工作流的函数。

但最重要的区别是你工作的方式。Fn专注于易于使用，但这使得它非常武断。它提供热函数(所有其他框架也可以提供)和流函数(这更独特——不完全清楚如何与其他框架一起工作)。

它成立于2016年，这使得它和OpenWhisk一样古老，并且有相当数量的贡献者。尽管如此，我还是被大量强加给开发者的意见所困扰，这些意见并不适合Kubernetes(你不能用Kubernetes来部署afict)。这是我的要求，所以我没有尝试。然而，它与无服务器框架是兼容的，可以稍微减轻这一点。

IronFunctions

Iron Functions是由一家同名公司支持的。这增加了一些初始的复杂性，因为github readme将你重定向到“文档”，这实际上是Iron公司的主页面。如果你点击“docs”，就不会看到Iron Functions。真正的文档在存储库的docs目录中。

它是基于Docker的，像许多其他框架一样，一个有趣的特性是它对AWS Lambda函数提供了类似的支持。你可以从Lambda中获取代码，然后直接在Iron上运行;这对迁移来说很好。

不幸的是，它似乎不支持将清单部署到Kubernetes，就像Fn一样，而且它也不受无服务器框架的支持。这使我不敢去尝试。谷歌的流行趋势中也没有出现。

Severless Framework

我在文章中已经多次提到了这一点，因此它本身就值得一节。

它不是一个平台，它运行任何函数。它是一个无服务器的软件开发工具包。事实上，它本质上只是一种包装机制。但美妙之处在于，一旦以无服务器方式打包，您就可以将相同的代码部署到Lambda、谷歌Functions、Azure Functions、OpenWhisk、OpenFaas、Kubeless或Fn。

这种可移植性非常有吸引力。它允许开发人员以标准的方式构建他们的代码，但仍然允许标准、定价、特性设置或可用性来决定在哪里部署。

此外，它允许我们稍微推迟框架的选择。我之前提到过，我喜欢Kubeless关于Kubernetes的方向，但它还不够成熟。如果我们使用Serverless，那么我们现在就可以在OpenFaas或Lambda上构建代码，然后很容易地移植到Kubeless上。

唯一的缺点就是名字都很蠢。每一个。单身。时间。我必须加上“没有服务器的框架，而不是技术”。再加上受支持语言的数量有限。但除此之外，我认为这是最安全的选择。

Funktion

Funktion是红帽公司已经失效的解决方案。

本文：http://jiagoushi.pro/node/1487

讨论：请加入知识星球【首席架构师智库】或者微信【jiagoushi_pro】或者QQ【2898908662】