终于有人把Knative讲明白了
導(dǎo)讀：Knative是Google在2018的Google Cloud Next大會(huì)上發(fā)布的一款基于Kubernetes的Serverless框架。
作者：劉宇
來(lái)源：大數(shù)據(jù)DT（ID：hzdashuju）
其基本信息如表2-2所示。
▼表2-2 Knative基本信息
Knative一個(gè)很重要的目標(biāo)就是制定云原生、跨平臺(tái)的Serverless編排標(biāo)準(zhǔn)。Knative是通過(guò)整合容器構(gòu)建（或者函數(shù)）、工作負(fù)載管理（和動(dòng)態(tài)擴(kuò)縮）以及事件模型來(lái)實(shí)現(xiàn)Serverless標(biāo)準(zhǔn)的。Knative社區(qū)的主要貢獻(xiàn)者有Google、Pivotal、IBM、Red Hat。CloudFoundry、OpenShift這些PaaS提供商都在積極地參與Knative的建設(shè)。
01 工作原理
如圖2-14所示，Knative是建立在Kubernetes和Istio平臺(tái)之上的，使用了Kubernetes提供的容器管理組件（deployment、replicaset和pod等），以及Istio提供的網(wǎng)絡(luò)管理組件（ingress、LB、dynamic route等）。
Knative中有兩個(gè)重要的組件，分別是為其提供流量的Serving（服務(wù)）組件以及確保應(yīng)用程序能夠輕松地生產(chǎn)和消費(fèi)事件的Event（事件）組件。
其中，Serving組件基于負(fù)載自動(dòng)伸縮，包括在沒(méi)有負(fù)載時(shí)縮減到零，允許使用者為多個(gè)修訂版本應(yīng)用創(chuàng)建流量策略，從而通過(guò)URL輕松路由到目標(biāo)應(yīng)用程序；而Event組件的作用是使生產(chǎn)和消費(fèi)事件變得容易，允許操作人員使用自己選擇的消息傳遞層。
除了Serving和Event組件之外，Build也是Kantive的組件之一。其提供“運(yùn)行至完成”的顯示功能，這對(duì)創(chuàng)建CI/CD工作流程很有用，通過(guò)靈活的插件化的構(gòu)建系統(tǒng)將用戶源代碼構(gòu)建成容器。
目前，其已經(jīng)支持多個(gè)構(gòu)建系統(tǒng)，比如Google的Kaniko，它無(wú)須運(yùn)行Docker Daemon就可以在Kubernetes集群上構(gòu)建容器鏡像。Serving使用它將源存儲(chǔ)庫(kù)轉(zhuǎn)換為包含應(yīng)用程序的容器鏡像。
在諸多Serverless開(kāi)源項(xiàng)目中，Knative的優(yōu)勢(shì)也是較為明顯的。一方面，Knative以Kubernetes為底層框架，與Kubernetes生態(tài)結(jié)合得更緊密。無(wú)論是云上Kubernetes服務(wù)還是自建Kubernetes集群，都能通過(guò)安裝Knative插件快速地搭建Serverless平臺(tái)。
另一方面，Knative聯(lián)合CNCF，把所有事件標(biāo)準(zhǔn)化為CloudEvent，提供事件的跨平臺(tái)運(yùn)行，同時(shí)讓函數(shù)和具體的調(diào)用方法解耦。在彈性層面，Knative可以監(jiān)控應(yīng)用的請(qǐng)求，并自動(dòng)擴(kuò)縮容，借助于Istio（Ambassador、Gloo等）支持藍(lán)綠發(fā)布、回滾的功能，方便應(yīng)用發(fā)布。
同時(shí)，Knative支持日志的收集、查找和分析，并支持VAmetrics數(shù)據(jù)展示、調(diào)用關(guān)系跟蹤等。
Knative工作原理如圖2-14所示。
▲圖2-14 Knative工作原理
02 功能與策略
1. Serving（服務(wù)）
Serving模塊定義了一組特定的對(duì)象，包括Revision（修訂版本）、Configuration（配置）、Route（路由）和Service（服務(wù)）。Knative通過(guò)Kubernetes CRD（自定義資源）的方式實(shí)現(xiàn)這些Kubernetes對(duì)象。所有Serving組件對(duì)象間的關(guān)系可以參考圖2-15。
▲圖2-15 Serving組件對(duì)象間的關(guān)系
Knative Serving始于Configuration。使用者在Configuration中為部署容器定義所需的狀態(tài)。最小化Configuration至少包括一個(gè)配置名稱(chēng)和一個(gè)要部署容器鏡像的引用。
在Knative中，定義的引用為Revision。Revision代表一個(gè)不變的、某一時(shí)刻的代碼和Configuration的快照。每個(gè)Revision引用一個(gè)特定的容器鏡像和運(yùn)行它所需要的特定對(duì)象（例如環(huán)境變量和卷）。然而，使用者不必顯式創(chuàng)建Revision。Revision是不變的，它們從不會(huì)被改變和刪除。
相反，當(dāng)使用者修改Configuration的時(shí)候，Knative會(huì)創(chuàng)建一個(gè)Revision。這使得一個(gè)Configuration既可以反映工作負(fù)載的當(dāng)前狀態(tài)，也可以用于維護(hù)一個(gè)歷史的Revision列表。
Knative中的Route提供了一種將流量路由到正在運(yùn)行的代碼的機(jī)制。它將一個(gè)HTTP可尋址端點(diǎn)映射到一個(gè)或者多個(gè)Revision。Configuration本身并不定義Route。
2. 彈性伸縮
Serverless架構(gòu)的一個(gè)關(guān)鍵原則是可以按需擴(kuò)容，以滿足需要和節(jié)省資源。Serverless負(fù)載應(yīng)當(dāng)可以一直縮容至零。這意味著如果沒(méi)有請(qǐng)求進(jìn)入，則不會(huì)運(yùn)行容器實(shí)例。如圖2-16所示，Knative使用兩個(gè)關(guān)鍵組件實(shí)現(xiàn)該功能。它將Autoscaler和Activator實(shí)現(xiàn)為集群中的Pod。
▲圖2-16 Knative彈性伸縮原理簡(jiǎn)圖
用戶可以看到它們伴隨其他Serving組件一起運(yùn)行在knative-serving命名空間中。Autoscaler收集達(dá)到Revision并發(fā)請(qǐng)求數(shù)量的有關(guān)信息。為了做到這一點(diǎn)，它在Revision Pod內(nèi)運(yùn)行一個(gè)名為queue-proxy的容器。該P(yáng)od中也運(yùn)行用戶提供的鏡像。
queue-proxy檢測(cè)該Revision上觀察到的并發(fā)量，然后每隔一秒將此數(shù)據(jù)發(fā)送到Autoscaler。Autoscaler每隔兩秒對(duì)這些指標(biāo)進(jìn)行評(píng)估，并基于評(píng)估的結(jié)果增加或者減少Revision部署的規(guī)模。默認(rèn)情況下，Autoscaler嘗試維持每Pod每秒平均接收100個(gè)并發(fā)請(qǐng)求。這些并發(fā)目標(biāo)和平均并發(fā)窗口均可以變化。
Autoscaler也可以利用Kubernetes HPA（Horizontal Pod Autoscaler）來(lái)替代該默認(rèn)配置。這將基于CPU使用率實(shí)現(xiàn)自動(dòng)伸縮，但不支持縮容至零。這些設(shè)定都能夠通過(guò)Revision元數(shù)據(jù)注解（Annotation）定制。
Autoscaler采用的伸縮算法針對(duì)兩個(gè)獨(dú)立的時(shí)間間隔計(jì)算所有數(shù)據(jù)點(diǎn)的平均值。它維護(hù)兩個(gè)時(shí)間窗，分別是60秒和6秒。Autoscaler以?xún)煞N模式運(yùn)作：Stable Mode（穩(wěn)定模式）和Panic Mode（恐慌模式）。在穩(wěn)定模式下，它使用60秒時(shí)間窗的平均值決定如何伸縮部署以滿足期望的并發(fā)量。
如果6秒時(shí)間窗的平均并發(fā)量?jī)纱芜_(dá)到期望目標(biāo)，Autoscaler轉(zhuǎn)換為恐慌模式并使用6秒時(shí)間窗。這讓它更加快捷地響應(yīng)瞬間流量的增長(zhǎng)。它也僅僅在恐慌模式下擴(kuò)容以防止Pod數(shù)量快速波動(dòng)。如果超過(guò)60秒沒(méi)有發(fā)生擴(kuò)容，Autoscaler會(huì)轉(zhuǎn)換回穩(wěn)定模式。
3. Build（構(gòu)建）
Knative的Serving（服務(wù)）組件是解決如何從容器到URL的，而B(niǎo)uild組件是解決如何從源代碼到容器的。Build資源允許用戶定義如何編譯代碼和構(gòu)建容器。這確保了在將代碼發(fā)送到容器鏡像庫(kù)之前以一種一致的方式編譯和打包代碼。下面介紹一些新的組件。
Build：驅(qū)動(dòng)構(gòu)建過(guò)程的自定義Kubernetes資源。在定義構(gòu)建時(shí)，用戶需要定義如何
獲取源代碼以及如何創(chuàng)建容器鏡像來(lái)運(yùn)行代碼。
Build Template：封裝可重復(fù)構(gòu)建步驟以及允許對(duì)構(gòu)建進(jìn)行參數(shù)化的模板。
Service Account：允許對(duì)私有資源（如Git倉(cāng)庫(kù)或容器鏡像庫(kù)）進(jìn)行身份驗(yàn)證。
4. Event（事件）
到目前為止，向應(yīng)用程序發(fā)送基本的HTTP請(qǐng)求是一種有效使用Knative函數(shù)的方式。無(wú)服務(wù)器的松耦合特性同時(shí)也適用于事件驅(qū)動(dòng)架構(gòu)。也就是說(shuō)，可能在文件上傳到FTP服務(wù)器時(shí)需要調(diào)用一個(gè)函數(shù)；或者任何時(shí)間發(fā)生一筆物品銷(xiāo)售時(shí)需要調(diào)用一個(gè)函數(shù)來(lái)處理支付和庫(kù)存更新的操作。
與其讓?xiě)?yīng)用程序或函數(shù)考慮監(jiān)聽(tīng)事件的邏輯，不如當(dāng)那些被關(guān)注的事件發(fā)生時(shí)，讓Knative去處理并通知我們。
自己實(shí)現(xiàn)這些功能則需要做很多工作并要編寫(xiě)實(shí)現(xiàn)特定功能的代碼。幸運(yùn)的是，Knative提供了一個(gè)抽象層使消費(fèi)事件處理變得更容易。
Knative直接提供了一個(gè)“事件”，而不需要編寫(xiě)特定的代碼來(lái)選擇消息代理。當(dāng)事件發(fā)生時(shí)，應(yīng)用程序無(wú)須關(guān)心它來(lái)自哪里或發(fā)到哪里，只需要知道事件發(fā)生了即可。如圖2-17所示，為實(shí)現(xiàn)這一目標(biāo)，Knative引入了三個(gè)新的概念：Source（源）、Channel（通道）和Subscription（訂閱）。
Source（源）：事件的來(lái)源，用于定義事件在何處生成以及如何將事件傳遞給關(guān)注對(duì)象的方式。
Channel（通道）：通道處理緩沖和持久性，即使該服務(wù)已被關(guān)閉，也可確保將事件傳遞到預(yù)期的服務(wù)。另外，通道是代碼和底層消息傳遞解決方案之間的一個(gè)抽象層。這意味著可以像Kafka和RabbitMQ一樣在某些服務(wù)之間進(jìn)行消息交換，但在這兩種情況下都不需要編寫(xiě)特定的實(shí)現(xiàn)代碼。
Subscription（訂閱）：將事件源發(fā)送到通道，并準(zhǔn)備好處理它們的服務(wù)，但目前沒(méi)有辦法獲取從通道發(fā)送到服務(wù)的事件。為此，Knative設(shè)計(jì)了訂閱功能。訂閱是通道和服務(wù)之間的紐帶，指示Knative如何在整個(gè)系統(tǒng)中管理事件。
▲圖2-17 Knative事件處理模型簡(jiǎn)圖
Knative中的服務(wù)不關(guān)心事件和請(qǐng)求是如何獲取的。它可以獲取來(lái)自入口網(wǎng)關(guān)的HTTP請(qǐng)求，也可以獲取從通道發(fā)送來(lái)的事件。無(wú)論通過(guò)何種方式獲取，服務(wù)僅接收HTTP請(qǐng)求。這是Knative中一個(gè)重要的解耦方式。它確保將代碼編寫(xiě)到架構(gòu)中，而不是在底層創(chuàng)建訂閱、通道向服務(wù)發(fā)送事件。
關(guān)于作者：劉宇（花名：江昱），國(guó)防科技大學(xué)電子信息專(zhuān)業(yè)博士，阿里云Serverless產(chǎn)品體驗(yàn)側(cè)負(fù)責(zé)人，從事Serverless相關(guān)的工作多年，負(fù)責(zé)阿里云函數(shù)計(jì)算（FC）、Serverless工作流（FNF）等產(chǎn)品的體驗(yàn)工作，有豐富的實(shí)踐經(jīng)驗(yàn)。阿里云戰(zhàn)略級(jí)開(kāi)源項(xiàng)目Serverless Devs發(fā)起人和負(fù)責(zé)人，Serverless Framework、Kubevela等開(kāi)源項(xiàng)目貢獻(xiàn)者，社區(qū)項(xiàng)目Anycodes在線編程負(fù)責(zé)人。
本文摘編自《Serverless工程實(shí)踐：從入門(mén)到進(jìn)階》，經(jīng)出版方授權(quán)發(fā)布。
延伸閱讀《Serverless工程實(shí)踐：從入門(mén)到進(jìn)階》
點(diǎn)擊上圖了解及購(gòu)買(mǎi)
轉(zhuǎn)載請(qǐng)聯(lián)系微信：DoctorData
推薦語(yǔ)：從產(chǎn)品、開(kāi)發(fā)和工程實(shí)踐3個(gè)維度全面講解Serverless架構(gòu)。阿里云Serverless產(chǎn)品專(zhuān)家和技術(shù)專(zhuān)家撰寫(xiě)。
劃重點(diǎn)👇
干貨直達(dá)👇
吐血整理！12種通用知識(shí)圖譜項(xiàng)目簡(jiǎn)介
50%企業(yè)數(shù)據(jù)治理失敗！這9大要素才是成功關(guān)鍵
多段實(shí)例代碼詳解7大類(lèi)Python運(yùn)算符，建議收藏！
4918字，詳解商品系統(tǒng)的存儲(chǔ)架構(gòu)設(shè)計(jì)
更多精彩👇
在公眾號(hào)對(duì)話框輸入以下關(guān)鍵詞
查看更多優(yōu)質(zhì)內(nèi)容！
讀書(shū)?|?書(shū)單?|?干貨?|?講明白?|?神操作?|?手把手
大數(shù)據(jù)?|?云計(jì)算?|?數(shù)據(jù)庫(kù)?|?Python?|?爬蟲(chóng)?|?可視化
AI?|?人工智能?|?機(jī)器學(xué)習(xí)?|?深度學(xué)習(xí)?|?NLP
5G?|?中臺(tái)?|?用戶畫(huà)像?|?數(shù)學(xué)?|?算法?|?數(shù)字孿生
據(jù)統(tǒng)計(jì)，99%的大咖都關(guān)注了這個(gè)公眾號(hào)
👇
總結(jié)
以上是生活随笔為你收集整理的终于有人把Knative讲明白了的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
