【无服务器架构】Kubernetes的无服务器框架比较:OpenFaas, OpenWhisk,Fission,Kubeless和更多

这将对在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星数或谷歌搜索等代理度量。它们表示为。有关项目受欢迎程度的更多信息,请参阅此处。

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

比较/框架 OpenFaas OpenWhisk Kubeless Fission IronFunctions Fn
流行度(Github Stars) 20k 5.3k 6.5k 6.1k 2.9k 4.9

流行

(相关谷

歌趋势 100 means most popular)

37 58 24 N/A (conflicts with fission)

N/A

(conflicts

with serverless)

3

流行度

(总StackOverflow posts)

21 359 15 2 5 9
稳定度(Contributors) 157 188 101 144 32 84
稳定度(Contributors > 10 Commits) 10 33 7 6 9 19
稳定度 (Corporate Backer) VMWare (1) IBM (Apache Foundation) (3) Bitnami Platform9 https://iron.io Oracle

稳定度

(Started)

Dec 2016 Feb 2016 Nov 2016 Aug 2016 Feb 2016 May 2016

稳定度(

开发语言)

Go Scala Go Go Go Go

工具(打包

机制)

Docker container Docker container

Docker

container

Docker

container

Docker Docker

工具 (

k8s部

署功能)

Manifest with custom yaml Manifest with custom yaml Manifest

Manifest

with custom

yaml

Proprietary Proprietary

工具(

无服务

器部署)

Yes (WIP) Yes Yes No No Yes

技术(

底层

技术)

Alertmanager / Prometheus, Nats CouchDB, Kafka, Nginx, Redis, Zookeeper

None (optional

Nats or Kafka)

fluentd

(optional

Nats)

Postgres, Redis DB (sqlite3, PostgreSQL, MySQL), MQ (Bolt, Redis), Prometheus

可用性 (Worked

out of the box?)

Yes Yes

No (serverless

plugin failed)

Yes (but 

annoyances)

Didn’t try Didn’t try

可用性

(文档质量)

Good Good

Average 

(没有

很好的

组织)

Poor

 (组织不佳,

导航奇怪,文件缺失)

Average

 (组织不佳)

Good

可用性

(Slack channel?)

Yes but through email Yes

Yes (#kubeless

channel of the k8s slack: 

http://slack.k8s.io)

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

Serverless框架建议

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

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

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

Recommended open source serverless stack

无服务器框架的附加建议允许开发人员选择是要部署到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是红帽公司已经失效的解决方案。

原文:https://winderresearch.com/a-comparison-of-serverless-frameworks-for-kubernetes-openfaas-openwhisk-fission-kubeless-and-more/

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

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