【译】Kubernetes Serverless 框架的全面对比（OpennFaas，OpenWhisk，Fission，Kubeless 等）

原文连接：A Comparison of Serverless Frameworks for Kubernetes: OpenFaas, OpenWhisk, Fission, Kubeless and more

AWS Lambda 已经成为 Serverless（无服务）的代名词。但与 AWS 分离有两个好处：能避免了一些限制和更加灵活。

Serverless（无服务）实际上是个伪名词，它其实是一套彻底抽象出底层硬件技术的技术。很显然，这些函数或功能实际上仍在在某处的服务器上运行，但咱们不用在意这个。开发者只须要提供一个代码函数，而后再经过某种接口来消费或调用：通常是 REST，但也能够经过基于消息的技术来调用（好比Kafka, Kinesis, Nats, SQS 等）。

下面对 Kubernetes 平台的 Serverless 框架进行了比较，并提供了一些建议：

对比结果

下面的表格是对 k8s 无服务框架的一些比较，主要从受欢迎程度、稳定性、工具、技术和易用性这几个方面进行。

像受欢迎程度这种观点的问题是很难量化的，因此咱们不得不借助一些指标。好比说，我真的很想知道天天又多少人在使用这个框架，可是像找到一个这样确切的数字是很难的，因此咱们借助了 Github stars 或者 Google Trends 这样的指标来表示「受欢迎程度」。有关于受欢迎程度的更多信息能够看这里：Open Source Metrics。

请注意，这里有不少指标只是粗略估计。因此可能看起来某个框架会比实际状况更好或者更差，请结合总体状况来阅读。

维度/框架	OpenFaas	OpenWhisk	Kubeless	Fission	IronFunctions	Fn
(欢迎度)Github Stars
(欢迎度)Google Trends (100 表示最受欢迎)	37	58	24	N/A(和裂变冲突了)	N/A	3
(欢迎度)稳定性(贡献者)
(欢迎度)StackOverflow.com 帖子数	21	359	15	2	5	9
(欢迎度)提交数>10的贡献者	10	33	7	6	9	19
(稳定性)赞助公司	VMWare	IBM(Apache 基金会)	Bitnami	Plaform9	Iron.io	Oracle
(稳定性)首次发布时间	2016/12	2016/02	2016/11	2016/08	2016/02	2016/05
(稳定性)开发语言	Go	Scala	Go	Go	Go	Go
(工具)打包工具	Docker 容器	Docker 容器	Docker 容器	Docke 容器	Docker	Docker
(工具)k8s 部署方式	自定义 yaml Manifest	自定义 yaml Manifest	Manifest	自定义 yaml Manifest	和使用者有关	和使用者有关
(工具)经过 serverless 部署 ?	YES(WIP)	YES	YES	NO	NO	YES
(工具)基础技术	Alertmanager / Prometheus, Nats	CouchDB, Kafka, Nginx, Redis, Zookeeper	None (可选用 Nats 或 Kafka)	fluentd (也能够用 Nats)	Postgres, Redis	DB (sqlite3, PostgreSQL, MySQL), MQ (Bolt, Redis), Prometheus
(易用性)开箱即用	YES	YES	NO(经过 serverless 部署失败了)	YES(但也有点问题)	没有尝试	没有尝试
(易用性)文档质量	Good	Good	通常(条理性略差)	差(条理性差，文档缺失)	通常(条理性略差)	Good
(易用性)有无 Slack channel	有(经过 email)	有	有(slack.k8s.io)	有	有	有

Serverless 框架的建议

根据上表的比较，我建议：

• 使用 serverless framwork 来做为 SDK
• 在 k8s 上使用 OpenFaas 或 OpenWhisk 来管理函数
• OpenFaas 成熟、易于使用和可扩展、但和 OpenWhisk 相比，它在核心项目上的活跃开发者比较少，并且也不太受欢迎。（根据我对活跃开发者和受受欢迎程度的定义）
• OpenWhisk 很成熟，很受欢迎并获得了许多活跃开发者的支持，但也很复杂。它使用 Scala 来编写，并且获得了 IBM/Apache 的支持（多是好事也多是坏事，这个看本身的观点了）

因此最后产生的技术栈可能像这样：

