譯者：陳佳棟、宋淨超、孫海洲、徐鵬、邱世達

Knative 是一個基於 Kubernetes 的，用於構建、部署和管理現代 serverless 應用的平臺。

是一本由 Pivotal 公司贊助 O’Reilly 出品的電子書，公眾號後臺回覆”knative“獲取下載地址。本書中文版由 ServiceMesher 社群自發翻譯。

前言

Kubernetes 贏了。這不是誇大其詞，事實就是如此。越來越多的人開始基於容器部署，而 Kubernetes 已經成為容器編排的事實標準。但是，Kubernetes 自己也承認，它是一個

而不是平臺。它可以作為一個執行和管理容器的很好的平臺，但是這些容器是如何構建、執行、擴充套件和路由很大程度上是由使用者自己決定的。這些是 Knative 想要補充的缺失部分。

也許你已經在生產上使用 Kubernetes，或者你是一個前沿技術愛好者，夢想著將你基於 OS/2 執行的組織現代化。不管怎樣，本報告都沒有假定太多東西，只是要求您知道容器是什麼，具有 Kubernetes 的一些基本知識，可以訪問 Kubernetes 叢集。如果這些您都不具備的話，那麼 Minikube 是一個很好的選擇。

我們將使用大量程式碼示例和預先構建的容器映象，這些映象我們都為讀者開源，您可以從 github.com/gswk 找到所有程式碼示例，並在 hub.docker.com/u/gswk 找到所有容器映象。您還可以在 gswkbook.com 找到這兩個儲存庫以及其他重要參考資料的連結。

目標讀者

我們本質上是開發人員，所以這份報告主要是針對開發人員編寫的。在整個報告中，我們將探索 serverless 架構模式，並向開發人員展示自服務用例示例（例如構建和部署程式碼）。然而，Knative 吸引了不同角色的技術人員。特別是，將 Knative 元件作為更大平臺的一部分或與他們的系統整合的想法會引起運維和平臺構建者們的極大興趣。當這些受眾探索如何使用Knative 來實現其特定目的時，本報告將對他們非常有用。

你將學到什麼

儘管本報告並不旨在詳解 Knative 的全部功能，但已足夠深入，可以帶您入門 Knative，瞭解它的工作原理和使用方式。初步瞭解了 Knative 後，我們將花一些時間研究如何使用它的每個主要元件。然後轉到一些高階用例，最後通過構建一個真實的示例應用來結束，該應用將充分利用您在本報告中學到的所有知識。

Knative 概述

我們有一個信念：以平臺的方式提供軟體是一個最佳選擇。事實證明，標準化的開發和部署流程能讓開發人員更專注於新功能的研發，從而減少時間和金錢上的消耗。不僅如此，確保應用程式之間的一致性也意味著其更容易打補丁，更新和監控，從而讓運維工作也更加高效。Knative 的目標就是成為這樣的現代化平臺。

什麼是 Knative

我們先來看看 Knative 的目標。Knative 的目標是在基於 Kubernetes 之上為整個開發生命週期提供幫助。它的具體實現方式是：首先使你作為開發人員能夠以你想要的語言和以你想要的方式來編寫程式碼，其次幫助你構建和打包應用程式，最後幫助你執行和伸縮應用程式。

為此，Knative 將重點放在三個關鍵元件上：build（構建）你的應用程式，為其提供流量serving（服務），以及確保應用程式能夠輕鬆地生產和消費event（事件）。

通過靈活的外掛化的構建系統將使用者原始碼構建成容器。目前已經支援多個構建系統，比如 Google 的 Kaniko，它無需執行 Docker daemon 就可以在 Kubernetes 叢集上構建容器映象。

基於負載自動伸縮，包括在沒有負載時縮減到零。允許你為多個修訂版本（revision）應用建立流量策略，從而能夠通過 URL 輕鬆路由到目標應用程式。

使得生產和消費事件變得容易。抽象出事件源，並允許操作人員使用自己選擇的訊息傳遞層。

Knative 是以 Kubernetes 的一組自定義資源型別（CRD）的方式來安裝的，因此只需使用幾個 YAML 檔案就可以輕鬆地開始使用 Knative 了。

無伺服器架構（serverless）？

到目前為止，我們已經討論了應用程式的容器化。但都2019年了，我們讀了半章卻還沒有提到“無伺服器架構（serverless）”這個詞。也許作為當今技術中被提到最多的一個詞，無伺服器架構（serverless）仍然在尋找一個整個行業都能認同的定義。許多人都同意這個理念的影響最大的是程式碼量，比如以前需要編寫大型、單一的應用程式，現在你只需編寫通過

來呼叫的小型、單一用途的函式即可。這些事件可以簡單到是一個 HTTP 請求或一個來自訊息通道（如 Apache Kafka）的訊息。同時事件也可能是間接的，比如這些操作：將影像上傳到 Google Cloud Storage或更新了 Amazon 的 DynamoDB 中的一張表。

許多人也都同意這表示著你的程式碼只在處理請求時才用到計算資源。對於很多託管服務來說，如 Amazon 的 Lambda 或 Google Cloud Functions，這意味著你只需要為活躍期間的計算服務付費，而不是一臺7x24小時執行並可能在大部分時間內無所事事的虛擬機器。在本地或非託管的無伺服器架構（serverless）平臺上，則表示程式碼可以只在需要時執行，在不需要時就停止，從而讓你的基礎設施能在其他方面自由使用計算資源。

在這些基礎原理之上的是一場聖戰。有些人堅持無伺服器架構（serverless）只適合在託管的雲環境中執行，在本地執行這樣的平臺完全是不對的。其他人則認為它更像是一種哲學理論上的設計。也許這些定義最後會合並，也許不會。就目前來說，隨著無伺服器架構（serverless）普及率的持續增長，Knative 最有可能成為其標準。

為什麼是 Knative ？

除了關於無伺服器架構（serverless）定義的爭論之外，下一個邏輯問題是“為什麼創造的是 Knative ？”隨著基於容器的架構的流行和 Kubernetes 的普及，我們又開始見到一些相同的問題，這些問題之前也出現在平臺即服務（PaaS）方案上並推動了其發展。如在構建容器時，我們該如何保證其一致性？誰負責給所有東西打補丁？如何根據需求來伸縮？如何實現零停機部署？

雖然 Kubernetes 確實已經演進並開始解決其中一些問題，但是之前提到的關於不斷髮展的無伺服器架構（serverless）的概念方面產生了更多的問題。如何管理多個事件型別的一致性？如何定義事件源和目標？

許多無伺服器架構（serverless）或函式即服務（FaaS）框架都嘗試回答這些問題，但它們都在用不同的方式來解決問題，且不是所有的解決方案都用到了 Kubernetes。而 Knative 構建在 Kubernetes 的基礎上，併為構建和部署無伺服器架構（serverless）和基於事件驅動的應用程式提供了一致的標準模式。Knative 減少了這種新的軟體開發方法所產生的開銷，同時還把路由（routing）和事件（eventing）的複雜性抽象出來。

結論

現在我們已經很好地理解了什麼是 Knative 以及它被創造出來的原因，接下來我們將進一步深入瞭解它。下一章將介紹 Knative 的三個關鍵元件。我們將詳細研究它們，並解釋它們是如何協同工作的，以及如何充分發揮它們的潛力。之後，我們將瞭解如何在 Kubernetes 叢集上安裝 Knative 和一些更高階的用例。最後，我們將通過演示一個 demo 來展示你能在這個報告中學習到的大部分內容。