Kubernetes上领先的开源 Serverless 解决方案汇总

图0: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 参数 详情
开始时间 2016 年 2 月(首次公开提交)
速度 2,300 多个提交,240 多个观察者,3,700 多个星,700 多个分叉,1,200 个松散成员(kubernetes 中只有 160 多个成员)
许可 Apache 许可证 2.0
状态 生产使用良好(是 IBM Cloud Functions 的基础,与 Adobe 产品一同使用)
代码行(LOC) 〜64000 行(仅限平台),用 Scala 编写
主要作者 Rodric Rabbah,MarkusThömmes,James Dubee,Carlos Santana,Christian Bickel,Perry Cheng。Chetan Mehrotra,Tyson Norris,其中几位来自 IBM 和 Adobe。(Perry 和 Rodric 由此开创了纯无服务器云——nimbella.com)
安装过程 多个部署目标包括 k8s
主要特点 “生产就绪”,工业设计
安全 / 多租户 严格,一直到容器(linux cgroup 和命名空间)

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

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

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

Fission 参数 详情
开始时间 2016 年 8 月
速度 3,900 多个星,340 多个分叉,140 多个观察者,340 多个分叉,800 多个松散成员
许可 Apache 许可证 2.0
状态 版本 1.0
代码行(LOC) ~25000行,golang
主要作者 Soam Vasani(VMWare/Platform 9,SF),现在是 Ta-Ching Chen(VMView,台湾)。还有 Vishal Biyani(来自印度 Pune InfraCloud)
安装过程 基于 helm 的 w/clean quickstart
主要特点 易用性,商业支持?
安全 / 多租户 命名空间级别的软多租户,比 K8s 本身稍微宽松一些?

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 参数 详情
开始时间 2016 年 11 月
速度 960 多个提交,170 多名观察者,4,000 多个星,400 多个分叉,350 多个松散成员(#kubeless on K8s Slack)
许可 Apache 2.0
状态 运行时 (runtime) 是“稳定的”,但是…维护模式?有人会用这个吗?
代码行(LOC) 12000, golang
主要作者 Tuna Ng(已离职,现为 TomoChain 区块链首席工程师),Andres Martinez Gotor(Bitnami),Sebastien Goasguen(前 Bitnami 人,现就职于 TriggerMesh)
安装过程 YAML 和 curls
主要特点 CLI 兼容 AWS Lambda CLI,基于核心 K8s 构造
安全 / 多租户 基于 CRD,因此内部身份验证依赖于 K8s API / 命名空间 / RBAC。外部身份验证基于 HTTP 头。

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

OpenFaaS,Kubernetes 上的简单 serverless

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

OpenFaaS 参数 详情
开始时间 2016 年 12 月
速度 3,850 个提交,450 + 观察者,15000 + 个星,1600 + 分叉,1,200 + 松散成员
许可 MIT
状态 最终用户页面有很多标志,包括一些著名的大牌
代码行(LOC) 〜5000,golang,还有更多的分散在其它库中
主要作者 Alex Ellis(在英国 ADP 工作了 10 年以上,现就职于 VMWare),现在已经有 180 多个社区贡献者
安装过程 YAML+ helm 模板
主要特点 简单! AWS-SNS 触发系统,包含 Istio 集成,CRD 支持,REST API,ARM 支持(32 位和 64 位),“功能 + 模板商店“ 和 “OpenFaaS 云
安全 / 多租户 所有容器都是非 root 用户,包括只读文件系统的选项。还有专用命名空间、可管理的 K8s RBAC 角色和“默认身份验证”(在 OpenFaaS 云上使用 GitHub 或 GitLab+ OAuth 2.0 授权)

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

Knative 参数 详情
开始时间 2018 年 1 月
速度 2400+ 提交,183 + 观察者,2100 + 星,490 + 分叉,1,200+ 松散成员(特别地,并非 #knative on K8s Slack – 它们是不同的生态系统)
许可 Apache 2.0
状态 v0.4.0 (阿尔法, 贝塔?)
代码行(LOC) 服务:~87000,事件~25000
主要作者 大量的 Google 员工,以及“来自~48 家不同公司的约 300 名贡献者”。
安装过程 一套“酵母”式的 Isitio CRD,然后便是干净的 yamls
主要特点 Istio,终于有一个用例了!耶!自动伸缩,透明构建,用户空间遥测,修订,流量分割等。
安全 / 多租户 继承 Istio?期望他们能做到这一点
需注意点 谷歌请求 T-Mobile 在 Knative 预发布 (pre-launch) 上构建商店定位器原型。参见:https://youtu.be/qzPG4O-DhYw?t=617

坊间消息是,谷歌有超过 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 吧。

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注