另外还有一点额外的建议，就是 serverless framwork 容许开发者将函数部署到 Lambda 或其余 k8s 的无服务平台上。若是你已经有函数部署在了 Lambda 上，这很是有助于函数的迁移。

各类框架的介绍

Severless Framework

这篇文章下面会屡次提到 Serverless framwork，因此应该先说下它是什么。

它不是一个平台，但它能够运行任何函数。它是无服务的一个 SDK。事实上，它本质上只是作了一层包装。但最爽的是，经过 Serverless framwork 来打包的函数，你能够将相同的代码部署到 Lambda，Google Functions，Azure Functions，OpenWhisk，OpenFaas，Kubeless 或 Fn 中。

这么便利的特性很是吸引人，它制定了一个标准，让开发者遵循标准来构建他们的代码，也容许开发者从标准、成本、功能特性或可用性等方面来分析并决定在哪里部署它们。

此外，它也必定程度上让咱们不用介意「应该使用哪一个框架」。我喜欢 Kubeless 的实现方式，但它还不够成熟。若是咱们是基于 Serverless Framework 的话，那么咱们能够在 OpenFaas 和 Lambda 上构建咱们的函数代码，之后能够轻松地移植到 Kubeless 中。

惟一的缺点是名字起得有点尴尬，很容易形成误解。还有如今支持的语言也有限，但除了这些，我认为这是最安全的选择了。

OpenWhisk

OpenWhisk 是一个成熟的无服务框架，而且获得 Apache 基金会和 IBM 的支持。IBM 云函数服务也是基于 OpenWhisk 构建的。主要提交者都是 IBM 的员工。

OpenWhisk 利用了 CouchDB, Kafka, Nginx, Redis 和 Zookeeper，有不少底层的组件，因此增长了必定的复杂性。好处是开发者能够清晰地关注于可伸缩和弹性的服务，缺点是开发者和使用者都须要具有这些工具的知识和学习如何使用，另外一个缺点是它重复实现了一些 Kubernetes 中已经存在的特性（好比自动扩缩容）。函数最终会和框架一块儿运行在 Docker 容器中。

OpenWhisk 能够用 Helm chart 来安装 ，但有些步骤仍是须要手动。函数应用能够用 CLI 工具或者 serverless framework 来部署。Prometheus Metrics (用于监控函数运行各项指标) 是开箱即用的。

OpenFaas

OpenFaas 是一个受欢迎且易用的无服务框架（虽然在上表中不及 OpenWhisk）。但它不像 OpenWhisk 那么受欢迎，并且代码的提交都是基于我的进行的。除了我的开发者在业余时间的贡献外，VMWare 还聘请了一个团队在全职维护 OpenFaas。如今有一家名为 OpenFaas 的公司在英国注册成立了，但还不清楚这个公司和 OpenFaas 项目的有什么关联。

OpenFaas 的架构相对简单一些。能够经过 Kafka、SNS、CloudEvents、CRON 或其余同步/异步触发器来调用 API 网关，其中异步调用是由 NATS Streaming 来处理的。服务的弹性伸缩是使用 Prometheus 和 Prometheus Alertmanager 来完成的，但也支持替换成 Kubernetes 的 HorizontalPodAutoscaler。

经过 Helm 或 kubectl 能够提供完整的 Kubernetes 安装支持，包括 CRD 的 Operator (好比经过 kubectl 来获取函数)。还有一个 Kubernetes Operator WIP 很好用：openfaas-operator。

函数应用能够经过 CLI 工具或者 serverless framework 部署。还提供了一个 “Funtion Store”，提供了许多在 OpenFaas 上使用的功能。Prometheus Metrics (用于监控函数运行各项指标) 也是开箱即用的。

Kubeless

我对 Kubeless 很是感兴趣，由于它是基于原生 Kubernetes 的。工做原理是在原生 Kubernetes 添加了 “函数” 这种自定义资源的 CRD。除了这个实现很是聪明，也意味着它将 Kubernetes 变成了一个函数运行器，而没有像其余框架那样添加了各类复杂的功能，好比消息机制。

我喜欢像标准 Kubernetes 对象那样来管理函数，意味着 Kubernetes 全部常见的好东西均可以开箱即用（好比 Helm、Ark等）。

