Kubernetes 上领先的开源 Serverless 解决方案有哪些

在去年年底的一次YC Startup School采访中，YC 软件工程师Kyle Corbitt，询问了亚马逊的首席技术官Werner Vogels，关于容器和Kubernetes的问题。Werner 在台上待了 44 多分钟，显得很困惑，他详述了 AWS 的最低限度可行的容器产品, 然后突然转了一个弯，说道：“容器的一个问题是，它几乎让你又回到了云出现之前的那个时代。”他说，“虽然容器对开发人员来说是一个很好的抽象，但客户仍需要做很多工作。没有人关心在底层运行的容器，因为它似乎只是你需要额外支付的税款。“

所有开源无服务器 Kubernetes 的路径均指向 Knative

当然，Werner 这里是在谈论他自己的书。AWS 已经半心半意地将 Kubernetes 作为其承诺的服务，这不仅因为 Kubernetes 是“谷歌为每个人提供的基础设施，“而且因为 AWS 认为 Kubernetes 会分散人们对下一个更具影响力、更具粘性且更容易计费的阶段即“serverless”的注意力。”因此，当 AWS 继续在 Lambda 上沿用微软的战略——拥抱、扩展再消灭时，谷歌正在通过即将推出的“Knative”将其在 Kubernetes 上的筹码加倍。

Kubernetes 上的 serverless 化，从何开始

是谁最先开始了在 Kubernetes 上的 serverless 化？那些在他们自己的数据中心操作的人都曾遇到过CNCF的“云原生”图景。除了“小道地图”能指导对容器好奇的人，还有一个徽标PDF （和相应的单页SPDY /笔记本电池基准测试工具），能够引导爱好者行走在CNCF的“云原生图景的推荐路径”之上。CNCF 现在甚至展示“Serverless 图景”。如果你按下下拉式按钮并进入开源的”可安装“平台，你将会遇到一些“Kubernetes 上的 serverless 化”的有力竞争者。

让我们根据开始的时间排序，依次浏览每个开源 serverless 产品。

Apache OpenWhisk，一种多功能、具有行业优势的 Serverless 解决方案

上图的第一个开源无服务器平台看起来很像一个正在孵化的 ASF 项目，例如IBM Blue。

OpenWhisk 是第一个由大型供应商开源发布的合法 Serverless/基于事件的架构。它来自纽约州约克镇的 IBM 研究团队，用 Scala 编写，它看起来非常非常严格。它甚至还有一个项目维基百科，托管在 Confluence 上。我很难准确地说出 OpenWhisk 在商业环境中的受欢迎程度，但似乎 IBM 很乐意向人们推销基于 OpenWhisk 的“云功能”。OpenWhisk 甚至被捐赠给了 Apache 基金会。虽然它可以在 Kubernetes 上使用，但是某位原创作者称它是为“大规模部署扩展而不仅仅是检查”而创建的。这非常有趣，尤其如果你是一家 Java 公司，使用容器或 kubernetes API（命名空间）作为多租户边界对于您的首席信息安全官来说是场噩梦。

Fission，第一个真正的 Kubernetes Serverless 平台

接下来，开源 Serverless 竞赛的领跑者是一个完全基于 Kubernetes 的项目，这个项目来自 Platform9，名为“Fission”。

Fission似乎主要是由少数几位工程师创造的。这些人与 Platform9 的联合创始人一起，试图在 VMWare 上摒弃虚拟化技术。在这些选项中，Fission借助一些强大的流行玩意儿，实现了一个非常轻松的 quickstart 安装过程。Fission通过预热动态加载器、实时重新加载、记录/重放、金丝雀部署和 prometheus 指标集成，实现了低于 100 毫秒的“冷启动”。如果您欣赏前 VMWare 杰出员工运营一家 OpenStack + K8s 初创公司的行为，那么您可以使整个集群专门运行Fission工作负载，这件好事不应该被错过。

Kubeless，在 Serverless 中使用 Kubernetes API 的早期先驱

在 Fission 之后很快出现了“Kubeless”，它在 Kubernetes Custom Resource Definitions 的路径上被看做是一个早期的幻想家。（什么是 CRD 或 CRD +自定义控制器？我认为是 K8s 扩展机制，它利用基础 Kubernetes 集群结构实现更高级别的功能。或者是，除了 Envoy 之外，为 Istio 提供动力的东西。）

