Kubernetes近來受到高度關註，且已經成為容器領域的主要抽象方案。考慮到Kubernetes強大的容器排程能力，及其為基礎設施自動化帶來的堅實基礎，這一切自然是在情理之中。
不過我們註意到，開發團隊在使用普通Kubernetes進行應用程式部署時，往往會遇到困難。推送容器本身雖然無甚挑戰，但如果大家希望利用其推送應用程式程式碼——或者函式，那麼單憑Kubernetes自身就不太夠用了。
正因為如此，才會有大量供應商圍繞Kubernetes推出層級更高的抽象技術，Knative[1]應運而生。
大家可能已經註意到，在最近的分散式系統世界當中，函式即服務（‘函式’或者‘無伺服器’）已經成為一種新的抽象趨勢。其允許開發人員更輕鬆地執行並部署程式碼片段，且這些程式碼片段將能夠快速實現規模伸縮以響應事件需求。
這對開發人員而言，無疑是個極具吸引力的主張。為什麼？因為將一切基礎設施與事件處理流程抽象出來（直到其觸發函式為止）意味著開發人員能夠完全專註於自己的功能性程式碼——是的，再沒有任何其它事務會分散他們的精力。
當然，世界上沒有免費的午餐。那麼，函式的複雜性又體現在哪裡？
目前市面上存在著大量函式即服務選項。而對每款產品而言，其在觸發函式的具體方法、可以處理的事件格式、擴充套件能力以及幫助開發人員抽象出的實際複雜度數量方面皆有所區別。
對於具備實用性的抽象，公有雲供應商往往會將其打包為一項服務。其中包括Azure Functions（微軟）、Lambda（AWS）以及Google Cloud Functions等等。每種服務都執行函式程式碼以唾液事件，並根據當前需求進行擴充套件。此類產品採用務實的計費方式——使用者需要按照函式的具體呼叫次數付費。
開源開發人員也投身於無伺服器陣營，並開發出OpenFaaS、Fission、Kubeless以及Project riff等專案。這一切都是函式即服務的典型例子，且建立在Kubernetes基礎之上。但各專案之間的共通之處也就僅此而已。
各個專案在以下三大核心領域都有著略有區別的實現方式：
-
各專案都擁有一種構建服務，或者利用函式程式碼構建並部署容器的方法。
-
各專案都擁有一種實現擴充套件伸縮以響應對函式呼叫需求的方法。
-
各專案都提供一種基於事件的函式呼叫方法，例如包含事件代理的http或釋出/訂閱機制。
這些微妙的差異實際上成了採用過程中的巨大障礙。企業開發者們意識到這種碎片化問題的存在，因此他們決定暫不採取行動，而是靜待市場上出現真正的執行標準。
谷歌公司當然也發現了這個問題，並意識到需要提供通用型工具以幫助開發人員在Kubernetes上構建函式。而其解決方案，正是Knative（發音為kay-nay-tiv）。
Knative是一個開源軟體層，旨在幫助雲服務供應商及企業平臺運營商為任何雲環境中的開發人員提供無伺服器體驗。
在Pivotal公司，我們已經將自己的事件模型由Project riff移交給了Knative。此外，我們還與谷歌一道在Knative專案的多個領域開展合作，包括為其提供開發人員與程式碼支援。我們對這個專案的前景感到非常興奮，且正在嘗試將Project riff與Knative結合起來，從而為我們即將推出的Pivotal函式服務[2]建立基礎。
那麼，關於Knative大家有必要瞭解哪些資訊？首先，該專案利用Kubernetes作為容器編排層，且在我們所熟知的Kubernetes原語（Pod、副本集、部署等）之上構建函式。那麼Istio呢？沒錯，Knative利用Istio實現叢集內的網路路由以及用於進入叢集的入口連線。
不過，Kubernetes與Istio還遠遠不夠。因此，Knative還添加了其它三種鬆散耦合的元件以提供完整的無伺服器平臺：Build、Eventing以及Serving。
-
Build提供一套可插入模型，用於利用原始碼構建容器。
-
Eventing允許各應用/函式釋出及訂閱事件流，例如Google Cloud Pub/Sub以及Apache Kafka。
-
Serving提供相關能力，用以輕鬆執行應用程式/函式並對其進行規模伸縮。
如此一來，Knative就獲得了輕鬆易行的函式部署與執行方法，具體包括以下樣式：
下麵，我們將更具體地聊聊Build、Eventing與Serving。
Build：利用靈活及可擴充套件的原始碼實現容器自動化
開發人員負責編寫原始碼。Kubernetes負責處理容器。那麼，我們該如何調和這種不匹配問題？很簡單，利用開發人員編寫的原始碼構建容器。（聽起來很熟悉吧？Cloud Foundry就在使用buildpack實現這一效果。）Knative提供一套專門用於立足原始碼構建容器的可插拔模型。該模型透過定製化資源進行定義，屬於一套Kubernetes API物件集合。這種方法能夠提供基礎構建塊，確保將原始碼作為CI/CD管道等更大規模系統中的組成部分。
-
描述在何處查詢構建所使用的原始碼。該位置會被儲存在/workspace分捲當中，併在後續步驟內被加以使用。原始碼的的具體儲存位置為各類原始碼控制系統（例如GIT、GCS或者其它可訪問的原始碼自定義容器）。
-
步驟或模板。 即構建容器的實際工作。該流程體現為一系列遵循構建器規範的步驟。您亦可將其視為一套構建模板，由可插拔構建器組成，專門用於利用原始碼構建容器。目前，該模型支援五種可共享構建過程的構建模板，分別為之前提到的Cloud Foundry Buildpacks、Google Container Builder、Bazel、Kaniko以及Jib。
-
服務賬戶。此賬戶用於執行構建結果。
-
分捲。提供在構建過程當中可供使用的各分捲的定義能力。這些分捲可以具有多種用途，例如共享秘密憑證或為多個步驟提供快取功能。
Serving：可實現高階操作的按需擴充套件與版本控制
自動化能力將有效改善開發人員的工作流程。Serving能夠以自動化方式實現從容器到函式執行的整個流程。此外，其還能夠快速部署容器並執行規模伸縮，甚至可根據傳入請求將規模降低至零。Istio在不同修訂版本（函式版本）之間進行流量路由，從而實時零停機更新、藍/綠部署、部分負載測試以及程式碼回滾等效果。
-
管理應用程式/函式生命週期的資源，並提供單點控制。其負責處理物件的建立，旨在確保應用程式/函式具備網路路由、配置以及服務更新等版本控制能力。
-
為程式碼及其配置提供一套不可變快照。各修訂版本將取用容器映象以及由此建立的build。各修訂版本之間可共存於同一歷史記錄之內，從而實現藍/綠部署或者回滾等高階操作。
-
能夠將網路端點對映至一個或多個函式修訂版本。
-
定義所需的最新部署狀態，併在狀態更新時定義修訂版本的狀態。
Eventing：對釋出/訂閱細節進行抽象處理，幫助開發人員擺脫相關負擔
函式的存在是為了響應事件。FaaS專案與託管服務之間的實現差異，集中體現在獲取並使用這些事件的具體方式身上。Knative Eventing元件旨在對這些事件進行抽象處理，從而幫助開發人員擺脫與後端相關的具體細節。如此一來，開發人員將不必費心於挑選訊息傳遞平臺以及資料複製方法等工作。
Knative為開發人員提供Kubernetes定製化資源，這些資源可用於事件的生產與消費。此類定製化資源主要分為以下兩大類別：
-
即釋出者在傳送訊息時面向的釋出/訂閱標的（主題）。從本質上講，頻道可被視為獲取或放置事件的位置目錄。
-
匯流排。各頻道的後端供應方。其屬於支援事件的訊息收發平臺，具體選項包括Google Cloud PubSub、Apache Kafka以及RabbitMQ等等。
-
為應用程式/函式指定Knative服務，併為其指明立足頻道所傳遞的具體訊息。其屬於應用程式/函式的入口地址。
Knative是一套全新的解決方案，但目前已經存在大量關於具體使用方式及使用理由的指導性資源。總結而言，企業正編寫越來越多的軟體方案，這意味著典型的現代企業必然擁有自己的應用程式平臺、容器編排工具與函式。Pivotal希望立足這些不同抽象物件推動開源創新。在這項工作當中，Cloud Foundry、Kubernetes以及現在的Knative都將扮演重要的角色，幫助各大公司對自身構建及執行軟體的具體方式進行現代化改造。
-
http://github.com/knative
-
https://pivotal.io/platform/pivotal-function-service
原文連結：https://thenewstack.io/knative-enables-portable-serverless-platforms-on-kubernetes-for-any-cloud/
Kubernetes專案實戰訓練將於2018年8月17日在深圳開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：Docker介紹、Docker映象、網路、儲存、容器安全；Kubernetes架構、設計理念、常用物件、網路、儲存、網路隔離、服務發現與負載均衡；Kubernetes核心元件、Pod、外掛、微服務、雲原生、Kubernetes Operator、叢集災備、Helm等，點選下方圖片檢視詳情。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