交互是经过标准 kubectl 进行的，因此没有额外的工具，而且内置了无服务的支持。

这听起来很完美啊，但。。。

不幸的是它还不够成熟，还不能用户生产。社区也不够大，文档不全（不得不依赖其余文章或帖子）。并且无服务的支持有 bug，这也意味着不能在 Amazon EKS 中使用，

从积极的角度来看，我相信在将来 6 个月内，Kubeless 会成为名副其实的 「Kubernetes serverless framework」。

Fission

Fission 很是有趣，由于它介于 Kubeless 和 OpenWhisk 中间。它很大程度上了依赖了 Kubernetes 的不少特性，但又没有彻底集成。这种方法的好处是它能够利用 Kubernetes 的长处（好比自动弹性伸缩），但在须要作一些其余不一样的事情的时候能够得到更好的性能。例如，它有一个至关复杂的冷启动池机制。

Fission 由 Platform9 支持，能够经过 Helm 来安装。使用了 Influxdb 来处理状态，以及提供了 FluentD 来收集日志，以便开箱即用。消息机制使用的是 Nats，缓存使用的是 Redis。如你所见，其余框架都没有提供开箱即用的缓存和日志功能，虽然手动添加这些功能也很是简单。

Fission 有一个很是好的扩展叫 Fission Workflows。它是一个让开发者用函数式变成来编写函数的工具。这是一个很是有趣的方向，我很想知道能用他来作些什么。

然而，Fission 的用户不多（在 StackOverflow 上只有两个相关问题，但这觉得着它很容易使用么？）。核心的贡献者也很是少，只有 6 个贡献者的提交超过了 10 次。除此以外还有一些其余的缺点，但主要仍是由于缺乏用户和开发人员，文档也比较缺失。这让开发者很难搞懂框架是怎么运行的，我也不知道代码是怎么进行模板化和启动 Pods 的，这可能会对将来产生一些隐患。整体来讲，我对 Fission 的建设感到很是疑惑。。「咱啥也不知道，咱也不敢问」

还有一点，Fission 这个名字也很难搜索获得。

Fn

Fn 这个名字听起来有点尴尬。它是开源的，但主要的贡献者都来自于 Oracle。使用上主要依赖于 Fn CLI，函数运行在 Docker 容器中。这篇博文中有一些关于 CLI 的信息，文档在这里。框架的一些组件能够用 Helm 来部署。还有一个叫 Fn Flow 的新功能，它能够用来编排多函数，相似 OpenWhisk。

但最重要的区别是工做方式，Fn 更注重于易用新，但这显得它很是自觉得是。他提供了函数的热部署（其余框架也能提供这个功能），以及「流函数」（这很独特，可是不清楚这是怎么和其余框架一块儿工做的）。

Fn 项目是从 2016 年开始的，因此它年纪其实和 OpenWhisk 差很少了，也拥有必定量的贡献者。尽管如此，但有些功能和 Kubernetes 是冲突的，我被这些功能拖累了（好比你不能经过 Kubernetes 来部署 AFAICT）。但这是个人诉求，因此我没有使用下去了。可是它是和 serverless framework 兼容的，必定程度上获得了一些缓解吧。。

IronFunctions

Iron Functions 获得了一家同名公司的支持。因此这里有些坑，在 github 上的 readme 上你点击「documentation」实际上跳转到了 Iron 公司的首页。而后你在页面中再点击「docs」，获得的内容又不是关于 Iron Functions 的。实际上真正的文档在仓库的 docs 目录下。。。

和其余框架同样，它也是基于 Docker 的。有一个有趣的特色是，它对于 AWS Lambda 有一些特殊的支持。你能够从 Lambda 中获取代码而后直接在 Iron Functions 上运行。这对迁移很是友好。

不幸的是，它并不能像 Fn 那样原生地支持经过 manifest 部署到 Kubernetes，并且也不支持 Serverless framework。由于这种种缺点，因此我没有继续去尝试使用它了。它也不够受欢迎，没有出如今 Google Trends 上。

Funktion

Funktion 是 RedHat 的一个已经失效了的解决方案。

---

关注【IVWEB社区】公众号获取每周最新文章，通往人生之巅！