【譯】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社區】公衆號獲取每週最新文章，通往人生之巔！