Kubeless 令人困惑的一点是，虽然它仍然在被维护并且最终用户表示出了兴趣，其创作者无一例外都转战到了其他项目。原来的领导现在成了“区块链工程师“，另一个关键领导者已经成立了一家“serverless 化”的新公司TriggerMesh（它本身是GitLab中的 serverless 集成的众多驱动力之一）。所以，很难说 Kubeless 的发展方向是什么，但如果你正忙着编写自己的控制器并在 CRD 中徜徉，Kubeless 可能是一个有用的东西。12000 行的 golang“意味着 K8s API 的概念证明”，多好啊？

OpenFaaS，Kubernetes 上的简单 serverless

OpenFaaS 非常吸引人。它是唯一拥有除 Apache 2.0 以外的许可证的竞争者，它尤其以社区为中心，在最初对标 Docker Swarm 之后，它于 2017 年中期添加了 Kubernetes 支持，并且非常精简。

OpenFaaS 是一个专职的单身工程师的心血结晶，该工程师此前已牢固地打造了一个周边社区。OpenFaaS 以其简单、紧密的代码库和完美的消息传递而著称，如“更简单的 serverless 功能”，“一键安装”，“随着需求的增加而自动扩展包括扩展到零”。很不错吧？它的维护者在 2017 年 7 月还添加了一个Kubernetes介绍到文档中，如果你还不是 K8s 企业，以下陈述可能会给你留下一个很好的印象：“只有 serverless 的解决方案，才可以与 Kubernetes 和 Docker Swarm 原生集成”，“由价值驱动”，“以社区为中心”，“与 40 年前相比，现有 160 多名贡献者。”最近该项目的 faas-netes 运算符甚至几乎完全由来自 Weaveworks 的 Stefan Prodan 重建，从而与 Kubernetes 实现更紧密的集成。

一个小小的问题是 - 不要因为 OpenFaaS 的“Docker Captain”血统，便错误地将它排除在外（就像你的作者做的那样！）。如果你在 Google Docs 调查中打勾，支持OpenFaaS Slack生态系统，他甚至会自动邀请您参加社区贡献者会议。这很吸引人。

Knative，又被戏称为：所有你的 OSS serverless（和 Ingress）均属于我们

最后是 Knative。如果你按相反的时间顺序阅读本文，你会在这里停下来。Knative 是 lambda 的有力竞争者。如果在此期间你没有密切关注 2018 年中期的Google Cloud NEXT会议，你很容易错过 Knative。与时俱进吧！Knative即将到来，而且带着Istio。

坊间消息是，谷歌有超过 90 名工程师正着力构建 Knative，Knative 是 GCP 和 GKE 之间即将到来的深度“云功能”集成的基础。如果你很勇敢，你甚至可以要求参加 beta 测试计划，而这能让你获取 knative 就像点击 Google Cloud 控制台中的按钮一样简单。

下面是与项目密切接触的人的话。Oren Teich, “所有这些都重新融入了Knative”。还有一位 Google 老员工在Knative公告HN帖子中说道：“当然，这些都只是早期的，但考虑到我们的目标是将共性（我们所做的 80％都大致相同）编写出来并且改善客户工作负载的可移植性，我希望看到使用Knative构建的新产品，或者现有产品以Knative为基础。“在同一个帖子中，Pivotal 的一位高级软件工程师指出，“我认为 FaaS 是一种具有一些额外功能的 PaaS（扩展到零无疑是它最引人注目的功能）。”

其他开源 serverless 平台

仔细观察 #serverless 空间，你还会注意到还有很多其他产品，比如 -来自Oracle的Fn, Pivotal 的 Riff, VMWare的 Dispatch, Galatic Fog, Nuclio, Virtual Kubelet （严肃地说，这也是 serverless？），PipelineAI, Nuclio，可能还有更多。对不起，乍一眼看的话，它们中的大多数都很快就会不敌 Knative。

托管的无服务器怎么样？Google Cloud Functions, Huawei FunctionStage, Cloudflare Workers, Azure Functions, Serverless(.com)。当然，在创造真正的商业价值的同时，购买它们吧。但我还是回到我的 YAML 吧。

查看英文原文：The Leading Open Source Serverless Solutions for Kubernetes